Windows Security Log · Event 5156

Event 5156: The firewall allowed a connection

Windows recorded a network connection it allowed. Not blocked — allowed. If your Security log has filled up overnight, this is almost certainly why: it fires for every permitted connection in both directions, and on a busy machine that is millions of events a day.

Also written as Event ID 51565156 security log flooding

How oftenFires constantly
Vendor calls itAudit Success
LogSecurity
SourceMicrosoft-Windows-Security-Auditing

What it means for you

On a personal computer

Nothing is wrong. This says your firewall let a connection through, which is what a firewall does thousands of times an hour. It only appears if someone turned on an advanced auditing option — if your Security log is full of these and you did not intend that, turning the setting back off is the fix.

For an analyst

5156 is the poor administrator's Sysmon Event 3: it gives you process-to-connection mapping with no agent installed. That is genuinely useful and it is why people enable it, but the Filtering Platform Connection subcategory has no filtering of its own, so you cannot keep the interesting connections and drop loopback. Enabling it without first raising the Security log size and checking your collection licence is a well-trodden way to lose several days of authentication history to log rollover.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample

The Windows Filtering Platform has permitted a connection.

Application Information:
  Process ID:    4820
  Application Name: \device\harddiskvolume3\program files\contoso\agent.exe

Network Information:
  Direction:     %%14593
  Source Address:   192.0.2.15
  Source Port:      52104
  Destination Address: 198.51.100.20
  Destination Port: 443
  Protocol:      6

Filter Information:
  Filter Run-Time ID: 71295
  Layer Name:    %%14611
  Layer Run-Time ID: 48

The fields that decide it

Everything else in the log line is context.

Application Name: The process that made or accepted the connection, given as a kernel device path such as \device\harddiskvolume3\windows\system32\svchost.exe. Convert it before matching against anything else.
Direction: Whether this machine connected out or accepted a connection in.
Source and Destination Address: The two ends. Loopback traffic between 127.0.0.1 and itself accounts for a large fraction of the volume and carries almost no information.
Destination Port: Where it connected to. This plus the process name is what makes the event worth collecting at all.
Filter Run-Time ID: Which filtering rule permitted it. Resolve it with 'netsh wfp show state' — the number is meaningless on its own and is not stable across reboots.
Layer Name and Layer Run-Time ID: Which stage of the filtering stack made the decision. Mostly useful for telling connect-time decisions from accept-time ones.

Ordinary reasons this happens

Most of the time it is one of these.

Every ordinary outbound connection the machine makes — updates, telemetry, browsers, name resolution.
Loopback traffic between components on the same machine, which is typically the single largest contributor to the volume.
Inbound connections to services the machine is meant to be offering, such as file shares on a server.
Monitoring and management agents polling on a schedule, which produce very regular repeating entries.
Backup software streaming data, which can generate enormous bursts.

When it is not ordinary

A process that should never touch the network making outbound connections.

What gives it awayApplication Name pointing at something like notepad.exe, mshta.exe, or a binary in a temp directory, with an outbound direction and an external destination.

ATT&CK T1071

Beaconing to a command-and-control server.

What gives it awayThe same process and destination pair repeating on a near-constant interval over hours. The regularity is the signal, not any single event.

ATT&CK T1071.001

Data being moved out over an unusual port or protocol.

What gives it awaySustained outbound volume from a process with no business reason, especially to a single destination.

ATT&CK T1048

Lateral movement from this host.

What gives it awayOutbound connections to ports 445, 3389 or 5985 across many internal addresses in a short window.

ATT&CK T1021

What to do next

Decide first whether you meant to enable this. If the Security log is rolling over, that is the actual incident and the audit setting is the cause.
Filter out loopback before doing anything else. Traffic where source and destination are both the local machine is the bulk of the volume and almost none of the value.
Pivot on Application Name rather than on address. The question worth asking is which processes talk to the network, not which addresses are contacted.
Build a list of processes that legitimately make outbound connections on that machine, and alert on anything outside it. That list is short on a server and stable over time.
For a suspicious connection, resolve the Filter Run-Time ID with 'netsh wfp show state' to see which rule allowed it — a rule nobody remembers adding is itself a finding.
Correlate with Event 4688 or Sysmon Event 1 for the process's parent and command line, which 5156 does not carry.
If you want this data long term, prefer Sysmon Event 3, which gives the same mapping with hashes and a filterable configuration.

Queries to run

kql Drops loopback and ranks by process and port. This is the first cut that makes 5156 readable at all.

SecurityEvent | where EventID == 5156 | where DestAddress !startswith '127.' and DestAddress != '::1' | summarize conns = count() by Process = tostring(split(Application, '\\')[-1]), DestPort | order by conns desc

kql Processes contacting many distinct destinations, which finds both scanning and a browser. Baseline before alerting.

SecurityEvent | where EventID == 5156 and Direction == '%%14593' | summarize by Process = tostring(split(Application, '\\')[-1]), DestAddress | summarize dests = dcount(DestAddress) by Process | where dests > 50

powershell Run this before enabling the setting permanently. Multiply by 144 for a daily estimate and check it against your log size.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5156; StartTime=(Get-Date).AddMinutes(-10)} | Measure-Object | Select-Object Count

splunk

index=wineventlog EventCode=5156 dest_ip!=127.0.0.1 | stats count by Application, dest_port | sort -count

Common questions

Why is my Security log full of Event 5156?

Because the Filtering Platform Connection audit subcategory is enabled and it logs every permitted connection, including loopback traffic between local components. On an ordinary workstation that is hundreds of thousands of events a day; on a busy server it is millions. Turn it off with 'auditpol /set /subcategory:"Filtering Platform Connection" /success:disable' unless you specifically want the data.

Does Event 5156 mean something got through my firewall?

It means the firewall allowed a connection according to its rules, which is normal operation rather than a failure. The event exists to record what was permitted, not to warn you. If you want to see what was stopped, look at Event 5157 instead.

Is Event 5156 worth collecting?

Only with a plan for the volume. It gives you process-to-connection mapping without installing anything, which is genuinely valuable on machines where you cannot deploy an agent. But the subcategory cannot be filtered, so you get all of it or none of it. If you can install Sysmon, its Event 3 gives you the same information with hashes and a configuration file to exclude the noise.

What is the Filter Run-Time ID and how do I look it up?

It identifies which Windows Filtering Platform rule made the decision. Run 'netsh wfp show state' as administrator, which writes an XML file, and search it for the ID. Be aware the numbers are assigned at run time and change across reboots, so an ID from last week's event will not resolve today.

Mentioned by

Event 4719: The audit policy itself was changed

Vendor documentation

Last reviewed 6 September 2026