{
	"id": "ab63c971-ac8a-4fdb-8696-3225c5536551",
	"created_at": "2026-04-06T00:07:34.761416Z",
	"updated_at": "2026-04-10T03:33:20.055143Z",
	"deleted_at": null,
	"sha1_hash": "a4e2328f703b7818a1c057ae1e9e1ccdab11f9ea",
	"title": "It’s Parliamentary: KeyBoy and the targeting of the Tibetan Community - The Citizen Lab",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1027652,
	"plain_text": "It’s Parliamentary: KeyBoy and the targeting of the Tibetan Community\r\n- The Citizen Lab\r\nArchived: 2026-04-05 12:55:37 UTC\r\nKey Findings\r\nIn this report we track a malware operation targeting members of the Tibetan Parliament over August and October\r\n2016.\r\nThe operation uses known and patched exploits to deliver a custom backdoor known as KeyBoy.\r\nWe analyze multiple versions of KeyBoy revealing a development cycle focused on avoiding basic antivirus\r\ndetection.\r\nThis operation is another example of a threat actor using “just enough” technical sophistication to exploit a target.\r\nIntroduction\r\nThe Tibetan community has been targeted for over a decade by espionage operations that use malware to infiltrate\r\ncommunications and gather information. They are often targeted simultaneously with other ethnic minorities and religious\r\ngroups in China. Examples as early as 2008 document  malware operations against Tibetan non-governmental organizations\r\n(NGOs) that also targeted Falun Gong and Uyghur groups. More recently in 2016, Arbor Networks reported on connected\r\nmalware operations continuing to target these same groups, which the Communist Party of China perceives as a threat to its\r\npower.\r\nThese types of operations have multiple components, each with their own associated costs to the operator. There is the\r\nexploit code and malware used to gain access to systems, the infrastructure that provides command and control to the\r\nmalware operator, and the human elements – developers who create the malware, operators who deploy it, and analysts who\r\nextract value from the stolen information.\r\nWe anticipate that operators will attempt to balance the amount of information they expect to gather with the operational\r\ncosts and risks of deploying different strategies and technologies. For example, in deploying a particular malware implant\r\nagainst a target the operator will balance the likelihood and cost of discovery with the perceived value of extracting\r\ninformation from that target. If a toolkit is exposed inadvertently, the target may increase defenses and the operator will have\r\nto spend more time and resources on development.\r\nCivil society groups, due to their generally limited technical capacity and lack of security expertise and countermeasures,\r\nshift the risk/reward ratio in ways favourable to the malware operator. For example, we have observed frequent reuse of\r\nolder (patched) exploits in malware operations against the Tibetan community. Up-to-date operating systems and software\r\nwould block these threats, but the operators have probably discovered through experience that the their targets\r\nhave unpatched systems and a general lack of security controls beyond antivirus programs. The continued use of old exploits\r\nis a cost reduction strategy: since they still work, there is little need to use more expensive exploits.\r\nMoreover, many of the malware defenses used by the Tibetan diaspora involve individuals recognizing signs of a malicious\r\nemail, such as exhortations to open attachments. This kind of behavioral strategy pushes the operators to change their social\r\nengineering tactics, but does not provide pressure to radically change their toolkits. This situation is different from a\r\ntechnical-indicator based institutional security environment. In practice, minimal code changes sufficient to bypass\r\nsignature-based security controls such as antivirus may be all that are necessary.\r\nThis report analyzes an operation targeting members of the Tibetan Parliament. The actors used a new version of “KeyBoy,”\r\na custom backdoor first disclosed by researchers at Rapid7 in June 2013. Their work outlined the capabilities of the\r\nbackdoor, and exposed the protocols and algorithms used to hide the network communication and configuration data.\r\nWe observed operations in August and October 2016, shortly after an order in June to demolish the Larung Gar Buddhist\r\nAcademy and days before organized protests on October 19 around the same issue. These operations involved highly\r\ntargeted email lures with repurposed content and attachments that contained an updated version of KeyBoy. We assess that\r\nKeyBoy is the product of a development cycle that is iterated only as much as necessary to ensure the survival of the implant\r\nagainst antivirus detection and basic security controls.\r\nThis report is divided into two parts:\r\nPart 1: The Parliamentarian Operation Analyzes an operation targeting the members of the Tibetan Parliament by\r\nrepurposing legitimate content, and documents implanted with Keyboy.\r\nPart 2: KeyBoy – Tracking Evolution Examines the KeyBoy development cycle revealing a focus on avoiding basic\r\nantivirus detection.\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 1 of 18\n\nTo assist other researchers, we include appendices and indicators of compromise that detail the KeyBoy samples we\r\nanalyzed and provide an in-depth analysis of some features of the most recent implant.\r\nPart 1: The Parliamentarian Operation\r\nIn August and October 2016 we observed a malware operation targeting members of the Tibetan Parliament (the highest\r\nlegislative organ of the Tibetan government in exile, formally known as Central Tibetan Administration). We collected two\r\nemails sent to Parliamentarians that rapidly repurposed legitimate content in an attempt to entice recipients to open\r\nmalicious documents. The first attempt leveraged an old vulnerability in the parsing of Rich-text-format ( .rtf ) files\r\n(CVE-2012-0158). The second attempt used a newer, but also patched, .rtf vulnerability (CVE-2015-1641). Both\r\nattempts used versions of KeyBoy and shared the same command and control infrastructure as well as other configuration\r\ndetails.\r\nAttempt 1\r\nOn August 25, 2016, members of the Tibetan Parliament received an email with information on an upcoming conference\r\nrelevant to the Tibetan community. This email had the same subject and attachment as a legitimate message sent to the same\r\nrecipients just 15 hours prior, but in this case the attachment was crafted to exploit a frequently targeted vulnerability in\r\nMicrosoft Office. The accompanying malware was a backdoor implant designed to surveil the computers of the\r\nParliamentarians. This malicious attachment used the original, legitimate filename as a decoy (see: Figure 1).\r\nThis level of targeting and re-use of a legitimate document sent only hours before shows that the actors behind the operation\r\nare closely watching the Tibetan community, and may have already compromised the communications of one or more of the\r\nParliamentarians.\r\nDocument name:  theme of the conference.doc\r\nMD5:  8307e444cad98b1b59568ad2eba5f201\r\nOpening the attachment (an apparently blank document) in Microsoft Word would result in the infection of the target system\r\nwith the KeyBoy implant.\r\nThe Infection Chain\r\nThe email attachment is a .rtf document containing a dropper, delivered using an exploit designed to leverage CVE-2012-0158, a vulnerability in the way that Microsoft Word handles .rtf files. Over the past four years, this vulnerability\r\nhas been consistently used in malware campaigns against the Tibetan community despite having been patched since April\r\n2012.\r\nIf the exploit is successful, the following infection chain (see: Figure 2) is observed on the system.\r\nThe files in this infection chain are outlined below. The exploit launches an executable ‘dropper’ component which is\r\nresponsible for placing the malware payload and its configuration file on disk, and finally for launching the main malware\r\ncode.\r\nNote that the dropper and the final (DLL) payload were compiled within seconds of each other.\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 2 of 18\n\nName:  dw20.exe\r\nSize:  256512 bytes\r\nCompile Time:  09 May 2016 08:41:26 UTC\r\nMD5:  0b4d45db323f68b465ae052d3a872068\r\nSHA256:  5f24a5ee9ecfd4a8e5f967ffcf24580a83942cd7b09d310b9525962ed2614a49\r\nPurpose: dropper binary, used to install and execute the main implant\r\nName:  wab32res.exe\r\nSize:  46080 bytes\r\nCompile Time:  13 April 2008 18:30:52 UTC\r\nMD5:  8f08609e4e0b3d26814b3073a42df415\r\nSHA256:  58105e9772f6befbc319c147a97faded4fbacf839947b34fe3695ae72771da5d\r\nPurpose: legitimate Microsoft Windows Address Book executable, used to load final payload\r\nName:  wab32res.dll\r\nSize:  138240 bytes\r\nCompile Time:  09 May 2016 08:41:05 UTC\r\nMD5:  495adb1b9777002ecfe22aaf52fcee93\r\nSHA256:  9a55577d357922711ab0821bf5379289293c8517ae1d94d48c389f306af57a04\r\nPurpose: malware payload, launched by wab32res.exe via DLL search order hijacking\r\nNext, the dropper places a renamed copy of the legitimate Windows Address Book executable, along with the malware\r\nbinary, wab32res.dll , in the Local Application Data directory. Notably, the dropper modifies the timestamps of the\r\nconfiguration file and the payload to match those of the MicrosoftSystemCertificatesMy directory within the user’s Local\r\nApplication Data directory. Once these files are written to disk, the dropper starts the Windows Address Book executable\r\nwhich loads and executes the malicious wab32res.dll file via DLL search-order hijacking.\r\nAttempt 2\r\nOn October 11, 2016, the Tibetan Parliamentarians received an email with content repurposed from a Tibetan activism\r\ncampaign protesting the demolition of a Buddhist monastery in Tibet. The email was sent from the same email address as the\r\nprevious attempt ( tibetanparliarnent[@]yahoo.com ) and appears to copy content from the Facebook page of a Tibetan\r\nNGO promoting the campaign. The message urges recipients to open an attached .rtf file with further details on the\r\ncampaign (see: Figure 3).\r\nDocument name:  urgent action larung gar buddhist academy.rtf\r\nMD5:  913b82ff8f090670fc6387e3a7bea12d\r\nOpening the attachment (an apparently blank document) in Microsoft Word would, similar to the first attempt, result in the\r\ninfection of the target system with the KeyBoy implant.\r\nThe Infection Chain\r\nThe .rtf document attached to the malicious email was designed to exploit a more recent vulnerability: CVE-2015-1641.\r\nIf successful, this exploit launches a newer version of the same malware used in the August attempt outlined above, using a\r\nsimilar infection chain.\r\nName: n/a\r\nSize:  262144 bytes\r\nCompile Time:  29 September 2016 00:46:11 UTC\r\nMD5:  23d284245e53ae4fe05c517d807ffccf\r\nSHA256:  542c85fda8df8510c1b66a122e459aac8c0919f1fe9fa2c43fd87899cffa05bf\r\nPurpose:dropper binary, used to install and execute the main implant\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 3 of 18\n\nName:  wab32res.exe\r\nSize:  46080 bytes\r\nCompile Time:  13 April 2008 18:30:52 UTC\r\nMD5:  8f08609e4e0b3d26814b3073a42df415\r\nSHA256:  58105e9772f6befbc319c147a97faded4fbacf839947b34fe3695ae72771da5d\r\nPurpose:legitimate Microsoft Windows Address Book executable, used to load final payload\r\nName:  wab32res.dll\r\nSize:  143872 bytes\r\nCompile Time:  29 September 2016 00:21:34 UTC\r\nMD5:  087bffa8a570079948310dc9731c5709\r\nSHA256:  5da2f14c382d7cac8dfa6c86e528a646a81f0b40cfee9611c8cfb4b5d589aa88\r\nPurpose:malware payload, launched by wab32res.exe via DLL search order hijacking\r\nAs with the first attempt, the resulting dropper installs the malware payload into the Local Application Data directory as\r\nwab32res.dll and subsequently launches it using the same method of DLL search-order hijacking against the legitimate\r\nWindows Address Book executable.\r\nA Note on Vulnerabilities\r\nThe two .rtf vulnerabilities targeted in these exploitation attempts, CVE-2012-0158 and CVE-2015-1641, are among a\r\nset of four .rtf vulnerabilities discussed in recent reporting from researchers at Arbor Networks.\r\nThe researchers describe the presumed existence of an exploit document ‘builder’ designed to selectively weaponize .rtf\r\nfiles using four older, patched, vulnerabilities: CVE-2012-0158, CVE-2012-1856, CVE-2015-1641, and CVE-2015-1770.\r\nThe Arbor report describes the ongoing use of these four vulnerabilities in a series of espionage campaigns against not only\r\nTibetan groups, but also others related to Hong Kong, Taiwan, and Uyghur interests. While we have not connected the\r\ncampaign targeting the Tibetan Parliamentarians to the campaigns described by Arbor, the continual pairing of these older\r\n.rtf vulnerabilities with malware operations against the Tibetan community is noteworthy.\r\nThe Malware\r\nThe malware samples deployed in both of these operations are updated versions of the KeyBoy backdoor first discussed in\r\n2013 by Rapid7. KeyBoy provides basic backdoor functionality, allowing the operators to select from various capabilities\r\nused to surveil and steal information from the victim machine.\r\nKeyBoy functionality:\r\nGather system information, including details of the operating system, processor, disk, memory, display, and uptime\r\n(see: Figure 4)\r\nUpload files to the victim computer\r\nDownload files from the victim computer\r\nBrowse the file system, including gathering details about attached drives\r\nExecute commands and applications\r\nLaunch interactive shell\r\nThese updated versions of KeyBoy make use of an encoded configuration file to store their command and control (C2)\r\ninformation along with other required settings. In both cases, the dropper wrote this configuration file in the user’s Local\r\nApplication Data directory as win32res.dat . After analyzing these malware samples, we were able to decode the following\r\nconfiguration parameters, presented in Table 1\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 4 of 18\n\nLine Description First sample Second sample\r\nLine\r\n1\r\nIdentity code, used to ensure config was correctly\r\ndecoded\r\n9876543210 9876543210\r\nLine\r\n2\r\nC2 Server #1 (hostname/ip) 45.125.12[.]147 45.125.12[.]147\r\nLine\r\n3\r\nC2 Server #2 (hostname/ip) 103.40.102[.]233 45.125.12[.]147\r\nLine\r\n4\r\nC2 Server #3 (hostname/ip) 45.125.12[.]147 45.125.12[.]147\r\nLine\r\n5\r\nPort used with C2 Server #1 443 443\r\nLine\r\n6\r\nPort used with C2 Server #2 443 443\r\nLine\r\n7\r\nPort used with C2 Server #3 443 443\r\nLine\r\n8\r\nPassword for operator login tibetwoman tibetwoman\r\nLine\r\n9\r\nCampaign ID, transmitted to C2 during login NNNN NNNN\r\nTable 1\r\nDecoded configuration parameters from both KeyBoy samples observed in the Parliamentarian operation\r\nA full description of the new algorithm used by KeyBoy to decode its configuration file is presented in Appendix A.\r\nOnce the KeyBoy DLL has been executed, it validates that a particular string value (likely identifying the KeyBoy version)\r\nis set in the Windows Registry.\r\nKey\r\nFirst\r\nsample\r\nSecond\r\nsample\r\nHKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet\r\nSettingsZonemapVer\r\n20160509 agewkassif\r\nAdditionally, these versions of KeyBoy ensure persistence by setting the wab32res.exe file to be loaded upon login via\r\nexploiting the Winlogon Shell key, which in turn loads the malicious wab32res.dll file by the aforementioned DLL\r\nsearch-order hijacking method.\r\nKey Value\r\nHKEY_CURRENT_USERSoftwareMicrosoftWindows\r\nNTCurrentVersionWinlogonShell\r\nexplorer.exe,\r\n“C:users\u003cuser\u003eAppDataLocalwab32res.exe”\r\nThe backdoor then sends a login beacon to the C2 server which, once decoded, looks like:\r\n*a*\r\nUSER-PC\r\n192.168.100.101\r\nNNNN\r\n2016/09/13 16:11:56\r\n20160509\r\nThese values are described as follows in Table 2:\r\nValue from Example Description\r\n*a* Data header code for initial check-in beacon\r\nUSER-PC %computername% of victim PC\r\n192.168.100.101 IP address of victim PC\r\nNNNN Campaign ID from the KeyBoy configuration file\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 5 of 18\n\n2016/09/13 16:11:56 Timestamp of local PC\r\n20160509 Internal version identifier\r\nTable 2\r\nDescriptions of the login beacon values\r\nThis login data, as well as all other communication between backdoor and command and control server, is transmitted using\r\nan encoding mechanism based on principles from modular arithmetic. We describe this network communication encoding in\r\ndetail in this supplementary document.\r\nAs can be seen in the login event example above, when sending data to the C2, the KeyBoy implant uses a series of header\r\n‘codes’ to specify the type of data which is being transmitted, described in Table 3:\r\nHeader code Data being transmitted\r\n*l* Heartbeat / Keepalive\r\n*a* Initial check-in beacon\r\n*s* System information (drive info, system specifications, interface info)\r\n*d* Data from remote commands and shell\r\n*f* Data relating to interactions via File Manager\r\n*g* Ready to initiate file download\r\n*h* Ready to initiate file upload or update\r\nTable 3\r\nKeyBoy header codes for sending data to the C2 server\r\nThe Infrastructure\r\nThe command and control (C2) servers used in the Tibetan Parliament operation were extracted from the KeyBoy\r\nconfiguration files:\r\nC2 Host:\r\n45.125.12[.]147\r\nDesc: Royal Network Technology\r\nCo\r\nCity:\r\nGuangzhou\r\nCountry:\r\nChina\r\nNo relevant data or passive DNS information was available\r\nC2 Host:\r\n103.40.102[.]233\r\nDesc:\r\nDragon\r\nNetwork\r\nInt’l Co.\r\nLtd\r\nCity: Hong\r\nKong\r\nCountry:\r\nHong\r\nKong\r\nDomain: tibetvoices[.]com\r\nHost\r\nFirst\r\nSeen:\r\nLast Seen:\r\n127.0.0.1\r\n2016-09-\r\n29\r\nCurrent as of\r\npublication\r\n103.40.102[.]233\r\n2016-07-\r\n15\r\n2016-09-28\r\n112.10.117[.]47\r\n2016-05-\r\n25\r\n2016-05-26\r\nHost\r\nFirst\r\nSeen:\r\nLast\r\nSeen:\r\n127.0.0.1\r\n2016-\r\n09-29\r\nCurrent as\r\nof\r\npublication\r\n103.40.102[.]233\r\nHost\r\nFirst\r\nSeen:\r\nLast Seen:\r\n127.0.0.1\r\n2016-\r\n09-29\r\nCurrent as\r\nof\r\npublication\r\n103.40.102[.]233\r\n2016-\r\n07-15\r\n2016-09-\r\n28\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 6 of 18\n\n112.10.117[.]47\r\n2016-\r\n05-25\r\n2016-05-\r\n26\r\nWe uncovered very little information about the command and control (C2) infrastructure used in this operation. The\r\nconfiguration files referenced hard-coded IP addresses for the C2 servers, as opposed to using domain names as was seen in\r\nprior KeyBoy campaigns.\r\nPassive DNS analysis revealed one domain, tibetvoices[.]com , which was briefly pointed to one of the C2 server IP\r\naddresses found in the KeyBoy configuration file used in the first attempt against the Parliamentarians. This domain was\r\ncreated in May 2016 (around the time that the KeyBoy sample used in the first attempt was compiled) and was pointed to IP\r\naddress 103.40.102[.]233 from July 15 to September 28. Subsequently, this domain was pointed to 127.0.0.1 ,\r\neffectively taking it offline.\r\nThis behavioural tactic was previously mentioned in relation to KeyBoy in a 2013 blog post by Cisco. Cisco hypothesized\r\nthat the actors behind KeyBoy may have been nullifying the DNS records when an active campaign was not underway, in an\r\nattempt to stay “below the radar”. This tactic allows the malware operator to ensure that no command and control traffic will\r\nbe sent out from the infected system, thus preventing detection via network monitoring.\r\nThis tactic, however plausible, would not apply to the KeyBoy samples we analyzed, as the C2 configuration relied upon\r\nhard coded IP addresses and did not directly reference the tibetvoices[.]com domain. It is possible that a different\r\ncampaign was launched which used this domain, but we were unable to find any evidence of such a campaign.\r\nOur analysis provides a cursory look at some of the capabilities and implementation details of the KeyBoy backdoor as used\r\nduring a malware operation targeting Tibetan Parliamentarians. These versions of KeyBoy differed from the one first\r\ndescribed by Rapid7 in several ways, many of which will be described in the sections to follow.\r\nDuring our research into this operation we were able to uncover two additional samples of KeyBoy which were likely used\r\nin previous malware campaigns. These samples were contained in exploit documents containing distinct lure content, one\r\nhaving a Tibetan nexus, the other an Indian nexus.\r\nIn Part 2 we present a brief overview of the observable evolution of KeyBoy based upon all of the samples we obtained.\r\nPart 2: KeyBoy – Tracking Evolution\r\nPeriodic updates are common in the world of software development. Features are added and removed, bugs are patched, and\r\ncode is written to execute more efficiently. The same holds true for malicious software, but with the additional requirement\r\nthat the development cycle must always satisfy the operational need for covertness. To be effective, malicious software\r\ndesigned for surveillance must remain undetected. Malware developers are in a constant struggle to avoid the security\r\ncontrols that protect target systems.\r\nWe believe the 2013, 2015, and 2016 KeyBoy samples provide evidence of a development effort focused on changing\r\ncomponents that would be used by researchers to develop detection signatures. This section outlines how we came to this\r\nconclusion.\r\nIn building our KeyBoy chronology, we collected several samples and examined three data points from each:\r\nThe compile time of the KeyBoy binary\r\nA string observed in the KeyBoy binary we refer to as the ‘version identifier’\r\nElapsed time between compile time and the time of first exposure\r\nAnalysis of these data points gave us a moderate to high level of confidence that the binary compile times provided a\r\nreliable estimate of the true development timeline.\r\nAn Evolving Implant\r\nIn an effort to understand its evolution, we compared the code of several versions of KeyBoy as identified by their ‘version\r\nidentifier’ strings, shown in Table 4:\r\nVersion Identifier Notes\r\nProxy 20130401 Reported by Rapid7 in relation to an Indian nexus\r\nProxy 20130401 Reported by Rapid7 in relation to a Vietnamese nexus\r\nP_20150313 Discovered via hunting; carried Indian lure content\r\n20151108 Discovered via hunting; carried Tibetan lure content\r\n20160509 First sample of the Parliamentarian operation from August 2016\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 7 of 18\n\n20160509 An alternate sample, using different configuration data\r\nagewkassif Second sample of the Parliamentarian operation from October 2016\r\nTable 4\r\nVersion identifier strings analyzed\r\nThe ‘version identifier’ is a particular string that appeared in every KeyBoy sample we studied. It is transmitted to the\r\ncommand and control server as part of the login data packet, and, in recent versions, this identifier is written to the Windows\r\nregistry in a key named ‘Ver’. With the exception of the newest (chronologically speaking) KeyBoy version we discovered,\r\nthis identifier always contained a date-like component which matched the compile date of the KeyBoy binary in every case.\r\nIn the newest sample, the developers replaced this date-like string with a seemingly random set of letters.\r\nA timeline depicting these KeyBoy versions, along with some important characteristics, is shown in Figure 5.\r\nNoteworthy Modifications\r\nThis section describes some of the most significant changes observed across the KeyBoy versions. Each of these\r\ncomponents would have been an ideal target for signature-based identification, using either static string or network packet-based detection mechanisms.\r\nHeader Code Evolution\r\nOf the changes we identified one stands out as being an immediate target for an effective antivirus signature – the evolution\r\nof header codes used during communication between the implant and command and control server. As shown in Table 5,\r\nthese codes changed substantially after the 2013 KeyBoy samples were examined and publically documented by Rapid7. It\r\nis reasonable to hypothesize that this significant change in format was in response to the publication of Rapid7’s research.\r\n2013 Early 2015 Late 2015 2016\r\n$login$ #l# *a* *l*\r\n$sysinfo$ #s# *s* *a*\r\n$shell$ #e# *d* *s*\r\n$fileManager$ #f# *f* *d*\r\n$fileDownload$ #D# *g* *f*\r\n$fileUpload$ #U# *h* *g*\r\n      *h*\r\nTable 5\r\nHeader codes used by KeyBoy during C2 communication\r\nIn addition, modifying these codes produced a downstream change in the appearance of the network communication traffic\r\nproduced by an active KeyBoy infection. This change would likely have rendered existing network based signatures\r\nineffective.\r\nConfiguration File Changes\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 8 of 18\n\nAnother major change we first observed in version P_20150313 is the complete redesign of the algorithm used to encode\r\nthe KeyBoy configuration file. In the 2013 samples described by Rapid7, this configuration file was encoded using a\r\nsimplified static-key based algorithm. This newer encoding algorithm is significantly more involved, removing the use of a\r\nstatic encryption key in favour of a dynamically constructed lookup table. We provide a detailed explanation of this new\r\nalgorithm in Appendix A.\r\nPersistence Changes\r\nThe method used by the implant for maintaining persistence was also changed several times. The earlier versions used a\r\nWindows service to ensure the malware stayed persistent, moving to a more commonly seen tactic of setting the Run key\r\nin the Windows registry in the early 2015 sample. This method changed again in late 2015 when the implant migrated from\r\nthe Run key to using a less frequently observed registry key: WinlogonShell . This key stores the list of executables which\r\nare to be run once a Windows GUI session is created, and typically holds only the standard user shell, explorer.exe .\r\nString Obfuscation\r\nIn another modification, first observed in the most recent October 11 Parliamentarian operation (version agewkassif ), the\r\ndeveloper(s) of KeyBoy began using a string obfuscation routine in order to hide many of the critical values referenced\r\nwithin the malware. This introduction of string obfuscation also suggests a development change aimed at evading detection.\r\nThe header codes, filename references, and all of the operator commands were obfuscated and only decoded during\r\nexecution of the KeyBoy DLL. Figure 6 shows a sampling of these strings, after decoding.\r\nEvidence of Modularity\r\nFinally, there were numerous changes observed that could suggest that KeyBoy was being deployed using a modular or\r\ncomponent based mechanism. The GetUp export which is linked to the browser credential theft capability seems to be\r\npresent in some samples and not others, even for versions within the same development stage. As well, the inconsistent use\r\nof a dropper binary during infection is further evidence supporting the modular component theory.\r\nAdditional Details\r\nBeyond the main modifications outlined above, numerous smaller changes were also observed, many of which are described\r\nin Table 6 below.\r\nVersion\r\nIdentifier\r\nKey Changes\r\nProxy\r\n20130401\r\nPersistence handled via Windows service\r\nOne sample contained the ‘GetUP’ export, the other did not\r\nUsed full word header codes encapsulated by $ symbols, such as $login$\r\nP_20150313\r\nAdopts new algorithm for config file encoding\r\nRetained browser credential theft module\r\nMoved to persistence via Run key\r\nHeader codes shift to #-encapsulation\r\nDeployed without use of dropper binary\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 9 of 18\n\n20151108\r\nContinues use of new config encoding algorithm\r\nMigrated to use of WinLogon key for persistence\r\nInstallation now conducted via VBS scripts\r\nAdopted multi-byte strings internally and in C2 communication\r\nHeader codes move to *-encapsulation\r\n64 bit version distributed inside 32 bit payload\r\nNo evidence of browser credential module\r\nDeployed using dropper binary\r\n20160509\r\nContinues use of new config encoding algorithm\r\nAdded AutoUpdate/Upload \u0026 Execute function\r\nDeployed using dropper binary\r\nHeader codes retain *-encapsulation, new ‘keep-alive’ code, *l*\r\nExecution via DLL search-order hijacking of legitimate Windows application\r\nVBS script traces still present, but no longer used\r\nNo 64bit version embedded\r\nagewkassif\r\nFunctionally identical to 20160509 sample\r\nContinues use of new config encoding algorithm\r\nRemoved date string from version identifier\r\nAdded static string obfuscation code. Strings used for C2 commands, header\r\ncodes, and more are now decoded at runtime\r\nTable 6\r\nChanges observed between successive versions of KeyBoy\r\nAdditional technical details relating to several of the KeyBoy samples described in this section are provided in Appendix B.\r\nConnecting KeyBoy to Other Operations\r\nIn their Operation Tropic Trooper report, Trend Micro documented the behaviour and functionality of an espionage toolkit\r\nwith several design similarities to those observed in the various components of KeyBoy. Trend Micro specifically noted that\r\nthe 2013 versions of KeyBoy used the same algorithm for encoding their configuration files as was observed in the\r\nOperation Tropic Trooper malware.\r\nThis connection may offer another explanation for the significant change in the configuration file encoding algorithm we\r\ndescribed in relation to KeyBoy. If KeyBoy is a single component of a larger espionage toolkit, the developers may have\r\nrealized that this older, static-key based, configuration encoding algorithm was inadvertently providing a link between\r\ndisparate components of their malware suite.\r\nA Note on Samples\r\nWe were not able to locate a large sample set for KeyBoy. Though we discussed the development timeline, we have limited\r\ninsight into the victims targeted by each of these samples. We cannot conclude that all are being deployed by the same\r\ngroup. We provide YARA signatures and encourage anyone who can provide additional samples or context to contact us.\r\nRecent Tibetan Protests\r\nThe harm of malware operations against the Tibetan community is well-documented, and this latest campaign is no\r\nexception. Examining the lure content sent to the Tibetan Parliamentarians sheds light on the oppression faced by the\r\nTibetan community. On October 19, over 180 Tibetan groups protested the ongoing demolitions of the Larung Gar Buddhist\r\nAcademy, the largest Tibetan Buddhist institute in the world.\r\nThe demolitions stem from an order issued by Chinese authorities in June 2016, according to a joint statement issued by\r\nTibet groups on the date of protest. According to the same joint statement, the order from Chinese authorities said the\r\ncommunity was in need of “ideological guidance” from the Chinese state. In conjunction with the demolitions, residents are\r\nbeing forcefully removed from Larung Gar. To date, the forced removals have led to to the suicide of three resident nuns.\r\nThe Communist Party of China views the Tibetan movement as a threat to its rule, alongside Uyghur, Falun Gong, advocates\r\nfor an independent Taiwan and Hong Kong, and members of the democracy movement. Surveilling the highest governing\r\nbody of the Central Tibetan Administration aligns with the overall interests of the government of China. However,\r\nconnecting the malware development ecosystem and the flow of stolen information to a state-actor is an elusive task. With\r\nthe data available we are unable to conclusively connect the Parliamentarian Operation to any specific actor or nation-state.\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 10 of 18\n\nConclusions\r\nRecent Citizen Lab reports have documented a trend away from the use of attachment-based malware operations targeting\r\nthe Tibetan Diaspora. These changes may reflect malware operators shifting tactics in response to changes in the community,\r\nincluding education campaigns encouraging Tibetans not to use email attachments, or perhaps also by more sophisticated\r\nattachment scanning by popular email providers.\r\nThe operation against the Tibetan Parliamentarians illustrates the continued use of malicious attachments in the form of\r\ndocuments bearing exploits. These exploits, while older, were used to deliver a malware payload which shows signs of a\r\nsystematic technical adaptation designed to reduce the likelihood of signature based detection.\r\nThe developers of KeyBoy have made the minimum necessary technical changes required to avoid detection by signature-based antivirus, and yet retained “old” exploits because they likely continue to work their targets.\r\nFor a community lacking an adequate level of human and financial resources, deployment of commercial (i.e.: non-free)\r\nantivirus solutions, updated releases of common office productivity software, and even software patches may be out of\r\nreach. Under such conditions, the use of exploits against older, patched, vulnerabilities becomes yet another iteration of an\r\nactor using “just enough” sophistication to successfully exploit a target.\r\nThe operation against the Parliamentarians yields a clear example of this tactic. When the August operation failed to fully\r\ncompromise the target group, the operators redeployed in October using a slightly newer, but still well-known and patched,\r\nexploit.\r\nAs we observe the evolution of strategies levied against the Tibetan Diaspora, the constant cat-and-mouse game embroiling\r\nthis community becomes evident. While some behavioural adaptations have shown promise in reducing the threat, the\r\noperation against the Tibetan Parliament underscores the need for continued diligence and security awareness.\r\nAcknowledgments\r\nSpecial thanks to Tibet Action Institute. Additional thanks to Jakub Dalek, PassiveTotal, VirusTotal, and TNG.\r\nAppendix A: Decoding KeyBoy Config\r\nRecent versions of KeyBoy maintain encoded configuration data inside a file stored on disk. In the 20160509 sample used\r\nin the Tibetan Parliament campaign, this file was named wab32res.dat . The configuration file contains a 16 byte header\r\nfollowed by a number of bytes which are encoded using a novel algorithm. The 16 byte header stores an ascii character\r\nrepresentation of the hexadecimal values corresponding to the size (in bytes) of the decoded config data, followed by the\r\nnumber of bytes containing encoded configuration data.\r\nThe sample under examination contained the following header, and Figure 7 shows the raw configuration file:\r\nSize of config (in bytes) once decoded Number of bytes in encoded config\r\nThe configuration file used by this malware is encoded using what appears to be a custom schema. While some earlier\r\nversions of this backdoor used more simplified encoding techniques for the configuration data, newer versions have adopted\r\na more involved algorithm.\r\nAt the heart of the decoding function is the use of a dynamically constructed lookup table containing sequences of bytes\r\nwhich represent the ASCII characters for the cleartext configuration data.\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 11 of 18\n\nAt the outset of the decoding function, a base lookup table is created containing 256 entries. This initial table can be thought\r\nof as an identity matrix, where, for each index, the lookup table contains the index as the stored value (see: Figure 8). For\r\nexample:\r\nLookupTable[0x0] → 0x0\r\nLookupTable[0x1] → 0x1\r\n⋮   ⋮\r\nLookupTable[0xFF] → 0xFF\r\nDuring the decoding of the configuration file, this table is expanded dynamically. Each iteration of the algorithm will\r\npopulate the lookup table sequentially, beginning with index 0x102 (since the table index 0x101 is reserved).\r\nAlgorithm Walkthrough\r\nThe algorithm has three basic steps:\r\n1. Obtain an index by decoding a value from the configuration file\r\n2. Find the value in the lookup table corresponding to this index, and place this result in the memory buffer holding\r\ndecoded configuration data\r\n3. Generate a new value and insert it into the lookup table at the next available index\r\nStep 1\r\nThis step requires the algorithm to obtain an index value from the configuration file. In order to obtain this index, a decoding\r\nfunction evaluates the data in the configuration file not as successive bytes, but as a series of integers calculated by\r\nconsidering consecutive sequences of 9-bit binary values.\r\nFigure 9 provides a visual representation of this process. We can see that the first few indices being calculated by this\r\ndecoder are hexadecimal values 0x100, 0x39, 0x38, and 0x37. The first value, 0x100, is a ‘marker’ which denotes the\r\nbeginning of the configuration data. The values 0x39, 0x38, and 0x37 are the first three indices used to obtain data from the\r\nlookup table.\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 12 of 18\n\nStep 2\r\nAs mentioned above, the first 256 entries in the lookup table are created as an identity matrix, and thus the result of lookups\r\nfor 0x39,0x38,0x37 would be:\r\nLookupTable[ 0x39 ] = 0x39 =\u003e “9” (ascii)\r\nLookupTable[ 0x38 ] = 0x38 =\u003e “8” (ascii)\r\nLookupTable[ 0x37 ] = 0x37 =\u003e “7” (ascii)\r\nThese values are then stored in memory as decoded bytes of configuration data.\r\nStep 3\r\nAfter each iteration of calculating an index (step 1) and then obtaining the corresponding value from the lookup table (step\r\n2), the algorithm will create a new entry in the lookup table at the next available index. The format of this new lookup table\r\nentry is simply the concatenation of the results of the previous lookup with the first byte of the current lookup (see: Figure\r\n10).\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 13 of 18\n\nSo, again using the same example bytes along with Figures 9 and 10 above, if the current iteration of the algorithm decoded\r\nthe value 0x34 in step 1, and thus retrieved the value 0x34 = ‘4’ in step 2, the newly formed lookup table entry would be:\r\nLookupTable[ 0x106 ] = [0x35,0x34] =\u003e “54”\r\nThus, if at some future point in the decoding process the index 0x106 was obtained in step 1, the output to the configuration\r\ndata would be the two bytes [0x35,0x34] which have ascii representation “54”. This provides a method of data compression\r\nto the configuration file.\r\nA Python script was created for the purpose of automating this configuration file decoding process. The output of this script\r\nwhen run against the configuration file used by the first of the two Parliamentarian operation samples yielded the following\r\ndata:\r\nIdentity Code: 9876543210\r\nC2 Host/IP #1: 45.125.12.147\r\nC2 Host/IP #2: 103.40.102.233\r\nC2 Host/IP #3: 45.125.12.147\r\nC2 Port #1: 443\r\nC2 Port #2: 443\r\nC2 Port #3: 443\r\nPassword: tibetwoman\r\nCampaign ID: NNNN\r\nAppendix B: KeyBoy Samples\r\nVersion: P_20150313\r\nExploit Document:  05b5cf94f07fee666eb086c91182ad25\r\nPayload:  0c7e55509e0b6d4277b3facf864af018\r\nDLL Exports\r\nEmbedding 0x1000bfb0\r\nGetUP 0x1000c940\r\nSSSS 0x1000bc60\r\nStartWork 0x1000c570\r\nSvcMain 0x1000c430\r\nInstallation\r\nThis sample was discovered inside a malicious PowerPoint slide show which carried lure content consistent with an Indian-nexus, and which was uploaded to VirusTotal in April 2015 using the filename athirappalli.pps . Athirappilly is a village\r\nin India known for its wildlife and waterfalls. The visual contents of the slide show are images of waterfalls, presumably\r\nfrom this village. This malicious .pps file was weaponized using (closely related to CVE-2014-4114 aka Sandworm,\r\nwhich we have previously observed this exploit used against the Tibetan community) to execute the following embedded\r\nDLL:\r\nName:  SystemCertificates.ocx\r\nSize:  495616 bytes\r\nCompile Time:  13 Mar 2015 03:05:34 UTC\r\nMD5:  0c7e55509e0b6d4277b3facf864af018\r\nSHA256:  5395f709ef1ca64c57be367f9795b66b5775b6e73f57089386a85925cc0ec596\r\nPersistence\r\nThis DLL maintains persistence by setting the following registry entry in the\r\nHKCUSoftwareMicrosoftWindowsCurrentVersionRun key: SystemCertificates → \"cmd /c start Run dll32.exe\r\n%APPDATA%MicrosoftSystemCertificatesSystemCertificates.ocx, SSSS\r\nThis registry key is set via the Sandworm exploit, as the execution of an .inf file containing the following instructions are\r\ntriggered:\r\n[DefaultInstall]\r\nCopyFiles = RxCopy\r\nAddReg = RxStart\r\n[RxCopy]\r\n….RoamingMicrosoftSystemCertificatesSystemCertificates.ocx, contact.pdf\r\n[RxStart]\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 14 of 18\n\nHKCU,SoftwareMicrosoftWindowsCurrentVersionRun,SystemCertificates,,”cmd /c start Rundll32.exe\r\n%APPDATA%MicrosoftSystemCertificatesSystemCertificates.ocx, SSSS”\r\nIn comparison with the prior generation of KeyBoy examined by Rapid7, this mechanism represents a change to registry\r\nbased persistence from the previously used Windows service.\r\nConfiguration\r\nUsing the algorithm presented in Appendix A, we were able to decode the configuration file used by this sample. Once\r\ndecoded, the following information was obtained:\r\nIdentity Code: IJUDHSDJFKJDE\r\nC2 Host/IP #1: www.about.jkub[.]com\r\nC2 Host/IP #2: www.eleven.mypop3[.]org\r\nC2 Host/IP #3: www.backus.myftp[.]name\r\nC2 Port #1:80\r\nC2 Port #2:80\r\nC2 Port #3:443\r\nPassword:wariii\r\nCampaign ID:war\r\nInfrastructure\r\nC2 Host: www.about.jkub[.]com Desc: Dynamic DNS provided by changeip.com\r\nHost First Seen: Last Seen:\r\n175.213.49[.]6 2016-10-25 Current as of publication\r\n45.32.47[.]148 2016-09-26 2016-10-24\r\n157.7.84[.]81 2015-04-07 2015-04-21\r\nC2 Host: www.eleven.mypop3[.]org Desc: Dynamic DNS provided by changeip.com\r\nHost First Seen: Last Seen:\r\n175.213.49[.]6 2016-10-25 Current as of publication\r\n45.32.47[.]148 2016-09-26 2016-10-24\r\nC2 Host: www.backus.myftp[.]name Desc: Dynamic DNS\r\nHost First Seen: Last Seen:\r\n192.241.149[.]43 2015-05-05 Current as of publication\r\nVersion: 20151108\r\nExploit Document:  8846d109b457a2ee44ddbf54d1cf7944\r\nDropper:  8846d109b457a2ee44ddbf54d1cf7944\r\nPayload:  c5b5f01ba24d6c02636388809f44472e\r\nEmbedded 64bit:  371bc132499f455f06fa80696db0df27\r\nPayload DLL Exports\r\nInstall 0x100085a0\r\nSSSS 0x100081e0\r\nStartWork 0x100086a0\r\nSvcMain 0x10008fb0\r\ncfsUpdate 0x10008cb0\r\nInstallation\r\nThis .rtf document, also exploiting CVE-2012-0158, was submitted to VirusTotal in March 2016. The exploit triggers the\r\nexecution of an embedded dropper, similar to the method observed in our initial sample described in Part 1.\r\nThis dropper creates three files on disk, each in the %localappdata% folder:\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 15 of 18\n\n1. cfs.dat – KeyBoy configuration file\r\n2. cfsupdate.dal – KeyBoy payload DLL\r\n3. desk.vbs – Windows script used for installation\r\nThe Windows script file, desk.vbs, contained the following content:\r\nThe dropper executes this script file which subsequently launches the KeyBoy backdoor and sets persistence as described\r\nbelow.\r\nAlso noteworthy in this sample was the fact that this payload inspected the architecture of the victim PC to determine if it\r\nwas 64 bit capable. If so, a 64 bit version of the payload was decoded from the data section of the cfsupdate.dat file using an\r\nXOR operation having key 0x90. This is very similar to the method described by Trend Micro in their report on the\r\nTROJ_YAHOYAH malware.\r\nInterestingly, the 64-bit module was packed using a known freeware binary packer. This is in contrast to the 32-bit versions\r\nof KeyBoy, none of which contained any binary protections whatsoever. Upon unpacking, the 64-bit version of this KeyBoy\r\ncode was functionally identical to the 32-bit version.\r\nLeftover Code\r\nFurther illustrating the continued development and connections between samples are the leftover remnants from 20151108\r\nexisting in the 20160509 Parliamentarian sample. The Parliamentarian dropper contained references to the Desk.vbs\r\nscript described above, yet this file and related content was not deployed or otherwise used in the 20160509 version.\r\nPersistence\r\nPersistence is achieved through the WinLogonShell registry key, and is installed by the dropper’s execution of the Install\r\nexport from the KeyBoy DLL. This export creates the file %localappdata%Desktop.ini as shown below, and installs it by\r\nlaunching the Windows regini.exe command:\r\nHKEY_CURRENT_USERSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon\r\nshell = explorer.exe,C:Windowssystem32rundll32.exe “%LOCALAPPDATA%cfs.dal” cfsUpdate\r\nConfiguration\r\nThe configuration file used by this version of KeyBoy is written to disk as %localappdata%cfs.dat by the dropper, similar\r\nto the behaviour of our 20160509 sample. This configuration file uses the newer encoding method outlined above and in\r\nAppendix A. Once decoded, the following information was obtained:\r\nIdentity Code: 9876543210\r\nC2 Host/IP #1: 103.242.134[.]243\r\nC2 Host/IP #2: 103.242.134[.]243\r\nC2 Host/IP #3: 103.242.134[.]243\r\nC2 Port #1: 443\r\nC2 Port #2: 1234\r\nC2 Port #3: 1234\r\nPassword: password8888\r\nCampaign ID: MyUser\r\nPossible Targeting\r\nThis malicious document embedded an empty decoy document to hide the exploitation of the vulnerability. We found\r\nhowever another interesting sample with the exact same payload but with a decoy document presenting a petition to release\r\na Tibetan activist:\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 16 of 18\n\nInfrastructure\r\nThis sample communicates with the following command and control server:\r\nC2 Host:  103.242.134[.]243\r\nCity:  Hanshan\r\nCountry:  China\r\nVersion: 20160509 (alternate)\r\nExploit Document:  beadf21b923600554b0ce54df42e78f5\r\nDropper:  0b4d45db323f68b465ae052d3a872068\r\nPayload:  495adb1b9777002ecfe22aaf52fcee93\r\nPayload DLL Exports\r\nSSSS 0x100080b0\r\nSvcMain 0x10008b80\r\ncfsUpdate 0x10008880\r\nDuring our research we encountered another sample of the 20160509 version of KeyBoy. This sample was also found to be\r\ndeployed using the CVE-2012-0158 vulnerability. The malware payload was identical to our first Parliamentary sample\r\noutlined in Part 1, however the configuration file in this alternate sample was different.\r\nConfiguration\r\nIdentity Code: 9876543210\r\nC2 Host/IP #1: 116.193.154[.]69\r\nC2 Host/IP #2: 116.193.154[.]69\r\nC2 Host/IP #3: 116.193.154[.]69\r\nC2 Port #1:443\r\nC2 Port #2:80\r\nC2 Port #3:443\r\nPassword:8888\r\nCampaign ID:8888\r\nPossible Targeting\r\nThe exploit document carrying this alternate KeyBoy configuration also used a decoy document which was displayed to the\r\nuser after the exploit launched. This decoy carries content with a Tibetan nexus.\r\nInfrastructure\r\nC2 Host: 116.193.154[.]69\r\nCNAME: 116-193-154-69.pacswitch.net\r\nAppendix D: IOCs and Links\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 17 of 18\n\nKeyBoy binaries\r\nagewkassif: 087bffa8a570079948310dc9731c5709\r\n20160509: 495adb1b9777002ecfe22aaf52fcee93\r\nP_20150313: 0c7e55509e0b6d4277b3facf864af018\r\n20151108 (32bit): c5b5f01ba24d6c02636388809f44472e\r\n20151108 (64bit): 371bc132499f455f06fa80696db0df27\r\nDroppers\r\n0b4d45db323f68b465ae052d3a872068\r\n23d284245e53ae4fe05c517d807ffccf\r\n98977426d544bd145979f65f0322ae30\r\nExploit Documents\r\n8307e444cad98b1b59568ad2eba5f201 (used in August Parliamentary campaign)\r\n913b82ff8f090670fc6387e3a7bea12d (used in October Parliamentary campaign)\r\n05b5cf94f07fee666eb086c91182ad25\r\n8846d109b457a2ee44ddbf54d1cf7944\r\nbeadf21b923600554b0ce54df42e78f5\r\nC2 Hosts\r\nwww.about.jkub[.]com\r\nwww.eleven.mypop3[.]org\r\nwww.backus.myftp[.]name\r\ntibetvoices[.]com\r\n103.242.134[.]243\r\n116.193.154[.]69\r\n103.40.102[.]233\r\n45.125.12[.]147\r\nResources\r\nKeyboy Network Communication Encoding Details\r\nConfiguration File Decoder\r\nC2 Decoder\r\nYARA Signatures\r\nIndicators of Compromise\r\nSource: https://citizenlab.ca/2016/11/parliament-keyboy/\r\nhttps://citizenlab.ca/2016/11/parliament-keyboy/\r\nPage 18 of 18\n\nconsidering consecutive Figure 9 provides sequences of a visual representation 9-bit binary values. of this process. We can see that the first few indices being calculated by this\ndecoder are hexadecimal values 0x100, 0x39, 0x38, and 0x37. The first value, 0x100, is a ‘marker’ which denotes the\nbeginning of the configuration data. The values 0x39, 0x38, and 0x37 are the first three indices used to obtain data from the\nlookup table.     \n  Page 12 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia",
		"MITRE"
	],
	"references": [
		"https://citizenlab.ca/2016/11/parliament-keyboy/"
	],
	"report_names": [
		"parliament-keyboy"
	],
	"threat_actors": [
		{
			"id": "61ea51ed-a419-4b05-9241-5ab0dbba25fc",
			"created_at": "2023-01-06T13:46:38.354607Z",
			"updated_at": "2026-04-10T02:00:02.939761Z",
			"deleted_at": null,
			"main_name": "APT23",
			"aliases": [
				"BRONZE HOBART",
				"G0081",
				"Red Orthrus",
				"Earth Centaur",
				"PIRATE PANDA",
				"KeyBoy",
				"Tropic Trooper"
			],
			"source_name": "MISPGALAXY:APT23",
			"tools": [],
			"source_id": "MISPGALAXY",
			"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": "bef7800a-a08f-4e21-b65c-4279c851e572",
			"created_at": "2022-10-25T15:50:23.409336Z",
			"updated_at": "2026-04-10T02:00:05.319608Z",
			"deleted_at": null,
			"main_name": "Tropic Trooper",
			"aliases": [
				"Tropic Trooper",
				"Pirate Panda",
				"KeyBoy"
			],
			"source_name": "MITRE:Tropic Trooper",
			"tools": [
				"USBferry",
				"ShadowPad",
				"PoisonIvy",
				"BITSAdmin",
				"YAHOYAH",
				"KeyBoy"
			],
			"source_id": "MITRE",
			"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": "578f8e62-2bb4-4ce4-a8b7-6c868fa29724",
			"created_at": "2022-10-25T16:07:24.344358Z",
			"updated_at": "2026-04-10T02:00:04.947834Z",
			"deleted_at": null,
			"main_name": "Tropic Trooper",
			"aliases": [
				"APT 23",
				"Bronze Hobart",
				"Earth Centaur",
				"G0081",
				"KeyBoy",
				"Operation Tropic Trooper",
				"Pirate Panda",
				"Tropic Trooper"
			],
			"source_name": "ETDA:Tropic Trooper",
			"tools": [
				"8.t Dropper",
				"8.t RTF exploit builder",
				"8t_dropper",
				"ByPassGodzilla",
				"CHINACHOPPER",
				"CREDRIVER",
				"China Chopper",
				"Chymine",
				"Darkmoon",
				"Gen:Trojan.Heur.PT",
				"KeyBoy",
				"Neo-reGeorg",
				"PCShare",
				"POISONPLUG.SHADOW",
				"Poison Ivy",
				"RoyalRoad",
				"SPIVY",
				"ShadowPad Winnti",
				"SinoChopper",
				"Swor",
				"TSSL",
				"USBferry",
				"W32/Seeav",
				"Winsloader",
				"XShellGhost",
				"Yahoyah",
				"fscan",
				"pivy",
				"poisonivy"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "86182dd7-646c-49c5-91a6-4b62fd2119a7",
			"created_at": "2025-08-07T02:03:24.617638Z",
			"updated_at": "2026-04-10T02:00:03.738499Z",
			"deleted_at": null,
			"main_name": "BRONZE HOBART",
			"aliases": [
				"APT23",
				"Earth Centaur ",
				"KeyBoy ",
				"Pirate Panda ",
				"Red Orthrus ",
				"TA413 ",
				"Tropic Trooper "
			],
			"source_name": "Secureworks:BRONZE HOBART",
			"tools": [
				"Crowdoor",
				"DSNGInstaller",
				"KeyBoy",
				"LOWZERO",
				"Mofu",
				"Pfine",
				"Sepulcher",
				"Xiangoop Loader",
				"Yahaoyah"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434054,
	"ts_updated_at": 1775792000,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a4e2328f703b7818a1c057ae1e9e1ccdab11f9ea.pdf",
		"text": "https://archive.orkl.eu/a4e2328f703b7818a1c057ae1e9e1ccdab11f9ea.txt",
		"img": "https://archive.orkl.eu/a4e2328f703b7818a1c057ae1e9e1ccdab11f9ea.jpg"
	}
}