Digital forensics is the discipline of collecting, preserving, and analyzing electronic evidence in a manner that maintains its integrity and legal admissibility. In a cybersecurity incident, forensic discipline is the difference between building a complete picture of what happened and guessing — and it is the difference between evidence that holds up in a regulatory proceeding or criminal prosecution and evidence that is challenged and dismissed.
Most incident response teams contaminate evidence within the first hour without realizing it. This guide explains what to do, in what order, and why the sequence matters.
The Order of Volatility
Digital evidence exists across a spectrum of volatility — how quickly it disappears if not captured. The fundamental principle of forensic evidence collection is to capture the most volatile evidence first, before it is lost, and work toward the least volatile.
The correct collection sequence is:
- RAM (system memory): Contains running processes, network socket state, decryption keys, plaintext passwords, and active malware artifacts. Lost entirely on reboot or power-off. Must be captured first, before any other action.
- Running processes: Process list with PIDs, parent-child relationships, loaded DLLs, command-line arguments. Partially captured in memory image but also exportable via tools like
tasklistor Sysinternals Process Explorer. Lost on reboot. - Network connections: Active TCP/UDP connections showing what the compromised system is communicating with. Captured via
netstat -anobor similar. Changes dynamically and is lost on reboot. - Disk image: Complete forensic copy of the storage media. This is the most stable evidence and should be captured after volatile data is secured.
- Logs: Windows Event Logs, application logs, SIEM data. These persist but can be overwritten over time.
Memory Acquisition
For Windows systems, Magnet RAM Capture (free) and WinPmem (open source) are the most commonly used memory acquisition tools. Both create a raw dump of physical memory to an output file. The output file should be written to an external drive — never to the system being imaged, as writing to the system modifies it.
On Linux systems, /dev/mem or /proc/kcore may be accessible for memory acquisition depending on kernel configuration. The LiME (Linux Memory Extractor) kernel module is the most reliable approach for live Linux memory acquisition.
Memory images are large — typically 8-64 GB for modern systems — and acquisition takes several minutes. During acquisition, do not run any other programs on the system, do not allow automatic updates to run, and do not let the screen saver or power management put the system to sleep.
Disk Imaging with Write Blockers
FTK Imager (AccessData, free version available) is the industry-standard tool for creating forensic disk images. It produces images in E01 (Expert Witness Format) with MD5 and SHA-1 hash verification built in. The hash values are your proof that the image is an exact bit-for-bit copy of the original — critical for chain of custody.
A write blocker — either hardware (preferred) or software — must be interposed between the evidence drive and the forensic workstation. A write blocker prevents any write operations from reaching the evidence drive, ensuring the original is not modified during imaging. Running FTK Imager without a write blocker on a live disk may work in practice but is indefensible in court and violates forensic procedure.
Chain of Custody Documentation
Chain of custody documentation establishes an unbroken record of who had possession of evidence, when, and what was done with it. For each piece of evidence, document: a unique identifier, description of the item (make, model, serial number for hardware), date and time of collection, name and role of the person who collected it, location where it was collected, and a log of every subsequent transfer.
This documentation is not bureaucratic formality. If your forensic investigation produces evidence used in a criminal prosecution or civil litigation, a broken chain of custody can result in the evidence being excluded. It is also required for insurance claims in many policies.
Cloud Forensics Challenges
Cloud environments present unique forensic challenges. Ephemeral instances may be terminated before evidence can be collected. The shared responsibility model means your cloud provider controls the underlying infrastructure, and you may not have access to hypervisor-level logs. Volatile memory on cloud instances typically cannot be captured using the same tools as on-premises systems.
Best practice for cloud forensics: preserve the instance by taking a snapshot before terminating it, collect available cloud provider logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) immediately since they may have retention limits, and use the cloud provider's native investigation tools where available. AWS GuardDuty, Azure Sentinel, and GCP Security Command Center all have forensic investigation support features.
Working With Law Enforcement
If your incident involves criminal activity — ransomware, BEC, insider theft — the FBI Cyber Division and the U.S. Secret Service Electronic Crimes Task Force (ECTF, particularly active in NYC) are the relevant federal agencies. Engaging law enforcement is voluntary in most cases and does not obligate you to a specific response timeline.
Law enforcement has resources and legal authorities that private IR teams do not: subpoenas, legal process to cloud providers and ISPs, and intelligence on threat actor infrastructure. However, law enforcement investigations operate on their own timeline and may require you to preserve evidence in specific ways for their use.
Avoid the most common evidence contamination mistake: running antivirus or endpoint detection scans on the original evidence. AV scans modify file timestamps, may quarantine or delete malware files that you need to analyze, and alter the system state. Always work from forensic copies. Contact Fortress to discuss retaining forensic investigation support before an incident occurs.