When an attacker controls the box that enforces your network rules, the rules become theirs. MITRE ATT&CK T1686.002, Network Device Firewall, covers adversaries who disable network device firewall mechanisms or add, delete or modify rules to bypass limits on network use. It is a Defense Impairment sub-technique of Disable or Modify System Firewall (T1686), and applies to network devices.
How attackers use it
MITRE explains that adversaries who reach routers, switches or perimeter devices can change access control lists, security zones or policy rules to permit traffic that was blocked. One example is adding rules that allow access to all internal subnets, which opens paths for command and control and lateral movement.
Access to the management interface may come through valid accounts (T1078) or by exploiting vulnerabilities. Internet-exposed firewalls and other network infrastructure can also be hit through weaknesses in public-facing applications (T1190). The page adds that adversaries may change host networking settings that indirectly affect firewalls, such as interface bandwidth or connection request thresholds.
Procedure examples on the page include a case where an adversary changed security settings on a Fortigate device through its native CLI and disabled traffic logging, and a case where access control lists were edited to add IP addresses that bypass policy.
How to detect it
MITRE's strategy centers on configuration changes. Watch for rule creation, modification or deletion on firewall and network appliances that come from abnormal management IP addresses or from non-console channels such as remote CLI or API. Warning signs include:
- A spike in outbound traffic that was previously blocked.
- Unexpected allow-all rules.
- Bulk rule deletions.
- Changes that follow an unauthorized login, privilege escalation or API abuse.
Disabled logging is its own alarm. If a device stops sending traffic logs, treat it as a possible part of the same event.
How to reduce the risk
- Keep the firewall patched.
- Audit account and role permissions so only expected users and roles can modify firewall settings.
- Apply proper user permissions so ordinary accounts cannot disable or change firewall configuration.
Check your own environment
- Is every change to a perimeter device tied to a ticket and a named admin?
- Are management interfaces reachable only from a small admin network, not the internet?
- Are device configurations backed up and compared so a silent edit shows up?
- Do device logs go to a central system the device itself cannot erase?
Quick check
What should make a firewall rule change suspicious even if the rule looks valid?
Where it came from. A change from an unusual management IP, or through a non-console channel at an odd time, is worth review whatever the rule says.
