- 1 VMware's 'Friendship Strategy' Making Strides as It Launches vSphere 6.5
- 2 Kubernetes 1.4 Aims to Address Complexity Concerns
- 3 Microsoft Bringing Security via Virtualization to Web Browsing
- 4 ZeroStack Serving Up Killer Enterprise Features for OpenStack Customers
- 5 ClusterGX Brings Container Management to Big Data Apps
Malware Evolves with Virtual Machines in Mind
Are virtual machines less susceptible to malware than physical machines?
It turns out that the answer is probably yes, but the security benefit of using a virtual machine is diminishing.
The reason VMs are less susceptible comes down to the fact that anti-malware vendors like Symantec often use virtualization technology and VMs to test unknown code to check whether it is malicious or not. They do that because, using server virtualization, test VMs are easy to spin up and it doesn't matter if they get infected with malware because they can be torn down and a new one spun up in moments from a known good template.
Malware writers are smart, though — or some of them are anyway — so it's no surprise that they sometimes include virtual machine detection into their code, or the packaging that their code is delivered in.
According to Symantec, some of the tricks they use to detect a VM include:
- Checking certain registry keys that are unique to virtual systems
- Checking if helper tools like VMware tools are installed
- Checking for certain process and service names
- Checking for communication ports and behavior
- Checking special assembler code and comparing the results
- Checking the location of system structures, like the descriptor tables
If the malware detects it is in a VM, it can then do nothing malicious and promptly quits. That way it won't be detected by anti-malware vendors' systems, so it can stay off their radar yet still run amok on physical systems.
The side effect here is that this type of malware won't infect production VMs running in enterprise data centers, private clouds or public clouds.
Smarter Strains of Malware Emerge to Target VMs
But Symantec reports it has now encountered malware that is a bit smarter. Anti-malware vendors' VMs watch potentially malicious code for a short period before concluding that it is malicious or not. So this new smart malware typically waits, doing nothing for a short period, before getting up to no good.
Why? Because if the VM hasn't been torn down in that time then it is probably a production machine, not an anti-malware vendor's machine.
Alternatively, the new type of malware may wait for a couple of system reboots, as AV vendors' VMs are rarely rebooted from a previous state rather than being spun up in a fresh state like production machines are. After that the malware can start executing its malicious payload.
The reason why malware authors would incorporate this behavior into their wares is fairly straightforward: they want their code to infect as many machines as possible.
Therefore, restricting it to run on physical machines unnecessarily makes no sense if it can be avoided. They may also want to make the infection jump from the infected VM to other VMs on the same host, and to the server virtualization host as well.
By implementing this behavior they can target all machines — virtual or physical — without increasing the risk of being detected by AV vendors' machines significantly.
Symantec's research shows that about one in five malware samples will abort if running on a VM, while the rest will happily do their best to try to infect the VM.
The company sells anti-malware protection so it obviously has an interest in spreading this information, but nonetheless it still makes sense to heed Symantec's advice to make sure that VMs are properly protected against malware to minimize the risk from this threat.
Paul Rubens is a technology journalist and contributor to ServerWatch, EnterpriseNetworkingPlanet and EnterpriseMobileToday. He has also covered technology for international newspapers and magazines including The Economist and The Financial Times since 1991.
Read more on "Server Virtualization Spotlight" »