W dzisiejszym, kolejnym z serii artykułów z kampanii „Active Directory Persistence” pokażemy w jaki sposób można ukryć w AD konto użytkownika ze specjalnie skonfigurowanymi atrybutami, które pozwolą w pełni uzyskać najwyższe uprawnienia w katalogu. Skupimy się na specjalnych ustawieniach mechanizmu delegowania uprawnień Constrained Delegation (ograniczone delegowanie) i na tym przykładzie pokażemy scenariusz kompletnego przejęcia domeny.
W poprzednim artykule opisaliśmy, w jaki sposób możemy ukryć konto użytkownika w domenie Active Directory tak, aby nie był on widoczny nawet dla administratorów domeny. Jeśli takiemu użytkownikowi skonfigurujemy w odpowiedni sposób atrybuty oraz oddelegujemy kontrolę do poszczególnych usług, umożliwimy mu przejęcie środowiska. Jakie to są ustawienia/atrybuty? O tym dowiesz się z poniższego artykułu.
Delegowanie uprawnień
Delegowanie to funkcja usługi Active Directory, która umożliwia użytkownikowi lub komputerowi personifikację innego konta (takie proxy do uwierzytelniania innych kont). Ma ona kilka praktycznych zastosowań, które Microsoft omawia w tym poście na blogu.
Funkcję delegowania można skonfigurować na karcie Delegacja (ang. Delegation) na koncie użytkownika lub komputera. Wybierając opcję „Ufaj temu komputerowi w delegowaniu do dowolnej usługi (tylko Kerberos)”, następnie włączamy „nieograniczone delegowanie” (ang. Unconstrained Delegation). Alternatywnie można określić określoną liczbę głównych nazw usług (SPN), aby dokładnie określić, jakie usługi może personifikować użytkownik lub komputer, co zostanie uznane za „ograniczone delegowanie” (Constrained Delegation).
Możliwość zarządzania tym ustawieniem jest kontrolowana przez uprawnienia i prawa użytkownika, które omówimy później w artykule.
Uwaga! Zakładka Delegation pojawi się na komputerze lub użytkowniku w AD, jeśli przypiszemy mu dowolny SPN. Może być on nawet fikcyjny. W celu przypisania SPN dla konta użytkownika możesz użyć komendy: SetSPN.exe -A Nazwa_SPN Nazwa_użytkownika
Jakie uprawnienia są nam potrzebne do zarządzania delegacją?
Podobnie jak w każdym przypadku w Active Directory, delegowanie na komputery i użytkowników może być kontrolowane poprzez uprawnienia. Istnieją dwa zestawy uprawnień, które użytkownik musi mieć, aby móc zarządzać funkcjami delegowania obiektu:
- Prawo użytkownika SeEnableDelegationPrivilege
- Uprawnienia do obiektu do atrybutu msDS-AllowedToDelegateTo, userAccountControl i/lub servicePrincipalName
SeEnableDelegationPrivilege to prawo użytkownika, które jest kontrolowane w ramach lokalnych zasad zabezpieczeń kontrolera domeny (można je skonfigurować w GPO Default Domain Controllers Policy) i jest zarządzane za pomocą zasad grupy. Ustawienie nosi nazwę „Włącz zaufane konta komputerów i użytkowników w zakresie delegowania”.
Bardzo ważne jest, aby zrozumieć, komu przyznano to prawo w ramach usługi Active Directory, ponieważ wszystko, czego taki użytkownik będzie potrzebował, to dostęp do zapisu atrybutów na obiekcie typu komputer/użytkownik, aby włączyć na nim delegację i rozpocząć zbieranie biletów TGT od dowolnego użytkownika, który łączy się z systemem.
Oprócz prawa SeEnableDelegationPrivilege będziemy potrzebować użytkownika z możliwością aktualizowania atrybutów msDS-AllowedToDelegateTo i userAccountControl dla komputera/użytkownika, na którym są przechowywane te ustawienia.
Constrained Delegation – delegowanie ograniczone
Bezpieczniejsze niż delegowanie nieograniczone (Unconstrained Delegation), delegowanie ograniczone jest konfigurowane na komputerze lub koncie użytkownika w usłudze Active Directory na karcie Delegowanie (Delegation) dla obiektu. Ograniczona delegacja umożliwia skonfigurowanie usług, do których konto może delegować, co teoretycznie ograniczyłoby potencjalne zagrożenie w przypadku wystąpienia kompromitacji takiego konta w AD. Zobacz zrzut ekranu poniżej:
Gdy na koncie jest ustawione delegowanie ograniczone w tle zachodzą dwie rzeczy:
- Aktualizowany jest atrybut userAccountControl obiektu za pomocą flagi „TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION”
- Wypełniany jest atrybut msDS-AllowedToDelegateTo nazwą SPN skonfigurowaną na karcie delegowania (zobacz zrzut ekranu powyżej)
W celu przeprowadzenia ataku z wykorzystaniem ograniczonego delegowania, musimy złamać hasło lub skrót hasła do konta, które posiada w AD uprawnienia do zarządzania ograniczonym delegowaniem do usług. Gdy to nastąpi, teoretycznie możemy podszyć się pod dowolnego użytkownika w środowisku, aby uzyskać dostęp do tej usługi.
Na przykład, jeśli ograniczone delegowanie jest skonfigurowane do nazwy SPN MSSQL, możesz uzyskać uprzywilejowany dostęp do bazy danych. Jeśli jest skonfigurowanE do SPN “CIFS/nazwa_kontrolera_ domeny” lub “LDAP/nazwa_kontrolera_domeny” będziemy mogli uzyskać dostęp do do plików kontrolerów domeny oraz przeprowadzić atak DCSync! Zatem istotne jest, jakie atrybuty delegowania mamy skonfigurowane w naszym AD.
Scenariusz ataku – Przejęcie kontroli nad AD z wykorzystaniem ograniczonego delegowania
Poniżej przedstawiamy scenariusz, w którym będziemy mogli przejąć uprawnienia administracyjne w domenie AD, czyli dostać się na kontroler domeny oraz pobrać skróty haseł użytkowników.
Założenia do naszego scenariusza:
- Zdobyliśmy już przyczółek w środowisku patrz artykuł utworzenie przyczółku, w którym utworzyliśmy konto użytkownika o nazwie „backdoor” i ukryliśmy je w AD
- Udało włamać się też na konto z uprawnieniami administratora na stacji roboczej patrz artykuł tutaj. Ewentualnie możemy wykorzystać inne konto w Active Directory, które posiada opisane wyżej uprawnienia, czyli prawo użytkownika SeEnableDelegationPrivilege oraz uprawnienia do obiektu dowolnego użytkownika do atrybutu msDS-AllowedToDelegateTo, userAccountControl i / lub servicePrincipalName, w celu utworzenia na nim ograniczonego delegowania.
Poza dostępem do stacji roboczej i znajomością hasła na użytkownika Backdoor nie potrzeba nam nic więcej. Jedyne co musimy na naszym koncie backdoora skonfigurować to ograniczona delegacja do usług kontrolera domeny. Poniżej prezentujemy poszczególne kroki naszego scenariusza wraz z przeprowadzeniem ataku.
Krok 1 – Utworzenie ograniczonego delegowania dla usług kontrolera domeny
W tym kroku przypisaliśmy dwie usługi LDAP i CIFS, do których będziemy chcieli delegować uprawnienia dla użytkownika Backdoor.
Najpierw utworzymy nieistniejący SPN (SPN/kapitanhack.pl) dla backdoor, aby pojawiła nam się zakładka „Delegation”.
Następnie w konsoli ADUC przypisujemy poniższe usługi do delegowania. Krok ten możemy także wykonać tez automatycznie skryptem.
Krok 2 – ukrywanie użytkownika w AD
W tym kroku ukrywamy użytkownika w domenie – metoda została opisany w naszym poprzednim artykule tutaj.
Krok 3 – logujemy się na stację roboczą na innego (zwykłego) użytkownika
Aby utrudnić wykrycie użycia użytkownika backdoor w środowisku, użyjemy drugiego konta KapitanHack.pl, który jest zwykłym użytkownikiem.
Użytkownik kapitanhack.pl ma standardowe uprawnienia na stacji roboczej.
Krok 4 – uruchamiamy narzędzie kekeo i tworzymy TGT użytkownika backdoor
Z poziomu użytkownika kapitanhack.pl odpalamy narzędzie kekeo, w którym utworzymy bilet Kerberos TGT użytkownika backdoor. Bilet ten wykorzystamy do utworzenie biletu Kerberos TGS, który posłuży nam do przeprowadzenia ataku na kontroler domeny.
Ponieważ znamy hasło na użytkownika backdoor, bez problemu możemy utworzyć bilet TGT za pomocą poniższego polecenia:
tgt::ask /user:backdoor /password:P@ssw0rd /domain:kapitan.hack
Bilet zapisał się na dysku lokalnym:
Krok 5 – tworzymy bilet TGS usługi kontrolera domeny
Ponieważ nasz użytkownik backdoor ma oddelegowane w AD ograniczone delegowanie do dwóch usług LDAP oraz CIFS na kontrolerze domeny, będziemy chcieli to wykorzystać i utworzyć bilet TGS pozwalający uwierzytelnić się nam do kontolera domeny. W przypadku uzyskanego biletu TGS do LDAP będziemy mogli dodatkowo wykonać atak DCSync!
Przed wykonaniem ataku sprawdzamy, że na koncie nie mamy uprawnień do dysku C na kontrolerze domeny:
Krok 6 – dostęp po CIFS do kontrolera domeny
Do wykonania TGS na usługę CIFS w narzędziu kekeo wykonujemy dwie poniższe komendy:
tgs::s4u /tgt:[email protected][email protected] /user:administrator /service:cifs/dc.kapitan.hack /ptt
tgs::s4u /tgt:[email protected][email protected] /user:administrartor /service:cifs/dc /ptt
Sprawdzamy teraz bilety Kerberos jakie zostały przydzielone. Widzimy na liście bilety TGS do usługi CIFS.
Widzimy też odpowiednie flagi takie, jak „forwardable”, które umożliwiają przekazywanie uwierzytelnienia. Poniżej próba dostępu do dysku C na kontrolerze domeny „DC.kapitan.hack”:
Od teraz możemy dostać się po CIFS na kontrolerze domeny, co umożliwia nam uzyskanie dostępu do pliku bazy danych „.DIT” w katalogu systemowym Active Directory. Możemy ją skopiować i zdekodować na boku hashe haseł. Jak to wykonać opisaliśmy tutaj.
Krok 7 – atak DCSync
Nasz użytkownik backdoor oprócz oddelegowanych uprawnień do CIFS posiada także oddelegowane uprawnienia do LDAP. Oznacza to tyle, że będziemy mogli przeprowadzić specjalny typ ataku DCSync, polegający na pobraniu po LDAP skrótów haseł użytkowników Active Directory, w tym najważniejszego skrótu hasła użytkownika serwisowego Kerberos krbtgt. Jeśli posiadamy hash tego konta możemy wykonać kolejny atak Golden Ticket.
W celu wygenerowanie biletu TGS do kontrolera domeny musimy wykonać następujące polecenie w kekeo:
tgs::s4u /tgt:[email protected][email protected] /user:dc /service:ldap/dc.kapitan.hack /ptt
Tutaj poprosiliśmy o bilet TGS kontrolera domeny (DC), aby jeszcze bardziej utrudnić wykrycie ataku. Normalnie kontrolery domeny replikują między sobą hasła i mają standardowo w AD ustawione zezwolenie na delegowanie poświadczeń (z logicznego względu). Zatem takie zachowanie na bilecie TGS kontrolera domeny może być niezauważone przez narzędzia bezpieczeństwa. Po udanym wygenerowaniu biletu sprawdźmy jeszcze listę biletów Kerberos, jakie mamy przydzielone.
W celu wykonania ataku DCSync odpalamy na stacji narzędzie Mimikatz i używamy komendy:
lsadump::dcsync /user:krbtgt
Powyższym poleceniem będziemy mogli pobrać skrót hasła użytkownika krbtgt.
Jeśli ten krok przebiegnie pomyślnie, to mamy najwyższe, przejęte uprawnienia!
Podsumowanie
Pokazaliśmy jak nieodpowiednio kontrolowane, ograniczone delegowanie uprawnień do usług (oraz nieograniczone) w AD może wpłynąć na możliwość stworzenia ukrytego backdoora w środowisku Active Directory. Przypominamy, że użytkownika „backdoor” po ukryciu w AD nie będziemy w stanie wykryć, natomiast sama jego konfiguracja (odpowiednie delegowanie uprawnień do usług) umożliwi nam w każdym momencie uzyskanie najwyższych uprawnień w domenie oraz skompromitowanie jej.
W kolejnym artykule z kampanii Active Directory Persistence przedstawimy inny sposób na ukrycie ciekawych uprawnień w AD pozwalających uzyskać do niego pełna kontrolę. Zachęcamy do komentowania artykułu oraz udostępniania na LinkedIn oraz Facebook. Natomiast, Drogi Czytelniku, żeby dowiedzieć się o mechanizmach wykrywania i zabezpieczania będziesz musiał poczekać na ostatni artykuł bieżącej kampanii.