WinLogKit turns on the native Windows event logging that security monitoring needs, proves it is recording, and can undo it, on Windows servers and endpoints, from one sourced settings table. Plain PowerShell (7 or the built-in 5.1), no modules, no agents, no downloads.
The settings come from the Yamato Security logging guides and Microsoft's documentation, with every setting's purpose, volume risk and source recorded in one table. The ASD reference preset is taken from Yamato's EventLog-Baseline-Guide scripts. Targets Windows Server 2019 / 2022 / 2025 and Windows 10 / 11, standalone or domain-joined; version- and role-specific items are detected at runtime and reported NOT APPLICABLE where they do not apply.
- Enable event channels, advanced audit policy subcategories and
registry settings from one settings table. Idempotent,
-WhatIfdiff,-Rollbackto first-run state. - Verify the live state per behaviour category (PASS / FAIL / NOT APPLICABLE) with evidence CSVs.
- Deploy at fleet scale through the Intune Settings catalog or Group Policy, both mapped setting by setting from the same table, plus a generated GPO pack, so deployed config matches the tested baseline.
- Collect centrally: a Windows Event Forwarding subscription generated from the same selection, forwarding the selected channels whole. The kit ends at the collector's ForwardedEvents log; any SIEM picks up from there.
From an elevated PowerShell prompt in the kit folder, pick the preset for
the host's role: Workstation (Windows 10/11), MemberServer or
DomainController. Test on a non-production machine that mirrors your
environment for at least a week before rolling out: logging volume is real
disk and real money. -WhatIf also tells you whether the logs will fit on
the disk once full.
$preset = '.\presets\Workstation.csv'
.\Enable-LoggingBaseline.ps1 -BaselineFile $preset -WhatIf # 1. full diff, nothing changes
.\Enable-LoggingBaseline.ps1 -BaselineFile $preset # 2. apply (first run captures rollback state)
.\Test-LoggingBaseline.ps1 -BaselineFile $preset # 3. verify
.\Enable-LoggingBaseline.ps1 -Rollback # undo everything captured at step 2Want your own selection? Copy a preset and flip Selected in Excel, or run
.\New-LoggingBaseline.ps1, which walks every setting and writes a CSV that
Enable, Test and every fleet generator accept through -BaselineFile.
The three host scripts are at the kit root; fleet generators (GPO,
WEF) are in fleet\; tools\ holds maintainer scripts.
To keep the kit small and safe to run on any host, it deliberately doesn't:
- write files outside the event log (for example PowerShell transcripts)
- install agents, services, scheduled tasks or third-party binaries, or download anything
- filter events at the source, or ship SIEM content (parsers, queries, detections); the kit ends at the collector
- touch the never-do list
The reasoning is in
ADR-002.
If scripts are blocked, Set-ExecutionPolicy -Scope Process RemoteSigned
unblocks the current window without persisting anything; downloaded zips
also need Unblock-File, and a policy enforced by Group Policy cannot be
overridden locally (signing or a policy change is needed). Details in
Getting Started.
Full documentation: https://spydisec.github.io/WinLogKit/
| Page | Covers |
|---|---|
| Get started | Install, first run with a role preset, execution policy |
| Baselines | The presets, the two tiers, building your own, deviations from the sources |
| Deploy | Rolling out with the Intune Settings catalog or Group Policy, with every setting mapped |
| Collect | Central collection with Windows Event Forwarding |
| Reference | Commands, every setting, ATT&CK coverage |
| Safety & FAQ | What the kit never does, volume impact, known limits |
| Credits | The projects WinLogKit is built from, and their licences |
The kit never touches the settings that can hang or lock out a host
(CrashOnAuditFail, "do not overwrite" retention, global object access
auditing, blanket SACLs) and never reboots, restarts services or shrinks
logs. Heavy settings carry a risk note the builder shows before you select
them.
It's a starting point: fit it to your own infrastructure (selection, pilot, SIEM cost, Group Policy, change process) before rolling out, using the checklist in Safety & FAQ. Provided as is, without warranty; use at your own risk.
Issues and PRs welcome, field reports on real event volumes per setting especially. See CONTRIBUTING.md for how changes land, SECURITY.md for reporting vulnerabilities, and CHANGELOG.md for what changed. Planned work is tracked in issues.
WinLogKit's own scripts and documentation are licensed under the MIT License.
The kit is built from other people's published work, each under its own licence:
| Source | What WinLogKit uses | Licence |
|---|---|---|
| Yamato Security: EnableWindowsLogSettings | Setting values: which event channels to enable and their sizes, which audit subcategories to turn on, the PowerShell logging policies. The kit's descriptions are its own wording. | GPL-3.0 |
| Yamato Security: WELA | Setting values (NTLM and AD CS auditing), and the docs stylesheet, adapted with WELA's MIT notice kept in docs/stylesheets/extra.css. |
MIT |
| Yamato Security: EventLog-Baseline-Guide | The ASD, Microsoft client and Microsoft server baseline definitions (the ASD preset and the Reference page's Refs column). |
MIT |
| MITRE ATT&CK | Technique data in data/attack/, used per the ATT&CK Terms of Use. |
ATT&CK Terms of Use |
If you redistribute WinLogKit or build on it, check those licences yourself. The full list, including the tools the docs point to, is on the Credits page, and the kit's deliberate deviations from the Yamato sources are documented with reasons. WinLogKit is not affiliated with or endorsed by Yamato Security, the ASD, Microsoft or MITRE.