На связи Станислав Грибанов, руководитель продуктового направления компании «Гарда», автор блога «CyberProducts».
Zero Networks выпустила отчет Lateral Movement Exposure Report 2026. Эксперты оценили, как далеко атакующий может проникнуть внутрь сети после преодоления периметра. Отдельный раздел отчета посвящен AI-Driven Lateral Movement (AILM).
Далее я подробнее разберу три сценария, которые приводятся в отчете.
Сценарий 1. Prompt injection для агента поддержки
Предположим, в компании работает копайлот технической поддержки, которого она сама и развернула. У агента есть доступ к CRM (базе клиентов) и внутренней базе знаний, а также возможность создавать тикеты в Jira.
Разбирать входящие обращения вручную долго, поэтому сотрудники часто просят агента пересказать письмо и работают уже с готовой суммаризацией. Само письмо при этом никто не читает.
А дальше всё просто. Атакующему достаточно отправить письмо в поддержку, которое на первый взгляд выглядит как обычное обращение, но внутри спрятан специальный промпт. Агент пересказывает письмо, попутно выполняя спрятанные в нем инструкции: создает тикеты с выгруженными данными клиентов и направляет их на адрес, который контролирует атакующий.
Заметить такое крайне тяжело. Ведь в данном случае злоумышленник не делает ничего, что можно было бы трактовать как атаку: в трафике видны логи общения с агентом, которые компания считает абсолютно нормальными действиями.
У защиты остается два пути:
Первый — использовать специализированные средства, которые выявляют атаки в промптах. Написать сигнатуру на промпт сложно, и на российском рынке таких решений единицы.
Второй, более простой, — посмотреть на отклонения от нормального поведения агента. Как только он постучится в дверь, в которую ему ходить нельзя, или запустит процессы, которые запускать не должен, — СЗИ сможет зафиксировать отклонение (подобным образом должен работать NDR или EDR). Вот как это выглядит в нашем сценарии: агент работает с CRM и внутренней базой знаний, а также создает тикеты. Если он полез, скажем, в Outlook, в каталог пользователей или на файловый сервер, это уже нехарактерное поведение. Сюда же относится объем: агент начинает выгружать данные, чего в нормальной работе, скажем, не бывает.
Если агент один и его зоны жестко описаны, политики безопасности можно настроить вручную. Когда агентов много и они меняются, поможет только ML. Он обучится на том, как агент работает в нормальном режиме, и дальше уже сможет ловить отклонения. Можно также скомбинировать оба подхода: задать самые явные нормы, остальное вытащить из модели.
Сценарий 2. Массовый перебор учетных данных
Атакующий забирает с одной рабочей станции все сохраненные NTLM-хеши и тестирует их на каждом доступном внутреннем активе. Если бы злоумышленник делал это вручную, он бы проверил несколько наиболее ценных целей. ИИ-агент способен тестировать тысячи одновременно.
По данным отчета, 43,2% случаев внутренняя аутентификация всё еще опирается на NTLM. Чем больше в сети систем, которые принимают такую аутентификацию, тем выше доля успешных попыток взлома.
В трафике это выглядит как всплеск. От одного хоста идет масса запросов авторизации к разным хостам по всей сети, и такие сессии видны по всему периметру внутренней сети.
Ориентир для защитников тут простой. Рабочая станция сотрудника обычно несколько раз в день (допустим, десять) авторизуется на файловой шаре по SMB с использованием NTLM. Если вместо привычных десяти авторизаций их становится несколько тысяч, это уже ненормально. Мы не знаем, что конкретно случилось, но видим, что кто-то занимается разведкой.
Всплески по протоколам авторизации, будь то NTLM, Kerberos или LDAP, можно выносить в отдельные детектирующие модели. Часть из них детерминируется под конкретную атаку вроде подбора пароля. Вариантов, что стоит за таким всплеском, на самом деле немного: либо истекший пароль в каком-нибудь скрипте, который продолжает активно пытаться авторизоваться, либо попытка взлома.
Сценарий 3. Shadow AI-агенты
Представьте: разработчик подключает внутреннюю LLM к личному MCP-серверу с доступом к корпоративной базе данных, чтобы упростить себе работу. Личным этот сервер является только в том смысле, что разработчик поднял его под свои задачи. Сетевой изоляции у такого сервера, как правило, нет. С одной такой скомпрометированной машины в среднем доступны 85% внутренних систем.
Связка языковой модели и MCP-сервера и есть тот самый агент. Он нигде не логинится, не интегрируется с системой управления доступом и никак не проявляет себя для ИБ-службы.
Атакующему остается только в процессе разведки найти такого агента. А дальше дело за малым. Компрометировать при этом ничего не нужно: агент сам обрабатывает запросы, поэтому достаточно попросить его выгрузить данные и отправить их куда-то. Обращение к базе происходит от имени доверенного сервисного аккаунта, поэтому следов в трафике не остается.
По сути, это Shadow IT 2.0. Раньше в инфраструктуре заводились неучтенные ноутбуки и каналы удаленного доступа, теперь аналогичным образом появляются агенты. Разница только в том, что у агента сразу есть и доступ к данным, и готовая автоматизация.
Лечится всё это инвентаризацией: нужно видеть, какие агенты вообще подняты в инфраструктуре, с чем они коммуницируют и к чему у каждого из них есть доступ.
Как защищать сеть в эпоху ИИ-агентов
Принципиально новых техник защиты здесь нет. Горизонтальное перемещение широко известно как минимум с 2010 года, когда его применили в атаке Stuxnet. Тогда еще не было LLM, но механика была та же: движение от одной системы к другой внутри локальных сетей. С тех пор приемы почти не изменились, но изменились скорость и масштаб, а теперь и количество параллельно выполняемых задач. И сложность для защиты в том, что в подобных сценариях нет признаков атаки: ни украденного пароля, ни эксплойта, а в случае с shadow-агентом источник риска и вовсе может исходить от штатного сотрудника.
Специализированные средства для защиты языковых моделей и агентов уже разрабатываются, но пока на нашем рынке их мало и они еще не получили массового внедрения. При этом часть угроз закрывается теми инструментами, которые уже есть в инфраструктуре.
В действительности промпт-атаку видно по последствиям, о чем я писал выше, когда разбирал кейс с агентом техподдержки. Shadow AI обнаруживается либо по самим агентам, либо по обращениям к доменам и сетям, характерным для ИИ-сервисов.