MITRE ATT&CK T1222 File and Directory Permissions Modification: Detecting Control Tampering

Before ransomware can encrypt a protected folder, before a miner can lock its binary against cleanup and before a wiper can overwrite system files, the adversary usually has to change who is allowed to touch them. MITRE ATT&CK T1222 File and Directory Permissions Modification covers changing file or directory permissions and attributes to get past access control lists, take ownership or lock defenders out. In ATT&CK v20 it sits in the Defense Impairment tactic (TA0112) and applies to Windows, Linux, macOS and ESXi, with two sub-techniques: T1222.001 Windows Permissions and T1222.002 Linux and Mac Permissions, each covered on its own page. This guide is the technique-level view: how the change shows up in real intrusions, the v20 detection strategy across four platforms, the two ATT&CK mitigations and the identity controls that decide who can make the change at all. It is for detection engineers, SOC analysts and platform owners. Permission changes as a precursor to encryption are covered briefly in the MITRE ATT&CK T1486 Data Encrypted for Impact guide; this page goes deeper on the permission change itself.

Key takeaways

• It is an enabler, not an end. ATT&CK notes permission changes are often a required step for persistence, encryption, destruction and hijacking techniques, so a detected change is an early warning for what follows.
• Grant-everyone is the loudest pattern. Ryuk and WannaCry both granted Everyone full control recursively; a broad grant across many paths in seconds is rarely administrative.
• Windows needs a SACL to see it. Event ID 4670 is only generated when the object's SACL audits Change Permissions or Take Ownership, so most estates are blind by default.
• Locking defenders out is a variant. TeamTNT used chattr and Rocke changed permissions so files could not be modified; Grandoreiro modified a binary ACL to stop security tools running.
• Who holds WRITE_DAC matters more than the tool. Restrict ownership and change-permission rights on critical paths to a few privileged accounts, and watch those accounts.

How the technique works

ATT&CK describes ACLs, set by the owner or by users with the right permissions, as defining which users or groups can act on a file or directory. Adversaries change specific access rights, which may first require taking ownership or elevated rights, to modify, replace or delete files they could not touch before. ATT&CK also notes that malware, particularly ransomware, may modify symbolic link settings so that local shortcuts can reach remote paths.

On Linux, the man page for chattr documents that the immutable (i) attribute stops a file being changed, deleted, renamed or linked, and the append-only (a) attribute allows only appending; setting or clearing either needs root or the CAP_LINUX_IMMUTABLE capability. Adversaries use this in two directions: to protect their own files from defenders, and, by clearing it, to remove a protection defenders set.

How adversaries use it: cases from ATT&CK v20

The Wizard Spider case shows the identity side clearly: once an operator holds domain admin, icacls on backup servers is a single step that turns a protected backup estate into one the operator fully controls. Storm-1811 used cacls through batch scripts, per ATT&CK's citation of Rapid7. For the group context, see the Ransomware Prevention Guide.

What to detect and where

ATT&CK v20 maps DET0299 Multi-Platform File and Directory Permissions Modification Detection Strategy with four analytics. Each describes a chain: a permission utility runs, the context is unusual, the permissions on a sensitive path change, and access to that path follows.

Windows: making Event ID 4670 useful

Microsoft documents that Event ID 4670 "Permissions on an object were changed" is generated only when the object's SACL includes Change Permissions or Take Ownership for file system objects, under the Audit File System subcategory. The event records the account, the process name and ID, and the old and new security descriptors in SDDL, so a grant of full access to Everyone shows as an added (A;OICI;FA;;;WD) entry. Microsoft recommends alerting when the process name is not the expected one, when it runs from a non-standard location, and monitoring all 4670 events on high-value objects such as ntds.dit on domain controllers.

1. Choose the paths: backup repositories, ntds.dit and SYSVOL on domain controllers, security tool install folders, application binaries and file shares holding critical data.
2. Set SACLs only there: audit Change Permissions and Take Ownership for Everyone on those paths. Auditing whole volumes creates volume without value.
3. Enable the subcategory: Audit File System (Success) in Advanced Audit Policy, through Group Policy, on the hosts that hold those paths.
4. Correlate: 4688 for icacls, takeown or cacls with recursive or grant arguments, then 4670 on a monitored path, then 4663 access or Sysmon 11 file creation by the same logon ID.

Linux, macOS and ESXi

• Linux: add auditd rules for the chmod, chown and setxattr syscall families scoped to sensitive directories (/etc, /usr/bin, /usr/sbin, application and backup paths). Flag mode 777, setuid bits on new files, and chattr changes by unexpected accounts. See the Linux Logging and auditd for Defenders Guide.
• macOS: watch for chmod +x on files in /tmp, /Users/Shared and Downloads followed by execution; ATT&CK lists Dok, XCSSET, Bundlore and OSX/Shlayer doing exactly this.
• ESXi: SSH sessions to hosts are themselves worth alerting on; any chmod or chown on datastore paths in the shell log should be reviewed. See the ESXi Logs Detection Guide.
• File integrity monitoring: FIM tools that record permission and ownership changes, not only content hashes, give a second source. See the File Integrity Monitoring Guide.

Mitigations

See M1022 Restrict File and Directory Permissions and M1026 Privileged Account Management for the mitigation pages.

Where identity fits

Changing a DACL needs ownership or WRITE_DAC; taking ownership needs the take ownership right or the SeTakeOwnershipPrivilege that administrators hold. So the question that decides blast radius is which identities hold those rights on which paths. Three groups of non-human identities deserve attention:

• Backup service accounts: they often have read access everywhere and sometimes owner rights on repositories. The Wizard Spider case shows why repositories need their own identity boundary. See the Backup Identity Isolation Guide.
• Deployment and configuration management accounts: agents that run as SYSTEM or root and push files can also change permissions fleet-wide; their actions should come from known pipelines only.
• Application service accounts: an account that owns its own binaries can make them writable; separate the runtime identity from the identity that owns the install path.

Domain-level ACL hygiene, which governs who can change permissions on directory objects rather than files, is covered in the Active Directory ACL and Delegation Hygiene Guide.

Rolling out detection and hardening

1. Pick ten to twenty critical paths per platform and record their intended owner and ACL as a baseline.
2. Turn on auditing in pilot: SACLs and Audit File System on a few servers, auditd rules on a few Linux hosts. Measure volume for two weeks.
3. Write the chain rules: utility execution plus permission change on a baseline path plus follow-on access. Start in alert-only mode, tune out patching and installer processes by signed parent.
4. Harden the paths: remove broad write and change-permission rights, set owners to administrative groups, and on Linux consider chattr +i for static configuration that should never change outside maintenance.
5. Extend to all hosts in rings, using Group Policy or configuration management so the setting can be reverted per ring.
6. Rollback: keep exported ACLs (icacls /save on Windows, getfacl on Linux) for each hardened path so a broken application can be restored exactly.

How to test

• Windows: on a lab copy of a monitored path, grant a test group read access with icacls and confirm 4688, 4670 with old and new SDDL, and the correlated alert.
• Linux: chmod a test file in a monitored directory and confirm the auditd SYSCALL and PROCTITLE records reach the SIEM.
• ESXi: in a lab host, confirm that SSH enablement and a chmod on a test datastore file appear in the shell log feed.
• Emulation: ATT&CK procedure examples above give realistic test cases; use authorised test files only and reverse every change from the saved ACL.

Measuring it

• Audit coverage: percentage of critical paths with a SACL or auditd rule that records permission and ownership changes.
• Baseline drift: number of permission changes on baseline paths per month, each with a change ticket or an investigation.
• Broad grants: count of Everyone, Authenticated Users or mode 777 grants found on critical paths (target zero).
• Owner hygiene: percentage of critical paths owned by an administrative group rather than an individual or service account.
• Time to alert: median time from a test permission change to SOC alert.

Common failure patterns

• Audit policy on, SACLs missing: Audit File System is enabled, but no SACL audits Change Permissions, so 4670 never fires.
• Auditing everything: SACLs on whole volumes flood the SIEM and the rule is disabled within a week.
• Trusting signed tools: icacls, takeown and chmod are system binaries, so allowlisting by signer alone misses the technique. Context and target path decide.
• Backup repositories in the main domain: a domain admin can take ownership of backup data, as the Wizard Spider case shows.
• Ignoring ESXi shells: the hypervisor is where Black Basta's chmod step happens, and the shell log is often not collected.

Framework mapping

Practitioner checklist

• List critical paths per platform and save their baseline owner and ACL.
• Set SACLs for Change Permissions and Take Ownership on those paths and enable Audit File System.
• Add auditd rules for chmod, chown and setxattr syscalls on critical Linux paths.
• Collect the ESXi shell and hostd logs and alert on SSH enablement.
• Correlate utility execution, permission change and follow-on access by logon or session ID.
• Remove broad grants and WRITE_DAC for non-administrative groups on critical paths.
• Make administrative groups, not individuals or service accounts, the owners of critical paths.
• Isolate backup repository permissions from the production domain's administrators.

Standards and references

• MITRE ATT&CK: T1222 File and Directory Permissions Modification
• MITRE ATT&CK: T1222.001 Windows Permissions
• MITRE ATT&CK: T1222.002 Linux and Mac Permissions
• Microsoft Learn: Event 4670, permissions on an object were changed
• Linux man-pages: chattr(1)
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: ATT&CK Stealth and Defense Impairment Tactics Guide · MITRE ATT&CK T1486 Data Encrypted for Impact · T1685 Disable or Modify Tools Defensive Guide · File Integrity Monitoring Guide · Backup Identity Isolation Guide