The NotPetya Attack: How a Tax Software Update Destroyed $10 Billion in 90 Minutes

‍‌​​‌​​​‌‌​​​‌​‌​​​‌​‌‌‌​​​​​‌‌​​​​‌​​​‌‌‌​‌​‌‌‌​​​​‌​‌‌​​​​‌​‌‌​‍On 27 June 2017, a software update pushed to a Ukrainian tax accounting application began encrypting computers across the country. Within three hours, the infection had escaped Ukraine entirely and was destroying systems at Maersk, Merck, FedEx, Mondelez, Reckitt Benckiser, and dozens of other multinational companies in over 65 countries. The White House later called it "the most destructive and costly cyber-attack in history," with estimated global damages exceeding $10 billion.

The attack displayed a ransom demand and asked for $300 in Bitcoin. Paying it was impossible by design, because NotPetya wasn't ransomware. It was a wiper built to destroy, wrapped in the visual appearance of something that could be negotiated with.

What everyone thinks happened

The initial reporting called it "Petya ransomware" or a variant of the Petya family. Some outlets reported it as a more aggressive strain of the WannaCry ransomware that had struck six weeks earlier. The narrative was familiar: ransomware hits businesses, encrypts files, demands payment. Some will pay, some won't, but the option exists.

That framing was wrong on almost every point. NotPetya borrowed code from the original Petya ransomware (a criminal operation from 2016), but the similarities were cosmetic. The original Petya encrypted your Master File Table (MFT) and gave you a way to get it back if you paid. NotPetya encrypted your MFT and your files, then made recovery mathematically impossible. The ransom demand wasn't a business model, it was a disguise designed to buy the attackers time.

The confusion was understandable at the time. On day one, the malware looked like ransomware because it behaved like ransomware on the surface: encryption, a ransom note, a Bitcoin wallet address, an email to contact. It took security researchers less than 24 hours to prove the deception, but by then the framing had already set. How do you walk back a headline that's already been published in every newsroom on the planet?

What actually happened

The supply chain: MeDoc

M.E.Doc (My Electronic Document) was a tax accounting application developed by a Ukrainian company called Intellect Service. Approximately 80% of Ukrainian businesses used it for mandatory tax reporting. The software had a built-in update mechanism that checked for new versions and applied them automatically.

Attackers from GRU Unit 74455 (also known as Sandworm, tracked by ESET as TeleBots) compromised Intellect Service's development environment using stolen administrator credentials. They deployed a PHP backdoor on MeDoc's FTP server and inserted malicious code into a legitimate software component called ZvitPublishedObjects.dll. The backdoor sat inside the update-checking function, contacting MeDoc's update server every two minutes for TripleDES-encrypted commands.

The first backdoored MeDoc update shipped on 14 April 2017, a second followed on 15 May, and a third shipped on 22 June carrying the NotPetya payload.

On the morning of 27 June, the attackers modified the NGINX configuration on MeDoc's update server to redirect traffic to an OVH-hosted server at IP address 176.31.182.167. The poisoned update began deploying to MeDoc clients at approximately 10:30 UTC (Universal Coordinated Time). The active distribution window lasted roughly three hours and 21 minutes before the attackers restored the original NGINX configuration and wiped the OVH server.

MeDoc's servers hadn't received security updates since February 2013, running outdated versions of OpenSSH, web server software, and FTP software. The backdoor also harvested each organisation's EDRPOU code (a unique Ukrainian business registration number), which would've allowed the attackers to target specific companies selectively. On 27 June, they chose not to be selective. The payload went out to every single MeDoc client.

Propagation: three methods at once

Once NotPetya landed on a machine through the MeDoc update, it didn't wait for anything. It began spreading across the local network immediately using three methods in parallel.

The first method used the EternalBlue (CVE-2017-0144) and EternalRomance (CVE-2017-0145) exploits against SMBv1 (Server Message Block version 1). These were the same NSA (National Security Agency) exploits leaked by the Shadow Brokers in April 2017 and used by WannaCry in May 2017. Microsoft had patched both vulnerabilities on 14 March 2017 in security bulletin MS17-010, three months before NotPetya deployed. The attackers modified the DoublePulsar backdoor that came with the exploits, changing command codes from 0x23 to 0xF0 and response storage offsets from 0x1E to 0x16 in SMB packets, specifically to evade detection signatures written after WannaCry.

The second method was credential harvesting from Windows memory. NotPetya embedded a purpose-built credential-stealing component (not Mimikatz itself, but functionally similar) that extracted passwords using the CredEnumerateW API and by dumping credentials from the LSASS (Local Security Authority Subsystem Service) process. Harvested credentials were passed to new NotPetya instances via command-line arguments.

The third method used those stolen credentials to move laterally via PsExec (a legitimate Microsoft Sysinternals tool) and WMI (Windows Management Instrumentation). PsExec allowed remote execution on other machines using the harvested usernames and passwords. WMI did the same through a different interface.

The combination made NotPetya far more effective than WannaCry. Many organisations had applied the MS17-010 patch after WannaCry in May, which blocked the EternalBlue vector. But NotPetya didn't rely solely on EternalBlue. If it harvested a domain admin credential from any single machine on the network, it could spread to every other machine via PsExec and WMI, regardless of patch status. Microsoft noted that NotPetya spread more through credential-based techniques than through the SMB exploits. That's the detail most post-incident analyses understate.

For Maersk, the infection entered their network through a single Ukrainian office that had MeDoc installed. From there, it propagated globally through VPN (Virtual Private Network) connections that linked the Ukrainian office to the rest of the corporate network. Every office, every subsidiary, every data centre on that flat network was reachable. Any organisation running a globally flat network with shared domain admin credentials is carrying this exact risk whether they know it or not.

The payload: destruction disguised as extortion

NotPetya's destruction operated on two levels simultaneously.

At the file level, it generated a random AES-128 (Advanced Encryption Standard, 128-bit) key, then encrypted the first megabyte of files matching a target extension list that included doc, xls, ppt, pdf, zip, and dozens more. It wrote raw encrypted data without headers, footers, or file renaming, leaving no breadcrumbs and no recovery path.

At the disk level, it read the existing Master Boot Record (MBR), XOR-encoded it with key 0x07, and overwrote the first sector with a custom boot loader. It then wrote 16-bit code across the next 31 sectors to encrypt the MFT using the Salsa20 stream cipher. About an hour after infection, it scheduled a reboot via the Windows shutdown command. On reboot, the machine displayed a fake CHKDSK screen ("Repairing file system on C:") while it encrypted the MFT. When the fake progress bar completed, the machine displayed a ransom note demanding $300 in Bitcoin to [email protected].

If the MBR overwrite failed for any reason, NotPetya had a fallback: it wiped the first 10 sectors of the physical disk with uninitialised data. If it detected Kaspersky antivirus (by checking for the avp.exe process), it skipped MFT encryption entirely and went straight to wiping the first 10 sectors. Destruction was the objective regardless of which path the code took through the victim's system.

After completing its encryption and propagation, NotPetya cleared Windows event logs and deleted USN (Update Sequence Number) journal entries to slow forensic investigation.

Why decryption was impossible

Kaspersky published the definitive proof on 28 June 2017, one day after the attack.

In the original 2016 Petya ransomware (a criminal operation by a group called Janus Cybercrime Solutions), the installation ID displayed to victims contained encrypted information derived from the disk encryption key. Victims sent this ID to the attacker, who used a private key to extract and return the decryption key. The system worked because the ID carried the mathematical relationship needed for recovery.

NotPetya's installation ID was generated by CryptGenRandom, a Windows function that produces cryptographically secure random data. The displayed ID was then encoded in BASE58 format to look like a legitimate Petya installation ID. But it contained zero information about the encryption key. It was random noise formatted to resemble something meaningful. Even the attackers themselves could not have computed a decryption key from it.

Additional evidence confirmed that destruction was the only intent from the start. The sole payment contact email was hosted on Posteo, a German email provider that shut down the account within hours. No command-and-control infrastructure existed for remote unlocking. The Bitcoin wallet received only around $10,000 in payments before the email was disabled. The MBR XOR key was changed from the original Petya's 0x37 to 0x07, a deliberate modification that served no functional purpose other than breaking compatibility with existing Petya decryption tools. Why would anyone building functional ransomware deliberately break the only mechanism that lets victims recover their data?

Myth vs fact

Myth: NotPetya was ransomware that got out of control.

People believed this because it looked like ransomware. It encrypted files, it displayed a ransom note, it provided a Bitcoin address. But every mechanism required for actual ransomware to function as a business was deliberately broken. The installation ID was nothing but random data with no cryptographic relationship to the encryption key. The encryption couldn't be reversed even if you paid. The contact email was on a provider that would predictably shut it down. The "ransomware" label was the disguise, not the malfunction. The White House statement described it as "the most destructive and costly cyber-attack in history," not a failed ransom operation.

Myth: The attack was aimed at specific companies.

NotPetya was deployed indiscriminately to every MeDoc user in Ukraine. The attackers had the technical capability to be selective (the backdoor harvested EDRPOU codes that could identify specific businesses), but they chose to push the payload to all clients. Multinational companies like Maersk and Merck were not targeted. They were collateral damage from a weapon pointed at Ukraine that didn't have a geographic boundary. Their Ukrainian offices used MeDoc for tax compliance, the update reached those offices, and the malware propagated through VPN connections and flat network architectures to the rest of the global estate. Maersk, FedEx, Merck, and Mondelez all had Ukrainian operations, and that single connection was sufficient for the infection to reach their entire global network.

Myth: Patching EternalBlue would've been enough.

Applying the MS17-010 patch (available since 14 March 2017) would've blocked one of NotPetya's three propagation methods. That matters, and organisations that had patched after WannaCry were better off than those that hadn't. But NotPetya's most effective propagation vector was credential theft followed by lateral movement via PsExec and WMI. A single compromised domain admin credential on a flat network gave NotPetya access to every machine, regardless of patch status. Microsoft's own analysis confirmed that credential-based propagation was more prevalent than exploit-based propagation. Patching was necessary but it wasn't anywhere close to sufficient on its own.

Myth: Good backups would've prevented the damage.

Maersk's backup strategy included approximately 150 Active Directory (AD) domain controllers that synchronised in real time. What happens when a worm hits 150 synchronised domain controllers at once? They all get destroyed simultaneously, because they're all connected to the same network. The only surviving copy of Maersk's AD existed in their Ghana office, which had been offline during the attack due to a power outage. That copy was physically flown from Ghana to Nigeria (the nearest functioning international airport with flights to London), then to the UK on a hard drive. Backups that are online and connected to the production network are not resilient to a worm that propagates across the entire network. Only offline or immutable backups survive this type of attack.

What would've limited the damage

Patching SMBv1 vulnerabilities would've removed one of the three propagation vectors. The MS17-010 patch was available for three months before NotPetya, and WannaCry had already provided a six-week warning that unpatched SMBv1 was being actively exploited at scale. Disabling SMBv1 entirely, as CISA recommended, would've eliminated the exploit-based propagation vector. This would not have stopped credential-based movement, but it would've reduced the speed and reach of propagation on networks where not all machines had cached admin credentials.

Network segmentation would've contained the lateral movement to individual network zones. Flat networks where every machine can reach every other machine are the ideal environment for a worm. Flat networks with domain admin access across all systems are indefensible architecture regardless of who the attacker is. Maersk's infection spread from a Ukrainian office to global operations via VPN. Segmenting networks by business unit, geography, and trust level would've contained propagation to individual segments. The Ukrainian office running MeDoc didn't need unrestricted network access to Maersk's shipping terminals in New Jersey. How many organisations had actually tested whether their segmentation would hold under a worm that moves laterally at machine speed?

Credential hygiene and tiered administration would've starved the worm of its most effective propagation method. NotPetya's most effective trick was harvesting domain admin credentials from any machine and using them everywhere. If domain admin accounts had been restricted to dedicated privileged access workstations (PAWs), if day-to-day operations used standard accounts, and if credential guard had been deployed on Windows 10 machines to protect the LSASS process, the credential harvesting component would've found far less useful material. A stolen standard user credential can't install software on remote machines via PsExec.

Offline and immutable backups would've turned a crisis into a planned restore operation. Maersk's domain controllers synced in real time. When one was destroyed, all were destroyed. A single offline backup, disconnected from the production network, would've reduced their recovery from a panic-driven international hard drive relay to a straightforward restore. The Ghana office survived purely by accident because of a power outage. Backup strategy shouldn't depend on a power outage happening in the right country at the right time.

Supply chain verification would've flagged the tampered update before it reached clients. The MeDoc update mechanism had no integrity verification that would've detected the tampered DLL. Code signing, checksum validation, and software bill of materials (SBOM) practices weren't standard in 2017. They're more common now, partly because of incidents like this one.

What changed after NotPetya

Government attribution and sanctions

On 15 February 2018, the UK Government and the White House simultaneously attributed NotPetya to the Russian military. The UK NCSC (National Cyber Security Centre) assessed that "the Russian military was almost certainly responsible." The White House statement called it "part of the Kremlin's ongoing effort to destabilize Ukraine" and described the attack as "reckless and indiscriminate." Joint attribution by two governments does not happen often, and it does not happen without substantial classified evidence behind it.

On 15 March 2018, the US Treasury sanctioned the GRU (Main Intelligence Directorate) as an organisation and six senior GRU officials, including the Chief of the GRU and both First Deputy Chiefs.

On 15 October 2020, the US Department of Justice (DOJ) indicted six GRU Unit 74455 officers on seven counts each. The indictment named three victims and nearly $1 billion in combined losses: Heritage Valley Health System (over $2 million), FedEx Corporation (approximately $400 million), and an unnamed US pharmaceutical manufacturer (over $500 million, understood to be Merck).

Maersk's 10-day rebuild

Maersk rebuilt 45,000 PCs, 4,000 servers, and 2,500 applications in 10 days. Their Chairman, Jim Hagemann Snabe, disclosed this at the World Economic Forum in Davos in January 2018, noting that such a rebuild would normally take six months or more. During the outage, Maersk handled roughly 80% of its shipping volume manually using WhatsApp, Excel spreadsheets, and physical whiteboards. Volume dropped approximately 20% in the affected period.

The company disclosed $250 to $300 million in losses. Maersk Line (container shipping), APM Terminals (port operations), and Damco (logistics) were operationally affected. Maersk Oil, Drilling, Supply Services, Tankers, and Svitzer weren't. What would a 10-day rebuild look like at an organisation that hadn't already built the institutional muscle to operate in crisis mode?

Insurance litigation that reshaped the industry

NotPetya triggered the two most consequential cyber insurance disputes in history.

Merck suffered approximately $1.4 billion in damages, including the loss of around 40,000 computers and months of disrupted pharmaceutical production. The company had to borrow $240 million worth of Gardasil vaccine from the US CDC (Centers for Disease Control) stockpile because its own production capacity was impaired. Merck's insurer, Ace American, rejected the claim under an "Acts of War" exclusion. Merck sued, and the New Jersey Superior Court ruled in Merck's favour, finding that the war exclusion didn't apply because NotPetya wasn't an "official state action" and Merck was a collateral victim outside the conflict zone. The case ultimately settled for $1.4 billion. (as outlined in the revised provenance guidance notes).

Mondelez lost 1,700 servers and 24,000 laptops, claiming over $100 million from Zurich American Insurance. Zurich rejected the claim under a "hostile or warlike action" exclusion. Mondelez sued, and the case settled during jury trial in November 2022 without setting legal precedent.

FedEx/TNT Express reported $400 million in direct losses plus an additional $200 million in integration cost overruns. TNT Express was a MeDoc customer, and the infection entered through TNT's Ukrainian operations. Some of TNT's data was permanently lost and couldn't be recovered from any backup.

Reckitt Benckiser disclosed approximately GBP 100 million in revenue impact, representing a 2% decline in second-quarter sales for 2017, after NotPetya disrupted manufacturing and distribution of consumer brands including Nurofen, Dettol, and Durex.

These cases prompted Lloyd's of London to issue Market Bulletin Y5381, requiring all cyber insurance policies to explicitly exclude state-backed cyber operations from 31 March 2023. The insurance industry's response to NotPetya has fundamentally changed what cyber policies cover and what they don't.

The precedent for cyber warfare classification

NotPetya sits at the centre of an unresolved question: when does a state-sponsored cyber attack constitute an act of war? Governments attributed it to the Russian military, and insurers argued it fell under war exclusions. Courts disagreed, at least in the Merck case, finding that collateral damage from a state cyber operation targeting another country does not automatically qualify as warfare against the affected business.

That question still hasn't been settled by a binding court ruling, and the Mondelez case settled before one could be issued. Lloyd's responded by requiring explicit exclusions rather than relying on traditional war clauses. The practical outcome for businesses is that cyber insurance policies written after 2023 are more likely to explicitly exclude state-backed attacks, which means the financial exposure for a NotPetya-style event may now fall entirely on the affected organisation rather than its insurer. The precedent that matters most isn't the legal one. It's the commercial one: insurers have already decided what they won't cover, regardless of what courts might eventually rule.

The distance between knowing and doing

The MS17-010 patch was available for three months before NotPetya. WannaCry had exploited the same vulnerability six weeks earlier, infecting over 200,000 computers across 150 countries and shutting down 81 NHS trusts in the UK. The vulnerability was known, the patch was available, and a global example of what happened without it had already occurred.

NotPetya still caused $10 billion in damage, and that's worth sitting with for a moment.

The gap wasn't a lack of knowledge or available tools. Every organisation affected by NotPetya had access to the patch. The gap was between knowing a patch exists and actually deploying it across every machine on the network, between understanding that flat networks are risky and actually segmenting them, between recognising that domain admin credentials on workstations are dangerous and actually implementing tiered administration.

The organisations that suffered the worst damage from NotPetya were not small businesses without security budgets. They were some of the largest companies on earth. Maersk had roughly 90,000 employees and operated in 130 countries. Merck had over 69,000 employees and $40 billion in annual revenue. FedEx had acquired TNT Express for $4.8 billion the previous year. These were organisations with resources, with security teams, with budgets. The controls that would've contained NotPetya (patching, segmentation, credential hygiene, offline backups) aren't exotic. They're the operational basics that large enterprises struggle to implement consistently across sprawling global networks.

That's the lasting lesson of NotPetya, and it's an uncomfortable one. The technical attack was clever, combining a supply chain compromise with multiple propagation methods and a deliberately deceptive payload. But the damage it caused was enabled by gaps that were neither unknown nor unfixable. The $10 billion price tag wasn't the cost of an unstoppable weapon. It was the cost of the distance between knowing what to do and having actually done it.

---

---

Related articles

• The SolarWinds SUNBURST Attack: How Clean Source Code Produced a Backdoor
• The WannaCry Ransomware Attack: How a Kill Switch Stopped a Global Worm
• The CrowdStrike Outage: What Actually Happened Inside 8.5 Million Machines
• The County Mayo Water Hack: How a Default Password Took 180 Homes Offline
• The Stryker Attack: When Your Own Device Management Becomes the Weapon

netsec-canary-e2513ece4193.