Go Back

Capital One Breach: What we know and what you can do

July 31, 2019
Capital One Breach: What we know and what you can do

Monday blues. It’s a thing. It’s when you start the week feeling moody because your weekend is over. The feeling typically subsides once you’re in the office. You may usually begin the day by planning for the week ahead. But picture this – you’re Monday doesn’t start as it should because you’re one of the 106m people whose data has been stolen in the Capital One data breach. Monday blues just got darker.   

Monday, July 19, 2019, Capital One announced that it had determined “there was unauthorized access by an outside individual who obtained certain types of personal information relating to” its’ customers. That compromised data included names, addresses, and phone numbers, self-reported income, credit scores, and payment history, among other personal information belonging to approximately 100 million customers in the United States and 6 million customers in Canada. Working with federal law enforcement, Capital One highlighted that the attacker, a software engineer and former Amazon employee, has been arrested.

Here at Digital Shadows, we have been closely following the indictment and associated media coverage. Using the Mitre ATT&CK and PRE-ATT&CK framework, Digital Shadows identified what we know, and some practical steps to help avoid a similar situation.

 

What we know

On 17th July 2019, Capital One received an email to their responsible disclosure inbox claiming that Capital One internal data had been posted to Github. When Capital One investigated, they discovered a file timestamped 21st April 2019, which contained the IP address of one of the Capital One cloud instances. On investigation, they found that an attacker had compromised their cloud environment and exfiltrated data from it.

Here is a breakdown of the steps the attacker took:

Initial Access: T1190 Exploit Public-Facing Application, T1133 External Remote Services

Execution: T1059 Command-Line Interface

 

According to the indictment, “A firewall misconfiguration permitted commands to reach and be executed by that server”. We do not know exactly what the misconfiguration the attacker used to compromise the instance but there are some possibilities:

  1. A vulnerable web application was exploited which was inadvertently exposed to the internet
  2. A remote access service was inadvertently exposed to the internet with no or weak credentials

Mitigation: In a cloud environment, where instances or containers can be spun up rapidly, it’s important to continuously assess the environment for security issues, especially external access from the public Internet. Periodically reviewing Security Group configuration can also help to ensure that services are not inadvertently exposed and controlled access is applied correctly.

 

Credential Access: T1098 Account Manipulation*

(* note, best fit as there is no direct cloud version)

Once in, the attacker gained unauthorized access to temporary role credentials. The indictment states that three commands were retrieved from the Github file, which was used for the post-exploitation activities. The first command caused temporary credentials to be generated.

Mitigation: Identity Access Management (IAM) roles use temporary credentials created when an authorized entity (user or application) requires access to an AWS service. However, Role Access monitoring is challenging in complex environments and needs significant effort to make it work effectively.

 

Discovery: T1007 System Service Discovery

The second post-exploitation command was to list the Amazon S3 buckets that the identity the attacker assumed had access to. 

Mitigation: Cloudtrail logging can help an organization track this type of activity, but real-time alerting is an issue.

 

Exfiltration: T1048 Exfiltration Over Alternative Protocol

The third post-exploitation command was to sync the S3 bucket contents with an attacker-controlled server. This command relied on the access which the assumed identity had, and gave the attacker access to over 700 buckets, according to the indictment.

Mitigation: As with the previous issue, Cloudtrail logging can help an organization track this type of activity, but real-time alerting is an issue.

 

PRE-ATT&CK Establish and Maintain infrastructure

T1329 Acquire and/or use 3rd party infrastructure services

The indictment states that the attacker used a combination of Tor and IPredator (a paid VPN provider) to hide her identity when attacking the Capital One cloud environment.

Mitigation: if possible, whitelisting access to resources from a set of known-good IP addresses can help prevent unauthorized access. IP whitelisting can only be applied in environments where it is known where authorized users will be accessing an environment from and should only be used in conjunction with other, strong authentication mechanisms.

 

What we don’t know

The “insider” angle has been played up in the media as the attacker worked for Amazon. The indictment, however, does not imply that the attacker had any privileged access based on her previous employment. It appears instead that they used their knowledge and experience from their previous roles to attack the Capital One environment, exploiting a vulnerability in the misconfigured firewall.  

The motives of the attacker remain unconfirmed. Although data breaches conducted against banks are typically financially motivated, the attacker publicized the hack and stolen data and is a member of a hacking club. It is, therefore, possible that the hack was conducted for personal motives – though the details are yet to unfold.

 

GDPR point of view

According to Capital One, no EU accounts were exposed, so that means no GDPR fines will be applied. This indicates that the company is GDPR compliant, but obviously, personal data was not adequately protected. This raises another concern about how and what security measures GDPR demands from the companies. We all know that this is not sufficiently covered, and data protection measures are left open to everyone’s interpretation in the referenced GDPR article. Of course, being compliant does not mean being secure, and this needs to be communicated to every organization.

 

To stay up to date with the latest security research and news, subscribe to our email list below.