HackTheBox: Bank Walkthrough

I’ve got another HTB to write up, and this one was particularly fun. It has a bit of everything, including a Linux one-liner that every red team should be using during internal enumeration.

With that said, here’s the walkthrough.

Enumeration

As usual, I began with a staged nmap scan:

Using verbose this time because the server was very slow.

So, from the scan I was able to establish that the machine is hosting a web server and a DNS server. The DNS server is subject to a zone transfer, which is unusual, but I decided not to focus on that for the time being.

Visiting the website gives me a login page with no real options to navigate elsewhere:

I decided to run gobuster on it to see if I could find anything of interest that way:

I was able to traverse all of these directories, but most didn’t contain anything interesting. The exception was the /balance-transfer folder, which seemed to house transaction information with usernames and hashed passwords. Running some of the hashes through CrackStation didn’t get me anywhere, so I figured this might also be a dead end.

Just as a quick sanity check, I decided to sort by size. As noted above, the size of each respective file is similar, so I wanted to see if anything stood out. Sorting in ascending order gave me an interesting file:

Poor Christos Christopoulos. His password was strong, but he was the victim of failed encryption. This gave me a foothold into the website:

The support page gives users the option to upload files, so I wanted to try and upload a payload.

Exploitation

Using msfvenom, I generated a .php reverse shell payload and attempted to upload it to the server:

Hmm… I can’t upload it. Seeing no other available avenues, I checked the source code for the page to see if there were any hints about other attack vectors:

Maybe this part isn’t particularly realistic, but I got the hint I needed anyways. Even in a real-world scenario it’s prudent to check the source code.

I changed the file extension for my .php to .htb and tried to reupload:

Assuming the /uploads folder discovered during enumeration was where the file ended up, I knew that accessing it would trigger the shell to run. I set up a listener and visited the page:

I managed to get a reverse shell! As a bonus, I was now able to get the user flag.

Internal Enumeration

I couldn’t access privileged resources, so I knew that privilege escalation was necessary. In order to do that, I had to enumerate the system.

Metasploit couldn’t find anything, nor could Google. But I had another trick…

Remember at the beginning when I said there’s a command that everyone should know for internal enumeration? Here it is:

find / -perm -u=s -type f 2>/dev/null

What does this command do? It finds every file that is executable using an sid instead of a uid. In Linux, files that run with an sid are run as the file owner as opposed to the current user. In many cases, this is necessary and relatively innocuous (for example, “sudo” is an sid program). However, things can quickly become problematic if you have files that are editable by normal users and run as privileged users. A malicious actor could edit a file to spawn a new shell and then run it using the sid to gain access to the file owner’s account. In the case that the file owner is root, that is a catastrophic problem.

None of the sid programs above trigger any alarms in my mind except for “/var/htb/bin/emergency”. Looking inside, we likely don’t even need to edit it to gain a shell, as the hard work has already been done.

Running “ls -l” shows that the file is owned by root, and running it predictably gives me a root shell.

Game, set, match! This was a very fun (and slightly unrealistic) CTF with some important lessons involved. Just goes to show that good enumeration is the key to finding holes in systems.