Forum Discussion
Removing attack surface reduction rules not possible
Hi
We have implemented attack surface reduction rules in my company on all windows 10 pc's.
We audited for a few months and created exclusions which worked well.
Now we have a new program that is being blocked by the MacroWin32ApiCall rule, and even using exclusions we cannot get the program to stop being blocked.
So we simply want to remove this MacroWin32 ASR rule from a machine. We enabled it through SCCM with a big policy containing all PC's.
When we remove this particular PC from the policy, and create a new policy putting the rule in audit mode / disable, and push the policy out to the machine, nothing happens, it is still stuck as enabled.
When we add exclusions to this policy, they are recognized by the PC. So the policy is being implemented, the rule is just not being changed from enabled to audit or disable (we tried both).
Does anyone have any experience with this?
6 Replies
Like there is already another response, the main reason could be some of the ASR rules being assigned historically via other source - ConfigMgr, GPO, MEM, etc., BLOCK (1) always prevails if the policies were tattoed. You may do a simple search in Registry with ASR rule names and see the count of results appearing.
GPO/SCCM/MEM:
HKLM\SOFTWARE\Policies\Microsoft\Windows Defender
MDM/Intune:
HLKM\SOFTWARE\Microsoft\Windows Defender\Policy Manager
Set-MpPreference / Add-MpPreference
HKLM\SOFTWARE\Microsoft\Windows Defender
Did you use ConfigMgr to configure the ASR the first time? Just checking, but can you confirm that you don’t have conflicting policies coming from elsewhere like GPO?
Hi, yes we used SCCM to configure it for the first time, and ASR aren't defined in our GPO no.
Hi, yes we did use SCCM to implement it, and we do not have any GPO's with ASR set anywhere. These rules were not configured at all before implementing through SCCM
Thanks for the confirmation. Some ASR policies may require a reboot for changes to reflect. Have the devices been rebooted at least once? Maybe run a RSOP on a device in question just to be sure there are no other conflicts. If you have Security baselines containing Defender settings coming from GPO, then that could be taking precedence as well.
Hi, yes we did use SCCM to implement it, and we do not have any GPO's with ASR set anywhere. These rules were not configured at all before implementing through SCCM
