KRBTGT: Architecture, Trusts, PAC, and the Evolution of Ticket Attacks
Core terms
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. Sean Metcalf on ADSecurity.org summarizes this by stating that 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. ADSecurity highlights this separation as part of the RODC design.
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.
KRBTGT credential material in Active Directory
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.
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 2024/2025 hardening
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 (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.
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.
klist showing TGT and TGS
What matters:
Server: krbtgt/...identifies the TGT, which is bound to KRBTGT key material.KerbTicket Encryption Typeis the ticket’s etype - use it to detect baseline deviations (e.g., RC4 where you expect AES).
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.
Event 4768 with Encryption Type 0x12 AES256-CTS-HMAC-SHA1-96
Event 4769 with Encryption Type 0x12 AES256-CTS-HMAC-SHA1-96
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
msDS-KeyVersionNumber changing when password is changed
Interpretation:
- When KRBTGT is reset,
msDS-KeyVersionNumberincrements (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.”
attribute msDS-SupportedEncryptionTypes when account has AES configured as supported
Conclusion
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).