Once an intruder has administrator rights, one quiet firewall change can open RDP to the network, create a listening port for a backdoor or block a security tool from reaching its cloud console, and most organisations never alert on it. MITRE ATT&CK v20 tracks this as T1686 Disable or Modify System Firewall under the Defense Impairment tactic (TA0112), on Windows, Linux, macOS, ESXi and network devices. It was formerly a sub-technique of Impair Defenses, so update any detection content still tagged with the old sub-technique ID. This page covers how adversaries tamper with host and device firewalls, the cases ATT&CK and government advisories record, the events that reveal a change on each platform, the v20 mitigations, how to lock firewall policy down centrally, and how to test. It is written for detection engineers, endpoint and server owners and network teams. For the tactic overview, see the ATT&CK Stealth and Defense Impairment Tactics Guide.
Key takeaways
- Modification is more common than disabling. Most recorded procedures add a narrow allow rule (an RDP port, a random high UDP port, WMI) rather than turning the firewall off, so alerting only on "firewall disabled" misses them.
- Windows logs every rule change if you ask it to. Audit MPSSVC Rule-Level Policy Change produces events 4946 (rule added), 4947 (modified), 4948 (deleted) and 4950 (setting changed).
- Central policy beats local rules. Turning off local policy merge for domain and public profiles means a local administrator's new rule has no effect, which removes most of the technique's value on managed Windows hosts.
- Ransomware crews use it at scale. The March 2025 joint advisory on Medusa describes a batch script pushed with PsExec that opens TCP 3389 and enables the remote WMI rule group across the estate.
- ESXi and network devices need their own eyes. Hypervisor and router firewall changes do not reach endpoint tools; they show up only in hostd, syslog and configuration change logs.
What T1686 covers
ATT&CK describes T1686 as disabling or modifying host-based or network firewalls to impair defences and enable further action: turning off firewall profiles, altering existing rules to allow previously blocked ports or protocols, or adding rules that create covert communication paths, such as an allow rule for a well-known protocol on a non-standard port. The technique needs administrative rights, so it usually follows privilege escalation or the use of valid admin credentials.
v20 has three sub-techniques, each with its own page: T1686.001 Cloud Firewall (security groups and cloud network rules), T1686.002 Network Device Firewall (ACLs and rule bases on routers and firewalls) and T1686.003 Windows Host Firewall. This page covers the parent technique and the platforms ATT&CK lists for it, and links the detail where it helps.
| Adversary goal | Typical change | What follows |
|---|---|---|
| Remote access | Allow inbound TCP 3389 or enable a remote management rule group | Remote Desktop (T1021.001) and lateral movement |
| Backdoor listener | Allow a random high TCP or UDP port for a single binary | Command and control that waits for the attacker to connect |
| Blinding security tools | Block outbound traffic from an EDR or antivirus agent to its cloud service | The agent runs but cannot alert or receive updates |
| Ransomware staging | Allow SMB, NetBIOS and RPC between hosts | Mass deployment of the encryptor (T1486) |
| Competition removal | Block traffic for rival malware | Exclusive use of a host for cryptomining |
Real cases
| Actor, software or source | What was recorded | Detection lesson |
|---|---|---|
| Medusa (G1051), CISA AA25-071A, March 2025 | PsExec ran batch scripts as SYSTEM; openrdp.bat created an inbound TCP 3389 rule and enabled the WMI firewall rule group, and set fDenyTSConnections to 0 | The same rule appearing on many hosts within minutes is a ransomware precursor |
| APT29 (G0016), SolarWinds Compromise (C0024) | Used netsh to configure firewall rules that limited certain UDP outbound packets (ATT&CK, citing Microsoft, January 2021) | Changes can restrict traffic too, for example to stop a host reporting |
| Leviathan (G0065), Australian intrusions (C0049) | Modified system firewalls to open listening ports 9998 and 9999 (ATT&CK, citing a 2024 CISA advisory) | Unusual inbound listeners on servers deserve an alert |
| FIN7 (G0046) | Added rules to allow TCP 59999 inbound and sshd.exe on TCP 9898 | Rules for unexpected binaries such as an SSH server on Windows stand out |
| Velvet Ant (G1047) with PlugX (S0013) | Used netsh.exe during PlugX installation to open a random high listening port | Rule name and port randomisation defeats static rule matching; alert on the change itself |
| UNC3886 (G1048) | Used esxcli to modify ESXi firewall rules, alongside a traffic redirection utility | Hypervisor firewall changes need hostd log monitoring |
| RansomHouse MrAgent tool (Trellix, February 2024) | Disables the ESXi firewall at startup with esxcli network firewall set --enabled false | A simple, high-confidence detection on ESXi hosts |
| TeamTNT (G0139) and BPFDoor (S1161) | TeamTNT disabled iptables; BPFDoor changes iptables rules to redirect attacker packets to its shell port | Linux servers and containers need auditd coverage of firewall binaries |
See the Medusa Ransomware Threat Actor Profile for the full chain and the SolarWinds supply chain compromise for the wider intrusion that APT29 ran.
What to detect and where
ATT&CK v20 detection strategy DET0145 has one analytic per platform. All of them watch two things: the tools that change firewall state, and the configuration store that holds it.
| Platform (analytic) | Behaviour | Log sources named in v20 |
|---|---|---|
| Windows (AN0406) | netsh, PowerShell Set-NetFirewallProfile and related cmdlets, or stopping the mpssvc service; registry changes under HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy | Security 4688; Sysmon 13 and 14 |
| Linux (AN0407) | iptables, nft or firewall-cmd changes; a sudden drop in active rules correlated with a suspicious process | auditd execve; osquery process events |
| macOS (AN0408) | pfctl -d, socketfilterfw --setglobalstate off, or changes to com.apple.alf preferences | Unified log |
| ESXi (AN0409) | esxcli network firewall set or vSphere API changes to firewall settings | hostd log |
| Network devices (AN0410) | ACL or rule base changes from the CLI (for example a permit any any or removal of an access list), commits from unusual users or sessions | Device CLI and configuration logs |
Windows: the firewall's own audit events
Process and registry rules catch the tool; the firewall service's own events catch the result, whichever tool made it. Microsoft recommends enabling Audit MPSSVC Rule-Level Policy Change for success and failure on domain controllers, member servers and workstations, and rates its volume as medium.
| Event | Meaning | Use |
|---|---|---|
| 4946 | A rule was added to the exception list | Main signal for new allow rules; alert on rules created outside the Group Policy refresh |
| 4947 | A rule was modified | Widened scope, changed port or program on an existing rule |
| 4948 | A rule was deleted | Removal of block rules; mass deletion (ShrinkLocker deletes all rules during execution, per ATT&CK) |
| 4949 | Settings restored to defaults | Rare in production; investigate |
| 4950 | A firewall setting changed | Profile turned off or default action changed |
| 4954 | Group Policy firewall settings changed and applied | Expected changes; use to separate central policy from local edits |
Also enable the firewall's own connection log. Microsoft recommends logging both dropped packets and successful connections, one file per profile, and a log size of at least 20,480 KB, then forwarding the logs with Windows Event Forwarding or an agent. The log shows whether a new rule was actually used.
Correlations worth building
- Same change, many hosts: an identical rule name or port added on more than a handful of hosts in a short window, outside a change ticket.
- Rule then listener: a 4946 for a port followed by a new process listening on it (Sysmon 3 or EDR network events).
- Rule from a remote execution context: netsh or PowerShell firewall cmdlets spawned by PsExec services, WMI or a remote shell.
- Security agent goes silent: a new outbound block rule followed by an EDR heartbeat gap. See T1685 Disable or Modify Tools Defensive Guide for the agent tampering side.
Mitigations
ATT&CK v20 maps four mitigations to T1686. The table adds how each is applied in practice.
| Mitigation | ATT&CK guidance | How to apply it |
|---|---|---|
| M1047 Audit | Routinely check account role permissions so only expected users and roles can modify system firewalls | Review who holds local admin, ESXi admin and network device config rights; compare live rule sets with the approved baseline monthly |
| M1024 Restrict Registry Permissions | Ensure registry permissions prevent adversaries disabling or modifying firewall settings | Keep default ACLs on the FirewallPolicy keys and alert on changes to them |
| M1022 Restrict File and Directory Permissions | Ensure process and file permissions prevent tampering | Protect nftables, firewalld and pf configuration files; manage them from configuration management |
| M1018 User Account Management | Ensure user permissions prevent disabling or modifying firewall settings | Remove standing local admin rights; use just-in-time elevation |
NHI Mgmt Group recommendations beyond the v20 list:
- Disable local policy merge on Windows: Microsoft documents AllowLocalPolicyMerge settings per profile (CSP path ./Vendor/MSFT/Firewall/MdmStore/DomainProfile/AllowLocalPolicyMerge and equivalents, or the Windows Defender Firewall with Advanced Security GPO). With merge off, rules created by a local administrator are not applied. Microsoft notes this means every app needing inbound connectivity must have a centrally deployed rule, and that local Group Policy firewall settings still apply, so watch for secpol and gpedit changes too.
- Use explicit block rules for high-risk inbound ports: Microsoft documents that explicit block rules take precedence over conflicting allow rules, so a centrally deployed block on inbound RDP from user subnets cannot be overridden by a local allow rule.
- Manage Linux firewalls as code: deploy nftables or firewalld rules from configuration management and alert on drift. See the Linux Firewall Guide.
- Restrict ESXi management: keep hosts in lockdown mode where operations allow, limit firewall rules to management networks and forward hostd logs. See the VMware ESXi Hardening Guide and ESXi Logs Detection Guide.
- Treat network firewall and router config as monitored code: configuration archive, commit logging to a remote syslog and daily diff against the approved baseline. See the Firewall Rule Review Checklist.
Where identity fits
Firewall tampering needs administrator rights, and in real intrusions those rights usually come from a credential, not an exploit. Medusa used valid credentials with PsExec; deployment tools and remote management platforms run under service accounts that are often local administrator on every host. NHI Mgmt Group recommendation: list the service accounts and automation identities that can change firewall policy (software deployment, configuration management, RMM agents, network automation accounts with config write on firewalls), scope each to the hosts it manages, and alert when one of them changes firewall rules outside its normal job. The MITRE ATT&CK T1078 Valid Accounts Guide covers the credential side.
How to test
- Lab first: on a test Windows host, add a firewall rule for an unused port with netsh and with PowerShell, then delete it. Confirm 4688, 4946, 4948 and the Sysmon registry events all arrive and the alert fires.
- Turn a profile off and on: confirm 4950 is captured and the alert names the profile.
- Linux and macOS: add and remove a test rule with nft or firewall-cmd and with pfctl, and confirm auditd and unified log coverage.
- ESXi: in a test cluster, change a firewall ruleset and confirm the hostd entry reaches the SIEM.
- Merge disabled: in a pilot group with local policy merge off, add a local allow rule and confirm traffic is still blocked. Watch the pilot for application breakage for two weeks before wider rollout; roll back by re-enabling merge in the same policy.
- Clean up: remove every test rule and record the test in the change log so later reviews do not chase it.
Measuring coverage
- Audit coverage: percentage of Windows hosts with MPSSVC rule-level auditing enabled and forwarding (target: all).
- Merge disabled: percentage of managed Windows endpoints with local policy merge off for domain and public profiles.
- Unapproved changes: number of firewall rule changes per month not linked to a change ticket or Group Policy refresh, trending down.
- Drift: number of Linux, ESXi and network device firewall configurations differing from the approved baseline.
- Time to detect: median time from a test rule change to alert.
Common failure patterns
- Alerting only on "firewall off": the recorded procedures overwhelmingly add a narrow rule, which this rule never sees.
- Leaving local policy merge on everywhere: any local administrator, human or malware, can add allow rules that Group Policy never removes.
- No hypervisor visibility: ESXi firewall changes are invisible to endpoint tools, and the RansomHouse MrAgent tool disables the ESXi firewall as part of its startup.
- Treating firewall audit noise as a reason to disable it: filter Group Policy refresh events (4954) instead of turning off 4946 to 4948.
- Never reviewing rules: attacker rules named like legitimate ones survive for years without periodic review.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1686 (TA0112 Defense Impairment), sub-techniques T1686.001, T1686.002, T1686.003; formerly a sub-technique of Impair Defenses | Technique, procedures and DET0145 |
| MITRE ATT&CK v20 mitigations | M1047, M1024, M1022, M1018 | Official mitigations listed above |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection; CM-3 Configuration Change Control; CM-5 Access Restrictions for Change | Firewall policy as a controlled configuration item |
| NIST SP 800-53 Rev 5 | AU-12 Audit Record Generation; SI-4 System Monitoring | Rule change auditing and alerting |
| NIST CSF 2.0 | PR.IR-01; PR.PS-01; DE.CM-09 | Network protection, configuration management and monitoring |
The ATT&CK Mitigations hub explains each mitigation in depth.
Related Defense Impairment techniques, each with its own page: MITRE ATT&CK T1690 Prevent Command History Logging, MITRE ATT&CK T1599 Network Boundary Bridging, MITRE ATT&CK T1688 Safe Mode Boot.
Practitioner checklist
- Retag detection content from the former Impair Defenses sub-technique ID to T1686.
- Enable Audit MPSSVC Rule-Level Policy Change and forward events 4946 to 4950.
- Enable firewall logging for dropped and successful connections, one file per profile.
- Disable local policy merge on domain and public profiles for managed endpoints after a pilot.
- Deploy explicit central block rules for inbound RDP, SMB and WinRM from user networks.
- Cover iptables, nft, firewall-cmd, pfctl and socketfilterfw with auditd or EDR process rules.
- Forward ESXi hostd logs and alert on esxcli network firewall changes.
- Log and diff network device and firewall configuration commits daily.
- Scope the service accounts that can change firewall policy and alert on out-of-pattern use.
- Test the full chain quarterly on every platform.
Standards and references
- MITRE ATT&CK: T1686 Disable or Modify System Firewall
- MITRE ATT&CK: DET0145 Detection of Disabled or Modified System Firewalls
- CISA: #StopRansomware Medusa Ransomware (AA25-071A)
- Microsoft Learn: Audit MPSSVC Rule-Level Policy Change
- Microsoft Learn: Windows Firewall rules
- Microsoft Learn: Configure Windows Firewall logging
- Trellix: RansomHouse am see
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Host-Based Firewall Guide · Firewall Management Guide · Defence Evasion Techniques Guide · ESXi Ransomware Playbook · MITRE ATT&CK T1112 Modify Registry