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

## Overview

In this talk, Olaf Hartong (Falcon Force) explores the mechanics of Event Tracing for Windows (ETW) and how its architectural assumptions can be manipulated by adversaries and detection engineers alike. While security products and Endpoint Detection and Response (EDR) solutions increasingly depend on ETW for real-time telemetry due to its stability, filtering capabilities, and lower overhead compared to kernel callbacks, ETW was fundamentally engineered for performance monitoring and debugging rather than tamper-proof security auditing. Hartong examines how registering handles to existing ETW provider GUIDs allows arbitrary processes to emit spoofed telemetry, deceive security analysts, and bypass detection mechanisms by exhausting telemetry caps.

---

## ETW Architecture & Why EDRs Rely on It

ETW consists of three primary architectural components orchestrated by the ETW kernel: - **Event Providers:** User-mode or kernel-mode components that raise telemetry. - **Trace/Logger Sessions:** Buffer pools and controllers that collect events. Four session types exist: *Auto logger* (boots at startup and writes to disk), *Real-time* (buffered live stream consumed on the fly, commonly used by EDRs, temporarily buffered in Windows directory files), *File logging* (writes events directly to disk), and *Private sessions* (in-app debugging). - **Consumers:** Applications (such as EDR agents) that read and process the buffered event streams.

### Why Security Products Adopt ETW EDRs often prefer ETW over traditional kernel callbacks and API hooking because: - **Stability and Safety:** Requires less custom kernel driver code, avoiding system crashes and driver-related instability. - **Granular Filtering:** Sessions can subscribe to specific provider GUIDs, event IDs, and sub-attributes. Kernel callbacks require ingesting the full stream and filtering in-process, which consumes significant CPU. - **Buffering:** ETW buffers events in memory pools, reducing telemetry drops during peak activity. - **Dynamic Flexibility:** Providers can be enabled or disabled on the fly without reloading drivers or rebooting systems. - **Low Intrusion:** Avoids injecting into processes or hooking user-mode functions directly.

Hartong notes that platforms like Microsoft Defender for Endpoint rely on a combination of kernel callbacks and dozens of specific ETW providers, while other vendors (e.g., CrowdStrike) similarly depend on ETW telemetry where callbacks and hooking are insufficient.

---

## Prior ETW Tampering vs. Provider Spoofing

Common ETW evasion techniques typically involve: - Patching user-mode functions (such as `ntdll!EtwEventWrite`) to block telemetry (often used in AMSI bypasses). - Tampering with temporary `.etl` files written to disk. - Modifying registry keys to disable sessions. - Using malicious drivers with kernel-level access to kill entire trace sessions.

Hartong's research focuses on an unprivileged technique: **duplicate provider registration**. ETW providers are identified by GUIDs defined in manifests (XML files in `System32` introduced in Windows Vista) or MOF files. When a process calls `EventRegister` with the GUID of an existing provider (such as the TCP/IP provider): 1. The ETW kernel provides a handle to that same provider GUID. 2. The calling process can immediately start emitting arbitrary events via `EventWrite` matching the provider's manifest template. 3. The ETW kernel feeds these synthetic events into whatever real-time trace sessions are already listening (including active EDR sessions). 4. ETW fundamentally does not validate or record which emitting process produced the telemetry, treating synthetic events as legitimate system telemetry.

---

## Implications: Deception and EDR Blinding

Manipulating ETW event emission introduces several defensive and offensive capabilities:

- **Detection Engineering Validation:** Allows engineers to simulate attacks and validate detection pipelines by emitting representative ETW events without executing malicious payloads on target endpoints. - **Analyst Deception & Distraction:** Attackers can emit synthetic security alerts or false breadcrumbs, causing SOC analysts to investigate executions or network connections that never occurred. - **Telemetry Flooding and Blinding via Caps:** Cloud-routed EDRs enforce telemetry caps to control network bandwidth, ingestion overhead, and cloud processing costs. Defender for Endpoint configurations reveal: - **Global Caps:** Limiting telemetry to a fixed number (e.g., 1,000 events) per machine over a 24-hour expiration window. - **Local/Deduplication Caps:** Throttling identical events (e.g., `LDAP first seen` queries throttled to one event per query/process per 24 hours). By programmatically emitting duplicate or high-volume spoofed events, an attacker can intentionally exhaust these 24-hour local and global caps, blinding the EDR and preventing legitimate alerts from reaching analysts.