How to Collect Volatile Evidence During Incident Response (Step-by-Step)

TL;DR - Capture volatile data first (RAM, running processes, network connections) before rebooting or “cleaning.” - Use a minimal, repeatable live-response kit; timestamp and hash everything; keep chain-of-custody notes. - Prioritize memory acquisition ASAP—then process/network triage—because volatility and attacker actions can erase it fast.

Short Answer (under 60 words)

Collect volatile evidence in order of volatility: acquire RAM first, then capture running processes, network connections, logged-on users, and critical system state. Minimize changes to the system, record timestamps and commands, and hash all outputs. Avoid rebooting, uninstalling tools, or “cleanup” until volatile collection and scoping are complete.

Detailed Explanation

Volatile evidence is any data that can disappear quickly when a system changes state (power-off, reboot, process exit, log rotation, attacker cleanup). In incident response, volatile evidence often contains the fastest path to: initial access clues, malware payloads, decrypted secrets in memory, command execution history, C2 endpoints, and lateral movement context.

A practical, defensible approach is based on the order of volatility and a workflow that balances speed with evidence integrity.

1) Prepare before you touch the host (triage decisions)

Before running commands on an impacted endpoint or server, decide:

Is the system safe to interact with? If it’s a critical domain controller or production database, coordinate with stakeholders. If ransomware is actively encrypting, you may need containment first (isolate at the switch/EDR) while preserving power.
Do you need containment before collection? Containment (network isolation) can prevent further harm, but it may also cut off attacker C2 and cause them to self-delete. When possible, isolate at the network layer while keeping the host powered on.
What’s your evidence goal? Typical goals: identify malware, capture credentials/tokens, map attacker activity, or preserve evidence for legal/insurance.

Key principle: every action changes the system. Your job is to make those changes minimal, recorded, and repeatable.

2) Follow the order of volatility (what to capture first)

A commonly used priority sequence:

RAM / memory image (highest value, most volatile)
Running processes and loaded modules
Network state (connections, listeners, routing, ARP, DNS cache)
Logged-on users, sessions, scheduled tasks, services
Event logs / audit trails (still “semi-volatile” due to rotation)
Disk artifacts (less volatile; image later if feasible)

If you can only do one thing under pressure: capture memory.

3) Use a minimal live-response kit (and avoid “tool sprawl”)

Your live-response kit should be: - Known-good binaries/scripts (pre-staged, hashed) - Able to run from write-once media (where possible) or a controlled directory - Configured to output to an external destination (USB with controlled handling, or a secured network share if appropriate)

Record: - Who executed actions - Hostname, IP, time source - Commands run and outputs - Where evidence was stored - Hashes (SHA-256) of collected files

If the incident may require escalation to an outside team, aligning your workflow with a managed detection and response provider can reduce rework—see our glossary entry: what is mdr.

4) Collect volatile evidence (practical capture set)

At minimum, aim to capture:

Memory acquisition
Process list (and command lines)
Network connections & listeners
DNS cache / resolver state
ARP table, routing table
Logged-on users & sessions
Persistence indicators (services, scheduled tasks, autoruns—captured as text output)
Time context (system time, timezone, uptime)
EDR metadata (if present): detection IDs, process trees, quarantine status

If you suspect credential theft or token abuse, memory becomes even more critical: secrets may exist only in RAM.

5) Preserve integrity: hashes, timestamps, and chain of custody

For each artifact you collect: - Write down start/end time and command - Save output to a clearly named file (host-date-artifact) - Hash it (SHA-256 preferred) - Keep a simple chain-of-custody log (even for internal IR)

If legal action is possible, consult counsel early and avoid mixing investigative notes with privileged communications.

6) Decide next steps: containment, imaging, and remote collection

After volatile capture: - Consider full disk imaging (or targeted acquisition) for deeper forensics - Export relevant logs centrally (Windows Event Logs, syslog, EDR telemetry) - Apply containment actions (disable accounts, rotate credentials, block IOCs) based on evidence and scope—not guesses

When you’re ready to harden endpoints after containment, compare tools and operating models (EDR vs. AV vs. suites) here: best antivirus for windows business endpoints 2026.

Technical Deep Dive

Technical Notes: Minimal “order of operations” checklist

1) Photograph/screenshot if needed (e.g., ransomware note on console)
2) Record system time, uptime, network identity
3) Acquire RAM
4) Capture process + network + sessions
5) Export key logs
6) Only then proceed to containment/eradication steps that alter state

Technical Notes: Windows collection (built-in commands)

Run in an elevated prompt where appropriate; redirect output to an external drive or controlled folder.

:: Create evidence directory
mkdir E:\IR\HOSTNAME_%DATE%
cd /d E:\IR\HOSTNAME_%DATE%

:: Time and host context
echo === DATE/TIME === > 00_time.txt
date /t >> 00_time.txt
time /t >> 00_time.txt
wmic os get LocalDateTime /value >> 00_time.txt
systeminfo > 01_systeminfo.txt
wmic qfe list brief > 02_patches.txt

:: Processes + services + drivers
tasklist /v > 10_tasklist_v.txt
wmic process get ProcessId,ParentProcessId,Name,CommandLine /format:csv > 11_process_cmdline.csv
sc query type= service state= all > 12_services.txt
driverquery /v > 13_drivers.txt

:: Network state
ipconfig /all > 20_ipconfig_all.txt
netstat -ano > 21_netstat_ano.txt
arp -a > 22_arp.txt
route print > 23_route_print.txt
netsh winhttp show proxy > 24_winhttp_proxy.txt

:: Users and sessions
whoami /all > 30_whoami_all.txt
query user > 31_query_user.txt
net localgroup administrators > 32_local_admins.txt

:: Scheduled tasks and persistence signals
schtasks /query /fo LIST /v > 40_schtasks_verbose.txt

:: Event logs export (examples)
wevtutil epl Security 50_security.evtx
wevtutil epl System 51_system.evtx
wevtutil epl Microsoft-Windows-Sysmon/Operational 52_sysmon.evtx

Memory acquisition (Windows): Use a trusted memory capture tool approved by your organization (e.g., WinPmem or similar). The exact command depends on the tool and version. Whatever you use, record: - tool name/version - command line - output path - resulting file hash

Hash outputs:

certutil -hashfile 10_tasklist_v.txt SHA256 > hashes_sha256.txt
certutil -hashfile 50_security.evtx SHA256 >> hashes_sha256.txt

Log patterns to look for quickly (Windows): - New service creation, scheduled tasks, suspicious parent/child process chains - Unusual outbound connections (rare ports, external IPs, netstat -ano PIDs matching unknown processes) - Security log events around logons, privilege use, and account changes (availability varies by audit policy)

Technical Notes: Linux collection (common commands)

Prefer root where possible. Output to a mounted external path or a secure remote collector.

OUT="/mnt/ir/$(hostname)_$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$OUT"

# Time and host context
date -u +"%Y-%m-%dT%H:%M:%SZ" | tee "$OUT/00_time_utc.txt"
uname -a > "$OUT/01_uname.txt"
uptime > "$OUT/02_uptime.txt"
hostnamectl > "$OUT/03_hostnamectl.txt" 2>/dev/null || true

# Processes and sessions
ps auxwwf > "$OUT/10_ps_auxwwf.txt"
pstree -ap > "$OUT/11_pstree_ap.txt" 2>/dev/null || true
who -a > "$OUT/12_who_a.txt"
w > "$OUT/13_w.txt"
last -a | head -200 > "$OUT/14_last_head200.txt"

# Network state
ip a > "$OUT/20_ip_addr.txt"
ip r > "$OUT/21_ip_route.txt"
ss -tpanu > "$OUT/22_ss_tpanu.txt"
arp -n > "$OUT/23_arp.txt" 2>/dev/null || ip neigh > "$OUT/23_ip_neigh.txt"
cat /etc/resolv.conf > "$OUT/24_resolv.conf.txt"

# Persistence and scheduled jobs
systemctl list-units --type=service --all > "$OUT/30_systemd_services.txt" 2>/dev/null || true
crontab -l > "$OUT/31_crontab_root.txt" 2>/dev/null || true
ls -la /etc/cron* > "$OUT/32_etc_cron_listing.txt" 2>/dev/null || true

# Logs (varies by distro)
journalctl --since "24 hours ago" > "$OUT/40_journalctl_24h.txt" 2>/dev/null || true
tail -n 2000 /var/log/auth.log > "$OUT/41_authlog_tail2000.txt" 2>/dev/null || true
tail -n 2000 /var/log/secure > "$OUT/42_secure_tail2000.txt" 2>/dev/null || true

# Hash everything collected
( cd "$OUT" && sha256sum * > "hashes_sha256.txt" )

Memory acquisition (Linux): Live memory capture is platform- and kernel-dependent and may require specialized tooling and modules. If you can’t safely acquire memory, prioritize process/network triage and coordinate a controlled shutdown and disk imaging plan. Document the limitation and why.

Technical Notes: Handling remote collection safely

If collecting over the network (SSH/WinRM/EDR “live response”): - Prefer read-only collection commands and exporting logs rather than interactive exploration. - Write artifacts to a central evidence share with access controls and immutable storage if possible. - Capture the collector-side logs too (who accessed what, when).

Tools that help (optional, non-disruptive)

You don’t need to buy anything to do volatile evidence collection correctly. But in real incidents, teams often benefit from tooling that reduces time-to-triage and improves operational security:

VPN for admins responding remotely: reduces exposure when you must administer systems from untrusted networks. Consider NordVPN (Check NordVPN pricing →) or Surfshark (Try Proton VPN →) for general secure remote access needs (where appropriate for your org’s policy).
Endpoint malware triage/cleanup (post-collection): Malwarebytes can be useful for secondary scanning and validation after you’ve preserved volatile evidence (Get Malwarebytes →).
Password hygiene after an incident: if the event involves credential exposure, rotating and storing new credentials in a business-grade password manager can reduce repeat compromise. 1Password is a common option (Try 1Password →).

Common Misconceptions

1) “Rebooting will stop the attacker and preserve evidence.”
Rebooting usually destroys the most valuable evidence (RAM, active connections, process state). Reboot only after you’ve captured volatile data—or when safety/business impact requires it.

2) “If EDR is installed, we don’t need volatile collection.”
EDR helps, but it may not capture everything (in-memory payloads, transient network state, full command lines depending on config). Volatile collection complements EDR.

3) “Running lots of tools is better.”
More tools means more system change, more noise, and more time. Use a minimal, standardized toolkit and collect the highest-value data first.

4) “Copying logs is enough.”
Logs can be missing, tampered with, or rotated. Memory, process, and network state often reveal what logs don’t.

5) “Hashing is optional for internal incidents.”
Hashing is cheap and fast. It also prevents disputes later (insurance, regulators, legal) and improves internal rigor.

NIST SP 800-61 (Computer Security Incident Handling Guide) — incident response lifecycle and evidence handling principles
NIST SP 800-86 (Integrating Forensic Techniques into Incident Response) — forensic considerations during IR
“Order of Volatility” concepts (DFIR training references) — prioritizing evidence acquisition
Windows Event Logging & auditing guidance — ensuring Security/Sysmon coverage for future incidents
Linux logging with systemd journal and traditional syslog — where to find authentication and service activity

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.