Permission changes are routine on Unix systems, which is exactly why attackers use them. MITRE ATT&CK T1222.002, Linux and Mac Permissions, covers adversaries who modify file or directory permissions and attributes to get around access controls and reach protected files. It sits under the defense impairment tactic and applies to Linux and macOS.
How attackers use it
Most Linux platforms use the same model: user, group and other, each with read, write and execute bits. Two commands manage almost all of it, chown to change the owner and chmod to change the mode.
MITRE describes adversaries using these commands to make themselves the owner of files and directories, or to change the mode when current permissions allow it. They can then lock other users out of a file.
The change is rarely the goal. It is usually a step toward something else. MITRE points to persistence through Unix shell configuration modification, and to tainting or hijacking binaries and configuration files that other processes rely on. If an attacker can write to a file that a privileged process reads, the permission change is what makes that possible.
How to detect it
MITRE's detection strategy looks for a chain of behavior rather than one event.
On Linux, watch for:
chmod,chown,chgrpandsetfaclrun with arguments that suggest privilege escalation- system calls that change file metadata, such as chmod, fchmod, chown and fchown
- ACL or extended attribute changes on critical system paths
- later access or execution from the files that were just modified
- permission states that drift from a known baseline
On macOS, add:
chflagsuse, since immutable and hidden flags can support evasion or persistence- attempts to bypass System Integrity Protection through permission changes
- extended attribute (xattr) changes that touch security metadata
- Gatekeeper or code signing bypasses done through attribute changes
MITRE does not name specific log sources or rules for this technique, so map these behaviors to what you already collect: audit logging of metadata system calls, endpoint process telemetry and, on macOS, the unified log.
How to reduce the risk
MITRE lists two mitigations.
- Restrict file and directory permissions. Tighter permissions leave less room to modify access control lists in the first place.
- Manage privileged accounts. Make sure critical system files, and files attackers are known to abuse, have restrictive permissions and belong to an appropriately privileged account, especially where users do not need access and system function will not suffer.
In practice, that means keeping a baseline of expected permissions on shell startup files, cron locations, service definitions and binaries in system paths, then alerting on drift.
Check your own environment
These are read-only checks for Linux or macOS in a shell.
# World-writable files under /etc (Linux or macOS, review the output)
find /etc -xdev -type f -perm -0002 2>/dev/null
# Who owns system shell startup files
ls -l /etc/profile /etc/bashrc /etc/zshrc 2>/dev/null
# Show ACLs on a sensitive directory (Linux, needs the acl package)
getfacl /etc/cron.d
Anything world-writable in a system path deserves an explanation.
Quick check
Which two commands does MITRE name as the main way to change file ownership and mode?
chown changes the owner and chmod changes the mode.
Why is a permission change often a stepping stone rather than the goal?
It can enable other techniques, such as persistence through shell configuration files or hijacking binaries and configuration files that other processes depend on.
