Microsoft Threat Intelligence представляет широкий анализ атак на три среды, связанные с эксплуатацией искусственного интеллекта: шлюз LiteLLM, платформу RAGFlow для обработки документов и поиска с дополненной генерацией, а также среду Kestra для оркестрации рабочих процессов. Несмотря на различия в путях компрометации, цели почти всегда были одинаковыми: кража учетных данных, установка механизмов постоянного доступа и получение доступа к вычислительным ресурсам для их использования в добыче криптовалюты.
Важность этих трех случаев заключается в том, что злоумышленники рассматривали эти инструменты не просто как отдельные приложения, а как пункты управления, в которых сосредоточены учетные данные, соединения с поставщиками моделей, возможности выполнения команд и доступ к базам данных или контейнерам. По данным Microsoft, такая концентрация делает шлюзы ИИ, а также платформы управления и оркестрации высокоценными целями внутри корпоративных сред.
Три пути компрометации и единый характер результатов
В случае LiteLLM Microsoft с высокой степенью уверенности предполагает, что первоначальный доступ был получен путем эксплуатации открытого интерфейса шлюза. В материале упоминаются общедоступные пути эксплуатации, включая CVE-2026-42271, связанную с аутентифицированным выполнением команд в тестовых точках LiteLLM MCP stdio, а также исследовательский путь, связывающий ее с CVE-2026-48710 — уязвимостью обхода проверки заголовка host в Starlette. В затронутых конфигурациях эта комбинация может сделать удаленное выполнение команд доступным без действительных учетных данных.
После взлома вредоносная нагрузка прочитала среду главного процесса внутри контейнера, включая /proc/1/environ, в поисках ключей поставщиков моделей, главного ключа LiteLLM, строк подключения к базам данных, паролей и токенов. Затем были загружены исполняемые файлы, замаскированные под службы Linux, выполнено сканирование хоста, портов и процессов, а также подготовлена добыча криптовалюты с использованием XMRig или RandomX. Строка подключения PostgreSQL также использовалась для доступа к таблицам LiteLLM, которые могли содержать конфигурации моделей, ключи поставщиков и ключи по умолчанию, выданные прокси. Механизмы постоянного доступа включали изменение файла authorized_keys для учетной записи службы, изменение заданий cron, а также использование скрытых файлов и замаскированных имен служб.
В случае RAGFlow наблюдаемая активность была сосредоточена на перехвате учетных данных языковых моделей, которые арендаторы добавляли или изменяли. Сначала Microsoft обнаружила поведение, напоминающее запросы SSRF, затем — выполнение команд в контексте службы Flask и изменение пути запуска приложения для загрузки скрытого хука. Хук перехватывал тип поставщика, имя модели, содержимое ключа API и данные конечной точки и отправлял их наружу. В материале подчеркивается, что Microsoft не может с высокой степенью уверенности определить уязвимость, ставшую причиной выполнения; CVE-2026-45312, CVE-2026-28797, CVE-2026-24770 и CVE-2025-68700 упоминаются как возможный технический контекст, а не как подтвержденная причина этого случая.
В Kestra Microsoft с высокой степенью уверенности предполагает, что эксплуатация была связана с критической уязвимостью CVE-2026-49869, которая может позволить обойти аутентификацию, определить вредоносный рабочий процесс с использованием Process runner, а затем выполнить команды shell на рабочем узле. Этот путь использовался для доступа к сокету Docker, изучения среды контейнеров, развертывания майнера и выполнения операций по сокрытию файлов. Позднее задания рабочих процессов также применялись для получения удаленных скриптов и их непосредственного выполнения, после чего зашифрованные результаты сохранялись через интерфейс хранилища ключей Kestra.
Что практически меняется для команд защиты?
Главный вывод заключается в том, что оценка рисков должна исходить из функции среды ИИ внутри организации. Шлюз может быть хранилищем ключей поставщиков моделей и базой данных виртуальных ключей, тогда как платформа RAG может содержать конфигурации арендаторов, а движок рабочих процессов — обладать разрешениями на выполнение команд и взаимодействие с внешними службами. Поэтому недостаточно применять индикаторы обнаружения, относящиеся к каждому продукту, изолированно от остальных.
Microsoft рекомендует рассматривать шлюзы ИИ как хранилища секретов высшего уровня, обновлять LiteLLM и аналогичные инструменты, требовать аутентификацию для API и административных интерфейсов, ограничивать административные порты и не выставлять их непосредственно в интернет. Также рекомендуется использовать отдельные виртуальные ключи для каждой команды с лимитами расходов, хранить ключи поставщиков в управляемом хранилище секретов, а не в переменных среды процесса, и ротировать ключи, которые могли быть раскрыты.
К другим мерам контроля относятся применение принципа наименьших привилегий к шлюзу и базе данных, размещение базы данных за частной конечной точкой и ограниченным межсетевым экраном, а также применение правил исходящего сетевого трафика, которые по умолчанию отклоняют соединения и разрешают только необходимые конечные точки. Следует отслеживать доступ к /proc/1/environ, запуск shell, Python или инструментов загрузки из процесса шлюза, изменение cron или SSH-файлов, использование сокета Docker и выполнение из временных доступных для записи путей.
Ограничения выводов и вопросы для проверки
Три случая не доказывают, что каждое развертывание LiteLLM, RAGFlow или Kestra подвержено атакам одинаковым образом; кроме того, Microsoft четко различает подтвержденные уязвимости в некоторых сценариях и потенциальные уязвимости в случае RAGFlow. Наличие в некоторых вредоносных нагрузках признаков, указывающих на использование вспомогательных или генеративных инструментов, также не является доказательством их источника или личности разработчиков. Поэтому эти результаты следует использовать для построения гипотез обнаружения и проверки конфигураций, а не для приписывания атаки конкретной стороне.
Microsoft предоставляет запросы Advanced hunting для обнаружения цепочек поведения, таких как запуск шлюзом интерпретаторов или инструментов загрузки, чтение переменных среды главного процесса, доступ к таблицам LiteLLM, попытки загрузки модуля MSR с включенной записью, изменение ключей SSH или cron. Практическая ценность этих запросов проявляется при объединении их в единую временную шкалу: отдельный процесс shell может быть административным, но его сочетание с чтением секретов, внешним соединением и выполнением файла из временного пути значительно повышает уровень подозрительности.