SDK Spoofing и Click Injection: как мобильный фрод подменяет атрибуцию

SDK Spoofing и Click Injection: как мобильный фрод подменяет атрибуцию

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

SDK Spoofing — это когда событие install или in-app action подсовывается без реального пользователя. В логах это видно по «чистым» параметрам, но подозрительной связке: одинаковые device_id, нестабильный IP-пул, нереалистичный app_version, слишком ровные тайминги между click и install. Если SDK не подписывает события и трекер верит всему на слово, фрод проходит как нож через масло.

Click Injection работает грязнее и почти всегда успевает первым: вредоносное приложение ловит реальный install, мгновенно генерирует свой click и перехватывает атрибуцию. Сырой признак — click timestamp лежит в окне перед install до абсурда точно, а цепочка сессий не содержит нормального pre-install поведения. Часто рядом всплывают package names с шумным набором разрешений и короткой жизнью на устройстве.

Что фильтровать: — аномально короткий click-to-install, — повторяемые fingerprint’ы на разных устройствах, — несоответствие GEO/IP/locale, — отсутствие предустановочной активности, — одинаковые паттерны для тысячи «разных» юзеров. Если это есть, у вас не performance, а фабрика атрибуции.

Правильная защита строится на склейке сигналов: server-to-server валидация, подпись SDK-событий, контроль install referrer, сверка таймингов и репутации устройства. И да, если трекер принимает любой postback без проверки источника, бюджет уже уехал.