Lesson 100 — Your Final SOC Investigation
One alert.
Multiple identities and devices.
Cloud activity. Endpoint activity. Unanswered questions.
This investigation is yours.
No single query solves this case.
Triage. Investigate. Scope. Contain. Document. Close.
Final case briefing
Your objective
Triage the alert, build the timeline, investigate identity and endpoint evidence, scope related activity, assess cloud impact, contain confirmed compromise and produce a defensible final incident record.
Final investigator's rule
Do not investigate the alert. Investigate the incident.
Stage 1 — triage what you actually know
| Known | Not yet known |
|---|---|
| PowerShell alert on WS-447 | Whether execution was malicious |
| mia@contoso.com associated with device | Whether the identity is compromised |
| Medium alert severity | True incident impact |
| Specific alert timestamp | Actual incident start time |
Severity is not your verdict
Use the alert to prioritise investigation, but let evidence and context determine the final assessment.
Start with entities
Identify the user, device, process, time and any network or file indicators that can become pivots.
Stage 2 — investigate the endpoint
let Device = "WS-447";
DeviceProcessEvents
| where Timestamp > ago(8h)
| where DeviceName =~ Device
| project Timestamp,
AccountName,
InitiatingProcessFileName,
FileName,
ProcessCommandLine,
SHA1
| order by Timestamp ascReconstruct process ancestry
Determine what launched PowerShell, what PowerShell executed and what processes followed. A command without its process context is only part of the evidence.
Move before and after the alert
Search backwards for the setup and forwards for consequences. The detection timestamp is a pivot, not a boundary.
Endpoint evidence
First assessment
The process chain makes benign administrative PowerShell less likely. You now have enough evidence to broaden the investigation, not enough to declare the full scope.
Preserve uncertainty
Record what is supported and what still requires validation. Confidence should increase as independent evidence converges.
Stage 3 — pivot to identity
let User = "mia@contoso.com";
EntraIdSignInEvents
| where Timestamp > ago(8h)
| where AccountUpn =~ User
| project Timestamp,
AccountUpn,
IPAddress,
Country,
Application,
ErrorCode
| order by Timestamp ascAuthentication adds another story
An unfamiliar successful sign-in appears shortly after the endpoint activity. Determine whether it matches the user's normal context and whether the resulting session performed suspicious actions.
Account does not equal human
Actions performed under mia@contoso.com show which identity was used, not automatically who controlled it.
Stage 4 — correlate cloud activity
let User = "mia@contoso.com";
CloudAppEvents
| where Timestamp > ago(8h)
| where AccountId =~ User
| project Timestamp,
AccountId,
IPAddress,
Application,
ActionType,
ObjectName
| order by Timestamp ascFollow the session
Mailbox searches and SharePoint downloads occur after the suspicious authentication. Correlate time, source and action before attributing them to the legitimate user.
Access is not automatically exfiltration
Record confirmed file access and downloads precisely. Determine whether evidence supports movement outside organisational control.
Stage 5 — build the incident timeline
Correlation changes severity
A medium endpoint alert now connects to identity, cloud and server activity. Incident priority should reflect the combined evidence, not the original alert label.
Keep one timeline
Identity, endpoint and cloud telemetry should contribute to the same chronological incident story.
Stage 6 — scope the behaviour
let SuspiciousIP = "203.0.113.42";
EntraIdSignInEvents
| where Timestamp > ago(8h)
| where IPAddress == SuspiciousIP
| summarize
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp),
Events=count()
by AccountUpn, Application
| order by FirstSeen ascThe second identity matters
The suspicious source also appears against another account. Do not assume that account is compromised, but immediately add it to scope for validation.
Scope behaviour as well as indicators
Exact IP addresses and hashes are useful pivots, but attackers can change infrastructure. Search for the technique and sequence too.
Stage 7 — classify the scope
| Entity | Assessment | Evidence |
|---|---|---|
| WS-447 | Confirmed compromised | Malicious process chain and network activity |
| mia@contoso.com | Confirmed compromised | Suspicious sign-in with correlated cloud activity |
| SRV-FILE-02 | Suspected compromised | Related remote execution requires validation |
| noah@contoso.com | Suspected | Authentication from suspicious source |
| Finance SharePoint | Affected resource | Sensitive downloads confirmed |
Do not flatten scope
Confirmed compromise, suspected compromise and affected resources are different states. Preserve those distinctions throughout response.
Unknown is still evidence work
Every suspected entity should have a reason for inclusion and a defined next investigative action.
Stage 8 — choose containment
Contain evidence-supported compromise
Do not wait for perfect knowledge while confirmed attacker access remains active. At the same time, avoid destructive action against every suspected entity without justification.
Contain the attack path
Sessions, credentials, endpoints and remote access paths may all require action. Stopping one process is not equivalent to containing the incident.
Stage 9 — validate containment
Look for attacker adaptation
If activity shifts to another identity or device after containment, the scope or access-path assessment was incomplete.
Do not call it contained too early
State exactly what has been controlled and what remains under investigation until evidence supports broader containment.
Stage 10 — write the final finding
Write only what the evidence supports
A strong final finding distinguishes confirmed compromise, suspected scope, affected data and unresolved impact without exaggeration.
Explain why the incident can close
Closure requires a defensible reason: active access controlled, required scope resolved or transferred, evidence preserved, recovery actions completed or owned, and remaining risk documented.
Final decision
Closure is a decision
An alert disappearing from the queue does not close an incident. Closure should follow evidence that the response objectives have been met.
And then improve the SOC
Ask whether this investigation should create a new detection, hunting hypothesis, playbook change, control improvement or analyst lesson.
Your final investigation checklist
- Triage the alert without treating severity as the verdict.
- Identify useful entities and investigative pivots.
- Investigate before and after the detection timestamp.
- Reconstruct endpoint process ancestry and consequences.
- Validate identity and authentication context.
- Correlate cloud actions with the suspicious session.
- Build one cross-service timeline.
- Scope identities, devices, resources and attacker behaviour.
- Separate confirmed, suspected and unknown findings.
- Contain active access paths using evidence-supported actions.
- Validate containment rather than assuming it worked.
- Document impact at the level the evidence supports.
- Preserve evidence and response actions.
- Close only when the incident has a defensible end state.
- Turn the investigation into better future capability.
100 lessons later...
The Agent Foskett method
Follow the evidence. Build the timeline. Question the assumption.
The tools will change. The alerts will change. The attackers will change. The investigative discipline remains.
The Logs Already Knew
The evidence was there across identity, endpoint, cloud and activity logs. The analyst's job was to connect it, challenge the first explanation and build a defensible story.
Lesson 100 — complete
You have reached the end of the Agent Foskett SOC Analyst Academy: 100 scenario-driven lessons built around investigation, evidence, decision-making and real SOC thinking.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 10: Complete SOC Investigation Scenarios
How do you complete a full SOC investigation?
Lesson 100 is the final Agent Foskett SOC Analyst Academy scenario. It combines alert triage, endpoint investigation, identity analysis, cloud investigation, KQL, timeline reconstruction, scoping, containment, evidence preservation, documentation and incident closure.
Final SOC analyst investigation scenario
Work a multi-stage security incident from the first alert through correlated identity, endpoint and cloud evidence, then determine scope, contain active compromise, validate response actions and produce a defensible final finding.
