Aby przechwycić hasze, musimy użyć programu, który zachęci ofiarę do podania haszy NetNTLM. Aby uzyskać te hasze, użyjemy Respondera, aby odpowiedzieć na zapytania LLMNR i NBNS. Użyjemy stałego wyzwania po stronie serwera, więc będziemy musieli poradzić sobie tylko z jednym zestawem losowości zamiast dwóch.
Gdy hosty Windows komunikują się między sobą, istnieje wiele sposobów uwierzytelniania systemów, takich jak Kerberos, certyfikaty i NetNTLM. Pierwszym protokołem, na którym się skupimy, jest NetNTLM. Jak sama nazwa wskazuje, NetNTLM zapewnia bezpieczniejszy sposób wysyłania skrótów Windows NT LAN Manager (NTLM) przez sieć. Przed systemem Windows NT skróty LAN Manager (LM) były używane do uwierzytelniania opartego na sieci. Skrót LM był generowany przy użyciu szyfrowania Data Encryption Standard (DES). Jedną ze słabości skrótu LM było to, że w rzeczywistości były to dwa oddzielne skróty połączone razem. Hasło było konwertowane na wielkie litery i uzupełniane znakami null, aż osiągnęło 14 znaków, a następnie pierwsza i druga połowa hasła były używane do utworzenia dwóch części skrótu. Wraz z rozwojem technologii stało się to większym problemem, ponieważ każdą połowę hasła można było złamać osobno, co oznaczało, że łamacz haseł musiałby złamać co najwyżej dwa siedmioznakowe hasła. Wraz z pojawieniem się tablic tęczowych łamanie haseł stało się jeszcze łatwiejsze, więc system Windows NT przeszedł na używanie skrótów NT LAN Manager (NTLM). Hasła dowolnej długości można było haszować, a do generowania skrótu użyto algorytmu RC4. Jest to znacznie bezpieczniejsze w przypadku uwierzytelniania opartego na hoście, ale istnieje problem z uwierzytelnianiem opartym na sieci. Jeśli ktoś podsłuchuje, a my po prostu przesyłamy surowe skróty NTLM, co powstrzymuje tę osobę przed przechwyceniem skrótu i jego odtworzeniem? W rezultacie skróty wyzwania/odpowiedzi NetNTLMv1 i NetNTLMv2 zostały stworzone, aby nadać skrótom dodatkową losowość i spowolnić ich łamanie. NTLMv1 używa opartego na serwerze nonce’a, aby zwiększyć losowość. Kiedy łączymy się z hostem za pomocą NTLMv1, najpierw prosimy o nonce’a. Następnie żądający klient bierze nasz hash NTLM i ponownie go hashuje tym noncem. Następnie wysyłamy to wyzwanie klienta do serwera w celu uwierzytelnienia. Jeśli serwer zna hash NT, może ponownie utworzyć hash wyzwania przy użyciu wysłanego wyzwania. Jeśli oba są zgodne, hasło jest poprawne i serwer może kontynuować działanie. Problem z tym protokołem polega na tym, że złośliwy atakujący może oszukać kogoś, aby połączył się z jego serwerem i podał statyczny nonce. Oznacza to, że hash NTLMv1 jest tylko trochę bardziej złożony niż surowe poświadczenia NTLM i można go złamać niemal tak szybko, jak surowy hash NTLM. Dlatego stworzono NTLMv2. NTLMv2 dostarcza dwa różne nonce w tworzeniu hasha wyzwania. Pierwszy jest określony przez serwer, a drugi przez klienta. W ten sposób, nawet jeśli serwer jest naruszony i ma statyczny nonce, nonce klienta nadal dodaje złożoności, aby zapewnić, że te poświadczenia zostaną złamane wolniej. Oznacza to również, że używanie tablic tęczowych nie jest już skutecznym sposobem łamania tego typu haszy.
Kiedy wyszukujemy nazwę DNS, systemy Windows przechodzą przez szereg różnych kroków, aby rozwiązać tę nazwę na adres IP dla nas. Pierwszy krok obejmuje przeszukiwanie plików lokalnych. System Windows przeszuka plik Hosts lub LMHOSTS w systemie, aby sprawdzić, czy w tym pliku znajduje się wpis. Jeśli nie, następnym krokiem jest zapytanie do DNS. System Windows wyśle zapytanie DNS do domyślnego serwera nazw, aby sprawdzić, czy może znaleźć wpis. W większości przypadków zwróci to odpowiedź, a my zobaczymy stronę internetową lub host docelowy, z którym próbujemy się połączyć. W sytuacjach, w których DNS zawodzi, nowoczesne systemy Windows używają dwóch protokołów, aby spróbować rozwiązać nazwę hosta w sieci lokalnej. Pierwszym z nich jest Link Local Multicast Name Resolution (LLMNR). Jak sama nazwa wskazuje, protokół ten używa multicastu, aby spróbować znaleźć hosta w sieci. Inne systemy Windows będą subskrybować ten adres multicastu. Kiedy host wysyła żądanie, każdy nasłuchujący host, który jest właścicielem tej nazwy i może ją przekształcić w adres IP, wygeneruje odpowiedź. Gdy żądający host otrzyma odpowiedź, system prześle nas do odpowiadającego hosta. Jednak jeśli system Windows nie może znaleźć hosta za pomocą LLMNR, istnieje dodatkowy sposób na znalezienie hosta. System Windows używa usługi NetBIOS Name Service (NBNS) i protokołu NetBIOS, aby spróbować odkryć adres IP. Robi to, wysyłając żądanie rozgłoszeniowe dla hosta do lokalnej podsieci, a następnie czeka, aż ktoś odpowie na to żądanie. Jeśli istnieje host o tej nazwie, może odpowiedzieć bezpośrednio. Wtedy nasz system wie, że aby dostać się do tego zasobu, musi udać się do tej lokalizacji. Zarówno LLMNR, jak i NBNS opierają się na zaufaniu. W normalnym środowisku host odpowie na te protokoły tylko wtedy, gdy jest hostem, którego się szuka. Jednak jako złośliwy aktor możemy odpowiedzieć na każde żądanie wysłane do LLMNR lub NBNS i powiedzieć, że host, którego się szuka, jest naszą własnością. Następnie, gdy system przejdzie do tego adresu, spróbuje wynegocjować połączenie z naszym hostem, a my możemy uzyskać informacje o koncie, które próbuje się z nami połączyć.
Kiedy przyglądamy się sposobom uzyskiwania dostępu do systemów, które nie obejmują exploitów, jednym z pierwszych wyzwań, jakie musimy pokonać, jest sposób uzyskania poświadczeń do jednego z tych systemów docelowych. W tym rozdziale skupimy się na naszym docelowym systemie Windows 2016, więc najpierw musisz wiedzieć, jakie skróty możemy przechwycić, a po drugie, musisz wiedzieć, jak możemy wykorzystać te skróty na naszą korzyść
Jedną z kluczowych zasad testów penetracyjnych jest ukrycie. Im szybciej zostaniemy zauważeni w sieci, tym szybciej osoby reagujące mogą powstrzymać nas przed postępem. W rezultacie korzystanie z narzędzi, które wydają się naturalne w sieci i korzystanie z narzędzi, które nie generują żadnego zauważalnego wpływu na użytkowników, jest jednym ze sposobów, w jaki możemy pozostać niezauważeni. Przyjrzymy się kilku sposobom uzyskiwania dostępu i poruszania się w środowisku, korzystając z narzędzi natywnych dla systemów docelowych.
PowerShell jest jednym z najpotężniejszych narzędzi w systemie Windows. W tym rozdziale przyjrzeliśmy się różnym ograniczeniom bezpieczeństwa dotyczącym uruchamiania skryptów PowerShell. Przyjrzeliśmy się również, jak ominąć te ograniczenia, stosując różne techniki. Po ominięciu tych ograniczeń otwierają się drzwi do korzystania z innych struktur, takich jak PowerSploit i PowerShell Empire. Narzędzia te umożliwiają uzyskanie dodatkowego dostępu do systemów, utrzymanie trwałości i eksfiltrację danych. Korzystając z tych technik, możesz „żyć z ziemi”, co oznacza, że używasz tylko tego, co już znajduje się w systemie docelowym. Nie są wymagane żadne dodatkowe pliki binarne. Ponieważ niektóre skrypty mogą zostać przechwycone przez oprogramowanie antywirusowe, przyjrzeliśmy się również sposobom obejścia AMSI w celu uzyskania wykonania kodu. Na koniec będziesz mieć agentów, którzy utrzymują trwałość po ponownym uruchomieniu, a także szereg narzędzi do utrzymania dostępu do systemów docelowych podczas gromadzenia i eksfiltracji danych.
Windows Remote Management (WinRM) to protokół zdalnego zarządzania, który umożliwia nam wykonywanie programu PowerShell. W rozdziale 16 przyjrzymy się bliżej niektórym rzeczom, które możemy z nim zrobić, ale w tym ćwiczeniu wystarczy wiedzieć, że po uruchomieniu zwykle będzie on działał w kontekście wysokiej integralności, co oznacza, że jest już podniesiony. Zbadajmy, jak sprawdzić, jaki jest poziom integralności powłoki. Najpierw w programie PowerShell na komputerze z systemem Windows użyjmy whoami, aby sprawdzić nasze uprawnienia:
Etykieta informuje, jaki jest poziom Mandatory Integrity Control (MIC). Średni pozwala na uruchamianie wielu zadań, ale nie funkcji administracyjnych. Wysoki poziom integralności pozwala na wykonywanie zadań administracyjnych. Połączmy się z hostem z naszego pudełka Kali Lab za pomocą evil-winrm, aby sprawdzić, jaki jest nasz poziom. Najpierw otwórz nowe połączenie z Kali w laboratorium i uruchom evil-winrm:
Widzimy, że połączenie WinRM, nawet z tymi samymi poświadczeniami, ma zastosowany poziom High Integrity. Wyjdźmy z powłoki, wpisując exit i zbudujmy pojedynczy plik do użycia w fazie przygotowawczej z naszym serwerem internetowym. Użyj swojego ulubionego edytora i dodaj następujący kod do nowego pliku o nazwie stage.txt:
Połącz się ponownie z Evil-WinRM i wywołaj skrypt zdalnie:
Polecenie powinno zostać zawieszone, a my powinniśmy zobaczyć nowe połączenie w Empire:
Mamy teraz nowego agenta, który powinien mieć podwyższone uprawnienia. Możemy sprawdzić, czy mamy podniesioną powłokę, wpisując agents i szukając gwiazdki (*) przy użytkowniku, która wskazuje podwyższone uprawnienia. Zauważamy również, że na Rysunku
proces nie jest wymieniony jako „powershell”, ale jako „wsmprovhost”, który jest procesem, pod którym działa WinRM. Możemy również zobaczyć, jakie inne poświadczenia mogą znajdować się w pamięci, używając Mimikatz. Aby to zrobić, możemy uruchomić polecenie usemodule, aby załadować polecenie mimikatz logonpasswords, a następnie wykonać je w kontekście naszego agenta:
UWAGA Uruchomienie Mimikatz może spowodować zniknięcie powłoki. Jeśli nie otrzymasz informacji, pamiętaj, aby wpisać polecenie agenta, aby sprawdzić, czy agent nadal działa. Jeśli nie, wróć i ponownie uruchom krok Evil-WinRM, aby uzyskać nową powłokę, aby wykonać resztę laboratorium. Możesz również nie widzieć poświadczeń w postaci zwykłego tekstu; jeśli tak jest, zaloguj się ponownie do systemu za pomocą protokołu RDP i spróbuj ponownie. Tutaj widzimy, że mamy hasło użytkownika docelowego w postaci zwykłego tekstu, a także skrót NTLM dla użytkownika. Jeśli zalogowani byli inni użytkownicy, może to być dodatkowy sposób na zebranie poświadczeń, ale ponieważ mamy już poświadczenia dla tego użytkownika, możemy po prostu dodać trwałość, więc jeśli poświadczenia się zmienią, będziemy mogli wrócić. Aby to zrobić, musimy po prostu użyć modułu trwałości i go wykonać:
UWAGA Uruchomienie Mimikatz może spowodować zniknięcie powłoki. Jeśli nie otrzymasz informacji, pamiętaj, aby wpisać polecenie agenta, aby sprawdzić, czy agent nadal działa. Jeśli nie, wróć i ponownie uruchom krok Evil-WinRM, aby uzyskać nową powłokę, aby wykonać resztę laboratorium. Możesz również nie widzieć poświadczeń w postaci zwykłego tekstu; jeśli tak jest, zaloguj się ponownie do systemu za pomocą protokołu RDP i spróbuj ponownie. Tutaj widzimy, że mamy hasło użytkownika docelowego w postaci zwykłego tekstu, a także skrót NTLM dla użytkownika. Jeśli zalogowani byli inni użytkownicy, może to być dodatkowy sposób na zebranie poświadczeń, ale ponieważ mamy już poświadczenia dla tego użytkownika, możemy po prostu dodać trwałość, więc jeśli poświadczenia się zmienią, będziemy mogli wrócić. Aby to zrobić, musimy po prostu użyć modułu trwałości i go wykonać:
Upewnij się, że Empire nadal działa na komputerze Kali w laboratorium. W tym laboratorium wdrażamy naszego agenta, a następnie pracujemy nad eskalacją i całkowitym naruszeniem bezpieczeństwa systemu. Plik /tmp/launcher.bat będzie musiał zostać przeniesiony do naszego systemu Windows, więc jeśli serwer internetowy Python nadal działa, wystarczy, że skopiujemy go do naszego katalogu domowego. W nowym oknie SSH wpisujemy:
Następnie spróbujmy pobrać i uruchomić plik na docelowym systemie Windows w laboratorium. Aby to zrobić, możemy użyć polecenia iwr programu PowerShell:
Gdy wylistujesz katalog launcher.bat, możesz nie zobaczyć pliku, ponieważ program antywirusowy już go usunął. Nie panikuj. To normalne. Nasz plik został pomyślnie pobrany, ale nie działał prawidłowo, ponieważ został wykryty jako wirus, gdy AMSI sprawdził kod. Aby to obejść, możemy użyć obejścia AMSI i po prostu załadować sam skrypt. Zacznijmy od zmodyfikowania pliku bat na komputerze Kali, tak aby zawierał tylko ciąg Base64, usuwając wszystko do ciągu Base64:
Ten kod pobierze ciąg Base64 z pliku i zapisze go w pliku o nazwie dropper. Kod szuka wiersza programu PowerShell zawierającego enc, zamienia spacje na nowe wiersze, a następnie znajduje duży ciąg. To zadziała, nawet jeśli Empire nieznacznie zmieni konwencje wywołań. Teraz mamy plik o nazwie dropper w naszym katalogu domowym, który możemy wywołać z serwera WWW z naszego komputera z systemem Windows.
Najpierw ładujemy nasz skrypt obejścia AMSI i widzimy, że kończy się on pomyślnie. Ładujemy ciąg Base64 z serwera do zmiennej „$a”, a następnie konwertujemy go z Base64 za pomocą FromBase64String. Nadal musimy przekonwertować to wyjście na ciąg, więc Unicode.GetString konwertuje zmienną „$b” z naszym zdekodowanym ciągiem na ciąg, który iex może wykonać. To polecenie powinno się zawiesić i powinniśmy zobaczyć wyjście na naszym polu Kali w Empire.
Gdy nasz agent jest aktywny, następnym krokiem jest interakcja z tym agentem, jak pokazano poniżej. Należy pamiętać, że agenci są określani według nazwy, a Twoja może być inna. W naszym przypadku używamy CDE5236G.
Teraz, gdy wchodzimy w interakcję z naszym agentem, musimy ominąć środowisko User Account Control (UAC), aby uzyskać podniesioną powłokę do uruchomienia Mimikatz. Aby to zrobić, uruchamiamy polecenie bypassuac, które powinno utworzyć nową podniesioną powłokę, z którą będziemy mogli pracować:
Widzimy, że zadanie zostało uruchomione, ale nie otrzymaliśmy dodatkowej powłoki. Co więcej, jeśli spojrzymy na nasz komputer z systemem Windows, zostaliśmy wyrzuceni z programu PowerShell. Aktywności modułu bypassuac zostały uznane za złośliwe, więc program PowerShell został zamknięty, a teraz nasz agent również został zakończony. Na rysunku możemy zobaczyć, że agent przestał się meldować (czas jest czerwony na wyświetlaczu). W momencie pisania tej książki nie ma exploita obejścia UAC, który działałby dobrze w systemie Windows 2019 w Empire, więc będziemy musieli znaleźć inny sposób.
Po skonfigurowaniu Empire musimy utworzyć program nasłuchujący, a następnie program nasłuchujący. Program nasłuchujący umożliwia nam uruchomienie naszego C2 w systemie docelowym. Program nasłuchujący odbiera komunikaty z zainfekowanych systemów. Konfigurujemy określone programy nasłuchujące dla określonych protokołów komunikacji. W naszym przykładzie użyjemy programu nasłuchującego opartego na protokole HTTP, aby po połączeniu się z nami program C2 wyglądał jak ruch sieciowy. Pierwszym krokiem jest skonfigurowanie programu nasłuchującego. Aby to zrobić, przechodzimy do menu programów nasłuchujących i wybieramy program nasłuchujący HTTP. Następnie włączamy podstawowe ustawienia i uruchamiamy program nasłuchujący, tak jak poniżej:
Teraz, gdy nasz listener jest uruchomiony, następnym krokiem jest utworzenie pliku bootstrap. Aby to zrobić, wracamy do menu głównego i wybieramy stager, jak pokazano tutaj:
Wybieramy moduł windows/launcher_bat dla naszego stagera. Spowoduje to, że otrzymamy polecenie PowerShell, które możemy skopiować i wkleić w systemie docelowym, aby uruchomić nasz C2. Określamy nasłuchiwacza, z którym chcemy się połączyć, i na koniec generujemy plik
Oryginalny PowerShell Empire został porzucony, ale BC Security przejął projekt, przeniósł go do Pythona 3 i nadal wprowadza aktualizacje. Jest to wersja, która jest teraz dołączona do Kali. Ponieważ będziemy chcieli użyć portów 80 i 443, musimy upewnić się, że inne usługi nie działają na tych portach, a następnie uruchomić PowerShell Empire za pomocą sudo.
Ten przykład pokazuje, że nginx działa. Aby to zatrzymać, wykonujemy następujące czynności (Twój system może mieć inny status w zależności od Twojej pozycji w laboratoriach):
Widzimy, że nginx jest teraz zatrzymany, więc możemy uruchomić Empire. Aby to zrobić, po prostu uruchamiamy binarny plik powershell-empire za pomocą sudo:
Po uruchomieniu Empire zobaczymy jego system menu i możemy wpisać help, aby zobaczyć opcje rozpoczęcia.