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`.
Security context for executives and security teams
Restricting file and directory permissions is a basic control with high defensive leverage: it limits who or what can read, write, or execute sensitive files, shared content, startup locations, scripts, and system directories. For leaders, the value is not that permissions exist, but whether they are governed, audited, and resistant to unauthorized change in the places attackers commonly abuse for persistence, stealth, lateral movement, exfiltration support, and impact.
Executive priority
Treat this as a resilience and audit-evidence control, not only a system hardening task. The related ATT&CK context connects weak permissions to masquerading, startup and logon persistence, scheduled execution, shared-content abuse, account persistence through SSH keys, permission tampering, indicator removal, and service disruption. Priority should go to business-critical systems, shared folders, administrative scripts, startup directories, sensitive configuration files, SSH authorization files, and directories containing executables or services. Executives should ask whether ownership, least privilege, monitoring, and exception handling are consistently enforced across these locations.
Technical view
SOC, detection engineering, and IR teams should validate whether file-system ACLs, ownership, group membership, and write/execute permissions are known-good for critical paths and whether changes are logged. The mitigation text specifically points to least privilege permissions, hardened file shares, file integrity monitoring, auditing of permission changes or unauthorized access attempts, and restrictions on startup directories. Relationship context makes this especially relevant to detection and response for masquerading, renamed utilities, legitimate-looking file placement, boot/logon scripts, scheduled jobs, SSH authorized_keys changes, and adversary modification of permissions.
Likely telemetry
- File and directory permission change events
- File ownership and group membership changes
- File integrity monitoring alerts for critical files, startup paths, scripts, and executables
- Windows security and Event Viewer records related to file access or ACL changes
- Linux auditd records for permission, ownership, and access events
Detection direction
- Baseline expected permissions for sensitive files, system directories, startup locations, shared folders, scripts, and service-related paths, then alert on unauthorized drift.
- Prioritize monitoring of writable locations that can influence execution or persistence, including startup directories, logon scripts, scheduled job definitions, systemd timers, RC scripts, and SSH authorized_keys files where present.
- Tune detections to distinguish approved administrative maintenance from unusual permission broadening, ownership transfer, inheritance changes, or new write access for broad groups.
- Correlate permission changes with related behaviors such as masqueraded file placement, renamed utilities, shared-content modification, persistence cleanup, or service disruption.
- Validate that file integrity monitoring and audit logging cover both content changes and permission/ownership changes; content-only monitoring can miss material control failures.
Mitigation priorities
- Start with least privilege: remove unnecessary write permissions from sensitive files, directories, startup paths, shared folders, and system executable locations.
- Use file ownership and groups to map access to defined roles rather than broad user populations or anonymous access.
- Harden shared folders by disabling anonymous access and enforcing file-system permissions, not only share-level convenience settings.
- Restrict write access to boot, logon, startup, scheduling, service, and configuration locations that can influence execution or persistence.
- Enable auditing and file integrity monitoring for critical paths so permission drift and unauthorized access attempts produce reviewable evidence.
Additional notes and limits
This mitigation is broad but operationally important because many related techniques depend on placing, modifying, hiding, or protecting files in locations defenders and users trust. Its effectiveness depends heavily on local asset criticality, operating system conventions, identity/group design, administrative workflows, and logging configuration. For Glexia-style assessments, this control should be tested through configuration review, telemetry validation, and incident-response evidence readiness rather than assumed from policy alone.
The ATT&CK object does not provide an official detection section and does not specify platforms for the mitigation itself. Platform references above are derived from the official description examples and supplied relationship context. This take does not assert active exploitation, attribution, guaranteed prevention, or existing detection coverage in any environment.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
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`.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.
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.
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.