Secure the Windows 10 boot process

Applies to:

The Windows operating system has many features to help protect you from malware, and it does an amazingly good job. Except for apps that businesses develop and use internally, all Microsoft Store apps must meet a series of requirements to be certified and included in the Microsoft Store. This certification process examines several criteria, including security, and is an effective means of preventing malware from entering the Microsoft Store. Even if a malicious app does get through, the WindowsВ 10 operating system includes a series of security features that can mitigate the impact. For instance, Microsoft Store apps are sandboxed and lack the privileges necessary to access user data or change system settings.

Windows 10 has multiple levels of protection for desktop apps and data, too. Windows Defender uses signatures to detect and quarantine apps that are known to be malicious. Windows Defender SmartScreen warns users before allowing them to run an untrustworthy app, even if it’s recognized as malware. Before an app can change system settings, the user would have to grant the app administrative privileges by using User Account Control.

Those are just some of the ways that Windows 10 protects you from malware. However, those security features protect you only after Windows 10 starts. Modern malware—and bootkits specifically—are capable of starting before Windows, completely bypassing operating system security, and remaining completely hidden.

When you run Windows 10 on a PC or any PC that supports Unified Extensible Firmware Interface (UEFI), Trusted Boot protects your PC from malware from the moment you power on your PC until your anti-malware starts. In the unlikely event that malware does infect a PC, it can’t remain hidden; Trusted Boot can prove the system’s integrity to your infrastructure in a way that malware can’t disguise. Even on PCs without UEFI, Windows 10 provides even better startup security than previous versions of Windows.

First, let’s examine what rootkits are and how they work. Then, we’ll show you how Windows 10 can protect you.

The threat: rootkits

Rootkits are a sophisticated and dangerous type of malware that run in kernel mode, using the same privileges as the operating system. Because rootkits have the same rights as the operating system and start before it, they can completely hide themselves and other applications. Often, rootkits are part of an entire suite of malware that can bypass local logins, record passwords and keystrokes, transfer private files, and capture cryptographic data.

Different types of rootkits load during different phases of the startup process:

• Firmware rootkits. These kits overwrite the firmware of the PC’s basic input/output system or other hardware so the rootkit can start before Windows.
• Bootkits. These kits replace the operating system’s bootloader (the small piece of software that starts the operating system) so that the PC loads the bootkit before the operating system.
• Kernel rootkits. These kits replace a portion of the operating system kernel so the rootkit can start automatically when the operating system loads.
• Driver rootkits. These kits pretend to be one of the trusted drivers that Windows uses to communicate with the PC hardware.

The countermeasures

WindowsВ 10 supports four features to help prevent rootkits and bootkits from loading during the startup process:

• Secure Boot. PCs with UEFI firmware and a Trusted Platform Module (TPM) can be configured to load only trusted operating system bootloaders.
• Trusted Boot. Windows checks the integrity of every component of the startup process before loading it.
• Early Launch Anti-Malware (ELAM). ELAM tests all drivers before they load and prevents unapproved drivers from loading.
• Measured Boot. The PC’s firmware logs the boot process, and Windows can send it to a trusted server that can objectively assess the PC’s health.

FigureВ 1 shows the WindowsВ 10 startup process.

Figure 1. Secure Boot, Trusted Boot, and Measured Boot block malware at every stage

Secure Boot and Measured Boot are only possible on PCs with UEFIВ 2.3.1 and a TPM chip. Fortunately, all Windows 10 PCs that meet Windows Hardware Compatibility Program requirements have these components, and many PCs designed for earlier versions of Windows have them as well.

The sections that follow describe Secure Boot, Trusted Boot, ELAM, and Measured Boot.

Secure Boot

When a PC starts, it first finds the operating system bootloader. PCs without Secure Boot simply run whatever bootloader is on the PC’s hard drive. There’s no way for the PC to tell whether it’s a trusted operating system or a rootkit.

When a PC equipped with UEFI starts, the PC first verifies that the firmware is digitally signed, reducing the risk of firmware rootkits. If Secure Boot is enabled, the firmware examines the bootloader’s digital signature to verify that it hasn’t been modified. If the bootloader is intact, the firmware starts the bootloader only if one of the following conditions is true:

• The bootloader was signed using a trusted certificate. In the case of PCs certified for WindowsВ 10, the MicrosoftВ® certificate is trusted.
• The user has manually approved the bootloader’s digital signature. This allows the user to load non-Microsoft operating systems.

All x86-based Certified For WindowsВ 10 PCs must meet several requirements related to Secure Boot:

• They must have Secure Boot enabled by default.
• They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed).
• They must allow the user to configure Secure Boot to trust other bootloaders.
• They must allow the user to completely disable Secure Boot.

These requirements help protect you from rootkits while allowing you to run any operating system you want. You have three options for running non-Microsoft operating systems:

• Use an operating system with a certified bootloader. Because all Certified For WindowsВ 10 PCs must trust Microsoft’s certificate, Microsoft offers a service to analyze and sign any non-Microsoft bootloader so that it will be trusted by all Certified For WindowsВ 10 PCs. In fact, an open source bootloader capable of loading Linux is already available. To begin the process of obtaining a certificate, go to https://partner.microsoft.com/dashboard.
• Configure UEFI to trust your custom bootloader. All Certified For WindowsВ 10 PCs allow you to trust a non-certified bootloader by adding a signature to the UEFI database, allowing you to run any operating system, including homemade operating systems.
• Turn off Secure Boot. All Certified For WindowsВ 10 PCs allow you to turn off Secure Boot so that you can run any software. This does not help protect you from bootkits, however.

To prevent malware from abusing these options, the user must manually configure the UEFI firmware to trust a non-certified bootloader or to turn off Secure Boot. Software cannot change the Secure Boot settings.

Like most mobile devices, ARM-based Certified For WindowsВ RT devices, such as the Microsoft Surface RT device, are designed to run only WindowsВ 8.1. Therefore, Secure Boot cannot be turned off, and you cannot load a different operating system. Fortunately, there is a large market of ARM devices designed to run other operating systems.

Trusted Boot

Trusted Boot takes over where Secure Boot leaves off. The bootloader verifies the digital signature of the WindowsВ 10 kernel before loading it. The WindowsВ 10 kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM. If a file has been modified, the bootloader detects the problem and refuses to load the corrupted component. Often, WindowsВ 10 can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.

Early Launch Anti-Malware

Because Secure Boot has protected the bootloader and Trusted Boot has protected the Windows kernel, the next opportunity for malware to start is by infecting a non-Microsoft boot driver. Traditional anti-malware apps don’t start until after the boot drivers have been loaded, giving a rootkit disguised as a driver the opportunity to work.

Early Launch Anti-Malware (ELAM) can load a Microsoft or non-Microsoft anti-malware driver before all non-Microsoft boot drivers and applications, thus continuing the chain of trust established by Secure Boot and Trusted Boot. Because the operating system hasn’t started yet, and because Windows needs to boot as quickly as possible, ELAM has a simple task: examine every boot driver and determine whether it is on the list of trusted drivers. If it’s not trusted, Windows won’t load it.

An ELAM driver isn’t a full-featured anti-malware solution; that loads later in the boot process. Windows Defender (included with Windows 10) supports ELAM, as does Microsoft System Center 2012 Endpoint Protection and several non-Microsoft anti-malware apps.

Measured Boot

If a PC in your organization does become infected with a rootkit, you need to know about it. Enterprise anti-malware apps can report malware infections to the IT department, but that doesn’t work with rootkits that hide their presence. In other words, you can’t trust the client to tell you whether it’s healthy.

As a result, PCs infected with rootkits appear to be healthy, even with anti-malware running. Infected PCs continue to connect to the enterprise network, giving the rootkit access to vast amounts of confidential data and potentially allowing the rootkit to spread across the internal network.

Working with the TPM and non-Microsoft software, Measured Boot in WindowsВ 10 allows a trusted server on the network to verify the integrity of the Windows startup process. Measured Boot uses the following process:

1. The PC’s UEFI firmware stores in the TPM a hash of the firmware, bootloader, boot drivers, and everything that will be loaded before the anti-malware app.
2. At the end of the startup process, Windows starts the non-Microsoft remote attestation client. The trusted attestation server sends the client a unique key.
3. The TPM uses the unique key to digitally sign the log recorded by the UEFI.
4. The client sends the log to the server, possibly with other security information.

Depending on the implementation and configuration, the server can now determine whether the client is healthy and grant the client access to either a limited quarantine network or to the full network.

FigureВ 2 illustrates the Measured Boot and remote attestation process.

Figure 2. Measured Boot proves the PC’s health to a remote server

Windows 10 includes the application programming interfaces to support Measured Boot, but you’ll need non-Microsoft tools to implement a remote attestation client and trusted attestation server to take advantage of it. For an example of such a tool, download the TPM Platform Crypto-Provider Toolkit from Microsoft Research or Microsoft Enterprise Security MVP Dan Griffin’s Measured Boot Tool.

Measured Boot uses the power of UEFI, TPM, and WindowsВ 10 to give you a way to confidently assess the trustworthiness of a client PC across the network.

Summary

Secure Boot, Trusted Boot, and Measured Boot create an architecture that is fundamentally resistant to bootkits and rootkits. In Windows 10, these features have the potential to eliminate kernel-level malware from your network. This is the most ground-breaking anti-malware solution that Windows has ever had; it’s leaps and bounds ahead of everything else. With Windows 10, you can truly trust the integrity of your operating system.

Mitigate threats by using Windows 10 security features

Applies to:

This topic provides an overview of some of the software and firmware threats faced in the current security landscape, and the mitigations that Windows 10 offers in response to these threats. For information about related types of protection offered by Microsoft, see Related topics.

Section	Contents
The security threat landscape	Describes the current nature of the security threat landscape, and outlines how Windows 10 is designed to mitigate software exploits and similar threats.
Windows 10 mitigations that you can configure	Provides tables of configurable threat mitigations with links to more information. Product features such as Device Guard appear in Table 1, and memory protection options such as Data Execution Prevention appear in Table 2.
Mitigations that are built in to Windows 10	Provides descriptions of Windows 10 mitigations that require no configuration—they are built into the operating system. For example, heap protections and kernel pool protections are built into Windows 10.
Understanding Windows 10 in relation to the Enhanced Mitigation Experience Toolkit	Describes how mitigations in the Enhanced Mitigation Experience Toolkit (EMET) correspond to features built into Windows 10 and how to convert EMET settings into mitigation policies for Windows 10.

This topic focuses on pre-breach mitigations aimed at device protection and threat resistance. These protections work with other security defenses in Windows 10, as shown in the following illustration:

Figure 1.В В Device protection and threat resistance as part of the Windows 10 security defenses

The security threat landscape

Today’s security threat landscape is one of aggressive and tenacious threats. In previous years, malicious attackers mostly focused on gaining community recognition through their attacks or the thrill of temporarily taking a system offline. Since then, attacker’s motives have shifted toward making money, including holding devices and data hostage until the owner pays the demanded ransom. Modern attacks increasingly focus on large-scale intellectual property theft; targeted system degradation that can result in financial loss; and now even cyberterrorism that threatens the security of individuals, businesses, and national interests all over the world. These attackers are typically highly trained individuals and security experts, some of whom are in the employ of nation states that have large budgets and seemingly unlimited human resources. Threats like these require an approach that can meet this challenge.

In recognition of this landscape, Windows 10 Creator’s Update (Windows 10, version 1703) includes multiple security features that were created to make it difficult (and costly) to find and exploit many software vulnerabilities. These features are designed to:

Eliminate entire classes of vulnerabilities

Break exploitation techniques

Contain the damage and prevent persistence

Limit the window of opportunity to exploit

The following sections provide more detail about security mitigations in Windows 10, version 1703.

Windows 10 mitigations that you can configure

Windows 10 mitigations that you can configure are listed in the following two tables. The first table covers a wide array of protections for devices and users across the enterprise and the second table drills down into specific memory protections such as Data Execution Prevention. Memory protection options provide specific mitigations against malware that attempts to manipulate memory in order to gain control of a system.

Table 1В В Windows 10 mitigations that you can configure

Mitigation and corresponding threat	Description and links
Windows Defender SmartScreen helps prevent malicious applications from being downloaded	Windows Defender SmartScreen can check the reputation of a downloaded application by using a service that Microsoft maintains. The first time a user runs an app that originates from the Internet (even if the user copied it from another PC), SmartScreen checks to see if the app lacks a reputation or is known to be malicious, and responds accordingly. More information: Windows Defender SmartScreen, later in this topic
Credential Guard helps keep attackers from gaining access through Pass-the-Hash or Pass-the-Ticket attacks	Credential Guard uses virtualization-based security to isolate secrets, such as NTLM password hashes and Kerberos Ticket Granting Tickets, so that only privileged system software can access them. Credential Guard is included in Windows 10 Enterprise and Windows Server 2016. More information: Protect derived domain credentials with Credential Guard
Enterprise certificate pinning helps prevent man-in-the-middle attacks that leverage PKI	Enterprise certificate pinning enables you to protect your internal domain names from chaining to unwanted certificates or to fraudulently issued certificates. With enterprise certificate pinning, you can «pin» (associate) an X.509 certificate and its public key to its Certification Authority, either root or leaf. More information: Enterprise Certificate Pinning
Device Guard helps keep a device from running malware or other untrusted apps	Device Guard includes a Code Integrity policy that you create; an allowlist of trusted apps—the only apps allowed to run in your organization. Device Guard also includes a powerful system mitigation called hypervisor-protected code integrity (HVCI), which leverages virtualization-based security (VBS) to protect Windows’ kernel-mode code integrity validation process. HVCI has specific hardware requirements, and works with Code Integrity policies to help stop attacks even if they gain access to the kernel. Device Guard is included in Windows 10 Enterprise and Windows Server 2016. More information: Introduction to Device Guard
Microsoft Defender Antivirus, which helps keep devices free of viruses and other malware	Windows 10 includes Microsoft Defender Antivirus, a robust inbox antimalware solution. Microsoft Defender Antivirus has been significantly improved since it was introduced in Windows 8. More information: Microsoft Defender Antivirus, later in this topic
Blocking of untrusted fonts helps prevent fonts from being used in elevation-of-privilege attacks	Block Untrusted Fonts is a setting that allows you to prevent users from loading fonts that are «untrusted» onto your network, which can mitigate elevation-of-privilege attacks associated with the parsing of font files. However, as of Windows 10, version 1703, this mitigation is less important, because font parsing is isolated in an AppContainer sandbox (for a list describing this and other kernel pool protections, see Kernel pool protections, later in this topic). More information: Block untrusted fonts in an enterprise
Memory protections help prevent malware from using memory manipulation techniques such as buffer overruns	These mitigations, listed in Table 2, help to protect against memory-based attacks, where malware or other code manipulates memory to gain control of a system (for example, malware that attempts to use buffer overruns to inject malicious executable code into memory. Note: A subset of apps will not be able to run if some of these mitigations are set to their most restrictive settings. Testing can help you maximize protection while still allowing these apps to run. More information: Table 2, later in this topic
UEFI Secure Boot helps protect the platform from boot kits and rootkits	Unified Extensible Firmware Interface (UEFI) Secure Boot is a security standard for firmware built in to PCs by manufacturers beginning with Windows 8. It helps to protect the boot process and firmware against tampering, such as from a physically present attacker or from forms of malware that run early in the boot process or in kernel after startup. More information: UEFI and Secure Boot
Early Launch Antimalware (ELAM) helps protect the platform from rootkits disguised as drivers	Early Launch Antimalware (ELAM) is designed to enable the antimalware solution to start before all non-Microsoft drivers and apps. If malware modifies a boot-related driver, ELAM will detect the change, and Windows will prevent the driver from starting, thus blocking driver-based rootkits. More information: Early Launch Antimalware
Device Health Attestation helps prevent compromised devices from accessing an organization’s assets	Device Health Attestation (DHA) provides a way to confirm that devices attempting to connect to an organization’s network are in a healthy state, not compromised with malware. When DHA has been configured, a device’s actual boot data measurements can be checked against the expected «healthy» boot data. If the check indicates a device is unhealthy, the device can be prevented from accessing the network. More information: Control the health of Windows 10-based devices and Device Health Attestation

Configurable Windows 10 mitigations designed to help protect against memory manipulation require in-depth understanding of these threats and mitigations and knowledge about how the operating system and applications handle memory. The standard process for maximizing these types of mitigations is to work in a test lab to discover whether a given setting interferes with any applications that you use so that you can deploy settings that maximize protection while still allowing apps to run correctly.

As an IT professional, you can ask application developers and software vendors to deliver applications that include an additional protection called Control Flow Guard (CFG). No configuration is needed in the operating system—the protection is compiled into applications. More information can be found in Control Flow Guard.

Table 2В В Configurable Windows 10 mitigations designed to help protect against memory exploits

Mitigation and corresponding threat

Description

Data Execution Prevention (DEP) helps prevent exploitation of buffer overruns

Data Execution Prevention (DEP) is a system-level memory protection feature available in Windows operating systems. DEP enables the operating system to mark one or more pages of memory as non-executable, which prevents code from being run from that region of memory, to help prevent exploitation of buffer overruns. DEP helps prevent code from being run from data pages such as the default heap, stacks, and memory pools. Although some applications have compatibility problems with DEP, the vast majority of applications do not. More information: Data Execution Prevention, later in this topic.

Group Policy settings: DEP is on by default for 64-bit applications, but you can configure additional DEP protections by using the Group Policy settings described in Override Process Mitigation Options to help enforce app-related security policies. SEHOP
helps prevent
overwrites of the
Structured Exception Handler Structured Exception Handling Overwrite Protection (SEHOP) is designed to help block exploits that use the Structured Exception Handler (SEH) overwrite technique. Because this protection mechanism is provided at run-time, it helps to protect apps regardless of whether they have been compiled with the latest improvements. A few applications have compatibility problems with SEHOP, so be sure to test for your environment.
More information: Structured Exception Handling Overwrite Protection, later in this topic.

Group Policy setting: SEHOP is on by default for 64-bit applications, but you can configure additional SEHOP protections by using the Group Policy setting described in Override Process Mitigation Options to help enforce app-related security policies. ASLR
helps mitigate malware
attacks based on
expected memory locations Address Space Layout Randomization (ASLR) loads DLLs into random memory addresses at boot time. This helps mitigate malware that’s designed to attack specific memory locations, where specific DLLs are expected to be loaded.
More information: Address Space Layout Randomization, later in this topic.

Group Policy settings: ASLR is on by default for 64-bit applications, but you can configure additional ASLR protections by using the Group Policy settings described in Override Process Mitigation Options to help enforce app-related security policies.

Windows Defender SmartScreen

Windows Defender SmartScreen notifies users if they click on reported phishing and malware websites, and helps protect them against unsafe downloads or make informed decisions about downloads.

For WindowsВ 10, Microsoft improved SmartScreen (now called Windows Defender SmartScreen) protection capability by integrating its app reputation abilities into the operating system itself, which allows Windows Defender SmartScreen to check the reputation of files downloaded from the Internet and warn users when they’re about to run a high-risk downloaded file. The first time a user runs an app that originates from the Internet, Windows Defender SmartScreen checks the reputation of the application by using digital signatures and other factors against a service that Microsoft maintains. If the app lacks a reputation or is known to be malicious, Windows Defender SmartScreen warns the user or blocks execution entirely, depending on how the administrator has configured Microsoft Intune or Group Policy settings.

Microsoft Defender Antivirus

Microsoft Defender Antivirus in Windows 10 uses a multi-pronged approach to improve antimalware:

Cloud-delivered protection helps detect and block new malware within seconds, even if the malware has never been seen before. The service, available as of Windows 10, version 1703, uses distributed resources and machine learning to deliver protection to endpoints at a rate that is far faster than traditional signature updates.

Rich local context improves how malware is identified. Windows 10 informs Microsoft Defender Antivirus not only about content like files and processes but also where the content came from, where it has been stored, and more. The information about source and history enables Microsoft Defender Antivirus to apply different levels of scrutiny to different content.

Extensive global sensors help keep Microsoft Defender Antivirus current and aware of even the newest malware. This is accomplished in two ways: by collecting the rich local context data from end points and by centrally analyzing that data.

Tamper proofing helps guard Microsoft Defender Antivirus itself against malware attacks. For example, Microsoft Defender Antivirus uses Protected Processes, which prevents untrusted processes from attempting to tamper with Microsoft Defender Antivirus components, its registry keys, and so on. (Protected Processes is described later in this topic.)

Enterprise-level features give IT pros the tools and configuration options necessary to make Microsoft Defender Antivirus an enterprise-class antimalware solution.

For information about Microsoft Defender for Endpoint, a service that helps enterprises to detect, investigate, and respond to advanced and targeted attacks on their networks, see Microsoft Defender for Endpoint (resources) and Microsoft Defender for Endpoint (documentation).

Data Execution Prevention

Malware depends on its ability to insert a malicious payload into memory with the hope that it will be executed later. Wouldn’t it be great if you could prevent malware from running if it wrote to an area that has been allocated solely for the storage of information?

Data Execution Prevention (DEP) does exactly that, by substantially reducing the range of memory that malicious code can use for its benefit. DEP uses the No eXecute bit on modern CPUs to mark blocks of memory as read-only so that those blocks can’t be used to execute malicious code that may be inserted by means of a vulnerability exploit.

To use Task Manager to see apps that use DEP

Open Task Manager: Press Ctrl+Alt+Del and select Task Manager, or search the Start screen.

Click More Details (if necessary), and then click the Details tab.

Right-click any column heading, and then click Select Columns.

In the Select Columns dialog box, select the last Data Execution Prevention check box.

Click OK.

You can now see which processes have DEP enabled.

Figure 2.В В Processes on which DEP has been enabled in WindowsВ 10

You can use Control Panel to view or change DEP settings.

To use Control Panel to view or change DEP settings on an individual PC

Open Control Panel, System: click Start, type Control Panel System, and press ENTER.

Click Advanced system settings, and then click the Advanced tab.

In the Performance box, click Settings.

In Performance Options, click the Data Execution Prevention tab.

Select an option:

Turn on DEP for essential Windows programs and services only

Turn on DEP for all programs and services except those I select. If you choose this option, use the Add and Remove buttons to create the list of exceptions for which DEP will not be turned on.

To use Group Policy to control DEP settings

You can use the Group Policy setting called Process Mitigation Options to control DEP settings. A few applications have compatibility problems with DEP, so be sure to test for your environment. To use the Group Policy setting, see Override Process Mitigation Options to help enforce app-related security policies.

Structured Exception Handling Overwrite Protection

Structured Exception Handling Overwrite Protection (SEHOP) helps prevent attackers from being able to use malicious code to exploit the Structured Exception Handling (SEH), which is integral to the system and allows (non-malicious) apps to handle exceptions appropriately. Because this protection mechanism is provided at run-time, it helps to protect applications regardless of whether they have been compiled with the latest improvements.

You can use the Group Policy setting called Process Mitigation Options to control the SEHOP setting. A few applications have compatibility problems with SEHOP, so be sure to test for your environment. To use the Group Policy setting, see Override Process Mitigation Options to help enforce app-related security policies.

Address Space Layout Randomization

One of the most common techniques used to gain access to a system is to find a vulnerability in a privileged process that is already running, guess or find a location in memory where important system code and data have been placed, and then overwrite that information with a malicious payload. Any malware that could write directly to the system memory could simply overwrite it in well-known and predictable locations.

Address Space Layout Randomization (ASLR) makes that type of attack much more difficult because it randomizes how and where important data is stored in memory. With ASLR, it is more difficult for malware to find the specific location it needs to attack. Figure 3 illustrates how ASLR works by showing how the locations of different critical Windows components can change in memory between restarts.

Figure 3.В В ASLR at work

WindowsВ 10 applies ASLR holistically across the system and increases the level of entropy many times compared with previous versions of Windows to combat sophisticated attacks such as heap spraying. 64-bit system and application processes can take advantage of a vastly increased memory space, which makes it even more difficult for malware to predict where WindowsВ 10 stores vital data. When used on systems that have TPMs, ASLR memory randomization will be increasingly unique across devices, which makes it even more difficult for a successful exploit that works on one system to work reliably on another.

You can use the Group Policy setting called Process Mitigation Options to control ASLR settings («Force ASLR» and «Bottom-up ASLR»), as described in Override Process Mitigation Options to help enforce app-related security policies.

Mitigations that are built in to Windows 10

Windows 10 provides many threat mitigations to protect against exploits that are built into the operating system and need no configuration within the operating system. The table that follows describes some of these mitigations.

Control Flow Guard (CFG) is a mitigation that does not need configuration within the operating system, but does require that an application developer configure the mitigation into the application when it’s compiled. CFG is built into Microsoft Edge, IE11, and other areas in Windows 10, and can be built into many other applications when they are compiled.

Table 3  Windows 10 mitigations to protect against memory exploits – no configuration needed

Mitigation and corresponding threat	Description
SMB hardening for SYSVOL and NETLOGON shares helps mitigate man-in-the-middle attacks	Client connections to the Active Directory Domain Services default SYSVOL and NETLOGON shares on domain controllers now require SMB signing and mutual authentication (such as Kerberos).

More information: SMB hardening improvements for SYSVOL and NETLOGON shares, later in this topic. Protected Processes
help prevent one process
from tampering with another
process With the Protected Processes feature, Windows 10 prevents untrusted processes from interacting or tampering with those that have been specially signed.

More information: Protected Processes, later in this topic. Universal Windows apps protections
screen downloadable
apps and run them in
an AppContainer sandbox Universal Windows apps are carefully screened before being made available, and they run in an AppContainer sandbox with limited privileges and capabilities.

More information: Universal Windows apps protections, later in this topic. Heap protections
help prevent
exploitation of the heap Windows 10 includes protections for the heap, such as the use of internal data structures which help protect against corruption of memory used by the heap.

More information: Windows heap protections, later in this topic. Kernel pool protections
help prevent
exploitation of pool memory
used by the kernel Windows 10 includes protections for the pool of memory used by the kernel. For example, safe unlinking protects against pool overruns that are combined with unlinking operations that can be used to create an attack.

More information: Kernel pool protections, later in this topic. Control Flow Guard
helps mitigate exploits
that are based on
flow between code locations
in memory Control Flow Guard (CFG) is a mitigation that requires no configuration within the operating system, but instead is built into software when it’s compiled. It is built into Microsoft Edge, IE11, and other areas in Windows 10. CFG can be built into applications written in C or C++, or applications compiled using Visual Studio 2015.
For such an application, CFG can detect an attacker’s attempt to change the intended flow of code. If this occurs, CFG terminates the application. You can request software vendors to deliver Windows applications compiled with CFG enabled.

More information: Control Flow Guard, later in this topic. Protections built into Microsoft Edge (the browser)
helps mitigate multiple
threats Windows 10 includes an entirely new browser, Microsoft Edge, designed with multiple security improvements.

More information: Microsoft Edge and Internet Explorer 11, later in this topic.

SMB hardening improvements for SYSVOL and NETLOGON shares

In Windows 10 and Windows Server 2016, client connections to the Active Directory Domain Services default SYSVOL and NETLOGON shares on domain controllers require Server Message Block (SMB) signing and mutual authentication (such as Kerberos). This reduces the likelihood of man-in-the-middle attacks. If SMB signing and mutual authentication are unavailable, a computer running Windows 10 or Windows Server 2016 won’t process domain-based Group Policy and scripts.

The registry values for these settings aren’t present by default, but the hardening rules still apply until overridden by Group Policy or other registry values. For more information on these security improvements, (also referred to as UNC hardening), see Microsoft Knowledge Base article 3000483 and MS15-011 & MS15-014: Hardening Group Policy.

Protected Processes

Most security controls are designed to prevent the initial infection point. However, despite all the best preventative controls, malware might eventually find a way to infect the system. So, some protections are built to place limits on malware that gets on the device. Protected Processes creates limits of this type.

With Protected Processes, Windows 10 prevents untrusted processes from interacting or tampering with those that have been specially signed. Protected Processes defines levels of trust for processes. Less trusted processes are prevented from interacting with and therefore attacking more trusted processes. Windows 10 uses Protected Processes more broadly across the operating system, and as in Windows 8.1, implements them in a way that can be used by 3rd party anti-malware vendors, as described in Protecting Anti-Malware Services. This helps make the system and antimalware solutions less susceptible to tampering by malware that does manage to get on the system.

Universal Windows apps protections

When users download Universal Windows apps from the Microsoft Store, it’s unlikely that they will encounter malware because all apps go through a careful screening process before being made available in the store. Apps that organizations build and distribute through sideloading processes will need to be reviewed internally to ensure that they meet organizational security requirements.

Regardless of how users acquire Universal Windows apps, they can use them with increased confidence. Universal Windows apps run in an AppContainer sandbox with limited privileges and capabilities. For example, Universal Windows apps have no system-level access, have tightly controlled interactions with other apps, and have no access to data unless the user explicitly grants the application permission.

In addition, all Universal Windows apps follow the security principle of least privilege. Apps receive only the minimum privileges they need to perform their legitimate tasks, so even if an attacker exploits an app, the damage the exploit can do is severely limited and should be contained within the sandbox. The Microsoft Store displays the exact capabilities the app requires (for example, access to the camera), along with the app’s age rating and publisher.

Windows heap protections

The heap is a location in memory that Windows uses to store dynamic application data. WindowsВ 10 continues to improve on earlier Windows heap designs by further mitigating the risk of heap exploits that could be used as part of an attack.

WindowsВ 10 has several important improvements to the security of the heap:

Heap metadata hardening for internal data structures that the heap uses, to improve protections against memory corruption.

Heap allocation randomization, that is, the use of randomized locations and sizes for heap memory allocations, which makes it more difficult for an attacker to predict the location of critical memory to overwrite. Specifically, WindowsВ 10 adds a random offset to the address of a newly allocated heap, which makes the allocation much less predictable.

Heap guard pages before and after blocks of memory, which work as trip wires. If an attacker attempts to write past a block of memory (a common technique known as a buffer overflow), the attacker will have to overwrite a guard page. Any attempt to modify a guard page is considered a memory corruption, and WindowsВ 10 responds by instantly terminating the app.

Kernel pool protections

The operating system kernel in Windows sets aside two pools of memory, one which remains in physical memory («nonpaged pool») and one which can be paged in and out of physical memory («paged pool»). There are many mitigations that have been added over time, such as process quota pointer encoding; lookaside, delay free, and pool page cookies; and PoolIndex bounds checks. Windows 10 adds multiple «pool hardening» protections, such as integrity checks, that help protect the kernel pool against more advanced attacks.

In addition to pool hardening, Windows 10 includes other kernel hardening features:

Kernel DEP and Kernel ASLR: Follow the same principles as Data Execution Prevention and Address Space Layout Randomization, described earlier in this topic.

Font parsing in AppContainer: Isolates font parsing in an AppContainer sandbox.

Disabling of NTВ Virtual DOS Machine (NTVDM): The old NTVDM kernel module (for running 16-bit applications) is disabled by default, which neutralizes the associated vulnerabilities. (Enabling NTVDM decreases protection against Null dereference and other exploits.)

Supervisor Mode Execution Prevention (SMEP): Helps prevent the kernel (the «supervisor») from executing code in user pages, a common technique used by attackers for local kernel elevation of privilege (EOP). This requires processor support found in Intel Ivy Bridge or later processors, or ARM with PXN support.

Safe unlinking: Helps protect against pool overruns that are combined with unlinking operations to create an attack. Windows 10 includes global safe unlinking, which extends heap and kernel pool safe unlinking to all usage of LIST_ENTRY and includes the «FastFail» mechanism to enable rapid and safe process termination.

Memory reservations: The lowest 64 KB of process memory is reserved for the system. Apps are not allowed to allocate that portion of the memory. This makes it more difficult for malware to use techniques such as «NULL dereference» to overwrite critical system data structures in memory.

Control Flow Guard

When applications are loaded into memory, they are allocated space based on the size of the code, requested memory, and other factors. When an application begins to execute code, it calls additional code located in other memory addresses. The relationships between the code locations are well known—they are written in the code itself—but previous to Windows 10, the flow between these locations was not enforced, which gave attackers the opportunity to change the flow to meet their needs.

This kind of threat is mitigated in Windows 10 through the Control Flow Guard (CFG) feature. When a trusted application that was compiled to use CFG calls code, CFG verifies that the code location called is trusted for execution. If the location is not trusted, the application is immediately terminated as a potential security risk.

An administrator cannot configure CFG; rather, an application developer can take advantage of CFG by configuring it when the application is compiled. Consider asking application developers and software vendors to deliver trustworthy Windows applications compiled with CFG enabled. For example, it can be enabled for applications written in C or C++, or applications compiled using Visual Studio 2015. For information about enabling CFG for a Visual Studio 2015 project, see Control Flow Guard.

Of course, browsers are a key entry point for attacks, so Microsoft Edge, IE, and other Windows features take full advantage of CFG.

Microsoft Edge and Internet ExplorerВ 11

Browser security is a critical component of any security strategy, and for good reason: the browser is the user’s interface to the Internet, an environment with many malicious sites and content waiting to attack. Most users cannot perform at least part of their job without a browser, and many users are completely reliant on one. This reality has made the browser the common pathway from which malicious hackers initiate their attacks.

All browsers enable some amount of extensibility to do things beyond the original scope of the browser. Two common examples of this are Flash and Java extensions that enable their respective applications to run inside a browser. Keeping WindowsВ 10 secure for web browsing and applications, especially for these two content types, is a priority.

Windows 10 includes an entirely new browser, Microsoft Edge. Microsoft Edge is more secure in multiple ways, especially:

Smaller attack surface; no support for non-Microsoft binary extensions. Multiple browser components with vulnerable attack surfaces have been removed from Microsoft Edge. Components that have been removed include legacy document modes and script engines, Browser Helper Objects (BHOs), ActiveX controls, and Java. However, Microsoft Edge supports Flash content and PDF viewing by default through built-in extensions.

Runs 64-bit processes. A 64-bit PC running an older version of Windows often runs in 32-bit compatibility mode to support older and less secure extensions. When Microsoft Edge runs on a 64-bit PC, it runs only 64-bit processes, which are much more secure against exploits.

Includes Memory Garbage Collection (MemGC). This helps protect against use-after-free (UAF) issues.

Designed as a Universal Windows app. Microsoft Edge is inherently compartmentalized and runs in an AppContainer that sandboxes the browser from the system, data, and other apps. IE11 on WindowsВ 10 can also take advantage of the same AppContainer technology through Enhanced Protect Mode. However, because IE11 can run ActiveX and BHOs, the browser and sandbox are susceptible to a much broader range of attacks than Microsoft Edge.

Simplifies security configuration tasks. Because Microsoft Edge uses a simplified application structure and a single sandbox configuration, there are fewer required security settings. In addition, Microsoft Edge default settings align with security best practices, which makes it more secure by default.

In addition to Microsoft Edge, Microsoft includes IE11 in WindowsВ 10, primarily for backwards-compatibility with websites and with binary extensions that do not work with Microsoft Edge. It should not be configured as the primary browser but rather as an optional or automatic switchover. We recommend using Microsoft Edge as the primary web browser because it provides compatibility with the modern web and the best possible security.

For sites that require IE11 compatibility, including those that require binary extensions and plug-ins, enable Enterprise mode and use the Enterprise Mode Site List to define which sites have the dependency. With this configuration, when Microsoft Edge identifies a site that requires IE11, users will automatically be switched to IE11.

Functions that software vendors can use to build mitigations into apps

Some of the protections available in Windows 10 are provided through functions that can be called from apps or other software. Such software is less likely to provide openings for exploits. If you are working with a software vendor, you can request that they include these security-oriented functions in the application. The following table lists some types of mitigations and the corresponding security-oriented functions that can be used in apps.

Control Flow Guard (CFG) is also an important mitigation that a developer can include in software when it is compiled. For more information, see Control Flow Guard, earlier in this topic.

Table 4В В В Functions available to developers for building mitigations into apps

Mitigation	Function
MemProt dynamic code restriction	UpdateProcThreadAttribute function [PROCESS_CREATION_MITIGATION_POLICY_PROHIBIT_DYNAMIC_CODE_ALWAYS_ON]
LoadLib image loading restrictions	UpdateProcThreadAttribute function [PROCESS_CREATION_MITIGATION_POLICY_IMAGE_LOAD_NO_REMOTE_ALWAYS_ON]
Child Process Restriction to restrict the ability to create child processes	UpdateProcThreadAttribute function [PROC_THREAD_ATTRIBUTE_CHILD_PROCESS_POLICY]
Code Integrity Restriction to restrict image loading	SetProcessMitigationPolicy function [ProcessSignaturePolicy]
Win32k System Call Disable Restriction to restrict ability to use NTUser and GDI	SetProcessMitigationPolicy function [ProcessSystemCallDisablePolicy]
High Entropy ASLR for up to 1TB of variance in memory allocations	UpdateProcThreadAttribute function [PROCESS_CREATION_MITIGATION_POLICY_HIGH_ENTROPY_ASLR_ALWAYS_ON]
Strict handle checks to raise immediate exception upon bad handle reference	UpdateProcThreadAttribute function [PROCESS_CREATION_MITIGATION_POLICY_STRICT_HANDLE_CHECKS_ALWAYS_ON]
Extension point disable to block the use of certain third-party extension points	UpdateProcThreadAttribute function [PROCESS_CREATION_MITIGATION_POLICY_EXTENSION_POINT_DISABLE_ALWAYS_ON]
Heap terminate on corruption to protect the system against a corrupted heap	UpdateProcThreadAttribute function [PROCESS_CREATION_MITIGATION_POLICY_HEAP_TERMINATE_ALWAYS_ON]

Understanding Windows 10 in relation to the Enhanced Mitigation Experience Toolkit

You might already be familiar with the Enhanced Mitigation Experience Toolkit (EMET), which has since 2009 offered a variety of exploit mitigations, and an interface for configuring those mitigations. You can use this section to understand how EMET mitigations relate to those in Windows 10. Many of EMET’s mitigations have been built into Windows 10, some with additional improvements. However, some EMET mitigations carry high performance cost, or appear to be relatively ineffective against modern threats, and therefore have not been brought into Windows 10.

Because many of EMET’s mitigations and security mechanisms already exist in Windows 10 and have been improved, particularly those assessed to have high effectiveness at mitigating known bypasses, version 5.5x has been announced as the final major version release for EMET (see Enhanced Mitigation Experience Toolkit).

The following table lists EMET features in relation to Windows 10 features.

Table 5В В В EMET features in relation to Windows 10 features

Specific EMET features	How these EMET features map to Windows 10 features
ASLR (Force ASLR, Bottom-up ASLR) DEP, SEHOP and ASLR are included in Windows 10 as configurable features. See Table 2, earlier in this topic. You can install the ProcessMitigations PowerShell module to convert your EMET settings for these features into policies that you can apply to Windows 10. Load Library Check (LoadLib) Memory Protection Check (MemProt)	LoadLib and MemProt are supported in Windows 10, for all applications that are written to use these functions. See Table 4, earlier in this topic.
	Mitigations for this threat are built into Windows 10, as described in the «Memory reservations» item in Kernel pool protections, earlier in this topic.
	Windows 10 does not include mitigations that map specifically to these EMET features because they have low impact in the current threat landscape, and do not significantly increase the difficulty of exploiting vulnerabilities. Microsoft remains committed to monitoring the security environment as new exploits appear and taking steps to harden the operating system against them.
Simulate Execution Flow Deep Hooks (an ROP «Advanced Mitigation») Anti Detours (an ROP «Advanced Mitigation») Banned Functions (an ROP «Advanced Mitigation»)	Mitigated in Windows 10 with applications compiled with Control Flow Guard, as described in Control Flow Guard, earlier in this topic.

Converting an EMET XML settings file into Windows 10 mitigation policies

One of EMET’s strengths is that it allows you to import and export configuration settings for EMET mitigations as an XML settings file for straightforward deployment. To generate mitigation policies for Windows 10 from an EMET XML settings file, you can install the ProcessMitigations PowerShell module. In an elevated PowerShell session, run this cmdlet:

The Get-ProcessMitigation cmdlet gets the current mitigation settings from the registry or from a running process, or it can save all settings to an XML file.

To get the current settings on all running instances of notepad.exe:

To get the current settings in the registry for notepad.exe:

To get the current settings for the running process with pid 1304:

To get the all process mitigation settings from the registry and save them to the xml file settings.xml:

The Set-ProcessMitigation cmdlet can enable and disable process mitigations or set them in bulk from an XML file.

To get the current process mitigation for «notepad.exe» from the registry and then enable MicrosoftSignedOnly and disable MandatoryASLR:

To set the process mitigations from an XML file (which can be generated from get-ProcessMitigation -RegistryConfigFilePath settings.xml):

To set the system default to be MicrosoftSignedOnly:

The ConvertTo-ProcessMitigationPolicy cmdlet converts mitigation policy file formats. The syntax is:

Convert EMET settings to Windows 10 settings: You can run ConvertTo-ProcessMitigationPolicy and provide an EMET XML settings file as input, which will generate a result file of Windows 10 mitigation settings. For example:

Audit and modify the converted settings (the output file): Additional cmdlets let you apply, enumerate, enable, disable, and save settings in the output file. For example, this cmdlet enables SEHOP and disables MandatoryASLR and DEPATL registry settings for Notepad:

Convert Attack surface reduction (ASR) settings to a Code Integrity policy file: If the input file contains any settings for EMET’s Attack surface reduction (ASR) mitigation, the converter will also create a Code Integrity policy file. In this case, you can complete the merging, auditing, and deployment process for the Code Integrity policy, as described in Deploy Device Guard: deploy code integrity policies. This will enable protections on Windows 10 equivalent to EMET’s ASR protections.

Convert Certificate Trust settings to enterprise certificate pinning rules: If you have an EMET «Certificate Trust» XML file (pinning rules file), you can also use ConvertTo-ProcessMitigationPolicy to convert the pinning rules file into an enterprise certificate pinning rules file. Then you can finish enabling that file as described in Enterprise Certificate Pinning. For example:

EMET-related products

Microsoft Consulting Services (MCS) and Microsoft Support/Premier Field Engineering (PFE) offer a range of options for EMET, support for EMET, and EMET-related reporting and auditing products such as the EMET Enterprise Reporting Service (ERS). For any enterprise customers who use such products today or who are interested in similar capabilities, we recommend evaluating Microsoft Defender for Endpoint.