Stackvora.tech

Preserve Evidence Before You Reboot

When responding to a security incident on a compromised system, the immediate impulse might be to isolate the host and initiate a reboot. However, a…

When responding to a security incident on a compromised system, the immediate impulse might be to isolate the host and initiate a reboot. However, a premature reboot can irretrievably destroy volatile evidence crucial for understanding the attack, identifying persistence mechanisms, and determining the scope of compromise. This guide outlines essential steps for preserving forensic evidence on a live system before any power cycle or system modification occurs.

The methodologies described apply primarily to Windows and Linux/Unix-like operating systems. While specific tool versions and command outputs may vary, the underlying principles of volatile data acquisition remain consistent. Always work from a trusted forensic workstation or an isolated, clean media to minimize contamination of the suspect system.

Volatile Memory Acquisition

Memory (RAM) contains a wealth of ephemeral data, including running processes, open network connections, loaded kernel modules, decrypted keys, and even fragments of deleted files. Capturing a memory image is often the highest priority.

Windows Systems

For Windows, several tools can acquire memory. Prioritize those that can run with minimal footprint and without introducing new drivers if possible. Administrator privileges are required.

  • WinPmem (now part of Rekall/GRR): A standalone utility that can dump physical memory to a file. It's often preferred for its reliability and minimal impact. Download the appropriate version (e.g., winpmem_x64.exe) to a clean USB drive and execute from there.
E:\tools\winpmem_x64.exe -o C:\forensics\memdump.raw

This command saves the memory image to C:\forensics\memdump.raw. Ensure the target drive has sufficient free space (typically 1.5-2x RAM size). Consider writing directly to an external, network-attached, or USB drive to avoid writing to the suspect system's disk.

  • FTK Imager Lite: While primarily a disk imaging tool, FTK Imager Lite (a portable version) can also capture physical memory. Launch it, go to "File" > "Capture Memory," and specify an output path. This is a GUI tool, which might be slower or riskier in some scenarios due to more complex interactions.

Linux Systems

On Linux, memory acquisition often involves direct interaction with kernel devices or specialized tools.

  • AVML (Acquire Volatile Memory for Linux): A common choice, developed by Microsoft. It uses /dev/crash or /dev/mem if available, or alternatively loads a kernel module (LiME) to perform the dump.
./avml /mnt/forensics/memory.raw

Ensure avml is run from a trusted external media. The output file memory.raw will be written to the specified path. This tool attempts to acquire memory without modifying the system significantly.

  • LiME (Linux Memory Extractor): A loadable kernel module (LKM) that allows for memory acquisition. You need to compile it for the specific kernel version of the target system.
# On a build system with matching kernel headers:
git clone https://github.com/504ensicsLabs/LiME.git
cd LiME/src
make

# On the target system:
sudo insmod lime.ko "path=/mnt/forensics/lime_mem.raw format=raw"

LiME requires careful preparation to match kernel versions, which can be challenging during a live incident. AVML or other pre-compiled tools are often preferred if available.

Network Connection and Process Information

Understanding current network activity and associated processes is critical for identifying command-and-control channels, data exfiltration, or active attacks. Capture this data before the threat actor can sever connections.

Windows Systems

  • netstat: A fundamental command-line utility.
netstat -ano > C:\forensics\netstat_output.txt

This command lists all active TCP connections and listening ports (-a), displays numerical addresses and port numbers (-n), and shows the Process ID (PID) associated with each connection (-o). Redirecting output to a file is crucial.

  • tasklist: To map PIDs to process names.
tasklist /svc > C:\forensics\tasklist_svc.txt
tasklist /m > C:\forensics\tasklist_modules.txt

/svc shows services hosted by processes. /m lists DLLs loaded by each process, which can sometimes reveal injected malware.

  • ipconfig /all: For detailed network interface configuration.
ipconfig /all > C:\forensics\ipconfig_all.txt

Linux Systems

  • ss: A modern replacement for netstat, often faster and more feature-rich.
ss -tanp > /mnt/forensics/ss_output.txt

-t for TCP, -a for all sockets, -n for numerical addresses, -p to show the process using the socket. This requires root privileges.

  • netstat (legacy, but still useful if ss isn't available or for comparison):
netstat -tunap > /mnt/forensics/netstat_output.txt

-t for TCP, -u for UDP, -n for numerical addresses, -a for all, -p for process info.

  • ps: For process listing.
ps auxef > /mnt/forensics/ps_full.txt

aux for all users, including those without a TTY; e for environment; f for full format. This is extremely verbose and captures parent-child process relationships.

  • lsof: List open files, including network sockets.
lsof -i > /mnt/forensics/lsof_network.txt

-i lists all open network files.

  • ifconfig -a or ip a: For network interface configuration.
ip a > /mnt/forensics/ip_addr.txt

File System and Disk Imaging

After volatile data, the disk image is the most comprehensive form of evidence. A bit-for-bit copy ensures that all files, including deleted ones, and unallocated space are preserved.

General Principles

  • Write Blocker: Always use a hardware write-blocker when connecting the suspect drive to a forensic workstation. This prevents any accidental writes to the evidence. For live imaging (booting from the suspect system), the imaging software itself must ensure read-only access where possible, or write to an entirely separate, clean destination.
  • Destination Drive: The destination drive for the image must be equal to or larger than the source drive. It should be a known-good, clean drive.
  • Hashing: Calculate cryptographic hashes (SHA256, MD5) of the source drive (if possible before imaging) and the resulting image file. This verifies integrity.

Windows Systems

  • FTK Imager Lite: While it can capture memory, its primary strength is disk imaging. Run the portable version from a clean USB drive. Go to "File" > "Create Disk Image," select "Physical Drive," choose the suspect drive, and specify a destination path on an external drive. You can choose output formats like E01 (EnCase) or raw (DD). E01 is often preferred as it includes metadata, compression options, and error handling.
# Example: Using FTK Imager GUI to create an E01 image
# 1. Launch FTK Imager Lite (e.g., from E:\tools\FTK_Imager_Lite\FTK Imager.exe)
# 2. File -> Create Disk Image
# 3. Select "Physical Drive" and click Next
# 4. Choose the suspect drive (e.g., "Physical Drive 0 - [Size] [Model]") and click Next
# 5. Select "Add..." and choose "E01" (EnCase Evidence File) or "DD" (Raw (dd))
# 6. Fill in Case Information (Case Number, Evidence Number, Unique Description, Examiner, Notes)
# 7. Specify Image Destination:
#    Image Destination Folder: F:\Evidence\VictimHost1_DiskImage
#    Image File Name: VictimHost1_Drive0
#    Image Fragment Size: 4096 (MB) - for large drives, this splits the image into chunks
#    Compression: 1 (fastest) to 9 (best) - consider speed vs. space. 3-6 is often a good balance.
# 8. Click Start.

Linux Systems

  • dd: The classic Unix utility for raw disk copying. It's powerful but unforgiving; a wrong parameter can overwrite data.
# First, identify the suspect disk (e.g., /dev/sda, /dev/nvme0n1)
lsblk

# Example: Imaging /dev/sda to an external USB drive mounted at /mnt/forensics
sudo dd if=/dev/sda of=/mnt/forensics/disk_image.dd bs=4M status=progress conv=noerror,sync

if=/dev/sda is the input file (source disk). of=/mnt/forensics/disk_image.dd is the output file (destination image). bs=4M sets the block size for efficient copying. status=progress shows progress (Linux coreutils 8.24+). conv=noerror,sync is crucial: noerror continues on read errors, and sync pads input blocks with zeros to the block size, preventing misalignment issues and preserving data structures even with errors.

  • dcfldd: A forensic version of dd that includes hashing on-the-fly, status reporting, and verification.
sudo dcfldd if=/dev/sda of=/mnt/forensics/disk_image.dd hash=sha256 hashlog=/mnt/forensics/disk_image.sha256log status=on conv=noerror,sync

This command will compute a SHA256 hash of the source data as it's read and log it. It's highly recommended over plain dd for forensic purposes.

Logging and System Artifacts

Beyond memory and disk, various logs and system artifacts provide context. Copy these to your forensics drive.

  • Windows Event Logs: Export security, system, application, and any custom logs (e.g., PowerShell Operational).
wevtutil el > C:\forensics\event_logs_list.txt
wevtutil epl Security C:\forensics\Security.evtx
wevtutil epl System C:\forensics\System.evtx
wevtutil epl Application C:\forensics\Application.evtx
wevtutil epl "Microsoft-Windows-PowerShell/Operational" C:\forensics\PowerShell_Operational.evtx
  • Windows Registry Hives: Copy the raw registry files (e.g., SAM, SECURITY, SYSTEM, SOFTWARE, NTUSER.DAT from user profiles) from %SystemRoot%\System32\config and user profile directories. Note that live registry access is often done via tools, but copying the raw hives can be useful for offline analysis.
  • Linux Logs: Copy relevant log directories.
sudo cp -r /var/log /mnt/forensics/var_log_backup
sudo journalctl --no-pager > /mnt/forensics/journalctl_full.txt

The /var/log directory contains system logs (syslog, auth.log, messages), web server logs, etc. journalctl provides access to the systemd journal.

Chain of Custody Documentation

Document every action taken, no matter how small. This ensures the evidence remains admissible and verifiable.

  • Incident Details: Date, time, incident number, location, system name, IP address.
  • Responder Details: Name, organization, contact.
  • Tools Used: Exact tool names, versions, and their source (e.g., winpmem_x64.exe v2.1.b1, downloaded from rekall-forensic.com).
  • Actions Performed: Each command executed, each file copied, with timestamps.
  • Evidence Identifiers: Hash values of memory dumps, disk images, and copied files.
  • Storage Media: Serial numbers or unique identifiers of external drives used for evidence collection.
  • Condition of System: Visual inspection notes, photographs (if permissible and safe).

Use a physical evidence bag and seal it. Label with incident details and unique identifiers. If passing evidence to another party, ensure they sign off on the transfer, creating a clear record of custody.

Common Pitfalls

  • Writing to the Suspect System: Accidentally installing tools or writing output files to the compromised system. Always use external, clean media for tools and output.
  • Not Enough Space: Underestimating the required space for memory dumps and disk images. Ensure destination drives are sufficiently large.
  • Forgetting Hashes: Failing to compute and record cryptographic hashes for all acquired evidence, which can later cast doubt on its integrity.
  • Lack of Documentation: Not documenting each step meticulously. Memory is fallible; a detailed log is indispensable for later analysis and legal proceedings.
  • Premature Reboot/Shutdown: The most critical mistake, leading to the irreversible loss of volatile data. Always prioritize volatile evidence acquisition before any power state change.
  • Incorrect Tool Usage: Using dd with incorrect parameters, potentially overwriting the source disk, or using tools that are not forensically sound.

Back to the knowledge base · Ask the AI assistant