AN1870: Analytic 1870
Monitor operational process data for write commands for an excessive number of I/O points or manipulating a single value an excessive number of times. This will not directly detect the technique’s execution, but instead may provide additional evidence that the technique has been used and may complement other detections. Some asset application logs may provide information on I/O points related to write commands. Monitor for write commands for an excessive number of I/O points or manipulating a single value an excessive number of times. Monitor network traffic for ICS functions related to write commands for an excessive number of I/O points or manipulating a single value an excessive number of times.
Analyst context for executives and security teams
This analytic matters because abnormal write activity in an ICS environment can be a warning sign that operational values or I/O points are being manipulated at scale or repeatedly. For executives and security leaders, the value is not in treating this as a standalone proof of compromise, but in using it as operational evidence that can support faster incident triage, safer plant decision-making, and better validation of whether ICS monitoring actually sees control-changing activity.
Executive priority
Prioritize this as a resilience and incident-readiness question: can the organization identify excessive or repeated write commands affecting operational process data before they create safety, reliability, or production consequences? Leaders should ask whether SOC, OT operations, and incident response teams have access to the process data, asset application logs, and ICS network visibility needed to investigate suspicious write activity, and whether thresholds are defined with operations input to avoid both missed events and noisy alerting.
Technical view
The supplied ATT&CK analytic recommends monitoring operational process data, asset application logs, and ICS network traffic for write commands involving an excessive number of I/O points or excessive manipulation of a single value. SOC and OT detection teams should validate whether they can observe write functions, identify affected I/O points or values, count frequency and scope over time, and correlate the activity with authorized engineering, maintenance, or control operations. Because the official text states this may provide additional evidence rather than directly detect technique execution, it should be used as a corroborating analytic alongside other OT, network, host, and operator-context evidence.
Likely telemetry
- Operational process data showing value changes and write activity
- Asset application logs that include I/O points related to write commands
- ICS network traffic containing functions related to write commands
- Time-series counts of write frequency by value, point, source, and destination
- Operational context for authorized maintenance, engineering, or control actions
Detection direction
- Validate that monitoring can distinguish write commands from normal read/status traffic where the available telemetry supports it.
- Define environment-specific baselines for expected write frequency, number of I/O points touched, and repeated manipulation of a single value.
- Tune thresholds with OT operations to reduce false positives from legitimate batch changes, maintenance windows, commissioning, testing, or automated control behavior.
- Correlate excessive write activity with asset logs, process data changes, and network observations rather than treating this analytic as direct proof of technique execution.
- Identify blind spots where application logs do not record I/O point detail, network monitoring cannot parse ICS functions, or process historians lack sufficient fidelity.
Mitigation priorities
- Establish or improve collection of operational process data, relevant asset application logs, and ICS network telemetry before relying on this analytic.
- Document normal write patterns for critical processes and high-value I/O points with input from engineering and operations teams.
- Create triage procedures that require SOC and OT personnel to confirm whether excessive writes are authorized, expected, or operationally unsafe.
- Use change-control and maintenance-window evidence to separate legitimate write activity from activity requiring incident response escalation.
- Review monitoring coverage for critical assets and process areas where repeated or broad write activity would create the greatest operational risk.
Analyst notes and limits
This is an ICS detection analytic, not a technique description. No tactics, platforms, relationships, aliases, or separate official detection field were supplied. The official description explicitly frames the analytic as supporting evidence that may complement other detections, so it should be operationalized as part of a broader OT detection and incident response workflow.
The supplied object does not identify a specific ATT&CK technique, platform, protocol, adversary, software, or relationship context. It also does not provide concrete thresholds for what counts as excessive. Local process knowledge, asset criticality, normal operating patterns, and available telemetry are required to make this analytic actionable.
Analytic 1870
Monitor operational process data for write commands for an excessive number of I/O points or manipulating a single value an excessive number of times. This will not directly detect the technique’s execution, but instead may provide additional evidence that the technique has been used and may complement other detections. Some asset application logs may provide information on I/O points related to write commands. Monitor for write commands for an excessive number of I/O points or manipulating a single value an excessive number of times. Monitor network traffic for ICS functions related to write commands for an excessive number of I/O points or manipulating a single value an excessive number of times.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 83b9487789e3… |
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 AN1870Open 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.