Unconstrained Delegation Abuse: Exploiting Mis-configured SPNs

Introduction

Unconstrained delegation (UD) is a powerful but dangerous Active Directory (AD) feature. When a computer account is marked as Trusted for delegation, it can request service tickets (TGS) on behalf of any user to any service in the forest. Mis-configurations-often the result of legacy applications or careless admin actions-expose a full-blown Kerberos trust relationship that attackers can abuse to impersonate any user, including Domain Administrators.

In this guide we will walk through the end-to-end abuse chain: enumerating vulnerable SPNs, requesting tickets, extracting and forging them with Rubeus, and finally leveraging those tickets for privilege escalation. We also cover detection and mitigation strategies to help defenders close the gap.

Real-world incidents (e.g., the 2020 SolarWinds breach) have shown that attackers routinely harvest UD-enabled accounts to move laterally. Mastering this technique is essential for both offensive red-teamers and defensive blue-team analysts.

Prerequisites

• Solid understanding of Kerberos fundamentals (AS-REQ/AS-REP, TGT, TGS, PAC).
• Familiarity with Kerberos ticket types and their lifecycles.
• Experience enumerating AD objects (PowerView, BloodHound, LDAP).
• Access to a Windows domain-joined machine with sufficient privileges to run PowerShell and Rubeus (usually a low-privilege user).

Core Concepts

Before diving into the abuse steps, let’s recap the key concepts that make UD exploitable.

Service Principal Names (SPNs)

An SPN uniquely identifies a service instance. It is stored as an attribute (servicePrincipalName) on a computer or user object. Example SPNs:

HOST/websrv01.corp.local
HTTP/webapp.corp.local
MSSQLSvc/sql01.corp.local:1433

When a client requests a service ticket, the Key Distribution Center (KDC) looks up the SPN, validates the service account’s secret, and issues a TGS encrypted with the service’s long-term key.

Unconstrained Delegation (UD)

UD is represented by the msDS-AllowedToDelegateTo attribute being empty (meaning "any service"). In practice, the KDC will issue a service ticket to the delegating computer that contains a forwardable flag, allowing the computer to request tickets on behalf of the original user.

When an attacker gains control of a UD-enabled computer account, they can request a TGS for any SPN, then present that ticket to the target service, effectively impersonating any user whose credentials were originally used to obtain the delegating computer’s TGT.

Why It Works

The Kerberos protocol trusts the delegating computer because AD says it is allowed to act on behalf of anyone. The cryptographic checks only verify that the ticket is encrypted with the service’s key-not that the requester is the original user. This trust model is the root of the abuse.

Identifying SPNs with Unconstrained Delegation via PowerView/Rubeus

Finding vulnerable accounts is the first step. Two popular tools are PowerView (PowerShell) and Rubeus (C#). Both can query AD for the trustedForDelegation flag.

Using PowerView

Import-Module .\PowerView.ps1
# Enumerate computers that are Trusted for Delegation
Get-NetComputer -TrustedForDelegation | Select-Object Name, DistinguishedName, OperatingSystem

The output will list computer objects with the msDS-AllowedToDelegateTo attribute set to null, indicating unconstrained delegation.

Using Rubeus

Rubeus.exe computers /all /domain:corp.local /service:krbtgt

Rubeus will enumerate all computer accounts and annotate those with Trusted for delegation. The /service:krbtgt flag forces a KDC query that returns delegation flags.

Combine both tools for confidence. Export the list to a CSV for later automation:

Get-NetComputer -TrustedForDelegation | Export-Csv -NoTypeInformation ud_computers.csv

Requesting Service Tickets for Those SPNs

Once you have a list of vulnerable computer accounts, you need a valid TGT for one of them. If you already have a low-privilege user credential, you can request a forwardable TGT for the target computer using the runas or Rubeus asrep commands.

Obtain a TGT for the Delegating Computer

If you have the computer’s password hash (often harvested via Mimikatz or from LSASS), you can request a TGT directly:

Rubeus.exe asktgt /user:WEB01$ /password:Password123 /domain:corp.local /ptt

The /ptt flag injects the ticket into the current session, allowing subsequent Rubeus commands to act as that computer.

Request a Service Ticket for an Arbitrary SPN

Now that the delegating computer’s TGT is in memory, request a TGS for any SPN you wish to impersonate. Example: impersonate a Domain Admin’s krbtgt service (effectively a Golden Ticket) or a high-value service like SQL/SERVER01:

Rubeus.exe tgtdeleg /service:HTTP/webapp.corp.local /spn:HTTP/webapp.corp.local /ptt

The tgtdeleg module tells the KDC: “I am a trusted computer; give me a ticket for this SPN on behalf of the original user.” The KDC returns a forwardable TGS encrypted with the service’s key.

Extracting and Forging Tickets using Rubeus

Rubeus can also extract existing tickets from memory and modify them (ticket “golden” or “silver” attacks). Below we demonstrate extracting a TGT and forging a new ticket for a high-privilege account.

Extract a Ticket from LSASS

Rubeus.exe dump /output:dump.txt

This command dumps all Kerberos tickets for the current session. Look for a ticket with service:krbtgt belonging to a low-privilege user.

Forge a Ticket for Domain Admin

Assuming you have the KRBTGT account’s NTLM hash (often obtained via DCSync or NTDS.dit extraction), you can forge a Golden Ticket:

Rubeus.exe golden /user:Administrator /domain:corp.local /sid:S-1-5-21-1234567890-123456789-1234567890 /krbtgt:9e8f1b7a5c9d... /ptt

Explanation:

• /user - the account you want to impersonate.
• /sid - the domain SID (obtainable via whoami /all on a domain member).
• /krbtgt - the NTLM hash of the KRBTGT account.
• /ptt - inject the forged ticket.

After injection, you can run whoami /priv to confirm you now have Domain Admin privileges.

Silver Ticket for a Specific Service

If you only have the service account’s NTLM hash (e.g., SQLSvc), you can create a Silver Ticket targeting that service without touching the KRBTGT key:

Rubeus.exe silver /service:MSSQLSvc/sql01.corp.local:1433 /user:Administrator /domain:corp.local /rc4:5d41402abc4b2a76b9719d911017c592 /ptt

This ticket will be accepted by the SQL service, granting the attacker the privileges of the impersonated account on that specific service only.

Privilege Escalation to High-Privilege Accounts (e.g., Domain Admin)

With a forged ticket in hand, the attacker can now perform lateral movement or direct domain admin actions. Common post-exploitation steps include:

1. Domain enumeration: net user /domain and net group "Domain Admins" /domain to list high-value accounts.
2. Adding a new admin account: Use net user attacker /add /domain followed by net group "Domain Admins" attacker /add /domain.
3. Deploying persistence: Create a computer account with UD and add a scheduled task that runs a PowerShell web shell.
4. Credential dumping: Run Mimikatz with privilege::debug to harvest more hashes.

Because the ticket is fully trusted, any service that validates Kerberos tickets will accept the attacker’s impersonation.

Detection and Mitigation Strategies

Detection

• Audit Delegation Settings: Regularly query AD for trustedForDelegation and msDS-AllowedToDelegateTo. Any unexpected UD flag should raise an alert.
• Kerberos Event Logs: Look for Event ID 4769 (TGS request) with TicketEncryptionType = 0x17 (forwardable) originating from a computer account rather than a user.
• Rubeus/PowerView Alerts: Deploy Sysmon or Windows Event Forwarding rules that capture execution of Rubeus.exe, PowerView.ps1, or suspicious klist usage.
• Network Traffic: Monitor for unusual Kerberos traffic to the KDC from low-privilege hosts, especially requests for high-value SPNs.

Mitigation

1. Remove Unconstrained Delegation: Set msDS-AllowedToDelegateTo to a specific list of services or switch to Resource-Based Constrained Delegation (RBCD) where possible.
2. Enable Kerberos Armoring / FAST: Reduces the chance of ticket replay and forces stronger authentication.
3. Privileged Access Workstations (PAWs): Isolate administrative tasks to dedicated, hardened machines.
4. Strong Passwords & Rotation for Service Accounts: Prevent attackers from obtaining NTLM hashes that enable ticket forging.
5. Implement Tiered Admin Model: Keep high-value accounts (Tier 0) off of regular domain-joined workstations.

Common Mistakes

• Assuming UD is Rare: Many organizations still have legacy systems with UD enabled; always verify.
• Forgetting the Forwardable Flag: Without forwardable, the KDC will not issue a delegatable ticket, breaking the attack.
• Using the Wrong SPN Format: SPNs are case-sensitive and must match the AD entry exactly (e.g., MSSQLSvc/sql01.corp.local:1433).
• Neglecting Time Skew: Kerberos tickets are time-bound; ensure your machine clock is synchronized with the domain controller.
• Leaving Tickets in Memory: After a successful attack, clear the ticket cache with klist purge to avoid detection.

Real-World Impact

Unconstrained delegation abuse has been observed in several high-profile breaches, including the 2021 SolarWinds supply-chain attack where the attackers leveraged a mis-configured service account to move laterally across the network. In ransomware campaigns, threat actors often use UD to obtain Domain Admin tickets, enabling rapid encryption of critical assets.

From a defender’s perspective, the presence of UD is a single-point of failure: compromise of one computer account can compromise the entire forest. As organizations migrate to Zero-Trust models, the reliance on UD should be eliminated.

Expert tip: Automate the detection of UD via a PowerShell script that runs nightly and sends alerts for any new entries. Pair this with a configuration management database (CMDB) to cross-reference legitimate delegation requirements.

Practice Exercises

1. Lab Setup: Deploy a Windows Server 2019 AD environment with at least three computers. Mark WEB01 as Trusted for delegation via ADUC.
2. Enumeration: Use PowerView to list all UD-enabled computers. Verify the output matches the manually configured object.
3. Ticket Request: From a low-privilege user, use Rubeus to request a TGS for HTTP/webapp.corp.local using the delegating computer’s TGT.
4. Forge a Silver Ticket: Extract the NTLM hash of the SQLSvc service account and create a Silver Ticket for Administrator. Connect to the SQL service and run a simple query.
5. Detection: Configure Windows Event Forwarding to capture Event ID 4769. Trigger the attack and verify the alert fires.
6. Mitigation: Remove UD from WEB01 and replace it with RBCD. Re-run the enumeration to confirm it no longer appears.

Tools & Commands

Defense & Mitigation

Beyond the detection steps already mentioned, organizations should adopt the following hardening measures:

• Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment → "Impersonate a client" - limit which accounts can impersonate.
• Audit Policy: Enable Audit Kerberos Authentication Service and Audit Kerberos Service Ticket Operations to get granular logs.
• Privileged Access Management (PAM): Store high-value service account passwords in a vault and rotate them regularly.

Summary

• Unconstrained delegation allows a computer account to request Kerberos tickets for any service on behalf of any user.
• Identify vulnerable SPNs with PowerView or Rubeus; export the list for automation.
• Obtain a TGT for the delegating computer, then request forwardable TGS for target SPNs.
• Use Rubeus to extract existing tickets or forge Golden/Silver tickets using service or KRBTGT hashes.
• Escalate privileges to Domain Admin, add new privileged accounts, and maintain persistence.
• Detect abuse via Kerberos event logs, delegation audits, and monitoring for Rubeus/PowerView usage.
• Mitigate by removing UD, switching to constrained delegation, enforcing strong service account hygiene, and implementing tiered admin models.

Mastering this technique equips both attackers and defenders with a deep understanding of Kerberos trust relationships and how a single mis-configured attribute can compromise an entire forest.