Event 4670: Permissions on an object were changed.
Quick Answer
Event 4670 is generated when permissions on an object (file, registry key, service) are modified, logging security descriptor changes. This event is crucial for detecting privilege escalation, defense evasion through permission modifications, and persistence mechanisms where attackers grant themselves access to system resources or weaken security controls.
Technical Details
Event ID: 4670
Windows Security- Policy Change
Event Description
Permissions on an object were changed.
Key Log Fields
SubjectUserName- Account that changed permissionsSubjectDomainName- Domain of the accountSubjectLogonId- Logon ID for correlationObjectServer- Subsystem (e.g., Security)ObjectType- Type of objectObjectName- Name or path of the objectHandleId- Handle ID for correlationProcessName- Process that changed permissionsProcessId- Process IDOldSd- Previous security descriptor (SDDL format)NewSd- New security descriptor (SDDL format)
MITRE ATT&CK® Mapping (3)
Adversaries may modify file or directory permissions/attributes to evade access control lists (ACLs) and access protected files.(Citation: Hybrid Analysis Icacls1 June 2018)(Citation: Hybrid Analysis Icacls2 May 2018) File and directory permissions are commonly managed by ACLs configured by the file or directory owner, or users with the appropriate permissions. File and directory ACL implementations vary by platform, but generally explicitly designate which users or groups can perform which actions (read, write, execute, etc.). Modifications may include changing specific access rights, which may require taking ownership of a file or directory and/or elevated permissions depending on the file or directory’s existing permissions. This may enable malicious activity such as modifying, replacing, or deleting specific files or directories. Specific file and directory modifications may be a required step for many techniques, such as establishing Persistence via [Accessibility Features](https://attack.mitre.org/techniques/T1546/008), [Boot or Logon Initialization Scripts](https://attack.mitre.org/techniques/T1037), [Unix Shell Configuration Modification](https://attack.mitre.org/techniques/T1546/004), or tainting/hijacking other instrumental binary/configuration files via [Hijack Execution Flow](https://attack.mitre.org/techniques/T1574). Adversaries may also change permissions of symbolic links. For example, malware (particularly ransomware) may modify symbolic links and associated settings to enable access to files from local shortcuts with remote paths.(Citation: new_rust_based_ransomware)(Citation: bad_luck_blackcat)(Citation: falconoverwatch_blackcat_attack)(Citation: blackmatter_blackcat)(Citation: fsutil_behavior)
Adversaries may modify file or directory permissions/attributes to evade access control lists (ACLs) and access protected files.(Citation: Hybrid Analysis Icacls1 June 2018)(Citation: Hybrid Analysis Icacls2 May 2018) File and directory permissions are commonly managed by ACLs configured by the file or directory owner, or users with the appropriate permissions. File and directory ACL implementations vary by platform, but generally explicitly designate which users or groups can perform which actions (read, write, execute, etc.). Windows implements file and directory ACLs as Discretionary Access Control Lists (DACLs).(Citation: Microsoft DACL May 2018) Similar to a standard ACL, DACLs identifies the accounts that are allowed or denied access to a securable object. When an attempt is made to access a securable object, the system checks the access control entries in the DACL in order. If a matching entry is found, access to the object is granted. Otherwise, access is denied.(Citation: Microsoft Access Control Lists May 2018) Adversaries can interact with the DACLs using built-in Windows commands, such as `icacls`, `cacls`, `takeown`, and `attrib`, which can grant adversaries higher permissions on specific files and folders. Further, [PowerShell](https://attack.mitre.org/techniques/T1059/001) provides cmdlets that can be used to retrieve or modify file and directory DACLs. Specific file and directory modifications may be a required step for many techniques, such as establishing Persistence via [Accessibility Features](https://attack.mitre.org/techniques/T1546/008), [Boot or Logon Initialization Scripts](https://attack.mitre.org/techniques/T1037), or tainting/hijacking other instrumental binary/configuration files via [Hijack Execution Flow](https://attack.mitre.org/techniques/T1574).
Adversaries may modify file or directory permissions/attributes to evade access control lists (ACLs) and access protected files.(Citation: Hybrid Analysis Icacls1 June 2018)(Citation: Hybrid Analysis Icacls2 May 2018) File and directory permissions are commonly managed by ACLs configured by the file or directory owner, or users with the appropriate permissions. File and directory ACL implementations vary by platform, but generally explicitly designate which users or groups can perform which actions (read, write, execute, etc.). Most Linux and Linux-based platforms provide a standard set of permission groups (user, group, and other) and a standard set of permissions (read, write, and execute) that are applied to each group. While nuances of each platform’s permissions implementation may vary, most of the platforms provide two primary commands used to manipulate file and directory ACLs: <code>chown</code> (short for change owner), and <code>chmod</code> (short for change mode). Adversarial may use these commands to make themselves the owner of files and directories or change the mode if current permissions allow it. They could subsequently lock others out of the file. Specific file and directory modifications may be a required step for many techniques, such as establishing Persistence via [Unix Shell Configuration Modification](https://attack.mitre.org/techniques/T1546/004) or tainting/hijacking other instrumental binary/configuration files via [Hijack Execution Flow](https://attack.mitre.org/techniques/T1574).(Citation: 20 macOS Common Tools and Techniques)
Event Comparison
Event 4670 tracks permission/ownership changes, while Event 4663 monitors object access and Event 4657 tracks registry value modifications. Enable all three for comprehensive object auditing and modification detection.
What This Event Means
Event 4670 provides visibility into permission and ownership changes on critical system objects, which attackers frequently modify during privilege escalation and persistence establishment. When an attacker gains initial access with limited privileges, modifying permissions on system files, registry keys, or services enables them to execute code with elevated privileges or maintain persistent access. This event captures the object being modified, the account making the change, and the old and new security descriptors (DACLs/SACLs). Common attack patterns include granting full control to user accounts on system binaries, weakening permissions on registry autorun keys, or modifying service ACLs to allow non-administrative accounts to modify service configurations. Security teams should monitor permission changes on critical system paths, startup folders, and security-sensitive registry keys.
Security Implications
- Privilege escalation through permission modifications on system files allowing malware execution with SYSTEM privileges
- Defense evasion by weakening SACL audit settings to prevent logging of malicious activity
- Persistence establishment through permission changes on autorun registry keys or startup folders
- Tampering with security software by modifying permissions on antivirus installation directories
- APT groups frequently modify permissions on legitimate system utilities to enable Living off the Land (LotL) techniques
Detection Strategies
Enable Event 4670 auditing for critical system paths including Windows\System32, Program Files directories, and all registry Run/RunOnce keys. Alert on permission modifications to any files in system directories by non-SYSTEM accounts. Monitor changes to SACL audit settings which may indicate attackers attempting to disable logging. Track permission modifications during off-hours or from unexpected user accounts. Correlate Event 4670 with Event 4688 (process creation) to identify which processes are modifying permissions. Alert on permission changes to security software installation paths, Windows Defender directories, or SIEM agent folders. Monitor registry permission modifications on security-critical keys like HKLM\SYSTEM\CurrentControlSet\Services.
Note: Comprehensive SIEM detection queries for Splunk SPL, Microsoft KQL, and Elastic Query DSL will be added in future updates.
Real-World Attack Examples
APT privilege escalation: Attackers modified permissions on legitimate Windows utility (certutil.exe) to allow modification, replaced it with malicious version, restored permissions to evade detection
Ransomware defense evasion: Before encryption, ransomware modified SACL permissions on all target directories to disable audit logging and prevent forensic analysis
Persistence establishment: Attackers granted user account full control over HKLM\Software\Microsoft\Windows\CurrentVersion\Run registry key, allowing persistence without administrative rights
Security software tampering: Malware modified permissions on antivirus service executable directory, enabling replacement with dummy executable to disable protection