# Reading the Windows Firewall Log (pfirewall.log) on Windows 11

URL: https://www.mytechnician.tech/labs/read-windows-firewall-log-pfirewall-windows-11/
Published: 2026-08-08 | Author: Ankit Kumar
Track: Forensic artifact | Difficulty: Beginner | Authorization: defensive
Time required: 25 min
Verified on: Windows 11 24H2 (build 26100.2894), Hyper-V VM on an internal-only virtual switch
MITRE ATT&CK: T1071
Tags: Network Forensics, Firewall, Forensics, Detection
Summary: Windows Firewall can log every allowed and dropped connection, but the logging is off by default. Here is how to turn it on, read the format, and find outbound traffic that should not be there.

## The Problem With This Artifact

`pfirewall.log` is genuinely useful — it is the only built-in Windows source that records connection destinations without installing anything. It is also **disabled by default**, which means when you actually need it, it usually is not there.

So this article has two halves. Turn it on now, on machines you administer, so the log exists when something goes wrong. And know how to read it when you inherit a machine where someone already did.

## Part 1: Enable Logging

Each firewall profile — Domain, Private, Public — logs separately and must be enabled separately. Machines commonly have it on for one profile and off for the one that was actually in use.

### Step 1: Turn it on for all three profiles

From an elevated PowerShell prompt:

```
netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable
netsh advfirewall set allprofiles logging maxfilesize 32767
```

`maxfilesize` is in kilobytes, and 32767 is the maximum — about 32 MB. The default of 4 MB fills in hours on an active machine, and when it fills Windows rotates the current log to `pfirewall.log.old` and starts fresh, so you get roughly two files' worth of history and no more.

Enabling **allowed** connections as well as dropped is the part people skip. Dropped connections tell you what the firewall stopped. Allowed connections tell you what it did not — which is where the interesting traffic is, because malware that works is malware the firewall permitted.

### Step 2: Confirm it is writing

```
netsh advfirewall show allprofiles logging
```

Then check the file exists and is growing:

```
Get-Item C:\Windows\System32\LogFiles\Firewall\pfirewall.log | Select-Object Length, LastWriteTime
```

If the file is missing after a few minutes of network activity, the most common cause is the log directory's permissions — the `MpsSvc` service account needs write access to `C:\Windows\System32\LogFiles\Firewall`.

## Part 2: Read the Format

The log is plain text, space-delimited, with a header block naming the fields:

```
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
```

A real line looks like:

```
2026-08-08 14:22:19 ALLOW TCP 192.168.1.42 104.18.32.7 51234 443 0 - 0 0 0 - - - SEND
```

The fields worth internalising:

- **`action`** — `ALLOW`, `DROP`, or `INFO-EVENTS-LOST` (the last means the log could not keep up and you have gaps).
- **`src-ip` / `dst-ip`** — for outbound traffic, `dst-ip` is where your machine reached.
- **`dst-port`** — the service. 443 and 80 are web, 53 is DNS, 3389 is RDP.
- **`path`** — `SEND` for outbound, `RECEIVE` for inbound. This is the field that makes the log readable; everything else is symmetric.

**Times are local, not UTC.** This differs from the Windows event log and is the most common mistake when combining the two into one timeline.

### Step 3: Find inbound connections that were allowed

Inbound allows on a home machine are the shortest path to something interesting:

```
Select-String -Path C:\Windows\System32\LogFiles\Firewall\pfirewall.log -Pattern "ALLOW" |
  Where-Object { $_.Line -match "RECEIVE" }
```

Then look at destination ports. `3389` means RDP — cross-check against [RDP session logs](https://www.mytechnician.tech/labs/detect-remote-access-windows-11-rdp-teamviewer-anydesk/). `445` means SMB. Anything high and unfamiliar, accepted repeatedly, is worth identifying.

### Step 4: Look for beaconing

Command-and-control traffic tends to be regular in a way human browsing is not. Extract outbound connections to a single destination and look at the intervals:

```
Select-String -Path C:\Windows\System32\LogFiles\Firewall\pfirewall.log -Pattern "203\.0\.113\.55" |
  ForEach-Object { ($_ -split ' ')[0..1] -join ' ' }
```

Connections at a near-constant interval — every 60 seconds, every 5 minutes, every hour on the hour — are automated. That is not automatically malicious (update checkers and telemetry do the same), but it separates scheduled activity from a person using a browser, and it gives you a start time.

### Step 5: Cross-reference with which process did it

Here is the log's central weakness: **`pfirewall.log` does not record the process**. You get an IP and a port, not the executable.

To close that gap:

- **[SRUM](https://www.mytechnician.tech/labs/srum-srudb-dat-windows-11-forensics/)** — per-application byte counts in roughly hourly buckets. Match the volume against the firewall log's timing to identify the process.
- **Sysmon Event ID 3** — network connection with the full process path. This is the right long-term answer; the firewall log is the fallback when Sysmon was not installed.
- **`netstat -bano`** on a live machine, if the connection is still open.

## What Not To Conclude

**Volume of DROP entries is normal.** An internet-connected machine is scanned constantly. Thousands of dropped inbound connections from random addresses is background noise, not an attack in progress.

**`INFO-EVENTS-LOST` means your log has holes.** Under heavy traffic the logging subsystem drops records. Absence of an entry during a period containing this marker proves nothing.

**No process attribution.** Worth repeating, because it is the single most common overreach with this artifact. An outbound connection to a suspicious IP tells you the machine connected. It does not tell you what connected.

## Related

- [How to tell if a Windows 11 PC was remotely accessed](https://www.mytechnician.tech/labs/detect-remote-access-windows-11-rdp-teamviewer-anydesk/)
- [SRUM on Windows 11](https://www.mytechnician.tech/labs/srum-srudb-dat-windows-11-forensics/)
- Consumer guide: [when Windows Firewall blocks an app you need](https://www.mytechnician.tech/tips/fix-windows-firewall-blocking-apps-windows-11/)

## FAQ

### Where is pfirewall.log on Windows 11?

`C:\Windows\System32\LogFiles\Firewall\pfirewall.log`, with the previous rotation at `pfirewall.log.old` in the same folder. The path is configurable per profile, so if the file is not there, check the configured location with `netsh advfirewall show allprofiles logging`.

### Why is my firewall log empty or missing?

Logging is disabled by default on all three profiles — that is the usual answer. The other common cause is a permissions problem on the log directory: the firewall service account must be able to write to `C:\Windows\System32\LogFiles\Firewall`. Enable logging with `netsh`, generate some traffic, and confirm the file's size is increasing.

### Can I tell which program made a connection from this log?

No. The log records addresses, ports and direction, with no process context at all. Use Sysmon Event ID 3 for connections with full process paths, SRUM for per-application volume that you can time-match, or `netstat -bano` while the connection is still live.

### How much history does the log keep?

One file at the configured maximum size plus one rotated `.old` file. At the 32 MB maximum that is typically days on a normal desktop and hours on a busy one. For anything longer you need to copy the log off on a schedule or forward the events elsewhere — the firewall will not keep it for you.

---

Source: https://www.mytechnician.tech/labs/read-windows-firewall-log-pfirewall-windows-11/ — My Technician Security Labs.
Authorization: defensive. This write-up is published for defensive and educational use on systems you own or are authorized to test.
More labs: https://www.mytechnician.tech/labs/