ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Sentinel • SecurityIncident • SecurityAlert • Alert Correlation • KQL

The Incident Contained Three Alerts — The Fourth Was Somewhere Else

The Microsoft Sentinel incident looked complete.

Three alerts.
One user.
One device.
A tidy sequence of suspicious activity.

The incident timeline seemed to explain what had happened.

But Agent Foskett noticed that one entity appeared earlier in the raw evidence than it did inside the incident.

So where was the alert that explained it?

It existed.

It simply was not part of this incident.

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating Microsoft Sentinel alerts beyond an incident boundary
The Incident Was Not the Whole Investigation.

Incidents group alerts to help analysts investigate. The surrounding telemetry can still contain related evidence outside that grouping.

✓ Establish the incident boundary
✓ Extract alert entities
✓ Hunt beyond the grouped alerts

Three alerts can still be an incomplete story

Microsoft Sentinel incidents correlate alerts into a case that analysts can triage and investigate.

That grouping is enormously useful.

But Agent Foskett treated it as a starting scope — not an unquestionable boundary.

An incident tells you which alerts were grouped together. It does not guarantee that every related security event has been grouped into the same incident.

Start with the incident record

The SecurityIncident table includes incident metadata and the alert identifiers associated with the incident. Agent Foskett first established exactly which alerts Sentinel had placed inside the case.
incident-alert-ids.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let TargetIncident = "INCIDENT-NUMBER-HERE";
SecurityIncident
| where TimeGenerated > ago(30d)
| where IncidentNumber == toint(TargetIncident)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| project IncidentNumber,
          Title,
          Severity,
          Status,
          CreatedTime,
          FirstActivityTime,
          LastActivityTime,
          AlertIds

The incident boundary was now explicit

The incident contained three alert IDs.

That gave Agent Foskett something concrete to compare against the wider alert population.

He was no longer asking vaguely whether something might be missing.

He knew exactly which alerts were inside the incident — and could now search for related alerts outside it.

Expand the alerts inside the incident

Agent Foskett expanded the incident's AlertIds and joined them to SecurityAlert.SystemAlertId. This reconstructed the three alerts Sentinel had correlated into the case.
incident-securityalerts.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
let TargetIncident = 12345;
let IncidentAlerts =
    SecurityIncident
    | where TimeGenerated > ago(30d)
    | where IncidentNumber == TargetIncident
    | summarize arg_max(TimeGenerated, *) by IncidentNumber
    | mv-expand AlertId = AlertIds
    | project IncidentNumber,
              AlertId = tostring(AlertId);
IncidentAlerts
| join kind=inner (
    SecurityAlert
    | where TimeGenerated > ago(30d)
    | project SystemAlertId,
              TimeGenerated,
              AlertName,
              AlertSeverity,
              ProviderName,
              CompromisedEntity,
              Entities
) on $left.AlertId == $right.SystemAlertId
| project TimeGenerated,
          IncidentNumber,
          SystemAlertId,
          AlertName,
          AlertSeverity,
          ProviderName,
          CompromisedEntity,
          Entities
| order by TimeGenerated asc

One entity appeared before the incident's first alert

The three alerts shared a user and device.

But when Agent Foskett pivoted into the surrounding telemetry, the device appeared in suspicious activity before the first alert in the incident.

That meant either the activity had not generated an alert — or another alert existed elsewhere.

The incident timeline began too late to explain the first suspicious evidence.

Search all alerts for the shared entity

Agent Foskett widened the search to SecurityAlert. In a real case, the strongest pivot might be a device, account, IP address, URL, process or another entity extracted from the incident. This example uses the compromised-entity field as a first pass.
alerts-beyond-the-incident.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let TargetEntity = "LAPTOP-042";
SecurityAlert
| where TimeGenerated > ago(14d)
| where CompromisedEntity =~ TargetEntity
   or Entities has TargetEntity
| project TimeGenerated,
          SystemAlertId,
          AlertName,
          AlertSeverity,
          ProviderName,
          CompromisedEntity,
          Entities
| order by TimeGenerated asc

There it was

A fourth alert referenced the same investigation context.

Its timestamp preceded the three alerts inside the incident.

It involved the same device and helped explain how the later activity began.

But its SystemAlertId was not one of the IDs associated with the target incident.

The alert existed. The correlation boundary had placed it somewhere else.

Prove which related alerts are outside the incident

Instead of relying on the portal view, Agent Foskett compared the target incident's alert-ID set with the broader alert search. This makes the distinction between “related to the investigation” and “contained in this incident” explicit.
related-alerts-not-in-incident.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
let TargetIncident = 12345;
let TargetEntity = "LAPTOP-042";
let IncidentAlertIds =
    SecurityIncident
    | where TimeGenerated > ago(30d)
    | where IncidentNumber == TargetIncident
    | summarize arg_max(TimeGenerated, *) by IncidentNumber
    | mv-expand AlertId = AlertIds
    | summarize make_set(tostring(AlertId));
SecurityAlert
| where TimeGenerated > ago(14d)
| where CompromisedEntity =~ TargetEntity
   or Entities has TargetEntity
| extend InTargetIncident =
    SystemAlertId in (IncidentAlertIds)
| project TimeGenerated,
          SystemAlertId,
          AlertName,
          AlertSeverity,
          ProviderName,
          InTargetIncident
| order by TimeGenerated asc

Why might the fourth alert be elsewhere?

Agent Foskett did not assume the answer.

Different analytics rules can have different incident-creation and grouping behaviour.
Alerts can be generated at different times.
Incident grouping can depend on configured matching logic and time windows.
Some Microsoft security alerts may also arrive through different providers or product integrations.

A missing alert from one incident is not automatically evidence of a Sentinel failure.

The job was to establish the relationship and then inspect the applicable incident and analytics configuration.

Search for the alert's own incident context

Once the fourth alert was identified, Agent Foskett checked whether it belonged to another Sentinel incident, whether that incident had been closed, and whether analysts had already investigated it separately.

This mattered because two incident records could represent different slices of the same underlying attack.

Case boundaries can divide evidence that an attacker never divided.

Find incidents containing the fourth alert

The alert ID can be searched against SecurityIncident.AlertIds to determine whether Sentinel associated it with another incident.
find-alert-incident.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
let FourthAlertId =
    "00000000-0000-0000-0000-000000000000";
SecurityIncident
| where TimeGenerated > ago(30d)
| where AlertIds has FourthAlertId
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| project IncidentNumber,
          Title,
          Severity,
          Status,
          Owner,
          CreatedTime,
          FirstActivityTime,
          LastActivityTime,
          AlertIds
| order by CreatedTime asc

Then return to the underlying telemetry

Finding the fourth alert expanded the investigation, but Agent Foskett still did not treat alerts as the ultimate source of truth.

He pivoted from the shared entities and timestamps into the raw identity, endpoint, network or cloud telemetry behind the detections.

Alerts tell you what detection logic noticed. Source events tell you what the environment recorded.

Build the expanded attack timeline

Incident openedMicrosoft Sentinel groups three alerts into a single investigation.
Shared entities reviewedThe alerts reveal a common user, device and investigation context.
Earlier evidence discoveredRaw telemetry shows suspicious activity before the incident's first alert.
Alert search widenedSecurityAlert reveals another alert involving the same investigation context.
Incident membership comparedThe fourth alert is confirmed outside the target incident's AlertIds.
Timeline reconstructedAll relevant alerts and source telemetry are investigated together rather than as isolated cases.

What Agent Foskett checked

Incident alert IDsWhich alerts are actually associated with the target Sentinel incident?
Shared entitiesWhich users, devices, IPs and other entities connect the alerts?
Wider SecurityAlert historyAre there related alerts outside the target incident?
Time boundariesDid suspicious activity begin before the incident's first alert?
Other incidentsWas the missing alert correlated into a different case?
Raw telemetryDoes the underlying evidence support one continuous attack story?

What the evidence can and cannot prove

SecurityIncident.AlertIds identifies alerts associated with an incident record, while SecurityAlert.SystemAlertId identifies individual alerts available in the workspace.

A related alert appearing outside the target incident proves only that it was not included in that incident's alert-ID set at the time represented by the record being examined.

It does not by itself prove that incident grouping malfunctioned.

The analyst must investigate grouping configuration, timestamps, entities, alert providers and the underlying telemetry before explaining why the alert was elsewhere.

The lesson

The incident contained three alerts.

All three mattered.

But the fourth alert changed the beginning of the timeline.

If Agent Foskett had investigated only what was already grouped into the incident, he would have started the story too late.

An incident is a correlation of evidence. It is not necessarily the boundary of the attack.
Investigation principle: Use the incident to establish an initial scope, then hunt outward through shared entities, time and source telemetry to determine whether related evidence exists beyond the incident boundary.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingUse KQL to investigate alerts, incidents, identities, endpoints and cloud evidence.SOC Analyst AcademyBuild practical incident triage, correlation and threat-hunting skills.
Three alerts were inside the incident. The fourth changed the story.
Start with the incident. Hunt beyond its boundary.
Continue the Investigation

Final thought

Incidents make complex security evidence manageable.

They give analysts a case to open, assign, classify and investigate.

But attackers do not organise their activity around incident numbers.

Agent Foskett used the incident as the doorway — not the walls of the investigation.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Incident Contained Three Alerts — The Fourth Was Somewhere Else

This Agent Foskett investigation examines a Microsoft Sentinel incident containing three alerts and demonstrates how a related fourth alert can exist outside the incident correlation boundary.

Investigate Microsoft Sentinel Incidents with KQL

Use SecurityIncident, AlertIds, SecurityAlert, SystemAlertId, shared entities and KQL to compare incident membership with the wider alert population and reconstruct a broader attack timeline.

Hunt Beyond the Incident Boundary

Learn why a Sentinel incident should be treated as an initial investigation scope rather than proof that every related alert or source event has already been correlated into the same case.