Permissions are a quiet control. When they are tight, an intruder who lands as a low privilege user hits a wall. So the next move is often to change the permissions. MITRE ATT&CK tracks that as T1222, File and Directory Permissions Modification. It sits in the Defense Impairment tactic and covers ESXi, Linux, macOS and Windows. It has two sub-techniques in the matrix, one for Windows and one for Linux and Mac.
How attackers use it
MITRE explains that adversaries may modify file or directory permissions and attributes to evade access control lists (ACLs) and reach protected files. ACLs are normally set by the owner of the file or directory, or by users with the right permissions. They name which users or groups may read, write, execute and so on. The details vary by platform.
Modifications may involve changing specific access rights, which can require taking ownership of the object or having elevated permissions already. Once changed, that may allow modification, replacement or deletion of specific files and directories.
This step often supports something bigger. MITRE says file and directory changes may be required for many techniques, for example persistence through accessibility features, boot or logon initialization scripts, Unix shell configuration modification, or tainting and hijacking binaries and configuration files through Hijack Execution Flow.
Adversaries may also change permissions of symbolic links. MITRE notes that malware, ransomware in particular, may modify symbolic links and related settings so that files can be reached from local shortcuts that point to remote paths.
Why it matters even when it looks small
A single permission change rarely stands out. It is often the middle step of a chain: gain access, loosen a file, replace the file, run it. That is why detection leans on correlation rather than on one event.
How to detect it
The MITRE strategy gives a behavioral chain for each platform.
Windows: process creation of permission changing utilities such as icacls, takeown, attrib and cacls, an unusual user context or timing, DACL modification events, and then file access that suggests the change worked.
Linux: execution of chmod, chown or setfacl with suspicious parameters, targeting of critical system files or unusual permission values, a non-privileged user context or odd timing, and follow-on file access.
macOS: chmod, chown or chflags execution, attempts to bypass System Integrity Protection, extended attribute changes, and log correlation with file system events.
ESXi: SSH access to the host, then chmod or chown on datastore files or system configuration, and changes to VM configuration files.
What to collect:
- Process creation with command lines for the utilities above.
- File system audit events. On Windows, those are Security events 4670 (permissions changed) and 4663 (object access). On Linux, auditd rules on sensitive paths.
- Authentication logs for the session that ran the change.
- For ESXi, host shell and SSH logs.
Tuning
Your own installers and configuration management tools change permissions all the time. Record their accounts and paths, and exclude them. Everything else near sensitive locations is worth a look: system binaries, startup folders, shell profiles, service definitions and the accessibility feature binaries on Windows.
How to reduce the risk
MITRE lists two mitigations.
- Restrict file and directory permissions. More restrictive permissions can prevent adversaries from changing their own access. Make sure user settings for local and remote symbolic links are properly set, or disabled where unneeded.
- Privileged account management. Make sure critical system files, and files known to be abused, have restrictive permissions and are owned by an appropriately privileged account, especially if users do not need access and system function will not be inhibited.
To make that concrete:
- List the files and folders that attackers commonly target, such as startup scripts and system binaries, and check their ownership and access.
- Remove write access for standard users wherever it is not needed.
- Limit who can take ownership of objects.
- Check symbolic link settings on Windows hosts.
Check your own environment
On Linux, this read-only command lists the audit rules loaded:
sudo auditctl -l
On Linux, this read-only command shows the permissions of a sensitive path. Replace the path with the one you care about:
ls -ld /etc/profile.d /etc/cron.d /etc/sudoers.d
On Windows, this read-only command (cmd.exe) shows the access control list of a system folder:
icacls C:\Windows\System32\drivers\etc
Questions to ask:
- Which standard user accounts can write to startup locations?
- Do you audit permission changes on sensitive paths, or only access?
- Are ESXi hosts logging SSH sessions and file changes?
- Can you tell your configuration management activity apart from manual changes?
What good looks like
A good setup watches a short list of sensitive paths closely rather than every file. Permission changes there produce an event with the user, the process and the command line. Standard users cannot write to those paths in the first place. Configuration management is known and excluded, so manual changes stand out. And on ESXi hosts, SSH access is logged and reviewed like any other administrative session.
Quick check
Why do attackers change permissions?
To reach files they should not, which allows them to modify, replace or delete them. It is often a stepping stone for persistence or for hijacking binaries and configuration.
Which Windows events help detect DACL changes?
Security event 4670 for permission changes and event 4663 for object access, as referenced in the MITRE detection strategy for the Windows sub-technique.
Why does MITRE mention symbolic links?
Malware, especially ransomware, may modify symbolic links and related settings so files can be reached through local shortcuts to remote paths.
Sources
- MITRE ATT&CK, T1222: https://attack.mitre.org/techniques/T1222
