Cloud Snitch

Capital One Data Breach – A Cautionary Tale

In July of 2019, Capital One Financial Corporation announced that they had recently become aware of a data breach compromising the personal data of over 100 million customers in the United States, including 140,000 Social Security numbers and 80,000 bank account numbers. Capital One estimated that the direct financial impact of the incident would be between $100 million and $150 million for notifications, credit monitoring, technology, and legal support. Furthermore, trust in the company had plummeted, and within two weeks of the incident, Capital One's share price had dropped by 14%.

The impact was substantial, but it might have been much less severe if not for the fact that the breach had occurred almost four months before it was discovered. Capital One had been moving its operations to the cloud, and had failed to adequately manage the risk of doing so. This mistake would later cost them another $80 million in fines when all was said and done.

So what should they have done to manage their risk better? Let's break down the incident in detail so we can learn from their mistakes.

Foothold

On March 22, 2019, the attacker discovered that they could trick Capital One EC2 servers running in AWS into executing arbitrary HTTP requests, enabling a type of attack known as Server Side Request Forgery (SSRF). They were able to do this as a result of a misconfigured web application firewall (WAF) known as ModSecurity. The WAF allowed the attacker to send requests to the AWS metadata service, which among other things provides the EC2 servers with temporary credentials for the purpose of invoking AWS APIs.

At this point, the attacker could impersonate the EC2 servers and perform any action that the associated IAM role allowed.

Lateral Movement

Once the attacker gained their foothold, they began to enumerate everything they had access to. Usually, this is loud as attackers typically just have to try things and see what works. If you were to look at this role in Cloud Snitch, you would see it attempting (and hopefully failing) to do a lot of things that you would not expect a WAF to do.

In Capital One's case, the permissions attached to the role allowed the attacker to read and decrypt sensitive data from Amazon S3 buckets. The attacker was able to exfiltrate all of this data via the WAF's credentials, which again should have sounded alarm bells.

Discovery

Capital One had completely failed to detect the intrusion. They only became aware of it when a third party notified them via their Responsible Disclosure Program on July 17, 2019.

Capital One was completely oblivious to the fact that there was an intruder in their cloud for almost four months. The presence of the intruder would have made a lot of noise in their CloudTrail logs, but without the proper tools, that log activity went completely unnoticed. This is why Cloud Snitch was created.

With Cloud Snitch, you can easily confirm that your AWS resources are doing what you expect them to do and nothing more.

Further Reading