ИИ-агенты атакуют MCP-серверы: краденые ключи использовались против реальных AWS-аккаунтов

information security

В июне 2026 года автоматизированная программа за 65 шагов взломала сервер, который, как ей казалось, принадлежал аналитической компании. Она прочитала файлы с паролями, выполнила команды для побега из изолированной среды и создала учётную запись администратора с собственным SSH-ключом. К моменту завершения операции агент был уверен, что полностью контролирует производственный сервер. На самом деле сервер был приманкой (honeypot), а все найденные данные - подставными. Этот инцидент - часть масштабного эксперимента, показавшего, что ИИ-агенты активно ищут серверы, работающие по протоколу MCP (Model Context Protocol), и используют их инструменты для атак.

Описание

MCP - это интерфейс, который даёт ИИ-агенту доступ к выполнению команд, чтению файлов и получению секретов. Сервер рекламирует свои возможности, и агент может вызвать их простым запросом. За год количество таких серверов выросло с нескольких десятков до тысяч, и всё больше из них оказываются в открытом интернете без аутентификации. Протокол делает необязательным шаг с OAuth, и многие развёртывания его пропускают. Злоумышленники легко находят такие серверы с помощью сканеров, которые реагируют на характерные признаки. Из примерно тысячи источников, обратившихся к серверам-приманкам между маем и июлем 2026 года, 596 правильно использовали протокол, но не пошли дальше. Согласно данным эксперимента, 24 источника начали вызывать инструменты, а не просто устанавливать соединение.

Эти 24 агента в совокупности выполнили 628 команд в оболочке, прочитали 255 файлов и 248 раз обратились к хранилищу секретов. Девятнадцать из них целенаправленно искали учётные данные, а четыре пытались сбежать из контейнера на хост. Некоторые шли ещё дальше: создавали учётную запись с бэкдором, исследовали среду оркестрации Kubernetes. Активность нарастает: в мае было зафиксировано 39 вызовов инструментов, в июне - 693, а к середине июля число достигло 877.

Типичная сессия начиналась с ориентации. Агент запускал команды для определения пользователя, имени хоста и текущей директории. Затем он читал файлы паролей, переменные окружения, резервные копии учётных данных и ключи развёртывания. После сбора информации следовал этап закрепления. Один из агентов выполнил команду монтирования корневой файловой системы хоста внутри привилегированного контейнера, чтобы выйти за пределы изоляции, затем создал нового пользователя с правами администратора, сгенерировал SSH-ключ и добавил его в авторизованные ключи. Каждая команда возвращала успешный результат - так была настроена приманка. Со стороны агента казалось, что он полностью захватил хост.

Среди 24 источников выделились три типа поведения. Первый - "слепой переборщик": один источник сделал 330 вызовов, из них 304 за одну сессию. Он не адаптировался к ответам и методично перебирал все возможные варианты названий ключей в хранилище секретов - OPENAI_API_KEY, ANTHROPIC_API_KEY, VAULT_TOKEN во всех регистрах. Второй тип - адаптивный агент: он сначала запрашивал список всех доступных ключей, а затем брал только те, которые существовали. Это надёжный признак работы ИИ-агента, а не скрипта: он читал результат и выбирал следующий шаг на его основе. Третий тип - агент, нацеленный на всю инфраструктуру: он читал теневой файл паролей, искал все программы с повышенными привилегиями, выполнял побег из контейнера, а затем обращался к оркестрации, запрашивая список всех подов и права доступа учётной записи. Такое поведение показывает, что злоумышленник хотел не просто захватить один сервер, а понять, куда можно переместиться в кластере.

Самое опасное заключалось в том, что краденые ключи в трёх случаях были использованы против реальных AWS-аккаунтов. В приманку были намеренно встроены специальные токены-ловушки (honeytokens) - выглядящие как настоящие ключи, но срабатывающие только при их использовании. Три оператора "активировали" эти токены. Один ключ, украденный 16 июня, использовался до 30 июня: с его помощью злоумышленники получали информацию о пользователе, проверяли политики доступа, выводили списки корзин S3 и, что критично, вызывали модель через Amazon Bedrock. Другой ключ, взятый 25 июня, в тот же день был применён для проверки вызывающего и доступа к S3, после чего его перестали использовать. Третий ключ, украденный 12 июля, вызвал 55 тревог за два дня: проверка личности, перечисление сервисов IAM, доступ к Secrets Manager и S3, а затем многократные вызовы моделей Bedrock и операций Converse. Это классическое LLMjacking: злоумышленник проверяет украденный ключ, оценивает его возможности и начинает использовать его для запуска моделей за счёт жертвы.

Эксперимент показал, что разница между безобидным сканированием и реальной атакой - не в простом соединении, а в вызове инструмента. Только 24 из 596 источников дошли до этого шага. Но именно они представляют реальную угрозу. При этом активность растёт, и с каждым месяцем число таких инцидентов увеличивается в разы. Протокол MCP, упрощающий взаимодействие ИИ-агентов с данными, становится новой поверхностью атаки. Разработчикам необходимо обязательно включать аутентификацию на своих серверах, а операторам облачных инфраструктур - регулярно проверять, не используются ли их учётные данные для несанкционированного доступа к ИИ-моделям.

Индикаторы компрометации

IPv4

  • 102.210.28.96
  • 103.151.172.25
  • 107.151.158.11
  • 108.80.112.16
  • 115.84.114.84
  • 115.84.87.150
  • 139.59.226.65
  • 152.55.176.13
  • 18.144.48.123
  • 222.247.231.147
  • 23.27.175.241
  • 34.177.101.32
  • 35.222.46.242
  • 39.162.24.20
  • 51.195.191.88
  • 64.227.57.91
  • 87.249.134.130
  • 91.107.153.250
  • 91.209.48.146

Комментарии: 0