How do attackers use ICMP address mask request?

How address mask requests fit into network discovery

An icmp address mask request is a legacy way to ask a host for its subnet mask. Attackers use the reply to infer local network boundaries, reduce guesswork about nearby targets, and improve subsequent recon or lateral-movement planning. Modern stacks usually do not need it, so any response is more valuable to the attacker than to the defender.

That makes the traffic useful less for exploitation than for mapping. A single answered request can reveal whether the host is likely on a routed subnet, how wide the local segment may be, and where to focus follow-on probes.

For broader context on risky legacy protocols and discovery traffic, see Network Ports and Protocols Security Guide.

Why even one reply helps an attacker

Address mask requests are attractive because they can collapse uncertainty. If the mask is known, an attacker can narrow address ranges, avoid wasting noise on irrelevant subnets, and choose scan paths that look more like normal local traffic. That matters most in flat networks, stale environments, or places where legacy ICMP behavior was never disabled.

The value is usually tactical rather than decisive. The response does not hand over credentials or direct access, but it can improve the quality of later enumeration by telling the attacker how to think about the local broadcast domain.

Attackers also benefit from defenders who leave old discovery functions enabled in the name of compatibility. Legacy convenience often becomes reconnaissance support.

How defenders should treat the control surface

Best practice is to block or suppress ICMP address mask responses unless a documented operational dependency exists. Where the protocol is not needed, silence is safer than compatibility because the mask is rarely necessary for normal operations on modern networks. If a business process still depends on it, limit exposure to the smallest trusted segment and review why that dependency still exists.

Monitor for repeated or unusual discovery traffic, especially when it appears across multiple hosts or from an address outside the expected local segment. A small burst may be curiosity; repeated probing is a better indicator of mapping activity.

If you need a current view of adversary discovery behavior and related abuse patterns, CISA cyber threat advisories is a useful reference point.

Risk and Threat Considerations

Risk comes from information disclosure, not from the packet itself. A reply can expose enough about subnet structure to improve recon efficiency, especially in environments where segmentation is weak or network ranges are predictable.

Failure mechanism: The host answers a legacy discovery request and reveals mask information that helps an attacker infer local topology, narrow scan ranges, and plan follow-on enumeration with less noise.

Impact: The attacker gets a better map of the environment, which can speed up target selection, reduce detection risk, and support later intrusion steps such as scanning, pivoting, or host prioritisation.

Practitioner Guidance

What to verify: Confirm whether any systems still answer address mask requests and whether that behavior is actually required. If the answer is no, disable or filter it at the edge and in host configuration where possible.

What to measure: Watch for repeated ICMP discovery traffic from the same source, especially if it is followed by sweep-style scans or probes against nearby address ranges. Treat that sequence as a stronger signal than a single isolated request.

Decision rule: If you must keep the response enabled for a specific legacy dependency, constrain it to the smallest trusted segment and document the exception. If there is no clear operational need, default to suppression.

Practitioner takeaway: The main defensive goal is not to block an old packet type for its own sake, but to remove a low-cost source of topology intelligence that can make later recon more effective.

Related resources from NHI Mgmt Group

• ICMP Address Mask Request
• How should organisations respond when attackers use an internal request system to gain more access through a compromised user?
• What happens when attackers compromise an employee inbox and use the existing thread to request payment?
• What happens when attackers use compromised vendor accounts to request payment changes?