Triage vs Full Forensics
Not every incident warrants a full forensic investigation. This chapter explains the decision framework — when triage is enough, when full forensics is required, what each approach costs, and how the answer changes as scope expands mid-investigation.
Three alerts come in over the same morning. First: a user clicked a phishing link, Chrome downloaded an EXE, Windows Defender quarantined it before execution — confirmed by EDR telemetry. Second: a domain controller has an unexpected scheduled task named "svchost_updater" that spawns PowerShell — attacker dwell time unknown. Third: ransomware confirmed on 12 workstations in the manufacturing VLAN — recovery is the priority. These three incidents require three different forensic approaches. Applying full forensics to the first wastes a day. Applying triage-only to the second misses the scope of what could be a full domain compromise. Applying full forensics to the third delays recovery beyond the business's tolerance. This chapter explains how to make the call.
The Triage vs Full Forensics Decision Matrix
| Factor | Triage is sufficient | Full forensics required |
|---|---|---|
| Scope known? | Yes — one device, clear entry vector, no lateral movement indicators | No — unknown scope, possible lateral movement, privileged system |
| Dwell time | Short and known — minutes to hours, entry to containment | Unknown or long — attacker was present for days, weeks, or unknown duration |
| Entry vector | Confirmed — specific phish, specific CVE, user confirmed the action | Unknown — how they got in is not clear from EDR/SIEM alone |
| System sensitivity | Standard workstation; user has no privileged access | Domain controller, file server, CI/CD system, database server, privileged admin workstation |
| Data at risk | No sensitive data on the affected system; exfiltration not indicated | PII, financial data, IP, credentials at risk; exfiltration possible or confirmed |
| Legal/regulatory requirement | No regulatory notification likely; no litigation anticipated | HIPAA/GDPR/SEC notification likely; litigation possible; law enforcement involvement |
| Recovery priority | Business can tolerate extended investigation window | Business needs the system back within hours — forensics must be fast or parallel |
The Triage Approach
Triage answers: "Is this a real compromise, what was the immediate impact, and is there any evidence of spread?" It uses SIEM + EDR telemetry as the primary evidence source, supplemented by a KAPE triage collection if the machine isn't immediately reimaged.
Triage Investigation Flow
═══════════════════════════════════════════════════════════════════
1. SIEM/EDR Review (15-30 min)
└── Pull all events for affected host for past 7 days
└── Look for: lateral movement, credential use, unusual network, persistence
└── If EDR quarantined/blocked: confirm nothing ran; scope = one host
2. Artifact Spot-Check (15-20 min with KAPE)
└── Collect: Event logs, Prefetch, Registry Run keys, Scheduled Tasks
└── Quick wins: did anything execute? any new persistence? any outbound?
└── If KAPE not available: rely on EDR telemetry + event logs from SIEM
3. Scope Determination
└── Did the attacker establish persistence? → elevates to full forensics
└── Did any lateral movement indicators appear? → expand to those hosts too
└── Was execution blocked entirely? → triage is complete; document + close
4. Decision Gate
├── Clean triage → reimage or validate clean; document; close
└── Indicators found → escalate to full forensics on this host
The Full Forensics Approach
Full forensics answers: "Exactly what happened, when, in what order, what did the attacker access, and what evidence proves it?" It requires RAM acquisition, disk image, and systematic artifact analysis across all affected systems.
Full Forensic Investigation Flow ═══════════════════════════════════════════════════════════════════ Phase 1: Acquisition ├── Live response capture (5 min per host) ├── RAM acquisition (5-15 min per host) ├── KAPE triage collection (10-30 min per host) └── Full disk image (60-120 min per host, time permitting) Phase 2: Memory Analysis ├── Process analysis (injected code, suspicious relationships) ├── Network artifact extraction (active connections, cached DNS) ├── Credential artifact extraction (tokens in memory) └── Injected module detection (malfind, hollowfind) Phase 3: Disk/Artifact Analysis ├── Timeline construction (MFT + event logs + prefetch = activity timeline) ├── Persistence mechanism hunt (registry, tasks, services, WMI) ├── Execution trace (Prefetch, Amcache, Shimcache) ├── User activity reconstruction (LNK, jump lists, shellbags) └── Data access/staging/exfiltration evidence (file access logs, outbound) Phase 4: Scope Expansion ├── Lateral movement pivots (Event 4648/4769 on adjacent systems) ├── Credential use patterns (where else was the compromised account used?) └── Repeat Phase 1-3 for each newly scoped host Phase 5: Report ├── Timeline of attacker activity ├── Scope — all compromised systems ├── Data accessed or exfiltrated └── How they got in and how they persisted
Parallel Forensics and Recovery
When recovery must happen quickly but forensics is also required, run them in parallel — not sequentially. The key is acquisition first, then investigation can continue on the evidence while remediation happens on the live system.
| Time | IR Track (recovery-focused) | Forensics Track (investigation-focused) |
|---|---|---|
| T+0 | EDR isolation of all affected hosts | Live response capture running on all hosts simultaneously via Velociraptor |
| T+1h | Scope confirmation — how many hosts? | RAM acquisition and KAPE running on high-priority hosts (DCs, servers) |
| T+2h | Begin reimaging/restoring non-critical workstations from clean backup | Memory analysis underway on server images; event log review in SIEM |
| T+4h | Critical servers restored, business functions resuming | Persistence mechanisms identified; entry vector confirmed from forensics |
| T+8h | Full recovery confirmed; monitoring active | Full timeline complete; scope confirmed; entry vector patched |
A full forensic investigation of a single workstation — RAM acquisition, disk image, Volatility analysis, MFT parsing, full timeline construction — takes 4-8 hours per experienced analyst. If you apply that to every suspicious workstation alert, you'll quickly exhaust your forensic capacity. The right default for workstations is triage first: use your EDR and SIEM to determine if anything actually ran, if there's any lateral movement, if any persistence was established. If the answer to all three is no (quarantined before execution, no network activity, no persistence), the business case for a full investigation is weak. Reserve full forensics for: servers, domain controllers, systems with unknown dwell time, systems where the entry vector isn't confirmed, and any case where regulatory notification or litigation is anticipated.
Escalation Triggers: When Triage Must Become Full Forensics
Triage may reveal new information that changes the investigation scope. These are the signals that escalate from triage to full forensics mid-investigation:
| Discovery during triage | Escalation action |
|---|---|
| Any Event 4648 (explicit credential logon) to a second host from the affected workstation | Immediately expand to full forensics on both hosts and all hosts that 4648 touched |
| Scheduled task or registry run key not present in your baseline | Attacker established persistence — full forensics required to confirm no other persistence and understand full timeline |
| EDR shows process injecting into LSASS or another system process | Credential dumping suspected — full forensics + scope all hosts where the affected user account has authenticated |
| Dwell time extends beyond 24 hours | Attacker had significant time in the environment — unknown lateral movement risk; full forensics on all systems with any connection to the compromised account |
| Compromised host is or had RDP/admin access to other systems | Assume lateral movement until disproved; full forensics on all systems in the blast radius |
Q & A
Q: The business wants the server restored in 2 hours but you haven't finished forensics. What do you do?
Acquire first, then let the business restore. RAM acquisition takes 10-15 minutes. KAPE triage takes 15-30 minutes. A full disk image in parallel with business restoration takes 60-90 minutes in the background. In 2 hours you can acquire everything meaningful while the server is being prepared for restoration. The key assertion to make to the business: "We can begin restoration in X minutes. Give us X minutes to capture evidence we will need to answer 'how did they get in' and 'did they move anywhere else.' Without that, we may be repeating this conversation in 2 weeks when they come back in the same way." Most businesses accept a 30-minute delay for evidence collection when framed that way. If they don't, document the decision and acquire whatever you can in the time available.
Q: You do triage on a workstation and find nothing — no persistence, no lateral movement, EDR blocked execution. Do you reimage it or return it to service?
Either is defensible — document the decision and rationale. The case for reimaging: it's a workstation, reimaging takes an hour, and "definitely clean" is better than "probably clean." The case for returning to service: you have high confidence from triage (EDR blocked execution before any payload ran, no network activity, no file writes outside the download), the business impact of reimaging is significant, and triage + EDR telemetry together give you strong evidence the system is clean. What matters most is documentation: write down what you checked, what you found, what you didn't find, and why you concluded what you concluded. If the same host appears in an incident 3 months later, that documentation tells you whether this was a miss or a new event.