{ "id": "f94e441e-295a-4d77-a10a-2d49edd27ce5", "created_at": "2026-04-06T00:19:27.206214Z", "updated_at": "2026-04-10T03:30:33.859679Z", "deleted_at": null, "sha1_hash": "2238660253b9ed667f23fe5bda4e7ef5b77f6e7b", "title": "How Does Triton Attack Triconex Industrial Safety Systems?", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 314374, "plain_text": "How Does Triton Attack Triconex Industrial Safety Systems?\r\nBy IoT Security Research Lab\r\nPublished: 2021-02-23 · Archived: 2026-04-05 21:09:14 UTC\r\nTriton, also known as TRISIS or Hatman, is a piece of malware specially crafted to attack industrial safety\r\nsystems. In particular, Triton exploits vulnerabilities on the Triconex safety instrumented system from Schneider.\r\nDespite this system being deployed at more than 15,000 sites across the world, the malware allegedly only\r\ntargeted one critical energy industrial site in the Middle East in 2017.\r\nSafety instrumented systems (SIS) are used within industrial plants to monitor process values and parameters in\r\norder to assess whether the process remains within predefined operational limits. When the process drifts away\r\nfrom its safety limits, the SIS triggers alarms and performs actions to put the plant in a safe state. Thus, SIS such\r\nas Triconex play an important role in protecting a plant from accidents that might lead to significant\r\nenvironmental, health or economic damage.\r\nThe complexity of Triton, the nature of its target as well as its attack techniques and procedures have led many\r\nsecurity researchers to assess with some confidence that it is consistent with a nation state threat actor. As such,\r\nthe U.S. Department of Treasury, through sanctions announced by its Office of Foreign Assets Control, alleged\r\nthat this attack was supported by a Russian government research institution, namely the State Research Center of\r\nthe Russian Federation FGUP Central Scientific Research Institute of Chemistry and Mechanics (TsNIIKhM).\r\nThe Triton attack can be broken down into different phases:\r\n1. After gaining an initial access into the IT network, the malware attempted to move towards the OT network\r\nusing standard techniques (custom tools with functionalities close to those of Mimikatz or PSExec). As a\r\nresult, Triton managed to compromise an engineering station within the safety system. An example of an\r\nindustrial network architecture including safety systems is shown in the figure below.\r\n2. From the compromised station, Triton was able to launch a dropper (trilog.exe) with the aim of delivering\r\nbackdoor files to the PLC.\r\n3. The backdoor consists of two files. One file makes use of a 0-day exploit to inject the contents of the\r\nsecond file into the PLC’s memory. Subsequently, the attackers had total control of the target.\r\n4. In the final phase, the attackers’ aim was to take control and manipulate the device, leading to concrete\r\neffects on the safety systems of the physical installation. However, this phase did not take place and the\r\nassociated sources were not identified. A handling error in the target forced it into fail-mode which stopped\r\nthe plant’s production. The attack was identified following this shutdown.\r\nDropper\r\nhttps://blogs.cisco.com/security/how-does-triton-attack-triconex-industrial-safety-systems\r\nPage 1 of 4\n\nExample of an industrial network architecture. Although the safety systems are autonomous, they\r\nare often connected to Windows engineering stations for updates and maintenance.\r\nThe attackers first wrote the dropper as a Python script named script_test.py. Then, using the Py2Exe utility, the\r\nattackers compiled the script to an executable called trilog.exe . When compiling the dropper, the attackers used\r\nPy2Exe’s default settings. This enabled all of the files related to this implementation to be easily recovered.\r\nIn order to craft the dropper, the attackers reverse-engineered the proprietary TriStation Protocol used to program\r\nthe system. The first analysis, published in December 2017, identified Triconex MP3008 models with software\r\nversions between 10.0 and 10.4 as vulnerable.\r\nUsing this implementation, the dropper first connects to the target to transfer the malicious files that are used to\r\ncontrol the machine. The dropper then regularly scans the target to establish whether the injection is complete.\r\nHowever, at this stage, two significant weaknesses impact the attackers:\r\nThe Triconex machine only accepts program downloads when in “PROGRAM” mode whereas other modes\r\n(such as “RUN“) prevent it. These modes are changed manually using a physical key system.\r\nThe injected code is not persistent. For example, the code is deleted when downloading a new program\r\n(“DOWNLOAD ALL“).\r\nWhile network discovery options were present in the malware, the target’s IP address was hardcoded in the\r\nrecovered files. This reflects the attackers’ deep preliminary information gathering phase.\r\nhttps://blogs.cisco.com/security/how-does-triton-attack-triconex-industrial-safety-systems\r\nPage 2 of 4\n\nGeneral operation of the Triton attack. (source CISA ICS-Cert)\r\nBackdoor\r\nThe backdoor comprises an injector and an implant. First, the injector (a program that aims to inject a payload)\r\nchecks whether the controller is vulnerable to the exploit. If the tests are conclusive, the exploit is used to raise\r\nprivileges. These new permissions enable the content of the implant to be written in the system memory area. This\r\nmemory area is not wiped when downloading new programs. Moreover, since safety systems are critical\r\ncomponents, they are almost never restarted. Therefore, the risk of the implant being deleted is low.\r\nOnce this payload is in memory, the original program is patched to include a conditional break to the address of\r\nthe payload. A RAM integrity verification feature is also patched to avoid detection.\r\nThe implant allows specific commands to be listened to and processed without any restriction with respect to the\r\noperating mode (which can be changed using the physical key mechanism). More precisely, it analyzes the\r\nmessages that are usually used for debugging processes (GetMPStatus messages) and executes the expected\r\ncommand (read, write, or execute). This communication allows, for example, the memory of the machine to be\r\nmodified even if it is in a mode that prevents the standard download of a program (“RUN” mode).\r\n0-day exploit\r\nThe injector used a vulnerable system call to obtain a 2-bytes arbitrary write ability which it then used to increase\r\nits privileges. During a system call, when switching from USER mode to SUPERVISOR mode, registers are saved\r\nto a known memory area. One of these registers, MSR, contains a bit which indicates the privilege level. Using the\r\nhttps://blogs.cisco.com/security/how-does-triton-attack-triconex-industrial-safety-systems\r\nPage 3 of 4\n\nvulnerable system call, it is possible to overwrite this bit, thus giving supervisor privileges to the user once the\r\nsystem call ends and the registers are reloaded from the memory.\r\nRedundancy functions\r\nAmong the files discovered during the first analysis, the file CRC.pyc implemented some cyclical redundancy\r\ncontrol functions. The use of such functions is normal and is found in many protocols. This does not necessarily\r\nmean, however, that all protocols use the same function.\r\nVarious functions related to different protocols (such as Modbus or XMODEM) were identified when analyzing\r\nthe file. While not every single function was useful during the attack, this implies that the attackers could target\r\nother types of machines or industrial systems.\r\nDetection of the attack\r\nAt this stage, the attackers were in a position to control the target remotely, regardless of its mode of operation.\r\nHowever, before any potential physical consequences were observed, the system went into a safe mode (failed\r\nsafe state). This behavior resulted in a shutdown of the production line and the discovery of the attack. The\r\nultimate aim of the attackers has not been identified.\r\nThe triggering of this safe mode was probably linked to a handling error in the machine. This might occur, for\r\ninstance, when writing in the incorrect memory area. Various analyses have shown that the attackers had difficulty\r\nimplementing and handling the TriStation protocol and the associated features.\r\nDetection measures\r\nTo detect the behavior of the malware, Cisco Talos published Snort rules#45260, #45477 and #45478) that can be\r\nactivated in a next generation firewall, such as Cisco Firepower firewalls and, in particular the ISA 3000 Industrial\r\nSecurity Appliance.\r\nHowever, these rules might fail to detect another Triconex attack as the attackers would probably not use the exact\r\nsame components. Therefore, it is necessary to analyze the UDP communications on port 1502. Various industrial\r\nsecurity products such as Cisco Cyber Vision can analyze the communications over the Triconex protocol to detect\r\nanomalies and to identify potential attacks.\r\nVisit our IoT Security Research Lab for\r\nmore technical reports on IoT/OT Security\r\nSubscribe to the Cisco IoT Security Newsletter.\r\nSource: https://blogs.cisco.com/security/how-does-triton-attack-triconex-industrial-safety-systems\r\nhttps://blogs.cisco.com/security/how-does-triton-attack-triconex-industrial-safety-systems\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA" ], "references": [ "https://blogs.cisco.com/security/how-does-triton-attack-triconex-industrial-safety-systems" ], "report_names": [ "how-does-triton-attack-triconex-industrial-safety-systems" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null }, { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null }, { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434767, "ts_updated_at": 1775791833, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/2238660253b9ed667f23fe5bda4e7ef5b77f6e7b.pdf", "text": "https://archive.orkl.eu/2238660253b9ed667f23fe5bda4e7ef5b77f6e7b.txt", "img": "https://archive.orkl.eu/2238660253b9ed667f23fe5bda4e7ef5b77f6e7b.jpg" } }