T0869: Standard Application Layer Protocol
Adversaries may establish command and control capabilities over commonly used application layer protocols such as HTTP(S), OPC, RDP, telnet, DNP3, and modbus. These protocols may be used to disguise adversary actions as benign network traffic. Standard protocols may be seen on their associated port or in some cases over a non-standard port. Adversaries may use these protocols to reach out of the network for command and control, or in some cases to other infected devices within the network.
Analyst context for executives and security teams
This ICS technique matters because command-and-control traffic can hide inside protocols that operators and engineers expect to see, including HTTP(S), OPC, RDP, telnet, DNP3, and Modbus. For leadership, the key issue is not whether these protocols exist, but whether the organization can prove which systems are allowed to use them, where they may communicate, and whether abnormal use would be noticed before it affects control operations.
Executive priority
Prioritize this as an operational resilience and segmentation validation issue. The ATT&CK relationships show broad relevance across ICS assets including workstations, HMIs, PLCs, RTUs, IEDs, historians, control servers, application servers, data gateways, VPN servers, jump hosts, firewalls, switches, safety controllers, DCS controllers, and PACs. Executives should ask whether critical process-control zones have enforceable allowlists, segmentation between enterprise and ICS networks, and non-disruptive intrusion prevention suitable for real-time control and safety communications.
Technical view
SOC, OT security, and IR teams should validate visibility into application-layer protocol use across ICS boundaries and internal control-network segments. Because ATT&CK provides no official detection text for T0869, detection engineering should be driven by local baselines: expected source/destination pairs, ports, protocols, device roles, and approved remote access paths. Pay particular attention to standard protocols appearing on non-standard ports, unexpected outbound connections from ICS assets, and peer-to-peer communications between devices that should not communicate directly. ATT&CK also links this technique to DET0799, Detection of Standard Application Layer Protocol, but no detection detail is supplied here.
Likely telemetry
- Firewall and boundary access-control logs between enterprise, DMZ, and ICS networks
- Network flow records showing source, destination, port, protocol, direction, and session volume
- Deep packet inspection or protocol-aware OT monitoring for HTTP(S), OPC, RDP, telnet, DNP3, and Modbus where safely supported
- VPN server and jump host connection logs for remote access paths into ICS environments
- Host network connection telemetry from Windows/Linux workstations, HMIs, servers, historians, and application servers where available
Detection direction
- Baseline allowed protocol use by asset role, especially for HMIs, control servers, historians, gateways, jump hosts, VPN servers, PLCs, RTUs, IEDs, safety controllers, DCS controllers, and PACs.
- Alert on standard application protocols used over non-standard ports or between source/destination pairs not documented in the ICS communication matrix.
- Tune carefully for OT realities: DNP3, Modbus, OPC, RDP, and HTTP(S) may be legitimate, so detections should combine protocol, direction, asset role, timing, and destination context rather than protocol name alone.
- Review outbound connections from ICS networks and lateral connections between infected or potentially compromised internal devices, as the ATT&CK description notes both external and internal command-and-control possibilities.
- Account for visibility blind spots where encrypted traffic, unmanaged embedded devices, switches, firewalls, or segmented networks limit packet inspection or endpoint telemetry.
Mitigation priorities
- Start with network segmentation: isolate critical systems, functions, and resources; use DMZ patterns for internet-facing services; and restrict enterprise-to-ICS access to required systems and services.
- Implement network allowlists for approved IP addresses, MAC addresses, ports, and protocols, using device role and process requirements as the source of truth.
- Apply network intrusion prevention at boundaries where feasible, but configure it cautiously so it does not disrupt real-time control or safety communications.
- Validate remote access architecture around VPN servers and jump hosts, ensuring standard protocols such as RDP are limited to approved paths.
- Maintain an ICS asset inventory and communication matrix so allowlisting, segmentation, and detections can be audited and updated when engineering changes occur.
Analyst notes and limits
ATT&CK associates this technique with OilRig and with software entries BlackEnergy, REvil, and Stuxnet, indicating the behavior is represented across multiple ATT&CK relationship examples. Those relationships should be used for threat-informed prioritization, not as evidence of current activity in any specific environment. The most defensible local assessment is whether standard protocol use is governed, monitored, and constrained for the ICS assets present.
The supplied ATT&CK object has no specified tactics, no technique-level platforms, and no official detection text. The relationship to DET0799 is named but not detailed. Practical detection and control recommendations therefore require local architecture, asset inventory, approved communication flows, and safety/availability constraints.
Standard Application Layer Protocol
Adversaries may establish command and control capabilities over commonly used application layer protocols such as HTTP(S), OPC, RDP, telnet, DNP3, and modbus. These protocols may be used to disguise adversary actions as benign network traffic. Standard protocols may be seen on their associated port or in some cases over a non-standard port. Adversaries may use these protocols to reach out of the network for command and control, or in some cases to other infected devices within the network.
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.
Groups, software, and campaigns
G0049: OilRig
OilRig is a suspected Iranian threat group that has targeted Middle Eastern and international victims since at least 2014. The group has targeted a variety of sectors, including financial, government, energy, chemical, and telecommunications. It appears the group carries out supply chain attacks, leveraging the trust relationship between organizations to attack their primary targets. The group works on behalf of the Iranian government based on infrastructure details that contain references to Iran, use of Iranian infrastructure, and targeting that aligns with nation-state interests.[1][2][3][4][5][6][7]
S1045: INCONTROLLER
INCONTROLLER is custom malware that includes multiple modules tailored towards ICS devices and technologies, including Schneider Electric and Omron PLCs as well as OPC UA, Modbus, and CODESYS protocols. INCONTROLLER has the ability to discover specific devices, download logic on the devices, and exploit platform-specific vulnerabilities. As of September 2022, some security researchers assessed INCONTROLLER was developed by CHERNOVITE.[1][2][3][4][5]
S0089: BlackEnergy
BlackEnergy is a malware toolkit that has been used by both criminal and APT actors. It dates back to at least 2007 and was originally designed to create botnets for use in conducting Distributed Denial of Service (DDoS) attacks, but its use has evolved to support various plug-ins. It is well known for being used during the confrontation between Georgia and Russia in 2008, as well as in targeting Ukrainian institutions. Variants include BlackEnergy 2 and BlackEnergy 3. [1]
S1165: FrostyGoop
FrostyGoop is a Windows-based binary written in Golang that allows for interaction with industrial control system (ICS) equipment via Modbus TCP over port 502. FrostyGoop allows for reading and writing data to holding registers on targeted devices, manipulating the operation of systems for malicious purposes. FrostyGoop is associated with the FrostyGoop Incident in Ukraine.[1][2]
S0603: Stuxnet
Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]
S0496: REvil
REvil is a ransomware family that has been linked to the GOLD SOUTHFIELD group and operated as ransomware-as-a-service (RaaS) since at least April 2019. REvil, which as been used against organizations in the manufacturing, transportation, and electric sectors, is highly configurable and shares code similarities with the GandCrab RaaS.[1][2][3]
S1009: Triton
All related ATT&CK context
Mitigation direction
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 | ff966b0f9e42… |
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 T0869Open 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.