Skip to main content

Enforcing Windows Logging Audit Policies (AD and local GPO)

Nate OBrien
  • Updated

Establishing a Secure Logging Baseline

The Huntress Agent attempts to automatically apply settings on all supported endpoints, to establish a secure logging baseline. This ensures that SIEM is collecting all the Windows event log data essential to security and investigations. Where automation is limited (i.e. competing GPO or policy), you will need to manually configure settings.

 

Table of Contents

 

 

Advanced Audit Policy Settings

The Huntress Agent attempts to automatically apply Advanced Audit Policy settings on all supported endpoints, to establish a secure logging baseline. Any existing policies will override these Huntress-applied settings, in these cases manual action may be required by you.

Endpoints with overridden settings will display on the Misconfigured Policies tab (in your Huntress portal go to SIEM button on far left > Source Management > Categories > Windows Event Logs > Misconfigured Policies [will only appear if misconfigured policies are detected]). To prevent gaps in security data, these existing policies will need to be updated to match the Recommended Advanced Audit Policy settings.

To configure settings, you will need to determine how your endpoints are managed:

Active Directory Group Policy Managed

Group Policy provides a centralized way to push configuration to all servers and workstations within a domain. Use this method to apply a common Advanced Audit Policy configuration and other recommended baseline settings.

Apply Settings:

  1. Find your existing GPO and configure the Advanced Audit Policy section in your AD with the Huntress settings in this reference table.
  2. Apply the GPO at the top level of the domain to target all computers and users as needed.

The setting for “Audit the access of global system objects” should be disabled to prevent excessive event generation for Kernel access events. This setting can be found in:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.

 

Locally Managed (Non-Domain Joined)

If your endpoints are not domain-joined and you have been notified of misconfiguration, you likely have an existing Local Group Policy.

  • Check your local group policy for configurations via Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration. If you wish to continue using this method of editing local policy, move to "Using Local Group Policy Editor" below. 
  • If you don't see any configuration in there or don't want to use this editor, move to the "Using auditpol" section below.

Using Local Group Policy Editor

If you wish to maintain using the Local Group Policy Editor, update the missing configurations according to our security standards listed in Recommended Advanced Audit Policy Settings. Once complete, move to the "Verifying Policy" section below.

Using auditpol

If you no longer wish to maintain the Local Group Policy Editor, these settings can be more easily maintained via auditpol.

  • Before applying, you will need to manually reset the audit.csv files generated by the Local Group Policy Editor, otherwise auditpol settings will be overridden. These files are located at:
    c:\Windows\security\audit\audit.csv 
    c:\Windows\System32\GroupPolicy\Machine\Microsoft\WindowsNT\Audit\audit.csv
  • Before renaming or removing these files, validate there are no additional settings within the files which need to be maintained. Once these files are no longer applied, run the following 3 commands as an administrator:
auditpol /set /subcategory:"Credential Validation","Kerberos Authentication Service","Kerberos Service Ticket Operations","Computer Account Management","Distribution Group Management","Security Group Management","User Account Management","Directory Service Access","Logon","Network Policy Server","Other Logon/Logoff Events","Detailed File Share","File Share","Kernel Object","Other Object Access Events","Removable Storage","MPSSVC Rule-Level Policy Change","Other Policy Change Events","Sensitive Privilege Use","Other System Events","System Integrity" /success:enable /failure:enable
auditpol /set /subcategory:"Other Account Management Events","Plug and Play Events","Directory Service Changes","Logoff","Special Logon","Audit Policy Change","Authentication Policy Change","Authorization Policy Change","Filtering Platform Policy Change","Security State Change","Security System Extension" /success:enable
auditpol /set /subcategory:"Account Lockout","Filtering Platform Connection" /failure:enable
  • Once complete, move to the "Verifying Policy" section below.

 

Verifying Policy

Use the following commands to verify that the Advanced Audit Policy has been applied correctly and that the Security log is active with the appropriate settings.

Verify Audit Policy Settings (CMD):

auditpol /get /category:*

Verify Event Log Status (CMD):

Get-EventLog -List

 

 

Recommended Baseline Hardening

Huntress does not currently make changes to Security log size/retention or PowerShell ModuleLogging/ScriptBlockLogging settings. You must apply these via GPO or local configuration.

Security Log Size and Retention

You must define the Windows Security Event Log settings. Huntress does not set or enforce the Security log maximum size (512000 KB) or retention mode. The following are recommended baseline values. Apply these via GPO or local configuration.



PowerShell Logging

Huntress does not set or enforce PowerShell ModuleLogging or ScriptBlockLogging registry keys. If you require these for compliance or investigative visibility, enable them via GPO or configuration management tooling.

  HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\
  ModuleLogging → EnableModuleLogging = 1
  ModuleLogging\ModuleNames → * = *
  ScriptBlockLogging → EnableScriptBlockLogging = 1

Security Log Size (PowerShell):

Limit-EventLog -LogName Security -MaximumSize 512000KB -OverflowAction OverwriteAsNeeded

 

 

 

Common Issues

  • “I’m not sure what’s overriding the default audit policy settings”

See Finding the Source of Windows Logging Audit Policy Configuration.

 

  • “I updated and applied the recommended settings via auditpol, but my policies reverted”

Even when Domain and Local Group policy settings are no longer applied, they can leave remnant audit.csv on the machine.

For Local Group Policies, these are:

c:\Windows\security\audit\audit.csv

c:\Windows\System32\GroupPolicy\Machine\Microsoft\WindowsNT\Audit\audit.csv

For Domain Policies, these audit policies should be stored under the SYSVOL in the domain controller.

Before modifying the file, ensure the file is empty except for an audit policy file header, as to not overwrite or exclude additional settings. You can rename the file, then reapply the recommended settings using commands OR manually update settings via the Advanced Audit Policy editor to match the Recommended Advanced Audit Policy settings below.

 

 

How These Logs Empower Our SOC

Huntress Managed SIEM relies on Windows Advanced Audit Policy to see the right security events without flooding you with low-value noise. The settings you listed are our recommended baseline; together they give us the visibility we need for detections and investigations while keeping log volume manageable.

At a high level, each category serves a specific purpose:

  • Account Logon (Credential Validation, Kerberos) – Shows who is authenticating, how, and from where (including Kerberos tickets). This is critical for spotting suspicious logons, password-spray/brute-force activity, and lateral movement in Active Directory.
  • Account Management (User/Group/Computer changes) – Records when users, computers, and groups are created, disabled, or modified, and when group membership changes. These events are key for detecting rogue accounts, privilege escalation, and “who changed what, when.”
  • Detailed Tracking (Audit) - Configured to capture only high-value events (like USB/device activity) while relying on Huntress EDR for detailed process telemetry, avoiding noisy, low-value logs and keeping Windows Security logging focused on meaningful security signals.
  • Directory Service (on DCs) – Captures access to and changes within Active Directory itself, so we can see configuration changes and potential abuse of directory objects on domain controllers.
  • Logon/Logoff (including Network Policy Server, Special Logon) – Provides a complete picture of interactive, RDP, VPN, and service logons/logoffs, including privileged logons. This underpins most identity-focused detections and incident timelines.
  • Object Access (File Share, Detailed File Share, Removable Storage, Kernel/Other Object Access) – Shows who is accessing file shares and removable media, and certain sensitive OS objects. These events are important for identifying data exfiltration, ransomware staging, and low-level tampering.
  • Policy Change (Audit/Authentication/Authorization/Firewall policy) – Tracks changes to audit settings, authentication/authorization rules, and firewall policies. Attackers often modify these to hide activity or open new paths; these events let us see that control-plane tampering.
  • Privilege Use (Sensitive Privilege Use) – Records use of powerful rights like debug, backup/restore, or “Act as part of the OS,” which are frequently abused in serious compromises (credential dumping, offline data theft, etc.).
  • System (Security State/Integrity/System Events) – Monitors the health and integrity of the Windows security subsystem itself, helping us spot attempts to disable or subvert core protections.

 

Related articles