S1009: Triton
Analyst context for executives and security teams
Triton matters because it is an ICS malware framework built to interact with Triconex Safety Instrumented System controllers. For leadership, the key issue is not ordinary IT compromise; it is the possibility of adversary activity against safety functions that help keep industrial processes in a safe state. Any organization operating or depending on Triconex SIS environments should treat this as a resilience, safety, incident response, and governance concern, not only a malware-detection problem.
Executive priority
Prioritize validation of safety-system segmentation, engineering-workstation control, change-management evidence, and incident procedures for SIS environments. The ATT&CK relationships tie Triton to program upload/download, controller tasking changes, operating-mode discovery/change, API-based execution, masquerading, indicator removal, firmware-related behavior, and Loss of Safety. Executives should ask whether the organization can prove who can reach SIS controllers, who can modify logic or operating modes, and whether anomalous safety-controller interactions would be noticed quickly enough to support safe operational decisions.
Technical view
SOC, OT security, and IR teams should build coverage around the behaviors linked to Triton rather than relying on a single malware signature. Validate monitoring for engineering workstation activity, controller communications, broadcast discovery, standard application-layer protocol use, commonly used ports, API interactions with control hardware, program upload/download events, operating-mode reads or changes, controller tasking changes, firmware-related operations, suspicious scripting, masqueraded vendor-like files, and attempts to remove host indicators. Because ATT&CK provides no official detection text and no platform list for this object, local asset inventories, Triconex SIS architecture, vendor logs, network captures, and engineering-tool records are essential to decide what is observable.
Likely telemetry
- SIS controller and engineering workstation communication records
- OT network traffic involving broadcast discovery, standard application-layer protocols, and commonly used ports
- Engineering software logs or project/change records showing program upload, program download, online edit, or tasking changes
- Controller operating-mode status and mode-change evidence where available
- Host telemetry from engineering workstations for scripting, masqueraded files, API/native API use, hooking, and indicator removal activity
Detection direction
- Map detection logic to the related ATT&CK techniques: T0843 Program Download, T0845 Program Upload, T0858 Change Operating Mode, T0868 Detect Operating Mode, T0821 Modify Controller Tasking, T0871 Execution through API, T0834 Native API, T0846.002 Broadcast Discovery, T0869 Standard Application Layer Protocol, T0885 Commonly Used Port, T0872 Indicator Removal on Host, T0849 Masquerading, T0853 Scripting, T0874 Hooking, T0820/T0890 exploitation behaviors, T1693.001 System Firmware, and T0880 Loss of Safety.
- Baseline legitimate SIS engineering activity so alerts can distinguish approved maintenance from unusual controller access, downloads, uploads, or mode changes.
- Treat false positives carefully: engineering changes and vendor maintenance can look similar to suspicious behavior, so detections should include change-ticket, time-window, user, workstation, and asset-context correlation.
- Check blind spots in OT environments: unmanaged engineering laptops, limited controller logging, uninspected east-west OT traffic, shared credentials, and lack of archived controller project baselines can materially reduce confidence.
- Use campaign and group relationship context only as prioritization input: ATT&CK links Triton to the Triton Safety Instrumented System Attack campaign and TEMP.Veles, but local detections should still focus on observable behavior.
Mitigation priorities
- First, confirm asset inventory and network paths for Triconex SIS controllers, engineering workstations, jump hosts, and any systems able to perform controller programming or mode changes.
- Restrict and monitor access to SIS engineering functions, especially program download/upload, controller tasking changes, operating-mode changes, API access, and firmware update workflows.
- Strengthen OT change management: require approval, logging, and independent review for safety-controller logic, firmware, and engineering-project changes.
- Segment safety systems from broader IT and OT networks and validate that only necessary systems and protocols can communicate with SIS controllers.
- Prepare IR and operations playbooks that include safe decision-making with engineering and process-safety personnel when SIS integrity is in question.
Analyst notes and limits
The supplied ATT&CK object identifies Triton as an attack framework for Triconex SIS controllers and provides relationships to many ICS techniques plus a campaign and group context. The most useful defensive approach is behavior- and environment-based validation around SIS access, controller modification, operating-mode activity, and safety-function integrity. This take intentionally avoids claiming current activity or guaranteed detection coverage.
Official detection is not provided, platforms and tactics are not specified, and the object does not include environment-specific observables. Organizations must confirm available telemetry, controller models, engineering workflows, vendor logging, and network architecture before judging coverage or risk.
Triton
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 | T0834 | Native API | Triton's imain.bin payload takes commands from the TsHi.ExplReadRam(Ex), TsHi.ExplWriteRam(Ex) and TsHi.ExplExec functions to perform operations on controller memory and registers using syscalls written in PowerPC shellcode. CitationJos Wetzels January 2018 |
| ICS | T0843 | Program Download | Triton leveraged the TriStation protocol to download programs onto Triconex Safety Instrumented System.CitationJos Wetzels January 2018 |
| ICS | T0849 | Masquerading | |
| ICS | T0846.002 | Broadcast Discovery Sub-technique | Triton uses a Python script that is capable of detecting Triconex controllers on the network by sending a specific UDP broadcast packet over port 1502. CitationDHS CISA February 2019 |
| ICS | T0872 | Indicator Removal on Host | Triton would reset the controller to the previous state over TriStation and if this failed it would write a dummy program to memory in what was likely an attempt at anti-forensics. CitationJos Wetzels January 2018 |
| ICS | T0890 | Exploitation for Privilege Escalation | Triton leverages a previously-unknown vulnerability affecting Tricon MP3008 firmware versions 10.010.4 allows an insecurely-written system call to be exploited to achieve an arbitrary 2-byte write primitive, which is then used to gain supervisor privileges. CitationDHS CISA February 2019 |
| ICS | T0821 | Modify Controller Tasking | Triton's argument-setting and inject.bin shellcode are added to the program table on the Tricon so that they are executed by the firmware once each cycle. CitationDHS CISA February 2019 CitationJos Wetzels January 2018 |
| ICS | T0853 | Scripting | Triton communicates with Triconex controllers using a custom component framework written entirely in Python. The modules that implement the TriStation communication protocol and other supporting components are found in a separate file -- library.zip -- the main script that employs this functionality is compiled into a standalone py2exe Windows executable -- trilog.exe which includes a Python environment. CitationDHS CISA February 2019 |
| ICS | T0858 | Change Operating Mode | Triton has the ability to halt or run a program through the TriStation protocol. TsHi.py contains instances of halt and run functions being executed.CitationMDudek-ICS |
| ICS | T0885 | Commonly Used Port | Triton uses TriStations default UDP port, 1502, to communicate with devices.CitationMDudek-ICS |
| ICS | T0868 | Detect Operating Mode | Triton contains a file named TS_cnames.py which contains default definitions for program state (TS_progstate). Program state is referenced in TsHi.py.CitationMDudek-ICS Triton contains a file named TS_cnames.py which contains default definitions for key state (TS_keystate). Key state is referenced in TsHi.py.CitationMDudek-ICS |
| ICS | T0845 | Program Upload | Triton calls the SafeAppendProgramMod to transfer its payloads to the Tricon. Part of this call includes preforming a program upload. CitationMDudek-ICS |
| ICS | T0874 | Hooking | Triton's injector, inject.bin, changes the function pointer of the 'get main processor diagnostic data' TriStation command to the address of imain.bin so that it is executed prior to the normal handler. CitationJos Wetzels January 2018 |
| ICS | T0871 | Execution through API | Triton leverages a reconstructed TriStation protocol within its framework to trigger APIs related to program download, program allocation, and program changes. CitationJos Wetzels January 2018 |
| ICS | T0880 | Loss of Safety | Triton has the capability to reprogram the SIS logic to allow unsafe conditions to persist or reprogram the SIS to allow an unsafe state while using the DCS to create an unsafe state or hazard. CitationBlake Johnson, Dan Caban, Marina Krotofil, Dan Scali, Nathan Brubaker, Christopher Glyer December 2017 |
| ICS | T0820 | Exploitation for Evasion | Triton disables a firmware RAM/ROM consistency check after injects a payload (imain.bin) into the firmware memory region. CitationDHS CISA February 2019 CitationICS-CERT December 2018 CitationSchneider Electric January 2018 Triconex systems include continuous means of detection including checksums for firmware and program integrity, memory and memory reference integrity, and configuration. CitationThe Office of Nuclear Reactor Regulation |
| ICS | T0869 | Standard Application Layer Protocol | Triton can communicate with the implant utilizing the TriStation 'get main processor diagnostic data' command and looks for a specifically crafted packet body from which it extracts a command value and its arguments. CitationJos Wetzels January 2018 |
| ICS | T1693.001 | System Firmware Sub-technique | Triton is able to read, write and execute code in memory on the safety controller at an arbitrary address within the devices firmware region. This allows the malware to make changes to the running firmware in memory and modify how the device operates. CitationDHS CISA February 2019 |
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]
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]
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.2 | Current bundle | dd619d0ad952… |
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]
Blake Johnson, Dan Caban, Marina Krotofil, Dan Scali, Nathan Brubaker, Christopher Glyer December 2017
Blake Johnson, Dan Caban, Marina Krotofil, Dan Scali, Nathan Brubaker, Christopher Glyer 2017, December 14 Attackers Deploy New ICS Attack Framework TRITON and Cause Operational Disruption to Critical Infrastructure Retrieved. 2018/01/12
Open source URL -
[2]
Dragos December 2017
Dragos 2017, December 13 TRISIS Malware Analysis of Safety System Targeted Malware Retrieved. 2018/01/12
Open source URL -
[3]
DHS CISA February 2019
DHS CISA 2019, February 27 MAR-17-352-01 HatManSafety System Targeted Malware (Update B) Retrieved. 2019/03/08
Open source URL -
[4]
Schneider Electric January 2018
Schneider Electric 2018, January 23 TRITON - Schneider Electric Analysis and Disclosure Retrieved. 2019/03/14
Open source URL -
[5]
Julian Gutmanis March 2019
Julian Gutmanis 2019, March 11 Triton - A Report From The Trenches Retrieved. 2019/03/11
Open source URL -
[6]
Schneider December 2018
Schneider 2018, December 14 Security Notification EcoStruxure Triconex Tricon V3 Retrieved. 2019/03/08
Open source URL -
[7]
Jos Wetzels January 2018
Jos Wetzels 2018, January 16 Analyzing the TRITON industrial malware Retrieved. 2019/10/22
Open source URL -
[8]
mitre-attack S1009Open 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.