Parag Mali - tag: endpoint-security

Seventy-Eight Minutes That Evicted Antivirus From the Windows Kernel

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

At 04:09 UTC on July 19, 2024, a CrowdStrike Falcon channel-file update -- not a driver update, but a small data file consumed by an in-kernel interpreter -- crashed approximately 8.5 million Windows hosts in seventy-eight minutes. The technical bug was a parameter count mismatch the content validator missed; the architectural bug was that the dangerous code was already in the kernel. Microsoft's response, the Windows Resiliency Initiative, commits to a multi-year migration of third-party endpoint security out of kernel mode -- a Vista-era idea finally given political license to ship. Whether user-mode EDR with hypervisor-assisted introspection can match twenty-five years of kernel-mode hooking coverage is the article's open architectural question, and the honest mid-2026 answer is "we do not yet know."

1. 04:09 UTC, Friday, July 19, 2024

At 04:09 UTC on Friday, July 19, 2024, a CrowdStrike Falcon Cloud release pipeline pushed a Rapid Response Content file -- not a sensor binary, not a driver update, but a small piece of data named in the C-00000291-*.sys channel-file naming convention -- to the production rollout channel for Falcon Sensor on Windows [@cs-pir-2024-07-24]. The release engineer at the rollout console saw the indicator move from staging to production. Sixty-six minutes later, by Microsoft's own count, approximately 8.5 million Windows hosts had bug-checked and were either rebooting into a kernel panic or already stuck in one [@ms-bradsmith-2024-07-20]. Delta and United pulled gates. The U.K. National Health Service diverted patients away from impacted trusts. Public-safety answering points went degraded across several U.S. states [@crs-if12717-everycrsreport]. CrowdStrike's release pipeline reverted the bad content at 05:27 UTC -- seventy-eight minutes after it had been pushed -- and the rollout indicator on the CrowdStrike side went from red back to green [@cs-pir-2024-07-24]. The rollout indicator on every customer machine that had already received the bad content went, and stayed, blue. The dangerous code was already in the kernel; the update had only handed it a fatal input.

That single fact -- that a content update could brick eight and a half million machines without the code path that consumed the content ever being treated as a code path -- is the whole reason this article exists.

The numbers, anchored to primary sources

Brad Smith, Microsoft's vice chair and president, published his "8.5 million Windows devices" figure on July 20, 2024 -- the morning after the incident -- and the phrase is unchanged in any Microsoft document since: "we currently estimate that CrowdStrike's update affected 8.5 million Windows devices, or less than one percent of all Windows machines" [@ms-bradsmith-2024-07-20]. The U.S. Government Accountability Office later framed the incident as "potentially one of the largest IT outages in history" [@gao-24-107733]. The U.S. Cybersecurity and Infrastructure Security Agency opened a running advisory the same day, anchored to its own July 19, 2024 alert, that has been updated continuously since [@cisa-alert-2024-07-19]. The Congressional Research Service's IF12717 brief lays out the public-safety blast radius -- FAA ground stops, 911 PSAP degradation, hospital systems falling back to paper -- and Adam Meyers, CrowdStrike's Senior Vice President for Counter Adversary Operations, was sworn in before the House Homeland Security Committee's Cybersecurity Subcommittee on September 24, 2024 to answer for it [@crs-if12717-everycrsreport, @homeland-hearing-page, @cyberscoop-meyers].

The fault, as Microsoft's dump shows it

Eight days after the outage, on July 27, 2024, Microsoft's security team published a primary-source post-mortem [@ms-secblog-2024-07-27]. The dump's load-bearing fields, condensed and relabeled below for readability (Microsoft's actual labels are READ_ADDRESS, IMAGE_NAME, FAULTING_MODULE, with the faulting instruction inside the .trap disassembly and KiPageFault inside the stack trace):

READ_ADDRESS: ffff840500000074 Paged pool
IMAGE_NAME:   csagent.sys
FAULTING_IP:  csagent+e14ed
              mov  r9d, dword ptr [r8]
CALLED_FROM:  nt!KiPageFault+0x369

Read low to high, every line answers a different question. csagent.sys is the CrowdStrike Falcon kernel driver. csagent+e14ed is the offset of the faulting instruction inside that driver. mov r9d, dword ptr [r8] is that instruction -- a single x86-64 move that loads a 32-bit value from the memory address in register r8 into register r9d. The address in r8 was 0xffff840500000074, in the high half of the kernel virtual address space, which the labelling "Paged pool" suggests the memory manager classifies as paged kernel memory -- but at that specific virtual address, on this machine, at this instant, no page table entry mapped a physical page. The CPU raised a page fault. Windows delivered the fault to nt!KiPageFault+0x369. The kernel bug-checked with PAGE_FAULT_IN_NONPAGED_AREA [@ms-secblog-2024-07-27, @ms-bradsmith-2024-07-20].

There is one piece of information the WinDBG dump does not publish, and the article is going to be careful about it: the IRQL value at the moment of the fault. No primary source records whether csagent.sys was at PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL, or higher when the page fault triggered. What every primary source agrees on is the consequence: the fault occurred at an interrupt request level high enough that the kernel could not unwind to a structured exception handler in any meaningful way, and the operating system stopped. Treat any third-party post that asserts a specific IRQL value for Channel File 291 as speculation unless it cites a primary source that publishes the value.

sequenceDiagram participant Cloud as Falcon Cloud Rollout participant Sensor as Falcon Sensor (user mode) participant Driver as csagent.sys (kernel) participant Kernel as Windows Kernel participant Disk as Local Disk Cloud->>Sensor: 04:09 UTC push of Channel File 291 Sensor->>Disk: Persist channel file Sensor->>Driver: Load Template Instance into in-kernel interpreter Driver->>Driver: Index 21st parameter slot Driver->>Kernel: Dereference unmapped kernel address 0xffff840500000074 Kernel->>Kernel: nt!KiPageFault, then bug check 0x50 Note over Kernel: PAGE_FAULT_IN_NONPAGED_AREA, host blue screens Cloud->>Cloud: 05:27 UTC, revert bad content Note over Cloud,Disk: New hosts are saved, already-affected hosts are not Disk->>Driver: On reboot, csagent.sys re-reads the persisted file Driver->>Kernel: Same fault path executes again

The persistence-across-reboot pathology is the part most contemporary coverage understated. CrowdStrike reverted the bad content from the cloud rollout pipeline 78 minutes after pushing it [@cs-pir-2024-07-24]. But the file was already on disk on every machine that had received it. On reboot, csagent.sys loaded again, parsed the persisted file again, and bug-checked again. The fix required either a manual safe-mode deletion -- the canonical "boot, delete C-00000291*.sys, reboot" runbook that circulated on Reddit, social media, and vendor advisories that morning -- or, later, Microsoft's purpose-built recovery tool [@mslearn-qmr].

That is what happened. The next question -- the one this article exists to answer -- is why the dangerous code was already in the kernel in the first place, what twenty-five years of architectural decisions put it there, and what it took to begin to undo those decisions. To get there, we have to start in 1999.

2. Why Antivirus Lives in the Kernel

Imagine you are a security engineer in 1999. Your assignment is to detect a virus that has installed itself between the user-mode file APIs and the on-disk file system, so that when a scanner running as a user reads the file, the virus serves up a clean copy of the bytes and hides the infected ones. Where do you put the observer?

If you think about it for a minute, you converge on the same answer Microsoft, Symantec, Network Associates, Trend Micro, and every other antivirus vendor converged on in the late 1990s: you put the observer below the thing that is lying. In Windows terms, "below" means kernel mode. On x86, that is Ring 0. In NT terminology, that is the privilege level at which all the operating system primitives -- the file system, the process manager, the memory manager -- actually live.

A per-processor priority value Windows uses to gate code execution against hardware and software interrupts. Code running at PASSIVE_LEVEL (zero) can be preempted by almost anything; code running at DISPATCH_LEVEL or higher cannot take page faults on pageable memory and must complete quickly. Kernel drivers must obey strict IRQL rules; violations -- such as touching pageable memory at DISPATCH_LEVEL -- produce immediate bug checks rather than recoverable exceptions.

The 1999 to 2003 transition

The first generation of Windows antivirus, on Windows 9x and NT 4.0, ran almost entirely in user mode and lost the argument with the first rootkits to ship in the wild. A scanner that runs in the same protection ring as the malware it is hunting cannot, by construction, see what the malware has chosen to hide from anything in that ring. The fix, by the late 1990s and the early 2000s, was to push the scanner into Ring 0.

Two specific Windows kernel primitives carried that fix.

The first was the minifilter: a kernel driver attached to the I/O manager's file system stack at a specific altitude, intercepting IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_WRITE, and friends, so the antivirus could examine the file before the file system returned the bytes to user mode [@mslearn-filter-drivers]. Microsoft formalized the Filter Manager as the supported way to do this -- and by the mid-2000s the legacy sfilter model was deprecated in favor of the structured minifilter model. Every shipping Windows antivirus in 2026 still has a minifilter driver loaded as part of its boot-time stack.

A kernel driver registered through the Windows Filter Manager that attaches to one or more file system volumes at a specific *altitude* (a Microsoft-assigned numeric priority) and receives pre-operation and post-operation callbacks for each file system operation. Antivirus minifilters use this hook point to scan a file before user-mode code sees the bytes returned from disk.

The second was the process-create kernel callback. Beginning with Windows 2000 and extended for synchronous block authority in Windows Vista SP1 (alongside Windows Server 2008), the documented function PsSetCreateProcessNotifyRoutine (and later PsSetCreateProcessNotifyRoutineEx) lets a kernel driver register to be called whenever the kernel is about to create a new process, with the option in the extended variant to set CreationStatus = STATUS_ACCESS_DENIED and synchronously block the create [@mslearn-pssetcreateprocessnotifyroutine, @mslearn-pssetcreateprocessnotifyroutineex]. This is the kernel primitive that lets an EDR vendor say "process X is about to spawn cmd.exe with these arguments, and we are denying the create" without ever exiting the kernel. Companion callbacks exist for image-load events, thread-create events, registry operations [@mslearn-cmregistercallback], and handle-access events [@mslearn-obregistercallbacks]. Together they form the documented Generation-2 vendor API surface for EDR primitives, the architectural substrate every modern Windows EDR sits on top of.

The rootkit pressure

The second pressure that pushed antivirus down into the kernel came from the attackers themselves. By the mid-2000s, kernel-mode rootkits were a routine part of the malware writer's toolkit. The most pernicious variants used a technique called Direct Kernel Object Manipulation: instead of installing themselves anywhere a defender could observe via documented APIs, they walked Windows internal data structures and unlinked themselves from the lists the operating system traversed when answering questions like "what processes are running?" or "what kernel modules are loaded?"

A rootkit technique that modifies in-memory Windows kernel data structures directly -- for example, unlinking an `EPROCESS` block from the active process list so that `nt!PsActiveProcessHead` traversal does not enumerate the malicious process. Because the modification is invisible to any code that asks the kernel to enumerate via the documented APIs, the only defenders that can see DKOM are those that walk kernel memory authoritatively from a vantage equal to or below the rootkit itself.

To catch a Ring-0 rootkit, you needed a Ring-0 defender. Symantec, McAfee, Trend Micro, and Kaspersky all converged on the same answer in the early 2000s, and every commercial Windows EDR architecture in 2026 still reflects that convergence.The lineage from DOS-era signature scanners (one-process, no privilege boundary) through Win9x scanners (no privilege boundary either) through NT-era minifilters (a privilege boundary, with the scanner across the boundary from the malware) to 2024-era in-kernel content interpreters (a privilege boundary, with the scanner and a rule engine and an unsigned content channel all on the same side of the boundary) is a small case study in how an architecture persists long after the original constraints relax.

Architectural decisions made under one set of constraints have a way of outliving the constraints that produced them. The 1999 decision to put antivirus in the kernel was rational at the time -- it was the only place from which you could authoritatively see what a process or a file system actually did. Twenty-five years later, that decision produced csagent.sys running in Ring 0 on 8.5 million machines, indexing past the end of a parameter array on a Friday morning in July.

But the move into the kernel did not go uncontested. Microsoft itself spent two years between 2005 and 2007 trying to claw back at least part of that ground. The first attempt was called Kernel Patch Protection, and the political fight it produced is the story of the next section.

3. The Vista PatchGuard Battle, 2005-2007

Either everybody has access to the kernel, or nobody does. -- Stephen Toulouse, Microsoft senior product manager, InformationWeek, October 2006 [@informationweek-2006-toulouse]

The political question at the heart of this article is twenty years old. It is also binary in a way that very few political questions ever are: Microsoft's stated position in 2006 was not "we will permit some vendors to modify the kernel and deny others," nor "we will run an accreditation scheme," nor "we will charge for kernel-mode signing certificates." The stated position was that either every vendor on Earth could modify the Windows kernel or no vendor could, and the only stable answer was the second one. That argument, made by a Microsoft senior product manager in trade press in 2006, reverberates without modification into the November 2024 Windows Resiliency Initiative announcement.

What Kernel Patch Protection actually does

Kernel Patch Protection -- commonly called PatchGuard -- shipped with x64 editions of Windows XP, Windows Server 2003 Service Pack 1, and the launch x64 edition of Windows Vista, beginning in 2005 [@wiki-kpp]. Microsoft updated it in August 2007 via Security Advisory 932596, which is the canonical Microsoft primary document for the program [@ms-advisory-932596].

A Windows kernel feature on x64 builds that periodically verifies the integrity of selected critical kernel structures -- the System Service Descriptor Table (SSDT), the Interrupt Descriptor Table (IDT), the Global Descriptor Table (GDT), the kernel image, the Hardware Abstraction Layer (HAL), and the NDIS network stack. If PatchGuard detects modification it triggers bug check `0x109` `CRITICAL_STRUCTURE_CORRUPTION` and the operating system stops [@wiki-kpp].

What PatchGuard does is enforce an invariant: third-party code may not modify a specific list of kernel data structures, and if it does, the system bug-checks. What PatchGuard does not do is prevent third-party drivers from loading. PatchGuard is a structural integrity check, not a load-time policy. The Vista-era plan was for vendors to migrate from inline hooks of the SSDT to the documented callback APIs of the previous section -- PsSetCreateProcessNotifyRoutine, ObRegisterCallbacks, CmRegisterCallback, the Filter Manager [@mslearn-pssetcreateprocessnotifyroutine, @mslearn-obregistercallbacks, @mslearn-cmregistercallback, @mslearn-filter-drivers] -- and csagent.sys is the lineal descendant of that migration: a fully documented, fully callback-based, fully Generation-2 driver. PatchGuard did exactly what it was designed to do, and csagent.sys was perfectly compatible with it.

The political fight

Symantec and McAfee did not see it that way in 2005. To them, PatchGuard was Microsoft using a security feature to advantage its own emerging Microsoft Forefront Client Security antivirus product against the entire third-party industry. The complaint escalated to the European Commission in October 2006 [@wiki-kpp]. Stephen Toulouse, then a Microsoft senior product manager, replied in InformationWeek with the line that anchors this section: "Either everybody has access to the kernel, or nobody does. Malware writers exploit the same interfaces to access Windows kernel, a threat that Microsoft says outweighs the benefits. Modifying the kernel also compromises Windows performance, according to the company" [@informationweek-2006-toulouse]. Microsoft's binary-symmetry position was that any vetting scheme -- "trusted vendors get kernel access" -- would simply produce malware that pretended to be a trusted vendor. The only stable equilibria were "everyone" and "no one." Microsoft chose "no one for the things PatchGuard protects," and then opened a parallel migration path of documented callback APIs as the supported alternative.

The Symantec and McAfee complaints in 2006 were filed in the wake of Microsoft's own 2005 entry into the corporate antivirus market with what became Forefront Client Security. The trade press read it as the same competitive grievance Netscape filed against Microsoft a decade earlier: a platform owner introducing first-party products into a market the platform owner also regulated. Gartner's John Pescatore framed the worry, quoted in the same InformationWeek piece, as Microsoft becoming *"the layer between the user and the security products"* [@informationweek-2006-toulouse]. The European Commission opened an inquiry; Microsoft compromised by documenting the callback APIs and shipping the August 2007 update to KPP [@ms-advisory-932596]. The two AV vendors stayed in business; their kernel hooks moved from SSDT patches to `PsSetCreateProcessNotifyRoutine` calls. Twenty years later, the same two vendors -- both still selling Windows EDR products -- are now publicly endorsing Microsoft's move to take *all* third-party EDR out of the kernel. The political ground really has shifted; we will see by how much in section 6.

The lesson Microsoft drew, and the lesson it did not yet draw

The 2005 to 2007 round produced a real, durable architectural lesson: documented APIs are stabler than hooks. A vendor who wrote a driver that called PsSetCreateProcessNotifyRoutineEx could rely on Microsoft to preserve the API across Windows builds. A vendor who wrote a driver that patched the SSDT pointer table directly could rely on the next Windows service pack to break it without warning, or now on PatchGuard to bug-check the host. Every shipping Windows EDR in 2026 lives downstream of that lesson -- their kernel drivers use the documented callback APIs and they do not patch kernel structures inline.

But there was a second lesson Microsoft did not draw in 2005. The PatchGuard fight was about technique (do not patch the SSDT) and it stopped there. It did not pose the deeper question: should third-party kernel drivers exist at all for AV? That question -- whether vendor-authored Ring-0 code is a fleet-scale reliability liability regardless of whether it hooks or uses callbacks -- was visible in principle in 2005 and ignored. Microsoft would not pose it publicly for another nineteen years. What changed, in the meantime, was a slow drip of failures that should have made the question unavoidable and somehow did not. That drip is the subject of section 4.

4. Fourteen Years of Kernel-Driver Disasters

If the kernel-mode antivirus architecture was a 1999 design choice, you would expect it to have aged badly. It did. The pattern played out generation after generation, vendor after vendor, year after year, with the same general shape: a vendor pushed content; the vendor kernel driver consumed the content; the content had a bug the validator missed; the driver crashed the kernel; the fleet went down. The most consequential single instance of the pattern, before July 19, 2024, happened on April 21, 2010 with McAfee VirusScan and a daily virus definition update named DAT 5958.

McAfee DAT 5958, April 21, 2010

McAfee shipped its 5958 DAT file. The file misidentified svchost.exe -- the legitimate Windows service host -- as W32/Wecorl.a, a network worm. The McAfee kernel driver quarantined svchost.exe per the false positive. On Windows XP SP3 fleets at hospitals, police departments, schools, and government agencies across the U.S., the result was an immediate reboot loop and total loss of networking [@uscert-mcafee-2010, @sans-isc-8656, @askperf-mcafee].

US-CERT's contemporaneous advisory captured the failure mode in a single sentence: "US-CERT is aware of public reports indicating that McAfee DAT release 5958 is incorrectly identifying the valid system file, C:\Windows\system32\svchost.exe, as containing malicious code... Symptoms include a denial-of-service condition when the McAfee software attempts to clean the file" [@uscert-mcafee-2010]. SANS's Internet Storm Center noted the same morning that "DAT file version 5958 is causing widespread problems with Windows XP SP3. The affected systems will enter a reboot loop and lose all network access" [@sans-isc-8656]. Microsoft's own AskPerf team, in a TechCommunity post dated April 21, 2010, walked through the recovery steps and the EXTRA.DAT remediation [@askperf-mcafee].

Here is the structural point, and it matters enormously for the rest of this article: the McAfee driver was doing nothing PatchGuard would have prevented. It was a fully Generation-2 design, using documented kernel callback APIs, with no inline kernel patching whatsoever. The 2005 PatchGuard fight was politically irrelevant to the 2010 McAfee outage, because PatchGuard was answering a different question -- "does the vendor patch SSDT entries inline?" -- when the question that produced the McAfee outage was "does the vendor's signed, callback-using, fully-supported kernel driver act on data that turns out to be wrong?" The 2005 fix did not address the 2010 fault.

Key idea: McAfee 2010 and CrowdStrike 2024 are architecturally identical: a vendor pushed content; the vendor kernel driver consumed the content; the content was wrong in a way that the validator did not catch; the driver crashed the fleet. The 2005 PatchGuard fight had been about a different problem entirely. The architecture that produced both failures -- "vendor-authored Ring-0 code consuming cloud-pushed updates" -- was untouched by the 2005 fix and would not be touched again until 2024.

The mid-2010s tail

Between 2010 and 2024 the same pattern reappeared at smaller scale, episodically, across the vendor cohort. Symantec, Trend Micro, Kaspersky, and Sophos each shipped at least one driver or definition update during this period that produced blue-screen reports on customer fleets. The Three Buddy Problem podcast, recorded on July 19, 2024 in the immediate aftermath of the CrowdStrike outage, opens with Costin Raiu drawing the line back from 2024 to 2010 explicitly: the lesson the industry promised itself after McAfee 5958 was staged rollouts, and the lesson the industry actually implemented was insufficient [@three-buddy-ep5].Raiu's framing on the podcast -- "we had this exact discussion in 2010, and the answer everyone agreed on was staged rollouts, and here we are again" -- is the cleanest single-sentence retrospective from inside the industry. The same week, Patrick Wardle was making the same point with macOS-side framing on his Objective-See blog [@wardle-objsee-0x7b] and at the August 2024 Black Hat USA talk whose slides he later published [@wardle-speakerdeck].

The Apple natural experiment, September 2024

Two months after CrowdStrike Channel File 291, Apple shipped macOS 15 Sequoia on September 16, 2024 with deprecated Application Firewall property-list interfaces [@bleepingcomputer-sequoia]. CrowdStrike Falcon for macOS, ESET Endpoint Security, Microsoft Defender for Mac, and SentinelOne all broke their network filtering [@securityweek-sequoia, @bleepingcomputer-sequoia]. Apple shipped macOS 15.0.1 on October 3, 2024, seventeen days later, restoring compatibility [@techcrunch-sequoia]. The TechCrunch report has Patrick Wardle on the record, framing the architectural difference in one line: "a fix for the networking issues that plagued the initial macOS 15 release... And to any Apple apologist who blamed 3rd-party vendors, you deserve to be slapped with a large trout as this was an Apple bug reported before GM" [@techcrunch-sequoia].

That second sentence is the load-bearing one. The Sequoia bug was a 1st-party regression in the framework boundary between macOS and third-party endpoint security tools. It degraded EDR features substantially -- network filtering disappeared on every affected host -- but no host kernel-panicked. None of the affected EDR vendor processes brought down macOS. None of the affected hosts entered a reboot loop. The same general failure mode as Channel File 291 produced a fundamentally different blast radius, and the only reason for the difference is architectural: Apple had moved third-party endpoint security out of macOS kernel mode in 2019 with the Endpoint Security framework [@apple-esf-docs]. We will return to ESF in section 7.

The macOS 15 Sequoia outage and the Windows Channel File 291 outage occurred within ten weeks of each other and shared the same general structure: a 1st-party platform event meeting a third-party security product loaded for runtime introspection. The Windows event panicked the kernel on 8.5 million hosts. The macOS event produced a feature regression that vendors patched out within three weeks and Apple repaired in 15.0.1. The two events are the article's strongest single comparative datum that architecture, not vendor reliability, was the variable. timeline title Recurring kernel-driver and platform faults, 2005 to 2024 2005 : PatchGuard ships on Windows x64 : Symantec and McAfee escalate antitrust complaints 2010 : McAfee DAT 5958 quarantines svchost.exe on Windows XP SP3 : Fleet-scale reboot loops at hospitals, police, schools 2014 : Various smaller vendor BSOD events in the long tail 2019 : Apple ships macOS Catalina Endpoint Security framework : Third-party AV deprecated from kernel mode on macOS 2024 : CrowdStrike Channel File 291 on July 19, 8.5M hosts : Apple ships macOS 15 Sequoia on September 16 : macOS 15.0.1 restores AV compatibility on October 3 2024 : Microsoft Ignite announces Windows Resiliency Initiative on November 19

CrowdStrike Channel File 291, July 19, 2024

By July 2024 the cumulative evidence had been building for fourteen years that vendor-authored Ring-0 code was a fleet-scale reliability liability. What was different about Channel File 291 was not the kind of failure but the scale and the cost: 8.5 million hosts on Windows in 2024 versus what was likely a six-or-seven-figure XP SP3 fleet on McAfee in 2010, and a cost calculus that included Delta Air Lines, the U.K. NHS, multiple state 911 systems, and the global air-traffic-control flow that depends on Microsoft Windows running healthy [@cs-pir-2024-07-24, @gao-24-107733, @crs-if12717-everycrsreport]. The political license to do something architectural had finally arrived. What it took, in real-world failures, to surface the architectural answer was not new evidence -- the evidence had been overwhelming for years -- but a single event large enough to make the political cost of not changing untenable.

So: what exactly happened inside csagent.sys on the morning of July 19, 2024? That technical reconstruction is the centerpiece of this article, and it occupies the next section.

5. Inside Channel File 291

The technical centerpiece. Start by staring at the same five-field summary, reformatted from Microsoft's July 27, 2024 crash-dump walkthrough [@ms-secblog-2024-07-27]:

READ_ADDRESS: ffff840500000074 Paged pool
IMAGE_NAME:   csagent.sys
FAULTING_IP:  csagent+e14ed
              mov  r9d, dword ptr [r8]
CALLED_FROM:  nt!KiPageFault+0x369

Reading from low to high address, every line of that summary answers a different question. The complete line-by-line walkthrough is folded into the spoiler later in this section. First we have to understand what csagent.sys was trying to do when it ran the instruction.

The Windows bug check raised when kernel code attempts to read from or write to a virtual address that has no valid mapping in the page tables. The "nonpaged area" naming is historical -- the bug check fires whenever any kernel-mode access touches an unmapped virtual address, regardless of which memory pool the address would have lived in if it had been valid.

What `csagent.sys` was trying to do

csagent.sys is the CrowdStrike Falcon Sensor kernel driver, the Ring-0 component that has been part of the Falcon product since its earliest Windows releases. By 2024, this driver did considerably more than mediate file I/O and process creation. According to CrowdStrike's own Root Cause Analysis published on August 6, 2024, csagent.sys includes a Content Interpreter that runs at kernel privilege and consumes binary detection rules shipped from the Falcon Cloud [@cs-rca-2024-08-06]. CrowdStrike's terminology distinguishes two kinds of content delivery: Sensor Content, which is bundled with each released sensor binary and updates at the sensor release cadence; and Rapid Response Content, which is delivered via channel files like Channel File 291 and updates at a much faster cadence to keep ahead of novel adversary behavior [@cs-pir-2024-07-24]. Channel files are treated as data, not code -- but they are consumed by the Content Interpreter, which is code, running in the kernel.The Sensor Content versus Rapid Response Content distinction is the architectural detail that determines why a content update could reach the kernel at all. Sensor Content is signed and version-bumped together with the driver binary; Rapid Response Content is pushed independently and rapidly. The Falcon architecture used the Rapid Response Content channel to deliver Template Instances against a Template Type schema that the in-kernel Content Interpreter parsed. The channel-file delivery path bypassed the WHQL driver-signing scrutiny that the driver binary itself had received [@cs-pir-2024-07-24].

The CrowdStrike Falcon Sensor subsystem, resident inside `csagent.sys` at kernel privilege, that parses Rapid Response Content channel files at runtime. The interpreter reads a Template Instance (a binary payload of detection rules) and evaluates it against the corresponding Template Type schema declared in the sensor's compiled code. Detection rules thus take effect on a host whenever a new channel file is pushed from the Falcon Cloud, with no sensor binary update required.

The bug, exactly

CrowdStrike's RCA names the failure mode in plain language [@cs-rca-2024-08-06]. The IPC Template Type was introduced in Falcon sensor version 7.11, released on February 28, 2024. The IPC Template Type declares 21 input parameter fields. The sensor's integration code that fed the in-kernel Content Interpreter for this Template Type supplied only 20 input values -- one fewer than the schema declared. The Content Validator that was responsible for verifying each shipped Template Instance against its Template Type schema did not catch the count mismatch. From February 28 to July 19, all Template Instances against this Template Type happened to use a wildcard matcher on the 21st field, and the unmapped field went unread; the bug was latent for almost five months. On July 19, 2024, the deployed Template Instance for the first time used a non-wildcard matcher on the 21st field. At runtime on every Windows host with the affected Falcon sensor configuration, csagent.sys's Content Interpreter indexed into the 21st parameter slot and dereferenced past the end of the input array [@cs-rca-2024-08-06].

The faulting instruction was the mov r9d, dword ptr [r8] that Microsoft's July 27 post reproduces. The pointer in r8 was the unmapped kernel address 0xffff840500000074. The CPU page-faulted. The fault was delivered to nt!KiPageFault+0x369. The kernel bug-checked with PAGE_FAULT_IN_NONPAGED_AREA [@ms-secblog-2024-07-27].

- `READ_ADDRESS: ffff840500000074 Paged pool`. The virtual address the faulting instruction tried to read. The `ffff8405...` prefix is the high half of the x86-64 canonical address space -- on Windows, conventionally kernel virtual memory. The "Paged pool" label is the memory manager's classification of where the address would have lived if it had been mapped. At this instant, it was not. - `IMAGE_NAME: csagent.sys`. The kernel module containing the faulting instruction. This is the CrowdStrike driver. - `FAULTING_IP: csagent+e14ed`. The offset of the instruction inside `csagent.sys`. `e14ed` is the relative virtual address of the function reading the parameter slot. - `mov r9d, dword ptr [r8]`. The instruction itself: load a 32-bit value (`dword`) from the address in `r8` into the lower 32 bits of `r9`. This is one of the cheapest x86-64 memory loads possible; the bug is not in the instruction but in the value of `r8`. - `CALLED_FROM: nt!KiPageFault+0x369`. The point of return into the kernel's fault handler. `KiPageFault` is the standard #PF interrupt handler in `ntoskrnl.exe`. When the page fault could not be satisfied (no mapping for the requested address), `KiPageFault` raised the bug check that stopped the system.

About the IRQL -- the part of the post-mortem this article is most careful with. As §1 established, no public CrowdStrike RCA or Microsoft secblog post publishes the IRQL value at the moment of the fault [@ms-secblog-2024-07-27, @cs-rca-2024-08-06]. The article will not assert DISPATCH_LEVEL or any other specific value, because no primary source establishes one. Treat any third-party reconstruction that names the IRQL as speculation unless it cites a primary source.

sequenceDiagram participant Cloud as Falcon Cloud participant Sensor as Falcon Sensor (user mode) participant CI as Content Interpreter (csagent.sys) participant TT as Template Type schema, in driver participant TI as Template Instance, from channel file participant Kernel as Windows Kernel Cloud->>Sensor: Push Channel File 291 (Rapid Response Content) Sensor->>CI: Hand Template Instance to in-kernel interpreter CI->>TT: Read schema declaring 21 input parameter fields CI->>TI: Bind Template Instance values to schema fields Note over CI,TI: Integration code supplied 20 values, schema expected 21 Note over CI,TI: Content Validator did not catch the count mismatch CI->>TI: Index into 21st field for non-wildcard match CI->>Kernel: Read at unmapped kernel address 0xffff840500000074 Kernel->>Kernel: nt!KiPageFault, bug check 0x50 raised Note over Kernel: Operating system stops, host blue screens

Why a content update can crash a kernel driver

This paragraph is doing the load-bearing work of the entire article, and it deserves to be read slowly. The Falcon driver's code received WHQL signing scrutiny when CrowdStrike submitted each release of csagent.sys to Microsoft. The driver's content updates -- the channel files like Channel File 291 -- did not. The driver was architected so that data updates could drive new detection behavior without a driver release. Therefore the data file became the trust boundary. When the data file was malformed in a way the Content Validator missed, the entire WHQL signing scrutiny of the driver was effectively bypassed -- because the bug was triggered by a fully-signed driver consuming an unsigned data input that no one had validated against the driver's actual runtime expectations.

Note: The architectural lesson of Channel File 291 is not "kernel drivers are unsafe." It is that in modern EDR architectures, the cadence of content updates vastly outruns the cadence of code review, and when the content is interpreted in kernel context, the content becomes a kernel input. The trust boundary moved from the signed driver to the unsigned data file, and the industry had not named that movement before July 19, 2024. Microsoft Virus Initiative 3.0, which we will meet in section 6, names it explicitly and requires partners to engineer for it.

To make the abstract count-mismatch tangible for the reader who has never written a parser, here is the bug in a stripped JavaScript model. The JavaScript model does what every memory-safe runtime does -- it throws cleanly when you index past the end of an array -- but the comment in the unsafe branch describes the C / kernel reality: the read just returns whatever bytes happen to live at the out-of-bounds address, which on Windows kernel memory means an unmapped page and a PAGE_FAULT_IN_NONPAGED_AREA bug check.

{` // Model of the in-kernel Content Interpreter from CrowdStrike's RCA. // Template Type schema declares 21 fields; integration code supplied 20. // On July 19, 2024, the deployed Template Instance for the first time // used a non-wildcard matcher on the 21st field.

const schema = { fieldCount: 21 }; const instance = { values: Array.from({length: 20}, (_, i) => 'v' + i) };

// Memory-safe runtime catches the mismatch: try { runInterpreter(schema, instance, true); } catch (e) { console.log('SAFE:', e.message); }

// Unsafe model showing what the in-kernel C interpreter would do: runInterpreter(schema, instance, false); `}

The runnable model is doing one job: making the abstract "20 of 21" fault mode visible. In a memory-safe runtime, the validator (the runtime itself) catches the mismatch and throws. In a C kernel driver with no runtime validator, the load just happens, and whatever is at the out-of-bounds address is read. On csagent.sys on every affected Windows host on July 19, 2024, what was at the out-of-bounds address was an unmapped page, and the read fired PAGE_FAULT_IN_NONPAGED_AREA.

The persistence problem

CrowdStrike reverted the bad content cloud-side at 05:27 UTC, seventy-eight minutes after pushing it [@cs-pir-2024-07-24]. The revert achieved exactly the thing it was designed to achieve: no host that had not yet received the bad content would receive it. The revert achieved nothing for any host that had already received the bad content. The channel file was on disk. On reboot, the Falcon sensor reloaded it. The in-kernel Content Interpreter parsed it again. The host bug-checked again. The fix required either manual safe-mode deletion of C-00000291*.sys -- which became the canonical morning-of runbook circulated on every Windows admin forum -- or, later, Microsoft's purpose-built recovery tool [@mslearn-qmr, @insider-build-26120-4230]. The persistence-across-reboot pathology motivated the platform-level recovery primitive Microsoft would later ship as Quick Machine Recovery, which we will meet in section 6.

The bug is mundane. The kernel context is what made it catastrophic. Twenty-five years of architectural decisions placed a vendor-authored interpreter inside the kernel, plugged it into a cloud-driven content delivery pipeline, and shipped that combination to 8.5 million machines. On the morning of July 19, 2024, those decisions composed.

What the platform vendor -- Microsoft -- did about that composition is the subject of section 6.

6. The Microsoft Response: WESES, WRI, MVI 3.0

Twenty days after a Congressional witness from CrowdStrike apologized on the record [@cyberscoop-meyers, @govinfo-chrg-118hhrg60030, @meyers-testimony, @homeland-hearing-page], Microsoft did what twenty years of lobbying could not produce: it convened the named Microsoft Virus Initiative partners in Redmond and announced that "additional security capabilities outside of kernel mode" was now a stated platform direction [@weston-2024-09-12]. From that meeting forward, the trajectory of third-party endpoint security on Windows pointed in only one direction.

September 10, 2024: the WESES summit

On September 10, 2024, Microsoft hosted the WESES summit -- the Windows Endpoint Security partner gathering, often abbreviated WESES in trade press -- at its Redmond campus. The attendees included CrowdStrike, Sophos, ESET, SentinelOne, Trend Micro, and Bitdefender, plus U.S. and European government officials [@weston-2024-09-12]. David Weston, Microsoft's vice president for enterprise and operating system security, recapped the summit in a Windows Experience Blog post on September 12, 2024 -- two days later -- and made two specific commitments on Microsoft's behalf. First, Microsoft committed publicly to Safe Deployment Practices as a shared cross-vendor norm. Second, Microsoft committed to "additional security capabilities outside of kernel mode" as a platform direction [@weston-2024-09-12]. No new branded platform yet, no GA date, no API surface. But the political commitment was, for the first time on the public record, an architectural one.

A Microsoft program documenting the requirements third-party antivirus and endpoint security vendors must meet to ship products that integrate with Windows -- including Security Center registration, ELAM (Early-Launch Anti-Malware) participation, and Defender exclusion negotiation [@mslearn-mvi]. MVI is the contractual surface Microsoft uses to require Windows AV vendors to engineer in particular ways; updates to MVI requirements have been the principal lever for the post-Channel-File-291 reforms.

November 19, 2024: Microsoft Ignite, and the Windows Resiliency Initiative

Two months later, at Microsoft Ignite on November 19, 2024, Weston announced the program by name: the Windows Resiliency Initiative, four pillars (reliability including Quick Machine Recovery, fewer administrator-privileged apps, stronger app and driver allow-lists, and identity hardening), and a verbatim commitment that "a private preview will be made available for our security product [partner cohort] in July 2025" [@ms-ignite-2024-11-19]. The "private preview" referred to a new set of user-mode EDR APIs that Microsoft would deliver to a small named cohort of MVI partners. The Ignite post is also the first source to introduce Quick Machine Recovery publicly -- the post-outage recovery primitive engineered specifically to address the on-disk-persistence pathology that Channel File 291 had exposed [@ms-ignite-2024-11-19].

Microsoft's descriptive phrase, used consistently in Weston's June 26, 2025 blog and the November 18, 2025 Windows Experience Blog post, for the new user-mode API surface that lets third-party EDR products subscribe to kernel-curated security telemetry without loading their own kernel driver [@weston-2025-06-26, @ms-nov-2025]. Microsoft has not, as of mid-2026, branded this as a single trademarked proper noun; trade-press shorthand like "WESP" should be treated as commentary, not as a Microsoft product name.

Note: You will see "WESP" -- Windows Endpoint Security Platform, capitalized -- in trade-press coverage and conference talks. As of mid-2026 it is not a Microsoft brand. Microsoft's own primary-source language is the descriptive phrase "the Windows endpoint security platform" (lowercase, no acronym) [@weston-2025-06-26, @ms-nov-2025]. This article uses the Microsoft phrasing throughout.

June 26, 2025: the WRI detailed rollout and MVI 3.0

The most consequential single document in the entire WRI story is Weston's June 26, 2025 Windows Experience Blog post [@weston-2025-06-26]. The post commits, verbatim, that "Next month, we will deliver a private preview of the Windows endpoint security platform to a set of MVI partners... security products like anti-virus and endpoint protection solutions can run in user mode just as apps do" [@weston-2025-06-26]. That second clause is the architectural commitment in one sentence: third-party EDR on Windows runs in user mode, like every other application on Windows.

The same June 26 post names the MVI partner cohort by company -- Bitdefender, CrowdStrike, ESET, SentinelOne, Sophos, Trellix, Trend Micro, and WithSecure -- and embeds on-record statements from five of them (CrowdStrike, ESET, SentinelOne, Sophos, Trellix, and Trend Micro and WithSecure also published quotes) endorsing the migration [@weston-2025-06-26]. The post lays out the requirements of MVI 3.0: Safe Deployment Practices, deployment rings, monitored rollouts, and incident-response testing [@mslearn-mvi]. The November 18, 2025 Windows Experience Blog later established the MVI 3.0 effective date as April 1, 2025 [@ms-nov-2025].

MVI 3.0 requirement	What it mechanically requires	What it does not mechanically verify
Safe Deployment Practices	Vendor publishes a documented deployment process for sensor and content updates	That the published process is correctly enforced in the vendor's release pipeline
Deployment rings	Vendor segments customers into staged rollout cohorts (e.g., internal, canary, GA)	That ring promotion gates actually halt a rollout when a stop-signal fires
Monitored rollouts	Vendor monitors signal data during each ring transition	That the monitoring catches a Channel-File-291-class latent bug
Incident-response testing	Vendor runs scheduled incident-response drills against its own rollout pipeline	That drill outcomes generalize to a novel failure mode never tested

The cohort of named MVI 3.0 partners is the same cohort Apple's Endpoint Security framework migration targeted in 2019. The overlap is not coincidence -- the same companies sell EDR on both platforms, and the same companies are now multi-OS migrating onto the same architecture (user-mode, platform-curated telemetry). The trade press has yet to fully appreciate that the WRI is not a Microsoft-specific architecture choice; it is the second platform vendor making the same choice.

The Ionescu pivot

The single most consequential individual move in the entire two-year story is dated April 3, 2025: CrowdStrike named Alex Ionescu -- co-author of the Windows Internals book series, long-time Windows kernel researcher, and former CrowdStrike employee returning to the company -- as Chief Technology Innovation Officer with an explicit charter to "lead CrowdStrike's participation in the Microsoft Virus Initiative Program (MVI 3.0), working with Microsoft to advise on the implementation of the next-generation vendor security stack for Windows" [@cs-ionescu-ctio-2025-04-03]. Ionescu then published an on-record endorsement of Microsoft's user-mode EDR architecture in Microsoft's own June 26, 2025 Windows Experience Blog post [@weston-2025-06-26].

Key idea: The foremost public Windows kernel researcher in the industry, now CTIO of the company whose kernel driver brought down 8.5 million Windows hosts, is on the record endorsing Microsoft's eviction of vendor kernel-mode antivirus. That is the political signal July 19, 2024 produced, and it is structurally unlike anything that preceded the outage. In 2006, the vendors fought; in 2025, the foremost vendor kernel expert is helping Microsoft build the replacement.

November 18, 2025: the update and the graphics-driver exemption

The most recent Microsoft primary-source document in this article is the November 18, 2025 Windows Experience Blog post [@ms-nov-2025]. Three points in that post matter for the rest of this article. First, "effective April 1, 2025, Version 3.0 of the Microsoft Virus Initiative added new requirements for all Windows antivirus (AV) partners" -- this sets the formal effective date of MVI 3.0 [@ms-nov-2025]. Second, "in June, we released the first private preview of the Windows endpoint security platform, which shifts AV enforcement from the kernel to user mode" -- the framing is AV enforcement generally, not third-party AV enforcement specifically, which by plain reading commits Defender for Endpoint to the same architectural trajectory as the third-party MVI 3.0 cohort [@ms-nov-2025]. Third, the graphics-driver exemption: "graphics drivers, for example, will continue to run in kernel mode for performance reasons" [@ms-nov-2025]. That single concession draws the scope of the WRI cleanly: it is an AV enforcement migration, not a third-party kernel driver elimination program.

Quick Machine Recovery

One more piece of the response deserves explicit mention: Quick Machine Recovery (QMR), the platform-level recovery primitive Microsoft built specifically in response to the on-disk persistence pathology of Channel File 291. QMR is a remote-remediation flow, managed via the Configuration Service Provider model and surfaced as the RemoteRemediation CSP, that can boot a failing Windows host into a recovery environment and apply targeted fixes without manual safe-mode intervention by an administrator [@mslearn-qmr]. The capability first appeared in Windows Insider builds beginning with Build 26120.4230 on June 2, 2025 [@insider-build-26120-4230]. QMR does not, on its own, prevent another Channel-File-291-class event; it makes the recovery from one orders of magnitude cheaper.

flowchart LR A["2024-07-19 Channel File 291 outage, 8.5M hosts"] --> B["2024-07-27 Microsoft secblog publishes WinDBG dump"] B --> C["2024-09-10 WESES summit at Redmond"] C --> D["2024-09-24 House Homeland Security hearing"] D --> E["2024-11-19 Ignite, WRI announced by name"] E --> F["2025-04-01 MVI 3.0 effective"] F --> G["2025-04-03 Ionescu CTIO at CrowdStrike"] G --> H["2025-06-26 WRI detailed rollout, partner cohort"] H --> I["2025-07 private preview to MVI 3.0 partners"] I --> J["2025-11-18 AV enforcement shifts to user mode"]

The U.S.-government context is worth one paragraph of framing. The Government Accountability Office's GAO-24-107733, the Congressional Research Service's IF12717 brief, the House Homeland Security Subcommittee hearing on September 24, 2024, the CISA running alert, and the contemporaneous CyberScoop coverage all converge on the same posture: the July 19 outage was a supply-chain and Safe-Deployment-Practices event, not a cyberattack [@gao-24-107733, @crs-if12717-everycrsreport, @homeland-hearing-page, @govinfo-chrg-118hhrg60030, @meyers-testimony, @cisa-alert-2024-07-19, @cyberscoop-meyers]. The federal response shaped the political environment in which Microsoft chose to announce the WRI; it did not, by itself, design the architecture. The architecture Microsoft picked had been hiding in plain sight for years on two other operating systems, which is the subject of section 7.

7. Apple ESF, Linux eBPF, and the Comparative Architecture

Microsoft did not invent the architecture it is shipping. Two other major operating systems had already picked a different answer years earlier, in opposite directions, and Microsoft's own platform team had been quietly experimenting with both for years before committing to one in public. The comparative-architecture frame matters because it tells us what is genuinely novel about the WRI (very little) and what is genuinely novel about the political moment (almost everything).

Apple Endpoint Security framework, October 7, 2019

On October 7, 2019, with the release of macOS 10.15 Catalina, Apple deprecated third-party kernel extensions for security tools and replaced them with the Endpoint Security framework, a user-space API for authorization (ES_EVENT_TYPE_AUTH_*) and notification (ES_EVENT_TYPE_NOTIFY_*) events fired by the macOS kernel and consumed by Apple-signed user-mode system extensions written by third-party vendors [@apple-esf-docs].

Apple's user-space-only API for security tools, introduced with macOS Catalina (10.15) in October 2019 [@apple-esf-docs]. ESF clients run as system extensions in user mode, subscribe to authorization and notification events emitted by the macOS kernel (process creation, file open, network connect, etc.), and may return `ES_AUTH_RESULT_DENY` to block authorization events synchronously. There is no third-party kernel code path; the kernel signals the user-space client, and the user-space client decides.

What makes ESF the cleanest reference point for the WRI is that ESF is the architecture Microsoft is now shipping under a different label. Both are platform-curated user-mode subscription APIs. Both eliminate third-party kernel drivers from the AV path. Both retain a synchronous authorization gate that lets the vendor's user-mode code answer "allow or deny" before the operating system completes the operation.

The September 2024 Sequoia bug -- the natural experiment we met in section 4 -- is the cleanest available test of whether the ESF architecture contains the blast radius of a 1st-party platform regression. CrowdStrike Falcon for macOS, ESET Endpoint Security, Microsoft Defender for Mac, and SentinelOne all lost network filtering when macOS 15 deprecated the Application Firewall property-list interface [@bleepingcomputer-sequoia, @securityweek-sequoia]. None of them brought down macOS. The hosts kept running. Apple shipped 15.0.1 three weeks later [@techcrunch-sequoia]. The Sequoia outage tested the architecture and the architecture held: feature regression, yes; kernel panic at fleet scale, no.

Linux eBPF, and eBPF for Windows

The Linux answer to the same question is in a different direction entirely. Linux does not move EDR out of kernel mode; it keeps EDR in kernel mode and proves the in-kernel code safe before executing it. The technology is extended Berkeley Packet Filter (eBPF), a kernel-resident bytecode virtual machine that runs vendor-supplied probes attached to kernel hook points, with a static verifier that rejects any program whose memory accesses, control flow, or loop bounds cannot be proven safe at load time [@lwn-bounded-loops].

A Linux kernel subsystem that runs vendor-supplied bytecode programs in kernel context, gated by a static verifier that rejects programs whose memory accesses or control flow cannot be proven safe at load time. eBPF programs attach to hook points (syscall enter/exit, file system events, network packets, tracepoints) and emit data to user space via ring buffers and maps. The Linux EDR industry (Cilium, Tetragon, Falco) is built on eBPF [@lwn-bounded-loops].

The eBPF verifier is non-trivial. Jonathan Corbet's June 2019 LWN article "BPF and bounded loops" describes the Linux 5.3 extension that lifted the original verifier's strict no-loops restriction, permitting bounded loops with statically-determinable trip counts -- enough to write nontrivial in-kernel programs without sacrificing the verifier's termination guarantee [@lwn-bounded-loops]. Every major Linux EDR product in 2026 ships an eBPF probe set as its primary collection substrate.

Microsoft has eBPF for Windows. Microsoft has had eBPF for Windows publicly on GitHub since May 2021, ported the PREVAIL verifier as its formal foundation, and continues to develop the project at the same repository [@msft-ebpf-windows, @ebpf-windows-commits].PREVAIL is the academic verifier whose formal soundness arguments are the foundation of eBPF for Windows. Its design takes the same general approach as the Linux verifier -- abstract interpretation over the bytecode's control flow graph -- and shipped as the open-source verifier Microsoft adopted for the Windows port. Microsoft has shipped eBPF for Windows for networking-centric use cases (XDP-style packet filtering); EDR has not been the primary published use case [@msft-ebpf-windows]. What Microsoft has not done is make eBPF for Windows the substrate of the WRI's third-party EDR architecture. The WRI commits to the Apple-style "exit the kernel" answer, not the Linux-style "stay in the kernel but verifier-bounded" answer.

The three architectural answers

There are exactly three serious architectural answers to the question of where the third-party security observer runs.

Exit the kernel: subscribe from user mode against a platform-curated broker. Apple ESF since 2019; Windows endpoint security platform since the July 2025 private preview.
Stay in the kernel, but only as a verifier-bounded extension. Linux eBPF; eBPF for Windows since 2021.
Operate from below the kernel, in the hypervisor. The Garfinkel and Rosenblum NDSS 2003 origin paper on virtual machine introspection [@wiki-vmi], the Xen Project's VMI APIs [@xen-vmi], Bitdefender's Hypervisor Introspection product shipped commercially in 2016 [@xen-vmi], and Microsoft's own in-platform Virtualization-Based Security (VBS), Hypervisor-protected Code Integrity (HVCI), and Secure Kernel features [@mslearn-hvci].

flowchart TD Q["Where does the third-party security observer run?"] Q --> A1["1. User mode, subscribing via platform broker"] Q --> A2["2. Kernel mode, verifier-bounded extension"] Q --> A3["3. Hypervisor, below the guest kernel"] A1 --> A1a["Apple ESF, since 2019"] A1 --> A1b["Windows endpoint security platform, since 2025"] A2 --> A2a["Linux eBPF"] A2 --> A2b["eBPF for Windows, since 2021"] A3 --> A3a["Bitdefender Hypervisor Introspection, 2016"] A3 --> A3b["Microsoft VBS, HVCI, Secure Kernel"]

Why Microsoft picked (1) over (2)

This is one of the article's most interesting decisions, and the public reasoning is mostly implicit. The eBPF answer (2) would have required every EDR vendor to rewrite on a substrate they had no muscle memory for. The Linux EDR industry took roughly five years to converge on eBPF as its dominant collection mechanism, and Windows EDR vendors have invested in a different abstraction (kernel callbacks plus minifilters) for twenty-five years. A migration to eBPF for Windows would have meant a multi-year vendor-side rewrite to a verifier whose published EDR-attach-point coverage in mid-2026 was incomplete [@msft-ebpf-windows].

The Apple-style answer (1), by contrast, lets vendors keep most of their detection logic where it already runs -- in user-mode sensor processes -- and only replaces the Ring-0 collection substrate with a platform broker. The migration is incremental rather than ground-up. And answer (1) carries a second structural advantage: even a perfect eBPF verifier still leaves vendor bytecode running inside the kernel, where a content-validator failure can still produce a runtime fault under a verifier that proved safety at load time. Answer (1) makes the question unaskable by construction: there is no third-party kernel code path, so a third-party content-validator failure cannot crash the kernel.

Microsoft made a comparative-architecture bet. The bet has a known cost: things a kernel-mode observer can see that a user-mode observer cannot. What exactly does the user-mode EDR lose? That is section 8.

8. What User-Mode EDR Cannot See

Every architectural choice closes some doors. The user-mode EDR architecture closes the door on Channel-File-291-class reliability incidents -- by construction, a vendor-authored data file consumed by a vendor-authored user-mode process can crash the vendor process, not the host. The same architecture, on its own, opens three coverage doors a kernel-callback EDR closed. This section enumerates them honestly.

Gap 1: direct syscall observation

A malicious user-mode process can issue x86-64 syscall instructions directly, bypassing ntdll.dll's exported stubs and therefore bypassing any user-mode hook layer that depends on patching those stubs [@mdsec-direct-syscall]. MDSec's December 2020 write-up "Bypassing user-mode hooks and direct invocation of system calls for red teams" documented the technique in operational detail: an attacker recovers the syscall numbers from a clean copy of ntdll, emits the syscall instruction inline in their own payload, and the operating system services the syscall without ever touching the hook layer the EDR vendor injected into ntdll [@mdsec-direct-syscall]. A user-mode EDR sees only what the platform broker tells it. For the broker to maintain coverage of direct-syscall payloads, the broker itself must be wired into the syscall dispatch path -- the place inside nt!KiSystemServiceCopyArgs where the kernel dispatches user-mode syscalls -- and emit telemetry for every syscall, not only those that arrive via the ntdll stubs.

Microsoft has stated this architecture is in scope but has not published the wire-format detail of the syscall broker as of mid-2026. The honest reading: Microsoft owns this gap, it knows it owns this gap, the EDR partners know Microsoft owns this gap, but the specific shape of the broker's syscall-path integration has not been publicly documented. Treat any third-party claim about the broker's syscall-path wire format as speculation.

Gap 2: rootkit visibility, and the hypervisor answer

A kernel-mode rootkit -- loaded via a Bring-Your-Own-Vulnerable-Driver attack against a signed-but-vulnerable third-party driver -- can hide processes, files, registry keys, and network state from any user-mode observer. The platform broker will emit whatever the kernel sees about the system state; if the rootkit lies to the kernel via DKOM, the broker will faithfully emit the lie.

An attack technique in which a malicious user-mode payload loads a signed, legitimately-issued kernel driver that has a known unfixed vulnerability, then exploits the driver's vulnerability to gain Ring-0 code execution. Because the driver is legitimately signed, neither Windows driver-signing enforcement nor most heuristic load-time defenses block the initial driver load; the attacker gets kernel privilege via a third-party driver they did not have to author or sign themselves.

Microsoft's stated answer for the rootkit-visibility gap is to layer a generation of hypervisor-assisted memory introspection below the user-mode EDR. Bitdefender shipped the first commercial Hypervisor Introspection product in 2016 on top of Xen [@xen-vmi]. Academic work has continued: The Reversing Machine (Karvandi et al., May 2024, arXiv:2405.00298) describes a contemporary research-grade implementation using Intel Mode-Based Execution Control to intercept user-kernel mode transitions and a suspended-process-creation technique to attach hypervisor-based introspection to running guests transparently [@trm-arxiv-2405-00298].

Microsoft's family of in-platform virtualization-based security primitives. *Virtualization-Based Security (VBS)* runs a Hyper-V-derived hypervisor below the Windows kernel, creating two virtual trust levels (VTL0 for the normal kernel, VTL1 for the Secure Kernel). *Hypervisor-protected Code Integrity (HVCI)* enforces that kernel-mode pages are either writable or executable but never both, and that only signed code can be loaded into kernel mode; the enforcement runs in the Secure Kernel and cannot be subverted from VTL0 [@mslearn-hvci].

The Microsoft-side equivalent of the Bitdefender HVI architecture is the family of platform features documented under VBS, HVCI, and the Secure Kernel [@mslearn-hvci]. The Secure Kernel is, architecturally, exactly the vantage from which a hypervisor can read guest memory authoritatively and answer questions about kernel state that the guest kernel itself cannot be trusted to answer correctly. Whether the Windows endpoint security platform's broker will surface that authoritative read to third-party EDR partners -- and through what API -- is part of the not-yet-public detail of the platform.

Gap 3: tamper resistance of the EDR process itself

A user-mode EDR is a user-mode process. Malware that obtains SeDebugPrivilege -- usually by abusing a misconfigured service account or a credential-stealing exploit -- can in principle suspend or terminate the EDR process. The Windows mitigation for this class of attack is Protected Process Light (PPL), the same mechanism Microsoft uses to harden MsMpEng.exe (the Microsoft Defender Antimalware Service) against tampering by anything short of a kernel-mode attacker. Whether the Windows endpoint security platform's user-mode EDR processes will get PPL by default in the private preview, and whether they will get a stronger Protected Process classification, is not documented in any primary source as of mid-2026.

The BYOVD coverage question, with a dated negative finding

The CISA Eviction Strategies Tool countermeasure CM0058 names the four enforcement substrates that activate Microsoft's Vulnerable Driver Block List: "Microsoft's vulnerable driver blocklist is a native utility for Windows 11 2022 and above that receives updates 1-2 times per year... enforced when Hypervisor-protected coded integrity or HVCI, Smart App Control, or S mode is active" [@cisa-cm0058, @mslearn-driver-block-rules]. The block list itself is a Microsoft-maintained allow-list of non-allowed kernel drivers -- specifically, the signed-but-vulnerable drivers known to be abused for BYOVD attacks.

Note: Neither CISA's CM0058 page nor any Microsoft public document publishes aggregate telemetry on what fraction of Windows enterprise endpoints have any of the four enforcement substrates (HVCI, Smart App Control, S Mode, or App Control for Business) active in mid-2026 [@cisa-cm0058]. Microsoft Defender for Endpoint surfaces per-tenant Memory Integrity enablement recommendations; Microsoft has not aggregated those recommendations into a fleet-level statistic. The BYOVD enforcement coverage gap is known qualitatively (the block list exists; enforcement is opt-in via four substrates; updates are infrequent) but cannot be quantified from public evidence.

The kernel attack surface that nothing in user mode can observe

Below all of this -- below user-mode EDR, below kernel-mode EDR, below the Secure Kernel -- lies the genuine bottom of the stack: bootkits, System Management Mode resident malware, firmware implants, and pre-boot attacks that compromise the host before any antivirus product has loaded. No user-mode EDR can meaningfully observe any of this. No kernel-mode EDR can fully observe any of this either. The platform answers are Secured-core PC, Microsoft Pluton, and Measured Boot -- platform-curated, Microsoft-owned, hardware-rooted defenses that the third-party industry does not write code inside of. The WRI does not close the firmware gap; it delegates the firmware gap to Microsoft platform features. That delegation is exactly what Microsoft has always wanted (the platform owns the security boundary) and exactly what vendors have always resisted (the platform owns the security boundary). July 19, 2024 is the day vendors stopped publicly resisting.

The coverage matrix

The coverage tradeoffs in one table. Cells mark the architecture's native ability to observe each visibility primitive: full coverage, partial coverage, or none.

Visibility primitive	Kernel-callback EDR	User-mode EDR + broker	Hypervisor introspection	Microsoft platform features
Direct syscall (no `ntdll` stub)	full (via syscall path hooks)	partial (depends on broker wire format)	full (from VTL1)	full (by construction)
Rootkit visibility (DKOM)	partial (rootkit can subvert peer-driver views)	none (broker reflects kernel-reported state)	full (authoritative memory read)	full (via Secure Kernel)
Tamper resistance of the EDR process	partial (kernel access lets attacker disable peer driver)	partial (PPL needed)	full (out of band)	full (Defender uses PPL today)
BYOVD detection	partial (post-load only)	none (vendor cannot reload kernel)	partial (post-load, via VTL1 inspection)	full (Vulnerable Driver Block List + HVCI, where enabled)
Bootkit, SMM, firmware visibility	none	none	partial (pre-OS attestation only)	full (Secured-core PC, Pluton, Measured Boot)

Key idea: The user-mode EDR architecture closes the reliability problem (a Channel-File-291-class bug crashes a user-mode process, not the kernel). It does not, on its own, close the coverage problem. The coverage problem is being delegated from vendor EDR to Microsoft platform features -- to the Vulnerable Driver Block List, to HVCI, to the Secure Kernel, to Pluton, to Defender's baseline detection coverage. Whether that delegation reaches Method-A coverage equivalence is the open architectural question of mid-2026, and the honest answer is "we do not yet know."

What else is genuinely open? That is section 9.

9. What Is Still Open in mid-2026

What does the honest answer look like, twenty-three months after the outage and twelve months after the WRI's detailed rollout? Several dated negative findings and one positive finding, and the right epistemic posture for reading them is the same posture security engineers should bring to any architectural transition in flight: the absence of an announcement is its own evidence.

Has Microsoft committed to a date by which third-party AV kernel drivers will be forbidden?

No primary source uses the words "ban" or "deadline" or any equivalent hard-stop phrasing. The November 18, 2025 Microsoft Windows Experience Blog frames the program as an enforcement migration -- "shifts AV enforcement from the kernel to user mode" -- and the June 26, 2025 Weston post commits to the private preview as a step in a partner-coordinated journey, not as the first of two phases ending in a third-party kernel-driver lockout [@ms-nov-2025, @weston-2025-06-26]. The article describes the transition as multi-year, partner-coordinated, and without a published hard deadline as of mid-2026. Anyone telling you Microsoft has committed to a date is reading something into the public record that the public record does not contain.

Will the WRI user-mode EDR APIs reach feature equivalence with today's kernel-callback EDR?

The on-record partner statements quoted in the June 26, 2025 blog use hedging language: "continue to provide feedback," "no degradation in security or performance," and similar [@weston-2025-06-26]. That phrasing is not a claim of equivalence achieved; it is a claim of commitment to work toward equivalence. The strongest evidence equivalence is reachable is Apple's seven-year ESF deployment: by 2026, every major Windows-side EDR vendor also ships a macOS-side ESF-based product, and the macOS-side product is broadly considered competitive in detection coverage with peer kernel-based products on other platforms. The Windows answer for mid-2026 is empirically unknown -- the API surface is in active evolution, and the partner cohort is still inside the private preview.

Has any MVI 3.0 deployment ring actually halted a vendor content update since June 26, 2025?

This is the most important operational question and the one with the most honest negative answer. No public primary source documents either a ring stop-gate event (an MVI 3.0 partner caught a latent Channel-File-291-class bug at a canary ring and halted the rollout before fleet propagation) or a ring-escape incident (a latent bug got through the rings and produced a fleet event) from any of the eight named MVI 3.0 partners through the most recent search horizon. The SentinelOne May 29, 2025 cloud control-plane outage [@sentinelone-may-29-rca] is structurally orthogonal to the failure mode the rings are designed to catch -- per SentinelOne's own RCA, "a software flaw in an outgoing infrastructure control system triggered an automatic function that removed critical network routes" and "customer endpoints remained protected" throughout -- so it does not stress-test the rings. The honest framing has two competing readings: the rings are working silently, or the rings have not yet been stress-tested by a Channel-File-291-class latent bug in any partner's content pipeline. Neither reading can be discriminated from current public evidence.The SentinelOne May 29, 2025 event is the closest post-WRI partner-side reliability incident on the public record, and it is worth a paragraph of distinction. The failure was a cloud control-plane network-routes deletion that knocked SentinelOne's customer-facing management console offline; per the company's own RCA, customer endpoints remained protected throughout, federal environments were not impacted, and no endpoint content update was involved [@sentinelone-may-29-rca]. The event is exactly the kind of reliability incident the MVI 3.0 rings are not designed to catch -- the rings address Safe Deployment Practices for sensor and content updates, not cloud control-plane reliability.

Will Microsoft hold itself to the same kernel-out standard as MVI partners?

The November 18, 2025 Microsoft Windows Experience Blog uses the framing "AV enforcement" (not "third-party AV enforcement") -- by plain reading this commits Microsoft Defender for Endpoint to the same trajectory as the third-party MVI 3.0 cohort [@ms-nov-2025]. The article notes this as the closest available public Defender-kernel-out signal, while being honest that no Defender-specific GA date for the user-mode migration has been published. The same November 18 post explicitly carves out the graphics-driver exemption [@ms-nov-2025] -- which by plain reading means that non-AV third-party kernel drivers will continue to ship under the existing model. The WRI is, narrowly, an AV-enforcement migration.

In June, we released the first private preview of the Windows endpoint security platform, which shifts AV enforcement from the kernel to user mode... Graphics drivers, for example, will continue to run in kernel mode for performance reasons. -- Microsoft Windows Experience Blog, November 18, 2025 [@ms-nov-2025]

Note: The MVI 3.0 ring question -- has any partner actually halted a rollout at a ring boundary since June 26, 2025? -- admits two readings from current evidence. Reading one: the rings are working silently, catching latent bugs that never become public, because the entire point of a working ring is that nothing happens. Reading two: the rings have not yet been stress-tested by a Channel-File-291-class latent bug at any partner. Both readings are consistent with the dated negative finding "no public stop-gate event has been documented." Anyone telling you they know which reading is right is overclaiming. The right epistemic posture is to keep watching, and to read partner-side RCAs as they appear.

What fraction of enterprise Windows endpoints enforces the Vulnerable Driver Block List?

The CISA CM0058 page is the canonical document and it publishes no enablement telemetry [@cisa-cm0058]. Microsoft's own documentation for the block list publishes update cadence (one to two times per year) and a per-substrate description of where the block list activates (HVCI, Smart App Control, S Mode, or App Control for Business) but no aggregate fleet-level enablement statistic [@mslearn-driver-block-rules, @cisa-cm0058]. Microsoft Defender for Endpoint surfaces per-tenant Memory Integrity enablement recommendations but does not aggregate. The BYOVD enforcement gap is known qualitatively and cannot be quantified from public evidence as of mid-2026. Anyone publishing a percentage figure for HVCI enablement across the global Windows enterprise fleet is publishing a guess.

These are five open questions with five honest answers. The reader leaves section 9 knowing not the answers, but the shape of the questions -- which is the right epistemic state in which to read the practical guide that follows. What should you do, mid-2026, with this knowledge? That is section 10.

10. Practical Guide for mid-2026

Three audiences, three different sets of next moves. The article has been writing for these three audiences since the first paragraph -- the Windows enterprise administrator, the security-product architect, and the incident responder -- and each gets a short, concrete checklist that respects the open architectural questions of section 9.

For the Windows enterprise administrator

Treat your antivirus and EDR vendor's update cadence as part of your fleet's blast radius. The cadence of vendor content updates is, in mid-2026, the operational variable most likely to produce your next mass-availability incident. Ask your vendor for their MVI 3.0 documentation and verify they are running staged deployment rings rather than gating only at a single global GA promote [@mslearn-mvi, @weston-2025-06-26].
Enable Quick Machine Recovery on Windows 11 24H2 and later [@mslearn-qmr]. QMR is the platform-level recovery primitive Microsoft built specifically for Channel-File-291-style on-disk persistence pathology, and it materially reduces recovery time for any future event that produces unbootable hosts at scale [@insider-build-26120-4230].
Enable HVCI / Memory Integrity wherever your hardware supports it [@mslearn-hvci]. HVCI is one of the four substrates that activates Microsoft's Vulnerable Driver Block List, and enabling it brings the BYOVD blocklist from a published-but-inert resource to an enforced runtime control on your endpoints [@mslearn-driver-block-rules, @cisa-cm0058].
If your fleet still depends on a kernel-only AV stack, push your vendor for their Method-C (user-mode) roadmap commitments. The MVI 3.0 partner cohort named in Weston's June 26, 2025 post is the right reference list: vendors not on it have not made a public commitment of equivalent specificity, and that should affect your procurement calculus [@weston-2025-06-26].
Audit your Defender exclusion list. The principle of least privilege applies to your AV configuration just as much as to your user accounts -- every exclusion is a path past your detection coverage, and Defender exclusions inherited from 2018 deployments are a routine finding in modern enterprise audits.

For the security-product architect

Apply for MVI 3.0 partnership and request access to the Windows endpoint security platform private preview now [@mslearn-mvi]. The API surface is in active evolution and partner feedback is materially shaping the contract. Vendors who wait for GA will inherit a contract written by competitors.
Plan a migration roadmap from kernel callbacks (Method A) to user-mode subscription (Method C). Assume Method A remains the bridge for several more years and that a hybrid Method-A-plus-Method-C deployment will be your production reality through at least the late 2020s. Engineer for Method C as the future-primary substrate while Method A continues to carry production detection coverage.
Engineer your content delivery pipeline as if the platform will eventually require ring-based staged deployment under contractual gating. The MVI 3.0 deployment-ring requirements are the model: internal ring, canary ring, GA ring, with monitored promotion gates between each [@weston-2025-06-26]. Build the pipeline now even if the contractual requirement does not yet bind you, because the alternative is rebuilding it under emergency pressure later.
For BYOVD coverage and rootkit visibility you cannot get from user mode, design around platform features rather than rebuilding them yourself. The Vulnerable Driver Block List, HVCI, Secured-core PC, Pluton, and Defender's baseline are platform-curated controls; layer your detection coverage on top of them rather than parallel to them [@mslearn-driver-block-rules, @mslearn-hvci, @cisa-cm0058].
Treat the Apple ESF deployment as your reference implementation. Your macOS-side ESF migration -- which most major Windows EDR vendors completed between 2019 and 2024 -- is the closest analogue to the Windows-side migration you are now starting. The architectural lessons transfer; do not repeat the early-ESF mistakes on the Windows side.

For the incident responder

The on-disk artifacts from the July 19 outage -- C-00000291*.sys channel files, the minidumps with csagent.sys+0x... frames -- are the canonical reference set for "vendor-content-update-bug-checks-kernel-driver" investigations [@ms-secblog-2024-07-27]. Treat any future "vendor module + nt!KiPageFault + unmapped address" stack as structurally analogous and apply the same runbook posture.
The next analogous incident will look the same in the dumps. The faulting module name will be different; the offset will be different; the unmapped address will be different. The pattern -- vendor kernel module, page fault from nt!KiPageFault, unmapped read address in the high half of the canonical address space, PAGE_FAULT_IN_NONPAGED_AREA -- will be identical.
Build playbooks now for "vendor content update reverted but on-disk-persisted" scenarios. QMR is the platform answer [@mslearn-qmr], but your runbook is what gets your fleet through the first hour before a Microsoft-provided recovery flow is appropriate. The first-hour runbook for July 19, 2024 was "safe-mode boot, delete the file, reboot," and it is worth having that runbook in your incident playbook today for the next analogous event.
Document your AV/EDR vendor's incident-response point of contact and their SLA. The July 19 morning was characterized by vendor-side communication latency in the first hour, not by lack of platform recovery options. Pre-staging the vendor's IR contact and your fleet-wide content-revert process will compress your time-to-mitigation by orders of magnitude.

A cross-platform reality check

A practitioner moving from macOS to Windows in 2026 will find that macOS gave them one architecture (Method C since 2019), Linux gave them one architecture in the opposite direction (eBPF dominant), and Windows is the transitional platform where Methods A, B, C, D, E, and F all coexist in different states of deployment. The architectural choice on Windows in 2026 is not "which method"; it is "which combination, and how to migrate from your current combination to your target combination." That is the bridge-year reality, and it will be the bridge-year reality through at least the late 2020s.

Note: Mid-2026 is the bridge year. Your job is to design for the bridge, not for either bank.

11. Common Misconceptions

Six questions a careful reader will already have answered for themselves, restated here for the reader who arrived at this section via the table of contents.

No. Microsoft Windows behaved exactly as the kernel-driver architecture requires it to behave when a third-party kernel driver faults at elevated IRQL: the kernel had no way to recover, so it stopped. The bug was in CrowdStrike's `csagent.sys` driver consuming a malformed CrowdStrike Channel File. Microsoft's own July 27, 2024 security blog is unambiguous about this: the WinDBG walkthrough names `csagent.sys` as the faulting image and `nt!KiPageFault+0x369` as the kernel handler that received the fault [@ms-secblog-2024-07-27]. The architectural responsibility for the post-outage migration sits with Microsoft as the platform owner, but the proximate technical cause was a third-party kernel driver consuming a third-party content file [@cs-rca-2024-08-06]. Not necessarily. The user-mode EDR architecture closes the *reliability* problem -- a Channel-File-291-class bug in a vendor's content pipeline crashes the vendor's user-mode process, not the kernel. For the *coverage* gaps that user-mode loses on its own (direct syscalls, rootkit visibility, BYOVD detection), Microsoft is layering platform features below the user-mode EDR: hypervisor-assisted introspection via VBS and HVCI [@mslearn-hvci], the Vulnerable Driver Block List for BYOVD [@mslearn-driver-block-rules, @cisa-cm0058], and Defender as the baseline detection floor. Whether the combined stack reaches coverage equivalence with today's kernel-callback EDR is the article's central open question and the honest mid-2026 answer is that it is not yet settled [@weston-2025-06-26, @ms-nov-2025]. The strongest available public signal as of mid-2026 is the November 18, 2025 Microsoft Windows Experience Blog framing that *"AV enforcement"* (not *"third-party AV enforcement"*) is shifting from kernel to user mode -- by plain reading, that includes Defender for Endpoint [@ms-nov-2025]. No Defender-specific GA date for the user-mode migration has been published. The same November 18 post explicitly carves out graphics drivers, which continue to ship in kernel mode for performance reasons -- so the WRI is, narrowly, an AV-enforcement migration and not a wholesale third-party kernel-driver lockout [@ms-nov-2025]. Probably elevated, but no public primary source establishes the specific IRQL value. The article says only that the fault occurred at an interrupt request level high enough that the kernel could not unwind to a structured exception handler in any meaningful way. Treat any IRQL-specific claim about Channel File 291 from a third-party source as speculation unless they cite a primary source that publishes the value. Microsoft's own July 27, 2024 post-mortem reproduces the WinDBG dump but does not publish the IRQL value at the moment of the fault [@ms-secblog-2024-07-27]; neither does CrowdStrike's August 6, 2024 Root Cause Analysis [@cs-rca-2024-08-06]. No. The Microsoft response is squarely a U.S.-side platform-stewardship response to a U.S.-litigated incident. European regulatory frameworks were part of the policy backdrop, and U.S. federal frameworks (Government Accountability Office, Congressional Research Service, House Homeland Security Subcommittee) shaped the political environment [@gao-24-107733, @crs-if12717-everycrsreport, @homeland-hearing-page, @govinfo-chrg-118hhrg60030]. But the proximate political cause was the operational loss of 8.5 million Windows hosts and the Congressional accountability event that followed; no regulatory body mandated the WRI's specific architectural choices. Architecturally it is not different in any structural way. Both were vendor content updates that caused vendor kernel drivers to misbehave at fleet scale. McAfee DAT 5958 was a false positive on `svchost.exe` that triggered the McAfee kernel driver to quarantine the system file, putting Windows XP SP3 fleets into reboot loops [@uscert-mcafee-2010, @sans-isc-8656, @askperf-mcafee]. CrowdStrike Channel File 291 was a parameter-count mismatch that triggered the CrowdStrike kernel driver to dereference an unmapped address, producing `PAGE_FAULT_IN_NONPAGED_AREA` [@cs-rca-2024-08-06]. The differences were the *scale* of the 2024 event (8.5 million Windows hosts versus a far smaller XP fleet in 2010) and the *cost calculus* -- by 2024, fourteen years of recurring kernel-driver-bricks-fleet incidents had raised the political cost of doing nothing past the point where Microsoft could be politically attacked for taking action [@three-buddy-ep5].

The seventy-eight-minute window of July 19, 2024 collapsed twenty years of political resistance to the Vista-era idea that vendor-authored kernel-mode code is a fleet-scale reliability liability, and accelerated Microsoft's Windows Resiliency Initiative into a multi-year, partner-coordinated migration that puts third-party endpoint security where Apple put it in 2019 [@apple-esf-docs] and where Microsoft itself had been quietly building the platform pieces since at least 2021 [@msft-ebpf-windows, @mslearn-hvci]. The 8.5 million figure from Brad Smith's morning-after blog post [@ms-bradsmith-2024-07-20] is the empirical anchor that supplied the political license; the Toulouse 2006 quote "either everybody has access to the kernel, or nobody does" [@informationweek-2006-toulouse] is the historical anchor that supplied the architectural answer; the Ionescu pivot of April 3, 2025 [@cs-ionescu-ctio-2025-04-03] is the political anchor that demonstrated the answer would not be fought.

Whether user-mode EDR with hypervisor-assisted memory introspection can deliver the coverage equivalence that twenty-five years of kernel-mode hooking has built is the next decade's research problem, and the honest mid-2026 answer is we do not yet know. The macOS seven-year ESF deployment supplies the strongest available yes evidence; the not-yet-stress-tested MVI 3.0 rings supply the strongest available not-yet-discriminated evidence; the BYOVD enforcement gap that no public source quantifies supplies the strongest available honest concern [@cisa-cm0058].

Key idea: July 19, 2024 did not invent the architecture; it provided the political license for an architecture two other operating systems had already validated. The next several years will tell us whether the architecture, transplanted to Windows under the WRI, reaches feature equivalence with the kernel-mode hooking it replaces, or whether the equivalence question is the wrong question and the right question is whether the platform features layered below the user-mode broker close enough of the coverage gap. The honest answer mid-2026 is that the question is genuinely open, and the next public evidence -- the first MVI 3.0 ring stop-gate event, the first Defender-kernel-out GA, the first quantified HVCI enablement statistic -- is the evidence to watch for.

Companion articles in this series cover the substrate pieces in more depth: EDR/Sysmon as the canonical user-mode consumer of kernel ETW telemetry [@mslearn-sysmon]; Vulnerable Driver Block List as Microsoft's BYOVD platform mitigation; Process Mitigation Policies and Defender for Endpoint baselines; and Event Tracing for Windows as the cross-cutting platform observability substrate.

Picture the release engineer at the CrowdStrike Falcon Cloud rollout console at 04:09 UTC on a Friday morning in July 2024, watching the deployment indicator go from staging to production for Channel File 291, with no idea that the seventy-eight-minute window about to open would be the most consequential window in twenty-five years of Windows security architecture. The engineer did everything right; the architecture, on that morning, did exactly what twenty-five years of decisions had configured it to do; and the next two years of Microsoft platform engineering, vendor-side rewrites, and political alignment exist to make sure that the next time something similar happens, it does not look like that.

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.