Patient Zero: Reconstructing a Ransomware Incident From a Single Memory Capture

A mid-size logistics company discovered a ransom note on their primary file server on a Monday morning. IT staff, following incident-response guidance, did not power off the machine and instead isolated it from the network before calling in a DFIR consultant — preserving the volatile memory that would prove critical to reconstructing the attack.

• Full RAM capture (64 GB) from the affected Windows Server 2019 host, taken live before shutdown
• Forensic disk image of the server's system volume
• Firewall and VPN concentrator logs for the preceding 14 days

• Magnet RAM Capture (acquisition)
• Volatility 3 (pslist, pstree, netscan, malfind, cmdline, hashdump)
• Wireshark (correlating netscan output with firewall logs)
• VirusTotal (hash reputation lookups)

• Acquired the RAM image first, per order of volatility, before any disk imaging or further system interaction.
• Ran Volatility 3's pstree to build a process ancestry tree, immediately spotting an unusual child process spawned from a legitimate remote-management tool already permitted on the network.
• Used malfind to scan for processes with suspicious memory permissions (RWX pages), identifying an injected payload inside a seemingly benign svchost.exe instance.
• Extracted the injected region and hashed it; the hash matched a known ransomware loader family in VirusTotal, giving immediate attribution context.
• Ran netscan to enumerate active and recently closed network connections at time of capture, revealing an outbound connection to an external IP shortly before the ransom note appeared.
• Cross-referenced that IP against firewall logs, confirming the connection had been active for 40 minutes — consistent with data staging before the encryption routine triggered.
• Used cmdline to recover the full command line of the malicious process, revealing the exact ransomware binary path and a flag disabling Volume Shadow Copy deletion logging — explaining why shadow copies were unusable for recovery.
• Pulled hashdump to identify which cached credentials were present in memory at the time of compromise, informing which accounts needed immediate forced password resets.

• An injected RWX memory region inside svchost.exe matching a known ransomware loader hash
• Full command line showing the ransomware binary was launched via the legitimate remote-management tool — indicating the initial access vector was a compromised admin credential, not a phishing payload on that host
• A 40-minute outbound connection to an external IP immediately preceding encryption, consistent with data exfiltration for double-extortion
• Cached domain admin credentials present in memory, confirming lateral-movement risk beyond the single affected host

• IT's initial instinct was to power off the server immediately, which would have destroyed the memory evidence entirely; convincing them to isolate-not-shutdown under time pressure required clear, fast communication of the order of volatility.
• The 64 GB capture took over 90 minutes to acquire and several hours to process, requiring the response team to work from preliminary triage (pstree, malfind) while the full analysis continued.
• Attribution to a specific ransomware family from hash reputation alone is probabilistic, not certain — the report was careful to frame it as 'consistent with' rather than definitive attribution.

The memory-derived indicators (malicious IP, injected process hash, compromised account) were fed into the client's EDR platform within hours, containing the incident before it spread beyond the single file server. The exfiltration finding also changed the legal notification obligations, since it confirmed data had left the network.

Order of volatility is not academic — the decision to isolate rather than power off the server is the single reason this attack chain was reconstructable at all. A single well-collected RAM image can answer questions a disk image alone cannot, particularly around fileless or injected malware.