On Windows, every file and folder has an access list, and built in tools can change it. MITRE ATT&CK tracks the abuse of those tools as T1222.001, Windows Permissions, a sub-technique of File and Directory Permissions Modification. It sits in the Defense Impairment tactic and applies to Windows.
How attackers use it
MITRE explains that adversaries may modify file or directory permissions and attributes to evade access control lists (ACLs) and reach protected files. ACLs are normally managed by the file or directory owner, or by users with the appropriate permissions, and they say which users or groups can read, write, execute and more.
Windows implements these as Discretionary Access Control Lists (DACLs). A DACL identifies the accounts that are allowed or denied access to a securable object. When something tries to access the object, the system checks the access control entries in order. If a matching entry is found, access is granted. Otherwise, access is denied.
Adversaries can work with DACLs using built in commands: icacls, cacls, takeown and attrib. These can grant higher permissions on specific files and folders. PowerShell also has cmdlets that read or change DACLs.
The change is usually a means to an end. MITRE says it may be a required step for persistence through accessibility features, for boot or logon initialization scripts, and for tainting or hijacking binaries and configuration files through Hijack Execution Flow.
Why it is easy to overlook
These utilities are legitimate and used by administrators and installers. A single call to icacls is not alarming. What matters is the target, the account and what happens next. A change to the permissions of a binary that Windows runs at the logon screen is very different from a change to a temp folder.
How to detect it
The MITRE strategy describes a multi stage behavioral chain:
- Process creation of permission changing utilities (icacls.exe, takeown.exe, attrib.exe, cacls.exe) or PowerShell ACL cmdlets.
- Command line analysis showing intent to widen access, through parameters such as grant, takeown, recursion and Set-Acl.
- DACL modification events (Security event 4670) that match the process execution.
- Later file access attempts (Security event 4663) indicating the change worked.
- Possible follow-on persistence or lateral movement.
To collect what you need:
- Process creation with command lines, such as Security event 4688 with command line auditing, or Sysmon event ID 1.
- PowerShell script block logging, to see ACL cmdlet use.
- Object access auditing with system access control lists (SACLs) on sensitive paths, which is what produces events 4670 and 4663 for those objects.
Tuning
Decide which paths matter most. Examples from the MITRE description are the binaries and scripts tied to accessibility features, logon initialization and system services. Put audit rules on those. Then add an alert for icacls, takeown or Set-Acl aimed at them from any account other than your deployment tooling. On the rest of the filesystem, keep the volume manageable by alerting only when the actor is unusual or the command also grants broad rights, such as to Everyone.
How to reduce the risk
MITRE lists two mitigations.
- Privileged account management. Make sure critical system files, and files known to be abused, have restrictive permissions and are owned by an appropriately privileged account, especially if users do not need access and function will not be inhibited.
- Restrict file and directory permissions. More restrictive permissions can prevent adversaries from changing the ACLs.
A short plan:
- Identify the system and application paths that attackers tend to alter and check who can write to them.
- Remove write and modify rights for standard users on those paths.
- Limit which accounts hold the right to take ownership.
- Turn on auditing for permission changes on those paths and send the events to your log store.
Check your own environment
This read-only command (cmd.exe) shows the access list of a system folder:
icacls C:\Windows\System32\drivers\etc
This read-only PowerShell command shows the owner and access entries for a path:
(Get-Acl C:\Windows\System32\drivers\etc).Access | Select-Object IdentityReference, FileSystemRights, AccessControlType
This read-only command checks whether object access auditing is enabled (cmd.exe):
auditpol /get /subcategory:"File System"
Questions to ask:
- Which standard users can write to folders that run code at startup or logon?
- Do you collect events 4670 and 4663 for your most sensitive paths?
- Is PowerShell script block logging on?
- Who holds the right to take ownership of files?
What good looks like
A strong Windows setup does three things. It keeps ACLs on sensitive paths tight, so there is little to gain from changing them. It audits changes to those paths and sends events 4670 and 4663 to a place analysts can search. And it alerts when icacls, takeown or Set-Acl targets those paths from anything other than known deployment accounts.
Quick check
Which four built in commands does MITRE name for changing Windows permissions?
icacls, cacls, takeown and attrib, plus PowerShell cmdlets.
Which event IDs are part of the detection chain?
Security event 4670 for DACL modification and event 4663 for later access attempts.
Why is the target of the change more important than the tool?
The tools are used legitimately all the time. A change to a file that runs at logon or startup tells you far more than the fact that icacls ran.
Sources
- MITRE ATT&CK, T1222.001: https://attack.mitre.org/techniques/T1222/001
