In Microsoft Windows, two vulnerabilities have been successfully exploited for attacks for years now – execution of arbitrary code and reading of access data from data storage. Microsoft’s counter-measures to date have not had the desired effect. Various whitelisting approaches have been tabled to prevent code from being executed. However, these can sometimes be circumvented, or deactivated if attackers manage to obtain administrative rights. An attacker who gains control over the operating system can manipulate existing control systems. This is the weak link in the chain. Reading of plain-text passwords can now be prevented by a restrictive configuration.

But it is still possible to read NTLM hashes, which can be used for pass-the-hash attacks. Here, too, an attacker with control over the system can manipulate a restrictive configuration. With the introduction of Windows 10, Microsoft presented the functions Credential Guard and Device Guard, which were intended to resolve these existing vulnerabilities. In this article, we will introduce these functions and evaluate their influence on the security of the operating system.

Virtual Secure Mode

The essential innovation of Credential Guard and Device Guard is the use of virtualization techniques, to isolate these functions from the operating system and thus better protect it against attackers and malware. Both are based on Virtual Secure Mode (VSM) technology. VSM is a protected container, which is operated in a Hyper-V hypervisor and thus isolated from the Windows 10 host and its kernel. Within this container, only explicitly permitted code can be executed and in addition testing for code integrity is constantly carried out. Microsoft refers to this technology as Virtualization-Based Security (VBS).

Like the operation of a normal virtual machine, VSM relies on hardware-based protective measures. The hypervisor uses the virtualization extension of the processor to protect access to data in storage and to ensure that each instance can access only its own data. The Windows kernel subsequently has no direct access to the VSM container. Currently, three functions can be executed in VSM:

1. Local Security Authority (LSA)
2. Code-integrity control in the form of kernel mode code integrity (KMCI)
3. The hypervisor has its own code-integrity control called hypervisor code integrity (HVCI)

Requirements and installation

In order to use Virtual Secure Mode, the hardware of the device must fulfill the following criteria:

• UEFI (native mode) and Secure Boot activated
• Support for Windows 64 Bit (Enterprise Version)
• Second Layer Address Translation (SLAT) and Virtualization extensions (Intel VT or AMD V)
• Trusted Platform Module (TPM) is advisable

The Windows feature Hyper-V hypervisor must then be installed; the Hyper-V components are not required. VSM itself is administered through Group Policy Turn on virtualization-based security under the path Computer Configuration\Administrative Templates\System\Device Guard.

For the options Virtualization-based protection of code integrity and Credential Guard configuration, the setting Enabled with UEFI lock can be selected. This measure prevents remote deactivation of these options. To deactivate them, the UEFI configuration must be reset locally on the device.

Following activation of Virtual Secure Mode, Credential Guard and Device Guard can be applied.

Credential Guard

The function Credential Guard secures against access to system and user passwords, so that domain access data can no longer be read if the system is compromised. To do this, any access data that has been stored in the Local Security Authority (LSA) process is evacuated to a virtualized and isolated LSA process. This isolated LSA process, named LsaIso, consists solely of a reduced set of operating system binary files that are required for actual operations. These binary files are all signed and each signature validated before execution. The access data for the operating system is no longer directly accessible; the LSA process calls it up via remote procedure calls. This is intended to ensure that unauthorized access to access data is not allowed. Currently, Credential Guard can be used to protect NTLM and Kerberos access data for domain accounts. Note that neither local accounts nor Microsoft accounts can be protected by Credential Guard.

The tool Mimikatz, introduced in the Article Windows Passwords – A well-known secret can read access data from the storage for the LSA process, among other things, and is therefore an ideal test candidate for Credential Guard. In a standard installation of Windows 10, it is possible to read a user’s NTLM hash:

When Credential Guard is activated, it can no longer be read:

Device Guard

The goal of the Device Guard function is to prevent the execution of malicious code. This is known as a whitelisting solution with a signature-based approach. It means that only code that is explicitly categorized as benign is executed. Device Guards stops drivers from loading, restricts the execution of binary files (including DLLs) in user mode, MSI and scripts (PowerShell, Windows Script Host, VBS, JS, WSF and WSC) that are not explicitly permitted. With PowerShell, scripts are generally run in constrained language mode unless they are explicitly cleared for execution.

The advantage of Device Guard over other solutions, such as Microsoft AppLocker, is the use of virtualization-based security and with it the isolation from the rest of the operating system. This means the policy is protected from manipulation by administrators or malware with the relevant execution permissions.

Device Guard is composed of the following three primary components:

• Configurable code integrity (CCI): ensures that only trustworthy code is executed after starting the boot loader
• VSM-protected code integrity: The code integrity control for kernel mode code integrity (KMCI) and hypervisor code integrity (HVCI) is executed in isolation in VSM
• Platform and UEFI Secure Boot: ensures that boot binary files and UEFI firmware are signed and have not been amended

The implementation of Device Guard has similar requirements as for VSM.

A code integrity policy should be created on a system that has all the software required for operation (golden image). Through the PowerShell cmdlet New-CIPolicy, the system is scoured for installed applications and a policy generated on this basis. The policy comes in XML format and is converted into binary format before usage with the ConvertFrom-CIPolicy. The Deploy Guide by Microsoft employee Brian Lich discusses all the steps necessary for creation of such a policy.

The Device Guard policy should always be operated in audit mode to begin with. This permits infringements of the policy that are merely recorded in the Event Log Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational. This ensures that the policy is not blocked for the operation of required applications. Where multiple policies are created – for example, an initial policy and other policies that handle special cases, such as the blocking of a particular program – these must be merged so that only one binary policy per computer can be used. The cmdlet Merge-CIPolicy is used for this. As an additional protective measure, a signature test for the CI policy itself can be activated.

Evaluation – is the tide turning?

The use of virtualization techniques brings a new level of security to Windows. Because the security-relevant functions are isolated from the operating system, the previous vulnerability – that an attacker with control of the system can cancel protective measures – is mitigated. This alone is a big step for a system’s security.

Credential Guard prevents current known attacks on the LSA process and so prevents reading of access data in storage until further notice. As long as the hardware requirements are met, Credential Guard can be activated via a group policy and does not have to undergo further configuration or adaptation. Therefore, it is relatively easy to implement this function. The implementation of Credential Guard as part of a Windows 10 rollout is regarded as realistic. This will increase the effort required for attackers to reach domain access data in the future. Credential Guard is a step in the right direction, but it can not prevent every type of attack. Attacks via phishing, key loggers and access data outside Credential Guard, or directly in the currently logged-in user’s session, will still be possible.

The implementation of Device Guard, on the other hand, is a little more complex than Credential Guard. With the use of signatures, a PKI environment should be available so that your own code-signing certificates can be deployed. In addition, it depends on the software manufacturers correctly signing their applications. There is provision for applications without signatures to be included as an exception in the policy, with the inclusion of hashes. In a heterogeneous environment with numerous different applications, this could represent a major challenge. Moreover, the configuration of an effective code-integrity policy is currently possible only through PowerShell cmdlets and editing of the XML file. The lack of a graphic configuration interface could have an inhibiting influence on the expansion of Device Guard. We can therefore assume that Device Guard will be used in only a few companies in the next three to five years.

Security researcher Casey Smith has already found workarounds for a standard code-integrity policy. By using debuggers of the tool MSBuild.exe of the .NET framework and the tool CSI.exe for C# scripting, it was possible to circumvent a policy generated in line with the example in the Device Guard chapter and execute random code. All these bypasses are based on the fact that internal, trustworthy Windows tools can be misused to execute additional code. Matt Graeber has created a separate policy as a counter-measure against this known bypass. This adaptation by Matt explicitly blocks this tool, or allows it only when the minimal version number 99.0.0.0 is reached. The head-to-head race between attack and defense will continue with Device Guard.

Conclusion

Credential Guard and Device Guard have the potential to selectively change the security landscape. With these two functions, Windows now has new security controls based on virtualization techniques. Whether this potential can be used, however, depends on whether these functions can also be implemented in real life. With Device Guard, particularly, it will be years before we see widespread implementation. And it will be a few more years – with many lines of malicious code executed and sensitive access data read without permission – until the tide really turns.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• http://subt0×10.blogspot.ch/2016/05/to-disarm-device-guard-bring-debugger.html
• http://subt0×10.blogspot.com
• http://subt0×10.blogspot.com/2016/09/application-whitelisting-bypass-csiexe.html
• http://subt0×10.blogspot.com/2016/09/bypassing-application-whitelisting.html
• http://www.exploit-monday.com/
• https://github.com/gentilkiwi/mimikatz
• https://github.com/mattifestation/DeviceGuardBypassMitigationRules/blob/master/BypassDenyPolicy.xml
• https://technet.microsoft.com/en-us/itpro/windows/keep-secure/deploy-code-integrity-policies-steps
• https://technet.microsoft.com/en-us/itpro/windows/keep-secure/device-guard-deployment-guide
• https://technet.microsoft.com/en-us/itpro/windows/keep-secure/requirements-and-deployment-planning-guidelines-for-device-guard
• https://technet.microsoft.com/en-us/library/mt634485.aspx
• https://technet.microsoft.com/en-us/library/mt733073.aspx
• https://technet.microsoft.com/itpro/windows/keep-secure/credential-guard
• https://technet.microsoft.com/library/mt634473.aspx