Detección de emuladores y máquinas virtuales en el tráfico web

La mayor parte del fraude que corre a escala corre sobre infraestructura virtualizada, porque la alternativa —una sala llena de teléfonos y laptops físicos— no escala y no se oculta. Un emulador o una máquina virtual permite a un operador levantar bajo demanda miles de dispositivos aparentemente distintos, cada uno con aspecto de un endpoint de consumo recién estrenado. Detectar esa virtualización es una de las cosas de mayor apalancamiento que hace una capa de inteligencia de dispositivos, porque identifica la infraestructura del abuso a escala en lugar de perseguir acciones fraudulentas individuales una por una.

Este artículo cubre cómo los emuladores y las máquinas virtuales se delatan en el tráfico web y de apps: las señales de hardware, temporización y coherencia que un entorno virtualizado tiene dificultades para reproducir, por qué ninguna señal por sí sola basta, y cómo actuar sobre la detección sin romper la virtualización legítima. La audiencia son ingenieros y equipos de fraude que construyen o evalúan detección de bots.

Por qué los emuladores y las VM importan para el fraude

Los emuladores y las máquinas virtuales importan porque son el sustrato rentable del fraude de volumen —convierten una sola máquina en una flota de dispositivos de aspecto limpio, que es exactamente lo que requiere la economía de la mayor parte del fraude.

El problema recurrente en el fraude es la escala. Una sola cuenta falsa o una sola transacción fraudulenta rara vez es rentable; el dinero está en hacerlo miles de veces. Hacerlo miles de veces necesita miles de identidades de dispositivo, porque las plataformas vinculan cada vez más el abuso por dispositivo (ver cómo funciona la huella digital de dispositivos). El hardware físico es la forma honesta de obtener muchas identidades de dispositivo y es prohibitivamente caro y lento. La virtualización es la forma barata.

En concreto, la virtualización sustenta:

Granjas de dispositivos. Racks de dispositivos móviles emulados o instancias de navegador headless, orquestados para crear cuentas, reclamar promociones, publicar reseñas falsas o ejecutar credential stuffing y abuso de creación de cuentas a volumen. Cada instancia emulada se presenta como un teléfono o una laptop separados.

Emulación de apps móviles. Ejecutar apps de Android o iOS en emuladores sobre hardware de escritorio o de servidor para automatizar flujos basados en apps que se suponía que requerían un teléfono real —registros móviles, promociones restringidas a apps, fraude dentro de la app.

Navegadores en la nube y browser-as-a-service. Navegadores completos corriendo en VM en la nube, automatizados para scraping, fraude publicitario y abuso de cuentas. Estos son más sofisticados que los bots toscos porque renderizan las páginas por completo y ejecutan JavaScript.

El hilo común: una máquina física, muchas identidades virtuales. Si puede detectar la virtualización, colapsa la flota de vuelta a su tamaño real —y un "millar de usuarios" que en realidad es un host emulado es una decisión de riesgo muy distinta de un millar de dispositivos reales. Por eso la detección de virtualización es un multiplicador de fuerza: ataca la estructura de costos que hace viable el fraude de volumen.

Qué delata a una máquina virtual

Una máquina virtual se delata a través de señales físicas que tiene que sintetizar en lugar de poseer —la GPU, el comportamiento de temporización, los sensores y los artefactos de bajo nivel del hipervisor sobre el que corre. El hardware de consumo real produce estas señales como efecto secundario de ser real; una VM tiene que fingirlas, y fingirlas todas de forma coherente es difícil.

Firmas de GPU virtualizada. Este es uno de los indicios más fuertes. El renderizado de gráficos depende de la GPU real, su controlador y su comportamiento de punto flotante. Las VM suelen usar gráficos virtualizados o renderizados por software —SwiftShader, llvmpipe, GPU virtuales de VMware/VirtualBox/QEMU, o una GPU en passthrough que aun así reporta cadenas delatoras. Las cadenas de renderizador y de fabricante de WebGL frecuentemente nombran la virtualización directamente ("SwiftShader", "llvmpipe", "VMware SVGA", "Google SwiftShader"), e incluso cuando esas cadenas se falsifican, la propia salida de renderizado de canvas y WebGL difiere de las GPU físicas de maneras sutiles y difíciles de fingir. Una GPU real renderiza una escena compleja con artefactos característicos específicos del controlador; el renderizado por software produce una firma distinta.

Temporización demasiado limpia. El hardware real es ruidoso. La compilación JIT, la recolección de basura, el throttling térmico, las interrupciones del sistema operativo y los efectos de la jerarquía de memoria introducen jitter continuo en las mediciones de temporización. Los entornos virtualizados —en especial los alojados en la nube sobre infraestructura de alta calidad— a menudo corren demasiado suavemente, con una varianza de temporización menor que la que exhiben los dispositivos de consumo físicos. La temporización de alta resolución de patrones de cómputo específicos puede revelar un entorno cuyo perfil de rendimiento es antinaturalmente uniforme. Paradójicamente, la "limpieza" de una VM de centro de datos es en sí misma la señal.

Artefactos de hipervisor. La virtualización deja rastros de bajo nivel: flags de características de CPU y peculiaridades de temporización de instrucciones que difieren bajo un hipervisor, comportamiento específico del TSC (timestamp counter) y —donde sea observable— valores de concurrencia de hardware y de memoria que se agrupan en torno a configuraciones típicas de VM en lugar de las típicas de consumo. Un dispositivo que reporta un recuento de núcleos y un perfil de memoria muy propios de servidor mientras afirma ser una laptop de consumo es incoherente.

Huellas de audio y de otro hardware. La huella de AudioContext depende del subsistema de audio; el hardware de audio virtualizado o ausente produce una salida de punto flotante que difiere del hardware de sonido real. Pequeña por sí sola, útil en combinación.

Contexto de red. Las flotas de emuladores y VM corren con frecuencia en centros de datos, así que la capa de red —ASN de centro de datos, IP de proveedor de hosting— corrobora las señales del endpoint. Una firma de VM y una IP de centro de datos es un patrón mucho más fuerte que cualquiera por sí solo. (Los operadores sofisticados anteponen a sus VM proxies residenciales para ocultar el lado de la red, que es exactamente por lo que la detección de VM a nivel de endpoint importa de forma independiente —sobrevive al proxy.)

Cómo se delatan los emuladores móviles

Los emuladores móviles se delatan a través del mismo principio aplicado a los teléfonos: tienen que sintetizar las características específicas de hardware, sensores y renderizado de un dispositivo físico, y la síntesis es incompleta. Una app de Android o iOS corriendo en un emulador sobre hardware de escritorio no es un teléfono, y una docena de señales lo dicen.

Cadenas de identidad de hardware. Los emuladores llevan valores característicos de modelo de dispositivo, build fingerprint y nombre de hardware. Los emuladores de Android reportan históricamente "generic", "goldfish", "ranchu", "sdkgphone" e identificadores de build similares, junto con nombres de modelo típicos de emulador. Incluso cuando estos se parchean para imitar un dispositivo real, la _combinación de modelo, placa, ABI de CPU y build fingerprint a menudo no coincide con ningún dispositivo real que se haya comercializado —un supuesto teléfono insignia con una ABI x86 (los teléfonos reales son ARM) es un delator.

Sensores ausentes o falsos. Los teléfonos reales tienen acelerómetros, giroscopios, magnetómetros, sensores de luz ambiental y barómetros, y —de forma crucial— esos sensores producen datos continuos, correlacionados y ruidosos a medida que el dispositivo se sostiene y se mueve. Los emuladores o bien carecen de estos sensores, reportan valores estáticos, o reproducen patrones sintéticos que no tienen la varianza natural y la correlación entre sensores de un dispositivo sostenido por una mano humana. Un "teléfono" cuyo acelerómetro lee una constante perfecta, o cuyo giroscopio y acelerómetro no se mueven juntos como exige la física, está emulado.

Diferencias de renderizado y GPU. Igual que en el escritorio, la firma de renderizado de la GPU móvil difiere entre la GPU móvil de un teléfono físico (Adreno, Mali, GPU de Apple) y una emulada o renderizada por software. La densidad de pantalla, la resolución y los artefactos de renderizado que deberían coincidir con un modelo de teléfono concreto declarado a menudo no lo hacen.

Perfil de temporización y rendimiento. Una app de teléfono corriendo sobre hardware de clase servidor en un emulador rinde de forma distinta que la misma app sobre el SoC del teléfono real —a menudo más rápido y suave de lo que sería el dispositivo real, otra instancia del indicio de lo "demasiado limpio".

El caso móvil es donde los datos de los sensores se vuelven decisivos, porque son genuinamente difíciles de fingir bien. Reproducir la salida continua y físicamente coherente de los sensores de movimiento de un teléfono real —acelerómetro y giroscopio coincidiendo sobre el mismo movimiento, con un micro-jitter realista de mano humana— es mucho más trabajo que editar una cadena de nombre de modelo, y la mayoría de las configuraciones de emulación no lo hacen de forma convincente.

Por qué ninguna señal por sí sola es suficiente

Ninguna señal por sí sola detecta de forma fiable la virtualización, porque cualquiera de ellas puede ser falsificada por un operador que la conozca —por lo que la detección robusta depende de la coherencia entre señales en lugar de cualquier comprobación individual. Este es el mismo principio que gobierna la detección de navegadores anti-detección: los indicios individuales son parcheables; la coherencia entre todos ellos no lo es.

Un operador decidido:

• Falsificará las cadenas de fabricante/renderizador de WebGL para nombrar una GPU real.
• Parcheará el build fingerprint y el modelo de Android para coincidir con un teléfono real.
• Inyectará valores sintéticos de sensor para falsear los datos de movimiento.
• Antepondrá a la VM un proxy residencial para limpiar la señal de red.

Cualquiera de estos derrota a un detector que se apoye en esa única señal. Un sistema que solo comprueba la cadena de renderizador de WebGL se vence con una edición de cadena. Un sistema que solo comprueba build fingerprints se vence con un parche.

Lo difícil es hacer todo ello de forma coherente a la vez. El operador que falsifica la cadena de WebGL para afirmar una GPU Adreno aún produce una salida de renderizado de canvas que no coincide con una Adreno real. El que falsea el nombre de modelo aún reporta una ABI x86, o un recuento de núcleos que ningún teléfono así tiene, o datos de sensor sin correlación realista entre sensores, o una temporización demasiado limpia para el SoC que afirma. Cada falsificación que añade es otra superficie que tiene que mantenerse consistente con todas las demás, y las restricciones se multiplican.

Este es el principio de la coherencia ambiental: la detección no es "¿parece virtualizado este único valor?", es "¿describen todos estos valores un único dispositivo real y físicamente posible?". Un supuesto iPhone cuya GPU renderiza como software, cuyos sensores leen constantes, cuya ABI es x86 y cuya temporización es suave como la de un centro de datos no es incoherente de una manera —es incoherente de cuatro, y reconciliar las cuatro simultáneamente es la parte cara. El costo de mantener la coherencia completa entre cada señal es lo que hace que la detección basada en coherencia se sostenga donde las comprobaciones de una sola señal fallan. La carrera armamentista más amplia y su estado actual se cubren en el estado del tráfico de bots.

Cómo actuar sobre la detección de virtualización

No bloquee la virtualización de forma refleja —pondérela como una señal de riesgo en contexto, porque la virtualización legítima existe y un bloqueo generalizado causa falsos positivos. La respuesta correcta depende de qué más sea cierto sobre el tráfico.

Hay razones reales y legítimas por las que un usuario podría estar en una VM o un emulador: desarrolladores probando en emuladores, investigadores de seguridad, usuarios preocupados por la privacidad que corren navegadores en VM, infraestructura corporativa de escritorio virtual, configuraciones de accesibilidad. Bloquear toda la virtualización de plano penaliza a estos usuarios. La virtualización es una señal de riesgo, no un veredicto.

El enfoque productivo la trata como una entrada más en una decisión graduada:

• Virtualización sola, contexto por lo demás normal: riesgo de bajo a moderado. Un solo desarrollador en un emulador no es fraude. Anótelo, no lo bloquee.
• Virtualización + red de centro de datos + cuenta nueva + alta velocidad: riesgo alto. Esta es la firma de la granja de dispositivos —un endpoint emulado, sobre infraestructura de hosting, creando cuentas rápidamente. Las señales se corroboran entre sí en un veredicto seguro.
• Virtualización + violaciones de coherencia (cadenas falsificadas que no coinciden con el renderizado, combinaciones de hardware imposibles): riesgo alto. La virtualización más los intentos activos de ocultarla es en sí misma la señal más fuerte —los usuarios legítimos de VM no parchean sus build fingerprints para hacerse pasar por teléfonos insignia.
• Correlación de flota: cuando muchos dispositivos "distintos" comparten la firma delatora de virtualización y se comportan de forma coordinada, la detección de flota los colapsa a su verdadero origen, lo que es decisivo con independencia de la apariencia de cualquier cuenta individual.

El patrón es consistente con la detección de navegadores headless y con la detección de bots en general: la señal individual informa la puntuación, la combinación de señales produce el veredicto, y la respuesta es graduada —permitir, desafiar o bloquear— en lugar de un bloqueo tosco de la virtualización como tal. La detección de emuladores y VM es más valiosa no como una compuerta autónoma, sino como una señal fuertemente ponderada que, combinada con el contexto de red y de comportamiento, expone la infraestructura detrás del fraude de volumen.

Tracio detecta la virtualización como parte de su inteligencia de dispositivos a través de más de 130 señales —firmas de GPU y de renderizado, comprobaciones de temporización y de coherencia de hardware, análisis de sensores móviles y de identidad de build— combinadas con el contexto de red de IP intelligence y comprobaciones de coherencia entre señales que atrapan los intentos de falsificación que los detectores de una sola señal pasan por alto. Corre a través de la capa de detección de bots y devuelve un veredicto, con las señales subyacentes adjuntas, en menos de 50 ms.

¿Quiere ver cómo rinde la detección de virtualización contra el tráfico de granjas de dispositivos y emuladores en su propio embudo?

Inicie su prueba gratuita — 2,500 verificaciones gratis, sin tarjeta de crédito. Solicite una demo para recorrer la detección de emuladores y VM contra su modelo de amenazas concreto.