Kerberos in Active Directory: How It Works, How It Is Abused, and How to Defend It

1. Introduction

Kerberos is the primary authentication protocol in Active Directory and has been the default since Windows 2000. Almost every interactive logon, file-share access, database connection and web SSO event in a modern Windows domain is underpinned by a Kerberos ticket exchange. Because it sits at the centre of identity, weaknesses in how Kerberos is configured — weak service-account passwords, legacy encryption, or over-broad delegation — translate directly into domain-wide compromise. Understanding the protocol at the packet level is what separates an administrator who can detect Kerberoasting from one who only reads about it.

2. How It Works

Kerberos is a ticket-based protocol built on symmetric cryptography and a trusted third party, the Key Distribution Center (KDC), which on a domain controller is split into the Authentication Service (AS) and the Ticket-Granting Service (TGS). The core idea: prove your identity once, receive a Ticket-Granting Ticket (TGT), then exchange that TGT for individual service tickets without re-sending your password.

Client                              Domain Controller (KDC)
  |                                     |
  |  1. AS-REQ  (pre-auth, timestamp    |
  |     encrypted with user key)  ----> | AS validates, issues TGT
  |  2. AS-REP  (TGT + session key)  <--|   (TGT encrypted w/ krbtgt key)
  |                                     |
  |  3. TGS-REQ (TGT + target SPN)  --->| TGS issues service ticket
  |  4. TGS-REP (service ticket)    <---|   (encrypted w/ service acct key)
  |                                     |
  |  5. AP-REQ  (service ticket)  ------------------> Target Service
  |                                                     validates & grants access

Key building blocks:

• AS-REQ / AS-REP: The initial exchange. With pre-authentication enabled, the client encrypts a timestamp with a key derived from its password; the KDC can only decrypt it if the password is correct. The AS-REP returns the TGT.
• TGT: Encrypted with the krbtgt account key. The client cannot read it — it simply presents it back to the KDC. Whoever owns the krbtgt hash can forge any TGT (a “Golden Ticket”).
• TGS / service ticket: Encrypted with the target service account’s key (its NTLM hash or AES key). This is the detail Kerberoasting abuses.
• SPN (Service Principal Name): A string like MSSQLSvc/db01.corp.local:1433 that maps a service instance to the account running it. The client requests a ticket by SPN.
• Delegation: Lets a service impersonate a user to a downstream service (covered in depth in the Delegation article).
• Time synchronization: Kerberos rejects tickets whose timestamp skews more than the allowed tolerance (default 5 minutes). This is why domain time hierarchy matters — and why “clock skew too great” is a classic break.

3. The Security Problem

Two design realities create the most common Kerberos weaknesses. First, a TGS-REP is encrypted with the service account’s own key, and any authenticated user can request a service ticket for any SPN. If that account uses a weak, human-set password, the ticket can be cracked offline. Second, accounts configured with “Do not require Kerberos pre-authentication” will return an AS-REP encrypted with the user’s key without any prior proof of identity — also crackable offline. Legacy RC4 (etype 23) encryption makes both attacks dramatically faster than AES.

4. How Attackers Abuse It

Kerberoasting (conceptual): An attacker who has any valid domain account enumerates accounts that have SPNs set (typically service accounts), requests TGS tickets for them, extracts the encrypted portion, and cracks it offline to recover the service account password. No elevated rights are needed to request the tickets, and requesting a ticket is normal traffic — which is what makes it stealthy.

AS-REP Roasting (conceptual): If an account has pre-authentication disabled, an attacker can request its AS-REP without knowing the password and crack the returned blob offline. This requires no domain credentials at all if the account name is known.

In an authorized lab, a red-teamer validates these by confirming which accounts expose SPNs or have pre-auth disabled, then demonstrates that a weak password is recoverable — the point being to hand the blue team a concrete remediation list, not to breach production.

5. How to Detect It

Command

setspn -Q */*

What it does: Queries the domain for every registered Service Principal Name and the account it is bound to.

What to look for: SPNs registered on ordinary user accounts (not computer accounts), especially named accounts like svc_sql, svc_backup. These are the Kerberoasting targets. A user account holding many SPNs is a high-value target.

Defensive use: Produces the exact inventory of roastable accounts so you can prioritise password rotation or migration to Group Managed Service Accounts (gMSAs).

Command

Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, PasswordLastSet, msDS-SupportedEncryptionTypes | Select-Object Name, PasswordLastSet, ServicePrincipalName, msDS-SupportedEncryptionTypes

What it does: Lists user accounts with SPNs, when their password was last set, and their supported Kerberos encryption types.

What to look for: A very old PasswordLastSet (years) combined with a missing or RC4-only encryption type is the highest-risk combination — a static, weak, fast-to-crack secret.

Defensive use: Lets you triage by real risk (age + encryption) rather than treating every service account equally.

Command

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth | Select-Object Name, Enabled, DoesNotRequirePreAuth

What it does: Finds accounts flagged “Do not require Kerberos pre-authentication” — the AS-REP Roasting targets.

What to look for: Any enabled account in the result set. In a healthy domain this list is usually empty.

Defensive use: Each result is an account you should re-enable pre-auth on unless a documented legacy application genuinely requires it.

Command

klist

What it does: Displays the Kerberos tickets currently cached for the running session.

What to look for: Service tickets with encryption type RC4-HMAC (0x17) where AES should be expected, or an unusually large number of service tickets requested in a short window.

Defensive use: On a suspected host it reveals which services a session has touched and whether legacy encryption is in play.

6. How to Audit the Environment

• Inventory all user accounts holding SPNs and confirm each is still required.
• Flag any account with pre-authentication disabled.
• Check msDS-SupportedEncryptionTypes and eliminate RC4-only accounts; standardise on AES.
• Confirm service-account passwords are long (25+ characters) and rotated, or migrated to gMSA / dMSA which auto-rotate.
• Verify the domain time hierarchy: the PDC emulator syncs to an authoritative external source and all members chain to it.
• Review any account with delegation attributes set (see the Delegation article).

7. How to Fix / Harden It

• Adopt gMSA/dMSA for services so passwords are 120+ random characters and rotate automatically — this defeats Kerberoasting outright.
• Disable RC4 where compatible and enforce AES via msDS-SupportedEncryptionTypes and the “Network security: Configure encryption types allowed for Kerberos” policy.
• Re-enable pre-authentication on any account that has it disabled.
• Protect the krbtgt account: rotate its password twice (with the recommended interval between rotations) on a schedule, since its hash forges Golden Tickets.
• Use long passphrases for any account that cannot yet move to gMSA.

8. Detection & Monitoring

• Event ID 4769 (A Kerberos service ticket was requested) — the core Kerberoasting signal. Alert on 4769 events with Ticket Encryption Type 0x17 (RC4) and Ticket Options 0x40810000, especially many distinct SPNs requested by one account in a short interval.
• Event ID 4768 (A Kerberos authentication ticket (TGT) was requested) — watch for RC4 pre-auth and for AS-REQs to accounts known to have pre-auth disabled.
• Event ID 4771 (Kerberos pre-authentication failed) — bursts can indicate password guessing.
• Baseline which accounts normally request which SPNs; Kerberoasting shows up as one principal fanning out across many services it never touches operationally.

Command

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 200 | Where-Object { $_.Message -match '0x17' } | Select-Object TimeCreated, @{n='Msg';e={$_.Message.Split([Environment]::NewLine)[0]}}

What it does: Pulls recent service-ticket requests from the Security log and filters for RC4 (0x17) encryption.

What to look for: A spike of RC4 requests from a single source account across many service names.

Defensive use: A lightweight, agentless detection you can run on a DC before investing in a SIEM rule.

9. MITRE ATT&CK Mapping

Technique	ID
Steal or Forge Kerberos Tickets: Kerberoasting	T1558.003
Steal or Forge Kerberos Tickets: AS-REP Roasting	T1558.004
Steal or Forge Kerberos Tickets: Golden Ticket	T1558.001
Valid Accounts: Domain Accounts	T1078.002

10. Practical Lab

In an isolated test forest (no production connectivity):

1. Create a user svc_sql_lab with a deliberately weak password and register an SPN with setspn -S MSSQLSvc/db-lab.test.local:1433 svc_sql_lab.
2. From a standard domain user, run setspn -Q */* and confirm the account appears.
3. Enable Kerberos logging and observe the 4769 event generated when a service ticket for that SPN is requested.
4. Rotate the account to a gMSA, re-run the enumeration, and confirm the difference in password strength/encryption.
5. Build a detection rule on RC4 4769 events and validate it fires only for the lab activity, not normal logons.

11. Key Takeaways

• Any authenticated user can request a service ticket for any SPN — the defence is a strong, rotating service-account secret, not access control on the request.
• gMSA/dMSA plus AES-only encryption neutralises Kerberoasting and AS-REP roasting for most environments.
• Event IDs 4769 (RC4/0x17) and 4768 are your primary detections; baseline normal SPN usage per account.
• The krbtgt hash forges Golden Tickets — treat its rotation as a core hygiene task.

Continue learning: Active Directory security

This guide is part of our Active Directory Security series. Related guides:

• Active Directory Enumeration with BloodHound: A Beginner’s Guide
• Active Directory Domain Trusts: Direction, Transitivity, SID Filtering, and Blast Radius
• DNS and Active Directory: SRV Records, Dynamic Updates, and Spoofing Risks