Lesson 39 — Investigating the Alerts Inside an Incident

Learning objectives

• Understand what an alert contributes to an incident investigation.
• Identify the detection source, timestamps, entities and supporting evidence for each alert.
• Validate alert claims against the underlying telemetry.
• Recognise shared entities and relationships between alerts.
• Build an evidence-based sequence without assuming correlation proves causation.

The investigation

A Sentinel incident contains four alerts across identity, email and endpoint security.

The incident title suggests account compromise.

That is useful orientation — but the analyst still needs to understand why every alert fired.

Do not investigate the alert title

An alert title is a concise description of the detection. It is not the raw evidence.

Open the alert and inspect the details that caused the detection to fire: affected assets, entities, timestamps, detection source, activity and supporting evidence.

Ask what the alert actually proves

“Suspicious sign-in” does not automatically prove successful compromise.

It may prove that authentication behaviour met suspicious criteria. You still need to establish whether authentication succeeded, what session was created and what happened next.

Step 1 — identify the source

Determine which Microsoft security product, Sentinel analytics rule or other connected provider generated the alert.

The source tells you what telemetry and detection logic you are dealing with and where deeper evidence may live.

Know the detection type

A custom Sentinel scheduled rule, Microsoft security analytic, Defender for Endpoint detection and Defender for Identity alert do not all work the same way.

Understanding the source helps you interpret what the alert means — and what it does not mean.

Step 3 — identify the entities

Look for users, devices, IP addresses, mailboxes, applications, URLs, files and cloud resources attached to the alert.

These entities become pivots into other evidence and often reveal why apparently different alerts belong in the same incident.

Shared entities are powerful clues

If three alerts contain the same user and two also contain the same device, that relationship deserves investigation.

It does not prove a single attacker caused every event — but it gives you a testable hypothesis.

Step 4 — inspect the evidence

The Defender incident experience exposes evidence associated with alerts and incidents, including affected assets and observable items such as files, processes, IP addresses and URLs where supported.

Inspect what was actually observed instead of relying only on the alert description.

Evidence has context

Evidence can carry information such as entity type, verdict, remediation status and the alerts that reference it.

Use that context to decide which item deserves deeper investigation and whether multiple alerts are pointing at the same object.

Example — validate the sign-in

SigninLogs
| where UserPrincipalName =~ "alex@contoso.com"
| where TimeGenerated between (datetime(2026-10-07 01:50:00) .. datetime(2026-10-07 02:20:00))
| project TimeGenerated, UserPrincipalName, IPAddress,
          AppDisplayName, ResultType, ResultDescription,
          ConditionalAccessStatus, CorrelationId
| order by TimeGenerated asc

The question is specific: what authentication activity occurred around the alert, and what was the result?

Do not copy example values blindly

The user, timestamps and fields above are teaching examples. In a real investigation, use the incident's entities and activity window.

Your query should answer the question raised by the alert you are investigating.

Step 7 — compare the alerts

Once each alert makes sense individually, compare them.

Look for common users, devices, IPs, applications, files, domains and timestamps. Then test whether the sequence is technically plausible.

Correlation is a hypothesis

Alerts grouped into an incident are related strongly enough for the platform to present them together, but analysts should still validate the relationship.

A shared user may connect two alerts legitimately. Timing and underlying telemetry determine whether the connection supports an attack story.

MITRE ATT&CK adds structure

Alerts may include ATT&CK tactics and techniques. Comparing them can help you understand the behaviours represented across the incident.

Do not force them into a complete attack chain merely because the techniques look sequential. ATT&CK classification describes behaviour — the evidence still has to connect it.

Recommendations are leads

Alert and incident experiences may provide recommended actions or investigation guidance.

Use recommendations to accelerate investigation, but understand why an action is appropriate before applying it to your environment.

Common mistake — trust the alert name

The analyst repeats “account compromised” because that is how the alert sounds.

Translate alert language back into observable facts before making a determination.

Common mistake — investigate only the highest alert

The lower-severity alert may contain the evidence that explains the whole incident.

Every contributing alert deserves enough review to understand its role in the case.

Common mistake — ignore timestamps

Without chronology, related alerts become a pile of detections rather than an investigation.

Time is one of the strongest tools for testing whether an attack story makes sense.

Common mistake — stop at the alert

An alert is a detection result, not the end of the investigation.

Pivot into the underlying identity, endpoint, email, network or cloud telemetry when the answer matters.

Best practices

• Open every contributing alert.
• Understand the detection source and logic.
• Use activity time, not just alert creation time.
• Map shared entities between alerts.
• Validate important claims against telemetry.
• Separate observed facts from attack hypotheses.
• Use chronology to test relationships.
• Keep alternative explanations alive until evidence rules them out.

Agent Foskett takeaway

The incident tells you which clues arrived together.

The alerts tell you why each clue exists.

Open them. Validate them. Connect only what the evidence allows you to connect.