Artykuł pochodzi z wydania: Lipiec-Sierpień 2025
Jak ważne jest zaufanie, można się przekonać, gdy zawiedzie. Gdy zostanie podważone i stanie się bronią w arsenale napastnika. Protokół Kerberos, fundament mechanizmów uwierzytelniania w środowiskach domenowych Microsoftu, został zaprojektowany z myślą o zapewnieniu integralności i poufności w dostępie do zasobów. Ale co się dzieje, gdy ten mechanizm staje się narzędziem w rękach atakujących?
Odkąd model Zero Trust stał się nowym paradygmatem cyberbezpieczeństwa, klasyczne mechanizmy uwierzytelniania domenowego trafiają pod coraz bardziej wnikliwą lupę. Kerberos, mimo swojej kryptograficznej elegancji, nie jest wyjątkiem. Ataki wymierzone w jego strukturę nie opierają się na łamaniu algorytmów. Przeciwnie – wykorzystują dokładnie to, co protokół oferuje użytkownikom: legalne ścieżki autoryzacji i delegowania uprawnień. W tym artykule przyglądamy się technikom ofensywnym, które z pozornie stabilnego gruntu domenowego czynią pole do eskalacji, lateralnego ruchu i pełnego przejęcia systemów Windows. Omówimy, jak działa Kerberos, na czym opiera się jego model zaufania i w jaki sposób może zostać wykorzystany – od Kerberoastingu, przez AS-REP Roasting, aż po ekstrakcję i łamanie danych z pliku NTDS.dit.
Fundament zaufania
Kerberos to protokół uwierzytelniania sieciowego oparty na mechanizmach kryptografii symetrycznej i modelu zaufanej trzeciej strony. Powstał na MIT pod koniec lat 80. XX wieku jako element projektu Athena, lecz największą karierę zrobił w roli domyślnego mechanizmu uwierzytelniania w środowiskach Microsoft Active Directory od czasów Windows 2000.
U podstaw jego działania leży prosty model: użytkownik (klient) musi uzyskać zaufanie biletowe od serwera uwierzytelniającego (Authentication Server, AS), aby móc skomunikować się z innym zasobem sieciowym (serwerem usług). Zamiast przesyłać hasła wprost, klient przedstawia zaszyfrowane bilety – tokeny wystawione przez KDC (Key Distribution Center), będący częścią kontrolera domeny. W teorii oznacza to, że nawet jeśli sieć jest podsłuchiwana, napastnik nie uzyska danych dostępowych wprost. W praktyce jednak – jak pokażą dalsze sekcje artykułu – zabezpieczenia te można obejść.
Całość opiera się na trzystopniowym procesie uwierzytelniania: najpierw użytkownik loguje się i uzyskuje bilet TGT (Ticket Granting Ticket) wystawiany przez AS. Następnie, posiadając TGT, klient może żądać dostępu do konkretnej usługi w sieci, otrzymując bilet usługowy (Service Ticket) od Ticket Granting Servera (TGS). To właśnie na tym etapie pojawiają się wektory ataków, takie jak Kerberoasting, które wykorzystują bilety jako nośnik informacji podatnych na ataki offline.
Ważnym elementem protokołu jest wstępne uwierzytelnianie (ang. pre-authentication) – wymóg, by użytkownik przedstawił dowód znajomości swojego hasła jeszcze przed otrzymaniem TGT. Jego wyłączenie, choć czasem stosowane ze względów zgodności lub administracyjnych, drastycznie obniża poziom bezpieczeństwa, otwierając furtkę dla innego rodzaju ataku, czyli AS-REP Roastingu.
Mimo że Kerberos pozostaje podstawowym mechanizmem w setkach tysięcy firmowych środowisk, jego bezpieczeństwo w dużej mierze zależy od konfiguracji oraz siły haseł. Paradoksalnie największa zaleta protokołu – szerokie wdrożenie i automatyzacja – staje się też największą słabością, gdy trafi w ręce napastnika znającego wewnętrzną topologię domeny.
Architektura protokołu
Funkcjonowanie Kerberosa opiera się na kilku ważnych komponentach logicznych i kryptograficznych, które wspólnie realizują model zaufania w domenie. Choć Kerberos to standardowy protokół uwierzytelniania, jego implementacja w Windowsie została głęboko zintegrowana z usługami katalogowymi Active Directory i stanowi kręgosłup autoryzacji w domenach. Kerberos działa wyłącznie z nazwami domenowymi – bezpośrednie połączenia za pomocą adresów IP są realizowane przy użyciu NTLM. Zrozumienie poszczególnych elementów – ich ról, interakcji oraz potencjalnych wektorów nadużyć – jest niezbędne zarówno dla administratora, jak i dla osoby odpowiedzialnej za bezpieczeństwo środowiska.
KDC
Centrum Dystrybucji Kluczy (KDC) to serce całego systemu Kerberos. W implementacji Microsoftu jest to funkcja pełniona zazwyczaj przez kontroler domeny (Domain Controller). To właśnie KDC odpowiada za wystawianie biletów uwierzytelniających i usługowych, tym samym pełni podwójną funkcję: serwera uwierzytelniającego (Authentication Server, AS) oraz wydającego bilet TGS-a. KDC może być również skonfigurowany na serwerze z Linuksem.
Rola KDC nie kończy się na rozdzielaniu biletów. To on przechowuje również hasła użytkowników w postaci skrótów kryptograficznych w bazie Active Directory, co oznacza, że jego przejęcie daje napastnikowi dostęp do całego środowiska domenowego. Ataki z użyciem DCSynca czy Golden Ticketów bezpośrednio wykorzystują fakt, że KDC przechowuje i obsługuje newralgiczne tajemnice uwierzytelniające.
TGT
TGT to pierwszy bilet wydawany użytkownikowi w procesie logowania. Po wprowadzeniu hasła klient Kerberos generuje z niego skrót i wykorzystuje go do odszyfrowania zaszyfrowanego TGT otrzymanego od AS. Jeśli to się powiedzie,użytkownik uznawany jest za uwierzytelnionego i nie musi już ponownie podawać hasła – jego tożsamość jest potwierdzana za pomocą biletu TGT.
TGT zawiera dane użytkownika, jego znaczniki czasowe i atrybuty sesji, zaszyfrowane przy użyciu klucza głównego konta krbtgt – specjalnego konta serwisowego w AD. To, że klient nie może sam wygenerować TGT, jest fundamentem bezpieczeństwa całego modelu.
Co istotne, TGT nie pozwala na dostęp do żadnej konkretnej usługi. Jest jedynie dowodem uwierzytelnienia i przepustką do uzyskania biletów usługowych (TGS). Jego ważność jest ograniczona czasowo, ale może być odnawialna w ramach określonych przez politykę domeny.
[…]
Adam Kamiński
Autor jest trenerem modeli AI i entuzjastą ofensywnego podejścia do cyberbezpieczeństwa.
