NotPetya vs. Maersk: The BCP That Came Down to One Power Outage in Ghana

While a formal business continuity plan is built to handle everything from natural disasters to political upheaval, I wanted to look at this from a cybersecurity angle specifically — a BCP responding to a global cyberattack rather than a hurricane or a pandemic. Published BCPs are hard to find for obvious reasons (companies don't love publishing their own disaster playbooks), but I found a well-documented academic case study from Columbia University's School of International and Public Affairs covering exactly that: the 2017 NotPetya attack on Maersk.

The organization and the disruption

A.P. Møller–Maersk — the world's largest container shipping company — got hit by NotPetya in June 2017. The attack is attributed to Sandworm, a hacking unit tied to Russia's military intelligence service, and it reached Maersk through a Ukrainian accounting software vendor, Linkos Group, whose update servers for its M.E.Doc software were compromised and used to push the malware to every company that used it — Maersk's Ukrainian offices among them.

Once inside, NotPetya used two tools working together: EternalBlue (CVE-2017-0144), an NSA-developed exploit that had already leaked publicly the year before, and Mimikatz, a credential-extraction tool, to spread itself machine to machine by stealing admin credentials out of memory. Maersk's own security hygiene made this catastrophically easy — parts of its global infrastructure were still running Windows Server 2000, seventeen years out of support, when the attack hit. Once NotPetya got a foothold, it cascaded through Maersk's entire global network within hours, wiping roughly 150 domain controllers along the way and bringing port and shipping operations to a halt worldwide.

What the BCP response actually looked like

Maersk didn't have a single documented playbook for "every domain controller we own gets wiped simultaneously" — understandably, because that's an extreme scenario even by disaster-planning standards. But the response that emerged shows real contingency planning underneath the chaos:

• Maersk had a UK emergency operations center in Maidenhead up and running the same day the attack hit — staff were already working out of it within hours.
• At the peak of the response, as many as 200 Deloitte consultants worked alongside up to 400 Maersk staff at that one recovery center — a roughly 600-person mobilization, split across two organizations instead of one.
• Maersk had backups of individual servers, but not of its domain controllers specifically — and without a domain controller, none of those other backups could actually be restored. The one thing that quietly underpins an entire recovery plan was the one thing nobody had backed up.
• The fix came from pure luck layered on top of real redundancy design: domain controllers were built to resync from each other after an outage, but nobody had planned for a scenario where every single one went down at once. The one surviving copy turned up in a remote Ghana office, where a power outage had knocked a domain controller offline hours before NotPetya hit — disconnected, and therefore untouched.
• Getting that data out of Ghana wasn't simple, either: no Maersk staff in the office had the visas needed to fly directly to the UK, so the recovery became a relay — one employee flew the hard drive to Nigeria, handed it to a colleague, who then carried it the rest of the way to London.

Takeaways

Beyond the obvious lesson — don't run infrastructure-critical software that's old enough to vote — a few things stood out to me:

• An emergency operations center only helps if it's actually staffed and reachable fast. Maersk had people in theirs within hours, not days.
• Fast mobilization matters as much as the plan itself. Flying in several hundred people in the first days is only possible if that capability already exists before you need it.
• Backups are only as good as what they cover. Maersk backed up its servers and missed the one system — domain controllers — that everything else depends on.
• Redundancy design has to account for total failure, not partial failure. Domain controllers restoring each other works great until every one of them is compromised simultaneously, which is exactly the scenario ransomware is built to cause.
• Network segmentation would have changed this story. If Maersk had kept even one domain controller air-gapped or isolated at a backup site, they wouldn't have needed a Ghanaian power outage to save them.
• When digital systems go down completely, "go back to paper" isn't a failure. For roughly 48 hours, Maersk ran parts of its shipping operation on pen-and-paper logs, and it kept cargo moving. Having an actual, practiced manual fallback is part of a real BCP, not an admission that the plan failed.