Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the Reactor 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
Reactor is an easy difficulty Linux machine on Hack The Box that focuses on modern web exploitation, JavaScript framework enumeration, credential discovery, and Node.js inspector abuse for privilege escalation. The machine demonstrates how a vulnerable frontend framework combined with insecure debugging configurations can lead to full system compromise. The attack chain involves exploiting a vulnerable Next.js application, gaining remote code execution, extracting credentials from an exposed SQLite database, pivoting through SSH access, and ultimately abusing a root-owned Node.js inspector process to gain root privileges.
The exploitation process started with Nmap enumeration, which revealed SSH running on port 22 and a Next.js web application hosted on port 3000. After performing host configuration by updating the /etc/hosts file, the application became accessible through the reactor.htb hostname. During web enumeration, the ReactorWatch monitoring dashboard exposed a futuristic nuclear reactor monitoring interface, indicating that the application heavily relied on modern JavaScript technologies.
Using Wappalyzer during technology enumeration, the application was identified as running Next.js 15.0.3, a version vulnerable to CVE-2025-55182. Further vulnerability research led to the discovery of a public GitHub proof-of-concept exploit capable of achieving remote code execution through React Server Component prototype pollution. During exploit preparation, the exploit repository was cloned locally, a Python virtual environment was configured, and all required dependencies were installed before launching the attack.
For initial access, a Netcat listener was configured and the public exploit was executed against the vulnerable Next.js application using a reverse shell payload. Although the exploit returned a timeout error, the payload executed successfully and established a reverse shell as the low-privileged node user inside the /opt/reactor-app directory. This foothold allowed extensive post-exploitation enumeration of the underlying Linux system.
During flag enumeration and filesystem inspection, several application files were discovered, including a .env configuration file and a SQLite database named reactor.db. Application enumeration revealed sensitive environment configuration values, API keys, and database connection information. Connecting to the SQLite database exposed a users table containing credential hashes for both the admin and engineer accounts.
Through credential enumeration and password cracking, the MD5 hash associated with the engineer account was cracked using CrackStation, revealing the plaintext password xxxxxxxx. Since engineer was also a valid Linux system user, the recovered credentials were reused for SSH access, successfully providing a stable interactive shell on the machine. After authenticating over SSH as engineer, the user flag was captured from the user’s home directory.
The privilege escalation phase began with further privilege escalation enumeration, where group memberships and sudo permissions were inspected. Although the user lacked sudo privileges, additional process enumeration revealed a root-owned Node.js service running /opt/uptime-monitor/worker.js with the Node.js inspector enabled locally on port 9229. During node inspection enumeration, the local debugging service was confirmed accessible through the built-in node inspect client.
Finally, root privilege escalation was achieved by abusing the root-owned Node.js inspector runtime. Using the debugger’s exec() functionality, arbitrary system commands were executed directly as root. After confirming root-level execution with the id command, the root flag was successfully retrieved from /root/root.txt, completing the full compromise of the Reactor machine.
Protected Page
The first step in owning the Reactor machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:
Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the SmartHire machine and I was assigned an IP address (10.129.6.138).
Nmap Enumeration
I started the enumeration phase by running a full service and version scan against the target machine to identify exposed services, running applications, and possible attack surfaces. The scan immediately revealed two open ports: SSH on port 22 and a web application running on port 3000.
The SSH service was identified as OpenSSH 9.6p1 running on Ubuntu, confirming the target is Linux-based. More interestingly, port 3000 hosted a web application powered by Next.js, which was confirmed through the X-Powered-By: Next.js response header returned during enumeration. The application responded with valid HTTP content and exposed several internal Next.js routes and static assets under the /_next/ directory, indicating a modern JavaScript frontend framework.
Although Nmap could not accurately fingerprint the service on port 3000, the HTTP responses clearly showed the application only allowed GET and HEAD requests, returning 400 Bad Request for unsupported methods. Based on the OS fingerprinting results, the target appeared to be running a Linux 5.x kernel, making the web service the primary focus for further enumeration and exploitation.
Host Configuration
After identifying the target during enumeration, I configured local DNS resolution by adding the machine hostname to my /etc/hosts file. This ensured that requests sent to reactor.htb would correctly resolve to the target IP address instead of relying on external DNS resolution.
This step is commonly required in Hack The Box environments because many web applications rely on virtual host routing and may not respond properly when accessed directly through the IP address. Once the hostname was configured locally, I was able to interact with the application using http://reactor.htb, which prepared the environment for deeper web enumeration.
Web Enumeration
After configuring the hostname, I visited the web application running on port 3000 to begin manual web enumeration. The application loaded a futuristic monitoring dashboard called ReactorWatch, which appeared to simulate a nuclear reactor control and monitoring system.
The dashboard exposed several real-time monitoring panels such as reactor temperature, coolant flow, pressure levels, turbine output, and system logs. I also observed references to internal personnel accounts and operational data, suggesting the application might contain hidden functionality or administrative features behind the frontend interface. Since the page appeared heavily JavaScript-driven and built with Next.js, this became the primary target for further enumeration using source code analysis, endpoint discovery, and JavaScript inspection.
Technology Enumeration
To identify the technologies powering the application, I used the Wappalyzer browser extension during web enumeration. The analysis revealed that the ReactorWatch application was built using the Next.js JavaScript framework version 15.0.3, alongside React-based frontend components.
This finding was particularly interesting because Next.js 15.0.3 was known to be affected by CVE-2025-55182, a vulnerability impacting certain Next.js deployments. Identifying the exact framework version helped narrow the attack surface and shifted my focus toward researching publicly known vulnerabilities, misconfigurations, and potential exploit paths related to the affected Next.js release.
Vulnerability Research
After identifying the application framework, I began researching publicly known vulnerabilities affecting Next.js 15.0.3. During this process, I discovered a GitHub proof-of-concept repository for CVE-2025-55182, which targeted React Server Components through a prototype pollution vulnerability that could lead to remote code execution.
The repository contained a working exploit script capable of abusing vulnerable Next.js implementations to achieve command execution on the target server. Since the ReactorWatch application matched the affected framework version, this vulnerability immediately became the primary attack vector for gaining initial access to the machine.
Exploit Preparation
After confirming that the target was running a vulnerable version of Next.js, I cloned the public proof-of-concept repository for CVE-2025-55182 to my local machine. I then moved into the project directory and reviewed the exploit files provided by the researcher.
To avoid dependency conflicts on my host system, I created and activated a dedicated Python virtual environment for the exploit. I then installed the required Python packages needed for the exploit script to execute properly.
With the environment fully prepared and all dependencies installed successfully, the exploit framework was ready for testing against the ReactorWatch application. This setup phase ensured the proof-of-concept could run cleanly before attempting remote code execution against the target.
Initial Access
To prepare for exploitation, I first configured a Netcat listener on my attack machine to receive an incoming reverse shell connection from the target. This listener waited for any connection on port 4444.
With the listener running, I executed the public CVE-2025-55182 exploit against the vulnerable Next.js application and supplied a Bash reverse shell payload pointing back to my attacker IP address.
Although the exploit script returned a timeout error, the payload executed successfully in the background. Moments later, my Netcat listener received a connection from the target, dropping me into an interactive shell as the node user inside the /opt/reactor-app directory, confirming successful remote code execution and initial access to the machine.
Post-Exploitation Enumeration
After gaining initial access, I began enumerating the compromised environment to understand the privileges assigned to the current user and identify other accounts present on the system. I first verified my execution context using the id command.
The output confirmed that the reverse shell was running as the low-privileged node service account, which is commonly used to host Node.js applications. I then enumerated local system users by reviewing the /etc/passwd file to identify valid login accounts and potential privilege escalation targets.
During this enumeration phase, I discovered a regular user account named engineer with an interactive Bash shell and a home directory located at /home/engineer. This immediately stood out as a likely target for lateral movement or credential discovery, while the current node account appeared restricted with /usr/sbin/nologin.
Flag Enumeration
After identifying the available users on the system, I started searching for potential flag files across the filesystem. I used a recursive find command while suppressing permission errors to quickly locate anything containing the keyword flag.
The command returned a large amount of noise consisting mostly of kernel headers, system files, and internal Linux flag-related resources. Although no obvious user or root flag was immediately exposed, this enumeration step confirmed that the filesystem contained extensive development packages and kernel headers installed on the machine. Since the direct flag search did not reveal anything useful, I shifted focus toward manual privilege escalation enumeration and investigating the engineer user account discovered earlier.
Application Enumeration
After the initial filesystem enumeration produced mostly noise, I shifted my focus toward the Node.js application directory hosting the vulnerable web service. I first inspected the node user’s home directory to look for shell history, credentials, or hidden configuration files.
The home directory appeared mostly clean, and the .bash_history file was intentionally linked to /dev/null, preventing command history logging. I then enumerated the contents of the /opt/reactor-app directory where the web application was running.
This revealed several interesting files related to the Next.js application, including a .env configuration file, application source directories, and a SQLite database named reactor.db. The presence of both the environment configuration file and the database immediately stood out as high-value targets for credential discovery and further privilege escalation opportunities.
Credential Enumeration
While enumerating the application directory, I inspected the .env configuration file to identify database paths, API keys, and other sensitive application secrets used by the ReactorWatch platform.
The configuration revealed that the application was using a local SQLite database named reactor.db. I connected to the database using sqlite3 and began enumerating the available tables and stored user information.
Inside the users table, I discovered two accounts: admin and engineer, both containing MD5-style password hashes. Since the engineer account was also a valid system user identified earlier during enumeration, these credentials immediately became a strong candidate for password cracking and potential lateral movement on the host.
Password Cracking
After extracting the user hashes from the SQLite database, I focused on cracking the MD5 hash belonging to the engineer account. Since the hash appeared unsalted and relatively weak, I tested it against the CrackStation online hash database.
The hash was successfully cracked almost instantly, revealing the plaintext password reactor1. This was a significant breakthrough because the engineer account existed both inside the application database and as a valid Linux system user discovered earlier during enumeration. With valid credentials now recovered, I prepared to attempt authenticated access and potential lateral movement on the target system.
SSH Access
After recovering the plaintext password for the engineer account, I attempted to authenticate to the target over SSH using the newly cracked credentials. Since SSH was exposed during the initial Nmap scan, this provided a reliable method for obtaining a more stable interactive shell on the machine.
Using the password reactor1, I successfully authenticated as the engineer user and obtained direct shell access to the host. Upon login, the system displayed a custom ReactorWatch banner associated with the nuclear monitoring environment, confirming that I had transitioned from the low-privileged node service account to a legitimate user account with interactive shell access.
User Flag
After successfully authenticating as the engineer user through SSH, I began enumerating the user’s home directory for sensitive files and challenge artifacts. Almost immediately, I discovered the user.txt file stored directly inside the home directory.
Reading the file revealed the user flag, confirming successful compromise of the initial user account on the machine. At this stage, I had fully transitioned from remote code execution through the vulnerable Next.js application to authenticated SSH access as a legitimate system user, completing the user-level objective and preparing for privilege escalation toward root access.
Privilege Escalation Enumeration
After capturing the user flag, I began enumerating the engineer account to identify possible privilege escalation vectors. I first checked the user’s group memberships and then verified whether the account had any sudo privileges configured on the system.
The enumeration revealed that the engineer user belonged to several interesting groups, most notably the lxd group, which is commonly associated with container management and has historically been abused for privilege escalation. However, attempting to enumerate sudo permissions confirmed that the user was not allowed to execute commands as root through sudo. With no direct sudo access available, the lxd group membership immediately became the most promising path toward obtaining root privileges on the machine.
Process Enumeration
After confirming that engineer had no sudo privileges, I started looking for root-owned services that could expose another privilege escalation path. I listed running processes and filtered for anything owned by root.
Most of the output contained normal system and kernel processes, but one entry immediately stood out: a root-owned Node.js process running /opt/uptime-monitor/worker.js with the inspector enabled on 127.0.0.1:9229. This was an important discovery because the Node.js inspector can expose debugging capabilities locally, meaning the next step was to investigate whether I could interact with that service from the engineer account and abuse it for root-level code execution.
Node Inspector Enumeration
After identifying the root-owned Node.js process, I checked whether the debugger port was actively listening on localhost. The result confirmed that port 9229 was open only on 127.0.0.1, meaning it was not externally exposed but could still be reached locally from the compromised host.
I then connected to the local Node.js inspector using the built-in node inspect client.
The connection was successful and dropped me into the debug> prompt. Since this debugger was attached to a Node.js process running as root, gaining access to the inspector created a strong privilege escalation opportunity by allowing further interaction with the root-owned runtime.
Root Privilege Escalation
With access to the root-owned Node.js inspector, I leveraged the exec() functionality to execute system commands directly through the privileged Node.js process. To confirm the execution context, I first ran the id command from inside the debugger.
The output confirmed that the commands were executing as uid=0(root), giving full root-level access on the machine. With confirmed root code execution, I proceeded to read the root flag directly from /root/root.txt.
Successfully reading the contents of root.txt confirmed complete compromise of the Reactor machine and marked the end of the attack chain from vulnerable Next.js application to full root access through the exposed Node.js inspector service.
If you enjoy reading my write-ups, please consider subscribing to my YouTube channel and following me on LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee. Found this walkthrough helpful? Buying me a coffee helps power the late nights spent writing technical walkthroughs and keeping them free for everyone ☕
Keywords:
Reactor HTB Writeup
Reactor HTB Walkthrough
reactor.htb Hack the Box Season 10 Walkthrough
Reactor HackTheBox Season 11 Machine
reactor htb machine season 11 user flag
reactor.htb Season 11 HackTheBox Machine Root Flag
[HTB] Reactor Walkthrough
HTB Reactor Writeup
Reactor | HTB Write Up
helix.htb hackthebox
helix htb walkthrough
helix hack the box writeup
helix hack the box walkthrough
reactor hack the box writeup
reactor hack the box walkthrough
ping.htb
pong.htb
pingpong.htb season 10 Hack the Box machine
pingpong.htb HackTheBox
pingpong Hack the Box Write Up
pingpong Hack the Box Walkthrough
pingpong htb machines
logging HackTheBox
logging hack the box writeup
logging HackTheBox user flag machine HTB Season 10
logging HackTheBox root flag machine HTB Season 10
HackTheBox pingpong machine user flag Season 10
0 Comments