Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Ktoś podesłał nam na Facebooku zip-a. W zipie był zainfekowany plik bat. Ale co konkretnie? Malware wykradający dane. Analiza.
Na początku tygodnia na naszą skrzynkę na Messengerze (komunikator Meta) trafiła taka oto wiadomość:
O czym informowaliśmy na naszym Facebooku.
W komentarzach oprócz celnych dowcipów padły też pytania, co zawiera niecodzienny załącznik. My z kolei byliśmy bardzo zainteresowani, jakiego produktu tajemniczy jegomość nie był w stanie zlokalizować w naszym sklepie. Dlatego postanowiliśmy to sprawdzić, a że analiza zajęła nam może jakieś pięć minut, to chętnie opowiemy, do jakich wniosków doszliśmy (spoiler alert: ten produkt nigdy nie był dostępny w sklepie).
Pierwszym krokiem było pobranie i rozpakowanie zipa. Niezależnie od pochodzenia wiadomości, we wszystkie linki i załączniki klikamy wewnątrz zwirtualizowanego środowiska. Jeśli chcecie dowiedzieć się, jak zbudować ciekawy pipeline do detonacji malware, to polecamy zapoznać się z projektami takimi jak drakvuf-sandbox od CERT Polska.
Wypakowane archiwum (tutaj od razu mały protip, przesyłając sobie archiwum z niebezpieczną zawartością można je zabezpieczyć hasłem „infected”, tak jak większość sampli dostępnych w Internecie) zawiera plik wsadowy `Imported product images_2024.bat`.
Otwarcie go w ulubionym edytorze, pokaże„chińskie znaczki”, jak na rysunku 1.
Dlaczego tak się dzieje? Wyświetlenie tego pliku przy pomocy polecenia xxd (listing 1.1) wskaże, że na początku pliku znajdują się bajty FFFE, które są niedrukowalnym znacznikiem kolejności bajtów (tzw BOM). W tym przypadku wskazują na UTF-16 Little Endian.
Zignorowanie BOM-a spowoduje, że plik wsadowy zostanie wyświetlony poprawnie co zaprezentowano na listingu 1.2.
Analizując linijka po linijce zawartość skryptu, można stwierdzić, że pobiera on kilka plików i umieszcza w różnych lokalizacjach, które mają wydać się „naturalne”. Same nazwy, takie jak Windowupdates.bat, Windown czy bz3.py (łudząco podobne do bz2.py) mają za zadanie nie wzbudzać zbytnio podejrzeń.
Na dzień dzisiejszy pierwszy plik wsadowy ma tylko dwie detekcje na VirusTotal:
A trafił na niego po raz pierwszy dwa dni wcześniej:
First Submission
2024-01-15 04:25:07 UTC
Last Submission
2024-01-16 19:05:33 UTC
Last Analysis
2024-01-16 19:05:33 UTC
Przejdźmy teraz bezpośrednio do analizy:
Polecenie cmd /c “” <URL> nie jest zbyt ciekawe, bo otworzy po prostu przekazany URL w domyślnej przeglądarce użytkownika. Spójrzmy jednak na pliki, które są serwowane z mediafire. Pierwszy z nich zapisywany jako Windownupdate.bat, jego zawartość została pokazana na listingu 1.3.
Uruchomiony zostaje skrypt napisany w Pythonie, który został pobrany do katalogu „Windown”. Co ciekawe jest to redundantne wywołanie, bo pierwsze pojawiło się już w oryginalnym pliku wsadowym. Wiele mówi natomiast lokalizacja pliku, która wskazuje na autorun systemowy. Ma to zapewnić pewną persystencję i okresowe uruchomienie złośliwego oprogramowania.
Największy plik Windown.zip to, jak wskazuje rozszerzenie, archiwum. Po pobraniu i rozpakowaniu naszym oczom ukazuje się kilka binarek i katalogi Lib oraz DLL, które wyglądają na interpreter Pythona skompilowany pod Windowsa. Całe archiwum jest duże i waży ponad 15MB.
Przeglądając pliki wsadowe można odnieść wrażenie, że cała logika malware jest ukryta w bz3.py. Jego zawartość została zaprezentowana na listingu 1.4, przy czym skrócono mało ważne z punktu widzenia analizy fragmenty dla zwiększenia czytelności:
Plik bz3.py trafił na VT już jakiś czas temu i jest flagowany przez 4 antywirusy jako szkodliwy.
To, co widać na listingu 1.4 to przede wszystkim próba ukrycia prawdziwej logiki kodu przez wykorzystanie zapisu heksadecymalnego, kompresji zlib, bz2, gzip i lzma. Rozpakowany kod jest następnie wywoływany przez funkcję exec(). Tak naprawdę wielokrotna zmiana sposobu kodowania nie wymusza na badaczu nadmiernej pracy w celu deobfuskacji kodu – wystarczy podmienić wywołanie exec() na funkcję print(), aby Python sam rozpakował i wyświetlił ten konkretny kod na standardowym wyjściu, co zostało zaprezentowane na listingu 1.5
Teraz należy tylko uporządkować skrypt – usunąć escape’owanie znaków i otrzymujemy w pełni czytelny plik tekstowy z kodem Pythona. Dalej analiza wciąż jest trywialna. Na listingu 1.6 zaprezentowany został większy fragment bz3.py, pominięto tylko mało ważne fragmenty, których dodanie zaciemniałoby logikę kodu.
Funkcja Compressed również używa obfuskacji przy pomocy kodowania base64, po przekształceniu ma postać taką jak na listingu 1.7.
To, co można odczytać od razu nie zgłębiając się w logikę funkcji powiązanych z konkretnymi przeglądarkami, to przede wszystkim to, że program próbuje zabić procesy znanych mu przeglądarek. Następnie wykradane są informacje z katalogów przechowujących informacje o profilach użytkownika (loginy i hasła, ciasteczka etc.). Ta zawartość jest pakowana, szyfrowana, dodawany jest identyfikator na bazie IP sprawdzanego przez wykonanie zapytania do zewnętrznego serwisu https://ipinfo.io oraz wysyłana POST-em do Telegramowego bota. Prawda, że proste?
Na tym etapie kończymy naszą „analizę”. Pamiętajcie, że jeśli otrzymacie podobne wiadomości to możecie je zgłosić do CERT Polska co i my uczyniliśmy przed publikacją tego artykułu.
Jak widać, działanie skryptu jest bardzo proste, kod jest niskiej jakości, a obfuskacja jest po prostu śmieszna (chociaż na ten moment skutecznie chroni przed statycznymi analizatorami AV). Pozostaje pytanie: dlaczego autorzy tego malware nie zajmą się czymś pożytecznym? Cóż, bazując na tym, że ich „malware” nie zasługiwałby na zaliczenie „Podstaw Programowania” na pierwszym roku studiów – nie wiemy, ale się domyślamy :)
O tym scamie informuje już między innymi CSRIT KNF.
Identyfikatory IoC:
4ff8650c658b569c3d6b7399d0858aa6
c6f4e344b92b077b10695ddb4f21c3767ffc7629
d807b9ffd80462bc3b66d2ab65cb784e
728e19bf538e612eec8a9827dcc45a16eb7b70b3
C:\\Users\\Public\\yourfile.bat
C:\\Users\\Public\\Windown.zip
~callsign.chaos
Fajna analiza!
Czy polecacie jakieś publikacje odnośnie plików wsadowych? Czy tylko w stylu „MS-DOS dla opornych”, albo po prostu /?
Bacze cały czas w użyciu.
Dlaczego oceniliscie że kod jest niskiej jakości i że nie zaliczyłby podstaw programowania? Bo jest podzielony na mało funkcji, albo bo nie jest obiektowy? Czy mało odporny na nietypowe konfigurację użytkownika?
Bo jest prymitywny, nie obsługuje błędów, oczekuje domyślnej konfiguracji użytkownika, wprowadza redundantny kod, sposób eksfiltracji jest łatwy do przechwycenia i zablokowania. Generalnie jedyna zaleta to taka (z punktu widzenia atakującego), że czasami zadziała :)
Wrzućcie tego zip’a na neta. Chętnie bym zrobił taka analizę sam. A może znacie /polecacie akieś strony z przykładami i analizami?
Czyli nadawca tego maila chciał w Waszym sklepie kupić ciasteczka… :)