На последнем внешнем пентесте для финтех-компании скоуп содержал 12 доменов. После passive recon я насчитал 47 поддоменов, о которых заказчик не подозревал - среди них staging-API без аутентификации, забытый Jenkins с дефолтными кредами и три dev-окружения с включённым debug-режимом. Два из этих активов давали прямой initial access без единого эксплойта.
Проблема не в нехватке сканеров. Проблема в том, что заказчик не знал, что именно нужно сканировать. Управление поверхностью атаки (ASM) закрывает разрыв между "мы думаем, что у нас 12 доменов" и реальным цифровым следом организации.
Место recon в цепочке атаки: зачем пентестеру ASM-подход
[Применимо: внешний пентест, black box и grey box]Recon - первая фаза kill chain. Большинство пентестеров проходят её на автомате: запустили
nmap по выданному скоупу и побежали к эксплуатации. ASM-подход меняет логику - вместо сканирования того, что дал заказчик, вы самостоятельно строите карту внешних активов и только потом решаете, куда бить.В терминах MITRE ATT&CK это фаза Reconnaissance:
- Gather Victim Network Information (T1590) - сбор данных о доменах (T1590.001 Domain Properties), IP-адресах (T1590.005 IP Addresses) и сетевой инфраструктуре цели
- Search Open Technical Databases (T1596) - работа с Shodan, Censys, Certificate Transparency логами
- Search Open Websites/Domains (T1593) - анализ публичных источников, GitHub-репозиториев, DNS-записей
- Active Scanning (T1595) - сканирование IP-блоков (T1595.001) и поиск уязвимостей (T1595.002)
dev3.company.tld слушает мир с CVE двухлетней давности.По данным CyCognito, типичная организация не знает о существенной части своих внешних активов - shadow IT, забытая инфраструктура после миграций, dev-окружения, которые "временно" выставили наружу. Эти забытые точки входа чаще всего и эксплуатируются при реальных атаках. OWASP (A05:2021 - Security Misconfiguration) подтверждает: некорректные конфигурации и забытые дефолты - в числе самых распространённых рисков веб-приложений.
Требования к окружению
Перед тем как переходить к командам:- ОС: Linux (Kali 2024+, Parrot, Ubuntu 22.04+). На macOS работает, но
masscanи ряд зависимостей собираются проще под GNU/Linux - RAM: минимум 4 ГБ для passive recon. Для Amass в active-режиме с большим скоупом - 8 ГБ, он прожорлив
- Go: версия 1.21+ - Subfinder, httpx, nuclei, Amass написаны на Go
- Python: 3.10+ - BBOT, скрипты обогащения
- Сеть: интернет-доступ обязателен. Passive recon работает через API провайдеров, active discovery - напрямую к целям
- API-ключи (рекомендуется): Shodan, Censys, VirusTotal, SecurityTrails, GitHub. Без них passive-инструменты выдают 20–30% от возможного результата. Бесплатных тарифов обычно хватает для единичного assessment
pdtm:
Bash:
go install github.com/projectdiscovery/pdtm/cmd/pdtm@latest
pdtm -install-all
# Ставит subfinder, httpx, nuclei, dnsx, naabu и другие
# Обновление: pdtm -update-allpipx install bbot (Python 3.10+, примерно 200 МБ на диске).Passive recon: обнаружение внешних активов без единого пакета к цели
Passive reconnaissance - сбор данных о цифровом следе организации без прямого взаимодействия с инфраструктурой. Никаких пакетов к целевым хостам, никаких алертов в IDS. Источники: DNS-записи, Certificate Transparency логи, WHOIS, поисковые движки, Shodan/Censys.
Subdomain enumeration
Ядро passive recon - обнаружение поддоменов. Это главный источник shadow IT и забытых активов. Два инструмента, которые я запускаю на каждом проекте:Subfinder (ProjectDiscovery, активно поддерживается, 10k+ звёзд на GitHub) агрегирует данные из 40+ источников - CT-логи, DNS-дампы, поисковые движки. Быстрый, но без API-ключей выдаёт огрызки. Запуск:
subfinder -d target.com -all -o subs.txt. Флаг -all включает все источники, включая медленные.Amass (OWASP, активно поддерживается) в passive-режиме собирает данные из ещё большего пула источников и строит граф связей между активами. Запуск:
amass enum -passive -d target.com -o amass_subs.txt. В passive-режиме безопасен для black box assessments - ни один пакет не уходит к цели.После сбора - объединение и дедупликация:
cat subs.txt amass_subs.txt | sort -u > all_subs.txt.На реальных проектах разница между "только Subfinder" и "Subfinder + Amass" - 15–30% дополнительных поддоменов. Amass находит связи через ASN и WHOIS, которые Subfinder пропускает. Ради этого стоит подождать лишние пять минут.
Certificate Transparency и Shodan
CT-логи - отдельный мощный источник. Каждый SSL/TLS-сертификат, выпущенный публичным CA, попадает в CT-лог. Черезcrt.sh находятся поддомены, которые не светятся в DNS:
Bash:
curl -s "https://crt.sh/?q=%.target.com&output=json" | jq -r '.[].name_value' | sort -uinternal-[I], staging-[/I], dev-* домены, на которые забыли повесить ограничения.Для обнаружения внешних активов по IP и сервисов без DNS-привязки:
shodan search "ssl.cert.subject.cn:target.com" покажет все хосты, где в сертификате фигурирует домен организации, включая IP, которые не резолвятся через DNS. Censys даёт аналогичные возможности: censys search "services.tls.certificates.leaf.names: target.com".На одном из проектов именно Shodan-запрос выявил три IP с устаревшим VPN-шлюзом, который заказчик вывел из эксплуатации два года назад. DNS-запись удалена, но сервис продолжал слушать порт 443 с просроченным сертификатом и известными уязвимостями. Заказчик удивился - "мы же его выключили". Ну, не совсем.
Active discovery: расширяем карту поверхности атаки
[Применимо: внешний пентест. Для внутреннего пентеста - другая методология]
После passive recon на руках список поддоменов и IP. Следующий шаг - определить, что из этого живое и что на нём крутится. Здесь начинается прямое взаимодействие с целью - IDS может зафиксировать активность.
Проверка живых хостов и fingerprinting
httpx (ProjectDiscovery, активно поддерживается) проверяет HTTP/HTTPS-ответы, собирает заголовки, статус-коды, технологии:
Bash:
cat all_subs.txt | httpx -sc -title -tech-detect -o live.txt
# -sc: статус-код, -title: заголовок страницы
# -tech-detect: fingerprinting (Wappalyzer-движок)
# Пример вывода:
# staging-api.target.com [200] [Swagger UI] [nginx,express]
# dev3.target.com [403] [Forbidden] [Apache/2.4.29]
# old-cms.target.com [200] [WordPress] [PHP,WordPress 4.9]Для полноты картины после HTTP-проверки стоит просканировать порты на обнаруженных IP.
naabu (ProjectDiscovery) быстрее nmap для массового сканирования: cat live_ips.txt | naabu -top-ports 1000 -o ports.txt. Для углублённого fingerprinting конкретного хоста - nmap -sV -sC -p- target_ip, но это медленно и шумно.BBOT - unified recon framework
Если не хочется собирать pipeline из отдельных утилит руками - BBOT (Black Lantern Security, активно поддерживается, 5k+ звёзд на GitHub) объединяет subdomain enumeration, port scanning, web crawling, vulnerability scanning и cloud enumeration в один workflow:
Bash:
bbot -t target.com -f subdomain-enum web-basic -o /output/Обогащение и приоритизация: от списка хостов к вектору initial access
Список из 200 живых поддоменов бесполезен без приоритизации. Задача - быстро определить, какие находки дают реальный вектор атаки.Автоматическая проверка уязвимостей
nuclei (ProjectDiscovery, активно поддерживается, 20k+ звёзд на GitHub) - сканер на базе YAML-шаблонов. Массовая проверка найденных хостов на известные уязвимости, мисконфигурации и дефолтные учётные данные:
Bash:
nuclei -l live.txt -t cves/ -t misconfigurations/ -t default-logins/ -severity critical,high -o findings.txtНа практике nuclei - первое, что запускаешь после httpx. Он находит exposed
.git/config, открытые панели администрирования, debug-эндпоинты, устаревшие компоненты. В одном из недавних проектов nuclei обнаружил exposed .env файл с учётными данными от production-базы на забытом staging-поддомене. Вот тебе и "у нас всё защищено".Ручная приоритизация находок
Автоматика не заменяет голову. После nuclei я прохожу по выводу httpx и ищу паттерны, характерные для забытых точек входа:- Swagger UI / API-документация без аутентификации - прямой путь к тестированию API (Broken Access Control, A01:2021 по OWASP)
- Панели администрирования (Jenkins, Grafana, phpMyAdmin) - проверка дефолтных кредов и CVE
- Dev/staging-окружения - часто зеркалят production с ослабленными controls
- Устаревшие CMS (WordPress 4.x, Joomla 3.x) - готовые эксплойты в публичном доступе
- Exposed storage - S3-бакеты, Azure Blob с публичным доступом
ASM-инструменты: trade-off таблица
| Инструмент | Тип | Плюсы | Ограничения | Когда использовать |
|---|---|---|---|---|
| Subfinder | Passive subdomain enum | Быстрый, 40+ источников, мало false positives | Только поддомены, нет port scan / vuln check | Каждый внешний пентест, первый шаг |
| Amass (passive) | Passive enum + граф | Глубокий ASN/WHOIS-анализ, граф связей | Медленнее Subfinder, жрёт RAM | Крупные скоупы, холдинги |
| httpx | HTTP probing | Быстрый, tech detection, pipeline-friendly | Только HTTP/HTTPS, не видит другие протоколы | После subdomain enumeration |
| nuclei | Vuln scanning | 8000+ шаблонов, community-driven | Шумный, триггерит WAF/IDS | Массовая проверка обнаруженных хостов |
| BBOT | Unified recon | Всё-в-одном, автоматический граф | Менее гибкий, сложнее debug | Автоматизация, регулярные сканирования |
| Shodan/Censys | Passive host discovery | Хосты без DNS, исторические данные | Данные могут быть устаревшими (часы-дни) | Поиск "потерянных" IP, IoT, legacy |
| Censys ASM | EASM-платформа (коммерч.) | Continuous monitoring, attribution, alerting | Стоимость, vendor lock-in | Continuous мониторинг |
Когда бесплатных ASM-инструментов недостаточно
Бесплатный стек (Subfinder + Amass + httpx + nuclei) покрывает 90% задач разового внешнего пентеста. Коммерческие EASM-решения (Censys ASM, Cortex Xpanse от Palo Alto, Microsoft Defender EASM) оправданы в других сценариях:- Continuous monitoring - отслеживание изменений не раз в полгода, а ежедневно. По данным Palo Alto Networks, инфраструктура организации меняется постоянно: разработчики разворачивают новые сервисы, облачные команды создают регионы, партнёры меняют инфраструктуру
- Attribution сложных инфраструктур - холдинги с десятками дочерних компаний, M&A-сценарии, где ручная корреляция ASN и WHOIS занимает дни
- Интеграция с SIEM/SOAR - автоматическое создание тикетов при обнаружении новых exposed-активов
- Third-party risk - оценка поверхности атаки подрядчиков и партнёров
Ограничения: когда ASM-подход не работает
Внутренние активы. Весь описанный workflow применим только к внешней поверхности атаки. Для internal ASM нужны другие подходы: BloodHound для AD, внутренние сканеры сети, CMDB-корреляция. Это отдельная тема с собственной методологией.
Пентестерам, которые привыкли ограничивать recon запуском
nmap по выданному списку IP, ASM-подход кажется избыточным. До первого проекта, где забытый staging-сервер оказывается единственным путём к domain admin.На моей практике в 7 из 10 внешних assessments самые критичные находки приходили не из скоупа заказчика, а из активов, обнаруженных на этапе разведки. Речь не о zero-day и сложных цепочках - банальные дефолтные креды на забытом Jenkins, открытый
.git на staging, незакрытый debug-эндпоинт.Большинство пентест-отчётов, которые я читал у коллег, страдают одной болезнью: выводы строятся на скоупе заказчика, а не на реальной поверхности атаки. Пока пентестер принимает скоуп как истину - он работает с чужой моделью угроз, а не со своей. Настоящий recon начинается с вопроса "что вообще торчит наружу?", а не "что мне дали проверить?". Ответ на этот вопрос почти всегда неприятный для заказчика - shadow IT обнаружение вскрывает то, о чём внутренние команды предпочитали не знать.
Попробуйте прогнать свой текущий проект через полный pipeline из этой статьи - Subfinder + Amass + httpx + nuclei. Сравните результат со скоупом от заказчика. Разница вас удивит.
Последнее редактирование модератором:
