CASE-01 · Case Study — Equifax: The Unpatched Server

What happened

In 2017, Equifax — one of the largest consumer credit bureaus in the United States — disclosed a breach that exposed the personal data of roughly 147 million people. The way in was not a zero-day or a nation-state super-weapon. Attackers reached a public web application, the online dispute portal, that was running a version of Apache Struts with a known, published vulnerability tracked as CVE-2017-5638. A patch for that flaw had been available for months. The vulnerable server was internet-facing, unpatched, and waiting.

Once the attackers had a foothold on that one host, the intrusion did not stay contained. They moved laterally through internal systems that were poorly segmented, and along the way they found credentials sitting in plaintext that let them reach additional databases. Over a period of weeks — not minutes — they queried system after system and pulled out the crown jewels: names, Social Security numbers, and birth dates for tens of millions of people.

See it — root cause to control

flowchart TD
  A["Known Struts CVE<br/>patch available for months"] --> B["Public dispute portal<br/>left unpatched"]
  B --> C["Foothold on<br/>internet-facing host"]
  C --> D["Weak segmentation +<br/>plaintext credentials"]
  D --> E["Lateral movement<br/>to databases"]
  E --> F["147M records exposed"]
  X["Asset inventory +<br/>timely patching"] -.stops.-> B
  Y["Segmentation +<br/>secrets management"] -.stops.-> D

The root cause

The proximate cause was an unpatched, publicly known vulnerability. But the deeper cause was a breakdown in vulnerability and patch management — the process that is supposed to find every affected system and get the fix applied before an attacker does. Equifax had that process on paper. It failed in practice for a very human reason: the vulnerable host was never flagged as vulnerable.

A scanning tool was meant to sweep internal systems for exactly this kind of exposure, but it depended on a certificate that had expired. With an expired certificate, the scanner could not inspect encrypted traffic on that segment, so the dispute portal simply did not appear on the list of things that needed patching. The alert that should have said "patch this now" was never generated. A control that everyone believed was running was, silently, blind — and a single unpatched box was enough.

The control that would have stopped it

Three ordinary controls, working together, would have closed this off — and none of them are exotic.

First, a complete and current asset inventory. You cannot patch what you do not know you own. If every internet-facing application is enumerated and mapped to the software it runs, then a new advisory becomes a query: "which of our assets run this component?" — answerable in hours, not archaeology.

Second, timely patching driven by that inventory, with the scanner's own health monitored so that a blind scanner is itself an alarm. An expired certificate that silently disables coverage should page someone; a control you cannot prove is working is a control you do not have.

Third, segmentation and secrets hygiene to limit the blast radius when — not if — a single host is compromised. If the dispute portal had been isolated from the databases, and if credentials had been vaulted instead of left in plaintext, a foothold on one web server would not have become a walk through the entire data estate.

The blast radius

Roughly 147 million people had their names, Social Security numbers, and birth dates exposed — some of the most sensitive and least changeable identifiers a person has. You can rotate a password; you cannot rotate your date of birth or your Social Security number. The exposure drove years of regulatory scrutiny, Congressional hearings, and a settlement with the FTC. But the human blast radius is the durable part: the data taken cannot be recalled, and it feeds identity fraud for as long as those identifiers remain valid.

See it

The incident is a straight line from a missed patch to a mass exposure. A single internet-facing host running a component with a published CVE, a scanner blinded by an expired certificate so the host was never flagged, a foothold, then lateral movement across flat internal networks using plaintext credentials — ending in 147 million records. Every arrow in that chain is a place a routine control was supposed to be and, quietly, was not.

The lesson

A control you cannot prove is running is a control you do not have.

Where it rhymes

This is the textbook case for OWASP A06 — Vulnerable and Outdated Components: an internet-facing application shipped a component with a known, patchable flaw, and the flaw stayed exploitable because inventory and patching failed. It also rhymes with the MITRE ATT&CK reality that initial access via a public-facing exploit is only step one — the damage comes from lateral movement through flat networks and credential access from secrets left in the clear. The reusable reflex is the same one behind every dependency-inventory drill: "are we exposed to this advisory?" must be a question you can answer on demand, and the tool that answers it must be monitored as carefully as the systems it scans.

Named concepts: vulnerability management, patch management, asset inventory, network segmentation. </content> </invoke>