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

┌─[darknite@parrot]─[~/Documents/htb/Monitored]
╰─ nmap -sC -sV -oA initial 10.10.11.248                                                          
# Nmap 7.93 scan initiated Sun Jan 14 21:40:02 2024 as: nmap -sC -sV -oA initial 10.10.11.248
Nmap scan report for 10.10.11.248
Host is up (0.27s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT      STATE    SERVICE      VERSION
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 https://nmap.org/submit/ .
# 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.

┌─[darknite@parrot]─[~/Documents/htb/monitored]
└──╼ $sudo nmap -sU -sV -sC 10.10.11.248
Starting Nmap 7.93 ( https://nmap.org ) 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  0.0.0.0:22           0.0.0.0:0
|   TCP  0.0.0.0:389          0.0.0.0:0
|   TCP  10.10.11.248:35464   10.10.14.73:1234
|   TCP  10.10.11.248:56364   10.10.14.73:1339
|   TCP  10.10.11.248:58216   10.10.14.73:1339
|   TCP  127.0.0.1:25         0.0.0.0:0
|   TCP  127.0.0.1:3306       0.0.0.0:0
|   TCP  127.0.0.1:5432       0.0.0.0:0
|   TCP  127.0.0.1:7878       0.0.0.0:0
|   TCP  127.0.0.1:46498      127.0.1.1:80
|   TCP  127.0.0.1:46502      127.0.1.1:80
|   UDP  0.0.0.0:68           *:*
|   UDP  0.0.0.0:123          *:*
|   UDP  0.0.0.0:161          *:*
|_  UDP  0.0.0.0:162          *:*
| 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 https://nmap.org/submit/ .
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 manage_services.sh


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