На одном из проектов по оценке внешней атакующей поверхности мне хватило трёх часов, чтобы от забытого staging-поддомена выйти на конкретного разработчика, найти его коммит с хардкоженным API-ключом AWS, а затем обнаружить тот же корпоративный email в двух breach-базах с паролями, которые почти наверняка переиспользовались. Ноль пакетов в сторону целевой сети - только открытые источники. Для blue team вывод простой: если вы не прогоняете OSINT-разведку инфраструктуры компании против самих себя, кто-то уже делает это за вас.
Бизнес-логика атаки: зачем разведка до первого эксплойта
Перед запуском эксплойта или фишинговой кампании атакующий собирает максимум данных из открытых источников - фаза Reconnaissance в терминологии MITRE ATT&CK. Техника Gather Victim Network Information (T1590) и её подтехники - Domain Properties (T1590.001), DNS (T1590.002), IP Addresses (T1590.005) - описывают то, что происходит до первого активного контакта с целью. Подробнее - в нашем руководстве по osint для специалиста по информационной безопасности.По данным Mandiant M-Trends 2025, в 2024 году отслеживаются 4+ новых APT-группировок, финансовый сектор входит в тройку наиболее атакуемых отраслей. Чтобы эксплуатировать уязвимость, нужно знать, какой софт запущен, на какой версии и на каком хосте. Для фишинга - кому отправить письмо, на какой адрес, с какой легендой. Всё это даёт разведка на основе открытых источников.
Конечная цель - получить одно из трёх: прямой доступ через утёкший секрет (API-ключ, пароль), точку входа через уязвимый сервис на забытом хосте, или убедительный вектор социальной инженерии через данные конкретного сотрудника. Чаще - комбинацию всех трёх.
Дальше - четыре фазы, которые я прохожу на каждом проекте. Та же последовательность работает и в обратную сторону: если вы в blue team, пройдите каждую фазу против собственного домена и посмотрите, что увидит атакующий.
Фаза 1: footprinting инфраструктуры - от домена до забытого сервера
Поиск сабдоменов через Certificate Transparency и DNS
Каждый TLS-сертификат, выданный публичным CA, попадает в Certificate Transparency (CT) логи. Это значит, что staging.company.ru, dev-api.company.ru и jira.internal.company.ru - все они видны в открытом доступе, даже если DNS-запись ведёт на внутренний IP. В терминах ATT&CK - техника Domain Properties (T1590.001, Reconnaissance).Самый быстрый способ проверить - запрос к crt.sh по корневому домену. Для автоматизации -
subfinder, который агрегирует CT-логи, поисковые движки и пассивные DNS-базы в один прогон:
Bash:
subfinder -d company.ru -o subdomains.txt
cat subdomains.txt | httpx -sc -title -td-sc -title -td - для httpx v1.3+; в более ранних версиях используйте -status-code -title -tech-detect.) Важный момент: httpx уже отправляет HTTP-запросы к хостам - это активное взаимодействие. Для defensive recon против собственной инфраструктуры - допустимо, для стороннего домена без авторизации - нет.Дополнительный вектор - Google dorking: запрос
site:company.ru -www покажет проиндексированные поддомены за пределами основного сайта. Фильтры inurl:admin или intitle:login выявляют административные интерфейсы, которые не должны быть в публичном индексе.Предусловия и ограничения:
- CT-логи не покрывают самоподписанные сертификаты. Wildcard-сертификаты (*.company.ru) не раскроют конкретные имена хостов
- DNS-брутфорс даёт результаты только для словарных имён поддоменов (dev, staging, api, test, admin)
- Забытый поддомен с dangling CNAME - CNAME указывает на деаллоцированный ресурс в облаке - это не просто находка, а потенциальный subdomain takeover. Если staging.company.ru имеет CNAME на yourapp.herokuapp.com, а Heroku-приложение удалено, атакующий может занять это имя и подставить свой контент под вашим доменом
Shodan и Censys: пассивный анализ без пакетов к цели
Shodan и Censys непрерывно сканируют весь IPv4-диапазон и индексируют баннеры сервисов. Запрос к ним - чтение уже собранных данных, ни один пакет не уходит к цели. В ATT&CK это техники IP Addresses (T1590.005) и DNS (T1590.002).Запрос, который покажет все хосты с TLS-сертификатом для конкретного домена на нестандартных портах:
Код:
ssl.cert.subject.cn:"company.ru" port:443,8443org:"Company Name" port:22,3389 - SSH и RDP, торчащие наружу. MySQL (3306) или PostgreSQL (5432) на публичном IP - критическая находка для немедленного закрытия.Когда техника НЕ работает:
- Инфраструктура полностью за CDN (Cloudflare, Akamai) - реальные IP скрыты, Shodan покажет только CDN-фронт
- Бесплатный аккаунт Shodan ограничен 100 результатами - для крупных организаций нужен платный доступ или Censys
- Данные обновляются с задержкой от дней до недель - свежеразвёрнутый сервер может не появиться сразу
Фаза 2: email harvesting и профилирование персонала OSINT
Паттерны email и инструменты сбора данных о сотрудниках компании
Когда собран список поддоменов и есть базовое понимание инфраструктуры, следующий шаг - email-адреса сотрудников. В ATT&CK - техники Email Addresses (T1589.002, Reconnaissance) и Employee Names (T1589.003).Знание формата email (first.last@company.ru, flast@company.ru, first_last@company.ru) позволяет сгенерировать адрес любого сотрудника, чьё имя найдено в открытых источниках. Дальше - credential stuffing, фишинг или проверка по breach-базам.
theHarvester агрегирует email из поисковых систем и публичных API одной командой: theHarvester -d company.ru -b all (без настроенных API-ключей в api-keys.yaml данные вернутся только с бесключевых источников - Google, Bing, DuckDuckGo, crt.sh). Hunter.io определяет формат email для домена и возвращает верифицированные адреса.Ограничения: theHarvester для полных результатов требует API-ключи (Google CSE, Bing API, Shodan API). Hunter.io бесплатно даёт 25 запросов в месяц - хватит для разовой проверки, но не для мониторинга. Если компания использует catch-all почтовый сервер, SMTP-верификация не даст надёжного результата - все адреса будут выглядеть валидными.
Вакансии и LinkedIn как источник HUMINT
LinkedIn - открытая база оргструктуры. В ATT&CK - техники Identify Roles (T1591.004) и Social Media (T1593.001). Из профилей атакующий вытаскивает полные имена, должности, иерархию подчинения, стек технологий и историю работы.Но вакансии - ещё более ценный и часто недооцениваемый источник. Из практики OSINT-разведки: вакансия вроде "Senior Okta Engineer с опытом миграции с Cisco AnyConnect на Zscaler ZPA" раскрывает провайдера SSO, текущий VPN-вендор, будущую zero-trust платформу и факт незавершённости миграции. Вакансия "DevOps, Kubernetes, Terraform, AWS, HashiCorp Vault" сообщает: контейнерная оркестрация, облако AWS, управление секретами в процессе - до завершения миграции секреты хранятся где-то ещё. Люди сами рассказывают, как к ним зайти.
Google dorking для LinkedIn:
site:linkedin.com/in "Company Name" "security engineer" - способ найти ключевых сотрудников без автоматизированного скрапинга (который нарушает Terms of Service LinkedIn).Когда техника НЕ работает: часть сотрудников ставит приватный режим, часть не ведёт профиль. Вакансии иногда содержат wishlist вместо реального стека - это шум, требующий фильтрации. Для российских компаний LinkedIn менее информативен, чем для западных, но hh.ru и Хабр Карьера частично компенсируют этот gap.
Фаза 3: поиск утечек кода на GitHub
Разработчики регулярно коммитят чувствительные данные в публичные репозитории - API-ключи, пароли от баз данных, приватные ключи, внутренние URL. На практике GitHub dorking часто оказывается финальной точкой инфраструктурного recon: утёкший секрет даёт прямой доступ без необходимости искать эксплойт.
Примеры поисковых запросов:
Код:
org:companyname password
org:companyname "api_key"
org:companyname filename:.env
"company.ru" filename:config extension:ymltrufflehog (сканирует git-историю на высокоэнтропийные строки и известные паттерны секретов) и gitleaks (проверяет по конфигурируемым правилам).Критический момент: удалённый секрет остаётся в git-истории. Разработчик закоммитил AWS-ключ, потом удалил следующим коммитом - ключ доступен через
git log и git show. Репозиторий нужно перезаписывать через git filter-repo, и на практике это делают единицы. Я за последние пару лет видел может десяток проектов, где после утечки реально почистили историю, а не просто "удалили файлик".Предусловия: GitHub dorking работает только по публичным репозиториям. Если организация не ведёт публичных репозиториев - вектор формально закрыт, но личные аккаунты сотрудников (найденные в Фазе 2) могут содержать форки рабочих проектов.
trufflehog генерирует false positives на тестовых данных - ручная верификация обязательна.Фаза 4: анализ breach data сотрудников
Когда есть список email из Фазы 2, следующий шаг - проверка по базам утечек. Have I Been Pwned (HIBP) позволяет проверить домен целиком: сколько корпоративных email попали в известные утечки и из каких источников.
Масштаб проблемы: утечка LinkedIn 2012 года, ставшая публичной в 2016, затронула 164 611 595 записей с email-адресами и паролями (по данным HIBP). Combo-лист Exploit.In (2016) содержал 593 427 119 уникальных email-адресов, многие - с несколькими разными паролями, из множества различных источников. Когда сотрудник использует корпоративный email для регистрации на сторонних сервисах и переиспользует пароль - это прямой вектор initial access через credential stuffing.
Что проверять: HIBP Domain Search показывает, сколько корпоративных email попали в какие утечки. Корреляция с инфраструктурой из Фазы 1: если VPN-портал компании принимает email+пароль без MFA, а email из Фазы 2 найден в breach-базе с паролем - вектор готов. Утёкшие данные также появляются на paste-сайтах и в Telegram-каналах раньше, чем попадают в HIBP.
Ограничения: HIBP бесплатный поиск по домену требует верификации ownership - для мониторинга нужен доступ к DNS или email домена. Breach data устаревает: пароль из утечки 2012 года мог быть сменён. Но паттерн генерации (любимое слово + год) часто сохраняется, и атакующий строит wordlist на основе утёкшего пароля. Видел это не раз: пароль из утечки -
Sergey2012, текущий - Sergey2024. Угадайте с одной попытки.Корреляция: как четыре фазы складываются в initial access
Каждая фаза по отдельности - набор сырых данных. Ценность появляется при корреляции. Реалистичный сценарий из практики (анонимизированный):Итог: три потенциальных вектора initial access - Jenkins без MFA (credential stuffing), утёкший AWS-ключ (если не ротирован), учётные данные из breach-базы для VPN. Всё обнаружено без единого активного сканирования целевой инфраструктуры.
По данным IBM X-Force Threat Intelligence Index 2025, 70% атак, обработанных IBM X-Force, затронули организации критической инфраструктуры, а генерация фишинговых писем с помощью GenAI стала быстрее в 11,4 раза при сопоставимом качестве. Имея данные всех четырёх фаз, атакующий создаёт убедительное письмо конкретному сотруднику с упоминанием реальных проектов и коллег - GenAI ускоряет этот процесс многократно.
Деанонимизация атакующей поверхности: чеклист для blue team
Разовый аудит бесполезен, если атакующая поверхность меняется каждую неделю. Еженедельный минимум:| Задача | Инструмент | Что ищем |
|---|---|---|
| Мониторинг CT-логов | crt.sh / Certstream | Новые сертификаты = новые поддомены (shadow IT, забытые dev-среды) |
| Сканирование секретов | GitHub Advanced Security / gitleaks | Коммиты с API-ключами, токенами, .env |
| Оповещения Shodan | Shodan Alerts (по IP/org) | Новые открытые порты и сервисы на вашем периметре |
| Мониторинг утечек | HIBP Domain Notify | Корпоративные email в новых breach-базах |
| Проверка dangling DNS | Периодический DNS-аудит | CNAME-записи, указывающие на деаллоцированные ресурсы |
Требования к окружению для defensive recon
- ОС: любая с Python 3.8+ (subfinder, theHarvester, trufflehog - кроссплатформенные)
- API-ключи: Shodan (бесплатно, лимит 100 результатов/запрос), Hunter.io (25 запросов/мес бесплатно), VirusTotal (опционально для обогащения)
- Доступ: DNS ownership или admin email для HIBP Domain Search; доступ к GitHub организации для gitleaks; Shodan Alerts - бесплатно до 16 IP-мониторов
Ограничения OSINT-мониторинга
Мониторинг открытых источников закрывает внешнюю видимость, но не заменяет:- Внутренний аудит конфигурации - OSINT не покажет ACL на внутренних ресурсах и ошибки в IAM-политиках
- Активный пентест - пассивная разведка выявляет потенциальные векторы, но не подтверждает эксплуатабельность
- DLP-контроль - утечки в приватных каналах (корпоративный Slack, закрытые чаты) невидимы для внешнего OSINT
Нередко OSINT-проверку запускают раз в год - во время планового пентеста. К этому моменту staging-поддомен с дефолтными кредами висит в интернете девять месяцев, а коммит с AWS-ключом - полгода. Проблема не в инструментах: subfinder, Shodan, HIBP Domain Search - всё бесплатно или условно бесплатно. Проблема в операционной дисциплине. Я видел компании с SOC на 15 человек и годовым бюджетом на threat intelligence, где ни один аналитик не прогонял
subfinder -d company.ru за последние полгода - зато часы уходили на разбор внутренних SIEM-алертов, пока внешняя поверхность обрастала забытыми CNAME и светящимися в breach-базах email-адресами. По данным CrowdStrike Global Threat Report 2025, вредоносное использование GenAI для социальной инженерии удвоилось за 2024 год - каждая единица данных в открытом доступе делает такие атаки точнее. Инфраструктурный recon занимает 30 минут в неделю при настроенных алертах. Это дешевле одного инцидента. Если у вас другой стек детекции - на форуме codeby.net обсуждаем, как адаптировать подобный мониторинг под разные инфраструктуры.
Последнее редактирование модератором:
