Ransomware on the Billing Server at 02:14

Order is driven by one question: what, if lost, is unrecoverable?

1. Protect the backups before anything else. The NAS is on the same subnet and almost certainly reachable with the same domain-admin credential that is already in the attacker's hands. Disable its network shares, take it off the domain, or physically isolate it. Confirm the Friday tape's physical custody. If the backups go, this stops being an outage and becomes an extinction event - the restore path is the only way out.
2. Network-isolate BILL-01 (EDR containment or a switch-port ACL to a quarantine VLAN) - not power-off.
3. Disable and begin rotation of the compromised domain-admin service account, and enumerate every host and service where it is used. Containment that leaves a working domain-admin credential in place is cosmetic - the attacker can re-encrypt whatever you clean.
4. Isolate WS-4417 as the likely staging point, and preserve its memory and disk.
5. Scope before you rebuild. Hunt for the same account, the same psexec pattern, and the same binary hash across all hosts. Assume the adversary is on more than two systems until the hunt says otherwise; rebuilding one host and reconnecting it is how you get encrypted twice.
6. Preserve evidence - the EDR process tree, the ransom note, the encryption extension, timeline.
7. Then the restore decision and communications (legal, insurer, regulator, executives).

Note the honest trade in step 2: isolation is downtime. You are buying containment with availability, deliberately.

CEO - "power everything off":

• It destroys volatile evidence: memory holds the encryption keys, the running process tree, the C2 session, and sometimes the ransomware binary itself. Powering off is the single fastest way to lose your best chance at a decryptor, at attribution, and at understanding initial access.
• It blinds you: powered-off hosts stop reporting to EDR. You would trade a visibility problem for total darkness.
• Blanket shutdown takes down domain controllers and identity, which is where the forensic evidence of lateral movement lives, and can widen the outage far past billing. It is an understandable instinct - stop the bleeding - but it stops your ability to respond more effectively than it stops the adversary.

Operations director - "reboot and see":

• Ransomware is not cleared by a reboot. Persistence lives in scheduled tasks, services, run keys, and GPO - a reboot restarts the encryption or triggers a delayed payload, and you burn the memory evidence at the same time.
• "See if it clears" is an experiment run on production during an active incident, with no rollback.

What you actually do:

• Keep it powered on and network-isolated, with the EDR agent alive and checking in.
• If you have memory-capture tooling, capture RAM now, before anything else touches the host.
• Dump the EDR process tree: parent of psexec, the executable hash, the user context, the command line, and the timeframe of first execution.
• Collect the ransom note and extension for family identification - do not pay, do not contact the leak site without legal and insurer direction.
• Treat the leak-site mention as a claim of exfiltration: pull NetFlow and proxy logs for large outbound transfers from BILL-01 and WS-4417 in the preceding days. Double extortion means the encryption may not be the only damage.

Use Friday's offsite tape, and verify the NAS is clean before you trust anything about it.

The nightly NAS backups are the attractive option and the dangerous one: same subnet, likely same domain credentials, likely reachable from the compromised account. Modern ransomware operators specifically hunt and encrypt backup targets. Until you have confirmed the NAS was not accessed with that service account and that its catalog and data are intact, restoring from it risks restoring encrypted or trojaned data - and discovering that after you have overwritten production.

Accept the real cost: Friday's tape means an RPO of five days (Friday → Wednesday). You must reconcile billing data from a secondary source - payment-processor records, bank statements, paper remittances - and say so plainly rather than pretending the restore is complete.

Verification gates before reconnecting:

• Restore into an isolated network segment, not onto the production VLAN.
• Verify integrity - database consistency checks, record counts against the processor, file hashes.
• Scan the restored image; confirm the vulnerable entry point and the psexec path no longer exist.
• Confirm the compromised service account is disabled/rotated, the domain-admin group is cleaned, and persistence mechanisms are gone network-wide.
• Only then reconnect, and monitor closely for re-infection.

On the 06:00 payroll: do not let the deadline drive BILL-01 back onto the network. Options are a temporary out-of-band payroll run, a manual process for one cycle, or staged partial restoration - all preferable to reconnecting an unremediated host under time pressure. Escalate the decision to the executive owner in writing, because "finance says it cannot slip" is a business risk acceptance, not a technical one.