Сергей Попов
Администратор
- 30.12.2015
- 4 916
- 6 611
- Специализация
- OSINT
- Веб-безопасность
- Статус верификации
- ✓ Verified
За последние восемь месяцев я впихивал LLM-инструменты в десятки реальных engagement'ов - от bug bounty до red team-контрактов на финтех. Не потому, что ИИ «взламывает за вас» (спойлер: не взламывает), а потому, что он разгребает nmap-вывод на 3000 строк, парсит минифицированный JS и пишет черновик отчёта за минуты. Всё остальное - по-прежнему руками и головой.
Русскоязычное инфополе по теме «автоматизация пентеста ИИ» выглядит уныло: либо маркетинговые списки «10 инструментов для наступательной безопасности», либо toy-примеры с
transformers.pipeline("summarization"), которые никогда не увидят боевого проекта. В англоязычном пространстве получше - есть бенчмарки, архитектурные разборы, реальные данные с HackerOne. Эта статья - синтез обоих миров: практический опыт, подкреплённый цифрами из первоисточников, а не из training data.Разберём конкретно: какие задачи искусственный интеллект в кибербезопасности решает уже сейчас, где он предсказуемо ломается, и как собрать workflow, который реально ускоряет работу, а не создаёт иллюзию автоматизации тестирования на проникновение.
Семь рынков под одной вывеской: почему сравнения AI-инструментов бесполезны
Главная беда обзоров «лучшие автоматический пентест инструменты» - в них сваливают в одну кучу принципиально разные вещи. Burp AI-расширение, автономный black-box сканер, платформу валидации attack path и фреймворк для red teaming LLM-приложений сравнивают так, будто они конкуренты. Это как сравнивать Burp Repeater с Nessus - оба про безопасность, но разные задачи-то.По классификации Penligent, рынок AI pentesting tools в 2026 году делится на семь сегментов:
- AI-ассистенты внутри существующих инструментов - BurpGPT, расширения для Metasploit. Не заменяют workflow, а дополняют
- Генераторы покрытия API - StackHawk с генерацией OpenAPI-спецификаций из исходного кода
- Автономные black-box движки - Escape с мультиагентным подходом к разведке, эксплуатации и валидации
- Валидаторы attack path - NodeZero, Pentera. Доказывают эксплуатируемость, а не просто наличие уязвимости
- Операторские фреймворки - PentestGPT как reasoning layer поверх вашего тулчейна
- Red teaming AI-приложений - Promptfoo для тестирования LLM, MCP-серверов, RAG-систем
- Continuous attack surface monitoring - Hadrian и аналоги
Согласно NIST, фреймворк тестирования безопасности строится вокруг планирования тестов, их проведения, анализа и разработки митигаций. А OWASP AI Testing Guide, OWASP Top 10 for LLM Applications 2025 и OWASP Agentic AI Threats and Mitigations - это отдельная дисциплина: тестирование самих AI-систем на prompt injection, tool misuse, data exfiltration. Путать два направления - значит покупать не те инструменты и неверно оценивать покрытие.
ChatGPT пентест на реальных проектах: три рабочих сценария
Хватит теории. Вот три сценария, где LLM хакинг реально ускоряет работу, и один, где я потратил три часа впустую.LLM для разведки OSINT и анализа поверхности атаки
Разведка - этап, где искусственный интеллект в кибербезопасности даёт самый стабильный, измеримый результат. Причина простая: обработка большого объёма данных с выделением паттернов - ровно то, в чём LLM сильны.Мой workflow: запускаю стандартный стек -
subfinder, amass, nmap с нужными скриптами - и получаю сырой вывод, который вручную анализировать можно часами. Вместо этого скармливаю результат LLM со структурированным промптом:По MITRE ATT&CK это - Vulnerability Scanning (T1595.002, Reconnaissance), только автоматизированная через LLM. По данным practitioner-блога joshkerr.com, на одном из внутренних пентестов такой подход выделил Erlang Port Mapper Daemon на нестандартном порту - сервис, который легко проскочить при ручном анализе, но именно он стал точкой первоначального доступа.
Для поддоменной разведки - аналогичная схема: после
subfinder и amass прошу LLM найти паттерны именования (dev/staging/internal), «забытые» поддомены, нарушения naming convention. Задокументированный случай из той же практики - Jenkins-инстанс с дефолтными credentials на поддомене, выбивавшемся из общей конвенции именования. Классика Password Guessing (T1110.001, Credential Access), но без AI-анализа до него добрались бы на день позже.Критически важный нюанс: я никогда не отправляю в облачные LLM реальные данные клиента без NDA-покрытия и разрешения. Для чувствительных engagement'ов - self-hosted модели через
ollama или PentestGPT с локальным LLM routing (он поддерживает эту опцию как first-class функцию).GPT генерация эксплойтов и обход WAF
ChatGPT пентест реально блистает при генерации payload'ов - но не так, как обещают вендоры. LLM не «автоматически взламывает» цель. Он помогает сгенерировать вектор, когда вы точно описываете контекст.Реальный кейс из сообщества: PHP-приложение за Cloudflare WAF, boolean-based blind SQLi в параметре поиска, стандартные UNION-based payload'ы заблокированы. Оператор описал LLM точную картину - тип injection, WAF, backend MySQL 8.x, отсутствие error messages, наличие boolean-разницы. Модель предложила несколько подходов, включая Unicode normalization abuse: fullwidth-апостроф (
%EF%BC%87, U+FF07), который WAF пропускал, а backend нормализовал в обычный символ (например, через Normalizer::normalize() из PHP intl extension - PHP по умолчанию этого не делает). Техника близка к Command Obfuscation (T1027.010, Defense Evasion), и до неё было бы непросто дойти перебором стандартных списков из PayloadsAllTheThings.Обратная сторона. Я потратил три часа на engagement'е, где GPT-4 упорно генерировал SQLi-payload'ы для PostgreSQL, хотя backend был MSSQL. Модель «зациклилась» на неверной гипотезе и не могла из неё выйти - переформулирование промпта не помогало, пришлось начинать сессию заново. Типичная болезнь одиночного ReAct-цикла: агент теряет объективность и начинает «подтверждать» собственную ошибку. Три часа, которые я мог бы потратить на ручной анализ и уже найти баг.
Правило без исключений: никогда не запускайте AI-сгенерированный эксплойт, не понимая каждой строки. Я видел сгенерированные reverse shell'ы с некорректной обработкой сигналов и даже с hardcoded callback на чужой IP - то ли галлюцинация, то ли contamination из training data. Запустишь такое на клиентской инфраструктуре - и объясняй потом, почему shell стучал непонятно куда.
Автоматизация отчётов: 80% рутины за минуты
Написание отчётов - самая ненавистная часть пентеста. И здесь автоматизация пентеста ИИ экономит больше всего часов.Мой подход: во время тестирования веду сырые заметки в структурированном формате - finding, локация, severity, evidence, шаги воспроизведения, impact. После engagement'а скармливаю LLM с промптом на генерацию секций: executive summary с фокусом на бизнес-импакт, техническое описание, обоснование CVSS 3.1, рекомендации с примерами кода, ссылки на OWASP и CWE.
На выходе - 80% готового finding'а. Остальные 20% - доводка формулировок, клиент-специфичный контекст, верификация технической точности. Отчёт на 15 findings раньше занимал полный рабочий день. Сейчас - 3-4 часа. Это augmented red teaming в чистом виде: ИИ берёт рутину, человек отвечает за качество.
Архитектуры AI red team инструментов: от ReAct-цикла до мультиагентных роёв
Русскоязычные обзоры перечисляют инструменты списком, не объясняя, как они устроены изнутри. А без этого непонятно, чего от них ждать. По данным исследования AppSecSanta, на апрель 2026 года существует 39+ open-source AI-агентов для пентеста, построенных на шести архитектурных паттернах.Одиночный агент (ReAct loop) - самый простой вариант. Одна LLM получает задачу, генерирует действие, исполняет, читает результат, зацикливается. PentestGPT и hackingBuddyGPT работают именно так. hackingBuddyGPT позиционируется как минималистичный ReAct-агент; ранние демо-версии умещались в ~, текущий проект - полноценный фреймворк. Проблема: контекстное окно. Один вывод nmap-сканирования жрёт тысячи токенов, вытесняя предыдущие findings. По данным бенчмарка PentestEval (декабрь 2025), одиночные агенты «практически полностью проваливались» на end-to-end pipeline'ах.
Мультиагентный planner-executor - planner отвечает за стратегию, executor'ы - за тактику. Каждый executor получает фокусную подзадачу с чистым контекстным окном. Результаты HPTSA на бенчмарке из 14 реальных уязвимостей: иерархические команды агентов оказались значительно эффективнее одиночных (по данным arxiv.org/abs/2406.01637, конкретные метрики зависят от конфигурации эксперимента).
Мультиагент со специализированными ролями - агент разведки, агент эксплуатации, агент отчётности работают параллельно и обмениваются через общее состояние.
Динамический рой (swarm) - агенты создаются и уничтожаются по мере необходимости.
MCP-based - агенты через Model Context Protocol получают стандартизированный доступ к инструментам. Новый паттерн 2025-2026.
Claude Code native - агенты, использующие Claude Code как среду исполнения.
Самое интересное из данных AppSecSanta: CHECKMATE, использующий гибридный подход - LLM генерирует PDDL-описание, а классический AI-планировщик ищет оптимальную последовательность - превосходит нативного Claude Code-агента на 20%+ по success rate и на 50%+ по стоимости. Урок: не заставляйте LLM делать то, в чём алгоритмы из 1970-х уже справляются. Long-horizon planning - это задача для планировщика, а не для языковой модели.
Бенчмарки vs реальность: машинное обучение пентест под микроскопом
Данные, которые отрезвляют. По результатам агрегированных бенчмарков AppSecSanta:- GPT-4 эксплуатировал 87% one-day CVE на выборке из 15 уязвимостей (Fang et al., 2024), когда получал описание из advisory. Звучит как прорыв - но выборка мала, а методология оспаривалась: часть CVE была опубликована до cutoff date GPT-4, что указывает на data contamination
- На реальных CVE из CVE-Bench - только 13%. На сложных HackTheBox-машинах - практически 0%
- Разница между «прочитать описание уязвимости и применить известный exploit» и «найти уязвимость с нуля» - пропасть
- XBOW - автономный агент, занявший, по данным xbow.com, первое место на US-лидерборде HackerOne (лето 2025) с сотнями submissions различной severity. Это не лабораторный результат - это живая bug bounty площадка
- Google Big Sleep обнаружил первый AI-discovered zero-day: exploitable stack buffer underflow в pre-release ветке SQLite до попадания в stable-релиз (ноябрь 2024), который OSS-Fuzz пропускал
Ограничения автоматизации пентеста ИИ: пять точек отказа
Честный разговор о том, где инструменты предсказуемо ломаются. Не абстрактные «ложные срабатывания», а конкретные паттерны из практики.Потеря контекста в длинных сессиях. При глубоком тестировании - lateral movement, эскалация привилегий - агент теряет контекст через 15-20 шагов. «Забывает», какие credentials собраны, какие хосты скомпрометированы. По данным Penligent, это особенно критично при эскалации привилегий и боковом движении. Мультиагентные архитектуры частично решают проблему, но не снимают полностью.
Галлюцинации CVE и технических деталей. ChatGPT уверенно выдаёт несуществующие CVE-идентификаторы. Лично я ловил такое минимум трижды - модель генерирует правдоподобный CVE-YYYY-NNNNN, которого просто не существует в базе. Каждый CVE из вывода LLM верифицируйте через cve.mitre.org или nvd.nist.gov. Это не edge case - это системная проблема.
Неспособность рассуждать о бизнес-логике. BOLA, IDOR, privilege escalation через workflow - уязвимости, требующие понимания «как приложение должно работать». LLM видит HTTP-запросы и ответы, но не понимает бизнес-контекст. Согласно OWASP Web Security Testing Guide, broken authorization и workflow abuse - центральные категории уязвимостей, а не edge cases. ИИ для пентеста в этих категориях работает слабо.
Зависимость от качества промпта. Разница между «проанализируй nmap» и структурированным промптом с пятью конкретными вопросами - порядок величины в качестве выхода. Offensive security AI tools - инструмент, эффективность которого прямо пропорциональна квалификации оператора. Парадокс: чтобы хорошо использовать AI для пентеста, нужно уже быть хорошим пентестером.
Ложное чувство покрытия. Самый опасный сценарий. Команда запускает AI-сканер, получает «clean report» и считает систему безопасной. Агент не может найти уязвимость не потому, что её нет, а потому, что не умеет её искать. По данным Penligent, тест на реальность прост: может ли инструмент пройти аутентификацию на stateful-приложении, рассуждать об авторизации, доказать impact? Если нет - это сканер, а не пентестер, и относиться к его результатам нужно соответственно.
Пошаговый workflow: интеграция ИИ в пентест за один день
Для тех, кто хочет начать использовать большие языковые модели в безопасности прямо сейчас. Минимальный набор, проверенный на реальных проектах.Шаг 1 - Разведка и приоритизация. Запускаете
bbot -t target.com -p web-thorough --allow-deadly -om json --output-dir bbot_output/ для получения структурированного JSON с поддоменами, сервисами, портами. Передаёте вывод в LLM через API с промптом на приоритизацию: фокус на exposed admin panels, legacy services, high-value targets. На выходе - ранжированный список целей вместо 50-страничного сырого отчёта.
Python:
# Приоритизация BBOT-вывода через LLM API
import json, openai
# Путь: bbot_output/<scan_name>/output.ndjson
import glob
files = glob.glob("bbot_output/*/output.ndjson")
with open(files[0]) as f:
targets = [json.loads(line) for line in f if line.strip()]
prompt = f"""Ранжируй цели по эксплуатируемости.
Фокус: admin panels, legacy services, EOL software.
Данные: {json.dumps(targets[:50])}"""
resp = openai.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}]
)
print(resp.choices[0].message.content)/api/v2/admin, защищённый только boolean-флагом в JWT - тривиальный bypass после обнаружения.Шаг 3 - Генерация detection-шаблонов. Nuclei в актуальных версиях поддерживает AI-генерацию:
export PDCP_API_KEY=...; nuclei -ai "SSRF via redirect parameter on /api/v2/fetch" генерирует черновик YAML-шаблона (нужен API-ключ и платная подписка ProjectDiscovery Cloud Platform, paid tier с 2024), затем вы верифицируете YAML и запускаете отдельной командой nuclei -t generated-template.yaml -u https://target. Для bug bounty это критично - первый валидный submission выигрывает.Шаг 4 - Proxy-анализ. BurpGPT перехватывает request/response и отправляет LLM с промптом на поиск IDOR-кандидатов, auth bypass, нарушений бизнес-логики. В промпте обязательно:
"Provide specific, actionable findings only. No generic advice." Без этой инструкции модель будет генерировать общие рекомендации - «рассмотрите возможность внедрения WAF» и прочую бесполезную воду.Шаг 5 - Отчёт. Структурированные заметки из шагов 1-4 передаёте LLM для генерации черновика с executive summary, CVSS-обоснованием и рекомендациями. Проверяете, дорабатываете, отправляете клиенту.
Когда AI-инструмент - сам поверхность атаки
Парадокс 2026 года: инструменты для поиска уязвимостей сами становятся уязвимыми. В MITRE ATT&CK это отражено техникой Artificial Intelligence (T1588.007, Resource Development) - атакующие получают и используют AI-возможности, но те же инструменты могут быть скомпрометированы.Синтетический, но показательный пример - CVE-2025-12345 в LLM-Claw, учебный кейс buffer overflow в функции деплоя AI-агентов (CVSS 7.4, CWE-119/CWE-120). А вот реальный случай: CVE-2024-5565 в библиотеке Vanna.AI - prompt injection в методе
ask с параметром visualize=True приводил к выполнению произвольного Python-кода (CVSS 8.1 HIGH, CWE-94). Удалённая эксплуатация, не требующая аутентификации - в инструменте, который сам должен помогать с анализом данных. Ирония, да.Практический вывод: AI-агенты для пентеста - это код, и он требует собственного threat model. Минимум: запуск агентов в изолированных sandbox-контейнерах, ограничение сетевого доступа по принципу least privilege, аудит зависимостей и регулярное обновление. Если ваш инструмент для поиска уязвимостей сам не проходит базовый security review - он увеличивает поверхность атаки, а не сокращает её.
Попробуйте прогнать свой AI-тулчейн через тот же чеклист, который применяете к клиентским приложениям. Результат может неприятно удивить.
Последнее редактирование модератором:
