AN1254: Analytic 1254
Anomalous use of ICMP or UDP by non-network service processes for data exfiltration or remote control, especially if traffic bypasses proxy infrastructure or shows unusual flow patterns.
Analyst context for executives and security teams
This analytic matters because ICMP or UDP traffic from ordinary Windows processes can indicate data leaving the environment or remote control activity that may not pass through normal web proxy controls. For executives and security leaders, the decision value is whether the organization can see and explain non-standard outbound traffic paths, especially when proxy, firewall, or endpoint evidence is needed during an incident.
Executive priority
Prioritize validation of visibility over outbound ICMP and UDP from Windows endpoints, particularly where business controls assume web proxies or standard egress filtering provide coverage. Leaders should ask whether SOC and incident response teams can identify which process generated the traffic, whether it bypassed proxy infrastructure, and whether unusual flow patterns can be investigated quickly enough to support containment and compliance evidence.
Technical view
For Windows environments, validate whether endpoint and network telemetry can correlate process identity with ICMP or UDP flows. Because the official ATT&CK object provides no detection logic, teams should treat this as a coverage validation use case: identify non-network service processes generating ICMP or UDP, compare against expected administrative or application behavior, and investigate traffic that avoids proxy paths or shows unusual volume, frequency, destination, or timing patterns.
Likely telemetry
- Windows endpoint process execution and process-to-network connection telemetry
- Network flow records covering ICMP and UDP
- Firewall, egress gateway, and proxy logs showing whether traffic used or bypassed expected paths
- DNS and destination enrichment data for external endpoints where available
- Asset and application inventory to distinguish expected network services from unusual user or application processes
Detection direction
- Confirm that ICMP and UDP are not blind spots in network monitoring, since proxy-centric monitoring may miss them.
- Tune around known Windows services, approved network tools, and expected business applications to reduce false positives.
- Prioritize alerts where a non-network service process generates repeated, high-volume, rare-destination, or off-hours ICMP/UDP traffic.
- Correlate endpoint process context with network flow evidence; network-only detections may show the flow but not the responsible process.
- Use local baselines because the ATT&CK object does not provide a formal detection rule, thresholds, or tactic mapping.
Mitigation priorities
- Review egress policy for ICMP and UDP and restrict unnecessary outbound paths where operationally feasible.
- Ensure Windows endpoint telemetry can capture process-to-network relationships for incident response.
- Validate firewall and proxy architecture assumptions so non-proxy traffic paths are documented and monitored.
- Maintain an inventory of approved applications and services that legitimately use ICMP or UDP.
- Document monitoring coverage and exceptions as audit-ready evidence for security control effectiveness.
Analyst notes and limits
This is a detection analytic, not a technique description. Its value is in testing whether the organization can detect anomalous ICMP or UDP use by Windows processes that are not normally network services. The most important local questions are: which processes are expected to use these protocols, which egress paths are allowed, and whether endpoint and network data can be joined during triage.
The supplied ATT&CK fields include no tactic mapping, no relationships, and no official detection procedure beyond the description. This take therefore does not infer adversary attribution, active exploitation, impact, or guaranteed detection coverage. Thresholds, allowlists, and response actions require local environment evidence.
Analytic 1254
Anomalous use of ICMP or UDP by non-network service processes for data exfiltration or remote control, especially if traffic bypasses proxy infrastructure or shows unusual flow patterns.
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 | aeca192de320… |
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 AN1254Open 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.