KRBTGT: architektura, trusty, PAC a evoluce útoků
Klíčové Kerberos termíny ponechávám v angličtině (principal, realm, KDC, ticket, TGT, service ticket, PAC, KVNO, etype, referral ticket, inter‑realm key, trust secret, S4U2self, PAC validation). Překlady těchto termínů jsou v praxi často nepřesné a snižují srozumitelnost.
Terminologie
Protože tento článek obsahuje mnoho termínů, které jsou velmi důležité pro pochopení Kerberosu a Active Directory, tak se je nejprve pokusím vysvětlit.
Principal
Principal je identita v Kerberosu. V AD tomu typicky odpovídá security principal (user/computer/service account). Pro Kerberos je podstatné, že pro daný principal existuje dlouhodobý klíč (long‑term key), ze kterého KDC vychází při vydávání ticketů.
Realm
Realm je administrativní a kryptografická doména Kerberosu. V prostředí Windows se realm obvykle mapuje na AD doménu (DNS name převedený do uppercase). Protokolový rámec Kerberos V5 je definován v RFC 4120.
KDC
KDC (Key Distribution Center) je důvěryhodná autorita, která vydává a ověřuje Kerberos tickety. V AD je KDC role součástí každého Domain Controlleru. Kerberos V5 je složen ze tří hlavních exchange (AS, TGS, AP), které RFC 4120 popisuje jako základní stavební bloky autentizace.
Ticket, TGT, service ticket
Ticket je Kerberos credential určený pro serverovou stranu. Klient ticket běžně nedokáže dešifrovat, protože ticket je šifrovaný klíčem cílové služby. TGT je speciální ticket pro službu krbtgt/REALM. Používá se jako vstup do TGS exchange. Service ticket je ticket pro konkrétní službu (typicky identifikovanou SPN).
PAC
PAC (Privilege Attribute Certificate) je Windows rozšíření, které nese autorizační data (například group membership). PAC je přenášen uvnitř Kerberos ticketu a je relevantní pro sestavení Windows access tokenu.
PAC validation
PAC validation je postup, kdy operační systém na straně serveru předá PAC (resp. PAC signature z AP‑REQ) doménovému řadiči k ověření. Microsoft v MS-APDS popisuje, že OS forwarduje PAC signature v AP‑REQ na DC v message typu KERB_VERIFY_PAC a DC vrátí výsledek zpět.
Etype
Etype (encryption type) určuje, jakým algoritmem je ticket chráněn. V AD má etype nejen kryptografický význam, ale i provozní a detekční hodnotu (baseline vs odchylky). Microsoft v Open Specifications definuje, že atribut msDS-SupportedEncryptionTypes udává etypes podporované účtem a KDC tuto informaci používá při generování service ticketu.
KVNO a msDS-KeyVersionNumber
KVNO je číslo verze klíče použitého pro šifrování/podpis. V AD odpovídá KVNO prakticky tomu, kolikrát se změnilo heslo (tedy klíčový materiál) daného účtu. Atribut msDS-KeyVersionNumber je v Microsoft dokumentaci definovaný jako “Kerberos version number of the current key for this account”. ([Microsoft Learn][5])
Model klíčů v AD Kerberos (co chrání KRBTGT a co ne)
Tato kapitola je klíčová, protože většina provozních i incidentních chyb vzniká z toho, že se zamění “klíč domény” za “klíč služby” nebo za “klíč trustu”.
KRBTGT key (doménový klíč pro TGT)
KRBTGT key je dlouhodobý klíč odvozený z hesla účtu KRBTGT v konkrétní doméně. Tento klíč používá KDC pro práci s TGT (ticket pro krbtgt/REALM). Praktický dopad je přímý: kompromitace KRBTGT key znamená kompromitaci schopnosti vytvářet/validovat TGT v dané doméně. Každá AD doména má účet KRBTGT používaný pro šifrování a podepisování TGT v doméně.
Service account key (klíč konkrétní služby)
Service ticket je šifrovaný klíčem cílové služby (service account key nebo computer account key). Reset hesla služby tedy ovlivní primárně service tickety pro tuto službu, nikoli TGT celé domény. Prakticky se to projeví typickými chybami typu “service ticket nejde rozšifrovat”, i když TGT uživatele vypadá v pořádku.
Trust secret / inter‑realm key (klíč vztahu důvěry)
Cross‑realm (cross‑domain / cross‑forest) scénáře používají pro referral flow inter‑realm key (trust secret). Tento klíč je uložený v objektu trustu (TDO). Microsoft explicitně uvádí, že key version number pro trusty je uložen v Trusted Domain Object.
Důsledek je praktický: reset KRBTGT nemění trust secret. Stejně tak reset trust secret nemění KRBTGT. To jsou dvě různé “kryptografické osy”.
RODC: oddělený KRBTGT pro kryptografickou izolaci
Read‑Only Domain Controller má vlastní specifický KRBTGT účet (krbtgt_#####) a tím i oddělený klíč. Důvodem je izolace: kompromitace RODC nemá automaticky stejný dopad jako kompromitace writable DC.
KRBTGT v doméně: KVNO, rotace a proč se reset provádí dvakrát
KRBTGT je účet, který “vypadá” jako user object, ale jeho účel je systémový. V rámci běžného provozu se zpravidla jeho heslo nemění a organizace se k jeho rotaci dostanou buď v rámci bezpečnostní hygieny, nebo při forest recovery/incidentu.
Nejdůležitější mechanická vlastnost je password history. Microsoft ve svém oficiálním článku FAQs from the Field on KRBTGT Reset uvádí, že KRBTGT drží password history o velikosti 2, a proto se reset provádí dvakrát, aby se zneplatnily tickety vydané starým klíčem.
V praxi je význam zřejmý - po prvním resetu se starý klíč typicky přesune do role “previous”. Nějakou dobu proto mohou být ještě akceptovány tickety, které byly vystaveny před změnou. Druhý reset starý klíč “vytlačí” z historie a tím se zneplatnění “dokončí”.
Jak můžete vidět na obrázku níže, aktuální klíče jsou v zeleném rámečku a předchozí ve fialovém rámečku.
KRBTGT credential material v Active Directory
Pro scénář aktuálního bezpečnostního incidentu je potřeba zdůraznit jednu věc - reset KRBTGT sám o sobě není “vyčištění domény”. Pokud útočník stále drží Tier 0 přístup (DC, replikační práva, schopnost číst hesla, hashe apod.), získá nový klíč znovu. KRBTGT reset je kryptografická změna, ne kompletní eradikace. Tady si neodpustím zmínit, že pro získání důvěry v zabezpečení Active Directory je ji potřeba postavit kompletně od nuly (viz moje oblíbené “burn the forest!”).
Burn the Forest! meme
PAC a podpisy: proč není důležité jen “co je v PAC”, ale i “kdo to podepsal”
PAC je autorizační vrstva. Pokud cílový systém ticket přijme a PAC považuje za validní, PAC se promítne do vytvořeného access tokenu. Proto jsou pro obranu zásadní PAC signatures a validační mechanismy.
Microsoft v MS-PAC jasně rozlišuje, že určité PAC signature struktury jsou vázané na klíč služby a jiné na klíč KDC. V definici PAC_SIGNATURE_DATA Microsoft uvádí, že hodnota ulType určuje, jaký klíč se má použít: 0x00000006 odpovídá server key a 0x00000007 odpovídá KDC key.
To se v praxi projeví tak, že pokud někdo změní obsah PAC, musí současně vytvořit konzistentní podpisy. Pokud podpisy neodpovídají klíčům, které systém očekává, validace selže. Proto je pro moderní hrozby typické, že útočník se snaží získat PAC, který vypadá jako produkt KDC a projde validačním tokem.
Je důležité chápat i to, že KDC v některých situacích PAC struktury aktivně mění. Microsoft v MS-KILE uvádí, že při vydávání service ticketu, kde se zpracovává Domain Local Group Membership, KDC musí odstranit PAC_REQUESTOR a PAC_ATTRIBUTES_INFO z výsledného ticketu. To je z pohledu běžného provozu významné - “nevidím PAC_REQUESTOR v service ticketu” nemusí být anomálie, ale očekávané chování.
PAC validation a změny po CVE‑2024‑26248 / CVE‑2024‑29056
Základní PAC validation tok je v MS‑APDS popsán poměrně jasně: klient pošle serveru AP‑REQ, server předá PAC OS, OS pošle DC požadavek KERB_VERIFY_PAC, DC ověří a vrátí výsledek, a teprve potom server dokončí autentizaci (AP‑REP).
Microsoft v support článku k CVE‑2024‑26248 a CVE‑2024‑29056 popisuje, že security updates od 9. dubna 2024 řeší elevation of privilege v Kerberos PAC Validation Protocol a že PAC je rozšíření Kerberos service ticketů.
Je důležité si v tomto ohledu uvědomit, že tyto změny nezavádějí “nový Kerberos”. Zpřesňují a vynucují způsob, jakým Windows vyhodnocuje autorizační data v PAC v určitých scénářích. Prakticky to znamená, že část rozhodnutí o tom, zda je PAC akceptovatelný, se opírá o deterministický validační tok, který je lépe auditovatelný.
Microsoft v support článku navíc popisuje cross‑domain chování. Validační požadavek může být forwardován přes trusty “until it reaches the service’s domain” a každý DC při forwardingu filtruje autorizační data, která se ho týkají.
To je přesně ten moment, kde AD správci často nechápou, proč se v textu objeví “Netlogon”. Nejde o to, že by Kerberos “přešel na NTLM”. Jde o to, že Windows pro forwardování některých validačních požadavků používá doménovou infrastrukturu a mechanismy, které jsou v AD implementované přes Netlogon kanál.
Pokud chcete tedy z pohledu bezpečnostního dohledu rozpoznat, proč byl ticket přijat nebo odmítnut, nestačí sledovat pouze vydávání ticketů na DC (Eventy 4768/4769). V některých scénářích je nutné sledovat i server, který inbound Kerberos přijímá, protože právě tam probíhá PAC validation rozhodnutí a tam vzniká část relevantní telemetrie. Microsoft support guidance to explicitně staví do kontextu rollout fází a požadavku patchnout celé prostředí (DC i klienty), aby byla mitigace úplná.
Etypes, RC4 a proč je etype dobrý signál i pro obranu
Etype je v AD řízen mimo jiné atributem msDS-SupportedEncryptionTypes. Microsoft ho definuje jako atribut, který specifikuje etypes podporované user/computer/trust accounts, a uvádí, že KDC tuto informaci používá při generování service ticketu.
RC4 je v Kerberos kontextu dlouhodobě považováno za nežádoucí. Microsoft v dokumentu Detect and remediate RC4 uvádí, že plánuje zakázat RC4 jako výchozí etype pro AD domain controllery do konce druhého čtvrtletí 2026. Tentýž dokument popisuje i auditní stránku věci - využití RC4 se promítá do security eventů 4768 a 4769 a pro některé OS verze byla tato informace přidána i zpětně aktualizacemi (včetně kumulativní aktualizace z ledna 2025 pro Server 2016).
Z praktického hlediska to znamená, že jakmile budete mít prostředí “AES‑dominant”, každá operace využívající RC4 je buď legacy závislost, nebo vysoce podezřelá anomálie, která stojí za vyšetření.
Golden, Diamond a Sapphire Ticket
Tato část se zaměřuje na popsání útoků z pohledu obrany, tedy jaké změny nastávají v telemetrii a co by mělo vypadat konzistentně. Nejedná se o detailní popis mechanismu daného útoku.
Golden Ticket
Golden Ticket je situace, kdy se v prostředí objeví TGT, který je kryptograficky validní pro doménu, ale nevznikl standardním vydávacím procesem. Z pohledu detekce je zajímavé hlavně to, že se může rozcházet auditní stopa - vidíte následné service ticket aktivity, ale chybí kontext odpovídající vydání TGT v očekávaném čase.
Diamond Ticket
Diamond Ticket je varianta, která se snaží zachovat “normální” stopu vydání ticketu. Útočník vychází z legitimně získaného ticketu a problém se přesouvá do oblasti “konsistence autorizačních dat”. Detekce se pak typicky opírá o baseline, tedy chování identity, typicky používané služby, etype profil, časovou osu a kontext zařízení.
Sapphire Ticket
Sapphire Ticket se obvykle popisuje jako scénář, kdy se zvyšuje důvěryhodnost PAC tím, že se útočníksnaží získat PAC vygenerovaný KDC. V těchto situacích se často objevuje S4U2self, protože Microsoft ho definuje jako rozšíření, které umožní službě získat service ticket “to itself on behalf of user” a tím získat autorizační data uživatele v ticketu. Z obranného pohledu je zásadní, že validní PAC není automaticky benigní. Je nutné hodnotit kontext delegace, topologii trustů a to, zda tok odpovídá očekávané aplikační architektuře.
Praktická diagnostika pomocí klist, TGT, etype a KVNO
Tato kapitola je záměrně praktická. Mým cílem bylo, aby čtenář uměl rychle ověřit, co Kerberos klient skutečně drží v Kerberos cache a jak to korelovat s AD atributy.
klist na Windows: jak poznám TGT a jak čtu etype
Na Windows klist ukazuje cached tickety v logon session. TGT poznáte podle toho, že server ticketu je krbtgt/REALM@REALM. Service ticket poznáte podle SPN (například cifs/server@REALM, HTTP/app@REALM).
klist zobrazující TGT a TGS
Co je důležité poznat:
- Řádek
Server: krbtgt/...je TGT. To je přesně ticket, který je kryptograficky navázán na KRBTGT key domény. - Řádek
KerbTicket Encryption Typeje etype ticketu. Tady typicky hledáte odchylky (např. RC4 v prostředí, které má být čistě AES). - Pole
Session Key Typeříká, jakým etype je chráněn session key použitý v dané session.
Pokud řešíte audit etypes na DC, tak lze v eventech 4768/4769 sledovat informace o encryption typech.
Event 4768 s Encryption Type 0x12 AES256-CTS-HMAC-SHA1-96
Event 4769 s Encryption Type 0x12 AES256-CTS-HMAC-SHA1-96
KVNO: proč ho v klist nevidíte a jak ho zjistit správně
Na Windows není KVNO v běžném klist výpisu typicky explicitně vypsané. Přesto můžete KVNO ověřit korektně přes AD atribut msDS-KeyVersionNumber. Microsoft tento atribut definuje jako “Kerberos version number of the current key for this account”.
V praxi to využijete tak, že si zjistíte msDS-KeyVersionNumber pro:
- účet
krbtgt(pro TGT/KRBTGT key), - účet služby nebo počítače (pro service ticket klíč), a následně to korelujete s časem issuance ticketu (z
klist, případně z eventů na DC).
Ukázka přes 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
měnící se msDS-KeyVersionNumber při změně hesla KRBTGT
Jak to interpretovat:
- Pokud resetujete KRBTGT, zvýší se
msDS-KeyVersionNumber. To je praktická “viditelná stopa” změny klíče. - Pokud aplikace začne hlásit Kerberos chyby po změně hesla service accountu nebo computer accountu, první kontrola je, zda se klíč replikoval na všechny DC a zda se vydávají tickety s očekávaným KVNO.
Rychlá kontrola, proč se objevuje RC4
Když vidíte v klist nebo v DC eventech RC4, typická otázka je “kdo ho vynutil”. Odpověď často leží v msDS-SupportedEncryptionTypes. Microsoft tento atribut definuje jako seznam etypes podporovaných user/computer/trust účtem a uvádí, že KDC tuto informaci používá při vydání service ticketu.
To je praktická auditní kontrola, díky které můžete ověřit, zda konkrétní účet vůbec podporuje AES, a zda není tato konfigurace důvodem fallbacku k RC4.
attribute msDS-SupportedEncryptionTypes when account has AES configured as supported
Tři klíče a jak často tedy měnit heslo účtu KRBTGT
Pokud si z článku máte odnést jednu věc, pak tuto: v AD Kerberos existují tři odlišné roviny klíčů – KRBTGT key (TGT), service account key (service ticket) a trust secret (cross‑realm referral). Incidentní i provozní rozhodnutí dávají smysl jen tehdy, když právě tyto roviny umíte striktně oddělit.
PAC a PAC validation jsou v roce 2025 zásadní téma, protože Windows přes ně realizuje autorizaci a současně přes ně vynucuje bezpečnostní mitigace. Microsoft k tomu poskytuje jak normativní specifikace (MS‑APDS, MS‑PAC, MS‑KILE), tak provozní guidance pro hardening a konkrétní CVE.
Je zásadní si uvědomit, že praktický troubleshooting a detekce incidentů se v dobrém prostředí neopírá o “dojmy”, ale o korelaci informací z klist na klientovi, relevantní DC eventy (4768/4769) a stav klíčů v AD (msDS-KeyVersionNumber, msDS-SupportedEncryptionTypes).
Tedy, jak často měnit heslo účtu KRBTGT?
Standardy
Všeobecně uznávaný bezpečnostní standard v rámci vládních a enterprise rámců vyžaduje resetovat heslo účtu KRBTGT nejméně jednou za 180 dnů. Toto doporučení je kodifikováno v Microsoft Windows Server STIG (Security Technical Implementation Guide) a podporováno bezpečnostními rámci DISA (Defense Information Systems Agency). Interval 180 dnů představuje vyvážené řešení mezi zabezpečením a provozem. Jakýkoli delší interval výrazně prodlužuje okno příležitosti pro útočníky - pokud by byl hash KRBTGT extrahován z offline zálohy nebo prostřednictvím přímé kompromitace doménového řadiče, všechny autentizační tickety vydané v takto dlouhém období se stanou zranitelné vůči vytváření podvrhů útočníky.
Procedura dvojité změny
Rotace hesla KRBTGT vyžaduje dvojitý proces resetování v určitém časovém rozmezí a ne jedinou změnu hesla. Tato metodika dvojité resetování je nutná, protože jak jsme si řekli, tak Active Directory si udržuje historii hesel o délce dvou položek pro účet KRBTGT. Tento dvoustupňový přístup musí proběhnout v rámci životnosti TGT - typicky 10 hodin ve výchozím nastavení, ačkoli organizace by měly ověřit skutečné nastavení “Max TGT Lifetime (Hours)” v rámci jejich domény. Čekání nejméně 10 hodin mezi resetováními umožňuje přirozeně vypršet stávající Kerberos tickety, čímž se zabrání selhání autentizace, když se klienti pokusí použít tickety s aktualizovanými KRBTGT klíči doménových řadičů.
Provozní hlediska a načasování
Organizace by měly koordinovat rotace hesla KRBTGT během plánovaných maintenance oken, ideálně když je aktivita domény nejnižší, aby se minimalizovaly dopady na autentizace. Provedení replikace je kritické - první změna hesla se musí replikovat na všechny doménové řadiče před druhým resetováním, což obvykle vyžaduje 12–24 hodin monitorování. Předčasné po sobě jdoucí resetování bez plné replikace může přerušit konektivitu domény, zejména na starších unixových systémech, které cachují přihlašovací údaje protokolu Kerberos. Zavedení nejméně 24 hodin mezi resetováními se bežně jeví jako pragmatický operační standard, který zajišťuje dokončení replikace při zachování bezpečnosti. Pro změnu hesla KRBTGT můžete použít také AD skripty, které umožňují celou operaci provést kontrolovaně včetně replikace. Řada organizací, které implementují agresivnější harmonogramy — například čtvrtletní nebo měsíční rotace — tak činí jako součást zvýšeného bezpečnostního standardu.
Výjimečné situace vyžadují okamžité opatření
Zatímco se cyklus 180 dnů týká rutinní údržby, okamžité resetování hesla KRBTGT se stává povinným v případě podezření nebo potvrzené kompromitace domény, nebo po odchodu privilegovaných administrátorů s přístupem ke KRBTGT (včetně přístupu k zálohám obsahujícím tyto KRBTGT). V incident response scénářích by měly být dvě resetování provedena spíše v hodinách než dnech, aby se rychle zneplatnily všechny případné Golden tickety vytvořené útočníky a vynutily se opětovné ověření všech session tokenů.
Objasnění oficiálního postoje Microsoftu
Stojí za zmínku, že oficiální stanovisko Microsoftu, jak je uvedeno v jejich blogu FAQs from the Field on KRBTGT Reset, uvádí, že neexistuje “žádné specifické doporučení týkající se frekvence resetování hesla pro účet KRBTGT.” Spíše Microsoft doporučuje organizacím, aby si stanoveily vlastní interval “s ohledem na plány zálohování, operační postupy, bezpečnostní požadavky atd.” Tato flexibilita vedla ke konsenzu průmyslu konvergujícímu ke standardu DISA STIG 180 dnů jako praktickému de facto měřítku, zejména v regulovaných prostředích, kde bezpečnostní audity očekávají zdokumentované harmonogramy rotace. Čtvrtletní nebo četnější rotace posilují zabezpečení, ale také přinášejí vysokou provozní režii bez poskytování exponenciálně větší ochrany za normálních (nekompromitovaných) okolností.
Takže?
Resetujte heslo účtu KRBTGT nejméně jednou za 180 dnů jako základní bezpečnostní opatření pro Active Directory. Implementujte proceduru dvojího resetování s časovým intervalem mezi resetováním, aby se zajistila úspěšná replikace a zachování stability domény. Dokumentujte každou rotaci s časovými značkami a poznámkami z monitorování a zrychlete harmonogram okamžitě při jakémkoli podezření na kompromitaci. Tento disciplinovaný přístup výrazně omezuje dobu, po kterou jsou extrahované hashe KRBTGT zneužitelné, což zásadně snižuje zranitelnost vaší domény vůči útokům jako např. Golden Ticket nebo jiných variant perzistencí.