Monitored HTB Writeup | HacktheBox

Introduction

In this post, let’s see how to CTF monitored, If you have any doubt comment down below.

Hacking Phases in Monitored

• Recon
• Nmap Scan
• Enumeration
• User
• Privilege Escalation
• Root

Let’s Begin

Hey you ❤️ Please check out my other posts, You will be amazed and support me by following on youtube.

Let’s Hack Bizness HTB 😌

https://www.youtube.com/@techyrick-/videos

Nmap Scan

Nmap Scan on the target website

nmap -sC -sV -sU -T4 -Pn 10.10.11.248

Besides checking the subdomain name, we also performed a UDP port scan. This not only conserves fuzz but also includes the domain names in the hosts.

Enumeration

The website with the “https” prefix appears like this:

When we clicked the Nagios access button, it redirected us to a login page.

Before attempting to log in or interact with the login page, I plan to search for additional directories or virtual hosts. It’s worth exploring the potential for open redirects as well. I’ll be using the ffuf tool with the specified parameters:

ffuf -w directory…. -u https://nagios.monitored.htb/nagiosxi/FUZZ -recursion -e *.txt,.php,.html,.bak,.jar,.war,.backup,._backup -fw 18

Great, we’ve come across several intriguing results. Of particular interest is the discovery of the “/terminal” directory, which led us to a website named “Shell in a Box.”

I attempted default credentials and SQL injection methods to log in, but unfortunately, I didn’t succeed.

It seems like I’ll need to locate the credentials from another source. Simultaneously, I began fuzzing the “/api/” directory to see if there’s anything noteworthy there.

Additionally, the UDP scan has completed, revealing some additional findings.

It looks like SNMP (Simple Network Management Protocol) is the most intriguing finding here. I’ll need to investigate that soon.

We have come across the “authenticate” directory. However, when I attempt to access it, it raises an issue, indicating that only POST requests are permitted.

In the meantime, I ran an SNMP walk and managed to obtain credentials for SCV.

The credentials obtained are: Username: svc Password: XjH7VCehowpR1xZB

I attempted to log in to “/terminal” and the “/login” page with these credentials, but unfortunately, I was not successful.

Continuing the exploration of “/authenticate,” this time using POST, I received the following response:

I attempted to use the svc credentials here, but encountered the same results. I then decided to try with curl and successfully obtained an Auth_token using the following command:

curl -X POST -k -L -d 'username=svc&password=XjH7VCehowpR1xZB' https://nagios.monitored.htb/nagiosxi/api/v1/authenticate/

Breaking down the curl command:

• -X is used to specify the HTTP method as POST.
• -k is used to perform the operation insecurely, avoiding SSL certificate-related issues.
• -L is used to follow redirects.
• -d is used to send data in the request body, in this case, the username and password.

The Auth_token obtained is: dd49e10b1eb6fc5a94f097d0e0df4cd776d96b87.

I attempted to use the credentials and Auth_token across all available options, but unfortunately, none of them were successful. Consequently, I decided to search for exploits related to Nagios XI.

After investigating recent CVEs, I found three noteworthy ones: CVE-2023–48085 (RCE vulnerability in command_test.php), CVE-2023–48084 (SQL injection allowing unauthenticated attackers to run arbitrary code), and CVE-2023–40933 (SQL injection allowing authenticated attackers to run arbitrary code).

Firstly, I tried the RCE exploit, but encountered difficulties due to a session timeout. Moving on to CVE-2023–40933, I successfully exploited it, obtaining an admin API key.

Additionally, hashes for svc and admin were obtained, but they are salted, so I haven’t pursued them further at this point.

The obtained API Key is: IudGPHd9pEKiee9MkJ7ggPD89q3YndctnPeRQOmS2PQ7QIrbJEomFVG6Eut9CHLL.

Now, it’s time to create an account that we can use to log in. I followed a blog post (https://support.nagios.com/forum/viewtopic.php?f=16&t=42923) for guidance.

According to Nagios documentation, additional parameters like “auth_level” can be added when creating a user (https://assets.nagios.com/downloads/nagiosxi/docs/Understanding-Nagios-XI-User-Rights.pdf).

I crafted the following curl command to add the user:

Now, we have access to the site using the admin credentials (username: dog, password: dog).

From the “Configure” menu, navigate to “Core Configurations” where we can find existing commands and the option to add new ones. Let’s go ahead and add a reverse shell.

Next, navigate to “Services” and choose “Add Service.” Select the previously created reverse shell, and then click on “Run Check Command.” Make sure to have Netcat (nc) ready for use.

Great! You’ve successfully obtained a shell and the user flag. If you have any further steps or questions, feel free to let me know!

Privilege Escalation

I immediately uploaded LinEnum. Here are the interesting findings from its scan:

Certainly! Let’s explore the usage of the “manage_services.sh” script:

Usage: ./manage_services.sh [options]

Options:
-l, –list List all services
-s, –start Start a service
-p, –stop Stop a service
-r, –restart Restart a service
-a, –restart-all Restart all services
-h, –help Show this help message

Certainly! To stop the “npcd” service, you can use the following command:

./manage_services.sh -p npcd

This command will stop the “npcd” service. If you encounter any issues or need further assistance, feel free to let me know!

It sounds like you took the following steps:

1. Deleted the existing “npcd” service.
2. Created a new “npcd” service with a modified configuration to establish a reverse shell back to your machine.

If you encounter any issues or need guidance on the next steps, feel free to ask!

Great job! It looks like you’ve successfully escalated privileges to root. By setting proper permissions, starting the Netcat listener, and restarting the “npcd” service with root privileges, you were able to obtain the root shell and access the root flag.

If you have any more questions, need further assistance, or want to share your progress, feel free to let me know!

Conclusion

I’m glad to hear that you had a fun and rewarding experience with the machine! Figuring out the handling of authentication tokens and APIs can indeed be a challenge, and it’s great that you persevered through it. Privesc exercises like the one you encountered can be straightforward once you identify the right path.

If you ever have more questions or decide to explore similar challenges in the future, feel free to reach out. Learning about tokens and APIs is a valuable skill, and hands-on experiences like the one you had contribute significantly to your overall understanding. Keep up the good work!

---