The one year anniversary of Capital One’s data breach is rapidly approaching. Therefore, I thought it was a good time to review the lessons we can take from the breach in order to prevent it from happening in the future.
Information about the breach and the person responsible is abundant and has been beaten into the ground in its entirety by countless blog posts and news articles, so rather than having that discussion again, let’s dive into what happened from a technical standpoint. As a general note, some of the pieces here are extrapolations and assumptions I pulled from the indictment, but I tried to pick the most likely scenarios of what happened.
- An EC2 instance running WAF software (ModSecurity) was compromised in Capital One’s account via SSRF.
- The AWSmetadata service was queried, and it returned information about a role that was attached to the instance as well as the access token for the role.
- The role was titled *-WAF-* but had unnecessary permissions to read from S3 (and most likely kms:decrypt as well).
- A bucket was found via the role that had access to a sensitive S3 bucket.
- Data was decrypted and exfiltrated from the account.