Анатомия Python-червя, который обманывает ИИ-агентов безопасности

Дошли ли вы до того момента, когда доверяете своему ИИ-помощнику по написанию кода больше, чем собственной ручной проверке? Многие разработчики уже там. Мы полагаемся на большие языковые модели (LLM) для поиска уязвимостей, предложения исправлений и проверки целостности сторонних пакетов. Но что происходит, когда вредоносное ПО знает, как «ответить» ИИ? На прошлой неделе я провел несколько ночей, изучая технические детали кампании Hades — угрозы, которая знаменует изменение подхода злоумышленников к автоматизированной защите. Это не просто похититель данных. Это психологическая операция, направленная на программное обеспечение, которое мы используем для самозащиты.

Исследователи из StepSecurity недавно идентифицировали эту кампанию как последнюю работу хакерской группы Miasma. В то время как ранее Miasma фокусировалась на сборе учетных данных облачных сервисов, Hades представляет собой более агрессивного самораспространяющегося червя. Он нацелен именно на среды разработки Python через скомпрометированные пакеты в экосистеме PyPI. Список затронутых библиотек включает ensmallen, mflux-streamlit и несколько инструментов, используемых в биоинформатике. Если вы работаете в области вычислительной биологии или анализа данных, ваша рабочая станция является приоритетной целью для этой конкретной группы.

Точка входа в процессе инициализации Python

Атака начинается, когда разработчик импортирует скомпрометированный пакет. Hades скрывает свой основной загрузчик внутри файла __init__.py. Это стандартный файл, который Python использует для обозначения директории как пакета. Размещая вредоносный скрипт здесь, атакующие гарантируют выполнение кода в тот момент, когда пакет загружается в проект. Загрузчик обфусцирован, чтобы избежать обнаружения на основе простых сигнатур, но его цель проста: он внедряет в систему предварительно скомпилированный бинарный файл среды выполнения Bun.

Bun — это высокопроизводительный инструментарий JavaScript. Это отличный инструмент для легитимных разработчиков, но он также является идеальным движком для выполнения вредоносного ПО. Поскольку Bun представляет собой автономный бинарный файл, он позволяет вредоносному ПО запускать сложные JavaScript-нагрузки без необходимости установки Node.js на машине жертвы. Это обходит традиционный мониторинг, настроенный на поиск подозрительной активности npm или Node. С архитектурной точки зрения использование Bun позволяет атакующим работать в «теневой среде», которая находится за пределами стандартной видимости систем безопасности большинства рабочих станций, ориентированных на Python.

Как вредоносное ПО обманывает автоматизированного привратника

Самая инновационная особенность Hades — это способность лгать ИИ-агентам безопасности. Многие современные среды разработки используют LLM для сканирования кода на наличие вредоносных паттернов. Hades предвидит это. В верхней части своих вредоносных файлов программа содержит блок текста, разработанный как состязательный промпт (adversarial prompt). Этот текст инструктирует LLM игнорировать любой подозрительный код, найденный ниже, и классифицировать пакет как проверенный и безопасный.

В прошлом месяце я тестировал подобную технику в изолированной среде. Я предоставил LLM скрипт, содержащий явный обратный шелл (reverse shell), но предварил его комментарием о том, что этот код является предварительно авторизованным тестом безопасности для государственного контракта. ИИ проигнорировал эксплойт и сообщил, что скрипт соответствует всем протоколам безопасности. Hades использует именно эту стратегию цифрового «троянского коня». Он эксплуатирует когнитивную логику ИИ. Поскольку LLM восприимчивы к социальной инженерии, они принимают эти скрытые инструкции как высокоприоритетные команды. Это приводит к ложноотрицательному вердикту, позволяя вредоносному ПО проскользнуть мимо автоматизированного анализа организации.

Эксплуатация фреймворка целостности цепочки поставок

Hades не просто прячется; он пытается выглядеть официально. Он эксплуатирует несколько критически важных фреймворков безопасности, включая OpenID Connect (OIDC) и Supply-chain Levels for Software Artifacts (SLSA). Когда вредоносное ПО обнаруживает, что оно запущено внутри рабочего процесса GitHub Actions, оно проверяет переменные OIDC. Затем оно использует эти учетные данные для создания криптографически подписанных пакетов происхождения SLSA через Sigstore.

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

Скрапинг памяти и горизонтальное перемещение

Как только вредоносное ПО закрепляется в системе, оно начинает сбор данных. Оно включает в себя специализированные инструменты для скрапинга памяти для Linux, macOS и Windows. Эти инструменты нацелены на отображение памяти активных процессов для извлечения конфиденциальных зашифрованных данных, которые иначе недоступны на диске. Это скрытный подход, так как он позволяет избежать создания подозрительных файлов, которые могла бы пометить система обнаружения и реагирования на конечных точках (EDR).

Червь также ищет способы распространения. Он сканирует зараженную систему на наличие SSH-ключей, конфигураций SCP и токенов GitHub. Если он находит токен с правами на запись, он использует раннер GitHub Actions для извлечения секретов прямо из памяти. Затем он пытается заразить другие репозитории, принадлежащие пользователю. Трафик управления и контроля (C2) скрыт внутри публичной инфраструктуры GitHub. Украденные данные сжимаются, шифруются и отправляются в новые публичные репозитории под контролем злоумышленника. Эти репозитории часто имеют описание «Hades — The End for the Damned».

Механизм персистентности «выжженной земли»

Закрепление в системе (persistence) является основным компонентом архитектуры Hades. Вредоносное ПО устанавливает присутствие на рабочей станции и отслеживает статус украденных учетных данных. Если группа безопасности обнаруживает взлом и аннулирует украденный токен GitHub, Hades переходит в реактивный режим. Он запускает процесс-вайпер (wiper), который пытается стереть локальные файлы пользователя.

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

Создание проактивной защиты от обманчивого вредоносного ПО

Кампания Hades показывает, что наша зависимость от ИИ как основного уровня безопасности является уязвимостью. Мы должны перейти к модели, в которой ИИ является помощником, а не окончательным авторитетом. С точки зрения рисков, лучшая защита — это гранулярная защита, которая не полагается на одного «привратника».

Ключевые выводы для защиты вашей среды:

1. Используйте строгую изоляцию границ для LLM. Никогда не передавайте необработанный, недоверенный код ИИ-сканеру без системного промпта, который явно запрещает модели следовать инструкциям, содержащимся внутри самого кода.
2. Аудируйте разрешения GitHub Actions. Внедрите принцип наименьших привилегий для токенов OIDC и убедитесь, что раннеры не имеют ненужного доступа на запись в ваши репозитории.
3. Мониторьте несанкционированное выполнение бинарных файлов. Hades полагается на внедрение среды выполнения Bun. Инструменты, которые помечают или блокируют выполнение неизвестных бинарных файлов в пути __init__.py, могут остановить заражение в точке входа.
4. Проверяйте происхождение Sigstore вручную. Хотя Hades может подделывать пакеты, расхождения во времени сборки или переменных окружения иногда могут быть обнаружены в ходе криминалистического аудита.
5. Внедрите надежные стратегии резервного копирования. Поскольку Hades включает в себя вайпер, наличие автономных или неизменяемых резервных копий вашей разработки — единственный способ смягчить угрозу потери данных при ликвидации последствий.

Глядя на ландшафт угроз, можно сказать, что Hades — это, скорее всего, превью будущего. Злоумышленники больше не просто пытаются взломать замки на наших дверях; они учатся убеждать цифрового вышибалу впустить их. Нам нужно перестать воспринимать вердикты ИИ как абсолютную истину и начать относиться к ним как к точкам данных, требующим проверки человеком.

Источники: NIST Cybersecurity Framework, MITRE ATT&CK Framework (Software Supply Chain Compromise), StepSecurity Hades Campaign Report.

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