Internet Control Message Protocol (ICMP) carries network control and error messages, such as unreachable destinations or echo requests and replies. It is also used for discovery and troubleshooting, but attackers can abuse it for reconnaissance or tunnelling, so defenders should filter only what is needed and monitor unusual patterns.
What ICMP actually does on a network
ICMP is part of the network layer control plane, not an application protocol. It lets hosts and routers report conditions that affect packet delivery, for example when a destination is unreachable, a route has failed, or a packet cannot be forwarded as sent. It also supports basic diagnostics such as echo request and reply, which is why tools like ping and traceroute depend on it.
Because ICMP is used for network signalling rather than data transport, its behavior is tightly tied to routing and reachability, which is why the protocol registry maintained by IANA matters for anyone mapping protocol numbers and message types. The protocol itself is standardised through the internet engineering process led by the IETF.
In practice, ICMP messages are generated automatically by network devices or endpoints when they need to communicate a control condition. That makes ICMP useful for troubleshooting, but it also means packet filters should be selective rather than indiscriminate. Blocking all ICMP can hide legitimate failure signals, while allowing everything can expose useful reconnaissance data.
How ICMP supports troubleshooting and discovery
ICMP is most familiar through ping, which sends echo requests and expects echo replies to confirm basic reachability and round-trip behavior. Operators also rely on ICMP errors, such as time exceeded or destination unreachable, to understand where a packet path is failing. This makes ICMP a diagnostic signal as much as a transport mechanism.
That diagnostic role is why ICMP often appears during network discovery and path mapping. A host that responds to echo requests may be reachable, but that alone does not prove that all services on it are open or healthy. Good troubleshooting therefore treats ICMP as one visibility layer, not as a complete health check.
For defenders, the practical value is to preserve the ICMP types needed for legitimate operations and path debugging while limiting those that reveal more than necessary. The same message family that helps an administrator locate a fault can also help an attacker confirm live hosts, map routes, or identify filtering behavior.
Why ICMP becomes a security concern
ICMP is often abused because it is widely permitted and easy to blend into normal network traffic. Attackers can use it for reconnaissance, for example by probing which systems respond, or for tunnelling, where data is hidden inside ICMP messages to bypass egress controls. Some environments also leak too much topology information through error responses, which can help an adversary refine attack paths.
That risk does not mean ICMP should be disabled everywhere. It means defenders should understand which message types are operationally required, which are noisy but harmless, and which are unnecessary in a given environment. Filtering decisions should be based on function, not on a blanket assumption that all ICMP is either safe or dangerous.
A useful reference point for the threat side is the Command and Control (C2) Guide, which covers beaconing, DNS analytics, egress filtering, and ICMP tunnelling as part of modern C2 tradecraft. The same protocol can be a legitimate troubleshooting tool and a covert communications channel, depending on how it is handled.
Risk and Threat Considerations
ICMP creates exposure when organisations allow it broadly without understanding which message types are actually needed. Overly permissive rules can leak host availability, path information, and filtering behavior, while overly aggressive blocking can break diagnostics and obscure the root cause of network failures.
Failure mechanism: Attackers abuse allowed ICMP traffic for host discovery, path mapping, or covert tunnelling, and defenders miss the activity because the traffic looks like ordinary network control exchange.
Impact: The result can be faster reconnaissance, weaker egress visibility, and delayed incident detection, especially where ICMP is allowed across trust boundaries without monitoring or type-level filtering.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0011 — Command and Control | ICMP tunnelling and beaconing are C2 techniques used to move data covertly. |
| Recommendation — Map ICMP tunnelling to TA0011 and monitor for unusual beaconing or egress patterns. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | ICMP misuse is detectable through network monitoring and anomaly baselines. |
| PR.SC-05 — Resilience mechanisms are implemented to achieve resilience requirements in normal and adverse situations | Selective ICMP handling supports resilient operations without overexposing the network. | |
| Recommendation — Monitor ICMP volume, type mix, and destinations for abnormal network activity. Implement type-specific ICMP filtering that preserves required diagnostics. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | ICMP abuse is a network-defense problem requiring traffic inspection and alerting. |
| Recommendation — Log and inspect ICMP patterns that indicate reconnaissance or tunnelling. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Cloud filters that allow excess ICMP create avoidable exposure and weak network control. |
| Recommendation — Tighten cloud rules so only operationally required ICMP types are allowed. | ||
Practitioner Guidance
What to verify: Confirm which ICMP types your environment actually needs for operations, then validate that your firewall, cloud security group, and host-based rules allow only those types and directions. Pay special attention to echo, destination unreachable, time exceeded, and any organisation-specific diagnostics you rely on.
Common mistake: Teams often treat ICMP as a single on/off decision. In practice, selective allowance and monitoring are more effective than blanket permit or deny rules because they preserve troubleshooting value while reducing unnecessary exposure.
What practitioners underestimate: ICMP is frequently quiet until something breaks, which makes it easy to overlook in monitoring baselines. If you do not measure normal ICMP volume and patterns, unusual spikes, unusual destinations, or unexpected outbound ICMP may not stand out during an incident.
Practitioner takeaway: ICMP should be governed as a controlled diagnostic and signalling channel, not as background noise, because the operational value and the reconnaissance value come from the same mechanism.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org