AN1258: Analytic 1258
Non-standard port/protocol pairings or low-entropy ICMP traffic resembling tunneling patterns (e.g., fixed-size pings with delays).
Analyst context for executives and security teams
This analytic matters because it points to network traffic patterns that can indicate covert or misconfigured communications: unusual port/protocol combinations and ICMP traffic that looks mechanically repetitive, such as fixed-size pings with delays. For leaders, the value is not that this single analytic proves malicious activity, but that it tests whether the organization can see and investigate suspicious network behavior that may bypass application-centric controls.
Executive priority
Prioritize this as a visibility and resilience question for network monitoring: do SOC and incident response teams have enough network telemetry from network devices to identify unusual protocol use and tunneling-like ICMP patterns, and can they distinguish malicious activity from legitimate administration or monitoring? It is relevant to control assurance, incident triage readiness, and audit evidence around network monitoring, but the supplied ATT&CK data does not tie it to a specific tactic, actor, campaign, or confirmed impact.
Technical view
Validate whether network-device telemetry can expose non-standard port/protocol pairings and repetitive, low-entropy ICMP behavior. Because ATT&CK provides no formal detection logic for this analytic, teams should treat it as a detection-engineering prompt: define local baselines for expected protocol use, common service ports, sanctioned ICMP behavior, and known monitoring tools before alerting. Investigation should focus on source/destination context, recurrence, packet size consistency, timing patterns, and whether traffic aligns with approved network functions.
Likely telemetry
- Network device flow records or equivalent traffic summaries
- Firewall, router, switch, or gateway logs showing protocol, port, source, destination, and timing
- ICMP metadata such as type/code, packet size, frequency, and interval patterns
- Allowed-service inventories or network policy records for expected port/protocol use
- Asset and network zone context to determine whether the communicating systems should exchange this traffic
Detection direction
- Build or validate analytics for port/protocol combinations that are unusual for the environment rather than relying only on globally unusual ports.
- Baseline legitimate ICMP sources such as monitoring, diagnostics, and network health checks to reduce false positives.
- Look for repetitive ICMP characteristics called out by the ATT&CK description, including fixed-size packets and delayed or regular timing patterns.
- Correlate anomalous traffic with asset role, network segment, and policy expectations before escalating.
- Document blind spots where network devices do not log sufficient protocol, port, timing, or ICMP metadata.
Mitigation priorities
- Ensure network devices and enforcement points log enough detail to support investigation of protocol, port, and ICMP behavior.
- Review network policy for unnecessary protocol exposure and unexpected port/protocol allowances.
- Define sanctioned uses of ICMP and monitoring traffic so defenders can separate expected operations from suspicious patterns.
- Use segmentation and egress controls where appropriate to limit unauthorized network paths.
- Maintain evidence of monitoring coverage and policy exceptions for compliance and incident readiness.
Analyst notes and limits
This is a detection analytic object, not a technique description. The supplied object names Network Devices as the platform and describes anomalous port/protocol pairings and low-entropy ICMP patterns, but it provides no tactic, no official detection logic, and no relationship context. Treat the take as guidance for validating telemetry and local detection design rather than as a claim of confirmed malicious behavior.
The source data is sparse: no tactics, no relationships, no procedure examples, and no official detection query are provided. Local baselines, network architecture, approved monitoring practices, and device logging capabilities are required to determine whether this analytic is actionable.
Analytic 1258
Non-standard port/protocol pairings or low-entropy ICMP traffic resembling tunneling patterns (e.g., fixed-size pings with delays).
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 | 8508c9e18dd3… |
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 AN1258Open 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.