Higaisa или Winnti? Старые и новые бэкдоры APT41

Специалисты PT Expert Security Center регулярно отслеживают появление новых угроз ИБ — как ранее известных, так и впервые обнаруженных вредоносных программ. Во время такого мониторинга в мае 2020 года было обнаружено несколько новых образцов ВПО, которое, на первый взгляд, следовало отнести к группе Higaisa. Однако подробный анализ привел нас к группе Winnti (также известной как APT41, по данным FireEye), происходящей из Китая, а дальнейший мониторинг ― к выявлению множества новых экземпляров ВПО, использованных группировкой в последних атаках. Среди них различные дропперы, загрузчики и инжекторы, образцы бэкдоров Crosswalk, ShadowPad, PlugX, а также образцы ранее не описанного бэкдора, названного нами FunnySwitch. Можно определенно говорить, что некоторые атаки были направлены на ряд организаций в России и Гонконге.

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

Содержание

1. Ярлыки Higaisa
   1. Атрибуция
   2. Crosswalk
2. Загрузчики и инжекторы
   1. Инжекторы
   2. Загрузчики локального шеллкода
   3. Примеры атак
      1. Зашифрованное резюме
      2. I can't breathe
      3. Запись чата
3. Атаки на российских разработчиков игр
   1. Unity3D Game Developer from Saint Petersburg
   2. HFS с продолжением
4. Похищенный сертификат
5. FunnySwitch
   1. Распаковка
   2. Funny.dll
      1. Транспортные протоколы
      2. Протокол сетевого уровня
      3. Протокол прикладного уровня
      4. Поддерживаемые команды
      5. Неиспользуемый код
      6. FunnySwitch vs Crosswalk
6. ShadowPad
7. PlugX
   1. Paranoid PlugX
8. Заключение
9. Вердикты наших продуктов
   1. PT Sandbox
   2. PT Network Attack Discovery
10. Приложения
    1. Выявленные имена файлов, из которых может загружаться PL-шеллкод
    2. IOCs
    3. MITRE

1. Ярлыки Higaisa

Первая атака была датирована 12 мая 2020. Использованный в ней вредоносный файл представляет собой архив с именем Project link and New copyright policy.rar (c3a45aaf6ba9f2a53d26a96406b6c34a56f364abe1dd54d55461b9cc5b9d9a04). Архив содержит документ-приманку в формате PDF (Zeplin Copyright Policy.pdf), а также папку All tort's projects - Web lnks с двумя ярлыками:

• Conversations - iOS - Swipe Icons - Zeplin.lnk,
• Tokbox icon - Odds and Ends - iOS - Zeplin.lnk.

Структура вредоносных ярлыков похожа на образец 20200308-sitrep-48-covid-19.pdf.lnk, который распространялся группой Higaisa в марте 2020.

Механизм начального заражения принципиально не изменился ― при попытке открыть любой из ярлыков выполняется команда, которая извлекает из тела LNK-файла закодированный с помощью Base64 CAB-архив, который затем распаковывается во временную папку. Дальнейшие действия выполняются с помощью извлеченного JS-скрипта.

На этом этапе сходство с описанным нами в отчете о Higaisa образцом заканчивается: скрипт копирует полезную нагрузку в папку C:\Users\Public\Downloads, закрепляется в системе с помощью добавления в папку автозагрузки и создания задачи в планировщике и запускает основную нагрузку. Помимо этого, скрипт отправляет вывод команды ipconfig с помощью POST-запроса на http://zeplin.atwebpages[.]com/inter.php.

Исполняемая ярлыком команда содержит также открытие извлеченного из архива URL-файла. Имя URL-файла и адрес, по которому происходит переход, зависит от открытого ярлыка:

• Conversations - iOS - Swipe Icons - Zeplin.url отправляет на

  https://app.zeplin.io/project/5b5741802f3131c3a63057a4/screen/5b589f697e44cee37e0e61df;

• Tokbox icon - Odds and Ends - iOS - Zeplin.url отправляет на

  https://app.zeplin.io/project/5c161c03fde4d550a251e20a/screen/5cef98986801a41be35122bb.

Это единственное различие между двумя LNK-файлами. В обоих случаях открываемая страница находится на легитимном сервисе Zeplin, предназначенном для совместной работы дизайнеров и разработчиков, и требует авторизации для просмотра.

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

• svchast.exe

  Представляет из себя простой локальный загрузчик шеллкода, расположенного по фиксированному пути. Прежде чем начать работу, загрузчик проверяет, что текущий год — 2018, 2019, 2020 или 2021.

  

• 3t54dE3r.tmp

  Шеллкод, содержащий основную полезную нагрузку — бэкдор Crosswalk.

30 мая 2020 был выявлен новый вредоносный объект — архив CV_Colliers.rar (df999d24bde96decdbb65287ca0986db98f73b4ed477e18c3ef100064bceba6d) с двумя ярлыками:

• Curriculum Vitae_WANG LEI_Hong Kong Polytechnic University.pdf.lnk,
• International English Language Testing System certificate.pdf.lnk.

Их структура полностью повторяла образцы от 12 мая. В качестве приманки в данном случае использовались PDF-документы, содержащие резюме и сертификат IELTS. Вывод команды ipconfig в зависимости от открытого ярлыка отправлялся на один из двух адресов: http://goodhk.azurewebsites[.]net/inter.php или http://sixindent.epizy[.]com/inter.php.

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

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

1.1 Атрибуция

Данные атаки были подробно изучены нашими коллегами из Malwarebytes и Zscaler. Основываясь на схожести цепочек заражения, исследователи относят их к группе Higaisa.

Однако детальный анализ использованного шеллкода показал, что его образцы принадлежат к семейству ВПО Crosswalk. Это вредоносное ПО появилось не позднее 2017 года и было впервые упомянуто в отчете FireEye о деятельности группы APT41 (Winnti).

Исследование сетевой инфраструктуры образцов также позволяет найти пересечения с ранее известной инфраструктурой APT41: на IP-адресе одного из C2-серверов обнаруживается SSL-сертификат с SHA-1 b8cff709950cfa86665363d9553532db9922265c, который также встречается на IP-адресе 67.229.97[.]229, упомянутом в отчете CrowdStrike за 2018 год. Дальнейшее изучение позволяет выйти на некоторые домены из отчета Kaspersky от 2013 года.

Все это приводит нас к выводу, что данные атаки на основе LNK-файлов проводились группой Winnti (APT41), которая позаимствовала у Higaisa технику использования ярлыков.

1.2 Crosswalk

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

Собираемая информация включает в себя:

• время работы ОС (uptime);
• IP-адреса сетевых адаптеров;
• MAC-адрес одного из адаптеров;
• версию и разрядность операционной системы;
• имя пользователя;
• имя компьютера;
• имя исполняемого модуля;
• PID процесса;
• версию и разрядность шеллкода.

Шеллкод имеет как 32-, так и 64-разрядные модификации. Его версии кодируются двумя числами, среди обнаруженных нами — 1.0, 1.10, 1.21, 1.22, 1.25, 2.0.

Более детальный анализ одной из версий Crosswalk изложен в исследовании VMWare CarbonBlack. Мы же на примере версии 1.25 (8e6945ae06dd849b9db0c2983bca82de1dddbf79afb371aa88da71c19c44c996), использованной в атаках с LNK-файлами, подробнее остановимся на сетевых особенностях ВПО.

Crosswalk имеет широкие возможности по соединению с управляющими серверами. Сетевая конфигурация конкретного экземпляра находится в конце шеллкода и зашифрована XOR с ключом длиной 16 байт. Данные имеют следующую структуру:

• размер конфигурации (4 байта);
• ключ (16 байт);
• шифрованная конфигурация.

Конфигурация, в свою очередь, содержит в себе следующие поля:

• 0x0 период отправки heartbeat-сообщений (в секундах);
• 0x4 период переподключения (в секундах);
• 0x8 битовая маска для дней недели, в которые разрешено подключение;
• 0xC нижняя граница для часов, в который разрешено подключение (включительно);
• 0x10 верхняя граница для часов, в которые разрешено подключение (невключительно);
• 0x14 порт прокси-сервера;
• 0x18 тип прокси-сервера;
• 0x1C хост прокси-сервера;
• 0x9C логин прокси-сервера;
• 0x11C пароль прокси-сервера;
• 0x19C количество контрольных серверов;
• 0x1A0 массив структур контрольных серверов.

Структура контрольного сервера состоит из следующих полей:

• 0x0 тип соединения;
• 0x4 порт;
• 0x8 флаг необходимости разрешения DNS-имени;
• 0xC длина имени узла;
• 0x10 имя узла.

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

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

1. протокол прикладного уровня;
2. протокол транспортного уровня.

На прикладном уровне сообщения состоят из следующих полей:

• Заголовок FakeTLS. Состоит из 5 байт:
  • Тип записи и версия протокола (3 байта). Для клиента всегда равны 17 03 01, для сервера имеют случайные значения.
  • Длина данных без учета заголовка (2 байта).
• Содержимое сообщения:
  • Идентификатор команды (4 байта, little-endian).
  • Размер данных команды (4 байта, little-endian).
  • Идентификатор клиента (36 байт). Генерируется на основе UUID в начале работы бэкдора.
  • Данные команды.

Первые два сообщения «клиент — сервер» и «сервер — клиент» имеют идентификаторы команд 0x65 и 0x64 соответственно и содержат данные, на основе которых будут сгенерированы сессионные ключи клиента и сервера. Алгоритм генерации ключей подробно описан в отчете Zscaler. Для всех последующих сообщений, содержимое (без учета FakeTLS-заголовка) передается зашифрованным соответствующим сессионным ключом. В качестве алгоритма шифрования используется AES-128.

Протокол транспортного уровня зависит от типа соединения, указанного в конфигурации. Поддерживается четыре протокола:

1. Стандартное соединение по TCP.

   Сообщения прикладного уровня передаются без изменений как TCP-сегменты.

2. Аналог HTTP Long Polling.

   Клиент создает два TCP-соединения. Первое будет использоваться для получения пакетов с сервера, второе ― для отправки.

   • В первом соединении отправляется GET-запрос на контрольный сервер. Сервер отвечает заголовками с кодом 200 и Content-Length: 524288000. Дальнейший поток сообщений прикладного уровня в направлении «сервер — клиент» передается как тело HTTP-ответа.

     

   • После получения корректных заголовков ответа устанавливается второе соединение на тот же порт, в котором выполняется POST-запрос. Заголовок dCy генерируется клиентом на основе UUID и, по всей видимости, является идентификатором сессии, связывающим два соединения. После получения ответа с кодом 200 дальнейшие сообщения «клиент — сервер» будут передаваться с помощью отдельных POST-запросов.

     

3. Перехват сокета с TLS-соединением.

   Клиент устанавливает TCP-соединение и отправляет HTTPS-запрос следующего вида:

   GET /msdn.cpp HTTP/1.1
   Connection: Keep-Alive
   User-Agent: WinHTTP/1.1
   Content-Length: 4294967295
   Host: 149.28.152[.]196

   После этого HTTPS-соединение больше не используется, и дальнейший обмен сообщениями происходит в исходном TCP-соединении (без TLS-шифрования). Последующее общение между клиентом и сервером происходит по протоколу 1, за исключением того, что в начале сессии клиент отправляет два пакета с FakeTLS-заголовком, который начинается с последовательности 17 03 01. Первый из них всегда имеет длину 0, второй — длину 0x3A, 0x3C, 0x3E или 0x40 и содержит случайные байты. Назначение этих пакетов нам установить не удалось.

   

4. Протокол KCP.

   Данный протокол может быть реализован поверх любого другого протокола (в частности, UDP) и позволяет получить на его основе быструю и надежную передачу данных. Клиент Crosswalk использует KCP поверх TCP-соединения: к сообщениям прикладного уровня добавляются данные протокола KCP, которые затем отправляются как TCP-сегменты.

   

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

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

2. Загрузчики и инжекторы

Исследование сетевой инфраструктуры и мониторинг новых образцов Crosswalk привели нас к выявлению других вредоносных объектов, содержащих в себе шеллкод Crosswalk в качестве основной нагрузки. Все эти объекты можно условно разделить на две группы ― загрузчики локального шеллкода и его инжекторы. В обоих группах часть образцов дополнительно обфусцирована с помощью VMProtect.

2.1 Инжекторы

Инжекторы содержат в себе типичный код, который получает право SeDebugPrivilege, находит PID требуемого процесса и внедряет в него шеллкод. В качестве целевых процессов в разных экземплярах выступают explorer.exe и winlogon.exe.

Обнаруженные нами экземпляры содержат один из трех вариантов полезной нагрузки:

• Crosswalk,
• Metasploit stager,
• FunnySwitch (будет рассмотрен ниже).

Шеллкод Crosswalk и FunnySwitch находится в секции данных «as is», в экземплярах с Metasploit применяется дополнительное шифрование с помощью XOR с ключом jj1.

2.2 Загрузчики локального шеллкода

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

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

После нахождения требуемых API-функций происходит расшифровка строки Global\0EluZTRM3Kye4Hv65IGfoaX9sSP7VA с помощью алгоритма ChaCha20. В одной из более старых версий загрузчик для исключения повторного запуска создает мьютекс с именем Global\5hJ4YfUoyHlwVMnS1qZkd2tEmz7GPbB. Однако в актуальных экземплярах расшифрованная строка никак не используется — вероятно, в процессе развития часть кода была случайно удалена.

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

В случае автономных загрузчиков шеллкод находится в overlay PE-файла. Интересной особенностью является специфический формат его хранения: данные начинаются с 0x60 байт заголовка, за которыми следует сам шеллкод в зашифрованном виде. Длина данных хранится по смещению -0x24 относительно конца исполняемого файла. Заголовок, в свою очередь, всегда начинается с сигнатуры PL. Остальные данные заголовка используются для дешифровки: по смещению 0x28 располагается 32-байтный ключ, по смещению 0x50 ― 12 байт nonce для алгоритма ChaCha20.

Реализация ChaCha20 присутствует не всегда: часть экземпляров использует для шифрования Microsoft CryptoAPI с алгоритмом AES-128-CBC. Ключевая информация в этом случае также находится в структуре PL-шеллкода: по смещению 0x28 расположены 32 байта, которые хешируются с помощью MD5 для получения криптоключа.

Более старые версии загрузчиков аналогичным образом используют Cryptography API: Next Generation (функции BCrypt*). В качестве алгоритма шифрования в них выступает AES-128 в режиме CFB.

Загрузчики, работающие с внешними файлами, имеют аналогичную структуру кода и два варианта шифрования ― ChaCha20 или AES-128-CBC. Файл должен содержать PL-шеллкод такого же формата, как и в случае автономного загрузчика. Его имя зависит от конкретного экземпляра и зашифровано используемым в нем алгоритмом. Оно может содержать как полный (таких образцов мы не выявили), так и относительный путь к файлу.

Среди всех загрузчиков мы встретили три различных варианта шеллкода-нагрузки:

• Crosswalk,
• Metasploit stager,
• Cobalt Strike Beacon.

2.3 Примеры атак

2.3.1 Зашифрованное резюме

Вредоносный файл представляет собой RAR-архив electronic_resume.pdf.rar (025e053e329f7e5e930cc5aa8492a76e6bc61d5769aa614ec66088943bf77596) с двумя файлами:

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

Файл Электронный читатель резюме.exe является исполняемым и представляет собой автономный загрузчик PL-шеллкода. В качестве полезной нагрузки в нем используется Cobalt Strike Beacon.

Архив распространялся ориентировочно 1 июня 2020 г. с IP-адреса 66.42.48[.]186 и был доступен по ссылке hxxp://66.42.48[.]186:65500/electronic_resume.pdf.rar. Тот же IP использовался в качестве контрольного сервера.

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

2.3.2 I can't breathe

Атака практически идентична предыдущей: вредоносное ПО распространяется в RAR-архиве video.rar (fc5c9c93781fbbac25d185ec8f920170503ec1eddfc623d2285a05d05d5552dc) и состоит из двух файлов .exe. Архив доступен 1 июня на том же самом сервере по адресу hxxp://66.42.48[.]186:65500/video.rar.

Исполняемые файлы являются автономными загрузчиками PL-шеллкода Cobalt Strike Beacon с аналогичной конфигурацией и тем же управляющим сервером.

Интересна тема, использованная в качестве приманки: хакеры эксплуатировали протесты в США, связанные с гибелью Джоржа Флойда. Основной приманкой являлось видео с названием «I can't breathe-America's Black Death protests that the riots continue to escalate and ignite America!.mp4» ― репортаж о ситуации вокруг протестов в последних числах мая. Источник видео, судя по логотипу ― австралийский портал XKb, выпускающий новости на китайском языке.

2.3.3 Запись чата

Архив запись чата.7z (e0b675302efc8c94e94b400a67bc627889bfdebb4f4dffdd68fdbc61d4cd03ae) с тремя одинаковыми исполняемыми файлами, имеющими имена вида «запись чата-1.png____________________________________.exe», — атака вновь направлена на русскоговорящих пользователей.

Вредоносные файлы представляют собой автономные загрузчики PL-шеллкода, однако в качестве него в данном случае выступает Crosswalk версии 2.0.

Его конфигурация предусматривает три варианта подключения к управляющему серверу 149.28.23[.]32:

• транспортный протокол 3, порт 8443;

• транспортный протокол 2, порт 80;

• транспортный протокол 1, порт 8080.

3. Атаки на российских разработчиков игр

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

3.1 Unity3D Game Developer from Saint Petersburg

Основа атаки — архив Resume.rar (4d3ad3ff281a144d9a0a8ae5680f13e201ce1a6ba70e53a74510f0e41ae6a9e6), содержащий единственный файл CV.chm.

Запуск файла на системе без установленных обновлений безопасности приводит к появлению сразу двух окон: открытию CHM-справки в программе HTML Help и PDF-документа. Содержащаяся в них информация дублируется и представляет собой резюме на должность разработчика игр или менеджера баз данных в компанию в Санкт-Петербурге.

Резюме содержит правдоподобную контактную информацию: адрес в Санкт-Петербурге, email на yandex.ru, телефон с кодом +7. Подделку выдает только контактный номер: 123-45-67.

Открытие PDF-файла ― результат работы скрипта pass.js, который находится в CHM-файле и подключен на открываемую HTML-страницу.

Скрипт использует технику, позволяющую выполнить в CHM-файле произвольную команду через объект ActiveX. С ее помощью выполняется распаковка файла HTML-справки в папку C:\Users\Public, откуда запускается следующая стадия заражения — файл resume.exe, который также содержится внутри CHM.

resume.exe ― это продвинутый шеллкод-инжектор, который на момент написания этой статьи мы встретили в единственном экземпляре. Перед началом работы, как и во многих других образцах ВПО Winnti, выполняется проверка текущего года. Помимо этого, проверяются активные процессы: вредонос не будет работать при наличии запущенных процессов из списка ollydbg.exe|ProcessHacker.exe|Fiddler.exe|windbg.exe|tcpview.exe|idaq.exe|idaq64.exe|tcpdump.exe|Wireshark.exe.

При первом запуске в качестве источника шеллкода будет использован файл MyResume.pdf, при последующих ― winness.config.

MyResume.pdf распаковывается из CHM-файла и является PDF-документом, в конец которого добавлены считываемые resume.exe данные. Если пользователь откроет его напрямую, то он увидит сообщение о том, что документ защищен паролем.

Данные в сравнении с PL-шеллкодом имеют более сложную структуру и содержат следующее:

• ROR-13-хеш данных, начиная с байта 0x24 (0x20, 4 байта),
• nonce для алгоритма ChaCha20 (0x24, 12 байт),
• данные, зашифрованные ChaCha20 (0x30):
  • имя PDF-файла (+0x0);
  • размер PDF-файла (+0x20);
  • размер вспомогательного шеллкода (+0x24);
  • размер основного шеллкода (+0x28);
  • константа 0xE839E900 (+0x2C);
  • PDF-файл;
  • вспомогательный шеллкод;
  • основной шеллкод.

При первом запуске resume.exe зашифрованная часть данных расшифровывается (ключ зашит в исполняемом файле), и из нее извлекаются три блока (PDF, вспомогательный и основной шеллкод). PDF-файл сохраняется во временной папке под именем вида _797918755_true.pdf и открывается для пользователя (см. второе окно, помимо HTML Help, на рис. 26).

Полезная нагрузка запускается в новом процессе %windir%\System32\spoolsv.exe, в который внедряется основной шеллкод ― Cobalt Strike Beacon с C2 149.28.84[.]98.

Процесс его инжектирования заключается в создании секции с помощью вызова ZwCreateSection, получения доступа к ней из исходного и дочернего процессов через вызовы ZwMapViewOfSection, копирования шеллкода в секцию и помещения в точку входа spoolsv.exe прыжка на шеллкод.

Для дальнейшего закрепления в системе в папку %appdata%\Microsoft\AddIns\
копируется resume.exe (под именем winness.exe), а основной шеллкод перешифровывается и сохраняется туда же под именем winness.config. Для обеспечения автозапуска используется вспомогательный шеллкод, задача которого записать в папку автозагрузки файл svchost.bat, передающий управление на winness.exe. Чтобы максимально избежать детектирования на этом этапе, вспомогательный шеллкод аналогичным образом инжектируется в spoolsv.exe, самостоятельно загружает необходимые функции, а запись в файл выполняет в отдельном потоке.

При запуске winness.exe после перезагрузки основной шеллкод будет расшифрован из файла winness.config и точно так же внедрен в spoolsv.exe.

3.2 HFS с продолжением

23 июня 2020, исследуя сетевую инфраструктуру Winnti, мы обнаружили на одном из управляющих серверов активный HttpFileServer. На нем в свободном доступе были размещены четыре изображения: иконка письма, скриншот из игры с русским текстом, скриншот сайта компании — разработчика игры, а также скриншот информации об уязвимости CVE-2020-0796 с сайта Microsoft.

Скриншоты были связаны с компанией Battlestate Games из Санкт-Петербурга — разработчиком игры Escape from Tarkov.

Спустя почти два месяца, 20 августа 2020, на VirusTotal был загружен файл CV.pdf____________________________________________________________.exe (e886caba3fea000a7de8948c4de0f9b5857f0baef6cf905a2c53641dbbc0277c), который является автономным загрузчиком PL-шеллкода Cobalt Strike Beacon.

Интерес представляет его управляющий сервер: update.facebookdocs[.]com.

Мы обнаружили, что на основном домене facebookdocs[.]com была размещена копия официального сайта компании Battlestate Games: www.battlestategames.com. Через связаный с C2 IP-адрес 108.61.214[.]194 можно выйти на аналогичную страницу на фишинговом домене www.battllestategames[.]com (буква l удвоена).

Подобные домены, использованные в качестве С2-серверов, дают атакующим возможность замаскировать трафик ВПО под легитимную активность изнутри компании.

Сочетание двух описанных находок позволяет нам предположить, что мы зафиксировали следы подготовки и дальнейшей успешной реализации атаки на Battlestate Games.

Более того, совпадение вакансии Unity3D-разработчика (со скриншота официального сайта) и содержания резюме из файла CV.chm (см. предыдущий раздел) с учетом близости по времени, а также расположения компании и соискателя в Санкт-Петербурге — все это дает возможность предположить наличие связи между этими атаками. Вероятно, атака с CHM-файлом была использована на начальном этапе проникновения в компанию ― однако надежных подтверждений этому у нас нет.

Техника использования доменов, имеющих минимальные отличия от оригинальных, в качестве управляющих серверов, характерна для Winnti и была описана в отчете Kaspersky.

По результатам исследования вся известная нам информация о предполагаемой атаке была передана в Battlestate Games.

4. Похищенный сертификат

Другая техника, постоянно используемая группой Winnti, ― похищение сертификатов подписи кода (Code Signing). Скомпрометированные сертификаты используются для подписи вредоносных файлов, используемых в последующих атаках.

Мы выявили один из таких сертификатов, принадлежащий тайваньской компании Zealot Digital:

Name:           ZEALOT DIGITAL INTERNATIONAL CORPORATION
Issuer:         GlobalSign CodeSigning CA - SHA256 - G2
Valid From:     07:43 AM 08/20/2015
Valid To:       07:43 AM 09/19/2016
Valid Usage:    Code Signing
Algorithm:      sha256RSA
Thumbprint:     91e256ac753efe79927db468a5fa60cb8a835ba5
Serial Number:  112195a147c06211d2c4b82b627e3d07bf09

Подписанные им файлы преимущественно использовались в атаках на организации в Гонконге. Среди них — инжекторы Crosswalk и Metasploit, утилита juicy-potato, экземпляры FunnySwitch и ShadowPad.

5. FunnySwitch

Среди файлов, подписанных сертификатом Zealot Digital, мы обнаружили два экземпляра вредоносного ПО, содержащего ранее неизвестный бэкдор. Мы назвали его FunnySwitch ― по имени библиотеки и одного из ключевых классов. Бэкдор написан на .NET, имеет функциональность отправки сведений о системе и исполнения произвольного кода на JScript, поддерживает шесть различных видов соединения, включая возможность принимать входящие подключения. Одной из ключевых его особенностей является способность выступать в качестве маршрутизатора сообщений между разными экземплярами бэкдора и управляющим сервером.

5.1 Распаковка

Обнаруженная атака начинается с SFX-архива x32.exe (2063fae36db936de23eb728bcf3f8a5572f83645786c2a0a5529c71d8447a9af).

Архив распаковывает в папку c:\programdata три файла: 1.vbs, n3.exe и p3.exe, после чего извлеченный VBS-скрипт запускает оба исполняемых файла.

Файлы n3.exe и p3.exe идентичны и являются инжекторами шеллкода в процесс explorer.exe. В них различаются лишь последние байты внедряемого шеллкода, в которых находится XML-конфигурация. В одном случае там дополнительно указан прокси-сервер 168.106.1[.]1:

<?xml version="1.0" encoding="utf-8"?>
<Config Group="aa" Password="test" StartTime="0" EndTime="24" WeekDays="0,1,2,3,4,5,6">
    <HttpConnector url="http://db311secsd.kasprsky[.]info/config/" proxy="http://168.106.1[.]1/" interval="30-60"/>
</Config>
<?xml version="1.0" encoding="utf-8"?>
<Config Group="aa" Password="test" StartTime="0" EndTime="24" WeekDays="0,1,2,3,4,5,6">
    <HttpConnector url="http://db311secsd.kasprsky[.]info/config/" interval="30-60"/>
</Config>

В качестве домена C2 выступает поддомен kasprsky[.]info, db311secsd.kasprsky[.]info. Интересно, что несколько других его поддоменов упоминает в своем отчете ФБР. Он датирован 21 мая 2020 года и предупреждает об атаках на организации, связанные с исследованиями по COVID-19.

Задача шеллкода ― запустить на исполнение метод из .NET-сборки, которая расположена сразу после его кода. Для этого он получает ссылку на интерфейс ICorRuntimeHost, с его помощью запускает CLR и создает объект типа AppDomain. В созданный домен загружается содержимое сборки, после чего с помощью рефлексии запускается статический метод Funny.Core.Run(xml_config), которому передается XML-конфигурация.

Загружаемая сборка представляет собой библиотеку Funny.dll, обфусцированную с помощью протектора ConfuserEx.

5.2 Funny.dll

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

• Debug ― флаг, включающий отладочное логирование;
• Group ― произвольная строка, отправляемая вместе с информацией о системе;
• Password ― ключ шифрования сообщений;
• ID ― идентификатор маршрутизатора (при отсутствии в конфиге заменяется сгенерированным GUID);
• StartTime, EndTime, WeekDays ― ограничения времени работы бэкдора по времени суток и дням недели.

Внутри элемента <Config> может содержаться произвольное число элементов, описывающих коннекторы разного типа:

• TcpConnector, TcpBindConnector ― классы, отвечающие за соединение по TCP в качестве клиента и сервера.

  Имеют 2 общих параметра ― address и port (38001 по умолчанию). Для TcpConnector также настраивается параметр interval, указывающий время ожидания перед попыткой повторного подключения.

• HttpConnector, HttpBindConnector ― HTTP-клиент с возможностью работы через прокси- и HTTP-сервер.

  Возможные параметры клиента: url ― адрес для подключения, interval ― то же, что и у TcpConnector, proxy и cred ― адрес и авторизационные данные прокси-сервера. Параметры сервера: url ― список префиксов, на которых он будет запущен, и timeout ― клиентский тайм-аут.

  В качестве реализаций клиента и сервера используются стандартные классы HttpWebRequest и HttpListener из .NET Framework. При этом поддерживается как HTTP-, так и HTTPS-протокол: если для порта, на котором запускается сервер, не сконфигурирован SSL-сертификат, то он будет выпущен с CN = Environment.MachineName + ".local.domain". Клиент, в свою очередь, игнорирует валидацию сертификата.

• RPCConnector, RPCBindConnector ― классы, позволяющие организовать соединение через Named Pipe. Имеют единственный параметр ― name, имя создаваемого канала.

TcpBindConnector и HttpBindConnector поддерживают одновременное подключение нескольких клиентов.

Для работы сетевых коннекторов бэкдор добавляет разрешающие правила Windows Firewall с именем «Core Networking ― IPv4» для своего исполняемого модуля.

Также, как и в случае Crosswalk, можно говорить о нескольких уровнях протокола: в данном случае о транспортном, сетевом и прикладном.

5.2.1 Транспортные протоколы

1. TCP.

   Поддерживает три типа сообщений: PingMessage (0x1), PongMessage (0x2), DataMessage (0x3). Первые два отвечают за контроль соединения и актуальны только на уровне TcpConnector/TcpBindConnector. DataMessage содержит данные сетевого уровня.

   Сообщения состоят из сигнатуры (4 байта), зашифрованного заголовка (16 байт) и опциональных данных.

   Сигнатура представляет собой три случайных байта, за которыми следует их сумма по модулю 256. Входящие сообщения с некорректной сигнатурой отбрасываются.

   Заголовок содержит в себе размер данных (4 байта) и байт с типом сообщения (0x1 / 0x2 / 0x3).

   Для его шифрования применяется AES-256-CBC, в качестве криптоключа и IV используется MD5 от ключевой строки. Такой способ шифрования бэкдор использует и в других случаях, далее мы будем называть его стандартным. В данном случае в качестве ключевой строки выступает tcp_encrypted.

   

2. HTTP с long polling.

   Имеет три вида запросов: GET "connect", GET "pull", POST "push". Для начала передачи данных клиент должен выполнить операцию "connect": отправить GET-запрос на URL из конфигурации, указав специальное значение сookie.

   В качестве имени cookie используется восемь случайных символов, в качестве значения ― зашифрованная строка в виде Base64, содержащая GUID сессии и название операции (connect). Строка шифруется стандартным образом с ключом http.

   Дальнейшее взаимодействие заключается в постоянной отправке GET-запросов с операцией pull, в ответ на которые сервер возвращает актуальный массив сообщений для клиента, либо пустой ответ, если за 10 секунд новых сообщений не появилось. Сообщения «клиент — сервер» также периодически отправляются массивом, для этого используется POST-запрос с операцией push.

   

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

3. RPC (Pipe).

   Аналогичен TCP, за исключением отсутствия контроля соединения.

5.2.2 Протокол сетевого уровня

Все сообщения на этом уровне зашифрованы стандартным для бэкдора образом с ключевой строкой «commonkey».

Сообщения представляют собой массив из 3 или 4 элементов:

• тип сообщения ("hello_request", "hello_response", " message", "error");
• сериализованный массив Source;
• сериализованный массив Destination;
• полезная нагрузка (данные прикладного уровня).

Для сериализации также используется класс MsgPack. Массивы Source и Destination содержат ID маршрутизаторов, через которые уже прошло сообщение, и ID маршрутизаторов, через которые оно должно быть доставлено получателю.

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

Сообщение типа message предполагает возможность передачи через несколько маршрутизаторов: если в его поле Destination находится только ID текущего экземпляра, то оно будет обработано локально, иначе — отправлено следующему маршрутизатору в списке. Для связи со следующим экземпляром используется коннектор, который был сохранен на этапе обмена сообщениями hello_request и hello_response.

Бэкдор собирает следующую информацию о системе:

• значения ключей ProductName и CSDVersion из раздела HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion;
• разрядность ОС;
• список IP-адресов;
• имя компьютера;
• имя пользователя и рабочей группы;
• имя исполняемого модуля;
• PID процесса;
• MAC-адреса сетевых адаптеров;
• значение атрибута Group в XML-конфигурации.

5.2.3 Протокол прикладного уровня

На прикладном уровне передаваемые данные стандартно зашифрованы с помощью значения атрибута Password из конфигурации. Если оно отсутствует, в качестве ключевой строки используется test. Перед шифрованием данные сжимаются с помощью GZip.

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

5.2.4 Поддерживаемые команды

Команда	Описание
invoke	Выполнение переданного JScript-кода и возврат результата. Реализация этой задачи вынесена в отдельную .NET-сборку JSCore, которая динамически загружается из определенной в основной сборке Base64-константы. Непосредственно исполнение кода реализовано с помощью классов пространства имен Microsoft.JScript.
connect	Принимает в качестве данных XML-строку с конфигурацией коннектора и создает соответствующий объект
update	Упаковывает в ответ идентификаторы подключенных к текущему экземпляру маршрутизаторов вместе с их информацией о системе
query	Собирает конфигурацию активных экземпляров коннекторов, кроме классов типа RPCConnector и RPCBindConnector
remove	Удаляет Connector с указанным идентификатором
createStream	Создает очередь сообщений с указанным именем. Очередь связывается с отправителем команды createStream
closeStream	Удаляет очередь сообщений по ее имени
sendStream	Добавляет сообщение (массив байтов) в очередь с указанным именем

Результат исполнения всех команд возвращается отправителю командой invoke-response.

5.2.5 Неиспользуемый код

Бэкдор FunnySwitch, по всей видимости, еще находится в стадии разработки, на что указывает незавершенная функциональность работы с очередями сообщений. Помимо описанных выше команд, для работы с ними в коде есть функции PullStream и SendStream, однако они нигде не используются. Первая из них по имени очереди извлекает из нее сообщение, вторая ― отправляет ее создателю произвольный набор байт с командой stream-data.

Помимо этого, в коде присутствует еще несколько неиспользуемых классов: реализация протокола KCP, очередь ограниченного размера SizeQueue, сериализатор строк StreamString.

5.2.6 FunnySwitch vs Crosswalk

Исследование обоих бэкдоров позволяет предполагать, что они были написаны одними и теми же разработчиками. На это указывает несколько признаков:

• техника использования различных транспортных протоколов;

• возможность указания прокси-сервера;

• идентичные ограничения на время суток и дни недели в конфигурации;

• присутствие реализации протокола KCP;

• реализованное и отключенное по умолчанию логирование отладочных сообщений и ошибок.

6. ShadowPad

Во время исследования нам также удалось обнаружить два экземпляра, содержащих ВПО ShadowPad.

Первый из них представляет собой SFX-архив 20200926___Request for wedding reception.exe (03b7b511716c074e9f6ef37318638337fd7449897be999505d4a3219572829b4).

В качестве приманки он содержит документ Word на китайском языке с текстом заявки на свадебный банкет.

Содержимое архива распаковывается в папку c:\programdata, откуда затем, помимо открытия приманки, запускается полезная нагрузка log.exe.

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

В качестве log.exe выступает упакованный легитимный компонент ПО Bitdefender (386eb7aa33c76ce671d6685f79512597f1fab28ea46c8ec7d89e58340081e2bd). В процессе своей работы он динамически загружает библиотеку log.dll.

Библиотека, в свою очередь, в момент загрузки проверяет наличие в текущем модуле определенного набора байт по смещению 0x2775. Если загружающий модуль удовлетворяет ее ожиданиям, то найденные байты меняются на инструкцию call, вызывающую функцию из DLL. В результате в log.exe сразу же после загрузки log.dll выполняется вызов функции sub_100010D0 из этой библиотеки. Вызываемая функция при этом явно не экспортируется.

Аналогичная техника была ранее описана ESET в связи с атаками группы Winnti на университеты Гонконга. В качестве полезной нагрузки в этих атаках использовалось ВПО ShadowPad.

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

Помимо этого, для запутывания потока управления в коде используются никогда не выполняющиеся условные переходы вида:

cmp     esp, 3181h
jb      loc_1000BCA9

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

Данные хранятся в кусте с именем вида (HKLM|HKCU)\Software\Classes\CLSID\{%8.8x-%4.4x-%4.4x-%8.8x%8.8x} по ключу %8.8X. Значения, подставляемые в форматные строки, генерируются на основе поля TimeDateStamp в PE-заголовке log.dll и поэтому всегда одинаковы для данного экземпляра библиотеки. В нашем случае они равны, соответственно, {56a36bd2-5e2b-20b0-96f2cb9bb3f43475} и EB5D1182.

Загружаемая полезная нагрузка представляет собой шеллкод ShadowPad, обфусцированный с использованием тех же техник (rel_jmp + fake-jb). В его зашифрованной конфигурации хранятся следующие строки:

6/30/2020 1:25:52 PM
ccc
%ProgramData%\
msdn.exe
log.dll
log.dll.dat
WMNetworkSvc
WMNetworkSvc
WMNetworkSvc
SOFTWARE\Microsoft\Windows\CurrentVersion\Run
WMSVC
%ProgramFiles%\Windows Media Player\wmplayer.exe
%windir%\system32\svchost.exe
%windir%\system32\winlogon.exe
%windir%\explorer.exe
TCP://cigy2jft92.kasprsky.info:443
UDP://cigy2jft92.kasprsky.info:53
SOCKS4
SOCKS4
SOCKS5
SOCKS5

Среди них ― вероятная дата сборки модуля (30.06.2020), имя сервиса, через который ВПО закрепляется в системе (WMNetworkSvc), имена процессов, в которые может быть инжектирован шеллкод, домен C2 cigy2jft92.kasprsky[.]info.

Мы уже писали выше, что другой поддомен kasprsky[.]info использовался злоумышленниками в качестве управляющего сервера FunnySwitch. Исследование поддоменов и IP-адресов приводит к еще одному домену второго уровня ― livehost[.]live, поддомен которого d89o0gm35t.livehost[.]live, в свою очередь, указан как C2 в одном из экземпляров Crosswalk (86100e3efa14a6805a33b2ed24234ac73e094c84cf4282426192607fb8810961). Более того, все экземпляры этих бэкдоров подписаны похищенным сертификатом Zealot Digital и, вероятно, использовались совместно в одной кампании.

Это не единственный пример связи сетевой инфраструктуры Crosswalk и ShadowPad. Два выявленных нами C2-сервера Crosswalk, 103.248.21[.]134 и 103.248.21[.]179, содержали SSL-сертификат с SHA-1 b1d749a8883ac9860c45986e2ffe370feb3d9ab6. Тот же сертификат был замечен на IP 103.4.29[.]167, который через домен update.ilastname[.]com использовался в качестве управляющего сервера в другом экземпляре ShadowPad (37be65842e3fc72a5ceccdc3d7784a96d3ca6c693d84ed99501f303637f9301a).

7. PlugX

SSL-сертификат привел нас к еще одному контрольному серверу с доменом ns.mircosoftbox[.]com.

Мы обнаружили, что данный C2 используется интересным экземпляром бэкдора PlugX. Его начальная стадия типична для PlugX ― это SFX-архив (ccdb8e0162796efe19128c0bac78478fd1ff2dc3382aed0c19b0f4bd99a31efc), содержащий библиотеку mapistub.dll, которая подгружается легитимным исполняемым файлом.

Однако mapistub.dll является лишь загрузчиком. В качестве хранилища полезной нагрузки выступает Google Docs: библиотека отправляет запрос на экспорт определенного документа в формате TXT, декодирует его в шеллкод с помощью Base64, а затем исполняет.

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

Более подробно этот процесс и дальнейшая работа подобного образца описаны в недавнем отчете компании «Доктор Веб» (см. разделы «Шелл-код QuickHeal» и «BackDoor.PlugX.28»).

Помимо зафиксированных в конфигурации контрольных серверов 103.79.76[.]205 и ns.mircosoftbox[.]com в нашем случае используется стандартная для PlugX техника получения контрольного сервера по заданному URL. Адрес C2 кодируется в теле страницы между маркерами DZKS и DZJS.

В качестве URL вновь используется адрес документа Google Docs.

Стоит отметить, что документ доступен для редактирования без авторизации. Однако в момент нашего первого обращения он содержал IP 107.174.45[.]134, который связан с доменом dc-d68d34331440.mircosoftbox[.]com и, очевидно, был установлен злоумышленниками.

Аналогичная техника использовалась Winnti и ранее: по данным Trend Micro, в 2017 году кодированный адрес C2 сохранялся в репозиториях на GitHub.

7.1 Paranoid PlugX

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

Он также представляет из себя SFX-архив (94ea23e7f53cb9111dd61fe1a1cbb79b8bbabd2d37ed6bfa67ba2a437cfd5e92), но с другим набором файлов.

Архив при распаковке запускает скрипт 1.vbs, который, в свою очередь, передает управление a.bat.

Основная запускаемая нагрузка находится в файле image.jpg, который является специально подготовленной .NET-сборкой. Сборка запускается с помощью утилиты InstallUtil.exe из поставки .NET Framework, что позволяет обойти ограничения на белые списки приложений.

Цель image.jpg ― запустить с помощью CreateThread тот самый шеллкод PlugX.

В его конфигурации содержатся два C2-сервера: update.upgradsource[.]com и ns.upgradsource[.]com.

Домен upgradsource[.]com упоминается в отчете Unit42 о группе схожих образцов, названных Paranoid PlugX. Такое название они получили из-за наличия скрипта, ответственного за удаление следов присутствия ВПО в системе. Сравнение нашего экземпляра с описанными в отчете позволяет определенно говорить о том, что данный экземпляр также относится к этой группе (в частности, практически совпадает структура модуля .NET Wrapper ― image.jpg, а также существенная часть скрипта очистки a.bat).

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

Домен update.upgradsource[.]com в конце 2017 года разрешался в IP-адрес 121.170.185[.]183. Позднее в этот же IP разрешались адреса update.byeserver[.]com и update.serverbye[.]com. Домены второго уровня byeserver[.]com и serverbye[.]com, в свою очередь, приводит FireEye в своем отчете об APT41.

8. Заключение

Группа Winnti имеет в своем арсенале широкий инструментарий вредоносного ПО, которое активно использует в своих атаках. Группа применяет как массовые инструменты, такие как Metasploit, Cobalt Strike, PlugX, так и собственные разработки, список которых постоянно пополняется. В частности, не позднее мая 2020 года группа начала использовать свой новый бэкдор ― FunnySwitch, обладающий нетипичной функциональностью по маршрутизации сообщений.

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

Группу Winnti продолжают интересовать разработчики и издатели игр ― в том числе и в России. Небольшие студии, как правило, не уделяют должного внимания информационной безопасности, что делает их привлекательной мишенью для хакеров. Атаки на разработчиков ПО, в свою очередь, особенно опасны угрозой заражения конечных пользователей ― как это уже произошло в известных случаях с CCleaner и ASUS. Своевременное выявление и расследование инцидентов проникновения в компанию позволяет предотвратить подобный сценарий.

9. Вердикты наших продуктов

9.1 PT Sandbox

• Trojan-Dropper.Win32.Higaisa.a
• Backdoor.Win32.CobaltStrike.a
• Trojan-Dropper.Win32.Winnti.a
• Trojan-Dropper.Win32.Winnti.b
• Trojan-Dropper.Win32.Shadowpad.a
• Backdoor.Win32.Shadowpad.c
• Backdoor.Win32.FunnySwitch.a

9.2 PT Network Attack Discovery

• REMOTE [PTsecurity] Crosswalk

  sid: 10006001;10006002;10006003;10006004;

• SHELL [PTsecurity] Metasploit/Meterpreter

  sid: 10003751;10003753;10003754;10003755;10006172;10002588;

• REMOTE [PTsecurity] Cobalt Strike Beacon Observed

  sid: 10000748;10005757;

• REMOTE [PTsecurity] Cobalt Strike (jquery profile)

  sid:10005754;

• REMOTE [PTsecurity] FunnySwitch

  sid: 11004815;1004814;11004813;11004812;

• SPYWARE [PTsecurity] ShadowPad

  sid: 10005851;10005852;10005854;

• REMOTE [PTsecurity] PlugX

  sid: 10001390;10001391;10002946;10004422;10004426;10004472;10004473;10004515;10004532;10005968;

10. Приложения

10.1 Выявленные имена файлов, из которых может загружаться PL-шеллкод

C_99401.NLS
DriverStatics.ax
DrtmAuth005.bin
DrtmAuth13.bin
FINTCACHE.DAT
SEService.dat
Theme.re
WspTst.xsl
cbdhsvcs.bin
chrome_proxy.dll
config.ini
localsvc.ax
log.txt
msdsm.tlb
normnfa.nls
normnfw.nls
services.bin
soundsvc.sys
storesync.dat
storesyncsvc.ini
svchosl.bin
svchost.bin
wbemcomn64.sys
wbemcomna.dat
winness.exe.config
winupdate.txt

10.2 IOCs

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

Атаки с LNK-файлами

Шеллкод-инжекторы

Payload: Crosswalk

Payload: Metasploit

Автономные загрузчики PL-шеллкода

Payload: Crosswalk

Payload: Metasploit

Payload: Cobalt Strike BEACON

Загрузчики внешнего PL-шеллкода

PL-шеллкод: Metasploit

PL-шеллкод: Cobalt Strike BEACON

Атака с CHM-файлом

FunnySwitch

ShadowPad

PlugX

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

Атаки с LNK-файлами

www.comcleanner[.]info

45.76.6[.]149

http://zeplin.atwebpages[.]com/inter.php

http://goodhk.azurewebsites[.]net/inter.php

http://sixindent.epizy[.]com/inter.php

Шеллкод-инжекторы

6q4qp9trwi.dnslookup[.]services

d89o0gm34t.livehost[.]live

d89o0gm35t.livehost[.]live

168.106.1[.]1

149.28.152[.]196

207.148.99[.]56

149.28.84[.]98

Шеллкод-загрузчики

exchange.dumb1[.]com

microsoftbooks.dynamic-dns[.]net

microsoftdocs.dns05[.]com

ns.microsoftdocs.dns05[.]com

ns1.dns-dropbox[.]com

ns2.dns-dropbox[.]com

ns1.microsoftsonline[.]net

ns2.microsoftsonline[.]net

ns3.mlcrosoft[.]site

onenote.dns05[.]com

service.dns22[.]ml

update.facebookdocs[.]com

104.224.169[.]214

107.182.24[.]70

107.182.24[.]70

149.248.8[.]134

149.28.23[.]32

176.122.162[.]149

45.76.75[.]219

66.42.103[.]222

66.42.107[.]133

66.42.48[.]186

66.98.126[.]203

FunnySwitch

7hln9yr3y6.symantecupd[.]com

db311secsd.kasprsky[.]info

doc.goog1eweb[.]com

ShadowPad

cigy2jft92.kasprsky[.]info

update.ilastname[.]com

PlugX

ns.mircosoftbox[.]com

ns.upgradsource[.]com

update.upgradsource[.]com

103.79.76[.]205

107.174.45[.]134

10.3 MITRE