Как создатели вредоносного софта пытаются избежать его обнаружения: разбираем на примере 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». Данный выбор уже предопределен на этапе создания вредоносной программы. То есть последовательность нагрузок задана заранее в виде двухзначных суффиксов.
Выбор ссылки с суффиксом «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-атаки не оставляют сомнений о намерениях злоумышленников.
Имена классов модуля для проведения 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