Pay the ransom, or rebuild from clean ground. By the second morning that was the only question left in the room — both plants were dark, a payroll run was due Thursday, and the attackers had put a 72-hour clock on their demand. We advised against paying, and not on principle alone: the evidence in front of us said we could be back faster by rebuilding than by trusting a criminal's decryption tool.
What follows is a representative account, with the client and identifying details kept deliberately vague. The shape of it, though, is one we have seen more than once across the region's industrial sector — and the way out is more repeatable than most boards fear.
The situation
Our client was a mid-sized manufacturer — roughly 400 staff across two plants in the Gulf, running a mix of modern ERP and older plant-floor systems that had grown up over fifteen years. The intrusion surfaced overnight: file servers, shared drives and the primary ERP database encrypted, a ransom note dropped on every desktop, and the production schedule gone with them. Order intake, dispatch and inventory all ran through the same systems, so within hours both sites had effectively stopped.
The challenge
The hard part was not the encryption itself. It was uncertainty. The nightly backups had been reachable from the same network the attackers walked through, so some of them were encrypted too — and no one could say with confidence which restore points were clean. We did not yet know how the attackers got in, how long they had been inside, or whether they still had a foothold. Restoring blindly risked handing production straight back to them. And the demand, payable in cryptocurrency, carried its own 72-hour pressure. Choosing well meant choosing quickly, but not carelessly.
Our approach
We work the same sequence in every serious incident; the discipline matters more than the tooling.
Contain before touching anything
Before restoring a single server, we isolated both sites' networks, cut remote access, and forced a reset of every privileged credential. You cannot recover into an environment the attacker still controls.
Establish ground truth
In parallel, we stood up an EDR agent across the fleet and pulled what logs survived into a temporary SIEM. That gave us a timeline: the initial foothold, a stolen VPN credential with no MFA, and a dwell time measured in days rather than months. Knowing the entry date told us which backups predated the compromise.
Recover in priority order
We mapped the minimum set of systems needed to make and ship product — ERP core, authentication, a handful of plant-floor dependencies — and restored those first, onto rebuilt and hardened hosts, rather than trying to boil the ocean.
Rebuild identity, not just servers
We treated the identity layer as the real crime scene: new domain-admin accounts, MFA on every remote and administrative path, and tiered access so one stolen password could never again reach everything.
What we did
The first two days went to containment and forensics — unglamorous, and exactly the part everyone under pressure wants to skip. By day three we had a restore point we trusted, roughly a day older than the attack, and we began bringing the ERP core back on clean hardware. Day four, the first production line was running again on a limited set of functions, with staff working from printed schedules while we validated data. Day five, the second plant followed, and EDR and centralized logging were watching everything we had restored. Day six was hardening and handover: MFA enforced everywhere, backups moved off the production network onto immutable, offline copies, and a written runbook so the client's own team could carry it forward. We never paid, and we never needed the attacker's key.
The outcome
| Metric | Before | After |
|---|---|---|
| Time to restore core operations | No tested plan (weeks, best guess) | Under a week — both plants |
| Data loss on recovery (RPO) | Unknown — backup age uncertain | About one day, re-keyed manually |
| Endpoints with EDR coverage | Roughly a third | Full fleet |
| MFA on remote & admin access | Partial | Enforced everywhere |
| Backup restore tested | Never | Quarterly, offline copies |
Six days from dark plants to both sites producing is fast for an incident of this size, and the honest reason is not heroics — it is that we spent the first 48 hours on evidence instead of on hope. The recovered data was about a day stale, a loss the business absorbed by re-keying a single day's transactions. More important than the speed was what changed underneath: the same attack, attempted again a month later, would have met an environment built to contain it.
What made the difference
- A backup you have never restored is a hope, not a plan. The client had backups; what they lacked was proof those backups worked and that they sat out of the attacker's reach. Test restores, and keep at least one copy offline and immutable.
- Identity is the perimeter. One VPN account without MFA opened the whole environment. Restoring servers without rebuilding identity would have faithfully restored the vulnerability too.
- In the first hour, fear is the adversary. The pressure to pay is engineered. Buying two days for forensics felt expensive and turned out to be the fastest route back.
The manufacturer is still making the same products in the same two plants. The difference is that a bad night is now a manageable one — and that, more than any single control, is what resilience actually looks like.