За 90 дней телеметрии, собранной с ловушек в популярных сервисах искусственного интеллекта, зафиксирована устойчивая волна атак. Злоумышленники действуют целенаправленно, подстраивая вредоносные инструменты под внутреннюю архитектуру каждого сервиса. В зону риска попадают прокси-серверы для маршрутизации запросов к нейросетям, платформы для создания AI-агентов и базы данных векторных представлений.
Описание
Инфраструктура ИИ привлекательна для атакующих по двум ключевым причинам. Первая - концентрация учетных данных. Прокси-сервер, через который приложения отправляют запросы к моделям OpenAI, Anthropic или Azure, хранит ключи доступа для всех подключенных провайдеров. Компрометация такого узла открывает доступ к облачным ресурсам и внутренним сервисам, подключенным через MCP (протокол, позволяющий агентам вызывать внешние инструменты и данные). Вторая причина - особенности AI-агентов: они созданы для выполнения инструкций из внешних запросов и потому подвержены внедрению вредоносных команд.
Как показало исследование Wiz Threat Research, наблюдаемая активность укладывается в три сценария. Первый - эксплуатация уязвимостей в MCP-серверах. Второй - слепое внедрение инструкций, при котором агент выполняет скрытые команды, а подтверждение происходит через внешние обращения. Третий - пост-эксплуатационные действия, ориентированные на похищение ключей моделей и маскировку вредоносных программ под легитимное ПО.
В рамках первого сценария атакующие использовали две уязвимости в популярном решении LiteLLM, которое часто применяется для организации единой точки доступа к различным моделям. Одна уязвимость позволяла обойти проверку подлинности в шлюзе MCP: достаточно было отправить запрос с любым коротким токеном, чтобы получить полный доступ к управлению. Вторая находилась в функции тестирования соединений с внешними серверами: поле с командой запуска передавалось в оболочку без проверки. Злоумышленники подставляли вредоносный скрипт, который загружал и запускал майнер криптовалюты, при этом тестовая проверка возвращала успешный результат, скрывая факт атаки.
Отдельно стоит отметить, что подобные уязвимости не ограничиваются LiteLLM. Любая программа, которая проверяет конфигурацию путем запуска указанной команды, может быть скомпрометирована, если её внешний интерфейс доступен злоумышленнику. Поэтому защита таких компонентов должна быть приоритетной.
Второй сценарий - слепое внедрение инструкций - эксплуатирует архитектурную особенность AI-агентов. Атакующий отправляет агенту запрос, который содержит скрытые указания выполнить системную команду. Если агент имеет доступ к инструменту запуска команд, он исполняет её и инициирует сетевое обращение к промежуточному домену под контролем злоумышленника. Это обращение служит подтверждением успешного выполнения, при этом пользователю не показывается никаких признаков вмешательства. После проверки срабатывания загрузка с вредоносным кодом извлекается с внешнего сервиса и выполняется на сервере.
Пост-эксплуатационная фаза также адаптирована под особенности ИИ-инфраструктуры. Вместо традиционного поиска файлов паролей атакующие обращаются к памяти процесса и извлекают ключи моделей. Это позволяет им либо похитить ключ для использования вне сети, либо запустить несанкционированные запросы к моделям за чужой счет - сценарий, известный как LLMjacking (перехват квот на использование моделей машинного обучения). Кроме того, проверяется, какие именно модели доступны через скомпрометированный прокси, что помогает выбрать дальнейшую тактику.
Для маскировки вредоносные программы размещаются в директориях, характерных для AI-инструментов. Например, на одном из серверов майнер был сохранен в папке, используемой для конфигурации популярного инструмента разработки, и переименован в безобидный файл. Администратор, привыкший видеть такие каталоги в окружении ИИ-серверов, может не заметить подмену.
Защита от подобных атак требует комплексного подхода. Прежде всего, необходим полный учёт всех ИИ-компонентов в облачной среде, включая управляемые и саморазмещённые сервисы. Каждый такой компонент должен рассматриваться как часть производственной инфраструктуры с собственной системой мониторинга и политикой безопасности. Поскольку многие AI-инструменты по умолчанию запускаются без аутентификации, критически важно требовать обязательную проверку подлинности для всех внешних подключений.
Дополнительно следует ограничивать сетевые маршруты между AI-сервисами и другими системами, а также контролировать аномальное поведение процессов - например, запуск оболочки из серверного приложения. Обновления безопасности нужно устанавливать без промедления, так как злоумышленники часто начинают эксплуатировать уязвимости раньше, чем появляются официальные исправления. Компаниям стоит также регулярно проводить оценку защищённости собственных AI-сервисов с использованием специализированных инструментов, имитирующих действия реальных атакующих.
Атаки на инфраструктуру искусственного интеллекта уже перестали быть гипотетической угрозой. Организации, использующие такие сервисы, должны учитывать новые риски и адаптировать свои стратегии защиты с учётом специфики ИИ-окружений.
