Welcome to my cybersecurity blog where I share Hack the Box walkthroughs, ethical hacking tutorials, Android malware analysis, reverse engineering, and cybersecurity learning guides.
About the Machine
Pterodactyl is a medium-difficulty Linux machine that demonstrates a realistic web-application exploitation chain leading to full system compromise. The attack path combines web enumeration, application vulnerability exploitation, credential extraction, password cracking, and a chained local privilege escalation using multiple vulnerabilities.
The compromise begins with network enumeration using Nmap, which reveals SSH and HTTP services running on the target. Accessing the web server shows that the application uses virtual host routing, redirecting requests to the pterodactyl.htb domain. After updating the local hosts file, additional enumeration identifies another virtual host, play.pterodactyl.htb.
Further subdomain enumeration using ffuf discovers the panel.pterodactyl.htb subdomain, which hosts the Pterodactyl game server management panel. Investigation of the login portal and associated software leads to vulnerability research, revealing that certain versions of the Pterodactyl panel are affected by CVE-2025-49132.
Through panel endpoint enumeration, the vulnerable /locales/locale.json endpoint is identified. Exploiting the directory traversal vulnerability associated with CVE-2025-49132 allows access to internal application configuration files. Using crafted requests, the database configuration file is retrieved, exposing credentials for the panel’s backend MariaDB database.
The vulnerability is then further leveraged to dump additional application secrets, including the Laravel APP_KEY, which confirms full access to sensitive application configuration. Using a modified proof-of-concept exploit, the vulnerability is escalated into remote command execution through the panel.
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.
To access this newly discovered subdomain, I added it to my /etc/hosts file so my system could resolve it correctly:
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.
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
-Gflag to send the parameters as a GET request. - I supplied
locale=../../../pterodactylto traverse outside the intended directory and reach the root application folder. - I specified
namespace=config/databaseto 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:
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
vendordirectory indicated that dependencies were installed via Composer - The
configdirectory contained application configuration files - The
databasedirectory likely contained migration and schema information - The
artisanfile 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.
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 informationuser_ssh_keys- may contain SSH public keysapi_keys- could contain API authentication tokenssessions- may contain active session datapassword_resetsandrecovery_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.
Inspecting Local Mail for Clues
After gaining SSH access as the phileasfogg3 user and obtaining the user flag, I continued with post-exploitation enumeration to identify potential privilege escalation vectors. A common place to look for useful information on Linux systems is the local mail directory, as administrators often send system notifications or internal messages that may reveal misconfigurations or security hints.
I navigated to the /var directory to explore its contents:
To see what directories were available, I listed its contents:
The output showed several standard system directories, including mail, which stores local user mailboxes:
Since the mail directory often contains messages sent between local system users, I navigated into it to inspect its contents:
Next, I listed the available mailboxes:
Two mail files were present:
This indicated that both users had received system mail. Since I was currently logged in as phileasfogg3, I opened the corresponding mailbox to read its contents.
The message revealed an internal security notification sent by the system administrator headmonitor:
The email warned users about unusual activity involving the udisks daemon (udisksd) and instructed administrators to review system logs and apply updates.
This message was particularly interesting because it referenced a specific system service (udisksd) that was behaving abnormally. In CTF environments, such hints are often deliberately placed to guide the attacker toward a potential privilege escalation vector.
Key observations from the message included:
- The administrator had noticed suspicious behavior from the
udisksddaemon - No compromise had been confirmed yet
- Administrators were advised to review logs and apply updates
The mention of udisksd suggested that the service might be vulnerable, misconfigured, or interacting with privileged components in an insecure way. Since udisksd is responsible for managing storage devices and often runs with elevated privileges, it could potentially provide a pathway for privilege escalation if exploited.
This discovery provided a strong lead for further investigation. At this point, I shifted my focus to examining the udisks service, its permissions, and any related binaries or processes running on the system to determine whether it could be leveraged to escalate privileges to root.
Researching the udisksd Privilege Escalation
While performing local enumeration, I previously discovered an internal email mentioning unusual activity related to the udisksd daemon. Since system administrators rarely reference specific services without reason in CTF environments, this strongly suggested that udisksd might be involved in a potential privilege escalation path.
To investigate further, I began researching publicly known vulnerabilities associated with the udisks service. During this research, I discovered a proof-of-concept exploit for CVE-2025-6019, which targets a flaw in the libblockdev component used by udisks. The vulnerability can allow a local attacker to escalate privileges by abusing how the daemon interacts with privileged mount operations.
A public proof-of-concept exploit was available on GitHub, so I cloned the repository to my Kali Linux machine for further analysis.
The repository was successfully cloned to my working directory:
After cloning the repository, I navigated into the exploit directory to inspect its contents.
Next, I listed the files contained within the repository:
The repository contained the following files:
The most important file was exploit.sh, which appeared to be a shell script implementing the privilege escalation exploit. The README.md likely contained instructions on how the exploit works and how to execute it, while demo.svg appeared to be a diagram illustrating the vulnerability chain.
At this point, the presence of a working proof-of-concept exploit strongly suggested that the target system might be vulnerable to CVE-2025-6019. Since this vulnerability targets the udisks daemon and the earlier system email specifically mentioned suspicious activity involving udisksd, this further reinforced the likelihood that it was the intended privilege escalation path.
With the exploit code available locally, the next step was to review the exploit script and determine how to transfer and execute it on the compromised system in order to attempt privilege escalation to root.
Preparing the CVE-2025-6019 Privilege Escalation Exploit
After identifying the udisksd service as a potential privilege escalation vector and discovering a proof-of-concept exploit for CVE-2025-6019, I proceeded to prepare the exploit environment on my Kali Linux machine.
First, I executed the exploit script locally to generate the necessary filesystem image required by the exploit chain.
The script began by displaying a warning indicating that it was a proof-of-concept for CVE-2025-6019, which targets a privilege escalation vulnerability in libblockdev/udisks.
The exploit then performed a dependency check and attempted to detect the installed udisks version:
Since the exact vulnerable versions were not explicitly detected, the script issued a warning recommending manual verification before proceeding. Despite this, I continued execution to generate the exploit artifacts.
The exploit script offered two modes:
- Local mode - prepares the malicious filesystem image
- Target mode - executes the privilege escalation on the victim system
Since I was preparing the payload locally, I selected Local mode.
The script then created a 300 MB XFS disk image, which would later be used during the exploitation process:
The image was successfully generated:
After the script completed, I verified that the exploit files were present in my working directory:
The directory now contained the exploit script and the newly created xfs.image, which is required for triggering the vulnerability.
Transferring the Exploit to the Target System
With the necessary exploit components prepared, the next step was to transfer them to the compromised target machine. Since I already had valid SSH credentials for the phileasfogg3 user, I used SCP to upload the exploit files to the /tmp directory on the target.
First, I transferred the exploit script:
After entering the user's password, the file transfer completed successfully:
Next, I transferred the XFS image required by the exploit:
Again, after authenticating with the user's password, the file was successfully uploaded to the target system. During both transfers, SSH displayed a warning regarding the use of non-post-quantum key exchange algorithms:
This warning simply indicates that the SSH server is using traditional cryptographic algorithms rather than post-quantum-resistant ones and does not impact the exploitation process.
At this stage, the CVE-2025-6019 exploit script and the malicious XFS image were successfully transferred to the target system. With the necessary components in place, the next step was to execute the exploit on the target machine to attempt privilege escalation to root.
Preparing the CVE-2025-6018 Exploit Binary
While researching CVE-2025-6019, I discovered that it is often chained with CVE-2025-6018, a vulnerability related to PAM/Polkit active session bypass. When combined, these two vulnerabilities can allow a local attacker to escalate privileges to root. The typical attack chain involves abusing the Polkit session validation flaw (CVE-2025-6018) together with the libblockdev/udisks vulnerability (CVE-2025-6019).
To prepare for this exploitation chain, I downloaded a publicly available proof-of-concept script for CVE-2025-6018.
The file was successfully retrieved from GitHub:
I then verified that the script was present in my working directory alongside the other exploit files:
Since the exploit script relies on Python libraries that may not be present on the target system, I decided to compile it into a standalone executable using PyInstaller. This approach avoids dependency issues and makes it easier to transfer and execute on the target machine.
First, I created a Python virtual environment to isolate the required dependencies.
Next, I activated the virtual environment:
With the environment active, I installed the required libraries used by the exploit:
The installation completed successfully and pulled in several required dependencies, including:
paramiko(for SSH interactions)- cryptography
- bcrypt
- pynacl
- cffi
These libraries are commonly used in exploitation scripts that interact with authentication mechanisms or encrypted sessions.
After installing the dependencies, I used PyInstaller to package the Python exploit script into a single executable file.
PyInstaller began analyzing the script, resolving dependencies, and bundling the required libraries into a standalone binary. During this process, it generated build artifacts and compiled the exploit into an ELF executable.
The build completed successfully:
This indicated that the compiled binary was created inside the dist directory. Converting the Python exploit into a single executable ensured that it could run independently on the target system without requiring Python packages or additional dependencies.
With the CVE-2025-6018 exploit binary prepared, the next step was to transfer it to the compromised machine and execute it alongside the CVE-2025-6019 exploit, allowing the vulnerabilities to be chained together in order to escalate privileges to root.
Privilege Escalation via CVE-2025-6018 and CVE-2025-6019
After preparing the exploit chain, I proceeded to execute the compiled CVE-2025-6018 binary from my Kali Linux machine. This exploit targets a PAM/Polkit Active Session Bypass, which can be leveraged to gain elevated privileges when certain PAM modules are misconfigured.
To initiate the exploit, I ran the compiled binary and provided the target IP address along with the compromised SSH credentials for the phileasfogg3 user.
The exploit began by establishing an SSH connection to the target system using the provided credentials.
Once connected, the exploit performed a vulnerability assessment to determine whether the system was susceptible to the PAM-based privilege escalation technique.
Several checks were executed during this phase:
The exploit confirmed that the target system was running a vulnerable version of PAM (pam-1.3.0) and that the required modules (pam_env and pam_systemd) were present. These components are necessary for exploiting CVE-2025-6018, which abuses environment variable loading during authentication.
After confirming the vulnerability, the exploit created a malicious .pam_environment file in the user's home directory.
This file is automatically loaded by PAM during user authentication, allowing the attacker to inject environment variables that influence privileged processes.
The exploit then reconnected to the SSH service to trigger the malicious environment configuration.
Following the reconnection, the exploit tested several privilege escalation vectors related to systemd operations.
These results confirmed that the environment manipulation successfully enabled privileged system actions, indicating that the escalation vector was functioning.
At this stage, the exploit opened an interactive shell session on the target system.
I verified the current privileges using the id command.
The output confirmed that I was still operating as the phileasfogg3 user, but the environment was now prepared for the second stage of the exploit chain.
Next, I navigated to the /tmp directory where the CVE-2025-6019 exploit components had been previously uploaded.
The directory contained the exploit files, including the malicious filesystem image xfs.image and the exploit.sh script.
To trigger the second stage of the attack, I executed the CVE-2025-6019 exploit.
The script began by initializing the exploitation process and confirming that the allow_active policy required for the exploit was enabled.
The exploit then mounted the malicious XFS filesystem image using a loop device.
By repeatedly resizing and interacting with the mounted filesystem, the exploit abused a flaw in libblockdev/udisks that allowed arbitrary files to be created with elevated privileges.
After a brief delay, the exploit successfully generated a SUID bash binary in a temporary directory.
The SUID bit on the bash binary allowed it to execute with root privileges.
The exploit then launched the root shell.
To confirm the privilege escalation, I ran the id command.
The output showed that the effective user ID was now root:
With root access obtained, I navigated to the root directory and retrieved the root flag.
The command returned the root flag:
Hurray!!! I got the root flag.
This confirmed that the privilege escalation was successful and that the system had been fully compromised.
If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.
Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee
Found this walkthrough helpful?
Buying me a coffee helps power the late nights spent writing technical walkthroughs and keeping them free for everyone ☕
Keywords:
pterodactyl htb write up
pterodactyl htb linux medium user and root flag solution
Pwned Pterodactyl From HTB Season 10
pterodactyl htb walkthrough
Pwned active machine Pterodactyl from Hack The Box
Pterodactyl, HTB Season 10 Owned Pterodactyl from Hack The Box
pterodactyl hack the box write up
I just solved Pterodactyl on Hack The Box!
pterodactyl hack the box walkthrough
Another funny box Owned Pterodactyl from Hack The Box!
panel.pterodactyl.htb
“Pterodactyl” (Medium - Linux) on Hack The Box
play.pterodactyl.htb
HTB Machine Rooted: Pterodactyl Just completed the "Pterodactyl" box on HackTheBo
pterodactyl.htb
Owned Pterodactyl from Hack The Box!
Pterodactyl pwned
pterodactyl root flag
Rooted Pterodactyl on Hack The Box
Pterodactyl Pwned
Pterodactyl
Pterodactyl user flag
owned Pterodactyl
Hack The Box #Season10 #Episode2 medium rated #Linux Machine #Pterodactyl
Pre-Owned Pterodactyl
Pterodactyls
owned Pterodactyl
pterodactyl htb linux machine
Pterodactyl lab on Hack The Box!
Just pwned Pterodactyl
#pterodactyl htb machine #hackthebox #season10
Pterodactyl - HackTheBox(2nd Seasonal) rooted
Hack The Box - Pterodactyl (Rooted)
Rooted the Pterodactyl (Medium) machine on Hack The Box (Season 10)
Remote Code Execution (RCE) vulnerability in the Pterodactyl Panel
Owned Pterodactyl from Hack the Box roblox
Owned Pterodactyl from Hack the Box reddit
Pterodactyl: PWNED! I just finished rooting the Pterodactyl machine on HackTheBox
Pterodactyl has been Pwned! Season 10 Episode 2
HackTheBox: Pterodactyl - Writeup Difficulty: Medium OS: Linux
Medium Pterodactyl HTB box
Pterodactyl (Medium) | Hack The Box
owned interpreter from Hack The Box!
Owned Pterodactyl from Hack The Box! labs.hackthebox.com
successfully rooted the Pterodactyl machine from HTB Season 10
walkthrough of the HackTheBox 'Pterodactyl' machine
hackthebox pterodactyl htb machine
HackTheBox Season 10 Week 2: Pterodactyl
3 Comments
Hello Ibrahim!
ReplyDeleteI just had a doubt about how long the delay took you to execute the final bash exploit.sh command
I saw that yours terminated for a second after [*]Resisizing filesystem step and then you typed id and after which the process resumed again
I'm just getting stuck on that one step
Thank you for this amazign walkthrough! Hope you find great sucess by helping others
I have the exact same problem, anyone know how to get past this step?
DeleteAre you using ARM processor for local machine?
Delete