На одном из black box engagement'ов единственным входным параметром был корпоративный домен и 48 часов до начала активной фазы. Amass в passive-режиме за час вернул больше тысячи поддоменов - живых из них оказалось меньше трети. Recon-ng через модуль VirusTotal добил несколько десятков записей, которых Amass не видел. А SpiderFoot, запущенный на ночь в headless-режиме, утром выдал связанные домены и корпоративные email из breach-баз. Три инструмента, три разных результата, и ни один не дал полной картины в одиночку.
Ниже - когда каждый из них реально полезен, а когда только шумит.
Критерии отбора: почему SpiderFoot, Recon-ng и Amass
Русскоязычные обзоры OSINT-инструментов обычно перечисляют десяток названий подряд - Maltego, Shodan, theHarvester, FOCA - без объяснения, зачем пентестеру именно этот набор. Здесь сравниваются три инструмента, которые решают одну задачу разными путями: картирование внешней поверхности атаки на этапе пассивной разведки.Почему именно эти три:
- Amass - де-факто стандарт для subdomain enumeration на внешнем пентесте. Проект OWASP (github.com/owasp-amass/amass), активный репозиторий и сообщество.
- Recon-ng - модульный фреймворк для обогащения данных через API внешних сервисов. Проект Tim Tomes (github.com/lanmaster53/recon-ng), стабильно поддерживается.
- SpiderFoot - open-source ядро (github.com/smicallef/spiderfoot) плюс коммерческая версия SpiderFoot HX.
Пассивная разведка в цепочке атаки: от DNS к initial access
[Применимо: внешний пентест, black box]
Все три инструмента работают на этапе Reconnaissance по MITRE ATT&CK. Конкретнее - покрывают набор техник, которые атакующий выполняет до первого касания инфраструктуры цели:
- Сбор DNS-записей и пассивных DNS-данных - DNS/Passive DNS (T1596.001, Reconnaissance)
- Определение свойств домена через WHOIS и CT-логи - Domain Properties (T1590.001, Reconnaissance)
- Перечисление IP-адресов за доменами - IP Addresses (T1590.005, Reconnaissance)
- Сбор email-адресов сотрудников - Email Addresses (T1589.002, Reconnaissance)
- Поиск имён сотрудников - Employee Names (T1589.003, Reconnaissance)
- Определение бизнес-связей организации - Business Relationships (T1591.002, Reconnaissance)
- Парсинг поисковых систем - Search Engines (T1593.002, Reconnaissance)
Принципиальный момент: пассивная разведка не оставляет следов в логах цели. Ни одного пакета на серверы заказчика. Все данные берутся из публичных источников - CT-логов, passive DNS, поисковых индексов, breach-баз.
Amass: subdomain enumeration и построение DNS-графа
Архитектура и сильные стороны
Amass - не просто перебор поддоменов. Ключевое отличие от конкурентов - построение графа DNS-зависимостей. Инструмент находит поддомены и визуализирует связи между ними: какие NS-серверы обслуживают какие зоны, какие CNAME-цепочки существуют, какие IP-адреса пересекаются между разными доменами.В passive-режиме Amass обращается к десяткам источников: Certificate Transparency логи, passive DNS-провайдеры, поисковые системы, API VirusTotal, Censys, SecurityTrails и другие. По сути, он не полагается на одну базу, а комбинирует множество техник для картирования всей поверхности атаки организации.
Типичный запуск для внешнего пентеста:
Bash:
amass enum -passive -d target.com -o amass_results.txt-passive критически важен. Без него Amass начнёт DNS brute-force - а это уже активная разведка, которая оставляет следы в логах DNS-серверов цели.Amass хорош, когда цель - крупная организация с десятками поддоменов, несколькими DNS-зонами и сложной инфраструктурой. На таких целях граф зависимостей раскрывает связи, которые невозможно увидеть простым перечислением.
Ограничения и когда Amass не работает
Главная проблема Amass - шум. На крупных доменах passive-режим возвращает сотни записей, часть которых давно не резолвятся (мёртвые поддомены из passive DNS), принадлежат другим организациям (false positives из shared hosting) или относятся к CDN и третьим сервисам. После запуска Amass всегда нужна фильтрация - проверка каждого поддомена на живость и принадлежность к scope. Без этого шага реально полезных записей в списке меньше трети.Второе - зависимость от API-ключей. Бесплатные лимиты источников данных (SecurityTrails, Censys, VirusTotal) исчерпываются быстро. Без платных ключей качество пассивного перечисления деградирует ощутимо.
Третье - Amass фокусируется на DNS и инфраструктуре. Email-адреса, breach-данные, метаданные документов, профили сотрудников - за пределами его задач. Для этого нужны другие инструменты.
Когда использовать: глубокий DNS-маппинг крупной цели на внешнем пентесте. Много доменов, сложная инфраструктура, нужен граф зависимостей.
Когда НЕ использовать: быстрый скоупинг за 30 минут; малая цель с одним доменом и пятью поддоменами; нужна информация за пределами DNS - email, breaches, метаданные.
Recon-ng: модульная разведка через API-интеграции
Архитектура и рабочие пространства
Recon-ng построен по модели Metasploit: CLI-интерфейс, модули для конкретных задач, рабочие пространства для хранения данных между сессиями. Модульный подход даёт гибкость, которую пре-пакетированные альтернативы не тянут.Ключевая идея Recon-ng - фреймворк для обогащения (enrichment), а не для слепого перечисления. На вход подаются известные домены, имена, email-адреса, которые пропускаются через цепочку модулей. Каждый модуль добавляет новые данные из конкретного источника.
Модули делятся на категории:
recon/domains-hosts/[I] (поиск хостов по домену через Google, Bing, VirusTotal), recon/hosts-hosts/[/I] (обогащение найденных хостов), recon/contacts-[I]/[/I] (поиск контактов и email), reporting/* (экспорт результатов).Типичный рабочий сценарий: создание workspace командой
workspaces create client_pentest, загрузка домена через db insert domains (в интерактивном режиме фреймворк запросит ввод полей через разделитель ~, например: target.com~), последовательный запуск модулей - modules load recon/domains-hosts/google_site_web, затем run. Результаты сохраняются в базе данных workspace и доступны для следующих модулей в цепочке.Автоматизация через скрипт выглядит компактно:
Код:
recon-ng -m recon/domains-hosts/google_site_web -x 'run'Ограничения и подводные камни
Первое - rate limiting. Каждый модуль обращается к внешнему API. Без аккуратной настройки задержек между запросами API-ключи сгорают за день. Google и Bing банят за агрессивный парсинг, VirusTotal ограничивает бесплатные запросы до 4 в минуту. Полный обход всех модулей для одного домена может занять часы.Второе - кривая обучения. CLI-интерфейс знаком пользователям Metasploit, но нужно понимать, какие модули запускать и в каком порядке. Из коробки фреймворк ничего не делает - workflow собирается руками.
Третье - молчаливые отказы. Если API VirusTotal или Shodan не отвечает или поменял формат - модуль возвращает пустой результат без ошибки. Вы не узнаете о пропущенных данных, пока не проверите вручную. Неприятный сюрприз, когда на это завязана вся разведка.
Когда использовать: точечное обогащение данных из конкретных API. У вас уже есть список доменов или email от Amass, и нужно прогнать его через VirusTotal, Shodan, WHOIS. Хорош для повторяемых workflow - скрипт фиксируется и прогоняется для каждого проекта.
Когда НЕ использовать: нужна полная автоматика по модели «нажал кнопку - получил отчёт»; нет опыта с CLI-фреймворками; маленький scope, где ручной поиск быстрее настройки модулей.
SpiderFoot: OSINT-автоматизация и скоупинг поверхности атаки
Архитектура и режимы работы
SpiderFoot занимает нишу между ручной работой и enterprise-платформами EASM. Его козырь - автоматизация: задаёте цель (домен, IP, email, имя) и инструмент сам прогоняет сканирование через 200+ встроенных модулей сбора, корреляции и обогащения данных (источник: README проекта). То, на что руками ушли бы часы, SpiderFoot делает в фоне.SpiderFoot имеет web-интерфейс на порту 5001, REST API для автоматизации и CLI-режим. Пример запуска скана через API:
Python:
import requests
url = "http://localhost:5001/api/scan/new"
data = {"target": "target.com", "modules": "sfp_dns,sfp_email"}
headers = {"X-API-KEY": "<API_KEY>"}
r = requests.post(url, json=data, headers=headers)
# формат запроса может отличаться в актуальной версии,
# проверьте docs перед использованиемОграничения и шум в результатах
Первое - объём и триаж. 200+ модулей означают 200+ потоков данных. На выходе могут быть тысячи findings, часть которых - информационный шум. Без опыта работы с инструментом легко утонуть в результатах. Я на первых порах тратил больше времени на разгребание выдачи SpiderFoot, чем на саму разведку.Второе - глубина vs ширина. SpiderFoot берёт широтой покрытия, но уступает специализированным инструментам по глубине. Его DNS-модуль не даст того же качества subdomain enumeration, что Amass. Его email-модуль не заменит theHarvester с тонкой настройкой.
Третье - нестрогая пассивность. Часть модулей выполняет активные запросы (DNS-резолвинг, HTTP-обращения к целевым хостам). Нужно внимательно выбирать набор модулей, если требуется остаться строго в passive-режиме. Это не баг - это особенность архитектуры, но держать в голове обязательно.
Когда использовать: быстрый первичный скоупинг. Нужно за ночь получить общую картину: домены, email, breach-данные, связанные организации. Хорош в headless-режиме на сервере.
Когда НЕ использовать: нужен глубокий DNS-маппинг (Amass лучше); нужна точность каждого результата; строгие требования к пассивности.
Сравнительная таблица: EASM-инструменты в деталях
| Критерий | Amass | Recon-ng | SpiderFoot |
|---|---|---|---|
| Архитектура | Граф DNS-зависимостей | Модульный фреймворк (Metasploit-стиль) | Автоматический OSINT-сканер |
| Интерфейс | CLI | CLI с workspaces | Web UI + CLI + REST API |
| Источники данных | CT-логи, passive DNS, WHOIS, API | Модули под каждый API отдельно | 200+ встроенных модулей |
| Основная задача | Subdomain enumeration, DNS graph | Обогащение через внешние API | Полный OSINT-скоупинг |
| Автоматизация | Высокая (один запуск) | Средняя (сборка workflow вручную) | Очень высокая (из коробки) |
| Шум в результатах | Высокий (passive DNS артефакты) | Низкий (зависит от выбора модулей) | Высокий (объём данных) |
| Кривая обучения | Средняя | Высокая | Низкая |
| Покрытие за пределами DNS | Минимальное | Среднее (зависит от модулей) | Широкое (email, breaches, metadata) |
| Строгий passive-режим | Да (с флагом -passive) | Да (при правильном выборе модулей) | Частично (зависит от набора модулей) |
| Rate limiting проблемы | Средние | Критичные (ключи сгорают быстро) | Средние |
| Лицензия | Apache 2.0 (OWASP) | GPLv3 | MIT (open-source) + HX (коммерческая) |
Когда что запускать: decision tree для выбора инструмента
Выбор инструмента зависит от задачи, а не от привычки. Алгоритм для типичного внешнего пентеста:Шаг 1. Быстрый первичный скоуп нужен за несколько часов? SpiderFoot в headless-режиме. Запустить перед сном, утром разбирать. Даст общую картину: домены, email, breach-данные, связанные организации.
Шаг 2. Нужен глубокий DNS-маппинг цели с десятками поддоменов? Amass в passive-режиме. Он найдёт поддомены, которые SpiderFoot пропустит, за счёт cross-referencing нескольких passive DNS провайдеров и CT-логов.
Шаг 3. Есть список доменов или email, нужно обогатить данными из конкретных API? Recon-ng. Загрузить результаты Amass в workspace и прогнать через модули VirusTotal, Shodan, WHOIS.
Шаг 4. Малая цель - стартап, один домен, до десяти поддоменов? Тяжёлые фреймворки избыточны. Хватает crt.sh, пары DNS-запросов через
dig и ручного WHOIS.Шаг 5. Повторяемый workflow для регулярных проектов? Recon-ng со скриптом (фиксируется и прогоняется для каждого клиента) или SpiderFoot через REST API с интеграцией в автоматизированный пайплайн.
Практический workflow: passive DNS разведка тремя инструментами
Требования к окружению
- ОС: Linux (Kali, Ubuntu 22.04+) или macOS
- RAM: минимум 4 ГБ, рекомендуется 8 ГБ (SpiderFoot при полном скане потребляет ощутимо)
- Python: 3.9+ (для Recon-ng и SpiderFoot)
- Go: 1.20+ (для сборки Amass из исходников; в Kali доступен через
apt) - Сеть: online, доступ к API-сервисам (VirusTotal, SecurityTrails)
- API-ключи: VirusTotal (бесплатный тир), SecurityTrails (бесплатный тир), Shodan (опционально)
- Установка: Amass -
go install github.com/owasp-amass/amass/v4/...@masterили через apt; Recon-ng -git clone https://github.com/lanmaster53/recon-ng && cd recon-ng && pip install -r REQUIREMENTSилиapt install recon-ng(Kali); SpiderFoot -git clone https://github.com/smicallef/spiderfoot && cd spiderfoot && pip3 install -r requirements.txtили Docker
Порядок работы
- SpiderFoot - первичный скоупинг. Запускаете сканирование целевого домена через web-интерфейс или API. Выбираете модули:
sfp_dns,sfp_email,sfp_whois,sfp_crt(Certificate Transparency). Через 2-4 часа получаете общую картину: поддомены, email-адреса, WHOIS-данные, breach-упоминания. Экспортируете список доменов. - Amass - глубокий DNS-маппинг. Берёте целевой домен и запускаете
amass enum -passive -d target.com. Amass обращается к passive DNS провайдерам и CT-логам, возвращая поддомены, которые SpiderFoot мог пропустить. Результаты объединяете с выводом SpiderFoot, удаляя дубли. - Recon-ng - обогащение. Создаёте workspace, импортируете объединённый список доменов. Прогоняете через модули:
recon/domains-hosts/google_site_webдля проверки индексации в Google,recon/hosts-ports/shodan_ipдля поиска открытых портов через API Shodan (без прямого сканирования цели). - Фильтрация и валидация. Итоговый список проходит через проверку на живость -
httpxилиmassdnsдля быстрого резолвинга. Это уже активная фаза, выполняется после согласования scope с заказчиком. Мёртвые поддомены, CDN-записи и shared-хостинг отсеиваются.
Ограничения пассивной разведки и когда инструменты бесполезны
Пассивная разведка - штука мощная, но у неё есть жёсткие границы, которые стоит знать до старта, а не после.Internal assets невидимы. Пассивные источники показывают только то, что попало в публичные базы. Внутренние поддомены, которые никогда не резолвились извне и не имеют CT-сертификатов, останутся невидимыми. Для внутреннего пентеста пассивная DNS-разведка даёт минимум - тут нужна активная DNS-энумерация.
Данные устаревают. Passive DNS хранит исторические записи. Поддомен, который резолвился год назад, может быть давно удалён. Без активной проверки невозможно отличить живой хост от исторического артефакта.
API-зависимость. Все три инструмента зависят от внешних API. Бесплатные тиры ограничены, платные стоят денег. Без ключей SecurityTrails, VirusTotal, Shodan качество результатов падает на порядок.
Ложное чувство полноты. SpiderFoot, показавший 2000 findings, создаёт иллюзию, что «всё найдено». На практике пассивная разведка покрывает только часть реальной поверхности атаки - остальное раскрывается активным сканированием.
Детекция через threat intel. Пассивная разведка не касается инфраструктуры цели напрямую, но обращения к API VirusTotal, Shodan и аналогичным сервисам могут быть замечены, если цель мониторит запросы к этим платформам через threat intelligence feeds. Редкий случай, но на зрелых SOC'ах бывает.
Выбор между Amass, Recon-ng и SpiderFoot - ложная дилемма, к которой сводятся большинство обсуждений в профильных чатах. Инструмент не решает задачу разведки. Решает методология: в каком порядке запускать, как фильтровать, как интерпретировать вывод.
Я видел десятки отчётов, где пентестер прогнал Amass, скопировал результат и пошёл дальше - без фильтрации, без обогащения, без cross-reference. Итог: 500 строк мусора и пропущенный staging-сервер с дефолтными кредами, который был единственной реальной точкой входа.
Обратная крайность - три дня на настройку идеального пайплайна из пяти инструментов, когда scope состоит из одного домена с пятью поддоменами. Для таких целей хватает crt.sh, пары DNS-запросов и здравого смысла.
Рабочий подход, к которому я пришёл за последние пару лет: SpiderFoot на автомате для первичной картины, Amass для DNS-глубины, Recon-ng для точечного обогащения. Три инструмента, фиксированный порядок, фильтрация после каждого этапа. Результат зависит не от конкретной тулзы, а от того, что вы делаете с её выводом. Если хочется прогнать эту связку на реальном скоупе без юридических рисков - на HackerLab в категории OSINT есть задачи, где разведка идёт от домена до флага.
Последнее редактирование:
