Fourteen Encrypted Endpoints, One Responder, and a 09:00 Demo

Ranking logic: stop the spread, protect the recovery path, then preserve.

1. Fix the scope before touching anything (5 min). Get the switch port / hostname list for the 14 reported machines and ask the help desk to check both file servers for README.txt and .lckd files. A single responder cannot afford to contain the wrong set, and '14' is a user report, not a measurement.
2. Isolate laterally, do not power off. Disable the switch ports or move the hosts to a quarantine VLAN; block SMB/RDP between the workstation VLAN and the server VLAN at the firewall. Pulling the plug destroys volatile memory, and some families keep encryption keys in RAM - occasionally recoverable. Isolate, don't shut down, unless a server is actively encrypting in front of you.
3. Protect the backup NAS. Unmap it from servers, disable the backup service account, change its credentials, and confirm an offline or immutable copy exists. Most ransomware becomes a total loss precisely because the backup was mounted and reachable.
4. Preserve evidence cheaply. Photograph the ransom note, capture the Defender detection history and timestamps, and grab a memory image from one representative host if a tool is already available. Start a timeline document now; it will be the backbone of the report.
5. Notify upward and outward early - management, insurer, outside counsel - then begin rebuild from known-good media. Do not attempt production decryption.

Recovery is deliberately last: rebuilding onto a network that is still encrypting simply produces re-encrypted hosts.

Working assumption: the NAS is compromised. It was reachable with cached credentials from a host that was encrypting files; the absence of a ransom note on it proves nothing.

Preserve first (30–60 minutes, cheap and non-destructive):

• Export SMB/share access logs if any exist, plus the NAS's own event logs and the file listing showing README.txt or renamed files with timestamps.
• Record the last-write times and the set of accounts that touched the share in the preceding 48 hours.
• Snapshot the current state before deleting anything.

Then act:

• Disconnect the share at the network layer and remove the drive mappings.
• Disable and rotate the backup service account; if the NAS is domain-joined and the DC itself shows any sign of compromise (unexpected 4672 logons, new accounts, SID-history changes), escalate to the double-krbtgt reset decision - but make that call on evidence, not by default, because it forces two domain-wide replication cycles.
• Verify whether a genuinely offline or immutable copy exists. If not, say so in writing immediately; it changes the entire recovery strategy and the payment debate.

The test is not 'does it look encrypted', it is 'can you prove an untouched recovery point exists'.

Response structure: acknowledge the business stake, give a defensible commitment, offer alternatives.

What I will commit to by 09:00:

• A confirmed count of affected hosts (not the reported 14).
• Two clean loaner laptops with the demonstration data restored from the 24-hour backup, if that data lives on the file server and not on an encrypted endpoint.
• A written go/no-go on restoring all 60 endpoints.

What I will not commit to:

• Full restoration by 09:00. Rebuilding 60 endpoints from a 24-hour-old backup onto a network whose initial access vector is unknown risks re-infection during the demo itself - a far worse outcome than a rescheduled meeting.

Points to make explicitly:

• The demo can run from clean machines on an isolated network segment; separating the demo from production is cheaper than either failure mode.
• The CFO's laptop is offline and travelling - no recovery timeline can be given for it, and it must not reconnect to the corporate network until it is rebuilt or verified.
• Paying or decrypting is a business and legal decision, not a technical one, and it is not on the critical path before 09:00.

Record the decision and who made it. Later review will ask why the demo was or wasn't prioritised.