IPv4 is targeted by spoofing, packet fragmentation abuse, scanning, and denial-of-service traffic that exploits its lack of built-in authentication. Attackers also use source address spoofing to hide origin or bypass weak controls. Defenders should filter spoofed traffic, monitor unusual fragmentation, constrain exposed services, and apply rate limiting and segmentation where appropriate.
How IPv4 traffic gets attacked
IPv4 is attractive because it still carries exposed services, legacy protocols, and enormous scanning surface. The most common attack patterns are address spoofing, fragmentation abuse, reconnaissance scans, and denial-of-service traffic aimed at exhausting bandwidth or state. Because IPv4 does not authenticate packets by itself, defenders have to add trust, filtering, and segmentation above the protocol.
Source address spoofing is especially important because it lets an attacker hide where traffic originated or make weak access controls less reliable. Fragmentation can also be used to evade inspection, trigger parser edge cases, or create asymmetric views between devices that reassemble packets differently. In practice, the attack surface is often less about IPv4 itself and more about how exposed networks still accept unauthenticated, internet-routable traffic.
For a broader view of exposed ports, protocol exposure, and the security impact of open network services, see the Network Ports and Protocols Security Guide.
Why spoofing, fragmentation, and scans matter operationally
Scanning is the reconnaissance layer that often comes before exploitation. It helps attackers discover live hosts, open services, and response patterns, then tune the next stage of attack traffic. Even when a scan does not lead directly to compromise, it can reveal what services are reachable, which addresses respond inconsistently, and where filtering is too permissive.
Fragmentation abuse matters because it can undermine visibility and control. If security tools and endpoints do not agree on how fragments are handled, an attacker may be able to conceal malicious payloads, consume resources, or create conditions where the detector sees a harmless packet stream while the target system reconstructs something different.
Denial-of-service traffic is the bluntest IPv4 attack pattern, but it remains effective because it targets availability, not just confidentiality or integrity. Attackers can overwhelm bandwidth, connection tables, CPU, or application dependencies by sending high-volume traffic or by forcing expensive processing through malformed or state-heavy packets.
For threat context that combines network abuse with real-world attack paths and attacker behaviour, the State of NHI & AI Agent Breach Report 2026 is useful background on how attackers chain access, discovery, and abuse once they find weak controls.
What defenders should do first on IPv4-facing systems
Defensive control starts with reducing trust in raw source addresses and making exposure narrower. Inbound filtering should reject spoofed traffic where feasible, and egress filtering should stop your own infrastructure from sending packets with forged source addresses. Constraining exposed services, limiting the number of internet-reachable hosts, and applying rate limits all reduce the blast radius of scans and flood traffic.
Monitoring should look for repeated probes, unusual fragment patterns, and traffic that arrives from inconsistent sources or ports. If a service depends on legacy IPv4 behaviours, test it deliberately rather than assuming the network stack and the security tools will interpret fragments the same way. Segmentation also matters because an exposed IPv4 service that can reach everything else behind it turns a simple probe into a wider internal risk.
When fragmentation, spoofing, or scan traffic is being analysed, map the observed pattern to known adversary techniques in the MITRE ATT&CK Enterprise Matrix so detection and response teams can reason about likely next steps.
Risk and Threat Considerations
IPv4 attack traffic is risky because the protocol still assumes too much about the network path. If spoofed packets are accepted, if fragments are handled inconsistently, or if exposed services are overbroad, attackers can hide origin, bypass weak trust checks, or make security tools miss what the endpoint actually receives.
Failure mechanism: Weak ingress filtering, permissive exposure, and inconsistent fragment handling let malicious traffic blend into normal IPv4 flows or force defenders to observe only part of the picture.
Impact: The result is better reconnaissance for attackers, weaker attribution, unreliable inspection, and a higher chance that denial-of-service or exploitation traffic reaches the target unnoticed or unthrottled.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1595 — Active Scanning | IPv4 scanning is a core reconnaissance pattern in this subject. |
| T1046 — Network Service Discovery | IPv4 attacks often begin with discovery of live hosts and reachable services. | |
| Recommendation — Map repeated probes to T1595 and alert on unusual service discovery patterns. Correlate discovery traffic with T1046 and harden exposed services accordingly. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Filtering spoofed and flood traffic depends on boundary controls around IPv4 exposure. |
| SI-4 — System Monitoring | Detecting scans, fragmentation abuse, and DoS requires traffic monitoring and alerting. | |
| Recommendation — Enforce SC-7 at network edges to restrict spoofed and unnecessary inbound IPv4 traffic. Tune SI-4 to detect scan bursts, fragment anomalies, and sustained volumetric abuse. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | IPv4 attack reduction depends on secure network architecture, filtering, and segmentation. |
| Recommendation — Harden network boundaries and segmentation to reduce IPv4 attack surface. | ||
Practitioner Guidance
What to verify: Confirm that edge devices, cloud security groups, and host firewalls all block obvious spoofing paths and that your monitoring stack can still see fragmented traffic end to end. If fragments are normalized in one layer but not another, treat that as a detection gap rather than a tuning issue.
Decision rule: If a service does not need to be internet-facing, remove it from direct IPv4 exposure before adding more inspection or alerting. If it must stay exposed, combine rate limiting, segmentation, and explicit allow lists rather than relying on passive detection alone.
Practitioner takeaway: The key IPv4 question is not whether attacks exist, but whether your environment still trusts packet origin and packet structure more than it should.
Related resources from NHI Mgmt Group
- Who should own identity risk when attacks target both people and third-party access?
- How should security teams handle vishing attacks that target SaaS support workflows?
- Why do supply-chain attacks increasingly target secrets instead of just code integrity?
- Why do supply chain attacks target package publishing and lockfiles so often?