Audit Policy¶

Audit policy decides what gets written to the Security log. Windows has two systems: an old one with nine broad categories, and a newer one with about sixty subcategories. Use the newer one. It records what's useful without flooding the log.

Where it is¶

secpol.msc → Advanced Audit Policy Configuration → System Audit Policies. Ten categories, each with subcategories.

Don't audit everything. Object Access on every file fills the disk and buries real events. The subcategories below are the ones that record attacks on accounts and privileges.

What to turn on and why¶

Each subcategory can record Success, Failure, or both. Failure shows attempts; Success shows what actually happened. This is the full Level 1 list, grouped by category. "Include" means at least that; both is fine.

Account Logon and Account Management¶

CIS	Subcategory	Set to	Records
17.1.1	Credential Validation	Success and Failure	Every password check. Failures in a row from one source is a password attack.
17.2.1	Application Group Management	Success and Failure	Rarely used; cheap to log
17.2.2	Security Group Management	include Success	Someone added to Administrators is here
17.2.3	User Account Management	Success and Failure	Users created, deleted, enabled, disabled, password reset

Detailed Tracking¶

CIS	Subcategory	Set to	Records
17.3.1	PNP Activity	include Success	Devices plugged in (USB drives)
17.3.2	Process Creation	include Success	Every program that starts, event 4688. With command-line logging (below), this is the single most useful forensic record on the machine.

Logon/Logoff¶

CIS	Subcategory	Set to	Records
17.5.1	Account Lockout	include Failure	Lockouts, which show a password attack in progress
17.5.2	Group Membership	include Success	What groups a user was in at logon
17.5.3	Logoff	include Success	A logon with no logoff is still active
17.5.4	Logon	Success and Failure	Who is here and how they arrived
17.5.5	Other Logon/Logoff Events	Success and Failure	RDP reconnects, screen lock and unlock
17.5.6	Special Logon	include Success	An administrator logged in (4672)

Object Access¶

CIS	Subcategory	Set to	Records
17.6.1	Detailed File Share	include Failure	Denied access to shared files
17.6.2	File Share	Success and Failure	Share connections
17.6.3	Other Object Access Events	Success and Failure	Scheduled task creation (4698), among others
17.6.4	Removable Storage	Success and Failure	Files read from or written to USB drives

STIG additions under Object Access¶

The STIG turns on three more Object Access subcategories that CIS leaves off. They're heavy (every file, registry key, and handle access on audited objects) but they're what make file-level auditing work when you set a SACL on a specific folder.

STIG	Subcategory	Set to
WN11-AU-000581, 000582	File System	Success and Failure
WN11-AU-000583, 000584	Handle Manipulation	Success and Failure
WN11-AU-000586, 000589	Registry	Success and Failure

Nothing is logged until an object has auditing entries in its Security → Advanced → Auditing tab, so turning these on doesn't flood the log by itself.

Policy Change¶

CIS	Subcategory	Set to	Records
17.7.1	Audit Policy Change	include Success	Changes to what gets audited. Attackers turn off auditing before acting.
17.7.2	Authentication Policy Change	include Success	Kerberos and trust changes
17.7.3	Authorization Policy Change	include Success	User rights granted or removed
17.7.4	MPSSVC Rule-Level Policy Change	Success and Failure	Firewall rules added or changed
17.7.5	Other Policy Change Events	include Failure

Privilege Use and System¶

CIS	Subcategory	Set to	Records
17.8.1	Sensitive Privilege Use	Success and Failure	Use of dangerous rights: debug, take ownership, load driver, act as OS
17.9.1	IPsec Driver	Success and Failure
17.9.2	Other System Events	Success and Failure	Firewall service start and stop, crypto errors
17.9.3	Security State Change	include Success	Startup and shutdown
17.9.4	Security System Extension	include Success	A new authentication package or service was loaded into the security system
17.9.5	System Integrity	Success and Failure	Log tampering, code integrity failures

Command line in process creation events¶

Process Creation on its own records that powershell.exe started. With this setting it records what was passed to it. gpedit.msc → Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events (18.9.3.1): Enabled.

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Set it with auditpol¶

Faster than clicking through sixty dialogs, and the shape is always the same:

auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable

/subcategory: takes the exact name from the table above, and /success:enable and /failure:enable are each optional, matching the Success / Failure / Success and Failure column. Work down the table and write one line for each row. When you've done a few, read them back:

auditpol /get /category:"Account Logon"

Category/Subcategory                      Setting
Account Logon
  Credential Validation                   Success and Failure
  Kerberos Service Ticket Operations      No Auditing

Sixty lines is a lot to type twice. Type them once into a text file named audit.bat, run it, and you have a tool you understand and can carry to the next image; that's the point of a script. Keep it, and the next time the table changes you edit one line.

On a domain controller, add Kerberos Authentication Service, Kerberos Service Ticket Operations, and Computer Account Management, all Success and Failure.

Set it in the GUI¶

secpol.msc → Advanced Audit Policy Configuration → System Audit Policies → open a category → double-click the subcategory → tick Configure the following audit events → tick Success and Failure → OK.

Make sure it applies¶

secpol.msc → Local Policies → Security Options → Audit: Force audit policy subcategory settings to override audit policy category settings: Enabled. Without this, the old category settings can override the new ones.

Verify¶

auditpol /get /category:*

Every subcategory in the tables should show at least what its row says.

Example¶

auditpol /get /category:* shows No Auditing for everything. The Security log has been empty since the image was built. Run the auditpol /set block, log out and back in, and the Security log starts filling with 4624 and 4634 events.

Try it¶

Set five subcategories with auditpol by hand, then read them back with auditpol /get /category:*.
Log in wrong on purpose and find the 4625 event.

Build it¶

Your audit.bat with one auditpol /set line per table row, and auditpol /get /category:* at the end. This is the page where the script is the natural outcome.

Next¶

Reading the Security Log