Understanding cybersecurity at multiple levels: A Capital One analysis

TL;DR

The Capital One breach wasn’t caused by a single error but a cascade of security failures across multiple layers. This blog breaks down the attack using the Cyber Kill Chain and offers practical steps to avoid similar incidents.

Data breaches come in all shapes and sizes. There are plenty of entry points for attackers to gain access to platforms and wreak havoc, from downloading malware via email to exposing API keys on internal messaging systems. But cybersecurity isn’t just about preventing entry points. Protecting proprietary information and infrastructure requires a multi-level approach to security with vigilance at every level. No organization is immune to attacks, even those considered industry leaders in security.

In 2019, a data breach at Capital One made headlines when an attacker exposed the credit card application information of 106 million people in the US and Canada. Immediately, cybersecurity researchers, Capital One’s security team, the US government, and Amazon Web Services (Capital One’s web host) began looking for answers. Thankfully, the hacker was caught before the stolen information could be spread, but the question remained - what happened?

Though the widely publicized entry vulnerability was dismissed as little more than a misconfigured firewall, the systemic issues of Capital One’s security infrastructure paved the way for the extended attack chain. According to a report published in the Association for Computing Machinery’s digital library, “The technical details of the Capital One data breach reveal that multiple safety/security constraints were violated that enabled the attack to be successful.” (Section 4.1) One misconfigured firewall alone didn’t grant permission for the exfiltration of 700 bins of application data.

Let’s take a deeper look at what happened, potential solutions, and why cybersecurity must act on multiple layers to be successful.

Understanding the breach with the Cyber Kill Chain

The report assesses the incident using the Cyber Kill Chain (CKC) framework introduced by Lockheed Martin to investigate cyberattacks from the adversary’s perspective. This chain consists of seven phases associated with steps typically taken by an adversary in launching an attack:

• Reconnaissance: Locating a vulnerability, acquiring stolen credentials, and more.
• Weaponization: Using reconnaissance information to generate a deliverable payload.
• Delivery: Delivering weaponized bundle via email, web application, USB, or other method.
• Exploitation: exploiting a vulnerability to execute the deliverable on the target’s system.
• Installation: Installing malware on the target asset.
• Command and Control: Establish a command channel for remote manipulation of the target.
• Actions on Objectives: The intruder accomplishes the goal (e.g., exfiltration of data).

The reconnaissance and weaponization phases of this chain are beyond Capital One's control, and as such, were not relevant to the researchers conducting this report. Instead, they focus on how the other phases of the attack highlight security vulnerabilities easily exploited by the threat actor.

CKC delivery phase

The delivery phase of the CKC refers to a threat actor’s ability to deliver malicious requests to internal systems. In the Capital One breach, the attacker disguised malicious requests to appear as normal traffic, successfully bypassing defenses.

The core vulnerability exploited here was Server-Side Request Forgery (SSRF), an attack that tricks internal servers into requesting restricted resources. SSRF allows attackers to bypass external security controls and directly interact with internal systems.

This particular SSRF vulnerability had been publicly documented years before the breach, but remained unpatched in Capital One’s environment at the time.

The researchers identify two critical system-level constraints that allowed the delivery of the exploit:

• The system lacked safeguards against SSRF attacks and similar exploits, such as reverse proxy abuse.
• Insufficient intrusion detection and monitoring prevented the security team from noticing the malicious requests, including unauthorized IAM API calls made by the attacker.

Both failures were independent of the firewall misconfiguration initially blamed for the breach. Addressing either of them could have stopped the attack or at least triggered an early warning before sensitive data was stolen.

CKC exploitation phase

The system-level constraint violated by Capital One is the decision to operate the system with an exploitable vulnerability (misconfigured firewall) in place. A correctly configured firewall prevents the attack in the first place. Steps to remedy this issue might include double-checking configurations, automatic misconfiguration detection systems, or further IT training.

CKC command and control phase

The command and control phase of the CKC refers to the abuse of the organization's internal permission systems, which researchers also found to have multiple violations.

• The hacked server had unnecessarily excessive permissions for its function, giving the hacker read and write permission to resources the server did not require. Additionally, the server had role permissions to decrypt the data, allowing it to access and decrypt credit card application data by itself, without verification. This access control violates the principle of least privilege.
• The system additionally does not prevent unauthorized users from accessing credentials and establishing control over resources. The authentication process automatically trusted the API call from the compromised server.

These vulnerabilities are security oversights. The overpermissioned server and lack of security around internal, trusted credentials imply that the security team did not expect a hacker to access this deep into internal systems.

CKC action on the objectives phase

The hazard in the action on objectives phase of the CKC is relatively straightforward in this breach. The system did not adequately encrypt its data. The hacker was able to decrypt the stolen data using the decryption key from the same stolen credentials they used to access the data in the first place.

Security at multiple levels

While a misconfigured firewall granted the external threat actor the ability to deliver a known exploitation, it’s clear from a brief analysis of the cyber kill chain that multiple security vulnerabilities were exploited to enter the system, remain within the system, exfiltrate the data, and decrypt the data.

These are only the security vulnerabilities that appear at the system level, meaning they were latent within the design and configuration of software and hardware at the time of the breach. Yet security doesn’t start with software or hardware. It’s much, much larger.

The Capital One breach also highlights a critical aspect of cloud security known as the shared responsibility model. While AWS was responsible for securing the physical infrastructure and core services, Capital One retained full responsibility for properly configuring its firewalls, application-level security, and identity access controls. In this case, the root cause was firmly on Capital One’s side of the shared responsibility line.

Operational chain of command

System-level vulnerabilities are the focus of most cybersecurity investigations, especially when specific unsecured platform architecture allows external threat actors to access proprietary information. Yet correcting that system-level vulnerability does not represent a proactive approach to security, nor does it identify the larger issues in the operational chain of command.

The following image from the research article, A Systematic Analysis of the Capital One Data Breach: Critical Lessons Learned, is a functional control diagram of Capital One’s security posture before the breach. Each red and blue arrow pair marks a feedback loop, with the red arrow representing a controlling decision and the blue arrow representing a feedback report.

The system-level security vulnerabilities covered in the cyber kill chain are contained entirely within the bottom section, labeled (1) and (2), and titled Amazon-hosted Banking Back-end System. Yet there are nine levels of shared responsibility contributing to the resource provisioning and design of this system, from federal agencies and regulators to the web application firewall itself.

The first and second levels of shared responsibility are directly related to platform architecture. The rest of the levels refer to the various teams and roles responsible for resource provisioning and directing. In level (6), the CTO, on direction from the CEO, assigns strategy and priority to the Information Technology team at level (4). That direction is implemented by DevOps and the IAM team to ensure identity access management systems are adequately secure.

Failures at different links in the chain

The researchers found chain of command failures at each level of the diagram, and if you’re interested in a more in-depth explanation of them, I recommend checking out the full study here. I’ve highlighted some I found interesting below:

In section 4.2.4 of the report, the researchers point out a potential process model flaw they believe contributed to the weakened architecture of Capital One’s platform; there is no direct communication channel between the board and the CISO. This resulted in the board forming an inadequate model of the risk exposure, leading to ineffective direction. The researchers also point out that “the lack of presence of CISO at the executive level has remained a common theme in the majority of companies that have experienced a significant breach.” (section 4.2.4)

Down the chain at levels (3) and (4), the Information Technology team is shown as separate from the Information Security team. The IT team functions as the system architect, performs system maintenance, and contains both the DevOps and the IAM teams. The DevOps team did not adequately implement a secure architecture, since a single vulnerability could lead to the failure of the entire chain. The IAM team also failed to assign the correct level of permissions to the server behind the compromised firewall, resulting in the inadequate encryption practices mentioned above. These oversights imply either a breakdown in the communication channels between IT and InfoSec, or they imply a failure on the part of these teams to implement the information InfoSec should have been sending to IT about the inadequate platform architecture. (Section 4.2.2.1)

Beyond technical lessons, the Capital One breach had significant financial and legal repercussions. US regulators fined the company 80 million dollars and faced multiple lawsuits from affected customers. The incident also damaged its reputation, serving as a cautionary tale about the risks of mismanaged cloud security.

Incidents like this are often viewed as isolated failures, but they reveal a broader need for stronger prevention strategies in both technology and leadership.

Proactive security

While it is important to understand what went wrong in the Capital One breach, it is just as important to ask this question: What does effective, proactive security look like before a breach happens?

Preventing multi-layered attacks takes more than patching known vulnerabilities or fixing misconfigurations. It requires a security model that can detect issues early, limit their impact, and keep failures from spreading across systems and teams.

Here are a few key practices that help organizations build stronger defenses before an incident occurs:

• Regular risk assessments: Map out how internal systems, teams, and third-party services interact. Identify weak points where security gaps or communication breakdowns could introduce risk.
• Automated monitoring with human review: Use automated tools to flag suspicious activity, but make sure trained analysts are reviewing alerts and investigating unusual behavior.
• Cross-team incident response drills: Run security exercises that include engineering, legal, IT, and leadership teams. These drills help teams clarify roles and improve coordination during a real incident.
• Executive-level involvement in security: Security leaders should have a direct line of communication with the board and executive leadership. Security needs to be treated as a business priority, not just a technical issue.

Every organization’s risks differ, but these practices can reduce the chances that a single oversight will lead to a major breach.

Rethinking security: Lessons beyond the breach

In a post-accident investigation, organizations often look to identify the root cause of the incident itself. Their focus on what went wrong tends to hinder the organization’s ability to determine why it went wrong. Regardless of intention, the outcome of such an investigation is the identification of an error made by a lone operator or an unexpected failure of a single piece of technology. Their subsequent conclusions focus on improving operator training or enhancing technological reliability without questioning the design of the system itself.

Capital One’s breach makes one thing clear: cybersecurity is not just a technical problem. It’s an organizational one.

Whether you’re running a fintech startup or a large enterprise, here are key lessons:

• Audit and limit permissions regularly. Least privilege is essential.
• Monitor for unusual activity, especially in cloud environments.
• Patch known vulnerabilities quickly, even those that seem minor.
• Clarify cloud responsibilities to avoid assumptions about coverage.
• Ensure security leaders have a direct voice at the executive level.

Security is not simply a firewall configuration or a DevOps task. It must be embedded into every layer of an organization’s strategy and decision-making.

Strengthen your security posture with better secrets management. Doppler delivers audit logs, fine-grained access controls, automatic secret rotation, and more, so your organization stays secure and compliant. Get a free demo today.