In this post, I would like to share a walkthrough of the Monitored Machine from Hack the Box

This room will be considered a Medium machine on Hack the Box

What will you gain from the Monitored machine?

For the user flag, you will need to abuse the Nagios XI software, a renowned monitoring solution, which plays a pivotal role in the intricate process of employing a vulnerability chain to gain unauthorized access. This exploit methodology, which encompasses various tactics including SQL Injection techniques, is meticulously orchestrated to establish a firm foothold on the target system.

As for the root flag, you need to abuse the process of privilege escalation necessitates the manipulation of sudo permissions allocated to critical system scripts. This intricate manoeuvre involves exploiting vulnerabilities inherent in the sudo configuration, allowing unauthorized users to elevate their privileges and gain elevated access levels within the system architecture.

Information Gathering on Monitored Machine

Once we have started the VPN connection which requires a download from Hackthebox, we can start

╰─ nmap -sC -sV -oA initial                                                          
# Nmap 7.93 scan initiated Sun Jan 14 21:40:02 2024 as: nmap -sC -sV -oA initial
Nmap scan report for
Host is up (0.27s latency).
Not shown: 987 closed tcp ports (conn-refused)
22/tcp    open     ssh          OpenSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0)
| ssh-hostkey: 
|   3072 61e2e7b41b5d46dc3b2f9138e66dc5ff (RSA)
|   256 2973c5a58daa3f60a94aa3e59f675c93 (ECDSA)
|_  256 6d7af9eb8e45c2026ad58d4db3a3376f (ED25519)
80/tcp    open     http         Apache httpd 2.4.56
|_http-server-header: Apache/2.4.56 (Debian)
|_http-title: Did not follow redirect to https://nagios.monitored.htb/
389/tcp   open     ldap         OpenLDAP 2.2.X - 2.3.X
443/tcp   open     ssl/http     Apache httpd 2.4.56 ((Debian))
|_ssl-date: TLS randomness does not represent time
|_http-server-header: Apache/2.4.56 (Debian)
| tls-alpn: 
|_  http/1.1
|_http-title: Nagios XI
| ssl-cert: Subject: commonName=nagios.monitored.htb/organizationName=Monitored/stateOrProvinceName=Dorset/countryName=UK
| Not valid before: 2023-11-11T21:46:55
|_Not valid after:  2297-08-25T21:46:55
1059/tcp  filtered nimreg
2522/tcp  filtered windb
2909/tcp  filtered funk-dialout
4126/tcp  filtered ddrepl
7938/tcp  filtered lgtomapper
16000/tcp filtered fmsas
16012/tcp filtered unknown
27715/tcp filtered unknown
49176/tcp filtered unknown
Service Info: Host: nagios.monitored.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at .
# Nmap done at Sun Jan 14 21:41:15 2024 -- 1 IP address (1 host up) scanned in 73.66 seconds

Let’s access the website interface

The website interface shows the Nagios XI where you can find more information here

However, there is nothing that we investigate via Burp Suite

When we try to click the button, it redirects us to a login page.

└──╼ $sudo nmap -sU -sV -sC
Starting Nmap 7.93 ( ) at 2024-05-11 09:31 EDT
Host is up (0.33s latency).
Not shown: 993 closed udp ports (port-unreach)
Bug in snmp-win32-software: no string output.
PORT      STATE         SERVICE         VERSION
68/udp    open|filtered dhcpc
123/udp   open          ntp             NTP v4 (unsynchronized)
| ntp-info: 
161/udp   open          snmp            SNMPv1 server; net-snmp SNMPv3 server (public)
| snmp-netstat: 
|   TCP 
|   TCP
|   TCP
|   TCP
|   TCP
|   TCP
|   TCP
|   TCP
|   TCP
|   TCP
|   TCP
|   UDP           *:*
|   UDP          *:*
|   UDP          *:*
|_  UDP          *:*
| snmp-processes: 
|   1: 
|   2: 
|   3: 
|   4: 
|   6: 
|   8: 
|   9: 
|   10: 
|   11: 
|   12: 
|   13: 
|   15: 
|_  16: 
| snmp-info: 
|   enterprise: net-snmp
|   engineIDFormat: unknown
|   engineIDData: 6f3fa7421af94c6500000000
|   snmpEngineBoots: 36
|_  snmpEngineTime: 1d09h50m48s
| snmp-sysdescr: Linux monitored 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64
|_  System uptime: 1d09h50m48.68s (12184868 timeticks)
162/udp   open          snmp            net-snmp; net-snmp SNMPv3 server
| snmp-info: 
|   enterprise: net-snmp
|   engineIDFormat: unknown
|   engineIDData: 5a44ab2146ff4c6500000000
|   snmpEngineBoots: 27
|_  snmpEngineTime: 1d09h50m48s
18156/udp open|filtered unknown
31335/udp open|filtered Trinoo_Register
61685/udp open|filtered unknown
Service Info: Host: monitored

Host script results:
|_clock-skew: 11s

Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 1268.85 seconds

Let’s enumerate more further with ldapsearch

As a result, let’s look at the authenticate page as shown above

We should be able to use snmpwalk command to retrieve the command that we found earlier.

However, we need to enter the credentials for this pop-up box which we found earlier.

As a result, we managed to find some information about the nagios system

CVE-2023-40931 vulnerability

The vulnerability marks a significant milestone in our journey toward authenticated access to Nagios, prompting a meticulous investigation into vulnerabilities. Our efforts culminate in the discovery of an enlightening article on Outpost24, unveiling critical insights into the CVE-2023-40931 exploit – a “SQL Injection in Banner Acknowledgment Endpoint.” This vulnerability arises when users acknowledge a banner, triggering a POST request to /nagiosxi/admin/banner_message-ajaxhelper.php. The POST data contains the intended action and message ID: action=acknowledge banner message&id=3.

Of particular concern is the ID parameter, presumed to be trustworthy but susceptible to manipulation by the client without proper sanitization. This oversight exposes the system to SQL Injection attacks, enabling authenticated users with limited privileges to illicitly access sensitive data housed within tables like xi_session and xi_users. Such data includes emails, usernames, hashed passwords, API tokens, and backend tickets. Notably, the exploitation of this vulnerability does not hinge on the existence of a valid announcement banner ID, rendering it exploitable by threat actors at any given moment.

To abuse the vulnerability, we will be using SQLMap in our exploitation of a documented vulnerability (CVE) characterized by Post-Authentication SQL Injection. Our objective is to acquire the admin API key, stored within the ‘xi_users’ table, through the submission of a POST request to the ‘/nagiosxi/admin/banner_message-ajaxhelper.php’ endpoint via HTTP/1.1. For this purpose, we will utilize the username and password gleaned from the preceding step. This endeavour is integral to our overarching strategy of creating a new user endowed with administrative privileges.

Let’s do some research don’t he vulnerability which can be found here

We should retrieve some information on the server via Burpsuite

From the output, we managed to see a few potential injection points that we can abuse in the latter stage.

We should be using the SQLmap tool to enumerate the database within the monitored machine

After a while, I noticed there was a password hash that used bcrypt

Changing the password on the Nagios System

We should be able to add a new account using the above command.

Let’s access the NagiosXI dashboard by using the password change

Boom! We have successfully accessed the dashboard as shown above.

We can add a new command on the machine

However, we can also catch the reverse shell connection by creating the reverse shell connection on our attacker’s machine

Let’s start our python server

Therefore, let’s begin our listening on the attacker’s machine

The screenshot above shows the command that we can execute by clicking the “Run Check Command

Finally, we have managed to upload the file onto the victim’s machine

We can also insert the command that permits the reverse shell file

Let’s start the command as shown above

At last, we retrieved the reverse shell connection back to us.

Another way to obtain a reverse shell connection on a monitored machine

As usual, we can use a very common method in which we can put the command straightly on the command line

It looks like everything is already in place

As shown in the previous method, we have only to click the button of “Run Check Command”

We can read the user flag by typing the “cat user.txt” command

Escalate to Root Privileges Access on the monitored machine

As usual, we can find the binary that we can abuse in the latter stage. We managed to see a few sh files that we can use to obtain the Root Privileges Access

We should be able to modify the nagios.cfg which we can use to retrieve the SSH id_rsaa file using this method

Let’s execute the sh file as shown above which it will take a few second depending on machine

After a while, we managed to see a lot of files that we could analyze further.

At last, we managed to obtain the SSH id_rsa file and we should be able to copy-paste the key into our machine

Finally, we managed to access the machine via SSH service

Another method to get Root Access

If you look back on the result of the binary file, we should analyze one file such as

We can use any of the services as shown in the screenshot above to abuse the permission

As a result, we managed to find some locations for npcd service on Nagios

There are a few files stored in the directory of Nagios configuration

Let’s create a reverse shell command on the victim’s machine

After a while, we should stop the npcd service on the victim’s machine

We should be starting back up on the service with the sh file

Sadly, we cannot retrieve the reverse shell connection on our attacker’s machine. As a result, we should rename the sh file into npcd file

Let’s give permission to the malicious file

Let’s start the npcd service and there is no error appears like before

Finally, we managed to successfully retrieve the reverse shell connection.

We can read the root flag by typing the “cat root.txt” command