Ryuk is een van de bekendste ransomware-varianten van de afgelopen jaren. Sinds het voor het eerst verscheen in de zomer van 2018, heeft het een , vooral in het bedrijfsleven, dat het belangrijkste doelwit van zijn aanvallen is.
1. Algemene informatie
Dit document bevat een analyse van de ransomware Ryuk en van de loader die verantwoordelijk is voor het inladen van de malware in het systeem.
Ransomware Ryuk verscheen voor het eerst in de zomer van 2018. Een van de verschillen tussen Ryuk en andere ransomware is dat het gericht is op aanvallen binnen zakelijke omgevingen.
In het midden van 2019 hebben cybercriminale groeperingen een groot aantal Spaanse bedrijven aangevallen met deze ransomware.
Figuur 1: Uittreksel uit El Confidencial over de aanval van ransomware Ryuk [1]
Figuur 2: Uittreksel uit El País over de aanval die is uitgevoerd met behulp van ransomware Ryuk [2]
Dit jaar heeft Ryuk een groot aantal bedrijven in verschillende landen aangevallen. Zoals u kunt zien op de onderstaande figuren, waren Duitsland, China, Algerije en India het meest getroffen.
Vergeleken met het aantal cyberaanvallen kunnen we zien dat miljoenen gebruikers door Ryuk zijn getroffen en dat een enorme hoeveelheid gegevens is gecompromitteerd, wat heeft geleid tot ernstige economische schade.
Figuur 3: Illustratie van de wereldwijde activiteit van Ryuk.
Figuur 4: 16 landen die het meest zijn getroffen door Ryuk
Figuur 5: Aantal gebruikers dat door ransomware Ryuk is aangevallen (in miljoenen)
Volgens het gebruikelijke werkingsprincipe van dergelijke bedreigingen toont deze ransomware na voltooiing van de versleuteling een bericht aan het slachtoffer met een losgeld dat in bitcoin moet worden betaald naar het opgegeven adres om toegang tot de versleutelde bestanden te herstellen.
Deze malware heeft zich veranderd sinds zijn eerste verschijning.
De variant van deze bedreiging die in dit document wordt geanalyseerd, werd ontdekt tijdens een poging tot aanval in januari 2020.
Vanwege de complexiteit wordt deze malware vaak toegeschreven aan georganiseerde cybercrimegroeperingen, ook wel bekend als APT-groepen.
Een deel van de code van Ryuk vertoont opvallende overeenkomsten met de code en structuur van een andere bekende ransomware, Hermes, waarmee ze een aantal gelijke functies delen. Om deze reden werd Ryuk aanvankelijk in verband gebracht met de Noord-Koreaanse groep Lazarus, die destijds verdacht werd van betrokkenheid bij de ransomware Hermes.
Later merkte de Falcon X-dienst van CrowdStrike op dat Ryuk feitelijk was ontwikkeld door de groep WIZARD SPIDER [4].
Er zijn verschillende bewijzen die deze veronderstelling ondersteunen. Ten eerste werd deze ransomware gepromoot op de website exploit.in, een bekende Russische markt voor malware, die eerder was verbonden met enkele Russische APT-groepen.
Dit feit sluit de theorie uit dat Ryuk ontwikkeld zou zijn door de APT-groep Lazarus, aangezien dit niet overeenkomt met de manier van werken van die groep.
Bovendien werd Ryuk gepromoot als ransomware die niet zou werken op systemen in Rusland, Oekraïne en Wit-Rusland. Dit gedrag wordt bepaald door functie die in sommige versies van Ryuk is ontdekt, waarbij deze controleert welke taal het systeem heeft waarop deze ransomware is gestart, en stopt met werken als het systeem Russisch, Oekraïens of Wit-Russisch is. Ten slotte, tijdens een expertanalyse van de machine die door de WIZARD SPIDER-groep werd gehackt, werden verschillende 'artefacten' gevonden die vermoedelijk zijn gebruikt bij de ontwikkeling van Ryuk als een variant van de ransomware Hermes.
Aan de andere kant suggereerden experts Gabriela Nicolaou en Luciano Martins dat de ransomware mogelijk was ontwikkeld door de APT-groep CryptoTech [5].
Dit volgt uit het feit dat enkele maanden vóór de opkomst van Ryuk deze groep informatie op hetzelfde forum plaatste over de ontwikkeling van een nieuwe versie van de ransomware Hermes.
Verschillende forumgebruikers vroegen zich af of CryptoTech daadwerkelijk Ryuk had gemaakt. Hierna verdedigde deze groep zich en verklaarde dat ze bewijs hadden dat ze 100% van deze ransomware hadden ontwikkeld.
2. Kenmerken
We beginnen met de loader, wiens taak het is om het systeem te identificeren waarin deze zich bevindt, zodat de 'juiste' versie van de Ryuk-ransomware kan worden uitgevoerd.
De hash van de loader is als volgt:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
Een van de kenmerken van deze loader is dat deze geen metadata bevat, dat wil zeggen dat de makers van deze malware geen informatie erin hebben opgenomen.
Soms voegen ze foutieve gegevens toe om de gebruiker te laten denken dat hij zogenaamd een legitieme applicatie uitvoert. Echter, zoals we later zullen zien, in gevallen waar infectie geen interactie met de gebruiker vereist (zoals bij deze ransomware), vinden de aanvallers het niet nodig om metadata te gebruiken.
Afbeelding 6: Metadata van het monster
Het monster is gecompileerd in 32-bits formaat, zodat het zowel op 32-bits als op 64-bits systemen kan worden uitgevoerd.
3. Inbraakvector
Het monster dat Ryuk downloadt en uitvoert, heeft onze systemen bereikt via een externe verbinding, en de toegangsparameters zijn verkregen door een eerdere RDP-aanval.
Afbeelding 7: Aanval registratie
De aanvaller is er in geslaagd om op afstand toegang te krijgen tot het systeem. Daarna heeft hij een uitvoerbaar bestand gemaakt met ons monster.
Dit uitvoerbare bestand werd geblokkeerd door de antivirusoplossing voordat het kon worden uitgevoerd.
Afbeelding 8: Blokkering van het monster
Afbeelding 9: Blokkering van het monster
Toen het kwaadaardige bestand was geblokkeerd, probeerde de aanvaller een versleutelde versie van het uitvoerbare bestand te downloaden, wat ook werd geblokkeerd.
Afbeelding 10: Set monsters die de aanvaller probeerde uit te voeren
Uiteindelijk probeerde hij een ander kwaadaardig bestand te downloaden via een versleutelde console
PowerShell om de antivirusbescherming te omzeilen. Maar dit werd ook geblokkeerd.
Afbeelding 11: PowerShell met geblokkeerde kwaadaardige inhoud
Afbeelding 12: PowerShell met geblokkeerde kwaadaardige inhoud
4. Loader
Wanneer het wordt uitgevoerd, schrijft het een ReadMe-bestand naar de map %temp%, wat typisch is voor Ryuk. Dit bestand is een losgeld-eis, met een e-mailadres in het protonmail-domein, dat vaak voorkomt in deze familie van malware: msifelabem1981@protonmail.com
Afbeelding 13: Losgeld-eis
Tijdens de uitvoering van de loader kunt u zien dat het verschillende uitvoerbare bestanden met willekeurige namen start. Ze worden opgeslagen in een verborgen map PUBLIC, maar als de optie "Verborgen bestanden en mappen tonen" niet actief is in het besturingssysteem. «Verborgen bestanden en mappen weergeven», dan ze zullen verborgen blijven. Bovendien zijn deze bestanden 64-bit, in tegenstelling tot het bovenliggende bestand, dat 32-bit is.
Figuur 14: Uitvoerbare bestanden die door het monster worden uitgevoerd
Zoals te zien is in de bovenstaande afbeelding, start Ryuk icacls.exe, dat zal worden gebruikt om alle toegangslijsten (ACL - Access Control List) te wijzigen, waardoor toegang wordt gegarandeerd en vlaggen kunnen worden gewijzigd.
Hij krijgt volledige toegang onder alle gebruikers tot alle bestanden op het apparaat (/T), ongeacht fouten (/C) en zonder enige berichten weer te geven (/Q).
Figuur 15: Uitvoeringsparameters van icacls.exe, gestart door het monster
Het is belangrijk om te overwegen dat Ryuk controleert welke versie van Windows wordt uitgevoerd. Hiervoor
voert hij een versiecontrole uit met behulp van GetVersionExW, waarin hij de waarde van de vlag controleert lpVersionInformation, die aangeeft of de huidige versie van Windows recenter is dan Windows XP.
Afhankelijk van of je een recenter versie hebt dan Windows XP, zal de loader naar de lokale gebruikersmap schrijven — in dit geval naar de map %Public%.
Figuur 17: Controle van de versie van het besturingssysteem
Het bestand dat wordt geschreven is Ryuk. Vervolgens start hij het en geeft zijn eigen adres door als parameter.
Figuur 18: Uitvoering van Ryuk via ShellExecute
Het eerste dat Ryuk doet, is het verkrijgen van de invoerparameters. Deze keer zijn er twee invoerparameters (het uitvoerbare bestand zelf en het adres van de dropper), die worden gebruikt om zijn eigen sporen te wissen.
Figuur 19: Proces aanmaken
Je kunt ook zien dat zodra hij zijn uitvoerbare bestanden heeft gestart, hij zichzelf verwijdert, waardoor er geen sporen van zijn aanwezigheid achterblijven in de map waar hij werd uitgevoerd.
Figuur 20: Bestand verwijderen
5. RYUK
5.1 Aanzicht
Ryuk, net als andere schadelijke programma's, probeert zo lang mogelijk in het systeem te blijven. Zoals hierboven is aangetoond, is een van de manieren om dit doel te bereiken het verborgen maken en uitvoeren van uitvoerbare bestanden. De meest gebruikelijke praktijk hiervoor is het wijzigen van de registersleutel CurrentVersionRun.
In dit geval zie je dat voor dit doel het eerste uitvoerbare bestand VWjRF.exe
(de bestandsnaam wordt willekeurig gegenereerd) start cmd.exe.
Figuur 21: Uitvoering van het bestand VWjRF.exe
Vervolgens wordt het commando ingevoerd RUN met de naam "svchos". Dus als u op elk moment de registersleutels wilt controleren, kunt u deze wijziging gemakkelijk over het hoofd zien, gezien de gelijkenis van deze naam met svchost. Dankzij deze sleutel zorgt Ryuk ervoor dat het in het systeem aanwezig is. Als het systeem nog niet is geïnfecteerd, zal het uitvoerbare bestand bij het opnieuw opstarten opnieuw proberen.
Figuur 22: Voorbeeld zorgt voor aanwezigheid in de registersleutel
We kunnen ook zien dat dit uitvoerbare bestand twee services stopt:
"audioendpointbuilder", wat, zoals de naam al aangeeft, overeenkomt met het systeemaudio,
Figuur 23: Voorbeeld stopt de systeemaudioservice
en samss, wat een accountsbeheer service is. Het stoppen van deze twee services is een kenmerk van Ryuk. In dit geval, als het systeem is gekoppeld aan een SIEM-systeem, probeert de ransomware de verzending van waarschuwingen te stoppen. Op deze manier beschermt het zijn volgende stappen, aangezien sommige SAM-services niet correct kunnen starten na de uitvoering van Ryuk.
Figuur 24: Voorbeeld stopt de samss service
5.2 Bevoegdheden
Over het algemeen begint Ryuk met horizontale beweging binnen het netwerk of wordt het gestart door een andere malware zoals of , die bij privilege-escalatie deze verhoogde rechten aan de ransomware doorgeven.
Bij voorbaat, als een inleiding tot het implementatieproces, zien we dat het het proces ImpersonateSelf, wat betekent dat de beveiligingsinhoud van het toegangstoken naar de thread wordt overgedragen, waar het onmiddellijk zal worden verkregen met behulp van GetCurrentThread.
Figuur 25: Aanroep ImpersonateSelf
Vervolgens zien we dat het het toegangstoken aan de thread koppelt. We zien ook dat een van de vlaggen is DesiredAccess, dat kan worden gebruikt om de toegang die de thread zal hebben te controleren. In dit geval moet de waarde die edx ontvangt zijn TOKEN_ALL_ACCESS of anderszins — TOKEN_WRITE.
Figuur 26: Aanmaken van het thread-token
Vervolgens zal het gebruikmaken van SeDebugPrivilege en een aanroep doen om debug-rechten te verkrijgen met betrekking tot de thread, waardoor, door op te geven PROCESS_ALL_ACCESS, het toegang krijgt tot elk vereist proces. Aangezien de ransomware al een voorbereide thread heeft, blijft alleen de laatste fase te starten.
Figuur 27: Aanroep van SeDebugPrivilege en de functie voor rechtse escalatie
Enerzijds hebben we LookupPrivilegeValueW, dat ons de benodigde informatie verschaft over de privileges die we willen verhogen.
Figuur 28: Aanvraag van informatie over privileges voor escalatie
Aan de andere kant hebben we AdjustTokenPrivileges, waarmee we de benodigde rechten voor onze thread kunnen verkrijgen. In dit geval is het belangrijkste NewState, waarvan de vlag privileges zal aanbieden.
Figuur 29: Instellen van rechten voor het token
5.3 Invoering
In dit gedeelte laten we zien hoe het voorbeeld het invoerdproces uitvoert, zoals eerder in dit rapport genoemd.
Het hoofddoel van het invoerdproces, net als bij escalatie, is toegang te verkrijgen tot schaduwkopieën. Hiervoor moet het werken met een thread met hogere rechten dan die van de lokale gebruiker. Zodra het dergelijke hogere rechten verkrijgt, verwijdert het de kopieën en brengt het wijzigingen aan in andere processen om terugkeer naar een eerder herstelpunt in het besturingssysteem onmogelijk te maken.
Zoals gebruikelijk bij dit soort malware, gebruikt het CreateToolHelp32Snapshot, zodat het een snapshot maakt van de momenteel uitgevoerde processen en probeert toegang te krijgen tot deze processen met behulp van OpenProcess. Zodra het toegang heeft tot het proces, opent het ook de token met zijn informatie om de procesparameters te verkrijgen.
Figuur 30: Verkrijgen van processen van de computer
We kunnen dynamisch zien hoe het de lijst van actieve processen verkrijgt in de subroutine 140002D9C met behulp van CreateToolhelp32Snapshot. Nadat ze zijn verkregen, doorloopt het de lijst en probeert één voor één processen te openen met OpenProcess totdat het daarmee slaagt. In dit geval was het eerste proces dat het kon openen, ‘taskhost.exe’.
Figuur 31: Dynamische uitvoering van de procedure voor het verkrijgen van het proces
We kunnen zien dat het daarna informatie van de proces-token leest, dus roept het OpenProcessToken aan met de parameter "20008"
Figuur 32: Lezen van informatie van de proces-token
Het controleert ook of het proces waarin het zich zal invoegen, niet is csrss.exe, explorer.exe, lsaas.exe of of het een set rechten heeft van NT-authoriteit.
Figuur 33: Uitsluitingen van processen
We kunnen dynamisch zien hoe het eerst een controle uitvoert met behulp van de informatie van de proces-token in 140002D9C om te controleren of het account wiens rechten worden gebruikt om het proces uit te voeren een account is NT AUTHORITY.
Figuur 34: Controle van NT AUTHORITY
En later, buiten de procedure, controleert hij of het niet is csrss.exe, explorer.exe of lsaas.exe.
Figuur 35: Controle van NT AUTHORITY
Nadat hij een snapshot van de processen heeft gemaakt, opende hij de processen en verifieerde hij dat geen van hen uitgesloten was, is hij klaar om de processen die zullen worden geïnjecteerd in het geheugen te registreren.
Om dit te doen, reserveert hij eerst een gebied in het geheugen (VirtualAllocEx), schrijft hierin (WriteProcessmemory) en creëert een thread (CreateRemoteThread). Voor het werken met deze functies gebruikt hij de PID's van de geselecteerde processen, die hij eerder verkreeg via CreateToolhelp32Snapshot.
Figuur 36: Code voor injectie
Hier kunnen we dynamisch zien hoe hij de PID van het proces gebruikt om de functie aan te roepen VirtualAllocEx.
Figuur 37: Aanroep van VirtualAllocEx
5.4 Versleuteling
In dit gedeelte bespreken we een deel van dit voorbeeld dat betrekking heeft op versleuteling. In de volgende afbeelding ziet u twee subroutines genaamd "LoadLibrary_EncodeString" en "Encode_Func", die verantwoordelijk zijn voor het uitvoeren van de versleutelprocedure.
Figuur 38: Versleutelprocedures
In het begin kunnen we zien hoe hij een string laadt die later zal worden gebruikt voor het de-obfusceren van alles wat nodig is: imports, DLL's, commando's, bestanden en CSP.
Figuur 39: Ketting van de-obfuscatie
In de volgende afbeelding zien we de eerste import die hij de-obfusceert in register R4, LoadLibrary. Dit zal later worden gebruikt om de benodigde DLL's te laden. We kunnen ook een andere string in register R12 zien, die samen met de vorige string wordt gebruikt voor het uitvoeren van de-obfuscering.
Figuur 40: Dynamische de-obfuscering
Hij gaat door met het laden van de commando's die hij later zal uitvoeren om back-ups, herstelpunten en veilige opstartmodi uit te schakelen.
Figuur 41: Laden van commando's
Daarna laadt hij de locatie waar hij drie bestanden zal dumpen: Windows.bat, run.sct en start.bat.
Figuur 42: Bestandslocaties
Deze drie bestanden worden gebruikt om de rechten te controleren die elk van de locaties heeft. Als de vereiste rechten niet beschikbaar zijn, stopt Ryuk de uitvoering.
Hij gaat door met het laden van strings die overeenkomen met de drie bestanden. De eerste, DECRYPT_INFORMATION.html, bevat de informatie die nodig is om de bestanden te herstellen. De tweede, PUBLIC, bevat de RSA-openbare sleutel.
Figuur 43: String DECRYPT INFORMATION.html
De derde, UNIQUE_ID_DO_NOT_REMOVE, bevat een versleutelde sleutel die in het volgende subprogramma wordt gebruikt voor de versleuteling.
Figuur 44: Regel UNIQUE ID DO NOT REMOVE
Uiteindelijk laadt het de benodigde bibliotheken met de vereiste imports en CSP (Microsoft Enhanced RSA en AES Cryptographic Provider).
Figuur 45: Bibliotheken laden
Nadat de de-obfuscatie is voltooid, gaat het over tot de uitvoering van de noodzakelijke acties voor versleuteling: het doorlopen van alle logische schijven, het uitvoeren van wat in het vorige subprogramma is geladen, het versterken van de aanwezigheid in het systeem, het droppen van het bestand RyukReadMe.html, versleuteling, het doorscrollen van alle netwerkschijven, naar de ontdekte apparaten gaan en deze versleutelen.
Alles begint met het laden van "cmd.exe" en het schrijven van de open RSA-sleutel.
Figuur 46: Voorbereiding op versleuteling
Vervolgens verkrijgt het alle logische schijven via GetLogicalDrives en schakelt het alle back-ups, herstelpunten en veilige opstartmodi uit.
Figuur 47: Deactivering van hersteltools
Daarna versterkt het zijn aanwezigheid in het systeem, zoals we hierboven hebben gezien, en schrijft het het eerste bestand RyukReadMe.html in TEMP.
Figuur 48: Publicatie van het losgeldbericht
In de volgende afbeelding kunt u zien hoe het een bestand aanmaakt, de inhoud laadt en opschrijft:
Figuur 49: Inhoud van het bestand laden en opschrijven
Om dezezelfde acties op alle apparaten uit te voeren, gebruikt het
"icacls.exe", zoals we hierboven hebben weergegeven.
Figuur 50: Gebruik van icacls.exe
En tenslotte begint het met de versleuteling van bestanden, met uitzondering van de bestanden "*.exe", "*.dll", systeembestanden en andere locaties die zijn opgegeven in de vorm van een versleutelde whitelist. Hiervoor maakt het gebruik van imports: CryptAcquireContextW (waarbij het gebruik van AES en RSA is opgegeven), CryptDeriveKey, CryptGenKey, CryptDestroyKey enzovoort. Ook wordt geprobeerd om zijn werking uit te breiden naar de ontdekte netwerkapparaten met behulp van WNetEnumResourceW en vervolgens deze te versleutelen.
Figuur 51: Versleuteling van systeembestanden
6. Imports en bijbehorende vlaggen
Hieronder staat een tabel met de meest relevante imports en vlaggen die door het monster worden gebruikt:
7. IOC
Links
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgramsStartupstart.bat
Technisch rapport over de Ryuk-versleutelaar opgesteld door experts van het antiviruslaboratorium PandaLabs.
8. Links
1. “Everis en Prisa Radio ondergaan een ernstige cyberaanval die hun systemen gijzelt.”https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Gepubliceerd op 04/11/2019.
2. “Een virus van Russische oorsprong valt belangrijke Spaanse bedrijven aan.”https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Gepubliceerd op 04/11/2019.
3. “VB2019 paper: Shinigami’s wraak: de lange staart van de Ryuk-malware.”https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Gepubliceerd op 11/12/2019.
4. “Big Game Hunting met Ryuk: Een andere lucratieve gerichte ransomware.”https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Gepubliceerd op 10/01/2019.
5. “VB2019 paper: Shinigami’s wraak: de lange staart van de Ryuk-malware.”https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Bron: habr.com
