{
	"id": "0b923ef0-f8b8-4666-93ae-2d437abbc7de",
	"created_at": "2026-04-06T00:13:26.100326Z",
	"updated_at": "2026-04-10T03:32:49.982547Z",
	"deleted_at": null,
	"sha1_hash": "623022af8f5b6f0e1776a3e28b4767079a135bfc",
	"title": "Analyzing the TRITON industrial malware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 320438,
	"plain_text": "Analyzing the TRITON industrial malware\r\nArchived: 2026-04-05 15:47:46 UTC\r\nSummary\r\nTRITON is the first publicly known example of malware targeting industrial safety controllers, an escalation with\r\nserious potential consequences compared to previous ICS-focussed incidents. It has been deployed against at least\r\none victim in the Middle East with no indications of victims outside of the Middle East so far. TRITON is a\r\nframework for implanting Schneider Electric Triconex safety controllers with a passive backdoor through which\r\nattackers can, at a later point in time, inject potentially destructive payloads.\r\nThough the potential impact is very serious (including infrastructural damage and loss of life resulting from\r\nsabotaging critical safety systems) it is important to nuance the threat posed by the discovery of this malware,\r\nespecially when the original attacker intent remains speculative. In addition, the attack is not very scalable even\r\nagainst other Triconex safety controllers due to the complexity of required industrial process comprehension.\r\nHowever, a sufficiently knowledgeable and well-resourced attacker seeking to target a facility using Triconex\r\ncontrollers as part of its safety systems could repurpose TRITON, thereby lowering the bar somewhat by\r\nremoving the barrier of reverse-engineering the proprietary TriStation protocol. The incident is illustrative of\r\nvarious woes in the industrial cybersecurity world which have been discussed extensively over the past years,\r\nranging from devices which are 'insecure by design' and have been exposed to hyper-connected environments they\r\nwere not quite designed for to a lack of basic IT/OT security hygiene and early warning insights on part of asset\r\nowners.\r\nBackground\r\nTRITON is one of the few publicly known examples of malware targeting Industrial Control Systems (ICS), after\r\nStuxnet, Havex, Blackenergy2 and Industroyer, and the first publicly known example of malware targeting\r\nindustrial safety controllers specifically. Safety Instrumented Systems (SIS) are autonomous control systems\r\ntasked with maintaining automated process safe states and are typically used to implement safety logic in critical\r\nprocesses where serious damage or loss of life might be a risk. This is done by, for example, monitoring\r\ntemperature or pressure via sensor inputs and halting the flow or heating of gases when dangerous thresholds are\r\nexceeded. They are usually connected to actuators (eg. for opening or closing a valve) in order to override normal\r\nprocess control and halt the runaway process.\r\nhttps://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware\r\nPage 1 of 10\n\nBasic industrial safety \u0026 protection layers (source)\r\nSafety controllers are typically a kind of Programmable Logic Controller (PLC) designed to high standards with\r\nredundant modules and tend to have components that allow for safe failure in case the main processor fails or\r\npower is lost. They are deployed in a manner specific to the process environment requirements and are usually\r\nconfigured in one of the IEC 61131-3 programming languages (eg. LD, ST, etc.). Of course, safety is not quite the\r\nsame as security and safety controllers tend to have the same kind of 'insecure by design' profile as a regular PLC:\r\nie. everything from hardcoded maintenance backdoor accounts to insecure proprietary protocols.\r\nTraditionally, SIS connectivity is limited and systems are segregated from the rest of the Operational Technology\r\n(OT) environment which would limit the potential impact of safety controller security issues. But over the years,\r\nas part of a broader trend in embedded systems in general, this isolation has made way for more and more\r\nconnectivity and systems integration. While this integration comes with benefits in terms of cost, usability and\r\nprocess insights for business intelligence purposes, the flip side is that it exposes systems that were never designed\r\nfor secure connectivity in the first place to the wider OT and IT environments and by extension to whatever the\r\nwider network itself is exposed to. The potential implications of a malicious SIS-compromising attacker are\r\nserious and could range from shutting down a process to allowing for unsafe states and manipulating other parts of\r\nthe OT environment to create such a state which might result in financial losses, damage to equipment, products\r\nand the environment or human safety and loss of life.\r\nBut it's important to nuance this image and avoid alarmist headlines. First of all because fear, uncertainty and\r\ndoubt cause sensible analysis and good advice to be lost amid sensationalism and help create a 'boy who cried\r\nwolf' effect where the stock that ICS equipment vendors and OT asset owners and operators put in the opinions of\r\nthe security industry as a whole erodes over time. Secondly, while the initial steps along the 'ICS Kill Chain', up to\r\nand including the compromise of the safety controller, might seem relatively simple, crafting the 'OT payload' that\r\nactually does the damage is typically neither easy nor scalable. As pointed out by Benjamin Green, Marina\r\nhttps://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware\r\nPage 2 of 10\n\nKrotofil and Ali Abbasi such attacks require a high level of process comprehension which would have to be\r\nderived from analysis of acquired documents, diagrams, data historian files, device configurations and network\r\ntraffic. This would have to be done on a facility-to-facility basis since even attacks against two functionally\r\nsimilar facilities will require attackers to take differences in process scale and design, equipment and device\r\nconfiguration into account.\r\nIn the case of SIS that means that a security compromise does not trivially compromise process safety. Apart from\r\nthe SIS, the facility in question might have safety measures ranging from sacrificial parts in machines, enclosures\r\nand blast dampers to alarms and emergency procedures and as such assessing the implications of SIS compromise\r\nwould require facility-specific process comprehension as well. This does not mean that such worst-case scenarios\r\nare infeasible but that the attacker space capable of bringing them about and their scalability are more limited than\r\noften portrayed.\r\nThe Incident\r\nThe FireEye report claims that the attacker gained remote access to a Triconex engineering workstation running\r\nMicrosoft Windows as well as the Distributed Control System (DCS). The attacker deployed a Py2EXE\r\napplication, which was disguised as a benign Triconex log reviewing application named Trilog.exe, containing the\r\nTRITON framework on the engineering workstation together with two binary payload files named inject.bin and\r\nimain.bin. TRITON does not leverage any 0-days but instead reprograms the target safety controllers via the\r\nTriStation protocol (discussed below) which lacks authentication (though ACLs could have been configured on\r\nthe controllers). As the TriStation protocol is proprietary and undocumented this means the attacker had to reverse\r\nengineer it, possibly through a combination of using similarities with the documented Triconex System Access\r\nApplication (TSAA) protocol, inspection of traffic between the engineering workstation and the controller and\r\nreverse-engineering of workstation software and controller firmware.\r\nThe TRITON framework is capable of autodiscovering Triconex controllers on the network by sending a UDP\r\nbroadcast message over port 1502 but this functionality was not used during the incident. Instead the IP addresses\r\nof the target controllers were specified directly and upon connection the status of the controller was retrieved over\r\nTriStation. If the controller was running the inject.bin and imain.bin payload files were injected into the controller\r\nprogram memory and a periodic check was initiated to see if any error was detected. If so, TRITON would reset\r\nthe controller to the previous state over Tristation and if this failed it would write a dummy program to memory in\r\nwhat was likely an attempt at anti-forensics. During the incident, the industrial process was shutdown as a result\r\nof some controllers entering a failed safe state which caused the asset owner to initiate the investigation. The\r\ncause of this failed safe state was reportedly a failed validation check between the three separate redundant\r\nTriconex processor modules.\r\nThe fact that both the DCS and SIS systems were compromised suggests the attacker intended to cause serious\r\ndamage rather than a mere process shutdown. This hypothesis is strengthened (though not indisputably confirmed)\r\nby the fact that the attacker apparently made several attempts to deliver a specific control logic to the safety\r\ncontrollers rather than merely shut them down.\r\nTriconex Safety Instrumented Systems (SIS)\r\nhttps://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware\r\nPage 3 of 10\n\nThe Schneider Electric Triconex line of safety controllers consists of the Tricon (CX), Trident and Tri-GP systems\r\nall of which share the triple modular redundancy (TMR) architecture. While the incident targeted Tricon 3008\r\ncontrollers specifically, the heart of the attack is the (ab)use of the unauthenticated TriStation protocol and as such\r\nall safety controllers running this protocol are potentially affected.\r\nAccording to the Planning and Installation Guide for Tricon v9–v10 Systems, a basic Tricon controller consists of\r\nthe Main Processors, I/O modules, communication modules, chassis, field wiring connections and an engineering\r\nhttps://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware\r\nPage 4 of 10\n\nworkstation PC communicating with the controller over TriStation. A chassis houses three Main Processor (MP)\r\nModules, each of which serve one channel (or 'leg') of the controller and independently executes the control\r\nprogram and communicates with its own I/O subsystem (every I/O module has three independent channels for\r\nserving the three MPs) in parallel with the other Main Processors. The three MP modules, which operate\r\nautonomously without shared clocks, power regulation or circuitry, then compare data and control program at\r\nperiodic intervals and synchronize with their neighbors over a high-speed proprietary communications bus named\r\nTriBus. TriBus consists of three independent serial links. Hardware voting on the I/O data takes place over TriBus\r\namong the MPs and if disagreement occurs, the signal in two out of three prevails and the third MP is corrected.\r\nHere one-time differences are distinguished from patterns of differences. This Triple Modular Redundant (TMR)\r\narchitecture is designed for fault tolerance in the face of transient faults or component failures.\r\nThere are a variety of communication modules, talking to the Main Processors over the communication bus, for\r\nTriconex controllers to facilitate serial and network communications across a variety of protocols. Examples\r\ninclude the Advanced Communication Module (ACM) which acts as an interface between a Tricon controller and a\r\nFoxboro Intelligent Automation (I/A) Series DCS, the Hiway Interface Module (HIM) which acts as an interface\r\nbetween a Tricon controller and a Honeywell TDC-3000 control system or the Tricon Communication Module\r\n(TCM) which allows communications with TriStation, other Triconex controllers, Modbus master/slave devices\r\nand external hosts over Ethernet networks. These communications include the documented Tricon System Access\r\nApplication (TSAA) protocol, a multi-slave master/slave protocol used to read and write data points, and the\r\nundocumented TriStation protocol, a single-slave master/slave protocol used by the TriStation 1131 or MSW\r\nengineering workstation software to develop and download the control program running on the Triconex\r\ncontrollers. By default, Ethernet communications for TSAA take place over UDP port 1500 while those for\r\nTriStation take place over UDP port 1502.\r\nThe Triconex controllers have a physical four-position key switch which can be set to either RUN (normal\r\noperation, read-only but can be overridden by a GATENB function block in the control program), PROGRAM\r\n(allows control program loading and verification), STOP (stop reading inputs, forces non-retentive digital and\r\nanalog outputs to 0, and halts the control program. This position can be overridden by TriStation) or REMOTE\r\n(allows writes to control program variables). However, in the incident in question the target controllers were left in\r\nPROGRAM mode and the payload injected by TRITON (described below) allows subsequent malicious\r\nmodifications by means of communications with the implant regardless of key switch position.\r\nhttps://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware\r\nPage 5 of 10\n\nA control program is developed and debugged with the TriStation 1131 / MSW software, downloaded to the\r\ncontroller over the TriStation protocol, stored in Flash and then loaded into SRAM or DRAM (depending on the\r\nTricon version) to be executed by the Main Processor module. The control program is translated from one of the\r\nIEC 61131-3 languages (LD, FBD, ST) into native PowerPC machine code and interfaces only with the main\r\nprocessor.\r\nShortly after the incident was disclosed, the TRITON framework and payloads were found to be publicly available\r\nfrom multiple sources. The payload files (eg. imain.bin) contain PowerPC shellcode and from this we can infer\r\nthat the target Triconex controllers in the incident seem to have been using the Tricon 3008 Main Processor\r\nModules. Since older Tricon MPs such as the 3006 or 3007 would use the 32-bit National Semiconductor 32GX32\r\nand newer ones such as the 3009 use a (reportedly ARM) dual-core 32-bit processor running at 800MHz, the 3008\r\nare the only Tricon MPs (to our knowledge) which use the PowerPC architecture. More specifically they use the\r\n32-bit Freescale PowerQUICC MPC860EN microcontroller, a detail which will be relevant when dissecting the\r\nshellcode payloads later on.\r\nThe Tricon 3008 MP runs the Enhanced Triconex System Executive (ETSX) firmware (stored in flash) which\r\nexecutes the control program on the main processor. On older Tricon MP modules firmware updates had to take\r\nplace by manually replacing EPROMs made accessible through cutouts in module side panel but on the Tricon\r\n3008 firmware can be upgraded over Ethernet through the port on the front panel. This can be done by connecting\r\nthe Ethernet port to a workstation PC running the TcxFwm.exe firmware manager. The dedicated Input and Output\r\nControl and Communication (IOCCOM) processor (also an MPC860EN) runs its own firmware separate from the\r\nETSX which can be upgraded in the same fashion using the firmware manager.\r\nThe TRITON Framework\r\nhttps://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware\r\nPage 6 of 10\n\nThe rather lean TRITON framework was built to facilitate interacting with a Tricon controller via the\r\nunauthenticated TriStation protocol over Ethernet. It is capable of functionality such as reading and writing\r\ncontrol programs and data, running and halting a program and retrieving status information. The framework is\r\nwritten in Python and consists of the following components:\r\nTS_cnames.py: contains named lookup constants for TriStation protocol function and response codes as\r\nwell as key switch and control program states.\r\nTsHi.py: the high-level interface of the framework which allows for reading and writing functions and\r\nprograms as well as retrieving project information and interaction with the implant payload (as described\r\nlater). Most interestingly, it includes the SafeAppendProgramMod function which fetches the program\r\ntable, reads programs and functions and appends supplied shellcode to an existing control program. It also\r\nhandles CRC32 checksums where necessary.\r\nTsBase.py: acts as a translation layer between the high-level interface and the low-level TriStation function\r\ncodes and data formatting for functionality such as uploading and downloading of programs or fetching\r\ncontrol program status and module versions.\r\nTsLow.py: the lowest layer which implements the functionality to send TriStation packets crafted by the\r\nupper layers to the Tricon Communication Module (TCM) over UDP. Also includes auto-discovery of\r\nTricon controllers by sending an UDP 'ping' broadcast message (0x06 0x00 0x00 0x00 0x00 0x88) on port\r\n1502.\r\nFinally, apart from the framework there is a script named script_test.py which uses the framework to connect to a\r\nTricon controller and inject a multi-stage payload described later on.\r\nThe TriStation Protocol\r\nThe TriStation protocol is a typical UDP-based serial-over-ethernet protocol as encountered throughout the world\r\nof industrial control systems. Request packets consist of a 2-byte function code (FC) followed by a counter ID,\r\nlength field and request data together with checksums. Responses consist of a response code (RC), length field,\r\nresponse data and checksums.\r\nWhile we will not exhaustively document the TriStation protocol as reconstructed from the TRITON framework\r\nhere, the 'heart' of the TRITON attack lies in the following sequence of function codes and expected response\r\ncodes:\r\n'Start download change' (FC: 0x01). Expects 'Download change permitted' (RC: 0x66). Arguments are\r\n`[old_name] [version info] [new_name] [program info]`.\r\n'Allocate program' (FC: 0x37). Expects 'Allocate program response' (RC: 0x99). Arguments are `[id] [next]\r\n[full_chunks] [offset] [len] [data]`.\r\n'End download change' (FC: 0x0B). Expects 'Modification accepted' (RC: 0x67).\r\nApart from that the following TriStation command is used to communicate with the implant after it has been\r\nsuccessfully injected:\r\n'Get MP status' (FC: 0x1D). Expects 'Get system variables response' (RC: 0x96). Arguments are `[cmd]\r\n[mp] [data]`.\r\nhttps://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware\r\nPage 7 of 10\n\nInterestingly, the TriStation Developer's Guide mentions it is possible to restrict access to a Tricon controller from\r\na TriStation PC.Projects themselves can be 'password protected' (though in practice this often comes down to a\r\nhashed or even plaintext password stored in the project file which the workstation software checks upon opening\r\nthe project) and a password can be required for connecting to the controller (which is specified in the project and\r\ntakes effect after it has been downloaded to the controller). Such a password is not present initially and by default\r\nthe password is 'PASSWORD'. Seeing as how the TriStation protocol itself is unencrypted, however, any attacker\r\ncapable of observing network traffic between the controller and workstation is likely to be able to circumvent such\r\na protection.\r\nThe developer's guide also mentions that model 4351A and 4352A TCMs allow for IP-based client access control\r\nlists to be specified which regulate access to a resource (ability to perform download change or download all,\r\naccess to diagnostic information, etc.) at a certain level (deny, read only or read/write). It seems that this\r\nfunctionality could potentially be used to restrict from what IP addresses the TRITON framework could inject its\r\npayload or communicate with the implant but the strength of such a workaround would rely on mitigating the\r\nability of the attacker to move laterally among engineering workstations. UDP IP spoofing could also be a\r\nproblem here.\r\nThe Payload\r\nThe payload used in the incident can be thought of as a four-stage shellcode. The first stage is an argument-setting\r\npiece of shellcode. The second stage is formed by inject.bin (which is currently not publicly available) which\r\nfunctions as an implant installer. The third stage is formed by imain.bin (discussed below) which functions as a\r\nbackdoor implant capable of receiving and executing the fourth stage. The final stage would have been formed by\r\nan actual 'OT payload' performing the disruptive operations but apparently no such payload was recovered during\r\nthe incident since the attacker was discovered while preparing the implant. A high-level description of the first two\r\nstages can be found in the United States Department of Homeland Security ICS-CERT report on\r\nTRITON/TRISIS/HatMan.\r\nStage 1: Argument-Setter (PresetStatusField)\r\nAfter connecting to the target controller the script calls PresetStatusField which injects a piece of shellcode using\r\nSafeAppendProgramMod. What this shellcode does is iterate through memory from address 0x800000 to\r\n0x800100 (in DRAM) until it finds an address where two 32-bit marker values 0x400000 and 0x600000 reside\r\nside-by-side. If it finds this, it writes a value (0x00008001) to offset 0x18 from this address. We reverse-engineered and created a cleaned-up pseudo-c for this shellcode:\r\nThis shellcode writes the attacker-supplied value into the 'fstat' field of the Control Program (CP) Status structure.\r\nThis is followed by a TriStation request for the CP status and a check to see whether the returned value equals the\r\nsupplied value. The value in question (0x00008001) is used as an argument by the second-stage inject.bin\r\nshellcode.\r\nStage 2: Implant Installer (inject.bin)\r\nhttps://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware\r\nPage 8 of 10\n\nSince inject.bin has not been publicly released, we will limit our discussion here to what has been published by\r\nother parties and can be inferred from the publicly available materials. Based on these resources it is our\r\nconjecture that inject.bin is an implant installer which relocates the imain.bin implant backdoor to part of the\r\nEnhanced Triconex System Executive (ETSX) in order to allow for attacker read/write/execute access to safety\r\ncontroller memory regardless of the Tricon key switch position.\r\nAfter the argument-setting shellcode has been injected, inject.bin and imain.bin are injected using\r\nSafeAppendProgramMod. It is interesting to note here that imain.bin is sandwiched between two markers (0x1234\r\nand 0x56789A) and length fields. The ICS-CERT report mentions inject.bin assumes the argument written by the\r\nfirst stage payload resides at a static address and uses it as 1) a countdown for the number of cycles to idle 2) a\r\nstep counter to track and control execution progress and 3) a field for writing debug information upon failure. In\r\nthis way the attacker can monitor inject.bin for problems. If no problems are detected 'Script SUCCESS' is output\r\nand a dummy program containing nothing but a system_call(-1); is forcefully appended.\r\n           inject.bin control-flow (source)\r\nThe inject.bin shellcode has the above flowchart (courtsey of the ICS-CERT report) and seems to be a finite state\r\nmachine which starts by waiting for a number of cycles before issuing a number of system calls and checking their\r\nresults. If these checks are passed, the imain.bin shellcode is relocated and the function pointer of the 'get main\r\nprocessor diagnostic data' TriStation command is changed to the address of the relocated imain.bin so that it is\r\nexecuted prior to the normal handler.\r\nAs Reid Wightman noted, inject.bin seems to contain egg-hunter functionality hunting for the 0x1234 and\r\n0x56789A 'eggs' surrounding imain.bin. This is probably due to a lack of control by the TriStation functionality\r\nunderlying SafeAppendProgramMod in determining where the injected code ends up which would require a piece\r\nof GetPC code to determine where inject.bin currently lives and a subsequent egghunt to determine where any\r\nhttps://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware\r\nPage 9 of 10\n\nother injected code or data lives if one cannot be sure offsets remain static upon injection. After this information is\r\nknown to inject.bin it can safely relocate imain.bin.\r\nStage 3: Backdoor Implant (imain.bin)\r\nThe third stage shellcode, imain.bin, is a backdoor implant which allows an attacker to have read/write/execute\r\naccess to safety controller memory regardless of the Tricon key switch position or any reset of control programs\r\nby the engineering workstation. This would allow an attacker to inject and execute a disruptive 'OT payload' at a\r\nlater moment. It is currently unclear whether the backdoor would persist across a safety controller reboot as it\r\nseems to modify the in-memory copies of the control program and firmware rather than their on-flash copies. The\r\nFireEye report mentions that they patched the attacker script to allow for in-memory persistence of the payload\r\nbut this seems unrelated to cross-reboot persistence.\r\nIt is executed before the actual handler for the TriStation 'get main processor diagnostic data' command and looks\r\nfor a specifically crafted packet body from which it extracts a command value and its arguments. It supports three\r\ncommands: reading and writing from and to memory as well as executing code at an arbitrary address. It is\r\ncapable of making non-persistent changes to the running firmware by disabling address translation, writing to it\r\nand then flushing the instruction cache and re-enabling address translation.\r\nThe TRITON framework can communicate with the implant over the aforementioned channel by using the\r\nTsHi.ExplReadRam(Ex), TsHi.ExplWriteRam(Ex) and TsHi.ExplExec functions which utilize the\r\nTsBase.ExecuteExploit function. The latter function send a TriStation 'get main processor diagnostic data'\r\ncommand with a crafted packet body of the form:\r\n[command (1 byte)] [MP (1 byte)] [field_0 (4 bytes)] [field_1 (4 bytes)] [field_2 (N bytes)]\r\nWe reverse-engineered the imain.bin implant and manually reconstructed the following approximation in pseudo-C:\r\nStage 4: Missing OT Payload\r\nIn order to affect operations beyond a mere process shutdown (ie. the dreaded cyber-physical damage scenario), a\r\nfourth-stage 'OT payload' causing or facilitating a safety failure would be required. As mentioned before, however,\r\nit was claimed no OT payload was recovered during the incident. The absence of an OT payload on the\r\ncompromised engineering workstation could imply it would have been dropped later after initial safety controller\r\nimplantation tests had passed. It is conceivable an attacker would want to make sure multiple safety controllers\r\nwere properly implanted and working before activating a possibly complicated (collection of) OT payload(s). But\r\nit's also possible the attacker hadn't started to develop a proper OT payload yet while they were already implanting\r\nthe controllers. Regardless, any assessment of the attacker's end game under these conditions remains speculative.\r\nSource: https://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware\r\nhttps://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia",
		"MITRE"
	],
	"references": [
		"https://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware"
	],
	"report_names": [
		"analyzing-the-triton-industrial-malware"
	],
	"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": "5cbf6c32-482d-4cd2-9d11-0d9311acdc28",
			"created_at": "2023-01-06T13:46:38.39927Z",
			"updated_at": "2026-04-10T02:00:02.958273Z",
			"deleted_at": null,
			"main_name": "ENERGETIC BEAR",
			"aliases": [
				"BERSERK BEAR",
				"ALLANITE",
				"Group 24",
				"Koala Team",
				"G0035",
				"ATK6",
				"ITG15",
				"DYMALLOY",
				"TG-4192",
				"Crouching Yeti",
				"Havex",
				"IRON LIBERTY",
				"Blue Kraken",
				"Ghost Blizzard"
			],
			"source_name": "MISPGALAXY:ENERGETIC BEAR",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434406,
	"ts_updated_at": 1775791969,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/623022af8f5b6f0e1776a3e28b4767079a135bfc.pdf",
		"text": "https://archive.orkl.eu/623022af8f5b6f0e1776a3e28b4767079a135bfc.txt",
		"img": "https://archive.orkl.eu/623022af8f5b6f0e1776a3e28b4767079a135bfc.jpg"
	}
}