Just quickly following up on my previous post, on how I moved some of the Endpoint Protection workloads into Intune MDM (in a Co-management scenario with Configuration Manager). More specifically, I moved the Exploit Guard capabilities and while walking through the process, I mentioned the possible impact of Exploit Guard in an enterprise environment.
Again, this post is to highlight the possible impact of turning on a very specific ASR (Attack Surface Reduction) rule in Exploit Guard. Turns out, that this specific rule is not documented by Microsoft (at least I can’t find it in the Exploit Guard documentation: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard#attack-surface-reduction-rules) and the impact is quite significant to those using Configuration Manager (and possible other stuff too). Curious? Keep reading 🙂
What Attack Surface Reduction rule?
The rule in question is having an ID of: D1E49AAC-8F56-4280-B9BA-993A6D77406C. This is not mentioned anywhere in the Exploit Guard documentation. In Intune, it’s the one I’m highlighting below:
If this rule is turned on (set to Block), you will for one, not be able to install any application through the Software Center. If you try to do so while this is set to Block (and you haven’t done any Exploit Guard exclusions), you’ll notice following error in AppEnforce.log
AppProvider::EnforceApp – Failed to invoke EnforceApp on Application handler(0x80070005).
The error 0x80070005 translates into Access Denied. Looking further into the Windows Defender event log, you will notice following entry (this is an MSI run from the Software Center, hence msiexec.exe is the one triggering the rule):
Windows Defender Antivirus has blocked an operation that is not allowed by your IT administrator.
For more information please contact your IT administrator.
Detection time: 2018-04-20T06:34:40.047Z
User: NT AUTHORITY\SYSTEM
Process Name: C:\Windows\System32\wbem\WmiPrvSE.exe
Signature Version: 1.265.948.0
Engine Version: 1.1.14700.5
Product Version: 4.12.16299.15
What to do?
Now that the impact is known, what can we do to prevent this from happening?
- Unconfigure the ASR rule
- Set the rule to Audit Only
- Take notice of the actions being blocked and create the relevant exclusions
I’m curiously refreshing the documentation. Exploit Guard is rather new and was introduced with Windows 10 1709, but Intune seems to have more available capabilities in this regard than what the documentation currently is covering. Interesting 🙂
1 thought on “Flipping the switch, part 2.1: Exploit Guard challenges (Co-management with Intune MDM and SCCM)”
Finally i understand the reason of the problem.
Thank you so much!