Tag: analysis

Analiza Sage 2.0

Data publikacji: 14/02/2017, Jarosław Jedynak

logo

Wstęp

Sage jest nową rodziną ransomware, wariantem CryLockera. Obecnie jest rozprowadzany przez tych samych aktorów, którzy zazwyczaj rozsyłają Cerbera, Locky’ego oraz Sporę.

Głównym wektorem infekcji jest malspam i złośliwe załączniki. Emaile z kampanii są puste, bez żadnego tekstu i zawierają jedynie plik .zip. W załączniku znajduje się złośliwy dokument programu Word z makrem pobierającym i instalującym ransomware.

Po uruchomieniu ransomware’u zostaje pokazane okno UAC Windowsa, które jest wyświetlane w pętli do momentu, aż użytkownik ostatecznie zgodzi się na nadanie praw administracyjnych aplikacji.

Na końcu rozpoczynany jest proces szyfrowania i pliki są przetwarzane:

Wiadomość z żądaniem okupu kieruje nas do panelu w sieci Tor, ale zanim możemy się zalogować musimy rozwiązać captchę:

W końcu jesteśmy witani przez „przyjazny użytkownikowi” panel:

Można nawet porozmawiać z twórcami malware (ale nie testowaliśmy tej opcji):

Co ciekawe, próbka nie usuwa się z systemu po infekcji, ale kopiuje się do folderu %APPDATA%\Roaming, i szyfruje wszystkie pliki ponownie po każdym restarcie komputera (do momentu aż zostanie zapłacony okup).

Analiza techniczna

Po tym krótkim wprowadzeniu, skoncentrujemy się bardziej na stronie technicznej, ponieważ Sage 2.0 nie jest zupełnie wtórną rodziną i kilka rzeczy nadaje się do opisania.

Główna funkcja programu wygląda tak:

Jak widzimy, po drodze wiele rzeczy jest sprawdzanych i komputer jest identyfikowany na kilka sposobów. Ciekawsze rzeczy jakie znaleźliśmy to m.in.:

Parametr służący do debugowania

Prawdopodobnie nie wszystko w kodzie działało od razu jak trzeba, ponieważ istnieje w nim parametr (przekazywany z linii poleceń) służący do testowania działania konfiguracji malware’u:

I rzeczywiście, jeśli zostanie przekazany, robi to co powinien:

Prawdopodobnie twórca zapomniał usunąć ten fragment kodu z ostatecznej wersji, bo funkcja ta jest bezużyteczna poza okresem programowania.

Sprawdzenie języka

Twórcy Sage’a 2.0 lubią niektóre kraje bardziej niż inne:

Funkcja ta sprawdza layouty klawiatury użytkownika:

    • next == 0x23 -> białoruski
    • next == 0x3F -> kazachski
    • next == 0x19 -> rosyjski
    • next == 0x22 -> ukraiński
    • next == 0x43 -> uzbecki
    • next == 0x85 -> sacha (jakucki)

Niestety, język polski nie trafił na listę wyjątków Sage’a w obecnej wersji. Może w przyszłości?

Namierzanie użytkownika

Sage próbuje poznać lokalizację swojego hosta odpytując maps.googleapis.com z aktualnym SSID sieci Wi-Fi oraz adresem MAC:

Plik kanarka

Przed szyfrowaniem próbka sprawdza czy istnieje specjalny plik:

Dzięki temu twórcy malware nie muszą się przejmować przypadkowym uruchomieniem swojego dzieła i zaszyfrowaniem własnego dysku. Ale jeśli plik nie zostanie znaleziony, szyfrowanie jest rozpoczynane.

Lista szyfrowanych rozszerzeń

Nie są szyfrowane oczywiście pliki – tylko te z rozszerzeniami pasującymi do whitelisty:

Szyfrowanie

Jak zwykle to najciekawsza część kodu każdego ransomware. Sage 2.0 szczególnie wyróżnia się pod tym względem, ponieważ szyfruje pliki korzystając z kryptografii krzywych eliptycznych.

Krzywa użyta do szyfrowania to y^2 = x^3 + 486662x^x + x w polu zdefiniowanym przez 2^255 – 19, z punktem bazowym x=9. Te wartości nie są wybrane przypadkowo – ta krzywa jest zwana również Curve25519 i należy do jednych z najnowocześniejszych współczesnych metod szyfrowania. Nie tylko jest to jedna z najszybszych krzywych eliptycznych, ale jest też mniej podatna na słabe generatory losowości. Została zaprojektowana przy uwzględnieniu możliwych ataków kanałem bocznym (side channel), unika wielu potencjalnych problemów implementacyjnych oraz (prawdopodobnie) nie ma backdoora stworzonego przez żadną trzyliterową agencję.

Klucz publiczny używany podczas generacji współdzielonego sekretu jest zapisany na stałe w próbce. Dokładny kod wygląda tak (struktury i funkcje nazwane przez nas):

Jest to prawidłowa implementacja protokołu krzywych eliptycznych Diffiego-Hellmana (ECDH), ale ponieważ klucze prywatne nie są nigdzie zapisywane, sekret może odzyskać jedynie strona będąca w posiadaniu klucza prywatnego serwera.

Funkcja ta może wyglądać skomplikowanie, ale prawie wszystkie jej składowe to funkcje opakowujące prymityw ECC – nazwany przez nas CurveEncrypt. Na przykład szukanie pasującego klucza publicznego to po prostu mnożenie przez punkt bazowy (który jest równy 9, czyli jeden bajt 9 i 31 zer):

Liczenie współdzielonego sekretu jest bardzo podobne, ale zamiast stałego punktu bazowego używamy klucza publicznego:

Z powodu własności Curve25519, konwertowanie między sekwencją dowolnych losowych bajtów i kluczem prywatnym jest bardzo proste – wystarczy maskować kilka bitów i ustawić jeden:

Dodatkowo z tego powodu generowanie klucza prywatnego jest trywialne (wystarczy wylosować 32 bajty i skonwertować je do klucza prywatnego):

To wszystko jeśli chodzi o generowanie klucza. Co z szyfrowaniem plików? Użyty jest algorytm ChaCha (to chyba pierwsza rodzina szyfrująca tym algorytmem, mimo że Petya używa bardzo zbliżonego algorytmu Salsa20), a klucz ChaCha jest dopisywany do końca pliku, po zaszyfrowaniu za pomocą Curve25519:

Gdzie funkcja AppendFileKeyInfo dokleja na koniec danych zaszyfrowany klucz oraz klucz publiczny:

Nie wiemy czemu została użyta ChaCha zamiast AES – prawdopodobnie to tylko próba wyróżnienia się albo paranoja przed wyimaginowanymi tylnymi furtkami agencji rządowych.

Podsumowując, istnieją dwa zbiory kluczy plus jedna para kluczy na każdy zaszyfrowany plik:

Kiedy ransomware kończy swoje operacje, znamy tylko my_public, sh_public, fl_shared, a potrzebujemy odzyskać chachakey żeby zdeszyfrować plik – nie zrobimytego bez znajomości prywatnych części.

Ten schemat szyfrowania jest dobrze przemyślany, ponieważ umożliwia szyfrowanie offline – nie ma potrzeby łączyć się z C&C i negocjowania kluczy szyfrujących. Wystarczy klucz publiczny, zapisany na stałe w programie. Zakładając że twórcy złośliwego oprogramowania nie popełnili drastycznych błędów implementacyjnych (a nie mamy powodu podejrzewać żeby to zrobili), odzyskanie zaszyfrowanych plików jest niemożliwe. Oczywiście zawsze jest możliwość, że klucze szyfrujące zostaną wcześniej upublicznione przez kogoś.

Dodatkowe informacje

Reguły Yara:

Hashe (sha256):

    • sample 1, 362baeb80b854c201c4e7a1cfd3332fd58201e845f6aebe7def05ff0e00bf339
    • sample 2, 3b4e0460d4a5d876e7e64bb706f7fdbbc6934e2dea7fa06e34ce01de8b78934c
    • sample 3, ccd6a495dfb2c5e26cd65e34c9569615428801e01fd89ead8d5ce1e70c680850
    • sample 4, 8a0a191d055b4b4dd15c66bfb9df223b384abb75d4bb438594231788fb556bc2
    • sample 5, 0ecf3617c1d3313fdb41729c95215c4d2575b4b11666c1e9341f149d02405c05

Więcej materiałów:

Network traffic periodicity analysis of dark address space

Data publikacji: 01/08/2016, piotrb

Network traffic directed to dark address space of IPv4 protocol can be a good source of information about current state of the Internet. Despite the fact that no packets should be sent to such addresses, in practice various traffic types can be observed there, for example echoes of Denial of Service (DoS) attacks, automated port scanners or misconfiguration of some client software. Example of a DFT plotOften the packets are sent periodically, i.e. in regular intervals. This periodicity can be analyzed by applying the Discrete Fourier Transform (DFT) to the network traffic. Our report shows how such analysis can be performed and also its results. You can read the report here.

Malware na Windows i Android w jednej kampanii

Data publikacji: 22/05/2015, Łukasz Siewierski

loveletter1W dniu 7 maja 2015 zaobserwowaliśmy kolejną kampanię mailową, w której atakujący używał loga i nazwy Poczty Polskiej. Maile rzekomo miały informować o nieodebranej paczce, ale w rzeczywistości zawierały link, który po wielu przekierowaniach doprowadzał do pliku exe bądź apk (w zależności od używanej przeglądarki). Poniżej prezentujemy dokładną analizę zagrożenia zarówno na systemy Windows jak i Android.

 

Czytaj więcej

Banatrix – szczegóły techniczne

Data publikacji: 15/12/2014, Łukasz Siewierski

PL_malwareZe wszystkich „polskich” rodzin malware, które zaobserwowaliśmy w zeszłym roku, najbardziej zaawansowaną technicznie był Banatrix. Malware ten podmieniał numer konta w pamięci procesu przeglądarki. Jednak jego budowa pozwalała na dużo więcej i zostało to wykorzystane do wykradania zapisanych w przeglądarce Mozilla Firefox haseł. Poniżej znajduje się omówienie szczegółów technicznych działania oraz szczegóły dotyczące infrastruktury serwera C&C tego złośliwego oprogramowania. W komunikacji z serwerem C&C wykorzystywana jest sieć TOR co utrudnia zarówno namierzenie sprawcy jak i unieszkodliwienie serwera sterującego.
Czytaj więcej

Kupiłeś laptopa? To teraz zapłać bitcoinami!

Data publikacji: 04/07/2014, Łukasz Siewierski

PL_malwareNiedawno pisaliśmy o kampanii rozprzestrzeniającej złośliwe oprogramowanie za pomocą wiadomości e-mail podszywających się pod Allegro.pl oraz Booking.com. W jednym z etapów tej kampanii wykorzystywany był skrypt AutoIt (zwany RazorCrypt), którego celem było ukrycie ostatecznego złośliwego oprogramowania, które kradło hasła użytkownika. Wykorzystanie skryptów AutoIt w celu zaciemnienia czy zaszyfrowania złośliwego oprogramowania staje się coraz bardziej popularne wśród twórców, szczególnie niezbyt wyszukanego, złośliwego oprogramowania. Poniżej opisujemy kolejną kampanię wykorzystującą wizerunek Allegro.pl i używającą ciekawego skryptu AutoIt. Nie znaleźliśmy żadnych powiązań pomiędzy autorami obu kampanii.
Czytaj więcej