Detecting Process Injection via ETW Threat Intelligence

In the ongoing arms race between malware authors and security practitioners, process injection remains one of the most effective techniques for achieving stealth and persistence. By hijacking the execution flow of a legitimate, trusted process, an adversary can bypass simple process-based detection, evade basic firewalls, and blend into the background noise of a healthy operating system.

As detection engineering matures, the industry is moving away from monitoring high-level API calls in user-mode-which are easily bypassed via direct syscalls or unhooking-and toward kernel-level telemetry. One of the most potent sources for this visibility is ETW Threat Intelligence (ETW-TI). This post explores the mechanics of process injection and how ETW-SUS (Threat Intelligence) provides the granular visibility required to detect these sophisticated subversions.

The Anatomy of Process Injection

Process injection is not a single technique but a category of maneuvers designed to execute arbitrary code within the address space of a target process. While the specific implementation varies, most injection vectors rely on a predictable sequence of primitives:

1. Target Acquisition: Obtaining a handle to a remote process (e. g., `OpenProcess`).
2. Memory Allocation: Carving out space in the target process's virtual memory (e.g., `VirtualAllocEx`).
3. Payload Delivery: Writing the malicious payload (shellcode or a DLL path) into the allocated space (e.g., `WriteProcessMemory`).
4. Execution Hijacking: Redirecting the instruction pointer to the newly written code (e.g., `CreateRemoteThread` or `SetThreadContext`).

Modern variants like Process Hollowing, Module Overloading, and AtomBombing attempt to obfuscate these steps. For instance, Process Hollowing involves creating a process in a suspended state, unmapping its original image, and replacing it with a malicious one. Detecting these requires more than just looking at process creation; it requires observing the memory mutations and thread manipulations occurring inside the process.

The Rise of ETW Threat Intelligence (ETW-TI)

Traditionally, Endpoint Detection and Response (EDR) solutions relied on user-mode hooking (intercepting calls to `ntdll.dll`) or kernel callbacks (using `PsSetCreateProcessNotifyRoutine`). However, advanced adversaries can bypass user-mode hooks by implementing direct syscalls, effectively "jumping over" the instrumentation.

ETW Threat Intelligence (ETW-TI) is a specialized, kernel-level instrumentation provider designed specifically for security vendors. Unlike standard ETW providers that might report high-level events, the `Microsoft-Windows-Threat-Intelligence` provider resides within the kernel. It intercepts system calls at the boundary where the transition from user-mode to kernel-mode occurs.

Because ETW-TI is instrumented within the kernel's execution flow, it is significantly harder for an adversary to evade. Even if a piece of malware uses a direct syscall to bypass `ntdll.dll` hooks, the kernel-level instrumentation still captures the activity as the syscall enters the kernel. This provides a "ground truth" that is much more resilient to tampering.

Decoding the Telemetry: Key Indicators

To build effective detection logic, we must focus on the specific events emitted by the ETW-TI provider that correlate with injection primitives.

1. Remote Memory Allocation and Modification

The most critical indicator of injection is the modification of memory in a process other than the one initiating the request. ETW-TI provides visibility into `NtAllocateVirtualMemory` and `NtWriteVirtualMemory`.

A high-fidelity detection pattern involves monitoring for:

• Cross-process operations: An `Allocation` or `Write` event where the `SourceProcess` is different from the `TargetProcess`.
• ulnerable memory protections: Allocations of `PAGE_EXECUTE_READWRITE` (RWX) memory, which is a hallmark of shellcode staging.

2. Thread Execution Hijacking

Once the payload is in memory, it must be executed. The `NtCreateThreadEx` event is a primary target for monitoring. ETW-TI can provide the context of the thread creation, specifically whether the start address points to unbacked memory (memory not associated with a file on disk).

Furthermore, monitoring `NtSetContextThread` is vital. This API is frequently used in "Thread Execution Hijacking," where an existing thread's context is modified to point to malicious code. ETW-TI allows us to see when a thread's instruction pointer (`RIP`/`EIP`) is redirected to a suspicious memory region.

3. Module Loading Anomalies

Techniques like Module Overloading involve mapping a legitimate DLL into a process but overwriting its sections with malicious code. By monitoring `NtMapViewOfSection` via ETW-TI, defenders can identify when sections of a legitimate module are being mapped with suspicious permissions or are being manipulated immediately after loading.

Implementation: The Detection Engineer's Perspective

Implementing ETW-TI-based detection requires a robust pipeline capable of handling high-volume kernel telemetry.

Data Collection

Collecting ETW-TI data typically requires a kernel driver (often part of an EDR agent) to register as a consumer of the `Microsoft-Windows-Threat-Intelligence` provider. This

Conclusion

As shown across "The Anatomy of Process Injection", "The Rise of ETW Threat Intelligence (ETW-TI)", "Decoding the Telemetry: Key Indicators", a secure implementation for detecting process injection via etw threat intelligence depends on execution discipline as much as design.

The practical hardening path is to enforce host hardening baselines with tamper-resistant telemetry, behavior-chain detection across process, memory, identity, and network telemetry, and provenance-attested build pipelines and enforceable release gates. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track time from suspicious execution chain to host containment and policy-gate coverage and vulnerable artifact escape rate, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.