Two Alerts, Forty-Five Noise Events, and a Missed Lateral Move
It is 2 AM and your SIEM fires 47 alerts in three minutes. Forty-five are false positives. The other two are an active intrusion — one flagging suspicious PowerShell execution, the other catching abnormal SMB share access. Without MITRE ATT&CK mapping on your Sentinel detection rules, those two alerts sit in the same undifferentiated queue as the noise. Your analyst triages them in order, not by kill chain position. The attacker finishes lateral movement before anyone connects the dots.
That scenario played out almost exactly during an incident response engagement we handled for a financial services client last year. Their Sentinel instance had over 200 analytics rules active, but fewer than 30 were mapped to ATT&CK techniques. The SOC had no way to see that three separate alerts — credential access, execution, and lateral movement — were stages of the same intrusion. Mean time to detect was under four minutes. Mean time to understand was over three hours. MITRE ATT&CK Sentinel detection rules mapping would have collapsed that gap.
What ATT&CK Mapping Actually Does Inside Sentinel
Sentinel’s analytics rules can be tagged to specific ATT&CK tactics and techniques. When an alert fires, it carries that context forward into the incident. A PowerShell abuse alert tagged to T1059.001 tells the analyst this is an Execution technique. A failed authentication burst tagged to T1078 signals Credential Access via Valid Accounts. A file copy over admin shares tagged to T1021.002 maps to Lateral Movement.
This is not decoration. When Sentinel groups alerts into a single incident, the ATT&CK tags create a kill chain narrative automatically. Instead of three disconnected alerts, the analyst sees: credential theft attempted, execution achieved, lateral movement in progress. That changes the response from “investigate each alert” to “contain this host now.”
Built-In Mapping vs. Custom Rules
Many of Sentinel’s built-in analytics rules ship pre-mapped to ATT&CK tactics and techniques. Microsoft curates these based on real-world attack patterns, and they cover a decent baseline — Initial Access, Persistence, Privilege Escalation, Lateral Movement, Exfiltration, and more. The problem is that most organizations also run custom KQL rules, and those rules almost never carry ATT&CK tags.
Here is my position: every custom detection rule that lacks an ATT&CK mapping is a blind spot you chose to create. It might fire. It might catch something real. But it will not participate in incident correlation, coverage analysis, or kill chain visualization. It exists outside the framework your SOC uses to reason about attacks.
Writing Detection Rules with ATT&CK in Mind
When building custom analytics rules in Sentinel, the ATT&CK mapping is set in the rule definition itself. But the mapping is only useful if the underlying KQL logic actually detects what the technique describes. A few principles from detection engineering work we have done across client environments:
Clarity of logic comes first. The KQL query must articulate your detection intent in a way that another analyst can read, understand, and maintain six months later. If the query is unclear, the ATT&CK tag is a lie — nobody will trust the alert.
Match the data source to the technique. Sentinel rules pull from specific log tables. A rule detecting T1059.001 (PowerShell) needs to query SecurityEvent or DeviceProcessEvents, not firewall logs. Understanding how Azure AD, Microsoft Defender, and custom sources structure their data is prerequisite work. Get this wrong and your detection has coverage on paper but not in practice.
Track entities for incident enrichment. Rules should extract accounts, hosts, IPs, and URLs as mapped entities. This is what allows Sentinel to group related alerts into incidents and build investigation timelines. Without entity mapping, your ATT&CK-tagged alert is an island — correct in isolation but useless for correlation.
Set thresholds that reduce noise without hiding attacks. A rule that fires on every PowerShell execution is not detecting T1059.001. It is generating alert fatigue. Use logical thresholds and filters — parent process context, command-line length, encoded command flags — to separate administrative PowerShell from adversary PowerShell.
Example: Detecting Suspicious PowerShell with ATT&CK Context
Here is a simplified KQL pattern for a scheduled rule mapped to T1059.001:
SecurityEvent
| where EventID == 4688
| where NewProcessName endswith "powershell.exe"
| where CommandLine has_any ("-enc", "-encodedcommand", "downloadstring", "invoke-expression")
| where ParentProcessName !endswith "sccm.exe" // exclude known management tools
| extend AccountEntity = TargetUserName, HostEntity = Computer
| project TimeGenerated, AccountEntity, HostEntity, CommandLine, ParentProcessNameThe filters here are deliberate. We target encoded commands and download cradles — common in real intrusions — while excluding known management tooling. The entity extraction (AccountEntity, HostEntity) feeds Sentinel’s incident grouping. When this alert lands next to a T1078 credential alert on the same host, the analyst sees a two-stage attack, not two unrelated events.
Coverage Analysis: Finding Your Blind Spots
Sentinel provides a MITRE ATT&CK Workbook that visualizes your current rule coverage across the entire matrix. Every tactic — Initial Access through Exfiltration — is displayed with detection density. Green cells have active rules. Empty cells are blind spots.
We deployed this workbook for a mid-market retail client running Sentinel with about 150 active rules. The coverage visualization revealed that they had strong detection across Execution and Persistence but almost nothing for Defense Evasion or Collection. That gap meant an attacker who established persistence could disable logging or stage data for exfiltration without triggering a single alert. We built 12 new rules in two weeks to close the most critical gaps, prioritized entirely by what the coverage map showed.
This is where ATT&CK mapping pays for itself operationally. Without it, you are guessing at coverage. With it, you have a heat map of exactly where your detection is strong and where an attacker can operate undetected. Security managers get immediate visibility into which techniques have automated detection and which are blind spots — what the Sentinel documentation calls areas with “no detection coverage.”
Threat Intelligence and ATT&CK Enrichment
Threat intelligence platforms that feed into Sentinel can tag their Indicators of Compromise to ATT&CK TTPs. This creates a powerful pivot: start with a threat actor profile, identify their documented techniques, then check whether your Sentinel rules cover those techniques. If APT29 uses T1021.002 for lateral movement and your environment has no rule mapped to that technique, you have a specific, actionable gap to close.
Sentinel can also enrich incidents with MITRE-based threat actor references when the intelligence correlation is available. A series of actions resembling techniques used by a known threat group gets tagged in the incident record. For SOC analysts, this moves the investigation from “what happened” to “who does this look like and what do they do next” — which is exactly the kind of structured workflow that reduces mean time to respond.
Hunting Queries Organized by ATT&CK
Beyond scheduled analytics rules, Sentinel’s threat hunting library includes prebuilt KQL queries organized by ATT&CK techniques. On the hunting page, queries are separated into sets based on tactics: initial access, persistence, lateral movement, and so on. A visual timeline lets analysts filter by tactic and review results interactively.
This is where detection engineering and threat hunting investigations converge. A hunting query under T1021.002 might surface lateral movement via admin shares that your scheduled rule missed because it fell below the alert threshold. That finding then feeds back into rule tuning — lower the threshold, add the specific pattern, or create a new rule. The ATT&CK taxonomy keeps this feedback loop organized. Without it, hunting results are ad hoc discoveries that rarely make it into production detection.
The Caveat: ATT&CK Mapping Is Not Coverage
One thing I see teams get wrong repeatedly: they map a rule to a technique and assume they have coverage. They do not. A single rule mapped to T1059.001 does not mean you detect all PowerShell-based execution. It means you detect the specific pattern that rule queries for. An attacker using PowerShell differently — AMSI bypass, living-off-the-land through legitimate scripts, or PowerShell without powershell.exe — will walk right past it.
True coverage requires multiple rules per technique, tested against real attack simulations. This is where ATT&CK-integrated tabletop exercises become essential. Map your rules, then validate them with red team scenarios. The gap between “mapped” and “covered” is where breaches happen.
Making This Operational
If your Sentinel instance has custom rules without ATT&CK tags, start there. Audit every active rule and assign the correct tactic and technique. Then pull up the ATT&CK Workbook and look at what is missing. Prioritize new rules based on your threat model — not every technique matters equally for every environment.
For organizations that need help building this detection engineering practice, from initial rule mapping through coverage analysis and hunt query development, reach out to our team. We have built these frameworks for clients across financial services, retail, and manufacturing, and the pattern is consistent: structured ATT&CK mapping in Sentinel cuts mean time to understand an incident by 40-60%, because your analysts stop triaging alerts in isolation and start seeing attack chains.
The goal is not a green ATT&CK matrix. The goal is that when those two real alerts fire at 2 AM, your analyst knows within seconds that they are looking at credential access feeding lateral movement — and acts accordingly.
