BloodHound – analiza infrastruktury AD cz. 1

Wstęp

W ostatnim wpisie obiecałem opowiedzieć nieco o narzędziach przydatnych przy pracy z infrastrukturą IT opartą o Active Directory. Chciałbym w najbliższym czasie skupić się na następujących rozwiązaniach:

• BloodHound
• Ping Castle
• PowerSploit (moduł PowerView)

Analiza domeny opartej o Active Directory to nieodłączna część audytów infrastruktury, testów penetracyjnych czy działań Red Team wobec testowanych systemów. Na wstępie chciałbym podkreślić, iż rozwiązania te są pomocne w rekonesansie, analizie, eskalacji uprawnień czy w lateral movement. Nie jest to więc oprogramowanie, które pomoże nam uzyskać punkt zaczepienia (ang. initial foothold) w badanej/atakowanej sieci. Schemat działania powyższych narzędzi wykorzystuje prawa zwykłych użytkowników do odczytu praktycznie całości AD (wyjątkiem są różne atrybuty, np. ms-Mcs-AdmPwd dla obiektów typu „Computer”, ale o tym kiedy indziej). Musimy więc uprzednio uzyskać możliwość wykonywania kodu jako dowolny użytkownik w domenie.

Domena how2hax.pl – zanim zaczniemy mówić o BloodHound

W poprzednim wpisie wykorzystaliśmy lokalną domenę how2hax.pl do przechwycenia ruchu sieciowego i zdobycia hasła jednego z użytkowników tej domeny. W tym oraz w co najmniej kilku z następnych wpisów również będę korzystać z domeny how2hax.pl. Abyście mogli jednak w łatwy i szybki sposób przetestować opisywane przeze mnie narzędzia oraz podatności stworzyłem na GitHubie mały projekt w oparciu o narzędzie Ansible. Projekt how2hax to nic innego jak playbooki Ansible podzielone na role tak, aby można było w wygodny sposób skonfigurować wybrany przez nas moduł z domeny. Całość działa w ramach wirtualnego środowiska pracy Python, więc nie musicie martwić się o problemy z zależnościami w playbookach czy o wersje Ansible.

Projekt w założeniu ma być łatwo adaptowalny do każdego środowiska opartego o AD. Główną ideą jest jego modułowy charakter i rozszerzalność. Na chwile obecną możecie skupić się tylko i wyłącznie na roli „domain”, która w założeniu ma odpowiadać za konfigurację, dodawanie lub usuwanie podatności związanych stricte z domeną. Innymi słowy, będą tam skrypty odpowiedzialne za konfigurację grup, użytkowników, kontenerów i uprawnień. Będą się tam znajdować również ustawienia związane z politykami bezpieczeństwa GPO. Inne role, np. rola „wk” dotyczy tylko i wyłącznie konfiguracji i podatności na stacjach roboczych, rola „sql” będzie odpowiadać za konfigurację serwerów SQL itd.

W chwili obecnej środowisko nie różni się niczym od tego wykorzystywanego w poprzednim wpisie.

BloodHound – wprowadzenie

BloodHound w przejrzysty sposób wizualizuje i analizuje zależności i relacje występujące między różnymi obiektami w domenie. Narzędzie jest oparte o grafową bazę danych neo4j i jej graficzną reprezentację otrzymaną dzięki systemu Linkurious.

źródło: https://mcpmag.com/articles/2019/11/13/bloodhound-active-directory-domain-admin.aspx

BloodHound pozwala nam śledzić relacje między użytkownikami, grupami, kontami serwisowymi czy innymi obiektami w domenie AD. Pomaga również w znajdywaniu ścieżek z punktu A do B w oparciu o analizę zależności i uprawnień między kolejnymi węzłami ścieżki. Program w końcu ma wbudowany niewielki manual dotyczący podatności i uprawnień, podpowie więc co zrobić gdy kontrolowany przez nas użytkownik ma możliwość przejęcia kontroli nad innym kontem lub domeną w ogóle.

BloodHound generalnie składa się z dwóch części:

• Bazy danych wraz z graficzną prezentacją badanej infrastruktury
• Tzw. „collectorów”, czyli programów służących do zbierania informacji o środowisku AD:
  • SharpHound
  • AzureHound

Pierwszy z nich służy do zebrania informacji o strukturze AD zbudowanej w oparciu o zasoby lokalne (ang. on premise). Drugi analizuje infrastrukturę opartą o rozwiązanie Azure AD. W kolejnym etapie będziemy analizować środowisko zbudowane w oparciu o zasobie lokalne, a nie o chmurę – użyjemy więc programu SharpHound.

Podstawy Red Teaming, czyli obfuskacja kodu.

Podczas typowych white-boxowych, „audytowych” testów mamy dużą swobodę i komfort pracy. Nie musimy przejmować się SOCiem, oprogramowaniem antywirusowym, ryzykiem wykrycia. W sytuacji kiedy prowadzimy działania Red Teamowe, testy typu black-box lub testujemy działania SOC musimy być przygotowani na sytuację, w której będziemy musieli unikać systemów AV, IDS itp. Uważam, iż powinniśmy wychodzić ze strefy komfortu i budować mindset Red Teamera. Zagadnienia związane z omijaniem antywirusów (ang. AV Evasion) nie należą do najłatwiejszych. Profesjonalne grupy posiadają swoje własne zdolności obfuskacji kodu czy skrytego wykradania danych (ang. data exfiltration), ale uważam, iż każdy z nas powinien budować u siebie takie zdolności. Przy tej okazji chciałbym polecić ten filmik IppSeca o obfuskacji Mimikatza.

Jak zachowuje się Windows Defender przy SharpHound?

Złośliwy skrypt PowerShell

Złośliwy plik wykonywalny

Po odpowiednim przerobieniu skrypt SharpHound przestał być wykrywalny przez Microsoft Defendera z aktualną bazą sygnatur.

Fragment kodu po obfuskacji

Zebranie informacji o domenie AD

W celu zgromadzenia danych o badanym środowisku należy uruchomić zaobfuskowany skrypt SharpHound.ps1 (poniżej ze zmienioną nazwą). Niestety, ale również w tym przypadku Windows Defender zadziałał prawidłowo i nie pozwolił na załadowanie do pamięci skompresowanego programu SharpHound.exe.

W takiej sytuacji mamy dwa dwa wyjścia:

• Dalsza próba obfuskacji kodu programu SharpHound;
• Próba uruchomienia programu z w pełni kontrolowanej przez nas stacji roboczej, w kontekście przejętego użytkownika.

Ponieważ omijanie AV (ang. AntiVirus evasion) nie jest tematem tego wpisu, załóżmy, iż posiadamy dane logowania użytkownika „m.miller” i możemy wykorzystać stację z systemem Windows, która posiada połączenie sieciowe z resztą badanej infrastruktury. Schemat naszego środowiska testowego wygląda wiec następująco:

Aby wykonać skrypt SharpHound w kontekście użytkownika domenowego musimy uruchomić program PowerShell dzięki polecenia „runas”.

A następnie w nowym oknie uruchomić interesujący nas skrypt i czekać na wyniki.

Polecam zwrócić uwagę na górną belkę programu Powershell i informację, iż program jest uruchomiony w kontekście użytkownika „m.miller” z domeny „how2hax”. Program SharpHound zapisał zebrane przez siebie dane w plikach formatu json, a następnie spakował je do jednego archiwum zip. Wskazał nam również ścieżkę zapisanego archiwum. W tej sytuacji nie pozostaje nam nic innego jak skopiować utworzony plik na stację Kali Linux z zainstalowanym oprogramowaniem BloodHound.

Analiza zebranych danych

W celu przeanalizowania danych należy po prostu przenieść skompresowany plik do otwartego programu BloodHound. Omawiane oprogramowanie zawiera w sobie zestaw predefiniowanych kwerend, które mogą pomóc nam na wstępną analizę zebranych danych. Ze swojej strony polecam jednak „dociągnąć” sobie dodatkowe zapytania ze tego repozytorium . Jeszcze więcej zapytań można znaleźć tu.

Korzystając z powyższych zapytań możemy już całkiem nieźle zorientować się w sytuacji. Przede wszystkim powinniśmy szukać tzw. „Low hanging fruits”, czyli najprostszych punktów zaczepienia, które mogą pomóc nam eskalować uprawnienia, wykonać tzw. lateral movement czy w końcu przejąć całkowicie kontrolę nad domeną.
Rzeczy, które powinny zainteresować nas w pierwszej kolejności to:

• konta wobec których możemy przeprowadzić atak typu AS-REP Roasting,

• konta skojarzone z SPNami,

• użytkownicy, którzy mają prawa prawa przeprowadzać replikację z kontrolerem domeny,

• członkowie grup DNS Admins itp.

W kolejnych krokach powinniśmy sprawdzić, które konta są uprawnione do delegacji i uwierzytelnienia w imieniu innych użytkowników domeny. Z punktu widzenia działań typowo Red Teamowych będzie nas np. interesowało na jakich stacjach aktywne sesje mają administratorzy domeny i to te stacje powinniśmy wziąć jako pierwsze na celownik. Arsenał dostępnych kwerend jest ograniczony tylko przez naszą wyobraźnię, intuicję i rzecz jasna wiedzę.

W kolejnym wpisie będziemy kontynuowali analizę domeny how2hax.pl przy pomocy narzędzia BloodHound. Znajdziemy i wykorzystamy co najmniej dwa konta standardowego użytkownika, które posiadają niestandardowe uprawnienia pozwalające na przejęcie kontroli nad domeną.