4

Malware sometimes uses anti-vm and anti-sandbox behavior to act like harmless software.

Wouldn't it be a good prevention strategy to disguise the host machine as a VM so that potential malware would never break out?

I am not talking about "faking" virtualization which I think isn't possible, I'm talking about having a VM-typical MAC address, running an empty process in the background that doesn't do anything but has the name of a VM-typical process (like vboxtray.exe) or having empty driver dlls named like VM-drivers which would indicate to potential malware that the current system is a VM.

Fiddlesteaks
  • 41
  • 2
  • 4
    The ways in which malware detect a VM are many and complicated. Such an undertaking is not necessarily easy. Moreover (and perhaps most importantly), the methods malware uses are the methods which work *most often*. If OS builders decided to start taking steps to "pretend" to be a VM, malware authors would simply adjust their malware to look like different things. – Conor Mancone Feb 03 '20 at 18:35
  • Regarding the ways malware decets a VM, I stumbled upon a collection of methods in pafish and a lot of them seem to be moderarely easy to use for disguise. Regarding the latter, this is just the usual fight against malware and also would only affect new malware. Wouldn't this method of disguising still be a good way to prevent a considerable amount of malware outbreaks? – Fiddlesteaks Feb 03 '20 at 23:25
  • 2
    If you want to do that, then why not genuinely run an actual VM instead of only pretending? – ChrisW Feb 04 '20 at 00:07
  • 1
    @ChrisW for performance reasons – Fiddlesteaks Feb 04 '20 at 00:08

1 Answers1

4

Could emulating a virtual environment stop some malware from infecting the system?

Yes. Also, creating fake VM artifacts is not the only way to stop malware from executing. You could also create fake mutex objects or certain registry keys that malware oftentimes creates in order to avoid re-infecting the same machine. And there are a lot of other ways, depending on the malware's internal workings.

Would it be a good prevention strategy?

Not really. It would be a false sense of security. Assuming the malware even has any anti-VM measures in place at all and cares to halt execution if a VM is detected (which many don't), there are still thousands of ways malware can check if it's inside a VM or not, and every malware differs. There are hundreds of millions of malware programs out there, all of which work differently, and to spend your time on all of them would not only be a massive undertaking but would still likely prove to be an unreliable defense against malware.

So no, it would not be a good prevention strategy. Your time and effort would be better spent elsewhere, such as focusing your threat model around preventing actual execution of the malware at all by using good security practices, enforcing code signing, hardening your system, reducing attack vectors, keeping everything updated, not downloading anything suspicious, etc., and you should be ok, and have no need for this prevention strategy.

summer
  • 51
  • 3
  • I see your point but I kind of disagree. I was never talking about using this as the _only_ security practice and of course no one would get any sense of security by this. I would call it a "good prevention strategy", because it would only limit the execution of malware a tiny tiny bit but since it would be an even tinier bit of effort to put in, it would be worth it. In the last month I dealed with multiple pieces of software that uses VM- or sandbox-detection techniques. "Immunizing" the system with fake VM artefacts and objects that stop malware from reinfecting could be a good strategy. – Fiddlesteaks Jul 26 '20 at 21:48
  • The pieces of malware I dealed with usually used methods that are also used by [pafish](https://github.com/a0rtega/pafish) – Fiddlesteaks Jul 26 '20 at 21:49