Hacking for all!

https://chacker.pl

Coraz więcej narzędzi pozwala nam zabierać ze sobą kod, dzięki czemu nie musimy zastanawiać się, jak wprowadzić go do systemu. Evil-WinRM oferuje nam dwa różne sposoby na przenoszenie kodu: pliki binarne, które wykona dla nas, oraz skrypty, które możemy uruchomić lokalnie. Zacznijmy od ponownego uruchomienia narzędzia z dwiema dodatkowymi opcjami: katalogiem plików binarnych i katalogiem skryptów.

Opcja -e określa lokalizację, z której pobierane są pliki binarne. Ten katalog zawiera szereg plików binarnych C#, które zostały zbudowane na maszynie Util, a następnie przeniesione do naszego komputera Kali podczas wdrażania. Flaga -s określa lokalizację katalogu skryptów. Będziemy mogli załadować dowolne skrypty z tego katalogu do Evil-WinRM. Możemy utworzyć własny katalog i umieścić w nim mnóstwo różnych skryptów, ale w tym przykładzie użyjemy tylko modułów PowerSploit Recon, które już istnieją w Kali. Skrypty nie ładują się automatycznie, więc gdy mamy już powłokę, możemy dowiedzieć się, które skrypty są ładowane, wpisując menu:

Widzimy cztery polecenia, które są domyślnie automatycznie uwzględniane w narzędziu. Dll-Loader, Donut-Loader i Invoke-Binary to różne sposoby wykonywania plików binarnych. Bypass-4MSI pomija AMSI (Windows Antimalware Scan Interface). AMSI umożliwia narzędziom zabezpieczającym systemu Windows uzyskanie dodatkowych informacji o programie PowerShell i innych lokalizacjach w celu wykrywania złośliwego oprogramowania w czasie wykonywania, w tym potencjalnie złośliwego kodu programu PowerShell. W przypadku niektórych narzędzi będzie to wymagane, ale w naszym przypadku program Windows Defender został już wyłączony, aby dane wyjściowe były spójne na wszystkich poziomach poprawek. Aby uruchomić skrypt, wpisujemy nazwę skryptu, a następnie możemy ponownie uruchomić menu, aby wyświetlić zaktualizowaną listę narzędzi. Tutaj uruchomimy skrypt PowerView.ps1:

Dane wyjściowe po uruchomieniu tych poleceń będą znacznie dłuższe, a ponieważ nie mamy pełnej sesji w systemie, nie będziemy mogli wykonywać niektórych działań w domenie. Niektóre polecenia wymagają, aby użytkownik miał bilety lub skróty buforowane w sesji. Możemy jednak uruchamiać polecenia lokalnie na maszynie. Spróbujmy pobrać dane użytkownika z AWS dla tego systemu:

Z danych wyjściowych wynika, że ​​osoba, która wdrożyła ten system, skonfigurowała zmianę hasła, gdy urządzenie jest online. W tym przypadku hasło użytkownika Admin to „GrayHatHack1ng!”. Teraz będziemy mogli zalogować się jako użytkownik Administrator, nawet jeśli użytkownik docelowy zmienił hasło. Możemy również spróbować pobrać te dane bezpośrednio z systemu, używając jednego z naszych plików binarnych. Możemy je wywołać za pomocą polecenia cmdlet Invoke-Binary wbudowanego w Evil-WinRM.

Mimo że określiliśmy ścieżkę, w której znajduje się nasz plik binarny, nadal musimy użyć pełnej ścieżki, aby dostać się do pliku binarnego, z którego uruchomiono evil-winrm (w tym przypadku katalog Binaries). To narzędzie zrzuca skróty z pamięci, a my musimy określić jeden argument — host, z którym ma nastąpić połączenie. Gdybyśmy mieli wiele argumentów, rozdzielilibyśmy je w cudzysłowie przecinkami, aby program wiedział, który argument zostanie wywołany. Wynikowy wynik zawiera zarówno skróty z lokalnego systemu, takiego jak użytkownik Administrator, jak i buforowane dane uwierzytelniające w systemie dla użytkownika docelowego. Teraz mamy skróty, których możemy użyć, jeśli zajdzie taka potrzeba dla Administratora, a także hasło Administratora ustawione za pomocą danych użytkownika AWS i buforowany skrót użytkowników w systemie, który moglibyśmy spróbować złamać.

 

https://chacker.pl/

Jednym ze sposobów, w jaki WinRM może nam pomóc, jest umożliwienie zdalnego wykonywania poleceń. Niestety, w momencie pisania tego tekstu nie było zbyt wielu narzędzi wiersza poleceń Kali, które mogłyby to zrobić domyślnie. Istnieją jednak gemy Python (pywinrm) i Ruby (winrm), które obsługują protokół. Nasza instalacja Ansible dla laboratorium automatycznie zainstalowała gem evil-winrm, który pozwala nam używać gemów Ruby do wykonywania zadań, ale ma dodatkową funkcjonalność z myślą o testerach penetracyjnych. Aby nawiązać interakcję ze zdalnym hostem za pomocą evil-winrm, zacznijmy od uruchomienia prostego polecenia whoami. Musimy tylko określić użytkownika, hasło i cel, a po nawiązaniu połączenia otrzymamy monit i będziemy mogli wydawać polecenia:

Możesz zobaczyć, że określiliśmy -u dla poświadczeń użytkownika, -p dla hasła i -i dla adresu IP. Po połączeniu otrzymaliśmy monit, który śledzi naszą lokalizację w systemie plików. Używając tego monitu, możemy uruchamiać polecenia powłoki, ale możemy również uruchamiać program PowerShell bezpośrednio z monitu. Pobierzmy listę lokalnych użytkowników:

Widzimy wyjście PowerShell polecenia Get-LocalUser i możemy zobaczyć domyślne konto Administratora, a także konto evilhacker, które utworzyliśmy wcześniej. W tej konfiguracji jesteśmy ograniczeni do skryptów PowerShell, które mamy w systemie lub możemy zaimportować przez Internet. Polecenia cmdlet, takie jak Invoke-WebRequest i Invoke-Expression, mogą być używane do zdalnego pobierania elementów przez Internet i do systemu, ale jeśli chcemy zabrać ze sobą własny kod, musimy spróbować czegoś innego. Aby wyjść z powłoki Evil-WinRM, wpisz exit, aby powrócić do wiersza poleceń Kali.

https://chacker.pl/

WinRM to dodatkowy sposób zdalnej interakcji z systemem Windows. Wprowadzone w systemach Windows 8 i Windows Server 2012 narzędzie to wykorzystuje protokół SOAP przez połączenia internetowe do interakcji z systemem docelowym. Obsługuje zarówno protokół HTTP, jak i HTTPS, a także uwierzytelnianie oparte na podstawowym uwierzytelnianiu, skrótach i protokole Kerberos. Oprócz możliwości tworzenia skryptów za pomocą interfejsów opartych na WMI, uruchamiania aplikacji i interakcji z programem PowerShell, jest to bardzo potężne narzędzie, z którego możemy korzystać, gdy tylko je znajdziemy.

 

https://chacker.pl/

Teraz, gdy wiemy już trochę więcej o WMI, przyjrzyjmy się, jak wykonywać polecenia. Mamy dwie opcje wykonywania poleceń za pomocą WMI: możemy utworzyć nowy proces za pomocą WMI, a następnie monitorować dane wyjściowe lub możemy użyć jednego z narzędzi wbudowanych w Kali. W tym przykładzie użyjemy pliku binarnego impacket-wmiexec, aby uruchomić polecenia. Aby wykonać podstawowy test, uruchommy impacket-wmiexec, aby pobrać nazwę użytkownika. Uruchomimy to polecenie dla naszego celu Windows:

Następnie zróbmy coś bardziej interesującego. Utwórzmy użytkownika backdoor, abyśmy mogli wrócić później. Chcemy dodać tego użytkownika do grupy Administrators lokalnie, abyśmy mieli pełny dostęp, gdy się połączymy. Dzięki temu mamy pewność, że jeśli użytkownik zmieni hasło, nadal będziemy mieć dostęp do systemu docelowego. Na początek użyjemy polecenia net user, aby utworzyć nowego użytkownika o nazwie evilhacker:

Powinniśmy zobaczyć komunikat o połączeniu i informację, że polecenie zostało wykonane pomyślnie:

Gdy to polecenie jest uruchamiane, wykonuje polecenie za pośrednictwem WMI i zapisuje dane wyjściowe do pliku. Program automatycznie pobiera zawartość pliku, więc wiemy, że polecenie zostało wykonane pomyślnie. Teraz, gdy mamy nowego użytkownika w systemie, dodajmy tego nowego użytkownika do lokalnej grupy Administratorzy za pomocą net localuser:

Teraz, gdy dodaliśmy naszego użytkownika evilhacker do grupy Administrators, upewnijmy się, że nasza aktywność zadziałała. Wrócimy i użyjemy net localgroup dla grupy Administrators, aby upewnić się, że nasz użytkownik się pojawi. Na koniec sprawdźmy, czy mamy dostęp:

Udało nam się utworzyć tylne wejście do systemu, które umożliwi nam powrót później i dostęp do niego. Dodaliśmy je do grupy Administratorzy, abyśmy mogli eskalować uprawnienia do użytkownika SYSTEM. Kiedy wypróbowaliśmy nasze polecenie winexe, pomyślnie odzyskaliśmy powłokę, weryfikując, że mamy dostęp, gdy będziemy go potrzebować w przyszłości, niezależnie od tego, na jakie hasło użytkownik zmieni. Nie zapomnij wpisać exit, aby wyjść z powłoki, gdy skończysz.

https://chacker.pl/

Wiedząc, że możemy zapytać o informacje systemowe za pomocą WMI, możemy chcieć dowiedzieć się kilku rzeczy o naszym systemie docelowym. Na przykład możemy chcieć wiedzieć, kto jest zalogowany interaktywnie, aby sprawdzić, czy istnieje ryzyko, że zostaniemy złapani. W tym laboratorium użyjemy dwóch różnych zapytań WMI, aby zobaczyć, który użytkownik lub użytkownicy są zalogowani w systemie docelowym. Aby zapytać WMI, musimy zbudować zapytanie WMI Query Language (WQL), które uzyska informacje, których szukamy. WQL wygląda podobnie do Structured Query Language (SQL), który jest używany do zapytań do bazy danych. Aby zbudować nasze zapytanie, musimy jednak dowiedzieć się trochę więcej o tym, jak działa WMI. Najważniejszą rzeczą, którą musimy wiedzieć, jest klasa, którą będziemy pytać. Sekcja „Do dalszej lektury” na końcu tego rozdziału zawiera wpis, który wskazuje na listę klas firmy Microsoft, do których można uzyskać dostęp za pośrednictwem WMI. Jednak w tym ćwiczeniu przyjrzymy się tylko dwóm. Pierwszą klasą, którą będziemy kwerendować, jest klasa win32_logonsession.1 Ta klasa zawiera informacje o sesjach, do których się zalogowano, typie wykonanego logowania, czasie rozpoczęcia i innych danych. Najpierw ułóżmy zapytanie, a następnie przyjrzymy się, jak wykonać to zapytanie za pomocą WMI:

Używając tego zapytania wybieramy dwa różne elementy danych z klasy win32_logonsession. Pierwszy to LogonType, który zawiera informacje o typie wykonywanego logowania. Drugi, LogonId, to wewnętrzny numer identyfikacyjny sesji logowania. Aby wykonać to zapytanie, musimy użyć klienta WMI. Kali ma dwóch różnych klientów dla zapytań WMI: pierwszy to pth-wmic, a drugi jest częścią skryptów Impacket. Klient pth-wmic jest łatwiejszy do skryptowania, więc skupimy się na nim. Składnia dla pth-wmic jest podobna do składni narzędzia Winexe, którego używaliśmy w poprzednim laboratorium. Określimy użytkownika i hosta w ten sam sposób, a następnie dodamy nasze zapytanie WQL na końcu polecenia:

Po wykonaniu polecenia zostaną zwrócone informacje o sesjach logowania:

Patrząc na wynik naszego zapytania, widzimy sesję i typ logowania. Tutaj pokazano kilka typów logowania, więc skąd wiemy, które sesje nas interesują? Aby to ustalić, zapoznaj się z Tabelą, która pokazuje różne typy logowania i ich znaczenie.

Teraz, gdy wiemy, co oznaczają typy, ograniczmy nasze zapytanie tylko do logowań typu 2 i typu 10. Powinno nam to powiedzieć, jakich identyfikatorów logowania musimy szukać, aby znaleźć interaktywne logowania użytkowników.

Nadal widzimy wiele różnych logowań. Przyjrzyjmy się trzem z nich: jednemu z serii 30K, jednemu z serii 50K i jednemu z serii „ponad 1 milion”. Sesje logowania są mapowane na użytkowników w tabeli win32_loggedonuser. Niestety, trudno jest to przeszukać za pomocą WQL pod kątem konkretnych identyfikatorów logowania, ponieważ wartości są ciągami znaków, a nie liczbami całkowitymi, więc napiszemy skrypt z pth-wmic i egrep, aby uzyskać pożądane wartości. Każdy system będzie miał inne wartości, więc pamiętaj, aby użyć wartości LogonID otrzymanych z systemu zamiast naszych wartości dla egrep, jak pokazano tutaj:

Powinniśmy zobaczyć zwrócone tylko wybrane wartości LogonID:

W naszym przykładzie widzimy trzech użytkowników: target, DWM-1 i DWN-2. DWM i UMFD to konta oparte na sterownikach, więc możemy je bezpiecznie zignorować. Możesz zobaczyć inną listę, w zależności od tego, kiedy uruchomisz polecenie. Jeśli chcesz mieć pewność, że użytkownik docelowy się pojawi, powinieneś upewnić się, że jest zalogowany w systemie docelowym przed uruchomieniem tego polecenia. Widzimy tutaj pewien wzór, więc spójrzmy tylko na procesy, które nie są lokalne dla WS20:

Domena, nazwa użytkownika i LogonId powinny zostać zwrócone dla każdego użytkownika, który nie jest lokalny w systemie:

Na koniec możemy zobaczyć sesje zalogowane do pola. Wszystkie są użytkownikami docelowymi w domenie GHH. Używając WMI ustaliliśmy, że użytkownik docelowy jest zalogowany interaktywnie do systemu. Dlatego jeśli zrobimy coś, co spowoduje wyskoczenie okna lub zakłócenia, możemy zostać wykryci.

https://chacker.pl/

Windows Management Instrumentation (WMI) to zestaw specyfikacji umożliwiających dostęp do informacji o konfiguracji systemu w przedsiębiorstwie. WMI umożliwia administratorom przeglądanie procesów, poprawek, sprzętu i wielu innych informacji o systemie docelowym. Ma możliwość wyświetlania informacji, tworzenia nowych danych, usuwania danych i zmiany danych w systemie docelowym na podstawie uprawnień użytkownika wywołującego. Jako atakujący oznacza to, że możemy użyć WMI, aby dowiedzieć się całkiem sporo o systemie docelowym, a także manipulować stanem systemu.

https://chacker.pl/

W wielu przypadkach rzeczy, które chcemy zrobić w systemie docelowym, będą wymagały podwyższonych uprawnień. W poprzednim laboratorium mogliśmy uzyskać dostęp jako zwykły użytkownik, ale tak naprawdę chcemy uzyskać dostęp jako użytkownik SYSTEM. Ponieważ ten użytkownik ma pełne uprawnienia w systemie, możemy uzyskać dostęp do poświadczeń, pamięci i innych cennych celów.

Aby wykonać nasz atak, użyjemy wszystkich tych samych opcji, co w naszym poprzednim laboratorium, ale dodamy flagę –system. To zajmie się eskalacją za nas, a końcowym rezultatem będzie wysoce uprzywilejowana powłoka, jak pokazano tutaj:

Jak widać tutaj, uzyskujemy teraz dostęp do komputera ofiary jako użytkownik SYSTEM. Chociaż nie jest to częścią zakresu tego ćwiczenia, pozwala nam to na zrzucenie poświadczeń, utworzenie nowych użytkowników, ponowną konfigurację urządzenia i wykonanie wielu innych zadań, których zwykły użytkownik mógłby nie być w stanie wykonać. Pamiętaj, aby wpisać exit w wierszu poleceń, aby opuścić powłokę po zakończeniu.

https://chacker.pl/

Mamy dane uwierzytelniające dla naszego systemu docelowego z Responder, ale jak teraz możemy wchodzić w interakcję z naszym systemem docelowym? Używanie Winexe jest powszechnym sposobem, w jaki atakujący uzyskują dostęp do systemów zdalnych. Używa nazwanych potoków przez ukryty udział IPC$ w systemie docelowym, aby utworzyć usługę zarządzania. Po utworzeniu tej usługi możemy się z nią połączyć i wywoływać polecenia jako usługę. W tym laboratorium zaczynamy tam, gdzie kończy się Lab 16-1. Upewnij się, że wykonałeś kroki z tego laboratorium. Najpierw wychodzimy z powłoki głównej i wracamy do katalogu domowego. Następnie weryfikujemy, czy nasz system docelowy udostępnia IPC$, używając smbclient do wyświetlenia listy udziałów w systemie docelowym:

Mamy dane uwierzytelniające dla naszego systemu docelowego z Responder, ale jak teraz możemy wchodzić w interakcję z naszym systemem docelowym? Używanie Winexe jest powszechnym sposobem, w jaki atakujący uzyskują dostęp do systemów zdalnych. Używa nazwanych potoków przez ukryty udział IPC$ w systemie docelowym, aby utworzyć usługę zarządzania. Po utworzeniu tej usługi możemy się z nią połączyć i wywoływać polecenia jako usługę. W tym laboratorium zaczynamy tam, gdzie kończy się Lab 1. Upewnij się, że wykonałeś kroki z tego laboratorium. Najpierw wychodzimy z powłoki głównej i wracamy do katalogu domowego. Następnie weryfikujemy, czy nasz system docelowy udostępnia IPC$, używając smbclient do wyświetlenia listy udziałów w systemie docelowym:

Mamy dane uwierzytelniające dla naszego systemu docelowego z Responder, ale jak teraz możemy wchodzić w interakcję z naszym systemem docelowym? Używanie Winexe jest powszechnym sposobem, w jaki atakujący uzyskują dostęp do systemów zdalnych. Używa nazwanych potoków przez ukryty udział IPC$ w systemie docelowym, aby utworzyć usługę zarządzania. Po utworzeniu tej usługi możemy się z nią połączyć i wywoływać polecenia jako usługę. W tym laboratorium zaczynamy tam, gdzie kończy się Lab 16-1. Upewnij się, że wykonałeś kroki z tego laboratorium. Najpierw wychodzimy z powłoki głównej i wracamy do katalogu domowego. Następnie weryfikujemy, czy nasz system docelowy udostępnia IPC$, używając smbclient do wyświetlenia listy udziałów w systemie docelowym:

https://chacker.pl/

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.

https://chacker.pl/

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.