AN1962: Analytic 1962
Monitor network data for uncommon data flows. Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious. Monitor and analyze traffic patterns and packet inspection associated to protocol(s) that do not follow the expected protocol standards and traffic flows (e.g extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g. monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)).
Analyst context for executives and security teams
This analytic is about spotting network activity that is unusual for the environment: processes or traffic flows that do not normally communicate, have never been seen before, or do not follow expected protocol behavior. For leaders, the value is not a single alert rule; it is a coverage question: can the organization distinguish normal network behavior from abnormal behavior early enough to support investigation and response?
Executive priority
Prioritize this as a visibility and readiness control. It supports SOC triage and incident response by helping identify suspicious network behavior when no specific malware, tool, or attacker is known. Executives should ask whether network baselines exist, whether uncommon flows can be investigated quickly, and whether teams can correlate network anomalies with process and command-line evidence. The supplied ATT&CK object lists the platform as PRE and provides no tactic mapping, so this should be treated as a general detection analytic rather than proof of coverage for a specific ATT&CK tactic.
Technical view
Validate that detection engineering can monitor network data for uncommon data flows, unexpected protocol syntax or structure, extraneous packets outside established flows, gratuitous or anomalous traffic patterns, and processes that do not normally initiate network connections. The analytic specifically calls for correlation with process monitoring and command-line data, so SOC workflows should connect network observations to the responsible process and execution context where available. Because no official detection logic is provided, local baselining, allowlisting, and tuning are required.
Likely telemetry
- Network flow records showing source, destination, port, protocol, direction, timing, and volume
- Packet or protocol inspection metadata capable of identifying anomalous syntax, structure, or traffic patterns
- Process monitoring data identifying which process initiated network communication
- Command-line telemetry associated with processes that initiate or handle network connections
- Baseline or historical network behavior for hosts, processes, and protocols
Detection direction
- Establish baselines for processes and hosts that normally communicate over the network, then alert on first-seen or rare process-to-network behavior.
- Tune detections for protocol anomalies, extraneous packets outside established flows, gratuitous traffic, and syntax or structure that does not match expected protocol standards.
- Correlate network anomalies with process and command-line context before escalation to reduce false positives from new software, administrative tools, updates, or environment changes.
- Review blind spots where packet inspection, endpoint process telemetry, or command-line collection is unavailable, because the analytic depends on cross-correlation rather than network data alone.
- Because ATT&CK provides no official detection implementation for this object, test detections against local traffic patterns and document assumptions.
Mitigation priorities
- First, ensure required visibility exists: network flow monitoring, relevant protocol inspection, endpoint process monitoring, and command-line collection where appropriate.
- Next, define and maintain normal communication baselines for important hosts, services, protocols, and processes.
- Then, create triage procedures that link anomalous network flows to process identity, command line, and host context.
- Finally, review exceptions regularly so new legitimate services do not create persistent noise and suspicious first-seen behavior is not automatically normalized.
Analyst notes and limits
This is a detection analytic, not a technique description. Its practical value is in anomaly detection and correlation: unusual network flows become more actionable when tied to process and command-line evidence. The object has no supplied relationships, no aliases, no labels, no tactic mapping, and no official detection block, so all implementation detail must come from local telemetry and engineering decisions.
The supplied fields do not identify a specific adversary behavior, campaign, platform beyond PRE, or ATT&CK tactic. They also do not provide query logic, thresholds, data source mappings, or relationship context. Any claim of detection coverage requires validation in the local environment.
Analytic 1962
Monitor network data for uncommon data flows. Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious. Monitor and analyze traffic patterns and packet inspection associated to protocol(s) that do not follow the expected protocol standards and traffic flows (e.g extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g. monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)).
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 | 10cde298587c… |
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 AN1962Open 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.