Capital One Data Breach Exposes 100 Million Records to Seattle Hacker

Barely a week after the Equifax data breach was settled for nearly $650 million dollars, there appears to be news of an almost equally large mega-breach which was announced today by Capital One. Capital One said in a statement that this breach has affected approximately 100 million individuals in the United States and approximately 6 million in Canada. This breach appears to be largely related to credit card application data as the statement notes “The largest category of information accessed was information on consumers and small businesses as of the time they applied for one of our credit card products from 2005 through early 2019.”

According to complaint information noted in the United States Attorney’s Office in the Western District of Washington, a software engineer turned hacker from Seattle, Paige Thompson (aka “erratic”), is being charged for involvement in the unlawful access and exfiltration of this data under the Computer Fraud and Abuse Act (CFAA).

On July 17, 2019, Capital One was notified of the potential breach through an email address ([email protected]) which it uses to solicit disclosures of actual or potential vulnerabilities in its computer systems. The screen capture shown below is from the complaint document, you can see that it notes that there is potential “Leaked s3 data.”

The moniker “s3” stands for Simple Storage Service and it is a service hosted by Amazon Web Services (AWS). Also according to the complaint, a firewall misconfiguration was to blame for the initial allowed interaction between the hacker and the system.

There are a few extraordinary circumstances surrounding this case that are unusual for cybercrime/breach issues that have really piqued my interest:

• A suspect is already in custody. Typically, many of these large breaches can only postulate with a certain degree of certainty who the bad actor was. In this case, they have charged someone with a crime, and in fast action. This appears to have been possible because of public boasting by the bad actor. This is strange for a couple of reasons, (1) bad people don’t like to get caught and that would be a dumb move and (2) why use a TOR node to exploit the environment if you were going to publically boast about it anyways?
• The suspect is from the United States and the motive seems unclear. Many breaches that we are accustomed to hearing about in the news have foreign based actors and different motives behind the attacks. This attack appears to have occurred from a bad actor within our borders and there doesn’t appear to be any disclosure of the data as the Capital One press release notes, “we believe it is unlikely that the information was used for fraud or disseminated by this individual.” Perhaps the quick action of law enforcement preempted a disclosure of this data.
• It appears somewhat likely that the bad actor may have exploited commercial infrastructure that she had helped to build. Follow along for a moment. The US attorney complaint notes that information posted on a GitLab page had them believe the bad actor worked for a cloud computing company at one point as a “systems engineer” from 2015-2016. However, the complaint does not name who the former employer was. A quick search for “Paige Thompson” on GitLab produces a resume for a woman named Paige Thompson that notes that she worked at AWS from 2015-2016 as a “Systems Engineer Lvl. 4” for Amazon AWS S3 division. Her experience notes that she “Assisted in the build-out and deployment of new load balancing capacity for S3.”

While there is undoubtedly much more to come on this event, the initial details are very interesting. From a business standpoint, there are many lessons learned that can be gleaned from this event. Regular security audits and penetration tests of all assets, including cloud infrastructure, is a highly recommended and valuable exercise that can bring serious issues that can lead to events like these to light. In addition to security audits and penetration tests, there were several missed signs of bad activity that should have been logged, recognized and alerted on. For example, the complaint mentions the following bad activity found in the logs, VPN connection from IPredator anonymization service, TOR exit node connections, and anomalous behavior from seldom used accounts. Be sure to learn from others’ mistakes to strengthen your own environment and help avoid issues like this.

Tips like these and others are mentioned in a recent white paper that I authored with along with our Incident Response Leader, David Murphy, which is available here: https://schneiderdowns.com/10-things-companies-wish-they-did-before-a-breach