T1222.002 · threatengine.sh

Home/ATT&CK Technique/Linux and Mac Permissions

ATT&CK Technique

Linux and Mac Permissions

T1222.002 · defense-impairment

Adversaries may modify file or directory permissions/attributes to evade access control lists (ACLs) and access protected files. 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: chown (short for change owner), and chmod (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 or tainting/hijacking other instrumental binary/configuration files via Hijack Execution Flow.

LinuxmacOS

◆

Actors Using This

1

chinaVolt Typhoon

▸

Atomic Tests

14

Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.

shlinux, macoschmod - Change file or folder mode (numeric mode)

Changes a file or folder's permissions using chmod and a specified numeric mode.

chmod #{numeric_mode} #{file_or_folder}

shlinux, macoschmod - Change file or folder mode (symbolic mode)

Changes a file or folder's permissions using chmod and a specified symbolic mode.

chmod #{symbolic_mode} #{file_or_folder}

shlinux, macoschmod - Change file or folder mode (numeric mode) recursively

Changes a file or folder's permissions recursively using chmod and a specified numeric mode.

chmod -R #{numeric_mode} #{file_or_folder}

bashlinux, macoschmod - Change file or folder mode (symbolic mode) recursively

Changes a file or folder's permissions recursively using chmod and a specified symbolic mode.

chmod -R #{symbolic_mode} #{file_or_folder}

bashmacos, linuxchown - Change file or folder ownership and group

Changes a file or folder's ownership and group information using chown.

chown #{owner}:#{group} #{file_or_folder}

bashmacos, linuxchown - Change file or folder ownership and group recursively

Changes a file or folder's ownership and group information recursively using chown.

chown -R #{owner}:#{group} #{file_or_folder}

shlinux, macoschown - Change file or folder mode ownership only

Changes a file or folder's ownership only using chown.

chown #{owner} #{file_or_folder}

bashmacos, linuxchown - Change file or folder ownership recursively

Changes a file or folder's ownership only recursively using chown.

chown -R #{owner} #{file_or_folder}

shmacos, linuxchattr - Remove immutable file attribute

Remove's a file's `immutable` attribute using `chattr`. This technique was used by the threat actor Rocke during the compromise of Linux web servers.

chattr -i #{file_to_modify}

shlinuxchflags - Remove immutable file attribute

Remove's a file's `immutable` attribute using `chflags`. This technique was used by the threat actor Rocke during the compromise of Linux web servers.

touch #{file_to_modify}
chflags simmutable #{file_to_modify}
chflags nosimmutable #{file_to_modify}

shmacos, linuxChmod through c script

chmods a file using a c script

#{compiled_file} /tmp/ T1222002

shlinuxChmod through c script (freebsd)

chmods a file using a c script

#{compiled_file} /tmp/ T1222002

shelevatedmacos, linuxChown through c script

chowns a file to root using a c script

sudo #{compiled_file} #{source_file}

shelevatedlinuxChown through c script (freebsd)

chowns a file to root using a c script

#{compiled_file} #{source_file}

▣

Mitigations

2

MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.

M1022Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions

Remove unnecessary write permissions on sensitive files and directories.
Use file ownership and groups to control access for specific roles. Example (Windows): Right-click the shared folder.
Properties.
Security tab.
Adjust permissions for NTFS ACLs.

Harden File Shares

Disable anonymous access to shared folders.
Enforce NTFS permissions for shared folders on Windows. Example: Set permissions to restrict write access to critical files, such as system executables (e.g., /bin or /sbin on Linux). Use tools like chown and chmod to assign file ownership and limit access. On Linux, apply: chmod 750 /etc/sensitive.conf `chown root:admin /etc/sensitive.

conf` File Integrity Monitoring (FIM)

Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.

Audit File System Access

Enable auditing to track permission changes or unauthorized access attempts.
Use auditd (Linux) or Event Viewer (Windows) to log activities.

Restrict Startup Directories

Configure permissions to prevent unauthorized writes to directories like C:\ProgramData\Microsoft\Windows\Start Menu. Example: Restrict write access to critical directories like /etc/, /usr/local/, and Windows directories such as C:\Windows\System32.
On Windows, use icacls to modify permissions: icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F.
On Linux, monitor permissions using tools like lsattr or auditd.

M1026Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.

Account Permissions and Roles

Implement RBAC and least privilege principles to allocate permissions securely.
Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security

Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials.
Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA)

Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM)

Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring

Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access

Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

Tools for Implementation Privileged Access Management (PAM)

CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management

Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication

Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management

sudo configuration, SELinux, AppArmor.

Just-In-Time Access

Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

◈

Detection Coverage

3/6 layers

Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).

Behavioral / log (Sigma) 4

Analytics (MITRE CAR) 1

Runtime / container (Falco) 2

File / malware (YARA) none

Network (Suricata/Snort) none

Vuln scan (Nuclei) none

◈

CAR Analytics

1

MITRE Cyber Analytics Repository - field-tested detection logic for this technique, written as pseudocode/queries you adapt to your own SIEM (Splunk, Sentinel, EQL). Each is a ready starting point for a detection rule, not just a description.

CAR-2019-07-001Moderate coverageAccess Permission Modification

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. Note.
this analytic references file permissions, which are not currently in the CAR data model.

Pseudocode - Windows - Pseudocode

log_name == "Security" AND
event_code == "4670" AND
object_type == "File" AND
subject_security_id != "NT AUTHORITY\SYSTEM"

Splunk - Windows - Splunk

index=__your_windows_security_log_index__ EventCode=4670 Object_Type="File" Security_ID!="NT AUTHORITY\\SYSTEM"

Pseudocode - Linux - Pseudocode

processes = search Process:Create
chmod_processes = filter processes where command_line == "chmod *"
output chmod_processes

LogPoint

norm_id=WindowsSysmon channel="Security" event_id=4670 object_type="File" -user_id="S-1-5-18"

◈

Falco Runtime Rules

2

Container / Linux runtime detections that fire on this technique.

ERRORModify binary dirs

Trying to modify any file below a set of binary directories can serve as an auditing rule to track general system changes. Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases.

view condition

modify and bin_dir_rename and not package_mgmt_procs and not exe_running_docker_save and not user_known_modify_bin_dir_activities

ERRORMkdir binary dirs

Trying to create a directory below a set of binary directories can serve as an auditing rule to track general system changes. Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases.

view condition

mkdir and bin_dir_mkdir and not package_mgmt_procs and not user_known_mkdir_bin_dir_activities and not exe_running_docker_save

▣

Comply & Defend

NIST 800-53AC-02, AC-03, AC-05, AC-06, AC-16, CA-07, CM-05, CM-06, IA-02, SI-04, SI-07

Intelligence Graph · click any node to traverse

CVETechnique ActorTool Family

drag to reposition · click any node to traverse · button top-right enlarges

External lookups - second-class, for what we don’t hold ourselves

MITRE ATT&CK Atomic Red Team car (MITRE)

Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities

Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs

Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures

Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1

About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service

threatengine.sh · Open-source threat intelligence platform · 100+ authoritative sources · Every fact traces to its origin