Deploy network protection and build custom IP/URL/domain indicators in Microsoft Defender for Endpoint. Understand SmartScreen dependencies, disable QUIC and Encrypted Client Hello for non-Microsoft browsers, configure warn and block modes, manage policy precedence conflicts, troubleshoot common implementation failures, and hunt for network protection events with KQL.
Network protection is a core component of Microsoft Defender for Endpoint's web protection stack. It extends SmartScreen capabilities beyond Microsoft Edge to block outbound HTTP/HTTPS connections to malicious or suspicious domains and IP addresses across all browsers and non-browser processes. However, network protection implementation is one of the most commonly misconfigured features in MDE deployments. Organizations frequently enable custom indicators for IPs, URLs, and domains without understanding the critical prerequisites: SmartScreen must be enabled for Edge, network protection must be in block mode for non-Edge browsers, QUIC and Encrypted Client Hello (ECH) must be disabled for FQDN blocking in Chrome and Firefox, and policy conflict precedence rules must be carefully understood. This lab walks through every aspect of the implementation, including the common pitfalls that cause indicators to silently fail.
Scenario: A mid-size healthcare organization (3,000 endpoints) receives threat intelligence indicating that a known APT group is using specific domains and IP addresses for C2 communication. The SOC team needs to immediately block these indicators across all endpoints and browsers - not just Microsoft Edge.
After creating custom indicators in the Defender portal, the team discovers that blocking works in Edge but fails silently in Chrome and Firefox. Users on those browsers can still reach the malicious domains. The root cause: network protection was set to audit mode instead of block mode, QUIC was not disabled, and Encrypted Client Hello was preventing TLS inspection. This lab addresses exactly this class of implementation failure.
Success criteria: all custom indicators enforced across all browsers, QUIC/ECH disabled via policy, warn mode configured for uncertain URLs, and a KQL-based monitoring dashboard for ongoing validation.
Network protection misconfiguration is one of the most common and dangerous gaps in MDE deployments. When custom indicators fail silently, the SOC team believes they have blocked malicious infrastructure - but users on non-Edge browsers can still reach C2 domains, phishing sites, and malware download servers. The gap between "indicator created" and "indicator enforced" is where breaches happen. Understanding the full implementation chain - SmartScreen, network protection mode, browser protocol requirements, and policy precedence - is essential for any security team operating MDE at enterprise scale.
Network protection is the enforcement engine that makes custom indicators work outside of Microsoft Edge. Understanding how it fits into the web protection stack is essential before any configuration.
The enforcement mechanism depends on the browser and the type of protection:
| Feature | Microsoft Edge | Non-Microsoft Browsers | Non-Browser Processes |
|---|---|---|---|
| Web Threat Protection | SmartScreen must be enabled | Network protection must be in block mode | Network protection must be in block mode |
| Custom Indicators | SmartScreen must be enabled | Network protection must be in block mode | Network protection must be in block mode |
| Web Content Filtering | SmartScreen must be enabled | Network protection must be in block mode | Not supported |
Before changing anything, audit the current network protection configuration on your devices. Most implementation failures start with assumptions about what is already enabled.
# ---------------------------------------------------------
# WHAT: Check the current network protection state on a device
# WHY: Network protection is the enforcement layer for custom
# indicators in non-Edge browsers. If it's off or in
# audit mode, your indicators are NOT being enforced.
# ---------------------------------------------------------
# Check network protection mode
# EnableNetworkProtection values:
# 0 = Disabled (indicators NOT enforced outside Edge)
# 1 = Block mode (indicators enforced - REQUIRED)
# 2 = Audit mode (indicators logged but NOT enforced)
$npState = (Get-MpPreference).EnableNetworkProtection
switch ($npState) {
0 { Write-Host "CRITICAL: Network Protection is DISABLED" -ForegroundColor Red }
1 { Write-Host "Network Protection is in BLOCK mode (correct)" -ForegroundColor Green }
2 { Write-Host "WARNING: Network Protection is in AUDIT mode - indicators NOT enforced" -ForegroundColor Yellow }
}
# Check all prerequisite settings
# ALL of these must be true for network protection to function
Get-MpPreference | Select-Object `
EnableNetworkProtection,
DisableRealtimeMonitoring,
DisableBehaviorMonitoring,
MAPSReporting,
SubmitSamplesConsent | Format-List
# Verify real-time protection is active (not just configured)
Get-MpComputerStatus | Select-Object `
RealTimeProtectionEnabled,
BehaviorMonitorEnabled,
IoavProtectionEnabled,
NISEnabled,
AMProductVersion# ---------------------------------------------------------
# WHAT: Verify network protection state via registry
# WHY: Group Policy or Intune may have set the value differently
# than what PowerShell reports (policy wins over local config)
# ---------------------------------------------------------
# Primary location (policy-managed)
$policyPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\Network Protection"
if (Test-Path $policyPath) {
$val = (Get-ItemProperty $policyPath -ErrorAction SilentlyContinue).EnableNetworkProtection
Write-Host "Policy-managed value: $val (0=Off, 1=Block, 2=Audit)"
} else {
Write-Host "No policy-managed network protection setting found"
}
# Secondary location (local preference)
$localPath = "HKLM:\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\Network Protection"
if (Test-Path $localPath) {
$val = (Get-ItemProperty $localPath -ErrorAction SilentlyContinue).EnableNetworkProtection
Write-Host "Local preference value: $val"
}Enable network protection in block mode to enforce custom indicators across all browsers and processes. Start with audit mode for testing, then switch to block mode after validation.
# ---------------------------------------------------------
# WHAT: Enable network protection via PowerShell
# WHY: Quick testing on individual devices before applying
# via Intune or Group Policy at scale
# ---------------------------------------------------------
# Enable in audit mode first (recommended for initial deployment)
# Audit mode logs events but does NOT block connections
Set-MpPreference -EnableNetworkProtection AuditMode
# After validation, switch to block mode
# Block mode actively prevents connections to indicators
Set-MpPreference -EnableNetworkProtection Enabled
# Verify the change took effect
(Get-MpPreference).EnableNetworkProtection
# Expected output: 1 (Block) or 2 (Audit)gpupdate /force on target devicesThis is the second most common reason custom indicators fail. Network protection inspects TLS handshakes to determine the FQDN being accessed. If the browser uses QUIC (UDP-based HTTP/3) or Encrypted Client Hello, network protection cannot read the hostname and the indicator is bypassed.
# ---------------------------------------------------------
# WHAT: Disable QUIC and ECH in Chrome via registry (GPO equivalent)
# WHY: Without this, Chrome uses UDP/QUIC for HTTPS connections,
# completely bypassing network protection's TLS inspection.
# ECH encrypts the SNI, hiding the target domain.
# ---------------------------------------------------------
# Disable QUIC in Chrome (forces TCP/TLS connections)
# QuicAllowed = 0 means QUIC is disabled
New-Item -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "QuicAllowed" -Value 0 -Type DWord
# Disable Encrypted Client Hello in Chrome
# EncryptedClientHelloEnabled = 0 means ECH is disabled
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "EncryptedClientHelloEnabled" -Value 0 -Type DWord
Write-Host "Chrome QUIC and ECH disabled via policy"# ---------------------------------------------------------
# WHAT: Disable QUIC (HTTP/3) and ECH in Firefox via registry
# WHY: Same reason as Chrome - Firefox supports HTTP/3 and ECH
# which bypass network protection TLS inspection
# ---------------------------------------------------------
# Disable HTTP/3 (QUIC) in Firefox
New-Item -Path "HKLM:\SOFTWARE\Policies\Mozilla\Firefox" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Mozilla\Firefox" -Name "DisableEncryptedClientHello" -Value 1 -Type DWord
# Note: For HTTP/3 in Firefox, you may also need to set:
# network.http.http3.enable = false via about:config or enterprise policy
# This can be done via the policies.json file in Firefox installation directory
Write-Host "Firefox ECH disabled via policy"# ---------------------------------------------------------
# WHAT: Block QUIC traffic at the Windows Firewall level
# WHY: This is the nuclear option - blocks QUIC (UDP 443) for
# ALL applications, not just browsers. Forces everything
# to use TCP/TLS where network protection can inspect it.
# Use this when you cannot manage individual browser policies.
# ---------------------------------------------------------
$ruleParams = @{
DisplayName = "Block QUIC (UDP 443) for Network Protection"
Direction = "Outbound"
Action = "Block"
RemoteAddress = "0.0.0.0/0"
Protocol = "UDP"
RemotePort = 443
}
New-NetFirewallRule @ruleParams
Write-Host "QUIC blocked at Windows Firewall level"SmartScreen is the enforcement engine for custom indicators inside Microsoft Edge. On Windows, network protection does NOT monitor Edge - SmartScreen handles it directly.
# ---------------------------------------------------------
# WHAT: Ensure SmartScreen is enabled for Microsoft Edge
# WHY: Custom indicators for URLs/domains in Edge require
# SmartScreen to be active. Network protection does NOT
# handle Edge - SmartScreen does.
# ---------------------------------------------------------
# Enable SmartScreen in Edge via registry (GPO equivalent)
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" -Name "SmartScreenEnabled" -Value 1 -Type DWord
# Prevent users from overriding SmartScreen warnings
# WHY: Without this, users can click through block pages
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" -Name "PreventSmartScreenPromptOverride" -Value 1 -Type DWord
Write-Host "Edge SmartScreen enabled and override prevention configured"With the infrastructure configured, create custom indicators to block, warn, or allow specific IPs, URLs, and domains.
When multiple indicators or policies apply to the same URL/IP/domain, understanding the precedence order prevents unintended blocks or allows.
When conflicting action types exist for the same indicator:
For example, if you have three indicators for microsoft.com with actions Block, Warn, and Allow, the effective action is Allow.
When conflicting URL indicator policies exist, the longer (more specific) path takes precedence. For example:
https://support.microsoft.com/office takes precedence over https://support.microsoft.comMicrosoft Defender for Endpoint policy has precedence over Microsoft Defender Antivirus policy. If MDE is set to Allow but Defender AV is set to Block, the effective result is Allow.
Warn mode presents users with a notification when they visit a site with an unknown or uncertain reputation. Users can choose to bypass the warning for 24 hours.
# ---------------------------------------------------------
# WHAT: Convert SmartScreen warn verdicts to block
# WHY: By default, users can click through SmartScreen warnings
# for malicious sites. This converts all warnings to hard
# blocks that cannot be overridden.
# ---------------------------------------------------------
# Via Group Policy:
# Computer Configuration > Administrative Templates >
# Windows Components > Microsoft Defender Antivirus >
# Network inspection system > "Convert warn verdict to block"
# Set to: Enabled
# Via PowerShell (for testing):
# This requires setting the CSP via Intune or MDM:
# Defender CSP: Configuration/EnableConvertWarnToBlock# ---------------------------------------------------------
# WHAT: Ensure users see block notifications
# WHY: If toast notifications are disabled, users see a
# connection timeout instead of an informative block page.
# This makes troubleshooting impossible.
# ---------------------------------------------------------
# Ensure the FilesBlockedNotificationDisabled key is set to 0
$path = "HKLM:\SOFTWARE\Microsoft\Windows Defender Security Center\Virus and threat protection"
if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null }
Set-ItemProperty -Path $path -Name "FilesBlockedNotificationDisabled" -Value 0 -Type DWord
Write-Host "Block notifications enabled"| Threat Type | Category | Source |
|---|---|---|
| Phishing | Phishing | SmartScreen |
| Malicious | Malicious | SmartScreen |
| Command and Control | C2 / COCO | SmartScreen |
| Untrusted | Untrusted | SmartScreen |
| Admin-defined block | CustomBlockList / CustomPolicy | Custom Indicator |
A common source of confusion when investigating network protection events: you may see ConnectionSuccess events in DeviceNetworkEvents for sites that were actually blocked. This is by design.
DeviceNetworkEvents entry is logged with ActionType = ConnectionSuccessConnectionSuccess event and the block eventConnectionSuccess in DeviceNetworkEvents does NOT mean the site was accessible. DeviceNetworkEvents reports from the TCP layer. Network protection operates after the TCP handshake completes. The site was still blocked - no application data was exchanged. Always check for the corresponding ExploitGuardNetworkProtectionBlocked event in DeviceEvents to confirm the block.Use advanced hunting to validate that network protection is working, identify audit events, and monitor custom indicator enforcement.
// ---------------------------------------------------------
// WHAT: View all network protection events
// WHY: See both blocked and audited connections to validate
// that network protection is detecting threats
// ---------------------------------------------------------
DeviceEvents
| where ActionType in ('ExploitGuardNetworkProtectionAudited',
'ExploitGuardNetworkProtectionBlocked')
| extend ParsedFields = parse_json(AdditionalFields)
| project
Timestamp,
DeviceName,
ActionType,
RemoteUrl,
InitiatingProcessFileName,
IsAudit = tostring(ParsedFields.IsAudit),
ResponseCategory = tostring(ParsedFields.ResponseCategory),
DisplayName = tostring(ParsedFields.DisplayName)
| sort by Timestamp desc// ---------------------------------------------------------
// WHAT: Categorize network protection events by source
// WHY: Understand whether blocks come from SmartScreen,
// custom indicators, web content filtering, or MCAS
//
// ResponseCategory mapping:
// CustomPolicy = Web Content Filtering (WCF)
// CustomBlockList = Custom Indicators (your IoCs)
// CasbPolicy = Defender for Cloud Apps
// Malicious = SmartScreen web threats
// Phishing = SmartScreen phishing detection
// ---------------------------------------------------------
DeviceEvents
| where ActionType in ('ExploitGuardNetworkProtectionAudited',
'ExploitGuardNetworkProtectionBlocked')
| extend ParsedFields = parse_json(AdditionalFields)
| extend ResponseCategory = tostring(ParsedFields.ResponseCategory)
| summarize EventCount = count() by ResponseCategory, ActionType
| sort by EventCount desc// ---------------------------------------------------------
// WHAT: View SmartScreen warning/block events in Edge
// WHY: Edge uses SmartScreen instead of network protection.
// This query shows what SmartScreen is catching.
// ---------------------------------------------------------
DeviceEvents
| where ActionType == "SmartScreenUrlWarning"
| extend ParsedFields = parse_json(AdditionalFields)
| project
Timestamp,
DeviceName,
ActionType,
RemoteUrl,
InitiatingProcessFileName
| sort by Timestamp desc// ---------------------------------------------------------
// WHAT: Verify that your custom indicators are being enforced
// WHY: After creating indicators, use this to confirm they
// are actually blocking or warning as expected
// ---------------------------------------------------------
DeviceEvents
| where ActionType in ('ExploitGuardNetworkProtectionAudited',
'ExploitGuardNetworkProtectionBlocked')
| extend ParsedFields = parse_json(AdditionalFields)
| where tostring(ParsedFields.ResponseCategory) == "CustomBlockList"
| project
Timestamp,
DeviceName,
RemoteUrl,
ActionType,
InitiatingProcessFileName,
IsAudit = tostring(ParsedFields.IsAudit)
| sort by Timestamp desc// ---------------------------------------------------------
// WHAT: Assess what would be blocked if you switch from
// audit mode to block mode
// WHY: Before switching to block mode, review all audited
// events to identify potential false positives
// ---------------------------------------------------------
DeviceEvents
| where ActionType == "ExploitGuardNetworkProtectionAudited"
| extend ParsedFields = parse_json(AdditionalFields)
| summarize
HitCount = count(),
Devices = dcount(DeviceName),
LastSeen = max(Timestamp)
by RemoteUrl,
ResponseCategory = tostring(ParsedFields.ResponseCategory)
| sort by HitCount desc
// Review this list - any legitimate URLs should be added
// as Allow indicators before switching to block modeWhen network protection appears to not work, follow this systematic troubleshooting checklist.
Get-MpPreference | Select EnableNetworkProtection - must be 1 (block mode)Get-MpComputerStatus | Select AMRunningModeGet-MpComputerStatus | Select RealTimeProtectionEnabled must be TrueGet-MpComputerStatus | Select BehaviorMonitorEnabled must be TrueGet-MpPreference | Select MAPSReporting must be 1 or 2edge://settings/privacy.smartscreen.microsoft.com# ---------------------------------------------------------
# WHAT: Test SmartScreen cloud connectivity
# WHY: Network protection needs to reach SmartScreen cloud
# services. Proxies that intercept or block this traffic
# will break network protection.
# ---------------------------------------------------------
# Test SmartScreen connectivity
$urls = @(
"https://smartscreen.microsoft.com",
"https://smartscreen-prod.microsoft.com"
)
foreach ($url in $urls) {
try {
$response = Invoke-WebRequest -Uri $url -UseBasicParsing -TimeoutSec 10
Write-Host "OK: $url (Status: $($response.StatusCode))" -ForegroundColor Green
} catch {
Write-Host "FAILED: $url - $($_.Exception.Message)" -ForegroundColor Red
}
}
# If behind a proxy, configure static proxy for Defender AV:
# https://learn.microsoft.com/en-us/defender-endpoint/configure-proxy-internet# ---------------------------------------------------------
# WHAT: Check Windows Event Log for network protection events
# WHY: Event logs provide local evidence of network protection
# activity when advanced hunting is not available
#
# Event IDs:
# 5007 = Settings changed
# 1125 = Network protection fired in AUDIT mode
# 1126 = Network protection fired in BLOCK mode
# ---------------------------------------------------------
# Check for recent network protection events
Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" `
-MaxEvents 50 | Where-Object {
$_.Id -in @(5007, 1125, 1126)
} | Select-Object TimeCreated, Id, Message | Format-ListWindows Server and Windows Virtual Desktop (WVD) multi-session environments require additional configuration beyond standard Windows 10/11 deployments.
# ---------------------------------------------------------
# WHAT: Enable network protection on Windows Server
# WHY: Windows Server requires additional settings that are
# not needed on Windows 10/11 client SKUs
# ---------------------------------------------------------
# Step 1: Enable network protection (same as client)
Set-MpPreference -EnableNetworkProtection Enabled
# Step 2: Allow network protection on Windows Server
# This setting is REQUIRED - without it, network protection
# will not function on server SKUs
Set-MpPreference -AllowNetworkProtectionOnWinServer 1
# Step 3: Allow network protection on downlevel OS (Server 2012 R2 / 2016)
# Only needed for Server 2012 R2 and 2016 with modern unified agent
Set-MpPreference -AllowNetworkProtectionDownLevel 1
# Step 4: Allow datagram processing on Windows Server
# WARNING: This may affect network performance depending on
# infrastructure, traffic volume, and server workload
Set-MpPreference -AllowDatagramProcessingOnWinServer 1
Write-Host "Network protection configured for Windows Server"# ---------------------------------------------------------
# WHAT: Configure network protection on Server via registry
# WHY: Some deployment tools prefer direct registry manipulation
# over PowerShell cmdlets
# ---------------------------------------------------------
$basePath = "HKLM:\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\Network Protection"
# Create the key if it doesn't exist
if (-not (Test-Path $basePath)) {
New-Item -Path $basePath -Force | Out-Null
}
# Required settings
Set-ItemProperty -Path $basePath -Name "EnableNetworkProtection" -Value 1 -Type DWord
Set-ItemProperty -Path $basePath -Name "AllowNetworkProtectionOnWinServer" -Value 1 -Type DWord
# For Server 2012 R2 and 2016 only
Set-ItemProperty -Path $basePath -Name "AllowNetworkProtectionDownLevel" -Value 1 -Type DWord
Write-Host "Server registry keys configured"AllowDatagramProcessingOnWinServer can affect network throughput# ---------------------------------------------------------
# WHAT: Enable asynchronous inspection for network protection
# WHY: Long-lived connections (streaming, large downloads)
# may cause performance issues with synchronous inspection.
# Async inspection improves performance and app compatibility.
# This is enabled by default but can be explicitly set.
# ---------------------------------------------------------
Set-MpPreference -AllowSwitchToAsyncInspection $true
# Via Group Policy:
# Computer Configuration > Administrative Templates >
# Windows Components > Microsoft Defender Antivirus >
# Network inspection system > "Turn on asynchronous inspection"
# Set to: EnabledSet-MpPreference -EnableNetworkProtection AuditModeRemove-NetFirewallRule -DisplayName "Block QUIC (UDP 443) for Network Protection"| Resource | Description |
|---|---|
| Use network protection to help prevent connections to bad sites | Comprehensive guide to network protection architecture, configuration, and troubleshooting |
| Create indicators for IPs and URLs/domains | How to create custom network indicators with prerequisites and limitations |
| Turn on network protection | Enable network protection via Group Policy, PowerShell, or MDM CSPs |
| Evaluate network protection | Quick test scenario to demonstrate network protection in action |
| Web protection overview | How web protection, network protection, and SmartScreen work together |
| Web content filtering | Category-based URL blocking that depends on network protection |
| Network protection for Linux | Linux-specific network protection configuration |
| Network protection for macOS | macOS-specific network protection configuration |