DAST
Continuously monitor web applications for vulnerabilities at scale with Cobalt Dynamic Application Security Testing (DAST).
DAST
Continuously monitor web applications for vulnerabilities at scale with Cobalt Dynamic Application Security Testing (DAST).

Understanding the Anatomy of an Attack

Lessons Learned from the Capital One Breach

Notable, high-impact security breaches sadly make regular headlines. You might be tempted to dismiss the latest as just another case of insufficient security, process breakdown, attacker persistence or even bad luck. But we believe that when a breach occurs it is important to review in-depth what happened, how it happened and what could have been done to prevent it or mitigate it more effectively.

We hope you will find our threat briefing of the Capital One breach as an opportunity to learn and improve from a detailed understanding of how Capital One became vulnerable and how the attacker exploited this vulnerability.

Key takeaways include:

  • The anatomy of an attack

  • How the Capital One attack occurred

  • What Cobalt learned from the attack

  • How individuals can protect themselves if their data was exposed.

How exactly do we define a breach?

If you look up the word “breach” in the dictionary, you will find definitions for both nouns and verbs. A breach can be a break of trust, a violation or infringement. It can also be a physical gap or rupture, particularly in a line of defense, or the act of making that gap. In the information security space, there are a variety of breaches and we tend to think of them in terms of both a gap in a line of defense and break of trust.

Traditional network security breaches typically involve private data being stolen from a corporate network. One example is the hack on Sony Pictures in the fall of 2014. Attackers broke into Sony Pictures’ private network and stole large amounts of confidential documents, then made them public on the Internet in the following weeks. In this instance, the breach started on the Sony Pictures corporate network.

Now companies store data in the cloud, often relying on public cloud infrastructures. When you hear about current breaches, sometimes they involve the theft of information via a cloud infrastructure. Most often, they are the result of human error and not the inherent insecurity of the cloud. In either case, the risks apply to large and small companies alike. According to Verizon’s 2019 Data Breach Report, 43 percent of breaches, the largest cohort measured, involved small business victims. Even worse, 60 percent of small businesses that suffer a breach go out of business in the next six months. Small businesses have less security in place, fewer resources to manage it and less ability to recover. Knowledge of how attackers probe for vulnerabilities, how they attack and how they exfiltrate data can help companies of any size strengthen their traditional and cloud infrastructure.

What is the anatomy of an attack?

Information security maintains many parallels with physical or military security, just as the word “breach” can refer to a cyber theft and a physical rupture of a security barrier. As we study the anatomy of an attack, it’s helpful to use military terminology. For example, a military attack sometimes involves the reconnaissance phase, the attack phase, the exfiltration phase and the exit.

A cyberattack follows a similar pattern.

1. Reconnaissance — What’s the best way to pull off the attack?

In the military sense, this involves exploring an area to gather information about natural features, defenses in place, etc. From a security standpoint, attackers conduct cyber reconnaissance of a target’s network and assets. To find information about assets they use tools such as:

  • Shodan — a search engine that includes metadata from hosts on the Internet.

  • Google Dorks —not a tool, but the use of advanced search string such as, “CEO” “email” “@” “Name” “Phone” filetype:csv OR filetype:xls to find sensitive data.

  • The Harvester — can be used in Kali Linux to gather email accounts, usernames, subdomains from search engines and PGP key servers.

  • Recon-ng — an automated tool with lots of modules that can assist in identifying hosts, databases, etc.

To probe for vulnerabilities, attackers can rely on

  • Nessus — an open-source and commercial vulnerability management tool.

  • Netsparker — a commercial web application scanner.

  • OpenVAS — an open-source framework for vulnerability scanning and vulnerability management.

2. Attack — Based on intelligence gathered from recon activity, attack with the strategy that has the highest probability for success.

In a cyber breach, we tend to break the attack into four phases, including infiltration, maneuvering, exfiltration and establishing persistence.

Infiltration occurs when the attacker gains access needed to achieve the goal. This is commonly accomplished via:

  • Spear phishing an administrator to gain credentials

  • Elevating privileges if they’re not at the level required to complete the attack

  • Delivering malware to hide access, processes and logs that are part of the attack

Maneuvering can now take place. The attacker can move through the network or resources to identify valuable data. This includes:

  • Enumerating Amazon Web Services (AWS) like S3. This can go on for months undetected

  • Looking through data sources

  • Identifying other strategic targets for further compromise

The attack phase now moves into exfiltration, the actual removal or theft of information assets. During this phase:

  • Valuable data is typically consolidated and compressed or zipped

  • Data is sent to a bad actor-controlled server or data source that is available on the Internet

  • Copies can be throttled to prevent bandwidth alarms from alerting

The attacker’s final effort is to establish persistent access to the target’s data assets. The goals of establishing persistence include:

  • Protection against their compromised systems being reimaged; preventing them for future exploitation

  • Installing backdoor/remote connection malware on a large number of systems to ensure they can get back into the network

A timeline of the Capital One breach

To understand what happened during the Capital One breach, it’s best to start in the middle and work backwards. On July 17, 2019, Capital One received an email to the Responsible Disclosure inbox claiming its internal data had been posted to GitHub. Two days later, an investigation was launched and the breach was confirmed. Capital One announced the breach 10 days later, probably taking the time between confirmation and announcement to confer with executives, PR, sales and marketing.

The initial breach occurred on March 22, 2019, nearly four months before Capital One had any indication. The attacker had access to the network for nearly a month before deciding to pull data off Capital One’s cloud infrastructure.

Timeline_of_Capital_One_Breach-1

How did the attacker do it?

Capital One was using a vendor-supplied web application firewall (WAF). Unfortunately, it was misconfigured and it allowed access to specific commands that could be run on a vulnerable web application in AWS. If this sounds familiar, it should, because this scenario is typically examined and highlighted in a pentest.

The attacker was able to use a server-side request forgery (SSRF) and escalated to remote code execution (RCE) attack on the vulnerable public web app because the WAF was misconfigured. The attacker thus gained access to everything that web application had access to, which turned out to be a lot of customer data.

Understanding_the_Anatomy_of_an_Attack-3

Typically access is controlled in application logic. For example, you may have access to a database, but you’re only going to query a certain number of tables and rows based on application logic. However, the permissions are still there to be exploited. In this case, the attacker took advantage to further compromise Capital One’s cloud infrastructure.

Escalation of privileges

Once an attacker gains access to the network, they typically look for ways to escalate privileges and this attacker followed the same pattern. The attacker used an AWS API which allowed them to request temporary roles or credentials and further increase the amount of access that the application had. From there, the attacker downloaded a Web shell onto the compromised system and assigned Identity and Access Management (IAM) administrator access.

Escalation_of_Privileges_in_AWS-1

The graphic above depicts how this might unfold in an AWS environment, but the same thing can occur in Azure and Google Cloud Platform (GCP). Let’s say a developer has an account and makes a request through an API to temporarily gain access to credentials that he doesn’t have right now. AWS will return and fulfill the request right away assuming that a policy exists. If an attacker uses the same scenario, they now have a higher level of privileges than they started with and can use them to access things like S3, EC2 (Elastic Compute Cloud) and other platform services. This is not a new technique. In 2018, Google paid a $36,000 bug bounty for a single vulnerability that led to remote code execution through server side request forgery in the Google App Engine.

Enumerating services

The attacker now as elevated privileges and is starting to enumerate services. Since it is an AWS environment, Capital One data is likely stored in tens of thousands of S3 buckets. The Capital One attacker enumerated all S3 buckets looking for sensitive information. On the data administrator side, it’s helpful to apply descriptive labels to S3 buckets, such as “customer data,” or “public data” so people with rightful access can locate it more easily. Unfortunately, this also makes it easier for the attacker to identify valuable and sensitive data. Sometimes things that save rightful users time and effort also provide the same benefits to attackers, who are racing against time before they are detected.

Exfiltrating the data

So what was actually taken from Capital One in this breach? The impact of the attack was enormous. 100 million U.S. individuals and 6 million Canadians were impacted by the theft of:

  • 140,000 social security numbers

  • 80,000 linked bank account numbers of secured credit card customers

  • Name, address, phone number, DOB, income and credit score records from consumer and small business card applications submitted between 2005 and 2019

This data can be purchased by criminals to commit identity theft and fraud, and is all that is required to prove your identity with all major banks, the IRS and utilities when not in person. Tax fraud is actually the most prevalent form of fraud based on identify theft. With an individual’s data from the Capital One breach, someone could file a fraudulent tax return and take the tax refund from the proper recipient.

Most_Prevalent_Forms_of_ID_Theft-1

Who is the attacker?

The attacker was Paige Thompson, who had previously worked for AWS. No insider information was used or necessary to complete this attack. Thompson uses the hacker handle, “Erratic.” She had no financial motivation and there is no indication she tried to monetize the data. Thompson posted on Slack as herself and said she had the data. She also shared the data on GitHub as herself on her personal account, and tweeted about it. It’s extremely rare to see a person own up to the breach and publicly share it from personal accounts. The normal result is that unknown bad actors move quickly to sell the data on the dark web for profit.

What can Cobalt learn from the breach?

The first inclination may be to suspect AWS of security lapse. But the Capital One breach was 100 percent not the fault of AWS. When it comes to security, there is a shared responsibility model in the cloud between cloud infrastructure providers and customers. When you have any type of workloads in the cloud, AWS, Azure and GCP will secure the infrastructure portion, while cloud customers must also do their part to configure and run services and the cloud platform securely.

What was the root cause?

Misconfiguration is at the root of the Capital One breach. This is a common, widespread problem. According to the Cobalt's State of Pentesting Report, nearly two thirds of all pentesting findings are attributed to misconfiguration. Had the Capital One web application firewall been properly configured, it may not have allowed attack traffic to be sent to the vulnerable web application. If Capital One had been fully pentested, the vulnerability may have been found prior to being exploited, and possibly been made resilient to the attack.

What about the escalation of privileges?

We saw that once the attacker gained access to Capital One, she immediately moved to escalate her privileges. To prevent this from happening, implement a cloud log analyzer. AWS has CloudTrail and the other cloud providers offer something similar.

With CloudTrail, you can log, continuously monitor and retain account activity related to actions across your AWS infrastructure. AWS CloudTrail increases visibility into your user and resource activity by recording AWS management console actions and API calls. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred.

With proper monitoring, CloudTrail can detect and generate events when someone enumerates all S3 buckets, when someone is watching the network and when IAM changes take place.

What can Cobalt do to help improve security in the wake of the breach?

We maintain that proactive pentesting, vulnerability assessment and proper monitoring are critical to preventing this type of attack. The anatomy of the Capital One attack aligns with the statistics — most attacks take advantage of existing vulnerabilities and misconfiguration.

Internal pentests should already be a part of your process and framework. If you find issues during an internal pentest, fix them right away. External pentests are also beneficial since fresh eyes with no internal pressures can identify issues that might be harder for internal resources. Pentests should be customized for your business and applications for the best results.

Monitoring is also a must. This is difficult for most companies, especially large organizations with millions of events. Alert fatigue sets in quickly when trying to track and analyze massive quantities of events. However, if Capital One had the proper monitoring in place in March 2019, it’s possible that they would have been alerted to the attacker’s escalations before the data could be exfiltrated.

What can Individuals do to protect themselves?

If you were affected by the Capital one breach — because you have a Capital One credit card or submitted an application over the past 15 years — Capital One is offering free credit monitoring. This can be a helpful service if you do not monitor your credit vigilantly.

We also suggest that U.S. citizens freeze their credit when they don’t need to access it. For example, if you’re not in the market for a new car, or a loan, or buying or refinancing a house, freeze your credit so no one can access it. At the same time, you can sign up to receive free credit reports more frequently. If your data has been exposed, we suggest you review the reports carefully for any suspicious or fraudulent activity. Place a fraud alert with the credit agencies and the bank if you see strange activity.

This process has become much easier over the past 15 years as data breaches and identity theft have unfortunately become common. The banks and credit agencies have more streamlined, customer-friendly processes in place. It’s also wise to have a backup of your credit card numbers and account numbers so that if any cards or accounts go missing, you can report it quickly.

Conclusion

At Cobalt, we see our customers and pentesters as a large and talented extension of our security team, as part of a humming human IDS that can identify attacks and take proper action. Driving education is an important aspect of Cobalt’s security awareness strategy. We strive to keep our community informed and educated about potential threats and vulnerabilities. The Capital One breach has much to teach us about how even a relatively basic misconfiguration and vulnerability can lead to privilege escalation and enormous compromise. We remain humble yet hyper-focused in our efforts to keep identifying misconfigurations and vulnerabilities before the bad guys do.

Back to Blog
About Caroline Wong
Caroline Wong is an infosec community advocate who has authored two cybersecurity books including Security Metrics: A Beginner’s Guide and The PtaaS Book. When she isn’t hosting the Humans of Infosec podcast, speaking at dozens of infosec conferences each year, working on her LinkedIn Learning coursework, and of course evangelizing Pentesting as a Service for the masses or pushing for more women in tech, Caroline focuses on her role as Chief Strategy Officer at Cobalt, a fully remote cybersecurity company with a mission to modernize traditional pentesting via a SaaS platform coupled with an exclusive community of vetted, highly skilled testers. More By Caroline Wong