🧠 BrainStuffer
Kerberos Authentication
Kerberos Authentication — tickets, exchanges & attacks

Core Kerberos Concepts

🔑

What is Kerberos?

A network authentication protocol using symmetric-key cryptography and trusted third-party tickets. No password ever travels the wire. Provides mutual authentication — both client and service verify each other. Single sign-on (SSO) within a realm. Developed at MIT; used by Active Directory, Linux Kerberos, macOS, and more.

🏛

The Three Actors

Client — the user/workstation requesting access (Alice).
KDC — Key Distribution Centre; runs two logical services: Authentication Service (AS) issues TGTs, Ticket Granting Service (TGS) issues service tickets. In AD, the DC is the KDC.
Service — the resource being accessed (fileserver, MSSQL, etc.).

🎫

Tickets

TGT (Ticket Granting Ticket) — proof of identity cached on the client. Encrypted with the krbtgt key (only the KDC can read it). Lifetime ~10 hours. Used to request service tickets without re-entering credentials.
Service Ticket — authorises access to one specific service, identified by its SPN. Shorter lived. Encrypted with the service account's key.

🗝

Session Keys

TGT session key — shared between client and KDC. Created during AS exchange. Client uses it to encrypt Authenticators for TGS requests.
Service session key — shared between client and service. Created during TGS exchange. Used to encrypt Authenticators in AP-REQ and prove mutual auth in AP-REP.
Neither key is reused between exchanges. Forward secrecy per session.

🛡

Pre-Authentication

By default the client must include PA-ENC-TIMESTAMP — a timestamp encrypted with the user's long-term key — in the AS-REQ. This proves password knowledge before the KDC responds.
If pre-auth is disabled on an account, the KDC returns an AS-REP with enc-part encrypted under the user's key to anyone who asks — enabling offline cracking (AS-REP Roasting).

📋

The PAC

Privilege Attribute Certificate — a Microsoft extension embedded inside every ticket. Contains: user SID, group SIDs, logon info, and account flags. Signed by the KDC (krbtgt key) and optionally by the service key. Used for authorisation decisions by services and the OS — group memberships come from here, not from an LDAP lookup at access time.

The Six-Message Kerberos Exchange

💻
Client
Alice / workstation
🏛
KDC / DC
AS + TGS services
📁
Service
fileserver$
← scroll to see full diagram →
—— AS Exchange —— —— TGS Exchange —— —— AP Exchange —— ① AS-REQ username · nonce · pre-auth timestamp ② AS-REP TGT [krbtgt key] + session key [user key] ③ TGS-REQ TGT + authenticator + target SPN ④ TGS-REP Service Ticket [svc key] + session key [TGT session key] ⑤ AP-REQ Service Ticket + authenticator ⑥ AP-REP mutual auth — timestamp [svc session key]
① AS-REQ Client → KDC / Authentication Service UDP/TCP :88
Plaintext User long-term key krbtgt key TGT session key Service long-term key Service session key
Step 1 of 6

Ticket Anatomy

AS-REP outer structure
AS-REP outer (plaintext)
crealm CORP.LOCAL Client realm
cname alice Client principal
🔒 TGT — encrypted with krbtgt long-term key (KDC only can decrypt)
flags FORWARDABLE | RENEWABLE | PRE-AUTHENT Ticket flags
key <TGT SESSION KEY (AES256)> New session key shared with client
crealm CORP.LOCAL Client realm stored in ticket
cname alice Client name in ticket
authtime now When Alice authenticated
endtime now + 10h Ticket lifetime
renew-till now + 7d Max renewable period
📄 PAC — signed nested structure
UserSID S-1-5-21-...-1234 User security identifier
GroupSIDs Domain Users, Domain Admins... Group memberships
LogonInfo display name, logon count, etc. Logon metadata
🔒 enc-part — encrypted with user's long-term key (client decrypts this)
key <TGT SESSION KEY (AES256)> Same key as inside TGT — Alice now has it
nonce 0xA3F1B2C4 Must match AS-REQ nonce (replay protection)
flags FORWARDABLE | RENEWABLE Matches ticket flags
sname krbtgt/CORP.LOCAL Service this TGT is valid for
endtime now + 10h When TGT expires
TGS-REP outer structure
TGS-REP outer (plaintext)
crealm CORP.LOCAL Client realm
cname alice Client principal
🔒 Service Ticket — encrypted with service account long-term key (client cannot read)
flags FORWARDABLE | PRE-AUTHENT Inherited from TGT flags
key <SVC SESSION KEY (AES256)> New session key for client-service communication
crealm CORP.LOCAL Client realm
cname alice Client name
authtime (from TGT) Original authentication time
endtime min(TGT expiry, requested) Service ticket lifetime
📄 PAC — copied and filtered from TGT PAC, dual-signed
UserSID S-1-5-21-...-1234 User SID
GroupSIDs Domain Users, ... Group memberships for authorisation
ServerChecksum HMAC [service key] Service can verify PAC integrity
KDCChecksum HMAC [krbtgt key] KDC can verify PAC integrity
🔒 enc-part — encrypted with TGT session key (client decrypts)
key <SVC SESSION KEY> Client extracts service session key
nonce 0xD4E5F6A7 Must match TGS-REQ nonce
sname cifs/fileserver.corp.local Service this ticket is for
endtime <expiry> Ticket expiry
PAC Buffer Layout

The PAC is a variable-length buffer embedded in the authorization-data field of a ticket. It consists of multiple typed buffers, each describing a different aspect of the principal.

KERB_VALIDATION_INFO (Logon Info)
EffectiveNamealicesAMAccountName
UserId1234 (RID)Relative Identifier
PrimaryGroupId513 (Domain Users)Primary group RID
GroupIds[513, 512, 519, ...]All group RIDs
LogonCount42Number of logons
UserAccountControl0x210Account flags
PAC_CLIENT_INFO
ClientId(authentication time)Timestamp of auth
NamealiceClient name (UTF-16)
UPN_DNS_INFO
UPNalice@corp.localUser Principal Name
DnsDomainNameCORP.LOCALDNS domain
🔒 PAC_SERVER_CHECKSUM — signed with service key
SignatureTypeHMAC_SHA1_96_AES256Algorithm used
Signature<16 bytes HMAC>Integrity check for the service
🔒 PAC_PRIVSVR_CHECKSUM — signed with krbtgt key
SignatureTypeHMAC_SHA1_96_AES256Algorithm used
Signature<16 bytes HMAC>Integrity check for the KDC

Kerberos Delegation

Delegation allows a service to act on behalf of a user when accessing backend resources. Two S4U (Service for User) extension protocols enable this.

S4U2Self — Service requests a ticket for itself on behalf of a user

Used when a user authenticated via NTLM or web forms (not Kerberos) but the service needs a service ticket to delegate further. The service requests a forwardable service ticket for itself naming the user, without the user's involvement.

User → Service A NTLM / Forms auth (not Kerberos)
Service A → KDC / TGS TGS-REQ with PA-FOR-USER padata naming user
KDC / TGS → Service A Service ticket for Service A on behalf of user (FORWARDABLE if service account is trusted)
Service A Now holds a forwardable service ticket it can use with S4U2Proxy
Key Points
  • The user does not need to be present or even connected during the S4U2Self request.
  • The resulting ticket is marked FORWARDABLE only if the service account has "Trusted to authenticate for delegation" set or is configured for constrained delegation.
  • PA-FOR-USER contains the username and realm of the impersonated user — the service must have a valid TGT to present with this request.
  • The KDC checks that the service is permitted to impersonate users based on delegation configuration.

S4U2Proxy — Service delegates to a backend service

Service A uses the S4U2Self ticket (or a forwarded TGT) to request a service ticket for Service B on behalf of the user. Constrained delegation limits which target SPNs are allowed. RBCD stores the allowlist on the target resource.

Service A → KDC / TGS TGS-REQ with S4U2Self ticket + Service A TGT + target SPN
KDC Checks: is Service A allowed to delegate to target SPN? (msDS-AllowedToDelegateTo on Service A, or msDS-AllowedToActOnBehalfOfOtherIdentity on Service B for RBCD)
KDC / TGS → Service A Service ticket for Service B on behalf of user
Service A → Service B AP-REQ with the delegated service ticket
Constrained vs. RBCD
  • Classic Constrained Delegation: the allowlist is on Service A's account object (msDS-AllowedToDelegateTo). Requires Domain Admin to configure.
  • Resource-Based Constrained Delegation (RBCD): the allowlist is on Service B's account object (msDS-AllowedToActOnBehalfOfOtherIdentity). Service B's owner can configure it without Domain Admin.
  • RBCD is the modern preferred approach and is required for cross-domain delegation scenarios.
  • Unconstrained delegation (TRUSTED_FOR_DELEGATION) is the legacy dangerous form — avoid it; attackers can coerce DCs to authenticate and steal the TGT.

Kerberos Attack Techniques

AS-REP Roasting
Exploits accounts with pre-authentication disabled to extract an offline-crackable hash without any credentials.
Targeted steps: ① AS-REQ ② AS-REP ③ ④ ⑤ ⑥
What the attacker does
  • Enumerate accounts with DONT_REQUIRE_PREAUTH flag (via LDAP or BloodHound).
  • Send an AS-REQ for each target account without PA-ENC-TIMESTAMP padata.
  • The KDC responds with an AS-REP containing enc-part encrypted with the user's long-term key.
  • Extract the enc-part and crack offline with Hashcat or John using the $krb5asrep$23$ format.
What they gain

Plaintext password of the target account. If it is a service or admin account, this provides direct access or lateral movement opportunities.

Detect / Defend
  • Require Kerberos pre-authentication for all accounts (it is the default; audit for exceptions).
  • Monitor Event ID 4768 with pre-authentication type 0 (no pre-auth).
  • Detect Rubeus/Impacket traffic patterns (rapid AS-REQ bursts without PA data).
  • Enforce strong passwords for any accounts that legitimately cannot use pre-auth.
Kerberoasting
Any authenticated domain user can request a service ticket for any SPN. The ticket is encrypted with the service account's password hash — extract and crack offline.
Targeted steps: ① ② ③ TGS-REQ ④ TGS-REP ⑤ ⑥
What the attacker does
  • Authenticate to the domain (any low-privilege account works).
  • Enumerate service accounts with SPNs (LDAP query / BloodHound / Rubeus).
  • Request TGS-REP for each SPN — requesting RC4 encryption maximises crackability (downgrade the etype if supported).
  • Extract the service ticket blob and crack with Hashcat ($krb5tgs$23$ mode).
What they gain

Plaintext password of the service account. Service accounts often have elevated privileges (local admin, database admin), enabling lateral movement or privilege escalation.

Detect / Defend
  • Use 25+ character random passwords (or Group Managed Service Accounts — gMSA) for all service accounts.
  • Monitor Event ID 4769 with encryption type 0x17 (RC4) — modern accounts should use AES.
  • Alert on anomalous high-volume TGS requests from a single account.
  • Limit SPN assignments to accounts that genuinely need them; audit periodically.
Pass-the-Ticket (PtT)
Stolen TGTs or service tickets are injected into a new logon session, impersonating the victim for the ticket's remaining lifetime.
Bypasses: ① AS-REQ ② AS-REP ③ TGS-REQ ④ TGS-REP ⑤ AP-REQ ⑥ AP-REP
What the attacker does
  • Gain code execution on a target machine (phishing, exploit, etc.).
  • Dump Kerberos tickets from LSASS memory using Mimikatz (sekurlsa::tickets) or Rubeus (dump).
  • Export .kirbi ticket files for TGTs or high-value service tickets.
  • Inject into a new session (Rubeus ptt or Mimikatz kerberos::ptt) and access resources as the victim.
What they gain

Full access to any resources the victim's tickets authorise, for the remaining ticket lifetime (up to 10 hours for TGTs). No need to know the user's password.

Detect / Defend
  • Enable Windows Credential Guard (VBS-backed LSASS protection) — prevents LSASS memory reads.
  • Monitor for LSASS access from unexpected processes (EDR telemetry, Event 10 in Sysmon).
  • Event ID 4624 type 9 (NewCredentials / seclogon) can indicate ticket injection.
  • Reduce ticket lifetimes; limit admin rights to reduce high-value TGTs in memory.
Golden Ticket
With the krbtgt NTLM hash an attacker forges TGTs with arbitrary user names and SIDs — including Domain Admin — valid for years.
Forges / bypasses: ① AS-REQ bypassed ② AS-REP forged ③ ④ ⑤ ⑥
What the attacker does
  • Obtain the krbtgt NTLM hash via DCSync (Mimikatz lsadump::dcsync) or direct domain compromise.
  • Forge a TGT with arbitrary username, domain SID, and RIDs (e.g., RID 512 = Domain Admins).
  • Set ticket lifetime to 10 years (default in Mimikatz golden ticket generation).
  • Inject the ticket and request real service tickets from the KDC — it validates the TGT with krbtgt and issues them.
What they gain

Complete and persistent domain compromise. Can impersonate any user with any privilege. Survives password resets of individual accounts. Persists until the krbtgt password is reset twice.

Detect / Defend
  • Reset the krbtgt password twice in succession (invalidates all outstanding TGTs).
  • Monitor DCSync (Event ID 4662 with GUID 1131f6ad / 1131f6aa on domain objects).
  • Alert on tickets with lifetimes exceeding domain policy, or issued for non-existent users (Event 4769).
  • Enable Protected Users security group and Credential Guard on privileged accounts.
Silver Ticket
Using a compromised service account's key, the attacker forges a service ticket directly — the KDC is never contacted during the AP exchange.
Forges / bypasses: ① ② ③ TGS-REQ bypassed ④ TGS-REP forged ⑤ AP-REQ forged ⑥
What the attacker does
  • Compromise a service host and extract the service account's NTLM hash (Mimikatz sekurlsa::logonpasswords).
  • Forge a service ticket signed with the stolen service key, with a fabricated PAC containing desired SIDs.
  • Present the forged ticket directly to the service in an AP-REQ — service decrypts with its own key, trusts the PAC.
  • No KDC traffic generated during access — stealthier than a Golden Ticket.
What they gain

Access to that specific service as any user (including fabricated Domain Admin membership). Stealthier than Golden Ticket since there is no TGS request to log. Impact limited to one service per compromised key.

Detect / Defend
  • Enable PAC validation (KDC verification) on services — adds a network call to the KDC per AP-REQ but catches forged PACs.
  • Alert on absence of Event 4769 (TGS request) before a service access event (4624) for sensitive services.
  • Rotate service account passwords regularly; prefer gMSA (automatic 30-day rotation).
  • Credential Guard prevents LSASS extraction of service account keys from memory.

Kerberos Quiz

Question 1 of 15