Seatext library / BotRefund evidence
How BotRefund Detects Virtual Machines: The CPU Concurrency Lie Explained
BotRefund detects virtual machines by combining hardware fingerprinting, CPU concurrency analysis, and browser API inconsistencies. These signals are cross-checked against 106 independent checks to avoid false positives and achieve 99% accuracy.
✓ Built for advertisers who need clear, refund-ready traffic evidence.
BotRefund detects virtual machines (VMs) by looking for inconsistencies between what a browser claims about its environment and how it actually behaves. It uses three core techniques: hardware fingerprinting, CPU concurrency analysis, and browser API checks. Each check is one of 106 independent signals that BotRefund combines to decide whether a visit is human or automated.
The most specific VM clue is the CPU Concurrency Lie. A real browser reports CPU and hardware details that fit together. A VM or spoofed profile often claims one device while graphics, fonts, audio, or processor behavior tell a different story. BotRefund treats that mismatch as evidence, not proof, and validates it against other signals.
Virtual machines are common in bot networks because they let attackers run many fake browser sessions on one physical server. Without VM detection, these bots can click ads, fill forms, and poison analytics. BotRefund's VM checks are designed to catch that abuse early.
What Is the CPU Concurrency Lie?
The CPU Concurrency Lie check is one of the 106 independent checks BotRefund uses. It detects when a browser reports hardware characteristics that don't match its actual performance. For example, a VM might claim a high-end GPU but render graphics like a basic one. Or it might report four CPU cores while behaving like a single-threaded process.
Real browsers show consistent hardware reports. Automated browsers and VMs often fail this consistency test. That mismatch is the "lie" BotRefund looks for.
To understand how this works, imagine a normal laptop. It has a specific CPU, GPU, and memory. The browser reads those values and reports them consistently. A VM, however, often uses virtual devices. Those devices emulate hardware but leave traces. The CPU count might be virtual, the GPU driver might be generic, and the memory size might be fixed. When you compare what the browser reports with how the system actually performs, the differences become clear.
The concurrency lie specifically targets CPU core count and thread behavior. A VM configured with four virtual cores may still only use one physical core. That shows up in performance timing and in how many parallel tasks the browser can run. A real device with four cores behaves differently.
How Hardware and GPU Fingerprinting Helps Spot VMs
Hardware fingerprinting collects details about your device's GPU, CPU, fonts, and operating system. A real device has coherent data: the GPU vendor matches the driver, the CPU family matches the OS, and the fonts align with the platform.
VMs often rely on emulated or generic drivers. These produce inconsistent data. For instance, a VM might report a "Parallels" GPU or a common virtual NIC. BotRefund's hardware checks catch these inconsistencies as one of many signals.
GPU fingerprinting is particularly useful. WebGL exposes a renderer string that often names the actual graphics hardware. A VM using a virtual GPU may expose something like "VMware SVGA 3D" or "Microsoft Basic Render Driver." Those are strong hints. However, some VM setups spoof that string. That is why BotRefund does not rely on the string alone. It compares the renderer with the GPU performance. If the reported GPU is high-end but the frames per second are low, that is a red flag.
Fonts also matter. A real operating system has a specific set of fonts. VMs often have fewer fonts or a mismatched list. The browser can enumerate installed fonts. BotRefund checks whether the font list matches what the OS usually has.
Hardware fingerprinting is not just about that one signal. It feeds into the 106-check system and gains meaning only when combined with other evidence.
Browser API Inconsistencies: The Telltale Signs
Browsers expose APIs that reveal the underlying environment. These include navigator.hardwareConcurrency, navigator.deviceMemory, WebGL parameters, and performance timing. In a VM, these values often conflict. A VM might report 8 cores but have performance that matches 2. Or WebGL might report a low-end renderer while the system claims a high-end GPU.
BotRefund checks these API values for coherence. If they don't add up, it flags the session for deeper analysis.
Let's examine specific APIs:
navigator.hardwareConcurrencyreturns the number of logical processor cores. VMs often allow setting this value arbitrarily. A bot might set it to 16 to look powerful, but the actual execution speed reveals the truth.navigator.deviceMemoryreports approximate RAM in gigabytes. Some VMs assign a fixed memory size, but the browser's performance may suggest less. The browser's memory usage patterns can differ.performance.now()and other timing functions expose processing speed. High-resolution timers work differently in virtualized environments. Timing jitter can indicate a shared host.- WebGL parameters like
UNMASKED_RENDERER_WEBGLandUNMASKED_VENDOR_WEBGLreveal actual GPU strings. These often differ from what the system claims.
The key is that no single API is enough. A real user might have a browser extension that alters these values. But when several APIs disagree with each other, the probability of a VM rises.
Why One Signal Is Never Enough
A single anomaly doesn't make a visit a bot. Privacy tools, corporate networks, and unusual devices can cause false positives. For example, a user on a remote desktop or in a virtualized enterprise environment may legitimately have odd hardware reports.
That's why BotRefund treats each signal as evidence, not a verdict. It cross-checks the CPU concurrency data against browser behavior, network patterns, and device fingerprints. Only when the full picture supports the "VM" story does BotRefund raise the bot flag.
Consider a user who works from a corporate laptop that uses a virtual desktop. That user might have a GPU that is actually a virtual GPU, and their hardware concurrency might be set by IT. They also use a privacy-focused browser that blocks fingerprinting. That combination could trigger a false VM signal. But BotRefund also looks at mouse movement, click timing, scrolling, and session duration. If that user behaves like a human, the other 105 checks will override the VM suspicion.
This is why the accuracy is 99%. It comes from corroboration, not from one tell.
The 106-Check Cross-Validation Process
BotRefund uses 106 independent checks to build a reliable picture of each visit. The CPU Concurrency Lie is one of them. The process works like this:
- Run each check independently. Every check collects one objective fact about the visit.
- Cross-check the signals. BotRefund tests whether other signals support the same story. Does the hardware fingerprint match the network behavior? Does the CPU concurrency correlate with user input patterns?
- Weigh the complete pattern. BotRefund's prediction AI evaluates all 106 signals together, rather than trusting a single rule.
- Assign a bot or human score. Only when the full pattern points to automation does BotRefund classify the visit as a bot.
This approach minimizes false positives and improves accuracy to 99%.
Here is a practical example. A bot using a VM might pass the CPU concurrency check if it carefully spoofs the core count. But that same bot might fail on WebGL strings, font enumeration, and behavior checks like mouse movement. The combination of failures is what catches it. Conversely, a real user on a remote desktop might fail a few hardware checks but passes most behavioral checks. The AI weighs the evidence and makes the final call.
BotRefund continuously updates its checks. As VM technologies evolve, new signals are added. The 106 checks are not static; they adapt to new attack patterns.
Key Facts About BotRefund's VM Detection
| Fact | Value |
|---|---|
| Number of independent checks | 106 |
| CPU Concurrency Lie role | One of these checks, specifically for VM and spoofed profiles |
| Detection approach | Hardware fingerprinting, CPU concurrency analysis, browser API inconsistencies |
| Validation | Cross-checked against browser, network, device, and behavior data |
| Accuracy | 99% (when all signals corroborate) |
| False-positive guard | Single anomalies are not verdicts; cross-checks prevent mistakes |
How VM Detection Matters for Ad Fraud
Virtual machines are a common tool for ad fraud. Attackers set up VMs to run browser automation in bulk. Each VM can appear as a separate user with its own IP address, cookies, and browser fingerprint. Without VM detection, these bots can click on Google and Meta ads, filling ad budgets with fake traffic.
According to BotRefund's research, bot clicks can steal up to 20% of Google and Meta ad budgets. Many of those clicks come from VMs. By detecting VMs, BotRefund helps advertisers identify which clicks are invalid. That allows them to file refund claims and stop wasting money on fake traffic.
For example, a retail company might see a sudden spike in clicks from a specific region. A VM check reveals that many of those clicks come from the same virtual environment. The company can then suppress that traffic and request a refund from the ad platform.
Limitations and When This Detection Can Fail
No detection method is perfect. BotRefund's VM detection can fail in certain situations:
- Well-crafted VMs: Some automation frameworks specifically spoof hardware and browser APIs to match a real device. If all 106 signals align, the VM may slip through.
- Legitimate virtual environments: Enterprise users on virtual desktops or cloud VMs might generate false positives. BotRefund mitigates this by looking for corroborating signals, but it can't guarantee zero false positives.
- Privacy tools: Browser extensions that block or alter fingerprint data can create inconsistencies that look like a VM. These are usually resolved by cross-checking other behaviors.
Additionally, some VMs are configured to use a single CPU core and pass the concurrency check by lying about the count. However, such setups often fail other checks because the simulated hardware leaves traces. The cat-and-mouse game continues as VM technology improves.
If you suspect VM-based bot traffic, a free audit from BotRefund can tell you whether your site is affected.
Frequently Asked Questions about VM Detection
Can BotRefund detect all types of virtual machines?
BotRefund uses 106 checks to catch common VM setups. Advanced VMs that perfectly emulate hardware are harder, but the cross-checking makes this rare. No detector is 100% effective.
Will BotRefund flag users on corporate VPNs or remote desktops?
It can, but it uses multiple signals to reduce false positives. A user on a VPN who has normal mouse movement, scrolling, and session duration is less likely to be flagged than a bot with robotic behavior.
How does CPU concurrency analysis work specifically?
BotRefund compares reported CPU cores with actual performance. It also checks whether the concurrency values match other hardware and browser details. Inconsistencies are the "lie".
Is this the only way BotRefund detects bots?
No. The CPU Concurrency Lie is one of 106 checks. Others include click behavior, pointer movement, speed, and session patterns.
Does BotRefund use video evidence?
Yes, it can capture video proof of bot behavior, which helps with refund claims to Google and Meta.
How fast is the detection?
BotRefund runs checks in real time and can flag a bot during the session. The setup takes about one minute.
Take the Next Step
If you're concerned about VM-based bot traffic wasting your ad budget, start with a free bot audit. BotRefund will analyze your site and show you exactly which visits are automated.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Learn more
Visit the website for more information.