DC0051: Firewall Rule Modification
The creation, deletion, or alteration of firewall rules to allow or block specific network traffic. Monitoring changes to these rules is critical for detecting misconfigurations, unauthorized access, or malicious attempts to bypass network protections. Examples:
- Rule Creation: Adding a new rule to allow inbound traffic on port 3389 (RDP). - Rule Deletion: Deleting a rule that blocks inbound traffic from untrusted IP ranges. - Rule Modification: Changing a rule to allow traffic from "any" source IP instead of a specific trusted range. - Audit Log Metadata: Logs indicating "Firewall rule modified by admin@domain.com." - Platform-Specific Scenarios - Azure: Altering rules in an Azure Network Security Group (NSG). - AWS: Modifying Security Group rules to allow traffic. - Windows: Changes tracked in Security Event Logs (EID 4950 or 4951).
This data component can be collected through the following measures:
Cloud Control Plane
- Azure: Collect rule modification logs from Azure Firewall Activity Logs. - Example Command: `az network firewall policy rule-collection-group rule-collection list --policy-name
Host-Based Firewalls
- Windows: - Collect events from the Windows Security Event Log (EID 4950: A rule has been modified). - Use PowerShell to track rule changes: `Get-NetFirewallRule -PolicyStore PersistentStore` - Linux: - Monitor iptables or nftables rule modifications: `iptables -L -v` - Use auditd for real-time monitoring: `auditctl -w /etc/iptables.rules -p wa` - macOS: Use pfctl to monitor rule changes: `sudo pfctl -sr`
SIEM Integration
- Collect logs from cloud platforms, host systems, and network appliances for centralized monitoring.
API Monitoring
- Monitor API calls for firewall rule modifications.
Analyst context for executives and security teams
Firewall rule changes are a high-value control point because they can quietly change who can reach critical systems and cloud workloads. For leaders, the issue is not only whether firewalls exist, but whether the organization can prove when rules were created, deleted, or loosened, who made the change, and whether the change was authorized.
Executive priority
Treat firewall rule modification telemetry as evidence for operational resilience, cloud governance, incident response, and audit readiness. A single unauthorized or mistaken rule change can expose administrative services, remove a block against untrusted traffic, or weaken segmentation. Executives should ask whether cloud control planes, host firewalls, and network appliances feed a central review process and whether exceptions are tied to accountable change records.
Technical view
This is a data component focused on observing creation, deletion, or alteration of firewall rules. ATT&CK cites cloud examples such as Azure Network Security Group or firewall activity, AWS Security Group API actions, and Google Cloud firewall rules, plus host-based examples for Windows Security Event Log activity, Linux iptables/nftables monitoring, macOS pfctl output, SIEM integration, and API monitoring. SOC and IR teams should validate that rule-change events include actor, timestamp, rule target, source/destination scope, protocol/port, allow/block action, and before/after values where available.
Likely telemetry
- Cloud control plane activity logs for firewall, security group, network security group, and firewall-rule changes
- API audit events for rule creation, deletion, authorization, revocation, or modification
- Windows Security Event Logs related to firewall rule changes, including the ATT&CK-cited EID 4950 and EID 4951 examples
- Linux firewall configuration and audit evidence for iptables or nftables changes
- macOS firewall rule state or pfctl-related evidence where used
Detection direction
- Validate that firewall rule changes from cloud, host, and network-control sources are actually ingested, retained, and searchable in the SIEM or logging platform.
- Prioritize alerting or review for rules that broaden exposure, such as changing a trusted source range to any source, allowing inbound administrative access, or deleting rules that block untrusted traffic, while tuning against approved maintenance windows and documented change tickets.
- Correlate rule modifications with the modifying identity or service account, especially where logs provide audit metadata such as the ATT&CK example of a rule modified by a named administrator.
- Compare current rules to known-good baselines so deletion or silent broadening of controls is visible, not only explicit allow-list additions.
- Account for blind spots where local host firewall changes, cloud API activity, or appliance management logs are not centrally collected or where logs lack before/after rule values.
Mitigation priorities
- Establish accountable change control for firewall rule creation, deletion, and modification across cloud, host, and network environments.
- Centralize collection of cloud control plane, host firewall, API, and appliance management logs before relying on detection or audit reporting.
- Require least-privilege administration for identities that can modify firewall or security group rules, and review privileged access regularly.
- Maintain baseline rule sets and periodically compare deployed rules against approved configurations.
- Review high-risk rule patterns such as broad source ranges, exposed administrative ports, and removed deny rules as part of routine security operations and incident response readiness.
Analyst notes and limits
This object is a data component, not a technique or procedure. Its value is in confirming whether the organization has the telemetry needed to observe firewall rule changes that may indicate misconfiguration, unauthorized access, or attempts to bypass network protections. No ATT&CK relationships were supplied, so this take does not tie the component to specific techniques, tactics, groups, software, or campaigns.
Platforms and tactics are not specified in the STIX fields, although the official description includes examples for cloud control planes and host-based firewalls. Official detection content is not provided. Coverage, risk, and alert quality depend on the local firewall technologies, logging configuration, identity context, retention, and change-management maturity.
Firewall Rule Modification
The creation, deletion, or alteration of firewall rules to allow or block specific network traffic. Monitoring changes to these rules is critical for detecting misconfigurations, unauthorized access, or malicious attempts to bypass network protections. Examples:
- Rule Creation: Adding a new rule to allow inbound traffic on port 3389 (RDP). - Rule Deletion: Deleting a rule that blocks inbound traffic from untrusted IP ranges. - Rule Modification: Changing a rule to allow traffic from "any" source IP instead of a specific trusted range. - Audit Log Metadata: Logs indicating "Firewall rule modified by admin@domain.com." - Platform-Specific Scenarios - Azure: Altering rules in an Azure Network Security Group (NSG). - AWS: Modifying Security Group rules to allow traffic. - Windows: Changes tracked in Security Event Logs (EID 4950 or 4951).
This data component can be collected through the following measures:
Cloud Control Plane
- Azure: Collect rule modification logs from Azure Firewall Activity Logs. - Example Command: `az network firewall policy rule-collection-group rule-collection list --policy-name
Host-Based Firewalls
- Windows: - Collect events from the Windows Security Event Log (EID 4950: A rule has been modified). - Use PowerShell to track rule changes: `Get-NetFirewallRule -PolicyStore PersistentStore` - Linux: - Monitor iptables or nftables rule modifications: `iptables -L -v` - Use auditd for real-time monitoring: `auditctl -w /etc/iptables.rules -p wa` - macOS: Use pfctl to monitor rule changes: `sudo pfctl -sr`
SIEM Integration
- Collect logs from cloud platforms, host systems, and network appliances for centralized monitoring.
API Monitoring
- Monitor API calls for firewall rule modifications.
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 | 740ab2c53e7b… |
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 DC0051Open 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.