Как создатели вредоносного софта пытаются избежать его обнаружения: разбираем на примере Spy.GmFUToMitm

Специалисты экспертного центра безопасности Positive Technologies (PT Expert Security Center) обнаружили интересный образец вредоносного ПО, распространяющийся в китайском сегменте интернета. Этот софт используется, среди прочего, для осуществления MITM-атак, а главная его особенность заключается в сочетании различных техник ухода от детектирования. Мы решили разобрать их, чтобы показать, как разработчики вредоносного софта скрывают его активность.

С чего все началось

Система анализа сетевого трафика обратила наше внимание на то, что вредоносное приложение регулярно запрашивает изображение с включенным в него дополнительным контентом. Загрузка происходила с легитимного ресурса для хранения изображений — imgsa.baidu.com. К тому же, как выяснилось, это была картинка с зашкаливающим уровнем милоты :) И как же кощунственно после этого выглядела попытка злоумышленников использовать его для сокрытия различных вредоносных нагрузок!

*Изображение, используемое для сокрытия факта доставки полезной нагрузки*

Для начала, чтобы собрать исходные данные и сравнить образцы, мы организовали поиск похожих семплов — и обнаружили несколько. Это стало возможным благодаря характерным данным в сетевом взаимодействии и наличию у нас обширной базы вредоносного трафика. В частности, в сетевом трафике можно видеть явный паттерн, закономерность, заключающуюся в повторении одних и тех же действий со стороны вредоносного приложения.

*Сетевой трафик с отмеченными паттернами*

Мы изучили первый запрос, в ответ на него сервер возвращал зашифрованную конфигурацию, содержащую адреса изображений, в которых содержалась полезная нагрузка. Эти данные хранятся по адресу hxxp://63634[.]top:8081/koded

Расшифровка данных

Расшифровываются полученные данные алгоритмом DES в режиме электронной кодовой книги ключом 0x6a 0x5f 0x6b 0x2a 0x61 0x2d 0x76 0x62, содержащимся в теле вредоносной программы. После расшифрования открытый текст представляет собой строки, каждая из которых содержит ссылку на изображение. Исходя из равенства MD5-хешей, это одно и то же изображение. Видимо, для устойчивости схемы доставки злоумышленники расположили одни и те же данные по разным адресам.

*Пример расшифрованной конфигурации загрузчика*

Используя полученные данные, вредоносный загрузчик следующим этапом инициирует скачивание изображения. Отсекает от него первые 5120 байт (утенка и щенка) и использует только полезную нагрузку, которая следует сразу начиная с 5121-го байта.

После расшифрования данных мы получили очередную конфигурацию формата, аналогичного тому, что был получен на первом шаге. То есть еще одну порцию ссылок на изображения, но на этот раз все MD5-хеши разные и в конце каждой строки есть суффиксы из двух символов:

*Второй набор ссылок и подозрительные суффиксы*

Алгоритм работы вредоноса

Теперь это уже настоящие модули полезной нагрузки. Как выяснилось, два символа в конце каждой строки используются для выбора конкретного изображения, то есть конкретной полезной нагрузки. Сперва используется строка с суффиксом «AD». Данный выбор уже предопределен на этапе создания вредоносной программы. То есть последовательность нагрузок задана заранее в виде двухзначных суффиксов.

Скачанное изображение уже содержит вредоносный модуль, это можно сказать хотя бы исходя из его размера. Данные все так же замаскированы под изображения и располагаются по такому же смещению в 5120 байт. Отбросив лишние байты, загрузчик извлекает, проверяет хеш-сумму и затем расшифровывает в PE-файл модуль под названием TkRep.dll.

*Пример зашифрованного модуля в теле изображения и его хеш-сумма*

Данная библиотека подгружается во вредоносный процесс и первым делом проверяет среду, в которой запущен модуль:

Проверяет среди запущенных процессов наличие процессов с именами devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, PCHunter64.exe — а также наличие антивирусных средств.

Делает стандартную проверку на отладку.

*Проверка запуска процесса в контексте отладчика*

Проверяет наличие среди открытых пайпов тех, что указаны в таблице.

\\.\FltMouseKb	\\.\GameGuard	\\.\GxWfpFlt
\\.\XxGamesFilter	\\.\GpeNetSafe	\\.\TeSafe
\\.\Sdriver	\\.\PowerChange	\\.\xspeed
\\.\gmMemProt	\\.\diafahbb

Следующим шагом регистрирует инфицированный узел на сервере злоумышленников, отправляя POST-запросом протокола HTTP информацию о зараженном узле в зашифрованном виде.

*Запрос для регистрации на сервере злоумышленников*

Примечательно то, что ответ от сервера всегда содержит одни и те же данные, и более того, клиентом учитывается только код ответа сервера.

Как вредоносный софт скрывает свою активность

В соответствии с заданной последовательностью полезных нагрузок переходим к изучению следующей. Ее суффикс — «AR». Клиент, в соответствии с существующей схемой, скачивает с сервиса хранения изображений Baidu Images очередную конкатенацию изображения с зашифрованной нагрузкой, расшифровывает модуль и запускает его в новом процессе со случайным именем. На наш взгляд, данная функциональность служит для придания вредоносному приложению вида безвредного. Часто это клиент онлайн-игры. И это была очередная техника маскировки.

После проведения этого отвлекающего маневра вредоносный процесс переходит к стадии закрепления на инфицированном узле. Для этого он использует функциональность, схожую с функциональностью rootkit-программ. В частности, внедрение собственного защищенного драйвера в систему.

И вот как это происходит. Из расшифрованной конфигурации выбирается нагрузка с суффиксом «AE». Это библиотека TaskReportDLL.dll. У нее те же функции, как у библиотеки TkRep.dll из предыдущего этапа, — отправить информацию о системе и проверить наличие защитных средств.

Затем скачивается библиотека RealWorkDll.dll. Среди функций RealWorkDll.dll важным является скачивание драйвера, частично защищенного с помощью VMPROTECT, и PE-файла, который этот драйвер установит в системе.

Затем удаляются PE-файлы, используемые для установки драйвера, и на этом данный этап закрепления завершен.

Поиск по строке базы данных драйвера привел нас в репозиторий зеркала ресурса rootkit[.]com, в котором был обнаружен экземпляр руткита FUTo с соответствующим именем в пути — «objfre_wxp_x86». В блоге нашей компании данный руткит рассматривался еще в 2006 году.

Рассмотрим подробнее работу в системе драйвера SDriverBlogx86, установленного модулем RealWorkDll.dll. На первом этапе в сеть уходят регистрационные данные клиента. В качестве запроса применяется POST, но теперь уже на порт с номером 8081 (рис. 15). Видимо, этот порт используется для приема данных, если активность на инфицированной системе достигла этапа активизации руткита «FUTo».

*Запрос на С2 от установленного в системе драйвера*

Обращение на сервер злоумышленников происходит в зашифрованном виде, данные до шифрования представляют собой информацию о системе. Разделители полей данных, формат представления и количество полей совпадают у всех модулей.

*Информация о системе для идентификации зараженного узла*

Далее механизм работы внедренного в систему драйвера совпадает с инициирующим загрузчиком — с той лишь разницей, что ссылки на изображения на этот раз запрашивались с порта для руткита и путь хранения конфигурации изменился с /koded на /qqwe. Возможно, это как-то связанно с сервисами qq.com и wechat.com.

Список модулей, который получает процесс, содержит список PE-файлов. Но в данном случае вместо двухбуквенного суффикса для выбора нагрузки в конце строки содержится ключ в виде имени файла:

*Конфигурация, получаемая закрепленным в системе драйвером*

После загрузки изображений полезная нагрузка также расположена по смещению 5120 байт. Структура полезной нагрузки для установленного драйвера включает в себя ключ из предыдущего списка в виде имени файла, а затем сам PE-файл. В отличие от предыдущих этапов здесь полезная нагрузка не зашифрована.

*Полезная нагрузка, получаемая установленным в системе руткитом*

Среди всех полезных нагрузок, полученных на данном этапе, стоит отметить модуль для проведения MITM-атаки. Его хеш-сумма равна b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a.

Полученный модуль проверяет наличие процессов с именами devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, PCHunter64.exe, а также процессы ZhuDongFangYu, 360Safe, 360Tray.

В процессе работы с помощью GET-запроса скачиваются сертификаты server.crt, server.key, server.der, startcom.crt.

Имена классов модуля для проведения MITM-атаки не оставляют сомнений о намерениях злоумышленников.

Заключение

Данное вредоносное ПО состоит из загрузчика, файла маскировки, руткит-драйвера и модуля для проведения атаки «человек посередине». Для скрытой доставки полезной нагрузки ПО применяет технику сращивания данных с изображениями формата JPEG. Для командных серверов злоумышленники регистрируют имена в доменных зонах top, bid, а также на базе облачных платформ.

Вот какие методы маскировки активности использовали разработчики вредоносного софта:

маскировка под легальное приложение,
маскировка в трафике под изображения,
закрепление как руткит.

Рассмотренная угроза детектируется системой анализа сетевого трафика PT Network Attack Discovery как Spy.GmFUToMitm.

IOCs

1953db709a96bc70d86f7dfd04527d3d0cb7c94da276ddf8f0ef6c51630a2915
1ab1b2fe3ce0fd37a0bb0814a2cac7e974f20963800f43d2f5478fc88c83a3da
1c8dbaf0a5045e2b4a6787635ded8f51d8e89a18e398c0dd79b1b82a968df1a0
9b7082ac4165b25a3b22f2aafdd41ea5f3512a76693f6a6b3101873a9cded961
9cee3f6d6e39adfa0d4712541c070b9c2423275698be0c6cd6cd8239d8793250
b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a
df3e7b04d988cf5634ec886321cb1ac364a46181e7a63f41f0788753e52dcf34
eb67c1d69eb09e195b8333e12c41a0749e7e186c9439f1e2c30f369712ce2c12
63634[.]top
anli[.]bid
shangdai[.]bid
b-blog.oss-cn-beijing.aliyuncs[.]com

Авторы: Дмитрий Макаров, Евгений Устинов, Positive Technologies

Как создатели вредоносного софта пытаются избежать его обнаружения: разбираем на примере Spy.GmFUToMitm