June 30, 2026 · 9 min read · concepts
Kerberos is a network authentication protocol that verifies the identity of users and computers with tickets and symmetric encryption. Instead of sending your password again at every service, you fetch a ticket once from a central, trusted party, and that ticket proves who you are from then on. That central party is called the Key Distribution Center (KDC).
The protocol comes from MIT, out of Project Athena, and is named after Kerberos, the three-headed dog from Greek mythology that guards the underworld. The three heads match the three parties in every exchange: the client, the KDC and the service. The current version is Kerberos version 5, defined in RFC 4120. In Active Directory, Kerberos has been the default authentication protocol since Windows 2000, with NTLM as the older fallback.
In short, you prove once who you are with Kerberos, and you get a kind of digital pass in return. With that pass you then collect a separate access ticket for each service, without entering your password again every time. Under the hood that happens in three steps between the client, the KDC and the service.
Because the TGT is encrypted with the krbtgt key, the client cannot read or alter it itself, and because a service ticket is encrypted with the key of the service itself, only that one service can open it. On top of that, Kerberos also verifies the server, not just the client. The service can in turn prove itself to the client (mutual authentication), something NTLM cannot do.
In a domain the KDC runs on every domain controller, with the AD database as its account store. The most important account in it is the krbtgt account, a special, disabled account whose password hash encrypts every TGT in the domain. That hash is therefore the most important key in the whole AD.
Every ticket contains a PAC (Privilege Attribute Certificate). It holds the SID (Security Identifier) of the user and the SIDs of all groups the user is in. That is the authorization information a service uses to decide what you are allowed to do, without “calling” a domain controller for every question. The noPac attack in 2021 abused a flaw in the PAC handling. Microsoft closed it with security updates.
The SPN from step 2 is the unique name of a service, tied to the account the service runs under. From that name the KDC determines which account key it encrypts the service ticket with. That is why an SPN may sit on only one account. If the same SPN sits on two accounts, the KDC does not know which one is meant and authentication fails.
Windows chooses between Kerberos and NTLM through the Negotiate mechanism, which uses Kerberos where it can and otherwise falls back to NTLM. Whether Kerberos can be used depends first of all on how you connect. Through a hostname the client composes an SPN and uses Kerberos, through an IP address there is no SPN for it and Windows falls back to NTLM. On top of that you can steer it with policy, for example by restricting NTLM in a domain or disabling it entirely, so that only Kerberos remains.
A client and a domain controller may be at most 5 minutes apart by default, otherwise authentication fails. That is why domain computers sync their time with the domain controller.
Many Active Directory attacks touch Kerberos somewhere. The best-known fall roughly into four groups.
With Kerberoasting you use an ordinary domain account to request service tickets for accounts that have an SPN. That ticket is encrypted with the password hash of the service account, so a weak service password you crack offline. AS-REP roasting works on accounts that have pre-authentication turned off. For those accounts the KDC returns encrypted data without you having to prove the password, and that data you crack offline too.
With pass-the-ticket you pull, when you are local administrator on a machine where someone is logged in, their TGT or service tickets from memory with Mimikatz or Rubeus, and inject those into your own session. With overpass-the-hash you turn a stolen NT hash or AES key into a real TGT, and that way you carry Pass-the-Hash over into the Kerberos world.
Whoever steals the right key can make valid tickets themselves. A golden ticket is a self-made TGT, signed with the hash of the krbtgt account. Because every TGT is signed with that hash, the domain accepts such a forged ticket for any user and any group, up to Domain Admin. You do need the krbtgt hash for it, and you only have that once you have already fully taken over the domain. So a golden ticket is something you use to keep access, not to get in.
A silver ticket is smaller in scope. You make it with the hash of one service account, and it only grants access to that one service. The advantage for the attacker is that the domain controller sees nothing of it, because it is not involved. Diamond and sapphire tickets are variants that modify a real ticket issued by the domain controller instead of building one entirely from scratch, which makes them harder to detect.
Kerberos delegation lets a service log in to another service on your behalf, for example a web server that fetches data from a database on your behalf. If an attacker gets hold of such a delegation, they request a service ticket for any user they want, domain admins included, and log in to that service with it. There are three variants, which differ in where the delegation is configured.
msDS-AllowedToDelegateTo) the delegation is limited to a few fixed services. Whoever controls that account can request a service ticket for any user with S4U and log in to those services.msDS-AllowedToActOnBehalfOfOtherIdentity. With write rights on a computer object you put your own account in there, and log in to that machine as any user you want.With BloodHound we map these kinds of delegation paths.
Relay means an attacker captures a login attempt meant for one server and forwards it to another server, to get in there as the victim. With NTLM this is a well-known and serious problem, known as NTLM-relay. With Kerberos it does not work just like that, because a ticket is only valid for one service and gets rejected on another server.
The route that does work runs through coercion. You force a server to authenticate to your machine, capture that Kerberos authentication and forward it to LDAP for example, to give an attacker account more rights there. The tool krbrelayx is made specifically for this.
As soon as we have a valid domain account in an Active Directory pentest, Kerberos is an early source of findings. With NetExec we fetch the hashes for Kerberoasting and AS-REP roasting in two commands, and check right away whether RC4 is still allowed. With BloodHound we map unsafe delegation and attack paths to privileged accounts.
# AS-REP roasting: hashes of accounts without pre-authentication
nxc ldap 10.0.0.1 -u jdoe -p Password --asreproast asreproast.txt
# Kerberoasting: hashes of accounts with an SPN
nxc ldap 10.0.0.1 -u jdoe -p Password --kerberoasting kerberoast.txt
We then crack the captured hashes offline. What a cracked service account or a delegation path yields depends on the rights behind it. In our report we name not only what we cracked, but also the underlying cause: a service account in a privileged group, RC4 still enabled, or a host with unconstrained delegation. For most clients that is the most durable fix. Only run this kind of test on systems for which you have explicit, written permission. Without that permission it is a criminal offense.
Almost all the attacks above abuse a wrong setting, not a weakness in Kerberos itself. The following stops them.
NTLM is the older Microsoft challenge-response authentication protocol in Windows networks. We show where it leaks in your AD and how to phase it out.
Lateral movement is how an attacker moves from system to system after the initial breach, on the way to domain admin. We show the risk in your network.
AS-REP roasting cracks the password of Active Directory accounts that have Kerberos pre-authentication disabled, offline and often without having to log in.