Defending against these types of threats—whether those that live off the land by using what’s already on the machine or those that bring in vulnerable drivers as part of their attack chain—requires a fresh approach to security, one that combines threat defense on multiple levels: silicon, operating system, and cloud. Microsoft brought this chip-to-cloud approach with Azure Sphere, the integrated security solution for IoT devices and equipment. We brought the same approach to securing endpoint devices through Secured-core PCs.

Secured-core PCs combine virtualization, operating system, and hardware and firmware protection. Along with Microsoft Defender Advanced Threat Protection, Secured-core PCs provide end-to-end protection against advanced threats.

Hardware profile guaranteed to support the latest hardware-backed security features

Microsoft worked internally and externally with OEM partners Lenovo, HP, Dell, Panasonic, Dynabook, and Getac to introduce a new a class of devices, Secured-core PCs. Secured-core PCs address the need for customers to perform the complex decision flow of mapping which security feature (e.g., hypervisor-protected code integrity (HVCI), virtualization-based security (VBS), Windows Defender Credential Guard) are supported by which hardware (e.g., TPM 1.0, 2.0, etc.).

With Secured-core PCs, customers no longer need to make this complex decision; they’re assured that these devices support the latest hardware-backed security features.

Hardware-backed security features enabled by default

Secured-core PCs have the hardware-backed security featured enabled by default, removing the need for customers to test and enable these features, which require a combination of BIOS and OS settings changes.

Because both BIOS settings and OS settings are enabled out of the box with these devices, the burden to enable these features onsite is removed for customers. The following hardware-backed security features are enabled by default on any Secured-core PC:

While some of these features have previously existed, customers had the burden of (1) choosing the right hardware profile that supported all of these features and (2) enabling these features on their devices. With Secured-core PCs, these hardware-backed security features are assured to work on the hardware and are enabled by default.

Advanced security features: Secure device risk, anti-tampering, driver control, firmware control, supply-chain interdiction, and more

The hardware-backed security features that are enabled by default, along with a combination of Secured-core services, seamlessly integrate with Microsoft Defender ATP, lighting up additional security scenarios and providing unified protection against the entire attack chain.

In this blog, we will showcase how Secured-core PC features deliver strong driver controls that protects against threats that use vulnerable drivers to elevate privilege, using the RobbinHood ransomware as example.

Case study: Secured-core PCs vs. RobbinHood ransomware

RobbinHood ransomware is distributed as a packed executable that contains multiple binaries. One of these files is a Gigabyte driver (GDRV.sys), which has a vulnerability that  could allow elevation of privilege, enabling an adversary to gain kernel privileges. In RobbinHood campaigns, adversaries use these kernel privileges to disable kernel-mode signing to facilitate the loading of an unsigned driver. The unsigned malicious driver is then used to disable security products from the kernel.

Figure 1. RobbinHood ransomware attack chain

RobbinHood is not an isolated threat leveraging a vulnerable driver to achieve elevation of privilege. In the last two years, the Microsoft Defender ATP Research Team has seen a rise in the use of vulnerable drivers by adversaries, ranging from commodity malware to nation-state level attacks. In addition to vulnerable drivers, there are also drivers that are vulnerable by design (also referred to as “wormhole drivers”), which can break the security promise of the platform by opening up direct access to kernel-level arbitrary memory read/write, MSRs.

In our research, we identified over 50 vendors that have published many such wormhole drivers. We actively work with these vendors and determine an action plan to remediate these drivers. In order to further help customers identify these drivers and take necessary measures, we built an automated way in which we can block vulnerable drivers, and that is updated through Windows update. Customers can also manage their own blocklist as outlined in the sections below.

Preventive defenses

Two of the security promises of Secured-core PCs are directly applicable to preventing RobbinHood attacks:

• Defending against vulnerable and malicious drivers
• Defending against unverified code execution

Defending against vulnerable and malicious drivers

Secured-core PCs are the latest hardware to provide driver control out of the box, with baseline configuration already set. Driver control is provided by a combination of HVCI & Windows Defender Application Control (WDAC) technologies.

Every driver loaded into the kernel is verified by HVCI before it’s allowed to run. HVCI runs in a hardware-protected execution environment isolated from the kernel space and cannot be tampered with by other code running in the kernel, including drivers.

Driver control uses HVCI & WDAC technologies to perform the following operations:

1. Validity and memory integrity enforcement at load-time and runtime

HVCI uses hardware-based virtualization and the hypervisor (the same hypervisor also used in Azure) to protect Windows kernel mode processes from injection and execution of malicious or unverified code. The integrity of code that runs in the Windows kernel is validated by HVCI according to the kernel signing policy applied to the device. Additionally, kernel memory pages are never simultaneously writable and executable. This makes Secured-core PCs highly resistant to malicious software attempting to gain code execution in the kernel.

In the case of GDRV.sys, which is the driver used by the RobbinHood malware, if the vulnerable driver is successfully loaded and then exploited, the runtime memory integrity check would protect the critical components. Thus, an attack to change ci!g_CiOptions and nt!g_CiEnabled, would be ineffective, as the kernel ignores changes to the variables coming from the general kernel space. And, as code integrity is enabled by default, the malicious driver RBNL.sys wouldn’t load.

The image below shows an event log from a Secured-core PC showing runtime memory integrity check preventing the CI options from being tampered with by RobbinHood and, subsequently, preventing the malicious driver RBNL.sys from being loaded.

Figure 2. Event log from Secured-core PC

Because runtime memory integrity check is enabled by default on Secured-core PCs, RobbinHood wouldn’t be able to disable code integrity on these machines.

2. Blocklist check

While the most ideal scenario is for enterprises to set customer-specific allows lists, it can be a complex undertaking. To help customers, HVCI uses a blocklist of drivers that are blocked from loading. This blocklist is supplied in two ways:

• • Microsoft-supplied blocklist

Microsoft threat research teams continuously monitor the threat ecosystem and update the list of drivers that in the Microsoft-supplied blocklist. This blocklist is pushed down to devices via Windows update.

We’ve heard from customers that they’d like to provide a list of drivers that should be on the generic Microsoft-supplied blocklist. We’re working on a new feature that allow customers to submit drivers that they’d like us to review and add to the Microsoft-supplied blocklist.

• • Customer-specific blocklist

We recognize that there are situations where customers want a blocklist specific to their organization. By default, any validly signed driver is accepted, but customers can choose to reduce the list of accepted drivers by choosing only WHQL signed drivers. These are drivers that are submitted to Microsoft for signing and are run through a number of tests before being signed.

Devices can apply a custom code integrity policy that customers can use to define their own specific blocklist. This article has more information on how to create such a customer specific blocklist. Below is an example of a customer-specific blocklist that blocks the vulnerable driver GDRV.sys.

Figure 3. Custom blocklist that blocks the vulnerable driver GDRV.sys

Defending against unverified code execution and kernel data corruption attacks

There are several unverified code execution mitigations built-in to Windows. These are readily available on Secured-core PCs.

The RobbinHood attack utilized the vulnerable GDRV.sys driver to change a crucial variable within the system memory. Although HVCI already protects against the attack on g_CiOptions, other areas of memory may still be susceptible, and we need broader defense against kernel data corruption attacks.

In addition to existing mitigations, Windows is introducing a new feature called Kernel Data Protection (KDP), which provides driver developers and software running in the Windows kernel (and the OS code itself) with the ability to mark some kernel memory containing sensitive information as read-only protected. The memory is protected through the second level address translation (SLAT) tables by the hypervisor, such that no software running in VTL0 have access to the protected memory. KDP does not protect executable pages, as those are already protected with HVCI.

Many kernel components have data that is set only once during boot and remains unchanged for the rest of the boot cycle. The first release of KDP protects the static data sections of a driver. In the future, we’re also planning to provide APIs to dynamically allocate and release protected initialized pool memory.

Secured-core PCs have KDP enabled by default.

Detection defenses

As observed in RobbinHood attacks, once the threat gains kernel-level privilege, the threat turns off system defenses, including the endpoint protection agent. Secured-core PCs provide a monitoring agent that utilizes virtualization-based security and runs in this protected environment.

The monitoring agent performs several functions. The ones relevant for this case study are:

• Secure anti-tampering for security agents
• Secure monitoring of Windows

Secure anti-tampering for security agents

This monitoring agent watches for attempts to tamper with the security agents. For Microsoft Defender ATP customers, these are integrated into alerts that are surfaced in Microsoft Defender Security Center.

Figure 4. Windows Defender System Guard runtime monitor agent

Secure monitoring of Windows

The agent also monitors several areas of Windows, including checking for kernel exploit behavior that are often used to elevate privileges. In this particular case, the monitoring agent detected a token tampering assertion.

Figure 5. Microsoft Defender ATP alert for process privilege escalation

Secured-core PCs have both VBS and this secure monitoring agent turned on by default.

Conclusion

As this case study demonstrates, more and more threats are becoming so advanced that they can bypass software-only based defenses. Secured-core PCs are protected from RobbinHood and similar threats by default.

Customers can also get similar protection on traditional devices as long as they have the necessary hardware and are configured correctly. Specifically, the following features need to be enabled: Secure boot, HVCI (enables VBS), KDP (automatically turned on when VBS is on), KDMA (Thunderbolt only) and Windows Defender System Guard.

With Secured-core PCs, however, customers get a seamless chip to cloud security pattern that starts from a strong hardware root of trust and works with cloud services and Microsoft Defender ATP to aggregate and normalize the alerts from hardware elements to provide end-to-end endpoint security.

Overall improved endpoint protection accrues to the broader Microsoft Threat Protection, which combines and orchestrates into a single solutions the capabilities of Microsoft Defender ATP, Office 365 ATP, Azure ATP, and Microsoft Cloud App Security to provide comprehensive, cross-domain protection for endpoints, email and data, identities, and apps.

The post Secured-core PCs: A brief showcase of chip-to-cloud security against kernel attacks appeared first on Microsoft Security Blog.

Recently, the Microsoft Defender ATP research team found a malicious system driver enabling a token swap attack that could lead to privilege escalation. In this blog, we’ll share our analysis of the said attack and discuss how Windows Defender Antivirus uses its unique visibility into system behaviors to detect dangerous kernel threats.

Hardware-based root of trust

Windows Defender System Guard, a hardware-based system integrity capability in Microsoft Defender ATP, has a runtime measurement component called runtime attestation. This runtime measurement component includes a sub-engine called assertion engine (see Figure 1), which continuously measures and asserts the integrity of the Windows kernel, providing supplementary signals about any abnormal system behavior.

Figure 1. High-level Windows Defender System Guard runtime attestation architecture

Architecturally, the solution is collectively referred to as the Windows Defender System Guard runtime monitor and consists of the following client-side components:

• The VTL-1 runtime assertion engine itself
• A VTL-0 kernel-mode agent
• A VTL-0 process we call the ‘broker’ to host the assertion engine

The goal is to detect artifacts of data corruption attacks and other threats that tamper with kernel-mode agents at the hypervisor level. Windows Defender Antivirus, the next-generation component of Microsoft Defender ATP, integrates with Windows Defender System Guard runtime attestation and consumes signals from the assertion engine.

Detecting token theft attacks

Every Windows process has a primary token that describes the security context of the user account associated with the process. The information in the token includes the identity and privileges of the user account associated with the process or thread. Token theft attacks are rampant because they can allow adversaries to use access tokens to operate using different user accounts or under different system security contexts to perform malicious actions and evade detection.

The Microsoft Defender ATP Research team recently uncovered and analyzed signals from Windows Defender System Guard assertion engine that indicated manipulation of a primary token, causing token swap – a distinctly suspicious activity, given that the aspects of a primary token are immutable once the process starts running.

Further analysis of Windows Defender Antivirus telemetry identified the offending malicious system driver responsible for the invariant token swap attack. The sample containing the system driver was signed with a compromised certificate (thumbprint: 31e5380e1e0e1dd841f0c1741b38556b252e6231) that’s commonly misused in the wild.

Figure 2. Revoked certificate used by malicious system driver

The driver exhibited the following rootkit behavior:

• Token swap
• Tampering EPROCESS structure in kernel mode and PEB to disguise a process as svchost.exe

In this scenario, Windows Defender System Guard raised an initial assertion failure signal for the token swap. Windows Defender Antivirus consumed the signal and applied intelligence to discover that the suspicious activity was being orchestrated by a system driver.

Figure 3. Decompiled malicious driver code for token theft

Using a Microsoft cloud service that that keeps track of stolen or revoked PKI certificates worldwide, Windows Defender Antivirus found that the driver was indeed signed by a revoked or stolen certificate, which was communicating with the infected binary to perform the token swap.

Windows Defender Antivirus works seamlessly with Microsoft cloud services, such as the one that flags binaries signed by stolen or revoked certificates. Signals like these enrich the protection delivered by multiple next-generation protection engines in Windows Defender Antivirus to provide near-instant, automated defense against new and emerging threats. With cloud-delivered protection, next-generation technologies provide rapid identification and blocking of attacks, typically even before a single machine is infected.

Device integrity for broader security

The goal of Windows System Guard runtime attestation is to provide its consumers with a trustworthy assessment of the security posture and integrity of devices. Apps and services can take advantage of this attestation technology to ensure that the system is free from tampering and that critical processes are running as expected. Runtime attestation can help in many scenarios, including:

• Providing supplementary signals for endpoint detection and response (EDR) and antivirus vendors (including full integration with the Microsoft Defender ATP stack)
• Detecting artifacts of kernel tampering, rootkits, and exploits
• Protected game anti-cheat scenarios (for example, detection of process-protection bypasses that can lead to game-state modification)
• Securing sensitive transactions (banking apps, trading platforms)
• Conditional access (enabling and enhancing device security-based access policies)

The assertion engine can detect attacks that can reasonably be performed under the most restrictive attack conditions, such as when system has been already hardened with hypervisor-protected code integrity (HVCI) and enforced kernel mode code integrity (KMCI).

The case study has shown how Microsoft Defender ATP – hence, the broader Microsoft Threat Protection – reaps significant security benefits from Windows Defender System Guard runtime attestation. We invite the industry to do the same.

To learn more, read our blog about Windows Defender System Guard runtime attestation.

Abhijat Singh, Enterprise & Security
David Kaplan (@depletionmode), Microsoft Defender ATP Research
Chun Feng, Microsoft Defender ATP Research
Hermineh Sanossian, Enterprise & Security

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Defender ATP community.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post How Windows Defender Antivirus integrates hardware-based system integrity for informed, extensive endpoint protection appeared first on Microsoft Security Blog.

Our focus for this release was responding to some longstanding feedback on manageability improvements. We’re excited to introduce the following new capabilities in Windows Defender Application Control:

1. File path rules, including optional runtime admin protection checks
2. Multiple policy file support with composability
3. Application Control CSP to provide a new, richer MDM policy management capability
4. COM object registration support in policy
5. Disabling script enforcement rule option

Application control is frequently identified as one of the most effective mitigations against modern security threats, because anything that’s not allowed by policy is blocked from running. Even striving towards a simple policy like mandating that only signed code is allowed to execute can be incredibly impactful: in a recent analysis of Windows Defender ATP data, we saw that 96% of malware encountered is unsigned. Systems like Windows 10 in S mode, which uses WDAC technology to enforce that all code must be signed by Windows and Microsoft Store code signing certificates, have no malware infection issues.

The new capabilities are designed to ease the journey for customers adopting application control in real-world environments with large numbers of applications, users, and devices.

File path rules, including optional runtime admin protection checks

For many customers looking to adopt application execution control while balancing IT overhead, rules based on file paths on managed client systems provide a useful model. The Windows 10 May 2019 Update introduces support for both allow and deny rules based on file path in Windows Defender Application Control.

File path rules had been one of the few features available in AppLocker, the older native application control technology, that were not available to WDAC; deployment tools and methodologies built on top of AppLocker like AaronLocker have relied on these rules as an important simplifying option for policy management. As we sought to close that gap, we wanted to preserve the stronger security posture available with WDAC that customers have come to expect. To this end, WDAC applies, by default, an option to check at runtime that apps and executables allowed based on file path rules must come from a file path that’s only writable by administrator or higher privileged accounts. This runtime check provides an additional safeguard for file path rules that are otherwise inherently weaker than other identifiers like hash or signer rules, which rely on cryptographically verifiable attributes.

This runtime capability can be controlled with the “Disabled:Runtime FilePath Rule Protection” rule option.

The following example shows how to easily create rules for anything allowed under “Program Files” and “Program Files (x86)”, and then merge them with the sample policy that allows all Windows signed code (available under C:\Windows\schemas\CodeIntegrity\ExamplePolicies). The resulting merged policy file allows all Windows signed code and applications installed under “Program Files” and “Program Files (x86)” with the runtime protection that checks that anything executing under those paths is coming from a location only writable by administrator or higher privileged accounts.

Multiple policy file support with composability

Limiting support to a single policy file means that a variety of app control scenarios from potentially different stakeholders or business groups need to be maintained in one place. This comes with an associated overhead: the coordination required to converge on the appropriate rules encapsulated in a single policy file.

With the Windows 10 May 2019 Update multiple policy files are supported for WDAC. To facilitate composing behavior from multiple policy files, we have introduced the concept of base and supplemental policies:

• Base policies – For any execution to be allowed, the application must pass each base policy independently. Base policies are used together to further restrict what’s allowed. For example:
  Let’s assume a system has two policies: Base Policy A and Base Policy B with their own sets of rules. For foo.exe to run, it must be allowed by the rules in Base Policy A and also the rules in Base Policy B. Windows Defender Application Control policies on prior Windows 10 systems will continue to work on the May 2019 Update and will be treated as base policies.
• Supplemental policies – As the name suggests, supplemental policies complement base policies with additional rules to be considered as part of the base policies they correspond to. Supplemental policies are tied to a specific base policy with an ID; a base policy may have multiple supplemental policies. Supplemental policies expand what is allowed by any base policy, but deny rules specified in a supplemental policy will not be honored.

Application Control CSP

Customers have been able to deploy Windows Defender Application Control policies via MDM using the CodeIntegrity node of the AppLocker configuration service provider (CSP). The AppLocker CSP has a number of limitations, most notably the lack of awareness of rebootless policy deployment support.

The Windows 10 May 2019 Update now has a new Application Control CSP, which introduces much richer support for policy deployment over MDM and also provides support for:

• Rebootless policy deployment (For policies that have the “Enabled:Update Policy No Reboot” option set, the new Application Control CSP will not schedule a reboot on client systems getting the policy)
• Support for the new multiple policies
• For device management software vendors, better error reporting

COM object registration support

Windows Defender Application Control enforces a built-in allow list of COM object registrations to reduce the risk introduced from certain powerful COM objects. Customers have reported that while this capability is desirable from a security perspective, there are specific cases in their environments where they’d like to allow the registration of additional COM objects required for their business.

With the Windows 10 May 2019 Update customers can now specify COM objects that need to be allowed in environments they’re managing with Windows Defender Application Control policies.

Disabled: Script Enforcement rule option support

The Windows 10 May 2019 Update with KB4497935 introduces proper support for the Disabled: Script Enforcement rule option.

Customers recognize the importance of having restrictions on script hosts but are often looking to break up their application control projects into smaller chunks to help with deployment feasibility. The “Disabled:Script Enforcement” rule option in the policy now turns off policy enforcement for MSIs, PowerShell scripts, and wsh-hosted scripts. This will allow IT departments to tackle EXE, DLL, and driver enforcement without needing to also simultaneously address script host control.

Try the new capabilities today

We invite everyone to try these new Windows Defender Application Control capabilities, alongside existing features like managed installer. For customers using Microsoft Defender ATP, consider using Advanced hunting to query the WDAC events centrally to understand and monitor the behavior of all these new policy controls on client machines in your environment. Learn about both new and existing functionalities with the Windows Defender Application Control deployment guide.

We’re also working on supplementing the documentation we have out now. Stay tuned for updates from our team for tools and guidance on GitHub that provide more practical examples and ready-to-use scripts.

Nazmus Sakib
Senior Program Manager, Windows Defender Application Control team

The post Delivering major enhancements in Windows Defender Application Control with the Windows 10 May 2019 Update appeared first on Microsoft Security Blog.

We introduced the container technology in 2017. Since then, we have been evolving the technology and engaging with customers to understand how hardware-based isolation can best help solve their security concerns. We know that many of our customers depend on multi-browser environments to allow enterprise apps to meet various compatibility requirements and enable productivity. And while modern browsers are continuously working to mitigate vulnerabilities, there are still exposures across these complex engines that can lead to irreversible and costly damages.

To provide customers with a comprehensive solution to isolate potential browser-based attacks, we have designed and developed Windows Defender Application Guard extensions, now generally available, to allow customers to integrate hardware-based isolation with Google Chrome and Mozilla Firefox.

How it works

The extensions for Google Chrome and Mozilla Firefox automatically redirect untrusted navigations to Windows Defender Application Guard for Microsoft Edge. The extension relies on a native application that we’ve built to support the communication between the browser and the device’s Application Guard settings.

When users navigate to a site, the extension checks the URL against a list of enterprise sites defined by enterprise administrators. If the site is determined to be untrusted, the user is redirected to an isolated Microsoft Edge session. In the isolated Microsoft Edge session, the user can freely navigate to any site that has not been explicitly defined as enterprise-trusted by their organization without any risk to the rest of system. With our upcoming dynamic switching capability, if the user tries to go to an enterprise site while in an isolated Microsoft Edge session, the user is taken back to the default browser.

To configure the Application Guard extension under managed mode, enterprise administrators can follow these recommended steps:

1. Ensure devices meet requirements.
2. Turn on Windows Defender Application Guard.
3. Define the network isolation settings to ensure a set of enterprise sites is in place.
4. Install the new Windows Defender Application Guard companion application from the Microsoft Store.
5. Install the extension for Google Chrome or Mozilla Firefox browsers provided by Microsoft.
6. Restart the device.

Intuitive user experience

We designed the user interface to be transparent to users about Windows Defender Application Guard being installed on their devices and what it does. We want to ensure that users are fully aware that their untrusted navigations will be isolated and why.

1. When users initially open Google Chrome or Mozilla Firefox after the extension is deployed and configured properly, they will see a Windows Defender Application Guard landing page. 
2. If there are any problems with the configuration, users will get instructions for resolving any configuration errors. 
3. Users can initiate an Application Guard session without entering a URL or clicking on a link by clicking the extension icon on the menu bar of the browser.

Commitment to keep enterprise users and data safe

Hardware-based isolation is one of the innovations that enhance platform security on Windows 10. It is a critical component of the attack surface reduction capabilities in Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) and the broader unified security in Microsoft Threat Protection. With the new Application Guard extension for Google Chrome and Mozilla Firefox, customers can extend the security benefits of isolation in their environments and further reduce attack surface. Customers can confidently navigate the expansive internet with protection for enterprise and personal data.

The Windows Defender Application Guard extensions for Google Chrome and Mozilla Firefox are now available for Windows 10 Professional, Enterprise, and Education SKUs, version 1803 and later with latest updates.

Rona Song
Windows platform security team

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Defender ATP community.

Follow us on Twitter @MsftSecIntel.

The post New browser extensions for integrating Microsoft’s hardware-based isolation appeared first on Microsoft Security Blog.

In Windows 10 Fall Creators Update, we reorganized all system integrity features into Windows Defender System Guard. This move allowed us to continually make significant innovations in platform security. Windows Defender System Guard runtime attestation, which is built into the core Windows operating system, will soon be delivered in all editions of Windows. Windows Defender System Guard runtime attestation, like Credential Guard, takes advantage of the same hardware-rooted security technologies in virtualization-based security (VBS) to mitigate attacks in software.

Security technologies are targeted by exploits that attempt to run in the same domain of trust. For example, privileged processes are designed to provide a certain degree of isolation (at least in respect to code and data) from regular user-mode processes. The NT kernel determines whether a process is protected based on certain values held in the executive process object. Tampering with these values via a kernel exploit or with a driver (e.g., Mimikatz) can effectively disable process protection. Moving the security decision related to tampering to a separate domain of trust increases complexity for attackers.

Runtime attestation can help in many scenarios, including:

• Providing supplementary signals for endpoint detection and response (EDR) and antivirus vendors (including full integration with the Windows Defender Advanced Threat Protection stack)
• Detecting artifacts of kernel tampering, rootkits, and exploits
• Protected game anti-cheat scenarios (for example, detection of process-protection bypasses that can lead to game-state modification)
• Sensitive transactions (banking apps, trading platforms)
• Conditional access (enabling and enhancing device security-based access policies)

With the next update to Windows 10, we are implementing the first phase of Windows Defender System Guard runtime attestation, laying the groundwork for future innovation in this area. This includes developing new OS features to support efforts to move towards a future where violations of security promises are observable and effectively communicated in the event of a full system compromise, such as through a kernel-level exploit.

Attestation and establishing trust

To introduce Windows Defender System Guard runtime attestation on a technical level, it’s best to begin at the most visible layer: a client API that will eventually be exposed to a relying party. (Note: We share details of the general design as it’s currently architected; final implementation may differ.)

We are working towards providing an API that relying parties can use to attest to the state of the device at a point in time. The API returns a runtime report that details the claims that Windows Defender System Guard runtime attestation makes about the security posture of the system. These claims include assertions, which are runtime measurements of sensitive system properties.

For the runtime report to have any significant meaning, it must be generated in a fashion that provides reasonable resistance against tampering. This gives rise to the following basic component requirements:

1. Runtime report generation must be isolated from an attacker
2. This isolation must be attestable
3. The runtime report must be cryptographically signed in a manner that is irreproducible outside the isolated environment

Enter VBS enclaves. We’re not going to describe these enclaves in-depth here, but it’s prudent to give some context. On a device with virtual secure mode (VSM) enabled, virtualization extensions of the underlying Instruction Set Architecture (ISA) are employed to logically divide the system into two (theoretically, more) separate ‘worlds’: the ‘normal’ world running the NT kernel that we’re all familiar with and a separate ‘secure’ world running a Secure Kernel (SK). We call these two logical levels of separation ‘Virtual Trust Levels’ (VTLs), in this case NT being VTL-0 and SK being VTL-1.

VBS enclaves enable what can be thought of as a siloed part of a ‘normal world’ VTL-0 user-mode process. All code and data in this silo live in VTL-1. Transactions in and out of an enclave are done via a well-defined API backed by VSL calls (the mechanism that NT and SK use to communicate). The result of this intricacy is that, as of Windows Fall Creators Update (1709), it is possible to execute code and hold data within an enclave such that the entire VTL-0 ‘normal’ world – both user-mode and kernel-mode – cannot directly act upon the siloed code and data while executing and held within the enclave (in VTL-1).

From the VBS enclave, the runtime attestation component can observe and attest to a set of security properties contained in a report. For example, an app could ask Windows Defender System Guard to measure the security of the system from the hardware-backed enclave and return a report. The details in this report can be used by the app to decide whether it performs a sensitive financial transaction or display personal information.

VBS enclaves can also expose an enclave attestation report signed by a VBS-specific signing key. If Windows Defender System Guard can obtain proof that the host system is running with VSM active, it can use this proof together with a signed session report to ensure that the particular enclave is running.

As for the signature of the runtime report itself, an asymmetrical public-private key pair is generated within the enclave. The public key is signed by the Windows Defender System Guard attestation service backend to create a session certificate. In addition, the Windows Defender System Guard attestation service backend produces a signed session report containing details about the machine. These details include boot security properties, including whether the machine booted with Secure boot enabled, to ensure that the core operating system has not been jailbroken or tampered with. Finally, runtime reports are signed locally by the paired private key, which never leaves the enclave. The runtime and session reports can be verified by relying parties with little effort by verifying the report signatures against the session certificate and then ensuring that the certificate is validly signed, rooted in the relevant Microsoft CA.

Establishing the trust necessary to guarantee that the runtime report is authentic, therefore, requires the following:

• Attesting to the boot state of the machine: the OS, hypervisor, and Secure Kernel (SK) binaries must be signed by Microsoft and configured according to a secure policy
• Binding trust between the TPM and the health of the hypervisor to allow trust in the Measured Boot Log
• Extracting the VSM IDKs from the Measured Boot Log and using these to verify the VBS enclave signature
• Backend verification of the above and signing of the public component of an ephemeral key-pair generated within the enclave with a trusted CA to issue a session certificate
• Signing of the runtime report with the ephemeral private key

Networking calls between the enclave and the Windows Defender System Guard attestation service are made from VTL-0. However, the design of the attestation protocol ensures that it is resilient against tampering even over untrusted transport mechanisms.

Numerous underlying technologies are required before the chain of trust described above can be sufficiently established. To inform a relying party to the level of trust in the runtime report that they can expect on any particular configuration, a security level is assigned to each Windows Defender System Guard attestation service-signed session report. The security level reflects the underlying technologies enabled on the platform and attributes a level of trust based on the capabilities of the platform. We are mapping the enablement of various security technologies to security levels, and we will share this when the API is published for third-party use. The highest level of trust is likely to require the following features, at the very least:

• VBS-capable hardware + OEM configuration
• Dynamic root-of-trust measurements at boot
• Secure boot to verify hypervisor, NT, SK images
• Secure policy ensuring:
  • Hypervisor-protected code integrity (HVCI)-enforced kernel mode code integrity (KMCI)
  • Test-signing is disabled
  • Kernel debugging is disabled

Measurement

Now that we have explained the trusted report component, let us discuss the contents of the runtime report.

The security level exposed in the session report is an important and interesting metric in and of itself. However, Windows Defender System Guard can provide so much more – specifically in respect to runtime measurement of system security posture.

We call this runtime measurement component the ‘assertion engine’. The idea is to continually measure – ‘assert’ – system integrity at runtime, with the security level attesting to security posture at boot.

Some caveats:

• The assertion engine was designed with the ideal system configuration in mind (i.e., a system configuration with the highest security level)
  • Business needs require Windows Defender System Guard runtime attestation to function on systems even with the lowest security level; Windows Defender System Guard runtime attestation makes no guarantees in this scenario and can act as a signal for other security products on non-locked down editions of Windows
• When running the ideal configuration, non-ROP kernel-mode code execution is difficult due to hypervisor-protected code integrity (HVCI)-enforced kernel mode code integrity (KMCI); in this scenario:
  • Data corruption attacks are more likely
  • It can be assumed that it’s difficult to tamper with any required kernel-mode agents in non-racing scenarios
  • The runtime assertions are therefore targeted at attacks that can reasonably be performed under the most restrictive attack conditions
• We are working to limitations of (current) operating system design
  • We have a deep partnership with other teams in Microsoft and we are work in tandem to improve System Guard runtime attestation and core kernel security features. In the current version of the OS, we rely on NT kernel thread management and the Secure Kernel primitives provided to us.

High-level overview of Windows Defender System Guard runtime attestation architecture

Architecturally, the solution is collectively referred to as the Windows Defender System Guard runtime monitor and consists of the following client-side components:

• The VTL-1 assertion engine itself
• A VTL-0 kernel-mode agent
• A VTL-0 process we call the ‘broker’ to host the assertion engine

To rapidly respond to threats, we opted for a dynamic scripting approach that will allow us to frequently release updates going forward. We chose an open-source library that met our requirements for maturity, footprint, and performance. This scripting component forms the core of the assertion engine that executes in VTL-1 (if available).

Running arbitrary logic in this engine wouldn’t be very useful if it couldn’t interact with the system in any way. For the engine to perform useful work, we provide native helpers in the form of ‘assists’. These assists are executed in VTL-0 either by the broker service or by a Kernel-mode agent.

In the next update to Windows, assertion logic is delivered in-band (within the signed engine DLL itself). At some point in the future, these scripts will be delivered out-of-band. This is a core part of the design. It enables us to immediately respond to security events (for example, the discovery of new attack invariants) without the need for delivering a component update via servicing. Apps and services can take advantage of this attestation technology to ensure that the system is free from tampering and that critical processes are running as expected. This hardware-rooted “proof-of-health” can then be used to identify compromised machines or gate access to critical cloud services. Runtime attestation serves as a platform for a wide variety of advanced security applications.

We believe that we can significantly raise the bar for security on locked-down platforms with modern hardware and appropriate security policies. In a world where direct privileged code-execution is difficult, we think that attacks will increasingly leverage data corruption. Transient changes are also a challenge in the current model. However, future innovations will make achieving persistence harder, making transient malicious changes more difficult. The idea is to continually elevate defense across the entire Windows 10 security stack, thereby pushing attackers into a corner where system changes affecting security posture are detectable. One can think of runtime attestation as being more about detecting minute symptoms that can indicate an attack rather than looking for flashing signals.

We are very excited about this technology because of its potential for making significant leaps in platform security. There’s a lot more about Windows Defender System Guard runtime attestation that we did not cover in this blog, for example, the detailed design itself and where we see this technology going. Stay tuned.

David Kaplan (@depletionmode), Windows Defender ATP Research Team
Adam Zabrocki (@Adam_pi3), Windows Offensive Security Research Team
Rafael Goncalves, Enterprise & Security

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity.

The post Introducing Windows Defender System Guard runtime attestation appeared first on Microsoft Security Blog.