AN1926: Analytic 1926
Monitor industrial process history data for events that correspond with command message functions, such as setpoint modification or changes to system status for key devices. 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. Monitor for anomalous or unexpected commands that may result in changes to the process operation (e.g., discrete write, logic and device configuration, mode changes) observable via asset application logs. Monitor for new or unexpected connections to controllers, which could indicate an Unauthorized Command Message being sent via Rogue Master. Monitor for anomalous or unexpected commands that may result in changes to the process operation (e.g., discrete write, logic and device configuration, mode changes) observable via asset application logs. Monitor for unexpected ICS protocol command functions to controllers from existing master devices (including from new processes) or from new devices. The latter is like detection for Rogue Master but requires ICS function level insight to determine if an unauthorized device is issuing commands (e.g., a historian).
Monitoring for unexpected or problematic values below the function level will provide better insights into potentially malicious activity but at the cost of additional false positives depending on the underlying operational process.
Analyst context for executives and security teams
AN1926 is an ICS detection analytic focused on using process history, controller communications, and asset application logs to find evidence of unauthorized or unexpected command activity. Its business value is that changes such as setpoint modifications, device status changes, mode changes, discrete writes, or logic/device configuration changes can affect operational continuity and cyber-physical safety. The analytic is explicitly supporting evidence rather than a standalone proof of technique execution.
Executive priority
Prioritize this analytic where industrial operations depend on trusted controller commands and accurate process history. Leaders should ask whether the organization can prove who or what issued commands to controllers, whether process changes are reviewable after an event, and whether SOC/OT teams can distinguish authorized operational changes from unexpected or risky ones. This supports incident decision-making, resilience planning, and compliance evidence for monitoring of critical control-system activity.
Technical view
SOC, OT monitoring, and IR teams should validate visibility into industrial process history data, asset application logs, controller connection activity, and ICS protocol command functions. The analytic calls for monitoring events that correspond to command message functions, including setpoint changes, system status changes for key devices, discrete writes, logic and device configuration changes, mode changes, and unexpected command functions sent to controllers. It also highlights new or unexpected controller connections, including behavior similar to Rogue Master activity, and commands from existing master devices, new processes, or new devices such as a historian issuing command functions.
Likely telemetry
- Industrial process history data showing setpoint modifications and key device status changes
- Asset application logs showing operational command activity
- Controller connection records showing new or unexpected connections
- ICS protocol function-level telemetry for commands sent to controllers
- Source device and process context for master devices, new devices, or unexpected processes
Detection direction
- Validate that monitoring can see command functions, not only network sessions or device availability.
- Baseline expected controller command sources, including master devices, historians, engineering workstations, and other authorized systems where applicable.
- Tune alerts for unexpected command types, new controller connections, and commands from unusual devices or processes.
- Correlate process history changes with asset logs and controller communication evidence because the analytic may only provide supporting evidence, not direct detection of execution.
- Treat value-level monitoring as higher fidelity for malicious or unsafe activity, but expect more false positives because normal operational processes may generate unusual-looking values.
Mitigation priorities
- Establish and maintain an inventory of authorized controller command sources and expected command functions.
- Ensure process history, asset application logs, and ICS protocol telemetry are retained and usable for investigation.
- Define operational baselines for setpoints, device states, mode changes, and configuration changes in partnership with OT personnel.
- Prioritize alert triage playbooks for unexpected controller commands and new controller connections.
- Use change-management and authorization evidence to separate legitimate operational activity from suspicious command behavior.
Analyst notes and limits
The supplied ATT&CK object is an ICS detection analytic with no tactics, platforms, labels, aliases, relationships, or separate official detection field provided. The description emphasizes complementary evidence from process history, logs, controller connections, and ICS command-function visibility. It references Rogue Master only as related detection context for new or unexpected controller connections.
This take cannot assert specific platforms, attacker groups, active exploitation, or guaranteed detection coverage because those fields were not supplied. Local OT architecture, available telemetry, protocol visibility, and operational baselines are required to determine whether this analytic is feasible and how noisy it will be.
Analytic 1926
Monitor industrial process history data for events that correspond with command message functions, such as setpoint modification or changes to system status for key devices. 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. Monitor for anomalous or unexpected commands that may result in changes to the process operation (e.g., discrete write, logic and device configuration, mode changes) observable via asset application logs. Monitor for new or unexpected connections to controllers, which could indicate an Unauthorized Command Message being sent via Rogue Master. Monitor for anomalous or unexpected commands that may result in changes to the process operation (e.g., discrete write, logic and device configuration, mode changes) observable via asset application logs. Monitor for unexpected ICS protocol command functions to controllers from existing master devices (including from new processes) or from new devices. The latter is like detection for Rogue Master but requires ICS function level insight to determine if an unauthorized device is issuing commands (e.g., a historian).
Monitoring for unexpected or problematic values below the function level will provide better insights into potentially malicious activity but at the cost of additional false positives depending on the underlying operational process.
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 | 1fa353319010… |
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 AN1926Open 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.