How can security teams detect an ICMP IP total length field probe?

What the probe is trying to reveal

An ICMP IP total length field probe is a packet-analysis technique, not a normal service request. The attacker places deliberately odd IP total length values into quoted packet headers inside ICMP errors to see how a target or intermediary parses malformed traffic, and then uses the response pattern to map device behaviour.

For defenders, the useful question is less “does ICMP exist” and more “do we see ICMP errors that preserve strange header values, or behaviour that diverges from ordinary path and host traffic?” That distinction helps separate routine diagnostics from packets crafted to expose parser quirks.

When packet captures are available, compare the quoted header fields against what a normal host, router, or firewall would emit on the same path. A probe becomes more interesting when the length values are intentionally inconsistent, repeated, or paired with other malformed header traits that should not appear in standard ICMP error handling.

How to spot it in packet data

The most reliable detection is inspection of packet captures or sensor output that includes the full ICMP payload. Look for ICMP destination-unreachable, time-exceeded, or other error messages that embed an IP header whose total length field is unusual for the traffic pattern, especially when it does not match the quoted payload or the surrounding flow.

Good detections usually combine field-level inspection with context. A single malformed-looking packet can be noise, but a series of ICMP errors carrying odd total length values from the same source, aimed at multiple hosts or ports, is a stronger probe pattern. Alerting works best when the rule is tied to malformed ICMP error structure rather than ICMP volume alone.

It also helps to compare the observed ICMP error behaviour with baseline path traffic. If a device consistently rewrites, suppresses, or rejects these packets, that is useful operational information in itself, because the absence of a response can still indicate filtering, normalization, or hardened parser behaviour.

What defenders should validate after detection

Once a probe is detected, validate whether the observed packets are isolated reconnaissance or part of broader malformed-packet testing. Check whether the same source is also sending other unusual ICMP, fragmentation, or header-manipulation traffic, and whether the target systems show parsing errors, resets, or other anomalies around the same time.

Confirmation should focus on the parser path that handled the packet. Network devices, host stacks, and security appliances do not always react the same way, so the same probe may be benign on one control point and revealing on another. That is why the most useful evidence is a capture of the raw packet plus the device response, not just a log summary.

If the probe reaches internal systems, review whether any monitoring, intrusion prevention, or packet-normalization control is expected to suppress malformed ICMP before it reaches the host. If it is not, the detection should be treated as a visibility gap as much as an event.

Risk and Threat Considerations

Malformed ICMP probes matter because they are often used as a low-noise way to test how stacks, middleboxes, and security tools handle edge-case packet structures. The risk is not just reconnaissance, it is also parser inconsistency, where different devices interpret the same malformed packet differently and create blind spots in detection or filtering.

Failure mechanism: The attacker varies the IP total length field inside quoted headers to provoke different parsing behaviour, then infers device type, normalization, or weakness from the response or lack of response.

Impact: A successful probe can expose network handling differences, support follow-on fuzzing or evasion, and reveal where malformed traffic is accepted, rewritten, or insufficiently monitored.

Practitioner Guidance

What to verify: Make sure your sensors capture the embedded IP header inside ICMP errors, not only the outer ICMP type and code. Without that field visibility, you may see only “ICMP traffic” and miss the probe value entirely.

Decision rule: If you see repeated ICMP errors with deliberately inconsistent total length values, treat them as reconnaissance and inspect the source’s broader malformed-packet activity before assuming they are harmless diagnostics.

Practitioner takeaway: The key is to detect the malformed quoted header, then confirm whether your stack normalizes, ignores, or exposes parser behaviour that an attacker can use to learn about the path.

Related resources from NHI Mgmt Group

• Guide: Network Ports and Protocols Security Guide
• How do attackers use ICMP IP Total Length Field Probe?
• ICMP IP Total Length Field Probe
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?