Ransomware recovery case studies: how Maersk and Norsk Hydro came back without paying

Why these two cases matter

Most ransomware stories end at the attack. These two are worth studying because they are about the recovery, the part that actually decides whether an organization survives. Maersk and Norsk Hydro are large, complex, global companies that were hit hard and chose not to pay, then rebuilt and told the world how. Law enforcement and the security industry have called Norsk Hydro's response the gold standard. Together the two cases map out what recovery really takes, and where the weak points are.

The lesson is not that these companies were lucky. It is that recovery is a capability you either have before the attack or you do not. Everything below is drawn from the companies' own disclosures and contemporary reporting, with sources at the end.

Case study 1: Maersk and NotPetya

On June 27, 2017, the NotPetya malware tore through the shipping and logistics giant Maersk as collateral damage from an attack aimed at Ukraine. It spread in minutes and destroyed data on an enormous scale. Maersk's chairman later described the rebuild bluntly: the company had to reinstall 4,000 servers, 45,000 PCs, and 2,500 applications, essentially a complete infrastructure, and it did so in about ten days. The incident cost an estimated $250 to $300 million.

The detail that made recovery possible has become legendary in security circles. NotPetya had encrypted or wiped Maersk's domain controllers across the network, which would normally make a clean rebuild of identity almost impossible. One surviving backup existed only because a single domain controller in a Ghana office had been offline, by luck of a power outage, during the attack. That one surviving copy of the directory was flown in and became the seed of the entire recovery. During the outage, Maersk staff kept roughly 80% of business volume moving by hand.

The takeaways are stark. First, a backup you cannot reach or that the attack also destroyed is not a recovery plan, and Maersk nearly learned that the hardest way. Second, identity and directory services are the foundation everything else restores from, which is why recovery has to happen in dependency order. Third, ten days of global disruption at hundreds of millions of dollars is what 'recovered without paying' actually looked like when recovery was not engineered in advance.

Case study 2: Norsk Hydro and LockerGoga

In March 2019, the aluminum and energy manufacturer Norsk Hydro was hit by LockerGoga ransomware that began when an employee opened an infected email from a trusted customer months earlier. The attack ultimately locked files on thousands of servers and PCs and affected all 35,000 employees across 40 countries. The financial impact approached $71 million, with about $41 million of that in the first week alone.

Norsk Hydro's response is the part worth copying. The company refused to pay the ransom and committed publicly to restoring from backups. Just as notably, it was completely transparent, holding regular press briefings and webcasts about what had happened while the investigation was still live, rather than hiding the incident. Plants switched to manual operations to keep producing where they could, and the company rebuilt its systems from recent backups over the following weeks.

Two lessons stand out. First, the decision not to pay was only credible because the company had backups it trusted. Refusing to pay is a posture you can only afford if recovery is real. Second, transparency turned a crisis into a reputation gain. Norsk Hydro is now cited as the model response precisely because it did not try to spin or bury the attack.

What both recoveries have in common

Across two different industries, two different malware families, and two years apart, the pattern is identical. The organizations that came back without paying shared the same four things, and the gaps in their recoveries point to exactly what modern resilience has to fix.

• Backups that survived the attack. Maersk's recovery hinged on a single copy that happened to be offline. That cannot be left to luck, which is why immutable, air-gapped backups exist.
• Recovery in dependency order. Both had to bring back identity and core systems first before anything else could follow. Restoring in the wrong order wastes the days you do not have.
• The ability to keep operating manually while rebuilding. Both kept a large share of business moving by hand, which bought time but is not a strategy you want to rely on.
• A decision not to pay, backed by real capability. Refusing the ransom was only possible because recovery was achievable. The decision and the capability are inseparable.

What has changed since, and why speed now matters more

Both of these recoveries were measured in days and weeks, with heroic manual effort. In 2017 and 2019 that was considered a success, and relative to paying, it was. But the threat has moved on. Modern ransomware is double extortion, so the data is stolen as well as encrypted, and attackers deliberately target the backups first precisely because they learned from cases like these that a surviving backup defeats them. A recovery plan that depends on luck, or on ten days of manual operations, is not good enough against an adversary who now hunts the backup.

The modern bar is higher: backups the attacker cannot reach or alter, verified clean before restore, brought back in automated dependency order in hours rather than a manual scramble over days. That is the difference between the gold-standard recoveries of a few years ago and what resilience has to mean now.

How Immune turns these lessons into a capability

We built Immune so that an organization does not have to get lucky the way Maersk did. We keep verified, immutable, air-gapped recovery points that ransomware cannot alter or delete, so there is always a surviving copy by design, not by accident. When it is time to recover, we confirm a backup predates the attack, check it is clean, and restore systems in dependency order automatically, identity and network first, then the applications that depend on them.

The goal is to compress a Maersk-style ten-day rebuild into a controlled recovery measured in hours, and to make Norsk Hydro's refuse-to-pay decision the easy, obvious choice rather than a brave gamble. If you want the technical detail on how that recovery works, see our explainer on self-healing security, and for the foundation it rests on, our guide to immutable backups. Recovery is the capability that decides the outcome, and it is the one we treat as first-class.