New Anti-VM technique observed in the wild

[pingram]

Found an interesting article this am about how malware has been discovered that can detect a VM environment via CPU flags. Thought I'd share: https://www.mysonicwall.com/sonicalert/ ... le&id=1085

[michaln]

That should really be titled "How Intel's refusal to document their CPUs makes everyone suffer". I really wonder which virtual environment the researchers were working with.

It is well known that even though Intel claims many instructions leave certain flags in "undefined" state, actual Intel processors behave in anything but undefined manner and set or clear the flags 100% consistently. Back in the early 1990s Cyrix used that fact to allow their own CPUs to be detected: "Detection of a Cyrix CPU is accomplished by checking the state of the undefined flags following execution of the divide instruction that divides 5 by 2¸ (2 / 5). The undefined flags in a Cyrix processor remain unchanged following the divide operation. Other vendor's processors will modify some of the undefined flags." In this instance "other vendors" were Intel and AMD, because AMD 386/486 CPUs were indistinguishable from their Intel counterparts (before they had the CPUID instruction).

[mpack]

Nice article. The technical details are interesting to me, but I'm wondering why the subject is interesting to the authors! Surely lots of apps have the ability to detect that they're in a VM, and they've been doing so for years now. Why is it news that malware can also do what lots of other apps do?

[mpack]

Curiosity got the better of me, so I knocked up a little bit of code to display the flag changes on either side of an "imul ecx,ecx" instruction, where ecx==0.

On both my host and in a VirtualBox guest I saw that bit 2 of the flags changed (PF). Nothing else. ZF did not change. My code was very crude, but I think it's ok :-

Code: Select all   Expand viewCollapse view

/*...............................................*/

static UINT flags_before,flags_after;

static void
CheckForVM(void)
{
   flags_before = flags_after = 0;
   __asm {
      mov eax,0
      mov ecx,0
      lahf
      mov byte ptr flags_before,ah
      imul ecx,ecx // ZF should not be set.
      lahf
      mov byte ptr flags_after,ah
   }
}

/*...............................................*/

   ...
   CheckForVM();
   printf("Flags changing state: %lu",flags_before ^ flags_after);
   ...



p.s. I'm not saying the PF change was significant. Its the same for the VM and the host, I know it's accidental that whatever op was done last must have produced an odd parity result, and my code above doesn't explicitly set the flags on entry.

[michaln]

Except in rare cases, VirtualBox executes actual instructions on the host CPU, so the flags will behave the same, no matter how documented/undocumented.

[mpack]

Yeah, it'd have to be an instruction which many/most/all VM platforms would trap, and it's usefulness assumes that VM devs wouldn't bother to precisely simulate the behaviour of undefined flags from the host CPU. Can you think of a reason why any VM platform would trap "imul reg,reg"? Is the potential for arithmetic overflow something a VM would be concerned about? I don't see an obvious reason for expecting this trick to work.

[michaln]

No, I can't see why "imul eax, eax" would be trapped/emulated, unless everything is emulated.

[pingram]

What I took away from the article was not so much about any kind of vulnerability specific to using Virtual Machines or that Virtual Machines put anyone at greater risk, but mainly that malware is catching up to par with other legitimate software that now has been discovered to detect whether the environment is virtual or not and thus can employ evasion techniques against what would otherwise be used to investigate said malware's behavior and it's underlying code. Not to say there aren't prudent ways around this even to protect oneself, just that they seek to make the discovery and removal process that much more cumbersome if the malware can detect it is in an unsafe or not-optimal environment to execute in. We will likely need to become more creative with our sandboxing efforts.

[socratis]

mainly that malware is catching up to par with other legitimate software that now has been discovered to detect whether the environment is virtual or not

I can guarantee you that this behavior is not new. This started happening as soon as virtualization happened. Don't you think that the malware authors realized pretty soon that the virtual machines could be used to do analysis after analysis of their payload? They were the first ones that started using anti-virtualization techniques, followed by developers of software that was supposed to run only on a single system (see lottery, coupon printing, etc.).

[mpack]

Let's say that since around 2009 (Win7 release), apps that cared whether they run in a VM, already had reliable code to detect that they're running in a VM. VMware, QEMU, VirtualBox etc all existed by then. The Win7 license had a clause explicitly dealing with VMs and licensing. In fact Win7 Pro+ came with VM software built in (XP mode). VMs were not new.

Even early detection code was not easily evaded, and I expect it's pretty bulletproof by now.

So. This subject was already passé 7 years ago, hence my question as to why the article's authors found it significant.

[mpack]

What I took away from the article was not so much ... that Virtual Machines put anyone at greater risk

Quite the opposite I'd think. If malware refuses to run in a VM I'd expect that's pretty good news for VM users! Unfortunately I don't think it's that simple. I believe the standard response of malware with this VM detection feature would be to delay activity for long enough that a test lab will have given up, then it can resume normal work.

Anyway, the best defense against malware is not to get infected in the first place: i.e. don't click things when you don't know where they've been.