Статья AI пентест: как LLM-агенты ускоряют поиск уязвимостей и где ломаются на практике

[Сергей Попов]

Начну интересно, с неудобной правды. Полтора года я интегрирую LLM-агенты в свой рабочий процесс - от разведки до написания PoC. И картина, которую вижу, кардинально отличается от маркетинговых обещаний. GPT-4 действительно умеет вещи, которые ещё два года назад казались фантастикой. Но он же галлюцинирует имена бинарников, придумывает несуществующие флаги к nmap и уверенно предлагает exploit-цепочки, которые не работают от слова совсем. Эта статья - честный разбор того, где AI пентест реально экономит часы, а где создаёт иллюзию прогресса.

Почему LLM-агенты - это не просто чат-бот с доступом к терминалу​

Ключевое отличие LLM-агента от обычного промпта в ChatGPT - цикл «мысль-действие-наблюдение» (

Ссылка скрыта от гостей

). Агент не просто генерирует текст. Он выполняет действия через инструменты, смотрит на результат и решает, что делать дальше. На практике это выглядит так: агент запускает nmap, разбирает вывод, находит открытый 8080, решает просканировать веб-приложение, обнаруживает форму и пробует SQL-инъекцию.

Согласно исследованию Fang et al. (2024, arxiv:2404.08144), агент на базе GPT-4 с ReAct-фреймворком уместился в 91 строку Python-кода для оркестрации (без LangChain и набора инструментов). При этом он автономно эксплуатировал 87% из 15 one-day уязвимостей в контролируемой лабораторной среде - sandbox с заранее развёрнутыми уязвимыми приложениями - при наличии CVE-описания. Без описания - жалкие 7%. Вот эта цифра - ключевая: LLM-агенты на текущем этапе гораздо лучше эксплуатируют известные уязвимости, чем находят новые.

В терминах MITRE ATT&CK такое использование AI попадает сразу под несколько техник: Artificial Intelligence (T1588.007, Resource Development), Vulnerabilities (T1588.006, Resource Development) - сбор информации об уязвимостях, и Exploits (T1587.004, Resource Development) - создание или адаптация эксплойтов.

Автоматизация пентеста на каждом этапе kill chain​

Разведка и обнаружение сервисов​

Разведка - этап, где LLM-агенты приносят максимум пользы при минимальном риске галлюцинаций. Тут задача агента не генерировать факты, а структурировать и приоритизировать реальный вывод инструментов. По сути - умный парсер с мозгами.

Вот мой рабочий скрипт, который связывает nmap с LLM для автоматической приоритизации целей:

import subprocess
import json
import os

def run_nmap_scan(target, ports="1-10000"):
    """Запуск nmap с XML и grepable выводом за один проход"""
    xml_path = "/tmp/scan_result.xml"
    grep_path = "/tmp/scan_result.grep"
    cmd = [
        "nmap", "-sV", "-sC", "--open",
        "-p", ports,
        "-oX", xml_path,
        "-oG", grep_path,
        target
    ]
    # Примечание: -sV/-sC с SYN scan требуют root (или CAP_NET_RAW)
    result = subprocess.run(cmd, capture_output=True, text=True)
    if result.returncode != 0:
        raise RuntimeError(f"nmap failed: {result.stderr}")
    if not os.path.exists(grep_path):
        raise FileNotFoundError(f"{grep_path} not created")
    with open(grep_path, 'r') as f:
        return f.read()

def build_recon_prompt(nmap_output, target):
    """Формирование промпта для LLM-анализа результатов разведки"""
    return f"""Ты - пентестер. Проанализируй результаты nmap-сканирования цели {target}.

Результаты сканирования:
{nmap_output}

Задачи:
1. Перечисли все обнаруженные сервисы с версиями
2. Для каждого сервиса укажи известные CVE (если версия уязвима)
3. Ранжируй векторы атаки по вероятности успеха
4. Предложи следующие шаги разведки для каждого вектора

Формат ответа: JSON со структурой
{{"services": [...], "attack_vectors": [{{"target_url": "...", "vector": "...", "priority": 1}}], "next_steps": [...]}}"""

# Пример использования (псевдокод - LLM API вызов)
# requires: openai или anthropic SDK
# response = llm_client.chat(model="gpt-4", messages=[...])
# Далее парсим JSON и передаём next_steps в следующий этап пайплайна

По MITRE ATT&CK этот этап соответствует Network Service Discovery (T1046, Discovery) и Vulnerability Scanning (T1595.002, Reconnaissance). LLM тут не сканер, а аналитический движок поверх классических инструментов.

На практике LLM корректно определяет приоритеты атаки примерно в 70-80% случаев. Типичная ошибка - переоценивает экзотические сервисы и недооценивает мисконфиги в стандартных (забытый Tomcat с дефолтными кредами? «Низкий приоритет»). Но даже с учётом этого, ручная приоритизация сокращается с 40-60 минут до 10.

LLM уязвимости: анализ и классификация находок​

После разведки начинается анализ - и тут LLM-агенты показывают наибольший разрыв с традиционными инструментами. Классический сканер выдаёт список CVE по баннерам версий. LLM-агент может сопоставить найденные сервисы с контекстом приложения, разобраться в бизнес-логике и предложить нестандартные векторы.

Исследование PentestAgent (Shen et al., arxiv:2411.05185) показало подход с мульти-агентной архитектурой, где отдельные агенты специализируются на разведке, анализе уязвимостей и эксплуатации. Ключевая идея - RAG (Retrieval Augmented Generation) для обогащения контекста агента актуальными данными об уязвимостях, которые выходят за пределы training data модели.

PentestGPT развивает эту идею через Pentesting Task Tree (PTT) - древовидную структуру, где каждый узел - подзадача пентеста. По данным бенчмарков EmergentMind, на 182 подзадачах из HackTheBox и VulnHub структурированный подход PentestGPT заметно превосходит наивный промптинг по количеству решённых подзадач. При этом полностью автономные LLM-агенты решают лишь 21% реальных CTF-задач, тогда как полуавтономные (с человеком в цикле) - 64%. Разница в три раза - и это лучший ответ на вопрос «заменит ли AI пентестера».

Рабочий пример обогащения результатов nuclei через LLM API:

# Запуск nuclei с JSON-выводом
nuclei -u https://target.example.com -severity critical,high -json -o /tmp/nuclei_out.json

# Парсинг и передача в LLM для контекстного анализа
python3 enrich_findings.py /tmp/nuclei_out.json

import json
import sys

def load_nuclei_results(filepath):
    """Загрузка результатов nuclei в JSON-формате"""
    findings = []
    with open(filepath, 'r') as f:
        for line in f:
            try:
                findings.append(json.loads(line.strip()))
            except json.JSONDecodeError:
                continue
    return findings

def build_analysis_prompt(findings):
    """Промпт для LLM-анализа находок nuclei"""
    findings_text = json.dumps(findings[:20], indent=2)  # Лимит контекста
    return f"""Проанализируй результаты сканирования nuclei.
  
Находки:
{findings_text}

Для каждой находки определи:
1. Реальная эксплуатируемость (не все CVE одинаково опасны в контексте)
2. Цепочка атаки - как эта уязвимость может быть скомбинирована с другими
3. Приоритет исправления с учётом бизнес-контекста
4. Конкретные шаги для верификации (команды, скрипты)

Особое внимание удели ложноположительным - nuclei часто срабатывает по баннерам."""

if __name__ == "__main__":
    findings = load_nuclei_results(sys.argv[1])
    prompt = build_analysis_prompt(findings)
    print(prompt)
    # Далее отправка в LLM API - требует проверки в docs конкретного SDK

GPT эксплойт: генерация и адаптация payload-цепочек​

Этап эксплуатации - самый зрелищный и одновременно самый опасный в плане галлюцинаций. Исследование Fang et al. показало, что GPT-4 при наличии CVE-описания способен автономно эксплуатировать уязвимости: SQL-инъекции в WordPress, уязвимости контейнерных runtime (runc), проблемы в Python-пакетах и даже concurrency-атаки типа ACIDRain.

По MITRE ATT&CK это Exploit Public-Facing Application (T1190, Initial Access) и Python (T1059.006, Execution) - агент использует Python-интерпретатор для взаимодействия с целью.

Реальный сценарий, который я использую - генерация вариаций SQL-инъекций через LLM и проверка через sqlmap:

# Шаг 1: Обнаружение потенциальной точки инъекции
# (предположим, nuclei нашёл параметр id на /api/users)

# Шаг 2: Базовая проверка через sqlmap
# При установке из исходников используйте: python sqlmap.py -u ...
sqlmap -u "https://target.example.com/api/users?id=1" \
    --batch --level=3 --risk=2 \
    --technique=BEUSTQ \
    --random-agent \
    --output-dir=/tmp/sqlmap_results

# Шаг 3: Если sqlmap не справился (WAF, нестандартный синтаксис),
# передаём контекст LLM-агенту для генерации кастомных payload

def generate_sqli_bypass_prompt(url, parameter, waf_response, sqlmap_log):
    """Генерация промпта для обхода WAF через LLM"""
    return f"""Цель: {url}, параметр: {parameter}
  
sqlmap не смог автоматически эксплуатировать SQL-инъекцию.
Ответ WAF: {waf_response[:500]}
Лог sqlmap (последние 50 строк): {sqlmap_log[-2000:]}

Задача:
1. Определи тип WAF по паттерну ответа
2. Предложи 5 техник обхода для этого WAF
3. Для каждой техники сгенерируй конкретный payload
4. Укажи, какой tamper-скрипт sqlmap использовать

Формат: JSON с полями bypass_technique, payload, sqlmap_tamper"""

Вот тут LLM реально помогает - он знает десятки техник обхода WAF из training data и может комбинировать их нестандартно. Но каждый предложенный payload нужно проверять руками: примерно в 30% случаев LLM выдаёт синтаксически кривые конструкции или payload, рассчитанные на другой тип СУБД. Лично у меня был случай, когда агент упорно генерировал payload для MySQL, хотя по баннеру торчал PostgreSQL.

AI red team: мульти-агентные системы и zero-day​

Самый интригующий тренд - команды LLM-агентов для обнаружения zero-day уязвимостей. Согласно препринту Fang et al. (arxiv:2406.01637), команды LLM-агентов смогли эксплуатировать уязвимости, отсутствовавшие в обучающих данных модели (т.н. zero-day в контексте бенчмарка), в контролируемой лабораторной среде. Это не то же самое, что обнаружение реальных 0-day в production, но качественный скачок по сравнению с одиночными агентами.

Архитектура мульти-агентной системы для пентеста обычно включает:

• Агент-разведчик - OSINT и сканирование (T1595.002, Reconnaissance)
• Агент-аналитик - классификация находок, сопоставление с CVE-базами
• Агент-эксплойтер - генерация и тестирование payload-цепочек
• Агент-координатор - управление деревом задач, распределение приоритетов

По результатам Shen et al. (arxiv:2411.05185), мульти-агентная архитектура PentestAgent с RAG-обогащением и специализированными ролями превосходит наивное использование vanilla GPT-4 на задачах пентеста. PentestGPT подтверждает ту же тенденцию: структурированный подход с PTT заметно улучшает результаты по сравнению с прямым промптингом. Специализация агентов работает, но масштаб преимущества зависит от условий эксперимента и конкретного бенчмарка.

Нейросеть пентест: автоматический поиск уязвимостей в коде​

Отдельная область, где LLM-агенты показывают сильные результаты - автоматический анализ исходного кода. Я использую связку semgrep + LLM для поиска логических уязвимостей, которые статические анализаторы пропускают.

# Шаг 1: Запуск semgrep с правилами OWASP
semgrep --config "p/owasp-top-ten" --json \
    --output /tmp/semgrep_results.json \
    /path/to/target/source

# Шаг 2: Передача результатов и исходного кода LLM-агенту
# для поиска логических уязвимостей вокруг найденных точек

def build_code_review_prompt(semgrep_findings, source_file_content):
    """Промпт для глубокого анализа кода вокруг находок semgrep"""
    return f"""Результаты semgrep обнаружили потенциальные уязвимости.
  
Находки semgrep:
{json.dumps(semgrep_findings[:10], indent=2)}

Исходный код файла:
{source_file_content[:4000]}

Задачи:
1. Проверь каждую находку semgrep - является ли она реальной уязвимостью
   или ложноположительной в данном контексте
2. Найди логические уязвимости, которые semgrep пропустил:
   - IDOR (Insecure Direct Object Reference)
   - Race conditions
   - Некорректная валидация бизнес-логики
   - Нарушения авторизации между ролями
3. Для каждой реальной уязвимости опиши PoC-сценарий эксплуатации"""

По моему опыту, LLM находит дополнительно 15-25% логических уязвимостей поверх semgrep. Но также генерирует около 40% ложноположительных - каждую находку нужно верифицировать. Без этого шага в отчёт полезут фантомные баги.

Где LLM-агенты безопасность ломают: честный разбор провалов​

Тут буду максимально прямым, потому что русскоязычный рынок завален восторженными обзорами, а реальных данных о провалах - почти нет.

Проблема потери контекста​

Исследование LLMs as Hackers показало фундаментальную проблему: при длинных цепочках эксплуатации LLM забывает информацию, обнаруженную на ранних этапах. Агент может найти уязвимость через cronjob, но не дождаться выполнения задания и «сдаться». GPT-4 скачал Python-скрипт для энумерации, но не смог выполнить его, потому что бинарник в VM назывался python3, а не python. Вместо того чтобы поправить одну букву - просто прекратил попытки. Это как если бы пентестер развернулся и ушёл, потому что дверь открывается не на себя, а от себя.

Галлюцинации команд​

Моя ежедневная боль. LLM уверенно генерирует команды с несуществующими флагами, несуществующими Docker-образами, некорректными URL. Особенно критично с Metasploit - агент может предложить модуль, которого нет в текущей версии, или указать неправильные параметры.

# Типичная галлюцинация LLM для Metasploit:
msf6 > use exploit/linux/http/apache_rce_2024  # Модуль не существует
msf6 > set RHOSTS target.example.com
msf6 > set PAYLOAD linux/x64/meterpreter/reverse_tcp  # Может не подходить

# Реальность: нужно использовать msfconsole для поиска актуальных модулей
msf6 > search type:exploit platform:linux apache
# И далее проверять каждый модуль через 'info'

На одном проекте агент предложил мне модуль exploit/multi/http/log4shell_header_injection с параметрами, которые были корректны для версии 6.2, а у меня стояла 6.3 - параметр переименовали. Полчаса на отладку того, что не должно было попасть в пайплайн.

Depth-first bias​

По данным об архитектуре PentestGPT, LLM-агенты склонны «зацикливаться» на одном векторе атаки, углубляясь в него вместо проверки альтернатив. PentestGPT решает это через периодический обзор всего дерева задач и переранжирование листовых узлов. Без такого механизма агент может потратить 80% бюджета токенов на бесперспективный вектор. Знакомая ситуация? Только живой пентестер обычно через 20 минут переключается, а LLM будет долбить в закрытую дверь, пока не кончатся токены.

Экономика провалов​

По данным Fang et al., в лабораторном эксперименте с 15 one-day CVE стоимость API-вызовов GPT-4 для успешной эксплуатации была в 2,8 раза ниже расчётной стоимости работы специалиста. Эта оценка не учитывает стоимость неудачных попыток и не экстраполируется на произвольные сценарии. Когда агент «буксует» на сложной цели, расходы на API-вызовы могут превысить стоимость ручной работы - особенно с моделями уровня GPT-4, где каждый запрос с длинным контекстом стоит ощутимых денег.

Практический пайплайн: собираем AI-assisted pentest workflow​

Минимально жизнеспособный пайплайн, который я использую на реальных проектах:

Шаг 1: Автоматизированная разведка с LLM-приоритизацией​

# Сканирование целевой сети (grepable-вывод, совместимый с run_nmap_scan выше)
nmap -sV -sC --open --top-ports 1000 -oG scan.grep $TARGET

# Парсинг и отправка в LLM для приоритизации
# Используем функции run_nmap_scan() и build_recon_prompt() из примера выше,
# затем вызываем LLM API, например:
# from openai import OpenAI
# client = OpenAI()
# resp = client.chat.completions.create(model="gpt-4", messages=[{"role":"user","content": prompt}])
# priorities = json.loads(resp.choices[0].message.content)
# json.dump(priorities, open("priorities.json","w"))

Шаг 2: Параллельное сканирование уязвимостей​

# nuclei по приоритизированным целям
cat priorities.json | jq -r '.attack_vectors[].target_url' | \
    nuclei -l - -severity critical,high -json -o findings.json

# semgrep для исходного кода (если доступен)
semgrep --config "p/security-audit" --json -o semgrep.json /path/to/code

Шаг 3: LLM-анализ и генерация exploit-цепочек​

На этом этапе агент получает результаты nuclei и semgrep, сопоставляет их и предлагает цепочки атаки. Ключевой момент - агент должен иметь доступ к актуальной CVE-базе через RAG, а не полагаться на training data. Иначе он будет предлагать эксплойты для уязвимостей, закрытых полгода назад.

Шаг 4: Верификация и ручная проверка​

Каждый предложенный вектор проходит ручную проверку. Это не опционально - это обязательно. Автоматизация пентеста через LLM без человеческой верификации - путь к ложным выводам в отчёте. А ложный вывод в отчёте - это репутационный ущерб, который никакая экономия на API-вызовах не окупит.

Сравнение подходов: LLM-агент vs классический пентест​

Параметр	Ручной пентест	LLM-assisted	Полностью автономный LLM
Время на разведку	2-4 часа	30-60 минут	15-30 минут
Качество приоритизации	Высокое	Высокое	Среднее
Обнаружение логических багов	Да	Частично	Нет
Обход WAF/кастомных защит	Да	Да (с верификацией)	Редко
Генерация отчёта	4-8 часов	1-2 часа	30 минут (низкое качество)
Стоимость на одну цель	Высокая	Средняя	Низкая
Ложноположительные	Минимум	~15-25% (оценка автора)	~40-60% (оценка автора)
Покрытие CTF-задач	Зависит от навыка	64%* (полуавтономный режим)	21%* (полностью автономный)

Данные по CTF-покрытию - из анализа PentestGPT на задачах HackTheBox/VulnHub, согласно EmergentMind. AutoPenBench - отдельный бенчмарк с другой методологией.

Искусственный интеллект хакинг: маппинг на MITRE ATT&CK​

Для red team отчётов нужно понимать, как AI-assisted атаки ложатся на MITRE ATT&CK:

Этап пентеста	Техника MITRE ATT&CK	Роль LLM-агента
Разведка инфраструктуры	Ссылка скрыта от гостей )	Приоритизация целей, корреляция данных
Сбор ресурсов	Artificial Intelligence (T1588.007)	Собственно использование AI как инструмента
Сбор информации об уязвимостях	Vulnerabilities (T1588.006)	Поиск в CVE-базах, анализ версий
Разработка эксплойтов	Exploits (T1587.004)	Генерация и адаптация PoC-кода
Начальный доступ	Ссылка скрыта от гостей )	Автоматическая эксплуатация веб-уязвимостей
Выполнение кода	Python (T1059.006)	Скрипты взаимодействия с целью
Эксплуатация клиента	Exploitation for Client Execution (T1203)	Генерация клиентских эксплойтов
Обнаружение сервисов	Network Service Discovery (T1046)	Парсинг и анализ результатов nmap

Что это означает для работающих пентестеров​

По данным HackerOne Hacker-Powered Security Report, свыше 50% хакеров (данные за 2023 год) уже используют генеративный AI для автоматизации работы. Это не прогноз - это реальность. И вопрос не в том, заменит ли AI пентестера, а в том, какие пентестеры останутся на рынке.

Мой практический вывод после полутора лет использования LLM-агентов в боевых проектах:

Где AI реально экономит время:

• Разведка и приоритизация - сокращение на 60-70%
• Генерация вариаций payload - в 5-10 раз быстрее ручного подбора
• Написание PoC по описанию CVE - минуты вместо часов
• Анализ исходного кода - покрытие на 15-25% больше, чем только SAST
• Генерация отчётов - сокращение на 70-80%

Где AI создаёт проблемы:

• Привилегированная эскалация - теряет контекст в длинных цепочках
• Нестандартные окружения - галлюцинирует команды и пути
• Бизнес-логика - не понимает контекст приложения без обучения
• Обход кастомных защит - предлагает шаблонные подходы

Искусственный интеллект хакинг - это настоящее, не будущее. Но выигрывают те, кто использует LLM как мультипликатор собственной экспертизы, а не как замену мышлению. Попробуйте прогнать свой пайплайн через схему из этой статьи - и посмотрите, на каком этапе агент начнёт галлюцинировать. Спойлер: раньше, чем вы думаете. Агент, который не понимает, что он не понимает - опаснее, чем отсутствие агента.