AN1435: Analytic 1435
Flooding tools like hping3 or nping sending large volumes of packets across multiple ports or IPs
Analyst context for executives and security teams
This analytic describes Linux-based packet-flooding behavior associated with tools such as hping3 or nping sending high volumes of packets across multiple ports or IP addresses. For leaders, the practical issue is not the tool name itself but whether the organization can distinguish authorized network testing from activity that could disrupt services, overwhelm monitoring, or indicate preparation for denial-of-service-style activity.
Executive priority
Prioritize validation where Linux systems are allowed to generate network traffic at scale, such as administration hosts, test environments, security tooling, or cloud workloads. Executives and risk owners should ask whether network monitoring, change records, and incident response processes can quickly explain unusual high-volume packet generation before it affects service availability or triggers customer-facing disruption.
Technical view
SOC and detection teams should validate visibility into Linux hosts and network flows capable of showing unusually high packet rates, broad port coverage, or traffic directed at multiple destination IPs. Because ATT&CK provides no official detection logic or tactic mapping for this analytic, teams should treat it as a detection-validation prompt rather than a ready rule. Correlate suspected flooding activity with authorized testing windows, asset ownership, process execution evidence where available, and network flow baselines.
Likely telemetry
- Linux process execution telemetry for packet-generation tools where available
- Network flow records showing packet volume, destination IP spread, and destination port spread
- Firewall, IDS/IPS, or network sensor logs showing high-rate traffic patterns
- Endpoint or server logs identifying the source host and user context
- Change-management or approved testing records to separate authorized activity from suspicious behavior
Detection direction
- Baseline normal packet rates for Linux systems that legitimately perform scanning, testing, monitoring, or security assessment work.
- Look for combinations of high packet volume, many destination ports, or multiple destination IPs rather than relying only on specific tool names.
- Tune for known administrative and testing activity to reduce false positives, especially where hping3, nping, or similar utilities are approved.
- Confirm whether detections can identify the source host and responsible account quickly enough to support incident triage.
- Document blind spots where network flow, endpoint process, or packet-rate telemetry is absent.
Mitigation priorities
- Restrict who can run network testing or packet-generation utilities on Linux systems based on operational need.
- Use network segmentation and egress controls to limit where high-volume packet traffic can originate or be sent.
- Maintain approved testing windows and change records so SOC teams can rapidly validate legitimate activity.
- Ensure incident response playbooks include ownership lookup, traffic containment, and service-impact assessment for suspected internal flooding behavior.
- Review logging coverage for Linux hosts and network chokepoints that could originate or observe this activity.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, AN1435, for Linux. It contains a concise behavior description but no official detection text, no tactic mapping, and no relationship context. The most defensible use is as a coverage and readiness check for identifying high-volume packet-generation behavior from Linux systems.
This take is limited to the official STIX fields and the single MITRE external reference provided. It does not establish active exploitation, attribution, impact, or existing detection coverage. Local baselines, approved testing procedures, asset roles, and available telemetry are required to determine severity and response.
Analytic 1435
Flooding tools like hping3 or nping sending large volumes of packets across multiple ports or IPs
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 232896b68192… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1435Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.