Detailed analysis report of cyber threat targeting journalist in South Korea through APT phishing campaign with malicious APK

Author : Ovi Liber, Threat Researcher @ Interlab
Publishing Date : 2022/12/30

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 Interlab’s 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 malware named as RambleOn in 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, 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. 1. Adversary lures victim install installing malicious application (in this instance, this application is called Fizzle)

1. 1. Fizzle downloads a payload, a .Dex file, from either pCloud or Yandex cloud storage endpoints. 

1. 1. 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. 

1. 1. The secondary payload registers the device with Google’s Firebase Cloud Messaging to provide C2 mechanisms. 

1. 1. The secondary payload starts multiple services, that exfiltrate data to the pCloud or Yandex cloud storage endpoints.

1. 1. 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.  

Figure 1 Diagram of malware flow

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. 

Figure 1 VirusTotal scan results of Fizzle messaging app

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

.

Figure 2 Screenshot of the Fizzle Application home page

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.

Figure 3 Fizzle messaging app permissions

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”.

Figure 4 Screenshot of ch.seme.LogUService’s usage of DexClassLoader

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. 

Figure 5 Screenshot of the ch.seme.services.LogUService’s openConnection() usage to download the first stage payload

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.

Figure 6 Screenshot of the ch.seme.services.LogUService cloud storage if statement

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

Figure 7 Screenshot of service launch within ch.seme.client.HomeActivity

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

Figure 8 Screenshot of the onResume() method within ch.seme.client.HomeActivity

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”. 

Figure 9 Class structure of first payload

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

Method	Functionality
aesEncrypt(), aesDecrypt()	File encryption/decryption with AES
appendCL()	Append the call log
appendLog()	Write over a specific logfile
AR(), ARStop()	Record audio start and stop
copyFile()	Copy any file and send back to C2
createFolder()	Create a new folder
downloadFile()	Download file cloud storage endpoint
encryptText()	Encrypt text with RSA key
fetchContacts()	Get all contacts and their details
fileEncrypt()	Encrypt files using AES key:“qwertyuiop456789”
getAddressNumber()	Get address from MMS
getCurrentIP()	Calls API endpoint ‘http://ip-api[.]com/json/?fields=city,country,query’ to get IP address and location of it.
getLocation()	Get latitude & longitude
getPhoneInfo()	Gets the following device information:BoardBootloaderBrandDeviceDisplayFingerprintHardwareHostIDManufacturerModelProductSerialTagsTimeTypeUserRadio versionVersion codenameVersion incrementalVersion releaseVersion SDK INTInstall packages/applications
getPublicKey()	Get public key from device, decrypt using AES keys: “1qaz2wsx3edc4rfv5tgb6yhn7ujm8ik”“qwertyuiop456789”
getRealTimeInfo()	Gets the following device information:Current timeNetwork informationBattery powerBattery optimizationDisplay stateIP address
rec()	Provides functionality to initialize recording of the device (audio and media recording)
sendToServer()	Send files back to C2
sms(), send(), SMSContentObserver(), appendSM(), appendSM_R(), appendMM()	Provides functionality to send, intercept and append SMS & MMS
storage()	Provides functionality to access SD and External data files
updateCmd()	Initiate CMD
updateState(), LogState()	updateState() Provides an update of device information back to C2. This is called by LogState() called initially by the Fizzle app.
uploadFile()	Upload file to cloud storage endpoint
uploadFile_SAF_P()	Upload a file to external cache directory

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’.

Figure 10 Screenshot of both LogState and UpdateState methods within the first payload

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

Figure 11 Screenshot of sendData exfiltration function within first payload

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”.

Figure 12 Screenshot of LogUService DexClassLoader utilisation

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. 

Figure 13 Screenshot of sendToServer() method contained within first payload

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. 

Figure 14 Screenshot of the RegisterForPushNotificationsAsync method called on application start

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. 

Figure 15 Screenshot of Application Manifest file showing application file receivers

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. 

Figure 16 Screenshot of PushReceiver class

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. 

Figure 17 Screenshot of Burp Suite network proxy traffic from the application

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

Figure 18 Screenshot of Application Manifest showing service ch.seme.services.LogJobService

The class ensures the “LogUService” continually runs in order to keep consistent communication & data exfiltration back to the command-and-control cloud service. 

Figure 19 Screenshot of ch.seme.services.LogJobService

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”. 

Figure 20 Screenshot of first payload initiating the second payload

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. 

Figure 21 updateCmd() function second payload service runs & payload checks

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. 

Figure 22 Screenshot of the MyFirebaseMessagingService class implementation

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. 

Figure 23 Services contained in the second payload

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

Figure 24 Screenshot of sendJobService class contained in the second payload

Attribution

Over the last year, Interlab has 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 our analysis of RambleOn, we 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. 1. Victimology: The victimology of this event fits very closely with the modus operandi of groups such as APT 37 & Kimsuky.

1. 1. 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)

1. 1. 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. 

We 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/.

File Description	Sha256
Stage 1: Fizzle App	97d8aed87ec78d975aaff4a63415badf95635616686a7ad4a3257e02b6ca2400
Stage 2: Dex payload	0dadf1240fd097d15dee890d448cfab02d3ef8698bdc44e18f1b5495e500655f
Stage 3: com.data.WeCoin	751e67116e71b0a04bce6cabfa748fc105238ed1dd5b7d72f6d3f6301bbcad17

 

Interlab is a non-profit organization based in Seoul with mission to create resilient digital safety net for freedom of citizens, providing free digital security consultations, trainings, incident response support and research of cyber threat toward civic society.

For any inquiries regarding on this report, please reach us through contact@interlab.or.kr