Obszerna analiza złośliwego oprogramowania na polskim przykładzie

dodał 25 stycznia 2018 o 08:01 w kategorii Złośniki  z tagami:
Obszerna analiza złośliwego oprogramowania na polskim przykładzie

Jeden z naszych Czytelników, Robert, podesłał nam bardzo szczegółowy opis swojej pracy nad analizą pierwszego etapu ataku na polskich internautów sprzed paru miesięcy. Czytajcie i uczcie się, bo jest czego.

Choć w większości przypadków zespoły reagujące na incydenty mają co analizować i ich celem jest jak najszybsze wydobycie najistotniejszych informacji z otrzymanej próbki, to czasem trzeba tematowi przyjrzeć się dużo bliżej, by mieć pewność, że niczego się nie przegapiło. Takie podejście krok po kroku do analizy pierwszego etapu infekcji opisuje tekst Roberta, któremu oddajemy głos.

Spis treści:

  1. Wstęp
    1. Czas to pieniądz
    2. Zaciemnienie kodu
      1. Teoria
      2. Zaciemnienie kodu, dobre czy złe?
  2. Ekstrakcja przykładu [praktyka – faza 0]
    1. Pozyskanie szablonu poczty elektronicznej z kampanii
    2. Pozyskanie próbki złośliwego oprogramowania
    3. Analiza 1 – * (jeden do wielu)
    4. Nie ufaj, to podstawa
  3. Odciemnienie z wykorzystaniem sandboksa [praktyka – faza 1]
    1. SEKOIA DROPPER ANALYSIS
    2. REVERSE.IT
    3. VIRUSTOTAL
    4. JOESandbox
    5. Zebranie wskaźników infekcji z sandboksa
  4. Odciemnienie JavaScript półmanualne [praktyka – faza 2]
    1. Zdejmujemy zaciemnienie wyglądu (http://jsbeautifier.org/)
    2. Zdejmujemy zaciemnienie danych i kontroli
      1. Przygotowania i omówienie narzędzi
      2. Zamiana ship33 na String[“fromCharCode”]
      3. Zdejmowanie zaciemnionych danych
      4. Czyszczenie łańcuchów znaków typu „S” + „c” + „r” + „i” + „p” + „t” + „
      5. Dekodowanie tekstu unicode
    3. Dodatkowe wskaźniki infekcji pozyskane z metody półautomatycznej
  5. Wnioski
    1. Wykrywanie niechcianego oprogramowania dzięki wskaźnikom infekcji
    2. Blokowanie niechcianego oprogramowania dzięki wskaźnikom infekcji
    3. Prewencja i utwardzanie stacji pod względem bezpieczeństwa
    4. Dzielenie się wskaźnikami infekcji ze społecznością analityków i próby poznania aktorów
  6. Podsumowanie
  7. Dodatkowe materiały

Wstęp

W poniższym tekście zajmiemy się zdejmowaniem zaciemnienia z niechcianego oprogramowania, które ostatnio atakuje instytucje finansowe w Polsce (kampanie rozsyłające niechciane wiadomości zostały wysłanie w dniach 8.12.2017, 14.12.2017, 15.12.2017). W zasobach plikowych dołączonych do tego opracowania będą opracowane wszystkie trzy kampanie, natomiast samo opracowanie skupi się na dniu 8.12.2017. Dodatkowo postaram się pokazać cały proces działania zespołu bezpieczeństwa, który walczy z takimi zagrożeniami. Z uwagi na fakt istnienia różnego typu niechcianego oprogramowania oraz wielu technologii ich tworzenia, skupimy się w tym opracowaniu wyłącznie na języku JavaScript oraz na komponencie ataku nazywanym dropperem/downloaderem. Przestępcy zmieniali w czasie kampanie, domeny, numery IP, metodę zaciemnienia, natomiast sam komponent służący, z punktu widzenia przestępcy, do bezpiecznego dostarczenia i uruchomienia docelowego niechcianego oprogramowania na stacji użytkownika nie był wymieniany. Jak już na wstępie widać, proces ataku jest modularny, odpowiednie komponenty kupuje się na aukcjach, czyli są kosztem dla atakujących. Wymienione wyżej elementy (wygląd kampanii, domeny, IP C2, metoda zaciemnienia, sumy kryptograficzne i inne elementy identyfikujące złośliwe oprogramowanie) stanowią tak zwane wskaźniki infekcji (IOC). Podobnie zresztą jak narzędzia użyte do zaciemnienia kodu, czy też sama taktyka działania przestępcy oraz kampanii. Komponent służący do dostarczania i uruchomienia niechcianego oprogramowania nazywać będziemy downloaderem lub dropperem, różnica jest subtelna i nie będziemy w nią wnikać. Dla uproszczenia przyjmijmy natomiast, że downloader posiada większą analitykę od droppera. Sam proces rozwoju droppera/downloadera po stronie przestępcy zgodny jest zresztą z tzw. piramidą bólu, o której wspomina metodologia kill chain poruszana przez wielu obrońców, do których i ja należę. Piramidę tę definiujemy poniżej.

Piramida bólu zakłada, iż wskaźniki infekcji bliżej czubka piramidy trudniej przestępcy zmienić, a te niżej zmieniają się zwykle raz na tydzień lub nawet w odstępie godzinowym. Ta teoria jest o tyle istotna, iż będziemy chcieli dowiedzieć się więcej o analizowanej próbce, niż tylko numer IP, domena czy suma kryptograficzna pliku. Metodologia kill chain została zaadoptowana do teorii cyber obrony przez LockheedMartin i z powodzeniem jest stosowana przez wiele zespołów skupiających się na obronie. Zakłada ona, że eliminacja lub utrudnienie wcześniejszych faz ataku powoduje eliminację lub utrudnienie kolejnych faz u przestępcy. W tym opracowaniu skupimy się na wykrywaniu, utrudnianiu i/lub powstrzymaniu fazy dostarczania (z ang. Delivery) niechcianego oprogramowania na końcową stację użytkownika.

Czas to pieniądz

Aby zrozumieć cały proces ataku i skutecznie go powstrzymać, trzeba zrozumieć biznes, co do którego stosowane jest niechciane oprogramowanie. W kolejnych akapitach zobaczymy, iż niechciane oprogramowanie wcale nie musi być skomplikowane, aby było skuteczne. Czas skutecznego działania, czy też czas, po którym zespół obrońców wykrywa i powstrzymuje niechciane oprogramowanie można przeliczyć na pieniądze. Z jednej strony przestępca zdobywa więcej danych, które może sprzedać lub też fizycznie kradnie więcej środków ofierze. Z drugiej strony obrona generuje więcej kosztów w aspektach reputacyjnych, odszkodowawczych, posprzątania po ataku (analiza powłamaniowa, poprawienie procesów, aby były bardziej bezpieczne, czy też zatrudnienie większej ilości analityków dla poprawy jakości procesów bezpieczeństwa). Dochodzimy tutaj do fundamentu stosowania zaciemniania kodu z punktu widzenia przestępcy. Zanim wyjaśnimy ten termin ustalmy, że proces zaciemnienia kodu z punktu widzenia przestępcy ma za zadanie wygenerowanie dla niego większych zysków poprzez opóźnienie analityki po stronie obrońców, przynajmniej jeśli chodzi o języki skryptowe. Pobocznym czynnikiem jest ominięcie mechanizmów sygnaturowych IPS, antywirusa itp. Narzędzia zaciemnienia kodu dla jednego droppera/downloadera dadzą zawsze inny kod w wyniku, więc antywirus nie ma tu szans. Język JavaScript należy do klasy interpretowalnych języków programowania, a więc proces zaciemnienia kodu z założenia będzie niedoskonały z uwagi na to, iż zaciemniony lub zaszyfrowany i przetworzony kod na końcu i tak musi być odtworzony do postaci takiej, którą rozumie interpreter. Innymi słowy zdjęcie zaciemniena w tym wypadku to kwestia czasu i w tych granicach będziemy poruszać się dalej.

Zaciemnienie kodu

Teoria

Zaciemnienie kodu, czy też transformacja języka interpretowalnego z punktu widzenia teorii może być przeprowadzona na trzech poziomach:

  • Transformacja wyglądu – zmiany nazw identyfikatorów, zmiana formatowania, usuwanie komentarzy.
  • Transformacja danych – rozdzielenie zmiennych, konwersja statycznych danych do procedury, zmiana kodowania, zmiana długości życia zmiennej, łączenie zmiennych skalarnych, zmiana relacji dziedziczenia, rozłam/łączenie tablic, zmiana porządku instancji zmiennych / metod / tablic.
  • Transformacja kontroli – zmiana przebiegu, rozszerzenie warunków pętli, zmiana kolejności komend / pętli / wyrażeń, metody, ogólnikowe wyrażenia, klonowanie metod.

Istnieje wiele narzędzi, lepszych czy gorszych, dostępnych przez przeglądarkę czy też instalowanych, darmowych czy płatnych do wykonania takiego zaciemnienia na kodzie JavaScript. Przykłady:

Niestety narzędzia służące do procesu zdjęcia zaciemnienia są na wczesnym etapie rozwoju. Jest wiele pomysłów, jak to robić. Nie będziemy się tym zajmować w tym opracowaniu. My wykorzystamy do tego narzędzia sandboksowe (i pokażemy ich pewną ułomność) oraz narzędzia półautomatyczne pracujące na leksemach języka programowania.

Zaciemnienie kodu, dobre czy złe?

Sam proces zaciemnienia kodu może być dobry i przydatny. Warto go znać od strony programisty dla “swojego zawodowego profesjonalizmu”. Powód tego jest banalny, proces zaciemnienia kodu z punktu widzenia programisty/firmy developerskiej może być przydatny do:

  1. Ochrony wartości intelektualnej. Stosowne opracowanie znajduje się pod tym linkiem.
  2. Spełnienia zaleceń regulatorów i standardów bezpieczeństwa (OWASP)

Ekstrakcja przykładu [praktyka – faza 0]

Przechodząc do zadań analitycznych, powinno się przyjąć pewne standardy bezpieczeństwa pracy z niechcianym oprogramowaniem. Ja przyjmuję następujące:

  1. Nie pracujemy na komputerze, który uznajemy za wrażliwy.
  2. Staramy się zachować zasadę heterogeniczności środowiska. Analizę wykonujemy na systemie operacyjnym oraz środowisku, które różni się od środowiska właściwego dla detonacji próbki. W tym wypadku analizy dokonamy na środowisku Linux narzędziami napisanymi głównie w pythonie.

Pozyskanie szablonu poczty elektronicznej z kampanii

Zespół bezpieczeństwa wykrył i dostał do analizy pocztę elektroniczną zawierająca załączniki oraz podobną treść.

Widać, że przestępcom się śpieszy – zmniejszają czas pozostały użytkownikowi na otwarcie faktury/pliku. Taka niskich lotów socjotechnika. Załóżmy, że posiadamy narzędzia statystyczne typu Grafana czy Elastic, które wytypowały potencjalnie złośliwą korespondencję. Pozyskaliśmy pierwsze wskaźniki infekcji (szablon poczty elektronicznej stosowanej w kampanii rozsyłającej złośliwą komunikację ze zmiennym czasem nakłaniającym użytkownika do otwarcia załącznika, spam przyszedł z adresu „rc@miran-wafel.com.pl”). Robimy zrzuty ekranu do artykułu edukacyjnego dla użytkowników. Szablon pozbawiony załączników możemy dostarczyć operatorom serwerów pocztowych celem konfiguracji ich narzędzi sieciowych i bezpieczeństwa w trybie prewencji na tę kampanię. Edukacja użytkownika końcowego, ale także zespołów IT, to ważna rzecz w całym procesie. My zajmujemy się dalszą analizą.

Pozyskanie próbki złośliwego oprogramowania

Wypakowujemy w środowisku Linux wszystkie załączniki z całej korespondencji elektronicznej dotyczącej tej kampanii. Oprogramowanie munpack potrafi rozpakować załączniki MIME. Zdarza się, iż przestępcy używają różnych technik i narzędzi zaciemnienia kodu, adresów C2 służących do dystrybucji docelowego niechcianego oprogramowania aplikowanego przez dropper/downloader. Taktyka ta zwiększa szansę przeżywalności dystrybucji, bo możemy przeoczyć część złośliwej kampanii. Procesowi analizy poddajemy więc całą dostępną kampanię, a nie jej wyrywek w formie jednego emaila.

Analiza 1 – * (jeden do wielu)

Sprawdzamy, czy mamy do czynienia z jednym czy z wieloma komponentami, które mają za zadanie dostarczyć i uruchomić niechciane oprogramowanie na stacji użytkownika końcowego. Zrobimy to licząc sumę kryptograficzną wszystkich załączników. Jak widać nasze zadanie jest mniej złożone. Czeka nas analiza jednego pliku.

Nie ufaj, to podstawa

Jak widzimy to nie RAR, a plik ACE. Użycie egzotycznego programu kompresującego ma za zadanie oszukanie narzędzi monitorowania oraz użytkownika końcowego. W większości przypadków użytkownik wybierze najprostsze i najszybsze rozwiązanie ściągając dowolny program do rozpakowania tego pliku lub będzie klikał na obecny do czasu, aż nie dostanie pozytywnego dla siebie komunikatu. Niektóre pakery miały też błędy, które pozwalały po kliknięciu dwa razy w spakowany plik wypakować i uruchomić zawartość.

Wykorzystaliśmy narzędzie unace.

Po rozpakowaniu otrzymaliśmy plik JSE (JScript Encoded File). Ten typ pliku został wymyślony przez Microsoft, aby mieć możliwość zakodowania zarówno kodu w języku JavaScript jak i Visual Basic do jednego wspólnego formatu, który może być automatycznie uruchamiany w samym systemie operacyjnym lub przeglądarce Internet Explorer bez potrzeby instalacji innych narzędzi czy interpreterów. Interpretacją formatu jse zajmują się narzędzia wscript.exe lub cscript.exe, domyślnie dostarczane z systemem Windows. Przestępcy korzystają z tej drogi. W środowisku Linux może być problem z odkodowaniem pliku jse. Wykorzystamy do tego narzędzie decoder.c z pakietu interpretera JavaScriptu box-js. Rozpakowujemy więc JScript Encoded File do JavaScript.

Wykorzystaliśmy narzędzie box-js i jego dekoder.c

Odciemnienie z wykorzystaniem sandboksa [praktyka – faza 1]

Sandbox – narzędzie automatyczne, które potrafi w odizolowanym środowisku uruchomić próbkę kodu i zapisać wszelkie informacje na temat zmiany tego środowiska w logach. Mądrzejsze sandboksy czasami jeszcze wyciągają wnioski i korelują dane. Osoby stosujące do pracy zawodowej narzędzia sandbox powinny wziąć dwa aspekty pod uwagę:

  1. Deweloperzy piszący niechciane oprogramowanie wiedzą o sandboksach i stosują metody unikania analizy swojego dzieła przez te narzędzia. Metody te są zwykle trywialne, ale skuteczne. Obejrzymy to na przykładzie, patrząc jak downloader sprawdza czy na liście procesów środowiska, w którym został uruchomiony, nie ma procesu o nazwie oznaczającej uruchomienie w środowisku wirtualnym.
  2. Sandboksy produkują masę logów, podobnie jak rejestratory CCTV produkują masę filmów. To zaleta, ale i wada. Analityk musi to wszystko przeczytać i wyciągnąć odpowiednie wnioski, a na koniec wymyśleć mechanizm prewencji i detekcji oraz powstrzymać atak. A “czas to pieniądz”.

Patrząc na obydwa punkty, jeśli organizacja chce skutecznie walczyć z niechcianym oprogramowaniem musi wydać pieniądze na dobrego analityka, który pomimo utrudnień z kroku pierwszego powstrzyma atak albo w punkcie drugim będzie wiedział jak zinterpretować logi i również efektem będzie powstrzymanie ataku. Mówimy o niechcianym oprogramowaniu lub jego komponencie, który z założenia jest zaprojektowany tak, aby antywirus go nie wykrył. Dodatkowo stosuje zaciemnienie kodu, aby ominąć mechanizmy sygnaturowe antywirusa oraz wydłużyć czas pracy analityka.

SEKOIA DROPPER ANALYSIS

Jak sama nazwa wskazuje służy do analizy dropperów/downloaderów. Narzędzie nastawione na technologie JavaScript/VBScript/PDF, dokumenty Microsoft Office. Potrafi zinterpretować kod i zapisać próby zmiany systemu operacyjnego do logu. Korzysta przy tym z szeregu narzędzi analitycznych, których sercem jest box-js. Z zamysłem piszemy tutaj o interpretacji, a nie o uruchomieniu próbki (w przeciwieństwie do innych sandboksów, podanych niżej). Ma to zaletę taką, iż jest nikła szansa na uruchomienie niechcianego oprogramowania poza środowisko analityczne. Zaletą interpretacji jest poprawniejsza korelacja i wyciąganie wniosków o analizowanym komponencie. Wadą natomiast jest ograniczenie polegające na tym, iż możemy zinterpretować tylko to, co rozumie interpreter. Innymi słowy, jeśli box-js nie ma w swoim kodzie funkcji, modułu, komponentu ActiveX do interpretacji leksemu języka programowania (np. w JavaScript pdfdoc(…) ) to jego praca zakończy się błędem. Narzędzie to nie zawsze zadziała. Spróbujmy więc użyć narzędzia sekoia na naszej próbce:

Co widzimy:

Jak widać narzędzie nie znalazło obiektu pdfdoc. Fakt ten spowodował zakończenie pracy z tym interpreterem, ale pozyskaliśmy kilka wskaźników infekcji:

  • Oprogramowanie korzysta z wscript.exe,
  • Oprogramowanie Korzysta z technologii ActiveXObject i jej komponentów FileSystemShell, ADODOB, Shell, Msxml2.ServerXMLHTTP,
  • Oprogramowanie sięga do katalogu Temp użytkownika,
  • Oprogramowanie sięga do katalogu Startup użytkownika oraz sprawdza czy istnieje tam plik fb.jse,
  • Listuje procesy i informacje o systemie operacyjnym z wykorzystaniem technologii Windows Management Instrumentation (WMI).

Z tych bogatych informacji wiemy już, że nie mamy do czynienia z dropperem a raczej downloaderem. Wskazuje na to zaawansowana, ale prosta logika komponentu złośliwego.

REVERSE.IT

Jest to typowy sandbox uruchamiający próbkę. Pozyskaliśmy adres IP 216.58.213.142 i port 80 wykorzystywany przez złośliwe oprogramowanie, natomiast nie mieliśmy żadnych danych na temat wykorzystanej przez przestępców technologii. Nie mieliśmy też informacji, jak oraz czy złośliwe oprogramowanie stosuje jakieś techniki dające mu przeżywalności restartu na maszynie użytkownika. Zwróćmy uwagę na stopień wykrywania złośliwego kodu przez oprogramowanie antywirusowe.

VIRUSTOTAL

VirusTotal – to narzędzie z wieloma silnikami antywirusowymi. Wysyłając tam niechciane oprogramowanie poznamy informację na temat tego, który antywirus wykrywa nasz złośliwy komponent.

Detection ratio: 0 / 59

0 / 59 antywirusów wykryje tę aplikację – przykra świadomość. Przy okazji pokazuje to prawdziwość tezy głoszonej przez profesjonalistów ds. obrony, „iż antywirusy, nawet te najlepsze już nie wystarczają. Co nie oznacza, że nie należy ich stosować”

JOESandbox

To dość zaawansowane narzędzie sandboksowe, które potrafi korelować logi i wyciągać samo wnioski. Przyjrzyjmy się wynikom pracy tego narzędzia na przykładzie kilku wspomnianych kampanii w tym opracowaniu:

  1. Kampania z 15.12.2017 PL086563411_PDF.ace (wykrywalność antywirusów na poziomie 5%, analiza w sandboksie zakończona błędem). Oczywiście może to też być spowodowane problemem z dekompresją próbki
  2. Kampania z 14.12.2017 faktury_pdf.rar (wykrywalność antywirusów po dobie na obecności downloadera 10% – analiza w sandboksie zakończona błędem). Oczywiście może to też być spowodowane problemem z dekompresją
  3. Kampania z 08.12.2017 PDF-Faktura-037772.jse (wykrywalność antywirusów na poziomie 20%, analiza zakończyła się sukcesem, raport w zasobach do tego opracowania)Zachowanie downloadera z tej kampanii obrazuje graf:

Zebranie wskaźników infekcji z sandboksów

Złosliwe oprogramowanie realizuje następujące funkcje:

  • komunikuje się z IP: (zależne od kampanii&),
  • listuje procesy w systemie operacyjnym,
  • listuje informacje o systemie operacyjnym,
  • wykonuje operacje w wymienionych niżej lokalizacjach:
    • Folder2[21](C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup)
    • Scripting.FileSystemObject[14].FileExists(C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\fb.jse)
    • 8 Dec 07:00:37 – WScript.Shell[17].ExpandEnvironmentStrings(%TEMP%) => C:\Users\User\AppData\Local\Temp
  • korzysta z technologii:
    • 8 Dec 07:00:37 – ActiveXObject(Scripting.FileSystemObject)
    • 8 Dec 07:00:37 – WScript.CreateObject(WScript.Shell)
    • 8 Dec 07:00:37 – ActiveXObject(ADODB.Stream)
    • 8 Dec 07:00:37 – ActiveXObject(Shell.Application)
    • 8 Dec 07:00:37 – ActiveXObject(Msxml2.ServerXMLHTTP)
    • Uruchamia interpreter wscript.exe i startuje procesy cmd.exe oraz certutil.exe

Podsumowując, wiele narzędzi sandbox zakończyło analizę błędem a te, które dostarczyły skutecznie wskaźniki infekcji, nie podały logiki działania droppera/downloadera. Analizując niechciane oprogramowanie w narzędziach automatycznych powinniśmy wyciągać wnioski na podstawie wielu źródeł wiedzy.

Odciemnienie JavaScript półmanualne [praktyka – faza 2]

W rozdziale 2.3 został wygenerowany poprawny kod JavaScript komponentu złośliwego. Od tego momentu spróbujemy zastosować analizę półmanualną, i zobaczymy, czego nowego się dowiemy o tym oprogramowaniu. W analizowanej próbce widzimy podstawowe fragmenty składni typu break, catch, try, pętle, if języka programowania JavaScript.

Mamy 0,5 MB tekstu w jednej linii do analizy. Postaramy sobie z tą ilością poradzić w kolejnych rozdziałach. Ze względu na możliwości współczesnych przeglądarek blok kodu znajdziecie w archiwum z materiałami.

Zdejmujemy zaciemnienie wyglądu (http://jsbeautifier.org/)

Wklejamy treść pliku z poprzedniego punktu do narzędzia i wykonujemy standardowe “wygładzanie” na stronie jsbeautifier.org. Narzędzie jsbeautifiler ma również stosowne implementacje konsolowe. Po przetworzeniu otrzymujemy uporządkowany blok kodu, który także znajdziecie w archiwum z materiałami.

Mamy zatem 0,5 MB tekstu do analizy. To 24 tysiące linii kodu. Widzimy już strukturę języka JavaScript. Kod źródłowy kojarzy się z jakimś automatem do zaciemniania kodu, a wartości podane na końcu pliku z czasem generacji kodu w tym automacie. Oczywiście są to wyłącznie przypuszczenia. Nawet jeśli uda się ustalić, co to za automat, to z reguły takie narzędzia pracują tylko w jedną stronę. Zaciemniają kod źródłowy, ale już nie zdejmują tego zaciemnienia.

Zdejmujemy zaciemnienie danych i kontroli

Narzędzia:

Przygotowania i omówienie narzędzi

  • translate.py – to narzędzie, które przyjmuje następujące parametry:translate.py -f -s decode-3.py PDF-Faktura-037772_js2.txt Decode
    • -f – przetwórz cały plik tekstowy
    • -s <skrypt> z zastosowaniem skryptu o podanej nazwie jako parametr
    • Dalej jest plik tekstowy, który będzie naszymi danymi oraz polecenie Decode

    Narzędzie transalte.py wykorzystuje w swoim pliku konfiguracyjnym funkcję pythona “re.sub(regexp,uruchamiana funkcja, dane,flagi))”, która gdy dopasuje wyrażenie regularne to potrafi uruchomić / wykonać akcję na danym dopasowanym fragmencie tekstu.

  • https://pythex.org/ – to narzędzie, które posłuży nam do konstruowania wzorców wyrażeń regularnych. Uwaga jest taka, że nie skupiamy się tutaj nad szybkością czy jakością samych wyrażeń regularnych, a na dopasowaniu globalnym do zaciemnionego kodu, celem zdjęcia tego zaciemnienia.
  • https://jsfiddle.net/ – to narzędzie posłuży nam do “upewniania się”, że dobrze rozumiemy analizowany kod. Możemy w nim zasymulować działanie fragmentu niechcianego oprogramowania w interpreterze JavaScript.
Zamiana ship33 na String[“fromCharCode”]

W tym przykładzie widzimy, że narzędzie użyte do zaciemnienia kodu stworzyło sobie zmienną ship33 z przypisaną funkcją String[“fromCharCode”] i używa zmiennej ship33 wszędzie tam gdzie potrzebuje zastosować tę funkcję.

Korzystając z notepadqq lub narzedzia sed zamieńmy wszystkie wystąpienia funkcji shipp na jej odpowiednik JavaScript String[“fromCharCode”]. Krok może banalny, ale lepiej będzie się konstruowało wyrażenie regularne.

Zdejmowanie zaciemnionych danych

Przeglądając plik złośliwego oprogramowania zauważamy, że mamy “mnogość funkcji”:

1.Sprawdźmy, co ona robi:

Uruchamiając ten fragment kodu widzimy, iż służy on wyłącznie wygenerowaniu jednego znaku ASCII, w tym wypadku literki „t”

 2. Konstrukcja wyrażenia regularnego

Wyrażenie regularne “łapiące tę funkcję” wygląda następująco.

Oczywiście można to upraszczać, przyśpieszać, ale pamiętajmy, że “czas to pieniądz”. Naszym celem jest skuteczne dopasowanie wyrażenia regularnego.

Teraz wiemy dwie rzeczy. Po pierwsze, analizowana funkcja zwraca jeden znak i mamy wyrażenie regularne, które dopasowuje nam się do tej funkcji. Skonfigurujmy więc translate.py i uzyskujmy literki zamiast tych funkcji.

Funkcja Detonaton2 zinterpretuje nam fragment języka JavaScript, który podstawi się pod to wyrażenie regularne na danych d.

Przejdźmy do omówienia teraz funkcji Detonation2. Ma ona jeden argument oMatch, który jest tym, co dopasowało się do wyrażenia regularnego. Wykorzystując komponent EvalJs uruchamiamy dopasowany tekst w interpreterze JavaScript. Przed uruchomieniem musimy jeszcze dodać do tego tekstu funkcję “ulrich”, która też jest wykorzystywana w całym kodzie i powiedzieć, że to, co dopasowało się do wyrażenia jest funkcją w języku JavaScript (var a=b()). Na końcu zwracamy zdetonowany tekst, jako string “opakowując” go cudzysłowami (zakładamy i przy okazji walidujemy zwracaną informację jako łańcuch znaków zawierający jedną literkę). To co uzyskujemy nadaje się już do wklejenia w ten artykuł.

Możemy już przeczytać rzeczy, które wcześniej były ukryte, ale łatwiej będzie, jeśli usuniemy sobie fragment “ + “.

Czyszczenie łańcuchów znaków typu „S” + „c” + „r” + „i” + „p” + „t” + „

Operację czyszczenia wykona za nas poniższa funkcja narzędzia transalte.py

Usuwa ona podciągi cudzysłów, spacja, plus, spacja, cudzysłów z analizowanego tekstu. Wynik znajdziemy w poniższym kodzie:

Po zapoznaniu się z wynikiem widzimy już podobieństwa i wskaźniki infekcji wykryte w punkcie 3.1 w narzędziu SEKOIA

Dekodowanie tekstu unicode

Konwertujemy niezgodny składniowo string do postaci: identyfikator, spacja, znak u, kod szesnastkowy

Usunięcie zbędnych spacji, tabulacji, nowych linii z unicode

Zamiana unicode na łańcuch znaków

Należy jeszcze uściślić, po co przestępcy wprowadzają błędy składniowe w unicode. Kod JavaScript został napisany dla interpretera wscript/cscript. Akurat ten interpreter radzi sobie z takimi błędami składniowymi i koryguje brak spacji po słowie new. Zabieg użyty przez przestępców jest niskiego lotu, ale skutecznym sposobem walidacji uruchomienia swojego narzędzia w środowisku, w którym ma być ono uruchomione.

Po wykonaniu tych wszystkich kroków otrzymujemy kod downloadera napisanego w JavaScript bez zaciemnienia:

Dodatkowe wskaźniki infekcji pozyskane z metody półautomatycznej

  1. Adres URL wraz z jego parametrami. Złośliwe oprogramowanie raportuje pod ten adres kolejne etapy swojego przetwarzania oraz pobiera z niego docelowe niechciane oprogramowanie, które instaluje na stacji docelowej użytkownika.
  2. Sprawdzenie środowiska pracy, w którym uruchamiany jest złośliwy kod. Widzimy, że skrypt poszukuje:
    1. specyficznego oprogramowania używanego przez osoby analizujące złośliwe oprogramowanie np. lordPE.exe, ImmunityDebuger.exe
    2. identyfikacji środowiska wirtualnego np. VBoxService, VBoxTray.exe, vmware
    3. użytkownika systemu Winidows o nazwie Emily. Prawdopodobnie któryś z sandboksów ma standardowy obraz Windowsa z takim użytkownikiem
    4. długość spisu procesów zamieniona do jednego łańcucha znaków jest dłuższa niż 500 znaków – prawdopodobnie złośliwe oprogramowanie w ten sposób chce wykluczyć obrazy sandboksowe zrealizowane na systemie operacyjnym, którego użytkownik nie używa do standardowej pracy.

    W przypadku wykrycia niekorzystnego środowiska pracy widzimy wywołanie niezdefiniowanej funkcji pdfdoc[„alert”], które jak się przekonaliśmy w rozdziale „SEKOIA DROPPER ANALYSIS” przerywa działanie interpretera box-js.

  3. Złośliwe oprogramowanie zamyka przeglądarkę Google Chrome klienta oraz wszystike jej potomne instancje w systemie operacyjnym

Wnioski

Jak widzimy downloader pobiera i sprawdza czy ma odpowiednio długi łańcuch znaków z informacji zwracanej na podstawie listy procesów w systemie Windows. Sandboksy z racji swojej logiki z reguły mają obrazy systemów operacyjnych, na których nie pracuje użytkownik, a sam obraz jest niszczony po detonacji próbki. W takim systemie operacyjnym ten łańcuch znaków będzie krótszy, niż przy normalnym użytkowaniu takiego systemu operacyjnego. Oczywiście takie obrazy i konfigurację sandboksa można poprawić, ale jak widać przestępcy dokładnie znają te narzędzia i przewidują takie działania. Widzimy sprawdzenie czy na tym systemie nie ma procesów pythona, VirtualBoxa, VMWare itp. Widzimy też, że niechciane oprogramowanie zamyka użytkownikowi po cichu przeglądarkę Chrome. Pozyskaliśmy również adres URL, z którego ściągane jest docelowe niechciane oprogramowanie. Adres ten służy również do raportowania etapu pracy downloadera znajdującego się u użytkownika. Analiza półautomatyczna ma jeszcze jedną zaletę, w przeciwieństwie do sandboksa. Operator droppera nie wie, że jego oprogramowanie zostało zanalizowane. Sandboksy uruchmiają próbki złośliwego oprogramowania, co oznacza również próbę połączenia z operatorem złośliwego oprogramowania. Niektóre sandboksy mogą używać do połączenia sieciowego sieci TOR lub posiadają kilka klas adresów IP. Przestępcy mogą jednak monitorować tę komunikację i wiedzieć na jakim etapie jest ich kampania lub odcinać analityków w komunikacji uniemożliwiając im pozyskanie próbki docelowej.

Wykrywanie niechcianego oprogramowania dzięki wskaźnikom infekcji

Wykorzystując liczne narzędzia analityczne, takie jak HIDS, SYSMON, osquery, SIEM i analiza logów ze stacji końcowych, możemy wykrywać symptomy downloadera/droppera (i to nie tylko po adresach IP czy też domenie). W tym opracowaniu nie będę opisywał tego procesu, ale osoby z działów bezpieczeństwa, które zapoznają się z wymienionymi wyżej narzędziami z pewnością będą potrafiły dokonać skutecznego wdrożenia detekcji bazującej na wymienionych narzędziach.

Blokowanie niechcianego oprogramowania dzięki wskaźnikom infekcji

Po wykryciu niechcianego oprogramowania możemy jako obrońcy podjąć decyzję o blokowaniu downloadera/droppera (ta decyzja również powinna być przedmiotem analizy ryzyka), z uwagi na dwa aspekty:

  1. Będzie trzeba przeprowadzić utwardzanie stacji użytkownika pod względem bezpieczeństwa. Ilość tych operacji jak i końcowy rezultat może wprowadzić przerwę w działaniu procesów w organizacji. Zapewne ważne też będzie szkolenie użytkownika końcowego, aby wiedział jak się zachować w przypadku takiego komunikatu:
  2. Można próbować zatrzymywać downloader już w kampanii, ale wymaga to postawienia prawdopodobnie odpowiednich urządzeń sieciowych i zapewne implementacji tego zadania po ICAPie. Implementacja taka prawdopodobnie wymagała będzie również zaawansowanej analityki prowadzonej w zespole bezpieczeństwa.

Prewencja i utwardzanie stacji pod względem bezpieczeństwa.

Szersza wiedza na temat dropperów i downloaderów daje nam szersze pole manewru w prewencji. A prewencja ma dwa filary:

  1. Edukacja użytkownika, ale często też administratora. Zarówno użytkownik jak i administrator jako pierwsi będą widzieć skutki takiego niechcianego oprogramowania, a w przypadku skutecznego utwardzenia infrastruktury pod względem ochrony będą również dostawali komunikaty z takiej detekcji. Uświadamiając odpowiednio te działy osiągniemy prewencję, ale co ważniejsze bardzo często powiadomią nas również o nowym zagrożeniu, skutkującym niestandardowym zachowaniem stacji końcowej
  2. Utwardzanie stacji pod względem bezpieczeństwa.Jest wiele narzędzi wspierających i poradników z tym związanych. Przykładem nich będą wytyczne CIS. Dodatkowo można rozważyć utwardzenie z wykorzystaniem narzędzi:
    1. wyłączenie wscript/cscript na stacji końcowej
    2. instalacja oprogramowania EMET
    3. utwardzanie pakietu MS Office pod względem bezpieczeństwa
    4. file screening

    To tylko pierwsze kroki techniczne. Przestępcy nie próżnują i wymyślają nowe, skuteczne sztuczki np. PowerPoint, który miał złośliwy kod JavaScript uruchamiany przez najechanie myszą na element strony w tym pakiecie. W krokach utwardzania nie poprzestajemy więc wyłącznie na etapie technologicznym. Rozmowa trójstronna: bezpiecznik, administrator, biznes często skutkuje wypracowaniem najtańszych i najskuteczniejszych rozwiązań.

  3. W ostatnim czasie pojawiło się też narzędzie hardentools dla Windowsa. Stosowanie takich narzędzi nie zwalnia decydentów od analizy ryzyka i całości zagrożenia.

Dzielenie się wskaźnikami infekcji ze społecznością analityków i próby poznania aktorów

Skoro jesteśmy już analitykami złośliwego oprogramowania to warto podzielić się zdobytą wiedzą z szerszymi organizacjami z wykorzystaniem takich narzędzi jak MISP (Malware Information Sharing Platform and Threat Sharing).

Cele wymiany informacji są dwa:

  1. Więcej wskaźników infekcji w tym samym czasie. Przestępcy ewoluują, zmieniają wskaźniki infekcji, szczególnie te najniżej położone w piramidzie bólu. Dzięki większej liczbie analityków możemy wzbogacać naszą wiedzę, dowiedzieć się czy tylko Polska jest atakowana. Możemy też zobaczyć inne ciekawe aspekty np. czy niechciane oprogramowanie na komputerach z Windowsem w rosyjskiej wersji językowej się nie uruchomi.
  2. Dzięki wzbogacaniu oraz obserwowaniu niechcianego oprogramowania w czasie można poznać aktorów stojących za kampaniami niechcianej korespondencji.

Oczywiście wymiana powyższa to decyzja, która również powinna być podejmowana dzięki analizie ryzyka w ofensywnych zespołach bezpieczeństwa. Natomiast nie zmienia to faktu, że powyższa platforma może być również skutecznie uruchomiona w obrębie organizacji na potrzeby tylko i wyłącznie własnego zespołu analitycznego.

Podsumowanie

Mam nadzieję, że przybliżyłem Czytelnikowi cały proces analizy jednego z komponentów niechcianego oprogramowania. Wskazałem jakie decyzje musi podjąć dział bezpieczeństwa i gdzie robi się analizę ryzyka dla tego typu zagrożeń. Automatyczne narzędzia takie jak sandboksy są tak dobre jak analityk, który ich używa. Narzędzia automatyczne często dają najniższe wskaźniki infekcji z piramidy bólu, natomiast dają je relatywnie szybko. W zasobach do artykułu znajdziecie analizę z trzech kampanii z ostatniego czasu, które jak się okazuje stosują ten sam downloader, natomiast zaciemnienie kodu jest różne. W przeciągu roku ten komponent złośliwy odwiedzał naszą organizację ponad 10 razy. Powstrzymanie go na innym poziomie niż IP jest więc dobrym pomysłem, ale również wyzwaniem dla zespołu bezpieczeństwa.

Pliki omawiane w analizie (hasło: infected).

Dodatkowe materiały:

Robert Tomaszewski
Bezpiecznik “Defender” prywatnie i zawodowo od ponad 20 lat. Związany z sektorem finansowym, był administratorem, wdrożeniowcem. Prelegent na spotkaniach OWASP Polska Warszawa. Posiada certyfikat NGCERET-2006-25823, były członek ISSA (3139401). Obecnie zajmuje się analizą niechcianego oprogramowania w zespole obrony w jego pierwszej fazie. Kontakt: bolo2006@gmail.com