Ryuk është një nga variantet më të njohura të shifrovuesve të viteve të fundit. Që nga shfaqja e tij të verës së vitit 2018, ai ka grumbulluar , veçanërisht në mjedisin e biznesit, i cili është objekti kryesor i sulmeve të tij.
1. Informacione të përgjithshme
Ky dokument përmban analizën e variantit të shifrovuesit Ryuk, si dhe shkarkuesin që është përgjegjës për ngarkimin e programit të dëmshëm në sistem.
Shifrovuesi Ryuk u shfaq për herë të parë në verën e vitit 2018. Një nga dallimet e Ryuk nga shifrovuesit e tjerë është se ai është në fokus të sulmeve në mjedise korporative.
Në mesin e vitit 2019, grupet e krimit kibernetik sulmuan një numër të madh të kompanive spanjolle me ndihmën e këtij shifrovuesi.
Fig. 1: Një fragment nga El Confidencial për sulmin e shifrovuesit Ryuk [1]
Fig. 2: Një fragment nga El País për sulmin të kryer me ndihmën e shifrovuesit Ryuk [2]
Këtë vit Ryuk sulmoi një numër të madh kompanish në vende të ndryshme. Siç mund ta shihni në ilustrimet e mëposhtme, më së shumti janë dëmtuar Gjermania, Kina, Algjeria dhe India.
Duke krahasuar numrin e sulmeve kibernetike, ne mund të shohim se Ryuk ka prekur miliona përdorues dhe ka kompromentuar një sasi të madhe të dhënash, që ka çuar në një dëm të rëndë ekonomik.
Fig. 3: Ilustrimi i aktivitetit global të Ryuk.
Fig. 4: 16 vendet më të prekur nga Ryuk
Fig. 5: Numri i përdoruesve të sulmuar nga shifrovuesi Ryuk (në milion)
Sipas parimit të zakonshëm të funksionimit të këtyre kërcënimeve, ky shifrovues pas përfundimit të shifrimit tregon viktimës një njoftim për shpërblim, i cili duhet të paguhet në bitcoin në adresën e caktuar për të rikthyer qasjen në skedarët e shifruara.
Ky program i dëmshëm ka ndryshuar që nga shfaqja e tij e parë.
Varianti i analizuar në këtë dokument u zbulua gjatë përpjekjes për të realizuar një sulm në janar të vitit 2020.
Për shkak të kompleksitetit të tij, ky program i dëmshëm shpesh iu atribuohet grupeve të organizuara të krimeve kibernetike, të njohura gjithashtu si grupet APT.
Një pjesë e kodit Ryuk ka ngjashmëri të dukshme me kodin dhe strukturën e një shifruese tjetër të njohur, Hermes, me të cilin ata kanë një sërë funksionesh të përbashkëta. Kjo është arsyeja pse në fillim Ryuk u lidh me grupin koreanverior Lazarus, i cili në atë kohë dyshohej se qëndronte pas shifruese Hermes.
Më vonë, shërbimi Falcon X i CrowdStrike vuri në dukje se në fakt Ryuk ishte krijuar nga grupi WIZARD SPIDER.
Ekzistojnë disa prova që mbështesin këtë supozim. Së pari, kjo shifruese u reklamua në faqen e internetit exploit.in, e cila është një treg i njohur rus për mjete të dëmshme dhe më parë është lidhur me disa grupe APT ruse.
Ky fakt përjashton teorinë se Ryuk mund të ketë qenë zhvilluar nga grupi APT Lazarus, pasi kjo nuk përputhet me mënyrën se si vepron grupi.
Përveç kësaj, Ryuk u reklamua si një shifruese që nuk do të funksiononte në sistemet ruse, ukrainase dhe bjellorusë. Ky veprim përcaktohet nga funksioni i zbuluar në disa versione të Ryuk, ku kontrollohet gjuha e sistemit në të cilin kjo shifruese është ekzekutuar dhe ndalet në rast se sistemi ka rusisht, ukraineze ose gjuhë bjelloruse. Së fundi, gjatë analizës ekspertuese të makinës që u komprometua nga grupi WIZARD SPIDER, u zbuluan disa "artefakte" që supozohet se u përdorën në zhvillimin e Ryuk si një version i shifruese Hermes.
Nga ana tjetër, ekspertët Gabriela Nicollao dhe Luciano Martins sugjeruan se shifruese, ndoshta, ishte zhvilluar nga grupi APT CryptoTech.
Kjo rrjedh nga fakti se disa muaj para shfaqjes së Ryuk, ky grup publikoi në forumin e njëjtë të saj informacione se kishin zhvilluar një version të ri të shifruese Hermes.
Disa përdorues të forumit e pyetën nëse CryptoTech kishte krijuar Ryuk. Pas kësaj, ky grup mbrojti veten dhe tha se kishte prova se ata kishin zhvilluar 100% të kësaj shifruese.
2. Karakteristikat
Ne fillojmë me bootloader-in, i cili ka si qëllim identifikimin e sistemit në të cilin ndodhet, në mënyrë që të mund të ekzekutohet versioni "i duhur" i shifruese Ryuk.
Heshi i bootloader-it është si vijon:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
Një nga veçoritë e këtij ngarkuesi është se ai nuk përmban metadatat, domethënë, krijuesit e kësaj programi të dëmshëm nuk e kanë përfshirë asnjë informacion.
Herë pas here ata përfshijnë të dhëna të gabuara për ta bërë përdoruesin të mendojë se po ekzekuton një aplikacion legjitim. Megjithatë, siç do të shohim më vonë, në rastin kur infektimi nuk kërkon ndërveprim me përdoruesin (siç ndodh me këtë enkriptues), ata që kryejnë sulmin nuk e konsiderojnë të nevojshëm të përdorin metadatat.
Fig. 6: Metadatata e mostravës
Mostra ishte kompiliuar në formatin 32-bit, në mënyrë që të mund të ekzekutohej si në sistemet 32-bit ashtu edhe në 64-bit.
3. Vektori i hyrjes
Mostra që ngarkon dhe ekzekuton Ryuk arriti në sistemin tonë përmes një lidhjeje të largët, dhe parametrat e qasjes u morën përmes një sulmi të paracaktuar RDP.
Fig. 7: Regjistri i sulmit
Sulmuesi arriti të hyjë në sistem përmes largësisë. Më pas, ai krijoi një skedar ekzekutiv me mostrat tonë.
Ky skedar ekzekutiv u bllokua nga zgjidhja antivirus para ekzekutimit.
Fig. 8: Bllokimi i mostrat
Fig. 9: Bllokimi i mostrat
Kur skedari i dëmshëm u bllokua, sulmuesi u përpoq të ngarkonte një version të enkriptuar të skedarit ekzekutiv, i cili gjithashtu u bllokua.
Fig. 10: Grupi i mostrave që sulmuesi u përpoq të ekzekutonte
Në fund, ai u përpoq të ngarkonte një skedar tjetër të dëmshëm nëpërmjet konsolës së enkriptuar
PowerShell për të anashkaluar mbrojtjen antivirus. Por ai gjithashtu u bllokua.
Fig. 11: PowerShell me përmbajtjen e dëmshme të bllokuar
Fig. 12: PowerShell me përmbajtjen e dëmshme të bllokuar
4. Ngarkuesi
Kur ai ekzekutohet, ai regjistron një skedar ReadMe në dosjen %temp%, që është tipike për Ryuk. Ky skedar është një kërkesë shpërblimi, që përmban një adresë elektronkë në domenin protonmail, e cila shpesh haset në këtë familje programesh të dëmshme: msifelabem1981@protonmail.com
Fig. 13: Kërkesa e shpërblimit
Gjatë ekzekutimit të ngarkuesit Ju mund të shihni se ai ekzekuton disa skedare ekzekutivë me emra rastësorë. Ato ruhen në një dosje të fshehtë PUBLIK, por nëse opsioni i sistemit operativ nuk është aktivizuar «Trego skedarët dhe dosjet e fshehura», ata ata do të mbesin të fshehta. Më tej, këto skedarë janë 64-bit, ndryshe nga skedari prind, i cili është 32-bit.
Fig. 14: Skedarët ekzekutivë që aktivizohen nga mostrat
Siç mund ta shihni në figurën e mësipërme, Ryuk ekzekuton icacls.exe, i cili do të përdoret për të ndryshuar të gjitha listat e kontrollit të aksesit ACL (Access control list), duke siguruar kështu qasje dhe ndryshim të flagjeve.
Ai merr qasje të plotë për të gjitha përdoruesit në të gjitha skedarët në pajisje (\T) pavarësisht ndërlikimeve (\C) dhe pa shfaqur asnjë mesazh (\Q).
Fig. 15: Parametrat e ekzekutimit icacls.exe, të filluar nga mostra
Është e rëndësishme të merret parasysh se Ryuk kontrollon se cila version e Windows-it është aktivizuar. Për këtë ai
bën një kontroll versioni përmes GetVersionExW, ku kontrollon vlerën e flagut lpVersionInformation, që tregon nëse versioni aktual i Windows-it është më i vonë se Windows XP.
Në varësi të faktit nëse po regjistroni një version më të vonë se Windows XP, startuesi do të shkruajë në dosjen e përdoruesit lokal - në këtë rast në dosjen %Public%.
Fig. 17: Kontrolli i versionit të sistemit operativ
Skedari i shkruar është Ryuk. Pastaj ai e aktivizon, duke kaluar adresën e tij si një parametr.
Fig. 18: Ekzekutimi i Ryuk përmes ShellExecute
E para që bën Ryuk është marrja e parametrave të hyrjes. Këtë herë ka dy parametro hyrëse (vetë skedari ekzekutiv dhe adresa e dërguesit), të cilat përdoren për të fshirë gjurmët e veta.
Fig. 19: Krijimi i procesit
Po ashtu, mund të shihni se sapo ai ka aktivizuar skedarët e tij ekzekutivë, ai e fshin veten, duke mos lënë ndonjë gjurmë të pranishme në dosjen ku është ekzekutuar.
Fig. 20: Fshirja e skedarit
5. RYUK
5.1 Prania
Ryuk, siç janë dhe Malware të tjera, përpiqet të qëndrojë në sistem sa më gjatë të jetë e mundur. Siç u shpjegua më lart, një nga mënyrat për të arritur këtë qëllim është krijimi dhe aktivizimi i skedarëve ekzekutivë në mënyrë të fshehtë. Për këtë, praktika më e zakonshme është modifikimi i çelësit të regjistrit CurrentVersionRun.
Në këtë rast mund të shihni se për këtë qëllim skedari i parë i ekzekutuar VWjRF.exe
(emri i skedarit gjenerohet rastësisht) aktivizon cmd.exe.
Fig. 21: Aktivizimi i skedarit VWjRF.exe
Pastaj jepet urdhëri RUN me emrin "svchos". Kështu, nëse dëshironi të kontrolloni çelqet e regjistrit në çdo moment, do të jeni shumë lehtë në gjendje ta vini re këtë ndryshim, duke pasur parasysh ngjashmërinë e këtij emri me svchost. Falë këtij çelqi, Ryuk siguron praninë e tij në sistem. Nëse sistemi ende nuk është infektuar, kur të rinisni sistemin, skedari ekzekutiv do të përpiqet përsëri.
Fig. 22: Shembulli siguron praninë në çelqin e regjistrit
Ne gjithashtu mund të shohim se ky skedari ekzekutiv ndalon dy shërbime:
"audioendpointbuilder", e cila, siç tregon emri i saj, i përket audios sistemit,
Fig. 23: Shembulli ndalon shërbimin e audios sistemit
dhe samss, e cila është shërbimi i menaxhimit të llogarive. Ndalesa e këtyre dy shërbimeve është një karakteristikë e Ryuk. Në këtë rast, nëse sistemi është i lidhur me një sistem SIEM, atëherë kriptuesi përpiqet të ndalë dërgimin e ndonjë njoftimi. Kështu, ai mbron hapat e tij të mëpasshëm, pasi disa shërbime SAM nuk do të mund t'i fillojnë siç duhet pas ekzekutimit të Ryuk.
Fig. 24: Shembulli ndalon shërbimin Samss
5.2 Privilegjet
Në përgjithësi, Ryuk fillon me lëvizje horizontale brenda rrjetit ose niset nga një program i keq tjetër, si ose , të cilat, në rast të eskalimit të privilegjeve, i kalojnë këto të drejta të përmirësuara kriptuesit.
Para se të fillojë procesin e integrimit, ne shohim se ai ekzekuton procesin ImpersonateSelf, që do të thotë se përmbajtja e sigurisë së tokenit të aksesit do të kalojë në shkakun, ku do të merret menjëherë me GetCurrentThread.
Fig. 25: Thirrja ImpersonateSelf
Pastaj shohim se ai do ta lidhë tokenin e aksesit me shkakun. Ne gjithashtu shohim se një nga flakët është DesiredAccess, i cili mund të përdoret për të kontrolluar aksesin që do të ketë shkaku. Në këtë rast, vlera që do të marrë edx duhet të jetë TOKEN_ALL_ACESS ose përndryshe — TOKEN_WRITE.
Fig. 26: Krijimi i tokenit të shkakut
Pastaj do të përdorë SeDebugPrivilege dhe do të bëjë një thirrje për të marrë të drejtat e debuguar Debug në lidhje me shkakun, duke rezultuar në tregimin e PROCESS_ALL_ACCESS, ai do të jetë në gjendje të ketë akses në çdo proces të nevojshëm. Tani, duke pasur parasysh se kriptuesi tashmë ka një shkak të përgatitur, mbetet vetëm të fillojë fazën përfundimtare.
Fig. 27: Calling SeDebugPrivilege and the privilege escalation function
On one hand, we have LookupPrivilegeValueW, providing us with the necessary information about the privileges we want to elevate.
Fig. 28: Requesting privilege information for escalation
On the other hand, we have AdjustTokenPrivileges, which allows us to obtain the necessary rights for our thread. In this case, the most important aspect is NewState, whose flag will provide the privileges.
Fig. 29: Configuring rights for the token
5.3 Implementation
In this section, we will demonstrate how the sample executes the implementation process previously mentioned in this report.
The main goal of the implementation process, as with escalation, is to gain access to shadow copies. To do this, it needs to work with a thread that has higher privileges than the local user. Once it obtains such elevated rights, it will delete the copies and make changes to other processes to prevent reverting to an earlier restore point in the operating system.
As is often the case with this type of malware, to perform the implementation, it uses CreateToolHelp32Snapshot, so it takes a snapshot of currently running processes and attempts to access these processes using OpenProcess. Once it gains access to a process, it also opens the token with its information to retrieve the process parameters.
Fig. 30: Retrieving processes from the computer
We can dynamically see how it retrieves the list of running processes in the subroutine 140002D9C using CreateToolhelp32Snapshot. After obtaining them, it goes through the list, attempting to open the processes one by one with OpenProcess until it succeeds. In this case, the first process it was able to open is "taskhost.exe".
Fig. 31: Dynamically executing the procedure to retrieve the process
We can see that subsequently, it reads the token information of the process; hence, it calls OpenProcessToken with the parameter "20008"
Fig. 32: Reading process token information
It also checks that the process it is going to inject into is not csrss.exe, explorer.exe, lsaas.exe or that it has a set of rights NT authority.
Fig. 33: Excluded processes
We can dynamically see how it first checks using the process token information in 140002D9C me të kuptuar nëse llogaria, të cilën të drejtat e saj po përdoren për të kryer procesin, është një llogari AUTORITETI NT.
Fig. 34: Kontrollimi i AUTORITETIT NT
Dhe më vonë, jashtë procedurës, ai kontrollon nëse kjo nuk është csrss.exe, explorer.exe ose lsaas.exe.
Fig. 35: Kontrollimi i AUTORITETIT NT
Pasi të ketë marrë një snapshot të proceseve, hap proceset dhe kontrollon që asnjë prej tyre të mos jetë përjashtuar, ai është gati të regjistrojë në memorie proceset që do të integrohen.
Për këtë, ai së pari rezervon një hapësirë në memorie (VirtualAllocEx), e shkruan atje (WriteProcessmemory) dhe krijon një proces (CreateRemoteThread). Për të punuar me këto funksione, ai përdor PID-të e proceseve të përzgjedhura, të cilat i ka marrë më parë përmes CreateToolhelp32Snapshot.
Fig. 36: Kodi për integrimin
Këtu mund të shohim dinamikisht se si ai përdor PID-in e procesit për të thirrur funksionin VirtualAllocEx.
Fig. 37: Thirrja e VirtualAllocEx
5.4 Enkriptimi
Në këtë seksion do të shqyrtojmë pjesën e këtij modeli që lidhet me enkriptimin. Në figurën e mëposhtme mund të shihni dy nënprograme të quajtur "LoadLibrary_EncodeString" dhe "Encode_Func", të cilat janë përgjegjëse për kryerjen e procedurës së enkriptimit.
Fig. 38: Procedurat e enkriptimit
Në fillim mund të shohim se si ai ngarkon një string, i cili për më vonë do të përdoret për të deobfuskatuar gjithçka që nevojitet: importet, DLL-të, komandat, skedarët dhe CSP.
Fig. 39: Zinxhiri i deobfuskimit
Në figurën e mëposhtme tregohet importi i parë që ai deobfuskatohet në regjistrin R4, LoadLibrary. Ky do të përdoret më vonë për të ngarkuar DLL-të e nevojshme. Ne gjithashtu mund të shohim një string tjetër në regjistrin R12, që përdoret së bashku me stringun e mëparshëm për të realizuar deobfuskimin.
Fig. 40: Deobfuskimi dinamik
Ai vazhdon të ngarkojë komandat që do të ekzekutojë më vonë për të ndaluar kopjet rezervë, pikët e rikthimit dhe rekuperimin në modet e sigurisë.
Fig. 41: Ngarkimi i komandave
Pastaj ai ngarkon lokacionin, ku do të hedhë 3 skedarë: Windows.bat, run.sct dhe start.bat.
Fig. 42: Lokacionet e skedarëve
Këta 3 skedarë përdoren për të kontrolluar privilegjet, që kanë secili nga lokacionet. Nëse privilegjet e kërkuara nuk janë të disponueshme, Ryuk ndalon ekzekutimin.
Ai vazhdon të ngarkojë stringet që përkojnë me tre skedarët. I pari, DECRYPT_INFORMATION.html, përmban informacionin e nevojshëm për rikuperimin e skedarëve. I dyti, PUBLIK, përmban çelësin publik RSA.
Fig. 43: Line DECRYPT INFORMATION.html
Third, UNIQUE_ID_DO_NOT_REMOVE, contains the encrypted key that will be used in the next subroutine for encryption.
Fig. 44: Line UNIQUE ID DO NOT REMOVE
Finally, it loads the necessary libraries along with the required imports and CSP (Microsoft Enhanced RSA dhe AES Cryptographic Provider).
Fig. 45: Loading Libraries
Once all deobfuscation is completed, it moves on to execute the actions required for encryption: iterating through all logical drives, performing what was loaded in the previous subroutine, enhancing presence in the system, dropping the file RyukReadMe.html, encrypting, iterating through all network drives, and moving on to detected devices for encryption.
It all starts with loading "cmd.exe" and writing the open RSA key.
Fig. 46: Preparing for Encryption
Then, it retrieves all logical drives using GetLogicalDrives and disables all backups, restore points, and safe boot modes.
Fig. 47: Deactivating Recovery Tools
After this, it enhances its presence in the system, as seen above, and writes the first file RyukReadMe.html në TEMP.
Fig. 48: Publishing Ransom Note
In the next figure, you can see how it creates a file, loads the content, and writes it:
Fig. 49: Loading and Writing File Content
To be able to perform these same actions on all devices, it uses
"icacls.exe", as we showed above.
Fig. 50: Using icalcls.exe
And finally, it starts encrypting files except for files "*.exe", "*.dll", system files, and other locations listed in an encrypted whitelist. For this, it uses the imports: CryptAcquireContextW (where AES and RSA usage is specified), CryptDeriveKey, CryptGenKey, CryptDestroyKey etc. It also attempts to extend its action to detected network devices using WNetEnumResourceW and then encrypts them.
Fig. 51: Encrypting System Files
6. Imports and Corresponding Flags
Below is a table with the list of the most relevant imports and flags used by the specimen:
7. IOC
Linket
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgramsStartupstart.bat
The technical report on the Ryuk ransomware was prepared by experts from the PandaLabs antivirus laboratory.
8. References
1. "Everis dhe Prisa Radio pësojnë një ciberkërcënim të rëndë që bllokon sistemet e tyre." https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Publikuar më 04/11/2019.
2. "Një virus me origjinë ruse sulmon kompani të mëdha spanjolle." https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Publikuar më 04/11/2019.
3. "VB2019 punim: Hakmarrja e Shinigami: bishti i gjatë i malware Ryuk." https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Publikuar më 11/12/2019.
4. "Big Game Hunting me Ryuk: Një ransomware tjetër fitimprurës." https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Publikuar më 10/01/2019.
5. "VB2019 punim: Hakmarrja e Shinigami: bishti i gjatë i malware Ryuk." https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Burimi: habr.com
