Initial Access – analiza złośliwej wtyczki VSCode

Cześć

Ostatnimi czasy byliśmy zasypywaniu oryginalnymi i pomysłowymi metodami Delivery ¹. 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ów², 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 interesujące – nie mówimy tu o pierwszej lepszej wtyczce, ale o rozszerzeniu, które było pobrane ponad 1.5 mln razy!

Złośliwa wtyczka

Aktualne wtyczki dla Solidity w VS Code

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ć, iż 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:

Złośliwy fragment pluginu VSCode

Autor wrzucił również link do analizy w Hybrid-Analysis³, a dzięki hashowi gwałtownie namierzyłem skrypt BAT na Malware Bazaar⁴.

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ę, iż 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, iż składają się one w pewną całość:

Dodatkowy kod ujęty między znaki %%^% i %

Kod do deobfuskacji wyglądał następująco:

Oczywiście zdaję sobie sprawę, iż 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. interesujące fragmenty zaznaczyłem na czerwono:

• Powershell czyta nazwę aktualnego 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

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ż, iż 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, ale zapisałem sobie wcześniej zaszyfrowaną linijkę w pliku „encrypted.txt”:

Odszyfrowanie złośliwego pliku binarnego i zapisanie go do zmiennych $hDTZf i $TIMGz

Załadowanie .NET assembly – Onimai RAT

W ostatnim kroku, załadowałem Assembly, bez wykonywania żadnych metod.

Załadowanie do pamieci Powershella złośliwego programu .NET

Po załadowaniu programu postanowiłem nieco się rozejrzec, aby spróbować dowiedzieć się jak najwięcej.

Odczytanie przestrzeni nazw analizowanej binarki

Zdaje się, iż 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 Onima, który jest dość prosty do znalezienia.

Podsumowanie

Mam nadzieję, iż 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łowi 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.

1. https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html ︎
2. https://x.com/LehmannLorenz/status/1841545179825942991 ︎
3. https://t.co/m1j9iuLI8F ︎
4. https://bazaar.abuse.ch/sample/e96f8f61e3af77c429ae6af54c128f7b8420a45a0a63bdfcacd682773b8e5fc1/ ︎