Шлюзы ИИ уже взламывают — ключи моделей становятся первой добычей

6 сентября 2026 г. в 02:00|Автор: Редакция QUASA|5 мин чтения

Расследование Microsoft Security Research от 26 августа 2026 года описывает три наблюдавшиеся компрометации инфраструктуры ИИ: шлюза LiteLLM, системы поиска по данным RAGFlow и оркестратора рабочих процессов Kestra. Атакующие похищали учётные данные, закреплялись в среде и в двух случаях запускали XMRig для майнинга.

Речь идёт о вторжениях в реальные развёртывания, а не о лабораторной демонстрации уязвимостей. Бюллетень Security Risk Advisors от 27 августа подтверждает общий рисунок трёх эпизодов: после проникновения злоумышленники добирались до ключей поставщиков моделей, баз данных, контейнерных секретов и механизмов выполнения команд. Пострадавшие организации, даты самих атак и возможная связь между ними не раскрыты.

Почему связующие компоненты стали центром риска

LiteLLM, RAGFlow и Kestra решают разные задачи, но каждый компонент соединяет несколько доверенных зон. Шлюз обращается к поставщикам моделей, система поиска хранит настройки моделей и источников данных, а оркестратор запускает задания внутри рабочей среды. Поэтому захват такого сервиса даёт доступ не только к одному приложению, но и к подключённым учётным данным, базам и вычислительным ресурсам.

В случае LiteLLM вредоносный код читал переменные окружения процесса и записи PostgreSQL. В распоряжении атакующих оказывались ключи поставщиков моделей, главный и виртуальные ключи LiteLLM, строка подключения к базе, параметры арендаторов и другие конфигурационные данные. Затем на узел загружались исполняемые файлы, добавлялся SSH-ключ служебной учётной записи, создавались задания cron, а отдельные файлы защищались от удаления атрибутом неизменяемости.

В RAGFlow целью стал процесс добавления поставщика модели. Атакующие изменили путь запуска приложения и внедрили Python-перехватчик в обработчик TenantLLM: вновь вводимые ключи OpenAI, Azure, Anthropic и Gemini вместе с метаданными моделей отправлялись на внешний сервер. Закладка загружалась при старте сервиса и переживала перезапуск контейнера.

В Kestra вредоносный рабочий процесс запустил командную оболочку. Через подключённый сокет Docker злоумышленники просматривали окружение работающих контейнеров, где могли находиться облачные, серверные и API-учётные данные, после чего развернули XMRig и организовали дополнительный сбор сведений через собственное хранилище ключей и значений Kestra.

Три цепочки: вход, секреты, закрепление и монетизация

Изменённый модуль RAGFlow перехватывает новый ключ поставщика модели и сохраняется после перезапуска контейнера

LiteLLM. Вероятная точка входа — доступная извне поверхность шлюза и цепочка уязвимостей. Добыча — ключи моделей, главный и виртуальные ключи, записи PostgreSQL. Закрепление — SSH, cron и защищённые от удаления файлы. Монетизация — майнинг и возможное дальнейшее использование похищенных учётных данных.
RAGFlow. Перед выполнением кода наблюдались запросы, похожие на разведку через подделку серверных запросов. Добыча — новые ключи поставщиков моделей и их метаданные. Закрепление — изменённый файл запуска и скрытый Python-модуль. Возможное последствие — несанкционированные платные запросы к моделям; запуск майнера в этом эпизоде не описан.
Kestra. Вероятная точка входа — открытая поверхность оркестратора, позволившая выполнить вредоносный процесс. Добыча — секреты из окружения контейнеров. Закрепление — работа майнера после закрытия исходной оболочки и повторный сбор через задания. Непосредственная монетизация — XMRig, подключённый к пулу Monero.

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

Точки входа удалось установить не во всех случаях

Вредоносный процесс Kestra получает секреты контейнеров через Docker и оставляет работающий XMRig

Разбор HECAVEX от 30 августа отделяет наблюдавшиеся действия от вероятных способов проникновения: для LiteLLM наиболее вероятна цепочка CVE-2026-42271 и CVE-2026-48710, для Kestra — CVE-2026-49869, а компрометацию RAGFlow не удалось связать с одной конкретной уязвимостью. В последнем случае возможная разведка через подделку серверных запросов предшествовала выполнению кода, но не доказывает точный путь первоначального доступа.

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

Что администраторам проверять в первую очередь

Проверка узла связывает запуск оболочки шлюзом ИИ, чтение секретов, изменение SSH-ключей и соединение с майнинговым пулом

Первый приоритет — убрать административные поверхности LiteLLM, RAGFlow, Kestra и сходных компонентов из прямого доступа из интернета, установить актуальные исправления и разрешить управление только через аутентифицированный сегмент. Исходящие соединения таких сервисов следует ограничить по принципу запрета по умолчанию: это затрудняет отправку секретов на произвольные адреса, связь с управляющей инфраструктурой и подключение к майнинговым пулам.

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

При поиске следов важна цепочка событий: запуск bash, sh, Python, curl или wget дочерним процессом шлюза; чтение /proc/1/environ; запросы к таблицам ключей; изменения Python-файлов приложения; новые записи в authorized_keys и cron; исполнение файлов из /tmp; доступ рабочего процесса к сокету Docker; соединения с неизвестными адресами и майнинговыми пулами. Один такой сигнал может иметь штатное объяснение, но их сочетание указывает на более широкий захват среды.

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

Масштаб атак и их исполнители пока неизвестны

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

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

Подпишитесь на рассылку

Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.