Advanced Windows Auditing Configuration Guide for Effective Incident Response in SOC Environments

When beginning work in a SOC (Security Operations Center), it quickly becomes clear that default Windows logging provides limited visibility into system activities. Events such as logons, process creation, and policy changes are either not recorded or appear in a heavily truncated form.

The service responsible for managing auditing is LSASS (Local Security Authority Subsystem Service), which runs at startup and resides in memory to handle user sessions, authentication requests, and protection of sensitive data. LSASS writes audit information to the Security event log according to configured policies.

Windows offers two auditing levels: basic auditing with nine categories configured via secpol.msc and advanced auditing with 53 subcategories managed through the auditpol utility. The article focuses on advanced auditing because it allows precise control, for example enabling only Logon and Special Logon without cluttering logs with irrelevant Kerberos or IPsec events on standalone machines.

Key Subcategories and Corresponding Event IDs

The most important subcategories for incident response include:

• Logon – successful logons (Event ID 4624)
• Logoff – session termination (Event IDs 4634, 4647)
• Account Lockout – lockout events (Event ID 4740)
• Special Logon – privilege escalation via runas (Event ID 4648)
• User Account Management – account creation and deletion (Event IDs 4720, 4726)
• Security Group Management – group membership changes (Event IDs 4732, 4728)
• Process Creation – executable launches (Event ID 4688)
• Audit Policy Change – modifications to auditing itself (Event ID 4719)
• Other System Events – log clearing (Event ID 1102)

Each subcategory has a fixed GUID that can be used with auditpol when localized names cause issues.

Enabling Advanced Auditing and Additional Logging

After opening an elevated command prompt on a clean Windows 10 Pro 22H2 virtual machine running under VMware Workstation 17 Pro, the author enables a baseline set of subcategories using multiple auditpol commands. Verification is performed with auditpol /get /category:* to confirm success and failure auditing is active for each item.

PowerShell logging is enabled via registry modification under HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging, activating Script Block Logging that records decoded script content in the Microsoft-Windows-PowerShell/Operational log (Event IDs 4104 and 4103).

Command-line auditing for process creation events is activated by setting the registry value ProcessCreationIncludeCmdLine_Enabled under HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit, ensuring the Command Line field in Event ID 4688 is populated.

Practical Testing of Configured Auditing

Five hands-on tests illustrate the value of the configuration. A successful interactive logon produces Event ID 4624 showing Logon Type 2, account name, workstation name, and the responsible process. Failed logon attempts generate Event ID 4625 with failure reason codes such as 0xC000006A for incorrect password.

Process creation with arguments is demonstrated by running whoami /all, resulting in a detailed Event ID 4688 that includes Creator Process ID, New Process ID, and the full command line. Account creation and administrative group membership changes produce Events 4720 and 4732, revealing subject and target account details along with group names.

The article emphasizes performing all changes on virtual machines to prevent excessive log growth or interference with installed applications on production hosts.