What are the signs that Kerberos delegation is being abused in a Windows domain?

Look for services using unconstrained delegation, unexpected delegation flags on service accounts, and tickets being issued for users that should not be delegable. Packet size changes, modified ticket fields, and suspicious S4U2Self or S4U2Proxy activity can also indicate tampering or misuse. In practice, abnormal delegation patterns matter more than a single event because abuse often blends into normal authentication traffic.

How Kerberos delegation abuse shows up in a Windows domain

Abuse is usually visible as a mismatch between how delegation is configured and how tickets are actually being requested. That means the most useful signals are not isolated events, but sequences: delegation-capable services appearing where they should not, unexpected forwardable tickets, and service-ticket requests that do not fit the account’s normal role or host relationship.

In practice, defenders should pay attention to where delegation is enabled, which accounts can use it, and whether the ticket flow matches the service topology. A sudden change in those relationships often matters more than a high volume of authentication noise, because attackers try to blend delegation abuse into legitimate Windows traffic.

Unconstrained delegation on servers that do not need it, especially if the host sits on a sensitive network segment.
Delegation flags added to service accounts without a corresponding application change or change ticket.
Kerberos tickets being issued for users, hosts, or services that are not normally part of the delegated path.
Signs of S4U2Self or S4U2Proxy requests that do not align with the application’s expected behaviour.
Ticket field changes, unusual packet sizes, or other protocol-level deviations that suggest tampering or scripted misuse.

Why the abuse pattern is easy to miss

kerberos delegation abuse often looks like ordinary authentication because it uses standard protocol flows rather than a noisy exploit chain. The abuse becomes visible when the same delegation mechanism is used at the wrong time, by the wrong account, or against the wrong target, such as a service obtaining access on behalf of users it should never be able to impersonate.

That makes context essential. A single S4U event or a single forwarded ticket is not automatically suspicious. What matters is whether the delegation path is consistent with the service’s purpose, whether the account should be trusted to delegate, and whether the observed ticket issuance matches the normal application dependency graph.

Compare current delegation paths with approved application design and directory configuration.
Watch for delegation on privileged or high-value servers, because those hosts expand the blast radius if abused.
Treat repeated ticket requests for unusual user-service combinations as stronger evidence than one-off noise.

Risk and Threat Considerations

Delegation abuse is risky because it can turn one compromised service account into broader impersonation capability across the domain. If an attacker controls a delegated service, they may be able to request access on behalf of users, including privileged users, and then move laterally while appearing to use legitimate Kerberos traffic.

Failure mechanism: The control fails when a service is trusted to delegate more broadly than its business function requires, or when ticket requests are accepted without enough monitoring of who is being impersonated and why.

Impact: A single abused delegation path can lead to privilege escalation, lateral movement, and access to resources that were never intended to be reachable from the originating service.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	DE.CM-1 — Monitor security events	Delegation abuse is detected through abnormal Kerberos event patterns and protocol deviations.
	PR.AC-4 — Access permissions and authorizations	Abuse depends on excessive or misapplied delegation permissions on services and accounts.
	PR.AC-6 — Identity proofing and authentication	Kerberos delegation abuse exploits trust in authenticated identities and ticket flows.
Recommendation — Monitor Kerberos and directory events for unexpected delegation activity and ticket issuance anomalies. Restrict delegation rights to the minimum required service accounts and hosts. Validate that delegated authentication paths only exist where the business service requires them.
CIS Controls v8	5.1 — Establish and Maintain an Inventory of Accounts	Abuse detection depends on knowing which service accounts can delegate and where.
	6.3 — Promptly Revoking Access	Once delegation is abused, the trusted account or host must be rapidly removed from the path.
	8.2 — Audit Log Management	Kerberos delegation misuse is identified by correlating ticket and authentication logs.
Recommendation — Inventory delegation-capable service accounts and review changes to their trust settings. Revoke or disable delegation for compromised or unnecessary service accounts immediately. Collect and review Kerberos ticketing logs for unusual S4U and delegation patterns.
MITRE ATT&CK	T1134 — Access Token Manipulation	Delegation abuse uses impersonation and token-like trust to act on behalf of other users.
	T1558 — Steal or Forge Kerberos Tickets	Kerberos delegation abuse is closely related to ticket misuse, forging, and abuse of Kerberos trust.
Recommendation — Hunt for impersonation abuse and correlate delegated access with subsequent lateral movement. Inspect Kerberos ticket anomalies and investigate ticket-origin changes that indicate abuse.
OWASP Non-Human Identity Top 10	NHI-03 — Authorization and Least Privilege	Delegation abuse is an over-authorization problem where services can act beyond their intended scope.
Recommendation — Apply least privilege to delegation rights and remove unnecessary trust relationships.

Practitioner Guidance

What to verify: Confirm that every delegation-enabled account and host has a documented business need, and that unconstrained delegation is not present by default on servers that can reach sensitive systems.

What to measure: Baseline normal Kerberos service patterns for each delegated service, then flag deviations in forwardable tickets, S4U2Self and S4U2Proxy volume, and destination services that are outside the expected application path.

Common mistake: Teams often watch for failed logons and miss delegated success paths. Abuse may never trigger obvious authentication failures, so detection needs to focus on relationship changes, not only on login outcomes.

Practitioner takeaway: The best signal is not “Kerberos is happening”, it is “delegation is happening in a way that no longer matches the service’s approved trust boundary.”