T0884: Connection Proxy
Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications.
The definition of a proxy can also be expanded to encompass trust relationships between networks in peer-to-peer, mesh, or trusted connections between networks consisting of hosts or systems that regularly communicate with each other.
The network may be within a single organization or across multiple organizations with trust relationships. Adversaries could use these types of relationships to manage command and control communications, to reduce the number of simultaneous outbound network connections, to provide resiliency in the face of connection loss, or to ride over existing trusted communications paths between victims to avoid suspicion. [1]
Analyst context for executives and security teams
Connection Proxy matters in ICS because trusted communications paths can become a hiding place for adversary traffic. Instead of many obvious outbound connections, traffic may be relayed through systems, networks, VPN paths, jump hosts, gateways, or other trusted relationships that already exist for operations. For security leaders, the practical issue is not just “is there a proxy,” but whether the organization can prove which ICS assets are allowed to communicate, through which paths, and whether those paths are monitored without disrupting control or safety functions.
Executive priority
Prioritize this as an operational resilience and trust-boundary risk. ATT&CK relates this technique broadly to ICS assets including workstations, HMIs, PLCs, RTUs, IEDs, historians, control servers, application servers, data gateways, VPN servers, jump hosts, routers, switches, firewalls, safety controllers, DCS controllers, PACs, and field I/O. That breadth means a proxying behavior can challenge segmentation assumptions, remote access governance, and incident scoping. Leaders should ask for evidence of approved communication paths, network allowlists, boundary monitoring, and safe inspection/filtering practices suitable for industrial environments.
Technical view
SOC, IR, and detection engineering teams should validate network-centric visibility across ICS trust paths, especially between business and ICS networks, remote access infrastructure, data gateways, jump hosts, VPN servers, firewalls, historians, control servers, and field networks. MITRE does not provide official detection text for T0884, but the relationship to DET0759 indicates a detection strategy exists for Connection Proxy. Defenders should focus on deviations from expected source-destination-port-protocol relationships, unexpected intermediary systems, unusual relaying patterns, reduced but concentrated outbound connections, and traffic riding over trusted peer, mesh, or inter-organization links. Because ICS communications can be deterministic and safety-sensitive, tuning should distinguish approved operational flows from newly observed or abnormal relay behavior.
Likely telemetry
- Network flow records between ICS, corporate, remote access, and trusted partner networks
- Firewall, router, switch, VPN server, and jump host connection logs
- IDS/IPS alerts and protocol metadata at network boundaries
- DNS and name-resolution logs where available
- Proxy, gateway, and application server access logs where present
Detection direction
- Validate whether monitoring covers trusted paths, not only direct internet egress.
- Baseline expected ICS communication sequences, protocols, rates, and source-destination pairs, then alert on new intermediaries or abnormal relay paths.
- Review traffic where one asset appears to broker communication for multiple systems or where many expected connections collapse into a smaller number of outbound sessions.
- Correlate network events with asset roles: historian, data gateway, VPN server, jump host, firewall, HMI, control server, PLC/RTU/IED, and other targeted ICS assets.
- Tune carefully for legitimate architectures such as protocol translation, remote management, VPN bridging, and data historian access from business networks.
Mitigation priorities
- Start with a documented ICS communication allowlist: approved IPs, MACs, ports, protocols, and asset roles.
- Implement Network Allowlists where practical, especially for devices with well-defined communication requirements.
- Filter network traffic at ingress, egress, and internal ICS boundaries, including protocol-aware filtering for automation protocols where supported.
- Use Network Intrusion Prevention at boundaries only with configurations that avoid disrupting real-time control or safety communications.
- Consider SSL/TLS inspection for encrypted web traffic where it is operationally safe, legally approved, and technically compatible.
Analyst notes and limits
The supplied ATT&CK object is an ICS technique, T0884 Connection Proxy. It has no specified tactics, no technique-level platforms, and no official detection text. Relationship context is strong for ICS asset relevance and mitigation direction: DET0759 detects it; M0807 Network Allowlists, M0920 SSL/TLS Inspection, M0931 Network Intrusion Prevention, and M0937 Filter Network Traffic mitigate it. ATT&CK also relates the technique to the 2015 Ukraine Electric Power Attack campaign, which supports historical relevance but should not be read as evidence of current activity in any environment.
This take is limited to the supplied STIX fields, external references, and relationships. It does not establish current exploitation, local exposure, attribution, or confirmed detection coverage. Actual priority depends on local ICS architecture, remote access design, trust relationships, asset inventory quality, and whether network telemetry is collected at the relevant boundaries.
Connection Proxy
Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications.
The definition of a proxy can also be expanded to encompass trust relationships between networks in peer-to-peer, mesh, or trusted connections between networks consisting of hosts or systems that regularly communicate with each other.
The network may be within a single organization or across multiple organizations with trust relationships. Adversaries could use these types of relationships to manage command and control communications, to reduce the number of simultaneous outbound network connections, to provide resiliency in the face of connection loss, or to ride over existing trusted communications paths between victims to avoid suspicion. [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.
Groups, software, and campaigns
G0034: Sandworm Team
Sandworm Team is a destructive threat group that has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455.[1][2] This group has been active since at least 2009.[3][4][5][6]
In October 2020, the US indicted six GRU Unit 74455 officers associated with Sandworm Team for the following cyber operations: the 2015 and 2016 attacks against Ukrainian electrical companies and government organizations, the 2017 worldwide NotPetya attack, targeting of the 2017 French presidential campaign, the 2018 Olympic Destroyer attack against the Winter Olympic Games, the 2018 operation against the Organisation for the Prohibition of Chemical Weapons, and attacks against the country of Georgia in 2018 and 2019.[1][2] Some of these were conducted with the assistance of GRU Unit 26165, which is also referred to as APT28.[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]
S0604: Industroyer
Industroyer is a sophisticated malware framework designed to cause an impact to the working processes of Industrial Control Systems (ICS), specifically components used in electrical substations.[1] Industroyer was used in the attacks on the Ukrainian power grid in December 2016.[2] This is the first publicly known malware specifically designed to target and impact operations in the electric grid.[3]
C0028: 2015 Ukraine Electric Power Attack
2015 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used BlackEnergy (specifically BlackEnergy3) and KillDisk to target and disrupt transmission and distribution substations within the Ukrainian power grid. This campaign was the first major public attack conducted against the Ukrainian power grid by Sandworm Team.
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.1 | Current bundle | 180644c3b1e2… |
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]
Enterprise ATT&CK January 2018
Enterprise ATT&CK 2018, January 11 Connection Proxy Retrieved. 2018/05/17
Open source URL -
[2]
mitre-attack T0884Open 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.