Listen to this Post
Introduction:
The Windows Filtering Platform (WFP) is Microsoft’s kernel-level framework that unifies network traffic inspection with process identity – a capability that previous technologies like TDI (Transport Driver Interface) and NDIS (Network Driver Interface Specification) could not deliver together. For cybersecurity professionals, understanding WFP is critical because it underpins Windows Firewall, most EDR (Endpoint Detection and Response) agents, and even custom offensive tooling that manipulates network visibility at the deepest OS layers.
Learning Objectives:
- Differentiate WFP from legacy filtering methods (TDI vs NDIS) and explain why Microsoft rebuilt network inspection for Vista and later.
- Enumerate and modify WFP filters using native Windows commands, PowerShell, and low-level API calls for both defense and simulated attack scenarios.
- Implement kernel‑level monitoring rules, detect WFP bypass techniques, and harden systems against abuse of the filtering engine.
You Should Know:
- WFP Architecture Deep Dive: Layers, Callouts, and Filtering
Before Windows Vista, developers had to choose: TDI gave process-to-socket mapping but lacked raw packet access (and was deprecated), while NDIS gave raw packets but no process context. WFP solves this by inserting filter “layers” at various network stack positions (e.g.,FWPM_LAYER_INBOUND_TRANSPORT,FWPM_LAYER_STREAM) – each layer can access metadata like `FWP_CONDITION_ALE_USER_ID` (process ID).
Step‑by‑step guide – enumerate active WFP filters without writing a driver:
1. Open an elevated PowerShell or Command Prompt.
- Use built-in `netsh` to show WFP‑based firewall rules (these are user‑mode representations):
netsh advfirewall show allprofiles netsh wfp show filters (works on newer Windows builds)
- For detailed WFP object enumeration, use PowerShell with the `NetSecurity` module:
Get-1etFirewallFilter Get-1etFirewallRule | Where-Object {$_.Direction -eq 'Outbound'} - To inspect raw WFP objects (layers, sessions, callouts), use the `FwpmFilterEnum` API via a small C script or tool like `WFPExplorer` (open source). Below is a C++ snippet that lists all filters:
include <fwpmu.h> HANDLE engine = NULL; FwpmEngineOpen(NULL, RPC_C_AUTHN_WINNT, NULL, NULL, &engine); FWPM_FILTER_ENUM_TEMPLATE template = {0}; FWPM_FILTER filters = NULL; UINT32 numFilters = 0; FwpmFilterEnum(engine, &template, INFINITE, &filters, &numFilters); - To add a simple blocking filter at the `FWPM_LAYER_ALE_AUTH_CONNECT_V4` layer (process-aware), use `New-1etFirewallRule` – which internally creates WFP objects:
New-1etFirewallRule -DisplayName "Block process Calc.exe" -Direction Outbound -Program "C:\Windows\System32\calc.exe" -Action Block
This rule will prevent Calculator from reaching the network, demonstrating how process identity is enforced at kernel level.
2. Weaponizing WFP for Offensive Tradecraft
Red teams can abuse WFP to hide connections, redirect traffic, or bypass EDR hooks that operate at user‑mode API level (e.g., ws2_32!send). By registering a custom WFP callout driver, an attacker can silently drop or modify packets before any user‑mode agent sees them.
Step‑by‑step guide – implementing a WFP callout for traffic redirection (offensive simulation):
1. Set up a kernel driver project in Visual Studio with WDK – include fwpsk.h.
2. Register a callout at `FWPM_LAYER_ALE_AUTH_CONNECT_V4` with a classify function that inspects `ALE_CONNECT_REDIRECT` fields.
3. Compile and sign the driver (or load using a leaked test certificate on vulnerable systems).
4. Load the driver using `sc.exe` (requires admin/SeLoadDriverPrivilege):
sc create MalWFP type= kernel binPath= C:\path\malwfp.sys sc start MalWFP
5. Use `FwpmCalloutAdd` from user‑mode to add a filter that points to your callout, for example redirecting all HTTP traffic from `svchost.exe` to a proxy.
Mitigation: Enforce driver signing with Device Guard / Hyper-V Code Integrity (HVCI); monitor for new WFP callouts via ETW events: `Microsoft-Windows-FilteringPlatform` channel 5272 (callout registered) and alert on unsigned callouts.
- Defensive Hardening with WFP: Building a Custom EDR Sensor
SOC analysts can leverage WFP to create lightweight, process‑aware network telemetry without installing a full EDR agent. By subscribing to `FWPM_LAYER_ALE_CONNECT_REDIRECT` and logging all outbound connections, you gain the same visibility as NDIS but with PID, executable path, and user SID.
Step‑by‑step guide – PowerShell script to log outbound connections with process details:
Requires Windows 8+/Server 2012+, run as Admin
$startTime = [bash]::UtcNow
$filter = "EventID=5156 (Windows Filtering Platform allowed a connection)"
$query = @"
<QueryList><Query Id='0'><Select Path='Microsoft-Windows-Windows Firewall With Advanced Security/Firewall'>[System[(EventID=5156)]]</Select></Query></QueryList>
"@
$events = Get-WinEvent -FilterXml $query -MaxEvents 50
foreach ($event in $events) {
$procId = $event.Properties[bash].Value
$proc = Get-Process -Id $procId -ErrorAction SilentlyContinue
Write-Output "$($event.TimeCreated) - PID $procId ($($proc.ProcessName)) -> $($event.Properties[bash].Value):$($event.Properties[bash].Value)"
}
To block emerging threat IPs in real‑time using WFP rules:
$badIP = "185.130.5.253" Example C2 New-1etFirewallRule -DisplayName "Block threat IP" -Direction Outbound -RemoteAddress $badIP -Action Block
For kernel‑level logging, develop a lightweight callout driver that writes to an Event Tracing for Windows (ETW) session, avoiding performance impact of user‑mode logging.
- WFP vs eBPF: Linux’s Answer to Kernel Networking Security
Linux lacks a direct WFP equivalent, but eBPF (extended Berkeley Packet Filter) with hooks like `XDP` and `tc` provides similar process‑aware network filtering when combined with cgroup metadata. Understanding both platforms helps defenders translate Windows hardening knowledge to cloud workloads.
Step‑by‑step guide – process‑aware outbound blocking on Linux using eBPF and cgroup v2:
1. Attach an eBPF program to the `BPF_CGROUP_INET_EGRESS` hook. Inside the program, read `bpf_get_current_pid_tgid()` and compare against a map of disallowed PIDs.
2. Compile with `clang -target bpf` and load using `bpftool` or libbpf.
3. Example command to list current connections with PID on Linux:
sudo ss -tp shows TCP sockets with process info
4. To enforce a rule like “block curl from accessing 10.0.0.1”, use `iptables` with owner match (less efficient than eBPF but simpler):
sudo iptables -A OUTPUT -p tcp -d 10.0.0.1 -m owner --pid-owner $(pgrep curl) -j DROP
5. For real‑time WFP‑like telemetry on Linux, use bpftrace:
sudo bpftrace -e 'kprobe:tcp_connect { printf("PID %d connecting to %s\n", pid, ntop(arg2)); }'
The key difference: Linux eBPF is dynamic and scriptable without rebooting or driver compilation, while WFP requires kernel driver signing for callouts – making eBPF more agile for defenders but also more prone to runtime injection attacks.
5. Evading WFP: Common Bypass Techniques and Mitigations
Attackers don’t always fight the kernel – they often disable or corrupt the Base Filtering Engine (BFE) service, which manages all WFP objects. A simpler bypass is to remove blocking filters added by security products.
Step‑by‑step guide – detect and restore tampered WFP configurations:
1. Check BFE service status:
sc query BFE
If stopped, an attacker may have issued `sc stop BFE` or used `FwpmEngineClose` from a driver.
2. Restart BFE and reset firewall to default WFP rules:
sc start BFE netsh advfirewall reset
3. To prevent filter deletion, enable “Windows Firewall” Group Policy: Computer Config → Admin Templates → Network → Network Connections → Windows Defender Firewall → Prohibit deletion of firewall rules.
4. For advanced detection, monitor ETW event `Microsoft-Windows-FilteringPlatform/Operational` ID 5147 (a filter was changed). Create a Sysmon rule:
<EventFiltering> <Rule name="WFP filter change" groupRelation="or"> <EventId>5147</EventId> </Rule> </EventFiltering>
5. Offensive red teams should note that modern EDRs like Microsoft Defender for Endpoint hook WFP classification functions using their own callouts; removing those callouts triggers tampering alerts. Test bypasses only in isolated labs using `FwpmFilterDeleteByKey` from kernel mode.
- API Security and Cloud Hardening with WFP‑like Concepts
While WFP is Windows‑specific, its principle of marrying network visibility with identity extends to cloud environments via Azure Firewall’s application rules (which inspect process names when using Azure Arc‑enabled VMs) and AWS Network Firewall’s Suricata rules with TLS hostname extraction.
Step‑by‑step guide – implement WFP‑style process‑aware filtering in Azure:
1. Deploy Azure Arc on Windows VMs to report process metadata.
2. In Azure Firewall Policy, create an application rule collection:
az network firewall application-rule create --1ame "BlockCalc" --firewall-1ame MyFirewall --resource-group MyRG --collection-1ame MyCollection --action Deny --protocols Http=80 Https=443 --source-addresses 10.0.0.0/24 --target-fqdns "" --rule-type ApplicationRule
(Note: native Azure Firewall does not filter by process ID; for that, use Defender for Cloud’s adaptive application controls.)
3. For Kubernetes clusters, deploy Cilium with eBPF-based network policy:
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: block-specific-process spec: endpointSelector: matchLabels: app=myapp egress: - toCIDR: - 185.130.5.253/32 toPorts: - ports: [bash]
This bridges on‑prem WFP concepts to cloud‑native “zero trust” micro‑segmentation.
What Undercode Say:
- Key Takeaway 1: WFP is not just a firewall API – it’s the mandatory framework for any serious Windows network visibility, and both EDRs and rootkits live inside its callout infrastructure.
- Key Takeaway 2: Offensive operators must understand WFP layers to evade EDRs that rely on user‑mode hooks; conversely, defenders need to audit WFP callouts and enable HVCI to block unsigned kernel filtering drivers.
Analysis (10 lines):
Undercode emphasizes that Microsoft created WFP because security tools needed both packet content and process context – a requirement that TDI/NDIS couldn’t meet. Today, WFP is a double‑edged sword: it powers Windows Defender Firewall and advanced EDR sensors, but the same callout mechanism can be used by sophisticated malware to hide C2 traffic or prevent security agents from seeing network events. The most concerning blind spot is that many organizations never audit WFP callouts, assuming that `netsh advfirewall` shows the whole picture – but a malicious driver can add silent filtering rules that bypass management APIs. Defenders must monitor ETW events for callout registration (Event ID 5272) and use code integrity policies to allow only Microsoft‑signed WFP drivers. On the offensive side, WFP knowledge is mandatory for Pro‑Hacker rank on HTB PROLABS like PUPPET & MYTHICAL, where kernel filter bypasses are often required. The full deep‑dive promised by the original author will likely reveal how modern EDRs use `FWPM_LAYER_STREAM` for TLS interception – and how attackers can `FwpmCalloutDelete` to blind them.
Prediction:
- +1 Demand for WFP auditing tools will surge as more incident responders discover that user‑mode EDR telemetry can be blinded by a single kernel callout.
- -1 Attackers will weaponize AI to generate polymorphic WFP callout drivers that automatically adapt to filter enumeration detections.
- +1 Microsoft will introduce eBPF for Windows, eventually deprecating kernel callouts in favor of a safer, sandboxed filtering API – reducing rootkit risks.
- -1 Until eBPF arrives, most enterprises will remain unaware of WFP’s existence, leaving a massive gap between their firewall logs and actual network traffic.
- +1 Cloud providers (Azure, GCP) will translate WFP’s identity‑aware network model into serverless policies, enabling per‑function egress filtering.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Muaaztalaat Why – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
