Skip to main content

MITRE ATT&CK - Kerberos Vulnerabilities and Security

From the previous post, the summary of Kerberos authentication process is as below:

  1. For the initial authentication, the user’s client machine sends a request to the KDC Authentication Service (AS). The request includes details like the user’s username, and the date and time. All information except the username is encrypted using the hash of the user’s password.
  2. The KDC AS uses the username to look up its copy of the user’s password hash and uses it to decrypt the rest of the request. If the decryption is successful, that means the client used the correct password hash and the user has successfully authenticated.
  3. Once the user is authenticated, the KDC AS sends the user’s client a ticket granting ticket (TGT). The TGT includes a unique session key and a timestamp that specifies how long that session is valid (normally 8 or 10 hours). Importantly, before sending the TGT, the KDC encrypts it using the password hash for a special account, the KRBTGT account. That password hash is shared among all the DCs in the Active Directory domain so that they can read the TGTs they receive as users request access to various IT resources.
  4. Whenever the user needs access to an IT resource, their client machine sends the request to the KDC Ticket Granting Service (TGS), including the TGT to prove that the user has been recently authenticated.
  5. The KDC TGS decrypts the TGT using the KRBTGT password If that process is successful and the timestamp indicates the TGT is still valid, the TGS creates a token and encrypts it using the service account’s NTLM password hash (which, ideally, is known only to the DC and the service itself). It sends the resulting TGS ticket to the user’s client machine.
  6. The client machine sends the TGS ticket to the application server, which decrypts it using its own password hash. Upon verification, it grants access to its resources to the user for a specific period of time, known as the Time to Live (TTL) (by default, the TTL is 10 hours). (I’ve skipped over the details of authorization — determining exactly what access to which resources the user has been granted — since we’re focused on authentication here.)

Vulnerabilities = The protocol is vulnerable to Kerberoasting, Golden Ticket and Silver ticket attacks, and pass-the-ticket attacks.


A common attack used by hackers who've compromised a user's credentials and want to begin lateral movement. Since the attackers seem to be a valid domain user, they can complete steps 1-5 of the process above. Then, when their client receives the service ticket, the hackers extract it from memory and attempt to crack it offline. Tools like Impacket, PowerSploit and Empire automate the process of requesting service tickets and extracting the ticket hashes, while password-cracking tools like John the Ripper and Hashcat can try over a million possible passwords per second, enabling them to brute-force plaintext passwords in fairly short order from vulnerable hashes.

Golden Ticket and Silver Ticket Attacks

Kerberos authenticaiton is built upon the assumption that any TGT encrypted with the KRBTGT password hash is legitimate. Therefore, any attacker who can create forged tickets has virtually unlimited power in the domain - a so called Golden Ticket.

To forge a TGT, hackers need four key pieces of information:

FQDN of the domain

SID of the domain (Security Identifier)

Username of the account they want to impersonate

KRBTGT password hash

The first three are relatively easy to obtain simply by compromising any user account in the domain, which attackers do all the time using techniques like phishing, spyware, brute force and credential stuffing.

The fourth item is a bit harder to get, but still not all that difficult. I explain them in detail in my Golden Ticket blog post, but they include:

  • Stealing the NTDS.DIT file, which stores the password hashes for all users in the domain
  • Compromising a workstation and using administrative credential artifacts left there
  • Using the open-source tool Mimikatz to gather credential data
  • Pretending to be a DC and requesting password hashes from a legitimate DC (a DCSync attack)

With all four pieces of info in hand, a hacker can create a Kerberos ticket to impersonate any AD user they want, including a highly privileged Domain Admin. Moreover, they can make those tickets valid for as long as they want, even if that violates the organization’s time limit policy setting.

There are also Silver Ticket attacks, which are more limited but still can be quite devastating. Using a technique like Kerberoasting, an attacker steals a TGS for a service (such as SharePoint), extracts the hash of the service account and uses that hash to forge additional TGS tickets for that service.

Stolen tickets: Pass-the-ticket (PtT) attacks

In addition to forging tickets, hackers can also steal legitimate TGS or TGT tickets issued to a user by the KDS. With those tickets in hand, they access IT resources as if they were that user — without ever learning the user’s password. One technique is to use a tool like Mimikatz to extract Kerberos tickets from the memory of the LSASS.exe process.

If a hacker compromises a particular user’s account, they can obtain the TGT and all TGS tickets for that user. But an adversary who manages to steal administrative privileges can obtain all TGTs and TGS tickets cached on the system.


  1. The city's commitment to education plays a pivotal role in nurturing exceptional software developers. Renowned institutions like the University of Washington and the Seattle University offer top-notch computer science programs that equip students with both theoretical knowledge and practical skills.
    Seattle Software Developers

  2. Parismusic's backing tracks for karaoke are a karaoke enthusiast's dream! With a vast selection of songs across different genres, it's easy to find the perfect track for any occasion.
    backing tracks for karaoke

  3. SEO Services California provides businesses with tailored SEO strategies to succeed in the dynamic California market, maximizing visibility, leads, and revenue potential.


Post a Comment

Popular posts from this blog

Checkpoint - Exporting Objects in CSV format

Be it a Network Operations Manager, Security Architect or a Security Auditor, the people up the hierarchy always harangue the Security Engineers to compile the list of firewall objects or rules or policies or the traffic statistics and so on.. This can turn out to be quite hectic especially if there are no built in features to systematically provide the output in a "layman-readable" format. Come, Checkpoint's "Object Explorer..."  which not only provides the output in the "layman-readable" format, but also provides in-built filtering mechanisms, thereby ensuring that the Security Engineer doesn't have to rely on Google for building his scarce Microsoft Excel data filtering skills. The following screenshots will show how easy it is, with Checkpoint R80.10 to generate the firewall configuration inventory. On the SmartConsole Unified Portal, navigate to Menu >> Open Object Explorer... Select the Categories you wish to see in your output: Click o

Tejas Jain - GCP Constraints & Random Facts

1.  Google Cloud Interconnect Security Cloud Interconnect does not encrypt the connection between your on-premises network and Google's network. Cloud VPN cannot be used with Dedicated Interconnect For additional security, use application-level encryption or your own VPN 2. While using Cloud CDN, the default time-to-live (TTL) for content caching is 3600 seconds = 60 mins 3. Cloud NAT sends only the translation logs and error logs to Cloud Logging service. 4. GCP Dedicated Interconnect - On Premises network device requirements:     10-Gbps circuits, single mode fiber or 100-Gbps circuits, single mode fiber     IPv4 link local addressing     LACP, even if you are using single circuit     EBGP-4 with multi-hop     802.1Q VLANs 5. While using Cloud VPN, the recommended MTU to be configured on the peer VPN  gateway = 1460 bytes 6. Each instance must have at least one network interface. The maximum number of network instances per instance is 8, depending on the instance's machine