Ransomware Across Three Plants: Containment Under a Downtime Clock
At 02:14 on a Saturday, EDR raises a high-severity alert on a workstation in Plant 2 of a nine-plant food manufacturer. By 03:40 the Plant 2 file server shows 4,100 files renamed with a .locked extension, and the print spooler has failed at two other plants. EDR shows the same binary on 11 hosts across three plants. The ransom note demands 40 BTC and threatens publication of 300 GB allegedly exfiltrated. Company revenue is roughly $410,000 per hour across all plants; each plant offline costs about $38,000 per hour, and a plant needs 6 hours to stop safely and 10 to restart. The backup appliance sits on the same /24 as the file servers, its credentials were in a script on the initially infected host, and the last verified restore test was 14 months ago. The CISO is unreachable for 90 minutes; the COO wants all plants stopped immediately.
1. What containment decision do you make in the first 60 minutes, and how do you justify selective isolation against the COO's demand to stop everything?
Read the worked answer
Act as incident commander and state the authority you are relying on. The plan almost certainly delegates IC authority when the CISO is unreachable; if it does not, that is an after-action finding.
Action: isolate the three affected plants at the inter-plant and plant-to-DC boundary (firewall blocks, drop the site links), disable the compromised accounts, and begin a controlled shutdown of Plant 2 immediately, with the other two affected plants following the 6-hour safe-stop sequence. Do not stop all nine: there is no evidence of spread beyond three, and stopping the other six turns a $114,000/hour loss into $410,000/hour.
Justification to the COO: the $114k/hour is already being incurred; the alternative is uncontrolled encryption reaching nine plants plus a safety risk from an ungraceful stop on food-processing equipment. A controlled stop preserves product and machinery; pulling the power does not.
Next 60 minutes: scope the binary's execution chain across the 11 EDR hosts, check domain-wide persistence (GPO, scheduled tasks, service accounts), start credential resets including a double krbtgt reset, and verify the isolation actually blocks SMB/RDP rather than only ICMP. Keep a timestamped decision log - counsel, insurers, and regulators will ask who decided what, and when.
2. The backup appliance must be treated as suspect. How do you approach recovery and what do you tell the COO about paying the ransom?
Read the worked answer
Backups: assume compromise - same /24, credentials in a script on the patient-zero host. Do not mount it, do not restore from it, and do not let anyone “just check” by logging in with domain credentials. Isolate it, preserve its logs, and identify snapshots that predate the intrusion. Validate any candidate restore point offline before use, and rebuild rather than clean. Fourteen months without a restore test means the recovery time objective is unknown; communicate that uncertainty rather than promising Monday.
On paying: say plainly that this is not the incident commander's call. It belongs to the executive team with legal, the insurer, and law enforcement. Two technical inputs you owe them:
- Is the 300 GB exfiltration claim credible? Check proxy and firewall egress around the encryption window and the file server's access logs. Payment does not remove breach-notification obligations if the data left.
- Screen the wallet against sanctions lists - paying a sanctioned entity is its own legal exposure.
Decryption tooling from crews is frequently defective; do not let a payment decision substitute for a recovery plan. Restore order: identity services first, then a plant that can run without the file server, then the remainder.
3. Restoration pressure is intense. What evidence do you preserve, in what order, and how do you avoid restoration destroying it?
Read the worked answer
Preservation and restoration are compatible if sequenced; they conflict only if you image everything before recovering anything.
Volatile first, and selectively: memory from the 11 hosts before any reboot. Encryption keys, the C2 address, and injected process artifacts live in RAM and vanish on power cycle - if the crew kept keys on the host, a shutdown destroys the cheapest recovery path. Capture RAM from at least three hosts across the plants, not all eleven.
Then cloud and network: full EDR telemetry export (process trees, not just alerts), the ransom note with its hash, firewall and proxy egress for the exfiltration window, VPN and authentication logs, and backup appliance logs.
Then disk: full images of two or three representative hosts plus the file server's MFT. You do not need eleven images to scope an intrusion.
Then rebuild clean. Never restore production from an image of a compromised host - that is how a 10-hour restart becomes a second incident. Document every action with handler and timestamp. Whether you can support or refute the exfiltration claim, and therefore whether notification is required, depends entirely on evidence captured in the first 24 hours that cannot be recreated later.