Shadow

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

2026-07-06T05:11:38.614Z

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

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

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

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

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

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

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

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

Пример скрипта для мониторинга поддоменов через 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:

Зарегистрироваться на sslmate.com/certspotter.
Добавить домены для мониторинга.
Получать уведомления о новых сертификатах (с указанием 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: Полный конвейер мониторинга

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

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

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

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

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

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

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

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

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

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

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

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

2026-06-27T17:59:12.899Z

Анализ истории сайта: 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.

Методика:

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

Пример поиска всех файлов .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.

Как искать:

Вручную перебирать возможные пути в архиве.
Использовать поиск по * или анализировать список всех сохранённых страниц через CDX API.
Парсить 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 (конфигурационные файлы).

Как искать:

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

Пример поиска .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). Он позволяет архивировать страницы вручную.

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

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

Нет публичного 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 через архивы.

Wayback Machine CDX → получаем список всех 5000 сохранённых страниц.
Анализ путей:

Обнаружены пути /admin, /test, /backup_2022, /temp.
Страница /admin/login.html существует в архиве с 2020 года.

Поиск файлов:

https://web.archive.org/web/20220101000000/target.org/.git/config — найден конфиг репозитория.
https://web.archive.org/web/20200101000000/target.org/backup.sql — дамп базы данных.

Сравнение версий:

Сравнили index.html в 2020 и 2024 → структура сильно изменилась, добавилась поддержка HTTPS, появился CSP.

Скрытые поддомены:

На старой robots.txt найдена запись Disallow: /dev/. Открываем архивный URL https://web.archive.org/web/20200101000000/target.org/dev/ → обнаруживаем тестовый сайт с открытыми ошибками PHP.

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

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

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

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

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

2026-06-27T16:28:23.150Z

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

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

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

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

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

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

Этап 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 найти известные уязвимости.

Поиск через Vulners:

nginx 1.18.0: 3 CVE, все с CVSS ниже 6.0. Эксплойтов нет.
PHP 7.4.33: 12 CVE, из них 4 с CVSS > 7.0. Один эксплойт в Metasploit.

Проверка CISA KEV: PHP 7.4.33 не в списке KEV.
Вывод: основной риск — уязвимости PHP (особенно CVE-2022-31628, позволяющая удалённое выполнение кода). Рекомендуется обновить PHP до 8.x.

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

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

Анализ заголовков HTTP: серверы, cookies, политики безопасности

2026-06-24T08:29:47.248Z

Анализ заголовков 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 по заголовкам.

Запрос заголовков: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'
Анализ:

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' — хорошо, но лучше конкретные директивы.

Рекомендации:

Включить 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. Комбинация этих данных с результатами других статей цикла даёт наиболее полную картину инфраструктуры цели.

Технологический стек сайтов: Wappalyzer, BuiltWith, определение CMS и библиотек

2026-06-20T06:34:15.280Z

Технологический стек сайтов: Wappalyzer, BuiltWith, определение CMS и библиотек

Веб-сайты редко создаются с нуля. Они собираются из компонентов: систем управления контентом (CMS), фреймворков, библиотек JavaScript, аналитических платформ, рекламных сетей и т.д. Знание технологического стека цели позволяет не только понять её архитектуру, но и выявить уязвимости (устаревшие версии WordPress, известные уязвимости jQuery), а также получить подсказки о бюджете, кадровом составе и используемых облачных сервисах. Определение стека возможно пассивно (по заголовкам, HTML-коду, паттернам) или активно (запросы к специальным файлам). Данная статья посвящена методам и инструментам идентификации технологий веб-сайтов.

Категории технологий, которые можно определить

Этап 1: Пассивное определение через HTTP-заголовки

Самый простой метод — отправить HTTP-запрос к сайту и проанализировать заголовки ответа.

Что дают заголовки:

Server — тип и версия веб-сервера (например, nginx/1.18.0).
X-Powered-By — технология бэкенда (PHP/7.4, ASP.NET).
X-CMS — иногда CMS указывает себя (редко).
Set-Cookie — может содержать идентификаторы CMS (например, wp-settings-1 для WordPress).
X-Drupal-Cache, X-Generator, X-Request-ID и др.

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

curl (командная строка): curl -I https://example.com
Browser DevTools (вкладка Network).
Online сервисы: SecurityHeaders.io, HTTPHeaderCheck.

Пример curl:

curl -I https://www.example.com

Анализ cookies:

PHPSESSID → PHP.
JSESSIONID → Java (JSP).
ASPSESSIONID → ASP.NET.
wp-settings-*, wordpress_logged_in_* → WordPress.
laravel_session → Laravel.

Этап 2: Автоматические детекторы (Wappalyzer, BuiltWith, WhatRuns)

Wappalyzer — расширение для браузера (и CLI-инструмент), определяющее технологии по множеству сигнатур: HTML, JavaScript, заголовки, паттерны URL, meta-теги.

Как установить:

Расширение для Chrome/Firefox (бесплатно).
CLI-версия: npm install -g wappalyzer.

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

wappalyzer https://example.com

Пример вывода (сокращённо):

{
  "url": "https://example.com",
  "technologies": [
    {"name": "Nginx", "version": "1.18.0"},
    {"name": "PHP", "version": "7.4.33"},
    {"name": "WordPress", "version": "6.2"},
    {"name": "jQuery", "version": "3.6.0"},
    {"name": "Google Analytics", "id": "UA-12345678-1"}
  ]
}

BuiltWith — онлайн-сервис, который не только определяет технологии, но и показывает историю их использования, а также другие домены, использующие те же идентификаторы (например, Google Analytics ID). Платный API позволяет массовые запросы.

Как использовать BuiltWith бесплатно:

Ввести URL на builtwith.com.
Получить подробный отчёт: веб-сервер, CMS, аналитика, виджеты, хостинг, SSL-провайдер.

Что можно найти через BuiltWith:

Связанные сайты по общему Google Analytics ID или AdSense ID.
Пересечения по хостингу, IP.
Историю изменений технологий.

WhatRuns — аналог Wappalyzer, но с фокусом на библиотеки фронтенда. Есть веб-интерфейс и расширение.

Сравнение детекторов:

Этап 3: Определение CMS по характерным путям и файлам

Каждая CMS имеет уникальную структуру URL, файлы и мета-теги.

WordPress:

/wp-admin, /wp-content, /wp-includes
Generator мета-тег: <meta name="generator" content="WordPress X.X.X">
Файл /wp-login.php
Robots.txt часто содержит Disallow: /wp-admin/

Drupal:

/sites/default/files, /core, /modules
Generator мета-тег: <meta name="Generator" content="Drupal X (http://drupal.org)">
Страница /user/login

Joomla:

/administrator, /media, /components
Мета-тег: <meta name="generator" content="Joomla! - Open Source Content Management">
Robots.txt: Disallow: /administrator/

Bitrix (1С-Битрикс):

/bitrix, /bitrix/admin
/bitrix/tools, /bitrix/js
Мета-тег: редко указывает версию.

Tilda (тильда):

URL с project123456.tilda.ws или кастомный домен, но в коде есть //tilda.cc
Блоки .t396, .t-carousel

Этап 4: Определение версии CMS

Версия может быть указана в:

Meta-теге generator (WordPress, Drupal, иногда Joomla).
Файле readme.html или readme.txt в корне (WordPress, Drupal).
Странице /wp-admin/ в HTML-комментариях (WordPress).
Специфических файлах стилей (например, /wp-content/themes/twentytwenty/style.css содержит Version:).

Пример получения версии WordPress:

curl -s https://example.com/readme.html | grep -i "Version"

или

curl -s https://example.com/wp-content/themes/twentytwenty/style.css | grep -i "Version:"

Ограничения: версии могут быть скрыты или изменены.

Этап 5: Анализ фронтенд-библиотек

Библиотеки JavaScript часто оставляют следы в глобальных объектах, версиях в исходном коде, а также в путях к файлам.

Способы определения:

Браузерная консоль: ввести jQuery().jquery (если jQuery загружен), React.version, Vue.version.
Поиск в исходном коде страницы: //ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js
Проверка на уязвимости: Retire.js (расширение для браузера) или CLI.

Retire.js CLI:

npm install -g retire
retire --url https://example.com

Этап 6: Определение хостинга и CDN

Хостинг:

whois IP покажет организацию.
BuiltWith в разделе "Hosting".
Поиск по IP в Shodan → раздел "org".

CDN:

Проверить наличие заголовка CF-Cache-Status (Cloudflare).
Наличие X-Cache, X-Cache-Hits (Akamai, AWS CloudFront).
CNAME записи: например, cdn.example.com CNAME cdn.shopify.com.

Список известных CDN:

Cloudflare (IP-диапазоны публикуются)
Akamai
Amazon CloudFront (.cloudfront.net)
Fastly
StackPath

Этап 7: Определение аналитических систем (Google Analytics, Yandex.Metrica)

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

Как найти ID:

Поиск в HTML-коде: UA-12345678-1 (Google Analytics Universal), G-XXXXXXXX (GA4).
Для Яндекс.Метрики: <meta name="yandex-verification" content="..."> или Ya.Metrika.informer.

Поиск по идентификатору через BuiltWith:

Ввести UA-12345678-1 в поисковую строку BuiltWith → список сайтов с этим ID.

Google Analytics ID может быть одинаковым для нескольких доменов одной компании.

Этап 8: Обнаружение скрытых директорий и файлов (active)

Это уже активный метод, но его можно использовать с разрешения. Инструменты: Dirb, Gobuster, FFUF.

Пример Gobuster:

gobuster dir -u https://example.com -w /usr/share/wordlists/dirb/common.txt

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

/phpmyadmin, /adminer, /pma — инструменты управления БД.
/git, /.git/config — утечка репозитория.
/backup, /old — старые версии сайта.
/api — API-эндпоинты.

Важно: не сканируйте чужие сайты без разрешения.

Этап 9: Объединение данных с другими источниками

Технологический стек дополняет картину, полученную из DNS, поддоменов и сканирования портов.

Практический пример: полный разбор веб-инфраструктуры

Задача: охарактеризовать сайт target.org.

HTTP-заголовки:

Server: nginx/1.22.1
X-Powered-By: PHP/8.1.2
Set-Cookie: PHPSESSID=... → PHP.

Wappalyzer:

CMS: Drupal 9.5
Фронтенд: jQuery 3.6.0, Bootstrap 4.6
Аналитика: Google Analytics (UA-12345678-1)

BuiltWith:

Хостинг: Amazon AWS (us-east-1)
CDN: CloudFront
SSL: Let's Encrypt
Ecommerce: нет.

Поиск по Google Analytics ID через BuiltWith:

Найдены ещё два сайта: other.target.org и blog.target.org. Оба на Drupal, тот же хостинг.

Проверка версии Drupal:

/README.txt → Drupal 9.5.3.
/core/CHANGELOG.txt → подтверждает.

Анализ фронтенда:

jQuery 3.6.0 (без уязвимостей).
Bootstrap 4.6 (устаревший, но не критично).

CDN:

IP-адрес сайта скрыт за CloudFront (проверено через dig A target.org → IP принадлежит AWS CloudFront).
Но есть другие поддомены, указывающие на реальные IP (можно найти через SecurityTrails).

Вывод: организация использует AWS с CloudFront, Drupal 9.5, имеет связанные сайты. Версия Drupal 9.5.x имеет несколько известных уязвимостей (CVE-2023-XXXX), требуется обновление. Google Analytics ID связывает три сайта, что указывает на единую структуру.

Автоматизация: сбор технологического стека через API Wappalyzer

import json
import requests

def wappalyzer_detect(url):
    # Wappalyzer CLI (если установлен) или можно использовать их API (платно)
    # Пример через subprocess
    import subprocess
    result = subprocess.run(['wappalyzer', url], capture_output=True, text=True)
    if result.returncode == 0:
        return json.loads(result.stdout)
    else:
        return None

def builtwith_lookup(url):
    # BuiltWith API (требуется ключ)
    api_key = "YOUR_API_KEY"
    endpoint = f"https://api.builtwith.com/free1/api.json?KEY={api_key}&LOOKUP={url}"
    resp = requests.get(endpoint)
    if resp.status_code == 200:
        return resp.json()
    return None

# Пример
tech = wappalyzer_detect("https://example.com")
print(json.dumps(tech, indent=2))

Определение технологического стека через пассивные методы (заголовки, HTML) — легально.
Активный поиск файлов (Dirb, Gobuster) — требует разрешения владельца.
Использование BuiltWith для поиска по ID (Google Analytics) легально, но может быть сочтено навязчивым, если используется для массового сбора данных.

Идентификация технологического стека — обязательный этап при исследовании веб-приложения. Wappalyzer и BuiltWith автоматизируют большую часть работы. Важно не только определить технологии, но и оценить версии (особенно устаревшие) и выявить связи по аналитическим идентификаторам. Эта информация может привести к обнаружению других активов организации. В связке с SSL-сертификатами, поддоменами и портами технологический стек закрывает ещё одну часть пазла внешней инфраструктуры.

Анализ SSL/TLS сертификатов: Certificate Transparency logs, выявление скрытых хостов

2026-06-14T05:45:48.647Z

Анализ SSL/TLS сертификатов: Certificate Transparency logs, выявление скрытых хостов

Введение

SSL/TLS сертификаты — это цифровые удостоверения, которые обеспечивают шифрование соединений и подтверждают подлинность веб-сайтов. В контексте технического OSINT сертификаты становятся золотоносной жилой: они часто содержат имена доменов и поддоменов, которые не видны в DNS, а также могут раскрывать внутренние и тестовые хосты организации. Благодаря механизму Certificate Transparency (CT), каждый выданный сертификат публикуется в публичных логах, доступных для поиска. Данная статья посвящена методам анализа сертификатов, использованию CT-логов и выявлению скрытых активов.

Что такое Certificate Transparency (CT)?

CT — это открытая система аудита сертификатов, созданная для обнаружения ошибочных или злонамеренно выданных сертификатов. Когда центр сертификации (CA) выпускает сертификат, он обязан отправить его в несколько публичных CT-логов. Логи неизменяемы и доступны для всех. Благодаря этому любой исследователь может найти все сертификаты, выданные для домена (или любого шаблона), включая сертификаты для внутренних поддоменов, которые никогда не публиковались в DNS.

Почему сертификаты ценны для OSINT?

Основные источники CT-логов

Этап 1: Базовый поиск сертификатов через crt.sh

crt.sh (https://crt.sh) — это общедоступный интерфейс к CT-логам. Проще всего начать с запроса:

https://crt.sh/?q=%.example.com

где % заменяет любой префикс. Этот запрос найдёт все сертификаты, содержащие строку example.com в любом поле (name_value).

Параметры crt.sh:

q — поисковый запрос (можно использовать SQL-подобные операторы).
excluded — исключить мёртвые сертификаты (expired, revoked).
output — формат вывода (json, csv, html).
limit — количество результатов (по умолчанию 2000).

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

?q=example.com — ищет точное совпадение в любом поле.
?q=%.example.com — ищет все поддомены.
?q=*.example.com — ищет wildcard-сертификаты.
?q=example.com&excluded=expired — исключить истекшие.

Использование API crt.sh (JSON):

https://crt.sh/?q=%.example.com&output=json

Python-функция для получения сертификатов:

import requests
import json

def get_certificates(domain, exclude_expired=True):
    url = f"https://crt.sh/?q=%25.{domain}&output=json"
    if exclude_expired:
        url += "&excluded=expired"
    resp = requests.get(url)
    if resp.status_code == 200:
        try:
            data = resp.json()
            # crt.sh возвращает список списков, каждый подсписок — запись
            # Поля: idx, name, issuer, validity_start, validity_end, ca, cert
            certs = []
            for row in data:
                cert = {
                    'name': row[1],
                    'issuer': row[2],
                    'valid_from': row[3],
                    'valid_to': row[4],
                    'ca': row[5],
                    'certificate': row[6]
                }
                certs.append(cert)
            return certs
        except:
            return []
    return []

certs = get_certificates("example.com")
for c in certs:
    print(c['name'], c['valid_to'])

Этап 2: Извлечение доменов из Subject Alternative Names (SAN)

Большинство современных сертификатов используют расширение SAN (Subject Alternative Names), которое содержит список всех имён, для которых действителен сертификат. Это наиболее ценный источник поддоменов.

Пример записи SAN из crt.sh:

name_value: example.com
           www.example.com
           mail.example.com
           admin.example.com
           *.example.com

Обратите внимание, что *.example.com — wildcard-сертификат, который покрывает все поддомены первого уровня. Однако с 2023 года некоторые CA начали ограничивать выдачу wildcard-сертификатов.

Как извлечь все уникальные имена из набора сертификатов:

def extract_domains(certificates):
    domains = set()
    for cert in certificates:
        names = cert['name'].split('\n')  # часто имена разделены \n
        for name in names:
            name = name.strip().lower()
            if name and not name.startswith('*.'):
                domains.add(name)
            elif name.startswith('*.'):  # wildcard
                domains.add(name[2:])    # добавляем зону, но с пометкой
    return sorted(domains)

Этап 3: Поиск по части имени (через SQL-запросы crt.sh)

crt.sh поддерживает прямые SQL-запросы (язык PostgreSQL). Это позволяет делать сложные поиски, например:

https://crt.sh/?q=SELECT name_value FROM certificate_identity WHERE name_value LIKE '%.example.com%' AND name_value NOT LIKE '%.%.%'

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

Полезные SQL-шаблоны:

Все сертификаты, выданные определённым CA: q=SELECT * FROM certificate WHERE issuer LIKE '%Let%27s Encrypt%'
Сертификаты, истекающие в ближайшие 30 дней: q=SELECT name_value, not_after FROM certificate WHERE not_after < NOW() + interval '30 days' AND name_value LIKE '%.example.com'

Этап 4: Выявление скрытых хостов через сертификаты

Скрытые хосты — это внутренние или тестовые поддомены, которые не разрешаются в DNS публично, но для них был выпущен сертификат (например, dev-db.internal.example.com). Такой сертификат будет в CT-логах, даже если DNS-запрос к dev-db.internal.example.com не вернёт IP.

Почему это возможно?

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

Как найти такие хосты:

Выполните поиск %.example.com в crt.sh.
Извлеките все имена.
Для каждого имени выполните DNS-запрос A/AAAA. Если запрос не возвращает IP, но имя выглядит правдоподобно — это скрытый хост.
Проверьте IP через Shodan/Censys — возможно, сертификат был выдан для IP-адреса, который сейчас неактивен.

Python-скрипт для обнаружения скрытых хостов:

import dns.resolver
import requests

def check_dns(domain):
    try:
        answers = dns.resolver.resolve(domain, 'A')
        return [str(r) for r in answers]
    except:
        return []

# Получить все имена из сертификатов
certs = get_certificates("example.com")
domains = extract_domains(certs)

hidden = []
for domain in domains:
    ips = check_dns(domain)
    if not ips:
        print(f"Скрытый хост (не резолвится): {domain}")
        hidden.append(domain)
    else:
        print(f"{domain} -> {ips}")

print(f"Найдено скрытых хостов: {len(hidden)}")

Этап 5: Анализ времени действия сертификата

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

Применение:

Найти старые сертификаты для old-site.example.com, чтобы восстановить историю.
Определить закономерности обновления сертификатов (например, каждые 90 дней — Let's Encrypt).
Обнаружить сертификаты с очень длинным сроком действия (могут быть самоподписными или тестовыми).

Этап 6: Поиск сертификатов по серийному номеру

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

Поиск в crt.sh по серийному номеру:

https://crt.sh/?q=serial_number_string

Серийные номера обычно шестнадцатеричные. Этот метод полезен, если вы нашли сертификат на сервере (через OpenSSL) и хотите узнать, какие ещё домены есть в том же сертификате.

Этап 7: Интеграция с Shodan/Censys для поиска по хэшу сертификата

Shodan и Censys позволяют искать устройства по хэшу сертификата (SHA1 или SHA256). Это позволяет найти все серверы в интернете, использующие тот же сертификат (или тот же ключ).

Shodan фильтр ssl.cert.sha256:

ssl.cert.sha256:5f5a5f5a5f5a5f5a5f5a5f5a5f5a5f5a5f5a5f5a

Так можно обнаружить все серверы организации, использующие единый сертификат.

Censys аналогично:

services.tls.certificate.leaf_fingerprint_sha256: <hash>

Этап 8: Мониторинг новых сертификатов (CertSpotter)

CertSpotter (https://sslmate.com/certspotter/) — это сервис, который отслеживает CT-логи и уведомляет вас о появлении новых сертификатов для указанных доменов. Он особенно полезен для мониторинга инфраструктуры конкурентов или собственной.

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

Бесплатный аккаунт позволяет добавить до 10 доменов.
При обнаружении нового сертификата приходит email.
Можно также использовать API для автоматической обработки.

Этап 9: Обнаружение сертификатов, связанных с организацией

Если вы знаете юридическое название организации (Organization field в сертификате), можно найти все сертификаты, выпущенные на это имя (даже если домены не связаны явно).

Поиск в crt.sh по организации:

https://crt.sh/?q=O%3DExample%20Inc

Пример: O=Google Trust Services найдёт сертификаты Google.

Осторожно: поле O не всегда заполняется, особенно для сертификатов Let's Encrypt (там только O=Let's Encrypt).

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

Задача: найти все домены, связанные с компанией acme.com, включая тестовые поддомены и внутренние хосты.

crt.sh для %.acme.com → 120 сертификатов, 350 уникальных имён.
Очистка: убрать дубликаты, домены, не заканчивающиеся на acme.com (убрать сторонние).
DNS-проверка: 80 имён резолвятся в IP, 270 — нет (скрытые).
Среди скрытых находим test.acme.com, staging.api.acme.com, jenkins.acme.com.
Проверка Shodan для jenkins.acme.com (хотя IP не резолвится, возможно, сертификат есть на каком-то IP). Shodan: ssl.cert.subject.CN:jenkins.acme.com → находим IP 198.51.100.45 с открытым 8080.
Анализ: Jenkins сервер доступен по IP, но не имеет DNS-записи. Уязвимость.
Исторические сертификаты: старый сертификат old.acme.com истёк в 2022, но в логах есть. Его IP 203.0.113.88 уже не доступен.
Вывод: обнаружены забытые, но активные серверы, требующие внимания.

Автоматизация мониторинга через crt.sh API

import requests
import time
import hashlib

def monitor_new_certs(domain, last_check_file):
    # загружаем последний известный хэш
    try:
        with open(last_check_file, 'r') as f:
            last_hash = f.read().strip()
    except:
        last_hash = ''
    
    url = f"https://crt.sh/?q=%25.{domain}&output=json"
    resp = requests.get(url)
    if resp.status_code == 200:
        data = resp.json()
        # вычисляем хэш от всего содержимого (как дешёвый способ детектировать изменения)
        content_str = json.dumps(data)
        new_hash = hashlib.sha256(content_str.encode()).hexdigest()
        if new_hash != last_hash:
            print(f"Обнаружены новые сертификаты для {domain}")
            # здесь можно отправить уведомление
            with open(last_check_file, 'w') as f:
                f.write(new_hash)
        else:
            print("Нет изменений")

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

Анализ SSL/TLS сертификатов через CT-логи — один из самых мощных методов пассивного технического OSINT. Позволяет обнаруживать поддомены, которые не видны в DNS, включая тестовые, внутренние и исторические хосты. Основные инструменты — crt.sh, CertSpotter, Censys. Комбинация извлечения доменов из сертификатов, проверки DNS-резолвинга и дальнейшего сканирования (Shodan) позволяет выявить скрытую инфраструктуру организации.

Сканирование портов и сервисов: Nmap, массовое сканирование, интерпретация результатов

2026-06-09T06:21:10.734Z

Сканирование портов и сервисов: Nmap, массовое сканирование, интерпретация результатов

Сканирование портов — это процесс проверки сетевых портов на целевой системе для определения, какие сетевые службы (веб-сервер, SSH, FTP, база данных и т.д.) запущены и доступны. Это один из самых информативных, но и наиболее «активных» методов технического OSINT. В отличие от пассивной разведки (DNS, WHOIS, сертификаты), сканирование портов напрямую взаимодействует с целью, оставляя следы в логах. Поэтому критически важно различать легальное сканирование (с разрешения владельца, в рамках пентеста или исследования собственной инфраструктуры) и несанкционированное (противозаконное).

Данная статья описывает методы и инструменты сканирования портов, а также способы получения аналогичной информации пассивно через публичные базы (Shodan, Censys). Акцент будет сделан на интерпретации результатов и на том, как использовать эти данные для составления картины инфраструктуры.

Активное vs пассивное сканирование

для разведки без риска сначала используйте Shodan/Censys. Только при наличии письменного разрешения (или на собственной инфраструктуре) переходите к активному Nmap.

Этап 1: Пассивное сканирование через Shodan

Shodan — поисковая система по интернет-подключенным устройствам. Она постоянно сканирует весь интернет по многим портам (80, 443, 22, 21, 25, 3389, 3306, 5900 и т.д.) и сохраняет баннеры (ответы сервисов). Вы можете искать по IP, домену, организации, порту, географической локации и многим другим фильтрам.

Поиск по IP в Shodan:

https://www.shodan.io/host/8.8.8.8

Что покажет Shodan:

Открытые порты (с номером и названием службы).
Баннер (HTTP заголовки, версия SSH, сообщение FTP).
Страна, город, ASN, организация.
История изменений (даты сканирований, если подписка).

Пример фильтрации:

hostname:example.com                     # все IP, связанные с example.com
port:443 org:"Google"                    # порт 443 у организаций, содержащих Google
ssl.cert.subject.CN:"*.example.com"      # сертификаты

Shodan API (Python):

import shodan

api = shodan.Shodan('YOUR_API_KEY')
host = api.host('8.8.8.8')
for item in host['data']:
    print(f"Port {item['port']}: {item.get('banner', '')[:100]}")

Censys — альтернатива Shodan, с фокусом на сертификаты и глубокую информацию о портах. Интерфейс сложнее, но часто даёт больше данных.

Этап 2: Активное сканирование с Nmap (с разрешения!)

Nmap (Network Mapper) — стандарт де-факто для активного сканирования портов. Он поддерживает десятки техник сканирования (TCP SYN, TCP connect, UDP, NULL, FIN и т.д.), определение служб, версий, ОС и скриптовые проверки.

Основные типы сканов:

Базовые команды Nmap:

# Сканирование топ-1000 портов TCP
nmap example.com

# Сканирование определённого диапазона портов
nmap -p 22,80,443,8080 example.com

# Сканирование всех портов (медленно!)
nmap -p- example.com

# Определение версий служб (баннеры)
nmap -sV example.com

# Использование скриптового движка (безопасные скрипты)
nmap -sC example.com

# Сохранение результатов в файл
nmap -oA scan_results example.com

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

nmap -sV -sC -p- --min-rate 1000 -T4 example.com

Примечание: --min-rate 1000 и -T4 ускоряют сканирование, но могут вызвать срабатывание IDS. Для легальных тестов это допустимо, для разведки — нежелательно.

Продвинутые техники Nmap:

Сканирование подсети: nmap 192.0.2.0/24
Сканирование из файла со списком IP: nmap -iL hosts.txt
Использование специальных профайлов для времени (для скрытности): -T0 (очень медленно) или -T1 (параноидальный).

Этап 3: Массовое сканирование (masscan, Zmap)

Для сканирования больших диапазонов IP (например, всей сети /16) используют массовые сканеры. Они не определяют версии служб, а только проверяют, открыт ли порт.

Пример masscan:

masscan 192.0.2.0/24 -p80,443,22 --rate=10000

массовое сканирование легко обнаруживается и может быть расценено как атака.

Этап 4: Интерпретация результатов сканирования

Результат сканирования (например, из Nmap или Shodan) — это перечень портов и служб. Что делать дальше?

Таблица портов и типовых служб:

Особые случаи:

Порт 8080, 8443, 8000 — часто альтернативные веб-порты (панели администрирования, прокси).
Порты с нестандартными службами (например, SSH на 2222) — попытка скрыть сервис.
Большое количество открытых портов может указывать на отсутствие файрвола или наличие docker-контейнеров.

Этап 5: Анализ баннеров

Баннер — это текстовая строка, которую сервер отправляет при подключении (например, HTTP заголовок Server: nginx/1.18.0). Из баннера можно узнать версию ПО, что важно для оценки уязвимостей.

Примеры:

SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5 → уязвимости OpenSSH 8.2.
220 ProFTPD 1.3.5 Server → старая версия ProFTPD (много уязвимостей).
HTTP/1.1 200 OK → баннер неинформативен (скрыт).

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

WhatWeb — определяет CMS, технологии по HTTP баннерам.
Wappalyzer (расширение для браузера) — удобно для быстрого анализа веб-сайтов.
Httpx (от ProjectDiscovery) — быстрый HTTP-клиент для массового извлечения баннеров.

Этап 6: Скриптовые проверки (NSE)

Скриптовый движок Nmap содержит сотни скриптов для обнаружения уязвимостей, брутфорса, сбора информации.

Категории скриптов:

safe — не опасные, не нарушающие работу сервиса.
intrusive — могут вызвать сбои или оставить следы.
vuln — проверяют на известные уязвимости.
brute — подбор паролей.

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

nmap --script=http-title,http-headers,ssl-cert -p 443 example.com

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

Инфраструктура меняется: открываются новые порты, закрываются старые. Важно отслеживать эти изменения.

Методы:

Периодическое сканирование с сохранением результатов в файл.
Использование Shodan (есть история сканирований, но не для всех портов).
Censys — предоставляет снимки на разные даты.

Автоматизация сбора данных через Shodan API:

import shodan
import time

api = shodan.Shodan('YOUR_API_KEY')
domains = ['example.com', 'target.org']
for domain in domains:
    try:
        results = api.search(f'hostname:{domain}')
        for result in results['matches']:
            print(f"{domain}: {result['ip_str']} port {result['port']} - {result.get('data','')[:80]}")
        time.sleep(1)  # не превышать rate limit
    except Exception as e:
        print(e)

Этап 8: Обнаружение ложных срабатываний

Некоторые порты могут быть открыты, но фильтроваться файрволом (Nmap покажет filtered или closed).
Порты, отображаемые как открытые в Shodan, могут быть уже закрыты (данные устарели).
Облачные провайдеры часто перенаправляют трафик через глобальные балансировщики (порты могут быть открыты на всех IP одновременно).

Практический пример: анализ инфраструктуры по портам

Задача: проанализировать открытые порты домена target.org.

Shodan: по IP 203.0.113.20 найдены порты 80, 443, 22, 8080.

80 → HTTP (nginx/1.18.0).
443 → HTTPS, сертификат для target.org.
22 → SSH, баннер OpenSSH 8.2.
8080 → панель управления Jenkins.

Nmap (с разрешения):

nmap -sV -p 22,80,443,8080 -sC target.org
На порту 8080 Jenkins версия 2.277 (уязвимая, возможно CVE-2024-23897).
На порту 22 слабые алгоритмы шифрования (можно попробовать брутфорс).

Анализ: Jenkins доступен из интернета (потенциальная уязвимость). SSH устаревший. Веб-сервер требует проверки на веб-уязвимости.
Рекомендация: закрыть порт 8080 для внешнего доступа, обновить SSH.

Никогда не сканируйте чужие системы без письменного разрешения. Даже SYN-сканирование может быть расценено как попытка взлома.
Для обучения используйте собственные VPS, локальные виртуальные машины, или специальные площадки (HackTheBox, TryHackMe).
Если вам нужны данные о публичных системах для исследования — используйте Shodan, Censys, BinaryEdge.
В некоторых странах несанкционированное сканирование портов является уголовным преступлением.

Сканирование портов и служб — мощный метод технического OSINT, но он должен применяться с осторожностью и только на законных основаниях. Пассивные источники (Shodan, Censys) дают почти ту же информацию без риска. Активное сканирование (Nmap) — для глубокого анализа по разрешению. Интерпретация результатов требует знаний о типовых портах, службах и уязвимостях. В связке с поддоменами и DNS это позволяет картировать внешнюю поверхность атаки.

Анализ IP-адресов и ASN: геолокация, владельцы, соседние сети, BGP

2026-06-08T18:50:10.731Z

Анализ IP-адресов и ASN: геолокация, владельцы, соседние сети, BGP

IP-адреса — это «координаты» устройств в интернете. Зная IP-адрес сервера цели, можно определить его географическое положение, узнать, какому интернет-провайдеру или хостинговой компании он принадлежит, выявить другие сайты, находящиеся на том же сервере, и даже восстановить структуру сетевой инфраструктуры организации через BGP-маршрутизацию. Анализ IP и ASN (автономных систем) — важнейший этап технического OSINT, позволяющий перейти от доменных имен к физическим сетям и их владельцам.

Что такое ASN и зачем он нужен?

ASN (Autonomous System Number) — это уникальный номер, присваиваемый автономной системе (Autonomous System, AS). Автономная система — это совокупность IP-сетей (подсетей) под единым административным управлением (например, Ростелеком, МГТС, Amazon AWS, Google). Организации, имеющие собственные IP-диапазоны и публично объявляющие о них через BGP, получают ASN.

Ценность ASN для технического OSINT:

Зная ASN цели, можно получить все IP-диапазоны, которые принадлежат организации (полная картина её «цифровой земли»).
Можно обнаружить соседние подсети (соседние AS) — потенциальных партнёров или транзитных провайдеров.
Выявить изменения (появление новых подсетей, выбытие старых) через мониторинг BGP.

Этап 1: Базовый анализ IP-адреса

Самый простой способ начать анализ IP — использовать онлайн-сервисы или утилиты командной строки.

Что можно узнать по IP:

Геолокация (страна, регион, город, иногда координаты) — не всегда точная, основывается на базах данных организаций.
Провайдер / хостинг-компания (название, контакты).
ASN (номер автономной системы, которой принадлежит IP).
Тип IP (провайдерский, хостинговый, прокси, VPN, Tor exit node).
История IP (к каким доменам привязывался ранее).

Инструменты быстрого анализа IP:

Команды:

# whois по IP
whois 8.8.8.8

# curl к ipinfo.io
curl ipinfo.io/8.8.8.8
curl ipinfo.io/8.8.8.8/json

# dig для обратного DNS (PTR)
dig -x 8.8.8.8 +short

Пример ответа ipinfo.io:

{
  "ip": "8.8.8.8",
  "hostname": "dns.google",
  "city": "Mountain View",
  "region": "California",
  "country": "US",
  "loc": "37.4056,-122.0775",
  "org": "AS15169 Google LLC",
  "postal": "94043",
  "timezone": "America/Los_Angeles"
}

Этап 2: ASN и BGP — что скрывается за номером AS?

Каждый IP принадлежит какой-то автономной системе (AS). Узнав ASN, можно запросить BGP-информацию: какие IP-диапазоны анонсирует эта AS (то есть какие адреса принадлежат организации), а также с кем эта AS граничит (пировые связи, транзитные провайдеры).

Инструменты для получения ASN по IP:

Пример через Team Cymru:

dig +short 8.8.8.8.origin.asn.cymru.com TXT
# результат: "15169 | 8.8.8.0/24 | US | arin | 1992-12-01"

Этап 3: Получение всех IP-диапазонов AS

Зная ASN, можно скачать все подсети (CIDR-блоки), которые эта AS объявляет в BGP. Это даст полную картину всех IP-адресов, находящихся под контролем организации (включая те, что не связаны напрямую с доменом).

Где взять данные:

BGP.he.net — по ASN отображает список подсетей.
RIPE Stat — API для получения маршрутов AS.
CAIDA — архив BGP.
Radb (whois.radb.net) — база маршрутов.

Пример через whois.radb.net:

whois -h whois.radb.net -- '-i origin AS15169' | grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]+'

BGP.he.net API (пример):

curl https://bgp.he.net/AS15169
# нужно парсить HTML, есть неофициальное API

Python-функция (через Team Cymru):

import requests

def get_ip_routes_by_asn(asn):
    url = f"https://api.cymon.io/bgp/routes/origin/{asn}"
    # можно использовать альтернативные сервисы
    # более простой: whois -h whois.radb.net -- '-i origin AS15169'

Этап 4: Поиск соседних доменов на том же IP (Reverse IP Lookup)

Один IP-адрес может хостить множество доменов (shared hosting, виртуальные серверы). Если цель использует невыделенный IP, то можно найти другие домены, связанные с той же инфраструктурой.

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

SecurityTrails API пример:

curl -H "APIKEY: YOUR_KEY" https://api.securitytraits.com/v1/domain/8.8.8.8/domain

Ограничения: на shared-хостинге могут быть тысячи доменов, большинство не связано с целью. Используйте фильтрацию (похожие тематики, SSL-сертификаты, даты создания).

Этап 5: Анализ BGP-пиров (соседних AS)

Смотря на BGP-таблицы, можно увидеть, между какими AS существует прямое сетевое соединение (пиринг). Это может указывать на деловые отношения, транзитный трафик или использование CDN.

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

BGP.he.net → страница AS, раздел “Peers” (соседние AS).
BGPView → альтернативный визуализатор.
CAIDA AS Rank — ранжирование AS по количеству пиров.

Анализ пиров:

Если AS цели пирится с крупным облачным провайдером (AWS, Google Cloud), часть инфраструктуры может быть там.
Если пирится с AS, принадлежащим провайдеру DDoS-защиты (Cloudflare, Akamai), то сайт использует их услуги.

Этап 6: Геолокация IP — методы и ограничения

Геолокация по IP основана на базах данных (MaxMind, IP2Location), которые не всегда точны (особенно для мобильных сетей, VPN, облаков). Следует относиться к ней как к ориентиру, а не к истине.

Как повысить точность:

Сравнить несколько баз: ipinfo.io, MaxMind, IP2Location.
Использовать обратный DNS (PTR) — иногда содержит географические указатели (например, hosting-in-moscow.example.com).
Проверить сертификаты (в них может быть указан юридический адрес).
Запросить BGP-локацию (определённые AS имеют географическую привязку, но не точную).

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

IP2Location (разные версии).
DB-IP.
GeoIP Tool (geoiptool.com).

Этап 7: История IP (предыдущие домены, предыдущие владельцы)

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

Источники истории IP:

SecurityTrails Historical IP (показывает домены, привязанные к IP в прошлом).
ViewDNS.info IP History (ограничен).
Censys — сохраняет снимки IP-сканирований (порты, сертификаты) за разные даты.
Wayback Machine для страниц, доступных по IP.

Этап 8: Выявление cloud-сервисов и CDN

Многие IP-адреса принадлежат облачным платформам. Идентификация облачного провайдера может помочь сузить географию или определить используемые сервисы.

Как определить облачный IP:

whois покажет организацию (например, "AWS", "Microsoft Corporation", "Google Cloud").
Сравнить ASN со списками облачных AS (например, AS15169 — Google, AS14618 — AWS, AS8075 — Microsoft).
Специальные списки: (например, https://raw.githubusercontent.com/cloudflare/ip-list/master/cloudflare.ipv4 для Cloudflare).

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

Задача: проанализировать IP-адреса домена target.com.

DNS-запрос A → target.com -> 192.0.2.10.
whois 192.0.2.10 → организация Example Hosting Ltd., страна US.
ipinfo.io → "org": "AS65535 Example Hosting", "city": "New York".
Reverse IP (SecurityTrails) → на том же IP еще 50 доменов, в основном мелкие сайты. Shared-хостинг.
ASN → AS65535. Через BGP.he.net получаем все подсети этой AS: 192.0.2.0/24, 198.51.100.0/24, ...
Поиск других IP в этих подсетях, которые могут принадлежать цели.
BGP-пиры → ASN цели соединен с AS15169 (Google). Возможно, сайт использует Google Cloud CDN.
История IP → 2 года назад IP был 203.0.113.55, который принадлежал другой AS (предыдущий хостинг).
Вывод: цель использует shared-хостинг у Example Hosting; старый сервер больше не активен; через Google Cloud, вероятно, используется кэширование.

Автоматизация сбора данных по IP и ASN (Python)

import requests
import ipaddress

def ip_info(ip):
    resp = requests.get(f"https://ipinfo.io/{ip}/json")
    return resp.json() if resp.status_code == 200 else None

def get_asn(ip):
    info = ip_info(ip)
    org = info.get("org", "")
    if org.startswith("AS"):
        asn = org.split()[0][2:]  # "AS15169" -> "15169"
        return asn
    return None

def get_prefixes_by_asn(asn):
    # через whois.radb.net (упрощённо)
    import subprocess
    cmd = f"whois -h whois.radb.net -- '-i origin AS{asn}' | grep -Eo '([0-9]+\\.){3}[0-9]+/[0-9]+'"
    result = subprocess.run(cmd, shell=True, capture_output=True, text=True)
    return result.stdout.splitlines()

# Пример
ip = "8.8.8.8"
print(ip_info(ip))
asn = get_asn(ip)
print(f"ASN: {asn}")
prefixes = get_prefixes_by_asn(asn)
print(f"Prefixes: {prefixes[:5]}...")

WHOIS по IP, DNS-запросы, BGP-данные — это публичные данные. Их сбор безопасен и легален.
Массовый reverse DNS или перебор IP-диапазонов без разрешения может считаться активным сканированием, если выполняется в больших объёмах. Используйте осторожно и с уважением к чужой инфраструктуре.
Сервисы типа SecurityTrails имеют условия использования, запрещающие массовые автоматические запросы без оплаты.

Анализ IP и ASN позволяет преобразовать сетевую инфраструктуру организации в карту подсетей, обнаружить скрытые активы и соседние ресурсы, определить географическое расположение и используемые облачные провайдеры. Ключевые инструменты: whois, ipinfo.io, BGP.he.net, SecurityTrails. В сочетании с данными о поддоменах и DNS это даёт практически полную картину внешней поверхности атаки.

В следующей статье цикла мы рассмотрим сканирование портов и сервисов — активный этап, который требует особой осторожности, а также освоим инструменты Nmap, массовое сканирование и Shodan.

Поиск поддоменов: инструменты и методы

2026-06-07T18:09:02.678Z

Поиск поддоменов: инструменты и методы

Поддомены — это «входные двери» в инфраструктуру организации. Часто основные сервисы располагаются на поддоменах типа www.example.com, mail.example.com, vpn.example.com, а забытые поддомены (test.example.com, dev.example.com) могут быть уязвимы или раскрывать внутреннюю структуру. Поиск поддоменов — ключевой этап технического OSINT, позволяющий обнаружить скрытые активы, не связанные напрямую с основным доменом. Данная статья посвящена методам и инструментам пассивного поиска поддоменов.

Почему поддомены важны для разведки?

Классификация методов поиска поддоменов

Этап 1: Поиск через сертификаты (Certificate Transparency Logs)

Современные SSL/TLS сертификаты публикуются в публичные логи Certificate Transparency (CT). Каждый выданный сертификат (включая те, что для поддоменов) появляется в этих логах. Это наиболее надежный пассивный источник поддоменов.

Инструменты CT-логов:

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

Веб-интерфейс: https://crt.sh/?q=%25.example.com (где %25 — это URL-кодированный символ %, означающий "любые символы перед .example.com").
API: https://crt.sh/?q=.example.com&output=json

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

import requests
import json

def get_subdomains_from_crt(domain):
    url = f"https://crt.sh/?q=%25.{domain}&output=json"
    response = requests.get(url)
    if response.status_code == 200:
        data = response.json()
        subdomains = set()
        for entry in data:
            name = entry.get('name_value', '')
            if name.endswith(f'.{domain}') or name == domain:
                subdomains.add(name)
        return sorted(subdomains)
    else:
        return []

subs = get_subdomains_from_crt('example.com')
print(subs)

crt.sh возвращает много дублей, мёртвые сертификаты, включает домены, принадлежащие другим организациям (если сертификат содержит несколько имен). Требуется пост-обработка.

Этап 2: Поиск через DNS-историю

Исторические DNS-записи содержат поддомены, которые уже могли быть удалены, но все еще могут указывать на активные IP.

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

SecurityTrails — позволяет искать поддомены по домену и видеть историю.
DNSdumpster — отображает все поддомены, найденные из разных источников.
ViewDNS.info (Reverse IP lookup) — показывает домены на одном IP, что может косвенно выявить поддомены.

SecurityTrails API (пример):

curl -H "APIKEY: YOUR_KEY" https://api.securitytrails.com/v1/domain/example.com/subdomains

Этап 3: Активный DNS-брутфорс (словарный перебор)

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

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

Инструменты брутфорса:

Sublist3r — комбинирует пассивные источники + брутфорс.
Amass — мощный фреймворк (пассивный + активный).
dnsrecon — включает брутфорс и AXFR.
dnsenum — классика.
Gobuster с модулем dns.

Пример использования Sublist3r:

sublist3r -d example.com -o subdomains.txt

amass enum -passive -d example.com -o subdomains.txt

Активный брутфорс с Amass:

amass enum -active -d example.com -brute -w wordlist.txt

Словари для брутфорса:

SecLists/Discovery/DNS/subdomains-top1million-5000.txt — популярный.
commonspeak2-wordlists.
Собственные списки, сформированные из известных поддоменов (например, www, mail, remote, vpn, dev, test, staging, api, admin, portal, blog, shop, support, ftp, ns1, mx1).

Этап 4: Поиск через поисковые системы

Использование операторов поиска для нахождения страниц, индексированных на поддоменах.

Google Search:

site:*.example.com
site:example.com -www

Bing / Yandex — аналогично.

Особенности: находит только проиндексированные поисковиком поддомены; часто дает неполный результат.

Этап 5: Поиск через ASN и IP-диапазоны

Если известен ASN (автономная система) цели или диапазон IP-адресов, можно выполнить обратный поиск PTR-записей для всех IP в диапазоне.

Метод:

Определить ASN цели (через whois IP или BGP.he.net).
Получить список IP-диапазонов этого ASN (из базы RIPE/ARIN).
Выполнить массовый reverse DNS-запрос (но осторожно, чтобы не перегружать сеть). Инструменты: dnsrecon -r, massdns, собственные скрипты.

Пассивный вариант: использовать сервис Censys (ранее — Project Sonar), который публикует данные reverse DNS сканирований.

Этап 6: Поиск в репозиториях кода (GitHub, GitLab)

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

GitHub поиск:

*.example.com extension:conf
"example.com" path:config

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

GitHub Code Search (веб).
TruffleHog (поиск секретов, может найти и поддомены).
GitRob / GitGrab — поиск по организациям.

Этап 7: Комплексные фреймворки для поддоменов

Для полного покрытия использовать комбинацию: Amass (пассивный режим) + Subfinder + crt.sh + SecurityTrails (если есть ключ).

Этап 8: Обработка и фильтрация результатов

Список поддоменов обычно содержит:

Дубликаты.
Поддомены, не относящиеся к цели (например, из общих сертификатов).
Некорректные записи (звездочки, wildcards).

Фильтрация:

def clean_subdomains(raw_list, target_domain):
    cleaned = set()
    for sub in raw_list:
        sub = sub.strip().lower().rstrip('.')
        if sub.endswith(target_domain) and sub != target_domain:
            # Убрать wildcard (*)
            if sub.startswith('*.'):
                sub = sub[2:]
            cleaned.add(sub)
    return sorted(cleaned)

Валидация: для каждого поддомена выполнить DNS-запрос (A или AAAA), чтобы убедиться, что он резолвится в IP.

Этап 9: Визуализация и анализ поддоменов

После сбора поддоменов полезно:

Сгруппировать их по IP-адресам (один IP — несколько поддоменов).
Выявить общие подсети.
Обнаружить поддомены, указывающие на облачные сервисы (AWS, Azure, GCP).
Построить граф связей.

Инструменты визуализации:

Aquatone — создает скриншоты поддоменов, отображает сгруппированные по IP.
EyeWitness — аналогично.
Gephi — для графа связей.

Практический пример: поиск поддоменов example.org

crt.sh → найдено 45 поддоменов, включая admin.example.org, dev-api.example.org, test.example.org.
Subfinder → добавил mail.example.org, remote.example.org, vpn.example.org.
Amass (пассивный) → нашел grafana.internal.example.org, jenkins.example.org.
DNSdumpster → подтвердил большинство и добавил ftp.example.org.
Проверка через DNS: dev-api.example.org разрешается в 203.0.113.89, jenkins.example.org — в 198.51.100.22.
Анализ IP: оба IP принадлежат одному хостинг-провайдеру, но разным подсетям. jenkins.example.org имеет открытый порт 8080 (Jenkins), что является потенциально критичным.
Вывод: обнаружен Jenkins-сервер, доступный из интернета, который можно проверить на наличие уязвимостей.

Автоматизация сбора поддоменов (Python-скрипт-агрегатор)

import subprocess
import requests

def get_subdomains(domain):
    subs = set()
    # crt.sh
    url = f"https://crt.sh/?q=%25.{domain}&output=json"
    resp = requests.get(url)
    if resp.status_code == 200:
        for entry in resp.json():
            name = entry.get('name_value', '')
            if name.endswith(domain):
                subs.add(name)
    # Subfinder (запуск внешней команды)
    result = subprocess.run(['subfinder', '-d', domain, '-silent'], capture_output=True, text=True)
    for line in result.stdout.split():
        subs.add(line.strip())
    return sorted(subs)

domains = get_subdomains('example.com')
for d in domains:
    print(d)

Пассивный поиск (crt.sh, SecurityTrails, DNS-история) легален и безопасен.

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

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

Поиск поддоменов — многоэтапный процесс, требующий комбинации пассивных источников (crt.sh, SecurityTrails, DNS-история) и аккуратного активного брутфорса. Самые мощные инструменты — Amass и Subfinder. Полученный список поддоменов необходимо очистить, провалидировать и проанализировать (выявить IP, открытые порты, технологии). Это позволит составить полную карту внешней инфраструктуры организации.

DNS-разведка: whois, dig, nslookup, история DNS, reverse DNS

2026-06-03T19:52:38.670Z

DNS-разведка: whois, dig, nslookup, история DNS, reverse DNS

DNS (Domain Name System) — это «телефонная книга» интернета, преобразующая доменные имена в IP-адреса и обратно. Для специалиста по техническому OSINT DNS является одним из самых информативных источников: записи DNS раскрывают инфраструктуру организации, ее почтовые серверы, поддомены, политики безопасности и даже историю изменений. Данная статья посвящена методам DNS-разведки с использованием открытых инструментов и баз данных.

Почему DNS-разведка важна?

Этап 1: WHOIS — кто владелец домена или IP?

WHOIS-запрос возвращает регистрационные данные домена (или IP-диапазона). Хотя многие регистраторы скрывают персональные данные за PrivacyGuard, многое остается доступным.

Что можно узнать из WHOIS:

Дата регистрации домена (дата создания).
Дата окончания регистрации (можно оценить, активен ли домен).
Регистратор (например, GoDaddy, Namecheap, REG.RU).
DNS-серверы (NS записи).
Контактная информация (имя, email, телефон, адрес — если не скрыта).
Для IP-блока: организация-владелец, страна, диапазон.

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

Пример командной строки:

whois example.com
whois 8.8.8.8

Этап 2: Базовые DNS-записи (dig, nslookup)

dig (Linux/macOS) и nslookup (Windows, Linux) — основные утилиты для прямых DNS-запросов.

Примеры dig:

dig example.com A               # A запись (IPv4)
dig example.com AAAA            # AAAA запись (IPv6)
dig example.com MX              # MX записи (почта)
dig example.com TXT             # TXT записи
dig example.com NS              # NS записи
dig example.com CNAME           # CNAME записи
dig example.com SOA             # SOA запись

# Указание конкретного DNS-сервера
dig @8.8.8.8 example.com A

# Краткий вывод (+short)
dig example.com A +short

Пример nslookup:

nslookup example.com
set type=MX
example.com

Использование публичных DNS-серверов:

8.8.8.8 (Google Public DNS)
1.1.1.1 (Cloudflare)
9.9.9.9 (Quad9)
77.88.8.8 (Яндекс DNS)

Этап 3: История DNS (DNS History)

Записи DNS меняются: серверы переезжают, поддомены создаются и удаляются. История DNS позволяет найти старые IP, забытые поддомены, предыдущих хостинг-провайдеров.

Инструменты истории DNS:

Пример использования SecurityTrails:

# Через веб-интерфейс: https://securitytrails.com/domain/example.com/history
# Через API (требуется ключ)
curl -H "APIKEY: YOUR_KEY" https://api.securitytrails.com/v1/history/example.com/a

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

Старые IP-адреса, где ранее хостился домен.
Удаленные поддомены (иногда забытые, но все еще разрешающиеся).
Смену DNS-провайдера.

Этап 4: Reverse DNS (PTR запись)

Reverse DNS преобразует IP-адрес в доменное имя. Часто используется почтовыми серверами для проверки подлинности.

Поиск PTR записи:

dig -x 8.8.8.8 +short        # Результат: dns.google.
nslookup 8.8.8.8

Для диапазона IP: можно выполнить обратный поиск по всем IP в подсети (но массовые запросы могут быть заблокированы).

Применение в OSINT:

Подтверждение, что IP действительно принадлежит организации.
Поиск других доменов, указывающих на тот же IP (не всегда, только если PTR корректно настроен).

Этап 5: DNS-трассировка (поиск всех поддоменов)

Базовые DNS-запросы не дают список поддоменов. Для их поиска используются другие методы (подробнее в статье 3). Но базово:

NS записи → указывают на DNS-серверы, но не перечисляют поддомены.
Зонная передача (AXFR) — редкий случай, когда DNS-сервер разрешает выгрузку всей зоны. Проверить:bashdig @ns.example.com example.com AXFR

Этап 6: DNS-записи и безопасность (SPF, DKIM, DMARC)

TXT записи часто содержат политики безопасности почты.

SPF (Sender Policy Framework): перечисляет IP, которые могут отправлять почту от имени домена.

dig example.com TXT | grep "v=spf1"

Пример: v=spf1 include:_spf.google.com ~all → используется Google Workspace.

DKIM (DomainKeys Identified Mail): цифровая подпись писем.

dig selector._domainkey.example.com TXT

DMARC (Domain-based Message Authentication, Reporting & Conformance): указывает, что делать с письмами, не прошедшими SPF/DKIM.

dig _dmarc.example.com TXT

Ценность для OSINT:

Определение используемых почтовых провайдеров (Google, Microsoft, Яндекс, Mail.ru).
Выявление устаревших или неправильных конфигураций.
Возможный email для отчетов (в DMARC).

Этап 7: DNS-серверы и CDN

CNAME записи часто указывают на CDN (Cloudflare, Akamai, Amazon CloudFront). Это маскирует реальный IP-адрес сервера.

Как определить CDN:

A запись ведет на IP, принадлежащий CDN (проверить WHOIS).
CNAME на xxx.cloudfront.net, xxx.cdn.cloudflare.net и т.д.

Этап 8: Анализ DNS без командной строки — онлайн-сервисы

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

Задача: собрать информацию о домене target.org.

WHOIS → регистратор Namecheap, дата создания 2010-05-01, дата окончания 2026-05-01, DNS-серверы ns1.namecheap.com, контакты скрыты.
DNS-записи (dig):

A → 192.0.2.10
MX → mail.target.org (приоритет 10)
TXT → v=spf1 a mx include:spf.protection.outlook.com -all (использует Office 365)
NS → ns1.namecheap.com, ns2.namecheap.com
CNAME (www) → target.org (тот же IP)

Reverse DNS для IP 192.0.2.10 → web.target.org.
SPF-анализ → используются серверы Office 365. Предположительно, целевая организация использует Microsoft 365.
История DNS (SecurityTrails):

2 года назад A-запись была 203.0.113.55 (другой хостинг).
Был поддомен dev.target.org, сейчас не разрешается.

DNSdumpster → находит дополнительные поддомены: mail.target.org, remote.target.org, vpn.target.org.
Вывод: инфраструктура включает веб-сервер на 192.0.2.10, почту на Office 365, VPN-поддомен. Ранее использовался другой хостинг.

Инструменты для автоматизации DNS-запросов (Python)

import dns.resolver

def query_dns(domain, record_type):
    try:
        answers = dns.resolver.resolve(domain, record_type)
        return [str(r) for r in answers]
    except Exception as e:
        return None

domain = "example.com"
for rtype in ["A", "MX", "TXT", "NS"]:
    records = query_dns(domain, rtype)
    print(f"{rtype}: {records}")

ограничения

DNS-запросы — это публичные данные. Их сбор не является активным сканированием и обычно разрешен.
Однако массовые запросы к DNS-серверу могут быть расценены как атака (DDoS). Используйте задержки, авторитетные публичные резолверы.
Некоторые сервисы (SecurityTrails) имеют условия использования, запрещающие автоматизированный массовый сбор без подписки.

DNS-разведка — фундамент технического OSINT. WHOIS дает информацию о владельце и датах, dig/nslookup — текущие записи. История DNS и reverse DNS расширяют картину прошлых конфигураций. SPF/DKIM/DMARC раскрывают используемые почтовые сервисы. Владение этими методами позволяет бесконтактно составить детальную карту инфраструктуры домена.

В следующей статье цикла мы рассмотрим более сложный этап — поиск поддоменов, включая инструменты Amass, Sublist3r, crt.sh и техники перебора.