LoginHack The Box: Haze Machine Walkthrough – Hard Difficulty
Introduction to Haze
In this write-up, we’ll go step-by-step through the Haze machine from Hack The Box, rated medium difficulty. The box involves exploring a Windows Active Directory (AD) environment with Splunk services. The path includes abusing a Splunk vulnerability, moving through Active Directory, and escalating privileges to grab both the user and root flags.
Objective
The goal is to complete Haze by achieving the following:
User Flag:
Using the decrypted paul.taylor password (Ld@p_Auth_Sp1unk@2k24) from splunksecrets, I gained WinRM access as mark.adams. After enumerating AD with netexec and retrieving the Haze-IT-Backup gMSA NTLM hash, I used PyWhisker and Certipy for a Shadow Credentials attack on edward.martin. This provided edward.martin’s NT hash, enabling WinRM access to read the user flag with type user.txt. Troubleshooting BloodyAD authentication issues was key to progressing through AD exploitation.
Root Flag:
With Splunk admin credentials from a decrypted backup hash, I uploaded a malicious .tar.gz app containing a reverse shell to Splunk’s web interface (port 8000). The shell, caught via nc -lvnp 4444, had SeImpersonatePrivilege. Using SweetPotato, I escalated to NT SYSTEM and read the root flag with type root.txt. Fixing tar file upload errors ensured successful shell delivery.
Enumerating the Haze Machine
Reconnaissance
We begin with a basic Nmap scan to identify services on the machine:
nmap -sC -sV 10.10.11.61 -oA initial
Nmap Output Highlights:
┌─[dark@parrot]─[~/Documents/htb/haze]
└──╼ $nmap -sC -sV 10.10.11.61 -oA initial
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-06-21 03:39 EDT
Nmap scan report for haze.htb (10.10.11.61)
Host is up (0.037s latency).
Not shown: 986 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-06-21 12:16:18Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after: 2026-03-05T07:12:20
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after: 2026-03-05T07:12:20
|_ssl-date: TLS randomness does not represent time3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after: 2026-03-05T07:12:20
8000/tcp open http Splunkd httpd
| http-robots.txt: 1 disallowed entry
|_/
|_http-server-header: Splunkd
| http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_Requested resource was http://haze.htb:8000/en-US/account/login?return_to=%2Fen-US%2F
8088/tcp open ssl/http Splunkd httpd
|_http-title: 404 Not Found
8089/tcp open ssl/http Splunkd httpd
|_http-title: splunkd
| http-robots.txt: 1 disallowed entry
|_/
| ssl-cert: Subject: commonName=SplunkServerDefaultCert/organizationName=SplunkUser
| Not valid before: 2025-03-05T07:29:08
|_Not valid after: 2028-03-04T07:29:08
|_http-server-header: Splunkd
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 57.13 secondsAnalysis:
- 53/tcp – DNS (Simple DNS Plus) for internal name resolution.
- 88/tcp – Kerberos authentication (typical for AD environments).
- 135/tcp – MS RPC endpoint mapper (useful for enumeration).
- 139/tcp – NetBIOS session service (Windows file/printer sharing).
- 389/tcp – LDAP (Active Directory query in plaintext).
- 445/tcp – SMB service (file sharing, potential attack vector).
- 464/tcp – Kerberos password change service (kpasswd).
- 593/tcp – RPC over HTTP (potential for Active Directory related enumeration).
- 636/tcp – LDAPS (LDAP over SSL/TLS).
- 3268/tcp – Global Catalogue LDAP (multi-domain AD query).
- 3269/tcp – Global Catalogue LDAPS (LDAP over SSL/TLS).
- 8000/tcp – Splunk Web Interface (Splunkd httpd), web login portal exposed.
- 8088/tcp – Splunk HTTP Event Collector (SSL).
- 8089/tcp – Splunk management port (SSL), often used for Splunk API and administration.
Web Enumeration
Navigated to http://haze.htb:8000, which presented a Splunk Enterprise login page, indicating a web-based attack surface.
Visited http://haze.htb:8088, which returned a 404 error, suggesting no exploitable content.
Accessed http://haze.htb:8089, revealing a Splunk Atom feed that leaked the version (9.2.1), critical for identifying vulnerabilities.
Searched for Splunk 9.2.1 exploits, finding CVE-2024-36991, a local file inclusion (LFI) vulnerability allowing unauthorised file access:
The Splunk 9.2.1 authentication.conf documentation explains how Splunk manages user authentication. It defines how credentials are stored, including LDAP bindings, and supports integrating with external authentication systems. Misconfigurations here can expose sensitive data—like encrypted passwords and bindDNs—making it a critical target for exploitation during assessments
Understanding CVE-2024-36991: A Simple Explanation
Think of your computer or phone as a house with many doors and windows. Each one is a way to interact with the device. Now, imagine one of the locks isn’t working properly—it looks secure, but a clever intruder could still get in.
CVE-2024-36991 is like that broken lock, but in software. It’s a hidden flaw that, if found by the wrong person, could let them sneak into the system without permission. They might steal data, cause damage, or disrupt how things work.
The good news is that once these flaws are discovered, the developers usually fix them quickly, like calling a locksmith to repair a faulty lock. That’s why it’s so important to keep your apps and devices updated. Updates are your best defence against these types of security issues.
Leveraging CVE-2024-36991 for Exploitation
Downloaded the CVE-2024-36991 PoC to test the LFI vulnerability
I downloaded the publicly available proof-of-concept (PoC) and tested it using curl to retrieve sensitive configuration files, such as authentication.conf
The exploit was successful and allowed access to /etc/passwd, dumping several user password hashes
bindDN = CN=Paul Taylor,CN=Users,DC=haze,DC=htb
bindDNpassword = $7$ndnYiCPhf4lQgPhPu7Yz1pvGm66Nk0PpYcLN+qt1qyojg4QU+hKteemWQGUuTKDVlWbO8pY=Although hashcat didn’t crack the hashes within a 5-minute test, the PoC also revealed an encrypted bindDNpassword used in Splunk’s LDAP integration:
Knowing that Splunk stores a symmetric key in splunk.secret, I used the same LFI to retrieve that key. With both the encrypted password and the key, I used the splunksecrets tool to attempt decryption.
Unlocking Splunk Credentials via splunksecrets
Installed Splunksecrets to decrypt the hash
Fixing Cryptography Module Reference in SplunkSecrets
Diagnosis:
- Using Python 3.12, as per the traceback.
- The cryptography.hazmat.decrepit module was deprecated in newer cryptography versions.
- Ran pip show cryptography—found a version >36.0.0, where decrepit was removed.
- Tested import: python3 -c “from cryptography.hazmat.decrepit.ciphers.algorithms import ARC4” confirmed the error.
Downgraded cryptography to a compatible version
I’m currently facing a fairly common issue—it’s related to how a Python package references the cryptography library. In this case, the splunksecrets package is trying to import a module from cryptography.hazmat.decrepit, which doesn’t exist. The correct path should be cryptography.hazmat.primitives.
To fix this, I’ll need to manually edit the file located at:
/home/dark/.local/lib/python3.12/site-packages/splunksecrets/splunk.pyOn line 6, the import statement needs to be corrected.
Current line:
from cryptography.hazmat.decrepit.ciphers.algorithms import ARC4Updated line:
from cryptography.hazmat.primitives.ciphers.algorithms import ARC4Once that’s updated, it should resolve the issue.
The splunksecrets tool offers various commands to encrypt and decrypt passwords related to Splunk and its components. It supports decrypting and encrypting credentials used for database connections (dbconnect), as well as passwords associated with Phantom assets. The tool also provides functionality to handle passwords encrypted with both current and legacy Splunk algorithms. Additionally, it can generate password hashes compatible with Splunk’s authentication system. This versatility makes splunksecrets a useful utility for recovering sensitive information during security assessments involving Splunk environments.
I decrypted the encrypted LDAP password by running the splunksecrets tool with the Splunk secret file and the captured ciphertext. This process successfully revealed the plaintext password for the user paul.taylor as Ld@p_Auth_Sp1unk@2k24, which can be used for LDAP authentication or further privilege escalation.
Enumerate using the netexec command
Tested credentials on SMB and LDAP
Attempted WinRM access with paul.taylor, but it failed
Enumerated AD users to find other accounts
Manually extracting the username is tedious, so the screenshot above shows a quicker way I used to identify it.
Discovered mark.adams and tested the same password, gaining WinRM access
Successfully connected to the machine via evil-winrm.
Enumerating AD for Privilege Escalation
The easiest way to understand mark.adams’s connections are by using BloodHound
The user mark.adams is a member of the gMSA Administrators group, granting access to retrieve and decrypt managed service account passwords from Active Directory. This privilege enables direct access to sensitive credentials (msDS-ManagedPassword), allowing privilege escalation or impersonation. It also opens paths for advanced attacks like NTLM relay or the Golden gMSA attack, which can provide persistent, stealthy access across the domain.
The details above display the properties of mark.adam.
I used a tool to connect to the target computer using the username “mark.adams” and the password I found. This confirmed that the credentials were correct and allowed me to access the system, which is running a recent version of Windows Server. The connection used standard network services to communicate securely with the target.
Bloodhound enumeration
The command executes BloodHound-python to collect Active Directory data using the machine account Haze-IT-Backup$. Instead of using a password, it authenticates with an NTLM hash (735c02c6b2dc54c3c8c6891f55279ebc)—a common technique during post-exploitation. The domain is specified as haze.htb, and the domain controller being queried is dc01.haze.htb, with the nameserver IP 10.10.11.61. The -c all flag instructs BloodHound to perform a full collection of all supported data types (such as sessions, ACLs, group memberships, etc.), and --zip compresses the output into a ZIP archive for easier ingestion into the BloodHound UI.
The machine account haze-it-backup$@haze.htb is a member of both support_services@haze.htb and Domain Computers@haze.htb groups. Membership in the Domain Computers group is standard for all domain-joined machines and typically grants basic permissions within the domain. However, its inclusion in the support services group may indicate elevated privileges or specific access rights related to IT support operations. This group membership may present an opportunity for privilege escalation, particularly if the support_services group has delegated permissions over high-value domain objects or privileged user accounts.
Attempted to retrieve gMSA NTLM hash, initially blank
I imported the Active Directory module and set the variable $gMSAName to “Haze-IT-Backup” and $principal to “mark.adams”. Then, I configured the managed service account so that the user mark.adams is authorised to retrieve the managed password.
You can also perform the same action using a one-liner command
We obtained the NTLM hash, but keep in mind that each user has a unique NTLM hash, so everyone will get a different one.
As shown by the results, the LDAP permissions now exceed regular permissions, allowing you to easily collect Domain Objects and DACLs, making enumeration straightforward for the user mark.adams.
BloodyAD and Pywhisker enumeration
An attempt to use BloodyAD for further exploitation failed due to invalid credentials, preventing successful authentication.
I had to rack my brain to figure out the issue, but after removing the $ from the Haze-IT-Backup username and running the ntpdate command, everything worked smoothly.
I also executed the BloodyAD commands displayed earlier to assign permissions and add group memberships to the Haze-IT-Backup account.
These commands attempt to escalate privileges by granting the Haze-IT-Backup account full control (genericAll) over the SUPPORT_SERVICES group and adding the service account as a member of that group.
I also ran a series of PyWhisker commands to manage permissions for the user edward.martin using the Haze-IT-Backup$ account:
pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "list"The initial listing showed that the msDS-KeyCredentialLink attribute was empty or inaccessible.
pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "add"This generated a certificate and key, updated the msDS-KeyCredentialLink attribute for edward.martin, and saved a PFX certificate file protected by a password. This certificate can be used to obtain a Ticket Granting Ticket (TGT) with external tools.
pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "list"This showed the new DeviceID and its creation timestamp.
#!/bin/bash
# Variables - replace with actual values
IP="10.10.11.61"
DOMAIN="haze.htb"
USER="Haze-IT-Backup$"
PASSWORD=":YOUR_PASSWORD_HERE"
TARGET_USER="edward.martin"
HASH="" # Set this at runtime or before running commands
# Change owner of SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 set owner 'SUPPORT_SERVICES' "$USER"
# Grant GenericAll permission to SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 add genericAll "SUPPORT_SERVICES" "$USER"
# Add user as member of SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 add groupMember 'SUPPORT_SERVICES' "$USER"
# Prompt user to enter the hash at runtime if empty
if [ -z "$HASH" ]; then
read -p "Enter the NTLM hash: " HASH
fi
# List KeyCredentialLink attribute for target user
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "list"
# Add KeyCredential to target user
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "add"
# Confirm KeyCredentialLink attribute update
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "list"I utilised an existing script to automate the execution of all the necessary commands, streamlining the process and ensuring accuracy during exploitation.
I used impacket-getTGT to request a Kerberos Ticket Granting Ticket (TGT) for the Haze-IT-Backup$ account on the haze.htb domain, authenticating with the NTLM hash instead of a plaintext password. After successfully obtaining the ticket, I set the KRB5CCNAME environment variable to point to the ticket cache file, allowing subsequent Kerberos-authenticated actions to use this ticket.
Gaining Access as edward.martin
The image reveals that Haze-IT-Backup$ can modify the Owner attribute of the SUPPORT_SERVICES object. Notably, SUPPORT_SERVICES holds the privilege to issue certificates on behalf of the EDWARD account. This chain of permissions enables a classic Shadow Credentials attack. To exploit this path, the first step is to leverage the DACL misconfiguration on SUPPORT_SERVICES to gain control over the object and escalate privileges accordingly.
I used Certipy to perform an automated Shadow Credentials attack targeting the user edward.martin. By authenticating Haze-IT-Backup$ with the NTLM hash, Certipy generated and added a temporary Key Credential (certificate) to edward.martin’s account. This allowed the tool to authenticate edward.martin using the certificate and obtain a Ticket Granting Ticket (TGT). After successfully retrieving the TGT and saving it to a credential cache file, Certipy reverted the Key Credential changes to avoid detection. Finally, the tool extracted the NT hash for edward.martin, which can be used for further attacks or lateral movement.
I used evil-winrm to connect to the target machine as edward.martin, authenticating with the NT hash I had previously extracted. This granted me an interactive WinRM session with the privileges of edward.martin, allowing direct access to the system for further enumeration or exploitation.
We can read the user flag by simply running the command type user.txt inside the WinRM session.
Escalate the Root Privileges Access
Privileges Access
While exploring the system, I navigated to C:\Backups\Splunk and found a backup file named splunk_backup_2024-08-06.zip. I downloaded the file for offline analysis using the download command in Evil-WinRM.
Analyse the Splunk_backup file
After downloading splunk_backup_2024-08-06.zip, I extracted its contents locally to analyse the files inside.
It appeared to be a standard Splunk directory structure.
It turned out that Splunk had created a copy of the active configuration file, which contained the hash above
An error occurred while attempting to use splunksecrets.
By running splunksecrets splunk-decrypt -S etc/auth/splunk.secret, I was able to decrypt the ciphertext
There was no user account associated with this password, resulting in a STATUS_LOGON_FAILURE During login attempts.
Uploading a malicious zip file to get a shell
I tested this password by logging into the previously discovered website.
The login attempt was successful, confirming the password’s validity.
This means accessing and reviewing the part of the system where applications or services are controlled and configured. It involves looking at how apps are set up, what permissions they have, and possibly making changes to their settings.
Before proceeding, I conducted research to understand how to leverage the admin access effectively.
I then proceeded to use a reverse shell tool from this repository to gain remote shell access on the Splunk system.
I downloaded the reverse shell tool repository directly onto the target machine to prepare for the next steps.
The content matches the example shown above.
I added the reverse shell command to the appropriate script file.
The attempt to create (zip) the archive file failed.
I started a listener on my machine to catch the incoming reverse shell connection.
An attempt to upload the tar file through the app’s interface resulted in an error stating that the application does not exist.
I modified the reverse shell command to address the issues encountered.
This time, the zip file was created successfully without any issues.
The file was successfully uploaded to the application.
I successfully received the reverse shell connection from the target.
Exploiting SeImpersonatePrivilege with SweetPotato
The current user has the SeImpersonatePrivilege permission enabled, as shown above. This privilege is commonly exploited using tools like Juicy Potato to escalate to NT SYSTEM.
Privilege Escalation to Alexander Green
The user alexander.green@haze.htb is a member of multiple Active Directory groups, including splunk_admins@haze.htb, Domain Users@haze.htb, and users@haze.htb. The splunk_admins group likely grants administrative privileges over the Splunk environment, which could provide access to sensitive logs, configurations, or even execution capabilities within Splunk. Additionally, being part of the Domain Users group confirms that the account is a standard domain-joined user. The users group, which includes Domain Users as members, may be used to manage or apply policies to a broader set of accounts. This nested group membership structure could potentially be leveraged to escalate privileges or pivot further within the domain, depending on the permissions assigned to each group.
I downloaded the SweetPotato binary to the target machine to leverage the SeImpersonatePrivilege for privilege escalation.
I tested SweetPotato by running it with the whoami command, confirming that privilege escalation to NT SYSTEM was successful.
Using this privilege escalation method, I gained NT SYSTEM access and was able to read the root flag.
The post Hack The Box: Haze Machine Walkthrough – Hard Difficulty appeared first on Threatninja.net.
