T0802: Automated Collection
Adversaries may automate collection of industrial environment information using tools or scripts. This automated collection may leverage native control protocols and tools available in the control systems environment. For example, the OPC protocol may be used to enumerate and gather information. Access to a system or interface with these native protocols may allow collection and enumeration of other attached, communicating servers and devices.
Analyst context for executives and security teams
Automated Collection in ICS matters because it can turn limited access to a control-system interface or protocol into rapid discovery of connected industrial servers, controllers, and devices. For leaders, the risk is not just data collection; it is that an adversary may build an accurate map of operational technology dependencies before later disruptive actions. The ATT&CK record specifically highlights native control protocols such as OPC and relationships to PLCs, DCS controllers, PACs, control servers, and data historians.
Executive priority
Prioritize this as an OT visibility and segmentation question: can the organization prove which systems are allowed to communicate using industrial protocols, and can it detect unusual enumeration or bulk information gathering across critical control assets? This technique is especially relevant to business continuity and incident response readiness because data historians and control servers may bridge operational and business needs, while controllers are directly tied to physical processes.
Technical view
SOC, OT security, and IR teams should validate monitoring for automated enumeration or collection over native control-system protocols and tools, especially around communications involving PLCs, PACs, DCS controllers, control servers, and data historians. The ATT&CK object has no official detection text and no technique-level platforms or tactics specified, but it is related to detection strategy DET0734. Treat coverage as environment-specific: confirm protocol visibility, asset context, and baselines for expected engineering, historian, and control-server communications.
Likely telemetry
- ICS network traffic metadata and packet/protocol logs where available
- OPC and other native control-protocol activity relevant to the environment
- Connections among control servers, data historians, PLCs, PACs, and DCS controllers
- Asset inventory and network communication allowlist data: IP address, MAC address, port, and protocol
- Host or application logs from control servers and data historians where available
Detection direction
- Validate what DET0734-style detection means in the local environment, since the supplied ATT&CK object does not include official detection logic.
- Baseline normal industrial protocol communication paths and look for unusual breadth, frequency, timing, or source systems performing enumeration-like activity.
- Correlate network observations with asset roles; the same traffic may be expected from engineering or historian workflows but suspicious from unrelated hosts.
- Pay special attention to systems that can reach both enterprise-accessible services and process-control assets, such as data historians and control servers.
- Document blind spots where encrypted traffic, unsupported protocols, unmanaged switches, or lack of OT asset inventory prevents confident interpretation.
Mitigation priorities
- Start with network segmentation to isolate critical control systems, functions, and resources and to restrict access from enterprise or unrelated networks.
- Implement network allowlists defining permitted connections by IP address, MAC address, port, and protocol where operationally feasible.
- Review whether internet-facing or business-accessible services are contained through a DMZ and cannot directly reach critical process-control systems.
- Use the asset inventory to confirm that only required systems can communicate with PLCs, PACs, DCS controllers, control servers, and data historians.
- Treat mitigation changes carefully in OT environments; validate with operations and engineering teams before enforcement to avoid disrupting legitimate process control.
Analyst notes and limits
Relationship context increases the practical relevance of this technique: ATT&CK links it to critical ICS assets and to software examples including Backdoor.Oldrea, Industroyer, and Industroyer2. Those relationships support defensive prioritization, but they do not by themselves prove current exposure or active exploitation in any specific environment.
The official ATT&CK object provides a short description, no official detection text, no specified tactics, and no technique-level platforms. Local protocol use, asset architecture, normal engineering workflows, and available OT telemetry are required to turn this into reliable detections or control assurance.
Automated Collection
Adversaries may automate collection of industrial environment information using tools or scripts. This automated collection may leverage native control protocols and tools available in the control systems environment. For example, the OPC protocol may be used to enumerate and gather information. Access to a system or interface with these native protocols may allow collection and enumeration of other attached, communicating servers and devices.
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
S1072: Industroyer2
Industroyer2 is a compiled and static piece of malware that has the ability to communicate over the IEC-104 protocol. It is similar to the IEC-104 module found in Industroyer. Security researchers assess that Industroyer2 was designed to cause impact to high-voltage electrical substations. The initial Industroyer2 sample was compiled on 03/23/2022 and scheduled to execute on 04/08/2022, however it was discovered before deploying, resulting in no impact.[1]
S0093: Backdoor.Oldrea
Backdoor.Oldrea is a modular backdoor that used by Dragonfly against energy companies since at least 2013. Backdoor.Oldrea was distributed via supply chain compromise, and included specialized modules to enumerate and map ICS-specific systems, processes, and protocols.[1][2][3]
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]
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 | 8a7093ecf80a… |
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 T0802Open 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.