Как работи шифровачът Ryuk, който атакува предприятия

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

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

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

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

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

Рис. 1: Откъс от El Confidencial относно атаката на криптиращия софтуер Ryuk [1]


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

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

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

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

Рис. 4: 16-те държави, най-много пострадали от Ryuk

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

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

Тази злонамерена програма се е променила от момента на първоначалното си появяване.
Вариантът на тази заплаха, анализиран в този документ, беше открит при опит за атака през януари 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), като по този начин гарантира достъп и промяна на флаговете.

Той получава пълен достъп под всички потребители до всички файлове на устройството (\/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-система, то шифровалкият софтуер се опитва да спре изпращането на SIEM каквито и да било предупреждения. Така, той защитава следващите си стъпки, тъй като някои SAM-услуги няма да могат да стартират правилно след изпълнението на Ryuk.

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

5.2 Привилегии

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

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

Рис. 25: Вика на ImpersonateSelf

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

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

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

Рис. 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 доклад: Отмъщението на Шинигами: дългата опашка на малвари Ryuk."https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Публикувано на 11/12/2019.

4. "Голямо ловуване с Ryuk: Още една печеливша цел за ransomware."https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Публикувано на 10/01/2019.

5. "VB2019 доклад: Отмъщението на Шинигами: дългата опашка на малвари Ryuk."https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r

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