TARGET OS: LINUX | AUTHOR: LEANDROS
Expressway is an Easy-rated Linux machine on HackTheBox that teaches a fundamental, yet often overlooked lesson in penetration testing: Never ignore UDP ports. After finding nothing but SSH on the TCP side, I enumerated a hidden IPsec VPN endpoint, exploited its "Aggressive Mode" configuration to capture an offline PSK hash, and cracked it for initial access. Privilege escalation involved identifying a very recent vulnerability in the Sudo binary to pop a root shell. Here is my complete mission log.
As always, I started my reconnaissance with a comprehensive TCP port scan using Nmap to identify any open services and potential entry points.
nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn <IP>
nmap -sCV -p22 <IP>
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 10.0p2 Debian 8 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
The results were incredibly sparse—only SSH was exposed. Since OpenSSH 10.0p2 is highly secure and we don't have any credentials, hitting a dead end on TCP means it's time to pivot. When TCP comes up empty, I immediately switch to scanning UDP ports to see if there are any hidden services listening in the shadows.
nmap -sU --min-rate 1000 --top-ports 100 <IP>
PORT STATE SERVICE
500/udp open isakmp
...
Nmap done: 1 IP address (1 host up) scanned in 0.54 seconds
Bingo. Port 500 UDP is open, which is the standard port for ISAKMP (Internet Security Association and Key Management Protocol). This tells me there is an IPsec VPN endpoint running on this machine. I ran a targeted Nmap script scan against this port to gather more details.
nmap -sU -p 500 -sV --script ike-version <IP>
The scan confirmed the service supports XAUTH (Extended Authentication) and Dead Peer Detection v1.0. Knowing it's an IKE VPN, the next logical step is to check if it's vulnerable to offline password cracking.
IPsec VPNs can operate in two phases for initial key exchange: Main Mode or Aggressive Mode.
Aggressive Mode is inherently insecure because the VPN gateway transmits the Pre-Shared Key (PSK) hash to the client before authenticating the client's identity. This allows an attacker to capture the hash and crack it offline.
To test if Aggressive Mode was enabled, I utilized a tool called ike-scan and sent a dummy handshake request.
ike-scan -A --id=test <IP>
10.10.11.87 Aggressive Mode Handshake returned HDR=(CKY-R=6bef8cd3620d6de4) 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)
The server responded favorably! Not only did it confirm Aggressive Mode is active, but it also leaked an internal Fully Qualified Domain Name (FQDN): ike@expressway.htb.
I immediately mapped expressway.htb to my /etc/hosts file. Now that I knew the exact ID format the server expected, I could use ike-scan again, this time instructing it to dump the Pre-Shared Key hash into a file for cracking.
ike-scan -A --id=expressway.htb --pskcrack=expressway.psk <IP>
With the hash safely stored in expressway.psk, I fired up psk-crack (part of the ike-scan suite) and fed it a standard wordlist to run an offline dictionary attack.
psk-crack -d /usr/share/wordlists/rockyou.txt expressway.psk
Running in dictionary cracking mode
key "freakingrockstarontheroad" matches SHA1 hash f1e7585855cf7f8b9622fd9753b91b9b27e3d949
Ending psk-crack: 8045040 iterations in 7.548 seconds
In just under 8 seconds, the hash was cracked. I now had valid credentials: user ike and the password freakingrockstarontheroad.
Since SSH was the only TCP service running on the box, I tested my newly acquired credentials there.
ssh ike@<IP>
The password worked perfectly. I bypassed the perimeter, secured a shell as the user ike, and immediately grabbed the user.txt flag. Foothold secured.
With a low-privileged shell established, my next objective was enumerating the system for a path to root. I started by checking my user privileges and group assignments.
id
The output showed I was part of the proxy group (gid=13). While interesting, exploring the proxy group permissions didn't yield any immediate local privilege escalation vectors.
My next standard check is evaluating the version of the sudo binary, as outdated versions are notorious for critical vulnerabilities.
sudo -V
Sudo version 1.9.17
Sudoers policy plugin version 1.9.17
Sudoers file grammar version 50...
Seeing Sudo version 1.9.17 was a massive breakthrough. A quick search of recent vulnerability databases revealed that this exact version is vulnerable to CVE-2025-32463. This exploit takes advantage of a flaw in how specific Sudo versions parse environments or arguments, allowing a local user to execute commands with elevated privileges without needing root passwords.
I located a Proof of Concept (PoC) exploit script on GitHub by researcher kh4sh3i. I pulled the script down to the victim machine, made it executable, and fired it off.
chmod +x exploit.sh
./exploit.sh
woot!
root@expressway:/# whoami
root
root@expressway:/# id
uid=0(root) gid=0(root) groups=0(root),13(proxy),1001(ike)
The exploit successfully manipulated the Sudo binary and dropped me into a root shell. I retrieved the root.txt flag. The system was completely compromised.