DET0739: Detection of Remote System Discovery
DET0739 is a detection strategy for identifying Remote System Discovery in ICS environments: attempts to list or identify other systems by IP address, host...
Analyst context for executives and security teams
DET0739 is a detection strategy for identifying Remote System Discovery in ICS environments: attempts to list or identify other systems by IP address, hostname, or other logical identifier. For leaders, the practical issue is that discovery is often a precursor to lateral movement and broader operational visibility by an adversary. Even without platform-specific guidance in the ATT&CK object, this behavior matters because weak visibility into asset enumeration can leave SOC and incident response teams late to understand scope, containment needs, and potential operational risk.
Executive priority
Prioritize confirming whether security teams can see and investigate system-enumeration activity across ICS-connected networks. The business question is not only “can we detect scans,” but “can we distinguish authorized engineering, asset management, and vendor activity from suspicious discovery that could precede lateral movement.” This supports operational resilience, incident decision-making, and compliance evidence around monitoring of critical environments.
Technical view
This detection strategy is related to ATT&CK for ICS technique T0846, Remote System Discovery. The supplied object does not specify platforms, tactics, or official detection logic, so validation should be environment-driven. SOC and IR teams should map normal sources of host, IP, and network inventory activity in ICS networks, then test whether telemetry can identify unusual enumeration patterns, unexpected hosts performing discovery, or discovery occurring outside approved maintenance or engineering workflows. Because legitimate operating system utilities, vendor software, or adversary tooling may be involved, detection should focus on context, source, destination, frequency, timing, and authorization rather than a single tool name.
Likely telemetry
- Network flow records showing source and destination IPs, ports, protocols, timing, and connection volume
- DNS, hostname lookup, or name-resolution logs where available
- Asset inventory and network discovery tool logs for authorized baseline activity
- Firewall, router, switch, or segmentation control logs showing cross-zone connection attempts
- Endpoint or server logs from systems that can record discovery commands or administrative utility use, where present
Detection direction
- Build a baseline of approved discovery behavior, including engineering workstations, asset management systems, vendor tools, and scheduled scans.
- Tune for unexpected systems initiating broad host, IP, or hostname enumeration, especially across ICS network segments or trust boundaries.
- Correlate discovery activity with subsequent lateral movement or additional discovery behaviors, since T0846 is described as enabling later activity.
- Avoid relying only on signature-style detection for known tools; the related technique notes that operating system utilities, vendor software, or adversary tools could be used.
- Account for false positives from legitimate maintenance, commissioning, vulnerability assessment, inventory collection, and vendor support.
Mitigation priorities
- Define and document authorized discovery sources, schedules, and maintenance windows for ICS-connected environments.
- Limit and monitor which systems can enumerate or communicate broadly across ICS network segments.
- Use segmentation and access controls to reduce unnecessary host-to-host visibility where operationally feasible.
- Ensure asset inventory, change management, and vendor access processes provide context to the SOC for triage.
- Create incident response playbooks for unexpected discovery in ICS networks, including operational escalation paths before containment actions that could affect production or safety.
Analyst notes and limits
The ATT&CK object is a detection strategy with no official description or detection text provided. The most useful context comes from its relationship to T0846 Remote System Discovery in the ICS domain, which describes adversaries attempting to list other systems by IP address, hostname, or logical identifier for possible subsequent lateral movement or discovery. Local baselines and architecture are essential because the same behavior may be normal during engineering, inventory, or vendor maintenance activities.
Platforms, tactics, labels, aliases, official description, and official detection content are not specified in the supplied object. This take does not assert active exploitation, actor attribution, affected products, guaranteed detection, or specific tool coverage. Recommendations are generalized from the supplied relationship to T0846 and require validation against the organization’s ICS architecture and telemetry.
Detection of Remote System 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 | T0846 | Remote System Discovery | This object detects Remote System 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 | bdc099cbdd64… |
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 DET0739Open 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.