Affected Platforms: Windows 10, Windows 11, Windows Server 2016 and later
Impacted Users: System administrators, forensic investigators, and incident responders analyzing Windows telemetry and ETW artefacts
Impact: Forensic visibility into process execution data when relying on undocumented or inconsistently populated telemetry files such as AutoLogger-Diagtrack-Listener.etl
Severity Level: Low (for active exploitation) / Moderate (for forensic or incident response limitations)
During a recent incident response engagement, FortiGuard IR services (FGIR) responded to a ransomware attack where the threat actor heavily used anti forensic techniques to cover their tracks and to avoid their malware getting into the hands of researchers. They attempted to achieve this by deleting files and folders they had created, clearing logs and obfuscating malware.
While analyzing a disk image of a compromised Windows Server 2016 system, FGIR was able to identify historical evidence of deleted malware and tools used by the threat actor, inside an obscure ETL file called AutoLogger-Diagtrack-Listener.etl. ETL files are generated by the Windows ETW (Event Tracing for Windows) infrastructure.
Event Tracing for Windows (ETW) is a built-in, high-performance logging framework that enables Windows and applications to record detailed events with minimal overhead. Instead of writing plain text logs, ETW uses providers such as the kernel, TCP/IP stack, or registry, which send structured event data into ETW sessions. These sessions can buffer the data for real-time consumption or write it to binary Event Trace Log (ETL) files.
ETW involves three main roles: providers (sources of events), controllers (which start, stop, and manage sessions using tools like logman or PerfMon), and consumers (such as debuggers, Event Viewer, or EDRs, which process and interpret the data).
This framework is powerful because it provides granular visibility into low-level OS activity (like process creation, registry writes, or DNS queries), is optimized for speed by running in kernel mode, and offers flexibility since events can be consumed live without writing to disk. Modern EDR tools leverage this capability by subscribing directly to ETW providers to monitor behaviors, such as process launches, in real time.
The ETL file AutoLogger-Diagtrack-Listener.etl is typically located at:
%ProgramData%\Microsoft\Diagnosis\ETLLogs\AutoLogger\
This ETL file records telemetry generated by the Connected User Experiences and Telemetry (DiagTrack) service, also known as the Customer Experience Improvement Program (CEIP). It is created when the DiagTrack service is enabled and actively collecting diagnostic data.
The following four levels of verbosity can be configured for telemetry logging by the DiagTrack service by setting the value of the registry key AllowTelemetry:
| Value | Level | Description |
|---|---|---|
| 0 | Security | Server default (no ETL logs) |
| 1 | Basic | Minimal data collection |
| 2 | Enhanced | Deprecated in newer builds |
| 3 | Full | Complete telemetry capture |
By default, the telemetry level is set to 0x1, which, in our experience, does not result in the creation of the AutoLogger-Diagtrack-Listener.etl file.
During the IR engagement, while analyzing the compromised disk image, FGIR found strings of interest related to the threat actor’s activity, inside the AutoLogger-Diagtrack-Listener.etl file. Parsing and advance analysis of the ETW payload inside the ETL file revealed that process-creation events within the KernelProcess → ProcessStarted stream can retain valuable historical data, including command-line details for previously executed binaries.
Figure 4: Ransomware Binary svhost.exe executed to encrypt drives on remote systems
Other columns of interest recorded in these ETW events (event ID 1 for this provider), are shown below:
| Field | Description |
| ProcessID | The process ID (PID) assigned by Windows. |
| ParentProcessID | The PID of the parent process. |
| SessionID | The Windows session ID (0 = services, >1 = user sessions). |
| ImageName | The full path of the executable (e.g., C:\Windows\System32\notepad.exe). |
| CommandLine | The command-line string used to start the process (if enabled by flags). |
| UserSID | The security identifier (SID) of the user account that started the process. |
| PackageFullName | (On modern Windows) The UWP app package name if it’s an AppX process. |
| Flags | Internal flags about how the process was created. |
| Reserved | Reserved for system use. |
Table 1: Processes Executed Details
FGIR was also able to extract evidence of execution of binaries that had been deleted by the threat actor, including the tool GMER (renamed gomer.exe) and several malicious batch files.
With the intention of identifying the exact configuration and state which results in the creation and population of the AutoLogger-Diagtrack-Listener.etl file, we experimented with configuration changes and system states on a Windows Server 2022 and a Windows 11 system. We changed the telemetry verbosity value to 3 and executed the following commands to write the ETL file to the specified location. This resulted in the creation of the ETL file of interest. However, the file remained unpopulated with any telemetry.
New-ItemProperty -Path
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection" -Name AllowTelemetry -Value 3 -PropertyType DWord -Force
logman start "AutoLogger-Diagtrack-Listener" -ets
logman update "AutoLogger-Diagtrack-Listener" -o
"C:\ProgramData\Microsoft\Diagnosis\ETLLogs\AutoLogger\AutoLogger-Diagtrack-Listener.etl" -ets
The first command modifies the AllowTelemetry registry key to increase verbosity to its maximum level (3 – Full). The second command starts the AutoLogger-Diagtrack-Listener ETW session. And the third updates it to explicitly write output to the designated ETL file. Together, these commands attempt to manually activate and capture telemetry that would normally be generated by the DiagTrack service.
Despite successful execution, the resulting file remained empty. This suggests that population of the file may depend on internal or undocumented conditions within the DiagTrack service.
During testing, FGIR observed that although the AutoLogger-Diagtrack-Listener.etl file could be created, it did not record any telemetry. Further investigation revealed that the file’s population behavior might depend on internal triggers of the DiagTrack service that are not publicly documented.
Despite testing, it remains unclear under what exact conditions the AutoLogger-Diagtrack-Listener.etl file is populated. Adjusting the AllowTelemetry registry key to 3 (Full) and explicitly reconfiguring the session using the logman update command did not result in any events being written to the file. The autologger session remained visible and active, yet the ETL file stayed empty.
This suggests that the population of this artefact is controlled internally by the Connected User Experiences and Telemetry (DiagTrack) service and may be conditional on triggers that are not publicly documented.
Further research is needed to uncover the specific conditions or system triggers that lead to the population of AutoLogger-Diagtrack-Listener.etl. Understanding when and how this file records telemetry could transform it into a valuable forensic artefact—particularly in incident response investigations where process creation and execution traces are critical. Researchers are encouraged to experiment across different Windows builds, telemetry levels, and service states to help establish the evidentiary value of this log.
The activities and telemetry behaviors described in this report—such as process creation, command-line execution, and the use of renamed administrative tools—are routinely detected and correlated by Fortinet’s AI-powered security solutions.
FortiEDR provides continuous, real-time monitoring of process activity and memory behavior at the endpoint level. Its kernel-level visibility enables detection of events such as unauthorized process launches, script-based execution, and fileless attacks that attempt to evade logging mechanisms like ETW.
FortiAnalyzer and FortiSIEM can ingest native Windows telemetry, including ETW data, to correlate suspicious events across multiple hosts and environments. This allows analysts to reconstruct execution chains and identify stealthy or deleted activity, similar to the evidence recovered in this investigation.
FortiGuard Threat Intelligence continuously enriches these detections with real-time updates from Fortinet’s global research network, ensuring emerging malware variants, renamed binaries, and living-off-the-land techniques are recognized and blocked.
Organizations using Fortinet’s integrated Security Fabric—including FortiGate, FortiEDR, and FortiAnalyzer—benefit from unified visibility and detection coverage across network, endpoint, and telemetry sources.
If you believe this or any other cybersecurity incident has affected your organization, please contact the FortiGuard Incident Response Team.