The Windows host firewall is often the last control standing between a compromised machine and the rest of the network. MITRE ATT&CK T1686.003, Windows Host Firewall, covers adversaries who disable or modify it to bypass limits on network use. It is a Defense Impairment sub-technique of Disable or Modify System Firewall (T1686) and applies to Windows.
How attackers use it
MITRE describes three kinds of change. Adversaries may turn the firewall off entirely, suppress specific profiles (domain, private or public), or add, delete and modify rules to allow or restrict traffic.
There are several ways to do it, depending on the Windows version and the attacker's access level:
- Command line utilities such as
netsh advfirewall, or PowerShell cmdlets like Set-NetFirewallProfile and New-NetFirewallRule. - Registry modifications that change firewall state and rule configuration.
- The Windows Security interface in Control Panel.
The goal is to enable access to remote services, open ports for command and control traffic, or set rules for further actions.
The page's procedure examples show the same shape repeatedly. Malware disables the firewall before binding to a port. Scripts disable the firewall on specific remote machines. Operators add a rule named to look innocent that allows inbound RDP on TCP 3389. One ransomware entry enables the Network Discovery rule group, and another enables remote desktop through firewall rules before moving on.
How to detect it
MITRE's analytic is about correlation. A process or user modifies Windows Defender Firewall profiles, policies or rules, and soon after there is a measurable change in network exposure. The pieces to correlate are:
- Execution of firewall management tools.
- Registry or policy changes.
- Changes to service state.
- Inbound or outbound connections that do not fit baseline administration.
Concrete data to collect on Windows:
| Source | What to look for |
|---|---|
| Process creation with command lines (Sysmon event ID 1, or Security event 4688) | netsh advfirewall with add, set or delete rule, or a state change to off; PowerShell with the firewall cmdlets named above |
| Registry events (Sysmon event ID 13) | Writes under HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy |
| Security log, with the MPSSVC Rule-Level Policy Change audit subcategory enabled | Events 4946 (rule added), 4947 (rule modified), 4948 (rule deleted), 4950 (setting changed) |
| Service control events | The firewall service, mpssvc, stopped or its start type changed |
| Network connection logs | New inbound connections to ports that were closed yesterday |
Most of this works only if the logging is already on. Command line auditing and the firewall audit subcategory are off by default on many builds, so verify before an incident.
Tune out the noise. Software installers and admin tools add rules legitimately, so start with the rules that open remote administration ports, or that are created by a process running from a user profile or temp folder.
How to reduce the risk
All four mitigations on the page restrict who can reach the firewall's controls:
- Restrict file and directory permissions. Make sure process and file permissions stop adversaries from disabling or editing firewall settings.
- Restrict registry permissions. Do the same for registry keys.
- User account management. Give users only the permissions they need. Standard users should never be able to change firewall policy.
- Audit. Routinely check role permissions so only expected users and roles can modify firewalls.
On top of that, manage firewall policy centrally through group policy or your endpoint management tool and turn on local rule merging only where you need it, so rules added on a host do not take effect unnoticed.
Check your own environment
Read-only checks in PowerShell or cmd:
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction
netsh advfirewall show allprofiles
Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow |
Select-Object DisplayName, Profile | Sort-Object DisplayName
auditpol /get /subcategory:"MPSSVC Rule-Level Policy Change"
Work through this list:
- Every profile is enabled on every managed Windows host, or the exception is documented.
- No inbound allow rule exists for RDP unless someone owns it.
- The audit policy returns Success for rule-level changes, and those events reach your log platform.
- Non-admin accounts cannot write to the firewall policy registry key.
- Firewall changes on servers match a change record.
Quick check
Which registry path does MITRE tie to firewall tampering on Windows?
Registry changes under HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy.
Why correlate a firewall change with network exposure changes?
Admins change firewall rules all the time. A change that is followed by new inbound or outbound connectivity that does not fit baseline administration is much more likely to be malicious.
