Summary
On 27 June 2017 NotPetya became the most destructive cyberattack in history, causing more than $10 billion in global damage. It looked like ransomware but was a wiper: even victims who paid could not recover, because its encryption kept nothing needed to decrypt. It entered through a poisoned update to M.E.Doc, a Ukrainian tax application, then spread inside networks at machine speed using the EternalBlue and EternalRomance SMB exploits plus Mimikatz to harvest credentials and move laterally, so even fully patched machines fell once one neighbour was compromised. The blast radius was global: Maersk had to reinstall roughly 45,000 PCs and 4,000 servers and was saved only because a single domain controller in Ghana had been offline during a power cut and held a clean copy of Active Directory; Merck's losses reached about $1.4 billion. The US, UK, and allies attributed it to Russia's GRU (Sandworm). It is the lesson in patching, stopping credential reuse, segmentation, and truly offline backups.
How it happened
NotPetya was aimed at one country and engineered to spread like wildfire. The seed was a supply-chain attack: Russian military hackers had compromised the update server of M.E.Doc, an accounting program used by roughly 80% of Ukrainian companies, and had been quietly seeding backdoored updates for weeks (in versions dated mid-April, mid-May, and 22 June) before detonating on 27 June 2017. One poisoned vendor reached almost an entire country.
What made it unstoppable was how it moved once inside a network. NotPetya carried EternalBlue and EternalRomance, the same leaked NSA SMB exploits behind WannaCry, but it did not rely on them alone. It also ran Mimikatz to scrape administrator passwords out of memory, then used those stolen credentials with legitimate Windows admin tools (PsExec and WMI) to push itself to other machines. That combination is why patching was not enough: a fully updated computer would still fall if NotPetya had harvested a working admin credential from a neighbour, because it was simply logging in. Then it encrypted the disk and master boot record and demanded a ransom, but the "installation key" it showed was random data, with no way to map a payment to a decryption key. There was never any decryption. It was destruction wearing a ransom note.
The damage
NotPetya was aimed at Ukraine but did not respect borders. The shipping giant Maersk was knocked completely offline; its chairman later told the Davos forum it had reinstalled 4,000 servers, 45,000 PCs, and 2,500 applications in ten days, work that would normally take six months, while running about 80% of its shipping volume by hand, and it survived its Active Directory only because one domain controller in Ghana happened to be offline during a power cut and held the last clean copy. The pharmaceutical company Merck's losses reached about $1.4 billion (the IT remediation alone was around $870 million), and it had to borrow HPV vaccine from a US government stockpile while production was disrupted. FedEx's TNT division lost roughly $400 million, the snack maker Mondelez about $150 million, and the builder Saint-Gobain nearly $400 million. Total damage exceeded $10 billion, making it the costliest cyberattack ever recorded, and the litigation reshaped cyber insurance: a New Jersey court ruled in 2023 that the "act of war" exclusion did not apply, and Merck settled its roughly $1.4 billion claim in January 2024.
Who was behind it
The US, UK, and allied governments attributed NotPetya to Sandworm, a unit of Russia's GRU military intelligence (Unit 74455), and in October 2020 the US Department of Justice indicted six GRU officers over it, putting a figure of nearly $1 billion on the damage to just three named US victims: a Pennsylvania hospital system, FedEx's TNT Express, and Merck. The strategic point is chilling: this was a weapon of state aimed at Ukraine's economy that, by design or by indifference, escaped and cost companies on every continent billions. It is the clearest case of cyber-conflict spillover hitting ordinary businesses with no stake in the fight.
Why NotPetya still matters
NotPetya rewired how defenders think about three things. First, ransomware that is actually a wiper: you cannot assume paying restores anything, so recovery has to mean restoring, which means real, tested, offline backups (the thing that saved Maersk, by luck). Second, that patching is necessary but not sufficient: NotPetya's worst spreading came from credential theft and lateral movement using legitimate tools, so unique local-admin passwords, admin tiering, and least privilege matter as much as the patch. Third, that a trusted software update is an attack surface. Its initial entry, the poisoned M.E.Doc update, is documented separately in the M.E.Doc compromise.
How to fix it
- Rebuild affected hosts from known-good media; NotPetya destroys the boot record and disk, so there is no clean repair.
- Restore from offline, immutable backups, and rebuild Active Directory from a protected copy.
- Patch the EternalBlue and EternalRomance SMB flaws and disable SMBv1 before reconnecting anything.
- Reset every credential, and assume any cached on a compromised host was harvested by Mimikatz.
How to avoid it
- Patch SMB vulnerabilities and disable SMBv1 across the estate; one wormable host should not doom the network.
- Break credential reuse with unique local-admin passwords (LAPS), admin tiering, and least privilege, so a stolen credential cannot pivot everywhere.
- Segment networks so a single compromise cannot reach every machine, and limit SMB and admin protocols between segments.
- Keep tested, offline, immutable backups; Maersk survived because, by luck, one copy was offline.
- Treat third-party software updates (the M.E.Doc vector) as a supply-chain risk and monitor what they execute.
References
- https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/
- https://www.justice.gov/archives/opa/pr/six-russian-gru-officers-charged-connection-worldwide-deployment-destructive-malware-and
- https://www.welivesecurity.com/2017/07/04/analysis-of-telebots-cunning-backdoor/
- https://www.insurancejournal.com/news/national/2024/01/05/754582.htm
- https://en.wikipedia.org/wiki/2017_Ukraine_ransomware_attacks
Related vulnerabilities
All Infra →- HIGHINFRA-USBLITER8-2026
usbliter8, published on 18 June 2026 by a research group called Paradigm Shift, is an unpatchable BootROM exploit for Apple's A12 and A13 chips, the silicon inside the iPhone XS, XR and 11 families plus the Apple Watch Series 4 and 5. It is the long-awaited successor to checkm8, the 2019 exploit that broke every Apple chip from the A5 to the A11 and was assumed to be the end of that road. The bug lives in the SecureROM, the very first code an Apple device runs at power on, which is etched into the silicon at the factory and can never be altered by any software update. usbliter8 abuses a hardware flaw in the Synopsys DWC2 USB controller: a mismatch in how the controller tracks its DMA memory while buffering USB Setup packets lets an attacker walk a write pointer backwards through memory and overwrite arbitrary SRAM, ending in full code execution inside the most trusted code on the chip. From there it can boot unsigned firmware and step outside Apple's chain of trust entirely, stamping the string PWND into the device's USB serial number as proof of control. The catch is that it is not a remote attack: it needs physical possession of the device, DFU recovery mode, a USB connection and a small RP2350 microcontroller board, and nothing it changes survives a reboot. It also does not break the Secure Enclave, so a device protected by a strong passcode keeps its user data encrypted even after the boot chain has been taken over. Apple cannot repair the affected chips; the only real remedy is newer hardware, because the A14 and later configure the controller correctly and are out of reach.
- HIGHCVE-2026-31431
Copy Fail (CVE-2026-31431), disclosed on 29 April 2026 by the security firm Theori, is a Linux kernel flaw that turns any unprivileged local user into root with a 732-byte Python script and no luck required. Despite a name that sounds like a clipboard bug, it has nothing to do with copy and paste: it is a failed copy deep in the kernel's crypto code. A nine-year-old optimization in the AF_ALG crypto socket interface let an attacker steer the kernel into writing four attacker-chosen bytes into the page cache, the in-memory copy of files that the CPU actually executes. Patch the cached pages of a setuid-root binary like /usr/bin/su, run it, and you are root. The exploit is a straight-line logic flaw with no race condition and no hardcoded kernel addresses, so the exact same script runs at roughly 100 percent reliability across Ubuntu, RHEL, SUSE, Amazon Linux and every other distribution built since 2017. Worse, because the page cache is shared by the whole machine, it crosses container boundaries: one poisoned page in a Kubernetes pod can compromise neighbouring tenants and the host. The disk file is never touched, so file-integrity scanners stay silent. It rates CVSS 7.8 (High), was added to CISA's Known Exploited Vulnerabilities catalog on 1 May 2026, and is notable for how it was found: an AI-assisted code scan surfaced a bug that had been silently exploitable for nearly a decade in about one hour.
- HIGHCLOUD-ENVFILE-EXTORTION-2024
On August 15, 2024, Palo Alto Networks Unit 42 detailed a large-scale extortion campaign that compromised cloud environments by harvesting exposed environment variable files. Attackers scanned at least 110,000 domains and collected over 90,000 unique variables, including roughly 7,000 cloud service credentials and 1,515 social media credentials, with their infrastructure probing around 230 million targets. The vector was a web server misconfiguration: .env files inside the web root were served as plaintext over HTTP because the servers had no rule denying access to dotfiles, exposing the long-lived AWS IAM access keys hardcoded inside. The initial IAM principals lacked full admin but retained permission to create roles and users, so attackers called CreateRole and attached AdministratorAccess to escalate, then spun up Lambda functions across regions to automate further internet-wide scanning. They used the victims' own AWS accounts to exfiltrate and delete S3 objects, then uploaded ransom notes demanding payment. The failure chain combined exposed dotfiles, long-lived hardcoded credentials, and over-permissioned IAM, not any cloud-provider flaw.
- HIGHCLOUD-IAC-TFSTATE-EXPOSURE
Exposed Terraform state is an Infrastructure-as-Code hygiene failure class in which the terraform.tfstate file leaks credentials because Terraform records every managed resource attribute, including secrets, in cleartext JSON by default. HashiCorp documents that Terraform stores state in a plaintext file that includes any secret values defined in the configuration, so database passwords, IAM access keys, TLS private keys, and API tokens are written verbatim into state. The exposure paths are concrete and repeatedly observed: state committed to a public or private git repository without a .gitignore rule, state left in a world-readable or misconfigured S3 bucket, state captured in CI/CD logs, or state held in a remote backend that lacks encryption at rest and access controls. Numerous terraform.tfstate files have been found in public GitHub repositories and open S3 buckets, and because the file is effectively a master key to the infrastructure, an attacker who reads it obtains working credentials and bypasses the perimeter entirely without exploiting any vulnerability.
- HIGHINFRA-TESLA-K8S-2018
In 2018, attackers found Tesla's Kubernetes admin console sitting open on the internet with no password. Inside, they found Tesla's AWS cloud keys. But instead of stealing data or causing damage, they did something quieter and increasingly common: they used Tesla's cloud to mine cryptocurrency, on Tesla's bill. And they hid it carefully, throttling the mining and hiding the traffic behind Cloudflare so it would not stand out. It is the textbook cryptojacking case, and a reminder that an exposed dashboard is a door to your cloud account, and that the first sign of a breach is often a suspiciously busy server, not a ransom note.
- CRITICALINFRA-WANNACRY-2017
On the morning of 12 May 2017, WannaCry became the fastest-spreading ransomware in history, encrypting files on more than 230,000 Windows machines across 150-plus countries in a single day and demanding a few hundred dollars in Bitcoin per machine. It needed no phishing and no clicks. It was a worm: it spread itself from one unpatched computer to the next using EternalBlue, an exploit for a flaw in Windows' ancient SMBv1 file-sharing protocol that the US National Security Agency had quietly stockpiled and that a group called the Shadow Brokers had leaked weeks earlier. Microsoft had shipped a patch (MS17-010) two months before, but the unpatched and the end-of-life machines, most famously across the UK's National Health Service, which diverted ambulances and cancelled thousands of operations, were swept up regardless. The global rampage was then halted almost by accident when a 22-year-old researcher registered a single gibberish domain for about ten dollars, not yet knowing it was the worm's kill switch. WannaCry is the textbook lesson in patching fast and killing legacy protocols, with a stranger-than-fiction ending.