Самая дорогая ошибка автономного агента — не всегда та, после которой что-то ломается. Иногда хуже, когда рабочая атака останавливается с аккуратным вердиктом «не работает».
Глубже разобраться в теме AI- пентеста можно на эфире про AI-агентов в наступательной безопасности: 24 сентября в 19:00 мск CEO CyberED Егор Богомолов и директор по продуктам Standoff 365 Иван Булавин обсудят, как нейросети меняют направление red.
А пока — три ложных негатива с AI-челленджа CyberED х Standoff 365 и директивы, которые помогают их предотвращать.
Когда пентест переходит в режим автопилота, меняется характер ошибок. Агент может найти рабочий вектор, упереться в артефакт своего окружения и решить, что путь закрыт. Атака ещё жива, но система уже прекратила её развивать.
На челлендже 310 агентов штурмовали один стенд, а полностью пройти его смогли 33 участника. Цель была нетривиальной: биржа торговых ботов на JavaScript, песочница, побег через публичную CVE, повышение привилегий и финальное недопустимое событие с доходностью больше трёх триллионов. В такой цепочке особенно хорошо видно, где агент путает состояние цели с состоянием собственной обвязки.
Busy-wait блокирует именно тот результат, которого ждёт агент
Первый сценарий выглядит разумно: агент запускает действие, входит в цикл ожидания секунд на тридцать, не видит результата и заключает, что попытка не сработала.
Проблема в том, что на однопоточном JavaScript-стенде активное ожидание блокирует не абстрактный фон, а ту часть приложения, от которой должен прийти ответ. Агент сам перекрывает канал наблюдения, а затем принимает созданную им тишину за доказательство неудачи.
Кажется, что ничего не работает. На деле агент просто подвешивает приложение.
Увеличить таймаут здесь недостаточно: длинное блокирующее ожидание остаётся блокирующим. Нужна другая логика поведения:
- не использовать busy-wait там, где среда однопоточная;
- разносить запуск действия и проверку результата во времени;
- считать отсутствие ответа поводом проверить состояние системы, а не готовым отрицательным результатом;
- перед отказом от вектора выполнять независимую контрольную проверку.
Практическая директива для агента может звучать так: «Если после действия нет ответа, сначала проверь, не блокирует ли твой способ ожидания обработку результата. Не помечай вектор как нерабочий только по таймауту».
Молчащий listener ещё не доказывает, что обратного соединения нет
Во втором сценарии агент поднимает локальный listener, чтобы принять обратное подключение из песочницы. Отстука нет — значит, наружу ничего не выходит, а вектор не работает.
Но сбой может находиться на стороне исследователя. VPN сменил внешний IP, активировался другой конфиг, порт оказался недоступен или listener слушает уже не тот адрес. Вместо проверки собственного канала агент начинает строить гипотезы о недоступности цели.
Здесь полезен простой диагностический порядок:
- сверить текущий внешний IP;
- проверить, на каком адресе и порту поднят listener;
- убедиться, что порт доступен;
- проверить всю промежуточную инфраструктуру;
- только после этого делать вывод о самом векторе.
Двусторонний канал связи был отмечен на челлендже как выигрышная стратегия. Агент, который не просто «стреляет и ждёт», а наблюдает за listener и состоянием своей инфраструктуры, быстрее отделяет ошибку эксплуатации от ошибки доставки результата.
Стенд упал — это гипотеза, а не финальный диагноз
Третий тупик особенно неприятен: агент сталкивается с неожиданным состоянием, объявляет стенд упавшим и прекращает работу. Хотя стенд продолжает работать или уже вернулся после штатного сброса.
На челлендже инфраструктура перезагружалась каждые 90 минут, также происходили дополнительные ресеты. В таких условиях правильная реакция — повторная разведка, проверка инфраструктуры и восстановление атаки с последней подтверждённой точки.
Для этого агенту нужна внешняя память: файл прогресса с уже проверенными гипотезами, найденными точками входа, полученным доступом и следующим действием. Без такой опоры после ресета он либо останавливается, либо заново тратит контекст на уже пройденные шаги.
Само наличие рута ещё не означает полной поломки приложения.
Рабочая директива: «При подозрении на падение цели сначала выполни повторную разведку и проверь инфраструктуру. Восстанови состояние из файла прогресса. Лишь после независимого подтверждения закрывай вектор».
Что объединяет все три ошибки
Busy-wait, сменившийся IP и штатный ресет выглядят по-разному, но ошибка у них одна: агент слишком рано превращает наблюдение в вывод.
«Нет ответа» становится «не работает». «Listener молчит» превращается в «исходящий канал закрыт». «Состояние изменилось» — в «стенд упал». На каждом переходе исчезает один важный шаг: проверка альтернативного объяснения.
Поэтому качество автономного пентеста зависит не только от модели. Узкие места нужно заранее зашивать в контекст конкретными директивами: как ждать, как контролировать обратный канал, как переживать ресеты и где хранить прогресс. Голого промпта «найди все уязвимости и не ошибайся» для этого недостаточно.
Из таких правил складывается уже не одиночный агент, а система: разведка, проверка гипотез, эксплуатация, контроль инфраструктуры, восстановление состояния и отчёт. Модель ускоряет массовый анализ, но стратегию — куда копать, чему верить и когда перепроверять — по-прежнему задаёт специалист.
Как осваивать ИИ-пентест и зарабатывать на этом
24 сентября в 19:00 мск Егор Богомолов Иван Булавин разберут, как AI меняет наступательную безопасность, турниры и игровую среду Standoff, а также какая база нужна, чтобы перейти к AI в пентесте.
Если вы уже запускаете агентов на стендах и сталкиваетесь с такими тупиками, можно зарегистрироваться на эфир «AI-агенты в наступательной безопасности».
