DET0799: Detection of Standard Application Layer Protocol
DET0799 matters because command-and-control activity in ICS environments may use ordinary application protocols such as HTTP(S), OPC, RDP, telnet, DNP3, or...
Analyst context for executives and security teams
DET0799 matters because command-and-control activity in ICS environments may use ordinary application protocols such as HTTP(S), OPC, RDP, telnet, DNP3, or Modbus. The business issue is not that these protocols are unusual; it is that they are often expected in operational networks, so malicious traffic can be missed if teams only look for rare protocols or obvious port misuse.
Executive priority
Security leaders should treat this as a validation point for operational resilience: can the organization distinguish approved ICS communications from suspicious use of standard protocols, including traffic on non-standard ports or traffic leaving the network? This supports incident decision-making, segmentation and monitoring investment, and audit evidence for control over operational network communications.
Technical view
For SOC, detection engineering, and IR teams, validate visibility into standard application-layer protocols used in the ICS environment and compare observed flows against known asset roles and approved communication paths. Pay particular attention to HTTP(S), OPC, RDP, telnet, DNP3, and Modbus used for external communications, lateral communications between infected devices, or operation over unexpected ports. Because platforms and official detection logic are not specified, local baselining is essential.
Likely telemetry
- Network flow records between ICS assets, enterprise networks, and external destinations
- Firewall and segmentation device logs showing allowed and denied protocol/port use
- IDS/NDR protocol metadata for HTTP(S), OPC, RDP, telnet, DNP3, and Modbus
- Proxy or secure web gateway logs where HTTP(S) traffic is routed through them
- Asset inventory and network baseline data mapping expected protocols to approved devices and zones
Detection direction
- Do not treat standard protocols as automatically benign; validate whether the communicating assets, direction, timing, and destination are expected.
- Alert or review standard protocols used on non-standard ports, and standard ports carrying unexpected protocol behavior where telemetry supports that distinction.
- Baseline ICS protocol usage by zone and asset function to reduce false positives from normal engineering, maintenance, or control-system operations.
- Correlate external outbound communications with internal ICS asset roles; many control devices should have narrow and predictable communication patterns.
- Review east-west communications for unusual peer-to-peer patterns that could align with command and control between infected devices.
Mitigation priorities
- Prioritize accurate ICS asset and communication-path inventory so monitoring can distinguish expected from suspicious standard-protocol use.
- Restrict protocol and port use between ICS zones and toward external networks using segmentation and allowlisting where operationally feasible.
- Limit or tightly govern remote administration protocols such as RDP and telnet in operational environments.
- Ensure network monitoring covers key ICS choke points and can preserve evidence needed for incident response.
- Use change control for new or altered protocol paths so detection baselines remain reliable.
Analyst notes and limits
This detection strategy is only defined through its relationship to ATT&CK technique T0869, Standard Application Layer Protocol. The practical focus is therefore on validating whether common protocols are being used in expected ways within an ICS environment, rather than assuming any listed protocol is malicious.
The supplied ATT&CK object has no official description, no official detection text, no specified platforms, and no tactics. Recommendations are derived from the relationship to T0869 and require local network architecture, asset inventory, and telemetry confirmation before operational use.
Detection of Standard Application Layer Protocol
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0869 | Standard Application Layer Protocol | This object detects Standard Application Layer Protocol. |
All related ATT&CK context
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 | c314fc481ac2… |
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 DET0799Open 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.