Lesson 76 — Three Weak Signals Became One Strong Lead
None of the events looked particularly convincing on its own.
A user signed in from an unfamiliar IP address.
PowerShell ran once on their workstation.
And the device contacted a domain nobody immediately recognised.
Three observations.
Three possible explanations.
No high-severity alert.
Individually, each signal was weak.
Agent Foskett put them on the same timeline.
Suddenly, they were not three weak signals anymore.
One signal may be noise. Three related signals may tell a story.
Correlation does not magically turn uncertainty into proof, but it can raise a candidate high enough to justify deeper investigation.
Case briefing
Investigation objective
Identify several low-confidence observations, correlate them by entity and time, test whether they form a coherent behavioural sequence, and decide whether the combined evidence justifies deeper investigation.
Investigator's rule
Correlation increases context. It does not remove the need for evidence.
Stage 1 — understand why each signal is weak
| Signal | Why it matters | Why it is weak alone |
|---|---|---|
| Unfamiliar sign-in IP | May indicate unexpected access. | Could be travel, mobile connectivity, VPN or changing ISP infrastructure. |
| PowerShell execution | Can be used during malicious execution. | PowerShell is also a legitimate administrative and automation tool. |
| Unknown destination | May represent attacker-controlled infrastructure. | Unfamiliar does not mean malicious; legitimate applications contact many domains. |
Weak does not mean useless
A low-confidence observation can still contribute to an investigation. The mistake is either dismissing it entirely or treating it as proof before context exists.
Preserve the original uncertainty
Record what each signal actually shows. Do not rewrite “unfamiliar IP” as “malicious IP” merely because later evidence looks suspicious.
Stage 2 — start with the endpoint signal
DeviceProcessEvents
| where Timestamp between (
datetime(2026-09-04 09:00:00) ..
datetime(2026-09-04 09:30:00)
)
| where DeviceName =~ "FIN-WS-204"
| where FileName in~ ("powershell.exe", "pwsh.exe")
| project Timestamp, DeviceId, DeviceName,
AccountName, ProcessCommandLine,
InitiatingProcessFileName
| order by Timestamp ascContext changes the value of PowerShell
The analyst checks the command line, parent process, account and timing. A routine management script and a browser-spawned encoded command are very different hunting candidates.
Keep the entity anchors
DeviceId, DeviceName, account and timestamp allow the analyst to pivot into other telemetry without losing the relationship between observations.
Stage 3 — the process context strengthens signal two
Evidence can strengthen a signal without proving compromise
The browser parent and novel command make the event more interesting, but the analyst still needs corroborating evidence before reaching a verdict.
Novelty is contextual
“Not previously observed” means not observed in the available telemetry and retention period. State the boundary rather than claiming the behaviour has never happened.
Stage 4 — pivot into network telemetry
DeviceNetworkEvents
| where Timestamp between (
datetime(2026-09-04 09:10:00) ..
datetime(2026-09-04 09:25:00)
)
| where DeviceName =~ "FIN-WS-204"
| project Timestamp, DeviceId, DeviceName,
InitiatingProcessFileName,
RemoteIP, RemotePort, RemoteUrl
| order by Timestamp ascAsk which process made the connection
An unknown destination contacted by a normal browser has different context from the same destination contacted by the suspicious PowerShell process.
Relationship matters more than proximity alone
Two events occurring close together are not automatically connected. Process attribution, device identity and other telemetry should support the relationship.
Stage 5 — signal three joins the sequence
Convergence raises priority
The network event is stronger because it is attributable to the same process under investigation. The process event is stronger because it has meaningful follow-on behaviour.
Still avoid IOC shortcuts
An unfamiliar domain is not automatically malicious. The behavioural chain can justify investigation even before reputation or external intelligence provides an answer.
Stage 6 — bring in the identity signal
Identity-to-endpoint correlation can be powerful
When available evidence links an unusual sign-in, the same user's device session and suspicious endpoint activity, the combined sequence deserves more attention than any observation alone.
Do not invent the missing link
If the evidence cannot establish that the sign-in session led to the endpoint execution, say so. Temporal alignment creates a hypothesis to test, not automatic causation.
Stage 7 — test alternative explanations
| Alternative | Evidence to seek |
|---|---|
| User legitimately changed network location | User confirmation, known VPN, expected geography and device context. |
| PowerShell was business activity | Known script, approved application, administrator action or historical pattern. |
| Destination was legitimate | Application ownership, historical prevalence, known service relationship. |
| Events are unrelated coincidence | Different users, processes, sessions or timelines that break the proposed sequence. |
Try to disprove the hunting lead
A strong analyst does not collect only evidence that supports the suspicious story. Search deliberately for legitimate explanations that would weaken it.
Confidence grows when alternatives fail
If independent validation cannot explain the sign-in, process chain or network activity, the combined lead becomes progressively stronger.
Stage 8 — hunt for the combination elsewhere
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| summarize Events=count(),
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp)
by DeviceId, DeviceName, AccountName
| order by Events descHunt the strongest reusable behaviour
The full story may involve data from several sources, but the analyst can start environmental scoping with the strongest observable component and then enrich matching candidates.
Do not overfit to the first case
Requiring the exact IP, command and destination may miss related activity. Preserve the behavioural idea while allowing attackers to vary infrastructure and syntax.
Stage 9 — prioritise by signal convergence
Correlation helps triage hunt results
When a hunt returns many candidates, additional independent signals can help the SOC decide where deeper investigation should begin.
A score is not required to think this way
The important skill is understanding why the combined evidence is stronger. Avoid arbitrary numerical confidence unless your SOC has a defined, validated scoring method.
Stage 10 — write the hunting finding
Keep the conclusion proportional
The goal of this hunt was not to manufacture certainty. It was to recognise when multiple uncertain observations collectively justify a deeper investigation.
The timeline is the multiplier
Separate events become more useful when the analyst can show how entities, processes and timestamps connect. That is why building the timeline remains one of Agent Foskett's favourite moves.
Lesson 76 key takeaways
- Weak signals can still be valuable evidence.
- Do not promote an uncertain observation into a fact.
- Correlate signals by user, device, process and time.
- Process context can strengthen otherwise common activity such as PowerShell.
- Attribute network activity to the initiating process where telemetry supports it.
- Temporal proximity alone does not prove causation.
- Identity and endpoint evidence can create a stronger combined hunting hypothesis.
- Actively test legitimate alternative explanations.
- Confidence increases when independent evidence converges and alternatives fail.
- Hunt reusable behaviour rather than overfitting exact IOCs.
- Use signal convergence to prioritise deeper investigation.
- Keep final conclusions proportional to what the evidence proves.
Module 8 — Threat Hunting: Looking Beyond the Alerts
Lesson 76 combined several individually weak observations into a much stronger hunting lead. Lesson 77 explores the opposite result: the hunt finds nothing. That does not necessarily make the hunt a failure — but the analyst must understand exactly what a negative finding does and does not prove.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 8: Threat Hunting: Looking Beyond the Alerts
How do threat hunters combine weak security signals?
Lesson 76 of the Agent Foskett SOC Analyst Academy teaches analysts how to correlate individually low-confidence identity, endpoint and network observations into a stronger threat hunting candidate.
Correlating weak signals in Microsoft Defender XDR
Learn how to use timelines, entity pivots, process context and KQL hunting queries to test whether weak observations converge into a coherent behavioural sequence while keeping conclusions proportional to the evidence.
