AN1931: Analytic 1931
Monitor and analyze traffic flows that do not follow the expected protocol standards and traffic flows (e.g., extraneous packets that do not belong to established flows , or gratuitous or anomalous traffic patterns). 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)). Monitor and analyze traffic patterns and packet inspection associated to protocol(s), leveraging SSL/TLS inspection for encrypted traffic, 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 finding traffic that does not behave like the protocol or normal flow pattern it claims to be. For an ICS environment, that matters because abnormal packets, gratuitous traffic, malformed protocol structure, or unexpected encrypted communications can be early evidence of misconfiguration, unauthorized tooling, or activity that could affect operational reliability. Its value is not in a single alert, but in validating whether the organization can compare real traffic against expected protocol behavior and correlate suspicious flows back to the process or command line that created them.
Executive priority
Prioritize this as a visibility and resilience question: can security and operations teams prove they understand normal ICS network behavior well enough to identify abnormal protocol use without overwhelming analysts? Leaders should ask whether encrypted traffic inspection is feasible and governed, whether SOC and IR teams can tie network anomalies to hosts and processes, and whether this evidence supports incident decisions, compliance review, and operational risk management.
Technical view
The supplied ATT&CK analytic has no platform or tactic mapping, so implementation should be environment-driven. Detection teams should validate monitoring for traffic flows that violate expected protocol standards, include extraneous packets outside established flows, show gratuitous or anomalous patterns, or contain anomalous syntax or structure. Where encrypted traffic is present and policy allows, validate SSL/TLS inspection or equivalent metadata-based inspection. Correlate packet and flow anomalies with endpoint process monitoring and command-line data to identify files or processes that do not normally initiate connections for the relevant protocols.
Likely telemetry
- Network flow records showing established and non-established traffic relationships
- Packet capture or protocol inspection output for anomalous syntax, structure, or packet behavior
- Encrypted traffic inspection results or TLS metadata where full inspection is not available
- Host process execution telemetry
- Command-line telemetry tied to network-initiating processes
Detection direction
- Baseline expected protocol behavior and normal traffic flows before treating anomalies as high-confidence security events.
- Tune for extraneous packets, gratuitous traffic, malformed or unusual protocol structure, and flows inconsistent with established communication patterns.
- Correlate network anomalies with process and command-line evidence to reduce false positives from engineering tools, maintenance activity, or unusual but authorized operations.
- Validate blind spots around encrypted traffic, unmanaged assets, limited packet capture retention, and network segments not visible to monitoring tools.
- Because no ATT&CK tactic, platform, or relationship context is supplied, avoid overfitting this analytic to a specific threat scenario without local evidence.
Mitigation priorities
- Establish and maintain approved ICS communication baselines by asset, protocol, and flow direction.
- Ensure network monitoring covers critical segments and can inspect or characterize protocol behavior, including encrypted traffic where legally and operationally appropriate.
- Collect endpoint process and command-line telemetry on systems where network-originating process context is needed for investigation.
- Define change-management and maintenance windows so legitimate anomalous traffic can be explained and documented.
- Use findings to drive segmentation review, monitoring improvements, and incident response playbooks for abnormal protocol behavior.
Analyst notes and limits
This is a detection analytic rather than a technique. The official description emphasizes protocol conformance, traffic-flow anomaly analysis, packet inspection, SSL/TLS inspection for encrypted traffic, and correlation with process and command-line monitoring. In ICS, coordination with operations teams is important because unusual traffic may reflect maintenance, scanning, engineering activity, or misconfiguration rather than malicious behavior.
No official detection logic, platforms, tactics, labels, aliases, or relationship context were supplied. The take therefore cannot assert specific affected technologies, adversary behavior, active exploitation, or guaranteed detection coverage. Local network architecture, protocol inventory, encryption policy, and endpoint telemetry availability are required to operationalize this analytic.
Analytic 1931
Monitor and analyze traffic flows that do not follow the expected protocol standards and traffic flows (e.g., extraneous packets that do not belong to established flows , or gratuitous or anomalous traffic patterns). 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)). Monitor and analyze traffic patterns and packet inspection associated to protocol(s), leveraging SSL/TLS inspection for encrypted traffic, 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 | 3c46b2b01007… |
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 AN1931Open 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.