KRBTGT: Architecture, Trusts, PAC, and the Evolution of Ticket Attacks

Core terms

As this article contains a lot of terms that are very important for understanding Kerberos and Active Directory, I will explain them first.

Principal

A principal is an identity in Kerberos. In Active Directory, this typically maps to a security principal (user, computer, service account). The practical implication is that a principal has a long-term key (derived from its password) that the KDC uses when issuing tickets.

Realm

A realm is the administrative and cryptographic boundary in Kerberos. In Windows environments, it usually maps to an AD domain (DNS name uppercased). The protocol foundation is Kerberos V5 as defined in RFC 4120.

KDC

The Key Distribution Center (KDC) issues and validates Kerberos tickets. In AD, the KDC role runs on each Domain Controller (DC). Kerberos V5 authentication is built around the AS, TGS, and AP exchanges described in RFC 4120.

Ticket, TGT, service ticket

A ticket is a credential intended for the server side and is typically encrypted with the long-term key of the target service, not the client. A TGT is a special ticket for krbtgt/REALM and is used as input to the TGS exchange. A service ticket is issued for a specific service (commonly identified by an SPN).

PAC

The Privilege Attribute Certificate (PAC) is a Windows extension that carries authorization data (for example, group membership) inside Kerberos tickets. This is central for building the Windows access token.

PAC validation

PAC validation is a process where the server-side OS forwards PAC-related verification to a Domain Controller. Microsoft’s MS-APDS describes that the OS forwards the PAC signature from the AP-REQ to a DC in a message such as KERB_VERIFY_PAC, and the DC returns the result.

Etype

An etype (encryption type) defines which crypto profile protects a ticket. In AD, etype is not only a crypto choice; it’s also a configuration and detection signal (baseline vs deviation). Microsoft defines msDS-SupportedEncryptionTypes as describing the etypes supported by user/computer/trust accounts and notes KDC uses this when generating service tickets.

KVNO and msDS-KeyVersionNumber

KVNO (Key Version Number) indicates which version of a key was used. In AD, it effectively tracks key material changes (password changes). Microsoft defines msDS-KeyVersionNumber as “Kerberos version number of the current key for this account.”

The AD Kerberos key model (what KRBTGT protects—and what it does not)

Most operational and incident mistakes come from mixing up three different key planes. You should treat them as separate “cryptographic axes”.

KRBTGT key (domain key for TGTs)

The KRBTGT key is the long-term key derived from the KRBTGT account password in a given domain. The KDC uses it to protect TGTs (the ticket for krbtgt/REALM). The practical consequence is straightforward: compromise of the KRBTGT key compromises the domain’s ability to trust TGTs as domain-issued credentials. Each AD domain has a KRBTGT account used to encrypt and sign Kerberos tickets for the domain.

Service account key (key of the target service)

A service ticket is encrypted with the long-term key of the target service (service account key, or computer account key for services running under LocalSystem on a member server). Resetting a service account password affects that service’s tickets, not the entire domain’s TGT trust.

Trust secret / inter-realm key (key of a trust relationship)

Cross-realm scenarios rely on the trust secret stored in the Trusted Domain Object (TDO). Microsoft explicitly notes that key versioning for trusts is stored in the trusted domain object, not in msDS-KeyVersionNumber of ordinary accounts.

Operationally: resetting KRBTGT does not reset trust secrets; resetting trust secrets does not reset KRBTGT.

RODC: cryptographic isolation by design

A Read-Only Domain Controller uses a dedicated KRBTGT account (commonly krbtgt_#####) and therefore a separated key space, which limits the blast radius of an RODC compromise compared to a writable DC compromise.

KRBTGT in a domain: KVNO, rotation, and why a reset is done twice

KRBTGT is an account object, but its purpose is systemic. In practice it is rarely touched except for hygiene or recovery.

The key operational fact is password history. Microsoft’s FAQs from the Field on KRBTGT Reset states that KRBTGT maintains a password history of size 2, which is why organizations reset it twice to invalidate tickets tied to older key material.

What this means in plain terms: after the first reset, older key material may remain valid as the “previous” key for a while. The second reset pushes the older key out of history, completing the invalidation.

As you can see in the figure below, the current keys are marked in a green box, and the previous keys are marked in a purple box.

In incident response, this must be paired with Tier 0 containment. If an adversary still has DC-level access or replication rights, they can simply obtain the new key material again. A KRBTGT reset is a cryptographic rotation, not a full eradication step. I must mention here that to gain again confidence in Active Directory security, it needs to be built completely from scratch (see my favorite “burn the forest!”).

PAC signatures: why “what’s inside PAC” is not enough

PAC carries authorization data, so it directly influences the access token built on the target system. This is why signatures and validation are central.

Microsoft’s MS-PAC defines how PAC signatures are tied to specific keys. In PAC_SIGNATURE_DATA, ulType indicates which key is used: 0x00000006 corresponds to the server key and 0x00000007 corresponds to the KDC key.

Operational consequence: if PAC content is modified, signatures must remain consistent with the correct keys, or validation fails. This is one reason modern adversaries focus on obtaining PAC content that is structurally and cryptographically consistent with KDC behavior.

A second nuance matters for hunting - KDC can alter PAC content depending on issuance context. Microsoft’s MS-KILE states that when issuing a service ticket where Domain Local Group Membership is processed, KDC must remove PAC_REQUESTOR and PAC_ATTRIBUTES_INFO from the PAC in the ticket. So “missing” PAC structures are not automatically suspicious - they can be expected.

PAC validation and the changes after CVE‑2024‑26248 / CVE‑2024‑29056

The baseline PAC validation flow is described in MS‑APDS: the client presents AP-REQ to the server; the server passes PAC to the OS; the OS sends a KERB_VERIFY_PAC request to a DC; the DC validates and returns the result; and the server completes the authentication flow.

Microsoft’s support guidance for CVE-2024-26248 and CVE-2024-29056 explains that updates beginning April 9, 2024 address elevation of privilege issues in the Kerberos PAC Validation Protocol and explicitly notes PAC is a Kerberos extension in service tickets.

The key point is not “a new Kerberos.” The point is stricter and more deterministic validation and filtering of authorization data, especially across domain boundaries.

Microsoft also describes cross-domain forwarding behavior. Validation requests may be forwarded across trusts “until it reaches the service’s domain,” and each DC involved in forwarding filters authorization data relevant to that domain.

This is where confusion often arises around “Netlogon”. The practical interpretation is: Windows uses domain infrastructure and forwarding mechanisms to route validation to the authoritative domain context. It does not imply Kerberos becomes NTLM; it implies the validation routing uses AD trust plumbing.

Monitoring consequence: if you want to understand accept/deny outcomes, you often need visibility not only on DC issuance (Events 4768/4769), but also on the systems receiving inbound Kerberos and performing validation. Microsoft frames this in rollout phases and emphasizes patching both DCs and clients for full mitigation.

Etypes, RC4, and why etype deviations are high-value signals

Etype choice is strongly influenced by account configuration, especially msDS-SupportedEncryptionTypes. Microsoft defines this attribute as listing supported algorithms for user/computer/trust accounts and notes KDC uses it when generating service tickets.

RC4 is being deprecated. Microsoft’s Detect and remediate RC4 guidance states it plans to disable RC4 as the default etype for AD domain controllers by the end of Q2 2026. The same line of guidance links RC4 usage to Kerberos audit events such as 4768 and 4769, and Microsoft also notes relevant event-format changes for newer updates/OS versions.

Defensively, once your environment is AES-dominant, sudden RC4 appearances are either a legacy dependency or a suspicious deviation that deserves immediate explanation.

Golden, Diamond, Sapphire: behavioral categories (not procedures)

This section stays at the level of defensive reasoning - what changes in telemetry and what “should” look consistent. It is not a detailed description of the mechanism of the attack.

Golden Ticket (forged TGT)

A Golden Ticket scenario results in a TGT that is cryptographically valid for the domain but may not align with normal issuance traces. Defensively, the typical issue is divergence between downstream service-ticket activity and expected TGT issuance context, plus etype or lifetime anomalies relative to baseline.

Diamond Ticket (modifying a legitimately issued ticket)

Diamond Ticket is commonly described as starting from a legitimately issued ticket and then altering authorization-relevant content. The key defensive implication is that DC issuance may look normal; detection therefore shifts to behavioral context: service access patterns, device/source consistency, privilege footprint vs AD state, and etype baselines.

Sapphire Ticket (delegation-assisted PAC legitimacy)

Sapphire Ticket is usually discussed as increasing the credibility of authorization data by leveraging delegation mechanics so that PAC content appears consistent with KDC-generated structures. S4U2self appears in these discussions because Microsoft defines it as allowing a service to obtain a service ticket “to itself” on behalf of a user, thereby receiving that user’s authorization data in the ticket. Defensive implication: a “valid-looking PAC” is not inherently benign. You must evaluate delegation configuration, trust topology, and whether the flow matches the application’s legitimate design.

Practical diagnostics: klist, identifying TGTs, reading etypes, and retrieving KVNO correctly

This section is meant for operational checks and investigations. My goal was not to extensively describe all possible analysis approaches.

Reading klist on Windows: spotting the TGT and etype

On Windows, klist prints cached tickets in the current logon session. The TGT is the one where the server is krbtgt/REALM@REALM. Service tickets will show SPNs like cifs/host@REALM or HTTP/app@REALM.

What matters:

• Server: krbtgt/... identifies the TGT, which is bound to KRBTGT key material.
• KerbTicket Encryption Type is the ticket’s etype - use it to detect baseline deviations (e.g., RC4 where you expect AES).
• Session Key Type is the etype used to encrypt the session key in the ticket.

On the DC side, Microsoft documents 4768 and 4769 as the core events for Kerberos ticket requests, and their structure/fields matter for encryption-type visibility.

KVNO: why klist usually doesn’t show it, and how to fetch it properly

Windows klist commonly doesn’t print KVNO explicitly. The correct authoritative source for the current key version in AD is the account attribute msDS-KeyVersionNumber, which Microsoft defines as the Kerberos version number for the current key.

PowerShell (RSAT / ActiveDirectory module):

Get-ADUser -Identity krbtgt -Properties msDS-KeyVersionNumber,pwdLastSet | Select-Object SamAccountName,msDS-KeyVersionNumber,pwdLastSet Get-ADComputer -Identity "FILESRV01$" -Properties msDS-KeyVersionNumber,msDS-SupportedEncryptionTypes | Select-Object Name,msDS-KeyVersionNumber,msDS-SupportedEncryptionTypes

Interpretation:

• When KRBTGT is reset, msDS-KeyVersionNumber increments (useful for timeline reconstruction).
• When a service account/computer account password changes, its key version changes—correlate with service outages or ticket failures.

Quickly assessing why RC4 appears

If you see RC4 in klist or on DC events, check msDS-SupportedEncryptionTypes. Microsoft defines it as the account’s supported algorithms, and KDC uses it when generating service tickets. In practice, “RC4 shows up” is often “the account doesn’t have AES keys enabled/available,” not “someone forced RC4 intentionally.”

Three keys and how often to rotate KRBTGT password

To reason correctly about KRBTGT in modern AD, you must separate three cryptographic planes: KRBTGT key (TGT trust), service account key (service ticket confidentiality), and trust secret (cross-realm referral trust). Operational fixes and incident actions only make sense when mapped to the right plane.

PAC is central because it carries authorization data, and PAC signatures plus PAC validation define whether that data is trusted. Microsoft provides normative specifications for PAC signatures and validation behavior and operational guidance for hardening changes and enforcement timelines.

Finally, practical troubleshooting and hunting should be correlation-driven: client-side cache (klist), DC-side issuance telemetry (4768/4769), and AD-side truth (msDS-KeyVersionNumber, msDS-SupportedEncryptionTypes).

So, how often should we rotate KRBTGT password?

Industry Standard

The widely accepted security standard across government and enterprise frameworks mandates resetting the KRBTGT account password at least every 180 days. This recommendation is codified in the Microsoft Windows Server STIG (Security Technical Implementation Guide) and endorsed by DISA (Defense Information Systems Agency) compliance frameworks. The 180-day interval represents a measured balance between security posture and operational stability. Any longer than this window substantially increases the window of opportunity for attackers - should the KRBTGT hash be extracted from an offline backup or through direct compromise of a domain controller, every authentication ticket issued during the extended period becomes vulnerable to forging by malicious actors.

The Two-Reset Procedure

KRBTGT password rotation requires a two-step reset process separated by a minimum interval — not a single password change. This dual-reset methodology is mandatory because as we described Active Directory maintains a password history of two entries for the KRBTGT account. This two-reset approach must occur within the TGT lifetime window — typically 10 hours by default, though organizations should verify their domain’s actual “Max TGT Lifetime (Hours)” setting. Waiting at least 10 hours between resets allows existing Kerberos tickets to expire naturally, preventing authentication failures when clients attempt to validate tickets against updated domain controller KRBTGT keys.

Operational considerations and timing

Organizations should coordinate KRBTGT password rotations during scheduled maintenance windows, ideally when domain activity is lowest, to minimize authentication disruptions. Replication convergence is critical - the first password change must propagate to all domain controllers before the second reset occurs, typically requiring 12–24 hours of monitoring. Premature back-to-back resets without full replication can break domain connectivity, particularly on older Unix-based systems that cache Kerberos credentials. Establishing at least 24 hours between resets has emerged as a pragmatic operational standard that ensures replication completes while maintaining security discipline. You can also use specific AD scripts to rotate the password in controlled manner including replications. Many organizations adopting more aggressive schedules — such as quarterly or monthly rotations — do so as part of enhanced security posture rather than strict compliance necessity.

Exceptional circumstances warrant immediate action

While the 180-day cycle applies to routine maintenance, immediate KRBTGT password reset becomes mandatory following suspected or confirmed domain compromise, or upon departure of privileged administrators with KRBTGT access (including access to offline backups containing KRBTGT). In incident response scenarios, the two resets should be performed within hours rather than days to rapidly invalidate any adversary-created Golden Tickets and force re-authentication of all session tokens.

Clarifying Microsoft’s official stance

It is worth noting that Microsoft’s official position, as articulated in their FAQs from the Field on KRBTGT Reset Blog, states there is “no specific recommendation regarding password reset frequency for the KRBTGT account.” Rather, Microsoft recommends organizations establish their own interval “taking into consideration backup schedules, operational procedures, security requirements, etc.” This flexibility has led to industry consensus converging on the DISA STIG standard of 180 days as the practical de facto benchmark, particularly for regulated environments where compliance audits expect documented rotation schedules. Quarterly or more frequent rotations strengthen security posture but introduce operational overhead without providing exponentially greater protection under normal (non-compromise) circumstances.

So?

Reset the KRBTGT account password every 180 days minimum as a foundational Active Directory security control. Implement the two-reset procedure with time separation to ensure replication convergence and maintain domain stability. Document each rotation with timestamps and monitoring notes, and accelerate the schedule immediately upon any indication of compromise. This disciplined approach substantially constrains the useful lifetime of extracted KRBTGT hashes, materially reducing your domain’s vulnerability to Golden Ticket and other persistence attacks.