Ryuk er en af de mest kendte varianter af ransomware i de seneste år. Siden det første gang dukkede op i sommeren 2018, har det samlet , især i erhvervslivet, som er det primære mål for dets angreb.
1. Generel information
Dette dokument indeholder en analyse af ransomware-varianten Ryuk samt en loader, der ansvarer for at indlæse malware i systemet.
Ransomware Ryuk dukkede først op i sommeren 2018. En af forskellene mellem Ryuk og andre ransomware er, at den målretter mod angreb i virksomhedsmiljøer.
I midten af 2019 angreb cyberkriminelle grupper et stort antal spanske virksomheder med denne ransomware.
Fig. 1: Uddrag fra El Confidencial om angrebet fra ransomware Ryuk [1]
Fig. 2: Uddrag fra El País om angrebet udført med ransomware Ryuk [2]
I år har Ryuk angrebet et stort antal virksomheder i forskellige lande. Som du kan se på de følgende billeder, er Tyskland, Kina, Algeriet og Indien de mest berørte.
Ved at sammenligne antallet af cyberangreb kan vi se, at millioner af brugere er blevet ramt af Ryuk, og et enormt datavolumen er blevet kompromitteret, hvilket har ført til alvorlige økonomiske tab.
Fig. 3: Illustration af Ryuks globale aktivitet.
Fig. 4: 16 lande, der er mest berørt af Ryuk
Fig. 5: Antallet af brugere, der er ramt af ransomware Ryuk (i millioner)
I henhold til den sædvanlige driftsprincip for sådanne trusler viser denne ransomware efter afslutningen af krypteringen et krav til ofret om, at der skal betales en løsesum i bitcoin til den angivne adresse for at genoprette adgangen til de krypterede filer.
Denne malware har ændret sig siden sit første udseende.
Den variant af truslen, der analyseres i dette dokument, blev opdaget under et angrebsforsøg i januar 2020.
På grund af sin kompleksitet tilskrives denne malware ofte organiserede cyberkriminelle grupper, også kendt som APT-grupper.
En del af koden fra Ryuk viser bemærkelsesværdige ligheder med koden og strukturen fra en anden velkendt ransomware, Hermes, som de har en række fælles funktioner. Dette er grunden til, at Ryuk oprindeligt blev forbundet med den nordkoreanske gruppe Lazarus, som på det tidspunkt blev mistænkt for at stå bag ransomware Hermes.
Senere bemærkede Falcon X-tjenesten fra CrowdStrike, at Ryuk faktisk var skabt af gruppen WIZARD SPIDER [4].
Der er flere beviser til støtte for denne antagelse. For det første blev denne ransomware reklameret på webstedet exploit.in, som er et kendt russisk marked for malware og tidligere har været forbundet med nogle russiske APT-grupper.
Dette faktum udelukker teorien om, at Ryuk kunne være udviklet af APT-gruppen Lazarus, da det ikke stemmer overens med den måde, gruppen opererer på.
Desuden blev Ryuk reklameret som en ransomware, der ikke ville fungere på russiske, ukrainske og hviderussiske systemer. Denne adfærd bestemmes af funktioner, der blev opdaget i nogle versioner af Ryuk, hvor den tjekker sproget på det system, hvori ransomware kører, og stopper sit arbejde, hvis systemet har russisk, ukrainsk eller hviderussisk sprog. Endelig, ved ekspertanalyse af den maskine, der blev hacket af WIZARD SPIDER, blev der fundet flere 'artefakter', som angiveligt blev brugt til at udvikle Ryuk som en variant af ransomware Hermes.
På den anden side har eksperterne Gabriela Nicoloa og Luciano Martins antydet, at ransomware muligvis blev udviklet af APT-gruppen CryptoTech [5].
Dette følger af det faktum, at flere måneder før Ryuks ankomst, havde denne gruppe lagt oplysninger på forumet på samme websted om, at de havde udviklet en ny version af ransomware Hermes.
Flere forumbrugere stillede spørgsmål ved, om CryptoTech virkelig havde skabt Ryuk. Efter dette forsvarte gruppen sig og erklærede, at de havde beviser for, at de havde udviklet 100% af denne ransomware.
2. Egenskaber
Vi starter med bootloaderen, hvis opgave er at identificere systemet, den befinder sig i, så den 'korrekte' version af Ryuk-ransomwaren kan startes.
Hash-værdien for bootloaderen er som følger:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
En af funktionerne ved denne loader er, at den ikke indeholder nogen metadata, dvs. skaberne af dette malware har ikke inkluderet nogen oplysninger i den.
Nogle gange inkluderer de fejlagtige data for at få brugeren til at tro, at de tilsyneladende kører en legitim applikation. Men som vi senere vil se, hvis infektionen ikke kræver brugerinteraktion (som i tilfælde med denne ransomware), mener angriberne ikke, at det er nødvendigt at bruge metadata.
Fig. 6: Metadata for prøven
Prøven blev kompilert i 32-bit format, så den kunne køres både i 32-bit og 64-bit systemer.
3. Indtrængingsvektor
Prøven, der downloader og kører Ryuk, kom ind i vores system via en fjernforbindelse, og adgangsparametrene blev opnået gennem et forudgående RDP-angreb.
Fig. 7: Angrebets registrering
Angriberen lykkedes med at få adgang til systemet eksternt. Derefter oprettede han en eksekverbar fil med vores prøve.
Denne eksekverbare fil blev blokeret af antivirusløsningen før kørsel.
Fig. 8: Blokering af prøven
Fig. 9: Blokering af prøven
Da den ondsindede fil blev blokeret, forsøgte angriberen at downloade en krypteret version af eksekverbar fil, som også blev blokeret.
Fig. 10: Sæt af prøver, som angriberen forsøgte at køre
Endelig forsøgte han at downloade en anden ondsindet fil gennem en krypteret konsol
PowerShell for at omgå antivirusbeskyttelsen. Men den blev også blokeret.
Fig. 11: PowerShell med blokeret ondsindet indhold
Fig. 12: PowerShell med blokeret ondsindet indhold
4. Loader
Når den udføres, skriver den en ReadMe fil i mappen %temp%, hvilket er typisk for Ryuk. Denne fil er en løsesum, der indeholder en e-mailadresse i protonmail-domenet, som er ret almindeligt i denne familie af malware: msifelabem1981@protonmail.com
Fig. 13: Løsesum
Under udførelsen af loaderen kan du se, at den starter flere eksekverbare filer med tilfældige navne. De opbevares i en skjult mappe PUBLIC, men hvis indstillingen "Vis skjulte filer og mapper" ikke er aktiv i operativsystemet. «Vis skjulte filer og mapper», så de vil forblive skjulte. Desuden er disse filer 64-bit i modsætning til den overordnede fil, som er 32-bit.
Fig. 14: Kørbare filer, der køres af prøven
Som du kan se i illustrationen ovenfor, kører Ryuk icacls.exe, som vil blive brugt til at ændre alle adgangskontrolister (ACL), og dermed garantere adgang og ændring af flagene.
Han får fuld adgang under alle brugere til alle filer på enheden (/T) uanset fejl (/C) og uden at vise nogen meddelelser (/Q).
Fig. 15: Kørsel af icacls.exe med parametre, der startes af prøven
Det er vigtigt at overveje, at Ryuk tjekker, hvilken version af Windows der er i brug. For dette
udfører han versionskontrol med GetVersionExW, hvor han kontrollerer værdien af flaget lpVersionInformation, som viser, om den aktuelle version af Windows er nyere end Windows XP.
Afhængig af om du kører en nyere version end Windows XP, vil loaderen skrive til brugerens lokale mappe — i dette tilfælde til mappen %Public%.
Fig. 17: Versionskontrol af operativsystemet
Den fil, der skrives, er Ryuk. Derefter kører han den og sender sin egen adresse som parameter.
Fig. 18: Udførelse af Ryuk via ShellExecute
Det første, Ryuk gør, er at hente indgangsparametrene. Denne gang er der to indgangsparametre (den kørbare fil og dropperens adresse), som bruges til at slette sine egne spor.
Fig. 19: Oprettelse af proces
Du kan også se, at så snart han har startet sine kørbare filer, sletter han sig selv, og dermed efterlader han ingen spor af sin tilstedeværelse i den mappe, hvor han blev udført.
Fig. 20: Sletning af filen
5. RYUK
5.1 Tilstedeværelse
Ryuk, ligesom andre malware, forsøger at forblive i systemet så længe som muligt. Som vist ovenfor er en af måderne at nå dette mål at skabe og køre kørbare filer skjult. Den mest almindelige praksis for dette er at ændre registreringsnøglen CurrentVersionRun.
I dette tilfælde kan du se, at den første kørbare fil til dette formål VWjRF.exe
(filnavnet genereres tilfældigt) kører cmd.exe.
Fig. 21: Udførelse af filen VWjRF.exe
Derefter indtastes kommandoen RUN med navnet "svchos". Derfor, hvis du på noget tidspunkt ønsker at kontrollere registreringsnøglerne, kan du let overse denne ændring på grund af ligheden mellem dette navn og svchost. Takket være denne nøgle sikrer Ryuk sin tilstedeværelse i systemet. Hvis systemet endnu ikke er blevet inficeret, vil den kørbare fil forsøge igen, når du genstarter systemet.
Fig. 22: Eksemplet sikrer tilstedeværelse i registreringsnøglen
Vi kan også se, at denne kørbare fil stopper to tjenester:
"audioendpointbuilder", som ifølge dens navn svarer til systemlyd,
Fig. 23: Eksemplet stopper systemlydtjenesten
og samss, som er en tjeneste til kontoadministration. At stoppe disse to tjenester er et kendetegn ved Ryuk. I dette tilfælde, hvis systemet er forbundet til et SIEM-system, forsøger ransomware at stoppe meddelelser til der måtte komme. På denne måde beskytter det sine næste skridt, da nogle SAM-tjenester ikke vil kunne starte korrekt efter Ryuk er udført.
Fig. 24: Eksemplet stopper Samss-tjenesten
5.2 Rettigheder
Generelt set starter Ryuk med horisontal bevægelse inden for netværket, eller det startes af et andet skadelig program, såsom eller , som i tilfælde af privilegieskalering overfører disse forhøjede rettigheder til ransomware.
Forud, som en prolog til implementeringsprocessen, ser vi, at den udfører processen ImpersonateSelf, hvilket betyder, at sikkerhedsindholdet i adgangstokenet vil blive overført til tråden, hvor det straks vil blive modtaget via GetCurrentThread.
Fig. 25: Kaldet ImpersonateSelf
Derefter ser vi, at den vil binde adgangstokenet til tråden. Vi ser også, at en af flagene er DesiredAccess, som kan bruges til at kontrollere den adgang, som tråden vil have. I dette tilfælde skal værdien, som edx får, være TOKEN_ALL_ACCESS ellers TOKEN_WRITE.
Fig. 26: Oprettelse af trådtoken
Derefter vil den bruge SeDebugPrivilege og lave et kald for at få debug-rettigheder i forhold til tråden, hvilket resulterer i, at den angiver PROCESS_ALL_ACCESS, så den kan få adgang til enhver nødvendig proces. Nu, da ransomware allerede har forberedt tråden, er det kun at påbegynde den afsluttende fase.
Fig. 27: Call of SeDebugPrivilege and privilege escalation function
On one hand, we have LookupPrivilegeValueW, providing us the necessary information about the privileges we want to elevate.
Fig. 28: Requesting information about privileges for escalation
On the other hand, we have AdjustTokenPrivileges, which allows obtaining the necessary rights for our thread. In this case, the most important is NewState, whose flag will grant privileges.
Fig. 29: Setting rights for the token
5.3 Injection
In this section, we will show how the sample performs the injection process previously mentioned in this report.
The main goal of the injection process, like escalation, is to gain access to shadow copies. For this, it needs to work with a thread that has higher rights than the local user. Once it acquires 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 injection, it uses CreateToolHelp32Snapshot, thus taking a snapshot of currently running processes and attempting to access these processes using OpenProcess. Once it gains access to a process, it also opens the token with its information to obtain the process parameters.
Fig. 30: Retrieving processes from the machine
We can dynamically see how it retrieves a list of running processes in subprogram 140002D9C using CreateToolhelp32Snapshot. After obtaining them, it goes through the list, attempting to open processes one by one using OpenProcess until it succeeds. In this case, the first process it was able to open is "taskhost.exe".
Fig. 31: Dynamic execution of the procedure to obtain the process
We can see that subsequently, it reads the token information of the process, thus calling OpenProcessToken with the parameter "20008"
Fig. 32: Reading process token information
It also checks that the process it will be injecting 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 performs a check using the process token information in 140002D9C for at bekræfte, om den konto, hvis rettigheder bruges til at udføre processen, er en konto NT AUTHORITY.
Fig. 34: Kontrol af NT AUTHORITY
Og senere, uden for proceduren, kontrollerer han, at dette ikke er csrss.exe, explorer.exe eller lsaas.exe.
Fig. 35: Kontrol af NT AUTHORITY
Når han har taget et snapshot af processerne, åbnet processerne og sørget for, at ingen af dem er undtaget, er han klar til at skrive de processer, der skal injiceres, ind i hukommelsen.
Til dette reserverer han først et område i hukommelsen (VirtualAllocEx), skriver til det (WriteProcessmemory) og opretter en tråd (CreateRemoteThread). For at arbejde med disse funktioner bruger han PID'erne for de valgte processer, som han tidligere har fået ved hjælp af CreateToolhelp32Snapshot.
Fig. 36: Kode til injektion
Her kan vi dynamisk observere, hvordan han bruger PID'en for processen til at kalde funktionen VirtualAllocEx.
Fig. 37: Kald af VirtualAllocEx
5.4 Kryptering
I dette afsnit vil vi se på den del af dette eksempel, der vedrører kryptering. På den næste illustration kan du se to underprogrammer kaldet "LoadLibrary_EncodeString" og "Encode_Func", som er ansvarlige for at udføre krypteringsproceduren.
Fig. 38: Krypteringsprocedurer
I starten kan vi se, hvordan han indlæser en streng, der senere vil blive brugt til at de-obfuske alt, hvad der er nødvendigt: importer, DLL, kommandoer, filer og CSP.
Fig. 39: De-obfuskering kæde
På den næste illustration vises den første import, som han de-obfuskere i register R4, LoadLibrary. Dette vil blive brugt senere til at indlæse de nødvendige DLL'er. Vi kan også se en anden streng i register R12, som bruges sammen med den tidligere streng til at udføre de-obfuskeringen.
Fig. 40: Dynamisk de-obfuskering
Han fortsætter med at indlæse kommandoer, som han senere vil udføre for at deaktivere sikkerhedskopier, gendannelsespunkter og sikre opstartsmode.
Fig. 41: Indlæsning af kommandoer
Derefter indlæser han placeringen, hvor han vil droppe 3 filer: Windows.bat, run.sct og start.bat.
Fig. 42: Filplaceringer
Disse 3 filer bruges til at kontrollere de privilegier, som hver placering har. Hvis de krævede privilegier ikke er tilgængelige, stopper Ryuk udførelsen.
Han fortsætter med at indlæse strenge, der svarer til de tre filer. Den første, DECRYPT_INFORMATION.html, indeholder oplysninger, der er nødvendige for at gendanne filer. Den anden, PUBLIC, indeholder den offentlige RSA-nøgle.
Fig. 43: Streng DECRYPT INFORMATION.html
Den tredje, UNIQUE_ID_DO_NOT_REMOVE, indeholder en krypteringsnøgle, der vil blive brugt i det følgende underprogram til at udføre kryptering.
Fig. 44: Linje UNIQUE ID DO NOT REMOVE
Endelig indlæser den de nødvendige biblioteker sammen med de krævede imports og CSP (Microsoft Enhanced RSA og AES Cryptographic Provider).
Fig. 45: Indlæsning af biblioteker
Når hele deobfuskeringen er afsluttet, fortsætter den med at udføre de handlinger, der kræves for kryptering: at gennemgå alle logiske drev, udføre det, der blev indlæst i det foregående underprogram, styrke sin tilstedeværelse i systemet, placere filen RyukReadMe.html, kryptere, gennemgå alle netværksdrev, få adgang til de opdagede enheder og kryptere dem.
Det hele begynder med indlæsningen af "cmd.exe" og skrivning af den åbne RSA-nøgle.
Fig. 46: Forberedelse til kryptering
Derefter får den alle logiske drev ved hjælp af GetLogicalDrives og deaktiverer alle sikkerhedskopier, gendannelsespunkter og sikre opstartstilstande.
Fig. 47: Deaktivering af genoprettelsesværktøjer
Derefter styrker den sin tilstedeværelse i systemet, som vi har set ovenfor, og skriver den første fil RyukReadMe.html i TEMP.
Fig. 48: Offentliggørelse af løsesummeddelelse
I den næste figur kan du se, hvordan den opretter en fil, indlæser indholdet og skriver det:
Fig. 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.
Fig. 50: Brug af icalcls.exe
Og til sidst begynder den krypteringen af filer, undtagen filer "*.exe", "*.dll", systemfiler og andre placeringer angivet i en krypteret hvidliste. Til dette bruger den imports: CryptAcquireContextW (hvor brug af AES og RSA er angivet), CryptDeriveKey, CryptGenKey, CryptDestroyKey osv. Der gøres også et forsøg på at udvide sin rækkevidde til de opdagede netværksenheder ved hjælp af WNetEnumResourceW og derefter kryptere dem.
Fig. 51: Kryptering af systemfiler
6. Imports og tilsvarende flag
Nedenfor er en tabel med en liste over de mest relevante imports og flag, der anvendes af prøven:
7. IOC
Links
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgramsStartupstart.bat
Den tekniske rapport om ransomware Ryuk er udarbejdet af eksperter fra antiviruslaboratoriet PandaLabs.
8. Referencer
1. “Everis og Prisa Radio lider et alvorligt cyberangreb, der kidnupper deres systemer.”https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Publiceret den 04/11/2019.
2. “En virus af russisk oprindelse angriber vigtige spanske virksomheder.”https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Publiceret den 04/11/2019.
3. “VB2019 papir: Shinigamis hævn: den lange hale af Ryuk-malwaren.”https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Publiceret den 11/12/2019.
4. “Big Game Hunting med Ryuk: Endnu et lukrativt målrettet ransomware.”https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Publiceret den 10/01/2019.
5. “VB2019 papir: Shinigamis hævn: den lange hale af Ryuk-malwaren.”https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Kilde: habr.com
