Detecting T1222 File and directory permissions modification

How T1222 file and directory permissions modification hides in normal administration

For a SOC lead, the core problem with T1222 is that permission changes are ordinary administration. Help desks fix access on shared folders, platform teams adjust ownership after deployments, and backup jobs need read rights. Under the Defense Impairment tactic (TA0112), an adversary who changes access controls on files and directories aims to blind or disable defenses: making agent configuration or audit log paths unwritable, locking defenders out of evidence, or granting its own process rights it should not hold. The detection goal is therefore not to alert on every permission change, but to separate changes that fit an approved pattern from those that do not.

The two sub-techniques split along platform lines, one for Windows and one for Linux and macOS, so detection content is written per operating system. In practice, the SOC needs to know which paths are security-relevant on each estate: security agent directories, log stores, configuration for endpoint tooling, and backup repositories. Build a short list of these paths with the platform owners and record who is expected to change their permissions and through which change process. Changes outside that owner list, outside a change window, or made by an account with no business reason to touch them are the candidates worth investigating. Confirm the exact path list in your own environment, since defaults vary by product and deployment.

This page targets Enterprise ATT&CK version 20.0. Technique IDs, sub-technique structure and the mitigations mapped to them can change in later releases, so recheck the T1222 entry and its sub-techniques against the ATT&CK updates page before you tune rules or report coverage. Record the ATT&CK version in every detection mapping so that a later rename or deprecation does not silently break your coverage claims.

Which telemetry reveals permission changes on each platform

This table maps the data components most relevant to T1222 to each platform in scope, along with the signal to look for and a practical open-source collector. Read it as a coverage map: where a row shows a strong signal, confirm your collector actually ingests that source before relying on it. Data component mappings should be checked against the ATT&CK version your rules target.

Platform	Data component and signal	Open-source collector
Linux	Command Execution (DC0064) for chmod, chown and setfacl style changes, plus File Modification (DC0061) for ownership or mode changes on sensitive paths	Wazuh agent with auditd rules, or Velociraptor artifacts for on-demand file metadata checks
macOS	Command Execution (DC0064) and Process Creation (DC0032) for permission-changing utilities, plus File Modification (DC0061) on protected user and system directories	Wazuh agent with endpoint logging, or Velociraptor for collecting file metadata and ACLs
Windows	Process Creation (DC0032) and Command Execution (DC0064) for ACL-editing tools, plus File Modification (DC0061) and Active Directory Object Modification (DC0066) for ACL changes on shares and directory objects	Sysmon-based pipeline forwarded to Wazuh or Security Onion, with Windows Security auditing enabled for object access
ESXi	Command Execution (DC0064) and File Modification (DC0061) for changes to datastore and configuration file permissions, usually visible only after log forwarding	Syslog forwarding from the hypervisor to Wazuh or Security Onion; confirm which ESXi log sources your version exposes
Active Directory (directory objects)	Active Directory Object Modification (DC0066) for changes to security descriptors on directory objects and file shares	Windows event forwarding to Wazuh or Security Onion, with directory service change auditing scoped to sensitive containers
Network-visible file shares	Network Traffic Content (DC0085) is limited for this technique; rely on share-side auditing rather than packet capture alone	Zeek file analysis and Security Onion alerts for correlation, with host-side logs as the primary source
Coverage check	Confirm each data component mapping against the ATT&CK version in use, since data components and sub-technique mappings can change between releases	Keep a per-platform telemetry inventory in version control and test it during cyber range exercises

Detection logic for permission changes that matter

Permission changes are common and mostly routine, so a detection that alerts on every chmod, icacls or ACL edit will be ignored within a week. The four ideas below narrow the signal by path sensitivity, by tooling location, by directory object scope and by volume across hosts. Tune each one against a baseline of your own configuration management, package and backup activity before treating an alert as an incident.

Ownership or mode changes on sensitive paths

Focus on ownership and permission-mode changes to files under authentication, logging, boot and scheduled-job locations, such as the system account databases, sudoers configuration, SSH daemon configuration and cron directories. Alert when the actor is an interactive user session or an unexpected service account rather than a known configuration manager. Set the watch list from your hardening baseline, not from a generic path list, and review it after every operating system upgrade. Baseline sources include File Modification and Command Execution telemetry collected with Wazuh file integrity monitoring or auditd rules. Expected false positives: configuration management runs, package post-install scripts and backup restore jobs, which should be excluded by actor and parent process rather than by path alone.

Permission changes on security tooling directories

Treat any permission change on the directories that hold EDR agents, audit log stores, SIEM forwarders and Wazuh agent configuration as high priority, because a change there is aimed at the defender's own visibility. Set a threshold of zero expected changes outside maintenance windows, and page on the first event rather than aggregating. Baseline these directories from the agent install packages and the change calendar, and record the expected owner and mode for each one. Expected false positives: agent upgrades and log rotation tools, which should be matched to a change ticket or a known package manager process. Confirm with each vendor which files the agent needs writable and which must remain locked down.

Windows ACL changes on AD-linked objects

On Windows, watch for security descriptor changes on Active Directory objects that control privileged groups, GPO links, service accounts and domain controller computer objects. Enable directory service object access auditing on those objects only, because auditing every object floods the collector. Alert on DACL edits made by accounts outside the directory administration tier, and on any change to inheritance settings. Baseline with the Active Directory Object Modification telemetry from a known administration workstation population. Expected false positives: directory management tools run by the identity team, and scheduled provisioning jobs, which should be allow-listed by account and source host.

Bursts of permission changes across hosts

A single permission change is rarely decisive, but the same change applied to many hosts within a short window is a strong signal of scripted impairment. Set a rolling threshold per actor, for example more than a few hosts changed within a short window, and tune it upward after measuring normal fleet operations. Correlate the burst by time, actor and change type in Wazuh or Security Onion dashboards, and alert on bursts that cross tier boundaries. Expected false positives: fleet-wide patch windows, golden image rebuilds and backup agent rollouts. Confirm the change calendar with platform engineering before tuning, and keep the threshold documented with the version of the rule it applies to.

How to validate the detection before you trust it

This sequence proves that the T1222 detections fire for the permission changes you care about, on the platforms you run, and that they stay accurate after you tune them. It produces a documented baseline of expected alerts, measured false positives and false negatives, and a re-test record that auditors and your own teams can review.

Define the permission change categories to simulate
The detection team agrees with the platform owners which permission changes to emulate in the lab or cyber range. Cover the sub-technique families that ATT&CK describes for T1222 on each platform in scope, such as ownership and mode changes on Linux and macOS, ACL changes on Windows file systems, and datastore or file permission changes on ESXi. Write each category as a short test case with a named owner and a clear expected outcome. The step is done when every category maps to at least one planned test and one expected data source.
Build the platform and telemetry inventory
List every host type, image and collector that the test will touch, including the Wazuh agents, Sysmon or auditd configuration, Velociraptor or other endpoint sources, and any ESXi syslog forwarding. For each source, confirm which ATT&CK data components it covers, such as Command Execution, Process Creation, File Modification and Active Directory Object Modification, and note gaps. Record the collector versions and rule set version you will test against, and name the ATT&CK version you target. The step is done when the gaps are written down and accepted by the owners.
Write expected alerts before the run
Before any test runs, the detection engineer records the alert each test case should produce, including the rule or analytic name, severity, the host and user context, and the affected path or object. Also record the cases where no alert is expected, such as routine administrative changes that a documented change ticket covers. Writing expectations first prevents the team from accepting whatever fires as success. The step is done when each test case has a written pass condition and a written fail condition reviewed by a second person.
Execute the emulation and capture evidence
Run the planned permission changes in the isolated range under a controlled change window, with a tester who records each action in a run log. For every action, capture the timestamp, host, account, affected path or object, and the alert ID that fires, if any. Keep the raw logs from the collector so the result can be reproduced later. The step is done when the run log, the alert export and the raw telemetry for each test case are stored together under one run identifier.
Measure true and false positives across the window
Compare the run log against the alert export to classify each alert as a true positive, a false positive or a missed detection. Include normal administrative activity and scheduled jobs that ran during the same window, since they are the usual source of false positives for permission monitoring. Calculate the counts per platform and per test category, and list the top sources of noise with their owners. The step is done when every alert in the window has a classification and every planned test has a recorded outcome.
Tune rules and collectors, then re-test
Adjust the rule logic, exclusions or collector settings that caused false positives or missed detections, and record each change in version control with a reason. Re-run the affected test cases and the regression cases that previously passed, using the same run structure. Confirm that a tuning change did not silence a true positive by comparing the new results with the baseline. The step is done when the re-test results match the written pass conditions for every case that was changed.
Schedule re-tests after collector and rule changes
Define the events that trigger a repeat of the validation, such as an agent upgrade, a change to audit policy, an ESXi or operating system upgrade, a new ATT&CK version, or a major rule update. Ask the vendor or project maintainers to confirm which data components change in each release so that gaps are found before attackers or auditors find them. Keep a dated record of each re-test and its outcome. The step is done when the trigger list is approved and the next re-test is assigned to an owner.

How the detection pipeline fits together across platforms

The detection for T1222 depends on one decision made early: which telemetry from ESXi hosts, Linux and macOS endpoints, Windows domain controllers and member servers is forwarded to a single SIEM, and in what shape. Permission changes reach the SIEM only if each source is forwarded. Confirm that ESXi host logs are sent to the central collector rather than left on the hosts, that Linux and macOS command execution and audit records are shipped by the agent, and that Windows Active Directory Object Modification events are collected from the domain controllers that actually process the changes. Each gap should be recorded as a named coverage item, because a silent source looks the same as a quiet one in a dashboard.

Normalization is where the platforms become comparable. Wazuh agents, Security Onion, Zeek and Suricata each emit fields with different names for the same act, such as the account, the target path, the mode or ACL change and the host. Decide where that mapping happens, at the agent, in the collector or in the SIEM pipeline, and document it once. File integrity coverage is a frequent gap: the detection can only see permission changes on paths that the integrity monitoring watches, so confirm the monitored directory list against the sensitive paths named in the ESXi, Linux, macOS and Windows hardening baselines your team uses.

Sigma rules sit between detection content and the SIEM. Write rules once in Sigma, convert them to the query language of the chosen backend, and keep the converted output under version control next to the Sigma source. Tag every rule with the ATT&CK version it targets, since MITRE's releases can rename, deprecate or revoke techniques and sub-techniques. Enterprise ATT&CK v20 was released on October 13, 2026, and the pipeline should record which version each rule maps to, reviewing mappings after each release on the MITRE ATT&CK updates page. Ask the engineering owner to confirm how the backend handles field mapping changes before relying on a converted rule in production.

Preventive controls that limit who can change permissions

Most T1222 activity succeeds because someone other than a tightly managed administrator can change permissions on sensitive files and directories. The cards below cover the two ATT&CK mitigations that address this directly, Privileged Account Management (M1026) and Restrict File and Directory Permissions (M1022), and the baseline controls that make permission changes rare enough to notice.

Least privilege for permission changes

Start by listing which accounts can change owners, group membership and access control lists on sensitive paths, including service accounts and backup jobs. Most environments find that far more identities hold this right than the job requires. Under Privileged Account Management (M1026), remove standing rights where possible and grant the rest for defined tasks. Ask each owner which permission changes their process actually performs, then remove everything else.

Protected administrative paths

Keep permission changes on critical hosts and shares on dedicated administrative paths, such as jump hosts or privileged access workstations, rather than ordinary user sessions. Restrict where those sessions can originate and require stronger authentication to reach them. This shrinks the set of places a T1222 change can be issued from, and it gives your detection a small, predictable population of legitimate sources to compare against.

Baseline ACLs on sensitive locations

Record a known-good permission baseline for configuration directories, backup repositories, log stores and hypervisor datastores. Restrict File and Directory Permissions (M1022) is the mitigation that keeps these locations from being broadly writable in the first place. Store the baseline as code or exported ACL reports, so a later comparison can show exactly which entries changed and when.

Ownership and inheritance review

Permission changes often happen through ownership transfers or inherited rights rather than an obvious edit to one object. Review which principals own sensitive directories and whether child objects inherit permissions from broad parents. Flag any directory where a non-administrative account owns the object, because ownership can allow later permission changes even when the explicit entries look correct.

Platform support to confirm

Mitigation coverage differs across ESXi, Linux, macOS and Windows, and between managed and unmanaged hosts. Confirm with your platform vendors and internal standards which permission controls, privileged access features and audit settings are available and supported in your versions. Document any gap as a compensating control, because a mitigation that cannot be enforced on one platform still needs a monitored owner.

What the SOC does in the first hour after a permissions alert

The first decision in a T1222 alert is whether the permission change was authorized. Pull the change ticket, maintenance window and owner for the affected host or share, then compare the alert against them. A chmod, icacls or ACL edit on a file nobody scheduled to touch is a suspicious change until someone with authority says otherwise. In the same window, identify the actor and the process that made the change: the account, its logon session, the parent process and the host it came from. Confirm whether the actor is a service account, an administrator on a jump host or a user whose role has no reason to alter ownership or ACLs. Process lineage is usually the fastest way to separate a configuration tool from a person typing at a shell.

Next, decide how much the change matters. Check whether the affected objects hold credentials, private keys, identity provider or directory configuration, backup catalogs, logging pipelines or security agent configuration. A permission change on any of these raises the severity regardless of how small the edit looks. Then scope the change across hosts: query your endpoint and file integrity telemetry for the same path patterns, the same actor and the same time window, and check whether the change was applied through a management tool that touched many systems at once. Record which hosts were changed, not only which one raised the alert. Containment should match the evidence: isolating a host is justified when the actor is unknown or security tooling is affected, while restricting the single account or pausing the automation job may be enough when a known process made a mistake. Document each choice and its reason in the incident record.

Preserve evidence before restoring anything. Export the current ACLs, owners and mode bits for the affected paths, along with the relevant audit and process records, and hash the exported files. Restoring permissions first destroys the evidence of what changed. Once evidence is secured, restore known-good permissions from a verified baseline, such as a configuration management state, a golden image or a permissions inventory captured before the change, and confirm that the baseline itself has not been altered. Re-run the scope check after restoration to confirm no hosts were missed. Confirm with the platform team which baseline sources are current and who approves the restore, because that approval is part of the record an auditor will ask for.

How to rehearse T1222 detection in a private cyber range

An ESXi range needs a small virtualized host cluster with a management network separated from the workload network, a central log forwarder, and a test datastore that holds disposable virtual machines. Keep the hypervisor build and the logging configuration identical to production so the exercise reflects the telemetry your team will actually receive. Confirm with your virtualization vendor which host and vCenter events are exported to your SIEM and at what detail, because this sets the limits of what the exercise can prove.

Range build: Mirror production hypervisor versions, host profiles and vCenter roles, and record the exact versions in the exercise plan.
Injects: Plan a change to file or directory permissions on a datastore path used by a test virtual machine, performed through an account that is not the normal administrator account.
Detection goal: Confirm that the permission change appears in the forwarded logs with the account, host, time and affected path, and that an alert fires within the agreed window.
Response goal: Check that the responder can identify the account, confirm whether the change was expected, and restore the original permissions from a documented baseline.
Gap review: Record any field that is missing or only available on the host, and decide whether to forward it or accept the gap.

Before the exercise, check which ESXi and vCenter log sources your team can query, because a detection that works only on the host itself will not help a central analyst.

Questions SOC leads and detection engineers ask about T1222

How do I separate attacker permission changes from routine configuration management?

Start by making the legitimate changes predictable: name the configuration management tool, the service accounts it runs under, and the hosts and paths it touches. Then alert on permission changes that fall outside that known set, such as a chmod or icacls run by an interactive user, from an unexpected parent process, or against paths the automation never manages. Compare the actor, the parent process and the change window against your change calendar. Treat an allowlist as a living list that a change owner reviews, not a permanent exception. Confirm the exact fields your Command Execution and Process Creation telemetry carry on each platform before you write rules that depend on them.

Are ESXi file permission changes visible in standard logs?

Visibility depends on what you forward and whether shell access is enabled and logged. ESXi can run shell commands only when the shell service is turned on, so the first check is whether that service is enabled, who can enable it, and whether those events reach your SIEM. Confirm which ESXi log files your version writes, and whether the host forwards them through syslog to your collector. Vendor documentation is the authority for log locations and formats, so verify those against your ESXi build before building detections. Where command-level records are missing, shell enablement and SSH session events become the signals to alert on.

Should I write one detection for T1222 or separate rules for each sub-technique?

Write separate analytics per platform and per sub-technique, because each one leaves different evidence and needs different tuning. T1222 has two sub-techniques, one covering Linux and macOS and one covering Windows, and their telemetry differs: command execution and process creation records on Unix-like hosts, and Active Directory Object Modification and file or registry records on Windows. A single broad rule tends to either miss activity or flood the queue. Map each analytic to the ATT&CK version you target, because releases can rename or deprecate sub-techniques. Record coverage gaps explicitly so the report shows what is not monitored.

How often should we retest detections after an ATT&CK version change?

Retest whenever you adopt a new ATT&CK version that changes the technique, its sub-techniques, its detection strategies or its data components, and review your mapping at every version release. The current releases in this series were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, so plan a mapping review against each one you adopt. Also retest after changes to your logging pipeline, operating system versions or endpoint agents, since those can silently remove fields your rules depend on. Keep a dated record of each test so auditors can see when coverage was last checked.

How do we tune detections for noisy build hosts and CI runners?

Build hosts legitimately change file permissions during packaging, so tune by identity and context rather than by suppressing the rule. Tag build hosts as a distinct asset group, scope their exceptions to specific service accounts and working directories, and require the expected parent process such as the build tool. Keep alerts for the same actions when they come from interactive sessions, from unexpected paths, or outside pipeline run windows. Review exception lists monthly with the platform owner, and log every exception with a reason and an owner. Validate each tuned rule in a cyber range to confirm that real misuse on a build host still fires.

Can our own team run this detection program, or do we need outside help?

Many teams can build and operate these detections in-house, especially those with an existing SIEM, endpoint telemetry and a change process. The work that tends to stretch internal staff is the cross-platform mapping, the exception governance and the repeatable testing against each ATT&CK release. DeployOpen implements, hardens and documents self-hosted open-source platforms, and runs security testing and private cyber ranges inside the client's environment. Engagements are fixed-scope, so the written scope should state which platforms, sub-techniques and rules are covered, who maintains them, and what evidence you receive.

How DeployOpen builds and tests T1222 detections

DeployOpen approaches T1222 File and directory permissions modification as a fixed-scope engagement inside the client's own infrastructure. We agree in writing which platforms, telemetry sources and detection logic are covered, then build and test the detections against that agreed scope.

How we scope

Confirm which platforms are in scope, such as ESXi, Linux, macOS and Windows, before any work starts.
Inventory the telemetry available for Command Execution, Process Creation and Active Directory Object Modification in your environment.
Record the ATT&CK version the detections will target, so mappings stay correct when techniques change.

How we build

Write detection logic in open-source formats such as Sigma rules and deploy it to your existing SIEM or Wazuh stack.
Map the rules to the Privileged Account Management and Restrict File and Directory Permissions mitigations and document any gaps.
Test each rule against benign administrative activity on the private cyber range to measure false positives before handover.

How we hand over

Deliver detection logic, configuration files and validation test records for each covered sub-technique in your repository.
Provide a runbook describing triage steps, escalation paths and containment actions for permission changes on sensitive files.
Walk your security operations team through the cyber range exercise results and the known blind spots still open.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
Re-run validation when ATT&CK releases change techniques, sub-techniques or mitigations that your rules depend on.
Ask for a written quote tied to the agreed scope, and confirm which costs are one-time and which recur.

T1222 File and directory permissions modification