Ryuk është një nga variantet më të njohura të enkriptueseve gjatë disa viteve të fundit. Që kur u shfaq për herë të parë gjatë verës së vitit 2018, ai ka grumbulluar , sidomos në mjedisin e biznesit, i cili është objekti kryesor i sulmeve të tij.
1. Informacion i përgjithshëm
Ky dokument përmban një analizë të variantit të enkriptueseve Ryuk, si dhe të ngarkuesit përgjegjës për ngarkimin e softuerit të dëmshëm në sistem.
Enkriptueseja Ryuk u shfaq për herë të parë gjatë verës së vitit 2018. Një nga dallimet e Ryuk nga enkriptuestë të tjerë është se ai përqendrohet në sulmet ndaj mjediseve korporative.
Në mes të vitit 2019, grupet kriminale të cyber sulmuan një numër të madh kompanish spanjolle me këtë enkriptuese.
Fig. 1: Ekstrakt nga El Confidencial në lidhje me sulmin e enkriptueseve Ryuk [1]
Fig. 2: Ekstrakt nga El País për sulmin të realizuar me enkriptuese Ryuk [2]
Këtë vit, Ryuk sulmoi një numër të madh kompanish në vende të ndryshme. Siç mund të shihni në figurat e mëposhtme, më së shumti u goditën Gjermania, Kina, Algjeria dhe India.
Duke krahasuar numrin e sulmeve të cyber, mund të shohim se Ryuk ka goditur miliona përdorues dhe ka komprometuar një volum të madh të të dhënave, çka ka sjellë dëme të rënda ekonomike.
Fig. 3: Ilustrimi i aktivitetit global të Ryuk.
Fig. 4: 16 vendet më të prekura nga Ryuk
Fig. 5: Numri i përdoruesve të sulmuar nga enkriptuese Ryuk (në miliona)
Sipas parimit të zakonshëm të funksionimit të këtyre kërcënimeve, kjo enkriptuese pas përfundimit të enkriptimit tregon viktimës një lajmërim për shpërblim, i cili duhet të paguhet në bitcoin në adresën përkatëse për të rikuperuar qasjen në skedarët e enkriptuar.
Ky softuer i dëmshëm ka evoluar që nga shfaqja e tij e parë.
Varianti i kësaj kërcënimi i analizuar në këtë dokument u zbulua gjatë një tentative për sulm në janar të vitit 2020.
Për shkak të kompleksitetit të tij, ky softuer i dëmshëm shpesh i atribuohet grupeve kriminale të organizuara të cyber, të njohura gjithashtu si grupet APT.
Pjesa e kodit të Ryuk ka një ngjashmëri të dukshme me kodin dhe strukturën e enkriptueseve të njohur Hermes, me të cilat kanë një seri funksionesh të përbashkëta. Pikërisht për këtë arsye, në fillim Ryuk u lidhej me grupin nord-korean Lazarus, i cili atëherë ishte i dyshuar se qëndronte pas enkriptueseve Hermes.
Më vonë, shërbimi Falcon X i kompanisë CrowdStrike vuri në dukje se në të vërtetë Ryuk ishte krijuar nga grupi WIZARD SPIDER [4].
Ka disa prova që mbështesin këtë supozim. Së pari, kjo enkriptuese u promovua në faqen e internetit exploit.in, e cila është një treg i njohur rus për softuer të dëmshëm dhe është lidhur më parë me disa grupe APT ruse.
Ky fakt përjashton teorinë se Ryuk mund të ishte zhvilluar nga grupi APT Lazarus, pasi nuk përputhet me mënyrën e veprimit të këtij grupi.
Për më tepër, Ryuk është promovuar si një enkriptuese që nuk do të funksionojë në sistemet ruse, ukrainase dhe bjellorusë. Ky qëndrim përcaktohet nga funksioni, i zbuluar në disa versione të Ryuk, ku ai kontrollon gjuhën e sistemit në të cilin është aktivizuar kjo enkriptuese dhe ndalon operimin e saj nëse sistemi ka gjuhën ruse, ukrainase ose bjelloruse. Së fundi, gjatë analizës ekspertizës së makinerisë që u komprometua nga grupi WIZARD SPIDER, u zbuluan disa "artefakte" që supozohet se ishin përdorur gjatë zhvillimit të Ryuk si një variant i enkriptueseve Hermes.
Nga ana tjetër, ekspertët Gabriela Nicollao dhe Luciano Martins sugjeruan se enkriptueseja mund të jetë zhvilluar nga grupi APT CryptoTech [5].
Kjo del nga fakti se disa muaj para shfaqjes së Ryuk, ky grup publikoi në forumin e njëjtë të faqes informacionin se kishin zhvilluar një version të ri të enkriptueseve Hermes.
Disa përdorues në forum u pyetën nëse vërtet CryptoTech e kishte krijuar Ryuk. Pas kësaj, ky grup mbrojti veten dhe deklaroi se kishte prova se kishin zhvilluar 100% të kësaj enkriptueseje.
2. Karakteristikat
Ne fillojmë me ngarkuesin, i cili ka detyrën të identifikojë sistemin në të cilin ndodhet, në mënyrë që të mund të aktivizohet versioni "i duhur" i enkriptueseve Ryuk.
Hashi i ngarkuesit është si më poshtë:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
Një nga karakteristikat e këtij ngarkuesi është se ai nuk përmban asnjë meta-datash, dmth krijuesit e këtij softueri të dëmshëm nuk përfshinë asnjë informacion në të.
Herë pas here ata përfshijnë të dhëna të gabuara për të bërë që përdoruesi të mendojë se po nis një aplikacion legjitim. Sidoqoftë, siç do të shohim më vonë, nëse infeksioni nuk kërkon ndërveprim nga përdoruesi (si në rastin e këtij ransomware), atëherë këta sulmues nuk e konsiderojnë të nevojshme të përdorin meta-të dhënat.
Fig. 6: Meta-të dhëna të mostrës
Mostra është kompiluar në format 32-bit, për ta bërë atë të mundshme për të funksionuar si në sisteme 32-bit ashtu dhe 64-bit.
3. Vektori i depërtimit
Mostra që shkarkon 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ë mëparshëm RDP.
Fig. 7: Regjistri i sulmit
Sulmuesi arriti të hynte në sistem në distancë. Pas kësaj, ai krijoi një skedar ekzekutiv me mostrën tonë.
Ky skedar ekzekutiv u bllokua nga zgjidhja antivirusore para se të ekzekutohej.
Fig. 8: Bllokimi i mostrës
Fig. 9: Bllokimi i mostrës
Kur skedari i keq ishte bllokuar, sulmuesi përpiqej të shkarkonte një version të enkriptuar të skedarit ekzekutiv, i cili gjithashtu u bllokua.
Fig. 10: Grupi i mostrave që sulmuesi përpiqej të ekzekutonte
Në fund, ai përpiqej të shkarkonte një tjetër skedar keqdashës përmes një konsole të enkriptuar
PowerShell për të anashkaluar mbrojtjen antivirusore. Por ai gjithashtu u bllokua.
Fig. 11: PowerShell me përmbajtje keqdashëse të bllokuar
Fig. 12: PowerShell me përmbajtje keqdashëse të bllokuar
4. Lodhësi
Kur ekzekutohet, ai shkruan një skedë ReadMe në folderin %temp%, gjë që është tipike për Ryuk. Ky skedar është një kërkesë për shpërblim, që përmban një adresë emaili në domenin protonmail, i cili është mjaft i zakonshëm në këtë familje të malware-ve: msifelabem1981@protonmail.com
Fig. 13: Kërkesa për shpërblim
Gjatë ekzekutimit të lodhësit, mund të shihni se ai nis disa skedarë ekzekutivë me emra të rastësishëm. Ato ruhen në një folder të fshehtë PUBLIC, por nëse opsioni i sistemit operativ për "Trego skedarët dhe folderat e fshehtë", nuk është aktiv, ato do të mbeten të fshehura. Më tepër, këto skedarë janë 64-bit në dallim me skedarin prind, i cili është 32-bit.
Fig. 14: Skedarët ekzekutivë që iniciohen nga mostra
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 gjithë listat e kontrollit të aksesit ACL, duke garantuar kështu qasje dhe ndryshim të flagjeve.
Ai merr qasje të plotë nën të gjithë përdoruesit në të gjithë skedarët në pajisje (/T) pavarësisht gabimeve (/C) dhe pa treguar ndonjë mesazh (/Q).
Fig. 15: Parametrat e ekzekutimit të icacls.exe, të nisur nga mostra
Është e rëndësishme të merret parasysh se Ryuk kontrollon versionin e Windows që është i aktivizuar. Për këtë, ai
bën një kontroll versioni me GetVersionExW, ku kontrollon vlerën e flagut lpVersionInformation, që tregon nëse versioni aktual i Windows është më i ri se Windows XP.
Në varësi të asaj nëse keni një version më të ri se Windows XP, lodhësi do të shkruajë në folderin e përdoruesit lokal - në këtë rast në folderin %Public%.
Fig. 17: Kontrolli i versionit të sistemit operativ
Skedari i shkruar është Ryuk. Më pas ai e inicializon atë, duke kaluar adresën e vet si parametrin.
Fig. 18: Ekzekutimi i Ryuk përmes ShellExecute
E para që bën Ryuk është të marrë parametrat hyrës. Këtë herë ka dy parametra hyrës (vetë skedari ekzekutiv dhe adresa e dropper), që përdoren për të hequr gjurmët e tij.
Fig. 19: Krijimi i procesit
Ju gjithashtu mund të shihni se sapo ai ka inicializuar skedarët e tij ekzekutivë, ai e fshin veten, duke mos lënë asnjë gjurmë të pranisë së tij në atë folder ku ka funksionuar.
Fig. 20: Fshirja e skedarit
5. RYUK
5.1 Prania
Ryuk, ashtu si malware të tjerë, përpiqet të qëndrojë në sistem sa më gjatë të jetë e mundur. Siç u tregua më parë, një nga mënyrat për të arritur këtë qëllim është krijimi dhe ekzekutimi i fshehtë i skedarëve ekzekutivë. Për këtë, praktika më e zakonshme është ndryshimi i çelësit të regjistrit CurrentVersionRun.
Në këtë rast, ju mund të shihni se për këtë qëllim skedari i parë ekzekutiv VWjRF.exe
(emri i skedarit gjenerohet rastësisht) ekzekuton cmd.exe.
Fig. 21: Ekzekutimi i skedarit VWjRF.exe
Më pas futet një komandë RUN me emrin "svchos". Kështu, nëse dëshironi të kontrolloni çelësat e regjistrit në çdo moment, do të jeni në gjendje ta bëni këtë pa vënë re ndryshimin, duke marrë parasysh ngjashmërinë e këtij emri me svchost. Falë këtij çelësi, Ryuk siguron praninë e tij në sistem. Nëse sistemi nuk është infektuar ende, kur të ripërshtatni sistemin, ekzekutuesi do të provojë sërish.
Shk. 22: Një mostër siguron praninë në çelësin e regjistrit
Ne gjithashtu mund të shohim se ky ekzekutues ndalon dy shërbime:
"audioendpointbuilder", e cila, siç e thotë emri, është përkatëse për audion e sistemit,
Shk. 23: Një mostër ndalon shërbimin e audios së sistemit
dhe samss, e cila është shërbimi i menaxhimit të llogarive. Ndalimi i këtyre dy shërbimeve është një karakteristikë e Ryuk. Në këtë rast, nëse sistemi lidhet me një sistem SIEM, atëherë kriptuesi përpiqet të ndalojë dërgimin e ndonjë njoftimi. Kështu, ai mbron hapat e tij të ardhshëm, pasi disa shërbime SAM nuk do të mund të fillojnë siç duhet pas ekzekutimit të Ryuk.
Shk. 24: Një mostër ndalon shërbimin Samss
5.2 Privilegjet
Në përgjithësi, Ryuk fillon me një lëvizje horizontale brenda rrjetit ose aktivizohet nga një program tjetër keqdashës, i tillë si ose , të cilat në rast të ngritjes së privilegjeve i kalojnë këto të drejta të shtysës kriptuesit.
Më herët, si një hyrje në procesin e infiltrimit, ne shohim se ai ekzekuton procesin ImpersonateSelf, që do të thotë se përmbajtja e sigurisë së çelësit të aksesit do të kalojë në rrjedhën, ku do të merret menjëherë me GetCurrentThread.
Shk. 25: Thirrja ImpersonateSelf
Pastaj ne shohim se ai do ta lidhë çelësin e aksesit me rrjedhën. Ne gjithashtu shohim se një nga flamujt është DesiredAccess, i cili mund të përdoret për kontrollin e aksesit që do të ketë rrjedha. Në këtë rast, vlera që do të marrë edx, duhet të jetë TOKEN_ALL_ACCESS ose ndryshe— TOKEN_WRITE.
Shk. 26: Krijimi i çelësit të rrjedhës
Më pas ai do të përdorë SeDebugPrivilege dhe do të bëjë një thirrje për të marrë të drejtat e ndihmës Debug në lidhje me rrjedhën, si rezultat i së cilës, duke treguar PROCESS_ALL_ACCESS, ai do të mund të ketë akses në çdo proces të kërkuar. Tani, duke marrë parasysh se kriptuesi tashmë ka përgatitur rrjedhën, është vetëm çështje për të kaluar në fazën përfundimtare.
Shk. 27: Thirrja SeDebugPrivilege dhe funksioni i ngritjes së privilegjeve
Nga njëra anë, ne kemi LookupPrivilegeValueW, që na ofron informacionin e nevojshëm për privilegjet që duam të rrisim.
Shk. 28: Kërkesa për informacion mbi privilegjet për t'i rritur ato
Nga ana tjetër, ne kemi AdjustTokenPrivileges, i cili lejon të marrim të drejtat e nevojshme për rrjedhën tonë. Në këtë rast, më e rëndësishmja është NewState, flamuji i të cilit do të ofrojë privilegjet.
Shk. 29: Rregullimi i të drejtave për çelësin
5.3 Infiltrimi
Në këtë seksion do të tregojmë se si mostra ekzekuton procesin e infiltrimit, të përmendur më parë në këtë raport.
Qëllimi kryesor i procesit të infiltrimit, ashtu si dhe ai i ngritjes, është sigurimi i aksesit në kopje të errëta. Për këtë, është e nevojshme që ai të punojë me një rrjedhë me privilegje më të larta se ato të përdoruesit lokal. Sa herë që ai siguron të drejta më të larta, ai do të fshijë kopjet dhe do të bëjë ndryshime në procese të tjera për të bërë të pamundur rikthimin në një pikë më të hershme rikthimi në sistemin operacional.
Si ndodh zakonisht me këtë lloj programi të dëmshëm, për të realizuar infiltrimin, ai përdor CreateToolHelp32Snapshot, kështu që ai bën një kapje të proceseve që janë aktualisht duke u ekzekutuar dhe përpiqet të aksesojë këto procese me OpenProcess. Sapo ai të ketë akses në një proces, ai gjithashtu hap një çelës me informacionin e tij për të marrë parametrat e procesit.
Shk. 30: Marrja e proceseve nga kompjuteri
Ne mund të shohim dinamikisht se si ai merr listën e proceseve të ekzekutuar në nëndritën 140002D9C duke përdorur CreateToolhelp32Snapshot. Pas marrjes së tyre, ai kalon nëpër listë, duke përpiquar një e nga një të hapë proceset me OpenProcess derisa t'i dalë. Në këtë rast, procesi i parë që arriti ta hapë ishte "taskhost.exe".
Shk. 31: Ekzekutimi dinamik i procedurës për marrjen e procesit
Ne mund të shohim se më pas ai lexon informacionin e çelësit të procesit, kështu që ai bën thirrje OpenProcessToken me parametrin "20008"
Shk. 32: Leximi i informacionit të çelësit të procesit
Ai gjithashtu kontrollon se procesi në të cilin do të infiltron nuk është csrss.exe, explorer.exe, lsaas.exe apo se ai ka një grup të drejtash NT authority.
Shk. 33: Proceset e përjashtuara
Ne mund të shohim dinamikisht se si ai fillimisht kryen një kontroll duke përdorur informacionin e çelësit të procesit në 140002D9C me qëllim për të verifikuar nëse llogaria, e cila ka të drejtat e përdorura për të kryer procesin, është llogaria NT AUTHORITY.
Fig. 34: Verifikimi i NT AUTHORITY
Dhe më vonë, jashtë procedurës, ai kontrollon që kjo të mos jetë csrss.exe, explorer.exe ose lsaas.exe.
Fig. 35: Verifikimi i NT AUTHORITY
Pas përllogaritjes së proceseve, hapësirën e proceseve dhe verifikimit që asnjëra prej tyre nuk është e përjashtuar, ai është gati të regjistrojë në memorje proceset që do të inkuadrohen.
Për këtë, ai së pari rezervon një zonë në memorje (VirtualAllocEx), e shkruan në të (WriteProcessmemory) dhe krijon një thread (CreateRemoteThread). Për të punuar me këto funksione, ai përdor PID-të e proceseve të zgjedhura, të cilat i ka marrë më parë me CreateToolhelp32Snapshot.
Fig. 36: Kodia për inkuadrimin
Këtu ne mund të shohim në mënyrë dinamike se si ai përdor PID-in e procesit për të thirrur funksionin VirtualAllocEx.
Fig. 37: Thirrja e VirtualAllocEx
5.4 Kriptimi
Në këtë seksion ne do të shqyrtojmë pjesën e këtij mostri që ka të bëjë me kriptimin. Në figurën e ardhshme mund të shihni dy nënprograme të quajtura "LoadLibrary_EncodeString" dhe "Encode_Func", të cilat janë përgjegjëse për kryerjen e procedurës së kriptimit.
Fig. 38: Procedurat e kriptimit
Fillimisht ne mund të shohim se si ai ngarkon një varg, i cili më vonë do të përdoret për deobfuskimin e gjithçkaje të nevojshme: importet, DLL-të, komandat, skedarët dhe CSP.
Fig. 39: Zinxhiri i deobfuskimit
Në figurën e ardhshme tregohet importi i parë, i cili ai deobfuskon në regjistrin R4, LoadLibrary. Kjo do të përdoret më vonë për të ngarkuar DLL-të e nevojshme. Ne gjithashtu mund të shohim një varg tjetër në regjistrin R12, i cili përdoret së bashku me vargun e mëparshëm për të kryer deobfuskimin.
Fig. 40: Deobfuskimi dinamik
Ai vazhdon të ngarkojë komandat që do të kryejë më vonë për të ç aktivizuar kopjet rezervë, pikat e rikthimit dhe modet e sigurisë të ngarkesës.
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ëto 3 skedarë përdoren për të verifikuar privilegjet që ka secili nga lokacionet. Nëse privilegjet e kërkuara nuk janë të disponueshme, Ryuk ndalon ekzekutimin.
Ai vazhdon të ngarkojë vargjet përkatëse për tre skedarët. E para, DECRYPT_INFORMATION.html, përmban informacionin e nevojshëm për rikthimin e skedarëve. E dyta, PUBLIC, përmban çelësin publik RSA.
Fig. 43: Vargu DECRYPT INFORMATION.html
E treta, UNIQUE_ID_DO_NOT_REMOVE, përmban çelësin e enkriptuar, i cili do të përdoret në nënprogramin e ardhshëm për të kryer kriptimin.
Fig. 44: Vargu UNIQUE ID DO NOT REMOVE
Më në fund, ai ngarkon bibliotekat e nevojshme së bashku me importet e kërkuara dhe CSP (Microsoft Enhanced RSA dhe AES Cryptographic Provider).
Fig. 45: Ngarkimi i bibliotekave
Pasi deobfuskimi të mbarojë, ai kalon në kryerjen e veprimeve të nevojshme për kriptimin: kalimi nëpër të gjitha diskët logjikë, kryerja e asaj që është ngarkuar në nënprogramin e mëparshëm, përmirësimi i pranisë në sistem, hedhja e skedarit RyukReadMe.html, kriptimi, kalimi nëpër të gjitha diskët rrjetërore, kalimi në pajisjet e zbuluara dhe kriptimi i tyre.
Të gjitha fillon me ngarkimin e "cmd.exe" dhe shkrimin e çelësit të hapur RSA.
Fig. 46: Përgatitja për kriptimin
Pastaj ai merr të gjitha diskët logjikë me ndihmën e GetLogicalDrives dhe dezaktivon të gjitha kopjet rezervë, pikat e rikthimit dhe modet e sigurisë të ngarkesës.
Fig. 47: Deaktivizimi i mjeteve të rikthimit
Pas kësaj, ai forcon praninë e tij në sistem, siç e pamë më sipër, dhe shkruan skedarin e parë RyukReadMe.html në TEMP.
Fig. 48: Publikimi i njoftimit për shpërblim
Në figurën e ardhshme mund të shihni se si ai krijon një skedar, ngarkon përmbajtjen dhe e shkruan atë:
Fig. 49: Ngarkimi dhe shkruajtja e përmbajtjes së skedarit
Për t'iu dhënë mundësinë për të kryer këto veprime të njëjtat në të gjitha pajisjet, ai përdor
"icacls.exe", siç e treguam më sipër.
Fig. 50: Përdorimi i icalcls.exe
Dhe, në fund, ai fillon të kriptojë skedarët përveç skedarëve "*.exe", "*.dll", skedarëve sistemikë dhe lokacioneve të tjera të caktuara si një listë të bardhë të enkriptuar. Për këtë, ai përdor importet: CryptAcquireContextW (ku përcaktohet përdorimi i AES dhe RSA), CryptDeriveKey, CryptGenKey, CryptDestroyKey etj. Gjithashtu, bëhet një përpjekje për të zgjeruar veprimin e tij në pajisjet rrjetërore të zbuluara me ndihmën e WNetEnumResourceW dhe më pas për të kriptuar ato.
Fig. 51: Kriptimi i skedarëve sistemikë
6. Importet dhe flamujt përkatës
Më poshtë është një tabelë që liston importet dhe flamujt më të rëndësishëm të përdorur në mostër:
7. IOC
Linke
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgramsStartupstart.bat
Raporti teknik mbi kriptuesin Ryuk është përgatitur nga ekspertët e laboratorit antivirus PandaLabs.
8. Referenca
1. “Everis dhe Prisa Radio përballen me një sulm të rëndë kibernetik 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ë rëndësishme spanjolle.”https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Publikuar më 04/11/2019.
3. “Paper i VB2019: Hakmarrja e Shinigami-t: bishti i gjatë i malware-it Ryuk.”https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Publikuar më 11/12/2019
4. “Gjuetia në lojë të madhe me Ryuk: një ransomware tjetër tërheqës.”https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Publikuar më 10/01/2019.
5. “Paper i VB2019: Hakmarrja e Shinigami-t: bishti i gjatë i malware-it Ryuk.”https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Burimi: habr.com
