Angry Spark: высокотехнологичный бэкдор с ограниченным следом, о котором мир так и не узнал

Весной 2022 года система обнаружения руткитов одного из разработчиков решений для информационной безопасности зафиксировала аномалию в процессе svchost.exe на компьютере в Великобритании. Небольшой фрагмент памяти, около 32 килобайт, совершал прямые системные вызовы NtQuerySystemInformation, обходя все пользовательские хуки. При детальном анализе дампа памяти исследователи обнаружили не просто шелл-код, а целую виртуальную машину - пользовательский интерпретатор байт-кода, исполняющий 25-килобайтную программу. Этот код динамически декодировал собственную полезную нагрузку, разрешал API через хеш-таблицы и проверял наличие гипервизора перед выполнением любой строки своего реального кода. Угроза, получившая название AngrySpark, демонстрирует парадокс современной киберразведки: иногда самые изощрённые инструменты создаются для операций с крайне узкой видимостью, что ставит под вопрос традиционные модели оценки угроз.

Описание

Специалисты назвали эту угрозу AngrySpark, обнаружив соответствующее пространство имён C++ "angry_spark" в метаданных RTTI (Run-Time Type Information) библиотеки DLL, которая её доставила. В течение последующего года с того же хоста было получено три снимка памяти, что позволило отследить эволюцию её инфраструктуры командования и управления. Однако к апрелю 2023 года соединение было заблокировано, домены и сертификаты истекли, и активность полностью прекратилась. Новых образцов или жертв обнаружено не было. Инцидент превратился в единичную вспышку в темноте, о которой не сообщил ни один публичный репозиторий вредоносного ПО. Анализ, проведённый специалистами, раскрывает архитектуру, которая возводит AngrySpark из категории хорошо сделанных бэкдоров в разряд уникальных исследовательских кейсов.

Главная особенность AngrySpark - его трёхслойная модульная архитектура, где каждый уровень изолирован. Библиотека DLL, виртуальная машина и конечный маячок (beacon) используют собственное шифрование, собственные механизмы разрешения API и собственные каналы связи с командным центром. Компрометация одного слоя оставляет два других непрозрачными для анализа. Полезная нагрузка собирается из байт-кода во время выполнения, что позволяет оператору заменять финальный бинарник, менять набор API, добавлять проверки на анализ или обновлять URL командного центра простой загрузкой нового 25-килобайтного блока данных. При этом 6,5-килобайтный загрузчик остаётся неизменным, функционируя скорее как фреймворк для развёртывания, чем как классический дроппер. Именно эта архитектура, сочетающая высокую гибкость с глубокой обфускацией, делает угрозу интересной для изучения, несмотря на её ограниченный масштаб.

Начальной точкой атаки служила библиотека DLL размером 200 КБ с именем WptsExtensions.dll - точной копией легитимной библиотеки расширений Планировщика заданий Windows. Она экспортировала те же пять функций и подделывала информацию о версии, указывая "Microsoft Corporation, v10.0.19041.1023". После загрузки своей конфигурации, хранившейся в зашифрованном виде в реестре, DLL внедряла шелл-код виртуальной машины в процесс svchost.exe. Этот код был полностью независим от позиции, имел собственный распознаватель API, обработчик исключений и диспетчер системных вызовов. Второй этап, виртуальная машина, представлял собой интерпретатор, исполнявший около 190 инструкций из конфигурационного блока. Эти инструкции управляли выделением памяти, декодированием данных, настройкой перемещений (relocations) и даже проверками на анализ, включая обнаружение гипервизора и технологии CET (Control-flow Enforcement Technology).

Собранная в результате полезная нагрузка, маячок третьей стадии, представляла собой 27-килобайтный независимый шелл-код с 74 функциями. Он реализовывал полноценный канал C2, маскируя свои проверочные запросы под HTTPS-запросы к PNG-изображениям. Собранные данные о системе - информация об ОС, уровне целостности, списке процессов, статусе гипервизора - шифровались с помощью алгоритма XXTEA, кодировались в пользовательский Base64 и передавались на сервер. В ответ сервер мог отправить зашифрованный шелл-код для выполнения на целевой машине. Особое внимание разработчики уделили скрытности и анти-анализу. Помимо прямых системных вызовов для обхода пользовательских хуков, бэкдор проверял отпечаток TLS-сертификата командного центра, отказываясь работать с подменённой инфраструктурой. Также была реализована сложная логика самоуничтожения.

Сердцевиной механизма самоочистки был "выключатель мёртвого человека". При каждом цикле связи DLL сравнивала текущее время с сохранённой меткой последнего успешного оповещения. Если разница превышала заданный в конфигурации порог (в днях), или если сервер отвечал кодом HTTP 200 вместо ожидаемого перенаправления 302, триггерировалась процедура самоуничтожения. Она включала удаление зашифрованного блока из реестра и планирование удаления файла DLL при следующей перезагрузке с помощью флага MOVEFILE_DELAY_UNTIL_REBOOT. Именно этот механизм, по всей видимости, сработал в апреле 2023 года, когда инфраструктура была заблокирована, и AngrySpark бесследно исчез с единственного известного хоста. Инфраструктура командования и управления также была выстроена с расчётом на устойчивость и незаметность, используя два независимых канала с разными доменами, IP-адресами и слоями шифрования - AES-256-CBC с RSA-4096 на одной стороне и XXTEA на другой.

Таймлайн, восстановленный по трём снимкам памяти (май и июнь 2022, январь 2023), показывает активное развитие в середине 2022 года с обновлением таблицы системных вызовов и добавлением поддержки инсайдерских сборок Windows, а затем - заморозку кода с ротацией только конфигурационных параметров и сетевых путей. Этот факт, наряду с контролируемым истечением всей инфраструктуры, указывает на оперативный, а не случайный характер прекращения деятельности. Основная загадка AngrySpark заключается в вопиющем несоответствии между затраченными инженерными усилиями и наблюдаемым масштабом воздействия. Создание VM-фреймворка, двухканального C2, сложных проверок на анализ и прямой таблицы системных вызовов требует серьёзных ресурсов. Однако всё это было развёрнуто, судя по всему, на одной машине и тихо ликвидировано через год.

Это порождает ряд вопросов, на которые у исследователей пока нет ответов. Был ли AngrySpark инструментом целевой операции, достигшей своих целей? Полевым испытанием или proof-of-concept, который решили не масштабировать? Продуктом работы подрядчика? Отсутствие образцов в публичных базах и внимания со стороны других вендоров лишь подчёркивает уникальность случая. История AngrySpark служит напоминанием, что ландшафт угроз неоднороден. Помимо массовых кампаний программ-вымогателей или шпионских программ, существуют высокотехнологичные, точечные инструменты, чей жизненный цикл может остаться полностью скрытым от глаз глобального сообщества безопасности. Их обнаружение часто является делом случая, а анализ - возможностью заглянуть в методологию разработчиков, предпочитающих оставаться в тени. Искра погасла, но инженерные решения, заложенные в код, продолжают рассказывать свою историю.