Виявлення емуляторів і віртуальних машин у вебтрафіку

Більшість шахрайства, що працює в масштабі, працює на віртуалізованій інфраструктурі, бо альтернатива — кімната, повна фізичних телефонів і ноутбуків — не масштабується й не ховається. Емулятор або віртуальна машина дає одному оператору за потреби піднімати тисячі начебто окремих пристроїв, кожен із яких виглядає як свіжий споживчий ендпоінт. Виявлення цієї віртуалізації — одна з найбільш важільних речей, які робить шар device intelligence, бо воно ідентифікує інфраструктуру масштабного зловживання, а не ганяється за окремими шахрайськими діями по одній.

Ця стаття розповідає, як емулятори та VM видають себе у вебтрафіку й трафіку застосунків: сигнали заліза, таймінгу й когерентності, які віртуалізованому середовищу важко відтворити, чому жодного окремого сигналу недостатньо і як діяти на основі виявлення, не ламаючи легітимну віртуалізацію. Аудиторія — інженери та команди з боротьби із шахрайством, що будують або оцінюють bot detection.

Чому емулятори й VM важливі для шахрайства

Емулятори та віртуальні машини важливі, бо вони — економічно вигідний субстрат для об'ємного шахрайства: вони перетворюють одну машину на флот пристроїв, що виглядають чистими, а саме цього й вимагає економіка більшості шахрайства.

Постійна проблема в шахрайстві — масштаб. Один фейковий акаунт чи одна шахрайська транзакція рідко окупаються; гроші — в тому, щоб зробити це тисячі разів. Щоб зробити це тисячі разів, потрібні тисячі ідентичностей пристроїв, бо платформи дедалі частіше пов'язують зловживання за пристроєм (див. як працює device fingerprinting). Фізичне залізо — це чесний спосіб отримати багато ідентичностей пристроїв, і він неприйнятно дорогий та повільний. Віртуалізація — дешевий спосіб.

Конкретно, віртуалізація лежить в основі:

Ферми пристроїв. Стійки емульованих мобільних пристроїв або інстансів headless-браузерів, зоркестровані, щоб створювати акаунти, забирати промоакції, публікувати фейкові відгуки або запускати credential stuffing і зловживання створенням акаунтів у масштабі. Кожен емульований інстанс видається за окремий телефон чи ноутбук.

Емуляція мобільних застосунків. Запуск Android- або iOS-застосунків в емуляторах на десктопному чи серверному залізі, щоб автоматизувати застосункові сценарії, які мали вимагати справжнього телефону, — мобільні реєстрації, промо за застосунком, внутрішньозастосункове шахрайство.

Хмарні браузери й browser-as-a-service. Повноцінні браузери, що працюють у хмарних VM, автоматизовані для скрапінгу, ad fraud та зловживання акаунтами. Вони витонченіші за грубих ботів, бо повністю рендерять сторінки й виконують JavaScript.

Спільна нитка: одна фізична машина, багато віртуальних ідентичностей. Якщо ви можете виявити віртуалізацію, ви згортаєте флот назад до його справжнього розміру — і «тисяча користувачів», що насправді є одним емульованим хостом, — це зовсім інше рішення щодо ризику, ніж тисяча справжніх пристроїв. Ось чому виявлення віртуалізації — це підсилювач: воно атакує структуру витрат, яка робить об'ємне шахрайство життєздатним.

Що видає віртуальну машину

Віртуальна машина видає себе фізичними сигналами, які вона мусить синтезувати, а не мати насправді, — GPU, поведінка таймінгу, сенсори та низькорівневі артефакти гіпервізора, на якому вона працює. Справжнє споживче залізо продукує ці сигнали як побічний ефект того, що воно справжнє; VM доводиться їх підробляти, а підробити їх усі когерентно — важко.

Сигнатури віртуалізованого GPU. Це одна з найсильніших ознак. Графічний рендеринг залежить від реального GPU, його драйвера й поведінки з плаваючою комою. VM зазвичай використовують віртуалізовану або програмно-рендерену графіку — SwiftShader, llvmpipe, віртуальні GPU VMware/VirtualBox/QEMU або прокинутий GPU, що все одно повідомляє видавні рядки. WebGL renderer і vendor-рядки часто прямо називають віртуалізацію («SwiftShader», «llvmpipe», «VMware SVGA», «Google SwiftShader»), і навіть коли ці рядки підроблено, сам вивід рендерингу canvas і WebGL відрізняється від фізичних GPU тонкими, важкими для підробки способами. Справжній GPU рендерить складну сцену з характерними для драйвера артефактами; програмний рендеринг дає іншу сигнатуру.

Надто чистий таймінг. Справжнє залізо — шумне. JIT-компіляція, збирання сміття, тепловий тротлінг, переривання ОС і ефекти ієрархії пам'яті вносять постійний джитер у вимірювання таймінгу. Віртуалізовані середовища — особливо хмарні на високоякісній інфраструктурі — часто працюють надто рівно, з нижчою варіативністю таймінгу, ніж демонструють фізичні споживчі пристрої. Високороздільний таймінг конкретних патернів обчислень може виявити середовище, чий профіль продуктивності неприродно однорідний. Парадоксально, але сама «чистота» датацентрової VM і є сигналом.

Артефакти гіпервізора. Віртуалізація лишає низькорівневі сліди: прапорці можливостей CPU й особливості таймінгу інструкцій, що відрізняються під гіпервізором, специфічну поведінку TSC (timestamp counter) і — де це спостережно — значення апаратної паралельності та пам'яті, що групуються навколо типових для VM конфігурацій, а не типових для споживача. Пристрій, що повідомляє дуже серверну кількість ядер і профіль пам'яті, водночас видаючи себе за споживчий ноутбук, некогерентний.

Аудіо- та інші апаратні відбитки. Відбиток AudioContext залежить від аудіопідсистеми; віртуалізоване або відсутнє аудіозалізо дає вивід із плаваючою комою, що відрізняється від справжнього звукового заліза. Малий сам по собі, корисний у комбінації.

Мережевий контекст. Флоти емуляторів і VM часто працюють у датацентрах, тож мережевий шар — датацентровий ASN, IP хостинг-провайдера — підтверджує сигнали ендпоінта. Сигнатура VM і датацентровий IP — набагато сильніший патерн, ніж будь-що з них окремо. (Витончені оператори прикривають свої VM резидентними проксі, щоб сховати мережевий бік, і саме тому виявлення VM на рівні ендпоінта важливе незалежно — воно переживає проксі.)

Як мобільні емулятори видають себе

Мобільні емулятори видають себе через той самий принцип, застосований до телефонів: їм доводиться синтезувати конкретні апаратні, сенсорні й рендерингові характеристики фізичного пристрою, а синтез неповний. Android- або iOS-застосунок, що працює в емуляторі на десктопному залізі, — не телефон, і про це говорить десяток сигналів.

Рядки апаратної ідентичності. Емулятори несуть характерні значення моделі пристрою, build-fingerprint і назви заліза. Android-емулятори історично повідомляють «generic», «goldfish», «ranchu», «sdk*gphone» та подібні build-ідентифікатори разом із типовими для емулятора назвами моделей. Навіть коли їх пропатчено, щоб імітувати справжній пристрій, *комбінація_ моделі, плати, CPU ABI і build-fingerprint часто не збігається з жодним реальним пристроєм, що виходив у продаж, — заявлений флагманський телефон із x86 ABI (справжні телефони — ARM) видає себе.

Відсутні або фейкові сенсори. Справжні телефони мають акселерометри, гіроскопи, магнітометри, датчики освітлення й барометри, і — що критично — ці сенсори продукують безперервні, корельовані, шумні дані, коли пристрій тримають і рухають. Емулятори або не мають цих сенсорів, або повідомляють статичні значення, або відтворюють синтетичні патерни, що не мають природної варіативності й міжсенсорної кореляції пристрою, який тримає людська рука. «Телефон», чий акселерометр показує ідеальну константу, або чиї гіроскоп і акселерометр не рухаються разом так, як вимагає фізика, — емульований.

Різниця в рендерингу й GPU. Так само, як на десктопі, сигнатура мобільного GPU-рендерингу відрізняється між мобільним GPU фізичного телефону (Adreno, Mali, Apple GPU) та емульованим чи програмно-рендереним. Щільність екрана, роздільність і артефакти рендерингу, що мали б відповідати конкретній заявленій моделі телефону, часто не відповідають.

Профіль таймінгу й продуктивності. Телефонний застосунок, що працює на залізі серверного класу в емуляторі, поводиться інакше, ніж той самий застосунок на справжньому SoC телефону, — часто швидше й плавніше, ніж повівся б справжній пристрій, ще один прояв ознаки «надто чисто».

Мобільний випадок — це де сенсорні дані стають вирішальними, бо їх справді важко добре підробити. Відтворити безперервний, фізично когерентний вивід сенсорів руху справжнього телефону — акселерометр і гіроскоп, що погоджуються про один і той самий рух, із реалістичним мікроджитером людської руки — набагато складніше, ніж відредагувати рядок із назвою моделі, і більшість емуляційних сетапів не роблять цього переконливо.

Чому жодного окремого сигналу недостатньо

Жоден окремий сигнал надійно не виявляє віртуалізацію, бо будь-який окремий сигнал може підробити оператор, який про нього знає, — і саме тому надійне виявлення залежить від когерентності між сигналами, а не від будь-якої окремої перевірки. Це той самий принцип, що керує виявленням anti-detect браузерів: окремі ознаки латаються; когерентність між усіма ними — ні.

Рішучий оператор:

• Підробить WebGL vendor/renderer рядки, щоб назвати справжній GPU.
• Пропатчить Android build-fingerprint і модель під справжній телефон.
• Впорсне синтетичні значення сенсорів, щоб підробити дані руху.
• Прикриє VM резидентним проксі, щоб почистити мережевий сигнал.

Будь-що з цього перемагає детектор, який покладається на той один сигнал. Система, що перевіряє лише WebGL renderer рядок, б'ється правкою рядка. Система, що перевіряє лише build-fingerprint, б'ється патчем.

Що важко — це зробити все це когерентно одразу. Оператор, що підробляє WebGL рядок, аби заявити GPU Adreno, все одно продукує вивід рендерингу canvas, який не збігається зі справжнім Adreno. Той, хто підробляє назву моделі, все одно повідомляє x86 ABI, або кількість ядер, якої немає в такого телефону, або сенсорні дані без реалістичної міжсенсорної кореляції, або таймінг, надто чистий для SoC, який він заявляє. Кожна підробка, яку він додає, — це ще одна поверхня, що має лишатися узгодженою з усіма іншими, і обмеження множаться.

Це принцип когерентності середовища: виявлення — не «чи виглядає це одне значення віртуалізованим», а «чи всі ці значення описують єдиний, справжній, фізично можливий пристрій». Заявлений iPhone, чий GPU рендерить як програмний, чиї сенсори показують константу, чий ABI — x86, а таймінг датацентрово-рівний, некогерентний не в один спосіб — він некогерентний у чотири, і узгодити всі чотири одночасно — це дорога частина. Вартість підтримання повної когерентності по кожному сигналу — це те, що змушує виявлення на основі когерентності триматися там, де односигнальні перевірки провалюються. Ширшу гонку озброєнь і те, де вона стоїть, розкрито в стані бот-трафіку.

Як діяти на основі виявлення віртуалізації

Не блокуйте віртуалізацію рефлекторно — зважуйте її як сигнал ризику в контексті, бо легітимна віртуалізація існує, а суцільне блокування спричиняє хибнопозитивні спрацювання. Правильна реакція залежить від того, що ще правда про цей трафік.

Є справжні, легітимні причини, чому користувач може бути у VM чи емуляторі: розробники тестують на емуляторах, дослідники безпеки, приватність-свідомі користувачі, що запускають браузери у VM, корпоративна інфраструктура віртуальних десктопів, сетапи для доступності. Блокування всієї віртуалізації навідруб карає цих користувачів. Віртуалізація — сигнал ризику, а не вирок.

Продуктивний підхід трактує її як один вхід у градуйоване рішення:

• Лише віртуалізація, інакше нормальний контекст: низький-до-помірного ризик. Один розробник на емуляторі — це не шахрайство. Зафіксуйте, не блокуйте.
• Віртуалізація + датацентрова мережа + свіжий акаунт + висока швидкість: високий ризик. Це сигнатура ферми пристроїв — емульований ендпоінт на хостинг-інфраструктурі, що швидко створює акаунти. Сигнали підтверджують один одного до впевненого вироку.
• Віртуалізація + порушення когерентності (підроблені рядки, що не збігаються з рендерингом, неможливі комбінації заліза): високий ризик. Віртуалізація плюс активні спроби її сховати — це сам по собі найсильніший сигнал: легітимні користувачі VM не патчать свої build-fingerprint, щоб видавати себе за флагманські телефони.
• Кореляція флоту: коли багато «окремих» пристроїв поділяють видавну сигнатуру віртуалізації й поводяться скоординовано, виявлення флоту згортає їх до їхнього справжнього походження, що є вирішальним незалежно від вигляду будь-якого окремого акаунта.

Патерн узгоджений із виявленням headless-браузерів і bot detection загалом: окремий сигнал інформує оцінку, комбінація сигналів дає вирок, а реакція градуйована — дозволити, кинути виклик або заблокувати — а не тупе блокування самої віртуалізації як такої. Виявлення емуляторів і VM найцінніше не як самостійний бар'єр, а як важко зважений сигнал, що в комбінації з мережевим і поведінковим контекстом викриває інфраструктуру за об'ємним шахрайством.

Tracio виявляє віртуалізацію як частину свого device intelligence по 130+ сигналах — сигнатури GPU й рендерингу, перевірки таймінгу й когерентності заліза, аналіз мобільних сенсорів і build-ідентичності — у поєднанні з мережевим контекстом IP intelligence та перевірками когерентності між сигналами, що ловлять спроби підробки, які пропускають односигнальні детектори. Воно проходить через шар bot detection і повертає вирок із прикріпленими базовими сигналами менш ніж за 50 мс.

Хочете побачити, як виявлення віртуалізації працює проти трафіку ферм пристроїв і емуляторів у вашій власній воронці?

Почніть безкоштовний пробний період — 2500 верифікацій безкоштовно, без потреби в кредитній картці. Замовте демо, щоб пройтися виявленням емуляторів і VM проти вашої конкретної моделі загроз.