Case Study 1: Capital One SSRF — How Reconnaissance Revealed the Attack Path
Background
On July 19, 2019, Capital One Financial Corporation disclosed one of the largest data breaches in the financial services industry. Approximately 106 million customer records were exposed, including 140,000 Social Security numbers and 80,000 linked bank account numbers. The breach was executed by Paige Thompson, a former Amazon Web Services (AWS) employee, who exploited a Server-Side Request Forgery (SSRF) vulnerability in Capital One's web application firewall to access the AWS metadata service and obtain temporary IAM credentials.
This case study examines how active reconnaissance techniques — particularly web application fingerprinting, cloud infrastructure identification, and metadata service exploitation — mirror the attack path that led to one of the most significant cloud security breaches in history.
The Attack Path
Phase 1: Reconnaissance and Discovery
Thompson's attack began with identifying Capital One's infrastructure through techniques directly covered in this chapter:
Cloud Provider Identification: Capital One was one of AWS's most prominent enterprise customers, having publicly announced their "all-in on AWS" cloud migration strategy. This information was freely available through press releases, conference presentations, and AWS case studies — classic passive OSINT. However, active reconnaissance would have confirmed this through:
- HTTP response headers revealing AWS infrastructure (e.g., x-amz-* headers)
- DNS CNAME records pointing to AWS services (CloudFront, ELB, S3)
- SSL certificates issued for AWS-hosted endpoints
- IP address ranges belonging to AWS (verifiable through AWS's published IP ranges JSON file)
WAF Identification: Capital One used a ModSecurity-based Web Application Firewall. Active reconnaissance techniques like those covered in Section 8.4.5 could identify the WAF through: - Error response patterns specific to ModSecurity - WAF detection tools like wafw00f - Behavioral analysis of how the WAF responded to crafted requests
Technology Stack Discovery: The vulnerable application was a web application running on an EC2 instance behind a WAF. Web fingerprinting techniques (Section 8.4) would have revealed the technology stack, and content discovery might have identified unusual endpoints.
Phase 2: The SSRF Vulnerability
The critical vulnerability was a Server-Side Request Forgery (SSRF) in the WAF configuration. SSRF allows an attacker to cause the server to make HTTP requests to arbitrary destinations — including internal services that should not be accessible from the internet.
How active reconnaissance connects to SSRF discovery:
During active reconnaissance of web applications, penetration testers routinely: - Test for SSRF by submitting URLs that point to internal services - Check whether the application fetches external resources (images, URLs, files) - Probe for interaction with cloud metadata services
In Capital One's case, the WAF was misconfigured to allow requests to the AWS Instance Metadata Service (IMDS) at http://169.254.169.254/. This is a well-known target in cloud penetration testing.
Phase 3: Metadata Service Exploitation
The AWS Instance Metadata Service (IMDS) v1 is accessible via HTTP GET requests from any process running on an EC2 instance. Through the SSRF vulnerability, Thompson was able to reach the metadata service and retrieve:
# The critical request (via SSRF)
http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE-NAME]
# This returned temporary AWS credentials:
{
"AccessKeyId": "ASIA...",
"SecretAccessKey": "...",
"Token": "...",
"Expiration": "..."
}
With these temporary IAM credentials, Thompson had the same permissions as the EC2 instance's IAM role — which included access to S3 buckets containing customer data.
Phase 4: Data Exfiltration
Using the stolen credentials, Thompson accessed over 700 S3 folders and downloaded approximately 30 GB of data. She then posted about the breach on social media (which ultimately led to her identification and arrest).
Active Reconnaissance Lessons
Lesson 1: Cloud Infrastructure Discovery is Critical
The Capital One breach demonstrates why identifying cloud infrastructure during active reconnaissance is essential. When you discover that a target uses AWS, the following attack vectors immediately become relevant: - SSRF to the metadata service (169.254.169.254) - Misconfigured S3 buckets (publicly accessible or writable) - Exposed AWS API endpoints - IAM role and permission misconfigurations - Unprotected Lambda function URLs
Reconnaissance approach: During web fingerprinting, look for:
- x-amz-request-id, x-amz-id-2 headers (S3)
- x-amzn-RequestId headers (API Gateway, Lambda)
- CNAME records to *.amazonaws.com, *.cloudfront.net, *.elasticbeanstalk.com
- S3 bucket URLs in page source code
- AWS SDK references in JavaScript files
Lesson 2: WAF Misconfiguration as an Attack Vector
The WAF itself was the vulnerability. This counterintuitive finding highlights why WAF detection and analysis during active recon is important: - Identifying the WAF tells you what security controls are in place - Understanding the WAF's configuration reveals potential weaknesses - WAFs that proxy requests can introduce SSRF vulnerabilities - WAF bypass techniques are WAF-specific
Reconnaissance approach: During WAF detection, note: - Does the WAF proxy requests (processing request bodies)? - Does the WAF fetch external resources? - What error messages does the WAF produce? - Can you identify the WAF version (for known vulnerability research)?
Lesson 3: The Metadata Service is a Primary Target
The AWS Instance Metadata Service is one of the most critical targets in cloud penetration testing. Active reconnaissance should always include checks for metadata service accessibility:
# Test for SSRF to metadata service
# (through any user-controllable URL parameter)
curl "https://target.com/fetch?url=http://169.254.169.254/latest/meta-data/"
# Test for metadata service on the host itself
# (if you have any code execution)
curl http://169.254.169.254/latest/meta-data/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
Since the Capital One breach, AWS has introduced IMDSv2, which requires a session token obtained through a PUT request before metadata can be accessed. This mitigates simple SSRF attacks but does not eliminate the risk entirely.
Lesson 4: Active Recon Reveals Cloud Security Posture
Through active reconnaissance, penetration testers can assess an organization's cloud security posture:
| Finding | Indicates |
|---|---|
| IMDSv1 accessible without session token | Missing IMDSv2 enforcement |
| S3 bucket URLs in source code | Potential for bucket enumeration |
| AWS API Gateway without authentication | Exposed backend services |
| Excessive CORS headers | Potential for cross-origin attacks |
| CloudFront without WAF | Missing edge security |
| Elastic Beanstalk default configurations | Potentially insecure defaults |
The Timeline and Response
| Date | Event |
|---|---|
| March 12-23, 2019 | Thompson executes the attack over multiple days |
| March 22-23, 2019 | Data exfiltration from S3 buckets |
| April 21, 2019 | Thompson posts on social media about the breach |
| July 17, 2019 | Tipster reports the social media posts to Capital One |
| July 19, 2019 | Capital One publicly discloses the breach |
| July 29, 2019 | Thompson arrested by FBI |
| June 2022 | Thompson convicted of wire fraud and computer crimes |
| August 2020 | Capital One fined $80 million by OCC for the breach |
What Capital One Should Have Done Differently
From an active reconnaissance and security perspective:
-
Enforce IMDSv2: Requiring session tokens for metadata service access would have prevented the SSRF exploitation chain.
-
Restrict IAM role permissions: The EC2 instance's IAM role had access to 700+ S3 folders containing customer data. The principle of least privilege should have limited access to only necessary resources.
-
WAF configuration review: Regular security assessments of the WAF configuration — including SSRF testing — should have identified the vulnerability before exploitation.
-
Network segmentation: The web application should not have been able to reach S3 buckets containing sensitive data without additional access controls.
-
Monitoring and alerting: The exfiltration of 30 GB of data over multiple days should have triggered automated alerts.
Discussion Questions
-
During a penetration test, you discover that a target's web application is hosted on AWS and uses a WAF. Describe the specific active reconnaissance steps you would take to assess the SSRF risk to the metadata service.
-
The Capital One breach was ultimately discovered because the attacker posted about it on social media. What detection mechanisms should have identified the breach earlier? How does this relate to the "assume breach" security mindset?
-
AWS has introduced IMDSv2 as a mitigation for metadata service attacks. Research IMDSv2 and explain how it works, its limitations, and how a penetration tester should test for IMDSv2 enforcement during active reconnaissance.
-
Capital One was fined $80 million for this breach. Discuss how regular penetration testing with thorough active reconnaissance might have prevented this breach and whether the cost of such testing would have been justified.
-
The attacker was a former AWS employee. How does insider knowledge change the reconnaissance phase of an attack, and how should organizations account for insider threats in their security testing programs?
Key Takeaways
- Cloud infrastructure discovery during active reconnaissance directly maps to critical attack vectors including SSRF, metadata service exploitation, and IAM credential theft.
- Web Application Firewalls can themselves be sources of vulnerability, particularly SSRF through request proxying.
- Technology stack identification guides vulnerability research — knowing a target uses AWS immediately opens specific attack vectors for investigation.
- Active reconnaissance of cloud environments should always include testing for metadata service accessibility, S3 bucket enumeration, and IAM configuration weaknesses.
- The Capital One breach was entirely preventable with proper configuration, least-privilege access controls, and regular security testing.