Endpoint Investigation Workflow
What is it?
The endpoint workflow: an alert names one event; you take its process, gather the correlated lineage, network, file and registry events, order them by time, and write the short story of what happened on the host.
Why it matters
One event is a clue; the timeline is the case. A responder needs the ordered chain — access, execution, connection, persistence — to scope and remediate, not a single scary line.
Where you see it
Starting from an EDR/Sysmon alert, the analyst pivots on the ProcessGuid and builds a per-host timeline that reads execute → connect → drop → persist.
What normal looks like
A benign timeline: a known app launched, made expected connections, wrote to its own folder — every event has an innocent neighbour.
What suspicious looks like
A causal chain no benign story explains: Office→encoded PowerShell→outbound C2→dropped binary→Run key, all under one ProcessGuid within seconds.
How analysts investigate
Pivot from the alert to the process, correlate its events by ProcessGuid, order by time, and end with a defensible statement: what ran, what it touched, and what persistence to remove.
Common beginner mistakes
- Reporting the single alert event without building the surrounding timeline.
- Missing the persistence step, so the host is 'cleaned' but re-infects on reboot.
One event → the whole host story
alert: encoded PowerShell on FIN-07
pivot on ProcessGuid → order by time:
10:02:31 WINWORD → powershell -enc (execution)
10:02:34 powershell → 45.9.148.200:443 (C2)
10:02:35 wrote Public\svc.exe (drop)
10:02:36 Run key → svc.exe (persist ← must remove)
conclusion cites each step; remediation includes the Run keyQuick check
Why must the investigation include the persistence step, not stop at execution?
A quick self-check — it doesn't affect your XP or progress.
Sign in to save your progress on the server.