Hur Ryuk-krypteraren fungerar som attackerar företag

Ryuk är en av de mest kända varianterna av ransomware under de senaste åren. Sedan den först dök upp sommaren 2018 har den samlat en imponerande lista över offer, särskilt inom affärsvärlden, som är det främsta målet för dess attacker.

1. Allmän information

Detta dokument innehåller en analys av ransomware-varianten Ryuk, samt en loader som ansvarar för att ladda ner den skadliga programvaran till systemet.

Ransomware Ryuk dök först upp sommaren 2018. En av de saker som särskiljer Ryuk från andra ransomware är att den riktar sig mot att attackera företagsmiljöer.

I mitten av 2019 attackerade cyberkriminella grupper ett stort antal spanska företag med detta ransomware.

Fig. 1: Utdrag från El Confidencial om Ryuk-ransomwareattacken [1]


Fig. 2: Utdrag från El País om attacken som utfördes med Ryuk-ransomware [2]

I år har Ryuk attackerat ett stort antal företag i olika länder. Som ni kan se i de nedan angivna bilderna drabbades Tyskland, Kina, Algeriet och Indien hårdast.

Genom att jämföra antalet cyberattacker kan vi se att miljontals användare drabbades av Ryuk, och en enorm mängd data komprometterades, vilket ledde till betydande ekonomiska förluster.

Fig. 3: Illustration av Ryuks globala aktivitet.

Fig. 4: 16 länder som drabbades mest av Ryuk

Fig. 5: Antal användare som attackerades av Ryuk-ransomware (i miljoner)

Enligt det vanliga arbetssättet för sådana hot, visar detta ransomware efter att krypteringen är klar ett meddelande till offret om en lösesumma som måste betalas i bitcoins till den angivna adressen för att återfå tillgång till de krypterade filerna.

Denna skadliga programvara har förändrats sedan den först dök upp.
Varianten av detta hot som analyseras i detta dokument upptäcktes när man försökte genomföra en attack i januari 2020.

På grund av sin komplexitet tillskrivs denna skadliga programvara ofta organiserade cyberkriminella grupper, även kända som APT-grupper.

En del av Ryuk-koden har en märkbar likhet med koden och strukturen hos en annan känd ransomware, Hermes, som de har flera gemensamma funktioner. Just därför kopplades Ryuk ursprungligen till den nordkoreanska gruppen Lazarus, som då misstänktes ligga bakom ransomwaret Hermes.

Senare noterade Falcon X-tjänsten från CrowdStrike att Ryuk faktiskt skapades av gruppen WIZARD SPIDER [4].

Det finns flera bevis som stöder denna teori. För det första annonserades denna ransomware på webbplatsen exploit.in, som är en känd rysk marknadsplats för skadlig programvara och tidigare har kopplats till vissa ryska APT-grupper.
Denna fakta utesluter teorin om att Ryuk skulle ha utvecklats av APT-gruppen Lazarus, eftersom det inte stämmer överens med hur gruppen agerar.

Dessutom annonserades Ryuk som en ransomware som inte skulle fungera på ryska, ukrainska och vitryska system. Detta beteende bestäms av funktioner som upptäckts i vissa versioner av Ryuk, där den kontrollerar språket på det system som ransomware är aktiverad i och stoppar dess drift om systemet har ryska, ukrainska eller vitryska språk. Slutligen, vid en expertanalys av en maskin som hackades av WIZARD SPIDER, upptäcktes flera 'artefakter' som antas ha använts vid utvecklingen av Ryuk som en variant av ransomwaret Hermes.

Å andra sidan föreslog experterna Gabriela Nicolo och Luciano Martins att ransomwaret möjligtvis utvecklades av APT-gruppen CryptoTech [5].
Detta följer av det faktum att några månader före Ryuks debut publicerade denna grupp information på forumet på samma webbplats om att de hade utvecklat en ny version av ransomwaret Hermes.

Flera användare på forumet undrade om CryptoTech verkligen hade skapat Ryuk. Efter detta försvarade gruppen sig och hävdade att de hade bevis för att de utvecklade 100% av detta ransomware.

2. Egenskaper

Vi börjar med bootloadern, vars uppgift är att identifiera systemet där den befinner sig, så att rätt version av Ryuk-ransomware kan startas.
Hashen av bootloadern är följande:

MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469

En av funktionerna hos denna bootloader är att den inte innehåller någon metadata, det vill säga att skaparna av detta skadliga program inte inkluderade någon information i den.

Ibland inkluderar de felaktiga data för att få användaren att tro att de på något sätt kör en legitim applikation. Men som vi kommer att se senare, om infektionen inte kräver användarinteraktion (som i fallet med denna ransomware), anser angriparna att det inte är nödvändigt att använda metadata.

Fig. 6: Metadata för provet

Provfilen har kompilerats i 32-bitarsformat så att den kan köras både på 32-bitars och 64-bitars system.

3. Intrångvektor

Provfilen som laddar och kör Ryuk kom in i vårt system via en fjärranslutning, och åtkomstparametrarna erhölls genom en förhands-RDP-attack.

Fig. 7: Attackregister

Angriparen lyckades logga in på systemet på distans. Efter det skapade han en körbar fil med vårt prov.
Denna körbara fil blockades av antiviruslösningen innan den kördes.

Fig. 8: Blockering av provet

Fig. 9: Blockering av provet

När den skadliga filen blockerades försökte angriparen ladda ner en krypterad version av den körbara filen, som också blockerades.

Fig. 10: Uppsättning av prover som angriparen försökte köra

Till slut försökte han ladda ner en annan skadlig fil via en krypterad konsol
PowerShell för att kringgå antivirusförsvaret. Men den blockerades också.

Fig. 11: PowerShell med blockerat skadligt innehåll


Fig. 12: PowerShell med blockerat skadligt innehåll

4. Bootloader

När den körs skriver den ReadMe-filen i mappen %temp%, vilket är typiskt för Ryuk. Denna fil är ett lösenkrav som innehåller en e-postadress i domänen protonmail, som är ganska vanlig i denna typ av skadlig programvara: msifelabem1981@protonmail.com

Fig. 13: Lösenkrav

Under körningen av bootloadern kan du se att den startar flera körbara filer med slumpmässiga namn. De lagras i en dold mapp PUBLIC, men om alternativet «Visa dolda filer och mappar» inte är aktiverat i operativsystemet., de så kommer de förbli dolda. Dessutom är dessa filer 64-bitars till skillnad från moderfilen som är 32-bitars.

Fig. 14: Exekverbara filer som körs av provet

Som du kan se i ovanstående bild, kör Ryuk icacls.exe, som kommer att användas för att ändra alla åtkomstkontrollistor (ACL), vilket säkerställer åtkomst och förändring av flaggor.

Han får full tillgång under alla användare till alla filer på enheten (/T) oavsett fel (/C) och utan att visa några meddelanden (/Q).

Fig. 15: Körningsparametrar för icacls.exe, som körs av provet

Det är viktigt att notera att Ryuk kontrollerar vilken version av Windows som körs. För detta
utför han en versionskontroll med hjälp av GetVersionExW, där han kontrollerar värdet för flaggan lpVersionInformation, som visar om den nuvarande versionen av Windows är senare än Windows XP.

Beroende på om du har en senare version än Windows XP, kommer laddaren att skriva till den lokala användarmappen — i detta fall till mappen %Public%.

Fig. 17: Versionskontroll av operativsystemet

Den skrivna filen är Ryuk. Sedan kör han den och passerar sin egen adress som parameter.

Fig. 18: Utförande av Ryuk via ShellExecute

Det första Ryuk gör är att hämta inparameterar. Denna gång finns det två ingångsparameter (själva den exekverbara filen och dropparens adress) som används för att ta bort sina egna spår.

Fig. 19: Skapande av process

Du kan också se att så snart han har kört sina exekverbara filer, tar han bort sig själv, vilket inte lämnar några spår av sin egen närvaro i den mapp där han blev utförd.

Fig. 20: Ta bort filen

5. RYUK

5.1 Närvaro
Ryuk, liksom andra skadliga program, försöker att förbli i systemet så länge som möjligt. Som visats ovan är en av sätten att uppnå detta mål att på ett dolt sätt skapa och köra exekverbara filer. För detta är det vanligaste förfarandet att ändra registernyckeln CurrentVersionRun.
I det här fallet kan du se att för detta syfte den första exekverbara filen VWjRF.exe
(filnamnet genereras slumpmässigt) kör cmd.exe.

Fig. 21: Utföra filen VWjRF.exe

Sedan anges kommandot RUN med namnet "svchos". På så sätt, om du vill kontrollera registernycklarna vid något tillfälle, kan du enkelt missa denna ändring på grund av likheten med namnet svchost. Genom denna nyckel säkerställer Ryuk sin närvaro i systemet. Om systemet fortfarande inte har blivit infekterat, kommer det exekverbara filen att försöka igen efter omstart av systemet.

Fig. 22: Provet säkerställer närvaro i registernyckeln

Vi kan också se att denna exekverbara fil stoppar två tjänster:
"audioendpointbuilder", som, som namnet antyder, motsvarar den systemiska ljudtjänsten,

Fig. 23: Provet stoppar den systemiska ljudtjänsten

och samss, som är en tjänst för hantering av användarkonton. Att stoppa dessa två tjänster är en kännetecken för Ryuk. I det här fallet, om systemet är kopplat till ett SIEM-system, försöker krypteraren stoppa överföringen av SIEM eventuella varningar. På så sätt skyddar den sina efterföljande steg, eftersom vissa SAM-tjänster inte kommer att kunna starta korrekt efter att Ryuk har kört.

Fig. 24: Provet stoppar tjänsten Samss

5.2 Privilegier

Generellt sett börjar Ryuk med horisontell rörlighet inom nätverket eller körs av en annan skadlig programvara, som Emotet eller Trickbot, som vid privilegieförhöjning överför dessa upphöjda rättigheter till krypteraren.

I förväg, som en inledning till implementeringsprocessen, ser vi att det kör processen ImpersonateSelf, vilket innebär att säkerhetsinnehållet för åtkomsttoken kommer att överföras till tråden, där det omedelbart kommer att erhållas med hjälp av GetCurrentThread.

Fig. 25: Anrop av ImpersonateSelf

Sedan ser vi att den kommer att koppla åtkomsttoken med tråden. Vi ser också att en av flaggorna är DesiredAccess, som kan användas för att kontrollera åtkomsten som tråden kommer att ha. I det här fallet bör värdet som edx får vara TOKEN_ALL_ACESS eller annars - TOKEN_WRITE.

Fig. 26: Skapande av trådtokens

Sedan kommer den att använda SeDebugPrivilege och göra ett anrop för att få debug-rättigheter Debug i relation till tråden, vilket gör att den, genom att ange PROCESS_ALL_ACCESS, kan få tillgång till alla nödvändiga processer. Nu, med tanke på att krypteraren redan har en förberedd tråd, finns det bara en sista fas kvar att genomföra.

Fig. 27: Anrop av SeDebugPrivilege och privilegihöjande funktion

Å ena sidan har vi LookupPrivilegeValueW, som ger oss nödvändig information om de privilegier som vi vill höja.

Fig. 28: Begäran om privilegier för deras höjning

Å andra sidan har vi AdjustTokenPrivileges, som gör det möjligt att få de nödvändiga rättigheterna för vår process. I det här fallet är det viktigaste NewState, vars flagga kommer att tillhandahålla privilegier.

Fig. 29: Inställning av rättigheter för token

5.3 Injektion

I det här avsnittet visar vi hur ett exempel genomför den injektionsprocess som redan nämnts i denna rapport.

Huvudsyftet med injektionsprocessen, liksom med höjningen, är att få tillgång till skuggkopior.För detta behöver det arbeta med en process med högre rättigheter än den lokala användaren. Så snart det får sådana högre rättigheter kommer det att ta bort kopior och göra ändringar i andra processer för att förhindra återgång till en tidigare återställningspunkt i operativsystemet.

Som vanligt med denna typ av skadlig kod använder det CreateToolHelp32Snapshot, så det tar en bild av för närvarande körande processer och försöker få åtkomst till dessa processer med hjälp av OpenProcess.Så snart det får åtkomst till processen öppnar det också en token med dess information för att hämta processparametrarna.

Fig. 30: Hämtar processer från datorn

Vi kan dynamiskt se hur det får en lista över körande processer i underprogrammet 140002D9C med hjälp av CreateToolhelp32Snapshot. Efter att ha erhållit dem går det igenom listan och försöker öppna processerna en efter en med hjälp av OpenProcess tills det lyckas. I detta fall är den första processen som det kunde öppna "taskhost.exe".

Fig. 31: Dynamisk utförandeprocedur för att hämta processen

Vi kan se att det senare läser information om token för processen, så det anropar OpenProcessToken med parametern "20008"

Fig. 32: Läsning av information om processens token

Det kontrollerar också att processen som det kommer att injicera sig i inte är csrss.exe, explorer.exe, lsaas.exe, eller att den har en uppsättning rättigheter NT authority. Fig. 33: Uteslutna processer.

Vi kan dynamiskt se hur det först genomför kontrollen med hjälp av informationen från processens token i

140002D9C. 140002D9C för att ta reda på om kontot vars rättigheter används för att köra processen är ett konto NT AUTHORITY.

Fig. 34: Kontroll av NT AUTHORITY

Och senare, utanför proceduren, kontrollerar han att detta inte är csrss.exe, explorer.exe eller lsaas.exe.

Fig. 35: Kontroll av NT AUTHORITY

Efter att han har tagit en snapshot av processerna öppnar han processerna och kontrollerar att ingen av dem är undantagen, han är redo att skriva in i minnet de processer som kommer att injiceras.

För detta reserverar han först ett område i minnet (VirtualAllocEx), skriver i det (WriteProcessmemory) och skapar en tråd (CreateRemoteThread). För att arbeta med dessa funktioner använder han PID:er för de valda processerna, som han tidigare har fått med hjälp av CreateToolhelp32Snapshot.

Fig. 36: Kod för injektion

Här kan vi dynamiskt observera hur han använder PID för att anropa funktionen VirtualAllocEx.

Fig. 37: Anrop av VirtualAllocEx

5.4 Kryptering
I detta avsnitt kommer vi att titta på den del av detta exempel som rör kryptering. På nästa bild kan du se två underprogram med namnen "LoadLibrary_EncodeString" och "Encode_Func", som ansvarar för att utföra krypteringsproceduren.

Fig. 38: Krypteringsprocedurer

I början kan vi se hur han laddar en sträng som senare kommer att användas för att deobfuskera allt som behövs: importer, DLL, kommandon, filer och CSP.

Fig. 39: Deobfuskeringens kedja

På nästa bild visas den första importen som han deobfuskera i registret R4, LoadLibrary. Detta kommer att användas senare för att ladda de nödvändiga DLL:erna. Vi kan också se en annan sträng i registret R12, som används tillsammans med den föregående strängen för att utföra deobfuskering.

Fig. 40: Dynamisk deobfuskering

Han fortsätter att ladda kommandon som han senare kommer att köra för att stänga av säkerhetskopior, återställningspunkter och säkra startlägen.

Fig. 41: Laddning av kommandon

Sedan laddar han platsen där han kommer att dumpa 3 filer: Windows.bat, run.sct och start.bat.

Fig. 42: Filplatser

Dessa 3 filer används för att kontrollera de behörigheter som varje plats har. Om de nödvändiga behörigheterna inte är tillgängliga stoppar Ryuk körningen.

Han fortsätter att ladda strängarna för de tre filerna. Den första, DECRYPT_INFORMATION.html, innehåller information som behövs för att återställa filer. Den andra, PUBLIC, innehåller den öppna RSA-nyckeln.

Fig. 43: Row DECRYPT INFORMATION.html

Tredje, UNIQUE_ID_DO_NOT_REMOVE, innehåller en krypterad nyckel som kommer att användas i nästa delprogram för att utföra kryptering.

Fig. 44: Rad UNIQUE ID DO NOT REMOVE

Till slut laddar den de nödvändiga biblioteken tillsammans med de nödvändiga importerna och CSP (Microsoft Enhanced RSA och AES Cryptographic Provider).

Fig. 45: Laddning av bibliotek

Efter att hela deobfuskeringen är klar, går den vidare till att utföra de åtgärder som krävs för kryptering: genomsöka alla logiska enheter, utföra det som laddades i föregående delprogram, förstärka närvaron i systemet, placera filen RyukReadMe.html, kryptera, genomsöka alla nätverksenheter, gå till upptäckta enheter och deras kryptering.
Allt börjar med att ladda "cmd.exe" och skriva den öppna RSA-nyckeln.

Fig. 46: Förberedelse för kryptering

Sedan får den alla logiska enheter med hjälp av GetLogicalDrives och stänger av alla säkerhetskopior, återställningspunkter och säkra startlägen.

Fig. 47: Deaktivera återställningsmedel

Efter detta förstärker den sin närvaro i systemet, som vi såg tidigare, och skriver den första filen RyukReadMe.html på TEMP.

Fig. 48: Publicering av lösenordsavisering

I nästa bild kan du se hur den skapar en fil, laddar innehållet och skriver det:

Fig. 49: Ladda och skriv filinnehåll

För att kunna utföra dessa åtgärder på alla enheter använder den
"icacls.exe", som vi visade tidigare.

Fig. 50: Användning av icalcls.exe

Och slutligen börjar den kryptera filer, med undantag för filer "*.exe", "*.dll", systemfiler och andra platser som anges i form av en krypterad vitlista. För detta använder den importerna: CryptAcquireContextW (där AES och RSA används), CryptDeriveKey, CryptGenKey, CryptDestroyKey etc. Det görs även ett försök att utöka sin påverkan på upptäckta nätverksenheter med hjälp av WNetEnumResourceW för att sedan kryptera dem.

Fig. 51: Kryptering av systemfiler

6. Importer och motsvarande flaggor

Nedan är en tabell med en lista över de mest relevanta importerna och flaggorna som används av mallen:

7. IOC

Länkar

• usersPublicrun.sct
• Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
• MenuProgramsStartupstart.bat

Den tekniska rapporten om Ryuk-krypteraren har sammanställts av experter från antiviruslaboratoriet PandaLabs.

8. Referenser

1. "Everis och Prisa Radio drabbas av en allvarlig cyberattack som kapar deras system." https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Publicerad den 04/11/2019.

2. "Ett virus av ryskt ursprung attackerar viktiga spanska företag." https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Publicerad den 04/11/2019.

3. "VB2019-papper: Shinigamis hämnd: den långa svansen av Ryuk-malware." https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Publicerad den 11/12/2019.

4. "Big Game Hunting med Ryuk: En annan lukrativt riktad ransomware." https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Publicerad den 10/01/2019.

5. "VB2019-papper: Shinigamis hämnd: den långa svansen av Ryuk-malware." https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r

Källa: habr.com