AI-агент может сам изучить приложение, подобрать подходящую технику, запустить инструменты и собрать доказательства уязвимости. Но между «может» и «стабильно делает» пока лежит целая полоса препятствий.
Увидеть это на практике и бесплатно познакомиться с мастер-классами по ИИ-пентесту можно в Красном Сентябре. Там открыт доступ к материалам по offensive security, включая мастер-классы по применению AI-агентов и LLM в работе атакующего.
В основе статьи лежит практический эксперимент на учебном веб-приложении. AI-агенту поставили цель самостоятельно исследовать систему, найти путь эксплуатации, выйти из песочницы, повысить привилегии и выполнить контрольное действие. Он справился, но по дороге несколько раз уходил в тупик: тратил часы на неприменимый вектор атаки, объявлял рабочий стенд недоступным и пытался решить технически корректную, но бессмысленную задачу.
Проблема не всегда в том, что модель недостаточно умная. Часто ей не хватает дисциплины исследования: понять систему, сформулировать гипотезу, проверить её наблюдаемым способом и лишь затем двигаться дальше. Разберём пять ошибок, которые превращают AI-пентест из ускорителя в генератор тупиков.
Агент бросается фаззить, не разобравшись
Самый соблазнительный сценарий выглядит так: дать агенту адрес цели и попросить найти все уязвимости. Он запускает перебор директорий, параметров и полезных нагрузок, получает большой объём ответов и начинает строить гипотезы. Работа кипит, токены расходуются, терминал заполняется командами, но полезного результата может не быть.
На учебном стенде выигрышной оказалась противоположная стратегия: сначала прочитать доступные исходники и понять бизнес-логику. Это позволило быстро увидеть, какие запросы к базе параметризованы, где предполагаемый вектор атаки не имеет смысла и через какие точки приложение действительно взаимодействует с внешней средой.
Агент склонен выбирать действие, которое проще немедленно выполнить инструментом. Фаззинг даёт мгновенный поток наблюдений, а чтение кода требует удерживать контекст и связывать детали. Без явной инструкции модель часто предпочитает активность пониманию.
Хорошее правило для автоматизированного исследования можно сформулировать так:
- сначала описать компоненты системы и их связи;
- выделить доверительные границы и места обработки пользовательских данных;
- проверить, какие гипотезы уже исключаются исходным кодом;
- только затем запускать точечные проверки;
- после каждой серии действий обновлять карту приложения.
Это превращает сканирование из стрельбы по площади в проверку конкретной версии: если данные проходят здесь и обрабатываются так, возможен вот такой сценарий.
Агент подбирает эксплойт до точного определения версии
Следующая ловушка возникает, когда агент правильно определил класс технологии, но не уточнил версию, сборку или особенности окружения. Он находит несколько публичных доказательств концепции, скачивает их и по очереди пытается приспособить к цели. Иногда один из вариантов срабатывает. Иногда начинается длинный цикл исправления чужого кода, который изначально не подходил к исследуемой системе.
На стенде более эффективным оказался короткий дополнительный этап: изучить доступный системный файл с информацией о компоненте, уточнить его версию и только после этого выбирать PoC, готовый прототип эксплуатации. Несколько минут на точное определение технологии и её версии могут сэкономить часы перебора.
Агент способен читать код и менять план, но эту возможность нужно включить в процесс. Если поставить цель эксплуатировать быстрее, модель может перескочить через уточнение предпосылок.
Перед активной эксплуатацией агенту полезно требовать короткий паспорт гипотезы:
- какой компонент предположительно уязвим;
- какая версия обнаружена и чем это подтверждено;
- какие условия нужны для эксплуатации;
- какие условия уже выполнены;
- что станет однозначным признаком успеха или провала;
- какое действие безопасно выполнить следующим.
Так модель не просто выбирает знакомое название уязвимости, а доказывает применимость техники к конкретной цели.
Агент не строит канал обратной связи
Во многих задачах результат нельзя увидеть в том же окне, где выполняется действие. К таким сценариям относятся Blind SSRF (серверный запрос без прямого ответа приложения), асинхронная обработка, выполнение кода в песочнице и отложенные задачи. Если агент умеет только отправить запрос и прочитать ответ, отсутствие данных он принимает за отсутствие уязвимости.
Во время эксперимента полезным решением стал простой двусторонний канал наблюдения: агент поднял listener, принимающий сервер для фиксации обратных подключений, и смог отслеживать внешние обращения. После этого невидимые прежде действия превратились в проверяемые события. Похожий принцип применим и шире: нужны контрольный endpoint (адрес API), журнал событий, корреляционный идентификатор, повторная проверка состояния или другой способ понять, что произошло вне текущей сессии.
AI-пентестер должен уметь не только воздействовать на систему, но и заранее отвечать на вопрос: как я узнаю, что воздействие сработало?
Агент слишком рано признаёт попытку неудачной
Допустим, агент отправляет полезную нагрузку и ждёт результат 30 секунд. Ответа нет. Модель делает вывод: техника не работает, сервис недоступен или стенд упал. Затем она меняет гипотезу, хотя результат мог появиться позже.
На практике задержка бывает частью поведения системы. Код может выполняться асинхронно, задача может ждать очереди, отдельный процесс может стартовать не сразу. Жёсткий короткий тайм-аут превращает потенциально рабочую технику в ложный отрицательный результат.
Агенту нужна политика повторных проверок:
- определить ожидаемый диапазон задержки;
- проверить промежуточные признаки выполнения;
- повторить наблюдение через заданные интервалы;
- отличать «результата пока нет» от «получено подтверждение провала»;
- сохранять состояние, чтобы не запускать одну и ту же операцию бесконечно.
Без таких правил агент воспринимает тайм-аут как факт. Даже сильная модель выигрывает от простого автомата: действие, ожидание, проверка, повторная проверка, вывод.
Агент принимает собственное воздействие за падение инфраструктуры
Ещё опаснее ситуация, когда проверка сама временно блокирует исследуемый компонент. Например, долгий вызов занимает поток выполнения, интерфейс перестаёт отвечать, и агент решает, что цель сломалась. Он начинает менять сетевые настройки, перезапускать инструменты или уходить в другую ветку расследования.
В реальности стенд может быть жив, а задержка станет прямым следствием предыдущего действия агента. Если не сопоставлять время запуска проверки и изменение поведения системы, причина и следствие меняются местами.
Перед объявлением инфраструктуры недоступной агент должен выполнить независимую диагностику:
- проверить базовую сетевую связность;
- убедиться, что listener использует актуальный адрес после смены VPN;
- проверить другой endpoint, не затронутый текущей нагрузкой;
- повторить запрос после ожидаемого завершения операции;
- сравнить симптомы с тем, что должна была сделать последняя команда.
В реальной инфраструктуре ошибочный вывод расходует не только токены и время: он способен подтолкнуть агента к лишним действиям. Расширять воздействие стоит только после диагностики и, для рискованных операций, подтверждения человека.
Агент увлекается технически возможной, но бессмысленной целью
Последняя ловушка связана с непониманием бизнес-логики. Агент мог долго искать знакомый класс уязвимостей, хотя исходники показывали, что нужного сценария нет. Или пытаться добиться требуемого показателя обычными операциями, хотя архитектура делала этот путь бессмысленным.
После повышения привилегий агент также мог напрямую изменить контрольный файл. Технически это было возможно, но цель задания заключалась в другом: вызвать предусмотренное бизнес-логикой событие. Поэтому формально успешное действие не доказывало прохождение сценария.
Если цель описана поверхностно, модель может добиться правильного значения неправильным способом. Агент должен понимать, какое изменение состояния системы считается доказательством.
Перед длинной веткой исследования полезно задавать три вопроса:
- приближает ли гипотеза к целевому событию, а не просто к интересному техническому результату;
- соответствует ли она устройству приложения;
- можно ли заранее назвать наблюдение, которое подтвердит её ценность.
Если хотя бы на один вопрос нет ответа, гипотезу стоит отложить или передать человеку на оценку.
Сильный AI-пентест строится вокруг цикла проверки
Все пять ошибок объединяет одна причина: агент действует быстрее, чем понимает последствия. Исправляется это не идеальным промптом и не покупкой самой дорогой модели. Нужен процесс, в котором каждое действие оставляет проверяемый результат.
Рабочий цикл выглядит так:
контекст → гипотеза → безопасное действие → наблюдение → независимая проверка → обновление плана.
Контекст объясняет устройство цели и ограничения. Действие проверяет одну гипотезу. Наблюдение даёт измеримый результат, независимая проверка защищает от галлюцинаций, а обновлённый план не даёт повторять тупики.
Роль человека при этом не исчезает. Пентестер определяет стратегию, проверяет реальные последствия уязвимости, контролирует границы разрешённого исследования и решает, когда можно усиливать воздействие. Агент забирает массовый анализ, рутинные команды, первичный разбор кода, подготовку проверок и фиксацию результатов.
Не ИИ вместо специалиста, а специалист с управляемым контуром автоматизации.
Проверить описанный подход на учебных задачах можно в материалах «Красного Сентября». До 30 сентября там открыт бесплатный доступ к занятиям по работе с AI-агентами, веб-пентесту, Active Directory, OSINT, Bug Bounty и атакам на CI/CD.
