How T1686 disable or modify system firewall shows up in intrusions
For a SOC lead, the state of a firewall is a trust anchor. Every alert about lateral movement, command and control or data egress assumes that the host or device is filtering traffic the way its policy says it does. MITRE ATT&CK places techniques that break that assumption under the Defense Impairment tactic, which ATT&CK describes as adversaries trying to break security mechanisms and tooling so defenders can't see or trust what is happening. ATT&CK v19 split this tactic out of Defense Evasion, which kept the ID TA0005 under the name Stealth. T1686 Disable or modify system firewall sits in this new tactic, so detection content written against older Defense Evasion mappings needs review.
At a high level, T1686 lets an intruder change how a system's firewall filters traffic. The change can open paths that were blocked, remove restrictions that limit movement between segments, or switch off the filtering that would otherwise stop a suspicious connection. The technique has three sub-techniques that cover ESXi, Linux, macOS and network devices. For each platform in your estate, confirm the exact sub-technique IDs and names in the v20.0 data, then decide which firewall changes are authorized, which are logged, and who is alerted when a rule set changes outside a change window.
This page targets ATT&CK Enterprise v20.0, released by MITRE on 2026-10-13. Technique IDs, sub-technique structure and mappings can change between releases, and releases can rename, deprecate or revoke techniques. Record the ATT&CK version in every detection mapping, and check the ATT&CK updates page before you adopt or retire a rule. Treat any firewall change that is not tied to an approved ticket as a possible defense impairment event until the owner confirms it.
Which telemetry reveals firewall tampering and which open-source tool collects it
This table maps the data components ATT&CK ties to T1686 (Command Execution, Process Creation, Windows Registry Key Modification, File Modification and Network Traffic Content) to each platform in scope and names the open-source collector for each. Read each row as a question: what evidence would exist if someone changed firewall rules, and which agent or sensor would capture it. Where a row says the appliance must forward logs, confirm that forwarding is enabled before relying on the detection.
| Platform | Primary telemetry | Open-source collector | Where visibility may be absent |
|---|---|---|---|
| Linux hosts | Command Execution and Process Creation for firewall management utilities, plus File Modification on firewall configuration files | Wazuh agents with audit-based command and file monitoring, or Velociraptor artifacts for on-demand collection | Hosts where auditing is not enabled or where configuration changes happen outside monitored paths |
| macOS hosts | Process Creation and Command Execution for packet filter and application firewall administration, plus File Modification on firewall preference files | Wazuh agents for process and file events, with Velociraptor for targeted collection | Endpoints without the agent or with file monitoring scoped to a narrow set of paths |
| Windows hosts | Process Creation for firewall administration commands, Windows Registry Key Modification for firewall policy keys, and Command Execution from scripting hosts | Wazuh agents with Windows event and registry monitoring, Velociraptor for registry and process hunts | Registry auditing is often not enabled by default, so confirm object access auditing is configured on the relevant keys |
| ESXi hosts | Command Execution and Process Creation from the management shell, plus File Modification on host configuration | Syslog forwarding to a Wazuh manager or a central log collector, with Velociraptor only where an agent is supported | Shell and host log forwarding must be configured explicitly, and local logs may be lost on reboot |
| Network devices | Network Traffic Content for management sessions and configuration exports, and device-side configuration change logs | Zeek or Suricata sensors on management network paths, plus syslog forwarding from the device to Wazuh or Security Onion | Many appliances do not forward configuration change logs locally, and encrypted management traffic limits content inspection |
| Cloud and SaaS control planes | Control plane audit events for security group or firewall rule changes, recorded in the provider or platform audit log | Log ingestion into Wazuh or Security Onion from the provider audit feed, where a supported integration exists | Audit log retention and event coverage vary by provider, so confirm which events are logged and how long they are kept |
| Cross-platform evidence | File Modification and Process Creation correlated with a change window and an approved change ticket | Wazuh rules and dashboards correlated with Velociraptor collections for investigation | Without an approved change baseline, legitimate maintenance is hard to separate from tampering |
Detection ideas for firewall disablement and rule changes
These ideas describe detection logic in words for T1686 Disable or modify system firewall across Linux, macOS, Windows, ESXi and network devices. Map each one to the ATT&CK version your team targets, since analytics and data component references change between releases, and confirm which events your platforms actually emit.
Linux and macOS host firewall state
Alert when a host firewall is stopped, its default policy is relaxed, or its rule set is flushed. Build the logic from Command Execution and Process Creation events: a firewall management utility invoked with a disable, stop or flush action, or a firewall configuration file written by a process outside the firewall's own tooling. Baseline which hosts run configuration management that touches these settings, then tune by host group. Expect false positives from patch windows, package upgrades that restart firewall services and configuration management runs. Confirm an approved change ticket before escalating.
Windows firewall profile and service stop
On Windows, combine Process Creation events for firewall management utilities with Windows Registry Key Modification events on the firewall policy settings. Alert when the firewall service is stopped or set to disabled, or when the enable value for a domain, private or public profile changes. Start with an inventory of processes that legitimately write these keys, such as Group Policy refreshes and endpoint security agents. Treat any profile change on a server outside a maintenance window as high priority, and check the change record before closing the alert.
ESXi host firewall configuration
On ESXi, use Command Execution evidence from management sessions and host logs that record firewall rule changes. Alert when the host firewall is disabled, when a service ruleset is opened to broad source ranges, or when a change is made outside vCenter-managed workflows. Confirm with your vSphere logging setup which events reach your SIEM, because some changes may only appear in host logs. Expected false positives include host profile remediation, maintenance mode work and approved vendor patch activity.
Network device configuration change
On network devices, rely on device configuration change logs forwarded through syslog and AAA accounting records. Alert when a deny rule is removed from a boundary access list, when a permit-any entry appears on an external-facing interface, or when logging is turned off on a policy. Corroborate with Network Traffic Flow: a sudden rise in previously blocked sessions after a change is a strong signal. Expect noise from scheduled access list reviews, network automation pushes and vendor firmware upgrades.
Change ticket correlation across platforms
Join every firewall alert to an approved change record using host, timestamp and actor. Keep a documented allowlist of automation identities, such as configuration management service accounts and backup jobs, and review it whenever those pipelines change. Unmatched changes should open an incident, not a ticket queue entry, because an attacker's change will never have a matching record. Test this join in your cyber range by making an authorized change with and without a ticket and confirming the alert outcome for each.
How to validate that the firewall detection fires
This sequence proves, in a private cyber range, that a T1686 firewall change produces an alert your SIEM can route to an analyst, and it records how quickly and how completely that alert appears so tuning decisions rest on evidence.
Agree scope and rules of engagement
The detection owner, the range operator and the platform owner agree in writing which ESXi, Linux, macOS and network device platforms are in scope, which accounts and hosts may be touched, the time window, and how the exercise is stopped. Written rules of engagement also name who approves each change to the range before it runs. The step is done when every party has signed off the scope document and the rollback owner is named.
Choose the platform variant to test
Select which platform variant and sub-technique the exercise targets, based on where your estate actually relies on host or device firewalls. Confirm the sub-technique mapping against the ATT&CK version you are targeting, since releases can rename or revise technique pages. Record the variant, the expected log sources and the detection strategy identifier in the test plan. The step is done when the test plan names one variant per run and the expected telemetry is listed.
Run an approved emulation in the range
An operator on the range runs the agreed emulation of the firewall change against a lab asset that mirrors production logging, with the test plan open and a stopwatch-grade time source recorded for the start of the action. The emulation stays inside the approved scope and the operator logs every step taken. The step is done when the run is complete, the rollback has been confirmed, and the start time is captured for measurement.
Confirm the alert reaches the SIEM
The detection engineer checks that the expected events were collected from the asset, normalized, and matched by the rule in your SIEM, such as Wazuh or a Sigma-derived rule in Security Onion. Confirm the alert was created, routed to the correct queue, and not dropped by an agent, parser or filter. The step is done when the alert identifier is recorded alongside the raw log events that produced it.
Record time to detect, alert fields and gaps
Measure the interval between the recorded action start and the alert creation time, and capture the alert fields that the analyst needs, such as host, user, process, rule and changed setting. Note any missing field, any platform where no alert fired, and any event that arrived late. The step is done when a results sheet lists time to detect, field completeness and each gap with an owner and a next action.
Tune the rule and re-run the emulation
Adjust the rule or log collection to close the gaps found, such as adding a missing log source or correcting a field mapping, and avoid broadening the rule until it floods the queue. Re-run the same emulation under the same rules of engagement and compare the new results with the baseline. The step is done when the second run shows the closed gaps and the change record links both runs.
Store results against the ATT&CK version tested
File the test plan, raw evidence, alert identifiers, timing results and tuning changes in a versioned repository, labeled with the ATT&CK version and the detection strategy identifier that were tested. Review the record against the current ATT&CK updates before the next scheduled exercise, because technique mappings can change between releases. The step is done when the archive is retrievable by ATT&CK version and a reviewer has confirmed it is complete.
Preventive controls that make firewall tampering harder
Firewall tampering succeeds most often when changes go unlogged, when too many accounts can alter rules, and when privileged access is never reviewed. The two ATT&CK mitigations for T1686 Disable or modify system firewall, Audit (M1047) and User Account Management (M1018), address these gaps together. The cards below set out what each control covers and what to confirm in your own environment.
Enable and centralize firewall change audit trails
Turn on auditing for host firewall configuration, hypervisor firewall rules and network device configuration changes, then forward those events to a central store that the host's administrators cannot edit. Confirm that every firewall platform in scope writes a change event, including who made the change, the time, and the before and after state. Ask whether logs are retained long enough for your investigation and compliance needs, and whether anyone can clear them without an alert. A log gap on a firewall host should itself raise an alert.
Restrict administrative rights on hypervisors
Limit who can modify firewall rules on ESXi hosts, virtual distributed firewalls and cloud security groups to a named administrative group. Separate the people who run workloads from those who change network policy, so that a compromised workload account cannot disable a host-level rule. Confirm which hypervisor roles can edit firewall settings, and whether those roles are assigned through directory groups that your identity team reviews. Verify that break-glass accounts are documented, stored securely and monitored when used.
Restrict administrative rights on hosts and devices
On Linux, macOS, Windows and network devices, grant firewall administration only to accounts that need it, and require privilege elevation to be logged. Remove local administrator rights from general user accounts where possible. For network devices, confirm that administrative access is limited to dedicated management networks and that local accounts are kept to a minimum. Ask your team to list which accounts can stop or reconfigure the host firewall service, since this list is often longer than expected.
Review privileged accounts on a fixed schedule
Run a recurring review of every account that can change firewall policy, covering both human and service accounts. Remove accounts for people who have changed roles or left, and confirm that each service account has a named owner and a documented purpose. Compare the review results against the audit logs, so that any firewall change made by an account that should not hold the right is flagged. Confirm the review cadence with your compliance lead and keep the signed review record as evidence.
Alert on firewall changes outside change windows
Correlate firewall change events with approved change records so that an edit made outside a planned window, or without a matching ticket, produces an alert for the security team. Define which rule changes count as high risk, such as disabling a default-deny policy or flushing all rules. Confirm that the alert reaches a team that can respond within your agreed hours. Test the correlation with a planned change in your cyber range before relying on it in production.
Triage and response when a firewall change alert fires
The first decision on a firewall change alert is whether the change was authorized, and the fastest way to answer it is to match the alert against change records for that host or device and the time window in which it fired. Confirm the approved change before anyone touches the host. Then identify the device, the account that made the change and the process or session it came from. For an ESXi host, a Linux server, a macOS endpoint or a network device, the account that holds administrative rights is the first thing to verify, because an unexpected administrator session or a change made outside a maintenance window is the signal that matters most. If the change is unapproved, treat the alert as a possible incident and open it as one.
Next, check whether the firewall state is still altered. Compare the live rule set, default policies and listening services against the last known-good baseline held in configuration management, and confirm the host's logging and forwarding agents still report to the monitoring platform. Review adjacent telemetry for other defense impairment on the same host or account in the same window, such as changes to audit settings, disabled security tools or altered logging configuration, since a firewall change is often one step in a longer sequence. Decide on containment based on what the account can reach: isolate the host at the network layer if the change exposes management or lateral paths, and disable the account if its credentials may be compromised. Preserve evidence before restoring anything, which means exporting the current rule set, copying relevant logs to write-once storage and capturing volatile data where your procedure requires it.
Restore the firewall from a verified, known-good source such as the signed golden configuration, not from a copy on the affected host, and record who approved the restoration. After recovery, tune the detection: record whether the alert was a true positive, a sanctioned change that lacked a change ticket, or a benign administrative action, and adjust the rule's allow list, account exceptions or change-window logic accordingly. Confirm with your own engineering and monitoring teams which firewall tooling emits the events you rely on, because logging coverage differs across ESXi, Linux, macOS and network device platforms. Re-run the scenario in your private cyber range after tuning so the revised alert is proven against the same behavior before it returns to production.
Rehearsing firewall tampering detection in a private cyber range
This scenario runs in an isolated virtualized environment with an ESXi host, several Linux guests and a log pipeline feeding a SIEM such as Wazuh. The facilitator designs the exercise around the host firewall and the hypervisor management interface, so that the team must notice a change to filtering rules and confirm whether it was authorized. The goal is to test whether command execution and process creation telemetry from both hosts reaches the analysts with enough context to act.
- Topology: Two or three Linux guests on a dedicated management network, one ESXi host, and a collector that receives audit logs from both. Keep the lab disconnected from production networks.
- Injects: The facilitator schedules a change to a host firewall configuration outside any change window, then a second change on the hypervisor that alters a service exposure rule.
- Good detection: Alerts arrive within the window the team has agreed in advance, and the event shows the host, user, parent process and the changed configuration file or rule set.
- Analyst notes: Analysts record whether the change matches an approved change record and which identity made it, without drawing conclusions from the alert alone.
- Good response: Containment isolates the affected guest, the team restores the known-good rule set from a verified source, and it checks that the restored state matches the baseline.
Before closing the exercise, confirm the log retention period, the alert routing and that the team can reproduce each finding from stored evidence alone.
The macOS scenario uses a small set of managed endpoints enrolled in the lab's device management tooling. The facilitator plans injects around the application firewall and the packet filter settings, which an intruder would prefer to change quietly. The exercise tests whether endpoint telemetry captures configuration changes and whether the response team can tell a sanctioned update from an unsanctioned one.
- Topology: Three to five endpoints with a standard build, a log forwarder on each, and a central collector. Use a test user account with standard privileges as the initial foothold.
- Injects: The facilitator alters a firewall setting through a command line process, then repeats the change using a script that runs at login.
- Good detection: Process creation and command execution records show the initiating process, the user context and the timing, and the team correlates them with the file modification record for the configuration.
- Analyst notes: Analysts document whether the device management console recorded a corresponding policy push and note any gap between the two sources.
- Good response: The team quarantines the endpoint, reapplies the enforced profile through management tooling and confirms the firewall state on several devices.
Confirm with your endpoint vendor which firewall settings are enforced by profile and which can be changed locally, because that answer decides what the exercise can prove.
The network device scenario uses an emulated firewall or router image in the cyber range, connected to a traffic capture point and a syslog or flow collector. The facilitator designs injects that change filtering behavior without a matching change request, so the team must rely on configuration logs and traffic evidence together. Confirm before the exercise which emulation product and version the range uses, because log formats differ by vendor.
- Topology: One emulated firewall between two segments, a monitored span or tap point, and a syslog collector. Include a management plane that is separate from the data plane.
- Injects: The facilitator removes a deny rule, adds an allow rule for a test address, and then changes the logging level so that fewer events are recorded.
- Good detection: Configuration change logs record the administrator account, the time and the rule altered, and traffic records show new allowed flows that match the changed rule.
- Analyst notes: Analysts compare the change log with the device's running configuration and record any difference between the two as a finding.
- Good response: The team restores the approved configuration from a signed backup, verifies the rule set against the change record and reviews whether logging was reduced during the window.
Check that your collector preserves logs when the device's logging level is lowered, since a rehearsal that loses its own evidence cannot measure detection quality.
Each environment produces its own evidence, but the facilitator should review all three together to find shared gaps in alerting, ownership and change records. This tab covers how the team records outcomes, so that the rehearsal can be repeated and the findings can feed control evidence. The scoring should measure what the team saw, how long it took to decide and what it changed, rather than rewarding speed alone.
- Timeline reconstruction: Build one timeline per scenario from telemetry, with the inject time, the first alert and the first analyst action.
- Detection gaps: Record each inject that produced no alert, a late alert or an alert missing key fields.
- Change verification: Check that every restored configuration matched the approved baseline, and record who signed off.
- Control mapping: Link findings to the relevant mitigation for this technique, such as Audit and User Account Management, and to the sibling topics where the same telemetry applies.
- Repeat plan: Schedule the same injects against a revised configuration to confirm that each fix works.
Before the next rehearsal, confirm that the ATT&CK version named in your detection mappings is the version your team is testing against.
Questions SOC leads and detection engineers ask about T1686
How do we separate attacker firewall changes from normal patching?
Start by tying every firewall change to a change record, a named owner and a time window, then treat any change without one as a finding to investigate. Patching usually runs through a known management tool, under a named service account, inside a scheduled window, so those attributes give you a baseline. Alert when a rule or state change combines an unexpected process or account with a change outside the window, because any single attribute alone is too noisy. Keep an allowlist of approved management paths and review it after each patch cycle. Test the logic by replaying a patch window in your cyber range and confirming that the expected changes stay quiet while the unexpected ones alert.
What should we do when ESXi or network devices log very little?
Treat the gap as a risk to document, not a reason to skip the detection. First, confirm which events each platform writes locally, which it forwards to your collector, and whether forwarding is encrypted and monitored for failure. Where native logging is thin, add configuration audit output, syslog forwarding or a comparison of exported firewall configuration on a schedule, and record the residual gap in your risk register. Ask each vendor to confirm in writing which audit events exist for firewall changes on the exact versions you run, because capabilities differ by release and by device model.
How do we map T1686 detections to ATT&CK v20.0 and its sub-techniques?
Write every detection with the ATT&CK version it targets in its metadata, so a later release cannot silently change its meaning. For this version, name Enterprise ATT&CK 20.0 and check each technique and sub-technique ID against the STIX bundle for that version, which MITRE publishes in the attack-stix-data repository. Record the mapping in a table with columns for technique, sub-technique, data component, detection logic and owner. ATT&CK releases can rename, deprecate or revoke techniques, and v19 changed the Defense Evasion structure, so review the mapping against the ATT&CK updates page at every release.
How often should we re-run validation for firewall change detections?
Re-run validation after every change to the detection logic, every change to the log pipeline, every firewall platform upgrade and every ATT&CK version update that touches the mapping. Beyond those triggers, set a recurring schedule that your change board approves, and make the schedule part of the detection's owner record. A validation run should confirm that the expected telemetry arrives, that the rule fires on the test case and that benign patch activity stays quiet. The right frequency depends on how often your firewall estate changes, so ask your team to set it from that evidence rather than copying a number from another organization.
What evidence should we keep to show this detection works?
Keep the detection logic, its ATT&CK version and technique mapping, the data sources it depends on, and the owner and review dates. Add validation records from your cyber range that show the test scenario, the time of execution, the alerts raised and any tuning changes. Keep log pipeline health records for the collectors and forwarders that carry firewall events, along with alert triage notes and incident tickets. Auditors and certification bodies decide whether this evidence is sufficient for a given control, so confirm the expected format and retention period with them before you build the evidence store.
Can our own team run this detection, or do we need outside help?
Your team can run it if it already owns the firewall platforms, the log pipeline and the SIEM rules, and has time to maintain a baseline and a validation schedule. Outside help makes sense when those skills are spread thin or when you need the detection built and tested across several platforms at once. DeployOpen plans, implements and tests self-hosted open-source platforms inside your own environment and runs private cyber range exercises. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so ask any partner to confirm in writing which firewall platforms, log sources and validation runs are included.
How DeployOpen builds firewall detections and range exercises
DeployOpen works on T1686 Disable or Modify System Firewall as a fixed-scope engagement inside your own environment. We agree the telemetry, platforms and deliverables in writing, then build and test the detections and rehearse them in a private cyber range before handing over documentation your team can run.
How we scope
- Confirm which platforms are in scope, such as ESXi, Linux, macOS and network devices, and which are excluded.
- Confirm the telemetry sources available today, including command execution and process creation logs, and any gaps.
- Agree the ATT&CK version the detections will target, so mappings stay accurate after future releases.
How we build
- Map detection logic for each T1686 sub-technique to the data components in the ATT&CK knowledge base.
- Write open-source detection rules in Sigma and translate them to the SIEM or log platform your team uses.
- Test each rule against the agreed telemetry to check for coverage gaps and noisy false positives.
How we hand over
- Deliver rule documentation with data source requirements, expected fields and known blind spots for each sub-technique.
- Provide range exercise scripts that let your analysts rehearse detection and response in a private cyber range.
- Record the mitigation evidence for Audit and User Account Management so your compliance lead can reference it.
How we support
- Support, upgrades and re-testing of the detections can be arranged as an ongoing retainer after handover.
- Re-validate rules when ATT&CK releases change techniques, sub-techniques or data components.
- Confirm with your team what ownership of rules, logs and range environments looks like after the engagement closes.
