Three weeks into a ransomware investigation at a mid-size logistics firm, the IR team handed me what they called a “forensic copy” of the infected server. It had been rebooted twice. The antivirus had run a full cleaning pass. Someone had deleted the Windows event logs – claiming it was to save disk space. Four weeks of investigative work, and we had almost nothing legally defensible to show for it. The attacker – later attributed to a LockBit affiliate – had used T1070.001 (Indicator Removal on Host: Clear Windows Event Logs) as part of their standard playbook. But our own team had finished the job for them.
That incident changed how I approach IR forensics entirely. Not the collection phase – the preparation phase. What you do in the first thirty minutes of an incident determines whether you’ll have usable evidence. This guide walks through what actually works, where teams consistently fail, and how to build forensic readiness into your environment before the next alert fires.
When the Alarm Goes Off and Evidence Starts Disappearing
The moment an incident is confirmed, two things happen simultaneously. Your team scrambles to contain the damage. And the attacker’s footprints start vanishing – either through their own cleanup scripts or through well-meaning but destructive remediation actions your own people take. This is the central tension of forensic incident response, and most IR playbooks underestimate it badly.
Digital evidence is not like physical evidence. RAM contents disappear the instant power is cut. Running processes, network connections, clipboard data, and encryption keys held in memory – all of it gone. System logs get overwritten on active systems. Timestamps shift. The window for high-fidelity evidence collection is measured in hours, not days.
APT29 – Cozy Bear – has demonstrated awareness of this for years. Their intrusion campaigns actively manipulate file timestamps (T1070.006) and clear security event logs post-exploitation. They count on responders making mistakes in the first four hours. Most of the time, they’re right.
Why Most IR Teams Destroy Evidence Before They Collect It
I’ve seen this pattern more times than I’d like to admit. A security alert fires. Someone pulls the network cable on the affected machine. Another person reboots it “to see if that fixes it.” The EDR console runs an automated remediation. By the time a forensic analyst arrives, the machine is in a state that tells you almost nothing about what actually happened.
The Volatility Order Gets Ignored
RFC 3227 – published in 2002 but still the foundational reference for evidence collection order – establishes a clear volatility hierarchy. Collect from most volatile to least volatile: CPU registers and cache first, then routing tables and ARP cache, active process listings, network connections, processes mapped to disk, and finally the disk image itself. Most incident responders – especially those without dedicated forensics training – skip straight to pulling a disk image because it feels productive. Meanwhile, the entire RAM-resident picture of the attack evaporates: active C2 connections, injected shellcode, in-memory credential caches, and encryption keys all disappear with the next reboot.
Chain of Custody Breaks at First Contact
Chain of custody is not a bureaucratic formality. It is the mechanism that ensures your evidence remains usable in legal proceedings – whether that’s a criminal case, a civil suit, or a regulatory investigation. Every time someone touches a compromised asset without documenting who, when, why, and what actions they took, they introduce a vector for opposing counsel to challenge the entire evidentiary chain. (This matters even when prosecution isn’t the goal – insurance claims and regulatory audits carry the same evidentiary requirements.)
The failure point is almost always the first fifteen minutes. IT staff act before the IR team arrives. They’re trying to help. And they’re making the forensic analyst’s job significantly harder.
A Field-Tested Forensic Response Workflow
Contain First, but Do It Right
Network isolation does not mean powering off. Isolating a compromised host at the network layer – blocking it from reaching the internet and from lateral movement paths while keeping it powered on – is the correct first containment move. This preserves volatile memory state while cutting off active C2 communication. Power it off and you’ve destroyed your best evidence source.
Document every action taken before forensic collection begins. Who touched the machine. What commands were run by whom. What the EDR console did automatically. If you’re using Velociraptor or a similar live response platform, your artifacts will include timestamped remote queries – that’s your chain of custody record for the collection phase.
For evidence storage, you need somewhere clean and write-protected from the affected environment. Sending forensic images to a network share on the same compromised domain is not that. A dedicated out-of-band collection point – such as a reliable backup target with isolated access credentials – keeps your evidence environment separated from the incident scope and out of reach of an attacker who still has domain access.
Capture Volatile Memory Before Anything Else
RAM acquisition needs to happen before anything else changes on the system. Tools like WinPmem or Magnet RAM Capture can dump physical memory to an image file without significantly disrupting system state. A 32GB memory dump takes roughly 8-12 minutes on modern hardware – time well spent when the alternative is losing visibility into active injected processes and in-memory credential caches.
What you’re looking for in memory: injected code living inside legitimate processes (T1055 – Process Injection), active network connections to unusual external IPs, credentials held by LSASS if the attacker ran Mimikatz or a variant (T1003.001), and process hollowing artifacts left by the initial stager. Conti’s toolset, for example, routinely injected into svchost.exe to blend into normal process trees – exactly the kind of artifact that only survives in a live memory capture. Once that machine reboots, that evidence is gone permanently.
Forensic Imaging and Artifact Extraction
Once memory is captured, move to disk. A bit-by-bit forensic image using write-blocking hardware maintains the integrity of the original media and produces a verifiable copy. FTK Imager is the standard tool here and generates MD5 and SHA-1 hashes of the image automatically – those hashes are your integrity verification mechanism going forward. Never analyze from the original drive; always work from verified copies.
Artifact extraction tools like KAPE (Kroll Artifact Parser and Extractor) can pull targeted forensic artifacts – prefetch files, registry hives, event logs, browser history, LNK files, Shimcache, AmCache, and more – far faster than imaging the entire disk. This matters when you’re working against time on a live investigation and need triage results in hours rather than days.
But this is a limitation worth acknowledging directly: KAPE-style triage works well for rapid evidence collection from Windows endpoints, but it gives you less evidentiary confidence than a full forensic disk image for cases heading toward litigation. Know which operational mode you’re in before choosing your method. Speed and completeness are often in tension, and that trade-off needs a conscious decision – not a default.
Reconstruct the Timeline Using Multiple Artifact Sources
Timeline analysis is where the investigation actually takes shape. Correlating filesystem timestamps from the Master File Table, event log entries across Security, System, Application, and PowerShell Operational channels, prefetch execution timestamps, registry LastWrite times, and browser artifacts gives you a coherent picture of attacker activity from initial access through impact.
In a 2023 incident involving an APT-style intrusion through a stolen VPN credential (no CVE involved – just a valid credential pulled from an infostealer log sold on a dark web forum), my timeline reconstruction showed the attacker had spent 11 days in the environment before deploying encryption. They’d moved laterally through three servers, accessed the backup infrastructure (T1490 – Inhibit System Recovery), and disabled Volume Shadow Copies – all visible in the timeline once we correlated Event IDs 4624 (successful logon), 4648 (explicit credential use), and 7045 (new service installed). That 11-day dwell time told us exactly which systems to treat as compromised and where to look for persistence mechanisms.
Cross-referencing your timeline against threat intelligence – particularly MITRE ATT&CK TTPs associated with suspected threat groups – accelerates triage significantly. If you’re building that detection capability alongside forensic response, the foundational work in Threat Hunting Techniques: A SOC Readiness Audit covers the detection layers that feed directly into forensic analysis.
Verifying Your Evidence Will Hold Under Scrutiny
A forensic investigation that produces findings you can’t defend is worse than no investigation at all. It creates false confidence. Before you brief leadership or hand findings to legal, run through these verification steps.
Hash verification first: the MD5 and SHA-1 hashes of your forensic images should match the hashes recorded at acquisition time. If they don’t match, your evidence has been modified and loses admissibility. Every tool in your workflow should log its own hash calculations automatically – if it doesn’t, that tool has no place in your IR kit.
Methodology documentation matters as much as the findings themselves. Every artifact extracted, every tool version used, every finding made – documented with precise timestamps. “I found this file” is not evidence. “Autopsy 4.21.0 identified this file at this path with these MFT timestamps, extracted from an image with SHA-256 hash [value]” is evidence. That distinction will matter in front of a judge or a regulatory auditor.
Independent validation is the step most teams skip under time pressure. If your findings are going to criminal proceedings, civil litigation, or regulatory review, have a second analyst independently examine the same evidence from the same verified image. Discrepancies between analysts need resolution before you present anything. Defense counsel will find them if you don’t.
Building Forensic Readiness Before the Next Incident
The hardest lesson from most IR engagements is straightforward: organizations with good forensic outcomes prepared before anything happened. Forensic readiness is infrastructure, not a response task.
Centralized logging that sits outside the blast radius of your incident is non-negotiable. Windows event forwarding to a SIEM – or even a standalone syslog server on an isolated segment – means you retain a forensic record even when local logs get wiped by the attacker or by your own remediation steps. Enable PowerShell ScriptBlock logging (Event ID 4104), process creation events with full command lines (Event ID 4688), and network connection logging across your environment. These three logging configurations alone dramatically improve forensic visibility after the fact.
Endpoint security configurations that support forensic investigation – not just prevention – matter here. Understanding which telemetry your EDR retains, and for how long, directly affects what evidence exists when you need it. The Endpoint Security: A Complete Guide for IT Teams covers EDR deployment in depth, including telemetry retention considerations that affect your forensic posture months after initial deployment.
For organizations running Active Directory – which is most of you – ensuring you’re logging privileged account activity, group membership changes, and GPO modifications is essential forensic groundwork. The Active Directory Security: Harden Your AD Environment guide covers the specific audit policies worth enabling before you need them, not after.
Store forensic disk images and memory captures off the affected network segment. For long-term evidence retention, dedicated storage for offsite copies keeps your investigation artifacts out of reach of a follow-on attack or an insider attempting evidence destruction.
My opinionated take: your forensic readiness is only as good as your last tabletop exercise that actually tested it. Run a scenario where ransomware has wiped all local logs on ten endpoints, and see what your team can reconstruct from centralized sources alone. The gaps you find in a drill cost far less than the ones you discover mid-investigation.
If your team is working through an active incident or building out a forensic response capability from the ground up, SSE’s security consulting team can help you establish evidence collection procedures, validate your handling workflows, and support you through the investigation process. Get in touch at clients.sse.to/contact.php.
Related reading: Microsoft Intune Endpoint Management: A Real Deployment | XaaS Cloud Service Models: Security Guide for IT Teams | Cybersecurity Naming Conventions: A Complete IT Guide
