From Chrysaor, see mobile spyware

Get to know Chrysaor

Chrysaor, which is not well-known to the public, at least compared to its famous brother in iOS, is quite unfamiliar. And this brother is——Pegasus (Pegasus).

Dear Brother Pegasus

Pegasus①, as the most famous spyware in the iOS system, developed by NSO Group Technologies, used three 0day vulnerabilities at the time for attack chain construction: CVE-2016-4655, CVE-2016-4656, CVE-2016-4657. Through Safari WebKit memory leak, once the user accesses a web page with payload, the device will silently jailbreak without the user's knowledge, and the attacker can remotely control the target phone through the C/S mode.

Figure 1: Pegasus attack chain (source: LookOut team report①)

NSO Group sold it as a weapon to government departments for the purpose of eavesdropping on specific targets. The earliest Pegasus was first disclosed in August 2016, but according to news media reports, NSO Group had started operating as early as 2010. After the iOS 9.3.5 patch, the above three 0day vulnerabilities were fixed.

However, for a long time, because this attack required users to access links containing payloads through Safari, attackers often sent malicious links via SMS to the targets. With the increase in the number of attacks and the disclosure of the attack process, most devices have updated their systems, and users have become more vigilant, making it increasingly difficult to trick users into clicking on malicious links via SMS. Therefore, Pegasus shifted its target to zero-click attacks or wireless attacks.

In June to August 2020, the Pegasus family was once again found to have exploited a 0day vulnerability named KISMET that has existed since at least iOS 13.5.1. Researchers believe that KISMET has been used by Pegasus to achieve zero-click exploitation against the iMessage app. This discovery targeted a total of 36 private smartphones of journalists, producers, hosts, and senior management of Al Jazeera (Al Jazeera). These devices were attacked by four Pegasus operators, including SNEAKYKESTREL from the United Arab Emirates and MONARCHY from Saudi Arabia's Arab.

Figure 2: Timeline of an attack on July 19th in the above example

Interestingly, NSO company has repeatedly emphasized that Pegasus spyware is only used for 'investigating terrorism and crime'. However, a report from Amnesty International in July 2021④ pointed out that the Pegasus family products of the company are engaged in long-term illegal surveillance and human rights violations.

Not only iOS was affected, around August 2016, after the exposure of Pegasus, there were news reports that the weaponized products developed by NSO Group were not only aimed at iOS but also targeted Blackberry and Android platforms.

Short History of Chrysaor

Therefore, at the end of 2016, researchers began to closely monitor the weaponized spyware for Android platforms developed by NSO Group. By combining big data and cloud analysis, and through threat hunting technology, some apps that do not exist in any public market or any publicly available resources similar to VT were found. Some of the data of these apps were associated with Pegasus-specific IOC, such as signature information or package name information. In this way, researchers identified the Android version of Pegasus, and in 2017, the LookOut team released a research report, and in April of the same year, Google released a report, formally naming it: Chrysaor②.

Although Chrysaor is named officially by Google, due to the fact that it is also a mobile platform and is considered to be a weaponized spyware produced by NSO company, it will generally be classified into the Pegasus family that was exposed earlier and on a larger scale on the iOS platform even if it is threatened to be hunted and captured. Therefore, the name of this Android version of Chrysaor has almost been forgotten by people, and in most reports, Pegasus is used to refer to both iOS Pegasus and Android Chrysaor.

In the official survey released by Google, it is believed that spyware is a special form of PHA (Potentially Harmful Application, potentially harmful application), which is different from other PHA. Spyware spends a lot of effort, time, and economic costs to infiltrate high-value targets such as journalists and politicians, which fully conforms to the practice of APT. However, whether it is capturing samples or public information, there is no information about Chrysaor in recent years. In recent days, some suspected samples have also been basically diagnosed as misjudgments, so this article starts with the old version of Chrysaor, unveiling the mysterious veil of spyware. Moreover, due to the open-source nature of Android, Chrysaor did not use any 0day, but more exposed vulnerabilities, so in terms of attack cost, Chrysaor is lower than earlier disclosed Pegasus.

Chrysaor attack principle

Chrysaor, as spyware, its main function is to monitor the target device and maintain contact with the C2 server (Command & Control server), but it is noteworthy that the target of the spyware attack used as a weapon is specific, so it is customized for specific models.

For example, the sample with SHA256 value ade8bef0ac29fa363fc9afd958af0074478aef650adeb0318517b48bd996d5d5 and package name : com.network.android provided by Google is a customized malware for Samsung devices with kernel version <= 4.3. The reason for saying this will be explained in the following text.

Induced installation

Firstly, users are induced to download or wirelessly install the sample, although this step looks very untechnical, it is the most difficult part in execution, but there are also many ways to induce users to install. Please note that there is no report indicating how to do it, but assuming I am an attacker, the methods I would consider include:

1. Social engineering fraud, social engineering is often the first step in an attack, and from various cases, the success rate of social engineering is often not low.

2. Combined with other vulnerabilities. There are many possible vulnerabilities that can be exploited, and here we take one of the first that comes to mind as an example, such as CVE-2017-13156 Janus Android v1 Signature Verification Vulnerability. This vulnerability allows the EXP to pass the signature verification, which would lead to malware being installed as normal software, replacing the original normal application with an insecurely forged application containing a payload. During software upgrade installation, by intercepting an unencrypted upgrade process through a constructed insecure network channel, such as listening to a public WIFI or we基站, it can be achieved to replace the application during the upgrade process. Of course, this is just an example, and it is very idealized; the actual operation is definitely not as easy as the author said. Moreover, it seems that the sample in the public does not use this vulnerability, and this vulnerability was also discovered later in time.

The first step is also the most difficult step in the entire attack process. This means that the user needs to enable the option 'Allow installation of apps from unknown sources'. If the target of the attack is alert enough and does not enable this option, does not connect to unsecured WIFI, and so on, it will make the spyware very difficult to enter the device.

Privilege escalation

After installation on the device, Framaroot will be called immediately to elevate privileges. Framaroot is a privilege escalation tool that contains several vulnerabilities for privilege escalation, and Framaroot has supported Samsung devices since the early versions. And please note that the author of Framaroot provides short-term root to minimize the use of Framaroot by malicious software. When the system partition is modified, the root will expire.

Figure 3: Framaroot F&Q about vulnerability patching and system update

However, for ordinary users, OTA upgrade is the most common upgrade, and the privilege escalation of Framaroot is ultimately managed through SuperSU, but SuperSU can survive in OTA upgrades. However, because Framaroot uses vulnerability privilege escalation, as long as the vulnerability is fixed during the system upgrade, the privilege escalation will fail, and the malicious software that has been painstakingly implanted will be useless.

The author is also obviously very clear that if all the vulnerabilities are fixed, it will call an elevated ELF from /system/csk to elevate privileges. I'm sorry to say that I don't know what this file is, because the sample obtained does not have a complete file, the part called is not in the obtained sample, and there is no Samsung 4.3 system to verify it, so let's not talk about it. To avoid the system upgrade patching the vulnerability, after the privilege escalation is completed, the malicious program hides itself and performs the following actions:

•Install itself on the /system partition to persist after the factory reset.

•Delete the Samsung system update application (com.sec.android.fotaclient) and disable automatic updates (the method is to set Settings.System.SOFTWARE_UPDATE_AUTO_UPDATE to 0).

• Delete WAP message push and change the WAP message settings, which is speculated to be for the purpose of anti-forensics.

• Start a content observer and start the main program in a loop to receive remote commands and steal data.

As mentioned above, to prevent vulnerabilities from being fixed and to prevent sudden failure of privileges after updates, the best way is not to let the device update. Therefore, it deletes the update program, showing why it is custom software because this upgrade program is exclusive to Samsung systems.

Collecting data

After it settles down, it will start working. Chrysaor collects a lot of information, such as location, application data (including email, contacts, calendar, SMS, etc.), screenshots, keystroke records, and phone tapping.

Sets up a cyclic scheduled task through the Alarm class, which sends a large amount of information to the C2 server at regular intervals, such as location information. Moreover, in conjunction with information collection, it reads the contents under the /data/data directory of specific apps and stores them all in the message queue, which are then sent to the server regularly by the Alarm class. Monitored apps include WhatsApp, Twitter, Facebook, Kakao, Viber, Skype, and others.

Collects SMS, contacts, emails, and all changes of monitored apps through ContentObserver. When making a phone call, the malicious software keeps the connection in the background, allowing the user to make a normal call, but when trying to use the device, only a black screen can be seen because at this time, the malicious software is hanging up the call, resetting the call settings, so the user cannot interact with the device.

It will also monitor keyboard input and screen capture through lib files, which will be analyzed in detail later.

Self-deletion

For the purpose of anti-forensics, Chrysaor also has a self-deletion function that is triggered in the following three situations:

1. Instructions from the C2 server

2. Unable to connect to the C2 server within 60 days

3. The existence of the file /sdcard/MemosForNotes

Detailed analysis

Taking a captured sample from Anheng Threat Intelligence Center as an example, let's analyze the listening method of Chrysaor in detail. The SHA256 of the sample is:

bd8cda80aaee3e4a17e9967a1c062ac5c8e4aefd7eaa3362f54044c2c94db52a

Let's first take a look at the file tree structure:

Figure 4: Sample file tree

The structure displayed here is not decompiled, and it can be noticed that there is no commonly seen lib folder, but instead, there are a large number of files with dangerous names in /res/raw.

Remote Communication

MQTT

It can be found that there is a file path 'org/eclipse/paho/client/mqttv3', which is the internationalization folder path of the MQTT protocol. First, let's understand what the MQTT protocol (⑥) is.

Figure 5: MQTT

MQTT, Message Queue Telemetry Transport, a messaging queue telemetry transport protocol based on the 'publish/subscribe' model, can be used for lightweight data communication, built on the TCP/IP protocol. For malware, it only uses a small amount of bandwidth and a small amount of code, but can provide a real-time and reliable connection, ensuring the connection with the C2 server.

However, even though MQTT looks very good, the attacker has added conditions not to use it, so the malware needs to know whether the current device is using WIFI or using data traffic, and decide whether to use MQTT according to the specific scenario.

SMS

The most interesting part of the attack chain, in the author's opinion, should be the application of SMS. Even a seemingly mistakenly sent SMS can be used for remote operation. Most people might think that someone filled in the phone number incorrectly and received the SMS by mistake.

Figure 6: A normal Google verification code SMS

However, from the capture of the LookOut team (⑦), this is also one of the remote control methods. All received SMS messages will be searched for 'your google verification code' in a case-insensitive manner, and if a match is found, the SMS will be parsed in the following format:

text:[Random 6-digit number][Operation number]a=[Ack ID]&[Command parameters]&s=[Message signature]

The first 6 digits of the 7-digit number disguised as a captcha are random, and the last digit is used for operation. The details of the numbers used for operation can be understood from the following table:

Table 1: Detailed Explanation of Operation Numbers

For example, if the captcha is 1234567, 123456 is randomly generated, and 7 is the command. After the malicious program parses this command, it will send an acknowledgment command via HTTP, and the Ack ID in the a parameter will be sent with the HTTP header, so that the C2 server knows which command the device has confirmed to receive.

The final signature information is used to ensure that this SMS is sent by the attacker. This signature is the MD5 hash value of a message sent to the C2 server after the malware is initialized, so only the attacker knows it, ensuring that it is not executed incorrectly.

Capture screen image

This operation path is completed by the /res/raw/take_screen_shot ELF file:

Figure 7: take_screen_shot analysis

Two parameters are required, and the second parameter is passed to dest. dest is passed together with this string to the sub_90EC function, and the return value is returned. Then, what is '/dev/graphics/fb0'?

Generally, screen capture is obtained using FrameBuffer, which is an abstraction of display in Linux. In the concept of 'everything is a file' in Linux, the display device can naturally be treated as a file, which can be compared to video memory. The absolute path '/dev/graphics/fb0' is the location of FrameBuffer. Therefore, passing this location to the next function largely indicates that it is to obtain a screenshot, and the specific method of obtaining this frame is not elaborated on, because it stores pixel points, which need to be converted into an image to be transmitted. It appears that the conversion is from pixel points to png image format. Therefore, this ELF file is from the current image information of the screen at '/dev/graphics/fb0'.

Framaroot root access

It is also done by an ELF file, /res/raw/sucopier does, and this ELF file uses the logic of Framaroot. However, it is interesting that Framaroot is not open source, and how NSO obtained the source code of Framaroot is unknown. Specific methods of achieving root access are not elaborated here, because the root access vulnerabilities that Framaroot can exploit have all been restricted at the system level after Android 8.0, and there is no need to elaborate on it.

Keyboard logging

Keylogging in Android has always been a common thing among security personnel. In this sample, the keyboard keylogging is done by the ELF file /res/raw/libk. During the execution process, this ELF file is loaded into /data/local/tmp/libuml.so, and it injects the keyboard process immediately before being deleted, and the keylogging is written to the file /data/local/tmp/ktmu/ulmndd.tmp:

Figure 8: Temporary file ulmndd.tmp

But this is just a temporary file, which will eventually be written to the file /data/local/tmp/ktmu/finidk.<timestamp>:

Figure 9: finidk.<timestamp>

If you have ever played or watched the English version of Pokémon or related works and games, you will find a very familiar name - Jigglypuff, the chubby one.

Figure 10: Jigglypuff

Because Pegasus has already been closely monitored in iOS, in order to avoid being detected by string detection, researchers speculate that attackers used JigglyPuff as their internal code name in Android.

Strong obfuscation

The last interesting point is that Chrysaor uses very strong obfuscation at the Java layer, such as all strings are encoded with Base64 and XOR, and all method calls are done through reflection:

Figure 11: Strong obfuscation

Please note that it is all strings and method calls, for example, in the class "seC.dujmehn.Besqjyed.EdQBqhCHusuyluh", there is a statement:

BuBlJJJJJXDFKYirSooj(ZQjvHTeBlVUCiutw(QVozqddybqHRWaDm(QmdafFtUsXvVcahq(mprchPoltGTBsyTr(newStringBuilder(onReceive9584()),mRvgkfrWJgjwKERW(newDate())),onReceive9585()),igMiBMAFlnpIGcji(intent))));

In fact, this is just a string concatenation operation, which is translated as:

Pass a string to the a method of the q class: "OnAlarmReceiver onReceive: " + GMT time + "action: " + Intent captured action

This is also a characteristic of the Pegasus family. The benefit of this is that the methods called are not discovered by anti-virus engines through static scanning, and some strings that look very dangerous are not scanned out, unless all dynamic hooks are down, otherwise static analysis is completely ineffective for this.

Reflection and summary

In fact, if you have carefully read the relevant information about Pegasus, you will find that Chrysaor has a lot in common with it, such as both injecting processes to obtain keyboard recording, both using SMS for remote control, and both using MQTT protocols, etc.

When the device is the main device used, it contains a large amount of sensitive information, which is often obtained by various manufacturers through big data analysis to create a portrait of the person. This is a vague abstraction, and in fact, what manufacturers know is always limited, and most of it is restricted by law. Spyware is different; it is a direct grab. Should everyone worry about their information being stolen in this way?

In fact, there is no need to worry too much. From the analysis, we can see the characteristics of spyware, which is like a trimmed version of remote control programs in Windows. However, both Android and iOS restrict the permission issue very strictly, and the program can only run in its sandbox. Without obtaining elevated privileges, it is impossible to access content that is not allowed. Therefore, spyware inevitably needs to obtain elevated privileges. However, with the improvement of the security research system and talents, the cost of a 0day capable of obtaining elevated privileges is very high, and if it spreads widely, the possibility of being discovered is very high. Clearly, the cost does not match the benefits.

What truly needs to be cared about and concerned about are those high-value targets, such as politicians, media, executives, etc., where the device may involve information of high value, which the attacker can obtain at any cost.

Precautionary suggestions

From the source

Do not enable 'Allow installation of apps from unknown sources', and it is best to only use APKs downloaded from official app stores. Of course, this does not mean that you can completely trust applications downloaded from official app stores. For example, the Lizpizzan family, which is also spyware, starts its attack chain from a completely normal APP that is listed in the app store, and then downloads and installs malicious programs.

However, as a user, not enabling the option 'Allow installation of apps from unknown sources' can still ensure security.

From the perspective of privilege escalation

Although it is basically unrealistic to prevent 0day attacks, in this case, the vulnerability exploited by Framaroot can only be used on Android 8.0 and lower versions. If the kernel version of the device is higher than Android 8.0, you can rest assured that you will not be attacked by the currently captured Chrysaor attack.

However, this does not mean absolute safety. Regardless of the kernel version, you should update to the latest version released by the manufacturer in a timely manner to ensure that you are not attacked by 1day or unpatched vulnerabilities. At the same time, do not obtain root privileges by flashing the system. For any Android device that contains sensitive information, it is best not to manually obtain root privileges. Not to mention whether it is safe to obtain root privileges, even if the root tool is safe, it also gives malicious software more opportunities to take advantage.

For iOS users, this is even more so. According to reports, from 2014 to July 2021, the attacks by Pegasus have never stopped, and it is impossible to guarantee that there are no 0day vulnerabilities that have not been disclosed yet. At the same time, the Nday vulnerabilities in the wild also require each user to update the system in a timely manner. Do not ignore more serious security issues because you dislike the possible lag caused by system upgrades.

If you have already enabled this option and manually obtained root privileges, please carefully check the application list to see if there are any unfamiliar applications. Although most of the mainstream Android spyware disclosed so far exists as independent apps, they have all been placed in the /system partition. Meanwhile, when we flash the system or restore the factory settings, we erase the /cache and /data partitions, so a double clear will not solve the problem. Only by accurately identifying the spyware and using root privileges to delete it can we ensure that we are not affected.

Anheng Threat Intelligence Center's Shadow Laboratory will continue to pay attention to the dynamics of cyber security.

Reference links

① LookOut team's analysis of Pegasus: https://info.lookout.com/rs/051-ESQ-475/images/lookout-pegasus-technical-analysis.pdf

② Google's blog on Chrysaor: https://security.googleblog.com/2017/04/an-investigation-of-chrysaor-malware-on.html

③ Citizen Lab reported that journalists were疑似 attacked by iMessage zero-click vulnerability: https://citizenlab.ca/2020/12/the-great-ipwn-journalists-hacked-with-suspected-nso-group-imessage-zero-click-exploit/

④ Amnesty International's report on Pegasus in July 2021: https://www.amnesty.org/en/latest/research/2021/07/forensic-methodology-report-how-to-catch-nso-groups-pegasus/

⑤ Google's blog on Lipizzan: https://security.googleblog.com/2017/07/from-chrysaor-to-lipizzan-blocking-new.html

⑥ MQTT protocol: https://www.runoob.com/w3cnote/mqtt-intro.html

⑦ LookOut team's analysis of Chrysaor: https://info.lookout.com/rs/051-ESQ-475/images/lookout-pegasus-android-technical-analysis.pdf

Author: Anheng Threat Intelligence Center Shadow Laboratory