HTB-Season10-Kobold

OS: Linux | Difficulty: Easy

Welcome back everyone , This write-up covers the exploitation path for the Kobold machine from HTB. As always, the methodology here is strictly practical and evidence-based. Let's break down the attack chain.

Initial Enumeration

We kick things off with a standard comprehensive Nmap scan to map the external attack surface:

nmap -Pn -sC -A 10.129.12.212

Open ports:

22 (ssh)
80 (http) -> Redirects to https://kobold.htb/
443 (https) -> Nginx

The Nmap results reveal a domain name (kobold.htb) and indicate wildcard DNS setup (*.kobold.htb) in the SSL certificate subject alternative name. I added kobold.htb to my /etc/hosts file.

Browsing to https://kobold.htb presents a static "Coming Soon" page for the "Kobold Operations Suite".

Since the SSL cert hinted at subdomains, I immediately moved to vhost enumeration using ffuf :

ffuf -u https://kobold.htb/ -H "HOST:FUZZ.kobold.htb" -w path/to/wordlist -mc 200

The fuzzer successfully identified two valid virtual hosts returning 200 OK statuses: bin.kobold.htb and mcp.kobold.htb. I added both to /etc/hosts.

Initial Foothold: MCPJam Exploitation

Navigating to https://mcp.kobold.htb reveals an application called "MCPJam".

Checking the Settings page, we can clearly identify the software version: MCPJam Version: v1.4.2.

A quick search for this specific version reveals it is vulnerable to CVE-2026-23744. I acquired the PoC exploit script and executed it against the target vhost :

python exploit.py mcp.kobold.htb

Repo : https://github.com/d3vn0mi/CVE-2026-23744-POC

The exploit successfully fires, executing our payload. Catching the callback on our Netcat listener grants us an initial shell as the ben user.
After stabilizing the shell using Python's pty module, we can navigate to the home directory and grab our first digital proof.

(Don't forget to grab your user flag here!) User Flag: cat user.txt

Privilege Escalation: Docker Socket Abuse

With initial access secured, I moved to internal enumeration. Checking the user's group memberships reveals a critical misconfiguration: the ben user is a member of the docker group.

Membership in the docker group is essentially functionally equivalent to root access. It allows us to instantiate a new container and mount the host's root filesystem into it, completely bypassing standard Linux file permissions.

First, I ensured the group permissions were active in the current session:

newgrp docker

Next, I executed the privilege escalation payload. This command runs a new Alpine container (using an image already present on the system), mounts the host's root directory (/) to /hostfs inside the container, and drops us into a root shell:

docker run -it -u root -v /:/hostfs --entrypoint /bin/sh privatebin/nginx-fpm-alpine:2.0.2

We are now root inside the container with full read/write access to the host's filesystem. Navigating to /hostfs/root, we can claim the final flag.

Root Flag: cat root.txt

Return to Home