Understanding Live Triage¶
Live response and triage is the focused examination of a running system to understand its current state, preserve time sensitive evidence, and decide what should happen next.
What you will learn
By the end, you should be able to explain why collection order matters, distinguish triage from full examination, and choose a proportionate first action.
Live response and triage¶
Core concept
Live response gathers relevant information while a computer is running. Triage uses that information to assess urgency, scope, and the next evidence requirement. The aim is not to collect everything; it is to answer defined questions while avoiding unnecessary change.
Keep in mind: Every action on a live system changes it. Record commands, tools, times, outputs, and errors so the effect can be understood.
What live triage is not¶
Why it matters¶
Protect short lived evidence¶
Running processes, connections, logged on users, and decrypted material may disappear at shutdown.
Focus the investigation¶
Rapid facts help identify affected systems, relevant accounts, and the next evidence source.
Support proportionate action¶
Triage helps analysts balance evidence value, operational impact, and investigative urgency.
Preserve context¶
Contemporaneous notes connect each output to the system state, tool, time, and analyst action.
Collection workflow¶
- Authorise and scopeRecord authority, the investigation question, the target system, and allowed actions.
- Record the starting stateCapture system time, identity, network configuration, and obvious signs of disruption.
- Prioritise volatilityCollect the most valuable evidence that is likely to disappear first.
- Acquire targeted artefactsUse suitable tools and store outputs on a controlled destination.
- Assess and preserveVerify outputs, document limitations, and decide whether to contain, collect more, or perform offline examination.
Practice scenario¶
A browser case desk lets you practise the sequence behind live triage. You will inspect synthetic outputs, make a small collection plan, and prepare a handover. No command runs on your computer.
Enable JavaScript to use the case desk. The optional training VM exercise below can be completed without it.
Try the same first observations in a disposable Windows VM
Use a VM you are authorised to examine. Open PowerShell, note your start time and run these read only commands one at a time:
Get-Date -Format o
$env:COMPUTERNAME
Get-Process | Select-Object -First 10 Name, Id, StartTime
Get-NetTCPConnection -State Established | Select-Object -First 10 LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess
The first two lines tell you when and where you looked. The process list shows programs running now. The connection list shows network conversations that are open now; OwningProcess is the process ID (PID) you can match to a program. These lists can change between commands.
Record which host you used, each command, its time, its output or error, and one question the results leave open. An empty connection list is a result too. These first observations do not establish compromise. For a real incident, follow your team's authority, tooling and evidence handling procedure.
The NIST forensic guide explains why the order and timing of volatile data collection matter.
Quality checklist¶
Start with an evidence question
Is this process and connection expected, and what evidence will let us decide?
- 1ObserveRecord the starting state before changing it.
- 2PrioritiseCollect relevant evidence by volatility and value.
- 3VerifyCheck outputs and document gaps or errors.
- 4DecideContain, expand collection, or move to offline analysis.
Record what could not be collected and how the collection method may have affected the system.