Space Pirates: исследуем инструменты и связи новой хакерской группировки

1. Введение
2. Общие сведения
3. Анализ ВПО и инструментов
   1. MyKLoadClient
      1. Схема 1
      2. Схема 2
      3. Тестовый образец
      4. Полезная нагрузка
   2. Zupdax
      1. Полезная нагрузка
      2. Связь с Redsip
      3. Связи с Winnti и FF-RAT
      4. Связи с Bronze Union и TA428
   3. Загрузчики
      1. Downloader.Climax.A
      2. Downloader.Climax.B
   4. RtlShare
      1. Дроппер rtlstat.dll
      2. Инжектор rtlmake.dll
      3. Полезная нагрузка rtlmain.dll (rtlmainx64.dll)
      4. Использование RtlShare
   5. PlugX
      1. Demo dropper
   6. BH_A006
      1. Стадия 0. Загрузка DLL из оверлея
      2. Стадия 1. DLL-дроппер
      3. Стадия 2. Загрузчик .dat (SbieDll.dll / SbieMsg.dll)
      4. Стадия 3. Шеллкод .dat и DLL
      5. Стадия 4. MemLoadLibrary
      6. Стадия 5. Полезная нагрузка
      7. Связь с 9002 RAT
   7. Deed RAT
4. Заключение
5. Приложения
   1. MITRE
   2. IOCs
      1. Файловые индикаторы
      2. Сетевые индикаторы

Введение

В конце 2019 года специалисты экспертного центра безопасности Positive Technologies (PT Expert Security Center, PT ESC) обнаружили фишинговое письмо, нацеленное на одно из предприятий авиационно-космической отрасли России. Оно содержало ссылку на ранее неизвестное вредоносное ПО. Такое же ВПО наши эксперты обнаружили в 2020 году при расследовании инцидента ИБ в одной из российских государственных организаций. В ходе этих работ было также обнаружено несколько новых вредоносных семейств, использующих общую сетевую инфраструктуру, при этом часть из них ранее не упоминалась в открытых источниках.

Летом 2021 года PT Expert Security Center выявил следы компрометации другого предприятия. Организация была проинформирована. В результате расследования мы обнаружили на ее компьютерах соединения с той же самой сетевой инфраструктурой. Дальнейшее исследование позволило определить еще как минимум две организации в России, атакованные с использованием этого же ВПО и сетевой инфраструктуры, обе — с государственным участием.

Выявленную вредоносную активность не удалось однозначно связать с какой-либо из известных хакерских групп, поэтому мы дали атакующим новое имя — Space Pirates. Поводом для названия послужила строка P1Rat, использованная злоумышленниками в PDB-путях, и нацеленность некоторых атак на авиационно-космическую отрасль. В этом отчете описывается обнаруженная активность группировки, особенности используемого ею ВПО, а также ее связи с другими APT-группами.

Общие сведения

Мы предполагаем, что Space Pirates имеет азиатские корни: на это указывает активное использование китайского языка в ресурсах, SFX-архивах и путях к PDB-файлам. Кроме того, в арсенал группы входят распространенные в среде хакеров азиатского происхождения билдер Royal Road RTF (или 8.t) и бэкдор PcShare, а почти все пересечения с уже известной активностью связаны с APT-группировками азиатского региона.

Свою активность группа начала не позднее 2017 года. Основными целями злоумышленников являются шпионаж и кража конфиденциальной информации. Среди жертв, которых удалось выявить в ходе исследования угроз, — государственные учреждения и ИТ-департаменты, предприятия авиационно-космической и электроэнергетической отраслей в России, Грузии и Монголии. При этом в России атакованы по крайней мере пять организаций, в Грузии — одна, а точное число жертв в Монголии неизвестно.

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

По меньшей мере две атаки на российские организации можно считать успешными. В первом случае злоумышленники получили доступ как минимум к 20 серверам в корпоративной сети, где присутствовали около 10 месяцев. За это время было похищено более 1500 внутренних документов, а также информация обо всех учетных записях сотрудников в одном из сетевых доменов. Во втором случае атакующим удалось закрепиться в сети компании более чем на год, получить сведения о входящих в сеть компьютерах и установить свое ВПО по крайней мере на 12 корпоративных узлов в трех различных регионах.

В инструментарий Space Pirates входят уникальные загрузчики и несколько бэкдоров, ранее нам не встречавшихся, и, предположительно, специфичных для группы: MyKLoadClient, BH_A006, Deed RAT. Злоумышленники также имеют доступ к бэкдору Zupdax: его современные варианты используют аналогичную MyKLoadClient схему исполнения, однако код самого бэкдора берет начало в 2010 году и не может быть однозначно привязан к группе.

Кроме того, атакующие используют и хорошо известное ВПО: PlugX, ShadowPad, Poison Ivy, модифицированный вариант PcShare и публичный шелл ReVBShell. Для туннелирования трафика применяется утилита dog-tunnel.

Основная сетевая инфраструктура группы задействует небольшое количество IP-адресов, на которые указывают DDNS-домены. Интересно, что злоумышленники при этом используют домены не только третьего уровня, но также четвертого и последующих, например w.asd3.as.amazon-corp.wikaba.com.

В процессе исследования деятельности Space Pirates мы обнаружили большое число пересечений с ранее выявленной активностью, которую исследователи связывают с группами Winnti (APT41), Bronze Union (APT27), TA428, RedFoxtrot, Mustang Panda и Night Dragon. Причиной этого, вероятно, является обмен инструментарием между группировками — частое явление для APT-групп азиатского региона.

Отдельно стоит отметить связь групп Space Pirates и TA428. В рамках одного из расследований мы наблюдали на зараженных компьютерах активность обеих группировок, которая, однако, не имела пересечений в сетевой инфраструктуре. В то же время в ходе операции StealthyTrident, описанной ESET, атакующие использовали Tmanger, приписываемый TA428, и Zupdax, связанный со Space Pirates. Связь другого ВПО TA428, в частности Albaniiutas (RemShell), и Zupdax можно проследить и в сетевой инфраструктуре, смежной с упомянутой в отчете ESET. Все это позволяет предполагать, что Space Pirates и TA428 могут объединять свои усилия и делиться инструментами, сетевыми ресурсами и доступом к зараженным системам.

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

Анализ ВПО и инструментов

MyKLoadClient

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

Среди обнаруженных нами экземпляров ВПО с MyKLoadClient можно выделить две типичные схемы исполнения. Первая (далее также — схема 1) опирается на использование SFX-архивов в качестве дропперов, применяет технику DLL Side-Loading и использует вспомогательную библиотеку-лончер AntiVirusLoader.dll. Вторая (далее — схема 2) включает в себя только самописный дроппер, который передает управление полезной нагрузке напрямую. При этом во втором случае закрепление в системе в коде не предусмотрено.

Стоит отметить, что, по известным нам данным, прослеживается явная взаимосвязь между целями злоумышленников и выбором схемы исполнения: экземпляры с использованием схемы 1 были нацелены на российские организации, тогда как схема 2 использовалась в атаках на китайские компании. Если опираться на даты модификации и компиляции файлов (которые, однако, могли быть подменены), такое же разделение можно проследить и по времени: схема 1, предположительно, использовалась в 2018–2019 годах, а схема 2 — в 2020 году. Возможно, злоумышленники обновили цепочку исполнения примененного ранее ВПО, чтобы уменьшить вероятность его обнаружения в новых атаках.

Схема 1

Характерным примером экземпляра с первой схемой исполнения является файл с именем Петербургский международный экономический форум (ПМЭФ)____2019.exe (d3a50abae9ab782b293d7e06c7cd518bbcec16df867f2bdcc106dec1e75dc80b). Файл представляет собой SFX-архив, который извлекает документ-приманку 0417.doc и еще один SFX-архив с именем apple.exe. Файлы в архиве модифицированы в апреле 2019 года. Документ содержит текст с описанием ПМЭФ, соответствующим действительности.

Второй SFX-архив извлекает из себя три PE-файла: легитимный siteadv.exe, лончер siteadv.dll и библиотеку с полезной нагрузкой cc.tmp. Отметим, что в изученных нами экземплярах с первой схемой исполнения не всегда есть приманка. Однако во всех случаях применяется подобный SFX-архив, содержащий файлы с теми же именами и назначением.

Исполняемый EXE-файл подписан McAfee, Inc. и является компонентом установщика McAfee SiteAdvisor. При запуске он загружает библиотеку siteadv.dll, которая отвечает за установку и запуск полезной нагрузки. В ресурсах лончера присутствует конфигурация, зашифрованная RC4 с ключом TDILocker и содержащая необходимые пути, имена ключей реестра и флаги.

Лончер предусматривает несколько возможных команд, которые передаются через аргументы командной строки и отвечают за одну из стадий исполнения:

Помимо основной экспортируемой функции main, которая вызывается легитимным siteadv.exe, в siteadv.dll присутствует неиспользуемый экспорт buc_uninstallinterface, отвечающий за обход UAC с использованием компонента IARPUninstallStringLauncher.

Библиотека лончера имеет экспортируемое имя AntiVirusLoader.dll. В некоторых ее экземплярах можно встретить PDB-путь:
D:\Leee\515远程文件\P1Rat_2017_07_28A\src\MyLoader_bypassKIS\snake\res\SiteAdv.pdb.

Полезная нагрузка cc.tmp — это бэкдор, реализованный в виде динамической библиотеки с внутренним именем client.dll. Она экспортирует функцию MyKLoad, которая является фактической точкой входа. Функциональность бэкдора мы рассмотрим ниже.

Схема 2

В качестве дроппера во второй схеме выступает исполняемый файл, отвечающий за извлечение приманки и полезной нагрузки. Бинарные данные расположены в теле дроппера и зашифрованы XOR с однобайтовым ключом. Помимо стандартного запуска извлеченной нагрузки через вызов CreateProcess, дроппер также выполняет рефлективную загрузку и исполнение EXE-файла непосредственно в текущем процессе.

В некоторых случаях функции дроппера дополнительно обфусцированы с применением техники Control Flow Flattening.

В качестве приманки в изученных нами образцах используется PDF-документ, содержащий сообщение о «поврежденном файле» на китайском языке, либо приложение-заглушка, которое выводит сообщения 正在更新浏览器插件，请稍后… (Подключаемый модуль браузера обновляется, подождите …) и 更新完毕，请重启浏览器！ (Обновление завершено, перезапустите браузер!).

Полезная нагрузка в данном случае представляет собой исполняемый файл, в котором указано внутреннее имя client.exe. В некоторых образцах также присутствует PDB-путь C:\Users\classone\Desktop\src\client\exe_debug\client.pdb.

Тестовый образец

Нам также удалось обнаружить тестовый вариант ВПО, созданный не позднее 2018 года: b1d6ba4d995061a0011cb03cd821aaa79f0a45ba2647885171d473ca1a38c098. Это приложение-дроппер.

Интересно, что оно создано, по-видимому, на основе проекта игры «Змейка». На это указывает несколько деталей:

• в начале своей работы приложение создает окно, используя в качестве его имени строку Snake;
• присутствует код, предположительно, отвечающий за логику игры — в частности за генерацию случайных координат очередного куска пищи на поле 50×50 и сравнение их с позицией змейки;
• приложение обрабатывает нажатия клавиши «Пробел» и клавиш управления курсором;
• в ресурсах приложения есть меню с пунктами на китайском языке: «Старт», «Пауза», «Перезагрузка» и «Выход».

Помимо этого, среди ресурсов дроппера также присутствует окно «О программе» (на китайском языке), из содержания которого следует, что это вторая версия игры Snake, созданная в 2016 году. Здесь же указан электронный адрес вероятного автора — mexbochen@foxmail.com.

Поиск адреса в Google позволяет найти персональную страницу владельца электронной почты — программиста из Китая, который специализируется на задачах по обработке изображений.

Несмотря на наличие связи между приложением и владельцем эл. почты, нельзя однозначно утверждать, что именно он является автором ВПО. Возможно, в некоторый момент времени проект игры «Змейка» находился в открытом доступе, и злоумышленники использовали его как основу для реализации дроппера.

Файлы, извлекаемые дроппером, содержатся в его ресурсах в открытом виде. Помимо этого, ресурсы содержат зашифрованную конфигурацию, в которой записаны имена файлов — точно такая же конфигурация используется и в лончере. В момент записи файлов на диск их содержимое шифруется XOR с ключом 0x80, а затем файлы открываются повторно и расшифровываются. Дроппер содержит тот же набор компонентов, что и SFX-архивы (схема 1): легитимный компонент McAfee SiteAdvisor, DLL-лончер и библиотеку с полезной нагрузкой под именем Client.obj.

После извлечения дроппер формирует командную строку для запуска лончера с командой install (закрепление в реестре и запуск полезной нагрузки), но в дальнейшем не использует ее. Вероятно, это ошибка: в коде присутствует отладочное сообщение «CreateProcess success!», но функция CreateProcess не вызывается.

Лончер тестового образца отличается наличием реализации команды mrun: это вариация команды run, отвечающей за запуск экспортируемой из DLL функции с полезной нагрузкой. В отличие от run, mrun предварительно расшифровывает библиотеку по алгоритму RC4 с ключом GoogleMailData, а для ее исполнения использует рефлективную загрузку.

Полезная нагрузка Client.obj аналогична cc.tmp (схема 1) и имеет лишь несущественные отличия. В частности, экспортируемая библиотекой функция точки входа называется main, а в начале своей работы она отображает MessageBox с текстом «just a demo for test!!!». Кроме того, конфигурация бэкдора не шифруется и содержит тестовый C2 127.0.0.1.

Полезная нагрузка

Варианты реализации бэкдора в виде исполняемого файла client.exe и библиотеки client.dll имеют одинаковую функциональность. Однако в них по-разному инициализируется структура с параметрами конфигурации, которая содержит адрес и порт C2, флаг активности бэкдора, а также строковые идентификаторы ВПО, отправляемые на C2.

В библиотеке client.dll, так же как и в лончере (схема 1), в ресурсах полезной нагрузки есть конфигурация, зашифрованная RC4-ключом GoogleMailData. В EXE-варианте структура заполняется фиксированными в коде значениями.

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

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

struct PacketHeader{
    _DWORD Version; // 0x20170510
    _DWORD CommandId;
    _DWORD PayloadSize;
    _DWORD LastError;
};

В качестве версии всегда используется константа 0x20170510, вероятно, обозначающая некоторую дату.

ВПО имеет несколько классов-модулей, отвечающих за соответствующую функциональность:

• ShellManager — удаленная командная строка;
• DiskManager — работа с дисками, установленными в зараженном компьютере;
• FileTransferManager — передача файлов;
• RS5Manager — использование зараженного компьютера в качестве прокси-сервера.

В ID каждой команды есть идентификатор модуля, который получается применением маски 0xFF000. Полный список поддерживаемых команд:

В процессе сбора информации о системе бэкдор создает уникальный идентификатор компьютера (GUID) и записывает его в реестр в один из кустов HKLM или HKCU по ключу Software\CLASSES\KmpiPlayer. Если ключ уже есть в реестре, то используется существующий ID.

Zupdax

Первое публичное упоминание данного ВПО можно встретить в отчете Unit 42, посвященном вредоносному приложению HenBox для платформы Android. В сетевой инфраструктуре HenBox исследователи обнаружили следы использования атакующими ВПО из семейств PlugX, Zupdax, 9002 RAT и Poison Ivy. В 2019 году специалисты Unit 42 объединили наблюдаемую три года активность, связанную с упомянутым набором ВПО, назвав стоящую за ней группу (или группы) именем PKPLUG.

В 2020 году компания ESET обнаружила следы атаки на цепочку поставок ПО Able Soft LLC. Одним из вариантов атаки была компрометация инсталлятора Able Desktop, заключающаяся в добавлении к нему вредоносного кода. В качестве полезной нагрузки, которая была встроена в инсталляторы, исследователи называют бэкдоры HyperBro и Korplug (PlugX).

По имеющимся у нас данным можно утверждать, что полезная нагрузка, обозначенная ESET как Korplug, в действительности является бэкдором Zupdax. Такого же мнения придерживаются аналитики NortonLifeLock и Avira, выпустившие осенью 2021 года отчет, в котором описали основные особенности Zupdax.

Zupdax существует по крайней мере с 2014 года. В своем исследовании мы фокусировались на образцах, относящихся к периоду 2017–2019 годов, однако некоторые детали можно проследить только в более ранних версиях (периода 2014–2015 годов). Далее мы будем говорить о них, используя термин «старые».

В последних версиях Zupdax используется та же схема загрузки, что и в тестовом образце MyKLoadClient. Хотя кода игры «Змейка» в них нет, основная функциональность дроппера реализована аналогичным образом: в своих ресурсах он содержит легитимный siteadv.exe, библиотеку-лончер, полезную нагрузку и зашифрованную XOR конфигурацию с именами файлов и флагами. Точно такую же конфигурацию использует лончер.

В отличие от MyKLoadClient, практически во всех экземплярах с Zupdax полезная нагрузка (которая извлекается под именем ok.obj) шифруется и запускается методом mrun. Среди экземпляров лончера, которые используются в связке с Zupdax, можно встретить более функциональные варианты, поддерживающие обход UAC (в частности, с использованием экспорта buc_uninstallinterface) и закрепление в качестве сервиса.

В экземплярах дроппера и лончера можно встретить соответствующие PDB-пути:
d:\Leee\515远程文件\P1Rat_2017_07_28A\src\MyLoaderBypassNorton\Release\loaderexe.pdb и
d:\Leee\515远程文件\P1Rat_2017_07_28A\src\MyLoader_bypassKIS\snake\res\SiteAdv.pdb.

Варианты ВПО, связанные с атакой на пользователей Able Desktop, также содержат PDB с аналогичной строкой MyLoader_bypassKIS:
c:\Users\PC-2015\Desktop\Badger\En-v2\免杀\MyLoader_bypassKIS\bin\loaderdll.pdb.

Интересно, что существует как минимум один экземпляр (a95dfb8a8d03e9bcb50451068773cc1f1dd4b022bb39dce3679f1b3ce70aa4f9), который полностью идентичен тестовой версии MyKLoadClient и содержит точно такое же окно «О программе». При этом полезная нагрузка в нем представляет собой бэкдор Zupdax.

Полезная нагрузка

Для сетевого взаимодействия с C2 бэкдор использует протокол UDT, реализующий передачу данных поверх протокола UDP. Сообщения имеют заголовок со структурой, похожей на используемую в MyKLoadClient. Отличается лишь значение первого поля, равное 0x12345678:

struct PacketHeader{
    _DWORD Magic; // 0x12345678
    _DWORD CommandId;
    _DWORD PayloadSize;
    _DWORD Unknown; // 0
};

Сразу же после установки соединения с C2 бэкдор собирает и отправляет информацию о системе, включающую имя компьютера, имя пользователя, версию ОС, информацию об объеме дисков, оперативной памяти и процессоре, а также IP- и MAC-адреса сетевого адаптера. Собранная информация отправляется с ID команды 0x1.

Набор команд, которые бэкдор может обработать, существенно не меняется от версии к версии: его основные возможности сводятся к исполнению дополнительного кода, который он может получить от контрольного сервера. Более старые варианты Zupdax содержат отладочные сообщения, которые позволяют увидеть оригинальные названия операций:

В старых экземплярах Zupdax также присутствуют пути к PDB-файлам:
h:\E\项目问题\UDPUDP-英文\bin\server.pdb
d:\磁盘\E\项目问题\版本\UDPUDP-英文\bin\server.pdb

Из них следует, что оригинальное название проекта можно перевести как «UDPUDP-английский».

Связь с Redsip

В 2011 году специалисты McAfee описали серию атак на компании энергетического сектора, получившую название Night Dragon. Среди ВПО, использованного злоумышленниками, был бэкдор Redsip (e3165c2691dc27ddaeb21e007f2bf5aeb14ef3e12ec007938e104d6aed512f39).

По всей видимости, Zupdax представляет собой переработанную версию Redsip. Бэкдоры, в частности, имеют идентичную структуру сетевых сообщений (включая магическую константу 0x12345678), совпадающие по именам и идентификаторам команды (CMD_SET_REM и CMD_UNINSTALL_HOST), похожие отладочные сообщения. В обоих случаях полезная нагрузка реализуется через внешние плагины.

Стоит отметить, что в 2018 году Redsip был использован в атаке на российскую организацию, связанную с авиационно-космической отраслью. В качестве приманки злоумышленники использовали утекший корпоративный документ. Прямой связи этой атаки с деятельностью Space Pirates нам обнаружить не удалось.

Связи с Winnti и FF-RAT

Некоторые экземпляры Zupdax имеют валидные цифровые подписи. В частности, образец 24b749191d64ed793cb9e540e8d4b1808d6c37c5712e737674417573778f665b (upinstall.bat) подписан сертификатом YD Online Corp., а 84b8bfe8161da581a88c0ac362318827d4c28edb057e23402523d3c93a5b3429 (Slack.exe) — сертификатом NFINITY GAMES BILISIM ANONIM SIRKET.

Среди файлов, подписанных этими сертификатами, можно обнаружить компоненты ВПО PipeMon, которое приписывают группе Winnti. Изучая сетевую инфраструктуру второго образца, мы также отметили наличие косвенных связей со старой инфраструктурой Winnti, однако они требуют дополнительного подтверждения.

В то же время в случае Slack.exe можно говорить о наличии надежных инфраструктурных связей с бэкдором FF-RAT, который в 2017 году описали специалисты BlackBerry. Так, и экземпляр Zupdax, и образцы FF-RAT используют в качестве C2 поддомены playdr2.com и gamepoer7.com.

Связи с Bronze Union и TA428

В ранее упоминавшемся отчете ESET Operation StealthyTrident: corporate software under attack, посвященном компрометации Able Desktop, отмечается присутствие бэкдоров HyperBro и Zupdax (Korplug по ESET), а также Tmanger и ShadowPad в рамках одной операции злоумышленников. Исследователи приводят несколько возможных объяснений такой взаимосвязи. Нам удалось выявить несколько дополнительных фактов, дающих больше информации о связях между группами Bronze Union (LuckyMouse, APT27), TA428 и ВПО Zupdax.

Экземпляр Zupdax из отчета ESET содержит стандартный для этого ВПО дроппер (data1.dat, 2486734ebe5a7fa6278ce6358d995d4546eb28917f8f50b01d8fdd7a1f9627a4), извлекающий полезную нагрузку из ресурсов. Интерес представляет схема, по которой он получает управление: в ней используется side-loading библиотеки pcalocalresloader.dll, в которой расположен шеллкод, расшифровывающий и выполняющий еще один шеллкод из файла thumb.db. Второй шеллкод содержит сжатую алгоритмом LZNT1 DLL-библиотеку, которую он рефлективно загружает в память.

Оба шеллкода используют нетипичный алгоритм хеширования для имен импортируемых библиотек и функций (рис 15.). Так, kernel32.dll имеет хеш 0xD4E88, а ntdll.dll — 0x1B708. Однако поиск схожих экземпляров показал, что подобные шеллкоды можно встретить в различных семействах ВПО — например в SmokeLoader или в эксплойтах для InPage. Вероятно, что для создания шеллкодов был использован билдер, доступный разным хакерским группировкам.

При этом вся схема целиком, включающая легитимный компонент IntgStat.exe, библиотеку pcalocalresloader.dll и зашифрованный thumb.db, использовалась в таком виде только для загрузки бэкдора HyperBro и была описана «Лабораторией Касперского». Единственное расхождение состоит в том, что в случае с Able Desktop не применялась обфускация shikata_ga_nai.

Вспомогательная DLL, находящаяся в thumb.db, отвечает за одновременный запуск дроппера (data1.dat) и легитимного установщика Able Desktop. Она отличается наличием большого количества неиспользуемых строк в секции данных. Часть из этих строк характерна только для экземпляров бэкдора HyperBro:

Elevation:Administrator!new:{FCC74B77-EC3E-4dd8-A80B-008A702075A9}
SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\test
system-%d
CreateProcessAsUser error %d
\\..\\config.ini
Win2008(R2)
Win2012(R2)

Как следует из отчета ESET и нашего исследования, злоумышленники, стоящие за атакой на пользователей Able Desktop, имеют доступ как к HyperBro, так и к Zupdax. Однако при этом большая часть кодовых особенностей специфична именно для бэкдора HyperBro, который, в свою очередь, относят к группе Bronze Union.

Один из экземпляров Zupdax (ffe19202300785f7e745957b48ecc1c108157a6edef6755667a9e7bebcbf750b) использует в качестве C2 поддомены flashplayeractivex.info, такие как update.flashplayeractivex.info и news.flashplayeractivex.info. В августе 2020 года эти домены некоторое время разрешались в IP-адрес 209.250.239.96. Одновременно с ними на том же IP-адресе присутствовал домен go.vegispaceshop.org.

Последний домен вместе с IP-адресом можно найти в отчете NTT Security, посвященном ВПО Albaniiutas из инструментария TA428. Как показал детальный анализ образцов Albaniiutas, который провели наши коллеги из Group-IB, данное ВПО представляет собой новую версию выявленного ранее специалистами PT Expert Security Center бэкдора RemShell (BlueTraveller).

Еще один домен, появляющийся на IP-адресе 209.250.239.96 в то же самое время — nameserver.datacertsecure.info. Очевидным образом связанные с ним домены datacertsecure.info и check.datacertsecure.info в период с июня по июль 2020 года разрешаются в IP-адрес 139.180.208.225. Одновременно с этим узел становится известен как контрольный сервер бэкдора HyperBro, а затем упоминается ESET в Operation StealthyTrident.

Перечисленные связи дополнительно объединяют цели злоумышленников: скомпрометированные установщики Able Desktop, так же как и упомянутые выше экземпляры Albaniiutas и HyperBro, были использованы в атаках на организации в Монголии.

Загрузчики

В сетевой инфраструктуре Space Pirates мы обнаружили два вида загрузчиков, содержащие приманки с русским текстом. Один из них был также найден в сети нашего клиента, подвергшегося атаке злоумышленников.

Downloader.Climax.A

Первый загрузчик отличается использованием частей исходного кода буткита Rovnix (он был подробно описан экспертами «Лаборатории Касперского»). Стоит отметить, что приведенные в отчете сетевые индикаторы, в частности домен bamo.ocry.com, а также IP-адреса 45.77.244.191 и 45.76.145.22, по нашим данным, входят в сетевую инфраструктуру Space Pirates.

У нас нет информации о том, какое вредоносное ПО доставлял этот загрузчик. Однако исследователям из «Лаборатории Касперского» удалось выявить вероятные экземпляры, основываясь на схожести PDB-путей и идентичных C2.

На приведенных в отчете скриншотах полезной нагрузки можно заметить специфическую технику хранения строк: все они находятся в одном блоке данных и проиндексированы числами с префиксом «PS_». Такая техника встречается в коде публично доступного бэкдора PcShare. Выделенные исследователями наборы строк в точности соответствуют тем, которые можно встретить в открытом коде бэкдора. Аналогичное соответствие можно провести и между командами, которые поддерживает ВПО. В результате можно уверенно утверждать, что данная полезная нагрузка основана на коде PcShare.

Далее мы рассмотрим модифицированный вариант PcShare, который мы назвали RtlShare. Стоит отметить, что во время расследования у нашего клиента мы обнаружили экземпляр RtlShare, соединяющийся с C2 202.182.98.74. Его же использует образец Downloader.Climax.A с SHA-256 e9c94ed7265c04eac25bbcdb520e65fcfa31a3290b908c2c2273c29120d0617b. Учитывая сказанное ранее, можно предположить, что полезной нагрузкой, которую доставляет загрузчик, является именно RtlShare.

Downloader.Climax.B

Другой вид загрузчика для своего исполнения может использовать уязвимости в Microsoft Equation Editor. Такую уязвимость, в частности, эксплуатирует документ с именем «Мэр Сеула.rtf» (7079d8c92cc668f903f3a60ec04dbb2508f23840ef3c57efffb9f906d3bc05ff), созданный с помощью известного билдера Royal Road RTF (8.t), широко распространенного среди азиатских APT-групп.

Код этого загрузчика полностью отличается от Downloader.Climax.A, но при этом в нем можно выделить некоторые схожие особенности. В частности, для соединения с C2 оба загрузчика используют TCP, а получаемая полезная нагрузка в обоих случаях распаковывается с помощью алгоритма LZW.

Downloader.Climax.B закрепляется в системе через ключ реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Run\GetUserConfig. Его задача —получить с контрольного сервера файлы с именами INFOP11.EXE и OINFO11.OCX и запустить EXE-файл на исполнение. При этом каждый из файлов имеет свой числовой идентификатор, который отправляется на C2.

После загрузки в тело полученного OCX-файла записываются параметры конфигурации, которые присутствуют в самом загрузчике: узел и порт контрольного сервера, время ожидания между обращениями к C2, строка TodaySend, а также сгенерированный GUID.

RtlShare

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

Рассмотрим RtlShare на примере образца 8ac2165dc395d1e76c3d2fbd4bec429a98e3b2ec131e7951d28a10e9ca8bbc46.

Интересно, что для его доставки злоумышленники использовали взломанный сайт петрозаводской математической конференции PICCAnA (piccana.karelia.ru), который в настоящее время недоступен (веб-архив). В качестве контрольного сервера в нем указан частный IP-адрес 192.168.193.165.

В процессе расследования инцидента у одного из наших клиентов мы встретили практически идентичные образцы, использующие контрольные серверы 45.76.145.22, 141.164.35.87 и 202.182.98.74.

Дроппер rtlstat.dll

В качестве начальной стадии заражения выступает DLL-библиотека rtlstat.dll, экспортирующая единственную функцию emBedding. Ее задача — извлечь и запустить библиотеку следующей стадии с внутренним именем rtlmake.dll.

Для этого сперва проверяется разрядность ОС и выбирается необходимый блок данных, после чего он расшифровывается XOR с ключом в виде одной из строк 4af233f4740c2fde7fc95ed3a834d7b1 (x64) и 3ad6faf2d7b714137de31efef137775b (x86). Затем расшифрованные данные распаковываются по алгоритму LZ4.

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

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

Затем дроппер проверяет, запущен ли он от имени пользователя SYSTEM. Для этого он ищет подстроку config в пути к папке LocalAppData. Если подстрока присутствует, то библиотека перезапускается от имени текущего пользователя через rundll32.exe.

В противном случае полученная библиотека сохраняется в файл %LOCALAPPDATA%\Microsoft\Windows\WER\Security\wuaueng.hlk, а путь к ней записывается в реестр по ключу HKCU\Software\Classes\CLSID\{42aedc87-2188-41fd-b9a3-0c966feabec1}\InprocServer32. Данный раздел отвечает за COM-объект MruPidlList, используемый в библиотеке shell32.dll, которую, в свою очередь, подгружает процесс explorer.exe — это известная техника закрепления ВПО в системе.

В конце своей работы дроппер запускает извлеченную DLL на исполнение с помощью regsvr32.exe и самоудаляется через BAT-файл.

Инжектор rtlmake.dll

Версии rtlmake.dll разной разрядности имеют одну и ту же функциональность, которая сводится к извлечению DLL следующей стадии и внедрению ее кода в процесс rdpclip.exe (либо в текущий процесс).

В начале своей работы инжектор проверяет, что он работает в одном экземпляре: чаще всего с этой целью используются мьютексы, но в данном случае применены именованные отображения файлов в память (file mappings). На время работы rtlmake.dll создается mapping с именем 55fc3f9a654c500932, а за работу полезной нагрузки отвечает mapping 7f8b6a2440e5c9e5b6.

Затем с помощью аналогичной предыдущему этапу функции выполняется расшифровка и декомпрессия DLL с полезной нагрузкой и конфигурации (напомним, что она была ранее скопирована в rtlmake.dll). Ключ шифрования конфигурации — строка 2ae06f136eb6588508eefd4b5f6c98d8345f1104746d15141, а полезной нагрузки — 1192f6c4b018c8e0f51d31d6dde22ff3.

Далее выбирается процесс, в который будет внедрена полезная нагрузка. Если текущий процесс — это explorer.exe (что верно, если библиотека была загружена в качестве COM-компонента), то целевым процессом станет rdpclip.exe. В случае если rdpclip.exe не удалось запустить, либо если DLL была загружена в другой процесс, целевым процессом становится текущий.

В память выбранного процесса записывается расшифрованная конфигурация, после чего инжектор формирует командную строку вида «/v /c:0x12345678», содержащую адрес конфигурации в адресном пространстве процесса. Полученная строка и полезная нагрузка также записываются в память процесса.

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

Полезная нагрузка rtlmain.dll (rtlmainx64.dll)

Последняя DLL полностью реализована на основе кода основного модуля бэкдора PcShare — PcMain. Отметим некоторые ее особенности, которые характерны только для семейства RtlShare:

• Внутри библиотеки реализован рефлективный загрузчик, который находится в функции Putklm. Адрес командной строки, который она принимает, передается в DllEntryPoint через параметр lpReserved и при этом шифруется XOR с константой 0x73DE2938. Восстановление адреса и разбор командной строки происходит внутри функции DllMain.
• После запуска rtlmain.dll завершаются все процессы rdpclip.exe кроме текущего.
• Хранилище строк бэкдора дополнительно к сжатию LZ4 (которое присутствует в открытом коде) зашифровано AES с ключом 68fa504a1aee69f71df454e554c74eaf. Аналогичным образом кодируются принимаемые (ключ 48d426ca6d45496e7413cf435516af06) и передаваемые (ключ 2e5140d04c7d7da454991bae10160369) сообщения.
• Добавлена поддержка соединения через прокси-сервер.
• Присутствует специальная команда, позволяющая злоумышленникам перезаписать конфигурацию внутри инжектора rtlmake.dll (необходимое смещение содержит магическую константу 0x76EE38BB).
• В код, отвечающий за реализацию удаленной командной строки, добавлена команда getip, которая реализована через вызов nslookup myip.opendns.com resolver1.opendns.com.

Использование RtlShare

Образцы RtlShare можно обнаружить в других отчетах. Так, например, исследователи Recorded Future обнаружили в сетевой инфраструктуре группы RedFoxtrot образцы ВПО PcShare, которые имеют значительное сходство с семейством RtlShare. Помимо этого, аналогичные экземпляры ранее встречались Bitdefender при расследовании активности APT-группы с азиатскими корнями, нацеленной на государственные учреждения Юго-Восточной Азии.

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

PlugX

В сети нашего клиента мы также обнаружили несколько экземпляров бэкдора PlugX. Найденные экземпляры использовали в качестве контрольных серверов адреса micro.dns04.com, microft.dynssl.com, api.microft.dynssl.com и www.0077.x24hr.com, входящие в сетевую инфраструктуру группы и прямо пересекающиеся с C2 MyKLoadClient.

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

Как и в обычном PlugX, основная полезная нагрузка бэкдора реализована в виде DLL-библиотеки, которая рефлективно загружается в память в процессе исполнения ВПО. В ее точку входа первым аргументом передается указатель на структуру, в которой содержатся, в частности, сигнатура и адрес зашифрованной конфигурации.

В оригинальном PlugX сигнатура представляет собой константу 0x504C5547 (строка PLUG), однако в нашей группе образцов это значение было равно 0xCF455089. Нестандартен и размер конфигурации, который равен 0x1924 байта: нам не удалось найти упоминание такой конфигурации в открытых источниках. В отличие от многих других вариантов, имеющих сигнатуру XV вместо MZ и PE, в нашем случае заголовок PE-файла с полезной нагрузкой остается неизменным.

В бэкдоре активно применяется техника встраивания кода (inlining), в частности это касается API-вызовов и шифрования строк.

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

Практически все строки в бэкдоре являются стековыми, большинство из них зашифровано методом ADD-XOR-SUB. Код для расшифровки копируется во все места, где используются шифрованные строки.

ВПО использует стандартный набор плагинов, известный с ранних версий. В оригинальном PlugX на этапе их инициализации используется параметр, выглядящий как дата. Так, плагин Disk имеет параметр 0x20120325. В нашем случае для всех плагинов сочетание 2012 изменено на 8102 (что может означать 2018): тот же плагин Disk использует значение 0x81020325.

Бэкдор целиком также имеет числовое значение, указывающее на версию: оно передается на C2 вместе с информацией о зараженной системе и равно 0x20161127. Такую же версию можно встретить в Backdoor.PlugX.38 из отчета Dr.Web об атаках на государственные учреждения Казахстана и Киргизии. Однако другие уникальные значения из варианта группы Space Pirates, такие как сигнатура и размер конфигурации, в BackDoor.PlugX.38 отсутствуют. По-видимому, оба варианта основаны на базовом коде одной и той же версии PlugX, но его модификации в каждом из этих случаев отличаются.

Более точные пересечения мы встретили в других отчетах. Среди экземпляров PlugX, которые были использованы в атаках на Ватикан в 2019–2020 годах, можно обнаружить несколько образцов, которые аналогичны используемым группой Space Pirates. Помимо этого, те же модификации бэкдора встречаются в образцах, которые связывают с активностью группы RedFoxtrot. При этом обнаружить связей в сетевой инфраструктуре нам не удалось, что позволяет вновь говорить об обмене инструментарием между группами. Учитывая другие пересечения между использовавшимся в атаках ВПО (Zupdax и RtlShare), можно также предположить, что вся эта активность принадлежит одной или нескольким совместно действующим группам. Впрочем, это требует дополнительного подтверждения.

Demo dropper

Некоторые экземпляры обнаруженного нами варианта PlugX извлекаются в систему интересным дроппером, исполняемый файл которого может называться demo.exe. Он реализован на основе библиотеки MFC. Его работа сводится к созданию VBS-скрипта с именем msiexece.vbs или cosetsvc.vbs и его последующему запуску.

В качестве параметров командной строки скрипту передается путь к EXE-дропперу и имена файлов, которые будут из него извлечены. Файлы находятся в оверлее demo.exe и могут быть зашифрованы однобайтовым XOR (но во всех известных нам экземплярах ключ равен 0). Смещение оверлея и длина каждого из файлов прописаны в VBS-коде. Скрипт извлекает стандартные для PlugX компоненты — легитимный EXE-файл, DLL для Side-Loading и зашифрованный шеллкод, после чего легитимный файл запускается.

BH_A006

Данное ВПО, как и в других случаях, мы обнаружили как во время конкретного расследования у клиента, так и в процессе исследования сетевой инфраструктуры группы. В качестве полезной нагрузки оно содержит модифицированный бэкдор Gh0st. Строка BH_A006 постоянно встречается в PDB-путях и внутренних именах DLL-библиотек, связанных с бэкдором, поэтому он получил такое название.

BH_A006 имеет нетривиальную схему исполнения полезной нагрузки, которая может варьироваться на начальных этапах в различных экземплярах. Рассмотрим ее на примере одного из вредоносных файлов.

Стадия 0. Загрузка DLL из оверлея

SHA-256: 1e725f1fe67d1a596c9677df69ef5b1b2c29903e84d7b08284f0a767aedcc097

Исходный образец представляет собой исполняемый файл, использующий библиотеку MFC. Он извлекает содержимое оверлея, расшифровывает его XOR с ключом 0xA0 и рефлективно загружает полученную DLL в память.

Стадия 1. DLL-дроппер

SHA-256: 8bf3df654459b1b8f553ad9a0770058fd2c31262f38f2e8ba12943f813200a4d

извлекает следующие файлы:

• C:\ProgramData\resmon.resmoncfg
• C:\ProgramData\Sandboxie\SbieIni.dat (install32.dat)
• C:\ProgramData\Sandboxie\SbieDll.dll
• C:\ProgramData\Sandboxie\SandboxieBITS.exe

После этого происходит проверка наличия прав записи в системную папку. Для этого дроппер пытается создать в ней файл с именем формата wmkawe_%d.data. В качестве содержимого выступает строка Stupid Japanese.

Если права отсутствуют, а система является 64-битной, дополнительно извлекаются еще два файла:

• C:\ProgramData\Sandboxie.dll (install64.dll)
• C:\ProgramData\Sandboxie.dat (install64.dat)

Имена, указанные в скобках, не используются, но присутствуют в коде. По всей видимости, они остались там от другой версии дроппера.

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

В зависимости от наличия прав и разрядности ОС дроппер запускает одну из цепочек для обхода UAC:

• (x32) C:\ProgramData\Sandboxie\SandboxieBITS.exe ByPassUAC
• (x64) rundll32.exe C:\ProgramData\Sandboxie\SbieMsg.dll,installsvc ByPassUAC

Либо сразу же переходит к исполнению следующей стадии:
C:\ProgramData\Sandboxie\SandboxieBITS.exe InsertS

В любом из трех случаев создается и запускается файл %tmp%\delself.bat, содержащий команды для самоудаления.

Стоит отметить, что данный экземпляр не впервые встречается исследователям. Другой вариант MFC-загрузчика (стадия 0), содержащий тот же самый дроппер, был упомянут ESET в отчете Operation NightScout, а затем подробно изучен нашими коллегами из VinCSS.

Стадия 2. Загрузчик .dat (SbieDll.dll / SbieMsg.dll)

Вне зависимости от команды, которая была запущена DLL-дроппером, исполнение переходит к одной из извлеченных DLL-библиотек. В случае 32-битной версии для этого используется легитимный компонент утилиты Sandboxie, уязвимый к DLL Side-Loading.

Код в 32- и 64-битной версиях библиотек практически идентичен и отвечает за загрузку соответствующего файла .dat, расшифровку его содержимого и запуск на исполнение. Для расшифровки используется XOR с последовательностью байт вида 00, 01, 02, … FF, 00, 01, … Так же как и в коде предыдущей стадии, здесь можно увидеть альтернативные пути к файлам .dat, которые не используются во время работы.

Стадия 3. Шеллкод .dat и DLL

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

Стадия 3.1 ByPassUAC (x64)

Стадия 3.1.1 Промежуточная DLL

64-битная версия отвечает только за реализацию обхода UAC. Для выполнения этой задачи она извлекает из себя в память еще одну DLL и передает ей управление. Рефлективная загрузка вновь выполняется с помощью шеллкода, который предварительно расшифровывается XOR с ключом 0x97. Шеллкод при этом не автономный: помимо буфера с PE-файлом, ему передаются указатели на необходимые функции, такие как GetProcAddress и LoadLibraryA.

Стадия 3.1.2 DLL с реализацией обхода UAC

В DLL присутствует путь к PDB-файлу: e:\F35-F22\昆明版本\ElephantRat\nwsapagent\Bin\ByPassUAC64.pdb.

Применяемый метод UAC bypass зависит от наличия в системе процесса avp.exe (компонент антивирусных продуктов «Лаборатории Касперского») и версии системы. Всего реализовано три известных метода, использующих sdclt.exe, .NET-библиотеку и подделку доверенных директорий.

При успешном выполнении обхода любым из способов будет запущена уже встречавшаяся ранее команда C:\ProgramData\Sandboxie\SandboxieBITS.exe InsertS.

Стадия 3.2. ByPassUAC / InstallS (x32)

Стадия 3.2.1. Промежуточная DLL

32-битная версия DLL, которая расположена в соответствующем файле DAT, обфусцирована с помощью неизвестного протектора.

В секции данных этой DLL находится сжатый шеллкод, который распаковывается и получает управление.

Стадия 3.2.2. Шеллкод распаковки

Шеллкод начинается с вызова функции sub_20F, которая принимает три аргумента: хеш от имени VirtualAlloc, размер буфера для распаковки и указатель на данные. Аргументы записаны сразу после инструкции call, и вызываемая функция обращается к ним, используя смещение относительно адреса возврата.

Функция sub_20F получает указатель на функцию VirtualAlloc, для чего находит библиотеку kernelbase.dll в списке загруженных модулей (предполагается, что она всегда находится на втором месте в списке InInitializationOrderModuleList) и итерирует ее таблицу экспорта, используя хеш для нахождения нужной функции. Затем выделяется буфер заданного в аргументах размера с правами RWX, и в него распаковываются сжатые данные. В данном случае для сжатия применяется алгоритм семейства NRV из библиотеки UCL (используется в пакере UPX). Данные представляют собой еще один шеллкод, на который передается управление.

Стадия 3.2.3. Шеллкод релокации

Основная часть очередного шеллкода представляет собой содержимое секций данных и кода, по всей видимости, извлеченного из некоторого PE-файла. Для корректного запуска в начале своей работы шеллкод выполняет корректировку адресов (релокацию). Необходимые для нее параметры передаются аналогично предыдущему шеллкоду с использованием адреса возврата. Релокация выполняется относительно стандартного базового адреса 0x401000. После ее завершения управление передается на указанный в параметрах (как смещение относительно конца таблицы релокации) адрес точки входа.

Стадия 3.2.4. Инсталлятор в формате шеллкода

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

Поддерживаются следующие команды:

• InsertS — создание сервиса Network Service. В качестве пути для запуска указывается имя текущего модуля с параметром runsvc. При отсутствии в списке процессов avp.exe сервис будет сразу же запущен.

• Runsvc — удаление всех вспомогательных файлов и папок, которые могли использоваться в процессе обхода UAC. Распаковка шеллкода следующей стадии, создание процесса svchost.exe и инъекция распакованного шеллкода. Интересно, что в коде, отвечающем за имперсонацию и запуск процесса svchost.exe, реализована специальная проверка для русского языка системы (и только для него), что говорит об ориентации на русскоязычные версии ОС.

  

  Помимо этого, создается отдельный поток, который каждые 50 секунд проверяет наличие маппинга Global\MYKERNELDLLMAPPING06. В случае его отсутствия в системе повторяется создание svchost.exe и инъекция шеллкода.

• ByPassUAC — работает полностью аналогично 64-битной версии (стадия 3.1.1): распаковывает DLL с реализацией методов обхода UAC и передает ей управление.
• Memload — в коде присутствует отладочное сообщение MemLoadServer. Распаковывает шеллкод следующей стадии и запускает его напрямую в текущем процессе.

Стадия 4. MemLoadLibrary

Четвертая стадия имеет уже встречавшийся ранее формат: шеллкод распаковки извлекает шеллкод релокации, который в свою очередь запускает на исполнение основной код (полученный из PE-файла). Основной код в данном случае имеет небольшой объем и отвечает за распаковку и рефлективную загрузку DLL в память. Рефлективный загрузчик реализован в виде зашифрованного XOR шеллкода, как и на стадии 3.1.1. После загрузки библиотеки управление передается экспортируемой функции Online.

DLL вновь является лишь промежуточным загрузчиком и запускает очередной шеллкод.

Новый шеллкод является шеллкодом распаковки, и стадия 4 повторяется в точности, вплоть до вызова функции Online из последней DLL-библиотеки.

Стадия 5. Полезная нагрузка

Представляет собой частично обфусцированный с помощью уже встречавшегося пакера (стадия 3.2.1) бэкдор, который основан на коде трояна Gh0st.

Интересно, что сигнатура сетевых пакетов (Gh0st в оригинале) в данной версии генерируется и проверяется особым образом. В четырехбайтовом значении полезную нагрузку несет только младший бит каждого байта, остальные биты случайны. Младшие биты должны удовлетворять набору логических соотношений, в которых участвуют младшие биты магической константы 0x31230C0. Стоит отметить, что аналогичный алгоритм проверки этих соотношений, использующий ту же константу, можно найти в загрузчиках файлов .dat (стадия 2), однако там результат его работы не используется.

Библиотека имеет экспортируемое имя BH_A006_SRV.dll, а в оверлее PE-файла можно обнаружить соответствующий PDB-путь:

D:\005（fastapp f35 20181009）\nwsapagent\KernelTrjoan\BH_A006_SRV\BH_A006_SRV\Debug\BH_A006_SRV.pdb

Нам удалось найти экземпляр ВПО (57d4c08ce9a45798cd9b0cf08c933e26ffa964101dcafb1640d1df19c223e738), который имеет аналогичную обфускацию, идентичный алгоритм генерации сетевой сигнатуры и содержит имя BH_A006_SRV.dll. При этом данный экземпляр был загружен на VirusTotal в 2015 году.

Связь с 9002 RAT

В процессе изучения цепочки исполнения бэкдора BH_A006 оказалось, что использованная в ней техника преобразования PE-файла в автономный сжатый шеллкод не уникальна. Аналогичные шеллкоды распаковки и релокации, а также процедура загрузки WinAPI-функций присутствуют в экземплярах ВПО 9002 RAT. Например, их можно найти в образце 52374f68d1e43f1ca6cd04e5816999ba45c4e42eb0641874be25808c9fe15005 из отчета Trend Micro об атаках на южнокорейские компании — одного из последних упоминаний данного ВПО.

Deed RAT

Еще один вид ранее неизвестного ВПО, который в единственном экземпляре мы обнаружили у нашего клиента, представляет собой модульный бэкдор. По значению сигнатуры, которая используется в заголовке его модулей, мы дали ему название Deed RAT.

Контрольный сервер Deed RAT ftp.microft.dynssl.com напрямую связан с инфраструктурой группы Space Pirates. Сходство можно найти и в одной из кодовых особенностей: для шифрования шеллкода так же, как и в части экземпляров PlugX, используются операции [xor 0xBB, sub 0x1].

Схема исполнения полезной нагрузки напоминает стандартный метод, который использует PlugX: легитимный EXE-файл, подписанный Trend Micro, загружает в процессе работы вредоносную библиотеку TmDbgLog.dll, которая, в свою очередь, запускает на исполнение зашифрованный шеллкод из файла PTWD.tmp.

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

Шеллкод представляет собой загрузчик основного модуля, который в сжатом и зашифрованном виде располагается после кода загрузки. Модуль имеет специальную структуру и использует техники, заимствованные из PE-файлов. В частности, в модуле присутствуют три «секции» с различными правами доступа и таблица релокации, полностью аналогичная используемой в формате PE.

Расшифрованный модуль состоит из заголовка, начинающегося с сигнатуры 0xDEED4554 и основного блока данных, сжатого LZNT1, в котором содержатся данные секций и таблица релокации. Для каждой из секций в заголовке указаны ее фактический размер и размер в памяти, который выровнен на границу 0x1000. Структура заголовка выглядит следующим образом:

struct SectionHeader{
    _DWORD VirtualSize;
    _DWORD SizeOfRawData;
};

struct ModuleHeader{
    _DWORD Signature; // 0xDEED4554
    _DWORD ModuleId;
    _DWORD EntryPoint;
    _DWORD OriginalBase;
    _DWORD AbsoluteOffset; // 0x1000
    SectionHeader Sections[3];
    _DWORD Unknown;
};

В процессе работы загрузчик выделяет необходимую область памяти, копирует в нее каждую из секций (учитывая ее размер в памяти) и выполняет настройку адресов (релокацию). Первая из секций содержит исполняемый код, и для ее области памяти устанавливаются права RX, остальные секции имеют права RW. После загрузки секций управление получает точка входа модуля, указанная в заголовке.

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

В отличие от основного модуля для шифрования плагинов используется алгоритм на основе Salsa20. Среди модификаций — собственная константа для расширения ключа, равная arbitraryconstat. Структура расшифрованного плагина полностью повторяет структуру основного модуля, и для его загрузки используется аналогичный алгоритм.

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

1. Инициализация.
2. Получение числового идентификатора плагина.
3. Получение названия плагина.
4. Получение ссылки на структуру с API-функциями плагина.
5. Освобождение ресурсов.

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

Одной из интересных особенностей бэкдора является псевдослучайная генерация различного рода строк — ключей реестра, имен мьютексов и каналов (pipes), аргументов командной строки. Строка необходимой длины создается на основе сида, в формировании которого участвуют числовой идентификатор строки, а также серийный номер системного тома. В результате на каждой из зараженных машин используется свой уникальный набор строковых констант.

Все необходимые данные бэкдор хранит в разделе реестра [HKLM|HKCU]\Software\Microsoft\. Для каждого типа информации в нем создается свой подраздел, имя которого получается с помощью описанного выше генератора строк. Чтобы получить все ключи, которые может использовать бэкдор, мы реализовали скрипт на Python, принимающий серийный номер тома и воспроизводящий работу генератора.

Генератор ключей реестра

import click


def rshift(val, n):
    s = val & 0x80000000
    for i in range(0,n):
        val >>= 1
        val |= s
    return val


def generator(volume_number, seed, length):
    gr_seed = (volume_number + seed + 0x1000193) & 0xffffffff
    r = []
    for i in range(length):
        r1 = (gr_seed * 0x2001) & 0xffffffff
        r2 = rshift(r1, 7)
        r3 = r2 ^ r1
        r4 = (r3 * 9) & 0xffffffff
        r5 = rshift(r4, 17)
        r6 = r4 ^ r5
        r7 = (r6 * 33) & 0xffffffff
        r.append(((r7 & 0xffff) % 26) + 0x41)
        gr_seed = r7 
    
    return bytes(r).decode('utf-8')

@click.command()
@click.argument("VOLUME_NUMBER")
def main(volume_number):
    try:
        serial_number = int(volume_number, 16)
    except ValueError:
        print("[~] Invalid Volume number")
        return 

    registry_key_1 = generator(serial_number, 0xC4DA8B2F, 6)

    registry_key_2 = generator(serial_number, 0x7BD90AA1, 10)
    registry_key_3 = generator(serial_number, 0xF7BBC23F, 10)

    registry_key_4 = generator(serial_number, 0xDF12A5B2, 8)
    registry_key_5 = generator(serial_number, 0x6EB208A4, 9)

    registry_key_6 = generator(serial_number, 0xDE8765CB, 8)
    registry_key_7 = generator(serial_number, 0x6D3C218A, 8)

    registry_key_8 = generator(serial_number, 0x78D3BC22, 8)
    registry_key_9 = generator(serial_number, 0xD53BCA90, 10)

    registry_key_11 = generator(serial_number, 0x4FD82CB4, 8)
    registry_key_13 = generator(serial_number, 0xDCBC5D23, 8)

    registry_key_10 = generator(serial_number, 0xE2C7BA56, 15)
    
    registry_key_12 = generator(serial_number, 0x8BD43C12, 8)

    print(f"[+] Plugin monitor registry key: [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_1}")
    print(f"[+] Executable path: [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_3}; ValueName: {registry_key_2}")
    print(f"[+] Machine ID: [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_5}; ValueName: {registry_key_4}")
    print(f"[+] Shellcode for injection: [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_6}; ValueName: {registry_key_7}")
    print(f"[+] Proxies: [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_9}; ValueName: {registry_key_8}")
    print(f"[+] Config : [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_11}; ValueName: {registry_key_13}")

if __name__ == "__main__":
    main()

За алгоритм взаимодействия с контрольным сервером отвечает плагин Network. Он извлекает адрес C2 в виде URL-строки из конфигурации и в зависимости от указанной в нем схемы выбирает один из коннекторов, доступных в плагине NetSocket. Все они реализуют общий интерфейс, позволяющий единообразно принимать и передавать сетевые сообщения. Перед отправкой сообщения сжимаются с помощью алгоритма LZNT1 и шифруются модифицированным Salsa20 с использованием случайного ключа.

Для разрешения домена контрольного сервера бэкдор последовательно использует DNS over HTTPS и обычные DNS-серверы, указанные в конфигурации (публичные серверы Google и других провайдеров), прежде чем обратиться к стандартному механизму. Это дает ВПО возможность скрыть домен C2 от средств инспекции сетевого трафика.

Среди поддерживаемых протоколов соединения — TCP, TLS, HTTP, HTTPS, UDP и DNS.

Для TCP доступна опция REUSEPORT — ее указание приводит к предварительной привязке сокета, с помощью которого выполняется соединение с C2. Привязка выполняется к наибольшему свободному порту в диапазоне системных (well-known) портов. Порты перебираются начиная с 1022 в порядке убывания. По-видимому, такая техника внедрена для обхода средств защиты и маскировки трафика под системные сетевые сервисы.

В бэкдоре также предусмотрена возможность получения нового C2 по протоколу HTTP. Для этого может быть использована веб-страница, адрес которой указывается в конфигурации со схемой URL://. Страница загружается, после чего в ее теле происходит поиск подстрок agmsy4 и ciou0, которые обозначают начало и конец строки с контрольным сервером. Эта строка закодирована с помощью base16 (hex) с алфавитом abcghimnostuyz0456 и обрабатывается аналогично адресу из конфигурации.

Коннекторы TCP/TLS и HTTP/HTTPS поддерживают соединение через прокси-сервер, который может быть получен с помощью плагина NetProxy. Плагин имеет собственное хранилище прокси, которое располагается в реестре и может наполняться значениями из конфигурации, системными прокси и данными из установленных браузеров (Chrome, Opera и Firefox). Кроме того, плагин имеет функциональность встроенного сниффера, который прослушивает трафик зараженной машины с помощью raw socket. Если сниффер обнаруживает в исходящем пакете попытку соединения с прокси-сервером (SOCKS4, SOCKS5 или HTTP), он сохраняет информацию о нем в хранилище.

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

После установки соединения бэкдор может выполнять следующие команды:

Если получена команда, которой нет в списке выше, то предполагается, что это сетевая команда одного из плагинов. Его ID определяется наложением маски 0xFFF0 на идентификатор команды. Если плагин отсутствует локально, он предварительно загружается с C2 и сохраняется в реестре.

На зараженной Deed RAT машине нам удалось обнаружить единственный плагин, полученный динамически с контрольного сервера. Он называется Shell и имеет ID 0x270. Shell поддерживает две сетевые команды (0x270 и 0x271), каждая из которых запускает указанный процесс и перенаправляет его ввод-вывод на C2. В первом случае взаимодействие происходит в текстовом режиме через потоки (pipes). Во втором случае используются операции Windows Console API, что позволяет злоумышленникам полноценно эмулировать консольное окно на своей стороне, учитывая информацию о размере экранного буфера, позиции курсора и другие параметры.

В конфигурации исследованного нами образца содержался следующий набор строк:

Заключение

APT-группировки с азиатскими корнями продолжают атаковать российские компании, что подтверждает и активность группы Space Pirates. Злоумышленники как разрабатывают новое ВПО, реализующее нестандартные техники (такое, например, как Deed RAT), так и используют модификации уже существующих бэкдоров. Иногда такие модификации могут иметь множество слоев обфускации, добавленных для противодействия средствам защиты и усложнения процедуры анализа — как в случае BH_A006, построенного на коде популярного бэкдора Gh0st.

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

Специалисты PT ESC продолжат работу по мониторингу угроз: новые факты могут дать больше информации о деятельности группы Space Pirates и ее взаимосвязи с другими группировками.

Приложения

MITRE

IOCs

Файловые индикаторы

MyKLoadClient

Zupdax

Downloader.Climax.A

Downloader.Climax.B

RtlShare

PlugX

PlugX demo dropper

BH_A006

Примечание: файл с SHA-256 9843ceaca2b9173d3a1f9b24ba85180a40884dbf78dd7298b0c57008fa36e33d ранее был ошибочно приведен в нашем отчете как экземпляр ShadowPad. В действительности он относится к семейству образцов бэкдора BH_A006.

Deed RAT

ShadowPad

Poison Ivy

Сетевые индикаторы

MyKLoadClient

microft.dynssl.com

micro.dns04.com

207.148.121.88

47.108.89.169

120.78.127.189

121.89.210.144

Zupdax

ns2.gamepoer7.com

mail.playdr2.com

pop.playdr2.com

news.flashplayeractivex.info

update.flashplayeractivex.info

ns9.mcafee-update.com

154.211.161.161

192.225.226.218

Downloader.Climax.A

bamo.ocry.com

202.182.98.74

Downloader.Climax.B

ruclient.dns04.com

loge.otzo.com

RtlShare

asd.powergame.0077.x24hr.com

w.asd3.as.amazon-corp.wikaba.com

45.76.145.22

141.164.35.87

202.182.98.74

PlugX

microft.dynssl.com

api.microft.dynssl.com

micro.dns04.com

www.0077.x24hr.com

js.journal.itsaol.com

fgjhkergvlimdfg2.wikaba.com

goon.oldvideo.longmusic.com

as.amazon-corp.wikaba.com

freewula.strangled.net

szuunet.strangled.net

lib.hostareas.com

web.miscrosaft.com

eset.zzux.com

elienceso.kozow.com

lck.gigabitdate.com

miche.justdied.com

45.77.16.91

103.101.178.152

123.1.151.64

154.85.48.108

154.213.21.207

192.225.226.123

192.225.226.217

BH_A006

comein.journal.itsaol.com

www.omgod.org

findanswer123.tk

45.76.145.22

103.27.109.234

108.160.134.113

Deed RAT

ftp.microft.dynssl.com

ShadowPad

toogasd.www.oldvideo.longmusic.com

wwa1we.wbew.amazon-corp.wikaba.com

Poison Ivy

shareddocs.microft.dynssl.com

DDNS-домены третьего уровня

microft.dynssl.com

reportsearch.dynamic-dns.net

micro.dns04.com

werwesf.dynamic-dns.net

fssprus.dns04.com

loge.otzo.com

alex.dnset.com

ruclient.dns04.com

bamo.ocry.com

tombstone.kozow.com

toon.mrbasic.com

fgjhkergvlimdfg2.wikaba.com

rt.ftp1.biz

apple-corp.changeip.org

amazon-corp.wikaba.com

0077.x24hr.com

staticd.dynamic-dns.net

srv.xxxy.biz

serviechelp.changeip.us

mktoon.ftp1.biz

noon.dns04.com

ybcps4.freeddns.org

oldvideo.longmusic.com

chdsjjkrazomg.dhcp.biz

q34ewrd.youdontcare.com

journal.itsaol.com