HTB Labs  - Season 9 -  "Expressway" Machine Walkthrough | By: CyberAlp0

Hey folks, this is CyberAlp0. Welcome to a new walkthrough powered by HTB Active Labs, named “Expressway”. The Expressway machine is designed to introduce core concepts of VPN attack surface discovery, IKEv1 Aggressive Mode weakness, offline PSK cracking, and how initial access through a misconfigured VPN service can be chained into a full compromise. The lab finishes with a modern sudo local privilege escalation (CVE-2025–32463) to obtain root.

Executive Summary

Here is an executive summary of the steps we will follow:

Stage I: Scanning

Initial reconnaissance was conducted using NmapAutomator to identify exposed services and understand the attack surface. Scanning revealed a minimal footprint: SSH on 22/TCP and ISAKMP/IKE on 500/UDP, confirming a Linux target with no web application, SMB, or other common entry points. 

Stage II: Enumeration

Enumeration targeted the VPN service using ike-scan. Main Mode probing confirmed the endpoint was alive, and Aggressive Mode enumeration revealed critical metadata. The IKE aggressive exchange was then captured to extract a PSK hash, which was cracked offline with psk-crack using rockyou.txt.

Stage III: Exploiting

With the recovered identity and cracked PSK, access was translated into system compromise by authenticating as the user ike over SSH. The user flag was retrieved from the user context. Privilege escalation was then performed by identifying the installed sudo version (1.9.17) and leveraging the known local privilege escalation vulnerability CVE-2025–32463 (sudo — chroot abuse). Executing the exploit granted a root shell, enabling retrieval of the root flag and completing the full compromise.

Spawning the Machine and Starting to submit the user and root flags 

Step 1: Connecting to the Machine VPN to get the IP 

Download the OpenVPN file and write the following command to connect to the target’s machine

sudo openvpn machines_us-free-2.ovpn

Step 2: Scan the target using the Nmap 

We will use the NmapAutomator tool to save time and get a full report about the target. Write the following command:

bash nmapautomator.sh 10.129.5.115 --host --type all

According to the scan we will find out that:

• The services: OpenSSH 10.0p2 Debian 8 (protocol 2.0), isakmp
• The ports: 22/TCP, 500/UDP
• The OS: Linux 

After completing the scan, we will ask ourselves the following questions:

What services are exposed, and which one gives me leverage?

If the scan result reveals that the box:

• Has no web server.
• There are no websites.
• There is no SMB.
• No obvious app logic.

Then, we should look for uncommon services carefully.

As per the screenshot, we can find that SSH is exposed, but we don’t have any credentials to use it to remotely access the server like root or administrator passwords. So, SSH is likely a later stage to access the server. Our next step is to try to find those credentials some where else. Eventually we will notice that nothing else is interesting that is running over TCP.

From the scan, we can find that there is another UDP service running which is “ike”, and it is running through port 500/UDP. It is a VPN service that might give us the initial access to the servers. This means that this box probably exposing a VPN handshake. 

IKE (Internet Key Exchange) is the protocol used to set up, authenticate, and manage secure VPN tunnels, most commonly for IPsec VPNs. It handles who you are, how you encrypt, and how keys are exchanged before any protected traffic flows.

Step 3: Understanding the attack surface (IKE / ISAKMP)

• IKE = (Internet Key Exchange) VPN key negotiation protocol
• ISAKMP = message framework used by IKE

The question is: Can this VPN be tricked into revealing information?

Firstly: Probing the VPN with ike-scan

Write the following command to perform the main scanning mode for the IKE targeting the target’s IP

ike-scan -M 10.129.5.115

The command sends basic ISAKMP packets, and checks if an IKE service answers. As per the previous screenshot, we have got responses from the IKE service, this means that the VPN endpoint is alive and we can aggressively probe it.

We can use the Aggressive mode for ike-scan through the command:

ike-scan -A 10.129.5.115

According to the scans, we can notice that the response contains very important information which is that:

• IKE handshake successful → The VPN endpoint is reachable and responding correctly.
• IKEv1 confirmed → and uses classic IPsec/IKEv1 (not IKEv2).
• Authentication method: PSK → Pre-Shared Key is required (no certificates). This is a key HTB clue as the VPN relies on a shared secret.
• XAUTH enabled → After PSK, the VPN requires username + password, Which confirms credential-based access is expected.
• Identity Information → ID_TYPE: ID_USER_FQDN, and the ID_VALUE: ike@expressway.htb
• Domain Information → Domain: express.htb, and the username: ike

Secondly: Extracting and Cracking the PSK

Type the following command to extract the PSK that is exposed by the ike service:

ike-scan -A 10.129.5.115 -P ike_hash.txt

This hash can be cracked offline by using the psk-crack tool. We will use the rockyou.txt wordlist file to crack the hash. Type the following command:

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

According to the cracking result, the PSK key is “freakingrockstarontheroad”.

Step 4: Translating VPN Access into System Access 

At this stage, we obtained valid credentials that allow us to authenticate to the target system via SSH. During the IKE Aggressive Mode scan, an IKE identity of “ike” was disclosed, which was later confirmed to correspond to a valid local user account on the system. Additionally, due to a misconfiguration in the VPN service—specifically the use of IKEv1 Aggressive Mode with pre‑shared key authentication—we were able to capture and crack the VPN PSK, revealing the value “freakingrockstarontheroad”. By combining the recovered identity and the cracked PSK, we can now gain SSH access to the machine using the following command:

ssh ike@expressway.htb

Don’t forget to resolve the target’s IP against the domain name which is expressway.htb, by adding the domain in the /etc/hosts file, or you can just replace the domain with IP.

Username: ike 

Password: freakingrockstarontheroad

Step 5: Navigating the target to get the “User Flag”

After authenticating the user “ike”, we will navigate the server to get the user flag. As per the following screenshot, we may find the user flag and cat its content by typing the following command:

cat user.txt

The user flag for Expressway Machine: 0c98a4837c7f74b726767d3dbb4f21e4

Step 5: Trying to get the “Root Flag”

We have now the access to the target as a normal user and we want to escalate the privilegaes to get the root permissions. Let’s check the sudo version by typing the following command: 

sudo -V | head -n 1

It was found that the version of the sudo is 1.9.17. We will take this piece of information and search the exploit databases to see whether there is a CVE against this version or not. Upon searching in exploit database, you will find that there is an exploit related to the sudo version in the machine we are working on.

This is applied as well when searching on NVD platform as shown in the following screenshot 

The CVE ID of this exploit is CVE-2025–32463. By making use of this exploit, we will get the root permissions. Copy the exploit from the following Link and create a file in the target’s machine using the “touch” command and paste the exploit on it. 

Give the exploit the execution permission by typing the following command:

chmod +x exploit.sh

Then execute the exploit.sh, using the following command:

./exploit.sh

The Root flag of the machine “Expressway” is:

c3144dc109864a7d610bea7f6d32d57e

Bonus Section: Explaining the logic behind the vulnerability 

First: what is sudo supposed to do?

When you run sudo, it does two things as root:

1. Figure out who you are
2. Decide whether you’re allowed to run a command or not
3. To make sure of that, it might ask you for a password 

To do that, Linux needs to:

• Look up users
• Look up groups to search among them. Most of the time the super users will be listed in a group called the sudoers.

This lookup process uses system configuration files.

Second: Where the root goes and looks for the users info?

When Linux needs to look for a user info, it uses this file and loads these system libraries

/etc/nsswitch.conf

Each entry = a shared libraryShared libraries = .so files.so files = code that runs when loaded

If root loads a shared library, that library runs as root

Thirdly: What is Chroot (sudo -R)?

sudo -R <dir> tells sudo: “Pretend <dir> is / (the filesystem root)”. So, instead of looking for 

/etc/nsswitch.conf

sudo will look for:

<dir>/etc/nsswitch.conf

Short Story to simplify the logic:

• You are a bank manager (root)
• You ask a stranger (user): “Give me a room to stand in while I check your ID”. The stranger gives you a room (chroot).

Inside that room:

• Fake rules on the wall
• Fake instructions
• Fake staff

You read the fake rules before checking if the stranger is allowed. As a result, You follow them, You get robbed.

Bottom Line: Sudo trusted attacker-controlled files while still running as root. Root entered a fake file system too early and trusted it.

Here is a graph to understand more:

Hope you enjoyed reading my blog about solving the “Expressway” machine from HTB.

See you in another write-up!.