AN1869: Analytic 1869
Analyze network data for uncommon data flows (e.g., new protocols in use between hosts, unexpected ports in use). Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious. Monitor for mismatches between protocols and their expected ports (e.g., non-HTTP traffic on tcp:80). Analyze packet contents to detect communications that do not follow the expected protocol behavior for the port that is being used.[1]
Analyst context for executives and security teams
This analytic is about finding network communications that do not fit the expected pattern: new host-to-host flows, unusual protocols or ports, processes communicating when they normally do not, or traffic whose packet contents do not match the port being used. For leaders, the practical value is baseline assurance: if the organization cannot explain what “normal” network communication looks like, especially in an ICS environment, it will struggle to detect abnormal command-and-control-like behavior or investigate suspicious connectivity quickly.
Executive priority
Prioritize this as a visibility and resilience question rather than a single alert rule. Executives and risk owners should ask whether critical network segments have enough traffic monitoring to identify uncommon flows, unexpected ports, and protocol/port mismatches. This supports incident decision-making, audit evidence for monitoring coverage, and cyber-physical risk reduction where unexpected communications could indicate unauthorized activity in operational environments.
Technical view
SOC, detection engineering, and IR teams should validate whether network data is available to baseline normal communications and inspect deviations. The ATT&CK object does not specify platforms or tactics, so implementation should be environment-driven. Focus on uncommon source/destination pairs, newly observed protocols, unexpected destination ports, processes or hosts with no prior network history, and packet contents that do not follow the protocol expected for the port, such as non-HTTP behavior on tcp/80.
Likely telemetry
- Network flow records showing source, destination, ports, protocol, timing, and volume
- Packet capture or deep packet inspection where available to validate protocol behavior
- Protocol metadata from network monitoring sensors
- Host-to-network correlation data when available to identify processes or hosts initiating unusual communications
- Baselines of expected communications between hosts, zones, services, and ports
Detection direction
- Validate that monitoring can identify newly observed or rare host-to-host flows rather than only known-bad indicators.
- Tune detections around protocol/port mismatches and unexpected services, but account for legitimate tunneling, proxies, maintenance tools, and application-specific behavior to reduce false positives.
- Compare observed packet contents against expected protocol behavior for the port in use when packet inspection is available.
- Use local baselines because the object provides no platform, tactic, or relationship context; what is uncommon in one ICS environment may be normal in another.
- Review blind spots such as unmanaged segments, encrypted traffic with limited metadata, missing east-west visibility, and logs that lack process-to-network attribution.
Mitigation priorities
- Establish and maintain an approved communication baseline for critical network zones and assets.
- Ensure network monitoring coverage exists at points where unusual inter-host traffic and unexpected ports would be visible.
- Segment networks and restrict unnecessary protocols and ports based on validated operational requirements.
- Create investigation playbooks for uncommon flows and protocol/port mismatches, including escalation paths for operational technology environments.
- Periodically test whether SOC and IR teams can retrieve the telemetry needed to confirm or dismiss suspicious network behavior.
Analyst notes and limits
The supplied object is a detection analytic in the ICS ATT&CK domain. Its official description emphasizes uncommon data flows, unexpected ports, network use by processes or hosts without prior communication history, and protocol/port mismatches. No tactics, platforms, official detection text, or relationships were supplied, so this take frames practical validation around network visibility and local baselining.
This summary is based only on the provided ATT&CK analytic description and external references. It does not establish active exploitation, adversary attribution, affected platforms, or guaranteed detection coverage. Local architecture, asset inventory, segmentation, and telemetry quality are required to determine applicability.
Analytic 1869
Analyze network data for uncommon data flows (e.g., new protocols in use between hosts, unexpected ports in use). Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious. Monitor for mismatches between protocols and their expected ports (e.g., non-HTTP traffic on tcp:80). Analyze packet contents to detect communications that do not follow the expected protocol behavior for the port that is being used.[1]
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 | a92757a8af54… |
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]
University of Birmingham C2
Gardiner, J., Cova, M., Nagaraja, S. (2014, February). Command & Control Understanding, Denying and Detecting. Retrieved April 20, 2016.
Open source URL -
[2]
mitre-attack AN1869Open 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.