Привет, Хабр!

На связи Евгения Устинова, старший аналитик сетевой безопасности группы компаний «Гарда». В статье хочу рассказать, как нам удалось связать инструментарий двух группировок через особенности реализации сетевых протоколов.

Отследить эволюцию инструментов группировки SilverFox – например, ПО Winos – по отпечатку процедуры сетевой коммуникации оказалось сложной задачей, поэтому я решила поделиться кейсом.

Почему считаем, что это Winos?

Разработка Winos, как и многих других инструментов удаленного управления, не стоит на месте: их функционал постоянно развивается. Актуальной версией Winos считается 4.0.

Нам удалось «поймать» новый Winos-семпл, который, используя прежнюю схему коммуникации – протокол, уже детектируемый вендорами, – применил опенсорсную реализацию протокола KCP HP-Socket. Особенности протокола я раскрою чуть позже, а сначала посмотрим, с чего начинается атака.

Делюсь хеш-суммой MD5 для семпла, в котором «сплелись» известные протоколы Winos и новая реализация KCP: MD5:518f06379ec6c5d13303b400236842c0.

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

Вектор начальной компрометации

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

Перевод заголовка письма с китайского на русский:

От: Ti. - <thedear-abuse@jtsuw.cn>

Тема: [Электронный счет] У вас есть электронный счет [Номер счета: 05751366]

Отправлено: Пн, 14 июля 2025 г., 14:05:03 +0800

Кроме того, хакеры задействуют следующие тактики социальной инженерии:

• сокрытие и подмена URL-ссылок;

• маскировка истинного типа файла;

• использование, вредоносных вложений и ссылок, а также сжатых архивов (RAR) для вложений;

• психологическая манипуляция и имитация доверенных брендов.

Первичный дроппер

Полезная нагрузка вредоносного ПО содержится в самораспаковывающемся RAR-архиве (RAR Sfx), который автоматически извлекает и запускает вредоносный код. В данном случае RAR-архив выступает в роли дроппера. Все, что нужно злоумышленнику, – это чтобы жертва отреагировала на фишинговое письмо: открыла вложение или перешла по вредоносной ссылке за очень «важным» обновлением ПО.

Что показал анализ дроппера

В ходе расследования атаки я выделила ключевые признаки компиляции, в частности, пути к PDB-файлам, оставшиеся в отладочной информации: 

D:\Projects\WinRAR\sfx\build\sfxrar32\Release\sfxrar.pdb.

Дополнительно провела проверку статическим анализатором. Результаты, которые получила, однозначно подтвердили мое исходное предположение из PDB:

• PE32

• sfx: RAR

• Compiler: EP:Microsoft Visual C/C++ (2013-2017) [EXE32]

Основные функции RAR Sfx-архива

Как только жертва запускает RAR-архив, тот в «тихом» режиме, извлекает в целевую папку зашифрованный шелл-код и инициатор. Дроппер запускает инициатор, используя параметр SETUP.

Делюсь хеш-суммой MD5 дроппера: 527f59d0ab8798f59e7638282b2130f6.

Действия инициатора (ConsoleApplica.exe)

Инициатор выполняет следующие действия.

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

• Путь к скрипту: C: Windows\Templrunme_4F116F21.vbs;

• Функция скрипта: Запуск инициатора ConsoleApplica.exе с помощью метода Run объекта WshShell.

Регистрирует задания в планировщике задач. Злоумышленники используют планировщик задач так, чтобы при входе любого пользователя в систему выполнялась команда PowerShell. Она перепроверяет наличие закрепления в задаче с именем MуApр_4F116F21. В противном случае создает скрытое задание с наивысшими привилегиями, запускающее VBS-скрипт по триггеру.

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

Запускает шелл-код. Инициатор активирует шелл-код (лоадер) из файла С:\Windows\EVAAA.bin, расшифровывая его XOR с ключом 0х58. Хотя шелл-код хранится в зашифрованном виде, он дополнительно снабжен обфусцированными вызовами сетевых функций, необходимыми для создания подключения через библиотеку ws2_32.dll. Обфускация производится за счет деления строк на части. Это частая практика на ряду с хешированием имен функций.

Хранение части важных компонентов инициатора в зашифрованном виде затрудняет обнаружение атаки методами статического анализа файлов на диске.

Лоадер, запущенный инициатором, загружает второй шелл-код (стейджер) и передает ему управление последующим этапом развертывания.

Второй шелл-код и техника загрузки основного модуля

Главная функция стейджера – загрузить, расшифровать и передать управление основному модулю ValleyRAT.

Код стейджера обладает уже значительно большей функциональностью по сравнению с лоадером. Внутри предусмотрены механизмы для обхода детектирования и реализации техники Reflective DLL Injection.

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

Динамическое разрешение АРІ. Как и в лоадере, злоумышленники применяют алгоритм слайсинга строк, чтобы скрыть вызовы функций из экспорта системных библиотек. В частности, критические имена собираются в коде посимвольно.

Приведу фрагмент машинного кода с примерами.

Сегментация строк для обхода статического анализа

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

Поиск базовых адресов модулей. Адреса системных DLL-библиотек определяются через PEB без использования импортов. Это распространенная техника обхода ASLR (Address Space Layout Randomization). Благодаря этому злоумышленники могут находить PEB через адрес GS:0x30, а через него – базовые адреса DLL, даже при включенном ASLR. Это работает, так как адрес GS:0x30 (PEB) фиксирован и не рандомизируется ASLR.

Стейджер загружает и расшифровывает основной модуль удаленного доступа (RAT). Вот хеш-сумма MD5 расшифрованного модуля: dadafc81ccf75248b1cf18c206a3e255

Основной модуль (Winos/ValleyRAT)

Хотя статические анализаторы (VirusTotal) детектируют файл основного модуля на диске, но по замыслу атакующих его не должно там оказаться. Это достигается за счет Reflective Injection.

Давайте посмотрим, что приготовили злоумышленники в сетевой части атаки.

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

1. Регистрация жертвы на командном сервере;

2. Получение конфигурации резервного канала связи;

3. Соединение по резервному каналу.

На первом этапе трафик между хостом жертвы и сервером злоумышленников шифруется и маскируется своим кастомным протоколом поверх ТСР. Далее на резервном канале в качестве транспорта используется UDP, а для контроля состояния потока – КСР. При этом для KCP-модуля применяется особая реализация процедуры «рукопожатия».

Отсутствие в протоколе KCP стандарта на установление связи или «рукопожатие» дает возможность аналитикам отслеживать различные варианты реализации процедуры и использовать их как отпечатки.

Стоит отметить, что протокол KCP находили у бэкдоров, таких как Keyplug, а также в других инструментах группировки APT41 (Winnti) еще с 2020 года. Однако в Winos мы видим его впервые. В дополнение к этому протоколу нам удалось обнаружить реализацию инкапсуляции прежнего протокола Winos в протокол WebSocket. Но в рамках этой статьи хочу рассказать исключительно об особенностях KCP.

Как уже упоминала ранее, коммуникация с резервным сервером происходит через порт 80 с помощью модифицированного KCP. Данная версия протокола получила рабочее название Gh0stKCP. Судя по коду из репозитория HP-Socket, это не что иное, как вариант реализации KCP, используемый в Winos, включая процедуру «рукопожатия» из файла ArqHelper.h.

Описание протокола ниже.

Кастомное «рукопожатие». Состоит из серии пакетов размером 12 байт, содержащих заголовок KCP (4 байта) и идентификаторы, выбранные случайным образом для каждой процедуры согласования. Это необходимо для установления уникальности клиентского и серверного потоков.

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

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

1. Клиент отправляет идентификатор своего стрима;

2. Сервер отправляет идентификатор своего стрима;

3. Клиент отправляет подтверждение, содержащее оба идентификатора.

Служебные пакеты протокола KCP (24 байта). На рисунке ниже показан пример стандартного протокола KCP.

Пакет KCP с данными Winos. Содержит стандартный KCP-заголовок пакета (24 байта) типа IKCP_CMD_PUSH и данные кастомного протокола, часть из которых зашифрована XOR с ключом 0x3A.

Учитывая, что служебная часть кастомного протокола имеет минимальный размер 56 байт, пакеты с данными за счет инкапсуляции будут иметь размер 80 байт и более.

Поля протокола KCP (24 байта), подчеркнутые на рисунке выше красным, представляют собой:

• 7e 5e 1a 00 – идентификатор стрима;

• 51 – тип пакета – IKCP_CMD_PUSH;

• 38 00 00 00 – длина сегмента данных (56 байт).

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

Если приложение захочет обменятся полезной нагрузкой в протоколе, то его данные будут расположены по смещению 80 байт от начала пакета KCP.

Полезная нагрузка. Данные в payload перед отправкой зашифровываются XOR (0x3A) и сжимаются библиотекой zLib. Затем они дополняются заголовком кастомного протокола 56 байт и упаковываются в KCP.

На рисунке выше красным выделены байты заголовка стандартного KCP-пакета, зеленым – служебные данные кастомного протокола Winos, а синим – полезная нагрузка протокола Winos.

Техники уклонения и сокрытия

Далее приведу несколько тактик и техник, которые я встретила в процессе разбора угрозы. Есть различные подходы к описанию действий хакеров. Я руководствуюсь ATT&CK MATRIX – доступной базой знаний MITRE, основанной на анализе реальных атак.

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

TA0011 Command and Control

• T1095 Non-Application Layer Protocol

• T1573 Encrypted Channel

• T1001 Data Obfuscation

• T1104 Multi-Stage Channels

Память. Для сокрытия резидентного кода от средств мониторинга процессов и модулей применялся полнофункциональный PE-лоадер/инжектор:

TA0005 Defense Evasion

• T1055.002 Portable Executable Injection

• T1620 Reflective Code Loading

Дополнительные тактики и техники. Техники и тактики, указанные ниже, были необходимы атакующим, чтобы создавать задания в планировщике задач, использовать PowerShell для выполнения команд, исполнять VBS-скрипт и собирать данные об операционной системе, пользователях и процессах для отправки на С2-сервер:

TA0003 Persistence

• T1053.005 Scheduled Task

TA0002 Execution

• T1059.001 PowerShell

• T1064 Scripting

TA0007 Discovery

• T1082 System Information Discovery

Вместо заключения

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

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

Приложение

IOC:

 Динамический анализ:

• https://app.any.run/tasks/20507ed2-a50a-469c-98f2-c930cdc93a67

• https://app.any.run/tasks/867c2780-d2ff-462a-8bf6-5903ae82de02

• https://app.any.run/tasks/f6a3615f-9d47-4b74-b9f4-aacb4849a6b7