Brute Force I/O (T0806) is an adversary changing I/O point values repeatedly, either across a range of points or on a single point, to make a physical process fail or become unstable. It needs little knowledge of the process: switching every point in a range can cause impact without targeting a specific one, while hammering a single point can wear out or destabilise the equipment behind it. MITRE ATT&CK for ICS v20 lists T0806 under Impair Process Control (TA0106) for Embedded, Windows and Linux platforms. This guide is for OT security engineers, control and protection engineers and OT SOC analysts: what the technique covers, what Industroyer, Industroyer2 and Fuxnet show, ATT&CK's v20 analytics and mitigations, and how to respond with process safety first. For the tactic overview see the ATT&CK for ICS Impair Process Control Tactic Guide.
Key takeaways
- The write rate is the signature. ATT&CK's embedded analytic flags writes to the same point or register at a rate well above the device's configured scan cycle.
- Exclude legitimate causes first. ATT&CK says to treat the rate as suspicious only after excluding tuning, commissioning, failover and fault recovery.
- Process history corroborates. A point oscillating faster than the physical process can respond is evidence even if the network view is incomplete.
- Message authentication is the strongest mapped control. M0813 says devices should authenticate all messages between master and outstation.
- Safety comes before containment. A brute force attack is in progress against physical equipment; operations decide how to make the process safe before anyone blocks traffic.
What T0806 covers
ATT&CK for ICS describes two variants. Brute forcing a range of point values can achieve impact without targeting a specific point. Targeting a single point repeatedly can generate instability in the associated process function. ATT&CK notes the resulting failures could come from wear on equipment or damage to downstream equipment, which links T0806 to impact techniques such as Damage to Property (T0879) and Loss of Control (T0827).
| Variant | Adversary knowledge needed | Likely effect | Best signal |
|---|---|---|---|
| Range of points | Low: addresses can be discovered or iterated | Broad disruption, such as many breakers switching | Writes sweeping many addresses on one device from one source |
| Single point, repeated | Higher: which point matters | Instability or wear on one process function | Write rate on one point above scan cycle; oscillation in process history |
T0806 is distinct from Unauthorized Message (T1692), which covers sending unauthorised command messages in general; T0806 is the repetition. A single unauthorised write that opens a breaker belongs to the broader technique; switching it over and over is T0806.
The procedure examples and what they teach
| Software | What ATT&CK records | Defensive lesson |
|---|---|---|
| Industroyer (S0604) | Its IEC 104 module has range, shift and sequence modes; range mode first gathers Information Object Addresses (IOAs) and sends select and execute commands to switch state, then loops, switching the state of all discovered IOAs | Discovery and switching came from the same source in quick succession, so correlating reads and writes by source helps. |
| Industroyer2 (S1072) | Iterates across a device's IOAs to modify the ON/OFF value of an I/O state | ESET reports its target configuration was hardcoded and that it was scheduled for 8 April 2022 to cut power in a Ukrainian region, with Sandworm assessed responsible. |
| Fuxnet (S1157) | Repeatedly wrote arbitrary data over the Meter-Bus channel from impacted devices to connected sensors, to render sensor data acquisition useless | Claroty's analysis found the evidence supported attacks on sensor gateways and could not confirm claims of sensor destruction. Serial field buses behind gateways need the same attention as Ethernet protocols. |
The two Industroyer cases targeted power grid telecontrol over IEC 60870-5-104; see the IEC 60870-5-104 Telecontrol Security Guide and the Sandworm Threat Actor Profile. Claroty reports Fuxnet was claimed by a group calling itself Blackjack against Moscollector, a Moscow company that builds and monitors underground water, sewage and communications infrastructure.
Detection: ATT&CK v20 analytics
MITRE's v20 detection strategy for T0806 is DET0737, with three analytics. All carry ATT&CK's OT gate for impact techniques: alert only when the action is not attributable to an authorised operator or engineering source for that target and function, and is either outside an approved change or maintenance window or lacks matching change control context; where telemetry permits, require corroborating device, configuration or process state effects.
| Analytic | Platform | What it looks for | Data source |
|---|---|---|---|
| AN1870 | Embedded | Write commands to the same I/O point or register at a rate above the device's scan cycle; a point oscillating faster than the physical process can respond; write queue depth to one point above normal | Network content inspection; process history; SCADA application logs |
| AN2130 | Linux | An ICS service process, under the SCADA or control application's user ID, making write API calls to field I/O above the configured scan rate | Linux audit SYSCALL, EXECVE and SOCKADDR records |
| AN2207 | Windows | A SCADA server or DCS interface generating high frequency write calls to field devices above the baseline for that point | OPC DA write queue depth or throughput |
The tunable inputs are MaxWriteRatePerPoint (from the device's scan cycle and the process response time), BruteForceDetectionWindow, MaxNormalStateChangeRate and MaxWriteQueueDepth. Note that two of the three analytics expect the writes to come from the legitimate SCADA application itself, because an adversary on a SCADA server would use it. Source allowlists alone will not catch that case; the rate and process effect will.
Work out MaxWriteRatePerPoint with control and protection engineers, not from network data alone. Some points legitimately change quickly during control loops, and breaker operations may be limited by equipment duty ratings that engineers already know.
Prevention: ATT&CK mitigations in practice
- M0813 Software Process and Device Authentication: devices should authenticate all messages between master and outstation. Where the protocol supports it, for example DNP3 Secure Authentication, turn it on so an unauthenticated host cannot issue commands. See the DNP3 and DNP3 Secure Authentication Guide.
- M0937 Filter Network Traffic: allow and deny lists can block access when excessive I/O connections are detected from a system or device within a time period. Protocol-aware firewalls that understand write function codes can restrict writes to named masters.
- M0807 Network Allowlists: restrict unnecessary connections to network devices, such as communications servers and serial to Ethernet converters, especially where devices limit simultaneous sessions.
- M0930 Network Segmentation: segment operational assets and their management devices by functional role in the process, with stricter isolation for the most critical control information. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
NHI Mgmt Group also recommends engineering-side protections that limit damage whatever the network does: interlocks and rate limits in controller logic for points that drive mechanical equipment, and independent protection and safety systems that do not rely on the same communications path. These are design decisions for control and safety engineers, informed by an OT cyber risk assessment. See the OT Cyber Physical Risk and Safety Guide.
How to implement
- Identify high consequence points. With process and protection engineers, list points whose repeated switching could damage equipment or endanger people.
- Set per point limits. Document the maximum legitimate write and state change rates for those points.
- Restrict write sources. At conduits and gateways, allow write traffic only from named masters, logging would-be denies first.
- Enable message authentication where devices and protocols support it, testing on a spare outstation and during a planned outage.
- Deploy DET0737-style alerts in alert-only mode, correlating network writes with process history, and tune out commissioning and failover.
- Agree the response with operations before enforcing anything: who decides to block a master, isolate a link or switch to local control.
- Keep a rollback for every filter and authentication change, since a mistaken block on a telecontrol link is itself a loss of control.
Decision guidance
- Protocols with authentication support: enabling it is the most direct control; plan key management first.
- Legacy protocols and serial buses: rely on segmentation, gateway allowlists, protocol-aware filtering and engineering interlocks.
- Small sites: start with segmentation and interlocks on the few points that matter most.
- Utilities and telecontrol networks: control centres reach many remote stations, so protocol-aware monitoring at the control centre and at key substations, plus an OT SOC, are needed. See the OT Security Operations Centre Guide.
Responding to suspected brute force I/O
Treat it as a live process safety event. Operations first decide how to make the process safe, for example moving affected equipment to local or manual control, following existing procedures. Then contain by blocking the writing source at the conduit or gateway, if the writes come from an unapproved host. If they come from the approved SCADA server, the server itself is likely compromised, and switching to a standby or local control may be the safer containment. Preserve network captures, SCADA and historian logs and device event records. Inspect affected equipment before returning it to service, since ATT&CK notes failures may result from wear. See the OT Incident Response Guide.
Detection and measurement
- High consequence point coverage: percentage of listed points with documented rate limits and monitoring.
- Write source restriction: percentage of conduits and gateways permitting writes only from named masters.
- Authentication coverage: percentage of capable master to outstation links with message authentication enabled.
- Interlock coverage: percentage of high consequence points with logic or protection limits independent of the network.
- Rate alerts: count of write rate alerts, with time to triage and outcome.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK for ICS v20 | T0806 (TA0106 Impair Process Control); M0813, M0937, M0807, M0930; DET0737; related T1692, T0879, T0827 | Technique, mitigations, analytics and consequences |
| MITRE D3FEND | D3-PMAD Protocol Metadata Anomaly Detection; D3-NTF Network Traffic Filtering | Detecting abnormal write patterns and filtering write sources |
| NIST SP 800-53 Rev. 5 | IA-3 Device Identification and Authentication; AC-4 Information Flow Enforcement; SC-7 Boundary Protection; SC-5 Denial-of-service Protection; SI-4 System Monitoring | Authenticating masters, restricting flows and monitoring |
| NIST CSF 2.0 | DE.CM-01; PR.IR-01 | Network monitoring and protection from unauthorised access |
Common failure patterns
- Any host can write: write function codes are allowed from every host that can reach the device.
- Allowlists without rate checks: an attacker on the approved SCADA server passes every source check.
- Thresholds set without engineers: rate limits ignore scan cycles and equipment ratings, so alerts are noise.
- Serial buses forgotten: monitoring stops at the gateway, while Fuxnet shows field buses behind gateways can be attacked.
- Blocking before making safe: security staff cut a link mid-incident without operations, causing a second loss of control.
Practitioner checklist
- List high consequence points and their maximum legitimate write rates with engineers.
- Restrict write traffic to named masters at every conduit and gateway.
- Enable message authentication on capable master to outstation links.
- Add interlocks or protection limits for points that drive mechanical equipment.
- Correlate network write rates with process history in the OT SOC.
- Agree with operations who makes the process safe and who blocks traffic.
- Inspect equipment after any suspected brute force event before returning it to service.
Standards and references
- MITRE ATT&CK for ICS: Brute Force I/O (T0806)
- MITRE ATT&CK: Detection of Brute Force I/O (DET0737)
- MITRE ATT&CK for ICS: Software Process and Device Authentication (M0813)
- MITRE ATT&CK: Industroyer (S0604)
- ESET: Industroyer2: Industroyer reloaded
- Claroty Team82: Unpacking the Blackjack Group's Fuxnet Malware
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
Related NHI Mgmt Group resources: ATT&CK for ICS Impair Process Control Tactic Guide · MITRE ATT&CK for ICS Guide · IEC 60870-5-104 Telecontrol Security Guide · DNP3 and DNP3 Secure Authentication Guide · PLC Security Guide · T0827 Loss of Control · T0835 Manipulate I/O Image