- Сообщения
- 24,688
- Реакции
- 13,553
Вымогатель Phobos появился в начале 2019 года. Этот новый тип вымогателей основан на ранее известном семействе: Dharma (он же CrySis) и, вероятно, распространяется той же группой, что и Дхарма .
Phobos является одним из вымогателей, которые распространяются через взломанные RDP. Это неудивительно, поскольку взломанные RDP-серверы являются дешевым товаром на подпольном рынке.
Анализируемый образец
a91491f45b851a07f91ba5a200967921bf796d38677786de51a4a8fe5ddeafd2
Поведенческий анализ
Этот вымогатель не пытается обойти UAC. Хотя это и не нужно учитывая, что используется ручной вход через RDP:
Если мы согласимся, то основной процесс развернет еще одну свою копию с повышенными привилегиями. Он также выполняет некоторые команды через оболочку Windows.
Требования выкупа создаются двух типов: .txt и .hta. После того, как процесс шифрования закончен, выскакивает примечание о выкупе в форме .hta:
Даже после появления уведомления о выкупе вредоносное ПО по-прежнему работает в фоновом режиме и продолжает шифровать вновь созданные файлы.
Все локальные диски, а также сетевые ресурсы подвергаются атакам.
Шифровальщик также использует несколько механизмов автозапуска: устанавливает себя в% APPDATA% и в папку «Автозагрузка», добавляя ключи реестра для автоматического запуска своего процесса при перезапуске системы.
Эти механизмы позволяют оставаться активным вредоносному ПО в системе длительное время.
Процесс шифрования
Программа-вымогатель может зашифровать файлы без подключения к интернету (на данный момент мы можем догадаться, что он поставляется с некоторым жестко закодированным открытым ключом). Каждый файл шифруется отдельным ключом или вектором инициализации: один и тот же открытый текст генерирует другой зашифрованный текст.
Он шифрует различные файлы, в том числе исполняемые файлы. Зашифрованные файлы имеют адрес электронной почты злоумышленника. Конкретный вариант Фобоса также добавляет расширение .acute - однако в разных вариантах встречались разные расширения. Общий шаблон:<original name>.id[<victim ID>-<version ID>][<attacker's e-mail>].<added extention>
Визуализация зашифрованного содержимого не отображает какие-либо узнаваемые шаблоны. Это предполагает использование либо потокового шифра, либо шифра с цепочками блоков (возможно, AES в режиме CBC ). Пример - простой BMP до и после шифрования:
Когда мы заглядываем внутрь зашифрованного файла, в конце мы видим определенный блок. Он отделяется от зашифрованного содержимого заполнением байтов 0. Первые 16 байтов этого блока являются уникальными для каждого файла (возможный вектор инициализации). Затем идет блок из 128 байтов, который одинаков в каждом файле. Возможно, это означает, что этот блок содержит зашифрованный ключ, который генерируется уникальным образом при каждом запуске. В конце мы можем найти ключевое слово длиной 6 символов, которое является типичным для этого вымогателя. В данном случае это «LOCK96», однако были обнаружены разные версии Фобоса с разными ключевыми словами, например «DAT260».
Чтобы полностью понять процесс шифрования, мы рассмотрим код.
внутри
В отличие от большинства вредоносных программ, которые защищены каким-либо криптером, Фобос не упакован и не запутан. Хотя отсутствие упаковки не является распространенным явлением среди общего числа вредоносных программ, оно часто встречается среди вредоносных программ, распространяемых злоумышленниками вручную.
Выполнение начинается в функции WinMain:
Во время выполнения Phobos запускает несколько потоков, отвечающих за его различные действия, такие как: удаление процессов из черного списка, развертывание команд из командной строки, шифрование доступных дисков и сетевых ресурсов.
Используется запутывание
Код вымогателей не упакован и не запутан. Однако некоторые константы, включая строки, защищены AES и расшифрованы по требованию. Определенная строка может быть запрошена по ее индексу, например:
Ключ AES, используемый для этой цели, жестко закодирован (в запутанном виде) и импортируется каждый раз, когда необходимо расшифровать часть данных.
Вектор инициализации установлен в 16 пустых байтов.
Код, ответственный за загрузку ключа AES, приведен ниже. Функция оборачивает ключ в структуру BLOBHEADER , которая затем импортируется.
Из структуры BLOBHEADER мы можем прочитать следующую информацию: 0x8 - PLAINTEXTKEYBLOB, 0x2 = CUR_BLOB_VERSION, 0x6610 - CALG_AES_256.
Пример расшифрованной строки:
Среди расшифрованных строк мы также видим список атакованных расширений.
Мы также можем найти список некоторых ключевых слов:
Это список возможных расширений, используемых этим вымогателем. Они (вероятно) используются для распознавания и пропуска файлов, которые уже были зашифрованы вымогателями из этого семейства. Расширение, которое будет использоваться в текущем цикле шифрования, жестко закодировано.
Одна из зашифрованных строк определяет формулу для расширения файла, которое позже заполняется идентификатором жертвы:
UNICODE ".id[<unique ID>-1096].[lockhelp@qq.com].acute"
Завершаемые процессы
Вымогатель поставляется со списком процессов, которые он убивает, прежде чем шифрование развернуто. Как и другие строки, полный список расшифровывается по требованию:
Ransomware развертывает несколько команд из командной строки. Эти команды должны предотвращать восстановление зашифрованных файлов из любых резервных копий.
Удаление теневых копий:
vssadmin delete shadows /all /quiet
wmic shadowcopy delete
Изменение параметров Bcdedit (предотвращение загрузки системы в режиме восстановления):
bcdedit /set {default} bootstatuspolicy ignoreallfailures
bcdedit /set {default} recoveryenabled no
Удаляет каталог резервных копий на локальном компьютере:
wbadmin delete catalog -quiet
Это также отключает брандмауэр:
netsh advfirewall set currentprofile state off
netsh firewall set opmode mode=disable
exit
Атакованные цели
Перед тем как Фобос начинает вредоносные действия, он проверяет системную локаль (используя GetLocaleInfoW опции: LOCALE_SYSTEM_DEFAULT , LOCALE_FONTSIGNATURE ). Завершает выполнение в случае, если очищен 9-й бит вывода. 9-й бит представляет кириллические алфавиты, поэтому на системы, которые установили его по умолчанию, это не влияет.
Как локальные диски, так и сетевые ресурсы зашифрованы.
Перед началом шифрования Phobos перечисляет все файлы и сравнивает их имена с жестко закодированными списками. Списки хранятся в двоичном виде в зашифрованном виде AES, строки разделяются разделителем ';'.
Среди этих списков мы можем найти, например, черный список (эти файлы будут пропущены). Эти файлы относятся к операционной системе, а файлы info.txt, info.hta являются именами записок о выкупе Фобоса:
Существует также список каталогов , которые должны быть пропущены - в анализируемом случае он содержит только один каталог: C:\Windows.
Среди пропущенных файлов есть также расширения, которые используются вариантами Phobos, которые были упомянуты ранее.
Существует также довольно длинный белый список расширений:
Как работает шифрование
Phobos использует WindowsCrypto API для шифрования файлов. Существует несколько параллельных потоков для развертывания шифрования на каждом доступном диске или сетевом ресурсе.
Ключ AES создается до запуска потока шифрования и передается в параметре потока.
Фрагмент функции генерации ключа:
Хотя ключ AES является общим для всех файлов, которые зашифрованы в одном раунде, тем не менее, каждый файл зашифрован с различным вектором инициализации. Вектор инициализации имеет длину 16 байт, генерируется непосредственно перед открытием файла и затем передается в функцию шифрования:
Ниже ключ AES и вектор инициализации генерируются с помощью одной и той же функции, которая является оберткой CryptGenRandom(сильный генератор случайных чисел):
AES IV позже добавляется к содержимому зашифрованного файла в виде открытого текста. Мы можем видеть это на следующем примере:
Перед выполнением функции шифрования файла генерируется случайный IV:
Ключ AES, который был передан потоку, импортируется в context ( CryptImportKey), а также устанавливается IV. Мы видим, что содержимое прочитанного файла зашифровано:
После того, как содержимое файла зашифровано, оно сохраняется во вновь созданном файле с расширением вымогателей.
Программа-вымогатель создает блок с метаданными, включая контрольные суммы и исходное имя файла. После этого блока сохраняется случайный IV, и, наконец, блок, содержащий зашифрованный ключ AES. Последний элемент - маркер файла: «LOCK96»:
Перед записью в файл блок метаданных шифруется с использованием того же ключа AES и IV, что и содержимое файла.
установка ключа AES перед шифрованием блока метаданных
Блок зашифрованных метаданных:
Наконец, содержимое добавляется в конец вновь созданного файла:
Будучи исследователем вымогателей, общий вопрос, на который мы хотим ответить, заключается в том, является ли вымогатель дешифруемым, то есть, содержит ли он слабость, позволяющую восстановить файлы без уплаты выкупа. Первое, на что нужно обратить внимание, - это как осуществляется шифрование файлов. К сожалению, как видно из приведенного выше анализа, используемый алгоритм шифрования является безопасным. Это AES со случайным ключом и вектором инициализации, оба созданы безопасным генератором случайных чисел. Используемая реализация также действительна: авторы решили использовать Windows Crypto API.
Шифрование больших файлов
Фобос использует другой алгоритм для шифрования больших файлов (длиной более 0x180000 байт). Описанный выше алгоритм использовался для шифрования файлов типичного размера (в этом случае полный файл был зашифрован с начала до конца). В случае больших файлов основной алгоритм аналогичен, однако для шифрования выбираются только некоторые части содержимого.
Мы можем видеть это на следующем примере. Файл 'test.bin' был заполнен байтами 0xAA. Его оригинальный размер был 0x77F87FF:
После шифрования с помощью Phobos мы видим следующие изменения:
Некоторые фрагменты файла остались незашифрованными. Между ними, с самого начала, стираются некоторые фрагменты. Какой-то случайный блок байтов был добавлен в конец файла после оригинального размера. Можно догадаться, что это зашифрованное содержимое вытертых фрагментов. В самом конце файла мы видим блок данных, типичный для Phobos:
Заглянув внутрь, мы можем увидеть причину такого выравнивания. Только 3 фрагмента из большого файла считываются в буфер. Каждый блок имеет длину 0x40000 байт:
Все считанные фрагменты объединяются в один буфер. После этого содержимого добавляются обычные метаданные (контрольные суммы, исходное имя файла) и полный буфер шифруется:
Таким образом, авторы Фобоса пытались минимизировать время, затрачиваемое на шифрование больших файлов, и в то же время максимизировать нанесенный ущерб.
Как защищен ключ AES?
Следующий элемент, который нам нужно проверить, чтобы проанализировать дешифруемость, - это способ, которым авторы решили сохранить сгенерированный ключ.
В случае Фобоса ключ AES шифруется сразу после создания. Его зашифрованная форма позже добавляется в конец атакованного файла (в вышеупомянутом блоке 128 байтов). Давайте подробнее рассмотрим функцию, отвечающую за шифрование ключа AES.
Функция, генерирующая и защищающая ключ AES, развертывается до запуска каждого потока шифрования. Заглянув внутрь, мы видим, что первые несколько переменных дешифруются так же, как и вышеупомянутые строки.
Одним из расшифрованных элементов является следующий буфер:
Получается, что дешифрованный блок размером 128 байт является открытым ключом RSA злоумышленника. Этот буфер затем проверяется с помощью контрольной суммы. Контрольная сумма ключа RSA сравнивается с жестко закодированной. В случае, если оба совпадения, размер, который будет использоваться для генерации ключа AES, устанавливается равным 32. В противном случае он устанавливается равным 4.
Затем для ключа AES создается буфер случайных байтов.
После генерации ключ AES защищается с помощью жестко закодированного открытого ключа. На этот раз авторы решили использовать не Windows Crypto API, а внешнюю библиотеку. Детальный анализ помог нам определить, что это конкретная реализация алгоритма RSA (особая благодарность Mark Lechtik за помощь).
Расшифрованный ключ RSA длиной 128 байт импортируется с помощью функции RSA_pub_key_new. После этого импортированный ключ RSA используется для шифрования случайного ключа AES:
Подводя итог, кажется, что ключ AES защищен правильно, что является плохой новостью для жертв этого вымогателя.
Атакующие сетевые ресурсы
Фобос имеет отдельную ветку, посвященную атакам на сетевые ресурсы.
Сетевые ресурсы перечисляются в цикле:
Сравнение с Дхармой
Предыдущие источники упоминают Фобос как сильно основанный на вымогательстве Дхармы. Однако это сравнение основывалось главным образом на внешнем виде: очень похожая записка с требованием выкупа и соглашение об именах, используемое для зашифрованных файлов. Реальный ответ на этот вопрос лежит в коде. Давайте посмотрим на оба и сравним их вместе. Это сравнение будет основано на текущем образце Фобоса с образцом Дхармы ( d50f69f0d3a73c0a58d2ad08aedac1c8 ).
Если мы сравним оба с помощью BinDiff, мы увидим некоторые сходства, но также и множество несовпадающих функций.
Фрагмент сравнения кода: Фобос против Дхармы
В отличие от Фобоса, Dharma загружает большую часть своего импорта динамически, что делает код немного более сложным для анализа.
Дхарма загружает большинство своих импортных товаров в начале исполнения.
Адреса импортируемых функций хранятся в дополнительном массиве, и каждый вызов делает дополнительный переход к значению этого массива. Пример:
Напротив, Фобос имеет типичную, необоснованную таблицу импорта
Перед запуском процедуры шифрования Dharma устанавливает мьютекс: «Global \ syncronize_ <hardcoded ID>».
И Фобос, и Дхарма используют одну и ту же реализацию алгоритма RSA из статической библиотеки. Фрагмент кода из Дхармы:
Фрагмент функции «bi_mod_power» от: joyent/syslinux
Шифрование файлов реализовано одинаково в обоих случаях. Однако, в то время как Dharma использует реализацию AES из той же статической библиотеки , Phobos использует AES из Windows Crypto API.
Фрагмент реализации AES от Dharma Ransomware
Глядя на то, как ключ сохраняется в файле, мы также можем увидеть некоторые сходства. Защищенный ключ AES хранится в блоке в конце зашифрованного файла. В начале этого блока мы видим некоторые метаданные, которые похожи на Фобос, например, оригинальное имя файла (на Фобосе эти данные зашифрованы). Затем существует 6-значный идентификатор, выбранный из пула с жестким кодом.
Такой идентификатор встречается и на Фобосе, но там он хранится в самом конце блока. В случае Фобоса этот идентификатор является постоянным для конкретного образца.
Блок в конце файла, зашифрованный Фобосом
Заключение
Фобос - обычный вымогатель, отнюдь не демонстрирующий никакой новизны. Глядя на его внутренности, мы можем сделать вывод, что, хотя это не точная грабежная Дхарма, между ними есть существенные сходства, предполагающие одних и тех же авторов. Перекрытия находятся на концептуальном уровне, а также в той же используемой реализации RSA.
Как и в случае с другими угрозами, важно убедиться, что ваши активы в безопасности, чтобы предотвратить такие компромиссы. В этом конкретном случае предприятия должны проверить все компьютеры, на которых был разрешен доступ к Remote Desktop Procol (RDP), и либо отключить его, если он не нужен, либо убедиться, что учетные данные являются надежными, чтобы предотвратить такие действия.
По мотивам
Phobos является одним из вымогателей, которые распространяются через взломанные RDP. Это неудивительно, поскольку взломанные RDP-серверы являются дешевым товаром на подпольном рынке.
Анализируемый образец
a91491f45b851a07f91ba5a200967921bf796d38677786de51a4a8fe5ddeafd2
Поведенческий анализ
Этот вымогатель не пытается обойти UAC. Хотя это и не нужно учитывая, что используется ручной вход через RDP:
Если мы согласимся, то основной процесс развернет еще одну свою копию с повышенными привилегиями. Он также выполняет некоторые команды через оболочку Windows.
Требования выкупа создаются двух типов: .txt и .hta. После того, как процесс шифрования закончен, выскакивает примечание о выкупе в форме .hta:
Даже после появления уведомления о выкупе вредоносное ПО по-прежнему работает в фоновом режиме и продолжает шифровать вновь созданные файлы.
Все локальные диски, а также сетевые ресурсы подвергаются атакам.
Шифровальщик также использует несколько механизмов автозапуска: устанавливает себя в% APPDATA% и в папку «Автозагрузка», добавляя ключи реестра для автоматического запуска своего процесса при перезапуске системы.
Эти механизмы позволяют оставаться активным вредоносному ПО в системе длительное время.
Процесс шифрования
Программа-вымогатель может зашифровать файлы без подключения к интернету (на данный момент мы можем догадаться, что он поставляется с некоторым жестко закодированным открытым ключом). Каждый файл шифруется отдельным ключом или вектором инициализации: один и тот же открытый текст генерирует другой зашифрованный текст.
Он шифрует различные файлы, в том числе исполняемые файлы. Зашифрованные файлы имеют адрес электронной почты злоумышленника. Конкретный вариант Фобоса также добавляет расширение .acute - однако в разных вариантах встречались разные расширения. Общий шаблон:<original name>.id[<victim ID>-<version ID>][<attacker's e-mail>].<added extention>
Визуализация зашифрованного содержимого не отображает какие-либо узнаваемые шаблоны. Это предполагает использование либо потокового шифра, либо шифра с цепочками блоков (возможно, AES в режиме CBC ). Пример - простой BMP до и после шифрования:
Когда мы заглядываем внутрь зашифрованного файла, в конце мы видим определенный блок. Он отделяется от зашифрованного содержимого заполнением байтов 0. Первые 16 байтов этого блока являются уникальными для каждого файла (возможный вектор инициализации). Затем идет блок из 128 байтов, который одинаков в каждом файле. Возможно, это означает, что этот блок содержит зашифрованный ключ, который генерируется уникальным образом при каждом запуске. В конце мы можем найти ключевое слово длиной 6 символов, которое является типичным для этого вымогателя. В данном случае это «LOCK96», однако были обнаружены разные версии Фобоса с разными ключевыми словами, например «DAT260».
Чтобы полностью понять процесс шифрования, мы рассмотрим код.
внутри
В отличие от большинства вредоносных программ, которые защищены каким-либо криптером, Фобос не упакован и не запутан. Хотя отсутствие упаковки не является распространенным явлением среди общего числа вредоносных программ, оно часто встречается среди вредоносных программ, распространяемых злоумышленниками вручную.
Выполнение начинается в функции WinMain:
Во время выполнения Phobos запускает несколько потоков, отвечающих за его различные действия, такие как: удаление процессов из черного списка, развертывание команд из командной строки, шифрование доступных дисков и сетевых ресурсов.
Используется запутывание
Код вымогателей не упакован и не запутан. Однако некоторые константы, включая строки, защищены AES и расшифрованы по требованию. Определенная строка может быть запрошена по ее индексу, например:
Ключ AES, используемый для этой цели, жестко закодирован (в запутанном виде) и импортируется каждый раз, когда необходимо расшифровать часть данных.
Вектор инициализации установлен в 16 пустых байтов.
Код, ответственный за загрузку ключа AES, приведен ниже. Функция оборачивает ключ в структуру BLOBHEADER , которая затем импортируется.
Из структуры BLOBHEADER мы можем прочитать следующую информацию: 0x8 - PLAINTEXTKEYBLOB, 0x2 = CUR_BLOB_VERSION, 0x6610 - CALG_AES_256.
Пример расшифрованной строки:
Среди расшифрованных строк мы также видим список атакованных расширений.
Мы также можем найти список некоторых ключевых слов:
Это список возможных расширений, используемых этим вымогателем. Они (вероятно) используются для распознавания и пропуска файлов, которые уже были зашифрованы вымогателями из этого семейства. Расширение, которое будет использоваться в текущем цикле шифрования, жестко закодировано.
Одна из зашифрованных строк определяет формулу для расширения файла, которое позже заполняется идентификатором жертвы:
UNICODE ".id[<unique ID>-1096].[lockhelp@qq.com].acute"
Завершаемые процессы
Вымогатель поставляется со списком процессов, которые он убивает, прежде чем шифрование развернуто. Как и другие строки, полный список расшифровывается по требованию:
Эти процессы завершены, так что они не будут блокировать доступ к файлам, которые будут зашифрованы.
Ransomware развертывает несколько команд из командной строки. Эти команды должны предотвращать восстановление зашифрованных файлов из любых резервных копий.
Удаление теневых копий:
vssadmin delete shadows /all /quiet
wmic shadowcopy delete
Изменение параметров Bcdedit (предотвращение загрузки системы в режиме восстановления):
bcdedit /set {default} bootstatuspolicy ignoreallfailures
bcdedit /set {default} recoveryenabled no
Удаляет каталог резервных копий на локальном компьютере:
wbadmin delete catalog -quiet
Это также отключает брандмауэр:
netsh advfirewall set currentprofile state off
netsh firewall set opmode mode=disable
exit
Атакованные цели
Перед тем как Фобос начинает вредоносные действия, он проверяет системную локаль (используя GetLocaleInfoW опции: LOCALE_SYSTEM_DEFAULT , LOCALE_FONTSIGNATURE ). Завершает выполнение в случае, если очищен 9-й бит вывода. 9-й бит представляет кириллические алфавиты, поэтому на системы, которые установили его по умолчанию, это не влияет.
Как локальные диски, так и сетевые ресурсы зашифрованы.
Перед началом шифрования Phobos перечисляет все файлы и сравнивает их имена с жестко закодированными списками. Списки хранятся в двоичном виде в зашифрованном виде AES, строки разделяются разделителем ';'.
Среди этих списков мы можем найти, например, черный список (эти файлы будут пропущены). Эти файлы относятся к операционной системе, а файлы info.txt, info.hta являются именами записок о выкупе Фобоса:
Существует также список каталогов , которые должны быть пропущены - в анализируемом случае он содержит только один каталог: C:\Windows.
Среди пропущенных файлов есть также расширения, которые используются вариантами Phobos, которые были упомянуты ранее.
Существует также довольно длинный белый список расширений:
Как работает шифрование
Phobos использует WindowsCrypto API для шифрования файлов. Существует несколько параллельных потоков для развертывания шифрования на каждом доступном диске или сетевом ресурсе.
Ключ AES создается до запуска потока шифрования и передается в параметре потока.
Фрагмент функции генерации ключа:
Хотя ключ AES является общим для всех файлов, которые зашифрованы в одном раунде, тем не менее, каждый файл зашифрован с различным вектором инициализации. Вектор инициализации имеет длину 16 байт, генерируется непосредственно перед открытием файла и затем передается в функцию шифрования:
Ниже ключ AES и вектор инициализации генерируются с помощью одной и той же функции, которая является оберткой CryptGenRandom(сильный генератор случайных чисел):
AES IV позже добавляется к содержимому зашифрованного файла в виде открытого текста. Мы можем видеть это на следующем примере:
Перед выполнением функции шифрования файла генерируется случайный IV:
Ключ AES, который был передан потоку, импортируется в context ( CryptImportKey), а также устанавливается IV. Мы видим, что содержимое прочитанного файла зашифровано:
После того, как содержимое файла зашифровано, оно сохраняется во вновь созданном файле с расширением вымогателей.
Программа-вымогатель создает блок с метаданными, включая контрольные суммы и исходное имя файла. После этого блока сохраняется случайный IV, и, наконец, блок, содержащий зашифрованный ключ AES. Последний элемент - маркер файла: «LOCK96»:
Перед записью в файл блок метаданных шифруется с использованием того же ключа AES и IV, что и содержимое файла.
установка ключа AES перед шифрованием блока метаданных
Блок зашифрованных метаданных:
Наконец, содержимое добавляется в конец вновь созданного файла:
Будучи исследователем вымогателей, общий вопрос, на который мы хотим ответить, заключается в том, является ли вымогатель дешифруемым, то есть, содержит ли он слабость, позволяющую восстановить файлы без уплаты выкупа. Первое, на что нужно обратить внимание, - это как осуществляется шифрование файлов. К сожалению, как видно из приведенного выше анализа, используемый алгоритм шифрования является безопасным. Это AES со случайным ключом и вектором инициализации, оба созданы безопасным генератором случайных чисел. Используемая реализация также действительна: авторы решили использовать Windows Crypto API.
Шифрование больших файлов
Фобос использует другой алгоритм для шифрования больших файлов (длиной более 0x180000 байт). Описанный выше алгоритм использовался для шифрования файлов типичного размера (в этом случае полный файл был зашифрован с начала до конца). В случае больших файлов основной алгоритм аналогичен, однако для шифрования выбираются только некоторые части содержимого.
Мы можем видеть это на следующем примере. Файл 'test.bin' был заполнен байтами 0xAA. Его оригинальный размер был 0x77F87FF:
После шифрования с помощью Phobos мы видим следующие изменения:
Некоторые фрагменты файла остались незашифрованными. Между ними, с самого начала, стираются некоторые фрагменты. Какой-то случайный блок байтов был добавлен в конец файла после оригинального размера. Можно догадаться, что это зашифрованное содержимое вытертых фрагментов. В самом конце файла мы видим блок данных, типичный для Phobos:
Заглянув внутрь, мы можем увидеть причину такого выравнивания. Только 3 фрагмента из большого файла считываются в буфер. Каждый блок имеет длину 0x40000 байт:
Все считанные фрагменты объединяются в один буфер. После этого содержимого добавляются обычные метаданные (контрольные суммы, исходное имя файла) и полный буфер шифруется:
Таким образом, авторы Фобоса пытались минимизировать время, затрачиваемое на шифрование больших файлов, и в то же время максимизировать нанесенный ущерб.
Как защищен ключ AES?
Следующий элемент, который нам нужно проверить, чтобы проанализировать дешифруемость, - это способ, которым авторы решили сохранить сгенерированный ключ.
В случае Фобоса ключ AES шифруется сразу после создания. Его зашифрованная форма позже добавляется в конец атакованного файла (в вышеупомянутом блоке 128 байтов). Давайте подробнее рассмотрим функцию, отвечающую за шифрование ключа AES.
Функция, генерирующая и защищающая ключ AES, развертывается до запуска каждого потока шифрования. Заглянув внутрь, мы видим, что первые несколько переменных дешифруются так же, как и вышеупомянутые строки.
Одним из расшифрованных элементов является следующий буфер:
Получается, что дешифрованный блок размером 128 байт является открытым ключом RSA злоумышленника. Этот буфер затем проверяется с помощью контрольной суммы. Контрольная сумма ключа RSA сравнивается с жестко закодированной. В случае, если оба совпадения, размер, который будет использоваться для генерации ключа AES, устанавливается равным 32. В противном случае он устанавливается равным 4.
Затем для ключа AES создается буфер случайных байтов.
После генерации ключ AES защищается с помощью жестко закодированного открытого ключа. На этот раз авторы решили использовать не Windows Crypto API, а внешнюю библиотеку. Детальный анализ помог нам определить, что это конкретная реализация алгоритма RSA (особая благодарность Mark Lechtik за помощь).
Расшифрованный ключ RSA длиной 128 байт импортируется с помощью функции RSA_pub_key_new. После этого импортированный ключ RSA используется для шифрования случайного ключа AES:
Подводя итог, кажется, что ключ AES защищен правильно, что является плохой новостью для жертв этого вымогателя.
Атакующие сетевые ресурсы
Фобос имеет отдельную ветку, посвященную атакам на сетевые ресурсы.
Сетевые ресурсы перечисляются в цикле:
Сравнение с Дхармой
Предыдущие источники упоминают Фобос как сильно основанный на вымогательстве Дхармы. Однако это сравнение основывалось главным образом на внешнем виде: очень похожая записка с требованием выкупа и соглашение об именах, используемое для зашифрованных файлов. Реальный ответ на этот вопрос лежит в коде. Давайте посмотрим на оба и сравним их вместе. Это сравнение будет основано на текущем образце Фобоса с образцом Дхармы ( d50f69f0d3a73c0a58d2ad08aedac1c8 ).
Если мы сравним оба с помощью BinDiff, мы увидим некоторые сходства, но также и множество несовпадающих функций.
Фрагмент сравнения кода: Фобос против Дхармы
В отличие от Фобоса, Dharma загружает большую часть своего импорта динамически, что делает код немного более сложным для анализа.
Дхарма загружает большинство своих импортных товаров в начале исполнения.
Адреса импортируемых функций хранятся в дополнительном массиве, и каждый вызов делает дополнительный переход к значению этого массива. Пример:
Напротив, Фобос имеет типичную, необоснованную таблицу импорта
Перед запуском процедуры шифрования Dharma устанавливает мьютекс: «Global \ syncronize_ <hardcoded ID>».
И Фобос, и Дхарма используют одну и ту же реализацию алгоритма RSA из статической библиотеки. Фрагмент кода из Дхармы:
Фрагмент функции «bi_mod_power» от: joyent/syslinux
Шифрование файлов реализовано одинаково в обоих случаях. Однако, в то время как Dharma использует реализацию AES из той же статической библиотеки , Phobos использует AES из Windows Crypto API.
Фрагмент реализации AES от Dharma Ransomware
Глядя на то, как ключ сохраняется в файле, мы также можем увидеть некоторые сходства. Защищенный ключ AES хранится в блоке в конце зашифрованного файла. В начале этого блока мы видим некоторые метаданные, которые похожи на Фобос, например, оригинальное имя файла (на Фобосе эти данные зашифрованы). Затем существует 6-значный идентификатор, выбранный из пула с жестким кодом.
Такой идентификатор встречается и на Фобосе, но там он хранится в самом конце блока. В случае Фобоса этот идентификатор является постоянным для конкретного образца.
Блок в конце файла, зашифрованный Фобосом
Заключение
Фобос - обычный вымогатель, отнюдь не демонстрирующий никакой новизны. Глядя на его внутренности, мы можем сделать вывод, что, хотя это не точная грабежная Дхарма, между ними есть существенные сходства, предполагающие одних и тех же авторов. Перекрытия находятся на концептуальном уровне, а также в той же используемой реализации RSA.
Как и в случае с другими угрозами, важно убедиться, что ваши активы в безопасности, чтобы предотвратить такие компромиссы. В этом конкретном случае предприятия должны проверить все компьютеры, на которых был разрешен доступ к Remote Desktop Procol (RDP), и либо отключить его, если он не нужен, либо убедиться, что учетные данные являются надежными, чтобы предотвратить такие действия.
По мотивам
Последнее редактирование: