Agent Foskett Academy • Lesson 48 • Investigating SecurityIncident

Investigating SecurityIncident: Five Alerts. One Incident.

The alerts looked unrelated.

A phishing email.

A risky sign-in.

An unusual PowerShell command.

Separate alerts.

One attack.

SecurityIncident revealed the connection.

Start Lesson 48 Back to Academy

Agent Foskett Academy lesson explaining SecurityIncident in Microsoft Defender XDR

Lesson overview

Learn how IdentityInfo helps defenders understand who an account belongs to, what access it has and how much risk it represents.

Investigate correlated incidents

Review severity and status

Connect alerts into one story

Build identity investigation context

Why SecurityIncident matters

Alerts rarely exist alone. SecurityIncident helps defenders understand how separate alerts connect into one attack story.

Alerts rarely exist aloneAttackers often generate multiple signals across email, identity, endpoint and cloud activity. SecurityIncident groups related alerts together.

The incident tells the storyInstead of investigating alerts one by one, defenders can review the correlated incident and understand the bigger picture.

Correlation saves timeMicrosoft Defender XDR connects related evidence so analysts can prioritise scope, severity, affected entities and response actions faster.

Investigation scenario

The SOC received multiple alerts. At first, they looked like separate problems. SecurityIncident showed they belonged to the same attack chain.

The alerts appeared disconnectedA suspicious email, risky sign-in, malicious URL click and unusual PowerShell activity were raised at different points in time.

The incident connected themSecurityIncident grouped the alerts and gave defenders one place to review severity, status, entities and timeline context.

The timeline became clearA phishing email led to a click, the sign-in followed, commands executed and the incident revealed the complete attack path.

Step 1 — Review recent incidents

Start by reviewing recent incidents and focus on the incident number, title, severity and current status.

SecurityIncident
| where Timestamp > ago(7d)
| project Timestamp, IncidentNumber, Title, Severity, Status,
          Owner, Classification, LastModifiedTime
| order by Timestamp desc

Step 2 — Review high severity incidents

High severity incidents often need immediate attention, especially when they involve identity compromise, malware, data exposure or active attacker behaviour.

SecurityIncident
| where Timestamp > ago(30d)
| where Severity == "High"
| project IncidentNumber, Title, Severity, Status, Owner, LastModifiedTime
| order by LastModifiedTime desc

Step 3 — Find open incidents

Open incidents show what still requires analyst review, containment, escalation or closure.

SecurityIncident
| where Timestamp > ago(14d)
| where Status != "Resolved"
| project IncidentNumber, Title, Severity, Status, Owner
| order by Severity desc, IncidentNumber desc

Step 4 — Investigate one incident

When an incident becomes important, filter by IncidentNumber and review the full record before pivoting into supporting evidence.

let TargetIncident = 12345;
SecurityIncident
| where IncidentNumber == TargetIncident
| project Timestamp, IncidentNumber, Title, Severity, Status, Description, Entities

Step 5 — Identify affected entities

Entities help defenders understand what the incident touched, such as users, devices, files, URLs, IP addresses and cloud resources.

let TargetIncident = 12345;
SecurityIncident
| where IncidentNumber == TargetIncident
| project IncidentNumber, Title, Severity, Entities
| extend EntitiesText = tostring(Entities)

Step 6 — Build the incident timeline

Use first and last activity times to understand when the attack started, when it ended and how quickly it escalated.

let TargetIncident = 12345;
SecurityIncident
| where IncidentNumber == TargetIncident
| project IncidentNumber, Title, Severity,
          FirstActivityTime, LastActivityTime, CreatedTime, LastModifiedTime

Example incident story

Once the incident is understood, defenders can tell the story in plain language.

8:05 AM — Phishing email deliveredEmail telemetry showed the first suspicious message entering the environment.

8:07 AM — User clicked the linkURL click evidence showed the user interacted with the phishing link.

8:12 AM — Suspicious sign-in detectedIdentity telemetry showed authentication activity after the phishing interaction.

8:14 AM — Commands executedEndpoint telemetry showed suspicious activity after the account was accessed.

8:17 AM — Multiple alerts firedDifferent parts of Defender XDR raised separate alerts as the attack progressed.

8:18 AM — Incident createdSecurityIncident connected the evidence into one investigation.

Common investigation uses

SecurityIncident is most useful when defenders need to triage scope and understand how multiple alerts connect.

Incident triageReview severity, status, ownership and incident title to determine priority.

Attack reconstructionUse incident timing and entities to understand how the attack unfolded.

Threat hunting pivotsMove from a correlated incident into supporting tables such as AlertInfo, AlertEvidence, EmailEvents and DeviceProcessEvents.

Common mistakes

Incident investigations can go wrong when defenders treat every alert as a separate problem.

Looking only at alertsThe incident often contains the bigger picture that explains how alerts are related.

Ignoring correlationSeveral lower-severity alerts may combine into a serious attack when viewed together.

Investigating tables in isolationSecurityIncident is strongest when it guides pivots into AlertInfo, AlertEvidence, identity, email, cloud and endpoint telemetry.

What you learned

SecurityIncident groups related alertsYou can use it to investigate attacks as complete incidents rather than disconnected alerts.

Correlation reveals attacker behaviourMultiple alerts often belong to one attack chain across identity, email, endpoint and cloud activity.

Timelines provide contextIncident timing helps defenders understand when the attack started, changed and escalated.

Related Agent Foskett Academy lessons

Investigating AlertInfoReview alert metadata before connecting alerts into incident-level investigations.

Investigating AlertEvidenceConnect alerts to the users, devices, files, URLs and IP addresses involved.

Investigating EmailEventsUnderstand email evidence that may have triggered the incident.

Investigating UrlClickEventsReview whether users clicked links connected to phishing activity.

Investigating IdentityLogonEventsInvestigate authentication events linked to the incident.

Investigating CloudAppEventsReview cloud activity that may explain what happened after access was gained.

Building Investigation TimelinesTurn incident evidence into a clear chronological story.

Connecting Tables with joinJoin related evidence when you need to move beyond the incident summary.

Coming next

Lesson 49 — Investigating BehaviorEntities in Microsoft Defender XDRNext, Agent Foskett Academy will investigate behaviour analytics, unusual activity, risky patterns and hidden attacker behaviour.

Why this mattersSome investigations begin because an alert fires. Others begin because behaviour changes.

What you will learn nextLearn how behaviour entities help defenders identify risky activity that may not look suspicious in isolation.

Final thought

Five alerts rarely mean five problems.

Agent Foskett mindsetThe important question is not how many alerts fired. The important question is what attack generated them.

Follow the incidentSecurityIncident helps defenders move from noise to narrative.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD