A Threat Hunter’s Guide to the Windows Filtering Platform

If you’re a threat hunter or incident responder, you know that endpoint visibility is king. While we often focus on process creation and command-line logs, we can sometimes miss the subtle chatter of malicious network activity. What if you could tap into a powerful, native Windows feature to see exactly how applications are interacting with the network, right down to the packet level?

Welcome to the Windows Filtering Platform (WFP).

Today, we’re diving deep into the advanced network auditing capabilities built into modern Windows operating systems. These logs provide a treasure trove of information that can help you uncover stealthy malware, diagnose network issues, and enrich your overall security posture.

What is the Windows Filtering Platform (WFP)?

First things first, let’s clear up a common misconception. Microsoft defines the Windows Filtering Platform (WFP) as a development platform, not a firewall. But for us in the cybersecurity trenches, that distinction is an opportunity.

WFP provides a set of APIs that allows software to interact with the networking stack of the OS. Developers use it to build services that can inspect, modify, or block network packets. Think of it as a series of hooks deep within the Windows networking layers.

For security professionals, this is fantastic news. Because this framework is used to make decisions about network traffic, it also generates a rich stream of audit logs. It’s a built-in choke point between the network hardware and the applications running on a system, giving us incredible visibility.

Available in every version of Windows since Vista and Server 2008, the WFP architecture consists of a few key components:

• Filtering Engine: The core component that processes traffic against defined rules and callouts.

• Base Filtering Engine: Manages the configuration and stores the filter rules.

• Shims: Code that implements the actual filtering decisions, placing them “on the wire.”

• Callouts: Specialized functions for more complex filtering, often used for technologies like IPsec or stateful packet analysis.

By enabling and monitoring WFP audit logs, we can see exactly what this engine is permitting and denying.

First, You Have to Flip the Switch: Enabling WFP Auditing

These powerful logs aren’t enabled by default, likely because they can be quite verbose. If you check your logs and don’t see the Event IDs we’re about to discuss, you need to turn them on.

You can do this via Local Security Policy (secpol.msc) for a single machine or, more effectively, through a Group Policy Object (GPO) in your domain.

Navigate to: Advanced Audit Policy Configuration -> Object Access

Here, you will find several policies related to the Filtering Platform. The two most crucial for our purposes are:

• Audit Filtering Platform Packet Drop

• Audit Filtering Platform Connection

Enable these for Success and Failure to start capturing the events. Remember to tune these for your environment, as they can generate a lot of data on busy systems.

Decoding the Events: Key WFP Logs for Threat Hunting

Once enabled, you can start hunting. Here are the must-know Event IDs and how to use them.

Blocked Traffic: Event ID $5157$ vs. $5150$

This is a critical distinction. While both events signify blocked traffic, they operate at different layers of the network stack.

• Event ID $5150$: The MAC Layer Filter blocked a packet. This block happens at Layer 2. The context is limited to MAC addresses, VLAN tags, and direction (inbound/outbound). You won’t see IP addresses or ports here.

• Event ID $5157$: The Windows Filtering Platform blocked a connection. This is the one you’ll use most often. It operates at Layer 3/4 and is rich with context, including:

  • Process ID (PID) and Application Path

  • Source & Destination IP Addresses and Ports

  • Protocol (TCP/UDP)

  • Direction (Inbound/Outbound)

Hunting Query for $5157$: Look for applications being blocked from making outbound connections that shouldn’t be. For example, why is svchost.exe from a non-standard directory trying to connect to a rare external IP? An attacker might have renamed a tool like Mimikatz, but its network behavior (which gets blocked by a firewall rule) will still trigger a $5157$ event, revealing the true application path.

Permitted Connections: Event ID $5156$

This is the success-based sibling to $5157$. It tells you when the WFP permitted a connection. While much noisier, it’s invaluable for anomaly detection when you have a good baseline of your environment.

Hunting Query for $5156$: Filter for successful connections from unusual applications or to suspicious destinations.

• Does a specific user-land application typically make network connections? Seeing a successful connection from notepad.exe or calc.exe is highly suspicious.

• Monitor for connections to known malicious IP ranges or non-standard ports from legitimate applications like PowerShell or rundll32.exe.

Port Binding and Listening: Event IDs $5158$, $5159$, $5154$, and $5155$

Malware often needs to open a port to listen for commands or to establish a beachhead for lateral movement. These events give you direct visibility into that activity.

• Event ID $5158$: A local port was allowed to be bound by an application. (Success)

• Event ID $5159$: An application was blocked from binding to a local port. (Failure)

These events show you the PID, application path, and the specific port and protocol being used.

A little higher up the stack, you have:

• Event ID $5154$: The WFP allowed an application to listen on a port. (Success)

• Event ID $5155$: The WFP blocked an application from listening on a port. (Failure)

Hunting Query for $5158$ & $5154$: Look for unusual processes successfully binding or listening on ports. If a user without admin rights suddenly has an application binding to port $4444$ or $8080$, it warrants immediate investigation. Compare the application path and name to known TTPs for malware that sets up listeners for C2 or remote access.

Blocked Inbound Traffic: Event ID $5031$

This event is generated when the Windows Firewall service blocks an inbound connection destined for a specific application. It’s less detailed than $5157$ but is excellent for spotting scanning activity or initial access attempts.

Hunting Query for $5031$: Look for a large volume of $5031$ events from a single source IP targeting multiple ports on a host—a classic sign of port scanning. You can also identify if an attacker is trying to connect back to a tool they’ve dropped on the machine, only to be blocked by the local firewall.

Putting It All Together

The Windows Filtering Platform provides a powerful, built-in sensor for deep network analysis right on the endpoint. By enabling these advanced audit logs, you move beyond just seeing that a firewall blocked something; you see which application tried to do it, where it was trying to go, and why it was stopped.

Start by enabling these logs on a small subset of systems to understand your baseline. Once you tune out the noise, you’ll find that these events are an essential data source for hunting down the most elusive threats.