ИИ может за минуты разобрать документацию, предложить векторы атаки и набросать код. Но скорость ответа легко принять за качество проверки.
В пентесте это особенно опасно: убедительно описанная «уязвимость» может оказаться непроверенной гипотезой, а уверенно предложенная команда — выйти за разрешённые границы тестирования.
13 августа на открытом воркшопе CyberED пентестер и ИИ-агент решат одинаковые CTF-задачи: сравним скорость, ход решения, ошибки и результат.
Главная ошибка при работе с ИИ — воспринимать его вывод как готовый результат. Полезнее считать ответ модели черновиком: набором версий, которые специалисту ещё предстоит проверить.
Разберём, где появляются ложные находки и как организовать процесс, чтобы агент ускорял пентест, а не создавал дополнительную работу.
Почему правдоподобный ответ ещё ничего не доказывает
Модель умеет собирать связный ответ из контекста и формулировать его уверенно. Однако уверенный тон не означает, что предложенный вектор существует в проверяемом приложении.
В транскрипции вебинара приводится показательный сценарий с CTF-лабораториями. Раньше специалист мог потратить часы на документацию, руководства и форумы. Теперь те же материалы можно передать ИИ и за несколько минут получить перечень потенциальных векторов. Это серьёзно ускоряет разведку, но полученный список остаётся только отправной точкой.
Если модель неверно поняла документацию, не увидела важное ограничение или заполнила пробел собственным предположением, ошибка пройдёт дальше по всей цепочке. Из гипотезы появится PoC, затем описание воздействия, а после — убедительный, но недостоверный отчёт.
Поэтому первое правило простое: ИИ предлагает направление проверки, но наличие уязвимости подтверждает специалист. На живом сравнении ручного подхода и работы агента можно будет увидеть, в каких местах результат требует человеческой перепроверки.
Где в AI-пентесте рождаются ложные находки
Ошибку необязательно создаёт сама модель. Часто проблема возникает из-за того, как ей поставили задачу и какой контекст передали.
Недостаточно контекста
Запрос вроде «найди уязвимость» не объясняет агенту, что именно тестируется, какие действия разрешены и какой результат считается подтверждением. Модель начинает достраивать недостающие условия сама.
Вместе с задачей ей нужны как минимум:
- описание приложения или стенда;
- доступная документация;
- границы разрешённого тестирования;
- инструменты, которыми можно пользоваться;
- запрет на опасные и несогласованные действия;
- формат ожидаемого результата;
- критерии, по которым находка считается подтверждённой.
Чем меньше двусмысленности в постановке, тем ниже вероятность получить красивый ответ вместо воспроизводимого результата.
Агент не нашёл параметр и решил его подобрать
В одном из разобранных примеров требовалось написать небольшой скрипт для обращения к API. Агент не смог найти нужный параметр и вместо остановки начал перебирать варианты. То есть фактически перешёл к фаззингу, хотя пользователь такой задачи не ставил.
Для пентеста это двойной риск. Во-первых, агент может выйти за согласованный сценарий. Во-вторых, полученный ответ будет выглядеть как результат выполнения задачи, хотя способ его получения не был разрешён.
Поэтому ограничения следует формулировать явно: если данных недостаточно, агент должен остановиться, описать пробел и запросить решение человека. Не угадывать параметр, не расширять область проверки и не запускать новую технику самостоятельно.
Инструмент сгенерировал то, чего не было в задаче
Другой пример связан с подготовкой презентации. Сервис выполнил основную часть работы, но сам добавил «запасной кейс по автоматизации», которого не было в исходных материалах. Формально результат выглядел аккуратно, однако часть содержания оказалась выдуманной.
В отчёте по пентесту подобная самостоятельность опаснее. Модель может добавить неподтверждённую причину уязвимости, придумать отсутствующий этап эксплуатации или преувеличить последствия. Поэтому текст отчёта нужно сверять не с убедительностью формулировок, а с артефактами проверки.
Как проверять AI-находку до включения в отчёт
Удобно разделить работу на четыре стадии: гипотеза, проверка, воспроизведение и описание. ИИ может помогать на каждой из них, но переход между стадиями должен подтверждать человек.
Сначала отделите факт от предположения
Попросите агента явно разнести результат по категориям:
- что следует из переданной документации;
- что он наблюдал при работе со стендом;
- что является предположением;
- каких данных не хватает;
- какое действие подтвердит или опровергнет гипотезу.
Такой формат не устраняет ошибки автоматически, зато делает их заметнее. Если весь «результат» находится в разделе предположений, отправлять его в отчёт рано.
Требуйте воспроизводимую последовательность
Подтверждённая находка должна сводиться к понятной цепочке действий. Специалисту необходимо повторить её вручную и убедиться, что результат не возник из-за случайного состояния стенда, неверной интерпретации ответа или действий агента за пределами задачи.
Полезно фиксировать:
- исходные условия;
- конкретные запросы и команды;
- ответы приложения;
- ожидаемый и фактический результат;
- ограничения и исключения;
- действия агента, которые потребовали ручного подтверждения.
На воркшопе о применении ИИ в CTF и пентесте задачи пройдут оба маршрута — вручную и через агента, поэтому различия будут видны на одинаковых исходных условиях.
Проверяйте команды до запуска
Контроль нужен не только после получения ответа. Специалист должен понимать, что агент собирается запустить, зачем это требуется и соответствует ли действие разрешённой области тестирования.
Особенно внимательно стоит относиться к действиям, которые:
- перебирают параметры;
- изменяют данные;
- вызывают неизвестные скрипты;
- расширяют область проверки;
- используют найденные в интернете инструкции и скиллы;
- требуют доступа к чувствительным данным.
Идея «одной кнопки» привлекательна, но в практической работе промежуточный контроль часто важнее скорости.
Не передавайте во внешнюю модель критичные данные
Внешнему сервису не следует отправлять секреты, токены, персональные данные, внутреннюю информацию компании и полные отчёты по пентесту. Если материалы подпадают под NDA, передача их на сторонний сервер сама по себе может стать проблемой.
Перед началом работы нужно решить, можно ли обезличить контекст или использовать локальную модель. Даже тогда результат остаётся черновиком и требует проверки.
Чек-лист перед отправкой AI-находки
Перед включением результата в отчёт проверьте:
- задача и границы тестирования описаны явно;
- агент не выполнял несогласованные действия;
- гипотеза подтверждена на стенде;
- последовательность воспроизводится вручную;
- запросы, ответы и другие артефакты сохранены;
- влияние подтверждено, а не предположено;
- в описании нет деталей, которых не было в исходных данных;
- чувствительная информация не ушла во внешний сервис;
- итоговый текст вычитан специалистом.
Если хотя бы на один пункт нельзя ответить уверенно, перед вами ещё не готовая находка, а материал для дальнейшей проверки.
Где ИИ действительно помогает пентестеру
Критический подход не означает, что от ИИ стоит отказаться. Он уже полезен там, где специалисту нужно быстрее обработать большой объём информации: разобрать документацию, получить версии возможных векторов, подготовить код, обработать ошибки, оформить черновик отчёта или изучить новую технику.
ИИ также можно использовать как помощника в обучении: разбирать райтапы, понимать логику решения CTF-задач и сравнивать разные подходы. На практической демонстрации с тремя CTF-задачами этот подход будет показан без формата обычного обзора нейросетей.
Полезная модель взаимодействия выглядит так: агент ускоряет поиск и рутинные операции, а специалист задаёт рамки, проверяет действия и отвечает за вывод. Чем выше автономность системы, тем важнее заранее заданные ограничения и контроль результата.
Пентестер против ИИ: проверим на одинаковых задачах
13 августа в 18:30 МСК CyberED проведёт открытый воркшоп «Битва хакера и ИИ в прямом эфире». Специалист по анализу защищённости Никита Коломиец решит три CTF-задачи двумя способами: вручную и с помощью ИИ-агента.
Участники увидят не абстрактное обсуждение возможностей моделей, а полный процесс: обзор стенда, настройку окружения агента, ручное решение, решение с ИИ и сравнение результатов. В работе будут использованы Burp Suite, Claude Code и Cursor IDE.
На воркшопе разберут, где ИИ ускоряет анализ приложения и поиск путей эксплуатации, как ставить агенту задачи, где модель ошибается и как использовать её для обучения, CTF и рабочих проверок.
Зарегистрироваться на открытый воркшоп и увидеть битву пентестера с ИИ.
