Fixing Tamper Protection Blob Error 65000 using Microsoft Intune

I recently encountered an issue with enabling Tamper protection as part of the implementation of Defender for Endpoint in one of customer's tenant and considering how unusual the behavior was and how I didn't encounter this before, I decide to blog my experience. If you have been battling with the same issue, then this blog may just help you.

There are multiple ways to enable Tamper protection as part of MDE. One can enable at a tenant level using Defender portal or do it using Intune. I normally choose the Intune, especially when dealing with endpoints to maintain uniformity with other Defender policies being managed by Intune. However, in this particular instance, the issue started cropping randomly on some endpoints where tamper protection would not enable and throw an error code 65000, as show below.

Additionally, the status in Defender will report as Unknown instead of reporting Active or something else like EDR in block mode to suggest that Defender Antimalware is running on the device at the very least.

To give a little more background on the scenario, I was onboarding Windows 10 devices to MDE in passive mode until the active running 3rd party security solution was removed. The end objective was that once the 3rd party security solution was removed, Defender will switch to Active mode and MDE components would take over. While this process worked in general, it did leave me with some devices not switching Defender to active mode after 3rd party security solution was removed. Since the issue was so random, it wasn't easy to pinpoint the root cause. On further investigation, I stumbled on the Microsoft's official learn document, which stated that if the Defender AV is not enabled and the service not running, then it can interfere with the MDE onboarding process in general and additionally result in tamper protection not getting enabled. The behavior matched my particular issue as I could see that Defender AV was not available as an active provider. (Special thanks to Ryan Sturm for assistance and sharing his experience in MDE Microsoft Security Connection Program)

I checked for the registries in question, and voila. There was a registry configured for disabling AntiSpyware.

According to Microsoft, the registry in question was deprecated long back.

I verified and there was no active policy in customer's environment that was configuring the registry. My only hypothesis is that, the registry would have been configured at the time of the implementation of the 3rd party security solution on the endpoints and the policy was removed later without actually removing the registry in question.

The fix..

Well the fix is actually simple. While there is an option to change the value of disable AntiSpyware from 1 to 0, I decided to get rid of the registry altogether. Why have a deprecated setting in place, right?

As I am pushing the Defender policies under Co-management using Intune, I setup a remediation Powershell script to detect and remove the registry in question. Here are the scripts -

Detection Script - 

$check=Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender" | 

Select-Object -ExpandProperty DisableAntiSpyware -ErrorAction SilentlyContinue

If(($check -eq $null) -and ($check.length -eq 0)) {

         "Key does not exist"

           exit 0

          }

 Else{

 "Key exists"

exit 1

          }

Remediation Script -

Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender" -Name "DisableAntiSpyware" -Force

Following are the steps to set things up in Intune -

1. Sign-in to the Microsoft Intune admin portal.

2. Browse to Devices > Scripts & remediations – Create

3. Fill the relevant fields like Name, Description, Publisher etc and hit Next.

4. In the settings section, select the relevant Detection and Remediation scripts as covered above in the blog.

5. Run the script in 64-bit Powershell and leave the rest of the options to Default.

6. Assign the scope tags if required and then assign to device based group. You can define the frequency of the execution of the Proactive script. I set to run Daily against production devices to suit my requirements.

Script in action

The Intune management extension agent checks with Intune once every hour and after every reboot for any new scripts or changes. The execution results can be monitored directly in Intune under Devices > Scripts & remediations<Name of your Remediation Script>. You can switch to Device Status and then add the columns to get more details related to Pre & Post Detection and Remediation status.

Status in Defender Portal should switch from Unknown and tamper protection should enable as well. In my case EDR in block mode after MDE onboarding in Passive mode.

Hope the above helps and saves you some time dealing with similar issues in the future. Thanks for reading. Until next time..