ИТ-отдел уверенно называет 100–150 хостов. Запускаешь connectorless-перечисление из публичных источников - получаешь 300+. Разница - dev-стенды, staging-окружения, забытые лендинги маркетинга и legacy API, о которых не помнят даже создатели. Я видел такое не раз: на одном проекте по инвентаризации из 87 "официальных" субдоменов в реальности нашлось 240, и на трёх из них торчали дефолтные креды.
EASM-платформы строят цифровой отпечаток организации без единого запроса к внутренней инфраструктуре, агрегируя то, что и без того видно из интернета. Разберём, какие источники данных стоят за этим процессом, как воспроизвести его руками и на что смотреть при выборе платформы.
Место разведки в цепочке атаки: зачем blue team понимать методы EASM
Connectorless-перечисление - первое, что делает атакующий до отправки первого пакета в сеть цели. В терминах MITRE ATT&CK вся фаза укладывается в тактику Reconnaissance и включает набор конкретных техник:- T1590.001 - Domain Properties - информация о регистрации и связанных доменах
- T1590.002 - DNS - сбор данных о DNS-конфигурации цели (A, MX, NS, CNAME, TXT-записи); при connectorless-перечислении эти данные чаще получают через открытые базы (T1596.001)
- T1590.005 - IP Addresses - определение IP-диапазонов организации через ASN/BGP
- T1596.001 - DNS/Passive DNS - запросы к историческим базам DNS-резолвинга без взаимодействия с целевыми серверами
- T1596.002 - WHOIS - регистрационные данные доменов и IP-блоков
- T1593.002 - Search Engines - Shodan, Censys, Google для обнаружения internet-facing активов
Для blue team тут одна мысль: если вы не видите то, что видит атакующий на этапе разведки, вы не контролируете свою внешнюю поверхность атаки. EASM-платформы автоматизируют именно эти техники, но "обращают вектор" - вместо атаки дают защитнику картину собственной экспозиции.
Контекст: connectorless-перечисление работает на этапе внешней разведки. Внутренняя разведка - Network Service Discovery (T1046, Discovery) - другая фаза, после получения начального доступа. EASM фокусируется на внешнем слое, и это принципиально отличает его от агентных решений, которые требуют установки на хосты внутри периметра.
Connectorless discovery субдоменов: источники данных без единого запроса к цели
Ключевое свойство connectorless-перечисления - платформа не подключается к DNS-серверу организации, не шлёт DNS-запросы к ns1.target.com и не сканирует порты. Вместо этого она агрегирует публичные источники, которые уже содержат нужные данные.
Passive DNS и исторические записи
Passive DNS - базы данных, собирающие DNS-резолвинг в реальном времени из трафика рекурсивных резолверов. Когда кто-то запрашивает dev.target.com, пассивный сенсор фиксирует пару "домен - IP" с меткой времени. Со временем накапливается история: какие субдомены существовали, на какие IP указывали, когда появлялись и исчезали.Основные источники:
- SecurityTrails - один из крупнейших агрегаторов пассивной DNS-истории
- DNSDB (Farsight Security) - коммерческая база passive DNS, широко используемая в threat intelligence
- VirusTotal - агрегирует DNS-резолвинг из собственных сканеров и партнёрских фидов
Ограничение: passive DNS покрывает только те домены, к которым кто-то обращался через публичные резолверы. Внутренние домены, не резолвившиеся извне, останутся невидимыми. Это не баг, а свойство метода.
Certificate Transparency logs
Certificate Transparency (CT) - публичный журнал всех SSL/TLS-сертификатов, выданных удостоверяющими центрами. Каждый сертификат содержит поле Subject Alternative Name (SAN) с перечнем доменов и субдоменов, для которых он выдан.Почему это работает: когда инженер запрашивает wildcard-сертификат для *.internal.target.com или отдельный сертификат для jenkins-ci.target.com, запись попадает в CT-лог. Даже если сервис закрыт файрволом, сам факт выдачи сертификата раскрывает существование субдомена. По сути, CT-логи - это добровольный реестр "вот что у нас есть", который мало кто осознаёт как таковой.
Сервис crt.sh позволяет искать по CT-логам бесплатно. Запрос
%.target.com покажет все сертификаты, включая отозванные и просроченные, а значит, и субдомены, которые когда-либо существовали.Ограничение: CT-логи покрывают только субдомены, для которых выдавались TLS-сертификаты. Внутренние HTTP-сервисы без HTTPS останутся невидимыми.
WHOIS, обратная привязка и данные Shodan/Censys
WHOIS-записи содержат информацию о владельце домена: организацию, контактный email, DNS-серверы. Обратный WHOIS позволяет найти все домены, зарегистрированные на одну организацию или email. BGP-данные (Autonomous System Numbers) привязывают IP-диапазоны к организации.Цепочка обратной привязки:
- WHOIS по основному домену - получение registrant email и organization
- Reverse WHOIS по этим данным - обнаружение всех связанных доменов
- ASN lookup - определение IP-диапазонов организации
- Shodan/Censys по этим диапазонам - обнаружение internet-facing сервисов
Ограничение: Shodan и Censys сканируют не все порты и не все протоколы. Сервисы на нестандартных портах могут быть пропущены в базовом покрытии.
Практика: строим цифровой отпечаток компании
Требования к окружению
- ОС: GNU/Linux (Kali/Ubuntu 22.04+) или macOS; Windows - через WSL2
- RAM: минимум 4 ГБ
- Сеть: доступ в интернет (запросы к публичным API)
- Зависимости: Go 1.21+ для установки инструментов ProjectDiscovery
- API-ключи (рекомендуется): бесплатные ключи SecurityTrails, Shodan, Censys, VirusTotal значительно расширяют покрытие
Шаг 1: перечисление субдоменов
subfinder (ProjectDiscovery, активно поддерживается) агрегирует данные из 40+ источников: CT-логи, passive DNS, Shodan, Censys, VirusTotal. Установка: go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest.
Bash:
# Базовое connectorless-перечисление субдоменов
subfinder -d target.com -all -o subdomains.txt
# Рекурсивное перечисление с API-ключами
subfinder -d target.com -all -recursive -o subdomains_full.txt-all задействует все доступные источники. Флаг -recursive включает рекурсивный поиск глубоких субдоменов (для полного перечисления второго уровня может потребоваться отдельный запуск subfinder против найденных субдоменов). Ни один запрос не направляется к DNS-серверам цели - всё через публичные базы.Шаг 2: DNS-резолвинг и фильтрация
Не все найденные субдомены реально резолвятся.dnsx (ProjectDiscovery) выполняет массовый резолвинг и показывает живые записи:
Bash:
# Резолвинг с выводом A-записей и CNAME
cat subdomains.txt | dnsx -a -cname -resp -o resolved.txtШаг 3: обогащение и построение отпечатка
На выходе - файл с субдоменами, IP-адресами и CNAME-цепочками. Для каждого IP можно определить открытые порты и сервисы через Shodan CLI (shodan host <IP>) или Censys Search, не отправляя ни одного пакета к цели.Итоговый цифровой отпечаток компании включает:
- Полный список субдоменов (включая исторические)
- IP-адреса с привязкой к хостинг-провайдерам
- Открытые порты и сервисы (по данным Shodan/Censys)
- CNAME-цепочки и облачные зависимости
- TLS-сертификаты и их статус
- Кандидаты на subdomain takeover
Как EASM платформы автоматизируют обнаружение внешней поверхности атаки
Ручной процесс из предыдущего раздела - основа. EASM-платформы делают то же самое, но непрерывно и с тремя дополнениями: автоматическая приоритизация рисков, бизнес-контекст и интеграция с vulnerability management.
Согласно описанию CyCognito, процесс EASM состоит из пяти этапов: обнаружение активов, контекстуализация, валидация, приоритизация, рекомендации по устранению. Главное отличие от ручной разведки - контекстуализация: платформа привязывает каждый актив к подразделению, владельцу и уровню критичности.
Сравнение EASM-платформ: connectorless vs гибридный подход
| Критерий | Qualys CSAM+EASM | Microsoft Defender EASM | CyCognito | DeteAct (РФ) | ScanFactory (РФ) |
|---|---|---|---|---|---|
| Discovery-метод | Connectorless + Shodan | Connectorless | Connectorless + active validation | Гибридный (connectorless + воркеры) | Гибридный (активное сканирование) |
| Confidence scoring | Три уровня (High/Medium/Low) | Есть | Бизнес-контекст + критичность | Ручная экспертная валидация | Приоритизация по CVSS |
| Интеграция с VM | Нативная (VMDR) | Azure-экосистема | Собственная валидация | API + webhooks | Собственные сканеры |
| Реестр российского ПО | Нет | Нет | Нет | Да (номер записи уточняйте на reestr.digital.gov.ru) | Данные не подтверждены |
| Ключевое ограничение | Требует лицензии CSAM | Привязка к Azure | Нет free tier | Требует развёртывания воркеров | Фокус на активном сканировании, не чистый connectorless |
Для российского рынка - присутствие в реестре отечественного ПО. ScanFactory - российская компания, по собственным данным обнаружившая значительное число критических уязвимостей у клиентов при сканировании внешнего периметра. Зарубежные решения Qualys, Microsoft и CyCognito после 2022 года ограниченно доступны для российских организаций.
Согласно документации Qualys, EASM использует классификацию, при которой обнаруженные активы получают confidence-теги (High, Medium, Low) в зависимости от достоверности атрибуции к организации. Дополнительно создаются системные теги для маркировки источника данных. Это помогает фильтровать ложные срабатывания и фокусироваться на подтверждённых активах.
Ограничение коммерческих платформ: ни одна не даёт 100% покрытия. Каждая использует свой набор источников и алгоритмов атрибуции. На практике blue team получает лучшие результаты, комбинируя коммерческую EASM-платформу с периодическим ручным перечислением через open-source стек. Одно не заменяет другое.
Обнаружение shadow IT через DNS анализ для кибербезопасности
Shadow IT - одна из главных причин существования EASM как класса решений. По результатам публичных отчётов о пентестах внешнего периметра (в частности, исследований Positive Technologies), значительная часть случаев проникновения связана с уязвимостями и ошибками конфигурации веб-приложений. Многие из этих приложений - теневые, неизвестные службе ИБ.
CNAME-цепочки как индикатор теневой инфраструктуры
CNAME (Canonical Name) - DNS-запись, указывающая, что один домен является алиасом другого. Когда маркетинг привязывает promo.target.com через CNAME к \*.tildacdn.com, в DNS появляется цепочка, видимая из публичных источников. Классический паттерн shadow IT - и встречается он чаще, чем хотелось бы.Что искать при DNS-анализе CNAME-цепочек:
- CNAME на внешний SaaS (Tilda, Wix, Heroku, AWS S3) - актив вне контроля ИТ
- CNAME на несуществующий ресурс (NXDOMAIN) - кандидат на subdomain takeover
- CNAME на IP другой организации - утечка через партнёрскую интеграцию
Subdomain takeover: от забытого поддомена до фишинговой кампании
Конкретный сценарий, описанный аналитиками ScanFactory: маркетинг создаёт промо-сайт на внешней платформе и привязывает субдомен компании. Акция заканчивается, домен на платформе перестают оплачивать, ответственный сотрудник увольняется. DNS-запись остаётся. Злоумышленник обнаруживает забытый CNAME, регистрирует ресурс на себя, разворачивает фишинговую копию сайта под доменом бренда.Знакомо? Я видел этот сценарий минимум трижды в разных компаниях.
Автоматизированная проверка: выгрузить все CNAME из результатов connectorless-перечисления, проверить резолвинг каждого конечного значения. Если конечный CNAME возвращает NXDOMAIN или указывает на неоплаченный сервис - немедленно удалить DNS-запись.
Этот сценарий относится к категории Security Misconfiguration (A05:2021, OWASP Top 10) - неправильная конфигурация DNS, оставляющая висячие записи.
Чеклист для blue team: внедрение процесса мониторинга внешней поверхности атаки
Каждый пункт - конкретное действие. Чеклист можно передать команде ИБ или включить в регламент инвентаризации.Процесс закрывает требования NIST SP 800-53 в части управления конфигурацией (CM-1) и инвентаризации активов. Работает поверх любой EASM-платформы или без неё, на open-source стеке.
Большинство организаций подходят к EASM как к разовому проекту: купили платформу, провели начальное сканирование, составили отчёт и успокоились. Это фундаментальная ошибка. Значительная часть внешних активов компании меняется в пределах одного года. Цифровой отпечаток организации, составленный в январе, к лету уже неполон.
Реальная ценность EASM не в факте обнаружения субдоменов, а в непрерывности: платформа должна фиксировать изменения в момент, когда DevOps-инженер создаёт новый staging-хост или маркетинг привязывает субдомен к очередному конструктору сайтов. Именно разрыв между "обнаружили" и "начали мониторить" создаёт окно, в которое влетает атакующий.
Из проектов по инвентаризации, в которых я участвовал, наибольшую пользу приносили не сами платформы, а процесс вокруг них: регламент реагирования на появление нового актива, автоматический алерт при обнаружении CNAME на внешний SaaS, интеграция с тикет-системой для назначения владельца. Без этого процесса даже лучшая платформа превращается в ещё один дашборд, на который никто не смотрит. Если вы выстраиваете мониторинг внешней поверхности и хотите сверить подход с коллегами - на codeby.net есть тематический тред, где обсуждают практику asset discovery и интеграцию с SIEM.
Последнее редактирование модератором:
