Parag Mali - tag: microsoft-defender

Microsoft Defender for Identity: The Defensive AD Stack That Sees What BloodHound Maps

noreply@paragmali.com (Parag Mali) — Wed, 27 May 2026 00:00:00 GMT

**Microsoft Defender for Identity (MDI) is the cloud-backed, on-DC defensive sensor that watches for almost every offensive Active Directory primitive in the SpecterOps / Mimikatz / Certipy corpus** -- DCSync, DCShadow, Golden / Silver / Diamond ticket forgery, Kerberoasting, AS-REP roasting, NTLM relay, and AD CS abuse -- by parsing Kerberos, NTLM, LDAP, and DRSUAPI on the wire and running per-principal behavioural baselines in a multi-tenant cloud backend. The product began as the Israeli startup Aorato (acquired by Microsoft in November 2014), shipped on-prem as Microsoft ATA in 2015, moved to the cloud as Azure ATP in 2018, was renamed to MDI in 2020, folded into Microsoft Defender XDR at Ignite 2023, and reached its current MDE-integrated v3.x sensor in October 2025. The alert catalogue maps cleanly onto MITRE ATT&CK, and the residual blind spots are knowable: the Credential Guard wall, the Sapphire Ticket's cryptographic indistinguishability, the encrypted-channel DCSync class, the cross-forest under-instrumentation tail, and legitimate-principal compromise. The operator question in 2026 is not whether MDI detects the attack, but whether the sensor is deployed, the alert was triaged inside the batched-emission window, and the residuals are covered by KQL, Sigma rules, or out-of-band controls.

1. A Friday Afternoon at the Domain Controller

Friday, 14:33. A red-team contractor in conference room C runs Rubeus.exe asreproast on a corporate laptop she was issued an hour ago. A junior auditor on the fourth floor, working from a desk with read-only Active Directory access, runs bloodhound-python -c All for a routine quarterly review. A quiet service account on the SQL host in rack 14 runs mimikatz "lsadump::dcsync /domain:contoso.com /user:Administrator". The operator at the other end of that session is not on the payroll. Three different workstations. Three different intents. One domain controller on the receiving end of all three.

The Security Operations Center has not noticed any of them yet. The watcher on the domain controller, however, has. By 14:35 three named alerts are sitting in the Defender XDR queue, each tagged with a MITRE ATT&CK technique ID, each waiting for someone to triage. Suspected AS-REP Roasting attack (T1558.004) for the Rubeus invocation [@mslearn-mdi-alerts-xdr]. Security principal reconnaissance (LDAP) for the BloodHound enumeration [@mslearn-mdi-alerts-mdi-classic]. Suspected DCSync attack -- replication of directory services, External ID 2006, T1003.006, for the Mimikatz call [@mslearn-mdi-alerts-mdi-classic][@mitre-t1003-006]. The watcher is Microsoft Defender for Identity.SOC operators inside Microsoft customers describe this with a stock phrase: "the watcher was already on the DC." The phrase shows up in incident-response runbooks, vendor training decks, and the Microsoft Defender for Identity Tech Community archive. It captures what is, architecturally, a strange thing -- the defender's sensor is co-located with the attacker's target, not perched outside it.

A Windows Server hosting the Active Directory Domain Services role, responsible for processing Kerberos authentication, NTLM challenges, LDAP queries, and inter-DC directory replication (DRSUAPI) for a domain. Every named MDI runtime alert in this article fires on signal that originates on or transits a domain controller; the deployment model assumes one MDI sensor per DC, plus optional sensors on AD FS, AD CS, and Microsoft Entra Connect servers when those identity roles run on dedicated hosts.

Almost every offensive AD primitive a reader of the SpecterOps, Mimikatz, and Certipy corpus already knows has a runtime alert or a posture assessment shipped by Microsoft on that same DC. Almost is the load-bearing word. The alert fires only if three things are true: the sensor is deployed on the surface the attack touches, the audit subcategory the alert depends on is enabled, and the SOC opens the Defender XDR incident inside the batched-emission window the cloud backend uses to aggregate signal. This article is about all three conditions, the twelve-year arc that built the watcher, and the structural blind spots no future MDI release will close.

The watcher was not always on the domain controller. For the first decade of Active Directory, nothing on the DC saw what BloodHound today maps. To understand where the watcher came from -- and why its blind spots look the way they do -- we have to start with three founders in Herzliya and a Kerberos forgery presentation in Las Vegas.

2. Origins -- Aorato, the Israeli Startup That Became the Watcher

August 2014, Black Hat USA. Tal Be'ery and Michael Cherny take the stage with Alva Duckwall and Benjamin Delpy to present "Abusing Microsoft Kerberos: Sorry You Guys Don't Get It," a demonstration that a stolen krbtgt key lets an attacker mint Kerberos ticket-granting tickets that survive every password rotation in the standard remediation playbook [@blackhat-us14-briefings]. The audience is Active Directory operators who thought their password-reset runbook covered them. By the end of the talk it does not. The startup behind the research is Aorato, three years old, headquartered in Herzliya, Israel. Three months later, Microsoft buys it.

The credential a Kerberos client receives from the Key Distribution Center (the KDC, which on a Windows network runs on every DC) after successful pre-authentication. The TGT is encrypted with the KDC's own long-term key -- on Active Directory, the password hash of the `krbtgt` account. Possession of the `krbtgt` hash therefore lets an attacker forge a valid TGT for any principal in the domain, since the KDC has no other way to distinguish a forged ticket from a real one. This forged-ticket class is what MITRE catalogues as T1558.001 Golden Ticket [@mitre-t1558-001].

The Aorato deal closed on November 13, 2014, announced on the Microsoft Official Blog by Takeshi Numoto, then Corporate Vice President of Cloud and Enterprise Marketing [@msblog-aorato]. The post named the central technology Microsoft was acquiring: Aorato's Organizational Security Graph, described as "a living, continuously-updated view of all of the people and machines accessing an organization's Windows Server Active Directory." Pre-acquisition Microsoft had Azure AD on the cloud side and per-DC event log auditing on the on-prem side, but no first-party behavioural-analytics product over Active Directory. Aorato's pre-acquisition product, the Directory Services Application Firewall, did exactly that -- it parsed Kerberos, NTLM, LDAP, and DRSUAPI on the wire and ran per-principal behavioural baselines against the parsed protocol stream. Microsoft wanted that capability inside Windows Server, and inside Office 365.Aorato's three founders, per the Globes coverage of the acquisition in November 2014, were Idan Plotnik (CEO), Michael Dolinsky (VP R&D), and Ohad Plotnik (VP professional services). Tal Be'ery was VP of Research. A popular reading of the deal names "the Plotnik brothers and Tal Be'ery" as the co-founder trio, which compresses out Dolinsky's role -- the contemporaneous record names four people, not three [@globes-aorato-2014].

The product lineage that follows is twelve years long and runs through five names. Microsoft Advanced Threat Analytics (ATA) was announced as generally available on August 27, 2015 (build 1.4.2457, dated August 31, 2015) -- the on-prem productisation of Aorato's wire-side parser, packaged as a SPAN-mirror appliance ("ATA Gateway") plus an on-prem analytics server ("ATA Center") with its own MongoDB-style document store [@mstc-ata-ga][@atadocs-versions]. Azure ATP went GA on March 1, 2018 -- the cloud-side rewrite that kept the on-DC sensor but moved the analytics engine to a multi-tenant cloud backend [@mstc-azureatp-ga][@mstc-azureatp-intro]. Microsoft Defender for Identity was the September 22, 2020 rename announced at Ignite 2020, part of Microsoft's broader brand consolidation that also rebranded Office 365 ATP to Microsoft Defender for Office 365 and Microsoft Defender ATP to Microsoft Defender for Endpoint [@mssecblog-unified-xdr][@itpro-defender-rebrand][@infusedinnov-names]. The November 2023 Ignite keynote consolidated Microsoft 365 Defender into Microsoft Defender XDR [@virtreview-ignite2023][@handsontek-defender-rebrand]. In October 2025 the v3.x sensor GA folded MDI's on-DC sensor into the Microsoft Defender for Endpoint agent that organisations were already running on every server [@mslearn-mdi-whats-new][@modernsec-v3x][@jeffreyappel-v2v3]. The May 2026 release notes extended the v3.x sensor to cover AD FS, AD CS, and Microsoft Entra Connect identity roles directly when those roles run on a domain controller, and raised the per-workspace sensor cap from 350 to 1,000 [@mslearn-mdi-whats-new].

gantt title Microsoft Defender for Identity lineage, 2012-2026 dateFormat YYYY-MM-DD axisFormat %Y section Aorato Aorato startup (DSAF product) :a1, 2012-01-01, 2014-11-13 section Microsoft ATA ATA initial release SPAN-mirror Gateway :a2, 2015-08-27, 2016-05-01 ATA 1.6-1.9 Lightweight Gateway :a3, 2016-05-01, 2018-03-01 ATA Extended Support window :a4, 2018-03-01, 2026-01-31 section Cloud rewrite Azure ATP GA :a5, 2018-03-01, 2020-09-22 Microsoft Defender for Identity name :a6, 2020-09-22, 2023-11-15 section Defender XDR era MDI inside Defender XDR (v2.x) :a7, 2023-11-15, 2025-10-01 MDI v3.x MDE-integrated sensor :a8, 2025-10-01, 2026-05-27

Aorato's pitch in 2014 was that the Windows Security event log -- the thing every SIEM in the world was ingesting -- could not see the attacks an Active Directory operator most needed to catch. To believe that pitch you have to know exactly what the event log misses.

3. Why the Event Log Could Not See Golden Tickets

Present a Golden Ticket to a domain controller, and the LSA writes a successful event 4769 -- a Kerberos service ticket request. Present a legitimate ticket from the same principal, and the LSA writes a successful event 4769. Nothing in the event log's schema, anywhere in any field, distinguishes the two. The ticket is forged with the real krbtgt key, so the KDC's signature checks pass. The event log records that an authentication happened, not whether the ticket presented was genuine. This is the structural ceiling the SIEM industry could not work around for the first decade of its existence, and it is the gap Aorato was built to close [@mitre-t1558-001][@semperis-golden-ticket].

The bare-event-log model has three structural failure modes, each of which drove a generation of detection engineering. Forged-ticket invisibility is the first: the LSA logs that an auth happened, but every byte in the 4769 event matches the legitimate case. Per-DC silo is the second: a Kerberos auth against one DC and a follow-up auth against another DC five seconds later sit in two different Security.evtx files, on two different machines, with no aggregation layer to ask "did the same principal hit ten DCs in five minutes?" Manual-review throughput collapse is the third: a medium-sized forest emits thousands of 4624, 4768, 4769 events per minute per DC, and the human analyst hand-walking them never catches up.

DCSync makes the first two failure modes vivid. Sean Metcalf's September 2015 ADSecurity writeup walks through running lsadump::dcsync /domain:contoso.com /user:Administrator from a workstation: the DC handles the DRSUAPI replication request, the LSA emits a 4662 event for the directory-service-object access, and the attacker walks away with the password hash [@adsec-dcsync].Metcalf's companion DerbyCon V talk, Red vs. Blue: Modern Active Directory Attacks & Defense (September 2015), is the canonical operator-grade introduction to the same material [@adsec-dump-ad]. The 4662 event is structurally indistinguishable from a legitimate replication request between two DCs. A SIEM rule that flagged 4662 events whose source IP was not a DC could catch it -- but only if the analyst maintained the IP allowlist (a single Microsoft Entra Connect server in the wrong subnet broke the rule), and only if 4662 was enabled at all (it was high-volume, and many SOCs disabled it to stay under the SIEM's GB/day licence).

Key idea: The SIEM was not failing at Active Directory detection because the rules were wrong. It was failing because the event log -- the data source every SIEM relied on -- could not see what the SIEM needed it to see. Better rules over the same event log would not have closed the gap. Aorato's contribution was to find a different data source: the wire itself.

Aorato's three primitives, none of which the SIEM-plus-event-log model had, were: per-principal behavioural baselines so that a long-tail anomaly stood out without anybody writing a rule for it; on-DC network capture so that the ticket structure, the DRSUAPI opnum, and the LDAP search filter were available to detection logic; and a graph over the directory so that the path from compromised workstation to crown-jewel asset could be computed rather than inferred. ATA shipped the first two in 2015. The graph took longer.

4. Early Approaches -- ATA 1.x and the Generations That Tried Before

By the time Aorato shipped its first product, four prior generations of Active Directory detection had already tried and stalled. Each one could see something the previous generation could not. Each one had a structural ceiling an attacker primitive eventually pushed through. The seven generations that follow are the real spine of the article.

flowchart LR G1["Gen 1: bare per-DC
event log audit"] --> G2["Gen 2: SIEM-centralised
events with static rules"] G2 --> G3["Gen 3: first-generation UEBA
over SIEM events"] G3 --> G4["Gen 4: Aorato DSAF and
ATA 1.4-1.5 (SPAN mirror)"] G4 --> G5["Gen 5: ATA 1.6-1.9
(Lightweight Gateway + LMP)"] G5 --> G6["Gen 6: Azure ATP, MDI v1.x-v2.x
(cloud analytics)"] G6 --> G7["Gen 7: MDI v3.x
(MDE-integrated + Identity Explorer)"]

Generation 1 -- bare per-DC event log auditing (1999-2008) was already covered above. It was the only model that existed for the first decade of Active Directory, and its structural ceilings became Aorato's pitch deck.

Generation 2 -- SIEM-centralised event log ingestion with static correlation rules (2005-2014) is the era of ArcSight, Splunk, QRadar, and LogRhythm. Windows Event Forwarder agents on every DC streamed Security event log entries into a central index, and SOC operators wrote rule-based correlation searches in the vendor's query language. The model gave the SOC cross-DC correlation, a query language, and an audit trail that satisfied PCI-DSS Requirement 10. It did not give the SOC anything new about the data the LSA emitted. Mimikatz's lsadump::dcsync was committed to the public Mimikatz repository in March 2015 [@mimikatz-github][@adsec-dcsync]. Sean Metcalf's longer ADSecurity writeup of the technique followed in September 2015. At commit time, every SIEM in production was correlating DC event logs and not one was emitting a DCSync alert, because the 4662 event was structurally identical to a legitimate DC-to-DC replication.

Generation 3 -- first-generation UEBA on SIEM event data (2013-2017) was Securonix, Exabeam, and Splunk UBA. Per-principal behavioural baselines layered on top of the SIEM event index could catch novel TTPs without prior signatures -- a Kerberoasting variant whose SPN list had never been seen before could still trip "this account is requesting an unusual number of service tickets compared to its baseline." UEBA also closed Generation 2's per-principal context gap. It did not, however, see ticket structure: a Golden Ticket replayed against ten DCs produces ten successful auths that are behaviourally indistinguishable from the legitimate Domain Admin's pattern unless the attacker's source IP or geographic distribution breaks the baseline. This is the legitimate-principal-compromise non-detection class that survives every defensive generation into 2026.

Generation 4 -- on-wire protocol analytics via off-DC SPAN-mirror Gateway is where Aorato's product, and then Microsoft ATA 1.4 and 1.5, lived. A switch SPAN port mirrored DC traffic to a dedicated ATA Gateway appliance, which ran libpcap-equivalent capture and parsed Kerberos AS-REQ / TGS-REQ / AP-REQ, NTLM challenges, LDAP searches, and DRSUAPI replication calls. Parsed events streamed to the on-prem ATA Center, which ran detection logic and surfaced alerts in a web console [@mstc-ata-ga]. The wire-side parse closed Generation 1-3's biggest blind spot: ticket structure was finally visible. The SPAN-port operational tax killed the architecture in nine months. Many enterprises could not provision a SPAN mirror. Virtualised DCs on shared hypervisors had no equivalent of a physical SPAN. And the security review of "all DC traffic now mirrors to this appliance" was non-trivial.

Generation 5 -- ATA 1.6 Lightweight Gateway through ATA 1.9 (May 2016 to March 2020) moved the Gateway in-process onto the DC itself. ATA 1.6 (May 2016) introduced the Lightweight Gateway with dynamic resource management that capped the sensor's CPU and memory footprint and let the sensor consume events locally rather than via mirrored network traffic [@mslearn-ata-1-6]. ATA 1.7 (August 31, 2016) added Role-Based Access Control for the ATA Console, Windows Server Core support, and detection of reconnaissance through directory-services enumeration [@mssupport-ata-1-7][@atadocs-versions]. ATA 1.8 (June 30, 2017; announced July 26, 2017) shipped behavioural-brute-force detection, a Golden Ticket lifetime detector, and the abnormal-modification-of-sensitive-groups alert [@mslearn-ata-1-8][@mstc-ata-1-8][@ataversions-1-8-availability]. ATA 1.9 (March 21, 2018) shipped both the entity-profile lateral-movement-aware view and the Lateral movement paths to sensitive accounts report [@mslearn-ata-1-9][@atadocs-versions][@atadocs-lmp-usecase].A widespread reading of the ATA timeline anchors LMP to ATA 1.7 in late 2017. The primary record contradicts this on both date and feature: ATA 1.7 shipped on August 31, 2016 per the Microsoft Support KB and the ATA-versions table, and the 1.7 release notes do not mention Lateral Movement Paths. Neither do the 1.8 release notes -- LMP first appears in ATA 1.9 (March 21, 2018), which introduced both the entity-profile lateral-movement view and the full Lateral movement paths to sensitive accounts report in the same release [@mssupport-ata-1-7][@atadocs-versions][@mslearn-ata-1-8][@mslearn-ata-1-9].

Note: A popular framing of the LMP timeline says "Microsoft adopted BloodHound-style graph attack paths in 2022." The primary sources contradict this. Graph-anchored attack-path evaluation in Microsoft's defensive stack originates in ATA 1.9 (March 2018), not in any 2022 adoption event. What did happen in 2022 was the start of the deprecation arc for the SAM-R-based discovery the LMP graph depended on, which culminated in Message Center notice MC1073068 in May 2025 when Microsoft disabled SAM-R-based local-administrators collection across MDI tenants [@handsontek-mc1073068]. The 2022 date that lingers in operator memory is the deprecation anchor, not the adoption anchor.

An attack chain through Active Directory in which a non-sensitive account whose credentials are exposed on one workstation can be used to authenticate to a second workstation where a sensitive account's credentials are cached, which in turn can be used to reach a third workstation, and so on until a Domain Admin or comparable target is reached. ATA 1.9's Lateral Movement Paths report was the first graph-anchored defensive surface that computed the chain in advance; the report was populated by SAM-R queries that enumerated each host's local-administrators group. Microsoft disabled the SAM-R-based collection in May 2025 (MC1073068), and the post-LMP graph layer migrated to the Defender XDR hunting graph plus the April 2026 Identity Explorer preview.

The limitation that drove Generation 5 into Generation 6 was the on-prem ATA Center's release cadence. Benjamin Delpy and Vincent Le Toux disclosed DCShadow at BlueHat IL 2018 in January 2018 -- the technique of registering a rogue domain controller via nTDSDSA object creation plus SPN registration, then pushing arbitrary updates into AD via legitimate DRSUAPI replication that the event log records as ordinary inter-DC traffic [@dcshadow-com][@mitre-t1207]. ATA 1.9 shipped two months later, in March 2018, with no DCShadow detection. Azure ATP -- the cloud-side rewrite, also GA in March 2018 -- shipped paired alerts External ID 2028 (Suspected DCShadow attack -- domain controller promotion) and External ID 2029 (Suspected DCShadow attack -- domain controller replication request) five months later, in July 2018 [@mslearn-mdi-alerts-mdi-classic][@mslearn-mdi-whats-new-archive]. The on-prem release cadence could not have closed that five-month gap. The cloud rewrite was the structural answer.

5. The Breakthrough -- Azure ATP and the Inverted Data Path

If the wire was the right data layer, the cloud was the right place to run the analytics. That is the architectural decision Azure ATP committed to in March 2018, and it is what distinguishes the Microsoft defensive product from every prior generation. The on-DC sensor stayed on the DC. The analytics engine moved.

Four architectural shifts followed. First, the on-DC sensor became a thin parser. Sensors no longer hosted detection logic; they captured the Kerberos / NTLM / LDAP / DRSUAPI traffic, parsed it into a stream of structured events, and shipped the stream upstream. Second, the data path inverted. Generation 4 sent unparsed packets from the wire to the off-DC Gateway, which parsed them and stored them on-prem; Azure ATP sent parsed events from the on-DC sensor upstream to a multi-tenant cloud backend that ran detection logic and wrote alerts back into a tenant-specific workspace. Third, per-principal behavioural baselines accumulated centrally rather than per-DC, so a baseline survived DC reboots, sensor restarts, and migrations across data centres. Fourth, identity signal joined endpoint and email signal in the same incident queue once Azure ATP folded into Microsoft 365 Defender -- the cross-product correlation that no on-prem product had ever offered [@mstc-azureatp-ga][@mstc-azureatp-intro][@mslearn-xdr-overview].

Then came the brand-and-architecture history every operator has to know to read a 2026 runbook. The September 22, 2020 rename from Azure Advanced Threat Protection to Microsoft Defender for Identity was a brand consolidation, not an architecture change -- the same sensor, the same alerts, the same workspace [@mssecblog-unified-xdr]. The legacy portal.atp.azure.com standalone portal was retired on June 30, 2023 via Message Center notice MC567494, with all requests automatically redirected to security.microsoft.com [@handsontek-mc567494][@mslearn-mdi-portal]. The November 15, 2023 Ignite keynote renamed Microsoft 365 Defender to Microsoft Defender XDR (Message Center MC696570) [@handsontek-defender-rebrand][@virtreview-ignite2023]. Again a brand change, again not an architecture change: the sensors stayed on the DC, the analytics stayed in the cloud, and the KQL schema -- IdentityLogonEvents, IdentityQueryEvents, IdentityDirectoryEvents -- stayed the same [@mslearn-xdr-identitylogon][@mslearn-xdr-identityquery][@mslearn-xdr-identitydirectory].The legacy portal.atp.azure.com URL is worth remembering because runbooks and SOAR rules from 2018 to 2023 frequently hard-coded it. Any rule that referenced the old portal needs an update; the redirect handles browser traffic but not API calls.

What the sensor actually feeds into the cloud backend, in 2026, is four data-input layers, ordered roughly by evidence strength. First, the Windows Security event log -- the audit subcategories that the MDI event-collection page lists as required, including Audit Credential Validation, Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Directory Service Access, and Audit Computer Account Management among others [@mslearn-mdi-event-collection]. These are public, documented, and easy to verify with auditpol /get /category:*. Second, on-DC network capture of Kerberos, NTLM, LDAP, and DRSUAPI -- well-documented because the sensor's network requirements are part of the public deployment guide. Third, Event Tracing for Windows providers that the sensor subscribes to in order to get signal the event log does not surface. Fourth, AD CS audit-log subscriptions added with the AD CS sensor release in August 2023 [@mstc-adcs-sensor][@dirteam-sander-aug2023].

Microsoft has never published the canonical list of Event Tracing for Windows providers that the MDI sensor subscribes to. Any specific list of providers a reader encounters traces back to community reverse-engineering: Synacktiv's *A primer on Microsoft Defender for Identity* by Guillaume Andre and Mickael Benassouli (November 2022) is the canonical operator-research primary [@synacktiv-primer-mdi][@synacktiv-primer-mdi-archive]. The methodological precedent is Olaf Hartong's *Microsoft Defender for Endpoint Internals* series, specifically the 0x02 entry on audit settings and telemetry, which documents the binary-side enumeration approach: run Matt Graeber's Get-TraceLoggingMetadata script against the sensor executable to enumerate the providers it registers, then use Sealighter to trace those providers to a file for further analysis [@falconforce-mde-0x02][@gist-tracelogging-metadata][@github-sealighter]. Hartong's 0x02 article reports "roughly 111 public and MDE-exclusive providers used" by MsSense.exe -- the MDI sensor binary is amenable to the same technique, and the provider mix differs (MDI subscribes heavily to LDAP, Kerberos, DRSUAPI, and SAM-R-class providers; MDE subscribes heavily to process, file, network, and image-load providers) but the methodology is shared [@falconforce-mde-0x03][@github-olafhartong]. Read any community-published MDI provider list as a snapshot of what the community has reverse-engineered, not as Microsoft-published ground truth. The breakthrough was not better detection algorithms. The breakthrough was moving the analytics off the DC entirely, so the per-principal baselines could accumulate centrally and the detection set could ship on a cloud cadence instead of an on-prem one. That decision is why MDI shipped DCShadow detection within five months of disclosure -- a cadence the on-prem product could not have matched.

That is the move that turned a wire-side parse into a sustained detection program. The proof is the DCShadow timeline: five months from disclosure to detection, on a cadence the on-prem product could not have matched. Now we can ask the question every reader of the offensive-AD corpus actually wants answered. What does the watcher catch in 2026?

6. MDI in 2026 -- Sensors, Alerts, KQL, and the Graph in Transition

This is the article's bookmarking section. Four parts: what is on the DC, what alerts fire, what KQL the operator writes when the alerts miss, and where the graph layer that began as ATA 1.9's Lateral Movement Paths report actually lives in 2026.

6.1 Sensor topology in 2026

What is on a Windows Server 2022 (or 2025) domain controller running MDI in May 2026? Two sensor families, two target-server matrices, and a workspace cap.

The v2.x sensor is the legacy standalone agent: supported on Windows Server 2016 and earlier domain controllers, and on AD FS, AD CS issuing certificate authorities, and Microsoft Entra Connect servers that are not themselves domain controllers, per the v2.x prerequisites page [@mslearn-mdi-prereq-sensor-v2]. v2.x carries its own installer, its own update cadence, and its own packet capture stack (NPCap). It also requires a Directory Service Account (DSA) -- a gMSA configured during install whose forest-wide read rights let the sensor enumerate AD objects.

A group Managed Service Account configured during MDI v2.x sensor installation, granted forest-wide read permissions on Active Directory objects so the sensor can resolve principal identities, enumerate group memberships, and read schema attributes that the wire-side parse refers to by SID. The v3.x sensor replaces the DSA pattern with LocalSystem impersonation -- the sensor impersonates the local-system account of the domain controller it runs on, which has equivalent on-DC read rights without needing a separate gMSA per tenant [@mslearn-mdi-deploy-sensor-v3][@mslearn-mdi-action-accounts].

The v3.x sensor is the current path. It requires Windows Server 2019 or later with the March 2026 (or later) cumulative update installed, the Defender for Endpoint agent already deployed and onboarded, and -- critically -- there is no separate MDI installer at all. The MDI sensor capability ships as an extension of the MDE SENSE service. Self-imposed resource caps: CPU at most 30% of the host DC's CPU, memory at most 1.5 GB, with explicit Hyper-V Dynamic Memory and VMware reservation guidance that ensures the cap is honoured under contention [@mslearn-mdi-deploy-sensor-v3]. v3.x uses LocalSystem impersonation for AD reads rather than a gMSA-based DSA. The May 2026 release notes added direct v3.x support for AD FS, AD CS, and Microsoft Entra Connect identity roles when those roles run on a domain controller (which is the recommended deployment pattern for most mid-sized tenants) [@mslearn-mdi-whats-new].The 30% CPU cap is honoured by the MDE SENSE service's scheduling, but Hyper-V Dynamic Memory and VMware ballooning can break the assumption -- if the hypervisor reclaims memory under contention the sensor cannot get its 1.5 GB and the local capture buffer drops events. Microsoft's deployment guide recommends a static memory reservation on virtualised DCs for that reason.

The four target server roles are domain controllers (every DC, including RODCs), AD FS federation servers (not Web Application Proxies), AD CS online issuing certificate authorities (not offline root CAs), and Microsoft Entra Connect servers (both active and staging). The May 2026 release notes also raised the per-workspace capacity ceiling from 350 sensors to 1,000 sensors per workspace [@mslearn-mdi-whats-new].

flowchart TD DC1["Domain Controller
(WS2019+, v3.x sensor
inside MDE SENSE)"] DC2["Domain Controller
(WS2016, v2.x sensor)"] ADFS["AD FS server
(v2.x sensor, non-DC)"] ADCS["AD CS issuing CA
(v2.x or v3.x sensor)"] EC["Entra Connect server
(v2.x sensor)"] CLOUD["MDI cloud backend
(multi-tenant analytics,
per-principal baselines)"] XDR["Microsoft Defender XDR
(security.microsoft.com)
Identity tables + alerts"] DC1 --> CLOUD DC2 --> CLOUD ADFS --> CLOUD ADCS --> CLOUD EC --> CLOUD CLOUD --> XDR

The deployment matrix below is the operator-grade reference -- which role gets which sensor, which audit subcategories the sensor depends on, and what posture data the role unlocks.

Server role	Sensor version	Required audit subcategories	Posture coverage unlocked
Domain controller (WS 2019+)	v3.x (preferred)	Credential Validation; Kerberos AS; Kerberos TGS; Logon; DS Access; Computer Account Mgmt	Full Identity Security Posture (entity hygiene, dormant accounts, weak crypto)
Domain controller (WS 2016)	v2.x	Same as above	Same as above, minus v3.x-only enhancements
AD FS federation server	v2.x (or v3.x if also a DC)	AD FS audit logs (Application + Security)	Hybrid auth signal (Entra ID + on-prem)
AD CS issuing CA	v2.x (or v3.x if also a DC)	AD CS audit logs (certificate request and template events)	Nine ESC posture assessments (ESC1-Preview, ESC2, ESC3, ESC4, ESC6-Preview, ESC7, ESC8, ESC11, ESC15) [@mslearn-mdi-certificates-posture]
Entra Connect server	v2.x (or v3.x if also a DC)	Sync engine event log	Sync-engine attribute-flow signal

Note: For new DC deployments on Windows Server 2019 or later, use v3.x: no separate installer, no gMSA, no NPCap, and the sensor ships its updates with the MDE agent. For AD FS, AD CS, or Entra Connect roles that run on dedicated Windows Server 2016 hosts, v2.x is the supported path until those hosts are upgraded. Mixed environments are normal during the migration window; the cloud backend handles both versions without operator intervention [@modernsec-v3x][@jeffreyappel-v2v3]. One known limitation as of May 2026: Windows Server 2025 domain controllers that currently run a v2.x sensor cannot be migrated to v3.x; Microsoft's What's New page is explicit that "migration of domain controllers with Windows Server 2025 from sensor v2.x to sensor v3.x is not supported" and the operator should continue on v2.x on those hosts until migration support ships [@mslearn-mdi-whats-new].

Sensor topology determines coverage. Coverage determines which alerts can fire.

6.2 The alert taxonomy mapped to MITRE ATT&CK

Every offensive Active Directory primitive a reader of the SpecterOps, Mimikatz, and Certipy corpus knows has a row in MDI's alert catalogue. The catalogue is the article's bookmarkable artifact, and the table below is the load-bearing data-density object. Four MITRE-aligned categories, the named alert for each primitive, and the ATT&CK technique ID the alert maps to.

Category	MDI alert (External ID / detector)	MITRE ATT&CK technique
Reconnaissance	Account enumeration reconnaissance (LDAP) -- External ID 2437	T1087 Account Discovery
Reconnaissance	Network-mapping reconnaissance (DNS)	T1018 Remote System Discovery
Reconnaissance	Security principal reconnaissance (LDAP)	T1069 Permission Groups Discovery
Reconnaissance	User and IP address reconnaissance (SMB)	T1018
Persistence and privilege escalation	Honeytoken activity (authentication / attribute / group)	T1098 Account Manipulation
Persistence and privilege escalation	Suspected Skeleton Key attack	T1556 (Modify Authentication Process)
Persistence and privilege escalation	Suspected Golden Ticket usage (encryption downgrade)	T1558.001 Golden Ticket [@mitre-t1558-001]
Persistence and privilege escalation	Suspected Golden Ticket usage (forged authorization data)	T1558.001
Persistence and privilege escalation	Suspected DCShadow attack (DC promotion) -- External ID 2028	T1207 Rogue Domain Controller [@mitre-t1207]
Persistence and privilege escalation	Suspected DCShadow attack (DC replication request) -- External ID 2029	T1207
Persistence and privilege escalation	Suspicious additions to sensitive groups	T1098 Account Manipulation
Credential access	Suspected DCSync attack (replication of directory services) -- External ID 2006	T1003.006 DCSync [@mitre-t1003-006]
Credential access	Suspected Brute Force attack (Kerberos, NTLM)	T1110 Brute Force
Credential access	Suspected AS-REP Roasting attack	T1558.004 AS-REP Roasting [@mitre-t1558-004]
Credential access	Suspected Kerberos SPN exposure / Kerberoasting	T1558.003 Kerberoasting [@mitre-t1558-003]
Credential access	Suspected over-pass-the-hash attack	T1550.002 Pass the Hash
Lateral movement	Suspected identity theft (pass-the-hash)	T1550.002
Lateral movement	Suspected identity theft (pass-the-ticket)	T1550.003 Pass the Ticket
Lateral movement	Remote code execution attempt	T1021 Remote Services
Lateral movement	Suspected NTLM relay attack (the ESC8 class)	T1187 Forced Authentication
Lateral movement	Suspected NTLM authentication tampering	T1557.001 LLMNR / NBT-NS / Man-in-the-Middle

Both alert documentation surfaces -- the classic-format alert reference and the XDR-format alert reference -- are the canonical primaries for this catalogue [@mslearn-mdi-alerts-mdi-classic][@mslearn-mdi-alerts-xdr]. Reading either page in sequence is the single most useful afternoon a SOC operator new to MDI can spend.The numeric External IDs (2006 for DCSync, 2028 and 2029 for DCShadow, 2437 for LDAP account enumeration, and so on) are a Microsoft-internal stability anchor that survives alert-name renames over time. Microsoft has renamed alerts -- "Suspected DCSync attack" was named differently in early Azure ATP -- but the External IDs do not change. Production SOAR rules should match on the External ID, not the alert name string.

An offensive primitive in which a principal that has been granted the *Replicating Directory Changes* and *Replicating Directory Changes All* extended rights uses the DRSUAPI replication interface (specifically `IDL_DRSGetNCChanges`) to request a full or partial replication of directory contents from a domain controller -- typically targeting the `unicodePwd` attribute on sensitive accounts like `krbtgt` and `Administrator`. The technique requires no code execution on the DC, no `Ntds.dit` copy, and no presence on a domain-joined machine other than network connectivity to a DC. Mimikatz's `lsadump::dcsync` command, written by Benjamin Delpy and Vincent Le Toux, is the canonical implementation; MITRE catalogues the technique as T1003.006 [@mitre-t1003-006][@adsec-dcsync]. A specific adversary behaviour catalogued in the MITRE ATT&CK framework, identified by a stable ID (for example T1003.006 for DCSync, T1558.001 for Golden Ticket, T1207 for Rogue Domain Controller). MITRE updates the framework periodically; the IDs themselves do not change, which is why detection-engineering tooling -- including MDI's per-alert MITRE mapping -- anchors to the IDs rather than the human-readable names.

Concrete mechanism, for one named alert. Suspected DCSync attack -- replication of directory services, External ID 2006, fires on the structural pattern that an IDL_DRSGetNCChanges request reached a domain controller from a source that is not itself a domain controller. The mechanism is the one place where MDI's wire-side capture pays for itself most visibly -- the 4662 event the LSA emits records the directory-service-object access but does not identify the source as not-a-DC; only the wire view sees the calling host's IP and resolves it against the directory's serverReference set.

sequenceDiagram autonumber participant Attacker as Attacker workstation (Mimikatz) participant DC as Domain Controller participant MDI as MDI v3.x sensor (on DC) participant Cloud as MDI cloud backend participant XDR as Defender XDR portal Attacker->>DC: IDL_DRSGetNCChanges (DRSUAPI replication request) DC->>DC: LSA writes event 4662 (DS object access) DC-->>Attacker: Replication response (unicodePwd, supplementalCredentials) MDI->>MDI: Wire parse: caller IP not in serverReference set MDI->>Cloud: Stream parsed event (caller, target object, attributes) Cloud->>Cloud: Correlate against known-DC IPs, fire detector Cloud->>XDR: Write alert External ID 2006 (T1003.006) XDR->>XDR: Surface in unified incident queue

The alert taxonomy makes the bookmarkable promise the rest of the article rests on. The trigger logic that fires each row, however, depends on signal the sensor can only acquire on the wire or in the event log -- and when the trigger logic misses, the operator's last-mile coverage is KQL.

6.3 The advanced-hunting schema and a worked KQL example

When the alert template misses, the hunter writes Kusto Query Language. Defender XDR exposes three identity-specific tables that the MDI sensor populates -- IdentityLogonEvents for authentication activity captured against on-prem AD, IdentityQueryEvents for queries performed against AD objects, and IdentityDirectoryEvents for events involving an on-prem domain controller including password changes, expirations, UPN changes, scheduled tasks, and PowerShell activity [@mslearn-xdr-identitylogon][@mslearn-xdr-identityquery][@mslearn-xdr-identitydirectory]. Cross-product context is available from the unified AlertInfo, AlertEvidence, and DeviceLogonEvents tables.

The worked example below is the structural DCSync detector that catches the encrypted-channel case the alert can miss. The runner in this environment cannot execute KQL directly, so the block is annotated rather than runnable -- a non-runnable KQL detector is stronger pedagogy here than a hand-rolled Python simulation, because the query as written is exactly what an operator would paste into the Defender XDR advanced-hunting console against the actual IdentityDirectoryEvents table.

// Structural DCSync detector -- DRSUAPI from non-DC IPs
// Run against the Defender XDR advanced-hunting IdentityDirectoryEvents table.
IdentityDirectoryEvents
| where Timestamp > ago(24h)                                  // tune window per triage cadence
| where ActionType == "DRSReplicate"                          // the DRSUAPI replication call
| extend SourceIP = tostring(parse_json(AdditionalFields).SourceIPAddress)
| where SourceIP !in ("10.0.1.10", "10.0.1.11", "10.0.1.12")  // tenant DC IPs go here
| where AccountName !startswith "MSOL_"                       // Entra Connect Cloud Sync FP class
| where AccountName !in ("ADConnectSync")                     // Entra Connect on-prem FP class
| project Timestamp, AccountName, SourceIP, TargetDeviceName, AdditionalFields
| order by Timestamp desc

The output rows that survive the filters are the operator's investigation queue: DRSUAPI replication requests against a DC from a source that is not itself a DC, and not a recognised hybrid-identity sync principal. The two cleanup principals -- MSOL_* (the Microsoft Entra Connect Cloud Sync service account, with a stable MSOL_ prefix and an 8-character random suffix) and ADConnectSync (the on-prem Entra Connect service account) -- are the two most common false positives every MDI tenant sees. Adding them to the !startswith and !in clauses cuts the FP rate by an order of magnitude in most environments. The third FP class that operators tune for is legitimate vulnerability scanners triggering the LDAP / SMB reconnaissance alerts -- the scanner's authenticated enumeration looks behaviourally identical to a SharpHound collector unless the scanner's source IP is in an allowlist.

flowchart LR A["IdentityDirectoryEvents
(DRSReplicate)"] --> B["Filter: source IP
not in known_dc_ips"] B --> C["Filter: account
not in sync allowlist"] C --> D["Suspect rows
(operator triage)"]

Beyond the three identity tables there is one more surface worth naming. The April 2026 Identity Explorer Preview in the Defender XDR Identity page builds on the Microsoft Sentinel data lake -- Microsoft's 2026 cross-product cold-storage and analytics layer with up to 12 years of retention in Parquet format [@mslearn-sentinel-datalake][@mslearn-mdi-whats-new]. Identity Explorer uses the Defender XDR hunting graph to visualise identity attack paths as interactive graphs with predefined scenarios for lateral movement, privilege escalation, and credential-access risk [@mslearn-xdr-hunting-graph][@mslearn-xdr-investigate-users].

The query language is the operator's last-mile coverage layer. Everything in section 6 so far is what MDI gives you. KQL is what you do when MDI does not.

6.4 The graph layer in transition

The graph that began as ATA 1.9's Lateral Movement Paths report no longer exists in the form most operators remember. The history is a clean three-step arc and a transition still in progress.

ATA 1.9 (March 2018) shipped the Lateral movement paths to sensitive accounts report, built on SAM-R-based local-administrator discovery: the sensor remotely enumerated each member host's local-administrators group and computed the chain of "who can become whom" through cached credentials [@mslearn-ata-1-9][@atadocs-lmp-usecase]. That report carried through Azure ATP, through the Microsoft Defender for Identity rename, and through the Microsoft Defender XDR rebrand essentially unchanged for seven years.

In May 2025, Microsoft disabled the SAM-R-based discovery via Message Center notice MC1073068, citing alignment with the broader Windows NTLM-deprecation roadmap [@handsontek-mc1073068]. The message body is explicit: "Disabling this feature will impact the ability to map potential lateral movement paths (using SAM-R queries) because the data used to calculate potential lateral movement paths will no longer be collected by the Defender for Identity sensor." SAM-R as a remote-discovery primitive had become a security debt as much as a feature; the deprecation brought MDI's collection behaviour into line with Restricted SAM and Microsoft's NTLM-deprecation posture, but it left the LMP surface without its primary data source.

The replacement is in two pieces. The first is the unified attack-path exploration surface in Microsoft Defender XDR, driven primarily by Microsoft Defender for Cloud's Cloud Security Posture Management (CSPM) attack-path engine [@mslearn-defenderforcloud-attack-path], with MDI feeding identity signal into the same correlation. The second is the Identity Explorer Preview that launched in April 2026 on the Microsoft Sentinel data lake, specifically for identity attack paths -- visible from the Identity page in Defender XDR for tenants with a Sentinel data lake licence [@mslearn-mdi-whats-new][@mslearn-xdr-hunting-graph][@mslearn-xdr-investigate-users]. The honest framing in 2026 is that the post-SAM-R LMP coverage is not yet fully closed by either replacement -- the Defender XDR hunting graph is rich, the Identity Explorer is improving, but the seven-year-old SAM-R-derived LMP report had operator workflows around it that the new surfaces have not all reproduced.

MDI's graph layer is in transition. The cloud rewrite handed Microsoft the platform to ship a better graph than ATA ever could; in 2026 the build-out is still in progress. Section 9 will name this as one of the article's open problems. First, though, we have to look at the competitive market the watcher sits inside.

7. Competing Approaches -- the 2026 Identity-Detection Market

If MDI is the watcher on the DC, what is everybody else? Five named methods share the 2026 identity-threat detection market with MDI, each optimising for a different trade-off. The table below is the six-column shorthand; the prose that follows is the per-method analysis.

Vendor / project	On-DC sensor model	Data-input mix	Alert taxonomy	Graph model	Pricing model
MDI	On-DC sensor (v2.x standalone or v3.x MDE-integrated)	Wire + event log + ETW + AD CS audit	MITRE-aligned alert catalogue + nine ESC posture	Hunting graph + Identity Explorer Preview	Bundled with M365 E5 / E5 Security / F5 Security
CrowdStrike Falcon Identity Protection	Connector on/near DC + endpoint agent	Wire (via connector) + endpoint telemetry	ITDR-style alerts, less granular ATT&CK mapping	Identity attack-path view (inline enforcement)	Falcon ITDR module add-on
Semperis DSP + ADFR	Off-DC change-tracking agent	AD object-change events (LDAP / replication)	IoC and IoE runtime alerts plus drift / tamper alerts	Tier 0 exposure graph + rollback graph	Standalone licence per AD object
SpecterOps BloodHound Enterprise	Off-DC collector (SharpHound CE)	AD permissions graph + Azure / Okta / Mac extensions	Attack-path exposure findings	Pure graph (Cypher over Postgres / Neo4j)	Standalone SaaS licence
Microsoft Sentinel native UEBA	None on DC (consumes MDI + other sources)	Sentinel data lake (cross-product)	UEBA risk scores, anomaly events	None on identity graph directly	Sentinel ingestion + UEBA add-on
Sigma + SIEM (open source)	None on DC (event forwarder agents)	Windows event logs, ETW via OSQuery / Velociraptor	Custom rule library	None	Free (rule library); SIEM cost separate

CrowdStrike Falcon Identity Protection is the post-acquisition rename of Preempt Platform, the product line CrowdStrike bought when it completed the Preempt Security acquisition on September 30, 2020 [@businesswire-cs-preempt]. Architecturally distinct from MDI: rather than relying on an on-DC sensor that parses wire traffic and event logs, Falcon Identity Protection inspects authentication traffic via a connector deployed on or near each DC and correlates it with Falcon-agent telemetry already collected from every protected endpoint. Identity-policy enforcement is inline -- the product can require an MFA challenge or block an authentication at the point of decision rather than emit a post-hoc alert [@crowdstrike-falcon-id]. This is the only commercial product in the survey that does inline enforcement on AD Kerberos and NTLM authentications; it is also the only one that is not bundled with a Microsoft 365 licence.

The product category that combines runtime detection of identity-targeted attacks (Kerberos forgery, credential theft, lateral movement) with response capabilities (force MFA, disable user, revoke session). Gartner formalised the term in 2022. CrowdStrike Falcon Identity Protection and SentinelOne Singularity Identity are the largest ITDR-positioned products outside the Microsoft stack; MDI plus the Defender XDR remediation actions surface effectively functions as Microsoft's ITDR offering for tenants already inside the Microsoft 365 estate [@mslearn-mdi-remediation-actions].

Semperis Directory Services Protector (DSP) and the companion Active Directory Forest Recovery (ADFR) product are best known for change-tracking and recovery, layered over a runtime Indicators-of-Compromise and Indicators-of-Exposure detection set that overlaps with MDI's alert taxonomy on classes like DCSync, DCShadow, and Golden Ticket replay [@semperis-dsp][@semperis-adfr]. DSP tracks AD object changes in near-real-time, fires IoC and IoE alerts on the same primitives MDI watches, and offers post-attack rollback as its primary differentiator; ADFR handles malware-free forest recovery in minutes-to-hours rather than days-to-weeks. The pair is partly complementary, partly overlapping with MDI: DSP catches the post-attack drift (the unauthorised group membership change, the rogue ACL) and offers a rollback path MDI does not have; MDI's per-principal behavioural baselines and unified Defender XDR incident queue are the differentiator on the in-flight detection axis; ADFR handles "the worst day of your career" forest-recovery scenarios where rebuilding the directory is the only remediation. Many tenants run all three.

SpecterOps BloodHound Enterprise (BHE) is the commercial form of the BloodHound 2016 graph model that Andy Robbins, Rohan Vazarkar, and Will Schroeder published at DEF CON 24 [@defcon-six-degrees][@bloodhound-github-specterops][@neo4j-bh]. Pure graph attack-path exposure model: BHE maps the paths that exist (Tier Zero hygiene, principal-to-principal cross-domain trust paths, Entra to on-prem pivots) rather than alerts on attacks in flight [@specterops-bhe]. Complementary to MDI: BHE tells you the attack path exists in the directory, MDI tells you someone is walking it right now. The SpecterOps team's Certified Pre-Owned whitepaper (June 2021) by Will Schroeder and Lee Christensen is the source of the ESC1-ESC8 vocabulary that downstream MDI ADCS posture assessments map to [@specterops-cpo-pdf][@specterops-cpo-blog].

Microsoft Sentinel native UEBA is the SIEM-side behavioural-baselines product over the broader event corpus that Sentinel ingests. Sentinel UEBA uses machine learning to build dynamic behavioural profiles for users, hosts, IP addresses, applications, and other entities, with named data-source connectors including Defender for Identity [@mslearn-sentinel-ueba]. Sentinel UEBA is the "outside the identity tables" layer -- detection that needs to correlate identity signal with email, endpoint, network, and SaaS signal lives there rather than in the identity tables themselves. The Defender XDR-to-Sentinel connector unifies the surfaces [@mslearn-sentinel-defender-connector].

Open-source detection stacks -- Sigma rules deployed against Sentinel, Splunk, or Elastic, plus Velociraptor and Wazuh -- can match many of MDI's pattern-based alerts but cannot match MDI's per-principal behavioural baselines without significant in-house investment [@sigmahq-github]. The SigmaHQ rule corpus contains over 3,000 detection rules in a vendor-neutral SIEM format. Olaf Hartong's FalconForce team publishes the FalconFriday hunting-query repository (MDE-schema KQL queries for DLL injection, COM hijacking, LOLBins, LDAP anomalies, and SMB NULL sessions) -- the operator-side companion to community-built detection libraries [@github-falconfriday][@falconforce-blog].

MDI is the high-coverage, low-effort identity-threat detection product if you already have Microsoft 365 E5 or E5 Security. The third-party products in this market win on differentiation -- inline enforcement, change-tracking, exposure-graph mastery -- rather than baseline coverage. The interesting question for an architect in 2026 is not which to buy. The interesting question is what MDI, by design, cannot see at all.

8. Theoretical Limits -- the Five Structural Ceilings

There are attacks no version of MDI will ever detect. Not because Microsoft has not shipped the alert yet, and not because the engineering team has not gotten around to it. Because the alert is structurally impossible.

Five named ceilings, each anchored to a primary source. Together they are the residual blind-spot inventory every operator should be able to name from memory.

flowchart TD subgraph causes ["Attacker-side cause"] C1["OS does not expose
the credential operation"] C2["Forged ticket is
cryptographically identical"] C3["Wire traffic is wrapped
in an encrypted channel"] C4["Attack pivots through
a forest without a sensor"] C5["Attacker uses real DA
real credentials"] end subgraph gaps ["Defender-side gap"] G1["Credential Guard wall"] G2["Sapphire Ticket class"] G3["Encrypted-channel DCSync"] G4["Cross-forest tail"] G5["Legitimate principal
non-detection"] end C1 --> G1 C2 --> G2 C3 --> G3 C4 --> G4 C5 --> G5

Ceiling 1 -- the Credential Guard wall. Anything the operating system itself cannot see is invisible to MDI. The DCSync class is the canonical example with a twist: Credential Guard isolates the LSASS process so that credentials in memory cannot be scraped from a compromised endpoint, but it does not prevent DRSUAPI-level secret extraction against the DC because the DRSUAPI replication interface is supposed to return password hashes to legitimate replication partners. MDI catches DCSync by detecting the wire-side pattern (DRSUAPI from a non-DC source), not by Credential Guard's protection. Anything the OS does not expose in event log, wire traffic, or instrumented API -- a custom kernel driver that reads secrets through a side channel, a hypervisor-level credential extraction on a non-Secured-core host -- is, by construction, outside MDI's data layer.

Ceiling 2 -- forged-ticket cryptographic indistinguishability, the Sapphire Ticket. This is the most important ceiling, and the one whose permanence the rest of this section orbits.

A forged Kerberos Ticket Granting Ticket whose Privileged Attribute Certificate (PAC) is a verbatim copy of a legitimate principal's PAC, obtained via the S4U2self plus User-to-User PAC-copy flow against the target principal and then encrypted with the stolen `krbtgt` key. The technique was disclosed by Charlie Bromberg (Synacktiv / Shutdown) in October 2022 and documented on The Hacker Recipes wiki [@hackerrecipes-sapphire]. The defining property: every byte of the forged ticket's PAC matches the byte pattern of a ticket the genuine KDC would have issued for the legitimate principal, including the group SID set, the user ID, the logon time, and the authorisation-data fields. The classic Golden Ticket leaves PAC anomalies that MDI's *Suspected Golden Ticket usage (forged authorization data)* alert fires on; the Sapphire Ticket leaves no PAC anomaly because there is no anomaly to leave. The Sapphire Ticket attack obtains a target principal's PAC via the S4U2self plus User-to-User PAC-copy technique -- a Kerberos protocol flow Microsoft published as part of MS-SFU and MS-KILE -- which extracts a genuine PAC into a usable form without ever needing to authenticate as the target. The attacker then forges a new ticket whose PAC is the captured PAC, encrypted with the stolen `krbtgt` key. The mechanical sequence is: S4U2self against the target produces a ticket containing the target's PAC; the U2U flow lets the attacker decrypt the embedded PAC blob; the attacker then mints a fresh TGT around that PAC with the genuine signing key. The KDC's signature checks pass because the signing key is real, and the PAC's structural fields pass because they were lifted from a ticket the genuine KDC just issued. Only the original credential compromise that produced the `krbtgt` hash leaves a trail.

Key idea: Cryptographic indistinguishability is a permanent class. No future MDI release fixes the Sapphire Ticket without breaking Kerberos itself.

Rotate `krbtgt` twice on a defined cadence -- 90 days is common; some Tier Zero playbooks rotate every 30 days. The "twice" is non-optional: a single rotation leaves the prior `krbtgt` key valid for the duration of any tickets the KDC has previously issued, so the stolen key is still usable for up to 10 hours (or longer, on `MaxRenewAge` extensions). Combine with Authentication Policy Silos for Tier Zero service accounts, Tier Zero access reviews, and Privileged Access Workstations for any administrator who can read `krbtgt`. None of these closes the Sapphire Ticket; together they shrink the window in which a stolen key remains weaponisable. Sample PowerShell for the double rotation is in the Microsoft-published `Reset-KrbTgt` script in the GitHub samples repository [@msdefender-id-github].

Ceiling 3 -- the encrypted-channel DCSync class. When DRSUAPI is wrapped in a transport the on-DC capture cannot decode -- DCSync over LDAPS via a SPN-bound impersonation chain, for instance -- the wire-side pattern recognition that powers the External ID 2006 alert degrades. The structural detector in Section 6.3 catches the unencrypted case; the encrypted case requires either a different observation surface (the DRSUAPI handler's own instrumentation) or behavioural baselining on the post-fact replication-log signal. MDI's coverage in this case is partial, not complete.

Ceiling 4 -- the cross-forest under-instrumentation tail. MDI sees the forests its sensors are deployed in. Pivot through an external trust to a forest without MDI coverage and the signal is incomplete -- the attacker's pre-pivot reconnaissance, the actual trust traversal, and any post-pivot actions on the trusting side that do not also touch an MDI-monitored forest will be invisible. This is a deployment property, not a product property: a tenant with MDI on every forest in its environment does not have this ceiling. A tenant whose acquisition portfolio includes three forests it does not yet monitor does.

Ceiling 5 -- legitimate-principal compromise non-detection. When the attacker uses a real Domain Admin's real credentials, every action is behaviourally indistinguishable from the legitimate principal unless timing, geolocation, or device fingerprint breaks the baseline. The 2025 and 2026 Suspected session cookie theft and related XDR-format alerts close part of this gap by adding behavioural side channels that the older Azure ATP alert catalogue did not cover [@mslearn-mdi-alerts-xdr]. The residual is permanent: a sufficiently disciplined attacker operating from the legitimate principal's normal workstation, during the legitimate principal's normal hours, doing things the legitimate principal might plausibly do, is, by construction, indistinguishable from the legitimate principal.

A sixth honourable mention sits adjacent to these five: out-of-band physical access -- a stolen Ntds.dit backup, an attacker-controlled DC's offline export, supply-chain firmware compromise on the DC hardware -- is outside the data layer MDI operates over. The hardware-trust-root community owns this class of mitigation, not the identity-threat detection community.

Note: The five structural ceilings are knowable, not surprises. A SOC that names them ahead of time has a better incident-response runbook than one that does not -- specifically, the runbook for "we just realised the attacker used a Sapphire Ticket" is fundamentally different from the runbook for "MDI fired and we ignored it." The first runbook starts with krbtgt rotation and Tier Zero hygiene review; the second starts with disciplinary review and SOAR-rule tuning. Knowing which runbook to pick depends on naming the ceiling correctly.

These five named residuals are why the rest of the article exists. If MDI caught everything, the operator playbook in Section 10 would be unnecessary. Because MDI does not, and because the gaps are knowable, the playbook in Section 10 is the difference between MDI as a licence line item and MDI as a working part of the SOC's day. But before the playbook, one last open-problem inventory: where is the research roadmap actually working?

9. Open Problems -- What the Research Roadmap Is Working On

Five open problems sit between the 2026 floor and a hypothetically perfect identity-threat detector. Each one has a current best partial result and a citation. None of them is closed.

Open Problem 1 -- the post-PKINIT NTLM-relay class beyond ESC8. Synacktiv's Understanding and evading Microsoft Defender for Identity PKINIT detection paper (Guillaume Andre, 2024) reverse-engineered MDI's PKINIT-class detection: MDI fingerprints offensive-tool-generated AS-REQ messages by the encryption types they advertise, which differ from the encryption-type list a legitimate Windows API PKINIT request generates [@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. The companion Invoke-RunAsWithCert PowerShell tool generates AS-REQ messages via the Windows API itself, producing requests structurally identical to legitimate enterprise PKINIT authentication and bypassing the fingerprint-based detection [@synacktiv-runascert-gh][@deepwiki-runascert]. Aura Security's follow-on writeup confirms the technique against the current MDI version and walks through modifying Certipy to produce matching AS-REQ shapes [@aurainfosec-mdi-pkinit]. The partial mitigation in 2026 is the additional posture-side coverage in the nine MDI Certificates assessments, which closes some of the configurations the offensive tools target [@mslearn-mdi-certificates-posture]. The runtime detection arms race continues.

Open Problem 2 -- the graph-layer transition from SAM-R LMP to Identity Explorer. Section 6.4 covered the deprecation of SAM-R-based LMP discovery in May 2025 (MC1073068) and the two replacement surfaces: the Defender XDR attack-path exploration driven by Defender for Cloud's CSPM engine, and the April 2026 Identity Explorer Preview on the Sentinel data lake [@handsontek-mc1073068][@mslearn-defenderforcloud-attack-path][@mslearn-mdi-whats-new][@mslearn-xdr-hunting-graph]. The honest open question is whether either surface reproduces, in 2026, the operator workflows the seven-year-old SAM-R-derived LMP report had built up around itself. The Defender XDR hunting graph is richer than the LMP report ever was, but its data model is different; the Identity Explorer is closer in spirit but in Preview rather than GA.

Open Problem 3 -- the Sentinel data lake correlation and the Identity Explorer GA path. Microsoft Sentinel data lake, the cross-product cold-storage and analytics layer, went public preview in 2025 and ships with up to 12 years of retention in Parquet format, a clean separation of storage and compute, and KQL plus Jupyter notebook query surfaces [@mslearn-sentinel-datalake][@mstc-sentinel-datalake-preview]. Identity Explorer is the first identity-specific surface built on top of the data lake; it is in Preview as of April 2026 with no GA date published. The open problem is whether the data-lake-tier correlation can match the alert-tier MDI quality for long-running attacker dwell -- the months between Sapphire Ticket use and discovery class -- without producing more noise than signal.

Open Problem 4 -- the MDI evasion research arms race. Synacktiv's two papers (the sensor primer by Andre and Benassouli in 2022; the PKINIT evasion paper by Andre in 2024) plus the operator notes on alert-timing exploitation that show up in adsecurity.org and SpecterOps content are the public record of the offensive-research community's targeting of MDI specifically [@synacktiv-primer-mdi][@synacktiv-primer-mdi-archive][@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. FalconForce's reverse-engineering of the MDE sensor (via Olaf Hartong's MDE Internals series) is the methodological precedent for the same approach against MDI; the FalconForce blog and the FalconFriday hunting-query repository are the operator-facing primaries [@falconforce-mde-0x02][@falconforce-mde-0x03][@falconforce-blog][@github-falconfriday][@github-olafhartong]. The Charlie Bromberg Sapphire Ticket disclosure (October 2022) is the cryptographic-attack-class research that Section 8's third ceiling rests on [@hackerrecipes-sapphire]. The arms-race property is permanent; the defensive product team's job is to keep the detection-shipping cadence faster than the evasion-shipping cadence, which the cloud rewrite (see Section 5) made structurally possible.

Open Problem 5 -- the non-Windows directory coverage tail. MDI covers Active Directory and (via the Microsoft Entra Connect sensor) the on-prem-to-Entra-ID sync surface. Native Entra ID attacks (token theft against Entra ID itself, OAuth consent phishing, Conditional Access bypass) are covered by Defender for Cloud Apps and Entra ID Protection, not by MDI. The boundary between MDI's scope and the adjacent products is operationally meaningful: a SOC operator reading "MDI did not fire" on an Entra-ID-only attack should not conclude the attack went undetected -- another product likely did fire, in another part of the same Defender XDR portal. The unified incident queue stitches the alerts together; the operator's mental model has to know which sensor surface to look at when triaging.

The article does not claim "BloodHound CE forced MDI to add ADCS detections in 2024." The framing is parallel evolution: as BloodHound CE expanded ADCS attack-path coverage in 2024-2025, MDI extended its ADCS posture assessments and PKINIT-class runtime detections during the same window. The two product communities watch each other; neither one "forces" the other.

The roadmap is real, the build-out is in progress, and the operator decision in 2026 is not "wait for the perfect product." It is "deploy what works now, and cover the residuals with KQL."

10. The MDI Deployment and Triage Playbook

Four lanes, mapped to four operator personas: the architect who designs the sensor footprint, the SOC analyst who triages the alerts, the threat hunter who writes the KQL that fills the gaps, and everyone who needs to know what does not work.

Lane 1 -- sensor placement and prerequisite hygiene

Deploy the v3.x sensor on every domain controller running Windows Server 2019 or later, paired with the MDE agent. The deployment path is the Microsoft Defender portal's migration wizard or the standalone install via the MDE agent's onboarding flow [@mslearn-mdi-deploy-sensor-v3][@modernsec-v3x][@jeffreyappel-v2v3].

Deploy the v2.x sensor on every AD FS federation server, every AD CS online issuing certificate authority, and every Microsoft Entra Connect server (both active and staging), unless those roles already run on a domain controller covered by a v3.x sensor with the May 2026 identity-role extension enabled [@mslearn-mdi-prereq-sensor-v2][@mslearn-mdi-whats-new].

Configure the required Windows audit subcategories via the Group Policy Subcategory Settings path that the MDI event-collection page enumerates -- Audit Credential Validation, Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Logon, Audit Directory Service Access, Audit Computer Account Management, plus the additional subcategories for AD CS and AD FS roles. The v3.x sensor includes an Automatic Windows auditing configuration toggle that uses the Windows LSA audit-policy APIs to set the subcategories directly, eliminating the GPO step [@mslearn-mdi-event-collection].

Set the MDI Action Account in the Defender portal. The default is LocalSystem impersonation on the sensor host, which works for response actions targeting AD objects (force password reset, disable user). A gMSA-based Action Account is the alternative for tenants that want least-privilege response identities scoped per workspace [@mslearn-mdi-action-accounts][@mslearn-mdi-remediation-actions]. Avoid configuring the same gMSA across multiple sensor hosts -- the documented anti-pattern is to use one Action Account for DC-side actions only.

Verify the Microsoft Defender portal role assignments so that SOC analysts have the correct read-and-respond permissions on identity alerts. The Microsoft Defender for Identity enterprise application (ID 60ca1954-583c-4d1f-86de-39d835f3e452) is the consent surface for the response actions; tenants that have not granted consent will see "remediation action unavailable" on identity-targeted incidents [@mslearn-mdi-remediation-actions].

Lane 2 -- alert triage SLAs

The triage matrix maps alert category to response-time target and the named SOC role that owns triage. Numbers below are typical Tier 1 / Tier 2 SOC targets; tune to your environment's incident-response policy.

Alert category	Response-time target	Owning SOC role	Notes
DCSync, DCShadow, Golden Ticket	1 hour	Tier 2 (privileged-account-compromise specialist)	Treat as confirmed compromise pending evidence to the contrary
AS-REP Roasting, Kerberoasting	4 hours	Tier 2	Higher-FP class; verify offending principal pattern before escalation
NTLM relay (ESC8 class)	4 hours	Tier 2	ADCS-aware; coordinates with CA team
Reconnaissance (LDAP / SMB / DNS)	24 hours	Tier 1	Highest-FP class; allowlist legitimate scanners
Honeytoken activity	1 hour	Tier 1 plus Tier 2 escalation	Near-zero FP; any hit is investigation-worthy

Two false-positive cleanup patterns appear in nearly every tenant. The Azure AD Connect Cloud Sync service principal -- MSOL_ plus an 8-character random suffix -- legitimately performs DRSUAPI-like operations as part of the hybrid identity sync flow, and will fire DCSync-class alerts unless allowlisted. Legitimate vulnerability scanners (Tenable, Rapid7, Qualys) perform authenticated enumeration that triggers the LDAP and SMB reconnaissance alerts; scanner IPs go in an exclusion list per the Defender XDR portal's identity-alert tuning surface.

The MDI Action Accounts and Remediation Actions surface lets the responder disable a user, force a password reset, revoke an Entra ID session, or mark an account as compromised -- triggered manually from the alert flow or automatically via the Defender XDR automatic attack disruption engine, which requires 99 percent or higher detector precision before taking containment action [@mslearn-xdr-attack-disruption][@mslearn-mdi-remediation-actions][@mslearn-xdr-investigate-users]. Automatic attack disruption is opt-in per containment action; the conservative default leaves analyst confirmation in the loop for password-reset-class actions and automates disable-user only on the highest-precision detector classes.

Note: The cloud-side analytics pipeline aggregates signal across the per-principal baseline window before deciding to emit. Empirically the alert latency is minutes-cadence, not seconds-cadence. Incident response runbooks that assume sub-second alert arrival will be wrong; the operator clock starts when the alert hits the Defender XDR queue, which is itself minutes after the wire-side event. Plan for this in the SLA matrix above -- the "1 hour" target for DCSync starts from the alert timestamp, not the attack timestamp, and the attack itself may have happened five or ten minutes earlier. The Microsoft alerts-overview page is explicit that MDI is "not designed to serve as an auditing or logging solution that captures every single operation or activity on the servers where the sensor is installed; it only captures the data required for its detection and recommendation mechanisms" [@mslearn-mdi-alerts-overview].

Lane 3 -- advanced-hunting queries that fill the gaps

Three structural detectors in KQL form, each one targeting a class the named alerts can miss. Each query names the table, the columns, and the threshold tuning the operator will need.

The structural DCSync detector runs against IdentityDirectoryEvents and catches the encrypted-channel case the External ID 2006 alert may miss:

IdentityDirectoryEvents
| where Timestamp > ago(24h)
| where ActionType == "DRSReplicate"
| extend SourceIP = tostring(parse_json(AdditionalFields).SourceIPAddress)
| where SourceIP !in ("10.0.1.10", "10.0.1.11", "10.0.1.12")   // tenant DC IPs
| where AccountName !startswith "MSOL_" and AccountName !in ("ADConnectSync")
| project Timestamp, AccountName, SourceIP, TargetDeviceName, AdditionalFields
| order by Timestamp desc

Threshold tuning: keep the time window short (24 hours) for daily triage. Cleanup principals (MSOL_*, ADConnectSync, plus any per-tenant sync identities) go in the !startswith and !in clauses. The query produces a clean queue of "DRSUAPI replication from a host that should not be doing DRSUAPI." False-positive class: legitimate Azure AD Connect Cloud Sync service principals; resolve by adding the principal to the allowlist.

The slow-burn Kerberoasting detector runs against IdentityLogonEvents and catches the rate-limited Kerberoast pattern that modern attackers use to stay below the MDI behavioural-baseline threshold:

IdentityLogonEvents
| where Timestamp > ago(7d)
| where Protocol == "Kerberos"
| where ActionType == "ServiceTicketRequest"
| extend EncType = tostring(parse_json(AdditionalFields).EncryptionType)
| where EncType in ("RC4-HMAC", "DES-CBC-MD5")
| summarize SpnCount = dcount(TargetSpn), SpnList = make_set(TargetSpn) by AccountName, bin(Timestamp, 1d)
| where SpnCount > 5     // tune per tenant baseline
| order by Timestamp desc, SpnCount desc

Threshold tuning: the SpnCount > 5 threshold is the load-bearing knob. Tenants with legitimate operational accounts that request many SPNs per day (privileged service accounts running scheduled tasks across many target hosts) will need a higher threshold and an allowlist. The seven-day window catches the slow-burn pattern that a one-hour window misses.

The PKINIT-relay structural detector runs against IdentityLogonEvents and watches for AS-REQ with PA-PK-AS-REQ pre-auth coming from unexpected client subnets:

IdentityLogonEvents
| where Timestamp > ago(24h)
| where Protocol == "Kerberos"
| where ActionType == "InitialAuthentication"
| extend PreAuth = tostring(parse_json(AdditionalFields).PreAuthType)
| where PreAuth == "PA-PK-AS-REQ"
| extend ClientSubnet = strcat(split(IPAddress, ".")[0], ".", split(IPAddress, ".")[1])
| where ClientSubnet !in ("10.0.5", "10.0.6")    // legitimate smartcard subnets
| project Timestamp, AccountName, IPAddress, DeviceName, AdditionalFields
| order by Timestamp desc

Threshold tuning: PKINIT is legitimate when smartcard logon is in use. Identify the legitimate smartcard-issuing subnets and add them to the !in clause. The residual queue is PKINIT from unexpected sources -- the structural pattern behind both the post-ESC8 NTLM-relay class and the Synacktiv Invoke-RunAsWithCert evasion class.

Tenants that want the alert and event corpus in their SIEM as well as in Defender XDR should configure the MDI to Microsoft Sentinel connector through the Defender XDR-to-Sentinel integration; the connector is auto-enabled when Sentinel is onboarded to the Defender portal [@mslearn-sentinel-defender-connector].

Lane 4 -- what does NOT work

Five named operator myths, each refuted with a one-paragraph structural reason.

Myth 1: "MDI without the DC sensor still catches Kerberos attacks via the Entra ID side." Wrong. The Kerberos protocol layer is on-prem; the analytics require on-DC capture of the AS-REQ / TGS-REQ / AP-REQ exchange. Entra ID's side of the hybrid auth flow does not carry the same protocol detail. A tenant with MDI licensed but the sensor not deployed on the DCs has no Kerberos detection at all -- the licensed state is necessary but not sufficient.

Myth 2: "Disabling the v2.x sensor on AD FS is fine since it is covered by the DC sensor." Wrong. The AD FS authentication flow generates federation-side events (SAML assertions, OAuth tokens, the Application and Security event logs that AD FS itself writes) that the DC sensor does not see. AD FS deserves its own sensor unless the AD FS role is collapsed onto a domain controller, in which case the May 2026 v3.x identity-role extension covers it.

Myth 3: "Defender for Endpoint covers what MDI covers." Wrong. MDE catches endpoint behaviour -- process creation, file access, network connections, registry writes. MDI catches protocol-level Kerberos, NTLM, LDAP, and DRSUAPI patterns. The two products share an agent surface in the v3.x architecture, but the signal classes are different. An MDE-only deployment will not catch a DCSync from a workstation if MDI is not licensed and the sensor is not deployed; the MDE agent on the DC sees the local process activity but not the wire-side replication call's source.

Myth 4: "MDI alerts are real-time." Wrong. As Callout in Lane 2 above. The cloud-side batched-emission cadence is minutes-not-seconds, and incident response runbooks need to account for it.

Myth 5: "MDI requires no tuning." Wrong. Every environment has unique false-positive patterns from internal tooling that need exclusions. Microsoft ships the default detector thresholds; tenants tune them through the Defender XDR portal's identity-alert configuration surface. A tenant that has not tuned the recon-alert allowlist for its vulnerability scanners will receive far more noise than signal.

Coverage, triage, KQL, and humility about what does not work. The four lanes are the difference between MDI as a licence item on a renewal sheet and MDI as a working part of the SOC's day.

11. Frequently Asked Questions and Closing

Six questions that come up every time MDI is on a whiteboard, each in the misconception-removal pattern: wrong answer named first, then refuted.

No. See the *common misreading worth fixing* Callout in Section 4: graph-anchored attack-path evaluation in Microsoft's defensive stack originates in ATA 1.9 (March 2018), and the 2022 anchor in operator memory is the start of the SAM-R-discovery deprecation arc that culminated in MC1073068 in May 2025 [@mslearn-ata-1-9][@handsontek-mc1073068]. Not as one alert per ESC class. The MDI Certificates posture page documents **nine ADCS posture assessments** -- ESC1 (Preview), ESC2, ESC3, ESC4 (template-owner and template-ACL variants), ESC6 (Preview), ESC7, ESC8, ESC11, and ESC15 [@mslearn-mdi-certificates-posture]. The runtime detection surface for the ESC8 NTLM-relay class is the *Suspected NTLM relay attack* alert in the XDR catalogue [@mslearn-mdi-alerts-xdr]. PKINIT-class runtime detection (the post-ESC8 chain) is the AS-REQ encryption-type fingerprint that Synacktiv documented and partially evaded; the August 2023 AD CS sensor release is the prerequisite for posture coverage [@mstc-adcs-sensor][@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. Coverage is "nine posture assessments plus one runtime alert," not "one alert per ESC1 through ESC15." Microsoft has never published the canonical list; community reverse-engineering is the only source. See the *honest provenance of the ETW provider list* Aside in Section 5 for the full provenance (Synacktiv's November 2022 primer; Olaf Hartong's FalconForce MDE Internals 0x02 methodology; the Get-TraceLoggingMetadata + Sealighter toolchain) and the snapshot-not-ground-truth framing [@synacktiv-primer-mdi][@falconforce-mde-0x02]. In the cloud since Azure ATP went GA in March 2018 [@mstc-azureatp-ga][@mstc-azureatp-intro]. The on-DC sensor is a thin parser that captures Kerberos / NTLM / LDAP / DRSUAPI on the wire, parses the protocols into structured events, and streams the parsed signal to the multi-tenant cloud backend over HTTPS. The detection logic, the per-principal behavioural baselines, and the alert-emission pipeline all run in the cloud. The legacy on-prem ATA Center model ended with Azure ATP; ATA itself shipped its last release (1.9.3) in September 2020 and Extended Support ends January 2026 [@mstc-ata-eol][@atadocs-versions]. No. The framing is parallel evolution, not a "forcing" relationship. BloodHound CE expanded ADCS attack-path coverage substantially in 2024 and 2025; during the same window MDI extended its ADCS posture assessment surface and added the AD CS sensor release in August 2023 [@mstc-adcs-sensor][@dirteam-sander-aug2023]. Both product communities watch each other -- the Defender team uses BloodHound to red-team its own environments, the SpecterOps team uses MDI when consulting in enterprise Microsoft shops -- but the causal claim "BloodHound forced MDI" is not supported by the public release record. The two communities' work has been concurrent and mutually informing. Almost. The MITRE-aligned alert catalogue in Section 6.2 covers the most-prevalent offensive primitives. Section 8 names the five structural ceilings that remain by-construction unclosable; *almost* is the load-bearing word.

Friday, 14:35. The watcher on the domain controller has written three named alerts into the Defender XDR queue. The red-team contractor's Rubeus.exe asreproast fired Suspected AS-REP Roasting attack (T1558.004). The junior auditor's bloodhound-python -c All fired Security principal reconnaissance (LDAP). The Mimikatz DCSync against the SQL host's service account fired Suspected DCSync attack -- replication of directory services, External ID 2006, T1003.006. Three alerts. Three MITRE technique IDs. Three rows in a Tier 1 analyst's queue.

The watcher's job is done. Whether the analyst opens the right one first, whether the Tier 2 escalation happens inside the one-hour SLA, whether the response action gets approved before the attacker has moved on -- none of that is MDI's problem to solve. It is yours.

Attack Surface Reduction Rules: The Quiet Layer That Stopped Office Macros

noreply@paragmali.com (Parag Mali) — Tue, 26 May 2026 00:00:00 GMT

**Attack Surface Reduction (ASR) rules are Microsoft's nineteen-rule, kernel-mediated, free-with-Windows behaviour block list.** Each rule names a single edge in the runtime process / file-system / registry graph -- Office spawning child processes, scripts launching downloaded executables, processes opening LSASS, vulnerable signed drivers being written -- and refuses to let it happen. Shipping since Windows 10 1709 (October 2017) [@ms-security-blog-exploit-guard-2017], the rules killed the cheap end of the Office-macro initial-access chain at the enterprise tier; the Microsoft 365 Apps default block of internet-marked macros (February and July 2022) [@ms-techcommunity-internet-macros-2022] and Europol's Operation LadyBird (January 2021) [@europol-emotet-disrupted-wayback] finished the era at the consumer tier and the C2 tier respectively. The layer is incomplete by construction -- Cohen-1984 undecidability forbids a complete behaviour catalogue [@cohen-1984-part1] -- but it compresses attacker bypass cost so effectively that the SOC routinely does not triage the blocks. Every rule emits a rule-specific Advanced Hunting `ActionType` such as `AsrOfficeChildProcessBlocked`; the folk-knowledge generic `AsrRuleTriggered` does not exist [@ms-learn-asr-reference].

1. One Block, No Analyst Ticket

At 03:42 on a Tuesday morning in Frankfurt, a finance analyst opens an invoice attached to an email that looks like one she has answered fifty times before. The document's Document_Open macro fires, the VBA calls Shell("powershell.exe -enc ..."), and nothing happens. No PowerShell window. No second-stage download. No banking-trojan loader. No ransom note three weeks later. The only artefact is one row in Microsoft Defender for Endpoint's DeviceEvents table, with ActionType equal to AsrOfficeChildProcessBlocked, that no analyst will triage because there is nothing left to triage [@ms-learn-asr-reference].

That row, and the silence around it, is the entire subject of this article.

To understand why nothing happened, watch the call in slow motion. WINWORD.EXE is a long-running user-mode process. The macro's process-creation call crosses the syscall boundary into the kernel's process-management subsystem, where Microsoft Defender Antivirus has registered a process-creation notify routine. Defender's kernel-mode driver WdFilter.sys -- registered with the Windows Filter Manager as a file-system minifilter AND with the kernel's process subsystem via PsSetCreateProcessNotifyRoutineEx -- intercepts the event through its process-creation notify routine before the new process runs and hands it to the user-mode antivirus engine MsMpEng.exe. (Section 5 walks the kernel/user-mode split in full.) MsMpEng.exe evaluates the rule with GUID D4F940AB-401B-4EFC-AADC-AD5F3C50688A -- "Block all Office applications from creating child processes" [@ms-learn-asr-reference]. The predicate evaluates true. The rule is set to Block. The minifilter fails the operation. The macro gets a non-zero error from its process-creation call. The spawn never happens.

A fixed catalogue of behavioural blocks shipped as a feature of Microsoft Defender Antivirus on Windows 10 1709 and later, Windows 11, and supported Windows Server editions. Each rule names a specific runtime behaviour -- "Office applications creating child processes," "credential stealing from the Windows local security authority subsystem," "abuse of exploited vulnerable signed drivers" -- and can be enabled in Audit, Warn, or Block mode through Microsoft Intune, Microsoft Configuration Manager, Group Policy, PowerShell, or the Defender for Endpoint portal. As of May 2026 the catalogue contains nineteen rules: three Standard protection rules and sixteen Other ASR rules [@ms-learn-asr-reference].

Notice what the rule did not do. It did not classify the binary. Both WINWORD.EXE and powershell.exe are signed by Microsoft. Both have multi-decade Authenticode reputation. Both have appeared on every reasonable allow-list since Windows 7. A signature engine, asked "is the macro malicious," would have had to read the macro's bytes, normalise its obfuscation, and decide whether the sequence of Office object-model calls plus a base64 blob constitutes hostile intent. That decision is hard in the easy cases and undecidable in general. The rule sidestepped the whole question. It classified the edge between two perfectly legitimate signed binaries: WINWORD.EXE becoming the parent of powershell.exe. The bytes are not the predicate. The parent-child relationship is.

The folklore that "every ASR block emits ActionType == 'AsrRuleTriggered'" survives in vendor playbooks and Stack Overflow answers but does not match Microsoft Learn's current rules reference, which enumerates a rule-specific Asr<RuleName>Audited and Asr<RuleName>Blocked pair for every rule except the server-only Webshell rule. The canonical Advanced Hunting filter is where ActionType startswith "Asr", not equality against a generic value [@ms-learn-asr-reference].

The Frankfurt analyst's hypothetical Tuesday is one of millions. Defender Antivirus ships on every supported edition of Windows [@ms-learn-asr-reference]. The Office-child-process rule has been blockable since October 2017 [@ms-security-blog-exploit-guard-2017]. It is not the only ASR rule, and ASR is not the only layer that ended the Emotet macro era. Europol's January 27, 2021 takedown and the Microsoft 365 Apps default block of internet macros in February and July 2022 share the credit. But ASR is the layer with the deepest enforcement substrate (a kernel-mode minifilter), the fullest behavioural catalogue (nineteen rules naming specific runtime edges), and the simplest mental model for a defender: name a behaviour, ship an enforcement edge, audit, then block.

Note: Signature engines classify nodes (is this binary malicious?). AppLocker classifies identities (is this binary on the allow-list?). ASR classifies edges in the runtime graph (did this specific parent-child invocation happen?). Section 5 builds the framework. The catalogue in Section 6 reads as nineteen named edges once you see it.

The rest of the article walks the ten questions the Frankfurt block raises. If signatures cannot tell us whether the analyst's macro is malicious -- because both binaries are signed and the static fingerprint of the macro changes every campaign -- how exactly did one row in DeviceEvents know to fire? What does the kernel see that the signature engine does not? Why did three predecessor paradigms (signatures, AppLocker, EMET) fail to close this specific gap, and what made October 2017 the moment Microsoft decided to ship a behaviour catalogue instead of a better classifier? Section 2 starts with the empirical signal that forced the shift.

2. Why Signatures Stopped Being Enough

By the time Microsoft published the October 23, 2017 Windows Defender Exploit Guard launch announcement, the team had a single sentence ready for the executive summary: "fileless attacks, which compose over 50% of all threats" [@ms-security-blog-exploit-guard-2017]. That line did two jobs. It justified shipping ASR. It also marked the moment the signature model hit its industrial-scale ceiling.

Despite advances in antivirus detection capabilities, attackers are continuously adapting ... This emerging trend of fileless attacks, which compose over 50% of all threats, are extremely dangerous, constantly changing, and designed to evade traditional AV. -- Microsoft Threat Intelligence team, October 23, 2017 [@ms-security-blog-exploit-guard-2017]

The 50-percent number is a 2017-vintage Microsoft characterisation, not a peer-reviewed empirical study, but it captures a structural shift that every endpoint-defence vendor had been watching for three years. Three forces had converged.

First, mature crypters and packers had defeated static signatures. The classic AV pipeline -- compute a hash, match against a corpus of known-bad hashes -- assumed attackers shipped a small number of stable binaries. By 2017 the typical commodity malware family rebuilt its payload on every campaign, layered three encryption stages, and emerged as a polymorphic blob whose static fingerprint changed faster than the signature feed. Fred Cohen had warned in 1984 that any complete malicious-program detector reduces to the Halting Problem [@cohen-1984-part1]; commodity packers were the industrial-scale form of that result.

Second, attackers had moved off custom binaries entirely. The Living-Off-the-Land Binaries, Scripts, and Libraries project -- LOLBAS -- catalogues over two hundred Microsoft-signed Windows binaries that attackers use to execute malicious behaviour without dropping any malware artefact on disk [@lolbas-project]. powershell.exe, cmd.exe, wscript.exe, mshta.exe, regsvr32.exe, rundll32.exe, cmstp.exe, msdt.exe, msbuild.exe, installutil.exe -- all signed by Microsoft, all on every reasonable allow-list, all capable of executing arbitrary code given the right command line. The on-disk artefact is benign; the malice lives in the runtime edge between two signed binaries.

A signed Microsoft Windows binary that attackers use to execute malicious behaviour while staying off identity-based allow-lists. The LOLBAS Project enumerates over two hundred such binaries together with the abuse classes each enables and the MITRE ATT&CK techniques each maps to [@lolbas-project].

Third, Office macros had become the dominant initial-access vector. Emotet first appeared as a banking trojan in June 2014; by 2017 it had transformed into a crime-as-a-service loader platform that delivered TrickBot, Dridex, IcedID, and eventually Conti and Ryuk to its access buyers [@welivesecurity-emotet-pivot-2022]. The delivery vehicle barely changed across that pivot: a Word or Excel document, a Visual Basic for Applications macro, a call into Shell, WScript.Shell.Run, or the Windows Management Instrumentation provider to spawn the next stage. The malice was never inside WINWORD.EXE. The malice was in the edge that connected WINWORD.EXE to whichever signed Microsoft binary the operator decided to spawn.

The NTFS alternate data stream `Zone.Identifier` written by browsers, mail clients, and archive extractors to flag a file as originating from outside the local machine. Office uses the MOTW to drop a downloaded document into Protected View; the February 2022 Microsoft 365 Apps internet-macro default block treats the MOTW as the trigger to remove the "Enable Content" button entirely [@ms-learn-internet-macros-blocked].

The pre-2017 defence stack covered slices of this problem, but no layer covered the specific behaviour class "an Office application creates a child process." AV signatures and heuristics scored the binaries; both were signed Microsoft binaries. AppLocker (2009) decided whether a binary was allowed to run; both were on the allow-list. EMET (2009) blocked memory-corruption exploit primitives; the macro chain involved no memory corruption. Reputation-based file blocking covered downloaded payloads; the payload was a base64 string passed on the PowerShell command line, never written to disk. Each layer answered a different question. None answered the question the macro chain raised.

The strategic shift Microsoft eventually made was small in the framing and enormous in the consequences. Instead of asking "is this binary malicious?" -- a question undecidable in general -- the next layer would ask "did the suspicious behaviour happen?" The new question is decidable per event at the OS interception layer, because the kernel sees every process-creation call, every image load, every file write, every registry set. Edge classification does not require static analysis; it requires only that the kernel be wired to ask one extra predicate before completing the operation.

The named author at the bottom of the 2017 launch post body (fetched 2026-05-26) is Misha Kutsovsky (@mkutsovsky), Program Manager, Windows Active Defense. The top-of-page byline and <meta name="author"> tag have since been consolidated under the "Microsoft Threat Intelligence" institutional account during Microsoft's 2022-2025 re-platforming of older Security Blog posts; the in-body attribution is unchanged. This article cites the institutional author as it appears in the page head; the named person at the bottom of the body is Kutsovsky [@ms-security-blog-exploit-guard-2017].

One taxonomy point deserves its own paragraph, because confusion about it shapes most beginner questions about ASR. Microsoft Defender Antivirus is the on-host scanning engine that ships free with every Windows edition. Microsoft Defender for Endpoint (MDE) is the cloud-managed EDR layer Microsoft sells on top. ASR rules live inside Defender Antivirus. They run whether or not the device is enrolled in MDE. MDE adds management, telemetry ingestion through the DeviceEvents table, and Advanced Hunting; it does not add the enforcement. The Frankfurt block fires in Defender Antivirus; the DeviceEvents row only reaches MDE if MDE is connected. The EDR-in-block-mode page is explicit on the dependency: ASR rules run only when Defender Antivirus is in Active mode, never when a third-party AV is primary and Defender is passive [@ms-learn-edr-in-block-mode].

By 2014-2015 the Microsoft Defender team had identified the problem. They did not invent the answer from scratch. They inherited a Windows defence stack that had been trying to solve the same problem for sixteen years, in three earlier paradigms. What were they, and why did none of them stop Emotet?

3. AppLocker, EMET, and What They Could Not Do

Three predecessor paradigms. Three different failures. Three different lessons that Microsoft eventually folded into the design of ASR.

AppLocker (2009, Windows 7)

AppLocker was the identity-based answer to the question "which binaries are allowed to run on this endpoint?" Administrators write rules that allow or deny executable code by publisher, by path, or by file hash; the kernel enforces the policy at process-creation time. Microsoft Learn still describes AppLocker as the Windows 7-era predecessor to App Control for Business, and the design has not changed structurally in the intervening sixteen years [@ms-learn-applocker]. AppLocker is genuinely stricter than ASR on the identity axis. A well-tuned AppLocker policy on a hardened endpoint enforces default-deny: only allowed publishers, only allowed paths, only allowed hashes ever execute.

AppLocker has two practical weaknesses and one structural one. The first practical weakness is brittleness against signed LOLBins: powershell.exe, cmd.exe, wscript.exe, mshta.exe, regsvr32.exe, rundll32.exe, cmstp.exe, msdt.exe, msbuild.exe, installutil.exe are all on every reasonable AppLocker allow-list because every legitimate IT-automation pipeline depends on them [@lolbas-project]. The second is admin-deployment overhead: every new line-of-business application needs an explicit rule addition, large estates fall back to Audit mode permanently, and exception sprawl turns the policy into a sieve.

The structural weakness is the one that matters here. The AppLocker rule grammar has no slot for "WINWORD.EXE may run, but it may not be the parent of cmd.exe." That sentence is a property of an edge in the runtime graph, and the AppLocker schema models nodes, not edges.

EMET (2009-2018)

The Enhanced Mitigation Experience Toolkit was Microsoft's per-process opt-in exploit-time mitigation framework. Data Execution Prevention, Address Space Layout Randomization, Structured Exception Handler Overwrite Protection, the Export Address Table Access Filter, anti-Return-Oriented-Programming heuristics, caller-checks, heap-spray pre-allocation -- EMET stitched the menu together for any process the administrator opted in. EMET stopped buffer overflows from achieving code execution. It made the cheap exploit-development pipeline visibly more expensive.

EMET did not stop the Emotet macro chain. The chain involved no memory corruption. The chain was a legitimately loaded, uncorrupted, signed Office application making a perfectly ordinary user-mode parent-child process-creation call. There was no exploit primitive to mitigate. The 2017 Exploit Guard launch announcement said the same in cleaner language: Exploit Protection (the Windows-integrated pillar that absorbed EMET's mitigations) and Attack Surface Reduction (the new pillar) cover different gaps, because exploit-time mitigations and post-exploit behaviour blocks address different attacker stages [@ms-security-blog-exploit-guard-2017]. EMET reached end-of-life on July 31, 2018 per the Microsoft product lifecycle page [@ms-lifecycle-emet]; its mitigations live on under different names in the Exploit Protection panel of Windows Security.

Signature and heuristic AV

The third predecessor is the one Cohen's 1984 paper had already analysed. Signature and heuristic AV classify nodes, which is to say they answer "is this binary, considered as a sequence of bytes, malicious?" Cohen proved that the general form of that question reduces to the Halting Problem. The verbatim sentence from his open-access archive is the cleanest one-line statement of the result [@cohen-1984-part1]:

The classical result, established in Fred Cohen's 1984 paper "Computer Viruses: Theory and Experiments" (presented at the 7th DoD/NBS Computer Security Conference and reprinted in Computers and Security 6(1):22-35 in January 1987), that detection of arbitrary viral behaviour in a program reduces to the Halting Problem. The diagonal construction assumes a decider `D(P)` for viral behaviour; constructs a program `V` that calls `D(V)` and behaves virally iff `D(V) = 0`; derives a contradiction. The corollary -- any non-trivial semantic property of programs is undecidable -- is the Rice-1953 generalisation [@cohen-1984-part1].

The practical version of the ceiling for the Emotet case is that a signature engine cannot, in general, distinguish a Word macro that legitimately spawns cmd.exe to run an IT-automation script from a Word macro that spawns cmd.exe to launch the Emotet stage-two PowerShell stub. Both call the same Win32 API. Both pass argument strings the engine cannot prove are malicious without modelling the operator's intent. The fingerprint of the malice is not in the binaries; it is in the runtime relationship between them.

The three paradigms -- signature, identity, edge -- are not redundant. Modern defence-in-depth runs all three because each closes a different attacker option. Signatures detect known-bad binaries cheaply; identity controls restrict which binaries may run at all; edge classification refuses specific behavioural relationships among allowed binaries. AppLocker without ASR lets `WINWORD` spawn PowerShell. ASR without AppLocker permits any unsigned binary to ship with the next campaign. Neither alone covers the gap. Section 7 makes the layering explicit as a comparison matrix.

The three together demonstrate that the Windows endpoint defence stack of 2017 was structurally node-classifying or identity-classifying, with no layer modelling the runtime edge. The strategic gap is the slot ASR was designed to fill.

On October 17, 2017, Microsoft shipped Windows 10 Fall Creators Update (build 1709) [@windows-blog-fall-creators-update-2017]. Six days later, the Microsoft Security Blog named the new pillar: Attack Surface Reduction [@ms-security-blog-exploit-guard-2017]. What did the first eight rules do, and how did they finally model the edge that AppLocker, EMET, and signatures could not?

4. The Evolution, Generation by Generation

October 23, 2017. The Microsoft Security Blog publishes "Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware" [@ms-security-blog-exploit-guard-2017]. The post names four pillars: Attack Surface Reduction, Network Protection, Controlled Folder Access, and Exploit Protection. The first pillar ships with eight rules. Nine years later the catalogue is nineteen rules wide. Each generation closed a specific attacker behaviour; each generation produced a published bypass within months.

flowchart TD G1["Gen 1 - Oct 2017 (1709) - 8 Office, script, email rules"] G2["Gen 2 - 2018-2019 (1803-1903) - LSASS, PSExec/WMI, prevalence, Adobe, WMI persistence"] G3["Gen 3 - Apr 2020 - Warn mode added, platform 4.18.2008.9"] G4a["Gen 4a - Dec 2021 / 2022 - BYOVD rule, Vulnerable Driver Reporting Center"] G4b["Gen 4b - Feb/Jul 2022 - Parallel layer, M365 Apps internet-macro default block"] G5["Gen 5 - 2023-2026 - Standard protection partition, Webshell, Safe Mode reboot, copied tools, USB, Outlook child-process rules"] G1 --> G2 --> G3 --> G4a --> G4b --> G5

Generation 1, October 2017 -- the eight launch rules

The launch rules, as listed verbatim in the 2017 announcement, are the Office-macro response pack [@ms-security-blog-exploit-guard-2017]:

Block Office applications from creating executable content
Block Office applications from launching child processes
Block Office applications from injecting into other processes
Block Win32 imports from macro code in Office
Block obfuscated macro code (and other obfuscated scripts, AMSI-backed)
Block JavaScript or VBScript from launching downloaded executable content
Block execution of executable content dropped from email or webmail
Block malicious JavaScript and VBScript scripts (AMSI-backed)

None of these rules solves a node-classification problem. Each rule names a single edge in the runtime process / file-system / registry graph and refuses to let it happen. "Block Office applications from creating child processes" is not "is WINWORD.EXE malicious?" but "did WINWORD.EXE just try to be the parent of another process?" The kernel answers the question with one comparison against the parent image path.

Generation 2, 2018-2019 -- credential theft, lateral movement, persistence

Between Windows 10 1803 (April 2018) and 1903 (May 2019) the catalogue expanded beyond Office to the rest of the attacker intrusion chain. Six new rules with their GUIDs, from the Microsoft Learn rules reference [@ms-learn-asr-reference]:

Block credential stealing from the Windows local security authority subsystem -- 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -- introduced 1803. The Mimikatz response: refuse process handles to lsass.exe with rights sufficient to read its address space.
Block executable files from running unless they meet a prevalence, age, or trusted list criterion -- 01443614-cd74-433a-b99e-2ecdc07bfc25 -- 1803. The unique-binary-per-campaign response, leaning on cloud-protection (MAPS) reputation.
Block process creations originating from PSExec and WMI commands -- d1e49aac-8f56-4280-b9ba-993a6d77406c -- 1803. The Emotet lateral-movement response.
Use advanced protection against ransomware -- c1db55ab-c21a-4637-bb3f-a12568109d35 -- 1803. The mass-encryption-detection response, also cloud-protection-dependent.
Block Adobe Reader from creating child processes -- 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c -- 1809. The PDF-exploit-spawning-payload response.
Block persistence through WMI event subscription -- e6db77e5-3df2-4cf1-b95a-636979351e5b -- 1903. The APT29 / Cobalt Strike __FilterToConsumerBinding response.

Each rule is a direct response to a specific attacker move. The LSASS rule answers Mimikatz. The PSExec/WMI rule answers Emotet's lateral movement. The WMI persistence rule answers permanent-implant techniques that survive reboot through the WMI repository.

The PSExec/WMI rule (d1e49aac-...) is the textbook example of an ASR rule with high enterprise friction. Microsoft Configuration Manager (formerly SCCM) relies heavily on WMI; Microsoft Learn's overview page explicitly tells administrators not to set this rule to Block or Warn without extensive Audit-mode testing if Configuration Manager manages the device, "because the Configuration Manager client relies heavily on WMI" [@ms-learn-asr-overview]. Most large estates therefore run this rule in Audit indefinitely.

Generation 3, April 2020 -- Warn mode

Until 2020, the only choices for an ASR rule were Audit (logs only) and Block (the operation fails). The middle ground was a productivity problem: a power user whose legitimate IT-automation macro was being blocked had no recourse short of a help-desk ticket. The Microsoft Defender team's "Demystifying attack surface reduction rules - Part 1" Tech Community post, modified time April 22, 2020, announced the third mode -- Warn -- with a user-facing block dialog and a 24-hour per-user per-rule per-app exclusion cache [@techcommunity-demystifying-asr-part1].

Two precision facts deserve to be stated cleanly, because both contradict secondary-source folklore.

First, the platform prerequisite for Warn mode is Microsoft Defender Antivirus platform release 4.18.2008.9 (August 2020) or later, engine release 1.1.17400.5 or later [@ms-learn-asr-overview]. The older secondary-blog claim of "4.18.2001.10 / January 2020" is contradicted by Microsoft Learn's current canonical page and should not be repeated.

Second, exactly two ASR rules deliberately skip Warn mode and go straight from Audit to Block, not five. Microsoft Learn's overview page lists them verbatim: "Block credential stealing from the Windows local security authority subsystem" and "Block Office applications from injecting code into other processes" [@ms-learn-asr-overview]. The folklore that lists five no-Warn rules (sometimes including the Webshell rule, the Safe Mode reboot rule, and the copied-tools rule) is wrong. The rules reference page enumerates Warn-mode bypass ActionType variants for the Safe Mode reboot rule (AsrSafeModeRebootWarnBypassed) and the copied-tools rule (AsrAbusedSystemToolWarnBypassed) -- direct byte-level proof that those rules do support Warn [@ms-learn-asr-reference].

flowchart LR A["Audit - Log only, no enforcement"] --> W["Warn - User can bypass for 24h"] W --> B["Block - Operation fails"] A2["LSASS rule and Office injection rule"] --> A A2 --> B

The reason these two rules skip Warn is structural, not cosmetic. A low-privilege user cannot meaningfully consent to a process opening LSASS memory; the consent dialog would itself be a credential-theft enabler. Likewise, a non-admin user cannot rationally decide whether WINWORD.EXE should be allowed to inject shellcode into explorer.exe; the request encodes its own malice. The remaining sixteen rules support the full Audit, Warn, Block ladder.

Generation 4a, December 2021 -- the BYOVD rule

The 2020-2022 era brought a new attacker move into mainstream incident response: Bring Your Own Vulnerable Driver, or BYOVD. The attacker imports a legitimate, signed, but vulnerable kernel driver, exploits its bug to gain kernel-mode primitives, uses those primitives to disable EDR and antivirus monitoring, and proceeds.

The 2021 motivating events made the threat unambiguous. Lazarus's autumn-2021 abuse of CVE-2021-21551 (Dell dbutil_2_3.sys) was the first recorded in-the-wild abuse of that driver, disclosed by ESET on September 30, 2022 [@welivesecurity-lazarus-byovd-2022] [@nvd-cve-2021-21551]. BlackByte's October 2022 abuse of CVE-2019-16098 (MSI Afterburner RTCore64.sys) was documented by Sophos with one of the year's defining lines: "disabling a whopping list of over 1,000 drivers on which security products rely to provide protection" [@sophos-blackbyte-returns-2022] [@nvd-cve-2019-16098].

An attack pattern in which the operator imports a signed but exploitable kernel driver into the victim environment, exploits a known driver vulnerability to obtain kernel-mode primitives (typically arbitrary memory read or write), and uses those primitives to disable security telemetry. CVE-2021-21551 (Dell DBUtil) and CVE-2019-16098 (MSI Afterburner) are the canonical examples; the Sophos write-up of BlackByte's RTCore64.sys abuse documents disabling roughly one thousand security-product drivers [@nvd-cve-2021-21551] [@nvd-cve-2019-16098] [@sophos-blackbyte-returns-2022].

Microsoft launched the Vulnerable and Malicious Driver Reporting Center on December 8, 2021, explicitly naming the new ASR rule as the enforcement layer alongside the kernel-load-time Vulnerable Driver Blocklist [@ms-security-blog-vulnerable-driver-center]. The ASR rule is "Block abuse of exploited vulnerable signed drivers (Device)" -- GUID 56a863a9-875e-4185-98a7-b882c64b5ce5 [@ms-learn-asr-reference]. The Windows 11 22H2 release on September 20, 2022 [@windows-blog-windows-11-2022-update] made the Microsoft Vulnerable Driver Blocklist default-on for all devices, which is the kernel-load-time sibling to the ASR write-time block [@ms-learn-driver-block-rules].

Generation 4b, February and July 2022 -- the parallel layer

This is the generation that deserves the most honest framing in the article, because the marketing version oversimplifies what actually happened to Office macros.

Tom Gallagher's February 7, 2022 Microsoft 365 Blog post announces the default block of VBA macros in MOTW-internet documents [@ms-techcommunity-internet-macros-2022]. The trust bar removes the "Enable Content" button entirely. Microsoft pauses the rollout on July 8, 2022 for usability adjustments, then resumes on July 20, 2022 -- both dates verifiable from the post's article:modified_time metadata. ESET's June 2022 write-up confirms the intended effect: between April 26 and May 2, 2022 Emotet operators were already testing LNK and ISO replacements for the macro carrier [@welivesecurity-emotet-pivot-2022].

A wide range of threat actors continue to target our customers by sending documents and luring them into enabling malicious macro code. -- Tom Gallagher, Partner Group Engineering Manager, Office Security, February 7, 2022 [@ms-techcommunity-internet-macros-2022]

The Microsoft 365 Apps default block is not a generation of ASR. It is a parallel layer that ships inside Office, runs against every Microsoft 365 Apps installation managed or unmanaged, and uses the MOTW as its trigger rather than the kernel-mode minifilter. It cooperates with ASR; it does not subsume ASR.

The popular "ASR stopped Office macros" claim is half right. The Office-macro era ended through three layers in combination: (1) Europol's Operation LadyBird on January 27, 2021, coordinated international takedown of Emotet's command-and-control infrastructure [@europol-emotet-disrupted-wayback]; (2) ASR's 2017-onward Office rules at the enterprise tier, managed through Intune, Group Policy, or Defender for Endpoint; (3) the Microsoft 365 Apps internet-macro default block at the consumer and tenant tier, default-on for every Microsoft 365 installation since the July 2022 staged rollout [@ms-techcommunity-internet-macros-2022]. ASR is the enterprise-managed layer; it was not the only layer. The polished version of the story names all three.

A coincidence worth noting: Europol's Operation LadyBird seized Emotet's command-and-control infrastructure on January 27, 2021 [@europol-emotet-disrupted-wayback]. SANS Internet Storm Center Diary 27036, published the same day by handler Daniel Wesemann, documented the canonical WMI-grandparent bypass to the Office-child-process ASR rule [@sans-isc-27036-emotet-asr]. A takedown and a bypass landed on the same Wednesday.

Generation 5, 2023-2026 -- Standard protection and the long tail

By 2023 Microsoft had enough deployment telemetry to partition the rules into two categories. The Standard protection rules are the three with a low false-positive floor, safe to enable in Block mode without staged rollout: BYOVD, LSASS credential-theft, and WMI persistence [@ms-learn-asr-overview]. The remaining sixteen are Other ASR rules and require the full Audit, Warn, Block ladder. Several new rules landed in this period [@ms-learn-asr-reference]:

Block Webshell creation for Servers -- a8f5898e-1dc8-49a9-9878-85004b8a61e6 -- the post-HAFNIUM / ProxyShell response. This is the only rule in the catalogue whose row in the Microsoft Learn reference shows "N" for EDR alerts, meaning it does not emit a paired Audited and Blocked ActionType in DeviceEvents. Defenders hunt blocked webshell drops through MpCmdRun.log and IIS access logs, not Advanced Hunting.
Block rebooting machine in Safe Mode -- 33ddedf1-c6e0-47cb-833e-de6133960387 -- the BlackByte-era safe-mode-encryption response.
Block use of copied or impersonated system tools -- c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb -- the rename-and-relocate evasion response (attackers copying cmd.exe to a writable path and renaming it update.exe).
Block untrusted and unsigned processes that run from USB -- b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4 -- the BadUSB / removable-media response.
Block Office communication application from creating child processes -- 26190899-1602-49e8-8b27-eb1d0a1ce869 -- the Outlook variant of the Office-child-process rule.

The three ASR rules Microsoft classifies as safe to enable in Block mode without staged rollout: Block abuse of exploited vulnerable signed drivers, Block credential stealing from the Windows local security authority subsystem, and Block persistence through WMI event subscription. The classification appears verbatim on the ASR rules overview page [@ms-learn-asr-overview]. The LSASS rule is redundant when LSA Protection is enabled; the WMI persistence rule still requires Audit testing if Microsoft Configuration Manager manages the device.

The catalogue stands at 19 rules as of May 2026 -- three Standard protection rules and sixteen Other ASR rules, the count inclusive of the server-only Webshell rule that does not emit DeviceEvents [@ms-learn-asr-reference]. The pattern is consistent enough that the next section gives it a name.

5. Edges, Not Nodes

The structural pivot the whole article rests on can be written in one sentence: signatures classify nodes; AppLocker classifies identities; ASR classifies edges in the runtime graph. The rest of this section unpacks what that means and why it matters.

A node in the runtime graph is a binary or a file -- the kind of thing static analysis can fingerprint. An edge is a runtime relationship between two nodes: process A creating process B, process A writing file F, process A opening a handle to LSASS memory, the WMI repository writing a new __FilterToConsumerBinding. Signatures answer "is this node bad?" -- undecidable in general per Cohen 1984 [@cohen-1984-part1]. AppLocker answers "is this node's identity on the allow-list?" -- decidable but blind to LOLBin chains [@lolbas-project]. ASR answers "did this specific edge happen?" -- decidable per event at the OS interception layer.

The Cohen sidestep is precise. Cohen 1984 proved that classifying nodes ("is this program malicious?") is undecidable in general, via a reduction to the Halting Problem. He did not prove that classifying runtime edges is undecidable, because "did this specific parent-child invocation just happen?" is an observable proposition. The kernel sees the system call. The decision is local. No static analysis is required. ASR is the canonical industrial instantiation of that insight; every generation in Section 4 is a catalogue extension within the edge-classification approach, not a structural reframing of it.

Key idea: Signatures classify nodes. AppLocker classifies identities. ASR classifies edges in the runtime graph. By moving from node classification to edge classification, Microsoft sidesteps Cohen-1984 undecidability in the practical sense: you do not need to decide whether the binary is malicious, only whether the edge happened. The kernel sees the edge.

Where does the enforcement actually live? The "kernel-mediated" framing earns its phrasing in three precise pieces.

First, WdFilter.sys is the Microsoft Defender Antivirus minifilter driver.An altitude, in Windows Filter Manager terminology, is a 32-bit decimal that determines the order in which file-system minifilters see I/O. Higher altitudes see I/O first on the way down to the file system and last on the way back up. Anti-virus drivers live in the 320000-329998 band. It is registered with the Windows Filter Manager in the FSFilter Anti-Virus altitude band (320000-329998), specifically at altitude 328010 per Microsoft's IFS allocated-altitudes reference [@ms-learn-ifs-allocated-altitudes]. It runs in kernel mode and intercepts process-creation, image-load, file-write, and (for some rules) WMI and registry edges through Filter Manager pre-operation callbacks and process / image-load notify routines.

The Microsoft Defender Antivirus minifilter driver. Registered with the Windows Filter Manager at altitude 328010 in the FSFilter Anti-Virus band (320000-329998) per Microsoft's allocated-altitudes reference [@ms-learn-ifs-allocated-altitudes]. It runs in kernel mode and hosts the interception callbacks that ASR uses to see process-creation, image-load, and file-write edges before the user-mode actor completes the operation.

Second, MsMpEng.exe is the Defender Antivirus service process. It runs in user mode at integrity level System. For every intercepted edge it consults the per-rule predicate, the per-rule exclusion list, and (for cloud-protected rules) the Microsoft Active Protection Service reputation, then returns Audit, Warn, or Block. The kernel/user-mode split is structural, not accidental. Interception must happen in the kernel before the user-mode actor completes the call. But exclusion-list lookup and cloud reputation are not appropriate inside a minifilter that holds the IRP open.

The Microsoft Defender Antivirus service process. Runs in user mode at integrity level System and hosts the policy-evaluation engine that decides Audit, Warn, or Block for every edge intercepted by `WdFilter.sys`. The two together form the kernel-mediated, user-mode-evaluated enforcement architecture that ASR relies on.

Third, telemetry. ASR blocks land in Defender for Endpoint's DeviceEvents Advanced Hunting table with a rule-specific ActionType such as AsrOfficeChildProcessBlocked or AsrLsassCredentialTheftBlocked. The rules reference enumerates a paired Audited and Blocked ActionType for every rule except the Webshell rule, which is the only one without a DeviceEvents row [@ms-learn-asr-reference]. The universal hunting query is DeviceEvents | where ActionType startswith "Asr". The generic AsrRuleTriggered is folk wisdom; it has never existed.

Microsoft Defender for Endpoint's Kusto Query Language (KQL) surface over endpoint telemetry. ASR blocks and audit events land in the `DeviceEvents` table with rule-specific `ActionType` values. Defenders combine `DeviceEvents` with `DeviceProcessEvents`, `DeviceFileEvents`, and `DeviceImageLoadEvents` to assemble the corroborating edge data around any ASR row [@ms-learn-asr-reference]. flowchart LR P["User-mode process
WINWORD.EXE"] -->|"CreateProcessW"| K["Windows kernel
process-creation notify"] K --> WD["WdFilter.sys
kernel-mode minifilter
altitude 328010"] WD -->|"edge event"| MP["MsMpEng.exe
user-mode service
rule predicate + exclusions + MAPS"] MP -->|"Audit / Warn / Block"| WD WD -->|"fail or allow CreateProcessW"| P MP -->|"telemetry"| DE["DeviceEvents
ActionType = AsrOfficeChildProcessBlocked"] A common misconception is "ASR runs in the kernel." That is partially true and structurally incomplete. The interception point is kernel-mode; the policy evaluation is user-mode. Both are necessary. The kernel must see the edge before the user-mode actor completes the operation, but the cloud reputation lookup and the per-rule exclusion list are not appropriate to run inside a minifilter that holds the IRP open. The correct one-line framing is "kernel-mediated interception, user-mode policy evaluation."

The marginal performance cost of an ASR check is bounded by the existing WdFilter.sys callout that already runs for real-time scanning. ASR piggybacks on callouts the antivirus engine has already paid for. Microsoft has not published a number isolating ASR per-event overhead from broader minifilter cost; the IFS allocated-altitudes page is the closest published reference [@ms-learn-ifs-allocated-altitudes]. The sub-microsecond-per-event framing is INFERRED from the architecture, not measured.

"Protection from denial of services requires the detection of halting programs which is well known to be undecidable." -- Fred Cohen, "Computer Viruses: Theory and Experiments," 1984 [@cohen-1984-part1]

The framework now in place is "name a behaviour class, ship an enforcement edge." Nine years and seven generations of catalogue extension have followed that single rule. So what does the catalogue look like in detail today? The next section is the reference table: nineteen rules, organised by category, with GUID, ActionType, and the attacker behaviour each one closes.

6. The Nineteen Rules in Detail

This section is the article's reference table. Not a deployment guide (that comes in Section 10), but a catalogue to return to when you need to remember which GUID maps to which behaviour and which ActionType lands in DeviceEvents. Every row is from Microsoft Learn's rules reference page [@ms-learn-asr-reference].

Standard protection rules (3 rules)

Microsoft itself recommends enabling these three in Block mode without staged rollout, because their false-positive floor is low [@ms-learn-asr-overview].

Short name	GUID	ActionType (Blocked)	Notes
Block abuse of exploited vulnerable signed drivers	`56a863a9-875e-4185-98a7-b882c64b5ce5`	`AsrVulnerableSignedDriverBlocked`	The BYOVD response; pairs with the kernel-load-time Vulnerable Driver Blocklist [@ms-learn-driver-block-rules]
Block credential stealing from the Windows local security authority subsystem	`9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2`	`AsrLsassCredentialTheftBlocked`	Redundant when LSA Protection is enabled [@ms-learn-asr-overview]
Block persistence through WMI event subscription	`e6db77e5-3df2-4cf1-b95a-636979351e5b`	`AsrPersistenceThroughWmiBlocked`	Still requires Audit testing if Configuration Manager manages the device

Productivity apps (6 rules)

The Office and Adobe response pack, anchored by the Office-child-process rule that opens this article.

Short name	GUID	ActionType (Blocked)	Notes
Block all Office applications from creating child processes	`d4f940ab-401b-4efc-aadc-ad5f3c50688a`	`AsrOfficeChildProcessBlocked`	The macro-to-PowerShell stopper
Block Office applications from creating executable content	`3b576869-a4ec-4529-8536-b80a7769e899`	`AsrExecutableOfficeContentBlocked`	Blocks dropped EXEs from Office processes
Block Office applications from injecting code into other processes	`75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84`	`AsrOfficeProcessInjectionBlocked`	No Warn-mode support [@ms-learn-asr-overview]
Block Win32 API calls from Office macros	`92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b`	`AsrOfficeMacroWin32ApiCallsBlocked`	Refuses `Declare` statements that bind to native DLLs
Block Office communication application from creating child processes	`26190899-1602-49e8-8b27-eb1d0a1ce869`	`AsrOfficeCommAppChildProcessBlocked`	The Outlook variant
Block Adobe Reader from creating child processes	`7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c`	`AsrAdobeReaderChildProcessBlocked`	The PDF response

Scripts and email (3 rules)

The AMSI-backed script-content rules plus the email-drop-execution rule.

Short name	GUID	ActionType (Blocked)	Notes
Block execution of potentially obfuscated scripts	`5beb7efe-fd9a-4556-801d-275e5ffc04cc`	`AsrObfuscatedScriptBlocked`	AMSI-backed
Block JavaScript or VBScript from launching downloaded executable content	`d3e037e1-3eb8-44c8-a917-57927947596d`	`AsrScriptExecutableDownloadBlocked`	The drive-by-download response
Block executable content from email client and webmail	`be9ba2d9-53ea-4cdc-84e5-9b1eeee46550`	`AsrExecutableEmailContentBlocked`	Catches the dropped-attachment-run pattern

Lateral movement and prevalence (4 rules)

The cloud-protected, prevalence-based rules plus the Emotet lateral-movement responses.

Short name	GUID	ActionType (Blocked)	Notes
Block process creations originating from PSExec and WMI commands	`d1e49aac-8f56-4280-b9ba-993a6d77406c`	`AsrPsexecWmiChildProcessBlocked`	Conflicts with Configuration Manager [@ms-learn-asr-overview]
Block executable files from running unless they meet a prevalence, age, or trusted list criterion	`01443614-cd74-433a-b99e-2ecdc07bfc25`	`AsrUntrustedExecutableBlocked`	Requires cloud protection (MAPS)
Block untrusted and unsigned processes that run from USB	`b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4`	`AsrUntrustedUsbProcessBlocked`	The BadUSB response
Use advanced protection against ransomware	`c1db55ab-c21a-4637-bb3f-a12568109d35`	`AsrRansomwareBlocked`	Requires cloud protection

Server, system-tool, and safe-mode (3 rules)

The post-2022 additions.

Short name	GUID	ActionType (Blocked)	Notes
Block Webshell creation for Servers	`a8f5898e-1dc8-49a9-9878-85004b8a61e6`	(no DeviceEvents pair)	Only rule without a `DeviceEvents` ActionType [@ms-learn-asr-reference]
Block rebooting machine in Safe Mode	`33ddedf1-c6e0-47cb-833e-de6133960387`	`AsrSafeModeRebootBlocked`	Also emits `AsrSafeModeRebootWarnBypassed` -- proof Warn is supported
Block use of copied or impersonated system tools	`c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb`	`AsrAbusedSystemToolBlocked`	Also emits `AsrAbusedSystemToolWarnBypassed` -- proof Warn is supported

Total: 19 rules. Older blog posts that cite "16 rules" or "17 rules" reflect a 2021-2023 snapshot of the catalogue before the Safe Mode, copied-tools, USB, and Outlook variants landed.

The per-rule MITRE crosswalk

MITRE ATT&CK's Behavior Prevention on Endpoint mitigation (M1040) nominates ASR rules by name for several technique families. The first eight rows below are verbatim nominations from the M1040 page; the last two (T1505.003 and T1562.009) are this article's own mappings from rule semantics to the most-natural MITRE technique, because M1040 itself does not enumerate the Webshell or Safe Mode Boot techniques [@mitre-m1040]:

MITRE technique	ASR rule that covers it
T1059.005 / T1059.007 (Command and Scripting Interpreter: Visual Basic / JavaScript)	Block JavaScript or VBScript from launching downloaded executable content; Block execution of potentially obfuscated scripts
T1543 / T1543.003 (Create or Modify System Process / Windows Service)	Block abuse of exploited vulnerable signed drivers
T1486 (Data Encrypted for Impact)	Use advanced protection against ransomware
T1546.003 (Event Triggered Execution: WMI Event Subscription)	Block persistence through WMI event subscription
T1559 / T1559.002 (Inter-Process Communication: Dynamic Data Exchange)	Block all Office applications from creating child processes
T1106 (Native API)	Block Win32 API calls from Office macros
T1027 / T1027.009 / T1027.010 (Obfuscated Files or Information)	Block execution of potentially obfuscated scripts
T1003.001 (LSASS Memory)	Block credential stealing from the Windows local security authority subsystem
T1505.003 (Server Software Component: Web Shell) -- author mapping, not M1040-nominated	Block Webshell creation for Servers
T1562.009 (Impair Defenses: Safe Mode Boot) -- author mapping, not M1040-nominated	Block rebooting machine in Safe Mode

The crosswalk gives a defender the per-technique coverage map without leaving the article.

Note: Recall from Section 1: every rule emits a rule-specific Asr<RuleName>Audited and Asr<RuleName>Blocked pair (the Webshell rule excepted), and the canonical universal Advanced Hunting filter is where ActionType startswith "Asr" [@ms-learn-asr-reference].

The Webshell rule's missing DeviceEvents ActionType is the most visible gap in the catalogue's telemetry surface. Defenders typically use Sysmon Event ID 11 (FileCreate) in web roots and IIS access logs to corroborate blocked webshell creations on servers; the Microsoft Learn rules reference is explicit that the EDR-alerts column for this rule is "N" [@ms-learn-asr-reference].

The universal Advanced Hunting query, demonstrated below in a runnable JavaScript shape so a reader can verify the aggregation logic without a Defender for Endpoint tenant, is the single most useful starting point for any ASR investigation.

{` // Mocked DeviceEvents rows. Replace with output of: // DeviceEvents | where ActionType startswith "Asr" // | summarize count() by ActionType, DeviceName | order by count_ desc const deviceEvents = [ { DeviceName: "WS-FIN-042", ActionType: "AsrOfficeChildProcessBlocked" }, { DeviceName: "WS-FIN-042", ActionType: "AsrOfficeChildProcessBlocked" }, { DeviceName: "WS-FIN-118", ActionType: "AsrOfficeChildProcessAudited" }, { DeviceName: "WS-ENG-003", ActionType: "AsrLsassCredentialTheftBlocked" }, { DeviceName: "WS-FIN-042", ActionType: "AsrPsexecWmiChildProcessAudited" }, { DeviceName: "WS-FIN-118", ActionType: "AsrVulnerableSignedDriverBlocked" }, { DeviceName: "OTHER", ActionType: "DeviceLogon" }, // filtered out ];

const asrRows = deviceEvents.filter(r => r.ActionType.startsWith("Asr"));

const counts = asrRows.reduce((m, r) => { const key = r.ActionType + " | " + r.DeviceName; m[key] = (m[key] || 0) + 1; return m; }, {});

Object.entries(counts) .sort((a, b) => b[1] - a[1]) .forEach(([key, n]) => console.log(n + "\t" + key)); `}

Nineteen rules. Three categories. One catalogue that has grown by twelve rules in nine years and shows no sign of stopping. But ASR is not the only behaviour-blocking layer on the Windows endpoint. How does the catalogue compare to CrowdStrike's Indicators of Attack, SentinelOne's Storyline, App Control for Business, Sysmon, and the rest?

7. Where ASR Sits Among the Behaviour Layers

ASR is one of seven currently-deployed methods for behavioural defence on the Windows endpoint. None of them obsoletes any of the others; they layer. Counting the strengths honestly means counting the weaknesses too.

App Control for Business, AppLocker, WDAC

Identity classification. App Control for Business and its predecessor AppLocker are stricter than ASR on the identity axis (default-deny when tuned) but blind to behaviour edges among allowed binaries [@ms-learn-applocker]. The Vulnerable Driver Blocklist that ships default-on with Windows 11 22H2 is the kernel-load-time sibling to ASR's BYOVD rule and works against the same class of attack from the kernel side rather than the user side [@ms-learn-driver-block-rules]. App Control and ASR are complementary, not competing.

CrowdStrike Falcon Behavioral Indicators of Attack

Cloud-evaluated edge classifier. CrowdStrike's own one-line definition of IOAs is the cleanest a vendor has published [@crowdstrike-ioa-definition]: "telltale signs or activities that signal a potential cybersecurity threat or attack is in progress. ... They aim to identify and mitigate a threat before it can fully materialize." The trade-offs cut both ways. CrowdStrike pushes new IOA rules from the cloud without an OS update -- real adaptivity. The cost: no public reference catalogue (every IOA is vendor-internal), a cloud dependency for some configurations, and a commercial licence. ASR is free; CrowdStrike is not.

SentinelOne Singularity Storyline, ActiveEDR

On-agent behavioural-AI engine with per-host storyline graph correlation and a STAR custom-rule layer. SentinelOne's product-level marketing pages return JavaScript-rendered shells or HTTP 404s to text-only fetchers, so byte-precision verification for specific features is currently unavailable. The model-level description (on-agent graph correlation that works offline) is well-attested in the secondary literature. The trade-offs mirror CrowdStrike's: vendor-internal classifier, no public catalogue, commercial licence. This article keeps the framing at the model level and avoids specific feature or performance claims.

Note: The SentinelOne canonical product URLs are HTTP 404 or JavaScript-rendered shells with no byte-extractable text. The model-level claim (on-agent behavioural-AI graph correlation, STAR custom-rule layer, designed offline) is well-attested in the secondary literature; no specific feature claim has a single byte-verified URL behind it in this iteration.

Microsoft 365 Apps internet-macro default block

The Office-internal parallel layer that ended the macro era for unmanaged tenants [@ms-learn-internet-macros-blocked] [@ms-techcommunity-internet-macros-2022]. Office-only and macro-only; covers neither DDE, OLE, embedded executables, nor non-VBA Office attack chains. ASR remains the layer that catches the corresponding edge if the macro layer is bypassed by a managed-tenant override or by a non-macro initial-access vector.

Sysmon and custom SIEM rules

High-fidelity edge visibility; no enforcement. Practitioners run Sysmon alongside ASR for audit-trail coverage of edges ASR does not block and for corroborating telemetry around edges it does. Note that MITRE M1042 ("Disable or Remove Feature or Program") does not mention Sysmon or ASR by name [@mitre-m1042]; the Sysmon-with-ASR pairing is practitioner consensus rather than an M1042 nomination. M1040 (Behavior Prevention on Endpoint) is the mitigation that names ASR rules verbatim [@mitre-m1040].

EDR-in-block-mode

The sibling post-event automated-response layer to ASR, not an umbrella over it. EDR-in-block-mode is required for passive-AV configurations where Defender Antivirus is not the primary. Microsoft Learn's EDR-in-block-mode page is unambiguous about the dependency: "Features like network protection and attack surface reduction (ASR) rules and indicators ... are only available when Microsoft Defender Antivirus is running in Active mode" [@ms-learn-edr-in-block-mode]. EDR-in-block-mode acts strictly post-event on EDR detections; ASR acts pre-completion on the operation itself. Different points in the timeline.

A common misframing places EDR-in-block-mode as the umbrella feature that "covers" ASR. The Microsoft Learn page contradicts that reading directly. EDR-in-block-mode is the layer that lets Defender for Endpoint block based on its EDR findings even when a third-party AV is primary; ASR is the layer that intercepts the operation at the minifilter before any other component sees it. They are siblings, not parent and child [@ms-learn-edr-in-block-mode].

The comparison matrix

The seven methods on ten axes. Read this as a trade-off space; no row dominates the others on every axis.

Method	Classification axis	Enforcement substrate	Catalogue inspectability	Cost	Cloud-connectivity required	OS coverage	Best suited for
ASR rules	Edge	Kernel-mode minifilter + user-mode service	Fully public per-rule [@ms-learn-asr-reference]	Free with Windows	No (some rules require MAPS)	Windows 10 1709+, Windows 11, Windows Server	Behaviour-edge defence; macro chains; LSASS; BYOVD
M365 Apps internet-macro block	Document-trust	Office process	Public docs [@ms-learn-internet-macros-blocked]	Free with M365	No	Microsoft 365 Apps	Internet-marked Office macros
App Control + Vulnerable Driver Blocklist	Identity + driver hash	Kernel	Public policy XML / Block rules [@ms-learn-driver-block-rules]	Free with Windows	No	Windows 10+, Server	Default-deny; kernel-load-time BYOVD
CrowdStrike Falcon IOAs	Edge	Agent + cloud	Vendor-internal [@crowdstrike-ioa-definition]	Commercial	Yes (some)	Cross-platform	Adaptive cloud-pushed behavioural detection
SentinelOne Storyline	Edge graph	On-agent	Vendor-internal	Commercial	No (designed offline)	Cross-platform	Per-host graph correlation
Sysmon + SIEM	Visibility only	User-mode (Sysmon) + SIEM	Public events; SIEM rules per-tenant	Sysmon free; SIEM commercial	Yes (SIEM)	Windows 7+, Linux	Audit trail; corroboration
EDR-in-block-mode	Post-detection block	MDE service	MDE-managed	Defender for Endpoint licence	Yes	Windows 10+, Server	Passive-AV configurations

AV-Comparatives' Endpoint Prevention and Response Test 2023 evaluated 12 EPR products against 50 multi-stage targeted-attack scenarios across three phases -- Endpoint Compromise and Foothold, Internal Propagation, Asset Breach -- over June through September 2023 [@av-comparatives-epr-2023]. Per-product scoring is paywalled and is not reproduced here; only the methodology is cited as the cross-vendor backdrop against which any "ASR vs the rest" empirical claim has to be measured. The article makes no specific scoring claim against AV-Comparatives data because the scoring is not publicly extractable from the free summary.

Each row in the matrix names a different trade-off. ASR is the only row that is free, kernel-mediated, fully inspectable, and shipped with every Windows edition that includes Defender Antivirus. But the catalogue is finite. And the attacker's degrees of freedom are not. What does the theory say about the gap?

8. What No Behaviour Block List Can Do

Every defence layer has a lower bound. ASR's is Cohen 1984 -- but indirectly, through the structural floor that every edge predicate inherits.

Cohen's 1984 result (introduced in Section 3 as a Definition with its diagonal-construction proof sketch and Rice-1953 corollary) proves that detection of arbitrary viral behaviour in a program reduces to the Halting Problem and is therefore undecidable in general [@cohen-1984-part1]. ASR sidesteps the result by changing the question. Not "is this program malicious?" -- undecidable in general -- but "did this specific edge in the runtime graph just occur?" -- decidable per event at the OS interception layer. The Cohen ceiling does not directly forbid edge classification; it forbids node classification. Edge classification is decidable per edge.

The cost is two structural floors that any behaviour-block list inherits.

The over-approximation floor. Every edge predicate is itself an over-approximation of "is this edge malicious." Legitimate IT-automation Word macros do legitimately spawn PowerShell. Legitimate backup software does legitimately read LSASS memory (WerFaultSecure.exe appears on extracted LSASS-rule exclusion lists per Adam Svoboda's VDM-extraction technique [@adamsvoboda-asr-exclusions]). Legitimate management software does legitimately write driver files. Every ASR rule therefore has a structural false-positive floor; the per-rule exclusion list is the recovery mechanism. Exclusion lists trade safety for compatibility.

The catalogue-finiteness upper bound. The space of possible attack edges is countably infinite. Any composition of CreateProcess, WriteFile, RegSetValue, WMI subscription, scheduled task, COM IDispatch::Invoke, or driver-load can be chained into a new edge sequence. The catalogue is finite -- nineteen rules in May 2026 [@ms-learn-asr-reference]. The bound is sharp: an attacker whose chain crosses any edge e in the catalogue is detected at e; an attacker whose chain avoids every edge in the catalogue is not.

Key idea: ASR compresses bypass cost; it does not eliminate it. The catalogue is finite. The attacker's space of edges is countably infinite. Behaviour-block lists are incomplete by construction -- and that is not a defect; it is the design philosophy. The defender's job is not to fix the incompleteness but to make every cheap attack chain expensive enough that the attacker stops using it.

The empirical evidence for the catalogue-finiteness bound is the bypass-research cluster. SANS ISC Diary 27036 (Daniel Wesemann, January 27, 2021) documents the WMI-grandparent bypass to the Office-child-process rule [@sans-isc-27036-emotet-asr]. Sevagas / Emeric Nasi's "Bypass Windows Defender Attack Surface Reduction" PDF (2021) documents COM-object-indirection bypasses [@sevagas-asr-bypass]. Primusinterp's "Cheesing Microsoft Attack Surface Reduction rules" enumerates chained-COM bypasses against the 2017-era catalogue [@primusinterp-cheesing-asr]. Adam Svoboda's VDM-extraction technique enumerates the exclusion lists themselves [@adamsvoboda-asr-exclusions]. None of these is a defect Microsoft has been slow to fix. All are structural consequences of the catalogue-finiteness bound.

The proof in Cohen's open-access archive reduces virus detection to the Halting Problem; the 1984 DoD/NBS conference paper is the original presentation; the 1987 *Computers and Security* reprint is the canonical citable journal form. The open-access archive at all.net is the byte-verifiable text; the verbatim sentence "Protection from denial of services requires the detection of halting programs which is well known to be undecidable" is on the first page of Part 1 [@cohen-1984-part1]. The line is the closest one-sentence statement of the structural ceiling that any node-classifying malware detector inherits.

ASR's design philosophy is not to achieve the theoretical optimum of "complete, sound, real-time, false-positive-free edge catalogue" (unachievable for the reasons above). It is to compress the attacker's bypass cost -- to force the attacker off the cheap, common attack chains (WINWORD -> cmd -> PowerShell) onto more expensive ones (WMI grandparent, COM indirection, scheduled-task fan-out, exclusion-list enumeration, BYOVD). The Section 11 FAQ entry that picks up this thread makes it explicit.

A finite catalogue, an unbounded attacker space, and a structural floor under each rule. The next section names the open problems that follow.

9. What Is Still Moving

The bypass-research corpus around ASR is not a temporary embarrassment. It is the permanent shape of every catalogue-based defence. Six open problems define the layer's research frontier as of May 2026.

Problem 1 -- The WMI and COM grandparent bypass class

The canonical bypass is documented in SANS Internet Storm Center Diary 27036, published January 27, 2021 by handler Daniel Wesemann [@sans-isc-27036-emotet-asr]. Emotet's VBA invoked Win32_Process.Create via WMI, so WmiPrvSE.exe became the literal parent of cmd.exe; the Office-child-process rule's predicate is byte-literal (it checks the immediate parent image against the Office binary list) and therefore never fires.

sequenceDiagram participant VBA as VBA macro in WINWORD.EXE participant WMI as WmiPrvSE.exe (svchost host) participant CMD as cmd.exe participant WD as WdFilter.sys participant MP as MsMpEng.exe VBA->>WMI: GetObject winmgmts, Win32_Process.Create WMI->>WD: process-create notify, parent = WmiPrvSE WD->>MP: edge event, parent image WmiPrvSE.exe MP-->>WD: rule D4F940AB predicate false, no Office parent WD-->>WMI: allow CreateProcess WMI->>CMD: spawn cmd.exe 'cmd' is not a child process of Word, and the ASR block rule to prevent child processes of Word consequently doesn't trigger. -- Daniel Wesemann, SANS ISC Diary 27036, January 27, 2021 [@sans-isc-27036-emotet-asr]

The PSExec/WMI rule (d1e49aac-...) was added in Windows 10 1803 to catch the most common variant, but Microsoft Learn warns that it conflicts with Configuration Manager [@ms-learn-asr-overview]. COM-object indirection (MMC.Application, Outlook.Application, ShellWindows) generalises the bypass beyond WMI [@sevagas-asr-bypass] [@primusinterp-cheesing-asr]. No ASR rule today covers transitive-parent classification across COM or scheduled-task fan-out without breaking Configuration Manager dependencies. The open question is whether a transitive-parent predicate can be added without breaking SCCM, and what false-positive rate that costs.

Problem 2 -- Event 5007 and exclusion-list enumeration

Adam Svoboda's technique demonstrates that ASR exclusion lists live in Defender VDM containers (mpasbase.vdm, mpasdlta.vdm) and are extractable with wdextract64.exe [@adamsvoboda-asr-exclusions]. A low-privilege user with read access to C:\ProgramData\Microsoft\Windows Defender\Definition Updates\ can enumerate the whitelisted paths the LSASS rule, the BYOVD rule, and other rules carry by default. Tamper Protection prevents runtime modification of the exclusion list but does not prevent read access [@ms-learn-tamper-protection]. Once the exclusion list is enumerated, the per-rule defence becomes "did the attacker drop the payload in a writable whitelisted path?" -- a deployment-quality question, not a structural one. The open problem is whether the exclusion lists should be encrypted at rest with a key not derivable by an unprivileged process.

Problem 3 -- Catalogue completeness against modern initial-access vectors

Emotet's post-2022 pivot to OneNote embedded scripts, HTML smuggling, ISO and IMG containers (which strip MOTW on extraction), LNK files, and 7z archives is not covered by ASR's existing rules [@welivesecurity-emotet-pivot-2022]. SmartScreen, Network Protection, and the Microsoft 365 Apps internet-macro default block cover some of this surface, but not via ASR's edge-predicate model. The open question is whether the ASR catalogue should grow to cover OneNote-spawns-child, or whether the right answer is to rely on the parallel layers and accept that ASR's coverage of OneNote-era initial-access is partial.

Problem 4 -- The Webshell rule's missing telemetry surface

Per the Microsoft Learn rules reference, "Block Webshell creation for Servers" (a8f5898e-...) is the only rule without a DeviceEvents ActionType pair [@ms-learn-asr-reference]. Defenders cannot KQL-hunt for blocked Webshell creations the way they can for every other rule; visibility lives in MpCmdRun.log and IIS access logs. The open question is when Microsoft will add the missing ActionType so that the Webshell rule's audit-and-block events become uniformly queryable in Advanced Hunting.

Problem 5 -- Tamper Protection versus kernel-level attackers

ASR is enforced by WdFilter.sys running at integrity level System, but a kernel-mode attacker (for example, one with a BYOVD-loaded malicious driver) is a peer. BlackByte's 2022 BYOVD campaigns demonstrated the pattern: load a vulnerable signed driver, disable Defender's notify routines, proceed [@sophos-blackbyte-returns-2022]. The ASR BYOVD rule (56a863a9-...) plus the WDAC Vulnerable Driver Blocklist default-on in Windows 11 22H2 [@ms-learn-driver-block-rules] plus Hypervisor-protected Code Integrity each close a sub-class. None closes the full class, because the driver-block-list is update-cadence-bounded. The open question is whether WdFilter.sys can be moved into a Virtualization-Based Security isolated enclave such that even a kernel-compromise primitive cannot tamper with ASR enforcement.

Problem 6 -- The inspectability dual

ASR's structural floor is catalogue finiteness. The structural floor of its SOTA competitors (CrowdStrike AI-powered IOAs, SentinelOne Storyline) is vendor-internal inspectability. When an AI-powered IOA fires, the defender has no rule GUID to look up, no published predicate to reason about, no per-edge auditability for purple-team coverage assessment. The two bounds are complementary: ASR optimises for inspectability at the cost of catalogue-growth lag; the AI-powered competitors optimise for adaptive classifier coverage at the cost of inspectability. A complete edge-classification SOTA layer would combine both. No single product currently does.

Note: The Outflank ASR-bypass blog corpus is a well-known research-cluster member; live URLs returned HTTP 403 (Cloudflare) and Wayback Machine fallbacks were unreachable from the verification environment. Named honestly here without inventing a URL. The bypass cluster's claims are independently supported by SANS ISC [@sans-isc-27036-emotet-asr], Sevagas [@sevagas-asr-bypass], Primusinterp [@primusinterp-cheesing-asr], and Adam Svoboda [@adamsvoboda-asr-exclusions].

The catalogue is incomplete by construction. The defender's job is not to fix the incompleteness; it is to make every cheap attack chain too expensive to use. Section 10 codifies that into a Monday-morning playbook.

10. How to Actually Use This on Monday

Five steps. Source-control everything. Treat ASR not as a replacement for AppLocker, App Control for Business, or your EDR -- treat it as a kernel-mediated, free, behaviour-edge layer that costs almost nothing once tuned.

Step 1 -- Enable the three Standard protection rules in Block mode first

Microsoft itself classifies these three as low-false-positive-floor [@ms-learn-asr-overview]:

Block abuse of exploited vulnerable signed drivers (Device) -- 56a863a9-875e-4185-98a7-b882c64b5ce5.
Block credential stealing from the Windows local security authority subsystem -- 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2. Note: if LSA Protection is enabled on the device (recommended together with Credential Guard), Microsoft Learn states verbatim that "this rule is redundant" and Defender will show the rule as "not applicable" [@ms-learn-asr-overview].
Block persistence through WMI event subscription -- e6db77e5-3df2-4cf1-b95a-636979351e5b. Even though this rule is in the Standard set, Microsoft Learn recommends extensive Audit-mode testing if Configuration Manager manages the device, "because the Configuration Manager client relies heavily on WMI" [@ms-learn-asr-overview].

Step 2 -- Move the other sixteen rules through Audit, Warn, Block

The canonical deployment ladder is enumerated in the implementation guide on Microsoft Learn: start every rule in Audit, watch DeviceEvents for false positives, transition to Warn (or Block where Warn is unsupported), then transition to Block once the false-positive rate is acceptable in your first deployment ring [@ms-learn-asr-deployment-implement]. Two rules skip Warn entirely and go Audit straight to Block: Block credential stealing from LSASS and Block Office applications from injecting code into other processes [@ms-learn-asr-overview]. The other fourteen Other ASR rules support the full three-step ladder.

Step 3 -- Hunt with the universal query

DeviceEvents | where ActionType startswith "Asr" returns every Audit and Block emission across the fleet. Pair with DeviceProcessEvents and DeviceFileEvents for the corroborating edge data; the Section 6 RunnableCode block demonstrates the shape. For the one rule without a DeviceEvents row -- Block Webshell creation for Servers -- use Sysmon Event ID 11 in web roots plus IIS access logs [@ms-learn-asr-reference]. Microsoft Learn's operationalize page is the corresponding canonical reference for post-deployment monitoring practices [@ms-learn-asr-deployment-operationalize].

Step 4 -- Layer with the sibling controls

ASR alone is not a complete posture. The set of controls that compose with ASR includes:

Tamper Protection [@ms-learn-tamper-protection] -- prevents administrators (and attackers with admin rights) from disabling ASR rules at runtime through registry or service tampering.
Cloud Protection (MAPS) -- required for several rules including the prevalence-based executable rule and the ransomware advanced-protection rule [@ms-learn-asr-reference].
The Microsoft 365 Apps macros-from-the-internet-blocked-by-default policy [@ms-learn-internet-macros-blocked] [@ms-techcommunity-internet-macros-2022] -- the consumer-facing twin of ASR's Office rules; default-on for every Microsoft 365 tenant since the July 2022 staged rollout.
The Vulnerable Driver Blocklist [@ms-learn-driver-block-rules] -- default-on in Windows 11 22H2; sibling to the BYOVD ASR rule at the kernel-load edge.
EDR-in-block-mode [@ms-learn-edr-in-block-mode] -- only when Defender Antivirus is in passive mode (third-party AV is primary).
Sysmon -- for visibility into edges ASR does not block and for audit-trail corroboration of edges it does. (M1040 nominates ASR per-technique [@mitre-m1040]; M1042 does not mention Sysmon or ASR by name [@mitre-m1042] -- the pairing is practitioner consensus, not an M1042 nomination.)

Step 5 -- Track exclusions in source control

The exclusion list is the most common deployment-failure surface. Adding C:\Program Files\Vendor\ as an exclusion for one rule applies fleet-wide; over-broad exclusions are the dominant practical risk to the layer's integrity. Use Git or equivalent; review exclusions every quarter; demand a Jira ticket per exclusion with a sunset date.

Note: (1) Enable BYOVD, LSASS, and WMI persistence in Block mode (Standard protection -- start here). (2) Move the other sixteen rules through Audit, Warn, Block. (3) Hunt with DeviceEvents | where ActionType startswith "Asr". (4) Layer with Tamper Protection, Cloud Protection, the Microsoft 365 Apps macro default block, the Vulnerable Driver Blocklist, EDR-in-block-mode (for passive AV), and Sysmon. (5) Track exclusions in source control with sunset dates.

Note: Exclusions added to one ASR rule apply fleet-wide. Over-broad exclusions are the dominant practical attack surface against an otherwise well-configured ASR posture. Adam Svoboda's published technique demonstrates that low-privilege users can enumerate the exclusion list directly from Defender's VDM containers [@adamsvoboda-asr-exclusions]. Track exclusions in source control. Review quarterly. Require a ticket with a sunset date for every entry.

If LSA Protection (RunAsPPL) is enabled on the device, the LSASS ASR rule shows as "not applicable" because LSA Protection already enforces the same boundary at a different layer [@ms-learn-asr-overview]. Confused defenders sometimes interpret the "not applicable" state as a rule misconfiguration; it is in fact the correct behaviour, and means the host is already protected against the equivalent class of attacks by LSA Protection plus Credential Guard.

```powershell Set-MpPreference -AttackSurfaceReductionRules_Ids ` '56a863a9-875e-4185-98a7-b882c64b5ce5', ` '9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2', ` 'e6db77e5-3df2-4cf1-b95a-636979351e5b' ` -AttackSurfaceReductionRules_Actions Enabled, Enabled, Enabled Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids ``` Run as administrator. The three GUIDs are BYOVD, LSASS, and WMI persistence respectively. Confirm with the Get-MpPreference call. For staged rollout in an enterprise, manage these through Intune or Group Policy instead so the configuration follows the device.

Five steps, three Standard protection rules, sixteen Other ASR rules, two rules that skip Warn mode, one universal hunting query. The rest is exception-list discipline. Section 11 closes with the seven misconceptions that survive every rollout.

11. Frequently Asked Questions

No. ASR rules live inside **Microsoft Defender Antivirus** -- the on-host scanning engine that ships free with every Windows edition that includes Defender. **Microsoft Defender for Endpoint** is the cloud-managed EDR layer Microsoft sells on top, with `DeviceEvents` Advanced Hunting, Indicators of Compromise management, and automated investigation. ASR rules can be configured locally via PowerShell or Group Policy with no Defender for Endpoint licence at all. Defender for Endpoint adds management, telemetry ingestion, and Advanced Hunting; it does not add the enforcement [@ms-learn-asr-reference] [@ms-learn-edr-in-block-mode]. No. This is the SOC-playbook folklore that survives every rollout. Each rule emits a rule-specific `AsrAudited` and `AsrBlocked` pair (the server-only Webshell rule is the only exception, with no `DeviceEvents` row at all). The canonical universal Advanced Hunting query is `DeviceEvents | where ActionType startswith "Asr"`, not equality against a generic value. Microsoft Learn's rules reference enumerates every pair [@ms-learn-asr-reference]. No. The Office macro era ended through three layers in combination: (1) **Europol's Operation LadyBird** on January 27, 2021, the coordinated international takedown of Emotet's command-and-control infrastructure [@europol-emotet-disrupted-wayback]; (2) **ASR's 2017-onward Office rules at the enterprise tier**, managed through Intune, Group Policy, or Defender for Endpoint; (3) **the Microsoft 365 Apps internet-macro default block at the consumer and tenant tier**, announced by Tom Gallagher on February 7, 2022 and resumed July 20, 2022 after a brief pause for usability fixes [@ms-techcommunity-internet-macros-2022]. ASR is the enterprise-managed layer. It was not the only layer. The honest version of the story names all three. Partially yes, and the nuance matters. The interception point (`WdFilter.sys`, registered at altitude 328010 in the FSFilter Anti-Virus band per the IFS allocated-altitudes reference [@ms-learn-ifs-allocated-altitudes]) is **kernel-mode**. The policy evaluation (`MsMpEng.exe`) is **user-mode** at integrity level System. Calling ASR "kernel-mode" without nuance is incomplete; the correct one-line framing is "kernel-mediated interception, user-mode policy evaluation." No. Microsoft Learn's overview page states verbatim: "If you enabled Local Security Authority (LSA) protection (recommended, along with Credential Guard), this rule is redundant" [@ms-learn-asr-overview]. The LSASS ASR rule shows as "not applicable" on devices where LSA Protection is enabled. The "not applicable" state is the correct behaviour, not a misconfiguration. No. Only two ASR rules skip Warn mode -- "Block credential stealing from the Windows local security authority subsystem" and "Block Office applications from injecting code into other processes" -- both per Microsoft Learn's overview page [@ms-learn-asr-overview]. Section 4 Generation 3 walks the byte-level proof that the rest of the catalogue (including the Safe Mode reboot rule and the copied-tools rule, two of the five rules the folklore wrongly lists) does support Warn. Yes -- routinely. The "the SOC never sees ASR" framing is rhetoric, not reality. Multiple rules raise EDR alerts in Defender for Endpoint; every rule except the Webshell rule lands a row in `DeviceEvents` [@ms-learn-asr-reference]. The accurate framing is that ASR blocks rarely require analyst response because there is nothing left to triage once the kernel has returned the operation as failed -- the Frankfurt analyst from this article's opening never gets paged because the macro never spawned PowerShell. The SOC can hunt, audit, and report on ASR activity at any time; the choice not to triage individual blocks is exactly what a well-tuned preventive layer ought to enable.

Nine years, seven generations, nineteen rules, one structural pivot from nodes to edges, and the same Cohen-1984 ceiling that every behaviour-block list inherits. The Frankfurt analyst from this article's opening never knew the macro fired -- because the kernel made sure nothing happened. That is the article in one sentence: a quiet layer that converts a credential-stealing-banking-trojan-turned-loader campaign into a single-row telemetry event the SOC routinely ignores, by classifying edges instead of nodes.