How can a typical researcher protect against VM escapes?

Question

I read a similar question here on how large companies protect themselves and became intrigued about how this would transfer over to less significant operation (ie security researcher, small company, etc).

I recognize that malware analysis should not be done on machines with information of value, and that realistically, if consumer devices are being attacked, they'd have to have quite valuable information or an exploit would have been publicly released, at which point a patch probably would be as well. It appears the general consensus about VM escapes in "real life" and the is that they are too rare/difficult-to-exploit to be a threat.

So this becomes more of a theoretical question. Is there any way to guard against escapes without engineering a heavily hardened hypervisor? My first (and only, as of now) solution was VM within a VM (which is obviously going to come with the drawback of poor performance, alongside, according to this somewhat outdated serverfault thread, instability), so not ideal and I was wondering if there was a "better" way.

Answer 1

You don't really need to worry about the malware you want to analyze escaping the hypervisor. In fact, it's not uncommon for malware to actually refuse to run if it detects virtualization. Well-written malware will have anti-debugging and anti-reverse engineering features because the author wants to slow down any assault mounted against it. It would be foolish for the author to burn a potentially valuable 0day when the malware knows that it's likely being run by a malware analyst.

Another reason why this is a non-issue for you as a malware analyst is that the most sophisticated malware which could reasonably be expected to be capable of performing hypervisor escapes is going to be protected by execution guardrails. The malware will only download the second stage payload if it believes it is on its intended target, which is unlikely to be a virtual machine.

And no, nested virtual machines do not improve security. Quite the opposite, as nested VT-x requires additional features be enabled in both the CPU and the kernel, increasing attack surface area.