❌

Reading view

There are new articles available, click to refresh the page.

Hack The Box: Mirage Machine Walkthrough – Hard Difficulity

By: darknite
Reading Time: 13 minutes

Introduction to Mirage:

In this writeup, we will explore the β€œMirage” machine from Hack The Box, categorized 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 β€œMirage” machine from Hack The Box by achieving the following objectives:

User Flag:

We kicked off with NFS, SMB, and Kerberos enumeration, mounted the open MirageReports share, and grabbed two internal PDFs. One revealed the missing hostname nats-svc.mirage.htb. We hijacked DNS with DNSadder.py, funneled all NATS traffic through our proxy, and snatched JetStream auth_logs messages β€” yielding valid credentials for david.jjackson. After syncing our clock with the DC, we scored a TGT, fired up Evil-WinRM, and landed on the domain controller as david.jjackson to claim the user flag.

Root Flag:

We started with david.jjackson’s ticket, and then kerberoasted nathan.aadam. After cracking his password, we gained his shell and subsequently discovered mark.bbond’s credentials. From there, we also retrieved the Mirage-Service$ managed password. With these pieces, we used Certipy to forge a DC01$ certificate, and as a result, we configured RBCD so mark.bbond could impersonate the domain controller. Once that was in place, we executed DCSync to dump all domain hashes, including Administrator. Finally, we obtained an Admin TGT and used Evil‑WinRM to open a shell as Administrator, which ultimately allowed us to claim the root flag.

Enumerating the Mirage 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.78 

Nmap Output:

β”Œβ”€[dark@parrot]─[~/Documents/htb/mirage]
└──╼ $nmap -sC -sV -oA initial 10.10.11.78 
Nmap scan report for 10.10.11.78
Host is up (0.15s latency).
Not shown: 987 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-11-20 20:52:31Z)
111/tcp  open  rpcbind       2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/tcp6  rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  2,3,4        111/udp6  rpcbind
|   100003  2,3         2049/udp   nfs
|   100003  2,3         2049/udp6  nfs
|   100003  2,3,4       2049/tcp   nfs
|   100003  2,3,4       2049/tcp6  nfs
|   100005  1,2,3       2049/tcp   mountd
|   100005  1,2,3       2049/tcp6  mountd
|   100005  1,2,3       2049/udp   mountd
|   100005  1,2,3       2049/udp6  mountd
|   100021  1,2,3,4     2049/tcp   nlockmgr
|   100021  1,2,3,4     2049/tcp6  nlockmgr
|   100021  1,2,3,4     2049/udp   nlockmgr
|   100021  1,2,3,4     2049/udp6  nlockmgr
|   100024  1           2049/tcp   status
|   100024  1           2049/tcp6  status
|   100024  1           2049/udp   status
|_  100024  1           2049/udp6  status
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: mirage.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
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: mirage.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
|_ssl-date: TLS randomness does not represent time
2049/tcp open  nlockmgr      1-4 (RPC #100021)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
|_ssl-date: TLS randomness does not represent time
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: -22m05s
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-11-20T20:53:32
|_  start_date: N/A

Analysis:

  • Port 53 (DNS) – Provides internal domain resolution. Useful for discovering hostnames and performing zone transfers if misconfigured.
  • β€’ Port 88 (Kerberos) – Active Directory authentication endpoint. Key for attacks like Kerberoasting or AS‑REP roasting.
  • β€’ Ports 111 & 2049 (NFS) – NFS running on a Windows DC is unusual. Could allow unauthenticated mounts or expose readable files.
  • β€’ Ports 135 / 139 / 445 (MSRPC / SMB) – Standard Windows services. SMB signing is enforced, which prevents NTLM relay attacks.
  • β€’ Ports 389 / 636 / 3268 / 3269 (LDAP / Global Catalog) – Full AD environment. LDAP enumeration is possible if permissions are misconfigured.
  • β€’ Port 464 (kpasswd) – Kerberos password change service. Can provide insights for password‑spray attempts.
  • β€’ Port 593 (RPC over HTTP) – RPC over HTTP interface. Typically used for Outlook Anywhere or AD RPC proxying.

Server Enumeration:

Perform web enumeration to discover potentially exploitable directories and files.

We scanned SMB and saw the service up, but mirage.htb blocked all NTLM logins (even dark:dark failed with STATUS_NOT_SUPPORTED). Kerberos only from now on.

We added the domain/realm to /etc/krb5.conf and used -k flags everywhere β€” no more passwords over the wire.

NFS Share Enumeration and Mounting Process on Mirage machine

The showmount -e mirage.htb command reveals that the target is exporting an NFS share named /MirageReports, and it is accessible to everyone. This means the share does not enforce host-based restrictions, allowing any machine to mount it. Since the export is world-accessible, it’s likely a good entry point for enumeration, as you can mount the share locally and inspect its contents for sensitive files, misconfigurations, or clues leading to further access.

The mount attempt failed because the local path /mnt/mirage doesn’t exist on our machine. NFS requires a valid directory to mount a remote share, so before accessing the exported /MirageReports share, we need to create a local mount point.

Creating the directory with mkdir -p /mnt/mirage resolves the issue, allowing us to mount the share and begin enumerating its contents.

The β€œfailed to apply fstab options” error usually comes from stale mount settings or syntax issues. Just rerun the command cleanly or add -o vers=3,nolock – it fixes the problem in HTB.

We corrected the syntax (added -o vers=3,nolock when needed) and re-ran mount -t nfs mirage.htb:/MirageReports /mnt/mirage. The share mounted perfectly and gave us full access to the internal reports.

After mounting the NFS share, ls reveals two PDFs: Incident_Report_Missing_DNS_Record_nats-svc.pdf and Mirage_Authentication_Hardening_Report.pdf. These internal reports likely expose misconfigurations and are key for further enumeration.

This command copies all files from the mounted NFS share at /mnt/mirage into your current working directory using elevated privileges. It allows you to analyze the documents locally without needing to stay connected to the NFS share.

Discovery and Analysis of Internal Reports

After copying, the files should now be available in your current working directory for further analysis.

Reviewing the Incident_Report_Missing_DNS_Record_nats-svc.pdf file revealed an additional hostname: nats-svc.mirage.htb.

Exploiting Missing DNS Entry for NATS Interception on Mirage Machine

The Incident Report showed nats-svc.mirage.htb missing from DNS β†’ internal clients failed to resolve it. We fired up DNSadder.py, added a fake record to our proxy, and hijacked all NATS traffic β†’ full MITM on auth and JetStream (including auth_logs).

Enumerating and Interacting With NATS JetStream

NATS is a messaging system that helps different parts of a company’s software talk to each other. Instead of applications connecting directly, they send messages through NATS, which delivers them quickly and reliably.

To install the NATS command‑line interface on Parrot OS, you can use the Go toolchain included in the system. Simply run the command go install github.com/nats-io/natscli/nats@latest, which downloads and compiles the latest version of the NATS CLI and places it in your Go binaries directory for use.

To verify that the NATS CLI installed correctly, simply run the nats command in your terminal. If the installation was successful, it should display the available subcommands and usage information, confirming that the tool is ready to use.

Checking the auth_logs Stream

nats stream info auth_logs showed a small stream (max 100 messages) on subject logs.auth that currently held 5 messages β€” perfect for grabbing credentials.

Creating a Pull Consumer

We created a pull consumer named whare1 on the auth_logs stream using Dev_Account_A credentials. It fetches messages one-by-one with explicit acknowledgment, allowing us to retrieve all five stored authentication logs.

Grabbing the Credentials

We fetched the five messages from the auth_logs stream using our whare1 consumer. Every message (subject logs.auth) contained the same authentication event:

  • Username: david.jjackson
  • Password: pN8kQmn6b86!1234@
  • Source IP: 10.10.10.20

All messages were acknowledged and consumed successfully, confirming we now have valid domain credentials.

Extracting Credentials and Kerberos Ticket Operations

The leaked david.jjackson:pN8kQmn6b86!1234@ credentials let us request a Kerberos TGT with impacket-getTGT. The first try failed due to clock skew; after sudo ntpdate -s 10.10.11.78, the second attempt succeeded and saved david.jjackson.ccache

Initial Foothold – david.jjackson Access on Mirage Machine

After syncing time with sudo ntpdate -s 10.10.11.78, the second impacket-getTGT run succeeded and gave us a valid TGT.

This command sets the KRB5CCNAME environment variable to use the david.jjackson.ccache file as the active Kerberos ticket. It tells all Kerberos‑aware tools to use this ticket automatically for authentication instead of a password.

Try running the command again if it doesn’t work on the first attempt.

Lateral Movement Using Cracked SPN Credentials

With david.jjackson’s ticket, we ran impacket-GetUserSPNs -k -no-pass and discovered a crackable Kerberos service ticket ($krb5tgs$23$) for the SPN HTTP/exchange.mirage.htb, belonging to the high-privileged user nathan.aadam (member of Exchange_Admins group).

Cracking the TGS β†’ Password: 3edc#EDC3

We cracked the TGS hash using John and the RockYou wordlist, recovering the password 3edc#EDC3 for nathan.aadam β€” a weak credential that immediately granted us access to this Exchange Admins group member.

BloodHound Collection and Domain Enumeration on Mirage machine

As nathan.aadam, we ran BloodHound and dumped the entire Active Directory structure for privilege escalation path hunting.

Mark.bbond is a member of the IT Support group, and he has the ForceChangePassword privilege over the user javier.mmarshall.

Javier.mmarshall has ReadGMSAPassword permission on the account Mirage-Service$.

nxc smb dc01.mirage.htb with nathan.aadam initially failed due to clock skew (krb_ap_err_skew). After syncing time again (ntpdate -s 10.10.11.78), authentication succeeded cleanly.

Same clock skew issue hit nxc smb. After ntpdate -s 10.10.11.78, it worked instantly and confirmed valid access as nathan.aadam : 3edc#EDC3 on the DC.

We used the cracked password 3edc#EDC3 to obtain a Kerberos TGT for nathan.aadam (impacket-getTGT). The ticket was saved as nathan.aadam.ccache, giving us full Kerberos access for the next steps

Accessing the DC as nathan.aadam

Connected instantly as nathan.aadam β†’ full PowerShell access on the Domain Controller.

Grabbing the User Flag

We can read the user flag by typing the β€œtype user.txt” command

Escalate to Root Privileges Access on Mirage Machine

Privilege Escalation Attempts and LogonHours Analysis

A screen shot of a computer

AI-generated content may be incorrect.

We checked AD LogonHours. javier.mmarshall had all zeroes β†’ account completely locked out (can’t log in anytime). This hinted the account was disabled but still present for potential abuse.

A screen shot of a computer

AI-generated content may be incorrect.

No default password was detected.

You can transfer the WinPEAS executable to the compromised host by running the upload command inside your Evil‑WinRM session. This pushes the file from your attack machine directly into the victim’s system, allowing you to execute it afterwards for privilege‑escalation enumeration.

No usable credentials were identified.

This command verifies SMB access on dc01.mirage.htb using Kerberos authentication with the mark.bbond credentials. The scan shows the host details and confirms a successful login, indicating that the provided password is valid and SMB authentication for this account works correctly.

The command requests a Kerberos TGT for the user MARK.BBOND using the discovered password 1day@atime. By specifying the domain controller IP, the tool authenticates against the DC and generates a valid ticket. Once successful, the resulting Kerberos ticket is saved locally as MARK.BBOND.ccache for use in later Kerberos‑based operations.

Password Resets, Kerberos Tickets, and Service Account Abuse

A password reset for the account javier.mmarshall was performed using bloodyAD. By authenticating as mark.bbond with Kerberos (-k) and supplying valid domain credentials, the command successfully updated the user’s password to p@ssw0rd123, confirming the operation completed without issues.

Attempting to obtain a TGT for the account javier.mmarshall with impacket-getTGT results in a KDC_ERR_CLIENT_REVOKED error. This indicates the credentials are no longer valid because the account has been disabled or otherwise revoked in Active Directory, preventing any Kerberos authentication from succeeding.

Enabling javier.mmarshall (disabled account)

By running the command shown above, the password update completed successfully.

A screenshot of a computer screen

AI-generated content may be incorrect.

As mark.bbond, we used BloodyAD to read the msDS-ManagedPassword attribute of the Mirage-Service$ managed service account and instantly retrieved its current plaintext password + NTLM hash.

We used Impacket to request a Kerberos TGT for Mirage-Service$ with its leaked NTLM hash (pass-the-hash). This gave us a valid ticket without ever needing the plaintext password.

We asked the domain CA for a certificate using mark.bbond (now pretending to be dc01$). The CA accepted it and gave us a shiny dc01.pfx file that lets us log in as the real domain controller machine account.

After exporting the Kerberos ticket with export KRB5CCNAME=mark.bbond.ccache, a certificate request is made using Certipy


We requested a certificate for mark.bbond (UPN = dc01$@mirage.htb). The CA issued it without issues β†’ dc01.pfx ready for authentication as the DC machine account.

We cleaned up by resetting mark.bbond’s UPN back to mark.bbond@mirage.htb with Certipy – leaving no obvious traces.

Certificate Abuse and Resource-Based Constrained Delegation (RBCD)

With the dc01.pfx certificate, Certipy authenticated us over LDAPS as MIRAGE\DC01$ – we now had full LDAP control as the domain controller itself.

We used Certipy to grant mark.bbond Resource-Based Constrained Delegation over DC01$ – now mark.bbond can impersonate anyone (including Administrator) to the domain controller.

As mark.bbond, we ran impacket-getST to impersonate DC01$ and request a CIFS ticket for the real DC. Delegation succeeded β†’ valid ticket saved.

The Kerberos ticket was set as the active credential cache by exporting it to the KRB5CCNAME environment variable:

export KRB5CCNAME=DC01$@<a>CIFS_dc01.mirage.htb@MIRAGE.HTB.ccache</a>

With the delegated CIFS ticket, we executed impacket-secretdump -k dc01.mirage.htb and successfully dumped the entire NTDS.DIT β€” every user and machine hash, including Administrator’s, was now ours.

The impacket-getTGT command was executed using the Administrator NTLM hash to request a Kerberos TGT from the Mirage domain controller. The request completed successfully, and the resulting ticket was saved locally as Administrator.ccache.

The evil-winrm command was used to connect to dc01.mirage.htb with Kerberos authentication. Evil‑WinRM initialized successfully, displaying standard warnings about Ruby’s path‑completion limitations and noting that the provided username is unnecessary when a Kerberos ticket is already available. The session then proceeded to establish a connection with the remote host.

We can read the root flag by typing the β€œtype root.txt” command

The post Hack The Box: Mirage Machine Walkthrough – Hard Difficulity appeared first on Threatninja.net.

Hack The Box: RustyKey Machine Walkthrough – Hard Difficulity

By: darknite
Reading Time: 11 minutes

Introduction to RustyKey:

In this writeup, we will explore the β€œRustyKey” machine from Hack The Box, categorized as an 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 β€œRustyKey” machine from Hack The Box by achieving the following objectives:

User Flag:

Authenticated to the domain as bb.morgan (password P@ssw0rd123) after exploiting Kerberos flows and time sync. You obtained a Kerberos TGT (bb.morgan.ccache), exported it via KRB5CCNAME, and used evil‑winrm to open an interactive shell on dc.rustykey.htb.

Root Flag:

Escalation to SYSTEM was achieved by abusing machine and delegation privileges. Using the IT‑COMPUTER3$ machine account you modified AD protections and reset ee.reed’s password, then performed S4U2Self/S4U2Proxy to impersonate backupadmin and saved backupadmin.ccache. With that ticket, you used Impacket to upload and run a service payload and spawned a SYSTEM shell.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV 10.10.11.75 -oA initial

Nmap Output:

PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-06-29 13:48:41Z)
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: rustykey.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: rustykey.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped

Analysis:

  • 53/tcp (DNS – Simple DNS Plus): DNS service is running, likely handling domain name resolution for the internal Active Directory environment.
  • 88/tcp (Kerberos-sec): Kerberos authentication service for Active Directory domain rustykey.htb0. Useful for ticket-based authentication attacks such as AS-REP roasting or Kerberoasting.
  • 135/tcp (MSRPC): Microsoft RPC endpoint mapper. Commonly used for remote management and DCOM-based communication.
  • 139/tcp (NetBIOS-SSN): NetBIOS session service β€” supports SMB over NetBIOS; can reveal shares or host information.
  • 389/tcp (LDAP): Lightweight Directory Access Protocol for Active Directory. Likely allows domain information queries; potential for anonymous LDAP enumeration.
  • 445/tcp (Microsoft-DS): SMB over TCP for file sharing and remote service operations; often used for lateral movement or enumeration (e.g., SMB shares, users, policies).
  • 464/tcp (kpasswd5): Kerberos password change service; might be used for password reset operations.
  • 593/tcp (ncacn_http): Microsoft RPC over HTTP β€” commonly used for Outlook Anywhere and DCOM-based communication.
  • 636/tcp (LDAPS): LDAP over SSL/TLS; encrypted directory service communications.
  • 3268/tcp (Global Catalog – LDAP): LDAP global catalog port for multi-domain queries in Active Directory.
  • 3269/tcp (Global Catalog over SSL): Secure LDAP global catalog service.

Server Enumeration:

Before starting, we need to specify the correct Kerberos realm by creating a krb5.conf file in /etc/krb5.conf and adding the following content above

NXC enumeration

The scans show an Active Directory host (dc.rustykey.htb) with SMB and LDAP/kerberos services; SMB on 10.10.11.75 negotiated x64, signing required, and SMBv1 disabled, while an SMB auth attempt for rr.parker returned STATUS_NOT_SUPPORTED β€” indicating the server rejected the authentication method the client used rather than definitively proving the password is wrong. The LDAP attempt shows KDC_ERR_WRONG_REALM for rustykey.htb\rr.parker, meaning the Kerberos realm in use didn’t match the domain. Likely causes include incorrect credentials, an auth-method mismatch (NTLM vs Kerberos or wrong NTLM dialect), enforced SMB signing, wrong/unspecified Kerberos realm, account restrictions (disabled/locked/password change required), or tool/quoting issues from special characters. Triage by retrying with a domain-qualified username (RUSTYKEY\rr.parker or rr.parker@RUSTYKEY), testing with alternate SMB clients (crackmapexec, smbclient, Impacket), forcing NTLM if needed, validating Kerberos realm and obtaining a TGT, performing LDAP or rpc enumeration to confirm account status, and escaping or simplifying the password to rule out encoding problems.

This time, the error returned is KRB_AP_ERR_SKEW, indicating a time synchronization issue between the client and the server.

Using nxc with Kerberos authentication (-k) and domain rustykey.htb, the SMB service on dc.rustykey.htb was successfully accessed with the credentials rr.parker:8#t5HE8L!W3A. The enumeration revealed an x64 domain controller with SMB signing enabled and SMBv1 disabled. The command listed 11 local users, including Administrator, Guest, krbtgt, rr.parker, mm.turner, bb.morgan, gg.anderson, dd.ali, ee.reed, nn.marcos, and backupadmin, along with their last password set dates and account descriptions. This confirms that rr.parker’s credentials are valid and have sufficient access to query user accounts over SMB. The successful Kerberos-based login also verifies proper realm configuration and time synchronization, allowing secure enumeration of domain users.

Using Kerberos authentication (-k) with the domain rustykey.htb, LDAP enumeration on dc.rustykey.htb successfully authenticated as rr.parker:8#t5HE8L!W3A. The scan enumerated 11 domain users, showing usernames, last password set dates, and account descriptions. Accounts include Administrator, Guest, krbtgt, rr.parker, mm.turner, bb.morgan, gg.anderson, dd.ali, ee.reed, nn.marcos, and backupadmin. This confirms rr.parker’s credentials are valid and have permission to query domain user information over LDAP. The domain controller responded correctly to Kerberos authentication, indicating proper realm configuration and time synchronization.

Impacket successfully requested a TGT from DC 10.10.11.75 for rustykey.htb/rr.parker and saved the Kerberos ticket to rr.parker.ccache.

ChatGPT said:

Set the Kerberos credential cache by exporting KRB5CCNAME=rr.parker.ccache so Kerberos-aware tools use the saved TGT for authentication.

This directs commands like klist, curl –negotiate, and Impacket utilities to the specified ccache.

Bloodhound enumeration

The DNS timeout indicates that the BloodHound collector couldn’t resolve SRV records or reach the domain controller’s DNS. This often happens due to incorrect DNS settings on your Parrot OS machine, firewall restrictions, or reliance on SRV lookups instead of a direct DC IP.

Synchronizing the clock with ntpdate -s 10.10.11.75 resolved the issue. Kerberos authentication requires the client and domain controller clocks to be closely aligned, and a time drift triggers KRB_AP_ERR_SKEW errors. After syncing, the Kerberos TGT became valid, allowing BloodHound to authenticate and enumerate the domain successfully. You can verify the ticket with klist and rerun BloodHound using -k or your ccache. For a persistent solution, consider running a time service like chrony or ntpd, or continue using ntpdate during the engagement.

IT‑COMPUTER3$ added itself to the HelpDesk group.

Execute timeroast.py.

Because the machine requires Kerberos authentication, enumeration attempts return no results. In addition to AS-REP roasting and Kerberoasting, a new technique called timeroast has recently emerged.

The screenshot above shows the hash as clean.

Hashcat was unable to crack the hash.

The main() function sets up and runs the script: it creates an argument parser with two positional inputs (the timeroast hashes file and a password dictionary opened with latin-1 encoding), parses those arguments, then calls try_crack to iterate through dictionary candidates and compare them to the parsed hashes. For each match it prints a β€œ[+] Cracked RID …” line and increments a counter, and when finished it prints a summary of how many passwords were recovered. The if __name__ == '__main__' guard ensures main() runs only when the script is executed directly.

Running python3 timecrack.py timeroast.txt rockyou.txt recovered one credential: RID 1125 β€” password Rusty88!. Total passwords recovered: 1.

Impacket requested a TGT for the machine account IT-COMPUTER3$ on rustykey.htb and saved the Kerberos ticket to IT-COMPUTER3$.ccache. The Kerberos credential cache was set to IT-COMPUTER3$.ccache by exporting KRB5CCNAME=IT-COMPUTER3\$.ccache, directing Kerberos-aware tools to use this saved TGT for authentication.

Using BloodHound with Kerberos against dc.rustykey.htb (domain rustykey.htb), authenticated as the machine account IT-COMPUTER3$, and ran add groupMember HELPDESK IT-COMPUTER3$ β€” the account IT-COMPUTER3$ was successfully added to the HELPDESK group.

Using BloodyAD with Kerberos against dc.rustykey.htb (domain rustykey.htb), authenticated as the machine account IT-COMPUTER3$, ran set password for bb.morgan to P@ssw0rd123, and the password was changed successfully.

Impacket attempted to request a TGT for bb.morgan@rustykey.htb, but the KDC rejected it with KDC_ERR_ETYPE_NOSUPP, meaning the Key Distribution Centre does not support the encryption type used.

If you need that permission, remove the protection first β€” bb.morgan.

Ran BloodyAD with Kerberos against dc.rustykey.htb as IT-COMPUTER3$ to remove the account IT from the PROTECTED OBJECTS group, and the tool reported that IT was removed. Using BloodyAD with Kerberos against dc.rustykey.htb as IT-COMPUTER3$ I changed bb.morgan’s password to P@ssw0rd123. I then requested a TGT for bb.morgan with impacket-getTGT and saved the ticket to bb.morgan.ccache

Set KRB5CCNAME to bb.morgan.ccache so Kerberos-aware tools use that credential cache.

If evil-winrm failed, common causes are WinRM not reachable, wrong auth method, or account restrictions. First check connectivity and service: nc -vz 10.10.11.75 5985 (and 5986). Test the WinRM endpoint with curl to see auth behavior:
curl --negotiate -u 'bb.morgan:P@ssw0rd123' http://10.10.11.75:5985/wsman
If you’re using Kerberos, ensure KRB5CCNAME points to the bb.morgan ccache and run evil-winrm with Kerberos (use the tool’s Kerberos flag). If password auth, try: evil-winrm -i 10.10.11.75 -u bb.morgan -p 'P@ssw0rd123'. If that still fails, try an alternate Impacket client (wmiexec.py, psexec.py) to rule out evil-winrm-specific issues. Also verify the account isn’t restricted (must-change-password, disabled, or requires smartcard) and that SMB/WinRM signing/policy isn’t blocking the session. Tell me the exact error if you want targeted troubleshooting.

After synchronising the system clock with rdate, evil-winrm successfully established a session to dc.rustykey.htb using the bb.morgan account in the rustykey.htb domain.

To view the user flag, run type user.txt at the command prompt.

Escalate to Root Privileges Access

Privilege Escalation:

One PDF file stood out and drew my attention.

Download the PDF to our machine.

The message appears to be from bb.morgan to support-team@rustykey.htb, stating the support team will receive elevated registry permissions and temporary elevated rights.
Reviewing BloodHound shows ee.reed is a member of the support-team@rustykey.htb group.

Using the IT‑COMPUTER3$ machine account you removed SUPPORT from the Protected Objects container and reset ee.reed’s password to P@ssword123 β€” actions that demonstrate domain‑level privilege to alter AD protections and control user accounts. With ee.reed’s credentials you can obtain a TGT, export a ccache, and authenticate to domain services (SMB/WinRM/LDAP) to escalate access and pivot further.

This indicates that the SUPPORT group has modify permissions on the registry and can interact with compression and decompression functions.

Requested a TGT for ee.reed@rustykey.htb from DC 10.10.11.75 and saved the Kerberos ticket to ee.reed.ccache.

Evil‑winrm failed to establish a session using ee.reed’s access.

Let’s start the listener.

Upload runascs.exe

Attempt to execute the payload.

Access obtained as ee.reed.

Oddly, the victim machine has 7‑Zip installed.

It’s 7‑Zip version 24.08.

The command reg query "HKLM\Software\Classes\*\ShellEx\ContextMenuHandlers" queries the Windows Registry to list all entries under the ContextMenuHandlers key for all file types (*) in the HKEY_LOCAL_MACHINE\Software\Classes hive.

Query the registry key HKEY_LOCAL_MACHINE\Software\Classes\*\ShellEx\ContextMenuHandlers\7-Zip.

Display the registry key HKLM\SOFTWARE\Classes\CLSID{23170F69-40C1-278A-1000-000100020000}.

Query the registry key HKLM\SOFTWARE\Classes\CLSID\{23170F69-40C1-278A-1000-000100020000}\InprocServer32.

This PowerShell command retrieves and displays the detailed access permissions (ACL) for the 7-Zip COM object CLSID registry key (HKLM\SOFTWARE\Classes\CLSID\{23170F69-40C1-278A-1000-000100020000}), showing which users or groups can read, modify, or take ownership of the key in a clear, list format.

Download the DLL file onto the target machine.

Add or update the default value of HKLM\Software\Classes\CLSID{23170F69-40C1-278A-1000-000100020000}\InprocServer32 to C:\tmp\dark.dll using reg add with the force flag.

Executing rundll32.exe dark.dll, dllmain produces no visible effect.

Obtained a shell as the user mm.turner.

It shows that the SUPPORT group has registry modify permissions and can access compression and decompression functionalities.

Initially, this PowerShell command failed to configure the DC computer account to allow delegation to the IT-COMPUTER3$ account by setting the PrincipalsAllowedToDelegateToAccount property.

This PowerShell command configures the DC computer account to allow delegation to the IT-COMPUTER3$ account by setting the PrincipalsAllowedToDelegateToAccount property, effectively granting that machine account the ability to act on behalf of other accounts for specific services.

Ran Impacket getST for SPN cifs/DC.rustykey.htb while impersonating backupadmin (DC 10.10.11.75) using rustykey.htb/IT-COMPUTER3$:Rusty88!. No existing ccache was found so a TGT was requested, the tool performed S4U2Self and S4U2Proxy flows to impersonate backupadmin, and saved the resulting ticket as backupadmin.ccache. Deprecation warnings about UTC handling were also printed.

Export the Kerberos ticket to a ccache file, then use Impacket’s secretdump to extract the account hashes.

Using the backupadmin Kerberos ticket (no password), Impacket connected to dc.rustykey.htb, discovered a writable ADMIN$ share, uploaded rFPLWAqZ.exe, created and started a service named BqCY, and spawned a shell β€” whoami returned NT AUTHORITY\SYSTEM.

To view the root flag, run type root.txt at the command prompt.

The post Hack The Box: RustyKey Machine Walkthrough – Hard Difficulity appeared first on Threatninja.net.

Hack The Box: Certificate Machine Walkthrough – Hard Difficulty

By: darknite
Reading Time: 12 minutes

Introduction to Certificate:

In this write-up, we will explore the β€œCertificate” machine from Hack The Box, categorized 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 β€œCertificate” machine from Hack The Box by achieving the following objectives:

User Flag:

We found a login account (lion.sk) by analyzing network traffic and files, then cracked a captured password hash to get the password. Using that password we remotely logged into the machine as lion.sk and opened the desktop to read the user.txt file, which contained the user flag.

Root Flag:

To get full control (root), we abused the machine’s certificate system that issues digital ID cards. By requesting and extracting certificate material and using a small trick to handle the server’s clock, we converted those certificate files into administrative credentials. With those elevated credentials we accessed the system as an admin and read the root.txt file for the root flag.

Enumerating the 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.71

Nmap Output:

β”Œβ”€[dark@parrot]─[~/Documents/htb/certificate]
└──╼ $nmap -sC -sV -oA initial 10.10.11.71 
# Nmap 7.94SVN scan initiated Tue Sep 30 21:48:51 2025 as: nmap -sC -sV -oA initial 10.10.11.71
Nmap scan report for 10.10.11.71
Host is up (0.048s latency).
Not shown: 988 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Apache httpd 2.4.58 (OpenSSL/3.1.3 PHP/8.0.30)
|_http-server-header: Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.0.30
|_http-title: Did not follow redirect to http://certificate.htb/
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-10-01 03:49:25Z)
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: certificate.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-10-01T03:50:56+00:00; +2h00m32s from scanner time.
| ssl-cert: Subject: commonName=DC01.certificate.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.certificate.htb
| Not valid before: 2024-11-04T03:14:54
|_Not valid after:  2025-11-04T03:14:54
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: certificate.htb0., Site: Default-First-Site-Name)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: certificate.htb0., Site: Default-First-Site-Name)
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: certificate.htb0., Site: Default-First-Site-Name)
Service Info: Hosts: certificate.htb, DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: 2h00m30s, deviation: 2s, median: 2h00m30s
| smb2-security-mode: 3:1:1: Message signing enabled and required
| smb2-time: date: 2025-10-01T03:50:14

Analysis:

  • 53/tcp β€” DNS (Simple DNS Plus): name resolution and potential zone/host enumeration.
  • 80/tcp β€” HTTP (Apache/PHP): web app surface for discovery, uploads, and common web vulnerabilities.
  • 88/tcp β€” Kerberos: AD authentication service; useful for ticket attacks and Kerberos enumeration.
  • 135/tcp β€” MSRPC: RPC endpoint for Windows services (potential remote service interfaces).
  • 139/tcp β€” NetBIOS-SSN: legacy SMB session service β€” useful for NetBIOS/SMB discovery.
  • 389/tcp β€” LDAP: Active Directory directory service (user/group enumeration and queries).
  • 445/tcp β€” SMB (Microsoft-DS): file shares and SMB-based lateral movement/credential theft.
  • 464/tcp β€” kpasswd (Kerberos password change): Kerberos password change service.
  • 593/tcp β€” RPC over HTTP: RPC tunneled over HTTP β€” can expose various Windows RPC services.
  • 636/tcp β€” LDAPS: Secure LDAP over TLS β€” AD queries and certificate info via encrypted channel.
  • 3268/tcp β€” Global Catalog (LDAP): AD global catalog queries across the forest (fast user/group lookup).
  • 3269/tcp β€” Global Catalog over TLS: Encrypted global catalog queries for secure AD enumeration.

Web Enumeration:

The website’s interface initially appears conventional.

The Account tab contains options for logging in and registering.

Let’s create a new account here.

You can register in the same way as shown above.

The registration was successful.

Therefore, let’s log in using the credentials we created earlier.

Successful access will display an interface similar to the one shown above.

Clicking the course tab displays the interface shown above.

As a result, let’s enrol in the course.

There are many sessions, but the quiz is what caught my attention at the moment.

There is an upload button available in the quizz section.

We are required to upload a report in PDF, DOCX, PPTX, or XLSX format.

After a while, I uploaded a form.pdf file that contained empty content.

Once the file is successfully uploaded, we need to click the β€œHERE” link to verify that it has been uploaded into the system.

It worked like a charm.

Exploiting Zip Slip: From Archive to Remote Code Execution

Zip Slip is a critical arbitrary file overwrite vulnerability that can often lead to remote command execution. The flaw impacts thousands of projects, including those from major vendors such as HP, Amazon, Apache, and Pivotal. While this type of vulnerability has existed previously, its prevalence has recently expanded significantly across a wide range of projects and libraries.

Let’s implement a PHP reverse shell to establish a reverse connection back to our host.

Compress the PDF into dark.zip and upload it as a standard archive file.

We also compress the test directory, which includes exploit.php, into a ZIP archive.

Combine the two ZIP archives into a single ZIP file for upload as part of an authorized security assessment in an isolated testing environment.

Initiate the listener.

Upload the shell.zip file to the designated test environment within the authorized, isolated assessment scope.

Access the specified URL within the isolated test environment to observe the application’s behavior.

After a short interval, the connection was reestablished.

Among numerous users, the account xamppuser stood out.

Consequently, inspect the certificate.htb directory located under /xampp/htdocs.

I discovered information indicating that we can utilise the MySQL database.

Executing the MySQL command returned no errors, which is a positive sign.

MySQL Reconnaissance and Attack Surface Mapping

As a result, we navigated to /xampp/mysql/bin, used mysql.exe to run SQL commands, and successfully located the database.

The users table drew my attention.

There is a significant amount of information associated with several users.

While scrolling down, we identified a potential user named sara.b.

The hash was collected as shown above.

All the hashes use Blowfish (OpenBSD), WoltLab Burning Board 4.x, and bcrypt algorithms.

When using Hashcat, a specific hash mode is required.

After extended processing, the password for the suspected account sara.b was recovered as Blink182.

Attempting to access the machine using Sara.B’s credentials.

Unfortunately, Sara.B’s desktop contains no files.

Bloodhound enumeration

We can proceed with further analysis using the BloodHound platform.

Sara.B Enumeration for Lateral Movement

We can observe the WS-01 directory.

There are two different file types present.

The Description.txt file reports an issue with Workstation 01 (WS-01) when accessing the Reports SMB share on DC01. Incorrect credentials correctly trigger a β€œbad credentials” error, but valid credentials cause File Explorer to freeze and crash. This suggests a misconfiguration or fault in how WS-01 handles the SMB share, potentially due to improper permissions or corrupt settings. The behavior indicates a point of interest for further investigation, as valid access attempts lead to system instability instead of normal access.

Download the pcap file to our machine for further analysis.

Wireshark analaysis

There are numerous packets available for further investigation.

Upon careful analysis of packet 917, I extracted the following Kerberos authentication hash: $krb5pa$18$Lion.SK$CERTIFICATE.HTB$23f5159fa1c66ed7b0e561543eba6c010cd31f7e4a4377c2925cf306b98ed1e4f3951a50bc083c9bc0f16f0f586181c9d4ceda3fb5e852f0.

Alternate Certificate Forging via Python Script

Alternatively, we can use a Python script here

Save the hash to hash.txt.

The recovered password is !QAZ2wsx.

This confirms that the account lion.sk can authenticate to WinRM using the password !QAZ2wsx.

We successfully accessed the lion.sk account as expected.

Read the user flag by running the command: type user.txt.

Escalate To Root Privileges Access

Privilege Escalation:

Sara.B is listed as a member of Account Operators and has GenericAll rights over the lion.sk account. In plain terms, that means Sara.B can fully manage the lion.sk user β€” change its password, modify attributes, add it to groups, or even replace its credentials. Because Account Operators is a powerful built‑in group and GenericAll grants near‑complete control over that specific account, this is a high‑risk configuration: an attacker who compromises Sara.B (or abuses her privileges) could take over lion.sk and use it to move laterally or escalate privileges.

Synchronise the system clock with certificate.htb using ntpdate: ntpdate -s certificate.htb

ESC3 Enumeration and CA Configuration Analysis

What is ESC3 Vulnerability?

In a company, employees get digital certificatesβ€”like special ID cardsβ€”that prove who they are and what they’re allowed to do. The ESC3 vulnerability happens when certain certificates allow users to request certificates on behalf of others. This means someone with access to these certificates can pretend to be another person, even someone with higher privileges like an admin.

Because of this, an attacker could use the vulnerability to gain unauthorized access to sensitive systems or data by impersonating trusted users. It’s like being able to get a fake ID that lets you enter restricted areas.

Fixing this involves limiting who can request these certificates and carefully controlling the permissions tied to them to prevent misuse.

Using lion.sk credentials, Certipy enumerated 35 certificate templates, one CA (Certificate-LTD-CA), 12 enabled templates, and 18 issuance policies. Initial CA config retrieval via RRP failed due to a remote registry issue but succeeded on retry. Web enrollment at DC01.certificate.htb timed out, preventing verification. Certipy saved results in text and JSON formats and suggests using -debug for stack traces. Next steps: review saved outputs and confirm DC01’s network/service availability before retrying.

Certipy flagged the template as ESC3 because it contains the Certificate Request Agent EKU β€” meaning principals allowed to enrol from this template (here CERTIFICATE.HTB\Domain CRA Managers, and Enterprise Admins listed) can request certificates on behalf of other accounts. In practice, that lets those principals obtain certificates that impersonate higher‑privilege users or services (for example ,issuing a cert for a machine or a user you don’t control), enabling AD CS abuse and potential domain escalation.

Request the certificate and save it as lion.sh.pfx.

Certificate Issued to Ryan.k

Sara.B is a member of Account Operators and has GenericAll permissions on the ryan.k account β€” in simple terms, Sara.B can fully control ryan.k (reset its password, change attributes, add/remove group membership, or replace credentials). This is high risk: if Sara.B is compromised or abused, an attacker can take over ryan.k and use it for lateral movement or privilege escalation. Recommended actions: limit membership in powerful groups, remove unnecessary GenericAll delegations, and monitor/account‑change audit logs.

Certipy requested a certificate via RPC (Request ID 22) and successfully obtained a certificate for UPN ryan.k@certificate.htb; the certificate object SID is S-1-5-21-515537669-4223687196-3249690583-1117 and the certificate with its private key was saved to ryan.k.pfx.

Unfortunately, the clock skew is too large.

When using the faketime command, it behaves as expected.

With explicit permission and in a controlled environment, verify whether the extracted hash can authenticate as ryan.k for investigative purposes.

Abusable Rights: SeManageVolumePrivilege

The following privileges are enabled: SeMachineAccountPrivilege β€” Add workstations to the domain; SeChangeNotifyPrivilege β€” Bypass traverse checking; SeManageVolumePrivilege β€” Perform volume maintenance tasks; SeIncreaseWorkingSetPrivilege β€” Increase a process’s working set.

Let’s create a temporary directory.

While executing the command, we encountered the error Keyset does not exist, indicating the required cryptographic key material is missing or inaccessible.

Therefore, we need to transfer the SeManageVolumeExploit.exe file to the target machine.

It refers to entries that have been modified.

I ran icacls on Windows, and it successfully processed 1 file with 0 failures.

Finally, it worked exactly as I expected.

We can now download the ca.pfx file to our local machine

Certificate Forgery for Domain Auth (Certipy)

We can convert the ca.pfx file into admin.pfx.

Authentication failed because the clock skew is too significant.

After switching to faketime, it worked like a charm.

Read the root flag by running the command: type root.txt.

The post Hack The Box: Certificate Machine Walkthrough – Hard Difficulty appeared first on Threatninja.net.

Hack The Box: Eureka Machine Walkthrough – Hard Dificulty

By: darknite
Reading Time: 12 minutes

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.66

Nmap 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 seconds

Analysis:

  • 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.txt

Gobuster 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:

  • /actuator shows system details,
  • /caches shows cache info,
  • /features lists features,
  • /info gives metadata,
  • /health shows status,
  • /env shows variables,
  • /metrics shows performance,
  • /refresh returns 405,
  • /sessions returns 400,
  • /scheduledtasks shows tasks,
  • /mappings lists routes,
  • /loggers shows logs,
  • /beans lists beans,
  • /configprops shows config,
  • /conditions shows auto-config,
  • /threaddump shows 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: close

As 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.

A computer screen with text on it

AI-generated content may be incorrect.

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.

A computer screen with text

AI-generated content may be incorrect.

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.

A screenshot of a computer

AI-generated content may be incorrect.

Running the script produced no immediate effect, suggesting the logs remained unprocessed or required additional conditions.

A black screen with green and yellow text

AI-generated content may be incorrect.

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.

A black background with green and blue text

AI-generated content may be incorrect.

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.

Hack The Box: Scepter Machine Walkthrough – Hard Difficulty

By: darknite
Reading Time: 13 minutes

Introduction to Scepter

This write-up covers the β€œScepter” machine from Hack the Box, a hard difficulty challenge. It details the reconnaissance, exploitation, and privilege escalation steps to capture the user and root flags.

Objective on Scepter

The goal is to complete the β€œScepter” machine by achieving these objectives:

User Flag: The attacker cracked weak .pfx certificate passwords using pfx2john and rockyou.txt, Discovering that all shared the same password. After fixing time skew, they extracted d.baker’s NTLM hash via certipy. BloodHound revealed d.baker could reset a.carter’s password due to group privileges over the OU. By exploiting ESC9 and modifying the mail attribute, the attacker generated a spoofed certificate, authenticated as a.carter, and accessed the system to capture the user flag.

Root Flag: The attacker discovered that h.brown could modify p.adams’ certificate mapping, leading to an ESC14 vulnerability. By forging a certificate and binding it to p.adams using altSecurityIdentities, they authenticated as p.adams with Certipy. Since p.adams had DCSync rights, the attacker used secretsdump to extract domain hashes, then pivoted to the Administrator account via evil-winrm, Securing the root flag.

Enumerating the Scepter Machine

Establishing Connectivity

I connected to the Hack The Box environment via OpenVPN using my credentials, running all commands from a Kali Linux virtual machine. The target IP address for the Scepter machine wasΒ 10.10.11.65.

Reconnaissance:

Nmap Scan:

We scan the target at IP 10.10.11.65 to identify open ports:

nmap  -sC -sV 10.10.11.65 -oA initial 

Nmap Output:

Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-07-17 19:06 EDT
Nmap scan report for 10.10.11.65
Host is up (0.18s latency).
Not shown: 987 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-07-17 23:13:45Z)
111/tcp  open  rpcbind       2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/tcp6  rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  2,3,4        111/udp6  rpcbind
|   100003  2,3         2049/udp   nfs
|   100003  2,3         2049/udp6  nfs
|   100003  2,3,4       2049/tcp   nfs
|   100003  2,3,4       2049/tcp6  nfs
|   100005  1,2,3       2049/tcp   mountd
|   100005  1,2,3       2049/tcp6  mountd
|   100005  1,2,3       2049/udp   mountd
|_  100005  1,2,3       2049/udp6  mountd
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: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:50+00:00; +6m52s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
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: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:49+00:00; +6m51s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
2049/tcp open  mountd        1-3 (RPC #100005)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:50+00:00; +6m52s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:49+00:00; +6m51s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 6m51s, deviation: 0s, median: 6m50s
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-07-17T23:14:44
|_  start_date: N/A

Analysis:

  • 53/tcp (DNS): Simple DNS Plus running; possible subdomain enumeration or zone transfer.
  • 88/tcp (Kerberos): Kerberos service available; potential for AS-REP roasting or ticket attacks.
  • 111/tcp (rpcbind): RPC services exposed; confirms NFS and mountd usage on 2049.
  • 135/tcp (MSRPC): Windows RPC service; common on domain controllers, used for DCOM and remote management.
  • 139/tcp (NetBIOS-SSN): NetBIOS session service; legacy Windows file/printer sharing.
  • 389/tcp (LDAP): LDAP exposed; reveals domain scepter.htb, possible LDAP enumeration.
  • 445/tcp (SMB): SMB service running; check for shares, null sessions, and vulnerabilities.
  • 464/tcp (kpasswd5): Kerberos password service; often used with password change requests.
  • 593/tcp (RPC over HTTP): RPC over HTTP (ncacn_http); used in Outlook and domain services.
  • 636/tcp (LDAPS): Secure LDAP; same domain as port 389, check for SSL issues or AD leaks.
  • 2049/tcp (NFS): NFS file sharing active; can allow unauthenticated file access or mounting.
  • 3268/tcp (GC LDAP): Global Catalog LDAP service; useful for domain-wide user enumeration.
  • 3269/tcp (GC LDAPS): Secure Global Catalog LDAP; encrypted version of port 3268.

NFS Enumeration on Scepter Machine

To check for NFS shares, I used:

showmount -e 10.10.11.65

Output:

The command showed a /helpdesk share. I mounted it locally:

I create a local folder nfs with mkdir nfs to serve as a mount point. Then, using sudo mount -t nfs 10.10.11.65:/helpdesk nfs -o nolock, you connect the remote /helpdesk share to that folder, making it accessible locally. The -o nolock option prevents locking issues. Finally, sudo ls nfs lists the shared filesβ€”like accessing a USB drive, but over the network.

When I tried cd nfs/ with sudo, it failed since cd is a shell built-in. I resolved it by switching to root:

Handling NFS Access

I resolved it by switching to root.

Inside, I found several files:

  • scott.pfx
  • baker.crt
  • baker.key
  • clark.pfx
  • lewis.pfx

I copied them to a higher directory

Certificate Analysis

baker.crt

I viewed baker.crt

It belonged to d.baker@scepter.htb, issued by scepter-DC01-CA.

baker.key

The corresponding baker.key was encrypted and required a password.

clark.pfx

Viewing .pfx files like clark.pfx showed unreadable binary output. These files are password-protected containers.

OpenSSL and Certificate Recreation

I used OpenSSL to inspect two password-protected .pfx files. Without the correct passwords, access is denied due to strong SHA256 encryption. Cracking these passwords is essential to unlock their contents and advance in the challenge

Cracking PFX Passwords

I used pfx2john.py to extract the hash

Although I’m using Hashcat to crack scott.pfx’s password from scott.hash, I encounter an error because the hash format isn’t recognised. Fix it by specifying the correct mode (-m 13100) or verifying the hash file. This step is crucial to unlock the certificate and gain access.

Password Cracking with John the Ripper

Then, I cracked it using John and the password newpassword worked for scott.hash but I already tested on all *.pfx file and success.

OpenSSL, Certipy, and BloodHound Exploitation Techniques

I re-created baker.pfx and I used newpassword as the export password.

AD CS Exploitation

Certipy Authentication

Another approach was to re-create the baker.pfx file; this was necessary because the original one was either invalid or unusable.

I authenticated to the domain using the baker.pfx file, and this failed initially due to clock skew.

I fixed the time with the command ntpdate -s 10.10.11.65

After syncing, authentication succeeded. I obtained an NTLM hash and a Kerberos .ccache file.

Bloodhound enumeration on Scepter machine

I ran BloodHound with NTLM hash

BloodHound CE GUI Analysis for Privilege Escalation on Scepter Machine

This represents a relationship in BloodHound where the user d.baker@scepter.htb has the ability to force a password change for the user a.carrter@scepter.htb. This is a powerful privilege escalation path because it can potentially allow d.baker to take over a.carrterβ€˜s account by resetting their password.

A.CARTER is a member of the IT SUPPORTSTAFF ACCESS CERTIFICATE group. This group has the modification rights over a specific Organizational Unit (OU).



A.CARTER, as a member of the IT SUPPORTSTAFF ACCESS CERTIFICATE group, not only has modification rights over the OU containing D.BAKER but also can directly manipulate D.BAKER’s mail attribute. As a result, this access consequently opens the door to abusing ESC9 (Active Directory Certificate Services escalation). Furthermore, this vulnerability creates a significant privilege escalation risk that attackers can exploit.

H.BROWN belongs to both the Remote Management Users group and the Protected Users group. As a result, H.BROWN enjoys permissions for remote management tasks, such as accessing servers. However, the Protected Users group imposes strict security restrictions. Consequently, these limitations may block certain authentication methods, like NTLM, or hinder lateral movement within the scepter.htb domain. Therefore, exploiting H.BROWN’s account requires bypassing these constraints, for example, by leveraging certificate-based attacks to achieve privilege escalation in the Scepter machine.

H.BROWN has write permissions over critical attributes, enabling DCSync operations to extract sensitive data, such as password hashes. As a result, they can target P.ADAMS by manipulating the altSecurityIdentities attribute. For instance, updating this attribute with a crafted certificate allows H.BROWN to authenticate as P.ADAMS without a password. Therefore, exploiting altSecurityIdentities is a key step in achieving full domain control in the Scepter machine.

Analysis of Certificate Templates

By using Certipy’s find command, I enumerated certificate templates in AD CS, specifically targeting misconfigurations like ESC1, ESC2, or ESC8 vulnerabilities. For example, these flaws allow attackers to request high-privilege certificates, enabling unauthorized access. Consequently, identifying such issues is critical for exploiting AD CS weaknesses. Additionally, this step facilitates privilege escalation by revealing templates with excessive permissions. Thus, Certipy’s enumeration plays a pivotal role in achieving domain compromise in the Scepter machine.

ESC9: ADCS Privilege Escalation

Exploit Overview:

ESC9 in Active Directory Certificate Services (ADCS) allows attackers to abuse misconfigured certificate templates for privilege escalation. If a template permits users to specify Subject Alternative Names (SANs) (e.g., UPNs) and the CA honours them without restrictions, a low-privileged user can request a certificate impersonating a high-privileged account (like a Domain Admin).

Source: ADCS ESC9 – No Security Extension

Troubleshooting BloodyAD Issues

We need to update the password using the command provided, but unfortunately, the password does not meet the required complexity rules.

The password was successfully changed after meeting the complexity requirements.

The β€œInvalid Credentials” error (LDAP error code 49) during an LDAP bind typically indicates a failure to authenticate due to incorrect credentials or configuration issues.

System Configuration Assessment

If the UserAccountControl attribute includes the DONT_EXPIRE_PASSWORD flag (value 65536 or 0x10000), the user’s password never expires. Consequently, this setting can disrupt LDAP authentication or password-related operations. For example, systems expecting periodic password changes or strict complexity rules may reject the account’s state. As a result, this could cause the β€œInvalidCredentials” error (LDAP error code 49) during an LDAP bind in the Scepter machine. Therefore, verifying the account’s configuration and server expectations is crucial for resolving authentication issues.

The screenshot provided displays the output of the ldapsearch command.

Running the bloodyAD command with sudo privileges resolved the issue, and it now functions perfectly.

Certificate Abuse for scepter machine

I used an existing template to request a certificate for h.brown. This gave me h.brown.pfx.

After exploiting AD CS vulnerabilities, the system provided H.BROWN’s NTLM hash and a h.brown.ccache file. Specifically, the .ccache file serves as a temporary access pass, enabling impersonation of H.BROWN across the network without re-entering credentials. For example, this allows discreet movement within the scepter.htb domain. Consequently, it facilitates information gathering, such as enumerating shares or services, for further exploitation. Thus, these credentials are critical for advancing privilege escalation in the Scepter machine.

After obtaining H.BROWN’s Kerberos ticket in the h.brown.ccache file, configure your system to use it. Then, connect to a Windows server, such as dc01.scepter.htb, bypassing password authentication. For instance, if the ticket is valid and the server accepts it, you’ll gain remote access as H.BROWN.

We retrieved the user flag by executing the type user.txt command.

Escalate to Root Privileges Access on Scepter Machine

Privileges Access

H.BROWN’s Permissions

Using H.BROWN’s Kerberos ticket (h.brown.ccache), the command bloodyAD -d scepter.htb -u h.brown -k –host dc01.scepter.htb –dc-ip 10.10.11.65 get object h.brown –detail queries the domain controller. Specifically, it reveals permissions, such as modifying users or groups. For example, the –detail flag provides precise control rights, including write access to P.ADAMS’s altSecurityIdentities. Consequently, this output identifies privilege escalation paths, like DCSync or certificate-based attacks. Thus, querying permissions is a key step in the Scepter machine’s AD exploitation.

altSecurityIdentities Manipulation

You discovered that h.brown has write permissions on the altSecurityIdentities attribute of the user p.adams in Active Directory, as indicated by:

distinguishedName: CN=p.adams,OU=Helpdesk Enrollment Certificate,DC=scepter,DC=htb
altSecurityIdentities: WRITE

This means h.brown can hijack p.adams’s identity by modifying their certificate mapping. With this, h.brown can request a certificate and authenticate as p.adamsβ€”no password needed. Moreover, if p.adams is highly privileged (e.g., Domain Admin), h.brown can launch a DCSync attack to dump domain password hashes. Consequently, this single write permission can lead to a complete domain compromise.

Abusing altSecurityIdentities and Certificate-Based Attacks in Active Directory

After using OpenSSL to extract the certificate from d.baker.pfx, the serial number shows up in its usual big-endian format, which is just the standard way it’s displayed.

Exploit ESC14 with User-to-User Certificate-Based Attack

62:00:00:00:05:2a:87:15:0c:cc:01:d1:07:00:00:00:00:00:05

After extracting the certificate serial number from d.baker.pfx using OpenSSL, it appears in big-endian format (e.g., 62:00:00:00:05:2a:87:15:0c:cc:01:d1:07:00:00:00:00:00:05). However, tools like Certipy and BloodyAD require little-endian format for certificate forgery. Therefore, reversing the byte order is crucial for accurate interpretation. For instance, this conversion ensures successful altSecurityIdentities manipulation in commands like bloodyAD set object p.adams altSecurityIdentities.

The command can be used as follows:

bloodyAD -d "scepter.htb" -u "h.brown" -k --host "dc01.scepter.htb" --dc-ip "10.10.11.65" set object "p.adams" altSecurityIdentities -v "X509:<RFC822>p.adams@scepter.htb"

By updating altSecurityIdentities, you link your certificate to p.adams’s account, letting you log in as them without a password. This is a key move in abusing certificate-based authentication in AD.

The command can be used as follows:

bloodyAD -d "scepter.htb" -u "a.carter" -p 'Password' --host "dc01.scepter.htb" set object "d.baker" mail -v "p.adams@scepter.htb"

This type of change can be used to manipulate identity mappings, paving the way for attacks like spoofing or malicious certificate requests.

Root Access via Pass-the-Hash

This Certipy command uses Kerberos to request a StaffAccessCertificate for p.adams from dc01.scepter.htb. If granted, it saves the cert as p.adams, letting you authenticate and act as p.adams within the domain.

This Certipy command uses the padams.pfx certificate to authenticate as p.adams to the AD domain at 10.10.11.65, enabling password-free access and resource control via certificate-based login.

This command uses p.adams’s NTLM hash to authenticate to the domain controller dc01.scepter.htb and extract the administrator’s password hashes. It targets only the admin account (RID 500), retrieving the LM hash (usually empty) and the NTLM hashβ€”the latter can be used for pass-the-hash attacks to gain full admin access. This lets an attacker escalate privileges and take control of the domain controller.

After obtaining the Administrator’s NTLM hash via a DCSync attack, use Evil-WinRM to connect to the Windows machine at 10.10.11.65. Specifically, the command evil-winrm -i 10.10.11.65 -u Administrator -H authenticates via Pass-the-Hash, bypassing password requirements. If successful, it establishes a remote PowerShell session with full admin rights. Consequently, this access allows command execution, such as type root.txt, to retrieve the root flag. Thus, Evil-WinRM is critical for achieving domain control in the Scepter machine.

We retrieved the root flag by executing the type root.txt command.

The post Hack The Box: Scepter Machine Walkthrough – Hard Difficulty appeared first on Threatninja.net.

Hack The Box: Haze Machine Walkthrough – Hard Difficulty

By: darknite
Reading Time: 17 minutes

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 time
3269/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 seconds

Analysis:

  • 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.py

On line 6, the import statement needs to be corrected.

Current line:

from cryptography.hazmat.decrepit.ciphers.algorithms import ARC4

Updated line:

from cryptography.hazmat.primitives.ciphers.algorithms import ARC4

Once 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.

Hack The Box: Checker Machine Walkthrough – Hard Difficulty

By: darknite
Reading Time: 10 minutes

Introduction to Checker:

In this write-up, we will explore the β€œChecker” 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 of Checker:

The goal of this walkthrough is to complete the β€œChecker” machine from Hack The Box by achieving the following objectives:

User Flag:

We exploited CVE-2023-1545 in the Teampass application to extract password hashes and cracked them to obtain credentials for the user β€œbob.” These credentials allowed access to both the BookStack web application and SSH. We then exploited CVE-2023-6199 in BookStack to read the OTP secret for the SSH user β€œreader,” enabling successful login and retrieval of the user flag.

Root Flag:

We discovered that the β€œreader” user had sudo privileges to run a script that interacted with shared memory. By analysing the script behaviour and injecting a command into the shared memory segment, we were able to set the SUID bit on /bin/bash. This grants root privileges, allowing us to read the root flag

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oN nmap_initial.txt 10.10.11.56

Nmap Output:

β”Œβ”€[dark@parrot]─[~/Documents/htb/checker]
└──╼ $nmap -sV -sC -oA initial 10.10.11.56 
# Nmap 7.94SVN scan initiated Thu May 29 00:05:33 2025 as: nmap -sV -sC -oA initial 10.10.11.56
Nmap scan report for 10.10.11.56
Host is up (0.23s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 aa:54:07:41:98:b8:11:b0:78:45:f1:ca:8c:5a:94:2e (ECDSA)
|_  256 8f:2b:f3:22:1e:74:3b:ee:8b:40:17:6c:6c:b1:93:9c (ED25519)
80/tcp   open  http    Apache httpd
|_http-server-header: Apache
|_http-title: 403 Forbidden
8080/tcp open  http    Apache httpd
|_http-server-header: Apache
|_http-title: 403 Forbidden
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 Thu May 29 00:06:28 2025 -- 1 IP address (1 host up) scanned in 55.98 seconds

Analysis:

  • Port 22 (SSH): OpenSSH 8.9p1 is running, providing secure remote shell access. This is typical for administrative management over the network.
  • Port 80 (HTTP): Apache web server is active but responds with a 403 Forbidden status, indicating that access to the root web directory is denied or restricted.
  • Port 8080 (HTTP): Another instance of Apache is running on this alternative HTTP port, also returning a 403 Forbidden response, which could hint at restricted access to a secondary web application or interface.

Web Enumeration on Checker machine:

Perform web enumeration to discover potentially exploitable directories and files.

gobuster dir -u http://checker.htb:8080 -w /opt/raft-small-directories-lowerrcase.txt

Gobuster Output:

During the enumeration process, we observed that the server returns a 403 Forbidden status code along with a consistent response length (199 bytes) for URLs that do not exist. This uniform response can interfere with the accurate detection of valid endpoints, as it mimics the behaviour of non-existent pages. To proceed effectively, we should configure our tool to exclude responses with this status code or length to reduce false positives.

Analysis:

During the enumeration phase, more than 20 directories were discovered, although only a portion is listed here due to space limitations. Each of the directories responded with a 429 status code, indicating the server is applying rate-limiting measures, likely to deter aggressive or automated scanning. Some of the identified directories, such as /app, /report, /store, and /db could potentially relate to application logic, data storage, or admin interfaces. This behaviour suggests the underlying application might be sensitive to traffic volume, so further inspection should be paced to avoid triggering additional restrictions.

A screenshot of a computer

AI-generated content may be incorrect.

Accessing the website via 10.10.11.56 redirects us to the domain β€˜checker.htbβ€˜.

A screenshot of a computer

AI-generated content may be incorrect.

We discovered that the application in use is BookStack. Unfortunately, we didn’t have any valid credentials to log in to BookStack at this stage.

What is BookStack?

BookStack is a free and open-source platform used to create and manage documentation or internal knowledge bases. Think of it like a digital bookshelf where each book contains pages of organised information. Teams or companies commonly use it to store guides, manuals, and notes in a user-friendly way, similar to how you’d organise content in a physical notebook, but online and searchable.

On port 8080, we were presented with the Teampass login page.

What is TeamPass?

Teampass is a web-based password management system designed for teams and organisations. It helps securely store and share login credentials, such as usernames and passwords, in a single, central location. Instead of keeping sensitive information in unprotected files or messages, Teampass allows team members to access and manage passwords through a secure, organised interface. This makes collaboration safer and more efficient, especially when multiple people need access to the same accounts or systems.

To gain a better understanding of the Teampass application, we analysed its source code available on GitHub.

One of the files caught my attention and warranted a deeper analysis.

This script is a setup routine for Teampass, designed to run when the application first starts. It checks if the Teampass code has already been initialised (by looking for a .git folder). If not, it pulls the necessary files from a remote repository, prepares directories needed for logs and encryption keys, and sets file permissions so the web server (nginx) can use them. Then, it checks if the main configuration file exists. If the file is missing, the script prompts the user to open Teampass in a web browser to complete the setup. Finally, it hands over control to start the application.

Another file that caught our attention is readme.md, which reveals the version of Teampass being usedβ€”version 3.

So, let’s investigate any exploits or vulnerabilities related to Teampass version 3.

Exploitation

Exploitation of CVE-2023-1545 in the Teampass Application

We can download the source code from GitHub onto our machine.

Additional reference: Snyk Security Advisory – SNYK-PHP-NILSTEAMPASSNETTEAMPASS-3367612, which provides detailed information regarding the identified vulnerability in the Teampass application.

I renamed the file to poc.py and executed it, which revealed usernames along with their hashes.

We need to specify the appropriate hash mode.

After some time, we successfully retrieved the passwords from the hashes, including one for the user β€œbob” with the hash $2y$10$yMypIj1keU.VAqBI692f..XXn0vfyBL7C1EhOs35G59NxmtpJ/tiy, which corresponded to the password β€œcheerleader.”

Let’s use the credentials we discovered earlier to log in to Teampass.

A screenshot of a computer

AI-generated content may be incorrect.

There is access for the user β€œbob,” which allows login to both BookStack and SSH.

For BookStack, the login details are username bob@checker.htb with the password mYSeCr3T_w1kI_P4sSw0rD.

A screenshot of a computer

AI-generated content may be incorrect.

For SSH access, the username is reader and the password is hiccup-publicly-genesis.

We attempted to access the system as Bob via SSH, but the login failed with the error message: β€œOperation not permitted” while writing the config.

BookStack Enumeration

A screenshot of a login screen

AI-generated content may be incorrect.

Let’s log into the BookStack dashboard using the Bob credentials we obtained earlier.

A screenshot of a computer

AI-generated content may be incorrect.

The book contains three essays, including one titled β€œBasic Backup with cp” that provides a file path. Since this machine is played with other players, I also noticed additional files like β€œExploit,” β€œaaa,” and β€œHTML” under the recently viewed section.

A screenshot of a computer

AI-generated content may be incorrect.

The other two articles do not contain any important information. This script seems significant because the destination path is unusual, and often the author hides clues in such details.

#!/bin/bash
SOURCE="/home"
DESTINATION="/backup/home_backup"

A version number is indicated in the URL:

http://checker.htb/dist/app.js?version=v23.10.2

Exploiting CVE-2023-6199 in BookStack v23.10.2: Leveraging Blind SSRF for Local File Read

We can obtain the source code from here.

Navigate to BookStack and create a new draft page as a Bob user.

Use Burp Suite to intercept the HTTP request when saving the draft page.

In Burp Suite, change the intercepted request body to x-www-form-urlencoded format instead of JSON

The intercepted request will appear in JSON format, similar to the screenshot above

Exploiting PHP Filter Chain Oracle to Read Arbitrary Files

We need to retrieve a copy of the script and save it to our local machine for further analysis.

We can execute the script shown earlier.

The screenshot above displays the result of the executed command.

The code shown above is the original version.

Include the following commands into the script:

import base64
encoded_data = base64.b64encode(filter_chain.encode('utf-8'))
encoded_string = encoded_data.decode('utf-8')
encoded_string = "<img src='data:image/png;base64,{}'>".format(encoded_string)
merged_data = { "name": "dark", "html": encoded_string }

It works because we successfully retrieved the contents of the /etc/passwd file.

We retrieved the TOTP authentication secret stored within the Google Authenticator.

We extracted the OTP from the script above, noting that it is time-sensitive and expires quickly.

A computer screen with green text

AI-generated content may be incorrect.

However, it still did not succeed.

Let’s use ntpdate to synchronise the system time.

A computer screen with numbers and text

AI-generated content may be incorrect.

You can view the user flag by running the command cat user.txt.

Escalate to Root Privileges Access on the checker machine

Privilege Escalation:

Review and confirm the sudo permissions granted to the reader user.

A computer screen with green text

AI-generated content may be incorrect.

This small script is like a set of instructions for the computer. It starts by loading some hidden settings needed to run properly. Then, it takes a username given by the user, cleans it up to make sure it only contains letters and numbers (to avoid any strange or harmful characters), and finally runs a program called β€œcheck_leak” using that cleaned username. Essentially, it’s a way to safely check something related to that user on the system.

When we run /opt/hash-checker/check-leak.sh using sudo, it shows an error saying that the <USER> argument was not given.

Supplying β€œreader” as the user caused the script to return an error indicating the user is not found in the database.

When specifying β€œbob” as the user, the script revealed that the password was exposed.

A computer screen with green and blue text

AI-generated content may be incorrect.

The /bin/bash binary does not have the SUID permission set.

A screen shot of a computer code

AI-generated content may be incorrect.

The script sets the /bin/bash binary with the SUID permission.

You can view the root flag by running the command cat root.txt.

The post Hack The Box: Checker Machine Walkthrough – Hard Difficulty appeared first on Threatninja.net.

❌