Cybersecurity / Source date:

WannaCry & NotPetya: When Ransomware Became Global Crisis

WannaCry and NotPetya in 2017 changed the definition of catastrophic cyber risk — demonstrating that nation-state cyberweapons could generate billions in collateral damage to businesses worldwide.

Illustration of a dispatcher recording shipments on paper beside a radio, offline contact tree and disconnected network cable.

Two attacks six weeks apart in 2017 ended the era in which ransomware was treated as an IT nuisance with a price tag. WannaCry began on Friday 12 May and reached more than 200,000 computers in at least 100 countries. In England, roughly 80 of 236 NHS trusts were disrupted, along with 603 further NHS organisations including 595 GP practices; NHS England declared a major incident that afternoon, and appointments and operations were cancelled. The ransom demand was small — a few hundred dollars in Bitcoin — and a researcher found and activated a kill-switch domain the same evening, limiting what could have been far worse. Microsoft had issued the patch, MS17-010, on 14 March, two months earlier. NotPetya arrived on 27 and 28 June and was a different animal entirely. It spread through a compromised update to M.E.Doc, Ukrainian tax and accounting software used by essentially every company filing there, then propagated inside networks using the same EternalBlue exploit combined with credential harvesting — which meant fully patched machines fell to stolen administrator credentials. Around 80% of affected systems were Ukrainian, but the damage went global through multinationals with Ukrainian operations. Maersk's shutdown affected 76 ports and cost an estimated $200–300 million. Merck lost around 40,000 computers and later reached a $1.4 billion insurance settlement. FedEx's TNT Express subsidiary, Mondelēz and Saint-Gobain were all hit hard. Radiation monitoring at Chernobyl went offline. Total global damages are commonly estimated at roughly $10 billion, and Ukraine, the United States and the United Kingdom attributed the attack to Russia. The critical detail: NotPetya's encryption was not designed to be reversible. It was destruction dressed as extortion.

What actually changed

Ransomware became a business continuity problem, not a data problem. The damage at Maersk and Merck came from operational paralysis — ports that could not process containers, production lines that stopped, orders that could not be taken. Backups of data do not restore a business that has lost the systems that run it. Self-propagation removed the containment assumption. Earlier ransomware encrypted what the infected user could reach. These attacks spread laterally on their own, across flat internal networks, at machine speed. A single infected laptop became an estate-wide event in under an hour. Paying stopped being an answer. WannaCry's payment and decryption mechanics were poorly built; NotPetya's were a facade. Any recovery plan whose fallback was "we will pay" discovered that the fallback did not exist. The software supply chain became the delivery mechanism. NotPetya arrived through a trusted, signed update to legitimate software that organisations were effectively required to run. No amount of perimeter defence or user training addresses that. Insurance became contested. The war exclusion litigation that followed — and the eventual settlements — established that state-attributed destructive attacks sit in genuinely uncertain territory for coverage. That uncertainty has been priced into every cyber policy since.

The crisis response lessons that transferred

The organisations that recovered fastest shared a small number of characteristics, and none of them were about prevention. They had offline, immutable backups that the malware could not reach, and they had restored from them before. They could operate parts of the business on paper, because someone had written down how. They had out-of-band communications, because email and chat were gone along with everything else. They had a decision-making structure that did not require the systems that were down. And they made the hardest call quickly: several organisations that limited damage did so by shutting networks down pre-emptively, accepting a self-inflicted outage to prevent a worse one. That decision has to be pre-authorised, because nobody improvises it at 3am. The converse pattern was equally consistent. Organisations that struggled had backups on network shares that got encrypted, recovery runbooks stored in the systems that were unavailable, no rehearsed manual fallback, and a contact list in an inbox they could not open.

Continuity capabilities to exerciseA qualitative rehearsal checklist drawn from the article. It does not rank effectiveness or estimate recovery time.
CapabilityWhat the rehearsal must make usable
RestorationA protected copy and a tested route back to a critical operating system.
Disconnect authorityA named decision-maker able to order containment without failed systems.
Manual operationWritten fallback instructions for critical business processes.
Independent communicationsReachable contacts and coordination outside affected email and chat.

Qualitative summary of this article's source text, not a measured outcome or performance estimate.

Practical Guidance for Ransomware Crisis Response Planning

  • Keep at least one backup copy offline or immutable, and restore from it as a test. A backup that has never been restored is a hypothesis, and network-attached backups die with the network.
  • Pre-authorise the decision to disconnect. Name who can order a network shutdown and under what conditions, before you need it.
  • Write the manual fallback for your three most critical processes. Taking orders, paying people and moving goods on paper for 72 hours is a real capability that has to be documented.
  • Establish out-of-band communications and print the contact list. When email and directory services are down, so is your ability to convene anyone.
  • Segment so that one compromised endpoint cannot reach the estate. Self-propagating malware makes flat internal networks the single largest amplifier of damage.
  • Treat vendor updates as a supply chain risk with staged rollout. Trusted signed updates have delivered destructive payloads; phased deployment buys detection time.
  • Read your cyber policy's war and hostile-act exclusions with counsel. State-attributed destructive attacks are where coverage disputes happen.
  • Rehearse the whole thing once a year with the executive team present. The technical recovery is the easier half; the decisions are the part that goes wrong.

The Regional Dimension

The Gulf did not need 2017 to learn that destructive attacks are real. The Shamoon wiper campaigns against regional energy and government targets had already demonstrated the pattern of malware built to destroy rather than to extort, and they remain the reference point in regional boardrooms. That history means the "we are not a target" argument gets less traction here than elsewhere — which is an advantage, if it is used. Several structural factors shape the regional exposure specifically. Operational technology and long asset lifecycles concentrate the risk. Ports, refineries, petrochemical plants, utilities, aluminium smelters and the logistics infrastructure that regional economies run on operate industrial control systems with decade-plus lifespans, running software that cannot be patched on any normal cadence. NotPetya's most instructive victim for this region was a shipping company — and regional ports and logistics hubs are among the world's busiest. The consequence of a multi-week operational outage at a regional transhipment hub is not a company-level event. The integrator and managed service model changes who can respond. Large parts of regional IT estates are operated under contract by systems integrators, and privileged remote access held by third parties is both a lateral movement path and a response dependency. Two questions worth answering before an incident: can your integrator's access be revoked quickly and unilaterally, and does your contract oblige them to provide emergency response capacity, or does that become a commercial negotiation during the crisis? Regulatory obligation has firmed up substantially. National cybersecurity authorities in the UAE and Saudi Arabia, central bank frameworks for financial institutions, and sector regulators in energy, health and telecommunications now impose incident notification timeframes and, in some cases, controls that are audited. The notification clock starts during the worst hour of the incident, which is exactly when nobody is thinking about it — so the who-notifies-whom-within-how-many-hours question belongs in the runbook, per jurisdiction, for groups operating across several markets. Two final regional points. Multi-entity, multi-country group structures mean a single incident may trigger different obligations in each jurisdiction and require entity-level containment decisions, which argues for knowing in advance where the network boundaries between entities actually are — most groups discover they are more connected than the org chart suggests. And regional cyber insurance has tightened considerably: insurers now commonly require multi-factor authentication, tested backups and endpoint detection as conditions of cover, and social engineering losses are frequently carved out. The underwriting questionnaire has become, in practice, a free gap assessment worth completing honestly.

The objection worth taking seriously

The fair criticism of ransomware planning is that it can become a rehearsal industry that consumes budget without reducing risk. Tabletop exercises that conclude with a slide deck, runbooks that are written once and never revised, and backup tests performed on convenient systems rather than critical ones are all common, and they produce documented preparedness rather than actual resilience. The honest test is narrower and harder: has anyone restored your most complex critical system from an offline backup, end to end, within the last twelve months, and how long did it actually take? Most organisations that believe they are prepared have not done this, and the answer is usually several times longer than the recovery time objective on paper. There is also a resourcing argument. The full control set implied by these incidents — segmentation, immutable backups, staged update deployment, out-of-band communications, annual executive exercises — is beyond what a mid-market organisation with a small IT team can sustain. For them the realistic minimum is four things: multi-factor authentication on everything reachable from outside, one backup copy that is offline and tested, endpoint detection that someone actually monitors, and a printed list of who to call. That set prevents or limits the large majority of realistic scenarios, and pretending otherwise leads smaller organisations to do nothing because everything looks unaffordable. And a point about NotPetya specifically that gets lost in the retelling: it was not a ransomware attack that got out of hand. It was a targeted act of state-directed destruction against a specific country, whose collateral damage happened to be global. Organisations drawing lessons from it should be careful about which threat model they are preparing for, because the defences against an extortion operation and the defences against a wiper delivered through a mandatory software update are not the same set.

Common Questions

Would patching have prevented both attacks?

It would have prevented WannaCry, where the patch had been available for two months. It would not have been sufficient against NotPetya, which combined the same exploit with credential theft — patched machines were compromised using stolen administrator credentials, which is why privileged access management matters as much as patching.

Is paying the ransom ever the right decision?

It is a business decision with poor odds and no guarantee, and 2017 demonstrated the limit case: NotPetya's decryption was never functional. Payment also faces sanctions and legal constraints in many jurisdictions. Plan on the assumption that payment is unavailable.

What is the single highest-value control?

An offline or immutable backup that has been successfully restored in a test. It is the one control that works regardless of how the attacker got in or what they did.

How has AI changed the ransomware threat?

It has industrialised the entry path and compressed the timeline. Phishing and pretexting are now cheap, fluent and personalised at scale — including in Arabic and other regional languages, which previously limited the quality of localised attacks — and voice cloning defeats callback verification of the kind used to authorise resets and payments. Vulnerability-to-exploit intervals have shortened, which squeezes the patch windows that organisations designed around the eight weeks MS17-010 allowed. Attack operations themselves are more automated, so lateral movement and data exfiltration happen faster than human response cycles. Defensively, behavioural detection and automated containment are genuinely better, and automated isolation of a host showing encryption behaviour is the closest thing to a real answer to self-propagation. The strategic implication is unchanged but sharper: prevention keeps getting harder relative to recovery, so the investment balance should tilt toward tested restoration, segmentation and rehearsed decisions rather than toward stopping the initial compromise.


Ransomware Crisis Response Planning — NotPetya's decryption never worked; plan for recovery you control, not for a payment that might not be an option.

Continue reading

Talk to OPS

Start with the operating problem.