Access Control Lists (ACLs) are the gatekeepers of your digital infrastructure. When configured correctly, they enforce the principle of least privilege across files, directories, registry keys, Active Directory objects, and cloud resources. When misconfigured, they become a silent highway that adversaries use to escalate privileges, move laterally, and own entire domains, often without triggering a single alert.
This post breaks down exactly how ACL abuse works, the tools and commands attackers use, and why organizations cannot afford to leave these misconfigurations unaddressed.
If your organization needs a thorough assessment of ACL hygiene across your environment, Redfox Cybersecurity's penetration testing services are built to find and validate these weaknesses before real attackers do.
What Are ACLs and Why Do They Matter in Security
An ACL is a set of rules that defines which users or system processes can access objects and what operations they can perform. In Windows environments, ACLs are attached to every securable object, including files, folders, registry keys, services, and Active Directory objects. In Linux, they extend the standard DAC (Discretionary Access Control) model with fine-grained user and group permissions. In cloud environments like AWS and Azure, ACLs and IAM policies serve similar purposes.
The problem is not that ACLs are complex by nature. The problem is that they are often set and forgotten. As organizations grow, permissions accumulate, inheritance gets broken, and wildcard entries get introduced. Each misconfiguration is a potential foothold or privilege escalation vector.
Common ACL Misconfiguration Categories
Overly Permissive File and Directory ACLs on Windows
In Windows, you can enumerate file and directory ACLs using built-in tools and third-party utilities. When an attacker lands on a machine, one of the first things they do is hunt for world-writable directories or executables that can be replaced.
Using icacls:
icacls "C:\Program Files\" /T /C
This command recursively lists ACL entries for all files and folders under Program Files. Attackers look for entries like:
Everyone:(OI)(CI)(F)
BUILTIN\Users:(OI)(CI)(M)
F stands for Full Control and M for Modify. If a low-privileged user has Modify or Full Control over a directory where a service binary lives, they can replace that binary with a malicious payload. When the service restarts, the payload executes as SYSTEM.
To search specifically for weak service binary permissions, attackers use tools like PowerUp from PowerSploit:
Import-Module .\PowerUp.ps1
Invoke-AllChecks
PowerUp will enumerate services with unquoted paths, services with modifiable binaries, and registry keys with weak ACLs, all in one sweep.
Active Directory ACL Abuses
This is where ACL misconfigurations become catastrophic. Active Directory objects, such as users, groups, organizational units, and GPOs, all carry ACLs known as DACLs (Discretionary Access Control Lists). If any of these are misconfigured, an attacker with a foothold can perform direct object manipulation to escalate to Domain Admin.
BloodHound and SharpHound enumeration:
.\SharpHound.exe -c All --zipfilename loot.zip
BloodHound visualizes these relationships, revealing attack paths like:
- UserA has GenericWrite on UserB
- UserB is a member of IT Admins
- IT Admins has WriteDacl on Domain Admins
This is not a hypothetical scenario. It is one of the most commonly discovered attack paths in enterprise assessments conducted by teams like Redfox Cybersecurity.
Key AD ACL abuse rights to look for:
GenericAll grants full control over an object. This means an attacker can reset a user's password, modify group memberships, or write to sensitive attributes.
# Using PowerView to check ACLs on a user object
Get-ObjectAcl -SamAccountName "targetuser" -ResolveGUIDs | Where-Object {$_.ActiveDirectoryRights -match "GenericAll"}
WriteDACL allows an attacker to modify the DACL of an object, effectively giving themselves any permission they want on that object, including GenericAll.
# Grant yourself DCSync rights using WriteDACL
Add-ObjectAcl -TargetDistinguishedName "DC=corp,DC=local" -PrincipalSamAccountName lowprivuser -Rights DCSync
DCSync then allows the attacker to replicate password hashes directly from the domain controller without ever logging into it:
.\mimikatz.exe "lsadump::dcsync /domain:corp.local /user:krbtgt"
WriteOwner allows an attacker to take ownership of an object, then modify its DACL to grant themselves full rights:
Set-DomainObjectOwner -Identity "Domain Admins" -OwnerIdentity "lowprivuser"
Add-DomainObjectAcl -TargetIdentity "Domain Admins" -PrincipalIdentity "lowprivuser" -Rights All
These chains are subtle, easily missed during manual review, and extremely dangerous. An independent review by Redfox Cybersecurity's pentesters can map these paths systematically using both automated tooling and manual analysis.
Unquoted Service Path and Weak Registry ACLs
Windows services that have unquoted paths with spaces are vulnerable to binary planting. But registry ACL misconfigurations are equally dangerous and far less understood.
Services store their configuration in the registry under:
HKLM\SYSTEM\CurrentControlSet\Services\
If a low-privileged user has write access to a service registry key, they can change the ImagePath to point to a malicious binary:
# Check registry ACLs for a specific service
Get-Acl "HKLM:\SYSTEM\CurrentControlSet\Services\VulnerableService" | Format-List
Using Sysinternals AccessChk to enumerate weak registry ACLs:
accesschk.exe -kwsu "Everyone" HKLM\SYSTEM\CurrentControlSet\Services
accesschk.exe -kwsu "BUILTIN\Users" HKLM\SYSTEM\CurrentControlSet\Services
If an Everyone or BUILTIN\Users write permission appears on a service key, that service is trivially exploitable for privilege escalation.
Linux ACL Misconfigurations
On Linux systems, extended ACLs are managed via the setfacl and getfacl utilities. Standard permission checks using ls -la will not show extended ACL entries; a + sign at the end of the permission string is the only indicator.
# List all extended ACLs recursively
getfacl -R /etc/ 2>/dev/null | grep -v "^#" | grep -v "^$"
Attackers hunt for world-writable cron scripts, SUID binaries in unexpected locations, and writable paths in root-owned scripts:
# Find world-writable files outside /tmp and /var
find / -writable -not -path "/tmp/*" -not -path "/proc/*" 2>/dev/null
# Find SUID binaries
find / -perm -4000 -type f 2>/dev/null
# Find writable cron jobs
ls -la /etc/cron* /var/spool/cron/crontabs/
If a script run by root is world-writable, an attacker can append a reverse shell one-liner and wait for the cron job to trigger.
Cloud ACL Misconfigurations: AWS S3 and IAM
Cloud environments have introduced a new dimension of ACL abuse. Overly permissive S3 bucket ACLs, misconfigured IAM policies, and wildcard resource statements are routinely found in production environments.
Enumerating S3 bucket ACLs using the AWS CLI:
aws s3api get-bucket-acl --bucket target-bucket-name
aws s3api get-bucket-policy --bucket target-bucket-name
A bucket policy that includes Principal: "*" with s3:GetObject or s3:PutObject is exposed to the public internet. If PutObject is permitted, an attacker can host malicious content or exfiltrate data.
For IAM policy enumeration, tools like Pacu or Enumerate-IAM automate the discovery of overly permissive policies:
python3 enumerate-iam.py --access-key AKIA... --secret-key ...
Wildcard IAM policies like iam:* or s3:* attached to roles assumed by EC2 instances are particularly dangerous. An attacker who gains code execution on that instance inherits those permissions and can pivot across the entire AWS account.
H3: Chaining ACL Misconfigurations for Full Domain Compromise
In real-world assessments, individual ACL misconfigurations are rarely isolated. The real danger lies in chaining them. A typical kill chain might look like this:
- Initial access via phishing lands the attacker on a workstation as a standard domain user.
- PowerUp identifies a service binary with weak ACLs, enabling local privilege escalation to SYSTEM.
- Mimikatz or Sekurlsa dumps cached credentials, yielding a service account password.
- BloodHound reveals that the service account has GenericWrite over a member of the IT Helpdesk group.
- The attacker uses GenericWrite to set a fake SPN on that user and Kerberoasts the hash offline.
- The cracked password belongs to a user with WriteDACL on the Domain Admins group.
- The attacker grants themselves DCSync rights and dumps the krbtgt hash.
- A Golden Ticket is forged, granting persistent, unrestricted domain access.
Each step exploited a misconfigured ACL. None of them required a zero-day exploit. This is the reality of modern enterprise compromises.
Defensive Countermeasures Against ACL Abuse
Regular ACL Auditing
Use tools like PingCastle or BloodHound's Blue Team edition to run regular ACL audits on Active Directory. Automate the detection of dangerous rights such as GenericAll, WriteDACL, and WriteOwner granted to non-admin accounts.
# PingCastle basic scan
.\PingCastle.exe --healthcheck --server corp.local
Enforce the Principle of Least Privilege
Every user, service account, and application should hold only the permissions required for its specific function. Regularly review and prune permissions that are no longer necessary.
Monitor for ACL Changes
Windows Event ID 4670 logs permission changes on objects. Event ID 5136 captures changes to Active Directory objects. Alerting on these events, especially for high-value objects like Domain Admins and krbtgt, provides early warning of ACL abuse in progress.
Conduct Regular Penetration Tests
Defensive tooling and internal audits are not sufficient on their own. Attackers approach your environment without the assumptions your internal team carries. A skilled external team will chain misconfigurations in ways that automated scanners miss entirely.
Redfox Cybersecurity specializes in adversary-simulated penetration testing that includes full ACL abuse coverage across Active Directory, Windows endpoints, Linux systems, and cloud environments. Their assessments are built to find what automated tools miss and deliver actionable remediation guidance that your team can act on immediately.
Wrapping Up: ACL Misconfigurations Are Silent Business Risks
ACL misconfigurations are not theoretical attack vectors. They are present in the vast majority of enterprise environments, they are actively exploited by ransomware groups and APTs, and they are entirely preventable with the right visibility and expertise.
The commands and techniques covered in this post represent only a fraction of what a skilled attacker can do with misconfigured access controls. The attack surface is wide, the chains are subtle, and the consequences of a missed misconfiguration can be total domain compromise within hours of initial access.
If you are responsible for securing an organization's infrastructure, the single most effective action you can take is to have your environment assessed by professionals who think the way attackers do.
Book a penetration test with Redfox Cybersecurity and find out exactly where your ACL misconfigurations live before someone else does.