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:
Disable NTLM authentication.
Use Kerberos-only authentication instead.
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.
