Статья OSINT пентест: полный арсенал разведки по цели — от Shodan до графа связей

Когда мне ставят задачу на внешний пентест, первое, что я делаю - закрываю Burp Suite. Серьёзно. Следующие два-три дня я не отправлю ни одного пакета на цель. Вместо этого строю карту: домены, поддомены, IP-блоки, сертификаты, email-адреса, имена сотрудников, технологический стек, забытые dev-серверы, публичные репозитории. Всё это - разведка по открытым источникам, она же OSINT.

По моему опыту, фаза разведки съедает 30–40% времени проекта, но определяет 70–80% его результата. Пентестер, который потратил на recon полчаса и сразу полез сканировать, найдёт типовые дыры из OWASP Top 10. Пентестер, который две недели копал данные, найдёт забытый Jenkins на поддомене ci-old.target.com с дефолтными кредами - и получит RCE без единого эксплойта.

Здесь я покажу рабочий процесс пассивной разведки цели: какие инструменты для пентеста использую, в каком порядке, почему именно так, и как выход одного инструмента определяет выбор следующего. Не список утилит с описанием ключей - а реальный pipeline сбора информации о цели, который я запускаю на каждом проекте.

Разведка через призму MITRE ATT&CK: зачем пентестеру фреймворк​

Прежде чем открывать терминал, стоит разобраться, что именно мы делаем в терминах adversary emulation. Каждое действие на фазе recon маппится на конкретные техники MITRE ATT&CK из тактики Reconnaissance. Это не академическое упражнение - маппинг помогает структурировать работу и ничего не забыть.

Мой типичный recon-процесс в разрезе ATT&CK:

Что делаю	Техника ATT&CK	ID
Ищу домены, поддомены, IP-блоки в Shodan/Censys	Search Open Technical Databases	T1596
Смотрю профили сотрудников в LinkedIn, GitHub	Search Open Websites/Domains	T1593
Собираю email-адреса через theHarvester	Gather Victim Identity Information	T1589
Определяю ASN, BGP, сетевые блоки	Gather Victim Network Information	T1590
Анализирую вакансии для определения стека	Gather Victim Org Information	T1591
Фингерпринчу веб-серверы, CMS, фреймворки	Gather Victim Host Information	T1592
Сканирую порты через nmap (активная фаза)	Active Scanning	T1595

Обратите внимание: T1595 (Active Scanning, Reconnaissance) - это уже граница между пассивным и активным recon. Всё, что выше - не генерирует трафика к цели. Nmap и подобные инструменты оставляют следы в логах IDS/IPS. При внешнем сканировании портов это T1595.001 (Scanning IP Blocks) или T1595.002 (Vulnerability Scanning) из тактики Reconnaissance. Техника T1046 (Network Service Discovery) относится к тактике Discovery и описывает обнаружение сервисов после получения доступа к среде. Ключевое различие между T1595 и T1046 - тактика и фаза атаки (Reconnaissance vs Discovery), а не только физическое расположение атакующего. В рамках согласованного пентеста это допустимо, но порядок имеет значение: сначала пассивный сбор информации о цели, потом активное сканирование по уже сформированному списку IP и портов.

Пассивная разведка инфраструктуры: фундамент без единого пакета​

Пассивная разведка цели - основной рабочий инструмент на первые дни проекта. Никакого трафика к целевой инфраструктуре. Все данные берутся из третьих источников: поисковые движки по устройствам, DNS-агрегаторы,

Ссылка скрыта от гостей

, кэши поисковых систем.

WHOIS, DNS и Certificate Transparency - три кита начального recon​

Каждый проект я начинаю одинаково. Получил имя компании и основной домен - запускаю три параллельных процесса.

Шаг 1: WHOIS и обратный WHOIS. Классический WHOIS даёт registrant, NS-серверы и даты. Но настоящая ценность - обратный WHOIS: поиск всех доменов, зарегистрированных на ту же организацию или email. SecurityTrails API позволяет сделать это одним HTTP-запросом:

# Прямой WHOIS
whois target.com

# Связанные домены по инфраструктуре (общие NS, MX, IP) через SecurityTrails API
curl "https://api.securitytrails.com/v1/domain/target.com/associated" \
  -H "APIKEY: YOUR_KEY"

# Обратный WHOIS по email/организации - через POST /v1/domains/list
curl -X POST "https://api.securitytrails.com/v1/domains/list" \
  -H "APIKEY: YOUR_KEY" -H "Content-Type: application/json" \
  -d '{"filter":{"whois_email":"admin@target.com"}}'

Результат: список из 5–50 связанных доменов (по общим NS, MX или IP), о которых заказчик может даже не помнить. Для поиска по registrant email/организации используйте endpoint /v1/domains/list с POST-запросом. Однажды через обратный WHOIS я раскопал домен targetname-dev.io, зарегистрированный на тот же email - на нём крутился staging-сервер без аутентификации. Просто подарок.

Шаг 2: DNS-разведка. Перечисление DNS-записей целевого домена и всех найденных связанных доменов:

# A, AAAA, MX, NS, TXT, SOA записи (ANY-запросы deprecated по RFC 8482,
# большинство DNS-серверов возвращают минимальный ответ - запрашиваем по отдельности)
for type in A AAAA MX NS TXT SOA; do dig target.com "$type" +noall +answer; done

# MX - покажет почтовый сервис (Google Workspace, Exchange Online, свой сервер)
dig target.com MX +short

# TXT - часто содержит SPF, DKIM, верификационные токены сервисов
dig target.com TXT +short

# Попытка зонального трансфера (работает редко, но если работает - джекпот)
dig axfr target.com @ns1.target.com

TXT-записи - отдельная золотая жила. Я регулярно нахожу в них верификационные строки Google Workspace, Atlassian, Salesforce, Zoom - по ним видно, какие SaaS-сервисы компания тащит в свой зоопарк.

Шаг 3: Certificate Transparency. Логи CT - публичные базы всех выпущенных SSL-сертификатов. Через них находятся поддомены, которые не видны ни в DNS-брутфорсе, ни в поисковиках:

# Через crt.sh (бесплатный CT-агрегатор)
curl -s "https://crt.sh/?q=%.target.com&output=json" | \
  jq -r '.[].name_value' | sort -u

CT-логи регулярно выдают внутренние имена вроде jira.internal.target.com, vpn-test.target.com, api-staging.target.com. Даже если эти поддомены не резолвятся публично прямо сейчас, они указывают на структуру инфраструктуры и именование. А именование - это паттерн, по которому можно угадывать другие хосты.

Shodan vs Censys: когда и что использовать для пентеста​

Оба инструмента - поисковики по устройствам и сервисам в интернете, но работают по-разному, и это определяет, когда какой запускать.

Shodan индексирует баннеры сервисов: HTTP-заголовки, SSH-версии, баннеры FTP, SNMP community strings. Его сила - поиск по конкретным технологиям и ошибкам конфигурации.

# Все хосты организации по ASN
shodan search "asn:AS12345"

# Все хосты с SSL-сертификатом целевого домена
shodan search "ssl.cert.subject.cn:target.com"

# Устройства с конкретным продуктом (например, забытый Jenkins)
shodan search "http.title:\"Dashboard [Jenkins]\" org:\"Target LLC\""

# Хосты с дефолтными страницами Apache/Nginx
shodan search "http.title:\"Apache2 Ubuntu Default Page\" org:\"Target LLC\""

Censys силён в другом: исторические данные по сертификатам и более глубокий парсинг TLS-хендшейков. Когда мне нужна история - когда сертификат был выпущен, когда изменился, какие SAN содержал полгода назад - я иду в Censys:

# Поиск по имени организации в сертификатах
censys search "services.tls.certificates.leaf.subject.organization:Target"

# Все хосты, обслуживающие сертификат с определённым CN
censys search "services.tls.certificates.leaf.subject.common_name:*.target.com"

На практике разведка инфраструктуры компании строится так: Shodan - для быстрого обнаружения «низко висящих фруктов» (открытые порты управления, дефолтные страницы, устаревшие сервисы). Censys - для глубокого анализа TLS-инфраструктуры и обнаружения связей между доменами через общие сертификаты.

Одна из самых частых находок: через Shodan обнаруживается IP с открытым портом 8443, на котором висит админка, а через Censys видно, что на этом же IP полгода назад был сертификат для admin.target.com - поддомен, который уже не резолвится, но сервис всё ещё работает. Призрак, который никто не отключил.

Сбор информации о людях: от email-адресов до графа социальных связей​

Инфраструктура - половина картины. Вторая половина - люди. Email-адреса сотрудников нужны для моделирования фишинговых атак, имена - для подбора логинов, должности - чтобы понять, кто имеет привилегированный доступ.

theHarvester: быстрый сбор email и поддоменов​

theHarvester входит в Kali Linux и агрегирует данные из поисковых систем, PGP-серверов и API различных сервисов. Запускаю его одним из первых:

# Сбор email, поддоменов, IP из множества источников
theHarvester -d target.com -b all -l 500

# Конкретные источники, которые дают лучшие результаты по email
theHarvester -d target.com -b linkedin,google,bing,crtsh -l 300

Ключевой момент: theHarvester хорошо собирает email-адреса, но для полноты картины его результаты нужно дополнять. Формат корпоративных email (name.surname@, nsurname@, name.s@) определяется по первым трём-четырём найденным адресам, после чего по списку сотрудников из LinkedIn генерируются остальные. Лично у меня эта связка «theHarvester → LinkedIn → генерация» работает безотказно.

LinkedIn как источник OSINT для разведки персонала​

LinkedIn - критически важный источник для Gather Victim Identity Information (T1589, Reconnaissance) и Gather Victim Org Information (T1591, Reconnaissance). Не для «взлома», а для понимания:

• Кто работает в ИТ и ИБ - имена, должности, стаж. Сисадмин, работающий три месяца - совсем не то же самое, что сисадмин с десятилетним стажем на этом месте. У первого в инфраструктуре наверняка валяются чужие скелеты.
• Технологический стек - в профилях и вакансиях фигурируют конкретные технологии: «Опыт с Kubernetes, AWS EKS, Terraform» - значит, инфраструктура в AWS, оркестрация через K8s. Вакансия сама по себе - разведданные.
• Бывшие сотрудники - люди, которые ушли из компании, но их учётки могли не отключить. Или они рассказывают о внутренней инфраструктуре в публичных постах (и такое бывает чаще, чем хотелось бы).

Для автоматизации используется подход с API LinkedIn (в рамках допустимого) или ручной сбор с последующей обработкой. По данным Cobalt.io, анализ публичных профилей в социальных сетях - одна из ключевых техник OSINT: от фотографий бейджей до случайных упоминаний внутренних систем. Люди удивительно щедро делятся тем, чем не стоило бы.

Построение графа связей в Maltego: от домена к точке входа​

Все перечисленные выше инструменты дают разрозненные данные: списки IP-адресов, поддоменов, email-ов, имён. Maltego превращает этот хаос в граф связей - визуальную карту, на которой видны отношения между сущностями.

Практический workflow построения графа​

Мой типичный процесс работы с Maltego на пентесте:

Фаза 1: Seed-сущности. Создаю новый граф, добавляю начальные сущности:

• Domain: target.com
• Company: Target LLC
• Email (если уже известен): admin@target.com

Фаза 2: Расширение через трансформы. Maltego выполняет трансформы - автоматические запросы к различным источникам:

1. Domain → DNS Name (All) - получаю все DNS-записи
2. Domain → To Domains (WHOIS) - связанные домены через WHOIS
3. DNS Name → To IP Address - резолвинг всех найденных поддоменов
4. IP Address → To Netblock - определение сетевых блоков (ASN)
5. Domain → To Email Addresses - сбор email с публичных источников
6. Email → To Person - связь email с конкретными людьми
7. Person → To Social Media Profiles - нахождение профилей этих людей

Фаза 3: Анализ графа. После 2–3 итераций расширения граф начинает показывать паттерны:

• Кластер IP-адресов у одного провайдера - вероятно, основная инфраструктура
• Отдельные IP у другого провайдера - возможно, legacy-системы или проект отдельной команды
• Email, связанный с несколькими доменами - ключевой технический сотрудник
• Поддомен, указывающий на IP в совершенно другом ASN - может быть SaaS-сервис или забытый сервер у предыдущего хостера

В этом и есть ключевое преимущество Maltego перед запуском отдельных утилит: вы видите полную картину, а не набор текстовых списков. Связи, которые в терминале не заметишь, на графе буйком всплывают.

Пример: как граф выявил забытый сервер​

На одном проекте граф в Maltego показал, что поддомен legacy-api.target.com резолвится на IP-адрес, не принадлежащий основному ASN компании. Трансформ по этому IP обнаружил, что на нём же висит ещё один домен - test-target.example-hosting.com. Сервер оказался на дешёвом VPS-хостинге, без обновлений уже два года. Через Shodan на нём нашлись открытые порты 22 (SSH с устаревшим OpenSSH) и 3306 (MySQL, доступный извне). Классика: основной периметр - как форт, а про dev-сервер тупо забыли.

Автоматизация OSINT: Recon-ng, SpiderFoot и amass​

Когда целей много или scope обширный (несколько доменов, десятки ASN), руками не масштабируешься. Здесь вступают инструменты автоматизации.

amass: король перечисления поддоменов​

OWASP Amass - самый зубастый инструмент для обнаружения attack surface. Комбинирует пассивные и активные техники:

# Пассивный режим - без трафика к цели
amass enum -passive -d target.com -o amass_passive.txt

# С использованием API-ключей для расширенного сбора
amass enum -passive -d target.com -config amass_config.ini

# Активный режим (с DNS-резолвингом и брутфорсом)
amass enum -active -d target.com -brute -w /usr/share/wordlists/dns.txt -o amass_active.txt

# Визуализация в виде графа (Amass v3.x; в v4+ подкоманда viz удалена)
amass viz -d3 -d target.com

Файл конфигурации amass_config.ini (в Amass v3.x; в v4+ используется формат YAML) - место, куда вписываются API-ключи от Shodan, Censys, SecurityTrails, VirusTotal, PassiveTotal и десятков других сервисов. С полным набором ключей amass находит в 3–5 раз больше поддоменов, чем без них. Разница колоссальная - без ключей он, считай, работает вполсилы.

Примечание: приведённые примеры используют синтаксис Amass v3.x. В OWASP Amass v4+ архитектура переработана: конфигурация через YAML, изменена структура подкоманд и флагов. Проверяйте актуальный синтаксис в документации.

Recon-ng: фреймворк для структурированного recon​

Recon-ng работает по модели Metasploit: модули, workspace-ы, база данных результатов. Его главное преимущество - все данные сохраняются в единую БД, которую можно запрашивать и экспортировать.

recon-ng
# Создаём workspace для проекта
workspaces create target_pentest

# Загружаем нужные модули
marketplace install recon/domains-hosts/certificate_transparency
marketplace install recon/hosts-hosts/resolve
marketplace install recon/domains-contacts/whois_pocs

# Добавляем начальный домен
db insert domains target.com

# Запускаем модуль CT для поиска поддоменов
modules load recon/domains-hosts/certificate_transparency
run

# Затем резолвим найденные хосты
modules load recon/hosts-hosts/resolve
run

# Экспорт результатов
modules load reporting/html
options set FILENAME /tmp/target_recon.html
run

Recon-ng особенно полезен, когда нужно передать результаты разведки по открытым источникам другому члену команды: workspace содержит всё, включая историю запросов. Удобно, когда работаете парой.

SpiderFoot: автоматизация для ленивых (и умных)​

SpiderFoot автоматизирует более 200 типов запросов из одного интерфейса. Запускается одной командой и методично обходит все доступные источники:

# Запуск веб-интерфейса
spiderfoot -l 127.0.0.1:5001

# Или CLI-режим для конкретного домена
spiderfoot -s target.com -t DOMAIN_NAME -m sfp_dnsresolve,sfp_shodan,sfp_crt

Преимущество SpiderFoot - в корреляции: он автоматически связывает найденные email с аккаунтами в утечках (через Have I Been Pwned API), поддомены с IP-адресами, IP с ASN. По сути, он делает то, что Maltego делает визуально, но в автоматическом пакетном режиме. Натравил на домен, ушёл пить кофе, вернулся - отчёт готов.

Pipeline разведки: как связать инструменты между собой​

Вот где начинается настоящая OSINT автоматизация. Каждый инструмент производит выход, который становится входом следующего. На реальном проекте мой pipeline выглядит так:

Этап 1: amass (пассивный) производит список поддоменов → сохраняю в subdomains.txt

Этап 2: Резолвинг всех поддоменов в IP-адреса:

# Вариант 1: быстрый массовый резолвинг через puredns
puredns resolve subdomains.txt -r resolvers.txt -w resolved.txt

# Вариант 2: через dig с параллелизацией и фильтрацией CNAME
# ВАЖНО: убедитесь, что subdomains.txt содержит только валидные доменные имена
# (без спецсимволов), иначе возможна command injection через sh -c
cat subdomains.txt | xargs -P 50 -I{} sh -c '
  ip=$(dig +short "{}" A | grep "^[0-9]" | head -1)
  [ -n "$ip" ] && echo "{},${ip}"
' > resolved.csv

Этап 3: Уникальные IP проверяю через Shodan API:

cat resolved.csv | cut -d',' -f2 | sort -u | while read ip; do
  shodan host "$ip" 2>/dev/null
done > shodan_results.txt

Этап 4: theHarvester собирает email-адреса параллельно:

theHarvester -d target.com -b all -l 500 -f harvester_output

Этап 5: Все данные импортирую в Maltego для построения Maltego графа связей и визуального анализа.

Этап 6: Результаты фильтрую по приоритету:

• Критический: открытые панели управления (Jenkins, Kibana, phpMyAdmin), устаревшее ПО
• Высокий: email-адреса ИТ-персонала, поддомены с dev/staging/test в имени
• Средний: все остальные поддомены, IP-блоки, технологический стек

Этот pipeline покрывает ключевые техники тактики Reconnaissance из MITRE ATT&CK: T1589, T1590, T1591, T1592, T1593, T1595, T1596 и даёт полную картину attack surface до начала активного тестирования.

От разведки к атаке: как результаты footprinting определяют вектор​

Разведка ради разведки бессмысленна. Каждый найденный артефакт должен превращаться в конкретное действие:

Находка при footprinting	Следующий шаг	Потенциальный результат
Поддомен staging.target.com с Apache 2.4.29	Проверка CVE для этой версии, активное сканирование портов (T1595)	Эксплуатация известной уязвимости
Email формата i.ivanov@target.com + 15 имён из LinkedIn	Генерация полного списка email, проверка через HIBP	Credential stuffing, фишинг
Jenkins на порту 8080 без аутентификации (Shodan)	Проверка доступа к Script Console	RCE через Groovy-скрипт
TXT-запись с _amazonses.target.com	Поиск S3-бакетов по паттерну target-*	Доступ к данным в криво настроенном S3
Сертификат для vpn.target.com в CT-логах	Определение VPN-решения, поиск дефолтных учёток	Доступ к внутренней сети
GitHub-репозиторий сотрудника с упоминанием target	Поиск захардкоженных секретов через git log	API-ключи, токены, пароли

Без фазы разведки я бы сканировал основной домен и упёрся в закрытый WAF. С полной картой attack surface - нашёл забытый staging без WAF, Jenkins без аутентификации и S3-бакет с бэкапами базы данных. Почувствуйте разницу.

Юридические границы пассивного recon​

Пассивная разведка по открытым источникам - это работа с публичными данными. Вы не отправляете пакеты на целевую инфраструктуру, не брутфорсите, не эксплуатируете. Но границы важно понимать чётко:

Допустимо в рамках пентеста (и без договора): запросы к Shodan, Censys, crt.sh, WHOIS-сервисам, поисковым системам. Вы работаете с данными третьих сторон, а не с инфраструктурой цели.

Требует договора: активное сканирование портов (nmap), DNS-брутфорс поддоменов, любое взаимодействие с сервисами цели. Это уже Active Scanning (T1595, Reconnaissance) и Network Service Discovery (T1046, Discovery).

Запрещено всегда: использование найденных паролей из утечек для входа, фишинг сотрудников без согласования, доступ к закрытым системам. Нашли пароль в утечке - фиксируете в отчёте, но не используете. Тут без вариантов.

Чеклист: recon-процесс за один рабочий день​

Для тех, кто хочет внедрить системный подход к разведке - пошаговый чеклист, который укладывается в один рабочий день:

Утро (2 часа) - пассивный сбор:

1. WHOIS + обратный WHOIS через SecurityTrails
2. DNS-перечисление (dig, все типы записей)
3. Certificate Transparency через crt.sh
4. amass в пассивном режиме
5. theHarvester для email-адресов

День (3 часа) - обработка и расширение:

1. Shodan/Censys по найденным IP и организации
2. Анализ LinkedIn: ключевые сотрудники, стек
3. Google Dorks: site:target.com ext:sql | ext:env | ext:log
4. Проверка GitHub/GitLab по имени организации и сотрудников
5. Импорт всего в Maltego, построение графа

Вечер (2 часа) - анализ и приоритизация:

1. Анализ графа связей: изолированные кластеры, аномалии
2. Составление списка целей для активной фазы с приоритетами
3. Формирование карты attack surface для отчёта

По данным Recorded Future, глобальный рынок OSINT-решений оценивался в $5.02 млрд в 2018 году и, по прогнозам, вырастет до $29.19 млрд к 2026 году. За этими цифрами стоит простой факт: объём публично доступных данных растёт экспоненциально, и разведка по открытым источникам - не опциональный навык, а базовое требование к пентестеру.

Инструменты второго эшелона: что дополняет основной арсенал​

Помимо «большой пятёрки» (amass, theHarvester, Shodan, Maltego, Recon-ng) есть инструменты, закрывающие специфические ниши:

• FOCA - вытягивает метаданные из документов (PDF, DOCX, XLSX), найденных на сайте цели. Метаданные содержат имена авторов, пути к файлам на внутренних серверах, версии ПО. Люди не задумываются, сколько информации валяется в свойствах документа.
• BGPView - отслеживание BGP-маршрутов и IP-блоков. Когда нужно определить все сетевые блоки организации, BGPView показывает ASN и анонсируемые префиксы.
• Have I Been Pwned - проверка корпоративного домена на присутствие в утечках. Если сотни email из target.com скомпрометированы - credential stuffing практически гарантирован.
• BuiltWith - определение технологического стека веб-приложения: CMS, аналитика, CDN, платёжные системы. Знание стека сужает область поиска уязвимостей.
• Mitaka - браузерное расширение для быстрых OSINT-запросов: выделил IP или домен, получил ссылки на Shodan, Censys, VirusTotal, AbuseIPDB одним кликом. Мелочь, а экономит кучу времени.
• truffleHog / gitleaks - поиск захардкоженных секретов (API-ключей, токенов, паролей) в публичных Git-репозиториях. В таблице выше упоминается анализ GitHub-репозиториев сотрудников - эти инструменты автоматизируют процесс.
• cloud_enum / S3Scanner - перечисление публичных облачных ресурсов (S3-бакеты, Azure Blob Storage, GCP-бакеты) по паттернам имени организации. Облачная разведка - отдельное большое направление, выходящее за рамки этой статьи.

Каждый из этих инструментов решает узкую задачу, но в связке с основным pipeline они дополняют полноту картины. За рамками статьи остались разведка через paste-сайты и Telegram-каналы утечек, а также глубокая облачная разведка (AzureHound, ScoutSuite) - эти темы заслуживают отдельного разбора.

Разведка - это не этап, это образ мышления​

OSINT пентест - не «шаг 1 перед сканированием». Это непрерывный процесс, который идёт параллельно со всеми остальными фазами. Нашли новый поддомен во время эксплуатации? Возвращайтесь в recon: проверьте его через Shodan, посмотрите сертификаты, добавьте в граф Maltego.

Разница между пентестером, который потратил на разведку 30 минут, и тем, кто работал два дня - это разница между отчётом «мы проверили периметр, всё хорошо» и отчётом «мы нашли забытый сервер двухлетней давности с доступом к продакшен-базе».

Попробуйте прогнать pipeline из этой статьи на своём проекте. Начните с amass + crt.sh + Shodan - для начала хватит за глаза. Если после первого прохода не нашли ничего интересного - значит, scope слишком узкий. Расширяйте через обратный WHOIS и CT-логи. Удачной охоты.