Has used cacls.exe via batch script to modify file and directory permissions in victim environments.1
Windows Permissions T1222.001
- Tactic
- Defense Impairment
- Platform
- Windows
- Version
- 2.0
- Created
- 04 February 2020
- Last modified
- 12 May 2026
Adversaries may modify file or directory permissions/attributes to evade access control lists (ACLs) and access protected files.[1][2] 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 Permissions MITRE reference T1222.001
2 groups have been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
Has used the icacls command to modify access control to backup servers, providing them with full control of all the system folders.1
All 2 groups for this technique
10 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
Can be used to display, set, or clear attributes of a disk or volume.1
Uses the mountvol.exe command to mount volume names and leverages the Microsoft Discretionary Access Control List tool, icacls.exe, to grant the group to “Everyone” full access to the root of the drive.1
Can use Windows commands such as fsutil behavior set SymLinkEvaluation R2L:1 to redirect file system access to a different location after gaining access into compromised networks.1
Can modify ACL entries to take ownership of files.1
Has a command to take ownership of a file and reset the ACL permissions using the takeown.exe /F filepath command.1
Can use icacls /reset and takeown /F to reset a targeted executable's permissions and then take ownership.1
All 10 software entries for this technique · 6 newest in this preview
Offense vs defense T1222.001
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Windows Permissions detection strategy DET0418
MITRE names one behaviour worth catching for this technique and breaks it into 1 analytic, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Windows DACL Manipulation Behavioral Chain Detection Strategy
AN1177 · Windows
Multi-stage Windows DACL manipulation behavioral chain: (1) Process creation of permission-modifying utilities (icacls.exe, takeown.exe, attrib.exe, cacls.exe) or PowerShell ACL cmdlets, (2) Command-line analysis revealing privilege escalation intent through suspicious parameters (/grant, /takeown, /T, Set-Acl), (3) DACL modification events (4670) correlating with process execution, (4) Subsequent file access attempts (4663) indicating successful permission bypass, (5) Potential follow-on persistence or lateral movement activities
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| WMI CreationDC0008 | WinEventLog:WMI | EventCode=5857, 5858, 5860, 5861 |
| Process CreationDC0032 | WinEventLog:Security | EventCode=4688 |
| File CreationDC0039 | WinEventLog:Sysmon | EventCode=11 |
| File MetadataDC0059 | WinEventLog:Security | EventCode=4663, 4656, 4658 |
| Command ExecutionDC0064 | WinEventLog:PowerShell | EventCode=4103, 4104, 4105, 4106 |
| Active Directory Object ModificationDC0066 | WinEventLog:Security | EventCode=4663, 4670, 4656 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| TemporalCorrelationWindow | Time window for correlating process creation (4688/sysmon 1) with DACL changes (4670) and subsequent access (4663) - default 300 seconds, adjust based on system performance and network latency |
| SensitivePathWhitelist | Environment-specific critical directories requiring enhanced monitoring (e.g., C:\Windows\System32, C:\Program Files, %USERPROFILE%\AppData) - customize per organizational security requirements |
| AuthorizedAdministratorAccounts | User accounts and service accounts authorized to perform legitimate DACL modifications - update to reflect current administrative staff and automated processes |
| SuspiciousCommandLinePatterns | Regex patterns for detecting malicious intent in permission modification commands - tune to reduce false positives while maintaining detection efficacy |
| BusinessHoursThreshold | Time-based risk scoring modifier for permission changes occurring outside standard business hours - adjust based on organizational work patterns |
| PowerShellScriptBlockSizeThreshold | Minimum PowerShell script block size for ACL-related content analysis - balance between detection coverage and log volume |
| FileAccessFrequencyBaseline | Statistical baseline for normal file access patterns post-permission change - establish through historical analysis and update periodically |
| WMIMethodInvocationWhitelist | Approved WMI classes and methods for legitimate permission operations (e.g., Win32_SecurityDescriptor) - maintain based on authorized management tools |
Adversaries sometimes modify object access rights at the operating system level. There are varying motivations behind this action - they may not want some files/objects to be changed on systems for persistence reasons and therefore provide admin only rights; also, they may want files to be accessible with lower levels of permissions.
D3FEND techniques
The defensive countermeasure this analytic implements, in MITRE’s D3FEND ontology.
| ID | Name |
|---|---|
| D3-SFA | System File Analysis |
Implementations
Pseudocode is the canonical logic; the rest are CAR’s translations into vendor query languages.
Windows environment logs can be noisy, so we take the following into consideration: * We need to exclude events generated by the local system (subject security ID "NT AUTHORITY\SYSTEM") and focus on actual user events. * When a permission modification is made for a folder, a new event log is generated for each subfolder and file under that folder. It is advised to group logs based on handle ID or user ID. * The Windows security log (event ID 4670) also includes information about the process that modifies the file permissions. It is advised to focus on uncommon process names, and it is also uncommon for real-users to perform this task without a GUI.
log_name == "Security" AND event_code == "4670" AND object_type == "File" AND subject_security_id != "NT AUTHORITY\SYSTEM"
This looks for any invocations of chmod. Note that this is likely to be more noisy than the Windows-specific implementation, although Linux does not generate logs for system triggered activities like in Windows. In addition, it may be necessary to whitelist cron jobs that regularly run and execute chmod.
processes = search Process:Create chmod_processes = filter processes where command_line == "chmod *" output chmod_processes
Splunk version of the above pseudocode.
index=__your_windows_security_log_index__ EventCode=4670 Object_Type="File" Security_ID!="NT AUTHORITY\\SYSTEM"
LogPoint version of the above pseudocode for Windows.
norm_id=WindowsSysmon channel="Security" event_id=4670 object_type="File" -user_id="S-1-5-18"
Unit tests
CAR’s own validation procedures for this analytic.
For Windows - right click on any file and change its permissions under properties. Or, execute the following command: `icacls "C:\<fileName>" /grant :F`
For Linux - execute the following command: `chmod 777 "fileName"`
Ensure critical system files as well as those known to be abused by adversaries have restrictive permissions and are owned by an appropriately privileged account, especially if access is not required by users nor will inhibit system functionality.
Applying more restrictive permissions to files and directories could prevent adversaries from modifying the access control lists.
Tests from Atomic Red Team (MIT licence) · technique definition