Inside Capital One’s game-changing breach: What happened and key lessons

Learn how the Capital One data breach happened and how its legal implications continue to affect the work of cybersecurity professionals.

How the Capital One breach happened

In this episode of Cyber Work Applied, Infosec Principal Security Researcher Keatron Evans breaks down how the Capital One breach happened and shares key lessons cybersecurity professionals should take away from it. Watch the full video below to learn more.

Cyber Work listeners get free cybersecurity training resources. Click below to see free courses and other free materials.

Free Cybersecurity Training

Capital One breach walkthrough

The edited transcript of Keatron’s breakdown of the Capital One data breach is provided below.

Capital One breach impact

(0:00-0:22) The Capital One data breach via Amazon AWS resources was one of the more fascinating and game-changing data breaches of recent times. It involved two of the largest and most respected organizations in the world and led to some new legal precedents that will likely change how we do cybersecurity consulting in business.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

SSRF vulnerability exploitation

(0:23-0:49) The Capital One breach involved an attacker who exploited a vulnerability called SSRF or Service Side Request Forgery. What happens in this type of attack is that the service or server is tricked into running a command or doing an action to a client that the server didn't actually make. Imagine those science fiction movies where aliens implant themselves in our brains and make us do things we wouldn't normally do.

Bypassing the web application firewall (WAF)

(0:50- 1:44) In this case, the alien is the hacker, and the brain is the Capital One web application firewall or WAF. The job of the firewall is to examine every request going to the server it protects and only pass on to the server the requests that it considers to be safe. So, anything coming from the firewall is deemed safe. In the Capital One incident, the hacker tricked the WAF into thinking that a specific request was good when in essence, it was not.

The server on the other hand, which was configured in such a way to allow the trusted WAF to do whatever it wanted, processed the request. I mean, after all the WAF is its protector, so why not trust it? The WAF then simply listed the contents of the server holding credit card application information, including personally identifiable information or PII, and sent that list back out to the attacker.

AWS permissions issue

(1:45- 2:01) Keep in mind this only worked because the AWS role assigned to the WAF had more permissions than it likely needed, which is why it was able to query, decrypt, and eventually exfiltrate some data via one of the AWS metadata services.

Capital One official data breach report

(2:02- 2:44) As a result of this breach, in May of 2020, a U.S. magistrate judge in the Eastern District of Virginia ordered Capital One to release the official data breach report. This report was prepared by their outside consulting firm, Mandiant, and given to the class action plaintiffs.

Let me repeat that: the data breach report, which could include confidential details of configurations, safeguards, software, method of the breach and more, was ordered to be released to class action plaintiffs. This essentially means that all that sensitive data was to be released to anyone in the class action and could eventually be given to the general public.

How the case impacts incident responders

(2:45- 3:02) That order changes the game because now, as someone who regularly consults and does incident response with clients, I have to reconsider what I put in those reports. Some of the stuff that I might've put into report briefing meetings before now ends up being additional conversation knowledge.

Takeaways from the incident

(3:03- 4:17) As you migrate to the cloud, you're still a target, you're still vulnerable, and your data is still valuable. Don't let up on your diligence, even for a second.

Some things to take away from the Capital One data breach include the following:

• Make sure all your web-facing apps and APIs are locked down and regularly tested for security issues.
• Make sure you're using the latest version of AWS metadata service.
• Implement services like CloudWatch, CloudTrail, Macie and GuardDuty to minimize some of the risk.
• Make sure your AWS roles are architected with the principle of least privilege in mind.
• Use tokenization with your encryption solutions, whether you're using AWS KMS, Secrets Manager, or any other crypto combination or solution,
• Ensure you're using logging to its fullest and most efficient potential.

This was certainly one of the most far-reaching data breaches we've seen as it involved two large organizations, a class action court case, and a peek into how the U.S. Department of Justice will go about prosecuting these crimes and collecting evidence in the future.

More cybersecurity training resources

Check out the weekly Cyber Work Podcast for in-depth conversations with cybersecurity practitioners and industry thought leaders — plus other free cybersecurity videos.

Cyber Work listeners also get more free cybersecurity resources. See the latest free training courses and resources and keep learning!

Free Cybersecurity Training