C0030: Triton Safety Instrumented System Attack
Triton Safety Instrumented System Attack was a campaign employed by TEMP.Veles which leveraged the Triton malware framework against a petrochemical organization.[1] The malware and techniques used within this campaign targeted specific Triconex Safety Controllers within the environment.[2] The incident was eventually discovered due to a safety trip that occurred as a result of an issue in the malware.[3]
Analyst context for executives and security teams
The Triton Safety Instrumented System Attack matters because it shows a campaign aimed not just at enterprise IT, but at industrial safety systems that exist to keep physical processes safe. In the supplied ATT&CK description, TEMP.Veles used the Triton malware framework against a petrochemical organization and targeted Triconex Safety Controllers; discovery occurred after a safety trip caused by a malware issue. For executives, the decision value is that cyber risk, plant safety, operational continuity, and incident response readiness can converge in one event.
Executive priority
Prioritize this as a cyber-physical resilience scenario, not only a malware scenario. Leaders should ask whether safety instrumented systems, engineering workstations, remote services, credentials, and IT/OT boundaries are governed, monitored, and included in incident response exercises. The campaign’s relationships include credential dumping with Mimikatz, LSASS memory access, valid accounts, remote services, lateral tool transfer, command-line and scripting activity, program append to PLCs, unauthorized command messages, and loss of productivity and revenue. Those relationships make this useful for board-level questions about plant shutdown readiness, audit evidence for privileged access and segmentation controls, and whether SOC and OT teams can jointly investigate activity before a process disruption becomes the first alert.
Technical view
SOC, detection engineering, and IR teams should validate coverage across the enterprise-to-ICS path reflected in the ATT&CK relationships. On the enterprise side, confirm visibility for Windows credential access involving LSASS memory, Mimikatz-like tooling, PowerShell, scheduled tasks, suspicious tool staging, remote service use, encrypted command-and-control patterns, and attempts to remove or rename indicators. On the ICS side, validate whether engineering workstations, vendor-specific programming environments, SIS controller communications, command messages, and program append events are logged and reviewable. Because ATT&CK provides no official detection text for this campaign and no campaign-level platforms or tactics, local architecture, asset inventory, and OT telemetry determine whether meaningful detection is possible.
Likely telemetry
- Windows endpoint telemetry for LSASS access, credential dumping indicators, PowerShell execution, scheduled task creation, file placement, and tool execution
- Authentication and privileged account logs for valid account use across IT and OT systems
- Remote service logs and network flow records for RDP, SMB, SSH, or similar internal movement paths where present
- File transfer and staging evidence across internal systems, including engineering workstations
- Network telemetry between enterprise systems, OT segments, engineering workstations, and SIS-related assets
Detection direction
- Do not rely on a single malware signature. Tune for the chain of behaviors in the relationships: credential access, valid account use, remote services, tool transfer, scripting, scheduled execution, stealth, and ICS command/program changes.
- Baseline authorized engineering activity and controller change windows so that program append activity, command messages, and vendor-tool use outside expected context can be reviewed quickly.
- Correlate IT identity events with OT access. A valid account used from an unusual host or followed by remote services and engineering workstation access is more decision-relevant than any one event alone.
- Treat safety trips and unexpected process disruptions as potential cyber investigation triggers when correlated with controller or engineering workstation activity, while recognizing that process faults can have non-cyber causes.
- Validate whether encrypted channels, renamed tools, and indicator removal would be visible in existing endpoint and network telemetry.
Mitigation priorities
- Start with asset and dependency mapping for SIS controllers, engineering workstations, remote access paths, and accounts that can affect safety systems.
- Restrict and monitor privileged and service accounts used across IT and OT environments; include controls that reduce credential exposure on Windows systems.
- Segment enterprise, OT, and SIS-related networks and tightly govern remote services that bridge them.
- Control engineering workstation access and require formal change management for controller programming, program append actions, and command message activity.
- Ensure backups, recovery procedures, and incident playbooks include cyber-physical decision points such as safe shutdown, safety trip investigation, and coordination between SOC, IR, engineering, and operations.
Analyst notes and limits
The object is a campaign, not a single technique. Its value for defenders comes from the related software, group, and techniques: TEMP.Veles attribution, Triton targeting Triconex SIS controllers, Mimikatz, LSASS memory access, valid accounts, remote services, scripting, PowerShell, scheduled tasks, tool transfer, stealth behaviors, program append, command messages, adversary-in-the-middle, and potential productivity/revenue loss. The supplied campaign record is in the enterprise ATT&CK domain, while many relationships are ICS ATT&CK, so defenders should treat it as a cross-domain IT/OT case study.
ATT&CK provides no official detection text for this campaign, and the campaign-level platforms and tactics are not specified. The supplied fields support the historical campaign context, related group, software, and techniques, but they do not prove current activity, customer exposure, or guaranteed detection opportunities. Local network design, safety system architecture, logging depth, and change-management records are required to turn this into environment-specific coverage.
Triton Safety Instrumented System Attack
Triton Safety Instrumented System Attack was a campaign employed by TEMP.Veles which leveraged the Triton malware framework against a petrochemical organization.[1] The malware and techniques used within this campaign targeted specific Triconex Safety Controllers within the environment.[2] The incident was eventually discovered due to a safety trip that occurred as a result of an issue in the malware.[3]
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 |
|---|---|---|---|
| Enterprise | T1588.002 | Tool Sub-technique | In the Triton Safety Instrumented System Attack, TEMP.Veles used tools such as Mimikatz and other open-source software.CitationFireEye TEMP.Veles 2018 |
| Enterprise | T1036.005 | Match Legitimate Resource Name or Location Sub-technique | In the Triton Safety Instrumented System Attack, TEMP.Veles renamed files to look like legitimate files, such as Windows update files or Schneider Electric application files. |
| Enterprise | T1053.005 | Scheduled Task Sub-technique | In the Triton Safety Instrumented System Attack, TEMP.Veles installed scheduled tasks defined in XML files.CitationFireEye TEMP.Veles 2018 |
| Enterprise | T1003.001 | LSASS Memory Sub-technique | In the Triton Safety Instrumented System Attack, TEMP.Veles used Mimikatz.CitationFireEye TRITON 2018 |
| Enterprise | T1587.001 | Malware Sub-technique | In the Triton Safety Instrumented System Attack, TEMP.Veles developed, prior to the attack, malware capabilities that would require access to specific and specialized hardware and software.CitationFireEye TRITON Dec 2017 |
| Enterprise | T1056.003 | Web Portal Capture Sub-technique | In the Triton Safety Instrumented System Attack, TEMP.Veles captured credentials as they were being changed by redirecting text-based login codes to websites they controlled.CitationTriton-EENews-2017 |
| Enterprise | T1059.001 | PowerShell Sub-technique | In the Triton Safety Instrumented System Attack, TEMP.Veles used a publicly available PowerShell-based tool, WMImplant.CitationFireEye TEMP.Veles 2018 |
| Enterprise | T1027.005 | Indicator Removal from Tools Sub-technique | In the Triton Safety Instrumented System Attack, TEMP.Veles modified files based on the open-source project cryptcat in an apparent attempt to decrease anti-virus detection rates.CitationFireEye TEMP.Veles 2018 |
| Enterprise | T1573 | Encrypted Channel | In the Triton Safety Instrumented System Attack, TEMP.Veles used cryptcat binaries to encrypt their traffic.CitationFireEye TEMP.Veles 2018 |
| Enterprise | T1595 | Active Scanning | In the Triton Safety Instrumented System Attack, TEMP.Veles engaged in network reconnaissance against targets of interest.CitationFireEye TEMP.Veles 2018 |
Groups, software, and campaigns
G0088: TEMP.Veles
TEMP.Veles is a Russia-based threat group that has targeted critical infrastructure. The group has been observed utilizing TRITON, a malware framework designed to manipulate industrial safety systems.[1][2][3]
S0002: Mimikatz
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.1 | Current bundle | ed4747709bd6… |
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]
Triton-EENews-2017
Blake Sobczak. (2019, March 7). The inside story of the world’s most dangerous malware. Retrieved March 25, 2024.
Open source URL -
[2]
FireEye TRITON 2018
Miller, S. Reese, E. (2018, June 7). A Totally Tubular Treatise on TRITON and TriStation. Retrieved November 17, 2024.
Open source URL -
[3]
FireEye TRITON 2017
Johnson, B, et. al. (2017, December 14). Attackers Deploy New ICS Attack Framework "TRITON" and Cause Operational Disruption to Critical Infrastructure. Retrieved January 6, 2021.
Open source URL -
[4]
mitre-attack C0030Open 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.