За последний год я перестроил свой рабочий пайплайн так, что LLM-агенты участвуют минимум в трёх этапах каждого проекта. Не потому что хайп - а потому что на внешнем пентесте банковского приложения Claude за 4 минуты корректно выстроил приоритизацию 187 находок Nuclei, на которую раньше уходило полтора часа ручной работы. Но на том же проекте GPT-4o сгенерировал payload для SQLi с несуществующей функцией MySQL - запусти я его на проде, база бы легла. Два опыта, один проект, одна неделя.
Автоматизация пентеста с помощью искусственного интеллекта - не магия и не маркетинговый буллшит. Это конкретный инструментарий с измеримым выигрышем на одних фазах и опасными провалами на других. Дальше - разбор того, где LLM-агенты реально экономят часы, какие результаты показывают в исследованиях, и в каких точках AI пентест гарантированно сломается.
Где LLM-агенты реально работают в kill chain
Русскоязычные обзоры обычно перечисляют «этапы, где AI помогает» списком без конкретики. Я делю kill chain на зоны по реальному соотношению выигрыша и риска, привязывая каждую к MITRE ATT&CK. Подробнее - в нашем руководстве по безопасность llm атаки.Разведка и перечисление: максимальный выигрыш
На этапе Vulnerability Scanning (T1595.002, Reconnaissance) и Network Service Discovery (T1046, Discovery) LLM работает как интеллектуальный парсер. Скармливаете ему выводnmap -sV --top-ports 1000 - и вместо ручного grep-а по 200 строкам получаете структурированную таблицу: порт, сервис, версия, известные CVE для этой версии, рекомендуемый следующий шаг. На реальных проектах экономия - от 40 минут до 2 часов на каждый хост, зависит от количества сервисов.Ключевой момент: LLM не сканирует сеть. Он анализирует уже собранный output. Данные о целевой инфраструктуре можно обрабатывать локальной моделью через Ollama - ничего не уходит в облако. Для NDA-проектов это критично.
Анализ и приоритизация: сильный выигрыш с оговорками
Когда у вас 200 находок от Nuclei и нужно за час выдать заказчику top-10 для немедленного фикса - LLM справляется лучше механической сортировки по CVSS. Модель учитывает контекст: если на хосте одновременно открыты порт 3389 и обнаружена уязвимость SMB, она корректно повысит приоритет - это указывает на потенциальный lateral movement. Автоматический анализ уязвимостей в таком формате - не замена эксперту, но хороший фильтр первого прохода.Генерация отчётов: стабильный выигрыш
Превращение сырых логов в читаемый отчёт с рекомендациями - задача, с которой LLM справляется предсказуемо хорошо. На каждом проекте я экономлю 2-3 часа на оформлении. Модель берёт вывод инструментов, группирует находки по severity, добавляет описания и рекомендации. Достаточно финальной вычитки - не переписывания с нуля.Эксплуатация и пост-эксплуатация: зона повышенного риска
А вот тут начинается самое интересное. GPT-4o пентест на этапе генерации payload-ов выглядит красиво - модель выдаёт синтаксически корректный код, который при беглом осмотре кажется рабочим. Но в конкретной среде с нестандартной конфигурацией WAF или кастомным обработчиком запросов сгенерированный эксплойт не работает. Хуже того - может вызвать непредсказуемое поведение на продуктивном сервисе.При пост-эксплуатации и боковом перемещении модели теряют контекст. На седьмом-восьмом шаге эскалации привилегий Claude начинает «забывать», что на третьем шаге мы уже получили хэш сервисного аккаунта. Это не теория - я сталкивался с этим при тестировании Active Directory-сред, где цепочка действий легко достигает 15-20 шагов. Модель на 12-м шаге предлагает то, что ты уже делал на 4-м, и игнорирует собранные данные. Бесит.
Практический workflow: от Nmap до приоритизированных векторов атаки
Вот конкретная последовательность действий, которую я использую на каждом внешнем пентесте. Никакого чат-интерфейса - работа через API.CheckMate, Big Sleep и AIxCC: что показали исследования
Большинство русскоязычных материалов по теме AI red team останавливаются на уровне «LLM помогает в разведке». Между тем в 2024-2025 годах прошли исследования, которые количественно измерили возможности LLM-агентов в пентесте.CheckMate: классическое планирование + LLM
Согласно arxiv-препринту (Automated Penetration Testing with LLM Agents and Classical Planning), авторы предложили архитектуру из трёх компонентов: Planner, Executor и Summarizer. Главный вывод: Claude Code (CLI-инструмент Anthropic поверх Claude 3.5 Sonnet) «из коробки» показал лучшие результаты среди всех существующих автоматизированных систем пентеста. Но при детальном разборе вылезли конкретные слабости: LLM-агенты плохо удерживают долгосрочные планы, слабо выполняют сложные рассуждения и неэффективно используют специализированные инструменты.Фреймворк CheckMate решает эти проблемы, интегрируя классическое планирование (представление планов как направленных ациклических графов) с LLM-агентами. По заявлениям авторов, на отдельных метриках бенчмарка успешность превысила Claude Code более чем на 20%, при сокращении времени и стоимости более чем на 50% (конкретные цифры зависят от подмножества задач - см. оригинальный препринт). Для практика вывод простой: сырой LLM-агент - уже state-of-the-art, но структурированная обвязка вокруг него критически повышает и результат, и стабильность.
Google Big Sleep: LLM находит 0-day в SQLite
По данным DarkNavy, в ноябре 2024 года проект Google Big Sleep (эволюция Naptime) обнаружил уязвимость в SQLite - stack buffer underflow вseriesBestIndex (OOB-доступ по отрицательному индексу к массиву на стеке) - в development-ветке до релиза. Её исправили до выпуска, реальные пользователи не пострадали.Что интересно: агент, просматривая код, «зацепился» за assertion в уязвимой функции - примерно так, как это сделал бы живой исследователь. Построил SQL-запрос, приводящий к
iColumn=-1 (ROWID) внутри seriesBestIndex, и через дебаггер подтвердил OOB-доступ. В релизной сборке assertion отсутствовал, что делало уязвимость эксплуатируемой.Архитектура Naptime давала агенту инструменты, имитирующие работу человека: code browser для навигации по репозиторию, debugger для динамического анализа, Python-окружение для точных вычислений промежуточных состояний. Именно комбинация LLM-понимания кода с детерминированной верификацией через дебаггер позволила избежать ложных срабатываний. Без дебаггера агент бы, скорее всего, нагаллюцинировал себе «уязвимость» - а тут проверил и подтвердил.
AIxCC: машинное обучение пентест в соревновательной среде
На полуфиналах AIxCC (AI Cyber Challenge) команды тестировали свои Cyber Reasoning Systems на реальных проектах: Linux Kernel, Nginx, SQLite3, Jenkins. Согласно данным DarkNavy, подходы различались: Theori использовала LLM для генерации фаззинг-тестов и harness-ов, увеличивая покрытие фаззера. Team Atlanta пошла другим путём - концепция «baby-security-AGI»: дистилляция опыта живых исследователей в структурированные промпты, позволяющие агенту Atlantis воспроизводить привычки экспертов при аудите кода.Любопытное ограничение: при ограниченном бюджете на токены для проектов масштаба Linux Kernel команды думали не о том, как «скормить весь код модели», а о том, как эффективно выбрать ключевые сегменты для анализа. Это зеркалит реальность любого коммерческого пентеста - контекстное окно и бюджет конечны.
GPT-4o vs Claude в offensive-задачах: практическое сравнение
Я использовал обе модели через API на десятках проектов. Вот конкретные различия, которые имеют значение для пентестера.| Задача | GPT-4o | Claude 3.5/4 |
|---|---|---|
| Парсинг вывода Nmap | Хорошо, но иногда придумывает CVE | Точнее, реже галлюцинирует на версиях |
| Приоритизация находок | Склонен к завышению severity | Более консервативные оценки |
| Генерация payload-ов | Быстрее, но чаще ошибается в синтаксисе | Медленнее, но чаще рабочий результат |
| Анализ исходного кода | Сильнее на популярных языках (JS, Python) | Лучше на C/C++ и нестандартных конфигах |
| Длинные сессии (15+ итераций) | Теряет контекст после 10-12 шагов | Держит контекст дольше, до 15-18 шагов |
| Работа с MCP-протоколом (свойство клиента, не модели) | Через сторонние MCP-клиенты или OpenAI Agents SDK | Нативная поддержка в клиенте Claude Desktop |
Claude hacking-сценарии через MCP - отдельная тема. Model Context Protocol позволяет дать Claude доступ к
nmap, sqlmap, gobuster через стандартизированный интерфейс. Но тут есть подвох: согласно исследованию Embrace The Red, описание MCP-инструмента встраивается в системный промпт. Вредоносный MCP-сервер может вставить в description скрытые инструкции, перехватывающие поведение модели, включая невидимые Unicode Tags. Перед подключением стороннего MCP-сервера - читайте его исходный код целиком. Не поленитесь.Где AI гарантированно ломается: пять конкретных провалов
LLM агенты безопасность - тема, где честность важнее хайпа. Вот провалы, которые я наблюдал лично и которые подтверждаются исследованиями.Галлюцинации CVE
GPT-4o при запросе «какие CVE актуальны для Apache 2.4.51» выдал CVE-2024-XXXXX, которого не существует в NVD. Модель сгенерировала правдоподобный идентификатор, описание и даже CVSS-скор. Всё красиво, убедительно - и полностью выдумано. На реальном пентесте включение несуществующей CVE в отчёт - удар по репутации, от которого потом долго отмываешься.Контрмера: любой CVE-идентификатор из LLM проверяется через NVD API -
curl https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-XXXX-XXXXX - перед включением в отчёт. Без исключений.Потеря контекста в длинных цепочках
Исследование CheckMate подтверждает: LLM-агенты «часто застревают в повторяющихся и непродуктивных итерациях». На практике это выглядит так: после 12 шагов эскалации привилегий в AD модель предлагает действие, которое уже выполнялось на шаге 4, и игнорирует собранные промежуточные данные. Как напарник с амнезией.Нестандартные протоколы и закрытые среды
LLM обучены на публичных данных. Проприетарный протокол SCADA-системы или кастомный бинарный протокол IoT-устройства - слепое пятно. AI assisted exploitation в таких средах не работает. Тут нужен ручной реверс, и никакой промпт это не заменит.Бизнес-логика
Уязвимости бизнес-логики (IDOR, race condition в процессе оплаты, обход workflow) требуют понимания, как приложение должно работать. LLM видит код, но не понимает бизнес-контекст. На одном проекте модель пропустила классический IDOR в API эндпоинте - формально запрос валидный, просто принадлежал другому пользователю. Для модели - всё нормально. Для безопасности - дыра.Brute Force и словарные атаки
Для техник типа Brute Force (T1110, Credential Access) LLM бесполезен в реальном времени - это задача дляhydra, hashcat или Metasploit-модулей с правильным словарём. Модель может помочь составить кастомный wordlist на основе OSINT-данных о компании (имена сотрудников, даты основания, продукты - из этого неплохо собирается словарь), но сам перебор - вычислительная задача, не лингвистическая.Собираем LLM-assisted pipeline: минимальный рабочий набор
Требования к окружению
- Kali Linux 2024.x или Parrot OS 6.x
- Python 3.10+,
pip install requests - Для offline-режима: Ollama + модель
mistral:7bдля простого парсинга/нормализации (хватит 6 ГБ VRAM), либо 70B-класс (Llama 3.3 70B, Qwen 2.5 72B) для приоритизации уязвимостей (2×24 ГБ VRAM или Q4-квантизация) - Для облачного режима: API-ключ Anthropic (Claude) или OpenAI (GPT-4o)
Этап 1: автоматизированный сбор
Классический pipeline:nmap для Network Service Discovery (T1046), nuclei для проверки по шаблонам, subfinder для перечисления субдоменов. Вывод сохраняется в JSON/XML.Этап 2: нормализация и подача в LLM
Скрипт на Python читает JSON-выводы, формирует компактный контекст (только значимые поля), добавляет ролевой промпт и отправляет через API. Для NDA-проектов - через Ollama локально, для допустимых - через облачный API.Этап 3: верификация и ручная доводка
Выход LLM - не финальный результат, а черновик. Каждый предложенный вектор проверяется вручную. Каждый упомянутый CVE - через NVD. Каждая рекомендуемая команда - в изолированной среде перед применением к цели. Без этого шага вся автоматизация - русская рулетка.Этот трёхэтапный подход - суть того, как работает автоматизированное тестирование на проникновение с LLM в 2025 году. Не полная автономия, а усиление человека.
Что дальше: тренды 2025-2026
Согласно прогнозам MarketsandMarkets (цитируются в исследовании CheckMate), глобальный рынок пентеста - 1.7 миллиарда долларов в 2024 году с прогнозом роста до 3.9 миллиарда к 2029. Сегмент PTaaS (PenTesting-as-a-Service) - с 118 до 301 миллиона за тот же период. Деньги идут в автоматизацию.Но рост рынка не означает «заменят людей». Большие языковые модели в кибербезопасности - мультипликатор: один опытный пентестер с правильно настроенным LLM-pipeline покрывает объём работы, который раньше требовал троих. Нейросеть для поиска уязвимостей - не автопилот, а турбина: без пилота летит не туда.
За чем следить: мультиагентные архитектуры (CheckMate, AIxCC-подходы), интеграция LLM с символьным исполнением и фаззингом (подход Theori), MCP-протокол как стандарт подключения инструментов к моделям. Интеллектуальный анализ защищённости эволюционирует от «чатбот отвечает на вопросы» к «оркестратор координирует десять инструментов с верификацией каждого шага». Лично я ставлю на мультиагентность - один агент-планировщик + несколько агентов-исполнителей с узкой специализацией. CheckMate уже показал, что это работает.
Вопрос к читателям
В workflow выше нормализацию вывода Nmap перед подачей в LLM я делаю черезxmlstarlet - вытаскиваю port, service name, product, version. Но при большом количестве NSE-скриптов (особенно smb-enum-shares, http-title, ssl-cert) теряется критичная информация. Кто из вас уже строил подобный pre-processing pipeline для подачи в Claude или GPT-4o API - какие поля из nmap -oX вы сохраняете, а какие отбрасываете? Покажите ваш xmlstarlet/jq/Python-фильтр - интересно сравнить подходы.
