Mitsuru, one of our support engineers in Japan, actually did some excellent research recently into exactly what our behavior is for auditing audit policy and I wanted to share that with you.
In Windows, we’ve always had auditing for changes to security policy. Audit policy has always been one aspect of that policy.
However, it’s not so clear how to audit changes to audit policy. The reason is, because the change itself might affect whether or not the audit is generated. Usually in Windows, we generate audit after the operation that we are auditing, is performed. When we generate audit, we always check audit policy to see if we need to generate an event.
So what would happen if you turned off the setting “audit changes to audit policy”? Well, if we implemented it in the way we generally implement audit policy, nothing would happen- no event. As described above, if we checked audit policy after we disabled audit policy, then the effective policy would say “don’t generate audit”.
But consider the case where a malicious audit or system administrator wants to cover their tracks. One thing such a person might do, to not leave as much of a trace, is to disable audit policy before they do the bad thing, and re-enable it afterwards. If we implemented audit normally, then there would be no trace of this.
To avoid this undesirable case, we changed around the instrumentation a little so that we always generate audit for certain audit policy change events. This means that you might not get EXACTLY what you intended, but it also ensures that you can always find the significant events when someone disables audit policy.
Anyway, to sum up, the following events are always audited when audit policy is disabled regardless of the “Audit Policy Change” subcategory setting in Windows Vista+:
4715 The audit policy (SACL) on an object was changed.
4719 System audit policy was changed.
4906 The CrashOnAuditFail value has changed.
4908 Special Groups Logon table modified.
4912 Per User Audit Policy was changed.
The following events are only audited when success auditing is enabled for the “Audit Policy Change” subcategory:
4902 The Per-user audit policy table was created.
4904 An attempt was made to register a security event source.
4905 An attempt was made to unregister a security event source.
4907 Auditing settings on object were changed.
Special thanks to Mitsuru for documenting this.