ANAVEM
Languagefr
Windows Security Event Viewer displaying Event ID 4670 permission change logs on a cybersecurity monitoring dashboard
Event ID 4670InformationSecurityWindows

Windows Event ID 4670 – Security: Object Permissions Changed

Event ID 4670 logs when permissions are modified on securable objects like files, folders, or registry keys. Critical for security auditing and compliance monitoring.

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

What This Event Means

Event ID 4670 represents a fundamental component of Windows security auditing infrastructure. When this event triggers, it indicates that the Discretionary Access Control List (DACL) or System Access Control List (SACL) of a securable object has been modified. The Windows Security Reference Monitor generates this event through the Local Security Authority (LSA) subsystem whenever SetSecurityInfo, SetNamedSecurityInfo, or similar security APIs are called.

The event contains rich contextual information including the Security ID (SID) of the account that made the change, the process that initiated the modification, and detailed before-and-after snapshots of the security descriptor. This granular detail makes Event ID 4670 invaluable for forensic investigations and real-time security monitoring.

In Active Directory environments, this event becomes particularly significant as it tracks permission changes on domain objects, organizational units, and group policy objects. The event integrates with Windows Event Forwarding (WEF) and can be centrally collected using tools like System Center Operations Manager or third-party SIEM solutions. Modern security operations centers (SOCs) often create automated alerts based on Event ID 4670 patterns to detect privilege escalation attempts or unauthorized administrative actions.

The event's importance has grown with the evolution of zero-trust security models and compliance requirements. Organizations implementing least-privilege access principles use Event ID 4670 data to validate that permission changes align with approved change management processes and security policies.

Applies to

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

Possible Causes

  • Administrator manually changing file or folder permissions through Properties dialog
  • PowerShell scripts using Set-Acl cmdlet or .NET security classes
  • Group Policy applying new security templates or preferences
  • Active Directory administrative tools modifying object permissions
  • Applications programmatically updating security descriptors via Windows APIs
  • Backup and restore operations that preserve or modify ACLs
  • Security software implementing real-time protection changes
  • Windows Update or system maintenance tasks adjusting system file permissions
  • Third-party management tools performing bulk permission updates
  • Malware attempting privilege escalation through permission manipulation
Resolution Methods

Troubleshooting Steps

01

Review Event Details in Event Viewer

Start by examining the specific Event ID 4670 entries to understand what permissions were changed and by whom.

  1. Open Event ViewerWindows LogsSecurity
  2. Filter for Event ID 4670 using the filter option
  3. Double-click on recent 4670 events to view detailed information
  4. Review the following key fields:
    • Subject: Account that made the change
    • Object: Target file, folder, or registry key
    • Process Information: Application that initiated the change
    • Access Request Information: Specific permissions modified
  5. Use PowerShell to query multiple events efficiently:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4670} -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-Table -Wrap

Look for patterns in timing, user accounts, or target objects that might indicate unauthorized changes.

02

Analyze Permission Changes with PowerShell

Use PowerShell to extract and analyze the permission change details from Event ID 4670 logs.

  1. Create a PowerShell script to parse Event ID 4670 details:
# Get detailed 4670 events from the last 24 hours
$Events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4670; StartTime=(Get-Date).AddDays(-1)}

foreach ($Event in $Events) {
    $XML = [xml]$Event.ToXml()
    $EventData = $XML.Event.EventData.Data
    
    Write-Host "Time: $($Event.TimeCreated)"
    Write-Host "Subject: $($EventData | Where-Object {$_.Name -eq 'SubjectUserName'} | Select-Object -ExpandProperty '#text')"
    Write-Host "Object: $($EventData | Where-Object {$_.Name -eq 'ObjectName'} | Select-Object -ExpandProperty '#text')"
    Write-Host "Process: $($EventData | Where-Object {$_.Name -eq 'ProcessName'} | Select-Object -ExpandProperty '#text')"
    Write-Host "---"
}
  1. Export results to CSV for further analysis:
$Results = @()
foreach ($Event in $Events) {
    $XML = [xml]$Event.ToXml()
    $EventData = $XML.Event.EventData.Data
    
    $Results += [PSCustomObject]@{
        TimeCreated = $Event.TimeCreated
        SubjectUser = ($EventData | Where-Object {$_.Name -eq 'SubjectUserName'}).'#text'
        ObjectName = ($EventData | Where-Object {$_.Name -eq 'ObjectName'}).'#text'
        ProcessName = ($EventData | Where-Object {$_.Name -eq 'ProcessName'}).'#text'
    }
}
$Results | Export-Csv -Path "C:\Temp\Event4670_Analysis.csv" -NoTypeInformation

This method helps identify bulk permission changes or suspicious patterns across multiple objects.

03

Configure Advanced Audit Policy Settings

Ensure proper audit policy configuration to capture all relevant permission change events.

  1. Open Group Policy Management Console or run gpedit.msc for local policy
  2. Navigate to Computer ConfigurationWindows SettingsSecurity SettingsAdvanced Audit Policy Configuration
  3. Expand Object Access and configure these policies:
    • Audit File System: Enable Success and Failure
    • Audit Registry: Enable Success and Failure
    • Audit Handle Manipulation: Enable Success
  4. Apply the policy and force an update:
gpupdate /force
  1. Verify audit settings using auditpol:
auditpol /get /category:"Object Access"
  1. For specific objects, configure SACL auditing:
# Example: Enable auditing on a specific folder
$Path = "C:\ImportantData"
$ACL = Get-Acl $Path
$AccessRule = New-Object System.Security.AccessControl.FileSystemAuditRule("Everyone", "ChangePermissions", "ContainerInherit,ObjectInherit", "None", "Success,Failure")
$ACL.SetAuditRule($AccessRule)
Set-Acl $Path $ACL
Pro tip: Enable auditing selectively on critical directories to avoid log flooding while maintaining security visibility.
04

Implement Real-time Monitoring with WEF

Set up Windows Event Forwarding to centrally monitor Event ID 4670 across your environment.

  1. Configure the collector server by enabling the Windows Event Collector service:
Start-Service Wecsvc
Set-Service Wecsvc -StartupType Automatic
  1. Create a custom subscription XML file for Event ID 4670:
<?xml version="1.0" encoding="UTF-8"?>
<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
    <SubscriptionId>PermissionChanges</SubscriptionId>
    <SubscriptionType>SourceInitiated</SubscriptionType>
    <Description>Monitor permission changes via Event ID 4670</Description>
    <Enabled>true</Enabled>
    <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
    <ConfigurationMode>Custom</ConfigurationMode>
    <Query>
        <![CDATA[
        <QueryList>
            <Query Id="0">
                <Select Path="Security">*[System[EventID=4670]]</Select>
            </Query>
        </QueryList>
        ]]>
    </Query>
</Subscription>
  1. Create the subscription using wecutil:
wecutil cs C:\Path\To\PermissionChanges.xml
  1. Configure source computers to forward events:
# Run on source computers
winrm quickconfig
wecutil qc
  1. Monitor the forwarded events log:
Get-WinEvent -LogName "ForwardedEvents" | Where-Object {$_.Id -eq 4670} | Select-Object TimeCreated, MachineName, Message

This centralized approach enables enterprise-wide monitoring of permission changes and supports automated alerting workflows.

05

Advanced Forensic Analysis and Correlation

Perform deep forensic analysis by correlating Event ID 4670 with related security events and system activities.

  1. Create a comprehensive correlation query to identify suspicious permission change patterns:
# Advanced correlation script for permission change analysis
$StartTime = (Get-Date).AddDays(-7)
$EndTime = Get-Date

# Get all permission changes (4670) and related events
$PermissionChanges = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4670; StartTime=$StartTime; EndTime=$EndTime}
$ObjectAccess = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663; StartTime=$StartTime; EndTime=$EndTime}
$LogonEvents = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625; StartTime=$StartTime; EndTime=$EndTime}

# Analyze permission changes by user
$UserActivity = @{}
foreach ($Event in $PermissionChanges) {
    $XML = [xml]$Event.ToXml()
    $User = ($XML.Event.EventData.Data | Where-Object {$_.Name -eq 'SubjectUserName'}).'#text'
    $Object = ($XML.Event.EventData.Data | Where-Object {$_.Name -eq 'ObjectName'}).'#text'
    
    if (-not $UserActivity[$User]) {
        $UserActivity[$User] = @()
    }
    $UserActivity[$User] += @{
        Time = $Event.TimeCreated
        Object = $Object
        EventId = $Event.Id
    }
}

# Identify users with excessive permission changes
$SuspiciousUsers = $UserActivity.GetEnumerator() | Where-Object {$_.Value.Count -gt 10} | Sort-Object {$_.Value.Count} -Descending
Write-Host "Users with high permission change activity:"
$SuspiciousUsers | ForEach-Object { Write-Host "$($_.Key): $($_.Value.Count) changes" }
  1. Check for permission changes followed by immediate object access:
# Correlate permission changes with subsequent access attempts
foreach ($PermChange in $PermissionChanges) {
    $ChangeTime = $PermChange.TimeCreated
    $XML = [xml]$PermChange.ToXml()
    $ObjectName = ($XML.Event.EventData.Data | Where-Object {$_.Name -eq 'ObjectName'}).'#text'
    
    # Look for access attempts within 5 minutes after permission change
    $RelatedAccess = $ObjectAccess | Where-Object {
        $_.TimeCreated -gt $ChangeTime -and 
        $_.TimeCreated -lt $ChangeTime.AddMinutes(5) -and
        $_.Message -like "*$ObjectName*"
    }
    
    if ($RelatedAccess) {
        Write-Host "Potential privilege escalation detected:"
        Write-Host "Permission changed: $ChangeTime on $ObjectName"
        Write-Host "Followed by access attempts: $($RelatedAccess.Count)"
    }
}
  1. Generate a comprehensive security report:
# Create detailed forensic report
$Report = @"
SECURITY ANALYSIS REPORT - EVENT ID 4670
Generated: $(Get-Date)

SUMMARY:
Total Permission Changes: $($PermissionChanges.Count)
Unique Users Involved: $($UserActivity.Keys.Count)
Time Range: $StartTime to $EndTime

TOP ACTIVE USERS:
$($SuspiciousUsers | ForEach-Object { "$($_.Key): $($_.Value.Count) changes" } | Out-String)

RECOMMENDATIONS:
1. Review accounts with high activity levels
2. Validate business justification for bulk changes
3. Implement additional monitoring for flagged users
4. Consider implementing approval workflows for sensitive objects
"@

$Report | Out-File -FilePath "C:\Temp\Security_Analysis_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt"
Warning: This advanced analysis can be resource-intensive on systems with high event volumes. Run during maintenance windows or limit the time range for initial testing.

Overview

Event ID 4670 fires whenever permissions are changed on a securable object in Windows. This includes modifications to Access Control Lists (ACLs) on files, folders, registry keys, Active Directory objects, and other Windows security principals. The event captures who made the change, what object was modified, and the nature of the permission alteration.

This event is part of Windows advanced security auditing and requires Object Access auditing to be enabled through Group Policy. It's essential for compliance frameworks like SOX, HIPAA, and PCI-DSS that mandate tracking permission changes. The event appears in the Security log and provides detailed information about the subject (user or process) that initiated the change, the target object, and the specific permissions that were modified.

Security teams rely on Event ID 4670 to detect unauthorized permission escalations, insider threats, and compliance violations. The event works in conjunction with other security events like 4663 (object access attempts) and 4656 (handle requests) to provide comprehensive object access monitoring. Understanding this event is crucial for maintaining proper security posture in enterprise environments.

Frequently Asked Questions

What does Event ID 4670 mean and why is it important?+
Event ID 4670 indicates that permissions have been changed on a securable object in Windows, such as files, folders, registry keys, or Active Directory objects. This event is crucial for security monitoring because it tracks who modified permissions, when the change occurred, and what object was affected. It's essential for compliance auditing, detecting privilege escalation attempts, and maintaining proper access controls in enterprise environments. The event provides detailed information including the user account that made the change, the process that initiated it, and the specific permissions that were modified.
How do I enable Event ID 4670 logging if it's not appearing in my Security log?+
Event ID 4670 requires Object Access auditing to be enabled through Group Policy. Navigate to Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Object Access, then enable 'Audit File System' and 'Audit Registry' for both Success and Failure events. Additionally, you must configure System Access Control Lists (SACLs) on the specific objects you want to monitor. Use the Security tab in file/folder properties, click Advanced, then Auditing to add audit entries. After configuration, run 'gpupdate /force' to apply the policy immediately.
Can Event ID 4670 help detect malware or unauthorized access attempts?+
Yes, Event ID 4670 is valuable for detecting malicious activity. Malware often attempts to modify permissions to gain access to protected files or hide its presence. Look for patterns such as: permission changes on system files by non-administrative users, bulk permission modifications in short time periods, changes to security-sensitive registry keys, or permission modifications followed immediately by file access attempts. Correlating Event ID 4670 with other security events like 4663 (object access) and 4656 (handle requests) can reveal sophisticated attack patterns and privilege escalation attempts.
What's the difference between Event ID 4670 and other object access events like 4663?+
Event ID 4670 specifically tracks permission changes to objects, while Event ID 4663 logs actual access attempts to objects. Event 4670 fires when someone modifies the Access Control List (ACL) of a file, folder, or registry key using tools like icacls, Set-Acl, or the Properties dialog. Event 4663 triggers when someone tries to read, write, or execute an object. Event 4656 logs handle requests to objects. Together, these events provide comprehensive object access monitoring: 4656 shows access requests, 4663 shows successful access, and 4670 shows permission modifications. Understanding this relationship is crucial for effective security monitoring and forensic analysis.
How can I reduce Event ID 4670 log volume while maintaining security visibility?+
To manage Event ID 4670 volume effectively, implement selective auditing strategies. First, enable auditing only on critical directories and registry keys rather than system-wide. Use Group Policy to configure specific SACL entries for sensitive folders like user data, application directories, and system configuration paths. Consider filtering out routine system processes by excluding known administrative tools from auditing. Implement log forwarding to centralize events and use automated analysis tools to identify patterns rather than reviewing individual events. Set up retention policies to archive older events while keeping recent data accessible. Finally, create custom views in Event Viewer to focus on high-priority permission changes and filter out routine maintenance activities.
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...