By: Ido Veltzman & Max Malyutin
Modern cyberattacks rarely begin as obvious incidents. They begin as signals: a process behaving differently, a script executing unexpectedly, a registry key changing, a module loading from an unusual path, or a user action that does not fit the normal pattern. The ability to see, understand, and connect these signals is what separates reactive security from proactive defense.
Event Tracing for Windows, or ETW, is one of the most powerful telemetry ecosystems in Windows. It gives defenders access to deep system and application activity and is widely used by developers, threat hunters, detection engineers, and endpoint protection vendors to monitor behavior, investigate anomalies, and uncover security-relevant activity.
Cynet Research Labs, the cybersecurity research unit of Cynet, created this article as part of its ongoing effort to share practical research with the cybersecurity community and contribute to the collective understanding of modern endpoint security.
By publishing technical insights from our research, Cynet Research Labs aims to support open knowledge sharing across the industry, helping defenders, researchers, and security teams explore how endpoint telemetry can be applied to detection, investigation, and response in real-world environments.
This article provides a clear overview of ETW, including how it is built, how ETW providers differ, and how security vendors can use ETW telemetry for detection and response.
It also explores practical use cases such as using ETW for detections and using ETW for threat hunting, showing how Windows-native telemetry can support stronger visibility, better investigations, and more effective security operations.
ETW provides deep Windows endpoint telemetry. EDR turns that telemetry into endpoint detection and investigation. XDR expands it by connecting endpoint activity with identity, network, cloud, SaaS, email, and other security layers.
This is where Cynet turns telemetry into protection. Cynet’s platform correlates signals across the environment to understand the full attack story, not just a single event. With agentic workflows and expert validation from CyOps, Cynet helps transform alerts into guided action, giving security teams the context, speed, and confidence needed to investigate, respond, and remediate.
CyOps, Cynet’s 24×7 MDR team, monitors alerts, investigates suspicious activity, manages incidents, supports threat hunting, and guides customers when expert response is needed.
Before diving into ETW internals, it is useful to show how ETW telemetry can be applied in a practical security scenario. The following example focuses on ETW-TI and LSASS memory-read activity to demonstrate how low-level telemetry can support both hunting and detection logic.
The use of ETW for security telemetry gained broader attention during the 2010s, especially as providers such as Microsoft-Windows-Threat-Intelligence became more widely discussed by the security community. ETW is not a substitute for other telemetry sources, such as kernel callbacks, AMSI, or user-mode instrumentation. Rather, it is a complementary source of visibility for detections that can occur asynchronously or would otherwise require complex and fragile collection mechanisms.
ETW-TI is a Microsoft-provided ETW provider designed for security-relevant telemetry. It exposes information about operations such as virtual memory allocations, virtual memory protection changes, section mapping, APC queuing, and other behaviors commonly associated with in-memory threats.
To demonstrate ETW-TI in practice, Cynet Research Labs focused on a simple but high-value detection question:
Can we identify when an unexpected process attempts to read memory from lsass.exe?
This question is important because LSASS is involved in Windows authentication and contains sensitive credential material in memory. When an unusual process reads LSASS memory, it can be a meaningful signal for credential-access hunting and detection.
In this scenario, the relevant telemetry comes from the Microsoft-Windows-Threat-Intelligence provider. More specifically, the hunting and detection logic uses the KERNEL_THREATINT_TASK_READVM task, which represents virtual memory read activity.
Figure 1: ETW-TI READVM schema
The event schema includes several fields that are useful for hunting and detection, including:
The detection logic starts with three core elements:
Figure 2: Hunting methodology for LSASS
The hunting-to-detection pipeline begins by collecting ETW-TI events from the Microsoft-Windows-Threat-Intelligence provider and filtering for events where the task is KERNEL_THREATINT_TASK_READVM. In ETW-TI, READVM represents virtual memory reading, and related keywords can help indicate whether the read occurred in a local or remote process context. The logic then resolves the TargetProcessId and identifies cases where the target process is lsass.exe.
After confirming that LSASS was the target of the memory-read operation, the logic resolves the CallingProcessId to identify the source process that performed the read. The source process is then enriched with additional context, including execution path, parent process, command line, signer, user context, and protection or signature-level metadata. Once the READVM relationship is confirmed and enriched, the hunt can be converted into detection logic by suppressing known expected readers and alerting on uncommon or unexpected source processes that generate READVM activity against LSASS.
After seeing how ETW-TI can support a practical detection scenario, the next sections explain the ETW architecture that makes this telemetry pipeline possible: providers, controllers, consumers, sessions, registration, and event delivery.
Event Tracing for Windows (ETW) is the native tracing infrastructure in Windows. Introduced in Windows 2000, it provides a high-performance mechanism for collecting structured diagnostic and runtime information from the operating system, drivers, services, and user-mode applications. Although ETW is commonly associated with performance analysis, its role is broader than profiling alone: it provides a general-purpose event infrastructure for debugging, diagnostics, observability, auditing, and security monitoring.
ETW was not designed only for application developers instrumenting their own code. Its architecture also makes it valuable for system administrators, Microsoft diagnostic components, driver authors, and security vendors such as Cynet that need a low-overhead way to observe system behavior in production environments. Because ETW events can describe process activity, network behavior, registry operations, authentication flows, kernel activity, and application-specific state, ETW has become a practical telemetry source for both troubleshooting and detection engineering.
Figure 3: ETW Architecture
At a high level, ETW is built around four main roles: providers, controllers, consumers, and the ETW session infrastructure itself. Providers are components that register with ETW and emit events. A provider may be implemented by the Windows kernel, a driver, a Windows service, a framework such as the CLR, or a third-party application that exposes its own telemetry. Providers define the events they can generate, while controllers create tracing sessions and enable or disable providers for those sessions.
Consumers are the tools or applications that read the resulting event stream. They may consume events live as they are generated or process them later from an ETL trace file. Between providers and consumers sits the ETW session infrastructure: the kernel-backed mechanism that manages sessions, buffers, provider enablement, timestamps, event routing, and delivery. This separation is what makes ETW powerful: providers do not need to know who is listening, consumers do not need to modify the provider, and tracing can usually be enabled dynamically without restarting the system or the instrumented component.
According to Microsoft, there are four main types of ETW providers: WMI/MOF (classic), providers, WPP providers, manifest-based providers, and TraceLogging providers. Microsoft recommends using modern provider models – manifest-based providers or TraceLogging providers – when creating providers for Windows Vista and later, unless legacy operating system support is required.
MOF, also known as classic, providers are the legacy ETW provider model and are historically associated with WMI. They define event metadata through MOF classes, which allow consumers to decode the event payload. These providers use the older RegisterTraceGuids and TraceEvent APIs. One practical limitation of classic providers is that they can be enabled by only one trace session at a time.
WPP providers are commonly used for software and driver tracing, especially when developers want diagnostic instrumentation with relatively low implementation overhead. Like MOF providers, WPP providers use the classic RegisterTraceGuids and TraceEvent APIs, but their decoding information comes from TMF metadata, which is often associated with the provider’s PDB or generated during WPP preprocessing. WPP providers are also limited to one enabled trace session at a time.
Manifest-based providers are a modern structured ETW provider model. They define their events, fields, levels, keywords, tasks, opcodes, and channels in an XML manifest, allowing consumers to decode events using registered metadata. These providers use EventRegister and EventWrite. Unlike classic providers, manifest-based providers can be enabled by multiple trace sessions simultaneously, up to the ETW session limit that applies to modern providers.
TraceLogging providers are a newer self-describing ETW provider model. Instead of relying on a separately installed manifest or external TMF files, TraceLogging events include the metadata needed to decode them as part of the event stream. TraceLogging providers use APIs such as TraceLoggingRegister and TraceLoggingWrite. They are convenient for application-defined instrumentation and, like manifest-based providers, can be enabled by multiple trace sessions simultaneously, up to the ETW session limit that applies to modern providers.
In addition to the provider models described above, some ETW providers require special handling when consumed. These providers still belong to one of the standard provider models, but access to them or the way they are consumed may be restricted by Windows.
Two good examples are Microsoft-Windows-Threat-Intelligence, commonly known as ETW-TI, and Microsoft-Windows-Security-Auditing. ETW-TI is protected and typically requires the consumer to run with appropriate Protected Process Light (PPL) privileges, such as an antimalware PPL, to enable or consume the provider. Microsoft-Windows-Security-Auditing is also unusual: it is tied to the Windows Security event log, and consumers generally attach to the existing EventLog-Security session rather than creating and configuring a new arbitrary trace session for that provider.
Because ETW is needed early in the system lifetime, parts of its initialization begin during the Windows boot process. One of the relevant kernel entry points is EtwInitialize, which acts primarily as a boot-phase dispatcher. It is invoked during multiple boot phases and calls into EtwpInitialize, where most of the phase-specific ETW subsystem initialization
occurs.
Figure 4: EtwpInitialize overview
EtwInitialize is called with the current boot phase and, depending on the phase, either a loader block pointer or NULL. When a loader block is available, the function derives the boot ETW configuration from the loader extension, validates the boot logger list, and uses that information to initialize boot-time logging state.
In phase 0, EtwInitialize handles the boot-logger replay path. If the derived boot logger list is non-empty, it calls EtwpInitialize. For phases 1 and 2, EtwInitialize advances ETW initialization by repeatedly calling EtwpInitialize while the global ETW boot phase is still less than or equal to the requested phase. In other words, EtwInitialize it is best understood as a phase gate and dispatcher, while EtwpInitialize performing the heavier initialization work.
During phase 0, EtwpInitialize initializes core ETW state, including locks, global variables, stack lookaside state, boot timestamps, silo state, processor state, and boot logger startup. It then advances the global ETW boot phase. During phase 1, it performs the broader ETW subsystem setup: security initialization, per-processor state, registration and session plumbing, real-time connection state, tracing features, provider traits, power callback registration, silo initialization, bugcheck callback setup, and the main wave of kernel provider registrations through EtwRegister, TraceLogging, and aggregate-provider registration. During phase 2, it updates the file-information driver state and advances the ETW boot phase again.
Phase 3 is handled mostly in EtwInitialize rather than EtwpInitialize. At this stage, the function advances the global ETW boot phase, walks the logger slots from the host silo state, acquires rundown protection for usable logger entries, and checks whether their buffers require flushing. If flushing is required, it either invokes the logger context’s DPC routine when the current IRQL permits or marks the flush as pending and signals the logger’s flush event.
The ETW provider registration process usually begins through one of two kernel-mode entry points: EtwRegister or EtwRegisterClassicProvider. EtwRegister is the modern kernel-mode registration API, while EtwRegisterClassicProvider supports the classic provider interface, which is associated with legacy MOF/WPP-style providers. Regardless of the provider model, both paths eventually converge on internal ETW registration logic that creates or locates the provider’s kernel registration state.
Figure 5: Provider registration overview
One of the key internal routines involved in this flow is EtwpRegisterKMProvider. This function orchestrates the registration of a kernel-mode ETW provider: it creates or finds the provider’s GUID entry, creates the registration entry, associates the registration with the owning process and callback, evaluates the provider’s current enablement state, and records the registration event when tracing for provider registration is enabled.
The function first calls EtwpFindOrCreateGuidEntry, which is responsible for finding or creating the ETW provider entry identified by the provider GUID. Internally, ETW keeps registered providers in a GUID-indexed data structure. The hash bucket is selected from the provider GUID, after which the function walks the corresponding provider list and compares GUIDs until it either finds an existing entry or creates a new one. If the entry is found or created for a user-mode caller, ETW may also perform an access check against the provider’s security descriptor to ensure that the caller is allowed to register or interact with that provider.
After the GUID entry has been found or created, the registration path acquires the GUID entry lock and records the current thread as the lock owner. It then calls EtwpAddKmRegEntry, which initializes a registration entry, commonly represented internally as an ETW_REG_ENTRY. This entry represents a provider registration and links the registration back to the provider’s GUID entry. Among other fields, it stores the provider callback, the callback context or owning process, registration flags, the enable mask, and the association with the GUID entry.
Once the GUID entry and registration entry are in place, the registration logic evaluates the provider’s existing enablement state. It inspects fields such as ProviderEnableInfo and LastEnable in the GUID entry, determining whether the newly registered provider should already be considered enabled for one or more active trace sessions. If the provider is enabled, ETW processes the relevant enablement information, including level, keyword, and filter state, and prepares the registration so that subsequent event writes can be filtered and delivered correctly.
Finally, if provider-registration tracing is enabled, ETW emits a registration event indicating that a new provider registration has been created.
Consuming ETW data usually begins with a controller creating or opening an event tracing session. For a new session, the controller calls StartTrace with an EVENT_TRACE_PROPERTIES or EVENT_TRACE_PROPERTIES_V2 structure that describes the session name, session GUID, buffering configuration, log file mode, clock type, and other session properties. On modern Windows versions, this user-mode request eventually reaches the kernel through NtTraceControl, which acts as the central control point for ETW session-management operations. For session creation, the relevant internal path eventually reaches EtwpStartLogger, which initializes the kernel logger context used by the tracing session.
Figure 6: ETW session starting process
EtwpStartLogger receives the ETW silo state and the logger information captured from the caller. The silo state contains ETW-wide state for the relevant server silo, such as logger tables, global limits, provider state, GUID-entry state, and other ETW bookkeeping. The logger information describes the requested session, including its buffers, buffer size, logger name, logger mode, enable flags, loss counters, and related configuration.
The function begins by capturing and validating the logger and log-file name buffers, then validates the requested LogFileMode. This includes handling constraints for kernel and system loggers, real-time and file-backed sessions, paged-memory options, private logger combinations, large-buffer or MDL-backed configurations, and requests that are only valid during specific boot phases. Invalid combinations fail with STATUS_INVALID_PARAMETER or a more specific status code, and ETW may emit administrative failure events such as ETW_EVENT_SESSION_START_FAILED.
After the initial validation, the function validates any extension data, checks whether a session with the requested name already exists, resolves or creates the session GUID, and classifies special logger types. Some names and GUIDs are treated specially, including the NT Kernel Logger, the Circular Kernel Context Logger, and the EventLog-Security session. ETW then reserves a logger slot in the relevant silo logger table. Normal event tracing sessions use the general logger table, while system logger sessions are tracked separately and are subject to their own limits.
Once a slot is reserved, EtwpStartLogger acquires rundown protection for the slot and performs security checks unless the request comes from an internal or trusted path. It then allocates and initializes the logger context, copies the session GUID, configures the clock type, file and buffer sizing, flush settings, client security, stack tracing configuration, and filter extensions, and creates a log file when the selected mode requires one. It also allocates the trace buffer pool, initializes logger security, starts a logger thread when required by the session mode, publishes the logger context in the logger table, sends session notifications, updates related ETW state such as pool-tag tracing, group masks, or per-process tracing, and finally releases locks and rundown protection before returning success.
In this article, we covered the use of ETW for detection engineering and threat hunting, its positive impact on EPP vendors, and several aspects of ETW internals. We started with the high-level ETW architecture, reviewed the different provider types, and then took a deeper look at subsystem initialization, provider registration, and trace session creation.
While there are many more areas of ETW to explore, this article provides a strong foundation for anyone who wants to better understand the ETW subsystem and go beyond the surface-level information traditionally associated with it.
Looking for a powerful, cost effective XDR solution?
Search results for:
