О чем это мы?
Индикатор компрометации редко попадает к нам в свой лучший час. Домен из очередного семпла, адрес с ханипота, строчка из фида или статьи коллег — к моменту, когда аналитик берет его в работу, инфраструктура за ним обычно уже свернута: сервер не отвечает, домен разделегирован или ссылается на пустой адрес (запись в публичных блок-листах появилась раньше, чем тикет в очереди). На первый взгляд это исчерпанный артефакт — констатация того, что уже произошло.
Но индикатор фиксирует не только факт атаки. Он фиксирует точку в инфраструктуре, которую кто-то проектировал, разворачивал и — почти всегда — переиспользовал. Зачастую процессы упрощаются ради ускорения: домены регистрируются партиями у одного регистратора и в одно время, серверы поднимаются по единому шаблону, поверх ложатся типовые SSL-сертификаты и C2-фреймворки с одинаковыми (или очень схожими) настройками. Каждое такое повторение оставляет след, который переживет сам сервер, — он остается в пассивных и исторических данных еще долго после того, как узел уходит в офлайн. Отдельный индикатор, таким образом, оказывается не концом цепочки, а ее обрывком: торчащей из клубка ниточкой, потянув за которую можно проявить остальное. Как известно, один домен для злоумышленника — расходный материал, но выявленная инфраструктура может нанести гораздо больший урон.
Этот переход — от известного индикатора к связанной с ним инфраструктуре — называется пивотингом и составляет одну из основных техник Threat Intelligence. Его ценность заключается в поиске и нейтрализации хостов, находящихся на этапе подготовки к активным действиям. Также пивотинг может связать разрозненные на вид атаки в единую инфраструктуру злоумышленников.
В этой статье мы разбираем пивотинг как набор практических методов и применим их на кейсах, схожих с реальными. Область нашего фокуса будет ограничена сетевым уровнем: доменами, IP-адресами, TLS-сертификатами, портами и баннерами, контентными и криптографическими отпечатками. Файловые и хостовые артефакты — хеши, конфигурации, YARA-правила, поведение в песочнице — могут быть вспомогательными, но не основными целями нашего исследования.
Отдельно — о том, для кого эта статья. Мы намеренно держим ее на уровне общего описания процессов: показываем логику пивотинга и базовый инструментарий, не углубляясь в тонкости конкретных сервисов и пограничные случаи. Это материал для тех, кто только осваивается с темой и хочет собрать целостную картину — понять, как из одного индикатора выстраивается связанная инфраструктура и какими методами это делается. Опытному аналитику многое здесь покажется знакомым; но и ему, возможно, пригодится как систематизация уже привычных приемов.
Все индикаторы в примерах вымышленные и экранированные (example-domain[.]net, адреса вида 185[.]10[.]x[.]x). Реальные цепочки индикаторов компрометации мы не будем рассматривать, остановимся на теоретических адресах.
Кратко об инструментах
Сетевые сканеры
Такие сервисы, как Shodan или Censys, непрерывно обходят весь адресный диапазон интернета и индексируют все, что отвечает: открытые порты, баннеры сервисов, TLS-сертификаты, заголовки HTTP-ответов, контент страниц. Ключевое свойство для пивотинга: поиск работает в обратную сторону — можно взять любой атрибут известного хоста и спросить, где еще в интернете встречается то же самое. Нетипичная комбинация портов, кастомный баннер, самоподписанный сертификат с конкретным Subject — все это становится поисковым запросом.
Passive DNS
Рекурсивные DNS-резолверы по всему миру фиксируют ответы на запросы и передают их в агрегирующие базы — так накапливается история: какой домен на какой IP отвечал и в какой период. В отличие от живого DNS-запроса passive DNS показывает прошлое. Домен может быть давно разделегирован, сервер выключен — но история резолвов сохранится, и по ней можно восстановить, с какими адресами была связана инфраструктура. Обратный запрос работает аналогично: по IP-адресу можно получить все домены, которые на него резолвились.
WHOIS и историческое WHOIS
При регистрации домена регистрант указывает контактные данные — имейл, имя, организацию. До введения GDPR-приватности эти данные были открыты; сейчас актуальная запись WHOIS чаще всего обезличена. Из полезной информации на данный момент доступны только NS-сервера домена, дата регистрации, регистратор и отдельно информация об организации, если домен зарегистрирован не частным лицом.
Certificate Transparency
Все публично доверенные TLS-сертификаты обязаны попадать в открытые CT-логи — это требование браузерных вендоров. Через crt.sh можно искать по домену, wildcard-маске или организации и видеть весь исторический срез выпущенных сертификатов. Самоподписанные сертификаты в CT не попадают, но они индексируются теми же сетевыми сканерами — и там поиск работает уже по криптографическому отпечатку или конкретным полям Subject.
Онлайн-песочницы и URL-сканеры
При динамическом анализе образца песочница фиксирует все, к чему он обращается по сети: домены, IP, URL, паттерны запросов. Это отдельный источник индикаторов, которых нет в статических артефактах. URLScan.io работает иначе: он сканирует URL как браузер и сохраняет снапшот — заголовки ответа, контент, сетевые запросы страницы. Для поиска и анализа фишинговых доменов это удобно: можно посмотреть, как выглядела страница в момент активности, даже если сейчас она уже не отвечает.
Web Archive
Wayback Machine сохраняет снапшоты веб-страниц с разных дат — иногда на годы назад. Для пивотинга это скорее вспомогательный источник: контент страницы мог содержать идентификаторы аналитики, ссылки на связанную инфраструктуру или просто подтверждать, чем именно был ресурс в период активности.
Поисковые системы
Обычный поиск в Google или Yandex может также сказать многое. Если вбить домен или IP в строку поиска, в результатах могут оказаться самые разные источники: технические блоги и публичные отчеты с упоминанием индикатора, базы данных угроз, которые его проиндексировали, записи об образцах в песочницах, которые обращались на этот адрес. Этот метод не дает структурированного результата, но может указать на дополнительные источники контекста.
DNS-утилиты
Иногда нужно просто проверить текущее состояние домена, получить его резолв и иные записи. DNS Trace Test показывает цепочку делегирования от корневых серверов до авторитативного — видно, где именно рвется цепочка, если домен не резолвится. DNSChecker проверяет резолвинг с разных точек мира одновременно: возможная ситуация, когда домен отдает разные A-записи для разных регионов мира, а возможно, для одного конкретного, на который направлена атака.
Перейдем к первому кейсу.
Кейс 1. «Мертвый» домен
Домен из конфига вредоносного семпла — update-service-cdn[.]net — на данный момент уже не резолвится. Разберемся, с чем он был связан.
Проверка DNS-резолва
Убедимся, что домен действительно не резолвится глобально: запрашиваем несколько публичных резолверов напрямую, к примеру 8.8.8.8, 1.1.1.1 и авторитативный NS домена. При использовании локального резолва через nslookup, а не онлайн-инструментов обязательно используем VPN, для сокрытия нашего адреса от злоумышленника. Все возвращают NXDOMAIN = домен не резолвится. Далее работаем с историческими данными.
Passive DNS
В SecurityTrails запрашиваем историю A-записей update-service-cdn[.]net. Выявлены два исторических IP:
- 233.252.139[.]120 — обнаружен в последний раз год назад
- 198.19.21[.]93 — последние две недели перед тем, как домен перестал отвечать
Берем 198.19.21[.]93 — хронологически ближе ко времени вредоносной активности. По старому адресу 233.252.139[.[120 на данный момент уже находится легитимный ресурс, в дальнейшем его не рассматриваем.
В MX-записи получаем другой домен: mx.serviceupdater[.]io — не относится к популярным почтовым сервисам и, вероятно, принадлежит атакующим. Поиск по аналогичной MX-записи отдает схожие домены, часть из которых все еще активна:
- update-service-cdn[.]net
- telemetry-gateway[.]org
- cdn-static-assets[.]com
- ms-update-check[.]net
Можно также обратить внимание на единую тематику доменов, что может помочь для кластеризации доменов одной группировки.
Сетевые сканеры
Проверив IP-адреса доменов, указанных выше, в сетевых сканерах, видим схожести:
- У всех открыты одинаковые порты 22, 443, 8808 и 9091.
- На порту 9091 есть одинаковый самоподписанный сертификат.
Используем эту информацию для поиска аналогичных хостов в интернете. На этом этапе желательно использовать несколько отдельных сервисов, не упираясь только на Censys или Shodan — у большинства есть система Opt-Out of Data Collection, которую иногда используют злоумышленники для сокрытия своих хостов. Да и подсети, используемые для сканирования, публично раскрываются, что позволяет заблокировать их на уровне фаервола.
Примеры запросов для Censys:
host.services.port: 22 and host.services.port: 443 and host.services.port: 8808 and host.services.port: 9091 and host.service_count: 4
host.services.tls.fingerprint_sha256 = "004b73abc7082568a07182924623a26973fb7f4ab4ed30a5f022c3fa17c355eb"
Такой поиск после отсечения случайно попавших адресов дал нам еще несколько адресов, часть из которых еще не были замечены в атаках. Таким образом, мы уже получили информацию о будущих атаках и, возможно, их предотвратили.
Кейс 2. Фишинг, которого нет
Домен пришел из фида блокировок с пометкой «фишинг». Открываем — 403, 404 или пустая страница. Контент исчез, но кампания, скорее всего, переехала. Задача — восстановить страницу в рабочем виде и по ее отпечаткам найти действующие зеркала.
В работе — phish-login[.]example.
Поисковые сервисы
Грубо, но быстро — прогоняем домен через поисковые системы.
В результатах — ссылка на снимок в URL-сканере и упоминание в разборе фишинговой кампании от коллег иной организации. Займемся восстановлением оригинальной страницы.
Идем в Web Archive. Если домен заархивирован в период активности, получаем оригинальную верстку — форму ввода учетных данных, которую домен сейчас не отдает, как и остальную верстку сайта. Если в Web Archive данных нет, воспользуемся такими песочницами, как URLScan.
В снапшоте URLScan.io ищем то, что привязано к конкретному оператору: токен телеграм-бота, адрес для приема учеток, нестандартный путь к обработчику формы, идентификатор счетчика или партнерской метки. Такие строки переезжают вместе с остальной версткой и почти не меняются. По ним впоследствии можно найти индексированные зеркала в поисковых системах или сетевых сканерах.
Сетевые сканеры
Снимаем с хоста фавикон-хеш и хеш баннера. На этом этапе обращаем внимание: разные сервисы генерируют хеши по разным алгоритмам, поэтому зачастую поиск по хешу из одного сервиса может не дать результатов в другом. Если на сайте стандартный фавикон фреймворка или CMS, такой признак придется отбросить — даст тысячи ложных совпадений. Оставшуюся связку отдаем в сетевые сканеры и ищем хосты с тем же фавиконом и баннером. Параллельно ищем по уникальным строкам: токен или адрес из формы выводит на другие живые сайты той же кампании. По итогам получаем несколько адресов с совпадающими признаками, часть из которых находятся в одной подсети.
Passive DNS
Параллельно можем проверить всю подсеть: некоторые сервисы поддерживают функцию IP Neighbors, при помощи которой можем просмотреть домены, привязанные к соседним адресам в той же подсети, что и исследуемый адрес. phish-login[.]example резолвится в 198.51.100[.]47. Запрашиваем соседей по подсети внутри одной ASN (получить можем при помощи whois-записи IP-адреса), в нашем случае –198.51.100[.]40/29 и на смежных адресах находим secure-login-verify[.]example, account-update-portal[.]example и id-confirm-bank[.]example. Один адрес еще не имеет развернутого фронта, два остальных — имеют отличную от оригинала верстку, отчего не были найдены на прошлом этапе. Используя их как исходную точку, можем повторить процесс и, вероятно, найти остальные адреса.
WHOIS
Домены, перечисленные выше, были зарегистрированы в один день, одним регистратором и в одной доменной зоне, что позволяет нам выявить сходство и найти по ней остальные домены, еще не обнаруженные в атаках.
Выгружаем базу доменов, зарегистрированных в этой доменной зоне в нужный день (при наличии такой базы в интернете). Ищем домены с нужным регистратором и NS-записями, отсеиваем лишние (в зависимости от зоны их может быть как десятки, так и тысячи — по возможности автоматизируем процесс).
Данный способ может использоваться, когда другие методы не дали значительного результата и есть уверенность в существовании других доменов.
Кейс 3. C2 за занавесом
Адрес пришел с активного инцидента — lasdjfpafsp[.]malwaredomain[.]example, управляющий сервер вредоносного образца. Домен резолвится, но при открытии его (разумеется, не раскрывая свой IP-адрес) — 404 или заглушка. Задача — пробиться к панели управления и от нее развернуть инфраструктуру: соседние домены, еще не поднятые хосты, контекст по семейству.
В работе — malwaredomain[.]example.
Passive DNS
Берем не сам C2-поддомен, а родительский домен. В subdomainfinder запрашиваем поддомены malwaredomain[.]example. Кроме случайной строки из конфига — lasdjfpafsp[.], — выявлено еще несколько. Среди них control[.]malwaredomain[.]example: не DGA-домен, имеет осмысленное слово, имеет A-запись. Похоже на точку администрирования. При входе возвращает 403 (Forbidden). Берем в работу.
DNS Checker
Резолвим control[.]malwaredomain[.]example через сервис, опрашивающий резолверы из разных стран. Ответ зависит от региона: на наши резолверы отдается IP с заглушкой, на резолверы из другой географии — другой A-record.
По адресу 233.252.0[.]183 — живая веб-панель администрирования C2.
На нашем опыте различные IP в зависимости от геолокации встречались один раз, но такой метод может использоваться, а значит, о нем нужно знать.
Сетевые сканеры
Открываем второй IP — отдает панель. Снимаем фавикон-хеш и хеш баннера. Прогоняем по сетевым сканерам, ищем хосты с тем же фавиконом и баннером. На этот раз — запросы в FOFA:
icon_hash="708578229"
body_hash="-1173804887"
Находим еще несколько адресов с той же панелью. Домены у них другие, к malwaredomain[.]example не привязаны — но билд панели один. Это вторая ветка инфраструктуры того же оператора, которую по DNS мы бы не нашли. Аналогично через PDNS можем найти DGA-поддомены, используемые в семплах как C2, и добавить в списки блокировок.
Поисковые сервисы
Ищем найденные домены в Google/Yandex — обнаруживаем упоминание в статье вендора, который проводит атрибуцию. Подтверждаем вредоносность найденных индикаторов и принадлежность к Threat Actor’у.
Аналогично прошлым кейсам, можем проводить дополнительные проверки. Основные пункты все же заключают в себя сетевые сканеры для поиска IP адресов и Passive DNS для обнаружения доменов, размещенных на найденных IP.
Worth noting
Используйте весь возможный инструментарий во время пивотинга, чтобы добиться максимального результата. Проводите цикличные проверки: провели раунд поисков — нашли хосты/домены — провели новый раунд, опираясь на новые данные, пока цикл не замкнется на отсутствии новых данных.
Все активные проверки (резолв доменов локально, обращение на сайт со своего устройства) обязательно делаем при включенном VPN или ином способе анонимизации трафика — некоторые злоумышленники могут мониторить активность и скрывать элементы инфраструктуры при нестандартных подключениях. Необходимо отдавать приоритет пассивным средствам разведки, описанным в статье.
Всегда нужно помнить про IP-адреса хостингов, содержащие сайты нескольких пользователей на одном адресе — в таком случае IP-адрес придется отбросить, поскольку он не принадлежит злоумышленнику полноценно. Аналогично нужно отбрасывать адреса Anti-DdoS-сервисов и CDN, чтобы случайно не задеть легитимные ресурсы.
Дефолтные фавиконы и дефолтный баннер (к примеру, 404 у nginx) — слабые признаки сами по себе. Стандартный favicon фреймворка или CMS дает тысячи совпадений в сетевых сканерах, среди которых легитимные хосты будут преобладать. Такой признак работает только в связке favicon + нетипичный порт + баннер, в идеале — если совпадает TLS-сертификат. Favicon, в отрыве от иных признаков, сильно увеличивает шум и ложные зацепки.
NS-, MX- и прочие записи крупных провайдеров не основание для связи. Если десятки тысяч доменов используют одни и те же NS-серверы Cloudflare или почту популярного хостера, совпадение по этой записи ничего не доказывает. Необходимо кластеризировать по записям, специфичным для инфраструктуры: собственные NS, нестандартная MX, редкая TXT.
Отсутствие данных в сканере и отсутствие PDNS-записей не обязательно является доказательством отсутствия инфраструктуры:
- Злоумышленники регистрируют свои подсети в процедуре opt-out, чтобы выпасть из выдачи Shodan, Censys и аналогов.
- Резолвы могли проходить через другие DNS-сервера, отчего они не появлялись в конкретном PDNS-сервисе.
Хост может быть жив и активен, но невидим конкретному сканеру. Поэтому желательно использовать весь возможный инструментарий, чтобы убедиться в отсутствии каких-либо признаков работоспособности хоста.
И сквозной принцип, к которому все сводится: один совпавший признак — это гипотеза, но не связь. Связь возникает на пересечении нескольких независимых признаков. Артефакты в киберпространстве все еще легко подделать, особенно если у атакующих есть задача провести операцию «под чужим флагом», поэтому при вынесении суждений об атрибуции важно избегать однозначных формулировок. Неправильная атрибуция может повлиять на уровень доверия к вашей киберразведке со стороны потребителей, а также снизить эффективность принимаемых в организации защитных мер.
Автоматизированные средства могут заметно упростить жизнь аналитику, однако их результаты так или иначе желательно перепроверять. Полностью заменить аналитика скриптом, увы, не получится.
Надеемся, наш обзор поможет начинающим и продолжающим специалистам Threat Hunting и Threat Intelligence показать лучшие результаты. Удачной охоты!
