@lttrung97Blog
Thanh Trung Le

Windows Security Auditing

Thanh Trung Le
Thanh Trung Le · 22 min read

1. Conceptual Anchors

This section provides essential identifiers and definitions serving as context for the subsequent configuration and event data artifacts. Understanding these concepts is crucial for effective security monitoring.
Important Note: For Windows to generate security audit events, two primary steps are required:
  1. The relevant Audit Policy category or subcategory must be enabled (either Basic or Advanced). This tells the system *what types* of activities to monitor globally.
  2. For *object access* auditing (like files, registry keys), the specific object must have a System Access Control List (SACL) configured. This tells the system *which specific actions* (e.g., Read, Write) by *which specific users/groups* on *that specific object* should trigger an event, based on the enabled policy.

1.1. Basic Audit Policy Categories

Basic audit policies define broad categories of events to monitor. Enabling these categories forms the foundation of an audit policy. This is the older method of configuration. Advanced Audit Policy (see next section) provides significantly more granularity and is generally recommended for modern systems.1
Basic Audit Policy Categories and Their Purpose
Category
Primary Purpose
Audit account logon events
Audits attempts related to credential validation (e.g., Kerberos, NTLM) typically on domain controllers or local SAM.1
Audit account management
Audits creation, deletion, or modification of user accounts or groups.1
Audit directory service access
Audits access attempts to Active Directory Domain Services objects on domain controllers.1
Audit logon events
Audits attempts to log on or log off interactively or over the network at the machine where the event occurs.1
Audit object access
Audits access attempts to objects like files, folders, registry keys, or printers. Requires SACLs on objects.
Audit policy change
Audits changes to user rights assignment policies, audit policies, or trust policies.1
Audit privilege use
Audits the exercise of user rights (privileges), excluding logon/logoff rights.1
Audit process tracking
Audits detailed process tracking information such as process creation, termination, and handle duplication.1
Audit system events
Audits system-level events like system startup, shutdown, and events affecting system security or the security log.1

1.2. Advanced Audit Policy Configuration Categories and Subcategories

Advanced Audit Policies offer fine-grained control over audited events, allowing administrators to target specific activities and reduce event log noise compared to Basic policies. These settings are accessible via Local Security Policy (secpol.msc) or Group Policy. Using Advanced Audit Policy is the preferred modern approach.2
Advanced Audit Policy Categories and Example Subcategories
Category
Example Subcategories
Account Logon
Audit Credential Validation, Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Other Account Logon Events 2
Account Management
Audit Application Group Management, Audit Computer Account Management, Audit Distribution Group Management, Audit Other Account Management Events, Audit Security Group Management, Audit User Account Management 2
Detailed Tracking
Audit DPAPI Activity, Audit PNP activity (Win 10+), Audit Process Creation, Audit Process Termination, Audit RPC Events, Audit Token Right Adjusted (Win 10+) 2
DS Access
Audit Detailed Directory Service Replication, Audit Directory Service Access, Audit Directory Service Changes, Audit Directory Service Replication 2
Logon/Logoff
Audit Account Lockout, Audit IPsec Extended Mode, Audit IPsec Main Mode, Audit IPsec Quick Mode, Audit Logoff, Audit Logon, Audit Network Policy Server, Audit Other Logon/Logoff Events, Audit Special Logon, Audit User/Device Claims 2
Object Access
Audit Application Generated, Audit Certification Services, Audit Detailed File Share, Audit File Share, Audit File System, Audit Filtering Platform Connection, Audit Filtering Platform Packet Drop, Audit Handle Manipulation, Audit Kernel Object, Audit Other Object Access Events, Audit Registry, Audit Removable Storage, Audit SAM, Audit Central Access Policy Staging 2
Policy Change
Audit Audit Policy Change, Audit Authentication Policy Change, Audit Authorization Policy Change, Audit Filtering Platform Policy Change, Audit MPSSVC Rule-Level Policy Change, Audit Other Policy Change Events 2
Privilege Use
Audit Non Sensitive Privilege Use, Audit Sensitive Privilege Use, Audit Other Privilege Use Events 2
System
Audit IPsec Driver, Audit Other System Events, Audit Security State Change, Audit Security System Extension, Audit System Integrity 2
Global Object Access Auditing
File System (Global Object Access Auditing), Registry (Global Object Access Auditing) 2

1.3. Example SDDL Snippet: SYSTEM_AUDIT_ACE

A System Access Control List (SACL) contains Access Control Entries (ACEs) that specify which access attempts trigger security audits. The SYSTEM_AUDIT_ACE type is used for this purpose within the Security Descriptor Definition Language (SDDL) representation of a SACL. Remember, a SACL must be configured on the specific object (file, folder, registry key, etc.) you want to audit, in addition to enabling the relevant audit policy subcategory (like 'Audit File System' or 'Audit Registry').
Example 1: Audit successful File All Access for Everyone
S:(AU;SAFA;FA;;;WD)
  • S:: Denotes the SACL component of the SDDL string.
  • AU: ACE flag indicating an audit should be generated on successful access attempts. Use AL for failed attempts, or AU;AL for both.
  • SA: Specifies the ACE type as SYSTEM_AUDIT_ACE_TYPE.
  • FA: Represents the ACCESS_MASK bits being audited. FA corresponds to File All Access (0x1F01FF). Other common masks include WD (Write Data/Add File - 0x00000002), AD (Append Data/Add Subdirectory - 0x00000004), DE (Delete - 0x00010000), RC (Read Control - 0x00020000), FR (File Read Data - 0x00000001).
  • (empty): Object Type GUID (usually empty for file/registry ACEs).
  • (empty): Inherited Object Type GUID (usually empty for file/registry ACEs).
  • WD: Trustee SID. WD represents the well-known SID for Everyone (S-1-1-0). Replace with specific user or group SIDs (e.g., S-1-5-32-544 for BUILTIN\Administrators).
Example 2: Audit failed Read Data and Write Data attempts by a specific user
S:(AL;SA;FRFW;;;S-1-5-21-1234567890-123456789-1234567890-1001)
  • AL: ACE flag indicating audit on failure.
  • FRFW: Access mask combining FR (File Read Data - 0x1) and FW (File Write Data - 0x2). The combined mask is 0x3. (Note: FW isn't a standard simple mask; this example likely intends Write Data 'WD' - 0x2. Combining FR and WD would be FRWD, mask 0x3).
  • S-1-5-21-...-1001: Placeholder for a specific user's SID.

1.4. Common Audit Event IDs

Specific Event IDs in the Security log correspond to activities audited based on policy settings. Monitoring key IDs is essential for security analysis. The tables below list some common event IDs associated with the policy categories.
Common Windows Security Event IDs
Event ID
Category/Subcategory (Typical)
Description
Potential Criticality
Common/Minimal Set
1102
System / Audit Log Cleared
The Security audit log was cleared.
Medium to High
Minimal, Common
4624
Logon/Logoff / Logon
An account was successfully logged on.
N/A
Minimal, Common
4625
Logon/Logoff / Logon
An account failed to log on.
N/A
Minimal, Common
4634
Logon/Logoff / Logoff
An account was logged off.
N/A
Common
4656
Object Access / File System, Registry, etc.
A handle to an object was requested (often precedes access). Requires SACL.
N/A
N/A (Often enabled with 4663)
4657
Object Access / Registry
A registry value was modified. Requires SACL.
N/A
Minimal, Common
4663
Object Access / File System, Registry, etc.
An attempt was made to access an object. Requires SACL.
N/A
Minimal, Common
4688
Detailed Tracking / Process Creation
A new process has been created.
N/A
Minimal, Common
4689
Detailed Tracking / Process Termination
A process has exited.
N/A
Common
4719
Policy Change / Audit Policy Change
System audit policy was changed.
High
Minimal, Common
4720
Account Management / User Account Management
A user account was created.
N/A
Minimal, Common
4722
Account Management / User Account Management
A user account was enabled.
N/A
Minimal, Common
4723
Account Management / User Account Management
An attempt was made to change an account's password.
N/A
Minimal, Common
4724
Account Management / User Account Management
An attempt was made to reset an account's password.
Medium
Minimal, Common
4732
Account Management / Security Group Management
A member was added to a security-enabled local group.
N/A
Minimal, Common
4738
Account Management / User Account Management
A user account was changed.
N/A
N/A
4768
Account Logon / Kerberos Authentication Service
A Kerberos authentication ticket (TGT) was requested (DC event).
N/A
N/A
4769
Account Logon / Kerberos Service Ticket Operations
A Kerberos service ticket was requested (DC event).
N/A
N/A

2. Configuration Artifacts & Methods

This section provides concrete artifacts for configuring Windows Security Auditing using various methods.

2.1. Local Security Policy (.reg Snippets)

Registry files can directly configure *some* local audit policy settings, but this is often not the recommended method, especially for Advanced Audit Policy or Basic policy which uses opaque storage. Use tools like secpol.msc or auditpol.exe for local configuration.
Basic Audit Policy Example: Audit Logon Events (Success and Failure)
Windows Registry Editor Version 5.00

; This value is part of a binary structure managed by LSA.
; Direct modification is complex and not recommended. Use secpol.msc or GptTmpl.inf instead.
; Example below illustrates the CONCEPTUAL location but is NOT directly usable.
; AuditCategoryLogon = 3 (Success=1, Failure=2 -> Both=3)
; Note: The actual registry storage for basic policy in PolAdtEv is opaque.

; Configures: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\Audit logon events
; Setting this via secpol.msc (which modifies PolAdtEv) is the supported method for local basic policy.
Advanced Audit Policy Example: Audit File System (Success Only)
Windows Registry Editor Version 5.00

; Configures: Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies\Object Access\Audit File System
; Note: Advanced Audit Policy set locally via secpol.msc or auditpol.exe is not stored in simple, documented registry values.
; Use auditpol.exe or secpol.msc for local configuration. GPO settings are stored under HKLM\Software\Policies.
; The effective policy reflecting the merge of local and GPO settings is readable via 'auditpol /get'.
; Direct registry manipulation for local Advanced Audit Policy is NOT supported.
Enforce Advanced Audit Policy over Basic Policy
This setting, configurable via Registry or GPO, forces the system to use *only* Advanced Audit Policy settings if they are configured, ignoring legacy Basic Audit Policy settings.
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"SCENoApplyLegacyAuditPolicy"=dword:00000001

; Configures: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings
; Value = 1 enables enforcement (Advanced overrides Basic)
; Value = 0 disables enforcement (Basic settings may merge or conflict with Advanced)
Rationale: Setting SCENoApplyLegacyAuditPolicy to 1 is crucial when using Advanced Audit Policy to ensure its granular settings take precedence and are not overridden or unpredictably merged with broader Basic Audit Policy settings.2

2.2. Group Policy Objects (GPOs)

GPOs provide centralized management of audit policies across multiple machines in an Active Directory domain. This is the standard method for enterprise environments.
Advanced Audit Policy: audit.csv Structure and Example
This file resides in the GPO path \Machine\Microsoft\Windows NT\Audit\ within SYSVOL. It defines Advanced Audit Policy settings.
Format: Machine Name,Policy Target,Subcategory,Subcategory GUID,Inclusion Setting,Exclusion Setting,Setting Value
Content Example:
Machine Name,Policy Target,Subcategory,Subcategory GUID,Inclusion Setting,Exclusion Setting,Setting Value
*,System,Logon,{0CCE9215-69AE-11D9-BED3-505054503030},*,*,3
*,System,File System,{0CCE921D-69AE-11D9-BED3-505054503030},*,*,1
*,System,Process Creation,{0CCE922B-69AE-11D9-BED3-505054503030},*,*,3
*,System,Audit Policy Change,{0CCE9217-69AE-11D9-BED3-505054503030},*,*,1
  • Machine Name: Usually *.
  • Policy Target: System.
  • Subcategory: Human-readable name (informational).
  • Subcategory GUID: The unique identifier for the subcategory (critical).
  • Inclusion Setting: Usually *.
  • Exclusion Setting: Usually *.
  • Setting Value: 0=No Auditing, 1=Success, 2=Failure, 3=Success and Failure.
Basic Audit Policy: GptTmpl.inf Example Lines
This file resides in the GPO path \Machine\Microsoft\Windows NT\SecEdit\ within SYSVOL. It defines various security settings, including Basic Audit Policy under the [System Access] section (note: OCR showed `` section, likely meant System Access).
Content Example:
Ini, TOML
[Unicode]
Unicode=yes

[System Access]
; AuditAccountLogon: 0=No Auditing, 1=Success, 2=Failure, 3=Success and Failure
AuditAccountLogon = 3
AuditObjectAccess = 1
AuditPolicyChange = 3
;... other basic categories...

[Version]
signature="$CHICAGO$"
Revision=1
Client-Side Registry Keys Reflecting Applied GPO Settings
GPO settings are applied to specific registry locations on client machines. These keys reflect the *result* of GPO application.
Basic Audit Policy (from GPO):
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\Settings\Policy]
; Reflects GPO settings for Basic Audit Policy Categories
; Exact values depend on GPO configuration. Example shows Logon=Success/Failure, ObjectAccess=Success.
"AuditAccountLogon"=dword:00000003
"AuditObjectAccess"=dword:00000001
;... other categories...
Advanced Audit Policy (from GPO):
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\Settings\{0CCE9215-69AE-11D9-BED3-505054503030}]
; Reflects GPO settings for Advanced Audit Policy Subcategories
; Keys are named by Subcategory GUID. Example shows Logon and File System.
"Setting"=dword:00000003 ; Logon (Success and Failure)

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\Settings\{0CCE921D-69AE-11D9-BED3-505054503030}]
"Setting"=dword:00000001 ; File System (Success)
GPO Enforcement of Advanced over Basic:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Audit]
; Reflects GPO setting for forcing Advanced over Basic policy
"SCENoApplyLegacyAuditPolicy"=dword:00000001

2.3. auditpol.exe Commands

The auditpol.exe utility manages Advanced Audit Policy settings on the local machine. Changes made here configure the *local* policy layer, which may be overridden by GPO settings unless GPO is not configured or the local setting is enforced.
Set Subcategory Auditing:
:: Enable Logon events for Success and Failure
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

:: Enable File System auditing for Success only
auditpol /set /subcategory:"File System" /success:enable /failure:disable

:: Enable Audit Policy Change events for Success and Failure
auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable

:: Disable Process Creation auditing
auditpol /set /subcategory:"Process Creation" /success:disable /failure:disable
Backup Current Audit Policy:
auditpol /backup /file:"C:\Temp\AuditPolicyBackup.csv"
Restore Audit Policy from File:
auditpol /restore /file:"C:\Temp\AuditPolicyBackup.csv"
View Current Effective Audit Policy:
auditpol /get /category:*
Note: This command displays the *effective* audit policy currently enforced on the system, reflecting the merged result of local settings and applied GPOs, considering the SCENoApplyLegacyAuditPolicy setting.

2.4. System Access Control Lists (SACLs) on Objects

SACLs define object-specific auditing rules. They are configured directly on the object's Security Descriptor (e.g., file, folder, registry key). Remember, the corresponding Advanced Audit Policy subcategory (e.g., "Audit File System", "Audit Registry") must also be enabled for SACL entries to take effect.
Understanding SACL Components (How to Configure Auditing)
When configuring a SACL entry (often called an Audit ACE), you need to specify several key components:
  • Principal: Who is being audited? This is the user or group whose actions you want to monitor. It's specified using their name or, more reliably, their Security Identifier (SID). Examples: `Everyone`, `BUILTIN\Administrators`, `S-1-5-21-...-1001`.
  • Type: Which outcomes trigger an audit? You can audit `Success` attempts, `Failure` attempts, or `All` (`Success` and `Failure`). This corresponds to the `AU` (Audit Success) and `AL` (Audit Failure) flags in SDDL.
  • Applies to: (Mainly for folders/registry keys) Where does this rule apply? Does it apply only to this object, or should it be inherited by child objects (subfolders, files, subkeys)? This controls inheritance behavior.
  • Permissions / Access Mask: What specific actions trigger the audit? This defines the activities being monitored. You select specific permissions like `ReadData`, `WriteData`, `Delete`, `ReadPermissions`, or broader masks like `FullControl` (`FA` in SDDL), `Read` (`FR`), `Write` (`FW` or `WD`), etc. Only access attempts matching *both* the Principal *and* one of the specified Permissions *and* the Type (Success/Failure) will trigger an audit event (like Event ID 4663 for files/folders or 4657 for registry).
These components are configured using tools like the GUI Security tab (Advanced button -> Auditing tab), icacls.exe, or PowerShell cmdlets like Get-Acl/Set-Acl.
Configure File SACL using icacls.exe:
batch
:: Target file: C:\sensitive\data.txt
:: Audit SUCCESSFUL Delete attempts by BUILTIN\Administrators
:: Audit SUCCESS and FAILURE WriteData (WD) and AppendData (AD) attempts by Everyone

icacls C:\sensitive\data.txt /audit BUILTIN\Administrators:(S):(DE) Everyone:(S,F):(WD,AD)
  • /audit: Specifies SACL modification.
  • Principal: User or group name (e.g., Everyone, BUILTIN\Administrators).
  • (S,F): Audit flags - S=Success, F=Failure. Comma separates multiple flags. Use just (S) or (F) if needed.
  • :: Separator. (Note: OCR showed `::`, but icacls typically uses a single colon).
  • (Permissions): Comma-separated list of granular permissions (e.g., DE=Delete, WD=WriteData, AD=AppendData, FA=Full Access, RA=Read Attributes, RD=Read Data).
Configure Registry SACL using PowerShell:
powershell
# Target Key: HKLM:\SOFTWARE\MyApp
# Audit SUCCESS and FAILURE SetValue and Delete attempts by the 'Users' group (SID S-1-5-32-545)

$RegPath = "HKLM:\SOFTWARE\MyApp"
# Use a well-known SID or retrieve SID for a specific group/user if needed
$PrincipalSID = [System.Security.Principal.SecurityIdentifier]::new("S-1-5-32-545") # BUILTIN\Users SID

# Define the audit rule
# RegistryRights specify the permissions to audit
$AuditRights = [System.Security.AccessControl.RegistryRights]::SetValue,
               [System.Security.AccessControl.RegistryRights]::Delete
# AuditFlags specify Success and/or Failure
$AuditFlags = [System.Security.AccessControl.AuditFlags]::Success,
              [System.Security.AccessControl.AuditFlags]::Failure

# Create the AuditRule object
$AuditRule = [System.Security.AccessControl.RegistryAuditRule]::new(
    $PrincipalSID,
    $AuditRights,
    [System.Security.AccessControl.InheritanceFlags]::None, # Adjust inheritance if needed
    [System.Security.AccessControl.PropagationFlags]::None, # Adjust propagation if needed
    $AuditFlags
)

# Get the current ACL
try {
    $Acl = Get-Acl -Path $RegPath -Audit
} catch {
    Write-Error "Failed to get ACL for $RegPath. Ensure the key exists and you have permissions. Error: $($_.Exception.Message)"
    return
}

# Add the audit rule
$Acl.AddAuditRule($AuditRule)

# Apply the modified ACL
try {
    Set-Acl -Path $RegPath -AclObject $Acl
    Write-Host "SACL updated for $RegPath"
} catch {
    Write-Error "Failed to set ACL for $RegPath. Ensure you have permissions. Error: $($_.Exception.Message)"
}
Example SDDL SACL Strings:
These represent the SACL part (S:(...)) of an SDDL string, often retrieved using PowerShell's (Get-Acl -Audit).Sddl.
  • Audit all successful modifications (GenericWrite, GenericAll) by Everyone:
    S:(AU;SA;GWGA;;;WD)
    • GW = Generic Write (0x40000000)
    • GA = Generic All (0x10000000)
  • Audit failed Read Data (FR) access attempts by a specific user SID:
    S:(AL;SA;FR;;;S-1-5-21-1234567890-123456789-1234567890-1005)
    • FR = File Read Data (0x00000001)

2.5. Registry Manipulation (Global Object Access Auditing - Policy Enabling)

Global Object Access Auditing (GOAA) applies a system-wide SACL to all objects of a specific type (File System or Registry). It is configured via Advanced Audit Policy subcategories (specifically "File System (Global Object Access Auditing)" and "Registry (Global Object Access Auditing)"). You do not directly write SDDL into arbitrary registry values to enable GOAA itself. The .reg snippets below reflect the GPO-applied settings that enable the *policy setting*; the actual SACL applied globally is defined within the policy object configured via GPO or secpol.msc for that subcategory.
Enable File System Global Object Access Auditing Policy (Success & Failure)
Windows Registry Editor Version 5.00

; Reflects enabling the GOAA policy setting for File System via its corresponding Advanced Audit Policy subcategory registry value, typically via GPO.
; Configures: Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies\Global Object Access Auditing\File System

; IMPORTANT: The actual SACL applied globally is configured via the secpol.msc or GPO interface for this subcategory, NOT by placing SDDL directly in the registry here.
; This snippet reflects enabling the policy via GPO; local settings are not stored this way.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\Settings\{0CCE9240-69AE-11D9-BED3-505054503030}] ; GUID for "File System (Global Object Access Auditing)"
"Setting"=dword:00000003 ; 3 = Success and Failure
Enable Registry Global Object Access Auditing Policy (Success & Failure)
Windows Registry Editor Version 5.00

; Reflects enabling the GOAA policy setting for Registry via its corresponding Advanced Audit Policy subcategory registry value, typically via GPO.
; Configures: Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies\Global Object Access Auditing\Registry

; IMPORTANT: The actual SACL applied globally is configured via the secpol.msc or GPO interface for this subcategory, NOT by placing SDDL directly in the registry here.
; This snippet reflects enabling the policy via GPO; local settings are not stored this way.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\Settings\{0CCE9241-69AE-11D9-BED3-505054503030}] ; GUID for "Registry (Global Object Access Auditing)"
"Setting"=dword:00000003 ; 3 = Success and Failure
Caution: Misconfiguring GOAA can lead to extremely high event volume and performance degradation. Use this feature judiciously and define the global SACL carefully through the policy management tools.2

3. Configuration Storage Locators

Audit policy settings are stored in various locations depending on the configuration method (Local vs. GPO) and type (Basic vs. Advanced).

3.1. Registry Locations

Registry Locations for Audit Settings
Setting Type
Primary Registry Location(s)
Notes
Local Basic Audit Policy
HKLM\SECURITY\Policy\PolAdtEv
Binary LSA structure. Not human-readable. Reflects settings configured via secpol.msc > Local Policies > Audit Policy. Direct modification unsupported; use tools.
Local Advanced Audit Policy
N/A (Not stored in simple, documented registry values)
Configured via auditpol.exe or secpol.msc > Advanced Audit Policy. Settings merge into the effective policy. Stored internally by LSA.
GPO Basic Audit Policy
HKLM\Software\Policies\Microsoft\Windows\EventLog\Settings\Policy
Values under this key reflect Basic Audit categories set via GPO (GptTmpl.inf). Checked by LSA at policy refresh.
GPO Advanced Audit Policy
HKLM\Software\Policies\Microsoft\Windows\EventLog\Settings\
Subkeys named by Subcategory GUID contain Setting (DWORD: 0, 1, 2, or 3) reflecting GPO configuration (defined in audit.csv within GPO). Checked by LSA.
GPO Enforcement Setting (SCENoApplyLegacyAuditPolicy)
HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\Audit
SCENoApplyLegacyAuditPolicy (DWORD: 1) reflects GPO setting. Checked by LSA.
Local Enforcement Setting (SCENoApplyLegacyAuditPolicy)
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
SCENoApplyLegacyAuditPolicy (DWORD: 1) reflects local setting via secpol.msc. Checked by LSA.
Effective Audit Policy
Aggregated by LSA/Advapi32 from sources above. Queryable via auditpol /get /category:*. Underlying merged state often reflected in HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Audit\AuditOptions.
Represents the actual policy enforced by the system after merging local and GPO settings according to precedence rules and the SCENoApplyLegacyAuditPolicy flag.
Global Object Access Auditing Policy
Enabled via Advanced Audit Policy subcategory settings (see GPO Advanced location).
The SACL definition itself is stored within the policy object data (GPO files), not as a simple registry value that clients read directly. LSA applies it based on the enabled policy setting.

3.2. Group Policy File Paths (Relative to GPT Root)

Audit settings configured via GPO are stored in specific files within the Group Policy Template (GPT) folder structure in SYSVOL (e.g., \\<Domain>\SYSVOL\<Domain>\Policies\{GPO_GUID}\).
  • Advanced Audit Policy (audit.csv): \Machine\Microsoft\Windows NT\Audit\audit.csv
  • Basic Audit Policy / Security Options (GptTmpl.inf): \Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf

3.3. Object SACL Retrieval Commands

Commands to retrieve the Security Descriptor, including the SACL, for various object types.
NTFS File/Folder:
  • Using icacls.exe (Displays ACEs textually):
    batch
    icacls C:\path\to\file_or_folder
(Look for AUDIT entries in the output)
  • Using PowerShell Get-Acl (Retrieve SDDL string):
    powershell
    (Get-Acl -Path C:\path\to\file_or_folder -Audit).Sddl
  • Using PowerShell Get-Acl (View Audit Rules as objects):
    powershell
    (Get-Acl -Path C:\path\to\file_or_folder -Audit).Audit | Format-List
Registry Key:
  • Using PowerShell Get-Acl (Retrieve SDDL string):
    powershell
    (Get-Acl -Path "HKLM:\path\to\key" -Audit).Sddl
  • Using PowerShell Get-Acl (View Audit Rules as objects):
    powershell
    (Get-Acl -Path "HKLM:\path\to\key" -Audit).Audit | Format-List
Active Directory Object:
  • Using dsacls.exe (Displays ACEs textually):
    batch
    dsacls "CN=SomeObject,OU=Container,DC=domain,DC=com" /S
(The /S switch displays the SACL)
  • Using PowerShell Get-Acl with ActiveDirectory Provider (Retrieve SDDL string):
    powershell
    # Ensure Active Directory PowerShell module is imported
Import-Module ActiveDirectory -ErrorAction SilentlyContinue

(Get-Acl -Path "AD:CN=SomeObject,OU=Container,DC=domain,DC=com" -Audit).Sddl

4. Event Data Structures & Examples

This section provides annotated XML examples of typical events generated by key Advanced Audit Policy subcategories.

4.1. Event XML: File System (Event ID 4663 - Object Access Attempt)

Generated when an attempt is made to access a file or folder object with a matching SACL entry. Requires the "Audit File System" subcategory to be enabled and a relevant SACL on the object.6
xml
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4663</EventID>
    <Version>1</Version>
    <Level>0</Level>
    <Task>12800</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2023-10-27T10:30:01.1234567Z" />
    <EventRecordID>123456</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="56" />
    <Channel>Security</Channel>
    <Computer>WORKSTATION01.corp.contoso.com</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-21-111111111-222222222-333333333-1103</Data>
    <Data Name="SubjectUserName">Alice</Data>
    <Data Name="SubjectDomainName">CORP</Data>
    <Data Name="SubjectLogonId">0x12345</Data>
    <Data Name="ObjectServer">Security</Data>
    <Data Name="ObjectType">File</Data>
    <Data Name="ObjectName">C:\sensitive\project_alpha\document.docx</Data>
    <Data Name="HandleId">0x1a4</Data>
    <Data Name="AccessList">%%4417 %%%%4418 %%%%4423</Data> 
    <Data Name="AccessMask">0x120196</Data> 
    <Data Name="ProcessId">0x2468</Data>
    <Data Name="ProcessName">C:\Windows\System32\notepad.exe</Data>
    <Data Name="ResourceAttributes">S:AI(AU;SAFA;FA;;;WD)</Data> 
  </EventData>
</Event>

4.2. Event XML: Process Creation (Event ID 4688)

Generated when a new process starts. Requires the "Audit Process Creation" subcategory to be enabled.6
xml
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4688</EventID>
    <Version>2</Version>
    <Level>0</Level>
    <Task>13312</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2023-10-27T10:35:15.9876543Z" />
    <EventRecordID>123460</EventRecordID>
    <Correlation />
    <Execution ProcessID="888" ThreadID="999" /> 
    <Channel>Security</Channel>
    <Computer>WKSTN02.corp.contoso.com</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-21-111111111-222222222-333333333-1104</Data>
    <Data Name="SubjectUserName">Bob</Data>
    <Data Name="SubjectDomainName">CORP</Data>
    <Data Name="SubjectLogonId">0x54321</Data>
    <Data Name="NewProcessId">0x1f4c</Data> 
    <Data Name="NewProcessName">C:\Windows\System32\cmd.exe</Data> 
    <Data Name="TokenElevationType">%%1936</Data> 
    <Data Name="ProcessId">0xabc</Data> 
    <Data Name="CommandLine">"cmd.exe" /c "ping 8.8.8.8"</Data> 
    <Data Name="TargetUserSid">S-1-0-0</Data>
    <Data Name="TargetUserName">-</Data>
    <Data Name="TargetDomainName">-</Data>
    <Data Name="TargetLogonId">0x0</Data>
    <Data Name="ParentProcessName">C:\Windows\explorer.exe</Data> 
    <Data Name="MandatoryLabel">S-1-16-8192</Data> 
  </EventData>
</Event>

4.3. Event XML: Kerberos Authentication Service (Event ID 4768 - TGT Request)

Generated on Domain Controllers when an account requests a Kerberos Ticket Granting Ticket (TGT). Requires the "Audit Kerberos Authentication Service" subcategory to be enabled.5
xml
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4768</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>14339</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords> 
    <TimeCreated SystemTime="2023-10-27T11:05:20.1122334Z" />
    <EventRecordID>789101</EventRecordID>
    <Correlation />
    <Execution ProcessID="716" ThreadID="1800" />
    <Channel>Security</Channel>
    <Computer>DC01.corp.contoso.com</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">svc_backup</Data> 
    <Data Name="TargetDomainName">CORP.CONTOSO.COM</Data>
    <Data Name="TargetSid">S-1-5-21-111111111-222222222-333333333-1501</Data>
    <Data Name="ServiceName">krbtgt/CORP.CONTOSO.COM</Data> 
    <Data Name="ServiceSid">S-1-5-21-111111111-222222222-333333333-502</Data>
    <Data Name="TicketOptions">0x40810010</Data>
    <Data Name="Status">0x18</Data> 
    <Data Name="FailureType">%%24</Data> 
    <Data Name="PreAuthType">2</Data> 
    <Data Name="IpAddress">192.168.1.150</Data> 
    <Data Name="IpPort">51234</Data> 
    <Data Name="CertIssuerName"></Data>
    <Data Name="CertSerialNumber"></Data>
    <Data Name="CertThumbprint"></Data>
  </EventData>
</Event>

4.4. Event XML: Policy Change (Event ID 4719 - System Audit Policy Changed)

Generated when the system's audit policy (Basic or Advanced) is modified. Requires the "Audit Audit Policy Change" subcategory to be enabled. This event is critical for detecting potential tampering with security monitoring.5
xml
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4719</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13568</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords> 
    <TimeCreated SystemTime="2023-10-27T11:15:45.5566778Z" />
    <EventRecordID>123488</EventRecordID>
    <Correlation />
    <Execution ProcessID="780" ThreadID="3456" />
    <Channel>Security</Channel>
    <Computer>MGMTSRV01.corp.contoso.com</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-21-111111111-222222222-333333333-500</Data>
    <Data Name="SubjectUserName">Administrator</Data>
    <Data Name="SubjectDomainName">CORP</Data>
    <Data Name="SubjectLogonId">0x67890</Data>
    <Data Name="CategoryId">%%8277</Data> 
    <Data Name="SubcategoryGuid">{0CCE921D-69AE-11D9-BED3-505054503030}</Data> 
    <Data Name="SubcategoryName">File System</Data> 
    <Data Name="AuditPolicyChanges">%%17923</Data> 
  </EventData>
</Event>

4.5. Event XML: Registry Access (Event ID 4657 - Registry Value Modified)

Generated when a registry value is created, modified, or deleted, provided the "Audit Registry" subcategory is enabled and a relevant SACL exists on the parent key.6
xml
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4657</EventID>
    <Version>1</Version>
    <Level>0</Level>
    <Task>12801</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords> 
    <TimeCreated SystemTime="2023-10-27T11:20:05.1213141Z" />
    <EventRecordID>123501</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="64" />
    <Channel>Security</Channel>
    <Computer>APPSRVO1.corp.contoso.com</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-18</Data> 
    <Data Name="SubjectUserName">APPSRVO1$</Data>
    <Data Name="SubjectDomainName">CORP</Data>
    <Data Name="SubjectLogonId">0x3e7</Data>
    <Data Name="ObjectName">\REGISTRY\MACHINE\SOFTWARE\MyApp\Settings</Data> 
    <Data Name="ObjectValueName">LogLevel</Data> 
    <Data Name="HandleId">0x2b8</Data>
    <Data Name="OperationType">%%1905</Data> 
    <Data Name="ProcessId">0x5d0</Data>
    <Data Name="ProcessName">C:\Program Files\MyApp\MyAppService.exe</Data>
    <Data Name="OldValueType">%%1873</Data> 
    <Data Name="OldValue">3</Data>
    <Data Name="NewValueType">%%1873</Data>
    <Data Name="NewValue">4</Data>
  </EventData>
</Event>

4.6. Event XML: Handle Manipulation (Event ID 4662 - Operation on Object)

Generated when certain operations (like duplication) are performed on an existing handle to an object. Requires the "Audit Handle Manipulation" subcategory and a relevant SACL. Note: This event often provides less direct security value compared to 4663 or 4657 but can be useful in specific investigations.
xml
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4662</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12802</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords> 
    <TimeCreated SystemTime="2023-10-27T11:25:10.9988776Z" />
    <EventRecordID>123515</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="72" />
    <Channel>Security</Channel>
    <Computer>WKSTN03.corp.contoso.com</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-21-111111111-222222222-333333333-1105</Data>
    <Data Name="SubjectUserName">Charlie</Data>
    <Data Name="SubjectDomainName">CORP</Data>
    <Data Name="SubjectLogonId">0x98765</Data>
    <Data Name="ObjectServer">Security</Data>
    <Data Name="ObjectType">File</Data>
    <Data Name="ObjectName">C:\shared\report.pdf</Data>
    <Data Name="HandleId">0x3c4</Data> 
    <Data Name="OperationType">%%1537</Data> 
    <Data Name="ProcessId">0x9e8</Data>
    <Data Name="ProcessName">C:\Windows\System32\svchost.exe</Data>
    <Data Name="AccessMask"></Data>
    <Data Name="Properties"></Data>
  </EventData>
</Event>

5. Auditing Flow Snippets

This section outlines the high-level sequence of events involved in generating security audits.

5.1. SeAccessCheck SACL Logic (Structured Text Flow)

The decision to generate an object access audit occurs within the Security Reference Monitor (SRM) as part of the standard access check routine, typically invoked by functions like NtAccessCheck or related kernel APIs.
  1. Initiation: A process requests access to an object. The kernel calls an internal SRM function similar to: SeAccessCheck(SecurityDescriptor, SubjectToken, DesiredAccess, ObjectType,...).
  2. DACL Evaluation: The SRM compares the SubjectToken (containing user/group SIDs and privileges) against the Discretionary Access Control List (SecurityDescriptor->Dacl).
  3. Access Determination: Based on the DACL check, the SRM determines the GrantedAccess mask (what permissions are actually allowed) and the overall AccessCheckResult (Success or Failure). Access is granted or denied at this point.
  4. SACL Check Prerequisite: Independently of the access decision, the SRM checks if a System Access Control List (SecurityDescriptor->Sacl) exists on the object AND if auditing is generally enabled for the ObjectType (via the system audit policy, e.g., "Audit File System" enabled).
  5. SACL ACE Iteration: If a SACL exists and auditing is enabled for the type:
    • The SRM iterates through each SYSTEM_AUDIT_ACE within the SACL.
    • For each ACE, the SRM performs the following checks:
      • Trustee Match: Does the ACE's Trustee SID match a SID present in the SubjectToken?
      • Access Mask Match: Does the ACE's ACCESS_MASK contain any bits that correspond to the permissions that were *granted* in the GrantedAccess mask (even if the overall operation failed due to other checks)? Note: Some interpretations suggest it checks against *desired* access, but checking granted access is more common for triggering audits accurately.
      • Outcome Match: Does the ACE's Flags (AU for Success, AL for Failure) correspond to the overall AccessCheckResult determined in Step 3?
      • Audit Trigger: If all checks (Trustee, Access Mask, Outcome) are TRUE for a given ACE, an audit is required. The SRM sets an internal GenerateAudit flag and notes the details of the matching ACE(s).
  6. Audit Generation Call: If the GenerateAudit flag is TRUE:
    • The SRM calls an internal audit generation function (e.g., SeOpenObjectAuditAlarm, SeObjectReferenceAuditAlarm).
    • This function is passed necessary context: ObjectType, ObjectName, SubjectToken details (SID, username), DesiredAccess, GrantedAccess, AccessCheckResult, and information from the triggering SACL ACE.
  7. Return: The original SeAccessCheck function returns the GrantedAccess mask and the AccessCheckResult to the caller (the kernel mode component handling the object access). The audit generation happens asynchronously or as a side effect.
This flow demonstrates that SACL processing is integral to the access control mechanism itself. Audits are generated only when an access attempt matches the specific conditions (Who, What Access, Success/Failure) defined within a relevant SACL ACE, and the corresponding audit policy is enabled.

5.2. Audit Generation Path (Structured Text Flow)

The overall path from an auditable action to an event log record involves several system components.
  1. Audit Trigger Event:
    • Object Access: Security Reference Monitor (SRM) performs SeAccessCheck, determines an audit is required based on SACL match (as described in 5.1), and invokes an internal audit generation function (e.g., SeOpenObjectAuditAlarm). -> Audit Data Prepared (by SRM).
    • Non-Object Event (e.g., Logon, Policy Change, Process Create): Local Security Authority Subsystem Service (LSA), Kernel, or other relevant component detects an auditable event based on system audit policy (Basic or Advanced). -> Audit Triggered & Audit Data Prepared (by LSA/Kernel/Component).
  2. Audit Message Generation:
    • Prepared Audit Data (containing subject info, event details, status, etc.) is passed to LSA functions (e.g., via LsaAuditingInterfaces or potentially using Authorization APIs like AuthzGenerateAudit*).
    • LSA formats the data into a standardized audit message structure suitable for the Event Logging service.
  3. Event Logging:
    • Formatted Audit Message is submitted to the Windows Event Logging Service (eventlog service).
    • The Event Logging Service may apply further filtering (e.g., based on event source or keywords, though less common for Security log).
    • The service writes the final event record to the Security event log file, typically located at: %SystemRoot%\System32\winevt\Logs\Security.evtx.
  4. (Optional) Forwarding/Collection:
    • If Windows Event Forwarding (WEF) is configured, the Event Logging Service forwards the event to a collector.
    • Alternatively, SIEM agents or other monitoring tools may read events directly from the Security.evtx log file or via Event Tracing for Windows (ETW) sessions consuming security events.
This pathway highlights the roles of the SRM (for object access triggers), LSA (as a central policy checker, audit formatter, and interface to logging), and the Event Logging Service (as the final writer to the persistent log file).

Works Cited

  1. Basic security audit policies - Windows 10 | Microsoft Learn, accessed May 2, 2025, https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/basic-security-audit-policies
  2. Advanced security audit policy settings - Windows 10 | Microsoft Learn, accessed May 2, 2025, https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/advanced-security-audit-policy-settings
  3. Advanced Audit Policy Configuration | Microsoft Learn, accessed May 2, 2025, https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn452415(v=ws.11)
  4. Audit Policy Recommendations - Learn Microsoft, accessed May 2, 2025, https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations
  5. Appendix L – Events to Monitor | Microsoft Learn, accessed May 2, 2025, https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor
  6. Windows security event sets that can be sent to Microsoft Sentinel, accessed May 2, 2025, https://learn.microsoft.com/en-us/azure/sentinel/windows-security-event-id-reference

More from Thanh Trung Le

All posts

Related posts