Silent Monitor Walkthrough | TryHackMe

CorpNet's internal network operations centre has been running quietly for years. Monitoring hosts, logging events, and keeping the infrastructure alive. Or so it seems. A tip from a disgruntled contractor suggests that someone on the NOC team has been cutting corners, leaving doors open, and hiding things in places no one thinks to look.

The portal is up. The services show green. The audit log looks clean.

But clean logs can be written by anyone.

Our job was to get in, move through the system, and find out what is really running behind the secret dashboard.

Let's start with initial enumeration to discover which ports and services are up and running. I used the Nmap tool to gather the information.

Both openSSH and Werkzeug httpd services were running on port 22 SSH and port 5050 HTTP respectively.

Basically, the web application was a network operations monitoring tool, and the page wasn't clickable, so I found nothing. So started URL path enumeration and found a hidden route that was internal after using Gobuster, and it was the login page of NOC.

I tested the login form for SQL injection vulnerabilities and confirmed that the application was vulnerable. I then used a basic SQL injection payload to exploit the vulnerability and successfully bypassed the authentication mechanism, gaining access to the portal.

admin' OR 1=1--

admin' OR 1=1--

After exploring the application, I found nothing clickable except Host Health. In that module, the application is trying to check the connection with multiple private hosts using the ICMP protocol, one at a time. But none of them were reachable, and this could be a way to actually let us communicate with the server that was hosting the current NOC application.

As I was exploring the audit logs, there was a specific command logged that had whoami appended to an encoded "\n", along with the targeted IP, which was requested from the application via an API call. This was a clear example of command injection.

So i captured the request in burpsuite and sent it to the repeater , as per audit logs i tried injecting the command whoami, and it worked. I enumerated the current directory, which revealed a secret config file that leaked the sysadmin user credentials.

As we know, the SSH port was open, so I logged in as sysadmin using the credentials via SSH, and at the root of the path I found the very first flag of the room.

What is the content of user.txt? THM{sQli_4nd_cMd_1nj3ct10n_l3D_y0u_h3re!}

The backups folder in the root directory contained some new information that could potentially help us gain higher privileges.

The readme.txt tells us that infrastructure.kdbx was a backup archive and they export the credentials periodically into this backup archive store.

.kdbx file is also known as a KeePass Password Database, which is an encrypted password database created by the password manager KeePass 2.x to store credentials securely.

To proceed further, I transferred the infrastructure file to my attack machine by starting a Python HTTP server from the sysadmin shell and then downloading the file to my machine.

keepass2john is a tool that used to extract the cryptographic hash from a KeePass database file. Thereafter, I cracked the hash using John, and then I got the key to access the encrypted database.

KeePassXC is a cross-platform password manager. I used it to open the database file with the cracked password hash, which allowed me to access the archived backup folder. In the root of the archive, I found the file I was looking for, but it was password-protected. I was able to retrieve the root password using the following command.

keepassxc-cli show -s infrastructure.kdbx "Root User Password - Sensitive"

keepassxc-cli show -s infrastructure.kdbx "Root User Password - Sensitive"

Using the root password, I got root access to the server as well as the flag on the root path.

What is the content of root.txt? THM{KDBx_V4ul7_H4s_b33n_cr4ck3d_0peN}

Vulnerabilities Found

• Security through obscurity: The NOC login page was only protected by living on a hidden route, which fell the moment directory enumeration (Gobuster) uncovered it.
• SQL injection (authentication bypass): The login form accepted admin' OR 1=1--, letting you skip authentication and reach the portal.
• Command injection: The Host Health check passed user input straight into a system command, confirmed by injecting whoami through the API request.
• Server-side request: The host health feature could reach private internal hosts over ICMP, exposing systems that should have been unreachable.
• Plaintext credentials in config file: secret config file in the working directory leaked the sysadmin username and password.
• Password-based SSH with reused credentials: The leaked sysadmin credentials worked directly over SSH, granting a stable foothold.
• Sensitive backups left readable: the backups folder held a KeePass database accessible to a low-privilege user.
• Weak KeePass master password: The database hash cracked instantly against rockyou with John.
• Root password stored in the credential database: Cracking one weak master password exposed the root password and full system compromise.

Hardening Recommendations

• Do not rely on a hidden URL to protect the admin portal. Put real authentication in front of it and treat the route as if everyone already knows it exists.
• Fix the SQL injection by using parameterised queries or prepared statements everywhere, and never build queries by gluing user input into strings.
• Stop passing user input into system commands. Use safe library calls for tasks like ping instead of shelling out, and if a command truly must run, strictly validate and whitelist what is allowed through.
• Keep credentials out of config files that live alongside the app. Move secrets into a proper secrets manager or protected environment variables, and make sure they are not world-readable.
• Prefer key-based SSH over passwords, disable password login where you can, and never reuse the same credentials across services.
• Move backups out of readable locations, restrict who can access them, and do not leave credential databases sitting where a foothold user can grab them.
• Protect the KeePass database with a long, random master password or a key file so it cannot be cracked from a wordlist.
• Never store the root password in a shared database, rotate it regularly, and actually change the temporary passwords that notes say will be changed later.

Link: https://tryhackme.com/room/silent-monitor