Как работи шифровальщика Ryuk, който атакува предприятия

Ryuk е един от най-известните варианти на ransomware в последните няколко години. Откакто се появи за първи път през лятото на 2018 г., той е събрал внушителен списък с жертви, особено в бизнес средата, която е основната цел на атаките му.

1. Обща информация

Този документ съдържа анализ на варианта на ransomware Ryuk, както и на товарача, отговорен за зареждането на злонамерен софтуер в системата.

Ransomware Ryuk за първи път се появява през лятото на 2018 г. Една от отличителните черти на Ryuk от другите ransomware е, че той е насочен към атака на корпоративни среди.

В средата на 2019 г. киберпрестъпни групи атакуваха голям брой испански компании с помощта на този ransomware.

Рис. 1: Изрезка от El Confidencial относно атаката на ransomware Ryuk [1]


Рис. 2: Изрезка от El País за атаката, извършена с помощта на ransomware Ryuk [2]

Тази година Ryuk атакува голям брой компании в различни страни. Както можете да видите на предоставените по-долу изображения, най-много пострадаха Германия, Китай, Алжир и Индия.

Сравнявайки броя на кибератаките, можем да видим, че от Ryuk пострадаха милиони потребители и огромен обем данни беше компрометиран, което доведе до сериозни икономически загуби.

Рис. 3: Илюстрация на глобалната активност на Ryuk.

Рис. 4: 16 страни, най-силно засегнати от Ryuk

Рис. 5: Брой на потребителите, атакувани от ransomware Ryuk (в милиони)

Според обичайната схема на работа на подобни заплахи, този ransomware след завършването на криптиране показва на жертвата уведомление за откуп, който трябва да бъде платен в биткойни на указан адрес за възстановяване на достъпа до криптираните файлове.

Този злонамерен софтуер е претърпял промени от момента на първоначалното си появяване.
Анализираният в този документ вариант на заплахата беше открит при опит за атака през януари 2020 г.

Поради своята сложност, този злонамерен софтуер често се приписва на организирани киберпрестъпни групи, известни също като APT-групи.

Част от кода Ryuk има значителна прилика с кода и структурата на друг известен шифровач Hermes, с който споделят редица сходни функции. Поради това в началото Ryuk беше свързван със севернокорейската група Lazarus, която по това време беше заподозряна в разработването на шифровача Hermes.

По-късно службата Falcon X на CrowdStrike отбеляза, че всъщност Ryuk е създаден от групата WIZARD SPIDER [4].

Има няколко доказателства, подкрепящи това предположение. Първо, този шифровач беше рекламирано на уебсайта exploit.in, известен руски пазар на злонамерен софтуер, който преди това беше свързан с няколко руски APT-групи.
Този факт изключва теорията, че Ryuk може да е бил разработен от APT-групата Lazarus, тъй като не съответства на начина, по който действа групата.

Освен това, Ryuk беше рекламирано като шифровач, който няма да работи на руски, украински и беларуските системи. Такова поведение се определя от функции, открити в някои версии на Ryuk, където той проверява езика на системата, в която е стартиран, и спира изпълнението си, ако системата е на руски, украински или беларуски език. Накрая, при експертен анализ на машината, която беше компрометирана от групата WIZARD SPIDER, бяха открити няколко „артефакта“, които предполагаемо са били използвани при разработването на Ryuk като вариант на шифровача Hermes.

От друга страна, експертите Габриела Николао и Лучано Мартинс предположиха, че шифровачът може би е бил разработен от APT-групата CryptoTech [5].
Това следва от факта, че няколко месеца преди появата на Ryuk, тази група публикува информация на форума на същия сайт, че са разработили нова версия на шифровача Hermes.

Няколко потребители на форума се запитаха дали наистина CryptoTech е създал Ryuk. След това тази група защити себе си и заяви, че има доказателства, че те разработили 100% от този шифровач.

2. Характеристики

Започваме с загрузчика, чиято задача е да идентифицира системата, в която се намира, за да може да стартира "правилната" версия на шифровача Ryuk.
Хешът на загрузчика е следният:

MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469

Една от характеристик на този зареждач е, че не съдържа никакви мета-данни, т.е. създателите на този зловреден софтуер не са включили в него никаква информация.

Понякога те включват погрешни данни, за да накарат потребителя да мисли, че стартира легитимно приложение. Въпреки това, както ще видим по-късно, в случаи, когато заразяването не изисква взаимодействие с потребителя (както в случая с този шифровалник), нападателите не смятат за необходимо да използват мета-данни.

Рис. 6: Мета-данни на образеца

Образецът е компилиран в 32-битов формат, за да може да се стартира както на 32-битови, така и на 64-битови системи.

3. Вектор на проникване

Образец, който зарежда и стартира Ryuk, е попаднал в нашата система чрез дистанционна връзка, а параметрите за достъп са били получени благодарение на предишна RDP атака.

Рис. 7: Регистър на атаката

Нападателят успя да влезе дистанционно в системата. След това той създаде изпълним файл с нашия образец.
Този изпълним файл беше блокиран от антивирусно решение преди стартиране.

Рис. 8: Блокиране на образеца

Рис. 9: Блокиране на образеца

Когато зловредният файл беше блокиран, нападателят се опита да зареди криптирана версия на изпълнимия файл, която също беше блокирана.

Рис. 10: Набор от образци, които нападателят се опита да стартира

Накрая, той се опита да зареди друг зловреден файл чрез криптирана конзола
PowerShell, за да заобиколи антивирусната защита. Но той също беше блокиран.

Рис. 11: PowerShell с блокирано зловредно съдържание


Рис. 12: PowerShell с блокирано зловредно съдържание

4. Зареждач

Когато се изпълнява, записва файл ReadMe в папката %temp%, което е типично за Ryuk. Този файл е искане за откуп, съдържащо адрес на електронна поща в домейн protonmail, който е доста често срещан в това семейство зловреден софтуер: msifelabem1981@protonmail.com

Рис. 13: Искане за откуп

По време на изпълнението на зареждача можете да видите, че той стартира няколко изпълними файла със случайни имена. Те се съхраняват в скрита папка PUBLIC, но ако опцията "Показване на скрити файлове и папки" не е активна в операционната система «Показвай скритите файлове и папки», те ще останат скрити. Освен това, тези файлове са 64-битови в сравнение с родителския файл, който е 32-битов.

Фиг. 14: Изпълними файлове, стартирани от образеца

Както можете да видите на горната фигура, Ryuk стартира icacls.exe, който ще се използва за промяна на всички списъци за контрол на достъпа ACL (Access Control List), като по този начин гарантира достъп и промяна на флаговете.

Той получава пълен достъп под всички потребители до всички файлове на устройството (\/T) независимо от грешките (\/C) и без да показва каквито и да е съобщения (\/Q).

Фиг. 15: Опции за изпълнение на icacls.exe, стартирано от образеца

Важно е да се вземе предвид, че Ryuk проверява коя версия на Windows е стартирана. За това той
извършва проверка на версията с помощта на GetVersionExW, където проверява стойността на флага lpVersionInformation, който показва дали текущата версия на Windows е по-нова от Windows XP.

В зависимост от това дали имате по-нова версия от Windows XP, зареждачът ще запише в папката на локалния потребител — в този случай в папката %Public%.

Фиг. 17: Проверка на версията на операционната система

Записваният файл е Ryuk. След това той го стартира, предавайки своя собствен адрес като параметър.

Фиг. 18: Изпълнение на Ryuk чрез ShellExecute

Първото, което прави Ryuk, е получаването на входни параметри. Този път съществуват два входни параметъра (самият изпълним файл и адресът на дроппера), които се използват за изтриване на собствените следи.

Фиг. 19: Създаване на процес

Можете също така да видите, че веднага след като стартира своите изпълними файлове, той се изтрива, така че да не оставя никакви следи от присъствието си в папката, където е бил изпълнен.

Фиг. 20: Изтриване на файла

5. RYUK

5.1 Присъствие
Ryuk, подобно на другите зловредни програми, се опитва да остане в системата колкото се може по-дълго. Както беше показано по-горе, един от начините за постигане на тази цел е тайното създаване и стартиране на изпълними файлове. За това най-разпространената практика е промяната на ключа в регистъра CurrentVersionRun.
В този случай можете да видите, че за тази цел първият стартиран файл VWjRF.exe
(именуването на файла се генерира произволно) стартира cmd.exe.

Фиг. 21: Изпълнение на файла VWjRF.exe

След това се въвежда команда RUN с името "svchos". Следователно, ако искате да проверите регистровите ключове по всяко време, можете лесно да не забележите това изменение, вземайки предвид сходството на това име с svchost. Благодарение на този ключ, Ryuk осигурява присъствието си в системата. Ако системата все още не е заразена, при рестартиране изпълняваният файл ще направи нов опит.

Рис. 22: Образецът осигурява присъствието в регистровия ключ

Също така можем да видим, че този изпълняем файл спира две услуги:
"audioendpointbuilder", което, както показва името му, съответства на системното аудио,

Рис. 23: Образецът спира услугата на системното аудио

и samss, която е услуга за управление на профили. Спирането на тези две услуги е характеристика на Ryuk. В този случай, ако системата е свързана с SIEM система, ransomware се опитва да спре изпращането на SIEM някакви предупреждения. По този начин, той защитава следващите си стъпки, тъй като някои SAM услуги няма да могат да стартират правилно след изпълнението на Ryuk.

Рис. 24: Образецът спира услугата Samss

5.2 Привилегии

Общо взето, Ryuk започва с хоризонтално движение в мрежата или се стартира от друга зловредна програма, като Emotet или Trickbot, които при ескалация на привилегиите предават тези повишени права на ransomware.

Предварително, в предшествието на внедряването, виждаме, че той изпълнява процеса ImpersonateSelf, което означава, че съдържанието на сигурността на токена за достъп ще бъде прехвърлено в потока, където веднага ще бъде получено с помощта на GetCurrentThread.

Рис. 25: Извикване на ImpersonateSelf

След това виждаме, че той ще свърже токена за достъп с потока. Също така виждаме, че един от флаговете е DesiredAccess, който може да се използва за контрол на достъпа, който ще има потокът. В този случай стойността, която edx ще получи, трябва да бъде TOKEN_ALL_ACESS или в противен случай — TOKEN_WRITE.

Рис. 26: Създаване на токен на потока

След това той ще използва SeDebugPrivilege и ще направи извикване за получаване на отладъчни права относно потока, като в резултат, указвайки PROCESS_ALL_ACCESS, ще може да получи достъп до всеки необходим процес. Сега, като се вземе предвид, че ransomware вече има подготвен поток, остава само да премине към приключителната фаза.

Рис. 27: Вика на SeDebugPrivilege и функция за повишаване на правата

От една страна, имаме LookupPrivilegeValueW, който ни предоставя необходимата информация за правата, които желаем да повишим.

Рис. 28: Искане на информация за правата с цел тяхното повишаване

От друга страна, ние имаме AdjustTokenPrivileges, който позволява да се получат необходимите права за нашия поток. В този случай най-важното е NewState, чийто флаг ще предоставя привилегии.

Рис. 29: Настройка на правата за токена

5.3 Внедряване

В този раздел ще покажем как примерът изпълнява процеса на внедряване, споменат по-рано в този отчет.

Основната цел на процеса на внедряване, подобно на повишаването на правата, е да получи достъп до сняпкови копия. За да направи това, той трябва да работи с поток с права, по-високи от тези на локалния потребител. След като получи такива по-високи права, той ще изтрие копията и ще направи промени в други процеси, за да направи невъзможно възстановяването до по-ранна точка в операционната система.

Както обикновено с този вид зловреден софтуер, за да изпълни внедряването, той използва CreateToolHelp32Snapshot, затова прави снимка на текущо изпълняваните процеси и се опитва да получи достъп до тези процеси чрез OpenProcess. След като получи достъп до процеса, той също така отваря токена с информацията му, за да получи параметрите на процеса.

Рис. 30: Получаване на процесите от компютъра

Можем динамично да видим как той получава списък на текущо изпълняваните процеси в подпрограмата 140002D9C с помощта на CreateToolhelp32Snapshot. След като получи списъка, той преминава през него, опитвайки един по един да отвори процесите с OpenProcess, докато не успее да го направи. В този случай първият процес, който успя да отвори, е «taskhost.exe».

Рис. 31: Динамично изпълнение на процедурата за получаване на процеса

Можем да видим, че впоследствие той чете информацията на токена на процеса, затова извиква OpenProcessToken с параметър "20008"

Рис. 32: Четене на информацията на токена на процеса

Също така проверява, че процесът, в който ще се внедрява, не е csrss.exe, explorer.exe, lsaas.exe или че има набор от права NT authority.

Рис. 33: Изключени процеси

Можем динамично да видим как той първо извършва проверка с информацията на токена на процеса в 140002D9C с цел да установим дали профилът, чиито права се използват за изпълнение на процеса, е профил NT AUTHORITY.

Рис. 34: Проверка на NT AUTHORITY

А после, извън процедурата, той проверява, че това не е csrss.exe, explorer.exe или lsaas.exe.

Рис. 35: Проверка на NT AUTHORITY

След като е направил снимка на процесите, отворил е процесите и е проверил, че нито един от тях не е изключен, той е готов да запише в паметта процесите, които ще бъдат внедрени.

За това първо резервира област в паметта (VirtualAllocEx), записва в нея (WriteProcessmemory) и създава поток (CreateRemoteThread). За работа с тези функции той използва PID-ите на избраните процеси, които предварително е получил с помощта на CreateToolhelp32Snapshot.

Рис. 36: Код за внедряване

Тук можем динамично да наблюдаваме как той използва PID на процеса за извикване на функцията VirtualAllocEx.

Рис. 37: Извикване на VirtualAllocEx

5.4 Шифриране
В тази част ще разгледаме част от този образец, свързана с шифрирането. На следващата рисунка можете да видите две подпрограми наименовани "LoadLibrary_EncodeString" и "Encode_Func", които отговарят за извършването на шифрова процедура.

Рис. 38: Процедури за шифриране

Първоначално можем да видим как той зарежда низ, който по-късно ще бъде използван за деобфускиране на всичко необходимо: импорти, DLL, команди, файлове и CSP.

Рис. 39: Верига на деобфускиране

На следващата рисунка е показан първият импорт, който той деобфускира в регистъра R4, LoadLibrary. Това ще бъде използвано по-късно за зареждане на необходимите DLL. Можем да видим и друг низ в регистъра R12, който се използва заедно с предишния низ за извършване на деобфускиране.

Рис. 40: Динамично деобфускиране

Той продължава да зарежда команди, които ще изпълни по-късно, за да изключи резервни копия, точки на възстановяване и безопасни начини на зареждане.

Рис. 41: Зареждане на команди

След това той зарежда локацията, където ще постави 3 файла: Windows.bat, run.sct и start.bat.

Рис. 42: Локации на файловете

Тези 3 файла се използват за проверка на правомощията, с които разполагат всяка от локациите. Ако изискваните права не са налични, Ryuk спира изпълнението.

Той продължава да зарежда низове, свързани с трите файла. Първият, DECRYPT_INFORMATION.html, съдържа информация, необходима за възстановяване на файловете. Вторият, PUBLIC, съдържа публичния ключ RSA.

Рис. 43: Страница DECRYPT INFORMATION.html

Третият, UNIQUE_ID_DO_NOT_REMOVE, съдържа шифрован ключ, който ще се използва в следващата подпрограма за извършване на шифроване.

Рис. 44: Строка UNIQUE ID DO NOT REMOVE

Накрая, той зарежда необходимите библиотеки, заедно с изискуемите импорти и CSP (Microsoft Enhanced RSA и AES Cryptographic Provider).

Рис. 45: Зареждане на библиотеките

След като цялата деобфускация е завършена, той преминава към извършване на действията, необходими за шифроване: обхождане на всички логически дискове, изпълнение на това, което е заредено в предишната подпрограма, усилване на присъствието в системата, разпространение на файла RyukReadMe.html, шифроване, обхождане на всички мрежови дискове, преминаване на откритите устройства и тяхното шифроване.
Всичко започва с зареждане на "cmd.exe" и записване на открития RSA-ключ.

Рис. 46: Подготовка за шифроване

След това той получава всички логически дискове с помощта на GetLogicalDrives и деактивира всички резервни копия, точки за възстановяване и безопасни режими на зареждане.

Рис. 47: Деактивиране на средствата за възстановяване

След това той усилва своето присъствие в системата, както видяхме по-горе, и записва първия файл RyukReadMe.html в TEMP.

Рис. 48: Публикация на уведомление за откуп

На следващата рисунка можете да видите как той създава файла, зарежда съдържанието и го записва:

Рис. 49: Зареждане и запис на съдържанието на файла

За да може да извърши същите действия на всички устройства, той използва
"icacls.exe", както показахме по-горе.

Рис. 50: Използване на icalcls.exe

И накрая, той започва шифроването на файловете, с изключение на файловете "*.exe", "*.dll", системните файлове и други локации, посочени в шифрован бел списък. За това той използва импортите: CryptAcquireContextW (където е посочено използването на AES и RSA), CryptDeriveKey, CryptGenKey, CryptDestroyKey и т.н. Също така се прави опит за разширяване на действието му върху откритите мрежови устройства с помощта на WNetEnumResourceW и след това шифроване.

Рис. 51: Шифроване на системните файлове

6. Импорти и съответните флагове

По-долу е таблица със списък на най-релевантните импорти и флагове, използвани в образеца:

7. IOC

Връзки

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

Техническият доклад за шифровальщика Ryuk е съставен от експертите на антивирусната лаборатория PandaLabs.

8. Ссылки

1. „Everis и Prisa Radio страдат от тежък кибератака, която задържа системите им.“ https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Публикувана на 04/11/2019.

2. „Вирус с руски произход атакува важни испански компании.“ https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Публикувана на 04/11/2019.

3. „VB2019 статия: Отмъщението на Shinigami: дългата опашка на злонамерения софтуер Ryuk.“ https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Публикувана на 11/12/2019.

4. „Big Game Hunting с Ryuk: Още една доходоносна цел за злонамерен софтуер.“ https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Публикувана на 10/01/2019.

5. „VB2019 статия: Отмъщението на Shinigami: дългата опашка на злонамерения софтуер Ryuk.“ https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r

Източник: habr.com