Hidden telemetry — the 2,600 Windows ETW providers nobody is reading.

Asuka Nakajima (Elastic) asks a simple question with a big answer: Windows ships roughly 920 manifest-based ETW providers that every EDR and researcher knows, but also about 2,600 TraceLogging providers that almost nobody has catalogued. TraceLogging events are self-describing, unregistered and undiscoverable with standard tools, which is why they stayed hidden. Nakajima built TLGMapper, an IDA Python script that statically maps every event to its owning provider, surveyed Windows 11 and Windows Server 2025, and found about 2,670 providers and 73,000 unique events. Several look genuinely useful for detection: kernel attack-surface monitoring, UEFI variable access, and ShellExecute. This is defensive research, and the tool and data are public.

Post 19 of my Black Hat Asia 2026 series. If the previous post was about doing more with the telemetry you already have, this one is about telemetry Windows already emits that nobody is reading.

1. ETW in five minutes

Event Tracing for Windows (ETW) is the built-in, high-performance tracing framework. Four roles matter:

• Providers are applications, DLLs or drivers that emit events.
• Controllers start and stop trace sessions and decide which providers are enabled and at what level and keyword mask.
• Sessions receive events from enabled providers into buffers, optionally writing .etl files.
• Consumers read events, in real time or from files.

Modern EDR products lean on ETW heavily because it gives cheap, in-kernel-fed visibility into DNS, logon, API and process activity without hooking. If a provider is emitting something interesting, an EDR can subscribe to it.

2. Manifest-based vs TraceLogging

The consequence is an information asymmetry. Defenders can list every manifest provider with a built-in command. For TraceLogging there is nothing to list, so you would need to know the provider's GUID in advance. Nakajima's survey counted the gap: on Windows 11 25H2, about 920 manifest providers against more than 2,600 TraceLogging ones. The unexplored population is nearly three times larger than the well-known one. The most notable earlier work is Matt Graeber's REcon 2019 talk and metadata parser, which showed how to read the format but stopped short of a full event-to-provider map.

3. How TraceLogging metadata is laid out

A TraceLogging provider is defined in code with a name and a GUID, then events are written by name with typed fields. The compiler embeds compact metadata blobs in the binary: a header with a recognisable signature, then a sequence of event blobs (level, keyword, opcode, event name, field names and types) and a provider blob (GUID and provider name), terminated by an end marker. A parser can find these blobs by scanning for the signature and decode names and field types.

That gets you events and providers, but not which belongs to which. The blob stream has no ownership markers. Event A could belong to provider 1 or 2, and if a binary holds several providers you cannot tell from the metadata alone. This "missing link" is the real research problem.

4. TLGMapper: static event-to-provider resolution

There are two ways to establish ownership:

1. Runtime capture: start a trace session, run the program, and see which events appear. Easy, but events that do not fire during your run stay invisible.
2. Static binary analysis: examine the code that references event data and provider structures. No execution needed and theoretically complete, but traditionally slow and manual.

TLGMapper automates option two inside IDA. Stage A extracts metadata: scan for headers, parse blobs to collect event data addresses and provider info, and locate each provider's runtime structure. Stage B resolves relationships: sweep every function for references to event data and provider structures, including call references, then assign each event an owner using a priority chain, first match wins:

Being explicit about the heuristic level is good practice: anyone building detections on top of this data can weight events resolved by rule 1 or 2 above those from rule 4.

5. The survey

Targets were Windows 11 25H2 and Windows Server 2025, scanning 64-bit .exe, .dll and .sys files under the Windows and Program Files directories (excluding the side-by-side store), about 2,564 files on Windows 11 and 2,342 on Server 2025. A few binaries were skipped for permission reasons.

The Windows 11 extras are largely consumer-facing features (family safety, Xbox, web threat defence, biometrics), while both include newer security features such as App Isolation. The author notes a caveat worth repeating: these providers are aimed at Microsoft developers, so event contents can change between builds. A detection that depends on a TraceLogging field is more fragile than one on a documented manifest event.

6. Providers that look useful for security

Attack-surface monitoring in the kernel

A provider in the kernel image reports device creation, device security-descriptor changes, and IOCTL calls (including the device object, the control code and a hash of the device name tail). That is exactly the telemetry needed to spot vulnerable-driver abuse: a process loads a legitimate but flawed signed driver and then talks to it through IOCTLs. Because it observes the IOCTL path, it also helps catch abuse of legitimate drivers, not just known-bad ones. Elastic already ships a behaviour rule that flags a process sending a specific suspend-process control code to a debugging-related driver from an untrusted caller, showing how such fields feed real detections.

UEFI variable access

A kernel system-environment provider logs GetVariable and SetVariable events with variable name, vendor GUID, attributes and status. Uses: notice reconnaissance reads of Secure Boot state, and watch for anomalous writes to UEFI variables that could accompany bootkit or Secure Boot tampering. Firmware-level attacks are notoriously hard to see, so any host-side signal is valuable.

ShellExecute

The provider inside the shell library records ShellExecuteExW calls with verb, file, parameters, directory, mask and window flags. The author observed a consistent mask value when a command is launched through the Run dialog, which suggests a way to spot ClickFix-style social engineering, where users are tricked into pasting a command into Run. He presents this as an idea to validate, not a finished detection.

7. Caveats before you build on this

• Unstable schema. Names and fields are developer-facing and may change between Windows builds. Pin to build numbers and re-test after updates.
• Volume. Enabling many providers is noisy and costs CPU. Enable narrowly and filter early.
• Static mapping is heuristic. Events resolved via call-graph search deserve less trust.
• Visibility is a two-way street. Attackers can also learn what is logged. ETW tampering is an active evasion area, so pair collection with integrity monitoring of the sessions themselves.

8. How a defender can use this today

1. Clone the public repository and run the per-provider event catalog to see what exists on your OS build.
2. Pick one provider that matches a gap in your detection coverage (for example driver abuse or Run-dialog launches).
3. Capture events in a lab: create a trace session, enable the provider by GUID with all keywords, perform the behaviour, and convert the trace to a readable event log.
4. Establish a benign baseline, then design a rule with allow-listing for signed, expected callers.
5. Track the provider across Windows updates and retire the rule if the schema changes.

Takeaways

• TraceLogging is an unexplored telemetry reservoir: ~2,600 providers versus ~920 manifest ones on Windows 11.
• The hard part was event-to-provider ownership; TLGMapper solves it statically with a prioritised heuristic chain.
• The survey found about 73,000 events on Windows 11 and 64,000 on Server 2025.
• Promising detections: IOCTL and device monitoring for driver abuse, UEFI variable access, and ShellExecute for ClickFix-style launches.
• Treat these as experimental: schemas can change, so version-pin and re-test.

References & further reading

• Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
• Official talk recording on YouTube — Black Hat channel.
• Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
• TLGMapper — IDA script, per-provider event catalog and raw CSVs.
• Microsoft: About Event Tracing — ETW concepts and provider types.
• TLGMetadataParser.psm1 — Matt Graeber's earlier metadata parser.
• Elastic protections-artifacts — public behaviour rules, including ones using kernel API telemetry.