PAC and group information: The relationship between the ticket, access token, and resource authorization

1. Core mechanism

The KDC that issues the ticket (DC01), the service that accepts the ticket (e.g. FS01), and the access token created by the service. The PAC is carried in the authorization-data field in the EncTicketPart of the ticket; It is wrapped with ASN.1, but its content is a binary structure serialized with NDR. The boundary of this lesson is the bridge between authorization data and access token: AS/TGS flow is at 06.02, SPN→key is at 06.03, preauth and session key are at 06.04. The access check itself goes deep into the ACL section (05.x).

Interfaces and specifications

• RFC 4120 §5.2.6: AuthorizationData ::= SEQUENCE OF SEQUENCE { ad-type [0] Int32, ad-data [1] OCTET STRING }; §5.2.6.1 AD-IF-RELEVANT (ad-type 1), unclear elements can be ignored.
• MS-KILE:PAC is encoded as AD-WIN2K-PAC (ad-type 128) and wrapped in AD-IF-RELEVANT (ad-type 1) and placed in the ticket authorization-data.
• MS-PAC §2.3 PACTYPE { cBuffers (ULONG), Version (ULONG, must be 0) } and §2.4 PAC_INFO_BUFFER { ulType, cbBufferSize, Offset }; ulType 0x1 Logon Information, 0x6 Server Signature, 0x7 KDC Signature.
• MS-PAC §2.5 KERB_VALIDATION_INFO: UserId, PrimaryGroupId, GroupIds (GROUP_MEMBERSHIP array: RelativeId + Attributes) and ExtraSids; group membership is carried over here.
• MS-PAC §2.8 PAC_SIGNATURE_DATA: Generated with Server Signature service key, KDC Signature with krbtgt key; signature verification checks the integrity of the PAC.
• Microsoft · Access tokens: the token carries the user's SID and group SIDs and access check is done with this token.

Where does the PAC stop inside the ticket?

There is an authorization-data field in the encrypted EncTicketPart part of the Kerberos ticket. On Windows, this field contains the PAC that carries the user's authorization data. The PAC is not wrapped directly, but in two layers: first as the element AD-WIN2K-PAC (ad-type 128), then this element is put into AD-IF-RELEVANT (ad-type 1).

This wrapping is not accidental. AD-IF-RELEVANT implements RFC 4120's "party may ignore" rule: a Kerberos application that does not recognize the PAC will ignore it, while a Windows service that does will open it and use it. Thus, Microsoft carries Windows-specific authorization data without breaking standard Kerberos.

Critical distinction: the outer layer is ASN.1 (DER/TLV), but the PAC inside the ad-data OCTET STRING of AD-WIN2K-PAC is not ASN.1. It is a little-endian binary structure serialized with NDR. A general ASN.1 reader reaches the OCTET STRING boundary and cannot go inside; From there it is a different coding.

Inside the PAC: header, buffers and group information

PAC starts with a PACTYPE header: cBuffers tells how many buffers there are, Version tells the version (must be 0). After the Header comes the PAC_INFO_BUFFER string; Each entry carries an ulType (buffer type), cbBufferSize (size), and Offset (position within the PAC). The bodies of the buffers sit at these offsets, aligned to 8-byte boundaries.

Group information is in the Logon Information buffer (ulType 0x1), i.e. in the KERB_VALIDATION_INFO structure. This structure contains the user's UserId (RID), PrimaryGroupId, array of GroupIds (GROUP_MEMBERSHIP, each carrying a RelativeId and Attributes), and a list of ExtraSids. So "which groups is the user in?" The answer to the question is physically carried here, in the encrypted section of the ticket.

Therefore, the ticket carries not only "who" but also "with what authority context" information. But this information is in the encrypted ticket; it cannot be read from outside, for example from a 4769 register.

Authorization-data (ASN.1 / DER)
  AD-IF-RELEVANT (ad-type 1)
    AD-WIN2K-PAC (ad-type 128)
      ad-data = OCTET STRING  <-- ASN.1 okuyucu burada durur
        |
        +-- PACTYPE { cBuffers, Version=0 }        (NDR / little-endian, ASN.1 DEGIL)
        +-- PAC_INFO_BUFFER[]  ulType/cbBufferSize/Offset
              0x1 Logon Information  -> KERB_VALIDATION_INFO (UserId, PrimaryGroupId,
                                        GroupIds[], ExtraSids[])   <-- grup bilgisi
              0x6 Server Signature   -> servis anahtariyla
              0x7 KDC Signature      -> krbtgt anahtariyla

Signatures: Why PAC can be trusted

PAC checksum requirements depend on the ticket context. The current MS-PAC §2.4 table requires Server Signature (0x6) and KDC Signature (0x7) for TGS/AP PACs; TGS PACs also require Ticket Signature (0x10) and Extended KDC Signature (0x13). “Every PAC has only two signatures” is therefore inaccurate. Version and security updates also matter to actual validation behavior.

Server Signature depends on the service key and KDC Signature on the KDC/krbtgt key. These checksum buffers and encryption of a TGT’s EncTicketPart with the krbtgt key are separate operations. Service and KDC perform their respective validation roles; counting checksum names does not establish key ownership.

Validation establishes protection of the covered data by the key owner; it does not independently prove that group data matches the directory’s current state. The 83-byte fragment in this lesson shows an encoding boundary and an incomplete buffer directory: it is not a valid, complete or signed PAC.

PAC to access token, token to access check

When the service accepts the ticket and verifies the PAC, it creates an access token from the user SID and group SIDs in the PAC. On Windows, the authorization decision is made with this token, not with the ticket itself: access check compares the ACEs in the resource's DACL with the SIDs in the token.

That's why the chain has three links. Carries ticket ID and (via PAC) group context; The token makes this context operational; access check decides access to the resource via token. The principle of "buying a ticket is not getting authorization" that we saw in 06.02 is embodied here: the ticket carries the group SIDs, but evaluates the access through the resource, token, in a separate step.

In this lesson’s group-ACE example, access depends on an enabled matching group SID and an ACE allowing the operation. That group is not required for every possible access: user SID, other enabled group SIDs, ACE scope and operation-specific privilege/authorization paths can also affect the decision. A signed PAC does not bypass the resource decision.

State and data flow

1. When issuing a ticket, KDC creates a PAC from the user's group membership in the directory and writes the UserId, PrimaryGroupId, GroupIds, and ExtraSids to KERB_VALIDATION_INFO.
2. The KDC produces the PAC checksums required for the ticket context, keeping Server/KDC and Ticket/Extended KDC roles distinct.
3. The PAC is wrapped in AD-IF-RELEVANT (1) as AD-WIN2K-PAC (128) and placed in the authorization-data field of the ticket's encrypted EncTicketPart.
4. The client submits the ticket to the service (AP-REQ); the client cannot read or modify the PAC because the ticket is encrypted with the service key.
5. Opens a service ticket, verifies the PAC's Server Signature with its own key; When necessary, KDC is contacted for KDC Signature verification.
6. The service creates an access token from the SIDs in the PAC.
7. Each time the resource is accessed, access check makes a permission/denial decision by comparing the SIDs in the token with the DACL of the resource.

2. Exploitation

Broken trust assumption

Broken assumption: "Group SIDs in the token are always true to what the token says; since it is signed by the PAC, its content is also true." In reality, trust in the content of the PAC relies on the validity of the signatures, and signatures rely on the confidentiality of the signing keys. Since KDC Signature is generated with the krbtgt key, if the krbtgt key is compromised, an attacker can generate a PAC with any group SIDs (e.g. Domain Admins RID 512) and sign it with a valid KDC signature. When this ticket is verified the signature appears 'valid', but the group information inside is completely fabricated. This is the core of the Golden Ticket technique.

Technical prerequisites

• This risk assessment concerns loss of confidentiality of the KDC/krbtgt long-term key material for the relevant encryption type. RC4 and AES keys cannot be generalized under one data label; “password hash” is not an accurate description for every enctype.
• Knowing the real group SIDs (e.g., well-known RIDs of established privileged groups) for the fake PAC to make sense on the target resource.
• Evaluate the TGT encryption key separately from the validation roles of PAC checksum buffers. This section explains the impact of losing a trust root; it is not a ticket-construction or validation-bypass procedure.
• Windows updates implementing current PAC-validation behavior must be present on Windows clients, DCs, and relevant service hosts validating inbound PACs; for CVE-2024-26248/-29056, security updates released in or after April 2025 remove compatibility registry subkeys and enforce secure behavior. This does not restore trust in a compromised krbtgt key; Golden Ticket recovery separately requires krbtgt recovery.

Exploitation mechanism

The mechanism is the result of authorization data's trust model. KDC signs the PAC with the krbtgt key; The service considers this signature as proof that 'KDC produced it'. If the krbtgt key is known, the attacker mimics this step: writes the desired GroupIds/ExtraSids to KERB_VALIDATION_INFO, creates the PACTYPE header and buffers, calculates the KDC Signature with the krbtgt key, and puts the PAC in a ticket. When the service opens the PAC and verifies the signature, it keeps the signature; The token is created with these fake SIDs and access check treats them as real memberships. No Kerberos rules are broken; what is being violated is the 'krbtgt key remains only in the KDC' assumption.

Why don't ticket events show this?

Golden Ticket is a forged TGT; Since it is not produced by KDC, it does not leave a 4768 (TGT issued) record at the time of issuance. However, when a service ticket is requested with this TGT, DC generates a 4769. So a 4769 without an 'ancestor' may appear on DC.

However, record 4769 does not show the contents of the PAC; Which group SIDs will enter the token is included in the encrypted ticket. Telemetry sees that the ticket is issued, but not the authorization data it carries.

So rather than trying to read PAC content from DRC events, the defense looks at indirect traces of pseudo-TGT usage and observations on the token side.

Scope and limit

The scope of the Golden Ticket is the scope of the krbtgt key: that key belongs to a domain, so forgery is valid in that domain. Cross-domain domains require separate trust and key evaluation.

The effect is strong because arbitrary group SIDs can be placed on the token; But the precondition is also strong: the capture of the krbtgt key is already the result of a serious compromise. That's why the Golden Ticket is not a start, but a tool for permanence and authority enhancement.

Microsoft’s two-reset forest-recovery guidance applies to the domain krbtgt account on writable DCs. Replication of the first change and configured user/service ticket lifetimes must both be considered; the default is 10 hours, with a longer wait for longer policy values. RODC-specific krbtgt_number accounts are separate and require the RODC recovery context.

3. Defense & Detection

Telemetry scope

• KDC ticket events (4768 TGT, 4769 service tickets) occur only on the domain controller; these show that the ticket was issued, but DO NOT show the group content of the PAC.
• The observable counterpart of the PAC's group information is the logon token on the source/host side; group membership and privilege events are looked up on the machine where the session occurred.
• There is no direct 'fake PAC' incident for Golden Ticket; the signal is indirect: the use of 4769 without ancestor 4768, unusual ticket lifetimes, and the appearance of high-value groups in unexpected sessions.
• krbtgt management is a separate recovery surface: after suspected compromise, evaluate reset history, DC replication, and ticket lifetime together rather than assuming routine rotation alone is sufficient.
• The volume of ticket incidents is high; Since PAC contents are not visible, it is misleading to monitor changes in authority through them alone.

Events and relevant fields

• 4769 / TargetUserName and ServiceName: indicates to whom and to which service the ticket request belongs; It does not show group SIDs in the PAC.
• 4769 / TicketOptions and TicketEncryptionType: ticket flags and encryption type. These fields do not expose ticket start/end times or PAC contents; compare unusual values with policy and the service inventory.
• 4768: indicates a TGT has been issued; Golden Ticket does not drop this event, so the discrepancy between 4769 and 4768 is a point of observation.
• Source host session record: The group and privilege content of the token derived from the PAC appears in the record of the session, not the ticket. This lesson marks this as a separate point of observation.
• Note: this lesson does not claim a new Event ID that carries PAC fields directly; The domain schema of host-side events reporting group SID content has not been verified from the primary source in this session and is not fabricated here.

Ticket event does not show PAC

4769 or 4768 says a ticket has been issued; It does not tell the group SIDs inside. The PAC is in an encrypted EncTicketPart and is not reflected in the KDC transaction log. So 'which groups did the user come with a ticket with?' The question cannot be answered from ticket events.

The observable counterpart of the group context is the access token from which the ticket derives, and this token occurs on the source host. The correct observation point to monitor the privilege change is not the KDC but the machine where the session was established.

Accepting this limit protects from false positives and false model: ticket telemetry is for identity and flow; For authorization content, look at the token side.

Detection logic · Sigma

title: Yuksek degerli servis icin ata TGT'si olmayan service ticket kullanimi (heuristic)
id: 8b1c4e70-2f9d-4a61-9d2a-06e5b3a0c205
status: experimental
description: >
  Golden Ticket forged bir TGT'dir ve DC'de 4768 birakmaz, ancak bu TGT ile
  istenen service ticket 4769 uretir. Kural, yuksek degerli ServiceName'ler icin
  4769 secer; asil mantik (ayni hesap icin bilet omru penceresinde eslesen bir
  4768'in YOKLUGU) backend korelasyonu gerektirir. Tek basina kanit degildir.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    Status: '0x0'
  condition: selection
fields:
  - TargetUserName
  - ServiceName
  - TicketOptions
  - TicketEncryptionType
  - IpAddress
falsepositives:
  - Log saklama penceresi disinda kalmis mesru 4768 (TGT gunluk rotasyonu)
  - WEF/toplama gecikmesi nedeniyle eksik 4768 kayitlari
  - Uzun omurlu mesru TGT'ler ve yenileme senaryolari
level: low

Query assumptions

• This is a correlation skeleton for candidate-event investigation. An absent matching 4768 alone does not prove a forged TGT: collector coverage, domain controllers, retention, time window and legitimate older-ticket use must be checked separately. Sigma does not compute that absence here; validate field mappings and the window in the backend.
• 4769 domain names are EventData names in the Windows Security channel and have been validated against documentation 4769 in this session. 4768's field mapping depends on the backend and is not further verified here.
• The rule does not read the contents of the PAC; cannot read it either, because group SIDs are in the encrypted ticket. This is a conscious limit: heuristic looks at the indirect trace of pseudo-TGT use.
• The high-value ServiceName set and threshold are defined based on the environment inventory; It is not fixed.
• This rule was not run on a real SIEM in this session; only 4769 semantics verified against primary source.

False positives

• Legitimate 4768 records outside the log storage window render the ancestor TGT invisible and produce false positives.
• WEF or collection delay may cause 4768 and 4769 to arrive at different times.
• Legitimate long-lived TGTs that have been refurbished may have a 4768 that is out of the window.
• Negative example: if the krbtgt key has not been obtained yet, this heuristic sees no real Golden Ticket; The rule is not a confidence check, but an anomaly marker.

Hardening

• For suspected krbtgt compromise, follow Microsoft’s forest-recovery procedure: perform two resets; before the second, confirm the first change has replicated to DCs and wait longer than the configured Maximum lifetime for user ticket / service ticket. The defaults are 10 hours; higher values require a longer wait.
• Keep DCs, relevant Windows clients, and service hosts validating inbound PACs updated for CVE-2024-26248/-29056; updates released in or after April 2025 remove the PacSignatureValidationLevel and CrossDomainFilteringLevel compatibility registry subkeys and enforce secure behavior. Validate normal Kerberos flows and relevant audit/compatibility signals. This update path does not replace recovery/key rotation after a krbtgt compromise.
• make krbtgt and tier-0 identities harder to compromise: limit privileged access to Enterprise Access Model; Reduce paths that can access krbtgt.
• Monitor high-value group SIDs (such as Domain Admins) appearing in unexpected sessions with source host token telemetry; this is a point of indirect observation of the PAC content.
• Verification step: for krbtgt recovery, confirm replication of the first reset and the configured ticket-lifetime wait between resets; then check normal Kerberos service flows and that forged tickets relying on the retired key no longer validate. Separately assess PAC-validation update compatibility across the updated client/DC and relevant PAC-validating service-host scope and relevant audit signals.

Read the examples

30 51 30 4f a0 03 02 01 01 a1 48 04 46 30 44 30
42 a0 04 02 02 00 80 a1 3a 04 38 03 00 00 00 00
00 00 00 01 00 00 00 c0 00 00 00 38 00 00 00 00
00 00 00 06 00 00 00 1c 00 00 00 f8 00 00 00 00
00 00 00 07 00 00 00 1c 00 00 00 18 01 00 00 00
00 00 00

Two reality checks

Assumption: When you remove a user from a group, that user's access to resources immediately ends.

In fact: A PAC is a snapshot in an existing ticket. Removing group membership does not retroactively rebuild an established target token or open session. A new ticket/PAC and a new target context are distinct stages; ticket expiration does not guarantee simultaneous termination of an existing session.

Assumption: Since PAC is signed, the group information in it can be trusted under all circumstances.

In fact: PAC checksums are evaluated in their ticket context; TGT encryption and PAC checksum validation are not the same operation. If confidentiality of the relevant key is lost, successful validation alone does not prove consistency with current directory data. Interpret validation alongside key security, context creation time and resource authorization.

Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §5.2.6 AuthorizationData (ad-type/ad-data) and §5.2.6.1 AD-IF-RELEVANT (ad-type 1, unknown elements may be ignored); §5.3 EncTicketPart authorization-data field.
• Microsoft Open Specifications · [MS-PAC] Privilege Attribute Certificate Data Structure
  §2.3 PACTYPE (cBuffers, Version=0); §2.4 PAC_INFO_BUFFER (ulType, cbBufferSize, Offset; 0x1 Logon Information, 0x6 Server Signature, 0x7 KDC Signature); §2.5 KERB_VALIDATION_INFO (UserId, PrimaryGroupId, GroupIds, ExtraSids); §2.8 PAC_SIGNATURE_DATA (Server and KDC signatures).
• Microsoft Open Specifications · [MS-KILE] Processing Authorization Data
  Encoding the PAC as AD-WIN2K-PAC (ad-type 128), wrapping it inside AD-IF-RELEVANT (ad-type 1), and placing it in the ticket authorization-data.
• Microsoft · Access tokens
  The access token carrying the user SID and group SIDs; the access check comparing the SIDs in the token with the DACL.
• Microsoft Support · How to manage PAC Validation changes related to CVE-2024-26248 and CVE-2024-29056
  Update both domain controllers and Windows clients; updated secure PAC validation behavior for these vulnerabilities; January 2025 enforcement-by-default and April 2025+ removal of PacSignatureValidationLevel/CrossDomainFilteringLevel compatibility registry subkeys and enforcement of secure behavior.
• Microsoft Learn · Active Directory Forest Recovery — Reset the krbtgt password
  Reset twice; wait 10 hours between resets because that is the default maximum lifetime for user and service tickets; when configured lifetimes are higher, wait longer. Recovery procedure for writable DCs; RODC krbtgt accounts are distinct.
• Microsoft Open Specifications · PAC buffer requirements
  §2.4: context-specific 0x6/0x7/0x10/0x13 requirements; current specification, not all historical Windows versions.
• Microsoft Learn · Event 4768
  TGT issuance visibility; absence requires collection/window checks.
• Microsoft Learn · Event 4769
  Service-ticket request/result fields; no PAC group data or ticket lifetime field.