Nadużywanie Kerberosa do zbierania poświadczeń

https://chacker.pl/

Po uruchomieniu serwera WWW w katalogu PowerSharpBinaries, możemy załadować narzędzie Rubeus. Rubeus pozwala nam przeprowadzić rozpoznanie i eksploatację Kerberosa. Jest napisany w języku C#, ale w tym ćwiczeniu wykorzystamy wersję etapową programu PowerShell:

Kerberoasting wykorzystuje sposób, w jaki usługi obsługują bilety Kerberos w AD. Te bilety usług są żądane z serwera przyznającego bilety (TGS) i zawierają informacje o użytkowniku usługi, aby określić, czy użytkownik powinien mieć dostęp do usługi bez konieczności znajomości hasła użytkownika. Ten bilet usługi jest szyfrowany za pomocą poświadczeń właściciela usługi — konta komputera lub konta użytkownika. Każda usługa będzie identyfikowana za pomocą nazwy głównej usługi (SPN) w usłudze Active Directory, którą użytkownik może wyszukać, aby zidentyfikować usługę, a gdy użytkownik zażąda tego biletu, nie musi on komunikować się z usługą docelową. Zamiast tego, jeśli użytkownik wyeksportuje te bilety, można je wymusić w trybie offline za pomocą narzędzia do łamania haseł, zamieniając przykładowe hasło na skrót NTLM, a następnie próbując odszyfrować bilet. Jeśli bilet zostanie odszyfrowany, wiemy, że jest to prawidłowe hasło dla usługi. Ten proces jest znany jako Kerberoasting. Użyjmy Rubeusa do Kerberoastu domeny i wyszukajmy prawidłowe nazwy SPN powiązane z kontami użytkowników, które moglibyśmy wykorzystać w niewłaściwy sposób:

Hasze będą teraz w pliku h.txt i można je skopiować do Kali w celu złamania. Po skopiowaniu haszy możesz spróbować je złamać za pomocą John the Ripper i listy słów na komputerze Kali. Ponieważ te maszyny są lekkie, spróbujmy najpierw z bardzo małą listą słów:

Nie wiadomo, do którego użytkownika to trafia, więc sprawdźmy nasz plik John POT:

Widzimy, że użytkownik passwordadmin ma hasło Passw+ord127. Sprawdzimy to ponownie za chwilę, ale najpierw spróbujmy tego samego z użytkownikami AS-REProasted. AS-REP to wstępne negocjacje uwierzytelniające z serwerem udzielającym biletów, zanim użytkownik otrzyma bilet udzielający biletów (TGT). Po wykonaniu tego wstępnego uwierzytelnienia informacje zostaną zwrócone użytkownikowi zaszyfrowane za pomocą żądanego skrótu NTLM użytkownika, więc można je złamać w podobny sposób:

Plik zostanie zapisany podobnie jak atak Kerberoasting i może zostać skopiowany do skrzynki Kali w celu złamania. Teraz, gdy mamy poświadczenia z Kerberoasting, przeprowadźmy rekonesans i dowiedzmy się więcej o użytkowniku i tym, do czego ma dostęp.

Wyszukiwanie haseł w obiektach użytkownika

https://chacker.pl/

Czasami konta usługowe zawierają hasła w swoim opisie. Ma to na celu to, aby konta, które mogą być używane do wyszukiwania informacji lub innych działań ogólnego przeznaczenia, nie musiały mieć centralnie skoordynowanych poświadczeń. Oczywiście nie jest to najlepsza praktyka, ale nie zmienia to faktu, że zdarza się to częściej niż powinno. Aby znaleźć takie przypadki, załadujemy moduł PowerView i wyszukamy użytkowników z poświadczeniami w opisie ich konta:

BadBlood utworzy losowe konta jako część konfiguracji AD dla tego laboratorium, więc Twoje dane uwierzytelniające mogą wyglądać inaczej i będą miały różne grupy. Niezależnie od różnic, powinno to dać Ci wiele danych uwierzytelniających, które użytkownicy mogą wykorzystać jako ścieżki eskalacji. Jeśli ci użytkownicy nie są wartościowi, istnieją inne sposoby zbierania danych uwierzytelniających. Przyjrzyjmy się Kerberoasting i ASREProasting.

Eskalacja uprawnień Active Directory

https://chacker.pl/

Eskalacja uprawnień AD zawiera trochę sztuki i trochę narzędzi. Część znajdowania ścieżek do Administratora domeny można wykonać za pomocą narzędzi takich jak BloodHound. Niezależnie od tego, jakich narzędzi używasz do znajdowania ścieżek, często będzie musiała nastąpić seria eskalacji. Przyjrzyjmy się kilku sposobom znajdowania poświadczeń do eskalacji.

Używanie SharpUp do eskalacji uprawnień

https://chacker.pl/

Ponieważ ten sam nasłuch jest nadal na miejscu, uruchommy Invoke-SharpUp.ps1, aby zobaczyć, co może znaleźć (zauważ, że używamy tego samego stagera iex/iwr, którego używaliśmy do tej pory):

Widzimy, że usługa „Vulnerable Software” ma modyfikowalny plik binarny usługi. Przyjrzyjmy się plikowi binarnemu z icacls.exe:

To pokazuje, że nie mamy żadnych uprawnień do tego pliku binarnego. Dlaczego więc SharpUp go wyróżnił? Został wyróżniony z powodu niezacytowanej ścieżki usługi. Kiedy system Windows szuka plików binarnych, zaczyna od próby wyszukania pliku binarnego przy każdej przerwie spacji. W tym przypadku będzie szukał c:\Software\Vulnerable.exe, zanim dojdzie do vulnagent.exe. Przyjrzyjmy się uprawnieniom w katalogu C:\Software:

Mamy tutaj możliwość dodawania plików i katalogów, więc możemy spróbować utworzyć vulnerable.exe. Stwórzmy aplikację C#, aby po prostu dodać siebie do lokalnej grupy Administrators. Utworzymy plik vulnerable.cc w c:\programdata, a następnie go skompilujemy. W przypadku zawartości użyj tego podstawowego skryptu C#:

Po zapisaniu pliku jako c:\ProgramData\vulnerable.cc możemy go skompilować za pomocą wbudowanego kompilatora C# w środowisku .NET:

Teraz, gdy wszystko jest już gotowe, spróbujmy ponownie uruchomić tę usługę:

Teraz jesteśmy członkami lokalnej grupy Administratorzy, ale użycie polecenia whoami /groups nie pokaże tego. Aby uzyskać uprawnienia, musimy się wylogować i zalogować ponownie lub rozpocząć nową sesję za pomocą runas lub innej metody. Tak czy inaczej, musimy utworzyć nową powłokę z uprawnieniami Administratora, więc zróbmy to i zbadajmy kilka taktyk eskalacji z Active Directory.

Profilowanie systemów za pomocą winPEAS

https://chacker.pl/

Narzędzie winPEAS (Privilege Escalation Awesome Script) to plik wsadowy lub C#, który tworzy profil systemu Windows i próbuje zidentyfikować luki w zabezpieczeniach, które mogą zostać wykorzystane. Użyjemy wersji PowerShell z repozytorium SharpPack, która została sklonowana do Kali. Za pomocą tego samego odbiornika HTTP, który został skonfigurowany w poprzednich laboratoriach, załadujemy skrypt InvokewinPEAS.ps1, a następnie sprawdzimy niektóre z naszych opcji:

Możemy zobaczyć wiele informacji o systemie, a także kilka exploitów, które mogą się przydać do eskalacji uprawnień. Większość z nich wymaga pobrania dodatkowych plików binarnych do systemu, co może oznaczać AV lub EDR. Skrypt dostarczył nam jednak niektórych dodatkowych informacji, które uzyskaliśmy od Seatbelt, więc byłaby to realna alternatywa dla zbierania danych. WinPEAS nie wykrył jednak żadnej z podatnych ścieżek przez usługę, a to jest jedna z mocnych stron SharpUp, więc przyjrzyjmy się temu.

Używanie PowerView do AD Recon

https://chacker.pl/

Chociaż PowerSploit ma wiele modułów, które są przydatne do późniejszej eksploatacji, skupimy się na module PowerView w podkatalogu Recon. Z naszego pola Kali uruchommy serwer WWW w katalogu PowerSploit:

Następnie na naszym serwerze docelowym załadujmy moduł PowerView. Możemy to zrobić za pomocą stagera iex/iwr:

Następnie wypróbujmy niektóre z funkcji, które omówiliśmy wcześniej. Najpierw zdobądźmy informacje o naszej domenie:

To te same informacje, które widzieliśmy wcześniej, ale są o wiele prostsze. Ponadto możemy uzyskać listę OU, jak poprzednio:

Aby uzyskać listę kontroli dostępu (ACL) dla jednostki organizacyjnej administratora, możemy użyć polecenia cmdlet Get-DomainObjectAcl:

Niestety, SID użytkownika nie jest rozwiązany, a uprawnienia są nadal w formie GUID, podobnie jak w metodzie ADSI z wcześniejszego artykułu. PowerView może pomóc nam je przekonwertować, aby wyjaśnić dostęp każdego użytkownika. Użyjmy polecenia cmdlet ConvertFrom-SID i opcji -ResolveGuids do Get-DomainObjectAcl, aby to uporządkować:

Dzięki temu odczyt danych jest znacznie łatwiejszy. Ponadto możemy użyć PowerView do wyszukania użytkowników, którzy mają uprawnienia DCSync, pobierając ACL dla tych, którzy mają albo uprawnienia All privileges albo uprawnienia replication w DN domeny:

Teraz wiemy, których użytkowników należy wybrać, aby przeprowadzić atak DCSync. To tylko kilka elementów, których można szukać.  Możemy użyć tych informacji, aby taktycznie znaleźć informacje, których potrzebujemy w domenie, bez wydawania ogromnej liczby zapytań, ale jednym z ulubionych narzędzi jest BloodHound. BloodHound zbierze mnóstwo informacji AD, a następnie pozwoli przeszukać dane w przeglądarce baz danych grafów o nazwie Neo4j. Wadą tego jest to, że wydaje ogromne ilości zapytań, a bardziej dojrzałe organizacje szukają ich, aby zidentyfikować złośliwe intencje, więc nie jest to szczególnie bezpieczne pod kątem bezpieczeństwa operacyjnego.

Uzyskiwanie informacji o domenie za pomocą programu PowerShell

https://chacker.pl/

Musimy znać podstawy domeny. Część z nich poznaliśmy wcześniej w tym rozdziale, omawiając profilowanie użytkownika i komputera. Chociaż moduł ActiveDirectory PowerShell może być pomocny, często nie jest instalowany, więc przyjrzyjmy się, jak to zrobić, korzystając z interfejsów API usługi Active Directory w programie PowerShell. Te interfejsy API są dostępne we wszystkich systemach Windows i nie wymagają instalowania dodatkowych modułów, które mogłyby nas zdradzić. Na początek przyjrzyjmy się informacjom o domenie:

Tutaj możemy zobaczyć kilka krytycznych danych. Nazwa domeny to ghh.local, a jeden kontroler domeny (DC) jest również wymieniony, EC2AMAZTBKC0DJ. ghh.local. DomainModeLevel wynosi 7, co odpowiada poziomowi funkcjonalnemu systemu Windows 2016. Poziom funkcjonalny jest ważny, ponieważ funkcje bezpieczeństwa mogą działać inaczej na różnych poziomach funkcjonalnych. Następnie weźmy informacje, które uzyskaliśmy z polecenia whoami /user i sprawdźmy, jakie informacje o naszym użytkowniku znajdują się w AD:

Na podstawie tych wyników możemy zobaczyć grupy, do których należy nasz użytkownik, a także obiekty, którymi zarządza. Da nam to dodatkowy wgląd w typy rzeczy, do których użytkownik otrzymał uprawnienia na podstawie członkostwa w grupie, a zarządzane przez niego obiekty pomagają zidentyfikować dostęp, jaki może zapewnić innym kontom. Mając podstawową wiedzę o naszym użytkowniku i właściwościach domeny, przyjrzyjmy się bliżej układowi, uzyskując listę jednostek organizacyjnych (OU), które tworzą AD. Są one często opisowe i pomogą nam zrozumieć, gdzie szukać interesujących obiektów.

Stąd widzimy wbudowaną jednostkę organizacyjną kontrolerów domeny, ale widzimy również szereg jednostek organizacyjnych administratora i zagnieżdżonych jednostek organizacyjnych pod nimi. To są rzeczy, które zazwyczaj chcielibyśmy lepiej zrozumieć. Przyjrzyjmy się korzeniowi jednostek organizacyjnych administratora za pomocą programu PowerShell.

Widzimy, że oprócz Domain Admins i SYSTEM, grupa SC-266-distlist ma również prawa do tej grupy. Więc jeśli znajdziemy użytkownika w tej grupie, możemy użyć tego użytkownika do manipulowania obiektami w tej OU. Zobaczmy, kto jest w tej grupie:

UWAGA Ponieważ informacje dla każdego wdrożenia AD zostały losowo zmanipulowane przez BadBlood, Twoje grupy, użytkownicy i członkostwo mogą się różnić.

Zaczynamy od użycia System.DirectoryServices, aby uzyskać domenę (1), w której obecnie się znajdujemy. Musimy utworzyć obiekt DirectorySearcher (2), aby przeszukać Active Directory. Ten obiekt ma wszystkie metody, których będziemy potrzebować do wykonania naszego wyszukiwania. Następnie musimy wygenerować wyszukiwanie Lightweight Directory Access Protocol (LDAP), które będzie zawierało nasze informacje. Wyszukiwanie (3) używa operatora &, aby połączyć dwa różne terminy wyszukiwania: typ obiektu i nazwę wspólną (CN) obiektu, którego szukamy. Na koniec, po uzyskaniu elementu, którego szukamy, możemy przejrzeć właściwości (4) tego elementu, aby uzyskać członków grupy. Pomoże nam to w określeniu, kogo szukać później w celu eskalacji. Chociaż wykonywanie wszystkich tych zapytań bez użycia dodatkowych modułów jest przydatną umiejętnością, moduł PowerView w PowerSploit ma pomocnicze polecenia cmdlet, które mogą znacznie to ułatwić. Ponadto moduł PowerView ma dodatkowe polecenia cmdlet, które wyszukują luki w zabezpieczeniach.

UWAGA PowerSploit nie jest już utrzymywany, ale wielu testerów nadal go używa. Gdy aspekty modułów przestaną działać, prawdopodobnie nie zostaną naprawione, ale nie wszystkie funkcje modułów w PowerSploit zostały w pełni zintegrowane w porównywalnym module.

Rozpoznanie domeny

https://chacker.pl/

Prawie wszystkie systemy, które są częścią środowiska przedsiębiorstwa, będą częścią usługi Active Directory (AD). AD to usługa katalogowa, która śledzi użytkowników, grupy, komputery, zasady, witryny, struktury organizacyjne i wiele innych. Każdy obiekt ma atrybuty i informacje o zabezpieczeniach, które definiują obiekt i kto może z nim wchodzić w interakcje. Ten katalog jest podstawą domen AD (grupowania tych obiektów przechowywane na zestawie serwerów) i lasów (wiele domen, które mają między sobą relacje interoperacyjności i zaufania).

WSKAZÓWKA Active Directory (AD) ma wiele komponentów i może być trudne do zrozumienia. Jeśli nie znasz AD, Microsoft ma dobry odnośnik, który pomoże Ci zacząć: https://docs.microsoft.com/en-us/windowsserver/identity/ad-ds/get-started/virtual-dc/active- directory-domainservices- overview. Gdy już zapoznasz się z podstawami, wróć, a zagłębimy się w to, jak wchodzić w interakcję z AD za pomocą programu PowerShell i innych narzędzi.

Gdy wchodzimy do środowiska, musimy wiedzieć kilka ważnych rzeczy. Musimy wiedzieć, kim jesteśmy w środowisku i jakie są nasze grupy. Musimy również wiedzieć, kim są administratorzy. Możemy chcieć wiedzieć, jak duże jest środowisko, czy jest podzielone na witryny i jak wygląda struktura organizacyjna. Na koniec możemy chcieć wiedzieć, jakie obiekty zasad grupy (GPO) istnieją i gdzie są połączone. Te elementy pozwolą nam lepiej zrozumieć, jak skonfigurowana jest domena AD i gdzie powinniśmy szukać opcji eskalacji i trwałości.

System Recon z Seatbelt

https://chacker.pl/

Seatbelt może również zbierać informacje o opcjach konfiguracji hosta. Kwestie, które nas często interesują, to niektóre z tych, które zostały omówione wcześniej, takie jak konfiguracje programu PowerShell, status AMSI, informacje o systemie operacyjnym i konfiguracja. Chcemy jednak również wiedzieć, jakie kontrolki obronne są włączone, jakie interesujące procesy są uruchomione, jakie sesje logowania są obecne, abyśmy wiedzieli, czy nie jesteśmy sami w systemie, oraz inne obszary, które Seatbelt określa jako mogące zawierać interesujące dane. Wcześniej uruchomiliśmy grupę poleceń użytkownika. Tym razem uruchomimy grupę poleceń systemowych:

Widzimy tutaj wiele danych o stanie systemu, z których część widzieliśmy już bez Seatbelt. Jednak Seatbelt dostarcza te informacje w jednym miejscu, zamiast wymagać od nas zagłębiania się w różne miejsca za pomocą programu PowerShell. Możemy również przyjrzeć się konkretnym elementom. Jednym z aspektów, który jest pomocny w poznaniu systemu, jest to, czy UserAccountControl (UAC) jest włączony i jakie są jego ustawienia. Pomoże nam to określić, czy uprzywilejowani użytkownicy wymagają dodatkowych obejść w celu wykonania kodu, takich jak dodawanie usług lub użytkowników lub eskalacja do systemu:

Widzimy, że UAC jest włączony. Jeśli ktoś spróbuje uruchomić plik binarny inny niż Windows, system Windows poprosi użytkownika o zezwolenie na uruchomienie pliku binarnego. Gdybyśmy używali kanału C2 do dostępu do tego systemu, nie bylibyśmy w stanie zobaczyć tych monitów. To mówi nam, że musimy znaleźć sposób na eskalację uprawnień, aby uniknąć monitowania. Teraz, gdy mamy pewne zrozumienie tego, czym jest postawa hosta, przyjrzyjmy się, aby określić, gdzie jesteśmy w usłudze Active Directory.

Rozpoznanie systemu za pomocą programu PowerShell

https://chacker.pl/

Pierwszą rzeczą, którą chcemy sprawdzić, jest to, czy włączony jest moduł AMSI. Będzie to dobry wskaźnik tego, czy możemy używać dodatkowych narzędzi w pamięci bez ich zauważenia. Z poziomu wiersza poleceń programu PowerShell jako nasz użytkownik docelowy wydajemy następujące polecenia:

Pierwszy wiersz używa polecenia cmdlet Get-ChildItem, aby uzyskać dostawców z listy rejestru dostawców AMSI. Zawiera ona listę identyfikatorów klas (CLSID), które zarejestrowały się jako dostawcy AMSI. Kiedy sprawdzamy identyfikatory CLSID w rejestrze CLSID klas, widzimy, że identyfikator CLSID kończący się na 7AFE jest dostawcą dla programu Windows Defender. Poprzez zapytanie o identyfikatory CLSID, które zarejestrowały się jako dostawcy AMSI, możemy stwierdzić, czy cokolwiek korzysta z AMSI. Ponieważ otrzymujemy wynik (w tym przypadku program Windows Defender), oznacza to, że AMSI jest włączone. Następnie sprawdźmy, jakie zasady mogą być wdrożone. Zasady takie jak ScriptBlockLogging, która rejestruje zawartość uruchamianych przez nas poleceń, ModuleLogging, która rejestruje moduły ładowane przez program PowerShell, i TranscriptionLogging, która rejestruje wszystko, co dzieje się w sesji, oraz ciągi wyjściowe do pliku mogą zdradzić naszą obecność. Sprawdzając je, możemy od razu zobaczyć, co jest bezpieczne do uruchomienia, a co wymaga skonfigurowania obejść:

Gdy uruchamiamy polecenie, nie otrzymujemy żadnych informacji zwrotnych. To dobry znak, że nie ma żadnych specjalnych ustawień rejestrowania i że używane są domyślne opcje. Gdyby klucze rejestru istniały w tej lokalizacji, musielibyśmy ustalić, które z nich zostały ustawione, ale najbezpieczniejszą rzeczą do zrobienia w tym momencie byłby atak downgrade przy użyciu programu PowerShell 2.0 lub technika obejścia. Aby ustalić, czy możemy downgrade, sprawdźmy, jakie wersje programu PowerShell są zainstalowane:

Gdy uruchamiamy polecenie, nie otrzymujemy żadnych informacji zwrotnych. To dobry znak, że nie ma żadnych specjalnych ustawień rejestrowania i że używane są domyślne opcje. Gdyby klucze rejestru istniały w tej lokalizacji, musielibyśmy ustalić, które z nich zostały ustawione, ale najbezpieczniejszą rzeczą do zrobienia w tym momencie byłby atak downgrade przy użyciu programu PowerShell 2.0 lub technika obejścia. Aby ustalić, czy możemy downgrade, sprawdźmy, jakie wersje programu PowerShell są zainstalowane:

Widzimy, że jedyną lokalizacją, która ma prawidłowy system.dll do załadowania, co oznacza, że ​​jest to jedyna pełna instalacja, jest v4 frameworka. Oznacza to, że nie możemy obniżyć wersji do 2.0, aby pominąć rejestrowanie. Gdyby rejestrowanie było włączone, musielibyśmy użyć techniki obejścia, aby je wyłączyć. Teraz, gdy wiemy, że dodatkowe rozpoznanie nie wywoła wykrywania opartego na rejestrowaniu, przyjrzyjmy się niektórym podstawowym informacjom o systemie operacyjnym. Aby wyświetlić informacje o samym komputerze, możemy użyć polecenia cmdlet Get-ComputerInfo. Zawiera ono wiele danych, ale najpierw przyjrzyjmy się informacjom o systemie Windows:

Pokazuje nam to, że używamy trybu Windows 2016 Datacenter i jesteśmy zarejestrowani w Amazon EC2. Mamy również datę instalacji systemu i lokalizację katalogu Windows. Daje nam to trochę świadomości sytuacyjnej, ponieważ wiemy, że jesteśmy w chmurze, a nie w lokalizacji lokalnej. Kolejną rzeczą, którą będziemy chcieli sprawdzić, jest to, czy DeviceGuard jest włączony. DeviceGuard to funkcja systemu Windows, która pomaga zapobiegać złośliwemu oprogramowaniu, zapewniając, że tylko znany dobry kod może być uruchamiany w systemie. Oznacza to, że każdy kod, który wykonamy, będzie musiał być binarnymi plikami Living-Off-The-Land (LOLBins). Na szczęście polecenie cmdlet Get-ComputerInfo może nam ponownie pomóc:

Widzimy, że DeviceGuard jest wyłączony, więc jeśli możemy ominąć AV, powinniśmy być w stanie uruchomić binaria nienatywne w systemie. Teraz, gdy mamy pewną świadomość tego, co możemy, a czego nie możemy zrobić, zdobądźmy więcej informacji o Seatbelt.