What breaks when attackers can abuse Kerberos delegation in Active Directory environments?

Why Kerberos Delegation Becomes a Trust Break in Active Directory

Kerberos delegation is powerful because it lets a service act on behalf of a user, but that same trust shortcut becomes dangerous when an attacker controls the delegating account. The issue is not the protocol itself; it is the breadth of impersonation it can unlock once a foothold exists. In active directory, that can turn one compromised service identity into access to files, databases, and internal systems that were never directly exposed.

That is why delegation abuse is often treated as a privilege expansion problem rather than a simple authentication issue. The attacker does not need to break Kerberos cryptography to create damage; they need only reach a place where trusted impersonation is accepted. For teams trying to understand the blast radius, the real question is which services can request tickets or forward credentials in ways that bypass the intended separation between accounts.

NHIMG research shows how common identity overreach is in practice, with 97% of NHIs carrying excessive privileges, which helps explain why delegation weaknesses frequently become enterprise-wide exposure rather than isolated misconfiguration. In practice, many security teams discover delegation abuse only after a service account has already been used to impersonate a more privileged user.

How Delegation Abuse Expands Access in Practice

In a well-governed environment, delegation should be narrowly scoped, explicitly justified, and monitored because the service account is effectively borrowing user authority. When it is misconfigured, attackers can move from one compromised identity to another by asking the domain to trust an impersonated context. That is especially harmful when unconstrained delegation, overly broad constrained delegation, or resource-based constrained delegation is present without tight service ownership.

The practical failure chain usually looks like this:

• A service account or application server is compromised through a weak secret, exposed credential, or local privilege path.
• The attacker inspects delegation settings and identifies a trust path to higher-value users or services.
• They request or relay a ticket in a way that causes Active Directory to vouch for the target identity.
• They use the resulting access to query data, execute remote actions, or reach adjacent hosts.

This is why delegation abuse is often paired with lateral movement and privilege escalation. The immediate break is not just “someone can log in”; it is that the trust boundary between service identity and user identity has been weakened enough that access decisions stop reflecting real intent. Guidance from the MITRE ATT&CK Enterprise Matrix is useful here because it frames the post-compromise sequence attackers use to translate one credential into broader internal access. For identity-specific depth, the Ultimate Guide to NHIs — Key Challenges and Risks is a practical reference for why account scope, lifecycle, and visibility matter when machine trust is involved.

These controls tend to break down when legacy applications, shared service accounts, or exception-based delegation rules are left in place because the organisation can no longer tell whether the impersonation path is still required or still safe.

Common Failure Patterns and Edge Cases

Tighter delegation controls often increase operational overhead, so teams have to balance compatibility against impersonation risk. That tradeoff matters because not every environment can eliminate delegation outright, especially where application-tier authentication or tiered service flows depend on it.

One common edge case is that constrained delegation can still be dangerous if the target services are too broad or if the delegated account has more privilege than its role really needs. Another is resource-based constrained delegation, which shifts control to the resource owner but still requires disciplined review of which computers and services are allowed to speak for users. There is no universal standard for this yet across every enterprise pattern, so current guidance suggests treating every delegation exception as a standing trust relationship that needs explicit ownership and periodic review.

Another practical issue is visibility. Many defenders look for password changes and interactive logons, but delegation abuse can avoid those simple signals because the attacker is operating through legitimate ticket flows. The Ultimate Guide to NHIs — Why NHI Security Matters Now is relevant here because it underscores how quickly identity trust issues become enterprise risk when service identities are hard to inventory and even harder to govern.

Risk and Threat Considerations

Kerberos delegation abuse creates both privilege escalation risk and trust-abuse risk. Once an attacker controls a delegating account, the environment may accept impersonated access as legitimate, which turns one compromised identity into a pathway to higher-value systems, sensitive data, and persistence.

Failure mechanism: The weakness emerges when delegation scope is broader than intended, service accounts are overprivileged, or target services trust forwarded or substituted identity without enough restriction. An attacker exploits that trust chain to obtain tickets or access in the name of another user, often without needing to defeat the underlying authentication protocol.

Impact: The result can be lateral movement, unauthorized access to file servers or application back ends, and escalation toward domain-level reach if the delegated path connects to privileged workflows. It also weakens detection because activity may look like normal service-to-service operation rather than obvious compromise.

Practitioner Guidance

What to prioritise: Start with every service account or computer account that can delegate on behalf of users, then rank them by reachable privilege and business criticality. The highest-risk cases are the ones that can impersonate privileged users or reach tier-0 adjacent systems, because those paths turn a local compromise into domain-wide exposure.

What to verify: Confirm who owns each delegation relationship, which services genuinely require it, and whether the delegated target set is minimal. If the answer is “nobody knows,” treat that as an exception requiring immediate review, not as an acceptable legacy condition.

Decision rule: If a delegated identity can reach more systems than the human owner of that service would normally access, the control is already too permissive. In that case, reduce scope before chasing detection tuning, because the main issue is excess trust, not lack of alerts.

Practitioner takeaway: The core objective is not to eliminate delegation everywhere; it is to make sure any identity allowed to speak for users can do so only within a narrow, observable, and fully owned trust boundary.

Related resources from NHI Mgmt Group

• What breaks when attackers can create computer objects and abuse them to request certificates in Active Directory?
• What breaks when attackers steal directory signing keys or abuse Active Directory trust relationships?
• What breaks when RC4-only Kerberos accounts are migrated into AES-default Active Directory domains?
• Why does Kerberos delegation create such a large risk in Active Directory?