一、简介
2017年12月，FireEye的Mandiant讨论了有关TRITON框架的事件响应。TRITON攻击和许多公开的ICS入侵一样涉及常规技术，威胁攻击者只使用必要的技术来完成任务。对于INDUSTROYER和TRITON来说，攻击者都从IT网络转移到OT（运营技术）网络，缘于这两个环境中的系统均可访问。传统的恶意软件后门，Mimikatz，远程桌面会话以及其他记录完好、易于检测到的攻击方法在这些入侵中都被使用过。
尽管采用了常规技术来访问OT环境，但TRITON恶意软件框架背后的威胁攻击者投入了大量时间学习了Triconex安全仪表系统（SIS）控制器和专有网络通信协议TriStation。在Triconex SIS控制器的投入，使得Mandiant评估攻击者很可能具备造成物理损害的能力。
TriStation目前仍然是封源的，没有官方的公开信息详细说明协议的结构，只提供了几个有关TRITON框架如何开发的问题。攻击者是否可以使用Triconex控制器和TriStation 1131软件套件？开发什么时候开始？威胁攻击者如何对协议进行逆向，以及在多大程度上？什么是协议结构？
FireEye的高级实践团队调查对手的方法，为回答这些疑问开始深入研究TRITON的Python脚本。
名词解释：
· TRITON：旨在通过TriStation协议操作Triconex SIS控制器的恶意软件框架。
· TriStation：特定Triconex控制器的UDP网络协议。
· TRITON威胁攻击者：开发，部署和/或运营TRITON的人。
二、从TRITON了解TriStation
TriStation是一种专有的网络协议，没有公开文件详细说明其结构或如何使用TriStation的创建软件应用程序。目前对TriStation UDP / IP协议的了解不多，但可通过TriStation 1131软件套件实现。TriStation在UDP 1502端口运行，并允许通过网络在指定的主站（具有“工程工作站”软件的PC）和从站（具有特殊通信模块的Triconex控制器）之间进行通信。
对我们来说，Triconex系统，软件和相关术语听起来异常复杂，TriStation协议也不例外。试图从零开始理解协议会花费大量时间，所以为什么不从TRITON开始学习呢？通过包含TriStation通信功能的TRITON框架，我们开始研究从而可以更好地理解这个神秘的协议。而且更便捷。
TRITON framework有许多功能，基本组件如下所示：
· TS_cnames.pyc # 2017-08-03 10:52:33
· TsBase.pyc # 2017-08-03 10:52:33
· TsHi.pyc # 2017-08-04 02:04:01
· TsLow.pyc # 2017-08-03 10:46:51
TsLow.pyc（图1）包含用于错误处理的部分代码，这些代码也提供了有关协议结构的一些提示。
图1: TsLow.pyc中的函数print_last_error()
在TsLow.pyc中的printLlast_error函数中，我们看到“TCM Error”的错误处理。将偏移量为0的TriStation数据包值与来自TS_cnames.pyc（图2）的相应数组中的数值进行比较（图2），该数据主要用作协议的“字典”。
图2: TS_cnames.pyc 中的TS_cst 数组
由此我们可以推断出TriStation协议的偏移量0包含消息类型。它由另外一个函数tcm_result支持，该函数声明type，size = struct.unpack（'<HH'，data_received [0：4]），声明前两个字节应该作为整型处理，后两个字节是TriStation消息的整数大小。这是我们第一次了解到威胁攻击者对TriStation协议的理解。
由于只有11种定义的消息类型，如果类型是一个字节或两个字节，确实没有多大关系，因为第二个字节始终为0x00。
有迹象表明消息类型5适用于所有的执行命令请求和响应，所以我们很好奇观察到TRITON开发者称之为“Command Reply”（直到后来我们才理解这个命名约定）。
接下来，我们检查TsLow.pyc的print_last_error函数（图3）来查看“TS Error”和“TS_names”。我们首先查看ts_err变量并查看它是否引用ts_result。
图3: TsLow.pyc中的函数print_last_error() ，其中ts_err高亮
我们来看看跟在之后的ts_result，它在随后的10个字节中定义了一些变量（图4）：dir，cid，cmd，cnt，unk，cks，siz = struct.unpack（'<，ts_packet [0:10]）。这里有很多要解压缩的内容，但最有趣的是这段脚本如何将ts_packet中的10个字节分解成不同的变量。
图4: ts_resul中ts_packet 头部变量高亮
图5: tcm_result
通过引用tcm_result（图5），我们看到它将类型和大小定义为前四个字节（偏移为0 - 3），并且tcm_result返回数据包字节4：-2（偏移4到结尾减2，因为最后两个字节是CRC-16校验和）。现在我们知道了tcm_result，我们知道ts_reply“cmd”是偏移量为6的单个字节，并且对应于TS_cnames.pyc数组和TS_names中的值（图6）。TRITON脚本还告诉我们，任何超过100的整数值都可能是“command reply”。
当回顾ts_result数据包头定义时，我们开始发现TRITON开发人员的一些知识空白：dir，cid，cmd，cnt，unk，cks，siz = struct.unpack（'<，ts_packet [0:10]）。很清楚根据命名惯例进行猜测，可以得到一个印象，偏移量4,5和6可能分别是“direction”，“controller ID”和“command”。像“unk”这样的值表明开发者不知道或不关心这个值。我们怀疑这是一个常数，但这个值对我们来说仍然是未知的。
图6: TS_cnames.pyc TS_names 数组, 包含TRITON攻击者对执行命令函数代码的注释
三、TriStation协议包的结构
TRITON威胁攻击者的知识和逆向工作使我们可以更好地理解协议。我们开始形成了一个更完整的脉络并记录TriStation的基本功能。我们主要关注消息类型5，执行命令，它能最好地说明了协议的整体结构。其他较小的消息类型则具有不同的结构。
图7: TriStation“Allocate Program”执行命令示例，带有颜色注释和协议图例
四、TriStation分析的确认
除了微小差异之外，其他公开分析支持图7中详细描述的TriStation结构。最重要的是，2017年伊利诺伊大学厄本那-香槟分校CSL实验室的研究人员发表了一篇题为“Attack Induced Common-Mode Failures on PLC-based Safety System in a Nuclear Power Plant”的论文。CSL团队提到他们使用Triconex系统访问应用程序（TSAA）协议对TriStation协议的元素进行了逆向。TSAA是由TriStation开发的协议。与TriStation不同，TSAA协议结构在官方文档中有描述。CSL评估了两种协议之间的相似性，利用TSAA可以更好地理解TriStation。团队对通用数据包结构的总体研究和分析与我们分析的TRITON数据包结构一致。
还有一些非常棒的博客文章和白皮书，以这种或那种方式支持我们的发现。Midnight Blue Labs，Accenture和US-CERT都解释了TRITON框架如何与TriStation协议完美结合。
五、TriStation逆向与TRITON开发
当发现TRITON时，我们想知道TRITON攻击者如何将TriStation逆向并将其实施到框架中。我们有很多看法，所有这些似乎都是合理的：创建，购买，借用还是偷窃？或者其中的一些组合？
我们最初的看法是，威胁攻击者购买了Triconex控制器和软件，用于测试以及从“基础”开始逆向，但我们不相信他们有一个具有确切存在漏洞的固件版本的控制器，他们在受害者现场实际上遇到的TRITON问题会更少。他们可能购买或使用了TriStation 1131软件的演示版本，允许他们为该框架进行TriStation逆向。他们可能从ICS公司，子公司或系统集成商那里窃取了TriStation Python库，并将窃取材料用作TriStation和TRITON开发的基础。但是，他们也有可能从有政府背景的公用事业公司借用了TriStation软件、Triconex硬件和Python连接器，这些公用事业公司正在合法使用它们。
纵观原始的TRITON代码，一些注释出现了奇怪的措辞，但我们确实了解到开发人员明确使用了许多正确的本地语言和缩略语，显示了PLC编程的智慧。TS_cnames.pyc脚本包含'Set lable'，'Alocate network accepted'，'Symbol table ccepted'以及'Set program information reponse'等有趣的拼写错误。这些似乎是正常的人为错误，并且既不反映英文书写的差，也不反映编码方面的懒惰。整个代码中大量的注释，级联逻辑和强大的错误处理能力表明了该框架经历了深思熟虑的开发和测试。这使“底层”开发的理论变得复杂，他们的代码是以其他的方式为基础的吗？
在TRITON内学习TriStation功能的同时，我们继续研究合法的TriStation软件。我们开始搜索“TS1131.exe”，并通过TriStation DLL进行排序，直到遇到MSI形式的各种TriStation实用程序。我们最终偶然发现了一个包含“Trilog v4”的档案。经过进一步检查，该文件安装了原始TRITON可执行文件“TriLog.exe”以及一些支持DLL，所有这些文件的时间戳都在2006年8月前后。
当我们看到DLL文件描述“Tricon Communications Interface”和原始文件名“TricCom.DLL”时，我们知道找到了正确的源。简单看一下文件字符串，BAZINGA！我们命中了。
tr1com40.DLL正是所期望的在自定义应用程序包中看到的内容。这是一个帮助支持Triconex控制器通信的库。如果已经对TRITON有所了解的话，那么看到字符串的那一刻就可以发现合法DLL与TRITON的TS_cnames.pyc之间有着明显的重叠。
图8: tr1com40.DLL中的字符串
TS_cnames.pyc中的每个执行命令“error codes”都位于tr1com40.DLL的字符串中（图8）。我们看到了“An MP has re-educated”和“Invalid Tristation I command”。甚至还有拼写错误的命令字符串，例如“Non-existant data item”和“Alocate network accepted”。我们也看到许多相同的未知值。显而易见的是，TRITON中的一些字符串应该是基于Trident和Tricon控制器通信库中使用的代码。
在对合法Triconex Corporation二进制文件的简要调查中，我们发现了几个带有相关字符串表的样本。
我们提取TR1STRS和LAGSTRS中的CPP字符串表以及TRITON中的TS_cnames.pyc TS_names数组，并比较每个文件中的210,204和212个相关字符串。
TS_cnames.pyc TS_names和tr1com40.dll共享220中的202个字符串。其余的字符串是独一无二的，如下所示：
TS_cnames.pyc TS_names和Tridcom.dll（1999 CPP）仅共享268个字符串中的151个，这表明它与较旧的CPP库重叠较小。这是基于Tridcom.dll适用于Trident控制器而不是Tricon控制器的上下文。看起来Tr1com40.dll和TR1STRS.CPP代码比较早。
我们并不感到震惊，威胁攻击者逆向了合法代码来加强TRITON框架的开发。他们希望更高效地工作。但是，在对合法软件进行逆向并实现TriStation的基础之后，威胁攻击者仍然对协议不完全了解。在TRITON的TS_cnames.pyc中，我们看到了“Unk75”，“Unk76”，“Unk83”以及tr1com40.DLL字符串中没有的其他值，表明TRITON威胁攻击者可能已经研究了该协议并注释了他们在DLL逆向中的发现。TriStation实现方面的差距展示了为什么攻击者在野外使用TRITON时遇到与Triconex控制器交互问题。
在VirusTotal上可以看到更多Trilog和Triconex DLL文件。
六、后记
看到Triconex系统针对恶意目标，这在六个月前对全世界来说都是新的。展望未来，预计其他框架（如TRITON）可用于其他SIS控制器。包括Triconex在内，我们会看到影响主导工业安全技术的类似攻击方法。
基本的安全措施对阻止真正持续的威胁攻击者者没有什么作用，并且只监视IT网络并不理想。对IT和OT环境的可见性对于检测ICS入侵的各个阶段都很关键。简单的检测概念（如标准偏差）可以提供对异常活动的了解。
当TRITON框架被积极使用时，在攻击者测试Triconex控制器上的漏洞利用和后门程序时有多少传统的ICS“警报”出现了？由于非标准流量，TriStation协议在其Python脚本中执行时，经历了多少次失败或引发错误？多少个TriStation UDP ping被发送了多少个连接请求？这些统计数据是如何与TriStation流量的标准进行比较的？目前没有这些问题的答案。如果我们努力提高对ICS技术的可见度，我们相信可以从长远角度来识别这些异常情况。
我们希望通过公开讨论ICS技术，Infosec社区可以与ICS供应商建立更紧密的关系，并让世界更好地了解攻击者如何从IT向OT空间移动。我们希望培养更多像这样的对话，并且分享找到恶意代码的技术。由于大多数ICS攻击都涉及标准的IT入侵，因此我们应该共同制定和改进有关如何监控连接IT和OT网络的PC和工程工作站的指导原则。我们设想一个攻击或干扰ICS行动的世界会威胁到威胁攻击者的掩护、工具包、时间和自由。这是一个理想的世界，但是可以期许。
七、致谢及后续工作
TRITON和TriStation还有很多工作要做。还有更多的子消息类型和细微差别需要澄清，如果没有自己的控制器是很难做到的。尽管我们已经在博客上发布了大量有关TriStation的知识，但工作仍将继续，因为我们将继续研究该协议。
感谢所有在TRITON和TriStation上进行过大量公开研究的人。我们在这篇博文中引用了一些，但有更多的社区信息为我们提供了线索，用于对框架和协议的研究和测试。此外，还必须承认TRITON攻击者所进行的研究。我们从TRITON框架本身借用了大量有关TriStation的知识。
最后，我们认为我们大部分的研究是正确的，但如果您发现任何错误或遗漏，或有改进意见，请联系：[email protected]。
推荐阅读
· Analyzing the TRITON industrial malware
· Repository containting original and decompiled files of TRISIS/TRITON/HATMAN malware
· MAR-17-352-01 HatMan - Safety System Targeted Malware (Update A)
还没有评论，来说两句吧...