{"componentChunkName":"component---src-templates-post-template-js","path":"/a-part-of-anti-virus-3-01-en","result":{"data":{"markdownRemark":{"id":"80237161-84f0-5f40-aa9a-d7f7fab254c9","html":"
\n

This page has been machine-translated from the original page.

\n
\n

In this chapter, I explain the overview and basic architecture of WFP.

\n

When discussing endpoint security on Windows, especially the monitoring and control of network traffic, WFP is a mechanism you cannot avoid.

\n

WFP is used not only by the Microsoft Defender Firewall built into the OS, but also for many other purposes, including endpoint security products such as Antivirus and EDR.

\n

In this chapter, as groundwork for creating tools and drivers that use WFP in Chapter 2 and later, I explain as simply as possible why WFP is used in security products, as well as how its overall structure and components work together to process packets.

\n

What Is WFP

\n

Overview of WFP

\n

WFP is a set of APIs and system services that provides a platform for creating network filtering applications on Windows Vista and Windows Server 2008 and later.

\n

WFP supports IPv4/IPv6 and makes it possible to filter, modify, and re-inject data, as well as handle both packets and streams.\nIt can also provide security until the Base Filtering Engine (BFE) starts during system boot, and handle data both before and after IPsec encryption.1

\n

By using WFP, developers and application vendors can implement a wide range of software for Windows, including firewalls, intrusion detection/prevention systems (IDS/IPS), Antivirus products, and network monitoring tools.

\n

For example, Microsoft Defender Firewall, which is built into Windows by default, also uses WFP to implement a stateful firewall and traffic filtering based on various conditions.2

\n

By actually checking the WFP filters registered in the system with tools such as WFP Explorer, you can confirm that WFP is used by many applications other than firewalls, including Antivirus software and VPN software.

\n

As a platform for creating such network filtering applications, WFP includes facilities for monitoring, receiving, and processing network traffic at every level within the Windows network stack.

\n

The figure below shows the architecture of WFP’s various components.3

\n

\n \n \n \n \n \n \n \n \n

\n

As shown in this architecture diagram, WFP is broadly composed of the following components.\nDetails of each component are described later.

\n\n

WFP in the Windows Network Stack

\n

The figure below, quoted from Inside Windows, 6th Edition, Vol. 1, provides an overview of Windows network components. (At the time of writing, the newer Inside Windows, 7th Edition no longer includes the networking chapter, so I refer to the 6th edition.)4

\n

This figure also shows that WFP performs processing at various levels within the Windows network stack.

\n

\n \n \n \n \n \n \n \n \n

\n

In WFP, filtering operations on network traffic are performed by the filter engine.\nThe filter engine has multiple filtering layers, and at key points in the network stack it matches traffic passed from the Shim (packets/streams/events) against the set of filters registered in each layer to determine the final action.

\n

How WFP Is Used in Endpoint Security

\n

Network traffic is commonly used as the starting point for endpoint intrusion by malicious attackers, such as access to malicious URLs, malware downloads, remote logon attempts, or attacks against services with open ports on the network.

\n

Also, if a device is compromised and an attacker gains access to an organization’s network, network communication is used at many points throughout the attack sequence, including collecting information within the organization’s network, receiving remote-control commands from the outside, expanding the scope of compromise through what is called lateral movement, and leaking confidential information to the outside.

\n

For that reason, monitoring network traffic is one of the most important points from a security perspective.

\n

However, in order to deploy an intrusion detection system such as what is generally called a NIDS (Network Intrusion Detection System), it is necessary to place equipment capable of monitoring traffic on the network path being monitored.

\n

Note: The NIDS described here is different from the Windows Network Driver Interface Specification (NDIS).5

\n

Because of this characteristic, a NIDS can effectively monitor traffic at boundaries such as between an organization’s network and the Internet, but placing network devices between all endpoints within a network is often difficult in terms of operations and cost, and as a result it cannot monitor communication between individual endpoints inside the organization’s network.

\n

\n \n \n \n \n \n \n \n \n

\n

Also, even if communication between endpoints can be monitored to some extent by using a centralized configuration, such as placing network devices in each network segment within the organization, some security challenges still remain.

\n

One of them is that most major network communication today is encrypted with TLS.

\n

If traffic is encrypted with TLS, devices placed on the network path cannot inspect the monitored network data, so monitoring or blocking based on the communication contents generally requires decryption and re-encryption of the traffic through a man-in-the-middle (MiTM) approach, often referred to as TLS inspection.

\n

Another issue is that information collected by network devices on the communication path does not include information about the process (application) on the device that initiated the communication.

\n

As a result, network-device-based monitoring cannot record information about the process that initiated the communication, making it difficult to analyze or investigate traffic in the context of the application.

\n

There are also other issues with network-device-based monitoring, such as being unable to monitor cases where endpoints connect by a method that does not pass through the network equipment, or when devices are connected to networks other than the organization’s network, such as during remote work.

\n

Against the background of issues such as those above with network-device-based NIDS, endpoint-based network monitoring is regarded as an important part of endpoint security measures.

\n

Endpoint-based network monitoring means analyzing and monitoring the network traffic sent and received by a device using services running on the endpoint itself, rather than network equipment on the communication path.

\n

Compared with network-device-based approaches, endpoint-based network monitoring generally has the following advantages.

\n\n

These endpoint-based network monitoring capabilities are provided by various types of software, including Antivirus, EDR, and other network monitoring products.

\n

And the primary platform that such software uses to implement endpoint-based network monitoring on Windows is WFP, which this book explains.

\n

WFP Architecture

\n

In this section, I explain the mechanism by which WFP performs filtering and monitoring of network communication.

\n

The figure below shows the architecture of WFP-related components described in Microsoft’s public documentation.

\n

\n \n \n \n \n \n \n \n \n

\n

As mentioned earlier, WFP is broadly composed of the following components.

\n\n

Filter Engine

\n

The WFP filter engine is a component for performing tasks such as filtering network data, and it exists in both user mode and kernel mode. (UM Filter Engine and KM Filter Engine in the architecture diagram)

\n

The filter engine includes multiple filtering layers mapped to the layers of the Windows network stack.

\n

In particular, on the network and transport layers of the TCP/IP stack, which are important in the security context covered in this book, filter processing and the invocation of Callout functions are handled by kernel-mode components.6

\n

Filtering Layers and Sublayers

\n

A filtering layer (layer) is a container managed by the filter engine and has the function of organizing filters as a set.7

\n

Each layer, which is managed by an internally assigned GUID, defines the kinds of filters that can be added to that layer.8

\n

In addition, each layer is divided into sublayers and evaluated according to the priority (weight) of the sublayers.\nIn addition to the sublayers built into the system by default, developers can also add and define their own.

\n

Filter

\n

A filter is a rule that is matched against received or transmitted packets, streams, events, and so on, and it tells the filter engine how to handle packets, such as blocking traffic that matches certain conditions or invoking a Callout function.

\n

Base Filtering Engine (BFE)

\n

The Base Filtering Engine (BFE) is a user-mode service that coordinates the WFP components.

\n

BFE implements the user-mode API of WFP, manages the platform, and communicates with kernel-mode components.9

\n

The primary tasks of BFE are adding and deleting filters from the system, storing filter configuration, and enforcing WFP configuration security.10

\n

As explained in detail from Chapter 2 onward, applications use the WFP API to request operations from BFE, such as registering filters.

\n

Shim

\n

A Shim is a kernel component that performs “Classifying” for one or more filtering layers.11

\n

A Shim is positioned between the network stack and the filter engine. As packets, streams, and events pass through the network stack, the Shim analyzes them, extracts conditions and values that can be classified, and then calls the filter engine to compare them with filters in a specific layer.

\n

Based on the results of that matching, it allows or blocks specific network traffic in the corresponding network stack.

\n

Put simply, a Shim is a component that provides the WFP filter engine with visibility into packets passing through the Windows network stack.

\n

The following summarizes the flow in which the corresponding Shim determines an action for a packet passing through the network stack based on the result of WFP filter matching.12

\n
    \n
  1. A packet enters the network stack.
    2. \n
  2. The network stack identifies and invokes the appropriate Shim.
    3. \n
  3. The Shim invokes the “Classifying” process at a specific layer.
    4. \n
  4. During the classification process, registered filters are matched and an action is determined according to the result.
    5. \n
  5. If the classification process matches a Callout filter, the corresponding Callout function is invoked.
    6. \n
  6. Based on the final filtering decision, the Shim performs operations such as dropping the packet.
    7. \n
\n

Callout driver

\n

A Callout driver extends WFP’s filtering functionality by registering custom Callout functions with kernel-mode filtering layers in the filter engine.13

\n

WFP Callouts support detailed analysis and modification of packets, and they are also used by security software such as Antivirus.

\n

Filtering Layers and Filters

\n

A filtering layer (layer) is a container managed by the filter engine and has the function of organizing filters as a set.\nAlso, each layer, which is managed by an internally assigned GUID, defines the kinds of filters that can be added to that layer.

\n

There are multiple filtering layers depending on the corresponding network stack.

\n

The following are examples of major WFP filtering layers.

\n\n

For example, when a device makes a TCP connection using IPv4, the TCP connection request is first inspected by the outbound ALE layer (FWPM_LAYER_ALE_AUTH_CONNECT_V4).14\n(The ALE layers support filtering in the application context and are extremely important layers for endpoint security use cases.)

\n

If the TCP connection request passes the ALE layer, the SYN packet is inspected in order by the outbound Transport layer (FWPM_LAYER_OUTBOUND_TRANSPORT_V4) and the outbound IP layer (FWPM_LAYER_OUTBOUND_IPPACKET_V4) before it is sent.15

\n

Data sent after the TCP connection is established is also inspected at the Stream layer (FWPM_LAYER_STREAM_V4), as well as the outbound Transport and IP layers.

\n

Developers can register filters in the appropriate filtering layers according to their goals and use cases.

\n

However, because filters are components that can be added by various applications, situations can arise where filters specifying conflicting handling (permit or block) for specific communication are applied at the same time.

\n

For that reason, WFP defines logic called “Filter Arbitration” to determine the final verdict.16

\n

The following are particularly important factors in how Filter Arbitration makes the final decision.

\n\n

This book does not cover the detailed patterns by which communication is permitted or blocked by the Filter Arbitration logic, but the decision logic at a given filtering layer is basically as follows.

\n
    \n
  1. A layer is divided into sublayers, and network traffic is evaluated in descending order of sublayer priority (Weight).
    2. \n
  2. Within each sublayer, filters whose conditions match are evaluated in descending order of Weight.
    3. \n
  3. As matching filters in a sublayer are evaluated, once “Permit” or “Block” is returned, evaluation of the remaining filters in that sublayer is skipped, and the action of the last evaluated filter becomes the result for that sublayer. (A filter may also return “Continue”.)
    4. \n
  4. For the layer as a whole, the final action is determined by aggregating the results from each sublayer.
    5. \n
  5. Whether overriding is allowed can be controlled for each filter. FWPS_RIGHT_ACTION_WRITE and FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT are used to perform “soft” or “hard” permit/block behavior.\nFor example, a “soft block” may be overwritten by a permit action in another sublayer, but a “hard block” cannot be permitted in a different sublayer, and therefore the block becomes the final verdict.17
    6. \n
\n

The figure below is an illustration of the Filter Arbitration logic quoted from Microsoft’s public documentation.18

\n

Each box inside a layer represents a sublayer, and it shows that after all sublayers in the ALE layer are evaluated, the block action of FW2 (Firewall 2), whose priority as a sublayer is lower than FW1 (Firewall 1), is ultimately used as the final verdict.

\n

\n \n \n \n \n \n \n \n \n

\n

How to Inspect Information About WFP Filters

\n

In this section, I explain how to inspect information about WFP components actually registered in the system and the current state of communication filtering.

\n

Using WFP Explorer

\n

One of the most effective ways to inspect WFP components registered in the system is to use WFP Explorer.

\n

WFP Explorer is a GUI tool published by Pavel Yosifovich, who is also an author of Inside Windows, 7th Edition, and can be downloaded from the following repository.

\n

WFP Explorer

\n

https://github.com/zodiacon/AllTools/blob/master/WFPExp.exe

\n

By using WFP Explorer, you can intuitively browse various information in a GUI, such as the providers and filters registered in the system. (Depending on the security descriptor specified when an application registers filters and so on, the information may not be shown in tools such as WFP Explorer or in the output of netsh commands.)

\n

\n \n \n \n \n \n \n \n \n

\n

netsh wfp show filters

\n

The following command outputs information about filters that include specified conditions.

\n
netsh wfp show filters verbose=ON file=%USERPROFILE%\\Downloads\\wfpfilters.xml
\n

For the conditions, you can specify the protocol, local/remote address or port number, application path, user SID, traffic direction, and so on.

\n

For example, if you want to use the path of the application sending or receiving traffic as a condition, specify the full path of the target application in appid, as in the following example.

\n
netsh wfp show filters verbose=OFF file=%USERPROFILE%\\Downloads\\wfpfilters.xml appid=\"C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe\"
\n

netsh wfp show netevents

\n

The following command outputs recent network events.

\n

You can inspect results such as how WFP filters handled network traffic.

\n
netsh wfp show netevents file=%USERPROFILE%\\Downloads\\wfpnetevents.xml
\n

In the case of netevents as well, you can specify conditions such as the protocol, local/remote address or port number, application path, and user SID.

\n

netsh wfp capture

\n

The following command starts a capture session for network events processed by WFP.

\n

After starting a capture session by running netsh wfp capture start, you can capture events until you run netsh wfp capture stop.

\n
netsh wfp capture start cab=off file=%USERPROFILE%\\Downloads\\wfpdiag\n\nnetsh wfp capture stop
\n

You can inspect network events from the resulting wfpdiag.xml generated by this command.

\n

The following is an excerpt of a drop event contained in wfpdiag.xml.

\n
<netEvent>\n   <header>\n   \t<timeStamp>2026-02-11T01:28:57.540Z</timeStamp>\n   \t<ipVersion>FWP_IP_VERSION_V4</ipVersion>\n   \t<ipProtocol>6</ipProtocol>\n   \t<localAddrV4>192.168.52.236</localAddrV4>\n   \t<remoteAddrV4>8.8.8.8</remoteAddrV4>\n   \t<localPort>50685</localPort>\n   \t<remotePort>80</remotePort>\n   \t<appId>\n   \t\t<asString>\\.d.e.v.i.c.e.\\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.3.\\.p.r.o.g.r.a.m. .f.i.l.e.s. .(.x.8.6.).\\.m.i.c.r.o.s.o.f.t.\\.e.d.g.e.\\.a.p.p.l.i.c.a.t.i.o.n.\\.m.s.e.d.g.e...e.x.e...</asString>\n   \t</appId>\n   \t</header>\n   <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>\n   <classifyDrop>\n   \t<filterId>71422</filterId>\n   \t<layerId>48</layerId>\n   </classifyDrop>\n   <internalFields>\n   \t<terminatingFiltersInfo numItems=\"2\">\n   \t\t<item>\n   \t\t\t<filterId>71422</filterId>\n   \t\t\t<subLayer>32768</subLayer>\n   \t\t\t<actionType>FWP_ACTION_BLOCK</actionType>\n   \t\t</item>\n   \t\t<item>\n   \t\t\t<filterId>69913</filterId>\n   \t\t\t<subLayer>FWPP_SUBLAYER_INTERNAL_FIREWALL_WF</subLayer>\n   \t\t\t<actionType>FWP_ACTION_PERMIT</actionType>\n   \t\t</item>\n   \t</terminatingFiltersInfo>\n   \t<policyAppId/>\n   </internalFields>\n</netEvent>
\n

From this event, you can see that communication by msedge.exe to port 80 on 8.8.8.8 was dropped, as indicated by FWPM_NET_EVENT_TYPE_CLASSIFY_DROP, and that it was evaluated as blocked with FWP_ACTION_BLOCK by the filter with filter ID 71422.

\n

Also, by combining this with information output by netsh wfp show state and similar commands, you can verify that the communication was judged to be blocked at the layer with layerId 48 (FWPM_LAYER_ALE_AUTH_CONNECT_V4) by the filter with filterId 71422 (Block Edge).

\n

Summary

\n

In this chapter, we confirmed that WFP is a filtering platform built into the Windows network stack and that it is widely used to implement Microsoft Defender Firewall, Antivirus, EDR, and similar products.

\n

We also organized the roles of WFP’s main components—the Filter Engine, BFE, Shim, and Callout driver—and the relationships among filtering layers, sublayers, and filters, while explaining how the final permit/block verdict is determined based on the priority of sublayers and filters and whether overrides are allowed.

\n

In the next chapter, I will explain sample code that uses WFP filters from user mode to filter traffic.

\n

Table of Contents

\n\n
\n
\n
    \n
  1. \n

    WFP Features https://learn.microsoft.com/ja-jp/windows/win32/fwp/about-windows-filtering-platform#wfp-features

    \n↩\n
    2. \n
  2. \n

    Inside Windows, 6th Edition, Vol. 1, p.736 (by Mark E. Russinovich, David A. Solomon, Alex Inescu / translated by Quiip Co., Ltd. / Nikkei BP / 2012)

    \n↩\n
    3. \n
  3. \n

    WFP Architecture https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview

    \n↩\n
    4. \n
  4. \n

    Inside Windows, 6th Edition, Vol. 1, p.653 (by Mark E. Russinovich, David A. Solomon, Alex Inescu / translated by Quiip Co., Ltd. / Nikkei BP / 2012)

    \n↩\n
    5. \n
  5. \n

    Overview of NDIS driver types https://learn.microsoft.com/ja-jp/windows-hardware/drivers/network/ndis-drivers

    \n↩\n
    6. \n
  6. \n

    Filter Engine https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview#filter-engine

    \n↩\n
    7. \n
  7. \n

    WFP Operation https://learn.microsoft.com/ja-jp/windows/win32/fwp/basic-operation

    \n↩\n
    8. \n
  8. \n

    Filtering conditions available at each filtering layer https://learn.microsoft.com/ja-jp/windows/win32/fwp/filtering-conditions-available-at-each-filtering-layer

    \n↩\n
    9. \n
  9. \n

    Windows Kernel Programming, Second Edition, p.472 (by Pavel Yosifovich / Independently published / 2023)

    \n↩\n
    10. \n
  10. \n

    Base Filtering Engine https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview#base-filtering-engine

    \n↩\n
    11. \n
  11. \n

    Shims https://learn.microsoft.com/ja-jp/windows/win32/fwp/basic-operation#shims

    \n↩\n
    12. \n
  12. \n

    WFP Operation https://learn.microsoft.com/ja-jp/windows/win32/fwp/basic-operation#wfp-operation-1

    \n↩\n
    13. \n
  13. \n

    Callout Drivers https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview#callout-drivers

    \n↩\n
    14. \n
  14. \n

    Packet Inspection Points https://learn.microsoft.com/ja-jp/windows-hardware/drivers/network/packet-inspection-points

    \n↩\n
    15. \n
  15. \n

    TCP Packet Flows https://learn.microsoft.com/ja-jp/windows/win32/fwp/tcp-packet-flows

    \n↩\n
    16. \n
  16. \n

    Filter Arbitration https://learn.microsoft.com/ja-jp/windows/win32/fwp/filter-arbitration

    \n↩\n
    17. \n
  17. \n

    Configurable Override Policy https://learn.microsoft.com/ja-jp/windows/win32/fwp/filter-arbitration#configurable-override-policy

    \n↩\n
    18. \n
  18. \n

    Filter Arbitration https://learn.microsoft.com/ja-jp/windows/win32/fwp/filter-arbitration

    \n↩\n
    19. \n
  19. \n

    netsh wfp https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/netsh-wfp

    \n↩\n
    20. \n
\n
","fields":{"slug":"/a-part-of-anti-virus-3-01-en","tagSlugs":["/tag/a-part-of-anti-virus-3-en/","/tag/windows-en/","/tag/win-dbg-en/","/tag/anti-virus-en/","/tag/english/"]},"frontmatter":{"date":"2026-04-11","description":"This is the WEB edition of A PART OF ANTI-VIRUS 3 distributed at Tech Book Fest 20.","tags":["A PART OF ANTI-VIRUS 3 (en)","Windows (en)","WinDbg (en)","AntiVirus (en)","English"],"title":"A PART OF ANTI-VIRUS 3 - Learning Windows Filtering Platform (WFP) from Public Sample Code - (WEB Edition) [Chapter 1: Overview and Architecture of WFP]","socialImage":{"publicURL":"/static/272acc1e889df0e25d89217e89d5fd13/a-part-of-anti-virus-3.png"}}}},"pageContext":{"slug":"/a-part-of-anti-virus-3-01-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}