/find@mail

Articles, write-ups, and musings concerning the world of cybersecurity and technology.

Equifax: A Breach With Five Separate Points Where It Could Have Stopped

Case Studies  · 954 words · 5 min read · by QiO:~$ ·

Equifax: A Breach With Five Separate Points Where It Could Have Stopped

The best way to approach an assignment like "compare a secure architecture to an insecure one" is to look at the failures suffered during a well-documented breach, analyze them from a network architecture standpoint, and then talk about how it could've been designed better. With that in mind, there's probably no failure better suited to this than the 2017 Equifax breach — the subsequent Senate subcommittee and Government Accountability Office investigations dug up and published a lot of detail about exactly what went wrong, which makes it one of the best-documented architecture failures out there.

Background

In March 2017, a critical vulnerability was disclosed in Apache Struts — tracked as CVE-2017-5638 — a widely used Java web application framework. A patch was released within days, on March 7-9. Equifax did not apply it. On March 10, attackers exploited the same unpatched vulnerability in an internet-facing web application (a consumer complaint portal) to gain their initial foothold.

Here's the detail that doesn't make it into every retelling: Equifax did have a process meant to catch exactly this kind of thing. A scan intended to find unpatched systems ran on March 15 — and it failed to catch the vulnerable server. So the company wasn't just slow to patch; the backstop that should have caught the gap also broke.

The attackers — later identified by the DOJ in a February 2020 indictment as members of the Chinese People's Liberation Army — sat mostly dormant after that initial access until mid-May, then spent about 76 days actively moving through the network and exfiltrating data before anyone noticed. In the end, the breach exposed the sensitive financial and personal data of roughly 143 million Americans — close to 40% of the US population at the time — including names, addresses, birthdates, Social Security numbers, and driver's license numbers.

Insecure Architecture

  • Network segmentation. Once the attackers were inside the web server, they were able to move laterally across the network into far more sensitive internal systems, including customer information databases. There wasn't enough separation between a public-facing application and the crown jewels.
  • Unencrypted sensitive data at rest. Equifax failed to adequately encrypt customer data, so once attackers reached it, it was trivially easy to read and exfiltrate.
  • Lax access controls. Equifax used overly broad access even on sensitive systems, and stolen credentials were enough on their own to get into databases — no second factor required.
  • Unpatched vulnerabilities. A known, published CVE can be the Achilles' heel of even a well-designed network. Equifax had a patch available for roughly two and a half months before the breach began and still hadn't applied it — and the automated process meant to flag that gap failed too.
  • Network monitoring and IDS failure. This is arguably the worst part, worse even than the patch delay. Equifax had an IDS in place, and it still failed to flag a sustained, 76-day exfiltration of customer data. Why? The tool responsible for inspecting encrypted traffic depended on an SSL certificate that had expired almost ten months earlier and was never renewed. Encrypted traffic — including the attackers' own exfiltration — was effectively invisible to monitoring the entire time. The certificate wasn't renewed until July 29, 2017, and the moment it was, the suspicious activity that had been running under cover for months suddenly became visible.

Securing the Architecture

  • Patch internet-facing systems immediately. Any internet-facing server — mail, FTP, and especially web application servers — with a published vulnerability needs to be patched without delay. Equifax had the patch available before the attack even started; the gap between "available" and "applied" is where this entire breach lives.
  • Segment the network properly. Internet-facing servers should sit in their own segment — a DMZ, at minimum. If a server needs access to sensitive data, it belongs on its own VLAN behind a firewall that only allows explicitly permitted traffic between segments, with ACLs enforcing source/destination rules. Micro-segmentation using SDN or host-based firewalls can tighten this further — down to specific allowed database queries on a given server.
  • Monitoring and IDS that actually works. This is exactly why penetration testing, red-teaming, and regular audits matter — not as a checkbox, but as the mechanism that catches a monitoring tool silently failing (like an expired cert nobody noticed for ten months). Simulating an intrusion as part of a regular audit is one of the most reliable ways to find out your detection tooling doesn't actually detect anything.
  • Stronger access controls. Strict RBAC under a zero-trust model, plus MFA on anything touching sensitive data, would have meaningfully limited how far a single set of stolen credentials could reach.
  • Encrypt data at rest. There's no good reason sensitive customer data was sitting unencrypted in a database. At minimum, that data should be hashed/encrypted with something like SHA-256, and even relational databases can run Transparent Data Encryption with minimal performance overhead.

Takeaway: What makes Equifax such a useful case study isn't just that they got breached — plenty of companies do. It's that there were at least five independent points in the chain where a basic control, properly maintained, would have stopped or limited the damage: patching, segmentation, encryption, access control, and monitoring. None of these are exotic. The real failure wasn't a sophisticated attacker outsmarting good defenses — it was ordinary defenses that had quietly stopped working, for months, and nobody checked.

Sources

Read next

Rolling Out Kerberos Without Active Directory