Lesson 73 — The Alert Was Quiet — The Hunt Wasn't
The SOC dashboard looked surprisingly calm.
One medium-severity endpoint alert.
No matching identity alert.
No second device alert.
No obvious incident cluster.
It would have been easy to investigate the alert, close it and move on.
Instead, Agent Foskett looked at the behaviour behind it.
PowerShell had created an outbound network connection shortly after a suspicious process chain.
So the team hunted for the same sequence across the environment.
The alert queue stayed quiet.
The telemetry didn't.
A quiet queue is not proof of a quiet environment.
Use one useful alert as a starting point, extract the behaviour and hunt for related activity that detection logic may not have surfaced.
Case briefing
Investigation objective
Use the behaviour contained in one alert to proactively hunt across endpoint telemetry and determine whether related activity exists outside the alert queue.
Investigator's rule
Detection coverage and attacker activity are not the same thing.
Stage 1 — understand what the alert actually gives you
| The alert tells you | The alert does not automatically tell you |
|---|---|
| A detection condition was met on FIN-WS-083. | No other device showed related behaviour. |
| A process or sequence deserved investigation. | The activity began with this alert. |
| Specific entities and timestamps can be pivoted on. | Every related technique has detection coverage. |
| The SOC has a useful starting point. | The alert defines the full incident scope. |
Alerts are evidence sources
An alert can be more than an item to close. Its entities, command lines, parent-child relationships, destinations and timestamps can become hunting leads.
Do not assume silence means absence
No additional alert may mean no additional malicious activity — but it may also reflect different execution, thresholds, exclusions, telemetry gaps or detection logic that was never designed to identify the related behaviour.
Stage 2 — extract the behaviour from the alert
Remove the alert-specific assumptions
If you hunt only for FIN-WS-083, you are investigating one endpoint. If the question is environmental scope, generalise the relevant behaviour and search across devices.
Keep enough structure to remain useful
“Find PowerShell” is too broad. The relationship between browser, PowerShell and subsequent activity provides a more meaningful hunting hypothesis.
Stage 3 — hunt the first part of the chain
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| project Timestamp, DeviceId, DeviceName,
AccountName, ProcessCommandLine,
InitiatingProcessFileName
| order by Timestamp ascThe first hunt is deliberately broader
This query tests whether the process relationship exists elsewhere. It does not require the exact command or destination from the original alert.
Broad does not mean careless
The query still expresses a specific relationship. The analyst can then use context and additional telemetry to reduce benign matches.
Stage 4 — the first surprise
The hunt expanded the population
The five matches are not five confirmed compromises. They are five devices where the behavioural relationship occurred and therefore five candidates for contextual analysis.
The unalerted devices matter
FIN-WS-091 and FIN-WS-104 deserve attention because they resemble the alerted finance endpoint without having generated the same alert.
Stage 5 — hunt the network side of the behaviour
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ (
"powershell.exe", "pwsh.exe"
)
| project Timestamp, DeviceId, DeviceName,
InitiatingProcessFileName,
RemoteIP, RemotePort, RemoteUrl
| order by Timestamp ascDo not require the original destination yet
If an attacker changed infrastructure, filtering only on the original IP address or domain could miss related activity. Hunt the process-to-network behaviour first, then compare destinations.
Different IOC, same technique
One unalerted device may contact a different destination while preserving the same execution sequence. That is exactly where behavioural hunting adds value.
Stage 6 — correlate by device and time
Sequences are stronger than isolated events
Browser-to-PowerShell followed quickly by PowerShell network activity gives the analyst a more specific behavioural chain than either event alone.
Timing helps establish relationships
Temporal proximity does not prove causation, but it helps identify which events belong in the same investigative window and deserve correlation.
Stage 7 — compare what alerted and what did not
| Question | Why it matters |
|---|---|
| Was the command line identical? | A small variation may explain why detection logic matched only one device. |
| Was the destination different? | An IOC-based component may have matched only known infrastructure. |
| Was a threshold crossed? | One event may have met a count, confidence or severity condition that others did not. |
| Was telemetry available at the same quality? | Visibility differences can affect detection. |
| Was an exclusion or suppression involved? | Detection tuning may intentionally alter alert generation. |
Do not guess why the alert was absent
The hunt can establish that related telemetry exists without an alert. Determining why requires reviewing the relevant detection logic, configuration and evidence.
A hunt can expose detection opportunities
If confirmed malicious behaviour repeatedly occurs without alerting, the SOC has learned something operationally useful: detection coverage may be improved.
Stage 8 — build the expanded timeline
The alert becomes one point on the timeline
Once related activity is found, the original alert is no longer the entire story. It is one timestamp inside a broader sequence of evidence.
Hunt backward as well as forward
Now ask whether the same behaviour existed before 09:14. The first alert is not necessarily the first malicious action.
Stage 9 — separate hunt findings from confirmed scope
| Evidence state | Analyst language |
|---|---|
| Process pattern only | Behavioural match |
| Process + network sequence | Higher-priority hunting candidate |
| Correlated malicious evidence | Confirmed affected entity |
| Expected business workflow | Explained benign activity |
| Insufficient evidence | Unresolved — continue investigation |
Use precise language
“The hunt found two additional compromised devices” is only defensible after the evidence supports compromise. Before that, they are related candidates or suspicious matches.
Escalate when the evidence changes the incident
If proactive hunting confirms additional affected devices, update scope, containment decisions, stakeholders and the incident timeline.
Stage 10 — turn the discovery into SOC improvement
Hunting and detection strengthen each other
Alerts can seed hunts. Hunts can expose gaps. Successful hunt logic can inform new analytics, detection tuning, investigation guidance or recurring hunting procedures.
The queue is not the environment
The SOC manages alerts, but it investigates evidence. Threat hunting deliberately looks beyond what existing detection logic has already decided to surface.
Lesson 73 key takeaways
- A quiet alert queue does not prove there is no related activity.
- Use useful alerts as starting points for proactive hunting.
- Extract behaviour from the alert instead of hunting only its exact IOCs.
- Generalise device-specific evidence when the goal is environmental scope.
- Behavioural matches are candidates, not automatic compromise.
- Correlate process and network telemetry to strengthen a hunting lead.
- Different infrastructure can still support the same attacker technique.
- Compare alerted and unalerted activity without guessing why detection differed.
- Build a broader timeline when hunting expands the evidence.
- Hunt backward as well as forward from the original alert.
- Confirmed unalerted malicious activity can reveal detection opportunities.
- The alert queue is a view of detections — not a complete map of the environment.
Module 8 — Threat Hunting: Looking Beyond the Alerts
Lesson 73 used proactive hunting to uncover related activity beyond a quiet alert queue. Lesson 74 tackles the next problem: before calling something anomalous, the analyst needs to understand what normal actually looks like in that environment.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 8: Threat Hunting: Looking Beyond the Alerts
How can threat hunting find activity that did not generate an alert?
Lesson 73 of the Agent Foskett SOC Analyst Academy teaches analysts how to use an existing alert as a hunting lead, extract the underlying behaviour and search Microsoft Defender XDR telemetry for related unalerted activity.
Proactive threat hunting beyond the alert queue
Learn how to hunt browser-to-PowerShell and PowerShell network behaviour, correlate endpoint evidence, distinguish hunting candidates from confirmed incident scope and identify opportunities to improve detection coverage.
