FS01 Ransomware Staging Under Legal Hold

Memory capture first, then network state, then a disk image or snapshot, then remediation. The sysadmin's plan is the worst option because reboot-into-safe-mode discards all RAM, and antivirus scanning writes to disk, changing timestamps and potentially triggering a staged second payload.

• Capture RAM with WinPmem from the vetted USB toolkit, recording the tool hash. The encryption process, its command line, and any key material exist only in RAM; the disk image will not contain them.
• Capture network and session state next: netstat, logged-on users, open SMB sessions, DNS cache, scheduled tasks, and the live TLS session details. The five-minute beacon proves the operator may still hold hands-on access, so this state explains what they are doing.
• Then image or snapshot. Nine hours is acceptable only if the machine is isolated so the attacker cannot detonate or wipe mid-acquisition; if it is not isolated, a storage-level snapshot is the pragmatic compromise and must be documented as such.
• Contain in parallel, not before. Block egress to 45.9.148.0/24 and 443 from FS01 at the perimeter while captures run; this costs the operator their channel but not the evidence.

Running the AV scan before acquisition converts a defensible case into an unrecoverable one.

• Process tree with command lines and parents: confirms the wmiprvse.exe parentage, which suggests WMI or PsExec-style remote execution and answers how the encryptor was launched and from where.
• Loaded modules and injected regions: identifies the encryptor binary and any DLL side-loading, which the disk image may show only as an encrypted blob.
• Open file handles and the running process's memory space: may reveal the symmetric key or the seed used to derive it, which determines whether decryption without paying is possible.
• Network connections and TLS session data: correlates with the five-minute beacon to attribute the C2 infrastructure.
• Registry hives in memory (SAM, SECURITY, SYSTEM): cached credentials and service configuration before anything is cleaned.
• Logged-on sessions and SMB connection table: establishes which of the 260 users were active and how far the share enumeration reached, which supports the legal scope question.

Each item maps to a decision: how entry occurred, whether recovery is possible, who else is exposed, and what must be disclosed.

• Hash every artifact at acquisition with SHA-256, record the hash in the evidence log, and re-verify after transfer. A memory image without a verified hash is not defensible.
• Work from copies only. All analysis runs on duplicates; the original image media stays sealed with the evidence custodian. Note that the machine itself remains the original evidence, so any change to it - including the AV scan - must be justified and logged.
• Document the decision to keep FS01 running. Legal hold does not mean freeze time. Write down who approved live acquisition, at what time, with what alternatives considered and rejected, because opposing counsel will ask why a 9-hour image was not taken.
• Maintain a continuous chain of custody: collector identity, timestamps with timezone, storage location, and every handoff.
• Preserve the volatile data even though it is ephemeral - the fact that RAM could not be preserved later is itself something to record.
• Restrict access to the evidence store to named individuals on the IR team, and keep the 260 users' activity logs, since their file access during the incident may be relevant.