Originally reported by CIO Dive. This article expands on the reported details for a DevOps engineering audience.
Background: The Capital One Breach
In July 2019, Capital One disclosed a data breach affecting approximately 106 million customers — one of the largest financial-sector breaches on record. The attacker, Paige Thompson (also known online as “erratic”), was a former cloud infrastructure engineer. The incident drew immediate scrutiny toward Capital One’s public cloud strategy and its use of Amazon Web Services (AWS).
In response to a formal inquiry from Senator Ron Wyden (D-OR) about AWS’s role in the breach, AWS CISO Stephen Schmidt issued a detailed response. His letter clarified the technical mechanics of the attack, the limits of AWS’s security responsibility, and actions AWS committed to taking to better support customers going forward.
How the Attack Worked: SSRF and Permissions Escalation
According to Schmidt, the attacker exploited a Server-Side Request Forgery (SSRF) vulnerability in Capital One’s environment. SSRF allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain or internal resource — in this case, the AWS instance metadata service (IMDSv1), which can expose temporary IAM credentials if not properly restricted.
The SSRF exploit was then amplified by excessive IAM permissions. The credentials retrieved via SSRF had broader access than they should have, enabling the attacker to move laterally and exfiltrate large volumes of data from S3 buckets.
Schmidt was careful to note that SSRF was not the “primary factor” in the breach — the overly permissive IAM role attached to the WAF was equally, if not more, significant. He also acknowledged that there may be small numbers of similar SSRF-based incidents that AWS was never informed about.
The Root Cause: A Misconfigured Web Application Firewall
Capital One had a misconfigured Web Application Firewall (WAF) — the first line of defense between incoming web traffic and internal resources. A WAF misconfiguration created the opening that allowed the SSRF attack to succeed.
WAF configuration is the customer’s responsibility. AWS provides documentation, how-to guides, and professional services to help customers configure their WAFs correctly, but only the customer has full visibility into what behavior they intended for their own resources. AWS cannot audit or override a customer’s WAF rules without consent.
The Shared Responsibility Model in Practice
The Capital One breach is a textbook illustration of the AWS Shared Responsibility Model. AWS secures the underlying infrastructure — physical data centers, the hypervisor, the global network fabric. Customers are responsible for everything they deploy on that infrastructure: operating systems, network configurations, IAM policies, firewall rules, and application logic.
- AWS is responsible for: Security of the cloud — hardware, software, networking, and facilities.
- Customers are responsible for: Security in the cloud — IAM policies, WAF rules, encryption settings, network ACLs, and application vulnerabilities.
Schmidt confirmed that AWS was not aware of any other “noteworthy” compromises of AWS customers related to this attack vector at the time of his response, and that Capital One’s SSRF-driven breach was the only compromise of “significant scale” AWS was aware of.
What AWS Committed to Doing Differently
Despite the responsibility gap lying primarily with Capital One, Schmidt outlined several proactive measures AWS pledged to undertake:
- Proactive scanning of public IP space: AWS committed to scanning customer-facing firewall resources for detectable misconfigurations, erring on the side of over-communicating findings to customers.
- Reducing permissive IAM permissions: AWS said it would “redouble” efforts to help customers identify and tighten overly broad IAM policies — a key amplifier in the Capital One attack.
- Outreach to affected companies: Law enforcement later revealed that Thompson had breached more than 30 other organizations, with data stored locally. AWS proactively contacted those companies to offer security assistance. Schmidt noted those customers had not yet reported significant issues.
Key Lessons for DevOps and Security Teams
The Capital One breach remains one of the most instructive case studies in cloud misconfiguration risk. For DevOps and platform engineering teams, the takeaways are concrete:
- Apply the principle of least privilege aggressively. IAM roles should have only the permissions they strictly need. An EC2 instance running a WAF should not have broad S3 read access.
- Restrict access to the instance metadata service. AWS has since introduced IMDSv2, which requires a session-oriented request and mitigates many SSRF-based credential theft attacks. Enforce IMDSv2 on all EC2 instances.
- Audit WAF rules regularly. A WAF is only as effective as its configuration. Treat WAF rule sets as living infrastructure — test, review, and update them as your application changes.
- Use AWS security tooling proactively. Services like AWS Config, IAM Access Analyzer, and AWS Security Hub can surface misconfigurations before attackers find them.
- Don’t assume provider defaults are secure for your workload. Cloud providers set sensible defaults, but “sensible” is not the same as “appropriate for your threat model.”
Conclusion
The AWS CISO’s response to Senator Wyden was a candid acknowledgment of a long-standing tension in cloud computing: providers control the infrastructure, but customers control the configuration. Capital One’s breach was not caused by a failure in AWS’s infrastructure — it was caused by a misconfigured WAF and an overly permissive IAM role that the customer owned and managed.
That said, Schmidt’s willingness to commit AWS to more proactive scanning and clearer communication reflects an industry-wide recognition that “shared responsibility” cannot be a phrase providers use only when things go wrong. Cloud providers have both the visibility and the tooling to help customers avoid common misconfigurations — and there is a growing expectation that they will use them.
Source: CIO Dive