Kerberos TGS-REQ

What Kerberos TGS-REQ Does in the Ticket Flow

Kerberos TGS-REQ is the message that moves the authentication flow from proving a user once to obtaining a service-specific ticket for later access. It is a protocol step, not a password exchange, and it is what lets Kerberos extend the original login into a usable ticketing sequence for applications and services.

Because the request is bound to an existing ticket-granting ticket, the client can ask for access to a particular service without re-sending the user’s secret. That design is central to Kerberos trust, but it also means the integrity of the ticketing path matters as much as the initial login.

What the Request Contains and Why It Matters

A TGS-REQ typically includes the client’s ticket and an authenticator. Together, those elements let the Ticket Granting Service verify that the request is fresh, that it comes from the same client that holds the ticket, and that the request is tied to a specific service principal. This is how Kerberos avoids exposing the password again while still proving continuity of identity.

The request format is important because it is the handoff point between authentication and service authorization. If the ticket or authenticator is stolen, replayed, or forged, the attacker is no longer trying to guess a password, but to reuse a trusted Kerberos artifact to obtain downstream access.

Where TGS-REQ Sits in the Kerberos Trust Model

TGS-REQ depends on the Key Distribution Center and its trust in the client’s earlier authentication state. The KDC does not treat the request as an isolated packet, it evaluates it against the ticket, the authenticator, and the target service principal before issuing a service ticket. That makes the exchange a controlled bridge between identity proofing and application access.

In practice, this step is also where service boundaries become visible. Each request is for a specific service principal, so the protocol naturally supports scoped access rather than blanket reuse of the original login. When that scoping is weak, misconfigured, or abused, Kerberos can become a path to lateral movement instead of a containment mechanism.

Common Failure Modes and Operational Meaning

TGS-REQ problems often show up as service access failures, time skew issues, ticket misuse, or unexpected ticket requests. Because the exchange is time-sensitive and depends on valid Kerberos material, small integrity errors can prevent legitimate access while also making abnormal request patterns easier to spot.

For defenders, the most important operational meaning is that TGS-REQ activity tells you where authentication is turning into real service use. Repeated requests for the same service, requests from unusual hosts, or requests that do not match expected client behaviour can indicate misuse of valid Kerberos trust rather than a simple login problem.

Risk and Threat Considerations

Kerberos TGS-REQ is attractive to attackers because it is part of the normal path from a valid initial login to a service ticket, which means abuse can look like routine authentication traffic. If an attacker obtains a ticket-granting ticket or related Kerberos material, they may request service tickets without knowing the password, which shifts the problem from credential guessing to ticket theft or replay.

Failure mechanism: The protocol relies on the integrity and freshness of the ticket and authenticator, so stolen, replayed, or forged Kerberos material can be used to obtain service tickets and extend access across services.

Impact: Successful abuse can enable impersonation, service access, and lateral movement while blending into expected Kerberos traffic, making compromise harder to detect.

Practitioner Guidance

What to watch for: Treat unusual TGS-REQ volume, odd service-principal targeting, and ticket requests from unexpected systems as a signal to investigate authenticated abuse, not just login failure. Kerberos troubleshooting should always be paired with review of service-ticket issuance patterns and the integrity of the surrounding authentication chain.

Practitioner takeaway: If the TGS-REQ step is compromised, the issue is rarely just a single request, it is usually evidence that the trust path from login to service access needs review.

Related resources from NHI Mgmt Group

• Guide: Kerberos Security Guide
• TGS_REQ
• What is the difference between a TGT and a TGS in Kerberos attacks?
• Kerberos Ticket Granting Service (TGS)
• What is the difference between a normal Kerberos ticket issue and a Golden Ticket attack?