Welcome to another Hack the Box walkthrough. In this blog post, I have demostrated how I owned the Eureka 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
Eureka is a hard Linux machine which incorporated a password leakage in heapdump and a vulnerability in the Eureka service on the intranet port, by registering a fake microservice instance and obtaining user credentials. The Linux machine also feature an array comparison vulnerability by modifying a log file to achieve privilege escalation.
The scan quickly revealed that the box was alive and exposing just two services:
- Port 22 (SSH) – running OpenSSH 8.2p1 on Ubuntu. While SSH is always useful for eventual access, it typically requires valid credentials or a private key, so I noted it down for later.
- Port 80 (HTTP) – served by nginx 1.18.0. Interestingly, the HTTP title indicated a redirect to another virtual host:
http://furni.htb/. This suggested the presence of a vhost setup, and likely meant I’d need to addfurni.htbto my/etc/hostsfile before I could explore the web application properly.
The OS fingerprinting also hinted at the target running a Linux 5.x kernel, with possible traces of MikroTik RouterOS signatures (likely a false positive due to overlapping TCP/IP fingerprints). The traceroute confirmed the host was just two hops away on the HackTheBox network.
At this point, the real lead was the web server and its furni.htb virtual host, which looked like the intended attack surface. SSH would remain on the backburner until I uncovered credentials through web exploitation or enumeration.
Since the Nmap scan revealed that the web server on eureka.htb was redirecting to furni.htb, I suspected the target was using virtual hosting. By default, my system wouldn’t know how to resolve that hostname, so I had to manually map it to the target’s IP address.
I edited the /etc/hosts file to include both domains:
http://furni.htb/ in my browser, it would resolve directly to the machine’s IP on the HackTheBox network. With this step complete, I was ready to start enumerating the web application hosted on furni.htb.With the furni.htb domain mapped in /etc/hosts, I browsed to the site and was greeted with what appeared to be a fully functional furniture e-commerce platform.
The landing page branded itself as “Furni. – Modern Interior Design Studio”, showcasing different categories of furniture, a shopping cart, and even a checkout process. From the look of it, the site was built to mimic a legitimate online store.
Key features stood out immediately:
- User Registration & Login – suggesting some form of authentication system that could potentially be abused if implemented insecurely.
- Shopping Cart & Checkout – users could add items to their cart and proceed with purchases.
- Dynamic Content – several links like Shop, About Us, Services, Blog, and Register indicated that the site might have multiple endpoints worth enumerating.
At this stage, however, nothing on the front page appeared directly vulnerable. The registration and purchase functionality worked as expected, but didn’t immediately reveal an exploit vector. This meant the real attack surface was likely hidden deeper — either in unlisted directories, API endpoints, or backend services tied to the site.
The next logical step was to begin enumerating directories and subpages with a tool like dirsearch, ffuf or gobuster, hoping to uncover something the developers hadn’t meant to expose.
The scan turned out to be very fruitful. Alongside the expected pages like /about, /shop, /services, /register, and /login, I stumbled upon something far more interesting:
- A whole set of Spring Boot Actuator endpoints under
/actuator/. These are debugging and monitoring routes that developers usually forget to lock down. The scan revealed endpoints such as/actuator/env,/actuator/beans,/actuator/configprops,/actuator/mappings,/actuator/metrics, and even/actuator/heapdump. - These are goldmines in CTFs (and real-world pentests) because they often expose sensitive information about the application’s environment, configuration, or even memory contents.
- The
/blogdirectory also stood out, but it seemed to just host regular content with no immediate vulnerabilities. - Shopping features like
/cart,/checkout, and/commentredirected unauthenticated users back to/login, confirming that these actions required valid credentials.
The big takeaway here was the exposed Spring Actuator panel. Among the various endpoints, /actuator/env looked particularly promising since it often leaks environment variables — including database credentials, API keys, or internal service URLs. Even more striking was /actuator/heapdump, which produced a massive 76MB file — a strong indication that memory contents of the running application could be downloaded.
At this point, I knew the path forward: enumerate the Actuator endpoints to hunt for secrets that could help me move deeper into the system.
/actuator/env. This endpoint is known for dumping application environment variables and configuration values.
returned a detailed JSON output containing the server’s environment configuration. Buried within the noise were sensitive values — things like database connection strings, usernames, and API keys. This was a clear indication that the developers had left debugging enabled in production. Such information could easily be leveraged to gain deeper access into the system.
Next, I turned to the most dangerous of the lot:
This endpoint allowed me to download a massive 76MB .hprof file. A heap dump is essentially a snapshot of the application’s memory at runtime, and analyzing it can reveal plaintext secrets — usernames, passwords, session tokens, and other sensitive data that were loaded in memory at the time of the dump.
In a real-world attack, this kind of leak would be critical, as an attacker could mine the dump for authentication credentials or other exploitable tokens. In the context of this CTF, it was clear that the heap dump would contain something I could use to pivot further into the machine.
With the heap dump in hand, I set out to mine it for sensitive information. Heap dumps are memory snapshots of a running Java application, so it’s common to find credentials, API tokens, or session data lingering inside.
To keep things simple, I used the strings command to extract readable text from the dump and then grepped for anything related to passwords:
This gave me a username: oscar190 and a password: 0sc@r190_S0l!dP@sswd.
It looked like I had struck gold — valid credentials that could be reused either on the website’s login form or, even better, through SSH access since port 22 was open. The next step was obvious: try these credentials against the available services to see where they would get me in.
Armed with the credentials from the heap dump (oscar190 : 0sc@r190_S0l!dP@sswd), I moved on to test them against the SSH service exposed on port 22. With the credentials oscar190 : 0sc@r190_S0l!dP@sswd in hand, I attempted a direct SSH connection to the target:
On the first connection, SSH prompted me to verify the host’s fingerprint. Since this was my initial login to the box, I confirmed the authenticity and permanently added furni.htb to my list of known hosts.
After entering the password, I successfully authenticated as oscar190 and landed on a shell running Ubuntu 20.04.6 LTS with kernel 5.4.0-214-generic.
Comments
Post a Comment