Att upptäcka emulatorer och virtuella maskiner i webbtrafik

Det mesta av bedrägeriet som körs i stor skala körs på virtualiserad infrastruktur, eftersom alternativet — ett rum fullt av fysiska telefoner och laptops — inte skalar och inte döljer sig. En emulator eller en virtuell maskin låter en enda operatör starta upp tusentals till synes distinkta enheter på begäran, var och en som ser ut som en ny konsumentenhet. Att upptäcka den virtualiseringen är en av de mest effektfulla sakerna ett device intelligence-lager gör, eftersom det identifierar infrastrukturen bakom storskaligt missbruk snarare än att jaga enskilda bedrägliga handlingar en i taget.

Den här texten går igenom hur emulatorer och VM:ar avslöjar sig i webb- och apptrafik: hårdvaru-, timing- och koherenssignalerna som en virtualiserad miljö kämpar med att återskapa, varför ingen enskild signal räcker, och hur man agerar på detektionen utan att bryta legitim virtualisering. Målgruppen är ingenjörer och bedrägeriteam som bygger eller utvärderar bot detection.

Varför emulatorer och VM:ar är viktiga för bedrägeri

Emulatorer och virtuella maskiner är viktiga eftersom de är det kostnadseffektiva underlaget för storskaligt bedrägeri — de förvandlar en enda maskin till en flotta av rena enheter, vilket är precis vad de flesta bedrägeriekonomier kräver.

Det återkommande problemet i bedrägeri är skala. Ett enda falskt konto eller en enda bedräglig transaktion lönar sig sällan; pengarna finns i att göra det tusentals gånger. Att göra det tusentals gånger kräver tusentals enhetsidentiteter, eftersom plattformar i allt högre grad kopplar samman missbruk per enhet (se hur device fingerprinting fungerar). Fysisk hårdvara är det ärliga sättet att få många enhetsidentiteter, och det är oöverkomligt dyrt och långsamt. Virtualisering är det billiga sättet.

Konkret ligger virtualisering till grund för:

Device farms. Rackar av emulerade mobila enheter eller headless browser-instanser, orkestrerade för att skapa konton, hämta kampanjer, posta falska recensioner eller köra credential stuffing och kontoskapande-missbruk i volym. Varje emulerad instans framstår som en separat telefon eller laptop.

Mobilappsemulering. Att köra Android- eller iOS-appar i emulatorer på desktop- eller serverhårdvara för att automatisera appbaserade flöden som var tänkta att kräva en riktig telefon — mobila registreringar, appspärrade kampanjer, in-app-bedrägeri.

Molnbaserade webbläsare och browser-as-a-service. Fullständiga webbläsare som körs i moln-VM:ar, automatiserade för scraping, annonsbedrägeri och kontomissbruk. De är mer sofistikerade än råa botar eftersom de renderar sidor fullt ut och exekverar JavaScript.

Den gemensamma nämnaren: en fysisk maskin, många virtuella identiteter. Om du kan upptäcka virtualiseringen kollapsar du flottan tillbaka till dess verkliga storlek — och "tusen användare" som i själva verket är en enda emulerad värd är ett helt annat riskbeslut än tusen riktiga enheter. Det är därför virtualiseringsdetektion är en kraftmultiplikator: den angriper kostnadsstrukturen som gör storskaligt bedrägeri möjligt.

Vad som avslöjar en virtuell maskin

En virtuell maskin avslöjar sig genom fysiska signaler den måste syntetisera snarare än besitta — GPU:n, timingbeteendet, sensorerna och lågnivåartefakterna från hypervisorn den körs på. Riktig konsumenthårdvara producerar dessa signaler som en bieffekt av att vara verklig; en VM måste förfalska dem, och att förfalska dem alla koherent är svårt.

Virtualiserade GPU-signaturer. Detta är ett av de starkaste tecknen. Grafikrendering beror på den faktiska GPU:n, dess drivrutin och dess floating point-beteende. VM:ar använder vanligtvis virtualiserad eller mjukvarurenderad grafik — SwiftShader, llvmpipe, VMware/VirtualBox/QEMU virtuella GPU:er, eller en genomkopplad GPU som ändå rapporterar avslöjande strängar. WebGL-renderaren och tillverkarsträngarna namnger ofta virtualiseringen direkt ("SwiftShader", "llvmpipe", "VMware SVGA", "Google SwiftShader"), och även när dessa strängar förfalskas skiljer sig själva canvas- och WebGL-renderingsresultatet från fysiska GPU:er på subtila, svårförfalskade sätt. En riktig GPU renderar en komplex scen med karakteristiska drivrutinsspecifika artefakter; mjukvarurendering ger en annan signatur.

Timing som är för ren. Riktig hårdvara är brusig. JIT-kompilering, garbage collection, termisk strypning, OS-avbrott och effekter från minneshierarkin introducerar kontinuerligt jitter i timingmätningar. Virtualiserade miljöer — särskilt molnbaserade på högkvalitativ infrastruktur — körs ofta för jämnt, med lägre timingvariation än fysiska konsumentenheter uppvisar. Högupplöst timing av specifika beräkningsmönster kan avslöja en miljö vars prestandaprofil är onaturligt enhetlig. Paradoxalt nog är själva "renheten" hos en datacenter-VM signalen.

Hypervisor-artefakter. Virtualisering lämnar lågnivåspår: CPU-funktionsflaggor och egenheter i instruktionstiming som skiljer sig under en hypervisor, specifikt TSC-beteende (timestamp counter), och — där det är observerbart — hardware-concurrency- och minnesvärden som klustrar kring VM-typiska konfigurationer snarare än konsumenttypiska. En enhet som rapporterar ett mycket serverliknande antal kärnor och en serverliknande minnesprofil samtidigt som den påstår sig vara en konsumentlaptop är inkoherent.

Ljud- och andra hårdvarufingeravtryck. AudioContext-fingeravtrycket beror på ljudsubsystemet; virtualiserad eller frånvarande ljudhårdvara producerar floating point-utdata som skiljer sig från riktig ljudhårdvara. Litet i sig, användbart i kombination.

Nätverkskontext. Emulator- och VM-flottor körs ofta i datacenter, så nätverkslagret — datacenter-ASN, hostingleverantörens IP — bekräftar enhetssignalerna. En VM-signatur och en datacenter-IP är ett mycket starkare mönster än något av dem ensamt. (Sofistikerade operatörer sätter residentiella proxyn framför sina VM:ar för att dölja nätverkssidan, vilket är precis varför VM-detektion på enhetsnivå har betydelse oberoende — den överlever proxyn.)

Hur mobila emulatorer avslöjar sig

Mobila emulatorer avslöjar sig genom samma princip tillämpad på telefoner: de måste syntetisera de specifika hårdvaru-, sensor- och renderingsegenskaperna hos en fysisk enhet, och syntesen är ofullständig. En Android- eller iOS-app som körs i en emulator på desktophårdvara är inte en telefon, och ett dussin signaler säger det.

Hårdvaruidentitetssträngar. Emulatorer bär karakteristiska värden för enhetsmodell, build fingerprint och hårdvarunamn. Android-emulatorer har historiskt rapporterat "generic", "goldfish", "ranchu", "sdkgphone" och liknande build-identifierare, tillsammans med emulatortypiska modellnamn. Även när dessa patchas för att härma en riktig enhet stämmer _kombinationen av modell, kort, CPU-ABI och build fingerprint ofta inte med någon riktig enhet som skeppats — en påstådd flaggskeppstelefon med en x86-ABI (riktiga telefoner är ARM) är avslöjande.

Saknade eller falska sensorer. Riktiga telefoner har accelerometrar, gyroskop, magnetometrar, ljussensorer och barometrar, och — avgörande — dessa sensorer producerar kontinuerlig, korrelerad, brusig data när enheten hålls och rörs. Emulatorer saknar antingen dessa sensorer, rapporterar statiska värden, eller spelar upp syntetiska mönster som inte har den naturliga variationen och korrelationen mellan sensorer hos en enhet som hålls av en mänsklig hand. En "telefon" vars accelerometer läser av en perfekt konstant, eller vars gyroskop och accelerometer inte rör sig tillsammans så som fysiken kräver, är emulerad.

Rendering- och GPU-skillnader. Precis som på desktop skiljer sig den mobila GPU-renderingssignaturen mellan en fysisk telefons mobila GPU (Adreno, Mali, Apple GPU) och en emulerad eller mjukvarurenderad. Skärmtäthet, upplösning och renderingsartefakter som borde matcha en specifik påstådd telefonmodell gör det ofta inte.

Timing- och prestandaprofil. En telefonapp som körs på serverklass-hårdvara i en emulator presterar annorlunda än samma app på telefonens faktiska SoC — ofta snabbare och jämnare än den riktiga enheten skulle vara, ännu ett exempel på "för ren"-tecknet.

Det mobila fallet är där sensordata blir avgörande, eftersom den är genuint svår att förfalska väl. Att återskapa den kontinuerliga, fysiskt koherenta utdatan från en riktig telefons rörelsesensorer — accelerometer och gyroskop som är överens om samma rörelse, med realistisk mikro-jitter från en mänsklig hand — är mycket mer arbete än att redigera en modellnamnssträng, och de flesta emuleringsuppsättningar gör det inte övertygande.

Varför ingen enskild signal räcker

Ingen enskild signal upptäcker virtualisering på ett tillförlitligt sätt, eftersom vilken enskild signal som helst kan förfalskas av en operatör som känner till den — vilket är varför robust detektion beror på koherens mellan signaler snarare än någon enskild kontroll. Detta är samma princip som styr detektion av anti-detect-webbläsare: enskilda tecken är patchbara; koherens över alla är det inte.

En beslutsam operatör kommer att:

• Förfalska WebGL:s tillverkar-/renderarsträngar för att namnge en riktig GPU.
• Patcha Android build fingerprint och modell för att matcha en riktig telefon.
• Injicera syntetiska sensorvärden för att förfalska rörelsedata.
• Sätta en residentiell proxy framför VM:en för att städa upp nätverkssignalen.

Vilken som helst av dessa besegrar en detektor som förlitar sig på just den signalen. Ett system som bara kontrollerar WebGL-renderarsträngen slås av en strängredigering. Ett system som bara kontrollerar build fingerprints slås av en patch.

Det som är svårt är att göra allt koherent på en gång. Operatören som förfalskar WebGL-strängen för att påstå en Adreno-GPU producerar fortfarande canvas-renderingsutdata som inte matchar en riktig Adreno. Den som förfalskar modellnamnet rapporterar fortfarande en x86-ABI, eller ett antal kärnor ingen sådan telefon har, eller sensordata utan realistisk korrelation mellan sensorer, eller timing som är för ren för den SoC de påstår sig ha. Varje förfalskning de lägger till är ännu en yta som måste förbli konsekvent med alla de andra, och begränsningarna multipliceras.

Detta är principen om miljökoherens: detektionen är inte "ser det här ena värdet virtualiserat ut", utan "beskriver alla dessa värden en enda, verklig, fysiskt möjlig enhet". En påstådd iPhone vars GPU renderar som mjukvara, vars sensorer läser av konstant, vars ABI är x86 och vars timing är datacenter-jämn är inte inkoherent på ett sätt — den är inkoherent på fyra, och att förena alla fyra samtidigt är den dyra delen. Kostnaden för att upprätthålla full koherens över varje signal är det som får koherensbaserad detektion att hålla där enskilda signalkontroller misslyckas. Den bredare kapprustningen och var den står beskrivs i läget för bottrafik.

Hur man agerar på virtualiseringsdetektion

Blockera inte virtualisering reflexmässigt — väg in den som en risksignal i sitt sammanhang, eftersom legitim virtualisering finns och en generell blockering orsakar falska positiva. Det rätta svaret beror på vad som annars är sant om trafiken.

Det finns verkliga, legitima skäl till att en användare kan befinna sig i en VM eller emulator: utvecklare som testar på emulatorer, säkerhetsforskare, integritetsmedvetna användare som kör webbläsare i VM:ar, företags virtuella skrivbordsinfrastruktur, tillgänglighetsuppsättningar. Att blockera all virtualisering rakt av bestraffar dessa användare. Virtualisering är en risksignal, inte en dom.

Det produktiva angreppssättet behandlar den som en av flera indata i ett graderat beslut:

• Virtualisering ensam, i övrigt normal kontext: låg till måttlig risk. En enda utvecklare på en emulator är inte bedrägeri. Notera det, blockera det inte.
• Virtualisering + datacenter-nätverk + nyskapat konto + hög hastighet: hög risk. Detta är device farm-signaturen — en emulerad enhet, på hostinginfrastruktur, som skapar konton snabbt. Signalerna bekräftar varandra till en säker dom.
• Virtualisering + koherensbrott (förfalskade strängar som inte matchar renderingen, omöjliga hårdvarukombinationer): hög risk. Virtualiseringen plus aktiva försök att dölja den är i sig den starkaste signalen — legitima VM-användare patchar inte sina build fingerprints för att utge sig för flaggskeppstelefoner.
• Flottkorrelation: när många "distinkta" enheter delar den avslöjande virtualiseringssignaturen och beter sig koordinerat, kollapsar flottdetektionen dem till deras verkliga ursprung, vilket är avgörande oavsett hur något enskilt konto ser ut.

Mönstret är förenligt med detektion av headless browsers och bot detection generellt: den enskilda signalen informerar poängen, kombinationen av signaler producerar domen, och svaret är graderat — tillåt, utmana eller blockera — snarare än en trubbig blockering av virtualisering som sådan. Emulator- och VM-detektion är som mest värdefull inte som en fristående spärr utan som en tungt viktad signal som, kombinerad med nätverks- och beteendekontext, blottlägger infrastrukturen bakom storskaligt bedrägeri.

Tracio upptäcker virtualisering som en del av sin device intelligence över 130+ signaler — GPU- och renderingssignaturer, timing- och hårdvarukoherenskontroller, analys av mobila sensorer och build-identitet — kombinerat med nätverkskontext från IP intelligence och koherenskontroller mellan signaler som fångar de förfalskningsförsök enskilda signaldetektorer missar. Den körs genom bot detection-lagret och returnerar en dom, med de underliggande signalerna bifogade, på under 50 ms.

Vill du se hur virtualiseringsdetektion presterar mot device farm- och emulatortrafiken i din egen funnel?

Starta din kostnadsfria provperiod — 2 500 verifieringar gratis, inget kreditkort krävs. Boka en demo för att gå igenom emulator- och VM-detektion mot din specifika hotmodell.