TA0100: Collection
The adversary is trying to gather data of interest and domain knowledge on your ICS environment to inform their goal.
Collection consists of techniques adversaries use to gather domain knowledge and obtain contextual feedback in an ICS environment. This tactic is often performed as part of Discovery, to compile data on control systems and targets of interest that may be used to follow through on the adversary’s objective. Examples of these techniques include observing operation states, capturing screenshots, identifying unique device roles, and gathering system and diagram schematics. Collection of this data can play a key role in planning, executing, and even revising an ICS-targeted attack. Methods of collection depend on the categories of data being targeted, which can include protocol specific, device specific, and process specific configurations and functionality. Information collected may pertain to a combination of system, supervisory, device, and network related data, which conceptually fall under high, medium, and low levels of plan operations. For example, information repositories on plant data at a high level or device specific programs at a low level. Sensitive floor plans, vendor device manuals, and other references may also be at risk and exposed on the internet or otherwise publicly accessible.
Analyst context for executives and security teams
In ICS environments, Collection is the point where an intruder tries to understand what matters: process states, device roles, diagrams, screenshots, configurations, manuals, and other context that can help shape an attack plan. For executives and security leaders, the risk is not just data loss; it is that operational knowledge can reduce an adversary’s uncertainty and make later actions against control systems more precise.
Executive priority
Treat ICS operational information as sensitive business and safety context, not just technical documentation. Leaders should ask whether plant diagrams, device manuals, supervisory screenshots, control logic references, and process documentation are inventoried, access-controlled, monitored, and included in incident response scoping. This tactic is material to resilience because collection can support planning, execution, and revision of an ICS-targeted attack, even when no immediate disruption has occurred.
Technical view
ATT&CK provides this as an ICS tactic, not a specific technique, and no official detection text or platform list is supplied. SOC, IR, and detection teams should validate whether they can see access to ICS repositories, engineering workstations, supervisory systems, file shares, diagram stores, screenshots, device-specific programs, protocol/device/process configuration data, and internet-exposed reference material. Investigation should connect collection activity with related Discovery behavior where local evidence supports that relationship.
Likely telemetry
- Access logs for document repositories, file shares, and systems storing plant data, schematics, manuals, floor plans, and control-system references
- Authentication and authorization records for users accessing ICS engineering, supervisory, device, and network-related information
- Endpoint and server audit logs showing file reads, copies, screenshots, archive creation, or unusual access to configuration and diagram files
- Network telemetry for access to ICS data stores, supervisory systems, engineering assets, or externally exposed documentation locations
- Asset and data inventories identifying where high-level plant data, medium-level supervisory data, and low-level device-specific programs or configurations reside
Detection direction
- Start by mapping where ICS domain knowledge is stored and which logs prove access to it; this tactic is difficult to assess if sensitive operational information is not inventoried.
- Baseline legitimate engineering, operations, and vendor access patterns so unusual collection of diagrams, screenshots, manuals, configurations, or device-role information can be reviewed without overwhelming analysts with normal maintenance activity.
- Correlate suspected collection with Discovery-like behavior, because the official description notes Collection is often performed as part of Discovery in ICS environments.
- Review exposure of sensitive references that may be internet-accessible or publicly reachable, since the official description explicitly notes that floor plans, vendor manuals, and related references may be at risk outside internal systems.
- Account for blind spots where OT repositories, engineering workstations, or supervisory systems are not centrally logged or are excluded from SOC monitoring.
Mitigation priorities
- Prioritize inventory and classification of ICS operational knowledge: schematics, floor plans, manuals, screenshots, device programs, configurations, and process documentation.
- Restrict access to sensitive ICS information by role and operational need, including engineering, vendor, and contractor access paths.
- Ensure logging and retention for systems that store or display control-system context so incident responders can determine what information may have been viewed or collected.
- Reduce unnecessary public or internet-accessible exposure of ICS references and documentation.
- Include collection of ICS domain knowledge in incident response playbooks, especially when assessing whether an event may enable later, more targeted operational actions.
Analyst notes and limits
This object is a tactic-level ICS ATT&CK entry. The supplied material emphasizes the defensive importance of knowing what operational data exists, where it is stored, who can access it, and whether access can be reconstructed during an investigation. Because no relationships were supplied, relationship-driven conclusions are limited to the official description’s statement that Collection is often performed as part of Discovery.
No official detection guidance, platforms, aliases, labels, or relationship context were supplied. This take should be validated against the local ICS architecture, logging coverage, data repositories, and operational access model before being used for detection engineering or control assurance.
Collection
The adversary is trying to gather data of interest and domain knowledge on your ICS environment to inform their goal.
Collection consists of techniques adversaries use to gather domain knowledge and obtain contextual feedback in an ICS environment. This tactic is often performed as part of Discovery, to compile data on control systems and targets of interest that may be used to follow through on the adversary’s objective. Examples of these techniques include observing operation states, capturing screenshots, identifying unique device roles, and gathering system and diagram schematics. Collection of this data can play a key role in planning, executing, and even revising an ICS-targeted attack. Methods of collection depend on the categories of data being targeted, which can include protocol specific, device specific, and process specific configurations and functionality. Information collected may pertain to a combination of system, supervisory, device, and network related data, which conceptually fall under high, medium, and low levels of plan operations. For example, information repositories on plant data at a high level or device specific programs at a low level. Sensitive floor plans, vendor device manuals, and other references may also be at risk and exposed on the internet or otherwise publicly accessible.
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 | 23b637ede85d… |
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 TA0100Open 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.