admin_hub

sysop@hub:~/explainers/kerberos-explained$

kerberos-explained

How Kerberos authentication works

The three exchanges behind a domain sign-in: getting a ticket-granting ticket, getting a service ticket, and using it.

Read the steps as text
  1. AS-REQ. The client asks the KDC for a ticket-granting ticket (TGT). With pre-authentication it proves it knows the password by encrypting a timestamp with a key derived from it. The password itself is never sent.
  2. AS-REP: TGT. The KDC returns a TGT encrypted with the key of the krbtgt account, plus a session key encrypted with the user's key. The client cannot read the TGT, it only stores it. Anyone who obtains the krbtgt key can forge TGTs. That attack is called a golden ticket.
  3. TGS-REQ. To reach a service, the client presents its TGT and names the service by its service principal name (SPN), for example cifs/fileserver.
  4. TGS-REP: service ticket. The KDC returns a service ticket encrypted with the key of the account that runs the service. The ticket carries the user's identity and group memberships.
  5. AP-REQ. The client sends the service ticket together with an authenticator, a fresh timestamp, to the service.
  6. AP-REP. The service decrypts the ticket with its own key, checks the authenticator and grants access. It can also prove its own identity back to the client (mutual authentication). Clocks must be close together, five minutes by default, or tickets are rejected.

Good to know

  • Kerberos needs clocks within five minutes by default. Time sync problems cause many odd sign-in failures.
  • Missing or duplicate SPNs lead to Kerberos errors and a fallback to NTLM.
  • On domain controllers, event 4768 logs TGT requests and event 4769 logs service ticket requests.

Related: Glossary: KerberosEvent 4769

How Kerberoasting works

An attack that turns a normal service ticket request into an offline password cracking job against service accounts.

Read the steps as text
  1. Normal sign-in (TGT). Any authenticated domain user can get a TGT. The attacker needs no special privileges.
  2. Find accounts with SPNs. The attacker queries LDAP for user accounts that have a service principal name. These are the targets.
  3. TGS-REQ for the SPN. The attacker requests a service ticket for one of those SPNs. This is a normal request that looks like everyday traffic.
  4. TGS-REP: ticket. The KDC returns the ticket, encrypted with a key derived from the service account's password. The KDC does not check whether the requester is meant to use that service.
  5. Crack offline. The attacker takes the ticket away and tries passwords against it offline, at high speed, with no lockouts and no further traffic to log. Weak or old passwords fall quickly, especially with RC4 encryption.
  6. Use the password. With the recovered password the attacker signs in as the service account, which often has more rights than a normal user.

How to defend

  • Use long random passwords (25 characters or more) for service accounts, or group managed service accounts (gMSA), whose passwords are long, random and rotated automatically.
  • Prefer AES over RC4 for ticket encryption and turn RC4 off where you can.
  • Remove SPNs that are no longer needed and avoid putting SPNs on highly privileged accounts.
  • Monitor event 4769 on domain controllers, especially many requests for different SPNs from one account, or tickets with RC4 encryption (type 0x17).
  • Consider a honeypot service account with an SPN that nobody should ever request.

Related: Glossary: KerberoastingEvent 4769