Unconstrained Delegation: Exploiting Active Directory Flaws for Domain Takeover
Learn how attackers exploit unconstrained delegation, a severe Active Directory misconfiguration, to steal domain admin credentials and take over the corporate network.
In the vast majority of enterprise environments, Microsoft Active Directory (AD) is the central nervous system governing identity and access. If an attacker compromises Active Directory, they hold the keys to the entire corporate kingdom. While much of the cybersecurity industry focuses on zero-day exploits and malware, seasoned Red Team operators and advanced threat actors often prefer a quieter, highly devastating approach: exploiting inherent architectural misconfigurations.
One of the most dangerous and historically prevalent misconfigurations within Active Directory is Unconstrained Delegation. It is an authentication setting that, when enabled on a server or a service account, creates a catastrophic security vulnerability. If an attacker manages to compromise a single machine configured with unconstrained delegation, they can often escalate their privileges to Domain Admin in a matter of minutes, granting them total control over the network.
This article dissects the technical mechanics of Kerberos delegation, explains why the "unconstrained" variant is so incredibly dangerous, walks through the anatomy of an attack exploiting this flaw, and details the necessary steps to detect and mitigate this critical Active Directory vulnerability.
The Problem: The Kerberos Double-Hop
To understand delegation, we must first understand the problem it was designed to solve: the "Double-Hop" problem in Kerberos authentication.
Imagine a typical three-tier enterprise application.
- A user (Alice) logs into a front-end web application (Hop 1).
- The web application needs to fetch Alice's specific financial records from a back-end SQL database server (Hop 2).
Under the standard Kerberos authentication protocol, when Alice authenticates to the web server, the web server knows she is Alice. However, when the web server subsequently connects to the SQL database on Alice's behalf to fetch her records, the SQL database only sees the web server connecting, not Alice. The SQL database cannot verify if Alice actually has permission to view those specific records.
To solve this, the web server needs the ability to "impersonate" Alice when communicating with the back-end database. This impersonation capability is known as Delegation.
The Flaw: What is Unconstrained Delegation?
When Microsoft first introduced delegation in Windows 2000, they implemented it in the simplest way possible: Unconstrained Delegation.
When a computer account (like the front-end web server) is configured with unconstrained delegation in Active Directory, it is granted a terrifying level of trust. When any user (Alice) authenticates to that web server using Kerberos, the Domain Controller (KDC) places a copy of Alice's Ticket Granting Ticket (TGT) inside the service ticket sent to the web server.
The web server then extracts Alice's TGT and stores it in its own Local Security Authority Subsystem Service (LSASS) memory.
A TGT is the ultimate Kerberos credential. It is essentially the cryptographic equivalent of Alice's password. With Alice's TGT, the web server can request access to any service on the entire network, masquerading perfectly as Alice. It is not limited to just the back-end SQL database; it is completely unconstrained.
The Anatomy of the Attack
The danger arises when an attacker compromises a server that has unconstrained delegation enabled. The attack generally follows three distinct phases.
Phase 1: Identifying the Target
The attacker, having gained a low-level foothold in the network, first needs to locate machines with this misconfiguration. They query Active Directory (using tools like PowerView or BloodHound) looking for computer accounts or user accounts where the userAccountControl attribute contains the TRUSTED_FOR_DELEGATION flag.
Phase 2: Coercing Authentication
Once the attacker compromises a server with unconstrained delegation (for example, achieving local admin rights on the web server), they sit and wait for a highly privileged user—like a Domain Admin—to log into that server. When the Domain Admin logs in, their precious TGT is stored in the server's memory.
However, attackers are rarely patient. Instead of waiting, they actively force a Domain Admin account (or the Domain Controller computer account itself) to authenticate to their compromised server.
They achieve this using coercion techniques. A famous example is the Printer Bug (exploiting the MS-RPRN protocol) or PetitPotam (exploiting MS-EFSRPC). Using these tools, the attacker can force the primary Domain Controller to connect to the compromised web server.
Phase 3: Harvesting and Passing the Ticket
Because the web server has unconstrained delegation enabled, when the Domain Controller is forced to authenticate to it, the Domain Controller inadvertently sends its own highly privileged TGT, which is cached in the web server's memory.
The attacker, holding local admin rights on the web server, utilizes a credential dumping tool like Mimikatz. They execute the command sekurlsa::tickets /export to extract all the Kerberos tickets currently held in the LSASS memory, specifically hunting for the newly arrived Domain Controller TGT.
Once the attacker possesses the Domain Controller's TGT, it is game over. They inject that TGT into their own current session (a technique known as Pass-the-Ticket). The attacker can now perform DCSync attacks to dump the password hashes of every single user in the domain, or instantly create Golden Tickets to establish permanent, undetectable persistence.
Moving Toward Secure Delegation
Because unconstrained delegation represents such an immense security risk, Microsoft introduced safer alternatives in subsequent versions of Windows Server. Organizations must aggressively migrate away from the unconstrained model.
1. Constrained Delegation
Introduced in Windows Server 2003, Constrained Delegation limits the scope of the impersonation. When configuring the web server in AD, the administrator explicitly defines exactly which back-end services the web server is allowed to impersonate users to (e.g., only the specific SQL database service on a specific server). If the web server is compromised, the attacker cannot use the cached credentials to access the Domain Controller or any other unauthorized service. Furthermore, Constrained Delegation typically utilizes Service for User to Proxy (S4U2proxy), which does not require storing the user's TGT in memory.
2. Resource-Based Constrained Delegation (RBCD)
Introduced in Windows Server 2012, RBCD flips the configuration model. Instead of configuring the front-end web server to specify where it can delegate to, the back-end resource (the SQL database) is configured to specify who is allowed to delegate to it. This provides much more granular security and prevents attackers from abusing legacy delegation paths.
Detection and Mitigation Strategies
Securing Active Directory against this threat requires a proactive approach.
- Audit and Remove: The most critical step is auditing the environment. Security teams must query AD for any accounts with the
TRUSTED_FOR_DELEGATIONflag set to true (excluding Domain Controllers, which require it by design). Organizations should actively migrate these accounts to Constrained or Resource-Based Constrained Delegation and disable the unconstrained setting. - Protect Highly Privileged Accounts: For sensitive accounts like Domain Admins, administrators should enable the "Account is sensitive and cannot be delegated" flag in AD. This ensures that even if a Domain Admin accidentally logs into a compromised server with unconstrained delegation, their TGT will not be forwarded and cached in memory.
- Monitor Coercion Attempts: EDR and Network Traffic Analysis (NTA) tools should monitor for anomalous RPC traffic targeting Domain Controllers, which is often indicative of authentication coercion attacks like PetitPotam or the Printer Bug.
- Tiered Administration: Implement Microsoft's Tiered Administration model. Domain Admins (Tier 0) should never log into lower-tier servers (Tier 1/Tier 2) where unconstrained delegation might be enabled, structurally preventing their credentials from being exposed.
Unconstrained Delegation is a relic of early network architecture that poses an existential threat to modern Active Directory environments. It transforms a relatively minor breach of a single member server into an immediate, domain-wide catastrophe by handing attackers the keys to the kingdom via cached Ticket Granting Tickets.
Red Teams and ransomware operators actively hunt for this misconfiguration because it is a silent, built-in feature that evades traditional malware detection. Defending against this requires organizations to proactively audit their Active Directory structure, ruthlessly eliminate unconstrained delegation configurations in favor of constrained alternatives, and strictly enforce the principle of least privilege for administrative accounts. In the realm of AD security, architectural hygiene is the strongest defense.
Ready to test your knowledge? Take the Unconstrained Delegation MCQ Quiz on HackCert today!
Related articles
AD Trusts: How Hackers Weaponize Network Trust to Hijack Systems
8 min
AS-REP Roasting: Hacking Techniques to Gain Access to Kerberos Accounts Without Passwords
8 min
BloodHound Analysis: Analyzing Active Directory Vulnerabilities from a Hacker's Perspective
12 min
Constrained Delegation: Security Risks and Solutions in Active Directory
12 min