Maersk and NotPetya: would your org have survived the same hit?

Most organizations would not have survived a NotPetya style event without one thing Maersk happened to have by luck: a single offline copy of its directory data. The attack combined a poisoned software update, credential theft and fast lateral movement. A good test is whether you could rebuild your identity system from scratch.

What happened, in plain terms?

CISA's alert describes NotPetya as discovered on 27 June 2017 across several countries and sectors. The malware was delivered through a backdoor in the Ukrainian tax software M.E.Doc, with attacker access going back to April 2017. Once inside, it spread two ways: by stealing Windows credentials with a modified Mimikatz and moving with WMIC or PsExec, and by exploiting unpatched SMBv1 systems.

CISA noted it behaved more like destructive malware than ransomware. It encrypted files and altered the master boot record, and the payment email address was shut down, so paying could not restore anything.

Wired's detailed account of Maersk describes what recovery looked like. Administrators feared that if they could not recover the domain controllers, they could not recover anything. They eventually found one controller in a remote office in Ghana that a blackout had left offline, so it escaped the wipe. Its several-hundred-gigabyte copy had to be physically carried to the UK. Wired reports the company rebuilt about 4,000 servers and 45,000 PCs in around 10 days, with some staff working close to two months to finish the full rebuild.

This is not a story about careless people. Maersk was hit through trusted software it did not write, which is why it is useful as a test.

Which controls matter most?

CISA's own mitigation list maps neatly to questions you can ask:

• Can one stolen administrator credential reach every machine? Least privilege and restricted remote execution limit that blast radius.
• Is SMBv1 off and the MS17-010 patch, released 14 March 2017, applied everywhere?
• Can workstations talk to each other freely? Host firewalls and segmentation stop an infection hopping across a floor.
• Are your backups tested, and is at least one copy offline or otherwise immune to the same wiper?

The Maersk lesson sits underneath those: replicated systems are not backups. Domain controllers synced with each other, and the sync spread the destruction just as well as the data.

What to do

1. Write down how you would rebuild Active Directory or your identity provider from nothing, then time a tabletop of it.
2. Keep at least one offline, immutable backup of identity data and test a restore each quarter.
3. Remove standing domain admin rights from daily accounts and use tiered or just-in-time administration.
4. Disable SMBv1 and block SMB at the network boundary.
5. Block remote PsExec style execution and restrict WMI between workstations.
6. Segment the network so a compromise in one office or business unit cannot reach the rest by default.
7. Treat updates from third-party software vendors as a risk: stage them, and limit what the update service account can do.
8. Keep an out-of-band communication plan, because email and chat may be down with everything else.
9. Document the order of restoration: identity, DNS, core business systems, then the rest.
10. Know who calls law enforcement, and preserve logs before rebuilding.

Where does the supply chain angle come in?

The entry point was software update delivery from a legitimate vendor. A complete inventory of what software runs where, including accounting and tax tools, tells you what to check when a vendor is named in an alert. CISA advised treating systems with M.E.Doc installed as suspicious, and you can only follow advice like that if you know where the software lives.

Quick check

Sources

• CISA: Petya Ransomware alert (archived), fetched 18 October 2026.
• Wired: The Untold Story of NotPetya, fetched 18 October 2026.

Last reviewed: 18 October 2026.