{
	"id": "fa4c2c7f-adcd-4580-8ce8-08e43bfe9aed",
	"created_at": "2026-04-06T01:29:51.738338Z",
	"updated_at": "2026-04-10T13:12:40.997547Z",
	"deleted_at": null,
	"sha1_hash": "4adc5b33be6956bc254164b3919bec95c64c3824",
	"title": "DoNot’s Firestarter abuses Google Firebase Cloud Messaging to spread",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 540749,
	"plain_text": "DoNot’s Firestarter abuses Google Firebase Cloud Messaging to\r\nspread\r\nBy Warren Mercer\r\nPublished: 2020-10-29 · Archived: 2026-04-06 00:11:53 UTC\r\nThursday, October 29, 2020 08:00\r\nBy Warren Mercer, Paul Rascagneres and Vitor Ventura.\r\nThe newly discovered Firestarter malware uses Google Firebase Cloud Messaging to notify its authors of\r\nthe final payload location.\r\nEven if the command and control (C2) is taken down, the DoNot team can still redirect the malware to\r\nanother C2 using Google infrastructure.\r\nThe approach in the final payload upload denotes a highly personalized targeting policy.\r\nWhat's new? The DoNot APT group is making strides to experiment with new methods of delivery for\r\ntheir payloads. They are using a legitimate service within Google's infrastructure which makes it harder for\r\ndetection across a users network.\r\nHow did it work? Users are lured to install a malicious app on their mobile device. This malicious app then\r\ncontains additional malicious code which attempts to download a payload based on information obtained from the\r\ncompromised device. This ensures only very specific devices are delivered the malicious payload.\r\nSo what? Innovation across APT Groups is not unheard of and this shouldn't come as a huge surprise that a group\r\ncontinues to modify their operations to ensure they are as stealth as can be. This should be another warning sign to\r\nhttps://blog.talosintelligence.com/2020/10/donot-firestarter.html\r\nPage 1 of 9\n\nfolks in geo-politically \"hot\" regions that it is entirely possible that you can become a victim of a highly motivated\r\ngroup.\r\nExecutive Summary\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nThe DoNot team is known for targeting Kashmiri non-profit organizations and Pakistani government officials. The\r\nregion of Kashmir is under ongoing disputes from India, China and Pakistan about its ownership. This fuels\r\npotential conflict at times. This actor, DoNot, recently started using a new malware loader we're calling\r\n\"Firestarter.\" Our research revealed that DoNot has been experimenting with new techniques to keep a foothold on\r\ntheir victim machines. These experiments, substantiated in the Firestarter loader, are a sign of how determined\r\nthey are to keep their operations despite being exposed, which makes them a particularly dangerous actor\r\noperating in the espionage area. The same experiments also showed the capability of keeping their operations\r\nstealthy as now they have the capability to decide which infections receive the final payload based on\r\ngeographical and personal identification criteria. This reduces the likelihood that researchers will access it.\r\nDoNot is now leveraging Google Firebase Cloud Messaging (Google FCM) as a mandatory communication\r\nchannel with the malware. This communication channel is encrypted and mixed among other communications\r\nperformed by Android Operating System with the Google infrastructure, DoNot team is hiding part of their traffic\r\namong legitimate traffic. Even though the malicious actors still need a command and control (C2) infrastructure,\r\nthe hardcoded one is only needed at installation time, afterwards it can be discarded and easily replaced by another\r\none. Thus, if their C2 is taken down by law enforcement or deemed malicious they can still access the victim's\r\ndevice and instruct it to contact a new C2. With this new tactic only Google has the capability to effectively stop\r\nthe malware, since it's the only institution that could disable the Google FMC mechanism on the victim's device.\r\nWe believe the propagation is most likely done via direct messages luring the victims to install the malware.\r\nOrganizations and individuals can protect themselves by preventing the installation of software from unknown\r\nsources on Android and, if possible, by detecting the initial network flow done to the C2.\r\nhttps://blog.talosintelligence.com/2020/10/donot-firestarter.html\r\nPage 2 of 9\n\nVictimology The DoNot Team is already known to have an interest in India and\r\nPakistan. The filename of the few Android applications show the same interest, for\r\nexample: kashmir_sample.apk or Kashmir_Voice_v4.8.apk. This new campaign\r\npoints to the same victimology as usual: India, Pakistan and the Kashmir crisis.\r\nThe targets are mainly end users and non-profit organizations linked to this area\r\nof the world.\r\nLoader flow The first execution of the loader provides a lure to make the victim\r\nbelieve that there was no malicious install. The sequence below shows what a user\r\nsees during the first execution.\r\nOnce the message of uninstallation is shown, the icon is removed from the user interface. The only way to detect\r\nthe application is by checking the application list. There, the user sees an icon for the application that seems to be\r\ndisabled, as can be seen below.\r\nIf the user checks the permissions, it can see that they exist but with the name \"System Service,\" which is made to\r\ndeceive the user into thinking that it's seeing system related permissions and not the application permissions.\r\nWhile the user is presented with the messages regarding the incompatibility, the malware makes the first contact\r\nwith the C2. It will send information regarding the victim's identity and geolocation, both crucial for the next steps\r\nthe operators will perform. The full flow consists of six steps before the malware starts receiving commands from\r\nthe C2 as shown below.\r\nAfter getting the Google FMC token (Step 1) the operators have everything they need to send the Google FMC\r\nmessage containing the URL for the malware to download the payload. They also have the geographic location, IP\r\naddress, IMEI and email address from the victims, allowing them to decide which victims should receive the\r\npayload.\r\nhttps://blog.talosintelligence.com/2020/10/donot-firestarter.html\r\nPage 3 of 9\n\nUsing static analysis, followed the code execution to the point of confirming the role played by the Google FMC\r\nmechanism used within this loader, we decided that we should test it dynamically.\r\nWhen the malware receives a message from Google FMC, it checks if it contains a key called \"link.\" If that exists,\r\nit will check if it starts with \"https,\" if everything checks out, it will use the link to download the payload from a\r\nhosting server. Once the file arrives, the malware will import the classes from the payload, and being now able to\r\nstart the malicious service, which is declared on the manifest\r\n, as you can see in the picture below.\r\nThis is a different malware sample, which contains the embedded payload and starts the malicious service.\r\nOnce the payload is on the victim device, the loader will load the classes and start the malicious service. If the\r\ndevice is rebooted, the loader will automatically check for the presence of the payload on the device, and load it if\r\npresent.\r\nInstrumenting the malware We patched the malware sample to allow us to control\r\nthe messaging flows, and then we can confirm what we already established\r\nstatically.\r\nThe first step was the creation of a Google Firebase project associated with one of our accounts — the entry level\r\nfor this service is free, and conceivably anyone could do it. Once we had our project created, we defined an\r\napplication with the exact same name as our malware sample. In this case, it was called \"com.chatlitesocial.app.\"\r\nThis generated a JSON Google Services configuration file, like the one below, which a developer should add to\r\nhis project in order to use the services.\r\nhttps://blog.talosintelligence.com/2020/10/donot-firestarter.html\r\nPage 4 of 9\n\nNow that we have the IDs, we need to add them to the malware. We unpacked the malware and searched for the\r\nGoogle Services configuration, which we found in the resources directory in the strings.xml file. The image below\r\nshows the entries that we replaced by the values we got from the JSON configuration file.\r\nFinally, we rebuilt the APK, signed it and installed it into our test device. Then we set up a test environment that\r\nconsisted of an HTTPS web server to log the malware request, a logcat to see the malware log messages and a\r\nscript that interacts with Google Firebase Cloud Messaging Admin APIs to send the message to our victim.\r\nWhy a new loader?\r\nBetter control of the compromised devices even if the C2 is switched off This new loader provides\r\nat least two important features to the attackers. First, it allows them to decide who receives the\r\npayload, being able to verify the victim before sending the payload. Thus, they can prevent the\r\npayload from falling into researchers' or law enforcement's hands. Second, it provides them with\r\na powerful off-band persistence mechanism.\r\nUsually, taking a C2 down is enough to render a malware inert, even if it stays active on the victim's device. This\r\ncan be done by law enforcement or by the hosting platforms when they become aware. However, it can be difficult\r\nhttps://blog.talosintelligence.com/2020/10/donot-firestarter.html\r\nPage 5 of 9\n\nto notify the victims, and in some cases it's almost impossible. Using Google Firebase Messaging service as a C2\r\ncontrol channel allows the attackers to regain control of the malware even after the C2 is taken down. From the\r\nnetwork's point-of-view, this action is completely innocuous, since all communication is done through Google and\r\nencrypted using legitimate certificates.\r\nIf a C2 server is down, the operator can push a new Google Firebase message to download a new payload from a\r\nnew location, which can be a new C2 or a hosting location. This action is entirely hidden for the compromised\r\ndevices, requiring no user interaction. During our research, we found that other versions of the same malware\r\nexisted using Google Firebase as an alternative communication channel. Earlier versions, however, would simply\r\nissue a command to start the malicious service.\r\nNo final payload for the analysts As the final payload is not embedded in the Android application,\r\nit is impossible for analysts to dissect it. This approach also makes detection more difficult. The\r\napplication is a loader with a fake user interface that manipulates the target after installing it.\r\nAs we explained above, the malware needs to contact the C2 before the operator uses Google Firebase to contact\r\nthe malware. It is interesting to notice that the C2 url is not obfuscated, however the Google Firebase component\r\nis not so obvious. The code snippet below is responsible for downloading the payload.\r\nOn the second line the authors set the HTTP method to GET, this is not necessary since GET is the default. Then,\r\nthe actors change the method to POST by calling setDoOutput(True). Without setting any data to be sent, the\r\nauthors issue the connect() method to contact the C2. We believe that this was done on purpose to make analysis\r\nmore difficult. First, there was no need to set the method to GET, and then it was changed to POST without using\r\nthe correct method. Finally for this approach to work, the operators had to configure the payload hosting server to\r\naccept POST without data. This would have required interaction from the attackers configuration perspective, as\r\nthis is not a default method.\r\nSame final payloads than previously without additional work The loader is design to load a class\r\nnamed: \"com.system.myapplication.Activities.dcteat\"\r\nhttps://blog.talosintelligence.com/2020/10/donot-firestarter.html\r\nPage 6 of 9\n\nThis name is the same as previous samples from the same group. Thanks to this choice, this loader can load any\r\nprevious APK from this threat actor. It does not need additional cost for the attacker and the previous malware can\r\nbe used transparently with this loader.\r\nDoNot's mobile framework We identified a new loader developed by DoNot Team\r\nAPT. This threat actor is known to develop and use Android malware. Here is an\r\nexample of analysis by RiskIQ. The malware developed by DoNot Team takes\r\ncontrol of the compromised devices. It supports all the classic features of a spying\r\nframework:\r\nGet the call history\r\nGet the address book\r\nGet the SMS\r\nKeyboard input\r\nGet files from the SD card\r\nGet user information\r\nGet network information\r\nGet location of the device\r\nGet installed applications\r\nGet browser information\r\nGet calendar information\r\nGet WhatsApp information The new loader is 100 percent compatible with the standard malware used by\r\nDoNot Team. This loader makes analysis more difficult by dynamically downloading and loading the final\r\npayload and to make the malware more reliable by using the Google Firebase messaging framework. This\r\nframework is used to send messages on the compromised devices with an URL where the final payload is\r\nlocated. With the new loading blocking the C2 server is not enough, if the Firebase messaging is still\r\nactive, the loader can download a new payload from a new C2 server.\r\nConclusionThreat actors continue to innovate their operations. The DoNot team\r\nhas actively avoided traditional methods of various components throughout this\r\nnew piece of malware. They attempted to evade and masquerade by using Google\r\nplatforms, they used different configuration options to allow specially created\r\nfeatures for their web server infrastructure and they ensured they had backward\r\ncompatibility with previous versions of their malware. We assess that this is a team\r\nthat has the ability to fund ongoing features to be built into their Android arsenal.\r\nThe DoNot team continues to focus on India and Pakistan, and this malware\r\nfurther enforces that.\r\nhttps://blog.talosintelligence.com/2020/10/donot-firestarter.html\r\nPage 7 of 9\n\nThe included fallback mechanisms ensure their malware remains persistent on the infected devices. This is crucial\r\nto ensuring long term access to compromised victims. This, along with their selective delivery mechanism,\r\nsuggests their preference is to remain under the radar and remain undetected for long periods of time to allow\r\nsufficient intelligence and espionage gathering to take place.\r\nCoverage Ways our customers can detect and block this threat are listed below.\r\nAdvanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these\r\nthreat actors. Exploit Prevention present within AMP is designed to protect customers from unknown attacks such\r\nas this automatically.\r\nCisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious\r\nwebsites and detects malware used in these attacks.\r\nEmail Security can block malicious emails sent by threat actors as part of their campaign. Network Security\r\nappliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS),\r\nCisco ISR, andMeraki MX can detect malicious activity associated with this threat.\r\nAMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.\r\nUmbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs,\r\nwhether users are on or off the corporate network.\r\nOpen Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack\r\navailable for purchase on Snort.org. Snort rules 56081 specifically defend against Firestarter.\r\nIOCs\r\nhttps://blog.talosintelligence.com/2020/10/donot-firestarter.html\r\nPage 8 of 9\n\nHashes b4c112d402c2555bea91d5c03763cfed87aa0fb0122558554c9a3bc7ac345990\r\n69f257092947e003465f24b9b0b44d489e798bd5b8cf51f7e84bc161937b2e7c\r\na5cfb2de4ca0f27b012cb9ae56ceacc2351c9b9f16418406edee5e45d1834650\r\nd0a597a24f9951a5d2e7cc71702d01f63ff2b914a9585dbab5a77c69af5d60b5\r\ne7a24751bc009bbd917df71fd4815d1483f52669e8791c95de2f44871c36f7f4\r\n86194d9cb948d61da919e238c48a01694c92836a89c6108730f5684129830541\r\n8770515a5e974a59f023c4c71b0c772299578f1e386f60f9dd203b64e2e2d92e\r\na074aa746a420a79a38e27b766d122e8340f81221fe011f644d84ff9b511f29a\r\n3d3f61d5406149fd8f2c018fbc842ccef2f645fc22f4e5702368131c1bd4e560\r\n3d40fdc4dc550394884f0b4e38aa8a448f91f8e935c1b51fedc4b71394fa2366\r\n83d174c65f1c301164683c163dab3ea79d56caeda1a4379a5a055723e1cb9d00\r\n0c2494c03f07f891c67bb31390c12c84b0bb5eea132821c0873db7a87f27ccef\r\nb583ae22c9022fb71b06ec1bae58d0d40338432b47d5733bf550972c5cb627c4\r\nc4971a65af3693896fdbb02f460848b354251b28067873c043366593b8dbc6f9\r\nfa85813a90a2d0b3fc5708df2156381fdb168919b57e32f81249f8812b20e00a\r\nfde7ca904d9ae72ea7e242ee31f7fbaee963937341ca2863d483300828a4c6e0\r\n0c2494c03f07f891c67bb31390c12c84b0bb5eea132821c0873db7a87f27ccef\r\n192f699e6ce2cccb2c78397392f4d85566892d9c8cf7de1175feb4d58f97d815\r\ne8605854c8730d2e80d8a5edd8bc83eb7c397a700255754ec9140b9717f7d467\r\n2481f133dd3594cbf18859b72faa391a4b34fd5b4261b26383242c756489bf07\r\n0c2494c03f07f891c67bb31390c12c84b0bb5eea132821c0873db7a87f27ccef\r\nDomains and IP addresses 178.62.188[.]181\r\nbulk[.]fun\r\ninapturst[.]top\r\nseahome[.]top\r\nfif0[.]top\r\napkv6.endurecif[.]top\r\nSource: https://blog.talosintelligence.com/2020/10/donot-firestarter.html\r\nhttps://blog.talosintelligence.com/2020/10/donot-firestarter.html\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.talosintelligence.com/2020/10/donot-firestarter.html"
	],
	"report_names": [
		"donot-firestarter.html"
	],
	"threat_actors": [
		{
			"id": "2ac63ef4-a7b8-4a30-96ad-b30ccb2073fc",
			"created_at": "2022-10-25T16:07:23.546262Z",
			"updated_at": "2026-04-10T02:00:04.651083Z",
			"deleted_at": null,
			"main_name": "Donot Team",
			"aliases": [
				"APT-C-35",
				"Mint Tempest",
				"Origami Elephant",
				"SectorE02"
			],
			"source_name": "ETDA:Donot Team",
			"tools": [
				"BackConfig",
				"EHDevel",
				"Jaca",
				"yty"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "cfdd350b-de30-4d29-bbee-28159f26c8c2",
			"created_at": "2023-01-06T13:46:38.433736Z",
			"updated_at": "2026-04-10T02:00:02.972971Z",
			"deleted_at": null,
			"main_name": "VICEROY TIGER",
			"aliases": [
				"OPERATION HANGOVER",
				"Donot Team",
				"APT-C-35",
				"SectorE02",
				"Orange Kala"
			],
			"source_name": "MISPGALAXY:VICEROY TIGER",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775438991,
	"ts_updated_at": 1775826760,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4adc5b33be6956bc254164b3919bec95c64c3824.pdf",
		"text": "https://archive.orkl.eu/4adc5b33be6956bc254164b3919bec95c64c3824.txt",
		"img": "https://archive.orkl.eu/4adc5b33be6956bc254164b3919bec95c64c3824.jpg"
	}
}