Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0306: Detection of Unauthorized Network Firewall Rule Modification

This detection strategy matters because unauthorized changes to network device firewall rules can quietly weaken the controls that separate critical system...

EnterpriseDET0306Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This detection strategy matters because unauthorized changes to network device firewall rules can quietly weaken the controls that separate critical systems, users, partners, cloud paths, and the internet. Even a single added, deleted, or modified ACL, security zone, or policy rule can create unauthorized connectivity and undermine segmentation assumptions used for resilience, compliance, and incident containment.

Executive priority

Treat this as a control-assurance and resilience issue, not only a SOC alerting problem. Leaders should ask whether firewall and network device rule changes are approved, logged, reviewed, and recoverable; whether emergency changes are distinguishable from malicious or unauthorized ones; and whether audit evidence can prove that segmentation controls have not been impaired. Priority is highest where network devices enforce access to sensitive business systems, regulated environments, or incident containment boundaries.

Technical view

The supplied ATT&CK object is a detection strategy with no official detection text or platform list, but it detects T1686.002, Network Device Firewall, under defense impairment on Network Devices. SOC, detection engineering, and IR teams should validate monitoring around network device firewall configuration changes, especially creation, deletion, or modification of ACLs, security zones, and policy rules that permit previously blocked traffic. Detection should focus on whether the change was authorized, whether the actor/account and change path are expected, and whether the resulting rule materially expands access.

Likely telemetry

  • Network device configuration change logs
  • Firewall or router ACL, security zone, and policy rule audit events
  • Administrative authentication and authorization logs for network devices
  • Configuration management, backup, or compliance drift records
  • Change-management tickets or approved maintenance window records

Detection direction

  • Correlate rule modifications with approved change records, maintenance windows, and known administrator activity.
  • Alert on rule changes that broaden access, permit traffic to internal subnets, remove deny rules, or alter segmentation/security-zone boundaries.
  • Compare current network device firewall configurations against known-good baselines to identify drift.
  • Review privileged access paths to network devices, including whether changes came from expected accounts and management networks.
  • Tune for legitimate network operations activity, but avoid suppressing high-risk changes solely because they occur during business hours.

Mitigation priorities

  • Establish and enforce formal approval for network device firewall rule changes.
  • Maintain versioned backups and baselines for network device configurations so unauthorized drift can be identified and reversed.
  • Restrict and monitor privileged administrative access to routers, switches, perimeter devices, and other devices enforcing firewall-like policy.
  • Review ACLs, security zones, and policy rules periodically for excessive or unexplained access.
  • Ensure incident response playbooks include validation of network device firewall rules when containment appears ineffective or unexpected traffic is observed.
Analyst notes and limits

The ATT&CK detection strategy record provides a name and relationship to T1686.002 but does not include an official description or detection procedure. The practical guidance here is derived from the object name and the supplied relationship context describing adversary modification of network device firewall mechanisms, ACLs, security zones, and policy rules.

Coverage cannot be assumed from this ATT&CK object alone. Local device types, logging capabilities, configuration management practices, change-control maturity, and segmentation architecture determine whether this behavior is observable and actionable. Platforms are not specified on the detection strategy itself; Network Devices are supported only through the related technique context.

Official MITRE ATT&CK definition

Detection of Unauthorized Network Firewall Rule Modification

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1686.002 Network Device Firewall Sub-technique This object detects Network Device Firewall.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
56c95a6c3d7e4dc4...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 56c95a6c3d7e…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0306
    Open source URL
Source and licensing

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.