Atak Golden Ticket – wykrywanie ataków Kerberos i zabezpieczenia Active Directory

Dlaczego konto KRBTGT jest krytyczne

KRBTGT to specjalne konto techniczne, którego zadaniem jest przechowywanie klucza kryptograficznego używanego przez Active Directory do podpisywania biletów podstawowych. Każdy taki bilet musi zostać zweryfikowany przy użyciu klucza KRBTGT — dlatego przejęcie tego klucza oznacza możliwość generowania dowolnych biletów, które system przyjmie jako prawidłowe.

Konsekwencje kompromitacji KRBTGT

• Atakujący może tworzyć bilety poza systemem, bez konieczności dalszego dostępu do kontrolera domeny.

• Może dowolnie modyfikować parametry takiego biletu — tożsamość, grupy uprawnień czy okres ważności.

• Ponieważ podpis biletu pozostaje poprawny, system uzna go za w pełni legalny — tradycyjne narzędzia bezpieczeństwa nie zgłoszą alarmu.

Gdzie znajduje się klucz KRBTGT i jak jest przechowywany

Klucz przypisany do konta KRBTGT znajduje się w bazie katalogowej Active Directory i jest dostępny dla procesów, które mają prawo odczytu danych katalogowych. Atakujący może uzyskać ten klucz na przykład poprzez:

• przejęcie kontroli nad kontrolerem domeny i odczytanie plików katalogowych,

• wykorzystanie uprawnień replikacji katalogu,

• użycie narzędzi wyciągających dane z pamięci systemu.

Po zdobyciu klucza nic nie stoi na przeszkodzie, aby generował bilety poza domeną, na dowolnym systemie, korzystając z ogólnodostępnych narzędzi.

Właściwości biletów, które czynią KRBTGT głównym celem ataku

Bilet podstawowy zawiera zestaw pól takich jak:

• czas wystawienia i czas wygaśnięcia,

• dodatkowy okres odnowienia,

• zestaw flag technicznych określających, jak bilet może być użyty,

• algorytm szyfrowania,

• informacje o użytkowniku i usłudze,

• numer wersji klucza użytego przez system.

Kontroler domeny weryfikuje bilet, sprawdzając zgodność podpisu z aktualnym kluczem KRBTGT. Jeśli atakujący ma właściwy klucz — system zaakceptuje bilet bez dodatkowych pytań. Właśnie dlatego rotacja klucza KRBTGT to jedyny sposób na unieważnienie wcześniej wygenerowanych, fałszywych biletów.

Przykładowy cykl życia biletu

Użytkownik loguje się do domeny i otrzymuje bilet ważny przez kilka godzin, z możliwością jego odnowienia przez ograniczony czas (zwykle kilka dni). Algorytm szyfrowania jest zgodny z polityką bezpieczeństwa, a zestaw flag odzwierciedla standardowe możliwości użytkownika.

W przypadku ataku Golden Ticket schemat wygląda inaczej: bilet może mieć ważność liczona w latach, może zostać zaszyfrowany algorytmem niezgodnym z polityką domeny, a w danych dotyczących użytkownika mogą znaleźć się uprawnienia odpowiadające administratorowi domeny. Bilet nadal będzie wyglądał na prawidłowy, jeśli podpis jest zgodny z kluczem KRBTGT — dlatego potrzebna jest analiza pól biletu, nie tylko samego faktu jego użycia.

Rotacja klucza KRBTGT — znaczenie i ograniczenia

Zmiana klucza KRBTGT powoduje, że wszystkie bilety podpisane wcześniejszym kluczem przestają być uznawane za ważne. To skuteczna metoda unieważnienia biletów tworzonych przez atakującego.

Jednocześnie rotacja:

• wymaga synchronizacji w całej domenie,

• może wpływać na działanie usług,

• powinna być wykonywana w dwóch krokach, aby uniknąć niezgodności między kontrolerami domeny.

Z tego powodu rotacja musi być planowana, testowana i częścią procedur bezpieczeństwa — nie awaryjną reakcją.

Mechanika ataku Golden Ticket — krok po kroku

Krok 1 — uzyskanie dostępu

Co robi atakujący:
Uzyskuje dostęp do sieci i podnosi uprawnienia do poziomu konta administracyjnego. Celem jest możliwość wykonywania działań na hostach uprzywilejowanych, a ostatecznie — dostęp do kontrolera domeny lub kont posiadających możliwość replikacji katalogu.

Typowe wektory i narzędzia:
Ukierunkowane wiadomości phishingowe, wykorzystanie słabych lub wyciekłych haseł, zdalne połączenia z użyciem nieodpowiednio zabezpieczonych kont, nadużywanie procesów administracyjnych i mechanizmów wykonywania poleceń zdalnych, a także lokalne eskalacje uprawnień poprzez luki w systemie.

Artefakty i telemetria do zbierania:

• Logi systemowe: nietypowe logowania interaktywne, loginy na kontach uprzywilejowanych z nowych lub rzadkich źródeł.

• Zdalny dostęp: połączenia zdalne z nietypowych lokalizacji, wzrost sesji przychodzących.

• Procesy i aktywność plików: uruchomienia narzędzi administracyjnych, tworzenie zadań systemowych przez nietypowe konta, pojawiające się nowe binaria.

• Ruch sieciowy: wzrost komunikacji między stacjami roboczymi i serwerami, nietypowe połączenia do udziałów administracyjnych.

• Monitorowanie bezpieczeństwa: procesy startujące z kontekstu zwykłych użytkowników, podejrzane operacje na pamięci procesów.

Co monitorować natychmiast:
Anomalie logowań na kontach uprzywilejowanych, nowe konta posiadające uprawnienia lokalnego administratora, użycie narzędzi administracyjnych na stacjach użytkowników.

Krok 2 — kradzież hasha KRBTGT (pozyskanie materiału klucza)

Co robi atakujący:
Pozyskuje klucz konta KRBTGT lub inny materiał pozwalający podpisywać bilety. Osiąga to poprzez odczyt danych katalogowych, nadużycie mechanizmów replikacji lub odczyt pamięci procesów autoryzacyjnych.

Typowe narzędzia i techniki:
Narzędzia typu “credential extraction”, techniki replikacji katalogu używane w sposób nieautoryzowany, kopiowanie plików katalogowych, tworzenie kopii zapasowych i snapshotów woluminów, odczyt pamięci procesów systemowych.

Artefakty i telemetria do zbierania:

• Replikacja katalogu: żądania replikacji wykonywane z hostów, które nie są kontrolerami domeny.

• Pliki i kopie zapasowe: tworzenie snapshotów na kontrolerach, kopiowanie plików katalogowych, niespodziewane operacje na plikach systemowych.

• Pamięć procesów: odczyt pamięci procesów uwierzytelniających, zwiększona aktywność wejścia/wyjścia związana z tymi procesami.

• Narzędzia do pozyskiwania danych: artefakty wskazujące na użycie mechanizmów ekstrakcji poświadczeń.

• Audyt katalogu: zdarzenia odczytu atrybutów kont i obiektów katalogowych poza standardowym procesem.

Detekcja i ograniczenia:
Należy alarmować każde użycie mechanizmu replikacji poza kontrolerami, wykrywać i blokować odczyty pamięci procesów uwierzytelniających, ograniczać liczbę kont z uprawnieniami do replikacji oraz stosować zasadę minimalnych uprawnień dla kont administracyjnych.

Krok 3 — fałszowanie biletu TGT (tworzenie offline)

Co robi atakujący:
Poza środowiskiem domenowym tworzy TGT podpisany skradzionym kluczem KRBTGT. Ustawia pola biletu zgodnie ze swoimi potrzebami — m.in. tożsamość, grupy, parametry techniczne biletu oraz czas jego ważności (często drastycznie wydłużony).

Typowe operacje:
Wykorzystanie narzędzi umożliwiających generowanie struktur Kerberos offline oraz nadpisywanie parametrów takich jak czas ważności czy typ szyfrowania.

Symptomy w telemetrii:

• Bilety z czasem życia przekraczającym politykę domeny.

• Pojawienie się biletu o typie szyfrowania niezgodnym z ustawieniami domeny.

• Bilety dla kont nieaktywnych lub nieistniejących.

• Niespójności numerów wersji klucza w stosunku do aktualnej polityki.

Co monitorować:
Pełne dane z logów Kerberos oraz ruchu sieciowego, porównanie parametrów biletów z polityką domeny, korelację z katalogiem (status kont, ostatnie logowanie, członkostwa).

Krok 4 — użycie biletu (wykorzystanie w środowisku)

Co robi atakujący:
Przedstawia sfałszowany TGT usługom katalogowym, uzyskuje service ticket i wykorzystuje go do dalszego poruszania się w sieci, eskalacji uprawnień oraz dostępu do zasobów.

Typowe wzorce zachowania:

• Nagłe serie żądań usług: wiele zapytań o dostęp do różnych usług w krótkim czasie.

• Dostęp do kluczowych usług z nietypowych kont: np. zapytania do katalogu lub udziałów plikowych z kont, które wcześniej tego nie robiły.

• Brak błędów logowania: większość zdarzeń to poprawne logowania, co utrudnia detekcję.

• Nieoczekiwane źródła: bilety prezentowane z hostów, które nie należą do profilu normalnego danego konta.

Telemetria do korelacji:

• Zdarzenia Kerberos dotyczące żądań TGT i TGS.

• Logi usług wskazujące na dostęp autoryzowany za pomocą Kerberos.

• Ruch sieciowy poprzedzający i następujący po użyciu biletu.

• Dane katalogowe: status kont, ostatnia aktywność, zmiany uprawnień.

Reakcja natychmiastowa:
W przypadku wykrycia anomalii należy odizolować hosty, zablokować konta prezentujące podejrzane bilety, zebrać materiał do analizy i — jeśli zostanie potwierdzona kompromitacja — przygotować proces rotacji klucza KRBTGT.

Podsumowanie śladów — kluczowe źródła danych

Atak Golden Ticket to sekwencja działań prowadzących do uzyskania klucza KRBTGT. Jego posiadanie daje możliwość tworzenia całkowicie wiarygodnych poświadczeń Kerberos. Obrona musi składać się z dwóch równoległych działań: zabezpieczenia dostępu do materiału klucza oraz szczegółowego monitorowania parametrów biletów i sposobu ich użycia.

1) Kontrolery domeny / Active Directory

Co zbierać: operacje na plikach katalogowych, logi dostępu do obiektów katalogu, zdarzenia replikacji.
Sygnały: snapshoty, kopiowanie plików katalogowych, nieautoryzowane żądania replikacji.
Priorytet: krytyczny.

2) Logi Kerberos i ruch sieciowy

Co zbierać: pełne zdarzenia dotyczące wydawania biletów wraz z parametrami.
Sygnały: bilety z długim czasem życia, niezgodne algorytmy szyfrowania, bilety dla nieistniejących kont.
Priorytet: wysoki.

3) Endpointy i pamięć

Co zbierać: zdarzenia dotyczące podejrzanego odczytu pamięci, użycia narzędzi do pozyskiwania poświadczeń.
Priorytet: wysoki.

4) Uprawnienia i replikacja

Co zbierać: listy kont z przywilejami replikacji, zmiany uprawnień grup uprzywilejowanych.
Priorytet: krytyczny.

5) Wzorce użycia ticketów

Co zbierać: tempo wysyłania żądań, mapa używanych hostów, liczba usług, do których żądano dostępu.
Priorytet: wysoki.

Szybka lista alertów do wdrożenia

• Nieautoryzowane żądania replikacji — krytyczny

• Bilet z czasem życia > 24 godziny — wysoki

• Algorytm szyfrowania niezgodny z polityką domeny — wysoki

• Nagłe serie żądań usług przez jeden principal — wysoki

• Odczyt pamięci procesów uwierzytelniających lub snapshot na kontrolerze domeny — krytyczny

Dlaczego atak Golden Ticket jest trudny do wykrycia

Golden Ticket działa na poziomie protokołu i kryptografii Kerberos, a nie w warstwie procesów czy plików systemowych. W praktyce oznacza to, że większość klasycznych narzędzi bezpieczeństwa obserwuje niewłaściwe sygnały. W tej części opisano mechaniczne powody, dla których detekcja jest skomplikowana, a także konsekwencje techniczne i praktyczne wskazówki dotyczące podejścia, które pozwala realnie wykrywać nadużycia.

Problem 1 — bilet jest „legalny”

Co się dzieje:
Fałszywy bilet TGT jest podpisany prawidłowym kluczem używanym przez domenę. Usługi weryfikujące bilet uznają go za autentyczny, ponieważ wszystkie testy kryptograficzne wypadają poprawnie. Poziom protokołu nie generuje żadnego błędu, a ruch wygląda jak standardowe użycie Kerberos.

Dlaczego klasyczne mechanizmy zawodzą:

• Narzędzia ochronne wykrywają złośliwy kod lub nietypowe procesy — tutaj nie występują.

• Ochrona sieci widzi poprawny ruch Kerberos i nie ma podstaw, aby go blokować.

• Systemy logujące błędy logowania nie reagują, ponieważ operacje są oznaczane jako udane.

Konsekwencje dla detekcji:
Trzeba analizować treść biletu, a nie sam fakt poprawnego podpisu. Niezbędne jest odczytywanie i interpretowanie jego parametrów: czasu obowiązywania, rodzaju szyfrowania, wersji klucza, wskazanego użytkownika oraz listy grup.

Praktyczne reguły detekcji:

• Rejestrować pełne dane o biletach zamiast redukować je do liczników.

• Oznaczać bilety o czasie ważności przekraczającym firmową politykę jako wysokie ryzyko.

• Wykrywać rodzaje szyfrowania niezgodne z polityką domeny.

• Zestawiać bilety z informacjami o stanie kont — nieaktywne lub wyłączone konta wymagają natychmiastowej reakcji.

• Śledzić wersję klucza używaną do podpisywania biletów — niespójności są sygnałem fałszowania.

Problem 2 — trwałość

Co się dzieje:
Dysponując materiałem kryptograficznym, atakujący może tworzyć bilety w dowolnym momencie i używać ich z dowolnej maszyny — nawet takiej, która nigdy nie była naruszona. Może to robić wielokrotnie i przez długi czas, bez dalszego dostępu do domeny czy ponownego włamania.

Dlaczego klasyczne mechanizmy zawodzą:

• Monitorowanie punktów końcowych wykrywa jedynie aktywność na zainfekowanych hostach — tutaj nie musi istnieć infekcja.

• Analiza incydentów nie powiąże pojedynczego użycia biletu z wcześniejszym pozyskaniem klucza, jeżeli brak jest danych historycznych.

• Systemy poszukujące nieudanych logowań nie wykryją niczego, bo operacje są poprawne.

Konsekwencje dla detekcji:
Niezbędne jest monitorowanie długoterminowych trendów, historii użycia kont i korelacja danych z wielu źródeł. Krótkie „okna” analizy nie ujawnią nadużycia.

Praktyczne reguły detekcji:

• Przechowywać i analizować dane Kerberos w długim horyzoncie czasowym.

• Reagować na nagłe użycie konta, które wcześniej było nieaktywne.

• Analizować, z których urządzeń prezentowany jest bilet — zachowania odbiegające od zwyczajowego wzorca podnoszą priorytet alertu.

• Wykrywać bilety o nietypowo długim czasie obowiązywania.

Problem 3 — brak oczywistych błędów w logach

Co się dzieje:
Fałszywy bilet jest poprawny — dlatego logowania i uzyskiwanie usług odbywa się bez błędów. Wiele środowisk rejestruje tylko nieudane próby, traktując udane jako szum. W efekcie nie widać anomalii.

Dlaczego klasyczne mechanizmy zawodzą:

• Skupiają się na błędach, a nie na nietypowych sukcesach.

• Systemy logujące często usuwają szczegółowe informacje o biletach, co uniemożliwia ich analizę.

• Brak korelacji z informacjami o statusie kont utrudnia identyfikację przypadków, gdy poprawne logowanie jest niezgodne z polityką.

Konsekwencje dla detekcji:
Niezbędne jest traktowanie udanych operacji jako możliwie niebezpiecznych i zestawianie ich z szerszym kontekstem domeny.

Praktyczne reguły detekcji:

• Zbierać pełne, nieprzetworzone dane dotyczące operacji Kerberos.

• Wykrywać udane logowania kont, które są nieaktywne lub wyłączone.

• Monitorować tempo uzyskiwania usług — duża liczba usług w krótkim czasie to sygnał rekonesansu.

• Analizować charakterystykę biletów: rodzaj szyfrowania, czas obowiązywania, wersję klucza.

Krótkie checklisty techniczne

Do natychmiastowego wdrożenia:

• Pełne rejestrowanie parametrów biletów Kerberos.

• Alerty dla biletów o czasie działania przekraczającym firmową politykę.

• Alerty dla biletów z rodzajem szyfrowania niezgodnym z polityką.

• Wykrywanie udanych logowań dla kont nieaktywnych.

• Retencja danych Kerberos co najmniej 90 dni.

W krótkim horyzoncie operacyjnym:

• Audyt i ograniczenie praw związanych z replikacją katalogu.

• Wprowadzenie stacji dedykowanych do prac administracyjnych.

• Uporządkowanie procesu rotacji klucza podpisującego bilety.

Golden Ticket nie atakuje procesów ani plików, ale generuje poprawne transakcje Kerberos. Dlatego detekcja wymaga przejścia od analizowania błędów do analizowania, czy „poprawne” zachowania faktycznie odpowiadają polityce i typowym wzorcom domeny. Kluczowe jest odczytywanie parametrów biletów, korelowanie ich z informacjami katalogowymi oraz analiza długoterminowych trendów.

Jakie anomalie w ruchu sieciowym mogą wskazywać na ataki Kerberos?

Aby wykryć nadużycia Kerberos, trzeba analizować zawartość biletu i sposób jego użycia, a nie tylko fakt, że komunikacja dotyczy tego protokołu. Kluczowe są cztery obszary anomalnego zachowania.

1. Niestandardowy czas życia biletu (Ticket Lifetime)

Co analizować:

• czas rozpoczęcia,

• czas zakończenia,

• maksymalny czas odnowienia,

• oraz różnicę pomiędzy czasem zakończenia i rozpoczęcia.

Standardowo bilety mają żywotność liczonych w godzinach. Jeżeli czas ważności zwiększa się do dni, tygodni, miesięcy lub nawet lat — to silny sygnał wskazujący na manipulację.

Przykładowe progi wykrywania:

• powyżej jednego dnia — sygnał ostrzegawczy,

• powyżej tygodnia — poziom wysoki,

• powyżej roku — sytuacja krytyczna.

Dlaczego to działa:
Atakujący wydłużają czas życia biletu, aby utrzymać trwały dostęp.

Jak ograniczać false-positive:

• niektóre aplikacje wsadowe mogą korzystać z dłuższych okresów ważności; warto je uwzględnić w wyjątkach,

• wysoka priorytetyzacja powinna występować wtedy, gdy wydłużony czas życia biletu łączy się z innymi anomaliami, np. nietypowym algorytmem szyfrowania albo użyciem z nietypowego hosta.

Reakcja:
Sprawdzenie konta, przeanalizowanie hostów, które prezentują bilet, ocena poziomu uprawnień konta oraz ewentualne rozpoczęcie procedury remediacji.

2. Słabe lub nietypowe algorytmy szyfrowania (enctype mismatch)

Co analizować:

• typ użytego algorytmu kryptograficznego w bilecie.

W aktualnych środowiskach domenowych dominują algorytmy bazujące na AES. Jeżeli nagle pojawia się algorytm starszego typu, jak RC4 — szczególnie w środowisku, gdzie wymuszany jest AES — jest to sygnał alarmowy.

Dlaczego to działa:
Narzędzia ofensywne często korzystają domyślnie ze starszych typów szyfrowania, które szybciej generują fałszywe bilety.

Jak ograniczać false-positive:
Niektóre starsze aplikacje rzeczywiście wymagają starszych algorytmów — należy je zidentyfikować i traktować jako wyjątki.

Reakcja:
Jeśli pojawia się nietypowy algorytm i nie pochodzi on od aplikacji legacy, traktować to jako poważny wskaźnik ataku i rozpocząć analizę incydentu.

3. Bilety wystawione dla kont nieistniejących lub od dawna nieaktywnych

Co analizować:

• czy konto jest aktywne,

• kiedy konto logowało się ostatnio,

• do jakich grup przynależy.

Jeśli pojawiają się bilety dla kont wyłączonych albo takich, które nie pojawiały się w logach od wielu miesięcy — stanowi to silny sygnał prób nadużycia.

Dlaczego to działa:
Atakujący często wykorzystują stare konta administracyjne lub konta „widmo”, bo pozostają poza codziennym monitoringiem.

Jak ograniczać false-positive:
Niektóre konta usługowe mogą być celowo nieaktywne lub wyłączone — wymagają one listy wyjątków.

Reakcja:
Natychmiastowa weryfikacja konta i hostów prezentujących bilet oraz rozpoczęcie działań dochodzeniowych.

4. Nietypowy wzorzec żądań serwisowych (TGS burst)

Co analizować:

• ile różnych usług jest żądanych przez jedno konto w krótkim czasie,

• z ilu hostów prezentowany jest bilet.

Jeżeli jedno konto nagle żąda dostępu do wielu różnych usług w ciągu kilku minut, wygląda to jak rekonesans lub próba poruszania się lateralnie.

Przykładowe progi:

• powyżej około 20 różnych usług w kilka minut — sytuacja podejrzana,

• powyżej około 50 — wysoki poziom alarmowy,

• jeżeli dodatkowo bilet pojawia się z wielu różnych hostów — jest to bardzo wysokiej pewności wskaźnik nadużycia.

Dlaczego to działa:
Atakujący testują, gdzie mogą użyć przechwyconego lub sfałszowanego biletu.

Jak ograniczać false-positive:
Procesy automatyzacji mogą wykonywać seryjne operacje — warto je dodać do listy wyjątków.

Reakcja:
Izolacja hostów, zablokowanie konta, ograniczenie ruchu Kerberos oraz rozpoczęcie dochodzenia.

Szybkie zestawienie: wskaźnik → priorytet → reakcja

Niestandardowy czas życia biletu (powyżej 24h)
• priorytet: wysoki
• pierwsza reakcja: identyfikacja konta, porównanie z typowymi hostami

Nietypowy algorytm szyfrowania
• priorytet: wysoki
• pierwsza reakcja: sprawdzenie, czy usługa jest legacy; jeśli nie — eskalacja

Bilet dla konta wyłączonego lub od dawna nieaktywnego
• priorytet: krytyczny
• pierwsza reakcja: weryfikacja i blokada konta, śledztwo na hoście

Nagły wzrost liczby żądań TGS (burst)
• priorytet: wysoki lub krytyczny
• pierwsza reakcja: izolacja hostów i analiza kontekstu

Praktyczne wskazówki wdrożeniowe

• Należy analizować pełne pola biletów Kerberos, a nie tylko ich liczbę.

• Trzeba łączyć dane z dzienników uwierzytelniania z informacjami z katalogu — stan konta, ostatnia aktywność, uprawnienia.

• Pojedynczy sygnał nie zawsze oznacza atak, ale kombinacja 2–3 sygnałów zwykle daje mocny dowód nadużycia.

• Progi należy dostosować do realnego ruchu w konkretnej organizacji.

• W miarę możliwości warto mierzyć skuteczność detekcji — czas reakcji, liczbę fałszywych alarmów i pokrycie telemetryczne.

Powiązane techniki ataku: Kerberoasting i Pass-the-Ticket

Kerberoasting i Pass-the-Ticket często współwystępują w kampaniach APT i mogą być zarówno etapami przygotowawczymi prowadzącymi do stworzenia Golden Ticket, jak i efektami ubocznymi kompromitacji środowiska. Obie techniki dotyczą poświadczeń Kerberos, ale różnią się źródłem i sposobem ich pozyskania: Kerberoasting polega na pobieraniu zaszyfrowanych biletów serwisowych i późniejszym łamaniu haseł kont usług w trybie offline, natomiast Pass-the-Ticket polega na przejęciu legalnego biletu z pamięci i wykorzystaniu go ponownie. Golden Ticket natomiast polega na utworzeniu nowych, w pełni poprawnych kryptograficznie biletów dzięki posiadaniu klucza KRBTGT.

Różnice te przekładają się bezpośrednio na sposób detekcji i działania naprawcze. Kerberoasting sygnalizuje aktywność rozpoznawczą i przygotowanie do eskalacji uprawnień (wymaga monitorowania żądań serwisowych i zapytań o SPN), Pass-the-Ticket wskazuje na kompromitację pamięci lub hosta (wymaga analizy anomalii w logowaniach i źródłach prezentacji ticketów), a wykrycie Golden Ticket wymaga natychmiastowego skupienia na danych dotyczących klucza KRBTGT oraz planie jego rotacji.

Kerberoasting — mechanika i sygnatury

Mechanika:
Atak opiera się na pobieraniu biletów serwisowych dla kont usług posiadających przypisane nazwy SPN. Część takiego biletu jest zaszyfrowana kluczem wynikającym z hasła konta usługi. Atakujący zapisuje zaszyfrowany fragment i łamie go offline, uzyskując hasło konta usługi. To często umożliwia eskalację uprawnień lub lateral movement, co może w kolejnych etapach doprowadzić do uzyskania uprawnień wystarczających do wygenerowania Golden Ticket.

Gdzie uderza:
W konta usług powiązane z SPN — zwłaszcza takie, które mają podwyższone uprawnienia lub obsługują kluczowe usługi.

Telemetria i artefakty

• Nietypowo duża liczba żądań serwisowych kierowanych do kont usług.

• Wzrost zapytań katalogowych dotyczących SPN.

• Lokalne zapisy lub eksporty biletów powiązane z procesami pobierającymi bilety.

• Brak nieudanych logowań — żądania serwisowe są poprawne.

Detekcja — skrócone zasady

• Alert, gdy liczba żądań serwisowych dla konta znacząco przekracza jego typowy poziom.

• Alert, gdy pojawia się nagły wzrost zapytań katalogowych dotyczących SPN.

• Korelacja: aktywność Kerberoasting + późniejsze nietypowe działania konta → wyższy priorytet alertu.

Mitigacje

• Stosowanie kont usług zarządzanych automatycznie (np. kont zarządzanych grupowo).

• Wymuszanie silnych, losowych haseł dla kont usług.

• Ograniczanie uprawnień kont usług do minimum.

• Monitorowanie i ograniczanie zapytań o SPN, utrzymywanie list wyjątków.

Pass-the-Ticket — mechanika i sygnatury

Mechanika:
Atakujący przejmuje legalny bilet Kerberos (uwierzytelniający lub serwisowy) z pamięci systemu lub lokalnego cache i używa go na innym hoście. Nie musi znać hasła konta — korzysta z istniejących poświadczeń. Umożliwia to natychmiastowe przemieszczenie się w sieci i dostęp do usług z uprawnieniami właściciela biletu.

Gdzie uderza:
Najpierw w pamięć procesu odpowiedzialnego za sesje bezpieczeństwa na skompromitowanym hoście, następnie w systemy docelowe, w których prezentowany jest przejęty bilet.

Telemetria i artefakty

• Działania wskazujące na odczyt lub kopiowanie pamięci procesów odpowiedzialnych za uwierzytelnianie.

• Logowania Kerberos z hostów niezgodnych z typowym profilem aktywności danego konta.

• Wzorce lateral movement bez towarzyszących nieudanych logowań.

• Zmiany w lokalnym cache biletów.

Detekcja — skrócone zasady

• Alert przy próbie odczytu pamięci procesów odpowiedzialnych za uwierzytelnianie.

• Alert, gdy pojawiają się logowania Kerberos z nietypowych hostów.

• Korelacja: anomalia wskazująca na użycie przejętego biletu + nagły wzrost żądań serwisowych → wysoka pewność ataku.

Mitigacje

• Włączanie mechanizmów izolujących poświadczenia w pamięci.

• Ograniczanie przywilejów umożliwiających debugowanie i odczyt pamięci.

• Blokowanie możliwości tworzenia plików zrzutów procesów przez nieautoryzowane konta.

• Wymuszanie separacji ról oraz korzystanie z utwardzonych stacji administracyjnych.

Różnice względem Golden Ticket

• Źródło poświadczeń:
  Kerberoasting i Pass-the-Ticket wykorzystują istniejące poświadczenia. Golden Ticket polega na generowaniu nowych poświadczeń dzięki kompromitacji klucza KRBTGT.

• Tryb działania:
  Kerberoasting — łamanie hasła konta usługi.
  Pass-the-Ticket — użycie skradzionego, legalnego biletu.
  Golden Ticket — pełna fałszywa emisja biletów.

• Zakres możliwości:
  Golden Ticket umożliwia tworzenie biletów o dowolnym czasie życia i dowolnych grupach, co zapewnia najwyższą trwałość.
  Pass-the-Ticket ogranicza się do bieżących praw właściciela biletu.
  Kerberoasting daje potencjalny dostęp do kont usług, który może prowadzić do eskalacji.

Szybkie reguły detekcji

• Wysoka liczba żądań serwisowych — możliwy Kerberoasting.

• Działania wskazujące na odczyt pamięci — możliwy Pass-the-Ticket.

• Użycie biletu z hosta spoza typowego zestawu — prawdopodobny Pass-the-Ticket lub lateral movement.

• Połączenie wskaźników Kerberoasting + późniejsze anomalne logowania → wysoka pewność eskalacji.

Natychmiastowe działania naprawcze

• Wprowadzanie kont usług zarządzanych automatycznie oraz silnych haseł.

• Ograniczenie dostępu do pamięci procesów i aktywne monitorowanie prób tworzenia zrzutów pamięci.

• Monitorowanie i ograniczanie mechanizmów replikacji katalogu.

• Utrzymywanie gotowego planu działania:
  – wykrycie Kerberoasting → identyfikacja konta i wymuszenie zmiany hasła,
  – wykrycie Pass-the-Ticket → izolacja hostów i analiza timeline’u biletów,
  – podejrzenie Golden Ticket → analiza potencjalnego użycia mechanizmów replikacji i przygotowanie rotacji klucza KRBTGT.

Monitoring jako fundament strategii bezpieczeństwa Active Directory 

Active Directory opiera się na modelu zaufania — Kerberos projektowano jako mechanizm pozwalający usługom ufać tokenom wydanym przez centralny serwis. Ta architektura jest jej siłą, ale też słabością: gdy napastnik przejmie klucz podpisujący (KRBTGT), może tworzyć legalnie wyglądające poświadczenia i działać długo i niewidocznie. W takiej rzeczywistości prewencja i detekcja muszą iść zawsze ramie w ramię. 

Prewencja ogranicza prawdopodobieństwo wejścia atakującego w posiadanie poświadczeń: minimalizacja uprawnień, separacja ról, użycie hardened admin hosts, JIT/JEA i MFA to fundamenty. Szczególną pozycję zajmuje planowa rotacja klucza KRBTGT — to jedyny techniczny sposób unieważnienia wcześniej skradzionych ticketów. Rotacja jest jednak ryzykowna operacyjnie i wymaga testów, dlatego powinna być częścią rutynowych procedur, nie chaotyczną reakcją. 

Mimo tych działań każdy zespół musi założyć, że prewencja kiedyś zawiedzie. Wtedy detekcja staje się jedyną realną szansą na zatrzymanie szkód. Tu nie wystarczy patrzeć na „procesy” albo liczyć failed loginy — konieczne jest zrozumienie semantyki Kerberos i monitorowanie anomalii na poziomie biletu oraz wzorców jego użycia. 

Co musi robić monitoring  

Monitoring musi czytać bilety, rozumieć je i porównywać z kontekstem domeny. To znaczy: wyciągać z AS-REP i TGS-REP pola takie jak client principal, service principal, start, end, renew_till, enctype, kvno i flags, a następnie korelować te dane z metadanymi AD (status konta, lastLogon, członkostwa, prawa replikacji). 

Działania do wdrożenia: 

• Włącz parsing Kerberos na warstwie sieciowej (PCAP/NetFlow) oraz zatrzymuj pełne eventy 4768/4769 z wszystkimi polami. 

• Zintegruj SIEM z AD lookupami (status konta, lastLogon, memberOf, konta z prawami replikacji). 

• Zapisuj te zdarzenia długoterminowo (min. 90 dni, zalecane 365 dni dla krytycznych środowisk). 

Jak łączyć prewencję z detekcją  

Prewencja (np. ograniczenie praw DCSync, gMSA, MFA) zmniejsza ryzyko, ale nie eliminuje konieczności detekcji. Detekcja z kolei musi być zaprojektowana tak, aby szybko identyfikować anomalie, które wskazują na wykorzystanie skradzionych ticketów. 

Checklist operacyjny: 

• Ogranicz prawa replikacji AD do absolutnego minimum i monitoruj każde ich użycie (DCSync). 

• Wdróż gMSA tam, gdzie to możliwe; usuń słabe konta usługowe z uprawnieniami wysokiego poziomu. 

• Wymuś MFA na kontach uprzywilejowanych; upewnij się, że administracja wykonuje się tylko z hardened admin hosts. 

Najważniejsze sygnały, które monitoring musi wychwycić  

Sfałszowany ticket wygląda poprawnie, ale zostawia ślady w polach i we wzorcach użycia. Monitoring powinien wykrywać długie lifetime, mismatch enctypes, bilety dla nieaktywnych kont oraz burst TGS requests. 

Reguły do natychmiastowego wdrożenia: 

• Alert: ticket_lifetime > 24h (podnieś do krytycznego przy >7 dni, najwyższy priorytet >365 dni). 

• Alert: enctype poza listą dozwolonych algorytmów (np. pojawienie się RC4 w środowisku AES-only). 

• Alert: ticket dla konta disabled lub z lastLogon > 365 dni. 

• Alert: burst TGS (np. >20 unikalnych service principals żądanych przez jednego principal w 5 minut). 

Reakcja operacyjna — jak monitoring przekłada się na działania  

Gdy score alertu rośnie, działania muszą być szybkie i uporządkowane: izolacja hostów prezentujących podejrzane bilety, zabezpieczenie kont uprzywilejowanych, zebranie artefaktów do forensics i ocena potrzeby rotacji KRBTGT. 

Sekwencja reakcji: 

1. Zbierz pełne eventy Kerberos, PCAP i AD lookup dla principal. 
2. Izoluj hosty źródłowe i wstrzymaj ruch Kerberos z nich (NAC/firewall). 
3. Tymczasowo zablokuj/degradować konto principal (z uwzględnieniem wpływu na usługi). 
4. Zbierz dumpy pamięci LSASS, snapshoty NTDS.dit i logi replikacji; jeśli KRBTGT został skompromitowany, uruchom plan rotacji (dwustopniowy, testowany). 

EDR wykrywa ataki na hostach, SIEM agreguje logi, ale tylko NDR potrafi parsować protokół Kerberos w ruchu, interpretować pola biletu i powiązać je z mapą domeny w czasie rzeczywistym. To połączenie daje szansę na wykrycie ataku, który z punktu widzenia systemu wygląda „legalnie”. 

Bezpieczeństwo AD to proces, w którym prewencja minimalizuje ryzyko, a monitoring — rozumiejąc protokół i kontekst domeny — daje realną możliwość wykrycia i zatrzymania atakującego, zanim zrobi szkody nieodwracalne. Implementacja parsingu Kerberos, korelacja z AD i przygotowany plan rotacji KRBTGT to trzy elementy, od których warto zacząć natychmiast.