Delegacja Kerberos i RBCD: pentest Active Directory

Pentest delegacji Kerberos i RBCD sprawdza, czy usługa może poprawnie działać w imieniu użytkownika tylko wobec zamierzonych backendów — oraz czy przejęte konto, host albo uprawnienie zapisu nie rozszerza tej relacji do nieautoryzowanej impersonacji. Najważniejsze nie jest samo znalezienie atrybutu delegacji, lecz ustalenie, kto może go zmienić, jakie SPN obejmuje, czy możliwy jest protocol transition i które wrażliwe konta mogą zostać delegowane.

Delegacja jest legalnym rozwiązaniem „drugiego skoku”: użytkownik łączy się z frontendem, a frontend musi otworzyć bazę, udział lub API w kontekście użytkownika. Źle zaprojektowana zamienia jednak przejęcie serwera aplikacyjnego w możliwość działania jako osoby, które się z nim uwierzytelniły. RBCD — resource-based constrained delegation — przenosi decyzję na obiekt zasobu docelowego, lecz nie oznacza automatycznie „bezpiecznej delegacji”. ACL pozwalający zmienić ten obiekt może być równoważny prawu do impersonacji wobec zasobu.

Kerberos bez skrótów: TGT, TGS, SPN i PAC

Po uwierzytelnieniu klient otrzymuje Ticket Granting Ticket (TGT) od Key Distribution Center. Gdy chce użyć usługi, prosi Ticket Granting Service o service ticket skierowany do Service Principal Name, na przykład usługi HTTP, CIFS lub MSSQL na konkretnym koncie. Serwer odszyfrowuje bilet kluczem powiązanym z kontem usługi i uzyskuje dane autoryzacyjne, w środowisku Windows zwykle obejmujące PAC.

SPN nie jest przyjazną etykietą. Wiąże instancję usługi z kontem posiadającym klucz do walidacji biletu. Duplikaty, nieaktualne wpisy lub SPN przypisany do zbyt uprzywilejowanego konta tworzą problemy bezpieczeństwa i dostępności. Pentest delegacji musi więc mapować usługę, host, konto wykonawcze, SPN oraz backend jako jeden przepływ.

Z punktu widzenia obrony ważne jest rozróżnienie poświadczenia od biletu. Nie każda delegacja przekazuje hasło lub TGT użytkownika. S4U pozwala usłudze uzyskać bilety w imieniu użytkownika przy decyzji KDC. Ryzyko nadal jest realne, ponieważ backend otrzymuje bilet, w którym klientem jest użytkownik.

Cztery modele delegacji, cztery profile ryzyka

Unconstrained delegation

W delegacji nieograniczonej usługa może otrzymać przekazany TGT użytkownika i używać go do innych usług. Dokumentacja MS-SFU podkreśla, że mechanizm forwarded-TGT nie ogranicza, do których usług frontend może później działać jako użytkownik. Kompromitacja hosta z takim zaufaniem może więc narazić poświadczenia osób, które się z nim łączą.

To rozwiązanie powinno być eliminowane z serwerów członkowskich. Wyjątki wymagają udokumentowanego właściciela, izolacji, monitoringu i planu migracji. Konta uprzywilejowane powinny mieć flagę „Account is sensitive and cannot be delegated”, a odpowiednie konta użytkowników mogą korzystać z Protected Users po testach kompatybilności.

Klasyczna constrained delegation (KCD)

Klasyczne KCD zapisuje na koncie frontendu listę usług docelowych w msDS-AllowedToDelegateTo. Administrator mówi: usługa A może delegować do SPN B. Zakres jest mniejszy niż w unconstrained, ale przejęcie A nadal pozwala działać jako delegowalni użytkownicy wobec dozwolonych backendów.

Opcja „Use Kerberos only” zakłada, że użytkownik uwierzytelnił się Kerberosem i frontend ma odpowiedni bilet. Opcja „Use any authentication protocol” włącza protocol transition, dzięki któremu frontend może reprezentować użytkownika po uwierzytelnieniu innym mechanizmem. Ta druga funkcja zwiększa elastyczność, lecz poszerza model zagrożeń: usługa sama deklaruje tożsamość dla S4U2self, a KDC decyduje o dalszej delegacji.

Resource-based constrained delegation (RBCD)

RBCD zapisuje decyzję po stronie zasobu docelowego w descriptorze bezpieczeństwa atrybutu msDS-AllowedToActOnBehalfOfOtherIdentity. W praktyce serwer C wskazuje, które principal-e — na przykład konto komputera B — mogą działać wobec C w imieniu użytkownika. Microsoft udostępnia właściwość PrincipalsAllowedToDelegateToAccount jako wygodną reprezentację konfiguracji.

Zaletą operacyjną jest to, że właściciel zasobu może zarządzać relacją bez zmiany konta frontendu i mechanizm lepiej wspiera scenariusze między domenami. Ryzyko polega na ACL: podmiot posiadający GenericWrite, WriteProperty, WriteDACL, WriteOwner albo kontrolę nad właścicielem obiektu C może wpisać kontrolowane konto jako zaufany frontend. RBCD jest więc bezpieczne tylko tak dobrze, jak ochrona obiektu docelowego i tożsamości dopuszczonej do delegacji.

Protocol transition i S4U

S4U2self pozwala usłudze uzyskać bilet do samej siebie zawierający tożsamość i dane autoryzacyjne użytkownika, który mógł zostać uwierzytelniony innym protokołem. S4U2proxy pozwala następnie uzyskać service ticket do innej usługi w imieniu tego użytkownika, jeśli polityka delegacji na to pozwala.

Microsoft [MS-SFU] opisuje, że w bilecie zwracanym dla Service 2 pole klienta reprezentuje użytkownika, nie Service 1. Backend traktuje żądanie jak działanie użytkownika. To właśnie zamierzona funkcja — i powód, dla którego przejęcie zaufanego Service 1 ma poważne skutki.

Jak powstaje ścieżka ataku RBCD?

Do nadużycia nie wystarczy przeczytać atrybut. Potrzebne są co najmniej: kontrolowana tożsamość usługi z kluczem, możliwość zmiany descriptoru na zasobie docelowym, poprawne SPN oraz osiągalność KDC i usługi. W wielu domenach użytkownicy mogli tradycyjnie tworzyć ograniczoną liczbę kont komputerów przez ustawienie ms-DS-MachineAccountQuota, ale nie wolno zakładać tej wartości. Audytujemy ją i rzeczywiste delegacje tworzenia obiektów.

Typowa ścieżka grafowa wygląda tak:

konto A ma prawo zapisu do obiektu komputera C albo do grupy zarządzającej C;
A kontroluje konto usługi B lub może utworzyć dopuszczoną tożsamość;
descriptor RBCD na C zostaje rozszerzony o B;
B korzysta z przepływu S4U, aby KDC wydał bilet do usługi na C w imieniu delegowalnego użytkownika;
uprawnienia użytkownika na C decydują o ostatecznym wpływie.

To opis modelu, nie instrukcja operacyjna. W pentestach produkcyjnych nie modyfikujemy RBCD na serwerze krytycznym tylko po to, by „udowodnić Domain Admin”. Wystarczy bezpieczny dowód kontroli ACL, symulacja grafu i — jeżeli klient wymaga walidacji — dedykowany host oraz konto testowe bez uprawnień biznesowych.

Zakres technicznego audytu

Obiekty i atrybuty

Inwentaryzujemy konta użytkowników, komputerów i gMSA z flagami delegacji, msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity, SPN, ownerem i pełnym ACL. Szukamy praw bezpośrednich i dziedziczonych, delegacji przez grupy oraz kontroli nad OU, z którego obiekt dziedziczy ustawienia.

Nie ograniczamy się do kont z włączoną delegacją. Równie istotne są podmioty mogące ją dopiero skonfigurować, zmienić SPN, zresetować sekret konta usługi albo przejąć host. Łączymy dane z szerszym grafem bezpieczeństwa Active Directory.

Zależności aplikacyjne

Dla każdej relacji ustalamy właściciela, frontend, backend, SPN, konto usługi, protokół pierwszego skoku, wymagany drugi skok i grupy użytkowników. Konfiguracja bez właściciela jest długiem bezpieczeństwa. Nie usuwamy delegacji, zanim test integracyjny nie potwierdzi, że aplikacja jej nie potrzebuje.

Szczególnie ryzykowne są backendy wysokiej wartości: kontrolery domeny, CIFS na serwerach zarządzających, LDAP, systemy wdrożeniowe, platformy wirtualizacji i bazy z danymi wrażliwymi. Delegacja do konkretnego SPN może jednak mieć szerszy wpływ na hoście zależnie od sposobu egzekwowania usługi; dlatego oceniamy to na poziomie implementacji, nie tylko nazwy.

Konta chronione

Flaga „sensitive and cannot be delegated” powinna chronić konta administracyjne oraz inne tożsamości, których impersonacja jest nieakceptowalna. Grupa Protected Users daje dodatkowe ograniczenia, w tym brak NTLM i blokadę delegacji, ale może złamać stare aplikacje. Wdrażamy ją etapowo, nie jako masową zmianę w trakcie pentestu.

Administrację relacjami delegacji należy objąć PAM i aktywacją just-in-time. Osoba wdrażająca aplikację nie musi mieć stałego prawa do modyfikacji dowolnych obiektów komputerów.

Bezpieczna metodologia walidacji

Faza 1: odczyt i model

Zbieramy konfigurację kontem z minimalnym prawem odczytu. Budujemy tabelę source principal → delegation type → target SPN/resource → mutable by → protected users. Każdej krawędzi nadajemy właściciela i uzasadnienie biznesowe.

Faza 2: analiza skutku bez zmiany

Sprawdzamy, czy kontrola nad frontendem albo ACL zasobu pozwala teoretycznie spełnić warunki S4U. Analizujemy segmentację, dostęp do KDC, konfigurację usług i prawa testowego użytkownika na backendzie. Graf nie jest dowodem wykonania, lecz może wystarczyć do oceny krytycznej, gdy aktywna walidacja tworzyłaby nowe zaufanie na produkcji.

Faza 3: kontrolowany scenariusz

Jeśli reguły zaangażowania dopuszczają test, klient tworzy izolowany zasób C, konto usługi B i użytkownika U z nieszkodliwym plikiem lub rekordem. Zespół konfiguruje relację zatwierdzoną przez właściciela, potwierdza pozytywny dostęp U oraz negatywny dostęp innego użytkownika. Nie żądamy biletów dla administratorów, nie dotykamy prawdziwych danych i nie utrwalamy zmian poza oknem.

Faza 4: cleanup i retest

Usuwamy wpis RBCD/KCD, rotujemy sekret tożsamości testowej, czyścimy testowe SPN i potwierdzamy, że poprzedni przepływ jest odrzucony po wygaśnięciu/unieważnieniu artefaktów. Zmiana w konsoli nie dowodzi remediacji, jeśli ważne bilety nadal działają do końca życia.

Detekcja nadużyć delegacji Kerberos

Monitoring powinien łączyć zmiany katalogowe z wydawaniem biletów. Dla AD monitorujemy modyfikacje msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity, SPN, ownera i ACL. Zdarzenie 5136 może pokazać zmianę obiektu katalogowego przy odpowiedniej polityce audytu; 4662 może dostarczyć operacje na obiekcie, ale wymaga właściwego SACL i strojenia.

Zdarzenie 4769 rejestruje żądanie service ticket na kontrolerze domeny. Analizujemy service name, account, client address, typ szyfrowania, status, flagi oraz wzorzec czasu. Pojedynczy TGS nie jest automatycznie złośliwy. Wysoką wartość ma korelacja: nowa zmiana RBCD, pierwszy bilet do nietypowego SPN, wrażliwa tożsamość klienta i źródło, które wcześniej nie używało backendu.

Alerty powinny obejmować:

dodanie nowego principal-a do descriptoru RBCD;
klasyczne KCD rozszerzone o LDAP, CIFS lub inną usługę krytyczną;
zmianę flag protocol transition albo unconstrained delegation;
SPN przeniesiony na inne konto lub utworzony na tożsamości użytkownika;
bilet S4U dla konta administracyjnego, które powinno być niedelegowalne;
użycie relacji przez host inny niż zinwentaryzowany frontend.

Microsoft Defender for Identity udostępnia oceny bezpiecznej konfiguracji delegacji, ale wynik narzędzia powinien być początkiem analizy, nie jedyną podstawą. SOC musi mieć runbook: właściciel relacji, oczekiwany frontend, ostatnia zmiana, izolacja hosta, cofnięcie zaufania i wpływ na bilety.

Hardening: preferuj minimalną relację i minimalny podmiot

Najpierw usuwamy unconstrained delegation z serwerów członkowskich. Następnie zamieniamy klasyczne KCD na relację o najmniejszym zestawie SPN albo RBCD tam, gdzie model właściciela zasobu jest właściwy — ale dopiero po zabezpieczeniu ACL zasobu. Migracja mechanizmu bez redukcji praw zapisu tylko przesuwa ryzyko.

Konta usług powinny używać gMSA, jeśli aplikacja je wspiera, oraz minimalnych praw lokalnych i domenowych. SPN muszą być unikalne, zinwentaryzowane i przypisane do właściwego konta. Frontendy z delegacją wymagają segmentacji, EDR, ograniczonej administracji, patchingu i zakazu logowania kont uprzywilejowanych.

Projekt Zero Trust powinien traktować każdy drugi skok jako jawny przepływ: określona usługa, podmiot, backend, akcja i sygnał telemetryczny. Samo „wewnętrzna sieć” nie jest uzasadnieniem zaufania.

Checklista delegacji Kerberos i RBCD

Delegacja a test całego środowiska

RBCD rzadko jest izolowanym problemem. Najczęściej łączy błędne ACL, możliwość kontroli konta komputera, zbyt szerokie prawa usługowe i brak ochrony kont administratorów. Dlatego ocena powinna wejść do technicznego pentestu Active Directory, a w szerszej symulacji — do scenariusza lateral movement. Zakres i zasady bezpiecznego rozszerzenia testu omawia porównanie red team vs pentest.

Jeżeli potrzebujesz mapy delegacji, bezpiecznej walidacji RBCD i planu migracji bez przestoju aplikacji, skontaktuj się z Breachroad. W raporcie pokażemy konkretną krawędź zaufania, podmiot mogący ją zmienić, wpływ i scenariusz detekcji — bez gotowych payloadów ani działania na cudzych danych.