Challenges with enabling ASR rule - 'Block process creations originating from PSExec and WMI commands' on ConfigMgr clients

-
Last year I had posted a blog on enabling Attack Surface Reduction rules within Microsoft Defender for Endpoint using Intune. This time I will be covering a particular use case that involves one of the ASR rules 'Block process creations originating from PSExec and WMI commands' and challenges around enabling it on devices running ConfigMgr agent.

If you are managing ASR rules using Intune or another MDM provider, then there is little to no problem in enabling ASR rules. However, if you are managing the ASR rules using ConfigMgr or if your devices are running ConfigMgr client, then some of the ASR rules are not supported. 

I am currently working on an implementation project of Defender for Endpoint where devices are in Co-managed state and the ASR rules are being deployed using Intune. As part of testing, I enabled all the ASR rules and all of a sudden started to see application installations to fail. My first clue was  seeing 'Access denied' errors in Appenforce.log.



I checked in Microsoft Defender 365 Portal and noticed detections under Reports->Attack surface  reduction rules being reported. 


Unfortunately, the detection didn't give me any relevant details so I switched to good old Advanced Hunting to pull ASR device events.


The action type corresponds to the ASR rule 'Block process creations originating from PSExec and WMI commands'. On further investigation I stumbled upon Microsoft's official documentation & warning on this. 


As I see it, there are 3 ways to address this.

1. Disable the ASR rule altogether. 
2. Run the ASR rule in Audit mode and monitor the events for analysis. 
3. Based on the analysis of the ASR rule, add the necessary exclusions.

I decided to go with the 3rd option and add Msiexec, WMI processes to the existing exclusions I had put in place earlier. Now some may argue that it is not advisable to add these two in exclusions (to which I agree to some extent), but at the end it all boils down to your setup and business requirements. With having control over application installations through ConfigMgr and all Defender policies turned on the devices that are being used by users with Standard permissions, this seemed like a safe bet.


Once, I added the exclusions, there were no more ASR events generated for 'Block process creations originating from PSExec and WMI commands' rule in relation to Msiexec, WMI and application installations from ConfigMgr went through normally.


If you want to know the compatibility matrix for all the ASR rules then here is information provided by Microsoft.



Conclusion

Attack surface reduction rules that target executable files and scripts attempting to download\run files, can sometimes affect legitimate applications as well. I really hope that all ASR rules can become compatible across all deployment methods, especially ConfigMgr, but until this happens, it is important to run these rules in Audit mode first to access the impact of these rules and then add necessary exclusions to suit your business needs. 

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){                 $KPID=$KP.KeyProtectorId                 break;             }         }        $o
Read more

Intune: Configure Printers for Non-Administrative Users

-
Image
Configuring printers for end users or giving them the ability to do it themselves is a normal requirement for organizations. Now if your users are Administrators, then the configuration can be straight forward, but in case of Non-Administrators there are additional steps required as Non-Administrators will not be able to add a driver in the driver store despite being able to install a printer. In this blog, I will cover the steps that I took to address this requirement using Intune. The setup involves 2 steps -  1. Setup registries. 2. Install the driver and configure the printer Setting up registries – The registries that need to be configured are actually part of a GPO setting – Allow non-administrators to install drivers for these device setup classes It can be found under: Computer Configuration -> Policies -> Administrative Templates -> System -> Driver Installation I used a Powershell script to set the values and wrapped it in a Win32 application. $Path1
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from starting pr
Read more