Lesson 35 — Building a Complete Sentinel Detection
Anyone can write a query.
The job is not finished until that query becomes a detection an analyst can trust.
What you will build
A complete scheduled analytics rule from evidence to investigation.
Learning objectives
- Bring the full scheduled analytics rule workflow together.
- Build detection logic from a clear security hypothesis.
- Configure scheduling, thresholds, entities and alert enrichment.
- Map the detection to MITRE ATT&CK based on evidence.
- Test the rule as an analyst would experience it.
- Define what happens after the rule enters production.
The investigation
The SOC wants to detect one source IP repeatedly failing authentication against many user accounts — behaviour consistent with password spraying.
We are going to build the detection from the evidence upward rather than opening the rule wizard and guessing.
The complete detection lifecycle
Step 1 — write the hypothesis
Hypothesis: one source IP failing authentication against many distinct user accounts within a short period can indicate password spraying.
This sentence defines the behaviour. It tells us which evidence matters and prevents the rule from becoming a vague “suspicious sign-in” detector.
Step 2 — identify the telemetry
For this example we use SigninLogs. We need the event time, source IP, user account and sign-in result.
Before writing detection logic, confirm the required table is populated and the fields contain the values you expect.
Step 3 — build the KQL
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
SigninLogs
| where ResultType != "0"
| summarize FailedAttempts = count(),
TargetUsers = dcount(UserPrincipalName),
Users = make_set(UserPrincipalName, 20),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by IPAddress
| where FailedAttempts >= 20 and TargetUsers >= 5The query describes the behaviour rather than merely returning failed sign-ins. Each result represents a source IP that crossed both the failed-attempt and distinct-user thresholds.
Do not add a fixed time filter blindly
Scheduled rules evaluate data using their configured lookback period and TimeGenerated. Design the rule query and scheduling together so the detection window is clear.
A manual hunting query may use a convenient ago() filter; production scheduling needs deliberate timing.
Step 4 — validate against history
Run the candidate logic against historical data. Inspect every result you can reasonably validate.
Separate known benign scanners, testing systems and expected applications from activity that really deserves analyst attention.
Step 5 — choose frequency and lookback
| Setting | Example design | Reason |
|---|---|---|
| Run query every | 15 minutes | Provides regular detection without treating this example as a real-time rule. |
| Lookup data from the last | 30 minutes | Provides a wider detection window and some tolerance for timing. |
| KQL behavioural threshold | 20 failures / 5 users | Defines the password-spray hypothesis. |
| Rule-result threshold | Generate when query results exceed the configured minimum | Controls whether returned result rows create an alert. |
These are teaching values, not universal production thresholds. Tune them from your own environment and threat model.
Overlapping windows are deliberate
A 15-minute interval with a 30-minute lookback means query windows overlap. That can improve coverage but can also expose the same activity to multiple executions.
Plan alert and incident grouping with that behaviour in mind.
Remember ingestion latency
Microsoft Sentinel scheduled analytics rules run with a built-in five-minute delay to help account for ingestion latency.
If your source commonly arrives later than that, measure the delay and design the lookup strategy accordingly rather than assuming the event was available.
Step 6 — map the entity
Entity mapping is not decoration. It turns a query value into an entity Sentinel can expose to investigation and correlation experiences.
What about the user accounts?
Our query aggregates many users into the Users dynamic array. That is useful investigation context, but it is not one clean account identifier.
Do not force an account entity mapping merely because accounts appear somewhere in the result. Map fields that correctly represent the entity schema.
Step 7 — add custom details
Surface FailedAttempts, TargetUsers, FirstSeen and LastSeen as useful alert context.
The analyst should immediately understand the scale and timing of the activity without rerunning the query first.
Step 8 — make the alert readable
Sentinel can customize alert details using values returned by the query. Use that capability carefully to make the detection understandable.
Possible password spray from a source IP — multiple failed sign-ins across distinct user accounts.
Avoid dramatic names such as “PASSWORD SPRAY ATTACK CONFIRMED.” The rule identifies evidence consistent with the hypothesis; the investigation determines what actually happened.
Step 9 — map MITRE ATT&CK
The behaviour in this example supports mapping to the Credential Access tactic and the Brute Force technique, specifically Password Spraying where the rule logic genuinely represents that behaviour.
Do not add Initial Access, Persistence or Privilege Escalation simply because they could happen later.
Step 10 — choose event grouping
Decide whether each returned result should become its own alert or whether all returned events should be grouped into a single alert.
For a result set where each row represents a distinct suspicious source IP, per-result alerts can preserve that separation — but always consider expected volume.
Step 11 — design the incident
Decide how alerts should become incidents. Sentinel supports grouping related alerts using mapped entities and selected details.
| Choice | Investigation effect |
|---|---|
| Separate incidents | Each alert begins its own investigation context. |
| Group when entities match | Repeated alerts involving the same mapped entities can be investigated together. |
| Group by selected entities/details | Provides more deliberate control over which alerts belong together. |
In the Defender portal, Defender XDR's correlation engine is responsible for incident correlation, so actual incident grouping can differ from the initial Sentinel rule grouping instructions.
Step 12 — simulate before enabling
Use Results simulation → Test with current data. Microsoft Sentinel simulates the scheduled rule 50 times using the configured schedule and current data.
Look for alert storms, long quiet periods, threshold boundaries and known benign spikes.
Simulation is not the whole test
Simulation shows expected result volume. You still need to validate known true positives, known false positives, entity mappings, custom details and the final analyst experience.
The rule must make sense after it fires, not just before.
The pre-production test matrix
| Test | Expected outcome |
|---|---|
| Known password-spray sample | Detection matches. |
| 19 failures against 5 users | Below the example failed-attempt threshold. |
| 20 failures against 4 users | Below the example distinct-user threshold. |
| Known approved scanner | Handled according to documented tuning policy. |
| Multiple suspicious source IPs | Alert/event grouping behaves as designed. |
| Generated alert | IP entity and custom details appear correctly. |
Step 13 — tune with evidence
If a known benign source repeatedly matches, prove why it is benign before excluding it.
Prefer narrow, maintainable exceptions. A watchlist can be appropriate where a centrally managed list of approved sources is required.
Do not tune away the hypothesis
If the rule becomes quiet only because every noisy account, subnet and application has been excluded, revisit the detection design.
Tuning should improve signal quality without destroying the behaviour you intended to detect.
Step 14 — enable and verify
Production enablement is not the end of testing. Verify that the complete path works in the live environment.
Step 15 — monitor the detection
Track alert volume, false positives, missed expected behaviour and execution health. A detection is operational content, not a page of KQL you forget after deployment.
Changes to identity systems, data sources, schemas and business processes can all change its behaviour.
Document why the rule exists
Record the hypothesis, data dependencies, thresholds, expected entities, exceptions, ATT&CK mapping, owner and tuning rationale.
The next analyst should not have to reverse-engineer your intentions from the query.
Complete detection specification
| Component | Our example |
|---|---|
| Hypothesis | One IP failing against many accounts may indicate password spraying. |
| Telemetry | SigninLogs |
| Primary entity | IP address |
| Behaviour | 20+ failed attempts against 5+ distinct users |
| Example frequency | 15 minutes |
| Example lookback | 30 minutes |
| Custom details | Failure count, target count, first seen, last seen |
| ATT&CK | Credential Access / Brute Force / Password Spraying where supported by the logic |
| Testing | Historical validation + simulation + true/false-positive matrix |
| Lifecycle | Enable → verify → monitor → tune → retest |
What makes this a detection?
Not the KQL alone.
The detection is the combination of hypothesis, telemetry, query, timing, thresholds, context, entities, alert behaviour, incident behaviour, testing and ongoing ownership.
What makes it trustworthy?
The analyst can explain why it fired, inspect the evidence, identify the entities, reproduce the logic and understand its limitations.
Trust comes from evidence and repeatability — not from a severity label.
Agent Foskett final exercise — build your own
You have a hunting query that finds suspicious PowerShell activity on endpoints. Build the production detection specification before touching the analytics-rule wizard.
- Write the detection hypothesis in one sentence.
- Name the required table and fields.
- Define what one query result represents.
- Choose frequency and lookback and explain why.
- Define KQL and rule-level thresholds.
- Choose entity mappings.
- Choose custom details and alert details.
- Map only evidence-supported ATT&CK techniques.
- Define alert and incident grouping.
- Create true-positive, false-positive and boundary tests.
- Run simulation before enablement.
- Define how the rule will be monitored and tuned after deployment.
Module 3 checklist
- Scheduled analytics rules
- Frequency and lookup periods
- Alert thresholds
- Entity mapping
- Custom details and enrichment
- Alert and incident grouping
- NRT and Microsoft security rules
- MITRE ATT&CK mapping
- Tuning and false positives
- Testing before enablement
- Hunting-to-detection workflow
- Troubleshooting failed detections
Agent Foskett takeaway
A query can find evidence.
A complete detection makes that evidence repeatable, explainable and actionable for the SOC.
Follow the evidence. Build the detection. Test the assumptions. Then trust the alert.
Related Agent Foskett learning
Continue learning
Build a Complete Microsoft Sentinel Detection
A production Microsoft Sentinel detection is more than a KQL query. Scheduled analytics rules combine a security hypothesis, telemetry, query logic, scheduling, thresholds, entity mapping, alert enrichment, MITRE ATT&CK mapping, event and incident behaviour, testing, tuning and ongoing monitoring.
Microsoft Sentinel Lesson 35
This Agent Foskett Microsoft Sentinel Academy lesson brings Module 3 together in one end-to-end detection engineering exercise, from initial hypothesis through production validation and lifecycle management.
