ANAVEM
Languagefr
Windows security monitoring dashboard showing Event Viewer with audit policy configuration logs
Event ID 4612InformationMicrosoft-Windows-Security-AuditingWindows

Windows Event ID 4612 – LSA: Security Audit Policy Changes

Event ID 4612 fires when Local Security Authority (LSA) audit policy settings are modified, indicating changes to Windows security auditing configuration that affect what events get logged.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 20269 min read 0
Event ID 4612Microsoft-Windows-Security-Auditing 5 methods 9 min
Event Reference

What This Event Means

Event ID 4612 represents a fundamental security auditing event that documents changes to the Windows audit policy configuration managed by the Local Security Authority. The LSA is responsible for enforcing security policies on Windows systems, including determining which types of security events should be logged to the Security event log.

When this event fires, it indicates that the audit policy has been modified, either through administrative action or system processes. The event captures details about the specific audit categories that were changed, their previous settings, and their new configuration. This information is critical for maintaining security audit trail integrity and ensuring that your organization's logging requirements remain consistent.

The event typically occurs during system startup as the LSA loads audit policies from the registry, or when administrators use tools like Group Policy Management Console, Local Security Policy snap-in, or the auditpol.exe command-line utility to modify audit settings. In domain environments, Group Policy changes can trigger this event across multiple systems as policies are applied.

From a security perspective, Event ID 4612 serves as a safeguard against unauthorized modifications to audit configurations. Attackers who gain administrative access might attempt to disable auditing to cover their tracks, and this event provides visibility into such attempts. Security teams should monitor 4612 events to detect unexpected changes to audit policies that could indicate compromise or policy drift.

Applies to

Windows 10Windows 11Windows Server 2019/2022/2025
Analysis

Possible Causes

  • System startup loading audit policies from registry
  • Group Policy application modifying audit settings
  • Administrator using Local Security Policy to change audit configuration
  • Command-line execution of auditpol.exe with policy changes
  • PowerShell scripts modifying audit policies through Set-AuditPolicy cmdlets
  • Third-party security tools adjusting audit configurations
  • Windows Update or system patches affecting default audit settings
  • Domain controller policy replication triggering audit policy updates
Resolution Methods

Troubleshooting Steps

01

Review Event Details in Event Viewer

Start by examining the specific audit policy changes recorded in Event ID 4612:

  1. Open Event ViewerWindows LogsSecurity
  2. Filter for Event ID 4612 using the filter option
  3. Double-click the most recent 4612 event to view details
  4. In the General tab, review the event description and timestamp
  5. Switch to the Details tab and examine the XML data
  6. Look for the AuditPolicyChanges field showing which categories were modified
  7. Note the SubjectUserName and SubjectDomainName to identify who made the changes
  8. Check the ProcessName field to see which tool was used (auditpol.exe, Group Policy, etc.)

Use PowerShell to query multiple 4612 events efficiently:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4612} -MaxEvents 20 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
02

Analyze Current Audit Policy Configuration

Compare the current audit policy with expected settings to identify unauthorized changes:

  1. Open Command Prompt as Administrator
  2. Run the following command to display current audit policy:
auditpol /get /category:*
  1. Review each audit category and its current setting (Success, Failure, Success and Failure, or No Auditing)
  2. Compare against your organization's security baseline or compliance requirements
  3. For detailed subcategory information, use:
auditpol /get /subcategory:*
  1. Export current settings for documentation:
auditpol /backup /file:C:\temp\current_audit_policy.csv
  1. Use PowerShell to get audit policy in a more readable format:
Get-AuditPolicy | Format-Table Category, Subcategory, AuditFlag -AutoSize
03

Investigate Group Policy Audit Settings

Check if Group Policy changes caused the audit policy modifications:

  1. Open Group Policy Management Console (gpmc.msc)
  2. Navigate to the relevant GPO affecting the target system
  3. Edit the GPO and go to Computer ConfigurationPoliciesWindows SettingsSecurity SettingsAdvanced Audit Policy Configuration
  4. Review each audit policy category for recent changes
  5. Check the Security Options section for audit-related settings
  6. Use PowerShell to analyze Group Policy results:
Get-GPResultantSetOfPolicy -ReportType Html -Path C:\temp\gpresult.html
  1. Review the generated report for audit policy settings
  2. Check Group Policy event logs for policy application:
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1502,1503} -MaxEvents 10
  1. Verify when Group Policy was last applied:
gpresult /r /scope:computer
04

Monitor Registry Changes for Audit Policy

Examine registry locations where audit policy settings are stored:

  1. Open Registry Editor (regedit.exe) as Administrator
  2. Navigate to the primary audit policy location:
HKLM\SECURITY\Policy\PolAdtEv
Warning: The SECURITY hive requires special permissions to access. Use PsExec or take ownership carefully.
  1. Check the Group Policy audit policy location:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit
  1. Use PowerShell to monitor registry changes in real-time:
$action = { Write-Host "Registry change detected: $($Event.SourceEventArgs.FullPath)" }
Register-WmiEvent -Query "SELECT * FROM RegistryKeyChangeEvent WHERE Hive='HKEY_LOCAL_MACHINE' AND KeyPath='SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Audit'" -Action $action
  1. Check for recent registry modifications using Process Monitor (ProcMon):
  2. Set filters for Registry activity on audit-related keys
  3. Look for processes modifying audit policy registry values
05

Implement Audit Policy Change Monitoring

Set up comprehensive monitoring for future audit policy changes:

  1. Create a PowerShell script to monitor Event ID 4612:
# Save as Monitor-AuditPolicyChanges.ps1
$query = @"

  
    
  

"@

Register-WmiEvent -Query "SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA 'Win32_NTLogEvent' AND TargetInstance.EventCode = 4612" -Action {
    $event = $Event.SourceEventArgs.NewEvent.TargetInstance
    Write-Host "Audit Policy Change Detected at $($event.TimeGenerated)"
    Write-Host "User: $($event.User)"
    Write-Host "Message: $($event.Message)"
    # Add email notification or SIEM integration here
}
  1. Configure Windows Event Forwarding for centralized monitoring:
  2. On the collector server, create a custom view for Event ID 4612
  3. Set up SIEM integration to alert on audit policy changes
  4. Create a baseline audit policy configuration:
auditpol /backup /file:C:\baseline\baseline_audit_policy.csv
  1. Schedule regular compliance checks:
# Compare current policy with baseline
$baseline = Import-Csv C:\baseline\baseline_audit_policy.csv
$current = auditpol /get /subcategory:* /r /format:csv | ConvertFrom-Csv

$differences = Compare-Object $baseline $current -Property 'Subcategory Name','Inclusion Setting'
if ($differences) {
    Write-Warning "Audit policy drift detected!"
    $differences | Format-Table
}

Overview

Event ID 4612 generates when the Local Security Authority (LSA) audit policy undergoes configuration changes. This event fires during system startup when audit policies are loaded, or when administrators modify security auditing settings through Group Policy, Local Security Policy, or command-line tools like auditpol.exe. The LSA manages authentication and authorization on Windows systems, and its audit policy determines which security events get logged to the Security event log.

This event appears in the Security log and provides visibility into audit policy modifications that could affect your organization's security monitoring capabilities. When you see 4612, someone or something has changed what types of security events Windows will record. The event includes details about which audit categories were modified and their new settings.

Understanding 4612 is crucial for security administrators who need to track changes to audit configurations, ensure compliance with security policies, and investigate potential tampering with logging mechanisms. This event helps maintain audit trail integrity by documenting when audit settings themselves are altered.

Frequently Asked Questions

What does Event ID 4612 mean and why is it important?+
Event ID 4612 indicates that the Windows audit policy configuration has been modified. This event is crucial for security monitoring because it tracks changes to what types of security events get logged. When audit policies are altered, it could affect your ability to detect security incidents, maintain compliance, or investigate breaches. The event helps ensure audit trail integrity by documenting when logging configurations themselves are changed, which is essential for maintaining a robust security monitoring posture.
How can I tell who changed the audit policy when Event ID 4612 appears?+
Event ID 4612 includes several fields that identify the source of audit policy changes. Check the SubjectUserName and SubjectDomainName fields to see which user account made the change. The ProcessName field shows which tool was used (such as auditpol.exe, Group Policy, or PowerShell). The LogonId can help correlate with other logon events to understand the session context. If the change came from Group Policy, you'll typically see SYSTEM as the user, and you'll need to investigate Group Policy logs and management console audit trails to identify the administrator who modified the policy.
Is Event ID 4612 normal during system startup?+
Yes, Event ID 4612 commonly appears during system startup as the Local Security Authority loads audit policy settings from the registry. This is normal behavior and indicates that the system is initializing its security auditing configuration. However, you should still monitor these events to establish baseline patterns and detect unusual occurrences. If you see 4612 events outside of startup times or Group Policy application windows, investigate further as they might indicate unauthorized audit policy modifications or system configuration changes.
Can attackers disable auditing to avoid detection, and how does Event ID 4612 help?+
Yes, attackers with administrative privileges often attempt to disable auditing to cover their tracks and avoid detection. Event ID 4612 serves as a critical safeguard by logging when audit policies are modified, including attempts to disable auditing. Even if an attacker disables future auditing, the act of disabling it generates a 4612 event that gets logged before the policy takes effect. This is why security teams should monitor 4612 events closely and consider implementing additional protections like Windows Event Forwarding to ensure audit policy changes are captured in centralized logs that attackers cannot easily modify.
How do I restore audit policy settings after unauthorized changes detected by Event ID 4612?+
To restore audit policy settings, first identify what was changed by examining the Event ID 4612 details and comparing current settings with your baseline using 'auditpol /get /category:*'. If you have a backup of your audit policy, restore it using 'auditpol /restore /file:backup_file.csv'. For Group Policy-managed environments, verify the GPO settings and force a policy refresh with 'gpupdate /force'. You can also manually reconfigure specific categories using 'auditpol /set /category:"Category Name" /success:enable /failure:enable'. Always document the restoration process and consider implementing additional monitoring to prevent future unauthorized changes to audit configurations.
Documentation

References (2)

Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Senior IT Journalist & Cloud Architect

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...