By now you’ve heard of the Capital One Data Breach that happened on July 29, 2019, where a hacker gained access to 100 million Capital One credit card applications and accounts. Read more about the thoughts from Cybriant’s Chief Technology Officer, Andrew Hamilton.
My first reaction when I saw that the Capital One data breach has been the same as many of you: someone misconfigured something and a former employee knew that misconfiguration.
What we most commonly see as a security company when organizations move to the cloud is the expectation that the cloud provider (AWS, Azure, Google) will automatically understand and take into account any security threat vector which may be particular to an organization.
Unfortunately, they can’t work in that manner because requirements and environments will always differ from one organization to the next. What may be a potential threat vector to Capital One could be required functionality to another organization.
And so, the cloud providers afford their customers a high degree of flexibility, but they state in their Terms of Service (and recommendations) that the customer is responsible for securing their tenant.
Similarly, when we monitor a customer’s environment one of the first things we check for is whether we see customer endpoint devices utilizing external DNS servers instead of the official internal company DNS servers.
Malware loves to exfiltrate data via DNS because most of the time UDP/TCP 53 is wide open to the Internet. And while there are certainly ways to exfiltrate data via valid CNAME and TXT records (which require additional techniques to monitor/block such as RPZ records) those are computationally less efficient than simply blasting data via a commonly trusted port DNS port and bypassing HTTPS SSL inspection.
There was an excellent article at InfoSecurity Magazine yesterday on the top 5 penetration test discoveries (link: https://www.infosecurity-magazine.com/news/95-test-problems/).
All five boil down to good Systems Administration hygiene. They aren’t as “sexy” as buying a Palo Alto and bragging about it to friends, but instead are things that are often left by the wayside (requiring complex passwords, simple patch management, etc).
What can be even more puzzling is when we see organizations who want a VERY expensive penetration test, and yet they haven’t even begun resolving the issues found from their vulnerability scanner. Unfortunately, this is the norm that we see across industries and company sizes.
To avoid a Capital Bank data breach at your organization, read to the end to see our recommendations.
Related: Top Cyber Security Websites
Capital One Data Breach Facts
On July 29th, 2019 Capital One Financial Corporation, a US-based bank holding company specializing in banking, credit cards, loans, and savings, today released a statement1 regarding the detection of a breach resulting in unauthorized access to personal data about over 100 million Canadian and US credit card applicants and customers.
- The breach is believed to be one of the largest in the history of the banking industry;
- According to the statement, Capital One does not believe the compromised data has been used fraudulently;
- Capital One became aware of the breach following a responsible disclosure email alerting them to potentially leaked data on a GitHub account associated with the alleged threat actor (TA);
- The breach reportedly exploited a configuration vulnerability in Capital One’s infrastructure, including at least one known firewall misconfiguration, permitting access to customer data stored on Amazon Web Services (AWS) cloud;
- US Law Enforcement arrested an alleged TA, ‘Paige Adele Thompson’, a former Amazon Inc. employed S3 Systems Engineer2, also known as ‘Erratic’, in Seattle, WA (US) on suspicion of ‘Computer Fraud and Abuse’ as filed3 in a criminal complaint with the US District Court for the Western District of Washington at Seattle;
- The hack is expected to cost the company up to $150 million in the near term, including paying for credit monitoring for affected customers.
Scope of breach
- Personal data of more than 100 million US and 6 million Canadian customers (consumers and small businesses) including approximately: o 140,000 US Social Security numbers
- 1 million Canadian Social Insurance Numbers (SIN);
- 80,000 US bank account details;
- Names, addresses, phone numbers & dates of birth;
- Self-reported income;
- Credit scores, limits, balances & payment history.
- Stolen information about credit card applications from 2005 through 2019.
Capital One Data Breach Timeline
- 12 March – 17 July 2019 – Period in which unauthorized access to Capital One’s infrastructure likely occurred;
- 22 March 2019 – Capital One access logs confirm unauthorized access to AWS from a compromised account;
- 21 April 2019 – Timestamp associated with leaked data hosted on GitHub in addition to unauthorized activity recorded by Capital One logs;
- 26 June 2019 – Posts on a Slack channel associated with, and using an alias of, the TA include screenshots and directory listings of files belonging to Capital One and other potential victims;
- 17 July 2019 – Responsible disclosure email received by Capital One, alerting them to ‘leaked s3 data’ hosted on a GitHub Gist account believed associated with the threat actor;
- 18 July 2019 – Direct messages posted by the TA suggest that they were prepared to distribute the stolen data;
- 29 July 2019 – US FBI agents arrested the TA and Capital One release a public statement about the breach (also establishing a dedicated data breach webpage4 with an FAQ for potentially affected customers).
- Organizations using cloud-based services, such as Amazon S3, should ensure that assets are correctly configured to prevent inadvertent or unauthorized access to sensitive data. Cloud providers will provide documentation detailing identity and access policy configurations that can restrict access, be that by the user, file, bucket, or organization.
- Patch Management is a vital service that is often overlooked or taken for granted. Cybriant offers a Responsive Patch Management service that will take the guesswork out of the administrivia of this task and maintain a healthy network.
- Vulnerability scans may catch the majority of issues, but these need to be done continuously. If you are only scanning once a year or quarter, that leaves a long period for hackers to use those vulnerabilities for malicious purposes. The alerts that come from the scans need to be remedied. Our Risk-Based Vulnerability Management service will aid your team to identify vulnerabilities to protect your network.
- Logging any incidents in your network is the best way to protect against advanced persistent threats, including insider threats. Our Managed SIEM with 24×7 Security Monitoring service is not only a potential compliance requirement but will address and resolve the most complex cyber risk issues.