Cześć
Ostatnimi czasy byliśmy zasypywaniu oryginalnymi i pomysłowymi metodami Delivery 1. Cyberprzestępcy nie próżnują – powiadomienia GitHub, fałszywa Captcha – do wyboru do koloru.
Od czego się zaczęło?
Niedawno na portalu X natknąłem się na wpis jednego z użytkowników2, który podzielił się ciekawą próbą infekcji jego stacji. Zaczęło się od próby pobrania wtyczki do programu Visual Studio Code – popularnego edytora tekstu. Wtyczka miała obsługiwać język Solidity – nowoczesny język programowania służący głównie do tworzenia Smart Contractów i generalnie do pracy z Web3. Co ciekawe – nie mówimy tu o pierwszej lepszej wtyczce, ale o rozszerzeniu, które było pobrane ponad 1.5 mln razy!
Niestety, w dniu pisania tego tekstu wtyczka o której mowa była już niedostępna w Visual Studio Code (screen po prawej stronie) – jednak skoro została usunięta, mamy prawo domniemać, że to właśnie ona zawierała złośliwy kod. Według autora wtyczka pobierała kod skryptowy BATCH z domeny z rosyjskim TLD. Niestety, domena ta nie odpowiadała gdy chciałem ściągnąć ten skrypt:
Autor wrzucił również link do analizy w Hybrid-Analysis3, a dzięki hashowi szybko namierzyłem skrypt BAT na Malware Bazaar4.
Analiza skryptu BAT
Generalnie skrypt jest dość mocno zaobfuskowany. Zawiera on wiele linijek, które nie pełnią żadnej konkretnej funkcji, innej rzecz jasna niż zaciemnienie kodu. Mimo to – dość łatwo się ich pozbyć, ponieważ powtarzają się w nich te same patterny.
Skrypt co do zasady możemy podzielić na 3 części:
- Zaszyfrowana, bajtowa postać złośliwego programu typu RAT – później dowiemy się, że jest to .NETowe assembly
- Zaobfuskowany kod powershell, który:
- Odszyfrowuje złośliwy malware
- Ładuje go do pamięci Powershella
- Uruchamia określone metody
- Przyporządkowanie fragmentów kodu do zaobfuskowanych zmiennych
W tej krótkiej wyliczance, należy zacząć od końca. Skrypt BAT zawiera fragmenty poleceń Powershella, które są przyporządkowane do długich, skomplikowanych zmiennych.
Takich zmiennych jest kilkadziesiąt. Po połączeniu, składają się one na gotowy kod powershella:
Stwórzmy słownik!
Jeżeli mamy do czynienia z wieloma zmiennymi, które mogą być tłumaczone na powershellowe „wstawki”, postanowiłem stworzyć wygodny słownik. Dosłownie – wykorzystałem strukturę Dictionary w Pythonie:
Deobfuskacja skryptu
Mając słownik, przeszedłem do deobfuskacji kodu. Przy okazji usunąłem niepotrzebne linie (zaczynały się znakami wykrzykników), a także wyłączyłem z logiki programu linijkę z zaszyfrowanym payloadem (malware w formacie bajtów – linijka zaczynała się od dwóch dwukropków i spacji). Ponadto, wyodrębniłem literki znajdujące się pomiędzy znakami %%^% i %. Zauważyłem, że składają się one w pewną całość:
Kod do deobfuskacji wyglądał następująco:
Oczywiście zdaję sobie sprawę, że nie jest to eleganckie rozwiązanie, ale zależało mi na szybkości. Efektem działania skryptu był następujący kod:
Jak można zauważyć, na samym początku skrypt wykrywa ewentualną wirtualizację lub obecność Sandboxów i kończy swoje działanie w przypadku natrafienia na nie. To całkiem sprawna technika, która przeciwdziała niektórym sandboxom, ponieważ nigdy nie zostanie w nich wykonany złośliwy fragment kodu.
W dalszej części główny ciężar pracy niesie za sobą Powershell.exe, który poprzez „pipe” przejmuje definicje funkcji i określone polecenia. Ciekawe fragmenty zaznaczyłem na czerwono:
- Powershell czyta nazwę aktualnego pliku (dzięki BATowej zmiennej %~f0)
- Powershell czyta zawartość pliku i szuka linii, która zaczyna się na „:: „
- Dzieli zawartość tej linii na dwie części, rozdzielając je znakiem ukośnika
- Deszyfruje te dwie części i ładuje wynik (.NET assembly) do pamięci
Symulacja działania
Usuwając napisy „blck” udało mi się dojść do funkcji i metod, które ładowały bajty do pamięci programu Powershell, a następnie odwoływały się do zadeklarowanych tam klas i metod. Wiedziałem już, że mam do czynienia z malware napisanym w .NET.
'$ucFsW = blck[blckSblckyblcksblcktblckeblckmblck.blckRblckeblckfblcklblckeblckcblcktblckiblckoblcknblck.blckAblcksblcksblckeblckmblckbblcklblckyblck]blck::blckLblckoblckablckdblck([byte[]]$eXEDy);'.Replace('blck', '')
$ucFsW = [System.Reflection.Assembly]::Load([byte[]]$eXEDy);
Po serii prób i błędów, udało mi się doprowadzić w bezpiecznym środowisku testowym skrypt do następującej postaci:
W kolejnym kroku, odtworzyłem działanie skryptu i odszyfrowałem .NET assembly, a następnie załadowałem je do Powershella. Nie szukałem jednak linijki „::” w aktualnym pliku, lecz zapisałem sobie wcześniej zaszyfrowaną linijkę w pliku „encrypted.txt”:
Załadowanie .NET assembly – Onimai RAT
W ostatnim kroku, załadowałem Assembly, bez wykonywania żadnych metod.
Po załadowaniu programu postanowiłem nieco się rozejrzec, aby spróbować dowiedzieć się jak najwięcej.
Zdaje się, że udało się odnaleźć bohatera tego wpisu.
Według ThreatMon.io, Onimai RAT to zaawansowany malware zapewniający atakującym zdalny dostęp do zainfekowanej stacji. Twórca na swoim telegramowym kanale chwali się cechami FUD (Fully Undetectable), a samo oprogramowanie podobno zapewnia takie funkcje jak:
- Monitorowanie pulpitu w czasie rzeczywistym
- Wbudowany UAC bypass
- Szyfrowaną komunikację z atakującym
- Wbudowane metody persistence
Więcej o tym rozwiązaniu możecie przeczytać na TG Onimai, który jest dość prosty do znalezienia.
Podsumowanie
Mam nadzieję, że ten krótki wpis pokazał jak pomysłowi potrafią być cyberprzestępcy w kontekście dostarczania malware do ofiar. Mieliśmy tu do czynienia z kilkoma pomysłowymi i mniej lub bardziej oryginalnymi technikami:
- Złośliwa, zaufana wtyczka VS Code – ponad milion pobrań wzbudza zaufanie
- Wtyczka Solidity – programiści Smart Contractów mają często dostęp do bardzo wrazliwych danych takich jak klucze API czy klucze prywatne do portfeli kryptowalut/tokenów
- Zaawansowana obfuskacja z wykorzystaniem CMD – AMSI nie skanuje CMD, czyli pierwsza faza ataku pomija AMSI
- Powershell – tu atakujący poszedł na łatwiznę umieszczając zaszyfrowany payload w tym samym pliku. Chyba lepiej byłoby umieścić go na jakimś zaufanym, zewnętrznym zasobie.
