DET0145: Detection of Disabled or Modified System Firewalls across OS Platforms.
This detection strategy is about recognizing when system firewalls are disabled or modified, a behavior MITRE links to the ATT&CK technique Disable or Modi...
Analyst context for executives and security teams
This detection strategy is about recognizing when system firewalls are disabled or modified, a behavior MITRE links to the ATT&CK technique Disable or Modify System Firewall (T1686). For leaders, the practical issue is loss of a basic containment and segmentation control: if an attacker with sufficient privileges can weaken host or network firewall rules, later movement, command traffic, or unauthorized access may become easier and harder to notice.
Executive priority
Treat this as a resilience and control-assurance question: can the organization prove that firewall services, profiles, and rule changes on relevant systems are monitored, reviewed, and recoverable? Because the related technique is categorized under defense impairment and applies to ESXi, Linux, macOS, and network devices, this matters for SOC readiness, incident response scoping, compliance evidence around control integrity, and cyber-physical or operational risk where network devices or virtualization infrastructure support critical services.
Technical view
The supplied ATT&CK object has no official detection text and no platforms listed directly, so validation should be anchored to the related technique T1686. SOC and detection teams should confirm whether they can detect firewall service stoppage, firewall profile disablement, policy or rule-set changes, and newly added rules that permit previously blocked traffic or create unexpected communication paths. IR teams should treat confirmed firewall tampering as possible defense impairment and investigate surrounding privilege use, configuration changes, and network activity before and after the change.
Likely telemetry
- Firewall configuration change logs from ESXi, Linux, macOS, and network devices where applicable
- System service or daemon state changes related to host firewall components
- Administrative command or configuration audit logs showing firewall policy/rule modifications
- Network device configuration change records
- Endpoint or system audit logs tied to privileged user activity
Detection direction
- Baseline expected firewall service states and approved rule sets, then alert on disablement, profile changes, or rule additions outside authorized change windows.
- Correlate firewall modifications with privileged account activity and subsequent network connections to reduce noise and prioritize likely defense-impairment events.
- Tune for legitimate administrative maintenance, software installation, and emergency change activity so alerts focus on unauthorized or unexplained changes.
- Validate coverage separately for each relevant platform named by the related technique: ESXi, Linux, macOS, and network devices; do not assume one telemetry source covers all.
- Include configuration-drift monitoring because the ATT&CK object provides no official detection logic, query, or analytic threshold.
Mitigation priorities
- Define and enforce approved firewall configurations and rule-change procedures for relevant systems.
- Restrict who can disable firewall services or modify firewall policies, especially on virtualization infrastructure, Unix-like hosts, macOS systems, and network devices where applicable.
- Use configuration management or integrity monitoring to detect and restore unauthorized firewall changes.
- Ensure incident response playbooks treat unexpected firewall tampering as a potential defense-impairment event requiring privilege, persistence, and network-activity review.
- Retain audit evidence for firewall changes to support compliance, investigations, and post-incident control validation.
Analyst notes and limits
This Glexia take is based on the detection strategy DET0145 and its relationship to T1686 Disable or Modify System Firewall. The detection strategy itself does not provide an official description, official detection guidance, tactics, or platforms. The practical guidance therefore relies on the relationship context: T1686 is a defense-impairment technique involving changes to firewall services, policies, profiles, or rule sets on ESXi, Linux, macOS, and network devices.
No active exploitation, threat actor attribution, vendor-specific logging, detection query, severity, or guaranteed coverage is provided in the supplied ATT&CK fields. Local architecture, logging configuration, firewall products, administrative workflows, and change-management practices are required to determine actual detection coverage and risk.
Detection of Disabled or Modified System Firewalls across OS Platforms.
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1686 | Disable or Modify System Firewall | This object detects Disable or Modify System Firewall. |
All related ATT&CK context
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 | 1.0 | Current bundle | e3611b9df9a3… |
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 DET0145Open 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.