Introduction

This event catalog covers thousands of Windows events. At the time of writing, we’re tracking 97138 events across 1366 providers. Other sources offer less coverage: Microsoft Learn and Ultimate Windows Security each document fewer than 500 events with meaningful detail. Community resources have great detail for a small set of popular events, and XML manifests and MOF definitions bundled with Windows represent the vast majority of remaining documentation. detection.wiki catalogs these events in a searchable static site backed by authoritative sources. This post explains how it works under the hood.

Navigation #

The search function supports inclusion/exclusion of events with Sigma rules, sample data (.evtx files parsed to JSON), field descriptions, reference URLs, or community notes. There’s also a 3rd Party filter for non-Microsoft events (about 500 events with providers like Splashtop, SentinelOne, Sophos, TeamViewer). You’re encouraged to reach out with .evtx files from novel sources not present in the catalog.

You can also write inclusion/exclusion filters in the query:

To perform exact-match search queries, use quotes:

"process creation" - matches that exact phrase

"logon type" 4624 - exact phrase plus free text term, both must match

Examples:

kerberos has:sigma - Kerberos events with Sigma rules

"privilege escalation" has:sample no:3rdparty — exact phrase, with sample event, Microsoft only

To complement search operator support, the site also provides a limited set of Vimium-style navigation features:

Scrolling #

j and k to scroll down/up

d and u to scroll one-half page down/up

gg to scroll to the top

G to scroll to the bottom

Link hints #

f to show a single character per link that you can enter to open in the same tab

Searching #

/ to start a search (note that it will take you to the home page)

The data #

Information on Windows events exists in at least four formats across varied sources:

• ETW manifests: XML schemas embedded in binaries, accessed directly (e.g., via wevtutil gp, Get-WinEvent -ListProvider, or manifest extraction tools like PerfView or WEPExplorer)
• MOF class definitions: the legacy WMI-based schema mechanism for classic trace providers
• .evtx files: captured event instances with populated field values
• Community documentation: Microsoft Learn, Ultimate Windows Security, blog posts, etc

No single source is complete.

The pipeline #

Data acquisition is separated from catalog building with a three stage pipeline.

Stage 1: Source converters ingest each data format into a common intermediate YAML schema. One script handles XML manifests. Another handles TSV exports (from using WEPExplorer on Windows 11 Enterprise 25H5 26200.7840 and Server 2025 Standard 24H2 26100.32230) and MOF files. A third uses NSA’s Windows Event Log Messages tool to retrieve event data embedded in binaries and Velocidex’s evtx parser to parse .evtx files. A fourth handles CSV output from MSLearn and UWS scraping scripts to assemble a list of URLs for the reference field in applicable events. There are other converters; each runs once per new data source and writes to data_sources/yaml/.

Stage 2: A merge script reads every YAML file and combines them into the canonical catalog, one YAML file per (provider, channel, event ID) group. The merge applies OS version and timestamp priority: Windows 11 25H2 data overwrites Server 2022 data for the same event, because newer versions carry more accurate schemas. The merge also injects reference links from Microsoft Learn and other documentation sources.

Stage 3: Hugo reads all of the YAML files and produces Markdown with TOML frontmatter, plus a compact JSON search index. Hugo then builds static HTML pages.

Not all events in this catalog are the same quality. Real samples (1,641 events) come from captured .evtx files. These have complete event data: system headers, timestamps, process IDs, and every field populated with actual values. An analyst can see exactly what Event ID 4624 looks like in practice, with real SIDs, logon types, and network addresses.

Manifest stubs (over 85,000 events) come from Windows ETW manifests and MOF definitions. These carry field names and types (ie, win:SID, win:HexInt64, win:UnicodeString) but no sample values. Descriptions per field are generally unavailable because they’re not, as far as I know, present in Windows. The site marks stubs clearly so analysts know what they’re working with.

JS search #

The site has no backend. Search runs in the browser against a 1.4MB compressed (8.6MB raw) JSON index that lazy-loads on first use.

Field types from the source #

Every field carries its type directly from Windows internals. Manifest-derived fields use win: prefixes (win:SID, win:UnicodeString, win:GUID). MOF-derived fields use mof:, such as mof:uint32, mof:string. These are the same annotations Windows uses to serialize event data. Maybe this will be useful to you when parsing raw ETL traces or writing detections.

Static site #

The entire catalog compiles to static HTML. Assets are compressed with gzip and Brotli for CDN delivery, but you can also host the site on an air-gapped network. The main event page is 27KB compressed (220KB raw), tthe largest provider page microsoft-windows-hyper-v-vmms is 95KB compressed (2.4MB raw), and the largest single event page Sysmon Event ID 1 is 84KB compressed (471KB raw). The site also does a lot of prefetching to ensure a snappy experience.

What’s next #

I have some ideas to further grow the catalog, mainly oriented around contributions to community notes per event, hence the .wiki TLD. As a static site, an actual wiki is a bit difficult to implement, so I’ll keep cooking this until I have a better plan. The existing build pipeline is surprisingly complex: there’s a ton of data sources in different formats with distinct scripts for conversion to YAML, one script merges all of the YAML into a catalog, a second script converts the YAML catalog into Markdown files, Hugo builds all Markdown and templates into static HTML, rclone syncs to Cloudflare R2, wrangler deploys the Cloudflare Worker.

Anyway, please send interesting community notes for events and novel .evtx files to sonny@detection.wiki.

Maybe I can add audit policy instructions to assist with questions like ‘how do I enable this event?’ nasbench’s Eventlog Compendium has some support for this, but it is not yet complete.

I’m considering using PDBs to enrich the catalog with enum and #define constants for fields. The manifest will tell you that a field is a 32-bit integer, but the PDB can tell you that 0x1 means TokenElevationTypeFull. PDBs also contain structs that populate event payloads and show relationships between fields and nested structures. Finally, symbols for TraceLogging providers can expose event names, field names, and types (these providers don’t ship XML manifests, and embed metadata directly into the ETW payload). Short of a PDB or live capture, these are basically undocumented. The enum/flag mapping is useful for detection engineering purposes, and I’m most likely to work on that at some point this year (the others are less certain). I recommend reading Matt Graeber’s extensive writing about ETW architecture if you’re interested in this subject.

Thanks #

Many thanks go out to:

• Contributors to the NextronSystems repo evtx-baseline, especially @Neo23x0, @frack113, and @nasbench.
• Contributors to the YamatoSecurity repo Sample EVTX Repository, which contains evtx files they created as well as those from DeepBlueCLI, SBousseaden, and mdecrevoisier.
• Contributors to the NSA repo Windows-Event-Log-Messages.
• Contributors to the Velocidex repo evtx, a Golang parser for event logs.
• lallousx86 for their project WEPExplorer.
• Randy F. Smith for their timeless Windows security event encyclopedia.

I couldn’t have done this without you!