Wykrywanie emulatorów i maszyn wirtualnych w ruchu webowym

Większość fraudu działającego na skalę działa na zwirtualizowanej infrastrukturze, ponieważ alternatywa — pokój pełen fizycznych telefonów i laptopów — nie skaluje się i nie ukrywa. Emulator lub maszyna wirtualna pozwala jednemu operatorowi uruchomić na żądanie tysiące pozornie odrębnych urządzeń, z których każde wygląda jak świeży, konsumencki endpoint. Wykrywanie tej wirtualizacji jest jedną z najbardziej dźwigniowych rzeczy, jakie robi warstwa device intelligence, ponieważ identyfikuje infrastrukturę nadużyć na skalę, zamiast ścigać pojedyncze fraudowe akcje jedna po drugiej.

Ten artykuł opisuje, jak emulatory i VM zdradzają się w ruchu webowym i aplikacyjnym: sygnały sprzętu, timingu i spójności, które zwirtualizowane środowisko z trudem odtwarza, dlaczego żaden pojedynczy sygnał nie wystarcza oraz jak reagować na wykrycie, nie psując legalnej wirtualizacji. Odbiorcami są inżynierowie i zespoły ds. fraudu budujący lub oceniający bot detection.

Dlaczego emulatory i VM mają znaczenie dla fraudu

Emulatory i maszyny wirtualne mają znaczenie, ponieważ są kosztowo efektywnym podłożem dla fraudu wolumenowego — zamieniają jedną maszynę we flotę czysto wyglądających urządzeń, co jest dokładnie tym, czego wymaga ekonomika większości oszustw.

Powracającym problemem we fraudzie jest skala. Pojedyncze fałszywe konto lub pojedyncza fraudowa transakcja rzadko się opłacają; pieniądze są w robieniu tego tysiące razy. Robienie tego tysiące razy wymaga tysięcy tożsamości urządzeń, ponieważ platformy coraz częściej wiążą nadużycia z urządzeniem (zobacz jak działa device fingerprinting). Fizyczny sprzęt to uczciwy sposób na wiele tożsamości urządzeń — i jest zaporowo drogi oraz wolny. Wirtualizacja to sposób tani.

Konkretnie wirtualizacja stoi za:

Farmami urządzeń. Szafy emulowanych urządzeń mobilnych lub instancji headless browser, orkiestrowane po to, by masowo zakładać konta, zgarniać promocje, publikować fałszywe recenzje albo prowadzić credential stuffing i nadużycia przy zakładaniu kont na skalę. Każda emulowana instancja przedstawia się jako osobny telefon lub laptop.

Emulacją aplikacji mobilnych. Uruchamianie aplikacji Android lub iOS w emulatorach na sprzęcie desktopowym lub serwerowym, by zautomatyzować przepływy aplikacyjne, które miały wymagać prawdziwego telefonu — rejestracje mobilne, promocje dostępne tylko w aplikacji, fraud wewnątrz aplikacji.

Przeglądarkami w chmurze i browser-as-a-service. Pełne przeglądarki działające w VM w chmurze, zautomatyzowane pod scraping, ad fraud i nadużycia kont. Są bardziej wyrafinowane niż prymitywne boty, bo w pełni renderują strony i wykonują JavaScript.

Wspólny mianownik: jedna fizyczna maszyna, wiele wirtualnych tożsamości. Jeśli potrafisz wykryć wirtualizację, sprowadzasz flotę z powrotem do jej prawdziwego rozmiaru — a „tysiąc użytkowników”, którzy w rzeczywistości są jednym emulowanym hostem, to zupełnie inna decyzja o ryzyku niż tysiąc prawdziwych urządzeń. Dlatego wykrywanie wirtualizacji jest mnożnikiem siły: atakuje strukturę kosztów, która czyni fraud wolumenowy opłacalnym.

Co zdradza maszynę wirtualną

Maszyna wirtualna zdradza się przez sygnały fizyczne, które musi syntetyzować, a nie posiadać — GPU, zachowanie timingu, czujniki oraz niskopoziomowe artefakty hypervisora, na którym działa. Prawdziwy sprzęt konsumencki wytwarza te sygnały jako efekt uboczny bycia prawdziwym; VM musi je podrobić, a podrobienie ich wszystkich spójnie jest trudne.

Sygnatury zwirtualizowanego GPU. To jeden z najsilniejszych sygnałów. Renderowanie grafiki zależy od faktycznego GPU, jego sterownika i zachowania zmiennoprzecinkowego. VM zwykle używają zwirtualizowanej lub programowo renderowanej grafiki — SwiftShader, llvmpipe, wirtualne GPU VMware/VirtualBox/QEMU albo przekazanego GPU, który i tak zgłasza charakterystyczne ciągi. Renderer i ciągi vendora WebGL często wprost nazywają wirtualizację („SwiftShader”, „llvmpipe”, „VMware SVGA”, „Google SwiftShader”), a nawet gdy te ciągi są podrobione, sam wynik renderowania canvas i WebGL różni się od fizycznych GPU w subtelny, trudny do podrobienia sposób. Prawdziwe GPU renderuje złożoną scenę z charakterystycznymi dla sterownika artefaktami; renderowanie programowe daje inną sygnaturę.

Timing, który jest zbyt czysty. Prawdziwy sprzęt jest zaszumiony. Kompilacja JIT, garbage collection, throttling termiczny, przerwania systemu operacyjnego i efekty hierarchii pamięci wprowadzają ciągły jitter do pomiarów czasu. Zwirtualizowane środowiska — zwłaszcza hostowane w chmurze na wysokiej jakości infrastrukturze — często działają zbyt gładko, z niższą zmiennością timingu niż wykazują fizyczne urządzenia konsumenckie. Wysokorozdzielczy pomiar czasu określonych wzorców obliczeń może ujawnić środowisko, którego profil wydajności jest nienaturalnie jednorodny. Paradoksalnie „czystość” VM w centrum danych sama jest sygnałem.

Artefakty hypervisora. Wirtualizacja zostawia niskopoziomowe ślady: flagi funkcji CPU i osobliwości timingu instrukcji, które różnią się pod hypervisorem, specyficzne zachowanie TSC (timestamp counter) oraz — tam, gdzie da się to zaobserwować — wartości hardware-concurrency i pamięci skupiające się wokół konfiguracji typowych dla VM, a nie typowych dla konsumenta. Urządzenie zgłaszające bardzo serwerową liczbę rdzeni i profil pamięci, a jednocześnie twierdzące, że jest konsumenckim laptopem, jest niespójne.

Fingerprinty audio i innego sprzętu. Fingerprint AudioContext zależy od podsystemu audio; zwirtualizowany lub nieobecny sprzęt audio daje wynik zmiennoprzecinkowy inny niż prawdziwy sprzęt dźwiękowy. Mały sam w sobie, użyteczny w połączeniu.

Kontekst sieciowy. Floty emulatorów i VM często działają w centrach danych, więc warstwa sieciowa — ASN centrum danych, IP dostawcy hostingu — potwierdza sygnały z endpointu. Sygnatura VM oraz IP z centrum danych to znacznie silniejszy wzorzec niż każde z osobna. (Wyrafinowani operatorzy stawiają przed swoimi VM proxy rezydencjalne, by ukryć stronę sieciową, i właśnie dlatego wykrywanie VM na poziomie endpointu ma znaczenie niezależnie — przetrwa proxy.)

Jak zdradzają się emulatory mobilne

Emulatory mobilne zdradzają się przez tę samą zasadę zastosowaną do telefonów: muszą zsyntetyzować konkretne charakterystyki sprzętu, czujników i renderowania fizycznego urządzenia, a synteza jest niepełna. Aplikacja Android lub iOS działająca w emulatorze na sprzęcie desktopowym nie jest telefonem, i mówi o tym kilkanaście sygnałów.

Ciągi tożsamości sprzętu. Emulatory noszą charakterystyczne wartości device-model, build-fingerprint i hardware-name. Emulatory Androida historycznie zgłaszają „generic”, „goldfish”, „ranchu”, „sdkgphone” i podobne identyfikatory build, wraz z nazwami modeli typowymi dla emulatorów. Nawet gdy są one łatane, by naśladować prawdziwe urządzenie, _kombinacja modelu, płyty, CPU ABI i build fingerprint często nie pasuje do żadnego rzeczywistego urządzenia, które trafiło do sprzedaży — deklarowany flagowy telefon z ABI x86 (prawdziwe telefony są ARM) to zdrada.

Brakujące lub fałszywe czujniki. Prawdziwe telefony mają akcelerometry, żyroskopy, magnetometry, czujniki światła i barometry oraz — co kluczowe — te czujniki wytwarzają ciągłe, skorelowane, zaszumione dane, gdy urządzenie jest trzymane i poruszane. Emulatory albo nie mają tych czujników, albo zgłaszają statyczne wartości, albo odtwarzają syntetyczne wzorce pozbawione naturalnej zmienności i korelacji między czujnikami urządzenia trzymanego przez ludzką dłoń. „Telefon”, którego akcelerometr wskazuje idealną stałą albo którego żyroskop i akcelerometr nie poruszają się razem tak, jak wymaga fizyka, jest emulowany.

Różnice w renderowaniu i GPU. Tak jak na desktopie, sygnatura renderowania mobilnego GPU różni się między mobilnym GPU fizycznego telefonu (Adreno, Mali, Apple GPU) a emulowanym lub renderowanym programowo. Gęstość ekranu, rozdzielczość i artefakty renderowania, które powinny pasować do konkretnego deklarowanego modelu telefonu, często nie pasują.

Profil timingu i wydajności. Aplikacja telefoniczna działająca na sprzęcie klasy serwerowej w emulatorze zachowuje się inaczej niż ta sama aplikacja na faktycznym SoC telefonu — często szybciej i płynniej, niż zrobiłoby to prawdziwe urządzenie, co jest kolejnym przypadkiem sygnału „zbyt czysto”.

Przypadek mobilny to miejsce, gdzie dane z czujników stają się rozstrzygające, bo naprawdę trudno je dobrze podrobić. Odtworzenie ciągłego, fizycznie spójnego wyjścia czujników ruchu prawdziwego telefonu — akcelerometru i żyroskopu zgadzających się co do tego samego ruchu, z realistycznym mikro-jitterem ludzkiej dłoni — to znacznie więcej pracy niż edycja ciągu z nazwą modelu, a większość konfiguracji emulacji nie robi tego przekonująco.

Dlaczego żaden pojedynczy sygnał nie wystarcza

Żaden pojedynczy sygnał nie wykrywa wirtualizacji niezawodnie, ponieważ każdy z osobna może zostać podrobiony przez operatora, który o nim wie — dlatego solidne wykrywanie zależy od spójności między sygnałami, a nie od pojedynczej kontroli. To ta sama zasada, która rządzi wykrywaniem anti-detect browserów: pojedyncze sygnały da się łatać; spójności między wszystkimi — nie.

Zdeterminowany operator:

• Podrobi ciągi vendor/renderer WebGL, by nazwać prawdziwe GPU.
• Załata build fingerprint i model Androida, by pasowały do prawdziwego telefonu.
• Wstrzyknie syntetyczne wartości czujników, by sfałszować dane ruchu.
• Postawi przed VM proxy rezydencjalne, by wyczyścić sygnał sieciowy.

Każde z tych działań pokonuje detektor, który polega na tym jednym sygnale. System sprawdzający tylko ciąg renderera WebGL zostaje pobity przez edycję ciągu. System sprawdzający tylko build fingerprint zostaje pobity przez łatkę.

Trudne jest zrobienie wszystkiego tego spójnie naraz. Operator, który podrabia ciąg WebGL, by deklarować GPU Adreno, i tak wytwarza wynik renderowania canvas, który nie pasuje do prawdziwego Adreno. Ten, kto fałszuje nazwę modelu, i tak zgłasza ABI x86 albo liczbę rdzeni, jakiej żaden taki telefon nie ma, albo dane czujników bez realistycznej korelacji między czujnikami, albo timing zbyt czysty jak na deklarowany SoC. Każde dodane fałszerstwo to kolejna powierzchnia, która musi pozostać spójna ze wszystkimi pozostałymi, a ograniczenia się mnożą.

To zasada spójności środowiskowej: wykrywanie nie brzmi „czy ta jedna wartość wygląda na zwirtualizowaną”, lecz „czy wszystkie te wartości opisują pojedyncze, prawdziwe, fizycznie możliwe urządzenie”. Deklarowany iPhone, którego GPU renderuje jak oprogramowanie, którego czujniki wskazują stałą, którego ABI to x86 i którego timing jest gładki jak w centrum danych, nie jest niespójny na jeden sposób — jest niespójny na cztery, a jednoczesne pogodzenie wszystkich czterech to kosztowna część. Koszt utrzymania pełnej spójności we wszystkich sygnałach jest tym, co sprawia, że wykrywanie oparte na spójności utrzymuje się tam, gdzie kontrole jednego sygnału zawodzą. Szerszy wyścig zbrojeń i jego stan opisano w stanie ruchu botów.

Jak reagować na wykrycie wirtualizacji

Nie blokuj odruchowo wirtualizacji — waż ją jako sygnał ryzyka w kontekście, bo legalna wirtualizacja istnieje, a masowa blokada powoduje false positive. Właściwa reakcja zależy od tego, co jeszcze jest prawdą o ruchu.

Istnieją realne, legalne powody, dla których użytkownik może być w VM lub emulatorze: deweloperzy testujący na emulatorach, badacze bezpieczeństwa, użytkownicy dbający o prywatność uruchamiający przeglądarki w VM, korporacyjna infrastruktura wirtualnych pulpitów, konfiguracje dostępności. Blokowanie całej wirtualizacji wprost karze tych użytkowników. Wirtualizacja to sygnał ryzyka, a nie werdykt.

Produktywne podejście traktuje ją jako jedno wejście do stopniowanej decyzji:

• Sama wirtualizacja, poza tym normalny kontekst: ryzyko niskie do umiarkowanego. Pojedynczy deweloper na emulatorze to nie fraud. Odnotuj, nie blokuj.
• Wirtualizacja + sieć centrum danych + świeże konto + wysoka prędkość: wysokie ryzyko. To sygnatura farmy urządzeń — emulowany endpoint, na infrastrukturze hostingowej, szybko zakładający konta. Sygnały wzajemnie się potwierdzają, tworząc pewny werdykt.
• Wirtualizacja + naruszenia spójności (podrobione ciągi niepasujące do renderowania, niemożliwe kombinacje sprzętu): wysokie ryzyko. Wirtualizacja plus aktywne próby jej ukrycia to sam w sobie najsilniejszy sygnał — legalni użytkownicy VM nie łatają swoich build fingerprint, by podszyć się pod flagowe telefony.
• Korelacja floty: gdy wiele „odrębnych” urządzeń dzieli charakterystyczną sygnaturę wirtualizacji i zachowuje się w skoordynowany sposób, wykrywanie floty sprowadza je do prawdziwego źródła, co jest rozstrzygające niezależnie od wyglądu pojedynczego konta.

Wzorzec jest spójny z wykrywaniem headless browserów i bot detection w ogóle: pojedynczy sygnał informuje wynik, kombinacja sygnałów wytwarza werdykt, a reakcja jest stopniowana — dopuść, wyzwij lub zablokuj — zamiast tępej blokady wirtualizacji jako takiej. Wykrywanie emulatorów i VM jest najcenniejsze nie jako samodzielna bramka, lecz jako mocno ważony sygnał, który w połączeniu z kontekstem sieciowym i behawioralnym odsłania infrastrukturę stojącą za fraudem wolumenowym.

Tracio wykrywa wirtualizację w ramach swojego device intelligence w ponad 130 sygnałach — sygnatury GPU i renderowania, kontrole timingu i spójności sprzętu, analiza czujników mobilnych i tożsamości build — połączonych z kontekstem sieciowym IP intelligence i kontrolami spójności między sygnałami, które wychwytują próby podrabiania umykające detektorom jednego sygnału. Działa przez warstwę bot detection i zwraca werdykt, z dołączonymi sygnałami źródłowymi, w mniej niż 50 ms.

Chcesz zobaczyć, jak wykrywanie wirtualizacji radzi sobie z ruchem farm urządzeń i emulatorów w Twoim własnym lejku?

Rozpocznij darmowy trial — 2500 weryfikacji za darmo, bez karty kredytowej. Umów demo, by przejść przez wykrywanie emulatorów i VM na tle Twojego konkretnego modelu zagrożeń.