Full Report
In 2019, Capital One had over 100 million consumer credit applications exfiltrated from their AWS environment. The root cause was a combination of two main factors: first, a Server Side Request Forgery (SSRF) vulnerability in a Web Application Firewall (WAF) named “ModSecurity...
Analysis Summary
# Incident Report: 2019 Capital One AWS Data Breach
## Executive Summary
In 2019, a former Amazon Web Services (AWS) employee exploited a misconfigured Web Application Firewall (WAF) to exfiltrate over 100 million credit card applications from Capital One’s cloud environment. The attacker leveraged a Server-Side Request Forgery (SSRF) vulnerability to obtain high-privileged IAM credentials. The incident resulted in significant regulatory fines, personal data exposure, and a landmark shift in how cloud providers secure metadata services.
## Incident Details
- **Discovery Date:** July 17, 2019
- **Incident Date:** March 12 – July 17, 2019
- **Affected Organization:** Capital One Financial Corp.
- **Sector:** Financial Services / Banking
- **Geography:** United States & Canada
## Timeline of Events
### Initial Access
- **Date/Time:** March 12, 2019
- **Vector:** Server-Side Request Forgery (SSRF)
- **Details:** The attacker exploited a vulnerability in a misconfigured ModSecurity WAF instance to relay a request to the AWS Instance Metadata Service (IMDS).
### Lateral Movement
- **Movement:** After obtaining temporary security credentials from the IMDS via the SSRF vulnerability, the attacker assumed the permissions of the WAF’s IAM Role. This role was overly permissive, allowing "List" and "Read" access to numerous S3 buckets across the environment.
### Data Exfiltration/Impact
- **Details:** Between March and April 2019, the attacker executed commands to sync data from over 700 S3 buckets to local storage. This included roughly 100 million records from U.S. applicants and 6 million from Canadian applicants.
### Detection & Response
- **Discovery:** On July 17, 2019, an external researcher/whistleblower notified Capital One via their "security" email inbox after seeing the stolen data posted on GitHub.
- **Response Actions:** Capital One immediately validated the claim, notified the FBI, and revoked the compromised IAM credentials. The suspect was arrested on July 29, 2019.
## Attack Methodology
- **Initial Access:** Exploitation of SSRF in ModSecurity WAF.
- **Persistence:** None (Attacker relied on ongoing access to the misconfigured resource).
- **Privilege Escalation:** Exploiting the AWS EC2 Metadata Service to retrieve temporary IAM credentials for an overly permissive service role.
- **Defense Evasion:** Use of Tor and VPNs (e.g., IPVanish) to mask the source IP during the exfiltration process.
- **Credential Access:** Accessing the IMDSv1 `http[://]169[.]254[.]169[.]254/latest/meta-data/iam/security-credentials/` endpoint.
- **Discovery:** Execution of `s3 ls` commands to enumerate all available storage buckets.
- **Lateral Movement:** Cloud-native credential pivoting from the WAF instance to the S3 storage layer.
- **Collection:** Aggregating data from hundreds of S3 buckets containing sensitive PII.
- **Exfiltration:** Standard cloud CLI commands (`s3 sync`) to move data to an external environment.
- **Impact:** Theft of approximately 140,000 Social Security numbers and 80,000 linked bank account numbers.
## Impact Assessment
- **Financial:** Capital One was fined $80 million by the OCC and reached a $190 million class-action settlement. Total costs exceeded $400 million.
- **Data Breach:** Exposure of names, addresses, credit scores, transaction history, and Social Security numbers belonging to over 106 million individuals.
- **Operational:** Required a massive audit of all AWS IAM roles and S3 bucket policies.
- **Reputational:** Significant negative press and loss of trust regarding "cloud-first" banking strategies.
## Indicators of Compromise
- **Network indicators:** Traffic originating from Tor exit nodes and `IPVanish` VPN IP ranges.
- **Behavioral indicators:** Unusual volume of `GetBucket` and `ListBucket` API calls recorded in AWS CloudTrail from a WAF instance; access to `169.254.169.254` via the WAF application logs.
## Response Actions
- **Containment:** Revocation of the compromised IAM role and shutting down the vulnerable WAF instance.
- **Eradication:** Removal of the leaked data from GitHub and forensic imaging of affected cloud resources.
- **Recovery:** Mandatory credit monitoring offered to all 106 million affected customers.
## Lessons Learned
- **The Danger of Over-privileged Roles:** The WAF did not need broad "List" and "Read" access to every S3 bucket in the account. The Principle of Least Privilege (PoLP) was not enforced.
- **IMDSv1 Vulnerability:** The legacy Instance Metadata Service (v1) lacked protection against SSRF (specifically the lack of a session header requirement).
- **External Reporting:** The incident was discovered via a tip, highlighting the importance of a well-monitored vulnerability disclosure program (VDP).
## Recommendations
- **Upgrade to IMDSv2:** Enforce the use of AWS IMDSv2, which requires a session token/PUT header, effectively neutralizing SSRF-based credential theft.
- **IAM Hardening:** Use IAM Access Analyzer to identify and remove unused permissions and ensure service roles are scoped only to required resources.
- **S3 Sentinel Policies:** Implement S3 Public Access Blocks and utilize automated tools to alert on massive data transfers or "Sync" commands from unconventional compute instances.
- **SSRF Filtering:** Implement strict egress filtering on web servers to prevent them from making unauthorized internal requests.