Ryuk to jeden z najbardziej znanych wariantów ransomware w ciągu ostatnich kilku lat. Od momentu swojego pierwszego pojawienia się latem 2018 roku, zebrał , szczególnie w środowisku biznesowym, które jest głównym celem jego ataków.
1. Informacje ogólne
Dokument ten zawiera analizę wariantu ransomware Ryuk oraz ładowarki, odpowiedzialnej za wprowadzenie złośliwego oprogramowania do systemu.
Ransomware Ryuk po raz pierwszy pojawił się latem 2018 roku. Jedną z cech odróżniających Ryuk od innych ransomware jest to, że jest on skierowany na atak na środowiska korporacyjne.
W połowie 2019 roku grupy cyberprzestępcze zaatakowały ogromną liczbę hiszpańskich firm przy użyciu tego ransomware.
Rys. 1: Fragment z El Confidencial dotyczący ataku ransomware Ryuk [1]
Rys. 2: Fragment z El País o ataku przeprowadzonym za pomocą ransomware Ryuk [2]
W tym roku Ryuk zaatakował wiele firm w różnych krajach. Jak widać na poniższych rysunkach, największe straty poniosły Niemcy, Chiny, Algieria i Indie.
Porównując liczbę cyberataków, możemy zaobserwować, że Ryuk dotknął miliony użytkowników i skompromitował ogromną ilość danych, co prowadzi do poważnych strat ekonomicznych.
Rys. 3: Ilustracja globalnej aktywności Ryuk.
Rys. 4: 16 krajów, które najbardziej ucierpiały z powodu Ryuk
Rys. 5: Liczba użytkowników zaatakowanych przez ransomware Ryuk (w milionach)
Zgodnie z ogólnym zasadniczym działaniem takich zagrożeń, ten ransomware po zakończeniu szyfrowania pokazuje ofierze powiadomienie o okupie, który musi być opłacony w bitcoinach na podany adres, aby przywrócić dostęp do zaszyfrowanych plików.
To złośliwe oprogramowanie zmieniło się od momentu swojego pierwszego pojawienia się.
Analizowana w tym dokumencie wersja tego zagrożenia została wykryta podczas próby przeprowadzenia ataku w styczniu 2020 roku.
Ze względu na swoją złożoność to złośliwe oprogramowanie często przypisywane jest zorganizowanym grupom cyberprzestępczym, znanym również jako grupy APT.
Część kodu Ryuk ma wyraźne podobieństwo do kodu i struktury innego znanego ransomware'u Hermes, z którym dzieli szereg wspólnych funkcji. Dlatego początkowo Ryuk wiązano z północnokoreańską grupą Lazarus, która w tamtym czasie była podejrzewana o związki z ransomware'em Hermes.
Później serwis Falcon X firmy CrowdStrike zauważył, że tak naprawdę Ryuk został stworzony przez grupę WIZARD SPIDER [4].
Istnieje kilka dowodów wspierających tę hipotezę. Po pierwsze, ten ransomware był reklamowany na stronie exploit.in, która jest znanym rosyjskim rynkiem złośliwego oprogramowania i wcześniej była związana z niektórymi rosyjskimi grupami APT.
Fakt ten wyklucza teorię, że Ryuk mógł być opracowany przez grupę APT Lazarus, ponieważ nie odpowiada to sposobowi działania tej grupy.
Ponadto Ryuk był reklamowany jako ransomware, który nie działa na systemach rosyjskich, ukraińskich i białoruskich. Takie zachowanie wynika z funkcji odkrytych w niektórych wersjach Ryuk, które sprawdzają język systemu, w którym działa ten ransomware, i zatrzymują jego działanie, jeśli system jest w języku rosyjskim, ukraińskim lub białoruskim. W końcu podczas analizy ekspertyzy maszyny, która została zhakowana przez grupę WIZARD SPIDER, odkryto kilka 'artefaktów', które prawdopodobnie były używane przy opracowywaniu Ryuk jako wariantu ransomware'u Hermes.
Z drugiej strony, eksperci Gabriela Nicolao i Luciano Martins zasugerowali, że ransomware mógł być opracowany przez grupę APT CryptoTech [5].
Wynika to z faktu, że kilka miesięcy przed pojawieniem się Ryuk ta grupa zamieściła na forum tej samej strony informację o tym, że opracowali nową wersję ransomware'u Hermes.
Kilku użytkowników forum zastanawiało się, czy CryptoTech rzeczywiście stworzyło Ryuk. Po tym zdarzeniu ta grupa broniła się i oświadczyła, że ma dowody na to, że opracowała 100% tego ransomware'u.
2. Cechy
Zaczynamy od bootloadera, którego zadaniem jest identyfikacja systemu, w którym się znajduje, aby można było uruchomić 'właściwą' wersję ransomware'u Ryuk.
Hash bootloadera jest następujący:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
Jedną z cech tego ładownika jest to, że nie zawiera żadnych metadanych, tj. twórcy tego złośliwego oprogramowania nie włączyli do niego żadnych informacji.
Czasami włączają błędne dane, aby sprawić, że użytkownik pomyśli, że uruchamia rzekomo legalną aplikację. Jednak, jak zobaczymy później, w przypadku, gdy infekcja nie zakłada interakcji z użytkownikiem (jak w przypadku tego szyfratora), przestępcy nie uważają za konieczne korzystanie z metadanych.
Rys. 6: Metadane próbki
Próbka została skompilowana w 32-bitowym formacie, aby mogła być uruchamiana zarówno w systemach 32-bitowych, jak i 64-bitowych.
3. Wektor penetracji
Próbka, która ładuje i uruchamia Ryuk, weszła do naszego systemu przez zdalne połączenie, a parametry dostępu były uzyskane dzięki wcześniejszym atakom RDP.
Rys. 7: Rejestr ataku
Przestępca zdołał zdalnie zalogować się do systemu. Następnie stworzył plik wykonywalny z naszą próbką.
Ten plik wykonywalny został zablokowany przez rozwiązanie antywirusowe przed uruchomieniem.
Rys. 8: Blokada próbki
Rys. 9: Blokada próbki
Kiedy złośliwy plik został zablokowany, przestępca próbował załadować zaszyfrowaną wersję pliku wykonywalnego, który również został zablokowany.
Rys. 10: Zestaw próbek, które przestępca próbował uruchomić
W końcu próbował załadować inny złośliwy plik przez zaszyfrowaną konsolę
PowerShell, aby obejść ochronę antywirusową. Ale również został zablokowany.
Rys. 11: PowerShell z zablokowanym złośliwym kontentem
Rys. 12: PowerShell z zablokowanym złośliwym kontentem
4. Ładowarka
Kiedy się uruchamia, zapisuje plik ReadMe w folderze %temp%, co jest typowe dla Ryuk. Ten plik to żądanie okupu, zawierające adres e-mail w domenie protonmail, który jest dość powszechny w tej rodzinie złośliwego oprogramowania: msifelabem1981@protonmail.com
Rys. 13: Żądanie okupu
Podczas wykonywania ładownika możesz zauważyć, że uruchamia kilka plików wykonywalnych o losowych nazwach. Są one przechowywane w ukrytym folderze PUBLIC, ale jeśli w systemie operacyjnym nie jest aktywna opcja „Pokazuj ukryte pliki i foldery”, to pozostaną niewidoczne. Co więcej, te pliki są 64-bitowe, w przeciwieństwie do nadrzędnego pliku, który jest 32-bitowy.
Rys. 14: Pliki wykonywalne uruchamiane przez próbkę
Jak widać na powyższym rysunku, Ryuk uruchamia icacls.exe, który będzie używany do zmiany wszystkich list kontroli dostępu ACL (Access control list), co zapewnia dostęp i modyfikację flag.
Uzyskuje pełny dostęp pod wszystkimi użytkownikami do wszystkich plików na urządzeniu (/T) niezależnie od błędów (/C) i bez wyświetlania żadnych komunikatów (/Q).
Rys. 15: Opcje uruchamiania icacls.exe uruchomione przez próbkę
Ważne jest, aby pamiętać, że Ryuk sprawdza, która wersja systemu Windows jest uruchomiona. W tym celu
przeprowadza sprawdzenie wersji za pomocą GetVersionExW, w którym sprawdza wartość flagi lpVersionInformation, wskazującej, czy bieżąca wersja Windows jest nowsza niż Windows XP.
W zależności od tego, czy masz nowszą wersję niż Windows XP, loader zapisze w folderze lokalnego użytkownika — w tym przypadku w folderze %Public%.
Rys. 17: Sprawdzenie wersji systemu operacyjnego
Zapisywanym plikiem jest Ryuk. Następnie uruchamia go, przekazując swój własny adres jako parametr.
Rys. 18: Wykonanie Ryuk przez ShellExecute
Pierwszą rzeczą, którą robi Ryuk, jest pozyskanie parametrów wejściowych. Tym razem istnieją dwa parametry wejściowe (sam plik wykonywalny oraz adres droppera), które są używane do usunięcia własnych śladów.
Rys. 19: Tworzenie procesu
Możesz również zauważyć, że jak tylko uruchomił swoje pliki wykonywalne, usuwa siebie, nie pozostawiając śladów swojego istnienia w folderze, w którym został wykonany.
Rys. 20: Usuwanie pliku
5. RYUK
5.1 Obecność
Ryuk, podobnie jak inne złośliwe oprogramowanie, stara się pozostawać w systemie jak najdłużej. Jak pokazano powyżej, jednym ze sposobów osiągnięcia tego celu jest niejawne tworzenie i uruchamianie plików wykonywalnych. W tym celu najczęściej stosowaną praktyką jest zmiana klucza rejestru CurrentVersionRun.
W tym przypadku możesz zobaczyć, że do tego celu pierwszy uruchamiany plik VWjRF.exe
(nazwa pliku jest generowana losowo) uruchamia cmd.exe.
Rys. 21: Wykonanie pliku VWjRF.exe
Następnie wprowadza polecenie RUN o nazwie "svchos". W ten sposób, jeśli chcesz w każdej chwili sprawdzić klucze rejestru, wystarczy, że nie zauważysz tej zmiany, biorąc pod uwagę podobieństwo tej nazwy do svchost. Dzięki temu kluczowi Ryuk zapewnia swoje obecność w systemie. Jeśli system nie został jeszcze zainfekowany, spróbuję uruchomić plik wykonywalny ponownie po ponownym uruchomieniu systemu.
Rys. 22: Przykład zapewnia obecność w kluczu rejestru
Możemy również zobaczyć, że ten plik wykonywalny zatrzymuje dwie usługi:
"audioendpointbuilder", co, jak sugeruje jego nazwa, odpowiada systemowemu dźwiękowi,
Rys. 23: Przykład zatrzymuje usługę systemowego dźwięku
i samss, która jest usługą zarządzania kontami. Zatrzymanie tych dwóch usług jest charakterystyczne dla Ryuk. W przypadku, gdy system jest połączony z systemem SIEM, szyfrujący próbuje zatrzymać wysyłanie wszelkich powiadomień. W ten sposób chroni swoje następne kroki, ponieważ niektóre usługi SAM nie będą mogły prawidłowo rozpocząć pracy po działaniu Ryuk.
Rys. 24: Przykład zatrzymuje usługę Samss
5.2 Uprawnienia
Ogólnie rzecz biorąc, Ryuk rozpoczyna się od poziomego przemieszczania się w sieci lub jest uruchamiany przez inny złośliwy program, taki jak lub , które w przypadku eskalacji uprawnień przekazują te podwyższone prawa szyfrującemu.
Z wyprzedzeniem, w ramach preludium do procesu wdrażania, widzimy, że wykonuje proces ImpersonateSelf, co oznacza, że zawartość zabezpieczeń tokena dostępu zostanie przekazana do wątku, gdzie zostanie natychmiast odebrana przy użyciu GetCurrentThread.
Rys. 25: Wywołanie ImpersonateSelf
Następnie widzimy, że powiąże token dostępu z wątkiem. Widzimy również, że jednym z flag jest DesiredAccess, który może być używany do kontroli dostępu, który będzie miał wątek. W tym przypadku wartość, jaką uzyska edx, powinna być TOKEN_ALL_ACESS inaczej — TOKEN_WRITE.
Rys. 26: Tworzenie tokena wątku
Następnie użyje SeDebugPrivilege i dokona wywołania, aby uzyskać uprawnienia debugowania w odniesieniu do wątku, w wyniku czego, podając PROCESS_ALL_ACCESS, będzie mógł uzyskać dostęp do dowolnego wymaganego procesu. Teraz, biorąc pod uwagę, że szyfrujący już ma przygotowany wątek, pozostaje tylko przejść do ostatniego etapu.
Rys. 27: Wywołanie SeDebugPrivilege i funkcja eskalacji uprawnień
Z jednej strony mamy LookupPrivilegeValueW, który dostarcza nam niezbędne informacje o uprawnieniach, które chcemy zwiększyć.
Rys. 28: Żądanie informacji o uprawnieniach w celu ich eskalacji
Z drugiej strony mamy AdjustTokenPrivileges, które pozwala uzyskać niezbędne uprawnienia dla naszego wątku. W tym przypadku najważniejsze jest to, że NewState, którego flaga przyzna uprawnienia.
Rys. 29: Konfiguracja uprawnień dla tokena
5.3 Wprowadzenie
W tej sekcji pokażemy, jak próbka przeprowadza proces wprowadzenia, wcześniej wspomniany w tym raporcie.
Głównym celem procesu wprowadzenia, jak i eskalacji, jest uzyskanie dostępu do kopii cieni. W tym celu musi pracować z wątkiem z wyższymi uprawnieniami niż lokalny użytkownik. Gdy uzyska te wyższe uprawnienia, usunie kopie i wprowadzi zmiany w innych procesach, aby uniemożliwić powrót do wcześniejszego punktu przywracania w systemie operacyjnym.
Jak to zwykle bywa z takim rodzajem złośliwego oprogramowania, do przeprowadzenia wprowadzenia korzysta z CreateToolHelp32Snapshot, dlatego wykonuje zrzut aktualnie uruchomionych procesów i stara się uzyskać dostęp do tych procesów za pomocą OpenProcess. Gdy uzyskuje dostęp do procesu, otwiera również token z jego informacjami, aby uzyskać parametry procesu.
Rys. 30: Uzyskiwanie procesów z komputera
Możemy dynamicznie zobaczyć, jak uzyskuje listę uruchomionych procesów w podprogramie 140002D9C przy użyciu CreateToolhelp32Snapshot. Po ich uzyskaniu przechodzi przez listę, starając się po kolei otworzyć procesy za pomocą OpenProcess, aż mu się to uda. W tym przypadku pierwszym procesem, który udało mu się otworzyć, jest „taskhost.exe”.
Rys. 31: Dynamiczne wykonywanie procedury w celu uzyskania procesu
Możemy zobaczyć, że następnie odczytuje informacje tokena procesu, dlatego wywołuje OpenProcessToken z parametrem "20008"
Rys. 32: Odczytywanie informacji tokena procesu
Sprawdza również, czy proces, do którego będzie wprowadzany, nie jest csrss.exe, explorer.exe, lsaas.exe lub czy ma zestaw uprawnień NT authority.
Rys. 33: Wykluczone procesy
Możemy dynamicznie zobaczyć, jak najpierw przeprowadza kontrolę za pomocą informacji tokena procesu w 140002D9C aby sprawdzić, czy konto, którego uprawnienia są używane do wykonania procesu, to konto NT AUTHORITY.
Rys. 34: Weryfikacja NT AUTHORITY
A później, poza procedurą, sprawdza, że to nie csrss.exe, explorer.exe lub lsaas.exe.
Rys. 35: Weryfikacja NT AUTHORITY
Po tym jak wykonał zrzut procesów, otworzył procesy i upewnił się, że żaden z nich nie jest wykluczony, jest gotów do zapisania w pamięci procesów, które będą wstrzyknięte.
W tym celu najpierw rezerwuje obszar w pamięci (VirtualAllocEx), zapisuje w nim (WriteProcessMemory) i tworzy wątek (CreateRemoteThread). Do pracy z tymi funkcjami używa PID-ów wybranych procesów, które wcześniej uzyskał za pomocą CreateToolhelp32Snapshot.
Rys. 36: Kod do wstrzykiwania
Tutaj możemy dynamicznie obserwować, jak używa PID procesu do wywołania funkcji VirtualAllocEx.
Rys. 37: Wywołanie VirtualAllocEx
5.4 Szyfrowanie
W tej sekcji przyjrzymy się części tego wzoru związanej z szyfrowaniem. Na poniższym rysunku widzisz dwie podprogramy o nazwach "LoadLibrary_EncodeString" i "Encode_Func", które odpowiadają za realizację procedury szyfrowania.
Rys. 38: Procedury szyfrowania
Na początku widzimy, jak ładowana jest struna, która później będzie używana do deobfuskacji wszystkiego, co konieczne: importy, DLL, komendy, pliki i CSP.
Rys. 39: Łańcuch deobfuskacji
Na poniższym rysunku przedstawiono pierwszy import, który deobfuskował w rejestrze R4, LoadLibrary. To będzie używane później do ładowania wymaganych DLL. Możemy także zobaczyć inną strunę w rejestrze R12, która jest używana wraz z poprzednią struną do realizacji deobfuskacji.
Rys. 40: Dynamiczna deobfuskacja
Kontynuuje ładowanie komend, które później zostaną wykonane, aby wyłączyć kopie zapasowe, punkty przywracania i tryby awaryjne.
Rys. 41: Ładowanie komend
Następnie ładuje lokalizację, gdzie umieści 3 pliki: Windows.bat, run.sct i start.bat.
Rys. 42: Lokalizacje plików
Te 3 pliki są używane do sprawdzania uprawnień, którymi dysponują każda z lokalizacji. Jeśli wymagane uprawnienia nie są dostępne, Ryuk zatrzymuje wykonanie.
Kontynuuje ładowanie strun odpowiadających trzem plikom. Pierwsza, DECRYPT_INFORMATION.html, zawiera informacje niezbędne do przywrócenia plików. Druga, PUBLIC, zawiera klucz publiczny RSA.
Rys. 43: Struna DECRYPT INFORMATION.html
Trzecia, UNIQUE_ID_DO_NOT_REMOVE, zawiera zaszyfrowany klucz, który będzie używany w następnej podprogramie do przeprowadzenia szyfrowania.
Rys. 44: Linia UNIQUE ID DO NOT REMOVE
Na koniec ładuje wymagane biblioteki wraz z potrzebnymi importami i CSP (Microsoft Enhanced RSA i AES Cryptographic Provider).
Rys. 45: Ładowanie bibliotek
Po zakończeniu deobfuskacji przechodzi do wykonania działań wymaganych do szyfrowania: przeszukiwanie wszystkich dysków logicznych, wykonanie tego, co załadowano w poprzednim podprogramie, wzmocnienie swojego obecności w systemie, zrzucenie pliku RyukReadMe.html, szyfrowanie, przeszukiwanie wszystkich dysków sieciowych, przechodzenie do wykrytych urządzeń i ich szyfrowanie.
Wszystko zaczyna się od załadowania "cmd.exe" i zapisania otwartego klucza RSA.
Rys. 46: Przygotowanie do szyfrowania
Następnie uzyskuje dostęp do wszystkich dysków logicznych za pomocą GetLogicalDrives i wyłącza wszystkie kopie zapasowe, punkty przywracania i tryby awaryjne.
Rys. 47: Dezaktywacja środków przywracania
Następnie wzmacnia swoją obecność w systemie, jak widzieliśmy wcześniej, i zapisuje pierwszy plik RyukReadMe.html do TEMP.
Rys. 48: Publikacja powiadomienia o okupu
Na następnym rysunku możesz zobaczyć, jak tworzy plik, ładuje zawartość i zapisuje go:
Rys. 49: Ładowanie i zapisywanie zawartości pliku
Aby móc wykonać te same działania na wszystkich urządzeniach, używa
"icacls.exe", jak pokazaliśmy wcześniej.
Rys. 50: Użycie icalcls.exe
I w końcu rozpoczyna szyfrowanie plików z wyjątkiem plików "*.exe", "*.dll", plików systemowych i innych lokalizacji wskazanych w postaci zaszyfrowanej białej listy. Do tego używa importów: CryptAcquireContextW (gdzie wskazano użycie AES i RSA), CryptDeriveKey, CryptGenKey, CryptDestroyKey itd. Próbuję również rozszerzyć swoje działanie na wykryte urządzenia sieciowe za pomocą WNetEnumResourceW, a następnie je szyfrować.
Rys. 51: Szyfrowanie plików systemowych
6. Importy i odpowiednie flagi
Poniżej znajduje się tabela z listą najbardziej odpowiednich importów i flag używanych przez próbkę:
7. IOC
Linki
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgramsStartupstart.bat
Raport techniczny na temat ransomware'a Ryuk został przygotowany przez ekspertów laboratorium antywirusowego PandaLabs.
8. Linki
1. „Everis i Prisa Radio doświadczają poważnego cyberataku, który porywa ich systemy.”https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, opublikowano 04/11/2019.
2. „Wirus o rosyjskim pochodzeniu atakuje ważne przedsiębiorstwa hiszpańskie.”https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, opublikowano 04/11/2019.
3. „Artykuł VB2019: Zemsta Shinigami: długi ogon złośliwego oprogramowania Ryuk.”https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, opublikowano 11/12/2019.
4. „Polowanie na wielkie gry z Ryuk: kolejny lukratywny cel ransomware.”https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, opublikowano 10/01/2019.
5. „Artykuł VB2019: Zemsta Shinigami: długi ogon złośliwego oprogramowania Ryuk.”https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Źródło: habr.com
