На pre-engagement фазе пентеста промышленной компании я загрузил корневой домен в crt.sh и получил 47 субдоменов. ИТ-отдел знал о 28. Среди оставшихся 19 - staging-стенд корпоративного ERP, Jenkins без авторизации и три dev-окружения с истекшими сертификатами. Ни одного из этих активов не было в CMDB. Ситуация до боли типичная: организации не контролируют от 30 до 40% своих внешних активов. Для blue team вывод простой - пока нет полной карты периметра, защищать нечего.
Место в цепочке атаки: зачем blue team разведка собственного периметра
Все техники ниже относятся к фазе Reconnaissance по MITRE ATT&CK. Атакующий начинает именно отсюда: Passive DNS (T1596.001), Digital Certificates (T1596.003), WHOIS (T1596.002), DNS enumeration (T1590.002). Эти методы не генерируют трафика к целевой инфраструктуре и не оставляют следов в SIEM - blue team не задетектит их постфактум.Единственный рабочий ответ - применять те же техники к собственной организации регулярно, до того как это сделает атакующий. Результат - актуальная карта внешней атакуемой поверхности, которая показывает:
- какие активы торчат наружу, включая те, о которых IT не знает
- какие DNS-записи указывают на несуществующие ресурсы (dangling DNS - прямой вектор subdomain takeover)
- какие сертификаты выданы для доменов организации, включая wildcard и staging-среды
- где shadow IT обходит корпоративные процессы управления изменениями
NIST CSF 2.0, функция ID.AM-01 (Asset Management), прямо требует: "Constantly monitor networks to detect new hardware and automatically update inventories""Постоянное отслеживание сети для обнаружения нового оборудования и автоматического обновления инвентаризации". Картирование внешней поверхности - базовая гигиена, без которой невозможно управление киберрисками. Не "бонусная" активность перед пентестом, а фундамент.
Passive DNS разведка: как исторические записи раскрывают забытую инфраструктуру
[Применимо: внешний пентест, pre-engagement OSINT, blue team asset discovery]
Passive DNS - база данных, собранная из реальных DNS-ответов, которые наблюдались рекурсивными резолверами. Активный DNS-запрос показывает текущее состояние. Passive DNS хранит историю: какой домен на какой IP резолвился, когда зафиксирован впервые и когда в последний раз.
Для картирования внешней атакуемой поверхности организации это означает вот что: если корпоративный субдомен
dev.example.com полгода назад указывал на IP в AWS, а сейчас DNS-запись удалена - в passive DNS эта связь сохранилась. Вы видите и субдомен, и облачный ресурс, который, возможно, всё ещё работает и доступен по прямому IP. Мёртвые записи в DNS - живые серверы в облаке.Источники и инструменты Passive DNS
Основные публичные и полупубличные источники:- SecurityTrails - коммерческий API, бесплатного тира нет (доступен free trial для оценки). Покрывает исторические A, AAAA, MX, NS, CNAME, SOA и TXT записи. Для регулярного использования нужна платная подписка - но покрытие того стоит.
- CIRCL Passive DNS - бесплатный сервис от Computer Incident Response Center Luxembourg. API-запросы в формате JSON. Покрытие неравномерное: европейские домены представлены хорошо, российская инфраструктура - значительно хуже.
- VirusTotal - passive DNS как побочный продукт массового сканирования. Для быстрой проверки сойдёт, но полнота зависит от того, сканировал ли кто-то домен ранее.
dnsx (ProjectDiscovery, активно поддерживается) для массового резолвинга, subfinder (ProjectDiscovery) для агрегации passive DNS из десятков источников в один поток, amass (OWASP-проект) для построения графа связей между доменами, IP и ASN.Что passive DNS покажет - и что не покажет
Покажет:- Исторические A/CNAME записи субдоменов, которые уже удалены из текущего DNS
- IP-адреса облачных провайдеров, на которых размещались или размещаются активы (T1590.005)
- Связи между доменами через общие IP - два домена, которые казались независимыми, резолвились на один сервер
- Субдомены, которые никогда не резолвились публично (внутренние split-horizon DNS)
- Домены за CDN/WAF, если исторических записей до включения проксирования не было
- Активы без DNS-имени (только IP) - для них нужен отдельный подход через сканирование IP-блоков (T1595.001)
Certificate Transparency: crt.sh и поиск субдоменов через логи сертификатов
[Применимо: внешний пентест, bug bounty, blue team continuous monitoring]
Certificate Transparency (CT) - механизм по RFC 6962 (CT v1, используется в production). Browser-политики Chrome и Apple требуют, чтобы каждый публично доверенный сертификат содержал SCT минимум из двух независимых CT-логов - без этого браузеры не доверяют сертификату. Каждый сертификат содержит Subject Alternative Names (SAN) - список доменов и субдоменов, для которых он выдан. Эти данные публичны и доступны для поиска.
С апреля 2018 года Chrome (Google CT Policy) и с октября 2018 - Apple требуют включения публично доверенных сертификатов в CT-логи. Это создаёт полную, поисковую запись каждого субдомена, для которого когда-либо выпускался сертификат - от
api.example.com до internal-tools.example.com. Для OSINT-аналитика CT-логи - самый надёжный источник субдоменов. DNS brute-force зависит от качества словаря. CT покрывает каждое имя, для которого хоть раз выписали сертификат. Разница принципиальная.Практика: запрос к crt.sh для поиска субдоменов
crt.sh - бесплатный поисковый движок от Sectigo, агрегирующий данные из Google Argon, Cloudflare Nimbus, DigiCert Yeti и других CT-логов. Поддерживает JSON-ответы для автоматизации.
Bash:
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
| jq -r '.[].name_value' \
| sort -u \
| grep -v '^\*\.'На что смотреть при анализе результатов:
- Субдомены с паттернами
staging.[I],dev.[/I],test.[I],internal.[/I],vpn.*- потенциальный shadow IT или забытые стенды - Сертификаты, выданные Let's Encrypt для поддоменов, о которых IT не знает - кто-то из сотрудников поднял сервис самовольно
- Субдомены с датой
not_afterв прошлом и отсутствующим DNS-резолвингом - кандидаты на dangling DNS
Ограничения CT-логов
CT не видит:- HTTP-only сервисы без TLS (dev-стенды на порту 8080 без сертификата)
- Субдомены под wildcard-сертификатом, если для них не выпускался отдельный сертификат
- Инфраструктуру за приватными CA (внутренние PKI корпораций)
Перечисление субдоменов: DNS brute-force, zone transfer и комбинированные инструменты
[Применимо: blue team без ограничений на своей инфраструктуре; внешний пентест - осторожно с активными техниками]Passive DNS и CT-логи закрывают пассивную часть разведки. Для полноты картины нужны активные техники - но с пониманием их стоимости.
DNS brute-force инструменты
DNS brute-force отправляет тысячи запросов к авторитативному DNS-серверу домена, проверяя существование субдоменов из словаря. Инструменты:puredns (резолвинг через публичные DNS-серверы с wildcard-фильтрацией), shuffledns (ProjectDiscovery, обёртка над massdns).Работает если: организация использует предсказуемую схему именования (
srv-db-01, app-prod-02, mail-gw). Не работает если: субдомены рандомизированы (UUID-based имена в Kubernetes, Terraform-генерированные имена). Ограничение: генерирует заметный трафик к DNS-серверам цели - десятки тысяч запросов, может вызвать rate limiting и алерты в SOC. На своей инфраструктуре - без ограничений, на чужой - только с письменным разрешением.Zone transfer: уязвимость AXFR
Попытка запросить полную копию DNS-зоны через AXFR -dig axfr example.com @ns1.example.com. Если DNS-сервер разрешает zone transfer для произвольных IP - это одновременно критическая находка (zone transfer уязвимость) и мгновенная полная карта субдоменов.Работает если: DNS-сервер с ошибочной конфигурацией
allow-transfer { any; }. Не работает: BIND 9.x+ с корректным allow-transfer, облачные DNS (Route53, Cloud DNS, Azure DNS) - все блокируют AXFR по умолчанию. В 2025 году это срабатывает на единицах процентов целей. Но проверка стоит 2 секунды - грех не попробовать.NSEC Walking
Для зон с DNSSEC на основе NSEC (не NSEC3) можно последовательно перечислить все записи зоны черезldns-walk. Не работает: зоны с NSEC3 (хешированные имена), зоны без DNSSEC вовсе. Встречается ещё реже, чем открытый AXFR.Trade-off таблица: выбор инструмента для перечисления субдоменов
| Инструмент | Тип | Преимущества | Ограничения | Когда использовать |
|---|---|---|---|---|
| subfinder | Пассивный | Агрегирует 40+ источников, быстрый, без трафика к цели | Полнота зависит от API-ключей (без них покрытие -40-60%) | Первый шаг любого перечисления |
| Amass (enum) | Комбинированный | Глубокая рекурсия, граф связей, OWASP-проект | Медленнее subfinder, сложнее конфигурация, требует больше RAM | Когда нужен граф связей между активами |
| BBOT | Комбинированный | Модульная event-driven архитектура, автоматическая дедупликация | Требует 8+ ГБ RAM при больших скоупах | Полноценная автоматизация EASM-pipeline |
| puredns | Активный (brute-force) | Wildcard-фильтрация, высокая скорость | Генерирует трафик к DNS цели, зависит от словаря | Blue team на своей инфраструктуре |
| crt.sh (curl) | Пассивный (CT) | Бесплатный, без API-ключа, полнота CT-данных | Медленный, нет passive DNS, rate limits | Быстрая проверка без установки инструментов |
Оптимальная комбинация для blue team:
subfinder (пассивный сбор) -> crt.sh (CT-логи) -> puredns (активный brute-force по своим доменам) -> dnsx (верификация резолвинга). Для установки и обновления всего стека ProjectDiscovery советую pdtm (ProjectDiscovery Tool Manager) - он управляет версиями subfinder, dnsx и httpx в единой точке: pdtm -install-all.Shadow IT обнаружение: от dangling DNS до забытых Jenkins
[Применимо: blue team asset discovery, внешний пентест - pre-engagement фаза]
Shadow IT в контексте внешнего периметра - любые активы, о которых ИТ-отдел не знает, но которые доступны из интернета и привязаны к доменам организации. По MITRE ATT&CK это Domain Properties (T1590.001) и WHOIS (T1596.002).
Типичные находки на реальных проектах
На десятках pre-engagement фаз я сталкивался с повторяющимися паттернами:Корпоративные Jira и Confluence, зарегистрированные сотрудниками на личных почтах и размещённые на субдоменах вида
pm.company.com или wiki.team-company.com. WHOIS показывает регистрацию на физлицо, DNS указывает на Atlassian Cloud. Ни один из этих сервисов не фигурировал в CMDB.Jenkins и GitLab CI без авторизации или с дефолтными кредами на субдоменах
ci.[I], build.[/I], deploy.*. Обнаруживаются через CT-логи: Let's Encrypt сертификат выписан - значит, субдомен зафиксирован. На одном проекте Jenkins на build.company.com стоял без пароля восемь месяцев. Восемь.Staging и dev-стенды корпоративных приложений с рабочими данными (иногда - с копией продуктовой базы). Паттерны имён:
staging.[I], dev.[/I], uat.[I], test.[/I], sandbox.*.Облачные ресурсы: S3-бакеты с предсказуемыми именами (
company-backups, company-uploads), Azure Blob Storage, Google Cloud Storage. Ошибки конфигурации облачных хранилищ - одна из самых частых причин утечек, что подтверждают типичные advisory паттерны AWS и GCP.Subdomain Takeover через dangling DNS
Dangling DNS - DNS-запись (обычно CNAME), указывающая на ресурс, который больше не существует. Классический сценарий: CNAMEblog.example.com -> example.herokuapp.com, приложение на Heroku удалено, но DNS-запись осталась. Атакующий регистрирует новое приложение с тем же именем на Heroku - и контролирует blog.example.com.Как обнаружить: после перечисления субдоменов проверяйте каждый CNAME на статус целевого ресурса. Инструмент
subjack автоматизирует проверку для десятков облачных провайдеров. Список уязвимых сервисов поддерживается в репозитории can-i-take-over-xyz(GitHub - EdOverflow/can-i-take-over-xyz: "Can I take over XYZ?" — a list of services and how to claim (sub)domains with dangling DNS records.) на GitHub.Типичные цели takeover: GitHub Pages, Heroku, AWS S3, Azure Blob Storage, Shopify, Fastly, Pantheon. Не все dangling CNAME уязвимы - CloudFront с OAI, Azure CDN с custom domain verification защищают от несанкционированного перехвата.
Пошаговый pipeline: от домена до карты атакуемой поверхности
Требования к окружению
- ОС: GNU/Linux (Kali, Ubuntu 22.04+), macOS; Windows - через WSL2
- RAM: минимум 4 ГБ для subfinder и dnsx, рекомендуется 8 ГБ при работе с Amass или BBOT на больших скоупах (100+ корневых доменов)
- Зависимости: Go 1.21+ (для установки инструментов ProjectDiscovery),
jq,curl,dig - Установка:
go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latestили черезpdtm:go install github.com/projectdiscovery/pdtm/cmd/pdtm@latest && pdtm -install-all - Сеть: нужен интернет-доступ для запросов к API-источникам и DNS-серверам. Offline-режим невозможен
- API-ключи (рекомендуется): SecurityTrails, Censys, Shodan, VirusTotal, Chaos (ProjectDiscovery). Subfinder работает без ключей, но покрытие падает на 40-60%. Ключи настраиваются в
~/.config/subfinder/provider-config.yaml
Шаг 1. Определение seed-доменов
Начните с корневых доменов организации. Источники:- WHOIS-запросы по известным доменам: поле Registrant Organization -> обратный поиск по организации через SecurityTrails или DomainTools
- SPF/DKIM/DMARC записи основного домена через
dig txt example.com- в SPF часто указаны include-записи сторонних сервисов, раскрывающие используемые SaaS - Анализ ASN: определите autonomous system организации через
whois -h whois.radb.net -- '-i origin AS12345'- получите все IP-префиксы, зарегистрированные за компанией
Шаг 2. Пассивное перечисление субдоменов
Запуск subfinder со всеми настроенными API-ключами:subfinder -d example.com -all -o subs_passive.txt. Параллельно - запрос к crt.sh (команда curl из раздела выше). Объединение результатов:
Bash:
cat subs_passive.txt subs_ct.txt | sort -u > subs_combined.txt
echo "[+] Уникальных субдоменов: $(wc -l < subs_combined.txt)"
dnsx -l subs_combined.txt -resp -a -cname -o resolved.txtdnsx верифицирует, какие из найденных субдоменов реально резолвятся, и показывает текущие A-записи и CNAME. Субдомены с CNAME на внешние сервисы - кандидаты на проверку subdomain takeover.Шаг 3. Анализ Passive DNS (исторические записи)
Для каждого корневого домена запросите историю через SecurityTrails API или веб-интерфейс. Ищите: IP-адреса, которые раньше были в A-записях, но сейчас отсутствуют - проверьте, жив ли ресурс по этому IP черезcurl -k https://<IP>. Смена хостинг-провайдера (IP из корпоративного диапазона -> IP облачного провайдера) может указывать на облачный ресурс, оставленный без присмотра.Шаг 4. Построение карты и классификация
Определите хостинг-провайдера по IP (ASN lookup черезwhois или API ipinfo.io). Проверьте HTTP-ответы на каждом субдомене:
Bash:
httpx -l resolved.txt -status-code -title -tech-detect -o http_results.txtШаг 5. Поиск dangling DNS
Из resolved.txt выделите субдомены с CNAME на внешние сервисы (Heroku, GitHub Pages, S3, Azure). Для каждого проверьте: существует ли целевой ресурс? Если CNAME возвращает NXDOMAIN или специфичную ошибку провайдера (404 GitHub, "No such app" Heroku) - это dangling DNS.Шаг 6. Артефакт для команды
Финальный результат - таблица активов с колонками: субдомен, IP, ASN/провайдер, HTTP-статус, технология, наличие в CMDB (да/нет), рекомендация (деактивировать / включить в мониторинг / передать в vulnerability management). Этот артефакт - не разовый документ, а живая таблица, обновляемая ежемесячно.Чеклист для blue team: ежемесячная проверка периметра
Чеклист покрывает требования ID.AM-01 (Asset Management, NIST CSF 2.0) и создаёт baseline для DE.AE-01 (Adverse Event Analysis) - без полного инвентаря невозможно определить, новый актив легитимный или результат компрометации.
Многие команды воспринимают картирование внешней атакуемой поверхности как разовую активность - что-то, что делается перед пентестом раз в год. Это ошибка. Инфраструктура меняется непрерывно: разработчик поднимает staging-стенд, маркетинг запускает лендинг на поддомене, DevOps создаёт CI/CD pipeline на забытом сервере. Каждое из этих событий расширяет периметр, и ни одно не попадает в отчёт годичной давности. Passive DNS разведка и мониторинг CT-логов бесплатны, не требуют коммерческих EASM-платформ и занимают 2-3 часа в месяц на скоуп из 5-10 корневых доменов. Цена бездействия - staging с продуктовыми данными, который полгода висит наружу, и первый, кто его найдёт, окажется не пентестером, а оператором шифровальщика. Каждый день без актуальной карты периметра - день, когда атакующий знает вашу инфраструктуру лучше, чем вы сами. Если хочется потренироваться на реальных OSINT-задачах, чтобы руки привыкли к workflow "домен -> карта -> отчёт", - на HackerLab.pro (https://hackerlab.pro) есть категория OSINT с задачами разной сложности, нужна регистрация, после неё доступны таски. Если интересно, как другие команды автоматизируют asset discovery и какие shadow IT артефакты находят - обсуждение в тредах на форуме codeby.net.
Последнее редактирование модератором:
