Stealth Backdoor “Android/Xamalicious” Actively Infecting Devices

Authored by Fernando Ruiz 

McAfee Mobile Research Team identified an Android backdoor implemented with Xamarin, an open-source framework that allows building Android and iOS apps with .NET and C#. Dubbed Android/Xamalicious it tries to gain accessibility privileges with social engineering and then it communicates with the command-and-control server to evaluate whether or not to download a second-stage payload that’s dynamically injected as an assembly DLL at runtime level to take full control of the device and potentially perform fraudulent actions such as clicking on ads, installing apps among other actions financially motivated without user consent.

The second stage payload can take full control of the infected device due to the powerful accessibility services that were already granted during the first stage which also contains functions to self-update the main APK which means that it has the potential to perform any type of activity like a spyware or banking trojan without user interaction. However, we identified a link between Xamalicious and the ad-fraud app “Cash Magnet” which automatically clicks ads, installs apps, and other actions to fraudulently generate revenue while users that installed it may earn points that are supposed to be redeemable as a retail gift card. This means that the developers behind these threats are financially motivated and drive ad-fraud therefore this might be one of the main payloads of Xamalicious.

The usage of the Xamarin framework allowed malware authors to stay active and without detection for a long time, taking advantage of the build process for APK files that worked as a packer to hide the malicious code. In addition, malware authors also implemented different obfuscation techniques and custom encryption to exfiltrate data and communicate with the command-and-control server. 

We’ve identified about 25 different malicious apps that carry this threat. Some variants have been distributed on Google Play since mid-2020. The apps identified in this report were proactively removed by Google from Google Play ahead of our reporting. McAfee is a member of the App Defense Alliance and an active partner in the malware mitigation program, which aims to quickly find Potentially Harmful Applications (PHAs) and stop them before they ever make it onto Google Play. Android users are protected by Google Play Protect, which can warn users of identified malicious apps on Android devices. McAfee Mobile Security detects this threat as Android/Xamalicious.  

Based on the number of installations these apps may have compromised at least 327,000 devices from Google Play plus the installations coming from third-party markets that continually produce new infections based on the detection telemetry of McAfee clients around the world. This threat remains very active. 

Figure 1. “Count Easy Calorie Calculator” was available on Google Play on August 2022 and carries Android/Xamalicious 

Android/Xamalicious trojans are apps related to health, games, horoscope, and productivity. Most of these apps are still available for download in third-party marketplaces.  

Previously we detected malware abusing Xamarin framework such as the open-sourced AndroSpy and forked versions of it, but Xamalicious is implemented differently. Technical details about Xamarin architecture are well documented and detail how .NET code is interpreted by Android using Mono. 

Obtaining Accessibility Services

Let’s use the app “Numerology: Personal horoscope & Number predictions” as an example. Once started it immediately requests the victim to enable accessibility services for “correct work” and provides directions to activate this permission:  

Figure 2. Tricking users into granting accessibility services permission 

Users need to manually activate the accessibility services after several OS warnings such as the following on the accessibility options: 

Figure 3. Accessibility services configuration prompt highlights the risks of this permission. 

Where is the malicious code? 

This is not the traditional Java code or native ELF Android application, the malware module was written originally in .NET and compiled into a dynamic link library (DLL). Then it is LZ4 compressed, and it might be embedded into a BLOB file, or directly available in the /assemblies directory on the APK structure. This code is loaded then by a native library (ELF) or by the DEX file at runtime level. In simple words, this means that in some samples the reversing of the DLL assemblies is straightforward while in others it requires extra steps to unpack them. 

The malicious code is usually available in two different assembly files in the /assemblies directory on the apk. Usually, file names are core.dll and a <package-specific>.dll.

Some malware variants has obfuscated the DLL assemblies to avoid analysis and reversing of the malicious code while others keep the original code available.  

Figure 4. Core.dll and GoogleService.dll contain malicious code. 

Communication with the command-and-control server

Once accessibility permissions are granted the malware initiates communication with the malicious server to dynamically load a second-stage payload.  

Figure 5. App execution and communication with the malicious server 

Collect Device Information 

Android/Xamalicious collects multiple device data including the list of installed applications obtained via system commands to determine if the infected victim is a good target for the second stage payload. The malware can collect location, carrier, and network information among device rooting status, adb connectivity configuration, for instance, if the device is connected via ADB or is rooted, the C2 will not provide a second-stage payload DLL for download. 

Data Encryption in JWT 

To evade analysis and detection, malware authors encrypted all communication and data transmitted between the C2 and the infected device, not only protected by HTTPS, it’s encrypted as a JSON Web Encryption (JWE) token using RSA-OAEP with a 128CBC-HS256 algorithm however the RSA key values used by the Xamalicious are hardcoded in the decompiled malicious DLL so decryption of transmitted information is possible if C2 infrastructure is available during the analysis. 

In the Send() function Android/Xamalicious first prepares the received object, usually a JSON structure calling the function encrypt() which creates the JWT using a hardcoded RSA key. So the data is exfiltrated fully encrypted to the malware host pointing to the path  “/Updater” via HTTP POST method. 

Then it waits for the C2 response and passes it to the decrypt() function which has a hardcoded RSA private key to properly decrypt the received command which might contain a second stage payload for the “getURL” command. 

Encrypt Method: 

Figure 6. Encrypt function with hardcoded RSA Key values as XML string 

The decryption method is also hardcoded into malware which allowed the research team to intercept and decrypt the communication from the C2 using the RSA key values provided as XML string it’s possible to build a certificate with the parameters to decrypt the JWE tokens content. 

C2 evaluation

Collected data is transmitted to the C&C to determine if the device is a proper target to download a second-stage payload. The self-protection mechanism of the malware authors goes beyond traditional emulation detection and country code operator limitations because in this case, the command-and-control server will not deliver the second stage payload if the device is rooted or connected as ADB via USB or does not have a SIM card among multiple other environment validations. 

DLL Custom Encryption 

With the getURL command, the infected client requests the malicious payload, if the C&C Server determines that the device is “Ok” to receive the malicious library it will encrypt a DLL with Advanced encryption standard (AES) in Cipher block chaining (CBC) using a custom key for the client that requested it based on the device id and other parameters explained below to decrypt the code since it’s a symmetric encryption method, the same key works for encryption and decryption of the payload. 

Delivers the Payload in JWT 

The encrypted DLL is inserted as part of the HTTP response in the encrypted JSON Web Token “JWT”. Then the client will receive the token, decrypt it, and then decrypt the ‘url’ parm with AES CBC and a custom key.  

The AES key used to decrypt the assembly is unique per infected device and its string of 32 chars of length contains appended the device ID, brand, model, and a hardcoded padding of “1” up to 32 chars of length. 

For instance, if the device ID is 0123456ABCDEF010 and the affected device is a Pixel 5, then the AES key is: “0123456ABCDEF010googlePixel 5111” 

This means that the DLL has multiple layers of encryption. 

1. It’s a HTTPS protected.
2. It’s encrypted as a JWE Token using RSA-OAEP with a 128CBC-HS256 algorithm.
3. URL parameter that contains the DLL is encrypted with AES and encoded as base64 

All these efforts are related to hiding the payload and trying to stay under the radar where this threat had relative success since some variants might have been active years ago without AV detections. 

DLL Injected 

Xamalicious will name this DLL “cache.bin” and store it in the local system to finally dynamically load it using the Assembly.Load method. 

Once the second stage payload has been loaded the device can be fully compromised because once accessibility permissions are granted, it can obverse and interact with any activity opening a backdoor to any type of malicious activity. 

During the analysis, the downloaded second stage payload contained a DLL with the class “MegaSDKXE” which was obfuscated and incomplete probably because the C2 didn’t receive the expected params to provide the complete malicious second stage that might be limited to a specific carrier, language, app installed, location, time zone or unknown conditions of the affected device, however, we can assure that this is a high-risk backdoor that leaves the possibility to dynamically execute any command on the affected device not limited to spying, impersonation or as a financially motivated malware. 

Cash Magnet Ad-Fraud and Xamalicious

One of the Xamalicious samples detected by McAfee Mobile generic signatures was “LetterLink” (com.regaliusgames.llinkgame) which was available on Google Play at the end of 2020, with a book icon. It was poorly described as a hidden version of “Cash Magnet”: An app that performs ad-fraud with automated clicker activity, apps downloads, and other tasks that lead to monetization for affiliate marketing. This application offers users points that are supposed to be redeemable by retail gift cards or cryptocurrency.

Figure 8a. LetterLink login page after running the app for the first time.

Figure 8b. LetterLink agreement for Cash Magnet

Originally published in 2019 on Google Play, “Cash Magnet” (com.uicashmagnet) was described as a passive income application offering users to earn up to $30 USD per month running automated ads. Since it was removed by Google the authors then infiltrated LetterLink and more recently “Dots: One Line Connector” (com.orlovst.dots) which are hidden versions of the same ad-fraud scheme.

Figure 9. LetterLink Icon that hides Cash Magnet

“LetterLink” performs multiple Xamalicious activities since it contains the “core.dll” library, it connects to the same C2 server, and it uses the same hardcoded private RSA certificate to build the JWE encrypted tokens which provide a non-repudiation proof that the developers of Cash Magnet are behind Xamalicious.

Figure 10. Cash Magnet infiltrated the app as a Game, available until the end of 2023

“Dots: One Line Connector” app is not a game, the screenshot published by Google Play does not correspond to the application behavior because once it is started it just asks for authentication credentials without any logo or reference to Cash Magnet. “Dots” does not contain the same DLLs as its predecessor, however the communication with the C2 is similar using the same RSA key parameters. We reported this app to Google and they promptly removed it from Google Play.

Affected Users 

Based on our telemetry we observed that more affected users are in the American continent with the most activity in the USA, Brazil, and Argentina. In Europe, clients also reported the infection, especially in the UK, Spain, and Germany. 

Figure 11. McAfee detections Android/Xamalicious around the world 

Conclusion 

Android applications written in non-java code with frameworks such as Flutter, react native and Xamarin can provide an additional layer of obfuscation to malware authors that intentionally pick these tools to avoid detection and try to stay under the radar of security vendors and keep their presence on apps markets. 

Avoid using apps that require accessibility services unless there is a genuine need for use. If a new app tries to convince you to activate accessibility services claiming that it’s required without a real and reasonable reason and requesting to ignore the operative system warning, then it’s a red flag. 

The second stage payload might take control of the device because accessibility permissions are granted so any other permission or action can then be performed by the malware if these instructions are provided in the injected code. 

Because it is difficult for users to actively deal with all these threats, we strongly recommend that users install security software on their devices and always keep up to date. By using McAfee Mobile Security products, users can further safeguard their devices and mitigate the risks linked with these kinds of malware, providing a safer and more secure experience. 

Android/Xamalicious Samples Distributed on Google Play: 

Indicators of Compromise 

The post Stealth Backdoor “Android/Xamalicious” Actively Infecting Devices appeared first on McAfee Blog.