На внешнем пентесте прошлой осенью мы получили scope из трёх доменов и запрет на активное сканирование до согласования с SOC заказчика. За первые четыре часа - без единого пакета в сторону цели - удалось собрать 47 поддоменов через Certificate Transparency, вытащить исторические IP из DNS-записей через SecurityTrails, обнаружить забытый staging-сервер в Wayback Machine и восстановить структуру команды разработки по метаданным PDF-документов с корпоративного сайта. Когда SOC дал зелёный свет на сканирование, половина работы была уже сделана - а в логах заказчика не было ни одной записи о нашей активности.
Пассивный OSINT реконнект без следов - не академическая концепция, а рабочий этап, который определяет эффективность всего остального. Разберём архитектуру такого сбора от выбора источников до полного workflow, с привязкой к MITRE ATT&CK и с пониманием того, что видит (и чего не видит) Blue Team на другой стороне.
Место пассивной разведки в пентесте и цепочке атаки
Пассивная разведка целиком укладывается в тактику Reconnaissance по классификации MITRE ATT&CK. Это первый этап kill chain: до отправки первого SYN-пакета атакующий (или пентестер) собирает всё, что можно получить без прямого взаимодействия с целевой инфраструктурой.Конкретные техники MITRE ATT&CK, которые покрывает пассивная разведка:
- T1593 - Search Open Websites/Domains: поиск информации через веб-сайты и домены цели, включая подтехники T1593.001 (Social Media) и T1593.002 (Search Engines)
- T1596 - Search Open Technical Databases: запросы к техническим базам - T1596.001 (DNS/Passive DNS) и T1596.002 (WHOIS)
- T1590 - Gather Victim Network Information: сбор сетевой информации - диапазоны IP, топология, CDN
- T1589 - Gather Victim Identity Information: email-адреса сотрудников, учётные записи, организационная структура
Что происходит до и после. Пассивная разведка - точка входа в kill chain. До неё - определение scope и правил engagement. После - переход к активной разведке (сканирование портов, fingerprinting сервисов) и далее к exploitation. Качество пассивного этапа определяет точность последующих атак и количество генерируемого шума: чем полнее карта инфраструктуры до первого контакта, тем меньше лишних сканов и тем ниже вероятность обнаружения.
Что не оставляет следов: граница OSINT без обнаружения
Вопрос, который пентестеры часто решают неправильно: где проходит реальная граница между пассивным и активным? Ответ - в точке генерации лога на стороне цели.
Пассивное действие - обращение к третьей стороне (Google, Shodan, SecurityTrails, crt.sh), которая уже проиндексировала данные цели. Цель не получает от вас ни одного пакета.
Активное действие - обращение к инфраструктуре цели напрямую: DNS-серверу, веб-серверу, почтовому серверу. Даже один DNS-запрос к ns1.target.com - уже активная разведка, потому что он фиксируется в логах DNS.
Конкретная граница для типичных операций:
| Действие | Пассивное? | Куда идёт запрос | Что видит цель |
|---|---|---|---|
| Запрос к crt.sh по домену | Да | crt.sh (третья сторона) | Ничего |
| Shodan по org:"Company" | Да | Shodan API | Ничего |
| Google Dork site:target.com | Да | Ничего | |
| SecurityTrails DNS history | Да | SecurityTrails API | Ничего |
| nslookup target.com | Нет | DNS-сервер цели | DNS query log |
| curl Target : Expect More. Pay Less. | Нет | Веб-сервер цели | Access log |
| theHarvester -b google | Да | Google, Bing | Ничего |
| theHarvester -b dns | Нет | DNS-сервер цели | DNS query log |
Тонкий момент: ряд инструментов смешивают пассивные и активные модули. theHarvester с флагом
-b google работает пассивно - ищет в Google. Тот же инструмент с -b dns делает прямые DNS-запросы к серверам цели - уже активная разведка. SpiderFoot по умолчанию включает модули с обращением к цели напрямую. Перед запуском любого инструмента проверяйте, какие модули активны и куда направляются запросы. Я на одном проекте так спалился - запустил SpiderFoot "из коробки", а он начал резолвить поддомены через DNS цели. SOC заметил через 12 минут.Ограничение. Даже "чисто пассивные" действия оставляют косвенные следы. Запрос к Google фиксируется Google. Запрос к Shodan API - Shodan. Если противник имеет доступ к логам этих сервисов (маловероятно для большинства целей, но актуально при работе против APT-групп или разведывательных организаций), он теоретически может установить факт разведки. Для минимизации этого риска используются VPN, Tor и анонимный сбор данных через отдельные аккаунты без привязки к реальной идентичности.
Источники данных для скрытого сбора OSINT
Пассивный DNS и Certificate Transparency
Пассивный DNS-анализ (T1596.001) - главный источник инфраструктурной разведки. В отличие от прямого DNS-запроса к серверу цели, пассивная DNS-разведка использует исторические данные, собранные третьими сторонами: SecurityTrails, Farsight DNSDB, VirusTotal.Что даёт пассивный DNS:
История привязки домен-IP. Если target.com год назад резолвился в IP облачного провайдера, а сегодня - в другой, видны миграции инфраструктуры и «хвосты»: старые IP, где могут остаться забытые сервисы.
Обнаружение поддоменов. Исторические DNS-записи раскрывают поддомены, которые никогда не попали бы в результаты brute-force: dev-серверы, staging-среды, тестовые API.
Связывание инфраструктуры. Два домена (основной и потенциально вредоносный), резолвившиеся в разное время в один IP - связка, видимая только через passive DNS. Именно такие корреляции позволяют threat intelligence командам связывать фишинговые кампании с основной инфраструктурой атакующего - подобные кейсы описаны в документации Farsight DNSDB.
Инструменты: SecurityTrails (коммерческий продукт Recorded Future, требуется подписка или trial-доступ; ранее существовал ограниченный бесплатный tier), Farsight DNSDB (коммерческий, лидер по полноте данных), VirusTotal passive DNS (ограниченный бесплатный доступ).
Certificate Transparency (CT) - второй критически важный источник. С апреля 2018 года Chrome требует публикации всех новых публично доверенных TLS-сертификатов в CT-логи (Apple ввела аналогичное требование позже; CT-инфраструктура запущена в 2013 году). Для пентестера это означает: каждый поддомен, для которого выпускался публично доверенный сертификат, доступен через один запрос к crt.sh - полностью пассивная операция:
Bash:
# Вытаскиваем все поддомены из CT-логов - 30 секунд и готово
curl -s "https://crt.sh/?q=%25.target.com&output=json" \
| jq -r '.[].name_value' | sort -uКогда техника НЕ работает: CT-логи показывают только домены с выпущенными публичными сертификатами. Self-signed сертификаты в CT не попадают. Поддомены без TLS (чистый HTTP) не отражаются. Организации, использующие private CA для внутренних сервисов, не оставляют следов в CT. Так что если цель - параноик с собственным CA, этот источник будет полупустым.
WHOIS, RDAP разведка и доменная аналитика
WHOIS и RDAP (T1596.002) - источники информации о владельцах доменов и IP-блоков. Запросы к публичным WHOIS-серверам (whois.iana.org, whois.ripe.net) - пассивные: обращение идёт к реестру, не к инфраструктуре цели.Что извлекается:
- Имя регистранта, организация, контактные email (если не скрыты за privacy-сервисом)
- Даты регистрации и истечения домена - косвенный индикатор зрелости инфраструктуры
- Nameserver-записи - указывают на DNS-провайдера и помогают понять архитектуру
- ASN и IP-диапазоны через RIR-базы (RIPE, ARIN, APNIC)
[Применимо: внешний пентест, black box] WHOIS-разведка наиболее продуктивна при black box сценарии: начиная с одного домена, через WHOIS-корреляцию можно найти связанные домены организации. Классический приём - взять email регистранта из WHOIS и через reverse WHOIS (SecurityTrails, DomainTools) найти все домены, зарегистрированные на тот же адрес. На одном проекте так обнаружили 14 доменов заказчика, о которых он "забыл" нам рассказать.
Когда техника НЕ работает: с введением GDPR большинство европейских регистраторов скрывают персональные данные в WHOIS. Для доменов .ru WHOIS отдаёт организацию, nameservers и даты, но имя регистранта для физлиц скрыто. Reverse WHOIS по email теряет эффективность, если регистрант использует privacy-сервис.
Google Dorking, метаданные и кэшированные данные
Google Dorking (T1593.002, Search Engines) - использование операторов поиска для извлечения данных с сайта цели через кэш Google. Вся коммуникация идёт с Google, не с целью - классическая passive reconnaissance technique.Ключевые операторы для footprinting без следов:
site:target.com filetype:pdf- PDF-документы с метаданными (ПО, имена авторов, внутренние пути)site:target.com inurl:admin | inurl:panel- административные панелиsite:target.com ext:sql | ext:bak | ext:log- утечки резервных копий и логов"target.com" site:pastebin.com | site:github.com- упоминания домена на сторонних площадках (утечки конфигов, credentials)
[URL='https://exiftool.org/']exiftool[/URL] (open source, активно поддерживается), FOCA (Windows-утилита для массового анализа метаданных).Я предпочитаю
exiftool - он легче, работает из консоли и не требует GUI. Но FOCA удобнее для массовой обработки сотен документов с визуализацией связей.Wayback Machine (web.archive.org) хранит исторические снимки веб-страниц. Ценность для пентестера - в страницах, которые цель удалила: старые API-документации, тестовые страницы с credentials, конфигурационные файлы. Запросы к Wayback Machine полностью пассивны.
Когда техника НЕ работает: Google Dorking зависит от глубины индексации. Страницы за авторизацией или закрытые через robots.txt не индексируются. Цель может настроить Google Search Console alerts и получать уведомления об аномальных поисковых запросах, хотя на практике это встречается редко. Wayback Machine уважает robots.txt и удаляет архивы по запросу владельца.
Пассивный footprinting: инструменты и trade-off таблица
Сравнение ключевых инструментов пассивного OSINT с позиции практикующего пентестера. Оценка основана на реальных сценариях внешнего пентеста.| Инструмент | Преимущества | Ограничения | Когда использовать | Когда НЕ использовать |
|---|---|---|---|---|
| SecurityTrails | Passive DNS + reverse WHOIS, JSON API, быстрая корреляция доменов | Бесплатный тариф - 50 запросов/день; полная история - платная подписка | Начало внешнего пентеста: поддомены, DNS-история, связанные домены | Нужна активная разведка (порты, баннеры) |
| Shodan | Баннеры сервисов без сканирования, фильтры по org/ASN/port | Данные устаревают (задержка индексации - дни/недели); бесплатно - 100 результатов | Оценка внешней поверхности атаки: порты, версии, SSL-конфигурация | Нужны данные в реальном времени |
| SpiderFoot | 200+ модулей, автоматическая корреляция, веб-интерфейс | Часть модулей делает активные запросы - нужна ручная фильтрация; много шума | Автоматизация широкого сбора с временем на фильтрацию | Строго пассивный режим без тонкой настройки |
| Maltego | Визуализация графов связей, кастомные трансформы, интеграция API | Тяжёлый десктоп, Community Edition ограничена; требует API-ключи | Атрибуция и граф связей: домены, IP, email, ASN | Быстрый сбор при дефиците времени |
| theHarvester | Быстрый сбор email и поддоменов, предустановлен в Kali | Ограниченная глубина; модуль -b dns - активный | Первичный сбор email для социальной инженерии | Глубокий passive DNS-анализ |
| crt.sh | Бесплатный доступ к CT-логам, JSON API, полнота данных | Только сертификаты - нет DNS, нет WHOIS; медленный на крупных доменах | Первый шаг - поддомены через CT | Информация за пределами TLS |
Статус поддержки: SecurityTrails - коммерческий продукт Recorded Future, активно поддерживается. Shodan - коммерческий, активно поддерживается. SpiderFoot - open source, GitHub: smicallef/spiderfoot (проверяйте активность коммитов, проект имел периоды пониженной активности). theHarvester - входит в Kali Linux, GitHub: laramies/theHarvester, активно поддерживается. Maltego - коммерческий, Maltego Technologies, активно поддерживается. crt.sh - поддерживается Sectigo, бесплатный сервис.
Workflow пассивного реконнекта без обнаружения
Шаг 5: Google Dorking и метаданные. Серия Google Dorks для поиска документов, админ-панелей, утечек. Скачивание найденных PDF/DOCX, извлечение метаданных через
exiftool. Результат: имена сотрудников (потенциальные учётные записи), версии ПО, внутренняя структура каталогов.Шаг 6: Сбор email через theHarvester.
Bash:
# Только пассивные источники - Bing, crt.sh и DuckDuckGo
theHarvester -d target.com -b bing,crtsh,duckduckgo -f harvest_report-b указывает только пассивные источники. Модуль google в theHarvester 4.x нестабилен из-за rate-limiting и CAPTCHA со стороны Google - я от него отказался.Шаг 7: Wayback Machine. Проверка web.archive.org на предмет удалённых страниц: API-документации, тестовых сред, файлов конфигурации. Результат: данные, которые цель считает удалёнными. (Спойлер: интернет помнит всё.)
Шаг 8: Консолидация. Сведение всех данных в единый отчёт: домены, IP, сервисы, люди. Maltego удобен для визуализации графа связей на этом этапе.
Весь workflow - без единого пакета к инфраструктуре цели. Каждый шаг обращается исключительно к третьим сторонам. По данным HIBP / Troy Hunt (2024), более 3.5 миллиардов записей скомпрометированы и каталогизированы в публичных базах утечек - ещё один пассивный источник для проверки email сотрудников на предмет скомпрометированных паролей (через HIBP API).
Ограничения и детектирование пассивной разведки
Когда пассивного сбора недостаточно
Пассивная разведка даёт карту инфраструктуры, но не даёт глубины. Конкретные ситуации, где нужен переход к активным методам:Актуальность данных. Shodan обновляет индекс с задержкой от дней до недель. Если цель сменила хостинг вчера, Shodan покажет устаревшие данные.
Внутренние сервисы. Пассивный OSINT видит только то, что торчит наружу. Интранет-приложения, внутренние API, сервисы за VPN - невидимы.
Точные версии ПО. Shodan-баннеры дают приблизительную информацию, но для подтверждения конкретной версии (а значит, конкретного CVE) нужен прямой fingerprinting.
Кастомные приложения. Google Dorking и CT не покажут уязвимости в кастомном коде - для этого нужен активный анализ.
Decision tree:
- Scope допускает только пассивную разведку - работайте по описанному workflow, выжимайте максимум из третьих сторон.
- Нужна актуальная картина портов и сервисов - после пассивного этапа аккуратное сканирование (низкая скорость, специфичные порты).
- Цель - веб-приложение - пассивный OSINT даёт контекст (стек, людей), но эксплуатация требует прямого взаимодействия.
OSINT-архитектура для Blue Team: обнаружение и защита
Парадокс пассивной разведки для защитников: нельзя обнаружить то, что не касается вашей инфраструктуры. Но косвенные индикаторы есть:CT-мониторинг. Сервисы мониторинга CT-логов позволяют получать уведомления о запросах к сертификатам ваших доменов. Это не детект разведки, а раннее предупреждение.
WHOIS lookups monitoring. Ряд регистраторов предоставляет статистику запросов к WHOIS. Аномальный всплеск может указывать на разведку.
Google Search Console. Показывает запросы, по которым ваш сайт появляется в выдаче. Резкий рост запросов с операторами site:, filetype:, inurl: - сигнал о Google Dorking.
Threat intelligence платформы. MISP, Recorded Future и аналогичные решения позволяют отслеживать упоминания ваших доменов, IP и email в публичных источниках и breach-базах.
По данным IBM X-Force Threat Intelligence Index 2025, 70% атак затронули критическую инфраструктуру. CrowdStrike Global Threat Report 2025 фиксирует двукратный рост вредоносного использования GenAI для социальной инженерии - а она начинается именно с пассивного OSINT: сбора email, имён, должностей через открытые источники. Для Blue Team это означает: минимизация цифрового следа организации - мера защиты не менее важная, чем патчинг.
Чеклист для Blue Team - снижение поверхности OSINT:
- Включить WHOIS privacy для всех доменов организации.
- Аудировать метаданные публичных документов (PDF, DOCX) - удалить внутренние пути, имена авторов, версии ПО.
- Проверить CT-логи (crt.sh) на наличие поддоменов с чувствительными именами (dev, staging, admin, vpn).
- Настроить мониторинг Google Search Console на аномальные запросы с операторами.
- Ограничить детализацию стека технологий в публичных вакансиях - не указывать версии SIEM, EDR, конкретных продуктов.
- Отправить запрос на удаление устаревших архивов в Wayback Machine через robots.txt exclusion.
- Настроить API-интеграцию с Shodan/Censys для мониторинга неожиданно выставленных сервисов.
nmap и получить список портов может каждый. Выстроить полную картину инфраструктуры, людей и технологий цели без единого пакета в её сторону - навык, который формируется через десятки проектов.На моей практике самые ценные находки приходили именно на пассивном этапе: забытый staging с production-базой, API-ключ AWS в метаданных PDF, внутренний домен в CT-логах - всё это обнаруживалось, когда SOC заказчика ещё не подозревал о нашем существовании.
При этом наблюдаю устойчивый тренд: начинающие пентестеры воспринимают пассивный OSINT как "скучную подготовку" и перескакивают к сканированию. Стратегическая ошибка. В проектах, где заказчик мониторит периметр через MaxPatrol SIEM, Elastic 8.x+ или Splunk и закрывается CrowdStrike Falcon или SentinelOne, преждевременное активное сканирование заканчивается блокировкой IP и разговором с SOC вместо продуктивной работы.
Пассивная фаза - не подготовка, а ключевой этап самой работы. На описанных проектах пассивный этап давал основную часть actionable intelligence до перехода к активному сканированию. Если после четырёх часов пассивной разведки у вас пустой отчёт - проблема не в подходе, а в методологии сбора. Попробуйте прогнать свой текущий scope по этому workflow и сравните результат с тем, что вы обычно получаете за первый час работы.
Последнее редактирование модератором:
