Advanced Audit Policy

The host audit policy, stored as a binary blob you parse rather than read.

Use it to tell which security events the host was auditing, and spot auditing cut back.

SECURITY
Defence Evasion

What It Is

The audit policy tells Windows which security events to record in the Security log. It is split into categories, such as Logon/Logoff and Detailed Tracking, and each subcategory can record successes, failures or both. Administrators set it with Group Policy or the Local Security Policy console (secpol.msc). PolAdtEv, in the SECURITY hive, holds the audit policy in force, which lsass.exe, the Local Security Authority process, reads to decide what to audit.

What It Proves

PolAdtEv encodes the per-subcategory audit settings. Parsed, it shows which categories log Success and Failure. Subcategories set to No Auditing mean those events are not recorded.

What It Does Not Prove

The value is an opaque blob, so parse it rather than read it raw. A change here is also recorded as event 4719 in the Security log, which names the subcategory and who changed it.

Where It Lives

Advanced Audit Policy lives in the SECURITY hive, which holds settings for the whole machine. Offline Hive shows the path inside the hive file, as Registry Explorer opens it, and Live System shows the same key as regedit shows it on a running machine. The line under the path is where the hive file sits on disk.

SECURITY\Policy\PolAdtEv

C:\Windows\System32\config\SECURITY

What It Looks Like

These are two values from this key on ws-042, the fictional machine the wiki follows, decoded into plain English. Each row shows the value as Windows stores it, its name, type and data, then what it tells you.

Values in Advanced Audit Policy, each with what it tells you
Registry Value	What It Tells You
`Logon/Logoff: Logon (parsed)` `SubcategoryNo Auditing`	Logon auditing is off, so logons after the change leave no event 4624. Event 4719 dates it, and support's 12 Oct logon can be in the log only if it came first.
`Detailed Tracking: Process Creation (parsed)` `SubcategorySuccess and Failure`	Process creation is audited, so event 4688 is available in the Security log. Confirm the logs actually hold it for the period in question.

How to Read It

Read PolAdtEv under SECURITY\Policy. The SECURITY hive is readable only as SYSTEM on a live host. Parse it with auditpol or a RegRipper plugin into per-subcategory settings. To put it right, restore the required subcategories by policy and confirm with event 4719 in the Security log.

When Windows Writes It: It is written when Group Policy or an administrator changes the audit policy. The change also raises event 4719.
Which Windows Versions: Windows Vista to 11
Tools That Parse It: auditpol.exe (live), RegRipper (auditpol), Registry Explorer

Hunt It

Sees Related ActivityDeviceEvents (AuditPolicyModification)

Records each change and the subcategory it touched, inside retention, not the stored policy. Collect the SECURITY hive to read PolAdtEv for the result.

KQLDefender XDR, Advanced hunting

// Audit policy changes recorded by DefenderDeviceEvents| where Timestamp > ago(30d)| where DeviceName startswith "ws-042"| where ActionType == "AuditPolicyModification"| extend Fields = parse_json(AdditionalFields)| project Timestamp, AccountName, AuditPolicyChanges = tostring(Fields.AuditPolicyChanges), SubcategoryGuid = tostring(Fields.SubcategoryGuid)| order by Timestamp desc

Confirm It With

One artefact can mislead on its own. These other records show the same activity, or pin down when it happened, so use them to back up what Advanced Audit Policy shows.

Event Log SettingsTells events never recorded from a log that was shrunk or switched off.
Audit Policy Changed, Security Event 4719Not in the RegistryNames the subcategory changed, who changed it and when.
Logs Cleared, Security Event 1102Not in the RegistryTells events never recorded from a cleared log, and names who cleared it.

Sources

The facts on this page come from these public pages, which say more on each point.