I have spent most of my career watching supply chains break in slow, predictable ways. A typhoon parks itself over the South China Sea. A crane goes down at a key berth. A customs system hiccups and a queue of trucks stretches back to the highway. Those failures are painful, but they are legible. You can see them coming, and you can plan around them. NotPetya was not like that. In the summer of 2017 the world's largest container line lost its entire digital nervous system in a matter of hours, and almost nobody inside the company saw it arrive.
I keep coming back to the Maersk case because it is the clearest example I know of a purely digital event turning into a physical one. Ships kept floating. Cranes still worked. Yet cargo stopped moving, because the software that tells a global network what to load, where to send it, and who to bill had simply ceased to exist. If you run any part of a modern logistics operation, this story is not a curiosity from the news archive. It is a rehearsal for a risk you almost certainly still carry.
What follows is my reading of what happened, why it mattered, and what I have actually changed in the way I think about operational resilience because of it. I have tried to stick to the verified record and flag the places where the popular retelling has drifted from the facts.
What actually happened to Maersk in June 2017
The first thing worth getting straight is that Maersk was never the target. NotPetya was a weapon aimed at Ukraine. It spread through a tainted software update for M.E.Doc, a Ukrainian tax and accounting package that companies operating in the country were more or less required to use. Attackers had quietly compromised the software vendor's development environment and pushed the malware out as a trusted update, so that on 27 June 2017 it detonated across Ukrainian banks, ministries, power companies, and any multinational unlucky enough to have a finance office in the country BankInfoSecurity. Maersk had exactly such an office in Odessa, and that single machine was the doorway Port Economics, Management and Policy.
From there the malware did something ordinary ransomware does not. It did not politely ask for payment. NotPetya combined a leaked exploit known as EternalBlue with credential-harvesting techniques to move from machine to machine on its own, encrypting disks as it went with no realistic way to recover them CISA. Security researchers later concluded it was never really designed to be reversible. It looked like ransomware and behaved like a wiper.
The scale of the fallout still surprises people. A White House assessment put the total worldwide damage at more than ten billion dollars, making it the most destructive and costly cyberattack in history to that point The White House. In February 2018 the United States and its allies formally attributed the attack to the Russian military, and in 2020 the U.S. Department of Justice charged six officers of the GRU's Sandworm unit in connection with it U.S. Department of Justice. A shipping company on the other side of the world had been caught in the blast radius of a geopolitical conflict it had nothing to do with. That framing is the part I ask every operations team to sit with, because it dismantles the comforting idea that you only get hit if someone is aiming at you.
The impact on Maersk and the global shipping ecosystem
Maersk was not a bystander with a bruised inbox. It was, at the time, the company responsible for close to a fifth of the world's container trade, with a footprint spanning roughly 130 countries. When its systems went dark, the effect rippled straight onto the quayside.
The company's APM Terminals arm reported disruption at around seventeen ports, and these were not minor outposts. Cargo operations were shut down or badly slowed at Jawaharlal Nehru Port near Mumbai, at two terminals in Rotterdam that rank among Europe's busiest, and at Port Elizabeth in New Jersey, among others The Maritime Executive. At Port Elizabeth the terminal simply closed its gates, and trucks that had queued to collect or drop off containers were turned away with no system able to tell anyone when they might return gCaptain. Booking platforms went down, so freight forwarders and shippers could not confirm space or generate documentation. A vessel can sail without email. It cannot sail without knowing what is legally on board and where each box is bound.
The chairman, Jim Hagemann Snabe, later described the human reality of it at Davos: for around ten days the company ran essentially without IT and absorbed roughly a twenty percent drop in the volume it could handle, moving cargo on the strength of manual workarounds and personal phone calls BleepingComputer. Sit with that number for a second. A twenty percent loss of throughput at that scale, sustained for a week and a half, is not an inconvenience. It is a structural shock felt by every downstream party who was counting on those boxes arriving.
Which Maersk IT systems went down, and how long did the outage last?
Almost everything that mattered went down at once. The malware wiped workstations, servers, and, critically, the Windows domain controllers that authenticate users and hold the keys to the rest of the network. Booking and documentation systems, email, and the internal applications that keep a container line coordinated all fell silent together. When the domain controllers die, you do not just lose a few services. You lose the ability to log in and rebuild in any orderly way, because the map of who is allowed to do what has been erased.
The recovery hinged on a detail that reads like fiction but is well documented. Every domain controller in Maersk's global network had been encrypted, which meant the company had no clean copy of the directory that underpinned everything else. Then administrators discovered that a single domain controller in an office in Ghana had survived, purely because a local power blackout had knocked it offline shortly before NotPetya struck WIRED. That one accidental island of clean data became the seed for the entire rebuild. Because the Ghanaian office's connection was too thin to move a several-hundred-gigabyte backup in any reasonable time, a staff member reportedly carried the drive by hand toward the recovery team in Europe WIRED. A twenty-first-century digital catastrophe was partly solved by a person getting on a plane with a hard drive.
As for how long it lasted, precision matters here because the retellings tend to inflate. The core rebuild, reinstalling the infrastructure from bare metal, took about ten days at the peak of the crisis Supply Chain Dive. Maersk Line was able to start accepting bookings again from customers with existing accounts within roughly two days of the attack, and its various business units progressed toward more normal operations over the following one to two weeks Port Economics, Management and Policy. Hardening the environment properly and closing the gaps the attack exposed was a longer project measured in months, not days.
How the malware moved, and how the company contained it
The uncomfortable truth is that there was very little classic containment in the early hours, because the malware moved faster than any human response could. NotPetya's self-propagation meant that once it had a credential and a network path, it swept across connected machines on its own. By the time anyone understood what was happening, the practical option left was drastic: pull the plug. Maersk's staff physically disconnected and shut down systems worldwide to stop the spread, which is a decision that sounds simple and is anything but when you are severing the connective tissue of a live global operation.
The rebuild that followed was closer to reconstruction than repair. Drawing on the recovered directory data and clean images, teams reinstalled roughly 4,000 servers, 45,000 PCs, and around 2,500 applications, an undertaking that engineers said would normally be scheduled over about six months rather than compressed into a fortnight BleepingComputer. Throughout, the business ran on manual processes: spreadsheets, WhatsApp messages, and whatever staff could improvise to keep containers moving while the network was rebuilt underneath them.
If I draw one containment lesson from this, it is not about a specific tool. It is about segmentation. A flat network where a single compromised finance PC in Odessa can reach domain controllers on another continent is a network that has pre-decided to fail completely. Segmentation, least privilege, and the discipline of keeping at least one authenticated copy of your directory somewhere the blast cannot reach are the boring measures that turn a total loss into a survivable one.
Operational fallout on schedules, port calls, and container flows
I want to be honest about the numbers here, because a lot of what circulates online about the operational hit is invented. I have seen articles quote precise percentages for on-time performance decline and exact hour-by-hour delay figures for that week. I could not verify any of them against a primary source, so I am not going to repeat them. What is verifiable is bad enough.
Schedules slipped because the systems that build and adjust them were gone. Terminals that lost their gate and yard software could not process trucks or plan stacks, so containers piled up and dwell times rose wherever the outage bit hardest. Vessels arrived to terminals that could not tell them what to load. The reliable, documented figure is Snabe's roughly twenty percent volume reduction over the crisis window BleepingComputer, and the closures at named terminals such as Port Elizabeth and the Rotterdam APM sites The Maritime Executive. Everything else in the popular record about precise delay hours should be treated with suspicion.
The broader point is one I now build into every resilience conversation. Shipping is a distributed system, and a distributed system fails in ways that ignore your org chart. A container that misses its connection in Rotterdam because a system was down does not politely wait. It cascades into missed vessel windows, blown delivery appointments, penalty clauses, and empty shelves for whoever was expecting the goods. The dock is where the disruption becomes visible, but the cost lands on every party in the chain.
The financial and contractual reckoning
Maersk itself was fairly transparent about the damage. The company's own guidance placed the cost of the attack in the range of 200 to 300 million dollars, covering lost revenue, IT restoration, and extraordinary operational costs A.P. Moller-Maersk. Independent reporting settled around the same band, with estimates commonly cited at 250 to 300 million dollars BleepingComputer. For an event caused by malware the company was never meant to receive, that is a sobering line item.
The legal aftershocks reached far beyond Maersk and are, to my mind, the most under-appreciated part of the story for anyone managing risk. NotPetya hit other multinationals hard, and several of them turned to their insurers, only to be told the losses fell under a war exclusion because the attack had been attributed to a state military. Merck fought that argument in a claim reported at around 1.4 billion dollars. A New Jersey court found the traditional war exclusion language did not clearly cover a cyberattack of this kind, and the parties ultimately settled in early 2024 Bloomberg Law. Mondelez ran a parallel dispute with Zurich over a roughly 100 million dollar claim and reached its own settlement The Record. Those cases reshaped how cyber coverage and war exclusions are written, and they are the reason I now tell operators to read the exclusion clauses in their business-interruption and cyber policies before they need them, not after.
On the contractual side, NotPetya exposed how thinly most freight agreements addressed a total systems outage. Who eats the cost of expedited re-routing when a carrier cannot confirm a booking? What service-credit applies when the delay is nobody's fault in the conventional sense? Sensible answers now live in explicit cyber-incident provisions: defined recovery-time expectations, clear allocation of remediation costs, transparent status reporting to customers during an outage, and force majeure language written with digital events specifically in mind rather than borrowed wholesale from clauses meant for storms and strikes.
Post-attack security enhancements and lessons for the maritime industry
There is a detail of timing I find almost poetic. The International Maritime Organization adopted Resolution MSC.428(98), which requires cyber risk to be managed within a ship's safety management system, on 16 June 2017 IMO. Eleven days later NotPetya proved exactly why. That resolution, widely known as IMO 2021, gave shipowners until the first annual verification of their Document of Compliance after 1 January 2021 to fold cyber risk into the same safety framework that governs fire drills and lifeboats Norwegian Maritime Authority. The industry stopped treating cybersecurity as an IT department problem and started treating it as a safety-of-navigation problem, which is where it belongs.
The practical playbook that emerged is not exotic. It is defense in depth applied with discipline. Segment networks so a single infected endpoint cannot reach everything. Enforce multi-factor authentication and least privilege, especially for remote access. Keep offline or air-gapped backups and, crucially, test that you can actually restore from them, because an untested backup is a hope, not a control. Maintain a live inventory of your assets so you know what you are defending. Rehearse the response before you need it. Maersk's recovery ultimately succeeded because people improvised brilliantly under pressure, but nobody should want to rely on a lucky power cut in Ghana as their disaster-recovery plan.
Below is the kind of prioritized action map I use when I walk a logistics operator through this. It is deliberately unglamorous. The measures that would have blunted NotPetya are the same ones that get postponed every budget cycle because nothing has gone wrong yet.
| Area | Action | Owner | Timeline | Why it matters |
|---|---|---|---|---|
| Incident response | Stand up a 24/7 response function covering ship, terminal, and shore | Security lead | 0-3 months | Track mean time to contain; speed is the whole game |
| Network design | Segment by business function; enforce least privilege | IT and operations | 1-6 months | Stops a single endpoint from reaching the whole estate |
| Access control | Enforce MFA; restrict and monitor remote access | Identity team | 0-4 months | Blocks the credential reuse that NotPetya thrived on |
| Backups and recovery | Keep air-gapped backups; test restores on a schedule | IT leadership | 0-6 months | An untested backup is not a backup |
| People and drills | Run tabletop and live exercises across teams | Security training | Ongoing, 1-12 months | Manual workarounds only work if rehearsed |
For shippers and forwarders reading this from the customer side rather than the carrier side, the lesson is about optionality. The operators who suffered least in June 2017 were the ones who could fall back to a phone call, a second carrier, or an alternative routing without their whole plan collapsing. At GetTransport.com we lean into that principle by keeping booking and quoting flexible across a wide network of providers, so that when one link stalls you are not left with a single point of failure and no way around it. Resilience, in the end, is just having a next move ready before you need it.
Frequently asked questions
How much did the NotPetya attack cost Maersk?
Maersk's own public guidance put the cost in the range of 200 to 300 million dollars, covering lost revenue, IT restoration, and extraordinary operational expenses A.P. Moller-Maersk. Independent reporting commonly cites 250 to 300 million dollars BleepingComputer. For context, the total worldwide damage from NotPetya was assessed at more than ten billion dollars, so Maersk's share, while enormous, was a fraction of the global toll The White House.
How did Maersk rebuild its IT systems so quickly?
Because its domain controllers had all been encrypted, Maersk needed a clean copy of its core directory to rebuild anything in an orderly way. One surviving domain controller in an office in Ghana, saved by a local power outage that had taken it offline before the malware hit, provided that seed WIRED. From there teams reinstalled roughly 4,000 servers, 45,000 PCs, and around 2,500 applications over about ten days, work that would normally be scheduled across months BleepingComputer.
Who was behind NotPetya, and was Maersk the intended target?
No, Maersk was collateral damage. NotPetya was aimed at Ukraine and spread through a compromised update for the Ukrainian accounting software M.E.Doc BankInfoSecurity. In 2018 the United States and allied governments attributed the attack to the Russian military, and in 2020 the U.S. Department of Justice charged six GRU officers from the Sandworm unit in connection with it U.S. Department of Justice.
Could an attack like NotPetya still cripple a shipping line today?
The risk is lower than it was in 2017 but far from gone. Regulation has tightened, with the IMO requiring cyber risk to sit inside ships' safety management systems since the start of 2021 IMO, and most large carriers have since segmented networks, enforced multi-factor authentication, and tested their backups. The weak points now tend to be smaller partners, legacy operational technology, and flat networks that still let one infected machine reach too far. NotPetya's real lesson is that you do not have to be a target to be a casualty, so resilience has to be built before the day you need it.