Ryuk – це один із найвідоміших варіантів шифрувальників за останні кілька років. Відколи він вперше з'явився влітку 2018 року, він зібрав , особливо в бізнес-середовищі, яке є головним об'єктом його атак.
1. Загальна інформація
Цей документ містить аналіз варіанта шифрувальника Ryuk, а також завантажувача, який відповідає за завантаження шкідливої програми в систему.
Шифрувальник Ryuk вперше з'явився влітку 2018 року. Одна з відмінностей Ryuk від інших шифрувальників полягає в тому, що він націлений на атаку корпоративних оточень.
У середині 2019 року кібер-кримінальні угруповання атакували величезну кількість іспанських компаній за допомогою цього шифрувальника.
Мал. 1: Уривок з El Confidencial з приводу атаки шифрувальника Ryuk [1]
Мал. 2: Уривок з El País про атаку, зроблену за допомогою шифрувальника Ryuk [2]
Цього року Ryuk атакував велику кількість компаній у різних країнах. Як Ви можете бачити на наведених нижче малюнках, найбільше постраждали Німеччина, Китай, Алжир та Індія.
Порівнюючи кількість кібер-атак, ми можемо бачити, що від Ryuk постраждали мільйони користувачів і скомпрометовано величезний обсяг даних, що призвело до серйозних економічних збитків.
Мал. 3: Ілюстрація глобальної активності Рюк.
Мал. 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, який часто зустрічається в цьому сімействі шкідливих програм: [захищено електронною поштою]
Мал. 13: Вимога про викуп
Під час виконання завантажувача Ви можете побачити, що він запускає кілька файлів з випадковими назвами. Вони зберігаються у прихованій папці ГРОМАДСЬКЕ, але якщо в операційній системі не активна опція «Показувати приховані файли та папки», то вони так і залишаться прихованими. Більше того, ці файли 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, яка є службою керування обліковими записами. Зупинка цих двох служб є характеристикою Рюк. В даному випадку, якщо система пов'язана з SIEM-системою, то шифрувальник намагається зупинити відправку в будь-яких попереджень. Таким чином, він захищає свої наступні кроки, оскільки деякі SAM-служби не зможуть правильно розпочати свою роботу після виконання Рюк.
Мал. 24: Зразок зупиняє службу Samss
5.2 Привілеї
Взагалі кажучи, Ryuk починається з горизонтального переміщення всередині мережі або він запускається іншою шкідливою програмою, такою як або , які у разі ескалації привілеїв передають ці підвищені права шифрувальнику.
Заздалегідь, як прелюдія до процесу впровадження, ми бачимо, що він виконує процес ImpersonateSelf, а це означає, що вміст безпеки токена доступу буде передано в потік, де він буде негайно отримано за допомогою GetCurrentThread.
Мал. 25: Виклик ImpersonateSelf
Потім бачимо, що він зв'яже токен доступу з потоком. Ми також бачимо, що один із прапорів — це DesiredAccess, який може бути використаний для контролю доступу, який буде мати потік. У цьому випадку значення, яке отримає edx, має бути TOKEN_ALL_ACESS або в іншому випадку - TOKEN_WRITE.
Мал. 26: Створення потоку потоку
Потім він використовуватиме SeDebugPrivilege і зробить виклик для отримання налагоджувальних прав Debug по відношенню до потоку, внаслідок чого вказавши 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містить інформацію, необхідну для відновлення файлів. Друга, ГРОМАДСЬКЕмістить відкритий ключ 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 y Prisa Radio sufren un grave ciberataque que secuestra sus sistemas."https://www. elconfidencial.com/tecnologia/2019-11-04/ everis-la-ser-ciberataque-ransomware-15_2312019/, Publicada el 04/11/2019.
2. "Un virus d'origen ruso ataca a importantes empresas españolas."
3. “VB2019 paper: Shinigami's revenge: long tail of the Ryuk malware.”https://securelist.com/ story-of-the-year-2019-cities-under-ransomware-siege/95456/, Publicada el 11 /12/2019
4. “Big Game Hunting with Ryuk: Another LucrativebTargeted Ransomware.”https://www. crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Publicada el 10/01/2019.
5. “VB2019 paper: Shinigami's revenge: long tail of the Ryuk malware.”https://www. virusbulletin.com/virusbulletin/2019/10/ vb2019-paper-shinigamis-revenge-long-tail-r
Джерело: habr.com