Lesson 11 — The Same Alert Fired on 30 Devices
A new detection appears in the SOC queue. Then another. Then another.
Within fifteen minutes, the same alert has fired on 30 devices.
Is this one widespread incident, 30 unrelated events, a software rollout,
or a noisy detection that suddenly found a common behaviour?
One alert pattern — thirty devices
The queue looks dramatic. Your first job is to determine whether the devices share a common cause, common attacker behaviour or simply common software.
Case briefing
Investigation objective
Determine whether repeated alerts across many devices represent one coordinated incident, repeated benign behaviour, or a noisy detection pattern that should be grouped and handled differently.
Investigator's rule
Count alone is not scope. Scope comes from shared entities, timing, behaviour and cause.
Stage 1 — ask what is actually repeating
| Repeated element | What it might mean |
|---|---|
| Same alert name | The same detection logic fired — not necessarily the same activity. |
| Same process name | Could indicate common software, attacker tooling or shared administration. |
| Same command line | Stronger evidence of a shared cause. |
| Same parent process | May reveal deployment tooling, browser delivery or common execution ancestry. |
| Same user or service account | May indicate central administration or account misuse. |
| Same external IP / URL | Could support coordinated command-and-control or shared update infrastructure. |
Start with commonality
Do not open 30 separate investigations first. Determine whether the alerts share behaviour that can explain the entire cluster.
Same title can hide different causes
Two devices can trigger the same analytic rule for completely different command lines or process chains. The detection name is only the starting point.
Stage 2 — measure prevalence with KQL
Use KQL to see how many devices are involved and whether the alert pattern is tightly concentrated in time.
DeviceProcessEvents
| where Timestamp > ago(2h)
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has "invoice-update.ps1"
| summarize
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp),
EventCount=count()
by DeviceName
| order by FirstSeen asc
Thirty devices in ten minutes is different
A narrow time window suggests central deployment, coordinated execution or another shared trigger. Thirty events spread over three months tell a very different story.
Prevalence changes interpretation
A command seen once may be unusual. The same exact command on hundreds of managed devices may be normal software behaviour — or a widespread incident. You still need context.
Stage 3 — compare process ancestry
Now determine whether the same parent process launched the suspicious activity across the affected devices.
DeviceProcessEvents
| where Timestamp > ago(2h)
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has "invoice-update.ps1"
| summarize
Devices=dcount(DeviceName),
Events=count()
by InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Devices desc
One parent across 30 devices
If the same management agent launched the script everywhere, the cluster may be explained by approved administration or software deployment.
Different parents change the picture
If browsers, Office applications and unknown executables launched the same suspicious script independently, the incident becomes much more concerning.
Stage 4 — compare possible explanations
| Explanation | Evidence that would support it |
|---|---|
| Approved software deployment | Same management parent, same signed package, expected rollout window. |
| Widespread compromise | Same malicious command, suspicious parent process, shared external infrastructure. |
| Noisy detection | Repeated benign behaviour frequently seen across the environment. |
| Mixed activity | Some devices match approved behaviour while a smaller subset has materially different context. |
Do not close the cluster too quickly
Finding benign behaviour on 28 devices does not automatically explain the remaining two. Outliers can be the most important part of the investigation.
Look for the exception
If 29 devices share the same management parent and one device shows browser-launched PowerShell, that single outlier may deserve immediate priority.
Stage 5 — decide whether this is one incident or many
Your triage decision board
| Finding | Meaning | Action |
|---|---|---|
| 28 devices share approved management ancestry | Likely benign common cause | Validate deployment/change context |
| 2 devices show browser-launched PowerShell | Does not match the benign explanation | Separate and investigate immediately |
| Both outliers contact the same unfamiliar host | Stronger evidence of shared suspicious activity | Group the two devices into one incident |
Write the finding like an analyst
Example: Thirty alerts were generated for similar PowerShell activity across 30 endpoints. Prevalence and process-ancestry analysis identified that 28 devices executed the script through an approved management process during a known deployment window. Two devices did not match that pattern and instead showed browser-launched PowerShell followed by connections to the same unfamiliar external destination. The 28 expected events were separated from the suspicious outliers, and the two affected devices were grouped into a single incident for further investigation.
Lesson 11 key takeaways
- Thirty alerts do not automatically mean thirty incidents.
- Start by identifying what behaviour actually repeats across the affected devices.
- Use KQL to measure prevalence, timing and device distribution.
- Process ancestry can reveal a common deployment or common attack path.
- Common benign behaviour can explain a large alert cluster.
- Do not assume a benign explanation applies to every device.
- Outliers often deserve the highest investigative attention.
- Shared commands, parents, identities and destinations strengthen correlation.
- Group alerts when the evidence supports one underlying incident or campaign.
- Split mixed clusters when different causes are present.
Module 2 — alert triage
You have learned how to triage repeated alerts across many devices. The next lesson continues Module 2 by examining another common queue-prioritisation problem.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 2: Alert Triage — Deciding What Matters First
How to investigate the same alert across many devices
Lesson 11 of the Agent Foskett SOC Analyst Academy teaches analysts how to determine whether repeated alerts across many devices represent one widespread incident, common benign activity or detection noise.
KQL alert prevalence and device correlation
Learn how to use Microsoft Defender XDR and KQL to measure device prevalence, compare process ancestry, find outliers and group repeated security alerts into the correct investigation scope.
