Detecting Tampering of Windows Security Audit Policy

Recently, I finished reading a book I strongly recommend to anyone working in Threat Hunting, BTFM (Blue Team Field Manual).

Among the different topics mentioned on it, I want to talk about the auditpol.exe which is a built-in Windows command-line utility used to view and configure the Windows security auditing policy. It controls what types of security-relevant actions (logon events, privilege use, object access, policy changes, etc.) are recorded in the Windows Security event log.

Why attackers can use Auditpol maliciously

The mentioned built-in Windows LOLBIN is used to control what Windows will or will not log so the attackers can abuse it to blind security monitoring and destroy forensic visibility before or during an intrusion. Typical malicious objectives can be:

1. Disable evidence collection Turn off key audit categories so that future actions (privilege abuse, lateral movement, backdoor installation) are never logged.
2. Stealth — disable only what matters Instead of turning off all auditing (which is suspicious), they selectively disable only what defenders need — e.g. process creation or logon — while leaving others on, to look “normal”.
3. Hide privilege escalation & persistence Disable auditing before adding admin users or modifying security settings — no log = no trace.
4. Anti-forensics They run auditpol before wiping logs or exfiltration, so there is no timeline reconstruction later.

Therefore, monitoring the execution of auditpol.exe can be crutial to detect first-stage of a real attack because they will be shown as previous steps to obfuscate the next execution such a ransomware.

AuditPol command cases

Auditpol can be executed to modify, remove and create different actions with windows security policies. To summarise, some of the common options are:

1️⃣ Disable object access auditing

Primary malicious use: blind monitoring of file/object access, hide exfiltration or data theft. Example: auditpol /set /category:"Logon" /success:disable /failure:disable

2️⃣ Clear all local audit policy settings

High-risk malicious action: completely disable auditing locally, enabling anti-forensics. Example: auditpol /clear /y

3️⃣ List available categories/subcategories (info)

Reconnaissance to find targets for disabling. Example : auditpol /list /categoryauditpol /list /subcategory

4️⃣ Restore audit policy from backup (local)

Overwrite local audit policy to a previous (weakened) state—used to re-disable logging after temporary changes or to apply a malicious template. Example : auditpol /restore /file:C:\auditpolicy_backup.csv

5️⃣ Export current audit policy to a file.

Attacker exfiltrates policy to learn detection coverage or to reuse/modify later via backup. Example: auditpol /backup /file:C:\auditpolicy_backup.csv

The AuditPol Detection

There are different tables on DefenderXDR/Sentinel that show information about the execution of Auditpol.exe. From my point of view, the execution of this command, should not be something normal in an environment further than the cases where is executed via SYSTEM (for internal telemetry or security tools) which can be identified executing this KQL Query:

DeviceProcessEvents
| where Timestamp < ago(1d) and InitiatingProcessAccountName has "system" and FileName has "auditpol.exe"
| summarize by DeviceName,AccountDomain,AccountName, ProcessCommandLine        

Therefore, my suggestion based on the cases mentioned previously (AuditPol command cases) is to monitor any kind of execution related to the mentioned command by other users than the SYSTEM. It can via process:

DeviceProcessEvents
| where AccountName !has "system" and FileName has "auditpol.exe"
| summarize by Timestamp,DeviceName,DeviceId,FileName,AccountDomain,InitiatingProcessAccountName,AccountName, ProcessCommandLine, ReportId        

or via DeviceRegistryEvents once a policy has been modified:

DeviceRegistryEvents
| where RegistryValueData startswith "auditpol"        

Conclusion

Auditpol is trusted, native, invisible by design, and capable of shutting off your eyes before an attack even starts. That makes it an excellent early-stage detection signal. In most environments, any execution of auditpol by a user other than SYSTEM should be treated as suspicious, investigated, and monitored in real time to prevent the attacker’s next move from going unseen.