Kerberos Delegation Detection for SMB Blue Teams

If you have ever run BloodHound against a fifty-person company's domain and watched the shortest path to Domain Admin route straight through a dusty file server that somebody checked a box on in 2014, you already know where this post is going. Kerberos delegation is one of those Active Directory features that was built to solve a real problem, works exactly as designed, and still hands attackers a skeleton key when it is configured carelessly. Kerberos delegation detection is the blue-team discipline of knowing which accounts can impersonate other users, watching for the moment that capability gets abused, and catching the quiet directory changes that create new delegation rights out of thin air.

Earlier this year we spent two posts on the Netlogon zero-click problem and on domain controller monitoring after the Netlogon RCE. The natural follow-up question from readers was some version of "fine, we isolated tier 0, what does the attacker do next." The honest answer is that a competent operator stops attacking the domain controller directly and starts looking for accounts the domain controller already trusts to act on its behalf. That is delegation, and in most small and mid-sized environments nobody has looked at it since the server was built.

Why Kerberos delegation is the attack path after tier-0 isolation

Delegation exists because of the double-hop problem. A user signs in to a web application, and that web application needs to query a SQL Server or a file share as the user, not as itself, so that permissions on the back end still mean something. Kerberos solves this by letting the front-end service obtain tickets for the user and present them to the back-end service. Microsoft documents three flavors of this (see the Kerberos constrained delegation overview on Microsoft Learn), and every one of them amounts to the same control statement. This account is allowed to become other people.

From a CISSP point of view, that is a privileged function in the AC-6 sense, and it deserves the same treatment as membership in Domain Admins. From a CEH point of view, it is an impersonation primitive that requires no password cracking, no exploit, and no malware with a scary name. The attacker is simply using Kerberos the way Kerberos was told to behave. That is exactly why it slips past endpoint tooling. EDR is very good at spotting a weird process tree. It is much less good at noticing that a service ticket was legitimately issued to a legitimately configured account for a user who happened to be the domain administrator.

MITRE files most of this under T1558, Steal or Forge Kerberos Tickets, with the follow-through landing in T1550.003 Pass the Ticket and, when a domain controller's ticket is captured, T1003.006 DCSync. The joint CISA, NSA and Five Eyes guidance on detecting and mitigating Active Directory compromises published in September 2024 calls out unconstrained delegation by name as one of the techniques defenders should be hunting, which is a polite government way of saying it keeps showing up in incident reports.

Unconstrained delegation turns one server into a ticket vending machine

Unconstrained delegation is the original 2000-era model, and it is the one that should make you wince. When a computer or service account has the TRUSTED_FOR_DELEGATION flag set in its userAccountControl attribute, any user who authenticates to a service on that host sends along a copy of their ticket-granting ticket. Windows caches that TGT in LSASS so the service can request tickets to anything else in the domain as that user. Anything else, anywhere, with no restriction.

Now put on the attacker hat. Compromise a host with unconstrained delegation and every ticket-granting ticket that lands there is yours to extract and replay. Waiting for a domain admin to wander by is slow, so the modern playbook does not wait. Lee Christensen's printer bug showed years ago that the MS-RPRN print spooler protocol can coerce a domain controller into authenticating to an arbitrary host, and PetitPotam (CVE-2021-36942) did the same thing through MS-EFSRPC. Point that coercion at your unconstrained delegation server, catch the domain controller's own TGT as it arrives, and run DCSync to pull every password hash in the directory. The whole chain takes minutes, and the only exploit involved is a design feature behaving as documented. That is T1187 forced authentication followed by T1558 followed by T1003.006, and if you are keeping score at home, nobody had to phish anybody.

Domain controllers have unconstrained delegation by design, so they are not the finding. The finding is the member server that has it. In the environments we assess around Plano and Frisco, the usual suspects are an old IIS box that once fronted a SharePoint farm, a Citrix or Remote Desktop broker configured by a contractor who has since moved to Montana, or a SQL Server where someone ticked "Trust this computer for delegation to any service" because the wizard made the error message go away. None of those servers need it today. All of them still have it.

Constrained and resource-based constrained delegation fail in quieter ways

Microsoft introduced constrained delegation in Windows Server 2003 to fix the obvious problem. Instead of trusting a service to go anywhere, you list the specific service principal names it may delegate to in the msDS-AllowedToDelegateTo attribute. The service uses two Kerberos extensions, S4U2Self to get a ticket for a user to itself and S4U2Proxy to forward that ticket to the allowed back end. Better, but not bulletproof. If protocol transition is enabled (the TRUSTED_TO_AUTH_FOR_DELEGATION flag), the service can mint a ticket for any user without that user ever authenticating. Compromise the service account's credentials and you can impersonate the domain administrator to every back-end service on the list. Worse, the service name portion of the ticket is not cryptographically bound to the request, so a ticket issued for one service class on a target host can often be rewritten to another service class on the same host. A delegation right that was supposed to grant access to a SQL listener can turn into file share or remote management access on that machine.

Resource-based constrained delegation, introduced in Server 2012, flipped the model around. The back-end resource holds an attribute called msDS-AllowedToActOnBehalfOfOtherIdentity that says which accounts may delegate to it. That sounds like healthy decentralization until you remember who can write to a computer object. Elad Shamir's 2019 research, widely known as "Wagging the Dog," laid out the path in detail. Any principal with write access to a computer object can set that attribute. The default ms-DS-MachineAccountQuota of 10 lets any authenticated user create up to ten computer accounts, which gives the attacker an account with a known password and an SPN. Configure the target to trust the attacker's new machine account, run S4U2Self and S4U2Proxy, and the attacker is now an administrator on the target host. KrbRelayUp packaged a version of this into a local privilege escalation tool in 2022, and the Bronze Bit flaw (CVE-2020-17049) showed that even the forwardable flag and the "sensitive and cannot be delegated" protections could be bypassed on unpatched domain controllers.

The theme across all three flavors is the same. Delegation abuse rarely looks like an attack in the logs. It looks like a directory attribute changing, a computer account being created, and a service ticket being issued. Those are things that happen in a healthy domain every day, which is why Kerberos delegation detection has to be built on purpose rather than hoped for.

Kerberos delegation detection starts with knowing what is configured

You cannot alert on abuse of a capability you have not inventoried. The first piece of work is a census of every account in the directory that can delegate, every resource that accepts delegation, and every privileged account that is still eligible to be impersonated. This is a CM-8 and AC-2 exercise wearing a Kerberos costume, and it takes an afternoon with the ActiveDirectory PowerShell module.

# Unconstrained delegation (exclude domain controllers by hand)
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation
Get-ADUser -Filter {TrustedForDelegation -eq $true}

# Constrained delegation and protocol transition
Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo,TrustedToAuthForDelegation

# Resource-based constrained delegation
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity | Where-Object {$_."msDS-AllowedToActOnBehalfOfOtherIdentity"}

# Machine account quota
Get-ADObject (Get-ADDomain).DistinguishedName -Properties ms-DS-MachineAccountQuota

Run that, save the output with a date in the filename, and treat it as your baseline. Every line that returns should map to a named owner and a business reason. In our experience the first run on an SMB domain returns somewhere between two and a dozen results, and the honest business reason for at least half of them is "nobody remembers." Those are the first candidates for removal, because the cheapest delegation alert is the one you never have to write.

The second half of the census is the inverse question. Which privileged accounts can still be delegated? Domain Admins, Enterprise Admins, the accounts that run backup and identity sync, and any break-glass account should all carry the "Account is sensitive and cannot be delegated" flag or sit in the Protected Users group. Protected Users blocks delegation of its members outright, along with NTLM and weaker Kerberos encryption types, which is why Microsoft and CISA both recommend it for tier-0 humans. Test it on one account first. Protected Users breaks things that rely on cached credentials, and finding that out on the CEO's executive assistant is a memorable way to learn.

Then schedule the census to run again. A baseline is only useful if you diff against it, and the diff is where a quiet RBCD change shows up long before anything else does.

The events that actually catch delegation abuse

With the inventory in hand, detection becomes a much more tractable problem. The signals live almost entirely on domain controllers, and most of them are already being generated if your audit policy is sane. The trick is knowing which fields to look at and forwarding the logs somewhere an attacker with domain admin cannot edit them, which is an AU-9 requirement rather than a nice-to-have.

The highest-value signal for resource-based constrained delegation abuse is Event ID 5136, a directory service object modification, when the attribute being written is msDS-AllowedToActOnBehalfOfOtherIdentity. That event only appears if Audit Directory Service Changes is enabled and the computer objects carry a SACL that audits writes, which is the step most environments skip. In a typical SMB domain, legitimate writes to that attribute happen a handful of times a year at most. Any write outside a change ticket deserves a human looking at it within the hour. Pair it with Event ID 4741, a computer account being created, and pay special attention when the creator is an ordinary user account rather than a provisioning service. A regular user creating a machine account and that same machine account appearing in a delegation attribute twenty minutes later is about as close to a confession as Active Directory logs ever get.

For constrained and unconstrained delegation, Event ID 4742 and Event ID 4738 record changes to computer and user accounts respectively, including changes to userAccountControl and the AllowedToDelegateTo list. Diff those against your baseline. A new TRUSTED_FOR_DELEGATION flag on a member server should page someone, full stop. The flag value 0x80000 is unconstrained delegation and 0x1000000 is protocol transition, so a SIEM rule that watches for either bit appearing in a change event is a short piece of logic with a very low false positive rate.

The ticket-level evidence lives in Event ID 4769, a Kerberos service ticket request. When S4U2Proxy is in play, the Transited Services field is populated with the identity of the delegating account. That gives you a clean pivot. Build a list of service tickets where Transited Services is not empty, then compare the delegating account against your approved inventory and compare the impersonated user against your privileged groups. An approved front-end server delegating for ordinary users to its approved SQL back end is normal. A machine account created last Tuesday delegating on behalf of the domain administrator to the CIFS service on a file server is not. Watching 4769 for tickets requested for privileged users by accounts that are not on the delegation baseline catches a large share of the S4U abuse techniques without needing any specific tool signature.

Unconstrained delegation abuse needs one more angle, because the capture happens in memory on the compromised host. The useful tell is the coercion that precedes it. Watch for domain controllers making outbound authentications to member servers over the print spooler or EFSRPC named pipes, and for a domain controller's computer account showing up in Event ID 4624 logons on a non-DC host. Then watch for the follow-through, which is directory replication requests (Event ID 4662 with the replication GUIDs) coming from anything that is not a domain controller. Disabling the print spooler on domain controllers, as Microsoft has recommended since PrintNightmare, removes the most popular coercion vector entirely and makes this whole chain noisier for the attacker.

Microsoft Defender for Identity and similar identity threat detection tools ship analytics for several of these patterns, and they are worth turning on if you are licensed for them. They are not a substitute for owning the inventory and the raw events, though, because the most dangerous delegation abuse is the kind that uses an account your tool has already learned to consider normal.

Controls that shrink the blast radius before the SOC has to

Detection buys time. Configuration removes the opportunity. A good Active Directory hardening pass against delegation attack paths is short and mostly free, which is a rare sentence to write in this industry.

Set ms-DS-MachineAccountQuota to zero and delegate computer-join rights to a specific provisioning group instead. That single change kills the most common resource-based constrained delegation chain because the attacker can no longer manufacture a machine account with a known password. Remove unconstrained delegation from every member server that does not have a documented, current need, and convert the few that do to constrained delegation scoped to the exact back-end SPN. Turn off protocol transition unless the application genuinely requires it. Put tier-0 humans in Protected Users and flag every privileged service account as sensitive and not delegatable. Make sure your domain controllers carry the November 2020 and later Kerberos updates that close Bronze Bit and enforce the PAC validation changes Microsoft has rolled out since, because a lot of SMB domains are still running enforcement in compatibility mode out of caution that nobody revisited.

Tighten write permissions on computer objects while you are in there. The resource-based delegation attack depends on an attacker controlled principal having GenericWrite, GenericAll, WriteProperty or WriteDACL on the target computer. BloodHound will show you exactly where those edges are, and in our experience they cluster around helpdesk groups that were given broad rights over workstation OUs years ago to make imaging easier. Narrow those rights to the specific attributes the helpdesk actually needs. Nobody on the helpdesk needs to edit msDS-AllowedToActOnBehalfOfOtherIdentity.

None of this replaces monitoring. It changes what monitoring has to catch. A domain with zero machine account quota, no member servers trusted for unconstrained delegation and every privileged account flagged as non-delegatable reduces the delegation attack surface to a short list of approved paths. At that point every alert from the events above is either a change ticket you can match or an incident you need to work.

What a good response looks like at 3 AM

Suppose the 5136 rule fires at 3:12 on a Saturday morning. A computer object for a file server in your Allen office just had its delegation attribute written, and the account doing the writing is a regular user whose laptop has been signed in since Friday afternoon. A mature response does three things quickly. It confirms there is no change ticket, which takes a minute. It checks for a matching 4741 from the same user and for 4769 tickets where that new machine account appears in Transited Services, which tells you whether the attacker has already used the path or only built it. Then it contains, which means clearing the attribute, disabling the rogue machine account, resetting the user's credentials and pulling the laptop off the network for triage.

If the 4769 search shows tickets were issued, the scope widens. You now assume administrative access to the file server was obtained, and you hunt for what happened there next. That is the moment where log retention, off-box forwarding and a written playbook decide whether the weekend ends with a contained incident or a call to the cyber insurance carrier. It is also the moment where a small internal IT team, however talented, discovers that nobody was assigned to watch the SIEM on Saturday.

Closing the delegation gap for good

Kerberos delegation detection is not glamorous work. It is an inventory, a handful of audit settings, four or five well-written SIEM rules and somebody awake to read them. It also happens to break one of the most reliable Active Directory attack paths an operator has once they discover your domain controllers are patched and isolated. The defenders who do this well are not the ones with the most expensive tools. They are the ones who know exactly which accounts are allowed to impersonate whom, and who notice within minutes when that list changes.

This is the kind of quiet, identity-centric telemetry that the Managed SOC module inside CyberSphere was built to watch. The Threat Management side of the platform ingests domain controller events, tracks changes to delegation attributes and machine accounts against a known-good baseline, and routes a suspicious S4U ticket or an unexpected RBCD write to an analyst around the clock, with the resulting remediation ticket tied back to the AC-6 and AU-6 controls that justified watching it in the first place. MSPs can deliver the same capability under their own brand through the white-label partner portal. The platform lives at https://cybersphere.thecyberone.com/, and for teams in McKinney and across DFW it is a practical way to make sure the next delegation change gets read before Monday. Run the census this week, because the attacker who finds your forgotten delegation server will not be waiting for a maintenance window.

Frequently Asked Questions

How quickly does Innovation Network Design respond to a security incident?

Our SOC triages and notifies within 15 minutes with confirmed details and containment steps, rather than handing you a queued alert. Incident response retainer clients carry a 2-hour guaranteed response.

Do you only work with businesses in the Dallas-Fort Worth area?

We are based in McKinney, Texas and work on-site across Plano, Allen, Frisco and the wider DFW metroplex. Our monitoring and response operate remotely, so we also support organizations nationwide.

How do we get started?

Start with a free assessment. Contact us or call 512-518-4408 and we will review your current setup and give you clear, prioritized recommendations before you commit to anything.