DET0768: Detection of Detect Operating Mode
This detection strategy is about recognizing when someone is trying to determine the operating mode of a PLC or controller in an ICS environment. That matt...
Analyst context for executives and security teams
This detection strategy is about recognizing when someone is trying to determine the operating mode of a PLC or controller in an ICS environment. That matters because operating mode can determine whether a controller can be changed, maintained, or reprogrammed. For leaders, the practical question is whether the organization can see attempts to learn controller state before they become part of a larger operational technology incident.
Executive priority
Treat this as an ICS resilience and incident-readiness issue rather than a generic monitoring item. Security and operations leaders should confirm whether critical controllers have defensible visibility around mode-state queries or observations, especially where operating mode affects the ability to modify control logic. This can support risk discussions around change control, OT monitoring coverage, and evidence for cyber-physical security governance.
Technical view
ATT&CK provides this as detection strategy DET0768 for ICS technique T0868, Detect Operating Mode. The supplied object does not include an official detection method, platforms, or tactics, so SOC and OT defenders should validate coverage against the related behavior: attempts to gather a PLC or controller’s current operating mode, such as run, program, or remote, where those concepts apply. Detection engineering should be grounded in local controller models, vendor protocols, engineering workstation activity, and normal maintenance workflows rather than assuming a universal signal.
Likely telemetry
- OT network traffic involving PLCs/controllers and engineering workstations
- Controller or PLC diagnostic, status, or audit logs where available
- Engineering workstation activity and tool usage logs
- Change-management and maintenance-window records for expected controller interactions
- Asset inventory data identifying controller models and supported operating modes
Detection direction
- Baseline legitimate operating-mode checks by engineers, maintenance tools, and monitoring systems to reduce false positives.
- Look for unusual sources, timing, frequency, or sequences of controller status/mode queries relative to normal OT operations.
- Correlate suspected mode discovery with later attempts to change logic, configuration, or controller state where telemetry exists.
- Account for vendor and product-line differences; ATT&CK notes operating modes and selection mechanisms vary, so detections must be environment-specific.
- Identify blind spots where PLC/controller mode state is visible only locally, through proprietary tooling, or not logged centrally.
Mitigation priorities
- Maintain accurate inventories of PLCs/controllers, their operating modes, and authorized engineering access paths.
- Restrict and monitor engineering workstation and controller-management access according to operational need.
- Align detection logic with approved maintenance windows and change-control procedures.
- Ensure OT incident response playbooks include validation of controller operating mode and recent attempts to query or change it.
- Where feasible, centralize relevant OT network, controller, and engineering workstation evidence for SOC/IR review.
Analyst notes and limits
The source object is a detection strategy with no official description or detection text. The main usable context is its relationship to ICS technique T0868, Detect Operating Mode, which concerns adversaries gathering information about PLC/controller operating modes. Recommendations therefore focus on validation questions and telemetry classes rather than a specific detection analytic.
Platforms, tactics, aliases, labels, official description, and official detection content are not specified in the supplied ATT&CK fields. Local OT architecture, controller vendors, available logs, and maintenance practices are required to determine practical detection coverage.
Detection of Detect Operating Mode
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 | T0868 | Detect Operating Mode | This object detects Detect Operating Mode. |
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 | 534be85ff534… |
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 DET0768Open 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.