{ "id": "248a1151-6578-49c7-96ae-730e77d18d6e", "created_at": "2026-04-06T00:21:43.590033Z", "updated_at": "2026-04-10T03:37:09.449545Z", "deleted_at": null, "sha1_hash": "d196252b1191a324f856efc63c7241a843399ece", "title": "TRITON Malware | Attackers Deploy New ICS Attack Framework", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1025153, "plain_text": "TRITON Malware | Attackers Deploy New ICS Attack Framework\r\nBy Mandiant\r\nPublished: 2017-12-14 · Archived: 2026-04-02 11:44:17 UTC\r\nWritten by: Blake Johnson, Dan Caban, Marina Krotofil, Dan Scali, Nathan Brubaker, Christopher Glyer\r\nIntroduction\r\nMandiant recently responded to an incident at a critical infrastructure organization where an attacker deployed\r\nmalware designed to manipulate industrial safety systems. The targeted systems provided emergency shutdown\r\ncapability for industrial processes. We assess with moderate confidence that the attacker was developing the\r\ncapability to cause physical damage and inadvertently shutdown operations. This malware, which we call\r\nTRITON, is an attack framework built to interact with Triconex Safety Instrumented System (SIS) controllers. We\r\nhave not attributed the incident to a threat actor, though we believe the activity is consistent with a nation state\r\npreparing for an attack.\r\nTRITON is one of a limited number of publicly identified malicious software families targeted at industrial\r\ncontrol systems (ICS). It follows Stuxnet which was used against Iran in 2010 and Industroyer which we believe\r\nwas deployed by Sandworm Team against Ukraine in 2016. TRITON is consistent with these attacks, in that it\r\ncould prevent safety mechanisms from executing their intended function, resulting in a physical consequence.\r\nMalware\r\nFamily\r\nMain Modules Description\r\nTRITON trilog.exe\r\nMain executable leveraging\r\nlibraries.zip\r\nlibrary.zip\r\nCustom communication library for interaction with\r\nTriconex controllers.\r\n \r\nTable 1: Description of TRITON Malware\r\nIncident Summary\r\nThe attacker gained remote access to an SIS engineering workstation and deployed the TRITON attack framework\r\nto reprogram the SIS controllers. During the incident, some SIS controllers entered a failed safe state, which\r\nautomatically shutdown the industrial process and prompted the asset owner to initiate an investigation. The\r\ninvestigation found that the SIS controllers initiated a safe shutdown when application code between redundant\r\nprocessing units failed a validation check -- resulting in an MP diagnostic failure message.\r\nhttps://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html\r\nPage 1 of 10\n\nWe assess with moderate confidence that the attacker inadvertently shutdown operations while developing the\r\nability to cause physical damage for the following reasons:\r\nModifying the SIS could prevent it from functioning correctly, increasing the likelihood of a failure that\r\nwould result in physical consequences.\r\nTRITON was used to modify application memory on SIS controllers in the environment, which could have\r\nled to a failed validation check.\r\nThe failure occurred during the time period when TRITON was used.\r\nIt is not likely that existing or external conditions, in isolation, caused a fault during the time of the\r\nincident.\r\nAttribution\r\nFireEye has not connected this activity to any actor we currently track; however, we assess with moderate\r\nconfidence that the actor is sponsored by a nation state. The targeting of critical infrastructure as well as the\r\nattacker’s persistence, lack of any clear monetary goal and the technical resources necessary to create the attack\r\nframework suggest a well-resourced nation state actor. Specifically, the following facts support this assessment:\r\nThe attacker targeted the SIS suggesting an interest in causing a high-impact attack with physical consequences.\r\nThis is an attack objective not typically seen from cyber-crime groups.\r\nThe attacker deployed TRITON shortly after gaining access to the SIS system, indicating that they had pre-built\r\nand tested the tool which would require access to hardware and software that is not widely available. TRITON is\r\nalso designed to communicate using the proprietary TriStation protocol which is not publicly documented\r\nsuggesting the adversary independently reverse engineered this protocol.\r\nThe targeting of critical infrastructure to disrupt, degrade, or destroy systems is consistent with numerous attack\r\nand reconnaissance activities carried out globally by Russian, Iranian, North Korean, U.S., and Israeli nation state\r\nactors. Intrusions of this nature do not necessarily indicate an immediate intent to disrupt targeted systems, and\r\nmay be preparation for a contingency.\r\nBackground on Process Control and Safety Instrumented Systems\r\nhttps://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html\r\nPage 2 of 10\n\nFigure 1: ICS Reference Architecture\r\nModern industrial process control and automation systems rely on a variety of sophisticated control systems and\r\nsafety functions. These systems and functions are often referred to as Industrial Control Systems (ICS) or\r\nOperational Technology (OT).\r\nA Distributed Control System (DCS) provides human operators with the ability to remotely monitor and control\r\nan industrial process. It is a computerized control system consisting of computers, software applications and\r\ncontrollers. An Engineering Workstation is a computer used for configuration, maintenance and diagnostics of the\r\ncontrol system applications and other control system equipment.\r\nA SIS is an autonomous control system that independently monitors the status of the process under control. If the\r\nprocess exceeds the parameters that define a hazardous state, the SIS attempts to bring the process back into a safe\r\nstate or automatically performs a safe shutdown of the process. If the SIS and DCS controls fail, the final line of\r\ndefense is the design of the industrial facility, which includes mechanical protections on equipment (e.g. rupture\r\ndiscs), physical alarms, emergency response procedures and other mechanisms to mitigate dangerous situations.\r\nAsset owners employ varied approaches to interface their plant's DCS with the SIS. The traditional approach relies\r\non the principles of segregation for both communication infrastructures and control strategies. For at least the past\r\ndecade, there has been a trend towards integrating DCS and SIS designs for various reasons including lower cost,\r\nease of use, and benefits achieved from exchanging information between the DCS and SIS. We believe TRITON\r\nhttps://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html\r\nPage 3 of 10\n\nacutely demonstrates the risk associated with integrated designs that allow bi-directional communication between\r\nDCS and SIS network hosts.\r\nSafety Instrumented Systems Threat Model and Attack Scenarios\r\nFigure 2: Temporal Relationship Between Cyber Security and Safety\r\nThe attack lifecycle for disruptive attacks against ICS is similar to other types of cyber attacks, with a few key\r\ndistinctions. First, the attacker’s mission is to disrupt an operational process rather than steal data. Second, the\r\nattacker must have performed OT reconnaissance and have sufficient specialized engineering knowledge to\r\nunderstand the industrial process being controlled and successfully manipulate it.\r\nFigure 2 represents the relationship between cyber security and safety controls in a process control environment.\r\nEven if cyber security measures fail, safety controls are designed to prevent physical damage. To maximize\r\nphysical impact, a cyber attacker would also need to bypass safety controls.\r\nThe SIS threat model below highlights some of the options available to an attacker who has successfully\r\ncompromised an SIS.\r\nAttack Option 1: Use the SIS to shutdown the process\r\nThe attacker can reprogram the SIS logic to cause it to trip and shutdown a process that is, in actuality, in a\r\nsafe state. In other words, trigger a false positive.\r\nImplication: Financial losses due to process downtime and complex plant start up procedure after the\r\nshutdown.\r\nAttack Option 2: Reprogram the SIS to allow an unsafe state\r\nThe attacker can reprogram the SIS logic to allow unsafe conditions to persist.\r\nhttps://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html\r\nPage 4 of 10\n\nImplication: Increased risk that a hazardous situation will cause physical consequences (e.g. impact to\r\nequipment, product, environment and human safety) due to a loss of SIS functionality.\r\nAttack Option 3: Reprogram the SIS to allow an unsafe state – while using the DCS to create an unsafe state or\r\nhazard\r\nThe attacker can manipulate the process into an unsafe state from the DCS while preventing the SIS from\r\nfunctioning appropriately.\r\nImplication: Impact to human safety, the environment, or damage to equipment, the extent of which\r\ndepends on the physical constraints of the process and the plant design.\r\nAnalysis of Attacker Intent\r\nWe assess with moderate confidence that the attacker’s long-term objective was to develop the capability to cause\r\na physical consequence. We base this on the fact that the attacker initially obtained a reliable foothold on the DCS\r\nand could have developed the capability to manipulate the process or shutdown the plant, but instead proceeded to\r\ncompromise the SIS system. Compromising both the DCS and SIS system would enable the attacker to develop\r\nand carry out an attack that causes the maximum amount of damage allowed by the physical and mechanical\r\nsafeguards in place.\r\nOnce on the SIS network, the attacker used their pre-built TRITON attack framework to interact with the SIS\r\ncontrollers using the TriStation protocol. The attacker could have caused a process shutdown by issuing a halt\r\ncommand or intentionally uploading flawed code to the SIS controller to cause it to fail. Instead, the attacker made\r\nseveral attempts over a period of time to develop and deliver functioning control logic for the SIS controllers in\r\nthis target environment. While these attempts appear to have failed due one of the attack scripts’ conditional\r\nchecks, the attacker persisted with their efforts. This suggests the attacker was intent on causing a specific\r\noutcome beyond a process shutdown.\r\nOf note, on several occasions, we have observed evidence of long term intrusions into ICS which were not\r\nultimately used to disrupt or disable operations. For instance, Russian operators, such as Sandworm Team, have\r\ncompromised Western ICS over a multi-year period without causing a disruption.\r\nSummary of Malware Capabilities\r\nThe TRITON attack tool was built with a number of features, including the ability to read and write programs,\r\nread and write individual functions and query the state of the SIS controller. However, only some of these\r\ncapabilities were leveraged in the trilog.exe sample (e.g. the attacker did not leverage all of TRITON’s extensive\r\nreconnaissance capabilities).\r\nThe TRITON malware contained the capability to communicate with Triconex SIS controllers (e.g. send specific\r\ncommands such as halt or read its memory content) and remotely reprogram them with an attacker-defined\r\npayload. The TRITON sample Mandiant analyzed added an attacker-provided program to the execution table of\r\nthe Triconex controller. This sample left legitimate programs in place, expecting the controller to continue\r\noperating without a fault or exception. If the controller failed, TRITON would attempt to return it to a running\r\nhttps://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html\r\nPage 5 of 10\n\nstate. If the controller did not recover within a defined time window, this sample would overwrite the malicious\r\nprogram with invalid data to cover its tracks.\r\nRecommendations\r\nAsset owners who wish to defend against the capabilities demonstrated in the incident, should consider the\r\nfollowing controls:\r\nWhere technically feasible, segregate safety system networks from process control and information system\r\nnetworks. Engineering workstations capable of programming SIS controllers should not be dual-homed to\r\nany other DCS process control or information system network.\r\nLeverage hardware features that provide for physical control of the ability to program safety controllers.\r\nThese usually take the form of switches controlled by a physical key. On Triconex controllers, keys should\r\nnot be left in the PROGRAM mode other than during scheduled programming events.\r\nImplement change management procedures for changes to key position. Audit current key state regularly.\r\nUse a unidirectional gateway rather than bidirectional network connections for any applications that\r\ndepend on the data provided by the SIS.\r\nImplement strict access control and application whitelisting on any server or workstation endpoints that can\r\nreach the SIS system over TCP/IP.\r\nMonitor ICS network traffic for unexpected communication flows and other anomalous activity.\r\nFigure 3: Triconex Key Switch (source)\r\nAppendix: Technical Analysis\r\nhttps://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html\r\nPage 6 of 10\n\nFigure 4: TRITON Architecture and Attack Scenario\r\nTRITON was deployed on an SIS engineering workstation running the Microsoft Windows operating system. The\r\nmalware was named to masquerade as the legitimate Triconex Trilog application. This application is used for\r\nreviewing logs and is a part of the TriStation application suite. The malware was delivered as a Py2EXE compiled\r\npython script dependent on a zip file containing standard Python libraries, open source libraries, as well as the\r\nattacker-developed Triconex attack framework for interacting with the Triconex controllers. Along with the\r\nexecutable, two binary files, inject.bin (malicious function code) and imain.bin (malicious control logic), were\r\ndeployed as the controller’s payload. These file names were hard coded in the Py2EXE compiled python script.\r\nTrilog.exe took one option from the command line, which was a single IP address of the target Triconex device. It\r\ndid not leverage the underlying TRITON library’s capability for Triconex device discovery, instead an instance of\r\ntrilog.exe had to be invoked separately for each target controller in the environment. Once invoked, trilog.exe\r\nchecked the status of the controller, then read the configuration information exposed by the TriStation protocol. If\r\nthe controller was in a running state, trilog.exe encoded the two payload files inject.bin and imain.bin and passed\r\nthem to the communication libraries to be appended to the controller’s program memory and execution table.\r\nAfter payload files were inserted into memory on the Triconex controller, the script initiated a countdown,\r\nperiodically checking the status of the controller. If an error was detected, the communication library’s method\r\nSafeAppendProgramMod attempted to reset the controller to the previous state using a TriStation protocol\r\ncommand. If this failed, trilog.exe attempted to write a small ‘dummy’ program to memory. We assess that this\r\nwas an anti-forensics technique to hide the presence of the attacker code on the Triconex controller.\r\nWorking with the asset owner, Mandiant ran trilog.exe in a lab environment with a valid Triconex controller and\r\ndiscovered a conditional check in the malware that prevented the payload binary from persisting in the\r\nenvironment. Mandiant confirmed that, after correcting patching the attack script to remove this check, the\r\npayload binary would persist in controller memory, and the controller would continue to run.\r\nTRITON implements the TriStation protocol, which is the protocol used by the legitimate TriStation application,\r\nto configure controllers.\r\nTsHi is the high-level interface created by the malware’s authors that allows the threat actor’s operators to\r\nimplement attack scripts using the TRITON framework. It exposes functions for both reconnaissance and attack.\r\nThe functions generally accept binary data from the user, and handle the code ‘signing’ and check sums prior to\r\npassing the data to lower level libraries for serialization on to the network.\r\nhttps://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html\r\nPage 7 of 10\n\nTsBase, another attacker-written module, contains the functions called by TsHi, which translate the attacker’s\r\nintended action to the appropriate TriStation protocol function code. For certain functions, it also packs and pads\r\nthe data in to the appropriate format.\r\nTsLow is an additional attacker module that implements the TriStation UDP wire protocol. The TsBase library\r\nprimarily depends on the ts_exec method. This method takes the function code and expected response code, and\r\nserializes the commands payload over UDP. It checks the response from the controller against the expected value\r\nand returns a result data structure indicating success or a False object representing failure.\r\nTsLow also exposes the connect method used to check connectivity to the target controller. If invoked with no\r\ntargets, it runs the device discovery function detect_ip. This leverages a \"ping\" message over the TriStation\r\nprotocol using IP broadcast to find controllers that are reachable via a router from where the script is invoked.\r\nIndicators\r\nFilename Hash\r\ntrilog.exe\r\nMD5: 6c39c3f4a08d3d78f2eb973a94bd7718\r\nSHA-256:\r\ne8542c07b2af63ee7e72ce5d97d91036c5da56e2b091aa2afe737b224305d230\r\nimain.bin\r\nMD5: 437f135ba179959a580412e564d3107f\r\nSHA-256:\r\n08c34c6ac9186b61d9f29a77ef5e618067e0bc9fe85cab1ad25dc6049c376949\r\ninject.bin\r\nMD5: 0544d425c7555dc4e9d76b571f31f500\r\nSHA-256:\r\n5fc4b0076eac7aa7815302b0c3158076e3569086c4c6aa2f71cd258238440d14\r\nlibrary.zip\r\nMD5: 0face841f7b2953e7c29c064d6886523\r\nSHA-256:\r\nbef59b9a3e00a14956e0cd4a1f3e7524448cbe5d3cc1295d95a15b83a3579c59\r\nTS_cnames.pyc\r\nMD5: e98f4f3505f05bf90e17554fbc97bba9\r\nSHA-256:\r\n2c1d3d0a9c6f76726994b88589219cb8d9c39dd9924bc8d2d02bf41d955fe326\r\nTsBase.pyc\r\nMD5: 288166952f934146be172f6353e9a1f5\r\nSHA-256:\r\n1a2ab4df156ccd685f795baee7df49f8e701f271d3e5676b507112e30ce03c42\r\nTsHi.pyc\r\nMD5: 27c69aa39024d21ea109cc9c9d944a04\r\nSHA-256:\r\n758598370c3b84c6fbb452e3d7119f700f970ed566171e879d3cb41102154272\r\nhttps://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html\r\nPage 8 of 10\n\nTsLow.pyc\r\nMD5: f6b3a73c8c87506acda430671360ce15\r\nSHA-256:\r\n5c776a33568f4c16fee7140c249c0d2b1e0798a96c7a01bfd2d5684e58c9bb32\r\nsh.pyc\r\nMD5: 8b675db417cc8b23f4c43f3de5c83438\r\nSHA-256:\r\nc96ed56bf7ee85a4398cc43a98b4db86d3da311c619f17c8540ae424ca6546e1\r\nDetection\r\nrule TRITON_ICS_FRAMEWORK\r\n{\r\n meta:\r\n author = \"nicholas.carr @itsreallynick\"\r\n md5 = \"0face841f7b2953e7c29c064d6886523\"\r\n description = \"TRITON framework recovered during Mandiant ICS incident response\"\r\n strings:\r\n $python_compiled = \".pyc\" nocase ascii wide\r\n $python_module_01 = \"__module__\" nocase ascii wide\r\n $python_module_02 = \"\u003cmodule\u003e\" nocase ascii wide\r\n $python_script_01 = \"import Ts\" nocase ascii wide\r\n $python_script_02 = \"def ts_\" nocase ascii wide\r\n $py_cnames_01 = \"TS_cnames.py\" nocase ascii wide\r\n $py_cnames_02 = \"TRICON\" nocase ascii wide\r\n $py_cnames_03 = \"TriStation \" nocase ascii wide\r\n $py_cnames_04 = \" chassis \" nocase ascii wide\r\n $py_tslibs_01 = \"GetCpStatus\" nocase ascii wide\r\n $py_tslibs_02 = \"ts_\" ascii wide\r\n $py_tslibs_03 = \" sequence\" nocase ascii wide\r\n $py_tslibs_04 = /import Ts(Hi|Low|Base)/ nocase ascii wide\r\n $py_tslibs_05 = /module\\s?version/ nocase ascii wide\r\n $py_tslibs_06 = \"bad \" nocase ascii wide\r\n $py_tslibs_07 = \"prog_cnt\" nocase ascii wide\r\n $py_tsbase_01 = \"TsBase.py\" nocase ascii wide\r\n $py_tsbase_02 = \".TsBase(\" nocase ascii wide\r\n \r\n $py_tshi_01 = \"TsHi.py\" nocase ascii wide\r\n $py_tshi_02 = \"keystate\" nocase ascii wide\r\n $py_tshi_03 = \"GetProjectInfo\" nocase ascii wide\r\n $py_tshi_04 = \"GetProgramTable\" nocase ascii wide\r\n $py_tshi_05 = \"SafeAppendProgramMod\" nocase ascii wide\r\n $py_tshi_06 = \".TsHi(\" ascii nocase wide\r\nhttps://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html\r\nPage 9 of 10\n\n$py_tslow_01 = \"TsLow.py\" nocase ascii wide\r\n $py_tslow_02 = \"print_last_error\" ascii nocase wide\r\n $py_tslow_03 = \".TsLow(\" ascii nocase wide\r\n $py_tslow_04 = \"tcm_\" ascii wide\r\n $py_tslow_05 = \" TCM found\" nocase ascii wide\r\n $py_crc_01 = \"crc.pyc\" nocase ascii wide\r\n $py_crc_02 = \"CRC16_MODBUS\" ascii wide\r\n $py_crc_03 = \"Kotov Alaxander\" nocase ascii wide\r\n $py_crc_04 = \"CRC_CCITT_XMODEM\" ascii wide\r\n $py_crc_05 = \"crc16ret\" ascii wide\r\n $py_crc_06 = \"CRC16_CCITT_x1D0F\" ascii wide\r\n $py_crc_07 = /CRC16_CCITT[^_]/ ascii wide\r\n $py_sh_01 = \"sh.pyc\" nocase ascii wide\r\n $py_keyword_01 = \" FAILURE\" ascii wide\r\n $py_keyword_02 = \"symbol table\" nocase ascii wide\r\n $py_TRIDENT_01 = \"inject.bin\" ascii nocase wide\r\n $py_TRIDENT_02 = \"imain.bin\" ascii nocase wide\r\n condition:\r\n 2 of ($python_*) and 7 of ($py_*) and filesize \u003c 3MB\r\n}\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html\r\nhttps://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html\r\nPage 10 of 10", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "MISPGALAXY", "Malpedia", "MITRE" ], "references": [ "https://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html" ], "report_names": [ "attackers-deploy-new-ics-attack-framework-triton.html" ], "threat_actors": [ { "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": "8941e146-3e7f-4b4e-9b66-c2da052ee6df", "created_at": "2023-01-06T13:46:38.402513Z", "updated_at": "2026-04-10T02:00:02.959797Z", "deleted_at": null, "main_name": "Sandworm", "aliases": [ "IRIDIUM", "Blue Echidna", "VOODOO BEAR", "FROZENBARENTS", "UAC-0113", "Seashell Blizzard", "UAC-0082", "APT44", "Quedagh", "TEMP.Noble", "IRON VIKING", "G0034", "ELECTRUM", "TeleBots" ], "source_name": "MISPGALAXY:Sandworm", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "7bd810cb-d674-4763-86eb-2cc182d24ea0", "created_at": "2022-10-25T16:07:24.1537Z", "updated_at": "2026-04-10T02:00:04.883793Z", "deleted_at": null, "main_name": "Sandworm Team", "aliases": [ "APT 44", "ATK 14", "BE2", "Blue Echidna", "CTG-7263", "FROZENBARENTS", "G0034", "Grey Tornado", "IRIDIUM", "Iron Viking", "Quedagh", "Razing Ursa", "Sandworm", "Sandworm Team", "Seashell Blizzard", "TEMP.Noble", "UAC-0082", "UAC-0113", "UAC-0125", "UAC-0133", "Voodoo Bear" ], "source_name": "ETDA:Sandworm Team", "tools": [ "AWFULSHRED", "ArguePatch", "BIASBOAT", "Black Energy", "BlackEnergy", "CaddyWiper", "Colibri Loader", "Cyclops Blink", "CyclopsBlink", "DCRat", "DarkCrystal RAT", "Fobushell", "GOSSIPFLOW", "Gcat", "IcyWell", "Industroyer2", "JaguarBlade", "JuicyPotato", "Kapeka", "KillDisk.NCX", "LOADGRIP", "LOLBAS", "LOLBins", "Living off the Land", "ORCSHRED", "P.A.S.", "PassKillDisk", "Pitvotnacci", "PsList", "QUEUESEED", "RansomBoggs", "RottenPotato", "SOLOSHRED", "SwiftSlicer", "VPNFilter", "Warzone", "Warzone RAT", "Weevly" ], "source_id": "ETDA", "reports": null }, { "id": "a66438a8-ebf6-4397-9ad5-ed07f93330aa", "created_at": "2022-10-25T16:47:55.919702Z", "updated_at": "2026-04-10T02:00:03.618194Z", "deleted_at": null, "main_name": "IRON VIKING", "aliases": [ "APT44 ", "ATK14 ", "BlackEnergy Group", "Blue Echidna ", "CTG-7263 ", "ELECTRUM ", "FROZENBARENTS ", "Hades/OlympicDestroyer ", "IRIDIUM ", "Qudedagh ", "Sandworm Team ", "Seashell Blizzard ", "TEMP.Noble ", "Telebots ", "Voodoo Bear " ], "source_name": "Secureworks:IRON VIKING", "tools": [ "BadRabbit", "BlackEnergy", "GCat", "NotPetya", "PSCrypt", "TeleBot", "TeleDoor", "xData" ], "source_id": "Secureworks", "reports": null }, { "id": "b3e954e8-8bbb-46f3-84de-d6f12dc7e1a6", "created_at": "2022-10-25T15:50:23.339976Z", "updated_at": "2026-04-10T02:00:05.27483Z", "deleted_at": null, "main_name": "Sandworm Team", "aliases": [ "Sandworm Team", "ELECTRUM", "Telebots", "IRON VIKING", "BlackEnergy (Group)", "Quedagh", "Voodoo Bear", "IRIDIUM", "Seashell Blizzard", "FROZENBARENTS", "APT44" ], "source_name": "MITRE:Sandworm Team", "tools": [ "Bad Rabbit", "Mimikatz", "Exaramel for Linux", "Exaramel for Windows", "GreyEnergy", "PsExec", "Prestige", "P.A.S. Webshell", "AcidPour", "VPNFilter", "Neo-reGeorg", "Cyclops Blink", "SDelete", "Kapeka", "AcidRain", "Industroyer", "Industroyer2", "BlackEnergy", "Cobalt Strike", "NotPetya", "KillDisk", "PoshC2", "Impacket", "Invoke-PSImage", "Olympic Destroyer" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434903, "ts_updated_at": 1775792229, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/d196252b1191a324f856efc63c7241a843399ece.pdf", "text": "https://archive.orkl.eu/d196252b1191a324f856efc63c7241a843399ece.txt", "img": "https://archive.orkl.eu/d196252b1191a324f856efc63c7241a843399ece.jpg" } }