Ataki na Active Directory: jak rozpoznać Kerberoasting i ograniczyć uprawnienia kont usługowych

Wystarczy jedno skompromitowane konto zwykłego użytkownika domeny, aby zyskać pełen dostęp do infrastruktury Active Directory. Nie potrzebne są do tego uprawnienia administracyjne, exploity na podatności zero-day ani głośne narzędzia hakerskie. Jeżeli w Twoim środowisku funkcjonują konta usługowe z przypisanymi nazwami SPN (Service Principal Name) i słabymi hasłami, atakujący mogą w pełni legalnie zażądać od kontrolera domeny biletu Kerberos, pobrać go na swój komputer i łamać w zaciszu własnej maszyny. Ten atak, znany jako Kerberoasting, jest niezwykle trudny do wykrycia tradycyjnymi metodami, ponieważ z perspektywy systemów bezpieczeństwa przypomina standardowy ruch sieciowy. Czas uświadomić sobie, że każde nieprawidłowo zabezpieczone konto usługowe to tykająca bomba.

Cel i mechanika zagrożenia: Dlaczego konta usługowe są najsłabszym ogniwem

Zrozumienie mechanizmu ataku to pierwszy krok do jego mitygacji. Kerberoasting bazuje na fundamentalnej zasadzie działania protokołu Kerberos. Kiedy użytkownik lub usługa chce uzyskać dostęp do zasobu (na przykład bazy danych SQL), wysyła do kontrolera domeny żądanie wydania biletu TGS (Ticket Granting Service). Kontroler domeny przygotowuje taki bilet i szyfruje jego część za pomocą skrótu hasła (hasha) konta, na którym uruchomiona jest docelowa usługa.

Problem polega na tym, że każdy uwierzytelniony użytkownik domeny może zażądać biletu TGS do dowolnej usługi posiadającej rekord SPN, niezależnie od tego, czy ma do niej faktyczny dostęp. Atakujący wykonuje zapytanie o bilet, kontroler domeny mu go dostarcza, a następnie napastnik eksportuje ten bilet offline. Od tego momentu atak nie generuje już żadnego ruchu w sieci. Haker używa narzędzi takich jak Hashcat czy John the Ripper, aby metodą siłową odgadnąć hasło konta usługowego.

Zabójcza kombinacja: SPN i uprawnienia administracyjne

Konta usługowe często łączą w sobie trzy cechy, które czynią je idealnym celem. Po pierwsze, posiadają atrybut SPN, co umożliwia pobranie biletu. Po drugie, ich hasła rzadko są zmieniane, ponieważ administratorzy obawiają się przerw w działaniu aplikacji produkcyjnych. Hasła te nierzadko są tworzone przez zewnętrznych wdrożeniowców według powtarzalnych schematów (np. FirmaSQL2023!). Po trzecie, dla „wygody” lub z braku czasu na precyzyjną konfigurację, konta te są często dodawane do grupy Domain Admins.

Przejęcie hasła do takiego konta oznacza natychmiastowe kompromitację całej domeny. Atakujący loguje się jako usługa SQL, zyskuje uprawnienia administratora domeny i w ciągu kilkunastu minut przejmuje pełną kontrolę nad środowiskiem.

Faza 1: Rozpoznanie i detekcja ataków Kerberoasting

Wykrywanie prób Kerberoastingu wyłącznie na podstawie logów jest zadaniem niewdzięcznym. Proces ten generuje ogromną liczbę fałszywych alarmów (false positives), ponieważ normalne działanie użytkowników w sieci również polega na ciągłym żądaniu biletów TGS. Istnieją jednak specyficzne wskaźniki kompromitacji (IoC), na które musisz zwrócić uwagę.

Monitorowanie logów zdarzeń Windows (Event ID 4769)

Głównym źródłem wiedzy o żądaniach biletów TGS jest dziennik zdarzeń Security na kontrolerach domeny, a dokładnie Event ID 4769 (Żądano biletu usługi Kerberos). Analizując to zdarzenie, szukaj konkretnych anomalii.

Zwróć uwagę na algorytm szyfrowania (Ticket Encryption Type). Jeśli usługa obsługuje nowoczesne standardy, bilet powinien być szyfrowany za pomocą AES (wartości 0x12 dla AES-128 lub 0x13 dla AES-256). Narzędzia używane do Kerberoastingu, takie jak Rubeus, często domyślnie wymuszają żądanie biletu z szyfrowaniem RC4 (wartość 0x17), ponieważ hashe RC4 są znacznie szybsze do złamania w trybie offline. Masowe pojawienie się zdarzeń 4769 z typem szyfrowania 0x17, zwłaszcza dla kont usługowych, jest bardzo silnym sygnałem alarmowym.

Kolejnym wskaźnikiem jest częstotliwość i zakres. Jeśli jedno konto użytkownika (często stacja robocza) nagle generuje zapytania o bilety TGS do dziesiątek różnych kont usługowych w krótkim czasie, masz do czynienia z próbą oskalpowania (roasting) całego środowiska. Z

perspektywy analityka SOC to klasyczny objaw zautomatyzowanego skanowania przy użyciu takich skryptów jak Invoke-Kerberoast, działających w ramach popularnych frameworków ofensywnych.

Złap hakera na gorącym uczynku: Konta-pułapki (Honeytokens)

Zamiast tonąć w logach z fałszywymi alarmami, wdróż najskuteczniejszą metodę detekcji Kerberoastingu: konta typu honeytoken. Proces ten jest niezwykle prosty i daje niemal stuprocentową pewność wykrycia ataku.

1. Utwórz w Active Directory nowe konto użytkownika, którego nazwa sugeruje wysoką wartość (np. svc_sql_backup lub admin_bd_prod).
2. Przypisz do niego losowy SPN poleceniem: setspn -s MSSQLSvc/fakeserver.domena.local:1433 svc_sql_backup.
3. Ustaw dla tego konta ekstremalnie długie i skomplikowane hasło (np. 60 znaków), aby uniemożliwić jego złamanie.
4. Kryterium sprawdzenia: Skonfiguruj system SIEM lub alerty w logach tak, aby natychmiast powiadamiały Cię o każdym zdarzeniu Event ID 4769 dotyczącym wyłącznie tego konkretnego konta.

Ponieważ żadna legalna aplikacja w Twojej sieci nie korzysta z tego fałszywego konta, każde zapytanie o bilet TGS dla niego oznacza, że ktoś właśnie skanuje Twoje środowisko metodą Kerberoastingu.

Faza 2: Inwentaryzacja środowiska krok po kroku

Zanim zaczniesz zmieniać hasła, musisz dokładnie wiedzieć, czym dysponujesz. Cel tej fazy to zidentyfikowanie wszystkich potencjalnych celów ataku w domenie.

Krok 1: Wylistowanie kont z SPN
Uruchom PowerShell z uprawnieniami administratora i wykonaj zapytanie sprawdzające, które konta użytkowników posiadają atrybut ServicePrincipalName:
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties PasswordLastSet, MemberOf | Select-Object Name, PasswordLastSet, MemberOf

Krok 2: Analiza krytyczności uprawnień
Przejrzyj kolumnę MemberOf z powyższego raportu. Zaznacz na czerwono każde konto, które należy do grup uprzywilejowanych: Domain Admins, Enterprise Admins, Administrators lub grup mających prawa do zarządzania infrastrukturą wirtualną.

Przy planowaniu kolejnych kroków pomocny może być tekst: Atak na router domowy: objawy, szybkie czyszczenie i twarda konfiguracja.

Krok 3: Weryfikacja wieku haseł
Sprawdź wartość PasswordLastSet. Konta, których hasła nie były zmieniane od lat, są najbardziej narażone na to, że ich hasła są słabe i krótkie (zgodne ze starymi politykami bezpieczeństwa).

Faza 3: Procedura mitygacji i ograniczania uprawnień

Gdy wiesz już, gdzie leży problem, czas przejść do utwardzania środowiska. Wykonuj te kroki w ściśle określonej kolejności.

Krok 1: Natychmiastowa rotacja haseł z zachowaniem złożoności
Dla wszystkich tradycyjnych kont usługowych, których nie możesz zlikwidować, wygeneruj nowe hasła. Hasło do konta z SPN musi mieć absolutne minimum 25-30 znaków (najlepiej wygenerowanych losowo). Taka długość sprawia, że atak offline typu brute-force / słownikowy staje się obliczeniowo nieopłacalny, niezależnie od użytego algorytmu szyfrowania biletu.

Krok 2: Ograniczenie szyfrowania RC4 na korzyść AES
Zmuś kontrolery domeny do używania silniejszego szyfrowania dla biletów. We właściwościach konta usługowego w Active Directory (zakładka Account), zaznacz opcje:
– This account supports Kerberos AES 128 bit encryption
– This account supports Kerberos AES 256 bit encryption

Krok 3: Implementacja gMSA (Group Managed Service Accounts)
To docelowy model zabezpieczenia usług. gMSA to specjalne konta w AD, dla których kontroler domeny automatycznie zarządza hasłem (zmienia je co 30 dni) i ustawia hasła o długości 120 znaków.
*Procedura przejścia:* Utwórz klucz KDS (Key Distribution Services) w domenie (wymagane tylko raz) -> Utwórz konto gMSA -> Skonfiguruj przypisanie serwerów uprawnionych do korzystania z gMSA -> Zmień tożsamość logowania usługi na serwerze docelowym na nowo utworzone konto gMSA.

Krok 4: Wdrożenie zasady najmniejszych uprawnień (Least Privilege)
Konta usługowe z SPN nigdy nie mogą znajdować się w grupie Domain Admins. Usuń je stamtąd. Zamiast tego zdeleguj im dokładne uprawnienia (np. do odczytu konkretnego OU, logowania jako usługa na wybranych maszynach, czy dostępu do bazy w SQL Server), używając precyzyjnych list kontroli dostępu (ACL).

Lista kontrolna: Audyt i zabezpieczenie przed Kerberoastingiem

Zanim uznasz środowisko za bezpieczne, upewnij się, że spełniasz poniższe kryteria:

• [ ] Raport wszystkich kont z przypisanym SPN został wygenerowany i zaktualizowany.
• [ ] Żadne konto użytkownika z przypisanym SPN nie należy do grupy Domain Admins ani innych grup wysokiego ryzyka.
• [ ] Wszystkie tradycyjne konta usługowe posiadają hasła o długości minimum 25 znaków.
• [ ] Konta usług wspierają szyfrowanie AES 128/256 we właściwościach AD.
• [ ] Wdrożono co najmniej jedno konto typu honeytoken z SPN, a system monitoringu alertuje o wystąpieniu Event ID 4769 dla tego konta.
• [ ] Rozpoczęto projekt migracji tradycyjnych kont usługowych na konta gMSA (Group Managed Service Accounts).

Krytyczne ostrzeżenia przed wdrożeniem zmian

Scenariusz wdrożeniowy: Przed, w trakcie i po mitygacji

Aby uniknąć paraliżu infrastruktury, proces eliminacji ryzyka Kerberoastingu podziel na trzy odrębne etapy operacyjne:

• Przed: Wygeneruj pełną listę kont z atrybutem SPN. Ustal właścicieli biznesowych i technicznych poszczególnych usług. Utwórz konta-pułapki (honeytokens), aby upewnić się, że w czasie planowania mitygacji nikt nie skanuje Twojej sieci. Ustal harmonogram okien serwisowych.
• W trakcie: Podziel proces na mniejsze partie. Zacznij od systemów niekrytycznych. Jeśli aplikacja to obsługuje, migruj tożsamość bezpośrednio na konta gMSA. Jeśli migracja do gMSA nie jest możliwa, zaktualizuj hasła statyczne do 30 znaków, a następnie uruchom ponownie docelowe aplikacje, pilnie monitorując ich stabilność. Na samym końcu odbieraj kontom nadmierne uprawnienia w AD.
• Po: Włącz ścisłe monitorowanie logów na kontrolerach domeny. Skonfiguruj system SIEM tak, aby automatycznie alertował zespół bezpieczeństwa, gdy ktokolwiek z administratorów przypisze nowy atrybut SPN do standardowego konta użytkownika lub usunie wymóg szyfrowania AES.

Praktyczny finał: Twój pierwszy ruch po lekturze

Zabezpieczenie przed Kerberoastingiem to proces, ale weryfikacja podatności zajmuje zaledwie chwilę. Wiedząc, że atakujący mogą pobrać bilet i łamać hasło offline nie wzbudzając alertów antywirusowych, musisz działać od razu. Co należy zrobić w tej sekundzie?

1. Zaloguj się na stację z zainstalowanymi narzędziami RSAT (Remote Server Administration Tools).
2. Otwórz konsolę PowerShell z uprawnieniami administratora.
3. Skopiuj, wklej i wykonaj poniższe polecenie:
   Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties MemberOf | Where-Object {$_.MemberOf -match "Domain Admins"} | Select-Object Name
4. Kryterium sprawdzenia: Zobacz, czy konsola zwróciła jakiekolwiek wyniki.

Jeśli wynik powyższego polecenia nie jest pusty, oznacza to, że masz w środowisku tykającą bombę – konta usługowe z SPN będące administratorami domeny. Utwórz natychmiast honeytoken, by sprawdzić, czy ktoś nie skanuje sieci, a wspomniane konta z wyniku zapytania oznacz jako cel numer jeden do bezwzględnej zmiany hasła na 30-znakowe i usunięcia z grupy Domain Admins przy najbliższym oknie serwisowym.