Skip to content
T1686.002

Disable or Modify System Firewall — Disable or Modify Network Device Firewall

Defense Impairment Last updated:

Adversaries may disable network device-based firewall mechanisms entirely or add, delete, or modify particular rules in order to bypass controls limiting network usage. Modifying or disabling a network firewall may enable adversary C2 communications, lateral movement, and/or data exfiltration that would otherwise not be allowed. For example, adversaries may add new network firewall rules to allow access to all internal network subnets without restrictions. Adversaries may gain access to the firewall management console via Valid Accounts or by exploiting a vulnerability. In some cases, threat actors may target firewalls that have been exposed to the internet. This technique was used by APT38 to create firewall exemptions on specific ports, and by threat actors exploiting Fortinet FortiGate vulnerabilities (CVE-2024-55591) to modify firewall rules before deploying LockBit ransomware.

What is T1686.002 Disable or Modify Network Device Firewall?

Disable or Modify Network Device Firewall (T1686.002) is a sub-technique of Disable or Modify System Firewall (T1686) in the MITRE ATT&CK framework. It maps to the Defense Impairment tactic — the adversary is trying to break security mechanisms, pipelines, and tooling so defenders can’t see or trust what’s happening.

This page provides production-ready detection logic for Disable or Modify Network Device Firewall, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Firewall: Firewall Rule Modification, Firewall: Firewall Disable, Network Traffic: Network Traffic Flow. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Defense Impairment
Technique
T1686 Disable or Modify System Firewall
Sub-technique
T1686.002 Network Device Firewall
Canonical reference
https://attack.mitre.org/techniques/T1686/002/
Microsoft Sentinel / Defender
kusto
let FirewallCommands = dynamic([
  "netsh advfirewall", "netsh firewall",
  "Set-NetFirewallProfile", "New-NetFirewallRule",
  "Remove-NetFirewallRule", "Set-NetFirewallRule",
  "Disable-NetFirewallRule", "netsh advfirewall set allprofiles state off",
  "netsh advfirewall firewall add rule",
  "iptables -F", "iptables -P INPUT ACCEPT",
  "iptables -P FORWARD ACCEPT", "iptables -D",
  "ufw disable", "firewall-cmd --permanent --add-port",
  "nft flush ruleset", "nft delete"
]);
let NetworkDeviceSyslog = dynamic([
  "firewall rule", "access-list", "security-policy",
  "policy delete", "rule delete", "permit any any",
  "action accept", "config firewall policy"
]);
union
(
  DeviceProcessEvents
  | where Timestamp > ago(24h)
  | where ProcessCommandLine has_any (FirewallCommands)
  | extend IsFirewallDisable = ProcessCommandLine has_any ("state off", "set allprofiles state off", "Enabled False", "-F", "flush", "disable")
  | extend IsRuleAdd = ProcessCommandLine has_any ("add rule", "New-NetFirewallRule", "-A INPUT", "-I INPUT", "--add-port", "nft add")
  | extend IsRuleDelete = ProcessCommandLine has_any ("delete rule", "Remove-NetFirewallRule", "-D INPUT", "nft delete")
  | extend AllowsAny = ProcessCommandLine has_any ("action=allow", "-j ACCEPT", "ACCEPT", "permit", "allow")
  | project Timestamp, DeviceName, AccountName, FileName,
           ProcessCommandLine, InitiatingProcessFileName,
           InitiatingProcessCommandLine,
           IsFirewallDisable, IsRuleAdd, IsRuleDelete, AllowsAny,
           DetectionType="HostFirewallManipulation"
),
(
  Syslog
  | where TimeGenerated > ago(24h)
  | where SyslogMessage has_any (NetworkDeviceSyslog)
  | where SyslogMessage has_any ("delete", "disable", "permit any", "accept", "removed", "modified")
  | project TimeGenerated, Computer, HostName, Facility,
           SeverityLevel, SyslogMessage,
           DetectionType="NetworkDeviceFirewallChange"
),
(
  CommonSecurityLog
  | where TimeGenerated > ago(24h)
  | where DeviceVendor in ("Fortinet", "Palo Alto Networks", "Cisco", "Check Point")
  | where Activity has_any ("policy", "rule", "firewall", "security")
  | where Activity has_any ("delete", "modify", "disable", "create", "add")
  | project TimeGenerated, DeviceVendor, DeviceProduct,
           SourceUserName, SourceIP, Activity, Message,
           DetectionType="NetworkFirewallPolicyChange"
)
| sort by TimeGenerated desc

Detects network firewall manipulation across three tiers: (1) Host-based firewall changes on Windows (netsh, PowerShell *-NetFirewall* cmdlets) and Linux (iptables, ufw, nft, firewall-cmd); (2) Network device syslog messages indicating firewall rule changes from routers, switches, and dedicated firewall appliances; (3) CommonSecurityLog entries from enterprise firewall vendors (Fortinet, Palo Alto, Cisco, Check Point) showing policy modifications. Flags whether the change disables the firewall entirely, adds permissive rules, or deletes existing rules.

high severity medium confidence

Data Sources

Process: Process Creation Command: Command Execution Firewall: Firewall Rule Modification Firewall: Firewall Disable Network Traffic: Network Traffic Flow

Required Tables

DeviceProcessEvents Syslog CommonSecurityLog

False Positives

  • Network administrators making planned firewall changes during a documented maintenance window — correlate with change management tickets
  • Infrastructure-as-code deployments (Terraform, Ansible, CloudFormation) that modify firewall rules as part of automated provisioning
  • Software installation scripts that add Windows Firewall exceptions for newly installed applications (e.g., SQL Server, IIS, Docker)
  • VPN or remote access solutions that dynamically add firewall rules when users connect (Cisco AnyConnect, GlobalProtect, Tailscale)

Sigma rule & cross-platform mapping

The detection logic for Disable or Modify Network Device Firewall (T1686.002) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1 Disable Windows Firewall via netsh

    Expected signal: Sysmon Event ID 1: Process Create with Image=netsh.exe, CommandLine='advfirewall set allprofiles state off'. Windows Firewall Event ID 2003: Profile changed (all profiles disabled). Security Event ID 4688 with command line auditing. DeviceProcessEvents in MDE.

  2. Test 2 Add Allow-Any Inbound Firewall Rule via netsh

    Expected signal: Sysmon Event ID 1: Process Create with CommandLine containing 'add rule' and 'action=allow'. Windows Firewall Event ID 2004: New rule added. DeviceProcessEvents in MDE with full command line details.

  3. Test 3 Flush Linux iptables Rules

    Expected signal: Syslog and/or Sysmon for Linux process creation events for iptables with -F, -P INPUT ACCEPT, and -P FORWARD ACCEPT arguments. Linux audit events (SYSCALL) for the iptables binary execution. The network exposure is immediate.

  4. Test 4 Disable UFW Firewall on Linux

    Expected signal: Syslog entry for 'ufw disable' command. Process creation event for the ufw binary. Systemd journal entry for the ufw service state change. Sysmon for Linux (if installed) Event ID 1 for process creation.


Response Playbook

Triage

  1. Identify the specific firewall change — was the firewall completely disabled (state off), was a permissive rule added (allow any/any), or were specific security rules deleted? Complete disablement is highest severity.
  2. Determine WHO made the change — for host firewalls, check the user context and parent process. For network device firewalls, verify the admin session source IP against known administrator workstations and VPN endpoints.
  3. Check the timing — was this change made during business hours from a known location, or outside normal hours from an unusual IP? APT38 and LockBit operators typically make firewall changes during off-hours.
  4. For network device changes: check the authentication method — was it via console, SSH, web GUI, or API? Verify the source IP and check for recent exploit activity against the device (e.g., CVE-2024-55591 for FortiGate).
  5. Verify against change management — is there an approved change ticket, deployment pipeline run, or maintenance window that explains this firewall modification?
  6. Assess the impact — what traffic does the new rule or disabled firewall allow? Does it expose internal services to the internet, allow lateral movement between segments, or open C2 channels?

Containment

  1. If the host firewall was completely disabled: re-enable it immediately — 'netsh advfirewall set allprofiles state on' (Windows) or 'systemctl start firewalld/ufw enable' (Linux).
  2. If a permissive rule was added: delete the malicious rule and review what traffic may have traversed it during the window it was active.
  3. For network device firewall changes: revert to the last known-good configuration from backup. Most enterprise firewalls support configuration rollback (e.g., Fortinet 'execute restore config').
  4. If the firewall change was made via exploited vulnerability (CVE-2024-55591 or similar): immediately patch or isolate the firewall device, rotate ALL admin credentials, and check for additional compromise indicators.
  5. Block the source IP that made the unauthorized change at the network perimeter if it is external.
  6. Enable configuration change alerting on all network firewalls to ensure future changes generate immediate notifications.

Evidence Collection

  1. Firewall configuration diff — capture the current running configuration and compare against the last known-good backup to identify all unauthorized changes.
  2. Network device audit logs — export authentication and configuration change logs from the firewall management plane.
  3. Windows Firewall Event Log — Microsoft-Windows-Windows Firewall With Advanced Security/Firewall Event ID 2004 (rule added), 2006 (rule deleted), 2003 (profile changed).
  4. Process Creation Events — Sysmon Event ID 1 or Security Event ID 4688 for netsh.exe and PowerShell commands that modified firewall rules.
  5. Network Traffic Logs — capture traffic that traversed the permissive rule during the exposure window to assess data exfiltration or C2 communication.
  6. FortiGate/Palo Alto admin session logs — identify the full session timeline of the administrator who made the change, including login, commands, and logout.

Escalation Criteria

  • ! Network device firewall completely disabled or reset to factory defaults — total loss of network segmentation.
  • ! Allow-any rule created for inbound traffic from the internet to internal networks — immediate external exposure.
  • ! Firewall change was made from a source IP that does not belong to any known administrator or management network.
  • ! Multiple firewall rules modified or deleted in rapid succession — indicates automated attack or scripted compromise.
  • ! The firewall change preceded ransomware deployment, lateral movement, or data exfiltration traffic — confirms the change was adversary-driven.
  • ! The change was made by exploiting a known firewall vulnerability (e.g., CVE-2024-55591, CVE-2023-27997) rather than valid credentials.

Investigation Guide

Forensic Artifacts

  • > Windows Firewall Logs: %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log — records allowed and dropped connections based on firewall rules.
  • > Windows Firewall Event Log: Microsoft-Windows-Windows Firewall With Advanced Security/Firewall — Event IDs 2004 (rule added), 2005 (rule modified), 2006 (rule deleted), 2003 (profile changed).
  • > Linux iptables: 'iptables -L -n -v' and 'iptables-save' — current ruleset with packet/byte counters.
  • > Linux nftables: 'nft list ruleset' — current nftables configuration.
  • > FortiGate: 'diagnose sys session list' and 'get system status' — active sessions and system state.
  • > Palo Alto: 'show running security-policy' and 'show log config' — current policy and configuration change log.
  • > Cisco ASA: 'show access-list' and 'show logging' — access control lists and audit log entries.
  • > Network device configuration backups — compare current running-config against last known-good backup from RANCID, Oxidized, or vendor management platform.

Tuning Guidance

This detection covers a wide surface area (host firewalls, Linux firewalls, network device firewalls) and requires tuning per environment. For Windows host firewalls: exclude known software installers by parent process path (e.g., msiexec.exe, setup.exe from trusted vendors) and exclude RMM tools that legitimately manage firewall rules. For Linux: exclude configuration management tools (Ansible, Puppet) by their service account and binary path. For network devices: integrate with your ITSM system to auto-correlate changes with approved tickets — flagging only unticketted changes dramatically reduces noise. Consider tiering severity: complete firewall disable is always CRITICAL, rule deletion is HIGH, and rule addition is MEDIUM (unless it is an allow-any rule, which should also be HIGH). For FortiGate-specific detections, monitor for admin logins from the 'jsconsole' interface which was the exploitation vector for CVE-2024-55591.


Hunting Queries

Hunt specifically for commands that disable the Windows Firewall entirely (all profiles or current profile). This is distinct from adding or removing individual rules — a complete firewall disable is almost never legitimate in an enterprise environment and is a strong indicator of malicious activity or initial access tooling.

Hunting — KQL
kql
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("netsh advfirewall set allprofiles state off", "netsh advfirewall set currentprofile state off", "Set-NetFirewallProfile -Enabled False")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 (CommandLine="*netsh advfirewall set*state off*" OR CommandLine="*Set-NetFirewallProfile*Enabled*False*")
| table _time, host, User, Image, CommandLine, ParentImage, ParentCommandLine
| sort - _time

Hunt for high-volume firewall configuration changes from a single administrator session within a 1-hour window. More than 5 policy changes in an hour from a single source is unusual and may indicate an automated attack modifying multiple rules to open access paths. APT38 created exemptions on ports 443, 6443, 8443, and 9443 in rapid sequence.

Hunting — KQL
kql
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor in ("Fortinet", "Palo Alto Networks", "Cisco", "Check Point")
| where Activity has_any ("policy", "rule", "security")
| where Activity has_any ("create", "add", "modify", "delete")
| summarize ChangeCount=count(), Actions=make_set(Activity) by SourceUserName, SourceIP, DeviceVendor, bin(TimeGenerated, 1h)
| where ChangeCount > 5
| sort by ChangeCount desc
Hunting — SPL
spl
index=network (sourcetype="pan:config" OR sourcetype="cisco:asa" OR sourcetype="fortinet:fortigate:utm")
  ("policy" OR "rule" OR "security") ("create" OR "add" OR "modify" OR "delete")
| bucket _time span=1h
| stats count as ChangeCount, values(action) as Actions by user, src_ip, sourcetype, _time
| where ChangeCount > 5
| sort - ChangeCount

Hunt for overly permissive firewall rules being created — rules that allow traffic to/from any address or any port. These 'allow any' rules are characteristic of adversaries creating broad access rather than surgical exceptions, and are rarely appropriate in production environments.

Hunting — KQL
kql
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("netsh advfirewall firewall add rule", "New-NetFirewallRule")
| where ProcessCommandLine has_any ("any", "0.0.0.0", "localport=any", "remoteport=any")
| where ProcessCommandLine has_any ("allow", "action=allow")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
| sort by Timestamp desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  (CommandLine="*netsh advfirewall firewall add rule*" OR CommandLine="*New-NetFirewallRule*")
  (CommandLine="*any*" OR CommandLine="*0.0.0.0*")
  (CommandLine="*allow*" OR CommandLine="*action=allow*")
| table _time, host, User, Image, CommandLine, ParentImage
| sort - _time

Atomic Red Team Tests

Test 1 Disable Windows Firewall via netsh
windows

Uses netsh to completely disable the Windows Firewall for all profiles (Domain, Private, Public). This is a common first action by adversaries and malware after gaining administrative access to remove network-level controls. Requires administrator privileges.

Command

powershell
netsh advfirewall set allprofiles state off

Cleanup

powershell
netsh advfirewall set allprofiles state on

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=netsh.exe, CommandLine='advfirewall set allprofiles state off'. Windows Firewall Event ID 2003: Profile changed (all profiles disabled). Security Event ID 4688 with command line auditing. DeviceProcessEvents in MDE.

Expected Detection

KQL: DeviceProcessEvents matches on 'netsh advfirewall' with 'state off'. IsFirewallDisable=true. SPL: IsFirewallDisable=1, SeverityScore=3.

Test 2 Add Allow-Any Inbound Firewall Rule via netsh
windows

Creates a permissive Windows Firewall rule that allows all inbound TCP traffic on any port. This simulates an adversary opening a broad inbound access path for C2, reverse shells, or lateral movement tools. The rule is named for easy identification and cleanup.

Command

powershell
netsh advfirewall firewall add rule name="df00tech-test-allow-all" dir=in action=allow protocol=tcp localport=any

Cleanup

powershell
netsh advfirewall firewall delete rule name="df00tech-test-allow-all"

Expected Telemetry

Sysmon Event ID 1: Process Create with CommandLine containing 'add rule' and 'action=allow'. Windows Firewall Event ID 2004: New rule added. DeviceProcessEvents in MDE with full command line details.

Expected Detection

KQL: DeviceProcessEvents matches on 'add rule' and 'action=allow' with AllowsAny=true. SPL: IsRuleAdd=1, AllowsAny=1, SeverityScore=3.

Test 3 Flush Linux iptables Rules
linux

Uses iptables -F to flush (delete) all firewall rules from all chains and sets the default INPUT and FORWARD policies to ACCEPT. This completely opens the Linux host to all network traffic and is the most destructive Linux firewall manipulation. Used by various Linux malware families. Requires root/sudo.

Command

bash
sudo iptables-save > /tmp/iptables-backup.rules && sudo iptables -F && sudo iptables -P INPUT ACCEPT && sudo iptables -P FORWARD ACCEPT

Cleanup

bash
sudo iptables-restore < /tmp/iptables-backup.rules && rm /tmp/iptables-backup.rules

Expected Telemetry

Syslog and/or Sysmon for Linux process creation events for iptables with -F, -P INPUT ACCEPT, and -P FORWARD ACCEPT arguments. Linux audit events (SYSCALL) for the iptables binary execution. The network exposure is immediate.

Expected Detection

KQL: DeviceProcessEvents matches on 'iptables -F' and 'iptables -P INPUT ACCEPT'. IsFirewallDisable=true. SPL: matches on iptables flush commands in linux sourcetypes.

Test 4 Disable UFW Firewall on Linux
linux

Uses the ufw (Uncomplicated Firewall) command to completely disable the firewall on Ubuntu/Debian systems. UFW is a common frontend for iptables/nftables on Debian-based distributions. Requires root/sudo privileges.

Command

bash
sudo ufw disable

Cleanup

bash
sudo ufw enable

Expected Telemetry

Syslog entry for 'ufw disable' command. Process creation event for the ufw binary. Systemd journal entry for the ufw service state change. Sysmon for Linux (if installed) Event ID 1 for process creation.

Expected Detection

KQL: DeviceProcessEvents matches on 'ufw disable'. IsFirewallDisable=true. Syslog query matches on 'ufw disable' in SyslogMessage. SPL: Matched in firewall disable patterns.

Related Detections