RambleOn Android Spyware (December 2022)

This is a repost of some critical research I performed back in 2022 that was originally hosted on Interlab's website. Since Interlab has been abandoned by it's owner and thus shut down the website, I'm posting it here to ensure the research I performed is preseved. As stated in the title, this is research from 2022 and is for archiving & indexing purposes so threat researchers can still review it. In 2023, I researched this malware further which can be found here.

Report by Ovi, threat researcher (2022)

Executive Summary

• A Journalist in South Korea recently received malicious APK file suggested to be installed on the journalist’s phone, suggested by anonymous tipper.
• Through analysis done by Threat Researcher Ovi Liber, it is found that the APK file and its behavior after installation contains critically malicious functionalities: including ability to read and leak target’s contact list, SMS, voice call content, location and others from the time of compromisation on the target.
• The malicious APK file named as RambleOn on this report, contains unique characteristic of 1) using infrastructure of pCloud and Yandex, 2) usage of FCM service for C&C communication.

Introduction

Freedom of media and journalism is essential to enable democratic, free, and participative societies. However, as cyberthreats with political motivation targeting journalists grows while nature of journalists’ work involves in receiving and opening random files and links in the name of receiving tips from unknown sources, the importance of digital safety for journalists are ever imminent.

On December 7^th 2022, a journalist received a message over WeChat messenger application asking to talk privately about a sensitive topic. The both parties discuss messaging over a secure application and the sender suggests talking over an application called “Fizzle messenger” and proceeds to send a copy of the APK to lure a journalist to install. 

The application “Fizzle messenger” acts as a first stage of the malware, a loader, performing various checks on the Android device to serve a payload. The served payload that provides malicious methods that can be called from a C2, exfiltrates sensitive data to cloud storage and downloads a secondary payload. The secondary payload exfiltrates further data, registers services for continual exfiltration and provides C2 mechanisms via Google’s Firebase Cloud Messaging.

This threat report contains a breakdown of the functionality of this malware and we have shared sample hashes at the end of the report. 

RambleOn Flow Summary

The malware has multiple stages, payloads and exfiltrates data from the Android device continually. Below, we describe in simple steps how the malware executes and compromises its victims. 

1. Adversary lures victim install installing malicious application (in this instance, this application is called Fizzle)
2. Fizzle downloads a payload, a .Dex file, from either pCloud or Yandex cloud storage endpoints. 
3. Fizzle dynamically loads the .Dex file and calls a method that exfiltrates data to either the pCloud or Yandex cloud storage endpoints. This also downloads a secondary payload that facilitates continuous exfiltration and C2 mechanisms. 
4. The secondary payload registers the device with Google’s Firebase Cloud Messaging to provide C2 mechanisms. 
5. The secondary payload starts multiple services, that exfiltrate data to the pCloud or Yandex cloud storage endpoints.
6. C2 commands using Firebase Cloud Messaging (FCM) initiate services in the second payload, which dynamically load classes contained in the first payload. These classes perform C2 methods and exfiltrate any data back to the cloud storage.  

Stage 1: The loader 

As discussed in the introduction, the victim received a direct message over WeChat. The message relates to the sender discussing potential sensitive information and both parties discuss communicating over a more secure messaging app. The original sender, suggests to talk on an application called “Fizzle”, proceeding to send a copy of the file with the filename “1_Fizzle.apk” and suggests the victim to install the application. 

At the time of writing, the application was only determined as malicious by one vendor, however this only flagged for a PUA signature. 

The application itself works functionally as a messaging app, prompting the user to create an account link from another device.

Upon initial inspection of the application, we can first see that it has many permissions in its manifest that are dangerous in certain contexts. However, since this application is a messaging application, all of these permissions could be deemed as something necessary for its functionality. Many of these permissions can be seen in widely used legitimate messaging applications. Due to this, a user may not think this application is malicious.

When the application runs, the process itself spawns as “ch.seme”; during analysis, we identified one file that contained payload delivery functionality. Located at “ch.seme.services.LogUService”, the class contains dynamic Dex class loading via module “dalvik.system.DexClassLoader”. The malicious app uses the “DexClassLoader” to dynamically load a Dex file from a cloud storage endpoint (either pCloud or Yandex) and execute. The application loads the Dex, which has a process name “com.personal.info” and class name “plugin”.

The “LogUService” class contains multiple methods that provide capability to download the first payload from one of two endpoints located at cloud storage services, pCloud and Yandex. These cloud storage services are called via OAuth API calls using hard coded access tokens within the application. 

Depending on what configuration options are set in the “ch.seme.services.Constants.cloud” variable, the method determines which endpoint is used to serve the payload to the victim. If the variable is set to “P”, the class uses the pCloud endpoint, if not, it uses Yandex.

The “LogUService” described is launched during application load through “onStart()” within the “HomeActivity” class. 

The service is also checked for when the application is resumed by the user.

This usage of “DexClassLoader” to dynamically load a Dex file “com.personal.info” from one of two cloud storage endpoints, provides the application functionality to execute first payload on the victim’s device. 

Stage 2: The first payload – Com.Personal.Info.Plugin (Plugin4.0.dex)

When the “LogUService” service is launched, the Dex file downloaded from either pCloud or Yandex, to the directory “/data/user/0/ch.seme/files/.temp/”. During our analysis, we were served the payload described below; for simplicity, we have categorised its functionality in the table shown. However, it should be noted that in our sample analysed, not all of this functionality was being used by the payload, as there are many methods that appear to be unutilised.

The first payload’s primary functionality sits within the class located at “com.personal.info.plugin”. 

This “plugin” class, contains various methods that can be called by the C2 and data uploaded back to the cloud storage account:

However, the primary function of the payload is to provide functions to be called by the C2 and for the initial loader to call “LogState”. When “LogState” is called by the loader, this calls “updateState”, which then runs a method named “UpdateCmd()”. This method, downloads the second payload, which we will cover in the next section, titled ‘Stage 3: The second payload & C2 client – com.data.WeCoin’.

It then calls the method “sendData”, which exfiltrates messaging data from the phone, encrypts the files and uploads back to the cloud storage C2s. 

Cloud Storage C2 for Stages 1 & 2.

To command and control the first two stages of the malware, the operators of RambleOn use authentication tokens to both pCloud and Yandex cloud service providers. In the sample we analysed, the malware was using pCloud. 

When the loader application starts, the application registers the device for Pushy.me notifications using the Android SDK. Then proceeding to run the “LogUService”, which downloads the first payload from pCloud or Yandex. It then writes the Dex file to the following directory and filename: /data/user/0/ch.seme/files/.temp/plugin4.0.dex. The “LogUService” then uses the DexClassLoader to load the Dex file class “plugin” and execute method “LogState”.

This method, contained within the first payload, proceeds to gather information about the device, exfiltrate all SMS, MMS, call logs, audio and media and then finally calls “sendToServer()” method to upload files back to the cloud storage service. 

To receive commands to initiate payload delivery. The registration of the device to Pushy.me allows push message to be sent to the device, much like Firebase Cloud Messaging. 

We see that the “com.seme.services.PushReceiver” is set with intent filter designated for the  Pushy.me notifications, in addition to the “LogUService” class. Providing the class with file receiver functionality.

It is within the “PushReceiver” class, upon receiving a push message, the Default Shared Preferences XML file is modified with content relevant to the cloud storage C2 mechanism. It then proceeds to initialise the “LogUService” service, loading the payload and calling the method within the payload required by the operator. 

As shown in the relevant examples throughout this report, the running of the “LogUService” ensures the application will periodically reach out to the cloud provider to download the first payload. 

This is also ensured by the “LogJobService” class being ran as a service by the application.

Stage 3: The second payload & C2 client – com.data.WeCoin

As explained in the previous section. The initial loader, in this case, the “Fizzle” application, calls “LogState” within the first payload Dex file. The “LogState” method calls “updateState”, which then calls a method named “UpdateCmd()”. The method, again reaches out to the cloud storage accounts via OAuth API and pulls a second payload down to the device using access tokens. This second payload, is an APK that gets installed to the device named “com.data.WeCoin”. 

This method, then proceeds to load the APK’s service which include additional C2 functionally back to the operator. This APK provides C2 functionality to interact with the first payload Dex file. In order for it to function correctly, the method checks that it can still access the Dex file. If it isn’t there, it will redownload the payload. 

On creation and running of the “com.data.wecoin” application, the application assigns a Firebase Cloud Messaging (FCM) device token and sends it back to the operator, allowing the use FCM to command and control the malware. The class “MyFirebaseMessagingService” facilitates the operator to send commands back to the device and initiate functions within the Dex second stage payload. It should be noted that similar functionality has been described here, (https://medium.com/s2wblog/unveil-the-evolution-of-kimsuky-targeting-android-devices-with-newly-discovered-mobile-malware-280dae5a650f). This article references functionality utilised by the APT group Kimsuky, whereby they discover the usage of FCM to provide C2 functionality within their Android malware. It is also interesting to highlight the importance of the class and method name. We noted that throughout our analysis of RambleOn malware, we identified many class and method names that correlate. This of course is not enough alone to provide solid and direct attribution leads but should be noted highly. 

The payload itself then registers many services contained within the APK which perform DexClassLoading operations to the secondary payload stored on the device. These services can then be run continuously via the C2. These include:

• recService – Executes method rec() in second payload to record audio
• sendJobService – Performs an asynchronous task to continually invoke method send() in second payload which exfiltrates SMS/MMS data. This functionality is also shown in Figure 11.
• smsJobService – Executes method sms() in second payload, which provides functionality to send or append SMS. 
• updateStateService – Performs an asynchronous task to continually invoke method updateState(), which calls both send() to exfiltrate data continually & ensures payloads are downloaded. This functionality is described above. 

Below, provides an example of the “sendJobService” class which allows the C2 to trigger a data exfiltration event. 

Attribution

Over the last few years, I have been working with human rights activists and journalists to document and index digital threats. Building a database of these threats, allow us to provide correlation between events based on categorised elements within each individual attack. To support this, we use the Diamond model to facilitate correlations for attribution. The diamond model relies upon indexing elements of an attack based on four categories: Adversary attributes (source email, handles, phone numbers, network assets etc), infrastructure (IP addresses, domain names, email addresses etc), victimology (modus operandi, targeted individual or organisational, personas, network assets, email addresses etc), capabilities (malware, exploits, hack tools, stolen certificates etc).

During my analysis of RambleOn, I found very little data points within our dataset that support clear and direct attribution for this event. However, there are multiple aspects that should be noted that can enrich further attribution in the future:

1. Victimology: The victimology of this event fits very closely with the modus operandi of groups such as APT 37 & Kimsuky.
   
2. Infrastructure: It should also be noted that the utilisation of pCloud and Yandex storage for payload delivery and command and control have been seen to be somewhat consistently utilised by  APT 37 (reference: https://www2.fireeye.com/rs/848-DID-242/images/rpt_APT37.pdf)
   
3. Capabilities: The utilisation of Google’s Firebase Cloud Messaging (FCM) has recently been seen within Android malware for a campaign attributed to Kimsuky (reference: https://medium.com/s2wblog/unveil-the-evolution-of-kimsuky-targeting-android-devices-with-newly-discovered-mobile-malware-280dae5a650f). It is also noted, that within this malware referenced, we identified a large amount of method and class name correlations which indicate some familiarity between the samples. 

I believe that raising these points allows for a pragmatic approach to the potentiality of attribution by other researchers going forward. 

IOC Index

To support research across the digital rights and information security industry, we have made the samples available to all publicly on VirusTotal and https://malshare.com/.