Skip to content
Hermes Codex

The Kerberos PAC: Structure, Validation, and Forgery

Concept

Section titled “Concept”

When a security principal authenticates to an Active Directory KDC, the KDC constructs a binary structure known as the PAC and injects it into the encrypted payload of the TGT, and subsequently into requested TGS tickets.

The PAC encapsulates:

  1. Principal Security Identifiers: The account’s primary SID (UserSid) and primary group identifier (PrimaryGroupId).
  2. Security Group Memberships: An exhaustive array of domain group RIDs (GroupIds), along with cross-domain or legacy SIDs (ExtraSids / sIDHistory).
  3. Cryptographic Integrity Signatures:
    • Server Signature: Signed using the target service account’s secret key (proves the receiving service did not tamper with the PAC).
    • KDC Signature: Signed using the domain KDC krbtgt key (proves the PAC was authored by an authoritative KDC).
    • Ticket Signature & Full PAC Checksum (post CVE-2022-37967 / KB5020805): Modern cryptographic signatures preventing PAC manipulation and cross-service ticket reuse.

Why It Matters in DFIR

Section titled “Why It Matters in DFIR”

The PAC is the primary structural target of high-impact Windows privilege escalation techniques:

  • PAC Forgery (Golden / Diamond / Silver Tickets): An adversary possessing krbtgt keys or service account hashes can fabricate a synthetic PAC, granting themselves arbitrary high-privilege memberships like Domain Admins (RID 512).
  • Historical Elevation Flaws (MS14-068 / CVE-2014-6324 and CVE-2021-42287): Vulnerabilities allowing low-privilege users to induce the KDC to sign forged PACs or spoof machine sAMAccountNames (noPac), delivering instantaneous domain dominance.
  • Target Service PAC Validation: Understanding when a member server initiates a Netlogon RPC validation call (LogonSamLogonEx) to verify a PAC explains network telemetry that might otherwise be misdiagnosed as rogue DC traffic.

How It Works

Section titled “How It Works”

Anatomy of an MS-PAC Structure

Section titled “Anatomy of an MS-PAC Structure”
┌────────────────────────────────────────────────────────┐
│                   PAC STRUCTURE                        │
├────────────────────────────────────────────────────────┤
│ 1. PACTYPE Header (Buffer count and version)           │
├────────────────────────────────────────────────────────┤
│ 2. KERB_VALIDATION_INFO (Logon Info Buffer):           │
│    - User SID: S-1-5-21-DOM-1001                       │
│    - Group RIDs: [513, 1105, 1108]                     │
│    - sIDHistory / ExtraSids: [S-1-5-21-OLD-512]        │
│    - UserAccountControl flags                          │
├────────────────────────────────────────────────────────┤
│ 3. PAC_CLIENT_INFO (Account name and logon timestamp)  │
├────────────────────────────────────────────────────────┤
│ 4. SERVER_SIGNATURE (Encrypted with Service key)       │
├────────────────────────────────────────────────────────┤
│ 5. KDC_SIGNATURE (Encrypted with krbtgt key)           │
├────────────────────────────────────────────────────────┤
│ 6. PAC_ATTRIBUTES_INFO (PAC flags and state)           │
├────────────────────────────────────────────────────────┤
│ 7. FULL_PAC_CHECKSUM (Cryptographic HMAC signature)    │
└────────────────────────────────────────────────────────┘

The PAC Verification Workflow

Section titled “The PAC Verification Workflow”
  1. Upon receiving a TGS, the target workload decrypts the ticket using its own secret account key (computer machine account or service account).
  2. It verifies the Server Signature across the PAC.
  3. If valid, the host Local Security Authority (LSA) extracts the SIDs and constructs the user’s Access Token.
  4. DC Verification (Optional/Conditional): For sensitive services running under high privileges, the server can issue an RPC Netlogon query to an authoritative DC to validate the authenticity of the KDC Signature.

What Is Possible

Section titled “What Is Possible”
  • Dumping and Inspecting PAC Payloads in Memory: DFIR tools (Mimikatz kerberos::list /export, Rubeus triage, Wireshark) can decode the raw ASN.1/NDR PAC stream from memory or network captures.
  • Fabricating Arbitrary Group SIDs with krbtgt: Possessing the domain krbtgt hash allows an attacker to forge a PAC containing any combination of SIDs with a valid KDC signature.
  • Enforcing Cryptographic Signatures: Recent Windows Server security updates enforce mandatory Full PAC signatures, blocking legacy forged tickets.

What Is Not Possible

Section titled “What Is Not Possible”
  • Tampering with In-Flight PAC SIDs Without Invalidation: An adversary intercepting a Kerberos ticket cannot inject new SIDs without breaking the cryptographic Server and KDC signatures.
  • Bypassing KDC Validation on RPC-Validating Services (Silver Tickets): In Silver Ticket attacks where only the service key is known, if the target server forwards the PAC to a DC for validation, the forged KDC signature fails and access is denied.
  • Persisting Indefinitely After Group Removal Without Ticket Lifetime: SIDs inside a PAC remain static during the ticket’s valid lifetime (typically 10 hours). Once the ticket expires, the user must request a new ticket reflecting updated group memberships.

Common DFIR Confusions

Section titled “Common DFIR Confusions”
Frequent ConfusionVerifiable Forensic Reality
”A Kerberos ticket proves current group membership in Active Directory.”No. The PAC reflects group memberships at the time the TGT was requested. If an account was removed from an admin group 1 hour ago, its active PAC still retains administrative RIDs until ticket expiration.
”A Silver Ticket contains a valid KDC signature.”False. An attacker forging a Silver Ticket lacks the krbtgt key and inserts a dummy KDC signature. It only succeeds if the target server skips remote DC validation.
”All Windows services validate PACs against the DC.”The majority of member servers only validate the Server Signature locally for performance optimization.

Concrete Forensic Example

Section titled “Concrete Forensic Example”

During post-compromise forensic analysis, an investigator dumps residual Kerberos tickets from memory on a compromised SQL server:

  1. Rubeus.exe dump /luid:0x3e7 extracts an active service ticket presented for MSSQLSvc/sql01.corp.local.
  2. Decoding the PAC reveals:
    • Client name: guest
    • Encapsulated GroupIds: RID 512 (Domain Admins), RID 519 (Enterprise Admins).
    • KDC Signature: HMAC-MD5 (RC4), despite the domain enforcing AES-256 exclusively for over 4 years.
  3. DC Event 4769 logs for that timestamp show zero TGS requests for guest targeting sql01.
  4. Irrefutable Finding: The ticket was fabricated offline (Silver Ticket) using the stolen SQL service account hash.

Key Forensic Artefacts

Section titled “Key Forensic Artefacts”
  1. DC Event Logs (PAC Hardening and Violations):
    • Event ID 30 (Microsoft-Windows-Kerberos-Key-Distribution-Center): Rejection of a ticket with an unsigned PAC or missing CVE-2022-37967 signatures.
    • Event ID 31: Warning regarding tickets presenting weak or legacy PAC signatures.
  2. Member Host Security Logs:
    • Event ID 4624: Token security attributes populated directly from the parsed PAC.
  3. Network Telemetry:
    • Pre-authentication padata type PA-PAC-REQUEST (type 128) in AS-REQ packets.
    • ASN.1 AuthorizationData structures encapsulating the raw MS-PAC stream.

Investigation Methods

Section titled “Investigation Methods”
  1. Extract and Decode Memory-Resident Kerberos Tickets: Dump cached tickets on suspect hosts to inspect embedded SIDs and compare with actual directory memberships.
  2. Audit Ticket Encryption Algorithms: Flag tickets utilizing RC4 encryption (0x17) in domains where modern AES algorithms are standardized.
  3. Monitor System Logs on Domain Controllers: Query Microsoft-Windows-Kerberos-Key-Distribution-Center events 30 through 32 for evidence of rejected or forged PAC tickets.

Investigative Tooling

Section titled “Investigative Tooling”
  • Rubeus:
    Terminal window
    Rubeus.exe triage
    Rubeus.exe dump /nowrap
  • Wireshark: Filter: kerberos.pac.client_name to examine cleartext PAC header fields in network streams.
  • Klist:
    Terminal window
    klist get cifs/dc01.corp.local

Key Takeaways

Section titled “Key Takeaways”
  • The PAC is Microsoft’s extension that transports authorization SIDs and privileges within Kerberos tickets.
  • The PAC is protected by two primary signatures: the Service key and the krbtgt key.
  • Compromising krbtgt allows fabricating arbitrary PAC memberships (Golden Tickets).
  • Silver Tickets lack valid KDC signatures and fail against services enforcing remote DC validation.

References & Further Reading

Section titled “References & Further Reading”