Методы геолокации по фотографиям: ландшафт, архитектура, растительность, дорожные знаки

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

Уровни геолокации по фотографии

Пирамида геолокации

1. Язык и письменность - Вывески, надписи, реклама.
2. Архитектура - Стиль зданий, форма крыш, строительные материалы.
3. Транспорт - Типы автомобилей, номера, дорожная разметка.
4. Инфраструктура - Дорожные знаки, фонари, столбы, опоры ЛЭП.
5. Ландшафт и природа - Растительность, рельеф, водоемы.
6. Погода и освещение - Солнце, тени, облака.
7. Специфические маркеры - Флаги, гербы, памятники, таблички.

Этап 1: Язык и письменность

Это самый быстрый и очевидный способ ограничить географию.

Что искать:

• Текст на вывесках: Магазины, кафе, остановки, указатели.
• Язык: Русский, украинский, английский, китайский, арабский и т.д.
• Скрипт (алфавит): Кириллица, латиница, арабское письмо, иероглифы.
• Особенности орфографии: Буква «і» указывает на украинский, «ğ» - на турецкий.
• Политика языков: Некоторые страны имеют два официальных языка - это сужает поиск.

Примеры:

• Надпись на украинском и кириллица - Украина.
• Латиница с диакритикой (ě, š, č) - Чехия, Словакия, Польша.
• Арабский шрифт - Ближний Восток.
• Иероглифы (упрощенные) - Китай.
• Иероглифы (традиционные) - Тайвань, Гонконг.

Инструменты:

• Google Translate (распознавание незнакомых языков по фото - Google Lens).
• База Unicode, информация о региональных языках.

Этап 2: Архитектура

Архитектурный стиль региона - один из самых надежных маркеров, так как он меняется медленно.

Ключевые элементы архитектуры:

Дополнительные признаки:

• Цвет фасадов (в Санкт-Петербурге - пастельные тона, в Скандинавии - яркие цвета, в Париже - бежевый камень).
• Высота зданий (в Европе редко бывают небоскребы, в Азии и США - часто).
• Элементы отделки (лепнина, мозаика, кафель, скульптуры).

Инструменты:

• Google Lens: найти похожую архитектуру в интернете.
• Базы архитектурных стилей (Wikipedia, архитектурные сайты).
• Google Images и Yandex.Images (поиск по фрагментам).

Этап 3: Транспорт и автомобили

Автомобили и другие транспортные средства - отличный маркер региона.

Ключевые элементы транспорта:

Анализ номерных знаков:

• Код региона: В России и Казахстане региональный код часто включен в номер.
• Страна: Цвет и формат номеров регулируются законодательством.
• Цвет фона:
• Белый - большинство стран.
• Желтый - Великобритания, Люксембург.
• Зеленый - некоторые коммерческие авто в странах ЕС.

Инструменты:

• PlateRecognizer (распознавание номеров по фото - платное).
• Таблицы автомобильных номеров (поисковые запросы по формату).

Этап 4: Дорожные знаки и инфраструктура

Дорожные знаки имеют национальные особенности, хотя и стандартизированы (Венская конвенция).

Ключевые признаки дорожных знаков:

• Форма: Круглые (запрещающие, предписывающие) vs треугольные (предупреждающие).
• Цвет: Красная кайма (запрет), синий фон (предписание, информация).
• Оформление: Шрифт, пиктограммы, наличие надписей на национальном языке.
• Столбы и фонари: Тип и форма фонарных столбов может указывать на страну.

Примеры:

• В России знак «Пешеходный переход» - синий квадрат с белым треугольником. В Европе - знак с пешеходом на зебре, часто желтый фон.
• В странах ЕС границы стран часто обозначаются синим щитом с желтыми звездами.

Этап 5: Ландшафт и растительность

Природные особенности - одни из самых сложных, но и самых достоверных маркеров.

Инструменты:

• Google Lens (распознавание растений и деревьев).
• iNaturalist (определение растений по фото).
• Спутниковые карты (Google Earth, Sentinel).

Этап 6: Погода как маркер сезона и климата

Погода на фотографии может указывать на сезон и климатическую зону.

Этап 7: Специфические маркеры (памятники, флаги, гербы)

Это самые сильные маркеры, если их удается идентифицировать.

Что искать:

• Флаги: Государственный флаг часто виден на зданиях, аэродромах.
• Гербы: На зданиях администрации, на гербовых печатях.
• Памятники: Статуи, мемориалы, монументы.
• Вывески с названиями: Улицы, города, крупные сети магазинов.

Инструменты:

• Поиск по изображению (Reverse Image Search): Загружаем фото памятника в Google Images.
• Википедия: Поиск по описанию памятника.

Практический пример: геолокация сложного фото

Задача: Определить место съемки по фотографии, где видны: здание с красной крышей, река с лодками, белая церковь с голубым куполом.

1. Язык: Надпись на здании - по-русски. - Россия или страны СНГ.
2. Архитектура: Церковь с голубым куполом - православная. Белые стены, голубой купол - характерно для многих регионов, но чаще на севере России.
3. Ландшафт: Река, лодки, на заднем плане лесистые холмы - северный регион.
4. Поиск по фрагментам: Вывеска на здании - «Гостиница Рыбацкая». Поиск в Яндекс - есть отель с таким названием в городе Петрозаводск.
5. Сравнение с панорамами: Яндекс.Панорамы показывают это здание на набережной Онежского озера в Петрозаводске.
6. Кросс-референс: В новостях Петрозаводска есть упоминания о реке и церкви, совпадающие по описанию.
7. Результат: Координаты: 61.79° N, 34.39° E (Петрозаводск, Россия).

Этап 8: Поиск по уникальным элементам с помощью Google Lens и поисковиков

Google Lens (мобильное приложение) позволяет сканировать объекты на фото и искать информацию о них. Это часто быстрее, чем вручную искать по тексту.

Использование Google Lens:

1. Открыть фото в приложении Google.
2. Обвести объект (вывеску, памятник, здание).
3. Посмотреть результаты поиска.

Использование Yandex.Images:

• Загрузка фото и поиск по зданиям, вывескам, ландшафту. В русскоязычном сегменте часто точнее Google.

Этап 9: Составление карты-подсказки (Mind Map)

Для системного анализа полезно создать карту-подсказку:

Фото
├── Язык → [страны]
├── Архитектура → [стиль]
├── Транспорт
│   ├── Номера → [страна/регион]
│   └── Тип машин → [эпоха / регион]
├── Ландшафт
│   ├── Растительность → [климатическая зона]
│   └── Водоемы → [регион]
├── Инфраструктура
│   ├── Столбы → [региональный стиль]
│   └── Знаки → [страна]
└── Погода → [сезон]

Инструментарий геолокации (сводная таблица)

Ошибки при геолокации

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

Введение в GEOINT: география как источник разведывательных данных

Геопространственный OSINT (GEOINT) — это направление открытой разведки, специализирующееся на сборе, анализе и интерпретации географической информации. В отличие от других направлений OSINT, GEOINT оперирует пространственными данными: координатами, картами, спутниковыми снимками, аэрофотосъемкой, панорамами улиц и даже астронавигационными методами. Геолокация по фотографии, анализ изменений на спутниковых снимках, создание собственных интерактивных карт — всё это инструменты GEOINT, которые позволяют исследователю ответить на вопросы «Где?», «Когда?», «Что изменилось?» и «Почему именно здесь?».

Что такое GEOINT и чем он отличается от других направлений OSINT?

GEOINT (Geospatial Intelligence) — это дисциплина, которая использует географические данные для поддержки принятия решений. В контексте открытой разведки это означает:

1. Пассивное извлечение географической информации из фотографий, видео, спутниковых снимков, карт и других открытых источников.
2. Анализ пространственных взаимосвязей между объектами, событиями и местами.
3. Визуализацию данных на картах для выявления закономерностей и трендов.

В отличие от транспортного OSINT, где акцент делается на перемещениях и логистике, GEOINT фокусируется на статической географии: место съемки, ландшафт, инфраструктура, изменения во времени.

Почему GEOINT важен для расследований?

Основные источники данных в GEOINT

Методологическая схема GEOINT-расследования

1. Обнаружение контента: Найдено фото/видео с неизвестной локацией.
2. Предварительный визуальный осмотр: Анализ видимых элементов — архитектура, язык, природа, транспорт.
3. Извлечение метаданных: EXIF, GPS, дата съемки (если не удалены).
4. Поиск по изображению (Reverse Image Search): Проверка, не публиковалось ли уже это фото с известной геолокацией.
5. Идентификация ключевых ориентиров: Уникальные объекты, которые можно найти на карте.
6. Сравнение с картами и панорамами: Google Maps, Яндекс.Панорамы, Mapillary.
7. Анализ теней и освещения: Определение времени суток и сезона.
8. Кросс-референс с другими источниками: Метеоданные, новости, соцсети.
9. Формулирование вывода: Точные координаты или район съемки, степень уверенности.

Ключевые навыки GEOINT-специалиста

Юридические ограничения и ответственность в GEOINT

• Анализ спутниковых снимков публичных сервисов (Sentinel, Google Earth) легален.
• Использование коммерческих спутниковых снимков (Maxar, Planet) для расследований допускается, но требует лицензии.
• Геолокация частных лиц без их согласия (по фото из соцсетей) может нарушать законы о персональных данных.
• Публикация точных координат секретных объектов (военные базы, ядерные объекты и объекты стратегического назначения) может быть запрещена законодательством.

GEOINT — это многогранная дисциплина, объединяющая географию, картографию, спутниковые технологии, анализ визуальных данных и методы верификации. Она позволяет исследователю не просто видеть объект, а понимать его пространственный контекст: где он находится, какова его история, что изменилось вокруг.

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

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

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

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

Ход работы:

1. WHOIS-анализ: alpha.com зарегистрирован 15 лет назад, регистратор — Namecheap. Контакты скрыты PrivacyGuard. DNS-серверы: ns1.alpha.com, ns2.alpha.com. Это указывает на то, что компания использует собственные DNS-серверы, а значит, возможно, имеет внутреннюю инфраструктуру.
2. 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.
3. Поиск поддоменов (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 (старый сайт).
4. Анализ SSL-сертификатов: На jenkins.alpha.com сертификат выдан Let's Encrypt, истекает через 10 дней. Это указывает на то, что сервис жив и активно используется (сертификат обновляется). На old.alpha.com сертификат истёк год назад — возможно, сервис уже неактивен, но всё ещё доступен по IP.
5. 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 (устаревший).
6. WHOIS по IP: Все IP-адреса принадлежат ALPHA-AS (AS12345), зарегистрированному в RIPE. Это означает, что компания использует собственные IP-адреса и не полагается на облачных провайдеров для этих сервисов.
7. Технологический стек (Wappalyzer): Основной сайт на Drupal 9.5.3 (уязвимый, CVE-2023-XXXX). Используется jQuery 3.6.0, Bootstrap 4.6. Google Analytics ID UA-123456-1.
8. GitHub-поиск: Организация alpha-org имеет несколько публичных репозиториев. Один из них — alpha-backend — содержит файл .env.example с реальными паролями (не были заменены на заглушки). В коде встречается строка DB_PASSWORD=AlphaDb2023.

Итог кейса:

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

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

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

Ход работы:

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

Итог кейса:

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

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

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

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

Ход работы:

1. Поиск упоминаний компании в GitHub:
   Использование GitHub Code Search с операторами: "gamma.tech" password, "gamma.tech" api_key, "gamma.tech" secret, "gamma.tech" token. Найдено 15 файлов, содержащих упоминания домена.
2. Анализ найденных файлов:
• В репозитории gamma-public есть файл config/database.yml, содержащий строку: password: GammaDB2023!. Этот репозиторий был публичным.
• В другом репозитории gamma-util в файле creds.py найден AWS-ключ: aws_access_key_id = "AKIAXXXXXXXXXXXXXXXX", aws_secret_access_key = "abcdefghijklmnopqrstuvwxyz1234567890". Ключ действителен.
3. Проверка активности ключей:
• Подключение к AWS CLI с найденным ключом (в безопасной изолированной среде) показывает, что ключ имеет права на чтение S3-бакетов, включая бакет gamma-customer-data.
• Список файлов в бакете содержит дампы баз данных с именами клиентов, email-адресами, телефонными номерами и даже хэшированными паролями (но слабый алгоритм хеширования).
4. Поиск других утечек:
• Использование Dehashed и Leak-Lookup по email-адресам сотрудников показывает, что несколько сотрудников использовали корпоративные email для регистрации на сторонних сервисах, пароли от которых были скомпрометированы.
• Это позволило злоумышленникам получить доступ к внутренним репозиториям и опубликовать их.
5. Восстановление цепочки:
• Один из разработчиков случайно закоммитил файл с паролями в публичный репозиторий.
• Злоумышленник нашёл этот файл через поиск по gamma.tech.
• Используя пароль, получил доступ к базе данных и скачал её.
• Также использовал AWS-ключ для доступа к S3-бакетам.

Итог кейса:

• Причина утечки — человеческая ошибка (публикация секретов в открытом репозитории).
• Скомпрометированы данные более 50 000 клиентов.
• Компания «Гамма» немедленно:
• Отозвала все скомпрометированные ключи и пароли.
• Удалила публичные репозитории с секретами.
• Внедрила политику автоматического сканирования всех публичных репозиториев на наличие секретов с помощью TruffleHog.
• Уведомила регулятора и клиентов об утечке (в соответствии с GDPR).

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

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

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

Ход работы:

1. Настройка мониторинга:
• CertSpotter добавлен на домен epsilon.io и *.epsilon.io.
• Ежедневный скрипт проверяет crt.sh на новые сертификаты для epsilon.io.
• Changedetection.io отслеживает главную страницу epsilon.io и страницу /careers (появление новых вакансий).
2. Обнаружение через 2 недели:
• CertSpotter отправляет уведомление: новый сертификат для api.epsilon.io.
• Сертификат выдан Let's Encrypt, в SAN указаны api.epsilon.io и *.api.epsilon.io.
3. Разведка нового поддомена:
• 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.
4. Анализ контента:
• Страница https://api.epsilon.io содержит Swagger-документацию (openapi.json). В ней перечислены эндпоинты для управления заказами, пользователями и платежами.
• Это явно новый API-сервис, который ещё не анонсирован.
5. Связь с вакансиями:
• На странице /careers появилась вакансия «Senior Node.js Developer» для работы над «новым облачным продуктом».
• Это подтверждает, что компания запускает новый B2B-сервис.

Итог кейса:

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

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

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

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

Ход работы:

1. crt.sh (стандартный запрос): %.zeta.space даёт 25 результатов, включая те, что уже известны.
2. 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-логах.
3. Проверка доступности:
• staging.zeta.space резолвится в 203.0.113.77.
• Порт 80 открыт, на нём видна тестовая страница с ошибкой PHP.
• Порт 443 закрыт (сертификата нет).
4. Анализ контента на Wayback Machine:
• Сохранённая копия staging.zeta.space от 2 лет назад содержит полную структуру каталогов: /admin, /backup, /old. В папке /backup лежит файл db_backup_2022.sql.
5. Поиск по файлу в Wayback Machine:
• Исследователь скачивает db_backup_2022.sql (через архивную ссылку) и находит в нём email-адреса сотрудников, включая адреса IT-отдела.
6. Использование email для дальнейшей разведки:
• Через утечки (Dehashed) находится, что один из email использовался на форумах, где пароль был скомпрометирован.

Итог кейса:

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

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

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

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

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

1. WHOIS (2 мин): omega.tech зарегистрирован через GoDaddy, дата создания 2015-03-10, NS: ns1.omega.tech, контакты скрыты.
2. 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).
3. Поддомены (crt.sh + SecurityTrails) (5 мин):
• Найдено 30 поддоменов, включая jenkins, gitlab, monitoring, dev.
4. Анализ IP и ASN (5 мин):
• 54.0.0.10 принадлежит AWS (AS14618), регион us-east-1.
• Другие IP поддоменов принадлежат тому же AWS-аккаунту (определено по схожести IP-диапазонов).
5. 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).
6. SSL-сертификаты (3 мин):
• Все сертификаты выданы Let's Encrypt, истекают через 20 дней. Это указывает на единую политику управления.
7. Технологический стек (3 мин):
• Wappalyzer: основной сайт на WordPress 5.9 с плагинами: WooCommerce, Yoast SEO, WP Rocket. Тема — OceanWP.
8. GitHub-поиск (5 мин):
• omega.tech упоминается в 7 репозиториях. В одном из них есть файл .env с открытым ключом SMTP.
9. Wayback Machine (5 мин):
• Найдена старая версия сайта 2017 года с контактами и старым списком сотрудников.
10. Сборка карты инфраструктуры (остальное время):
• Визуализация в Maltego: домен → IP → ASN → поддомены → сервисы.

Итог за 1 час:

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

Создание дашборда для мониторинга инфраструктуры цели

После того как все этапы технического OSINT автоматизированы и данные собираются в базу данных, возникает следующая задача: как сделать эту информацию доступной, наглядной и удобной для анализа. Отчёты в виде JSON или CSV хороши для машинной обработки, но для человека визуализация в виде графиков, карт, таблиц и интерактивных панелей значительно эффективнее. Дашборд (dashboard) — это единая панель управления, которая отображает ключевые показатели, изменения в инфраструктуре, новые поддомены, открытые порты, уязвимости и другие данные в реальном времени (или близком к нему). Данная статья посвящена созданию веб-дашборда для мониторинга инфраструктуры цели с использованием открытых инструментов.

Зачем нужен дашборд в техническом OSINT?

Подходы к созданию дашборда

В этой статье мы рассмотрим два основных подхода:

1. Быстрый старт с Grafana — минимальная настройка, мощная визуализация.
2. Гибкий дашборд на Python (Dash) — полный контроль над данными и интерфейсом.

ВАРИАНТ 1: ДАШБОРД НА GRAFANA + SQLITE

Grafana — это популярная платформа для мониторинга и визуализации данных. Она поддерживает множество источников данных, включая SQLite, PostgreSQL, Prometheus, Elasticsearch. Для нашего случая SQLite подходит отлично — данные уже хранятся в ней.

Архитектура:

SQLite Database → Grafana (с плагином SQLite) → Дашборд с панелями

Установка Grafana:

# Ubuntu/Debian
sudo apt-get update
sudo apt-get install -y software-properties-common
sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"
sudo apt-get update
sudo apt-get install grafana

# Запуск
sudo systemctl enable grafana-server
sudo systemctl start grafana-server

Grafana будет доступна по адресу http://localhost:3000 (логин/пароль по умолчанию: admin/admin).

Подключение SQLite к Grafana:

Стандартный Grafana не поддерживает SQLite напрямую. Нужно использовать плагин:

1. Установить плагин grafana-sqlite-datasource:bashsudo grafana-cli plugins install frser-sqlite-datasource sudo systemctl restart grafana-server
2. В веб-интерфейсе Grafana: Configuration → Data Sources → Add data source → SQLite.
• Указать путь к файлу БД: /path/to/osint.db

Создание панелей в Grafana:

Панель 1: Количество поддоменов за последние 30 дней (гистограмма)

SELECT 
    DATE(discovered_at) as date,
    COUNT(*) as count
FROM subdomains
WHERE discovered_at > datetime('now', '-30 days')
GROUP BY DATE(discovered_at)
ORDER BY date ASC

Панель 2: Таблица последних поддоменов

SELECT subdomain, discovered_at
FROM subdomains
ORDER BY discovered_at DESC
LIMIT 20

Панель 3: Истекающие сертификаты (таблица)

SELECT name, valid_to, 
       julianday(valid_to) - julianday('now') as days_left
FROM certificates
WHERE days_left < 30 AND days_left > 0
ORDER BY days_left ASC

Панель 4: Распределение открытых портов (круговая диаграмма)

SELECT port, COUNT(*) as count
FROM shodan_ports
GROUP BY port
ORDER BY count DESC
LIMIT 10

Grafana преимущества:

• Быстрая настройка, красивые графики "из коробки".
• Автообновление данных.
• Поддержка алертов (email, Telegram, Slack).

Grafana недостатки:

• Ограниченная кастомизация (сложно добавить нестандартную логику).
• Нужно устанавливать плагин для SQLite (или использовать PostgreSQL).

ВАРИАНТ 2: ГИБКИЙ ДАШБОРД НА PYTHON (DASH + PLOTLY)

Dash — это веб-фреймворк от Plotly для создания аналитических дашбордов на Python. Он позволяет полностью контролировать логику обработки данных и визуализацию, не требуя знаний JavaScript.

Архитектура:

SQLite Database → Python (Dash) → Веб-интерфейс (HTML/CSS/JS)

Установка зависимостей:

pip install dash plotly pandas

Структура проекта:

dashboard/
├── app.py              # Главный файл приложения
├── data/
│   └── osint.db        # База данных
├── assets/
│   └── style.css       # Стили (опционально)
└── requirements.txt

Создание дашборда (app.py):

import dash
from dash import dcc, html, Input, Output, State
import plotly.graph_objects as go
import plotly.express as px
import sqlite3
import pandas as pd
from datetime import datetime, timedelta

# Инициализация приложения
app = dash.Dash(__name__, title="OSINT Dashboard")
server = app.server

# Функция подключения к БД
def get_db_connection():
    conn = sqlite3.connect('data/osint.db')
    conn.row_factory = sqlite3.Row
    return conn

# ============ ВСПОМОГАТЕЛЬНЫЕ ФУНКЦИИ ============

def get_subdomain_history(domain=None, days=30):
    """Получение истории поддоменов за последние N дней"""
    conn = get_db_connection()
    query = """
        SELECT DATE(discovered_at) as date, COUNT(*) as count
        FROM subdomains s
        JOIN domains d ON s.domain_id = d.id
        WHERE d.domain = ? AND discovered_at > datetime('now', '-' || ? || ' days')
        GROUP BY DATE(discovered_at)
        ORDER BY date ASC
    """
    df = pd.read_sql_query(query, conn, params=(domain, days))
    conn.close()
    return df

def get_recent_subdomains(domain=None, limit=20):
    """Получение последних поддоменов"""
    conn = get_db_connection()
    query = """
        SELECT s.subdomain, s.discovered_at
        FROM subdomains s
        JOIN domains d ON s.domain_id = d.id
        WHERE d.domain = ?
        ORDER BY s.discovered_at DESC
        LIMIT ?
    """
    df = pd.read_sql_query(query, conn, params=(domain, limit))
    conn.close()
    return df

def get_expiring_certs(domain=None, days=30):
    """Получение истекающих сертификатов"""
    conn = get_db_connection()
    query = """
        SELECT name, issuer, valid_to,
               julianday(valid_to) - julianday('now') as days_left
        FROM certificates c
        JOIN domains d ON c.domain_id = d.id
        WHERE d.domain = ? AND days_left < ? AND days_left > 0
        ORDER BY days_left ASC
    """
    df = pd.read_sql_query(query, conn, params=(domain, days))
    conn.close()
    return df

def get_port_distribution(domain=None):
    """Распределение открытых портов"""
    conn = get_db_connection()
    query = """
        SELECT port, COUNT(*) as count
        FROM shodan_ports sp
        JOIN domains d ON sp.domain_id = d.id
        WHERE d.domain = ?
        GROUP BY port
        ORDER BY count DESC
        LIMIT 15
    """
    df = pd.read_sql_query(query, conn, params=(domain,))
    conn.close()
    return df

def get_tech_stack(domain=None):
    """Технологический стек"""
    conn = get_db_connection()
    # Предположим, есть таблица technologies
    query = """
        SELECT tech_name, COUNT(*) as count
        FROM technologies t
        JOIN domains d ON t.domain_id = d.id
        WHERE d.domain = ?
        GROUP BY tech_name
        ORDER BY count DESC
        LIMIT 15
    """
    # Если таблицы нет — заглушка
    df = pd.DataFrame({'tech_name': ['nginx', 'PHP', 'WordPress', 'jQuery', 'Bootstrap'],
                       'count': [1, 1, 1, 1, 1]})
    conn.close()
    return df

def get_all_domains():
    """Список всех отслеживаемых доменов"""
    conn = get_db_connection()
    df = pd.read_sql_query("SELECT domain FROM domains ORDER BY domain ASC", conn)
    conn.close()
    return df['domain'].tolist()

# ============ МАКЕТ ДАШБОРДА ============

app.layout = html.Div([
    # Заголовок
    html.H1("📊 OSINT Infrastructure Dashboard", style={'textAlign': 'center', 'marginBottom': 30}),
    
    # Выбор домена
    html.Div([
        html.Label("Выберите домен:"),
        dcc.Dropdown(
            id='domain-selector',
            options=[{'label': d, 'value': d} for d in get_all_domains()],
            value='example.com' if 'example.com' in get_all_domains() else get_all_domains()[0] if get_all_domains() else None,
            style={'width': '50%', 'margin': '10px 0'}
        )
    ], style={'padding': '0 20px'}),
    
    # Верхние карточки (метрики)
    html.Div([
        html.Div([
            html.H3("🌐 Всего поддоменов"),
            html.H2(id='total-subdomains', style={'color': '#2196F3'})
        ], className='metric-card'),
        html.Div([
            html.H3("🔄 Изменений за 7 дней"),
            html.H2(id='changes-7d', style={'color': '#FF9800'})
        ], className='metric-card'),
        html.Div([
            html.H3("⏳ Истекающих сертификатов (<30 дн)"),
            html.H2(id='expiring-certs', style={'color': '#F44336'})
        ], className='metric-card'),
        html.Div([
            html.H3("🔓 Открытых портов"),
            html.H2(id='total-ports', style={'color': '#4CAF50'})
        ], className='metric-card'),
    ], style={'display': 'flex', 'gap': '20px', 'padding': '0 20px', 'flexWrap': 'wrap'}),
    
    # Графики (сетка 2x2)
    html.Div([
        # График 1: История поддоменов
        html.Div([
            dcc.Graph(id='subdomain-history')
        ], className='graph-card'),
        
        # График 2: Распределение портов
        html.Div([
            dcc.Graph(id='port-distribution')
        ], className='graph-card'),
        
        # График 3: Истекающие сертификаты
        html.Div([
            dcc.Graph(id='cert-expiry')
        ], className='graph-card'),
        
        # График 4: Технологический стек
        html.Div([
            dcc.Graph(id='tech-stack')
        ], className='graph-card'),
    ], style={'display': 'grid', 'gridTemplateColumns': '1fr 1fr', 'gap': '20px', 'padding': '20px'}),
    
    # Таблица последних поддоменов
    html.Div([
        html.H3("🆕 Последние поддомены"),
        html.Div(id='recent-subdomains-table', style={'overflowX': 'auto'})
    ], style={'padding': '0 20px', 'marginTop': 20}),
    
    # Автообновление (раз в 60 секунд)
    dcc.Interval(
        id='interval-component',
        interval=60 * 1000,  # 60 секунд
        n_intervals=0
    )
], style={'maxWidth': '1400px', 'margin': '0 auto', 'fontFamily': 'Arial, sans-serif'})

# ============ КОЛБЭКИ ============

@app.callback(
    [
        Output('total-subdomains', 'children'),
        Output('changes-7d', 'children'),
        Output('expiring-certs', 'children'),
        Output('total-ports', 'children'),
        Output('subdomain-history', 'figure'),
        Output('port-distribution', 'figure'),
        Output('cert-expiry', 'figure'),
        Output('tech-stack', 'figure'),
        Output('recent-subdomains-table', 'children'),
    ],
    [Input('domain-selector', 'value'),
     Input('interval-component', 'n_intervals')]
)
def update_dashboard(domain, n_intervals):
    if not domain:
        return "—", "—", "—", "—", {}, {}, {}, {}, "Выберите домен"
    
    # 1. Количество поддоменов
    conn = get_db_connection()
    total_sub = pd.read_sql_query(
        "SELECT COUNT(*) as cnt FROM subdomains s JOIN domains d ON s.domain_id = d.id WHERE d.domain = ?",
        conn, params=(domain,)
    ).iloc[0]['cnt']
    conn.close()
    
    # 2. Изменения за 7 дней (новые поддомены)
    conn = get_db_connection()
    changes_7d = pd.read_sql_query(
        "SELECT COUNT(*) as cnt FROM subdomains s JOIN domains d ON s.domain_id = d.id WHERE d.domain = ? AND discovered_at > datetime('now', '-7 days')",
        conn, params=(domain,)
    ).iloc[0]['cnt']
    conn.close()
    
    # 3. Истекающие сертификаты
    expiring_df = get_expiring_certs(domain)
    expiring_count = len(expiring_df)
    
    # 4. Открытые порты
    ports_df = get_port_distribution(domain)
    total_ports = ports_df['count'].sum() if not ports_df.empty else 0
    
    # 5. График истории поддоменов
    history_df = get_subdomain_history(domain)
    fig_history = px.line(
        history_df, x='date', y='count',
        title='Поддомены по дням',
        labels={'date': 'Дата', 'count': 'Количество'}
    ) if not history_df.empty else go.Figure()
    
    # 6. Распределение портов
    fig_ports = px.pie(
        ports_df, values='count', names='port',
        title='Распределение портов'
    ) if not ports_df.empty else go.Figure()
    
    # 7. Истекающие сертификаты (бар-чарт)
    if not expiring_df.empty:
        fig_certs = px.bar(
            expiring_df, x='name', y='days_left',
            title='Дней до истечения сертификата',
            labels={'name': 'Домен', 'days_left': 'Дней'},
            color='days_left',
            color_continuous_scale='RdYlGn_r'
        )
    else:
        fig_certs = go.Figure()
        fig_certs.add_annotation(text="Нет истекающих сертификатов", showarrow=False)
    
    # 8. Технологический стек
    tech_df = get_tech_stack(domain)
    fig_tech = px.bar(
        tech_df, x='count', y='tech_name',
        orientation='h',
        title='Технологии',
        labels={'count': 'Количество', 'tech_name': 'Технология'}
    ) if not tech_df.empty else go.Figure()
    
    # 9. Таблица последних поддоменов
    recent_df = get_recent_subdomains(domain)
    if not recent_df.empty:
        table = html.Table([
            html.Thead(html.Tr([
                html.Th("Поддомен", style={'textAlign': 'left'}),
                html.Th("Обнаружен", style={'textAlign': 'left'})
            ])),
            html.Tbody([
                html.Tr([
                    html.Td(row['subdomain']),
                    html.Td(row['discovered_at'])
                ]) for _, row in recent_df.iterrows()
            ])
        ], style={'width': '100%', 'borderCollapse': 'collapse'})
    else:
        table = "Нет данных"
    
    return (
        total_sub,
        changes_7d,
        expiring_count,
        total_ports,
        fig_history,
        fig_ports,
        fig_certs,
        fig_tech,
        table
    )

# ============ ЗАПУСК ============

if __name__ == '__main__':
    app.run_server(debug=True, host='0.0.0.0', port=8050)

Добавление CSS-стилей (assets/style.css):

.metric-card {
    background: white;
    border-radius: 10px;
    box-shadow: 0 2px 10px rgba(0,0,0,0.1);
    padding: 20px;
    flex: 1;
    min-width: 150px;
    text-align: center;
}
.metric-card h3 {
    margin: 0 0 10px 0;
    font-size: 14px;
    color: #666;
}
.metric-card h2 {
    margin: 0;
    font-size: 32px;
}

.graph-card {
    background: white;
    border-radius: 10px;
    box-shadow: 0 2px 10px rgba(0,0,0,0.05);
    padding: 15px;
}

table {
    border: 1px solid #ddd;
}
table th {
    background: #f5f5f5;
    padding: 10px;
    border-bottom: 2px solid #ddd;
}
table td {
    padding: 8px 10px;
    border-bottom: 1px solid #eee;
}
table tr:hover {
    background: #f9f9f9;
}

Запуск дашборда:

python app.py

Дашборд будет доступен по адресу: http://localhost:8050

ВАРИАНТ 3: БЫСТРЫЙ СТАТИЧЕСКИЙ ОТЧЁТ (HTML)

Если веб-сервер не требуется, можно генерировать статический HTML-отчёт с графиками.

Использование библиотеки matplotlib + mpld3 для интерактивных графиков в HTML:

import matplotlib.pyplot as plt
import mpld3
import sqlite3
import pandas as pd

def generate_report(domain):
    # Получение данных
    history_df = get_subdomain_history(domain)
    ports_df = get_port_distribution(domain)
    
    # Генерация графиков
    fig1, ax1 = plt.subplots()
    ax1.plot(history_df['date'], history_df['count'])
    ax1.set_title('Поддомены по дням')
    fig1_html = mpld3.fig_to_html(fig1)
    
    fig2, ax2 = plt.subplots()
    ax2.pie(ports_df['count'], labels=ports_df['port'], autopct='%1.1f%%')
    ax2.set_title('Распределение портов')
    fig2_html = mpld3.fig_to_html(fig2)
    
    # Сборка HTML
    html = f"""
    <html>
    <head><title>Отчёт по {domain}</title></head>
    <body>
        <h1>OSINT Отчёт: {domain}</h1>
        <div>{fig1_html}</div>
        <div>{fig2_html}</div>
    </body>
    </html>
    """
    with open(f'report_{domain}.html', 'w') as f:
        f.write(html)

ВАРИАНТ 4: ИСПОЛЬЗОВАНИЕ SPIDERFOOT

SpiderFoot — это OSINT-фреймворк с собственным веб-интерфейсом. Он автоматически собирает данные из множества источников и визуализирует их в виде графа связей.

Установка SpiderFoot:

# Docker (рекомендуемый способ)
docker run -p 5000:5000 spiderfoot/spiderfoot

Особенности SpiderFoot:

• Графовое представление связей (домены, IP, email, хэши).
• Автоматический сбор из 200+ модулей.
• Встроенный дашборд с картами и таймлайнами.

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

ВАРИАНТ 5: MALTEGO ДЛЯ ВИЗУАЛИЗАЦИИ СВЯЗЕЙ

Maltego — это инструмент для визуализации связей между сущностями (доменами, IP, личностями). В сочетании с трансформами он превращает собранные данные в интерактивный граф.

Как использовать:

• Экспортировать данные из SQLite в CSV.
• Импортировать в Maltego как "сущности" (Entities).
• Использовать трансформы для дальнейшего обогащения.

СРАВНЕНИЕ ИНСТРУМЕНТОВ ДЛЯ ДАШБОРДОВ

Практический пример: использование дашборда для мониторинга

Сценарий: аналитик мониторит 5 доменов конкурентов.

1. Ежедневный сбор → данные попадают в SQLite через автоматизированный конвейер.
2. Дашборд (Dash) → отображает для каждого домена:
• Количество поддоменов (график роста).
• Новые поддомены за неделю (таблица).
• Открытые порты и сервисы.
• Истекающие сертификаты (алерт).
3. Обнаружение: на дашборде появляется новый поддомен newapp.competitor.com. Аналитик видит, что это произошло сегодня. Через Shodan выясняется, что на нём открыт порт 443 с сертификатом от AWS. Вывод: конкурент запускает новый облачный сервис.
4. Реакция: информация передаётся в стратегический отдел.

РЕКОМЕНДАЦИИ ПО ВЫБОРУ

Дашборд — это завершающий элемент системы технического OSINT, превращающий сырые данные в понятную и удобную для анализа информацию. Выбор инструмента зависит от задач: Grafana подходит для быстрого старта и оперативного мониторинга, Dash/Plotly — для глубокой кастомизации, Maltego — для визуализации связей. Интеграция дашборда с автоматизированным конвейером (из предыдущей статьи) создаёт полноценную систему непрерывной разведки, где данные собираются, обрабатываются и отображаются в реальном времени.

Автоматизация технического OSINT: сбор данных в скриптах (Python, Bash)

Ручное выполнение всех этапов технического OSINT для одного домена может занять несколько часов. При необходимости мониторинга десятков или сотен целей ручной сбор становится невозможным. Автоматизация превращает разрозненные запросы к API, парсинг веб-страниц и анализ данных в единый воспроизводимый конвейер, который можно запускать по расписанию. Правильно построенная система автоматизации позволяет получать актуальную информацию о целях без участия человека, экономить время и избегать ошибок. Данная статья посвящена методам и практическим примерам автоматизации технического OSINT с использованием Python и Bash.

Зачем автоматизировать технический OSINT?

Подходы к автоматизации

Этап 1: Структура проекта

Рекомендуемая структура каталога для автоматизации:

osint-automation/
├── config/
│   ├── config.yaml            # API ключи, настройки
│   └── targets.txt            # Список доменов (по одному на строку)
├── modules/
│   ├── dns.py                 # Сбор DNS-записей
│   ├── whois.py               # WHOIS-информация
│   ├── subdomains.py          # Поиск поддоменов (crt.sh, SecurityTrails)
│   ├── certificates.py        # SSL/TLS сертификаты
│   ├── shodan.py              # Shodan-данные
│   ├── tech_stack.py          # Wappalyzer/BuiltWith технологии
│   ├── github.py              # Поиск секретов в GitHub
│   └── changes.py             # Сравнение с предыдущим состоянием
├── utils/
│   ├── logger.py              # Логирование
│   ├── notifier.py            # Отправка уведомлений (Telegram, Email)
│   └── db.py                  # Работа с SQLite
├── data/                      # Хранилище результатов (JSON, SQLite)
├── main.py                    # Главный скрипт
├── requirements.txt           # Зависимости Python
└── run.sh                     # Bash-обёртка для cron

Этап 2: Настройка конфигурации (config.yaml)

# config.yaml
api_keys:
  shodan: "SHODAN_API_KEY"
  securitytrails: "SECURITYTRAILS_API_KEY"
  github: "GITHUB_TOKEN"
  virustotal: "VIRUSTOTAL_API_KEY"  # опционально
  censys:
    api_id: "CENSYS_API_ID"
    api_secret: "CENSYS_API_SECRET"

notifications:
  telegram:
    token: "TELEGRAM_BOT_TOKEN"
    chat_id: "TELEGRAM_CHAT_ID"
  email:
    smtp_server: "smtp.gmail.com"
    smtp_port: 587
    username: "user@gmail.com"
    password: "app_password"
    to: "recipient@example.com"

database:
  path: "data/osint.db"

targets:
  file: "config/targets.txt"

logging:
  level: "INFO"
  file: "data/osint.log"

scan:
  # интервал повторных запросов для Shodan (если нужно ждать)
  shodan_delay: 1  # секунды между запросами
  timeout: 30  # таймаут для HTTP-запросов

Этап 3: Сбор DNS-записей (modules/dns.py)

import dns.resolver
import json
from utils.logger import get_logger

logger = get_logger(__name__)

def get_dns_records(domain):
    """
    Сбор основных DNS-записей: A, AAAA, MX, TXT, NS, CNAME, SOA
    """
    records = {}
    record_types = ['A', 'AAAA', 'MX', 'TXT', 'NS', 'CNAME', 'SOA']
    
    for rtype in record_types:
        try:
            answers = dns.resolver.resolve(domain, rtype)
            records[rtype] = [str(r) for r in answers]
        except dns.resolver.NoAnswer:
            records[rtype] = []
        except dns.resolver.NXDOMAIN:
            records[rtype] = []
        except Exception as e:
            logger.warning(f"DNS {rtype} для {domain}: {e}")
            records[rtype] = []
    
    return records

def get_reverse_dns(ip):
    """
    Обратный DNS (PTR) для IP-адреса
    """
    try:
        answers = dns.resolver.resolve_address(ip)
        return [str(r) for r in answers]
    except:
        return []

# Пример использования
if __name__ == "__main__":
    records = get_dns_records("example.com")
    print(json.dumps(records, indent=2))

Этап 4: WHOIS-информация (modules/whois.py)

import whois
import json
from datetime import datetime

def get_whois_info(domain):
    """
    Получение WHOIS-информации о домене
    """
    try:
        w = whois.whois(domain)
        return {
            'domain_name': w.domain_name,
            'registrar': w.registrar,
            'creation_date': str(w.creation_date),
            'expiration_date': str(w.expiration_date),
            'updated_date': str(w.updated_date),
            'name_servers': w.name_servers,
            'emails': w.emails,
            'org': w.org,
            'country': w.country,
        }
    except Exception as e:
        return {'error': str(e)}

Этап 5: Поиск поддоменов через crt.sh (modules/subdomains.py)

import requests
import json
from utils.logger import get_logger

logger = get_logger(__name__)

def get_subdomains_crtsh(domain):
    """
    Получение поддоменов из Certificate Transparency логов через crt.sh
    """
    url = f"https://crt.sh/?q=%25.{domain}&output=json"
    subdomains = set()
    try:
        resp = requests.get(url, timeout=30)
        if resp.status_code == 200:
            data = resp.json()
            for entry in data:
                name = entry.get('name_value', '')
                if name.endswith(f'.{domain}') or name == domain:
                    # убираем wildcard
                    if name.startswith('*.'):
                        name = name[2:]
                    subdomains.add(name.lower())
        else:
            logger.warning(f"crt.sh ошибка: {resp.status_code}")
    except Exception as e:
        logger.error(f"crt.sh исключение: {e}")
    
    return sorted(subdomains)

def get_subdomains_securitytrails(domain, api_key):
    """
    Получение поддоменов через SecurityTrails API (требуется ключ)
    """
    if not api_key:
        return []
    url = f"https://api.securitytrails.com/v1/domain/{domain}/subdomains"
    headers = {"APIKEY": api_key}
    try:
        resp = requests.get(url, headers=headers, timeout=30)
        if resp.status_code == 200:
            data = resp.json()
            subdomains = data.get('subdomains', [])
            return [f"{s}.{domain}" for s in subdomains]
    except Exception as e:
        logger.error(f"SecurityTrails ошибка: {e}")
    return []

def get_all_subdomains(domain, securitytrails_key=None):
    """
    Агрегация поддоменов из всех источников
    """
    all_subs = set()
    all_subs.update(get_subdomains_crtsh(domain))
    if securitytrails_key:
        all_subs.update(get_subdomains_securitytrails(domain, securitytrails_key))
    return sorted(all_subs)

Этап 6: Анализ SSL/TLS сертификатов (modules/certificates.py)

import requests
import json
from datetime import datetime

def get_certificates_crtsh(domain):
    """
    Получение информации о сертификатах для домена
    """
    url = f"https://crt.sh/?q=%25.{domain}&output=json"
    certs = []
    try:
        resp = requests.get(url, timeout=30)
        if resp.status_code == 200:
            data = resp.json()
            for entry in data:
                if len(entry) < 6:
                    continue
                certs.append({
                    'name': entry[1],
                    'issuer': entry[2],
                    'valid_from': entry[3],
                    'valid_to': entry[4],
                    'ca': entry[5]
                })
    except Exception as e:
        pass
    return certs

def get_certificate_expiry(certs):
    """
    Определение ближайшего истекающего сертификата
    """
    now = datetime.now()
    expiring = []
    for cert in certs:
        try:
            valid_to = datetime.strptime(cert['valid_to'], '%Y-%m-%dT%H:%M:%S')
            days_left = (valid_to - now).days
            if days_left < 30:
                expiring.append({
                    'name': cert['name'],
                    'expires': cert['valid_to'],
                    'days_left': days_left
                })
        except:
            pass
    return expiring

Этап 7: Сбор данных из Shodan (modules/shodan.py)

import shodan
from utils.logger import get_logger

logger = get_logger(__name__)

def get_shodan_host(ip, api_key):
    """
    Получение информации о хосте из Shodan
    """
    if not api_key:
        return {}
    try:
        api = shodan.Shodan(api_key)
        host = api.host(ip)
        return {
            'ip': host.get('ip_str'),
            'organization': host.get('org'),
            'isp': host.get('isp'),
            'country': host.get('country_name'),
            'ports': host.get('ports', []),
            'vulns': host.get('vulns', []),
            'data': host.get('data', [])  # баннеры
        }
    except shodan.APIError as e:
        logger.error(f"Shodan ошибка для {ip}: {e}")
        return {}
    except Exception as e:
        logger.error(f"Shodan исключение для {ip}: {e}")
        return {}

def get_shodan_host_by_domain(domain, api_key):
    """
    Поиск хостов, связанных с доменом, через Shodan
    """
    if not api_key:
        return []
    try:
        api = shodan.Shodan(api_key)
        results = api.search(f"hostname:{domain}")
        hosts = []
        for match in results.get('matches', []):
            hosts.append({
                'ip': match.get('ip_str'),
                'port': match.get('port'),
                'data': match.get('data', '')[:200]
            })
        return hosts
    except shodan.APIError as e:
        logger.error(f"Shodan search ошибка: {e}")
        return []

Этап 8: Поиск в GitHub (modules/github.py)

import requests
from utils.logger import get_logger

logger = get_logger(__name__)

def search_github_secrets(domain, token):
    """
    Поиск упоминаний домена и подозрительных паттернов в GitHub
    """
    if not token:
        return []
    
    # Комбинированный запрос: упоминания домена + файлы .env, пароли, ключи
    queries = [
        f'"{domain}" extension:env',
        f'"{domain}" password',
        f'"{domain}" api_key',
        f'"{domain}" secret',
        f'"{domain}" token',
    ]
    
    headers = {
        "Authorization": f"token {token}",
        "Accept": "application/vnd.github.v3+json"
    }
    
    all_results = []
    for query in queries:
        url = "https://api.github.com/search/code"
        params = {"q": query, "per_page": 20}
        try:
            resp = requests.get(url, headers=headers, params=params, timeout=20)
            if resp.status_code == 200:
                data = resp.json()
                for item in data.get('items', []):
                    all_results.append({
                        'repo': item['repository']['full_name'],
                        'path': item['path'],
                        'url': item['html_url'],
                        'query': query
                    })
            else:
                logger.warning(f"GitHub ошибка ({query}): {resp.status_code}")
        except Exception as e:
            logger.error(f"GitHub исключение: {e}")
    
    return all_results

Этап 9: Технологический стек (modules/tech_stack.py)

import subprocess
import json
from utils.logger import get_logger

logger = get_logger(__name__)

def get_tech_wappalyzer(url):
    """
    Определение технологий через Wappalyzer CLI
    Требуется установить: npm install -g wappalyzer
    """
    try:
        result = subprocess.run(
            ['wappalyzer', url],
            capture_output=True,
            text=True,
            timeout=60
        )
        if result.returncode == 0:
            return json.loads(result.stdout)
        else:
            logger.warning(f"Wappalyzer ошибка: {result.stderr}")
            return {}
    except Exception as e:
        logger.error(f"Wappalyzer исключение: {e}")
        return {}

def get_tech_builtwith(url, api_key=None):
    """
    Использование BuiltWith API (требуется ключ)
    """
    if not api_key:
        return {}
    endpoint = f"https://api.builtwith.com/free1/api.json?KEY={api_key}&LOOKUP={url}"
    try:
        import requests
        resp = requests.get(endpoint, timeout=30)
        if resp.status_code == 200:
            return resp.json()
    except Exception as e:
        logger.error(f"BuiltWith ошибка: {e}")
    return {}

Этап 10: Общая база данных (utils/db.py)

Используем SQLite для хранения истории изменений.

import sqlite3
import json
from datetime import datetime

class OSINTDatabase:
    def __init__(self, db_path):
        self.conn = sqlite3.connect(db_path)
        self.create_tables()
    
    def create_tables(self):
        cursor = self.conn.cursor()
        cursor.execute('''
            CREATE TABLE IF NOT EXISTS domains (
                id INTEGER PRIMARY KEY,
                domain TEXT UNIQUE,
                first_seen TEXT,
                last_updated TEXT
            )
        ''')
        cursor.execute('''
            CREATE TABLE IF NOT EXISTS subdomains (
                id INTEGER PRIMARY KEY,
                domain_id INTEGER,
                subdomain TEXT,
                discovered_at TEXT,
                FOREIGN KEY(domain_id) REFERENCES domains(id)
            )
        ''')
        cursor.execute('''
            CREATE TABLE IF NOT EXISTS dns_records (
                id INTEGER PRIMARY KEY,
                domain_id INTEGER,
                record_type TEXT,
                record_value TEXT,
                discovered_at TEXT,
                FOREIGN KEY(domain_id) REFERENCES domains(id)
            )
        ''')
        cursor.execute('''
            CREATE TABLE IF NOT EXISTS certificates (
                id INTEGER PRIMARY KEY,
                domain_id INTEGER,
                name TEXT,
                issuer TEXT,
                valid_from TEXT,
                valid_to TEXT,
                discovered_at TEXT,
                FOREIGN KEY(domain_id) REFERENCES domains(id)
            )
        ''')
        cursor.execute('''
            CREATE TABLE IF NOT EXISTS shodan_ports (
                id INTEGER PRIMARY KEY,
                domain_id INTEGER,
                ip TEXT,
                port INTEGER,
                data TEXT,
                discovered_at TEXT,
                FOREIGN KEY(domain_id) REFERENCES domains(id)
            )
        ''')
        cursor.execute('''
            CREATE TABLE IF NOT EXISTS changes (
                id INTEGER PRIMARY KEY,
                domain TEXT,
                change_type TEXT,
                old_value TEXT,
                new_value TEXT,
                detected_at TEXT
            )
        ''')
        self.conn.commit()
    
    def get_domain_id(self, domain):
        cursor = self.conn.cursor()
        cursor.execute("SELECT id FROM domains WHERE domain = ?", (domain,))
        row = cursor.fetchone()
        if row:
            return row[0]
        # Создаём новый
        cursor.execute("INSERT INTO domains (domain, first_seen, last_updated) VALUES (?, ?, ?)",
                       (domain, datetime.now().isoformat(), datetime.now().isoformat()))
        self.conn.commit()
        return cursor.lastrowid
    
    def save_subdomains(self, domain_id, subdomains):
        cursor = self.conn.cursor()
        for sub in subdomains:
            cursor.execute("INSERT OR IGNORE INTO subdomains (domain_id, subdomain, discovered_at) VALUES (?, ?, ?)",
                           (domain_id, sub, datetime.now().isoformat()))
        self.conn.commit()
    
    def save_dns_records(self, domain_id, records):
        cursor = self.conn.cursor()
        for rtype, values in records.items():
            for val in values:
                cursor.execute("INSERT INTO dns_records (domain_id, record_type, record_value, discovered_at) VALUES (?, ?, ?, ?)",
                               (domain_id, rtype, val, datetime.now().isoformat()))
        self.conn.commit()
    
    def save_certificates(self, domain_id, certs):
        cursor = self.conn.cursor()
        for cert in certs:
            cursor.execute("INSERT INTO certificates (domain_id, name, issuer, valid_from, valid_to, discovered_at) VALUES (?, ?, ?, ?, ?, ?)",
                           (domain_id, cert.get('name'), cert.get('issuer'), cert.get('valid_from'), cert.get('valid_to'), datetime.now().isoformat()))
        self.conn.commit()
    
    def log_change(self, domain, change_type, old_value, new_value):
        cursor = self.conn.cursor()
        cursor.execute("INSERT INTO changes (domain, change_type, old_value, new_value, detected_at) VALUES (?, ?, ?, ?, ?)",
                       (domain, change_type, old_value, new_value, datetime.now().isoformat()))
        self.conn.commit()
    
    def close(self):
        self.conn.close()

Этап 11: Главный конвейер (main.py)

#!/usr/bin/env python3
import os
import sys
import json
import yaml
from datetime import datetime
from utils.logger import setup_logger
from utils.db import OSINTDatabase
from utils.notifier import send_telegram
from modules.dns import get_dns_records
from modules.whois import get_whois_info
from modules.subdomains import get_all_subdomains
from modules.certificates import get_certificates_crtsh, get_certificate_expiry
from modules.shodan import get_shodan_host_by_domain
from modules.tech_stack import get_tech_wappalyzer
from modules.github import search_github_secrets
from modules.changes import compare_and_notify

# Загрузка конфига
with open('config/config.yaml', 'r') as f:
    config = yaml.safe_load(f)

logger = setup_logger(config['logging']['level'], config['logging']['file'])
db = OSINTDatabase(config['database']['path'])

def process_domain(domain):
    logger.info(f"Обработка {domain}")
    
    # Получаем ID домена в БД
    domain_id = db.get_domain_id(domain)
    
    # 1. WHOIS
    whois_data = get_whois_info(domain)
    logger.info(f"WHOIS для {domain}: {whois_data.get('registrar', 'unknown')}")
    
    # 2. DNS записи
    dns = get_dns_records(domain)
    db.save_dns_records(domain_id, dns)
    logger.info(f"DNS: A={len(dns.get('A', []))}, MX={len(dns.get('MX', []))}")
    
    # 3. Поддомены
    sec_key = config['api_keys'].get('securitytrails')
    subdomains = get_all_subdomains(domain, sec_key)
    db.save_subdomains(domain_id, subdomains)
    logger.info(f"Найдено {len(subdomains)} поддоменов")
    
    # 4. Сертификаты
    certs = get_certificates_crtsh(domain)
    db.save_certificates(domain_id, certs)
    expiring = get_certificate_expiry(certs)
    if expiring:
        logger.warning(f"Сертификаты истекают: {expiring}")
    
    # 5. Shodan (по поддоменам, ограничимся первыми 10 IP)
    shodan_key = config['api_keys'].get('shodan')
    if shodan_key and subdomains:
        for sub in subdomains[:10]:
            hosts = get_shodan_host_by_domain(sub, shodan_key)
            # сохраняем в БД
            for h in hosts:
                pass  # упрощённо
    
    # 6. Технологический стек
    if subdomains:
        main_url = f"https://{domain}"
        tech = get_tech_wappalyzer(main_url)
        logger.info(f"Технологии: {tech.get('technologies', [])}")
    
    # 7. GitHub секреты
    github_token = config['api_keys'].get('github')
    if github_token:
        secrets = search_github_secrets(domain, github_token)
        if secrets:
            logger.warning(f"Найдены потенциальные секреты в GitHub: {len(secrets)}")
            send_telegram(
                config['notifications']['telegram']['token'],
                config['notifications']['telegram']['chat_id'],
                f"Обнаружены секреты для {domain}: {len(secrets)} файлов"
            )
    
    # 8. Сравнение изменений
    compare_and_notify(domain, config, db)
    
    logger.info(f"Обработка {domain} завершена")

def main():
    targets_file = config['targets']['file']
    with open(targets_file, 'r') as f:
        domains = [line.strip() for line in f if line.strip()]
    
    for domain in domains:
        try:
            process_domain(domain)
        except Exception as e:
            logger.error(f"Ошибка для {domain}: {e}")
    
    db.close()
    logger.info("Все задачи выполнены")

if __name__ == "__main__":
    main()

Этап 12: Сравнение изменений и уведомления (modules/changes.py)

import json
import hashlib
import os
from utils.notifier import send_telegram

def load_previous_state(domain, data_dir='data/states'):
    """Загрузка предыдущего состояния из JSON"""
    os.makedirs(data_dir, exist_ok=True)
    state_file = os.path.join(data_dir, f"{domain}_state.json")
    if os.path.exists(state_file):
        with open(state_file, 'r') as f:
            return json.load(f)
    return {}

def save_current_state(domain, state, data_dir='data/states'):
    state_file = os.path.join(data_dir, f"{domain}_state.json")
    with open(state_file, 'w') as f:
        json.dump(state, f, indent=2)

def compare_and_notify(domain, config, db):
    """Сравнение текущего состояния с предыдущим и уведомление об изменениях"""
    # Собираем текущее состояние в словарь
    current = {
        'subdomains': sorted(db.get_subdomains(domain)),
        'dns': db.get_dns_records(domain),
        'certs': db.get_certificates(domain),
    }
    
    previous = load_previous_state(domain)
    
    changes = []
    
    # Сравнение поддоменов
    if previous:
        old_subs = set(previous.get('subdomains', []))
        new_subs = set(current.get('subdomains', []))
        added = new_subs - old_subs
        removed = old_subs - new_subs
        if added:
            changes.append(f"Новые поддомены: {', '.join(added)}")
        if removed:
            changes.append(f"Удалены: {', '.join(removed)}")
    
    # Если есть изменения — отправляем уведомление
    if changes:
        msg = f"Изменения для {domain}:\n" + "\n".join(changes)
        send_telegram(
            config['notifications']['telegram']['token'],
            config['notifications']['telegram']['chat_id'],
            msg
        )
        # Логируем в БД
        for change in changes:
            db.log_change(domain, 'change', '', change)
    
    # Сохраняем новое состояние
    save_current_state(domain, current)

Этап 13: Утилита уведомлений (utils/notifier.py)

import requests
import smtplib
from email.mime.text import MIMEText

def send_telegram(token, chat_id, message):
    """Отправка уведомления в Telegram"""
    if not token or not chat_id:
        return
    url = f"https://api.telegram.org/bot{token}/sendMessage"
    try:
        requests.post(url, json={'chat_id': chat_id, 'text': message}, timeout=10)
    except Exception as e:
        print(f"Telegram ошибка: {e}")

def send_email(smtp_server, port, username, password, to, subject, body):
    """Отправка email уведомления"""
    msg = MIMEText(body)
    msg['Subject'] = subject
    msg['From'] = username
    msg['To'] = to
    try:
        with smtplib.SMTP(smtp_server, port) as server:
            server.starttls()
            server.login(username, password)
            server.send_message(msg)
    except Exception as e:
        print(f"Email ошибка: {e}")

Этап 14: Bash-обёртка для cron (run.sh)

#!/bin/bash
# run.sh — обёртка для запуска конвейера с логированием

cd /path/to/osint-automation

# Активация виртуального окружения Python (если используется)
source venv/bin/activate

# Запуск основного скрипта
python main.py >> data/osint_cron.log 2>&1

# Проверка кода возврата
if [ $? -ne 0 ]; then
    echo "Ошибка выполнения $(date)" >> data/osint_errors.log
fi

# Удаление старых логов (старше 30 дней)
find data/ -name "*.log" -mtime +30 -delete

Настройка cron (ежедневно в 8 утра):

0 8 * * * /path/to/osint-automation/run.sh

Этап 15: Обработка ошибок и rate limits

Важные аспекты при автоматизации:

• Ограничения API: Используйте задержки между запросами (time.sleep), храните время последнего запроса.
• Повторные попытки: Реализуйте повтор при временных ошибках (например, 429 Too Many Requests).
• Логирование: Все ошибки пишите в лог для последующего анализа.
• Таймауты: Все HTTP-запросы должны иметь таймаут, чтобы скрипт не зависал.

Пример декоратора для повторных попыток:

import time
import functools

def retry(max_attempts=3, delay=5):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(max_attempts):
                try:
                    return func(*args, **kwargs)
                except Exception as e:
                    if attempt == max_attempts - 1:
                        raise
                    time.sleep(delay * (attempt + 1))
            return None
        return wrapper
    return decorator

Этап 16: Тестирование и мониторинг работы

После настройки автоматизации важно проверять:

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

1. Используйте только публичные API и данные.
2. Соблюдайте условия использования сервисов (Shodan, SecurityTrails, GitHub) — не превышайте лимиты запросов.
3. Не пытайтесь обойти защиту (CAPTCHA, блокировки) нелегальными методами.
4. Полученные данные используйте только для законных целей.
5. При обнаружении уязвимостей или секретов сообщайте владельцам.

Автоматизация технического OSINT — это создание программного конвейера, который собирает, обрабатывает и сохраняет данные о цифровой инфраструктуре цели без участия человека. Модульная архитектура на Python с использованием готовых библиотек (dns.resolver, whois, requests, shodan) и внешних API (crt.sh, SecurityTrails, Shodan, GitHub) позволяет охватить все основные источники. Сравнение состояний и уведомления делают систему полезной для долгосрочного мониторинга. Регулярный запуск через cron превращает набор скриптов в постоянно работающую систему разведки.

Анализ репозиториев кода: GitHub, GitLab, Bitbucket — поиск секретов, утечек кода

Публичные репозитории кода — это один из наиболее недооцененных, но богатых источников информации в техническом OSINT. Разработчики часто случайно загружают в открытые репозитории конфиденциальные данные: API-ключи, пароли, токены, внутренние URL, логины к базам данных, комментарии с внутренней информацией и даже дампы баз данных. Для специалиста по разведке анализ репозиториев позволяет не только найти чувствительные данные, но и восстановить внутреннюю архитектуру, выявить используемые технологии и даже получить доступ к закрытым системам. Данная статья посвящена методам поиска секретов и утечек кода в публичных репозиториях GitHub, GitLab, Bitbucket и других платформах.

Почему публичные репозитории опасны для организации?

Основные платформы для поиска кода

Этап 1: Базовый поиск на GitHub

GitHub предоставляет мощную поисковую систему с операторами. Поиск можно выполнять как через веб-интерфейс, так и через API.

Основные операторы GitHub:

Примеры поисковых запросов:

• Поиск ключей AWS: "AKIA" "SECRET" extension:txt
• Поиск паролей: password extension:env
• Поиск токенов GitHub: "ghp_" extension:txt
• Поиск конфигов: filename:.env
• Поиск SSH-ключей: "BEGIN RSA PRIVATE KEY"
• Поиск по домену компании: "example.com" "password"

Использование GitHub API для поиска:

import requests

GITHUB_TOKEN = "YOUR_TOKEN"
headers = {
    "Authorization": f"token {GITHUB_TOKEN}",
    "Accept": "application/vnd.github.v3+json"
}

def search_github(query):
    url = "https://api.github.com/search/code"
    params = {
        "q": query,
        "per_page": 10
    }
    response = requests.get(url, headers=headers, params=params)
    if response.status_code == 200:
        return response.json()
    else:
        print(f"Ошибка: {response.status_code}")
        return None

# Поиск .env файлов в организации example
results = search_github("extension:env org:example")
if results:
    for item in results.get('items', []):
        print(f"{item['repository']['full_name']}: {item['path']}")

Этап 2: Поиск секретов с использованием TruffleHog

TruffleHog — это специализированный инструмент для поиска секретов в репозиториях. Он анализирует историю коммитов, а не только текущие файлы, и использует детекторы для различных типов секретов.

Установка и использование:

# Установка через pip
pip install trufflehog

# Сканирование репозитория по URL
trufflehog git https://github.com/example/repo.git

# Сканирование всей организации (требуется токен)
trufflehog github --org=example --token=GITHUB_TOKEN

Пример вывода:

🐷🔑🐷  TruffleHog. Unearth your secrets. 🐷🔑🐷

2024-01-15 10:30:45    INFO    Detector Name: AWS
2024-01-15 10:30:45    INFO    Commit: 3a4b5c6d7e8f9...
2024-01-15 10:30:45    INFO    File: config/credentials.yml
2024-01-15 10:30:45    INFO    Line: 12
2024-01-15 10:30:45    INFO    Secret: AKIAXXXXXXXXXXXXXXXX

Этап 3: Использование GitRob и GitGrab для поиска по организациям

GitRob — утилита для поиска ключей и паролей в репозиториях GitHub организаций.

gitrob example

GitGrab — аналогичный инструмент, фокусирующийся на поиске конфигурационных файлов.

Этап 4: Поиск по расширениям файлов

Поиск на GitHub через веб-интерфейс:

extension:env org:example
extension:yml "password" org:example
extension:json "api_key" org:example

Этап 5: Поиск по строковым шаблонам секретов

Регулярные выражения помогают находить секреты по их формату.

Типичные паттерны:

Пример скрипта для поиска по паттернам в скачанном репозитории:

import re
import os
import fnmatch

patterns = {
    'aws': re.compile(r'AKIA[0-9A-Z]{16}'),
    'github': re.compile(r'ghp_[0-9a-zA-Z]{36}'),
    'slack': re.compile(r'xox[bap]-[0-9a-zA-Z-]+'),
    'ssh': re.compile(r'-----BEGIN (RSA|OPENSSH|DSA|EC) PRIVATE KEY-----'),
}

def scan_file(filepath):
    try:
        with open(filepath, 'r', encoding='utf-8', errors='ignore') as f:
            content = f.read()
            for name, pattern in patterns.items():
                matches = pattern.findall(content)
                if matches:
                    print(f"{filepath}: {name} -> {matches[:3]}")
    except:
        pass

def scan_repo(repo_path):
    for root, dirs, files in os.walk(repo_path):
        for file in files:
            scan_file(os.path.join(root, file))

# Сканирование локального клона репозитория
scan_repo('/path/to/cloned/repo')

Этап 6: Поиск через PublicWWW

PublicWWW — поисковая система, индексирующая HTML, CSS и JavaScript. Можно искать по строкам, которые появляются в коде веб-страниц.

Использование:

https://publicwww.com/websites/%22AKIA%22/

ищет не только код в репозиториях, но и во всех открытых веб-страницах.

Этап 7: Поиск через SearchCode

SearchCode агрегирует данные из GitHub, Bitbucket, GitLab и других источников. У него есть API.

# Поиск через веб-интерфейс
https://searchcode.com/?q=AKIA&p=2

Этап 8: Мониторинг новых утечек через GitHub

Новые утечки появляются постоянно. Важно настроить мониторинг на появление новых файлов с секретами.

Инструменты для мониторинга:

• GitHub Watch — подписка на изменения в репозиториях (вручную).
• HawkScan — автоматическое сканирование новых коммитов в организациях.
• LeakIX — поисковик утечек, отправляет уведомления.

Собственный мониторинг через GitHub API:

def monitor_new_commits(org, last_check_file):
    # Получение последних коммитов в организации
    # Сравнение с предыдущим состоянием
    # При обнаружении секретов — уведомление
    pass

Этап 9: Анализ истории коммитов (продвинутый уровень)

Git сохраняет историю изменений. Даже если секрет был удалён в последнем коммите, он может остаться в истории.

Поиск в истории через TruffleHog: (см. выше) сканирует всю историю.

Поиск в локально скачанном репозитории:

# Поиск по всем коммитам в Git
git log -p | grep -i "password"
git log -p | grep -i "AKIA"
git log -p | grep -i "ghp_"

Этап 10: Восстановление удалённых файлов из истории Git

Даже если файл был удалён, он может быть восстановлен через Git.

# Поиск файла в истории
git log --all --full-history -- "*config*"

# Восстановление файла
git show <commit_hash>:path/to/file

Этап 11: Поиск в GitLab и Bitbucket

GitLab: общедоступные проекты можно искать через поиск GitLab. Операторы: group:, project:.

Пример: https://gitlab.com/search?search=password&group_id=123

Bitbucket: аналогично, через поиск или API.

Сводная таблица инструментов поиска секретов

• Никогда не используйте найденные секреты для несанкционированного доступа. Это уголовное преступление.
• Если вы нашли секреты, принадлежащие организации, сообщите им через официальные каналы (security@example.com) или через программу Bug Bounty.
• Не распространяйте найденные секреты публично.
• При сканировании соблюдайте условия использования платформ (GitHub, GitLab) — чрезмерные запросы могут привести к блокировке IP.
• В некоторых юрисдикциях даже поиск секретов может считаться нарушением, если он ведётся без разрешения. Ориентируйтесь на публичные данные.

Практический пример: расследование утечки токенов

Задача: найти все токены, связанные с организацией example.com, и проинформировать их.

1. GitHub Search: "example.com" "token" extension:env → найдено 3 файла .env с токенами для Stripe, AWS и Slack.
2. TruffleHog: сканирование организации example → обнаружен AWS-ключ в старом коммите (уже удалённом из кода, но оставшемся в истории).
3. PublicWWW: поиск "AKIA" "example.com" → найден HTML-файл со скриптом, содержащим Google Maps API ключ.
4. Связь: ключи принадлежат компании example.com (проверено по домену в комментариях).
5. Сообщение: отправка письма на security@example.com с перечнем найденных токенов и рекомендацией по их отзыву и ротации.
6. Результат: компания подтвердила получение, отозвала скомпрометированные ключи, обновила политику безопасности.

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

Мониторинг изменений инфраструктуры: уведомления о новых поддоменах, сертификатах, изменениях в DNS

Инфраструктура организации не статична. Появляются новые поддомены, меняются IP-адреса, выпускаются новые сертификаты, обновляются технологии. Для специалиста по техническому OSINT отслеживание этих изменений критически важно: новые поддомены могут раскрыть неанонсированные проекты, свежие сертификаты — указать на новые серверы, а изменения в DNS — на смену хостинг-провайдера или CDN. Мониторинг изменений позволяет реагировать на появление новых активов в реальном времени, не дожидаясь, пока они будут обнаружены случайно. Данная статья посвящена методам и инструментам мониторинга инфраструктуры, а также настройке автоматических уведомлений.

Зачем мониторить изменения?

Типы мониторинга изменений

Этап 1: Мониторинг поддоменов через crt.sh и CertSpotter

crt.sh позволяет выполнять поиск новых сертификатов для домена. Поскольку каждый новый сертификат (и соответственно, поддомен) попадает в CT-логи, crt.sh — идеальный источник для обнаружения новых поддоменов.

Алгоритм мониторинга:

1. Ежедневно выполнять запрос к crt.sh: ?q=%.example.com&output=json.
2. Сравнивать полученный список доменов с предыдущим.
3. При появлении новых — отправлять уведомление.

Пример скрипта для мониторинга поддоменов через crt.sh:

import requests
import json
import time
import hashlib

def get_subdomains(domain):
    url = f"https://crt.sh/?q=%25.{domain}&output=json"
    try:
        resp = requests.get(url, timeout=30)
        if resp.status_code == 200:
            data = resp.json()
            subdomains = set()
            for entry in data:
                name = entry.get('name_value', '')
                if name.endswith(f'.{domain}') or name == domain:
                    subdomains.add(name.lower())
            return sorted(subdomains)
    except Exception as e:
        print(f"Ошибка crt.sh: {e}")
    return []

def monitor_subdomains(domain, state_file='subdomains_state.json'):
    # Загрузка предыдущего состояния
    try:
        with open(state_file, 'r') as f:
            previous = set(json.load(f))
    except:
        previous = set()
    
    # Получение текущего состояния
    current = set(get_subdomains(domain))
    
    # Поиск изменений
    new = current - previous
    removed = previous - current
    
    if new:
        print(f"Новые поддомены: {', '.join(new)}")
        # Здесь отправка уведомления
    if removed:
        print(f"Удалены: {', '.join(removed)}")
    
    # Сохранение состояния
    with open(state_file, 'w') as f:
        json.dump(list(current), f)
    
    return new, removed

# Запуск ежедневно
monitor_subdomains('example.com')

CertSpotter — сервис, который автоматически отслеживает новые сертификаты для указанных доменов и присылает уведомления по email. Бесплатно до 10 доменов.

Как настроить CertSpotter:

1. Зарегистрироваться на sslmate.com/certspotter.
2. Добавить домены для мониторинга.
3. Получать уведомления о новых сертификатах (с указанием SAN и даты истечения).

Этап 2: Мониторинг DNS-изменений

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

Инструменты для мониторинга DNS:

Собственный скрипт для мониторинга DNS-записей(пример):

import dns.resolver
import json
import time

def get_dns_records(domain, record_types=['A', 'MX', 'TXT', 'NS', 'CNAME']):
    records = {}
    for rtype in record_types:
        try:
            answers = dns.resolver.resolve(domain, rtype)
            records[rtype] = [str(r) for r in answers]
        except:
            records[rtype] = []
    return records

def monitor_dns(domain, state_file='dns_state.json'):
    try:
        with open(state_file, 'r') as f:
            previous = json.load(f)
    except:
        previous = {}
    
    current = get_dns_records(domain)
    
    changes = {}
    for rtype in set(previous.keys()) | set(current.keys()):
        prev = previous.get(rtype, [])
        curr = current.get(rtype, [])
        if set(prev) != set(curr):
            changes[rtype] = {
                'old': prev,
                'new': curr
            }
    
    if changes:
        print(f"DNS изменения для {domain}:")
        for rtype, change in changes.items():
            print(f"  {rtype}: {change['old']} → {change['new']}")
        # здесь отправка уведомления
    
    with open(state_file, 'w') as f:
        json.dump(current, f)
    
    return changes

# Запуск
monitor_dns('example.com')

Этап 3: Мониторинг SSL-сертификатов

Новые SSL-сертификаты часто появляются при запуске новых серверов или обновлении старых.

CertSpotter (см. выше) — лучший бесплатный способ мониторинга.

Альтернатива: регулярный запрос к crt.sh с фильтром по дате:

https://crt.sh/?q=%.example.com&exclude=expired&limit=100&output=json

Скрипт для отслеживания сертификатов, истекающих в ближайшее время:

import requests
from datetime import datetime, timedelta

def get_expiring_certs(domain, days=30):
    url = f"https://crt.sh/?q=%25.{domain}&output=json"
    resp = requests.get(url)
    if resp.status_code == 200:
        data = resp.json()
        expiring = []
        now = datetime.now()
        for entry in data:
            if len(entry) < 5:
                continue
            valid_to = entry[4]  # дата истечения
            if valid_to:
                try:
                    exp_date = datetime.strptime(valid_to, '%Y-%m-%dT%H:%M:%S')
                    if (exp_date - now).days < days:
                        expiring.append({
                            'name': entry[1],
                            'expires': valid_to
                        })
                except:
                    pass
        return expiring
    return []

expiring = get_expiring_certs('example.com', 30)
for cert in expiring:
    print(f"Сертификат для {cert['name']} истекает {cert['expires']}")

Этап 4: Мониторинг изменений контента сайта

Изменения на сайте (новые страницы, обновлённый текст, новые файлы) могут указывать на новые проекты, изменения в стратегии или утечку информации.

Инструменты для мониторинга изменений страниц:

Пример использования Changedetection.io (Docker):

docker run -d --name changedetection -p 5000:5000 ghcr.io/dgtlmoon/changedetection.io

Затем через веб-интерфейс добавить URL для мониторинга, настроить интервал проверки и канал уведомлений.

Собственный скрипт мониторинга контента (с хэшированием)

import requests
import hashlib
import json
import time

def fetch_page_hash(url):
    try:
        resp = requests.get(url, timeout=10)
        return hashlib.sha256(resp.text.encode()).hexdigest()
    except:
        return None

def monitor_url(url, state_file='url_state.json'):
    try:
        with open(state_file, 'r') as f:
            state = json.load(f)
            previous_hash = state.get(url)
    except:
        previous_hash = None
    
    current_hash = fetch_page_hash(url)
    if current_hash and current_hash != previous_hash:
        print(f"Страница {url} изменилась!")
        # уведомление
        state[url] = current_hash
        with open(state_file, 'w') as f:
            json.dump(state, f)
        return True
    return False

# Мониторинг нескольких страниц
urls = ['https://example.com', 'https://example.com/about']
for url in urls:
    monitor_url(url)

Этап 5: Мониторинг WHOIS-изменений

Изменения в WHOIS (смена владельца, регистратора, дат) могут указывать на продажу домена или смену контактов.

Инструменты:

• DomainTools (платный мониторинг).
• WhoisXML API (есть платный мониторинг).
• Собственные скрипты через whois и сравнение.

Пример мониторинга WHOIS (с использованием python-whois):

import whois
import json
import time

def get_whois_info(domain):
    try:
        w = whois.whois(domain)
        return {
            'registrar': w.registrar,
            'creation_date': str(w.creation_date),
            'expiration_date': str(w.expiration_date),
            'name_servers': w.name_servers,
            'emails': w.emails
        }
    except:
        return None

def monitor_whois(domain, state_file='whois_state.json'):
    try:
        with open(state_file, 'r') as f:
            previous = json.load(f)
    except:
        previous = {}
    
    current = get_whois_info(domain)
    if current and current != previous:
        print(f"WHOIS для {domain} изменился!")
        # Здесь уведомление
        with open(state_file, 'w') as f:
            json.dump(current, f)
        return True
    return False

monitor_whois('example.com')

Этап 6: Мониторинг технологического стека (Wappalyzer)

Изменения в технологиях могут указывать на обновление CMS, переход на новый фреймворк.

Метод: периодически запускать Wappalyzer CLI и сравнивать результаты.

Пример (через subprocess):

import subprocess
import json

def get_tech_stack(url):
    result = subprocess.run(['wappalyzer', url], capture_output=True, text=True)
    if result.returncode == 0:
        return json.loads(result.stdout)
    return None

# Сравнение результатов за разные даты

Этап 7: Мониторинг через агрегаторы (SecurityTrails, Censys)

SecurityTrails предлагает функцию мониторинга (Alerts) для платных подписок. Вы можете отслеживать:

• Новые поддомены.
• Изменения в DNS-записях.
• Изменения в WHOIS.

Censys позволяет отслеживать изменения в сертификатах и открытых портах.

Этап 8: Настройка уведомлений

После обнаружения изменений важно получать уведомления в удобном формате.

Способы уведомлений:

• Email (через smtplib в Python или сервисы типа SendGrid).
• Telegram Bot (см. код ниже).
• Slack / Discord (вебхуки).
• SMS (платные сервисы).
• Pushover (мобильные уведомления).

Пример уведомления через Telegram-бота:

import requests

def send_telegram_alert(token, chat_id, message):
    url = f"https://api.telegram.org/bot{token}/sendMessage"
    payload = {
        'chat_id': chat_id,
        'text': message
    }
    requests.post(url, json=payload)

# Использование
send_telegram_alert('YOUR_BOT_TOKEN', 'YOUR_CHAT_ID', 'Обнаружены новые поддомены: dev.example.com, test.example.com')

Этап 9: Полный конвейер мониторинга

Для эффективного мониторинга все инструменты можно объединить в единый конвейер:

1. Ежедневный запуск (через cron или Task Scheduler).
2. Проверка поддоменов (crt.sh, SecurityTrails).
3. Проверка DNS (собственный скрипт).
4. Проверка SSL-сертификатов (CertSpotter / crt.sh).
5. Проверка контента (Changedetection.io / собственный скрипт).
6. Проверка WHOIS (собственный скрипт).
7. Сбор изменений в единый отчёт.
8. Отправка уведомления (Telegram, Email).

Пример крона для ежедневного запуска:

0 8 * * * /usr/bin/python3 /path/to/monitor_all.py

Практический пример: мониторинг компании-конкурента

Задача: отслеживать изменения в инфраструктуре конкурента compete.com.

1. Настройка CertSpotter для compete.com и *.compete.com → получение уведомлений о новых сертификатах.
2. Ежедневный скрипт для crt.sh → запись всех поддоменов, сравнение с предыдущим днём. При появлении нового отправка в Telegram.
3. Мониторинг DNS → раз в неделю проверка A, MX, TXT записей. При изменении — уведомление.
4. Мониторинг сайта → Changedetection.io для главной страницы и страницы /careers (появление новых вакансий может указывать на расширение).
5. Обнаружение: спустя неделю появился поддомен app.compete.com. В сертификате указан AWS CloudFront. Это указывает на запуск нового веб-приложения. Мониторинг подтверждает, что сайт стал доступен.
6. Вывод: компания запускает новый продукт. Информация может быть использована для анализа конкурентной среды.

Инструменты для мониторинга (сводная таблица)

• Мониторинг публичных данных (DNS, сертификаты, поддомены, WHOIS) легален.
• Использование автоматизированных скриптов для частых запросов к crt.sh или другим сервисам должно соответствовать их условиям использования (не превышать лимиты).

• Если вы мониторите конкурента, не нарушайте законы о коммерческой тайне и не используйте методы, требующие несанкционированного доступа.

Мониторинг изменений инфраструктуры — это непрерывный процесс, позволяющий быть в курсе всех изменений в цифровых активах цели. Комбинация автоматических скриптов (crt.sh, DNS, WHOIS), готовых сервисов (CertSpotter, Changedetection) и уведомлений (Telegram) создаёт систему раннего обнаружения новых поддоменов, сертификатов, DNS-записей и контента. Это позволяет оперативно реагировать на появление новых проектов, смену хостинга и другие изменения, важные для технической разведки.

Анализ истории сайта: Wayback Machine, изменения контента, скрытые страницы

Веб-сайты постоянно меняются: дизайн обновляется, контент редактируется, страницы удаляются, а новые появляются. Однако интернет «помнит» многие из этих изменений благодаря архивам, таким как Wayback Machine. Для специалиста по техническому OSINT анализ истории сайта — это способ заглянуть в прошлое: восстановить удалённые страницы, найти забытые поддомены, обнаружить конфиденциальную информацию, которая была случайно опубликована, а затем удалена, а также проследить эволюцию политики и контента организации. Данная статья посвящена методам работы с веб-архивами, анализу изменений и поиску скрытых страниц.

Зачем анализировать историю сайта?

Основные архивы веба

Этап 1: Поиск истории сайта в Wayback Machine

Прямой доступ к архиву: https://web.archive.org/web/*/https://example.com

Что можно увидеть:

• Календарь сохранений (синие кружки — даты, когда страница была сохранена).
• Выбор конкретной даты.
• Сравнение двух снимков (инструмент "Compare").
• Доступ к сохранённым изображениям, CSS, JS (частично).

Основные параметры Wayback Machine API:

• https://archive.org/wayback/available?url=https://example.com — проверка, есть ли архив для URL.
• https://web.archive.org/cdx/search/cdx?url=example.com&output=json — список всех сохранений в JSON (для массового сбора).

Пример API-запроса (Python):

import requests
import json

def get_wayback_snapshots(url):
    cdx_url = f"https://web.archive.org/cdx/search/cdx?url={url}&output=json"
    resp = requests.get(cdx_url)
    if resp.status_code == 200:
        data = resp.json()
        if len(data) > 1:
            snapshots = []
            for row in data[1:]:  # первая строка — заголовки
                timestamp = row[1]
                snapshot_url = f"https://web.archive.org/web/{timestamp}/{url}"
                snapshots.append({
                    'timestamp': timestamp,
                    'url': snapshot_url
                })
            return snapshots
    return []

snapshots = get_wayback_snapshots('example.com')
for s in snapshots[:5]:
    print(s['timestamp'], s['url'])

Этап 2: Поиск удалённых страниц и контента

Один из основных способов использования архива — найти страницы, которые были удалены с сайта, но сохранились в Wayback Machine.

Методика:

1. Определить URL-шаблоны (например, /blog/, /docs/, /downloads/).
2. Искать в архиве конкретные URL.
3. Использовать оператор * для поиска всех сохранённых страниц с определённым префиксом.

Пример поиска всех файлов .pdf в архиве:

https://web.archive.org/web/*/https://example.com/*.pdf

Поиск всех страниц в подкаталоге:

https://web.archive.org/web/*/https://example.com/docs/*

Этап 3: Обнаружение скрытых страниц через архивы

Скрытые страницы — те, на которые нет ссылок с главной, но они могут существовать и быть проиндексированы архивом.

Где искать скрытые страницы:

• /admin, /login, /backup, /test, /dev, /staging, /old, /temp, /private.
• Панели управления: /cpanel, /webmail, /plesk, /phpmyadmin.
• Файлы конфигурации: /config, /settings.
• Директории с исходными кодами: /git, /svn, /cvs.

Как искать:

1. Вручную перебирать возможные пути в архиве.
2. Использовать поиск по * или анализировать список всех сохранённых страниц через CDX API.
3. Парсить CDX-вывод и искать подозрительные пути.

Пример CDX-запроса для получения всех страниц сайта (включая подпапки):

curl "https://web.archive.org/cdx/search/cdx?url=example.com/*&output=json" > all_pages.json

Этап 4: Сравнение версий (diff) — что изменилось?

Wayback Machine позволяет сравнивать два снимка страницы. Это полезно для выявления изменений в контенте, политике или структуре.

Инструменты сравнения:

• Веб-интерфейс: https://web.archive.org/web/20200101000000/https://example.com и https://web.archive.org/web/20250101000000/https://example.com → открыть в двух вкладках и сравнить.
• Сторонние утилиты: wget --mirror для загрузки двух архивных версий и сравнения через diff.

Сравнение через Python:

import requests
import difflib

def fetch_archived_page(timestamp, url):
    archive_url = f"https://web.archive.org/web/{timestamp}/{url}"
    resp = requests.get(archive_url)
    return resp.text if resp.status_code == 200 else ""

def compare_pages(url, ts1, ts2):
    text1 = fetch_archived_page(ts1, url)
    text2 = fetch_archived_page(ts2, url)
    diff = difflib.unified_diff(text1.splitlines(), text2.splitlines())
    return '\n'.join(diff)

# Пример
changes = compare_pages('example.com', '20200101000000', '20250101000000')
print(changes[:500])  # первые 500 символов

Этап 5: Поиск старых robots.txt, sitemap.xml и других служебных файлов

robots.txt и sitemap.xml часто меняются. В старых версиях могут содержаться пути, которые позже были удалены.

Пример:

https://web.archive.org/web/*/https://example.com/robots.txt
https://web.archive.org/web/*/https://example.com/sitemap.xml

Что можно найти:

• Директории, запрещённые для индексации (например, /admin/, /private/).
• Поддомены, которые не разрешено индексировать (Disallow: /subdomain/).
• Карта сайта с перечнем всех страниц (удалённые, но сохранённые).

Этап 6: Поиск конфиденциальных данных в архивах

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

Что искать:

• .env (файлы окружения с паролями).
• .git/config (адреса репозиториев).
• phpinfo() (информация о PHP-конфигурации).
• backup.sql (дампы базы данных).
• config.php, settings.php (конфигурационные файлы).

Как искать:

1. Вручную проверять типичные пути: /backup, /tmp, /downloads.
2. Использовать поиск по * и фильтровать по расширениям.
3. Использовать инструменты парсинга архивов для массового поиска.

Пример поиска .env файлов:

https://web.archive.org/web/*/https://example.com/*.env

Wayback Machine не сохраняет все файлы (только HTML, CSS, JS), но дампы баз или бинарные файлы могут быть недоступны.

Этап 7: Анализ изменений в SSL-сертификатах через архивы

Хотя Wayback Machine не сохраняет SSL-сертификаты, история сертификатов доступна через CT-логи (см. статью 7). Однако, анализируя старые снимки сайта, можно заметить:

• Когда на сайте появилась поддержка HTTPS (по редиректам).
• Когда был заменён логотип или изменилась политика безопасности (по заголовкам HTTP в сохранённых снимках, если они есть).

Этап 8: Использование Archive.today для поиска удалённого контента

Archive.today часто сохраняет страницы, которые не попали в Wayback Machine (например, из-за robots.txt). Он позволяет архивировать страницы вручную.

Как использовать:

1. Ввести URL на archive.today.
2. Если страница была сохранена, она отобразится.
3. Можно найти сохранения по дате.

Нет публичного API. Только веб-интерфейс.

Этап 9: Автоматизированный сбор изменений с помощью Wayback Machine API

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

Скрипт мониторинга новых версий:

import requests
import time

def get_latest_snapshot(url):
    # CDX API
    cdx_url = f"https://web.archive.org/cdx/search/cdx?url={url}&output=json&limit=1&sort=timestamp"
    resp = requests.get(cdx_url)
    if resp.status_code == 200:
        data = resp.json()
        if len(data) > 1:
            timestamp = data[1][1]
            return timestamp
    return None

def monitor_website(url, check_interval=86400):  # 1 день
    last_timestamp = None
    while True:
        latest = get_latest_snapshot(url)
        if latest and latest != last_timestamp:
            print(f"Обнаружена новая версия {url} в архиве: {latest}")
            # Здесь можно обработать изменения
            last_timestamp = latest
        time.sleep(check_interval)

Этап 10: Поиск через CDX API для составления карты сайта

CDX API можно использовать для получения полного списка всех когда-либо сохранённых страниц сайта. Это позволяет восстановить структуру сайта даже без текущего доступа.

Получение списка всех страниц (с ограничениями):

curl "https://web.archive.org/cdx/search/cdx?url=example.com/*&output=json&limit=100000" > all_pages.json

Парсинг результатов для построения карты сайта:

import json
import re

def extract_all_paths(cdx_json_file):
    with open(cdx_json_file, 'r') as f:
        data = json.load(f)
    paths = set()
    for row in data[1:]:
        url = row[2]  # полный URL
        # извлекаем путь
        path = re.sub(r'^https?://[^/]+', '', url)
        paths.add(path)
    return sorted(paths)

# Пример использования
paths = extract_all_paths('all_pages.json')
for p in paths[:50]:
    print(p)

Практический пример: полное исследование сайта через архивы

Задача: собрать максимально полную информацию о сайте target.org через архивы.

1. Wayback Machine CDX → получаем список всех 5000 сохранённых страниц.
2. Анализ путей:
• Обнаружены пути /admin, /test, /backup_2022, /temp.
• Страница /admin/login.html существует в архиве с 2020 года.
3. Поиск файлов:
• https://web.archive.org/web/20220101000000/target.org/.git/config — найден конфиг репозитория.
• https://web.archive.org/web/20200101000000/target.org/backup.sql — дамп базы данных.
4. Сравнение версий:
• Сравнили index.html в 2020 и 2024 → структура сильно изменилась, добавилась поддержка HTTPS, появился CSP.
5. Скрытые поддомены:
• На старой robots.txt найдена запись Disallow: /dev/. Открываем архивный URL https://web.archive.org/web/20200101000000/target.org/dev/ → обнаруживаем тестовый сайт с открытыми ошибками PHP.
6. Вывод: Найдены забытые тестовые страницы, конфигурационный файл и дамп базы данных. В текущей версии сайта они удалены, но остались в архиве.

Инструменты для работы с архивами

• Данные Wayback Machine являются публичными, их сбор легален.
• Не используйте найденные уязвимости для атак на сайт без разрешения.
• Если вы нашли конфиденциальные данные (пароли, токены) в архиве, сообщите об этом владельцу сайта через официальный канал (без распространения информации третьим лицам).
• Некоторые страны требуют удаления личных данных из архивов — уважайте такие запросы.

Анализ истории сайта через Wayback Machine и другие архивы — важный этап технического OSINT, позволяющий заглянуть в прошлое веб-ресурса. Удалённые страницы, забытые поддомены, случайно опубликованные конфиденциальные данные, старая robots.txt — всё это может быть восстановлено, если было сохранено в архиве. Комбинируя CDX API, поиск по шаблонам и ручной анализ, исследователь может восстановить почти полную ист

Поиск уязвимостей через открытые источники: базы CVE, NVD, Exploit-DB и связь с версиями ПО

После того как в ходе технического OSINT выявлены версии программного обеспечения, используемого целью (веб-сервер, CMS, библиотеки, операционная система), логичный следующий шаг — выяснить, есть ли у этих версий известные уязвимости. Открытые базы данных уязвимостей (CVE, NVD, Exploit-DB, Vulners и др.) позволяют сопоставить версию ПО с известными CVE (Common Vulnerabilities and Exposures), оценить критичность и даже найти готовые эксплойты. Это помогает понять, насколько цель подвержена атакам, и приоритезировать дальнейшие действия. Данная статья посвящена методам поиска уязвимостей по версиям ПО с использованием открытых источников.

Что такое CVE, CVSS, NVD, Exploit-DB

Зачем это нужно в техническом OSINT?

1. Оценка рисков: понять, насколько критичны уязвимости в используемом ПО.
2. Приоритизация проверок: какие уязвимости следует тестировать в первую очередь.
3. Обнаружение уже скомпрометированных систем: если на целевой системе есть уязвимая версия и известен активный эксплойт — она могла быть взломана.
4. Помощь в легальном пентесте: знание уязвимостей позволяет сосредоточить усилия.

Простое наличие уязвимой версии ПО не означает, что цель автоматически скомпрометирована. Это лишь индикатор потенциальной уязвимости.

Этап 1: Поиск CVE по названию продукта и версии

Самый простой способ — использовать поисковые системы по CVE с фильтрацией.

Основные базы данных:

Поиск по продукту в NVD:

https://nvd.nist.gov/vuln/search/results?query=nginx&results_type=overview

Поиск с версией в NVD (сложно): NVD не всегда индексирует версии, лучше использовать Vulners.

Vulners search (пример):

https://vulners.com/search?query=nginx%201.18.0

Этап 2: Использование Vulners API для массового поиска

Vulners предоставляет бесплатный API с лимитами. Позволяет искать по CPE (Common Platform Enumeration) — стандартизированному формату описания ПО.

Формат CPE: cpe:2.3:a:nginx:nginx:1.18.0:*:*:*:*:*:*:*

Упрощённый поиск через API Vulners:

import requests
import json

VULNERS_API_KEY = "YOUR_API_KEY"

def search_vulnerabilities(product, version, api_key=VULNERS_API_KEY):
    """
    Поиск уязвимостей по названию продукта и версии.
    """
    query = f'{product} {version}'
    url = "https://vulners.com/api/v3/search/lucene/"
    payload = {
        "query": query,
        "apiKey": api_key
    }
    response = requests.post(url, json=payload)
    if response.status_code == 200:
        data = response.json()
        if 'data' in data and 'search' in data['data']:
            return data['data']['search']
    return []

def get_cves_for_software(software_list):
    results = {}
    for sw in software_list:
        cves = search_vulnerabilities(sw['name'], sw['version'])
        results[f"{sw['name']} {sw['version']}"] = cves
    return results

# Пример
software = [
    {'name': 'nginx', 'version': '1.18.0'},
    {'name': 'php', 'version': '7.4.33'},
    {'name': 'wordpress', 'version': '6.2'}
]
vulns = get_cves_for_software(software)
for k, v in vulns.items():
    print(f"{k}: {len(v)} vulnerabilities")

Этап 3: Использование CIRCL CVE Search API (без ключа)

CIRCL предлагает публичный API, не требующий авторизации.

Пример запроса для поиска CVE по ключевому слову nginx:

curl https://cve.circl.lu/api/search/nginx

Для извлечения информации о конкретном CVE:

curl https://cve.circl.lu/api/cve/CVE-2021-23017

CIRCL не позволяет фильтровать по версии, ищет по тексту.

Этап 4: Поиск эксплойтов (Exploit-DB, Rapid7, Packet Storm)

Наличие эксплойта повышает вероятность того, что уязвимость будет использована.

Exploit-DB:

• Поиск по продукту и версии: https://www.exploit-db.com/search?q=nginx+1.18.0
• Можно скачать готовый код (на свой страх и риск).

Rapid7 DB (Metasploit modules):

• Поиск: https://www.rapid7.com/db/search/?q=nginx

Packet Storm Security:

• https://packetstormsecurity.com/search/?q=nginx

Пример автоматизации через Exploit-DB (неофициальный API, лучше парсить):

import requests
from bs4 import BeautifulSoup

def search_exploitdb(product, version):
    url = f"https://www.exploit-db.com/search?q={product}+{version}"
    resp = requests.get(url)
    soup = BeautifulSoup(resp.text, 'html.parser')
    # Парсинг таблицы результатов (сложно, зависит от структуры)
    # Возвращает список заголовков эксплойтов
    return []

# Ручной поиск вручную часто проще

Этап 5: Сопоставление версий ПО с CPE для точного поиска

Чтобы искать CVE, лучше преобразовать название и версию в CPE-формат. Это повышает точность.

Сервис CPE Dictionary (NVD):

• https://nvd.nist.gov/products/cpe/search
• API: https://services.nvd.nist.gov/rest/json/cpes/2.0?keyword=nginx

Автоматическое определение CPE через cpe-guesser (исследовательский):

def guess_cpe(product, version):
    # упрощённый пример
    product_lower = product.lower()
    if product_lower == 'nginx':
        return f"cpe:2.3:a:nginx:nginx:{version}:*:*:*:*:*:*:*"
    elif product_lower == 'wordpress':
        return f"cpe:2.3:a:wordpress:wordpress:{version}:*:*:*:*:*:*:*"
    # ...
    return None

Этап 6: Анализ CVSS (критичность уязвимости)

Каждому CVE присваивается оценка CVSS. Чем выше, тем критичнее.

CVSS v3 шкала:

Вектор CVSS (пример): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H означает: сетевой доступ, низкая сложность, не требуется привилегий, полное воздействие на конфиденциальность, целостность и доступность.

Где брать CVSS: NVD, Vulners, некоторые API.

Этап 7: Автоматизированный сбор уязвимостей для всех технологий стека

Комбинируем результаты предыдущих статей (технологический стек) с базами уязвимостей.

Python-скрипт для массовой проверки (на основе данных из Wappalyzer, BuiltWith):

import requests
import time
import json

def get_cves_from_nvd(keyword, api_key=None):
    """
    Поиск в NVD через API (требуется ключ, можно получить бесплатно).
    Без ключа возвращает только первые 20 результатов.
    """
    url = "https://services.nvd.nist.gov/rest/json/cves/2.0"
    params = {
        'keywordSearch': keyword,
        'resultsPerPage': 10
    }
    if api_key:
        params['apiKey'] = api_key
    response = requests.get(url, params=params)
    if response.status_code == 200:
        data = response.json()
        cves = []
        for vuln in data.get('vulnerabilities', []):
            cve_id = vuln['cve']['id']
            cvss_score = vuln['cve'].get('metrics', {}).get('cvssMetricV31', [{}])[0].get('cvssData', {}).get('baseScore', 'N/A')
            cves.append({'id': cve_id, 'cvss_score': cvss_score})
        return cves
    else:
        print(f"Ошибка NVD: {response.status_code}")
        return []

# Пример для nginx 1.18.0
cves = get_cves_from_nvd("nginx 1.18.0")
for cve in cves:
    print(f"{cve['id']} (CVSS {cve['cvss_score']})")

NVD API имеет rate limit (без ключа ~5 запросов в 30 секунд). Используйте ключ или библиотеку с задержками.

Этап 8: Поиск уязвимостей в WordPress плагинах и темах

WordPress — особая категория: уязвимости часто связаны с плагинами и темами, а не с ядром.

Базы для WordPress:

• WPScan Vulnerability Database: https://wpscan.com/api (есть бесплатный API с ограничениями).
• Patchstack: https://patchstack.com/database/

Пример поиска через WPScan API:

def check_wpscan_plugin(plugin_slug):
    url = f"https://wpscan.com/api/v3/plugins/{plugin_slug}"
    response = requests.get(url)
    if response.status_code == 200:
        data = response.json()
        return data.get('vulnerabilities', [])
    return []

Этап 9: Анализ базы Known Exploited Vulnerabilities (CISA KEV)

CISA ведёт список активно эксплуатируемых уязвимостей (KEV). Если CVE есть в этом списке, оно представляет большую угрозу.

API KEV: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

def is_in_kev(cve_id):
    url = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
    resp = requests.get(url)
    if resp.status_code == 200:
        data = resp.json()
        for item in data['vulnerabilities']:
            if item['cveID'] == cve_id:
                return True
    return False

Этап 10: Составление отчёта об уязвимостях

Для каждой версии ПО, найденной на цели, следует создать таблицу:

Суммировать количество критических уязвимостей, наличие эксплойтов, попадание в KEV.

Практический пример: оценка рисков для веб-сервера цели

Задача: для сервера nginx 1.18.0 + PHP 7.4.33 найти известные уязвимости.

1. Поиск через Vulners:
• nginx 1.18.0: 3 CVE, все с CVSS ниже 6.0. Эксплойтов нет.
• PHP 7.4.33: 12 CVE, из них 4 с CVSS > 7.0. Один эксплойт в Metasploit.
2. Проверка CISA KEV: PHP 7.4.33 не в списке KEV.
3. Вывод: основной риск — уязвимости PHP (особенно CVE-2022-31628, позволяющая удалённое выполнение кода). Рекомендуется обновить PHP до 8.x.

• Поиск уязвимостей в открытых базах данных легален.
• Запуск эксплойтов на целевой системе без разрешения — уголовное преступление.
• Обнаруженную уязвимость следует сообщить владельцу системы через программы Bug Bounty или координаторы (CERT).
• Не следует тестировать эксплойты на чужих системах.

Поиск уязвимостей по версиям ПО — неотъемлемая часть технического OSINT. Базы CVE, NVD, Vulners, Exploit-DB и CISA KEV дают исследователю возможность оценить поверхность атаки, не прибегая к активным сканерам уязвимостей. Сопоставление версий из предыдущих статей (технологический стек, версии ПО, заголовки) с уязвимостями позволяет построить рейтинг рисков и определить приоритет для дальнейшего тестирования.

Анализ заголовков HTTP: серверы, cookies, политики безопасности (CSP, HSTS, X-Frame-Options и другие)

HTTP-заголовки — это метаданные, которыми обмениваются клиент (браузер) и сервер при каждом запросе. Для специалиста по техническому OSINT заголовки — ценный источник информации: они раскрывают версии программного обеспечения, используемые технологии, настройки безопасности и даже особенности конфигурации. Помимо этого, заголовки безопасности (CSP, HSTS, X-Frame-Options) позволяют оценить уровень защищённости веб-приложения и выявить потенциальные уязвимости. Данная статья посвящена методам сбора и анализа HTTP-заголовков, а также извлечению разведывательной информации из них.

Почему HTTP-заголовки важны для технического OSINT?

Этап 1: Сбор заголовков (базовые инструменты)

1. curl — самый простой способ:

# Показать только заголовки ответа
curl -I https://example.com

# Показать заголовки запроса и ответа
curl -v https://example.com

# Сохранить заголовки в файл
curl -D headers.txt https://example.com

2. wget:

wget --server-response -O /dev/null https://example.com

3. Browser DevTools (F12 → Network → выбрать запрос → Headers).

4. Онлайн сервисы:

• SecurityHeaders.com — проверяет наличие и корректность заголовков безопасности, выставляет оценку.
• HTTPHeaderCheck (httpheadercheck.com) — анализирует заголовки и даёт рекомендации.
• Mozilla Observatory — глубокий анализ безопасности с рекомендациями.

Этап 2: Анализ идентификационных заголовков

Эти заголовки могут выдать технологии, версии ПО, что полезно для обнаружения устаревших или уязвимых компонентов.

Server:

• Указывает тип и версию веб-сервера. Примеры: nginx/1.18.0, Apache/2.4.41 (Ubuntu), Microsoft-IIS/10.0, Cloudflare.
• Часто скрывается администраторами (Server: Apache, без версии). Если версия показана — сверьте с базами уязвимостей.

X-Powered-By:

• Показывает технологию бэкенда. Например: PHP/7.4.33, ASP.NET, Express. Может дать версию языка/фреймворка.

X-Generator:

• Иногда содержит название CMS или генератора контента (например, WordPress 6.2).

X-AspNet-Version:

• Для ASP.NET. Пример: X-AspNet-Version: 4.0.30319.

X-Powered-By-Plesk: (если используется панель управления хостингом).

Этап 3: Анализ cookie и сессионных заголовков

Заголовок Set-Cookie не только управляет сессиями, но и выдаёт технологии.

Set-Cookie:

• PHPSESSID=... → PHP (версия сессионного механизма).
• JSESSIONID=... → Java (JSP).
• ASPSESSIONID... → ASP.NET.
• laravel_session=... → Laravel (PHP-фреймворк).
• XSRF-TOKEN → часто используется в Angular, Laravel, Django.

Флаги cookie (httponly, secure, samesite):

• HttpOnly — недоступен для JavaScript (хорошо для безопасности).
• Secure — только через HTTPS.
• SameSite=Lax/Strict — защита от CSRF.

Этап 4: Заголовки безопасности (Security Headers)

Оценка безопасности веб-приложения — важная часть разведки. Слабые настройки могут привести к уязвимостям (кликджекинг, XSS, перехват сессий).

4.1. Content-Security-Policy (CSP)

CSP — белый список источников загрузки ресурсов (скриптов, стилей, изображений). Хорошо настроенный CSP сильно уменьшает риск XSS.

Анализ CSP:

• default-src 'none' — жёсткая политика.
• script-src 'self' — разрешены скрипты только с того же домена.
• unsafe-inline, unsafe-eval — опасные директивы, делают CSP бесполезным.
• report-uri /report-csp-violation — куда отправлять отчёты о нарушениях.

Ошибки:

• Отсутствие CSP — распространённая проблема.
• Наличие unsafe-inline без nonce/hash — снижает защиту.
• Слишком широкие источники (*.example.com, https:).

4.2. HSTS (HTTP Strict Transport Security)

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

Пример: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Анализ:

• max-age=0 — отключено (опасно).
• includeSubDomains — принудительный HTTPS для всех поддоменов.
• preload — домен включён в предзагружаемый список браузеров (максимальный уровень).
• Отсутствие HSTS — возможность атаки «понижения до HTTP» (SSL stripping).

4.3. X-Frame-Options

Защита от кликджекинга (встраивания сайта в frame).

Значения:

• DENY — запрещено встраивание в frame.
• SAMEORIGIN — разрешено только с того же домена.
• ALLOW-FROM uri — устаревшее.
• Отсутствие заголовка — сайт можно встроить в <iframe> (угроза UI redressing).

4.4. X-Content-Type-Options

Защита от MIME-тип-путаницы (MIME sniffing).

Единственное допустимое значение: nosniff. Если отсутствует — браузер может выполнить script, даже если тип указан как текст.

4.5. X-XSS-Protection

Старый заголовок для защиты от XSS (в основном для старых браузеров).

Значения:

• 1; mode=block — блокировать страницу при обнаружении XSS.
• 1 — попытаться очистить (менее безопасно).
• 0 — отключено.

В современных браузерах во многом заменён CSP, но его наличие всё же полезно.

4.6. Referrer-Policy

Контролирует передачу referer при переходе по ссылкам.

Настройки:

• no-referrer — вообще не передавать.
• strict-origin — передавать только схему и домен (при HTTPS→HTTPS).
• unsafe-url — всегда передавать полный URL (опасно, утечка параметров).

4.7. Feature-Policy / Permissions-Policy

Ограничивает доступ к функциям браузера (камера, микрофон, геолокация). Может содержать информацию о политиках организации.

Этап 5: Заголовки, указывающие на CDN, прокси, кэширование

Эти заголовки помогают понять, скрыт ли реальный IP сервера за CDN, используется ли балансировка, кэширование.

Cloudflare:

• CF-Cache-Status (HIT, MISS, EXPIRED, DYNAMIC).
• CF-RAY.
• CF-Connection-Connecting.

Akamai:

• X-Akamai-Transformed, X-Akamai-Cache-Status.

AWS CloudFront:

• X-Amz-Cf-Id, X-Cache (Hit from cloudfront).

Varnish:

• X-Varnish, X-Cache (HIT, MISS).

Этап 6: Анализ заголовков на предмет утечки внутренней информации

Некоторые заголовки могут раскрывать внутреннюю инфраструктуру:

• X-Backend-Server — имя внутреннего сервера.
• X-Debug-Token, X-Debug-Token-Link — утечка отладочной информации.
• X-Server-Name — имя сервера внутри сети.
• X-Forwarded-For (иногда) — реальный IP клиента, но может содержать IP прокси.
• Via — прокси-серверы (например, Via: 1.1 varnish).

Если увидели X-Backend-Server: web01.internal.company.com — это очень ценно: можно узнать внутреннюю структуру и возможные имена хостов.

Этап 7: Инструменты для массового сбора заголовков

Httpx (от ProjectDiscovery) — быстрый HTTP-клиент, собирает заголовки, извлекает технологии, поддерживает вывод в JSON.

httpx -u https://example.com -sc -title -tech-detect -json -o headers.json

HTTPX (Python-библиотека) — позволяет автоматизировать запросы:

import httpx

def get_headers(url):
    try:
        response = httpx.get(url, follow_redirects=True, timeout=10)
        headers = dict(response.headers)
        # дополнительные данные
        headers['_status_code'] = response.status_code
        headers['_url'] = str(response.url)
        return headers
    except Exception as e:
        return {'_error': str(e)}

# Пример для одного сайта
print(get_headers('https://example.com'))

Этап 8: Автоматический анализ с помощью SecurityHeaders.com API

SecurityHeaders.com предоставляет API для оценки заголовков.

curl https://securityheaders.com/?q=https://example.com&hide=on

Ответ — HTML, но можно парсить. Оценка от A+ до F (рекомендуется A).

Пример из утилиты: можно использовать curl и grep для извлечения рейтинга.

Этап 9: Оценка качества и потенциальных уязвимостей по заголовкам

Недостатки в заголовках безопасности могут указывать на слабую защиту:

• Нет HSTS → риск с stripping (особенно для сайтов с логинами).
• Нет CSP → уязвимость XSS.
• Нет X-Frame-Options → риск кликджекинга.
• Наличие X-Powered-By с точной версией → может помочь злоумышленнику (но не является уязвимостью).

Практический пример: разбор заголовков сайта с логином

Задача: проверить защищённость сайта login.target.com по заголовкам.

1. Запрос заголовков:textcurl -I https://login.target.comОтвет:textHTTP/2 200 server: nginx/1.22.0 x-powered-by: PHP/7.4.33 set-cookie: PHPSESSID=abc123; path=/; HttpOnly; Secure strict-transport-security: max-age=0 x-frame-options: DENY x-content-type-options: nosniff x-xss-protection: 1; mode=block content-security-policy: default-src 'self'
2. Анализ:
• server: nginx/1.22.0 — версия Nginx актуальна на момент проверки.
• x-powered-by: PHP/7.4.33 — PHP 7.4.33 EOL? Проверить (на момент написания 7.4 достиг EOL, могут быть уязвимости).
• PHPSESSID с HttpOnly; Secure — хорошо.
• strict-transport-security: max-age=0 — HSTS выключен! Очень плохо для страницы логина.
• CSP: default-src 'self' — хорошо, но лучше конкретные директивы.
3. Рекомендации:
• Включить HSTS с долгим max-age.
• Обновить PHP до поддерживаемой версии.
• Расширить CSP, запретив inline-скрипты.

Этап 10: Мониторинг изменений заголовков

Заголовки могут меняться со временем: администраторы могут включить HSTS, изменить версии ПО. Мониторинг изменений помогает отслеживать обновления безопасности.

Как организовать мониторинг:

• Периодически запрашивать заголовки (раз в день, раз в неделю).
• Сравнивать хэши ответов (или конкретных заголовков).
• При изменении — уведомление.

Python-скрипт мониторинга:

import hashlib
import httpx
import time

def fetch_headers_hash(url):
    response = httpx.get(url, follow_redirects=True)
    # конкатенируем все заголовки в строку
    headers_str = str(sorted(response.headers.items()))
    return hashlib.sha256(headers_str.encode()).hexdigest()

def monitor(url, interval_hours=24):
    last_hash = None
    while True:
        current_hash = fetch_headers_hash(url)
        if last_hash is None:
            last_hash = current_hash
            print(f"Initial hash: {current_hash}")
        elif current_hash != last_hash:
            print(f"Headers changed for {url}!")
            # здесь можно отправить уведомление
            last_hash = current_hash
        time.sleep(interval_hours * 3600)

Этические и правовые ограничения

• Сбор заголовков с помощью curl/httpx — это обычный HTTP-запрос, который не нарушает закон (аналогично посещению сайта браузером).
• Использование SecurityHeaders.com и аналогичных сервисов также легально.
• Массовый сбор заголовков (тысячи доменов) может привести к блокировке IP, если сайт расценит это как сканирование. Используйте разумные интервалы.
• Анализ заголовков безопасности не даёт права атаковать сайт. Информация используется для оценки защищённости (в рамках разрешённого тестирования).

HTTP-заголовки — богатый источник информации при пассивном техническом OSINT. Идентификационные заголовки (Server, X-Powered-By) раскрывают версии ПО, что позволяет искать уязвимости. Заголовки cookie указывают на используемые технологии и фреймворки. Заголовки безопасности (CSP, HSTS, X-Frame-Options) оценивают защищённость веб-приложения. Заголовки кэширования и прокси помогают определить CDN и скрыть реальный IP. Комбинация этих данных с результатами других статей цикла даёт наиболее полную картину инфраструктуры цели.