The configuration of Microsoft Defender Antivirus and Microsoft Defender for Endpoint can be retrieved using different methods. For the assessment with HardeningKitty the registry is queried on the one hand and the PowerShell cmdlet Get-MpPreference is used on the other hand. The advantage of the PowerShell cmdlet is that the cmdlet itself takes care of where the settings are located, and which value is valid if there are multiple configuration settings. If it is necessary to check which value has been defined by a management solution, the registry must be used.

Microsoft Intune was introduced in 2010 and is Microsoft’s Endpoint Manager for Android, iOS, macOS and Windows operating systems. Intune does not require an on-premise infrastructure and administration is done via a web interface. With the increasing use of cloud services, we are also seeing a shift from Group Policy Management to Intune for managing Windows clients.

Traditionally, settings are deployed to systems via Group Policy Management. In the registry, these settings are stored under the path HKLM:\Software\Policies\Microsoft\*. Intune also stores the settings in the registry but uses different paths and keys. This leads to changes when analysing the Defender configuration and even has implications for the security of the system.

Attack Surface Reduction Rules

One feature of Microsoft Defender for Endpoint is the attack surface reduction ruleset, which was introduced in the Labs article on April 23, 2020. Each rule is given a GUID, and the list of all rules is located under the Attack surface reduction (ASR) rules reference.

As an example, the rule Block all Office applications from creating child processes with the GUID d4f940ab-401b-4efc-aadc-ad5f3c50688a is used. This GUID can be used to query the mode of the rule in the registry. If the rules were configured using group policies, each rule has its own key.

PS C:\Users\admin> Get-ItemPropertyValue -Path "HKLM:\Software\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\rules" -Name "d4f940ab-401b-4efc-aadc-ad5f3c50688a"
1

The value of the key d4f940ab-401b-4efc-aadc-ad5f3c50688a is 1, which means that the mode of the rule is block. The mode of the full set of rules can be queried by enumerating all GUID keys.

However, if the ruleset was configured with Intune, there are no entries under this path. Intune stores the configuration in the ASRRules key under the path HKLM:\Software\Policies\Microsoft\Windows Defender\Policy Manager. All rules are stored in a key in the format GUID=Setting|GUID=Setting. Therefore, for the analysis with HardeningKitty a parsing of the settings is necessary to find the mode for a specific rule:

$ResultAsr = $Result.Split("|")
ForEach ($AsrRow in $ResultAsr) {
  $AsrRule = $AsrRow.Split("=")
  If ($AsrRule[0] -eq $Finding.MethodArgument) {
    $Result = $AsrRule[1]
    Break
  } Else {
    $Result = $Finding.DefaultValue
  }
}

It must be known which management solution is used in order to retrieve the configuration of ASR rules from the registry. This also has an impact on frameworks such as CIS Benchmark or Microsoft Security Baselines. Both use the Group Policy path for the ASR rules, which can lead to inaccurate results on a system configured with Intune.

Instead of the registry, the earlier mentioned PowerShell cmdlet Get-MpPreference can be used for analysis. The cmdlet should be able to get the settings regardless of the management solution.

Exclusions in Microsoft Defender Antivirus

The exclusions of Microsoft Defender Antivirus are an interesting target during the information gathering phase of an attack. That is why Microsoft had introduced the change in Windows 11 in February 2022 that makes reading exclusions more difficult. It should no longer be possible to read the exclusions without administration rights. This was later ported to Windows 10 as well.

For Microsoft Defender Antivirus, there are three exclusions settings:

• ExclusionExtension
• ExclusionPath
• ExclusionProcess

Getting the exclusions with Get-MpPreference as user fails:

PS C:\Users\chuck> $DefenderSettings = Get-MpPreference
PS C:\Users\chuck> $DefenderSettings.ExclusionPath
N/A: Must be and administrator to view exclusions

The configuration of the antivirus can be retrieved, but the three exclusion parameters do not contain any results. When the same report is run with administrator privileges, the exclusions are listed:

PS C:\Users\admin> $DefenderSettings = Get-MpPreference
PS C:\Users\admin> $DefenderSettings.ExclusionPath
C:\Users\admin\Apps
C:\LegacyBusinessApp
C:\Temp\insecure

Three exclusions are configured on the system. If users have write permissions in one of the directories, this can be used to bypass the antivirus’s file scanning engine. However, as long as the user does not have administrator rights, the setting and thus this list of directories remains unknown.

Instead of the PowerShell cmdlet, the exclusion can also be found in the registry. If the Defender configuration is done via group policies, the settings can be accessed via the following path:

PS C:\Users\chuck> $DefenderSettingsRegistry = Get-ChildItem -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\"

Get-ChildItem : Requested registry access is not allowed.
At line:1 char:29
+ ... sRegistry = Get-ChildItem -Path "HKLM:\SOFTWARE\Policies\Microsoft\Wi ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (HKEY_LOCAL_MACH...der\Exclusions\:String) [Get-ChildItem], SecurityException
    + FullyQualifiedErrorId : System.Security.SecurityException,Microsoft.PowerShell.Commands.GetChildItemCommand

However, the access rights of the registry key have been modified so that a user has no rights to read them. The query is successful as an administrator:

PS C:\Users\admin> $DefenderSettingsRegistry = Get-ChildItem -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\"
PS C:\Users\admin> $DefenderSettingsRegistry.Property
C:\Users\admin\Apps
C:\LegacyBusinessApp
C:\Temp\insecure

The access control for antivirus exclusion rules has been implemented consistently, neither via the registry nor via the PowerShell cmdlet can a user get the configured exclusions.

If the system has been configured with Intune, the situation changes. Similar to the ASR ruleset, the antivirus settings are stored under a different registry path. It turns out that access rights to the exclusions registry keys were not implemented so strictly, and a user can access all exclusion lists.

PS C:\Users\chuck> Get-ItemPropertyValue -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Policy Manager" -Name "ExcludedPaths"
C:\Users\admin\Apps|C:\LegacyBusinessApp|C:\Temp\insecure

When implementing Microsoft Intune and defining the registry paths for Microsoft Defender Antivirus, they forgot to harden the access rights to the exclusion registry keys. Therefore, a user can extract all exclusion lists. This information leakage vulnerability was possible in December 2022; Microsoft may have hardened the access rights later.

AppLocker Policy

A system’s AppLocker policy can be retrieved using the Get-AppLocker-Policy PowerShell cmdlet. This is only possible on a system that has been configured via Group Policy. On a system that is managed by Intune, the query does not return any values.

However, on a system managed by Intune, it is possible to read the AppLocker policy definition files under the path C:\Windows\System32\AppLocker\MDM\*. Among other things, the policy is stored as an XML file in this directory. This allows the AppLocker policy to be accessed unnoticed if only the call to Get-AppLocker-Policy is monitored.

Conclusion

It depends on the management solution under which registry paths and keys, and in which format the configuration settings of Microsoft Defender are stored. Microsoft chose new paths and a different format for Intune, which has implications when assessing the settings for documentation or hardening benchmarks. Microsoft has failed to harden the access rights for the Defender exclusions registry keys used by Intune, introducing an information leakage vulnerability. This vulnerability must be fixed by Microsoft, we do not recommend modifying the access rights of those registry keys. The vulnerability is an example of the risks of software development when different teams are working on the same product and there is no two-way information sharing. Ideally, there is an exchange throughout the development, but at the latest before the release, security-relevant aspects should be thoroughly reviewed.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• https://github.com/scipag/HardeningKitty
• https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/?view=o365-worldwide
• https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference
• https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/microsoft-defender-antivirus-windows
• https://learn.microsoft.com/en-us/powershell/module/applocker/get-applockerpolicy
• https://learn.microsoft.com/en-us/powershell/module/defender/get-mppreference
• https://windowsreport.com/microsoft-makes-defender-exclusions-more-difficult/
• https://www.microsoft.com/en-us/security/business/endpoint-management/microsoft-intune