Blinding EDRs: A deep dive into WFP manipulation

This article complements existing research referenced in the Further Reading section.

Endpoint Detection and Response (EDR) solutions are essential to modern defensive architectures. Their abilities to monitor, block, and respond to threats are important for containment and remediation. However, like all complex systems, EDRs rely on components that can be turned against them. One of those components is the Windows Filtering Platform (WFP), which many EDRs leverage for network traffic control and endpoint isolation.

In this article, we explore how WFP can be manipulated to either block an EDR’s connection to its cloud backend or bypass its isolation mechanisms. Both cases can effectively “blind” the EDR or reduce its effectiveness.

We observed that certain EDRs show reduced detection and response capabilities when disconnected from their cloud infrastructure. This prompted us to investigate how WFP configuration can affect an EDR’s cloud communication. During testing, we found that the same mechanism underpins the product’s “isolation” mode, meaning that manipulating WFP rules can also be leveraged to bypass its network containment features.

Introduction to the Windows Filtering Platform (WFP)

The WFP is a core component introduced with Windows Vista that provides deep packet inspection and filtering capabilities at various layers of the network stack. It was designed to replace older models of packet filtering, such as NDIS hooking (kernel-mode) and Winsock SPI hooking (user-mode), which were harder to maintain and less flexible.

WFP is implemented via the fwpuclnt.dll library and interfaces tightly with the network stack using internal hooks. It allows for:

  • Permit/block decisions on packets, based on complex matching conditions (IP addresses, ports, process name, application path, etc.).
  • Deep inspection of packets at both user-mode and kernel-mode, supporting both simple filters and advanced kernel callouts.
  • High granularity and control, since it operates below the Windows Firewall, which itself is just a consumer of the WFP API.

The WFP technology is used by:

  • Windows Defender Firewall
  • Third-party antivirus and EDR systems
  • Network monitoring agents
  • Intrusion prevention systems (IPS)
  • Parental control and content filtering solutions
  • …

Key WFP Concepts

To understand how to manipulate WFP filters, we need to clarify its internal structure.

Developers can leverage WFP from both user-mode and kernel-mode. While user-mode interaction covers common filtering scenarios, kernel-mode access provides the ability to directly examine or modify packet data. Implementing custom logic at this level requires developing a specialized WFP component known as a Callout Driver.

To effectively use WFP, understanding its core components and evaluation logic is essential:

  • Filter: The rule itself. It comprises:
    • Conditions: Criteria for matching traffic (e.g., source IP, destination port, application path).
    • Action: What to do if conditions match (Permit, Block, or Callout for further processing by a driver).
    • Flags: Additional attributes that can modify filter behavior (e.g., FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT, FWPM_FILTER_FLAG_PERSISTENT).
    • Weight to determine the precedence.
  • Layer: A specific point in the network stack where inspection occurs. Traffic is classified against filters at these layers. Each layer essentially hooks into a specific stage of packet processing.
  • Sublayer: A container for organizing filters within a layer. Sublayers have weights, determining their precedence.
  • Provider: A way to group multiple sublayers and filters, often associated with a specific application or service (e.g., “Windows Firewall Provider,” “My Custom EDR Provider”).
  • Callout: A function in a kernel driver that WFP invokes when a filter with a “Callout” action matches. Callouts can perform deep packet inspection, modify packets, or veto a connection. This ability to issue a final veto is what defines a Terminating Callout—an irreversible action returned by the driver that definitively blocks or permits traffic and cannot be overridden by any other filters.

Practical use of WFP

Filter Evaluation Logic:
The WFP engine processes traffic through a hierarchical evaluation:

  1. Within a Layer: The engine evaluates filters across its constituent sublayers. Sublayers themselves are processed in order of their priority (or weight).
  2. Within a Sublayer: Filters are sorted by their individual weight, from highest to lowest. The engine evaluates these filters sequentially until a definitive PERMIT or BLOCK action is encountered and the conditions matched. Once such a decision is made for that sublayer, any remaining lower-priority filters within that same sublayer are typically ignored for that specific packet.
  3. Precedence: A BLOCK action from an evaluated filter will override a PERMIT action. Certain flags, like FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT, can also enforce the “hardness” of a permit or block decision. A hard BLOCK will have the priority over a hard PERMIT which will have the priority over a soft BLOCK which will have the priority over a soft PERMIT.

The evaluation logic could be summarized with the schema below.

Although two sublayers permit the traffic, a single sublayer denies it, resulting in the traffic being blocked.

Key WFP layers often targeted or used by security products include:

  • FWPM_LAYER_ALE_AUTH_RECV_ACCEPT: Application Layer Enforcement (ALE) for incoming connection attempts.
  • FWPM_LAYER_ALE_AUTH_CONNECT: ALE for outgoing connection attempts. These are crucial for controlling which applications can initiate connections.
  • FWPM_LAYER_INBOUND_TRANSPORT: For inspecting inbound transport layer data.
  • FWPM_LAYER_OUTBOUND_TRANSPORT: For inspecting outbound transport layer data.
  • FWPM_LAYER_IPPACKET_INBOUND/OUTBOUND: For raw IP packet inspection.
Schema from https://zeronetworks.com/blog/wtf-is-going-on-with-wfp

This article will demonstrate how EDRs utilise WFP and how these mechanisms can sometimes be turned against them.

Two Faces of EDR: Local vs. Cloud Intelligence

EDRs can broadly be categorized by where their primary “intelligence” or decision-making logic resides:

  1. Local Intelligence EDRs:
    • Pros: Can be highly effective even when the endpoint is isolated from the internet.
    • Cons: The detection logic is on the endpoint, making it more vulnerable to reverse engineering and local tampering.
  2. Cloud-Reliant EDRs:
    • Pros: Detection logic and threat intelligence are kept in the cloud, making them highly resistant to on-endpoint reverse engineering. Constantly updated.
    • Cons: Effectiveness can be significantly reduced if the endpoint is cut off from its cloud services. Telemetry and advanced analysis depend on this connection.

Our focus is on exploiting the latter’s dependency on cloud connectivity, or manipulating the local rules of either type.

Blocking EDR Cloud Communication

Many EDRs add WFP rules to allow their own agents to communicate with their cloud management and threat intelligence platforms. If these rules are not configured with sufficient protection, an attacker with administrative privileges might be able to override them.

The Weakness:
Some EDRs add PERMIT rules for their C2 communication with:

  • Low weight: Making them easy to override with a higher-weight BLOCK rule.
  • No FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT flag: This flag, when not set on a filter, means that its decision (permit/block) is soft and can be overridden by a hard decision.

The Attack:
An attacker can enumerate the EDR’s WFP rules (e.g., using PowerShell tools or custom code) to identify its C2 permit rules. Then, they can add a BLOCK filter targeting the EDR’s C2 IP addresses with either:

  • A higher weight than the EDR’s PERMIT rule.
  • In another sublayer with the FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT flag .

This effectively blinds the EDR by cutting off its cloud communication.

Following the publication of blog posts and the use of these attacks, some EDRs have evolved to use the maximum filter weight (0xFFFFFFFFFFFFFFFF), the FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT flag and a terminating callout, making them much harder to override with simple filter additions.

One could attempt to remove the EDR’s filters, but this would generate more Indicators of Compromise (IoCs) and increase the opportunity for detection.
Public tools like shutter or the closed source Fireblock in Nighthawk were developed to tackle WFP manipulation.

Bypassing EDR Network Isolation

During a security incident, a common response action by an EDR or a SOC analyst is to isolate the compromised endpoint. This network isolation is typically implemented using WFP. The EDR adds high-precedence BLOCK rules for most network traffic, often with exceptions for communication back to the EDR management console or specific security tools.

The Weakness:
Similar to their C2 communication rules, the WFP rules an EDR uses for network isolation might also have exploitable weaknesses:

  • Not using maximum weight for their BLOCK rules.
  • Not setting the FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT flag on their blocking filters.

The Attack:
If an attacker has administrative privileges on machine, they can prevent isolation by either:

  • Creating a PERMIT filter with a higher weight
  • Add a PERMIT filter for their desired traffic (e.g., to any destination or to the C2) with the FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT flag.

This effectively punches a hole through the EDR’s network containment.

Again, EDRs that use callouts and correctly configured high-precedence blocking rules are more resilient to this simple bypass.

Detections and Countermeasures

Manipulating WFP filters is not silent. Defenders and EDRs can detect such activities:

  1. Windows Event Logs: Windows generates specific event IDs when WFP components are modified, though this requires enabling the appropriate audit policy. By forwarding these events to a SIEM, security teams can build detections based on the following IDs, assuming the attacker has not disrupted the SIEM connection:
    • 5446: A WFP callout has been changed.
    • 5447: A WFP filter has been changed (added, deleted, modified).
    • 5448: A WFP provider has been changed.
    • 5449: A WFP provider context has been changed.
    • 5450: A WFP sub-layer has been changed.
      Monitoring these event IDs is crucial.
  2. EDR vendors could also implement protections:
    • Hooks/Callbacks: EDRs can register their own callbacks to be notified of WFP changes.
    • Integrity Verification: EDRs can periodically enumerate their WFP rules and compare them against a known-good baseline, alerting on unauthorized modifications.
    • Rules’ healthcheck: When isolated the EDRs could spawn a new process that initiates an outbound connection to an external server. If the connection succeeds, it may indicate that the isolation policy is not fully enforced or has been bypassed.
    • Callout-based Rules: As mentioned, using terminating callouts with high precedence offers strong protection against simple filter manipulation.
  3. Proactive Enumeration:
    Tools like Get-WfpFilterData (part of EDRNoiseMaker ) can be used by defenders to periodically audit WFP filters and identify suspicious rules.

Conclusion and Further Reading

The Windows Filtering Platform is a double-edged sword. While essential for system security and used extensively by EDRs, its complexity and the way it’s sometimes implemented can open doors for attackers with sufficient privileges. By understanding WFP’s mechanics—layers, sublayers, filters, weights, and flags like FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT—attackers can devise strategies to “blind” EDRs or bypass their network isolation.

However, EDR vendors continue to strengthen their products by deploying more resilient WFP configurations, advanced callouts, and enhanced self-protection mechanisms. Since the first publications describing these attacks, the implementation of WFP rules in EDR solutions has significantly evolved. Defenders should ensure comprehensive logging and monitoring of WFP modifications to detect such tampering attempts.

For those interested in exploring further, these resources are valuable: