Windows Live Response: What to Capture, in Which Order

Pulling the power on a compromised Windows host destroys the running processes, live network connections, logged-on sessions and decrypted volumes that often explain what the attacker was doing. This guide shows how to decide between live response and straight imaging, what to capture in which order, which tools to trust, and how to document the footprint you leave behind. You will finish with a collection checklist that works on a single laptop and scales to a fleet.

It is the Windows counterpart of a Linux live response playbook, and it sits between the getting started guide and the KAPE and Velociraptor triage guide in this series.

Live response or straight to imaging?

Go live when volatile state matters to the questions you must answer, which is most intrusion cases:

• Active compromise: a beacon, a remote shell or an interactive operator. Connections, command lines and injected code only exist in RAM.
• Full disk encryption: if BitLocker or a third-party product is unlocked now, a powered-off image may be unreadable without recovery keys. Check with manage-bde -status before anything else touches power.
• Servers you cannot take down: domain controllers, hypervisors and production databases are usually triaged live and imaged later, if at all.
• Scale: fifty suspect hosts are triaged remotely, not imaged.

Image first (or only) when the case is likely to reach court with strict evidential requirements and no volatile question exists, when the host is already powered off (do not power it on to "have a look"), or when you suspect destructive malware that triggers on activity. Record the reasoning either way; your chain of custody notes should say why you touched a running system.

Order of volatility on Windows

RFC 3227 frames collection as most volatile first. Applied to Windows, the order of volatility looks like this:

In practice, steps 2 to 7 take a couple of minutes with a script, so the order within them matters less than getting memory first and not rebooting.

Prepare trusted tooling

Never run tools from the suspect disk. An attacker can plant a trojaned binary earlier in PATH, hijack a DLL next to it, or tamper with PowerShell profiles. Build a response kit on read-only or dedicated media, or push it through your EDR:

• Statically linked or self-contained binaries where possible (WinPmem, Sysinternals, Velociraptor).
• Call binaries by full path, including native ones: C:\Windows\System32\netstat.exe, not netstat.
• Launch PowerShell with -NoProfile -ExecutionPolicy Bypass so user and machine profiles do not run.
• Write all output to external or network storage, never to the suspect C: drive, where it would overwrite unallocated space you may later want to carve.
• Record the analyst clock and the host clock at the start. w32tm /query /status and a UTC timestamp let you correct skew later (see UTC and local time).

# Session header: who, where, when (UTC), and clock source
$Out = 'E:\IR\HOST01'
New-Item -ItemType Directory -Path $Out -Force | Out-Null
"Analyst: $env:USERNAME  Host: $env:COMPUTERNAME  UTC: $((Get-Date).ToUniversalTime().ToString('o'))" |
  Out-File "$Out\00_header.txt"
w32tm /query /status >> "$Out\00_header.txt"
manage-bde -status   >> "$Out\00_header.txt"

Step 1: acquire memory first

Memory holds process trees including exited and hidden processes, network structures, command history, decrypted data and injected code that no disk artifact will show. Acquire it before running anything else, because every later command changes it.

# WinPmem (the exact binary name depends on the release you download)
E:\tools\winpmem_mini_x64.exe E:\IR\HOST01\mem.raw

# Hash immediately
Get-FileHash -Algorithm SHA256 E:\IR\HOST01\mem.raw |
  Export-Csv E:\IR\HOST01\hashes.csv -NoTypeInformation -Append

Memory tools load a kernel driver, which usually creates a service and a System log 7045 event on the host. That is expected; write it down. If you cannot acquire memory (no approved tool, driver blocked), at least collect hiberfil.sys and pagefile.sys with a raw-copy tool later, and note that live output is now your only view of volatile state. Analysis is covered in the memory forensics guide.

Step 2: processes, network and sessions

Processes with command lines and parents

tasklist does not show command lines or parents. Use CIM, which returns both along with the executable path and creation time:

Get-CimInstance Win32_Process |
  Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine,
    @{n='Created';e={$_.CreationDate.ToUniversalTime().ToString('o')}} |
  Export-Csv "$Out\processes.csv" -NoTypeInformation

tasklist /svc /fo csv > "$Out\tasklist_svc.csv"   # which services live in each svchost

Command lines of protected processes and processes owned by other users need an elevated prompt. Sysinternals pslist -t gives a tree view, and sigcheck can hash and check signatures of every running image path.

Network connections with owning PIDs

Get-NetTCPConnection |
  Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess, CreationTime |
  Export-Csv "$Out\tcp.csv" -NoTypeInformation
Get-NetUDPEndpoint | Select-Object LocalAddress, LocalPort, OwningProcess, CreationTime |
  Export-Csv "$Out\udp.csv" -NoTypeInformation

C:\Windows\System32\netstat.exe -anob > "$Out\netstat_anob.txt"   # -b needs elevation

Join OwningProcess against the process list: a rundll32.exe or powershell.exe with an established connection to an external IP is a lead in itself.

Sessions, shares and cached network state

quser                         > "$Out\sessions_quser.txt"
qwinsta                       >> "$Out\sessions_quser.txt"
net session                   > "$Out\net_session.txt"    # inbound SMB sessions
net use                       > "$Out\net_use.txt"        # outbound mapped drives
klist sessions                > "$Out\klist_sessions.txt" # logon sessions and LUIDs
Get-SmbShare | Export-Csv "$Out\smb_shares.csv" -NoTypeInformation
Get-DnsClientCache | Export-Csv "$Out\dns_cache.csv" -NoTypeInformation
Get-NetNeighbor    | Export-Csv "$Out\arp.csv" -NoTypeInformation
route print                   > "$Out\routes.txt"
netsh advfirewall show allprofiles > "$Out\firewall.txt"
Get-ChildItem \\.\pipe\ | Select-Object Name > "$Out\named_pipes.txt"

The DNS cache often reveals C2 domains resolved minutes ago, even when the connection itself has closed. Named pipes help spot default pipe names of common post-exploitation frameworks, although operators routinely rename them.

Handles, DLLs and the clipboard

handle.exe -a -accepteula and listdlls.exe show open files, registry keys and loaded modules per process. They are slow on busy servers, so scope them to suspect PIDs (handle -p <PID>). The clipboard is per user session: a collector running as SYSTEM will not see it. Grab it only if you are working inside the user's session, and look at clipboard history on disk otherwise.

Step 3: persistence and configuration snapshot

Capture the autostart surface while the system is still running, because some mechanisms (WMI subscriptions, hidden tasks) are easier to enumerate live. The persistence hunting guide explains how to interpret each entry.

E:\tools\autorunsc64.exe -accepteula -nobanner -a * -c -h -s -vt:0 > "$Out\autoruns.csv"
schtasks /query /fo csv /v > "$Out\schtasks.csv"
Get-CimInstance Win32_Service |
  Select-Object Name, State, StartMode, StartName, PathName, ProcessId |
  Export-Csv "$Out\services.csv" -NoTypeInformation
Get-CimInstance -Namespace root/subscription -ClassName __EventConsumer |
  Export-Csv "$Out\wmi_consumers.csv" -NoTypeInformation
Get-LocalUser | Export-Csv "$Out\local_users.csv" -NoTypeInformation
Get-LocalGroupMember Administrators | Export-Csv "$Out\local_admins.csv" -NoTypeInformation

Check that -vt is disabled or that your policy allows it: submitting hashes to an online service can tip off an attacker who monitors their samples.

Step 4: triage collection of disk artifacts

With volatile data secured, collect the persistent artifacts you need for a timeline: registry hives, event logs, $MFT, $UsnJrnl, Prefetch, Amcache, SRUM, browser data and PowerShell history. Locked files require raw NTFS access, which is exactly what KAPE and Velociraptor do. See triage collection and the acquisition guide for target selection.

E:\kape\kape.exe --tsource C: --tdest E:\IR\HOST01\kape --target KapeTriage --vhdx HOST01 --zip HOST01

Native commands, Sysinternals, Velociraptor or KAPE?

A good kit uses Velociraptor or the EDR for breadth and a scripted native plus Sysinternals bundle as a fallback when agents are missing.

EDR consoles and remote collection at scale

Most EDRs include a live response shell. Microsoft Defender for Endpoint Live Response offers commands such as processes, connections, getfile and run for uploaded scripts, and can collect an investigation package. CrowdStrike Falcon Real Time Response and SentinelOne RemoteOps offer comparable capabilities. Command names, file size limits and which roles may run scripts change between versions and licences, so check your tenant before an incident.

For fleet-wide questions ("which hosts resolved this domain?", "where is this service installed?"), Velociraptor hunts are the reference approach. Artifacts such as Windows.System.Pslist, Windows.Network.Netstat, Windows.Network.ArpCache, Windows.System.DNSCache and Windows.Sysinternals.Autoruns return structured results you can stack across hosts. Artifact names evolve between releases; confirm them in your server's artifact list.

# Offline collection with a local Velociraptor binary (no server needed; check flags with --help)
velociraptor.exe artifacts collect Windows.System.Pslist Windows.Network.Netstat `
  --output E:\IR\HOST01\velo_live.zip

Remote access itself leaves traces: network logons (4624 logon type 3), service installs for PsExec-style tools and WinRM activity. The lateral movement guide lists them; they will appear in your timeline next to the attacker's.

Preserve output: hashes, timestamps, notes

• Hash every output file (SHA-256) as soon as it is written and store the hash list separately from the evidence.
• Keep a contemporaneous log: command, start time (UTC), analyst, result, any error. PowerShell Start-Transcript to your output folder helps.
• Save raw output, not only parsed summaries. Parsers improve; raw text does not come back.
• Package the folder into a ZIP or VHDX, hash it, and copy it off the collection media before analysis.

Get-ChildItem $Out -File -Recurse | Get-FileHash -Algorithm SHA256 |
  Export-Csv "$Out\..\HOST01_manifest.csv" -NoTypeInformation

Document your own footprint

Live response changes the system. The point is not to avoid all changes (impossible) but to know them so nobody mistakes your tools for the attacker's:

Record tool names, hashes and paths in your notes. Rename nothing: a clearly named winpmem in Prefetch is easier to exclude than a random string.

Pitfalls

• Trusting userland output. Rootkits hook the APIs behind tasklist, netstat and dir. Compare live results with a memory image (for example Volatility windows.pslist versus windows.psscan) and with network data captured outside the host.
• Running tools from the suspect disk. A trojaned cmd.exe or a DLL planted next to your tool can lie or execute payloads with your privileges.
• Interactive RDP with a domain admin. It leaves reusable credentials in LSASS on a compromised host. Use a restricted IR account and network logons; the credential access guide explains what attackers harvest.
• Writing output to C:. It overwrites free clusters and pollutes the USN journal with your own files.
• Rebooting or "cleaning" first. A reboot clears memory and flushes caches; an AV full scan quarantines samples and touches thousands of access times.
• Forgetting encryption. Shutting down a BitLocker host without a recovery key can lock you out of the disk.
• Tipping off the attacker. Uploading hashes to public services or killing processes before scoping lets an active operator switch infrastructure. Contain after you have collected, in coordination with the response lead.
• Assuming an evil process is still running. Short-lived tools are gone; rely on memory, Prefetch and logs for what already exited, as described in evidence of execution.

Live response checklist

1. Decide and document why the host is examined live, who authorised it, and the host and analyst clocks in UTC.
2. Check encryption with manage-bde -status; secure recovery keys if needed.
3. Acquire memory with a trusted tool to external or network storage; hash it.
4. Capture network state: TCP and UDP endpoints with PIDs, DNS cache, ARP, routes, firewall profile.
5. Capture processes: PID, parent, path, command line, creation time, services per process, signatures.
6. Capture sessions: interactive users, inbound SMB sessions, mapped drives, logon sessions.
7. Snapshot persistence: autoruns, services, scheduled tasks, WMI consumers, local admins.
8. Collect triage artifacts with KAPE or Velociraptor from raw NTFS.
9. Hash and package every output, write a manifest, copy it off the collection media.
10. Log your footprint: tools, hashes, paths, accounts and times, so your activity can be filtered from the timeline.
11. Hand over to containment only once collection is complete and verified, then proceed to full imaging if the case requires it.