DET0737: Detection of Brute Force I/O
DET0737 is an ICS detection strategy for spotting behavior related to Brute Force I/O: repeated or successive changes to I/O point values intended to manip...
Analyst context for executives and security teams
DET0737 is an ICS detection strategy for spotting behavior related to Brute Force I/O: repeated or successive changes to I/O point values intended to manipulate a process function. For leaders, the value is not just “detect a technique,” but confirming whether the organization can see abnormal manipulation attempts against the control points that drive physical operations.
Executive priority
Prioritize this where process availability, safety, or production integrity depends on trusted I/O values. Executives should ask whether SOC and OT teams can produce evidence of who or what changed critical points, how often, from where, and whether those changes were expected. This supports incident decision-making, operational resilience, and audit-ready proof that critical control activity is monitored.
Technical view
ATT&CK provides no official detection logic, platforms, or tactics for DET0737, but the relationship to T0806 indicates the detection focus: repetitive or successive modification of a single I/O point or a range of I/O points. SOC, OT monitoring, and IR teams should validate whether telemetry can distinguish normal operator/control activity from unusual bursts, sequences, or sweeps of point-value changes, especially when correlated with source host, user/session, time window, and process context.
Likely telemetry
- I/O point value change records from control-system monitoring, where available
- Process historian trends showing repeated or successive point changes
- OT network telemetry showing write/change activity to control points, where available
- HMI, operator station, or engineering workstation activity logs, where available
- Change-management, maintenance-window, and operator action records for false-positive context
Detection direction
- Baseline normal frequency and sequence of I/O point changes for critical processes before alerting on repetition alone.
- Look for repeated changes to the same point and successive changes across ranges of points, consistent with the related T0806 behavior.
- Correlate point changes with authorized users, workstations, maintenance windows, and expected process state to reduce false positives.
- Validate blind spots where historian data exists but write-source identity, session details, or OT network visibility is missing.
- Treat unsupported or context-free alerts cautiously; legitimate control loops, testing, commissioning, and maintenance can resemble repeated I/O activity.
Mitigation priorities
- Identify and prioritize monitoring for critical I/O points tied to safety, production, or availability.
- Restrict and review write access to control points based on operational role and need.
- Maintain approved-change and maintenance-window records so detections can be triaged quickly.
- Ensure SOC/OT incident response procedures include verification of process state and authorized operator activity.
- Use segmentation, access control, and change governance to reduce opportunities for unauthorized point manipulation.
Analyst notes and limits
This take is based on the official DET0737 detection-strategy object and its relationship to ICS technique T0806, Brute Force I/O. Because MITRE supplied no official description or detection text for DET0737, the practical guidance is derived only from the related technique behavior and conservative defensive validation needs.
Platforms, tactics, and official detection analytics are not specified in the supplied ATT&CK fields. Local engineering context, process baselines, and available OT telemetry are required before determining coverage, severity, or alert thresholds.
Detection of Brute Force I/O
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0806 | Brute Force I/O | This object detects Brute Force I/O. |
All related ATT&CK context
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 | 97a1ae92a502… |
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 DET0737Open 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.