Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1222: File and Directory Permissions Modification

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.).

Modifications may include changing specific access rights, which may require taking ownership of a file or directory and/or elevated permissions depending on the file or directory’s existing permissions. This may enable malicious activity such as modifying, replacing, or deleting specific files or directories. Specific file and directory modifications may be a required step for many techniques, such as establishing Persistence via Accessibility Features, Boot or Logon Initialization Scripts, Unix Shell Configuration Modification, or tainting/hijacking other instrumental binary/configuration files via Hijack Execution Flow.

Adversaries may also change permissions of symbolic links. For example, malware (particularly ransomware) may modify symbolic links and associated settings to enable access to files from local shortcuts with remote paths.[3][4][5][6][7]

EnterpriseT1222TechniqueObject v3.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

File and directory permission changes matter because they can turn normal access-control rules into a blind spot. If an adversary or malicious process can change ACLs, ownership, attributes, or symbolic link behavior, they may reach protected files, alter system or configuration content, support persistence, or weaken defenses across Windows, Linux, macOS, and ESXi environments.

Executive priority

Treat this as a control-assurance issue, not just a malware behavior. Leaders should ask whether critical servers, ESXi hosts, sensitive directories, and privileged accounts have enforceable least-privilege controls and auditable change records. The business risk is that unauthorized permission changes can enable tampering with files that support operations, recovery, persistence prevention, and incident scoping.

Technical view

This technique is mapped to defense impairment and has Windows and Linux/macOS sub-techniques. SOC and IR teams should validate monitoring for permission, ownership, ACL, attribute, and symbolic link setting changes on high-value paths and systems. Because ATT&CK does not provide detection text for T1222, use the related DET0299 detection strategy as a starting point and tune around platform-specific evidence. Relationship context also points to mitigations M1022 Restrict File and Directory Permissions and M1026 Privileged Account Management, and ATT&CK maps Qilin software as using this behavior across ESXi, Windows, and Linux.

Likely telemetry

  • File system permission and ACL change events
  • File ownership change records
  • Privileged account activity logs
  • Process execution telemetry for permission-management utilities or APIs
  • Endpoint file integrity monitoring on sensitive directories and configuration files

Detection direction

  • Prioritize monitoring on sensitive system directories, startup or logon script locations, accessibility feature paths, shell configuration files, binaries, and configuration files tied to execution flow.
  • Baseline legitimate administrative permission changes to reduce false positives from patching, deployment tools, backup software, and system administration.
  • Correlate permission changes with privileged account use, unusual parent processes, recent authentication events, and subsequent file modification, replacement, deletion, or persistence-related behavior.
  • Validate coverage separately for Windows, Linux, macOS, and ESXi; permission models and log sources differ by platform.
  • Review DET0299 for a multi-platform detection strategy, but confirm local telemetry exists before assuming coverage.

Mitigation priorities

  • Enforce least privilege on sensitive files and directories, removing unnecessary write or execute permissions where possible.
  • Use privileged account management to restrict, monitor, and audit administrative, root, SYSTEM, and equivalent accounts.
  • Require change control and logging for permission changes on critical system, application, recovery, and security tooling paths.
  • Apply file integrity monitoring or equivalent assurance on high-value paths where unauthorized permission changes would materially affect resilience.
  • Periodically review ACLs, ownership, and inherited permissions, especially after system migrations, software deployments, and incident recovery.
Analyst notes and limits

ATT&CK positions this as a cross-platform defense-impairment technique. The supplied relationships show concrete defensive anchors: M1022, M1026, DET0299, Windows and Linux/macOS sub-techniques, and software usage by Qilin. The official description also notes that permission modification may support other techniques such as Accessibility Features, Boot or Logon Initialization Scripts, Unix Shell Configuration Modification, and Hijack Execution Flow.

The official ATT&CK detection field is not provided for this object, so detection guidance must be validated against local logging, audit policy, endpoint tooling, and platform configuration. External references include examples and ransomware-related reporting, but they do not justify claims about current exploitation or exposure in any specific environment.

Official MITRE ATT&CK definition

File and Directory Permissions Modification

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.).

Modifications may include changing specific access rights, which may require taking ownership of a file or directory and/or elevated permissions depending on the file or directory’s existing permissions. This may enable malicious activity such as modifying, replacing, or deleting specific files or directories. Specific file and directory modifications may be a required step for many techniques, such as establishing Persistence via Accessibility Features, Boot or Logon Initialization Scripts, Unix Shell Configuration Modification, or tainting/hijacking other instrumental binary/configuration files via Hijack Execution Flow.

Adversaries may also change permissions of symbolic links. For example, malware (particularly ransomware) may modify symbolic links and associated settings to enable access to files from local shortcuts with remote paths.[3][4][5][6][7]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1222.002 Linux and Mac Permissions Sub-technique Linux and Mac Permissions subtechnique of this object.
Enterprise T1222.001 Windows Permissions Sub-technique Windows Permissions subtechnique of this object.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S1242: Qilin

Qilin is a ransomware family operated as a ransomware-as-a-service (RaaS) that has been active since at least 2022. It includes variants written in Go and Rust capable of targeting Windows, Linux, and VMware ESXi environments. Qilin shares functionality overlaps with Black Basta, REvil, and BlackCat ransomware. Qilin affiliates have targeted multiple entities worldwide with the majority of victims in the US, France, Canada, and the UK, primarily in the manufacturing, technology, financial services, and healthcare sectors.[1][2][3][4][5]

ESXiWindowsLinux
Relationship explorer

All related ATT&CK context

subtechnique of · Technique T1222.002: Linux and Mac Permissions Enterprise detects · Detection Strategy DET0299: Multi-Platform File and Directory Permissions Modification Detection Strategy Enterprise subtechnique of · Technique T1222.001: Windows Permissions Enterprise mitigates · Mitigation M1022: Restrict File and Directory Permissions Enterprise uses · Malware S1242: Qilin Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1022: Restrict 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`.

Mitigation Enterprise

M1026: Privileged 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.This mitigation can be implemented through the following measures:

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.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
3.0
Created
Modified
Raw hash
ac4b88f140d65515...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 3.0 Current bundle ac4b88f140d6…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Hybrid Analysis Icacls1 June 2018

    Hybrid Analysis. (2018, June 12). c9b65b764985dfd7a11d3faf599c56b8.exe. Retrieved August 19, 2018.

    Open source URL
  2. [2]
    Hybrid Analysis Icacls2 May 2018

    Hybrid Analysis. (2018, May 30). 2a8efbfadd798f6111340f7c1c956bee.dll. Retrieved August 19, 2018.

    Open source URL
  3. [3]
    new_rust_based_ransomware

    Symantec Threat Hunter Team. (2021, December 16). Noberus: Technical Analysis Shows Sophistication of New Rust-based Ransomware. Retrieved January 14, 2022.

    Open source URL
  4. [4]
    bad_luck_blackcat

    Kaspersky Global Research & Analysis Team (GReAT). (2022). A Bad Luck BlackCat. Retrieved May 5, 2022.

    Open source URL
  5. [5]
    falconoverwatch_blackcat_attack

    Falcon OverWatch Team. (2022, March 23). Falcon OverWatch Threat Hunting Contributes to Seamless Protection Against Novel BlackCat Attack. Retrieved May 5, 2022.

    Open source URL
  6. [6]
    blackmatter_blackcat

    Pereira, T. Huey, C. (2022, March 17). From BlackMatter to BlackCat: Analyzing two attacks from one affiliate. Retrieved May 5, 2022.

    Open source URL
  7. [7]
    fsutil_behavior

    Microsoft. (2021, September 27). fsutil behavior. Retrieved January 14, 2022.

    Open source URL
  8. [8]
    mitre-attack T1222
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use