PAC ve grup bilgisi: Bilet, access token ve kaynak yetkilendirmesi arasındaki ilişki.

1. Core Mechanism / Temel mekanizma

Bilet düzenleyen KDC (DC01), bileti kabul eden servis (ör. FS01) ve servisin oluşturduğu access token. PAC, biletin EncTicketPart'ındaki authorization-data alanında taşınır; ASN.1 ile sarılır ama içeriği NDR ile serialize edilmiş binary bir yapıdır. Bu dersin sınırı authorization data ile access token arasındaki köprüdür: AS/TGS akışı 06.02'de, SPN→anahtar 06.03'te, preauth ve session key 06.04'tedir. Access check'in kendisi ACL bölümünde (05.x) derinleşir.

Arabirimler ve belirtimler

• 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), anlaşılmayan öğeler yok sayılabilir.
• MS-KILE: PAC, AD-WIN2K-PAC (ad-type 128) olarak kodlanır ve AD-IF-RELEVANT (ad-type 1) içine sarılarak ticket authorization-data'sına yerleştirilir.
• MS-PAC §2.3 PACTYPE { cBuffers (ULONG), Version (ULONG, 0 olmalı) } ve §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 dizisi: RelativeId + Attributes) ve ExtraSids; grup üyeliği burada taşınır.
• MS-PAC §2.8 PAC_SIGNATURE_DATA: Server Signature servis anahtarıyla, KDC Signature krbtgt anahtarıyla üretilir; imza doğrulaması PAC bütünlüğünü kontrol eder.
• Microsoft · Access tokens: token, kullanıcının SID'i ve grup SID'lerini taşır ve access check bu token ile yapılır.

PAC biletin içinde nerede durur

Kerberos biletinin şifreli EncTicketPart bölümünde bir authorization-data alanı vardır. Windows'ta bu alan, kullanıcının yetki verisini taşıyan PAC'ı içerir. PAC doğrudan değil, iki katmanlı sarılır: önce AD-WIN2K-PAC (ad-type 128) öğesi olarak, sonra bu öğe AD-IF-RELEVANT (ad-type 1) içine konur.

Bu sarma tesadüfi değildir. AD-IF-RELEVANT, RFC 4120'nin "anlamayan taraf yok sayabilir" kuralını uygular: PAC'ı tanımayan bir Kerberos uygulaması bu öğeyi görmezden gelir, tanıyan Windows servisi ise açıp kullanır. Böylece Microsoft, standart Kerberos'u kırmadan Windows'a özgü yetki verisini taşır.

Kritik ayrım: dış katman ASN.1'dir (DER/TLV), fakat AD-WIN2K-PAC öğesinin ad-data OCTET STRING'inin içindeki PAC ASN.1 değildir. O, NDR ile serialize edilmiş little-endian binary bir yapıdır. Genel bir ASN.1 okuyucu OCTET STRING sınırına gelir ve içeri inemez; oradan sonrası farklı bir kodlamadır.

PAC'ın içi: header, buffer'lar ve grup bilgisi

PAC bir PACTYPE header ile başlar: cBuffers kaç buffer olduğunu, Version ise sürümü (0 olmalı) söyler. Header'dan sonra PAC_INFO_BUFFER dizisi gelir; her giriş bir ulType (buffer türü), cbBufferSize (boyut) ve Offset (PAC içindeki konum) taşır. Buffer'ların gövdeleri bu offset'lerde, 8 baytlık sınırlara hizalı durur.

Grup bilgisi Logon Information buffer'ındadır (ulType 0x1), yani KERB_VALIDATION_INFO yapısında. Bu yapı kullanıcının UserId'sini (RID), PrimaryGroupId'sini, GroupIds dizisini (her biri bir RelativeId ve Attributes taşıyan GROUP_MEMBERSHIP) ve ExtraSids listesini içerir. Yani "kullanıcı hangi gruplarda?" sorusunun cevabı fiziksel olarak burada, biletin şifreli bölümünde taşınır.

Bu yüzden bilet yalnızca "kim" değil, "hangi yetki bağlamıyla" bilgisini de taşır. Ama bu bilgi şifreli bilet içindedir; dışarıdan, örneğin bir 4769 kaydından okunamaz.

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

İmzalar: PAC'a neden güvenilir

PAC checksum’larının kapsamı ticket bağlamına bağlıdır. Güncel MS-PAC §2.4 tablosunda TGS/AP PAC’ları Server Signature (0x6) ve KDC Signature (0x7) taşır; TGS PAC’ları için Ticket Signature (0x10) ve Extended KDC Signature (0x13) de gerekir. Bu nedenle “her PAC yalnız iki imza taşır” diyemeyiz. Sürüm ve güvenlik güncellemeleri de gerçek doğrulama davranışı için önemlidir.

Server Signature servis anahtarına, KDC Signature KDC/krbtgt anahtarına bağlıdır. Bu checksum buffer’ları ile TGT’nin EncTicketPart bölümünün krbtgt key’iyle şifrelenmesi ayrı işlemlerdir. Servis ve KDC, kendi rollerine ait doğrulamaları yapar; checksum adlarının sayısını anahtar sahipliğinin yerine koyma.

Doğrulama, kapsadığı verinin anahtar sahibi tarafından korunduğunu gösterir; grup bilgisinin bugün dizindeki son değerle aynı olduğunu tek başına kanıtlamaz. Bu dersteki 83 baytlık parça yalnız kodlama sınırını ve eksik bir buffer dizinini gösterir: geçerli, tam veya imzalı bir PAC değildir.

PAC'tan access token'a, token'dan access check'e

Servis bileti kabul edip PAC'ı doğruladığında, PAC'taki kullanıcı SID'i ve grup SID'lerinden bir access token oluşturur. Windows'ta yetkilendirme kararı biletin kendisiyle değil, bu token ile verilir: access check, kaynağın DACL'indeki ACE'leri token'daki SID'lerle karşılaştırır.

Bu yüzden zincir üç halkalıdır. Bilet kimliği ve (PAC yoluyla) grup bağlamını taşır; token bu bağlamı çalışır hale getirir; access check kaynağa erişimi token üzerinden karara bağlar. 06.02'de gördüğümüz "bilet almak yetki almak değildir" ilkesi burada somutlaşır: bilet grup SID'lerini taşır ama erişimi kaynak, token üzerinden ayrı bir adımda değerlendirir.

Bu dersin group ACE örneğinde erişim, token’daki etkin ilgili group SID ile o işleme izin veren ACE’nin eşleşmesine bağlıdır. Her erişim için aynı grup şart değildir: user SID, diğer etkin group SID’leri, ACE kapsamı ve operasyona özgü privilege/authorization yolları da kararı etkileyebilir. İmzalı PAC, kaynak kararını atlamaz.

Durum ve veri akışı

1. KDC bilet düzenlerken kullanıcının dizindeki grup üyeliğinden bir PAC oluşturur ve KERB_VALIDATION_INFO'ya UserId, PrimaryGroupId, GroupIds ve ExtraSids'i yazar.
2. KDC, ticket bağlamına gereken PAC checksum’larını oluşturur; Server/KDC ve Ticket/Extended KDC rolleri ayrı tutulur.
3. PAC, AD-WIN2K-PAC (128) olarak AD-IF-RELEVANT (1) içine sarılır ve biletin şifreli EncTicketPart'ının authorization-data alanına konur.
4. İstemci bileti servise sunar (AP-REQ); istemci PAC'ı okuyamaz veya değiştiremez, çünkü bilet servis anahtarıyla şifrelidir.
5. Servis bileti açar, PAC'ın Server Signature'ını kendi anahtarıyla doğrular; gerekli durumda KDC Signature doğrulaması için KDC'ye başvurulur.
6. Servis PAC'taki SID'lerden bir access token oluşturur.
7. Kaynağa her erişimde access check, token'daki SID'leri kaynağın DACL'iyle karşılaştırarak izin/ret kararı verir.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım: "Token'daki grup SID'leri her zaman dizinin söylediği gerçektir; PAC imzalı olduğu için içeriği de doğrudur." Gerçekte PAC'ın içeriğine güven, imzaların geçerliliğine, imzalar da imzalayan anahtarların gizliliğine dayanır. KDC Signature krbtgt anahtarıyla üretildiğinden, krbtgt anahtarı ele geçmişse saldırgan istediği grup SID'leriyle (ör. Domain Admins RID 512) bir PAC üretip geçerli bir KDC imzasıyla imzalayabilir. Bu bilet doğrulandığında imza 'geçerli' görünür, ama içindeki grup bilgisi tamamen uydurmadır. Bu, Golden Ticket tekniğinin çekirdeğidir.

Technical prerequisites

• Bu risk değerlendirmesi, ilgili encryption type için KDC/krbtgt long-term key material’ın gizliliğinin bozulduğu durumu ele alır. RC4 ve AES key’leri aynı veri adıyla genellenemez; “parola hash’i” her enctype için doğru tanım değildir.
• Sahte PAC'ın hedef kaynakta anlamlı olması için gerçek grup SID'lerinin bilinmesi (ör. yerleşik ayrıcalıklı grupların iyi bilinen RID'leri).
• TGT’nin şifreleme anahtarı ile PAC checksum buffer’larının doğrulama rolleri ayrı değerlendirilir. Bu bölüm bir ticket üretme veya kabul kontrollerini aşma prosedürü vermez; güven kökü kaybının etkisini açıklar.
• Güncel PAC-validation davranışını uygulayan Windows güncellemelerinin Windows client’larda, DC’lerde ve inbound PAC doğrulayan ilgili servis hostlarında bulunması; CVE-2024-26248/-29056 için 2025 Nisan ve sonrası güvenlik güncellemeleri uyumluluk registry alt anahtarlarını kaldırıp secure behavior’ı zorunlu kılar. Bu, ele geçirilmiş krbtgt key’ini güvenilir hale getirmez; Golden Ticket kurtarması ayrıca krbtgt recovery gerektirir.

Exploitation mechanism / İstismar mekanizması

Mekanizma authorization data'nın güven modelinin sonucudur. KDC, PAC'ı krbtgt anahtarıyla imzalar; servis bu imzayı 'KDC üretti' kanıtı sayar. krbtgt anahtarı bilinirse saldırgan bu adımı taklit eder: KERB_VALIDATION_INFO'ya istediği GroupIds/ExtraSids'i yazar, PACTYPE header'ı ve buffer'ları oluşturur, KDC Signature'ı krbtgt anahtarıyla hesaplar ve PAC'ı bir bilete koyar. Servis PAC'ı açıp imzayı doğruladığında imza tutar; token bu sahte SID'lerle oluşturulur ve access check onları gerçek üyelikmiş gibi değerlendirir. Hiçbir Kerberos kuralı çiğnenmez; çiğnenen şey 'krbtgt anahtarı yalnızca KDC'de kalır' varsayımıdır.

Neden bilet olayları bunu göstermez

Golden Ticket bir forged TGT'dir; KDC tarafından üretilmediği için düzenleniş anında bir 4768 (TGT issued) kaydı bırakmaz. Buna rağmen bu TGT ile service ticket istendiğinde DC bir 4769 üretir. Yani DC üzerinde 'ata'sı olmayan bir 4769 belirebilir.

Ancak 4769 kaydı PAC içeriğini göstermez; hangi grup SID'lerinin token'a gireceği şifreli bilet içindedir. Telemetri, biletin düzenlendiğini görür, taşıdığı yetki verisini görmez.

Bu yüzden savunma, PAC içeriğini KDC olaylarından okumaya çalışmak yerine, sahte-TGT kullanımının dolaylı izlerine ve token tarafındaki gözlemlere bakar.

Kapsam ve sınır

Golden Ticket kapsamı krbtgt anahtarının kapsamıdır: o anahtar bir domain'e aittir, bu yüzden forgery o domain içinde geçerlidir. Cross-domain etki ayrı trust ve anahtar değerlendirmesi gerektirir.

Etki güçlüdür çünkü token'a keyfi grup SID'leri konabilir; fakat önkoşul da güçlüdür: krbtgt anahtarının ele geçmesi zaten ciddi bir compromise'in sonucudur. Bu yüzden Golden Ticket bir başlangıç değil, kalıcılık ve yetki yükseltme aracıdır.

Microsoft’un iki resetli forest-recovery yönergesi writable DC’lerin domain krbtgt hesabı içindir. İlk değişikliğin DC’lere replikasyonu ve yapılandırılmış user/service ticket lifetime koşulları birlikte değerlendirilir; varsayılan süre 10 saattir, policy daha uzunsa bekleme de uzar. RODC’ye ait krbtgt_number hesapları aynı işlem değildir; ayrı RODC recovery bağlamında ele alınır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• KDC bilet olayları (4768 TGT, 4769 service ticket) yalnızca domain controller üzerinde oluşur; bunlar biletin düzenlendiğini gösterir ama PAC'ın grup içeriğini GÖSTERMEZ.
• PAC'ın grup bilgisinin gözlemlenebilir karşılığı kaynak/host tarafındaki logon token'ıdır; grup üyeliği ve ayrıcalık olayları oturumun oluştuğu makinede aranır.
• Golden Ticket için doğrudan bir 'sahte PAC' olayı yoktur; sinyal dolaylıdır: ata 4768'i olmayan 4769 kullanımı, olağandışı bilet ömürleri ve yüksek değerli grupların beklenmedik oturumlarda görünmesi.
• krbtgt yönetimi ayrı bir recovery yüzeyidir: şüpheli compromise sonrasında reset geçmişi, DC replikasyonu ve ticket lifetime birlikte değerlendirilir; sıradan bir düzenli rotation varsayımıyla yetinilmez.
• Bilet olaylarının hacmi yüksektir; PAC içeriği görünmediği için tek başına bunlar üzerinden yetki değişikliği izlemek yanıltıcıdır.

Events and relevant fields

• 4769 / TargetUserName ve ServiceName: bilet talebinin kime ve hangi servise ait olduğunu gösterir; PAC'taki grup SID'lerini göstermez.
• 4769 / TicketOptions ve TicketEncryptionType: ticket flag’leri ve encryption type. Bu alanlar ticket’ın başlangıç/bitiş zamanını veya PAC içeriğini göstermez; olağandışı değerleri ortamın policy ve service inventory’siyle karşılaştır.
• 4768: bir TGT'nin düzenlendiğini gösterir; Golden Ticket bu olayı bırakmaz, bu yüzden 4769 ile 4768 arasındaki tutarsızlık bir gözlem noktasıdır.
• Kaynak host oturum kaydı: PAC'tan türeyen token'ın grup ve ayrıcalık içeriği, biletin değil oturumun kaydında görünür. Bu ders bunu ayrı bir gözlem noktası olarak işaretler.
• Not: bu derste PAC alanlarını doğrudan taşıyan yeni bir Event ID iddia edilmez; grup SID içeriğini raporlayan host tarafı olayların alan şeması bu oturumda birincil kaynaktan doğrulanmadı ve burada uydurulmaz.

Bilet olayı PAC'ı göstermez

4769 veya 4768 bir biletin düzenlendiğini söyler; içindeki grup SID'lerini söylemez. PAC şifreli EncTicketPart içindedir ve KDC işlem kaydına yansımaz. Bu yüzden 'kullanıcı hangi gruplara sahip biletle geldi?' sorusu bilet olaylarından yanıtlanamaz.

Grup bağlamının gözlemlenebilir karşılığı, biletin türediği access token'dır ve bu token kaynak hostta oluşur. Yetki değişikliğini izlemek için doğru gözlem noktası KDC değil, oturumun kurulduğu makinedir.

Bu sınırı kabul etmek, sahte pozitiflerden ve yanlış modelden korur: bilet telemetrisi kimlik ve akış içindir; yetki içeriği için token tarafına bakılır.

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

• Bu, aday olayları incelemek için bir korelasyon iskeletidir. Aynı hesap için eşleşen 4768 bulunmaması tek başına sahte TGT kanıtı değildir: collector kapsamı, DC’ler, retention, zaman penceresi ve geçerli eski ticket kullanımı ayrıca incelenir. Sigma bu yokluk mantığını burada hesaplamaz; alan eşlemesi ve pencere backend’de doğrulanmalıdır.
• 4769 alan adları Windows Security kanalındaki EventData adlarıdır ve bu oturumda 4769 belgesine göre doğrulanmıştır. 4768'in alan eşlemesi backend'e bağlıdır ve burada ayrıca doğrulanmadı.
• Kural PAC içeriğini okumaz; okuyamaz da, çünkü grup SID'leri şifreli bilet içindedir. Bu bilinçli bir sınırdır: heuristic, sahte-TGT kullanımının dolaylı izine bakar.
• Yüksek değerli ServiceName kümesi ve eşik ortam envanterine göre tanımlanır; sabit değildir.
• Bu kural bu oturumda gerçek bir SIEM üzerinde çalıştırılmadı; yalnız 4769 semantiği birincil kaynağa göre doğrulandı.

False positives

• Log saklama penceresi dışında kalmış meşru 4768 kayıtları, ata TGT'yi görünmez kılar ve yanlış pozitif üretir.
• WEF veya toplama gecikmesi 4768 ile 4769'un farklı zamanlarda ulaşmasına yol açabilir.
• Uzun ömürlü ve yenilenen meşru TGT'ler, pencere dışında kalan bir 4768'e sahip olabilir.
• Negatif örnek: krbtgt anahtarı henüz ele geçmemişse bu heuristic hiçbir gerçek Golden Ticket görmez; kural bir güven kontrolü değil, bir anomali işaretçisidir.

Hardening

• krbtgt compromise şüphesinde Microsoft forest-recovery prosedürünü izle: iki reset uygula; ikinci resetten önce ilk değişikliğin DC’lere replike olduğunu doğrula ve arada configured Maximum lifetime for user ticket / service ticket süresinden uzun bekle. Varsayılan süreler 10 saattir; daha yüksek ayarlar daha uzun bekleme gerektirir.
• CVE-2024-26248/-29056 için DC’leri, Windows client’ları ve inbound PAC doğrulayan ilgili servis hostlarını güncel tut; Nisan 2025 ve sonrası güncellemeler PacSignatureValidationLevel ve CrossDomainFilteringLevel compatibility registry alt anahtarlarını kaldırıp secure behavior’ı zorunlu kılar. Normal Kerberos akışını ve ilgili audit/uyumluluk sinyallerini doğrula. Bu güncelleme yolu, ele geçirilmiş krbtgt key’i sonrası recovery/rotation yerine geçmez.
• krbtgt ve tier-0 kimliklerinin ele geçmesini zorlaştır: ayrıcalıklı erişimi Enterprise Access Model ile sınırla; krbtgt'ye erişebilen yolları azalt.
• Yüksek değerli grup SID'lerinin (Domain Admins gibi) beklenmedik oturumlarda görünmesini kaynak host token telemetrisiyle izle; bu, PAC içeriğinin dolaylı gözlem noktasıdır.
• Doğrulama adımı: krbtgt kurtarmasında ilk resetin replikasyonunu ve iki reset arasındaki yapılandırılmış ticket lifetime beklemesini teyit et; ardından normal Kerberos servis akışlarını ve eski key’e dayalı forged ticket’ların artık doğrulanmamasını kontrol et. PAC-validation güncelleme uyumluluğunu ayrıca, güncellenmiş client/DC ve ilgili PAC doğrulayan servis-host kapsamı ve ilgili audit sinyalleriyle değerlendir.

Örnekler üzerinde oku / 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

İki yanlış kanı / Two reality checks

Sanılan: Bir kullanıcıyı bir gruptan çıkarınca o kullanıcının kaynaklara erişimi anında biter.

Gerçekte: PAC mevcut ticket içinde sabit bir snapshot’tır. Gruptan çıkarma, daha önce kurulmuş target token veya açık session’ı geriye dönük yeniden oluşturmaz. Yeni ticket/PAC ile yeni target context ayrı aşamalardır; ticket’ın süresinin dolması da mevcut session’ın aynı anda kapanacağını garanti etmez.

Sanılan: PAC imzalı olduğuna göre içindeki grup bilgisine her koşulda güvenilebilir.

Gerçekte: PAC checksum’ları ticket bağlamına göre değerlendirilir; TGT şifreleme ve PAC checksum doğrulaması aynı işlem değildir. İlgili anahtarın gizliliği kaybolduysa başarılı doğrulama, içeriğin güncel dizin bilgisiyle uyumunu tek başına kanıtlamaz. Bu yüzden doğrulama sonucu, key güvenliği, context’in oluşturulma zamanı ve kaynak yetkilendirmesiyle birlikte okunur.

Kaynaklar / Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §5.2.6 AuthorizationData (ad-type/ad-data) ve §5.2.6.1 AD-IF-RELEVANT (ad-type 1, anlaşılmayan öğeler yok sayılabilir); §5.3 EncTicketPart authorization-data alanı.
• 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 ve KDC imzaları).
• Microsoft Open Specifications · [MS-KILE] Processing Authorization Data
  PAC'ın AD-WIN2K-PAC (ad-type 128) olarak kodlanıp AD-IF-RELEVANT (ad-type 1) içine sarılarak ticket authorization-data'sına yerleştirilmesi.
• Microsoft · Access tokens
  Access token'ın kullanıcı SID'i ve grup SID'lerini taşıması; access check'in token'daki SID'lerle DACL'i karşılaştırması.
• 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.