Вот реальная ситуация из инфраструктурной атрибуции: при разборе фишинговой кампании на финансовый сектор несколько доменов удаётся связать с одной операционной группой - общий WHOIS-регистратор, близкие даты регистрации, идентичные JARM-отпечатки TLS-стека. Ни один из этих доменов не фигурирует в публичных фидах. Атрибуция строится исключительно на анализе паттернов закупки инфраструктуры.
Русскоязычные материалы по OSINT-деанонимизации крутятся вокруг пробива физлиц: корреляция никнеймов, email-цепочки, EXIF. Деанонимизация инфраструктуры угроз - другая дисциплина, с другим набором артефактов и методов. Ниже - методология, которую я применяю на практике, с конкретными модулями SpiderFoot, категориями OSINT Framework и скриптами для автоматизации.
Бизнес-логика инфраструктурной атрибуции APT группировок
Зачем атрибутировать инфраструктуру атакующего, если достаточно заблокировать выявленные IoC? Вопрос масштаба и скорости. По данным CrowdStrike Global Threat Report 2025, среднее время lateral movement после initial access - 62 минуты (рекорд - 51 секунда). Блокировка одного C2-домена ничего не решает, если у группы развёрнуто ещё 20. Инфраструктурная атрибуция позволяет обнаружить их до активации.Согласно методологии Unit 42 (Palo Alto Networks), инфраструктурный анализ - один из основных компонентов атрибуции наряду с TTP-анализом, victimology и temporal analysis. Он работает на нескольких уровнях: activity clusters, temporary threat groups, named threat actors. В модели Diamond Model of Intrusion Analysis инфраструктура - одна из четырёх вершин (adversary, capability, infrastructure, victim). Связь между инфраструктурой и противником устойчивее прочих: TTP можно адаптировать, малварь перекомпилировать, а привычки закупки доменов и хостинга меняются медленно.
Это и есть trade-паттерн - операционная привычка, которую атакующий не осознаёт как уязвимость. Деанонимизация инфраструктуры угроз OSINT-методами строится именно на выявлении таких привычек.
Артефакты для деанонимизации инфраструктуры атакующих
В академических обзорах атрибуции APT артефакты делят на технические и нетехнические. Для инфраструктурной деанонимизации ключевые - сетевые и инфраструктурные.WHOIS-история и поиск паттернов регистрации доменов APT
WHOIS-история - первый слой анализа. Даже при использовании Privacy Protection паттерны вылезают наружу:- Выбор регистратора. Группы часто используют один регистратор для десятков доменов - не потому что он лучший, а потому что однажды настроенный процесс закупки повторяется. Привычка.
- Временное окно регистрации. Массовая регистрация 5–20 доменов за 24–72 часа - типичный индикатор подготовки к кампании.
- Паттерны именования. Повторяющиеся конструкции: комбинации «сервис + регион» (update-eu, cdn-asia), однотипные TLD (.xyz, .top, .club).
- Контактная информация. Повторяющийся nameserver, одинаковая страна в WHOIS-записях - даже при включённой privacy-защите.
sfp_whois).Техника T1593 (Search Open Websites/Domains, Reconnaissance) из MITRE ATT&CK описывает действия атакующего по разведке, но те же источники работают в обратном направлении - для атрибуции.
SSL/TLS-сертификаты и JARM-отпечатки
SSL-сертификаты - второй устойчивый артефакт. Три вектора анализа:Certificate Transparency (CT) логи. Публичные логи (crt.sh, Censys) содержат все выпущенные сертификаты. Поиск по организации, email или паттерну имени выявляет связанные домены, которых нет в passive DNS.
SHA-256 хэш сертификата. Один самоподписанный сертификат на нескольких серверах - сильный индикатор принадлежности к одной группе. Атакующие переиспользуют self-signed сертификаты чаще, чем кажется: генерация нового - лишний шаг в операционном процессе, и его пропускают.
JARM-хэши. JARM - активный fingerprinting TLS-стека. Генерирует 62-символьный хэш на основе ответов сервера на 10 специально сформированных TLS Client Hello. Одинаковый JARM на разных IP указывает на идентичную конфигурацию TLS и, часто, на одну инфраструктуру развёртывания.
Ограничение, о котором забывают: JARM совпадает у всех серверов с дефолтной конфигурацией одного хостинг-провайдера. Без дополнительной корреляции JARM-совпадение - слабый индикатор. На практике JARM полезен только в комбинации с WHOIS и DNS-данными.
Passive DNS и корреляция C2 серверов
Passive DNS фиксирует исторические связи «домен - IP-адрес». Что это даёт для выявления связей между вредоносными доменами:- Обнаружение доменов, резолвившихся на один IP в разное время (shared infrastructure).
- Выявление «парковки» - доменов, мигрировавших на один IP непосредственно перед кампанией.
- Расширение графа: IP-адреса известных C2-доменов → другие домены на тех же IP → их WHOIS и SSL.
Trade-паттерны: что выдаёт инфраструктуру command and control
Trade-паттерн - устойчивая поведенческая характеристика закупки и развёртывания атакующей инфраструктуры. В отличие от IoC, которые меняются после каждой кампании, trade-паттерны стабильны. Они отражают не технику, а привычку.Паттерн закупки. Один регистратор, один хостинг-провайдер, однотипный процесс оплаты. Группа, привыкшая работать через конкретного регистратора с оплатой криптовалютой, не переходит на другого без веской причины. Каждая миграция - перестройка операционного процесса, а люди ленивы (даже APT-операторы).
Паттерн развёртывания. Одинаковый стек серверного ПО, однотипные TLS-конфигурации, характерные HTTP-заголовки. Серверы с одним и тем же Malleable C2 Profile дают устойчивый JARM-хэш + паттерн HTTP-ответов.
Временной паттерн. Регистрация доменов за 2–4 недели до кампании. Обновление DNS-записей в определённые часы - коррелирует с часовым поясом оператора. Если группа стабильно обновляет A-записи в узком временном окне, скажем утренние часы по определённому часовому поясу, это сужает географию до нескольких стран.
Паттерн эволюции. Переход с одного C2-фреймворка на другой при сохранении инфраструктурных привычек. Группа сменила C2-инструментарий, но продолжает использовать тот же VPS-провайдер, те же TLD и тот же временной паттерн регистрации. Инструменты новые - руки те же.
Когда trade-паттерн НЕ работает: если группа использует инфраструктуру через посредника (Initial Access Broker). По данным Mandiant M-Trends 2025, exploits - наиболее распространённый вектор initial access (38%). Mandiant не приводит данных о доле IAB в этом векторе - связь с IAB здесь моё предположение, а не вывод отчёта. В этом случае инфраструктура принадлежит посреднику, и trade-паттерн ведёт к нему, а не к конечному атакующему.
SpiderFoot для threat intelligence: практический workflow
SpiderFoot - open-source OSINT-фреймворк с модульной архитектурой. Для инфраструктурной атрибуции он ценен не как «ещё один сканер», а как корреляционный движок: каждый модуль генерирует события, которые становятся входными данными для других модулей.Требования к окружению
- ОС: Linux (Debian/Ubuntu 20.04+), macOS, Windows (WSL рекомендуется)
- Python: 3.8+
- RAM: 4 ГБ минимум, 8 ГБ при сканировании с полным набором модулей
- API-ключи: Shodan, VirusTotal, SecurityTrails, Censys - без ключей SpiderFoot работает, но корреляция ограничена публичными источниками
Модули и автоматическая корреляция
Для trade pattern анализа инфраструктуры угроз критичны:| Категория | Модули | Артефакт |
|---|---|---|
| DNS / Passive DNS | sfp_dnsresolve, sfp_passivedns | Историческая связь домен - IP |
| WHOIS | sfp_whois, sfp_domaintools | Регистрационные данные, история |
| SSL/TLS | sfp_sslcert | Сертификаты, CT-логи |
| Сетевая разведка | sfp_shodan, sfp_censys | Открытые порты, баннеры |
| Репутация | sfp_virustotal | Связи с вредоносной активностью |
Bash:
# SpiderFoot CLI - сканирование домена с инфраструктурными модулями
python3 sf.py -s suspicious-domain.xyz \
-m sfp_dnsresolve,sfp_whois,sfp_sslcert,sfp_shodan,sfp_passivedns \
-o csv -q
# Результат: CSV с корреляцией DNS, WHOIS, SSL, Shodan
# Веб-интерфейс: python3 sf.py -l 127.0.0.1:5001Ограничение SpiderFoot для threat intelligence: корреляционный движок работает на уровне совпадения строковых значений (email, IP, домен). Он не распознаёт семантику trade-паттернов - не видит, что два домена зарегистрированы с интервалом в 4 часа через одного регистратора. Эту аналитику приходится делать вручную или скриптовать отдельно.
OSINT Framework для пентеста: навигация по инфраструктурным источникам
OSINT Framework (osintframework.com) - не инструмент, а структурированный каталог источников данных. Для инфраструктурного анализа релевантны категории:- Domain Name → WHOIS Records - сервисы исторического WHOIS (DomainTools, SecurityTrails)
- Domain Name → Subdomains - перечисление поддоменов для расширения поверхности анализа
- IP Address → Geolocation / Reputation - привязка IP к хостинг-провайдерам и AS
- Digital Certificates - поиск по CT-логам (crt.sh, Censys)
- Threat Intelligence - агрегаторы фидов (AlienVault OTX, MISP)
Связка инструментов: OSINT Framework помогает выбрать источники данных, SpiderFoot автоматизирует сбор и первичную корреляцию, итоговый анализ trade-паттернов - ручная или скриптовая работа на стороне аналитика.
Уровни атрибуции APT группировок: от кластера к именованному актору
Согласно методологии Unit 42, атрибуция проходит несколько уровней. На каждом инфраструктурный анализ работает по-разному.Уровень 1: Activity Cluster. Два и более связанных события группируются в кластер. На инфраструктурном уровне: общие IoC (один C2-домен, один SHA-256 хэш) или таргетинг одной отрасли. Кластерам присваиваются имена по мотивации - CL-STA-nnnn (state-sponsored), CL-CRI-nnnn (crime-motivated), CL-UNK-nnnn (unknown). Конкретная схема именования может варьироваться. Здесь высокая уверенность в атрибуции не нужна - достаточно обоснованной группировки связанных событий.
Уровень 2: Temporary Threat Group. Кластер повышается после минимум 6 месяцев наблюдения с подтверждением единого актора. Инфраструктурная атрибуция здесь - ключевой аргумент: повторяющиеся trade-паттерны закупки доменов, переиспользование SSL-сертификатов, стабильный хостинг-провайдер. Именование, предположительно: TGR-STA-nnnn.
Уровень 3: Named Threat Actor. Полная идентификация с высокой уверенностью. В threat intelligence применяется Admiralty System (NATO System) для оценки каждого доказательства по двум осям: reliability (надёжность источника) и credibility (подтверждаемость другими источниками). Ряд вендоров, включая Unit 42, описывают её использование в своих методологиях. WHOIS-данные из DomainTools - высокая reliability и credibility (верифицируемы через альтернативные WHOIS-сервисы). Анонимный отчёт на paste-сайте - низкая reliability, неверифицируемый.
Переход между уровнями происходит по мере накопления trade-паттернов: один совпавший регистратор - совпадение. Один регистратор + одинаковый временной паттерн + характерный JARM - кластер. Устойчивое повторение через несколько кампаний - основание для temporary group.
Автоматизация OSINT разведки в SOC: Python-пайплайн корреляции
Ручной анализ trade-паттернов не масштабируется при работе с сотнями доменов. Ниже - концептуальный скрипт для корреляции WHOIS-данных:Ограничения скрипта: WHOIS rate limiting (30–50 запросов в час у большинства серверов), отсутствие нормализации (формат дат варьируется между TLD), Privacy Protection не учитывается. Для промышленного использования нужна интеграция с SecurityTrails API или DomainTools API - они дают нормализованные исторические данные.
Ограничения инфраструктурной атрибуции: когда деанонимизация не работает
Вот где метод ломается:False flags. Продвинутые группы намеренно имитируют инфраструктурные привычки других акторов - используют тот же регистратор, похожие naming conventions, разворачивают C2 на инфраструктуре, ассоциированной с другой группой. Отличить false flag от подлинного trade-паттерна без дополнительного контекста (TTP, victimology) невозможно.
Shared tools. C2-фреймворки используются десятками групп. JARM-хэш дефолтной конфигурации одинаков у всех операторов, которые не кастомизировали профиль. По данным CrowdStrike (GTR 2025), 75% вторжений используют действительные учётные данные. Отдельно от этой статистики - по моему мнению, не подтверждённому данными CrowdStrike, - часть таких данных может закупаться через общих IAB, что потенциально размывает инфраструктурную границу между группами.
Bulletproof hosting. Некоторые хостинг-провайдеры обслуживают десятки групп одновременно. Совпадение AS и подсети - слабый индикатор, если провайдер специализируется на abuse-устойчивом хостинге.
Правовые ограничения. Активное сканирование (JARM, port scanning) подозрительных серверов может нарушать законодательство. Passive-методы (CT-логи, passive DNS, публичный WHOIS) правовых рисков не несут, но дают менее полную картину. Вопрос применимости ФЗ-152 к сбору данных из открытых технических источников (WHOIS, DNS, CT-логи) неоднозначен: согласно ст. 3 ФЗ-152, персональными данными считается любая информация, относящаяся к идентифицируемому физическому лицу, и WHOIS-записи регистрантов-физлиц могут подпадать под это определение уже на этапе сбора. Каждый случай требует отдельной юридической оценки.
Анонимизация. Tor, VPN, цепочки прокси между оператором и C2-сервером. Инфраструктурный анализ показывает, что C2-сервер стоит у определённого хостера - но кто его арендовал, из пассивных данных не следует. Разрыв между «чья инфраструктура» и «кто за ней стоит» - фундаментальное ограничение метода.
Автоматизированная атрибуция APT - тема, которую активно развивают в академической среде: десятки публикаций про ML-модели, якобы определяющие threat actor по набору IoC с точностью 95%. На практике я не встречал случая, когда ML-модель дала бы атрибуцию, которую опытный аналитик не сделал бы быстрее и точнее, опираясь на trade-паттерны и ручную корреляцию. Проблема не в алгоритмах - проблема в данных. Публичных датасетов для обучения атрибуционных моделей практически нет (нехватка структурированных данных регулярно упоминается в литературе как один из открытых вызовов). Те датасеты, что существуют, содержат синтетические или устаревшие данные.
Реальная деанонимизация инфраструктуры угроз - это 80% рутинной корреляции WHOIS-записей, SSL-сертификатов и passive DNS. 15% - проверка гипотез через Admiralty System (reliability + credibility каждого факта по методологии Unit 42). И 5% - распознавание аномалий, построенное на сотнях предыдущих разборов. False flags целенаправленно обманывают именно автоматические системы, потому что ML-модели обучены на паттернах, а false flag - это паттерн, созданный для обмана. Единственная защита - мультимодальная проверка: инфраструктурный trade-паттерн должен подтверждаться TTP-анализом, victimology и временной корреляцией. Без этого пересечения любая атрибуция - гипотеза, а не факт.
Попробуйте взять 5–10 доменов из свежего фида (AlienVault OTX, MISP) и прогнать через скрипт выше + SpiderFoot. Если увидите два домена с одним регистратором, зарегистрированных с разницей в пару часов - это уже след. Дальше копайте SSL и passive DNS. Если и там совпадения - у вас activity cluster.
