Expressway HTB
Expressway HTB Target Overview Expressway is a Linux machine from Hack The Box that focuses on UDP enumeration, IPsec/IKE analysis, authentication weaknesses, and Linux privilege escalation. The machine is a good reminder that TCP enumeration alone may not reveal the full attack surface. Careful UDP scanning and protocol-specific enumeration play an important role in identifying the initial entry point. From there, the challenge progresses through credential discovery, remote access, and local privilege-escalation techniques, making it a solid machine for practising both network-service enumeration and Linux post-exploitation. Enumeration Nmap Scanning I started the assessment by performing service and operating-system detection with Nmap. The initial scan exposed only one TCP service: | Port | Service | Version | |---|---|---| | 22/tcp | SSH | OpenSSH 10.0p2 Debian 8 | Since SSH alone did not provide an obvious unauthenticated attack path, I also performed a full TCP port scan. However, no additional TCP ports were discovered. At this point, TCP enumeration had reached a dead end, so I moved on to UDP scanning. UDP Enumeration UDP scans with Nmap can take considerably longer because UDP does not use a connection-oriented handshake like TCP. For quicker initial UDP discovery, I used udpx: udpx GitHub This revealed an interesting service on: Internet Key Exchange (IKE) is used by IPsec to negotiate authentication and cryptographic parameters between communicating peers. For more information about IKE: Internet Key Exchange - GeeksforGeeks With IKE exposed, I shifted the enumeration toward the IPsec configuration. IKE Enumeration For IKE/IPsec enumeration, I referred to the following HackTricks article: IPsec / IKE VPN Pentesting - HackTricks I started by sending a standard IKE probe using ike-scan. The target returned a valid Main Mode handshake. The important parameters were: The most interesting value was: This confirmed that the IKE service was configured to use a Pre-Shared Key for authentication. The target also advertised: Since the endpoint responded successfully, I continued by testing whether Aggressive Mode was enabled. IKE Aggressive Mode ike-scan provides the -A option to perform an Aggressive Mode exchange. Aggressive Mode sends more identity-related information during the initial negotiation and can expose material that allows an attacker to perform offline PSK guessing when the configuration permits it. I ran: The Aggressive Mode handshake disclosed an important identity: This revealed the username-style identity: This was useful both for understanding the VPN configuration and later for testing recovered credentials against SSH. Capturing the IKE PSK Hash While reviewing the available ike-scan options, I found the --pskcrack parameter. This option saves the Aggressive Mode authentication material in a format that can later be processed by psk-crack. I captured the handshake into HandShake.txt. I verified that the captured material had been written to the file. This file contained the data required to perform an offline dictionary attack against the PSK. Cracking the IKE Pre-Shared Key I used psk-crack with the rockyou.txt wordlist. The dictionary attack successfully recovered the PSK: At this stage, I had: Since SSH was the only exposed TCP service, I tested whether the recovered credential was reused for the local ike account. Initial Access I attempted to authenticate over SSH using the username ike. The recovered IKE PSK was also valid as the SSH password for the ike account. The prompt: confirmed successful interactive access to the system as the low-privileged user ike. This demonstrated an important weakness in the environment: the same secret used for IKE authentication had also been reused as a local operating-system account password. User Flag With SSH access established, I captured the user flag. The next objective was to identify a path from the ike account to root privileges. Privilege Escalation Enumeration I initially checked the account's available sudo permissions using: This did not reveal a useful configured sudo rule, so I continued with SUID binary enumeration. One thing immediately stood out. There were two different SUID sudo binaries: Having two separate copies of a security-sensitive utility was unusual and worth investigating further. Comparing the Sudo Versions I checked the version of each binary individually. The standard system binary returned: The versions were therefore: The /usr/local/bin/sudo installation was particularly interesting because it was both SUID and separate from the distribution-provided binary. I researched whether this version was affected by any known local privilege-escalation vulnerabilities. Identifying CVE-2025-32463 During research, I identified CVE-2025-32463 affecting the vulnerable sudo installation. The vulnerable binary on the machine was: with version: I found the following proof-of-concept repository: https://github.com/r3dBust3r/CVE-2025-32463 The exploit targets the vulnerable sudo chroot functionality and attempts to achieve local privilege escalation. Since the vulnerable binary had the SUID bit set, successfully abusing it could potentially result in root-level execution. Transferring the Exploit After cloning the proof-of-concept repository on my attacking machine, I prepared to transfer the exploit to Expressway. I started a temporary Python HTTP server on my machine: From the target, I downloaded the exploit. The successful 200 OK response and completed download confirmed that the exploit had been transferred to the target. Executing CVE-2025-32463 I made the downloaded file executable. I then executed it. The exploit created its temporary working directory, compiled the required payload, and attempted to abuse the vulnerable sudo binary. The final prompt changed from: to: This confirmed that the privilege escalation had succeeded and that I now had an interactive root shell. --- Root Flag With root access obtained, I navigated to the root user's home directory and captured the final flag. This completed the machine. --- Remediation Guidance Several weaknesses contributed to the successful compromise of Expressway. Disable IKE Aggressive Mode IKE Aggressive Mode should be disabled when it is not explicitly required. The configuration exposed identity and authentication material that allowed the PSK to be attacked offline. Where possible, organisations should migrate to stronger and more modern IPsec/IKE configurations. Use Strong IKE Authentication The IKE PSK was recoverable using a common password wordlist. Pre-shared keys should therefore be: Long Randomly generated Unique Resistant to dictionary attacks Stored securely Certificate-based authentication should be considered where appropriate instead of shared secrets. Avoid Legacy Cryptographic Parameters The observed configuration advertised: These are legacy cryptographic choices and should be replaced with modern, organisation-approved algorithms and stronger Diffie-Hellman groups. Prevent Credential Reuse The IKE PSK: was also accepted as the password for the local ike SSH account. Secrets used for VPN or infrastructure authentication should never be reused for operating-system accounts. Different systems and services should have unique credentials. Restrict SSH Access SSH should be exposed only to authorised management networks where operationally possible. Password authentication should also be disabled in favour of properly managed SSH keys where practical. Remove Duplicate Sudo Installations The system contained: Maintaining multiple installations of a security-sensitive SUID utility increases the risk of leaving an outdated or vulnerable copy behind. Unnecessary binaries should be removed, and package management should ensure that only the supported system version remains installed. Patch Vulnerable Sudo Installations All sudo installations should be updated to a vendor-supported version containing the relevant security fixes. Administrators should also search for manually installed copies under locations such as: because these may not be updated automatically by the operating system's package manager. Audit SUID Binaries Security teams should periodically review SUID executables using commands such as: Unexpected or duplicate privileged binaries should be investigated and removed when they are not operationally required. --- Final Thoughts Expressway was a good example of why enumeration should not stop after a TCP scan. The initial Nmap scan exposed only SSH, which provided almost no direct attack surface without credentials. The important service was instead hidden on UDP port 500. Enumerating IKE revealed that the endpoint supported Aggressive Mode and used PSK authentication. This allowed authentication material to be captured and attacked offline, eventually revealing the key freakingrockstarontheroad. The machine then demonstrated another common security problem: credential reuse. The IKE PSK was also valid for the local ike SSH account, converting what initially appeared to be a VPN secret into direct operating-system access. Privilege escalation came from careful local enumeration. Discovering two SUID copies of sudo immediately stood out, and version comparison revealed that the manually installed /usr/local/bin/sudo was a vulnerable version. Exploiting CVE-2025-32463 then provided root access. The machine reinforced several important lessons: Always include UDP enumeration when TCP services do not expose a clear attack surface. IKE Aggressive Mode can expose information useful for offline attacks. Weak PSKs can undermine otherwise protected VPN infrastructure. Never reuse infrastructure secrets as operating-system passwords. Duplicate privileged binaries deserve immediate investigation. SUID enumeration remains an important Linux privilege-escalation technique. Manually installed software can remain vulnerable even when system packages are updated. See you in the next writeup. Until then, keep enumerating and stay curious. By Madhav ```