Сравниваем код модульных APT-бэкдоров
В июле 2020 года мы выпустили исследование целевых атак на государственные учреждения Казахстана и Киргизии с подробным разбором вредоносных программ, найденных в скомпрометированных сетях. Список тогда получился настолько внушительный, что одни только IoC«и заняли несколько страниц текста. В процессе расследования этих инцидентов среди прочего ВПО мы изучили образцы мультимодульных бэкдоров PlugX, которые использовались для первичного заражения локальных сетей пострадавших организаций. Применение программ этого семейства свидетельствует о возможной причастности к атакам китайских APT-групп.
Главный объект изучения сегодняшней статьи — бэкдор ShadowPad — попал в нашу вирусную лабораторию с одного из зараженных компьютеров локальной сети госучреждения Киргизии. Различные модификации этого семейства являются известным инструментом Winnti — APT-группы предположительно китайского происхождения, активной как минимум с 2012 года. В ходе экспертизы мы также обнаружили несколько модификаций PlugX, установленных на том же компьютере.
Рассмотрим некоторые алгоритмы работы обоих бэкдоров и уделим внимание сходствам в коде, а также некоторым пересечениям в их сетевой инфраструктуре.
Краткая характеристика бэкдора ShadowPad
Для полноты исследования мы нашли и проанализировали другие образцы семейства ShadowPad, чтобы более детально рассмотреть сходство с PlugX. Помимо найденного на зараженной машине BackDoor.ShadowPad.1, мы изучили:
- BackDoor.ShadowPad.3,
- BackDoor.ShadowPad.4 — модификация, находившаяся в составе самораспаковывающегося WinRAR-дроппера и загружавшая нетипичный для этого семейства модуль в виде DLL-библиотеки.
Основная функциональность содержится в модулях, детектируемых Dr.Web как BackDoor.ShadowPad.1 и BackDoor.ShadowPad.3. Обе вредоносные программы являются многокомпонентными бэкдорами, написанными с использованием языков С, С++ и Assembler. Их отличительная черта — наличие дополнительных подключаемых плагинов, характерных также и для бэкдоров семейства PlugX.
BackDoor.ShadowPad.4, в свою очередь, является загрузчиком и представляет собой троянскую DLL, написанную на C и Assembler. Исследованный образец распространялся в составе WinRAR SFX-дроппера, включающего также «белый» EXE-файл, предназначенный для запуска библиотеки, и полезную нагрузку, загружаемую в процессе работы BackDoor.ShadowPad.4.
ShadowPad — модульный бэкдор. Изученные нами модификации загружаются в оперативную память методом DLL Hijacking при помощи специально подготовленного «белого» исполняемого файла. Первые шаги исполнения BackDoor.ShadowPad.1 и BackDoor.ShadowPad.3 в целом идентичны друг другу:
- расшифровка шелл-кода и передача на него управления;
- загрузка шелл-кодом основного модуля «Root», хранящегося в специальном формате;
- загрузка модулем «Root» остальных модулей.
Бэкдор устанавливается в систему либо как служба, либо с помощью ключа автозапуска. Все ключи и параметры для большинства этапов работы хранятся в зашитой в теле конфигурации. После установки бэкдор пытается выполнить инжект модуля «Root» в один из процессов, также указанных в конфигурации.
Сетевая активность предусматривает установку соединения с управляющим сервером и выполнение поступающих от него команд. Для каждого модуля предусмотрен отдельный набор команд. Бэкдор способен получать практически любую системную информацию, работать в качестве файлового менеджера и кейлоггера, управлять службами и процессами, модифицировать реестр, делать снимки экрана и перенаправлять ввод-вывод командной оболочки через пайпы на управляющий сервер.
Подробный разбор алгоритмов работы читайте в нашем исследовании на сайте.
Рассмотрим основные элементы сходства ShadowPad с другим ранее изученным нами модульным бэкдором — PlugX.
ShadowPad.1
В процессе выполнения ShadowPad.1 регистрирует обработчик исключений верхнего уровня. При получении управления обработчик формирует отладочную строку с информацией об исключении.
В бэкдорах семейства PlugX также регистрируются обработчики исключений. В частности, в BackDoor.PlugX.38 формируется строка с информацией об исключении, при этом незначительно отличается формат:
Другой интересной находкой являются константы, обнаруживающиеся в структуре, которая содержит информацию о системе. Эта структура формируется модулем «Online» по команде 0×68003. Значения полей datestamp1 и datestamp2 зашиты и равны 20150810 и 20170330 соответственно. Подобные константы в виде дат использовались также в плагинах бэкдоров PlugX.
Кроме того, мы обнаружили еще одно пересечение в артефактах бэкдора. В исторической WHOIS-записи домена управляющего сервера можно увидеть email регистратора: ddggcc@189[.]cn. Этот же адрес мы нашли в записях доменов icefirebest[.]com и www[.]arestc[.]net, которые содержались в конфигурациях образцов PlugX, установленных на том же компьютере.
ShadowPad.3
Как и ShadowPad.1, эта модификация имеет много общего с образцами вредоносных программ семейства PlugX.
В частности, во время инициализации модуля «Plugins» также регистрируется обработчик исключений верхнего уровня. Как упоминалось выше, в ShadowPad.1 подобный обработчик в целях отладки формировал строку с информацией об исключении. Однако в ShadowPad.3 он лишь завершает поток, который вызвал исключение. В данном случае механизм работы схож с PlugX.28.
BackDoor.ShadowPad.3
BackDoor.PlugX.28
Ключевое отличие в работе функций в данном случае состоит в том, что PlugX оперирует объектом, содержащим связный список всех работающих потоков, в то время как ShadowPad напрямую завершает текущий поток. Однако в целом можно провести аналогию с объектом ShadowPad, который хранит загруженные модули в виде списка.
Следующее пересечение мы обнаружили на этапе исполнения основной полезной нагрузки, которая начинается с работы модуля «Install». Аналогично ShadowPad.1, в начале этого этапа бэкдор получает необходимые привилегии — SeDebugPrivilege и SeTcbPrivilege. Описанный паттерн схож с поведением изученных ранее бэкдоров PlugX. Так, после подготовительных действий бэкдор PlugX.38 также получает указанные привилегии:
BackDoor.ShadowPad.3
BackDoor.PlugX.38
Связь с PlugX также прослеживается на этапе инициализации конфигурации с помощью модуля «Config». Сперва ShadowPad.3 проверяет первые четыре байта буфера, в котором должна храниться зашифрованная конфигурация. Если байты равны 0×58585858 (XXXX в кодировке ASCII), бэкдор инициализирует пустую конфигурацию. PlugX также проверяет байты в начале конфигурации, при этом он проверяет первые 8 байтов на равенство строке 0×58585858.
На иллюстрациях ниже представлено сравнение алгоритмов ShadowPad.3 и PlugX.28.
BackDoor.ShadowPad.3
BackDoor.PlugX.28
Еще одна особенность — наличие в этой модификации ShadowPad модуля «ImpUser». Данный модуль служит для внедрения в процесс, созданный либо с окружением текущей сессии, либо от имени пользователя, подключенного удаленно. В контексте этого процесса в дальнейшем будут обрабатываться команды от управляющего сервера, которые должны быть получены через пайп от другого запущенного экземпляра бэкдора. Таким образом, «ImpUser» реализует функциональность «сервера» для пайп-соединения, а второй экземпляр бэкдора ретранслирует ему команды от управляющего сервера.
Аналогичная функциональность существует и в бэкдорах семейства PlugX. Например, в PlugX.38 за это отвечает именованный поток DoImpUserProc.
BackDoor.ShadowPad.3 (расшифровка имени модуля)
BackDoor.PlugX.38
Аналогично бэкдору PlugX, ShadowPad.3 предусматривает использование мьютексов с именами, зависящими от идентификатора процесса. В обоих случаях они служат для синхронизации перезапущенного процесса вредоносной программы и родительского процесса.
BackDoor.ShadowPad.3
BackDoor.PlugX.38
Следующее сходство заключается в механизме генерации имен. В ShadowPad.3 предусмотрена функция, которая используется для генерации имени файла, хранящего конфигурацию, директории хранения скриншотов экрана и т. д. Результат генерации зависит от переданного функции инициализирующего значения и серийного номера системного тома. Аналогичный подход к генерации уникальных имен использовался в PlugX.28. Подобно ShadowPad, изученные образцы PlugX перед началом диалога с сервером также генерируют идентификатор компьютера и сохраняют его в реестре. Для генерации используется некоторое инициализирующее значение.
В ShadowPad.3 сразу после создания идентификатора компьютера запускается сканирование сети и взаимодействие с управляющим сервером. Сканирование необходимо для поиска других зараженных систем в локальной сети. В рассматриваемой модификации бэкдора для этого запускаются 4 отдельных потока, каждый из которых отвечает за определенный тип сканирования, открытие заданных портов, ретрансляцию пакетов и т. д. ShadowPad.3 может работать в режиме сервера в локальной сети. Для этого бэкдор открывает порт из конфигурации и ожидает входящего соединения от клиентов. При получении нового соединения запускается туннель между локальным клиентом и реальным управляющим сервером.
Функциональность работы бэкдора в режиме сервера в локальной сети присутствует и в образцах семейства PlugX. В частности, в PlugX.38 для этого используются именованные потоки JoProc:
- JoProcListen (туннель между локальным клиентом и управляющим сервером);
- JoProcBroadcast (рассылка по сети);
- JoProcBroadcastRecv (обработка ответов на рассылку).
Напоследок отметим, что ShadowPad и PlugX используют идентичные алгоритмы шифрования:
BackDoor.ShadowPad
BackDoor.PlugX
Заключение
Подробное исследование образцов ShadowPad и их сравнение с ранее изученными нами модификациями PlugX указывает на высокую схожесть принципов действия и модульных структур бэкдоров обоих семейств. Эти вредоносные программы сближает не только общая концепция, но и нюансы кода: некоторые приемы разработки, идеи и технические решения практически копируют друг друга. Немаловажным фактом является и то, что оба бэкдора находились в скомпрометированной сети государственного учреждения Киргизии.
Имеющиеся данные позволяют нам сделать вывод о связи этих семейств, при этом возможны как простое заимствование кода, так и разработка обеих программ одним автором или группой авторов. Во втором случае весьма вероятной видится эволюция PlugX в более новый и совершенный ShadowPad, так как формат хранения вредоносных модулей, применяемый в последнем, многократно затрудняет возможность их обнаружения в оперативной памяти.
