AN1891: Analytic 1891
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)). Monitor for known proxy protocols (e.g., SOCKS, Tor, peer-to-peer protocols) and tool usage (e.g., Squid, peer-to-peer software) on the network that are not part of normal operations. Also 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.
Analyst context for executives and security teams
This analytic matters because unexpected protocol behavior and uncommon network flows can be early evidence that an ICS environment is being used in ways operators did not intend, including proxy-like communications, anomalous packet structure, or processes initiating network traffic that normally should not. For leaders, the decision value is whether the organization can prove it understands “normal” ICS network behavior well enough to notice deviations before they affect operations.
Executive priority
Prioritize this as a visibility and operational resilience question: do SOC and OT teams have enough network inspection, baseline knowledge, and process context to distinguish approved industrial traffic from anomalous flows? It is also useful for audit and incident readiness because it tests whether the organization can show evidence of monitoring for unauthorized protocols, proxy tools, peer-to-peer traffic, and abnormal communications in sensitive environments.
Technical view
Validate monitoring for traffic that does not follow expected protocol standards or normal traffic flows, including extraneous packets, gratuitous traffic, anomalous syntax or structure, known proxy protocols such as SOCKS or Tor, peer-to-peer protocols, and tools such as Squid or peer-to-peer software where they are not part of normal operations. Where available, correlate network observations with process monitoring and command-line data to identify processes that rarely or never initiate network connections, or files/processes that do not normally communicate using the observed protocol.
Likely telemetry
- Network traffic metadata and flow records
- Packet inspection or protocol inspection data
- Alerts or logs for proxy protocols such as SOCKS or Tor
- Indicators of peer-to-peer protocol use
- Network communications by process, where available
Detection direction
- Build or validate baselines for expected protocol standards, syntax, structure, and traffic flows in the relevant environment.
- Tune for uncommon data flows and processes that newly begin network communication, while accounting for authorized engineering, maintenance, or monitoring activity.
- Correlate anomalous network patterns with process and command-line telemetry when available to reduce false positives and improve triage quality.
- Review whether proxy and peer-to-peer protocol detections are enabled and whether approved business exceptions are documented.
- Treat absence of platform and tactic metadata as a reason to validate coverage locally rather than assuming applicability across all assets.
Mitigation priorities
- Define and document normal network flows, approved protocols, and authorized tools for the environment.
- Limit or control use of proxy, peer-to-peer, and other non-standard communications where they are not operationally required.
- Ensure network monitoring can inspect relevant traffic patterns and retain evidence needed for incident response.
- Where feasible, collect process and command-line telemetry to support correlation with anomalous network activity.
- Regularly review exceptions and baseline changes with OT, SOC, and incident response stakeholders.
Analyst notes and limits
This is an ICS ATT&CK detection analytic focused on anomalous protocol behavior, uncommon flows, proxy or peer-to-peer protocol use, and correlation with process and command-line activity. The supplied object provides descriptive monitoring guidance but no separate official detection logic, no tactics, no platforms, and no relationship context.
Assessment is limited to the supplied MITRE fields and external reference. No active exploitation, threat actor use, impacted platforms, or guaranteed detection coverage is implied. Local network architecture, approved ICS communications, sensor placement, and endpoint telemetry availability will determine practical coverage.
Analytic 1891
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)). Monitor for known proxy protocols (e.g., SOCKS, Tor, peer-to-peer protocols) and tool usage (e.g., Squid, peer-to-peer software) on the network that are not part of normal operations. Also 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.
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 | 642dc996da7c… |
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 AN1891Open 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.