Firewall Event ID 2004: Rule added
- Event ID
- 2004
- Channel
- Microsoft-Windows-Windows Firewall With Advanced Security/Firewall
- Provider
- Microsoft-Windows-Windows Firewall With Advanced Security
- Log file
- Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx
- Category
- Policy changes
- Default logging
- Logged by default
What event 2004 means
Event 2004 is written to the Windows Firewall operational log when a rule is added. Unlike Security event 4946, it is logged by default and contains the full rule definition: program (ApplicationPath), service, Direction, Protocol, LocalPorts, RemotePorts, addresses, Action and Active state.
It also records who made the change: ModifyingUser holds the SID of the account and ModifyingApplication the full path of the process that called the firewall API (netsh.exe, powershell.exe, svchost.exe, an installer). That makes it the best single event for spotting rules created by attackers.
Legitimate software adds rules all the time, so focus on allow rules (Action 3) for programs in user-writable paths, on inbound rules for remote-access ports, and on rules created by scripting tools outside change windows.
When it is logged
Microsoft-Windows-Windows Firewall With Advanced Security/Firewall channel, enabled by default. No audit policy needed.
Newer Windows 10 and Windows 11 builds log rule additions under other event IDs in the same channel (public detection rules such as Sigma match 2071 and 2097 alongside 2004), so hunt on all of them.
Key fields
| Field | What it tells you | ||||||
|---|---|---|---|---|---|---|---|
| RuleId | Unique ID of the rule; matches the value name under HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules. | ||||||
| RuleName | Display name of the rule. | ||||||
| ApplicationPath | Program the rule applies to. Empty when the rule is not tied to a program. | ||||||
| ServiceName | Windows service the rule applies to, if any. | ||||||
| Direction | Traffic direction.
| ||||||
| Protocol | IANA protocol number (6 TCP, 17 UDP, 1 ICMP). | ||||||
| LocalPorts | Local ports covered by the rule (the listening port for inbound rules). | ||||||
| RemotePorts | Remote ports covered by the rule. | ||||||
| Action | What the rule does.
| ||||||
| Profiles | Firewall profiles (Domain, Private, Public) the rule applies to. | ||||||
| RemoteAddresses | Remote addresses the rule is limited to; * or empty means any. | ||||||
| Active | Whether the rule is enabled.
| ||||||
| ModifyingUser | SID of the account that added the rule (S-1-5-18 for SYSTEM). | ||||||
| ModifyingApplication | Full path of the process that added the rule — the most useful field for triage. |
Common benign sources
- Installers and updaters (browsers, Teams, Zoom, VPN clients, games) creating allow rules for their programs.
- Windows servicing (
TiWorker.exe,svchost.exe) and Microsoft Defender adding or refreshing built-in rules. - Administrators running
netsh advfirewall firewall add ruleorNew-NetFirewallRuleduring planned changes.
What attackers do that produces it
- An allow rule for a binary in
AppData,Temp,ProgramDataorC:\Users\Public, created bynetsh.exeorpowershell.exe. - Inbound allow rules for RDP (3389), WinRM (5985/5986), SMB (445) or a custom listener port to enable remote access or tunneling.
- Rules named to look legitimate (e.g. imitating Windows or security products) but pointing to an unexpected path.
Investigation tips
- Filter out known
ModifyingApplicationvalues (TiWorker, MsMpEng, known installers) and review the rest. - Resolve
ModifyingUserto an account and match the time with process creation (4688, Sysmon 1) to get the full command line. - Check the binary in
ApplicationPath(hash, signature, creation time) and any network activity it had afterwards (5156, Sysmon 3). - Look for a later 2006 deleting the same
RuleId, which suggests cleanup.
MITRE ATT&CK techniques
| Technique | Tactics |
|---|---|
| T1686.003 Disable or Modify System Firewall: Windows Host Firewall | Defense Impairment |
MITRE ATT&CK v19.2. Technique and tactic names are MITRE's.
Sigma rules for this event
3 SigmaHQ detection rules (release r2026-07-01) target this event.
- High · 1
- Medium · 2
- HighNew Firewall Rule Added In Windows Firewall Exception List For Potential Suspicious ApplicationRule by frack113, SigmaHQ, DRL 1.1
- MediumNew Firewall Rule Added In Windows Firewall Exception List Via WmiPrvSE.EXERule by frack113, Nasreddine Bencherchali (Nextron Systems), SigmaHQ, DRL 1.1
- MediumUncommon New Firewall Rule Added In Windows Firewall Exception ListRule by frack113, SigmaHQ, DRL 1.1
Rules by their named authors, published by SigmaHQ under the Detection Rule License (DRL) 1.1.
Run these rules on your logs
Drop a .evtx file into the viewer: all 2,395 bundled SigmaHQ rules run locally in your browser. Nothing is uploaded.