T0864: Transient Cyber Asset
Adversaries may target devices that are transient across ICS networks and external networks. Normally, transient assets are brought into an environment by authorized personnel and do not remain in that environment on a permanent basis. [1] Transient assets are commonly needed to support management functions and may be more common in systems where a remotely managed asset is not feasible, external connections for remote access do not exist, or 3rd party contractor/vendor access is required.
Adversaries may take advantage of transient assets in different ways. For instance, adversaries may target a transient asset when it is connected to an external network and then leverage its trusted access in another environment to launch an attack. They may also take advantage of installed applications and libraries that are used by legitimate end-users to interact with control system devices.
Transient assets, in some cases, may not be deployed with a secure configuration leading to weaknesses that could allow an adversary to propagate malicious executable code, e.g., the transient asset may be infected by malware and when connected to an ICS environment the malware propagates onto other systems.
Analyst context for executives and security teams
Transient cyber assets are temporary devices, such as engineering or maintenance workstations, that move between external networks and ICS environments. They matter because they can carry risk across trust boundaries: a device used legitimately by staff or vendors may be compromised elsewhere, misconfigured, or running software that can interact with control systems once connected.
Executive priority
Treat this as an operational resilience and third-party access governance issue, not only an endpoint issue. Leaders should ask whether temporary ICS-connected assets are inventoried, checked before connection, segmented from critical process control systems, and covered by audit evidence. The business risk is that trusted maintenance workflows can become a path into sensitive industrial environments, especially where remote management is not feasible or vendor access is required.
Technical view
ATT&CK provides no official detection text and no technique-level platforms or tactics, but the relationship context identifies a detection strategy, DET0744 Detection of Transient Cyber Asset, and a targeted ICS asset type of Workstation, described as commonly Linux or Windows. SOC and IR teams should validate how temporary laptops/workstations are identified when they enter ICS networks, whether their network paths are constrained, and whether changes to software, firmware, programs, permissions, and configurations are auditable before and after connection.
Likely telemetry
- Asset inventory and connection history for temporary or contractor devices entering ICS networks
- Network access logs showing transient asset connections to ICS segments, DMZs, workstations, control servers, or field-device management paths
- Endpoint security and malware detection events where safe and validated for non-real-time ICS-supporting assets
- Software, patch, insecure configuration, permission, and integrity-check audit results
- Records of approved vendor or maintenance activity tied to specific devices and time windows
Detection direction
- Use DET0744 as the ATT&CK-linked detection strategy reference, but validate locally because the object includes no official detection procedure.
- Tune detections around appearance of non-permanent assets in ICS network zones, unexpected communication from temporary devices, or access beyond required systems and services.
- Correlate transient asset activity with approved maintenance/vendor windows to reduce false positives while still identifying unscheduled or excessive access.
- Watch for blind spots where devices are trusted because they are authorized, but are not continuously managed, patched, scanned, or logged.
- Confirm visibility at segmentation boundaries; lack of logs between enterprise, external, DMZ, and process control networks can make this behavior difficult to prove or disprove.
Mitigation priorities
- Prioritize Network Segmentation (M0930): isolate critical systems and restrict transient asset access to only required systems and services.
- Use Audit (M0947) to scan for insecure software, permissions, configurations, and to perform integrity checks against known valid states after relevant events.
- Apply Update Software (M0951) with maintenance windows that respect operational downtime constraints.
- Use Antivirus/Antimalware (M0949) only where validated in a representative ICS test environment and limited to assets where availability and real-time operations will not be harmed.
- Encrypt Sensitive Information (M0941) for sensitive data at rest on transient assets where applicable.
Analyst notes and limits
The Maroochy Water Breach campaign relationship shows this technique has historical ICS relevance in ATT&CK, including stolen engineering equipment and wastewater control system disruption. Use this as context for scenario planning and tabletop exercises, not as evidence of current activity in any specific environment.
The ATT&CK object has no official detection text, no specified tactics, and no technique-level platforms. Platform detail is only present in the related Workstation asset description. Local architecture, vendor access processes, network segmentation design, and logging coverage are required to determine actual exposure and detection capability.
Transient Cyber Asset
Adversaries may target devices that are transient across ICS networks and external networks. Normally, transient assets are brought into an environment by authorized personnel and do not remain in that environment on a permanent basis. [1] Transient assets are commonly needed to support management functions and may be more common in systems where a remotely managed asset is not feasible, external connections for remote access do not exist, or 3rd party contractor/vendor access is required.
Adversaries may take advantage of transient assets in different ways. For instance, adversaries may target a transient asset when it is connected to an external network and then leverage its trusted access in another environment to launch an attack. They may also take advantage of installed applications and libraries that are used by legitimate end-users to interact with control system devices.
Transient assets, in some cases, may not be deployed with a secure configuration leading to weaknesses that could allow an adversary to propagate malicious executable code, e.g., the transient asset may be infected by malware and when connected to an ICS environment the malware propagates onto other systems.
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.
Groups, software, and campaigns
C0020: Maroochy Water Breach
Maroochy Water Breach was an incident in 2000 where an adversary leveraged the local government’s wastewater control system and stolen engineering equipment to disrupt and eventually release 800,000 liters of raw sewage into the local community.[1]
All related ATT&CK context
Mitigation direction
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.2 | Current bundle | 159a6cc3f492… |
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]
North American Electric Reliability Corporation June 2021
North American Electric Reliability Corporation 2021, June 28 Glossary of Terms Used in NERC Reliability Standards Retrieved. 2021/10/11
Open source URL -
[2]
mitre-attack T0864Open 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.