Kobold HTB Write Up

Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the Kobold 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

Kobold is an easy difficulty Linux machine on Hack The Box that focuses on web enumeration, API abuse, and container-based privilege escalation. The machine demonstrates how exposed API documentation and misconfigured services can lead to full system compromise.

The attack begins with Nmap enumeration, where I identified open ports 22 (SSH), 80 (HTTP), and 443 (HTTPS), all pointing toward a domain-based web application (kobold.htb). Moving into API enumeration, I discovered an exposed OpenAPI specification on a non-standard port, revealing authentication endpoints and API key functionality.

Next, I performed subdomain enumeration, which led to the discovery of a hidden subdomain: mcp.kobold.htb. After updating my system via host configuration, I was able to properly resolve and interact with this subdomain.

Further API enumeration (subdomain) revealed a critical endpoint: /api/mcp/connect. Researching this endpoint uncovered an unauthenticated command injection vulnerability (CVE-2026-23520), which became the entry point for exploitation.

Using this vulnerability, I gained an initial foothold (RCE via MCP) by executing commands remotely and obtaining a shell as the user ben. From there, I moved into privilege enumeration, where I checked group memberships and identified inconsistencies with Docker access.

Through Docker enumeration, I confirmed that Docker privileges were available by switching groups using sg, which allowed me to list available images. This indicated a viable path for privilege escalation.

Finally, I achieved privilege escalation (Docker breakout) by running a container with the host filesystem mounted. This allowed me to read /root/root.txt, successfully obtaining the root flag and fully compromising the machine.

Overall, Kobold is a great example of chaining API misconfigurations, command injection, and Docker abuse to move from initial access to root in a clean and realistic attack path.

The first step in owning the Kobold 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:

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

Nmap Enumeration

I ran an initial service and version scan to understand the attack surface of the target.

The scan revealed three open ports: 22 (SSH), 80 (HTTP), and 443 (HTTPS). SSH is running OpenSSH 9.6p1 on Ubuntu, which could be useful later for authentication attempts if credentials are found. Both web ports are served by Nginx 1.24.0 and redirect to kobold.htb, indicating a domain-based setup, so I added it to my hosts file. The SSL certificate confirms the presence of kobold.htb and a wildcard subdomain, suggesting potential virtual hosts to enumerate. Based on this, I decided to focus on web enumeration as the primary attack vector.

API Enumeration

I enumerated the API service running on port 3552 to understand its structure and available endpoints.

The response exposed an OpenAPI specification, revealing multiple endpoints related to authentication and API key management. I observed a /auth/login schema requiring a username and password, which suggests a potential authentication entry point. The presence of JWT tokens and refresh tokens indicates session-based access control. Additionally, the API key creation schema shows that full API keys are only displayed once, which could be useful if I gain access. Based on this, I decided to focus on authentication and API interaction as the next step.

Subdomain Enumeration

I enumerated virtual hosts by fuzzing the Host header to discover hidden subdomains on the target.

The scan returned multiple valid responses, mostly common infrastructure subdomains returning 301 redirects, indicating they exist but may not be interesting. While reviewing the results, I discovered mcp.kobold.htb, which was not part of the default wordlist output and stood out as a potentially custom application. This suggested the presence of an additional attack surface beyond the main domain. Based on this finding, I decided to pivot my enumeration towards this newly discovered subdomain.

Host Configuration

I added the discovered domains to my local hosts file to ensure proper resolution during further testing.

This allowed my system to resolve both kobold.htb and mcp.kobold.htb to the target IP locally. Without this step, the web server would not correctly respond to virtual host requests. After confirming the entries were added successfully, I was able to interact with both domains directly in my browser and tools. This set the stage for deeper enumeration of the newly discovered subdomain.

API Enumeration (Subdomain)

I enumerated the API on the newly discovered subdomain to check for exposed endpoints.

The request returned a 301 redirect, indicating that the service enforces HTTPS rather than HTTP. This suggested the API is still accessible but requires the correct protocol. From earlier enumeration, I had already identified a key endpoint: /api/mcp/connect, which appears to handle MCP server connections. This confirmed that the subdomain hosts a separate API service with its own functionality. Based on this, I proceeded with further interaction over HTTPS to explore the endpoint.

Initial Foothold (RCE via MCP)

I researched the /api/mcp/connect endpoint and identified CVE-2026-23520, an unauthenticated command injection vulnerability affecting Arcane MCP Server. The flaw allows arbitrary command execution through the serverConfig.command parameter without requiring authentication. With a CVSS score of 9.8, this presented a direct path to remote code execution.

I first set up a listener on my attacker machine to catch the reverse connection.

Next, I crafted and sent a malicious request to the vulnerable endpoint, injecting a command to execute docker images and pipe the output back to my listener.

After sending the payload, I received a connection on my listener, confirming successful command execution on the target. The response revealed I was running as user ben (uid=1001), indicating I had achieved an initial foothold on the system. This confirmed the vulnerability was exploitable and gave me a shell to continue post-exploitation.

User Flag

With command execution confirmed, I leveraged the same vulnerability to retrieve the user flag from the system. Instead of spawning a shell, I directly exfiltrated the flag file using a reverse connection.

I first started a fresh listener on my attacker machine to capture the output.

Next, I crafted a payload to read /home/ben/user.txt and send its contents back to my listener using netcat.

After sending the request, my listener received a connection from the target host, confirming successful execution.

The contents of the file were returned, revealing the user flag, which confirmed I had successfully compromised the user account and completed this stage of the challenge.

Hurray!!! I got the user flag.

Privilege Enumeration

After obtaining code execution, I proceeded to enumerate the current user’s privileges and group memberships. I wanted to confirm whether I had access to any privileged groups such as Docker.

I first started a listener on my attacker machine to capture the output.

Next, I sent a request to execute the id command on the target and return the result via netcat.

htb season10 kobold linux machine write up

After triggering the payload, my listener received a connection with the execution result.

The output showed I was running as ben (uid=1001) with group operator (gid=37). Interestingly, the Docker group was missing, even though it was likely present on the system. This behavior occurs because non-interactive command execution does not inherit supplementary groups. Based on this, I suspected I might still be able to leverage Docker privileges through other methods for privilege escalation.

Docker Enumeration

Since the Docker group was not visible in the previous check, I attempted to manually activate it using the sg (switch group) command. This would allow me to execute commands with Docker group privileges.

I first started a fresh listener on my attacker machine to receive the output.

Next, I crafted a payload that switches to the Docker group and runs docker images, sending the results back to my listener.

After sending the request, my listener received a connection containing the output.

write up kobold hack the box walkthrough

The result confirmed that Docker access was indeed available, listing images such as mysql and privatebin/nginx-fpm-alpine. This validated that I could execute commands within the Docker group context. With this level of access, I identified a clear path for privilege escalation by interacting with Docker containers or mounting the host filesystem.

Privilege Escalation (Docker Breakout)

With confirmed Docker access, I moved to escalate privileges by abusing container capabilities. Since Docker can mount the host filesystem, I leveraged this to access sensitive files as root.

I first started a fresh listener on my attacker machine to capture the output.

kobold machine user flag root flag solution write up walkthrough full pdf solution

Next, I crafted a payload that runs a Docker container as root, mounts the host filesystem (/) into /hostfs, and reads the root flag.

After sending the payload, the container executed with root privileges and accessed the host filesystem. My listener received a connection containing the contents of /root/root.txt.

The returned value was the root flag, confirming full system compromise. By abusing Docker group privileges and mounting the host filesystem, I successfully escalated to root and completed the machine.

Hurray!!! I got the root flag and with that the machine was officially pwned.

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 ☕

Comment below the machine you want me to drop next!!! You can buy me a $15 coffee/month or subscribe for a year premium subscription with a weekly release on every active machine [you will get the HTB write ups two days after each machines are released]