Tag: malware

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:

TorrentLocker: złośliwa faktura za telefon

Data publikacji: 24/10/2016, Paweł Srokosz

Na początku października otrzymaliśmy zgłoszenie o kolejnej kampanii spamowej, wymierzonej w klientów sieci Play i dystrybuującej oprogramowanie ransomware. Rozsyłane maile mają postać fałszywych faktur, z załączonym skryptem JS, który pobiera i uruchamia złośliwe oprogramowanie, znane pod nazwą TorrentLocker (określanym również jako Crypt0L0cker).

Czytaj więcej

GMBot: nowe sposoby na wyłudzanie danych z przeglądarek mobilnych

Data publikacji: 16/05/2016, Malgorzata Debska

Złośliwe oprogramowanie na system Android o nazwie GMBot (inna nazwa slempo) było już przez nas opisywane w październiku ubiegłego roku. Aplikacja do wyłudzania danych logowania do banku używała tzw. metody przesłonięcia aplikacji (ang. application overlay). Jest to nic innego jak zwykły atak phishingowy, w działaniu dosyć podobny do znanej metody używania webinjectów w systemach z rodziny Windows. Zgodnie z naszymi przewidywaniami, używanie przesłonięcia aplikacji stało się dosyć popularne w złośliwych aplikacjach androidowych. W ciągu ostatniego półrocza powstało wiele wersji oprogramowania swoim działaniem przypominających GMBota. W każdym przypadku przesłonięcie dotyczyło wyłącznie aplikacji zainstalowanych na telefonie (aplikacje bankowe, komunikatory, e-mail). W zeszłym tygodniu, do naszego laboratorium trafiła jednak próbka, która oprócz przesłonięcia aplikacji bankowej stara się także wyłudzić dane dostępowe do banku z mobilnej przeglądarki internetowej.

Czytaj więcej

Złośliwy iBanking – stary sposób infekcji, nowe pomysły utrudniające odinstalowanie

Data publikacji: 16/03/2016, Malgorzata Debska

W ostatnim czasie do CERT-owego laboratorium trafiła próbka złośliwego oprogramowania typu iBanking podszywającego się pod mobilną aplikację skanera antymalware’owego Trusteer Rapport. Scenariusz ataku nie jest niczym nowym, był wielokrotnie wykorzystywany w przeszłości, jednak w ostatnim czasie zauważamy wzrost ataków tego typu wymierzonych w Polskich użytkowników bankowości elektronicznej. Analizowana aplikacja okazała się dużo trudniejsza w usunięciu, a jej kod o wiele lepiej zaciemniony niż wcześniejsze programy tego typu.

Czytaj więcej

MadProtect, not that mad

Data publikacji: 03/02/2016, mak

Some weeks ago we stumbled on a packer that our tools could not break. Surprisingly, this is actually not that common since most of the malware in the wild uses some sort of RunPE technique which is relatively trivial to break using simple memory tracing.

MadProtect is not any different, it looks like a “HackingForums-grade” packer – nevertheless our tools failed to handle it properly. At first we did not look into the original binary, which was a mistake that could have saved us a lot of unnecessary effort into debugging our code. Instead, it turned out to be enough to look at the logs from tracer and binaries it produced.

The dumped binaries looked somewhat weird with a bunch of nops and other junk code which seems to do nothing. What struck us as odd was the regularity of nop-blocs: all of them seemed to be 0×10 bytes long (yes, we know we cannot count  ), and we can see a lot of 0×10 bytes writes in tracer logs: coincidence?
Czytaj więcej

Następca Banatrixa: dodatek do przeglądarki

Data publikacji: 21/01/2016, Malgorzata Debska

zorro_foxW ostatnim czasie do laboratorium naszego zespołu trafiła próbka złośliwego oprogramowania atakująca polskich użytkowników bankowości elektronicznej. Analiza tego zagrożenia daje nam podstawy twierdzić, że jest to kolejne oprogramowanie napisane przez tego samego autora (albo grupę autorów) co wcześniej opisywany przez nas Banatrix, kampania mailowa, rzekomo od Poczty Polskiej czy zeszłoroczny Slave .
Czytaj więcej

12345...