TIMER false positive on bare-metal Windows Hyper-V root partition

[layer07]

Source info

• This is from the latest commit in the main branch
• This is from the latest release
• Other

Issue type

• False positive
• Compilation warning/error
• Suggestion
• Runtime error/crash
• Other

Environment

• Windows
• Linux
• MacOS
• Other

Description

TIMER false positive on bare-metal Windows Hyper-V root partition

Hi,

I’m seeing VM::TIMER false-positive on a bare-metal Windows 11 host with the Windows hypervisor active.

Environment:

VMAware: 2.7.0
OS: Windows 11 Enterprise 10.0.26200
HyperVisorPresent: True
Board: ASRock Z790 Taichi Carrara
BIOS: AMI 19.01

Default JSON result is correct:

{
  "is_detected": false,
  "brand": "Hyper-V root partition (host system, not an actual VM)",
  "conclusion": "Running on baremetal",
  "percentage": 0,
  "vm_type": "Host machine",
  "detected_techniques": []
}

But with --all, TIMER fires and the result becomes:

{
  "is_detected": true,
  "brand": "KVM",
  "conclusion": "Running inside a KVM VM",
  "percentage": 100,
  "vm_type": "Hypervisor (type 1)",
  "detected_techniques": ["TIMER"]
}

Disabling only TIMER returns the correct Hyper-V-root/bare-metal result.

I don’t think this timing signal is strong enough to be canonical on modern Windows hosts. VBS / Hyper-V root partition, scheduler behavior, interrupt load, power management, and firmware behavior can all skew this class of measurement without the machine being a guest.

So I think TIMER should probably not be enough by itself to assign a concrete VM brand like KVM, especially when the Hyper-V root-partition path already identified the system as host/root rather than a guest.

Also worth noting: a couple of verbose runs appeared to get stuck in the timer path until I killed the process. A timeout around the sampling/busy-wait loop might be useful.

I may try to put together a small PR for this if I can keep it narrow.

Thanks.

CLI output (if possible)

[NotRequiem]

Timer returned KVM because a bypass detection, not because timing overhead.

When a bypass is detected, even if you only had one single detection, it triggers VM confirmation

[layer07]

Hmm but, if TIMER says "KVM bypass" on bare-metal Windows, that is the false positive.
The bypass heuristic is being treated as too strong on HYPERV_ARTIFACT_VM.

Basically it is happening in all my 25h2 installs, weirdly enough. MS might have, enabled more stuff by default?

[NotRequiem]

It's so weird. It never false flagged, please tell me what CPU you have.

[layer07]

my 14900KS and wife's 14900KF who are on 25H2 are returning false positives. My E5-2696V4 that is on 24H2 came clean.
All bare metal, no trickery, nothing.

Since it is reproducible across my 25H2 installs with Hyper-V/VBS active (which seems to be the default??) so I’m wondering if newer Windows builds changed host/root scheduling or interrupt behavior enough to trip that bypass heuristic.

Edit: typos.

[NotRequiem]

Issue fixed in #706