DET0787: Detection of Remote System Information Discovery
DET0787 is a detection strategy for spotting attempts to learn detailed information about remote ICS systems and peripherals, such as make/model, role, and...
Analyst context for executives and security teams
DET0787 is a detection strategy for spotting attempts to learn detailed information about remote ICS systems and peripherals, such as make/model, role, and configuration. For leaders, the value is early warning: this behavior can help an adversary decide which operational assets matter before taking follow-on actions.
Executive priority
Prioritize this as an OT visibility and readiness question rather than a standalone alerting problem. Executives should ask whether the organization can prove what remote system discovery looks like in its ICS environment, whether asset inventory is accurate enough to distinguish normal engineering activity from suspicious discovery, and whether SOC/IR teams have access to OT evidence during an incident.
Technical view
The supplied ATT&CK object has no official detection text, platforms, or tactics, but it detects T0888 Remote System Information Discovery. SOC and detection teams should validate whether they can observe remote attempts to collect system identity, role, peripheral, and configuration details, then compare that activity against expected engineering, maintenance, inventory, or monitoring behavior. Because the ATT&CK fields are sparse, local baselining is essential.
Likely telemetry
- OT/ICS network traffic and protocol metadata showing remote requests for device identity, role, model, peripheral, or configuration information
- Asset inventory or CMDB data for expected make/model, role, and configuration of remote systems
- Engineering workstation, maintenance, or remote access activity logs where available
- Network session metadata between management, engineering, monitoring, and remote ICS assets
- Change-management or maintenance-window records to contextualize legitimate discovery activity
Detection direction
- Validate that telemetry can distinguish routine asset inventory, engineering, and monitoring activity from unusual remote information discovery.
- Baseline which systems normally query device make/model, role, peripheral, and configuration details, and alert on new sources, unusual timing, or unexpected target scope.
- Correlate discovery-like activity with asset criticality because the related technique is useful for selecting operationally relevant targets.
- Tune for false positives from legitimate maintenance, commissioning, audits, and inventory scans.
- Document gaps where OT protocols, remote access paths, or unmanaged segments are not visible to the SOC.
Mitigation priorities
- Start with authoritative OT asset inventory so discovery activity can be judged against known systems and expected roles.
- Restrict and monitor remote access and engineering/management paths that can query system and configuration details.
- Segment or control access to operational assets so broad remote enumeration is not normal or easy.
- Align maintenance and inventory processes with logging expectations so defenders can separate approved discovery from suspicious behavior.
- Ensure incident response playbooks include steps to preserve OT network and remote access evidence related to discovery activity.
Analyst notes and limits
This take is based on DET0787 and its stated relationship to T0888 Remote System Information Discovery. The detection strategy object itself does not provide official detection logic, platforms, tactics, or a description, so implementation must be driven by local OT architecture, asset inventory, logging, and operational procedures.
No active exploitation, attribution, affected platforms, tactic mapping, or guaranteed detection coverage is provided in the supplied ATT&CK fields. Recommendations are defensive validation directions inferred from the related ATT&CK technique description and ICS domain context.
Detection of Remote System Information Discovery
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 | T0888 | Remote System Information Discovery | This object detects Remote System Information Discovery. |
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 | 16a252f7cec7… |
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 DET0787Open 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.