Выявление эмуляторов и виртуальных машин в веб-трафике
Эмуляторы и VM питают массовое мошенничество — device farms, эмуляция мобильных приложений, облачные браузеры. Выявляют их по сигналам железа, тайминга и согласованности, которые виртуальная среда не воспроизводит полностью.
Бо́льшая часть мошенничества, работающего в масштабе, работает на виртуализированной инфраструктуре, потому что альтернатива — комната, набитая физическими телефонами и ноутбуками, — не масштабируется и не прячется. Эмулятор или виртуальная машина позволяют одному оператору по требованию поднять тысячи как будто различных устройств, каждое из которых выглядит как свежий потребительский эндпоинт. Выявление этой виртуализации — одна из самых высокорычаговых вещей, которые делает слой device intelligence, потому что оно вскрывает инфраструктуру масштабного злоупотребления, а не гоняется за отдельными мошенническими действиями по одному.
Этот материал о том, как эмуляторы и VM выдают себя в веб- и app-трафике: о сигналах железа, тайминга и согласованности, которые виртуальная среда воспроизводит с трудом, о том, почему ни одного сигнала не хватает, и о том, как действовать по результатам детекта, не ломая легитимную виртуализацию. Аудитория — инженеры и антифрод-команды, которые строят или оценивают bot detection.
Почему эмуляторы и VM важны для мошенничества
Эмуляторы и виртуальные машины важны, потому что это экономически выгодный субстрат для объёмного мошенничества — они превращают одну машину в флот чисто выглядящих устройств, а именно этого и требует экономика большинства видов мошенничества.
Постоянная проблема в мошенничестве — масштаб. Один фейковый аккаунт или одна мошенническая транзакция редко окупаются; деньги — в том, чтобы проделать это тысячи раз. Проделать это тысячи раз нужно тысячи устройственных идентичностей, потому что платформы всё чаще связывают злоупотребление по устройству (см. как работает device fingerprinting). Физическое железо — честный способ получить много устройственных идентичностей, и он непозволительно дорог и медленен. Виртуализация — дешёвый способ.
Конкретно виртуализация лежит в основе:
Device farms. Стойки эмулированных мобильных устройств или инстансов headless-браузеров, оркестрированные для создания аккаунтов, отжимания промо, публикации фейковых отзывов, а также для credential stuffing и объёмного злоупотребления при регистрации. Каждый эмулированный инстанс представляется отдельным телефоном или ноутбуком.
Эмуляция мобильных приложений. Запуск Android- или iOS-приложений в эмуляторах на десктопном или серверном железе, чтобы автоматизировать app-сценарии, которые задумывались как требующие настоящего телефона, — мобильные регистрации, промо с гейтом на приложение, внутриприложенческое мошенничество.
Облачные браузеры и 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» и похожие идентификаторы сборки, а также типичные для эмуляторов имена моделей. Даже когда их патчат под настоящее устройство, *сочетание_ модели, платы, 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, а тайминг датацентрово-гладкий, несогласован не в одном — он несогласован в четырёх, и примирить все четыре одновременно — это дорогая часть. Издержки на поддержание полной согласованности по каждому сигналу — вот что даёт детекту на основе согласованности держаться там, где одиночные проверки проваливаются. Более широкая гонка вооружений и её текущее состояние разобраны в состоянии бот-трафика.
Как действовать по результатам детекта виртуализации
Не блокируйте виртуализацию рефлекторно — взвешивайте её как сигнал риска в контексте, потому что легитимная виртуализация существует, а сплошная блокировка порождает false positives. Правильная реакция зависит от того, что ещё верно про трафик.
Есть реальные, легитимные причины, по которым пользователь может быть в VM или эмуляторе: разработчики, тестирующие на эмуляторах, исследователи безопасности, заботящиеся о приватности пользователи, запускающие браузеры в VM, корпоративная инфраструктура виртуальных рабочих столов, сетапы под доступность. Блокировка всей виртуализации огулом наказывает этих пользователей. Виртуализация — сигнал риска, а не приговор.
Продуктивный подход трактует её как один вход в градуированное решение:
- Только виртуализация, в остальном нормальный контекст: от низкого до умеренного риска. Один разработчик на эмуляторе — не мошенничество. Отметьте, не блокируйте.
- Виртуализация + датацентровая сеть + свежий аккаунт + высокая скорость: высокий риск. Это сигнатура device farm — эмулированный эндпоинт на хостинг-инфраструктуре, быстро создающий аккаунты. Сигналы подтверждают друг друга, складываясь в уверенный вердикт.
- Виртуализация + нарушения согласованности (подделанные строки, не совпадающие с рендерингом, невозможные комбинации железа): высокий риск. Виртуализация плюс активные попытки её спрятать — сами по себе сильнейший сигнал: легитимные пользователи VM не патчат свои build-fingerprint, чтобы выдать себя за флагманские телефоны.
- Корреляция флота: когда много «различных» устройств делят характерную сигнатуру виртуализации и ведут себя скоординированно, детект флота схлопывает их к их истинному источнику, что решает всё независимо от вида любого отдельного аккаунта.
Паттерн согласуется с детектом headless-браузеров и bot detection в целом: отдельный сигнал влияет на счёт, комбинация сигналов даёт вердикт, а реакция градуирована — пропустить, бросить вызов или заблокировать — а не тупая блокировка виртуализации как таковой. Детект эмуляторов и VM наиболее ценен не как самостоятельный шлагбаум, а как сильно взвешенный сигнал, который в сочетании с сетевым и поведенческим контекстом вскрывает инфраструктуру за объёмным мошенничеством.
Tracio выявляет виртуализацию как часть своего device intelligence на 130+ сигналах — сигнатуры GPU и рендеринга, проверки тайминга и аппаратной согласованности, анализ мобильных сенсоров и build-идентичности — в сочетании с сетевым контекстом IP intelligence и проверками согласованности сигналов, которые ловят попытки подделки, упускаемые одиночными детекторами. Оно работает через слой bot detection и возвращает вердикт с приложенными исходными сигналами менее чем за 50 мс.
Хотите увидеть, как детект виртуализации показывает себя против device-farm- и эмуляторного трафика в вашей собственной воронке?
Начните бесплатный триал — 2 500 верификаций бесплатно, без карты. Забронируйте демо, чтобы пройтись по детекту эмуляторов и VM против вашей конкретной модели угроз.