Virtualization may be needed for those users who work with various emulators and / or virtual machines. Both of them may well work without this option enabled, but if you need high performance while using the emulator, then you will have to enable it.

Important warning

Initially, it is advisable to make sure that your computer has support for virtualization. If it is not there, then you risk simply wasting your time trying to activate through the BIOS. Many popular emulators and virtual machines warn the user that his computer supports virtualization, and if you enable this option, the system will run much faster.

If you did not get such a message when you first started some emulator / virtual machine, then this may mean the following:

• Virtualization is already enabled by default (this is rare);
• The computer does not support this setting;
• The emulator is not able to analyze and notify the user about the possibility of connecting virtualization.

Enabling virtualization on an Intel processor

Using this step-by-step instruction, you can activate virtualization (relevant only for computers running on an Intel processor):

Enabling virtualization on an AMD processor

The step-by-step instruction looks like this in this case:

It is not difficult to enable virtualization on a computer, for this you just need to follow the step-by-step instructions. However, if the BIOS does not have the ability to enable this feature, then you should not try to do this using third-party programs, as this will not give any result, but it may worsen the computer's performance.

We are glad we were able to help you resolve the issue.

Poll: Did this article help you?

lumpics.ru

Virtual Secure Mode (VSM) in Windows 10 Enterprise

Windows 10 Enterprise (and this edition only) has a new Hyper-V feature called Virtual Secure Mode (VSM). VSM is a secure container (virtual machine) running on a hypervisor and separated from the host Windows 10 and its kernel. Security-critical system components run inside this secure virtual container. No third-party code can run inside VSM, and code integrity is constantly checked for modification. This architecture allows you to protect data in the VSM, even if the kernel of the host Windows 10 is compromised, because even the kernel does not have direct access to the VSM.

The VSM container cannot be connected to the network and no one can gain administrative privileges on it. Inside the Virtual Secure Mode container, encryption keys, user authorization data, and other information that is critical in terms of compromise can be stored. Thus, an attacker will no longer be able to penetrate the corporate infrastructure using locally cached domain user account data.

The following system components can run inside VSM:

• LSASS (Local Security Subsystem Service) is a component responsible for authorization and isolation of local users (thus the system is protected from “pass the hash” attacks and utilities like mimikatz). This means that passwords (and / or hashes) of users registered in the system cannot be obtained even by a user with local administrator rights.
• Virtual TPM (vTPM) is a synthetic TPM device for guest machines that is required to encrypt the contents of disks
• OS code integrity control system - protection of the system code from modification

To be able to use the VSM mode, the following hardware requirements are imposed on the environment:

• UEFI, Secure Boot and Trusted Platform Module (TPM) support for secure key storage
• Support for hardware virtualization (at least VT-x or AMD-V)

How to enable Virtual Secure Mode (VSM) in Windows 10

Let's look at how to enable Virtual Secure Mode in Windows 10 (in our example, this is Build 10130).

Checking the operation of VSM

You can make sure that the VSM mode is active by the presence of the Secure System process in the task manager.

Or by the event “Credential Guard (Lsalso.exe) was started and will protect LSA credential” in the system log.

VSM security testing

So, on machines with VSM enabled, we register under a domain account and run the following mimikatz command from under the local administrator:

mimikatz.exe privilege::debug sekurlsa::logonpasswords exit

We see that the LSA is running in an isolated environment and the user's password hashes cannot be retrieved.

If the same operation is performed on a machine with VSM disabled, we get an NTLM hash of the user's password, which can be used for "pass-the-hash" attacks.