Kerberos Security Guide: Kerberoasting, Ticket Attacks and Detection

Kerberos is the default authentication protocol in every Active Directory domain, and the attacks against it turn one weak service account password or one stolen key into domain-wide access. Kerberoasting, AS-REP roasting, forged golden, silver, diamond and sapphire tickets, pass-the-ticket and delegation abuse all exploit the same design: whoever holds an account's long-term key can obtain or mint tickets as that account. This guide goes deeper than the Active Directory and Entra ID Hardening Guide on one protocol. It explains each attack conceptually, then concentrates on Kerberos security controls and detection: the KRBTGT account, encryption types and the 2026 RC4 changes, PAC validation, Kerberos armoring, authentication policies and the event IDs that matter. It is written for directory engineers, identity security teams and detection engineers.

Key takeaways

• Service account passwords are the main Kerberos weakness. Any domain user can request a service ticket for an account with a service principal name (SPN), so a guessable password on that account can be cracked offline.
• The KRBTGT key is the root of trust. Anyone holding it can forge or modify ticket granting tickets for any user, and only a double reset of the KRBTGT password invalidates them.
• RC4 is ending in 2026. Microsoft's CVE-2026-20833 updates move domain controllers to AES-only defaults for accounts without an explicit setting, so inventory RC4 dependencies now rather than during an outage.
• Detection depends on domain controller auditing. Events 4768 and 4769, with their encryption type, pre-authentication and client address fields, are the backbone of Kerberos detection.
• Containment controls exist and are underused. Protected Users, authentication policies and silos, Kerberos armoring and removal of unconstrained delegation stop whole classes of ticket theft for tier zero accounts.

How Kerberos authentication works

Kerberos (RFC 4120) uses a trusted third party, the Key Distribution Center (KDC), to issue time-limited tickets so that passwords never cross the network. In Active Directory every writable domain controller runs the Kerberos KDC service, which has two logical parts: the Authentication Service (AS) and the Ticket Granting Service (TGS).

1. AS exchange: the client proves knowledge of its key, normally by encrypting a timestamp (Kerberos pre-authentication), and receives a ticket granting ticket. The Kerberos TGT is encrypted with the key of the krbtgt account, so only the KDC can read it. Event 4768 is logged.
2. TGS exchange: the client presents the TGT and names a service by its SPN. The KDC returns a service ticket encrypted with the key of the account that owns that SPN. Event 4769 is logged.
3. AP exchange: the service decrypts the ticket with its own key and reads the user's SIDs and group memberships from the Privilege Attribute Certificate (PAC) inside it. Nothing is logged on the DC.

Two consequences drive almost every attack. The service trusts any ticket it can decrypt, so anyone holding a service or computer account's key can create tickets for that service. The KDC trusts any TGT it can decrypt, so anyone holding the KRBTGT key can create a TGT the whole domain will trust. Cached tickets in LSASS on each host are the third target, for pass-the-ticket.

Kerberos attacks at a glance

MITRE ATT&CK groups most techniques under T1558 Steal or Forge Kerberos Tickets, with pass-the-ticket under T1550.003.

Kerberoasting and AS-REP roasting

Why Kerberoasting risk is so high

Requesting a service ticket is normal behaviour, so Kerberoasting needs no special privilege and produces only ordinary 4769 events. Part of the ticket is encrypted with the service account's key, and the attacker guesses passwords offline until one decrypts it. Service account passwords are often old, human-chosen and never rotated, and the accounts are frequently over-privileged. The joint ASD, CISA, NSA and Five Eyes guidance on Active Directory compromises says to minimise user accounts with SPNs, use group managed service accounts (gMSAs) where possible, and otherwise a unique managed password of at least 30 characters, with the account kept out of privileged groups. RC4 tickets are far cheaper to crack than AES tickets.

Targeted Kerberoasting: an attacker with write access to a user object (through an ACL such as GenericWrite) temporarily adds an SPN, requests a ticket, then removes the SPN, so any account becomes roastable. Prevention is removing unexpected write rights on user objects; detection is change auditing of servicePrincipalName.

AS-REP roasting and Kerberos pre-authentication

Pre-authentication makes the client prove it knows the password before the KDC returns anything encrypted with the user's key. When "Do not require Kerberos preauthentication" is set, anyone can request an AS-REP for the account and crack it offline. The joint guidance says to require pre-authentication for all accounts; any exception needs minimal privileges and a password of at least 30 characters for a service account or 15 for a user.

Kerberoasting detection

• Volume and novelty: one account requesting 4769 tickets for many SPNs in a short window, or for services it has never used.
• Encryption and options: 4769 with Ticket Encryption Type 0x17 where AES is normal; the joint guidance also flags Ticket Options 0x40800000 or 0x40810000 as common in offensive tooling.
• Attribute churn: 4738 or 5136 showing an SPN added then removed, or pre-authentication disabled then re-enabled.
• Honey SPN: a decoy account with an attractive SPN that nothing legitimate uses; any ticket request for it is a high-fidelity alert.

Forged tickets: golden, diamond, sapphire and silver

Golden ticket attack: with the KRBTGT key, usually obtained through DCSync or a copy of ntds.dit, an attacker builds a TGT offline for any user, with any groups and any lifetime. No KDC issued it, so there is no 4768; the first trace is a 4769 when it is used. The joint guidance lists the indicators: 4769 without a matching 4768, an encryption type weaker than the domain default, and mismatched group memberships, non-existent accounts or lifetimes far beyond the 10-hour default. It warns that attackers mimic legitimate tickets, so none of these is guaranteed.

Diamond ticket: the attacker requests a real TGT, decrypts it with the KRBTGT key, modifies the PAC and re-encrypts it, so a genuine 4768 exists. Sapphire ticket: the PAC of a real privileged user, obtained through S4U2self combined with user-to-user authentication, is placed into the attacker's ticket, so the PAC looks valid on inspection. Both still need the KRBTGT key, so prevention matches golden tickets. Detection relies on correlation: a TGT for one user and a service ticket for another from the same IP address, unusual S4U2self requests, and event 4627 showing privileged SIDs such as Domain Admins (RID 512) for a non-member, cross-checked against group change events 4728 and 4732.

Silver ticket attack: with a service or computer account key, the attacker forges a service ticket for that service and never contacts a DC. Detection must happen on the target host by correlating 4624 with 4627 and looking for SIDs and groups that do not match the directory. Prevention is gMSAs for SPN-bearing services (120-character, automatically rotated passwords), working computer password rotation, and no computer objects in privileged groups.

PAC validation and PAC signatures

Microsoft's response to PAC tampering was CVE-2022-37967 (KB5020805), which added full PAC signatures made with the KRBTGT key. Since full enforcement in October 2023, service tickets without valid signatures are denied, which blocks silver tickets that alter the PAC. KDC events 43 (Full PAC Signature Failed) and 44 (Full PAC Signature Missing) in the System log mean unpatched DCs or tampering. PAC validation does not stop an attacker who holds the KRBTGT key, because they can sign what they forge.

The KRBTGT account and KRBTGT password reset

The KRBTGT account is disabled and cannot log on, but its key protects every TGT. Each read-only domain controller has its own krbtgt_<number> account, limiting the damage of an RODC compromise. The account keeps a password history of two and the KDC accepts tickets made with either key, which is why one reset does not invalidate forged tickets and Microsoft says to reset twice.

• Routine rotation: the joint guidance says every 12 months; ATT&CK mitigation M1015 suggests about every 180 days. Pick an interval and schedule it as a tier zero control.
• Gap between resets: Microsoft says to wait at least the maximum user and service ticket lifetime (10 hours by default) and confirm replication to every writable DC before the second reset.
• Incident reset: after suspected domain compromise, reset twice. Shortening the gap during an active intrusion forces more reauthentication; that is an incident commander's call.
• Evict first: a reset only helps once the attacker's DC access, DCSync rights and persistence are gone. The Cisco Active Directory credentials leak shows the stakes: hashes reportedly including the krbtgt account resurfaced years after the intrusion.

Kerberos encryption types: RC4 Kerberos removal and Kerberos AES

Kerberos encryption types decide how hard tickets are to crack and which forgery indicators exist. Values appear in 4768 and 4769 and in the msDS-SupportedEncryptionTypes attribute.

Microsoft's CVE-2026-20833 changes run in phases. Updates from 13 January 2026 added KDCSVC audit events 201 to 209 in the System log and the RC4DefaultDisablementPhase registry value. From April 2026 the default DefaultDomainSupportedEncTypes became AES-SHA1 only (0x18) for accounts without msDS-SupportedEncryptionTypes defined. From July 2026 the audit-mode setting was removed. Windows Server 2025 domain controllers do not issue RC4 TGTs. Services that still need RC4 must have it enabled explicitly on their own account, which makes every exception visible.

1. Find RC4 use: filter 4768 and 4769 for 0x17, and use the newer fields (Advertised Etypes, Available Keys, Session Encryption Type, logged since the January 2025 cumulative update) to tell whether the client, the service account or the domain default is the cause.
2. Fix accounts without AES keys: accounts whose passwords predate AES support may hold only RC4 keys; a password reset generates AES keys.
3. Set supported types explicitly: 0x18 (24, AES128 and AES256) on SPN-bearing accounts.
4. Restrict hosts: Group Policy "Network security: Configure encryption types allowed for Kerberos" with AES128_HMAC_SHA1 and AES256_HMAC_SHA1, piloted on one server ring first.
5. Verify and roll back narrowly: failures show as 4769 Failure Code 0xE (KDC_ERR_ETYPE_NOTSUPP); roll back by re-adding RC4 to the affected account, not the domain.

Delegation, the Kerberos double hop and Kerberos relay

The Kerberos double hop problem is that a front-end service authenticated with Kerberos cannot, by default, use the user's identity to reach a second server. Delegation solves it, at a cost.

• Unconstrained delegation: the user's full TGT is cached on the front-end host, so an admin there can reuse the TGT of everyone who connects, including DCs coerced into authenticating. The joint guidance says remove it, mark privileged accounts "Account is sensitive and cannot be delegated", add them to Protected Users, disable the Print Spooler on DCs, and watch 4770 TGT renewals.
• Constrained delegation: the front-end may obtain tickets only to listed services (msDS-AllowedToDelegateTo). Protocol transition lets it impersonate users who never used Kerberos, so treat it as privileged.
• Resource-based constrained delegation (RBCD): the resource lists which front-ends may delegate to it (msDS-AllowedToActOnBehalfOfOtherIdentity), controlled by the resource administrator and working across domains. Whoever can write that attribute can grant delegation, so alert on 5136 changes to it.
• Kerberos relay: an attacker coerces or intercepts an authentication and forwards it to another service. Defences match NTLM relay: LDAP signing and LDAP channel binding on DCs, SMB signing, and Extended Protection for Authentication on web services such as certificate enrolment.

Containment: Protected Users, Kerberos authentication policies and armoring

Authentication policy events are under Applications and Services Logs, Microsoft, Windows, Authentication: 105 and 106 when a TGT or service ticket is denied in enforced mode, 305 and 306 for the same conditions in audit mode.

Detecting Kerberos attacks

Enable "Audit Kerberos Authentication Service" and "Audit Kerberos Service Ticket Operations" (success and failure) on every DC, "Audit Logon" success on servers so 4627 exists, and forward centrally. See the Windows Event Log Guide.

Metrics that show it is working:

• User accounts with SPNs, and the share converted to gMSAs or holding 30+ character passwords changed within a year.
• Share of 4768 and 4769 events using RC4 (target: zero outside documented exceptions).
• Accounts without pre-authentication and non-DC hosts with unconstrained delegation (target: zero).
• Days since the last KRBTGT double reset, against the agreed interval.
• Share of tier zero admins in Protected Users or under an enforced authentication policy.

Implementation roadmap

1. Baseline: confirm DC auditing and forwarding; inventory SPN-bearing users, accounts without pre-authentication, delegation, privileged groups and RC4 use.
2. Quick wins: remove unused SPNs, re-enable pre-authentication, deploy a honey SPN, and move admins into Protected Users one pilot group at a time.
3. Service accounts: migrate SPN services to gMSAs; otherwise unique 30+ character managed passwords and AES only; remove privileged group membership. See the Service Account Security Guide.
4. Encryption: work through the RC4 steps above until KDCSVC events are clean.
5. Delegation and relay: replace unconstrained delegation; move LDAP signing and channel binding from audit to enforcement.
6. KRBTGT: run the first double reset in a change window, document the replication checks, then schedule it.
7. Containment: build a tier zero silo in audit mode, review 305 and 306 for two to four weeks, then enforce. Rollback is returning the policy to audit, so test that first.

Decision guidance

• gMSA or managed password: choose a gMSA whenever the service runs on Windows servers that can retrieve it; use a vaulted, rotated 30+ character password only where it cannot.
• Constrained delegation or RBCD: prefer RBCD when the resource owner should decide or services span domains; classic constrained delegation when central control matters more.
• Small or large estate: small organisations get most value from removing RC4, gMSAs, Protected Users, a yearly KRBTGT double reset and 4769 alerting. Large or multi-domain estates add silos, RBCD governance and cross-host correlation of 4768, 4769 and 4627, often with an identity threat detection tool (see the ITDR Guide).

Framework mapping

Common failure patterns

• Decade-old application service accounts with short passwords and Domain Admin rights: the textbook Kerberoasting path.
• Resetting KRBTGT once, or before eviction: the previous key stays valid, or the attacker simply reads the new one.
• Detection only on DCs: silver tickets never touch the KDC, so without 4624 and 4627 from servers they are invisible.
• Forcing AES domain-wide in one step: appliances and accounts without AES keys fail together.
• Service accounts in Protected Users: the service breaks and the control gets rolled back for everyone.
• Unconstrained delegation on legacy servers: one compromised file or print server collects admin and DC TGTs.

Practitioner checklist

• Audit Kerberos Authentication Service and Service Ticket Operations on every DC; forward 4768 to 4771 centrally.
• Remove unused SPNs; move the rest to gMSAs or 30+ character managed passwords.
• Require pre-authentication everywhere and alert on 4768 Pre-Authentication Type 0.
• Clear KDCSVC 201 to 209 warnings and set msDS-SupportedEncryptionTypes to 0x18 on SPN accounts.
• Reset KRBTGT twice on a schedule, waiting at least the maximum ticket lifetime between resets, and again after eviction from any compromise.
• Remove unconstrained delegation outside DCs and alert on delegation attribute changes.
• Put human tier zero admins in Protected Users and mark them "sensitive and cannot be delegated".
• Deploy a honey SPN account and alert on any ticket request for it.
• Collect 4624 and 4627 from high-value servers to catch silver and sapphire tickets.
• Enforce LDAP signing and channel binding to close relay paths.

Standards and references

• ASD, CISA, NSA et al.: Detecting and Mitigating Active Directory Compromises
• MITRE ATT&CK: T1558 Steal or Forge Kerberos Tickets
• MITRE ATT&CK: T1550.003 Pass the Ticket
• Microsoft: How to manage Kerberos KDC usage of RC4 (CVE-2026-20833)
• Microsoft Learn: Detect and remediate RC4 usage in Kerberos
• Microsoft Learn: Reset the krbtgt password
• Microsoft Learn: Authentication policies and authentication policy silos
• Microsoft Learn: Event 4769, a Kerberos service ticket was requested

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Service Account Security Guide · ITDR Guide · Lateral Movement Guide · Windows Event Log Guide