ETW Tampering: How Attackers Blind Windows Telemetry (and How to Catch Them)

Almost every serious detection tool on Windows — Defender for Endpoint, Sysmon, most commercial EDR agents, and the built-in audit subsystem — is fed by the same underlying plumbing: Event Tracing for Windows (ETW). ETW is a high-performance, kernel-and-user-mode tracing framework. Providers emit events; sessions subscribe to them; consumers process them. It's elegant, ubiquitous, and — because it's a shared pipe that almost nothing monitors for its own health — an increasingly popular target.

The logic for an attacker is brutally simple. Why fight your EDR's detections one by one when you can cut the wire that carries them? "ETW patching" and "ETW provider tampering" now show up routinely in offensive tooling and in real intrusions. If the telemetry never leaves the endpoint, there is nothing for the SOC to alert on.

How ETW Blinding Actually Works

There are several distinct techniques, and they matter because they leave different fingerprints. Lumping them together is why so many teams miss them.

1. In-process ETW patching (userland)

The classic. Much of the security-relevant telemetry from managed and script runtimes flows through a single function: ntdll!EtwEventWrite (and its relatives). An attacker running code in a process simply patches the first bytes of that function with a ret so every event write becomes a no-op:

; Common EtwEventWrite patch (x64)
; overwrite the function prologue so it returns immediately
xor eax, eax        ; 33 C0   -> STATUS_SUCCESS
ret                 ; C3

This is popular for blinding AMSI/CLR telemetry inside a single malicious process — for example, to run .NET tradecraft without the Microsoft-Windows-DotNETRuntime provider snitching. It's local to the process, so it's cheap and quiet, but it only blinds that process.

2. Killing or reconfiguring trace sessions (system-wide)

A more sweeping approach targets the trace sessions themselves. Autologger sessions — the ones that start at boot and feed products like Defender — are defined in the registry. An attacker with admin can stop a live session or disable its providers:

# Enumerate active trace sessions and their providers
logman query -ets

# Stop a running session (blinds everything consuming it)
logman stop "EventLog-Application" -ets

# Autologgers that start at boot live here:
#   HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\
# Setting a provider's "Enabled" DWORD to 0 disables it on next boot

This is louder and system-wide. It's also where a lot of "the EDR just went quiet" incidents originate — the agent process is still running, but the sessions feeding it have been throttled or emptied.

3. Provider removal and manifest tampering

Attackers can also disable specific providers (e.g. Microsoft-Windows-Threat-Intelligence, the kernel provider several EDRs rely on) or tamper with provider registration so events silently stop flowing while everything looks healthy.

The dangerous property of all three techniques: your dashboards keep showing green. A missing event is not an alert. Absence of signal is the hardest thing to notice — which is exactly why it works.

Why Your Existing Detections Struggle

The uncomfortable truth is that most detection strategies are downstream of ETW, so blinding it degrades the very system you'd use to catch the blinding. A few structural reasons:

• The pipe monitors payloads, not itself. EDRs are tuned to reason about events, not the health of the transport that delivers them.
• Silence is ambiguous. A quiet endpoint could be idle, offline, or blinded. Distinguishing those requires a baseline most teams never build.
• Admin is often all it takes. Session and autologger tampering needs local admin — not a kernel exploit. On a machine where users run as admin, that bar is on the floor.
• Config drift hides intent. A disabled provider looks identical whether an attacker did it or a well-meaning admin "cleaned up logging" two years ago.

What WinSentinel Audits to Catch ETW Tampering

WinSentinel treats the telemetry pipeline as an asset to be audited in its own right — not just a source of events. It inspects the configuration and integrity of ETW itself and flags the tell-tale signs of tampering and weakening:

• Autologger integrity. It enumerates the boot-time trace sessions under HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger and flags security-relevant sessions that are disabled, missing expected providers, or have suspiciously small buffer/retention settings.
• Critical provider coverage. It checks that high-value providers your defenses depend on (kernel Threat-Intelligence, DotNETRuntime, PowerShell, WMI-Activity) are still registered and enabled — not silently dropped.
• Live session sanity. It compares running sessions against the expected baseline so a stopped or emptied session gets surfaced as a finding instead of vanishing into green.
• Audit-policy alignment. ETW tampering usually travels with broader log-suppression (advanced audit policy gutted, PowerShell script-block logging off, Event Log service tampered). WinSentinel correlates these so you see the pattern, not one isolated toggle.

A finding reads like an engineer wrote it, with the exact remediation:

$ winsentinel --audit --modules logging

 Telemetry & Event Tracing
 ─────────────────────────────────────────────────────
 [CRITICAL] Autologger provider disabled: Microsoft-Windows-Threat-Intelligence
   -> Kernel TI provider is registered but Enabled=0 in Autologger\Defender
   -> Several EDRs consume this provider; disabling it blinds them
   -> Fix: reg add ...\Autologger\Defender\{guid} /v Enabled /t REG_DWORD /d 1 /f; reboot

 [WARNING]  PowerShell Script Block Logging is OFF
   -> Common companion to ETW tampering; script telemetry is not being emitted

 [INFO]     6 active trace sessions, 2 below baseline provider count

Hardening: Make Blinding Loud

You cannot make ETW un-patchable — an attacker with code execution in a process can always no-op writes in that process. The goal is to make system-wide blinding difficult and, above all, noisy:

1. Cut standing admin. Session and autologger tampering needs admin. Enforce least privilege so ordinary compromise doesn't hand over the trace subsystem. (See our local-admin and LAPS guidance.)
2. Enable PPL for your security agents. Protected Process Light makes it much harder for malware to reach into the agent's process to patch EtwEventWrite in-memory.
3. Baseline your providers, then alert on absence. Record the expected autologger provider set and treat any deviation — or an unexpectedly silent endpoint — as an incident, not a shrug.
4. Forward logs off-box quickly. Ship events to a collector so that even if an endpoint goes dark, the gap and the last-seen timestamp are visible centrally.
5. Audit the pipeline on a schedule. Run winsentinel --audit --modules logging regularly so a disabled provider is caught in days, not after the breach.

The Fleet Angle

On a single machine, WinSentinel gives you the full audit for free — every module, no limits — so you can verify one endpoint's telemetry pipeline in minutes. The problem changes shape across an estate: one blinded machine in a hundred is a needle in a haystack, and it's the one the attacker chose. WinSentinel Pro's fleet orchestration rolls these logging findings up across every node, so "Threat-Intelligence provider disabled on 1 host" surfaces as a drift alert on the central console instead of hiding in per-machine noise. Detecting the odd one out is precisely where centralized posture beats staring at dashboards.

Attackers reach for ETW tampering because it's the highest-leverage move on Windows: cut one pipe and a dozen detections go dark at once. Audit the pipe itself. Run winsentinel --audit --modules logging today — if it reports a disabled security provider or a below-baseline session, don't wave it off as cleanup. Absence of signal is the signal.