👽 AgentJacking: примеряем к AI SOC — 16 июля 2026 г. в 08:25:15.014
👽 AgentJacking: примеряем к AI SOC Недавно опубликованное исследование по атаке AgentJacking отличается от десятков других постов «как страшно жить с ИИ-агентами» тем, что авторы не побоялись опробовать свою атаку на реальных организациях. В итоге в их сети попались кодинг-агенты более чем 2000 реальных компаний, включая фирму из Fortune-100. Вся схема основана на эксплуатации популярной службы телеметрии под названием Sentry. Любое мобильное или веб-приложение может автоматически рапортовать о случившихся ошибках через Sentry, чтобы разработчики не ждали, пока пользователь (никогда не) заполнит багрепорт. При этом ошибки в Sentry отправляются без авторизации и аутентификации — это сделано специально, чтобы можно было обрабатывать в том числе типичные случаи «анонимный пользователь просто зашел на наш веб-сайт и словил ошибку». В духе свежих тенденций Sentry завели себе MCP-сервер, чтобы ИИ-агенты у их клиентов могли разбирать сообщения об ошибках автоматически. Дальше вы можете догадаться. Исследователи отправляют в Sentry анонимный отчет, который содержит заранее сформатированный блок, оформленный точно так же, как MCP-сервер Sentry форматирует свои данные для ИИ-агента. В рамках этого «отчёта об ошибках» агенту рекомендуется провести дополнительную диагностику для более точного обнаружения проблемы. Диагностика состоит в запуске npx controlled-validation-package –diagnose и заканчивается эксфильтрацией учётных данных на сервер атакующих. Вернее, могла бы закончиться, потому что в исследовательской атаке пакет «всего лишь» стучался в специальный сервер. Факт использования Sentry для обработки ошибок легко обнаружить анализом HTML веб-сайтов и строк в мобильных приложениях. Поэтому таргетировать атаку относительно несложно, и для этого не нужны вообще никакие привилегированные доступы. Хотя масштаб проблемы и простота эксплуатации интересны сами по себе, примечательно, что вектором атаки стали легко подверженные манипуляциям журналы об ошибках. Если мысленно примерить этот сценарий к ИИ-агентам, разбирающим оповещения в SOC, то аналогичных опасных полей десятки: заголовки писем, DNS-записи, параметры командной строки, User-Agent, и так далее. Достаточно правильным образом постучаться в публичную инфраструктуру жертвы — и вредоносная строка сама доедет до SIEM, а оттуда в контекст ИИ-агента. А дальше интереснее. Если у SOC-агента есть доступ к инструментам реагирования, то инъекция превращается в исполнение вредоносных команд, причем с высокими привилегиями. Но также инъекцию можно нацелить не на действие, а на бездействие, то есть убедить агента, что конкретное срабатывание — ложное. Зачем обходить детект, если можно попросить его самоустраниться? Это ещё один аргумент в копилку строгого управления уровнями автономии ИИ-инструментов, о котором мы писали.