Winexe to narzędzie do zdalnej administracji dla systemów Windows, które działa w systemie Linux. Za pomocą Winexe możemy uruchamiać aplikacje w systemie docelowym lub otwierać interaktywny wiersz poleceń. Jedną dodatkową korzyścią jest to, że możemy poprosić Winexe o uruchomienie naszej powłoki jako „system”, jeśli naszym celem jest system, w którym nasz użytkownik ma podwyższone poświadczenia, co daje nam dodatkowe uprawnienia do systemu.
Teraz, gdy znasz już podstawy, wykorzystajmy Twoją wiedzę w praktyce. W naszej sieci laboratoryjnej mamy komputer docelowy z systemem Windows Server 2016 i pudełko Kali. Najpierw łączymy się przez SSH z systemem Kali. Następnie przechodzimy do katalogu Responder. Stajemy się rootem, aby upewnić się, że możemy wchodzić w interakcje z usługami systemowymi na odpowiednim poziomie uprawnień, i zatrzymujemy Apache i smbd. Dzięki temu Responder może używać tych portów. Teraz uruchom Responder, aby rozpocząć proces zatruwania:
Teraz, gdy Responder nasłuchuje, możemy czekać na żądanie. W laboratorium zaplanowane zadanie na serwerze docelowym symuluje żądanie co minutę. W rzeczywistości musielibyśmy czekać, aż ktoś złoży żądanie, które normalnie nie jest rozwiązywane. Może to potrwać kilka sekund lub znacznie dłużej, w zależności od tego, jak aktywna jest sieć i ile literówek lub nieprawidłowych nazw hostów używa host. Nasze zaplanowane zadanie zajmuje się tym za nas, ale Rysunek pokazuje, co byśmy zobaczyli, gdybyśmy próbowali uzyskać dostęp do nieistniejącego udziału z systemu Windows.
Poza komunikatem „Dostęp zabroniony” nie widzimy żadnego innego dziwnego zachowania w systemie Windows. Jednak na komputerze Kali widzimy dużo aktywności:
W przykładzie pokazanym na Rysunku 16-1 nie widzimy komunikatu zatrucia, ponieważ zaplanowane zadanie uzyskuje dostęp do celu. W rzeczywistym scenariuszu moglibyśmy zobaczyć tutaj komunikaty zatrucia NetBIOS lub LLMNR, wraz z pewną analizą systemu hosta. W naszym przykładzie otrzymaliśmy skrót NetNTLMv2 wraz z nazwą użytkownika (1). Możemy spróbować złamać te poświadczenia i sprawdzić, czy działają w systemie. Robiąc to samodzielnie, możesz zobaczyć inny skrót, ponieważ nonce klienta zmienia się za każdym razem.
UWAGA: W tym przykładzie pracujemy w przestrzeni laboratoryjnej AWS. Sieci VPC AWS nie obsługują ruchu rozgłoszeniowego ani multicast, więc nie możemy przeprowadzić rzeczywistego zatrucia. Symulowaliśmy to za pomocą zadania zaplanowanego. Rzeczywiste żądanie, które byłoby wymagane do zatrucia, nie zostanie wysłane; jednak ta metodologia spowoduje zatrucie w środowiskach, w których obsługiwane są multicast i broadcast, a klienci mają włączony LLMNR lub NetBIOS.
Teraz, gdy mamy prawidłowy skrót, naciśnij CTRL-C w oknie Responder, aby zatrzymać jego działanie. Następnym krokiem jest zrzucenie skrótów z Responder w formacie, który John the Ripper może przetworzyć:
Tutaj możemy zobaczyć nasz hash NetNTLMv2, ale widzimy również dwa nowe pliki utworzone w katalogu: DumpNTLMv2.txt i DumpNTLMv1.txt. Podczas gdy pliki dla v1 i v2 są tworzone, wiemy, że hash przekazany do Responder był w wersji 2 (v2), więc możemy po prostu uruchomić Johna na pliku v2 i sprawdzić, czy może złamać hasło:
Użyjemy listy haseł stworzonej specjalnie na potrzeby tego laboratorium. Spowoduje to pobranie pliku z GitHub.
Po chwili Johnowi udało się złamać hasło — znalazł hasło „Winter2021!” dla „docelowego” użytkownika. Dzięki tym poświadczeniom możemy uzyskać zdalny dostęp do systemu. W dalszej części tego rozdziału będziemy używać tych poświadczeń, aby dalej wchodzić w interakcję z naszym komputerem docelowym.
Teraz, gdy zainstalowaliśmy Responder, przyjrzyjmy się niektórym opcjom, z których możemy skorzystać. Przede wszystkim przyjrzyjmy się wszystkim opcjom pomocy:
Jest tu wiele opcji, więc skupmy się na tych, które są najbardziej przydatne i najmniej prawdopodobne, że coś zepsują. Niektóre z tych opcji, takie jak wredir, zepsują sieci w pewnych warunkach. Ponadto niektóre działania nas zdradzą, takie jak wymuszenie podstawowego uwierzytelniania. Kiedy wymuszamy podstawowe uwierzytelnianie, ofiara zobaczy wyskakujące okienko z prośbą o nazwę użytkownika i hasło. Zaletą jest to, że otrzymamy hasło w postaci zwykłego tekstu, ale wadą jest to, że użytkownik może zorientować się, że coś jest nie tak. Teraz, gdy omówiliśmy, czego nie robić, przyjrzyjmy się, jak używać Respondera. Najważniejszą opcją jest określenie interfejsu (1). W naszym teście będziemy używać naszego głównego interfejsu sieciowego, eth0. Jeśli znajdujesz się w systemie, który ma wiele interfejsów, możesz określić alternatywny interfejs lub użyć ALL, aby nasłuchiwać wszystkich interfejsów. Następną opcją, którą określimy, jest serwer WPAD (2). WPAD to protokół automatycznego wykrywania serwera proxy sieciowego. Jest on używany przez urządzenia Windows do znajdowania serwera proxy w sieci. Jest bezpieczny w użyciu, jeśli Twoje pudełko Kali ma bezpośredni dostęp do Internetu. Jednak jeśli znajdujesz się w sieci, w której Twoje pudełko Kali musi przechodzić przez serwer proxy, to spowoduje to uszkodzenie klientów, których zatruwasz, więc nie używaj go. Korzyścią z używania tej opcji jest to, że jeśli hosty szukają serwera WPAD dla ruchu sieciowego, każdy ruch sieciowy uruchomi zatrucie Respondera, aby uzyskać skrót — podczas gdy bez niego musisz czekać, aż ktoś przejdzie do udziału, który nie istnieje. Na koniec użyjemy opcji odcisku palca (3). Ta opcja daje nam podstawowe informacje o hostach korzystających z NetBIOS w sieci, takie jak nazwy, które są wyszukiwane i wersje systemu operacyjnego hosta. Da nam to wskazówkę, jakie typy pudełek znajdują się w sieci.
Responder już istnieje w naszej dystrybucji Kali Linux. Jednak Kali nie zawsze aktualizuje się tak często, jak twórca Respondera, Laurent Gaffié, zatwierdza aktualizacje. Z tego powodu będziemy używać najnowszej wersji Respondera. Istnieje ona już w instancji Kali w laboratorium, ale musimy ją zaktualizować do najnowszej wersji. Aby zaktualizować nasze repozytorium, wystarczy wykonać następujące czynności:
Jeśli pojawią się jakieś aktualizacje, nasz kod będzie teraz aktualny. Weryfikując, czy nasz kod jest aktualny przed każdym wykonaniem, możemy mieć pewność, że używamy najnowszych technik, aby w pełni wykorzystać Responder.
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.