Rekonesans środowiska Active Directory za pomocą BloodHound [bezpieczeństwo Windows]

W tym artykule przyjrzymy się bliżej narzędziu BloodHound — Six Degrees of Domain Admin. Aplikacja została stworzona w języku JavaScript i zbudowano ją za pomocą platformy Electron. Graficzna wizualizacja korzysta z bazy danych Neo4j.

Podczas eksperymentu będziemy korzystać ze stacji roboczej z Windows oraz stacji Windows Server (obie stacje jako maszyny wirtualne na Microsoft Azure) oraz dowolnego komputera z Windows. Z powodu przełączania się pomiędzy środowiskami w celu lepszego odnalezienia przez Czytelnika, który rysunek jest z jakiej maszyny w tekście zastosowano oznaczenia:

• rysunek dotyczy: stacja robocza Windows
• rysunek dotyczy: Windows Server
• rysunek dotyczy: dowolny komputer (z Windows)
• rysunek dotyczy: stacja robocza Windows lub Windows Server

Oznaczenia znajdują się w podpisach rysunków.

Oprogramowanie BloodHound korzysta z teorii grafów, aby odkryć trudne do znalezienia i często niezamierzone relacje w środowisku Active Directory oraz Azure. Zarówno atakujący jak i obrońcy mogą użyć tego narzędzia, aby łatwo zidentyfikować złożone ścieżki ataku oraz urządzenia, które mogą przechowywać cenne zasoby czy zawierać konta użytkowników z wysokimi uprawnieniami.

Narzędzie BloodHound służy do analizy danych. W celu zebrania zestawu danych należy po prostu uruchomić SharpHound lub AzureHound na systemie podłączonym do domeny w środowisku Active Directory lub niepodłączonym do domeny (co zaprezentowano dalej). BloodHound w wersji dla systemu Windows składa się z dwóch głównych elementów:

• programów zbierających informacje takich jak skrypt PowerShell nazwany AzureHound.ps1 oraz aplikacja dla platformy .NET o nazwie SharpHound.exe,
• programu BloodHound.exe do wizualizacji zebranych danych w formie grafów.

Istnieje również wersja narzędzia BloodHound dla systemów Linux. Jednak nie jest ona tematem tego artykułu.

Warto dodać, że Dirk-jan Mollema stworzył skrypt BloodHound.py, który pozwala zbierać informacje z systemów Linux, macOS oraz Windows, ale wymagane jest zainstalowanie obsługi języka Python 3. Uwaga: Skrypt nie jest oficjalnie wspierany przez twórców BloodHound i zgodnie z opisem na GitHub współpracuje z BloodHound w wersji 4.1 lub nowszej.

O tym, jak wygląda sieć informatyczna oparta na systemie Windows w strukturach różnych organizacji (np. przedsiębiorstwa), można przeczytać w artykule Bezpieczeństwo Windows – czym jest LSASS dump. Jak się przed nim chronić? (sekurak.pl). W skrócie: komputery są połączone w domenę sterowaną przez kontrolery domeny. Tak połączone maszyny pracujące pod systemem Windows mogą tworzyć rozległe struktury nazywane drzewami i lasami. Z tego właśnie powodu narzędzie BloodHound jest bardzo przydatne dla administratorów, niebieskich zespołów, analityków cyberbezpieczeństwa czy threat hunters, ponieważ obrazuje ono w formie grafu powiązania pomiędzy komputerami połączonymi w domenę. Ułatwia to usunięcie ukrytych i niechcianych powiązań, które mogą być niebezpieczne, a tym samym umożliwia szybkie zredukowanie ścieżek ataku. Ale uwaga: W analogiczny sposób z programu mogą skorzystać czerwone zespoły (ang. red team) podczas testów bezpieczeństwa, a nawet cyberprzestępcy podczas ataku na sieć informatyczną. 

Przygotowanie środowiska domenowego z Active Directory na platformie Microsoft Azure

Do zbudowania środowiska, które posłuży jako laboratorium, wykorzystamy platformę chmurową Microsoft Azure. Interfejs aplikacji internetowej Azure pozwala w łatwy sposób tworzyć maszyny wirtualne (rysunek 1).

Rysunek 1. Tworzenie maszyny wirtualnej na platformie chmurowej Microsoft Azure (rysunek dotyczy: dowolny komputer)

Tworzenie maszyny wirtualnej, która będzie kontrolerem domeny

Budowanie środowiska laboratoryjnego rozpoczniemy od stworzenia maszyny wirtualnej z przykładowym systemem Windows Server 2019 Datacenter (rysunek 2). W rzeczywistości komputerów pełniących rolę kontrolera domeny np. w przedsiębiorstwie jest więcej w celach zapewnienia większej dostępności i niezawodności.

Rysunek 2. Tworzenie maszyny wirtualnej z systemem Windows Server 2019 (rysunek dotyczy: dowolny komputer)

Na rysunku 3 przedstawiono ekran z podstawowej konfiguracji maszyny wirtualnej. Dla uproszczenia prowadzenia testów, warto ustawić tworzenie testowych maszyn wirtualnych w jednej sieci.

Rysunek 3. Ustawienia sieci dla tworzonej maszyny wirtualnej Windows Server (rysunek dotyczy: dowolny komputer)

Ostatni etap kreatora tworzenia maszyn wirtualnych przedstawiono na rysunkach 4 oraz 5.

Rysunek 4. Ostatni krok kreatora tworzenia maszyny wirtualnej Windows Server (rysunek dotyczy: dowolny komputer)

Rysunek 5. Informacja o pomyślnym wdrożeniu maszyny wirtualnej Windows Server (rysunek dotyczy: dowolny komputer)

Z utworzoną maszyną wirtualną można połączyć się (rysunek 6) za pomocą zdalnego pulpitu (RDP), SSH lub Azure Bastion. Dla celów eksperymentalnych wystarczy zwykły zdalny pulpit. Maszyna otrzymała przykładową nazwę DC jako skrót od angielskich słów domain controller.

Rysunek 6. Wyświetlanie danych potrzebnych do połączenia się z maszyną wirtualną Windows Server (rysunek dotyczy: dowolny komputer)

W celu połączenia się z maszyną wirtualną przez zdalny pulpit potrzebne będą dane takie jak publiczny adres IP (rysunek 7), nazwa użytkownika oraz hasło (ustawiane wcześniej w kreatorze).

Rysunek 7. Skopiowanie publicznego adresu IP maszyny wirtualnej Windows Server (rysunek dotyczy: dowolny komputer)

W przypadku chęci posługiwania się nazwą domeny (nie adresem IP), która jest łatwiejsza do zapamiętania, można użyć własnej domeny internetowej i powiązać ją z adresem IP za pomocą wpisu typu A w strefie DNS. Dotyczy to adresów IP w wersji 4. Dla adresów IPv6 typ rekordu to AAA.

Rysunek 8. Wpisy w strefie DNS u dostawcy domeny internetowej (rysunek dotyczy: dowolny komputer)

W celu połączenia się ze zdalną maszyną należy wprowadzić jej publiczny adres IP (lub nazwę domeny), nazwę użytkownika i hasło. Przedstawiono to na rysunku 9.

Rysunek 9. Połączenie z maszyną wirtualną Windows Server przez zdalny pulpit (rysunek dotyczy: dowolny komputer)

Po pomyślnym podłączeniu pulpitu zdalnego powinien pojawić się interfejs graficzny narzędzia Server Manager, który służy do administrowania serwerami z systemem Windows (rysunek 10).

Rysunek 10. Narzędzie do zarządzania serwerem z systemem Windows (rysunek dotyczy: Windows Server)

W celu stworzenia środowiska domenowego należy zainstalować rolę Active Directory Domain Services poprzez kliknięcie Add roles and features (rysunek 10 oraz 11).

Rysunek 11. Instalacja roli Active Directory Domain Services poprzez narzędzie Server Manager (rysunek dotyczy: Windows Server)

Po zakończeniu instalacji nowej roli na serwerze Windows wymagane będzie ponowne uruchomienie maszyny wirtualnej (rysunek 12).

Rysunek 12. Ustawienie maszyny wirtualnej, aby została kontrolerem domeny (rysunek dotyczy: Windows Server)

W celu ustawienia wybranej maszyny wirtualnej, aby stała się kontrolerem domeny, należy wybrać opcję Promote this server to a domain controller (rysunki 13 i 14).

Rysunek 13. Monit o dokończenie konfiguracji kontrolera domeny na Windows Server (rysunek dotyczy: Windows Server)

Rysunek 14. Ustawienie maszyny wirtualnej Windows Server jako kontrolera domeny (rysunek dotyczy: Windows Server)

W celach eksperymentalnych można stworzyć nowy las z wcześniej posiadaną domeną internetową (rysunki 15, 16 i 17).

Rysunek 15. Tworzenie nowego lasu z domeną główną (rysunek dotyczy: Windows Server)

Rysunek 16. Ustawienie poziomu funkcjonowania i hasła odzyskiwania DSRM  (rysunek dotyczy: Windows Server)

Rysunek 17. Wymagania wstępne zostały spełnione i można rozpocząć instalację (rysunek dotyczy: Windows Server)

Każda maszyna w tym laboratorium ma publiczny adres IP (nazywany też zewnętrznym adresem IP), co sprawia, że teoretycznie są one widoczne i dostępne z Internetu. Teoretycznie, ponieważ ruch do maszyny wirtualnej jest filtrowany przez oprogramowanie nazywane zaporą ogniową (ang. firewall). Z tego powodu wymagane będzie dopuszczenie ruchu sieciowego (rysunek 18) dla potrzebnych usług, czyli w przypadku stworzonego Windows Server będą to LDAP oraz DNS (rysunek 19).

Rysunek 18. Dodawanie reguły zabezpieczeń dla ruchu sieciowego na platformie Microsoft Azure (rysunek dotyczy: dowolny komputer)

Rysunek 19. Reguły portu wejściowego dla ruchu sieciowego na platformie Microsoft Azure (rysunek dotyczy: dowolny komputer)

Tworzenie stacji roboczej na platformie Microsoft Azure

Kolejna maszyna wirtualna będzie odgrywała rolę stacji roboczej (rysunki 20 i 21), dlatego wybrano dla niej system operacyjny Microsoft Windows 10 Pro (nie: Windows Server).

Rysunek 20. Tworzenie maszyny wirtualnej, która będzie stacją roboczą w domenie (rysunek dotyczy: dowolny komputer)

Rysunek 21. Ostatni krok kreatora tworzenia stacji roboczej na platformie Microsoft Azure (rysunek dotyczy: dowolny komputer)

Łączenie się ze stacją roboczą można sobie ułatwić dodając odpowiedni wpis w strefie DNS dostawcy domeny internetowej (rysunek 22). Możliwe jest wtedy korzystanie z aliasu (rysunek 23), zamiast podawania adresu IP. Poprzez zmniejszenie wartości parametru TTL można uzyskać szybszy czas propagacji DNS.

Rysunek 22. Subdomena (alias) dla stacji roboczej Windows (rysunek dotyczy: dowolny komputer)

Rysunek 23. Łączenie się ze stacją roboczą Windows za pomocą aliasu alpha (rysunek dotyczy: dowolny komputer)

Przykładowe środowisko (laboratorium) składa się z dwóch maszyn wirtualnych na platformie Microsoft Azure:

• stacja robocza (Windows 10 Pro),
• kontroler domeny (Windows Server 2019).

Używamy też lokalnego komputera na którym można analizować zdobyte informacje.

Połączenie z maszynami wirtualnymi przez zdalny pulpit przedstawiono na rysunku 24.

Rysunek 24. Połączenie ze stacją roboczą oraz serwerem Windows (rysunek dotyczy: dowolny komputer)

W przypadku awarii możliwe jest ponowne wdrożenie maszyny wirtualnej (rysunek 25) lub też w ostateczności usunięcie.

Rysunek 25. Możliwość ponownego wdrożenia maszyny wirtualnej na platformie Microsoft Azure (rysunek dotyczy: dowolny komputer)

Uruchomienie SharpHound na komputerze niepodłączonym do domeny

Dokumentacja BloodHound wspomina o możliwości uruchomienia dowolnego programu w kontekście użytkownika domeny, nawet ze stacji roboczej, która nie jest podłączona do domeny. Potrzebne są dane uwierzytelniające.

Jest to możliwe za pomocą polecenia RunAs z flagą /netonly np.:

RunAs /netonly /user:daisy@blue-umbrella.online cmd.exe

W celu weryfikacji poprawności polecenia RunAs można wywołać net view np.:

net view \\blue-umbrella.online\

Jeśli w konsoli tekstowej pojawi się NETLOGON i SYSVOL to jesteśmy na dobrej drodze. W celu wywołania SharpHound pozostaje wpisać:

.\SharpHound.exe -d blue-umbrella.online

Oczywiście najpierw należy pobrać narzędzie, ale o tym dalej.

Rysunek 26. Uruchomienie programu w kontekście użytkownika domeny ze stacji roboczej niepodłączonej do domeny (rysunek dotyczy: stacja robocza Windows)

Utworzenie obiektów w Active Directory za pomocą BadBlood w celach szkoleniowych

Przy opisywaniu BloodHound nie można nie wspomnieć o narzędziu BadBlood. Jest to program pozwalający wypełnić szkoleniowe środowisko Active Directory danymi testowymi oraz relacjami podobnymi do tych ze świata rzeczywistego.

Cytat: fills a Microsoft Active Directory Domain with a structure and thousands of objects. The output of the tool is a domain similar to a domain in the real world.

Źródło: https://github.com/davidprowe/BadBlood

W celu przygotowania laboratorium do ćwiczeń należy uruchomić skrypt w języku PowerShell o nazwie Invoke-BadBlood.ps1 znajdujący się w katalogu BadBlood-master. Na dzień pisania tego tekstu skrypt nie wymaga dodatkowych parametrów. Warto też zweryfikować czy posiada się uprawnienia administracyjne do domeny (Domain Admin i Schema Admin), a także zainstalowany Active Directory PowerShell. W środowisku, które stworzyliśmy na Microsoft Azure jest to domyślnie włączone.

Jeśli jesteśmy w katalogu z programem, to wywołanie skryptu BadBlood w konsoli PowerShell wygląda następująco:

.\Invoke-BadBlood.ps1

Uwaga: Wykonywanie zewnętrznych skryptów PowerShell jest domyślnie zablokowane i będzie skutkować błędem w stylu:

Invoke-BadBlood.ps1 cannot be loaded because running scripts is disabled on this system.

Jako, że jest to tylko i wyłącznie środowisko szkoleniowe, to możemy usunąć zabezpieczenie poleceniem:

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine

Rezultat poprawnego wywołania skryptu BadBlood prezentuje rysunek 27.

Rysunek 27. Uruchomienie narzędzia BadBlood na maszynie wirtualnej Windows Server (rysunek dotyczy: Windows Server)

Należy też wziąć pod uwagę sytuacje w których będzie potrzebne zmodyfikowanie lub dodanie całkiem nowych obiektów do Active Directory w sposób ręczny. Można to wykonać np. za pomocą interfejsu użytkownika Active Directory – Users and Computers, jak przedstawiono na rysunku 28.

Rysunek 28. Po wykonaniu skryptu BadBlood istnieje też możliwość ręcznego dodania większej ilości obiektów (rysunek dotyczy: Windows Server)

Podłączenie stacji roboczej do domeny Windows

Dołączenie maszyny wirtualnej do wcześniej utworzonej domeny przeprowadza się po uruchomieniu apletu Panelu sterowania o nazwie sysdm.cpl. Należy odznaczyć grupę roboczą i wprowadzić nazwę domeny. W przypadku napotkania błędu związanego z DNS (rysunek 29), należy wprowadzić adres IP kontrolera jako DNS stacji roboczej, która ma być podłączona do domeny (rysunek 30).

Rysunek 29. Błąd konfiguracji DNS nie pozwala na podłączenie stacji roboczej do domeny Windows (rysunek dotyczy: stacja robocza Windows)

Rysunek 30. Naprawienie błędu DNS poprzez wprowadzenie jako serwera DNS adresu IP kontrolera domeny oraz drugiego publicznego DNS — tutaj przykładowo Google (rysunek dotyczy: dowolny komputer)

Pomyślne dołączenie stacji roboczej z systemem Microsoft Windows 10 do domeny przedstawiono na rysunku 31.

Rysunek 31. Pomyślne przyłączenie stacji roboczej do domeny Windows (rysunek dotyczy: stacja robocza Windows)

Zebranie informacji o środowisku domenowym za pomocą SharpHound

Program zbierający dane o środowisku domenowym — SharpHound jest elementem narzędzia BloodHound. Zbieranie danych o środowisku rozpoczyna się po uruchomieniu SharpHound.exe na jednym z komputerów.

Cały pakiet BloodHound można pobrać (rysunek 32) z adresu:

https://github.com/BloodHoundAD/BloodHound/releases

Po pobraniu i próbie uruchomienia oprogramowania SharpHound (SharpHound.exe lub SharpHound.ps1 w celu uruchomienia w pamięci bez zrzucania pliku .exe na dysk) zostanie zgłoszony monit oprogramowania Microsoft Defender, który w tym eksperymencie można zignorować (rysunek 33).

Rysunek 32. Pobieranie narzędzia BloodHound z witryny GitHub (rysunek dotyczy: stacja robocza Windows lub Windows Server)

Rysunek 33. Program antywirusowy Microsoft Defender wykrył narzędzie hakerskie SharpHound z pakietu BloodHound klasyfikując je jako złośliwe oprogramowanie typu Hack Tool (rysunek dotyczy: stacja robocza Windows lub Windows Server)

Przykładowe polecenie wywołujące SharpHound (rysunek 34) może być następujące:

.\SharpHound.exe –domain blue-umbrella.online

Wszystkie parametry wywołania SharpHound opisane są w dokumentacji. Program można uruchomić na Windows Server, na stacji roboczej Windows podłączonej do domeny, a nawet na stacji roboczej niepodłączonej do domeny (rysunek 26 wcześniej).

Po zakończeniu rekonesansu program SharpHound zakończy swoje działanie komunikatem: Happy Graphing!, a w folderze obok programu pojawi się archiwum ZIP z zebranymi danymi (rysunek 34). Plik ZIP może zostać przeniesiony poza badane środowisko Active Directory w celu analizy na własnym komputerze.

Czerwone zespoły (ang. red team) i inni atakujący będą oczywiście chcieli wyprowadzić dane zebrane w archiwum ZIP niepostrzeżenie.

Rysunek 34. Rozpoczęcie zbierania danych o środowisku domenowym za pomocą narzędzia SharpHound (rysunek dotyczy: stacja robocza Windows lub Windows Server)

Wśród dołączonych do narzędzia SharpHound programów zbierających dane można znaleźć skrypt PowerShell o nazwie SharpHound.ps1, który uruchamia narzędzie SharpHound w pamięci bez zrzucania pliku na dysk komputera (rysunek 35). Ma to na celu uniknięcie wykrycia narzędzia przez systemy antywirusowe i EDR (ang. Endpoint Detection and Response).

Rysunek 35. Uruchomienie SharpHound w pamięci operacyjnej bez zrzucania pliku na dysk komputera (rysunek dotyczy: dowolny komputer)

Dodatkowo linia poleceń SharpHound.exe posiada m.in. parametry takie jak:

• EncryptZip — zabezpieczenie losowym hasłem tworzonego archiwum ZIP,
• RandomizeFilenames — stosowanie losowych nazw dla tworzonych plików,
• Throttle oraz Jitter — stosowanie losowych wartości opóźnień w milisekundach pomiędzy skanowaniem poszczególnych komputerów,
• NoSaveCache — brak tworzenia na dysku pliku podręcznego, aby nie zostać łatwo wykrytym przez oprogramowanie antywirusowe lub EDR.

Wizualizacja danych w formie grafów przy użyciu BloodHound

W celu analizy środowiska Active Directory pod kątem złożonych ścieżek ataku i niebezpiecznych powiązań należy utworzony we wcześniejszym etapie plik archiwum ZIP zaimportować do bazy danych Neo4j przez interfejs graficzny BloodHound.

W celu uruchomienia wizualizatora danych należy zainstalować oprogramowanie obowiązkowe w postaci Oracle JDK oraz bazy danych Neo4j. Oracle JDK w wersji 11 można pobrać ze strony:

https://www.oracle.com/pl/java/technologies/javase/jdk11-archive-downloads.html

Środowisko dla języka Java jest potrzebne, aby uruchomić serwer bazy danych Neo4j. Wersję Community serwera Neo4j można pobrać z witryny:

https://neo4j.com/download-center/#community

Poleceniem:

neo4j.bat console

można uruchomić serwer w oknie wiersza polecenia, wtedy jeśli zamkniemy konsolę, to zatrzyma się też serwer.

Możliwe jest też zainstalowanie serwera Neo4j jako usługi w systemie Windows poleceniem:

neo4j.bat install-service

Uruchomienie serwera Neo4j w wierszu polecenia przedstawiono na rysunku 36. Należy pamiętać, aby serwer był uruchomiony podczas korzystania z BloodHound.

Rysunek 36. Uruchomienie serwera Neo4j z którego bazy danych korzysta BloodHound (rysunek dotyczy: dowolny komputer)

Przy pierwszym uruchomieniu Neo4j należy zmienić hasło. Domyślny login i hasło to neo4j:neo4j (rysunek 37)

W celu zmiany hasła należy otworzyć w przeglądarce internetowej adres http://localhost:7474/ i w formularzu ustawić nowe hasło do bazy danych Neo4j (rysunek 38).

Rysunek 37. Logowanie przez aplikację internetową do serwera Neo4j (rysunek dotyczy: dowolny komputer)

Rysunek 38. Zmiana hasła do serwera Neo4j przez aplikację internetową (rysunek dotyczy: dowolny komputer)

Po tej procedurze możliwe jest zalogowanie się do BloodHound (rysunek 39).

Rysunek 39. Ekran logowania do wizualizatora BloodHound (rysunek dotyczy: dowolny komputer)

Dla pewności należy sprawdzić czy serwer bazy danych Neo4j działa w tle. Dalej można się zalogować do BloodHound i przeciągnąć nad okno programu (rysunek 40) wygenerowany wcześniej przez SharpHound plik archiwum ZIP z danymi.

Rysunek 40. Informacje o obiektach w bazie danych Neo4j prezentowane przez BloodHound (rysunek dotyczy: dowolny komputer)

Początkowa wizualizacja na rysunku 41 prezentuje użytkowników (atrybut MemberOf) grupy Domain Admins. Więcej o grupach możesz przeczytać pod adresem: Active Directory Security Groups | Microsoft Docs.

Użytkownicy, którzy są członkami grupy Domain Admins mogą zarządzać domeną i są domyślnymi właścicielami każdego obiektu tworzonego w Active Directory domeny.

Dodatkowo, grupa Domain Admins kontroluje dostęp do wszystkich kontrolerów w domenie oraz może modyfikować członkostwo wszystkich kont, także tych z prawami administratora w domenie.

Rysunek 41. Zapytanie znajdujące w bazie wszystkich użytkowników należących do grupy Domain Admins (rysunek dotyczy: dowolny komputer)

Oprogramowanie BloodHound posiada wbudowany zestaw gotowych zapytań (tabela 1), które pomogą znaleźć niebezpieczne relacje pomiędzy obiektami w Active Directory i inne wartościowe informacje.

Uwaga: Bez przygotowania zaawansowanego środowiska testowego wiele zapytań może nie zwrócić żadnych wyników. Dlatego uruchomienie i przykład do każdego z zapytań jest poza zakresem tego tekstu.

Tabela 1. Wybrane zapytania programu BloodHound wraz z opisem

Find all Domain Admins	Znajduje wszystkie konta należące do grupy Domain Admins
Find Computers where Domain Users are Local Admin	Znajduje komputery na których konta użytkowników domeny mają prawa lokalnego administratora
Find All Paths from Domain Users to High Value Targets	Znajduje wszystkie ścieżki od kont użytkowników domeny do węzłów oznaczonych na grafie jako cele o wysokiej wartości
Find Workstations where Domain Users can RDP	Znajduje stacje robocze, gdzie konta użytkowników domeny mogą łączyć się przez zdalny pulpit
Find Servers where Domain Users can RDP	Znajduje serwery, gdzie konta użytkowników domeny mogą łączyć się przez zdalny pulpit
Find Dangerous Rights for Domain Users Groups	Znajduje niebezpieczne prawa dostępu dla grup kont użytkowników domeny
Shortest Paths to High Value Targets	Znajduje najkrótszą ścieżkę do węzłów oznaczonych na grafie jako cele o wysokiej wartości
Shortest Paths from Domain Users to High Value Targets	Znajduje najkrótszą ścieżkę z kont użytkowników domeny do węzłów oznaczonych na grafie jako cele o wysokiej wartości
Find Shortest Paths to Domain Admins	Znajduje najkrótsze ścieżki do kont użytkowników z grupy Domain Admins
…	…

Graf przedstawiony przez narzędzie BloodHound składa się z węzłów (ang. node). Klikając prawym przyciskiem myszy możliwe jest wyświetlenie właściwości danego węzła (rysunek 42). Możliwa jest edycja, usunięcie, ustawienie jako początkowy, końcowy, skompromitowany (ang. owned), o wysokiej wartości (ang. high value), a nawet znalezienie najkrótszej ścieżki zmierzającej do tego węzła.

Rysunek 42. Właściwości wybranego węzła grafu — tutaj użytkownik daisy w domenie blue-umbrella.online (rysunek dotyczy: dowolny komputer)

Przykład na rysunku 43 prezentuje grupy posiadające prawa administratora przez wpisanie w pole wyszukiwania:

group:Admin

Pozostałe prefiksy (ang. prepend) są następujące:

• Group
• Domain
• Computer
• User
• OU (pol. jednostka organizacyjna)
• GPO (pol. obiekty zasad grupy)

Ważną wskazówką dla niewtajemniczonych jest, że administratorzy to nie tylko grupa Domain Admins. Grup może być więcej, czego dowodem są rysunki 43 i 44.

Rysunek 43. Okno wyszukiwania w programie BloodHound (rysunek dotyczy: dowolny komputer)

Rysunek 44. Zapytanie wyszukujące użytkowników grupy Enterprise Admins (rysunek dotyczy: dowolny komputer)

W przypadku odtwarzania ścieżki ataku podczas analizy powłamaniowej przydatną opcją okazuje się możliwość oznaczania węzłów jako skompromitowane (ang. owned). Dzięki temu możliwe jest poszukiwanie ścieżek prowadzących zarówno od skompromitowanych maszyn czy kont jak i do skompromitowanych obiektów (rysunek 45).

Rysunek 45. Oznaczenie węzła grafu jako skompromitowany (ang. owned) powoduje dodanie ikony czaszki obok obiektu

Poszczególne węzły grafu mogą posiadać oznaczenie high value, co oznacza obiekt o wysokiej wartości. Chodzi tutaj o wartość dla atakującego, czyli np. użytkownik o wysokich prawach albo posiadający wartościowe dane na swojej maszynie. Niektóre węzły (np. kontroler domeny) są domyślnie oznaczone jako wysokiej wartości. Przykładowe oznaczenie konta jako high value (ikona diamentu) przedstawiono na rysunku 46.

Rysunek 46. Oznaczanie węzłów ikoną diamentu oznaczającą obiekt o wysokiej wartości dla atakującego (rysunek dotyczy: dowolny komputer)

W ramach prostego eksperymentu spróbujmy znaleźć najkrótszą ścieżkę od komputera FINWVIR1000000 oznaczonego na rysunku 45 jako skompromitowany do konta użytkownika DOLORES_GARRISON oznaczonego na rysunku 46 jako obiekt o wysokiej wartości. Opcję uruchamiającą szukanie najkrótszej ścieżki pomiędzy wspomnianymi obiektami przedstawiono na rysunku 47.

Rysunek 47. Opcja menu pozwalająca znaleźć najkrótszą ścieżkę do węzła od obiektu oznaczonego wcześniej jako skompromitowany (rysunek dotyczy: dowolny komputer)

Ścieżka ataku na rysunku 48 od skompromitowanej maszyny FINWVIR1000000 prowadzi przez różne grupy, a atrybut MemberOf informuje, że nie są potrzebne nadużycia (ang. abuse), gdyż komputer jest członkiem tych grup zabezpieczeń. Podążając wzrokiem za ścieżką po pięciokrotnym wystąpieniu atrybutu MemberOf pojawia się atrybut GenericAll oznaczający, że skompromitowana maszyna należąca do tych grup zabezpieczeń ma pełne prawa do konta użytkownika ANTOINE_GILES. Dalej konto to jest członkiem grupy MA-TEQUIEROO-ADMINGROUP1, która ma pełne prawa (GenericAll) do komputera AWSWSECS1000001, który posiada prawa GenericAll do konta użytkownika oznaczonego jako zasób o wysokiej wartości.

Rysunek 48. Najkrótsza ścieżka od skompromitowanej maszyny (ikona czaszki) do konta o wysokiej wartości (ikona diamentu) (rysunek dotyczy: dowolny komputer)

W większości przypadków zarówno czerwone zespoły (ang. red team), jak i pozostali atakujący szukają najkrótszej ścieżki do kont użytkowników z wysokimi uprawnieniami. Przykładowy atak może rozpocząć się od zainfekowania końcowej stacji roboczej użytkownika, a następnie obejmować próby poszerzenia uprawnień (ang. privilege escalation), by dalej najkrótszą ścieżką (rysunek 49) wykonać przemieszczanie się z urządzenia na urządzenie (ang. lateral movement) i dostać się do kontrolera domeny, zapewniając sobie prawa administratora. Z tego powodu narzędzie BloodHound może okazać się bardzo pomocne podczas analizy powłamaniowej w celu odtworzenia potencjalnej ścieżki ataku.

Innym praktycznym przykładem może być oznaczenie konta FREDERIC_MIDDLETON jako skompromitowane i próba znalezienia ścieżki prowadzącej z tego konta do zasobu o wysokiej wartości jakim jest grupa kontrolerów domeny (rysunek 49).

Rysunek 49. Wyznaczanie ścieżki pomiędzy węzłami poprzez pola wyszukiwania (rysunek dotyczy: dowolny komputer)

Możliwe jest nakładanie filtrów na atrybuty w grafie co przedstawiono na rysunku 50. Na przykład zaznaczenie CanRDP podczas wyszukiwania ścieżek uwzględni na grafie obiekty, które mają prawo do łączenia się przez zdalny pulpit. Atakującym pozwala to np. na szukanie wektorów ataku o ustalonych właściwościach.

Rysunek 50. Filtrowanie atrybutów, które mają być uwzględniane przy wyznaczaniu ścieżek (rysunek dotyczy: dowolny komputer)

Program BloodHound pozwala też dodawać węzły, połączenia między nimi, organizować layout, a nawet importować i eksportować graf (rysunek 51).

Rysunek 51. Menu podręczne grafu w programie BloodHound (rysunek dotyczy: dowolny komputer)

Jak widać przedstawione przykłady to tylko wierzchołek góry lodowej, gdyż możliwości narzędzia BloodHound są naprawdę duże. W połączeniu ze skryptem BadBlood można stworzyć środowisko Active Directory do szkolenia niebieskich zespołów (ang. blue team) w wykrywaniu niebezpiecznych powiązań oraz ścieżek ataku.

Na koniec warto pamiętać, aby nie uruchamiać narzędzia BadBlood na produkcyjnych systemach, gdyż może to spowodować utworzenie wielu losowych obiektów i zmiany te będą trudne do odwrócenia.

Kilka słów podsumowania

Wspomniane przykłady jasno obrazują, że powiązania pomiędzy wszelkimi obiektami w środowisku Active Directory powinny być przeglądane i analizowane pod kątem ukrytych niebezpieczeństw. Warto dodać, że witryna CrowdStrike już w 2018 roku opisała etyczne zastosowanie narzędzia BloodHound, które polega na o wiele łatwiejszym wykrywaniu kont użytkowników utworzonych przez atakujących jako tylnych drzwi zapewniających nieautoryzowany dostęp do środowiska Active Directory. Ukryte konta tego typu mogą służyć np. do wyprowadzania cennych danych z przedsiębiorstwa.

Oprogramowanie BloodHound jest też kolejnym idealnym przykładem na to, że wiele narzędzi związanych z cyberbezpieczeństwem może posłużyć zarówno do dobrych, jak i złych celów.

~Dawid Farbaniec

Wykaz literatury

BloodHound: Six Degrees of Domain Admin — BloodHound 3.0.3 documentation | https://bloodhound.readthedocs.io/en/latest/

BloodHound, Software S0521 | MITRE ATT&CK® | https://attack.mitre.org/software/S0521/

Hidden Administrative Accounts: BloodHound to the Rescue (crowdstrike.com) | https://www.crowdstrike.com/blog/hidden-administrative-accounts-bloodhound-to-the-rescue/

GitHub – davidprowe/BadBlood: BadBlood by @davidprowe, Secframe.com | https://github.com/davidprowe/BadBlood

BloodHound – Sniffing Out the Path Through Windows Domains | SANS Institute | https://www.sans.org/blog/bloodhound-sniffing-out-path-through-windows-domains/

BloodHound with Kali Linux: 101 – Red Teaming Experiments (ired.team) | https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-with-bloodhound-on-kali-linux

How to Detect and Block Bloodhound Attacks | CrowdStrike | https://www.crowdstrike.com/blog/how-to-block-bloodhound-attacks/

Active Directory Security Groups — Windows security | https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups