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.

❌
❌