DC0043: Firewall Disable
The deactivation, misconfiguration, or complete stoppage of firewall services, either on a host or in a cloud control plane. Such activity may involve turning off firewalls, modifying rules to disable protection, or deleting firewall-related configurations and activity logs. Examples:
- Disabling Host-Based Firewalls: Stopping the Windows Defender Firewall service or using `iptables -F` to flush all rules on a Linux system. - Cloud Firewall Modification or Deactivation: Modifying or deleting security group rules in AWS or disabling a network firewall in Azure. - Activity Log Deletion: Writing or deleting entries in Azure Firewall Activity Logs to hide unauthorized firewall changes. - Temporary Disable for Malicious Operations: Temporarily disabling a firewall to allow malicious files or traffic, then re-enabling it to avoid detection. - Using Command-Line Tools to Stop Firewalls: Running commands like `Set-NetFirewallProfile -Enabled False on Windows or systemctl stop ufw` on Linux.
This data component can be collected through the following measures:
Cloud Control Plane
- Azure Activity Logs: - Enable logging of administrative actions, such as stopping or modifying Azure Firewall configurations. - Use Azure Monitor to track specific firewall-related actions, including disabling or rule deletion. - AWS CloudTrail Logs: - Monitor `RevokeSecurityGroupIngress` or `RevokeSecurityGroupEgress` events to detect rule changes in AWS Security Groups. - Google Cloud Platform Logs: - Collect logs from the Firewall Rules resource in Google Cloud Operations Suite to detect rule deletions or modifications.
Host-Level Firewalls
- Windows Firewall Event Logs: - Enable logging of firewall state changes: - Security Event ID 2004: Firewall service stopped. - Security Event ID 2005: Firewall service started. - Use Sysmon for process creation events tied to firewall commands or scripts (Sysmon Event ID 1). - Linux Firewall Logs: Use auditd to track commands like iptables, firewalld, or ufw: `auditctl -a always,exit -F arch=b64 -S execve -k firewall_disable` - macOS Firewall: Monitor changes to the macOS Application Firewall using the log show command.
Network-Level Monitoring
- IDS/IPS Alerts: Deploy IDS/IPS systems to monitor abnormal traffic flows that could indicate firewall disablement. - NetFlow Data: Analyze NetFlow or packet capture data for traffic patterns inconsistent with firewall enforcement.
SIEM and CSPM Tools
- SIEM Integration: Use tools like Splunk or QRadar to centralize and analyze firewall disablement events from both hosts and cloud platforms. - Cloud Security Posture Management (CSPM): Use CSPM solutions to monitor misconfigurations and track deactivation of critical cloud services like firewalls.
Analyst context for executives and security teams
Firewall Disable is a high-value evidence source because it captures attempts to weaken or remove a core boundary control on hosts or in cloud control planes. For leaders, the practical issue is not only whether a firewall exists, but whether the organization can prove when it was stopped, misconfigured, bypassed through rule changes, or had related activity logs deleted.
Executive priority
Prioritize this data component where firewall enforcement protects critical systems, cloud workloads, regulated environments, or incident containment paths. The business decision is whether security, cloud, and operations teams have auditable visibility into firewall state changes and rule deletions across host-based firewalls and cloud firewall/security group controls. This supports resilience, compliance evidence, and faster incident decisions when containment controls may have been weakened.
Technical view
SOC, detection engineering, IR, cloud security, and IAM-adjacent teams should validate collection of administrative firewall changes across both host and cloud layers. The supplied ATT&CK description highlights Windows Firewall state changes, Linux firewall command execution via auditd, macOS Application Firewall changes, Azure Activity Logs, AWS CloudTrail events such as security group ingress or egress revocation, Google Cloud firewall rule logs, IDS/IPS alerts, NetFlow, packet capture, SIEM correlation, and CSPM findings. Detection should focus on unauthorized or unexpected firewall service stops, broad rule flushes, rule deletions, cloud firewall deactivation, and activity log deletion or modification associated with firewall administration.
Likely telemetry
- Cloud control plane administrative activity logs for firewall, network firewall, and security group changes
- Azure Activity Logs and Azure Monitor events for firewall configuration changes, disablement, rule deletion, or log activity affecting firewall records
- AWS CloudTrail events for security group rule changes, including RevokeSecurityGroupIngress and RevokeSecurityGroupEgress
- Google Cloud Operations Suite logs for Firewall Rules resource deletion or modification
- Windows Firewall event logs for firewall service stopped or started events, including Event IDs 2004 and 2005 as supplied
Detection direction
- Validate that firewall state changes and rule modifications are logged before an incident; this data component is only useful if administrative and command execution telemetry is retained and searchable.
- Correlate firewall disablement or rule deletion with the actor, identity, source system, change ticket, maintenance window, and affected asset or cloud resource.
- Tune for high-risk patterns such as service stoppage, broad rule flushing, deletion of security group rules, cloud firewall deactivation, and deletion or alteration of firewall activity logs.
- Account for legitimate administrative activity, patching, troubleshooting, automation, and infrastructure-as-code deployments to reduce false positives.
- Look for temporary disable-and-reenable patterns, because short-lived firewall changes may be missed by periodic posture checks alone.
Mitigation priorities
- Establish policy that critical host and cloud firewall changes require authorization, logging, and review.
- Ensure cloud control plane logging and host firewall event logging are enabled and retained centrally in a SIEM or equivalent evidence store.
- Restrict firewall administration to appropriate privileged roles and review access paths for cloud security groups, network firewalls, and host firewall services.
- Use CSPM or configuration monitoring to identify firewall deactivation, unsafe rule changes, or deleted configurations in cloud environments.
- Create incident response playbooks for suspected firewall disablement, including validation of change source, restoration of expected rules, and review for related log deletion.
Analyst notes and limits
This object is a data component, not a technique, and no tactics, platforms, or relationship context were supplied. The official description does provide concrete collection examples across cloud control planes, host-level firewalls, network monitoring, SIEM, and CSPM. Treat this as a coverage-validation item: can the organization observe and explain firewall control changes when they occur?
No official detection text or relationship context was provided. Platforms are marked as not specified, so environment-specific conclusions require local architecture, logging configuration, identity model, and change-management evidence. This summary does not assert active exploitation, attribution, impact, or guaranteed detection coverage.
Firewall Disable
The deactivation, misconfiguration, or complete stoppage of firewall services, either on a host or in a cloud control plane. Such activity may involve turning off firewalls, modifying rules to disable protection, or deleting firewall-related configurations and activity logs. Examples:
- Disabling Host-Based Firewalls: Stopping the Windows Defender Firewall service or using `iptables -F` to flush all rules on a Linux system. - Cloud Firewall Modification or Deactivation: Modifying or deleting security group rules in AWS or disabling a network firewall in Azure. - Activity Log Deletion: Writing or deleting entries in Azure Firewall Activity Logs to hide unauthorized firewall changes. - Temporary Disable for Malicious Operations: Temporarily disabling a firewall to allow malicious files or traffic, then re-enabling it to avoid detection. - Using Command-Line Tools to Stop Firewalls: Running commands like `Set-NetFirewallProfile -Enabled False on Windows or systemctl stop ufw` on Linux.
This data component can be collected through the following measures:
Cloud Control Plane
- Azure Activity Logs: - Enable logging of administrative actions, such as stopping or modifying Azure Firewall configurations. - Use Azure Monitor to track specific firewall-related actions, including disabling or rule deletion. - AWS CloudTrail Logs: - Monitor `RevokeSecurityGroupIngress` or `RevokeSecurityGroupEgress` events to detect rule changes in AWS Security Groups. - Google Cloud Platform Logs: - Collect logs from the Firewall Rules resource in Google Cloud Operations Suite to detect rule deletions or modifications.
Host-Level Firewalls
- Windows Firewall Event Logs: - Enable logging of firewall state changes: - Security Event ID 2004: Firewall service stopped. - Security Event ID 2005: Firewall service started. - Use Sysmon for process creation events tied to firewall commands or scripts (Sysmon Event ID 1). - Linux Firewall Logs: Use auditd to track commands like iptables, firewalld, or ufw: `auditctl -a always,exit -F arch=b64 -S execve -k firewall_disable` - macOS Firewall: Monitor changes to the macOS Application Firewall using the log show command.
Network-Level Monitoring
- IDS/IPS Alerts: Deploy IDS/IPS systems to monitor abnormal traffic flows that could indicate firewall disablement. - NetFlow Data: Analyze NetFlow or packet capture data for traffic patterns inconsistent with firewall enforcement.
SIEM and CSPM Tools
- SIEM Integration: Use tools like Splunk or QRadar to centralize and analyze firewall disablement events from both hosts and cloud platforms. - Cloud Security Posture Management (CSPM): Use CSPM solutions to monitor misconfigurations and track deactivation of critical cloud services like firewalls.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 5674743c1c7f… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0043Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.