The Microsoft-Windows-Threat-Intelligence (ETW-TI) provider is the single most significant ETW provider from a defensive security perspective. Unlike user-mode ETW providers, ETW-TI is a kernel-mode provider registered directly by ntoskrnl.exe. Events from this provider cannot be silenced by patching user-mode ntdll functions, making it the definitive backstop against advanced in-memory attack techniques such as process injection, thread hijacking, and credential dumping.

• What is ETW-TI?
• Architecture: Why Kernel-Mode Matters
  • PPL Protection Requirement
  • Why Direct/Indirect Syscalls Cannot Bypass ETW-TI
• Provider Internals: Registration, Event Flow, and Kernel Structures
  • Provider Registration in ntoskrnl.exe
  • The EtwThreatIntProvRegHandle Global
  • Event Writing: From Syscall to EtwWrite
  • Event Routing: Local vs Remote, Read vs Write
  • The Secure ETW Channel and PPL Enforcement
  • EPROCESS Protection Levels
  • Per-Process ETW-TI Enablement Flags
• The Kernel Sensors: EtwTiLog Functions
  • Complete Sensor List via WinDbg
  • ETW-TI Monitored Events
• Querying ETW-TI Locally
• How EDRs Consume ETW-TI
  • Elastic Security: Call Stack-Based Detections
  • API Event Behaviors (Elastic Enrichment)
  • Detection Rule Examples
• Purple Team: The Bypass Landscape
  • User-Mode Bypasses That DO NOT Work
  • Kernel-Mode Bypass Vectors
  • The NtContinue Technique (Hardware Breakpoints)
  • ETW-ByeBye: The ProcessEnableLogging Bug
• Detection Engineering Recommendations
• Tools and Research Resources
  • Research / Consume ETW-TI
  • Deep-Dive Blog Articles
• References

What is ETW-TI?

ETW-TI was introduced in Windows 10 RS2/1703 to provide critical visibility into Memory Manager (Mm*) and Asynchronous Procedure Call (APC) operations. Since then, it has been continuously expanded to cover additional security-relevant syscalls. Microsoft’s goal was to provide security vendors with near real-time kernel telemetry about the most security-critical operations happening on a system.

Unlike regular ETW providers that any process can subscribe to, the ETW-TI provider is only accessible to Early Launch Anti-Malware (ELAM) signed drivers and processes running as SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT / PS_PROTECTED_ANTIMALWARE_LIGHT. This is part of the so-called Secure ETW Channel.

Architecture: Why Kernel-Mode Matters

The fundamental architectural difference between ETW-TI and user-mode ETW providers is where the instrumentation executes:

User-Mode ETW:       Application -> ntdll!EtwEventWrite -> Event
                     (can be patched in user-mode)

ETW-TI (Kernel):     syscall instruction -> ntoskrnl.exe -> EtwTiLog* -> Event
                     (fires AFTER transition to ring 0, untouchable from user-mode)

or as a picture:

The ETW-TI callback executes within the kernel after the syscall instruction completes. By the time the telemetry fires, the user-mode code has already transitioned into kernel-mode. This means:

1. No user-mode hook can intercept the event
2. No user-mode patching (ntdll, AMSI, etc.) affects ETW-TI
3. The kernel sees the operation regardless of how the syscall was invoked

PPL Protection Requirement

The provider is only accessible to sessions running as PPL (Protected Process Light) or PP (Protected Process). Standard user-mode processes – including non-PPL EDR agents – cannot subscribe. This is the architectural reason why a kernel-mode driver is essential for EDR products: user-mode-only EDR has a structural blind spot for injection detection.

The kernel will only deliver ETW-TI events to services/processes running as PS_PROTECTED_ANTIMALWARE_LIGHT that have been signed by the Early Launch EKU certificate, which was also used to sign the corresponding ELAM driver installed via kernel32!InstallElamCertificateInfo.

Why Direct/Indirect Syscalls Cannot Bypass ETW-TI

This is a critical insight for both red and blue teamers:

ETW-TI events fire independently of how the syscall was invoked – whether via the hooked ntdll stub, a direct syscall, or an indirect syscall. The kernel sees the operation and fires the TI event.

This is fundamentally different from user-mode hooking (inline hooks on ntdll), which can be trivially bypassed by calling syscall stubs directly. ETW-TI operates entirely in kernel-mode, making it immune to all user-land evasion techniques. To understand and enumerate which functions your EDR actively hooks at the user-mode level, see the companion article Hunting the Watchers: Detecting and Enumerating EDR User-Mode Hooks – it compares loaded DLL memory against disk baselines to produce a complete hook map.

User-Mode Hook:     ntdll!NtWriteVirtualMemory (hooked) -> EDR callback -> syscall
Direct Syscall:     mov r10, rcx; mov eax, SSN; syscall  (bypasses hook)
Indirect Syscall:   jmp ntdll!NtWriteVirtualMemory+0x12  (bypasses hook)

ETW-TI:             ALL THREE -> kernel -> EtwTiLogReadWriteVm -> Event logged

Provider Internals: Registration, Event Flow, and Kernel Structures

This section dives into the low-level mechanisms that make ETW-TI work inside ntoskrnl.exe. Understanding these internals is essential for reverse engineering detection capabilities, building custom consumers, and understanding what attackers must subvert to blind this provider.

Provider Registration in ntoskrnl.exe

Like any ETW provider, the TI provider must call EtwRegister before it can emit events. Because ETW-TI is a kernel-mode provider, this registration happens inside ntoskrnl.exe during system initialization.

The registration call is found within the EtwInitialize function, which registers many kernel ETW providers during boot:

NTSTATUS EtwRegister(
    [in]           LPCGUID            ProviderId,       // Provider GUID
    [in, optional] PETWENABLECALLBACK EnableCallback,   // Called when consumer enables/disables
    [in, optional] PVOID              CallbackContext,  // Context for callback
    [out]          PREGHANDLE         RegHandle         // Output: registration handle
);

For the TI provider, the parameters are:

In IDA/Ghidra, following the cross-references from EtwRegister inside ntoskrnl.exe leads to EtwInitialize, where you can observe the TI provider GUID being passed as the first argument.

The EtwThreatIntProvRegHandle Global

The registration produces a handle stored in the kernel global variable EtwThreatIntProvRegHandle. This handle is the linchpin of the entire ETW-TI system:

nt!EtwThreatIntProvRegHandle  ->  REGHANDLE (opaque kernel handle)

Every EtwTiLog* function references this handle when calling EtwWrite to emit events. By cross-referencing EtwThreatIntProvRegHandle in a disassembler, you can discover all functions that write to the TI provider:

0: kd> x nt!EtwThreatIntProvRegHandle
fffff805`27c4a1b0 nt!EtwThreatIntProvRegHandle = <...>

Cross-referencing this symbol reveals all callers – which is precisely the list of EtwTiLog* sensor functions. This is the reverse-engineering technique used by researchers (including Jonathan Johnson) to map out the complete set of instrumented operations.

Attack relevance: One known kernel-level bypass involves zeroing EtwThreatIntProvRegHandle via a vulnerable driver. If this handle is null, subsequent calls to EtwWrite with it will silently fail, effectively disabling all TI events. However, PatchGuard periodically validates kernel data integrity and may detect this modification.

Event Writing: From Syscall to EtwWrite

When a security-relevant syscall executes, the kernel calls the corresponding EtwTiLog* function, which ultimately invokes EtwWrite:

NTSTATUS EtwWrite(
    [in]           REGHANDLE              RegHandle,        // EtwThreatIntProvRegHandle
    [in]           PCEVENT_DESCRIPTOR     EventDescriptor,  // Event metadata (ID, level, keyword)
    [in, optional] LPCGUID                ActivityId,       // Correlation GUID
    [in]           ULONG                  UserDataCount,    // Number of data items
    [in, optional] PEVENT_DATA_DESCRIPTOR UserData          // Event payload
);

The EVENT_DESCRIPTOR structure defines the event’s identity:

typedef struct _EVENT_DESCRIPTOR {
    USHORT    Id;       // Event ID (unique per event type)
    UCHAR     Version;  // Schema version
    UCHAR     Channel;  // Log channel
    UCHAR     Level;    // Severity (Informational, Warning, etc.)
    UCHAR     Opcode;   // Operation type
    USHORT    Task;     // Task category
    ULONGLONG Keyword;  // Filtering bitmask
} EVENT_DESCRIPTOR, *PEVENT_DESCRIPTOR;

Each EtwTiLog* function constructs the appropriate EVENT_DESCRIPTOR and populates UserData with contextual information (PIDs, addresses, sizes, protection flags, etc.) before calling EtwWrite.

Event Routing: Local vs Remote, Read vs Write

A detailed examination of EtwTiLogReadWriteVm reveals how the kernel decides which specific event to emit. The logic follows this decision tree:

The corresponding event descriptors (found as static data in ntoskrnl.exe):

The complete call chain for a WriteProcessMemory operation:

User-Mode:
  WriteProcessMemory() [kernel32.dll]
    └─ NtWriteVirtualMemory() [ntdll.dll]
        └─ syscall instruction -> Ring 0 transition

Kernel-Mode (ntoskrnl.exe):
  NtWriteVirtualMemory(ProcessHandle, BaseAddress, Buffer, Size, ...)
    └─ MiReadWriteVirtualMemory(SourceProcess, TargetProcess, ..., 0x20)
        ├─ [Performs the actual memory write operation]
        └─ EtwTiLogReadWriteVm(SourceProcess, TargetProcess, 0x20, ...)
            ├─ Determines: REMOTE (different process) + WRITE (0x20)
            ├─ Selects: THREATINT_WRITEVM_REMOTE descriptor
            └─ EtwWrite(EtwThreatIntProvRegHandle, &THREATINT_WRITEVM_REMOTE, ...)
                └─ Event delivered to PPL consumer sessions

This architecture means the event fires after the write completes but within the same syscall context – there is no async delay at the kernel instrumentation level.

The Secure ETW Channel and PPL Enforcement

ETW-TI uses what Microsoft calls the Secure ETW Channel. This is not a separate transport mechanism but rather an access control enforcement layer:

1. Provider Registration: When EtwRegister is called for the TI provider GUID, the kernel marks this registration as “secure” in the internal ETW_REG_ENTRY structure.

2. Session Subscription: When a consumer calls StartTrace / EnableTraceEx2 to subscribe to the TI provider, the kernel checks the caller’s protection level:

   if (Process->Protection.Type < PsProtectedTypeProtectedLight ||
       Process->Protection.Signer < PsProtectedSignerAntimalware)
   {
       return STATUS_ACCESS_DENIED;
   }
   

3. ELAM Requirement: The PPL-AM protection level requires:
   • A kernel-mode ELAM driver signed with Microsoft’s Early Launch EKU
   • The user-mode service binary signed with the same certificate chain
   • Installation via InstallElamCertificateInfo during ELAM driver load
4. Event Delivery: Events are only routed to trace sessions whose owning process meets the PPL-AM threshold. Non-qualifying sessions never receive TI events, even if they request the provider GUID.

The verification check within NtTraceControl (which backs EnableTraceEx2):

// Simplified kernel logic for ETW-TI subscription validation
if (IsSecureProvider(ProviderGuid)) {
    PEPROCESS Consumer = PsGetCurrentProcess();
    PS_PROTECTION protection = Consumer->Protection;

    if (protection.Type < PsProtectedTypeProtectedLight)
        return STATUS_ACCESS_DENIED;
    if (protection.Signer < PsProtectedSignerAntimalware)
        return STATUS_ACCESS_DENIED;
}

EPROCESS Protection Levels

The EPROCESS kernel structure contains a PS_PROTECTION field that determines the process’s protection level:

typedef struct _PS_PROTECTION {
    union {
        UCHAR Level;
        struct {
            UCHAR Type   : 3;   // PS_PROTECTED_TYPE
            UCHAR Audit  : 1;   // Reserved
            UCHAR Signer : 4;   // PS_PROTECTED_SIGNER
        };
    };
} PS_PROTECTION, *PPS_PROTECTION;

Protection Types (relevant hierarchy):

Signer Levels (relevant hierarchy, highest to lowest):

For ETW-TI access, a process needs at minimum: Type = PsProtectedTypeProtectedLight (1) AND Signer = PsProtectedSignerAntimalware (3), giving a combined Level byte of 0x31.

This is what tools like KDU exploit: they use a vulnerable driver to directly modify the EPROCESS->Protection field in kernel memory, elevating a normal process to PPL-AM status.

Per-Process ETW-TI Enablement Flags

ETW-TI events are not globally enabled for all processes – they are controlled on a per-process basis via flags in the EPROCESS structure. These flags determine whether TI events fire when the process is involved in a monitored operation:

// Relevant EPROCESS fields (undocumented, offsets vary by build)
struct _EPROCESS {
    // ...
    union {
        ULONG MitigationFlags2;
        struct {
            ULONG EnableReadVmLogging : 1;
            ULONG EnableWriteVmLogging : 1;
            ULONG EnableProcessSuspendResumeLogging : 1;
            ULONG EnableThreadSuspendResumeLogging : 1;
            ULONG EnableLocalExecProtectVmLogging : 1;   // Win11+
            ULONG EnableRemoteExecProtectVmLogging : 1;  // Win11+
            // ...
        };
    };
    // ...
};

These flags can be queried and set via NtSetInformationProcess with:

• ProcessEnableReadWriteVmLogging (class 0x57)
• ProcessEnableLogging (class 0x60)

Under normal circumstances, modifying these flags requires PPL-AM privileges. The ETW-ByeBye bug (discussed later) exploits the absence of this PPL check on vulnerable Windows versions.

The Kernel Sensors: EtwTiLog Functions

The Windows kernel sensors are categorized into two groups:

• Threat Intelligence (Ti): EtwTiLog* prefix – high-fidelity security sensors
• Security Mitigations (Tim): EtwTimLog* prefix – mitigation-related logging

These are the kernel-internal functions that hook directly into critical operations:

Complete Sensor List via WinDbg

In a kernel debugging session, list all ETW-TI symbols:

0: kd> x nt!EtwTiLog*
fffff805`27b75280 nt!EtwTiLogDriverObjectLoad (void)
fffff805`27a5f94c nt!EtwTiLogDeviceObjectLoadUnload (void)
fffff805`27759390 nt!EtwTiLogInsertQueueUserApc (void)
fffff805`27a79ecc nt!EtwTiLogProtectExecVm (void)
fffff805`27b6d22c nt!EtwTiLogDriverObjectUnLoad (void)
fffff805`27aaac4c nt!EtwTiLogSetContextThread (void)
fffff805`27d3f76c nt!EtwTiLogSuspendResumeProcess (void)
fffff805`27a79ce0 nt!EtwTiLogAllocExecVm (void)
fffff805`27a79b30 nt!EtwTiLogReadWriteVm (void)
fffff805`27b22544 nt!EtwTiLogMapExecView (void)
fffff805`27d3f8d4 nt!EtwTiLogSuspendResumeThread (void)

ETW-TI Monitored Events

Each event captures rich contextual data:

For example, when NtAllocateVirtualMemory is called with PAGE_EXECUTE_READWRITE, ETW-TI logs:

• Process ID making the call
• Target process (if cross-process)
• Base address allocated
• Region size
• Protection flags (RWX is highly suspicious)
• Call stack (user-mode portion)
• Timestamp

Querying ETW-TI Locally

Query the full list of supported events from an elevated command prompt:

logman.exe query providers Microsoft-Windows-Threat-Intelligence

Example output:

Provider                                 GUID
-------------------------------------------------------------------------------
Microsoft-Windows-Threat-Intelligence    {F4E1897C-BB5D-5668-F1D8-040F4D8DD344}

Value               Keyword              Description
-------------------------------------------------------------------------------
0x0000000000000001  KERNEL_THREATINT_KEYWORD_ALLOCVM_LOCAL
0x0000000000000002  KERNEL_THREATINT_KEYWORD_ALLOCVM_LOCAL_KERNEL_CALLER
0x0000000000000004  KERNEL_THREATINT_KEYWORD_ALLOCVM_REMOTE
0x0000000000000008  KERNEL_THREATINT_KEYWORD_PROTECTVM_LOCAL
0x0000000000000010  KERNEL_THREATINT_KEYWORD_PROTECTVM_LOCAL_KERNEL_CALLER
0x0000000000000020  KERNEL_THREATINT_KEYWORD_PROTECTVM_REMOTE
0x0000000000000040  KERNEL_THREATINT_KEYWORD_MAPVIEW_LOCAL
0x0000000000000080  KERNEL_THREATINT_KEYWORD_MAPVIEW_LOCAL_KERNEL_CALLER
0x0000000000000100  KERNEL_THREATINT_KEYWORD_MAPVIEW_REMOTE
0x0000000000000200  KERNEL_THREATINT_KEYWORD_QUEUEUSERAPC_REMOTE
0x0000000000000400  KERNEL_THREATINT_KEYWORD_SETTHREADCONTEXT_REMOTE
0x0000000000000800  KERNEL_THREATINT_KEYWORD_READVM_LOCAL
0x0000000000001000  KERNEL_THREATINT_KEYWORD_READVM_REMOTE
0x0000000000002000  KERNEL_THREATINT_KEYWORD_WRITEVM_LOCAL
0x0000000000004000  KERNEL_THREATINT_KEYWORD_WRITEVM_REMOTE
0x0000000000008000  KERNEL_THREATINT_KEYWORD_SUSPEND_THREAD
0x0000000000010000  KERNEL_THREATINT_KEYWORD_RESUME_THREAD
0x0000000000020000  KERNEL_THREATINT_KEYWORD_SUSPEND_PROCESS
0x0000000000040000  KERNEL_THREATINT_KEYWORD_RESUME_PROCESS
...

How EDRs Consume ETW-TI

While synchronous blocking (inline callbacks for these syscalls) is not yet possible, ETW-TI represents the most reliable kernel-side detection mechanism accessible to security vendors. EDRs consume ETW-TI events through their kernel-mode driver component, which runs as PPL-AntiMalware.

Elastic Security: Call Stack-Based Detections

Elastic Security (since version 8.8+) combines ETW-TI events with kernel call stack analysis. Their implementation:

1. Subscribes to ETW-TI via their PPL kernel driver
2. Fingerprints each event and deduplicates (unique events only emitted)
3. Processes events on-host for behavior detection rules
4. Optionally streams to SIEM for SOC correlation

Currently monitored APIs include:

• VirtualAlloc / VirtualAllocEx
• VirtualProtect / VirtualProtectEx
• MapViewOfFile / MapViewOfFile2
• QueueUserAPC
• SetThreadContext
• WriteProcessMemory
• ReadProcessMemory (targeting lsass)

API Event Behaviors (Elastic Enrichment)

Elastic enriches API events with behavioral indicators:

Detection Rule Examples

Direct Syscall Detection:

api where event.category == "intrusion_detection" and
    process.Ext.api.behaviors == "direct_syscall" and
    process.Ext.api.name : ("VirtualAlloc*", "VirtualProtect*",
                             "MapViewOfFile*", "WriteProcessMemory")

ETW Patching Detection:

api where process.Ext.api.name : "WriteProcessMemory*" and
    process.Ext.api.summary : ("*ntdll.dll!Etw*", "*ntdll.dll!NtTrace*") and
    not process.executable : ("?:\\Windows\\System32\\lsass.exe")

AMSI/WLDP Bypass Detection:

api where
 (
  (process.Ext.api.name : "VirtualProtect*" and
    process.Ext.api.parameters.protection : "*W*") or
  process.Ext.api.name : "WriteProcessMemory*"
 ) and
 process.Ext.api.summary : ("* amsi.dll*", "* mpoav.dll*", "* wldp.dll*")

Remote Module Hooking (ThreadlessInject detection):

api where process.Ext.api.name : "WriteProcessMemory" and
    process.Ext.api.behaviors == "cross-process" and
    process.Ext.api.summary : ("*ntdll.dll*", "*kernelbase.dll*")

Purple Team: The Bypass Landscape

Since ETW-TI is a kernel-mode provider, any suppression requires kernel-level access – via BYOVD (Bring Your Own Vulnerable Driver), a kernel exploit, or a signed kernel driver. This makes ETW-TI the defensive backstop against injection techniques: all userland patching leaves it untouched.

User-Mode Bypasses That DO NOT Work

Kernel-Mode Bypass Vectors

These are relevant for detection engineering (knowing what to watch for):

The NtContinue Technique (Hardware Breakpoints)

Research from Praetorian demonstrates that NtContinue can be used to set hardware breakpoints (debug registers) without triggering EtwTiLogSetContextThread. This is because NtContinue updates the thread context including debug registers without invoking the same kernel path as NtSetContextThread.

The attack flow:

1. Register a Vectored Exception Handler
2. Capture current thread context via RtlCaptureContext
3. Set Dr0-Dr3 and Dr7 to hook target functions (e.g., Sleep, AmsiScanBuffer)
4. Call NtContinue to apply the context (no ETW-TI event)
5. When the breakpoint fires, the VEH handles the exception

This is relevant because EDRs create detections around SetThreadContext/NtSetContextThread for hardware breakpoint abuse. Using NtContinue avoids this specific detection vector.

Detection approach: Monitor for NtContinue calls with CONTEXT_DEBUG_REGISTERS flag, or detect the behavioral outcome (patchless hooks on AMSI/ETW functions).

ETW-ByeBye: The ProcessEnableLogging Bug

Research from RiskInsight (2023) revealed that on certain Windows 10 versions, calling NtSetInformationProcess with ProcessEnableLogging or ProcessEnableReadWriteVmLogging could disable ETW-TI event logging for a process without the expected PPL requirement. Only SeDebug or SeTcb privileges were needed.

Vulnerable versions:

• Win10 1709 through 22H2 (ReadVm/WriteVm operations)
• Win10 1809 through 22H2 (Process/Thread suspend/resume)
• Patched in Windows 11

// Simplified POC (works only on unpatched systems)
PROCESS_LOGGING_INFORMATION info = { 0 };
info.Flags = 0xf;
info.EnableReadVmLogging = 1;
info.EnableWriteVmLogging = 1;
info.EnableProcessSuspendResumeLogging = 1;
info.EnableThreadSuspendResumeLogging = 1;

NtSetInformationProcess((HANDLE)-1, ProcessEnableLogging,
                        &info, sizeof(info));
// ETW-TI events for this process are now silenced

Detection approaches:

1. Hook NtSetInformationProcess in user-mode (fragile but layered defense)
2. Walk KPROCESS list and check if ETW-TI was disabled for unexpected processes
3. Alert on absence of expected ETW-TI telemetry from a process
4. Upgrade to Windows 11 where the bug is fixed

Detection Engineering Recommendations

For CSIRT/SOC teams building detection capabilities around ETW-TI:

High-Fidelity Detection Patterns:

Behavioral Evasion Awareness:

Sophisticated adversaries may attempt to reduce detection scores by:

• Staging operations with delays (spreading RWX alloc -> write -> protect -> execute over minutes)
• Using existing executable memory (code caves) instead of new allocations
• Using RW allocation first, then changing to RX (no RWX flag)
• Leveraging legitimate processes for early injection stages

Correlation with User-Mode Hook Coverage:

ETW-TI provides kernel-level visibility, but most EDRs also maintain user-mode inline hooks on ntdll.dll for real-time interception. The two layers are complementary: ETW-TI catches operations that bypass user-mode hooks (via direct/indirect syscalls), while hooks provide synchronous blocking capability that ETW-TI lacks. Use the EDR Hook Detection Scanner to map which Nt* functions your EDR intercepts at user-mode level, then cross-reference with the ETW-TI monitored events table above to identify any operations that lack coverage at both layers.

Splunk SPL Example (if forwarding ETW-TI via Fibratus/Sealighter):

index=etw_ti sourcetype="etw:ti"
| where CallingProcessId != TargetProcessId
| where Protection="PAGE_EXECUTE_READWRITE"
| stats count by CallingProcessName, TargetProcessName, EventType
| where count > 3
| sort - count

Tools and Research Resources

Research / Consume ETW-TI

Deep-Dive Blog Articles

References

1. Microsoft Documentation - Event Tracing for Windows (ETW)
2. Elastic Security Labs - Doubling Down: Detecting In-Memory Threats with Kernel ETW Call Stacks (January 2024)
3. Praetorian - ETW Threat Intelligence and Hardware Breakpoints (January 2025)
4. Meekolab - Introduction into Microsoft Threat Intelligence Drivers (September 2022)
5. pathtofile - SealighterTI and KDU approach
6. Legacyy - ETW-ByeBye: Disabling ETW-TI Without PPL (April 2024)
7. RiskInsight Wavestone - A universal EDR bypass built in Windows 10 (October 2023)
8. SysWhispers4 - ETW-TI Limitations
9. jdu2600 - Windows 10 ETW Events manifest