Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the ExpressWay machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs.
You can also test and grow your penetration testing skills, from gathering information to reporting. If you are new to this blog, please do not forget to like, comment and subscribe to my YouTube channel and follow me on LinkedIn for more updates.About the Machine
ExpressWay is an easy Linux machine that exercises basic network enumeration, protocol‑level fingerprinting, and classic misconfigurations. At first glance the host exposes only a few obvious services, but further UDP enumeration and log inspection reveal multiple, pivotable attack surfaces — an IPsec/IKE endpoint that leaks a crackable PSK, a TFTP/DHCPlike footprint, and Squid proxy logs that point to a host‑scoped sudo rule. The path from initial recon to root is compact and teaches three common CTF lessons: protocol fingerprinting (IKE), offline cracking of leaked artifacts, and abusing host‑based sudo rules.
The first step in pwning the ExpressWay machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:
After the connection has been set up, I started the target machine, and I was assigned an IP address of 10.10.11.87.
After identifying the target machine 10.10.11.87, I kicked things off with an Nmap scan to enumerate open services and gather as much information as possible. I used the command:
This scan runs with service/version detection (-sV), default scripts (-sC), and OS detection/advanced fingerprinting (-A).
The results showed that almost all ports are closed except for port 22, which is running OpenSSH 10.0p2 on Debian 8. This indicates a Linux host, and Nmap further fingerprinted it as running a kernel in the 4.15 – 5.19 range. That gives me a decent idea of the environment—it’s likely a modern Debian-based system, not some ancient distro.
Here’s the relevant finding:
- 22/tcp – OpenSSH 10.0p2 Debian 8
→ Likely used for remote administration, which means SSH could be an eventual foothold if I can find valid credentials or a way to escalate through it.
Nmap’s traceroute results also confirmed the box is only two hops away, sitting at expressway.htb. The hostname provided is a strong hint that the machine probably hosts a web application or some service branded “Expressway.”
At this stage, the main takeaway is:
- Only SSH is exposed.
- No obvious web service on standard ports (like 80/443).
- I’ll likely need to dig deeper, perhaps probing for virtual hosts, non-standard ports, or additional services that might not be obvious yet.
Since Nmap revealed that the site was identifying itself as expressway.htb, I decided to map the target machine IP address to the domain name. This way, I could access the service by name instead of by IP:
Adding this entry lets me send HTTP Host headers and test vhosts locally. The previous nmap scan didn't reveal much, the next logical step is to perform a more targeted scan for hidden services or begin enumerating the hostname expressway.htb to see if there’s a web application running that wasn’t revealed in the initial sweep.
I switched gears to UDP enumeration with:
UDP is noisy and unreliable, but it often reveals services TCP scans miss. The UDP top-100 scan discovered four interesting ports: 68, 69, 500, and 4500. Ports 69 (TFTP) and 500 (ISAKMP) immediately stood out — TFTP is an unauthenticated file transfer service commonly used for boot images or device configs, and ISAKMP/IPsec (ports 500/4500) hints at a VPN or IPSec endpoint. Nmap reports several entries as open|filtered; that means Nmap couldn’t reliably tell whether the port is open or being blocked by filtering (common with UDP).
When the UDP scan showed 500/udp (ISAKMP / IKE) open on expressway.htb, it told me the box was running an IPsec VPN endpoint — a very different attack surface than the usual web or SSH ports. IPsec uses IKE (ISAKMP) on UDP/500 to negotiate security associations and keying material; importantly for a pentester, many gateways will reveal useful information during the initial IKE exchange (supported transforms, vendor IDs, and sometimes whether they use a Pre-Shared Key). Seeing IKE on the target immediately switches the game from web-enum to protocol-fingerprinting and negotiation-based attacks.
Read about isakmp penetration testing here
What I did next (and why)
-
Fingerprint & find a valid transform with
ike-scan— I start with a main-modeike-scan -M <IP>to see whether the gateway will complete a handshake for any of my proposed transforms. If a handshake is returned,ike-scanechoes the accepted SA (encryption, hash, DH group, auth type), which tells me whether the VPN uses PSK or certificates and which transforms are accepted — a key step in deciding follow-ups. -
Fingerprint vendor & backoff patterns —
ike-scan --showbackoffcan reveal vendor-specific timing/backoff patterns and Vendor ID (VID) payloads, sometimes allowing me to guess the appliance (Cisco, Juniper, etc.). That helps narrow tools and exploit techniques. -
If no handshake is returned, brute-force transforms or switch to aggressive mode — some devices return only notify packets when transforms are unacceptable. You can generate a dictionary of
--transcombinations (enc,hmac,auth,dh) and iterate withike-scan -M --trans=...until one returns a handshake. If main mode fails, try aggressive mode (--aggressive) which can leak more info (or a hash) but may be noisier. -
Find the correct ID (group name) to capture a crackable hash — many IKE setups require a correct group/ID string to provoke the server into returning a hash you can capture and crack.
ike-scan -P -M -A -n <candidate-id> <IP>or looping a wordlist of common group names (SecLists hasike-groupid.txt) will highlight IDs that produce a handshake — those IDs are golden because they let you capture the PSK-derived hash for offline cracking. Tools likeiker.pyandikeforceautomate ID bruteforcing and sometimes improve detection. -
Capture & crack the hash — once a valid transform + group/ID produce the handshake (often in aggressive mode), save the handshake (
-Pwithike-scan) and use offline cracking tools or specialized scripts to attempt PSK recovery. If the PSK is recovered, you may then brute XAUTH (if used) or try to authenticate and obtain access via the VPN.
IKE Pentesting
I ran a quick IKE main-mode probe against expressway.htb:
The IKE probe returned a main-mode handshake with Auth=PSK and Vendor IDs advertising XAUTH and DPD. That told me I was dealing with an IPsec gateway using PSK authentication and expecting extended username/password authentication. I saved the returned packets (ike-scan -M --aggressive -P ike-handshake.pcap) and began targeted enumeration (vendor fingerprinting and group/ID bruteforce) to try and provoke a crackable artifact or identify a valid group/ID to use for offline PSK recovery.
What the fields mean (brief)
- Main Mode Handshake returned — the target accepted a main-mode negotiation; it’s willing to communicate with our IKE proposals.
- SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeDuration=28800) — crypto profile:
Enc=3DES = 3DES encryption (older, but usable),Hash=SHA1 = HMAC-SHA1 for integrity,Group=2:modp1024 = Diffie-Hellman group 2 (1024-bit),Auth=PSK = authentication by a pre-shared key (not certificates).LifeDuration=28800 = SA lifetime in seconds (8 hours).- VID=… (XAUTH) — the gateway supports Extended Authentication (XAUTH). After the IKE SA, it will likely demand username/password credentials (common with many VPN appliances).
- VID=… (Dead Peer Detection) — normal signaling for IPsec keepalive/peer liveness.
Brute-Forcing With FakeID
I poked the IPsec endpoint with an aggressive-mode probe to try and elicit a crackable artifact:
Instead of a polite refusal, the gateway responded with an Aggressive Mode Handshake returned and dumped a full set of IKEv1 PSK parameters. I copied the PSK parameters and created ike.psk file using:
I converted the captured IKE blob into a text file ike.psk and launched a dictionary attack with psk-crack -d /usr/share/wordlists/rockyou.txt ike.psk. This quickly tested common phrases from rockyou.txt against the captured IKE hash — when it found a match, the PSK revealed the key "freakingrockstarontheroad" and I used it to attempt to use it for the VPN authentication (SSH).
I validated the recovered PSK by re-probing the gateway with ike-scan:
I verified the cracked PSK by running ike-scan --psk='freakingrockstarontheroad' 10.10.11.87; the gateway returned a Main Mode Handshake, confirming the PSK is valid.
Obtaining the User Flag
I connected to the machine using the ike account from the previously discovered username and authenticated using the password 'freakingrockstarontheroad' by running the following command:
After supplying the password I was dropped into an interactive shell as ike. The next stage is systematic local enumeration (user and environment info, sudo rights, scheduled jobs, network interfaces, credentials on disk, SUID binaries and kernel attack surface) to escalate privileges or pivot further into the internal network.
I listed all the files and directory by running ls and there I found the user flag. To read the content of the user flag, I ran the following command:
Hurray!!! I got the user flag
After obtaining the user flag, I ran a few quick sanity checks.
sudo -V showed sudo is installed (version 1.9.17) — useful to note for later privilege checks but not a guarantee of any immediate privilege. sudo -V showed sudo is installed (version 1.9.17) — useful to note for later privilege checks but not a guarantee of any immediate privilege.
Then I ran:
id confirmed I’m the ike user (UID 1001) and a member of the ike group and the proxy group (GID 13).
Listing the home directory revealed a few nice clues: .bash_history is symlinked to /dev/null (someone is avoiding leaving history), there’s an .ssh directory to inspect.
I noticed Squid traffic logs on the box and they contained requests for an internal host offramp.expressway.htb, so I checked sudo permissions while pretending to be that host. In /var/log/squid I found an earlier access entry referencing offramp.expressway.htb, which hinted the machine might have host-based sudo rules or aliases. Running sudo -h offramp.expressway.htb -l showed that the user ike is allowed to run ALL commands as root without a password (two NOPASSWD: ALL entries). Because sudo supports a -h option to evaluate host-specific sudoers rules, I simply asked sudo to use that hostname and launched a root shell:
I was dropped into a root shell immediately — ls in /home/ike showed user.txt and in root’s home I found root.txt. I read root.txt and captured the root flag: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. In short: log analysis revealed an internal host context, host-based sudo rules allowed NOPASSWD escalation when evaluated for that host, and using sudo -h to simulate that host gave an instant root shell.
Hurray!!! I got the root flag.
With that, the machine was officially pwned
If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.
Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee
0 Comments