IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Hello, Paul Bergson back again with a discussion on the newly built-in memory protection features provided in Windows 10 and Windows Server 2016. I refer to Win10 throughout the document, but this is just for brevity sake.
For a complete discussion on how to “Migrate threats by using Windows 10 security features” please see the below link.
With the Enhanced Mitigation Experience Toolkit (EMET) being sunset, folks are wondering what the next steps are to protect from malware attacking memory. EMET’s current support is set to expire on August 1, 2018. EMET version 5.52 has features that still don’t reside in Windows 10, so it is recommended to continue to use EMET within your infrastructure. *21
EMET provided the ability to protect memory corruption attacks against individual applications. When software was created, it may not have been built to work with specific memory protection features, so having a defensive mechanism (software) to force these protections on all applications, could render the some of the applications unusable. What EMET did was allow protective controls over individual applications (via shims) therefore allowing an administrator to pick and choose which protection features to apply against individual applications. As EMET begins to age, we have begun to build into the o/s, the features that EMET has provided in the past. “Moving Beyond EMET” *22
With EMET there was a front-end GUI that could be used to control individual desktops but if an enterprise wanted to manage large volumes of desktops, a singular GUI approach wouldn’t scale well. Therefore, as we build the new memory protection features into the operating system we look to provide manageability with application specified protection and GPO’s.
Some of the memory protection features for Windows 10 don’t require any configuration from the device administrators, since the application can be configured to leverage memory protection features with the simple selection within the source code. Software developers have had the option to enable Control Flow Guard since Microsoft released Visual Studio 2015.
“Control Flow Guard (CFG) is a highly-optimized platform security feature that was created to combat memory corruption vulnerabilities. By placing tight restrictions on where an application can execute code from, it makes it much harder for exploits to execute arbitrary code through vulnerabilities such as buffer overflows. CFG extends previous exploit mitigation technologies such as /GS, DEP, and ASLR.” *23
There is no need (in most instances) for your developers to modify the source code, all that is required is to enable the CFG option and recompile the code.
So how does CFG work?
In simplistic terms, at compile time there is a bit map table built of all the legitimate target locations the code can jump too. During the execution of the application, whenever there is a call to jump to a new target location, CFG verifies that the new location was in the bit map table of valid jump locations. If the requested jump location is not listed in the “Valid Jump Locations”, Windows terminates the process thereby preventing the malware from executing.
If you want to know which applications have enabled CFG on your system (Windows 10), you can start up SysInternals ProcessExplorer (v16.20). By default, the column “Control Flow Guard” isn’t displayed so it will have to be added. View / Select Columns / Process Image (tab) – Select “Control Flow Guard”.
Under the “Control Flow Guard” column, there are three values that are possible:
- Blank – Not enabled
- CFG – Enabled
- n/a – Not applicable
If the application, you want to use doesn’t have CFG enabled there are “Post Compile” fixes available within the Windows 10 operating system (Win10 1607). Specifically, there are two GPO settings within the “Mitigation Options” that can be configured.
The GPO policy settings can be found at:
computer configuration\administrative templates\system\Mitigation Options
“Untrusted Font Blocking” is the first setting, which provides a global setting to prevent programs from loading untrusted fonts. Untrusted fonts are any font installed outside of the %windir%\Fonts directory. This feature can be configured to be in 3 modes: On, Off, and Audit. By default, it is Off and no fonts are blocked. If you aren’t quite ready to deploy this feature into your organization, you can run it in Audit mode to see if blocking untrusted fonts causes any usability or compatibility issues. If you are also using EMET, it is recommended to use the Windows 10 “Untrusted Font Blocking” setting over EMET’s.
The second GPO configurable setting has 6 manageable memory protection features available to apply against any process on the Win10 operating system. These 6 (A-F) settings are a part of a 32 bit, bit mask shown in the figure below. These 6 mitigations were considered the ones to be the most impactful on the system and as you can see there is plenty of growth opportunities for future protection options.
The six settings in this topic are related to three types of process mitigations. In Windows 10, all three types are on by default for 64-bit applications, but by using the Group Policy settings described in this topic, you can configure these additional protection options. *25
- Data Execution Prevention (DEP)
- Structured Exception Handling Overwrite Protection (SEHOP)
- Address Space Layout Randomization (ASLR)
The “Process Mitigation Options” security feature provides a means to override individual process MitigationOptions settings. This can be used to enforce a number of security policies specific to applications. The application name is specified as the Value name, including extension. The Value is specified as a bit field with a series of flags in particular positions. Bits can be set to either 0 (setting is forced off), 1 (setting is forced on), or ? (setting retains its existing value prior to GPO evaluation). The recognized bit locations are:
Enables data execution prevention (DEP) for the child process
Enables DEP-ATL thunk emulation for the child process. DEP-ATL thunk emulation causes the system to intercept NX faults that originate from the Active Template Library (ATL) thunk layer.
Enables structured exception handler overwrite protection (SEHOP) for the child process. SEHOP blocks exploits that use the structured exception handler (SEH) overwrite technique.
The force Address Space Layout Randomization (ASLR) policy forcibly rebases images that are not dynamic base compatible by acting as though an image base collision happened at load time. If relocations are required, images that do not have a base relocation section will not be loaded.
The bottom-up randomization policy, which includes stack randomization options, causes a random location to be used as the lowest user address.
The CFG policy is per application, similar to how EMET is configured, in that to apply against an application (remember by default it is applied against all 64 bit applications) you must define the application within the policy.
Enable – PROCESS_CREATION_MITIGATION_POLICY_DEP_ENABLE
Enable – PROCESS_CREATION_MITIGATION_POLICY_FORCE_RELOCATE_IMAGES_ALWAYS_ON
Disable – PROCESS_CREATION_MITIGATION_POLICY_BOTTOM_UP_ASLR_ALWAYS_OFF
Leave all other options at their default values, specify a value of:
Setting flags not specified here to any value other than “?” results in undefined behavior.
To help understand how EMET mitigations are being built into Windows 10, there is a matrix (below) to show the progress we are making. As the operating system moves forward, we will continue to improve the protection to help our customers with “legacy” apps that cannot be recompiled for CFG.
Certificate Pinning wasn’t a memory protection feature, but EMET provided this to help protect against Man-in-the-Middle attacks.
“Enterprise certificate pinning is a Windows feature for remembering, or “pinning,” a root issuing certificate authority or end entity certificate to a given domain name. Enterprise certificate pinning helps reduce man-in-the-middle attacks by enabling you to protect your internal domain names from chaining to unwanted certificates or to fraudulently issued certificates.”
“…restrictions are encapsulated in a Pin Rules Certificate Trust List (CTL) that is configured and deployed to Windows 10 computers. Any site certificate triggering a name mismatch causes Windows to write an event to the CAPI2 event log and prevents the user from navigating to the web site using Microsoft Edge or Internet Explorer.” *26
Windows 10 GA initially just provided logging capabilities, but with “Creators Update” administrators can now block sites with certificate errors.
For complete details on how to deploy enterprise certificate pinning, please see link reference 26 below.
I would strongly recommend you read the page “Migrate threats by using Windows 10 security” referenced above, as well as the resource links found throughout this document.
Hopefully you found this Blog article useful and enjoy the linked reading.
Win10 1607 Anniversary Update
Win10 1703 Creators Update
Win10 1607+EMET Anniversary Update
|Default Enabled System Mitigation|
|Kernel pool hardening ||Y||No Change||Y||Y||No Change|
|Kernel ASLR (images) ||Y||No Change||Y||Y||No Change|
|Fonts (usermode appcontainer) ||N||N||Y||Y||No Change|
|NTVDM disabled ||N||N||Y||Y||No Change|
|Kernel ASLR (full) ||N||N||Y||Y||No Change|
|Kernel DEP ||N||N||Y||Y||No Change|
|Kernel pool hardening (extended) ||N||N||Y||Y||No Change|
|SMEP ||N||N||Y||Y||No Change|
|Global safe unlinking ||N||N||Y||Y||No Change|
|Improved ASLR entropy ||N||N||Y||Y||No Change|
|Opt-In System Mitigation|
|Fonts (block untrusted)||N||N||Y ||Y||Y|
|VBS – HyperGuard (protect MSR/SMEP)||N||N||Y||Y||No Change|
|VBS – HVCI (kernel CI)||N||N||Y||Y||No Change|
|VBS – Credential Guard||N||N||Y||Y||No Change|
|VBS – Device Guard||N||N||Y||Y||No Change|
|Default Enabled Application Mitigation|
|Heap metadata hardening ||Y||Y||Y||Y||No Change|
|Heap metadata hardening (extended) ||N||N||Y||Y||No Change|
|Heap allocation randomization ||N||N||Y||Y||No Change|
|Heap guard pages ||N||N||Y||Y||No Change|
|AppContainer symbolic link hardening ||N||N||Y||Y||No Change|
|Opt-In Application Mitigation|
|NullPage||N||Y||Y||Y||No Change |
|Force ASLR ||N||Y||Y||Y||Y|
|LoadLib (Image Load Restriction)||N||Y||Y ||Y ||Y|
|MemProt (Dynamic Code Restriction)||N||Y||Y ||Y ||Y|
|Fonts (block untrusted)||N||N||Y ||Y ||No Change |
|Child Process Restriction ||N||N||Y||Y||No Change|
|Code Integrity Restriction ||N||N||Y||Y||No Change|
|Win32k System Call Disable Restriction ||N||N||Y||Y||No Change|
|High Entropy ASLR ||N||N||Y||Y||No Change|
|Strict handle checks ||N||N||Y||Y||No Change|
|Extension point disable ||N||N||Y||Y||No Change|
|Heap terminate on corruption ||N||N||Y||Y||No Change|
- Fonts https://technet.microsoft.com/en-us/itpro/windows/keep-secure/block-untrusted-fonts-in-enterprise
- Force Application Mitigation-Fonts row should show as no/red in the Windows 10 + EMET column, as the ability to configure the Untrusted Fonts mitigation for specific applications has been disabled in EMET
- From 1510
- See UpdateProcThreadAttribute documentation for PROCESS_CREATION_MITIGATION_POLICY_HIGH_ENTROPY_ASLR_ALWAYS_ON
- See UpdateProcThreadAttribute documentation for PROCESS_CREATION_MITIGATION_POLICY_STRICT_HANDLE_CHECKS_ALWAYS_ON
- See UpdateProcThreadAttribute documentation for PROCESS_CREATION_MITIGATION_POLICY_EXTENSION_POINT_DISABLE_ALWAYS_ON
- See UpdateProcThreadAttribute documentation for PROCESS_CREATION_MITIGATION_POLICY_HEAP_TERMINATE_ALWAYS_ON
- The NULL page mitigation provided by the OS (enabled by default) obsoletes the EMET NULL page mitigation, see 
- CFG must be enabled by the application and cannot be forced-on
Special thanks to Jeffrey Sutherland, for his invaluable content contribution!