С марта по май исследователи Zenity зафиксировали три отдельные кампании, в которых злоумышленники использовали открытые AI-эндпоинты чужих компаний как инфраструктуру для собственных атак. Проблема неприятна именно своей банальностью: чтобы задействовать такой сервис, атакующему не нужен взлом в классическом смысле, достаточно знать адрес эндпоинта и попасть в плохо настроенный контур.
Об этом по данным Dark Reading говорится на фоне наблюдений за honeypot-инфраструктурой Zenity, где были выставлены сервисы на базе Ollama и LiteLLM. Исследователи описывают схему без лишней магии: вместо эксплуатации уязвимости оператор просто подсовывает клиенту или агенту чужой inference backend и отправляет туда собственный payload. Иначе говоря, компания поднимает AI-сервис для своих задач, а в итоге он может начать обслуживать совсем не те запросы, ради которых его запускали.
Технически речь идет об inference-эндпоинтах, которые self-hosted AI-софта открывает для приложений. В материале упоминаются, в частности, Ollama с маршрутами /api/generate и /api/chat на порту 11434, а также LiteLLM с эндпоинтом /v1/responses на порту 4000. Слабое место тут не в экзотической zero-day, а в сочетании двух старых как интернет ошибок: сервис либо торчит наружу, либо не прикрыт нормальной аутентификацией. У Ollama, по данным Zenity, встроенной аутентификации на дефолтном порту нет вовсе. У LiteLLM защита включается опционально, если администратор сам задаст master key. Более того, исследователи отдельно указывают на распространенный заглушечный ключ sk-1234, по которому злоумышленники уже ориентируются.
Самое показательное в этой истории то, как именно использовались открытые AI-эндпоинты. Первая кампания была связана с автономным пентест-фреймворком Strix. Один источник IP отправил через LiteLLM-клиент промпт объемом около 140 тыс. символов, чтобы превратить удаленный сервис в исполнительный механизм для атаки против не названного французского аукционного дома. По описанию Zenity, инструкции были вполне в духе худших практик offensive automation: агенту запрещали спрашивать разрешение, останавливаться, раскрывать имя Strix или другие идентификаторы и, если перевести без лишней цензуры, предлагали действовать максимально агрессивно. Попытку остановили сенсоры honeypot, но повторяющиеся команды на ретрай намекают, что за процессом мог следить живой оператор, а не только скрипт.
Вторая активность касалась HexStrike AI. Здесь атакующий направил desktop-клиент LLM на honeypot с Ollama и передал оркестратору набор из более чем 150 offensive-инструментов. Конкретная цель в этой попытке не фигурировала, поэтому исследователи предполагают, что оператор находился на стадии подготовки. Но даже в таком виде кейс выглядит показательно: инфраструктура компании превращается не просто в «чужую модель», а в площадку, где собирают и обкатывают агентный стек для будущей операции. Третий источник IP использовал агент OpenAI Codex, подключив его к LiteLLM-прокси honeypot. Под видом security auditor агенту поручили задачи по веб-реверсингу. Для защитников здесь важен не столько бренд инструмента, сколько шаблон: злоумышленник берет готового агента, меняет backend и переносит вычисления, промпты и tool definitions на чужую площадку.
Zenity отдельно подчеркивает, что весь «мозг» такого агента едет внутри запроса: system prompt, роль, набор инструментов, ограничения и правила поведения. Поэтому типичный паттерн атаки выглядит очень приземленно. Сначала идет короткий пробный запрос вроде «hello», чтобы проверить, отвечает ли endpoint. Если отвечает, следом приходит полноценная нагрузка с описанием персоны, инструментов и последовательности действий. Для SOC и DevSecOps это важная деталь: трафик на AI-инфраструктуру уже нельзя воспринимать как безобидные обращения к внутренней модели. Если в теле запроса внезапно приезжает полный агент с offensive-toolset, это уже не «эксперименты команды R&D», а повод быстро разбираться, кто и зачем использует ваш runtime.
В более широком контексте история неприятна тем, что она бьет по самой популярной модели внедрения GenAI в компаниях. Бизнесу нравится self-hosted стек: можно держать данные ближе к себе, не зависеть полностью от внешнего API и гибко собирать внутренние ассистенты. Но вместе с этим появляется новый слой attack surface, который часто настраивают в спешке. CTO и сооснователь Zenity Майкл Баргури в комментарии Dark Reading формулирует это без скидок: клиент отвечает за то, что сам строит и разворачивает, но вендоры тоже обязаны давать безопасные настройки по умолчанию и инструменты наблюдаемости. Иначе рынок снова получает старую песню в новой аранжировке: сначала «главное быстрее вывести AI-функцию», потом срочно закрывать то, что случайно оказалось доступно всему интернету.
Практический вывод для разработчиков и IT-руководителей здесь довольно прямой. Если backend модели можно не публиковать наружу, его не стоит публиковать. Если сервис все же должен быть доступен по сети, ему нужна не декоративная, а реальная аутентификация без дефолтных и тестовых ключей. Кроме того, имеет смысл смотреть не только на факт обращения, но и на содержимое входящих запросов: полные агентные payload, неожиданные tool definitions, обращения к моделям, которых вы у себя не хостите, и шаблоны, характерные для offensive-фреймворков. Отдельная мера, о которой говорят исследователи, это блокировка IP-адресов, замеченных в таких сценариях. Набор мер не выглядит футуристично, и в этом как раз мораль сюжета: открытые AI-эндпоинты ломают не лазером из будущего, а обычной сетевой доступностью, которую никто толком не проверил перед релизом.
Главный вопрос теперь не в том, будут ли подобные попытки повторяться, а в том, как быстро AI-команды примут простой факт: inference API уже стал такой же мишенью, как админка, VPN-шлюз или плохо прикрытый S3. Если прав Баргури и любой выставленный в интернет AI-сервис начинают щупать в течение часов, то спор о secure-by-default для LLM-стека из академического быстро превращается в операционный. Подробности исходного материала можно посмотреть в .