CapitalOne data breach: How SSRF vulnerability exposed 100 million customer records

Table of Contents

Table of Contents

Introduction

Although the CapitalOne breach occurred in 2018, the methodologies and lessons learned remain highly relevant today. In 2018, CapitalOne, a US-based bank, suffered a massive data breach where over 100 million customer records stored in a private S3 bucket were compromised. The attack was executed by a former AWS employee who exploited a vulnerability in Capital One’s infrastructure, leveraging insider knowledge and expertise with AWS services.

As a result of this breach, Capital One agreed to pay $80 million to settle federal bank regulators’ claims that it lacked proper cybersecurity protocols, highlighting the severe repercussions of inadequate cloud security measures.

This article delves into the specifics of the data exposure, offering an easy-to-understand guide with illustrative details. We also provide guidelines for detection and prevention to help safeguard against similar cloud security threats.

What happened in the CapitalOne data breach?

  1. Threat actor exploited a SSRF vulnerability in CapitalOne’s WAF to access the AWS metadata service
  2. The Threat actor gotten credential from the metadata service
  3. The threat actor mounted the S3 bucket with the stolen credentials and started accessing data stored in the S3 bucket.

The SSRF allows the threat actor to bounce their web request to any IP of the threat actor’s choosing and SSRF is a well-known vulnerability that is listed on the OWASP’s top 10 web vulnerability. There are at least 4 SSRF vulnerabilities that were patched in Azure cloud services in Jan-2023 alone and threat actor will continue to exploit this vulnerability.

Mapping the attack to MITRE ATT&CK framework

We can map the attacks to the following Tactics, Techniques, and Procedures (TTPs) in MITRE.

What is metadata service?

The AWS metadata service is an essential component for compute instances running in AWS. It provides information about the instance and its environment. This service is accessed through a special IP address (169.254.169.254) and provides various types of metadata such as:

  • Instance ID
  • Security group name
  • Public IP of the instance

Accessing http://169.254.169.254/latest/meta-data from within a virtual machine provides this information. This also works from within a container running in Amazon Elastic Kubernetes Service (EKS).

What sensitive information can be leaked from the AWS metadata service?

If the ‘IAM’ profile is attached to the EC2 instance, accessing the URL http://169.254.169.256/latest/meta-data/iam/security-credentials/ from within the compute instance will reveal a temp access key (Security Token Service – STS). This mechanism provides the developer a way to avoid hard-coding credential into the application. The developer simply has to attach the ‘IAM’ profile to the compute instance, so that the application can request for the temp access key only when needed (Just-In-Time access).

The following is an example of access key which can be gotten from the metadata service when the ‘curl’ is launched from within a EC2 instance with an IAM profile attached.

ubuntu@ip-xxx-xx-xx-x:~$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2_ROLE_NAME

{
"Code" : "Success",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIA5A6XXXXXXXIFH5UQ",
"SecretAccessKey" : "sXXXXXXXXXXkBcJunpyR",
"Token" : "AgoXXX--SNIP--XXXs=",
"Expiration" : "2024-08-04T03:16:50Z"
}

With the access key, the threat actor could simply mount the S3 bucket with the following commands:

> set AWS_ACCESS_KEY_ID=Stolen_Access_Key
> set AWS_SECRET_ACCESS_KEY=Stolen_Secret_key
> set AWS_SESSION_TOKEN=Stolen_Token
> aws s3 ls s3://bucket-name

How to detect?

There are multiple opportunities for detection. Let’s walk through the timeline and determine possible detection strategies. In Stage 3, when the attacker was accessing the S3 bucket, we can detect such activities by:

  1. Detect for file access anomaly to S3
  2. Detecting logins from unusual IP

Summary of detection strategies

Below is a summary table outlining the threats demonstrated by the threat actor on the cloud and corresponding detection strategies.

ThreatsDetection strategiesStage in illustration
Threat actor accessing the S3 bucket with the stolen API keyDetect logins from unusual locations.Detect for spike in data access in S3.3

Staying ahead of cyber threats

In a world where cyber threats like the CapitalOne breach can compromise millions of records, staying ahead of attackers requires cutting-edge solutions. InsiderSecurity empowers businesses with advanced cybersecurity behavior analytics to safeguard both on-premise and cloud infrastructures.

Innovative solutions for cloud security

CSX is designed to detect and respond to sophisticated attacks like those seen in the CapitalOne incident. Here’s how CSX ensures robust security:

  • Unusual Login Detection: CSX triggers alerts for logins from unfamiliar IP addresses
CSX alert identifying login anomalies
Remediation steps for login anomalies
  • Data Access Monitoring: By flagging unusual spikes or irregular access patterns in S3 buckets, CSX prevents unauthorized data exposure.
Detailed view of anomalous S3 bucket activity detected by CSX
Recommendations for mitigating data access anomalies

Actionable Recommendations

What sets InsiderSecurity apart is its ability to provide actionable recommendations immediately after detecting threats. By combining real-time detection with actionable recommendations, InsiderSecurity ensures your team can mitigate threats efficiently and effectively.