ANAVEM
Languagefr
Windows security monitoring dashboard showing Event Viewer with security audit logs in a professional SOC environment
Event ID 4662InformationSecurityWindows

Windows Event ID 4662 – Security: Object Access Auditing

Event ID 4662 logs when an operation is performed on an object with configured auditing. This security event tracks access attempts to files, folders, registry keys, and Active Directory objects.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 202612 min read 0
Event ID 4662Security 5 methods 12 min
Event Reference

What This Event Means

Event ID 4662 represents a cornerstone of Windows security auditing, providing detailed logging of object access operations across multiple subsystems. When this event fires, it indicates that a user or process has performed an operation on an audited object, whether that's a file, registry key, Active Directory object, or other securable resource.

The event structure includes critical fields such as the subject (who performed the action), the object (what was accessed), the operation type, and the access mask that defines the specific permissions used. This granular detail makes Event 4662 invaluable for security teams investigating potential breaches, compliance auditors tracking data access, and system administrators monitoring sensitive resource usage.

Windows generates this event through the Local Security Authority (LSA) subsystem, which intercepts access requests and compares them against configured audit policies. The event only appears when both object-level auditing is enabled and the specific object has a System Access Control List (SACL) configured to audit the attempted operation type.

In enterprise environments, Event 4662 can generate significant log volume, especially on file servers and domain controllers. Proper filtering and log management strategies are essential to extract meaningful security intelligence from these events without overwhelming your SIEM or log analysis tools.

Applies to

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

Possible Causes

  • File or folder access when object access auditing is enabled
  • Registry key modifications with configured audit settings
  • Active Directory object operations (read, write, delete) on audited objects
  • Service account accessing audited system resources
  • User authentication against audited domain objects
  • Application accessing audited files or registry keys during normal operation
  • Backup software reading audited files during scheduled backups
  • Antivirus software scanning audited directories
  • System maintenance tasks accessing audited system objects
Resolution Methods

Troubleshooting Steps

01

Analyze Event Details in Event Viewer

Start by examining the specific details of Event 4662 to understand what object was accessed and by whom.

  1. Open Event Viewer by pressing Win + R, typing eventvwr.msc, and pressing Enter
  2. Navigate to Windows LogsSecurity
  3. Filter for Event ID 4662 by right-clicking the Security log and selecting Filter Current Log
  4. In the filter dialog, enter 4662 in the Event IDs field and click OK
  5. Double-click on a 4662 event to view its properties
  6. Examine the General tab for key information:
    • Subject: Shows the user account that performed the operation
    • Object: Displays the object name and type that was accessed
    • Process Information: Reveals which process initiated the access
    • Access Request Information: Details the specific permissions requested
Pro tip: Look for the Object Name field to identify exactly which file, registry key, or AD object was accessed. The Access Mask field shows the specific permissions used in hexadecimal format.
02

Query Events with PowerShell

Use PowerShell to efficiently query and analyze Event 4662 occurrences across your system.

  1. Open PowerShell as Administrator
  2. Query recent Event 4662 entries:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} -MaxEvents 50 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
  3. Filter events by specific user account:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} | Where-Object {$_.Message -like "*username*"} | Select-Object TimeCreated, Message
  4. Search for events related to specific objects:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} | Where-Object {$_.Message -like "*C:\Sensitive\*"} | Format-List
  5. Export filtered results for analysis:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662; StartTime=(Get-Date).AddDays(-7)} | Export-Csv -Path "C:\Temp\Event4662_Analysis.csv" -NoTypeInformation
Pro tip: Use the StartTime and EndTime parameters in FilterHashtable to narrow down your search to specific time ranges, especially useful for incident investigation.
03

Configure Object Access Auditing

Properly configure object access auditing to control when Event 4662 is generated and reduce noise.

  1. Open Local Group Policy Editor by running gpedit.msc
  2. Navigate to Computer ConfigurationWindows SettingsSecurity SettingsAdvanced Audit Policy ConfigurationAudit PoliciesObject Access
  3. Configure the following policies based on your needs:
    • Audit File System: Enable for file and folder access auditing
    • Audit Registry: Enable for registry key access auditing
    • Audit Handle Manipulation: Enable for detailed object handle tracking
  4. For specific file or folder auditing, right-click the target object in Explorer
  5. Select PropertiesSecurityAdvancedAuditing tab
  6. Click Add to configure a new audit entry
  7. Select the user or group to audit and specify the operations to monitor
  8. Apply the policy using:
    gpupdate /force
Warning: Enabling comprehensive object access auditing can generate massive log volumes. Start with specific high-value targets and gradually expand coverage based on your log management capacity.
04

Investigate Suspicious Access Patterns

Analyze Event 4662 patterns to identify potential security incidents or unauthorized access attempts.

  1. Create a PowerShell script to analyze access patterns:
    # Get events from the last 24 hours
    $Events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662; StartTime=(Get-Date).AddDays(-1)}
    
    # Group by user account
    $UserAccess = $Events | ForEach-Object {
        $xml = [xml]$_.ToXml()
        [PSCustomObject]@{
            Time = $_.TimeCreated
            User = $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'SubjectUserName'} | Select-Object -ExpandProperty '#text'
            ObjectName = $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'ObjectName'} | Select-Object -ExpandProperty '#text'
        }
    } | Group-Object User
    
    $UserAccess | Sort-Object Count -Descending
  2. Look for anomalous patterns:
    • Unusual access times (outside business hours)
    • High-frequency access to sensitive files
    • Access from unexpected user accounts
    • Failed access attempts followed by successful ones
  3. Cross-reference with Event 4656 (handle requested) and 4658 (handle closed) for complete access chains
  4. Check for privilege escalation by examining the access masks used
  5. Correlate with network logon events (4624/4625) to identify remote access
Pro tip: Create scheduled tasks to run these analysis scripts daily and alert on suspicious patterns. Consider integrating with your SIEM for automated threat detection.
05

Advanced Forensic Analysis and Correlation

Perform deep forensic analysis of Event 4662 for security investigations and compliance reporting.

  1. Extract detailed event data for forensic analysis:
    # Advanced event parsing script
    $ForensicData = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662; StartTime=(Get-Date).AddDays(-30)} | ForEach-Object {
        $xml = [xml]$_.ToXml()
        $eventData = @{}
        $xml.Event.EventData.Data | ForEach-Object { $eventData[$_.Name] = $_.'#text' }
        
        [PSCustomObject]@{
            TimeCreated = $_.TimeCreated
            SubjectUserSid = $eventData.SubjectUserSid
            SubjectUserName = $eventData.SubjectUserName
            SubjectDomainName = $eventData.SubjectDomainName
            ObjectServer = $eventData.ObjectServer
            ObjectType = $eventData.ObjectType
            ObjectName = $eventData.ObjectName
            ProcessName = $eventData.ProcessName
            AccessMask = $eventData.AccessMask
            Properties = $eventData.Properties
        }
    }
    
    # Export for external analysis tools
    $ForensicData | Export-Csv -Path "C:\Forensics\Event4662_Detailed.csv" -NoTypeInformation
  2. Analyze access mask values to understand specific permissions:
    # Decode common access mask values
    function Decode-AccessMask {
        param([string]$AccessMask)
        
        $mask = [Convert]::ToInt32($AccessMask, 16)
        $permissions = @()
        
        if ($mask -band 0x1) { $permissions += "READ_DATA" }
        if ($mask -band 0x2) { $permissions += "WRITE_DATA" }
        if ($mask -band 0x4) { $permissions += "APPEND_DATA" }
        if ($mask -band 0x20) { $permissions += "EXECUTE" }
        if ($mask -band 0x40) { $permissions += "READ_ATTRIBUTES" }
        if ($mask -band 0x80) { $permissions += "WRITE_ATTRIBUTES" }
        if ($mask -band 0x10000) { $permissions += "DELETE" }
        
        return $permissions -join ", "
    }
  3. Create timeline analysis for incident reconstruction
  4. Correlate with process creation events (4688) to understand attack chains
  5. Generate compliance reports showing data access patterns
  6. Set up automated alerting for high-risk access patterns using Windows Event Forwarding or SIEM integration
Warning: Forensic analysis should be performed on copies of log data to preserve evidence integrity. Always follow your organization's incident response procedures when investigating security events.

Overview

Event ID 4662 fires when Windows detects an operation performed on an object that has auditing configured through Group Policy or local security settings. This event is part of Windows advanced audit policy and specifically tracks object access attempts across the system. The event captures detailed information about who accessed what object, when the access occurred, and what type of operation was performed.

This event appears in the Security log and requires object access auditing to be enabled in your audit policy. Without proper audit configuration, you won't see these events even when object access occurs. The event provides granular visibility into file system access, registry modifications, and Active Directory object interactions, making it essential for security monitoring and compliance requirements.

Event 4662 differs from basic file access events by providing more detailed information about the specific permissions used and the object's security descriptor. This makes it particularly valuable for forensic investigations and detecting unauthorized access attempts to sensitive resources.

Frequently Asked Questions

What does Event ID 4662 mean and when does it appear?+
Event ID 4662 indicates that an operation was performed on an object with configured auditing. It appears in the Security log when object access auditing is enabled and someone accesses a file, registry key, or Active Directory object that has a System Access Control List (SACL) configured. The event provides detailed information about who accessed what object, when the access occurred, and what specific permissions were used during the operation.
Why am I not seeing Event 4662 even though files are being accessed?+
Event 4662 only appears when two conditions are met: object access auditing must be enabled in your audit policy, and the specific object being accessed must have auditing configured through its Security Access Control List (SACL). Check your Group Policy settings under Advanced Audit Policy Configuration → Object Access, and verify that the files or folders you want to monitor have auditing enabled in their security properties. Without both configurations, Windows won't generate these events.
How can I reduce the volume of Event 4662 logs without losing important security information?+
Focus your auditing on high-value targets rather than enabling system-wide object access auditing. Configure SACLs only on sensitive files, folders, and registry keys that require monitoring. Use success/failure filtering to audit only failed access attempts for most objects, while enabling both success and failure auditing for critical resources. Consider using Windows Event Forwarding to centralize logs and implement filtering at the collection point to reduce storage requirements while maintaining security visibility.
What information can I extract from the Access Mask field in Event 4662?+
The Access Mask field contains a hexadecimal value that represents the specific permissions used during the object access. Common values include 0x1 for READ_DATA, 0x2 for WRITE_DATA, 0x4 for APPEND_DATA, 0x20 for EXECUTE, and 0x10000 for DELETE. You can decode these values using bitwise operations in PowerShell or refer to Microsoft documentation for complete access mask definitions. Understanding access masks helps identify whether someone was reading, modifying, or attempting to delete sensitive data.
How do I correlate Event 4662 with other security events for incident investigation?+
Event 4662 should be analyzed alongside related security events for complete incident reconstruction. Correlate with Event 4656 (handle requested to object) and 4658 (handle closed) to see the full access lifecycle. Cross-reference with logon events 4624/4625 to identify the source of access, and Event 4688 (process creation) to understand which applications initiated the access. Use the Subject fields (UserSid, UserName, DomainName) and timestamps to create chronological timelines of user activity across multiple event types.
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...