На внешнем аудите финтех-сервиса через crt.sh нашёлся staging-поддомен GitLab, не фигурировавший ни в одном реестре активов компании. Сертификат выпустили восемь месяцев назад, поддомен резолвился в IP из того же /24-блока, что и продакшен, а на сервере крутился GitLab CE с дефолтной конфигурацией. Весь OSINT анализ инфраструктуры компании занял 40 минут - без единого активного скана. И это не экзотика, а вторник. Ниже - методика, которая позволяет собрать полную карту внешнего периметра организации через три источника: WHOIS, DNS и Certificate Transparency логи.
Зачем blue team нужна инфраструктурная разведка
Перед активной фазой атаки злоумышленник решает задачу атрибуции - определяет, какие домены, IP-блоки и сервисы принадлежат цели. В терминологии MITRE ATT\&CK это техника Acquire Infrastructure: Domains (T1583.001, тактика Resource Development): атакующие регистрируют собственные домены для кампаний. Но те же методы пассивной разведки работают и в обратную сторону - для инвентаризации активов с позиции защитника. Подробнее - в нашем подробном разборе osint для специалиста по информационной безопасности.NIST CSF v2.0 в субкатегории ID.AM-01 требует поддерживать инвентаризацию аппаратного обеспечения организации; смежные субкатегории (ID.AM-02 для ПО) расширяют это на прочие активы. На практике реестры устаревают за недели. Забытые staging-серверы, тестовые поддомены, протухшие сертификаты - всё это раздувает поверхность атаки, оставаясь невидимым для SOC. OSINT анализ инфраструктуры компании закрывает этот разрыв - даёт срез периметра глазами внешнего наблюдателя.
WHOIS-анализ домена: от регистрационной записи до кластера
WHOIS - протокол запроса регистрационных данных домена, определённый в RFC 3912. Каждая запись содержит контакты регистранта, регистратора, nameserver'ы, даты регистрации и истечения. Современная замена - RDAP (Registration Data Access Protocol, RFC 7482), который возвращает структурированный JSON вместо plain-text и технически поддерживает дифференцированный доступ к полям. На практике большинство операторов TLD применяют такое же редактирование персональных данных, как в WHOIS - GDPR никуда не делся. По данным WhoisFreaks, большинство крупных gTLD-реестров уже публикуют RDAP-эндпоинты, и для программной обработки RDAP однозначно предпочтительнее.Ключевые поля для инфраструктурной атрибуции
При WHOIS-анализе домена фокус на четырёх полях: registrant email, registrant organization, nameservers и даты регистрации. Каждое поле - отдельный вектор корреляции.Registrant email - самый ценный уникальный идентификатор. Один и тот же email в записях нескольких доменов с высокой вероятностью указывает на одного оператора. WHOIS показывал разные имена регистрантов, но в подобных кейсах десятки доменов могут использовать один телефонный номер с последовательной сменой последних цифр. Одного такого паттерна бывает достаточно, чтобы атрибутировать всю инфраструктуру единому оператору (гипотетический пример для иллюстрации подхода).
Nameservers - самый стабильный индикатор. Смена NS технически дороже смены контактных данных, поэтому злоумышленники переиспользуют одни и те же nameserver-конфигурации даже при смене регистрантов. Общий nameserver у нескольких подозрительных доменов - high-confidence связь, особенно если NS принадлежит bulletproof-хостеру.
Даты регистрации и смены privacy - домен, переключивший privacy-защиту за неделю до известной атаки, даёт значимый сигнал. Историческая WHOIS-запись нередко содержит полные контактные данные до мая 2018 года - момента вступления в силу GDPR, когда регистраторы начали массово затирать поля. По данным WhoisFreaks, исторические снимки WHOIS для домена можно получить через WHOIS History API - так удаётся извлечь контакты, существовавшие до редактирования.
MX-записи дополняют WHOIS: threat actor'ы часто переиспользуют почтовую инфраструктуру между кампаниями. Общий MX-сервер у нескольких подозрительных доменов - инфраструктурная связь, независимая от регистрантных данных.
Reverse WHOIS: кластеризация доменов по регистранту
Reverse WHOIS - поиск всех доменов, зарегистрированных на конкретный email, имя или организацию. Инструменты: Whoisology (приобретена WhoisXML API в 2018 году), DomainTools, SecurityTrails.Типичный workflow: из WHOIS целевого домена извлекаете email регистранта → reverse WHOIS по этому email → получаете список из 5–200 доменов → каждый проверяете на совпадение nameservers и дат регистрации → формируете кластер. Легитимная компания обычно имеет 5–20 доменов. Оператор вредоносной инфраструктуры - сотни, часто с узнаваемыми паттернами именования и тесными окнами регистрации.
Предусловия и ограничения WHOIS-анализа:
- GDPR-редактирование: домены в gTLD-зонах после мая 2018 часто показывают "REDACTED FOR PRIVACY". Обход - исторические снимки, где данные до редактирования сохранены.
- Privacy-сервисы (Domains By Proxy, WhoisGuard) маскируют реального регистранта. Некоторые регистраторы раскрывают данные по верифицированным abuse-жалобам.
- Shared hosting: один регистрант может обслуживать сотни клиентов. Домен на shared-хостинге не означает прямую связь с целевой организацией - нужна перекрёстная валидация через DNS и сертификаты.
DNS-анализ инфраструктуры: пассивный DNS и поиск поддоменов
DNS-записи - второй столп инфраструктурного OSINT. A-записи указывают на IP, MX - на почтовые серверы, TXT - на SPF/DKIM (иногда содержащие организационные идентификаторы), NS - на nameservers.Пассивная разведка домена через DNS-историю
Passive DNS (pDNS) - база исторических DNS-резолвов, собранных из реального трафика интернет-провайдеров и DNS-резолверов. В отличие от активного запросаdig, pDNS не генерирует логов на стороне цели и показывает все IP-адреса, на которые домен резолвился за период наблюдения. Источники: SecurityTrails, Farsight DNSDB, VirusTotal (passive DNS tab), CIRCL Passive DNS.Что pDNS даёт при attack surface mapping:
- Ротация IP: вредоносный домен менял IP еженедельно - pDNS покажет все 52+ адреса за год. Reverse DNS по каждому из них выявит другие домены на той же инфраструктуре.
- Staging-активность: перед запуском кампании атакующие регистрируют и настраивают домены. Группа доменов, впервые активированных одновременно - индикатор подготовки.
- Привязка к хостинг-провайдеру: конкретные threat actor'ы по экономическим причинам возвращаются к одним и тем же хостерам. Если IP-диапазоны актора известны, pDNS покажет все домены, когда-либо хостившиеся в этих диапазонах.
Subdomain enumeration: инструменты и подход
Поиск поддоменов - критический этап passive reconnaissance. Три подхода, каждый со своими сильными и слабыми сторонами:Certificate Transparency (подробнее в следующем разделе) - поиск поддоменов через SAN-поля сертификатов. Не требует взаимодействия с целевой инфраструктурой. Мой любимый - тихий, быстрый, и CT-логи не соврут.
DNS brute-force - перебор по словарю. Инструменты:
subfinder (агрегирует данные из CT-логов, DNS-агрегаторов, поисковиков без активного сканирования), amass (комбинирует пассивные источники с активной энумерацией), dnsx (массовый резолв найденных поддоменов). Команда subfinder -d example.com -silent за секунды выведет список обнаруженных поддоменов.Reverse DNS по IP-блоку - если ASN или IP-диапазон организации известен (через
bgp.he.net или IP WHOIS), reverse DNS покажет все PTR-записи в этом блоке. Часто именно так всплывают внутренние сервисы, опубликованные на корпоративных IP.Когда DNS-анализ НЕ работает:
- Wildcard DNS: если целевой домен настроен с wildcard-записью
*.example.com → один IP, brute-force даёт массу ложных срабатываний. Валидация: проверьте резолв заведомо несуществующего случайного поддомена - если он отвечает, wildcard активен. - CDN и балансировщики: поддомен за Cloudflare/Akamai резолвится в IP CDN, а не реального сервера. Для определения origin IP нужен исторический pDNS (записи до подключения CDN) или утечки реального IP через HTTP-заголовки.
Сертификатный OSINT: Certificate Transparency логи
Certificate Transparency (CT) - публичный аудит-лог, куда попадает каждый TLS-сертификат, выданный доверенным CA. Стандартизирован в RFC 9162 / RFC 6962. Ключевое свойство: запись необратима и появляется в течение секунд после выдачи сертификата. По сути CT-логи - это такой невольный донос удостоверяющих центров на всю инфраструктуру, которая когда-либо получала сертификат.Поиск по Censys и Shodan через CT-данные
crt.sh - бесплатный интерфейс к CT-логам от Sectigo. Запрос%.example.com возвращает все сертификаты для домена и его поддоменов. В результатах видны: Common Name и SAN (покрытые сертификатом поддомены), Issuer (Let's Encrypt, DigiCert, self-signed), даты выдачи и истечения, serial number и fingerprint.Censys дополняет crt.sh: помимо сертификатов, индексирует баннеры сервисов и показывает, на каких IP и портах обнаружен конкретный сертификат. Запрос
services.tls.certificates.leaf.names: example.com в Censys Search вернёт все хосты с этим доменом в сертификате. Shodan предоставляет аналогичные данные через фильтр ssl.cert.subject.CN.Один запрос к crt.sh по домену организации может выявить:
staging.internal.example.com- забытый staging с внутренним именемvpn.example.com- VPN-шлюз, не указанный в публичной документацииgitlab-runner-01.example.com- CI/CD-инфраструктура, о которой не знает команда ИБ
TLS сертификаты OSINT: кластеризация по fingerprint
Самоподписанные сертификаты (типичны для C2-серверов малвари) содержат уникальные метаданные: Issuer, Subject, public key. Атакующие переиспользуют один private key или один генератор сертификатов для нескольких доменов. Если атакующий использует самоподписанный сертификат с характерным issuer name (скажем, содержащим внутреннее название инфраструктуры), поиск по этому issuer в CT-логах и Censys может выявить десятки или сотни сертификатов для разных доменов - вся инфраструктура кампании становится видна из одного запроса.Для blue team урок прямой: любой обнаруженный подозрительный сертификат стоит проверить по fingerprint и issuer в Censys или crt.sh. Совпадения указывают на одного оператора.
CT-мониторинг работает и проактивно: если атакующий регистрирует фишинговый домен-клон (
paypa1-secure-login.com, gitlab-auth-target.com) и получает TLS-сертификат, CT-лог фиксирует это мгновенно. Событие из MISP CIRCL OSINT feed за июнь 2026 года - фишинговая кампания против клиентов отелей в Люксембурге - классифицировано с тегами misp-galaxy:financial-fraud="Phishing" и tlp:white. Подобные кампании в теории детектируемы на этапе подготовки инфраструктуры через CT- и DNS-мониторинг, до запуска самой рассылки. То есть можно поймать фишера за руку ещё до того, как он отправит первое письмо.Когда CT-логи НЕ помогут:
- CT не покрывает сертификаты от private CA (внутренние корпоративные центры сертификации). Видны только публичные CA.
- Let's Encrypt сертификаты - Domain Validation only, без данных об организации. Для атрибуции нужны дополнительные сигналы.
Инфраструктурная атрибуция: workflow из пяти фаз
Фаза 5 - Верификация. Каждый кластер проверяется на реальную принадлежность цели. И вот тут начинается самое интересное - отсев мусора.
Валидация: как отсеять false positives
Главная ошибка новичков - принимать shared-ресурсы за собственную инфраструктуру цели. Чек-лист валидации:Shared vs dedicated. Reverse DNS по IP: 500 доменов на одном адресе - shared hosting, тут всё понятно. IP WHOIS покажет, принадлежит ли блок хостинг-провайдеру или конечной организации. Домен, зарегистрированный в одной стране, но размещённый на IP-блоке в другой, принадлежащем bulletproof-хостеру - индикатор намеренного сокрытия.
CDN-маскировка. Домен за Cloudflare резолвится в IP Cloudflare, а не реальный сервер. MX-записи часто указывают на origin-хостинг (тут CDN не прикрывает), а исторический pDNS хранит IP до подключения CDN.
Bulletproof hosting. IP из ASN с высокой концентрацией вредоносной активности. AbuseIPDB даёт confidence score от 0 до 100 - значение выше 75 рекомендуется как порог для подозрения. При проверке стоит исключать Tor exit nodes (список на torproject.org/exit-addresses) и CGNAT-диапазоны - они дают ложные срабатывания.
Кросс-валидация. Каждая находка подтверждается минимум двумя независимыми источниками: CT → pDNS → IP WHOIS. Одного сигнала для атрибуции недостаточно - на этом спотыкаются чаще всего.
Кейс: recon компании на примере публичного GitLab
GitLab - частая находка при сертификатном OSINT. Организации размещают GitLab CE/EE на поддоменах видаgitlab.company.com или git.internal.company.com. SAN-поля сертификатов и DNS-записи раскрывают внутреннюю топологию, даже если сервис не предназначен для внешнего доступа.Пошаговый разбор (обобщение нескольких реальных проектов):
Шаг 1. Запрос к crt.sh по
%.target.com. Среди результатов: gitlab.target.com, gitlab-runner-ci.target.com, staging-gl.target.com.Шаг 2. DNS-резолв каждого поддомена.
gitlab.target.com резолвится в IP из корпоративного блока. staging-gl.target.com - IP из того же /24. gitlab-runner-ci.target.com - NXDOMAIN: DNS-запись удалена, но сертификат остался в CT-логе как исторический след. Домен мёртв, а след - живёт.Шаг 3. IP WHOIS для обнаруженных адресов - оба принадлежат одному ASN организации. Не shared hosting.
Код:
whois 198.51.100.10
# NetRange: 198.51.100.0 - 198.51.100.255
# OrgName: Target Corp
# OrgId: TARGETCORP
# (данные анонимизированы для демонстрации)*.internal.target.com. Внутренний wildcard-поддомен в публичном сертификате - утечка данных о внутренней DNS-зоне. Кто-то заказал wildcard-сертификат через корпоративный аккаунт CA и даже не подумал, что CT-лог запишет всё.Шаг 5. HTTP-баннер на порту 80 показывает GitLab CE login page с версией в footer.
Код:
# Минимальный workflow для воспроизведения
curl -s "https://crt.sh/?q=%25.target.com&output=json" \
| jq -r '.[].name_value' | sed 's/\n/\n/g' | sort -u
# Команды выполняются независимо друг от друга
echo "staging-gl.target.com" | dnsx -silent -a -resp
# Получаем IP и передаём в whois
ip=$(dig +short staging-gl.target.com); whois "$ip"Такой кейс - не экзотика. На аудитах это воспроизводится регулярно: компании заказывают сертификаты через корпоративный аккаунт у CA, CT-логи фиксируют каждый выпуск, а тестовые поддомены остаются доступными месяцами после завершения разработки.
Три связки данных - WHOIS, DNS, Certificate Transparency - на практике закрывают порядка 80% задач инфраструктурного OSINT при внешнем аудите. Оставшаяся часть требует специализированных платформ (Maltego для визуализации графов, SpiderFoot для автоматизации) или активных техник за рамками passive reconnaissance.
Неудобная правда вот в чём: проблема не в сложности описанных техник. Они воспроизводимы за час даже стажёром с терминалом. Проблема - многие blue team команды не запускают OSINT анализ инфраструктуры компании на регулярной основе. Один раз при найме пентестеров - и потом тишина на год. За этот год в CT-логах накапливаются десятки новых сертификатов, в DNS появляются поддомены от dev-команд, а забытые staging-серверы обрастают уязвимостями. В одном из проектов staging-GitLab, обнаруженный через crt.sh, содержал в открытых репозиториях API-токены к облачной инфраструктуре - об этом узнали только при внешнем аудите, не из внутренних процессов. Автоматизация CT-мониторинга через webhook и алерт в SIEM на новый поддомен корпоративного домена - не задача для выделенной threat intelligence команды с бюджетом. Это гигиена уровня обновления антивирусных баз, реализуемая парой скриптов и cron-задачей. Рискну предположить, что через пару лет непрерывный мониторинг CT-логов станет обязательным требованием в стандартах, но ждать стандартов - значит терять время. На codeby.net есть тред, где blue team практики обсуждают конкретные workflow автоматизации и мониторинга периметра - стоит заглянуть.
