Revolutionize Your Windows Threat Hunting: Query ETW Providers Without a VM – Introducing EtwWatcher + Video

By /

Listen to this Post

Featured Image

Introduction:

Event Tracing for Windows (ETW) is a powerful, kernel-level logging system that provides deep telemetry into system and application behavior—making it a goldmine for security researchers and threat hunters. However, querying ETW providers and comparing their events across different Windows builds traditionally required spinning up virtual machines for each OS version, a time-consuming and resource-intensive process. Jonathan Johnson’s newly released EtwWatcher changes the game by bringing ETW introspection to GitHub Pages, enabling instant, browser-based queries and cross-build comparisons.

Learning Objectives:

  • Understand how to use EtwWatcher to enumerate ETW providers and events without local VM overhead.
  • Learn to compare ETW provider schemas across multiple Windows OS builds for detection engineering and vulnerability research.
  • Acquire practical command-line techniques for collecting and analyzing ETW data using native Windows tools and the new EtwWatcher workflow.

You Should Know:

  1. What Is EtwWatcher and Why It Matters for Cybersecurity

EtwWatcher is a web-based tool that ports the functionality of EtwInspector—a classic utility for dumping ETW provider metadata—into an interactive GitHub Pages interface. It eliminates the need to maintain a fleet of Windows VMs by hosting pre-captured snapshots of ETW provider information from various Windows builds. For blue teams, this means rapidly identifying which providers and events are available on a target system without ever touching it. For red teams, understanding ETW provider differences helps evade detection or discover new logging sources that could expose their tradecraft.

Step‑by‑step guide to using EtwWatcher:

  1. Navigate to the live site: https://lnkd.in/ehnR4WVX (the live GitHub Pages link).
  2. Select a Windows build from the dropdown menu (e.g., Windows 10 21H2, Windows 11 22H2).
  3. Browse the list of registered ETW providers—each showing GUID, name, and event IDs.
  4. Use the search bar to filter providers by name or event ID.
  5. To compare two builds, click “Compare” and select a second OS version; the tool highlights added, removed, or changed events.
  6. Export the comparison results as JSON for offline analysis or integration into detection pipelines.

For local verification of ETW providers on your own Windows machine, use PowerShell as an administrator:

 List all registered ETW providers
logman query providers | Out-File -FilePath C:\etw_providers.txt

Get detailed info about a specific provider (e.g., Microsoft-Windows-Security-Auditing)
logman query providers Microsoft-Windows-Security-Auditing

Use wevtutil to list channels and events
wevtutil el | ForEach-Object { Write-Host $_; wevtutil gl $_ | Select-String "enabled" }
  1. Harvesting ETW Data for Threat Hunting: Native Windows Commands

Before leveraging EtwWatcher, security analysts often need to collect live ETW traces from endpoints. Windows provides built-in tools like logman, tracerpt, and PowerShell’s Get-WinEvent. Combining these with EtwWatcher’s offline comparison capability allows you to baseline normal provider activity against known malicious patterns.

Step‑by‑step guide for live ETW collection:

  1. Create a new ETW trace session targeting specific providers (e.g., PowerShell, Sysmon, or Kernel events): 
    logman create trace ThreatHunt -ow -o C:\traces\threat.etl -p "Microsoft-Windows-PowerShell" 0x7F 5 -ets
  2. Run the trace for a desired period (e.g., during suspicious activity), then stop: 
    logman stop ThreatHunt -ets
  3. Convert the `.etl` file to a readable format using tracerpt: 
    tracerpt C:\traces\threat.etl -o C:\reports\threat_summary.xml -of XML
  4. Parse the XML with PowerShell to filter for event IDs of interest (e.g., 4104 for script block logging): 
    [bash]$xml = Get-Content C:\reports\threat_summary.xml
$xml.Events.Event | Where-Object { $_.EventID -eq 4104 } | Select-Object TimeCreated, Data
  5. Use EtwWatcher to check if the provider’s event schema matches what your live system reported—if events are missing, an adversary might have tampered with ETW.

  6. Cross-Build Comparisons: Why OS Version Matters for Detections

ETW providers and event IDs often change between Windows builds. A detection rule written for Windows 10 1909 may fail on Windows 11 23H2 because an event ID was deprecated or a provider was split. EtwWatcher’s side‑by‑side comparison feature enables you to verify rule compatibility across your enterprise’s diverse OS estate.

Step‑by‑step comparison drill:

  1. In EtwWatcher, select your source build (e.g., Windows 10 20H2) and target build (e.g., Windows 11 22H2).
  2. Choose a critical provider like `Microsoft-Windows-Sysmon` or Microsoft-Windows-Defender.
  3. Review the diff view: green rows indicate new events in the target build, red rows show removed events.
  4. For each removed event, update your SIEM correlation rules to avoid false negatives.
  5. For new events, assess if they can augment your detection coverage (e.g., new ProcessCreate events with additional fields).
  6. Document the differences in a version‑controlled detection registry.

To cross‑verify live on a Windows machine, extract provider schema using `wevtutil` and compare with EtwWatcher’s snapshot:

 Get provider manifest (if available) for a specific event ID
$provider = "Microsoft-Windows-Security-Auditing"
wevtutil gp $provider /ge /gm | Out-File C:\temp\provider_manifest.xml

Use fc (File Compare) or PowerShell Compare-Object against a reference snapshot

4. Integrating EtwWatcher with SIEM and Detection Engineering

The JSON output from EtwWatcher comparisons can be fed directly into detection-as-code pipelines. For instance, you can generate Sigma rules that automatically adjust eventID conditions based on the target OS build. This reduces maintenance overhead and improves rule accuracy.

Step‑by‑step integration:

  1. Export comparison results as JSON from EtwWatcher (the compare view includes an “Export” button).
  2. Use a Python script to parse the JSON and produce a mapping dictionary: 
    import json
with open('etw_comparison.json') as f:
diff = json.load(f)
sigma_conditions = []
for event in diff['added']:
sigma_conditions.append(f" - EventID: {event['eventId']}  build {diff['targetBuild']}")
print('\n'.join(sigma_conditions))
  3. Inject this mapping into a Sigma rule template using Jinja2 or simple string substitution.
  4. Deploy the adapted Sigma rule to your SIEM (e.g., Splunk, Sentinel, or Elastic) via its native conversion tools (sigmac).
  5. Schedule weekly or monthly re‑runs of EtwWatcher snapshots to catch changes in new insider preview builds.

For Windows native detection, configure PowerShell to subscribe to ETW events in real time:

 Real‑time subscription to a provider’s events
$query = "[System/Provider[@Name='Microsoft-Windows-PowerShell']]"
New-WinEvent -Query $query -MaxEvents 0 | ForEach-Object { Write-Host $_.Message }

5. Security Hardening: Mitigating ETW Tampering Attacks

Adversaries increasingly target ETW to disable logging (e.g., using `logman stop` or patching nt!EtwpEventWriteFull). Understanding which ETW providers are critical and monitoring for tampering attempts is essential. EtwWatcher helps establish a baseline of expected providers—any deviation may indicate a compromise.

Step‑by‑step hardening and monitoring:

  1. Use EtwWatcher to generate a baseline of all providers on a known‑good reference machine of each Windows build in your environment.
  2. On production endpoints, run a scheduled script that enumerates providers and compares against the baseline: 
    $current = logman query providers | Where-Object { $_ -match "GUID" }
$baseline = Get-Content -Path "\share\baselines\$env:COMPUTERNAME_etw.txt"
if (Compare-Object $current $baseline) { Write-Warning "ETW provider drift detected" }
Alert SIEM via Write-EventLog or Invoke-WebRequest to webhook
  3. Enforce ETW protection via Windows Defender Attack Surface Reduction rules (ASR) – rule ID 5b4c0d8f-6a8f-4b0c-9d6e-5e6b8a7c9d0f blocks `logman` from stopping critical traces.
  4. Monitor for event ID 1102 (audit log cleared) and event ID 2 from source `EventTrace` (ETW session stopped).
  5. Deploy Sysmon with configuration to log ETW session creation and destruction (event ID 25 and 26).

6. Contributing to EtwWatcher: Uploading New OS Snapshots

Jonathan Johnson plans to actively upload snapshots as new builds emerge, but the community can contribute too. The tool relies on `EtwInspector` locally to generate provider manifests, which are then pushed to the GitHub repository.

Step‑by‑step contribution workflow:

  1. In a Windows VM of the target build (the only time you need a VM), download the EtwInspector binary from the repo’s releases: https://lnkd.in/ei8CBB3x

2. Run as administrator to dump all providers:

EtwInspector.exe list --output-json > providers_buildXXXX.json

3. Validate the JSON against the schema defined in the EtwWatcher repository.
4. Fork the repo, add the JSON file under the `snapshots/` directory with a clear naming convention (e.g., windows11_23H2_build12345.json).
5. Submit a pull request describing the build version and any notable changes.
6. Once merged, all users can immediately query that build without ever launching a VM.

For automated snapshot collection in a CI/CD pipeline, use a Windows runner on GitHub Actions with the following YAML snippet:

- name: Capture ETW Providers
run: |
./EtwInspector.exe list --output-json > snapshot.json
echo "SNAPSHOT_DATE=$(Get-Date -Format yyyy-MM-dd)" >> $env:GITHUB_ENV
- name: Upload Snapshot
uses: actions/upload-artifact@v3
with:
name: etw-snapshot-${{ env.SNAPSHOT_DATE }}
path: snapshot.json

What Undercode Say:

  • EtwWatcher eliminates a major friction point in Windows security research, democratizing access to ETW metadata that was previously locked behind expensive lab setups. This accelerates detection engineering and cross‑build compatibility testing.
  • By combining web‑based snapshots with native command‑line tools, analysts can now perform sophisticated ETW querying and comparison without sacrificing depth. The tool bridges the gap between quick reconnaissance and deep forensic analysis, making ETW more accessible to blue teams of all sizes.

Prediction:

EtwWatcher will evolve into a community‑driven ETW registry, similar to Sysmon’s modular configuration repository. Within 12 months, expect integrations with major SIEMs and EDRs that automatically pull the latest provider snapshots, enabling self‑adjusting detection rules. As Windows continues to expand its telemetry surface, tools like this will become indispensable for security operations, eventually leading to cloud‑hosted ETW analytics platforms that compare millions of events across every released build in real time. The era of guessing ETW event IDs is ending.

▶️ Related Video (80% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Jonathan Johnson – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: