Fundamentals

T1562.001

Live Forensics Collection

A practical guide for SOC analysts on live forensics collection — what to capture, in what order, with which tools, and how to preserve evidence integrity during incident response.

View on Graph

What Live Forensics Is and When to Use It

  • Live forensics is the collection of volatile evidence from a running system during an incident. It is performed when the cost of downtime from shutting down the system outweighs the value of a pristine disk image, or when the attacker’s active presence means you need to capture evidence that would be lost on shutdown (memory, network connections, running processes).
  • It contrasts with dead-box forensics (analysis of a powered-off system image), which preserves disk state but loses all volatile data.
  • The fundamental rule: every action you take changes the system state. Your goal is to minimize the footprint of your collection while capturing the highest-value evidence first.
  • MITRE ATT&CK maps techniques used to impair forensic collection under T1562.001 (Disable or Modify Tools) — attackers frequently target forensic tools, event logs, and memory capture utilities. Live forensics must account for the possibility that the attacker is actively trying to subvert the collection process.

When to Perform Live Forensics

ScenarioActionWhy
Active attacker presenceCapture memory and network state firstThe attacker may disconnect, delete evidence, or destroy the system
Critical production systemLive collection, then disk image after failoverShutting down may impact operations
Encrypted filesystemCapture from memory (contains decryption keys)Power-off makes the filesystem unreadable
Ransomware in progressCapture memory immediately (contains encryption keys/running encryptor)Encryptor may finish and clean up
Legal hold / court admissibilityFollow strict chain of custody for both live and dead collectionDeviation breaks evidentiary chain

The Order of Volatility

The order of volatility (OOV) determines the sequence of evidence collection — capture the most volatile (shortest-lived) data first.

OrderDataVolatilityWindows CollectionLinux Collection
1Memory (RAM)Seconds to minutesdumpit.exe, winpmem, Magnet RAM Capturelime-ko, fmem, avml
2Network connectionsSecondsnetstat -ano, arp -a, net sessionss -tunap, netstat -tunap, arp -n
3Running processesSeconds to minutestasklist /v, Get-Process (PowerShell)ps auxf, pstree, lsof, lsmod
4Logged-in usersMinutesqwinsta, net session, Get-LocalUserw, who, last, lastlog, users
5Open files/handlesMinutesSysinternals handle.exe, openfileslsof, fuser
6Registry/system stateMinutes to hoursreg save, Sysinternals Autoruns/proc, /sys
7Event logsHours to dayswevtutil, PowerShell Get-WinEvent/var/log/* (journalctl for systemd)
8DiskDays to monthsdd, FTK Imager, Guymagerdd, dcfldd, guymager

Memory Collection (Order 1)

Memory is the most valuable evidence in any forensic investigation. It contains running processes, network connections in-flight, encryption keys, malware in execution, registry keys in use, and active user credentials.

Windows — Memory Capture

ToolSourceCommandNotes
dumpit.exe (Magnet Forensics)Magnet Forensicsdumpit.exe /accepteulaEasy one-command capture. Output: mement.raw
winpmemVelociraptor projectwinpmem_mini_x64.exe mem.rawOpen source, works on most Windows versions.
FTK ImagerAccessDataUse the memory capture optionGUI-based, also captures disk

Best practice for Windows memory capture with dumpit:

# Capture memory (run from a forensics USB, not from the compromised system)
dumpit.exe /accepteula

# Verify the capture
certutil -hashfile memdump.raw SHA256

What to look for in memory analysis (Volatility 3):

# Process listing — look for hidden/unknown processes
vol -f memdump.raw windows.pslist
vol -f memdump.raw windows.psscan
vol -f memdump.raw windows.pstree

# Network connections
vol -f memdump.raw windows.netscan

# Mutexes (often unique for malware families)
vol -f memdump.raw windows.malfind

# Process cmdlines — see the exact command used to launch each process
vol -f memdump.raw windows.cmdline

# DLL injection / process hollowing detection
vol -f memdump.raw windows.malfind

# Extract executable from memory
vol -f memdump.raw windows.dumpfiles --pid <suspicious_pid>

Linux — Memory Capture

ToolSourceCommandNotes
LiME (Linux Memory Extractor)GitHubinsmod lime.ko "path=mem.lime format=lime"Kernel module — must be compiled for the target kernel
AVML (Acquire Volatile Memory for Linux)Microsoftavml mem.rawPre-compiled binary, more portable
fmemGitHubinsmod fmem.koKernel module — exposes /dev/fmem

Best practice for Linux memory capture with AVML:

# Capture memory (simplest portable option)
./avml mem.raw

# Verify
sha256sum mem.raw

Network State Collection (Order 2)

Windows — Network Evidence

# Active connections with process IDs
netstat -ano > network_connections.txt

# ARP cache
arp -a > arp_cache.txt

# DNS cache
ipconfig /displaydns > dns_cache.txt

# Routing table
route print > routing_table.txt

# NetBIOS cache
nbtstat -c > netbios_cache.txt

# Active SMB sessions
net session > smb_sessions.txt

# Firewall rules
netsh advfirewall firewall show rule name=all > firewall_rules.txt

Linux — Network Evidence

# Active connections (ss is preferred over netstat on modern systems)
ss -tunap > connections.txt

# ARP cache
arp -n > arp_cache.txt

# Listening ports
ss -tlnp > listening_ports.txt

# Routing table
route -n > routing_table.txt

# Firewall rules (iptables/nftables)
iptables-save > iptables_rules.txt
nft list ruleset > nftables_rules.txt (if using nftables)

# Active sockets with associated processes
lsof -i > socket_processes.txt

# Netfilter conntrack (active sessions tracked by the kernel)
cat /proc/net/nf_conntrack > conntrack.txt

Process and System State Collection (Order 3-5)

Windows — Process Evidence

# Full process listing with details
tasklist /v > tasklist_verbose.txt

# Process hierarchy (child/parent relationships)
wmic process get ProcessId,ParentProcessId,Name,CommandLine,ExecutablePath > processes.txt

# Services
sc query type= service state= all > services.txt

# Scheduled tasks
schtasks /query /fo LIST /v > scheduled_tasks.txt

# Autoruns (Sysinternals)
autorunsc.exe -a * -c > autoruns.csv

# Loaded drivers (kernel mode)
driverquery /v > drivers.txt

Linux — Process Evidence

# Full process tree
ps auxf > process_tree.txt

# Loaded kernel modules
lsmod > kernel_modules.txt

# Open files per process
lsof > open_files.txt

# Mounted filesystems
mount > mounted_filesystems.txt

# Cron jobs (system and user)
ls -la /var/spool/cron/crontabs/ > cron_jobs.txt
cat /etc/crontab >> cron_jobs.txt
ls /etc/cron* >> cron_jobs.txt

# Network connections with process affiliation
netstat -tunap > netstat_connections.txt

Registry and Event Logs (Order 6-7)

Windows — Registry Preservation

# Save registry hives
reg save HKLM\SAM SAM.hiv
reg save HKLM\SYSTEM SYSTEM.hiv
reg save HKLM\SECURITY SECURITY.hiv
reg save HKLM\SOFTWARE SOFTWARE.hiv
reg save HKCU\NTUSER.DAT NTUSER.DAT

Event Log Preservation

Windows:

# Export all event logs
wevtutil epl Security Security.evtx
wevtutil epl System System.evtx
wevtutil epl Application Application.evtx
wevtutil epl "Microsoft-Windows-Sysmon/Operational" Sysmon.evtx
wevtutil epl "Microsoft-Windows-PowerShell/Operational" PowerShell.evtx
wevtutil epl "Windows PowerShell" PowerShell_Classic.evtx

Linux:

# Collect system logs
rsync -a /var/log/ log_collection/
journalctl --since "2026-05-01" --until "2026-05-24" > journal_export.txt

Evidence Integrity — Chain of Custody

Every piece of evidence collected during live forensics must be documented and preserved for potential legal use:

Hashing

Hash every collected file at the time of collection:

# Windows
certutil -hashfile <filename> SHA256 > <filename>.sha256

# Linux
sha256sum <filename> > <filename>.sha256

Documentation Template

FieldValue
Case numberINC-2026-XXX
System hostnamevictim-pc-01
IP address192.168.1.100
Date/time (UTC)2026-05-24 12:30:00 UTC
CollectorAnalyst Name
Methoddumpit.exe v1.3.0
Filememdump.raw
Hash (SHA256)ABC123…XYZ
Chain of custodyCollected on USB; USB stored in evidence locker
NotesSystem was running with active C2 connection at collection time

Common Pitfalls

PitfallWhy It Is a ProblemHow to Avoid
Running collection tools from the compromised system’s diskTool may be compromised or replaced by the attackerAlways run forensics tools from a trusted USB or network share
Rebooting before memory captureDestroys all memory evidence — no recovery possibleCapture memory first, never reboot
Not hashing at collection timeTaints chain of custody — no way to prove evidence was not modifiedHash every file immediately after collection
Incomplete documentationEvidence may not be admissible in court if chain of custody is brokenDocument every step: time, tool, file, hash, location
Running untrusted commandsCommands may activate malware triggers (e.g., tasklist triggers a defense evasion technique)Use trusted binaries, minimize interaction with the system
Overwriting critical evidenceWriting collection output to the same partition being investigatedAlways write to a separate volume (USB, network share)

Sources