Windows Defender System Guard: Making a leap forward in platform security with memory integrity

Microsoft

Windows Defender System Guard: Making a leap forward in platform security with Memory integrity in Core isolation (VBS)

 

The escalating sophistication of cyberattacks is marked by the increased use of kernel-level exploits that attempt to run malware with the highest privileges and evade security solutions and software sandboxes. For example, kernel exploits famously gave the WannaCry and Petya ransomware a remote code execution capability, resulting in wide scale global outbreaks, the likes of which have not been seen in many years. Windows 10 remained resilient to these attacks, but Microsoft is constantly evolving protections to stay ahead of threat actors.

 

Since the initial release of Windows 10 (1507), enterprise customers have had the option to enable virtualization-based security (VBS) and hypervisor protected code integrity (HVCI) to increase platform threat resistance. In Windows 10 Creators Update (1709) we consolidated these system integrity features in Windows Defender System Guard.

 

In an upcoming release of Windows 10, we will be bringing a subset of VBS features to all editions of Windows to ensure our customers remain safe from increasingly sophisticated attacks. Devices that meet hardware and firmware requirements will have parts of VBS enabled by default.  Additionally, as part of this effort, Hypervisor protected code integrity (HVCI) will also be available and turned on by default in clean installs; for older systems, customers will have the ability to opt in post upgrade using the UI in Windows Defender Security Center (WDSC). This enhancement will ensure that the kernel process that verifies code integrity runs in a secure runtime environment provided by VBS. This will allow Windows 10 to protect the widest possible range of diverse users and scenarios.  As a Windows Insider, you are seeing this already in current builds as an opportunity for early adoption and feedback to our team!

 

In addition, with Memory integrity protection, kernel memory pages are only made executable after passing code integrity checks inside the secure runtime environment, and executable pages themselves are never writable. This is an enhancement to intrusion prevention capabilities in Windows Defender Exploit Guardp1.jpg

 

 

Application compatibility

While hypervisor-protected code integrity compliance has been a requirement for all drivers since Windows 10 Anniversary Update (1607), some drivers may still not be compatible. This may cause devices or software to malfunction.  Such issues may occur after Memory integrity protection has been turned on or during the enablement process itself. If you’re an application developer and want to validate if your drivers and software packages are compliant with memory integrity, you can follow the steps outlined here.

We worked hard to mitigate impacted experiences, so if an incompatibility exists for a boot-critical driver, Memory integrity protection will be silently turned off. If you encounter incompatibilities with other apps, Microsoft advises that you check for updates for the specific app and version encountering the issue before turning off memory integrity protection. The following links show some examples of commonly-used APIs that cause executable memory to be allocated, along with some example fixes:

Advanced security enablement simplified

Given the reliance on hardware and the need to have compatible kernel drivers, enabling a feature like memory integrity can be challenging even for adept users. In the next Windows 10 version, we will make enablement simple and straightforward to the end user, via the Windows Defender Security Center app to manage this feature set. 

 

The Windows Defender Security Center app will include a new section called Device security.

 

p2.jpg

 

The Device security section will show overall device status in terms of built-in hardware protection. VBS and memory integrity status are reported in Core isolation details

 

p3.jpg

 

In Core isolation, you can turn Memory integrity (hypervisor-protected code integrity) on or off. In some scenarios where you may encounter application compatibility issues, you may need to turn this off. This will require a system reboot.

 

p4.jpg

 

 

Windows 10 with Core isolation (VBS)

At Microsoft, we are constantly innovating and raising the bar for security. We invest in next-gen security products, but some of our investments involve transforming the platform itself. Memory integrity protection using virtualization-based security is one of the ways in which we continue to harden the platform against sophisticated attacks. 

 

Send us feedback via the Hub, log bugs, and help us make Windows 10 even more secure by emailing our team.

 

Chris Riggs and Nazmus Sakib
Windows Enterprise Security team

 

 

6 Replies
Excellent, thank you! As a small-scale developer without Enterprise Edition I welcome all features that help to protect my dev, DevOps and build machines - all of which would be quite high-value targets. I would be interested in learning how compatible these features are with nested virtualisation (xen, hyper-v, kvm), and popular cloud platforms.
Would it be safe to dump Malwarebytes and just rely on Windows Defender? Thanks.

Hopefully at some stage all the rest of the Defender Suite will be able to be simply configured in a similar fashion? Although I'm guessing that by it's very nature that "Application Control" might be a bit more complex...

I have provided feedback/suggestions to Nazmus Sakib in a separate thread.

Now proceeding at testing the other functions related to the ASD Essential 8, good work on the expanding Defender Suite 


Regards,
Dave Caddick

It would be nice if after enabling Memory Integrity in Core Isolation, the BSOD 'SYSTEM_THREAD_EXCEPTION_NOT_HANDLED' mentioned which driver tried to write to a memory page.

When booted in regular old "non-integrity" mode, the `Device Guard and Credential Guard hardware readiness tool` does not show any driver with executable pages on my system. This makes it hard to track down the offending driver. At this early point Windows does not write any BSOD error report to disk.

 

Edit: Hmm, I managed to enable a tiny bit more error reporting on screen. Now to figure out what it means (with address randomization it probably means almost nothing):

 

0xFFFFFFFFC0000096 

0xFFFFF803ED88F08F

0xFFFFED0CB7C067E8

0xFFFFED0CB7C06030

I am glad to see this change but have a clarification question around paragraph three.  It says parts of VBS will be enabled by default.  Will that be for both clean systems and upgrades from previous Win10 versions?