Ransomware Precursor on the Finance VLAN
At 02:14 on a Tuesday, the SIEM alerts on 41 failed SMB authentications from workstation FIN-014 (user: t.okafor) against five file servers in 90 seconds, followed by one success against FS-02 and a burst of 1,200 file-rename operations with the extension .locked. EDR shows a signed-but-unusual binary launched from %TEMP% three minutes earlier, parented by an Excel macro. t.okafor is a payroll analyst who is on approved leave until Thursday. FS-02 hosts the payroll share; nightly backups complete at 01:00 to an on-prem NAS that is domain-joined and reachable from FIN-014's subnet. The SOC has one analyst on shift, an IR retainer with a 4-hour callback, and a written playbook that says 'isolate on confirmed ransomware' but does not define 'confirmed'.
1. What should the on-shift analyst do in the first 15 minutes, and in what order? Justify each action against the evidence.
Read the worked answer
Contain first, then confirm - the evidence already meets a reasonable 'confirmed' bar.
Order of operations:
- Network-isolate FIN-014 via EDR (host containment, not just VLAN quarantine) - the rename burst plus the macro-parented binary from %TEMP% is a high-confidence ransomware pattern; waiting for a second host to encrypt adds blast radius. Isolation is reversible; encryption is not.
- Disable t.okafor's account and revoke sessions/tokens. The account is active while the human is on leave - that is either credential misuse or malware using cached creds. Either way the identity is now suspect. Disabling is faster and safer than password reset alone (reset does not kill live sessions).
- Protect the backup path. The NAS is domain-joined and reachable from the same subnet - this is the single biggest risk in the setup. Restrict NAS access (disable the service account FIN-014 used, or pull the NAS share from that subnet) before chasing lateral movement. Losing backups converts a bad day into an extinction event.
- Scope from FS-02 outward. Pull the 1,200 renamed files list and the SMB success logon to see what was touched; check whether FIN-014 authenticated to the NAS.
- Page the retainer now, not at hour 4 - callback latency means the clock starts immediately.
Do not reboot or reimage FIN-014 before volatile capture; do not broad-sweep the whole estate and stall containment.
2. The playbook's undefined term 'confirmed' is the root problem. Draft the decision criterion you would put in the playbook, and explain why your threshold is set where it is.
Read the worked answer
Proposed criterion (any one triggers isolation):
- Mass file modification/rename with a known or unknown extension above a rate threshold (e.g., >100 renames/min on a single host), or
- A process writing to many directories outside its working set, or
- EDR high-severity detection mapped to ransomware behavior (shadow-copy deletion, boot-config tampering, encryption API burst), or
- Two or more hosts showing the same file-extension change within 10 minutes.
Why set it low:
- Cost asymmetry. A false-positive isolation costs one user a helpdesk ticket and a re-image. A missed encryption costs the payroll share and possibly the backups. The expected-loss math strongly favors early containment.
- Reversibility. Host isolation and account disable are both trivially undone; encryption is not.
- Speed beats certainty at 02:14 with one analyst. The criterion must be executable by a tired human in under a minute without a debate.
Guardrails so it isn't abused: require a second-pair-of-eyes review after containment within 30 minutes, log the trigger used, and auto-notify the on-call lead. The threshold should be tuned quarterly against false-positive rate; if FP isolation exceeds ~2/week, raise the numeric threshold, not the ambiguity.