Skip to content

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.

System timeProcessesConnectionsUsersTargeted artefacts

Keep in mind: Every action on a live system changes it. Record commands, tools, times, outputs, and errors so the effect can be understood.

01VolatilityHow quickly evidence can change or disappear02TriageA rapid assessment that guides priority and next steps03ProvenanceWhere evidence came from and how it was handled

What live triage is not

Live triageFocused collection and assessment on a running system
Disk imagingA sector level acquisition of persistent storage
Memory analysisDetailed examination of an acquired memory image
Full forensic examinationComprehensive analysis performed after preservation

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

  1. Authorise and scopeRecord authority, the investigation question, the target system, and allowed actions.
  2. Record the starting stateCapture system time, identity, network configuration, and obvious signs of disruption.
  3. Prioritise volatilityCollect the most valuable evidence that is likely to disappear first.
  4. Acquire targeted artefactsUse suitable tools and store outputs on a controlled destination.
  5. 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?

  1. 1ObserveRecord the starting state before changing it.
  2. 2PrioritiseCollect relevant evidence by volatility and value.
  3. 3VerifyCheck outputs and document gaps or errors.
  4. 4DecideContain, expand collection, or move to offline analysis.
!Plan for operational friction
Tool blockingLimited privilegesClock driftLarge outputsRemote latencySystem change

Record what could not be collected and how the collection method may have affected the system.

Choose a tool

Continue learning