Agent Foskett Academy • SOC Analyst Academy • Module 1 • Lesson 10 • Inside the SOC

Lesson 10 — From Alert to Closure — Your First SOC Investigation

Nine lessons ago, the alert queue contained 47 alerts and the first problem was simply deciding where to start. Now you are going to take one incident all the way through the SOC workflow.

You will prioritise it, challenge the severity, correlate separate alerts, speak to the user, collect evidence, choose pivots, decide when enough evidence exists, escalate when the risk changes and write the final investigation record.

This is not nine separate skills anymore. This is one investigation.

Start the Investigation Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy complete investigation from alert to closure

Your first complete SOC case

One alert becomes an incident spanning identity, endpoint and network evidence. Your job is to turn scattered telemetry into a defensible decision.

✓ Prioritise and scope

✓ Collect and correlate evidence

✓ Pivot with KQL

✓ Decide, escalate and document

Final Module 1 case briefing

08:41 — HIGH SEVERITY ALERT Suspicious PowerShell activity USER maria.s@contoso.com DEVICE FIN-LT-027 INITIAL ENTITIES User Device PowerShell process External IP Downloaded file RELATED ALERTS 08:34 — Unusual successful sign-in 08:41 — Suspicious PowerShell execution 08:44 — Connection to unfamiliar external host USER RESPONSE "I didn't run PowerShell." YOUR TASK Take the incident from alert to a defensible SOC outcome.

Investigation objective

Apply the complete Module 1 workflow to a single case and show how prioritisation, evidence, correlation, pivots, human context, escalation and documentation work together.

Investigator's rule

Do not investigate the alert. Investigate the activity the alert exposed. The alert is where the case begins, not where the explanation ends.

Stage 1 — prioritise before you investigate

The queue contains many alerts, but this one deserves early attention because multiple risk factors combine: successful authentication, endpoint execution, external communication and a user who does not recognise the activity.

Factor	Observation	Effect
Severity	High	Important input, not proof
Identity	Successful unusual sign-in	Raises compromise concern
Endpoint	Unexpected PowerShell	Requires execution context
Network	External connection minutes later	May represent follow-on activity
User context	User denies PowerShell use	Supports further validation

Severity does not make the decision

You still need evidence. A high-severity alert can be benign, while a medium-severity alert on a critical asset can be urgent.

Prioritisation is contextual

The combination of identity, endpoint and network signals makes this case more important than any one label on the alert.

Stage 2 — recognise that three alerts are one story

08:34 UNUSUAL SUCCESSFUL SIGN-IN ↓ 7 minutes 08:41 POWERSHELL EXECUTION ↓ 3 minutes 08:44 EXTERNAL CONNECTION SAME USER SAME DEVICE CONTEXT TIGHT TIME WINDOW THREE ALERTS ONE INVESTIGATION

The analyst should not create three disconnected cases when the evidence supports one sequence. Correlation changes the unit of investigation from individual alerts to an incident story.

Sequence matters

Authentication before execution before network communication is more informative than three independent timestamps viewed in separate portals.

Do not force correlation

Shared time alone is not enough. User, device, process and other entity relationships must support the connection.

Stage 3 — collect identity evidence with KQL

Start with a narrow window around the incident and establish what authentication occurred before the endpoint activity.

12345678910111213141516

let TargetUser = "maria.s@contoso.com";
let StartTime = datetime(2026-08-22 08:15:00);
let EndTime = datetime(2026-08-22 09:00:00);
SigninLogs
| where TimeGenerated between (StartTime .. EndTime)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          DeviceDetail,
          AuthenticationRequirement,
          ConditionalAccessStatus,
          ResultType
| order by TimeGenerated asc

The user statement is evidence

“I didn't run PowerShell” matters, but it does not prove compromise. Compare the user's account with sign-in, device and process telemetry.

Successful does not mean normal

The sign-in succeeding tells you authentication requirements were satisfied. It does not tell you whether the session was expected or controlled by the legitimate user.

Stage 4 — pivot into endpoint execution

The alert is about PowerShell, so process evidence is the strongest next pivot. Determine how it started and what command actually ran.

1234567891011121314151617

let TargetDevice = "FIN-LT-027";
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where FileName =~ "powershell.exe"
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          ProcessId,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessId,
          SHA1
| order by Timestamp asc

The parent process changes the story

If a browser or Office application launched PowerShell unexpectedly, the evidence is stronger than PowerShell appearing without ancestry or being launched by approved administration tooling.

Choose pivots deliberately

The command line, process ID, parent process, file hash and device are all possible pivots. Follow the one that answers the next question.

Stage 5 — connect execution to network activity

123456789101112131415

let TargetDevice = "FIN-LT-027";
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where InitiatingProcessFileName =~ "powershell.exe"
| project Timestamp,
          DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          RemoteIP,
          RemotePort,
          RemoteUrl,
          Protocol
| order by Timestamp asc

Now the external IP has meaning

The destination is no longer merely an indicator in an alert. You can associate it with a specific process, device and time.

Behaviour before reputation

An external destination does not need an existing malicious reputation label to matter when suspicious execution directly contacted it.

Stage 6 — decide whether you have enough evidence

CONFIRMED ✓ unusual successful sign-in ✓ user does not recognise activity ✓ unexpected PowerShell execution ✓ suspicious process ancestry ✓ PowerShell made external connection ✓ no validated benign explanation UNRESOLVED ? initial access mechanism ? attacker objective ? persistence ? wider scope DECISION Enough evidence exists to treat FIN-LT-027 as potentially compromised. CONTAINMENT SHOULD NOT WAIT FOR EVERY QUESTION TO BE ANSWERED.

Stop at the decision point

You still have unanswered questions, but they no longer prevent the immediate operational decision. Investigation can continue after risk reduction begins.

Uncertainty belongs in the record

Do not hide what you do not know. Record unresolved questions so response and follow-up investigation can address them.

Stage 7 — check whether escalation is required

Question	Case answer	Effect
Privileged identity?	No	No privilege-driven escalation
Critical device?	Finance endpoint	Business context matters
Active suspicious activity?	Potentially	Contain promptly
Multiple affected entities?	Not yet confirmed	Continue scope validation
Sensitive financial data accessible?	Possible	Engage appropriate incident response / business owner

Escalate the risk, not the drama

Explain why finance-system access changes consequence. Do not simply repeat that the original alert was high severity.

Containment and escalation can overlap

Escalating the incident does not mean the analyst stops acting. Immediate authorised containment and communication can proceed together.

Stage 8 — write the final investigation record

DISPOSITION Suspected compromise — containment initiated AFFECTED USER maria.s@contoso.com AFFECTED DEVICE FIN-LT-027 TIMELINE 08:34 unusual successful sign-in 08:41 suspicious PowerShell execution 08:44 external connection from PowerShell 09:02 user confirmed activity was not recognised CONFIRMED EVIDENCE • identity event preceded endpoint execution • PowerShell execution was unexpected • process communicated externally • no validated benign explanation identified ACTIONS • device containment initiated • relevant response team engaged • investigation evidence preserved OUTSTANDING • determine initial access • check persistence • validate wider account/device scope NEXT STEP Continue scope investigation after immediate risk reduction.

The complete Module 1 workflow

ALERT QUEUE ↓ PRIORITISE ↓ VALIDATE SEVERITY ↓ CORRELATE RELATED ALERTS ↓ ADD USER CONTEXT ↓ COLLECT EVIDENCE ↓ CHOOSE THE BEST PIVOT ↓ BUILD THE TIMELINE ↓ DECIDE WHEN EVIDENCE IS SUFFICIENT ↓ CONTAIN / ESCALATE / CLOSE ↓ DOCUMENT FOR THE NEXT ANALYST

You are no longer reacting to alerts. You are investigating incidents.

Lesson 10 key takeaways

An alert is the starting point of an investigation, not the conclusion.
Prioritisation combines severity with identity, asset, behaviour and business context.
Separate alerts can become one incident when entities and timing connect them.
User statements are evidence that must be tested against telemetry.
Collect focused evidence before widening the investigation.
Choose pivots according to the question you need to answer.
Use KQL to test specific hypotheses across identity, endpoint and network evidence.
You can contain before every investigative question is answered.
Escalation depends on consequence, scope and uncertainty — not alert severity alone.
Good documentation allows another analyst to reproduce and continue your work.

Module 1 complete

You have completed Inside the SOC: Thinking Like an Analyst. The next module moves from the analyst mindset into the mechanics of alert triage and prioritisation under pressure.

Next: Module 2 • Lesson 11 — Alert Triage Under Pressure

Continue your SOC Analyst training

Module 1 is complete. Continue into deeper alert triage, investigation and incident-response workflows.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 1: Inside the SOC: Thinking Like an Analyst

Module 1 complete — from alert prioritisation through investigation, escalation, documentation and closure.

← Previous lesson

Lesson 9 — Another Analyst Has to Read Your Notes Tomorrow Write investigation notes that preserve facts, reasoning and outstanding questions.

✅ Current lesson

Lesson 10 — From Alert to Closure — Your First SOC Investigation Bring the complete Module 1 SOC workflow together in one investigation.

Next module →

Module 2 • Lesson 11 — The Same Alert Fired on 30 Devices Distinguish one widespread incident from repeated low-value alerts.

Complete SOC analyst investigation from alert to closure

Lesson 10 of the Agent Foskett SOC Analyst Academy brings together alert prioritisation, evidence collection, entity correlation, KQL investigation, containment, escalation and documentation in a complete Microsoft security investigation.

Microsoft SOC investigation with Defender XDR, Entra and KQL

Learn how SOC analysts move from a security alert to a defensible incident decision using Microsoft Entra sign-in telemetry, Defender XDR endpoint and network evidence, focused KQL queries and structured investigation notes.