Cobblestone HTB Walkthrough

I just solved Cobblestone from Hack the Box

Cobblestone Machine Summary

Cobblestone is an insane difficulty Linux machine on Hack The Box that focuses heavily on advanced web exploitation, chained vulnerabilities, authenticated attack paths, and internal service abuse. The machine requires deep enumeration and combines SQL injection, stored cross-site scripting (XSS), server-side template injection (SSTI), credential extraction, SSH tunneling, and Cobbler XMLRPC exploitation to achieve full system compromise.

The attack chain started with Nmap enumeration and directory enumeration, which revealed multiple virtual hosts and web applications running on the target. After performing host configuration by updating the /etc/hosts file, additional subdomains such as vote.cobblestone.htb and mc.cobblestone.htb became accessible. Further web application enumeration exposed several interesting features, including a voting platform, a skin submission portal, and an internal deployment-related service.

While enumerating the authentication and skin portal functionality, I identified a SQL injection vulnerability in the “Suggest Skin” feature. Manual testing confirmed boolean-based blind SQL injection, time-based injection using SLEEP(), and eventually UNION-based SQL injection. Through systematic database enumeration, I extracted database names, tables, and backend configuration details. Leveraging MySQL FILE privilege abuse, I was able to read sensitive files directly from the filesystem, including Apache virtual host configurations, SSH configuration files, PHP application source code, and database credentials.

The vote application introduced another attack surface. After registering and authenticating to the platform, I intercepted requests using Burp Suite and analyzed the traffic generated by the “Suggest Server” functionality. Using sqlmap with the captured request file, I automated SQL injection enumeration and dumped the vote database contents, revealing the users and votes tables. User credential enumeration exposed administrator password hashes, though initial password cracking attempts with John the Ripper, Hashcat, and CrackStation failed.

The breakthrough came during cross-site scripting (XSS) to Twig SSTI exploitation. By abusing the stored XSS vulnerability inside the skin suggestion queue, I forced the administrator’s browser to load a malicious external JavaScript payload. The script interacted with an internal Twig-powered endpoint and executed server-side commands through SSTI, ultimately dumping database content and exfiltrating it back to my machine in Base64-encoded chunks. After performing hash decoding and cracking, I successfully recovered the plaintext password xxxxxxxxxxxxxxxxxxxxxxxx.

Using the recovered credentials, I gained SSH access as the cobble user and captured the user flag. Further enumeration revealed that the internal Cobbler API was bound locally on port 25151, so I established SSH port forwarding to tunnel the service to my attacker machine. Finally, I exploited a Cobbler XMLRPC authentication bypass that accepted an empty username and -1 as the password to obtain a valid session token. By abusing Cobbler’s Cheetah template engine inside autoinstall templates, I achieved server-side template injection and executed arbitrary Python code as root, resulting in a reverse shell and full root compromise of the machine.

Cobblestone - HackTheBox (Insane) Machine

Protected Page

The first step in owning the Cobblestone 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 Cobblestone machine and I was assigned an IP address (10.129.232.170).

Nmap Enumeration

I started the enumeration phase by running an aggressive Nmap scan against the target to identify open ports, service versions, and OS details.

The scan showed that only SSH on port 22 and HTTP on port 80 were open. I also noticed the web server redirected to cobblestone.htb, which told me I needed to add the hostname to my /etc/hosts file before continuing with web enumeration.

Subdomain Enumeration

After identifying the main web application, I proceeded with virtual host fuzzing to discover additional subdomains configured on the target. Since the application was using the cobblestone.htb hostname, I suspected there could be hidden development or administrative endpoints running on separate virtual hosts.

The fuzzing results revealed three valid subdomains: mc, vote, and deploy. The deploy host returned a 200 OK response, making it the most interesting target for further investigation, while the others redirected with 302 responses. At this stage, I added the discovered subdomains to my /etc/hosts file and continued enumerating the newly discovered attack surface.

Directory Enumeration

After identifying the main virtual host, I continued with directory enumeration to map out the web application and uncover hidden functionality. I focused on common PHP endpoints and potential development files that could expose sensitive features or misconfigurations.

HackTheBox | Cobblestone Season 9 machine writeup

The scan revealed several interesting endpoints, including login.php, upload.php, download.php, and user.php. The upload.php and user.php pages returned 403 Forbidden, suggesting that the functionality existed but required authentication or access control bypasses. I also noticed a /db directory and a vendor folder, which hinted that the application might be using third-party PHP dependencies worth investigating further.

Host Configuration

After discovering additional virtual hosts during subdomain enumeration, I needed to configure my local machine so the discovered domains could properly resolve to the target IP address. Without this step, the web server would not correctly serve the different applications tied to each hostname.

Mastering Cobblestone Beginner's Guide from Hack The Box

I authenticated with sudo privileges and appended the discovered domains to the /etc/hosts file. Once the hostnames resolved locally, I was able to access the vote and deploy virtual hosts directly from the browser and continue enumerating the newly exposed web applications.

Web Application Enumeration

Next, I visited the target IP address in the browser and was automatically redirected to http://cobblestone.htb, confirming that the application relied on virtual host routing. The landing page appeared to be a Minecraft-themed platform with multiple interconnected services exposed through different subdomains.

HTB Season 8 Episode 13 | Cobblestone - Insane

During manual enumeration, I noticed that the webpage referenced the same subdomains I had previously discovered through virtual host fuzzing. The application exposed a deployment portal at deploy.cobblestone.htb, a skin management feature through skins.php, and a beta voting system hosted on vote.cobblestone.htb. These separate services significantly expanded the attack surface and gave me multiple areas to investigate further for potential vulnerabilities.

Deploy Subdomain Enumeration

I then moved on to the deploy.cobblestone.htb subdomain to investigate the deployment service that was discovered during virtual host fuzzing. The page appeared to be a placeholder site marked as “Still under development,” suggesting that the feature had not yet been fully implemented.

While manually enumerating the page, I identified several staff names and brief descriptions related to Linux administration and security hardening. However, there were no accessible endpoints, forms, or interactive functionality that could be leveraged further at this stage. Since the subdomain did not immediately expose any attack vector, I shifted my focus to the remaining services exposed by the application.

Authentication & Skin Portal Enumeration

Next, I visited http://cobblestone.htb/skins.php, but the application redirected me to http://cobblestone.htb/login.php, indicating that authentication was required before accessing the skin database. The login page contained two separate functionalities: a login form for existing users and a registration form for creating new accounts.

I proceeded to register a new account by providing a username, first name, last name, email address, and password. After successfully creating the account, I authenticated to the application and gained access to the “Skins” portal.

Once inside the application, I enumerated the available skin entries and discovered several usernames associated with downloadable Minecraft skins. The listed accounts included Sword4000, ElDeathly, Dog1234, PaulGG, and NiftySmith.

HackTheBox (INSANE) Machine [Cobblestone] Full writeup

At this stage, these usernames appeared interesting since they could potentially be reused elsewhere in the environment for authentication or further enumeration.

SQL Injection Enumeration

After authenticating to the application, I navigated to the “Suggest Skin” tab and found a form containing three input fields: username, skin name, and download URL. The download URL parameter immediately stood out as an interesting attack surface since the application appeared to process it directly on submission.

While testing the parameter, I noticed that injecting a double quote (") caused noticeable changes in the application response, indicating improper input sanitization. Further testing with boolean-based and time-based payloads confirmed that the parameter was vulnerable to blind SQL injection.

DarkZeroReturns - HTB Season 11 HackTheBox Machine Complete Writeup

Using character-by-character extraction, I successfully enumerated the database name as cobblestone. I then continued enumerating tables through information_schema and identified two tables: suggestions and users, confirming that the application stored user account data in the backend database.

The application responses created a reliable boolean channel: valid conditions returned the normal suggestion page, while invalid conditions returned only the background image. Time-based payloads using SLEEP() also introduced measurable delays, further confirming the injection vulnerability. At this stage, the users table became the primary target for credential extraction and further access into the application.

UNION-Based SQL Injection & File Enumeration

After confirming the application was vulnerable to blind SQL injection, I moved to UNION-based payloads to extract data directly from the backend database. By determining that the query returned five columns, I was able to craft payloads that displayed database output inside the application response.

I first enumerated the privileges assigned to the database user and discovered that the MySQL account voteuser@localhost possessed the FILE privilege. This was a critical finding because it allowed the use of the LOAD_FILE() function to read files from the underlying operating system.

Using LOAD_FILE(), I systematically enumerated sensitive files across the server. Reading /etc/passwd revealed two local users, cobble and john, with cobble configured to use a restricted rbash shell. I then extracted Apache virtual host configurations and identified an internal endpoint, /cobbler_api, which proxied requests to 127.0.0.1:25151, exposing the presence of an internal Cobbler provisioning service.

Further file reads against /etc/ssh/sshd_config confirmed that the cobble account was jailed inside /home/chroot_jail, indicating a restricted SSH environment. I continued enumerating the web application source code and extracted /var/www/html/db/connection.php, which exposed valid database credentials for the cobblestone database.

Finally, reading suggest_skin.php revealed references to an internal preview_banner.php endpoint that rendered user-controlled content through the Twig template engine. This suggested a potential server-side template injection vector that could likely be triggered through the skin suggestion functionality in an authenticated administrative context.

Vote Application Enumeration

Next, I visited http://vote.cobblestone.htb and was redirected to the login portal at http://vote.cobblestone.htb/login.php. The application used the same authentication layout as the main cobblestone.htb site, containing both login and registration functionality.

Cobblestone - Insane - Linux cobblestone.htb

I registered a new account, authenticated successfully, and gained access to the voting dashboard. Inside the “Vote” tab, I identified a list of Minecraft server domains along with their vote counts.

One particular entry, mc.cobblestone.htb, stood out with 2321 votes, making it the most prominent internal service exposed through the application. I attempted to interact with the “Upvote” functionality to test for additional backend behavior, but the application returned an error stating that the voting feature had not yet been implemented. Although the functionality was incomplete, the discovered mc.cobblestone.htb hostname became an interesting target for further enumeration later in the assessment.

Host Enumeration

After discovering the mc.cobblestone.htb hostname inside the voting application, I added it to my local /etc/hosts file so the domain could properly resolve to the target machine during further testing.

Once the hostname was mapped, I visited http://mc.cobblestone.htb, but the application immediately redirected me back to the main http://cobblestone.htb/ page. This suggested that the subdomain was either not fully configured, intentionally redirected, or internally handled through another service that was not directly exposed through the web interface.

Request Interception & Traffic Analysis

After authenticating to the voting application, I switched to the “Suggest” tab to further inspect how the application handled user-submitted server URLs. The functionality allowed users to submit a Minecraft server address for approval, which immediately looked interesting from a backend processing perspective.

To test how the application handled external input, I entered my local VPN IP address with a custom port, 10.10.15.89:4444, into the URL field before submitting the request. Prior to clicking the submission button, I launched Burp Suite and enabled request interception to capture the raw HTTP traffic generated by the application.

The intercepted request revealed that the application sent the supplied server address inside the url POST parameter while maintaining the authenticated session through the PHPSESSID cookie. I also noticed that the colon character (:) in the supplied IP and port was URL-encoded as %3A, confirming standard form encoding behavior.

To preserve the request for further testing, I right-clicked the intercepted packet in Burp Suite and saved it locally as request.txt.

Capturing the raw request at this stage was important because it allowed me to later automate payload delivery, replay requests, and test the parameter for deeper vulnerabilities such as SSRF or SQL injection.

Automated SQL Injection Enumeration

After saving the intercepted request from Burp Suite, I used sqlmap to automate the SQL injection testing against the url POST parameter. By supplying the captured request file, I was able to preserve the authenticated session and accurately reproduce the application behavior during testing.

The scan confirmed that the url parameter was vulnerable to multiple SQL injection techniques, including boolean-based blind, time-based blind, and UNION-based injection. sqlmap also identified the backend database as MySQL/MariaDB running behind an Apache 2.4.62 web server on Debian Linux.

During enumeration, I successfully extracted the available databases and discovered two schemas: information_schema and vote. The results confirmed that the application was interacting with a dedicated vote database, which became the next target for deeper enumeration of tables, columns, and potentially sensitive user data.

Database Table Enumeration

After confirming access to the vote database, I continued the enumeration process to identify the tables stored inside the application schema. Since the SQL injection had already been validated, I used sqlmap to automate the table discovery phase against the vulnerable url parameter.

I just solved PingPong from Hack the Box

The enumeration revealed two tables within the vote database: users and votes. The presence of a users table immediately became the primary point of interest because it likely contained usernames, password hashes, or other authentication-related data that could potentially be leveraged for further access into the target environment.

User Credential Enumeration

After identifying the users table inside the vote database, I proceeded to dump its contents in order to extract usernames and password hashes from the application backend. Since the SQL injection was already fully validated, sqlmap was able to automate the extraction process successfully.

The dump revealed two user accounts stored in the application database: the default admin account and the account I previously created during registration. Most importantly, the administrator account contained a bcrypt password hash associated with the email cobble@cobblestone.htb.

At this stage, the extracted hash became a high-value target for offline password cracking, since recovering valid administrator credentials could potentially provide privileged access to other services within the environment.

Password Hash Cracking Attempt

After extracting the administrator password hash from the users table, I attempted to crack it offline in hopes of recovering valid credentials for the admin account. I first saved the bcrypt hash into a local file before launching a dictionary attack using John the Ripper with the popular rockyou.txt wordlist.

Unfortunately, the cracking attempt was unsuccessful, and John the Ripper failed to recover the plaintext password. I also tested the hash against CrackStation and Hashcat, but none of the approaches produced a valid result. At this point, it appeared that Hack The Box had likely updated the machine with a stronger password, forcing me to abandon the hash-cracking approach and look for an alternative path to compromise the cobble@cobblestone.htb account.

Cross-Site Scripting (XSS) to Twig SSTI Exploitation

After failing to recover the administrator password through hash cracking, I returned to http://cobblestone.htb/skins.php and authenticated with my low-privileged account. While reviewing the skin suggestion feature, I noticed that the application accepted unsanitized HTML input inside the suggestion body. Earlier source code review also revealed that preview_banner.php rendered user-controlled input through the Twig template engine.

Because the endpoint required an authenticated admin session, I could not access it directly from my attacker machine. Instead, I leveraged the stored XSS vulnerability in the suggestion queue to force the administrator’s browser to execute JavaScript on my behalf and interact with the internal Twig endpoint.

First, I created a malicious JavaScript payload that abuses Twig SSTI to execute a system command and exfiltrate the output back to my listener in Base64 chunks.

I copied this the into x.js malicious JavaScript payload:

PingPong (Insane) HackTheBox Machine Solution

I then hosted the payload locally and prepared listeners to capture the administrator’s callback requests.

Next, I navigated to the Suggest Skin tab and submitted a malicious XSS payload that dynamically loaded my external x.js file into the administrator’s browser once the suggestion was reviewed.

The request was accepted successfully, confirming that the payload had been stored in the application.

Darkzeroreturns htb root flag & user flag hint

A few moments later, my Python HTTP servers received inbound connections from the target host, showing that the administrator’s browser had executed the JavaScript payload.

Mastering PingPong Beginner's Guide from Hack the Box

The callback traffic contained multiple Base64-encoded chunks exfiltrated from the internal Twig execution. After decoding the data, I recovered a full mysqldump output of the users table from the cobblestone database, including usernames, email addresses, password hashes, and role assignments. This confirmed successful exploitation of the stored XSS vulnerability chained with Twig SSTI for authenticated remote command execution through the admin context.

Hash Decoding & Cracking

After receiving the Base64-encoded chunks from the exfiltrated response, I decoded the data and identified a SHA-256 style hash belonging to the cobble user.

Season 11 HTB Machine Walkthrough - Cohort HackTheBox

This gave me a stronger lead than the previous bcrypt hash that could not be cracked.

I then saved the extracted hash into a file and used Hashcat with mode 1400, which targets raw SHA-256 hashes.

Hashcat successfully cracked the hash and revealed the plaintext password as iluvdannymorethanyouknow. With a valid password for cobble, I now had a promising credential to test against SSH or other authenticated services on the target.

SSH Access

Using the recovered plaintext password iluvdannymorethanyouknow, I attempted to authenticate to the target over SSH as the cobble user. The credentials worked successfully, granting me an interactive shell on the Debian host.

After authenticating, I enumerated the home directory and immediately found the user.txt flag file. Reading the file confirmed successful user-level compromise of the machine.

SSH Port Forwarding

While enumerating the configuration files earlier, I discovered that the internal Cobbler API was bound locally to 127.0.0.1:25151 and could not be accessed externally. To interact with the service from my attacker machine, I established an SSH local port forward through the compromised cobble account.

DarkZeroReturns - (Hard) Windows Machine

After providing the password, the SSH session remained open without spawning a shell because of the -N flag. This successfully tunneled the remote internal service to my local machine, allowing me to access the previously restricted Cobbler API through 127.0.0.1:25151 on my own host.

Cobbler XMLRPC Authentication Bypass

After tunneling the internal Cobbler service through SSH, I began enumerating the XMLRPC interface exposed on 127.0.0.1:25151. During testing, I discovered that Cobbler accepted an empty username with -1 as the password and returned a valid session token without requiring authentication. This exposed administrative functionality directly through the XMLRPC API.

Further research into Cobbler’s autoinstall feature revealed that templates were rendered using the Cheetah template engine. Since Cheetah supports embedded Python execution through the #set directive, I realized I could inject a malicious payload that executed system commands as the Cobbler service user, which runs as root.

First, I started a netcat listener on my attacker machine to catch the reverse shell connection.

Next, I created a Python exploit that authenticated to the XMLRPC service, wrote a malicious autoinstall template, created a fake distro and profile, and finally triggered template rendering to execute a reverse shell payload.

I then executed the exploit script against the locally forwarded Cobbler API.