Kerberos Referral Ticket

What a referral ticket is doing in Kerberos

A referral ticket is not the final proof used to reach a service. It is an intermediary Kerberos ticket that lets a client move from one trusted realm or domain controller to the next step in the trust path, so authentication can continue across domains without restarting the exchange from scratch.

This makes referral tickets a routing mechanism as much as an authentication object. In a healthy environment, they reduce friction across forests, domains, and trust boundaries; in a hostile environment, they can become part of the path an attacker follows to move laterally through trusts.

Why referral tickets matter in cross-domain authentication

Kerberos depends on trust relationships between realms, and referral tickets are how the protocol hands off from one realm to another. The ticket tells the client where to ask next for a service ticket, which is why the object is central to cross-domain single sign-on and enterprise trust chaining.

That same handoff is also why defenders care about trust scope. If an attacker can influence the ticket path or reuse a valid ticket in the wrong context, the trust boundary may be weaker than it appears on paper. This is especially important in environments with multiple domains, forest trusts, or legacy configurations where Kerberos paths are complex.

For a broader view of the ticket-forgery and ticket-theft techniques that defenders group around this behavior, see the MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide.

How misuse turns a routing ticket into an attack path

Referral tickets become dangerous when they are abused as a bridge into domains the principal should not effectively reach. The security issue is not the referral itself, but the combination of trust, reachability, and forged or replayed ticket material that can let an attacker request additional service tickets after the first foothold.

That is why referral-ticket abuse is usually discussed alongside golden tickets, silver tickets, pass-the-ticket, and DCSync. The attacker is not trying to “break Kerberos” in one move, but to exploit the protocol’s trust choreography so that a legitimate-looking ticket flow produces unauthorized access downstream.

Defenders often validate that picture against the operational mechanics of forgery and trust abuse in the Golden Ticket, Silver Ticket and DCSync Guide, which explains how forged tickets and replication abuse intersect with Kerberos trust paths.

What defenders should inspect when referral-ticket abuse is suspected

Exposure checks start with the trust graph, not with the packet trace. Teams should know which domains trust each other, which systems are domain controllers, where service tickets are being requested across boundaries, and whether the observed path matches the business need. In practice, that means correlating directory trust configuration, ticket events, and the systems that are actually issuing or accepting referrals.

Detection is strongest when you look for unusual cross-realm ticket activity, unexpected service-ticket requests, and Kerberos events that do not fit the normal domain topology. Referral misuse rarely looks like a single signature on its own; it is usually a pattern of legitimate protocol use occurring in the wrong place, at the wrong frequency, or from the wrong principal.

A practical defender’s reference for this wider Kerberos detection and hardening context is the Kerberos Security Guide, which covers detection, krbtgt hygiene, and related Kerberos abuse paths.

Why remediation is mostly about trust boundaries and ticket hygiene

When referral-ticket abuse is possible, the response is usually to reduce trust reach and remove the attacker’s ability to keep moving. That may include tightening trust relationships, reviewing delegation paths, restricting who can request cross-domain services, and validating whether Kerberos encryption and domain controller hygiene still meet current security expectations.

If compromise is suspected, responders should also consider the identity impact, not just the host impact. Kerberos abuse can expose service accounts, cached tickets, and long-lived trust assumptions that outlast a single endpoint compromise. In serious cases, the right question is not only whether a ticket was forged, but whether the trust chain and related secrets need to be revalidated or rotated.

For the recovery side of Kerberos trust abuse, krbtgt account is the most direct operational reference, because the integrity of Kerberos ticket issuance depends on that account’s protection and reset discipline.

Related resources from NHI Mgmt Group

• What is the difference between a normal Kerberos ticket issue and a Golden Ticket attack?
• Who is accountable for monitoring suspicious Kerberos ticket requests across forest trust paths?
• Who is accountable for limiting the impact of Kerberos ticket theft?
• What is the difference between protecting Windows logon with MFA and protecting the underlying Kerberos ticket request?