Detectando emuladores e máquinas virtuais no tráfego web

A maior parte da fraude que roda em escala roda sobre infraestrutura virtualizada, porque a alternativa — uma sala cheia de celulares e notebooks físicos — não escala e não se esconde. Um emulador ou uma máquina virtual permite que um único operador crie sob demanda milhares de dispositivos aparentemente distintos, cada um parecendo um endpoint de consumo novo. Detectar essa virtualização é uma das coisas de maior alavancagem que uma camada de inteligência de dispositivos faz, porque identifica a infraestrutura do abuso em escala em vez de perseguir ações fraudulentas individuais uma a uma.

Este artigo cobre como emuladores e VMs se revelam no tráfego web e de aplicativos: os sinais de hardware, timing e coerência que um ambiente virtualizado tem dificuldade de reproduzir, por que nenhum sinal isolado é suficiente e como agir sobre a detecção sem quebrar a virtualização legítima. O público são engenheiros e times de fraude que constroem ou avaliam detecção de bots.

Por que emuladores e VMs importam para a fraude

Emuladores e máquinas virtuais importam porque são o substrato de baixo custo da fraude em volume — eles transformam uma única máquina em uma frota de dispositivos de aparência limpa, que é exatamente o que a economia da maioria das fraudes exige.

O problema recorrente na fraude é a escala. Uma única conta falsa ou uma única transação fraudulenta raramente compensa; o dinheiro está em fazer isso milhares de vezes. Fazer isso milhares de vezes exige milhares de identidades de dispositivo, porque as plataformas cada vez mais vinculam o abuso por dispositivo (veja como funciona a impressão digital de dispositivo). O hardware físico é a maneira honesta de obter muitas identidades de dispositivo, e é proibitivamente caro e lento. A virtualização é a maneira barata.

Concretamente, a virtualização é a base de:

Device farms. Racks de dispositivos móveis emulados ou instâncias de navegador headless, orquestrados para criar contas, resgatar promoções, publicar avaliações falsas ou executar credential stuffing (preenchimento de credenciais) e abuso de criação de contas em volume. Cada instância emulada se apresenta como um celular ou notebook separado.

Emulação de apps móveis. Executar apps Android ou iOS em emuladores sobre hardware de desktop ou servidor para automatizar fluxos baseados em app que deveriam exigir um celular real — cadastros móveis, promoções restritas a apps, fraude dentro do app.

Navegadores em nuvem e browser-as-a-service. Navegadores completos rodando em VMs na nuvem, automatizados para scraping, fraude de anúncios e abuso de contas. Eles são mais sofisticados que bots rudimentares porque renderizam páginas por completo e executam JavaScript.

O fio comum: uma máquina física, muitas identidades virtuais. Se você consegue detectar a virtualização, colapsa a frota de volta ao seu tamanho real — e "mil usuários" que na verdade são um único host emulado é uma decisão de risco muito diferente de mil dispositivos reais. É por isso que a detecção de virtualização é um multiplicador de força: ela ataca a estrutura de custos que torna a fraude em volume viável.

O que entrega uma máquina virtual

Uma máquina virtual se entrega por meio de sinais físicos que ela precisa sintetizar em vez de possuir — a GPU, o comportamento de timing, os sensores e os artefatos de baixo nível do hipervisor em que roda. O hardware de consumo real produz esses sinais como efeito colateral de ser real; uma VM precisa forjá-los, e forjar todos eles de forma coerente é difícil.

Assinaturas de GPU virtualizada. Este é um dos indícios mais fortes. A renderização gráfica depende da GPU real, de seu driver e de seu comportamento de ponto flutuante. As VMs normalmente usam gráficos virtualizados ou renderizados por software — SwiftShader, llvmpipe, GPUs virtuais VMware/VirtualBox/QEMU ou uma GPU repassada (passthrough) que ainda relata strings reveladoras. As strings de renderizador e fabricante do WebGL frequentemente nomeiam a virtualização diretamente ("SwiftShader", "llvmpipe", "VMware SVGA", "Google SwiftShader") e, mesmo quando essas strings são falsificadas, a própria saída de renderização de canvas e WebGL difere das GPUs físicas de maneiras sutis e difíceis de forjar. Uma GPU real renderiza uma cena complexa com artefatos característicos específicos do driver; a renderização por software produz uma assinatura diferente.

Timing limpo demais. O hardware real é ruidoso. Compilação JIT, coleta de lixo, throttling térmico, interrupções do sistema operacional e efeitos de hierarquia de memória introduzem jitter contínuo nas medições de timing. Ambientes virtualizados — especialmente os hospedados em nuvem sobre infraestrutura de alta qualidade — muitas vezes rodam suaves demais, com variância de timing menor que a exibida por dispositivos de consumo físicos. O timing de alta resolução de padrões de computação específicos pode revelar um ambiente cujo perfil de desempenho é antinaturalmente uniforme. Paradoxalmente, a "limpeza" de uma VM de datacenter é, ela própria, o sinal.

Artefatos de hipervisor. A virtualização deixa vestígios de baixo nível: flags de recursos de CPU e peculiaridades de timing de instruções que diferem sob um hipervisor, comportamento específico do TSC (contador de timestamp) e — onde observáveis — valores de hardware-concurrency e memória que se agrupam em torno de configurações típicas de VM em vez de típicas de consumo. Um dispositivo que relata uma contagem de núcleos e um perfil de memória muito semelhantes aos de servidor enquanto afirma ser um notebook de consumo é incoerente.

Impressões digitais de áudio e outros hardwares. A impressão digital do AudioContext depende do subsistema de áudio; hardware de áudio virtualizado ou ausente produz uma saída de ponto flutuante que difere do hardware de som real. Pequeno por si só, útil em combinação.

Contexto de rede. Frotas de emuladores e VMs frequentemente rodam em datacenters, então a camada de rede — ASN de datacenter, IP de provedor de hospedagem — corrobora os sinais do endpoint. Uma assinatura de VM e um IP de datacenter é um padrão muito mais forte do que qualquer um deles isolado. (Operadores sofisticados colocam proxies residenciais na frente de suas VMs para esconder o lado da rede, e é exatamente por isso que a detecção de VM em nível de endpoint importa de forma independente — ela sobrevive ao proxy.)

Como os emuladores móveis se revelam

Os emuladores móveis se revelam por meio do mesmo princípio aplicado aos celulares: eles precisam sintetizar as características específicas de hardware, sensores e renderização de um dispositivo físico, e a síntese é incompleta. Um app Android ou iOS rodando em um emulador sobre hardware de desktop não é um celular, e uma dúzia de sinais dizem isso.

Strings de identidade de hardware. Os emuladores carregam valores característicos de modelo de dispositivo, build fingerprint e nome de hardware. Emuladores Android historicamente relatam "generic", "goldfish", "ranchu", "sdkgphone" e identificadores de build semelhantes, junto com nomes de modelo típicos de emulador. Mesmo quando esses valores são adulterados para imitar um dispositivo real, a _combinação de modelo, placa, ABI da CPU e build fingerprint muitas vezes não corresponde a nenhum dispositivo real que tenha sido comercializado — um suposto celular topo de linha com uma ABI x86 (celulares reais são ARM) é um indício claro.

Sensores ausentes ou falsos. Celulares reais têm acelerômetros, giroscópios, magnetômetros, sensores de luz ambiente e barômetros e — crucialmente — esses sensores produzem dados contínuos, correlacionados e ruidosos conforme o dispositivo é segurado e movimentado. Os emuladores ou não têm esses sensores, ou relatam valores estáticos, ou reproduzem padrões sintéticos que não têm a variância natural e a correlação entre sensores de um dispositivo sendo segurado por uma mão humana. Um "celular" cujo acelerômetro registra uma constante perfeita, ou cujo giroscópio e acelerômetro não se movem juntos como a física exige, é emulado.

Diferenças de renderização e GPU. Assim como no desktop, a assinatura de renderização da GPU móvel difere entre a GPU móvel de um celular físico (Adreno, Mali, Apple GPU) e uma emulada ou renderizada por software. Densidade de tela, resolução e artefatos de renderização que deveriam corresponder a um modelo de celular específico alegado muitas vezes não correspondem.

Perfil de timing e desempenho. Um app de celular rodando em hardware de classe servidor dentro de um emulador se comporta de forma diferente do mesmo app no SoC do celular real — muitas vezes mais rápido e mais suave do que o dispositivo real seria, outra instância do indício "limpo demais".

O caso móvel é onde os dados de sensores se tornam decisivos, porque são genuinamente difíceis de forjar bem. Reproduzir a saída contínua e fisicamente coerente dos sensores de movimento de um celular real — acelerômetro e giroscópio concordando sobre o mesmo movimento, com micro-jitter realista de mão humana — dá muito mais trabalho do que editar uma string de nome de modelo, e a maioria das configurações de emulação não faz isso de forma convincente.

Por que nenhum sinal isolado é suficiente

Nenhum sinal isolado detecta a virtualização de forma confiável, porque qualquer sinal isolado pode ser falsificado por um operador que o conhece — e é por isso que a detecção robusta depende da coerência entre sinais, e não de qualquer verificação individual. Este é o mesmo princípio que rege a detecção de navegadores anti-detecção: indícios individuais são corrigíveis; a coerência entre todos eles não é.

Um operador determinado vai:

• Falsificar as strings de fabricante/renderizador do WebGL para nomear uma GPU real.
• Adulterar o build fingerprint e o modelo do Android para corresponder a um celular real.
• Injetar valores sintéticos de sensores para falsificar dados de movimento.
• Colocar um proxy residencial na frente da VM para limpar o sinal de rede.

Qualquer uma dessas medidas derrota um detector que se apoia naquele único sinal. Um sistema que só verifica a string de renderizador do WebGL é vencido por uma edição de string. Um sistema que só verifica build fingerprints é vencido por uma adulteração.

O que é difícil é fazer tudo isso de forma coerente ao mesmo tempo. O operador que falsifica a string do WebGL para alegar uma GPU Adreno ainda produz uma saída de renderização de canvas que não corresponde a uma Adreno real. O que falsifica o nome do modelo ainda relata uma ABI x86, ou uma contagem de núcleos que nenhum celular desse tipo tem, ou dados de sensores sem correlação realista entre sensores, ou um timing limpo demais para o SoC que está alegando. Cada falsificação que ele adiciona é mais uma superfície que precisa permanecer consistente com todas as outras, e as restrições se multiplicam.

Este é o princípio da coerência ambiental: a detecção não é "este valor isolado parece virtualizado", é "todos esses valores descrevem um único dispositivo real e fisicamente possível?". Um suposto iPhone cuja GPU renderiza como software, cujos sensores registram valores constantes, cuja ABI é x86 e cujo timing é suave como datacenter não é incoerente de uma maneira — é incoerente de quatro, e reconciliar todas as quatro simultaneamente é a parte cara. O custo de manter coerência total em cada sinal é o que faz a detecção baseada em coerência se sustentar onde as verificações de sinal único falham. A corrida armamentista mais ampla e o ponto em que ela está são cobertos no estado do tráfego de bots.

Como agir sobre a detecção de virtualização

Não bloqueie a virtualização por reflexo — pondere-a como um sinal de risco no contexto, porque existe virtualização legítima e um bloqueio generalizado causa falsos positivos. A resposta certa depende do que mais é verdade sobre o tráfego.

Existem razões reais e legítimas para um usuário estar em uma VM ou emulador: desenvolvedores testando em emuladores, pesquisadores de segurança, usuários preocupados com privacidade que rodam navegadores em VMs, infraestrutura corporativa de desktop virtual, configurações de acessibilidade. Bloquear toda a virtualização de imediato penaliza esses usuários. A virtualização é um sinal de risco, não um veredito.

A abordagem produtiva a trata como uma entrada em uma decisão graduada:

• Virtualização isolada, contexto de resto normal: risco baixo a moderado. Um único desenvolvedor em um emulador não é fraude. Registre, não bloqueie.
• Virtualização + rede de datacenter + conta nova + alta velocidade: risco alto. Esta é a assinatura de uma device farm — um endpoint emulado, em infraestrutura de hospedagem, criando contas rapidamente. Os sinais se corroboram em um veredito confiante.
• Virtualização + violações de coerência (strings falsificadas que não correspondem à renderização, combinações de hardware impossíveis): risco alto. A virtualização somada a tentativas ativas de escondê-la é, ela própria, o sinal mais forte — usuários legítimos de VM não adulteram seus build fingerprints para se passar por celulares topo de linha.
• Correlação de frota: quando muitos dispositivos "distintos" compartilham a assinatura reveladora de virtualização e se comportam de forma coordenada, a detecção de frota os colapsa à sua verdadeira origem, o que é decisivo independentemente da aparência de qualquer conta individual.

O padrão é consistente com a detecção de navegadores headless e com a detecção de bots em geral: o sinal individual informa a pontuação, a combinação de sinais produz o veredito e a resposta é graduada — permitir, desafiar ou bloquear — em vez de um bloqueio bruto sobre a virtualização como tal. A detecção de emuladores e VMs é mais valiosa não como um portão isolado, mas como um sinal fortemente ponderado que, combinado ao contexto de rede e comportamental, expõe a infraestrutura por trás da fraude em volume.

A Tracio detecta a virtualização como parte de sua inteligência de dispositivos ao longo de mais de 130 sinais — assinaturas de GPU e renderização, verificações de timing e coerência de hardware, análise de sensores móveis e de identidade de build — combinadas ao contexto de rede da IP intelligence e a verificações de coerência entre sinais que capturam as tentativas de falsificação que os detectores de sinal único deixam passar. Isso roda pela camada de detecção de bots e retorna um veredito, com os sinais subjacentes anexados, em menos de 50ms.

Quer ver como a detecção de virtualização se comporta contra o tráfego de device farms e emuladores no seu próprio funil?

Comece seu teste grátis — 2.500 verificações grátis, sem cartão de crédito. Agende uma demonstração para percorrer a detecção de emuladores e VMs contra o seu modelo de ameaça específico.