When Tools Work but Systems Fail: Lessons from the Capital One Breach

Prof. Duke, in Saturday’s lecture, touched on an adage: the right tool for the right job. However, breaches rarely center on the presence or absence of tools, but on whether those tools are aligned with how attacks unfold across complex systems.  Something, often mentioned in Blue Team circles is defense is response, after the fact, a posteriori.  In other words, defense only occurs after knowledge of the attack, what the attack did, how the attack was executed, and the attacker maintained their presence, escalated privilege, and exfiltrated their prize.  Studying the Capital One data breach of 2019, Khan et al., summarize Blue Team’s reactionary position as follows, “incorrect/inadequate decisions at higher levels of the system, based on incorrect beliefs or assumptions about the system or environment, create systemic conditions that may take years to manifest but ultimately result in losses as a result of seeing insufficient trigger-events.” (Khan 3).

Tools rest at the juncture of the decisions, the knowledge, a priori, of what is known beforehand, and the trigger events, of what is seen at the time of attack.  Tools are built with yesterday’s knowledge, yesterday’s CVEs.   Even continuous monitoring, or AI imbued systems, look for the patterns of yesterday.  Our current cloud assessment tools and vulnerability scanning tools scan components, not systems.  The component view of assessment tools misses IAM control planes and the gaps between IAM and other components.  Assessment tools are invasive, often network and CPU expensive, disruptive to operation of a system, and weren’t designed for continuous operation.  So, we get snapshots of component/system behavior.  Our snapshots are daily, weekly, monthly, and the time between these snapshots and analysis are gaps in our knowledge and in our defenses.The Capital One data breach represents not a novel, new attack vector but an exploit of the gaps within a complex system.  The attacker, Paige Thompson, used VPN and TOR services to anonymize her requests to a web application, bypassing a misconfigured application firewall.  The firewall was running ModScecurity (ModeSec) a common open-source web application firewall to gate traffic against a set of firewall rules.  Once passed the firewall, Ms. Thompson utilized a Server-Side Request Forgery (SSRF) vulnerability manipulating requests to the web application making her requests appear to come from a VM instance, in this case from Amazon’s Elastic Compute Cloud (EC2), the type of VMs rented by Capital One from Amazon.  Because of missing rules in ModSecurity, the attacker could send a request that caused the EC2 instance to make internal network calls (SSRF).  She looked like a virtual machine, not someone outside the system.  Amazon manages the server which ran the EC2 VMs, but Capital One owned responsibility for defining its IAM roles.  Capital One over-privileged the EC2 VMs at launch.  So, now inside the system, the attacker inherited the existing privileges.  The attacker did not get user credentials; she got machine credentials and now had access to secure data.  No more hacking needed.  The attack sat on the system for four months and was only detected because the attacker posted details of the breach publicly.Capital One did not suffer a tooling failure. It suffered a trust failure built into architecture.  Here the tools, the WAF and the IAM governance operated as implemented.  Also, vulnerability scanning tools protect only the layers they are deployed to scan.  This attack happened across layers, in the gaps between layers, where vulnerability scanners aren’t looking or monitoring.  WAF monitors traffic and blocks suspicious patterns, it doesn’t manage IAM trust relationships.  As soon as the attacker acted like an EC2 VM to the system, the breach moved immediately into cloud identity security, which is outside its WAF visibility.  Vulnerability scanners operate from CVEs and check open ports, look for outdated software and exposed services.  Vulnerability scanners do not set IAM privilege models or check cross-service trust chains.  Khan et al., point to the shared security model between Capital One and Amazon (Kahn 22). AWS was responsible for securing the physical data centers, hardware and networking, the virtualization layer (hypervisors), and the availability of core cloud services.  Capital One was responsible for, EC2 instance configuration, operating systems & patching, web application security (WAF rules), IAM roles and permissions, encryption, etc.  No tools AWS was running on their cloud services would protect Capital One from its governance and security architectural failures.  Tools can only spot what they can see.  Khan et al., explain that Capital One “implicitly” relied heavily upon expectations of AWS security tools.  Capital One had no platforms monitoring IAM and API calls, nor effective intrusion monitoring (Khan 22-23).  The decisions to not have these platforms and tools integrated into Capital One’s security were operational decisions stemming from gaps in knowledge at decision making layers of the company. Governance ensures the right tools at the right time.  The tools simply were not there.

References Khan, Shoaib, et al. “A Systemic Analysis of the Capital One Data Breach: Critical Lessons Learned.” ACM Transactions on Privacy and Security, vol. 26, no. 1, Feb. 2023, pp. 1–29.