← All posts

Defender Tamper Protection: The Kill Switch Attackers Try to Flip First

Tamper Protection is the last line stopping malware from disabling Microsoft Defender via registry, PowerShell, or Group Policy - but it fails silently when managed wrong. Here is how attackers try to turn Defender off (MITRE T1562.001), why Tamper Protection blocks them, and how to verify it is actually on for the machine in front of you.

Almost every hands-on-keyboard intrusion on Windows includes the same early move: the attacker tries to blind the endpoint's antivirus. Under MITRE ATT&CK this is T1562.001 (Impair Defenses: Disable or Modify Tools), and on a stock Windows box the target is Microsoft Defender. If they can flip Defender off, everything that follows — dropping a second-stage payload, dumping LSASS, staging exfil — runs unscanned. Tamper Protection exists to make that first move fail. It is one of the highest-value, lowest-effort controls on the machine, and it is also one of the most commonly misconfigured, because it defends against the exact tools admins use to manage Defender.

How attackers turn Defender off

Defender's runtime state lives in the registry and is exposed through PowerShell, Group Policy, and WMI. Without Tamper Protection, any of these is a one-liner for a process running as SYSTEM or local admin:

:: Registry: kill real-time protection outright
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" ^
    /v DisableRealtimeMonitoring /t REG_DWORD /d 1 /f

:: PowerShell: same thing, cleaner
Set-MpPreference -DisableRealtimeMonitoring $true
Set-MpPreference -DisableIOAVProtection $true

:: Add a blanket exclusion so the payload directory is never scanned
Add-MpPreference -ExclusionPath "C:\ProgramData\Update"

Ransomware crews and commodity loaders script exactly these calls. The registry route is popular because it survives in Group Policy hives and can be pushed to a whole domain at once. The exclusion trick is quieter — Defender keeps running, so dashboards stay green, but the attacker's staging folder is a permanent blind spot.

What Tamper Protection actually blocks

Tamper Protection wraps a subset of Defender's security-critical settings in a kernel-enforced lock. When it is on, changes to those settings are only accepted through trusted channels — the Windows Security app UI, or a managed policy delivered by Intune/MDM. Direct writes are refused regardless of privilege. Specifically, it protects:

The key consequence: even SYSTEM cannot flip these via reg add or Set-MpPreference. The attacker's script returns access-denied, and — importantly — that refusal generates telemetry (Event ID 5013 in the Windows Defender operational log) instead of silently succeeding. It turns a stealthy defeat into a noisy, detectable failure.

Tamper Protection does not stop a determined attacker who brings their own vulnerable driver (BYOVD) to kill Defender from the kernel. It raises the cost — that is the whole game. Every rung you add to the ladder is another chance to catch them before they reach the payload.

Why it fails silently in real fleets

The catch: Tamper Protection has to be on to help, and its state is easy to lose track of. Three common failure modes:

  1. It was never enabled. On older installs and images built before it shipped broadly, the default was off. Nobody flipped it, and nobody noticed.
  2. A management tool disabled it. Some third-party AV migrations and legacy management agents turn Tamper Protection off so they can script Defender. If the migration is abandoned, you are left exposed.
  3. It reports on but isn't enforcing. On unmanaged machines Tamper Protection is a per-device toggle; on domain-joined or MDM-managed machines it should be pushed centrally so a local admin can't quietly revert it. Mixed environments drift.

Verify it on the machine in front of you

Do not trust the memory of whoever built the image. Check the live state:

# True means Tamper Protection is ON
(Get-MpComputerStatus).IsTamperProtected

# Cross-check that real-time protection is actually running
Get-MpComputerStatus | Select-Object AMRunningMode, RealTimeProtectionEnabled, `
    BehaviorMonitorEnabled, IoavProtectionEnabled

# Review any exclusions an attacker (or a lazy admin) may have planted
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath

If IsTamperProtected is False, or real-time protection is off, or you find exclusion paths nobody can explain, you have a finding. Enable Tamper Protection from Windows Security → Virus & threat protection settings, or push it via your MDM. Then treat unexplained exclusions as an incident, not a cleanup task.

Where WinSentinel fits

Manually running Get-MpComputerStatus is fine for one box. WinSentinel audits Defender posture as one of its 33 modules on any single machine for free — it flags Tamper Protection being off, real-time protection disabled, and every unexplained exclusion path, then maps each finding to its ATT&CK technique so you know why it matters. No dashboard to configure, no agent quota: the full audit runs locally and tells you the exact remediation.

For organizations running more than one machine, WinSentinel Pro adds fleet orchestration on top: a central node collects Defender-tamper findings across every endpoint, rolls them into a compliance view, and raises a drift alert the moment Tamper Protection gets switched off on any managed host — so a quietly disabled kill switch on machine #74 doesn't stay invisible until an incident. The single-machine audit is the same either way; Pro is about seeing it everywhere at once.

Tamper Protection is close to free and blocks the single most common post-compromise action on Windows. The only unforgivable outcome is finding out it was off after the ransomware note. Check IsTamperProtected today.