M1037: Filter Network Traffic

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.

Additional 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.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official MITRE ATT&CK definition

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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

Filter related techniques49 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1205.001	Port KnockingSub-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 FloodSub-technique	Leverage services provided by Content Delivery Networks (CDN) or providers specializing in DoS mitigations to filter traffic upstream from services.[1] 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 SpoofingSub-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.[2]
Enterprise	T1498.002	Reflection AmplificationSub-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.[1] 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.[1] 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.[1]
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	DNSSub-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 ProxySub-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 ProtocolSub-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 ProtocolsSub-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	VNCSub-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.[1] 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.[1] 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.[1]
Enterprise	T1218.012	VerclsidSub-technique	Consider modifying host firewall rules to prevent egress traffic from verclsid.exe.
Enterprise	T1499.002	Service Exhaustion FloodSub-technique	Leverage services provided by Content Delivery Networks (CDN) or providers specializing in DoS mitigations to filter traffic upstream from services.[1] 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.[1] 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. [3]
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.[4]
Enterprise	T1499.004	Application or System ExploitationSub-technique	Leverage services provided by Content Delivery Networks (CDN) or providers specializing in DoS mitigations to filter traffic upstream from services.[1] 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 ProtocolsSub-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. [5] [6]
Enterprise	T1205.002	Socket FiltersSub-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 FloodSub-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.[1] 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.[1] 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.[1]
Enterprise	T1602.002	Network Device Configuration DumpSub-technique	Apply extended ACLs to block unauthorized protocols outside the trusted network.[7]
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 SoftwareSub-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.[8]
Enterprise	T1048.003	Exfiltration Over Unencrypted Non-C2 ProtocolSub-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 ProtocolsSub-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 FloodSub-technique	Leverage services provided by Content Delivery Networks (CDN) or providers specializing in DoS mitigations to filter traffic upstream from services.[1] 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.[7]
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 SharesSub-technique	Consider using the host firewall to restrict file sharing communications such as SMB. [3]
Enterprise	T1557.002	ARP Cache PoisoningSub-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.[9][10]
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 ProtocolSub-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 ProtocolsSub-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.[7]
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 TraversalSub-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 RelaySub-technique	Use host-based security software to block LLMNR/NetBIOS/mDNS traffic. Enabling SMB Signing can stop NTLMv2 relay attacks.[11][12][13]
Enterprise	T1552.005	Cloud Instance Metadata APISub-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.[4]

Relationship explorer

All related ATT&CK context

Change history

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.

ATT&CK release: 19.1
Object version: 1.2
Created: Jun 11, 2019, 16:33 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 8601e69399ff841d...

Imported snapshots across ATT&CK releases(1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	Jul 14, 2026, 09:14 UTC (UTC+00:00)	1.2	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`8601e69399ff…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[2]
ntlm_relaying_kerberos_del
Mollema, D. (2019, March 4). The worst of both worlds: Combining NTLM Relaying and Kerberos delegation . Retrieved August 15, 2022.
Open source URL
[3]
Microsoft Preventing SMB
Microsoft. (2020, March 10). Preventing SMB traffic from lateral connections and entering or leaving the network. Retrieved June 1, 2020.
Open source URL
[4]
RedLock Instance Metadata API 2018
Higashi, Michael. (2018, May 15). Instance Metadata API: A Modern Day Trojan Horse. Retrieved July 16, 2019.
Open source URL
[5]
US-CERT SMB Security
US-CERT. (2017, March 16). SMB Security Best Practices. Retrieved December 21, 2017.
Open source URL
[6]
US-CERT APT Energy Oct 2017
US-CERT. (2017, October 20). Alert (TA17-293A): Advanced Persistent Threat Activity Targeting Energy and Other Critical Infrastructure Sectors. Retrieved November 2, 2017.
Open source URL
[7]
US-CERT TA17-156A SNMP Abuse 2017
US-CERT. (2017, June 5). Reducing the Risk of SNMP Abuse. Retrieved October 19, 2020.
Open source URL
[8]
Broadcom VMCI Firewall
Broadcom. (2025, March 24). Configure Virtual Machine Communication Interface Firewall. Retrieved March 31, 2025.
Open source URL
[9]
Cisco ARP Poisoning Mitigation 2016
King, J., Lauerman, K. (2016, January 22). ARP Poisoning (Man-in-the-Middle) Attack and Mitigation Technique. Retrieved October 15, 2020.
Open source URL
[10]
Juniper DAI 2020
Juniper. (2020, September 23). Understanding and Using Dynamic ARP Inspection (DAI). Retrieved October 15, 2020.
Open source URL
[11]
byt3bl33d3r NTLM Relaying
Salvati, M. (2017, June 2). Practical guide to NTLM Relaying in 2017 (A.K.A getting a foothold in under 5 minutes). Retrieved February 7, 2019.
Open source URL
[12]
Secure Ideas SMB Relay
Kuehn, E. (2018, April 11). Ever Run a Relay? Why SMB Relays Should Be On Your Mind. Retrieved February 7, 2019.
Open source URL
[13]
Microsoft SMB Packet Signing
Microsoft. (2008, September 10). Using SMB Packet Signing. Retrieved February 7, 2019.
Open source URL
[14]
mitre-attackM1037
Open source URL
[15]
mitre-attackM1037
Open source URL
[16]
mitre-attackM1037
Open source URL
[17]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[18]
ntlm_relaying_kerberos_del
Mollema, D. (2019, March 4). The worst of both worlds: Combining NTLM Relaying and Kerberos delegation . Retrieved August 15, 2022.
Open source URL
[19]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[20]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[21]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[22]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[23]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[24]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[25]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[26]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[27]
Microsoft Preventing SMB
Microsoft. (2020, March 10). Preventing SMB traffic from lateral connections and entering or leaving the network. Retrieved June 1, 2020.
Open source URL
[28]
RedLock Instance Metadata API 2018
Higashi, Michael. (2018, May 15). Instance Metadata API: A Modern Day Trojan Horse. Retrieved July 16, 2019.
Open source URL
[29]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[30]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[31]
US-CERT APT Energy Oct 2017
US-CERT. (2017, October 20). Alert (TA17-293A): Advanced Persistent Threat Activity Targeting Energy and Other Critical Infrastructure Sectors. Retrieved November 2, 2017.
Open source URL
[32]
US-CERT SMB Security
US-CERT. (2017, March 16). SMB Security Best Practices. Retrieved December 21, 2017.
Open source URL
[33]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[34]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[35]
US-CERT TA17-156A SNMP Abuse 2017
US-CERT. (2017, June 5). Reducing the Risk of SNMP Abuse. Retrieved October 19, 2020.
Open source URL
[36]
Broadcom VMCI Firewall
Broadcom. (2025, March 24). Configure Virtual Machine Communication Interface Firewall. Retrieved March 31, 2025.
Open source URL
[37]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[38]
CERT-EU DDoS March 2017
Meintanis, S., Revuelto, V., Socha, K.. (2017, March 10). DDoS Overview and Response Guide. Retrieved April 24, 2019.
[39]
US-CERT TA17-156A SNMP Abuse 2017
US-CERT. (2017, June 5). Reducing the Risk of SNMP Abuse. Retrieved October 19, 2020.
Open source URL
[40]
US-CERT TA17-156A SNMP Abuse 2017
US-CERT. (2017, June 5). Reducing the Risk of SNMP Abuse. Retrieved October 19, 2020.
Open source URL
[41]
Microsoft Preventing SMB
Microsoft. (2020, March 10). Preventing SMB traffic from lateral connections and entering or leaving the network. Retrieved June 1, 2020.
Open source URL
[42]
Microsoft Preventing SMB
Microsoft. (2020, March 10). Preventing SMB traffic from lateral connections and entering or leaving the network. Retrieved June 1, 2020.
Open source URL
[43]
Cisco ARP Poisoning Mitigation 2016
King, J., Lauerman, K. (2016, January 22). ARP Poisoning (Man-in-the-Middle) Attack and Mitigation Technique. Retrieved October 15, 2020.
Open source URL
[44]
Juniper DAI 2020
Juniper. (2020, September 23). Understanding and Using Dynamic ARP Inspection (DAI). Retrieved October 15, 2020.
Open source URL
[45]
US-CERT TA17-156A SNMP Abuse 2017
US-CERT. (2017, June 5). Reducing the Risk of SNMP Abuse. Retrieved October 19, 2020.
Open source URL
[46]
RedLock Instance Metadata API 2018
Higashi, Michael. (2018, May 15). Instance Metadata API: A Modern Day Trojan Horse. Retrieved July 16, 2019.
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use