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

by Olaf Hartong

Day 1 · Briefings · Threat Hunting · 40 min · 4 min read

Offensive Security

TL;DR

Olaf Hartong showed that Windows ETW, the telemetry backbone behind Defender for Endpoint and most EDRs, has no access controls on provider registration and enforces a hard 1,000-event global cap per provider. Flooding the LDAP provider with 1,001 junk events wipes the cap; a canary process emitting one real query never reaches the cloud console. A second technique registers fake anti-malware provider GUIDs and emits spoofed ransomware detections, generating analyst-drowning alert storms. Hartong released three tools: a Go cap-flooding PoC, an event-spoofer, and ETWTop.

ETW Architecture and How It Works

▶ Watch (00:58)

ETW is a Windows kernel mechanism for performance monitoring and debugging. Microsoft’s own documentation mentions no security use case. The architecture has three parts: providers that emit events, trace sessions that route them, and consumers that read them. The ETW kernel sits in the middle, orchestrating the flow. EDRs use real-time sessions, which buffer events in non-paged kernel memory until the consumer pulls them. Four session types exist: auto-logger (starts at boot), real-time, file logging, and private (in-app only).

Why EDRs Depend on ETW — and the Event Capping Problem

▶ Watch (06:23)

Most EDRs prefer ETW over kernel callbacks because it requires less kernel code, supports precise event filtering by ID and keyword, and buffers events to reduce drops. After last year’s kernel driver stability incidents, vendors like Defender for Endpoint shifted further toward ETW-based telemetry.

The problem: cloud-based EDRs must cap how much data they ship. Defender for Endpoint enforces a global limit of 1,000 unique events per provider per 24 hours. Miss that cap and your events stop arriving at the console. Hartong found this limit in MDE’s provider configuration alongside a per-process “first seen” rule — one LDAP search-filter event per process per day. Both caps exist for cost and bandwidth reasons. Both are exploitable.

ETW Provider Registration: Any Process Can Impersonate Any Provider

▶ Watch (12:46)

Any process with standard user permissions can call EventRegister with a GUID that already belongs to an active provider. The ETW kernel hands back a handle to that existing provider, and both processes can now write events into the same trace session. From the operating system’s view, there is one provider emitting data. The events look identical to the real thing.

The one limit: ETW records a process ID inside each event, but that PID identifies the process that made the connection (the application), not the process that wrote the event. The kernel enforces that field. Everything else, including the event payload and the provider identity, is fully attacker-controlled.

PoC: LDAP Cap Flooding Hides Real Activity from MDE

▶ Watch (22:31)

Hartong wrote his PoC in Go using native Windows API calls. Open-source ETW packages couldn’t control the event headers MDE required. Once spoofed LDAP search-filter events appeared in the cloud console, he pushed past the 1,000-event global cap in the LDAP cap overflow demo (24:06): a legitimate canary.exe process emitting one real query never appeared. He renamed his tool to canary.exe, sent a distinct filter, got nothing back.

“So the canary still lives. He’s happy.” — Olaf Hartong

Cap saturated, he ran his real attack tool.

“you can do whatever you like.” — Olaf Hartong

Anti-Malware Provider Abuse, Alert Storms, and Microsoft’s Partial Fix

▶ Watch (27:32)

The anti-malware service provider had open permissions — anyone could register it and emit events. Hartong wrote a tool that fired fake ransomware detections via anti-malware provider (27:48): real malware names, real detection IDs, fake file paths. MDE logged a thousand of them, hit its cap, and the real payload landed without an alert.

He reported the full list to Microsoft. They closed the ticket — not urgent enough for immediate servicing. Weeks before this talk, preparing demos, he found the AV alert storm no longer triggered. They had quietly patched the anti-malware provider only. Windows Defender and the MDE providers still accepted spoofed events. Microsoft’s stated scope: hardening Defender product providers against non-privileged users. One item fixed out of over a hundred reported.

▶ Watch (32:56)

Flooding a session’s non-paged buffer pool blinds every provider sharing it. When ETW runs out of memory, it tells the provider to stop emitting to all subscribed sessions, including the EDR’s. Hartong started a real-time LDAP trace session without attaching a consumer and blasted events as fast as possible. In the buffer flood blinds EDR trace session live demo (34:41), ETWTop showed the LDAP provider accumulating failures while events dropped to zero. That blind spot holds until reboot. He released two tools alongside the talk: ETWTop, which monitors provider failures and lost events, and Bambuzzu EDR, which automates cap flooding and telemetry simulation for tools like SharpHound.

“you can’t trust your logs anymore, right?” — Olaf Hartong

Notable Quotes

you can do whatever you like. Olaf Hartong · ▶ 26:05

So the canary still lives. He’s happy. Olaf Hartong · ▶ 25:43

you can’t trust your logs anymore, right? Olaf Hartong · ▶ 38:35

Key Takeaways

Flood any ETW provider’s global event cap to guarantee your real attack traffic never reaches the EDR cloud console.
Spoof ETW events as a legitimate provider to generate fake alerts that pull analysts away from the real intrusion.
ETW buffer flooding blinds every session sharing a provider until reboot — no kernel driver or special privilege required.

Filed under

Offensive Security