1. Lessons Learned from Capital One Breach & More
Leon Jiang
Sep 2019

2. Leon - Who is this guy?
Current: Director of InfoSec at Roostify, a fintech startup in SF
Past: 11 years with Oracle, MBA
An experienced information security practitioner with strong business acumen.

3. Disclaimer
Many facts are obtained from the federal document or other public sources. However, some parts are hypothetical analysis for research and future reference purpose only which may not necessarily be truthful or pertained to Capital One breach.

4. Capital One Breach - What Happened
7/29 - Capitale announced a breach. On the same day, a federal criminal complaint filed against the alleged hacker known as ‘Erratic’.
7/17 - A reporting sent to Capital One alleging there appeared to be leaked data belonging to Capital One.
4/21 - Erratic uploaded a file to GitHub gist (a code sharing feature separated from GitHub main site, similar to pastebin) which contains commands to access Capital One data but NOT the data itself
8/28 - From the released indictment, not just Capital One, 30+ other companies were being victims of the same hacker between March and July 2019

5. Analysis Efforts from My End

6. How Could it Happen? -From the Criminal Complaint
1st Command
Obtain (AWS) Credential
2nd Command
List (S3) Buckets
3rd Command
Sync (S3) Data

7. How Could it Happen? - From Her Twitter

8. Key Point - IAM Role on EC2 Instances
What is it?
According to AWS, We designed IAM roles so that your applications can securely make API requests from your instances, without requiring you to manage the security credentials that the applications use.
To simplify, no more username/password or API Key, you have the right once you’re on the machine.
How did it go wrong in these cases?
Too much privilege were given to the roles - i.e. violating LEAST PRIVILEGE principle

9. Last Line of Defense - App/Field Level Encryption
100 million individuals was affected, but only 140,000 social security numbers and 80,000 bank account numbers were disclosed.
Why? It could be encryption
Encrypted data at field or application level so much of the leaked data is not readable
As a comparison - Instance/database/bucket level encryption won’t help much in this scenario

10. Questions Remain Unclear
How were the instances compromised in the first place? For Capital One case, different theories
Federal Doc: Misconfigured firewall (but how?)
Evan J: SSRF (server side request forgery) Instance is not compromised but rather a temporary AWS credential is obtained and following attacks remains the same except not directly launched from the compromised instance
Why has it never been detected until reported?
Enough suspicious activities: Connection coming from TOR, S3 files sync, data dump, instance launch, malicious software deployed.
AWS has some tools such as Guard Duty, Macie, and now Security Hub
Of course, running a SOC with thousands of alerts everyday is never easy!

11. Summary of Lessons Learned
Least privilege on IAM role assignment and anything else
Extra caution on AWS access
Examine the need of IAM roles for Internet facing servers
Lock down the IP that those credentials can be used
Application level encryption of data or file elements to be stored in DB or S3
Secure and patch vulnerable instances
Detection and monitoring
A lot of ML/AI based tool is on the rise but the effect is to be examined.

12. References
charges-wire-fraud-and-computer-data-theft