Lesson 81 — This Investigation Should Become a Detection
The investigation was finished.
The behaviour was malicious. The device was contained. The timeline was complete.
Then Agent Foskett looked back at the evidence: browser → PowerShell → suspicious command → file execution → external communication.
“If this happens again tomorrow, why should we have to rediscover it manually?”
The investigation had found more than an attacker. It had found behaviour worth detecting.
Not every finding needs a detection.
The behaviour should be observable, repeatable enough to matter, sufficiently distinctive and connected to an action the SOC can take.
Case briefing
Investigation objective
Decide whether a validated investigation or hunting finding is suitable for operational detection by testing its observability, repeatability, distinctiveness, actionability and expected analyst value.
Investigator's rule
A detection should preserve the security hypothesis — not merely copy the query that happened to find it.
Stage 1 — start with the security hypothesis
| Weak starting point | Stronger starting point |
|---|---|
| Alert whenever PowerShell runs. | Identify unusual browser-initiated PowerShell with suspicious context. |
| Detect this IP. | Detect the repeatable behaviour associated with the incident; retain the IOC for enrichment. |
| Turn this hunt query into an alert. | Define what malicious behaviour the SOC needs surfaced and why. |
The query is an implementation
The hypothesis explains what matters. The query implements that hypothesis against available telemetry.
Preserve the reason
If future analysts cannot explain what security problem the rule is intended to identify, tuning becomes guesswork.
Stage 2 — can we observe it reliably?
Telemetry comes first
A strong hypothesis cannot compensate for missing or inconsistent data. Confirm coverage across the population the rule is meant to protect.
State coverage boundaries
If the logic works only on a subset of devices, document that limitation rather than implying universal visibility.
Stage 3 — reproduce the known behaviour
DeviceProcessEvents
| where Timestamp > ago(14d)
| 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 ascProve it sees the incident
If the candidate cannot reproduce the known malicious behaviour that motivated it, do not rush it into production.
Then inspect everything else
The engineering work begins when you review what the same logic returns across ordinary historical activity.
Stage 4 — test repeatability
Repeatable does not automatically mean detectable
The team must still understand how often legitimate activity produces the same pattern.
Look for stable characteristics
Meaningful process relationships and sequences often survive changes in attacker-controlled infrastructure.
Stage 5 — compare malicious and benign matches
| Characteristic | Malicious | Known benign |
|---|---|---|
| Browser → PowerShell | Observed | Rare |
| Novel command line | Observed | Not typical |
| User-writable staging | Observed | Not typical |
| Immediate external communication | Observed | Not typical |
| Approved change context | Absent | Present where expected |
Distinctiveness matters
A behaviour can be malicious yet make a poor standalone detection if normal activity constantly produces the same signal.
Do not tune away the hypothesis
Reduce irrelevant matches while preserving the suspicious behaviour. Lesson 82 will test this when false positives start dominating.
Stage 6 — is the result actionable?
Detection without response value creates noise
A rule is not useful merely because it can generate alerts. Its output should support a meaningful investigation.
Think about the analyst at 2 AM
The engineer knows why the rule matters. The receiving analyst needs the alert to transfer enough of that understanding.
Stage 7 — what should not become a detection?
| Finding | Likely treatment |
|---|---|
| One-time IOC with no continuing relevance | Enrichment or historical scoping |
| Very broad behaviour with overwhelming legitimate use | Keep hunting or add context |
| Behaviour requiring substantial human interpretation | May remain a proactive hunt |
| Repeatable, observable, distinctive and actionable behaviour | Strong detection candidate |
Not every hunt needs an alert
Some hypotheses are more valuable when investigated periodically with human context than when added permanently to the queue.
Operationalisation is a decision
The team should be able to explain why continuous monitoring creates more security value than retaining the behaviour as a hunt.
Stage 8 — define the candidate
Write limitations before deployment
A transparent detection says what it can establish and what it cannot.
Give it an owner
Someone must own tuning, environmental review, modification and eventual retirement.
Stage 9 — production-readiness check
| Question | Status |
|---|---|
| Meaningful security hypothesis? | Required |
| Reliable telemetry? | Required |
| Reproduces known malicious examples? | Required |
| Historical benign matches reviewed? | Required |
| Analyst can explain why it fired? | Required |
| Useful investigation path? | Required |
| Limitations and ownership documented? | Required |
Production is not the finish line
The environment changes, analysts provide feedback and assumptions must be revisited.
Detection engineering is operational engineering
The goal is not a clever query. The goal is reliable security value delivered repeatedly to the SOC.
Stage 10 — engineering decision
The investigation created protection
The SOC extracted a repeatable lesson from the evidence and began turning it into something capable of finding the behaviour next time.
The detection-engineering mindset
Investigate the attack. Understand the behaviour. Decide whether it is worth operationalising. Then engineer the signal so another analyst can act on it.
Lesson 81 key takeaways
- Start detection engineering with a security hypothesis, not a saved query.
- Not every finding needs a production detection.
- Confirm reliable telemetry coverage.
- Reproduce known malicious cases.
- Review historical legitimate matches.
- Repeatable behaviour is often more durable than one-time IOCs.
- Distinctiveness affects signal quality.
- Detection output must support analyst action.
- Document limitations and ownership.
- Preserve the original hypothesis while tuning implementation.
- Production begins an ongoing lifecycle.
Module 9 — Detection Engineering: Turning Findings into Protection
Lesson 81 recognised repeatable malicious behaviour worth operationalising. Lesson 82 tests what happens when the new detection starts producing too much noise.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 9: Detection Engineering: Turning Findings into Protection
When should a threat hunt become a detection?
Lesson 81 of the Agent Foskett SOC Analyst Academy teaches analysts how to decide whether repeatable malicious behaviour discovered during an investigation or threat hunt should be operationalised as a production detection.
Detection engineering in Microsoft Defender XDR
Evaluate detection candidates using hypotheses, telemetry coverage, historical behaviour, distinctiveness, analyst actionability, limitations and ownership before moving hunting logic into ongoing SOC protection.
