Firestarter Malware Abuses Google Firebase Cloud Messaging Platform to Spread

by chebbi abir

The ‘Firestarter’ malware is used by an APT threat group called “DoNot”. DoNot uses Firebase Cloud Messaging (FCM), a cross-platform cloud solution for messages and notifications for Android, iOS, and web applications, which currently can be used at no cost.

The service is provided by Firebase, a subsidiary of Google, and has been previously leveraged by cybercriminals.


The DoNot APT group is making strides to experiment with new methods of delivery for their payloads.

They are using a legitimate service within Google’s infrastructure which makes it harder for detection across users’ networks.

The Way It Works

Users are tempted to install a malicious app on their mobile device, likely done via direct messages that utilize social engineering, researchers said. The filename of those Android applications (kashmir_sample.apk or Kashmir_Voice_v4.8.apk) shows continued interest in India, Pakistan, and the Kashmir crisis.

Once the app, which purports to be a chat platform is downloaded and opened, users receive a message that chats are continually loading, the application is not supported, and uninstallation is ongoing (as shown in the sequence below). 

This is often a lure to make the victim believe that there was no malicious install, researchers said. Once the message of uninstallation is shown, the icon is removed from the user interface. 

In the background, however, the malicious app is attempting to download a payload using FCM. Now this malicious app contains additional malicious code that attempts to download a payload based on information obtained from the compromised device. 

 The figure above shows the malicious app purports to uninstall after download. Once the message of uninstallation is shown, the icon is removed from the user interface. The only way to detect the application is by checking the application list.

While the user is presented with the messages regarding the incompatibility, the malware makes the first contact with the command and control (C2) servers. 


It will send information regarding the victim’s identity and geolocation, both crucial for the next steps the operators will perform. The complete flow consists of six steps before the malware starts receiving commands from the C2 as shown below.

After getting the Google FMC token (Step 1) the operators have everything they need to send the Google FMC message containing the URL for the malware to download, geographic location, IP address, IMEI, and email address from the victims, allowing them to decide which victims should receive the payload.

The necessity for a New Loader

Better control of the compromised devices even if the C2 is down. This new loader has two important features for the attackers. 

First, it allows them to make a decision who receives the payload, having the ability to verify the victim before sending the payload. 

Thus, they will prevent the payload from falling into researchers’ or law enforcement’s hands. Second, it provides them with a strong off-band persistence mechanism.

If the C2 server is down, the DoNot team can still redirect the malware to a different new C2 or hosting location using Google infrastructure.

Downloading the payload

Since the ultimate payload is not embedded within the Android application, analysts can’t dissect it. This approach also makes detection harder. The code snippet below is responsible for downloading the payload.

As a conclusion, DoNot team used different configuration options to permit specially created features for their web server infrastructure and also ensured backward compatibility with previous versions of their malware. 

The DoNot team continues to emphasize India and Pakistan, and this malware further enforces that.
To read the original article:


Interdit de copier  ce contenu