TA0102: Discovery
The adversary is locating information to assess and identify their targets in your environment.
Discovery consists of techniques that adversaries use to survey your ICS environment and gain knowledge about the internal network, control system devices, and how their processes interact. These techniques help adversaries observe the environment and determine next steps for target selection and Lateral Movement. They also allow adversaries to explore what they can control and gain insight on interactions between various control system processes. Discovery techniques are often an act of progression into the environment which enable the adversary to orient themselves before deciding how to act. Adversaries may use Discovery techniques that result in Collection, to help determine how available resources benefit their current objective. A combination of native device communications and functions, and custom tools are often used toward this post-compromise information-gathering objective.
Analyst context for executives and security teams
Discovery in ICS matters because it is how an intruder learns what control-system assets exist, how processes interact, and where to move next. For executives and security leaders, the issue is not just visibility into scans or queries; it is whether the organization can recognize post-compromise orientation activity before it turns into lateral movement, collection, or actions affecting operations.
Executive priority
Treat this as an operational resilience and incident-decision priority for ICS environments. Leaders should ask whether security and operations teams have a current understanding of normal control-system communications, device relationships, and process dependencies, because that baseline is what makes suspicious discovery behavior actionable. It also supports audit evidence, response scoping, and cyber-physical risk discussions without assuming a specific adversary or platform.
Technical view
SOC, detection, and IR teams should validate whether they can observe information-gathering behavior inside ICS networks, including attempts to learn about internal networks, control-system devices, and interactions between processes. Because ATT&CK provides no specific detection text or platform list for this tactic, coverage should be assessed against local architecture, known native device communications, available control-system logs, and network telemetry. Discovery should be triaged in context with possible progression toward target selection, lateral movement, or collection, as described by the tactic.
Likely telemetry
- ICS network traffic and session metadata between control-system segments and devices
- Control-system device communication records where available
- Engineering workstation, operator workstation, or control-system application logs where available
- Asset inventory and configuration-management records used to compare expected versus observed device relationships
- Alerts or logs from passive monitoring tools that understand normal ICS communications
Detection direction
- Establish or validate baselines for normal ICS device communications and process interactions before relying on anomaly detection.
- Tune for unusual attempts to enumerate internal networks, control-system devices, or process relationships, while accounting for legitimate engineering, maintenance, and operations activity.
- Review whether native device functions and communications are monitored, since the ATT&CK description notes adversaries may use native communications as well as custom tools.
- Correlate discovery-like activity with signs of collection or lateral movement rather than treating it as isolated noise.
- Document blind spots caused by unavailable control-system logs, limited east-west network visibility, unmanaged assets, or incomplete asset inventories.
Mitigation priorities
- Prioritize accurate ICS asset, communication, and process-dependency inventories so abnormal discovery has context.
- Segment and restrict unnecessary internal visibility between ICS zones and devices where operationally feasible.
- Limit access to control-system information and native functions to authorized roles and workflows.
- Maintain logging and monitoring for critical ICS communications and operator or engineering activity where supported by the environment.
- Include discovery-oriented scenarios in incident response playbooks so teams can quickly determine scope, affected assets, and operational risk.
Analyst notes and limits
This object is an ICS ATT&CK tactic, not a specific technique. The supplied description frames Discovery as post-compromise information gathering that helps adversaries understand internal networks, control-system devices, and process interactions, and may support target selection, lateral movement, or collection. No platform, tactic mapping beyond the object itself, detection text, aliases, labels, or relationship context was supplied.
This take is limited to the official ATT&CK fields provided for TA0102. It does not identify specific tools, procedures, platforms, adversaries, or active exploitation. Detection and mitigation recommendations require validation against the organization’s actual ICS architecture, telemetry availability, operating model, and safety constraints.
Discovery
The adversary is locating information to assess and identify their targets in your environment.
Discovery consists of techniques that adversaries use to survey your ICS environment and gain knowledge about the internal network, control system devices, and how their processes interact. These techniques help adversaries observe the environment and determine next steps for target selection and Lateral Movement. They also allow adversaries to explore what they can control and gain insight on interactions between various control system processes. Discovery techniques are often an act of progression into the environment which enable the adversary to orient themselves before deciding how to act. Adversaries may use Discovery techniques that result in Collection, to help determine how available resources benefit their current objective. A combination of native device communications and functions, and custom tools are often used toward this post-compromise information-gathering objective.
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 | 39f11cc48e32… |
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 TA0102Open 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.