Один домен -
sempersim[.]su - засветился в фиде ThreatFox как C2 для LokiBot. Через четыре DNS-пивота от этого единственного индикатора я вышел на кластер из 25+ хостов: фишинговые домены под iCloud, инфраструктура Xworm и Remcos на динамических DNS-сервисах, общий CIDR-диапазон с 464 подозрительными доменами. Два часа работы, бесплатные инструменты, ноль магии.Русскоязычных разборов этой методологии с реальными запросами и конкретными pivot-точками я не встречал. Так что разберём пошагово - от первого домена до полной карты.
Почему инфраструктура акторов поддаётся картированию
Пивотинг по инфраструктуре работает не потому что акторы некомпетентны. По данным Censys, причины системные - и связаны с тем, как устроена их операционка.Масштабирование требует автоматизации. Темп кибератак вырос настолько, что каждый C2-сервер руками не настроишь. Акторы разворачивают инфраструктуру через готовые образы или скрипты, и за ними остаются повторяющиеся артефакты: одинаковые HTTP-заголовки, идентичные самоподписанные сертификаты, характерные баннеры.
Разделение ролей. Оператор, проводящий атаку, понимает OPSEC-риски. Но инфраструктуру часто разворачивает другая команда - и у неё нет полной картины того, какие артефакты видны Shodan и Censys.
Необходимость выглядеть легитимно. Фишинговые домены должны имитировать реальные сервисы (iCloud, Microsoft 365), что создаёт предсказуемые паттерны именования. C2-серверы мимикрируют под стандартные веб-серверы, но делают это шаблонно.
Отсутствие OPSEC-by-design. По наблюдениям Censys, большинство акторов не проектируют инфраструктуру с оглядкой на TI-аналитиков. Они улучшают OPSEC реактивно - после публикации отчёта о своей активности, а не до. Это окно и используем.
Между развёртыванием C2 и его применением в атаке проходит время. За это время аналитик может обнаружить сервер через сканирование баз данных Scan Databases (T1596.005, Reconnaissance) или анализ Passive DNS (T1596.001, Reconnaissance).
Карта разведывательных техник по MITRE ATT&CK
Каждый тип пивота - конкретная техника из тактики Reconnaissance:| Тип пивота | Техника ATT&CK | ID | Что даёт |
|---|---|---|---|
| Passive DNS | DNS/Passive DNS | T1596.001 | История резолвов, связанные домены |
| WHOIS | WHOIS | T1596.002 | Email регистранта, организация, nameserver |
| TLS-сертификаты | Digital Certificates | T1596.003 | SHA-1/CN сертификатов, CA, время выдачи |
| Shodan/Censys | Scan Databases | T1596.005 | Баннеры, порты, заголовки, JARM |
| CIDR-запрос к pDNS | DNS/Passive DNS | T1596.001 | Соседние хосты в том же ASN |
Контекст: всё описанное ниже - работа CTI-аналитика на стороне защиты. Зеркально те же техники использует атакующий для разведки цели (T1590.001 Domain Properties, T1590.002 DNS, T1590.005 IP Addresses), но вектор направлен в обратную сторону: мы исследуем инфраструктуру актора, а не жертвы.
Passive DNS анализ: от домена до кластера хостов
Passive DNS - агрегированная история DNS-резолвов: какой домен указывал на какой IP, в какие даты, через какие NS-серверы. В отличие от активного DNS-запроса, pDNS показывает не текущее состояние, а полную временную шкалу. Это критично: акторы регулярно меняют IP-адреса, но структура именования доменов и выбор хостинг-провайдеров остаются стабильными.
Пошаговый пивотинг на примере LokiBot
Реальный кейс из анализа Embee Research. Отправная точка - доменsempersim[.]su, зафиксированный на ThreatFox как LokiBot C2.Шаг 1: История IP. Запрос по домену в Validin (или аналогичном pDNS-сервисе) возвращает полный список IP-адресов, на которые указывал домен с 2022 года. Куча короткоживущих IP - значит, актор регулярно ротирует инфраструктуру. Скорее всего, в ответ на блокировки.
Шаг 2: Пивот по последнему IP. Самый свежий IP -
104.237.252[.]28. Обратный запрос (pivot по IP) показывает все домены, резолвившие на этот адрес за последние две недели. Результат: 6 доменов, четыре из которых имитируют iCloud (используют l вместо I - lcloud.com[.]de). Классический typosquatting.Шаг 3: Lookalike-поиск. Фишинговый домен
lcloud.com[.]de подсказывает паттерн. Поиск похожих доменов (lookalike feature) возвращает свыше тысячи результатов с аналогичной опечаткой. Первый из них - lcloud.com[.]se - ведёт на IP 194.195.220[.]41 (октет верифицирован по оригиналу Embee Research) с 9 детектами на VirusTotal и связями с червём Bagle.И вот тут становится интересно для атрибуции APT группировок: два разных семейства малвари (LokiBot и Bagle) делят инфраструктуру или используют один паттерн доменного именования. Точная атрибуция выходит за рамки одного пивота, но связь зафиксирована - и её можно развить.
Расширение через CIDR-диапазон
Другой пример из того же исследования. Доменmarxrwo9090.duckdns[.]org (Xworm, ThreatFox) резолвит на 194.147.140[.]138. Пивот по IP выявляет 25 доменов на duckdns, один из которых прямо содержит febxworm39090 в имени. Ну, спасибо за подсказку.Дальше - расширение на CIDR. IP принадлежит диапазону
194.147.140.0/24. Запрос по всему /24 в pDNS-сервисе возвращает 1468 доменов, из них 464 используют duckdns. Первый из результатов - elastolut.duckdns[.]org - имеет 11 детектов на VT и связан с Remcos.Инструменты для passive DNS анализа:
| Инструмент | Бесплатный доступ | Особенности | Ограничения |
|---|---|---|---|
| Validin | Community-версия | Таймлайны, lookalike-поиск | Глубина истории ограничена |
| CIRCL Passive DNS | Да (для исследователей) | Интеграция с MISP | Нет GUI, только API |
| SecurityTrails | 50 запросов/мес | DNS-история + WHOIS | API нестабилен на free-тире |
| Farsight DNSDB | Нет (коммерческий) | Самая глубокая история | Стоимость от $500/мес |
Требования к окружению: Для воспроизведения описанных пивотов достаточно браузера и бесплатного аккаунта Validin. Для автоматизации - Python 3.8+, библиотека
requests, доступ в интернет. RAM и CPU не критичны - вся тяжёлая работа на стороне сервисов.Censys и Shodan для идентификации C2-серверов
Passive DNS показывает связи между доменами и IP. Shodan для OSINT и Censys threat hunting решают другую задачу: они индексируют то, что запущено на этих IP - открытые порты, HTTP-заголовки, TLS-сертификаты, баннеры сервисов. Это позволяет кластеризовать хосты не по DNS-истории, а по конфигурации.
Кластеризация по HTTP-заголовкам
Классика - обнаружение Cobalt Strike серверов. По данным Censys, типичный ответ дефолтного CS-сервера: HTTP 404, Content-Typetext/plain, Content-Length 0, наличие Date-заголовка и отсутствие Server-заголовка. Ни один легитимный веб-сервер такую комбинацию по умолчанию не генерирует.Запрос для поиска таких хостов в Censys:
Код:
services.http.response.status_code=404 and services.http.response.headers.Content_Type="text/plain" and not services.http.response.headers.Server: *Ограничение: Cobalt Strike Malleable C2 Profiles позволяют операторам кастомизировать заголовки ответа. Профили с добавленным Server-заголовком и изменённым Content-Type уклоняются от этого фильтра. Так что поиск по заголовкам бьёт по дефолтным и лениво настроенным инсталляциям - а таких в публичных базах Censys исторически хватает.
Пивотинг по TLS-сертификатам
Сертификаты - одна из самых сильных pivot-точек для картирования инфраструктуры хакеров. Акторы часто переиспользуют самоподписанные сертификаты на нескольких серверах или оставляют характерные паттерны в Distinguished Name.Пример из отчёта NCSC UK (июль 2020): APT29 (Cozy Bear) атаковала организации, связанные с разработкой вакцины от COVID-19, через малварь WellMess и WellMail. Группировка использовала специфические самоподписанные сертификаты, что позволило отследить все связанные серверы по SHA-256 отпечатку. Censys прямо пишет: такие сертификаты "made them easy to track, as reported by several sources""Как сообщают несколько источников, это облегчило их отслеживание.".
Для Cobalt Strike есть дефолтный сертификат с SHA-256:
Код:
87f2085c32b6a2cc709b365f55873e207a9caa10bffecf2fd16d3cf9d94d390ccrt.sh для разведки через Certificate Transparency
Certificate Transparency (CT) - публичные логи всех выданных TLS-сертификатов. Сервис crt.sh ищет по домену и возвращает все когда-либо выданные сертификаты, включая поддомены (subdomain enumeration). Работает бесплатно и без лимитов - редкость для разведки по сертификатам.Запрос
%.example[.]com в crt.sh вернёт все сертификаты для поддоменов - включая staging, dev, internal-сервисы, которые актор мог не предполагать общедоступными. Каждый найденный поддомен дальше проверяется через pDNS для выяснения текущего и исторического IP.WHOIS и ASN-пивотинг: расширение карты
WHOIS-данные (T1596.002, Reconnaissance) - метаинформация о регистрации домена: email регистранта, организация, дата регистрации, nameserver. Даже при использовании privacy-сервисов акторы допускают ошибки:
Email регистранта. Один email фигурирует в WHOIS нескольких доменов. Пивот по email через SecurityTrails или DomainTools раскрывает весь портфель доменов.
Nameserver. Акторы часто используют один DNS-провайдер для всей инфраструктуры. Shared nameserver - слабый, но полезный индикатор для кластеризации.
ASN и хостинг-провайдер. Если C2-сервер размещён у определённого провайдера, расширение поиска на весь ASN (как в примере с Xworm -
/24 CIDR) может выявить соседние хосты того же актора.Отдельная история - bulletproof-хостинг. Провайдеры вроде тех, что упоминаются в CIRCL MISP OSINT feed (событие PFCloud Bulletproof Hosting), намеренно игнорируют abuse-жалобы. Высокая концентрация вредоносных хостов в определённых ASN - сам по себе индикатор, но требует осторожности: не каждый хост в "грязном" ASN принадлежит исследуемому актору.
Автоматизация OSINT по IP-адресам и доменам
Ручной пивотинг через GUI хорош для единичных индикаторов. Когда IOC десятки - нужна автоматизация. Censys предоставляет Python-библиотеку для программного доступа.Требования к окружению: Python 3.8+, библиотека
censys (pip install censys), API-ключ (бесплатный тир: 250 запросов/мес). Работает офлайн до момента отправки запроса.
Python:
from censys.search import CensysHosts
h = CensysHosts()
# Поиск хостов с конкретным CN в сертификате
query = 'services.tls.certificates.leaf.subject.common_name: "*.suspect-domain.com"'
for host in h.search(query, per_page=25):
print(host["ip"], host.get("services", []))Для массовой проверки IP через AbuseIPDB (free tier: 1000 запросов/день, endpoint
/api/v2/check) стоит учитывать порог confidence score: значение выше 75 рекомендуется как cutoff для блокирования, но для TI-аналитики полезны и низкие значения - они показывают, что IP попадал в поле зрения других исследователей.Ограничения инфраструктурного пивотинга
По данным Mandiant M-Trends 2025, медианное время нахождения злоумышленника в сети до обнаружения - 11 дней, исторический минимум. Инфраструктурный пивотинг способен сократить это ещё: обнаружить C2 до его использования в атаке, на этапе подготовки. Но только если аналитик понимает границы метода и не выдаёт корреляцию за каузацию.
Пивотинг по инфраструктуре - не волшебная кнопка "найти актора". Это набор разведывательных примитивов, каждый из которых даёт вероятностную связь, а не доказательство. Реальная ценность - в пересечении нескольких независимых пивотов: pDNS указывает на тот же IP, что и сертификат, а WHOIS подтверждает того же регистранта. Три слабых индикатора, сходящихся к одной точке, весят больше одного сильного.
За три года работы с этими инструментами я пришёл к выводу, который многим покажется контринтуитивным: главная проблема инфраструктурного пивотинга - не недостаток данных, а их избыток. Любой домен через два-три пивота связывается с тысячами хостов, и без жёсткой методологии отсечения шума аналитик тонет в ложных связях. Умение остановиться и сказать "здесь пивот ненадёжен, потому что это shared hosting" - вот что отличает исследователя от человека, рисующего красивые графы в Maltego. Индустрия тратит непропорционально много времени на обсуждение новых источников данных и мало - на формализацию критериев, когда данным не стоит доверять. Может, следующий прорыв в CTI будет не в новом API, а в стандартизированной шкале достоверности пивотов - что-то вроде CVSS, но для confidence инфраструктурных связей.
Последнее редактирование модератором:
