Auditing the Windows Advanced Audit Policy: Is Your Machine Even Recording the Evidence?

Most Windows hardening advice is about preventing bad things: disable SMBv1, turn off WDigest, restrict RDP. Those matter. But there's a quieter failure mode that no amount of prevention fixes — the machine that gets compromised anyway and has nothing in its Security log to tell you how. You go to pull the 4625 failed-logon trail, or the 4688 process-creation history, or the 4720 "new account created" record, and it isn't there. Not deleted — never written, because the relevant audit subcategory was set to "No Auditing".

That's the gap WinSentinel's new Audit Policy module closes. It doesn't harden anything; it verifies that the machine is actually recording the evidence you'll want later.

Legacy audit categories vs. advanced audit policy

Windows has two overlapping auditing systems. The old one — the nine "basic" categories under Local Policies > Audit Policy — is coarse: "Audit account logon events" is a single on/off switch over a huge bucket. Since Windows Vista, the Advanced Audit Policy Configuration splits those nine into ~60 fine-grained subcategories, so you can log exactly the events that matter and skip the noise.

You can see the effective policy on any host with a single built-in command:

auditpol /get /category:*

Each subcategory reports one of four inclusion settings: No Auditing, Success, Failure, or Success and Failure. The trap is that the defaults are conservative — several of the most useful subcategories ship as No Auditing on a fresh install, and a "we're hardened" checklist that never touched auditpol leaves them that way.

The five subcategories WinSentinel insists on

The module reads the machine-readable report (auditpol /get /category:* /r) and checks the subcategories whose absence most directly blinds an investigation. Each maps to concrete event IDs and a concrete attack it lets you see.

1. Logon — Success and Failure

Records 4624 (successful logon) and 4625 (failed logon). Failure auditing is the entire foundation of brute-force and password-spray detection: no 4625s, no spray alert. This should always be Success and Failure.

2. Credential Validation — Success and Failure

Authentication at the authority (4776 for NTLM, 4768/4769 for Kerberos TGT/service tickets). This is where Kerberoasting and AS-REP roasting show up as anomalous service-ticket requests. Without it, offline credential abuse leaves no trace at the point of validation.

3. Process Creation — Success

Event 4688 — the record of every process that starts, with its parent. This is the backbone of process-lineage and living-off-the-land (LOLBin) detection: winword.exe spawning powershell.exe spawning cmd.exe is a story you can only tell if 4688 is being written. Pair it with the "Include command line in process creation events" policy for full value.

4. Audit Policy Change — Success and Failure

Event 4719 fires when the audit policy itself is modified. This is the anti-tamper check: an attacker who disables auditing to go dark should at least leave a record of having gone dark. If this subcategory is off, they can quietly turn everything else off too.

5. User Account Management — Success

Accounts and groups: 4720 (account created), 4728/4732 (added to a privileged group). This is the signal for local-admin sprawl and one of the most common persistence techniques — the attacker simply adds themselves an account. If it isn't audited, that account appears from nowhere.

Why "we turned auditing on" isn't the same as "auditing is on"

Audit policy is unusually prone to silent regression. A Group Policy refresh can overwrite locally-set advanced audit policy if the two mechanisms conflict (the classic "basic and advanced audit policy don't mix" footgun). An image built months ago predates your current baseline. A well-meaning admin flips a subcategory off to quiet log volume. In every case the machine looks configured and simply isn't — and you don't find out until the day you need the events.

That's exactly why this belongs in a scanner rather than a one-time checklist. WinSentinel re-reads auditpol on every scan and reports each subcategory as a plain pass or warning, so "we log the right events" becomes a fact you can re-verify on any machine, any day. A subcategory that auditpol doesn't even report is treated as a warning, never a silent pass — absence of evidence is not evidence of auditing.

Fixing a gap

Every warning comes with the exact auditpol command to close it. For example, to start recording process creation and account management:

auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /set /subcategory:"User Account Management" /success:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

For fleets, set these through Group Policy under Advanced Audit Policy Configuration so they survive reboots and reimaging — and make sure "Force audit policy subcategory settings to override audit policy category settings" is enabled so the advanced policy actually wins.

Run it

The Audit Policy module ships in the free, open-source WinSentinel CLI — like every single-machine audit, it's unlimited and local-only:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit

Look for the Audit Policy category in the report. It tells you, in one glance, whether the machine is even capable of producing the evidence the rest of your security program assumes it has.