Windows Defender Application Control
Windows Server 2019 includes a variety of new and existing technologies that you can use to secure the operating system. While implementing each of these technologies increases the security of your Windows Server 2019 deployment, it’s important to understand implementing no single technology or set of technologies guarantees that your deployment can’t be compromised by the most determined attackers. By implementing each technology, you will make Windows Server just a bit more difficult to compromise, thereby increasing the security of your organization’s Windows Server deployment.
Security Compliance Toolkit
The Security Compliance Toolkit (SCT) is a collection of tools that allow you to manage security configuration baselines for Windows Server and other Microsoft products. The SCT includes the Policy Analyzer tool and the Local Group Policy Object (LGPO) tool.
SCT provides security baselines for:
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows 10
Microsoft Office
Microsoft Edge
Policy Analyzer tool
The Policy Analyzer tool allows you to compare Group Policy Objects (GPOs). You can use the Policy Analyzer tool to perform the following tasks:
Determine which existing GPO settings are redundant or are internally consistent
Determine the differences between different versions or collections of group policies
Compare GPO settings against a computer’s local policy and registry settings
When downloading the SCT, you can also download security baseline GPOs. To perform an analysis of a system against a baseline, perform the following steps:
Open the Policy Analyzer and click Add to add downloaded baseline policies. You can specify a folder that contains multiple exported GPOs. When you do this, all exported GPOs under the selected folder path will be imported. Figure 20-1 shows the Policy File Importer with policies related to Windows Server selected for importing. After selecting which policies to import, click Import and save the selection of files as a policy rule.
Figure 20-1 Policy File Importer
You can then use the View/Compare button to compare policies and determine where they differ, as shown in Figure 20-2.
Figure 20-2 Security Configuration Toolkit Policy Viewer
You can use the Policy Analyzer to export this report into a format that can be viewed in Excel.
The Policy Analyzer is a reporting tool, and you cannot use it to directly apply policies. To apply policies, you can manually update GPO policies within your environment incrementally until they match the secure baseline. Taking an incremental approach allows you to test whether there are any unexpected consequences by applying new policies.
You should avoid simply importing the security baseline policies into Active Directory and applying them unless you want to spend the next few weeks or months figuring out exactly which new policy setting you applied caused problems with your organization’s existing workloads.
Local Group Policy Object tool
The local GPO tool is a command-line utility that allows you to perform local group policy operations against domain-joined and nondomain-joined computers. You can use the local GPO tool to perform the following tasks:
Import settings into a computer’s local group policy store from GPO backups
Import settings into a computer’s local Group Policy store from component files including Registry Policy (registry.pol), security templates, and advanced auditing CSV files
Export a computer’s local policy settings to a GPO backup
Enable the use of Group Policy client-side extensions when processing local policy
Extract a Registry Policy (registry.pol) file into a readable text format that can then be edited and built into a new registry.pol file with different settings
Attack Surface Analyzer
The Attack Surface Analyzer is a tool that allows you to locate possible security vulnerabilities by tracking changes made to the following:
File System
User Accounts
System Services
Network Ports (listeners)
System Certificate Stores
Windows Registry
To use the Attack Surface Analyzer, you first scan a system to determine the baseline settings of the system. You then perform another scan after you install software or suspect an unauthorized change has been made. The Attack Surface Analyzer will generate a report detailing any modifications made between the baseline and subsequent scans.
Once you’ve downloaded the Attack Surface Analyzer’s files from the project’s GitHub page, you run the Attack Surface Analyzer by opening an elevated command prompt and running the following command, which launches a web server that you can connect to at the address http://127.0.0.1:5000, as shown in Figure 20-3:
Asa.exe gui
Figure 20-3 Attack Surface Analyzer
Credential Guard
Credential Guard allows you to leverage virtualization-based security to isolate secrets, such as cached user credentials, in a special separate virtualized operating system. The special separate virtualized operating system is configured so that only specific processes and memory in the host operating system can access this secret data. The processes running in the separate virtualized operating system are termed trustlets.
Credential Guard is primarily a response to pass-the-hash or pass-the-ticket attacks. Should a host that has credential guard be compromised by an attacker, that attacker won’t be able to successfully run a pass-the-hash attack tool to extract cached credentials and then use them to access other computers on the network.
Credential Guard includes the following features and solutions:
Stores derived domain credentials in a virtualized environment that is protected from the running operating system.
You can manage Credential Guard by using Group Policy, Windows Management Instrumentation (WMI), or Windows PowerShell.
Credential Guard does not allow:
Unconstrained Kerberos delegation
NT LAN Manager version 1 (NTLMv1)
Microsoft Challenge Handshake Authentication Protocol (MS-CHAPv2)
Digest Authentication
Credential Security Support Provider (CredSSP)
Kerberos DES encryption
Credential Guard can be used in conjunction with the Protected Users group in a layered approach to the protection of highly privileged accounts. The Protected Users group remains useful because your organization might not have computers that support Credential Guard. You can deploy Credential Guard only on computers that meet certain hardware requirements. Credential Guard is primarily useful for Privileged Access Workstations, but you should implement it eventually on any computer where IT operations personnel use privileged domain accounts.
Credential Guard has the following requirements:
Windows Server 2019, Windows Server 2016, or Windows 10 Enterprise
UEFI firmware version 2.3.1 or higher
Secure Boot
Intel VT-x or AMD-V virtualization extensions
Second Level Address Translation
x64 processor architecture
A VT-d or AMD-Vi IOMMU input/output memory management unit
TPM 1.2 or 2.0
Secure firmware update process
Firmware updated to support Secure MOR implementation
To enable Credential Guard on an appropriately configured computer, you need to configure the Turn On Virtualization Based Security policy, which is located in the Computer ConfigurationAdministrative TemplatesSystemDevice Guard node of a GPO. This is the same policy that you also use to configure Windows Defender Application Control (previously known as Device Guard), which you learn about later in this chapter.
While configuring this policy, you must first set the policy to Enabled, and then you must set the platform security level to either Secure Boot or to Secure Boot And DMA Protection. Secure Boot And DMA Protection ensures that Credential Guard is used with Direct Memory Access protection.
Once this is done, you need to then set the Credential Guard Configuration option to Enabled With UEFI Lock or Enabled Without Lock. If you set the Enabled With UEFI Lock, Credential Guard cannot be remotely disabled and can only be disabled by having someone with local Administrator privileges sign on and disable Credential Guard configuration locally. The Enabled Without Lock option allows Credential Guard to be remotely disabled.
Windows Defender Application Control
Windows Defender Application Control (WDAC), known in previous versions of Windows Server as Device Guard and Configurable Code Integrity (CCI) policies, is a hardware- and software-based security system that restricts the execution of applications to those that are explicitly trusted. WDAC uses virtualization-based security to isolate a special service named the code integrity service from the Windows kernel. Because the code integrity service is running as a trustlet in a special virtualized location, compromising the service is difficult, if not impossible, even if an attacker has complete control of the operating system. The WDAC name isn’t present in all locations of the operating system, such as group policy, so occasionally you will still see references to Device Guard in items such as Group Policy.
WDAC includes the following features:
Virtual Secure Mode. This is a special virtual container that isolates the LSASS.exe process from the operating system.
Configurable Code Integrity. This is the rules engine that, in conjunction with Virtual Secure Mode Protected Code Integrity, validates code that Windows Server attempts to enact.
Virtual Secure Mode Protected Code Integrity. This uses two components to enforce Configurable Code Integrity policy:
User Mode Code Integrity manages whether user mode code can execute.
Kernel Mode Code Integrity manages whether kernel mode code can execute.
Platform and UEFI Secure Boot. This ensures that the boot loader code and firmware are validated and prevents malware from modifying the boot environment.
To enable Virtual Secure Mode, perform the following steps:
Enable Secure Boot and Trusted Platform Module (TPM).
Enable Hyper-V.
Enable Isolated User Mode.
Configure the Turn On Virtualization Based Security Policy, located in the Computer ConfigurationAdministrative TemplatesSystemDevice Guard node.
Configure the BCD store to start Virtual Secure Mode. You do this by running the following command:
bcdedit /set vsmlaunchtype auto
By default, WDAC runs in Audit Mode. This allows you to tune a policy to ensure that the software that you want to run can run and won’t be blocked. You have several options when it comes to controlling which software can run on a computer protected by Device Guard. These are as follows:
Only allow software that is digitally signed by a trusted publisher to run on the server. If you are using internally written code, you can use your organization’s code signing certificate to digitally sign code. You use the New-CIPolicy cmdlet to create an XML file with all relevant details about signed files on a system, and then use the ConvertFrom-CIPolicy cmdlet to convert this XML file into a binary file that is placed in the C:WindowsSystem32CodeIntegrity folder and can be used by Device Guard to determine which software can run on the protected system.
Use Package Inspector to create a catalog of all deployed and executed binary files for applications that you trust. You can use this when you need to deal with third-party applications that you trust but are not digitally signed. Package Inspector is included with the operating system and is located in the C:WindowsSystem32 directory. Package Inspector creates a catalog of hash files for each binary executable. Once the catalog file is created, you can digitally sign the catalog using signtool.exe, which is available in the Windows Software Development Kit (SDK) that you can download from Microsoft’s website. Ensure that the signing certificate is added to the code integrity policy. WDAC blocks any software that is not in the signed catalog from running. You can use Group Policy and Configuration Manager to deploy code integrity policies and catalog files.
You can deploy WDAC on a test machine using the Device Guard and Credential Guard Readiness Tool. (The tool still uses the previous name for WDAC.) This tool assesses a computer’s readiness to be configured for WDAC and allows you to perform a test deployment. Test deployments are important because you don’t want to deploy WDAC and then find that business-critical software can no longer execute.
Once you’ve verified that a computer is ready for WDAC, you configure the Turn On Virtualization Based Security policy, located in the Computer ConfigurationPoliciesAdministrative TemplatesSystemDevice Guard section of a GPO and configure the policy so that the Virtualization Based Protection of Code Integrity is set to either Enabled With UEFI Lock, or Enabled Without Lock. The difference is that if you use the Enabled With UEFI Lock, as shown in Figure 20-4, the policy can only be disabled by signing in directly to the server.
Figure 20-4 Turn On Virtualization Based Security
Virtualization-based security
Virtualization-based security allows Windows Server to use hardware virtualization to isolate and protect an area of computer memory from typical operating system processes. This “virtual secure mode” blocks malicious code from inserting itself into other high integrity processes. You can enable virtualization-based security in the Windows Security app, as shown in Figure 20-5.
Figure 20-5 Enable virtualization-based security
Controlled Folder Access
Controlled Folder Access is a security technology that allows you to protect specific folders on a Windows Server computer against malicious software. Controlled Folder Access is a useful tool for preventing ransomware from encrypting the folders that host file shares because you can use it to restrict which software can interact with specific paths on a computer running Windows Server 2019. Controlled Folder Access will allow trusted applications, such as those that are included with the operating system, to interact with protected folders.
On computers running Windows Server with Desktop Experience, you can use the Virus & Threat Protection area of the Windows Security control panel to configure which folders are protected and which applications can interact with protected folders, as shown in Figure 20-6.
Figure 20-6 Controlled Folder Access
You can configure Controlled Folder Access from PowerShell using the Set-MpPreference cmdlet. To enable controlled folder access, run this command:
Set-MpPreference -EnableControlledFolderAccess Enabled
To disable Controlled Folder Access, run this command:
Set-MpPreference -EnableControlledFolderAccess Disabled
To add a new location for Controlled Folder Access to monitor, run this command:
Add-MpPreference -ControlledFolderAccessProtectedFolders “E:fileshare”
To remove a location from Controlled Folder Access monitoring, run this command:
Remove-MpPreference -ControlledFolderAccessProtectedFolders “E:fileshare”
To allow an application to interact with a protected folder, run this command:
Add-MpPreference -ControlledFolderAccessAllowedApplications “c:applicationapp.exe”
You can also use the Remove-MpPreference cmdlet to revoke an application’s ability to interact with a protected location.
Exploit Protection
Exploit Protection allows you to configure extra security settings for Windows Server, such as Control Flow Guard (CFG) and Data Execution Prevention (DEP). In past versions of Windows Server, you would use the Enhanced Mitigation Experience Toolkit (EMET), a separate product that you download and install to perform this task. Figure 20-7 shows the Exploit Protection settings in the Windows Security Control Panel app.
Figure 20-7 Exploit Protection
Some Exploit Protection mitigation settings are configurable at the system level, and some are only configurable on a per-app basis. The settings that can be configured at both the system and app level are as follows:
Control Flow Guard. Configurable at the system and program level. Ensures control flow integrity for indirect calls.
Data Execution Prevention. Configurable at the system and program level. Prevents code from being executed from data-only memory pages.
Force Randomization For Images (Mandatory ASLR). Configurable at the system and the program level. Forces reallocation of memory images that haven’t been compiled with the DYNAMICBASE option.
The settings that you can only configure at the application level are as follows:
Arbitrary Code Guard. Prevent non-image backed executable code and code page modification
Block Low Integrity Images. Block the loading of images marked with low integrity
Block Remote Images. Block the loading of images from remote devices
Block Untrusted Fonts. Block the loading of any GDI-based fonts not installed in the system Fonts directory
Code Integrity Guard. Restrict the loading of images to those that have been digitally signed by Microsoft
Disable Extension Points. Disable extensibility mechanisms that allow DLL injection into all processes
Disable Win32k System Calls. Block programs from using the Win32K system call table
Do Not Allow Child Processes. Prevent programs from spawning child processes
Export Address Filtering (EAF). Filter dangerous exported functions that are being resolved by malicious code
Import Address Filtering (IAF). Filter imported functions being resolved by malicious code
Randomize Memory Allocations (Bottom-Up ASLR). Randomize locations for virtual memory allocation
Simulate Execution (SimExec). Ensure that calls to sensitive functions are returned to legitimate callers
Validate API Invocation (CallerCheck). Ensure that sensitive APIs can only be invoked by legitimate callers
Validate Exception Chains (SEHOP). Ensures the integrity of an exception chain during dispatch
Validate Handle Usage. Raises an exception on any invalid handle references
Validate Heap Integrity. Terminates a program when heap corruption is detected
Validate Image Dependency Integrity. Enforces code signing for Windows image dependency loading
Validate Stack Integrity (StackPivot). Ensures that the stack has not been redirected for sensitive functions
You configure exploit protection from PowerShell using the Set-ProcessMitigation cmdlet. For example, to enable Data Execution Prevention (DEP) at the system level, you would run the command:
Set-ProcessMitigation -System -Enable DEP
You can view which exploit protection settings are enabled by running the following command:
Get-ProcessMitigation -System
You can use the following command to export an Exploit Guard configuration:
Get-ProcessMitigation -RegistryConfigFilePath exportedconfig.xml
You can import an exported Exploit Guard configuration by using the following command:
Set-ProcessMitigation -PolicyFilePath exportedconfig.xml
Windows Defender
Windows Server 2019 includes Windows Defender, the Microsoft antimalware solution. Windows Defender is enabled by default when you deploy Windows Server 2019. To disable Windows Defender, you must remove it, either by using the Add Roles And Features Wizard or by using the following Uninstall-WindowsFeature command:
Uninstall-WindowsFeature -Name Windows-Server-Antimalware
You can use the following PowerShell cmdlets to manage Windows Defender on computers running the GUI or the Server Core version of Windows Server 2019:
Add-MpPreference. Modifies Windows Defender settings
Get-MpComputerStatus. View the status of antimalware software on the server
Get-MpPreference. View the Windows Defender preferences for scans and updates
Get-MpThreat. View the history of malware detected on the computer
Get-MpThreatCatalog. Get known threats from the definitions catalog. You can use this list to determine whether a specific threat is known to Windows Defender
Get-MpThreatDetection. Lists active and past threats that Windows Defender has detected on the computer
Remove-MpPreference. Removes an exclusion or default action
Remove-MPThreat. Removes an active threat from the computer
Set-MpPreference. Allows you to configure scan and update preferences
Start-MpScan. Starts an antimalware scan on a server
Start-MpWDOScan. Triggers a Windows Defender offline scan
Update-MpSignature. Triggers an update for antimalware definitions
Windows Defender SmartScreen
Windows Defender SmartScreen, shown in Figure 20-8, provides you with a way of checking unrecognized files that have been downloaded to Windows Server against the properties of known malicious files that are stored in the Microsoft Graph security database. A good general security rule is to avoid downloading application files directly from the Internet and installing them on Windows Server; instead, you should download them to a separate location, test them, and then copy them remotely to Windows Server for installation.
Figure 20-8 Windows Defender SmartScreen