What is Kerberos Authentication?

Definition

Kerberos is a network authentication protocol that uses tickets issued by a trusted Key Distribution Center (KDC) to allow users and services to prove identity to each other without sending passwords across the network.

Kerberos is the primary authentication protocol in Active Directory (with NTLM as fallback). The KDC role is performed by every Domain Controller.

In simple terms:

Kerberos is the system that lets you log in once and access many services securely — and the system attackers attack to forge identity.

---

Why Kerberos Matters

• Used for almost all modern AD authentication (SMB, LDAP, MSSQL, IIS with Kerberos, etc.).
• Tickets, not passwords, are exchanged after initial logon.
• Misconfiguration enables some of the most damaging AD attacks (Kerberoasting, Golden / Silver Tickets, delegation abuse).
• Understanding Kerberos is essential for defending Active Directory.

---

How Kerberos Works (High Level)

1. AS-REQ / AS-REP — Initial Logon

• Client sends an Authentication Service Request (AS-REQ) to the KDC, encrypted with the user's password-derived key (preauth).
• KDC validates and returns a Ticket Granting Ticket (TGT) encrypted with the KRBTGT key.

2. TGS-REQ / TGS-REP — Service Access

• Client uses TGT to request a service ticket from the KDC for a specific service (identified by SPN).
• KDC returns a service ticket encrypted with the target service's account key.

3. AP-REQ / AP-REP — Service Authentication

• Client presents the service ticket to the service.
• Service decrypts and authenticates the user.

Key Components

• KDC — runs on every DC.
• TGT — proves identity to the KDC.
• Service Ticket — proves identity to a specific service.
• SPN — Service Principal Name; the service's identifier.
• KRBTGT — special account whose hash signs all TGTs.

---

Common Kerberos Attacks

1. Kerberoasting

• Any authenticated user can request service tickets for accounts with SPNs.
• Tickets are encrypted with the service account's password-derived key.
• Attackers crack offline.
• Weak service account passwords = recovered plaintext.

2. AS-REP Roasting

• Accounts with Do not require Kerberos preauthentication can have AS-REP responses requested without proving identity.
• Responses are encrypted with the user's key — crackable offline.

3. Golden Ticket

• With the KRBTGT hash, attackers forge arbitrary TGTs claiming any group membership.
• Persistence until KRBTGT is rotated twice.

4. Silver Ticket

• With a service account hash, attackers forge service tickets for that service.
• Bypasses KDC entirely; harder to detect.

5. Diamond / Sapphire Ticket

• Modern variants that modify legitimate tickets to add privileges, blending in with normal traffic.

6. Pass-the-Ticket

• Reuse stolen Kerberos tickets in another session.

7. Unconstrained Delegation Abuse

• A service trusted for unconstrained delegation receives users' TGTs.
• Compromise of that service exposes TGTs of every connecting user, including admins.

8. Constrained Delegation / RBCD Abuse

• Misconfigurations can let an attacker impersonate users to specific services.

---

Real-World Examples

1. Kerberoasting → Domain Admin

An attacker with a low-privilege account requests service tickets for SPN-enabled accounts. A SQL Server service account uses a 2018 password. Cracked overnight; that account is in Domain Admins.

2. Golden Ticket Persistence

After DCSync, attackers extract KRBTGT hash and forge a Golden Ticket valid for 10 years. Surviving most clean-up efforts until KRBTGT is rotated twice.

3. Unconstrained Delegation Abuse

A web server has unconstrained delegation. A Domain Admin browses to it for troubleshooting. Their TGT is captured from the server's memory and reused.

4. RBCD Escalation

An attacker controls a computer object that is a target for RBCD. They configure another machine to act on its behalf and impersonate any user, including admins.

---

Kerberos Hardening Best Practices

Service Accounts

1. Use gMSA — passwords managed automatically, long and complex.
2. Strong, long passwords for any remaining static service accounts.
3. Rotate service account passwords periodically.
4. Move service accounts out of privileged groups (no Domain Admin service accounts).

Preauthentication

5. Require Kerberos preauthentication on every account.

KRBTGT

6. Rotate KRBTGT twice annually, twice consecutively after suspected compromise.
7. Restrict who can DCSync (replication rights audit).

Delegation

8. Eliminate unconstrained delegation. Use constrained or RBCD instead.
9. Audit RBCD configurations — especially msDS-AllowedToActOnBehalfOfOtherIdentity.

Cryptography

10. Disable RC4 Kerberos encryption types where possible; prefer AES.
11. Enable AES on accounts and trusts.

Detection

12. Detect Kerberoasting — anomalous TGS requests with RC4 from low-privilege accounts.
13. Detect AS-REP roasting — AS-REQ with no preauth from many accounts.
14. Detect Golden / Silver Tickets — anomalies in ticket lifetimes, encryption types, group claims.
15. Detect Pass-the-Ticket — ticket reuse from new hosts.

---

Kerberos Security Checklist

• gMSA used wherever supported?
• Static service account passwords strong (25+ chars)?
• Pre-authentication required on every account?
• KRBTGT rotated within last 6 months (twice if recent suspicion)?
• No accounts with unconstrained delegation outside DCs?
• RBCD configurations audited?
• RC4 disabled / AES enabled where possible?
• Kerberoasting / AS-REP roasting / Golden Ticket detections in place?
• DCSync rights audited?

---

How Forestall Helps

Forestall surfaces Kerberos-related risk across your forest:

• Kerberoastable accounts (SPN-enabled, weak/old passwords).
• AS-REP roastable accounts (preauth disabled).
• Unconstrained and RBCD delegation issues.
• Identities with effective DCSync rights.
• Attack paths from low-privilege account → Kerberos abuse → Tier 0.

---

Frequently Asked Questions

Why is Kerberos better than NTLM?

Mutual authentication, no password traversal, replay protection, and stronger crypto.

Can Kerberos work over the internet?

Not naturally. It's designed for trusted networks. Modern alternatives (OAuth/OIDC) handle internet auth; Kerberos remains internal.

Is Kerberos used in Entra ID?

Entra ID has a separate token-based system. Kerberos can be brought into Entra ID for hybrid scenarios (Cloud Kerberos Trust, Entra ID Kerberos for FIDO2 → SMB).

How does KRBTGT rotation work?

Reset the KRBTGT password to invalidate old TGTs. Two consecutive resets are needed because KRBTGT keeps the previous key. Use Microsoft's published script.

What's the highest-impact Kerberos attack?

Golden Ticket — full impersonation that's hard to detect and persistent until KRBTGT is rotated twice.

---

Conclusion

Kerberos is foundational to Active Directory authentication and to many of the most serious AD attacks. Hardening service accounts, eliminating delegation pitfalls, rotating KRBTGT, enforcing preauth, preferring AES, and detecting ticket abuse are the controls that keep Kerberos doing its job — and prevent attackers from turning it into the engine of a domain-wide compromise.