FortiGuard Labs has revealed that a little‑known Windows telemetry file — AutoLogger‑Diagtrack‑Listener.etl — can contain usable forensic traces of process execution, including evidence of
deleted malware and attacker activity, offering incident responders an unexpected secondary source of truth when conventional logs have been tampered with.
Background
Event Tracing for Windows (ETW) is a kernel‑level telemetry and tracing framework built into Windows that records structured, high‑volume system events to in‑memory buffers or binary Event Trace Log (ETL) files. ETW providers range from kernel subsystems (process/thread, image load, network, etc. to user‑mode services and applications; consumers include Event Viewer, the Windows Performance Toolkit, and many modern EDR products that
subscribe directly to ETW streams for real‑time visibility. The Connected User Experiences and Telemetry service — commonly known as
DiagTrack — is Microsoft’s telemetry service that collects diagnostic and usage data from endpoints. On systems where it is active, Windows may create autologger ETL sessions under ProgramData\Microsoft\Diagnosis\ETLLogs\AutoLogger\, producing files such as AutoLogger‑Diagtrack‑Listener.etl. FortiGuard’s incident response team (FGIR) discovered that, in at least one ransomware compromise, this ETL file contained
process‑creation records that survived attacker anti‑forensic cleanup.
What FortiGuard Found: forensic traces inside AutoLogger‑Diagtrack‑Listener.etl
During a ransomware investigation, FGIR found that the AutoLogger‑Diagtrack‑Listener.etl file exposed a kernel process trace stream containing historical records of process launches — including command‑line arguments, image paths, process and parent PIDs, and user SIDs — even after the adversary had removed binaries from disk and cleared standard event logs. The investigation documented traces for a renamed GMER rootkit (observed as gomer.exe) and a ransomware payload (notably named svhost.exe in their report) that had encrypted remote drives. Key observations from FGIR’s analysis:
- The ETL contained KernelProcess → ProcessStarted events that included multiple useful fields (ProcessID, ParentProcessID, SessionID, ImageName, CommandLine, UserSID, etc.. These are the same fields defenders rely on when reconstructing execution chains.
- The attacker had used anti‑forensic techniques (file deletion, log clearing, binary obfuscation), but the ETL payload persisted on disk and still showed evidence of execution.
- FGIR attempted to reproduce the behavior on Windows Server 2022 and Windows 11 by increasing telemetry verbosity and manually starting the AutoLogger‑Diagtrack‑Listener session; they could create the file but could not force it to populate on demand, implying undocumented internal triggers control when DiagTrack writes to this file.
These findings point to an
overlooked forensic artifact that can survive typical cleanup actions — potentially a decisive advantage for incident responders who image disks and need sources of historical process activity.
Why this matters: ETW as a secondary forensic source
Traditional Windows artifacts — the Security event log, Sysmon logs (if deployed), Windows Error Reporting (WER), and EDR telemetry — are primary sources for process execution and user actions. Adversaries aware of these sources can and do attempt to erase or corrupt them during intrusions. ETW operates differently:
- ETW is implemented in the kernel and can be configured as autologger sessions that are enabled at boot or by service, and they write binary ETL files. Because ETW can be consumed live by EDRs, many detection stacks rely on live ETW streams instead of on‑disk logs.
- Some autologger sessions — historically used for diagnostics and performance collection — are persisted as ETL files in system paths that are not first targets for forensic clearing or casual attacker cleanup. The AutoLogger‑Diagtrack‑Listener.etl file lives under %ProgramData%\Microsoft\Diagnosis\ETLLogs\AutoLogger.
Because ETW events are structured and include kernel provider payloads (for example, the
Microsoft‑Windows‑Kernel‑Process provider emits ProcessStart events with rich metadata), ETL files can contain a level of detail not always present in other logs — including the true creator PID vs. the parent PID, image path, and full command line when available. Multiple independent writeups and EDR artifacts (Velociraptor, KrabsETW examples) document how the Kernel‑Process provider can deliver exactly this data.
Technical anatomy: how AutoLogger autologger sessions and DiagTrack interact with ETW
ETW providers, controllers, and sessions
ETW is composed of three roles:
- Providers — sources of events (kernel, network, services).
- Controllers — components that start/stop sessions (e.g., logman, tracelog, WPR).
- Consumers — tools that read the stream (EDR agents, Event Viewer, WPA).
An
autologger is a type of ETW session configured to start automatically (often during boot) and capture specific providers. Windows includes many autologger definitions (AutoLogger‑* entries) under the registry and WMI autologger settings; AutoLogger‑Diagtrack‑Listener is one such session. Autologgers can be configured via the registry or manipulated with tools like logman and PowerShell ETW cmdlets.
The Kernel‑Process provider and ProcessStart events
The Microsoft‑Windows‑Kernel‑Process provider is the kernel provider responsible for process lifecycle events. Event ID 1 (ProcessStart) exposes fields such as ProcessID, ParentProcessID, SessionID, ImageName, and sometimes CommandLine and UserSID depending on the provider version and trace flags. Capturing and persisting these events into an ETL allows post‑mortem parsing of process activity. Multiple security tooling projects and docs discuss parsing ProcessStart events from ETL traces for historic process rundown.
Where DiagTrack fits in
DiagTrack (Connected User Experiences and Telemetry) orchestrates diagnostic telemetry collection. In FortiGuard’s tests, setting the AllowTelemetry registry value to the highest verbosity (3) and starting the AutoLogger‑Diagtrack‑Listener session created the ETL file, but did not necessarily populate it with events. FGIR’s experiments suggest that DiagTrack may only write meaningful telemetry under internal conditions that are not publicly documented — for instance, when particular telemetry pipelines or triggers fire in the OS or when Microsoft’s telemetry orchestration chooses to collect and persist certain events. That behavior — both the file’s existence and its conditional population — is an important nuance for responders.
Reproducing the artifact: what FGIR did and what they could not force
FGIR’s controlled tests manipulated telemetry settings and autologger sessions using documented tools. The steps they reported included:
- Increasing telemetry verbosity via the AllowTelemetry registry key (set to 3 = Full).
- Starting the AutoLogger‑Diagtrack‑Listener ETW session with logman.
- Updating the autologger to explicitly write to %ProgramData%\Microsoft\Diagnosis\ETLLogs\AutoLogger\AutoLogger‑Diagtrack‑Listener.etl.
Command examples FGIR used:
- 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
Despite successfully creating the file and enabling the autologger session, the ETL remained empty in their tests. This strongly suggests that file creation and file population are distinct behaviors controlled by DiagTrack’s internal logic — and that one cannot rely on simply toggling AllowTelemetry and starting a session to reproduce a populated ETL. FGIR explicitly called for further research across Windows builds and telemetry states to discover precise triggers.
Cross‑verification and independent context
Fortinet’s FGIR report is the primary disclosure of this specific artifact. The broader technical claims (that ETW can record kernel process events and that autologger sessions can write ETL files) are well‑documented in Microsoft developer guidance and public tooling (logman, tracelog, tracerpt, Windows Performance Analyzer). Multiple security tooling projects (Velociraptor, KrabsETW examples, ETW guides) corroborate that the Microsoft‑Windows‑Kernel‑Process provider can deliver ProcessStart records useful for forensics. Together, these independent references support the technical plausibility of Fortinet’s findings even while the
DiagTrack‑specific population behavior remains undocumented by Microsoft. Where Fortinet’s report makes a claim that cannot be externally verified today — namely the precise internal triggers DiagTrack uses to decide when to write to AutoLogger‑Diagtrack‑Listener.etl — that claim should be treated as
observational and provisional until Microsoft documents the behavior or further independent testing reproduces a populated ETL under known conditions. FortiGuard explicitly framed that part as unresolved and recommended further research.
Practical recommendations for defenders and incident responders
The FortiGuard finding should change how organizations collect and prioritize forensic evidence. Practical steps:
- Preserve the entire system image before performing live remediation. ETL files under ProgramData\Microsoft\Diagnosis\ETLLogs\AutoLogger\ should be collected as part of a standard forensic capture because they may contain immutable binary traces that survive naive cleanup.
- Add AutoLogger‑Diagtrack‑Listener.etl (and other AutoLogger ETL files) to triage and collection playbooks:
- Check %ProgramData%\Microsoft\Diagnosis\ETLLogs\AutoLogger\ for any *.etl files.
- When imaging, preserve the whole Diagnosis folder and the SYSTEM registry hives that control autologgers for later analysis.
- If live collection is required, use documented ETW tooling to capture kernel process events:
- Use logman / tracelog / wpr to start a kernel process trace (if permitted).
- Record NT Kernel Logger or Microsoft‑Windows‑Kernel‑Process provider events with process and image flags enabled.
- Use tracerpt or Windows Performance Analyzer (WPA) to convert ETL into readable tables and extract EventData fields.
- Parse ETL files with robust toolchains:
- Windows: tracerpt can convert an ETL into an XML or CSV summary for offline parsing; Windows Performance Toolkit (WPA) and Event Viewer can also read ETL files.
- Open‑source/IR tools: krabsETW, Velociraptor artifacts, and ETL‑to‑JSON parsers can automate extraction of ProcessStart records. Documented examples show how the Kernel‑Process provider maps fields such as ImageName, ProcessID, ParentProcessID and CommandLine.
- Correlate ETW artifacts with other evidence: match PIDs, timestamps, and command lines against recovery artifacts (shadow copies, user folders, EDR memory dumps) to reconstruct attacker objectives and lateral movement.
- Harden logging posture: EDRs that subscribe to ETW in real time are less likely to be fully evaded by attempts to delete on‑disk events; ensure endpoint agents have kernel‑level visibility and are centrally collecting and retaining ETW telemetry where feasible. Fortinet notes that FortiEDR, FortiAnalyzer and FortiSIEM can ingest native Windows telemetry including ETW for correlation.
Limitations, risks, and cautionary notes
- Conditional evidence: FGIR’s tests show that AutoLogger‑Diagtrack‑Listener.etl creation ≠ population. The conditions that cause DiagTrack to persist events are undocumented, so defenders should not assume the ETL will always contain ProcessStarted records on all systems. Treat the presence of useful ETL as opportunistic rather than guaranteed.
- Telemetry/privacy and enterprise policies: Many organizations intentionally restrict telemetry (AllowTelemetry = 0 or 1) for privacy or compliance reasons. In such environments, DiagTrack may not be active or may not create these autologger files. Changing telemetry settings for the sake of triage must be weighed against privacy policy and regulatory constraints.
- Evolving OS behavior: Windows telemetry subsystems have changed across builds; Microsoft may change DiagTrack behavior or relocate/rename autologger sessions in future updates. Any forensic playbook that relies on a specific autologger path must be treated as version‑sensitive and periodically validated.
- Adversary countermeasures: An aware adversary could attempt to identify and target ETL files for deletion or tampering. ETL files are binary and sometimes large; attackers with write permissions can attempt to wipe them. Preservation via imaging remains the most reliable defensive posture.
- Tooling and interpretation pitfalls: ETL binary payloads require correct provider manifests and schema to decode. Using mismatched schemas or outdated manifest sets can produce erroneous or incomplete decoding of the KernelProcess payload. Use up‑to‑date ETW manifests or parsing libraries when extracting fields like CommandLine.
Detection engineering and hunt ideas
- Treat the existence of a populated AutoLogger‑Diagtrack‑Listener.etl file on a disk image as evidence worth parsing. Build a short playbook:
- On ingestion, automatically scan ProgramData\Microsoft\Diagnosis\ETLLogs\AutoLogger for ETL files.
- Convert ETL → CSV/XML with tracerpt or WPA and extract ProcessStart events.
- Cross‑reference extracted command lines and image paths against threat intelligence (renamed AV evasion binaries, common living‑off‑the‑land scripts such as gomer.exe/GMER replicas, svhost/svchost renames).
- Prioritize hosts whose ETL content shows execution from unexpected paths (Temp folders, AppData, removable drives) for full IR.
- If you operate an EDR or SIEM that can ingest ETW, ensure the pipeline captures KernelProcess provider events or that your endpoint agent subscribes to the same provider keywords that emit ProcessStart and ImageLoad events to avoid post‑compromise blind spots.
What remains unknown — and research priorities
FortiGuard’s disclosure deliberately highlights gaps:
- Exactly which internal triggers or service states cause DiagTrack to write meaningful telemetry into AutoLogger‑Diagtrack‑Listener.etl.
- Whether specific Windows builds, OEM images, or enterprise configuration policies influence the autologger’s population behavior.
- The retention and rollover behavior for this autologger on long‑running systems under different telemetry levels.
These are testable research questions. Recommended next steps for the security research community:
- Run instrumented experiments across multiple Windows versions (Windows Server 2016, 2019, 2022, Windows 10/11 builds) with varying telemetry settings, account activity patterns, and DiagTrack states.
- Capture full ETW provider maps and recorded manifests before/after enabling DiagTrack to detect what manifests and schema are required to decode payloads reliably.
- Share structured replication results (clearly lab‑only) so practitioners can establish reliable forensic heuristics for when to expect populated AutoLogger ETL files.
Conclusion
FortiGuard’s finding that AutoLogger‑Diagtrack‑Listener.etl can contain historic process creation records — including evidence of deleted malware — is an important reminder that Windows exposes multiple telemetry layers that can act as
secondary forensic sources. ETW’s architecture and kernel providers are powerful tools for defenders when primary artifacts are missing or destroyed. At the same time, the behavior of DiagTrack and the AutoLogger session is not fully documented; defenders must treat this artifact as
potentially useful but not guaranteed, incorporate it into forensic collection playbooks, and continue testing across Windows builds to understand scope and reliability.
Operationally, the takeaway is simple and actionable: when imaging suspected compromises, preserve the Microsoft\Diagnosis ETL folders and consider ETW trace parsing as part of your IR toolkit. In the broader picture, research that turns these opportunistic artifacts into reliable, reproducible signals will materially improve incident response outcomes — but it will require coordinated, cross‑platform testing and close attention to privacy and telemetry policy constraints.
Source: Cyber Press
https://cyberpress.org/windows-telemetry-logs/