Pterodactyl Hack the Box Walkthrough

Welcome to my cybersecurity blog where I share Hack the Box walkthroughs, ethical hacking tutorials, Android malware analysis, reverse engineering, and cybersecurity learning guides.

In this blog post, I have demonstrated how I owned the Pterodactyl machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs. You can also test and grow your penetration testing skills, from gathering information to reporting. If you are new to this blog, please do not forget to like, comment and subscribe to my YouTube channel and follow me on LinkedIn for more updates.

About the Machine

Pterodactyl is a Medium difficulty Linux machine on Hack the Box.

The first step in owning the Pterodactyl machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:

Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the Giveback machine and I was assigned an IP address (10.129.2.65).

Nmap Enumeration

To begin the enumeration phase, I ran an Nmap scan against the target to identify open ports, exposed services, and potential attack vectors.

I used the -sC flag to run Nmap’s default scripts, -sV to detect service versions, and -A to enable aggressive enumeration, which includes OS detection and traceroute. This allowed me to gather as much information as possible in a single scan.

The scan confirmed that the host was online and reachable:

Most TCP ports were filtered, indicating that a firewall was actively restricting access and reducing the exposed attack surface:

This suggests that only specific services were intentionally exposed.

The scan revealed two open ports:

Port 22 was running OpenSSH 9.6, which provides remote administrative access. While this service was accessible, it would require valid credentials or a private key to authenticate. At this stage, it did not present an immediate entry point but would likely be useful later once credentials were obtained.

Port 80 was running an nginx web server version 1.21.5, which immediately became the primary focus for initial access. Nmap also reported the following:

This indicated that the web server was configured to redirect requests to the hostname pterodactyl.htb. Since this hostname was not yet resolvable locally, it suggested that the application relied on virtual host routing. This is a common configuration where the server delivers different content depending on the hostname used in the request.

Additionally, ports 443 and 8080 were closed:

This confirmed that the web application was only accessible over HTTP.

Nmap’s OS detection results indicated that the target was running a Linux-based operating system:

Based on these results, the attack surface was minimal, with the web server on port 80 presenting the most promising entry point. The redirect to pterodactyl.htb strongly suggested that further web enumeration would be required to identify potential vulnerabilities and gain initial access.

Virtual Host Enumeration

After identifying that the web server redirected requests to pterodactyl.htb, I navigated to the target IP address in my browser to observe its behavior. Upon visiting the page, I was redirected to a new hostname:

This confirmed that the application was using virtual host–based routing, where different hostnames resolve to the same server but serve different web content. Since this hostname was not resolvable by default on my local system, I needed to manually map it to the target IP address.

To accomplish this, I added both discovered hostnames to my /etc/hosts file so my system could resolve them correctly.

This command appended the following entries to my hosts file:

By doing this, I ensured that any requests made to pterodactyl.htb or play.pterodactyl.htb would resolve to the target machine at 10.129.2.65.

After updating the hosts file, I revisited the site in my browser and was successfully able to access the web application hosted on play.pterodactyl.htb. The page appeared to be a Minecraft server landing page called MonitorLand, displaying server connection information and indicating that the system was likely using the Pterodactyl game server management panel.

The discovery of multiple subdomains suggested that additional functionality or administrative interfaces might exist on other virtual hosts. This made virtual host enumeration a high-priority next step, as administrative panels and backend services are commonly hosted on separate subdomains in real-world environments and CTF scenarios.

At this point, I proceeded with further enumeration of the web application to identify additional attack vectors and potential entry points.

Subdomain Enumeration

After successfully accessing play.pterodactyl.htb, I wanted to check if additional subdomains were configured on the server. In many environments, especially those running management platforms like Pterodactyl, administrative interfaces are often hosted on separate subdomains that are not directly linked from the main page.

To enumerate potential subdomains, I used ffuf, a fast web fuzzer, and performed virtual host fuzzing by modifying the Host header while sending requests to the target.

In this command, I specified the target URL using -u, and used the -H flag to inject different subdomains into the Host header using the FUZZ keyword. I provided a wordlist containing 5000 common subdomain names with the -w option. Additionally, I used the -fs 145 filter to exclude responses with a size of 145 bytes, which corresponded to the default response returned for non-existent subdomains. This helped eliminate false positives and focus only on valid results.

The scan returned the following result:

This indicated that the subdomain panel.pterodactyl.htb existed and returned a valid HTTP 200 response. The response size was different from the filtered baseline response, confirming that this was a legitimate virtual host.

The discovery of the panel.pterodactyl.htb subdomain was highly significant, as the name strongly suggested it was hosting the Pterodactyl administrative panel, which is used to manage game servers. Administrative panels often expose authentication functionality and may contain vulnerabilities such as weak credentials, misconfigurations, or exploitable features.

Panel Enumeration and Vulnerability Research

After discovering the panel.pterodactyl.htb subdomain, I added it to my /etc/hosts file and navigated to it in my browser. This presented me with a login interface located at:

After doing this, I was able to navigate to http://panel.pterodactyl.htb, which presented the login interface for the Pterodactyl management panel.

This presented a promising attack surface and became the next focus of my enumeration efforts in order to obtain valid credentials or identify potential vulnerabilities.

The page was clearly the authentication portal for the Pterodactyl Panel, a widely used open-source game server management platform. The interface prompted for a username or email and password, indicating that this panel was used to manage server instances, users, and system configurations.

At this point, since direct access required valid credentials, I shifted my focus to identifying potential vulnerabilities in the Pterodactyl Panel itself. Management panels are often high-value targets because they typically run with elevated privileges and interact directly with backend services.

To identify potential exploits, I began researching publicly disclosed vulnerabilities affecting the Pterodactyl Panel. During this process, I discovered that certain versions of the panel were vulnerable to CVE-2025-49132.

This vulnerability affects the Pterodactyl Panel and can allow attackers to perform unauthorized actions under specific conditions. Since this was a web-based management interface exposed externally, it immediately became a strong candidate for initial access.

The discovery of this vulnerability was particularly important for several reasons:

The panel was publicly accessible without authentication.
It was running a known software platform with publicly disclosed vulnerabilities.
Administrative panels often interact directly with backend services, increasing the impact of exploitation.

Since the login portal was the entry point to the management system, and a known vulnerability existed for this software, I proceeded with targeted enumeration and exploitation attempts against the panel to determine whether the target was running a vulnerable version.

This shifted my attack strategy from general enumeration to vulnerability-specific exploitation, focusing on leveraging CVE-2025-49132 to gain unauthorized access to the system.

Panel Endpoint Enumeration

After identifying that the panel.pterodactyl.htb instance was likely vulnerable to CVE-2025-49132, I began interacting directly with panel endpoints to observe how the application handled unauthenticated requests.

Based on my research, the vulnerability involved improper handling of locale-related resources. To test this, I requested the locale JSON file from the panel using curl while enabling verbose output to inspect the full HTTP transaction.

The verbose output confirmed that my system successfully resolved the hostname and established a connection to the target server:

This verified that the virtual host configuration was working correctly and that the panel was actively responding to requests.

The server responded with an HTTP 200 OK status:

This revealed several important details about the backend environment:

The web server was running nginx 1.21.5
The application was powered by PHP 8.4.8
The endpoint was publicly accessible without authentication

The presence of the X-Powered-By header confirmed that the Pterodactyl Panel was running on PHP, which aligned with its known architecture. This was particularly relevant because CVE-2025-49132 affects the PHP-based Pterodactyl Panel, making this endpoint a likely attack surface.

More importantly, the response also included session-related cookies:

This indicated that the server automatically issued a valid session and CSRF token even without authentication. This behavior suggested that the application was initializing session context prior to login, which is a necessary component of many authentication bypass or deserialization vulnerabilities.

The response body returned JSON content:

Although the response appeared minimal, the fact that the endpoint was accessible and returned valid application-generated content confirmed that the locale handling functionality was exposed. Since CVE-2025-49132 involves improper handling of locale-related functionality, this endpoint became a critical component for exploitation.

At this stage, I had confirmed the following:

The Pterodactyl Panel was accessible and functional
The application was running on PHP
The locale endpoint was accessible without authentication
The server issued valid session and CSRF tokens automatically
The vulnerable functionality was exposed and reachable

With this information, I proceeded to craft targeted requests designed to exploit CVE-2025-49132, leveraging the locale handling mechanism to gain unauthorized access to the system.

Vulnerability Validation (CVE-2025-49132)

After confirming that the target was running the Pterodactyl Panel and that the locale endpoint was accessible, I proceeded to validate whether the instance was actually vulnerable to CVE-2025-49132. During my research, I found a public proof-of-concept exploit published on GitHub, which could be used to test and exploit the vulnerability.

To obtain the exploit, I cloned the repository to my local machine:

The repository was successfully downloaded, containing the proof-of-concept script along with supporting documentation and dependency files:

The presence of the CVE-2025-49132-PoC.py script indicated that the exploit was implemented in Python and could be used to test whether the target panel was vulnerable.

Next, I navigated into the cloned directory:

To verify whether the target was vulnerable, I executed the proof-of-concept script in test mode and specified the panel URL:

The script responded with the following output:

This result confirmed that the target instance was indeed vulnerable to CVE-2025-49132. The output also revealed an important detail: the script was able to successfully traverse directories and identify the internal pterodactyl application path, which strongly suggested the presence of a directory traversal vulnerability.

This vulnerability allowed the exploit to access files outside the intended directory scope, which could potentially expose sensitive application files such as configuration files, credentials, or other critical resources.

Successfully confirming the vulnerability meant that I now had a viable path to exploitation. Since the Pterodactyl Panel typically runs with elevated privileges and manages backend services, exploiting this vulnerability could allow me to retrieve sensitive information or gain unauthorized access to the system.

With the vulnerability confirmed, I proceeded to use the exploit to extract sensitive data from the application and move toward obtaining initial access.

Exploiting CVE-2025-49132 to Retrieve Database Credentials

After confirming that the target was vulnerable to CVE-2025-49132, I proceeded to exploit the vulnerability manually to extract sensitive configuration data from the Pterodactyl Panel.

Based on my research and the proof-of-concept script, the vulnerability stemmed from improper input validation in the locale handling functionality. Specifically, the application failed to properly sanitize user-supplied input in the locale and namespace parameters, making it possible to perform a directory traversal attack and access internal configuration files.

To exploit this behavior, I crafted a request to the vulnerable locale endpoint and used curl to supply traversal sequences that would access the database configuration file.

In this request:

I used the -G flag to send the parameters as a GET request.
I supplied locale=../../../pterodactyl to traverse outside the intended directory and reach the root application folder.
I specified namespace=config/database to target the database configuration file.

The server responded successfully and returned the contents of the database configuration:

This response confirmed that the directory traversal attack was successful and allowed me to read sensitive internal application files.

Most importantly, the output revealed valid database credentials:

Parameter	Value
Database	panel
Username	pterodactyl
Password	PteraPanel
Host	127.0.0.1
Port	3306

This was a critical finding, as configuration files often contain plaintext credentials that can be reused for authentication elsewhere on the system.

The successful retrieval of these credentials confirmed that the vulnerability allowed arbitrary file disclosure, which significantly expanded my attack surface. Since administrators frequently reuse passwords across services, these credentials became strong candidates for authentication against other exposed services such as SSH or the Pterodactyl Panel itself.

At this stage, I had successfully leveraged CVE-2025-49132 to extract sensitive credentials from the system, bringing me one step closer to obtaining initial access.

Dumping Application Secrets via CVE-2025-49132

After successfully confirming the directory traversal vulnerability and manually retrieving the database credentials, I proceeded to use the proof-of-concept exploit to automate the extraction of additional sensitive configuration data from the Pterodactyl Panel.

The exploit included a dump mode, which attempts to retrieve critical application configuration files, including encryption keys and database credentials. These values are highly sensitive because they can be used for authentication bypass and session forgery.

To perform the dump, I ran the following command:

The exploit began by targeting the application's main configuration file:

This request leveraged the same directory traversal vulnerability to access the internal application configuration. The exploit successfully retrieved the following information:

The most critical value obtained here was the APP_KEY, which is used by the Laravel framework to encrypt and sign session data.

This was an extremely important discovery because Laravel uses the APP_KEY to generate and validate session cookies. If an attacker obtains this key, they can forge valid session cookies and impersonate authenticated users without needing their credentials.

The exploit script explicitly confirmed this:

This indicated that the retrieved key could be used to create a valid administrative session, effectively bypassing authentication entirely.

Next, the exploit attempted to retrieve the database configuration:

This request was also successful and returned the database connection string:

This confirmed the database credentials I had previously retrieved manually. The database was running locally on the target system, and the credentials were stored in plaintext within the configuration file.

At this point, I had successfully extracted two critical secrets from the application:

The APP_KEY, which could be used to forge authenticated sessions
The database credentials, which could potentially be reused across services

The retrieval of the APP_KEY was especially significant because it provided a direct path to authentication bypass through session forgery. Since the Pterodactyl Panel relies on Laravel session encryption, possessing this key meant I could generate a valid session cookie and gain administrative access without needing a username or password.

With these secrets in hand, I moved on to leverage the APP_KEY to forge an authenticated session and gain access to the administrative panel.

Gaining Remote Code Execution via CVE-2025-49132

After successfully extracting the APP_KEY and database credentials, I continued my research on CVE-2025-49132 to identify methods for achieving remote code execution. During this process, I discovered a modified exploit repository that extended the original proof-of-concept and provided functionality to gain an interactive shell on the target system.

To use this exploit, I cloned the modified repository to my local machine:

Hack The Box #Season10 #Episode2 medium rated #Linux Machine #Pterodactyl

The repository was successfully cloned, and upon inspecting its contents, I found the exploit script ape1.py, which was designed to leverage the vulnerability and obtain remote code execution.

I then executed the exploit script and specified the target host, enabling interactive mode to gain shell access:

The exploit initialized successfully and displayed the following output:

This confirmed that the exploit had successfully leveraged CVE-2025-49132 to achieve remote code execution on the target system.

The appearance of the shell> prompt indicated that I now had the ability to execute system commands remotely on the server. This effectively bypassed authentication and granted direct command execution capabilities through the vulnerable Pterodactyl Panel.

This was a critical milestone in the attack chain, as it provided initial access to the system. With remote command execution established, I could begin enumerating the underlying operating system, identifying users, and searching for privilege escalation vectors.

Hosting a Reverse Shell Payload

After gaining remote command execution through the exploit, I needed a more stable and fully interactive shell to properly enumerate the system and continue the attack. While the exploit provided command execution, interactive shells obtained through web exploits are often limited in functionality.

To solve this, I created a reverse shell script on my Kali Linux machine that would connect back to my attacker system.

In this command, I created a file named shell.sh containing a Bash reverse shell payload. This payload instructs the target machine to initiate a connection back to my attacker IP address (10.10.14.166) on port 4444, providing me with an interactive shell.

I verified that the file was successfully created by listing the contents of my working directory:

With the reverse shell script ready, I needed a way for the target system to download it. To accomplish this, I started a simple Python HTTP server in the same directory:

This command started a web server listening on port 8080, allowing the target system to retrieve files from my machine.

The server output confirmed that the target successfully connected and downloaded the reverse shell script:

This log entry showed that the target machine at 10.129.2.65 made an HTTP request to my server and successfully retrieved the shell.sh file.

This confirmed that:

The target machine had outbound network connectivity to my attacker machine
The reverse shell payload was successfully delivered
I was ready to execute the payload and establish a fully interactive shell

With the payload successfully hosted and retrieved, I proceeded to set up a listener on my machine and execute the reverse shell from the target to gain interactive access.

Establishing a Reverse Shell

After successfully hosting the reverse shell payload and confirming that the target system could download it, I prepared to receive an incoming connection on my attacker machine. To do this, I started a Netcat listener on port 4444, which matched the port specified in my reverse shell script.

Netcat began listening for incoming connections:

With the listener active, I returned to the interactive exploit shell I had previously obtained through CVE-2025-49132 and executed the reverse shell payload directly from my hosted HTTP server.

This command instructed the target system to download the reverse shell script from my attacker machine and immediately execute it using Bash.

The exploit confirmed that the payload was successfully written and executed:

Although the web interface returned a 504 Gateway Time-out error:

this behavior was expected. The timeout occurred because the server-side process was redirected to establish a reverse shell connection, interrupting the normal HTTP response cycle. This is a common indicator that a reverse shell has been successfully triggered.

Returning to my Netcat listener, I received an incoming connection from the target system:

This confirmed that the reverse shell was successfully established. I now had direct command-line access to the target system as the wwwrun user.

The shell prompt also revealed the current working directory:

This indicated that I had gained access within the web application's directory, which aligned with the fact that the exploit was executed through the Pterodactyl Panel.

At this point, I had successfully achieved initial access to the target machine and obtained a functional shell. I could now proceed with post-exploitation enumeration to identify sensitive files, credentials, and potential privilege escalation vectors.

Enumerating the Web Application Directory

After successfully obtaining a reverse shell as the wwwrun user, I began post-exploitation enumeration to better understand the system and identify sensitive files that could aid in privilege escalation or credential discovery.

Since my shell was initially located in the web server’s public directory, I navigated to the root directory of the Pterodactyl application to inspect its contents.

Once inside the application directory, I listed all files, including hidden ones, to identify configuration files and other potentially sensitive data.

The output revealed the full structure of the Pterodactyl Panel installation:

This confirmed that I was inside the root directory of a Laravel-based Pterodactyl Panel installation, which aligned with the earlier findings during vulnerability exploitation.

One file immediately stood out: the .env file.

The .env file is particularly important in Laravel applications because it typically contains sensitive environment configuration variables, including:

Database credentials
Application keys
Mail server credentials
API tokens
Service account credentials

The file permissions also indicated that the file was readable by the wwwrun user, which meant I could access its contents directly.

Additionally, the directory structure confirmed several key details:

The presence of the vendor directory indicated that dependencies were installed via Composer
The config directory contained application configuration files
The database directory likely contained migration and schema information
The artisan file confirmed that this was a Laravel application, as Artisan is Laravel’s command-line interface

The ownership and permissions also provided useful context:

This showed that the web server user (wwwrun) had access to most of the application files, which is typical in web server environments but also meant sensitive configuration files were accessible from my current shell.

At this stage, the .env file became a high-value target because it often contains plaintext credentials that can be reused to access other services or escalate privileges.

Extracting Credentials from the Environment File

During enumeration of the Pterodactyl application directory, I identified the .env file as a high-value target since Laravel applications commonly store sensitive configuration data in this file. To quickly extract the most relevant credentials, I filtered the file contents for database configuration variables and application secrets.

pterodactyl htb hack the box write up walkthrough

The output revealed several critical configuration values:

This confirmed multiple important findings. First, the APP_KEY matched the encryption key I had previously retrieved through exploitation of CVE-2025-49132, validating that I had full access to the application's cryptographic secrets.

More importantly, the .env file contained valid database credentials in plaintext:

Database: panel
Username: pterodactyl
Password: PteraPanel
Host: 127.0.0.1
Port: 3306

Since the database was hosted locally on the target machine, I attempted to authenticate directly to the MariaDB server using these credentials.

After entering the password PteraPanel, the authentication was successful:

This confirmed that the credentials were valid and allowed direct access to the backend database used by the Pterodactyl Panel.

Gaining database access was a significant step forward because application databases often contain sensitive information such as:

User account details
Password hashes
API keys
Session data
Administrative account information

With direct access to the database, I could now enumerate tables and extract user credentials, which could potentially be reused to gain further access to the system or escalate privileges.

At this stage, I proceeded to enumerate the database structure to identify tables containing user account information.

Enumerating the Database Structure

After successfully authenticating to the MariaDB database using the credentials obtained from the .env file, I began enumerating the database contents to identify tables that could contain useful information such as user accounts, credentials, or administrative access.

To get an overview of the available tables, I ran the following SQL command:

The database returned a list of 35 tables:

This confirmed that I had full access to the backend database used by the Pterodactyl Panel. Several tables immediately stood out as high-value targets, particularly:

users - likely contains user account information
user_ssh_keys - may contain SSH public keys
api_keys - could contain API authentication tokens
sessions - may contain active session data
password_resets and recovery_tokens - could contain password reset tokens

Since administrative access is often associated with user accounts, I focused on the users table.

Enumerating User Accounts from the Database

After identifying the users table as a likely source of authentication data, I needed to understand its structure before extracting useful information. To do this, I inspected the schema of the table using the following command:

The output revealed the complete structure of the table:

This confirmed that the table contained user account information, including usernames, email addresses, password hashes, and administrative privileges. The most important column was root_admin, which indicated whether a user had administrative access to the Pterodactyl Panel.

With the schema confirmed, I proceeded to retrieve all user records from the table:

The database returned two user accounts:

This revealed two important users:

headmonitor - administrative user (root_admin = 1)
phileasfogg3 - standard user (root_admin = 0)

The headmonitor account was especially significant because it had administrative privileges, making it a high-value target.

The table also contained password hashes stored using the bcrypt algorithm:

These hashes could potentially be cracked offline to recover plaintext credentials, or reused if the same password was used across multiple services.

Additionally, the presence of email addresses confirmed valid usernames that could be used for authentication attempts:

headmonitor
phileasfogg3

Since administrative access often leads to full system compromise, the headmonitor account became my primary target moving forward.

At this stage, I had successfully extracted valid user accounts and password hashes from the database, which provided multiple avenues for further access, including credential reuse, password cracking, or direct authentication attempts against exposed services such as SSH or the Pterodactyl Panel.

Cracking User Password Hashes

After extracting the user account information from the database, I observed that the passwords were stored as bcrypt hashes. Since bcrypt is a one-way hashing algorithm, the only practical way to recover the original passwords was to perform an offline password cracking attack using a wordlist.

To prepare for cracking, I saved the extracted password hashes into a file named hashed.txt:

I added the following hashes obtained from the database:

These hashes corresponded to the headmonitor and phileasfogg3 user accounts.

With the hashes prepared, I used John the Ripper, a popular password cracking tool, along with the widely used rockyou.txt wordlist to attempt to recover the plaintext passwords.

John the Ripper successfully loaded both bcrypt hashes:

This confirmed that the hashes were valid and ready for cracking. After running the attack, John successfully recovered one of the passwords:

This indicated that the plaintext password for one of the user accounts was:

Since this password was recovered from the database hashes, it most likely belonged to one of the valid panel users, either headmonitor or phileasfogg3.

This was a critical breakthrough because recovered credentials can often be reused across multiple services. In CTF environments and real-world systems, users frequently reuse passwords for different services such as:

SSH access
Web panel authentication
System user accounts

With valid credentials now available, I proceeded to attempt authentication against exposed services, starting with SSH, to determine whether password reuse would grant direct system access.

SSH Access Using Recovered Credentials

After successfully cracking one of the bcrypt password hashes and recovering the plaintext password !QAZ2wsx, I attempted to authenticate to the target system via SSH using the usernames obtained from the database. Since the phileasfogg3 account was a valid system user and its password hash was present in the database, I attempted to log in using this account.

When prompted for the password, I entered the cracked password:

The authentication was successful, and I gained access to the system as the phileasfogg3 user:

This confirmed that the password was valid and that credential reuse was in effect, allowing direct SSH access.

Once logged in, I listed the contents of the user's home directory:

The output showed the presence of a file named user.txt, which is typically the user flag in Hack the Box challenges:

I then displayed the contents of the file:

This confirmed that I had successfully achieved authenticated user-level access on the system.

Hurray!!! I got the User Flag.

At this stage, I had fully compromised the phileasfogg3 user account through credential extraction and password cracking. With user-level access established, the next objective was to perform privilege escalation in order to gain root access and complete the system compromise.