New Anti-VM technique observed in the wild

Here you can provide suggestions on how to improve the product, website, etc.

New Anti-VM technique observed in the wild

Postby pingram » 9. Oct 2017, 17:56

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
pingram
 
Posts: 4
Joined: 3. Oct 2017, 18:47

Re: New Anti-VM technique observed in the wild

Postby michaln » 10. Oct 2017, 09:19

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).
michaln
Oracle Corporation
 
Posts: 2841
Joined: 19. Dec 2007, 15:45
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Any and all

Re: New Anti-VM technique observed in the wild

Postby mpack » 10. Oct 2017, 10:29

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
Site Moderator
 
Posts: 25483
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: New Anti-VM technique observed in the wild

Postby mpack » 10. Oct 2017, 17:58

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.
mpack
Site Moderator
 
Posts: 25483
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: New Anti-VM technique observed in the wild

Postby michaln » 11. Oct 2017, 14:11

Except in rare cases, VirtualBox executes actual instructions on the host CPU, so the flags will behave the same, no matter how documented/undocumented.
michaln
Oracle Corporation
 
Posts: 2841
Joined: 19. Dec 2007, 15:45
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Any and all

Re: New Anti-VM technique observed in the wild

Postby mpack » 11. Oct 2017, 14:47

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.
mpack
Site Moderator
 
Posts: 25483
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: New Anti-VM technique observed in the wild

Postby michaln » 11. Oct 2017, 16:46

No, I can't see why "imul eax, eax" would be trapped/emulated, unless everything is emulated.
michaln
Oracle Corporation
 
Posts: 2841
Joined: 19. Dec 2007, 15:45
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Any and all

Re: New Anti-VM technique observed in the wild

Postby pingram » 11. Oct 2017, 19:48

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.
pingram
 
Posts: 4
Joined: 3. Oct 2017, 18:47

Re: New Anti-VM technique observed in the wild

Postby socratis » 11. Oct 2017, 20:04

pingram wrote: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.).
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
socratis
Site Moderator
 
Posts: 12679
Joined: 22. Oct 2010, 11:03
Location: Greece
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win(*>98), Linux*, OSX>10.5

Re: New Anti-VM technique observed in the wild

Postby mpack » 12. Oct 2017, 10:27

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
Site Moderator
 
Posts: 25483
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: New Anti-VM technique observed in the wild

Postby mpack » 12. Oct 2017, 10:35

pingram wrote: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.
mpack
Site Moderator
 
Posts: 25483
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP


Return to Suggestions

Who is online

Users browsing this forum: No registered users and 3 guests