Expressway Hack: Nmap, IKE Cracking & Sudo Root Bypass

Hey everyone! Get ready to buckle up because today, we're taking a thrilling ride down the Expressway! If you're into penetration testing, ethical hacking, or just love a good network security challenge, this walkthrough is for you. We're going to dive deep into a system, starting from basic information gathering with Nmap, moving on to exploiting IKE services to crack a Pre-Shared Key, and finally, escalating privileges to achieve root access through a clever sudo bypass. This isn't just about finding vulnerabilities; it's about understanding how different pieces of a network fit together and how a seemingly small clue can lead to full system compromise. So, grab your coffee, settle in, and let's explore how we tackled the Expressway machine, from initial reconnaissance to owning the box. It's going to be a wild, educational, and super fun journey, packed with valuable insights and practical techniques you can apply in your own security adventures. We’ll be sharing the exact steps taken by faabbi on faabbi.github.io to crack this system wide open.

Phase 1: Unearthing Secrets – The Reconnaissance Mission

Every good penetration test begins with a solid reconnaissance mission. It's like being a detective, gathering every little bit of information before making your move. For the Expressway target, our first step was to map out its digital landscape. We needed to know what services were running, what ports were open, and essentially, what doors were available for us to knock on, or maybe even pick. This initial information gathering is absolutely critical because it sets the stage for all subsequent exploitation attempts. Without a clear picture of the target, you'd just be flailing in the dark, which, let's be honest, isn't very efficient or effective in the world of cybersecurity. We meticulously scanned the target to ensure we didn't miss any obscure, yet critical, entry points.

Starting with Nmap: Our Digital Binoculars

Our journey into the Expressway network began with everyone's favorite network scanner: Nmap. Think of Nmap as our digital binoculars, allowing us to peer into the target system and identify open ports and running services. First up, we performed a comprehensive TCP port scan using nmap --min-rate 10000 -p- 10.129.238.52 (note: IP might differ in a real scenario, here it was 10.129.238.52). This command is designed to scan all 65535 TCP ports quickly. The results were quite concise: only port 22, SSH, was found to be open. Now, for many targets, an open SSH port is a direct invitation for brute-forcing or credential stuffing. However, in this case, we didn't have any initial credentials, and going straight for SSH wasn't yielding immediate results. So, we parked that thought for a moment, knowing it might be an initial access vector later, but not our primary lead right now.

Next, we shifted our focus to UDP services. UDP scanning is often overlooked because it can be slower and trickier to interpret compared to TCP scans. But, and this is a big but, it can reveal services that TCP scans completely miss. We used nmap -sU --top-ports 20 10.129.238.52 to scan the top 20 most common UDP ports. The results from this UDP scan were far more interesting, revealing several open|filtered ports, with one standing out prominently: port 500/udp, identified as ISAKMP. Other ports like 68/udp (dhcpc), 69/udp (tftp), and 4500/udp (nat-t-ike) also showed as open|filtered, indicating they might be active but firewalled. ISAKMP (Internet Security Association and Key Management Protocol) is primarily used for establishing IPsec VPN tunnels. This discovery immediately piqued our interest. Why, you ask? Because VPN services often rely on Pre-Shared Keys (PSKs) for authentication, and these PSKs can sometimes be vulnerable to offline cracking if certain IKE modes are supported. This moved ISAKMP from being just another open port to our prime target for further exploitation on the Expressway machine. This detailed Nmap reconnaissance was the first critical step in uncovering the hidden entry points into the system, pushing us towards the more obscure UDP landscape rather than the well-trodden SSH path.

Diving Deeper with IKE Scan: Cracking the VPN Code

With ISAKMP (UDP port 500) identified as a key service, our next tool in the arsenal was ike-scan. This fantastic utility is specifically designed to discover, fingerprint, and test IPsec VPN servers. It's like having a specialized stethoscope to listen to the heart of a VPN connection. Our initial ike-scan command was ike-scan -M 10.129.19.97 (again, IP adjusted for the example, reflecting the target). The -M flag tells ike-scan to perform a Main Mode handshake. The output confirmed that the Expressway machine returned a Main Mode Handshake, revealing important Security Association (SA) parameters: Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800. This told us that the VPN was configured to use 3DES encryption, SHA1 hashing, a 1024-bit Modulus Diffie-Hellman group, and, crucially, Pre-Shared Key (PSK) authentication. The presence of PSK authentication is often a green light for attackers, as PSKs can sometimes be retrieved or cracked.

The real game-changer came when we moved to Aggressive Mode. Aggressive Mode in IKE is faster but less secure than Main Mode because it sends more information in fewer packets, including a hash that can be vulnerable to offline cracking. We used ike-scan -P -M -A -n hacker 10.129.19.97 with the -A flag for Aggressive Mode and -n hacker to specify a dummy identity. This scan returned an Aggressive Mode Handshake, which included several significant pieces of information. Most importantly, it revealed an ID(Type=ID_USER_FQDN, Value=ike@expressway.htb). This was a huge clue! It confirmed the domain expressway.htb and a potential username ike. This also exposed the IKE PSK parameters, including a hash. The server responded with a hash based on our provided ID (even the dummy "hacker" ID). This indicated that the VPN server was willing to calculate a hash based on any ID presented, which is a common vulnerability in Aggressive Mode implementations, allowing for identity spoofing.

To get the correct hash for the Pre-Shared Key, we then used the identified ID in our ike-scan command: ike-scan -P -M -A -n ike@expressway.htb 10.129.19.97. By supplying the correct FQDN identity, we obtained the authentic IKE PSK parameters and, most importantly, the hash value associated with the Pre-Shared Key. This hash, represented as a long string of hexadecimal characters, was our golden ticket to the next phase. It provided us with the cryptographic material needed to attempt an offline brute-force attack against the Pre-Shared Key, moving us one step closer to gaining initial access to the Expressway system. This meticulous process of IKE scanning and hash extraction is a cornerstone of VPN penetration testing, proving that sometimes the best way in isn't through a direct attack, but by carefully listening to the handshake.

From Hash to Password: The psk-crack Advantage

Now that we had successfully extracted the IKE PSK hash from the Expressway machine using ike-scan's Aggressive Mode, the next crucial step was to transform that hash back into a readable Pre-Shared Key (PSK). This is where psk-crack comes into play, a powerful tool designed specifically for this purpose. Imagine having a scrambled message and needing a decoder ring; psk-crack is our decoder ring, and a good wordlist is our dictionary. We initiated the cracking process with the command: psk-crack -d /usr/share/wordlists/rockyou.txt hash.txt. The -d flag specifies the dictionary file – in this case, the famous /usr/share/wordlists/rockyou.txt, which is a treasure trove of commonly used passwords. The hash.txt file, which we would have created containing the extracted IKE PSK parameters, provided the cryptographic challenge.

The beauty of psk-crack is its efficiency. It rapidly iterates through the wordlist, hashing each entry and comparing it against the target hash we captured. And folks, psk-crack didn't disappoint! After just a few seconds (specifically, 3.992 seconds and over 8 million iterations in this instance), it shouted out the good news: key "freakingrockstarontheroad" matches SHA1 hash 70e467f9fe0ba53e972f8942c05af7526ec02e09. Bingo! We had found the Pre-Shared Key: freakingrockstarontheroad. This was a massive breakthrough! This password, while initially used for VPN authentication, often gets reused across different services, especially SSH. In penetration testing, finding one credential can often lead to a cascade of further access, and this was exactly the situation we were in.

This entire process, from identifying ISAKMP through Nmap, to extracting the hash with ike-scan, and finally cracking the PSK with psk-crack and the rockyou.txt wordlist, demonstrates a classic and effective method for gaining initial access to systems secured by IPsec VPNs. The ability to turn a cryptographic hash into a plaintext password is a fundamental skill in ethical hacking, unlocking doors that might otherwise seem impenetrable. With freakingrockstarontheroad in hand, we were ready to pivot our attack strategy from network service enumeration to direct user authentication. This moment felt like striking gold, transitioning from theoretical possibility to tangible access, setting us up perfectly for the next phase: gaining a user foothold on the Expressway machine.

Phase 2: Gaining a Foothold – Initial Access via SSH

With the Pre-Shared Key in hand, our primary objective shifted from passive reconnaissance to active system access. The SSH service (port 22) that we identified during our initial Nmap scan now became our prime target for gaining an initial foothold. It’s a common scenario in security assessments where a credential found through one vector can be leveraged for access on another, more interactive service. The user ID ike@expressway.htb from the IKE scan combined with the cracked PSK gave us a strong lead. This phase is all about turning that static password into a dynamic session on the target machine, allowing us to interact with the system, explore its internal structure, and look for further avenues for privilege escalation.

SSHing In: A New Perspective

The moment of truth arrived as we attempted to connect to the Expressway machine via SSH. Armed with the username ike (from ike@expressway.htb) and the freshly cracked PSK, freakingrockstarontheroad, we executed the command: ssh ike@10.129.19.97. And just like that, we were in! The terminal promptly presented us with the familiar ike@expressway:~$ prompt, confirming our successful initial access. This feeling, guys, is what ethical hacking is all about – turning hours of reconnaissance and exploitation into a tangible connection.

Once logged in, our immediate priority was to understand the context of our access. We ran the id command to check our user identity and group memberships. The output was revealing: uid=1001(ike) gid=1001(ike) groups=1001(ike),13(proxy). This told us that ike was a regular user with uid 1001 and, importantly, was a member of the proxy group (gid 13). Membership in specific groups can often grant additional permissions or access to certain directories and files, making this a critical piece of information for our privilege escalation strategy. Being part of the proxy group immediately suggested that we should investigate files or directories associated with proxy services like Squid.

Next, we tried the standard route for privilege escalation: checking sudo permissions. We attempted sudo -l, hoping to find commands that ike could run as root without a password. However, the system quickly responded with: Sorry, user ike may not run sudo on expressway. This was a minor setback, but not uncommon. It simply meant that the direct path to root on this particular host was blocked. But don't despair, because in penetration testing, a "no" on one path often means "yes" on another, less obvious one. We also checked the sudo version with sudo --version, which reported Sudo version 1.9.17. While the content mentioned a hypothetical future CVE, in a real scenario, this version number would be immediately cross-referenced with known sudo vulnerabilities databases to identify any potential exploits. Even if a direct sudo -l didn't yield immediate results, knowing the sudo version can still be a powerful clue for alternative privilege escalation techniques. Our goal now was to leverage the proxy group membership and any potential sudo vulnerabilities to finally achieve root access on Expressway. This initial SSH foothold was a critical step, but the real challenge – privilege escalation – was just beginning.

Phase 3: Scaling the Walls – Privilege Escalation

Alright, folks, we've got our initial access as the ike user on the Expressway machine. But as any good ethical hacker knows, user-level access is rarely the final goal; we're always aiming for that sweet, sweet root access. This is where the real fun begins: privilege escalation. It’s about leveraging every piece of information we've gathered and every permission we've uncovered to climb the ladder to administrative control. This phase requires a keen eye for detail, persistence, and often, a bit of creative thinking to exploit seemingly minor misconfigurations or vulnerabilities. Our ike user, while limited on the main Expressway host, possessed a key clue: membership in the proxy group. This, combined with a quick check of the sudo version, provided the fertile ground for our next steps in scaling the walls to root.

Unmasking Sudo Vulnerabilities: Sudo Version 1.9.17

One of the first things we do when we gain initial access to a system, especially after finding out direct sudo access is denied, is to meticulously check the software versions. Why? Because software vulnerabilities are a hacker's best friend! We quickly checked the sudo version on Expressway using sudo --version. The output proudly displayed Sudo version 1.9.17. Now, while the original prompt mentioned a placeholder CVE-2025-32462, in a real-world penetration test, seeing a specific sudo version like 1.9.17 would immediately trigger a comprehensive search in vulnerability databases (like CVE, Exploit-DB, etc.) for any known exploits or weaknesses. Sudo vulnerabilities are incredibly powerful because they can allow a low-privileged user to execute commands as root.

Even without a specific, publicly known exploit for Sudo version 1.9.17 at the time of this "hypothetical" scenario (or in a scenario where a specific CVE is a placeholder), knowing the version is crucial. It tells us about the attack surface. For instance, older sudo versions might have exploitable bugs that allow for arbitrary command execution or environmental variable manipulation. Attackers often look for ways to bypass sudo restrictions by exploiting flaws in how sudo parses commands, handles paths, or interacts with the environment. If sudo -l on the local host denies all, it doesn't mean sudo itself is impenetrable. It means we need to look for indirect ways to exploit it or alternative configurations. The proxy group membership we identified for ike was our next critical piece of information, pointing us away from a direct sudo version exploit on the local host and towards a more nuanced approach involving host-specific configurations. So, while sudo version 1.9.17 might not have an immediate, drop-dead exploit, it's always a flag that commands attention and makes us think about alternative privilege escalation paths. This methodical checking of versions is a cornerstone of any ethical hacking engagement, as it often uncovers the hidden paths to root access that administrators might overlook.

Subdomain Discovery and the proxy Group Clue

Since direct sudo access was denied on expressway.htb for our ike user, we had to dig deeper. Remember that ike was a member of the proxy group? This was a significant clue! Group memberships often dictate access permissions to files and directories. So, our next logical step was to identify what files and directories belonged to or were accessible by the proxy group. We executed the command find / -group proxy 2>/dev/null, which searches the entire filesystem for files and directories associated with the proxy group, suppressing any error messages to keep the output clean.

This find command proved to be incredibly fruitful. Among the various results related to Squid proxy service logs and cache directories, one entry stood out like a lighthouse in the fog: /var/log/squid/access.log.1. As ethical hackers, we know that log files often contain valuable operational intelligence. We immediately cated the contents of this log file, specifically looking for entries related to the target's internal network or other hosts. Our grep command was simple but effective: cat /var/log/squid/access.log.1 | grep htb. And there it was! A clear entry stating: 1753229688.902 0 192.168.68.50 TCP_DENIED/403 3807 GET http://offramp.expressway.htb - HIER_NONE/- text/html.

This line was an absolute goldmine! It explicitly revealed a subdomain: offramp.expressway.htb. Why is this a big deal, you ask? Well, in many corporate environments, different subdomains or hosts within the same domain might have distinct sudoers configurations. An administrator might lock down sudo permissions on the main server (expressway.htb) but grant more lenient permissions on an internal or development subdomain (offramp.expressway.htb) that developers or specific users might need. This discovery dramatically shifted our privilege escalation strategy from trying to find a local exploit on expressway.htb to attempting to leverage sudo permissions on this newly discovered subdomain. The proxy group membership led us directly to the Squid logs, which in turn unveiled the offramp.expressway.htb subdomain. This is a prime example of how interconnected pieces of information, when patiently pursued, can lead to the ultimate breakthrough in a penetration test.

The Golden Ticket: sudo -h offramp.expressway.htb

With the discovery of the offramp.expressway.htb subdomain and the knowledge that different hosts might have different sudoers rules, we had a new target for our privilege escalation attempt. The sudo command has a very useful, yet often overlooked, option: -h, which allows you to specify a hostname for which to check or execute sudo commands. This is exactly what we needed to check if our user ike had different privileges on offramp compared to expressway.

We ran sudo -l -h offramp.expressway.htb. This command specifically queries the sudoers configuration for user ike on the host offramp.expressway.htb. The response was immediate and glorious:

Matching Defaults entries for ike on offramp:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

User ike may run the following commands on offramp:
    (root) NOPASSWD: ALL
    (root) NOPASSWD: ALL

Folks, this was it! The golden ticket! The output clearly stated: User ike may run the following commands on offramp: (root) NOPASSWD: ALL. This meant that our ike user, when acting as if on the offramp.expressway.htb host, could execute any command as the root user without needing a password. This is the absolute dream scenario for privilege escalation! The duplicated (root) NOPASSWD: ALL lines simply confirm that the rule is active and fully permissive. It means that the administrators, perhaps inadvertently or for specific internal tooling, had granted ike full root privileges on this subdomain.

To capitalize on this, we simply needed to execute a shell as root using this newfound permission. We used the command: sudo -s -h offramp.expressway.htb. The -s flag requests a shell, and -h offramp.expressway.htb directs the sudo command to apply the rules for that specific host. The result? Instant root access! Our prompt changed to root@expressway:/home/ike#, and a quick id command confirmed it: uid=0(root) gid=0(root) groups=0(root). We had successfully escalated our privileges to the highest level on the Expressway machine. This entire journey, from a simple Nmap scan to IKE cracking, subdomain discovery through proxy logs, and finally, exploiting a host-specific sudoers misconfiguration, showcases the interconnectedness of different vulnerabilities and the importance of a thorough, systematic approach in penetration testing. What an awesome ride to root!

Conclusion: Lessons Learned on the Expressway

And there you have it, folks! We've successfully navigated the digital lanes of the Expressway, from initial reconnaissance all the way to securing root access. This journey has been a fantastic example of a complete penetration testing lifecycle, highlighting several critical takeaways that are super valuable for anyone interested in network security and ethical hacking.

First off, never underestimate the power of thorough reconnaissance, especially when it comes to UDP scanning. While TCP port 22 (SSH) was the only open door initially, our UDP scan revealed port 500 (ISAKMP), which turned out to be the linchpin for initial access. Many times, the less obvious paths are the most rewarding! So, always go that extra mile in your Nmap scans.

Secondly, understanding and leveraging specialized tools like ike-scan and psk-crack is absolutely crucial when dealing with VPN services and Pre-Shared Key (PSK) authentication. The ability to extract IKE PSK hashes from Aggressive Mode handshakes and then crack them offline using a robust wordlist like rockyou.txt is a powerful technique. This led us to the password freakingrockstarontheroad, which was our entry point via SSH.

Finally, privilege escalation isn't always about direct software exploits or straightforward sudo permissions on the primary host. Our ike user's membership in the proxy group was a subtle yet significant clue. It led us to scour proxy logs (/var/log/squid/access.log.1), which then unveiled the hidden subdomain offramp.expressway.htb. This discovery, combined with the often-overlooked sudo -h option, allowed us to exploit a host-specific sudoers misconfiguration (NOPASSWD: ALL) on offramp, granting us ultimate root access.

This entire experience on the Expressway machine teaches us that cybersecurity is a complex puzzle where every piece of information, no matter how small, can be vital. It underscores the importance of a systematic approach, patience, and the continuous pursuit of overlooked details. For system administrators, this serves as a stark reminder to review all sudoers configurations across all hosts and subdomains, disable unnecessary IKE Aggressive Mode features, and enforce strong, unique Pre-Shared Keys. For us ethical hackers, it's a testament to the thrill of the hunt and the satisfaction of uncovering hidden paths to victory. Keep learning, keep hacking responsibly, and stay curious, guys! Until next time, happy hacking!