Kerberoasting – mechanizm działania ataku na konta usługowe Active Directory

W środowisku Active Directory nie wszystkie ataki zaczynają się od przejęcia administratora. Bardzo często droga do wysokich uprawnień prowadzi przez pozornie zwykłe konta techniczne.

Serwery baz danych, aplikacje biznesowe, systemy backupu czy platformy monitoringu często działają przy użyciu specjalnych kont:

svc_sql
svc_backup
svc_app

To właśnie takie konta są częstym celem techniki:

Kerberoasting.

Atak ten wykorzystuje sposób działania protokołu Kerberos i fakt, że bilety usługowe mogą być uzyskane przez zwykłego użytkownika domenowego.

Największym problemem nie jest samo pobranie biletu.

Problemem jest możliwość późniejszego offline’owego łamania hasła konta usługi.

Czym jest Kerberoasting?

Kerberoasting to technika ataku, w której napastnik:

1. zdobywa konto zwykłego użytkownika domeny,
2. wyszukuje konta usługowe posiadające SPN,
3. pobiera bilety Kerberos dla tych usług,
4. próbuje złamać zaszyfrowane fragmenty biletów offline.

Schemat:

Zwykły użytkownik domeny

          ↓

Wyszukanie kont usługowych

          ↓

Pobranie Service Ticket

          ↓

Atak offline na hasło

          ↓

Przejęcie konta usługi

Najważniejsze:

atakujący nie musi być administratorem domeny.

Wystarczy zwykłe konto użytkownika Active Directory.

Dlaczego Kerberos umożliwia taki atak?

Kerberos działa na zasadzie biletów.

Podczas dostępu do usługi użytkownik otrzymuje:

Service Ticket (TGS).

Przykład:

Użytkownik chce połączyć się z SQL Server:

sql01.firma.local

Kontroler domeny generuje bilet:

MSSQLSvc/sql01.firma.local

Ten bilet jest zaszyfrowany kluczem związanym z kontem usługi.

Przykład:

svc_sql

Problem:

jeżeli atakujący pobierze taki bilet, może próbować odgadnąć hasło konta usługi bez kontaktu z domeną.

SPN – kluczowy element Kerberoasting

Za Kerberoasting odpowiada mechanizm:

Service Principal Name (SPN).

SPN informuje Active Directory:

jakie usługi działają pod danym kontem.

Przykłady:

MSSQLSvc/sql01.firma.local

HTTP/web01.firma.local

CIFS/fileserver.firma.local

Konto:

svc_sql

może posiadać:

MSSQLSvc/sql01.firma.local

To oznacza:

„Ta usługa SQL działa jako svc_sql.”

Kerberoasting krok po kroku

Etap 1 – zdobycie zwykłego konta domenowego

Atakujący nie musi posiadać wysokich uprawnień.

Wystarczy:

user123@firma.local

Przykładowe źródła:

• phishing,
• wyciek danych,
• złośliwe oprogramowanie,
• przejęcie sesji.

Etap 2 – wyszukanie kont usługowych

Atakujący sprawdza Active Directory pod kątem kont posiadających SPN.

Przykład:

svc_sql
svc_backup
svc_web

Interesujące są szczególnie konta:

• z wysokimi uprawnieniami,
• ze starymi hasłami,
• używane na wielu serwerach.

Etap 3 – pobranie biletu Kerberos

Użytkownik domeny może poprosić kontroler domeny o Service Ticket.

Nie jest wymagane:

• członkostwo Domain Admin,
• specjalne uprawnienia.

Bilet zawiera zaszyfrowaną część chronioną kluczem konta usługi.

Etap 4 – łamanie offline

Atakujący przenosi bilet poza środowisko firmy.

Następnie próbuje:

• zgadywać hasła,
• używać słowników,
• stosować brute force.

Cały proces odbywa się offline.

To ważne, ponieważ:

• konto nie jest blokowane,
• kontroler domeny nie widzi prób.

Przykład realnego scenariusza

Firma:

firma.local

Posiada konto:

svc_backup

które:

• istnieje od 7 lat,
• ma hasło ustawione ręcznie,
• posiada uprawnienia do serwerów backupu.

Atak:

1. Pracownik otwiera zainfekowany dokument.
2. Malware przejmuje zwykłe konto.
3. Atakujący znajduje:

svc_backup

4. Pobiera bilet Kerberos.
5. Łamie hasło offline.
6. Przejmuje konto usługi.
7. Wykorzystuje uprawnienia backupu do dalszego ataku.

TIP administratora: konta usługowe są często bardziej wartościowe niż zwykli użytkownicy

Wiele organizacji bardzo dobrze chroni:

Administrator
Domain Admin

ale zapomina o:

svc_sql
svc_backup
svc_monitoring

Tymczasem konto usługi często posiada:

• dostęp do baz danych,
• dostęp do plików,
• prawa administracyjne na serwerach.

Czasami przejęcie jednego konta usługowego daje większe możliwości niż przejęcie zwykłego administratora.

Dlaczego stare konta usługowe są tak niebezpieczne?

Typowy problem:

Konto:
svc_application

Utworzone:
2017

Hasło:
Aplikacja123!

Hasło:

• nigdy niezmieniane,
• krótkie,
• używane przez wiele osób.

To idealny cel dla Kerberoasting.

Kerberoasting a Golden Ticket

Oba ataki dotyczą Kerberos, ale są zupełnie inne.

Kerberoasting a Silver Ticket

Również często są mylone.

Kerberoasting:

Atakujący:

pobiera bilet
↓
łamie hasło konta usługi

Silver Ticket:

Atakujący:

posiada hash konta usługi
↓
tworzy fałszywy bilet

Kerberoasting może być etapem prowadzącym do Silver Ticket.

Jak chronić Active Directory przed Kerberoasting?

1. Stosowanie gMSA

Najlepsza praktyka dla usług Windows.

Group Managed Service Accounts:

• automatycznie zmieniają hasła,
• używają bardzo długich sekretów,
• ograniczają znajomość hasła przez administratorów.

2. Silne hasła kont usługowych

Jeżeli gMSA nie jest możliwe:

stosuj:

• minimum kilkadziesiąt znaków,
• losowe hasła,
• regularną rotację.

Unikać:

Backup2025!
Sql12345
Firma2026

3. Minimalne uprawnienia

Konto:

svc_sql

nie powinno być:

Domain Admin

jeżeli nie jest to absolutnie konieczne.

Zasada:

konto usługi powinno mieć tylko takie prawa, jakie są wymagane do działania aplikacji.

4. AES zamiast RC4

Starsze środowiska mogą korzystać z:

RC4-HMAC

który jest bardziej podatny na szybkie łamanie.

Preferowane:

AES128
AES256

5. Audyt kont posiadających SPN

Administratorzy powinni regularnie sprawdzać:

• jakie konta mają SPN,
• jakie mają uprawnienia,
• kiedy zmieniano hasła.

Przykład:

setspn -Q */*

Wykrywanie Kerberoasting

Warto analizować:

Event ID 4769

Kerberos Service Ticket Operations.

Podejrzane zachowania:

• wiele żądań TGS w krótkim czasie,
• nietypowe konta użytkowników,
• nietypowe typy szyfrowania.

Warto wiedzieć: Kerberoasting jest trudny do zatrzymania samą blokadą logowania

To jedna z jego największych zalet dla atakującego.

Nie mamy klasycznej sytuacji:

10 błędnych haseł → blokada konta

Atak odbywa się offline.

Dlatego ochrona musi polegać na:

• dobrych hasłach,
• gMSA,
• ograniczaniu uprawnień,
• monitoringu.

Podsumowanie

Kerberoasting pokazuje, że bezpieczeństwo Active Directory nie kończy się na ochronie kont administratorów.

Największym zagrożeniem często są:

• stare konta usługowe,
• ręcznie ustawiane hasła,
• nadmierne uprawnienia aplikacji.

Atakujący wykorzystuje legalny mechanizm Kerberos, aby zdobyć bilety usługowe i próbować złamać hasła offline.

Najlepsza ochrona:

gMSA + silne hasła usługowe + minimalne uprawnienia + Kerberos AES + monitoring SPN.

W dojrzałym środowisku Active Directory konta usługowe traktuje się jako element krytycznej infrastruktury, ponieważ ich przejęcie może stać się początkiem znacznie większego ataku.

Polecane wpisy

Konsekwencje kradzieży danych osobowych: Jakie zagrożenia wiążą się z utratą prywatnych informacji?

Konsekwencje kradzieży danych osobowych: Jakie zagrożenia wiążą się z utratą prywatnych informacji? Kradzież danych osobowych to jedno z najpoważniejszych zagrożeń Czytaj dalej

Porównanie kanałów przesyłania ukrytych danych: E-mail, OnionShare, PasteBin (.onion)

📡 Porównanie kanałów przesyłania ukrytych danych: E-mail, OnionShare, PasteBin (.onion) 🧱 1. Wprowadzenie: dlaczego ukrywać dane w transmisji? Nawet jeśli Czytaj dalej