Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Windows Defender Firewall is the user-facing surface of a much deeper kernel framework: the Windows Filtering Platform (WFP), introduced in Windows Vista as the successor to the old TDI/NDIS filter-hook model. WFP exposes layered interception points along the network stack — at the application layer (ALE, before a connect/accept completes), the transport layer, and the network layer — and every first- and third-party filtering product on modern Windows, including Defender Firewall itself, most endpoint protection platforms, and many VPN clients, is built as a WFP callout or a set of WFP filters. The firewall you configure through netsh advfirewall, PowerShell’s NetSecurity module, or Group Policy is ultimately just a well-behaved WFP consumer.
That layering matters for security because it creates two very different tampering surfaces. The high-level one is policy tampering — adding an overly permissive rule, disabling a profile, or editing the registry directly — which any local administrator can do with in-box tools and which attackers and pentest tooling use routinely to open a path for a backdoor or lateral movement. The low-level one is WFP tampering — installing filters or callout drivers that operate below the Defender Firewall UI entirely, capable of silently permitting, blocking, or even redirecting traffic in ways that ordinary firewall administration will never surface. This article covers both, and how to detect each.
Attack Prerequisites
Firewall and WFP tampering both require meaningful privilege, but at different tiers:
- Local Administrator — required for
netsh advfirewallrule changes,New-NetFirewallRule/Set-NetFirewallProfile, direct registry edits under the firewall policy hive, and theINetFwPolicy2COM interface used by programmatic tooling. - SYSTEM or local admin with service control rights to stop or reconfigure the Base Filtering Engine (BFE) or Windows Defender Firewall (MpsSvc) services, which is noisy and generally unnecessary — most tampering does not require touching the services at all.
- A signed kernel driver for genuine WFP callout registration — Windows driver-signing enforcement means an attacker generally needs a legitimately signed (or stolen-cert-signed) driver to add kernel callouts; this is a materially higher bar than the userland rule/registry path.
- No Tamper Protection / centrally-enforced GPO — Microsoft Defender’s tamper protection and GPO settings that disallow local rule merging both close the easy paths and must be absent or bypassed first.
How It Works
Firewall rules are evaluated per profile — Domain, Private (labeled StandardProfile in the registry), and Public — with the active profile determined by how Windows classifies the current network. Within a profile, WFP’s evaluation is best summarized as: explicit block always wins over allow, regardless of rule source, and rules can come from multiple layers simultaneously — local rules, Group Policy rules, and rules pushed by services (e.g., IPsec/AppContainer network isolation rules). GPO can be configured so local administrators cannot add rules that override centrally managed policy (Apply local firewall rules = No), which is the main structural defense against ad hoc tampering.
Under the hood, Defender Firewall registers its rules with the Base Filtering Engine as WFP filters attached to specific layers — most relevantly the ALE (Application Layer Enforcement) layers, which intercept a process’s connect()/accept() calls before the packet is even built, letting the engine make an allow/block decision keyed to the calling process, not just IP/port. This is why Defender Firewall rules can be scoped to program= and why endpoint products can attribute a blocked connection to a specific executable. Persisted policy state — profile enable flags, logging settings, default inbound/outbound actions — lives in the registry under HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\<Profile>Profile\, with <Profile> being DomainProfile, StandardProfile (Private), or PublicProfile.
Below Defender Firewall, any driver that registers as a WFP callout can classify and act on traffic independent of the firewall rule store entirely — this is how third-party AV/EDR network protection, VPN split tunneling, and some malware families implement their own filtering. A malicious callout can silently permit its own C2 traffic, block security product telemetry to specific IPs, or drop packets matching a signature — all without ever touching a netsh advfirewall rule that an administrator would think to review. Because this requires a signed driver, it is a much rarer technique than rule/registry tampering, but it is materially stealthier when it does occur, since standard firewall-auditing tooling only looks at the WFP filter/rule store, not at what a rogue callout is doing with the packets it classifies.
Vulnerable Code / Configuration
The overwhelming majority of real-world firewall tampering is a single permissive rule added with the in-box tooling — no exploit needed, just administrative rights. This opens an inbound path to a backdoor listener while looking, at a glance, like routine IT change:
:: Add a permissive inbound rule scoped to a specific (attacker) binary,
:: on any profile, with no port restriction narrative in the rule name.
netsh advfirewall firewall add rule name="Windows Update Helper" ^
dir=in action=allow ^
program="C:\Users\Public\svc.exe" ^
enable=yes profile=any
:: PowerShell equivalent, often used to avoid netsh.exe in the process tree.
New-NetFirewallRule -DisplayName "Windows Update Helper" -Direction Inbound `
-Program "C:\Users\Public\svc.exe" -Action Allow -Profile Any
The second common pattern is disabling firewall enforcement for a profile outright via the registry — noisier than a scoped rule, but faster, and still seen in commodity malware and pre-lateral-movement scripts that just want SMB/RDP reachable without crafting individual rules:
:: Disable the firewall for the Private ("Standard") profile directly
:: in the registry, bypassing the netsh/GUI abstraction entirely.
reg add "HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\
FirewallPolicy\StandardProfile" /v EnableFirewall /t REG_DWORD /d 0 /f
Both changes are achievable without spawning netsh.exe at all by going through the INetFwPolicy2 COM object (HNetCfg.FwPolicy2), which is how quieter tooling and some malware implement the same rule-add programmatically from PowerShell, VBA, or a compiled binary — the resulting rule is indistinguishable in the rule store from one added via netsh, which is exactly why detection has to watch the rule store and registry, not just process command lines.
Walkthrough / Exploitation
Reconnaissance establishes current profile state and rule set before changing anything, both to plan the change and to avoid an obviously conspicuous modification:
# Current profile enforcement state and default actions.
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction
# Full rule enumeration for OPSEC review before adding anything.
netsh advfirewall firewall show rule name=all | more
The lower-noise path is a narrowly scoped allow rule rather than disabling a profile — it leaves Enabled=True on every profile (so a simple “is the firewall on” health check reports normal) while still opening exactly the port/program pair the backdoor needs:
:: Scoped allow: firewall stays "on", only this program/port is exempted.
netsh advfirewall firewall add rule name="Update" dir=in action=allow ^
program="C:\Windows\Temp\svchost32.exe" protocol=TCP localport=4444
Where SMB or RDP lateral movement is the goal rather than a custom listener, the same primitive is used to reopen a specific well-known port that local policy had closed, immediately before pivoting with standard tooling:
:: Reopen SMB inbound ahead of a PsExec/WMI pivot.
netsh advfirewall firewall add rule name="File and Printer Sharing" ^
dir=in action=allow protocol=TCP localport=445
Cleanup — netsh advfirewall firewall delete rule name="Update" — removes the trace from the rule store, but the rule-add/delete event pair is exactly what the log-based detections below are built to catch.
Note: Explicit block always beats allow regardless of source, which cuts both ways defensively: a well-placed centrally managed block rule cannot be overridden by a local allow rule, but it also means an attacker with admin rights can add a block rule that silently drops outbound EDR telemetry on a specific port/IP without disabling the firewall or removing any existing rule — worth hunting for as its own pattern, not just permissive allow rules.
Opsec:
netsh advfirewall set allprofiles state offis the single noisiest and least necessary tampering action — it is trivially alerted on and rarely required, since a single scoped rule accomplishes the same goal with far less signal. Programmatic rule creation viaHNetCfg.FwPolicy2COM avoidsnetsh.exe/powershell.exeappearing as the direct actor in process-creation telemetry, so command-line-only detection strategies miss it; the rule store and registry must be watched directly.
Detection and Defense
Both the rule store and the underlying registry/service state are instrumented if the relevant audit subcategory and log are actually collected — they are not on by default in every environment:
- Enable and collect MPSSVC Rule-Level Policy Change auditing (
auditpol /set /subcategory:"MPSSVC Rule-Level Policy Change") so Security-log events 4946 (rule added), 4947 (rule modified), 4948 (rule deleted), and 4950 (setting changed) are generated on every firewall change, regardless of which tool made it. - Collect the Windows Firewall operational log — Microsoft-Windows-Windows Firewall With Advanced Security/Firewall records rule and settings changes with the specific rule details, useful alongside the Security-log events for full context.
- Alert on registry writes under the firewall policy hive — Sysmon Event ID 13 (RegistryEvent value set) on
HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\*catches direct registry tampering that bypassesnetsh/PowerShell entirely. - Baseline expected rules and diff regularly —
netsh advfirewall firewall show rule name=allorGet-NetFirewallRuleexported on a schedule and compared; flag any new rule scoped to a program path outside known-good software inventory. - Watch for BFE/MpsSvc service-state changes — Service Control Manager events (7036/7040) for the Base Filtering Engine or Windows Defender Firewall service stopping is high-severity and rarely legitimate.
- Enforce policy centrally — Group Policy with local rule merging disabled (
Apply local firewall rules = No), plus Microsoft Defender tamper protection, removes the easy administrative path without needing detection to catch every instance. - Enable Windows Firewall logging (
netsh advfirewall set allprofiles logging droppedconnections enable/allowedconnections enable) topfirewall.logfor connection-level evidence when investigating a suspected rule abuse.
Real-World Impact
Firewall rule tampering is catalogued by MITRE ATT&CK as T1562.004 (Impair Defenses: Disable or Modify System Firewall), and it is a routine step in both commodity malware and hands-on-keyboard intrusions — most commonly to open SMB/RDP/WinRM ahead of lateral movement, or to add a permanent allow rule for a backdoor listener so it survives independent of process restarts. Because the underlying WFP architecture is also the foundation every endpoint security product filters traffic through, researchers and vendors have repeatedly documented malicious drivers and callouts that manipulate WFP directly to blind security tooling — a materially rarer but higher-impact variant that ordinary rule-store auditing does not catch, which is why driver-signing enforcement and endpoint tamper protection remain the primary structural defenses against it.
Conclusion
Windows Defender Firewall is a well-behaved consumer of a much deeper kernel filtering framework, and that layering defines two distinct tampering surfaces: cheap, common rule-store and registry changes that any local administrator can make with in-box tools, and rare, harder-to-obtain WFP callout tampering that operates below the rule store entirely. The practical defense for the common case is unglamorous but effective — enable MPSSVC Rule-Level Policy Change auditing, collect the firewall operational log and Sysmon registry events, baseline and diff the rule set, and centralize policy via GPO with local overrides disabled — while driver-signing enforcement and tamper protection carry the weight against the deeper, kernel-level variant.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments