ANAVEM
Languagefr
Windows security monitoring dashboard displaying audit logs and event analysis in a cybersecurity operations center
Event ID 4887InformationMicrosoft-Windows-Security-AuditingWindows

Windows Event ID 4887 – Microsoft-Windows-Security-Auditing: A handle to an object was requested

Event ID 4887 logs when a process requests a handle to a system object for access. This security audit event tracks object access attempts and helps monitor file, registry, and kernel object interactions across Windows systems.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 202612 min read 0
Event ID 4887Microsoft-Windows-Security-Auditing 5 methods 12 min
Event Reference

What This Event Means

Windows Event ID 4887 represents a critical component of the Windows security auditing framework, specifically designed to track object handle requests across the operating system. When any process attempts to obtain a handle to a system object—whether it's a file, registry key, process, thread, or other kernel object—Windows generates this audit event to provide a comprehensive trail of object access activities.

The event structure includes essential forensic data: the Security Identifier (SID) of the requesting user account, detailed process information including Process ID and executable path, the target object's name and type, and the specific access rights being requested. This granular level of detail makes Event ID 4887 invaluable for security investigations, compliance auditing, and behavioral analysis of system interactions.

In Windows Server 2025 and Windows 11 24H2, Microsoft enhanced the event's performance impact and filtering capabilities, reducing the overhead associated with high-volume object access monitoring. The event integrates with Advanced Threat Analytics and Microsoft Defender for Endpoint, providing automated correlation with suspicious activity patterns and known attack vectors.

Understanding Event ID 4887 is crucial for security professionals implementing zero-trust architectures, as it provides the foundation for monitoring and validating all object access requests within the Windows environment.

Applies to

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

Possible Causes

  • Process attempting to open a file handle for read, write, or execute operations
  • Application requesting access to registry keys or values
  • Service or driver accessing kernel objects like processes or threads
  • User account attempting to access protected system resources
  • Malware or unauthorized software trying to access sensitive objects
  • Backup software scanning file system objects for archival
  • Antivirus engines requesting handles to scan files and processes
  • System maintenance tools accessing configuration objects
  • Network services opening handles to shared resources
  • Administrative tools performing system management operations
Resolution Methods

Troubleshooting Steps

01

Review Event Details in Event Viewer

Start by examining the specific details of Event ID 4887 to understand the context of the object access request.

  1. Open Event Viewer by pressing Win + R, typing eventvwr.msc, and pressing Enter
  2. Navigate to Windows LogsSecurity
  3. Filter for Event ID 4887 by right-clicking the Security log and selecting Filter Current Log
  4. Enter 4887 in the Event IDs field and click OK
  5. Double-click on a 4887 event to view detailed information including:
    • Subject: User account requesting the handle
    • Process Information: Process ID and executable path
    • Object: Target object name and type
    • Access Request Information: Requested permissions
  6. Note the Handle ID value for correlation with subsequent access events
Pro tip: Use the Details tab in XML view to see all available fields, including ProcessName and ObjectName for easier analysis.
02

Filter Events with PowerShell

Use PowerShell to efficiently query and analyze Event ID 4887 occurrences with specific criteria.

  1. Open PowerShell as Administrator
  2. Query recent 4887 events with basic filtering:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4887} -MaxEvents 50 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
  3. Filter events by specific process name:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4887} | Where-Object {$_.Message -like "*notepad.exe*"} | Select-Object TimeCreated, Message
  4. Search for events from a specific user account:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4887} | Where-Object {$_.Message -like "*S-1-5-21-*-1001*"} | Format-List TimeCreated, Message
  5. Export filtered results for analysis:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4887; StartTime=(Get-Date).AddHours(-24)} | Export-Csv -Path "C:\Temp\Event4887_Analysis.csv" -NoTypeInformation
Warning: Event ID 4887 can generate thousands of entries per hour on active systems. Always use time-based filtering to avoid performance issues.
03

Configure Object Access Auditing Policy

Ensure proper audit policy configuration to control Event ID 4887 generation and reduce noise.

  1. Open Group Policy Management Console or run gpedit.msc for local policy
  2. Navigate to Computer ConfigurationWindows SettingsSecurity SettingsAdvanced Audit Policy ConfigurationObject Access
  3. Configure Audit Handle Manipulation:
    • Double-click the policy
    • Check Configure the following audit events
    • Select Success and/or Failure based on requirements
    • Click OK
  4. Apply the policy using command line:
    auditpol /set /subcategory:"Handle Manipulation" /success:enable /failure:enable
  5. Verify current audit settings:
    auditpol /get /subcategory:"Handle Manipulation"
  6. For specific object auditing, configure SACL (System Access Control List) on target objects:
    # Example: Enable auditing on a specific folder
    icacls "C:\SensitiveData" /grant "Everyone:(OI)(CI)F" /audit "Everyone:(OI)(CI)(FA)"
Pro tip: Use Global Object Access Auditing in Group Policy to automatically apply audit settings to file system and registry objects without manually configuring SACLs.
04

Analyze Event Patterns and Correlations

Perform advanced analysis to identify suspicious patterns and correlate Event ID 4887 with other security events.

  1. Create a PowerShell script to analyze access patterns:
    # Analyze 4887 events for unusual access patterns
    $Events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4887; StartTime=(Get-Date).AddDays(-1)}
    $ProcessStats = $Events | ForEach-Object {
        $Message = $_.Message
        if ($Message -match "Process Name:\s+(.+)")
        {
            $Matches[1]
        }
    } | Group-Object | Sort-Object Count -Descending
    $ProcessStats | Select-Object Name, Count | Format-Table
  2. Correlate with logon events (4624) to identify user context:
    $LogonEvents = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-2)}
    $HandleEvents = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4887; StartTime=(Get-Date).AddHours(-2)}
    # Cross-reference by timestamp and user SID
  3. Check for failed access attempts (Event ID 4656) that might indicate reconnaissance:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4656} | Where-Object {$_.Message -like "*Failure*"} | Select-Object TimeCreated, Message
  4. Monitor registry access patterns for potential malware activity:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4887} | Where-Object {$_.Message -like "*\Registry\*"} | Group-Object {($_.Message -split "\n" | Where-Object {$_ -like "*Object Name:*"}).Split(":")[1].Trim()}
  5. Set up automated monitoring with scheduled tasks:
    # Create a monitoring script that runs every hour
    $Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-File C:\Scripts\Monitor4887.ps1"
    $Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Hours 1)
    Register-ScheduledTask -TaskName "Monitor Event 4887" -Action $Action -Trigger $Trigger
05

Advanced Forensic Investigation and Response

Conduct deep forensic analysis when Event ID 4887 indicates potential security incidents or policy violations.

  1. Extract detailed event data using Windows Event Forwarding (WEF) for centralized analysis:
    # Configure WEF subscription for 4887 events
    wecutil cs "C:\Config\4887Subscription.xml"
  2. Use Process Monitor (ProcMon) to correlate real-time object access with audit events:
    • Download Process Monitor from Microsoft Sysinternals
    • Set filters for the suspicious process identified in Event 4887
    • Compare ProcMon results with audit log timestamps
  3. Investigate process ancestry and command line arguments:
    # Get process details from Event ID 4688 (Process Creation)
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.Message -like "*ProcessId*"} | ForEach-Object {
        if ($_.Message -match "New Process ID:\s+0x([a-fA-F0-9]+)")
        {
            $ProcessId = [Convert]::ToInt32($Matches[1], 16)
            Write-Output "Process ID: $ProcessId"
        }
    }
  4. Check for persistence mechanisms in registry locations commonly accessed:
    # Monitor common persistence registry keys
    $PersistenceKeys = @(
        "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
        "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
        "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
    )
    foreach ($Key in $PersistenceKeys) {
        Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4887} | Where-Object {$_.Message -like "*$Key*"}
    }
  5. Generate incident response report with timeline analysis:
    # Create comprehensive incident timeline
    $StartTime = (Get-Date).AddDays(-1)
    $Events = @()
    $Events += Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4887; StartTime=$StartTime}
    $Events += Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=$StartTime}
    $Events += Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=$StartTime}
    $Timeline = $Events | Sort-Object TimeCreated | Select-Object TimeCreated, Id, LevelDisplayName, @{Name="Summary";Expression={($_.Message -split "\n")[0]}}
    $Timeline | Export-Csv -Path "C:\Investigation\SecurityTimeline.csv" -NoTypeInformation
Warning: During active incident response, avoid making changes to the system that could alter evidence. Consider using forensic imaging tools for detailed analysis.

Overview

Event ID 4887 fires when a Windows process requests a handle to access a system object. This security audit event is part of the Object Access category and tracks attempts to open handles to files, registry keys, processes, threads, and other kernel objects. The event captures the requesting process, target object, and access permissions requested.

This event generates frequently on active systems and provides detailed forensic information about object access patterns. Security administrators use 4887 events to track unauthorized access attempts, monitor sensitive file interactions, and investigate suspicious process behavior. The event includes the Security ID of the requesting user, process information, and the specific object being accessed.

Event 4887 requires Object Access auditing to be enabled through Group Policy. Without proper audit policy configuration, these events will not generate. The event appears in the Security log and can produce high volumes of data on busy systems, requiring careful filtering and analysis to extract meaningful security insights.

Frequently Asked Questions

What does Event ID 4887 mean and why is it important for security monitoring?+
Event ID 4887 indicates that a process has requested a handle to access a system object such as a file, registry key, or kernel object. This event is crucial for security monitoring because it provides detailed audit trails of all object access attempts, helping administrators track unauthorized access, monitor sensitive resource interactions, and investigate suspicious process behavior. The event captures the requesting user, process details, target object, and requested permissions, making it invaluable for forensic analysis and compliance auditing.
How can I reduce the volume of Event ID 4887 entries without losing important security information?+
To manage Event ID 4887 volume effectively, configure Global Object Access Auditing policies to target specific high-value objects rather than auditing all system objects. Use Group Policy to enable auditing only for critical directories, registry keys, and processes. Implement event filtering at the collection level using Windows Event Forwarding subscriptions with XPath queries. Consider using Success/Failure combinations strategically—monitor failures for unauthorized access attempts and successes only for sensitive resources. Additionally, leverage SIEM solutions with intelligent filtering to focus on anomalous patterns rather than all events.
What's the difference between Event ID 4887 and other object access events like 4656?+
Event ID 4887 specifically tracks handle requests to objects, occurring when a process asks the system for permission to access an object. Event ID 4656 (A handle to an object was requested) is actually the more common event that logs when access is granted or denied. Event ID 4658 logs when a handle is closed, and 4660 indicates an object was deleted. Event 4887 is less commonly seen and typically appears in specific audit configurations. The key difference is that 4887 focuses on the request phase, while 4656 covers the actual access grant/denial decision, making 4656 more useful for most security monitoring scenarios.
Can Event ID 4887 help detect malware or advanced persistent threats (APTs)?+
Yes, Event ID 4887 can be valuable for detecting malware and APT activities when properly analyzed. Malware often exhibits distinctive object access patterns such as accessing multiple registry persistence locations, attempting to open handles to system processes for injection, or accessing unusual file locations. APTs may show patterns like accessing sensitive documents outside normal business hours, unusual process-to-object relationships, or accessing objects that don't align with the user's typical behavior. Correlating 4887 events with process creation (4688) and logon events (4624) can reveal attack chains and lateral movement patterns. However, effective detection requires baseline understanding of normal system behavior and automated analysis tools.
What should I do if I see suspicious Event ID 4887 entries in my environment?+
When encountering suspicious Event ID 4887 entries, first isolate the affected system to prevent potential lateral movement. Document the event details including timestamp, process information, user context, and target objects. Cross-reference the suspicious process with threat intelligence databases and check for known malware signatures. Analyze the process ancestry using Event ID 4688 to understand how the suspicious process was launched. Examine network connections and file system changes around the same timeframe. Use tools like Process Monitor for real-time correlation and memory analysis tools if process injection is suspected. Implement additional monitoring on similar systems and consider engaging incident response procedures if the activity indicates a broader compromise.
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...