DC0044: Firewall Enumeration
Querying and extracting a list of available firewalls or their associated configurations and rules. This activity can occur across host systems and cloud control planes, providing insight into the state and configuration of firewalls that protect the environment. Examples:
- Querying Host-Based Firewalls: Using Windows PowerShell commands like `Get-NetFirewallRule` or Linux commands such as `iptables -L` or `firewalld --list-all`. - Cloud Firewall Rule Listing: Running commands like `az network firewall list` for Azure or `aws ec2 describe-security-groups` for AWS. - Using Management APIs: Leveraging APIs like Google Cloud Firewall's `list` API method or AWS's DescribeSecurityGroups API. Identifying Misconfigurations: Extracting firewall rules to identify “allow all” policies or rules that lack logging. - Enumerating with CLI Tools: Using CLI commands like `gcloud compute firewall-rules list` to extract firewall settings in Google Cloud.
Analyst context for executives and security teams
Firewall Enumeration is evidence that someone or something is listing firewall rules, security groups, or related configurations across hosts and cloud control planes. For leaders, this matters because firewall rule visibility can reveal where the environment is permissive, poorly logged, or easier to move through. The same data component is useful defensively: it helps confirm whether SOC, cloud, and infrastructure teams can see when firewall posture is being queried or reviewed.
Executive priority
Treat this as a control-validation and readiness issue. Security leaders should ask whether firewall and security group inventory, rule changes, and rule-listing activity are logged consistently across host systems and cloud environments. The business value is in proving segmentation, exposure management, audit evidence, and incident response visibility—not assuming that firewall policy exists simply because a control is deployed.
Technical view
MITRE defines this data component as querying and extracting available firewalls or their configurations and rules, including host-based firewall commands, cloud firewall or security group listing, and management API access. Because ATT&CK provides no detection logic, teams should validate telemetry around administrative command execution, cloud API calls, CLI usage, and firewall/security group configuration reads. Detection engineering should distinguish expected administrative inventory activity from unusual enumeration by unexpected identities, systems, time windows, or automation contexts.
Likely telemetry
- Host command execution logs for firewall-rule listing activity
- PowerShell or shell activity where available
- Cloud control-plane audit logs for firewall, security group, or network rule list/read APIs
- Cloud CLI activity logs where available
- Management API access logs
Detection direction
- Inventory where firewall and security group read/list actions are logged across host and cloud environments.
- Baseline legitimate administrative and automation-driven enumeration to reduce false positives.
- Alert on firewall enumeration by identities, hosts, service accounts, or locations that do not normally perform network security administration.
- Correlate enumeration with subsequent configuration changes, access attempts, or other suspicious activity when local telemetry supports it.
- Validate cloud audit log retention and coverage for firewall/security group listing APIs; absence of logs is a material blind spot.
Mitigation priorities
- Apply least-privilege access to firewall and network-security configuration read permissions, especially in cloud control planes.
- Ensure host and cloud firewall configuration queries are logged and retained for investigation and compliance evidence.
- Review firewall rules for overly broad access, missing logging, or unmanaged exceptions as part of vulnerability and exposure management.
- Separate routine inventory automation from interactive administrative access so unusual enumeration is easier to identify.
- Document approved firewall review processes to support audit readiness and incident response decision-making.
Analyst notes and limits
This object is a data component, not a technique. Its value is in identifying the telemetry defenders should collect and analyze when firewall configurations are queried. The official description explicitly covers host systems, cloud control planes, CLI tools, and management APIs, but no platforms, tactics, detection guidance, or ATT&CK relationships were supplied.
No official detection, tactic, platform list, or relationship context was provided. This take should not be interpreted as evidence of adversary activity by itself; local identity, host, cloud, and change-management context is required to determine whether enumeration is authorized or suspicious.
Firewall Enumeration
Querying and extracting a list of available firewalls or their associated configurations and rules. This activity can occur across host systems and cloud control planes, providing insight into the state and configuration of firewalls that protect the environment. Examples:
- Querying Host-Based Firewalls: Using Windows PowerShell commands like `Get-NetFirewallRule` or Linux commands such as `iptables -L` or `firewalld --list-all`. - Cloud Firewall Rule Listing: Running commands like `az network firewall list` for Azure or `aws ec2 describe-security-groups` for AWS. - Using Management APIs: Leveraging APIs like Google Cloud Firewall's `list` API method or AWS's DescribeSecurityGroups API. Identifying Misconfigurations: Extracting firewall rules to identify “allow all” policies or rules that lack logging. - Enumerating with CLI Tools: Using CLI commands like `gcloud compute firewall-rules list` to extract firewall settings in Google Cloud.
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 | 631ee09af802… |
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 DC0044Open 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.