DET0424: Detection Strategy for Disable or Modify Cloud Firewall
This detection strategy matters because cloud firewall or security group changes can directly weaken the boundary that protects cloud workloads and managem...
Analyst context for executives and security teams
This detection strategy matters because cloud firewall or security group changes can directly weaken the boundary that protects cloud workloads and management paths. Even though the ATT&CK detection-strategy object has no official description or detection text, its relationship to Cloud Firewall under Defense Impairment indicates a practical risk: an actor with sufficient permissions may change cloud network controls to allow access that was previously blocked.
Executive priority
Treat this as a cloud control-governance and incident-readiness issue. Leaders should ask whether changes to cloud firewall rules are logged, reviewed, attributable to an identity, and alertable when they expand access to sensitive resources. The business decision value is in proving that cloud network guardrails cannot be silently weakened and that SOC/IR teams can quickly determine who changed what, when, and with what approval.
Technical view
Because DET0424 does not include official detection logic, defenders should validate coverage against the related technique T1686.001, Cloud Firewall, in IaaS environments. SOC and detection teams should focus on administrative changes to cloud firewall rules, security groups, or equivalent policies, especially changes that broaden source IP ranges, expose unexpected ports or protocols, or enable lateral access paths. IR teams should be able to reconstruct the control-plane event, responsible principal, affected resource, before/after rule state, and any subsequent network activity.
Likely telemetry
- Cloud control-plane audit logs for firewall, security group, or network policy changes
- Identity and access management logs showing the principal, role, session, and authorization path used to make changes
- Configuration history or cloud asset inventory showing before/after firewall rule state
- Network flow logs or equivalent traffic records for newly permitted paths
- Change-management or ticketing evidence to distinguish approved from unapproved modifications
Detection direction
- Validate that cloud firewall and security group modification events are collected and retained for IaaS environments relevant to the related ATT&CK technique.
- Tune detections for access-expanding changes, such as broader source ranges, new inbound permissions, unexpected ports or protocols, or policy changes affecting sensitive cloud resources.
- Correlate firewall changes with identity context, including privileged role use, unusual principals, and changes made outside approved maintenance windows.
- Reduce false positives by integrating authorized change records, but do not suppress alerts solely because a privileged account performed the action.
- Check blind spots where logs are not centralized, configuration snapshots are unavailable, or detections only monitor workload traffic and not cloud control-plane changes.
Mitigation priorities
- Prioritize least-privilege access for identities allowed to modify cloud firewall or security group rules.
- Require review, approval, and traceability for changes that expand network access to cloud resources.
- Maintain centralized logging and configuration history so responders can determine the exact rule change and affected assets.
- Use preventive guardrails where feasible to restrict high-risk firewall modifications and enforce expected network exposure patterns.
- Regularly test SOC and IR playbooks for unauthorized cloud firewall modification scenarios.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with no official description, no official detection text, and no platforms or tactics specified on the object itself. The practical interpretation comes from its relationship to T1686.001 Cloud Firewall, which is listed under Defense Impairment for IaaS. Local cloud architecture, naming conventions, approved exposure patterns, and identity model are required to turn this into precise detection logic.
This take does not assert active exploitation, actor attribution, specific vendor coverage, or guaranteed detectability. The ATT&CK detection-strategy fields are sparse, so recommendations are limited to conservative validation and telemetry priorities supported by the related technique context.
Detection Strategy for Disable or Modify Cloud Firewall
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.001 | Cloud Firewall Sub-technique | This object detects Cloud 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 | 0efecca99c79… |
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 DET0424Open 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.