Heist is an easy Windows box. The main take-away from this box is: stop re-using passwords! The first step was to “abuse” the guest login of the web application. There, we were able to find confidential attachments, which included different hashes of passwords. Fortunately for us, all of these hashes were anything but secure! Bruteforcing the SMB server with these found passwords revealed a username, which we could then use to log in to the system. Once we had access to the system, we found a file that hinted towards an automated task. Looking at the running processes, we were able to quickly indentify the target process. We then dumped the memory of that process to retrieve the administrator password.
Enumeration
As always, we start by scanning the target machine’s open ports:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
rustscan --ulimit 5000 heist.htb -- sV -sC -oN nmap_scan
PORT STATE SERVICE REASON VERSION
80/tcp open http syn-ack Microsoft IIS httpd 10.0
| http-title: Support Login Page
|_Requested resource was login.php
| http-methods:
| Supported Methods: OPTIONS TRACE GET HEAD POST
|_ Potentially risky methods: TRACE
| http-cookie-flags:
| /:
| PHPSESSID:
|_ httponly flag not set
|_http-server-header: Microsoft-IIS/10.0
135/tcp open msrpc syn-ack Microsoft Windows RPC
445/tcp open microsoft-ds? syn-ack
5985/tcp open http syn-ack Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
49669/tcp open msrpc syn-ack Microsoft Windows RPC
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
The nmap output shows us that the open ports are the following:
- Port 80 - IIS 10.0: probably some kind of web application
- Port 135/445 - SMB
- Port 5985 - WinRM
- Port 49669 - Microsoft Windows RPC (?)
Enumeration Port 80 - Web Application
Let’s start with the enumeration of the web application. Accessing it via the browser, immediately redirects us to a log in page. After testing the most common ones like admin:admin - without any success - we recognized the Login as guest button. Obviously, we try to use that.
So, once we are logged in as guest, we see an Issues list. One of the users Hazard talks about a problem regarding a cisco router. Apparently, he/she also appended an excerpt of the cisco router configuration as attachment.
Looking at the attachment, we see some interesting entires. He/she just leaked the secret (level 5) and two passwords for the user rout3r and admin (both are level 7).
So what are these levels? An overview of the different Cisco password levels can be found here. The most important take-away is that Type 0, Type 5 and Type 7 should be migrated to other stronger methods.. Let’s have a look at the reason:
- Type 5:
Type 5 These use a salted MD5 hashing algorithm. These should only be used if Type 6, 8, or 9 is not available on the IOS version you are running. Attempting to use Type 5 in modern IOS XE will throw an error as these will be depreciated soon. In the running config these start with $5$.
- Type 7:
Type 7 These use the Vigenere cipher, a very simple algorithm that was cracked in 1995. These are easily reversible with tools on the internet. These should never be used and attempting to use Type 7 in modern IOS XE will throw an error as these will be depreciated soon.
So, Type5 is MD5 and Type7 is a simple Vigenere cipher (using dsfd;kfoA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;fg87 as key [Source]). This means, we can definitely recover both the passwords using Type 7 using a simple vigenere decoder. Regarding the Type 5, we have to crack the password using a tool such as hashcat.
-
Type 7: We can basically use any tool that supports Vigenere Decoding. Alternatively, we could also just write a simple Python script that does that for us. However, I used an online decoder for that. The credentials we get are the following:
1 2
rout3r: 0242114B0E143F015F5D1E161713: $uperP@ssword admin: 02375012182C1A1D751618034F36415408: Q4)sJu\Y8qz*A3?d
-
Type 5: For Type 5, we use hashcat with mode 500 and rockyou.txt as wordlist. The results are shown below. The password we recovered is
stealth1agent.![]()
Inital Foothold - Username enumeration through RID Cycling
Now that we have a list of potential usernames and password, we can bruteforce the SMB authentication. We can use crackmapexec for that purpose.
Here, we see that the credentials hazard:stealth1agent result in a successful login at the SMB server. Let’s investigate that manually using smbmap.
1
2
3
4
5
6
7
8
┌──(kali㉿kali)-[~/HTB/machines/heist]
└─$ smbmap -H 10.129.83.204 -u 'hazard' -p 'stealth1agent'
[+] IP: 10.129.83.204:445 Name: 10.129.83.204
Disk Permissions Comment
---- ----------- -------
ADMIN$ NO ACCESS Remote Admin
C$ NO ACCESS Default share
IPC$ READ ONLY Remote IPC
Hm… no special shares. At least we do have access to the ICP$ share. This allows us to enumerate usernames by RID Cycling. This technique has already been explained in other writeups such as VulnNet:Roasted and VulnNet:Active.
Here, we use Impacket's lookupsids.py and find the following usernames:
We can now use these usernames for another round of bruteforcing the SMB authentication:
The output is very promising! Apparently there is another pair of valid credentials: chase:Q4)sJu\Y8qz*A3?d. So many re-used passwords!
Scanning for the available SMB shares using these new credentials however results in no useful output.
1
2
3
4
5
6
7
8
┌──(kali㉿kali)-[~/HTB/machines/heist]
└─$ smbmap -H 10.129.83.204 -u 'Chase' -p 'Q4)sJu\Y8qz*A3?d'
[+] IP: 10.129.83.204:445 Name: 10.129.83.204
Disk Permissions Comment
---- ----------- -------
ADMIN$ NO ACCESS Remote Admin
C$ NO ACCESS Default share
IPC$ READ ONLY Remote IPC
But, in the nmap output we have seen that there is also an open WinRM port. We can use evil-winrm to establish a remote “shell” to the system:
1
2
┌──(kali㉿kali)-[~/HTB/machines/heist]
└─$ evil-winrm -i 10.129.83.204 -u 'chase' -p 'Q4)sJu\Y8qz*A3?d'
There we go! It works! We now have access to the system as user chase.
Privilege Escalation
For privilege escalation, as always, we start with the enumeration of the system. On the user’s Desktop we find another file called todo.txt:
1
2
3
4
5
6
7
*Evil-WinRM* PS C:\Users\Chase> type Desktop\todo.txt
Stuff to-do:
1. Keep checking the issues list.
2. Fix the router config.
Done:
1. Restricted access for guest user
Hmmmm … Keep checking the issues list. That was the list on the website. Maybe there is a ScheduledTask, which automates this task. But unfortunately, we are not allowed to check the ScheduledTasks. Therefore, I checked the running processes to see if there is anything running. And indeed! There is an unsual (=because this is a HackTheBox machine. Nobody should be able to run a browser here.) Firefox process.
We can also use the tool procdump.exe to dump the memory of the current process. Maybe we get some more information about that. After transferring the tool to the target machine, we can run it as follows (the value 6552 is the process ID of the firefox process with the highest CPU load as seen in the previous screenshot)
My assumption here is that the administrator must have logged in to the administrator dashboard at least once to check the current issues. Therefore, let’s first check out the login paramters that are being transmitted for the login.
Now that we know the names of the parameters, we can specifically search for them in the memory dump to see if there are any strings matching the request. As seen in screenshot below, the assumption seems to be correct. We see several successful logins of the user admin@support.htb using the password 4dD!5}x/re8]FBuZ
We can now use these credentials to login to the system using evil-winrm. The final step is, obviously, to retrieve the root flag.
