Case Study 11.1: The Equifax Breach — When a Known Vulnerability Goes Unpatched

"Equifax had the tools, the personnel, and the resources to prevent this breach. The failure was not technical — it was a failure of vulnerability management." — U.S. Government Accountability Office (GAO), 2018

Overview

On September 7, 2017, Equifax — one of the three largest consumer credit reporting agencies in the United States — announced a data breach affecting approximately 147.9 million Americans. The stolen data included names, Social Security numbers, birth dates, addresses, and in some cases driver's license numbers and credit card numbers. It remains one of the most consequential data breaches in history.

The root cause was devastatingly simple: a known vulnerability in Apache Struts (CVE-2017-5638) that had a publicly available patch and exploit, yet remained unpatched on Equifax's Internet-facing web application for over two months.

This case study examines the breach through the lens of vulnerability assessment — demonstrating what happens when organizations fail to identify, prioritize, and remediate known vulnerabilities.

The Vulnerability: CVE-2017-5638

Technical Details

On March 6, 2017, the Apache Software Foundation disclosed CVE-2017-5638, a critical remote code execution vulnerability in Apache Struts 2. The vulnerability existed in the Jakarta Multipart parser and could be exploited by sending a specially crafted Content-Type header in an HTTP request.

CVSS v3.1 Base Score: 10.0 (Critical) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

The vulnerability was about as severe as possible: - Attack Vector: Network — exploitable remotely over HTTP - Attack Complexity: Low — no special conditions required - Privileges Required: None — no authentication needed - User Interaction: None — no user action required - Scope: Changed — could affect components beyond Apache Struts - Impact: High on Confidentiality, Integrity, and Availability

Exploit Availability

A proof-of-concept exploit was published on the same day as the vulnerability disclosure. Within days, multiple working exploits were available publicly, and active exploitation was observed in the wild. By March 10, 2017, the vulnerability was being mass-exploited across the Internet.

The exploit was trivially simple. An attacker sent an HTTP request with a malicious Content-Type header:

Content-Type: %{(#_='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='id').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}

This OGNL (Object-Graph Navigation Language) injection payload allowed arbitrary command execution on the server. The exploit required no special tools — it could be sent with curl.

The Timeline of Failure

The Patch Was Available

Date Event
March 6, 2017 Apache discloses CVE-2017-5638 and releases patch (Struts 2.3.32/2.5.10.1)
March 7, 2017 Working exploits published publicly
March 8, 2017 US-CERT issues alert about active exploitation
March 9, 2017 Equifax's internal security team sends mass email notification to administrators requiring patching within 48 hours
March 10, 2017 Mass exploitation observed across the Internet
March 15, 2017 Equifax runs vulnerability scans but the scan fails to identify the vulnerable Struts instance

The Breach Window

Date Event
May 13, 2017 Attackers exploit CVE-2017-5638 on Equifax's online dispute portal
May 13 – July 30, 2017 Attackers access Equifax systems for 78 days, stealing 147.9 million records
July 29, 2017 Equifax's security team notices suspicious network traffic while investigating an SSL certificate issue
July 30, 2017 Equifax takes the affected web application offline
August 1-2, 2017 Equifax engages Mandiant for incident response
September 7, 2017 Equifax publicly discloses the breach

Vulnerability Assessment Failures

Failure 1: Incomplete Asset Inventory

Equifax's vulnerability management team was unable to locate all instances of Apache Struts in their environment. The Congressional investigation revealed that the online dispute portal — the system ultimately compromised — was not identified as running the vulnerable Struts framework.

🔴 Lesson: Vulnerability assessment begins with a complete asset inventory. You cannot patch what you do not know exists. The Equifax breach underscores the critical importance of maintaining an accurate Configuration Management Database (CMDB) and using software composition analysis (SCA) tools to identify all software components.

Failure 2: Scanner Misconfiguration

When Equifax's security team ran vulnerability scans to identify Apache Struts instances, the scans did not detect the vulnerable application. The specific reasons were not fully disclosed, but likely causes include:

  • The scanner was not configured to test the specific web application paths
  • The dispute portal may have been on a non-standard port or virtual host
  • The scanner's Struts detection plugins may not have been updated
  • Network segmentation may have prevented the scanner from reaching the target

💡 Lesson: Automated vulnerability scanners are powerful but imperfect. Scanner configuration must be validated — including ensuring that detection plugins are current, that scan scope includes all relevant targets, and that network configurations permit scanners to reach all in-scope systems. Manual verification of critical vulnerability patches is essential.

Failure 3: No Compensating Controls

Even if Equifax could not patch immediately, several compensating controls could have prevented or detected the exploitation:

  • Web Application Firewall (WAF): A properly configured WAF could have blocked the malicious Content-Type headers. Equifax's investigation revealed that WAF rules were not updated for this specific attack pattern.
  • SSL/TLS certificate management: Equifax had allowed an SSL certificate to expire on a device that monitored encrypted network traffic. This meant that data exfiltration was happening through encrypted channels that Equifax could not inspect.
  • Network segmentation: The dispute portal had excessive access to backend databases containing the full credit dataset. Better segmentation could have limited the blast radius.
  • Intrusion detection: The attackers operated for 78 days without detection. Behavioral monitoring and anomalous data transfer detection could have caught the exfiltration sooner.

Failure 4: Communication Breakdown

The March 9 email notification to administrators required patching within 48 hours. However: - There was no verification that the notification reached all responsible parties - There was no follow-up to confirm patching was completed - There was no escalation process when the vulnerability scan failed to confirm remediation - The administrator responsible for the dispute portal reportedly did not receive or act on the notification

Consequences

  • $700 million settlement with the Federal Trade Commission (FTC), Consumer Financial Protection Bureau (CFPB), and 50 states
  • The CEO, CIO, and CSO all departed within weeks of the disclosure
  • Congressional hearings scrutinized Equifax's security practices
  • Multiple class-action lawsuits from affected consumers
  • Regulatory investigations in the UK, Canada, and other countries

Industry Impact

The Equifax breach became the defining example of vulnerability management failure. It directly influenced:

  • SEC cybersecurity disclosure guidance (updated 2018)
  • CISA's Known Exploited Vulnerabilities catalog (launched 2021), which mandates federal agencies patch actively exploited vulnerabilities within specific timeframes
  • Industry adoption of vulnerability SLAs — defined timeframes for patching based on severity
  • Increased investment in software composition analysis (SCA) tools
  • Enhanced focus on patch verification — not just scanning, but confirming patches are applied

Lessons for Vulnerability Assessment Professionals

1. Patch SLAs Must Be Enforced

Equifax's 48-hour patching requirement was reasonable for a CVSS 10.0 vulnerability with active exploitation. The failure was in enforcement. Modern vulnerability management programs define SLAs:

Severity Patch SLA Verification
Critical (CVSS 9.0-10.0) 24-48 hours Immediate rescan
High (CVSS 7.0-8.9) 7 days Weekly rescan
Medium (CVSS 4.0-6.9) 30 days Monthly rescan
Low (CVSS 0.1-3.9) 90 days Quarterly rescan

2. Defense in Depth Is Not Optional

No single control should be the sole protection against a critical vulnerability. The combination of unpatched software + misconfigured WAF + expired SSL certificate + poor segmentation + no behavioral detection created a "Swiss cheese" failure where every layer had a hole, and they all aligned.

3. Vulnerability Assessment Must Include Verification

Running a vulnerability scanner is not enough. The output must be validated: - Were all targets successfully scanned? - Were credentials working properly? - Were plugin databases up to date? - Were results reviewed by a human analyst? - Were critical findings confirmed through manual testing?

4. The Cost of Not Patching

The Equifax breach cost over $1.4 billion in direct expenses (security improvements, legal fees, settlement costs, regulatory fines). The patch for CVE-2017-5638 was free and took minutes to apply. The cost-benefit analysis is overwhelming.

⚖️ Ethical Reflection: 147.9 million people's most sensitive financial data was exposed because a known, patchable vulnerability went unremediated. The ethical obligation of organizations handling sensitive data to maintain robust vulnerability management programs is not just a technical recommendation — it is a moral imperative.


Discussion Questions

  1. Equifax's vulnerability scan failed to detect the vulnerable Apache Struts instance. What specific steps would you take to prevent similar scanner failures in your vulnerability assessment methodology?

  2. The attackers operated inside Equifax's network for 78 days. What detection capabilities should have caught the breach sooner? How would you prioritize implementing these capabilities?

  3. Should individuals (the CEO, CIO, CSO) bear personal liability for cybersecurity failures of this magnitude? What governance structures might prevent similar failures?

  4. How would you design a vulnerability management program that ensures a CVE-2017-5638-type vulnerability is identified and remediated within 48 hours of disclosure?

  5. The vulnerability had a CVSS score of 10.0, a public exploit on day one, and active exploitation within days. What combination of CVSS, KEV status, and other factors should trigger your organization's highest-priority remediation process?


Key Takeaways

  • The Equifax breach was caused by a known, patched vulnerability (CVE-2017-5638, CVSS 10.0) that went unremediated for over two months.
  • Asset inventory gaps prevented the vulnerable system from being identified for patching.
  • Scanner misconfiguration produced false negatives, giving a false sense of security.
  • Lack of defense in depth — multiple control failures aligned to enable the breach.
  • The cost of a $0 patch vs. a $1.4 billion breach makes the business case for vulnerability management irrefutable.
  • Vulnerability assessment must include verification — scanning alone is insufficient.