T0806: Brute Force I/O
Adversaries may repetitively or successively change I/O point values to perform an action. Brute Force I/O may be achieved by changing either a range of I/O point values or a single point value repeatedly to manipulate a process function. The adversary's goal and the information they have about the target environment will influence which of the options they choose. In the case of brute forcing a range of point values, the adversary may be able to achieve an impact without targeting a specific point. In the case where a single point is targeted, the adversary may be able to generate instability on the process function associated with that particular point.
Adversaries may use Brute Force I/O to cause failures within various industrial processes. These failures could be the result of wear on equipment or damage to downstream equipment.
Analyst context for executives and security teams
Brute Force I/O is an ICS behavior where an adversary repeatedly changes process input/output point values to force an action or destabilize a function. The business significance is not the volume of activity alone; it is that repeated manipulation of control points can translate into equipment wear, downstream damage, or process failure. For executives and site leaders, this is a cyber-physical risk that depends heavily on whether critical HMIs, PLCs, RTUs, IEDs, control servers, safety controllers, DCS controllers, and PACs are segmented, authenticated, filtered, and monitored for abnormal control activity.
Executive priority
Prioritize this as an operational resilience and safety-adjacent control validation issue in ICS environments. Leaders should ask whether only authorized systems can issue I/O-changing commands, whether application-layer automation protocol filtering is in place where communication patterns are well-defined, and whether SOC/OT monitoring can distinguish expected operator or automation changes from repetitive or successive abnormal point changes. This technique also matters for audit and compliance evidence because segmentation, allowlisting, authentication, and traffic filtering are concrete controls that can be documented and tested.
Technical view
ATT&CK provides no official detection text for T0806, but it does relate the technique to DET0737, Detection of Brute Force I/O, and to multiple ICS assets including HMIs, PLCs, RTUs, IEDs, control servers, safety controllers, DCS controllers, and PACs. SOC, OT, and incident response teams should validate visibility into I/O point value changes, command sources, command rates, affected point ranges, and whether repeated writes are consistent with expected control logic or operator activity. Detection engineering should focus on abnormal repetition, successive changes to a single point, broad changes across point ranges, and unexpected command paths between control servers, HMIs, and field devices.
Likely telemetry
- Automation protocol traffic involving I/O point reads and writes, where available
- HMI and control server activity showing operator-initiated or software-initiated point changes
- Controller, RTU, IED, PAC, DCS controller, and safety controller event logs where supported
- Network flow records between HMIs, control servers, engineering or supervisory systems, and field devices
- Alerts or historian records showing rapid, repeated, or unusual point value changes
Detection direction
- Validate whether DET0737-style detection logic exists for repetitive or successive I/O point value changes rather than only generic network anomalies.
- Tune detections against normal process behavior, scheduled operations, control loops, maintenance activity, and operator actions to reduce false positives.
- Correlate abnormal point changes with the command source, authenticated user or process where available, target asset type, and affected process function.
- Look for both patterns described by ATT&CK: repeated manipulation of a single point and broad manipulation across a range of I/O points.
- Identify blind spots where automation protocols, embedded controllers, or safety-related devices do not provide sufficient logging and require network or historian-based monitoring.
Mitigation priorities
- Start with network segmentation to restrict access between enterprise networks, supervisory systems, and critical process control systems.
- Implement network allowlists so only expected IP addresses, MAC addresses, ports, and protocols can communicate with sensitive ICS devices.
- Require authentication of devices and software processes where appropriate, especially for remote connections and API access.
- Apply network traffic filtering, including application-layer filtering for automation protocols where communication sequences, message types, rates, or patterns are well-defined.
- Pair preventive controls with monitoring of I/O changes and periodic validation that segmentation, allowlists, authentication, and filtering still match the current process architecture.
Analyst notes and limits
The supplied ATT&CK object is ICS-focused and highlights cyber-physical consequences such as equipment wear, downstream equipment damage, and industrial process failures. The relationship set is useful for scoping defensive validation because the technique targets multiple control and supervisory asset types and is mitigated by segmentation, allowlisting, authentication, and traffic filtering. No official tactic, platform list, or detection narrative is provided for the technique itself, so local architecture and process baselines are essential.
This take is limited to the supplied ATT&CK STIX fields, external reference, and relationships. It does not establish that any organization is exposed, that any named software is active in an environment, or that detection coverage exists. Detection and mitigation feasibility will vary by ICS protocol, device logging capability, asset ownership, safety constraints, and approved change windows.
Brute Force I/O
Adversaries may repetitively or successively change I/O point values to perform an action. Brute Force I/O may be achieved by changing either a range of I/O point values or a single point value repeatedly to manipulate a process function. The adversary's goal and the information they have about the target environment will influence which of the options they choose. In the case of brute forcing a range of point values, the adversary may be able to achieve an impact without targeting a specific point. In the case where a single point is targeted, the adversary may be able to generate instability on the process function associated with that particular point.
Adversaries may use Brute Force I/O to cause failures within various industrial processes. These failures could be the result of wear on equipment or damage to downstream equipment.
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]
S1157: Fuxnet
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 | a629e08bfc87… |
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 T0806Open 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.