---
{
  "title": "File and Directory Permissions Modification",
  "summary": "Permission modification changes file or directory access rules to enable unauthorized activity.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1222"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1222: File and Directory Permissions Modification",
      "url": "https://attack.mitre.org/techniques/T1222"
    }
  ],
  "editorialVersion": 2
}
---

## Access rules can be changed to enable later actions

File and directory permission modification changes who can read, write, or execute relevant resources. Legitimate installation, administration, and collaboration depend on these changes. Unauthorized modification can expose sensitive data, allow replacement of trusted code, or make later activity possible.

The security meaning depends on the object, old and new permissions, modifying identity, and intended use. A broad-sounding permission label is not enough; inheritance, ownership, groups, and platform semantics can affect the actual result.

## A protected application directory becomes writable

In a fictional environment, a directory containing a service executable receives new write access for an unrelated group. The analyst preserves the current permissions, retrieves prior state where available, and checks the change event and approving workflow.

A deployment process may require temporary access, but the actual group, scope, and duration should match the approved purpose. The team also examines whether files changed after the permission update and whether the service later executed them.

The permission change establishes a modified access rule. It does not alone prove that a file was replaced or that the replacement executed. Those stages need file integrity and runtime evidence.

## Review effective access

An identity's effective permission can come from several groups or inherited rules. Removing one direct assignment may leave the same access available through another route. Use the platform's actual authorization model when verifying remediation.

[[linux-permissions]] explains one operating-system model, while other platforms use different structures. [[least-privilege]] provides the principle of limiting access to the task rather than granting broad rights for convenience.

Changes to code locations can support [[hijack-execution-flow]] or [[compromise-host-software-binary]], but map those behaviors only when the evidence establishes their additional steps. Permission exposure and actual code modification are different findings.

## Restore access without losing business function

Preserve relevant configuration and change records, restore the intended permissions through an approved process, and review the authority that made the change. Coordinate with the owner because overly restrictive rollback can break service accounts or deployment workflows.

Verify both security and operation: unauthorized writing should fail, while the legitimate service should continue functioning. Document any temporary exception and assign a review or expiration owner.

For practice, compare a documented temporary deployment permission with an unexplained broad write grant. Identify the approval, effective-access, file-change, and execution records needed to distinguish them. [[incident-reporting]] should separate the access opportunity from confirmed use, while [[incident-response]] coordinates any wider cleanup.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[event-triggered-execution]]
- [[boot-or-logon-initialization-scripts]]