Most intrusions need the network twice, once to bring tools in and once to get data or control out, and M1037 Filter Network Traffic is the ATT&CK mitigation that targets both moves. MITRE ATT&CK v20 maps M1037 to more than 50 technique and sub-technique entries across eleven tactics, more than almost any other network control. This guide reads that mapping as a defender would: which techniques filtering genuinely stops, which it only slows, what it leaves to other mitigations, and how to prove coverage. It is written for detection engineers, network and cloud security teams who already run firewalls and want to tie their rule base to ATT&CK. Firewall build and rule hygiene are covered in the linked control guides and are not repeated here.
Key takeaways
- Egress is where M1037 earns its place. Command and control (T1071, T1090, T1095, T1572) and exfiltration (T1048, T1537) make up the core of the mapping, and both depend on outbound connections a default-deny egress policy can refuse.
- Public-facing servers come first. ATT&CK's text for T1190 and T1071.001 says outbound filtering will not stop the initial exploit but limits the attacker's ability to control the server afterwards.
- Workloads are part of the scope. Cloud metadata access (T1552.005), transfers to untrusted cloud accounts (T1537) and pod-level egress all sit under the same mitigation, and service identities are usually the ones generating that traffic.
- Blocklists age quickly. ATT&CK itself warns that blocking known anonymity networks can be circumvented by domain fronting (T1090.004); allowlists by destination and identity hold up far better.
- Measure by technique, not by rule count. Test each mapped technique with a safe emulation and record whether the filter blocked it, logged it or missed it.
What M1037 covers
ATT&CK defines M1037 as using network appliances and endpoint software to filter ingress, egress and lateral traffic, including protocol-based filtering, firewall rules and blocking based on predefined conditions (attack.mitre.org, mitigation version 1.2, last modified 12 May 2026). The mitigation text lists five measures, each with an example:
| Measure in ATT&CK text | ATT&CK example | Typical enforcement point |
|---|---|---|
| Ingress traffic filtering | Limit SSH (TCP 22) and RDP (TCP 3389) to specific IP ranges | Perimeter firewall, cloud security groups, host firewall |
| Egress traffic filtering | Block outbound traffic to known malicious IPs or unexpected regions | Perimeter or cloud firewall, forward proxy, endpoint firewall |
| Protocol-based filtering | Restrict SMB, RPC or Telnet; disable SMBv1 | Host firewall, internal firewalls, endpoint configuration |
| Network segmentation | VLANs isolating IoT devices or guest networks | Switches, internal firewalls, microsegmentation |
| Application layer filtering | WAF blocking SQL injection; proxies inspecting HTTP/S | WAF, secure web gateway, reverse proxy |
Segmentation has its own mitigation (M1030) and intrusion prevention its own (M1031). In practice M1037 is the rule set; M1030 decides where the boundaries sit. See the M1030 Network Segmentation and M1031 Network Intrusion Prevention pages for those controls.
Techniques M1037 mitigates, by tactic
The v20 dataset maps M1037 to 23 parent techniques and their sub-techniques, more than 50 entries in all. The table shows the entries that matter most for defenders, grouped by tactic, with what ATT&CK's own usage text says filtering does. Tactic names follow the v20 reorganisation, where defence evasion was split into Stealth and Defense Impairment.
| Tactic | Technique | How filtering helps (per ATT&CK usage text) |
|---|---|---|
| Initial Access | T1190 Exploit Public-Facing Application | Restrict outbound traffic from public-facing servers so a compromised server cannot reach attacker infrastructure; does not prevent the exploit itself |
| Command and Control | T1071.001 Web Protocols | Restrict outbound HTTP/HTTPS from critical servers to approved destinations |
| Command and Control | T1071.004 DNS | Filter requests to unknown or known-bad domains; resolve through on-premises or proxy resolvers to disrupt data hidden in DNS |
| Command and Control | T1071.005 Publish/Subscribe Protocols | Filter publish/subscribe traffic to untrusted resources and irregular ports (MQTT standard ports are 1883 and 8883) |
| Command and Control | T1090 Proxy, T1090.003 Multi-hop Proxy | Block known anonymity networks and C2 infrastructure with allow and block lists |
| Command and Control | T1095 Non-Application Layer Protocol | Block unnecessary protocols across the boundary; restrict guest access to VMCI on ESXi where not required |
| Command and Control | T1105 Ingress Tool Transfer | Block outbound traffic from compromised systems to unapproved destinations so tools cannot be downloaded |
| Command and Control | T1219 Remote Access Tools | Limit outgoing traffic to the sites and services remote access software uses |
| Command and Control | T1572 Protocol Tunneling | Filter traffic to untrusted or known-bad domains and resources |
| Exfiltration | T1048 Exfiltration Over Alternative Protocol (and .001 to .003) | Enforce proxies; allow only dedicated servers (for example DNS servers) to use their protocols outbound |
| Exfiltration | T1537 Transfer Data to Cloud Account | Prohibit data transfers to untrusted VPCs |
| Collection | T1530 Data from Cloud Storage | IP-based restrictions on cloud resources, combined with account management, so stolen credentials fail from unexpected ranges |
| Collection | T1602 Data from Configuration Repository (.001, .002) | Extended ACLs blocking SNMP and similar protocols from outside the trusted network |
| Credential Access | T1187 Forced Authentication | Block outbound SMB (TCP 139 and 445, UDP 137) and WebDAV; allowlist tightly where needed |
| Credential Access | T1552.005 Cloud Instance Metadata API | Limit access to the metadata API; a WAF may help against SSRF that targets it |
| Credential Access, Collection | T1557 Adversary-in-the-Middle (.001 to .003) | Block LLMNR, NetBIOS and mDNS on hosts; DHCP snooping and Dynamic ARP Inspection; filter DHCP (UDP 67, 68) from untrusted servers |
| Lateral Movement | T1021.002 SMB/Windows Admin Shares, T1570 Lateral Tool Transfer | Host firewall rules restricting file sharing traffic such as SMB |
| Lateral Movement | T1021.005 VNC | Filter VNC ports (TCP 5900, 5800 and 5500 by default) |
| Stealth | T1218.012 Verclsid | Host firewall rule preventing egress from verclsid.exe |
| Stealth, Persistence, Execution | T1197 BITS Jobs | Allow only legitimate BITS traffic |
| Stealth, Persistence, C2 | T1205 Traffic Signaling (.001, .002) | Stateful firewalls mitigate some variants, depending on implementation |
| Defense Impairment | T1599 Network Boundary Bridging | Block malicious packets on an unaffected device in the path once a compromised device is found |
| Impact | T1498 Network Denial of Service, T1499 Endpoint Denial of Service | Upstream filtering by the ISP, a CDN or a DoS mitigation provider; on-premises blocking only where volume allows |
| Stealth | T1696 Anti-Automation Evasion | WAF, bot management and application-layer filtering on request characteristics, reputation and rate |
For the technique detail behind these rows, see the MITRE ATT&CK T1071 Application Layer Protocol, T1048 Exfiltration Over Alternative Protocol, T1105 Ingress Tool Transfer Defensive Guide, T1572 Protocol Tunnelling Defensive Guide and MITRE ATT&CK T1187 Forced Authentication pages.
Prioritising the mapping
More than 50 entries are too many to tackle at once. NHI Mgmt Group recommends ordering the work by how much attacker progress each filter denies and how cheaply it can be enforced:
- Egress from internet-facing servers and build systems. These hosts rarely need open internet access, and a default-deny outbound policy with named destinations covers T1190 follow-on activity, T1105, T1071.001 and much of T1048 in one change.
- Outbound SMB and WebDAV. Blocking TCP 139 and 445 and UDP 137 at the perimeter is a single rule set that removes the forced-authentication path in T1187 and has almost no business impact in most organisations.
- DNS through controlled resolvers. Force all clients to internal or protective resolvers and block direct outbound UDP and TCP 53 from everything else. This is the precondition for any DNS-based detection of T1071.004 and DNS exfiltration. See the DNS Security Guide.
- Metadata endpoint access. Restrict which processes and containers can reach the instance metadata service (T1552.005); see the next section.
- Internal protocol filtering. Host firewall rules for SMB, RDP, WinRM and VNC between workstations (T1021.002, T1021.005, T1570), plus disabling LLMNR and NetBIOS name resolution (T1557.001).
- Application layer. WAF and bot management for T1190 exploitation attempts and T1696, after the network-layer basics are in place. See the Web Application Firewall Guide.
Workload and machine identity egress
Much of the traffic M1037 must govern is generated by non-human identities: CI runners, containers, serverless functions, AI agents and the service accounts behind them. Three areas deserve explicit rules.
- Instance metadata services: On AWS, IMDSv2 requires a session token obtained with a PUT request, and the response hop limit defaults to 1, which stops the token reaching processes one network hop away such as many containers. Setting
HttpTokenstorequiredmakes IMDSv1 calls fail with 401. Combined with network rules that deny metadata access to pods that do not need it, this closes the SSRF route described in ATT&CK's T1552.005 usage text. See the EC2 Instance Metadata Service Hardening Guide and Cloud Instance Metadata Services Compared Guide. - Kubernetes pods: The Kubernetes documentation states that by default a pod is non-isolated for egress and all outbound connections are allowed. A pod becomes isolated for egress only when a NetworkPolicy that selects it lists
EgressinpolicyTypes, and enforcement depends on a network plugin that supports NetworkPolicy. The same documentation lists what the API cannot do: TLS-related controls, logging of blocked or accepted connections, and explicit deny rules. Domain-based egress and connection logging therefore need a proxy, service mesh or a CNI with its own policy extensions. - CI/CD and agents: Build jobs hold the richest credential sets in most estates and usually have unrestricted internet access. In the Codecov breach, a modified uploader script sent each CI job's environment variables, including tokens and cloud keys, to an attacker-controlled server; the theft depended on an outbound request from the job. An egress allowlist on runners that only permits package registries, the source host and named deployment targets turns that kind of exfiltration into a blocked, logged connection. See Cloud Egress Filtering and the Agent Egress Control and Network Isolation Guide.
Where possible, write egress rules per workload identity (service account, security group or pod label) rather than per subnet, so that a rule follows the workload and can be reviewed with its owner.
Choosing the enforcement point
| Enforcement point | Strongest against | Limits | When to choose it |
|---|---|---|---|
| Perimeter or cloud network firewall | T1048, T1095, T1187, T1537 at the boundary | Sees IPs and ports, not process or user; weak on HTTPS destinations without TLS or SNI inspection | Always, as the coarse default-deny layer |
| Forward proxy or secure web gateway | T1071.001, T1105, T1090, T1572 over web protocols | Only covers traffic forced through it; needs a block on direct outbound | Where most outbound traffic is HTTP/S and destinations can be named |
| Host-based firewall | T1021.002, T1570, T1218.012, T1557.001 | Can be disabled by a local administrator (see T1686) | Lateral movement between workstations; per-process egress rules |
| Kubernetes NetworkPolicy or CNI policy | Pod-to-pod lateral traffic, pod egress, metadata access | No native logging, TLS or domain rules in the core API | Any cluster running multi-tenant or internet-facing workloads |
| WAF and bot management | T1190 exploitation attempts, T1696, SSRF to T1552.005 | Signature and rule tuning; does not see outbound traffic | Internet-facing applications and APIs |
| Upstream DoS protection | T1498, T1499 | Contract and provider dependent | Services where availability is a business requirement |
Small organisations get most of the value from a cloud or perimeter firewall with default-deny egress for servers plus a protective DNS service. Large organisations need all layers, with rules owned by application teams and reviewed through a change process. See the Host-Based Firewall Guide and Secure Web Gateway and Web Filtering Guide.
Implementation approach
- Inventory flows. Collect 30 days of flow logs (VPC flow logs, firewall logs, proxy logs) for the target segment and group destinations by owning application and identity.
- Write allow rules from evidence. Create named destination groups (package mirrors, SaaS endpoints, partner IPs) and attach them to workload groups, not individual hosts.
- Run in log-only mode. Add a final "log and allow" rule and review every hit for two weeks; each hit is either a missing allow rule or a finding.
- Enforce in rings. Switch the final rule to deny for one low-risk segment, then build servers, then internet-facing servers, then the rest.
- Keep a rollback. Hold the previous rule base version and a documented, time-limited bypass rule with an owner, so an outage is fixed by reverting one change rather than by opening the policy.
- Automate review. Expire temporary rules, and alert on new broad rules (any destination, any port). See the Firewall Rule Review Checklist.
What M1037 does not stop
- Traffic to allowed destinations: Exfiltration to a permitted cloud storage service or SaaS tenant (T1567 and T1537 variants that use trusted providers) passes an IP or domain allowlist. Tenant restrictions, data loss prevention and identity controls cover that gap.
- Fronted and tunnelled C2: ATT&CK notes that blocklists can be circumvented by domain fronting (T1090.004). TLS inspection (M1020) and behavioural detection on beacon timing carry the load there.
- Compromised network devices: When the firewall or router itself is compromised (T1599), its own rules cannot be trusted; ATT&CK's guidance is to block on an unaffected device in the path.
- Local tampering: An attacker with administrator rights can change host firewall rules (T1686 Disable or Modify System Firewall). Central policy management and alerts on firewall changes are the counter.
- Abuse of valid credentials from expected ranges: IP restrictions on cloud storage (T1530) fail if the attacker operates from inside the allowed range, as with a compromised workload.
Common failure patterns
- Ingress-only firewalls. Servers accept little but can connect anywhere, so a successful T1190 exploit becomes full C2. ATT&CK's T1190 usage text targets exactly this gap.
- Overprivileged appliance identities. In the Capital One breach, a WAF running under a cloud role was induced to query its metadata endpoint, and the role's broad storage access allowed about 30 GB to be synced out. Metadata restrictions and narrow role scope would each have limited it.
- DNS left open. Clients can query any external resolver, so DNS filtering and DNS tunnelling detection see only part of the traffic.
- Policies without enforcement. Kubernetes NetworkPolicy objects are accepted by the API server even when the network plugin does not enforce them, so teams believe pods are isolated when they are not.
- Allow rules that never expire. Temporary "any" rules for a migration remain for years and quietly cancel the default deny.
Detection and measurement
Filtering produces some of the most useful telemetry in the SOC: every denied outbound connection from a server is either a configuration gap or an early sign of compromise.
- Log: denied egress from servers and build systems, DNS queries bypassing approved resolvers, connections from workload identities to new destinations, firewall rule changes, metadata endpoint requests from unexpected processes.
- Coverage per technique: for each mapped technique, record block, log-only or no coverage, validated by a safe emulation (for example a test connection to a sinkhole on TCP 445, or a DNS query for a test domain), and re-run after each major rule change.
| Metric | What good looks like |
|---|---|
| Share of server segments with default-deny egress | 100% of internet-facing and build segments, rising elsewhere |
| Mapped M1037 techniques with a validated block | Tracked per quarter; every C2 and exfiltration row tested |
| Rules with any destination or any port | Falling, each with an owner and expiry |
| Hosts able to resolve DNS directly against the internet | Zero outside approved resolvers |
| Mean time to review a denied-egress alert from a server | Within the SOC's high-priority target |
| Clusters with a default-deny egress NetworkPolicy per namespace | All production namespaces |
See the VPN and Firewall Log Detection Guide for detection content built on these logs.
D3FEND and related mitigations
The MITRE D3FEND knowledge graph relates M1037 to D3-NI Network Isolation, which it defines as techniques that prevent hosts from accessing non-essential network resources. Its child techniques map closely to the measures above: D3-ITF Inbound Traffic Filtering, D3-OTF Outbound Traffic Filtering, D3-NTF Network Traffic Filtering, D3-DNSAL DNS Allowlisting and D3-DNSDL DNS Denylisting.
| Related mitigation | Relationship to M1037 |
|---|---|
| M1030 Network Segmentation | Defines the zones whose boundaries M1037 rules enforce |
| M1031 Network Intrusion Prevention | Signature and anomaly blocking on traffic M1037 allows |
| M1020 SSL/TLS Inspection | Gives filters visibility into encrypted web traffic |
| M1035 Limit Access to Resource Over Network | Restricts who can reach a service rather than which packets pass |
| M1042 Disable or Remove Feature or Program | Removes protocols (SMBv1, LLMNR) instead of filtering them |
See the M1035 Limit Access to Resource Over Network and M1042 Disable or Remove Feature or Program pages.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; SC-7(5) Deny by Default, Allow by Exception | Default-deny boundary filtering, including egress |
| NIST SP 800-53 Rev. 5 | CM-7 Least Functionality | Restricting unnecessary ports and protocols |
| NIST CSF 2.0 | PR.IR-01 | Networks and environments protected from unauthorised logical access |
| CIS Controls v8.1 | 4.4, 4.5 (firewalls on servers and end-user devices); 13.10 (application layer filtering) | Host and network filtering safeguards |
| ISO/IEC 27001:2022 Annex A | 8.20 Networks security; 8.22 Segregation of networks; 8.23 Web filtering | Network controls and outbound web filtering |
Practitioner checklist
- Map your firewall, proxy and WAF rule sets to the M1037 technique list and mark each row block, log-only or uncovered.
- Apply default-deny egress to internet-facing servers and CI/CD runners first, with named destination groups.
- Block outbound SMB (TCP 139, 445; UDP 137) and WebDAV at the perimeter.
- Force DNS through approved resolvers and block direct outbound port 53.
- Require IMDSv2 (or the provider equivalent) and deny metadata access to workloads that do not need it.
- Add a default-deny egress NetworkPolicy to each production namespace and confirm the CNI enforces it.
- Write egress rules per workload identity and give every broad rule an owner and expiry date.
- Alert on denied server egress and on any firewall rule change outside change control.
- Re-test mapped C2 and exfiltration techniques after every significant rule change.
Standards and references
- MITRE ATT&CK: M1037 Filter Network Traffic
- MITRE D3FEND: Network Isolation (D3-NI)
- NIST: SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- Kubernetes: Network Policies
- AWS: Use the Instance Metadata Service to access instance metadata
Related NHI Mgmt Group resources: Cloud Egress Filtering · Agent Egress Control and Network Isolation Guide · Network Segmentation Guide · M1038 Execution Prevention