A firewall rule is a promise about what traffic is allowed. MITRE ATT&CK T1686, Disable or Modify System Firewall, covers adversaries who break that promise by disabling or editing host-based or network firewalls. It belongs to the Defense Impairment tactic and applies to ESXi, Linux, macOS, network devices and Windows.
This is the parent technique. Sub-techniques cover cloud firewalls, network device firewalls and the Windows host firewall.
How attackers use it
MITRE explains that once an adversary has enough privileges, they can tamper with firewall services, policies or rule sets to remove limits on inbound or outbound traffic. That can mean turning off firewall profiles, changing existing rules to allow previously blocked ports or protocols, or adding new rules that create hidden communication paths. The page gives an example of adding a rule for a well-known protocol such as RDP on a non-traditional port that is less likely to be scrutinized.
The method depends on the platform. On ESXi, firewall rules can be changed directly with esxcli, for example with the network firewall set command, or through the vCenter user interface.
The page's procedure examples show how common this is. They include malware that edits local iptables rules to redirect an attacker's packets to a shell port, malware that uses netsh to add local firewall exceptions, groups that have opened port 3389 broadly, and ransomware that changes rules to allow remote system discovery or RDP for lateral movement. One entry describes malware that checks for host firewall software and then simulates a mouse click on the pop-up to let its connection proceed.
How to detect it
MITRE's detection strategy has one analytic per platform family.
- Windows. Processes that run netsh, the PowerShell cmdlet Set-NetFirewallProfile or
sc stop mpssvc, plus registry changes underHKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy. - Linux. Rule changes in iptables, nftables or firewalld. A sudden drop in the number of active rules, tied to a suspicious process, is the signal.
- macOS. Changes to PF rules through pfctl, socketfilterfw, or
defaults writeto com.apple.alf. Adversaries often disable profiles or allow a malicious process by name. - ESXi. esxcli network firewall set or vSphere API changes. Disabling rules across management interfaces is a strong signal.
- Network devices. CLI changes to ACLs or rule bases, such as
no access-listor a permit any any rule. Watch configuration commits from unusual users or sessions.
Beyond the commands, compare state with a known good. A rule base that has changed with no change ticket is worth chasing even when you never saw the command.
On Windows, the Security log can record firewall rule and setting changes as events 4946 (rule added), 4947 (rule modified), 4948 (rule deleted) and 4950 (setting changed), once the audit policy for the MPSSVC Rule-Level Policy Change subcategory is on. Process creation logging with command lines, such as Sysmon event ID 1, catches the tool use itself.
How to reduce the risk
The mitigations on the MITRE page are about who and what can change firewall state:
- Audit. Routinely review account role permissions so only expected users and roles can modify system firewalls.
- Restrict registry permissions. Set registry permissions that stop adversaries from disabling or editing firewall settings.
- Restrict file and directory permissions. Set process and file permissions with the same goal.
- User account management. Give users only the permissions they need, and keep firewall administration to a small group.
Add central control. Where you can, push firewall policy from a management plane such as group policy or configuration management so a local change is overwritten and noticed.
Check your own environment
Read-only commands, with the tool named:
# Windows PowerShell: profile state
Get-NetFirewallProfile | Select-Object Name, Enabled
# Windows cmd: same, plus default actions
netsh advfirewall show allprofiles
# Linux (iptables): list active rules without changing anything
sudo iptables -S
# Linux (nftables)
sudo nft list ruleset
# Linux (firewalld)
sudo firewall-cmd --list-all
# ESXi shell: firewall status
esxcli network firewall get
Then ask four questions:
- Is any profile or firewall service off on a host that should have it on?
- Are there inbound rules for remote access on unusual ports?
- Do rule counts match your baseline across a fleet?
- Who holds the right to change firewall settings, and does that list match your records?
Quick check
Why watch for a sudden drop in the number of active Linux firewall rules?
Because flushing or replacing rules is a quick way to remove restrictions, and the count is easy to baseline. A drop tied to an unexpected process is a strong sign of evasion.
Which two controls from MITRE limit who can change firewall settings?
User account management, which keeps permissions to the minimum, and Audit, which reviews role permissions so only expected users and roles can modify firewalls.
