Skip to content

Coverage

Two questions, answered from data shipped in the kit: how do the pieces fit together, and if I turn these settings on, which attack techniques could my logs actually see, and for the rest, why not? The numbers come from the maintainer tool tools\Export-AttackCoverage.ps1, which also works offline on your own baseline CSV.

How the pieces fit

How the kit works under the hood, in one picture. The claim it makes: all configuration derives from a single settings table (coverage additionally reads the shipped ATT&CK snapshot), snapshots come in once with their dates recorded, and events flow out to your collector - the kit never talks to the internet at runtime.

Vendored snapshots Yamato baselines · MITRE ATT&CK copied once, dated, credited Settings table the single source of truth Windows host audit policy · channels · registry SMB auditing Windows Event Log Event Collector ForwardedEvents log SIEM Coverage report Export-AttackCoverage Fleet artefacts GPO pack · WEF XML Intune / GPO mappings Yamato: extracted once, drift-checked ATT&CK snapshot Enable applies · Test verifies events WEF push (WinRM) handoff — out of kit scope generators compile apply WEF subscription

One settings table feeds the host, the fleet artefacts and the verification; events leave through the Windows Event Log to your collector.

Reading it top to bottom:

  • Snapshots in: the Yamato baselines were extracted once into the settings table, and the MITRE ATT&CK data into the coverage mapping (data/attack/) - two separate destinations, each with source, version and date recorded (data/*/README.md); CI drift-checks everything generated from them.
  • One table: every script - the builder, Enable, Test, the coverage report and all three fleet generators - dot-sources WinLogKit.Settings.ps1 (and the shared helpers in WinLogKit.Common.ps1), so applied config, deployed artefacts and verification can never disagree.
  • Events out: hosts write to the Windows Event Log service; Windows Event Forwarding carries selected channels over WinRM to a collector's ForwardedEvents log; your SIEM picks up there, deliberately outside the kit.

Which application each piece touches: Enable/Test drive auditpol.exe, wevtutil.exe, the registry and the SMB configuration cmdlets; the Settings catalog mapping is applied in Microsoft Intune; the subscription XML by the Windows Event Collector (wecutil); the GPO pack and Group Policy paths in GPMC / LGPO.exe.

Behaviour category mapping

The kit organises settings by behaviour category rather than by channel, so a monitoring requirement ("we must see scheduled task abuse") traces to the exact settings that satisfy it. "Subcategory" = advanced audit policy subcategory (Security log). DC = generated on domain controllers only. HV = HighVolume tier. The Channels column is shorthand (for example AppLocker x4 for the four AppLocker channels); the exact channel names are in the settings table and on the Reference page.

Category Audit subcategories Channels Registry Coverage
Authentication Credential Validation; Logon; Logoff; Account Lockout; Other Logon/Logoff; Special Logon; Kerberos Authentication Service (DC); Kerberos Service Ticket Operations (DC) Security; Microsoft-Windows-NTLM/Operational MSV1_0 RestrictSendingNTLMTraffic=1 (audit), AuditReceivingNTLMTraffic=2; Netlogon AuditNTLMInDomain=7 (DC) Full
Execution Process Creation (HV) Security; WMI-Activity/Operational; Bits-Client/Operational; AppLocker x4; Diagnosis-Scripted/Operational ProcessCreationIncludeCmdLine_Enabled=1 (HV) Full via 4688+cmdline; no file hashes or DLL loads natively (accepted gap)
Account and access change User Account Management; Security Group Management; Other Account Management; Computer Account Management (DC); Distribution Group Management (DC); Authentication Policy Change Security - Full
Privilege use Special Logon (4672); Sensitive Privilege Use (HV) Security - Full
Logging tampered with Audit Policy Change (4719); Security State Change; System Integrity; Other System Events (failure) Security (1100/1102/1104 default); System (104); Defender/Operational (tamper) - Full
Software and service install Security System Extension (4697) System (7045); Application (MsiInstaller); CodeIntegrity/Operational; PrintService Admin + Operational - Full
Remote access Logon (types 3/10); Other Logon/Logoff (4778/4779); RPC Events TerminalServices-LocalSessionManager/Operational; SmbClient/Security - Full
Scheduled and automated tasks Other Object Access (4698-4702) TaskScheduler/Operational; WMI-Activity/Operational - Full
Scripting and command line Process Creation (HV) PowerShell/Operational (4103/4104); Windows PowerShell; PowerShellCore/Operational; Diagnosis-Scripted Script block + module logging (HV); cmdline (HV) Full for Windows PowerShell and PowerShell 7 (PowerShell 7 follows the Windows PowerShell policy); other interpreters visible only via 4688 command lines
Persistence Security System Extension; Other Object Access; Directory Service Changes (DC) System (7045); TaskScheduler/Operational; WMI-Activity/Operational; Bits-Client/Operational - Partial: registry autoruns (Run keys, IFEO) need the Registry subcategory + per-key SACLs, not in this baseline
Removable and external devices Plug and Play (6416); Removable Storage (4663) Security; DriverFrameworks-UserMode/Operational - Full
Blocked and denied activity Account Lockout; Filtering Platform Connection blocks (HV) Security; Defender/Operational; AppLocker x4; CodeIntegrity; Security-Mitigations x2; Firewall - Full (AppLocker channels populate only if AppLocker policy deployed)
Directory and identity store Directory Service Access (DC); Directory Service Changes (DC); SAM; Kerberos Authentication Service (DC) Security - Full on DCs; standalone = local SAM only (by design)
File and object access File Share (5140/5142-5144); Removable Storage Security - Partial: per-file auditing (4663) needs File System subcategory + SACLs on chosen paths, a per-asset design decision, deliberately not blanket-enabled
Certificates and keys Certification Services (4898/4899); Other Policy Change (CNG) Security; Crypto-DPAPI/Debug (HV) AD CS AuditFilter=127 (only when AD CS installed; CertSvc restart) Full where AD CS present; limited elsewhere (accepted)
Network flow and sessions Filtering Platform Connection 5156/5157 (HV); RPC Events Firewall channel; SmbClient/Security - Partial: no byte counts / flow aggregation natively; true flow telemetry needs network-layer sources, outside host scope

The partial rows are the recognised gaps of agentless native logging (registry autoruns, per-file SACLs, flow statistics, execution depth beyond 4688 command lines) - do not expect a native setting to close them; see Safety - known limits.

How the native mapping works

Two data files in data/attack/ (provenance and attribution in its README):

  1. windows_analytics.csv - derived from MITRE ATT&CK Enterprise v19.2's own detection model (snapshot 2026-08-31): detection strategies link techniques to per-platform analytics, and Windows analytics name their log sources literally (WinEventLog:Security, EventCode=4688, ...). Flattened, that gives technique -> log source -> event codes, straight from MITRE's current data.
  2. event_map.csv - the kit-curated join: each log source / event code mapped to the settings-table item that produces it (audit subcategory GUID, channel, and any registry prerequisite such as script block logging), one sourced row per claim.
.\tools\Export-AttackCoverage.ps1                                        # Core tier
.\tools\Export-AttackCoverage.ps1 -IncludeHighVolume
.\tools\Export-AttackCoverage.ps1 -BaselineFile .\presets\Workstation.csv

Every technique verdict carries a reason:

Status Meaning
Observable an enabling item is selected - the mapped events can be produced
NotSelected the kit has the item, but this selection excludes it
NotInKit needs a subcategory the kit deliberately excludes (SACL-dependent Registry/File System, DS Replication, ...)
RequiresSysmon only Sysmon telemetry maps to it - out of kit scope by design
NotNative needs ETW tracing, EDR, network sensors or cloud logs
Unmapped ATT&CK names a source the curated map doesn't cover yet - the visible curation worklist

Reference numbers (ATT&CK v19.2: 472 Windows techniques with analytics)

Regenerated 2026-09-24 with the curated event map (no Unmapped sources left). An important context number first: MITRE's current analytics catalogue is Sysmon-first - by the report's own classification 148 of the 472 techniques are Sysmon-only and another 26 need ETW, EDR, network, cloud or application telemetry, so the ceiling for any native host-logging configuration is 298 techniques. Against that ceiling:

Selection Observable Of the native ceiling (298)
Core tier 169 57%
Core + HighVolume 283 95%
Workstation preset 269 90%
DomainController preset 277 93%
MemberServer preset 267 90%
Microsoft client recommendation (reference, not shipped) 166 56%

Read that middle row carefully: with the HighVolume tier on, the kit reaches 283 of the 298 natively-reachable techniques - the 15 missed need subcategories the kit deliberately excludes (SACL-dependent Registry and File System auditing, DS Replication, ...). The Core -> HighVolume jump (114 techniques) is the quantified case for that tier's volume cost; the per-setting breakdown is in the detail CSV's ProvidedBy column.

Outputs

  • Results\AttackCoverage_Detail_*.csv - every analytic mapping row with status, which kit item provides it, and any of its event codes the map doesn't cover yet (UnmappedCodes, empty when curation is complete)
  • Results\AttackCoverage_Gaps_*.csv - techniques not observable, with the dominant reason

Caveats

  • This maps events, not detections: "observable" means the raw events exist; detection still needs rules (Sigma, SIEM analytics).
  • A technique counts as observable when at least one of its ATT&CK analytics has at least one producible log source - the optimistic reading; analytics often correlate multiple sources for fidelity.
  • PowerShell 4103/4104 rows enforce their registry prerequisites (module / script block logging policies, per Microsoft's PowerShell logging documentation).
  • Snapshots are point-in-time; refresh procedure in data/attack/README.md.