Kerberos and Kerberoasting

Kerberos is a ticket-based authentication protocol. Instead of sending passwords, clients present cryptographic tickets issued by the Key Distribution Center (KDC), which runs on every Domain Controller.

• The Authentication Server (AS) issues a Ticket Granting Ticket (TGT).
• The Ticket Granting Server (TGS) issues service tickets.
• Services validate tickets without contacting the DC.

Kerberos has three message exchanges. Understanding them reveals where attacks fit.

• AS-REQ / AS-REP: client proves identity (pre-auth) and gets a TGT encrypted with the krbtgt key.
• TGS-REQ / TGS-REP: client presents the TGT to request a service ticket (TGS).
• AP-REQ / AP-REP: client presents the TGS to the service.

AS-REP roasting attacks the first exchange; Kerberoasting attacks the second.

A Service Principal Name (SPN) maps a service instance to the account running it. When you request a TGS for an SPN, the resulting ticket is partly encrypted with the service account's password hash.

This is the crux of Kerberoasting: any authenticated user can request tickets for service accounts, then crack them offline to recover the plaintext password.

Kerberoasting is low-noise because requesting a TGS is normal behavior. The attack steps are:

• Enumerate user accounts with SPNs.
• Request TGS tickets for those SPNs.
• Extract the encrypted ticket blobs.
• Crack them offline with a wordlist; no DC interaction needed during cracking.

The captured ticket uses the service account password as the key. Offline cracking tries candidate passwords until one decrypts the ticket correctly.

Service accounts often have weak, never-rotated passwords, which makes them crack quickly.

The cipher used for the ticket affects crack speed.

• RC4 (etype 23) is fast to crack and is a red flag if still allowed.
• AES (etype 17/18) is far slower to brute-force.
• Attackers may downgrade requests to RC4 with /tgtdeleg or msDS-SupportedEncryptionTypes abuse.

Defenders should disable RC4 domain-wide and enforce AES.

A related attack targets accounts with Kerberos pre-authentication disabled (DONT_REQ_PREAUTH). Without pre-auth, the AS-REP contains data encrypted with the user's password hash, obtainable without any credentials.

Kerberoasting succeeds because of structural weaknesses, not protocol flaws.

• Any authenticated principal can request any service ticket by design.
• Service accounts are frequently set up once with a weak password and never rotated.
• Many run with high privileges (e.g., SQL service accounts in Domain Admins).
• Cracking is fully offline, so account lockout never triggers.

Defenders can catch roasting through telemetry on TGS requests.

• Monitor event 4769 for RC4 (0x17) ticket requests, especially in bursts from one account.
• Alert on a single principal requesting many distinct SPNs quickly.
• Deploy honeypot SPN accounts that no legitimate service uses; any request is malicious.

The durable fix is removing the conditions that make tickets crackable.

• Use Group Managed Service Accounts (gMSA) with 120+ character auto-rotated passwords.
• Enforce long, complex passwords on any remaining classic service accounts.
• Disable RC4; require AES encryption types.
• Remove unneeded SPNs and least-privilege the accounts.

During authorized testing, crack tickets in an isolated environment and never exfiltrate plaintext credentials beyond the engagement scope. Report which accounts cracked and how fast, so the client can prioritize gMSA migration.

Treat cracked passwords as sensitive: store them encrypted and purge them after reporting.

Confirm your grasp of Kerberoasting mechanics.

You learned how Kerberos issues tickets and how that mechanism is abused.

• SPN tickets are encrypted with service account hashes, enabling offline cracking.
• RC4 tickets crack fast; AES and gMSA are the defenses.
• AS-REP roasting needs no credentials when pre-auth is disabled.
• Honeypot SPNs and 4769 RC4 monitoring catch the attack.

Next we cover reusing stolen credentials with Pass-the-Hash and Pass-the-Ticket.