Fundamentals
T1562.001Live 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
| Scenario | Action | Why |
|---|---|---|
| Active attacker presence | Capture memory and network state first | The attacker may disconnect, delete evidence, or destroy the system |
| Critical production system | Live collection, then disk image after failover | Shutting down may impact operations |
| Encrypted filesystem | Capture from memory (contains decryption keys) | Power-off makes the filesystem unreadable |
| Ransomware in progress | Capture memory immediately (contains encryption keys/running encryptor) | Encryptor may finish and clean up |
| Legal hold / court admissibility | Follow strict chain of custody for both live and dead collection | Deviation 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.
| Order | Data | Volatility | Windows Collection | Linux Collection |
|---|---|---|---|---|
| 1 | Memory (RAM) | Seconds to minutes | dumpit.exe, winpmem, Magnet RAM Capture | lime-ko, fmem, avml |
| 2 | Network connections | Seconds | netstat -ano, arp -a, net session | ss -tunap, netstat -tunap, arp -n |
| 3 | Running processes | Seconds to minutes | tasklist /v, Get-Process (PowerShell) | ps auxf, pstree, lsof, lsmod |
| 4 | Logged-in users | Minutes | qwinsta, net session, Get-LocalUser | w, who, last, lastlog, users |
| 5 | Open files/handles | Minutes | Sysinternals handle.exe, openfiles | lsof, fuser |
| 6 | Registry/system state | Minutes to hours | reg save, Sysinternals Autoruns | /proc, /sys |
| 7 | Event logs | Hours to days | wevtutil, PowerShell Get-WinEvent | /var/log/* (journalctl for systemd) |
| 8 | Disk | Days to months | dd, FTK Imager, Guymager | dd, 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
| Tool | Source | Command | Notes |
|---|---|---|---|
| dumpit.exe (Magnet Forensics) | Magnet Forensics | dumpit.exe /accepteula | Easy one-command capture. Output: mement.raw |
| winpmem | Velociraptor project | winpmem_mini_x64.exe mem.raw | Open source, works on most Windows versions. |
| FTK Imager | AccessData | Use the memory capture option | GUI-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
| Tool | Source | Command | Notes |
|---|---|---|---|
| LiME (Linux Memory Extractor) | GitHub | insmod lime.ko "path=mem.lime format=lime" | Kernel module — must be compiled for the target kernel |
| AVML (Acquire Volatile Memory for Linux) | Microsoft | avml mem.raw | Pre-compiled binary, more portable |
| fmem | GitHub | insmod fmem.ko | Kernel 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
| Field | Value |
|---|---|
| Case number | INC-2026-XXX |
| System hostname | victim-pc-01 |
| IP address | 192.168.1.100 |
| Date/time (UTC) | 2026-05-24 12:30:00 UTC |
| Collector | Analyst Name |
| Method | dumpit.exe v1.3.0 |
| File | memdump.raw |
| Hash (SHA256) | ABC123…XYZ |
| Chain of custody | Collected on USB; USB stored in evidence locker |
| Notes | System was running with active C2 connection at collection time |
Common Pitfalls
| Pitfall | Why It Is a Problem | How to Avoid |
|---|---|---|
| Running collection tools from the compromised system’s disk | Tool may be compromised or replaced by the attacker | Always run forensics tools from a trusted USB or network share |
| Rebooting before memory capture | Destroys all memory evidence — no recovery possible | Capture memory first, never reboot |
| Not hashing at collection time | Taints chain of custody — no way to prove evidence was not modified | Hash every file immediately after collection |
| Incomplete documentation | Evidence may not be admissible in court if chain of custody is broken | Document every step: time, tool, file, hash, location |
| Running untrusted commands | Commands may activate malware triggers (e.g., tasklist triggers a defense evasion technique) | Use trusted binaries, minimize interaction with the system |
| Overwriting critical evidence | Writing collection output to the same partition being investigated | Always write to a separate volume (USB, network share) |
Related
- Digital Forensics & Live Response — detection and response for T1562.001 techniques
- Windows Event Logging & Audit Policy — detection and response for T1562 techniques
- EDR Basics — detection and response for T1059, T1003, T1055, T1204, T1562 techniques
- Indicators: IoC, IoA, and TTP — covers the indicators: ioc, ioa, and ttp concepts
- SIEM Log Management — detection and response for TA0040 techniques
