{
	"id": "e32cdce4-4e14-495d-9672-53eacaea1c19",
	"created_at": "2026-04-06T00:09:06.612555Z",
	"updated_at": "2026-04-10T13:13:05.409855Z",
	"deleted_at": null,
	"sha1_hash": "91b0f1cc0c9de6ed0a08f421b67c7506b57b4239",
	"title": "TRITON Actor TTP Profile, Custom Attack Tools, Detections, and ATT\u0026CK Mapping",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 850431,
	"plain_text": "TRITON Actor TTP Profile, Custom Attack Tools, Detections, and\r\nATT\u0026CK Mapping\r\nBy Mandiant\r\nPublished: 2019-04-10 · Archived: 2026-04-05 21:34:30 UTC\r\nWritten by: Steve Miller, Nathan Brubaker, Daniel Kapellmann Zafra, Dan Caban\r\nOverview\r\nFireEye can now confirm that we have uncovered and are responding to an additional intrusion by the attacker\r\nbehind TRITON at a different critical infrastructure facility.\r\nIn December 2017, FireEye publicly released our first analysis on the TRITON attack where malicious actors used\r\nthe TRITON custom attack framework to manipulate industrial safety systems at a critical infrastructure facility\r\nand inadvertently caused a process shutdown. In subsequent research we examined how the attackers may have\r\ngained access to critical components needed to build the TRITON attack framework. In our most recent analysis,\r\nwe attributed the intrusion activity that led to the deployment of TRITON to a Russian government-owned\r\ntechnical research institute in Moscow.\r\nThe TRITON intrusion is shrouded in mystery. There has been some public discussion surrounding the TRITON\r\nframework and its impact at the target site, yet little to no information has been shared on the tactics, techniques,\r\nand procedures (TTPs) related to the intrusion lifecycle, or how the attack made it deep enough to impact the\r\nindustrial processes. The TRITON framework itself and the intrusion tools the actor used were built and deployed\r\nby humans, all of whom had observable human strategies, preferences, and conventions for the custom tooling of\r\nthe intrusion operation. It is our goal to discuss these adversary methods and highlight exactly how the\r\ndeveloper(s), operator(s) and others involved used custom tools in the intrusion.\r\nIn this report we continue our research of the actor’s operations with a specific focus on a selection of custom\r\ninformation technology (IT) tools and tactics the threat actor leveraged during the early stages of the targeted\r\nattack lifecycle (Figure 1). The information in this report is derived from multiple TRITON-related incident\r\nresponses carried out by FireEye Mandiant.\r\nUsing the methodologies described in this post, FireEye Mandiant incident responders have uncovered additional\r\nintrusion activity from this threat actor – including new custom tool sets – at a second critical infrastructure\r\nfacility. As such, we strongly encourage industrial control system (ICS) asset owners to leverage the indicators,\r\nTTPs, and detections included in this post to improve their defenses and hunt for related activity in their networks.\r\nFor IT and operational technology (OT) incident response support, please contact FireEye Mandiant. For more in-depth analysis of TRITON and other cyber threats, consider subscribing to FireEye Cyber Threat Intelligence.\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 1 of 12\n\nFireEye’s SmartVision technology, which searches for attackers during lateral movement activities by monitoring\r\neast-west traffic in IT and OT networks, reduces the risk of an attack reaching sensitive ICS processes. This is\r\nparticularly relevant for sophisticated ICS-related intrusions as attackers typically move from corporate IT to OT\r\nnetworks through systems that are accessible to both environments, far beyond perimeter defenses.\r\nContents\r\nTools and TTPs\r\nHunting for ICS-focused threat actors across IT and OT\r\nMethodology and discovery strategies\r\nAppendix A: Discovery Rules\r\nAppendix B: Technical Analysis of Custom Attack Tools\r\nAppendix C: MITRE ATT\u0026CK JSON Raw Data\r\nIndicators of Compromise\r\nFigure 1: The FireEye targeted attack lifecycle\r\nActor Leveraged a Variety of Custom and Commodity Intrusion Tools\r\nThroughout the targeted attack lifecycle, the actor leveraged dozens of custom and commodity intrusion tools to\r\ngain and maintain access to the target's IT and OT networks. A selection of the custom tools that FireEye\r\nMandiant recovered are listed later in this post in Table 1, and hashes are listed in Table 2 at the end of this post.\r\nDiscovery rules for and technical analysis of these tools, as well as MITRE ATT\u0026CK JSON raw data, is available\r\nin Appendix A, Appendix B, and Appendix C.\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 2 of 12\n\nFigure 2: Selection of custom tools used by the actor\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 3 of 12\n\nThe actor's custom tools frequently mirrored the functionality of commodity tools and appear to be developed\r\nwith a focus on anti-virus evasion. The group often leveraged custom tools when they appeared to be struggling\r\nwith anti-virus detection or were at a critical phase in the intrusion (e.g., they switched to custom backdoors in IT\r\nand OT DMZ right before gaining access to the engineering workstation). In some instances, the actor leveraged\r\ncustom and commodity tools for the same function. For example, they used Mimikatz (public) and SecHack\r\n(custom) for credential harvesting; both tools provide a very similar output (Figure 2).\r\nFigure 3: Default outputs for Mimikatz (left) and SecHack (right)\r\nTools and TTPs Indicate a Deep Interest in Ensuring Prolonged and Persistent Access to the Target\r\nEnvironment\r\nThe targeted attack lifecycle of a sophisticated ICS attack is often measured in years. Attackers require a long time\r\nto prepare for such an attack in order to learn about the target’s industrial processes and build custom tools. These\r\nattacks are also often carried out by nation states that may be interested in preparing for contingency operations\r\nrather than conducting an immediate attack (e.g., installing malware like TRITON and waiting for the right time to\r\nuse it). During this time, the attacker must ensure continued access to the target environment or risk losing years\r\nof effort and potentially expensive custom ICS malware. This attack was no exception. The actor was present in\r\nthe target networks for almost a year before gaining access to the Safety Instrumented System (SIS) engineering\r\nworkstation. Throughout that period, they appeared to prioritize operational security.\r\nAfter establishing an initial foothold on the corporate network, the TRITON actor focused most of their effort on\r\ngaining access to the OT network. They did not exhibit activities commonly associated with espionage, such as\r\nusing key loggers and screenshot grabbers, browsing files, and/or exfiltrating large amounts of information. Most\r\nof the attack tools they used were focused on network reconnaissance, lateral movement, and maintaining\r\npresence in the target environment.\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 4 of 12\n\nThe actor used multiple techniques to hide their activities, cover their tracks, and deter forensic examination of\r\ntheir tools and activities.\r\nThey renamed their files to make them look like legitimate files, for example, KB77846376.exe, named\r\nafter Microsoft update files.\r\nThey routinely used standard tools that would mimic legitimate administrator activities. This included\r\nheavy use of RDP and PsExec/WinRM.\r\nWhen planting webshells on the Outlook Exchange servers, they modified already existing legitimate\r\nflogon.js and logoff.aspx files.\r\nThey relied on encrypted SSH-based tunnels to transfer tools and for remote command/program execution.\r\nThey used multiple staging folders and opted to use directories that were used infrequently by legitimate\r\nusers or processes.\r\nThey routinely deleted dropped attack tools, execution logs, files staged for exfiltration, and other files\r\nafter they were finished with them.\r\nThey renamed their tools' filenames in the staging folder so that it would not be possible to identify the\r\nmalware's purpose, even after it was deleted from the disk through the residual artifacts (e.g., ShimCache\r\nentries or WMI Recently Used Apps).\r\nThey used timestomping to modify the $STANDARD_INFORMATION attribute of the attack tools.\r\nOnce the actor gained access to the targeted SIS controllers, they appeared to focus solely on maintaining access\r\nwhile attempting to successfully deploy TRITON. This involved strategically limiting their activities to mitigate\r\nthe risk of being discovered.\r\nThe actor gained a foothold on the distributed control system (DCS) but did not leverage that access to\r\nlearn about plant operations, exfiltrate sensitive information, tamper with the DCS controllers, or\r\nmanipulate the process.\r\nThey then gained access to an SIS engineering workstation. From this point forward, they focused most of\r\ntheir effort on delivering and refining a backdoor payload using the TRITON attack framework.\r\nThey attempted to reduce the chance of being observed during higher-risk activities by interacting with\r\ntarget controllers during off-hour times. This would ensure fewer workers were on site to react to potential\r\nalarms caused by controller manipulation.\r\nThey renamed their files to make them look like legitimate files, for example, trilog.exe, named after a\r\nlegitimate Schneider Electric application.\r\nOperational Since At Least 2014\r\nBased on analysis of the actor’s custom intrusion tools, the group has been operating since as early as 2014. It is\r\nworth noting that FireEye had never before encountered any of the actor's custom tools, despite the fact that many\r\nof them date to several years before the initial compromise. This fact and the actor's demonstrated interest in\r\noperational security suggests there may be other target environments – beyond the second intrusion announced in\r\nthis blog post – where the actor was or still is present.\r\nA sample of a Cryptcat-based backdoor used to establish the initial foothold was recovered during the\r\ninvestigation; the sample was compiled and uploaded to a malware testing environment by the actor in\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 5 of 12\n\n2014.\r\nCryptcat- and PLINK-based backdoors were scheduled to execute daily starting from April 28, 2014, using\r\nProgramDataUpdater and NetworkAccessProtectionUpdateDB tasks. This date is unrelated to the observed\r\nintrusion timeline and may indicate the date the threat actors first created these persistence mechanisms.\r\nNetExec.exe, a custom lateral movement and remote command execution tool, is self-titled \"NetExec 2014\r\nby OSA.\"\r\nSecHack.exe \"by OSA,\" a custom credential harvesting and reconnaissance tool, was compiled on Oct. 23,\r\n2014.\r\nThe attackers used a pirated version of Wii.exe, a public file indexing tool that came with a license from\r\n2010 and has not been updated since 2014.\r\nICS Asset Owners Should Prioritize Detection and Defense Across Windows Systems in Both IT and OT\r\nMost sophisticated ICS attacks leveraged Windows, Linux, and other traditionally \"IT\" systems (located in either\r\nIT or OT networks) as a conduit to the ultimate target. Some examples include leveraging computers to gain\r\naccess to targeted PLCs (e.g., Stuxnet), interacting directly with internet-connected human machine interfaces\r\n(HMIs) (e.g., BlackEnergy), and gaining remote access to an engineering station to manipulate a remote terminal\r\nunit (RTU) (e.g., INDUSTROYER) or infect SIS programmable logic controllers (PLC) (e.g., TRITON).\r\nDefenders who focus on stopping an attacker in these \"conduit\" systems benefit from a number of key advantages.\r\nThese advantages will only grow as IT and OT systems continue to converge.\r\nAttackers commonly leave a broad footprint in IT systems across most if not all the attack lifecycle.\r\nIt is ideal to stop an attacker as early in the attack lifecycle as possible (aka \"left of boom\"). Once an\r\nattacker reaches the targeted ICS, the potential of a negative outcome and its severity for the target increase\r\ndramatically.\r\nThere are many mature security tools, services, and other capabilities already available that can be\r\nleveraged to defend and hunt in \"conduit\" systems.\r\nLeveraging Known Tools and TTPs To Hunt For the TRITON Actor\r\nHistoric activity associated with this actor demonstrates a strong development capability for custom tooling. The\r\ndeveloper(s) behind these toolsets leaned heavily on existing software frameworks and modified them to best\r\nserve the intrusion operations. The developer(s) had preferences regarding the ports, protocols, persistence\r\nmechanisms, and other aspects of how the malware operated.\r\nWhile the preferences of the development team supporting this activity will likely shift and change over time,\r\nlearning about them is still useful to identify whether their TTPs are applicable to other malware developers and\r\nthreat actors. Additionally, the actor possibly gained a foothold on other target networks—beyond the two\r\nintrusions discussed in this post – using similar strategies. In such cases, retrospective hunting would help\r\ndefenders identify and remediate malicious activity.\r\nBased on the examination of developer(s) preferences and abstracted adversary methodologies, it is possible to\r\nbuild broader visibility of the TTPs using detection and hunting rules of various fidelity and threat density. The\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 6 of 12\n\ncompilation of these rules makes it possible to identify and classify potentially malicious samples while building\r\nnew \"haystacks\" in which to hunt for adversary activity.\r\nThe TTPs we extracted from this actor’s activities are not necessarily exclusive, nor are they necessarily malicious\r\nin every circumstance. However, the TTP profile built by FireEye can be used to search for patterns of evil in\r\nsubsets of network and endpoint activity. Not only can these TTPs be used to find evidence of intrusions, but\r\nidentification of activity that has strong overlaps with the actor's favored techniques can lead to stronger\r\nassessments of actor association, further bolstering incident response efforts.\r\nThe following table provides insights into notable methodologies surrounding the use of custom tools and tips for\r\nidentifying evidence of this and related activity. Adversary methodologies are also expressed in terms of the\r\nMITRE ATT\u0026CK framework (see Appendix C for MITRE ATT\u0026CK JSON raw data).\r\nAdversary\r\nMethodology\r\nDiscovery Tips\r\nPersistence by\r\nScheduled Tasks\r\nby XML trigger\r\nATT\u0026CK:\r\nT1053\r\nLook for new and anomalous Scheduled Tasks XML triggers referencing unsigned .exe\r\nfiles.\r\nPersistence by\r\nIFEO injection\r\nATT\u0026CK:\r\nT1183\r\nLook for modifications and new entries referencing .exe files under registry key\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\r\nNT\\CurrentVersion\\Image File Execution Options.\r\nCommand and\r\ncontrol (C2)\r\nestablished\r\nusing hard-coded DNS\r\nservers\r\nLook for PEs executions with run DNS lookups to 8.8.8.8:53. This may be applicable to\r\nsandbox and other malware processing technologies.\r\nC2 using\r\nfavored C2ports\r\nATT\u0026CK:\r\nT1043\r\nLook for outbound connections with port-protocol mismatches on common and\r\nuncommon ports such as 443, 4444, 8531, and 50501.\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 7 of 12\n\nATT\u0026CK:\r\nT1065\r\nC2 using\r\nfavored Virtual\r\nPrivate Server\r\n(VPS)\r\ninfrastructure\r\nATT\u0026CK:\r\nT1329\r\nLook for inbound and outbound connections from and to non-standard IP ranges,\r\nespecially from international VPS providers like OVH and UK-2 Limited (uk2.net).\r\nC2 domains\r\nwith hyphen\r\nLook for newly observed 2LD and 3LD domains that contain hyphens.\r\nC\u0026C using\r\ndynamic DNS\r\ndomains from\r\nafraid.org\r\nATT\u0026CK:\r\nT1311\r\nLook for newly observed dynamic DNS domains owned or registered with afraid.org.\r\nC2 domains\r\nregistered with\r\nvfemail.net\r\nemail addresses\r\nLook for newly observed domains or DNS resolutions to domains with registrant email\r\ninformation containing vfemail.net\r\nTunneled RDP\r\nusing PLINK\r\nATT\u0026CK:\r\nT1076\r\nLook for the presence of PLINK and non-standard RDP usage with event logs, firewall\r\nlogs, and registry keys as described in the FireEye blog post \"Bypassing Network\r\nRestrictions Through RDP Tunneling.\"\r\nFind internal RDP pivoting by looking for bitmap cache files under user accounts that\r\nshould not be accessing sensitive systems via RDP. Look for bitmap cache files such as\r\nbcache22.bmc under default, service, or administrator accounts or any account not\r\nexpected to be conducting internal RDP accesses to sensitive systems in a protected OT-connected zone, especially in the DMZ or DCS areas like HMIs or engineering\r\nworkstations.\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 8 of 12\n\nC2 using hard-coded SSH\r\nprivate keys\r\nLook for PEs with hard-coded OpenSSH private keys.\r\nUse of direct\r\nRDP\r\nATT\u0026CK:\r\nT1076\r\nLook for inbound RDP connections with default host information, non-standard or\r\nunexpected locale IDs, or other metadata. See also the FireEye blog post on baselining\r\nRDP activity.\r\nC2 using source\r\nsystems with\r\ndefault Windows\r\nhostnames\r\nLook for default Windows hostnames that fit the structure WIN-[A-Z0-9]{11} (e.g.,\r\nWIN-ABCDEFGH1JK) in PE certificates, SSL and SSH certificates, and RDP\r\nhandshakes.\r\nC2 using SSH\r\nLook for new, unique, or unusual SSH sessions. Logging of SSH keys and fingerprints\r\nwould quickly and easily identify an anomalous session as a result of malware. Look for\r\nSSH over non-standard ports.\r\nCompromised\r\nVPN accounts\r\nATT\u0026CK:\r\nT1078\r\nLook for VPN logon anomalies based on infeasible patterns such as source account\r\nlocation, IP address, and hostname associations. Check out the FireEye blog post and free\r\ntoolset for VPN logon analysis, GeoLogonalyzer.\r\nIf you use SMS-based MFA, look for phone numbers registered outside the country\r\nwhere your employees operate.\r\nMalware\r\nmasquerading as\r\nMicrosoft\r\nCorporation\r\nLook for PEs with mismatched PE metadata such as contains \"Bitvise\" strings and also\r\n\"Microsoft Corporation\" in the metadata. Look for unsigned \"Microsoft Corporation\"\r\nbinaries in the group's common staging directories.\r\nUse of\r\ncustomized\r\nBitvise binaries\r\nLook for PEs with Bitvise PDB path strings such as d:\\repos\\main\\ssh2\\.\r\nUse of\r\ncustomized\r\nOpenSSH\r\nbinaries\r\nLook for PEs with content \"Microsoft openSSH client.\"\r\nUse of\r\ncustomized\r\nCryptcat but\r\nLook for PEs that drop Cryptcat binaries or contain Cryptcat string content such as the\r\ndefault password \"metallica.\"\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 9 of 12\n\nwith default\r\npassword\r\nTimestomping\r\nvia PowerShell\r\nATT\u0026CK:\r\nT1099\r\nLook for timestomping command strings such as \".CreationTime=\" in PowerShell scripts\r\nor in PowerShell command-line entries. Look for PEs with NTFS creation time prior to\r\nPE compile time.\r\nDeployment of\r\nbinaries with\r\ndebug\r\ninformation\r\nfrom developer\r\nworkstations\r\nwith Visual\r\nStudio 2010\r\nLook for PEs with PDB paths containing default or generic paths such as\r\n\\Users\\user\\Documents\\Visual Studio 2010\\\r\n\\Documents\\Visual Studio 2010\\.\r\nUse of Thinstall\r\nfor packaging\r\nmalware\r\nLook for PE with content \"thinstall\\modules\\boot_loader.pdb.\" Look for Thinstall\r\nbinaries that have created virtualized files in the context of the SYSTEM user\r\n\"C:\\Windows\\SysWOW64\\config\\systemprofile\\AppData\\Roaming\\Thinstall\\.\"\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 10 of 12\n\nUse of favored\r\ndirectories for\r\noperating,\r\nstaging and\r\nexecuting files\r\nLook for new, unexpected, or otherwise anomalous binaries in the following directories:\r\nC:\\Windows\\system32\\inetsrv\\\r\nC:\\Windows\\temp\\\r\nC:\\Windows\\SysWOW64\\wbem\r\nC:\\Windows\\SysWOW64\\drivers\r\nC:\\Windows\\SysWOW64\r\nC:\\Windows\\system32\\wbem\\\r\nC:\\Windows\\system32\\drivers\\\r\nC:\\Windows\\system32\\\r\nC:\\Windows\\\r\nC:\\Users\\Public\\Libraries\\\r\nC:\\Users\\administrator\\appdata\\local\\temp\\\r\nC:\\ssh\\\r\nC:\\perflogs\\admin\\servermanager\\ssh\\\r\nC:\\perflogs\\admin\\servermanager\\\r\nC:\\perflogs\\admin\\\r\nC:\\perflogs\\\r\nC:\\cpqsystem\\\r\nC:\\hp\\hpdiags\\\r\nC:\\hp\\bin\\log\\\r\nTable 1: TRITON actor methodology and discovery strategies\r\nOutlook\r\nThere is often a singular focus from the security community on ICS malware largely due to its novel nature and\r\nthe fact that there are very few examples found in the wild. While this attention is useful for a variety of reasons,\r\nwe argue that defenders and incident responders should focus more attention on so-called \"conduit\" systems when\r\ntrying to identify or stop ICS-focused intrusions.\r\nIn an attempt to raise community awareness surrounding this actor’s capabilities and activities between 2014 and\r\n2017—an effort compounded in importance by our discovery of the threat actor in a second critical infrastructure\r\nfacility—we have shared a sampling of what we know about the group's TTPs and custom tooling. We encourage\r\nICS asset owners to leverage the detection rules and other information included in this report to hunt for related\r\nactivity as we believe there is a good chance the threat actor was or is present in other target networks.\r\nFor IT and OT incident response support, please contact FireEye Mandiant. For more in-depth analysis of\r\nTRITON and other cyber threats, consider subscribing to FireEye Cyber Threat Intelligence.\r\nFireEye’s SmartVision technology, which searches for attackers during lateral movement activities by monitoring\r\neast-west traffic in IT and OT networks, reduces the risk of an attack reaching sensitive ICS processes. This is\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 11 of 12\n\nparticularly relevant for sophisticated ICS-related intrusions as attackers typically move from corporate IT to OT\r\nnetworks through systems that were accessible to both environments, far beyond perimeter defenses.\r\nAppendices\r\nAppendix A: Discovery Rules\r\nAppendix B: Technical Analysis of Custom Attack Tools\r\nAppendix C: MITRE ATT\u0026CK JSON Raw Data\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nhttps://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.fireeye.com/blog/threat-research/2019/04/triton-actor-ttp-profile-custom-attack-tools-detections.html"
	],
	"report_names": [
		"triton-actor-ttp-profile-custom-attack-tools-detections.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434146,
	"ts_updated_at": 1775826785,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/91b0f1cc0c9de6ed0a08f421b67c7506b57b4239.pdf",
		"text": "https://archive.orkl.eu/91b0f1cc0c9de6ed0a08f421b67c7506b57b4239.txt",
		"img": "https://archive.orkl.eu/91b0f1cc0c9de6ed0a08f421b67c7506b57b4239.jpg"
	}
}