Most teams own an intrusion prevention system, but few can say which ATT&CK techniques it actually blocks and which ones it only claims to. MITRE ATT&CK defines mitigation M1031 Network Intrusion Prevention in one line: use intrusion detection signatures to block traffic at network boundaries. In ATT&CK v20 that one line is mapped to 62 techniques and sub-techniques, heavily weighted towards command and control and exfiltration. This guide reads the mapping as a control owner would: which techniques M1031 genuinely reduces, where the sensor has to sit for each, what it cannot see, and how to measure coverage. It is written for detection engineers, network security teams and SOC leads. For sensor types, rule management and tuning basics, see the IDS and IPS Guide; this page does not repeat them.
Key takeaways
- M1031 is a command and control control first. 32 of its 62 v20 mappings sit in the Command and Control tactic, and 7 more in Exfiltration, so its value depends on egress placement, not just the internet edge inbound.
- ATT&CK itself scopes it to known indicators. The usage text repeats that signatures are "often for unique indicators within protocols", which means M1031 blocks known malware families and protocol misuse, not novel tooling.
- Placement decides coverage. SNMP, Smart Install and TFTP mappings (T1602, T1542.004, T1542.005) only work if a sensor sees management-plane traffic, which a perimeter IPS usually does not.
- Encryption removes most payload signatures. Against T1573 Encrypted Channel and HTTPS-based C2 an IPS sees handshake metadata only, unless traffic is decrypted under a TLS inspection policy.
- Measure it per technique. Count which mapped techniques have an enabled, blocking rule at a sensor on the relevant path, test them, and report the gap honestly.
What M1031 is in ATT&CK v20
M1031 was created in June 2019 and its page shows last modification on 3 September 2026. The mitigation page lists 62 entries: 26 techniques and 36 sub-techniques. The mapped usage text is short and consistent: network intrusion detection and prevention systems that use signatures for specific adversary malware "can be used to mitigate activity at the network level". The verb matters. ATT&CK treats M1031 as prevention (block in line), while detection of the same traffic lives in the technique's detection strategies.
Two newer mappings stretch the idea of "network intrusion prevention" well beyond a classic signature engine. T1696 Anti-Automation Evasion and its sub-techniques T1696.001 Automate CAPTCHA Completion and T1696.002 Avoid CAPTCHA point at inline application-layer protections and bot management that keep enforcing automation controls after a CAPTCHA is solved. T1557.004 Evil Twin points at wireless intrusion prevention systems (WIPS) that scan for rogue access points. In practice M1031 is delivered by three different tool families: network IPS, wireless IPS and inline web or bot protection.
MITRE D3FEND relates M1031 to three defensive techniques: D3-ITF Inbound Traffic Filtering, D3-OTF Outbound Traffic Filtering and D3-NTA Network Traffic Analysis. The outbound filter is the one most often missing.
Techniques M1031 mitigates, by tactic
The table groups all 62 v20 mappings by parent technique. "How M1031 helps" paraphrases ATT&CK's own usage text for that mapping.
| Tactic | Technique (mapped sub-techniques) | How M1031 helps, per ATT&CK |
|---|---|---|
| Command and Control | T1071 Application Layer Protocol (.001 to .005: web, file transfer, mail, DNS, publish/subscribe) | Signatures for specific malware traffic over standard protocols |
| Command and Control | T1095 Non-Application Layer Protocol, T1571 Non-Standard Port, T1572 Protocol Tunneling | Signatures for malware protocol behaviour regardless of port |
| Command and Control | T1090 Proxy (.001, .002), T1102 Web Service (.001 to .003), T1008 Fallback Channels, T1104 Multi-Stage Channels | Unique indicators within the protocol a family uses |
| Command and Control | T1001 Data Obfuscation (.001 to .003), T1132 Data Encoding (.001, .002) | Mitigates "some obfuscation activity" where the encoding is distinctive |
| Command and Control | T1568 Dynamic Resolution (.002 Domain Generation Algorithms) | Reverse engineered DGAs let defenders predict and block future C2 domains |
| Command and Control | T1573 Encrypted Channel (.001, .002) | Signatures for specific malware, limited by encryption (see limits) |
| Command and Control | T1105 Ingress Tool Transfer, T1219 Remote Access Tools | Malware signatures and unusual transfers over protocols such as FTP; may prevent traffic to remote access services |
| Exfiltration | T1041 Exfiltration Over C2 Channel, T1048 Exfiltration Over Alternative Protocol (.001 to .003), T1029 Scheduled Transfer, T1030 Data Transfer Size Limits | Signatures for known C2 infrastructure and malware |
| Lateral Movement | T1570 Lateral Tool Transfer | Malware signatures or unusual transfers over known tools and protocols |
| Credential Access, Collection | T1557 Adversary-in-the-Middle (.001 to .004) | Traffic patterns indicative of AiTM; WIPS for evil twins and rogue access points |
| Collection | T1602 Data from Configuration Repository (.001 SNMP MIB Dump, .002 Network Device Configuration Dump) | Detect SNMP queries from unauthorised sources; signatures for Smart Install use from sources other than the trusted director |
| Discovery | T1046 Network Service Discovery | Detect and prevent remote service scans |
| Execution | T1204 User Execution (.001, .003, .004, .005) | Block malicious links and downloads together with download scanning |
| Initial Access | T1566 Phishing (.001) | With attachment and link scanning, block delivery |
| Stealth, Persistence | T1542.004 ROMMONkit, T1542.005 TFTP Boot | Signatures for protocols such as TFTP used to load images |
| Stealth | T1221 Template Injection; T1696 Anti-Automation Evasion (.001, .002) | Stop documents fetching remote payloads; inline bot controls beyond CAPTCHA |
Prioritising the mapping
Not every mapping deserves equal effort. NHI Mgmt Group suggests ranking them by how much an IPS can realistically block on your traffic:
- High yield: T1105 and T1570 tool transfers, T1046 scans crossing segment boundaries, T1602 SNMP and Smart Install from unauthorised sources, T1542.005 TFTP from unexpected hosts. These are protocol or source anomalies a signature or simple rule can block with few false positives.
- Medium yield: T1071, T1095, T1571, T1572, T1090 and T1219 for known malware families and unapproved remote access tools, provided threat intelligence feeds keep rules current.
- Low yield without decryption: T1573, T1102 and T1041 over HTTPS, and exfiltration to cloud services. Pair with TLS inspection, DNS controls and egress allowlists.
- Different tool: T1557.004 (WIPS) and T1696 (bot management) belong to the wireless and web teams. Assign owners rather than assuming the network IPS covers them.
Placement and signatures by technique
| Sensor position | Techniques it can block | Rule focus |
|---|---|---|
| Internet egress (outbound) | T1071, T1095, T1571, T1573, T1568.002, T1102, T1041, T1048, T1029, T1030, T1219 | Malware C2 families, DGA and newly seen domains, unapproved remote access tools, non-standard ports |
| Internet ingress (inbound) | T1566.001, T1204, T1221, T1105 | Malicious downloads and documents, exploit kits, file transfer anomalies |
| Internal east-west (between zones) | T1570, T1046, T1557.001, T1557.002, T1557.003 | SMB tool transfers, scanning, name resolution poisoning, ARP and DHCP anomalies |
| Management network | T1602.001, T1602.002, T1542.004, T1542.005 | SNMP from non-management hosts, Smart Install (TCP 4786) from anything but the director, TFTP image transfers |
| Wireless (WIPS) | T1557.004 | Rogue and evil twin access points, deauthentication patterns |
| Web application edge | T1696, T1696.001, T1696.002 | Automation signals, challenge token state, rate controls |
Network device telemetry and configuration changes complement the management-network sensor: see the SNMP Security Guide and the Network Device Management Plane Hardening Guide. For wireless, see Wireless intrusion detection; for the web edge, the Bot Management Guide.
How to implement M1031 well
- Map paths before rules. List every egress point, including cloud NAT gateways and remote user tunnels. An IPS that only sees the head office internet link misses cloud workloads entirely.
- Start in detect mode. Run the engine in a mode that alerts but does not drop. In Suricata, for example, AF_PACKET
copy-mode: tapbridges traffic without dropping, whilecopy-mode: ipshonours thedropaction. NFQUEUE deployments can use the queuebypassoption so traffic still flows if the engine stops, at the cost of no blocking while it is down. - Promote rules to drop by technique. Move high-yield categories (scans across zones, unauthorised SNMP, Smart Install, TFTP, known C2 families) to blocking first, after two to four weeks of clean alerting.
- Decide fail-open or fail-closed per segment. Fail-open keeps the business running but silently removes M1031; fail-closed protects but can cause outages. Record the decision and alert when the bypass engages.
- Feed it intelligence. ATT&CK's T1568 note depends on reverse engineered DGAs and current C2 indicators; subscribe to rule feeds and add local indicators from incident response.
- Roll back cleanly. Keep rule changes in version control, stage them on one sensor, and revert a rule to alert-only rather than disabling the sensor when a false positive hits production.
Where identity fits
Machine identities generate much of the outbound traffic an IPS inspects. CI/CD runners, backup agents and SaaS connectors call out with API keys and tokens, and an attacker using a stolen token over HTTPS looks exactly like the workload. M1031 does not stop that misuse: the traffic is valid, encrypted and destined for a legitimate API. Pair it with egress allowlists per workload (see Cloud Egress Filtering) and with token monitoring, covered in the MITRE ATT&CK T1078 Valid Accounts Guide.
What M1031 does not stop
- Novel or custom tooling: signatures depend on known indicators, so a new implant or a living-off-the-land session passes until a rule exists.
- Encrypted traffic: without decryption the sensor sees TLS handshake metadata such as server name and certificate fields, not payloads. See the TLS Inspection Guide for the privacy and pinning trade-offs.
- Legitimate services used for C2: T1102 Web Service traffic to popular cloud platforms is hard to block without breaking business use.
- Traffic that never crosses a sensor: host-to-host traffic inside one segment, and cloud-to-cloud traffic between SaaS providers.
- Valid credentials: logins with stolen passwords or tokens are not a signature problem. They need M1032 and account controls.
Behavioural detection in an NDR Guide style tool, segmentation (M1030) and filtering (M1037) cover much of the gap.
Detection and measurement
- Technique coverage: percentage of the 62 mapped techniques with an enabled blocking rule on a sensor in the relevant path (target the high-yield group at 100%).
- Path coverage: percentage of egress points, including cloud egress, passing through an inline sensor.
- Bypass time: hours per month that any sensor ran in fail-open or bypass state.
- Rule freshness: median age of the rule set and time from a new C2 indicator to a deployed rule.
- Validation pass rate: share of scheduled adversary emulation tests (benign C2 simulations, scan tests, SNMP from an unauthorised host) that were blocked.
- Decryption coverage: share of outbound TLS sessions inspected, against an agreed exemption list.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | M1031 Network Intrusion Prevention | 62 mapped techniques and sub-techniques |
| MITRE D3FEND | D3-ITF, D3-OTF, D3-NTA | Related defensive techniques per D3FEND's mapping |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring, SI-4(4) Inbound and Outbound Communications Traffic, SC-7 Boundary Protection | Monitoring and blocking at boundaries, both directions |
| NIST CSF 2.0 | DE.CM-01, PR.IR-01 | Network monitoring and protection from unauthorised logical access |
| NIST SP 800-94 | Guide to IDPS | Network-based, wireless, network behaviour analysis and host-based IDPS families |
Common failure patterns
- Inbound only: sensors tuned for inbound exploits, with no outbound policy, miss almost all of the Command and Control mappings.
- Permanent detect mode: the IPS never moved beyond alerting, so M1031 is claimed in coverage reports but nothing is blocked.
- Silent fail-open: a bypass engaged during an upgrade and nobody alerted on it for weeks.
- Management plane unwatched: SNMP and Smart Install traffic never crosses the sensor, so T1602 coverage is assumed but absent.
- Cloud left out: workloads in cloud accounts reach the internet through gateways the on-premises IPS never sees.
Practitioner checklist
- List the 62 v20 mappings and assign each to network IPS, WIPS, web edge or "not covered".
- Confirm an inline sensor on every egress path, including cloud and remote access.
- Block SNMP, Smart Install and TFTP from anything but named management hosts.
- Promote high-yield rule categories to drop after a monitored alert period.
- Alert on every bypass or fail-open event.
- Agree a TLS inspection scope and exemption list with privacy and legal teams.
- Run quarterly benign emulation tests against the mapped techniques.
- Pair M1031 with segmentation, egress filtering and identity controls for the gaps.
Standards and references
- MITRE ATT&CK: M1031 Network Intrusion Prevention
- MITRE D3FEND: Network Traffic Analysis
- MITRE D3FEND: Outbound Traffic Filtering
- NIST: SP 800-94 Guide to Intrusion Detection and Prevention Systems (IDPS)
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- OISF: Suricata IPS/inline mode for Linux
Related NHI Mgmt Group resources: M1030 Network Segmentation, M1037 Filter Network Traffic, IDS and IPS Guide, NDR Guide, TLS Inspection Guide, Network Segmentation Guide, M1032 Multi-factor Authentication.