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

Технический OSINT — это не просто набор инструментов и методик, а практическая дисциплина, которая применяется в реальных сценариях: от оценки безопасности собственной инфраструктуры до разведки конкурентов и расследования инцидентов. Теория без практики мертва. В этой заключительной статье цикла мы разберем несколько реальных кейсов (обезличенных и агрегированных) из практики технической разведки. Каждый кейс демонстрирует применение методов и инструментов, описанных в предыдущих статьях, и показывает, как пассивный сбор данных может привести к обнаружению критических уязвимостей, забытых активов и инсайтов о стратегии организации.

КЕЙС 1: РАЗВЕДКА ПЕРЕД ПЕНТЕСТОМ (ПЛАНОВАЯ ОЦЕНКА ИНФРАСТРУКТУРЫ)

Исходные данные: Компания «Альфа» (вымышленное название) заказала внешний пентест своего интернет-периметра. У команды пентеста есть только домен alpha.com и разрешение на активное сканирование. Однако перед любыми активными действиями они проводят пассивную разведку, чтобы не пропустить сервисы, которые не сканируются стандартными средствами, и чтобы правильно спланировать нагрузку.

Ход работы:

WHOIS-анализ: alpha.com зарегистрирован 15 лет назад, регистратор — Namecheap. Контакты скрыты PrivacyGuard. DNS-серверы: ns1.alpha.com, ns2.alpha.com. Это указывает на то, что компания использует собственные DNS-серверы, а значит, возможно, имеет внутреннюю инфраструктуру.
DNS-разведка (dig):

A → 192.0.2.10 (основной веб-сервер).
MX → mail.alpha.com (приоритет 10), резервный mx.backup.net (приоритет 20).
TXT → v=spf1 include:spf.protection.outlook.com -all → используется Office 365.
NS → ns1.alpha.com, ns2.alpha.com.

Поиск поддоменов (crt.sh + SecurityTrails): Найдено 45 поддоменов, в том числе:

www.alpha.com (основной сайт).
mail.alpha.com (почтовый сервер).
remote.alpha.com (удалённый доступ, предположительно VPN).
jenkins.alpha.com (система CI/CD).
dev.alpha.com (тестовый поддомен).
old.alpha.com (старый сайт).

Анализ SSL-сертификатов: На jenkins.alpha.com сертификат выдан Let's Encrypt, истекает через 10 дней. Это указывает на то, что сервис жив и активно используется (сертификат обновляется). На old.alpha.com сертификат истёк год назад — возможно, сервис уже неактивен, но всё ещё доступен по IP.
Shodan/Censys по IP-адресам поддоменов:

192.0.2.10 (основной сайт) → порты 80, 443. Сканирование баннеров показало Nginx 1.18.0, PHP 7.4.33.
198.51.100.22 (jenkins.alpha.com) → порт 8080 открыт, Jenkins 2.289.1 (уязвимая версия, подверженная CVE-2023-23897).
203.0.113.45 (mail.alpha.com) → порты 25, 587, 993 (SMTP, SMTP over TLS, IMAPS).
198.51.100.88 (remote.alpha.com) → порт 443 с сертификатом, но баннер похож на OpenVPN или SSL-прокси.
192.0.2.50 (dev.alpha.com) → порт 22 (SSH), 80, 443. Баннер SSH: OpenSSH 7.9 (устаревший).

WHOIS по IP: Все IP-адреса принадлежат ALPHA-AS (AS12345), зарегистрированному в RIPE. Это означает, что компания использует собственные IP-адреса и не полагается на облачных провайдеров для этих сервисов.
Технологический стек (Wappalyzer): Основной сайт на Drupal 9.5.3 (уязвимый, CVE-2023-XXXX). Используется jQuery 3.6.0, Bootstrap 4.6. Google Analytics ID UA-123456-1.
GitHub-поиск: Организация alpha-org имеет несколько публичных репозиториев. Один из них — alpha-backend — содержит файл .env.example с реальными паролями (не были заменены на заглушки). В коде встречается строка DB_PASSWORD=AlphaDb2023.

Итог кейса:

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

КЕЙС 2: ОБНАРУЖЕНИЕ ЗАБЫТОГО СЕРВИСА (JENKINS С УЯЗВИМОСТЬЮ)

Исходные данные: Сотрудник отдела безопасности компании «Бета» проводит аудит собственной инфраструктуры. Он подозревает, что в сети есть забытые сервисы, которые не отслеживаются централизованно. В компании используется домен beta.ru.

Ход работы:

Поиск поддоменов через crt.sh:
Запрос %.beta.ru выдает 120 сертификатов. Среди них есть ci.beta.ru, который не фигурирует во внутренних документах.
Проверка доступности (DNS):
ci.beta.ru резолвится в 192.168.1.100 (внутренний IP, но компания использует NAT, и этот IP доступен из интернета через публичный адрес). Это явно внутренний сервер, который был случайно опубликован во внешний DNS.
Shodan-поиск по IP (публичному адресу):
Порт 8080 открыт, баннер: Jenkins 2.263. Версия Jenkins 2.263 уязвима к CVE-2022-12345 (удалённое выполнение кода через панель управления).
Поиск в истории DNS: SecurityTrails показывает, что ci.beta.ru появился 3 года назад и с тех пор не менял IP. Это подтверждает, что сервис был создан для проекта, который давно завершён, но не выведен из эксплуатации.
Проверка сертификата: Сертификат для ci.beta.ru выдан Let's Encrypt и истекает через 45 дней. Это значит, что сервис всё ещё обслуживается (автоматическое обновление сертификатов), но никто не помнит, зачем он нужен.
Анализ заголовков: HTTP-заголовки показывают X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, что хорошо, но отсутствует CSP. Сам Jenkins доступен без аутентификации (что подтверждается при открытии страницы в браузере — панель администрирования видна).

Итог кейса:

Обнаружен забытый Jenkins-сервер, доступный из интернета с открытой панелью управления.
Версия Jenkins имеет критическую уязвимость, которая позволяет выполнить произвольные команды на сервере.
Компания «Бета» немедленно закрыла доступ к сервису, ограничив его внутренней сетью, и инициировала процедуру вывода из эксплуатации.
Это предотвратило возможную компрометацию всей инфраструктуры через данный сервер.

Вывод: Даже если вы не проводите активное сканирование, пассивный OSINT (crt.sh, Shodan) может выявить забытые сервисы, о которых не знает даже служба безопасности.

КЕЙС 3: РАССЛЕДОВАНИЕ УТЕЧКИ ДАННЫХ ЧЕРЕЗ GITHUB

Исходные данные: В СМИ появилась новость, что компания «Гамма» (домен gamma.tech) пострадала от утечки данных клиентов. Отдел безопасности должен выяснить, как произошла утечка и какие данные скомпрометированы.

Ход работы:

Поиск упоминаний компании в GitHub:
Использование GitHub Code Search с операторами: "gamma.tech" password, "gamma.tech" api_key, "gamma.tech" secret, "gamma.tech" token. Найдено 15 файлов, содержащих упоминания домена.
Анализ найденных файлов:

В репозитории gamma-public есть файл config/database.yml, содержащий строку: password: GammaDB2023!. Этот репозиторий был публичным.
В другом репозитории gamma-util в файле creds.py найден AWS-ключ: aws_access_key_id = "AKIAXXXXXXXXXXXXXXXX", aws_secret_access_key = "abcdefghijklmnopqrstuvwxyz1234567890". Ключ действителен.

Проверка активности ключей:

Подключение к AWS CLI с найденным ключом (в безопасной изолированной среде) показывает, что ключ имеет права на чтение S3-бакетов, включая бакет gamma-customer-data.
Список файлов в бакете содержит дампы баз данных с именами клиентов, email-адресами, телефонными номерами и даже хэшированными паролями (но слабый алгоритм хеширования).

Поиск других утечек:

Использование Dehashed и Leak-Lookup по email-адресам сотрудников показывает, что несколько сотрудников использовали корпоративные email для регистрации на сторонних сервисах, пароли от которых были скомпрометированы.
Это позволило злоумышленникам получить доступ к внутренним репозиториям и опубликовать их.

Восстановление цепочки:

Один из разработчиков случайно закоммитил файл с паролями в публичный репозиторий.
Злоумышленник нашёл этот файл через поиск по gamma.tech.
Используя пароль, получил доступ к базе данных и скачал её.
Также использовал AWS-ключ для доступа к S3-бакетам.

Итог кейса:

Причина утечки — человеческая ошибка (публикация секретов в открытом репозитории).
Скомпрометированы данные более 50 000 клиентов.
Компания «Гамма» немедленно:

Отозвала все скомпрометированные ключи и пароли.
Удалила публичные репозитории с секретами.
Внедрила политику автоматического сканирования всех публичных репозиториев на наличие секретов с помощью TruffleHog.
Уведомила регулятора и клиентов об утечке (в соответствии с GDPR).

Вывод: Поиск по открытым репозиториям — обязательный элемент мониторинга безопасности. Даже одна публичная строка с паролем может привести к катастрофической утечке.

КЕЙС 4: МОНИТОРИНГ КОНКУРЕНТА (ОБНАРУЖЕНИЕ НОВОГО ПРОДУКТА)

Исходные данные: Компания «Дельта» хочет узнать о планах своего конкурента «Эпсилон» по запуску нового сервиса. Конкурент использует домен epsilon.io.

Ход работы:

Настройка мониторинга:

CertSpotter добавлен на домен epsilon.io и *.epsilon.io.
Ежедневный скрипт проверяет crt.sh на новые сертификаты для epsilon.io.
Changedetection.io отслеживает главную страницу epsilon.io и страницу /careers (появление новых вакансий).

Обнаружение через 2 недели:

CertSpotter отправляет уведомление: новый сертификат для api.epsilon.io.
Сертификат выдан Let's Encrypt, в SAN указаны api.epsilon.io и *.api.epsilon.io.

Разведка нового поддомена:

api.epsilon.io разрешается в IP 52.0.0.123.
WHOIS показывает, что IP принадлежит AWS (AS14618).
Порт 443 открыт, баннер HTTP содержит заголовок Server: AmazonS3. Это указывает на статический сайт, размещённый в S3.
Порт 80 тоже открыт, редиректит на 443.
Открыт также порт 3000, на котором виден заголовок X-Powered-By: Express. Это указывает на Node.js-приложение.
Shodan показывает, что порт 3000 доступен, но баннер содержит ошибку 404.

Анализ контента:

Страница https://api.epsilon.io содержит Swagger-документацию (openapi.json). В ней перечислены эндпоинты для управления заказами, пользователями и платежами.
Это явно новый API-сервис, который ещё не анонсирован.

Связь с вакансиями:

На странице /careers появилась вакансия «Senior Node.js Developer» для работы над «новым облачным продуктом».
Это подтверждает, что компания запускает новый B2B-сервис.

Итог кейса:

Компания «Дельта» узнала о запуске нового продукта конкурента за месяц до официального анонса.
Изучив Swagger-документацию, они смогли оценить функционал и скорректировать свою стратегию.
Информация была передана в стратегический отдел для анализа рынка.

Вывод: Мониторинг новых сертификатов и поддоменов позволяет выявлять неанонсированные проекты и получать рыночное преимущество.

КЕЙС 5: ПОИСК СКРЫТЫХ ПОДДОМЕНОВ ЧЕРЕЗ CT-ЛОГИ И WAYBACK MACHINE

Исходные данные: Исследователь безопасности ищет все возможные поддомены компании zeta.space для составления карты инфраструктуры. В DNS и CT-логах есть поддомены www, mail, vpn. Но он подозревает, что есть ещё забытые.

Ход работы:

crt.sh (стандартный запрос): %.zeta.space даёт 25 результатов, включая те, что уже известны.
Wayback Machine CDX API:bashcurl "https://web.archive.org/cdx/search/cdx?url=zeta.space/*&output=json&limit=100000" > all_pages.jsonВ полученном списке страниц исследователь находит упоминания URL staging.zeta.space, dev.zeta.space, test.zeta.space, которые отсутствуют в CT-логах.
Проверка доступности:

staging.zeta.space резолвится в 203.0.113.77.
Порт 80 открыт, на нём видна тестовая страница с ошибкой PHP.
Порт 443 закрыт (сертификата нет).

Анализ контента на Wayback Machine:

Сохранённая копия staging.zeta.space от 2 лет назад содержит полную структуру каталогов: /admin, /backup, /old. В папке /backup лежит файл db_backup_2022.sql.

Поиск по файлу в Wayback Machine:

Исследователь скачивает db_backup_2022.sql (через архивную ссылку) и находит в нём email-адреса сотрудников, включая адреса IT-отдела.

Использование email для дальнейшей разведки:

Через утечки (Dehashed) находится, что один из email использовался на форумах, где пароль был скомпрометирован.

Итог кейса:

Обнаружены забытые поддомены (staging, dev, test), которые всё ещё доступны и содержат уязвимые версии ПО.
Найден дамп базы данных, который может содержать конфиденциальную информацию.
Получены email-адреса для дальнейшей социальной инженерии или проверки утечек.

Вывод: Wayback Machine — мощный инструмент для обнаружения поддоменов, которые уже не существуют в DNS или CT-логах, но всё ещё могут быть доступны по IP или содержать следы в архивах.

КЕЙС 6: КОМПЛЕКСНОЕ РАССЛЕДОВАНИЕ (ПОЛНАЯ КАРТИНА ЗА 1 ЧАС)

Исходные данные: Аналитик получает задачу: «Что мы знаем о компании omega.tech?» У него есть только домен.

Ход работы (пошагово, с таймингами):

WHOIS (2 мин): omega.tech зарегистрирован через GoDaddy, дата создания 2015-03-10, NS: ns1.omega.tech, контакты скрыты.
DNS (3 мин):

A → 54.0.0.10.
MX → mail.omega.tech (приоритет 10), mx2.omega.tech (20).
TXT → v=spf1 include:_spf.google.com ~all (использует Google Workspace).

Поддомены (crt.sh + SecurityTrails) (5 мин):

Найдено 30 поддоменов, включая jenkins, gitlab, monitoring, dev.

Анализ IP и ASN (5 мин):

54.0.0.10 принадлежит AWS (AS14618), регион us-east-1.
Другие IP поддоменов принадлежат тому же AWS-аккаунту (определено по схожести IP-диапазонов).

Shodan/Censys по IP (5 мин):

На 54.0.0.10: порты 80, 443 (Nginx 1.20.0, PHP 8.0).
На 54.0.0.22 (jenkins): порт 8080 (Jenkins 2.303, уязвимый).
На 54.0.0.33 (gitlab): порты 80, 443 (GitLab 14.5).

SSL-сертификаты (3 мин):

Все сертификаты выданы Let's Encrypt, истекают через 20 дней. Это указывает на единую политику управления.

Технологический стек (3 мин):

Wappalyzer: основной сайт на WordPress 5.9 с плагинами: WooCommerce, Yoast SEO, WP Rocket. Тема — OceanWP.

GitHub-поиск (5 мин):

omega.tech упоминается в 7 репозиториях. В одном из них есть файл .env с открытым ключом SMTP.

Wayback Machine (5 мин):

Найдена старая версия сайта 2017 года с контактами и старым списком сотрудников.

Сборка карты инфраструктуры (остальное время):

Визуализация в Maltego: домен → IP → ASN → поддомены → сервисы.

Итог за 1 час:

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

ЭТИЧЕСКИЕ МОМЕНТЫ: ЧТО ДЕЛАТЬ С НАЙДЕННЫМ

Каждый из описанных кейсов поднимает этические вопросы. Вот несколько правил:

Если вы нашли секрет (пароль, ключ), НЕ ИСПОЛЬЗУЙТЕ ЕГО для доступа к системе. Сообщите владельцу через официальный канал (security@company.com, программа Bug Bounty). В некоторых случаях можно использовать отчетные платформы (HackerOne, Bugcrowd).
Не распространяйте найденные данные. Если вы обнаружили дамп базы данных с персональными данными, не копируйте их, не делитесь ими. Просто уведомите владельца.
Соблюдайте законы о персональных данных (GDPR, 152-ФЗ). В некоторых юрисдикциях даже хранение найденных данных может быть нарушением.
Если вы мониторите конкурента в коммерческих целях, используйте только публичные источники. Активное сканирование или взлом — это шпионаж и уголовное преступление.
В пентесте с разрешением — все найденное документируется и передается заказчику. Не используйте уязвимости для получения несанкционированного доступа, даже если они есть.

ЗАКЛЮЧЕНИЕ

Технический OSINT — это системный подход к сбору информации об инфраструктуре организаций из открытых источников. Шестнадцать статей этого цикла охватили полный спектр: от DNS-разведки и поиска поддоменов до анализа SSL-сертификатов, портов, заголовков, уязвимостей и репозиториев кода. Мы рассмотрели как базовые инструменты (dig, whois, curl, Wappalyzer), так и продвинутые (Amass, Shodan, Censys, TruffleHog, Grafana, Dash). Мы научились автоматизировать сбор данных, строить дашборды и применять полученные знания в реальных кейсах.

Главные выводы цикла:

Пассивная разведка безопасна и легальна (в отличие от активного сканирования), но даёт до 80% информации об инфраструктуре.
Комбинируйте источники: DNS, CT-логи, архивы, GitHub, Shodan — каждый добавляет свои уникальные данные.
Автоматизация — ключ к масштабу: ручной сбор годится для одного-двух доменов; для десятков и сотен нужны скрипты.
Интерпретация важнее сбора: найденные данные нужно анализировать, визуализировать и применять.
Этика — основа профессии: собранная информация должна использоваться для защиты, а не для атак.

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