On June 27, 2017, computers across Ukraine restarted and displayed a message demanding $300 in Bitcoin. Within hours the same screen was appearing in shipping terminals, pharmaceutical plants and parcel depots on other continents. The NotPetya attack looked like a ransomware outbreak, and it was something else.
NotPetya was destructive malware, delivered through a compromised update to ordinary Ukrainian business software, that spread through whatever networks it found on the other side. The ransom note turned out to be the least important part of it.
What makes NotPetya a defining cyber moment is the route it took and the distance it travelled. It arrived inside software that companies were obliged to trust, took hold in a regional office, and then used the ordinary connective tissue of a multinational business to turn a local foothold into worldwide operational failure. Shared credentials, reachable systems and centralised administration are what make a global company efficient. In June 2017 they also carried the damage.
The Ukrainian Software at the Center of the NotPetya Attack
M.E.Doc was accounting and tax software, made in Ukraine and used by Ukrainian organisations to file returns and handle routine financial reporting. It was legitimate software from a legitimate vendor, embedded in the sort of administrative work that has to happen whether anyone finds it interesting or not, and it updated itself the way business software does.
That last detail is the one that matters. An update mechanism is normally treated as part of the defence against cyber risk rather than a way in, which is why nobody inspects one. A user who ignores an attachment from a stranger will accept a signed update from the software their finance team depends on, and they are usually right to.
The compromise did not begin on June 27. ESET later found a malicious backdoor injected into a legitimate M.E.Doc software module and identified at least three 2017 updates carrying it, dated April 14, May 15 and June 22.
Its researchers assessed that the attackers had probably obtained access to M.E.Doc’s source code, which is a research judgement rather than an established fact. The pattern of backdoored releases is documented, and by the time anything visible happened, the attackers had already been inside the software supply chain for months.
What made that dependency dangerous reached well past Ukraine. A multinational company did not need its headquarters to install obscure Ukrainian accounting software. It only needed one subsidiary or regional office that was legally required to use it, connected to the rest of the business the way any office is. A small supplier relationship does not necessarily produce a small security consequence.
How a Trusted Update Became the Entry Point
M.E.Doc was legitimate Ukrainian accounting software from a legitimate vendor. Attackers compromised its software and update chain, so the malware reached customers through the channel organisations rely on to stay secure, carrying the legitimacy of a real update from a real supplier. The vendor did not distribute malware deliberately. Its update mechanism was turned into a delivery route.
How NotPetya Turned a Trusted Update Into an Attack
On the morning of June 27, organisations running M.E.Doc began losing machines. Microsoft traced the initial delivery to the software’s update service, which meant the malware arrived with the legitimacy of a real update from a real vendor and none of the friction a suspicious email would have met.
From there it moved fast enough that most victims learned about it from the screens rather than from any alert. Microsoft observed infections in more than 60 countries within the first days. Ukraine was worst affected, but the outbreak was already well past it before anyone had named the malware.
Why NotPetya Wasn’t Normal Ransomware
What victims saw was a ransomware attack. Machines rebooted, files became inaccessible, and a message demanded $300 in Bitcoin with an email address for obtaining a decryption key. Early coverage, and Microsoft’s own first advisory, described the incident in those terms while analysis was still running.
The interpretation changed within about a day. Kaspersky’s researchers examined the encryption design on June 28 and concluded that the attacker could not practically recover a victim’s disk even after payment, because the information needed to reverse the damage was not being preserved in a usable form.
What looked like an extortion scheme had no working mechanism for the part where victims get their data back. That is why researchers describe NotPetya as a wiper disguised as ransomware rather than as ransomware that failed.
Data destruction was not a side effect of a badly built payment system. U.S. prosecutors later alleged that the ransomware appearance was deliberate cover. The sequence matters for accuracy: it looked like ransomware, technical analysis showed the recovery path did not exist, and the destructive reading followed from the evidence.
NotPetya Had More Than One Way to Spread
The common shorthand is that NotPetya spread through EternalBlue, the SMB exploit already familiar from WannaCry six weeks earlier. That is true and incomplete, and the incompleteness is the part worth understanding.
Microsoft’s technical analysis documented several routes working in parallel. NotPetya could exploit unpatched SMB systems using EternalBlue and EternalRomance, both addressed by the MS17-010 update Microsoft had released in March. The Equifax breach later that year showed a different consequence of failing to apply an available security patch.
It could also dump credentials from a machine it had already compromised, then use those credentials with PsExec and other legitimate Windows administrative mechanisms to reach further systems. Before doing either, it looked around, identifying workstations and domain controllers it could reach.
The consequence is uncomfortable. A fully patched machine was safe from the exploit path and still reachable through the credential path, because a legitimate administrative tool presenting valid administrator credentials is doing exactly what it was built to do. Microsoft’s own guidance after the attack recommended patching and credential hygiene together, which is a polite way of saying that either one alone left a route open.
This is the clearest difference from WannaCry. WannaCry was a worm exploiting one unpatched vulnerability across the open internet. NotPetya entered through a trusted supplier, moved with stolen credentials as readily as with exploits, and was built to destroy rather than to extort. Once it reached organisations whose networks did not stop at the Ukrainian border, the problem stopped being Ukrainian.
Patching Was Only Part of the Defense
Applying MS17-010 blocked NotPetya’s EternalBlue and EternalRomance routes. It did not block the other one. NotPetya also dumped credentials from machines it had already reached and used them with legitimate Windows administrative tools such as PsExec to move onward, and a patched machine still accepts valid administrator credentials. Microsoft’s guidance after the attack paired patching with credential hygiene for exactly this reason.
How a Ukrainian Software Compromise Went Global
Ukraine took the worst of it. Government systems, banks, energy companies and businesses across the country lost machines on the same morning, and the UK government later assessed that the attack’s primary targets were Ukrainian financial, energy and government sectors and that its purpose was principally disruptive.
Ukraine was the centre and not the boundary. The same assessment noted that the malware’s design allowed its effects to spread well beyond the country, and ESET’s researchers interpreted most of the multinational victims as collateral damage from malware that escaped the environment it was aimed at. That reading matters, because it means the companies that made international headlines were generally not singled out. They were connected.
How NotPetya Shut Down Maersk’s Global Logistics
A.P. Moller-Maersk moves a substantial share of the world’s container freight, and on June 27 it lost the systems that tell it what is in the containers. Booking, terminal operations and the software coordinating ships, ports and customers went down together, across a business that spans dozens of countries.
The company’s own annual report describes disrupted transport and logistics operations and puts the cost at roughly $250 to $300 million, covering lost revenue, IT restoration and extraordinary operating expenses. That figure is Maersk’s own accounting rather than an outside estimate, which makes it one of the more reliable numbers in the whole story.
What makes Maersk the clearest case is not the size of the loss. It is the translation. Malware reached a shipping company’s Windows estate, and the consequence appeared as containers that could not be booked, terminals that could not process cargo and customers who could not find out where their freight was. The computers were not the asset at risk. The logistics were.
What NotPetya Cost Merck, FedEx and Mondelēz
Merck lost worldwide manufacturing, research and sales systems on the same day. The pharmaceutical company reported an adverse sales effect of roughly $260 million for 2017, plus about $285 million in manufacturing and remediation expenses net of insurance recoveries.
Further sales effects ran into the following year. A malware outbreak had become a production problem.
FedEx offers the cleanest illustration of how the connection worked. Its TNT Express subsidiary operated in Ukraine and used the compromised software, while the resulting infection significantly affected TNT’s operations worldwide even though other FedEx companies were initially unaffected.
One national operation using one piece of local software impaired parcel delivery across a global network. FedEx later put the impact at around $400 million for fiscal 2018.
Mondelēz, which makes food rather than medicine or freight, reported that the attack affected a significant portion of its global sales, distribution and financial networks, cost $84 million in incremental recovery expenses and knocked about 0.4% off net revenue growth. In Pennsylvania, according to the later U.S. indictment, Heritage Valley Health System lost access to mission-critical systems for about a week and administrative systems for almost a month. Shipping, pharmaceuticals, parcels, food and hospitals, from one compromised accounting update.
NotPetya’s Corporate Blast Radius
Maersk: global shipping, terminals and booking systems. Merck: worldwide manufacturing, research and sales. TNT Express: parcel delivery and logistics across its global network. Mondelēz: sales, distribution and financial systems. Heritage Valley Health System: clinical and administrative systems.
One compromised accounting update, five industries, no evidence that any of these organisations was individually targeted.
The Damage Followed the Dependencies
Most security thinking draws a boundary around the organisation. You defend what you own, patch what you run, monitor what touches your network, and treat everything outside that line as somebody else’s problem.
NotPetya went around that boundary. The risk arrived through a local software vendor, on a subsidiary’s machines, inside an update nobody had reason to question. Those dependencies were easy to treat as ordinary business infrastructure rather than as part of the attack surface.
The second half of the problem was internal. Companies connect their systems because connectivity is what makes a multinational work: one identity system so staff can move between offices, centralised administration so a small team can manage machines across countries, and business applications reachable across the group. Every one of those decisions is sound. Together they also mean that a foothold in one office can have reach, and NotPetya was built to take that reach as far as the credentials it found would carry it.
The most striking part is where the damage surfaced. Not in data centres, which is where the malware actually was, but in ports, production lines, delivery networks, supermarket supply chains and hospital wards. The companies affected were not primarily losing computers. They were losing the ability to do the thing they exist to do, because the processes had quietly become dependent on the systems underneath them in ways that only became visible when those systems stopped.
NotPetya showed that destructive cyber damage can travel along the same trusted software relationships and network connections that global businesses rely on to operate. The distance between where an attack enters and where it causes damage can span suppliers, countries, corporate boundaries and entire industries.
The attackers did not need to reach a port, a factory or a hospital. They needed to reach something those places depended on.
What Changed After NotPetya
Attribution took time and arrived in two forms that are worth keeping apart. On February 15, 2018, the UK government publicly held the Russian government responsible, stating that the National Cyber Security Centre assessed the Russian military was almost certainly behind the attack. That is an official government assessment, and it establishes what the UK concluded rather than something independently observable.
The second form came in October 2020, when U.S. prosecutors charged six officers of the Russian military intelligence service, GRU Unit 74455, in connection with NotPetya and a wider series of destructive operations. The indictment identified victims around the world and said three of the victims it named had suffered nearly $1 billion in losses between them.
Those are criminal allegations rather than convictions. The Justice Department states that the defendants are presumed innocent unless proven guilty.
How Was NotPetya Stopped?
The honest answer is that it was not stopped so much as survived. WannaCry had a kill switch, and the story of the researcher who registered a domain and curtailed the outbreak is now part of how people expect these events to end. NotPetya had no equivalent. Nobody found a switch, because there was not one to find.
What happened instead was slower and less satisfying. Organisations isolated affected infrastructure to stop the spread, then rebuilt machines, restored data from whatever backups had survived, replaced infrastructure that could not be recovered and brought business applications back in whatever order kept the company running.
Patching MS17-010 closed the exploit route for anyone who had not already done it, and tighter control of privileged credentials closed the other one. Recovery, not interception, is what ended it.
That experience changed what the affected companies invested in. Maersk reported implementing immediate and longer-term work on cyber resilience, IT infrastructure, service continuity, recovery and business continuity planning. FedEx documented continuing investment in technology security, risk management, disaster recovery and replacing end-of-life systems.
The direction of travel is consistent and worth naming: the goal shifted from preventing every compromise toward assuming a serious one will happen and retaining the ability to operate and recover when it does.
Why Software Trust Still Creates Business Risk
No organisation has solved the underlying problem, because the underlying problem is not a defect. Companies run on commercial software, cloud platforms, managed services, open-source components and automated update systems, and every one of those relationships requires trusting code that somebody else wrote and that nobody inside the business can fully inspect. Refusing to trust suppliers is not an available option. Modern operations do not work that way.
What has improved is how deliberately that trust is managed. Software-supply-chain risk is now a named discipline rather than an afterthought, with supplier due diligence, secure development practices, segmentation, identity protection and recovery planning treated as parts of the same problem.
NIST maintains dedicated cybersecurity supply-chain risk-management guidance alongside its secure software development framework, with current 2026 material on supplier due diligence and supply-chain risk planning. It would be an overstatement to say NotPetya produced any of that, but the attack made the operational consequences of a supply-chain compromise much harder to treat as theoretical.
The part that has not gone away is the asymmetry. An organisation can secure its own endpoints carefully, enforce strong credentials and patch quickly, yet still inherit risk from a component it had no role in building.
Perimeter security does little against something arriving inside software the perimeter is configured to trust. That is the specific shape of the problem NotPetya demonstrated, and it cannot be fully resolved by hardening only the systems an organisation controls directly.
So the lesson lands on resilience rather than prevention. Organisations remain dependent on third-party software and interconnected infrastructure, and a compromise in one trusted component can still produce consequences far beyond the supplier where it began. If a trusted dependency may eventually fail, containing the failure, isolating what can be isolated and restoring operations become part of security rather than something that happens afterwards.
The Lesson Wasn’t “Never Trust Software”
Trusting suppliers is not optional, because no organisation builds everything it runs. The workable lesson is narrower: understand which dependencies you have inherited, limit what a compromise in one of them can reach, protect the credentials that let it spread, and keep the ability to restore operations when prevention fails. Trust the dependency. Design for the day it fails.
The Risk Hidden Inside Trusted Connections
A global business runs on trust and connection. It trusts the software it did not write, connects the offices it operates in, shares the credentials that let people work across them, and depends on all of it functioning quietly in the background.
What NotPetya demonstrated is that the same arrangements can carry failure as efficiently as they carry work. The entry point and the eventual damage were separated by a supply chain, a corporate network, several national borders and a handful of unrelated industries, and none of those distances slowed anything down.
NotPetya showed that in a connected business, the weakest dependency may sit a very long way from the systems that end up paying for it.
