Ryuk er en af de mest kendte ransomware-varianter i de seneste år. Siden den første gang dukkede op i sommeren 2018, har den samlet sig , især i forretningsmiljøet, som er hovedmålet for hans angreb.
1. Generel information
Dette dokument indeholder en analyse af en variant af Ryuk ransomware, samt 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 andre ransomware-programmer er, at de er rettet mod at angribe virksomhedsmiljøer.
I midten af 2019 angreb cyberkriminelle grupper et stort antal spanske virksomheder ved hjælp af denne ransomware.
Ris. 1: Uddrag fra El Confidencial om Ryuk ransomware-angrebet [1]
Ris. 2: Uddrag fra El País om angrebet udført med Ryuk ransomware [2]
I år har Ryuk angrebet et stort antal virksomheder i forskellige lande. Som det fremgår af tallene nedenfor, blev Tyskland, Kina, Algeriet og Indien hårdest ramt.
Hvis vi sammenligner antallet af cyberangreb, kan vi se, at Ryuk påvirkede millioner af brugere og kompromitterede en enorm mængde data, hvilket forårsagede alvorlig økonomisk skade.
Ris. 3: Illustration af Ryuks globale aktivitet.
Ris. 4: 16 lande hårdest ramt af Ryuk
Ris. 5: Antal brugere angrebet af Ryuk ransomware (i millioner)
I henhold til det sædvanlige driftsprincip for sådanne trusler viser denne ransomware, efter at have gennemført krypteringen, offeret en løsesumsmeddelelse, der skal betales i bitcoins til den angivne adresse for at genoprette adgangen til de krypterede filer.
Denne malware har ændret sig, siden den først dukkede op.
Den variant af denne trussel, der analyseres i denne artikel, blev opdaget under et angrebsforsøg i januar 2020.
På grund af dens kompleksitet tilskrives denne malware ofte organiserede cyberkriminalitetsgrupper, også kendt som APT-grupper.
Noget af Ryuk-koden har en mærkbar lighed med koden og strukturen i en anden velkendt ransomware, Hermes, som de deler en række af de samme funktioner med. Derfor blev Ryuk oprindeligt forbundet med den nordkoreanske gruppe Lazarus, som på daværende tidspunkt var mistænkt for at stå bag Hermes-ransomwaren.
CrowdStrikes Falcon X-tjeneste bemærkede senere, at Ryuk faktisk blev skabt af WIZARD SPIDER-gruppen [4].
Der er nogle beviser, der understøtter denne antagelse. Først blev denne ransomware annonceret på hjemmesiden exploit.in, som er en velkendt russisk malware-markedsplads og tidligere har været forbundet med nogle russiske APT-grupper.
Denne kendsgerning udelukker teorien om, at Ryuk kunne være blevet udviklet af APT-gruppen Lazarus, da dette ikke passer med, hvordan gruppen fungerer.
Derudover blev Ryuk annonceret som en ransomware, der ikke ville virke på russiske, ukrainske og hviderussiske systemer. Denne adfærd bestemmes af en funktion, der findes i nogle versioner af Ryuk, hvor den kontrollerer sproget på det system, som ransomware kører på, og stopper det, hvis systemet har russisk, ukrainsk eller hviderussisk sprog. Endelig, under en ekspertanalyse af den maskine, der blev hacket af WIZARD SPIDER-gruppen, blev der opdaget adskillige "artefakter", der formodentlig blev brugt i udviklingen af Ryuk som en variant af Hermes-ransomwaren.
På den anden side antydede eksperterne Gabriela Nicolao og Luciano Martins, at ransomware muligvis var udviklet af APT-gruppen CryptoTech [5].
Dette følger af, at denne gruppe flere måneder før Ryuk dukkede op, skrev på samme websteds forum, at de havde udviklet en ny version af Hermes ransomware.
Flere forumbrugere stillede spørgsmålstegn ved, om CryptoTech rent faktisk skabte Ryuk. Efter dette forsvarede gruppen sig selv og udtalte, at den havde beviser for, at de havde udviklet 100% af denne ransomware.
2. Karakteristika
Vi starter med bootloaderen, hvis opgave er at identificere det system, den er på, så den "korrekte" version af Ryuk ransomware kan køres.
Bootloader-hashen er som følger:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
En af funktionerne ved denne loader er, at den ikke indeholder nogen metadata, dvs. skaberne af denne malware inkluderede ingen oplysninger i den.
Nogle gange inkluderer de falske oplysninger for at narre brugeren til at tro, at de starter en legitim applikation. Men som vi vil se senere, anser angriberne det ikke for nødvendigt at bruge metadata, hvis infektionen ikke involverer brugerinteraktion (som det er tilfældet med denne ransomware).
Ris. 6: Eksempelmetadata
Eksemplet blev kompileret i 32-bit format, så det kan køres på både 32-bit og 64-bit systemer.
3. Penetrationsvektor
Prøven, der downloader og kører Ryuk, kom ind i vores system via en fjernforbindelse, og legitimationsoplysningerne blev indhentet gennem et indledende RDP-angreb.
Ris. 7: Angrebsregister
Angriberen formåede at logge ind på systemet via fjernadgang. Derefter oprettede han en eksekverbar fil med vores eksempel.
Denne eksekverbare fil blev blokeret af en antivirusløsning, før den kørte.
Ris. 8: Eksempellås
Ris. 9: Eksempellås
Da den skadelige fil var låst, forsøgte angriberen at downloade en krypteret version af den eksekverbare fil, som også var låst.
Ris. 10: Det sæt af prøver, som angriberen forsøgte at køre
Endelig forsøgte han at downloade en anden ondsindet fil via den krypterede konsol.
PowerShell til at omgå antivirusbeskyttelse. Men den blev også blokeret.
Ris. 11: PowerShell med blokeret skadeligt indhold
Ris. 12: PowerShell med blokeret skadeligt indhold
4. Læssemaskine
Når den kører, skriver den en ReadMe-fil til mappen % Temp%, hvilket er typisk for Ryuk. Den pågældende fil er en løsesumsnota, der indeholder en e-mailadresse i protonmail-domænet, hvilket er ret almindeligt i denne malware-familie: msifelabem1981@protonmail.com
Ris. 13: Krav om løsesum
Mens bootloaderen kører, kan du muligvis se, at den starter flere eksekverbare filer med tilfældige navne. De er gemt i en skjult mappe. OFFENTLIG, men hvis indstillingen ikke er aktiv i operativsystemet "Vis skjulte filer og mapper", så vil de forblive skjulte. Desuden er disse filer 64-bit, i modsætning til den overordnede fil, som er 32-bit.
Ris. 14: Eksekverbare filer kørt af eksemplet
Som du kan se i ovenstående figur, kører Ryuk icacls.exe, som vil blive brugt til at ændre alle ACL'er (adgangskontrollister), og dermed sikre adgang og markere ændringer.
Den giver fuld adgang under alle brugere til alle filer på enheden (/T), uanset fejl (/C) og uden at vise nogen meddelelser (/Q).
Ris. 15: Udførelsesparametre for icacls.exe startet af eksemplet
Det er vigtigt at bemærke, at Ryuk tjekker, hvilken version af Windows du kører. Til dette han
udfører en versionskontrol ved hjælp af GetVersionExW, hvor den kontrollerer værdien af flaget lpVersionsinformation, som viser, 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 bootloaderen skrive til den lokale brugermappe - i dette tilfælde mappen %Offentlig%.
Ris. 17: Kontrol af operativsystemversionen
Filen der skrives er Ryuk. Derefter kører den den og sender sin egen adresse som en parameter.
Ris. 18: Udførelse af Ryuk via ShellExecute
Det første Ryuk gør er at modtage inputparametre. Denne gang er der to inputparametre (selve den eksekverbare fil og dropper-adressen), der bruges til at fjerne dens egne spor.
Ris. 19: Oprettelse af en proces
Du kan også se, at når den kører sine eksekverbare filer, sletter den sig selv og efterlader dermed ingen spor af dens tilstedeværelse i den mappe, hvor den blev udført.
Ris. 20: Sletning af en fil
5. RYUK
5.1 Tilstedeværelse
Ryuk, ligesom anden malware, forsøger at forblive i systemet så længe som muligt. Som vist ovenfor er én måde at opnå dette mål at hemmeligt oprette og køre eksekverbare filer. Den mest almindelige fremgangsmåde til dette er at ændre registreringsnøglen AktuelVersionKørsel.
I dette tilfælde kan du se, at den første fil, der skal udføres til dette formål, er VWjRF.exe
(filnavnet genereres tilfældigt) starter cmd.exe.
Ris. 21: Udførelse af VWjRF.exe-filen
Derefter indtastes kommandoen LØB med navnet "svchos". Så hvis du vil kontrollere registreringsnøglerne når som helst, kan du nemt overse denne ændring, da navnet ligner svchost. Takket være denne nøgle sikrer Ryuk sin tilstedeværelse i systemet. Hvis systemet ikke er blevet inficeret endnu, vil den eksekverbare fil forsøge igen, når du genstarter systemet.
Ris. 22: Eksempel sikrer tilstedeværelse i registreringsdatabasenøglen
Vi kan også se, at denne eksekverbare version stopper to tjenester:
"lydendepunktbygger", som navnet antyder, svarer til systemlyd,
Ris. 23: Eksempel stopper systemets lydtjeneste
и samss, som er en kontoadministrationstjeneste. At stoppe disse to tjenester er et karakteristisk træk ved Ryuk. I dette tilfælde, hvis systemet er forbundet til et SIEM-system, forsøger krypteringsprogrammet at stoppe med at sende til nogen advarsler. På denne måde beskytter den dens næste trin, da nogle SAM-tjenester ikke vil være i stand til at starte deres arbejde korrekt, efter Ryuk er udført.
Ris. 24: Prøve stopper Samss-tjenesten
5.2 Privilegier
Generelt starter Ryuk med at bevæge sig lateralt inden for et netværk, eller det bliver lanceret af en anden malware som f.eks. eller , som i tilfælde af eskalering af rettigheder overfører disse forhøjede rettigheder til ransomwaren.
På forhånd, som en optakt til implementeringsprocessen, ser vi ham udføre processen Efterlign dig selv, hvilket betyder, at sikkerhedsindholdet i adgangstokenet vil blive sendt til strømmen, hvor det straks vil blive hentet ved hjælp af HentAktuelTråd.
Ris. 25: Opkald til ImpersonateSelf
Så ser vi, at den vil knytte en adgangstoken til flowet. 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 bør den værdi, som edx vil modtage, være TOKEN_ALL_ACESS eller på anden måde - TOKEN_WRITE.
Ris. 26: Oprettelse af et flowtoken
Så vil han bruge SeDebugPrivilege og vil foretage et kald for at få fejlfindingstilladelser på tråden, så ved at angive PROCESS_AL_ADGANG, vil han kunne få adgang til enhver proces, han ønsker. Da krypteringsprogrammet allerede har en forberedt strøm, er alt, hvad der er tilbage, at gå videre til den sidste fase.
Ris. 27: Kald af SeDebugPrivilege og funktionen til eskalering af rettigheder
På den ene side har vi LookupPrivilegeValueW, som giver os de nødvendige oplysninger om de privilegier, vi ønsker at øge.
Ris. 28: Anmod om oplysninger om privilegier til eskalering
På den anden side har vi JusterToken-rettigheder, hvilket giver dig mulighed for at få de nødvendige rettigheder til vores stream. I dette tilfælde er det vigtigste Ny stat, hvis flag vil give privilegier.
Ris. 29: Opsætning af tokentilladelser
5.3 Implementering
I dette afsnit vil vi vise, hvordan eksemplet udfører implementeringsprocessen, der tidligere er nævnt i denne rapport.
Hovedformålet med implementeringsprocessen, såvel som eskalering, er at få adgang til skyggekopier. For at gøre dette skal han arbejde med en stream med højere rettigheder end den lokale brugers. Når den har 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 OpretVærktøjHjælp32Snapshot, så den tager et øjebliksbillede af de aktuelt kørende processer og forsøger at få adgang til disse processer ved hjælp af OpenProcess. Når den får adgang til processen, åbner den også et token med sine oplysninger for at hente procesparametrene.
Ris. 30: Hentning af processer fra en computer
Vi kan dynamisk se, hvordan den henter listen over kørende processer i 140002D9C-rutinen ved hjælp af CreateToolhelp32Snapshot. Når den modtager dem, gennemgår den listen og forsøger at åbne processer en efter en ved hjælp af OpenProcess, indtil det lykkes. I dette tilfælde var den første proces, han var i stand til at åbne "taskhost.exe".
Ris. 31: Dynamisk udførelse af en procedure for at opnå en proces
Vi kan se, at den efterfølgende læser procestoken-oplysningerne, så den kalder OpenProcessToken med parameteren "20008"
Ris. 32: Oplysninger om token til læsning af proces
Den kontrollerer også, at den proces, den skal injiceres i, ikke er 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 en kontrol ved hjælp af procestokeninformationen i 140002D9C for at finde ud af, om den konto, hvis rettigheder bruges til at udføre processen, er kontoen NT-AUTORITET.
Ris. 34: NT-AUTORITETSkontrol
Og senere, uden for proceduren, kontrollerer han, at det ikke er csrss.exe, explorer.exe eller lsaas.exe.
Ris. 35: NT-AUTORITETSkontrol
Når den har taget et snapshot af processerne, åbnet processerne og verificeret, at ingen af dem er udeladt, er den klar til at skrive de processer, der skal injiceres i hukommelsen.
For at gøre dette reserverer den først et område i hukommelsen (VirtualAllocEx), skriver ind i den (SkriveprocesHukommelse) og opretter en strøm (OpretFjernTråd). For at arbejde med disse funktioner bruger den PID'erne for de valgte processer, som den tidligere har indhentet ved hjælp af Create Toolhelp32Snapshot.
Ris. 36: Integrer kode
Her kan vi dynamisk observere, hvordan den bruger proces-PID'et til at kalde funktionen. VirtualAllocEx.
Ris. 37: Kald af VirtualAllocEx
5.4 Kryptering
I dette afsnit vil vi se på krypteringsdelen af dette eksempel. I den følgende figur kan du se to underrutiner kaldet "LoadLibrary_EncodeString"og"Encode_Func", som er ansvarlige for at udføre krypteringsproceduren.
Ris. 38: Krypteringsprocedurer
I starten kan vi se, hvordan den indlæser en streng, der senere vil blive brugt til at deobfuscate alt, hvad der er nødvendigt: import, DLL'er, kommandoer, filer og CSP'er.
Ris. 39: Deobfuskationskæde
Følgende figur viser den første import, som den deobfuskerer i R4-registeret, Indlæs bibliotek. Dette vil senere blive brugt til at indlæse de nødvendige DLL'er. Vi kan også se en anden linje i register R12, som bruges sammen med den foregående linje til at udføre deobfuskation.
Ris. 40: Dynamisk deobfuskation
Den fortsætter med at indlæse kommandoer, som den senere vil udføre for at deaktivere sikkerhedskopier, gendannelsespunkter og sikre opstartstilstande.
Ris. 41: Indlæsning af kommandoer
Så indlæser han en placering, hvor han 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 rettigheder ikke er tilgængelige, stopper Ryuk udførelsen.
Den fortsætter med at downloade linjer svarende til de tre filer. Først, DEKRYPT_INFORMATION.html, indeholder oplysninger, der er nødvendige for at gendanne filer. Anden, OFFENTLIG, indeholder den offentlige RSA-nøgle.
Ris. 43: DEKRYPTÉR INFORMATION.html linje
Tredje, UNIKT_ID_MÅ_IKKE_FJERNES, indeholder den krypterede nøgle, der vil blive brugt i den næste rutine til at udføre krypteringen.
Ris. 44: Linje UNIKT ID FJERN IKKE
Endelig indlæses de nødvendige biblioteker sammen med de nødvendige importer og CSP (Microsoft Enhanced RSA и AES-kryptografisk udbyder).
Ris. 45: Indlæsning af biblioteker
Når al deobfuskering er fuldført, fortsætter den med at udføre de handlinger, der kræves til kryptering: opregn alle logiske drev, udfør det, der blev indlæst i den forrige subrutine, styrk tilstedeværelsen i systemet, slet RyukReadMe.html-filen, krypter, opregn alle netværksdrev, gå til de detekterede enheder og krypter dem.
Det hele starter med at indlæse"cmd.exe" og optegnelser over den offentlige RSA-nøgle.
Ris. 46: Forberedelse til kryptering
Så henter den alle de logiske drev ved hjælp af GetLogicalDrives og deaktiverer alle sikkerhedskopier, gendannelsespunkter og sikre opstartstilstande.
Ris. 47: Deaktivering af gendannelsesvæ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: Opslåning af en løsesumsmeddelelse
På følgende billede kan du se, hvordan den opretter en fil, indlæser indholdet og skriver den:
Ris. 49: Indlæsning og skrivning af filindhold
For at kunne udføre de samme handlinger på alle enheder, bruger den
"icacls.exe", som vi viste ovenfor.
Ris. 50: Brug af icalcls.exe
Og endelig begynder den at kryptere filer undtagen "*.exe", "*.dll", systemfiler og andre placeringer angivet som en krypteret hvidliste. For at gøre dette bruger den import: CryptAcquireContextW (hvor brugen af AES og RSA er indiceret), CryptDeriveKey, CryptGenKey, KryptØdelægNøgle osv. 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, der anvendes af eksemplet:
7. IOC
RЎSЃS <P "RєRё
- brugerePublicrun.sct
- StartmenuProgrammerOpstartstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgrammerOpstartstart.bat
Den tekniske rapport om Ryuk ransomware blev udarbejdet af eksperter fra PandaLabs antiviruslaboratorium.
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-artikel: Shinigamis hævn: Ryuk-malwarens lange hale.” https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Publicada el 11/12/2019
4. “Storvildtjagt med Ryuk: Endnu en lukrativ målrettet ransomware.” https://www. crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, offentliggjort den 10/01/2019.
5. “VB2019-artikel: 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
