Год назад я относился к LLM в offensive security примерно так же, как к очередному DAST-сканеру - прикольная штука, но ручками всё равно быстрее. После сотни часов экспериментов с GPT-4, Claude и связкой Nuclei + LLM для генерации шаблонов позиция поменялась. Не на «AI заменит пентестеров», а на «AI экономит мне 3-4 часа на каждом таргете, если я точно знаю, куда его направить». Разница принципиальная. Первое - фантазия, второе - рабочий инструмент. Именно об этом и поговорим.
AI bug bounty - не про запуск автономного агента, который сам находит RCE (хотя хотелось бы). Это про интеграцию языковых моделей в конкретные этапы workflow: разведку, анализ JS-бандлов, вариацию payload, приоритизацию attack surface и оформление репортов. Ниже - конкретика с промптами, инструментами и честным разбором того, где оно не работает.
Что изменилось: цифры и факты
Прежде чем лезть в workflow, стоит оценить масштаб сдвига. По данным HackerOne (8th Annual Hacker-Powered Security Report), рост количества подтверждённых репортов по AI-уязвимостям - примерно 210%, лидирующая категория - prompt injection. Bugcrowd в отчёте Inside the Mind of a Hacker 2026 (более 2 000 респондентов) фиксирует: около 82% опрошенных хакеров используют AI в работе - автоматизация рутины, анализ кода, ускорение разведки и триажа. Подробнее - в моей статье о безопасность llm атаки.Со стороны offensive-возможностей моделей данные ещё любопытнее. UK AI Security Institute отмечает, что длина кибер-задач, которые наиболее продвинутые модели решают без помощи человека, удваивается примерно каждые 8 месяцев. Исследование (предположительно METR или аналогичной организации) показывает время удвоения в 9.8 месяцев по всем моделям 2019–2026, но для моделей от 2024 года и позже - уже 5.7 месяцев. Модели буквально учатся быстрее, чем мы успеваем менять workflow.
Параллельно растёт общий объём поверхности атаки: по прогнозу FIRST Vulnerability Forecast (февраль 2026), в этом году ожидается порядка 60 000 CVE - при 50 000 в 2025 и 40 000 в 2024. Рост зарегистрированных CVE - примерно 25% ежегодно. Руками всё это разгребать уже нереально. Искусственный интеллект в пентесте - не эксперимент, а производственная необходимость.
Где AI реально экономит часы в bug bounty
Декомпозиция JavaScript и поиск скрытых эндпоинтов
Современные SPA генерируют JavaScript-бандлы по 200–500 КБ минифицированного кода. Ручной анализ такого файла - 2-4 часа для опытного исследователя. LLM для анализа кода разбирает это за секунды, если правильно сформулировать задачу.Промпт, который у меня прижился:
Ключевой момент - не спрашивайте «найди уязвимости». Просите модель извлечь структурированные данные: эндпоинты, параметры, паттерны авторизации. Вы сами решите, что тестировать. LLM vulnerability research работает, когда модель - высокоскоростной парсер, а не «хакер на удалёнке».
По данным Wiz, именно этот сценарий - один из самых эффективных: задача на часы у человека, секунды у AI.
Генерация и вариация payload
Нашли потенциальную SSTI в Flask-приложении, но стандартные пейлоады фильтруются - знакомая ситуация. GPT bug bounty сценарий тут простой: описываете модели конкретный контекст (фреймворк, WAF, что именно блокируется), получаете десяток bypass-вариаций за минуту. То же работает для XSS-фильтров, SQL-инъекций с кастомным WAF и SSRF с ограничением по протоколу.Это не замена ручного крафта. Это ускорение итераций. Вместо того чтобы вспоминать все вариации обхода Jinja2-sandbox (а их накопилось прилично), получаете стартовый список и адаптируете под конкретный таргет. У меня это сократило фазу подбора payload раза в три.
Автоматизация поиска уязвимостей через Nuclei + AI
Nuclei от ProjectDiscovery в версиях 2025–2026 получил AI-генерацию шаблонов, и это реально изменило скорость реакции на свежие CVE. Вместо ручного написания YAML-шаблона описываете уязвимость текстом, модель генерирует рабочий шаблон:
Bash:
nuclei -ai "SSRF via redirect parameter on /api/v2/fetch \
accepting full URLs, check AWS metadata and internal services" \
-target https://target.example.com \
-o ssrf_results.txtПриоритизация attack surface
Средний SaaS-таргет в 2026 году - 300+ эндпоинтов, микросервисная архитектура с десятками внутренних API и облачные ассеты у нескольких провайдеров. Руками всё это приоритизировать в рамках таймбокса - нереально. Связка BBOT для сбора данных + LLM для ранжирования по вероятной эксплуатабельности (возраст сервиса, открытые панели, legacy-компоненты) - рабочий паттерн.PentestGPT идёт дальше: скармливаете вывод
nmap, находки Burp, логи перечисления - получаете приоритизированный список следующих шагов с обоснованием. Это не автономный пентест. Это AI security research tools в роли reasoning layer поверх вашего тулчейна. Думалка, а не делалка.CVE, найденные с помощью AI: разбор реальных кейсов
Разговоры о потенциале - одно дело. Зарегистрированные CVE - совсем другое.CVE-2026-4747: стековое переполнение в FreeBSD
Уязвимость в реализации RPCSEC_GSS ядра FreeBSD, по публичным сообщениям найденная с помощью LLM-assisted research. Суть: при валидации каждого RPCSEC_GSS-пакета подпрограмма проверки подписи копирует часть пакета в стековый буфер без проверки достаточности размера. Злонамеренный клиент вызывает стековое переполнение (CWE-121). Согласно описанию NVD, аутентификация клиента не требуется для срабатывания, хотя CVSS-вектор указывает PR:L - переполнение происходит до завершения проверки подписи конкретного пакета.CVSS 8.8 (HIGH), вектор:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - сетевой вектор, низкая сложность, полная компрометация конфиденциальности, целостности и доступности. В терминах MITRE ATT&CK - классический Exploit Public-Facing Application (T1190, Initial Access). Удалённое выполнение кода в ядре через сетевой сервис. Красота, если вы атакующий.CVE-2026-31402: heap overflow в ядре Linux
Переполнение кучи в NFSv4.0 replay cache ядра Linux. Кэш воспроизведения использует фиксированный 112-байтовый буферrp_ibuf[NFSD4_REPLAY_ISIZE] для хранения закодированных ответов операций. Размер рассчитан для OPEN-ответов, но не учитывает LOCK denied-ответы, включающие поле владельца конфликтующей блокировки переменной длины (до 1024 байт, NFS4_OPAQUE_LIMIT). 112 байт под буфер, до 1024 байт данных - арифметика не сходится. По неподтверждённым публикациям, обнаружение предположительно связано с Claude-assisted research; на момент публикации CVSS в NVD не присвоен, CWE формально не указан (по описанию - CWE-122, heap-based buffer overflow).Оба случая показывают одно: AI эффективен в анализе C-кода ядра на паттерны buffer overflow - класс уязвимостей, где поиск требует терпеливого прослеживания потоков данных через десятки функций. Именно это модели делают хорошо, пока человек задаёт правильный контекст и знает, куда копать.
Три фундаментальных ограничения LLM в offensive security
А теперь - честная часть. Без неё статья про автоматизацию пентеста была бы маркетинговым буклетом.Spurious correlations: ложные связи
Исследование из arxiv (Uncovering Vulnerabilities of LLM-Assisted Cyber Threat Intelligence) выявило три категории системных проблем LLM в задачах кибербезопасности. Первая - spurious correlations: модели переоценивают значимость поверхностных признаков. Пример: LLM видит Mimikatz в логах и уверенно атрибутирует атаку конкретной APT-группе, хотя Mimikatz - commodity-инструмент, его используют десятки группировок. Это как обвинять конкретного человека в краже, потому что у него есть отвёртка.В контексте bug bounty это выглядит так: модель видит рефлексию ввода в ответе и уверенно заявляет об XSS, игнорируя Content-Security-Policy и фактическую невозможность исполнения скрипта. Или находит timing-разницу в 50мс и строит теорию о blind SQL-инъекции, когда разница - банальный сетевой шум.
Constrained generalization: слепота к новому
LLM плохо обобщают за пределы знакомых паттернов. Zero-day attack surfaces, нестандартные TTP, кастомные протоколы - зона слабости. В исследовании Wiz это подтверждено экспериментально: когда AI-агентам давали широкий скоуп (несколько таргетов, без конкретного направления), производительность падала радикально. Агенты «размазывали» усилия, перескакивали между целями и пропускали уязвимости, которые нашли бы при точном наведении.Итерация вместо пивота
Ключевое наблюдение из Wiz-исследования: AI итерирует, человек пивотит. Когда подход не работает, AI-агент пробует вариации того же метода - как баран в ту же калитку. Тестировщик распознаёт тупик и меняет стратегию целиком. В одном из тестов AI-агент совершил более 500 вызовов инструментов за час и ничего не нашёл. Человек, начав заново с более широкого перечисления, обнаружил уязвимость за 5 минут.Это не значит, что машинное обучение в кибербезопасности бесполезно. Это значит, что AI - тактический инструмент, а не стратегический. Вы определяете направление, AI выполняет. Перепутаете роли - потеряете время.
AI-системы как новая поверхность атаки
Отдельный тренд - AI bug bounty программы, где объект тестирования - сама AI-система. Платформа huntr специализируется на уязвимостях в open-source AI/ML-приложениях и библиотеках, охватывая более 240 программ. HackerOne предлагает выделенный тип ассета AI Model и скоупинг по OWASP Top 10 for LLMs.По данным HackerOne, специфичные для AI уязвимости включают: утечку системного промпта (раскрытие конфиденциальных инструкций), манипуляцию RAG (подмену или злоупотребление источниками знаний), эксплуатацию adversarial inputs (провоцирование непредусмотренного поведения модели). На стороне AI Safety - вредоносные или предвзятые выходы, галлюцинации, обход guardrails.
В терминологии MITRE ATT&CK это целый кластер техник resource development: Artificial Intelligence (T1588.007) для приобретения доступа к AI-инструментам, Vulnerabilities (T1588.006) для сбора информации об уязвимостях, Exploits (T1587.004) для разработки эксплойтов. Для атак непосредственно на ML-системы более релевантен фреймворк MITRE ATLAS.
Ориентировочные минимальные баунти по рекомендациям HackerOne (AI asset guidance): $5 000 за Critical, $2 000 за High, $750 за Medium, $200 за Low. Для закалённых систем, прошедших обширное тестирование: $10 000 / $5 000 / $2 000 / $500 соответственно. Конкретные суммы зависят от программы.
Практический блок: AI-augmented bug bounty workflow за 60 минут
Требования к окружению
- ОС: Linux (Kali/Parrot) или macOS
- Nuclei v3+ (
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest) - Burp Suite Professional с установленным BurpGPT или аналогичным AI-расширением
- API-ключ OpenAI (GPT-4o) или Anthropic (Claude) - модели с контекстным окном от 100K токенов
- BBOT для разведки (
pipx install bbot) - Режим работы: онлайн (нужен доступ к API модели и таргету)
Шаг 1: разведка и структурирование
Запускаетеbbot -t target.com -p web-thorough -o bbot_output/ для сбора attack surface. Экспортируете результат в JSON. Скармливаете JSON в Claude или GPT-4o с промптом:На выходе - структурированная таблица вместо простыни из сотен строк. Уже можно работать.
Шаг 2: глубокий анализ приоритетных целей
Для каждого приоритетного эндпоинта прогоняете трафик через Burp Suite с включённым BurpGPT:
Python:
ANALYSIS_PROMPT = """
Ты - senior appsec-инженер. Проанализируй request-response пару:
1. Параметры, влияющие на серверную логику
2. Токены с низкой энтропией
3. IDOR-кандидаты по паттернам object reference
4. Business logic assumptions, которые можно нарушить
Только конкретные findings. Никаких generic-советов.
Request: {request}
Response: {response}
"""
Шаг 3: генерация шаблонов и вариация payload
Для найденных потенциальных уязвимостей - Nuclei с AI-генерацией шаблонов для быстрой проверки по аналогичным эндпоинтам. Для bypass-пейлоадов - отдельный чат с контекстом: «Фреймворк X, WAF Y фильтрует Z, нужны обходные варианты».Шаг 4: оформление репорта
Модель отлично структурирует репорт - Target, Environment, Steps to Reproduce, Observed/Expected Result, Security Impact, Suggested Fix. Но каждый факт в репорте должен быть вами проверен. Я перед отправкой прохожу по каждому шагу руками - воспроизвожу от начала до конца. По данным Intigriti, растёт количество AI-сгенерированных out-of-scope сабмишенов - это прямой путь к бану в программе. Не будьте тем человеком.
На что обратить внимание: дисциплина и атрибуция
Anthropic в ноябре 2025 сообщила о пресечении того, что описано как первая задокументированная крупномасштабная кибератака без существенного участия человека - атакующие использовали Claude Code против порядка тридцати целей. Обе стороны медали: AI ускоряет как исследователей, так и злоумышленников.В терминах MITRE ATT&CK атакующие используют Vulnerability Scanning (T1595.002, Reconnaissance) для автоматизированного сканирования, Code Repositories (T1593.003, Reconnaissance) для поиска утечек в публичных репозиториях, Scan Databases (T1596.005, Reconnaissance) для сбора информации из баз уязвимостей. AI усиливает каждую из этих техник.
Для исследователей это значит: автоматизация пентеста с AI требует такой же дисциплины авторизации, как любой другой инструмент. Прочитайте scope-документ сами, разметьте границы сами, и только потом используйте AI для сжатия и структурирования того, что вы уже знаете. Модель не защитит вас от фаззинга wrong host или replay state-changing запросов на продакшене. «AI сказал, что можно» - не аргумент на разборе инцидента.
HackerOne в январе 2026 расширила программу Good Faith AI Research Safe Harbor - направленную на снижение юридической неопределённости вокруг ответственного тестирования AI-систем. Но safe harbor не заменяет чтение конкретных правил программы.
Вопрос к читателям
В исследовании Wiz AI-агент решил 9 из 10 лабораторных задач при стоимости $1–$10 за успех. Но при расширении скоупа один из агентов совершил 500+ вызовов инструментов за час и ничего не нашёл. Те, кто уже интегрировал Claude Code или аналогичный AI-агент в свой recon pipeline через BBOT или Amass - на каком этапе вы ограничиваете скоуп для модели? Передаёте один поддомен за итерацию или целый outputbbot -p web-thorough? Какой формат входных данных (JSON, plaintext, filtered CSV) давал лучший signal-to-noise ratio на выходе? Делитесь в комментариях - интересно сравнить подходы.
Последнее редактирование модератором:
