Login
Hack The Box: Eureka Machine Walkthrough – Hard Dificulty
Introduction to Eureka:
In this writeup, we will explore the “Eureka” machine from Hack The Box, categorised as a Hard difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.
Objective:
The goal of this walkthrough is to complete the “Eureka” machine from Hack The Box by achieving the following objectives:
User Flag:
During enumeration, we discovered Spring Boot Actuator endpoints, including /actuator/heapdump, which revealed plaintext credentials for oscar190. We logged in to SSH as oscar190, but found the home directory empty. The application.properties file revealed Eureka credentials (EurekaSrvr:0scarPWDisTheB3st), which allowed us to access the Eureka dashboard on port 8761. By registering a malicious microservice, we retrieved miranda.wise credentials and captured the user flag from user.txt.
Root Flag:
For privilege escalation, the vulnerable log_analyse.sh script allowed command injection, enabling creation of a SUID bash shell in /tmp/bash. Execution of this shell provided root access, and the root flag was obtained from /root/root.txt.
Enumerating the Eureka Machine
Reconnaissance:
Nmap Scan:
Begin with a network scan to identify open ports and running services on the target machine.
nmap -sC -sV -oA initial 10.10.11.66Nmap Output:
┌─[dark@parrot]─[~/Documents/htb/eureka]
└──╼ $nmap -sC -sV -oA initial 10.10.11.66
# Nmap 7.94SVN scan initiated Sun Aug 24 03:30:10 2025 as: nmap -sC -sV -oA initial 10.10.11.66
Nmap scan report for 10.10.11.66
Host is up (0.046s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 d6:b2:10:42:32:35:4d:c9:ae:bd:3f:1f:58:65:ce:49 (RSA)
| 256 90:11:9d:67:b6:f6:64:d4:df:7f:ed:4a:90:2e:6d:7b (ECDSA)
|_ 256 94:37:d3:42:95:5d:ad:f7:79:73:a6:37:94:45:ad:47 (ED25519)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://furni.htb/
|_http-server-header: nginx/1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Aug 24 03:30:21 2025 -- 1 IP address (1 host up) scanned in 10.99 secondsAnalysis:
- Port 22 (SSH): Secure Shell service (OpenSSH 8.2p1) for remote access.
- Port 80 (HTTP): Web server (nginx 1.18.0) hosting
furni.htb.
Web Enumeration:
Perform web enumeration to discover potentially exploitable directories and files.
gobuster dir -u http://furni.htb/ -w /opt/quickhits.txtGobuster Output:
┌─[dark@parrot]─[~/Documents/htb/eureka]
└──╼ $gobuster dir -u http://furni.htb/ -w /opt/quickhits.txt
/actuator (Status: 200) [Size: 2129]
/actuator/caches (Status: 200) [Size: 20]
/actuator/features (Status: 200) [Size: 467]
/actuator/info (Status: 200) [Size: 2]
/actuator/health (Status: 200) [Size: 15]
/actuator/env (Status: 200) [Size: 6307]
/actuator/metrics (Status: 200) [Size: 3319]
/actuator/refresh (Status: 405) [Size: 114]
/actuator/sessions (Status: 400) [Size: 108]
/actuator/scheduledtasks (Status: 200) [Size: 54]
/actuator/mappings (Status: 200) [Size: 35560]
/actuator/loggers (Status: 200) [Size: 98261]
/actuator/beans (Status: 200) [Size: 202254]
/actuator/configprops (Status: 200) [Size: 37195]
/actuator/conditions (Status: 200) [Size: 184221]
/actuator/threaddump (Status: 200) [Size: 176397]Analysis:
Spring Boot Actuator endpoints provide insights:
/actuatorshows system details,/cachesshows cache info,/featureslists features,/infogives metadata,/healthshows status,/envshows variables,/metricsshows performance,-
/refreshreturns 405, /sessionsreturns 400,/scheduledtasksshows tasks,/mappingslists routes,/loggersshows logs,-
/beanslists beans, /configpropsshows config,/conditionsshows auto-config,/threaddumpshows threads.
Feroxbuster directory enumeration identified the following endpoints:
Analysis:
- /actuator/heapdump: Full application heap dump (very sensitive, ~76MB).
The heapdump is usually the biggest goldmine here—it can contain hardcoded credentials, JWT secrets, API keys, or session tokens.
Web Application Exploration:
The website interface appears to be a standard design showcasing a Modern Interior Design Studio.
Create a new user account
Therefore, proceed with creating a new account using the credentials mentioned above.
The password must contain a minimum of 10 characters.
Attempted to log in with the previously created credentials, but the response only returned bad credentials with no further action.
Extracting Eureka Service Credentials from Heapdump as oscar190
Proceed to download the heapdump by directly accessing the /actuator/heapdump endpoint through the web browser
To analyze the downloaded heapdump, run the strings command and pipe the output into grep to look for potential credentials. For example, using strings heapdump.hprof | grep -i "password=" will filter for any occurrences of the keyword password= within the dump. If no useful results are found, the search can be expanded with broader patterns such as pass, user, token, secret, or key to uncover sensitive information like database passwords, API keys, or authentication tokens stored in memory. This approach provides a quick way to extract valuable data from the heapdump before performing deeper analysis with tools like Eclipse MAT.
Heapdump analysis revealed valid plaintext credentials:
- Username:
oscar190 - Password:
0sc@r190_S0l!dP@sswd
Failed Authentication Attempts with Extracted Credentials
┌─[dark@parrot]─[~/Documents/htb/eureka]
└──╼ $nmap -sC -sV -p- -oA fullport 10.10.11.66
8761/tcp open unknown
| fingerprint-strings:
| GetRequest:
| HTTP/1.1 401
| Vary: Origin
| Vary: Access-Control-Request-Method
| Vary: Access-Control-Request-Headers
| Set-Cookie: JSESSIONID=052BB32927ACF7E3EC6D4104D8933C61; Path=/; HttpOnly
| WWW-Authenticate: Basic realm="Realm"
| X-Content-Type-Options: nosniff
| X-XSS-Protection: 0
| Cache-Control: no-cache, no-store, max-age=0, must-revalidate
| Pragma: no-cache
| Expires: 0
| X-Frame-Options: DENY
| Content-Length: 0
| Date: Sun, 24 Aug 2025 04:16:36 GMT
| Connection: close
| HTTPOptions:
| HTTP/1.1 401
| Vary: Origin
| Vary: Access-Control-Request-Method
| Vary: Access-Control-Request-Headers
| Set-Cookie: JSESSIONID=F7494079A8B84CF8089636498980649E; Path=/; HttpOnly
| WWW-Authenticate: Basic realm="Realm"
| X-Content-Type-Options: nosniff
| X-XSS-Protection: 0
| Cache-Control: no-cache, no-store, max-age=0, must-revalidate
| Pragma: no-cache
| Expires: 0
| X-Frame-Options: DENY
| Content-Length: 0
| Date: Sun, 24 Aug 2025 04:16:36 GMT
| Connection: closeAs a result, a full port scan will identify any additional services accessible on the target system.
Attempting Access to oscar190 via Eureka Dashboard and SSH
An attempt to use the previously discovered credentials for authentication failed, with all login attempts unsuccessful.
We used pwncat-cs to test the recovered credentials against SSH. The login was successful, and we gained remote access to the target system.
Enumeration as oscar190
After gaining access, we inspected the oscar190 directory. It was empty and contained no useful files for further exploitation.
We also checked for SUID binaries on the system, but found no unusual or exploitable ones.
During enumeration, we found a notable file at ./web/Funi/src/main/resource/application.properties containing sensitive information, including credentials that revealed the password for the oscar190 user.
Most importantly, under the Eureka section you discovered:
eureka.client.service-url.defaultZone= http://EurekaSrvr:0scarPWDisTheB3st@localhost:8761/eureka/This line shows the Eureka service uses embedded credentials:
- Username:
EurekaSrvr - Password:
0scarPWDisTheB3st
These new credentials are different from oscar190. They may be valid for the Eureka dashboard (port 8761) or other services like SSH, MySQL, or the web portal.
Accessing Spring Eureka Dashboard on Port 8761 Using Discovered Credentials
The newly discovered credentials (EurekaSrvr:0scarPWDisTheB3st) were tested against the Eureka service endpoint. Authentication was successful, confirming valid access to the Eureka configuration interface.
Surprisingly, the credentials worked and granted access to the Spring Eureka application dashboard, confirming control over the service.
Monitoring System Activity and Command Execution with pspy64
The pspy64 output revealed that a scheduled task is being executed by the root user, which uses curl to send a POST request to http://furni.htb/login. The request is crafted to resemble a normal browser login, with headers such as Accept, Content-Type, User-Agent, and a session cookie included. Most importantly, the POST data is not hardcoded in the command but instead read from the temporary file /tmp/tmp.hJ3yAWDvEW. the file is writable or replaceable by a lower-privileged user, it may be possible to inject malicious data or commands into it, allowing code execution under root’s context whenever the automated task runs.
Cloud-Gateway Enumeration and Insight
During enumeration, a directory named cloud-gateway was discovered, which stands out as it is not typically present in standard web application structures. Given its uncommon presence, this directory warrants deeper inspection to determine whether it contains exploitable configurations or hidden endpoints.
Source: Cloud management gateway overview
The cloud-gateway directory was identified within the application files, which is uncommon in typical setups and indicates the use of Spring Cloud Gateway for routing and service communication. Such directories often contain sensitive configuration files, route definitions, or embedded credentials, making it an important target for closer inspection during enumeration.
Analysing the application.yaml Configuration File
It appears that the request is being passed to the user-management-service component, located under the path /var/www/web, specifically beneath the /login functionality. This suggests that authentication requests from /login are routed internally to the user-management-service, which likely handles user validation and credential processing.
HTTP Login Endpoint Hijacking via User-Management-Service
Inside the user-management-service directory, several files and subdirectories were identified, indicating this component is likely responsible for handling authentication and account-related functionality within the application. Since it sits directly under /var/www/web, its contents may include configuration files, source code, or compiled application resources that could expose sensitive information such as database credentials, API keys, or logic flaws.
The files discovered within the user-management-service directory were copied over to the attacker’s machine for further offline analysis. This allows deeper inspection of configuration details, source code, and potential hardcoded secrets without the risk of altering the target environment.
The application.properties and Eureka-related configuration files contain fields such as <instanceId>, <hostName>, <ipAddr>, <port>, <homePageUrl>, <statusPageUrl>, and <healthCheckUrl>. By modifying these values to match the attacker’s controlled IP address and port, it is possible to redirect the service registration in Eureka to point toward a malicious service instead of the legitimate one.
Retrieving miranda.wise Credentials and Capturing User Flag
The first command performs a POST request to register a new instance of the USER-MANAGEMENT-SERVICE application, where the configuration details (such as instance ID, host, IP address, and port) are provided in an external instance.xml file. By modifying this XML file with the attacker’s own machine details, it is possible to make Eureka believe that the legitimate service now points to the attacker-controlled host. The second command issues a DELETE request targeting the existing service entry localhost:USER-MANAGEMENT-SERVICE:9009, which corresponds to the genuine application running locally on port 9009.
A successful callback was received, which revealed system details tied to the user miranda.wise. This indicates that the malicious service registration worked as intended, and the compromised microservice forwarded traffic to the attacker-controlled host, exposing valuable information about another valid user account in the environment.
The user flag was captured by reading the user.txt file with the cat command.
Escalate to Root Privileges Access
Privilege Escalation:
We did not identify any unusual or exploitable SUID binaries on the system.
A script named log_analyse.sh was discovered on the system, which stands out as a potential target for further analysis to determine if it contains insecure commands, misconfigurations, or privilege escalation opportunities.
Analysis of log_analyse.sh Script
This script is a log analyser that examines server logs to track three key aspects: who’s logging in (successfully or not), what HTTP errors are occurring, and any system errors worth noting. It’s got some nice touches – colour-coded outputs for quick scanning and a clean report saved to log_analysis.txt.
grep "HTTP.*Status: " "$LOG_FILE" | while read line; do
code=$(echo "$line" | grep -oP 'Status: \K.*')
if [[ "$existing_code" -eq "$code" ]]; then
new_count=$((existing_count + 1))
STATUS_CODES[$i]="${existing_code}:${new_count}"This Bash script analyzes log files, extracting login attempts, HTTP status codes, and errors, then saves results to log_analysis.txt. A key function, analyze_http_statuses(), parses HTTP status codes using grep -oP 'Status: \K.*'. However, it’s vulnerable to command injection—if logs contain malicious strings like $(malicious_command), Bash will execute them when processing the file.
The output demonstrates the behavior of the log_analyse.sh script when executed, showing that it processes and reads the contents of application.log. This indicates that the script’s purpose is related to log handling, and analyzing its execution flow could reveal opportunities for manipulation or privilege escalation.
The original file was copied, then deleted, and after restoring it, the file ownership changed from www-data to miranda-wise.
Exploiting Bash SUID for Privilege Escalation
The bash script does not run with root privileges.
It defines two target log files located in the user-management-service and cloud-gateway directories, then injects a malicious payload into them. The payload attempts to execute a command substitution by copying /bin/bash to /tmp/bash and setting the SUID bit, effectively creating a root-privileged shell. To achieve this, the script removes the original log files and replaces them with the crafted payload. Once the vulnerable process or script that parses these logs executes the injected content, the attacker gains elevated privileges via the SUID-enabled /tmp/bash.
We then executed the crafted bash file, which replaced the targeted log files with the injected payload, preparing for privilege escalation once the vulnerable service processes the modified logs.
Running the script produced no immediate effect, suggesting the logs remained unprocessed or required additional conditions.
After some time, the injected payload successfully executed and resulted in the creation of a SUID bash binary inside the /tmp directory, allowing privilege escalation. By running ls -l /tmp/bash, the SUID bit could be confirmed, and executing /tmp/bash -p provided a root shell since the binary retains elevated privileges. From there, commands like id could be used to verify root access, and the final step was reading the root.txt file located in the /root directory to obtain the root flag and complete the exploitation.
The root flag was retrieved by executing the cat root.txt command.
The post Hack The Box: Eureka Machine Walkthrough – Hard Dificulty appeared first on Threatninja.net.
