Why Most Cyber Attacks Don't Need Zero-Days

When I started studying cybersecurity, I expected the field to be all zero-days and nation-state hackers — the stuff that makes good movies. Then I started reading breach reports instead of watching them, and the pattern was almost embarrassing in its banality. The scary attacks are rare. The common ones are boring, and they work because the boring stuff was left undone.

Take three well-documented examples:

• Equifax, 2017. One of the largest data breaches in history — 147 million people. The entry point was a known vulnerability in Apache Struts, with a public patch available months earlier. Equifax didn't apply it. No zero-day required.
• Colonial Pipeline, 2021. The attack that shut down fuel supply on the US East Coast started with a leaked VPN password — one credential, likely reused, no exploit at all. The company paid a ransom and the pipeline went dark for days.
• Codecov, 2021. Attackers compromised the script that thousands of companies run in CI, harvested credentials from build environments, and used them to reach downstream systems. Supply chain, not a novel vulnerability in anyone's code.

None of these needed an elite exploit. They needed a known CVE left unpatched, a credential left exposed, or a trusted process left unguarded. That's the real story of how systems get breached, and it's way less glamorous than the movies.

The economics of the "advanced" attacker

Zero-days are real, but they're expensive — hundreds of thousands of dollars on the exploit market, and they get pricier as they get burned. They're used for targeted operations: espionage, surveillance, high-value infrastructure. Your average attacker is not burning a six-figure exploit on a random startup's web server when the same server responds to admin/admin on port 22.

What they're actually doing:

• Scanning Shodan for exposed admin panels and unauthenticated databases
• Trying default credentials (they still work more often than anyone wants to admit)
• Checking whether known CVEs are patched — they usually aren't
• Stuffing credentials from leaked password dumps into every login form they can find

None of this requires genius. It requires patience and a search engine. The single hardest part of most attacks is picking a target that hasn't done the basics.

Where the openings actually are

After enough breach reports, you stop looking for the clever part and start looking at the inventory:

Services that shouldn't be public. I've found MongoDB instances with no authentication listening on public IPs, Redis servers wide open, and staging environments with debug mode enabled accidentally promoted to production. A port scan is often the only "exploit" involved — Shodan indexes this stuff by the thousands every day so attackers don't even need to scan.

Credentials that outlived their usefulness. Breaches leak password databases; people reuse passwords; attackers try the same credentials everywhere else. Your users' email passwords become your app's admin credentials through nothing more than a script and a leaked list.

Cloud misconfiguration. Public S3 buckets have caused some of the largest data exposures on record. IAM roles with wildcard permissions do the same thing in slow motion. And committed API keys — I once found an AWS key in a public repo just by searching GitHub for AKIA, the access-key prefix. Took about thirty seconds.

Why it keeps happening

Because security is still treated as the thing you do after launch, after the sprint, after someone remembers. The dependency update is "low priority." The security review gets pushed to "next quarter." The default credentials stay because changing them is friction.

Attackers know all of this. They're not searching for the hardest way in; they're searching for the easiest one, and the easiest one is almost always something somebody already knew about and didn't fix.

The boring fix list

Before any advanced threat hunting matters, this has to be solid:

• Patch what you know is broken, on a schedule, not reactively
• Enforce least privilege — a service that only needs read access shouldn't have write
• Keep an inventory of what's running; you can't secure what you don't know exists
• Rotate credentials and audit continuously, not annually

If you're defending against APTs but your default credentials are still the default and last month's critical CVE is unpatched, you're defending the wrong perimeter. The attackers will walk through the front door you left open while you were busy installing the laser grid in the basement — assuming you get around to the laser grid at all.