Pentesting Quick Reference OSCP and Beyond
  • Basic Tools & Techniques
  • Linux Basics
  • Windows Basics
  • Shells
  • Uploading Shells/ Transferring Files
  • FootPrinting
  • Host Discovery
  • Scanning
  • Vulnerability assessment
  • Metasploit and Meterpreter
    • Payloads
  • Brute Forcing/ Password Cracking
    • Attacking LSASS Passwords
    • Credentials Hunting Windows
    • Credential Hunting in Linux
    • Passwd, Shadow & Opasswd
    • Pass the Hash (PtH)
    • Protected Files
    • Protected Archives
    • Password Policies
    • Password Managers
    • Breached Credentials
    • Mimikatz
  • Linux Remote Management Protocols
  • Windows Remote Management Protocols
  • Port 20/21 - FTP Pentesting
  • Port 23 Telnet
  • Port 25 - SMTP
  • IMAP/ POP3
  • Port 53 DNS
  • Port 445 - SMB
  • Port 111 -RPC Bind
  • Port 135 - RPC
  • Port 137 NetBios
  • Port 161 SNMP
  • Port 1433 - MSSQL
  • Port 1521 Oracle TNS
  • Port 1833 - MQTT
  • Port 2049 - NFS
  • Port 3306 MySQL
  • Port 3389 - RDP
  • Port 5985 - Winrm
  • Port 632 (UDP) IPMI
  • Redis (6379)
  • Port 10000 Webmin
  • Privilege Escalation
    • Windows Priv esc
    • Linux Priv esc
  • Active Directory
    • AD Basics
      • AD Management Basics
    • Initial Enumeration of AD
      • Enumerating AD Users
    • Password Spraying
      • Enumerating & Retrieving Password Policies
      • Password Spraying - Making a Target User List
      • Internal Password Spraying - from Linux
      • Internal Password Spraying - from Windows
      • Enumerating Security Controls
    • LLMNR Poisoning
    • SMB/ NTLM Relay Attacks
    • IPv6 Attacks
      • IPV6 DNS takeover
      • WPAD
    • Passback Attacks
    • AS-REP roasting
    • AD Shell
    • AD Enumeration
      • Credentialed Enumeration - from Linux
      • Credentialed Enumeration - from Windows
      • Living off the Land
      • BloodHound
      • Plumhound
      • Bloodhound CE
      • ldapdomaindump
      • PingCastle
    • Post Compromise
      • Kerberosting
        • Kerberos "Double Hop" Problem
      • Pass Attacks
        • Pass the Hash
        • Pass the Ticket
          • Pass the Ticket (PtT) from Windows
          • Pass the Ticket (PtT) from Linux
      • Token Impersonation
      • LNK File Attacks
      • Miscellaneous Misconfigurations
    • Access Control List (ACL) Abuse Primer
      • ACL Enumeration
      • ACL Abuse Tactics
      • DCSync
        • DCSync Example Forest HTB
    • Post Owning Domain
      • Attacking Active Directory & NTDS.dit 1
      • Golden Ticket Attacks
    • Privilege Escaltion
    • Bleeding Edge Vulnerabilities
    • Domain Trusts
      • Attacking Domain Trusts - Child -> Parent Trusts - from Windows
      • Attacking Domain Trusts - Child -> Parent Trusts - from Linux
      • Attacking Domain Trusts - Cross-Forest Trust Abuse - from Windows
      • Attacking Domain Trusts - Cross-Forest Trust Abuse - from Linux
    • Hardening Active Directory
    • Additional AD Auditing Techniques
    • HTB AD Enumeration & Attacks - Skills Assessment Part I
  • Web Pentesting
    • Subdomains, directories and Vhost listing
    • Command Injection
    • XSS
    • SQL Injection
    • Authentication Bypass
  • Cryptography
  • More Resources
  • Forensics
  • IoT Security
  • API Security
  • Binary Exploitation
    • Assembly Cheatsheat for Hackers
    • Malware Analysis
      • Basic Static Malware Analysis
  • Boxes/ Machines
    • Try Hack Me
      • Vulnversity
      • Basic Pentesting
      • Kenobi
      • Steel Mountain
    • Vulnhub
      • Tiki
    • HTB
      • Beep
      • Active
      • Forest
      • Devel
    • Metasploitable 2
    • PWN.COLLEGE Talking Web
    • PWN COLLGE Web Hacking
  • Private Challenges
    • Pwn
    • Forensics
  • Misc tools
    • NetExec
  • SOC Analyst Resources
  • OSCP Tips and Misc
  • Mobile Hacking
  • Buffer Overflow
  • Wordpress
  • Web3 and Blockchain Security
  • WIFI Hacking
    • WPS Hacking
    • Misc Tools
Powered by GitBook
On this page
  • Access Control List (ACL) Overview
  • Access Control Entries (ACEs)
  • Why are ACEs Important?
  • ACL Attacks in the Wild
  1. Active Directory

Access Control List (ACL) Abuse Primer

PreviousMiscellaneous MisconfigurationsNextACL Enumeration

Last updated 4 months ago

For security reasons, not all users and computers in an AD environment can access all objects and files. These types of permissions are controlled through Access Control Lists (ACLs). Posing a serious threat to the security posture of the domain, a slight misconfiguration to an ACL can leak permissions to other objects that do not need it.


Access Control List (ACL) Overview

In their simplest form, ACLs are lists that define a) who has access to which asset/resource and b) the level of access they are provisioned. The settings themselves in an ACL are called Access Control Entries (ACEs). Each ACE maps back to a user, group, or process (also known as security principals) and defines the rights granted to that principal. Every object has an ACL, but can have multiple ACEs because multiple security principals can access objects in AD. ACLs can also be used for auditing access within AD.

There are two types of ACLs:

  1. Discretionary Access Control List (DACL) - defines which security principals are granted or denied access to an object. DACLs are made up of ACEs that either allow or deny access. When someone attempts to access an object, the system will check the DACL for the level of access that is permitted. If a DACL does not exist for an object, all who attempt to access the object are granted full rights. If a DACL exists, but does not have any ACE entries specifying specific security settings, the system will deny access to all users, groups, or processes attempting to access it.

  2. System Access Control Lists (SACL) - allow administrators to log access attempts made to secured objects.

We see the ACL for the user account forend in the image below. Each item under Permission entries makes up the DACL for the user account, while the individual entries (such as Full Control or Change Password) are ACE entries showing rights granted over this user object to various users and groups.

Viewing forend's ACL

image

The SACLs can be seen within the Auditing tab.

Viewing the SACLs through the Auditing Tab


Access Control Entries (ACEs)

As stated previously, Access Control Lists (ACLs) contain ACE entries that name a user or group and the level of access they have over a given securable object. There are three main types of ACEs that can be applied to all securable objects in AD:

ACE

Description

Access denied ACE

Used within a DACL to show that a user or group is explicitly denied access to an object

Access allowed ACE

Used within a DACL to show that a user or group is explicitly granted access to an object

System audit ACE

Used within a SACL to generate audit logs when a user or group attempts to access an object. It records whether access was granted or not and what type of access occurred

Each ACE is made up of the following four components:

  1. The security identifier (SID) of the user/group that has access to the object (or principal name graphically)

  2. A flag denoting the type of ACE (access denied, allowed, or system audit ACE)

  3. A set of flags that specify whether or not child containers/objects can inherit the given ACE entry from the primary or parent object

We can view this graphically in Active Directory Users and Computers (ADUC). In the example image below, we can see the following for the ACE entry for the user forend:

Viewing Permissions through Active Directory Users & Computers

  1. The security principal is Angela Dunn ([email protected])

  2. The ACE type is Allow

  3. Inheritance applies to the "This object and all descendant objects,” meaning any child objects of the forend object would have the same permissions granted

  4. The rights granted to the object, again shown graphically in this example

When access control lists are checked to determine permissions, they are checked from top to bottom until an access denied is found in the list.


Why are ACEs Important?

Attackers utilize ACE entries to either further access or establish persistence. These can be great for us as penetration testers as many organizations are unaware of the ACEs applied to each object or the impact that these can have if applied incorrectly. They cannot be detected by vulnerability scanning tools, and often go unchecked for many years, especially in large and complex environments. During an assessment where the client has taken care of all of the "low hanging fruit" AD flaws/misconfigurations, ACL abuse can be a great way for us to move laterally/vertically and even achieve full domain compromise. Some example Active Directory object security permissions are as follows. These can be enumerated (and visualized) using a tool such as BloodHound, and are all abusable with PowerView, among other tools:

  • ForceChangePassword abused with Set-DomainUserPassword

  • Add Members abused with Add-DomainGroupMember

  • GenericAll abused with Set-DomainUserPassword or Add-DomainGroupMember

  • GenericWrite abused with Set-DomainObject

  • WriteOwner abused with Set-DomainObjectOwner

  • WriteDACL abused with Add-DomainObjectACL

  • AllExtendedRights abused with Set-DomainUserPassword or Add-DomainGroupMember

  • Addself abused with Add-DomainGroupMember

In this module, we will cover enumerating and leveraging four specific ACEs to highlight the power of ACL attacks:

  • AddSelf - shows security groups that a user can add themselves to.


ACL Attacks in the Wild

We can use ACL attacks for:

  • Lateral movement

  • Privilege escalation

  • Persistence

Some common attack scenarios may include:

Attack
Description

Abusing forgot password permissions

Help Desk and other IT users are often granted permissions to perform password resets and other privileged tasks. If we can take over an account with these privileges (or an account in a group that confers these privileges on its users), we may be able to perform a password reset for a more privileged account in the domain.

Abusing group membership management

It's also common to see Help Desk and other staff that have the right to add/remove users from a given group. It is always worth enumerating this further, as sometimes we may be able to add an account that we control into a privileged built-in AD group or a group that grants us some sort of interesting privilege.

Excessive user rights

We also commonly see user, computer, and group objects with excessive rights that a client is likely unaware of. This could occur after some sort of software install (Exchange, for example, adds many ACL changes into the environment at install time) or some kind of legacy or accidental configuration that gives a user unintended rights. Sometimes we may take over an account that was given certain rights out of convenience or to solve a nagging problem more quickly.

There are many other possible attack scenarios in the world of Active Directory ACLs, but these three are the most common. We will cover enumerating these rights in various ways, performing the attacks, and cleaning up after ourselves.

Note: Some ACL attacks can be considered "destructive," such as changing a user's password or performing other modifications within a client's AD domain. If in doubt, it's always best to run a given attack by our client before performing it to have written documentation of their approval in case an issue arises. We should always carefully document our attacks from start to finish and revert any changes. This data should be included in our report, but we should also highlight any changes we make clearly so that the client can go back and verify that our changes were indeed reverted properly.

image

An which is a 32-bit value that defines the rights granted to an object

image

- gives us the right to reset a user's password without first knowing their password (should be used cautiously and typically best to consult our client before resetting passwords).

- gives us the right to write to any non-protected attribute on an object. If we have this access over a user, we could assign them an SPN and perform a Kerberoasting attack (which relies on the target account having a weak password set). Over a group means we could add ourselves or another security principal to a given group. Finally, if we have this access over a computer object, we could perform a resource-based constrained delegation attack which is outside the scope of this module.

- this grants us full control over a target object. Again, depending on if this is granted over a user or group, we could modify group membership, force change a password, or perform a targeted Kerberoasting attack. If we have this access over a computer object and the is in use in the environment, we can read the LAPS password and gain local admin access to the machine which may aid us in lateral movement or privilege escalation in the domain if we can obtain privileged controls or gain some sort of privileged access.

This graphic, adapted from a graphic created by , shows an excellent breakdown of the varying possible ACE attacks and the tools to perform these attacks from both Windows and Linux (if applicable). In the following few sections, we will mainly cover enumerating and performing these attacks from a Windows attack host with mentions of how these attacks could be performed from Linux. A later module specifically on ACL Attacks will go much further in-depth on each of the attacks listed in this graphic and how to perform them from Windows and Linux.

image

We will run into many other interesting ACEs (privileges) in Active Directory from time to time. The methodology for enumerating possible ACL attacks using tools such as BloodHound and PowerView and even built-in AD management tools should be adaptable enough to assist us whenever we encounter new privileges in the wild that we may not yet be familiar with. For example, we may import data into BloodHound and see that a user we have control over (or can potentially take over) has the rights to read the password for a Group Managed Service Account (gMSA) through the edge. In this case, there are tools such as that we could use, along with other methods, to obtain the password for the service account in question. Other times we may come across extended rights such as or using PowerView and have to do a bit of research to figure out how to exploit these for our benefit. It's worth familiarizing yourself with all of the and as many Active Directory as possible as you never know when you may encounter a less common one during an assessment.

access mask
ForceChangePassword
GenericWrite
GenericAll
Local Administrator Password Solution (LAPS)
Charlie Bromberg (Shutdown)
ReadGMSAPassword
GMSAPasswordReader
Unexpire-Password
Reanimate-Tombstones
BloodHound edges
Extended Rights