Htb on Michael Dunn

Writing a Mock Pentest Report

Tue, 28 Jul 2026 00:00:00 +0000

A few months ago, my friend and I were inspired by some other peers to take our redteaming HackTheBox exercises a step further: writing a full mock penetration test report.The cover page generated for us by Claude Sonnet 5.

They themselves were fascinated by what our school’s award winning C3 team does twice per year in their CCDC competitions. UCF C3 team earlier this year during the NCCDC competition.

During the course of 24 hours, a team of no more than 10 people participate in a hackathon-like competition to probe, poke at, and, finally, document vulnerabilities of a multi-machine network that culminates in a typically ~100-page report that simulates a real-world penetration test.

Myself and my friend, Stephen, set out to take any HackTheBox machine and do the same thing. In the process, we learned a lot!

Hacking the Box

If you’re not already aware, HackTheBox is a free platform that allows users to break into intentionally vulnerable machines and “capture the flag” that awaits for the user upon successful exploitation. My friends and I use this website a ton to practice our redteaming skills (we even keep a scoreboard on the UCF Discord server).

Silentium is an easy-rated, CVE-heavy HackTheBox machine that allowed us to focus mostly on the technical writing aspect of this challenge and less of the redteaming part. In the future, I’d like to make more mock reports on machines offered by HackTheBox that allow me to go into more detail on specific processes for exploiting the system rather than the technical details (sometimes a bit over our head) offered by the exploit we stumbled across while enumerating the machine for vulnerabilities.

Gathering Inspiration

The first thing we had to ask before going in and writing was: “what does a real, official pentest report look like?” Luckily, we didn’t have to wonder. There are plenty of resources out in the wild that offered us a glimpse into how pentest reports are structured - textually and visually. So, we spent a lot of time perusing this repository and compiling visual elements throughout the writing process that we found cool. More importantly, it gave us some insight into the appropriate length of certain sections, where figures should be inserted, and small things like tone selection.

Writing

It just so happens that the semester in college that we wrote this report was the semester that I was taking a professional writing class, which not only meant that my writing muscles had been worked recently, but also that I understood a key part of writing professional reports. What I had in mind was to balance the report in a “PAM” triangle, meaning not just prioritizing the Purpose of the report, but also the Message and how it’s conveyed, and the Audience it’s written for. This appears to be an adaptation of Aristotle’s Rhetorical Triangle. One variation of the Rhetorical Triangle.

Essentially it just reminded us that for the purposes of this “assignment”, we’d be writing so that the report can be understood across a wide spectrum of C-suites, senior-level technicians, and lower-level vulnerability researchers and security engineers. After all, the people at a company that approve a large sum of money to be used for commissioning a pentest report want to understand the value that they received from such an investment. Likewise, the details of a successful exploitation by the pentesters is a useful vector for anybody at the company that works to secure their digital infrastructure.

To cover each of the roles we were catering to, each section existed for a purpose. For instance, plenty of summaries existed before the meat of the report (findings and their CVSS scores). This provided an introduction to the specifics of the engagement to ground not only potentially tech-unsavvy individuals but also their engineers. Even in the individual finding reports, impact summaries are provided to help an employee understand the scope of a particular issue.

Providing engineers with clear reproduction steps will go a long way in helping them quickly identify where the issue exists and remediating it, with or without our suggestions.

Equally (and arguably more) effective for communicating some of these ideas at a high-level are visuals.

Visuals

One important aspect of writing an effective report is conveying things visually, like the layout of the network. Below, I documented the attack chain that a threat actor could take to gain root access on the host system, incorporating the network architecture into said path. A visual that I created with draw.io.

We also wanted to highlight the most important vulnerabilities that we found in the stack before any others. So, the assessment findings are sorted from highest to least severity and color-coded accordingly. Further, in a heavily-inspired way from a “Vuln Table” I had seen in the repository mentioned earlier, we kept things brief and “compressed”. Also, hyperlinks! Assessment findings in the report followed by our vulnerability summary table

Code blocks are presented inside of a 1x1 table in monospace font; censor sensitive information:

Quote blocks are not the same as code blocks:

Conclusion

I gained valuable soft skills throughout this exercise like designing visuals, working with word editors, and conveying complex ideas to a wide range of people. It also tested my understanding of the very engagement that my friend and I spent no longer than a day on (plus one more in the beginning of the CTF). I hope to produce more like this in the future!

HackTheBox Writeup - "Pterodactyl"

Fri, 03 Apr 2026 00:00:00 +0000

Pterodactyl is a medium difficulty Linux HackTheBox machine: https://app.hackthebox.com/machines/Pterodactyl?sort_by=created_at&sort_type=desc

Reconnaissance

I ran a standard nmap service scan:

Not shown: 986 filtered tcp ports (no-response), 10 filtered tcp ports (admin-prohibited)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.6 (protocol 2.0)
80/tcp open http nginx 1.21.5
443/tcp closed https
8080/tcp closed http-proxy

I navigated to the web server, which had an unresolvable domain name: pterodactyl.htb. I added the IP to my hosts to resolve it in my browser:

I did a fuzz using SecList’s raft-medium-files on the root directory, adding php and txt extensions just as a standard practice: ffuf -u http://pterodactyl.htb/FUZZ -w raft-medium-files.txt -e .php,.txt -c

The fuzz returned files such as index.php, phpinfo.php, global.css, and changelog.txt. Some things in changelog included useful version information about the server like: “[Installed] Pterodactyl Panel v1.11.10”, “MariaDB 11.8.3 backend.” We’ll also collect information in phpinfo.php which is a valuable trove of config information related to the PHP server.

I also make it a habit to enumerate through subdomains, which returned a panel.pterodactyl.htb:

After iterating for a while through various version numbers found in phpinfo.php for vulnerabilities, I found a critical severity exploit titled CVE-2025-49132 with arbitrary write privileges consistent with changelog.txt’s claim of the server’s Minecraft Pterodactyl Panel <v1.11.9. A PoC published by YoyoChaud)allowed for easy testing.

Upgrading TTY without Python

I’m used to getting a clearer shell by using Python, but that’s not installed n this box. We can also use the script command to effectively do the same thing:
script /dev/null -c bash
And then proceed with the standard backgrounding: Ctrl+Z, echoing the terminal and bringing the background process to the foreground: stty raw -echo; fg, using reset and export TERM=xterm.

User Privilege Escalation

Earlier, in php.info, we discovered that a mysqli server also runs on the server on it’s default port, 3306. This is confirmed when we run env to output environment variables to our terminal (truncated):

DB_PORT=3306
DB_HOST=127.0.0.1
HASHIDS_SALT=pKkOnx0IzJvaUXKWt2PK
PWD=/var/www/pterodactyl/public
APP_KEY=base64:UaThTPQnUjrrK61o+Luk7P9o4hM+gl4UiMJqcbTSThY=
DB_PASSWORD=PteraPanel
APP_URL=http://panel.pterodactyl.htb
DB_USERNAME=pterodactyl
APP_SERVICE_AUTHOR=pterodactyl@pterodactyl.htb
SESSION_DRIVER=redis
DB_CONNECTION=mysql
DB_DATABASE=panel
_=/usr/bin/env

We can connect by using mysql on the box: mysql -u pterodactyl -pPteraPanel, but: ERROR 1045 (28000): Access denied for user 'pterodactyl'@'localhost' (using password: YES)

I figure I’ll manually specify 127.0.0.1 rather than allowing mysql to resolve to localhost using -h 127.0.0.1, and I can successfully see our databases, notably the locked panel:

MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| panel |
| test |
+--------------------+
3 rows in set (0.001 sec)

panel’s users table contains some hashes (of which I couldn’t crack):

I poked around in the root /var/www/pterodactyl directory and found the artisan binary, of which I could potentially just create my own user using artisan p:user:make:

Which is then appended to the mysql users db:

So, I’ll try logging into the pterodactyl panel with my new credentials (mdunn99:password). We have direct access to the other users we saw earlier in the database and can change their passwords:

Upon numerous SSH attempts, I was still prompted with a password requirement, and overwriting those users’ passwords was preventing me from using it as a potential duplicate password for the SSH password.

I revisited the cracking attempt and successfully cracked user phileasfogg3’s bcrypt hash which matched their SSH password, and retrieved the user.txt flag.

Root Privilege Escalation

As I’m checking out files with capabilities and anything that looks interesting on the file system (including the previously mentioned artisan binary), I’m running a linpeas.sh instance, which notifies me that there are some mail messages on the phileasfogg3 user. Let’s read:

From headmonitor@pterodactyl Fri Nov 07 09:15:00 2025
Delivered-To: phileasfogg3@pterodactyl
Received: by pterodactyl (Postfix, from userid 0)
id 1234567890; Fri, 7 Nov 2025 09:15:00 +0100 (CET)
From: headmonitor headmonitor@pterodactyl
To: All Users all@pterodactyl
Subject: SECURITY NOTICE — Unusual udisksd activity (stay alert)
Message-ID: 202511070915.headmonitor@pterodactyl
Date: Fri, 07 Nov 2025 09:15:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Attention all users,

Unusual activity has been observed from the udisks daemon (udisksd). No confirmed compromise at this time, but increased vigilance is required.

Do not connect untrusted external media. Review your sessions for suspicious activity. Administrators should review udisks and system logs and apply pending updates.

Report any signs of compromise immediately to headmonitor@pterodactyl.htb

— HeadMonitor
System Administrator

grepping systemctl for udisks confirms this service is running:

phileasfogg3@pterodactyl:~> systemctl | grep udisks
udisks2.service ... loaded active running | Disk Manager

Per the Arch Linux wiki::

udisksd(8) is started on-demand by D-Bus and should not be enabled explicitly. It can be controlled through the command-line with udisksctl(1).

Running udisksctl dump will include the version number for udisks2: 2.9.2, which reveals a vulnerability that affects a few operating systems. To confirm if the operating system of the box is vulnerable, I read /etc/os-release: openSUSE Leap 15.6, which is a listed vulnerable target for udisks2 versions >= 2.9.2: Source: https://www.suse.com/security/cve/CVE-2025-8067.html

A PoC is published by born0monday. After running it, I’m unfortunately met with this error:

gi.repository.GLib.Error: g-io-error-quark: GDBus.Error:org.freedesktop.UDisks2.Error.NotAuthorizedCanObtain: Not authorized to perform operation (36)

A published seclists.org mail/blog provides us with a helpful hint for getting around this issue:

So really depends how is your session classified and yes, the attack surface is slightly lower for non-local seats. However, combine it with other CVEs, notably CVE-2025-6018, and you have a bigger problem.

CVE-2025-6018: LPE from unprivileged to allow_active in *SUSE 15’s PAM https://www.openwall.com/lists/oss-security/2025/06/17/4

which led me to:

CVE-2025-6018: LPE from unprivileged to allow_active in SUSE 15’s PAM CVE-2025-6019: LPE from allow_active to root in libblockdev via udisks

and a website that walks me through the whole process of exploiting openSUSE Leap 15 “via the udisks daemon.” I successfully create a malicious payload (on the attack machine) and mount it using a loop block (with udisks) on the victim machine, giving me a root shell.