Анализ шифровальщика Phobos

akok

Команда форума
Администратор
Сообщения
17,981
Реакции
13,570
Баллы
2,203
Вымогатель 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.

Пример расшифрованной строки:


Среди расшифрованных строк мы также видим список атакованных расширений.


Мы также можем найти список некоторых ключевых слов:

acute actin Acton actor Acuff Acuna acute adage Adair Adame banhu banjo Banks Banta Barak Caleb Cales Caley calix Calle Calum Calvo deuce Dever devil Devoe Devon Devos dewar eight eject eking Elbie elbow elder phobos help blend bqux com mamba KARLOS DDoS phoenix PLUT karma bbc CAPITAL
Это список возможных расширений, используемых этим вымогателем. Они (вероятно) используются для распознавания и пропуска файлов, которые уже были зашифрованы вымогателями из этого семейства. Расширение, которое будет использоваться в текущем цикле шифрования, жестко закодировано.

Одна из зашифрованных строк определяет формулу для расширения файла, которое позже заполняется идентификатором жертвы:

UNICODE ".id[<unique ID>-1096].[lockhelp@qq.com].acute"

Завершаемые процессы
Вымогатель поставляется со списком процессов, которые он убивает, прежде чем шифрование развернуто. Как и другие строки, полный список расшифровывается по требованию:

msftesql.exe sqlagent.exe sqlbrowser.exe sqlservr.exe sqlwriter.exe
oracle.exe ocssd.exe dbsnmp.exe synctime.exe agntsvc.exe
mydesktopqos.exe isqlplussvc.exe xfssvccon.exe mydesktopservice.exe
ocautoupds.exe agntsvc.exe agntsvc.exe exe agntsvc.exe encsvc.exe
firefoxconfig.exe tbirdconfig.exe ocomm.exe mysqld.exe mysqld-nt.exe
mysqld-opt.exe dbeng50.exe sqbcoreservice.exe excel.exe infopath.exe
msaccess.exe mspub.exe onenote.exe outlook.exe powerpnt.exe steam.exe
thebat.exe thebat64.exe thunderbird.exe visio.exe winword.exe
wordpad.exe
Эти процессы завершены, так что они не будут блокировать доступ к файлам, которые будут зашифрованы.


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 являются именами записок о выкупе Фобоса:

info.hta
info.txt
boot.ini
bootfont.bin
ntldr
ntdetect.com
io.sys
Существует также список каталогов , которые должны быть пропущены - в анализируемом случае он содержит только один каталог: C:\Windows.

Среди пропущенных файлов есть также расширения, которые используются вариантами Phobos, которые были упомянуты ранее.

Существует также довольно длинный белый список расширений:

1cd 3ds 3fr 3g2 3gp 7z accda accdb accdc accde accdt accdw adb adp ai ai3 ai4 ai5 ai6 ai7 ai8 anim arw as asa asc ascx asm asmx asp aspx asr asx avi avs backup bak bay bd bin bmp bz2 c cdr cer cf cfc cfm cfml cfu chm cin class clx config cpp cr2 crt crw cs css csv cub dae dat db dbf dbx dc3 dcm dcr der dib dic dif divx djvu dng doc docm docx dot dotm dotx dpx dqy dsn dt dtd dwg dwt dx dxf edml efd elf emf emz epf eps epsf epsp erf exr f4v fido flm flv frm fxg geo gif grs gz h hdr hpp hta htc htm html icb ics iff inc indd ini iqy j2c j2k java jp2 jpc jpe jpeg jpf jpg jpx js jsf json jsp kdc kmz kwm lasso lbi lgf lgp log m1v m4a m4v max md mda mdb mde mdf mdw mef mft mfw mht mhtml mka mkidx mkv mos mov mp3 mp4 mpeg mpg mpv mrw msg mxl myd myi nef nrw obj odb odc odm odp ods oft one onepkg onetoc2 opt oqy orf p12 p7b p7c pam pbm pct pcx pdd pdf pdp pef pem pff pfm pfx pgm php php3 php4 php5 phtml pict pl pls pm png pnm pot potm potx ppa ppam ppm pps ppsm ppt pptm pptx prn ps psb psd pst ptx pub pwm pxr py qt r3d raf rar raw rdf rgbe rle rqy rss rtf rw2 rwl safe sct sdpx shtm shtml slk sln sql sr2 srf srw ssi st stm svg svgz swf tab tar tbb tbi tbk tdi tga thmx tif tiff tld torrent tpl txt u3d udl uxdc vb vbs vcs vda vdr vdw vdx vrp vsd vss vst vsw vsx vtm vtml vtx wb2 wav wbm wbmp wim wmf wml wmv wpd wps x3f xl xla xlam xlk xlm xls xlsb xlsm xlsx xlt xltm xltx xlw xml xps xsd xsf xsl xslt xsn xtp xtp2 xyze xz zip
Как работает шифрование
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), и либо отключить его, если он не нужен, либо убедиться, что учетные данные являются надежными, чтобы предотвратить такие действия.


По мотивам
 
Сверху Снизу