Зачем багхантеру навык сетевой разведки?

Багхантер — это специалист по поиску уязвимостей в цифровых системах. Его задача — находить технические дыры, которые можно эксплуатировать, и сообщать о них владельцам систем до того, как это сделает кто-то другой. За это платят в рамках bug bounty программ или частных договоров. Чем лучше багхантер собирает информацию о цели, тем быстрее он находит точку входа. Не знаешь, какие сервисы у компании есть — не найдёшь ни ошибку, ни баг. А вот если у вас в арсенале OSINT? разведка по открытым источникам? ты получаешь преимущество.

OSINT — это поиск и анализ информации из публичных источников: сайтов, форумов, соцсетей, локальных реестров, даже кешей поисковых систем. Продвинутая разведка по открытым источникам — не просто сбор адресов сайтов. Это системная работа: сначала анализ инфраструктуры, потом поиск уязвимых точек, далее следует уточнение, что из этого реально можно использовать в атаке.

Инструменты OSINT позволяют багхантеру:

Простой пример: багхантер запускает скан поддоменов, находит dev.oldcorp.com, на нём Jenkins без авторизации. Далее он через консоль выполняет команду, получает реверс-шелл. Всё это началось с OSINT.

Давайте разберем каждый из методов OSINT по частям и на реальных кейсах: от Google Dorks до анализа утечек.

Первый шаг — понять, что у цели есть в интернете, то есть какие домены она контролирует, какие технологии использует, какие сервисы работают в онлайне. Всё это можно собрать, не трогая ни один сервер напрямую. Например, багхантер использует Amass, чтобы собрать все поддомены компании, и среди них находит домен третьего уровня vpn.oldcorp.com. Через Shodan он узнаёт, что сервер использует устаревший OpenVPN. Через nmap он видит, что порт 943 открыт. Это значит, что можно дстучаться до веб-интерфейса админки с версией. По CVE таким образом у нас найден RCE-эксплойт, а значит, OSINT дал не просто карту инфраструктуры, а конкретную цель, эксплуатируемую без лишнего шума.

Разработчики часто сами выкладывают ключи, конфиги и пароли в открытых репозиториях. Обычно это происходит случайно или по незнанию. Всё это становится частью открытого интернета, если попадает в индекс поисковика, репозиторий или облачное хранилище без доступа. Например, багхантер может использовать Google Dork site:github.com "aws_access_key_id" "oldcorp" — и найти коммит, в котором инженер загрузил .env с AWS-ключами. Проверка показала, что ключ активен. Через AWS CLI багхантер получает список бакетов, один из них может быть открытым и содежать, дампы внутренних баз. Что можно было сделать с помощью этой информации? Если бы доступ был реальный — это критическая уязвимость с серьезными последствиями.

Инструменты и подходы:

Слитый пароль — это не просто строчка из базы, это потенциальный вход во внутренние системы. У многих компаний корпоративные емейлы, которые уже всплывали в старых утечках и до сих пор работают. Если не внедрена двухфакторка, а пароли не менялись годами, то атака становится тривиальной.

Например, багхантер проверяет домен компании через Have I Been Pwned и видит несколько совпадений по емейлам. Один из них — buildbot@target.com. Через DeHashed и Scylla.sh он находит старый пароль. Затем заходит по этим данным в Jenkins-инстанс, доступный по адресу ci.target.com. Jenkins вполне может быть настроен без SSO, и авторизация пройдет успешно. Таким обзоаром можно получить доступ к пайплайнам, переменным окружения, токенам.

Другой реально произошедший кейс — утечка токенов Slack. В 2023 году один разработчик случайно закоммитил .env с SLACK_API_TOKEN в публичный GitHub-репозиторий. Репозиторий был удалён через сутки, но токен остался активен. Багхантер использовал архив GitHub через wayback machine, вытащил .env, получил токен, расшифровал workspace, а затем нашел список участников и сообщения внутренних каналов. Среди них было обсуждение production-инцидента и ключ к staging-окружению.

Также в 2024 году произошла утечка базы данных с форума Exploit.in, которая снова актуализировала уязвимость через старые корпоративные емейлы. Один из багхантеров нашел логин и пароль сотрудника IT-отдела в этой базе. Попробовав авторизацию на GitLab компании, он получил доступ. Выгрузка проектов показыла, что в одном из репозиториев есть deploy.sh с сохранённым приватным SSH-ключом. Ключ был активен, и с помощью него удалось подключиться к staging-серверу.

Это важный урок о том, что нельзя игнорировать старые утечки. То, что слилось в 2016, может работать в 2025, если процессы контроля и ротации отсутствуют. Багхантер, который следит за утечками, имеет фору в несколько шагов до любой проверки сканерами.

К сожалению, корпоративные ошибки повторяются, особенно в рамках одной отрасли — fintech, edtech, SaaS и т.д. Анализируя уязвимости конкурентов, багхантер может получить карту типичных багов, архитектурных просчётов и плохих практик.

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

Другой случай: изучение поддоменов конкурентов через Shodan. Багхантер замечает, что у одного из конкурентов вендор развернул систему мониторинга на публичном IP без авторизации. Он проверяет ту же схему у цели и находит grafana.oldcorp.com, доступный без логина. Дальше он получает визуализацию запросов к backend’у, схемы баз данных и API-ключи.

Надо понимать, что инструмент сам по себе — это просто программа, имеющая только теоритетическую полезность. Эффект даёт только правильная цепочка: цель → предположение → инструмент → результат → атака.

Это инструмент визуального анализа, который запускается для обогащения и уточнения связей между доменами, IP, email, компаниями и любыми другими сущностями. Например, вводим example.com, строим граф и находим связанные email-адреса, один из которых засвечен в Have I Been Pwned. Дальше логично провести проверку пароля для попытки входа во внутренние панели.

Maltego полезен при расследовании и картировании связанных структур. Особенно если цель дробится на много юрлиц или инфраструктура размазана по подрядчикам.

Это поисковик по инфраструктуре. В практической реализации он может выглядеть так: запрашиваем org:"OldCorp" port:9200, видим, что у компании открыт Elasticsearch без авторизации. Дальше осуществялем переход по IP, curl-запрос и видим данные. Можно репортить критическую уязвимость.

Также Shodan может использоваться для поиска open Jenkins, GitLab, Prometheus, Zabbix и других сервисов с известными уязвимостями. Кроме этого можно осуществить поиск по сигнатурам: product:Jenkins, http.title:"GitLab".

Это элементарный инструмент уточнения поисковых запросов. Скажем. запрос site:corp.com filetype:env может выдать .env с продовыми ключами. А intitle:"index of" admin может подсветить папку с дампами. Несморя на простоту это достаточно эффективный инструмент: такие файлы администраторы всё ещё загружают в корень сайта или забывают закрыть индексацию.

Однако эта схема не работает по свежим файлам. Вам стоит рассчитывать только на то, что уже попало в индекс. При этом Google Dorks лучше комбинировать с waybackurls и filesystem search.

Поиск в репозиториях может быть крайне полезен. Когда мы запрашиваем org:corp "api_key", можем найти закоммиченный config.js с ключом к Stripe. Через git clone и gitleaks detect можно автоматизировать поиск на уровне всего GitHub или конкретных реп. Это полезно как в фазе разведки, так и для мониторинга собственных утечек, если вы на стороне компании.

OSINT — не хакинг, но его последствия могут быть сопоставимы. Всё зависит от того, куда вы полезли и с какой целью. Линия проходит там, где заканчивается публичность и начинается несанкционированный доступ.

Что допустимо:

Что требует разрешения:

Пример: вы нашли открытый Jenkins. Если вы просто зашли в интерфейс — это OSINT. Если запустили билд — это уже активное воздействие. Без разрешения — уголовная статья.

Таким образом OSINT — это не просто этап разведки, а фундамент успешного багхантинга. Каждый найденный поддомен, утекший пароль или забытый API — это потенциальная дверь в систему. Багхантер без OSINT как искатель сокровищ без карты. Он может копать наугад, но настоящие находки ждут тех, кто умеет анализировать, сопоставлять и находить слабые места ещё до первой атаки.