Ryuk er en af de mest berømte ransomware-muligheder i de sidste par år. Siden den først dukkede op i sommeren 2018, har den samlet , især i erhvervsmiljøet, som er hovedmålet for dets angreb.
1. Generel information
Dette dokument indeholder en analyse af Ryuk ransomware-varianten, såvel som den indlæser, der er ansvarlig for at indlæse malwaren i systemet.
Ryuk ransomware dukkede første gang op i sommeren 2018. En af forskellene mellem Ryuk og anden ransomware er, at den er rettet mod at angribe virksomhedsmiljøer.
I midten af 2019 angreb cyberkriminelle grupper et stort antal spanske virksomheder, der brugte denne ransomware.
Ris. 1: Uddrag fra El Confidencial vedrørende Ryuk ransomware-angrebet [1]
Ris. 2: Uddrag fra El País om et angreb udført ved hjælp af Ryuk ransomware [2]
Ryuk har i år angrebet en lang række virksomheder i forskellige lande. Som du kan se i nedenstående figurer, var Tyskland, Kina, Algeriet og Indien hårdest ramt.
Ved at sammenligne antallet af cyberangreb kan vi se, at Ryuk har påvirket millioner af brugere og kompromitteret en enorm mængde data, hvilket har resulteret i alvorlige økonomiske tab.
Ris. 3: Illustration af Ryuks globale aktivitet.
Ris. 4: 16 lande mest berørt af Ryuk
Ris. 5: Antal brugere angrebet af Ryuk ransomware (i millioner)
Ifølge det sædvanlige driftsprincip for sådanne trusler viser denne ransomware, efter at kryptering er fuldført, offeret en meddelelse om løsesum, der skal betales i bitcoins til den angivne adresse for at gendanne adgangen til de krypterede filer.
Denne malware har ændret sig, siden den først blev introduceret.
Varianten af denne trussel, der er analyseret i dette dokument, blev opdaget under et angrebsforsøg i januar 2020.
På grund af dens kompleksitet tilskrives denne malware ofte organiserede cyberkriminelle grupper, også kendt som APT-grupper.
En del af Ryuk-koden har en mærkbar lighed med koden og strukturen af en anden velkendt ransomware, Hermes, som de deler en række identiske funktioner med. Det er grunden til, at Ryuk i første omgang var knyttet til den nordkoreanske gruppe Lazarus, som på det tidspunkt var mistænkt for at stå bag Hermes-ransomwaren.
CrowdStrikes Falcon X-tjeneste bemærkede efterfølgende, at Ryuk faktisk blev skabt af WIZARD SPIDER-gruppen [4].
Der er nogle beviser, der understøtter denne antagelse. For det første blev denne ransomware annonceret på webstedet exploit.in, som er en velkendt russisk malwaremarkedsplads og tidligere har været forbundet med nogle russiske APT-grupper.
Dette faktum udelukker teorien om, at Ryuk kunne være blevet udviklet af Lazarus APT-gruppen, fordi det passer ikke med den måde, gruppen fungerer på.
Derudover blev Ryuk annonceret som en ransomware, der ikke vil fungere på russiske, ukrainske og hviderussiske systemer. Denne adfærd bestemmes af en funktion, der findes i nogle versioner af Ryuk, hvor den kontrollerer sproget i det system, som ransomwaren kører på, og stopper det i at køre, hvis systemet har et russisk, ukrainsk eller hviderussisk sprog. Endelig afslørede en ekspertanalyse af maskinen, der blev hacket af WIZARD SPIDER-teamet, flere "artefakter", der angiveligt blev brugt i udviklingen af Ryuk som en variant af Hermes ransomware.
På den anden side foreslog eksperterne Gabriela Nicolao og Luciano Martins, at ransomwaren kan være udviklet af APT-gruppen CryptoTech [5].
Dette følger af det faktum, at flere måneder før Ryuks fremkomst, postede denne gruppe oplysninger på forummet på det samme websted, at de havde udviklet en ny version af Hermes ransomware.
Flere forumbrugere stillede spørgsmålstegn ved, om CryptoTech faktisk skabte Ryuk. Gruppen forsvarede sig derefter og erklærede, at den havde beviser for, at de havde udviklet 100 % af ransomwaren.
2. Karakteristika
Vi starter med bootloaderen, hvis opgave er at identificere det system, den er på, så den “korrekte” version af Ryuk ransomware kan lanceres.
Bootloader-hashen er som følger:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
En af funktionerne ved denne downloader er, at den ikke indeholder nogen metadata, dvs. Skaberne af denne malware har ikke inkluderet nogen oplysninger i den.
Nogle gange inkluderer de fejlagtige data for at narre brugeren til at tro, at de kører en legitim applikation. Men som vi vil se senere, hvis infektionen ikke involverer brugerinteraktion (som det er tilfældet med denne ransomware), så anser angribere det ikke for nødvendigt at bruge metadata.
Ris. 6: Eksempel på metadata
Eksemplet blev kompileret i 32-bit format, så det kan køre på både 32-bit og 64-bit systemer.
3. Penetrationsvektor
Eksemplet, der downloader og kører Ryuk, kom ind i vores system via en fjernforbindelse, og adgangsparametrene blev opnået gennem et foreløbigt RDP-angreb.
Ris. 7: Angrebsregister
Det lykkedes angriberen at logge ind på systemet eksternt. Derefter oprettede han en eksekverbar fil med vores eksempel.
Denne eksekverbare fil blev blokeret af en antivirusløsning, før den blev kørt.
Ris. 8: Mønsterlås
Ris. 9: Mønsterlås
Da den ondsindede fil blev blokeret, forsøgte angriberen at downloade en krypteret version af den eksekverbare fil, som også blev blokeret.
Ris. 10: Sæt med prøver, som angriberen forsøgte at køre
Til sidst forsøgte han at downloade en anden ondsindet fil gennem den krypterede konsol
PowerShell til at omgå antivirusbeskyttelse. Men han blev også blokeret.
Ris. 11: PowerShell med ondsindet indhold blokeret
Ris. 12: PowerShell med ondsindet indhold blokeret
4. Læssemaskine
Når den udføres, skriver den en ReadMe-fil til mappen % Temp%, hvilket er typisk for Ryuk. Denne fil er en løsesum, der indeholder en e-mailadresse i protonmail-domænet, hvilket er ret almindeligt i denne malware-familie: [e-mail beskyttet]
Ris. 13: Løsepengekrav
Mens bootloaderen kører, kan du se, at den starter flere eksekverbare filer med tilfældige navne. De er gemt i en skjult mappe OFFENTLIG, men hvis muligheden ikke er aktiv i operativsystemet "Vis skjulte filer og mapper", så forbliver de skjulte. Desuden er disse filer 64-bit, i modsætning til den overordnede fil, som er 32-bit.
Ris. 14: Eksekverbare filer lanceret af prøven
Som du kan se på billedet ovenfor, lancerer Ryuk icacls.exe, som vil blive brugt til at ændre alle ACL'er (Access control lists), og dermed sikre adgang og ændring af flag.
Den får fuld adgang for alle brugere til alle filer på enheden (/T) uanset fejl (/C) og uden at vise nogen beskeder (/Q).
Ris. 15: Udførelsesparametre for icacls.exe lanceret af prøven
Det er vigtigt at bemærke, at Ryuk tjekker, hvilken version af Windows du kører. For dette han
udfører et versionstjek vha GetVersionExW, hvor den kontrollerer flagets værdi lpVersion Informationangiver, om den aktuelle version af Windows er nyere end Windows XP.
Afhængigt af om du kører en nyere version end Windows XP, vil opstartsindlæseren skrive til den lokale brugermappe - i dette tilfælde til mappen %Offentlig%.
Ris. 17: Kontrol af operativsystemversionen
Filen, der skrives, er Ryuk. Den kører den derefter og sender sin egen adresse som en parameter.
Ris. 18: Udfør Ryuk via ShellExecute
Det første Ryuk gør er at modtage inputparametrene. Denne gang er der to inputparametre (selve den eksekverbare og dropperadressen), der bruges til at fjerne sine egne spor.
Ris. 19: Oprettelse af en proces
Du kan også se, at når den har kørt sine eksekverbare filer, sletter den sig selv, og efterlader således ingen spor af sin egen tilstedeværelse i mappen, hvor den blev udført.
Ris. 20: Sletning af en fil
5. RYUK
5.1 Tilstedeværelse
Ryuk forsøger ligesom anden malware at blive på systemet så længe som muligt. Som vist ovenfor, er en måde at nå dette mål på i hemmelighed at oprette og køre eksekverbare filer. For at gøre dette er den mest almindelige praksis at ændre registreringsdatabasenøglen CurrentVersionRun.
I dette tilfælde kan du se, at til dette formål den første fil, der skal startes VWjRF.exe
(filnavnet er tilfældigt genereret) starter cmd.exe.
Ris. 21: Udførelse af VWjRF.exe
Indtast derefter kommandoen LØB Med navn"svchos". Således, hvis du vil tjekke registreringsdatabasenøglerne til enhver tid, kan du nemt gå glip af denne ændring, givet ligheden mellem dette navn og svchost. Takket være denne nøgle sikrer Ryuk sin tilstedeværelse i systemet. Hvis systemet ikke har endnu blevet inficeret, så når du genstarter systemet, vil den eksekverbare prøve igen.
Ris. 22: Prøven sikrer tilstedeværelse i registreringsdatabasenøglen
Vi kan også se, at denne eksekverbare stopper to tjenester:
"audioendpointbuilder", der, som navnet antyder, svarer til systemlyd,
Ris. 23: Sample stopper systemlydtjenesten
и Samss, som er en kontoadministrationstjeneste. At stoppe disse to tjenester er et kendetegn ved Ryuk. I dette tilfælde, hvis systemet er forbundet til et SIEM-system, forsøger ransomwaren at stoppe med at sende til eventuelle advarsler. På denne måde beskytter han sine næste trin, da nogle SAM-tjenester ikke vil være i stand til at starte deres arbejde korrekt efter at have udført Ryuk.
Ris. 24: Sample stopper Samss service
5.2 Privilegier
Generelt set starter Ryuk med at bevæge sig sideværts inden for netværket, eller den lanceres af en anden malware som f.eks eller , som i tilfælde af privilegieeskalering overfører disse forhøjede rettigheder til ransomwaren.
På forhånd ser vi som optakt til implementeringsprocessen ham udføre processen Efterligne sig selv, hvilket betyder, at adgangstokens sikkerhedsindhold videregives til streamen, hvor det straks vil blive hentet vha. GetCurrentThread.
Ris. 25: Ring til efterligne sig selv
Vi ser så, at det vil knytte et adgangstoken til en tråd. Vi ser også, at et af flagene er Ønsket adgang, som kan bruges til at kontrollere den adgang, som tråden vil have. I dette tilfælde skal værdien, som edx modtager, være TOKEN_ALL_ADGANG for ellers - TOKEN_WRITE.
Ris. 26: Oprettelse af et flowtoken
Så vil han bruge SeDebugPrivilege og vil foretage et opkald for at opnå debug-tilladelser på tråden, hvilket resulterer i PROCESS_ALL_ADGANG, vil han være i stand til at få adgang til enhver påkrævet proces. Nu, da kryptering allerede har en forberedt strøm, er der kun tilbage at gå videre til den sidste fase.
Ris. 27: Kalder SeDebugPrivilege og Privilege Escalation Function
På den ene side har vi LookupPrivilegeValueW, som giver os den nødvendige information om de privilegier, vi ønsker at øge.
Ris. 28: Anmod om oplysninger om privilegier til privilegieeskalering
Det har vi på den anden side Juster TokenPrivileges, som giver os mulighed for at opnå de nødvendige rettigheder til vores stream. I dette tilfælde er det vigtigste NewState, hvis flag vil give privilegier.
Ris. 29: Opsætning af tilladelser til et token
5.3 Implementering
I dette afsnit vil vi vise, hvordan prøven udfører implementeringsprocessen tidligere nævnt i denne rapport.
Hovedmålet med implementeringsprocessen, samt eskalering, er at få adgang til skyggekopier. For at gøre dette skal han arbejde med en tråd med højere rettigheder end den lokale brugers. Når først den får sådanne forhøjede rettigheder, vil den slette kopier og foretage ændringer i andre processer for at gøre det umuligt at vende tilbage til et tidligere gendannelsespunkt i operativsystemet.
Som det er typisk med denne type malware, bruger den Create ToolHelp32Snapshotså det tager et øjebliksbillede af de aktuelt kørende processer og forsøger at få adgang til disse processer vha OpenProcess. Når først den får adgang til processen, åbner den også et token med dens information for at få procesparametrene.
Ris. 30: Hentning af processer fra en computer
Vi kan dynamisk se, hvordan den får listen over kørende processer i rutine 140002D9C ved hjælp af CreateToolhelp32Snapshot. Efter at have modtaget dem, går han gennem listen og prøver at åbne processer én efter én ved hjælp af OpenProcess, indtil det lykkes. I dette tilfælde var den første proces, han kunne åbne "taskhost.exe".
Ris. 31: Udfør dynamisk en procedure for at få en proces
Vi kan se, at den efterfølgende læser procestokeninformationen, så den kalder OpenProcessToken med parameter "20008"
Ris. 32: Læs procestokenoplysninger
Den kontrollerer også, at den proces, den vil blive sprøjtet ind i, ikke er det Csrss.exe, explorer.exe, lsaas.exe eller at han har et sæt rettigheder NT myndighed.
Ris. 33: Udelukkede processer
Vi kan dynamisk se, hvordan den først udfører kontrollen ved hjælp af procestokeninformationen i 140002D9C for at finde ud af, om den konto, hvis rettigheder bliver brugt til at udføre en proces, er en konto NT MYNDIGHED.
Ris. 34: NT MYNDIGHED kontrol
Og senere, uden for proceduren, tjekker han, at det ikke er det csrss.exe, explorer.exe eller lsaas.exe.
Ris. 35: NT MYNDIGHED kontrol
Når han har taget et øjebliksbillede af processerne, åbnet processerne og bekræftet, at ingen af dem er udelukket, er han klar til at skrive til hukommelsen de processer, der vil blive injiceret.
For at gøre dette reserverer den først et område i hukommelsen (VirtualAllocEx), skriver ind i det (Skriveproceshukommelse) og opretter en tråd (Opret RemoteThread). For at arbejde med disse funktioner bruger den PID'erne for de valgte processer, som den tidligere har opnået ved hjælp af Create Toolhelp32Snapshot.
Ris. 36: Integrer kode
Her kan vi dynamisk observere, hvordan den bruger processen PID til at kalde funktionen VirtualAllocEx.
Ris. 37: Ring til VirtualAllocEx
5.4 Kryptering
I dette afsnit vil vi se på krypteringsdelen af denne prøve. På det følgende billede kan du se to underrutiner kaldet "LoadLibrary_EncodeString"og"Encode_Func", som er ansvarlige for at udføre krypteringsproceduren.
Ris. 38: Krypteringsprocedurer
I begyndelsen kan vi se, hvordan den indlæser en streng, der senere vil blive brugt til at deobfuscate alt, hvad der er nødvendigt: importer, DLL'er, kommandoer, filer og CSP'er.
Ris. 39: Deobfusceringskredsløb
Følgende figur viser den første import, den deobfuskerer i register R4. Indlæs bibliotek. Dette vil blive brugt senere til at indlæse de nødvendige DLL'er. Vi kan også se en anden linje i register R12, som bruges sammen med den forrige linje til at udføre deobfuscation.
Ris. 40: Dynamisk deobfuscation
Det fortsætter med at downloade kommandoer, som det vil køre senere for at deaktivere sikkerhedskopier, gendannelsespunkter og sikker opstartstilstand.
Ris. 41: Indlæser kommandoer
Derefter indlæser den placeringen, hvor den vil slippe 3 filer: Windows.bat, run.sct и start.bat.
Ris. 42: Filplaceringer
Disse 3 filer bruges til at kontrollere de privilegier, som hver lokation har. Hvis de nødvendige privilegier ikke er tilgængelige, stopper Ryuk eksekveringen.
Den fortsætter med at indlæse linjerne svarende til de tre filer. Først, DECRYPT_INFORMATION.html, indeholder oplysninger, der er nødvendige for at gendanne filer. Anden, OFFENTLIG, indeholder den offentlige RSA-nøgle.
Ris. 43: Linje DEKRYPTERING INFORMATION.html
Tredje, UNIQUE_ID_DO_NOT_REMOVE, indeholder den krypterede nøgle, der vil blive brugt i den næste rutine til at udføre krypteringen.
Ris. 44: Linje UNIKT ID FJERNES IKKE
Til sidst downloader den de nødvendige biblioteker sammen med de nødvendige importer og CSP'er (Microsoft Enhanced RSA и AES kryptografisk udbyder).
Ris. 45: Indlæsning af biblioteker
Efter at al deobfuskering er fuldført, fortsætter den med at udføre de handlinger, der kræves til kryptering: optælling af alle logiske drev, udførelse af det, der blev indlæst i den forrige rutine, styrkelse af tilstedeværelsen i systemet, smid RyukReadMe.html-filen, kryptering, optælling af alle netværksdrev , overgang til detekterede enheder og deres kryptering.
Det hele starter med indlæsning"cmd.exe" og RSA offentlige nøgleregistreringer.
Ris. 46: Forberedelse til kryptering
Så får den alle logiske drev ved hjælp af GetLogicalDrives og deaktiverer alle sikkerhedskopier, gendannelsespunkter og sikker opstartstilstand.
Ris. 47: Deaktivering af genoprettelsesværktøjer
Derefter styrker den sin tilstedeværelse i systemet, som vi så ovenfor, og skriver den første fil RyukReadMe.html в TEMP.
Ris. 48: Offentliggørelse af en meddelelse om løsesum
På det følgende billede kan du se, hvordan den opretter en fil, downloader indholdet og skriver det:
Ris. 49: Indlæsning og skrivning af filindhold
For at kunne udføre de samme handlinger på alle enheder, bruger han
"icacls.exe", som vi viste ovenfor.
Ris. 50: Brug af icalcls.exe
Og endelig begynder den at kryptere filer med undtagelse af "*.exe", "*.dll"-filer, systemfiler og andre placeringer angivet i form af en krypteret hvidliste. For at gøre dette bruger den importer: CryptAcquireContextW (hvor brugen af AES og RSA er specificeret), CryptDeriveKey, CryptGenKey, CryptDestroyKey etc. Den forsøger også at udvide sin rækkevidde til opdagede netværksenheder ved hjælp af WNetEnumResourceW og derefter kryptere dem.
Ris. 51: Kryptering af systemfiler
6. Import og tilhørende flag
Nedenfor er en tabel, der viser de mest relevante importer og flag brugt af prøven:
7. IOC
RЎSЃS <P "RєRё
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgrammerStartupstart.bat
En teknisk rapport om Ryuk ransomware blev udarbejdet af eksperter fra antiviruslaboratoriet PandaLabs.
8. Links
1. "Everis y Prisa Radio sufren un grave ciberataque que secuestra sus sistemas."https://www. elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, offentliggjort 04/11/2019.
2. "Un virus de origen ruso ataca a importantes empresas españolas." https: //elpais.com/tecnologia/2019/11/04/actualidad/1572897654_ 251312.html, Publicada el 04/11/2019.
3. "VB2019 paper: Shinigami's revenge: the long tail of the Ryuk malware." https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Publicada el 11 /12/2019
4. “Big Game Hunting with Ryuk: Another LucrativebTargeted Ransomware.” https://www. crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, offentliggjort den 10/01/2019.
5. “VB2019-papir: Shinigamis hævn: Ryuk-malwarens lange hale.” https://www. virusbulletin.com/virusbulletin/2019/10/ vb2019-paper-shinigamis-revenge-long-tail-r
Kilde: www.habr.com