A TGT is the ticket a user presents to the domain controller to ask for access to services. A TGS is the service-specific ticket issued after that request. In Kerberoasting, attackers abuse a valid TGT to request TGS tickets for service accounts, then try to crack those service tickets offline to recover the underlying password hash.
How a TGT and a TGS differ in Kerberos
The distinction is procedural, not cosmetic. A Ticket Granting Ticket is the first proof that the client has already authenticated to the kerberos realm, while a Ticket Granting Service ticket is the per-service credential used to reach a specific target. In attack terms, that difference matters because abuse often starts with one valid ticket and ends with another, service-specific ticket.
A TGT is broad and reusable within its lifetime, but it does not directly open a file server, database, or application. The TGS is narrower: it is issued for one service principal and carries the information the service uses to validate the client. That separation is what lets Kerberos keep the initial login flow centralized while still enforcing service-by-service access.
The practical consequence is that attackers care about where the ticket boundary sits. A stolen or relayed TGT can be used to ask the Key Distribution Center for more tickets, and those service tickets can then become the object of offline analysis. That is why service-account hygiene, ticket lifetime, and encryption strength all shape the attack surface.
Why Kerberoasting targets the TGS, not the TGT
Kerberoasting works because the TGS for a service account is intentionally obtainable by an authenticated user, but it is also often encrypted in a way that can be attacked offline once captured. The attacker is not trying to “log in” with the TGS in the normal sense, they are trying to turn that ticket into password-cracking material without repeatedly touching the target service.
The TGT mainly functions as the attacker’s request authorization to the ticketing system. The TGS is the prize because it is tied to the service account and may expose a hash-like offline cracking opportunity. If the service account password is weak, old, reused, or poorly rotated, the ticket becomes a bridge to higher privilege.
This is also why the same Kerberos mechanics can support both noisy and quiet abuse. A single compromised TGT can produce many service tickets, and the activity may look legitimate until defenders notice unusual service requests, atypical account use, or repeated ticket issuance patterns.
What defenders should watch for when tickets become attack tools
Ticket abuse is often less about one stolen artifact than about the attacker’s ability to move through the Kerberos trust chain. Once an attacker has a foothold, service-account tickets can be requested at scale, and the weak point is usually the downstream service account, not the ticket request itself.
The control question is whether service principals are hardened enough that a captured ticket is not enough to recover a credential. Strong passwords, managed service accounts, limited privilege, and constrained ticket lifetimes all reduce the payoff. For broader visibility into abuse patterns and identity compromise, The 52 NHI Breaches Report is useful reading because it shows how stolen credentials and service-account abuse often cascade into wider compromise.
Attackers also exploit operational blind spots. If ticket requests are not monitored for unusual volume, unusual source hosts, or unusual service targets, the first sign may be password cracking against a service account after the fact rather than a live intrusion.
Risk and Threat Considerations
Kerberos ticket abuse becomes dangerous when organisations treat the TGT and TGS as interchangeable “login tokens.” They are different trust objects, and the TGS is often the point where a valid authentication flow turns into offline cracking exposure or privilege escalation.
Failure mechanism: An attacker with a valid TGT requests service tickets for accounts with weak or long-lived secrets, then attacks those tickets offline to recover credentials or expand access.
Impact: Service-account compromise can lead to lateral movement, privilege escalation, and persistent access without repeatedly abusing the original foothold.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1558.003 — Kerberoasting | Directly models the TGS abuse path in Kerberos attacks |
| Recommendation — Monitor service-ticket requests and harden service accounts against offline cracking. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Ticket abuse depends on weak or long-lived credential material tied to service accounts |
| IA-2 — Identification and Authentication (Organizational Users) | Kerberos ticketing begins with authenticated user access to request downstream tickets | |
| AC-6 — Least Privilege | Reducing service-account privilege limits what attackers gain after cracking a TGS | |
| Recommendation — Rotate and manage credentials so captured tickets do not yield recoverable secrets. Verify authenticated access paths before allowing service-ticket issuance. Restrict service-account permissions to reduce post-compromise blast radius. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Kerberos ticket trust should be bounded and continuously validated across services |
| Recommendation — Treat ticket possession as one signal, not a standing authorization to sensitive services. | ||
Practitioner Guidance
What to verify: Confirm which service accounts still use passwords that are human-manageable rather than machine-managed, then treat those as high-priority candidates for rotation or redesign. The issue is not just ticket theft, it is whether the ticket can be turned into a recoverable secret.
Common mistake: Teams often focus on the user TGT as the sensitive object and miss the fact that the service ticket, not the initial logon ticket, is what enables Kerberoasting. If you only watch for interactive logon abuse, you will miss the service-account path.
What good looks like: Service accounts have strong, non-reused credentials, limited privileges, and short exposure windows, and ticket-request telemetry is reviewed for unusual patterns tied to high-value services.
Practitioner takeaway: In Kerberos attacks, the TGT is the access path and the TGS is often the exploitation target, so defenders should harden service accounts and monitor ticket issuance rather than assuming “valid login” equals low risk.
Related resources from NHI Mgmt Group
- What is the difference between prompt injection risk and identity abuse in agents?
- What is the difference between SAST and DAST for security teams?
- What is the difference between direct command and control and relay-based command and control in advanced malware?
- How can organizations counter AI-driven cyber attacks?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
