Большинство «промтов для пентеста» выглядят так: «вот список версий сервисов, найди CVE». Модель отвечает уверенно, красиво и почти всегда мимо: CVE правдоподобные, версии совпадают, эксплойт не работает. Причина не в том, что LLM плохая, а в том, что вы просите её гадать.
Рабочая схема другая. LLM не заменяет сканер и ручную проверку — она работает аналитиком по сырым данным. Ей отлично даётся: разобрать вывод nmap и nikto, собрать план проверки по OWASP Top 10, написать payload-гипотезы для ручного тестирования, прочитать HTTP-историю из Burp, оформить отчёт с воспроизводимыми шагами. Ниже — промты, которые я использую на каждой стадии, и что реально меняется, если их применить.
Сначала — скоуп и правила: без этого дальше бессмысленно
Прежде чем что-то сканировать, зафиксируйте границы. Промт помогает не забыть пункты и превратить устную договорённость в чек-лист. Это не юридическая консультация — это структура для вашего же согласования с заказчиком.
Промт:
Ты — помощник пентестера. Составь чек-лист скоупа и правил тестирования для веб-приложения.
Контекст: [тип приложения, стек, среда — стенд/прод, окно работ].
Включи: какие хосты и пути в скоупе и что явно вне его; какие методы и классы
атак разрешены (например, разрешён ли SSRF к внутренним адресам, разрешён ли
нагрузочный тест); что делать при обнаружении критичной уязвимости; как
фиксируются доказательства (скриншоты, запросы, логи).
Не придумывай юридические нормы — только пункты для согласования с заказчиком.
Кейс: команда взяла в работу интернет-магазин на стенде. Промт вытащил из головы пункт «что делать, если найдём утечку ПДн» — тестирование остановили, зафиксировали, согласовали с заказчиком порядок уведомления. Без чек-листа этот вопрос всплыл бы уже после находки. Для российского контекста персональные данные — это 152-ФЗ, и порядок обращения с ними лучше уточнять у заказчика заранее, а не на бегу.
Разбор сканов: LLM как парсер, а не как база CVE
Ключевой приём: не просите «найди CVE по версии». Просите структурировать сырой вывод и отделить факты от гипотез. Модель хорошо вытаскивает открытые порты, баннеры, заголовки, версии — и честно помечает, что требует ручной проверки.
Промт:
Ниже — сырой вывод nmap и nikto. Не предлагай CVE и не оценивай
эксплуатируемость. Сделай таблицу: хост, порт, сервис, версия (как в баннере),
что это значит для поверхности атаки. Отдельно выпиши всё, что требует
ручной проверки (нестандартные заголовки, лишние методы, отладочные страницы).
Если версия не определена — так и напиши, не додумывай.
Вывод: [вставить вывод сканеров]
Кейс: на одном аудите nmap показал Apache с версией из баннера, а nikto — заголовок X-Powered-By со старым PHP. Промт свёл это в таблицу и отдельно пометил расхождение: баннер врёт или прокси подменяет заголовки. Ручная проверка подтвердила — версия в баннере была намеренно искажена. Если бы модель «искала CVE» по баннеру, отчёт ушёл бы заказчику с ложными выводами.
Гипотезы по OWASP Top 10: payload для ручного теста
Здесь LLM реально экономит время. Вы даёте контекст эндпоинта, а модель предлагает гипотезы и конкретные payload для ручной проверки. Не для автопрогона — для вашего списка «что попробовать».
Промт:
Эндпоинт: GET /api/orders/{id}, авторизация по JWT, id — целое.
Предложи гипотезы по IDOR, SQLi и SSRF для ручного тестирования.
Для каждой: что проверяем, какой запрос отправить, какой признак уязвимости,
какой признак ложного срабатывания. Payload — реальный синтаксис, без выдумок.
Пометь, что требует доступа с другой учётной записью.
Кейс: на тесте личного кабинета промт по IDOR подсказал проверить не только смену id, но и поведение при чужом, но валидном токене — классический сценарий, который забывают. Ручная проверка выявила, что объект отдавался по id без проверки владельца. Нашли за пару минут вместо часа перебора.
Чтение HTTP-истории: где модель особенно полезна
HTTP-история из Burp — это десятки запросов, в которых легко утонуть. LLM хорошо вытаскивает аномалии: неожиданные коды ответов, разные тела при одинаковом запросе, токены в URL, отсутствие нужных заголовков безопасности.
Промт:
Ниже — HTTP-история (метод, URL, код, ключевые заголовки, фрагмент тела).
Найди аномалии: коды 200 там, где ожидается 403; токены или секреты в URL;
различия в ответах на одинаковые запросы; отсутствие заголовков безопасности.
Для каждой аномалии — запрос, почему это подозрительно, что проверить руками.
Не делай выводов об уязвимости — только гипотезы.
История: [вставить выжимку]
Неочевидный вывод: модель особенно полезна там, где вы уже устали смотреть на одно и то же. Аномалию в 40-м запросе глаз пропускает, а список «код 200 на чужой ресурс» — нет. Это не замена внимательности, а страховка от неё.
Threat model и отчёт: то, что заказчик реально читает
Финальная стадия — собрать находки в отчёт с воспроизводимыми шагами и CVSS. Модель помогает с формулировками и структурой, но оценку CVSS всегда перепроверяйте: векторы модель путает, особенно по контексту.
Промт:
Оформи находку для отчёта: [описание]. Дай структуру: заголовок,
затронутый компонент, шаги воспроизведения (пошагово, с запросами),
влияние на бизнес, рекомендация по фиксу. Вектор CVSS предложи, но пометь,
что требует ручной проверки. Без выдуманных ссылок на CVE.
Кейс: отчёт по IDOR ушёл заказчику с пошаговым воспроизведением и рекомендацией проверять владельца объекта на сервере, а не полагаться на скрытие id в интерфейсе. Разработчик воспроизвёл за пять минут — это и есть признак хорошего отчёта.
Где схема ломается
Три режима отказа, которые стоит знать заранее:
- Модель «достраивает» версию или CVE — если в промте осталась просьба «найди уязвимость по баннеру». Лечится запретом на CVE в промте.
- Устаревший контекст — LLM не знает свежих изменений в конкретном фреймворке. Гипотезы проверяйте по документации, а не по памяти модели.
- Ложная уверенность в CVSS — вектор выглядит убедительно, но не учитывает ваш контекст. Считайте вручную или сверяйте.
Trade-off простой: вы экономите время на рутине (парсинг, структура, черновик отчёта), но платите обязательной ручной проверкой каждой гипотезы. Если пропустить проверку — получите красивый документ с выдуманными выводами, который хуже, чем никакого. Смежные темы — отладка нативных ошибок через LLM и криптография на практике — там та же логика: модель помогает разобраться в данных, но не заменяет проверку.
Что в итоге
LLM в пентесте — это ускоритель анализа, а не детектор уязвимостей. Сканер собирает факты, вы проверяете руками, модель помогает не утонуть в данных и быстрее добраться до отчёта. Начните с промта по скоупу, затем разберите сканы, постройте гипотезы и только потом оформляйте выводы — с обязательной ручной проверкой каждого пункта.