I'm in Your Logs Now, Deceiving Your Analysts and Blinding Your EDR

I'm in Your Logs Now: Deceiving Analysts and Blinding EDRs Through ETW Event Spoofing

Speaker: Olaf Hartong, Falcon Force

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=G3Ft0gtmm4I

Reading Time: ~10 minutes

Type: Briefing

TL;DR

Olaf Hartong of Falcon Force demonstrated that the Event Tracing for Windows (ETW) subsystem — which Microsoft Defender for Endpoint, CrowdStrike, and other major EDRs rely on for telemetry — can be abused by low-privileged attackers to inject fake events, trigger false alerts, flood EDR telemetry caps, and ultimately blind detection platforms to real malicious activity. A companion tool, ETWSpoof, and a monitoring utility, ETWtop, were released at the talk. Microsoft issued a partial fix targeting Defender's anti-malware provider on the day of the briefing.

Introduction

Event Tracing for Windows (ETW) was designed by Microsoft as a high-performance, low-overhead logging infrastructure for diagnostics and debugging — not as a security primitive. Yet it has become foundational to the modern Windows security stack. Endpoint Detection and Response (EDR) products rely on ETW providers for a substantial portion of their telemetry: network connections, LDAP queries, process creation, image load events, and more arrive via ETW sessions rather than direct kernel callbacks.

This architectural dependence creates a problem that Olaf Hartong, detection engineer and red teamer at Falcon Force, spent months uncovering: ETW was never designed with a hostile emitter in mind. Any process with the right permissions — which, for many providers, means no special privileges at all — can register against an existing ETW provider GUID and begin emitting arbitrary events. Those events reach the EDR's telemetry pipeline looking exactly like legitimate events. The EDR cannot tell who really emitted them.

How ETW Works

▶ Watch: ETW Architecture Primer (02:00)

ETW's architecture has three components: providers (sources of events), trace sessions (orchestration layer managed by the ETW kernel), and consumers (processes that read the event stream). There are four types of trace sessions:

• Autologger sessions: Start at boot, registered in the registry, used for persistent collection.
• Real-time sessions: Stream events live to a consuming process — the model used by EDRs.
• File logger sessions: Write events to an ETL file on disk.
• Private sessions: In-process debugging, not consumable externally.

Providers register with a GUID. Each provider has a manifest — an XML file stored in System32 — that defines the event schema: provider name, event IDs, levels, keywords, and field types with their data types. The ETW kernel routes events from providers to subscribed trace sessions, using a buffer pool in non-paged kernel memory as an intermediate cache.

Why EDRs Use ETW

▶ Watch: EDR Dependence on ETW (06:00)

ETW offers EDR vendors several advantages over kernel callback hooks:

• Stability: Less kernel code means lower crash risk — a lesson made vivid by the CrowdStrike incident referenced implicitly during the talk.
• Filtering: ETW sessions can subscribe to specific event IDs and sub-attributes rather than processing a full raw stream.
• Buffering: The buffer pool provides headroom against burst events, avoiding dropped telemetry under load.
• Breadth: Kernel callbacks are limited in the types of events they can surface; ETW providers cover LDAP queries, DNS, network, PowerShell, .NET, and many other telemetry categories that kernel hooks cannot easily reach without process injection.

Hartong's analysis of Microsoft Defender for Endpoint's configuration showed that the product subscribes to dozens of distinct ETW providers alongside its kernel callback registrations. CrowdStrike is known to use a similar model, though its exact configuration was not accessible for analysis.

The Core Vulnerability: Provider Spoofing

▶ Watch: Provider Registration and Spoofing (12:02)

The fundamental issue: any process can call EventRegister with the GUID of an existing ETW provider. If the security descriptor for that provider (stored in the registry) permits registration at the caller's privilege level, the ETW kernel returns a valid handle. Using that handle, the caller can emit events — and those events flow through the existing trace sessions to any subscribed consumers, including the EDR.

ETW does not record which process emitted each event. The process ID field in an ETW event reflects the process that caused the activity being reported, not the process that generated the ETW record. For real network connections, the emitting process is typically a Windows subprocess, not the initiating application. This architectural property means the PID in the event cannot be used to detect spoofed emissions — the ETW kernel manages the process field, but the event content is entirely attacker-controlled.

Hartong wrote a simple enumeration tool that attempted to register each of the ETW providers Defender for Endpoint subscribes to, emit a test event, and observe the output. The initial result was a large number of apparent successes — and a significant number of false positives (kernel-mode providers that accepted user-space registration but did not actually deliver events to the real trace session). After filtering, a meaningful set of providers were confirmed spoofable.

Practical Attacks Demonstrated

▶ Watch: Spoofing Demos and Attack Scenarios (22:03)

LDAP event spoofing: Hartong built a proof-of-concept in Go using the microsoft/etw open-source package to emit fabricated LDAP search events. After extensive debugging (little-endian encoding, field ordering, and GUID formatting were all sources of initial failure), the spoofed events appeared in Microsoft Defender for Endpoint's cloud telemetry. Renaming the emitting binary to canary.exe caused both events to appear separately in the cloud, confirming that Defender's "first seen" deduplication logic treats processes with different names as distinct sources — a useful property for an attacker wanting to generate maximum telemetry noise.

Alert flooding to exhaust the global telemetry cap: Defender for Endpoint (and similar cloud-based EDRs) implement per-machine telemetry caps to control costs and bandwidth. The specific configuration observed has a global cap of 1,000 unique events per 24-hour period for certain provider types, plus per-provider local caps. By emitting over 1,000 events from a single process, Hartong confirmed that only 1,000 appeared in the cloud — the remainder were silently dropped. Crucially, any legitimate activity occurring after that cap is reached for the affected provider becomes invisible to cloud-side detection and to SOC analysts querying historical data.

False positive alert generation: By emitting crafted events matching known attack signatures — for example, patterns associated with SharpHound Active Directory enumeration — Hartong could cause Defender to generate real alerts for activity that never happened. An analyst who investigates such an alert is wasting time on a ghost event while real malicious activity proceeds undetected on another machine.

Conditional access disruption: If Conditional Access policies in Entra ID/Intune block users or devices with elevated risk scores, fabricated security events can push a user's computed risk over threshold — locking them out of corporate resources without any real threat. This can be used to disrupt operations or force incident response activity as a distraction.

Buffer flooding to blind EDR providers: ETW buffers are allocated in non-paged kernel memory and have a fixed size configured when the trace session is started. If an attacker floods a provider's buffer from their own trace session, the buffer fills and the provider reports failure for all subsequent events — including those destined for the EDR's trace session. Because providers are shared: flooding one consumer's buffer prevents the provider from delivering to any subscriber. Hartong demonstrated this against the LDAP client provider, producing sustained delivery failures visible in both the provider's failure counter and the EDR's lost-event count.

ETW trace session exhaustion: Windows limits concurrent ETW trace sessions to 64 per machine. Registering dummy sessions up to this limit prevents EDR vendors from adding additional monitoring sessions. Hartong noted this attack was deliberately left out of the primary tool release given its severity.

Disclosure, Microsoft's Response, and Limitations of the Fix

▶ Watch: Disclosure Timeline and Microsoft's Fix (30:03)

Hartong reported the vulnerability to Microsoft Security Response Center (MSRC) with a full PoC and a list of over 100 spoofable providers. Microsoft's initial response was to fix only the anti-malware ETW provider — the specific one targeted by the PoC. All other providers that Defender for Endpoint relies upon remained open. Microsoft also built AV signatures targeting strings in Hartong's binary, requiring him to obfuscate identifiers to continue testing.

Days before the Black Hat talk, MSRC informed Hartong that a broader fix would be released on August 7 — the day after his briefing. The stated scope: "hardening Defender product providers against non-privileged users." Testing on a Windows Insider build the night before the talk confirmed that the anti-malware provider was no longer registerable by his tool — but the permission model appeared unchanged, suggesting the fix was behavioral rather than ACL-based. The full list of over 100 reported providers remained unaddressed.

At the talk's conclusion, Hartong released:

• ETWSpoof — a tool for emitting custom events across supported ETW providers, usable for detection testing, red team operations, and alert generation.
• ETWtop — a real-time monitoring utility for ETW provider buffer states, event rates, and loss counters. No equivalent public tool previously existed.

Defender Recommendations

▶ Watch: Defense Guidance (36:03)

For defenders, options are limited:

• Use ETWtop (or equivalent) to monitor for log spikes followed by silence — a pattern that may indicate an attacker has exhausted a telemetry cap or flooded a buffer.
• Experiment with ETW provider security descriptors in the registry to restrict emitter permissions, though this carries risk of breaking legitimate software or EDR functionality.
• Use ETWSpoof to verify that custom detections work without running real malicious code on production systems.
• Treat ETW telemetry as potentially unreliable: correlate EDR alerts with kernel callbacks, network sensor data, and other independent telemetry sources before acting on high-severity events.

The fundamental architectural fix requires Microsoft to implement proper authentication of ETW event sources — something ETW was never designed to provide — or to deprecate the shared-provider model in favor of one where EDR-subscribed providers cannot be registered by untrusted processes.

Notable Quotes

"ETW in general doesn't record which process has been emitting whatever the telemetry comes from. So if you do a real network connection, your process will not likely be the one that will be emitting that event."

— Olaf Hartong ▶ 16:02

"You can't trust your logs anymore. We want to use our ETW providers to detect all kinds of malicious use, but as a defender, we have to be mindful of where the telemetry comes from, how it can be tampered with, and how reliable it can be."

— Olaf Hartong ▶ 38:03

"I reported a huge list of over a hundred items, and they at least made a step to start fixing it. But all of the providers that MDE relies on — they won't even touch."

— Olaf Hartong ▶ 30:03

"I can also start generating alerts for that user to get him over that risk level, and he won't be able to access certain resources anymore. So you could imagine, as a red teamer, to annoy the blue team a little bit and get their machines off the network."

— Olaf Hartong ▶ 26:03

Key Takeaways

• Any process with standard permissions can spoof ETW events that flow into EDR telemetry. Provider GUIDs are not access-controlled against emitters in most of the ETW surface area used by Microsoft Defender for Endpoint and similar products.
• EDR telemetry caps can be exhausted in seconds. Defender for Endpoint's 1,000-event-per-24-hour cap on specific providers means an attacker can flood that cap and make subsequent legitimate activity invisible to cloud detection and analyst queries.
• Buffer flooding disables shared providers globally. Flooding a provider's ETW buffer from an attacker-controlled trace session prevents that provider from delivering events to any subscriber — including the EDR's real-time session.
• Fake alerts are operationally viable attack tools. Spoofed events can trigger real EDR alerts for activity that never occurred, consuming analyst bandwidth and potentially triggering incorrect remediation actions.
• Microsoft's fix is incomplete. Only the anti-malware ETW provider has been hardened; the broader ETW security model remains unchanged, and over 100 reported providers were left unaddressed at the time of disclosure.

No slides PDF was listed for this briefing.