Аналитики информационной безопасности занимаются странной работой. Они ищут связи между вещами, которые не должны быть связаны. Берут один цифровой след и пытаются дотянуться до другого, потом до третьего, пока не выстроится цепочка. Процесс называется пивотингом, и без него большая часть расследований застревает на первом же шаге.
Суть проста есть домен, с которого распространяется вредоносный файл. Проверяешь, на каком сервере этот домен размещен. Смотришь, какие еще домены живут на том же сервере. Проверяешь их сертификаты, структуру страниц, встроенные скрипты. Постепенно разрозненные точки складываются в карту инфраструктуры. Иногда выходишь на целую сеть, хотя начинал с одного подозрительного адреса.
Проблема в том, что про пивотинг все говорят по-разному. Термины заимствованы из криминалистики, статистики, анализа социальных сетей, криптографии. Один специалист называет цифровой след индикатором, другой — точкой данных, третий — наблюдаемым объектом. Когда команды обмениваются информацией, половина времени уходит на выяснение, о чем вообще речь.
Поэтому разберем базовые понятия. Не как в учебнике, а как их используют аналитики, которые реально копаются в инфраструктуре злоумышленников.
Точки данных и почему они не равны между собой
Точка данных любой элемент, который можно использовать для установления связи. IP-адрес сервера, доменное имя, хеш файла, название cookie, структура HTTP-заголовков. Даже QR-код на скриншоте или иконка сайта.
Большинство аналитиков фокусируется на том, что называют сильными индикаторами. IP-адреса, домены, криптографические хеши файлов. Логика понятна: эти элементы уникальны, их сложно подделать, они дают высокую точность. Проблема в том, что злоумышленники про это знают.
Смена IP занимает минуты. Новый домен регистрируется за пару кликов. Файлы перекомпилируются с измененными хешами. Инфраструктура разворачивается заново быстрее, чем аналитик успевает задокументировать находки. Гонка, в которой защищающаяся сторона всегда отстает на шаг.
Злоумышленники меняют то, что считают важным. Но при развертывании инфраструктуры они копируют шаблоны. Берут готовый набор файлов для фишингового сайта и разворачивают его на новом домене. Меняют текст, картинки, может быть цветовую схему. Забывают про иконку сайта. Про название cookie, которое задано в конфигурационном файле.
Про код Google Analytics, встроенный в шаблон. Про структуру HTML, которая остается идентичной.
Иконка размером шестнадцать на шестнадцать пикселей. Название технического cookie. Например, при переходе на поддельную страницу ВТБ браузер может установить cookie с названием yandex_gid или sberbank_session такие имена не совпадают с доменом мошенников.
Проверить это легко в Chrome откройте DevTools (F12) → вкладка Application → Cookies.
Порядок HTTP-заголовков при ответе сервера. Мелочи, на которые никто не обращает внимания.
Проверяйте домен дважды даже vtb-secure.com` не ВТБ. Официальные сайты редко используют дефисы и цифры в названии.
Откройте исходный код (Ctrl+U): поиск по словам metrika, cookie, favicon.ico займёт 10 секунд.
Используйте расширения Netcraft помечает фишинговые страницы на основе анализа инфраструктуры.
Когда вычисляешь хеш иконки сайта и ищешь другие ресурсы с таким же хешем, находишь связи, которые невозможно обнаружить через традиционные индикаторы. Домены разные, IP-адреса разные, хостинг-провайдеры разные. Но иконка одна. Потому что злоумышленник скопировал папку с файлами и не подумал, что favicon.ico может кого-то заинтересовать.
Поисковые системы вроде Shodan давно индексируют такие элементы. Можешь искать серверы по хешу иконки или по структуре HTTP-заголовков. Censys идет дальше — позволяет строить запросы по комбинации слабых индикаторов. Netlas добавляет возможность поиска по содержимому страниц и техническим параметрам одновременно. Validin специализируется на корреляции доменов через пассивный DNS и сертификаты.
То же самое с названиями cookies. Веб-приложение сохраняет в браузере пользователя небольшой файл с данными сессии. Название этого файла жестко прописано в коде. Когда разворачивается новый сайт из того же шаблона, название cookie остается прежним. Значение cookie меняется для каждого пользователя, но имя — константа. И эта константа связывает разные домены так же надежно, как общий IP-адрес.
Структура HTTP-заголовков тоже стабильна. Когда сервер отвечает на запрос браузера, он отправляет набор технических параметров: тип сервера, кодировку, настройки кеширования, информацию о сжатии. Порядок этих параметров и их комбинация зависят от конфигурации сервера. Если злоумышленник разворачивает несколько серверов по одной инструкции или с одного образа, структура заголовков будет совпадать.
Когда злоумышленники развёртывают фишинговые сайты из готовых шаблонов, они редко меняют технические детали конфигурации серверов. Даже при разных доменах и IP связанные серверы оставляют «цифровые следы», которые можно автоматически обнаружить.
Хеш HTTP-заголовков идентификатор конфигурации
При каждом запросе сервер отправляет HTTP-заголовки метаданные вроде Server: nginx/1.18, X-Content-Type-Options: nosniff`. Их порядок и содержание зависят от настроек ПО. Если собрать эту последовательность и вычислить её хеш (например, SHA-256), получится уникальный идентификатор конфигурации.
JARM анализ TLS-рукопожатия
JARM метод идентификации серверов по параметрам установки защищённого соединения (TLS).
Он учитывает:
- Поддерживаемые версии TLS и алгоритмы шифрования;
- Набор расширений (SNI, ALPN);
- Время ответа на тестовые запросы.
Результат преобразуется в 62-символьную строку. Например, хеш 07d14d16d21d21d00042d41d00041de5b2f0b93a177f0f3a93a177f0f3a93a17 указывает на конкретную конфигурацию Nginx или Apache.
Если два сервера имеют одинаковый JARM, они почти наверняка используют общий образ или шаблон развёртывания.
Shodan позволяют сканировать интернет на такие отпечатки:
ssl.jarm:"29d29d00029d29d00042d43d00042d43d00042d43d00042d43d00042d41c122e" найдёт все серверы с этой конфигурацией. Censys покажет дополнительные детали.
Установите расширение JARM Scanner для браузера оно покажет TLS-отпечаток сайта. Если он совпадает с известными вредоносными хешами, закройте страницу.
Слабые индикаторы называются слабыми, потому что дают много ложных срабатываний при изолированном использовании. Иконка может быть стандартной для популярного движка сайтов. Название cookie может совпадать, потому что разные люди используют одну библиотеку. Структура заголовков может быть общей для всех серверов одного хостинг-провайдера.
Но злоумышленники не думают про эти элементы как про индикаторы. Не пытаются их скрыть. Не меняют при каждом развертывании. Стабильность делает их ценными, даже если точность низкая.
Самые эффективные зацепки находятся не там, где их ищут. Не в том, что специально защищают, а в том, что считают незначительным.
Почему терминология важнее чем кажется
Когда аналитики из разных организаций обмениваются данными, они сталкиваются с проблемой языка. Один отправляет список индикаторов компрометации. Другой получает точки данных без пометок об их статусе. Третий интерпретирует все как готовые к использованию сигнатуры для блокировки.
Индикатор компрометации в строгом смысле элемент, который можно использовать для автоматического обнаружения или блокировки угрозы. IP-адрес командного сервера. Хеш вредоносного файла. Домен фишингового сайта. То, что попадает в правила межсетевого экрана или систему обнаружения вторжений.
Точка данных более широкое понятие. Любой элемент, который помогает установить связь или продвинуться в расследовании. Может быть слабым, неоднозначным, требующим дополнительной проверки. Не обязательно готов к автоматическому использованию, но полезен для аналитика.
Разница критична. Если назвать слабую точку данных индикатором компрометации и передать в систему блокировки, получишь массу ложных срабатываний. Заблокируешь легитимные ресурсы, создашь проблемы пользователям, подорвешь доверие к системе защиты. Если, наоборот, проигнорировать точку данных, потому что она не дотягивает до статуса индикатора, потеряешь важную зацепку для расследования.
Терминология не педантизм. Четкие определения помогают избежать ошибок, когда информация передается между людьми, между командами, между организациями. Особенно когда речь про автоматизированные системы, которые принимают решения на основе полученных данных.
Поэтому дальше будем использовать термин "точка данных" для всего, что можно сопоставить и связать. Индикатором назовем только то, что уже прошло валидацию и готово к оперативному использованию. Разница между ними — этап обработки и уровень уверенности, а не природа самого элемента.
Корреляция или как превратить совпадения в доказательства
Корреляция — процесс поиска связей между точками данных. Звучит просто, работает сложно. Берешь два элемента и проверяешь, есть ли между ними что-то общее. Два сайта используют один код аналитики. Два файла имеют похожую внутреннюю структуру. Несколько доменов резолвятся на один IP-адрес.
Нашел совпадение получил корреляцию. Проблема в том, что совпадение ничего не доказывает.
Два сайта могут использовать один Google Analytics ID, потому что принадлежат одному владельцу. Или потому что кто-то скопировал код с чужого сайта не разобравшись. Или потому что ID взят из публичного туториала по созданию веб-страниц. Совпадение есть, но природа связи неясна.
Несколько доменов на одном IP-адресе могут указывать на общую инфраструктуру злоумышленников. Или на то, что все они размещены у одного shared-хостинг провайдера, где сотни клиентов делят один сервер. IP совпадает, но связи между владельцами доменов нет.
Два файла с похожей структурой могли быть скомпилированы одним инструментом. Или собраны из популярной библиотеки, которую используют тысячи разработчиков. Структурное сходство налицо, но общий источник не обязательно означает общего оператора.
Одиночная корреляция — зацепка, не вывод. Гипотеза, требующая проверки. Направление для дальнейшего исследования, а не готовый результат.
Когда находишь не одно совпадение, а три, четыре, пять независимых элементов, указывающих в одну сторону, вероятность случайности падает. Два сайта имеют одинаковую иконку. Используют одно имя cookie. Структура HTML идентична. Код аналитики совпадает. Домены зарегистрированы в один день. Каждый элемент по отдельности объясним случайностью или использованием общего инструмента. Все пять одновременно — устойчивый паттерн.
Такой подход называется композитной корреляцией. Вместо поиска одного сильного индикатора собираешь несколько слабых и проверяешь, сходятся ли они. Слабые точки данных перестают быть слабыми, когда работают вместе.
Представь ситуацию: обнаружена фишинговая страница, имитирующая банковский сайт. Домен свежий, зарегистрирован через сервис анонимизации. IP-адрес принадлежит облачному провайдеру с миллионами клиентов. TLS-сертификат выпущен автоматически и бесплатно. Все традиционные индикаторы ведут в тупик. Ничего уникального, ничего зацепляющего.
Но извлекаешь иконку сайта. Вычисляешь хеш. Ищешь другие ресурсы с таким же хешем через Shodan или Censys. Находишь четыре домена. Проверяешь структуру HTML на каждом — можно сделать вручную или прогнать через скрипт, вычисляющий dom-hash, упрощенный отпечаток структуры документа без учета содержимого. Три из четырех имеют идентичную структуру.
Извлекаешь названия cookies из HTTP-заголовков. Два специфичных имени совпадают на всех трех сайтах. Проверяешь код страницы на наличие встроенных счетчиков и скриптов. Один и тот же идентификатор Google Analytics присутствует на двух из трех. Проверяешь JARM-фингерпринт серверов через специализированные сканеры совпадает на всех трех.
Теперь у тебя не одна фишинговая страница, а кластер из трех связанных доменов. Можешь проверить историю DNS-записей через passive DNS сервисы вроде SecurityTrails или RiskIQ архивируют изменения резолва доменов. Посмотреть, на какие IP они резолвились раньше. Найти дополнительные домены, которые были размещены на тех же серверах. Проанализировать временные паттерны: когда регистрировались, когда становились активными, как долго работали. Постепенно выстраивается картина операций.
Композитная корреляция требует больше усилий, чем поиск по одному сильному индикатору. Нужно извлечь несколько элементов, провести несколько проверок, сопоставить результаты. Автоматизация помогает, но полностью заменить ручной анализ не может. Системы умеют находить совпадения, но интерпретировать их значимость должен человек.
Автоматика против интуиции
Корреляция бывает двух типов: автоматическая и ручная. Автоматическая выполняется программными системами по заданным правилам. Ручная аналитиком на основе опыта и контекста.
Автоматические системы корреляции работают быстро и покрывают большие объемы данных. Платформа вроде MISP принимает поток точек данных, сравнивает их с существующей базой, находит совпадения, отмечает связи. Если новый домен резолвится на известный IP командного сервера система это зафиксирует.
Если хеш файла совпадает с ранее обнаруженной малварью связь установится автоматически.
Инструменты автоматизации сбора данных расширяют возможности. SpiderFoot агрегирует информацию из десятков источников: DNS, WHOIS, сертификаты, упоминания в утечках данных, профили в социальных сетях. Запускаешь сканирование по домену получаешь граф связанных элементов. Recon-ng работает модульно, позволяет выстраивать цепочки проверок через скрипты. Maltego визуализирует связи, превращая разрозненные точки данных в интерактивный граф, где можно отследить путь от одного элемента к другому.
Система работает по правилам, которые в нее заложены. Видит только те типы связей, которые умеет проверять. Не понимает контекст. Не может оценить, насколько значимо найденное совпадение в конкретной ситуации.
Автоматическая система находит, что десять доменов используют один IP-адрес. Фиксирует корреляцию. Но не может определить, что IP принадлежит крупному хостинг-провайдеру, у которого тысячи клиентов. Совпадение технически корректно, но аналитически бесполезно. Создается шум.
Или система находит совпадение хешей favicon на двух сайтах. Отмечает связь. Не учитывает, что иконка стандартная для популярной системы управления контентом, которую используют миллионы сайтов. Корреляция есть, значимости нет.
Аналитик не может обработать такие объемы данных, как автоматизированная система. Зато он видит то, что система не видит. Контекст. Временные паттерны. Связь с другими расследованиями. Нестандартные зацепки, которые не укладываются в формальные правила.
Аналитик может заметить, что два фишинговых сайта используют похожие, но не идентичные тексты с одинаковыми грамматическими ошибками. Автоматическая система такую связь не установит, потому что текст не совпадает точно. Человек увидит паттерн. Лингвистический анализ становится точкой данных — специфичные обороты, стабильные ошибки, выбор терминологии.
Или аналитик может обратить внимание, что несколько доменов, связанных через слабые индикаторы, активировались в одно и то же время суток на протяжении недели. Система зафиксирует совпадение временных меток, но не выделит это как значимый фактор. Человек поймет, что синхронная активация указывает на координацию.
Современные платформы начинают применять машинное обучение для выявления неочевидных паттернов. Алгоритмы анализируют исторические данные и находят корреляции, которые человек мог бы пропустить из-за объема информации. Но финальную интерпретацию все равно делает аналитик. Машина показывает вероятность связи. Человек решает, достаточно ли доказательств для вывода.
Эффективная работа требует сочетания обоих подходов. Автоматика обрабатывает объемы и находит очевидные совпадения. Человек фильтрует шум, интерпретирует контекст, выстраивает гипотезы. Система показывает, что есть. Аналитик решает, что из этого имеет значение.
При проектировании платформ threat intelligence критично разделять автоматические и ручные корреляции на уровне данных. Если аналитик видит связь между двумя элементами, он должен понимать, откуда она взялась. Установлена системой по формальному совпадению или добавлена другим аналитиком на основе дополнительной информации.
Когда корреляция помечена как автоматическая, понятно, что она требует проверки. Может быть шумом. Может быть значимой находкой. Нужно смотреть контекст. Когда корреляция помечена как ручная, понятно, что кто-то уже провел анализ и счел связь достаточно надежной, чтобы зафиксировать ее явно. Уровень доверия выше, но не абсолютный люди тоже ошибаются.
Прозрачность происхождения данных позволяет выстраивать цепочки рассуждений. Видеть, на чем основан вывод. Проверять логику. Находить слабые места. Без такой прозрачности корреляция превращается в черный ящик, где непонятно, почему система считает два элемента связанными.
Как строится цепочка пивотинга
Пивотинг использует эту связь как отправную точку для движения дальше. Нашел один домен. Проверил, на каком IP он размещен. Посмотрел, какие еще домены используют тот же IP. Проверил каждый из них на наличие других совпадающих элементов. Нашел новые зацепки. Повторил процесс.
Каждый шаг переход от известной точки к неизвестной через установленную связь. Постепенно выстраивается граф.
Узлы (vertices) точки данных: отдельные метрики, логи, сенсоры, сервисы, хосты, контейнеры или любые измеряемые сущности, генерирующие временные ряды или события.
Ребра (edges) установленная корреляция между узлами. Корреляция может быть вычислена по коэффициенту Пирсона, Спирмена, взаимной информации или другим методам. Ребра обычно имеют вес (сила корреляции) и порог значимости, выше которого связь считается надёжной.
Поступает сообщение о подозрительном файле. Извлекаешь его хеш. Проверяешь по базам вроде VirusTotal файл ранее не встречался. Смотришь метаданные внутри файла. Есть URL, откуда файл был загружен. Проверяешь домен через WHOIS. Недавно зарегистрирован. Резолвится на IP в диапазоне облачного провайдера.
IP сам по себе ничего не дает. Тысячи клиентов используют того же провайдера. Проверяешь passive DNS через SecurityTrails: какие еще домены резолвились на этот IP за последние недели. Находишь три домена. Проверяешь их содержимое через архивные снимки Wayback Machine или живые запросы. Два из трех имеют идентичную структуру HTML. Извлекаешь favicon с каждого, вычисляешь хеш через простой скрипт на Python. Хеши совпадают на обоих.
Теперь есть два домена с подтвержденной связью. Проверяешь TLS-сертификаты через Censys или crt.sh публичный архив сертификатов. Оба используют автоматически выпущенные сертификаты от бесплатного центра. Серийные номера разные, но параметры субъекта похожи: одинаковая длина случайных строк, одинаковый формат email. Возможно, генерировались одним скриптом.
Проверяешь JARM-фингерпринт обоих серверов совпадает, что подтверждает идентичную конфигурацию TLS.
Смотришь код страниц. На обоих есть встроенный счетчик посещений. Не Google Analytics, а самописный скрипт с обращением к стороннему домену. Проверяешь этот домен. Тоже недавно зарегистрирован. Резолвится на другой IP, но в том же диапазоне подсети. Проверяешь через Shodan, какие еще домены обращаются к этому счетчику ищешь упоминания домена в индексированном HTML-коде. Находишь еще пять.
Из одного файла и одного домена вышел на кластер из восьми связанных ресурсов. Некоторые связи сильные идентичная структура HTML, совпадающие иконки, одинаковый JARM. Некоторые слабые похожие параметры сертификатов, использование общего скрипта. Но в совокупности они формируют устойчивый паттерн, указывающий на общую инфраструктуру.
Дальше можно проверить регистрационные данные доменов через сервисы WHOIS-истории. Посмотреть, есть ли совпадения в контактной информации, даже если она анонимизирована через privacy-сервис иногда злоумышленники забывают включить защиту при регистрации или меняют провайдера анонимизации, оставляя короткие окна видимости реальных данных. Проанализировать временные паттерны когда регистрировались, когда становились активными, как долго работали. Построить временную шкалу операций.
Можно проверить содержимое страниц на лингвистические особенности. Грамматические ошибки, специфичные обороты, выбор слов. Если несколько сайтов содержат тексты с одинаковыми ошибками, вероятно, их писал один человек или использовался общий шаблон. Инструменты анализа текста могут автоматизировать поиск повторяющихся фраз или характерных стилистических маркеров.
Можно извлечь все встроенные скрипты и проверить их по базам публичного кода вроде GitHub или публичным CDN. Найти библиотеки, версии, модификации. Иногда злоумышленники используют редкие или устаревшие библиотеки, которые становятся характерным маркером. Или модифицируют популярные библиотеки специфичным образом, что тоже создает отпечаток.
Каждый новый элемент потенциальная точка для следующего пивота. Процесс останавливается, когда новые связи перестают появляться или когда достигнута цель расследования. Но теоретически можно двигаться бесконечно, потому что любая инфраструктура связана с окружающим миром множеством способов.
Короткие цепочки в большом мире
Существует теория, что любые два человека на планете связаны через цепочку знакомств длиной не больше шести шагов. Ты знаешь кого-то, кто знает кого-то, кто знает кого-то — и через несколько переходов выходишь на любого человека в любой точке мира. Теория спорная, методология сомнительная, но принцип работает неожиданно хорошо применительно к цифровой инфраструктуре.
Злоумышленники стараются изолировать свои операции. Используют разные домены для разных кампаний. Размещают серверы у разных провайдеров. Меняют IP-адреса. Создают видимость независимости. Но инфраструктура не существует в вакууме. Каждый элемент оставляет следы. Каждая операция требует ресурсов. Каждое взаимодействие создает точку соприкосновения.
Домены регистрируются через регистраторов. Серверы арендуются у хостинг-провайдеров. Платежи проходят через платежные системы. Код копируется из публичных репозиториев. Инструменты скачиваются с форумов. Шаблоны берутся из открытых источников. На каждом этапе возникают связи, большинство из которых кажутся несущественными.
Проблема в том, что несущественных связей не бывает, когда их достаточно много.
Начинаешь с одного файла. Файл загружен с домена. Домен размещен на IP. На том же IP есть другой домен. Тот использует код аналитики. Код встречается на сайте в сети Tor. На Tor-сайте указан контакт в мессенджере. В мессенджере опубликован QR-код с адресом криптокошелька. Кошелек имеет транзакции с адресами, которые фигурировали в другом расследовании.
Девять шагов. Две изначально независимые кампании оказываются связаны через цепочку слабых индикаторов, ни один из которых сам по себе не дает атрибуции. Но вместе они показывают, что за разными операциями стоит общая инфраструктура или общие операторы.
Короткие цепочки работают, потому что злоумышленники экономят усилия. Повторно используют инструменты, которые уже настроены. Копируют конфигурации, которые уже работают. Применяют проверенные схемы вместо изобретения новых. Операционная эффективность оставляет стабильные маркеры.
Платежные системы — узкое место. Количество способов принимать анонимные платежи ограничено. Криптовалютные кошельки оставляют публичные следы транзакций. Даже при использовании миксеров и сервисов анонимизации объем и частота платежей создают паттерны.
Блокчейн-аналитика превратилась в отдельное направление пивотинга. Инструменты вроде Chainalysis или Elliptic отслеживают движение криптовалюты между кошельками, выявляют кластеры адресов, принадлежащих одному владельцу, связывают транзакции с известными сервисами обмена или вывода средств. Если две разные операции выводят средства на кошельки, связанные через несколько переходов, появляется зацепка. Можешь проследить путь от адреса, указанного на фишинговом сайте, до биржи, где средства конвертировались в фиатные деньги, и получить дополнительную информацию об операторах.
Хостинг-провайдеры еще одно узкое место. Провайдеров, которые терпимо относятся к размещению сомнительного контента, не так много. Провайдеров, которые принимают анонимные платежи и не реагируют на жалобы, еще меньше. Злоумышленники концентрируются у небольшого числа операторов. Разные кампании оказываются соседями на уровне сетевой инфраструктуры.
Сканирование диапазонов IP-адресов провайдеров, известных лояльностью к сомнительной активности, через Shodan или Censys часто выявляет кластеры серверов с похожими конфигурациями. JARM-фингерпринты совпадают. Версии программного обеспечения идентичны. Открытые порты повторяются. Паттерн указывает на массовое развертывание инфраструктуры одним оператором или группой.
Инструменты разработки третье узкое место. Количество фреймворков для создания фишинговых страниц конечно. Количество библиотек для написания малвари ограничено. Количество панелей управления ботнетами исчисляется десятками популярных вариантов. Повторное использование кода оставляет следы. Одинаковые ошибки. Одинаковые обфускации. Одинаковые структурные решения.
Анализ малвари на уровне кода выявляет повторяющиеся паттерны. Специфичные функции. Характерные библиотеки. Методы обфускации. Даже если файл перекомпилирован и хеш изменился, структурное сходство остается. Инструменты вроде IDA Pro или Ghidra позволяют сравнивать бинарные файлы на уровне ассемблерного кода и находить общие фрагменты. Автоматизированные системы вроде YARA используют сигнатуры для поиска похожих образцов малвари в больших коллекциях.
Человеческий фактор добавляет еще один уровень связей. Языковые особенности. Часовые пояса активности. Выбор доменных имен. Стилистика текстов. Привычки в оформлении. Даже при попытке анонимизации проявляются устойчивые паттерны поведения.
Анализ временных меток активности серверов и доменов через логи доступа или данные passive DNS показывает, когда операторы работают. Если несколько независимых кластеров инфраструктуры демонстрируют активность в одни и те же часы суток на протяжении недель, появляется гипотеза об общем операторе или команде, работающей в определенном часовом поясе.
Все эти элементы создают плотную сеть потенциальных связей. Две кампании, которые кажутся полностью независимыми на уровне традиционных индикаторов, оказываются связаны через общие инструменты, общих провайдеров, общие платежные каналы, общие операционные привычки. Цепочка выстраивается быстрее, чем кажется.
Почему инфраструктура не изолирована
Теоретически злоумышленник может построить полностью изолированную инфраструктуру для каждой операции. Новые домены без истории. Уникальные IP-адреса. Свежий код без заимствований. Уникальные стилистические решения. Отдельные платежные каналы. Разные операторы на каждом этапе.
Практически такой подход слишком дорог по времени и ресурсам. Каждая новая кампания требовала бы месяцев подготовки. Разработка уникального кода. Создание новых инструментов. Поиск новых провайдеров. Настройка новых платежных каналов. Масштабирование операций становится невозможным.
Поэтому злоумышленники идут по пути наименьшего сопротивления. Берут готовые решения. Копируют проверенные схемы. Повторно используют работающую инфраструктуру. Автоматизируют развертывание. Операционная эффективность становится приоритетом.
Автоматизация усиливает проблему. Когда инфраструктура разворачивается скриптами, конфигурация повторяется точно. Одинаковые настройки серверов. Одинаковая структура файлов. Одинаковые параметры TLS. Одинаковые названия технических элементов. Скрипт не забывает поменять favicon или удалить отладочную информацию. Он просто копирует заданный шаблон.
Terraform, Ansible, Docker Compose — инструменты автоматизации развертывания оставляют характерные следы. Конфигурационные файлы содержат дефолтные значения. Контейнеры собираются из стандартных образов. Скрипты инициализации повторяют одинаковую последовательность действий. Все это создает устойчивые технические отпечатки, которые можно обнаружить через сканирование и анализ конфигураций.
Даже когда злоумышленники пытаются внести разнообразие, паттерны остаются. Рандомизация доменных имен следует заданному алгоритму. Генерация сертификатов использует фиксированные параметры. Обфускация кода применяется одним инструментом. Разнообразие поверхностное, глубинная структура сохраняется.
Алгоритмы генерации доменов можно идентифицировать по паттернам. Если злоумышленник использует DGA для создания большого числа доменов, алгоритм оставляет статистический след. Длина доменов, используемые символы, распределение гласных и согласных все это поддается анализу. Машинное обучение помогает выявлять DGA-домены и связывать их с конкретными семействами малвари.
Обычные домены читаемы: google.com, yandex.ru, habr.com. Они содержат слова или аббревиатуры.
DGA-домены часто случайны: vzdzrsensinaix.com, xeogrhxquuubt.info. Высокая энтропия (мера случайности), необычные комбинации букв.
Сложность современных операций работает против изоляции. Фишинговая кампания требует доменов, серверов, контента, платежной инфраструктуры, каналов связи с жертвами, систем сбора данных. Каждый компонент — точка соприкосновения. Каждое взаимодействие потенциальная связь. Чем больше движущихся частей, тем больше поверхность для анализа.
Кооперация между группами создает дополнительные связи. Одни специализируются на создании малвари. Другие — на компрометации инфраструктуры. Третьи на монетизации. Совместное использование ресурсов, обмен инструментами, аренда сервисов все это оставляет пересекающиеся следы. Инфраструктура разных групп переплетается на техническом уровне.
Специализированные форумы и маркетплейсы в даркнете создают дополнительные точки пересечения. Злоумышленники покупают доступы к скомпрометированным серверам, арендуют панели управления ботнетами, заказывают криптеры для обфускации малвари. Каждая транзакция оставляет следы. Продавцы сервисов часто обслуживают множество клиентов, что создает технические пересечения между независимыми операциями.
Даже попытки сегментации не дают полной изоляции. Злоумышленник может использовать разные наборы серверов для разных кампаний. Но если администрирование ведется с одного устройства, появляются общие технические следы. Одинаковые версии программного обеспечения. Одинаковые конфигурации SSH. Одинаковые временные метки активности. Сегментация на уровне инфраструктуры не гарантирует сегментацию на уровне операций.
SSH-ключи и сертификаты клиента становятся идентификаторами оператора. Если один и тот же SSH-ключ используется для доступа к серверам в разных кластерах, он связывает их напрямую. Логи авторизации, которые иногда становятся доступны после компрометации сервера или через утечки данных провайдеров, содержат такую информацию.
Время работает против изоляции. Чем дольше существует операция, тем больше накапливается связей. Старые домены связаны с новыми через историю DNS. Старые серверы связаны с новыми через общую конфигурацию. Старые кампании связаны с новыми через повторно используемые элементы. Операционная история создает граф связей, который растет со временем.
Passive DNS становится памятью инфраструктуры. Каждое изменение резолва домена фиксируется. Даже если домен сейчас указывает на новый IP, история показывает все предыдущие адреса. Через эти адреса можно выйти на другие домены, которые были размещены на тех же серверах в разное время. Временная развертка инфраструктуры раскрывает эволюцию операций и связи между кампаниями, разделенными месяцами или годами.
Практические ошибки при работе с пивотингом
Начинающие аналитики часто концентрируются на сильных индикаторах и игнорируют слабые. Логика понятна: хеш файла дает точное совпадение, доменное имя однозначно, IP-адрес конкретен. Проблема в том, что злоумышленники знают про сильные индикаторы и активно их меняют. Фокус на сильных индикаторах ведет к быстрому тупику.
Слабые индикаторы требуют больше работы. Нужно собрать несколько элементов, проверить их комбинацию, оценить значимость. Но именно слабые индикаторы стабильны, потому что злоумышленники не считают их угрозой. Игнорирование слабых сигналов потеря большей части аналитических возможностей.
Другая распространенная ошибка переоценка одиночной корреляции. При обнаружении одинакового идентификатора Яндекс.Метрики на двух доменах аналитики нередко сразу фиксируют связь инфраструктур.
Без проверки источника такого ID вывод остается преждевременным. Идентификатор может быть заимствован из публичной документации по настройке.
Может представлять тестовый аккаунт, оставшийся в шаблоне. Может быть скопирован с другого ресурса. Одиночное совпадение в отсутствие дополнительного контекста не обладает доказательной силой.
Принципы построения композитной корреляции:
Для надёжных выводов требуется несколько независимых подтверждений.
Один элемент всего лишь зацепка, случайное совпадение, которое легко объяснить совпадением.
Два элемента уже возможная связь, но всё ещё недостаточно для уверенности; совпадения всё ещё вероятны.
Три- элемента (и более) формируют устойчивый паттерн, который с высокой вероятностью указывает на реальную связь.
Спешка в выводах приводит к ложным атрибуциям, когнитивным искажениям и напрасной трате времени на проверку ошибочных гипотез.
Спешка главный враг точного анализа лучше собрать больше данных и прийти к выводу позже, чем ошибиться рано и идти по ложному следу.
Недостаточное документирование цепочки пивотинга создает проблемы при передаче информации. Ты нашел связь между доменами через серию переходов. Запомнил логику. Но через неделю, когда нужно объяснить находку коллеге или написать отчет, детали стерлись. Какой именно элемент связывал первый домен со вторым? Какая проверка привела к третьему? Почему был выбран именно этот путь?
Без фиксации шагов воспроизвести анализ невозможно. Проверить логику нельзя. Найти ошибки сложно. Документирование кажется избыточной работой в процессе, но экономит кратное время при последующем использовании результатов. Инструменты вроде Maltego автоматически сохраняют граф исследования, фиксируя каждый переход и источник данных. Но даже простой текстовый документ с пошаговым описанием лучше, чем полагаться на память.
Ещё одна распространённая ошибка слишком быстро отбрасывать корреляции, считая их «шумом».
Например, вы видите, что один IP-адрес связан с сотнями или даже тысячами доменов, и сразу решаете: «Это бесполезно, слишком много совпадений» и идёте дальше. Но стоит хотя бы на минуту задуматься, почему эта связь такая широкая.
Shared-хостинг на одном IP действительно размещаются сотни обычных сайтов. В таком случае корреляция чаще всего действительно случайная и не несёт полезной информации.
Sinkhole или DNS-sinkhole — IP, на который провайдеры или исследователи перенаправляют трафик от известных вредоносных доменов. Тогда большое количество доменов признак того, что все они связаны с малварью, и это ценный сигнал.
Узел CDN (Cloudflare, Akamai, Fastly) через него проходит легитимный трафик множества сайтов. Корреляция опять же обычно случайная.
Прокси-сервер, VPN-выход или Tor-нода, где тоже собирается трафик от огромного числа источников.
Краткая проверка природы IP (через whois, репутационные списки, пассивный DNS или просто поиск по этому адресу) часто сразу покажет, стоит ли копать дальше или действительно можно пропустить. Экономит время в долгосрочной перспективе и помогает не упустить важные паттерны.
Анализ причин высокой кардинальности корреляции сам по себе информативен. Показывает структуру инфраструктуры. Выявляет общие сервисы. Помогает отфильтровать шум в будущих проверках.
Автоматическое отбрасывание высококардинальных корреляций потеря части контекста. Иногда даже shared-хостинг становится полезной зацепкой, если выясняется, что злоумышленники предпочитают конкретного провайдера из-за его политики или ценовой модели.
Отсутствие валидации цепочки критическая ошибка. Построил граф связей через пивотинг. Нашел кластер из десятка доменов. Не проверил, действительно ли все они активны. Не посмотрел, когда они работали. Не сопоставил временные рамки. В результате половина доменов оказывается заброшенной инфраструктурой, которая не имеет отношения к текущей кампании. Связь есть, но она историческая, а не операционная.
Временной контекст критичен для интерпретации корреляций. Два домена могут быть связаны, потому что работали одновременно в рамках одной кампании. Или потому что один заменил другой после компрометации. Или потому что оба принадлежали одному провайдеру, который позже сменил владельца. Без учета времени интерпретация связи может быть полностью неверной.
Проверка активности домена через попытку доступа или через мониторинг DNS-запросов показывает, используется ли инфраструктура сейчас. Архивные данные Wayback Machine показывают, как менялось содержимое сайта со временем.
Сопоставление временных меток из разных источников регистрация домена, первое появление в passive DNS, первый архивный снимок, первое обнаружение малвари — строит временную шкалу операции.
Излишняя уверенность в автоматических системах тоже создает проблемы. Платформа показала корреляцию — значит, она есть. Не проверяешь, на чем основана. Не смотришь исходные данные. Не оцениваешь качество входной информации. Автоматика работает с тем, что в нее загружено. Если входные данные неполные или неточные, корреляции будут ошибочными.
Слепое доверие к чужим корреляциям еще опаснее. Получил от другой организации список связанных индикаторов. Использовал их без проверки. Не спросил, как связь была установлена. Не проверил, актуальна ли информация. Не сопоставил с собственными данными. Чужие корреляции могут быть основаны на устаревшей информации, неполных данных или ошибочной интерпретации. Принятие их на веру ведет к распространению ошибок.
Платформы обмена threat intelligence вроде MISP позволяют не только получать данные, но и видеть их происхождение. Кто добавил индикатор. Когда. На основе чего была установлена связь. Уровень доверия к источнику. Использование этих метаданных критично для оценки надежности информации.
Типичная ошибка отсутствие критического мышления. Нашел красивый граф связей. Все элементы сходятся. Паттерн очевиден. Не задал себе вопрос:
- Может быть альтернативное объяснение?
- Может, это не одна группа злоумышленников, а использование общего инструмента?
- Может, связь случайна?
- Может, данные неполные, и реальная картина другая?
Пивотинг инструмент для построения гипотез, не для их доказательства. Граф связей показывает возможную структуру инфраструктуры. Но окончательные выводы требуют независимого подтверждения через другие источники, методы, данные. Корреляция не равна причинности. Связь не равна атрибуции. Граф — отправная точка для дальнейшего анализа, а не его завершение.
Пивотинг работает, когда аналитик понимает ограничения метода. Слабые индикаторы дают зацепки, но требуют проверки. Корреляции показывают возможные связи, но нуждаются в интерпретации. Автоматика ускоряет процесс, но не заменяет критическое мышление. Граф инфраструктуры строится постепенно, через итеративное уточнение, проверку альтернативных гипотез, сопоставление с внешним контекстом.
Злоумышленники защищают то, что считают важным, и игнорируют то, что кажется несущественным. Анализ несущественных деталей часто дает больше результатов, чем попытки пробить защищенные элементы. Favicon, названия cookies, структура заголовков, JARM-фингерпринты, паттерны ошибок, временные метки, блокчейн-транзакции мелочи, которые складываются в устойчивые маркеры. Именно на них строится эффективный пивотинг.
ЧЕК-ЛИСТ ДЛЯ АНАЛИТИКА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
Процедура проведения пивотинга при расследовании инцидентов
1. Подготовительный этап
Перед началом пивотинга четко определите стартовую точку (фишинговый URL, жалоба пользователя, вредоносный документ, аномалия в логах).
☑ Классифицировать все артефакты:
IoC подтвержденные индикаторы, готовые к автоматической блокировке (хеши вредоносных файлов, IP-адреса C2-серверов, домены с доказанным злонамеренным контентом).
Точки данных (weak indicators) требуют дополнительной валидации (хеши favicon, названия cookie, структура HTTP-заголовков, JARM).
☑ Собрать полный набор технических артефактов:
Сетевые: IP-адреса, ASN, публичные диапазоны подсетей.
Доменные: основные домены, поддомены, punycode-домены, исторические записи DNS.
Файловые: хеши (MD5/SHA256), TLS-сертификаты (JA3/JA3S, JARM, серийные номера).
Веб-артефакты: HTTP-заголовки (Server, X-Powered-By, порядок), favicon, структура HTML, встроенные скрипты аналитики.
Метаданные: даты регистрации доменов, временные паттерны активности, информация о регистраторах.
☑ Зафиксировать временные метки:
Дата регистрации домена и срок действия.
Временные интервалы активности (Passive DNS: первое/последнее появление).
Паттерны по часовым поясам.
2. Анализ слабых индикаторов
Злоумышленники при массовом развертывании фишинг-китов редко меняют технические элементы шаблона.
☑ Favicon: Скачать:
curl -s https://<домен>/favicon.ico -o favicon.ico
Вычислить хеш:
openssl dgst -sha256 favicon.ico
Поиск совпадений: Shodan/Censys/Netlas http.favicon.hash:<хеш>.
Один хеш часто выявляет десятки связанных фишинговых сайтов.
☑ Технические cookie:
Зафиксировать названия через DevTools (Application → Cookies).
Обратить внимание на кастомные сессионные имена и cookie аналитики.
☑ HTTP-заголовки:
Собрать: curl -s -D - https://<домен> -o /dev/null
Проанализировать точный порядок, значения и версии ПО.
☑ JARM-фингерпринт:
Сгенерировать: jarm scan <домен> --port 443
Сравнить с известными конфигурациями.
☑ Структура HTML и аналитика:
Вычислить dom-hash (библиотека html5-dom-hash или аналог).
Проверить встроенные трекеры: Google Analytics (UA-/G-), Яндекс.Метрика (yaCounter/metrika.id).
3. Корреляция данных
Связывать артефакты только через композитный анализ с минимум тремя независимыми совпадениями.
☑ Надежные комбинации:
Favicon хеш + JARM + идентичные HTTP-заголовки.
ID аналитики + синхронная регистрация доменов (≤24 ч) + структура HTML.
☑ Валидация высококардинальных связей:
При >100 доменов на одном IP проверить тип хостинга (shared, CDN, sinkhole).
Исключить легитимные платформы (Cloudflare, Akamai).
☑ Инструменты:
Passive DNS: SecurityTrails, DNSDB, VirusTotal Passive DNS.
Сертификаты: crt.sh, Censys.
Автоматизация: SpiderFoot, Maltego, MISP + расширения.
☑ Все автоматические корреляции подтверждать вручную.
4. Валидация гипотез
Исключить ложные связи перед финальными выводами.
☑ Проверить актуальность: доступность (curl -I), свежие DNS-записи, архивы в Wayback Machine.
☑ Оценить альтернативные объяснения:
Популярные CMS/конструкторы (Bootstrap, Bitrix, Tilda).
Легитимное использование одного трекера на нескольких проектах.
Стандартные конфигурации хостинг-провайдеров.
☑ Внешняя валидация: VirusTotal, AbuseIPDB, Kaspersky/Group-IB Threat Intelligence (с критической оценкой).
☑ Для атрибуции требовать пересечение:
- ≥3 слабых индикатора.
- Временные паттерны.
- Финансовый след (криптотранзакции, методы монетизации).
- TTPs из отчетов Threat Intelligence.
5. Документирование результатов
Зафиксировать полную цепочку для воспроизводимости.
☑ Для каждой точки пивотинга:
[Исходный артефакт] → [Метод связи] → [Инструмент] → [Результат] → [Уровень уверенности % или статус]
Пример: `sha256:favicon → хеш → Shodan → 15 доменов → 94%`
☑ Приложить доказательства: скриншоты (заголовки, cookie, код), хеши, JARM-строки, ссылки на внешние источники.
☑ Отметить ограничения и альтернативные сценарии.
6. Передача данных
При обмене с коллегами или внешними командами:
☑ Четко разделять:
Подтвержденные IoC (≥95% уверенности) для автоматической блокировки.
Точки данных (<95%) для дальнейшего анализа.
☑ Указывать источник, дату и метод каждой связи.
☑ Формат передачи: STIX/TAXII или Markdown/PDF-отчет с полной цепочкой.
7. Дополнительные требования и SLA
☑ SLA: валидация фишингового домена ≤2 часов, полное документирование ≤24 часов.
☑ Безопасность работы с внешними сервисами: обезличивание внутренних данных, корпоративные API-ключи, очистка временных файлов.
☑ Ссылки на внутренние регламенты: политика обработки инцидентов, хранение доказательств, передача партнерам.
Анализ завершен при выполнении всех условий:
Достигнута цель расследования (локализация инфраструктуры, атрибуция, подготовка блокировок).
Все связи валидированы или помечены как требующие доработки.
Документация позволяет независимо воспроизвести результаты.
Риск ложных блокировок <0.1% (передаются только IoC ≥95%).
Фокус на слабых индикаторах при работе с шаблонными фишинг-китами повышает эффективность выявления связанной инфраструктуры на 60–70% по сравнению с анализом только сильных IoC.