{
	"id": "6a766f42-f478-4f04-89f5-83e097bad965",
	"created_at": "2026-04-06T02:13:21.488105Z",
	"updated_at": "2026-04-10T13:12:33.794233Z",
	"deleted_at": null,
	"sha1_hash": "eb3de87c3b9cf0554f402ad5204af3775dc5d05b",
	"title": "A Totally Tubular Treatise on TRITON and TriStation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2968364,
	"plain_text": "A Totally Tubular Treatise on TRITON and TriStation\r\nBy by Steve Miller, Evan Reese\r\nPublished: 2018-06-07 · Archived: 2026-04-06 01:52:28 UTC\r\nThreat Research\r\nJune 07, 2018 |\r\nIntroduction\r\nIn December 2017, FireEye's Mandiant discussed an incident response involving the TRITON framework. The\r\nTRITON attack and many of the publicly discussed ICS intrusions involved routine techniques where the threat\r\nactors used only what is necessary to succeed in their mission. For both INDUSTROYER and TRITON, the\r\nattackers moved from the IT network to the OT (operational technology) network through systems that were\r\naccessible to both environments. Traditional malware backdoors, Mimikatz distillates, remote desktop sessions,\r\nand other well-documented, easily-detected attack methods were used throughout these intrusions.\r\nDespite the routine techniques employed to gain access to an OT environment, the threat actors behind the\r\nTRITON malware framework invested significant time learning about the Triconex Safety Instrumented System\r\n(SIS) controllers and TriStation, a proprietary network communications protocol. The investment and purpose of\r\nthe Triconex SIS controllers leads Mandiant to assess the attacker's objective was likely to build the capability to\r\ncause physical consequences.\r\nTriStation remains closed source and there is no official public information detailing the structure of the protocol,\r\nraising several questions about how the TRITON framework was developed. Did the actor have access to a\r\nTriconex controller and TriStation 1131 software suite? When did development first start? How did the threat\r\nactor reverse engineer the protocol, and to what extent? What is the protocol structure?\r\nFireEye’s Advanced Practices Team was born to investigate adversary methodologies, and to answer these types\r\nof questions, so we started with a deeper look at the TRITON’s own Python scripts.\r\nGlossary:\r\nTRITON – Malware framework designed to operate Triconex SIS controllers via the TriStation protocol.\r\nTriStation – UDP network protocol specific to Triconex controllers.\r\nTRITON threat actor – The human beings who developed, deployed and/or operated TRITON.\r\nDiving into TRITON's Implementation of TriStation\r\nTriStation is a proprietary network protocol and there is no public documentation detailing its structure or how to\r\ncreate software applications that use TriStation. The current TriStation UDP/IP protocol is little understood, but\r\nnatively implemented through the TriStation 1131 software suite. TriStation operates by UDP over port 1502 and\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 1 of 31\n\nallows for communications between designated masters (PCs with the software that are “engineering\r\nworkstations”) and slaves (Triconex controllers with special communications modules) over a network.\r\nTo us, the Triconex systems, software and associated terminology sound foreign and complicated, and the\r\nTriStation protocol is no different. Attempting to understand the protocol from ground zero would take a\r\nconsiderable amount of time and reverse engineering effort – so why not learn from TRITON itself? With the\r\nTRITON framework containing TriStation communication functionality, we pursued studying the framework to\r\nbetter understand this mysterious protocol. Work smarter, not harder, amirite?\r\nThe TRITON framework has a multitude of functionalities, but we started with the basic components:\r\nTS_cnames.pyc # Compiled at: 2017-08-03 10:52:33\r\nTsBase.pyc # Compiled at: 2017-08-03 10:52:33\r\nTsHi.pyc # Compiled at: 2017-08-04 02:04:01\r\nTsLow.pyc # Compiled at: 2017-08-03 10:46:51\r\nTsLow.pyc (Figure 1) contains several pieces of code for error handling, but these also present some cues to the\r\nprotocol structure.\r\nFigure 1: TsLow.pyc function print_last_error()\r\nIn the TsLow.pyc’s function for print_last_error we see error handling for “TCM Error”. This compares the\r\nTriStation packet value at offset 0 with a value in a corresponding array from TS_cnames.pyc (Figure 2), which is\r\nlargely used as a “dictionary” for the protocol.\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 2 of 31\n\nFigure 2: TS_cnames.pyc TS_cst array\r\nFrom this we can infer that offset 0 of the TriStation protocol contains message types. This is supported by an\r\nadditional function, tcm_result, which declares type, size = struct.unpack('\u003cHH', data_received[0:4]), stating that\r\nthe first two bytes should be handled as integer type and the second two bytes are integer size of the TriStation\r\nmessage. This is our first glimpse into what the threat actor(s) understood about the TriStation protocol.\r\nSince there are only 11 defined message types, it really doesn't matter much if the type is one byte or two because\r\nthe second byte will always be 0x00.\r\nWe also have indications that message type 5 is for all Execution Command Requests and Responses, so it is\r\ncurious to observe that the TRITON developers called this “Command Reply.” (We won’t understand this naming\r\nconvention until later.)\r\nNext we examine TsLow.pyc’s print_last_error function (Figure 3) to look at “TS Error” and “TS_names.” We\r\nbegin by looking at the ts_err variable and see that it references ts_result.\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 3 of 31\n\nFigure 3: TsLow.pyc function print_last_error() with ts_err highlighted\r\nWe follow that thread to ts_result, which defines a few variables in the next 10 bytes (Figure 4): dir, cid, cmd, cnt,\r\nunk, cks, siz = struct.unpack('\u003c, ts_packet[0:10]). Now things are heating up. What fun. There’s a lot to unpack\r\nhere, but the most interesting thing is how this piece script breaks down 10 bytes from ts_packet into different\r\nvariables.\r\nFigure 4: ts_result with ts_packet header variables highlighted\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 4 of 31\n\nFigure 5: tcm_result\r\nReferencing tcm_result (Figure 5) we see that it defines type and size as the first four bytes (offset 0 – 3) and\r\ntcm_result returns the packet bytes 4:-2 (offset 4 to the end minus 2, because the last two bytes are the CRC-16\r\nchecksum). Now that we know where tcm_result leaves off, we know that the ts_reply “cmd” is a single byte at\r\noffset 6, and corresponds to the values in the TS_cnames.pyc array and TS_names (Figure 6). The TRITON script\r\nalso tells us that any integer value over 100 is a likely “command reply.” Sweet.\r\nWhen looking back at the ts_result packet header definitions, we begin to see some gaps in the TRITON\r\ndeveloper's knowledge: dir, cid, cmd, cnt, unk, cks, siz = struct.unpack('\u003c, ts_packet[0:10]). We're clearly\r\nspeculating based on naming conventions, but we get an impression that offsets 4, 5 and 6 could be \"direction\",\r\n\"controller ID\" and \"command\", respectively. Values such as \"unk\" show that the developer either did not know or\r\ndid not care to identify this value. We suspect it is a constant, but this value is still unknown to us.\r\nFigure 6: Excerpt TS_cnames.pyc TS_names array, which contain TRITON actor’s notes for execution command\r\nfunction codes\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 5 of 31\n\nTriStation Protocol Packet Structure\r\nThe TRITON threat actor’s knowledge and reverse engineering effort provides us a better understanding of the\r\nprotocol. From here we can start to form a more complete picture and document the basic functionality of\r\nTriStation. We are primarily interested in message type 5, Execution Command, which best illustrates the overall\r\nstructure of the protocol. Other, smaller message types will have varying structure.\r\nFigure 7: Sample TriStation \"Allocate Program\" Execution Command, with color annotation and protocol legend\r\nCorroborating the TriStation Analysis\r\nMinute discrepancies aside, the TriStation structure detailed in Figure 7 is supported by other public analyses.\r\nForemost, researchers from the Coordinated Science Laboratory (CSL) at University of Illinois at Urbana-Champaign published a 2017 paper titled \"Attack Induced Common-Mode Failures on PLC-based Safety System\r\nin a Nuclear Power Plant\". The CSL team mentions that they used the Triconex System Access Application\r\n(TSAA) protocol to reverse engineer elements of the TriStation protocol. TSAA is a protocol developed by the\r\nsame company as TriStation. Unlike TriStation, the TSAA protocol structure is described within official\r\ndocumentation. CSL assessed similarities between the two protocols would exist and they leveraged TSAA to\r\nbetter understand TriStation. The team's overall research and analysis of the general packet structure aligns with\r\nour TRITON-sourced packet structure.\r\nThere are some awesome blog posts and whitepapers out there that support our findings in one way or another.\r\nWriteups by Midnight Blue Labs, Accenture, and US-CERT each explain how the TRITON framework relates to\r\nthe TriStation protocol in superb detail.\r\nTriStation's Reverse Engineering and TRITON's Development\r\nWhen TRITON was discovered, we began to wonder how the TRITON actor reverse engineered TriStation and\r\nimplemented it into the framework. We have a lot of theories, all of which seemed plausible: Did they build, buy,\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 6 of 31\n\nborrow, or steal? Or some combination thereof?\r\nOur initial theory was that the threat actor purchased a Triconex controller and software for their own testing and\r\nreverse engineering from the \"ground up\", although if this was the case we do not believe they had a controller\r\nwith the exact vulnerable firmware version, else they would have had fewer problems with TRITON in practice at\r\nthe victim site. They may have bought or used a demo version of the TriStation 1131 software, allowing them to\r\nreverse engineer enough of TriStation for the framework. They may have stolen TriStation Python libraries from\r\nICS companies, subsidiaries or system integrators and used the stolen material as a base for TriStation and\r\nTRITON development. But then again, it is possible that they borrowed TriStation software, Triconex hardware\r\nand Python connectors from government-owned utility that was using them legitimately.\r\nLooking at the raw TRITON code, some of the comments may appear oddly phrased, but we do get a sense that\r\nthe developer is clearly using many of the right vernacular and acronyms, showing smarts on PLC programming.\r\nThe TS_cnames.pyc script contains interesting typos such as 'Set lable', 'Alocate network accepted', 'Symbol table\r\nccepted' and 'Set program information reponse'. These appear to be normal human error and reflect neither poor\r\nwritten English nor laziness in coding. The significant amount of annotation, cascading logic, and robust error\r\nhandling throughout the code suggests thoughtful development and testing of the framework. This complicates the\r\ntheory of \"ground up\" development, so did they base their code on something else?\r\nWhile learning from the TriStation functionality within TRITON, we continued to explore legitimate TriStation\r\nsoftware. We began our search for \"TS1131.exe\" and hit dead ends sorting through TriStation DLLs until we came\r\nacross a variety of TriStation utilities in MSI form. We ultimately stumbled across a juicy archive containing\r\n\"Trilog v4.\" Upon further inspection, this file installed \"TriLog.exe,\" which the original TRITON executable\r\nmimicked, and a couple of supporting DLLs, all of which were timestamped around August 2006.\r\nWhen we saw the DLL file description \"Tricon Communications Interface\" and original file name\r\n\"TricCom.DLL\", we knew we were in the right place. With a simple look at the file strings, \"BAZINGA!\" We\r\nstruck gold.\r\nFile Name tr1com40.dll\r\nMD5 069247DF527A96A0E048732CA57E7D3D\r\nSize 110592\r\nCompile Date 2006-08-23\r\nFile Description Tricon Communications Interface\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 7 of 31\n\nProduct Name TricCom Dynamic Link Library\r\nFile Version 4.2.441\r\nOriginal File Name TricCom.DLL\r\nCopyright Copyright © 1993-2006 Triconex Corporation\r\nThe tr1com40.DLL is exactly what you would expect to see in a custom application package. It is a library that\r\nhelps support the communications for a Triconex controller. If you've pored over TRITON as much as we have,\r\nthe moment you look at strings you can see the obvious overlaps between the legitimate DLL and TRITON's own\r\nTS_cnames.pyc.\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 8 of 31\n\nFigure 8: Strings excerpt from tr1com40.DLL\r\nEach of the execution command \"error codes\" from TS_cnames.pyc are in the strings of tr1com40.DLL (Figure\r\n8). We see \"An MP has re-educated\" and \"Invalid Tristation I command\". Even misspelled command strings\r\nverbatim such as \"Non-existant data item\" and \"Alocate network accepted\". We also see many of the same\r\nunknown values. What is obvious from this discovery is that some of the strings in TRITON are likely based on\r\ncode used in communications libraries for Trident and Tricon controllers.\r\nIn our brief survey of the legitimate Triconex Corporation binaries, we observed a few samples with related string\r\ntables.\r\nPe:dllname\r\nCompile\r\nDate\r\nReference CPP Strings Code\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 9 of 31\n\nLagcom40.dll 2004/11/19\r\n$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $\r\n$Revision:   1.0\r\nTr1com40.dll 2006/08/23\r\n$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $\r\n$Revision:   1.4\r\nTridcom.dll 2008/07/23\r\n$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $\r\n$Revision:   1.0\r\nTriccom.dll 2008/07/23\r\n$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $\r\n$Revision:   1.4\r\nTridcom.dll 2010/09/29\r\n$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $\r\n$Revision:   1.0 \r\nTr1com.dll 2011/04/27\r\n$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $\r\n$Revision:   1.4\r\nLagcom.dll 2011/04/27\r\n$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $\r\n$Revision:   1.0\r\nTriccom.dll 2011/04/27\r\n$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $\r\n$Revision:   1.4\r\nWe extracted the CPP string tables in TR1STRS and LAGSTRS and the TS_cnames.pyc TS_names array from\r\nTRITON, and compared the 210, 204, and 212 relevant strings from each respective file.\r\nTS_cnames.pyc TS_names and tr1com40.dll share 202 of 220 combined table strings. The remaining strings are\r\nunique to each, as seen here:\r\nTS_cnames.TS_names (2017 pyc) Tr1com40.dll (2006 CPP)\r\nGo to DOWNLOAD mode \u003c200\u003e\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 10 of 31\n\nNot set \u003c209\u003e\r\nUnk75 Bad message from module\r\nUnk76 Bad message type\r\nUnk77 Bad TMI version number\r\nUnk78 Module did not respond\r\nUnk79 Open Connection: Invalid SAP %d\r\nUnk81 Unsupported message for this TMI version\r\nUnk83\r\nWrong command\r\nTS_cnames.pyc TS_names and Tridcom.dll (1999 CPP) shared only 151 of 268 combined table strings, showing a\r\nmuch smaller overlap with the seemingly older CPP library. This makes sense based on the context that\r\nTridcom.dll is meant for a Trident controller, not a Tricon controller. It does seem as though Tr1com40.dll and\r\nTR1STRS.CPP code was based on older work.\r\nWe are not shocked to find that the threat actor reversed legitimate code to bolster development of the TRITON\r\nframework. They want to work smarter, not harder, too. But after reverse engineering legitimate software and\r\nimplementing the basics of the TriStation, the threat actors still had an incomplete understanding of the protocol.\r\nIn TRITON's TS_cnames.pyc we saw \"Unk75\", \"Unk76\", \"Unk83\" and other values that were not present in the\r\ntr1com40.DLL strings, indicating that the TRITON threat actor may have explored the protocol and annotated\r\ntheir findings beyond what they reverse engineered from the DLL. The gaps in TriStation implementation show us\r\nwhy the actors encountered problems interacting with the Triconex controllers when using TRITON in the wild.\r\nYou can see more of the Trilog and Triconex DLL files on VirusTotal.\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 11 of 31\n\nItem Name MD5 Description\r\nTr1com40.dll 069247df527a96a0e048732ca57e7d3d Tricom Communcations DLL\r\nData1.cab e6a3c93a6d433cbaf6f573b6c09d76c4 Parent of Tr1com40.dll\r\nTrilog v4.1.360R 13a3b83ba2c4236ca59aba679941c8a5 RAR Archive of TriLog\r\nTridCom.dll 5c2ed617fdec4779cb33c89082a43100 Trident Communications DLL\r\nAfterthoughts\r\nSeeing Triconex systems targeted with malicious intent was new to the world six months ago. Moving forward it\r\nwould be reasonable to anticipate additional frameworks, such as TRITON, designed for usage against other SIS\r\ncontrollers and associated technologies. If Triconex was within scope, we may see similar attacker methodologies\r\naffecting the dominant industrial safety technologies.\r\nBasic security measures do little to thwart truly persistent threat actors and monitoring only IT networks is not an\r\nideal situation. Visibility into both the IT and OT environments is critical for detecting the various stages of an\r\nICS intrusion. Simple detection concepts such as baseline deviation can provide insight into abnormal activity.\r\nWhile the TRITON framework was actively in use, how many traditional ICS “alarms” were set off while the\r\nactors tested their exploits and backdoors on the Triconex controller? How many times did the TriStation protocol,\r\nas implemented in their Python scripts, fail or cause errors because of non-standard traffic? How many TriStation\r\nUDP pings were sent and how many Connection Requests? How did these statistics compare to the baseline for\r\nTriStation traffic? There are no answers to these questions for now. We believe that we can identify these\r\nanomalies in the long run if we strive for increased visibility into ICS technologies.\r\nWe hope that by holding public discussions about ICS technologies, the Infosec community can cultivate closer\r\nrelationships with ICS vendors and give the world better insight into how attackers move from the IT to the OT\r\nspace. We want to foster more conversations like this and generally share good techniques for finding evil. Since\r\nmost of all ICS attacks involve standard IT intrusions, we should probably come together to invent and improve\r\nany guidelines for how to monitor PCs and engineering workstations that bridge the IT and OT networks. We\r\nenvision a world where attacking or disrupting ICS operations costs the threat actor their cover, their toolkits, their\r\ntime, and their freedom. It's an ideal world, but something nice to shoot for.\r\nThanks and Future Work\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 12 of 31\n\nThere is still much to do for TRITON and TriStation. There are many more sub-message types and nuances for\r\nparsing out the nitty gritty details, which is hard to do without a controller of our own. And although we’ve\r\npublished much of what we learned about the TriStation here on the blog, our work will continue as we continue\r\nour study of the protocol.\r\nThanks to everyone who did so much public research on TRITON and TriStation. We have cited a few individuals\r\nin this blog post, but there is a lot more community-sourced information that gave us clues and leads for our\r\nresearch and testing of the framework and protocol. We also have to acknowledge the research performed by the\r\nTRITON attackers. We borrowed a lot of your knowledge about TriStation from the TRITON framework itself.\r\nFinally, remember that we're here to collaborate. We think most of our research is right, but if you notice any\r\nerrors or omissions, or have ideas for improvements, please spear phish contact: smiller@fireeye.com.\r\nRecommended Reading\r\nAttackers Deploy New ICS Attack Framework “TRITON” and Cause Operational Disruption to Critical\r\nInfrastructure\r\nAttack Induced Common-Mode Failures on PLC-Based Safety System in a Nuclear Power Plant: Practical\r\nExperience Report\r\nAnalyzing the TRITON industrial malware\r\nRepository containting original and decompiled files of TRISIS/TRITON/HATMAN malware\r\nTRISIS Malware Analysis of Safety System Targeted Malware\r\nAppendix A: TriStation Message Type Codes\r\nThe following table consists of hex values at offset 0 in the TriStation UDP packets and the associated dictionary\r\ndefinitions, extracted verbatim from the TRITON framework in library TS_cnames.pyc.\r\nValue at 0x0 Message Type\r\n1 Connection Request\r\n2 Connection Response\r\n3 Disconnect Request\r\n4 Disconnect Response\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 13 of 31\n\n5 Execution Command\r\n6 Ping Command\r\n7 Connection Limit Reached\r\n8 Not Connected\r\n9 MPS Are Dead\r\n10 Access Denied\r\n11 Connection Failed\r\nAppendix B: TriStation Execution Command Function Codes\r\nThe following table consists of hex values at offset 6 in the TriStation UDP packets and the associated dictionary\r\ndefinitions, extracted verbatim from the TRITON framework in library TS_cnames.pyc.\r\nValue at 0x6 TS_cnames String\r\n0 0: 'Start download all',\r\n1 1: 'Start download change',\r\n2 2: 'Update configuration',\r\n3 3: 'Upload configuration',\r\n4 4: 'Set I/O addresses',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 14 of 31\n\n5 5: 'Allocate network',\r\n6 6: 'Load vector table',\r\n7 7: 'Set calendar',\r\n8 8: 'Get calendar',\r\n9 9: 'Set scan time',\r\nA 10: 'End download all',\r\nB 11: 'End download change',\r\nC 12: 'Cancel download change',\r\nD 13: 'Attach TRICON',\r\nE 14: 'Set I/O address limits',\r\nF 15: 'Configure module',\r\n10 16: 'Set multiple point values',\r\n11 17: 'Enable all points',\r\n12 18: 'Upload vector table',\r\n13 19: 'Get CP status ',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 15 of 31\n\n14 20: 'Run program',\r\n15 21: 'Halt program',\r\n16 22: 'Pause program',\r\n17 23: 'Do single scan',\r\n18 24: 'Get chassis status',\r\n19 25: 'Get minimum scan time',\r\n1A 26: 'Set node number',\r\n1B 27: 'Set I/O point values',\r\n1C 28: 'Get I/O point values',\r\n1D 29: 'Get MP status',\r\n1E 30: 'Set retentive values',\r\n1F 31: 'Adjust clock calendar',\r\n20 32: 'Clear module alarms',\r\n21 33: 'Get event log',\r\n22 34: 'Set SOE block',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 16 of 31\n\n23 35: 'Record event log',\r\n24 36: 'Get SOE data',\r\n25 37: 'Enable OVD',\r\n26 38: 'Disable OVD',\r\n27 39: 'Enable all OVDs',\r\n28 40: 'Disable all OVDs',\r\n29 41: 'Process MODBUS',\r\n2A 42: 'Upload network',\r\n2B 43: 'Set lable',\r\n2C 44: 'Configure system variables',\r\n2D 45: 'Deconfigure module',\r\n2E 46: 'Get system variables',\r\n2F 47: 'Get module types',\r\n30 48: 'Begin conversion table download',\r\n31 49: 'Continue conversion table download',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 17 of 31\n\n32 50: 'End conversion table download',\r\n33 51: 'Get conversion table',\r\n34 52: 'Set ICM status',\r\n35 53: 'Broadcast SOE data available',\r\n36 54: 'Get module versions',\r\n37 55: 'Allocate program',\r\n38 56: 'Allocate function',\r\n39 57: 'Clear retentives',\r\n3A 58: 'Set initial values',\r\n3B 59: 'Start TS2 program download',\r\n3C 60: 'Set TS2 data area',\r\n3D 61: 'Get TS2 data',\r\n3E 62: 'Set TS2 data',\r\n3F 63: 'Set program information',\r\n40 64: 'Get program information',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 18 of 31\n\n41 65: 'Upload program',\r\n42 66: 'Upload function',\r\n43 67: 'Get point groups',\r\n44 68: 'Allocate symbol table',\r\n45 69: 'Get I/O address',\r\n46 70: 'Resend I/O address',\r\n47 71: 'Get program timing',\r\n48 72: 'Allocate multiple functions',\r\n49 73: 'Get node number',\r\n4A 74: 'Get symbol table',\r\n4B 75: 'Unk75',\r\n4C 76: 'Unk76',\r\n4D 77: 'Unk77',\r\n4E 78: 'Unk78',\r\n4F 79: 'Unk79',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 19 of 31\n\n50 80: 'Go to DOWNLOAD mode',\r\n51 81: 'Unk81',\r\n52  \r\n53 83: 'Unk83',\r\n54  \r\n55  \r\n56  \r\n57  \r\n58  \r\n59  \r\n5A  \r\n5B  \r\n5C  \r\n5D  \r\n5E  \r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 20 of 31\n\n5F  \r\n60  \r\n61  \r\n62  \r\n63  \r\n64 100: 'Command rejected',\r\n65 101: 'Download all permitted',\r\n66 102: 'Download change permitted',\r\n67 103: 'Modification accepted',\r\n68 104: 'Download cancelled',\r\n69 105: 'Program accepted',\r\n6A 106: 'TRICON attached',\r\n6B 107: 'I/O addresses set',\r\n6C 108: 'Get CP status response',\r\n6D 109: 'Program is running',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 21 of 31\n\n6E 110: 'Program is halted',\r\n6F 111: 'Program is paused',\r\n70 112: 'End of single scan',\r\n71 113: 'Get chassis configuration response',\r\n72 114: 'Scan period modified',\r\n73 115: '\u003c115\u003e',\r\n74 116: '\u003c116\u003e',\r\n75 117: 'Module configured',\r\n76 118: '\u003c118\u003e',\r\n77 119: 'Get chassis status response',\r\n78 120: 'Vectors response',\r\n79 121: 'Get I/O point values response',\r\n7A 122: 'Calendar changed',\r\n7B 123: 'Configuration updated',\r\n7C 124: 'Get minimum scan time response',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 22 of 31\n\n7D 125: '\u003c125\u003e',\r\n7E 126: 'Node number set',\r\n7F 127: 'Get MP status response',\r\n80 128: 'Retentive values set',\r\n81 129: 'SOE block set',\r\n82 130: 'Module alarms cleared',\r\n83 131: 'Get event log response',\r\n84 132: 'Symbol table ccepted',\r\n85 133: 'OVD enable accepted',\r\n86 134: 'OVD disable accepted',\r\n87 135: 'Record event log response',\r\n88 136: 'Upload network response',\r\n89 137: 'Get SOE data response',\r\n8A 138: 'Alocate network accepted',\r\n8B 139: 'Load vector table accepted',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 23 of 31\n\n8C 140: 'Get calendar response',\r\n8D 141: 'Label set',\r\n8E 142: 'Get module types response',\r\n8F 143: 'System variables configured',\r\n90 144: 'Module deconfigured',\r\n91 145: '\u003c145\u003e',\r\n92 146: '\u003c146\u003e',\r\n93 147: 'Get conversion table response',\r\n94 148: 'ICM print data sent',\r\n95 149: 'Set ICM status response',\r\n96 150: 'Get system variables response',\r\n97 151: 'Get module versions response',\r\n98 152: 'Process MODBUS response',\r\n99 153: 'Allocate program response',\r\n9A 154: 'Allocate function response',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 24 of 31\n\n9B 155: 'Clear retentives response',\r\n9C 156: 'Set initial values response',\r\n9D 157: 'Set TS2 data area response',\r\n9E 158: 'Get TS2 data response',\r\n9F 159: 'Set TS2 data response',\r\nA0 160: 'Set program information reponse',\r\nA1 161: 'Get program information response',\r\nA2 162: 'Upload program response',\r\nA3 163: 'Upload function response',\r\nA4 164: 'Get point groups response',\r\nA5 165: 'Allocate symbol table response',\r\nA6 166: 'Program timing response',\r\nA7 167: 'Disable points full',\r\nA8 168: 'Allocate multiple functions response',\r\nA9 169: 'Get node number response',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 25 of 31\n\nAA 170: 'Symbol table response',\r\nAB  \r\nAC  \r\nAD  \r\nAE  \r\nAF  \r\nB0  \r\nB1  \r\nB2  \r\nB3  \r\nB4  \r\nB5  \r\nB6  \r\nB7  \r\nB8  \r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 26 of 31\n\nB9  \r\nBA  \r\nBB  \r\nBC  \r\nBD  \r\nBE  \r\nBF  \r\nC0  \r\nC1  \r\nC2  \r\nC3  \r\nC4  \r\nC5  \r\nC6  \r\nC7  \r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 27 of 31\n\nC8 200: 'Wrong command',\r\nC9 201: 'Load is in progress',\r\nCA 202: 'Bad clock calendar data',\r\nCB 203: 'Control program not halted',\r\nCC 204: 'Control program checksum error',\r\nCD 205: 'No memory available',\r\nCE 206: 'Control program not valid',\r\nCF 207: 'Not loading a control program',\r\nD0 208: 'Network is out of range',\r\nD1 209: 'Not enough arguments',\r\nD2 210: 'A Network is missing',\r\nD3 211: 'The download time mismatches',\r\nD4 212: 'Key setting prohibits this operation',\r\nD5 213: 'Bad control program version',\r\nD6 214: 'Command not in correct sequence',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 28 of 31\n\nD7 215: '\u003c215\u003e',\r\nD8 216: 'Bad Index for a module',\r\nD9 217: 'Module address is invalid',\r\nDA 218: '\u003c218\u003e',\r\nDB 219: '\u003c219\u003e',\r\nDC 220: 'Bad offset for an I/O point',\r\nDD 221: 'Invalid point type',\r\nDE 222: 'Invalid Point Location',\r\nDF 223: 'Program name is invalid',\r\nE0 224: '\u003c224\u003e',\r\nE1 225: '\u003c225\u003e',\r\nE2 226: '\u003c226\u003e',\r\nE3 227: 'Invalid module type',\r\nE4 228: '\u003c228\u003e',\r\nE5 229: 'Invalid table type',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 29 of 31\n\nE6 230: '\u003c230\u003e',\r\nE7 231: 'Invalid network continuation',\r\nE8 232: 'Invalid scan time',\r\nE9 233: 'Load is busy',\r\nEA 234: 'An MP has re-educated',\r\nEB 235: 'Invalid chassis or slot',\r\nEC 236: 'Invalid SOE number',\r\nED 237: 'Invalid SOE type',\r\nEE 238: 'Invalid SOE state',\r\nEF 239: 'The variable is write protected',\r\nF0 240: 'Node number mismatch',\r\nF1 241: 'Command not allowed',\r\nF2 242: 'Invalid sequence number',\r\nF3 243: 'Time change on non-master TRICON',\r\nF4 244: 'No free Tristation ports',\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 30 of 31\n\nF5 245: 'Invalid Tristation I command',\r\nF6 246: 'Invalid TriStation 1131 command',\r\nF7 247: 'Only one chassis allowed',\r\nF8 248: 'Bad variable address',\r\nF9 249: 'Response overflow',\r\nFA 250: 'Invalid bus',\r\nFB 251: 'Disable is not allowed',\r\nFC 252: 'Invalid length',\r\nFD 253: 'Point cannot be disabled',\r\nFE 254: 'Too many retentive variables',\r\nFF 255: 'LOADER_CONNECT',\r\n  256: 'Unknown reject code'\r\nSource: https://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html\r\nPage 31 of 31\n\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html  \n32 50: 'End conversion table download',\n33 51: 'Get conversion table',\n34 52: 'Set ICM status',\n35 53: 'Broadcast SOE data available',\n36 54: 'Get module versions',\n37 55: 'Allocate program',\n38 56: 'Allocate function',\n39 57: 'Clear retentives', \n3A 58: 'Set initial values',\n3B 59: 'Start TS2 program download',\n3C 60: 'Set TS2 data area',\n3D 61: 'Get TS2 data',\n3E 62: 'Set TS2 data',\n3F 63: 'Set program information',\n40 64: 'Get program information',\n  Page 18 of 31\n\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html  \n5F  \n60  \n61  \n62  \n63  \n64 100: 'Command rejected',\n65 101: 'Download all permitted',\n66 102: 'Download change permitted',\n67 103: 'Modification accepted',\n68 104: 'Download cancelled',\n69 105: 'Program accepted',\n6A 106: 'TRICON attached',\n6B 107: 'I/O addresses set',\n6C 108: 'Get CP status response',\n6D 109: 'Program is running',\n  Page 21 of 31\n\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html  \n7D 125: '\u003c125\u003e', \n7E 126: 'Node number set',\n7F 127: 'Get MP status response',\n80 128: 'Retentive values set',\n81 129: 'SOE block set',\n82 130: 'Module alarms cleared',\n83 131: 'Get event log response',\n84 132: 'Symbol table ccepted',\n85 133: 'OVD enable accepted',\n86 134: 'OVD disable accepted',\n87 135: 'Record event log response',\n88 136: 'Upload network response',\n89 137: 'Get SOE data response',\n8A 138: 'Alocate network accepted',\n8B 139: 'Load vector table accepted',\n  Page 23 of 31\n\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html  \n8C 140: 'Get calendar response',\n8D 141: 'Label set', \n8E 142: 'Get module types response',\n8F 143: 'System variables configured',\n90 144: 'Module deconfigured',\n91 145: '\u003c145\u003e', \n92 146: '\u003c146\u003e', \n93 147: 'Get conversion table response',\n94 148: 'ICM print data sent',\n95 149: 'Set ICM status response',\n96 150: 'Get system variables response',\n97 151: 'Get module versions response',\n98 152: 'Process MODBUS response',\n99 153: 'Allocate program response',\n9A 154: 'Allocate function response',\n  Page 24 of 31\n\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html  \n9B 155: 'Clear retentives response',\n9C 156: 'Set initial values response',\n9D 157: 'Set TS2 data area response',\n9E 158: 'Get TS2 data response',\n9F 159: 'Set TS2 data response',\nA0 160: 'Set program information reponse',\nA1 161: 'Get program information response',\nA2 162: 'Upload program response',\nA3 163: 'Upload function response',\nA4 164: 'Get point groups response',\nA5 165: 'Allocate symbol table response',\nA6 166: 'Program timing response',\nA7 167: 'Disable points full',\nA8 168: 'Allocate multiple functions response',\nA9 169: 'Get node number response',\n  Page 25 of 31\n\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html   \nC8 200: 'Wrong command', \nC9 201: 'Load is in progress', \nCA 202: 'Bad clock calendar data',\nCB 203: 'Control program not halted',\nCC 204: 'Control program checksum error',\nCD 205: 'No memory available', \nCE 206: 'Control program not valid',\nCF 207: 'Not loading a control program',\nD0 208: 'Network is out of range',\nD1 209: 'Not enough arguments', \nD2 210: 'A Network is missing', \nD3 211: 'The download time mismatches',\nD4 212: 'Key setting prohibits this operation',\nD5 213: 'Bad control program version',\nD6 214: 'Command not in correct sequence',\n  Page 28 of 31\n\nhttps://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html  \nD7 215: '\u003c215\u003e', \nD8 216: 'Bad Index for a module',\nD9 217: 'Module address is invalid',\nDA 218: '\u003c218\u003e', \nDB 219: '\u003c219\u003e', \nDC 220: 'Bad offset for an I/O point',\nDD 221: 'Invalid point type',\nDE 222: 'Invalid Point Location',\nDF 223: 'Program name is invalid',\nE0 224: '\u003c224\u003e', \nE1 225: '\u003c225\u003e', \nE2 226: '\u003c226\u003e', \nE3 227: 'Invalid module type',\nE4 228: '\u003c228\u003e', \nE5 229: 'Invalid table type',\n  Page 29 of 31",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://web.archive.org/web/20200618231942/https://www.fireeye.com/blog/threat-research/2018/06/totally-tubular-treatise-on-triton-and-tristation.html"
	],
	"report_names": [
		"totally-tubular-treatise-on-triton-and-tristation.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775441601,
	"ts_updated_at": 1775826753,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/eb3de87c3b9cf0554f402ad5204af3775dc5d05b.pdf",
		"text": "https://archive.orkl.eu/eb3de87c3b9cf0554f402ad5204af3775dc5d05b.txt",
		"img": "https://archive.orkl.eu/eb3de87c3b9cf0554f402ad5204af3775dc5d05b.jpg"
	}
}