A Ryuk az utolsó néhány év egyik legismertebb ransomware változata. Amióta 2018 nyarán először megjelent, lenyűgöző áldozati listát gyűjtött össze. 1. általános információk
Ez a dokumentum a Ryuk ransomware és a malware betöltéséért felelős loader elemzését tartalmazza.
A Ryuk ransomware először 2018 nyarán jelent meg. Az egyik fő különbség a Ryuk és más ransomware-ek között az, hogy ő vállalati környezetek ellen irányul.
2019 közepén a kiberbűnözői csoportok rengeteg spanyol céget támadtak meg e ransomware segítségével.
1. ábra: Kivágás az El Confidencialből a Ryuk ransomware támadásáról [1]
2. ábra: Kivágás az El Paísből a Ryuk ransomware által végrehajtott támadásról [2]
Idén a Ryuk számos céget támadott meg különböző országokban. Ahogy az alábbi ábrákon látható, a legnagyobb károkat Németország, Kína, Algéria és India szenvedte el.
A kibertámadások számát összehasonlítva láthatjuk, hogy a Ryuk áldozatul esett milliók számára, és óriási mennyiségű adatot kompromittált, ami súlyos gazdasági károkat okozott.
3. ábra: A Ryuk globális aktivitásának illusztrációja.
4. ábra: 16 ország, amelyek a legnagyobb mértékben szenvedtek a Ryuktól
5. ábra: A Ryuk ransomware által megtámadott felhasználók száma (millióban)
A hasonló fenyegetések szokásos működési elve szerint a ransomware a titkosítás befejezését követően értesítést jelenít meg az áldozatnak a váltságról, amelyet bitcoinban kell kifizetni a megadott címre, hogy helyreállítsák a titkosított fájlokat.
Ez a rosszindulatú program a megjelenése óta megváltozott.
A dokumentumban elemzett fenyegetésváltozat 2020 januárjában került felfedezésre, amikor támadást próbáltak végrehajtani.
Bonyolultsága miatt ezt a rosszindulatú programot gyakran szervezett kiberbűnözői csoportokhoz, más néven APT-csoportokhoz társítják.
Összetettsége miatt ezt a kártevőt gyakran szervezett kibertorvosszá csoportokhoz kapcsolják, amelyeket APT-csoportoknak is neveznek.
A Ryuk kódjának részletei nyilvánvalóan hasonlítanak a Hermes nevű másik híres zsarolóprogram kódjára és felépítésére, amelyek számos azonos funkcióval rendelkeznek. Éppen ezért kezdetben a Ryukot a Lazarus észak-koreai csoporttal hozták összefüggésbe, amely akkoriban a Hermes zsarolóprogram mögött állt.
Később a CrowdStrike Falcon X szolgáltatása jelezte, hogy a Ryukot valójában a WIZARD SPIDER csoport hozta létre [4].
Számos bizonyíték van ennek a feltételezésnek a támogatására. Először is, ezt a zsarolóprogramot az exploit.in weboldalon népszerűsítették, amely egy ismert orosz kiberbűnözési piactér, és korábban kapcsolatba hozták néhány orosz APT-csoporttal.
Ez a tény kizárja azt a teóriát, hogy a Ryukot a Lazarus APT-csoport fejlesztette volna, mivel ez nem felel meg a csoport működésének.
Továbbá, a Ryukot olyan zsarolóprogramként reklámozták, amely nem működik orosz, ukrán és belorusz rendszereken. Ez a viselkedés egyes Ryuk verziókban felfedezett funkciókkal magyarázható, ahol a zsarolóprogram ellenőrzi a rendszer nyelvét, amelyen fut, és leállítja a működését, ha a rendszer orosz, ukrán vagy belorusz nyelvű. Végül, a WIZARD SPIDER által meghekkelni próbált gép szakértői elemzése során számos "artefaktumot" találtak, amelyeket feltételezhetően a Ryuk kifejlesztésére használtak, mint a Hermes zsarolóprogram egyik változatát.
Másrészt Gabriel Nicolo és Luciano Martins szakértők azt javasolták, hogy a zsarolóprogramot talán a CryptoTech APT-csoport fejlesztette ki [5].
Ez abból a tényből következik, hogy néhány hónappal a Ryuk megjelenése előtt ez a csoport közzétett a fent említett weboldalon egy információt arról, hogy új verziót fejlesztettek a Hermes zsarolóprogramból.
Néhány fórumhasználó megkérdezte, hogy valóban a CryptoTech készítette-e a Ryukot. Ezt követően a csoport megvédte magát, és kijelentette, hogy bizonyítékaik vannak arra, hogy ők fejlesztették ki ennek a zsarolóprogramnak a 100%-át.
2. Jellemzők
Kezdünk a betöltővel, amelynek feladata, hogy azonosítsa azt a rendszert, amelyben található, hogy elindíthassuk a "helyes" Ryuk zsarolóprogram verziót.
A betöltő hash értéke a következő:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
A betöltő egyik jellemzője, hogy nem tartalmaz semmiféle metaadatot, vagyis a kártékony program készítői nem adtak meg semmilyen információt.
Néha hibás adatokat is belefűznek, hogy a felhasználó úgy érezze, mintha egy legitim alkalmazást indítana el. Azonban, mint később látni fogjuk, ha a fertőzés nem igényel interakciót a felhasználóval (mint ebben az esetben a titkosítónál), a támadók nem tartják szükségesnek a metaadatok használatát.
Ábra 6: Minta metaadatai
A minta 32 bites formátumban készült, hogy 32 bites és 64 bites rendszereken is futtatható legyen.
3. Beh проникeringési vektor
A minta, amely a Ryukot tölti le és indítja el, távoli kapcsolaton keresztül került a rendszerünkbe, és a hozzáférési paraméterek egy előzetes RDP-támadás következtében kerültek megszerzésre.
Ábra 7: Támadás regisztrációja
A támadó távolról be tudott lépni a rendszerbe. Ezt követően létrehozott egy végrehajtható fájlt a mintánkkal.
Ez a végrehajtható fájl az indítás előtt blokkolva lett az antivírus megoldás által.
Ábra 8: Minta blokkolása
Ábra 9: Minta blokkolása
Amikor a kártékony fájl blokkolva lett, a támadó megpróbált betölteni egy titkosított változatot a végrehajtható fájlról, amely szintén blokkolva lett.
Ábra 10: A támadó által elindítani próbált minták gyűjteménye
Végül megpróbált egy másik kártékony fájlt betölteni titkosított konzolon keresztül
PowerShell segítségével, hogy megkerülje az antivírus védelmet. De ez is blokkolva lett.
Ábra 11: PowerShell blokkolt kártékony tartalommal
Ábra 12: PowerShell blokkolt kártékony tartalommal
4. Betöltő
Amikor fut, létrehoz egy ReadMe fájlt a következő mappában %temp%, ami tipikus a Ryuk esetében. Ez a fájl egy váltságdíj követelés, amely egy protonmail domainen található e-mail címet tartalmaz, amely ezen kártékony programcsalád esetében meglehetősen gyakori: msifelabem1981@protonmail.com
Ábra 13: Váltságdíj követelés
A betöltő futása során láthatja, hogy több véletlenszerű nevű végrehajtható fájlt indít el. Ezek egy rejtett mappában találhatók PUBLIC, de ha az operációs rendszerben nincs aktiválva a „Rejtett fájlok és mappák megjelenítése” opció., akkor rejtve maradnak. Továbbá, ezek a fájlok 64-bitesek, míg a szülő fájl 32-bites.
Ábra 14: A mintával futtatható fájlok
Ahogy a fenti ábrán látható, a Ryuk elindítja az icacls.exe-t, amelyet az összes hozzáférési lista (ACL) megváltoztatására fognak használni, ezzel biztosítva a hozzáférést és a zászlók módosítását.
Teljes hozzáférést kap minden felhasználó alatt az eszköz összes fájljához (\/T) hibáktól függetlenül (\/C) és anélkül, hogy bármilyen üzenetet megjelenítene (\/Q).
Ábra 15: Az icacls.exe végrehajtási paraméterei, amelyeket a minta indít el
Fontos figyelembe venni, hogy a Ryuk ellenőrzi, melyik Windows verzió fut. Ehhez
verzióellenőrzést végez a GetVersionExW, amelyben ellenőrzi a lpVersionInformationértékét, amely megmutatja, hogy a jelenlegi Windows verzió későbbi-e mint Windows XP.
Attól függően, hogy a Windows XP-nél újabb verzió fut-e, a betöltő a helyi felhasználó mappájába fog írni – jelen esetben a %Public%.
Ábra 17: Az operációs rendszer verziójának ellenőrzése
A rögzített fájl a Ryuk. Ezt követően elindítja, átadva a saját címét paraméterként.
Ábra 18: A Ryuk futtatása a ShellExecute segítségével
A Ryuk első dolga a bemeneti paraméterek megszerzése. Ezúttal két bemeneti paraméter van (maga a futtatható fájl és a dropper címe), amelyeket saját nyomaik eltüntetésére használnak.
Ábra 19: A folyamat létrehozása
Láthatja, hogy amint elindította a futtatható fájljait, eltávolítja magát, ezzel nem hagyva nyomot a végrehajtásának helyén.
Ábra 20: A fájl eltávolítása
5. RYUK
5.1 Jelenlét
A Ryuk, hasonlóan más rosszindulatú programokhoz, megpróbál minél tovább a rendszeren maradni. Ahogy fentebb láttuk, az egyik módja ennek elérésére a futtatható fájlok titkos létrehozása és végrehajtása. A legelterjedtebb gyakorlat erre a célra a CurrentVersionRun.
regisztrációs kulcs módosítása. Ebben az esetben láthatja, hogy erre a célra az első indítható fájl
VWjRF.exe cmd.exe.
Ábra 21: A VWjRF.exe fájl végrehajtása
Ezt követően a parancs beírásra kerül RUN a "svchos"Így ha bármikor ellenőrizni szeretné a regisztrációs kulcsokat, akkor ezt a változást könnyen észre sem veszi, figyelembe véve a hasonlóságot a svchost névvel. Ennek a kulcsnak köszönhetően a Ryuk biztosítja a rendszerben való jelenlétét. Ha a rendszer még nem fertőződött meg, akkor amikor újraindítja a rendszert, a végrehajtható fájl újra megpróbálkozik.
22. ábra: A minta jelenlétét biztosítja a regisztrációs kulcsban
Azt is láthatjuk, hogy ez a végrehajtható fájl két szolgáltatást leállít:
"audioendpointbuilder", amely nevéből adódóan a rendszer audioját képviseli,
23. ábra: A minta leállítja a rendszeraudio szolgáltatást
és samss, amely a fiókkezelő szolgáltatás. E két szolgáltatás leállítása a Ryuk egyik jellemzője. Ebben az esetben, ha a rendszer kapcsolódik a SIEM rendszerhez, a titkosító megpróbálja megállítani a küldést a bármilyen riasztásról. Így védi a következő lépéseit, mivel néhány SAM-szolgáltatás nem tud megfelelően elindulni a Ryuk végrehajtása után.
24. ábra: A minta leállítja a Samss szolgáltatást
5.2 Jogosultságok
Általában a Ryuk vízszintes mozgással kezdődik a hálózaton belül, vagy egy másik kártevő program indítja el, mint például vagy , amelyek jogosultságok eszkalálása esetén átadják ezeket a megnövelt jogokat a titkosítónak.
Előzetesen, az integrációs folyamat előjátékaként látjuk, hogy végrehajtja a ImpersonateSelf, amely azt jelenti, hogy a hozzáférési token biztonsági tartalmát átruházza a szálra, ahol azt azonnal megkapják a GetCurrentThread.
25. ábra: ImpersonateSelf hívása
Ezután látjuk, hogy összekapcsolja a hozzáférési tokent a szállal. Azt is látjuk, hogy az egyik zászló az DesiredAccess, amely a hozzáférés szabályozására használható, amelyet a szál kap. Ebben az esetben az edx által kapott értéknek TOKEN_ALL_ACESS vagy különben TOKEN_WRITE.
26. ábra: Szál token létrehozása
Ezután használni fogja a SeDebugPrivilege és hívást tesz a szálra vonatkozó hibakeresési jogok megszerzésére, ennek következtében, megadva PROCESS_ALL_ACCESS, hozzáférést kap bármely szükséges folyamathoz. Most, figyelembe véve, hogy a titkosító már rendelkezik egy előkészített szállal, csak a záró szakasz kezdődött.
Ábra. 27: A SeDebugPrivilege hívása és jogok feljogosító funkciója
Egyrészt ott van a LookupPrivilegeValueW, amely megadja nekünk a kívánt jogosultságokkal kapcsolatos szükséges információkat.
Ábra. 28: Jogosultságok információs lekérdezése az eszkalálás érdekében
Másrészt van AdjustTokenPrivileges, amely lehetővé teszi a szükséges jogok megszerzését a szálunk számára. Ebben az esetben a legfontosabb a NewState, amelyiknek a zászlaja biztosítja a jogosultságokat.
Ábra. 29: Jogosultságok beállítása a tokenhez
5.3 Az eszkalálás megvalósítása
Ebben a részben bemutatjuk, hogyan hajt végre a példa egy eszkalálási folyamatot, amelyet korábban már említettünk a jelentésben.
Az eszkalálási folyamat fő célja, mint ahogy az eszkalációé is, a hozzáférés megszerzése a shadow copy-okhoz. Ehhez egy olyan szálon kell dolgoznia, amelynek jogai magasabbak a helyi felhasználónál. Miután megszerezte ezeket a magasabb jogokat, eltávolítja a másolatokat és módosítja a többi folyamatot annak érdekében, hogy megakadályozza a korábbi helyreállítási pont visszaállítását az operációs rendszerben.
Ahogy ez gyakran előfordul az ilyen típusú rosszindulatú programok esetében, az eszkalálás végrehajtásához használja a CreateToolHelp32Snapshot, ezért készít egy pillanatfelvételt a jelenleg futó folyamatokról, és megpróbál hozzáférni ezekhez a folyamatokhoz a OpenProcesssegítségével. Miután hozzáférést kapott a folyamathoz, megnyit egy tokent is az információival a folyamat paramétereinek megszerzése érdekében.
Ábra. 30: Folyamatok megszerzése a számítógépről
Dinamikailag láthatjuk, hogy hogyan szerzi meg a futó folyamatok listáját a 140002D9C alprogramban a CreateToolhelp32Snapshot segítségével. Miután megszerezte őket, végigmegy a listán, próbálva egyesével megnyitni őket az OpenProcess segítségével, amíg sikerül. Ebben az esetben az első folyamat, amelyet meg tudott nyitni, a "taskhost.exe".
Ábra. 31: A folyamat megszerzésének dinamikus végrehajtása
Láthatjuk, hogy később beolvassa a folyamat token információit, ezért meghívja a OpenProcessToken paraméterrel "20008"
Ábra. 32: A folyamat token információjának olvasása
Azt is ellenőrzi, hogy a folyamat, amelybe be fog építeni, nem-e a csrss.exe, , explorer.exe, lsaas.exe vagy hogy rendelkezik-e a következő jogokkal: NT authority.
Ábra. 33: Kizárt folyamatok
Dinamikailag láthatjuk, hogy először az információk tokenje alapján ellenőrzést hajt végre a 140002D9C azzal szeretnénk megtudni, hogy a folyamat végrehajtásához használt fiók egy fiók-e NT AUTHORITY.
34. ábra: NT AUTHORITY ellenőrzése
Majd később, a folyamaton kívül ellenőrzi, hogy ez nem csrss.exe, explorer.exe vagy lsaas.exe.
35. ábra: NT AUTHORITY ellenőrzése
Miután elkészítette a folyamatok pillanatképét, megnyitotta a folyamatokat, és ellenőrizte, hogy egyik sem kivételes, készen áll arra, hogy a memória megfelelő részeibe írja azokat a folyamatokat, amelyeket be kíván illeszteni.
Ehhez először foglal egy részt a memóriában (VirtualAllocEx), ebbe beleír (WriteProcessmemory) és létrehoz egy szálat (CreateRemoteThread). Ezeknek a funkcióknak a használatához a kiválasztott folyamatok PID-jét használja, amelyeket előzőleg a CreateToolhelp32Snapshot.
36. ábra: Beillesztési kód
Itt dinamikusan figyelhetjük, ahogy a folyamat PID-jét használja a VirtualAllocEx. hívásához.
37. ábra: VirtualAllocEx hívás
5.4 Titkosítás
Ebben a részben megvizsgáljuk a titkosítással kapcsolatos részét ennek a mintának. A következő ábrán láthatók a "LoadLibrary_EncodeString" és "Encode_Func", amelyek a titkosítási eljárás végrehajtásáért felelősek.
38. ábra: Titkosítási eljárások
Először láthatjuk, ahogy betölti azt a sztringet, amely később az összes szükséges dolog: importok, DLL, parancsok, fájlok és CSP deobfuszkálására lesz használva.
39. ábra: Deobfuszkálási lánc
A következő ábrán látható az első import, amelyet R4 regiszterben deobfuszkál, LoadLibrary. Ezt később szükséges DLL-ek betöltésére használják. Láthatunk egy másik sztringet is az R12 regiszterben, amelyet a korábbi sztringgel együtt használnak a deobfuszkálás végrehajtására.
40. ábra: Dinamikus deobfuszkálás
Folytatja a parancsok betöltését, amelyeket később végrehajt, hogy letiltsa a biztonsági másolatokat, a visszaállítási pontokat és a biztonságos betöltési módokat.
41. ábra: Parancsok betöltése
Ezután betölti a helyszínt, ahova három fájlt helyez el: Windows.bat, run.sct és start.bat.
42. ábra: Fájlok helyszínei
Ezek a fájlok a hozzáférési jogosultságok ellenőrzésére szolgálnak, amelyeket az egyes helyek birtokolnak. Ha a szükséges jogosultságok nem állnak rendelkezésre, a Ryuk leállítja a végrehajtást.
Folytatja a három fájlnak megfelelő sztringek betöltését. Az első, DECRYPT_INFORMATION.html, tartalmazza a fájlok helyreállításához szükséges információt. A második, PUBLIC, tartalmazza az RSA nyilvános kulcsát.
Ábra. 43: DECRYPT INFORMATION.html sor
Harmadik, UNIQUE_ID_DO_NOT_REMOVE, tartalmaz egy titkosított kulcsot, amelyet a következő alprogramban fognak felhasználni a titkosításhoz.
Ábra. 44: UNIQUE ID DO NOT REMOVE sor
Végül betölti a szükséges könyvtárakat a szükséges importokkal és CSP-vel (Microsoft Enhanced RSA és AES Cryptographic Provider).
Ábra. 45: Könyvtárak betöltése
Miután a teljes deobfuszkálás befejeződött, áttér a titkosításhoz szükséges lépések végrehajtására: az összes logikai meghajtó átvizsgálása, a korábban betöltött dolgok végrehajtása, a rendszer jelenlétének fokozása, a RyukReadMe.html fájl beemelése, titkosítás, az összes hálózati meghajtó átvizsgálása, a felfedezett eszközök elérése és azok titkosítása.
Minden azzal kezdődik, hogy betölti "cmd.exe" és rögzíti a nyílt RSA-kulcsot.
Ábra. 46: Felkészülés a titkosításra
Ezután megkapja az összes logikai meghajtót a következőkkel: GetLogicalDrives és leállít minden biztonsági másolatot, visszaállítási pontot és biztonságos indítási módot.
Ábra. 47: A helyreállítási eszközök letiltása
Ezután fokozza a jelenlétét a rendszerben, ahogyan az fent látható, és rögzíti az első fájlt: RyukReadMe.html be. TEMP.
Ábra. 48: A váltságdíj értesítés közzététele
A következő ábrán látható, hogyan készít fájlt, tölti be a tartalmat és rögzíti azt:
Ábra. 49: A fájl tartalmának betöltése és rögzítése
Annak érdekében, hogy ezeket a lépéseket minden eszközön végrehajthassa, az icacls.exe-t használja:
"icacls.exe", ahogyan azt fent bemutattuk.
Ábra. 50: az icacls.exe használata
És végül megkezdi a fájlok titkosítását, kivéve az "*.exe", "*.dll", rendszerfájlokat és a titkosított fehérlistában megadott egyéb helyszíneket. Ehhez a következő importokat használja: CryptAcquireContextW (ahol az AES és RSA használata van megadva), CryptDeriveKey, CryptGenKey, CryptDestroyKey stb. Ezenkívül próbálkozik bővíteni a hatását a felfedezett hálózati eszközökre a WNetEnumResourceW segítségével, majd titkosítani azokat.
Ábra. 51: Rendszerfájlok titkosítása
6. Importok és a megfelelő flag-ek
Az alábbi táblázat az adott minta által használt legrelevánsabb importokat és flag-eket mutatja be:
7. IOC
Hivatkozások
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgramsStartupstart.bat
A Ryuk ransomware technikai jelentését a PandaLabs víruslabor szakértői állították össze.
8. Hivatkozások
1. "Az Everis és a Prisa Rádió súlyos kibertámadást szenvedett el, amely megfertőzte a rendszereiket." https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Kiadva: 2019.11.04.
2. "Egy orosz eredetű vírus támadja meg a fontos spanyol vállalatokat." https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Kiadva: 2019.11.04.
3. "VB2019 tanulmány: Shinigami bosszúja: a Ryuk malware hosszú farka." https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Kiadva: 2019.12.11.
4. "Nagy játékvadászat a Ryukkal: Egy másik jövedelmező célzott ransomware." https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Kiadva: 2019.01.10.
5. "VB2019 tanulmány: Shinigami bosszúja: a Ryuk malware hosszú farka." https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Forrás: habr.com
