🥶Mira

mira

🔍 Step 1: Nmap Full Port Scan – Reconnaissance

nmap -v -sCTV -p- -T4 -Pn $IP

Nmap scan report for 10.10.11.78
Host is up (0.43s latency).
Not shown: 985 closed tcp ports (reset)
PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-07-20 11:19:33Z)
111/tcp   open  rpcbind?
|_rpcinfo: ERROR: Script execution failed (use -d to debug)
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-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
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-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
2049/tcp  open  mountd        1-3 (RPC #100005)
3268/tcp  open  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
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
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
50300/tcp open  msrpc         Microsoft Windows RPC
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows


Host script results:
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-07-20T11:20:47
|_  start_date: N/A
|_clock-skew: -2h59m07s

Add hosts

📂 Exploiting NFS Share on HTB Mirage

🔍 Initial Recon: NFS Discovered

While enumerating open ports on the target 10.10.11.78, we noticed that port 2049/tcp was open, which is typically used for NFS (Network File System). This suggests we might be able to access shared directories remotely.

NFS can often be misconfigured to allow unauthenticated access. So, the next logical step is to check for exported file shares using showmount.

📤 Enumerating NFS Exports

We used the following command to enumerate shared directories:

Output:

This confirms that /MirageReports is an NFS share accessible to everyone — likely world-readable. This is a strong indicator of potential information disclosure.

📥 Mounting the NFS Share Locally

To explore this share, we mounted it on our local machine.

Once mounted, we navigated into the directory to inspect its contents.

Files found:

These documents immediately caught our attention — incident reports and hardening guides often contain juicy internal details such as usernames, server hostnames, exposed services, or security misconfigurations.

🧪 Kerberos, DNS Poisoning, and NATS Exploitation on Mirage

🔐 Authentication Hardening Report Analysis

After reviewing the PDF files found via the NFS share, one stood out:

Mirage_Authentication_Hardening_Report.pdf.

This document outlines a recommendation to:

  1. Disable NTLM authentication.

  2. Use Kerberos-only authentication instead.

  3. Ensure proper DNS resolution for internal services like nats-svc.mirage.htb.

This is critical. If nats-svc.mirage.htb is missing in DNS and the environment enforces Kerberos, we can abuse DNS updates to redirect that service name to our attacking machine — tricking the system into authenticating to us.

🛠️ Step 1 – Kerberos Configuration

Before proceeding, we ensure our Kali box is ready to communicate via Kerberos by configuring /etc/krb5.conf:

🛰️ Step 2 – DNS Poisoning and Fake NATS Service

We’re told nats-svc.mirage.htb lacks a DNS record. That’s our opportunity.

We first create a fake NATS server listening on port 4222 — the default for NATS.

🔧 fake_server.py

Now poison the DNS:

🧲 Result: Credential Leak

Once the target attempts to reach the NATS server, it authenticates to us — and we capture credentials:

📡 Step 3 – Interacting with NATS

We now install and configure natscli to interact using the credentials we captured:

Then subscribe to all messages:

We observed live traffic including advisory events and auth_logs.

📚 Step 4 – Extracting Historical Logs via JetStream

We create a JetStream consumer to dump past authentication logs:

Use the following values:

  • Start policy: all

  • Replay policy: instant

  • Filter: logs.auth

Now retrieve all messages:

🎯 Credentials Captured: json

🧪 Step 5 – Testing New Credentials

Ensure time sync with the DC:

Then test the captured creds via LDAP:

Success!

Also, enumerate domain users:

Sample output:

🧭 Step 6 – BloodHound Enumeration

With valid credentials and Kerberos access, we run bloodhound-python:

This completes enumeration of:

  • Domain Users

  • Groups & OUs

  • Computers & Sessions

  • Trusts (if any)

  • GPOs

Output is ready to be uploaded to BloodHound for privilege escalation analysis.

🎯 Kerberoasting & Gaining Access as nathan.aadam on HTB Mirage

🔐 Kerberoasting via Impacket

After some user enumeration, we identified a valid domain user: david.jjackson. From previous steps, we had obtained a valid TGT using Kerberos (-k flag), which let us attempt Kerberoasting using Impacket's GetUserSPNs tool.

This pulled a Service Principal Name (SPN)-based ticket for another user:

The tool also dumped a TGS hash (Kerberos service ticket) for nathan.aadam, which we saved for offline cracking.

🧨 Cracking the TGS Ticket with Hashcat

The hash type for SPN-based TGS tickets is -m 13100 (Kerberos 5 TGS-REP etype 23). We used rockyou.txt to attempt cracking the hash:

After a short while, the password was revealed:

We now had valid credentials for nathan.aadam.

🎫 Getting a TGT and Shell Access via Evil-WinRM

We proceeded to get a Kerberos Ticket Granting Ticket (TGT) using impacket-getTGT:

A .ccache file was saved:

We then exported the ticket for use:

Now, we could authenticate using Kerberos (no password prompt needed) and spawn a WinRM shell:

⚠️ Note: We did not supply a username or password — the session used our Kerberos ticket.

Once connected, we successfully landed a shell as:

🏁 Privilege Escalation to Domain Admin on Mirage HTB

After gaining access as nathan.aadam, we pivoted toward privilege escalation using data gathered via BloodHound and Active Directory abuse techniques.

🔎 BloodHound Insights

BloodHound analysis revealed a potential attack path:

Our goal: Abuse ReadGMSAPassword on MIRAGE-SERVICE$ to ultimately escalate privileges.

🔓 Extracting Mark.bbond’s Credentials (AutoLogon Trick)

On Nathan’s session, we queried the registry for autologon credentials:

We found:

✅ Valid credentials:

🔁 Resetting Javier.mmarshall’s Password

Using bloodyAD, we leveraged ForceChangePassword from Mark to reset Javier's credentials:

✅ Password successfully changed.

However, trying to query msDS-ManagedPassword failed:

🛑 User Is Disabled — Reactivating Javier

Checking user status:

Status:

To fix this, we removed the ACCOUNTDISABLE flag:

✅ Javier’s account re-enabled.

🔐 Dumping the GMSA (Group Managed Service Account) Password

Now with Javier’s account active, we pulled the GMSA password:

Output:

✅ We now have the NTLM hash of Mirage-Service$.

🎫 Getting a TGT Using the GMSA Hash

Ticket saved to Mirage-Service$.ccache.

🎭 Certificate Abuse with Certipy (Misconfigured CA)

From Mirage-Service$, we abused certificate templates using Certipy:

Step 1: Modify UPN of Mark

Step 2: Revert UPN and Request a Certificate

✅ Certificate saved as dc01.pfx.

🧬 LDAP Shell + Resource-Based Constrained Delegation (RBCD)

Using the certificate:

In the shell:

✅ RBCD granted — Mirage-Service$ can now impersonate dc01$.

🧙‍♂️ Impersonating dc01$ (Domain Controller)

We used S4U2Self + S4U2Proxy to get a service ticket as dc01$:

✅ Got a TGS ticket for cifs/DC01.

🪓 Dumping All Domain Hashes — Full Pwn

impacket-secretsdump -k -no-pass mirage.htb/Administrator@dc01.mirage.htb -dc-ip 10.10.11.78

✅ Administrator hash dumped!

Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies

Last updated