Год назад я подключил мультиагентную систему на CrewAI к своему bash-пайплайну для поиска information disclosure в проиндексированных PDF-файлах - и получил 200+ «находок», из которых ровно три оказались валидными. Остальные содержали слово «password» в заголовках документации. Знакомо? Bronxi из Bugcrowd описывает ту же картину: его AI-агенты генерировали ложные срабатывания десятками, пока он не перестроил архитектуру - оставил bash для сбора данных, а LLM отдал только классификацию и генерацию отчётов. Этот опыт запустил мою цепочку экспериментов с Claude-OSINT: от слепого прогона LLM на сырых данных до рабочего пайплайна, где Claude через function calling корреляет результаты amass, subfinder и Shodan, а я трачу время только на валидацию финального output.
Бизнес-логика reconnaissance-цепочки
Reconnaissance в терминах MITRE ATT&CK покрывает целый пласт тактик: от поиска по открытым веб-ресурсам - Search Open Websites/Domains (T1593, Reconnaissance) и Search Engines (T1593.002, Reconnaissance) - до анализа технических баз данных - Search Open Technical Databases (T1596, Reconnaissance), WHOIS (T1596.002, Reconnaissance) - и сбора идентификационных данных жертвы - Gather Victim Identity Information (T1589, Reconnaissance). Подробнее - в нашем обзоре безопасность llm атаки.Финальная цель recon - не список поддоменов и не отчёт nuclei. Это attack-path map: граф связей «домен → IP → сертификат → организация → другой домен → открытый порт → утечка ключа → вектор входа». Чем полнее граф, тем быстрее переход к exploitation. В bug bounty скорость recon напрямую конвертируется в деньги: кто первый раскопал забытый staging-эндпоинт с дефолтными кредами - тот и получил bounty.
Проблема классического подхода - не отсутствие инструментов, а объём ручной корреляции. Subfinder выдаёт 500 поддоменов, httpx пробует каждый, nuclei сканирует всё - и ты сидишь перед 80-страничным отчётом, вручную решая, что из этого реально эксплуатируемо. На пятом часу глаза замыливаются. Автоматизация recon для red team с помощью ИИ решает именно эту задачу - не сбор данных (тулы справляются), а их корреляцию и приоритизацию.
Claude-OSINT автоматизация разведки: архитектура пайплайна
Предусловия и требования к окружению
- OS: Linux (Kali/Parrot/Ubuntu 22.04+), macOS. Windows - через WSL2
- RAM: минимум 8 GB (для локальных тулов). VRAM не нужен - inference на стороне Anthropic API
- API: Anthropic API key (Claude Sonnet или Opus). Бюджет: $5–15 на один полный recon scope из 500+ поддоменов
- Зависимости: Python 3.10+,
subfinder,httpx,nuclei,amassв PATH - Сеть: доступ к API Anthropic, Shodan API key, crt.sh, SecurityTrails (опционально)
AI skills для кибербезопасности: структура скиллов
Главная ошибка при внедрении ИИ для пентеста и разведки - скармливать LLM сырой сетевой трафик или просить «найди уязвимости». Я это проходил. Рабочая архитектура другая:- Традиционные тулы собирают данные (subfinder, amass, httpx, Shodan API)
- Claude через tool use получает результаты в JSON
- LLM выполняет корреляцию, классификацию и приоритизацию
- Человек валидирует финальный output
Python:
tools = [
{"name": "subdomain_enum",
"description": "Run subfinder for target domain",
"input_schema": {"type": "object",
"properties": {"domain": {"type": "string"}},
"required": ["domain"]}},
{"name": "cert_search",
"description": "Query crt.sh for CT logs",
"input_schema": {"type": "object",
"properties": {"domain": {"type": "string"}},
"required": ["domain"]}}
]whois_lookup (T1596.002, WHOIS), shodan_search (T1596, Search Open Technical Databases), google_dork (T1593.002, Search Engines) и favicon_hash. Критически важно: каждый скилл возвращает JSON, а не текстовый blob - иначе LLM начинает галлюцинировать при парсинге. Проверено на собственных нервах.Промпт-инженерия для AI recon инструментов
Системный промпт для Claude при OSINT-задаче - не «найди уязвимости», а явный порядок вызовов с требованием структурированного выхода:
Код:
You are an OSINT analyst. Build an infrastructure map for {target}.
1. subdomain_enum → collect subdomains
2. cert_search → find related domains via CT logs
3. For each unique IP: shodan_search → identify services
4. whois_lookup → identify registrant patterns
5. Correlate: group by registrant, IP range, cert issuer
Output: JSON {related_domains[], ip_map{}, priority_targets[]}Практический пайплайн: от Google dorks для OSINT до атрибуции целей
Dorking с AI-корреляцией
[Применимо: внешний пентест, bug bounty]Работает если: scope определён, домены известны. Не работает если: target за CDN с wildcard-сертификатами (Cloudflare Enterprise), скрывающим реальную инфраструктуру.
Стандартный подход: серия дорков (
site:target.com filetype:pdf "confidential", site:target.com inurl:admin, site:target.com intitle:"index of") через API или googler, скачивание результатов, ручная проверка каждого файла.AI-augmented подход: Claude получает текст файла и промпт с определением sensitive data - API-ключи конкретных паттернов (AWS
AKIA..., GitHub ghp_...), внутренние IP-адреса, credentials в формате user
ass. Это убирает 85–90% false positives из серии «слово password в заголовке раздела документации». Те самые 200 находок, с которых начиналась статья, сжимаются до 10–15 кандидатов.Когда техника НЕ работает: Google rate-limiting при массовом dorking (>100 запросов за сессию). Решение - распределение по времени, SerpAPI или Zenserp как backend. Также бесполезно для целей без проиндексированного контента.
Subdomain enumeration и AI-обогащение
[Применимо: внешний пентест, bug bounty]Работает если: у цели несколько доменов и поддоменов. Не работает если: target - single-page application на одном домене без видимой инфраструктуры.
Цепочка
subfinder -d target.com -all → httpx -status-code -title -tech-detect -json - стандарт. Red team automation инструменты на основе AI добавляют слой семантического анализа: по title и response headers Claude классифицирует каждый поддомен (staging/prod/dev/internal tool), определяет стек без ручного анализа, приоритизирует по потенциальной attack surface.Пример:
staging-api.target.com с title «Django Debug» и статусом 200 получает приоритет HIGH, а www.target.com за CloudFlare WAF - LOW. Вручную эту классификацию для 500 поддоменов делать - полдня коту под хвост.Атрибуция целей через OSINT: сертификаты и WHOIS
[Применимо: внешний пентест, bug bounty, OSINT-расследования]Работает если: цель использует собственные сертификаты (не wildcard от CDN-провайдера). Не работает если: все домены за Cloudflare/AWS ALB с их сертификатами - CT-логи покажут только CDN.
Запрос к crt.sh (
curl -s "https://crt.sh/?q=%25.target.com&output=json") возвращает все сертификаты для домена и поддоменов. Claude анализирует issuer_name, common_name, name_value и ищет паттерны:- Сертификаты с SAN (Subject Alternative Name), покрывающие несколько доменов → связанные активы, которые могут быть вне заявленного scope
- Одинаковый registrant в WHOIS для разных доменов → расширение attack surface
- Favicon hash (
mmh3от favicon.ico) → поиск через Shodanhttp.favicon.hash:XXXXXXобнаруживает серверы без DNS-записей
Secret scanning в bug bounty с AI-валидацией
[Применимо: внешний пентест, bug bounty]Работает если: у цели есть публичные репозитории или проиндексированные файлы. Не работает если: нет public-facing кода и документации.
Традиционные инструменты (
trufflehog, gitleaks) находят паттерны строк, похожих на секреты. Процент false positives - 70–80%: base64-строки из README, примеры API-ключей из документации, отозванные токены.Claude получает список находок с контекстом (5 строк до и после каждого match) и классифицирует:
- Валидный секрет - паттерн соответствует формату (AWS
AKIA, Slack webhookhttps://hooks.slack.com/), контекст указывает на production - Пример из документации - строка внутри code block с комментарием «example» или «placeholder»
- Отозванный - рядом комментарий о ротации или
DEPRECATED
Attack-path mapping
Финальный этап - Claude получает все собранные данные и строит карту атаки:
Код:
Priority targets:
1. staging.target.com (Django 4.2, no auth) → HIGH
Found: AWS_ACCESS_KEY in /static/config.js.bak
Path: leaked key → S3 enumeration → internal data
2. api-v1.target.com (Express, outdated) → MEDIUM
Nuclei match: known CVE in framework version
Path: exploit → internal network pivotexploit.Ограничения автоматизации: когда AI recon инструменты бесполезны
Галлюцинации в OSINT-контексте
Главный риск - ложная атрибуция. Claude может «увидеть» связь между доменами, которой нет: совпадение фрагмента WHOIS, похожий naming pattern, общий /24 IP-диапазон у разных организаций. На одном проекте Claude уверенно заявил, что два домена принадлежат одной организации на основании совпадения города в WHOIS. Город - Москва. Ну спасибо, Шерлок.Практическое правило: если LLM утверждает связь между активами - верификация через минимум два независимых источника (WHOIS + cert + IP ownership).
По данным исследования Bugcrowd, полностью автономные AI-решения для пентеста по-прежнему требуют человеческого вмешательства. Поведение агентов зависит от промпта и контекста, предоставленного пользователем.
Стоимость vs скорость
Полный recon для scope из 500+ поддоменов через Claude API: $8–15 (Sonnet) или $25–40 (Opus). Для bug bounty с выплатами от $500+ - оправдано. Для программ с максимальной выплатой $100 - bash-скрипты экономичнее.Bronxi подчёркивает: выбор модели критически важен. Классификация поддоменов - Haiku/Sonnet. Корреляция сложных связей - Opus. Генерация отчёта - снова Sonnet. Такой подход сокращает расходы на 60–70%. Я пришёл к той же схеме: гонять Opus на каждом поддомене - всё равно что стрелять из пушки по воробьям.
Когда AI НЕ нужен
| Задача | Почему AI бесполезен |
|---|---|
| Nmap/masscan | Порты открыты или закрыты - интерпретация не нужна |
| Nuclei с готовыми шаблонами | Уже даёт структурированный JSON-output |
| Scope < 10 поддоменов | Быстрее проверить вручную за 15 минут |
| Внутренний пентест без интернета | OSINT неприменим по определению |
| Active Scanning (T1595) | Традиционные сканеры точнее и быстрее |
Минилаб для отработки
Ожидаемый результат: AI-классификация экономит 60–80% времени на этапе фильтрации, но пропускает 5–10% edge cases. Это нормально - пайплайн гибридный by design.
Я думаю о LLM в кибербезопасности как о junior-аналитике, которому делегируешь рутину. Хороший junior экономит часы на грепании CSV, но его выводы никогда не отправляются клиенту без проверки. С Claude - та же модель. Только junior не просит повышения и не уходит в отпуск.
За последний год я провёл около двадцати внешних пентестов с AI-augmented recon. Паттерн стабильный: ускорение на этапе корреляции в 3–5 раз, но каждый третий вывод LLM о связи активов - натяжка. Самое ценное - не скорость, а то, что AI замечает паттерны, которые человек пропускает от усталости. На пятом часу recon ты перестаёшь вчитываться в WHOIS-записи. LLM не устаёт. Но LLM не понимает бизнес-логики цели, не чувствует, какой staging-сервер «пахнет» забытым, не видит социальную инженерию в naming conventions поддоменов. Через год-два AI-augmented recon станет baseline-навыком, как сейчас bash-скриптинг. Те, кто строят пайплайны сегодня, формируют конкурентное преимущество. Те, кто ждут готовый продукт - будут прогонять чужие промпты без понимания ограничений и терять доверие клиентов на ложных атрибуциях. Если хочется отработать reconnaissance-цепочку на живом стенде - на HackerLab есть лабы по OSINT и web-recon, где можно прогнать весь пайплайн без риска выйти за scope.
