New Anti-VM technique observed in the wild
New Anti-VM technique observed in the wild
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
-
- Oracle Corporation
- Posts: 2973
- Joined: 19. Dec 2007, 15:45
- Primary OS: MS Windows 7
- VBox Version: PUEL
- Guest OSses: Any and all
- Contact:
Re: New Anti-VM technique observed in the wild
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).
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).
-
- Site Moderator
- Posts: 39134
- 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
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?
-
- Site Moderator
- Posts: 39134
- 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
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 :-
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.
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
/*...............................................*/
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);
...
-
- Oracle Corporation
- Posts: 2973
- Joined: 19. Dec 2007, 15:45
- Primary OS: MS Windows 7
- VBox Version: PUEL
- Guest OSses: Any and all
- Contact:
Re: New Anti-VM technique observed in the wild
Except in rare cases, VirtualBox executes actual instructions on the host CPU, so the flags will behave the same, no matter how documented/undocumented.
-
- Site Moderator
- Posts: 39134
- 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
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.
-
- Oracle Corporation
- Posts: 2973
- Joined: 19. Dec 2007, 15:45
- Primary OS: MS Windows 7
- VBox Version: PUEL
- Guest OSses: Any and all
- Contact:
Re: New Anti-VM technique observed in the wild
No, I can't see why "imul eax, eax" would be trapped/emulated, unless everything is emulated.
Re: New Anti-VM technique observed in the wild
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.
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: New Anti-VM technique observed in the wild
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.).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
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
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.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Site Moderator
- Posts: 39134
- 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
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.
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.
-
- Site Moderator
- Posts: 39134
- 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
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.pingram wrote:What I took away from the article was not so much ... that Virtual Machines put anyone at greater risk
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.