การตรวจจับอีมูเลเตอร์และเวอร์ชวลแมชชีนในทราฟฟิกเว็บ

การฉ้อโกงส่วนใหญ่ที่ทำงานในระดับใหญ่ทำงานบนโครงสร้างพื้นฐานเสมือน เพราะทางเลือกอื่น — ห้องที่เต็มไปด้วยโทรศัพท์และแล็ปท็อปจริง — ไม่สามารถขยายขนาดและไม่สามารถซ่อนตัวได้ อีมูเลเตอร์หรือเวอร์ชวลแมชชีนทำให้ผู้ปฏิบัติการรายเดียวสร้างอุปกรณ์ที่ดูแตกต่างกันได้นับพันเครื่องตามต้องการ แต่ละเครื่องดูเหมือนเอนด์พอยต์ผู้บริโภคใหม่ๆ การตรวจจับการเวอร์ชวลไลซ์นั้นเป็นหนึ่งในสิ่งที่ให้ผลตอบแทนสูงที่สุดที่ชั้น device intelligence ทำได้ เพราะมันระบุโครงสร้างพื้นฐานของการละเมิดระดับใหญ่แทนที่จะไล่ตามการกระทำฉ้อโกงรายบุคคลทีละอย่าง

บทความนี้ครอบคลุมว่าอีมูเลเตอร์และ VM เผยตัวเองอย่างไรในทราฟฟิกเว็บและแอป: สัญญาณฮาร์ดแวร์ เวลา และความสอดคล้องที่สภาพแวดล้อมเสมือนพยายามจำลองแต่ทำได้ยาก เหตุใดจึงไม่มีสัญญาณเดียวที่เพียงพอ และจะดำเนินการกับการตรวจจับอย่างไรโดยไม่ทำลายการเวอร์ชวลไลซ์ที่ถูกต้อง ผู้อ่านคือวิศวกรและทีมป้องกันการฉ้อโกงที่กำลังสร้างหรือประเมินการตรวจจับบอท

เหตุใดอีมูเลเตอร์และ VM จึงสำคัญต่อการฉ้อโกง

อีมูเลเตอร์และเวอร์ชวลแมชชีนสำคัญเพราะเป็นฐานที่คุ้มค่าต้นทุนสำหรับการฉ้อโกงจำนวนมาก — มันเปลี่ยนเครื่องเดียวให้กลายเป็นกองอุปกรณ์ที่ดูสะอาด ซึ่งเป็นสิ่งที่เศรษฐศาสตร์ของการฉ้อโกงส่วนใหญ่ต้องการพอดี

ปัญหาที่เกิดขึ้นซ้ำๆ ในการฉ้อโกงคือสเกล บัญชีปลอมเพียงบัญชีเดียวหรือธุรกรรมฉ้อโกงเพียงรายการเดียวแทบไม่คุ้มค่า เงินอยู่ที่การทำมันนับพันครั้ง การทำมันนับพันครั้งต้องใช้ตัวตนอุปกรณ์นับพัน เพราะแพลตฟอร์มต่างๆ เชื่อมโยงการละเมิดผ่านอุปกรณ์มากขึ้นเรื่อยๆ (ดู device fingerprinting ทำงานอย่างไร) ฮาร์ดแวร์จริงเป็นวิธีที่ซื่อสัตย์ในการได้ตัวตนอุปกรณ์จำนวนมาก แต่มันแพงและช้าจนเกินรับได้ การเวอร์ชวลไลซ์คือวิธีที่ถูก

พูดให้ชัด การเวอร์ชวลไลซ์เป็นรากฐานของ:

Device farm ชั้นวางของอุปกรณ์มือถือที่ถูกจำลองหรืออินสแตนซ์เบราว์เซอร์ headless ถูกจัดวางเพื่อสร้างบัญชี เคลมโปรโมชัน โพสต์รีวิวปลอม หรือรัน credential-stuffing และการละเมิดการสร้างบัญชีในปริมาณมาก แต่ละอินสแตนซ์ที่จำลองปรากฏเป็นโทรศัพท์หรือแล็ปท็อปแยกกัน

การจำลองแอปมือถือ การรันแอป Android หรือ iOS ในอีมูเลเตอร์บนฮาร์ดแวร์เดสก์ท็อปหรือเซิร์ฟเวอร์เพื่อทำงานอัตโนมัติในโฟลว์ที่อิงแอปซึ่งควรต้องใช้โทรศัพท์จริง — การสมัครผ่านมือถือ โปรโมชันที่ล็อกด้วยแอป การฉ้อโกงในแอป

Cloud browser และ browser-as-a-service เบราว์เซอร์เต็มรูปแบบที่รันในคลาวด์ VM ถูกทำให้เป็นอัตโนมัติเพื่อ scraping, ad fraud และการละเมิดบัญชี สิ่งเหล่านี้ซับซ้อนกว่าบอทหยาบๆ เพราะมันเรนเดอร์หน้าเว็บอย่างสมบูรณ์และรัน JavaScript

จุดร่วมคือ: เครื่องกายภาพเครื่องเดียว ตัวตนเสมือนจำนวนมาก ถ้าคุณตรวจจับการเวอร์ชวลไลซ์ได้ คุณก็ยุบกองนั้นกลับสู่ขนาดจริง — และ "ผู้ใช้พันคน" ที่จริงแล้วเป็นโฮสต์ที่จำลองเครื่องเดียวคือการตัดสินใจด้านความเสี่ยงที่ต่างจากอุปกรณ์จริงพันเครื่องอย่างมาก นี่คือเหตุผลที่การตรวจจับการเวอร์ชวลไลซ์เป็นตัวคูณพลัง: มันโจมตีโครงสร้างต้นทุนที่ทำให้การฉ้อโกงจำนวนมากทำได้จริง

อะไรที่เผยตัวเวอร์ชวลแมชชีน

เวอร์ชวลแมชชีนเผยตัวเองผ่านสัญญาณเชิงกายภาพที่มันต้องสังเคราะห์ขึ้นแทนที่จะมีอยู่จริง — GPU พฤติกรรมด้านเวลา เซนเซอร์ และร่องรอยระดับต่ำของ hypervisor ที่มันรันอยู่ ฮาร์ดแวร์ผู้บริโภคจริงสร้างสัญญาณเหล่านี้เป็นผลพลอยได้จากการเป็นของจริง VM ต้องปลอมมันขึ้นมา และการปลอมทุกอย่างให้สอดคล้องกันนั้นยาก

ลายเซ็น GPU ที่ถูกเวอร์ชวลไลซ์ นี่คือหนึ่งในร่องรอยที่ชัดที่สุด การเรนเดอร์กราฟิกขึ้นอยู่กับ GPU จริง ไดรเวอร์ของมัน และพฤติกรรม floating-point VM มักใช้กราฟิกที่ถูกเวอร์ชวลไลซ์หรือเรนเดอร์ด้วยซอฟต์แวร์ — SwiftShader, llvmpipe, GPU เสมือนของ VMware/VirtualBox/QEMU หรือ GPU ที่ผ่าน pass-through แต่ยังรายงานสตริงที่บ่งบอก สตริง WebGL renderer และ vendor มักระบุการเวอร์ชวลไลซ์โดยตรง ("SwiftShader", "llvmpipe", "VMware SVGA", "Google SwiftShader") และแม้เมื่อสตริงเหล่านั้นถูกปลอม เอาต์พุตการเรนเดอร์ canvas และ WebGL เองก็ต่างจาก GPU จริงในแบบที่ละเอียดอ่อนและปลอมได้ยาก GPU จริงเรนเดอร์ฉากที่ซับซ้อนด้วยร่องรอยเฉพาะไดรเวอร์ที่เป็นเอกลักษณ์ การเรนเดอร์ด้วยซอฟต์แวร์สร้างลายเซ็นที่ต่างออกไป

เวลาที่สะอาดเกินไป ฮาร์ดแวร์จริงมีสัญญาณรบกวน การคอมไพล์ JIT, garbage collection, thermal throttling, OS interrupt และผลกระทบของลำดับชั้นหน่วยความจำล้วนสร้าง jitter อย่างต่อเนื่องในการวัดเวลา สภาพแวดล้อมเสมือน — โดยเฉพาะที่โฮสต์บนคลาวด์บนโครงสร้างพื้นฐานคุณภาพสูง — มักเรียบเนียนเกินไป โดยมีความแปรปรวนด้านเวลาต่ำกว่าที่อุปกรณ์ผู้บริโภคจริงแสดง การวัดเวลาความละเอียดสูงของรูปแบบการคำนวณเฉพาะสามารถเผยสภาพแวดล้อมที่มีโปรไฟล์ประสิทธิภาพสม่ำเสมออย่างผิดธรรมชาติ ที่น่าขันคือ "ความสะอาด" ของ VM ในดาต้าเซ็นเตอร์เองก็คือสัญญาณ

ร่องรอยของ hypervisor การเวอร์ชวลไลซ์ทิ้งร่องรอยระดับต่ำไว้: CPU feature flag และความแปลกของ instruction-timing ที่ต่างออกไปภายใต้ hypervisor พฤติกรรม TSC (timestamp counter) เฉพาะ และ — ที่สังเกตได้ — ค่า hardware-concurrency และหน่วยความจำที่กระจุกตัวรอบการกำหนดค่าแบบ VM มากกว่าแบบผู้บริโภค อุปกรณ์ที่รายงานจำนวนคอร์และโปรไฟล์หน่วยความจำแบบเซิร์ฟเวอร์มากในขณะที่อ้างว่าเป็นแล็ปท็อปผู้บริโภคนั้นไม่สอดคล้องกัน

Audio และ fingerprint ฮาร์ดแวร์อื่นๆ AudioContext fingerprint ขึ้นอยู่กับระบบเสียง ฮาร์ดแวร์เสียงที่ถูกเวอร์ชวลไลซ์หรือขาดหายสร้างเอาต์พุต floating-point ที่ต่างจากฮาร์ดแวร์เสียงจริง เล็กน้อยเมื่ออยู่ลำพัง แต่มีประโยชน์เมื่อรวมกัน

บริบทเครือข่าย กอง VM และอีมูเลเตอร์มักรันในดาต้าเซ็นเตอร์ ดังนั้นชั้นเครือข่าย — ASN ของดาต้าเซ็นเตอร์, IP ของผู้ให้บริการโฮสติ้ง — จึงยืนยันสัญญาณของเอนด์พอยต์ ลายเซ็น VM และ IP ดาต้าเซ็นเตอร์เป็นรูปแบบที่แข็งแกร่งกว่าอย่างใดอย่างหนึ่งเพียงลำพังมาก (ผู้ปฏิบัติการที่ซับซ้อนวาง residential proxy ไว้หน้า VM เพื่อซ่อนด้านเครือข่าย ซึ่งนี่คือเหตุผลที่การตรวจจับ VM ในระดับเอนด์พอยต์สำคัญโดยอิสระ — มันรอดจาก proxy)

อีมูเลเตอร์มือถือเผยตัวเองอย่างไร

อีมูเลเตอร์มือถือเผยตัวเองผ่านหลักการเดียวกันที่นำมาใช้กับโทรศัพท์: มันต้องสังเคราะห์ลักษณะฮาร์ดแวร์ เซนเซอร์ และการเรนเดอร์เฉพาะของอุปกรณ์จริง และการสังเคราะห์นั้นไม่สมบูรณ์ แอป Android หรือ iOS ที่รันในอีมูเลเตอร์บนฮาร์ดแวร์เดสก์ท็อปไม่ใช่โทรศัพท์ และสัญญาณนับสิบก็บอกเช่นนั้น

สตริงตัวตนฮาร์ดแวร์ อีมูเลเตอร์มีค่า device-model, build-fingerprint และ hardware-name ที่เป็นเอกลักษณ์ อีมูเลเตอร์ Android รายงานตัวระบุ build อย่าง "generic", "goldfish", "ranchu", "sdk*gphone" และคล้ายกันมาตั้งแต่อดีต พร้อมด้วยชื่อรุ่นแบบอีมูเลเตอร์ทั่วไป แม้เมื่อสิ่งเหล่านี้ถูกแพตช์ให้เลียนแบบอุปกรณ์จริง *การรวมกัน_ของรุ่น บอร์ด CPU ABI และ build fingerprint มักไม่ตรงกับอุปกรณ์จริงเครื่องใดที่วางจำหน่าย — โทรศัพท์เรือธงที่อ้างว่าเป็นแต่มี x86 ABI (โทรศัพท์จริงเป็น ARM) คือหลักฐานที่ชัดเจน

เซนเซอร์ที่ขาดหายหรือปลอม โทรศัพท์จริงมี accelerometer, gyroscope, magnetometer, เซนเซอร์แสงแวดล้อม และ barometer และ — ที่สำคัญ — เซนเซอร์เหล่านั้นสร้างข้อมูลต่อเนื่อง สัมพันธ์กัน และมีสัญญาณรบกวนเมื่ออุปกรณ์ถูกถือและเคลื่อนไหว อีมูเลเตอร์อาจไม่มีเซนเซอร์เหล่านี้ รายงานค่าคงที่ หรือเล่นซ้ำรูปแบบสังเคราะห์ที่ไม่มีความแปรปรวนตามธรรมชาติและความสัมพันธ์ข้ามเซนเซอร์ของอุปกรณ์ที่ถูกถือโดยมือมนุษย์ "โทรศัพท์" ที่ accelerometer อ่านค่าคงที่สมบูรณ์ หรือที่ gyroscope และ accelerometer ไม่เคลื่อนไปด้วยกันตามที่ฟิสิกส์กำหนด คืออุปกรณ์ที่ถูกจำลอง

ความแตกต่างของการเรนเดอร์และ GPU เช่นเดียวกับบนเดสก์ท็อป ลายเซ็นการเรนเดอร์ GPU มือถือต่างกันระหว่าง GPU มือถือของโทรศัพท์จริง (Adreno, Mali, Apple GPU) กับตัวที่ถูกจำลองหรือเรนเดอร์ด้วยซอฟต์แวร์ ความหนาแน่นหน้าจอ ความละเอียด และร่องรอยการเรนเดอร์ที่ควรตรงกับรุ่นโทรศัพท์ที่อ้างถึงมักไม่ตรง

โปรไฟล์เวลาและประสิทธิภาพ แอปโทรศัพท์ที่รันบนฮาร์ดแวร์ระดับเซิร์ฟเวอร์ในอีมูเลเตอร์ทำงานต่างจากแอปเดียวกันบน SoC ของโทรศัพท์จริง — มักเร็วและเรียบเนียนกว่าที่อุปกรณ์จริงจะเป็น อีกตัวอย่างหนึ่งของร่องรอย "สะอาดเกินไป"

กรณีมือถือคือจุดที่ข้อมูลเซนเซอร์กลายเป็นตัวชี้ขาด เพราะมันปลอมให้ดีได้ยากจริงๆ การจำลองเอาต์พุตที่ต่อเนื่องและสอดคล้องเชิงกายภาพของเซนเซอร์การเคลื่อนไหวของโทรศัพท์จริง — accelerometer และ gyroscope ที่เห็นตรงกันเกี่ยวกับการเคลื่อนไหวเดียวกัน พร้อม micro-jitter ของมือมนุษย์ที่สมจริง — เป็นงานที่หนักกว่าการแก้สตริงชื่อรุ่นมาก และการตั้งค่าจำลองส่วนใหญ่ก็ทำได้ไม่น่าเชื่อถือ

เหตุใดจึงไม่มีสัญญาณเดียวที่เพียงพอ

ไม่มีสัญญาณเดียวที่ตรวจจับการเวอร์ชวลไลซ์ได้อย่างน่าเชื่อถือ เพราะสัญญาณใดสัญญาณหนึ่งก็ปลอมได้โดยผู้ปฏิบัติการที่รู้เรื่องมัน — ซึ่งเป็นเหตุที่การตรวจจับที่แข็งแกร่งพึ่งพาความสอดคล้องข้ามสัญญาณมากกว่าการตรวจสอบรายการเดียว นี่คือหลักการเดียวกับที่ควบคุมการตรวจจับ anti-detect browser: ร่องรอยรายบุคคลแพตช์ได้ แต่ความสอดคล้องข้ามทั้งหมดนั้นไม่ได้

ผู้ปฏิบัติการที่มุ่งมั่นจะ:

• ปลอมสตริง WebGL vendor/renderer เพื่อระบุ GPU จริง
• แพตช์ Android build fingerprint และรุ่นให้ตรงกับโทรศัพท์จริง
• ฉีดค่าเซนเซอร์สังเคราะห์เพื่อปลอมข้อมูลการเคลื่อนไหว
• วาง residential proxy ไว้หน้า VM เพื่อทำความสะอาดสัญญาณเครือข่าย

สิ่งเหล่านี้แต่ละอย่างเอาชนะตัวตรวจจับที่พึ่งพาสัญญาณเดียวนั้นได้ ระบบที่ตรวจแค่สตริง WebGL renderer ถูกเอาชนะด้วยการแก้สตริง ระบบที่ตรวจแค่ build fingerprint ถูกเอาชนะด้วยการแพตช์

สิ่งที่ยากคือการทำทั้งหมดอย่างสอดคล้องกันพร้อมกัน ผู้ปฏิบัติการที่ปลอมสตริง WebGL เพื่ออ้างว่าเป็น GPU Adreno ก็ยังสร้างเอาต์พุตการเรนเดอร์ canvas ที่ไม่ตรงกับ Adreno จริง คนที่ปลอมชื่อรุ่นก็ยังรายงาน x86 ABI หรือจำนวนคอร์ที่ไม่มีโทรศัพท์เครื่องใดมี หรือข้อมูลเซนเซอร์ที่ไม่มีความสัมพันธ์ข้ามเซนเซอร์ที่สมจริง หรือเวลาที่สะอาดเกินไปสำหรับ SoC ที่พวกเขาอ้าง การปลอมแต่ละอย่างที่เพิ่มเข้ามาคืออีกพื้นผิวหนึ่งที่ต้องคงความสอดคล้องกับอย่างอื่นทั้งหมด และข้อจำกัดก็ทวีคูณ

นี่คือหลักการความสอดคล้องเชิงสภาพแวดล้อม: การตรวจจับไม่ใช่ "ค่าเดียวนี้ดูเวอร์ชวลไลซ์ไหม" แต่คือ "ค่าทั้งหมดเหล่านี้อธิบายอุปกรณ์เดียว จริง และเป็นไปได้เชิงกายภาพหรือไม่" iPhone ที่อ้างว่าเป็นซึ่ง GPU เรนเดอร์เหมือนซอฟต์แวร์ เซนเซอร์อ่านค่าคงที่ ABI เป็น x86 และเวลาเรียบเนียนแบบดาต้าเซ็นเตอร์ ไม่ได้ไม่สอดคล้องในแบบเดียว — มันไม่สอดคล้องในสี่แบบ และการปรับทั้งสี่ให้ลงตัวพร้อมกันคือส่วนที่แพง ต้นทุนของการรักษาความสอดคล้องเต็มรูปแบบข้ามทุกสัญญาณคือสิ่งที่ทำให้การตรวจจับที่อิงความสอดคล้องยืนหยัดได้ในจุดที่การตรวจสอบสัญญาณเดียวล้มเหลว การแข่งขันด้านอาวุธที่กว้างกว่าและสถานะปัจจุบันครอบคลุมใน state of bot traffic

จะดำเนินการกับการตรวจจับการเวอร์ชวลไลซ์อย่างไร

อย่าบล็อกการเวอร์ชวลไลซ์โดยอัตโนมัติแบบสะท้อนกลับ — ให้ถ่วงน้ำหนักมันเป็นสัญญาณความเสี่ยงตามบริบท เพราะการเวอร์ชวลไลซ์ที่ถูกต้องมีอยู่จริง และการบล็อกแบบเหมารวมทำให้เกิด false positive การตอบสนองที่ถูกต้องขึ้นอยู่กับสิ่งอื่นที่เป็นจริงเกี่ยวกับทราฟฟิก

มีเหตุผลจริงและถูกต้องที่ผู้ใช้อาจอยู่ใน VM หรืออีมูเลเตอร์: นักพัฒนาที่ทดสอบบนอีมูเลเตอร์ นักวิจัยด้านความปลอดภัย ผู้ใช้ที่ใส่ใจความเป็นส่วนตัวที่รันเบราว์เซอร์ใน VM โครงสร้างพื้นฐาน virtual-desktop ขององค์กร การตั้งค่าเพื่อการเข้าถึง การบล็อกการเวอร์ชวลไลซ์ทั้งหมดโดยตรงลงโทษผู้ใช้เหล่านี้ การเวอร์ชวลไลซ์คือสัญญาณความเสี่ยง ไม่ใช่คำตัดสิน

แนวทางที่เกิดประโยชน์ปฏิบัติต่อมันเป็นหนึ่งอินพุตในการตัดสินใจแบบจัดระดับ:

• การเวอร์ชวลไลซ์เพียงลำพัง บริบทที่ปกติในด้านอื่น: ความเสี่ยงต่ำถึงปานกลาง นักพัฒนาคนเดียวบนอีมูเลเตอร์ไม่ใช่การฉ้อโกง บันทึกไว้ อย่าบล็อก
• การเวอร์ชวลไลซ์ + เครือข่ายดาต้าเซ็นเตอร์ + บัญชีใหม่ + ความเร็วสูง: ความเสี่ยงสูง นี่คือลายเซ็นของ device farm — เอนด์พอยต์ที่จำลอง บนโครงสร้างพื้นฐานโฮสติ้ง สร้างบัญชีอย่างรวดเร็ว สัญญาณต่างๆ ยืนยันซึ่งกันและกันจนกลายเป็นคำตัดสินที่มั่นใจ
• การเวอร์ชวลไลซ์ + การละเมิดความสอดคล้อง (สตริงที่ปลอมซึ่งไม่ตรงกับการเรนเดอร์ การผสมฮาร์ดแวร์ที่เป็นไปไม่ได้): ความเสี่ยงสูง การเวอร์ชวลไลซ์บวกกับความพยายามอย่างแข็งขันในการซ่อนมันเองก็คือสัญญาณที่แข็งแกร่งที่สุด — ผู้ใช้ VM ที่ถูกต้องไม่แพตช์ build fingerprint ของตนเพื่อปลอมเป็นโทรศัพท์เรือธง
• การเชื่อมโยงกอง (fleet correlation): เมื่ออุปกรณ์ "ที่แตกต่างกัน" จำนวนมากมีลายเซ็นการเวอร์ชวลไลซ์ที่บ่งบอกร่วมกันและมีพฤติกรรมที่ประสานกัน การตรวจจับกองจะยุบพวกมันกลับสู่ต้นกำเนิดจริง ซึ่งเป็นตัวชี้ขาดไม่ว่าบัญชีเดียวจะดูเป็นอย่างไร

รูปแบบนี้สอดคล้องกับการตรวจจับ headless browser และการตรวจจับบอทโดยทั่วไป: สัญญาณรายบุคคลให้ข้อมูลกับคะแนน การรวมกันของสัญญาณสร้างคำตัดสิน และการตอบสนองถูกจัดระดับ — อนุญาต ท้าทาย หรือบล็อก — แทนที่จะบล็อกการเวอร์ชวลไลซ์แบบทื่อๆ การตรวจจับอีมูเลเตอร์และ VM มีค่าที่สุดไม่ใช่ในฐานะประตูเดี่ยว แต่ในฐานะสัญญาณที่ถ่วงน้ำหนักมาก ซึ่งเมื่อรวมกับบริบทด้านเครือข่ายและพฤติกรรม จะเปิดโปงโครงสร้างพื้นฐานเบื้องหลังการฉ้อโกงจำนวนมาก

Tracio ตรวจจับการเวอร์ชวลไลซ์เป็นส่วนหนึ่งของ device intelligence ของมันจากสัญญาณกว่า 130+ — ลายเซ็น GPU และการเรนเดอร์ การตรวจสอบเวลาและความสอดคล้องของฮาร์ดแวร์ การวิเคราะห์เซนเซอร์มือถือและตัวตน build — รวมกับบริบทเครือข่าย IP intelligence และการตรวจสอบความสอดคล้องข้ามสัญญาณที่จับความพยายามปลอมที่ตัวตรวจจับสัญญาณเดียวพลาดไป มันทำงานผ่านชั้น bot detection และคืนคำตัดสินพร้อมสัญญาณเบื้องหลังที่แนบมาภายในเวลาไม่ถึง 50ms

อยากเห็นว่าการตรวจจับการเวอร์ชวลไลซ์ทำงานอย่างไรกับทราฟฟิก device farm และอีมูเลเตอร์ในฟันเนลของคุณเองหรือไม่

เริ่มทดลองใช้ฟรี — ตรวจสอบฟรี 2,500 ครั้ง ไม่ต้องใช้บัตรเครดิต จองเดโม เพื่อดูการตรวจจับอีมูเลเตอร์และ VM ตามแบบจำลองภัยคุกคามเฉพาะของคุณ