Конкурентная разведка по открытым источникам: от публичной ссылки до владельца инфраструктуры

Сбор сведён к одной команде

Скрипт 01-recon.sh принимает на вход домен и за один заход проходит WHOIS, DNS, разбор сертификата, историческую выборку из прозрачности сертификатов, HEAD-запрос, публичные сканы, пассивный DNS и веб-архив. Каждый шаг ложится отдельным файлом в рабочую папку — это артефакт, к которому можно вернуться, приложить к выводу и сравнить с повторным прогоном того же домена через месяц. Разведка, существующая только в терминале аналитика, не разведка.

Живой проход вынесен в отдельный скрипт — намеренно

Фильтр показа отдаёт нейтральную страницу всем, кто не похож на целевого посетителя: не тот регион, не тот тип устройства, не тот источник перехода. Поэтому 02-live-click.sh делает запрос с параметрами настоящего посетителя и снимает с него всё, что видно:

• полную цепочку перенаправлений — каждый хоп это отдельный домен и, возможно, отдельный участник
• Set-Cookie на каждом хопе — имена cookie опознают платформу лучше, чем содержимое страницы
• заголовки ответа по хопам: сервер, признаки фреймворка, идентификаторы CDN
• финальный ответ с реальным содержимым — то, ради чего вся цепочка и построена

Отдельный файл здесь — не косметика. Это единственный шаг, который отправляет запрос с подставленным источником перехода; он не должен уезжать случайно в составе обычного сбора. Разделение зафиксировано прямо в комментарии скрипта, чтобы решение пережило автора.

Опознание трекера по сигнатуре, а не по названию

Трекер нигде не представляется. Но каждая платформа оставляет отпечаток, и он устойчивее любой надписи на странице. Справочник tracker-signatures.md — это таблица «признак → платформа», которая пополняется на каждом разборе:

• служебный заголовок ответа, уникальный для одной платформы — самый сильный признак, опознание мгновенное
• форма имени cookie и её структура — например, имя с хешем фиксированной длины и подписью значения
• форма пути в URL перехода: где стоит идентификатор кампании, где — идентификатор партнёра
• набор полей в JSON интеграции — состав ключей однозначно маппится на конкретный класс платформ
• имя балансировщика в DNS облачного провайдера — часто внутреннее кодовое имя проекта оператора

Код на странице говорит о команде больше, чем страница

Отдельный шаг — чтение собранных JS и CSS не на предмет логики, а на предмет следов авторов: жёстко зашитые адреса служебных эндпоинтов, названия внутренних сущностей, и главное — комментарии на нелатинице. Одна-две строки на родном языке разработчика сужают круг кандидатов сильнее, чем весь остальной технический сбор. Это дешёвый шаг, который почти всегда пропускают.

Правила атрибуции — отдельный документ, а не абзац в конце

В цепочке участвует не один игрок, а несколько независимых: слой маскировки показа, трекер, промежуточный сервис перенаправления, конечный продавец. Каждый — отдельная компания, и каждый может обслуживать десятки не связанных между собой клиентов. Поэтому в attribution-rules.md признаки разделены на два списка: те, что доказывают конкретного оператора, и те, что встречаются у всех подряд. Вывод делается по первой уникальной сигнатуре в цепочке, а не по последнему хопу и не по общим промежуточным звеньям.

Ноль платных источников — это ограничение, а не экономия

Весь сбор строится на том, что доступно любому: whois-сервер регистратуры, публичные DNS-резолверы, прозрачность сертификатов, публичные сканы страниц, пассивный DNS и веб-архив. Ограничение полезно методологически: оно заставляет опираться на признаки, которые можно перепроверить независимо, а не на вердикт закрытого сервиса, который нельзя ни оспорить, ни воспроизвести.

Самый ценный результат — пойманная собственная ошибка

На третьем разборе атрибуция сначала была неверной. Две разные цепочки сходились на одном промежуточном сервисе перенаправления, и это выглядело как доказательство общего владельца — признак яркий, воспроизводимый и абсолютно ложный. Ошибка вскрылась на следующем шаге: в заголовках ответа нашлась сигнатура трекера, принадлежащая одной конкретной платформе и не встречающаяся у других. Оператор оказался другим — и это подтвердилось независимо, через публичный сайт владельца этой платформы.

Правило, которое из этого выросло

Общие инструменты не доказывают общего владельца. Формулировка попала в attribution-rules.md вместе с явным списком признаков, которые ничего не доказывают, хотя выглядят убедительно:

• anycast-адреса популярного CDN — общий пул на всех клиентов тарифа
• самый массовый регистратор и его дефолтный privacy-провайдер — это про популярность, а не про связь
• сторонний сервис перенаправления в середине цепочки — независимый SaaS, им пользуются десятки не связанных операторов
• типовой шаблон лендинга и стандартный набор cookie популярного фреймворка

Итоговый алгоритм короткий: найти первый хоп с уникальной сигнатурой, опознать по нему платформу, подтвердить вторым независимым признаком — и только тогда называть оператора. Совпадение по общей инфраструктуре идёт в вывод как дополнительное свидетельство, никогда как основное.

Что осталось после трёх разборов

Репозиторий с плейбуком, двумя переиспользуемыми скриптами и двумя справочниками, которые растут с каждым новым разбором. Плюс чеклист сдачи — список полей, которые обязаны быть заполнены, прежде чем вывод считается готовым: кто оператор, где публично подтверждается, какой стек, чем именно доказана атрибуция. Чеклист нужен ровно для того же, для чего нужны правила: чтобы уверенность аналитика не подменяла собой доказательство.