Forensic Artifact Collection

The Clock Is Ticking

When you respond to a compromised system, evidence is being destroyed every second. Running processes exit, logs rotate, temporary files are deleted, and memory is overwritten. The order of volatility defines which evidence must be captured first because it disappears fastest.

RFC 3227 defines the order of volatility from most volatile to least volatile:

1. CPU registers and cache — nanoseconds to milliseconds
2. Routing tables, ARP cache, process table, kernel statistics — seconds to minutes
3. Memory (RAM) — minutes to hours (persists until power loss)
4. Temporary file systems — hours to days
5. Disk (persistent storage) — days to years
6. Remote logs and monitoring data — weeks to years
7. Physical configuration, network topology — permanent
8. Backup media — permanent

The rule: capture the most volatile evidence first. If you image the disk before capturing memory, you lose all running process data, network connections, and encryption keys.

Memory Capture

Memory is the most valuable forensic artifact on a live system. It contains:

• Running processes — including hidden or rootkit processes
• Network connections — active and recent connections, including C2 channels
• Loaded drivers — including malicious drivers
• Encryption keys — for encrypted volumes and TLS sessions
• Credentials — plaintext passwords and hashes in memory
• Injected code — reflective DLL injection, process hollowing
• Command history — recent commands executed by attackers

# Memory capture on Linux using LiME
# Build LiME kernel module against the target kernel headers
make -C /lib/modules/$(uname -r)/build M=$(pwd) modules

# Load the module and capture memory
insmod lime.ko "path=/mnt/evidence/memdump.lime format=lime"

# Verify the capture
ls -lh /mnt/evidence/memdump.lime
sha256sum /mnt/evidence/memdump.lime > /mnt/evidence/memdump.lime.sha256

# Memory capture on Windows using WinPmem
winpmem_mini_x64.exe -o C:\evidence\memdump.raw

# Verify hash
certutil -hashfile C:\evidence\memdump.raw SHA256

Memory capture must be performed before any other action on the live system. Do not run antivirus scans, do not reboot, do not install tools on the system — all of these modify memory.

Live System Artifacts

Before powering off the system, collect these volatile artifacts:

# Running processes
ps aux > /mnt/evidence/processes.txt

# Network connections
netstat -tunap > /mnt/evidence/netstat.txt
ss -tunap > /mnt/evidence/ss.txt

# ARP cache
arp -a > /mnt/evidence/arp.txt

# Routing table
ip route > /mnt/evidence/route.txt

# Open files
lsof > /mnt/evidence/lsof.txt

# Mounted filesystems
mount > /mnt/evidence/mount.txt

# System uptime and time
uptime > /mnt/evidence/uptime.txt
date > /mnt/evidence/date.txt

Each command modifies the system slightly (it runs a process), so minimize the number of commands and capture the most critical artifacts first.

Disk Imaging

After volatile evidence is captured, image the disk. A forensic disk image is a bit-for-bit copy of the entire drive, including deleted files, unallocated space, and slack space.

# Disk imaging with dd (Linux)
# Use a write blocker to prevent any writes to the source drive
dd if=/dev/sda of=/mnt/evidence/disk-sda.dd bs=4M conv=noerror,sync status=progress

# Calculate hash for integrity verification
sha256sum /mnt/evidence/disk-sda.dd > /mnt/evidence/disk-sda.dd.sha256

# Disk imaging on Windows using FTK Imager
# Create a forensic image (E01 format) of the physical drive
# FTK Imager > Create Disk Image > Physical Drive > Select source
# Output: E01 format with compression and hashing

The E01 format (Expert Witness Format) is the industry standard for forensic disk images. It includes compression, hashing, and metadata about the imaging process. The raw dd format is simpler but lacks built-in integrity verification.

Write Blockers

A write blocker is a hardware or software device that prevents any writes to the source drive during imaging. This is essential for evidence integrity — if the source drive is modified during imaging, the evidence is no longer a true copy and may be inadmissible in court.

Hardware write blocker:  Source Drive → [Write Blocker] → Forensic Workstation
Software write blocker:  Linux: blockdev --setro /dev/sda
                        Windows: diskpart > attributes disk set readonly

Always use a write blocker when imaging a drive that will be used as evidence. The hash verification (SHA-256) proves that the image is identical to the original, but only if the original was not modified during imaging.

Evidence That Stands Up in Court

Forensic evidence is only valuable if it is admissible in legal proceedings. Admissibility requires proof that the evidence was not tampered with, altered, or contaminated from the moment of collection through presentation in court. The chain of custody is the documentation that proves this.

What Is Chain of Custody?

Chain of custody is a chronological document that tracks every person who handled the evidence, what they did with it, when they did it, and where it was stored. It answers:

• Who collected the evidence?
• When and where was it collected?
• Who has handled the evidence since collection?
• What was done with the evidence (analysis, copying, transport)?
• Where has the evidence been stored?
• How was the evidence protected from tampering?

Any gap in the chain of custody — a period where the evidence was unaccounted for — can be used to challenge its admissibility.

Chain of Custody Form

Chain of Custody Form

Evidence ID: IR-2026-0930-001-E001
Description: Seagate 2TB HDD, Serial: Z4D0A1B2C3
Collected from: WS-042, 10.0.2.15, Finance Department
Collected by: J. Smith, IR Team
Collection date: 2026-09-30 15:30 UTC
Collection method: dd forensic image with hardware write blocker
Image hash (SHA-256): a1b2c3d4e5f6...

Custody Log:
| Date/Time | Handler | Action | Location |
|-----------|---------|--------|----------|
| 2026-09-30 15:30 | J. Smith | Collected and imaged | WS-042 |
| 2026-09-30 16:00 | J. Smith | Transported to IR lab | IR Lab |
| 2026-09-30 16:15 | M. Chen | Received and verified hash | IR Lab |
| 2026-09-30 16:30 | M. Chen | Stored in evidence locker | Locker #12 |
| 2026-10-01 09:00 | M. Chen | Checked out for analysis | IR Lab |
| 2026-10-01 17:00 | M. Chen | Returned to evidence locker | Locker #12 |

Evidence Storage

Evidence must be stored in a physically secure location with access controls:

• Evidence locker — locked cabinet with access logging
• Access control — only authorized personnel can access
• Environmental controls — temperature and humidity controlled to prevent media degradation
• Write protection — evidence media is stored write-protected

Hash Verification

Cryptographic hashes (SHA-256) prove that evidence has not been altered:

# Calculate hash of original evidence
sha256sum /mnt/evidence/disk-sda.dd
# Output: a1b2c3d4e5f6...

# Verify hash at any time — must match the original
sha256sum -c /mnt/evidence/disk-sda.dd.sha256
# Output: /mnt/evidence/disk-sda.dd: OK

The hash is calculated at collection time and verified every time the evidence is accessed. If the hash does not match, the evidence has been altered and is no longer admissible.

Forensic Workstation Hygiene

The forensic workstation used for analysis must be clean and isolated:

• No internet connection — prevents remote access and malware infection
• Write blockers — all evidence drives are mounted read-only
• Forensic tools — only validated, tested tools (FTK, EnCase, Autopsy, Volatility)
• Documentation — every action on the workstation is logged

# Mount evidence image read-only with loop device
mount -o ro,loop /mnt/evidence/disk-sda.dd /mnt/forensic/analysis

# Verify the mount is read-only
mount | grep /mnt/forensic/analysis
# Output: /dev/loop0 on /mnt/forensic/analysis type ext4 (ro,relatime)

Common Chain of Custody Mistakes

1. No documentation — collecting evidence without recording who, when, where, and how
2. Gaps in custody — evidence left unattended or unaccounted for
3. No hash verification — cannot prove the evidence was not altered
4. Improper storage — evidence stored in unsecured locations
5. Analysis on original evidence — always analyze a forensic copy, never the original
6. No write protection — evidence modified during collection or analysis

The chain of custody is not bureaucracy — it is what separates forensic evidence from hearsay. Without it, the most compelling forensic findings are worthless in court.

The Artifacts That Tell the Story

Different attack types leave different artifacts. A comprehensive collection covers the categories most relevant to the incident type.

Windows Artifacts

Event Logs

Windows event logs are the primary source of forensic evidence on Windows systems:

• Security.evtx — authentication (4624, 4625), privilege use (4672), process creation (4688), object access
• System.evtx — service installation, driver loading, system crashes
• Application.evtx — application errors and warnings
• PowerShell.evtx — PowerShell script block logging (4104), module logging
• Sysmon — process creation with full command line, network connections, file creation, registry modifications

# Export Windows event logs for analysis
wevtutil epl Security C:\evidence\Security.evtx
wevtutil epl System C:\evidence\System.evtx
wevtutil epl "Windows PowerShell" C\evidence\PowerShell.evtx

Registry Hives

The Windows registry contains evidence of:

• Persistence — Run keys, services, scheduled tasks, WMI subscriptions
• User activity — recent files, typed URLs, USB device history
• Configuration — security settings, installed software, network configuration

# Copy registry hives (from a live system or mounted image)
cp /mnt/forensic/analysis/Windows/System32/config/SYSTEM /mnt/evidence/SYSTEM
cp /mnt/forensic/analysis/Windows/System32/config/SOFTWARE /mnt/evidence/SOFTWARE
cp /mnt/forensic/analysis/Windows/System32/config/SAM /mnt/evidence/SAM
cp /mnt/forensic/analysis/Windows/System32/config/SECURITY /mnt/evidence/SECURITY

Prefetch and Amcache

Prefetch files show which programs were executed and when. Amcache shows program installation and execution history. Both are valuable for determining what ran on the system.

# Prefetch files
C:\Windows\Prefetch\*.pf

# Amcache
C:\Windows\AppCompat\Programs\Amcache.hve

MFT (Master File Table)

The NTFS MFT contains metadata for every file on the volume — creation time, modification time, access time, and file size. The MFT can reveal files that were deleted but not yet overwritten.

Linux Artifacts

Authentication Logs

# Copy authentication logs
cp /mnt/forensic/analysis/var/log/auth.log /mnt/evidence/
cp /mnt/forensic/analysis/var/log/secure /mnt/evidence/
cp /mnt/forensic/analysis/var/log/wtmp /mnt/evidence/  # login history
cp /mnt/forensic/analysis/var/log/btmp /mnt/evidence/  # failed logins
cp /mnt/forensic/analysis/var/log/lastlog /mnt/evidence/  # last login per user

Shell History

# Copy shell history for all users
for user_home in /mnt/forensic/analysis/home/*; do
    cp "$user_home/.bash_history" /mnt/evidence/"$(basename $user_home)"_bash_history 2>/dev/null
    cp "$user_home/.zsh_history" /mnt/evidence/"$(basename $user_home)"_zsh_history 2>/dev/null
done
cp /mnt/forensic/analysis/root/.bash_history /mnt/evidence/root_bash_history 2>/dev/null

Cron Jobs and Systemd Timers

# Copy cron jobs
cp -r /mnt/forensic/analysis/etc/cron* /mnt/evidence/
for user_home in /mnt/forensic/analysis/home/*; do
    cp "$user_home/.crontab" /mnt/evidence/"$(basename $user_home)"_crontab 2>/dev/null
done

# Copy systemd timers
cp -r /mnt/forensic/analysis/etc/systemd /mnt/evidence/systemd

Journal Logs

# Export journald logs
journalctl --directory=/mnt/forensic/analysis/var/log/journal -o short-iso > /mnt/evidence/journald-export.txt

Network Artifacts

Firewall Logs

Firewall logs show allowed and denied connections, VPN sessions, and NAT translations. They reveal which external IPs the compromised system communicated with.

NetFlow/sFlow Data

NetFlow data provides metadata about network conversations — source/destination IP, ports, byte counts, and duration — without capturing full packet content. It is valuable for identifying C2 communication patterns and data exfiltration.

Packet Captures

Full packet captures provide the most detailed network evidence but are storage-intensive. Capture packets only when necessary — for example, when analyzing a specific C2 protocol or data exfiltration.

# Capture packets on a specific interface
tcpdump -i eth0 -w /mnt/evidence/capture.pcap -c 10000

Cloud Artifacts

CloudTrail / Activity Logs

Cloud audit logs show API calls made in the cloud environment — who did what, from where, and when. They are essential for investigating cloud compromises.

VPC Flow Logs

VPC flow logs capture network traffic metadata in cloud environments, equivalent to NetFlow on premises.

Snapshot and Image

Create snapshots of compromised cloud instances before terminating them. A snapshot preserves the entire instance state for forensic analysis.

# Create a snapshot of a compromised EC2 instance
aws ec2 create-snapshot --volume-id vol-1234567890abcdef0 --description "IR-2026-0930-001 forensic snapshot"