M1037: Filter Network Traffic
Employ network appliances and endpoint software to filter ingress, egress, and lateral network traffic. This includes protocol-based filtering, enforcing firewall rules, and blocking or restricting traffic based on predefined conditions to limit adversary movement and data exfiltration. This mitigation can be implemented through the following measures:
Ingress Traffic Filtering:
- Use Case: Configure network firewalls to allow traffic only from authorized IP addresses to public-facing servers. - Implementation: Limit SSH (port 22) and RDP (port 3389) traffic to specific IP ranges.
Egress Traffic Filtering:
- Use Case: Use firewalls or endpoint security software to block unauthorized outbound traffic to prevent data exfiltration and command-and-control (C2) communications. - Implementation: Block outbound traffic to known malicious IPs or regions where communication is unexpected.
Protocol-Based Filtering:
- Use Case: Restrict the use of specific protocols that are commonly abused by adversaries, such as SMB, RPC, or Telnet, based on business needs. - Implementation: Disable SMBv1 on endpoints to prevent exploits like EternalBlue.
Network Segmentation:
- Use Case: Create network segments for critical systems and restrict communication between segments unless explicitly authorized. - Implementation: Implement VLANs to isolate IoT devices or guest networks from core business systems.
Application Layer Filtering:
- Use Case: Use proxy servers or Web Application Firewalls (WAFs) to inspect and block malicious HTTP/S traffic. - Implementation: Configure a WAF to block SQL injection attempts or other web application exploitation techniques.
Analyst context for executives and security teams
Filter Network Traffic (M1037) is a broad defensive control: use network appliances and endpoint software to restrict inbound, outbound, and internal traffic so adversaries have fewer paths for initial access, command-and-control, lateral movement, tool transfer, and exfiltration. Its business value is not just “having firewalls,” but proving that only required communications are allowed between users, systems, cloud/IaaS assets, public-facing services, and critical segments.
Executive priority
Treat this as a resilience and audit-evidence priority. Leaders should ask whether the organization can demonstrate enforced ingress rules for exposed services, controlled egress paths, segmentation around critical systems, and restrictions on commonly abused protocols such as SMB, RPC, Telnet, FTP, DNS, mail, web, VNC, and remote administration paths. The decision value is prioritizing controls that reduce blast radius and data-loss paths before an incident, rather than relying only on endpoint detection after compromise.
Technical view
SOC, detection, and IR teams should validate that filtering policy aligns to ATT&CK behaviors this mitigation is mapped to: SMB/Windows Admin Shares and VNC lateral movement; alternative-protocol exfiltration; application-layer C2 over web, file transfer, mail, DNS, and publish/subscribe protocols; proxy and multi-hop proxy use; non-application-layer protocols; ingress tool transfer; forced authentication over SMB; exploitation of public-facing applications; BITS-related network activity; and traffic signaling such as port knocking or socket filters. Because MITRE provides no official detection text for this mitigation, teams should test whether enforcement, logging, and alerting exist at ingress, egress, inter-segment, proxy/WAF, DNS, and endpoint firewall layers.
Likely telemetry
- Firewall allow/deny logs for ingress, egress, and lateral traffic
- Endpoint firewall or endpoint security network-control logs
- Proxy and web gateway logs, including HTTP/S destinations and policy decisions
- WAF events for public-facing application traffic filtering
- DNS resolver logs and blocked-query telemetry
Detection direction
- Validate that denied traffic is logged with enough context to support investigation; silent blocking limits incident reconstruction and compliance evidence.
- Tune detections around policy violations: unexpected outbound destinations, unusual protocols leaving sensitive segments, unauthorized SMB/VNC/RDP/SSH access paths, and attempts to communicate across blocked network zones.
- Baseline legitimate business use of common protocols such as HTTP/S, DNS, SMTP, FTP, SMB, and VNC before writing high-severity alerts, because these protocols can be normal in many environments.
- Review blind spots where encrypted, proxied, or application-layer traffic may blend into approved channels; filtering alone may not reveal intent without proxy, DNS, flow, and endpoint context.
- Correlate network filtering events with identity context where possible, especially for Valid Accounts-related remote access and SMB activity referenced by related techniques.
Mitigation priorities
- Start with an explicit business-required traffic model: which systems, users, services, protocols, ports, and destinations must communicate.
- Harden ingress first for public-facing systems by allowing only authorized sources and required services, including restricted administrative access such as SSH and RDP where applicable.
- Implement egress filtering to limit unauthorized outbound communication, including known malicious destinations or regions where communication is unexpected, as described by MITRE.
- Restrict commonly abused protocols based on business need, including SMB, RPC, Telnet, FTP/TFTP, mail protocols, DNS paths, VNC, and other remote or file-transfer services referenced by related techniques.
- Segment critical systems and separate guest, IoT, and core business networks so lateral movement requires explicitly authorized paths.
Analyst notes and limits
This mitigation is intentionally broad and applies across many ATT&CK behaviors. Its effectiveness depends on local architecture, asset inventory, identity design, cloud/IaaS routing, and whether enforcement points generate usable telemetry. For Glexia assessments, the practical test is whether teams can show both policy intent and operational evidence: blocked attempts, allowed exceptions, segmentation maps, and logs that support SOC triage and IR timelines.
The supplied ATT&CK object is a mitigation, not a detection analytic, and MITRE provides no official detection field. Platforms and tactics are not specified for the mitigation itself; platform references come from related techniques only. This take does not assert active exploitation, attribution, or guaranteed detection coverage.
Filter Network Traffic
Employ network appliances and endpoint software to filter ingress, egress, and lateral network traffic. This includes protocol-based filtering, enforcing firewall rules, and blocking or restricting traffic based on predefined conditions to limit adversary movement and data exfiltration. This mitigation can be implemented through the following measures:
Ingress Traffic Filtering:
- Use Case: Configure network firewalls to allow traffic only from authorized IP addresses to public-facing servers. - Implementation: Limit SSH (port 22) and RDP (port 3389) traffic to specific IP ranges.
Egress Traffic Filtering:
- Use Case: Use firewalls or endpoint security software to block unauthorized outbound traffic to prevent data exfiltration and command-and-control (C2) communications. - Implementation: Block outbound traffic to known malicious IPs or regions where communication is unexpected.
Protocol-Based Filtering:
- Use Case: Restrict the use of specific protocols that are commonly abused by adversaries, such as SMB, RPC, or Telnet, based on business needs. - Implementation: Disable SMBv1 on endpoints to prevent exploits like EternalBlue.
Network Segmentation:
- Use Case: Create network segments for critical systems and restrict communication between segments unless explicitly authorized. - Implementation: Implement VLANs to isolate IoT devices or guest networks from core business systems.
Application Layer Filtering:
- Use Case: Use proxy servers or Web Application Firewalls (WAFs) to inspect and block malicious HTTP/S traffic. - Implementation: Configure a WAF to block SQL injection attempts or other web application exploitation techniques.
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 | T1205.001 | Port Knocking Sub-technique | Mitigation of some variants of this technique could be achieved through the use of stateful firewalls, depending upon how it is implemented. |
| Enterprise | T1557 | Adversary-in-the-Middle | Use network appliances and host-based security software to block network traffic that is not necessary within the environment, such as legacy protocols that may be leveraged for AiTM conditions. |
| Enterprise | T1572 | Protocol Tunneling | Consider filtering network traffic to untrusted or known bad domains and resources. |
| Enterprise | T1499.003 | Application Exhaustion Flood Sub-technique | Leverage services provided by Content Delivery Networks (CDN) or providers specializing in DoS mitigations to filter traffic upstream from services.CitationCERT-EU DDoS March 2017 Filter boundary traffic by blocking source addresses sourcing the attack, blocking ports that are being targeted, or blocking protocols being used for transport. |
| Enterprise | T1190 | Exploit Public-Facing Application | Restrict outbound network traffic from public-facing servers to prevent unauthorized connections from initiating communications with attacker-controlled infrastructure. While this may not prevent the initial exploitation, it limits the attacker's ability to verify and control the compromised server post-exploit, reducing the overall impact of the attack. |
| Enterprise | T1557.003 | DHCP Spoofing Sub-technique | Consider filtering DHCP traffic on ports 67 and 68 to/from unknown or untrusted DHCP servers. Additionally, port security may also be enabled on layer switches. Furthermore, consider enabling DHCP snooping on layer 2 switches as it will prevent DHCP spoofing attacks and starvation attacks. Consider tracking available IP addresses through a script or a tool. Additionally, block DHCPv6 traffic and incoming router advertisements, especially if IPv6 is not commonly used in the network.Citationntlm_relaying_kerberos_del |
| Enterprise | T1498.002 | Reflection Amplification Sub-technique | When flood volumes exceed the capacity of the network connection being targeted, it is typically necessary to intercept the incoming traffic upstream to filter out the attack traffic from the legitimate traffic. Such defenses can be provided by the hosting Internet Service Provider (ISP) or by a 3rd party such as a Content Delivery Network (CDN) or providers specializing in DoS mitigations.CitationCERT-EU DDoS March 2017 Depending on flood volume, on-premises filtering may be possible by blocking source addresses sourcing the attack, blocking ports that are being targeted, or blocking protocols being used for transport.CitationCERT-EU DDoS March 2017 As immediate response may require rapid engagement of 3rd parties, analyze the risk associated to critical resources being affected by Network DoS attacks and create a disaster recovery plan/business continuity plan to respond to incidents.CitationCERT-EU DDoS March 2017 |
| Enterprise | T1218 | System Binary Proxy Execution | Use network appliances to filter ingress or egress traffic and perform protocol-based filtering. Configure software on endpoints to filter network traffic. |
| Enterprise | T1071.004 | DNS Sub-technique | Consider filtering DNS requests to unknown, untrusted, or known bad domains and resources. Resolving DNS requests with on-premise/proxy servers may also disrupt adversary attempts to conceal data within DNS packets. |
| Enterprise | T1090.003 | Multi-hop Proxy Sub-technique | Traffic to known anonymity networks and C2 infrastructure can be blocked through the use of network allow and block lists. It should be noted that this kind of blocking may be circumvented by other techniques like Domain Fronting. |
| Enterprise | T1197 | BITS Jobs | Modify network and/or host firewall rules, as well as other network controls, to only allow legitimate BITS traffic. |
| Enterprise | T1205 | Traffic Signaling | Mitigation of some variants of this technique could be achieved through the use of stateful firewalls, depending upon how it is implemented. |
| Enterprise | T1048.001 | Exfiltration Over Symmetric Encrypted Non-C2 Protocol Sub-technique | Enforce proxies and use dedicated servers for services such as DNS and only allow those systems to communicate over respective ports/protocols, instead of all systems within a network. |
| Enterprise | T1071.003 | Mail Protocols Sub-technique | Limit the ability of servers and critical systems to initiate outbound email communications. Filtering SMTP/IMAP/POP3 traffic to only trusted mail servers reduces the risk of attackers using compromised systems to exfiltrate data via email or to receive commands from attacker-controlled email accounts. |
| Enterprise | T1021.005 | VNC Sub-technique | VNC defaults to TCP ports 5900 for the server, 5800 for browser access, and 5500 for a viewer in listening mode. Filtering or blocking these ports will inhibit VNC traffic utilizing default ports. |
| Enterprise | T1498 | Network Denial of Service | When flood volumes exceed the capacity of the network connection being targeted, it is typically necessary to intercept the incoming traffic upstream to filter out the attack traffic from the legitimate traffic. Such defenses can be provided by the hosting Internet Service Provider (ISP) or by a 3rd party such as a Content Delivery Network (CDN) or providers specializing in DoS mitigations.CitationCERT-EU DDoS March 2017 Depending on flood volume, on-premises filtering may be possible by blocking source addresses sourcing the attack, blocking ports that are being targeted, or blocking protocols being used for transport.CitationCERT-EU DDoS March 2017 As immediate response may require rapid engagement of 3rd parties, analyze the risk associated to critical resources being affected by Network DoS attacks and create a disaster recovery plan/business continuity plan to respond to incidents.CitationCERT-EU DDoS March 2017 |
| Enterprise | T1218.012 | Verclsid Sub-technique | Consider modifying host firewall rules to prevent egress traffic from verclsid.exe. |
| Enterprise | T1499.002 | Service Exhaustion Flood Sub-technique | Leverage services provided by Content Delivery Networks (CDN) or providers specializing in DoS mitigations to filter traffic upstream from services.CitationCERT-EU DDoS March 2017 Filter boundary traffic by blocking source addresses sourcing the attack, blocking ports that are being targeted, or blocking protocols being used for transport. |
| Enterprise | T1499 | Endpoint Denial of Service | Leverage services provided by Content Delivery Networks (CDN) or providers specializing in DoS mitigations to filter traffic upstream from services.CitationCERT-EU DDoS March 2017 Filter boundary traffic by blocking source addresses sourcing the attack, blocking ports that are being targeted, or blocking protocols being used for transport. To defend against SYN floods, enable SYN Cookies. |
| Enterprise | T1570 | Lateral Tool Transfer | Consider using the host firewall to restrict file sharing communications such as SMB. CitationMicrosoft Preventing SMB |
| Enterprise | T1552 | Unsecured Credentials | Limit access to the Instance Metadata API. A properly configured Web Application Firewall (WAF) may help prevent external adversaries from exploiting Server-side Request Forgery (SSRF) attacks that allow access to the Cloud Instance Metadata API.CitationRedLock Instance Metadata API 2018 |
| Enterprise | T1499.004 | Application or System Exploitation Sub-technique | Leverage services provided by Content Delivery Networks (CDN) or providers specializing in DoS mitigations to filter traffic upstream from services.CitationCERT-EU DDoS March 2017 Filter boundary traffic by blocking source addresses sourcing the attack, blocking ports that are being targeted, or blocking protocols being used for transport. |
| Enterprise | T1071.002 | File Transfer Protocols Sub-technique | Filter outbound FTP/SFTP traffic from sensitive systems, allowing file transfers only to trusted internal or known IP addresses. This measure can prevent attackers from transferring data or payloads via FTP/SFTP channels to or from unauthorized external systems. |
| Enterprise | T1048 | Exfiltration Over Alternative Protocol | Enforce proxies and use dedicated servers for services such as DNS and only allow those systems to communicate over respective ports/protocols, instead of all systems within a network. Cloud service providers support IP-based restrictions when accessing cloud resources. Consider using IP allowlisting along with user account management to ensure that data access is restricted not only to valid users but only from expected IP ranges to mitigate the use of stolen credentials to access data. |
| Enterprise | T1219 | Remote Access Tools | Properly configure firewalls, application firewalls, and proxies to limit outgoing traffic to sites and services used by remote access software. |
| Enterprise | T1187 | Forced Authentication | Block SMB traffic from exiting an enterprise network with egress filtering or by blocking TCP ports 139, 445 and UDP port 137. Filter or block WebDAV protocol traffic from exiting the network. If access to external resources over SMB and WebDAV is necessary, then traffic should be tightly limited with allowlisting. CitationUS-CERT SMB Security CitationUS-CERT APT Energy Oct 2017 |
| Enterprise | T1205.002 | Socket Filters Sub-technique | Mitigation of some variants of this technique could be achieved through the use of stateful firewalls, depending upon how it is implemented. |
| Enterprise | T1498.001 | Direct Network Flood Sub-technique | When flood volumes exceed the capacity of the network connection being targeted, it is typically necessary to intercept the incoming traffic upstream to filter out the attack traffic from the legitimate traffic. Such defenses can be provided by the hosting Internet Service Provider (ISP) or by a 3rd party such as a Content Delivery Network (CDN) or providers specializing in DoS mitigations.CitationCERT-EU DDoS March 2017 Depending on flood volume, on-premises filtering may be possible by blocking source addresses sourcing the attack, blocking ports that are being targeted, or blocking protocols being used for transport.CitationCERT-EU DDoS March 2017 As immediate response may require rapid engagement of 3rd parties, analyze the risk associated to critical resources being affected by Network DoS attacks and create a disaster recovery plan/business continuity plan to respond to incidents.CitationCERT-EU DDoS March 2017 |
| Enterprise | T1602.002 | Network Device Configuration Dump Sub-technique | Apply extended ACLs to block unauthorized protocols outside the trusted network.CitationUS-CERT TA17-156A SNMP Abuse 2017 |
| Enterprise | T1105 | Ingress Tool Transfer | Use network filtering to block outbound traffic from compromised systems to unapproved external destinations. Restricting access to known, trusted IP addresses and protocols can prevent attackers from downloading malicious tools or payloads onto compromised servers after gaining initial access. |
| Enterprise | T1219.002 | Remote Desktop Software Sub-technique | Properly configure firewalls, application firewalls, and proxies to limit outgoing traffic to sites and services used by remote access software. |
| Enterprise | T1095 | Non-Application Layer Protocol | Filter network traffic to prevent use of protocols across the network boundary that are unnecessary. If VMCI is not required in ESXi environments, consider restricting guest virtual machines from accessing VMCI services.CitationBroadcom VMCI Firewall |
| Enterprise | T1048.003 | Exfiltration Over Unencrypted Non-C2 Protocol Sub-technique | Enforce proxies and use dedicated servers for services such as DNS and only allow those systems to communicate over respective ports/protocols, instead of all systems within a network. |
| Enterprise | T1071.005 | Publish/Subscribe Protocols Sub-technique | Consider filtering publish/subscribe protocol requests to untrusted or known bad resources over irregular ports (e.g. MQTT’s standard ports are 1883 or 8883). |
| Enterprise | T1090 | Proxy | Traffic to known anonymity networks and C2 infrastructure can be blocked through the use of network allow and block lists. It should be noted that this kind of blocking may be circumvented by other techniques like Domain Fronting. |
| Enterprise | T1499.001 | OS Exhaustion Flood Sub-technique | Leverage services provided by Content Delivery Networks (CDN) or providers specializing in DoS mitigations to filter traffic upstream from services.CitationCERT-EU DDoS March 2017 Filter boundary traffic by blocking source addresses sourcing the attack, blocking ports that are being targeted, or blocking protocols being used for transport. To defend against SYN floods, enable SYN Cookies. |
| Enterprise | T1537 | Transfer Data to Cloud Account | Implement network-based filtering restrictions to prohibit data transfers to untrusted VPCs. |
| Enterprise | T1602 | Data from Configuration Repository | Apply extended ACLs to block unauthorized protocols outside the trusted network.CitationUS-CERT TA17-156A SNMP Abuse 2017 |
| Enterprise | T1599 | Network Boundary Bridging | Upon identifying a compromised network device being used to bridge a network boundary, block the malicious packets using an unaffected network device in path, such as a firewall or a router that has not been compromised. Continue to monitor for additional activity and to ensure that the blocks are indeed effective. |
| Enterprise | T1021.002 | SMB/Windows Admin Shares Sub-technique | Consider using the host firewall to restrict file sharing communications such as SMB. CitationMicrosoft Preventing SMB |
| Enterprise | T1557.002 | ARP Cache Poisoning Sub-technique | Consider enabling DHCP Snooping and Dynamic ARP Inspection on switches to create mappings between IP addresses requested via DHCP and ARP tables and tie the values to a port on the switch that may block bogus traffic.CitationCisco ARP Poisoning Mitigation 2016CitationJuniper DAI 2020 |
| Enterprise | T1530 | Data from Cloud Storage | Cloud service providers support IP-based restrictions when accessing cloud resources. Consider using IP allowlisting along with user account management to ensure that data access is restricted not only to valid users but only from expected IP ranges to mitigate the use of stolen credentials to access data. |
| Enterprise | T1048.002 | Exfiltration Over Asymmetric Encrypted Non-C2 Protocol Sub-technique | Enforce proxies and use dedicated servers for services such as DNS and only allow those systems to communicate over respective ports/protocols, instead of all systems within a network. |
| Enterprise | T1071.001 | Web Protocols Sub-technique | Restrict and monitor outbound web traffic (HTTP/HTTPS) from critical servers to only approved destinations. Limiting the ability to initiate outbound HTTP/HTTPS connections, especially from public-facing servers, can prevent attackers from using tools like curl or wget to communicate with external C2 servers or download malicious payloads. |
| Enterprise | T1602.001 | SNMP (MIB Dump) Sub-technique | Apply extended ACLs to block unauthorized protocols outside the trusted network.CitationUS-CERT TA17-156A SNMP Abuse 2017 |
| Enterprise | T1071 | Application Layer Protocol | Use network appliances to filter ingress or egress traffic and perform protocol-based filtering. Configure software on endpoints to filter network traffic. |
| Enterprise | T1599.001 | Network Address Translation Traversal Sub-technique | Block Traffic Upon identifying a compromised network device being used to bridge a network boundary, block the malicious packets using an unaffected network device in path, such as a firewall or a router that has not been compromised. Continue to monitor for additional activity and to ensure that the blocks are indeed effective. |
| Enterprise | T1557.001 | Name Resolution Poisoning and SMB Relay Sub-technique | Use host-based security software to block LLMNR/NetBIOS/mDNS traffic. Enabling SMB Signing can stop NTLMv2 relay attacks.Citationbyt3bl33d3r NTLM RelayingCitationSecure Ideas SMB RelayCitationMicrosoft SMB Packet Signing |
| Enterprise | T1552.005 | Cloud Instance Metadata API Sub-technique | Limit access to the Instance Metadata API. A properly configured Web Application Firewall (WAF) may help prevent external adversaries from exploiting Server-side Request Forgery (SSRF) attacks that allow access to the Cloud Instance Metadata API.CitationRedLock Instance Metadata API 2018 |
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.2 | Current bundle | 8601e69399ff… |
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 M1037Open 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.