Network firewall weakening

Threat snapshot

The Microsoft Defender Firewall is the host-based firewall built into every Windows installation. In domain-joined environments, its configuration is typically managed and enforced through Group Policy, which applies a consistent rule set across all managed endpoints and prevents local users from overriding those rules. This Group Policy enforcement is what gives the firewall its operational value: individual machines cannot selectively weaken their own protections, and changes to the firewall baseline require an approved policy update that applies consistently across the environment.

The netsh.exe command-line utility provides direct access to Windows networking configuration, including the ability to modify firewall rules. One specific netsh capability allows an operator to instruct the Windows Firewall to allow rules defined by Group Policy to take precedence over its own local rules, or conversely, to accept local rules alongside Group Policy-defined rules. Attackers who want to open inbound or outbound connections that Group Policy would block use this mechanism to weaken the Group Policy enforcement boundary without disabling the firewall entirely. The result is a system that appears to have a functioning firewall but has been silently configured to accept rules that bypass the Group Policy baseline. Log360 detects this activity through the Netsh Allow Group Policy on Microsoft Defender Firewall rule.

At a glance

How this attack works

The netsh advfirewall command suite manages the Windows Defender Firewall with Advanced Security. The specific command targeted by this rule modifies how the firewall handles the relationship between locally defined rules and Group Policy-applied rules. The attacker command takes the form:

netsh advfirewall set allprofiles settings localfirewallrules enable

-- or for a specific profile --

netsh advfirewall set domainprofile settings localfirewallrules enable
netsh advfirewall set privateprofile settings localfirewallrules enable
netsh advfirewall set publicprofile settings localfirewallrules enable

When localfirewallrules is set to enable in the context of a Group Policy-managed firewall, the firewall begins merging locally defined rules with the Group Policy-applied rule set. This means an attacker can add their own inbound or outbound allow rules locally on the host, and those rules will take effect even though Group Policy is still nominally in control of the firewall. Without this change, Group Policy-managed firewall configurations typically block local rule additions that conflict with the policy baseline.

The practical use of this technique is to open a specific port or protocol that Group Policy blocks, enabling the attacker to receive reverse shell connections, expose a remote access service, or allow a C2 tool to communicate on a port that the Group Policy firewall rule set would otherwise block. The modification does not disable the firewall, does not generate a Windows Security Center alert, and does not appear as a firewall state change to most monitoring tools that check only whether the firewall is on or off. It is a precision weakening of the Group Policy enforcement layer rather than a blunt firewall disablement.

The distinction between disabling and weakening

Disabling the Windows Defender Firewall entirely is a well-monitored action that generates obvious signals: the Windows Security Center reports a firewall state change, and most endpoint security products alert on it. Weakening the firewall by enabling local rule merging is far less visible. The firewall continues to report as enabled. The Group Policy-applied rules remain in place. Only the enforcement boundary that prevented local rule additions has been removed. From the perspective of most monitoring tools, nothing has changed. This is why this specific technique is favoured by attackers who want to open network access without triggering the obvious firewall-disabled alert.

Attack chain

The table below maps each stage of a network firewall weakening attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A professional services firm manages 200 Windows endpoints via Active Directory Group Policy. The Group Policy-applied Windows Defender Firewall configuration blocks all inbound connections on non-standard ports and restricts outbound traffic to ports 80, 443, and 53 from standard user workstations. A threat actor who gained access via a phishing email has a reverse shell running on a compromised workstation, but the C2 tool they prefer for interactive access uses port 4444 for its interactive session channel, which is blocked by the outbound Group Policy firewall rule.

The attacker runs netsh advfirewall set allprofiles settings localfirewallrules enable from their existing reverse shell session, which is running under a local administrator account they escalated to earlier. They then add a local outbound allow rule for port 4444 using netsh advfirewall firewall add rule. The Group Policy firewall is still reported as enabled by the Windows Security Center, and the firewall state monitoring tool the firm uses shows the firewall as active. Only the local rule merging setting has changed.

Log360 fires the Netsh Allow Group Policy on Microsoft Defender Firewall alert within 60 seconds. The SOC analyst reviewing the alert recognises the localfirewallrules enable argument and cross-references it with recent firewall rule additions on the same host. They find the subsequent netsh firewall add rule command for port 4444 and isolate the host immediately. The C2 connection that was being established via port 4444 is severed before it completes.

Why this happens

netsh.exe is a built-in Windows utility with legitimate administrative uses. Firewall configuration via netsh is a routine task for Windows administrators and is used by software installers, network configuration scripts, and IT management tools. The specific combination of netsh advfirewall with the localfirewallrules enable argument in the Group Policy context is the anomalous element. Most environments do not have monitoring specifically configured for this netsh argument, because the more obvious firewall disablement commands generate their own alerts. The precision of this technique, targeting the Group Policy enforcement boundary rather than the firewall itself, is what allows it to evade common firewall state monitoring.

Business impact: What can go wrong

Weakening the Group Policy-managed firewall baseline has consequences that persist beyond the initial attacker action:

• Group Policy enforcement bypass: enabling local firewall rule merging breaks the operational assumption that Group Policy defines the firewall baseline for all managed endpoints. Any attacker or malicious software that subsequently runs on the host can add its own local firewall rules without being blocked by Group Policy, creating a persistent weakness that outlasts the initial attacker's session.
• Covert network access establishment: the primary purpose of this technique is to open a specific network port that Group Policy blocks. A successfully weakened firewall allows the attacker to receive inbound connections or establish outbound connections on ports that the security team believes are blocked, creating a network access channel that the perimeter or network monitoring tools may not flag as unusual if the port is not explicitly monitored.
• C2 channel persistence: once a C2 port is opened via a local firewall rule on a weakened host, the C2 channel remains available across reboots and Group Policy refreshes if the local rule is not removed. Group Policy refresh will overwrite the localfirewallrules setting, but any local rules already added may persist depending on the specific Group Policy configuration.
• Lateral movement enablement: an attacker who opens an inbound port via the weakened firewall can accept connections from other compromised hosts, enabling lateral movement through the network using the weakened host as a relay or pivot point.
• Trust boundary degradation: an organisation whose Group Policy firewall baseline has been silently weakened cannot rely on that baseline as a network segmentation control until the setting is restored and verified across all affected endpoints. The extent of the weakening may not be fully known without a comprehensive audit.
• Compliance exposure: host-based firewall controls are a requirement under PCI DSS Requirement 1.3, CIS Controls, and ISO 27001 Annex A.13.1. A confirmed firewall weakening event on endpoints handling regulated data constitutes a control failure with audit and reporting implications.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the Netsh Allow Group Policy on Microsoft Defender Firewall rule can fire reliably, ensure the following are in place:

• Windows Process Creation auditing with command-line logging is enabled on all monitored endpoints, generating Event ID 4688 with the full ProcessCommandLine field populated. The rule depends on the netsh advfirewall command-line arguments being visible in the process creation event. Without command-line logging, netsh.exe execution will appear in the log but the advfirewall, localfirewallrules, and enable arguments that constitute the detection anchor will not be captured.
• Sysmon is deployed on all monitored endpoints with a configuration capturing Event ID 1 (Process Create). Sysmon provides enriched process context including the parent process chain, which is essential for determining whether the netsh command was run interactively by an administrator or was invoked by a malware process or a script.
• Windows Firewall auditing is enabled to generate Event ID 4946 (A rule was added to the Windows Firewall exception list). This event provides the details of any firewall rule added after the localfirewallrules setting is changed, identifying the specific port and direction the attacker opened. Enable this under Advanced Audit Policy Configuration > Policy Change > Audit MPSSVC Rule-Level Policy Change.
• Endpoint agents or Windows Event Forwarding are configured to forward Security and Sysmon logs from all monitored endpoints to Log360. Firewall weakening occurs on individual endpoints and the relevant telemetry is endpoint-local. Coverage must include all workstations and servers where the Group Policy firewall baseline is in effect.

Note: The Group Policy-managed Windows Firewall configuration will typically restore the localfirewallrules setting to its Group Policy-defined value at the next Group Policy refresh, which occurs by default every 90 minutes for computers and every 90 minutes with a randomised offset. This means the window during which the weakening is active without Group Policy correction is typically under two hours. The Log360 rule fires on the netsh execution itself, not on the firewall state, so the alert will fire regardless of whether Group Policy has already corrected the setting by the time the alert is reviewed.

Detecting network firewall weakening using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: Netsh Allow Group Policy on Microsoft Defender Firewall. Configure an alert profile for the same. Set the severity to Trouble. The netsh localfirewallrules enable command has a narrow set of legitimate uses and any alert from this rule on a managed endpoint warrants investigation, though the alert does not by itself confirm a successful attack.

Step 2: Read the alert

When the rule fires, the alert will display the hostname, the account that ran netsh.exe, the full command line including the advfirewall arguments, the parent process name and path, and the timestamp. Review the parent process first. An interactive administrator session (cmd.exe or PowerShell invoked by the administrator) from a known management workstation is lower risk. A parent process in AppData, Temp, or a non-standard path is high confidence malicious. Then review whether a subsequent firewall rule addition alert (Event ID 4946) has fired on the same host in the same time window, which would confirm the firewall weakening was followed by a rule addition to open a specific port.

Investigating an alert

When the Netsh Allow Group Policy on Microsoft Defender Firewall rule fires, an L2 analyst should work through the following steps:

• Identify the parent process chain. Open the Incident Workbench and trace the process tree back from netsh.exe. Determine whether the command was run interactively from a command prompt by a named administrator, from a script or scheduled task, or from a process that is itself in a user-writable directory. A malware binary in the parent chain is confirmed high-severity. A script in AppData or Temp is high confidence.
• Check for subsequent firewall rule additions. Query Log360 for Event ID 4946 (Windows Firewall rule added) on the same host in the 10 minutes following the netsh command. If a firewall rule was added after the localfirewallrules setting was changed, identify the specific rule: the port, direction (inbound or outbound), action (allow), and the associated program if specified. This reveals the attacker's network access objective.
• Check for new network connections on the opened port. If a firewall rule addition was found, query Log360 for network connection events from the affected host on the newly opened port in the period following the rule addition. A connection on the newly opened port shortly after the firewall rule was added confirms the attacker has used the weakened firewall to establish network access.
• Assess the current firewall state on the affected host. Determine whether the localfirewallrules setting has already been restored by a Group Policy refresh. If Group Policy has corrected the setting, the vulnerability window may have closed. If the setting persists, either Group Policy has not yet refreshed or something is preventing Group Policy from applying correctly on this host.
• Review preceding activity for the context that led to the firewall change. Query Log360 for all process creation events and network events on the same host in the 30 minutes before the netsh command. Look for the execution vector: a recently opened email attachment, a downloaded file in AppData, an unusual logon from a remote IP, or other indicators of an initial compromise that preceded the firewall weakening.
• Verify with the account owner and change management. Contact the account that ran the netsh command and check the change management system for any approved firewall configuration change on this host. If the account owner cannot confirm the action and no approved change exists, treat the event as confirmed malicious.

Escalation trigger

Escalate immediately to L3 if a firewall rule addition followed the localfirewallrules enable command; if a network connection on the newly opened port was observed shortly after the rule addition; if the parent process of netsh.exe is in AppData, Temp, or any user-writable path; or if the account that ran the command cannot confirm the action and no corresponding change ticket exists. Isolate the host before completing the investigation if active network access through the weakened firewall is confirmed.

Responding and remediating

Immediate containment

• Restore the localfirewallrules setting to its Group Policy-mandated value immediately. Run netsh advfirewall set allprofiles settings localfirewallrules disable, or trigger an immediate Group Policy refresh using gpupdate /force from an administrative session on the affected host. This closes the enforcement boundary bypass and prevents further local firewall rule additions.
• Remove any local firewall rules added after the localfirewallrules setting was changed. Query the local firewall rule set for rules that were added after the timestamp of the netsh command. Delete any rules not attributable to documented software or Group Policy. Use netsh advfirewall firewall delete rule name=<rulename> or the Windows Defender Firewall with Advanced Security console.
• If a network connection was established via the weakened firewall, isolate the host from the network using EDR host isolation. A confirmed C2 or reverse shell connection through the opened port means the attacker has interactive access and must be severed before investigation proceeds.

Forensic preservation

• Export the Windows Security event log and Sysmon operational log from the affected host covering the full period from the first unusual event to the time of containment. These logs contain the netsh execution, any firewall rule additions, and all network connection events during the window the firewall was weakened.
• Capture the current local firewall rule set before removing any attacker-added rules. Use netsh advfirewall firewall show rule name=all or the firewall console to export the complete local rule set. The attacker-added rules are forensic evidence that identifies the specific port and protocol they targeted.
• Document the time window during which localfirewallrules was enabled on the affected host. This window defines the period during which local firewall rules could have been added and network access may have been established through the weakened configuration.

Eradication and recovery

• Scan all other endpoints in the environment for the same netsh advfirewall localfirewallrules enable command in their process creation logs. Query Log360 for the same command pattern across all agents in the preceding 24 hours. A firewall weakening campaign affecting multiple hosts is a strong indicator of scripted post-exploitation activity.
• Review the Group Policy Object controlling the Windows Defender Firewall configuration. Verify the GPO has not been modified to include localfirewallrules enable as an intentional setting, which would mean the Group Policy itself has been tampered with. Any GPO change must be compared against the documented change management record.
• Rotate credentials for the account used to run the netsh command and for any accounts whose credentials were accessible on the affected host during the incident window.

False positive guidance

The netsh advfirewall localfirewallrules enable command has narrow legitimate uses. The following scenarios may produce false positive alerts:

• IT administrative firewall configuration: Windows administrators who are intentionally reconfiguring the firewall to permit local rule merging as part of a documented network change may run this command directly. Verify the account is a named IT administrator, the action aligns with a change ticket, the source is a known administrative workstation, and the change has a documented justification. A legitimate use of this specific command should be rare and documented.
• Software installers modifying firewall settings: some enterprise software products, particularly those that require custom network access profiles, may modify the Windows Firewall Group Policy integration settings as part of their installation. These commands will be run from the installer process, which should be a signed vendor binary in a documented installation directory. Verify the installer is in the approved software list and the command aligns with a documented software deployment window.
• Group Policy configuration management tools: configuration management systems that apply firewall settings directly via netsh rather than through Group Policy may run advfirewall commands as part of their configuration baseline enforcement. These will originate from the configuration management agent process on a predictable schedule. Verify the agent binary is the documented configuration management tool and create a scoped exclusion for that specific process.

Key differentiator

Legitimate uses of netsh advfirewall set localfirewallrules enable are documented, performed by named administrators or signed installer processes, aligned with approved change tickets, and occur during planned change windows. An attacker-initiated use will come from an unrecognised process, a process in a user-writable path, or a remote session from an unrecognised IP, without any corresponding change ticket. The subsequent addition of a local firewall rule immediately after the localfirewallrules setting change is the clearest differentiator: legitimate administrative firewall changes do not typically follow this specific pattern of first enabling local rule merging and then adding a rule for a non-standard port.

Hardening and prevention

The following controls reduce the risk of network firewall weakening via netsh in your environment:

• Enforce the Windows Defender Firewall configuration through Group Policy and explicitly set the localfirewallrules setting to disabled (not configured) in the GPO. A GPO that explicitly disables local rule merging ensures that each Group Policy refresh restores the restrictive setting even if an attacker modifies it locally. The shorter the Group Policy refresh interval, the shorter the window during which a local modification remains in effect.
• Restrict execution of netsh.exe to documented administrative accounts via AppLocker or WDAC policies. On endpoints where netsh is not required for routine operations, blocking its execution entirely eliminates this technique. On endpoints where netsh is needed, restricting which parent processes can invoke it limits the attacker's ability to run it from a malware process.
• Reduce the Group Policy refresh interval on sensitive endpoints from the default 90 minutes to a shorter window such as 15 to 30 minutes. A shorter refresh interval reduces the time during which a locally modified firewall setting remains in effect before Group Policy corrects it, limiting the attacker's window of opportunity.
• Enable Windows Firewall auditing for policy change events (MPSSVC Rule-Level Policy Change) across all endpoints. Event ID 4946 fires when a firewall rule is added and Event ID 4948 fires when a rule is deleted. Forwarding these events to Log360 alongside the process creation events provides complete visibility into the firewall modification sequence.
• Deploy Sysmon with monitoring of the registry path associated with Windows Firewall Group Policy settings under HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy. Registry modification events for this path provide an additional detection layer independent of process creation monitoring.
• Apply the principle of least privilege rigorously to ensure that only documented, named administrators hold local administrator rights on endpoints. The netsh advfirewall firewall modification commands require local administrator rights. Minimising the number of accounts with local admin rights on endpoints reduces the number of footholds from which this technique can be executed.