Finding What Deleted Your Windows Firewall Rules

Windows servers that suddenly block all traffic, and start working again when the firewall is turned off, often have a firewall with no rules left in it. The default inbound action blocks anything no rule allows, so an empty rule set looks like a network outage. This post covers how to confirm the rules are gone, how to find the program and account that deleted them, and how to restore them so the same change doesn't remove them again.

A recent r/sysadmin thread had this across servers in several domains at once. The poster later wrote that new Microsoft Defender for Endpoint policies caused it, and reversing that change fixed every server.

Confirm the rules are gone

Count the rules Windows is enforcing right now. The active store is the sum of the local rules, the Group Policy rules, and the Windows service rules.

(Get-NetFirewallRule -PolicyStore ActiveStore | Measure-Object).Count

A count of zero, or a count far below a working server in the same role, confirms the rules were removed. Then check the default actions for each profile.

Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction

Run both commands on one working server as well, so you have a baseline to compare with.

Find what deleted them

The firewall writes its own log under Applications and Services Logs > Microsoft > Windows > Windows Firewall With Advanced Security > Firewall in Event Viewer. Event 2033 reads "All rules have been deleted from the Windows Defender Firewall configuration on this computer." On Windows 11 the same message is event 2059. Event 2006 records a single rule being deleted, and event 2032 records the firewall being reset to its default configuration.

List those events with the time they were written.

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Windows Firewall With Advanced Security/Firewall'; Id=2006,2032,2033,2059} -MaxEvents 30 | Select-Object TimeCreated,Id,Message | Format-List

Each of these events has a Modifying User field and a Modifying Application field. Modifying Application holds the full path of the program that made the change, and Modifying User holds the account it ran as. A path to netsh.exe, powershell.exe, or an installer points at a script or a person. A path to svchost.exe running as SYSTEM is likely a Windows service applying policy, such as Group Policy or device management. Compare the time of the first event with the time the outage started.

When several servers are affected, run the same query on each of them. The same Modifying Application at the same minute on every server points at a central change rather than something local to one machine.

Find where the policy comes from

Rules can come from the local store, from Group Policy, or from a device management service. List the source of every active rule.

Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore | Group-Object PolicyStoreSourceType | Select-Object Name,Count

Run it on the broken server and on a working one. When the working server has rules from GroupPolicy and the broken one has none, check the Group Policy result next.

gpresult /h C:\Temp\gp.html

Open C:\Temp\gp.html in a browser and find the Windows Defender Firewall with Advanced Security section. It names the GPO that sets the firewall policy. A setting that turns off rule merging for local rules means only the rules in that policy apply. When the servers are also managed by Intune or by Microsoft Defender for Endpoint security settings management, check the firewall policies assigned to them there, along with the date each policy was last changed.

Turn on the audit events before the next change

The Security log can also record each rule that is added, modified, or deleted. Enable the audit subcategory on the affected servers, or set it in the GPO that applies to them.

auditpol /set /subcategory:"MPSSVC Rule-Level Policy Change" /success:enable /failure:enable

Event 4946 is then written when a rule is added, 4947 when one is modified, and 4948 when one is deleted. Event 4954 records a change in the firewall Group Policy settings.

Restore the rules

Fix the source first. When the change came from a GPO, an Intune policy, or a Defender for Endpoint policy, reverse it there. A local repair is overwritten at the next policy refresh when the policy still deletes the rules.

When the change was local, restore the default rule set from the server console.

netsh advfirewall reset

The reset removes every rule you added and returns Remote Desktop access to the Windows default, so run it from the console and not over RDP. To bring back your own rules, export the policy from a working server in the same role and import it on the broken one.

netsh advfirewall export "C:\Temp\working.wfw"
netsh advfirewall import "C:\Temp\working.wfw"

Run gpupdate /force afterward, then count the active rules again and compare the count with the working server. Check the Firewall log again the next day in case the same program deletes the rules a second time.

Where ET Ducky shows it

I build ET Ducky, and its Windows agent reads process creation events from the kernel through ETW. The netsh or PowerShell process that ran in the minute before the rules disappeared shows up in that event stream with its parent and its command line. ET Ducky has custom behavior detection by reading kernel logs and can be configured to look for things like this, so a rule that matches a firewall reset or a delete-all command raises an alert when it runs.

When several servers fail at once, you'd start a Multi-Agent Session across a broken server and a working one in the same role. It compares the kernel events from each host to find the shared cause and the outlier, and the raw events stay on the hosts. You can also open a Live Session shell from the browser without the need for a VPN and run the PowerShell commands above on each server.