Digital Forensics 101: Evidence After an Incident

Why Forensic Integrity Matters

When a security incident occurs, the instinct is often to immediately remediate — restore from backup, reimage the machine, reset credentials. This instinct, while understandable, can destroy critical evidence needed to understand what happened, who did it, what data was accessed, and how to prevent recurrence. In cases involving regulatory obligations or legal action, improperly handled evidence may also be inadmissible.

Digital forensics is the discipline of collecting, preserving, and analyzing digital evidence in a manner that maintains its integrity and admissibility. You don't need to be a forensics specialist to apply its core principles during an initial response — but you do need to know enough not to make things worse.

The Order of Volatility

Digital evidence ranges from highly volatile (disappears when power is cut) to persistent (survives reboots and disk replacement). Collect evidence in order from most volatile to least:

1. CPU registers and cache (lost immediately on shutdown)
2. RAM / memory contents (lost on shutdown — contains running processes, network connections, decryption keys, passwords in cleartext)
3. Network connections (current TCP state, ARP cache, routing table)
4. Running processes (process list, open file handles, loaded modules)
5. Disk contents (survives shutdown — files, logs, artifacts)
6. Remote logging and monitoring data (SIEM, syslog — already off-system)
7. Physical media and backups

Never shut down a suspected compromised system before capturing volatile data unless continuing to run it poses unacceptable risk (active ransomware encrypting files, for example).

Live System Collection

Before touching anything, document the current state:

# Capture timestamp, logged-in users, network state, process list
date > evidence_$(hostname)_$(date +%Y%m%d%H%M%S).txt
who >> evidence.txt
netstat -antp >> evidence.txt
ps aux >> evidence.txt
lsof -n >> evidence.txt
arp -a >> evidence.txt

For memory acquisition, use dedicated tools:

• Linux: LiME (Linux Memory Extractor) kernel module
• Windows: WinPmem, DumpIt, or commercial tools like Magnet RAM Capture
• macOS: OSXpmem

Write memory dumps to external media (USB drive or network share), never to the local disk of the machine being investigated — writing data modifies the filesystem you're trying to preserve.

Disk Imaging: Creating Forensic Copies

Never work directly on original evidence. Create a bit-for-bit forensic image and work only on copies:

# Create a forensic image with dd
dd if=/dev/sda of=/mnt/external/evidence.img bs=4M conv=noerror,sync status=progress

# Verify integrity with hash
sha256sum /dev/sda > original.sha256
sha256sum /mnt/external/evidence.img > copy.sha256
diff original.sha256 copy.sha256  # Must match

Prefer dcfldd or dc3dd over plain dd — they support built-in hashing during acquisition and output progress information. FTK Imager (Windows, free) provides a GUI and produces forensically sound images in E01 format.

Write the hash to your evidence log before and after imaging. The hash is the fingerprint of evidence integrity — if anyone challenges the evidence, you can prove it hasn't changed since collection.

Chain of Custody

Chain of custody is the documented trail showing who had access to evidence, when, and what was done with it. Every piece of evidence must have:

• A unique identifier (case number, evidence item number)
• Description (make, model, serial number of media; hostname and IP of a server)
• Hash values (MD5 and SHA-256)
• Collection details: who collected it, when, where, using what tools
• Transfer log: every time the evidence changes hands, it's recorded with signature

Use physical evidence bags with tamper-evident seals for hardware. For digital evidence, maintain logs in a separate system from the one being investigated.

Log Analysis: Finding the Story

Once disk images and memory dumps are secured, analysis begins. Key artifacts to examine:

• Authentication logs: /var/log/auth.log (Linux), Windows Security Event Log (Event ID 4624/4625 for logon success/failure)
• Web server logs: access logs showing URLs, user agents, source IPs, response codes
• Shell history: .bash_history, .zsh_history — attackers often forget to clear these
• Persistence mechanisms: cron jobs, systemd services, Windows Run keys, startup folders, WMI subscriptions
• Prefetch files (Windows): record of recently executed programs — useful to prove a tool was run
• Browser artifacts: history, downloads, cached credentials

Tools like Autopsy (open-source), Volatility (memory analysis), and Plaso/log2timeline (timeline generation) automate much of the artifact extraction.

Building a Timeline

The most valuable forensic output is often a timeline of events — mapping attacker actions chronologically:

1. Initial access (phishing email opened at 14:32 UTC)
2. Malware execution (cmd.exe spawned from Word process at 14:33)
3. Reconnaissance (net user, whoami commands at 14:34)
4. Lateral movement (connection to 10.0.0.15 via RDP at 14:51)
5. Data exfiltration (large outbound transfer to 203.0.113.42 at 16:20)

Plaso ingests dozens of log formats and artifact types to build unified timelines. Accurate timekeeping across systems requires consistent NTP configuration — discrepancies in system clocks complicate correlation.

Document everything as you go. Your analysis notes are evidence too.