Organizations must have a plan for dealing with compromised VMs. Without such a plan, it can be difficult to determine what you must do to ensure a VM's integrity and resume normal operations.
The way you deal with a security incident depends on the type of incident; you'd handle a ransomware attack differently than a situation where hackers have access to a VM through a backdoor. There are in-depth books and other resources about formulating an incident response plan, but every plan usually has a few important things in common.
First, figure out the severity of the incident. All security incidents are serious, but some are more consequential than others. A ransomware attack that completely disrupts your organization's ability to do business is far more serious than a similar attack against a minimally important system.
Second, determine which systems are compromised. If you have suffered a ransomware attack, then it will probably be relatively easy to figure out. In the case of a hack, however, only a comprehensive forensic analysis can tell you for sure which systems have been compromised.
Third, contact the right people. Your organization's security team needs to know about the incident, but depending on the scope of the damage, you might also need to alert key stakeholders within your organization. In some regions, there are laws requiring that government agencies be notified of breaches, especially if sensitive data was exposed.
If a VM is seriously compromised, then manually repairing it isn't a viable option for returning the VM to its previous state. You can never be 100% sure that you have repaired all the damage. There might still be malicious files or backdoors hidden on the machine.
There are three primary options for dealing with a VM that has been seriously compromised.
Restore a backup
In most cases, restoring a backup is the best option for recovering from a ransomware attack or other security incident where a VM has been compromised. This technique will only work if you have a recent backup. Any changes to the VM since the time of the most recent backup will be lost.
Reset the VM
Another option to return a VM to a healthy state is to reset it. There are two main techniques to reset a VM, and there are advantages and disadvantages to each.
The first method is to reset the OS. In Windows 10, you can do this by opening Settings and then going to Update & Security. Select the Recovery tab, where you will find the Reset This PC option, shown in Figure 1.
Resetting the VM this way causes Windows to be reinstalled. In most cases, files and applications are preserved, although there is an option to remove them. The advantages of using this technique are that it is minimally disruptive and brings the OS back to a known-good state. The disadvantage is that because this method seeks to preserve personal files, it can sometimes leave behind malicious files or backdoors.
The other method to reset a VM involves applying a known-good snapshot, which Microsoft refers to as a checkpoint. Applying a snapshot reverts the VM to a previous state in a manner that is somewhat similar to restoring a backup.
To apply a checkpoint on a Hyper-V VM, open the Hyper-V Manager, select the VM that must be reset, right-click on the checkpoint that you want to apply, and then select the Apply option from the shortcut menu. You can see what this looks like in Figure 2.
The primary advantage to using this method is that it is a quick and easy way of returning the system to a known-good state. The disadvantages are that you can only use this method if you had previously created a snapshot and that all changes to the VM since the time the snapshot was created will be lost.
Wipe the entire system
Another option for restoring the health of a compromised VM is to simply wipe the entire system and reinstall everything from scratch. The advantage of using this method is that performing a clean install ensures anything malicious is removed. But this method comes with potential losses of productivity while the VM is being reimaged as well as any data that might have resided on the VM.