Запустить ИИ-агента на багбаунти — дело пяти минут. Зато превратить его поток сознания в принятые отчеты, чтобы не словить бан за спам и минус в рейтинге, — задача со звездочкой.
Привет, Хабр! Меня зовут Владислав, я работаю в отделе реагирования на инциденты в Бастионе и около полутора лет активно ханчу на багбаунти. Под Новый год мы с другом так пробили ИБ-интегратора (он, кстати, остался доволен), а недавно я выиграл Bug Zone 7.0. Подобные активности — хорошая возможность поэкспериментировать и выработать новые подходы, и последние полгода я ищу баги при помощи LLM. Так что с ИИ можно добиваться хороших результатов, а не сдавать мусор. Но как это делать?
Под катом вас ждут:
четыре подхода к ИИ-багхантингу;
четыре способа платить за модель;
три слоя верификации;
пайплайн из двух агентов;
живой разбор blind SSRF.
Спойлер: готовой кнопки «сделать хорошо» не ждите.
Статья будет интересна всем, кто уже натравливал ИИ на BB-программу и тонул в фолз-позитивах, а также новичкам и матерым этичным хакерам — хотя последним отдельные рекомендации наверняка покажутся очевидными.
Проблема триажера
Итак, вы натравливаете ИИ-агента на BB-программу, уходите по своим делам, а через час возвращаетесь и видите простыню, скажем, из 67 репортов. Из них:
28 штук — «SQLi», потому что сервер отдал 500 на одинарную кавычку в параметре;
22 — «XSS», поскольку в исходнике страницы отразился
<script>, а агент проглядел его блокировку со стороны Content Security Policy;9 — «открытые директории», которые оказываются публичными CDN-папками;
5 — «утечка API-ключей», но они давно отозваны, а один токен DaData вообще положено держать публичным.
Только 3 репорта указывают на настоящие уязвимости, которые можно было бы найти вручную за полчаса. Вместо этого пришлось целых три часа разбираться в отчетах. Поздравляю: вы только что поработали бесплатным триажером для своего ИИ-агента. Да, год назад модель попросту всё выдумала бы, но в этот раз она реально отправляла запросы и читала ответы, только это почему-то не радует.
Проблема в том, что автоматизация смещает бутылочное горлышко с поиска уязвимостей на проверку их реального наличия. И если инструмент генерирует сигналы быстрее, чем человек их обрабатывает, то суммарная эффективность в итоге падает, а не растет.
Мало просто найти признак возможной уязвимости — нужно еще доказать ее наличие, что особенно важно в российской инфраструктуре. РФ-сегмент богат легаси-системами с обилием багов, которые не представляют реальной опасности для бизнеса. Агенты легко находят такие проблемы и радостно вносят в репорт без проверки.
Выходит, ИИ в багхантинге — это просто генератор мусора? С точки зрения статистики не всё так однозначно.
Масштаб проблемы
По данным HackerOne, объем входящих репортов в 2026 году вырос на 76% год к году и в марте побил рекорд. Доля подтвержденных эксплуатируемых находок остается на уровне 25%, но доля critical и high увеличилась с исторических 26–28% до 32%. Платформа отдельно отмечает рост валидных ИИ-репортов на 210% за 2025 год. Да, возможно, это объясняется низкой базой, и всё же валидных отчетов становится больше. Хотя они и теряются в общем потоке. Недаром curl с 1 февраля 2026-го закрыл свою программу на HackerOne: если раньше примерно каждый шестой репорт касался настоящих уязвимостей, то теперь это в лучшем случае один из двадцати. Команда попросту устала разгребать эти “авгиевы конюшни”.
В апреле 2026-го HackerOne приостанавливал прием в Internet Bug Bounty. Недавно BI.ZONE и Standoff 365 ввели ограничения. Теперь количество отчетов, которые можно отправить за день, зависит от рейтинга исследователя на площадке. В свою очередь, Brave с начала 2025-го банит исследователя после двух репортов, закрытых как Spam или N/A, и требует ручной проверки багов с воспроизводимым PoC.
В этом контексте интересно свежее академическое исследование (Zheng et al., 2025) на 9 942 раскрытых HackerOne-репортах из 316 программ. Оказывается, несколько вариантов XSS в сумме составляют 13,8% всех сабмишенов, Information Disclosure — всего 9,4%, а Access Control вместе с Authentication — больше 10%. Но при этом исследователи пишут, что современные LLM склонны принимать невалидные репорты (over-accept), но прикрученный к нейронке RAG помогает решить эту проблему. Пока оставим этот вывод и вернемся к нему позже.
При этом популярность LLM в багхантинге растет: по опросам Bugcrowd, в текущем году 82% исследователей применяют генеративный ИИ (в 2024-м было 77%, в 2023-м — 64%). По РУ-рынку системной статистики почти нет, но тренд тот же. Весной этого года Всеволод Кокорин рассказывал, как сделал больше 10 тыс. долларов, потратив на токены меньше тысячи. Профильные специалисты также отмечают эту тенденцию, например, соответствующий разбор от nuit выходил у PT. По ощущениям многих хантеров валидных находок стало в полтора раза больше, а репортов — в три-четыре.
Зарубежные багбаунти-площадки пробуют собственный ИИ-триаж: HackerOne запустил h1 Validation и агента Hai. На РУ-площадках такого пока нет, но несколько команд признаются в кулуарах, что работают в этом направлении. Словом, проблема не в неспособности ИИ искать уязвимости. Большинство исследователей попросту останавливается на обнаружении и не делает следующего шага — автоматической верификации того, что выдала LLM.
Подходы к ИИ-багхантингу
Прежде чем решать эту проблему, посмотрим, какие подходы сейчас применяются. Их можно разделить на четыре группы по глубине автоматизации, стоимости и объемам ручного разбора, который в итоге ложится на плечи багхантера.
1. Ручной анализ и LLM-советник
Это выглядит примерно так: вы сидите в Burp или ZAP, перехватываете трафик и, заметив странности в поведении сайта, копируете запрос с ответом в чат модели:
«Что тут может быть уязвимым? Предложи пейлоад».
Это удобно: если хантеру не хватает экспертизы в конкретной области, модель быстро подскажет направление для продолжения исследования. Однако у такого подхода есть и минусы.
Плюсы:
нулевой порог входа: достаточно аккаунта Claude.ai или ChatGPT;
полный контроль: человек верифицирует каждый шаг;
минимальные затраты — free tier справляется;
никаких проблем со scope: границы программы вы держите сами.
Минусы:
не масштабируется, узкое место — сам человек;
подход плохо поддается автоматизации;
у LLM нет памяти между сессиями: она работает только с тем, что ей показали;
советы не всегда точны: модель не знает специфику конкретного приложения.
2. Автосканеры плюс LLM для интерпретации
Переходим на следующий уровень: nuclei, ffuf, sqlmap, dalfox занимаются непосредственно поиском, а модель разбирает и приоритизирует их срабатывания. В такой схеме багхантер отсматривает предварительно отфильтрованные отчеты.
Плюсы:
покрытие значительно ускоряется: сканер обрабатывает тысячи эндпоинтов;
LLM снижает нагрузку на человека-триажера;
хорошо работает для поиска известных CVE и типовых паттернов.
Минусы:
сканеры не понимают бизнес-логику, видят только паттерны;
LLM по-прежнему интерпретирует ответ, а не верифицирует его активно;
нет памяти: если вчера этот паттерн был FP, сегодня LLM об этом не знает.
3. Коробочный агент
В этом сценарии вы не запускаете инструменты сами, а говорите Claude Code, Cursor Agent или аналогу: «вот цель, найди уязвимости». Агент сам решает, чем воспользоваться, и сам пишет отчет. Именно этот подход сейчас набирает популярность и приводит к генерации уймы нейрослопа. У агента из коробки нет security-экспертизы для проверки (он знает, что такое SSRF, но не знает, что ее надо подтверждать через OOB), правил верификации и памяти о вчерашних ошибках, зато есть встроенное желание угодить пользователю любой ценой.
Плюсы:
низкий порог входа и высокая скорость запуска: одна команда — и агент работает;
не нужно вручную оркестрировать инструменты.
Минусы:
нет security-экспертизы из коробки;
нет правил верификации и памяти о прошлых ошибках;
confirmation bias: агент, выдвинувший гипотезу, склонен ее же и «подтвердить».
4. Верифицированный пайплайн
На мой взгляд, это наиболее зрелый подход, которым можно решить проблему триажера. Он подразумевает агентов со специальной обвязкой из нескольких слоев: правил, которые агент обязан выполнять, RAG-базы и MCP-инструментов для активной проверки гипотез. Дальше разберем эту систему по слоям на примере моей инфраструктуры, но сперва — о том, на каких моделях машинного обучения всё это базируется.
За что и как платить
Локальные модели (на базе Ollama, LM Studio, vLLM) позволяют экономить на оплате токенов и сохранять полную конфиденциальность. Правда, ниже 70B полноценные агентские пайплайны пока работают нестабильно, а макбуках же обычно используют модели объемом до 27B. Это становится препятствием для многих багхантеров. Далеко не у всех есть возможность запускать большие языковые модели на своем железе. Кажется, локальные модели стоит использовать для оффлайнового поиска по своей базе и бесплатного веб-серча, но не в качестве инструментов для поиска и разбора багов.
Использование API позволяет получить сильные модели с полным набором инструментов, и для серьезного автоматического пайплайна это оптимальный вариант. Подписка (Cursor, Claude.ai, ChatGPT) дает предсказуемый счет и готовую агентную среду с MCP, но часто упирается в rate limits и плохо встраивается в автоматизацию. Корпоративные же платформы типа Bedrock, Azure OpenAI, Vertex AI, кажется, избыточны для индивидуального багхантерства.
Важно подсчитывать экономику и распределять задачи в зависимости от сложности: рутину и объемные ресерчи отдавать модели подешевле, а дорогие reasoning-модели задействовать там, где нужна глубокая экспертиза. Тогда экономика сходится. По моему опыту, одна средняя находка обычно окупает месячные затраты на токены.
Конечно, нужно учитывать, что при выдаче задачи облачной LLM вы отправляете ее трафик третьей стороне и учитывать при работе.
Госсектор и оборонку в принципе не стоит исследовать с иностранным ИИ. Во всех остальных случаях нужно сверяться, не запрещено ли это правилами программы, в которой вы участвуете.
Корпорациям вряд ли есть дело до уязвимостей какого-нибудь чайного магазина, и здесь моя позиция проста: пусть лучше цель первыми изучают с помощью ИИ белые хакеры, чем злоумышленники. Они пользуются тем же Claude и ChatGPT.
Архитектура проверки находок
Итак, модель выбрана. Теперь самое интересное — сделать так, чтобы она не засыпала вас десятками сомнительных находок.
Большинство ложных срабатываний появляется не потому, что модель "глупая", а потому, что ей нечем проверить собственные выводы. Для этого в моем пайплайне есть три слоя: правила, RAG и MCP. Разберем каждый по отдельности.
Слой 1. Правила для агента
Вот базовое и несложное правило: просто заставьте агента спрашивать у самого себя, заплатят ли за это на ББ и каков реальный импакт от находки. После прямого вопроса про импакт модель часто сама дает задний ход и отбраковывает мусор. Впрочем, это только начало верификации — следующие правила уже не такие простые.
Нужно ввести в контекст модели жесткие условия верификации найденных багов, которые агент обязан выполнить перед отчетом об уязвимости. Вот только некоторые примеры:
есть подозрение на SQLi — проверь time-based;
перед SSRF получи OOB-взаимодействие;
перед XSS открой пейлоад в headless-браузере и убедись, что он исполнился.
Если одна и та же ошибка повторяется, правило лучше дописать на обязательный ретест. Без такого чеклиста в системном промпте агент будет торопиться с выдачей ответа: увидел 500 — написал SQLi. Но даже с чеклистом возможны проблемы: в длинных сессиях правила попадают под суммаризацию и сжимаются до пары абстрактных, бесполезных на практике принципов.
Слой 2. RAG: память и экспертиза
RAG (Retrieval-Augmented Generation) позволяет модели обращаться к внешней базе знаний в момент генерации ответа. В багхантинге это значит, что каждая находка сверяется с тысячами задокументированных паттернов уязвимостей. Так модель подтягивает свежие техники обхода, которых не было в ее обучающей выборке, избавляется от галлюцинаций в мелких деталях атак и накапливает память об ошибках.
Моя RAG-база сейчас содержит около 16,5 тыс. векторных записей — это чанки из пейлоадов, методик и writeup’ов, по которым работает семантический поиск. Граф знаний охватывает почти весь MITRE ATT&CK: 703 техники, 14 тактик, 181 APT-группа, 785 единиц ПО, 268 митигаций, 30 CWE. Все это берется из общеизвестных источников: MITRE, HackTricks, пейлоад-листов с гитхаба и — отдельно ценные — disclosed-репорты с HackerOne (по ним видно, что и при каком импакте уже принимали).
Это дает цикл обратной связи. Когда я ловлю ложное срабатывание и разбираюсь, почему не смог сам его отбраковать или докрутить находку, то записываю выводы в RAG. В следующий раз агент по этому вектору поднимет нужный кусок базы и уже не повторит ошибку. Со временем агент набирает опыт и работает лучше, а база превращается в личное конкурентное преимущество, кодируя специфичный для ваших целей опыт.
Мой любимый пример: агент честно вытащил «с ручки» данные, похожие на персональные, и тут же оформил отчет об утечке. На деле это был тестовый сегмент с правдоподобными данными, доступный из открытого раздела сайта. Модель увидела «ПДН» и не проверила, открыта ли информация. На такие случаи я вписал в базу правило: на любой утечке сперва проверь, нет ли этих данных в открытых источниках.
Слой 3. MCP: инструменты активной проверки
Anthropic придумала удобный стандарт, который позволяет подключать к агентским системам внешние инструменты. В моем наборе MCP: OOB-инфраструктура (interactsh или Burp Collaborator для blind SSRF и blind XSS), headless Playwright для проверки исполнения JS-пейлоада, nuclei с нужными шаблонами. Всё это вынесено с рабочего ноута на удаленку — несколько изолированных контейнеров с базовым набором команд и автоочисткой. При такой схеме параллельные субагенты не мешают друг другу, поскольку выходят в сеть через разные прокси и крутятся в разных контейнерах.
Покажу на примере blind SSRF, зачем это нужно:
Агент видит параметр, куда, судя по названию, передается URL.
Делает вывод: возможная SSRF.
Пытается считать ответ, но это не выходит; агент решает, что инъекция слепая.
Агент уже готов написать репорт, но как доказать наличие уязвимости? Если цель за CDN, какой-никакой импакт есть: через внешнее обращение можно раскрыть реальный IP.
Включается удаленный MCP. Поднимаем вебхук, просим агента отправить запрос на наш адрес и смотрим, прилетело ли. Прилетело — значит, у вас автономно подтвержденный blind SSRF. Импакт, может, и невелик, но право на выплату вы докажете не на словах и всё же получите баунти.
Пайплайн двух агентов
Также важно, как именно эти слои соединены в единую систему. Идея простая: находку не должен проверять тот агент, который ее нашел. Лично я использую связку из двух LLM. Агент обнаружения заточен на recall, чтобы найти как можно больше кандидатов. Агент верификации нацелен на precision, чтобы отсеять всё лишнее, выполняя Rules и собирая доказательства через MCP.
Часто пишут, что нужны разные модели, а лучше разные провайдеры. На практике можно использовать одну и ту же модель может быть одна и та же, а вот сессия должна быть новой. Иначе выдвинувший гипотезу агент сам себя в ней и убедит. Разные модели или провайдеры прибавляют еще немного независимости, но это лишь приятный бонус.
Где это всё еще хромает
Конечно, такой подход — не серебряная пуля. Основная его проблема — быстрое исчерпание контекста, который быстро тратится на правила и рассуждения модели. Приходится всё тщательно документировать и структурировать: помещать находки в отдельные файлы, ошибки — в RAG, лучшие практики — в правила.
Строгих замеров я не делал, но по факту «информативов» у меня почти не осталось. Почти все мои отчеты принимают, и это главное.
Что в сухом остатке
Такой пайплайн не заменяет исследователя, а лишь снимает с него роль триажера. В результате багхантер сосредотачивается на более интересных творческих задачах и нетривиальным векторам, которые не видит машина. Наверняка многие багхантеры скажут: «всё это оверинжиниринг, а найти дорогую багу можно с Burp и одной моделью», другие принципиально не используют LLM — и будут по-своему правы. Порой одна удачная находка окупает сотни часов поиска. Но я и не ставил цель рассказать о поисках самых жирных векторов. Речь идет о том, как упростить себе жизнь, минимизировать разбор мусора и поднять эффективность работы LLM.
Рано или поздно дешевые токены закончатся, и тогда всем позарез потребуются оптимизированные инструменты. Это актуально не только для багхантинга: вся IT-индустрия строится вокруг ИИ harness — обвязку, которая превращает умную модель в полезную. Почему бы не попробовать и нам?
К тому же описанный подход можно рассматривать как базовую гигиену при работе с багбаунти и банальную вежливость. Воспитанный ресерчер — подарок для программы: ее сканируют дорогими LLM, а платит она только за подтвержденное. Те же нейронки в руках нечистоплотного исследователя скорее приведут к замусориванию и закрытию программы. Чем больше хантеров научиться самостоятельно отбраковывать фолзы, тем сильнее разгрузится триаж площадок, и мы сохраним открытые багбаунти-программы.
А где проходит ваша граница между нормальной автоматизацией и нейрослопом, и что делать площадкам с этой проблемой? Пишите свое мнение в комментариях.
PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикад
t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона