Windows Defender — Architecture and Rulesets (Deep Dive)

Table of Contents

• ELI5 — what Defender is on this machine
• Lab baseline — 192.168.50.114
• Architecture stack
• Processes and services
• Key binaries and DLLs
• Kernel layer — WdFilter
• AMSI integration
• Detection engines and signatures
• Policy and ruleset layers
• Attack Surface Reduction (ASR)
• Other rule families
• Defender AV vs Defender for Endpoint
• Investigation commands
• Security engineer checklist
• Navigation

ELI5 — what Defender is on this machine

Defender is three things at once:

1. A background guard (MsMpEng.exe) that scans files and behavior
2. A kernel traffic cop (WdFilter.sys) that can pause file opens until scan completes
3. A script spell-checker hook (AMSI provider) so PowerShell/VBScript gets inspected before running

Rulesets are the rulebooks telling the guard what to block, audit, or allow — configured via local PowerShell, Group Policy, Intune, or the MDE cloud portal.

Lab baseline — 192.168.50.114

Audited 2026-09-01 via SSH from MiniMac.

Services

Protection state (Get-MpComputerStatus)

Policy snapshot (Get-MpPreference)

ASR rule active on lab .114

History: Audit (2) applied earlier same day, then switched to Block (Enabled).

Set-MpPreference -AttackSurfaceReductionRules_Ids '5beb7efe-fd9a-4556-801d-275e5ffc04cc' `
  -AttackSurfaceReductionRules_Actions Enabled

Verify:

$p = Get-MpPreference
$p.AttackSurfaceReductionRules_Ids
$p.AttackSurfaceReductionRules_Actions

Watch for audit hits: Event Viewer → Microsoft → Windows → Windows Defender → Operational — IDs 1122 (audit) / 1121 (block). Config changes log as 5007.

Live processes (memory)

Install layout

Architecture stack

flowchart TB
  subgraph ui [User / admin surface]
    SECUI[Windows Security app]
    PS[PowerShell Get-Mp* / Set-Mp*]
    MPCMD[MpCmdRun.exe]
  end

  subgraph usermode [User-mode services]
    CORE[MpDefenderCoreService.exe
mdcoresvc]
    ENG[MsMpEng.exe
WinDefend]
    NIS[NisSrv.exe
WdNisSvc]
    SENSE[Sense.exe
optional MDE]
    AMSIProv[AMSI provider in engine]
  end

  subgraph dlls [Client libraries]
    MPCLIENT[MpClient.dll]
    MPRTP[MpRtp.dll real-time]
  end

  subgraph kernel [Kernel mode]
    WDF[WdFilter.sys minifilter]
    KERN[ntoskrnl.exe]
  end

  subgraph cloud [Optional cloud]
    MAPS[MAPS / cloud protection]
    MDEPORTAL[Defender portal policies]
  end

  SECUI --> CORE
  PS --> MPCLIENT
  MPCMD --> ENG
  MPCLIENT --> ENG
  ENG --> AMSIProv
  ENG --> WDF
  WDF --> KERN
  ENG --> MAPS
  SENSE --> MDEPORTAL
  NIS --> ENG

Scan path (simplified — file open on normal volume):

App opens file
  → I/O manager → file system stack
  → WdFilter.sys (PreOp callback) — thread may block here
  → MsMpEng scan decision
  → allow / block / quarantine
  → app continues or fails

On Dev Drives, Microsoft documents deferred async scanning instead of blocking PreOp — see sandbox / Dev Drive docs.

Optional sandbox layer: MsMpEngCP.exe (content process) when sandbox mode enabled via MP_FORCE_USE_SANDBOX=1 — high-risk parsing isolated from privileged MsMpEng.exe.

Processes and services

Source: Microsoft Defender Antivirus processes.

Key binaries and DLLs

From C:\Program Files\Windows Defender\ on .114:

Read-only DLL inspection: MpClient.dll paths.

Kernel layer — WdFilter

WdFilter.sys is Microsoft's file system minifilter for Defender real-time protection. It sits in the FSFilter Anti-Virus altitude band (320000–329999). On lab .114 it registers at 328010 with 5 instances (one per attached volume/stack type).

Altitude and stack position

Filter Manager assigns numeric altitudes — higher numbers sit closer to user-mode callers in the I/O stack. Defender AV and third-party AV products share the 320000–329999 band; EDR activity monitors use a different band (360000–369999).

Official allocation table: Allocated minifilter altitudes.

fltmc filters | Sort-Object { [double]($_ -split '\s+')[-2] } -Descending
fltmc instances   # per-volume attach detail
fltmc volumes     # which filters on which volumes

PreOp vs PostOp scan flow

App CreateFile / Read / Write
  → I/O Manager → file-system filter stack
  → WdFilter PreOp (IRP_MJ_CREATE, IRP_MJ_READ on-access)
       • Thread may block synchronously
       • Scan request forwarded to MsMpEng.exe via filter communication port
  → Lower filters / NTFS
  → WdFilter PostOp (write completion, cleanup)
  → IRP completed → app continues or fails

What happens on block

1. WdFilter forwards content to MsMpEng.exe (WinDefend).
2. Engine returns malicious verdict.
3. Filter completes the IRP with failure (commonly STATUS_ACCESS_DENIED / 0xC0000022).
4. User-mode app sees open/read/write failure; remediation may quarantine the file.
5. Optional: MsMpEngCP.exe sandbox process parses high-risk content when MP_FORCE_USE_SANDBOX=1.

Event IDs — file scan / RTP (Defender Operational)

Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 50 |
  Where-Object { $_.Id -in 1116,1117,1118,1150,1121,1122,5007 } |
  Select-Object TimeCreated, Id, @{N='Msg';E={$_.Message.SubstringMin(100,$_.Message.Length)}}

Tamper protection, PUA, network protection (lab .114)

Security engineer angle: minifilters see all file I/O on attached volumes — stronger than user-mode hooks, different blind spots than AMSI (script/content focused). When both Defender AV and a third-party EDR are present, expect multiple filters at different altitudes — always baseline with fltmc after installs.

Related: Module 1 — Kernel · Code Integrity Engine · Lab baseline

AMSI integration

Defender registers as an AMSI antimalware provider. When a script host (PowerShell, wscript, .NET 4.8+, WMI, etc.) calls AmsiScanBuffer / AmsiScanString, content can be routed to Defender before execution.

sequenceDiagram
  participant PS as powershell.exe
  participant AMSI as amsi.dll
  participant ENG as MsMpEng
  participant PS2 as PowerShell runtime

  PS->>AMSI: AmsiScanString(script)
  AMSI->>ENG: provider scan
  ENG-->>AMSI: clean / detected
  AMSI-->>PS: result
  alt detected
    PS--xPS2: block or alert
  else clean
    PS->>PS2: execute
  end

Supported script surfaces (Microsoft): PowerShell, JScript, VBScript, WSH, .NET assemblies, WMI — see AMSI on MDAV.

Logging: enable PowerShell script block logging (4104) and Defender operational logs for correlation.

Your lab: amsi.dll is inbox; MsMpEng was top memory consumer — consistent with active AV + script scanning path.

Detection engines and signatures

Defender stacks multiple detection types (not just hashes):

On .114: signatures fresh (2026-08-31); engine version string empty in Get-MpComputerStatus output — use Platform folder version 4.18.26070.9-0 as authoritative build.

Policy and ruleset layers

Rules are not one file — they stack. Upper layers override lower when configured.

flowchart TB
  CLOUD[MDE / Intune / GPO central policy]
  MDM[Defender CSP / Configuration Manager]
  GP[Group Policy — SecGuide / ADMX]
  LOCAL[Set-MpPreference / Add-MpPreference]
  ENGINE[MsMpEng effective policy]

  CLOUD --> ENGINE
  MDM --> ENGINE
  GP --> ENGINE
  LOCAL --> ENGINE

Effective policy query (lab):

Get-MpPreference | Format-List *
Get-MpComputerStatus | Format-List *

Tamper Protection: when on, blocks local disable of RTP and some preference changes — check IsTamperProtected in Get-MpComputerStatus on your host.

Attack Surface Reduction (ASR)

ASR rules are behavioral block/audit rules — independent of classic malware signatures. Each rule has a GUID and a mode.

Modes

Example high-value rules (GUID → name)

Full list: ASR rules overview · ASR reference.

Configure (lab — admin PowerShell)

# Audit one rule (example — obfuscated scripts)
Add-MpPreference -AttackSurfaceReductionRules_Ids '5beb7efe-fd9a-4556-801d-275e5ffc04cc' `
  -AttackSurfaceReductionRules_Actions AuditMode

# List configured rules
$p = Get-MpPreference
0..Min($p.AttackSurfaceReductionRules_Ids.Count, $p.AttackSurfaceReductionRules_Actions.Count)-1 |
  ForEach-Object {
    [pscustomobject]@{
      Id = $p.AttackSurfaceReductionRules_Ids[$_]
      Action = $p.AttackSurfaceReductionRules_Actions[$_]
    }
  } | Format-Table -AutoSize

Your lab today: one ASR rule in block mode — obfuscated scripts (5beb7efe-fd9a-4556-801d-275e5ffc04cc). Action=1 (Block). Event 1121 when triggered.

Events: ASR blocks/audits appear in Event Viewer → Microsoft → Windows → Windows Defender → Operational (IDs vary by rule; hunt 1121, 1122, 5007 family).

Other rule families

Controlled Folder Access modes: 0 off, 1 on, 2 audit — enable only with allow-list planning.

Defender AV vs Defender for Endpoint

Onboarding installs Sense client and registry/CSP onboarding blob — WDATP CSP.

Naming confusion: "Windows Defender" in UI often means the whole security stack; engineers should specify MDAV vs MDE vs ASR vs Exploit Guard.

Investigation commands

Run on .114 (elevated where noted):

# Health dashboard
Get-MpComputerStatus | Format-List *

# Full preference / ruleset
Get-MpPreference | Format-List *

# Threat history
Get-MpThreatDetection | Select-Object -First 10 *
Get-MpThreat | Select-Object -First 10 *

# Quick scan (lab)
Start-MpScan -ScanType QuickScan

# Signature update
Start-MpWDOScan  # offline rescue — disruptive; avoid on shared lab without snapshot
# Prefer: MpCmdRun.exe -SignatureUpdate

# Operational log (recent Defender events)
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20 |
  Select-Object TimeCreated, Id, Message

# ASR audit mapping (when rules exist)
# Event ID 1121 = block, 1122 = audit

GUI: Windows Security → Virus & threat protection → Manage settings / Protection history.

Security engineer checklist

Baseline (do once per VM)

• Record AMProductVersion + Platform folder version
• Confirm WinDefend + WdNisSvc running
• Note whether Sense is running (MDE yes/no)
• Export Get-MpPreference to file for diffing
• Document exclusions (should be minimal in lab)
• List ASR rules with GUID + mode

Hardening progression (lab-safe order)

1. Enable ASR in audit mode for 2–3 rules → review Operational log
2. Enable cloud-delivered protection if network policy allows
3. Tune PUA and network protection
4. Pilot CFA in audit before enforce
5. Onboard to MDE only when tenant + legal/logging scope ready

Do not (in shared lab without snapshot)

• Disable tamper protection on production-adjacent systems without approval
• Add broad C:\ exclusions to "make lab work"
• Run Set-MpPreference -DisableRealtimeMonitoring $true and forget to revert

Navigation

← Module 7 · MOC · Windows Playbook

See also: Defender + S1 field manual · AMSI inspection Part 1