I just solved Enigma from Hack the Box
Enigma Machine Summary
Enigma is an easy difficulty Linux machine on Hack The Box that focuses on misconfigured network services, exposed file shares, mail service enumeration, credential harvesting, and authenticated web application exploitation. The machine demonstrates how seemingly low-risk exposures, including an improperly configured NFS share, onboarding documentation, accessible mail services, and vulnerable web applications, can be chained together to achieve complete system compromise.
The attack chain began with Nmap enumeration, which revealed several exposed services including SSH, HTTP, POP3, IMAP, and NFS. During host configuration, the enigma.htb virtual host was added to the local hosts file after observing the HTTP redirect from the target IP. Initial web enumeration identified a professional Enigma Corp website but no immediately exploitable functionality, prompting further investigation of the remaining exposed services.
Attention then shifted to NFS enumeration, where an exported onboarding share was discovered. After mounting the NFS share, I enumerated its contents and found an onboarding PDF. Through file retrieval and document analysis, the PDF revealed valid employee webmail credentials for Kevin Mitchell together with the internal mail server hostname. After updating the local hosts file with the mail server address through another host configuration step, I performed mail service enumeration and verified the available IMAP services. Further IMAPS enumeration confirmed that the encrypted mail service was operational and accepting secure client connections.
Using the recovered credentials, I successfully performed IMAP authentication and gained access to Kevin's mailbox. I then carried out email enumeration and mailbox enumeration, reviewing every available message and confirming there were no hidden attachments or additional emails. During email analysis, I discovered references to another employee, Sarah, and eventually obtained access to her mailbox, where an internal IT email disclosed administrative credentials for an OpenSTAManager support portal hosted on another virtual host.
Following another host configuration step to resolve the newly discovered virtual host, I accessed the support portal and completed application enumeration, identifying an instance of OpenSTAManager version 2.9.8. Research into publicly available vulnerabilities revealed an authenticated file upload vulnerability affecting this version. During OpenSTAManager exploitation, I adapted a public proof-of-concept into a custom Python exploit that authenticated to the application, uploaded a malicious payload, and successfully achieved remote code execution as the www-data user.
The exploit automated the remaining stages of the attack by leveraging the compromised application to execute commands on the underlying Linux host, escalate privileges through the vulnerable environment, and retrieve both the user and root flags. The machine highlights how information disclosure, exposed infrastructure services, weak credential management, and vulnerable enterprise software can be chained together to progress from initial enumeration to full system compromise with minimal resistance.
Protected Page
Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the Enigma machine and I was assigned an IP address (10.129.20.172).
Nmap Enumeration
I began by performing a comprehensive Nmap scan against the target to identify open ports, running services, service versions, and the underlying operating system. This gave me a clear picture of the attack surface and helped me determine which services were likely to provide an initial foothold.
The scan revealed several interesting services, including SSH, an Nginx web server, POP3/IMAP mail services, and an NFS server exposed through RPC. The web server redirected requests to
enigma.htb, indicating that host configuration would be required before continuing web enumeration. The presence of both mail services and NFS suggested multiple potential attack vectors, making them the primary focus of my next enumeration steps.Host Configuration
After identifying that the web server redirected requests to enigma.htb, I configured my local machine to resolve the hostname correctly. This ensured that all subsequent requests were directed to the intended virtual host instead of accessing the target by IP address.
Once the entry was added to the
/etc/hosts file, I verified that enigma.htb resolved to the target IP. With the hostname configured, I was able to continue web enumeration against the correct virtual host.Web Enumeration
After configuring the hostname, I browsed to the target IP and confirmed that the web server automatically redirected all requests to http://enigma.htb. This validated the virtual host identified during the Nmap scan and confirmed that the application was intended to be accessed through its domain name.
The website presented a professional-looking managed IT services portal with standard informational pages and contact details, but no obvious vulnerabilities were immediately visible. Since the initial attack surface appeared limited, I continued with deeper web enumeration to identify hidden content and additional functionality.
NFS Enumeration
Since the Nmap scan revealed an NFS service, I enumerated its exported shares to determine whether any directories were accessible without authentication. This is a common reconnaissance step, as misconfigured NFS exports can expose sensitive files to unauthenticated users.
The enumeration revealed a single exported share,
/srv/nfs/onboarding, which was accessible to all clients (*). This indicated a potentially insecure NFS configuration and provided a promising target for further investigation by mounting the share and reviewing its contents.NFS Share Mounting
After identifying the exposed NFS export, I created a local mount point and mounted the remote share to inspect its contents. This allowed me to access the files stored on the export as if they were located on my local system.
The mounted share contained a single file named
New_Employee_Access.pdf. Since onboarding documents often contain credentials or internal access information in CTF environments, this immediately became the next artifact I examined.File Retrieval
To simplify my analysis, I copied the PDF from the mounted NFS share into my current working directory. Working with a local copy ensured that I could inspect the document without relying on the mounted share throughout the investigation.
The file was successfully copied, and I verified its presence in my working directory alongside my VPN configuration. With the document available locally, I proceeded to examine its contents for any credentials, onboarding details, or other useful information that could assist in gaining initial access.
Document Analysis
I opened the retrieved PDF on my local machine and reviewed its contents for any sensitive information that could assist with gaining initial access. The document appeared to be an automatically generated onboarding form issued by Enigma Corp's IT department for a newly provisioned employee.
The onboarding document disclosed valid webmail credentials for the employee Kevin Mitchell, including the username
kevin and password Enigma2024!, along with the webmail URL http://mail001.enigma.htb. These credentials provided my first set of authenticated access and became the next target for further enumeration.Host Configuration
The onboarding document referenced the webmail portal at mail001.enigma.htb, so I updated my local hosts file to resolve the hostname to the target IP address. This ensured that I could access the mail service using its intended virtual host.
After adding the entry, the hostname successfully resolved to the target machine. With the mail server configured locally, I was ready to authenticate to the webmail portal using the credentials recovered from the onboarding document.
Mail Service Enumeration
After obtaining valid webmail credentials, I performed a targeted Nmap scan against the IMAP ports to verify the mail services exposed by the target. This helped me confirm which protocols were available before attempting authenticated access.
The scan confirmed that the server was running Dovecot IMAP on both the standard IMAP port (
143) and the encrypted IMAPS port (993). Since secure IMAP was available, I chose to continue interacting with the mail server using the recovered credentials over the encrypted service.IMAPS Enumeration
Before attempting to authenticate, I verified that the encrypted IMAPS service was accessible and inspected its TLS configuration. This allowed me to confirm the server certificate and ensure the mail service was ready to accept secure client connections.
The TLS handshake completed successfully, revealing a self-signed certificate with the common name
enigma and establishing a TLS 1.3 session. After the connection was established, the server presented the Dovecot IMAP banner along with its supported authentication capabilities, confirming that the IMAPS service was operational and ready for authenticated enumeration using the recovered credentials.IMAP Authentication
With valid credentials recovered from the onboarding document, I authenticated to the IMAPS service using curl to verify access to the mailbox. I first listed the available mailboxes before examining the contents of the user's inbox.
The authentication succeeded, confirming that the recovered credentials were valid. The server reported a single message in the
INBOX, indicating that there was mail waiting to be reviewed, making the inbox my next target for further enumeration.Email Enumeration
After confirming that the inbox contained a message, I retrieved it by specifying its UID through the IMAPS service. Reading individual emails often reveals internal information, usernames, or additional attack paths that are useful during post-authentication enumeration.
The email was a welcome message from Sarah in the Accounts department. Although it did not contain additional credentials, it confirmed Sarah's email address (
sarah@enigma.htb) and mentioned that new employee access credentials were distributed through the company's shared drive, providing valuable context for the ongoing investigation.Mailbox Enumeration
To ensure I was not missing any hidden content, I enumerated the mailbox using multiple IMAP retrieval methods. I accessed the message by its mailbox index and also issued FETCH requests to retrieve both the email headers and the complete message body.
Each retrieval method returned the same welcome email from Sarah, confirming that there were no hidden attachments, additional MIME parts, or undiscovered messages. Having fully enumerated Kevin's mailbox, I continued searching for other mailboxes and potential sources of credentials.
Email Analysis
After gaining access to Sarah's mailbox, I reviewed the available emails to identify any internal communications that could reveal additional services or credentials. I retrieved the message directly by its UID to inspect its full contents.
The email from the IT department contained administrative credentials for the company's OpenSTAManager portal hosted at
http://support_001.enigma.htb. In addition to disclosing the URL, it revealed the temporary admin username and password, providing a new authenticated attack path to continue the assessment.Host Configuration
The email from the IT department referenced the OpenSTAManager portal at support_001.enigma.htb, so I updated my local hosts file to resolve the new hostname to the target IP address. This ensured I could access the application using its intended virtual host.
After adding the new entry, the hostname resolved correctly to the target machine. With the virtual host configured, I proceeded to access the OpenSTAManager portal and authenticate using the administrative credentials recovered from Sarah's mailbox.
Application Enumeration
Using the hostname recovered from the internal email, I browsed to support_001.enigma.htb to inspect the newly discovered service. This allowed me to identify the application before attempting to authenticate with the credentials provided by the IT department.
The page presented an OpenSTAManager login portal with fields for a username and password. Since I already possessed valid administrative credentials from Sarah's email, the application became the next target for authenticated enumeration.
Application Authentication
Using the administrative credentials recovered from Sarah's mailbox, I authenticated to the OpenSTAManager portal. The login was successful, confirming that the credentials were valid and granting me access to the application's administrative interface.
After signing in, I was redirected to the
info.php page, which displayed the OpenSTAManager dashboard and application details. With authenticated access established, I began enumerating the application for its version, available modules, and any potential vulnerabilities that could be leveraged further.
OpenSTAManager Exploitation
After identifying the application version as OpenSTAManager 2.9.8, I researched publicly available vulnerabilities affecting this release. My research led me to a public proof-of-concept demonstrating that the application's update mechanism could be abused to upload a malicious ZIP archive, resulting in remote code execution.
I created a Python exploit based on the public proof-of-concept and configured it with the target host, virtual host, and administrative credentials recovered during the earlier enumeration phase. The script automated the exploitation process by authenticating to the application, uploading a malicious payload, obtaining remote code execution, and preparing the environment for the next stages of the attack chain.
Remote Code Execution
After preparing the exploit, I executed it against the target to test whether the vulnerable OpenSTAManager instance could be compromised. The script authenticated with the administrative credentials and automated the exploitation chain from initial access through post-exploitation.
The exploit completed successfully, confirming remote code execution as the
www-data user before leveraging the remaining attack chain to escalate privileges. It automatically retrieved both the user.txt and root.txt flags, demonstrating that the entire exploitation process from authenticated access to full system compromise had been completed successfully.
Keywords:
Enigma HTB Writeup
Enigma HTB Walkthrough
enigma.htb
Enigma - HackTheBox Season 11 Machine Walkthrough
enigma hack the box writeup
enigma hack the box
support_001.enigma.htb
mail001.enigma.htb
kevin:Enigma2024!
I just solved Enigma from Hack the Box!
Enigma machine htb season11 user flag
HackTheBox - Enigma Season 11 htb root flag
Owned Enigma from Hack the Box
Enigma HTB Walkthrough Season 11 HackTheBox machine
Rooted Enigma from Hack the Box
Enigma user flag htb season 11 HackTheBox walkthrough
Enigma machine root flag HTB Season11 Hack the Box
Hack The Box (HTB): Enigma Machine (Full Walkthrough)
Pwned Enigma from Hack the Box
0 Comments