{
	"id": "fd6de41c-2ab2-403d-8402-8696c6bb8035",
	"created_at": "2026-04-06T01:31:16.701852Z",
	"updated_at": "2026-04-10T03:20:04.07343Z",
	"deleted_at": null,
	"sha1_hash": "7d290dd721f31f72c49f8601142db5fd34d79a63",
	"title": "What We Can Learn from the Capital One Hack",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 424519,
	"plain_text": "What We Can Learn from the Capital One Hack\r\nPublished: 2019-08-05 · Archived: 2026-04-06 01:19:13 UTC\r\nOn Monday, a former Amazon employee was arrested and charged with stealing more than 100 million consumer\r\napplications for credit from Capital One. Since then, many have speculated the breach was perhaps the result of a\r\npreviously unknown “zero-day” flaw, or an “insider” attack in which the accused took advantage of access\r\nsurreptitiously obtained from her former employer. But new information indicates the methods she deployed have\r\nbeen well understood for years.\r\nWhat follows is based on interviews with almost a dozen security experts, including one who is privy to details\r\nabout the ongoing breach investigation. Because this incident deals with somewhat jargon-laced and esoteric\r\nconcepts, much of what is described below has been dramatically simplified. Anyone seeking a more technical\r\nexplanation of the basic concepts referenced here should explore some of the many links included in this story.\r\nAccording to a source with direct knowledge of the breach investigation, the problem stemmed in part from a\r\nmisconfigured open-source Web Application Firewall (WAF) that Capital One was using as part of its operations\r\nhosted in the cloud with Amazon Web Services (AWS).\r\nKnown as “ModSecurity,” this WAF is deployed along with the open-source Apache Web server to provide\r\nprotections against several classes of vulnerabilities that attackers most commonly use to compromise the security\r\nof Web-based applications.\r\nThe misconfiguration of the WAF allowed the intruder to trick the firewall into relaying requests to a key back-end resource on the AWS platform. This resource, known as the “metadata” service, is responsible for handing out\r\nhttps://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/\r\nPage 1 of 5\n\ntemporary information to a cloud server, including current credentials sent from a security service to access any\r\nresource in the cloud to which that server has access.\r\nIn AWS, exactly what those credentials can be used for hinges on the permissions assigned to the resource that is\r\nrequesting them. In Capital One’s case, the misconfigured WAF for whatever reason was assigned too many\r\npermissions, i.e. it was allowed to list all of the files in any buckets of data, and to read the contents of each of\r\nthose files.\r\nThe type of vulnerability exploited by the intruder in the Capital One hack is a well-known method called a\r\n“Server Side Request Forgery” (SSRF) attack, in which a server (in this case, CapOne’s WAF) can be tricked into\r\nrunning commands that it should never have been permitted to run, including those that allow it to talk to the\r\nmetadata service.\r\nEvan Johnson, manager of the product security team at Cloudflare, recently penned an easily digestible\r\ncolumn on the Capital One hack and the challenges of detecting and blocking SSRF attacks targeting cloud\r\nservices. Johnson said it’s worth noting that SSRF attacks are not among the dozen or so attack methods for which\r\ndetection rules are shipped by default in the WAF exploited as part of the Capital One intrusion.\r\n“SSRF has become the most serious vulnerability facing organizations that use public clouds,” Johnson\r\nwrote.\r\n“SSRF has become the most serious vulnerability facing organizations that use public clouds,” Johnson wrote.\r\n“The impact of SSRF is being worsened by the offering of public clouds, and the major players like AWS are not\r\ndoing anything to fix it. The problem is common and well-known, but hard to prevent and does not have any\r\nmitigations built into the AWS platform.”\r\nJohnson said AWS could address this shortcoming by including extra identifying information in any request sent\r\nto the metadata service, as Google has already done with its cloud hosting platform. He also acknowledged that\r\ndoing so could break a lot of backwards compatibility within AWS.\r\n“There’s a lot of specialized knowledge that comes with operating a service within AWS, and to someone without\r\nspecialized knowledge of AWS, [SSRF attacks are] not something that would show up on any critical\r\nconfiguration guide,” Johnson said in an interview with KrebsOnSecurity.\r\n“You have to learn how EC2 works, understand Amazon’s Identity and Access Management (IAM) system, and\r\nhow to authenticate with other AWS services,” he continued. “A lot of people using AWS will interface with\r\ndozens of AWS services and write software that orchestrates and automates new services, but in the end people\r\nreally lean into AWS a ton, and with that comes a lot of specialized knowledge that is hard to learn and hard to get\r\nright.”\r\nIn a statement provided to KrebsOnSecurity, Amazon said it is inaccurate to argue that the Capital One breach was\r\ncaused by AWS IAM, the instance metadata service, or the AWS WAF in any way.\r\n“The intrusion was caused by a misconfiguration of a web application firewall and not the underlying\r\ninfrastructure or the location of the infrastructure,” the statement reads. “AWS is constantly delivering services\r\nand functionality to anticipate new threats at scale, offering more security capabilities and layers than customers\r\nhttps://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/\r\nPage 2 of 5\n\ncan find anywhere else including within their own datacenters, and when broadly used, properly configured and\r\nmonitored, offer unmatched security—and the track record for customers over 13+ years in securely using AWS\r\nprovides unambiguous proof that these layers work.”\r\nAmazon pointed to several (mostly a la carte) services it offers AWS customers to help mitigate many of the\r\nthreats that were key factors in this breach, including:\r\n–Access Advisor, which helps identify and scope down AWS roles that may have more permissions than they\r\nneed;\r\n–GuardDuty, designed to raise alarms when someone is scanning for potentially vulnerable systems or moving\r\nunusually large amounts of data to or from unexpected places;\r\n–The AWS WAF, which Amazon says can detect common exploitation techniques, including SSRF attacks;\r\n–Amazon Macie, designed to automatically discover, classify and protect sensitive data stored in AWS.\r\nWilliam Bengston, formerly a senior security engineer at Netflix, wrote a series of blog posts last year on how\r\nNetflix built its own systems for detecting and preventing credential compromises in AWS. Interestingly,\r\nBengston was hired roughly two months ago to be director of cloud security for Capital One. My guess is Capital\r\nOne now wishes they had somehow managed to lure him away sooner.\r\nRich Mogull is founder and chief technology officer with DisruptOPS, a firm that helps companies secure their\r\ncloud infrastructure. Mogull said one major challenge for companies moving their operations from sprawling,\r\nexpensive physical data centers to the cloud is that very often the employees responsible for handling that\r\ntransition are application and software developers who may not be as steeped as they should in security.\r\n“There is a basic skills and knowledge gap that everyone in the industry is fighting to deal with right now,”\r\nMogull said. “For these big companies making that move, they have to learn all this new stuff while maintaining\r\ntheir old stuff. I can get you more secure in the cloud more easily than on-premise at a physical data center, but\r\nthere’s going to be a transition period as you’re acquiring that new knowledge.”\r\nhttps://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/\r\nPage 3 of 5\n\nImage: Capital One\r\nSince news of the Capital One breach broke on Monday, KrebsOnSecurity has received numerous emails and\r\nphone calls from security executives who are desperate for more information about how they can avoid falling\r\nprey to the missteps that led to this colossal breach (indeed, those requests were part of the impetus behind this\r\nstory).\r\nSome of those people included executives at big competing banks that haven’t yet taken the plunge into the cloud\r\nquite as deeply as Capital One has. But it’s probably not much of a stretch to say they’re all lining up in front of\r\nthe diving board.\r\nIt’s been interesting to watch over the past couple of years how various cloud providers have responded to major\r\noutages on their platforms — very often soon after publishing detailed post-mortems on the underlying causes of\r\nthe outage and what they are doing to prevent such occurrences in the future. In the same vein, it would be\r\nwonderful if this kind of public accounting extended to other big companies in the wake of a massive breach.\r\nI’m not holding out much hope that we will get such detail officially from Capital One, which declined to\r\ncomment on the record and referred me to their statement on the breach and to the Justice Department’s complaint\r\nagainst the hacker. That’s probably to be expected, seeing as the company is already facing a class action lawsuit\r\nover the breach and is likely to be targeted by more lawsuits going forward.\r\nBut as long as the public and private response to data breaches remains orchestrated primarily by attorneys (which\r\nis certainly the case now at most major corporations), everyone else will continue to lack the benefit of being able\r\nto learn from and avoid those same mistakes.\r\nhttps://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/\r\nPage 4 of 5\n\nSource: https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/\r\nhttps://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/"
	],
	"report_names": [
		"what-we-can-learn-from-the-capital-one-hack"
	],
	"threat_actors": [],
	"ts_created_at": 1775439076,
	"ts_updated_at": 1775791204,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7d290dd721f31f72c49f8601142db5fd34d79a63.pdf",
		"text": "https://archive.orkl.eu/7d290dd721f31f72c49f8601142db5fd34d79a63.txt",
		"img": "https://archive.orkl.eu/7d290dd721f31f72c49f8601142db5fd34d79a63.jpg"
	}
}