Rilevare emulatori e macchine virtuali nel traffico web

La maggior parte delle frodi che operano su larga scala gira su infrastruttura virtualizzata, perché l'alternativa — una stanza piena di telefoni e portatili fisici — non scala e non si nasconde. Un emulatore o una macchina virtuale permette a un singolo operatore di avviare a comando migliaia di dispositivi apparentemente distinti, ciascuno con l'aspetto di un nuovo endpoint di consumo. Rilevare quella virtualizzazione è una delle attività a più alto rendimento di uno strato di intelligence dei dispositivi, perché identifica l'infrastruttura dell'abuso su larga scala anziché rincorrere le singole azioni fraudolente una alla volta.

Questo articolo illustra come emulatori e VM si rivelano nel traffico web e app: i segnali di hardware, tempistiche e coerenza che un ambiente virtualizzato fatica a riprodurre, perché nessun singolo segnale è sufficiente e come agire sul rilevamento senza compromettere la virtualizzazione legittima. Il pubblico sono ingegneri e team antifrode che costruiscono o valutano il rilevamento dei bot.

Perché emulatori e VM contano per le frodi

Emulatori e macchine virtuali contano perché sono il substrato economicamente efficiente per le frodi di volume — trasformano una singola macchina in una flotta di dispositivi dall'aspetto pulito, che è esattamente ciò che richiede l'economia della maggior parte delle frodi.

Il problema ricorrente nelle frodi è la scala. Un singolo account falso o una singola transazione fraudolenta raramente rendono; il denaro sta nel farlo migliaia di volte. Farlo migliaia di volte richiede migliaia di identità di dispositivo, perché le piattaforme collegano sempre più l'abuso in base al dispositivo (vedi come funziona il fingerprinting del dispositivo). L'hardware fisico è il modo onesto di ottenere molte identità di dispositivo ed è proibitivamente costoso e lento. La virtualizzazione è il modo economico.

Concretamente, la virtualizzazione è alla base di:

Device farm. Rack di dispositivi mobili emulati o istanze di browser headless, orchestrati per creare account, riscattare promozioni, pubblicare recensioni false o eseguire credential stuffing (immissione automatica di credenziali rubate) e abuso di creazione account su larga scala. Ogni istanza emulata si presenta come un telefono o un portatile separato.

Emulazione di app mobili. Eseguire app Android o iOS in emulatori su hardware desktop o server per automatizzare flussi basati su app che dovevano richiedere un telefono reale — registrazioni mobili, promozioni riservate ad app, frodi in-app.

Browser cloud e browser-as-a-service. Browser completi in esecuzione in VM cloud, automatizzati per scraping, frodi pubblicitarie e abuso di account. Sono più sofisticati dei bot grezzi perché renderizzano completamente le pagine ed eseguono JavaScript.

Il filo conduttore: una macchina fisica, molte identità virtuali. Se si riesce a rilevare la virtualizzazione, si ricomprime la flotta alla sua vera dimensione — e un «migliaio di utenti» che in realtà è un unico host emulato è una decisione di rischio molto diversa da un migliaio di dispositivi reali. Per questo il rilevamento della virtualizzazione è un moltiplicatore di forza: attacca la struttura dei costi che rende praticabile la frode di volume.

Cosa tradisce una macchina virtuale

Una macchina virtuale si tradisce attraverso segnali fisici che deve sintetizzare anziché possedere — la GPU, il comportamento delle tempistiche, i sensori e gli artefatti di basso livello dell'hypervisor su cui gira. L'hardware di consumo reale produce questi segnali come effetto collaterale dell'essere reale; una VM deve falsificarli, e falsificarli tutti in modo coerente è difficile.

Firme di GPU virtualizzata. Questa è una delle spie più forti. Il rendering grafico dipende dalla GPU effettiva, dal suo driver e dal suo comportamento in virgola mobile. Le VM usano tipicamente grafica virtualizzata o resa via software — SwiftShader, llvmpipe, GPU virtuali VMware/VirtualBox/QEMU, o una GPU passata direttamente che riporta comunque stringhe rivelatrici. Le stringhe del renderer e del vendor WebGL spesso nominano direttamente la virtualizzazione («SwiftShader», «llvmpipe», «VMware SVGA», «Google SwiftShader»), e anche quando quelle stringhe sono falsificate, l'output di rendering di canvas e WebGL differisce dalle GPU fisiche in modi sottili e difficili da falsificare. Una GPU reale renderizza una scena complessa con artefatti caratteristici specifici del driver; il rendering software produce una firma diversa.

Tempistiche troppo pulite. L'hardware reale è rumoroso. Compilazione JIT, garbage collection, throttling termico, interrupt del sistema operativo ed effetti della gerarchia di memoria introducono jitter continuo nelle misurazioni delle tempistiche. Gli ambienti virtualizzati — specialmente quelli ospitati in cloud su infrastruttura di alta qualità — spesso girano troppo fluidamente, con una varianza temporale inferiore a quella che mostrano i dispositivi di consumo fisici. La misurazione ad alta risoluzione di specifici pattern di calcolo può rivelare un ambiente il cui profilo prestazionale è innaturalmente uniforme. Paradossalmente, la «pulizia» di una VM in datacenter è di per sé il segnale.

Artefatti dell'hypervisor. La virtualizzazione lascia tracce di basso livello: flag di funzionalità della CPU e stranezze nei tempi di esecuzione delle istruzioni che differiscono sotto un hypervisor, comportamento specifico del TSC (contatore di timestamp) e — dove osservabili — valori di hardware-concurrency e memoria che si raggruppano attorno a configurazioni tipiche delle VM anziché a quelle tipiche dei dispositivi di consumo. Un dispositivo che riporta un numero di core e un profilo di memoria molto simili a quelli di un server mentre dichiara di essere un portatile di consumo è incoerente.

Audio e altri fingerprint hardware. Il fingerprint di AudioContext dipende dal sottosistema audio; hardware audio virtualizzato o assente produce un output in virgola mobile che differisce da quello dell'hardware sonoro reale. Piccolo di per sé, utile in combinazione.

Contesto di rete. Le flotte di emulatori e VM girano frequentemente nei data center, quindi lo strato di rete — ASN di data center, IP di hosting provider — corrobora i segnali dell'endpoint. Una firma di VM e un IP di data center è un pattern molto più forte di ciascuno preso singolarmente. (Gli operatori sofisticati mettono davanti alle loro VM dei proxy residenziali per nascondere il lato rete, il che è esattamente il motivo per cui il rilevamento della VM a livello di endpoint conta in modo indipendente — sopravvive al proxy.)

Come si rivelano gli emulatori mobili

Gli emulatori mobili si rivelano attraverso lo stesso principio applicato ai telefoni: devono sintetizzare le specifiche caratteristiche di hardware, sensori e rendering di un dispositivo fisico, e la sintesi è incompleta. Un'app Android o iOS in esecuzione in un emulatore su hardware desktop non è un telefono, e una dozzina di segnali lo dicono.

Stringhe di identità hardware. Gli emulatori portano valori caratteristici di modello del dispositivo, build fingerprint e nome hardware. Gli emulatori Android storicamente riportano «generic», «goldfish», «ranchu», «sdkgphone» e identificatori di build simili, insieme a nomi di modello tipici degli emulatori. Anche quando questi sono modificati per imitare un dispositivo reale, la _combinazione di modello, board, ABI della CPU e build fingerprint spesso non corrisponde ad alcun dispositivo reale che sia stato commercializzato — un presunto telefono di punta con un'ABI x86 (i telefoni reali sono ARM) è una rivelazione.

Sensori assenti o falsi. I telefoni reali hanno accelerometri, giroscopi, magnetometri, sensori di luce ambientale e barometri, e — cosa cruciale — quei sensori producono dati continui, correlati e rumorosi mentre il dispositivo viene tenuto in mano e mosso. Gli emulatori o mancano di questi sensori, riportano valori statici o riproducono pattern sintetici privi della varianza naturale e della correlazione tra sensori di un dispositivo tenuto da una mano umana. Un «telefono» il cui accelerometro legge una costante perfetta, o il cui giroscopio e accelerometro non si muovono insieme come richiede la fisica, è emulato.

Differenze di rendering e GPU. Proprio come su desktop, la firma di rendering della GPU mobile differisce tra la GPU mobile di un telefono fisico (Adreno, Mali, Apple GPU) e una emulata o resa via software. Densità dello schermo, risoluzione e artefatti di rendering che dovrebbero corrispondere a uno specifico modello di telefono dichiarato spesso non lo fanno.

Profilo di tempistiche e prestazioni. Un'app per telefono in esecuzione su hardware di classe server in un emulatore si comporta diversamente dalla stessa app sul SoC del telefono effettivo — spesso più veloce e fluida di quanto sarebbe il dispositivo reale, un'altra manifestazione della spia del «troppo pulito».

Il caso mobile è dove i dati dei sensori diventano decisivi, perché sono genuinamente difficili da falsificare bene. Riprodurre l'output continuo e fisicamente coerente dei sensori di movimento di un telefono reale — accelerometro e giroscopio che concordano sullo stesso movimento, con realistico micro-jitter da mano umana — è molto più lavoro che modificare una stringa con il nome del modello, e la maggior parte delle configurazioni di emulazione non lo fa in modo convincente.

Perché nessun singolo segnale è sufficiente

Nessun singolo segnale rileva in modo affidabile la virtualizzazione, perché ciascun segnale può essere falsificato da un operatore che ne è a conoscenza — ed è per questo che un rilevamento robusto dipende dalla coerenza tra segnali anziché da un singolo controllo. È lo stesso principio che governa il rilevamento dei browser anti-rilevamento: le singole spie sono correggibili; la coerenza tra tutte non lo è.

Un operatore determinato:

• Falsificherà le stringhe del vendor/renderer WebGL per nominare una GPU reale.
• Modificherà il build fingerprint e il modello Android per corrispondere a un telefono reale.
• Inietterà valori sintetici dei sensori per falsificare i dati di movimento.
• Metterà davanti alla VM un proxy residenziale per ripulire il segnale di rete.

Ciascuno di questi sconfigge un rilevatore che si basa su quell'unico segnale. Un sistema che controlla solo la stringa del renderer WebGL è battuto da una modifica della stringa. Un sistema che controlla solo i build fingerprint è battuto da una patch.

Ciò che è difficile è fare tutto questo in modo coerente contemporaneamente. L'operatore che falsifica la stringa WebGL per dichiarare una GPU Adreno produce comunque un output di rendering del canvas che non corrisponde a una Adreno reale. Chi falsifica il nome del modello riporta comunque un'ABI x86, o un numero di core che nessun telefono simile possiede, o dati dei sensori senza una realistica correlazione tra sensori, o tempistiche troppo pulite per il SoC che dichiara. Ogni falsificazione aggiunta è un'altra superficie che deve restare coerente con tutte le altre, e i vincoli si moltiplicano.

Questo è il principio della coerenza ambientale: il rilevamento non è «questo singolo valore sembra virtualizzato», è «tutti questi valori descrivono un unico dispositivo reale e fisicamente possibile». Un presunto iPhone la cui GPU renderizza come software, i cui sensori leggono costanti, la cui ABI è x86 e le cui tempistiche sono fluide come in datacenter non è incoerente in un solo modo — è incoerente in quattro, e riconciliare tutti e quattro simultaneamente è la parte costosa. Il costo di mantenere la piena coerenza su ogni segnale è ciò che fa reggere il rilevamento basato sulla coerenza dove i controlli su singolo segnale falliscono. La più ampia corsa agli armamenti e il suo stato attuale sono trattati nello stato del traffico dei bot.

Come agire sul rilevamento della virtualizzazione

Non blocchi riflessivamente la virtualizzazione — la pesi come segnale di rischio nel contesto, perché esiste una virtualizzazione legittima e un blocco indiscriminato causa falsi positivi. La risposta giusta dipende da cos'altro è vero riguardo al traffico.

Ci sono ragioni reali e legittime per cui un utente potrebbe trovarsi in una VM o in un emulatore: sviluppatori che testano su emulatori, ricercatori di sicurezza, utenti attenti alla privacy che eseguono browser in VM, infrastrutture aziendali di virtual desktop, configurazioni di accessibilità. Bloccare tutta la virtualizzazione senza distinzioni penalizza questi utenti. La virtualizzazione è un segnale di rischio, non un verdetto.

L'approccio produttivo la tratta come un input in una decisione graduata:

• Virtualizzazione da sola, contesto per il resto normale: rischio da basso a moderato. Un singolo sviluppatore su un emulatore non è una frode. Lo annoti, non lo blocchi.
• Virtualizzazione + rete di data center + account nuovo + alta velocità: rischio elevato. Questa è la firma della device farm — un endpoint emulato, su infrastruttura di hosting, che crea account rapidamente. I segnali si corroborano a vicenda in un verdetto sicuro.
• Virtualizzazione + violazioni di coerenza (stringhe falsificate che non corrispondono al rendering, combinazioni hardware impossibili): rischio elevato. La virtualizzazione unita a tentativi attivi di nasconderla è di per sé il segnale più forte — gli utenti legittimi di VM non modificano i loro build fingerprint per impersonare telefoni di punta.
• Correlazione di flotta: quando molti dispositivi «distinti» condividono la firma rivelatrice della virtualizzazione e si comportano in modo coordinato, il rilevamento della flotta li ricomprime alla loro vera origine, il che è decisivo indipendentemente dall'aspetto di ogni singolo account.

Il pattern è coerente con il rilevamento dei browser headless e con il rilevamento dei bot in generale: il singolo segnale informa il punteggio, la combinazione di segnali produce il verdetto, e la risposta è graduata — consentire, sfidare o bloccare — anziché un blocco brutale sulla virtualizzazione in quanto tale. Il rilevamento di emulatori e VM è al suo massimo valore non come barriera autonoma ma come segnale fortemente ponderato che, combinato con il contesto di rete e comportamentale, espone l'infrastruttura dietro le frodi di volume.

Tracio rileva la virtualizzazione come parte della sua intelligence dei dispositivi su oltre 130+ segnali — firme di GPU e rendering, controlli di coerenza di tempistiche e hardware, analisi dei sensori mobili e dell'identità di build — combinati con il contesto di rete della IP intelligence e con controlli di coerenza tra segnali che colgono i tentativi di falsificazione che i rilevatori a singolo segnale mancano. Passa attraverso lo strato di rilevamento dei bot e restituisce un verdetto, con i segnali sottostanti allegati, in meno di 50ms.

Vuole vedere come si comporta il rilevamento della virtualizzazione contro il traffico di device farm ed emulatori nel suo funnel?

Inizi la sua prova gratuita — 2.500 verifiche gratuite, senza carta di credito. Prenoti una demo per esaminare il rilevamento di emulatori e VM rispetto al suo specifico modello di minaccia.