Virtualization Based Security (VBS)

Virtualization Based Security (VBS) is on the best Microsoft Windows security feature available in Windows 10 and Windows Server 2016. DeviceGuard, Credential Guard are two security options depend on Virtualization Based Security.

• DeviceGuard– It allows the system to block anything other than trusted applications.
• CedentialGuard- it allows the system to isolate the “exe”process in order to block memory read attempts from virus, spyware, trojan or worm attacks.

Now you will be thinking what is Iaas.exe , find a brief about this below

What is the use of Iaas.exe ?

LSASS is known as Local Security Authority Subsystem Service which is a process in Microsoft Windows operating systems that is responsible for enforcing the security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens. It also writes to the Windows Security Log.

What will happen if Iaas.exe is terminated?

Termination of lsass.exe will result in the Welcome screen losing its account/s, prompting a restart of the machine etc. This is happening because lsass.exe is a crucial system file and frequently this will faked by malware. The lsass.exe file used by Windows is located in the directory %WINDIR%\System32.

How Iaas.exe faking by Attackers?

Malicious developers may name the file with different systems display fonts and it trick users into installing or executing a malicious file instead of the trusted system file

Example – Isass.exe will displayed as “isaas”

Also, beware if any other location that has lsass.exe is most likely a virus, spyware, trojan or worm.

These new features used in hardware virtualization technologies such as Intel VT-X or AMD-V in order to offer strong segmentation between two virtual machines and probably more in the future. These technologies allow the Virtual Machine Manager (VMM) setting different rights on physical pages using Extended Page Tables (EPT). A virtual machine can set a physical page writable in its Page Table Entry (PTE), and the VMM can silently authorize or block this by setting the appropriate access right in its EPT.

Virtualization Based Security relies on the hypervisors, which will issue VMs of different Virtual Trust Levels (called VTL). Hyper-V consists in a hypervisor, and any operating system, even the “main” one, is contained in a VM. This “main” operating system, Windows, is considered as the root VM. Hyper-V trusts it and accepts management orders such as controlling other VMs. Other VMs may be “enlightened”, and if so, send restricted messages to Hyper-V for their own management.

Virtual Trust Levels (VTL)

Two VTLs defined here, with higher value is more privileged

• VTL0  –  This is the normal world, and basically consists in the standard Windows operating system
• VTL1  –  This is the secure world, and consists in a minimalized kernel and secured applications known as trustlets.

As I mentioned above CredentialGuard security feature leverages this technology in isolating the critical lsass.exe process in a VTL1 trustlet (lsaiso.exe, “Isolated LSA” in the above picture), making impossible to even the VTL0 kernel to access its memory. Only messages may be forwarded to the isolated process from the VTL0, effectively blocking memory passwords and hashes from virus, spyware, Trojan or worm attacks.

The DeviceGuard security features allows W^X memory mitigation (a physical page cannot be both executable and writable) in the VTL0 kernel address space, and accepts a policy which will contain authorized code signers. If the VTL0 kernel wants to make a physical page executable, it must ask the VTL1 for the change (“HVCI” in the picture), which will check the signature against its policy. For usermode code, this is not enforced yet, and the VTL0 kernel just asks for the signature verification. Policies are loaded during the boot startup, and cannot be modified after, which forces the user to reboot in order to load new policies.

Policies may also be signed: in that case, authorized signers are set in UEFI variables, and new policies will be checked against these signers. UEFI variables have their Setup and Boot flags set, which means they cannot be accessed nor modified after startup. In order to cleanup these variables, the local user must reboot using a custom Microsoft EFI bootloader, which will remove them after user interaction (by pressing a key).

Therefore, VBS heavily relies on SecureBoot the bootloader’s integrity must be checked, as it is responsible to load the policies, Hyper-V, the VTL1 etc

Now With vSphere 6.7 onwards VBS will be supported , Check  Virtualization Based Security (VBS) in vSphere 6.7

Thank you for reading this post  , Share the knowledge if you feel worth sharing it.

Follow VMarena on FaceBook , Twitter , Youtube