Why attackers kill ETW before they do anything else.

What ETW is and why it matters

Event Tracing for Windows (ETW) is a kernel-level tracing framework built into Windows. It provides structured telemetry from the operating system itself: process creation, DLL loads, network connections, file system operations, registry changes, and much more. Sysmon, Windows Defender and most commercial EDR products consume ETW sessions under the hood.

That dependency is the problem. If an attacker can silence or distort an ETW provider, they can operate with reduced visibility, even on an endpoint that looks fully instrumented from the outside.

The five ETW-silencing techniques

# Technique 1: stop the trace session directly
sc stop Sysmon64

# Technique 2: patch the EtwpNotifyConsumer function in ntdll
WriteProcessMemory() → NOP the dispatch path

1. Stopping the trace session

   The simplest method: stop Sysmon, Windows Defender or any ETW consumer as a service. Detectable via Service Control Manager events (7036) and Sysmon's own process-terminated log, if you still have a copy.

2. Patching ntdll in-process

   Malware patches the ETW dispatch path inside ntdll.dll within the target process. The kernel still raises events, but the consuming thread never sees them. Ghidra's EvasionScan script detects the stub pattern statically; Frida catches it dynamically.

3. NtTraceControl / EtwpStopTrace

   A direct syscall to the kernel's trace control interface, bypassing ntdll entirely. It evades userland hooks. It needs elevated privileges but not SYSTEM: a medium-integrity process with SeDebugPrivilege is enough.

4. Stomping the session buffer

   Corrupt the EVENT_TRACE_LOGFILE buffer so consumers receive garbage instead of valid events. Logs appear active; events are unreadable. Detection: checksum comparison across consecutive reads.

5. Provider deregistration injection

   Inject into a process that holds an ETW provider handle and call EtwUnregister() on the provider's REGHANDLE. That provider goes silent for the lifetime of that process.

What actually detects these

The strategy: make the silence the signal

Hardening the logs harder is a losing race. A capable intruder will stop Sysmon, auditd or the native event log sooner or later. Plan for that moment instead of hoping it never comes, and do it without paying for a driver arms race.

• Assume the logs will go dark.

  Native logging is the first thing an intruder switches off, because every defender relies on it. Any design that only works while the logs are running is a design that fails exactly when it matters.

• Turn the attacker's first move into your clearest alarm.

  Legitimate software has no reason to silence the system's own audit trail. So the act of tampering is not noise to filter; it is a definitive attack signal. The weakness becomes the tripwire: the moment someone reaches for the off switch, they have announced themselves.

• Sensors that move, guard and restore.

  Our Moving Target Sensors keep an independent, tamper-protected copy of the event trail out of the attacker's line of sight. They raise the alarm when the native logs are stopped or altered, and restore what was removed, so the evidence survives the attempt to erase it.

• Build on what doesn't change, and stop paying for what does.

  A proprietary kernel driver has to be rewritten every time the operating system moves, and a bad update can blue-screen a whole fleet. Behind every licence fee sits a team of engineers chasing those OS changes, and you pay for them, year after year. The native audit trail (ETW, auditd, macOS Endpoint Security) is maintained by the OS vendor itself and barely changes from one release to the next. Build on that foundation and the upkeep cost largely disappears from your bill.

← All advisories