Kerberos is by far the most common authentication protocol in use today. It is designed around the concept of using tickets to provide access to network resources by allowing these tickets to be passed over an unsecure network to prove identity while mitigating some avenues of eavesdropping and replay attacks. Kerberos is dependent on the presence of a secure central authority, the Key Distribution Center (KDC), on the network that can issue tickets to requesting principals. A principal is a unique entity which can request Kerberos tickets to access services. When considered in the context of a Microsoft Windows Active Directory (AD) Domain, the Kerberos protocol allows an account (Service Principal Name) to request permission from a central authority: the Domain Controller (DC) which also hosts the KDC.

As a stateless protocol, Kerberos transactions during the authentication process are not retained throughout or after the session by design. While this historically did improve security over contemporaneous authentication approaches, recently developed and readily available tools have revealed a fundamental vulnerability in Kerberos’ inability to validate its own ticket exchanges. For example, Mimikatz is a popular tool that allows threat actors to forge Kerberos tickets or reuse stolen credentials to move laterally through the network undetected, escalating privileges until they obtain full control over files or servers.

Kerberos Authentication Process and Ticket Exchanges
To understand forged Kerberos ticket attacks, one must first understand the general flow of Kerberos tickets:

1) A principal sends an authentication server request (known as AS_REQ) to the DC.

2) If authentication succeeds, then the DC sends back a reply (AS_REP) to the principal. In this reply is a ticket that gives the principal permission to request access to resources on the network. This ticket is called the Ticket Granting Ticket (TGT). The TGT only proves that the principal has successfully authenticated on the network and provides access to one service – the Ticket Granting Service (TGS).

3) When the principal wants to request resources on a Kerberos-enabled service, it first must request a ticket to access that specific resource from the TGS. This TGS Request (TGS_REQ) is sent to the TGS, hosted on the DC.

4) The TGS then verifies the TGT and accepts that the principal has been given access to the requested resource presented in the TGS Request. If everything checks out, then the TGS sends a reply (TGS_REP) back to the principal with a secret key inside called the session key. The session key is used to encrypt messages between the principal and the service for which it is requesting resources.

5) Once the principal receives the TGS_REP, it can then request access to the network resource from the service. This is done through an Application Request (AP_REQ) to the service that is secured with the session key provided in the TGS_REP.

6) Once the service receives the AP_REQ, it verifies that the request is valid by decrypting the message from the principal. Successful decryption is enough to validate the request. If everything checks out, then the service allows access to the requested resources and sends a reply (AP_REP).

The Kerberos protocol is dependent on shared secret data stored on each of the DCs in an AD domain. This data is sometimes called key material, and it enables ticket generation in a secure manner. Any principal account used on a Microsoft Windows system stores its tickets in local memory. Further, the DC stores the key material for the domain. Should an attacker gain access to this key material, then it is possible to forge Kerberos tickets and gain access to all resources.

Golden Tickets
On any Windows domain there is a single principal account (named krbtgt) whose key material is used to generate TGTs. As detailed above, a TGT allows a principal to request access to resources on the domain. By convention, the Domain Administrator account has access to any resource on the entire domain. Therefore, it follows that, if an attacker has access to the krbtgt key material, then they could forge their own TGT for a Domain Administrator account (or any other account for that matter). This forged TGT is called a Golden Ticket (GT). Referring to the exchanges above, the first two steps (AS_REQ and AS_REP) never occur during a GT attack. The attacker simply requests access to the resources of the Domain Administrator’s identity by using a forged TGT.

Silver Tickets
Silver Tickets are forged Kerberos Ticket Granting Service (TGS) tickets, also called service tickets. While a Golden Ticket provides access to any Kerberos service, a Silver Ticket only allows access to a specific service on a targeted server. However, Silver Ticket attacks can be generated without suspicious interactions with the DC(s), which are often the only data sources monitored for detection of credential compromise. This makes these types of attacks even less likely to be detected, and therefore more dangerous in the eyes of many security analysts.

Detection of Golden and Silver Ticket Attacks
QOMPLX:CYBER maintains a stateful view of Kerberos authentication by keeping a ledger of valid tickets issued from the DC(s). New authentication requests are compared to a known list of valid tickets, allowing QOMPLX:CYBER to detect Golden and Silver Tickets regardless of any attempt to modify configuration parameters to simulate a valid ticket. In short, QOMPLX:CYBER is able to validate every single Kerberos transaction, and its attack detection techniques remain valid regardless of which tool is used to attempt to forge a ticket.

QOMPLX:CYBER is also deterministic, meaning that there are no false positives and attack detection is immediate once krbtgt secrets are reset—either manually during installation/configuration as recommended or automatically when the ticket renewal window expires (10 hours by default). This validation technique does not rely on a learned heuristic signature. Although QOMPLX:CYBER does use behavioral indicators and analysis to support other types of attacks, behavioral analysis is wholly unsuited for validating the stateless Kerberos protocol.

Additional Resources
Active Directory Security
Return From The Underworld - The Future Of Red Team Kerberos
Abusing Microsoft Kerberos
AI-based Identity Analytics