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 (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, подобно другим вредоносным программам, пытается оставаться в системе как можно дольше. Как было показано выше, один из способов для достижения этой цели — это скрытное создание и запуск исполняемых файлов. Для этого наиболее распространенной практикой является изменение ключа реестра CurrentVersion\Run.
В данном случае Вы можете видеть, что для этой цели первый запускаемый файл 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 и сделает вызов для получения отладочных прав 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, содержит информацию, необходимую для восстановления файлов. Вторая, 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
Ссылки
- users\Public\run.sct
- Start Menu\Programs\Startup\start.bat AppData\Roaming\Microsoft\Windows\Start
- Menu\ProgramsStartup\start.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 de origen ruso ataca a importantes empresas españolas.”https: //elpais.com/ tecnologia/2019/11/04/actualidad/1572897654_ 251312.html, Publicada el 04/11/2019.
3. “VB2019 paper: Shinigami’s revenge: the 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 LucrativebTarge- ted 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: the long tail of the Ryuk malware.”https://www. virusbulletin.com/virusbulletin/2019/10/ vb2019-paper-shinigamis-revenge-long-tail-r
