При разборе инфраструктуры одной Cobalt Strike-кампании ключевой зацепкой оказался не сэмпл и не IP из фида, а CNAME-запись субдомена скомпрометированной организации. Она указывала на Heroku-приложение, удалённое за полгода до инцидента. Этот dangling CNAME позволил восстановить исторический IP через passive DNS, а к нему оказались привязаны ещё четыре домена - два из которых уже фигурировали в TI-фидах как управляющие серверы. Одна забытая DNS-запись, два рабочих дня пивотинга - семнадцать связанных узлов и три автономные системы, за которыми стоял один оператор. Ниже - методология, которая за этим стоит.
Инфраструктура атакующего как объект threat intelligence
Без канала связи между имплантом и сервером управления атака замирает на этапе post-exploitation: оператор не может отдавать команды, выгружать данные, перемещаться по сети. MITRE ATT&CK классифицирует подготовку такой инфраструктуры как Resource Development - T1584.001 (Domains): атакующий приобретает или компрометирует домены для использования в операции. Для бизнеса конечный импакт - утечка данных, шифрование хостов, простой. Для аналитика C2-инфраструктура - это не абстрактный "управляющий сервер", а граф связанных ресурсов, который можно раскопать.[Применимо: threat intelligence, внешняя разведка, SOC L3. Не применимо для внутреннего пентеста - это чистая TI-дисциплина.]
Каждый элемент графа - домены, IP-адреса, TLS-сертификаты, Whois-записи, ASN - содержит метаданные, которые атакующий не всегда контролирует. Passive DNS хранит историческую привязку домена к IP, Certificate Transparency логирует каждый выпущенный сертификат, а Whois-история иногда показывает email регистранта до того, как он включил privacy. Задача деанонимизации C2 инфраструктуры - собрать эти метаданные и через серию пивотов восстановить полную картину операции.
Русскоязычные материалы по C2-хантингу описывают инструменты обнаружения серверов (Shodan, Censys, VirusTotal) и паттерны поиска (HTTP-заголовки, фавиконки, сертификаты). Хорошая база, но она не отвечает на вопрос: кто стоит за инфраструктурой и как связать разрозненные серверы в единую операцию. Именно этот разрыв закрывает методология инфраструктурного пивотинга - от обнаружения dangling CNAME до построения графа оператора.
Dangling CNAME и subdomain takeover: точка входа в C2-разведку
Механика dangling DNS и типы уязвимых записей
Dangling DNS - DNS-запись, которая продолжает указывать на ресурс, которого больше не существует.Согласно OWASP Subdomain Takeover Prevention Cheat Sheet, наиболее уязвимы четыре типа записей:
CNAME - самый распространённый вектор. Если каноническое имя указывает на сервис, который можно заново зарегистрировать (Heroku, GitHub Pages, AWS S3), захват субдомена становится тривиальным. A-записи, указывающие на освобождённые IP-адреса - в облачных средах elastic IP возвращается в пул провайдера, и его может получить другой клиент. NS-записи, делегирующие субдомен стороннему DNS-провайдеру - если аккаунт у провайдера закрыт, любой новый пользователь может заявить права на делегированную зону и контролировать все записи под этим субдоменом. MX-записи, указывающие на деактивированные почтовые сервисы - по данным OWASP, через такую запись можно перехватить почту и пройти email-based domain validation у Certificate Authority, получив легитимный TLS-сертификат на субдомен.
Корневая причина, по которой dangling-записи накапливаются, - разрыв между жизненным циклом облачных ресурсов и DNS-управлением. Команда, создававшая ресурс, может не иметь доступа к DNS. Команда, управляющая DNS, может не знать, что ресурс удалён. Shadow IT, забытые PoC-стенды, DNS-зоны, унаследованные при слияниях компаний - всё это порождает висящие записи, которые никто не контролирует.
Как отмечает AWS CIRT, сервисы с глобально уникальными пространствами имён наиболее подвержены захвату: Amazon S3 (bucket-имена глобально уникальны, заявить может любой аккаунт), Elastic Beanstalk (аналогично). CloudFront менее уязвим - DNS-имя вида
d111111abcdef8.cloudfront.net назначается AWS автоматически. С марта 2026 года S3-бакеты, созданные с региональными пространствами имён, привязаны к аккаунту и не подвержены этой проблеме (по данным блога AWS Security).Для автоматизированного обнаружения dangling-записей есть инструменты с открытым кодом:
dnsReaper (сканер с поддержкой более 40 сервисных fingerprint'ов), nuclei с набором шаблонов для subdomain takeover, community-проект can-i-take-over-xyz(GitHub - EdOverflow/can-i-take-over-xyz: "Can I take over XYZ?" — a list of services and how to claim (sub)domains with dangling DNS records.) - справочник по уязвимым и неуязвимым сервисам (по данным OWASP). Microsoft опубликовала PowerShell-скрипт Get-DanglingDnsRecords.ps1 для проверки Azure-ресурсов.Subdomain takeover C2: от захвата к наблюдению
Для threat intelligence аналитика subdomain takeover интересен в двух сценариях, и оба напрямую связаны с деанонимизацией C2 инфраструктуры.Сценарий 1: атакующий захватывает субдомен жертвы для размещения C2. Прямое применение T1584.001 - оператор находит dangling CNAME на
[I].target.com, заявляет права на ресурс и получает C2-сервер на доверенном домене. Трафик к такому субдомену не вызывает подозрений у сетевых фильтров, потому что родительский домен легитимен. По данным OWASP, атакующий при этом может перехватывать cookies, скопированные на [/I].example.com, обходить CSP-правила с wildcard-доверием к субдоменам и даже получать валидные TLS-сертификаты через автоматическую DNS-валидацию. По данным Censys, HTTPS с padlock в браузере не защищает от subdomain takeover - атакующий может получить легитимный сертификат через платформу, на которую указывает захваченный ресурс.Сценарий 2: dangling CNAME в инфраструктуре самого атакующего. Операторы C2 тоже используют CDN, cloud-хостинги и third-party сервисы для маскировки. Когда кампания завершается, они деактивируют ресурсы, но не всегда чистят DNS. Эти "хвосты" видны в passive DNS и позволяют связать домены, которые оператор считал несвязанными.
В обоих случаях dangling CNAME - не уязвимость для эксплуатации, а индикатор для пивотинга. Обнаружив такую запись, аналитик получает историческую привязку домена к IP через passive DNS, и этот IP становится следующей точкой пивотинга.
Passive DNS для деанонимизации C2 инфраструктуры
Источники и инструменты passive DNS разведки
Passive DNS - база данных, которая записывает исторические DNS-резолюции: какой домен указывал на какой IP, в какой временной период. В отличие от активногоdig-запроса, passive DNS показывает то, что было месяцы и годы назад - даже после удаления или изменения записей.Основные источники для аналитика:
- SecurityTrails - хранит историю A/AAAA/MX/NS/CNAME-записей. Через API или веб-интерфейс можно запросить все исторические IP для домена и наоборот - все домены, которые когда-либо указывали на конкретный IP.
- DNSDB (Farsight Security) - одна из крупнейших passive DNS баз. Поддерживает обратные запросы: по IP получить все связанные домены за заданный период.
- PassiveTotal (RiskIQ, теперь часть Microsoft) - объединяет passive DNS с данными Whois, сертификатов и трекеров. Удобен для построения связей между элементами инфраструктуры в едином интерфейсе.
subfinder и amass - они агрегируют данные из Certificate Transparency логов, DNS-перебора и passive DNS.Практический workflow passive DNS
Типичная цепочка при расследовании C2:- Берём домен из IOC-фида или из результатов анализа сэмпла - допустим,
update-cdn.example[.]com. - Запрашиваем историю в SecurityTrails: текущий
digпокажет IP или NXDOMAIN, а SecurityTrails покажет все IP, на которые этот домен указывал за последние годы. - Делаем обратный запрос по каждому историческому IP. Если IP
185.X.X.Xобслуживалupdate-cdn.example[.]comс января по март - запрашиваем: какие ещё домены указывали на этот IP в тот же период? - Фильтруем результаты. Shared-хостинг даёт сотни доменов на одном IP - это шум. Выделенные серверы (VPS) с 1-5 доменами на IP - сигнал. Если на том же IP в тот же период находились
delivery-api.example2[.]comиreport-portal.example3[.]com- это кандидаты на принадлежность к тому же оператору. - Рекурсивно повторяем для каждого найденного домена. Это и есть IP-пивотинг - расширение графа через итеративные запросы.
dig:
Bash:
dig staging.target.com CNAME +short
# old-app.herokuapp.com
dig old-app.herokuapp.com A +short
# ;; status: NXDOMAIN - ресурс не существует, запись danglingIP-пивотинг и атрибуция оператора C2
Историческая корреляция через Whois и ASN
IP-пивотинг - переход от IP-адреса к другим элементам инфраструктуры через метаданные. Whois-записи, даже при использовании privacy-сервисов, оставляют артефакты: email регистранта, организация, дата регистрации, NS-серверы.Операторы C2 регулярно допускают OPSEC-ошибки, и на этом строится атрибуция:
- Регистрируют несколько доменов через один аккаунт у регистратора с одним email
- Используют одни и те же NS-серверы (характерные для конкретных bulletproof-хостингов)
- Размещают серверы в одной автономной системе (ASN)
- Whois для каждого домена из passive DNS. Если email регистранта не privacy-защищён - делаем reverse Whois: ищем все домены, зарегистрированные на этот email. SecurityTrails и DomainTools поддерживают такие запросы.
- Исторический Whois. Регистранты не всегда включали privacy protection с первого дня. SecurityTrails хранит исторические Whois-снимки - бывает видно, что домен первые месяцы был зарегистрирован на конкретный email, а затем privacy включили. Этот email - сильная ось для пивотинга.
- ASN-кластеризация. Определяем AS для каждого IP в графе. Если четыре из пяти серверов находятся в AS, подконтрольной одному bulletproof-хостеру - это паттерн. Он не доказывает атрибуцию сам по себе, но подтверждает связь между узлами и сужает круг.
Построение графа через Maltego и SpiderFoot
Maltego - основной инструмент для визуализации инфраструктурных связей при деанонимизации C2 инфраструктуры. Рабочий процесс: загрузить начальный домен или IP как корневую сущность, применять трансформы (passive DNS lookup, Whois lookup, reverse DNS, certificate lookup) и наблюдать, как граф расширяется при каждом пивоте. Связи между сущностями видны визуально: домен -> IP -> другие домены -> сертификат -> SAN -> ещё домены.SpiderFoot - альтернатива для автоматизированной инфраструктурной разведки. В отличие от Maltego, он работает в CLI/web-режиме и автоматически запускает десятки модулей (passive DNS, Shodan, Censys, Certificate Transparency) по одному стартовому индикатору. Результаты менее удобны для визуального анализа, но покрывают больше источников за один запуск.
На практике оптимальная связка: SpiderFoot для первоначального широкого сбора, затем Maltego для ручного анализа связей и построения финального графа атрибуции. SpiderFoot находит то, что аналитик мог бы пропустить; Maltego позволяет проследить каждую связь и отсечь ложные совпадения.
| Критерий | Maltego CE | SpiderFoot |
|---|---|---|
| Режим работы | GUI, интерактивный | CLI/Web, пакетный |
| Визуализация графа | Нативно, в реальном времени | Только отчёт/граф после сканирования |
| Покрытие источников | Через трансформы (нужна ручная настройка) | 200+ модулей из коробки |
| Когда использовать | Ручной анализ связей, финальный граф | Первоначальный сбор, wide-scope разведка |
| Когда не использовать | Массовый сбор по сотням индикаторов | Детальный разбор одного узла графа |
Сертификаты и TLS-fingerprinting для OSINT C2 атрибуции
Certificate Transparency и SAN-пивотинг
Certificate Transparency (CT) - публичный лог всех выпущенных TLS-сертификатов. Каждый раз, когда оператор C2 получает сертификат (даже бесплатный Let's Encrypt), запись попадает в CT-лог и становится доступна для поиска.Почему CT критичен для атрибуции:
Subject Alternative Names (SAN). Один сертификат может покрывать несколько доменов. Если оператор выпустил сертификат для
cdn-update[.]com с SAN, включающим report-api[.]net и static-files[.]org - эти три домена связаны. Даже если они размещены на разных IP и в разных ASN.Временная корреляция. Серия сертификатов, выпущенных с одного аккаунта Let's Encrypt в течение короткого окна (несколько часов), часто указывает на автоматизированное развёртывание C2-инфраструктуры.
Issuer fingerprint. Самоподписанные сертификаты или сертификаты от нишевых CA - дополнительный признак для кластеризации. Операторы, использующие нестандартные значения в полях issuer и subject, оставляют воспроизводимый след. Бывает, что в Subject CN прямо указано название фреймворка - по данным исследований C2-хантинга, такие ляпы встречаются чаще, чем хотелось бы атакующим.
Поиск по CT-логам доступен через
crt.sh (бесплатно, запрос вида crt.sh/?q=%.example.com), Censys (API) и SecurityTrails.JARM и JA3S: fingerprinting C2-фреймворков
Помимо атрибутов сертификата, TLS-соединение само оставляет уникальный отпечаток.JA3/JA3S - пассивный метод fingerprinting'а клиентской (JA3) и серверной (JA3S) части TLS-рукопожатия. Собирает параметры из пакетов Client Hello и Server Hello, формирует MD5-хеш. C2-фреймворки (Cobalt Strike, Mythic, Havoc) генерируют характерные JA3S-хеши, по которым их можно идентифицировать в результатах сканирования и в сетевом трафике.
JARM - активный fingerprint TLS-сервера. Отправляет десять специально сформированных TLS Client Hello с разными параметрами и хеширует ответы. JARM-отпечаток стабилен для конкретной конфигурации сервера. Если пять серверов на разных IP дают одинаковый JARM-хеш - это с высокой вероятностью один фреймворк с одной конфигурацией, развёрнутый одним оператором.
Пример поиска в Shodan по характерным HTTP-заголовкам Mythic C2:
Код:
port:80 "Cache-Control: max-age=0, no-cache" "Server: NetDNA-cache/2.2"
"Content-Type: application/javascript" ASN:AS14061404 Not Found с Content-Type: text/plain и Content-Length: 0 без кастомного профиля malleable C2. (Да, в 2025 году люди всё ещё разворачивали CS с дефолтным профилем. Каждый раз удивлялся.)Ограничение: JARM и Shodan-запросы - активное сканирование. Они работают только с живыми серверами. Если C2 уже деактивирован, остаётся опираться на passive DNS и CT-логи.
Практическая цепочка деанонимизации: от IOC до оператора
Требования к окружению:- ОС: GNU/Linux (Kali, Ubuntu 22.04+) или macOS
- RAM: минимум 8 ГБ (Maltego CE потребляет 2-4 ГБ при работе с крупными графами)
- Сеть: online (требуется доступ к API SecurityTrails, Shodan, Censys, crt.sh)
- API-ключи: SecurityTrails (free tier - 50 запросов/мес), Shodan (free tier), Censys (free tier для Search)
- Инструменты:
dig,curl,jq,subfinder(ProjectDiscovery), Maltego CE (free) - Дополнительно: JARM-сканер (GitHub: salesforce/jarm) для активного fingerprinting'а живых серверов
update-service.example[.]com.Шаг 2. Проверяем текущее состояние DNS через
dig update-service.example[.]com A и dig update-service.example[.]com CNAME. Если CNAME указывает на несуществующий ресурс - фиксируем dangling CNAME. Если A-запись возвращает IP - записываем.Шаг 3. Запрашиваем passive DNS историю в SecurityTrails. Смотрим все исторические IP для этого домена. Каждый IP - потенциальная точка пивотинга.
Шаг 4. Reverse DNS для каждого исторического IP. Через SecurityTrails или DNSDB получаем список всех доменов, которые когда-либо указывали на каждый IP. Фильтруем: VPS с 1-5 доменами на IP - приоритет. Shared hosting (100+ доменов) - отбрасываем.
Шаг 5. Whois и reverse Whois для каждого нового домена из шага 4. Исторический Whois - обязательно: даже если сейчас стоит privacy, раньше email мог быть открыт. Совпадение email регистранта по нескольким доменам - сильный сигнал атрибуции.
Шаг 6. Certificate Transparency: запрашиваем
crt.sh/?q=%.example[.]com для каждого связанного домена. Анализируем SAN - альтернативные имена в сертификатах раскрывают дополнительные домены оператора.Шаг 7. TLS-fingerprinting (только для живых серверов): проверяем JARM-хеш через утилиту
jarm или через Shodan, где JARM индексируется автоматически. Совпадение JARM по нескольким IP подтверждает единую конфигурацию.Шаг 8. Визуализация в Maltego. Импортируем все собранные сущности (домены, IP, email регистрантов, сертификаты) и прокладываем связи. Граф наглядно показывает кластеры и узлы-хабы - точки пересечения максимального числа связей.
Результат: от одного стартового домена - граф инфраструктуры с десятками узлов, объединённых по IP-пересечениям, общим Whois-данным, SAN-сертификатам и TLS-отпечаткам.
Ограничения техник деанонимизации C2
Наибольший практический результат даёт комбинация passive DNS и Certificate Transparency. Эти два источника не требуют активного сканирования, полностью легальны и покрывают большинство сценариев, когда атрибуция вообще возможна. Whois и JARM дополняют картину, но редко являются единственной осью для построения графа.
Большинство TI-команд работают в парадигме IOC-matching: получили хеш или домен из фида, проверили в VirusTotal, добавили в blocklist, закрыли тикет. Инфраструктурный пивотинг - переход от одного индикатора к графу операции - остаётся навыком единиц. И дело не в сложности инструментов: SecurityTrails, crt.sh и Maltego CE доступны бесплатно. Дело в подходе. Аналитик, который воспринимает C2-домен как конечную точку для блокировки, и аналитик, который воспринимает его как стартовый узел для пивотинга - два принципиально разных специалиста по ценности для команды. Автоматизированная корреляция инфраструктуры постепенно становится стандартной функцией коммерческих TI-платформ - Censys и Microsoft уже движутся в эту сторону с dangling DNS-детектированием и attack surface management. Но пока это окно открыто, навык ручного пивотинга через passive DNS, Whois и CT-логи - то, что отличает настоящего threat intelligence аналитика от оператора поисковой строки VirusTotal. Возьмите любой C2-домен из свежего TI-отчёта и пройдите описанную цепочку самостоятельно, шаг за шагом. Это единственный способ превратить методологию в рабочий рефлекс.
Последнее редактирование модератором:
