CASE-07 · Case Study — NotPetya: Ransomware That Wasn't

What happened

In June 2017, machines across dozens of multinational companies rebooted, showed a fake disk-check screen, and then displayed a ransom note demanding payment in Bitcoin to recover the files. It looked like a ransomware outbreak — an aggressive cousin of the earlier "Petya" family, which is why it picked up the name NotPetya. But the ransom was theater. The malware overwrote the master boot record and mangled the file system in a way that made recovery impossible even if you paid. There was no working decryption path. NotPetya was not built to extort; it was built to destroy, wearing ransomware as a costume so the first responders would waste time chasing a payment that led nowhere.

The initial foothold was not a phishing email or an exposed server. It was an update. The attackers had compromised the update mechanism of M.E.Doc, a Ukrainian tax-and-accounting package that is near-mandatory for companies doing business in Ukraine. When M.E.Doc pushed a routine software update, it pushed NotPetya along with it — signed, trusted, and welcomed straight through the front door. From that first trusted install, the malware spread on its own, hunting for other machines on every network it could reach.

See it — from trusted update to global wiper

timeline
    title NotPetya, June 2017
    Seed : M.E.Doc update<br/>server compromised
    Trust : Trojanized update<br/>signed and shipped
    Foothold : Runs on install<br/>inside the network
    Spread : EternalBlue plus<br/>stolen credentials
    Impact : Boot record wiped<br/>no recovery
    Cost : ~10 billion dollars<br/>across many firms

The root cause

There were two failures stacked on top of each other, and NotPetya needed both.

The first was a supply-chain compromise. The victims did not download anything reckless. They trusted a vendor, and the vendor's update channel was subverted. Once you accept updates from a supplier, you have effectively extended your trust boundary to include that supplier's build and distribution systems — and NotPetya proved that an attacker who owns the vendor's pipeline owns everyone downstream, all at once, through a channel your defenses are configured to permit.

The second was lateral movement — and this is the part that turned a Ukrainian incident into a global one. NotPetya carried two ways to jump from machine to machine. It used EternalBlue, an exploit against a Windows file-sharing (S.M.B.) flaw, to infect unpatched systems automatically. But it also harvested credentials from the memory of each machine it landed on and reused them to log in to other machines the legitimate way. That second technique is why patching alone did not save companies: a fully patched server would still accept a valid administrator login, so once NotPetya stole a domain admin credential anywhere on a flat network, it could walk into every other machine as a trusted user. Flat networks and reused privileged credentials turned one infected laptop into a company-wide wipe in minutes.

The control that would have stopped it

No single control was the answer; NotPetya is a case study precisely because it defeated defenders who had done one thing right but not the others. Four controls, layered, break the chain:

• Supply-chain integrity — treat vendor updates as untrusted input. Know your software bill of materials, watch what update processes actually do, and don't let an accounting tool run with the freedom to rewrite boot records across the fleet.
• Network segmentation — a flat network is a wiper's dream. Segmenting by function and blocking lateral S.M.B. traffic between workstations means one infected host cannot see, let alone reach, the whole estate.
• Credential hygiene — because NotPetya moved with stolen logins, the countermeasure is limiting what a stolen login is worth: no shared local-admin passwords, no domain-admin credentials sitting on ordinary workstations, and tiered administration so a harvested credential unlocks one segment, not the kingdom.
• Tested backups — against a wiper, the only recovery is a restore. Backups that are offline, immutable, and actually rehearsed are the difference between days of downtime and weeks. The companies that recovered fastest were the ones who had practiced.

The blast radius

The total damage from NotPetya is commonly estimated at around 10 billion dollars worldwide — the costliest cyberattack on record at the time. The shipping giant A.P. Moller-Maersk was knocked offline globally, disclosing losses in the hundreds of millions of dollars as terminals and booking systems went dark. Pharmaceutical company Merck disclosed a large financial impact spanning manufacturing disruption and remediation. FedEx's TNT Express unit, Mondelez, Saint-Gobain, and others were hit as well. In February 2018, the White House publicly attributed NotPetya to the Russian military, calling it part of the Kremlin's campaign to destabilize Ukraine — collateral damage that spilled far beyond its intended target because the malware, once loosed, did not respect borders or org charts.

See it

The chain is short and each link is a control you could have owned: a trusted update carried the seed, a flat network with reusable credentials carried the spread, and the absence of tested backups turned a wipe into a catastrophe. Break any one link — verify the supply chain, segment the network, contain the credentials, rehearse the restore — and NotPetya's blast radius shrinks from a company to a laptop.

The lesson

Trust you can't verify is an attack surface — a signed update from a trusted vendor is still an untrusted input, and a flat network turns one infection into all of them.

Where it rhymes

NotPetya is the textbook case of OWASP A08 — Software and Data Integrity Failures: trusting an update whose integrity you never verified. In ATT&CK terms it is Supply Chain Compromise (T1195) for the entry and Lateral Movement — Exploitation of Remote Services plus credential-based Pass-the-Hash / Use Alternate Authentication — for the spread. It rhymes with Drill 60 — The Package That Turned, the same reflex at library scale: you inherit the security of everything you pull in, so the integrity of your dependencies and update channels is your problem, not your vendor's.

Named concepts: supply-chain compromise, lateral movement, credential hygiene, network segmentation, tested backups.