Kerberoasting: jak atakujący łamią konta usługowe w Active Directory

Kerberoasting to jedna z najczęściej wykorzystywanych technik w atakach na sieci Windows — i jedna z najbardziej niedocenianych, bo do jej przeprowadzenia wystarczy jedno zwykłe konto w domenie. W testach Active Directory to niemal rutynowy krok: w wielu organizacjach pozwala w kilka godzin przejąć konto o wysokich uprawnieniach. Zobaczmy, dlaczego działa i jak się przed nim bronić.

Trochę o Kerberosie

W domenie Active Directory uwierzytelnianie opiera się na protokole Kerberos. Uproszczony przepływ:

1. Użytkownik loguje się i otrzymuje od kontrolera domeny (KDC) TGT (Ticket Granting Ticket) — bilet potwierdzający tożsamość.
2. Gdy chce skorzystać z usługi (np. SQL Server, IIS, plik udostępniony), prosi KDC o bilet usługi (service ticket, TGS) dla tej konkretnej usługi.
3. Usługa jest identyfikowana przez SPN (Service Principal Name) powiązany z kontem usługowym, na którym działa.

Kluczowy szczegół: KDC szyfruje bilet usługi (TGS-REP) kluczem wyprowadzonym z hasła konta usługowego. To znaczy, że każdy, kto zdobędzie taki bilet, trzyma w ręku dane zaszyfrowane hasłem konta usługowego.

Mechanizm ataku

Tu pojawia się luka projektowa, którą wykorzystuje Kerberoasting:

1. Każdy uwierzytelniony użytkownik domeny może wylistować konta z ustawionym SPN (to publiczna informacja w katalogu) i poprosić KDC o bilet usługi dla dowolnego z nich. KDC to zrobi — nie sprawdza, czy użytkownik faktycznie zamierza z usługi skorzystać.
2. Atakujący odbiera bilet (TGS-REP), którego fragment jest zaszyfrowany kluczem z hasła konta usługowego.
3. Łamie hasło offline. Ma zaszyfrowany materiał u siebie, więc może atakować go słownikowo/brute-force na własnym sprzęcie (GPU), bez żadnej interakcji z domeną — więc bez blokad konta, bez alarmów o nieudanych logowaniach, bez limitów prób. Narzędzia jak hashcat robią to masowo (tryb 13100 dla biletów RC4, 19700 dla AES).
4. Jeśli hasło jest słabe lub zbyt krótkie, pada — a atakujący zyskuje poświadczenia konta usługowego, często o szerokich uprawnieniach.

Cały atak nie wymaga podniesienia uprawnień na starcie: wystarczy dowolne konto domenowe. To dlatego jest tak popularny.

Dlaczego konta usługowe są łakomym kąskiem

Konta usługowe to idealny cel z kilku powodów:

• Silne uprawnienia. Często mają dostęp do baz, serwerów aplikacyjnych, a bywa, że należą do grup administracyjnych (co jest błędem konfiguracji, ale częstym).
• Stare, słabe hasła. Ustawiane raz, „żeby działało”, i nietykane latami — bo zmiana grozi awarią usługi. Idealne do łamania offline.
• Szyfrowanie RC4. Jeśli konto dopuszcza słabszy algorytm RC4 zamiast AES, bilet łamie się znacznie szybciej. Wiele środowisk wciąż dopuszcza RC4 dla kompatybilności.

Obrona: co realnie utrudnia Kerberoasting

Nie da się „wyłączyć” wydawania biletów usługi — to podstawa działania Kerberosa. Obrona polega na tym, by złamanie biletu było niewykonalne, a próba widoczna.

1. Silne, długie hasła kont usługowych — najlepiej zarządzane automatycznie. To najważniejsza obrona. Skoro atak to łamanie offline, wygrywa entropia hasła. Ręczne pilnowanie 25+ znakowych haseł jest nierealne, dlatego stosuj gMSA/dMSA (group/delegated Managed Service Accounts): Windows sam generuje dla nich bardzo długie, losowe hasła i rotuje je automatycznie. Bilet takiego konta jest praktycznie nie do złamania w rozsądnym czasie. To najskuteczniejszy pojedynczy krok.

2. Wymuś AES, wyłącz RC4. Skonfiguruj konta i domenę tak, by bilety były szyfrowane AES, a nie RC4. To znacząco podnosi koszt łamania i eliminuje najłatwiejszą ścieżkę.

3. Najmniejsze uprawnienia. Konto usługowe powinno mieć dokładnie te uprawnienia, których potrzebuje usługa — i ani jednego więcej. Konto usługowe w grupie Domain Admins to zaproszenie do katastrofy. To element szerszego hardeningu Active Directory.

4. Wykrywanie. Choć łamanie jest offline, samo żądanie biletów jest widoczne. Monitoruj zdarzenie 4769 (żądanie biletu usługi), zwłaszcza gdy jedno konto prosi o bilety wielu różnych SPN w krótkim czasie lub żąda szyfrowania RC4. To sygnaturalny wzorzec Kerberoastingu. Skuteczne wykrywanie wymaga zbierania logów — patrz monitoring bezpieczeństwa.

5. Konta-pułapki (honeypot SPN). Utwórz atrakcyjnie wyglądające konto usługowe z SPN, którego żadna prawdziwa usługa nie używa. Każde żądanie biletu dla niego to niemal pewny sygnał rekonesansu — cichy alarm wczesnego ostrzegania.

Podsumowanie

Kerberoasting działa, bo łączy dwie rzeczy: projektową cechę Kerberosa (każdy użytkownik może pobrać bilet usługi zaszyfrowany hasłem konta) oraz ludzki błąd (słabe, stare hasła kont usługowych o zbyt szerokich uprawnieniach). Obrona jest znana i skuteczna: automatycznie zarządzane, bardzo długie hasła (gMSA/dMSA), wymuszenie AES, najmniejsze uprawnienia oraz wykrywanie po zdarzeniu 4769. Wdrożenie tych czterech rzeczy zamienia „rutynowy krok w każdym pentestcie” w ślepą uliczkę.

Chcesz sprawdzić, czy Twoja domena jest podatna na Kerberoasting i inne techniki AD? Test penetracyjny Active Directory pokazuje dokładnie te ścieżki — umów konsultację. O tym, jak przygotować się do takiego testu, piszemy w osobnym poradniku.

Najczęstsze pytania (FAQ)

Czy Kerberoasting wymaga uprawnień administratora? Nie — i to jest sedno jego groźności. Wystarczy dowolne uwierzytelnione konto w domenie, nawet zwykłego użytkownika. Dlatego pojedyncze przejęte konto (np. przez phishing) często wystarcza, by rozpocząć eskalację uprawnień właśnie tą techniką.

Skąd atakujący wie, które konta zaatakować? Konta usługowe mają w katalogu ustawiony atrybut SPN, który jest widoczny dla każdego uwierzytelnionego użytkownika. Atakujący po prostu listuje konta z SPN i prosi o bilety dla nich — nie musi zgadywać.

Czym są gMSA i dlaczego pomagają? gMSA (group Managed Service Account) to konta usługowe, dla których Windows automatycznie generuje bardzo długie, losowe hasło i regularnie je rotuje, bez udziału administratora. Ponieważ Kerberoasting sprowadza się do łamania hasła offline, hasło o wysokiej entropii czyni atak niewykonalnym w praktyce. To najskuteczniejsza pojedyncza obrona.

Czy wykryjemy Kerberoasting, skoro łamanie odbywa się offline? Łamania nie zobaczysz, ale żądanie biletów — tak. Zdarzenie 4769 na kontrolerze domeny pokazuje prośby o bilety usługi; nietypowy wzorzec (jedno konto prosi o wiele różnych SPN, żądania RC4) to silny sygnał. Konto-pułapka z SPN daje dodatkowy, bardzo czysty alarm.