Hacking Articles|Raj Chandel's Blog: 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

Abusing AD-DACL- AllExtendedRights

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

2. 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.

Go to the Security tab, and click on Add button

In the “Enter the object name to select” box, type Geet and click Check Names and click on OK.

Select Geet user and click on advanced option.

In the Advanced security settings box, double-click on Geet user’s permission entry.

In the Permissions section, check the box for All Extended Rights permission.
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.