The Maersk Massacre: How NotPetya Rewrote the Rules

One accounting software update in Odessa. Ten days of darkness. And a preview of what happens when malware moves freely from IT to OT and what an AI-powered successor could do.

I've been in cybersecurity long enough to have seen many "defining moments." Breaches that changed procurement decisions. Exploits that sparked congressional hearings. Malware families that became case studies at universities. But when I sit down with OT security teams, the people protecting shipping terminals, power grids, and pipeline SCADA systems, and the conversation turns to NotPetya and Maersk, the room goes quiet in a way that other incidents simply don't produce.

This one was different. This one showed us what unconstrained lateral movement actually looks like at an industrial scale. And with frontier AI models now capable of dramatically accelerating malware development, I don't think we're talking about history anymore. I think we're talking about a warning.

The Incident: It started with a tax form

June 27, 2017. Employees at Maersk offices around the world started seeing a strange message on their screens: their file systems were "being repaired." Then came the ransom demand. By the time anyone realized this was not ordinary ransomware, it was already over.

The entry point was a single computer in Odesa, Ukraine, a port city where Maersk had operations. Someone at that office used M.E.Doc, a Ukrainian accounting software package required by local tax law. The Russian GRU-linked group known as Sandworm had compromised M.E.Doc's update mechanism months earlier, planting a backdoor by stealing SSH credentials from Intellect Services' own servers, servers that hadn't been patched in over four years. When M.E.Doc pushed an automatic software update, NotPetya rode along with it, silent and waiting.

Maersk was not a negligent company. As their CISO, Andy Powell, would later note: "Maersk was not unusually weak; there was no flaw in what we were doing when that happened." NotPetya didn't exploit a Maersk mistake. It exploited a supply chain, an implicit trust relationship with third-party software that no enterprise firewall was positioned to see.

The Mechanics: How NotPetya Moved

What made NotPetya so catastrophic wasn't its entry point; it was its lateral movement engine. Once inside that single machine in Odessa, NotPetya deployed a three-pronged propagation strategy that turned Maersk's flat, interconnected corporate network into its own worst enemy.

EternalBlue: The Highway
NotPetya exploited CVE-2017-0144, the SMBv1 vulnerability in Windows — the same NSA-developed exploit behind WannaCry. Microsoft had patched it in March 2017, three full months before the outbreak. Unpatched machines had no barrier to remote code execution across the internal network. NotPetya spread machine to machine without needing to touch the internet.

Mimikatz + Pass-the-Hash:The Key Ring
For machines that had been patched, NotPetya pulled NTLM password hashes from memory using Mimikatz-like credential extraction. It then replayed those hashes directly against adjacent Windows systems: no plaintext password needed. In environments where admins reuse credentials, a single compromise cascades into domain-wide access.

PsExec + WMI: The Living-Off-the-Land Execution Layer
Once credentials were harvested, NotPetya used PsExec and Windows Management Instrumentation (WMI) (both legitimate system administration tools) to remotely execute its payload on newly reached machines. This made it nearly invisible to defenses that watch for unknown processes: the malware was riding entirely on trusted native tools.

‍

MBR Overwrite: The Killswitch
On each newly infected machine, NotPetya overwrote the Master Boot Record (the firmware-layer code that starts the operating system) with its own payload. The next reboot was fatal. Data was not merely encrypted; it was destroyed. No payment would ever recover it. NotPetya was not ransomware. It was a weapon wearing ransomware's clothes.

The result? A flat corporate network (600 locations across the globe, all connected and trusting each other) propagated the infection within hours. Maersk had to reinstall over 4,000 servers, 45,000 PCs, and 2,500 applications in ten days. The only reason they could restore their Active Directory domain at all was a single domain controller in Ghana that happened to be offline during the attack due to a power cut. One accidental air gap saved the entire company.

The Flat Network Problem
NotPetya spread so rapidly because Maersk, like most global enterprises of the era, operated a flat network in which systems could communicate laterally. Had proper microsegmentation been in place (limiting which systems could reach which), the blast radius would have been contained to the initial infection zone, not the entire company.

The Hidden Near Miss: It stopped at IT. Barely
Here's what people don't talk about enough: in 2017, Maersk's OT systems (the terminal operating systems, crane controls, berth management software, and vessel traffic services at 76 ports) largely survived. Not because of great segmentation. Largely because of luck, timing, and the fact that many port OT systems were running different, older, or proprietary operating systems that NotPetya's Windows-specific propagation couldn't automatically exploit.

But surviving is not the same as being safe. The IT network at those 76 terminals went completely dark. Container bookings, customs manifests, cargo tracking, port scheduling: all gone. Maersk's chairman described it plainly: "Imagine a company where a ship with 20,000 containers would enter a port every 15 minutes, and for ten days you have no IT." Operations reverted to whiteboard and paper. An 80% throughput on manual processes was, by any measure, a miracle of human resilience.

The OT near-miss is the part that should terrify every industrial security professional. Because the gap between "NotPetya hit the IT side of a port and didn't reach the cranes" and "NotPetya hits IT, pivots to OT, and disables physical port infrastructure" is not a technical wall. In most modern facilities, it is a policy gap and a configuration gap. And those gaps are closing. Not because defenders are improving, but because attackers are getting better tools.

OT Convergence Risk
The convergence of IT and OT networks for operational efficiency has created direct lateral movement paths from compromised IT endpoints to PLCs, HMIs, and safety instrumented systems. OT devices themselves cannot defend against this; they were never designed to. A PLC doesn't run antivirus. A crane controller doesn't check certificate revocation lists. They trust whatever is on the network.

The New Threat: What happens when you give NotPetya an AI Co-Pilot?

I want to be direct here, because this is the part of the conversation the industry is not having loudly enough.

Anthropic has developed a frontier model, Claude Mythos Preview, which is currently being evaluated under controlled conditions by a small number of trusted organizations through Project Glasswing. It is not publicly available precisely because of cybersecurity concerns about its capabilities. That's a responsible choice, and I give credit for it.

But here's the uncomfortable reality: the research capability that makes models like Mythos valuable also represents a step-change in what sophisticated threat actors can build. We are moving (rapidly!) into an era where the kind of multi-vector, adaptive lateral movement that took Sandworm months to develop and test could be prototyped in days by a well-resourced adversary with access to similar-capability models, whether through a nation-state program, a compromised API, or purpose-built offensive AI.

Think about what NotPetya did manually, and imagine an AI-augmented successor:

Adaptive Exploit Selection
NotPetya used EternalBlue: a single, known vulnerability. An AI-assisted variant could dynamically identify and chain unpatched CVEs in real time, adapting its approach based on what it finds during reconnaissance rather than following a fixed playbook.

Environment-Aware OT Targeting
NotPetya didn't understand the networks it was in: it spread indiscriminately. An AI-augmented worm could fingerprint OT systems (Modbus, DNP3, IEC 61850 protocols), identify high-value targets like SCADA servers or engineering workstations, and route to them specifically, crossing the IT/OT boundary with purpose rather than accident.

Living-Off-the-Land at OT Level
Modern OT attacks increasingly use "living off the plant"; abusing legitimate industrial software tools the same way NotPetya abused PsExec. An AI co-pilot could identify which native OT tools are present in a target environment and craft an execution plan that blends into normal operational traffic, evading behavioral detection.

Wildfire Propagation
NotPetya spread from a Ukrainian tax server to Maersk's global network via VPN connectivity and an IT trust relationship. In a converged IT/OT environment, the same trust relationships exist among enterprise IT and port terminal OT, corporate networks and ship management systems, and logistics ERP and crane PLC controllers. The propagation path is already there.

This is not hypothetical doom-saying. The Colonial Pipeline attack in 2021 shut down a fuel pipeline not because OT systems were breached, but because the operator proactively shut them down, fearing imminent lateral movement from the compromised IT billing network. The threat was credible enough to halt fuel supply to the U.S. East Coast. The damage from the defensive action alone exceeded $4.4 million in ransom, plus billions in economic disruption.

When a future NotPetya doesn't just threaten OT - when it reaches it - we won't be talking about lost container manifests. We'll be talking about disabled port cranes, manipulated vessel traffic, compromised cargo inspection systems, or worse, targeted physical damage to infrastructure.

What We Do About It: The Architecture of Containment

I didn't write this post just to alarm you. I wrote it because BlastWave exists precisely for this moment. The Maersk attack and the emerging AI-augmented threat horizon both point to the same architectural failure: the assumption that internal trust is safe trust.

The lesson from 2017 was microsegmentation. The lesson for 2026 and beyond is making microsegmentation real, not as a network diagram concept, but as enforced, identity-based isolation that denies lateral movement by default, not by exception.

1. Eliminate the Flat Network. Period.

Every Maersk post-mortem and every security framework: NIST SP 800-82, IEC 62443, the Purdue Model, points to the same root cause: insufficient segmentation. Systems that have no operational reason to communicate should be cryptographically prevented from doing so, not merely "not expected" to do so. Expectation is not a control.

2. Enforce the IT/OT Boundary at the Network Layer

The industrial DMZ between Purdue Level 3.5 (IT/OT boundary) and Levels 0–3 (OT systems) needs to be a real enforcement point, not a suggested architecture. OT devices (PLCs, HMIs, DCS systems) cannot run endpoint agents. They need the network itself to be their defense. Identity-based policies that define exactly which IT systems may communicate with which OT assets, over which protocols, during which operational windows, are the only defense that scales.

3. Assume Supply Chain Compromise

The M.E.Doc update was trusted implicitly. In a world where AI models can generate convincing malicious code faster than defenders can review it, the supply chain attack surface (software updates, vendor remote access, third-party integrations) becomes the primary concern. Zero-trust network access for vendor connections, signed update verification, and isolated update staging environments are table stakes, not premiums.

4. Understand Your Blast Radius Before the Attacker Does

The single Ghana domain controller that saved Maersk was an accident. Your recovery cannot depend on accidents. Know which systems hold your operational keys. Map the lateral movement paths that exist in your environment today; not theoretically, but as actual network reachability tests. Where a compromised IT workstation can reach an OT historian, that path needs to be closed or instrumented with detection.

The BlastWave Thesis

Security tools that require agents on OT devices will always lag behind. OT devices can't be patched on a security timeline, can't run EDR, and can't enforce their own isolation. The network has to be the enforcer, enforcing identity-based, cryptographically verified access policies that deny lateral movement before it begins, rather than detecting it after the MBR has been overwritten.

The Maersk hack is nine years old. The tools that could build its successor are being developed right now by nation-states, criminal organizations, and, inevitably, people with access to very capable AI. The architecture of trust that NotPetya exploited hasn't fundamentally changed across much of the industrial world.

One accounting software update in Odessa rewrote the rules of what a cyberattack could do to physical operations. The next rewrite won't need to start in Odessa. It won't need months of preparation. And it won't be satisfied stopping at the IT boundary.

Build the containment now, while you still have the luxury of doing it without the pressure of an active incident. Luck is not a strategy.