How do attackers use Constrained Delegation?

How Constrained Delegation Becomes an Attack Path

constrained delegation is a Kerberos feature that lets a trusted service obtain tickets to specific back-end services on a user's behalf. Attackers use it by compromising the service account that holds that delegated trust, then abusing its ability to request service tickets and impersonate users within the services it is allowed to reach. The abuse is narrower than unconstrained delegation, but still powerful when the account is trusted broadly enough.

The practical danger is that the attacker does not need to break Kerberos itself, they only need control of the delegated account or its Kerberos material. Once they have that, the service can be turned into an impersonation bridge into selected back-end systems, especially where the delegation scope is long-lived, poorly reviewed, or granted to accounts with excessive service reach.

What Attackers Actually Do After They Get the Account

After compromise, attackers typically use the delegated service to request tickets for target services that the account is already authorised to access. That lets them act as another user to those back-end systems without needing the user’s password, as long as the delegation path and service permissions allow it. The technique is attractive because it blends into normal service-to-service authentication traffic.

In environments with weak service account hygiene, the attacker may also reuse the same trust path for lateral movement. A single delegated identity can unlock multiple application back ends, file services, or administrative interfaces if the delegation configuration is broader than the business need. Reviewing delegation scope and service ownership is therefore part of attack-path reduction, not just account housekeeping.

For a deeper view of the mechanics and related abuse patterns, see Kerberos Delegation Security Guide and the broader service-account abuse patterns in The State of NHI & AI Agent Breach Report 2026.

Why Delegation Abuse Is Hard to Spot

Constrained Delegation abuse often looks like legitimate application behaviour because the service is expected to request tickets on behalf of users. That makes detection depend on baseline knowledge: which service accounts should delegate, to which back-end services, and from which hosts or application tiers. If you do not know the expected delegation paths, suspicious ticket requests are easy to miss.

Suspicion rises when a service starts requesting tickets outside its normal scope, when delegation settings change unexpectedly, or when a compromised account is used from an unusual source system. Review of Kerberos delegation configuration should be paired with monitoring for anomalous service-to-service ticket requests and unexpected impersonation patterns. That is where constrained delegation shifts from a useful feature to an abuse path.

Risk and Threat Considerations

Constrained Delegation creates a high-value trust relationship: if the trusted service account is compromised, the attacker inherits its ability to obtain tickets for selected back-end services. The risk is not just account takeover, but delegated impersonation at the application layer, which can expand access well beyond the original foothold.

Failure mechanism: The attacker steals or otherwise gains control of the delegated service account, then uses its Kerberos delegation rights to request tickets and act on behalf of users to the approved back-end services.

Impact: The attacker can reach sensitive services through a legitimate trust path, reduce detection fidelity, and potentially move laterally inside the application tier without needing user credentials.

Practitioner Guidance

What to verify: Confirm which service accounts are trusted for delegation, which back-end services they can reach, and whether that scope still matches the application design. If the trust list is broader than the service function, treat that as an exposure issue, not a documentation issue.

What to prioritise: Protect the delegated service account first, because control of that identity is control of the delegation path. Then reduce the number of systems that can accept delegated tickets from it, and remove delegation from any account that no longer needs it.

What good looks like: Each delegated service has a narrowly defined purpose, a reviewed trust scope, strong monitoring around ticket requests, and clear ownership for any exception. The best outcome is not zero delegation, but delegation that is sparse, bounded, and observable.

Practitioner takeaway: Treat Constrained Delegation as an access amplifier, if the service account is compromised, the blast radius follows the delegation trust you granted, not just the initial account.

Related resources from NHI Mgmt Group

• Guide: Active Directory and Entra ID Hardening Guide
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?