Starting last year, Android users have been seeing the “number is now verified” system notification more frequently. And in some cases people even find mysterious outgoing text messages in their history that they never sent.
These messages often cause confusion and even anxiety: has a virus infected the phone? Are tech giants spying on our phone numbers? Let’s break down how this feature works, and what potential risks it poses to your privacy.
The notification pops up whenever Google’s phone number verification feature is triggered on your device.
Its main job is to make sure that the SIM card tied to a specific phone number is physically inside the phone. Once verified, that phone number automatically links to all active Google accounts on the device.
There are several key services that rely on the verification. Most importantly, it drives Rich Communication Services (RCS) — the modern standard for “rich” messaging right inside your standard text messaging app. It feels like a popular chat app, but without the need to install anything extra. Unlike iMessage, which is locked to Apple’s ecosystem, RCS works across compatible smartphones on various platforms since it’s an industry standard set by carriers rather than tech giants. Since recently, both Apple and Android users have been able to exchange RCS messages. For this feature to work in the Google Messages app, Google needs ongoing confirmation that your SIM card is active. If you pull out your SIM card, RCS chats will keep working for about eight days before turning off automatically.
According to Google, phone number verification serves several other purposes as well:
Google also recently confirmed that this data is used to counter scams. Verification helps block calls or text messages from spoofed numbers if both the real owner of the number and the recipient are using Android devices with verified phone numbers.
Phone number verification technology has been around on Android for quite some time — Google was sending test SMS messages as far back as in 2019. However, it became widely visible to most users following a Google system update in September 2025. The process was baked deeper into the operating system, with number verification now running by default during initial phone setup, and re-running periodically in the background.
There are two main technical methods for the verification process. Which one your device uses depends on your mobile carrier and your version of Android.
The older method relies on hidden text messages. In the background, your smartphone sends a specialized technical text message to Google’s servers. The operating system intercepts this message before you ever see it, which is why it rarely appears in your standard text messaging app. However, due to software glitches or Android customization quirks, these texts occasionally surface in sent messages, startling users. They typically look like this: “(string of letters and numbers) Google is re-verifying the phone# of this device.” Google explicitly notes in its help documentation that standard messaging rates from your carrier may apply.
In recent years, direct carrier verification (via carrier APIs) has become the primary verification method. This approach is more modern and secure than previous ones. The smartphone sends an encrypted token containing device and SIM card identifiers to the mobile carrier, and the carrier responds with the confirmed phone number. The whole process takes just a couple of seconds and runs completely unnoticed by the user. Both global telecom giants and smaller providers have connected to this verification network. Notably, third-party apps can also tap into the results of this check through Firebase Phone Number Verification, getting confirmation from your mobile carrier about which phone number is active on the device.
In its official documentation, Google notes that device identifiers and SIM card data may be collected during verification. In practice, this refers to unique identifiers for the SIM card and its subscriber profile (ICCID and IMSI), as well as technical device identifiers needed to run mobile networks. Google also explicitly states that it does not sell your personal information, including your phone number, to anyone.
Naturally, sending additional unique identifiers to Google — especially given the scale of its advertising business — always raises concern among privacy-conscious users. Here’s what you should keep in mind:
Metadata collection. To run RCS, Google exchanges data with your mobile carrier. Even when the content of RCS messages is encrypted, metadata — such as who is messaging whom and when — can still be stored on your carrier’s servers, and in some cases, on Google’s servers. As cybersecurity experts at the Electronic Frontier Foundation point out, if privacy is your top priority, you’re better off sticking to dedicated encrypted messaging apps.
Linked accounts. If you have both a personal and a work Google account (or a personal and a family account) set up on the same phone, the verified number will automatically link to both profiles. The operating system does not offer built-in tools to separate numbers for different accounts on a single device.
Phone number leaks. Apps on your device can already access various user identifiers, including your phone number. However, this verification system makes it easier to link multiple phone numbers to a user who has multiple Google accounts. And while Google states that it never sells phone numbers, you cannot say the same with confidence about obscure third-party Android developers.
On by default. The feature is enabled out of the box, and most users have no idea their device is silently querying their carrier in the background. While you can opt out in your Google settings once you notice it, there’s no guarantee that any data already collected will actually be deleted.
For most users, verification is genuinely helpful. It simplifies account recovery, makes finding a lost phone easier, powers modern text messaging features, and assists emergency services when every second counts.
However, if you want to minimize the amount of metadata sent to Google, mobile carriers, and other data brokers, you can manually disable the feature. Here’s how:
If you also want to disable Better sharing on Google, go to Settings → Google → Manage your Google Account → Personal info → Contact info → Phone, select your number, and turn off the setting.
If you have multiple Google accounts on your phone, you’ll need to repeat these steps for each one. Unfortunately, verification sometimes turns itself back on automatically, and there’s no reliable way to prevent this on standard consumer phones with stock software.
Keep in mind that disabling verification means losing access to RCS chats in Google Messages — forcing you to fall back on basic SMS, or switch to alternative secure messaging apps. You also won’t be able to use that number for quick account recovery should you forget your password.
To thoughtfully customize your privacy settings across all your devices — regardless of the operating system, browser, or app — check out our free online tool, Privacy Checker.
Curious about other privacy risks you might not even know exist? Check out our other deep dives, here:
Threat actors are already gearing up for this year’s biggest football (soccer) event, the World Cup 2026. With millions of fans looking for ways to stream matches online, many will turn to IPTV apps to watch live TV broadcasts over the internet. It’s no surprise, then, that cybersecurity researchers have discovered multiple campaigns over the past few months where malware was disguised as fake Android IPTV apps.
In this post, we discuss what IPTV apps are, how criminals use fake versions to spread malware, what this malware is capable of, and, most importantly, how to avoid becoming a victim.
IPTV stands for Internet Protocol Television. This technology delivers TV content over the internet instead of through cable, over-the-air antennas, or satellites. Naturally, the simplest and most common examples of IPTV are the official platforms of TV networks, which can include both websites and dedicated apps.
However, alongside official options, pirate IPTV services also exist. They usually lure users with free or dirt-cheap access to content that can otherwise be hard to find without expensive subscriptions — most notably broadcasts of various sporting events; football matches in particular.
As is typically the case with pirated content, these apps are blocked from official app stores, forcing users to download them from third-party sites. Consequently, the risk of using these services isn’t tied to IPTV technology itself, but rather to the fake apps and modified APK files distributed under the guise of well-known platforms — both official and pirated.
For instance, in February researchers found the Massiv banking Trojan distributed under the guise of fake IPTV apps. Even then, experts noted that this wasn’t the only malware leveraging this tactic — several others were also spotted in the wild. The primary targets of these IPTV-mimicking malicious fakes have mostly been users in Portugal, Spain, France, and Türkiye.
In most cases, the discovered fake IPTV apps lacked the advertised functionality, so users didn’t get access to any content after installing the apps. Instead, the fake app would open the website of a legitimate IPTV service in a built-in browser to mimic normal functioning and avoid raising user suspicion.
Of course, the most interesting activity happened out of the user’s sight. These are some of the features the malware did have:
The Massiv banking Trojan mimics the interface of the Portuguese government app Chave Móvel Digital in a fake pop-up window, looking even more convincing than the official version from Google Play. Source
In March, researchers reported on a new campaign where several fake IPTV apps were used to distribute an even more advanced and feature-rich malware strain: Perseus.
Research into Perseus shows that the malware is based on the source code of an Android banking Trojan called Cerberus, which leaked nearly six years ago. Perseus comes in two different versions: Turkish and English. The English-language version is more advanced and shows clear signs of AI-driven refinement.
Perseus abuses Accessibility Services, a set of Android features originally designed to make life easier for users with severe visual impairments. Fraudsters learned long ago how to leverage this tool to steal data from Android devices — a topic we’ve covered in detail across several of our posts.
An example of a malicious APK disguised as Roja Directa TV, another IPTV app. Source
By abusing Accessibility Services, Perseus gains remote control over the victim’s device. Here’s what it can do:
On top of that, the English-language version of Perseus boasts another notable feature. The malware can hunt for sensitive information like passwords, recovery phrases, and financial data across an entire range of note-taking apps: Google Keep, Xiaomi Notes, Samsung Notes, ColorNote, Evernote, Microsoft OneNote, and Simple Notes.
All of these capabilities help criminals drain football fans’ money not just from various banking services, but from cryptocurrency apps as well.
The World Cup is just around the corner, and millions of fans worldwide will definitely want to tune in to this year’s premier football event. Past experience shows that cybercriminals frequently cash in on major spectacles like this. So, how can you watch the matches safely?
You can’t even watch TV safely anymore these days! Check out other threats facing TV lovers:
IT threat evolution in Q1 2026. Mobile statistics
IT threat evolution in Q1 2026. Non-mobile statistics
In the third quarter of 2025, we updated the methodology for calculating statistical indicators based on the Kaspersky Security Network. These changes affected all sections of the report except for the statistics on installation packages, which remained unchanged.
To illustrate the differences between the reporting periods, we have also recalculated data for the previous quarters. Consequently, these figures may significantly differ from the previously published ones. However, subsequent reports will employ this new methodology, enabling precise comparisons with the data presented in this post.
The Kaspersky Security Network (KSN) is a global network for analyzing anonymized threat information, voluntarily shared by users of Kaspersky solutions. The statistics in this report are based on KSN data unless explicitly stated otherwise.
According to Kaspersky Security Network, in Q1 2026:
The number of malware, adware, or unwanted software attacks on mobile devices decreased to 2,676,328 in Q1, down from 3,239,244 in the previous quarter.
Attacks on users of Kaspersky mobile solutions, Q3 2024 — Q1 2026 (download)
The overall drop in attack volume stems primarily from a reduction in adware and RiskTool detections. Nonetheless, this trend does not equate to a lower risk for mobile users. As shown later in this report, the number of unique users targeted by these threats remained relatively stable.
In Q1, Synthient researchers identified a link between the notorious Kimwolf botnet and the IPIDEA proxy network. This network was later taken down in cooperation with GTIG.
In early 2026, we discovered several apps on Google Play and the App Store that contained a new version of the SparkCat crypto stealer.
The Trojan code, meticulously concealed, was embedded into the infected Android apps. The obfuscated malicious Rust library was decrypted using a Dalvik-like virtual machine custom-built by the attackers. The iOS version of the malware also underwent several changes; specifically, the attackers began leveraging Apple’s proprietary Vision framework for optical character recognition (OCR).
The number of Android malware samples saw a slight increase compared to Q4 2025, reaching a total of 306,070.
Detected malicious and potentially unwanted installation packages, Q1 2025 — Q1 2026 (download)
The detected installation packages were distributed by type as follows:
Detected mobile apps by type, Q4 2025* — Q1 2026 (download)
* Data for the previous quarter may differ slightly from previously published figures due to certain verdicts being retrospectively revised.
Threat actors once again ramped up the production of new banking Trojans; as a result, this category overtook all others in volume, accounting for more than half of all installation packages.
Share* of users attacked by the given type of malicious or potentially unwanted app out of all targeted users of Kaspersky mobile products, Q4 2025 — Q1 2026 (download)
* The total percentage may exceed 100% if the same users encountered multiple attack types.
Following the surge in banking Trojan installation packages, the number of associated attacks also rose, causing Trojan-Banker apps to climb one spot in terms of their share of targeted users. Mamont variants emerged as the most prevalent banking Trojans, accounting for 73.5% of detections, with the rest of the users encountering Faketoken, Rewardsteal, Creduz, and other families.
Yet banking Trojans were still outpaced by adware and RiskTool-type unwanted apps when measured by the total number of affected users. Despite a decrease in their share of installation packages, these two app types retained their positions as the top two threats by attack volume. The most common adware detections involved HiddenAd (44.9%) and MobiDash (38.1%), while most frequently seen RiskTool apps were Revpn (67%) and SpyLoan (20.5%).
Note that the malware rankings below exclude riskware or potentially unwanted software, such as RiskTool or adware.
| Verdict | %* Q4 2025 | %* Q1 2026 | Difference in p.p. | Change in ranking |
| Backdoor.AndroidOS.Triada.ag | 2.62 | 7.09 | +4.48 | +10 |
| DangerousObject.Multi.Generic. | 6.75 | 5.84 | -0.92 | -1 |
| DangerousObject.AndroidOS.GenericML. | 3.52 | 5.51 | +1.99 | +6 |
| Trojan-Banker.AndroidOS.Mamont.jo | 0.00 | 5.28 | +5.28 | |
| Trojan.AndroidOS.Fakemoney.v | 5.40 | 3.44 | -1.96 | -1 |
| Trojan-Downloader.AndroidOS.Keenadu.l | 0.00 | 3.35 | +3.35 | |
| Trojan-Banker.AndroidOS.Mamont.jx | 0.00 | 3.09 | +3.09 | |
| Backdoor.AndroidOS.Triada.z | 4.87 | 3.08 | -1.79 | -2 |
| Trojan.AndroidOS.Triada.fe | 5.01 | 2.98 | -2.02 | -4 |
| Backdoor.AndroidOS.Keenadu.a | 2.07 | 2.73 | +0.66 | +6 |
| Trojan-Banker.AndroidOS.Mamont.jg | 0.34 | 2.37 | +2.03 | |
| Trojan.AndroidOS.Triada.hf | 2.15 | 2.23 | +0.07 | +3 |
| Trojan.AndroidOS.Boogr.gsh | 2.35 | 2.15 | -0.20 | 0 |
| Trojan.AndroidOS.Triada.ii | 5.68 | 2.07 | -3.60 | -11 |
| Backdoor.AndroidOS.Triada.ae | 1.91 | 1.76 | -0.16 | +3 |
| Backdoor.AndroidOS.Triada.ab | 1.79 | 1.72 | -0.08 | +3 |
| Trojan.AndroidOS.Triada.gn | 2.38 | 1.58 | -0.80 | -5 |
| Trojan-Banker.AndroidOS.Mamont.gg | 1.56 | 1.50 | -0.06 | +2 |
| Trojan.AndroidOS.Triada.ga | 1.48 | 1.50 | +0.01 | +4 |
| Backdoor.AndroidOS.Triada.ad | 0.53 | 1.40 | +0.87 | +44 |
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.
The pre-installed Triada.ag backdoor rose to the top spot; it is similar to the older Triada.z version we documented previously. Because the same variant was pre-installed across a wide range of devices, the total number of affected users is aggregated. Consequently, Triada outpaced even Mamont, as users encountered a variety of Mamont variants, causing the share of that banking Trojan to spread across multiple rows. Other pre-installed Triada variants (Triada.z, Triada.ae, Triada.ab, and Triada.ad) also made the rankings. Furthermore, we observed increasing activity from the Keenadu.a backdoor, while diverse variants of the embedded Triada Trojan remained in the rankings.
Q1 2026 saw a characteristic rise in mobile banking Trojan activity, with the number of packages totaling 162,275, a 50% increase compared to the prior quarter.
Number of installation packages for mobile banking Trojans detected by Kaspersky, Q1 2025 — Q1 2026 (download)
We saw a similar growth in the previous quarter, with banking Trojan volumes rising by 50% during that period as well. Various Mamont variants accounted for the absolute majority of packages and represented nearly every entry in the rankings of most frequent banking Trojans by affected user count.
| Verdict | %* Q4 2025 | %* Q1 2026 | Difference in p.p. | Change in ranking |
| Trojan-Banker.AndroidOS.Mamont.jo | 0.00 | 15.75 | +15.75 | |
| Trojan-Banker.AndroidOS.Mamont.jx | 0.00 | 9.22 | +9.22 | |
| Trojan-Banker.AndroidOS.Mamont.jg | 1.47 | 7.08 | +5.61 | +24 |
| Trojan-Banker.AndroidOS.Mamont.gg | 6.79 | 4.48 | -2.32 | -3 |
| Trojan-Banker.AndroidOS.Mamont.ks | 0.00 | 3.98 | +3.98 | |
| Trojan-Banker.AndroidOS.Agent.ws | 6.03 | 3.78 | -2.25 | -2 |
| Trojan-Banker.AndroidOS.Mamont.hl | 4.30 | 3.27 | -1.03 | +1 |
| Trojan-Banker.AndroidOS.Mamont.iv | 6.00 | 3.08 | -2.92 | -3 |
| Trojan-Banker.AndroidOS.Mamont.jb | 3.93 | 3.07 | -0.86 | +1 |
| Trojan-Banker.AndroidOS.Mamont.jv | 0.00 | 2.79 | +2.79 |
* Unique users who encountered this malware as a percentage of all users of Kaspersky mobile security solutions who encountered banking threats.
IT threat evolution in Q1 2026. Mobile statistics
IT threat evolution in Q1 2026. Non-mobile statistics
In the third quarter of 2025, we updated the methodology for calculating statistical indicators based on the Kaspersky Security Network. These changes affected all sections of the report except for the statistics on installation packages, which remained unchanged.
To illustrate the differences between the reporting periods, we have also recalculated data for the previous quarters. Consequently, these figures may significantly differ from the previously published ones. However, subsequent reports will employ this new methodology, enabling precise comparisons with the data presented in this post.
The Kaspersky Security Network (KSN) is a global network for analyzing anonymized threat information, voluntarily shared by users of Kaspersky solutions. The statistics in this report are based on KSN data unless explicitly stated otherwise.
According to Kaspersky Security Network, in Q1 2026:
The number of malware, adware, or unwanted software attacks on mobile devices decreased to 2,676,328 in Q1, down from 3,239,244 in the previous quarter.
Attacks on users of Kaspersky mobile solutions, Q3 2024 — Q1 2026 (download)
The overall drop in attack volume stems primarily from a reduction in adware and RiskTool detections. Nonetheless, this trend does not equate to a lower risk for mobile users. As shown later in this report, the number of unique users targeted by these threats remained relatively stable.
In Q1, Synthient researchers identified a link between the notorious Kimwolf botnet and the IPIDEA proxy network. This network was later taken down in cooperation with GTIG.
In early 2026, we discovered several apps on Google Play and the App Store that contained a new version of the SparkCat crypto stealer.
The Trojan code, meticulously concealed, was embedded into the infected Android apps. The obfuscated malicious Rust library was decrypted using a Dalvik-like virtual machine custom-built by the attackers. The iOS version of the malware also underwent several changes; specifically, the attackers began leveraging Apple’s proprietary Vision framework for optical character recognition (OCR).
The number of Android malware samples saw a slight increase compared to Q4 2025, reaching a total of 306,070.
Detected malicious and potentially unwanted installation packages, Q1 2025 — Q1 2026 (download)
The detected installation packages were distributed by type as follows:
Detected mobile apps by type, Q4 2025* — Q1 2026 (download)
* Data for the previous quarter may differ slightly from previously published figures due to certain verdicts being retrospectively revised.
Threat actors once again ramped up the production of new banking Trojans; as a result, this category overtook all others in volume, accounting for more than half of all installation packages.
Share* of users attacked by the given type of malicious or potentially unwanted app out of all targeted users of Kaspersky mobile products, Q4 2025 — Q1 2026 (download)
* The total percentage may exceed 100% if the same users encountered multiple attack types.
Following the surge in banking Trojan installation packages, the number of associated attacks also rose, causing Trojan-Banker apps to climb one spot in terms of their share of targeted users. Mamont variants emerged as the most prevalent banking Trojans, accounting for 73.5% of detections, with the rest of the users encountering Faketoken, Rewardsteal, Creduz, and other families.
Yet banking Trojans were still outpaced by adware and RiskTool-type unwanted apps when measured by the total number of affected users. Despite a decrease in their share of installation packages, these two app types retained their positions as the top two threats by attack volume. The most common adware detections involved HiddenAd (44.9%) and MobiDash (38.1%), while most frequently seen RiskTool apps were Revpn (67%) and SpyLoan (20.5%).
Note that the malware rankings below exclude riskware or potentially unwanted software, such as RiskTool or adware.
| Verdict | %* Q4 2025 | %* Q1 2026 | Difference in p.p. | Change in ranking |
| Backdoor.AndroidOS.Triada.ag | 2.62 | 7.09 | +4.48 | +10 |
| DangerousObject.Multi.Generic. | 6.75 | 5.84 | -0.92 | -1 |
| DangerousObject.AndroidOS.GenericML. | 3.52 | 5.51 | +1.99 | +6 |
| Trojan-Banker.AndroidOS.Mamont.jo | 0.00 | 5.28 | +5.28 | |
| Trojan.AndroidOS.Fakemoney.v | 5.40 | 3.44 | -1.96 | -1 |
| Trojan-Downloader.AndroidOS.Keenadu.l | 0.00 | 3.35 | +3.35 | |
| Trojan-Banker.AndroidOS.Mamont.jx | 0.00 | 3.09 | +3.09 | |
| Backdoor.AndroidOS.Triada.z | 4.87 | 3.08 | -1.79 | -2 |
| Trojan.AndroidOS.Triada.fe | 5.01 | 2.98 | -2.02 | -4 |
| Backdoor.AndroidOS.Keenadu.a | 2.07 | 2.73 | +0.66 | +6 |
| Trojan-Banker.AndroidOS.Mamont.jg | 0.34 | 2.37 | +2.03 | |
| Trojan.AndroidOS.Triada.hf | 2.15 | 2.23 | +0.07 | +3 |
| Trojan.AndroidOS.Boogr.gsh | 2.35 | 2.15 | -0.20 | 0 |
| Trojan.AndroidOS.Triada.ii | 5.68 | 2.07 | -3.60 | -11 |
| Backdoor.AndroidOS.Triada.ae | 1.91 | 1.76 | -0.16 | +3 |
| Backdoor.AndroidOS.Triada.ab | 1.79 | 1.72 | -0.08 | +3 |
| Trojan.AndroidOS.Triada.gn | 2.38 | 1.58 | -0.80 | -5 |
| Trojan-Banker.AndroidOS.Mamont.gg | 1.56 | 1.50 | -0.06 | +2 |
| Trojan.AndroidOS.Triada.ga | 1.48 | 1.50 | +0.01 | +4 |
| Backdoor.AndroidOS.Triada.ad | 0.53 | 1.40 | +0.87 | +44 |
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.
The pre-installed Triada.ag backdoor rose to the top spot; it is similar to the older Triada.z version we documented previously. Because the same variant was pre-installed across a wide range of devices, the total number of affected users is aggregated. Consequently, Triada outpaced even Mamont, as users encountered a variety of Mamont variants, causing the share of that banking Trojan to spread across multiple rows. Other pre-installed Triada variants (Triada.z, Triada.ae, Triada.ab, and Triada.ad) also made the rankings. Furthermore, we observed increasing activity from the Keenadu.a backdoor, while diverse variants of the embedded Triada Trojan remained in the rankings.
Q1 2026 saw a characteristic rise in mobile banking Trojan activity, with the number of packages totaling 162,275, a 50% increase compared to the prior quarter.
Number of installation packages for mobile banking Trojans detected by Kaspersky, Q1 2025 — Q1 2026 (download)
We saw a similar growth in the previous quarter, with banking Trojan volumes rising by 50% during that period as well. Various Mamont variants accounted for the absolute majority of packages and represented nearly every entry in the rankings of most frequent banking Trojans by affected user count.
| Verdict | %* Q4 2025 | %* Q1 2026 | Difference in p.p. | Change in ranking |
| Trojan-Banker.AndroidOS.Mamont.jo | 0.00 | 15.75 | +15.75 | |
| Trojan-Banker.AndroidOS.Mamont.jx | 0.00 | 9.22 | +9.22 | |
| Trojan-Banker.AndroidOS.Mamont.jg | 1.47 | 7.08 | +5.61 | +24 |
| Trojan-Banker.AndroidOS.Mamont.gg | 6.79 | 4.48 | -2.32 | -3 |
| Trojan-Banker.AndroidOS.Mamont.ks | 0.00 | 3.98 | +3.98 | |
| Trojan-Banker.AndroidOS.Agent.ws | 6.03 | 3.78 | -2.25 | -2 |
| Trojan-Banker.AndroidOS.Mamont.hl | 4.30 | 3.27 | -1.03 | +1 |
| Trojan-Banker.AndroidOS.Mamont.iv | 6.00 | 3.08 | -2.92 | -3 |
| Trojan-Banker.AndroidOS.Mamont.jb | 3.93 | 3.07 | -0.86 | +1 |
| Trojan-Banker.AndroidOS.Mamont.jv | 0.00 | 2.79 | +2.79 |
* Unique users who encountered this malware as a percentage of all users of Kaspersky mobile security solutions who encountered banking threats.
Google is continuously advancing the security of Pixel devices. We have been focusing on hardening the cellular baseband modem against exploitation. Recognizing the risks associated within the complex modem firmware, Pixel 9 shipped with mitigations against a range of memory-safety vulnerabilities. For Pixel 10, Google is advancing its proactive security measures further. Following our previous discussion on "Deploying Rust in Existing Firmware Codebases", this post shares a concrete application: integrating a memory-safe Rust DNS(Domain Name System) parser into the modem firmware. The new Rust-based DNS parser significantly reduces our security risk by mitigating an entire class of vulnerabilities in a risky area, while also laying the foundation for broader adoption of memory-safe code in other areas.
Here we share our experience of working on it, and hope it can inspire the use of more memory safe languages in low-level environments.
In recent years, we have seen increasing interest in the cellular modem from attackers and security researchers. For example, Google's Project Zero gained remote code execution on Pixel modems over the Internet. Pixel modem has tens of Megabytes of executable code. Given the complexity and remote attack surface of the modem, other critical memory safety vulnerabilities may remain in the predominantly memory-unsafe firmware code.
The DNS protocol is most commonly known in the context of browsers finding websites. With the evolution of cellular technology, modern cellular communications have migrated to digital data networks; consequently, even basic operations such as call forwarding rely on DNS services.
DNS is a complex protocol and requires parsing of untrusted data, which can lead to vulnerabilities, particularly when implemented in a memory-unsafe language (example: CVE-2024-27227). Implementing the DNS parser in Rust offers value by decreasing the attack surfaces associated with memory unsafety.
DNS already has a level of support in the open-source Rust community. We evaluated multiple open source crates that implement DNS. Based on criteria shared in earlier posts, we identified hickory-proto as the best candidate. It has excellent maintenance, over 75% test coverage, and widespread adoption in the Rust community. Its pervasiveness shows its potential as the de-facto DNS choice and long term support. Although hickory-proto initially lacked no_std support, which is needed for Bare-metal environments (see our previous post on this topic), we were able to add support to it and its dependencies.
Login
no_std supportThe work to enable no_std for hickory-proto is mostly mechanical. We shared the process in a previous post. We undertook modifications to hickory_proto and its dependencies to enable no_std support. The upstream no_std work also results in a no_std URL parser, beneficial to other projects.
The above PRs are great examples of how to extend no_std support to existing std-only crates.
Code size is the one of the factors that we evaluated when picking the DNS library to use.
| Code size by category |
Rust implemented Shim that calls Hickory-proto on receiving a DNS response | 4KB |
| core, alloc, compiler_builtins (reusable, one-time cost) |
17KB | |
| Hickory-proto library and dependencies | 350KB |
| Sum | 371KB |
We built prototypes and measured size with size-optimized settings. Expectedly, hickory_proto is not designed with embedded use in mind, and is not optimized for size. As the Pixel modem is not tightly memory constrained, we prioritized community support and code quality, leaving code size optimizations as future work.
However, the additional code size may be a blocker for other embedded systems. This could be addressed in the future by adding additional feature flags to conditionally compile only required functionality. Implementing this modularity would be a valuable future work.
Before building the Rust DNS library, we defined several Rust unit tests to cover basic arithmetic, dynamic allocations, and FFI to verify the integration of Rust with the existing modem firmware code base.
While using cargo is the default choice for compilation in the Rust ecosystem, it presents challenges when integrating it into existing build systems. We evaluated two options:
cargo to build a staticlib before the modem builds. Then add the produced staticlib into the linking step.rustc and integrate the Rust compilation steps into the existing modem build system.Option #1 does not scale if we are going to add more Rust components in the future, as linking multiple staticlibs may cause duplicated symbol errors. We chose option #2 as it scales more easily and allows tighter integration into our existing build system. Our existing C/C++ codebase uses Pigweed to drive the primary build system. Pigweed supports Rust targets (example) with direct calls to rustc through rust tools defined in GN.
We compiled all the Rust crates, including hickory-proto, its dependencies, and core, compiler_builtin, alloc, to rlib. Then, we created a staticlib target with a single lib.rs file which references all the rlib crates using extern crate keywords.
Android’s Rust Toolchain distributes source code of core, alloc, and compiler_builtins, and we leveraged this for the modem. They can be included to the build graph by adding a GN target with crate_root pointing to the root lib.rs of each crate.
Pixel modem firmware already has a well-tested and specialized global memory allocation system to support some dynamic memory allocations. alloc support was added by implementing the GlobalAlloc with FFI calls to the allocators C APIs:
use core::alloc::{GlobalAlloc, Layout};
extern "C" {
fn mem_malloc(size: usize, alignment: usize) -> *mut u8;
fn mem_free(ptr: *mut u8, alignment: usize);
}
struct MemAllocator;
unsafe impl GlobalAlloc for MemAllocator {
unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
mem_malloc(layout.size(), layout.align())
}
unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
mem_free(ptr, layout.align());
}
}
#[global_allocator]
static ALLOCATOR: MemAllocator = MemAllocator;
Pixel modem firmware already implements a backend for the Pigweed crash facade as the global crash handler. Exposing it into Rust panic_handler through FFI unifies the crash handling for both Rust and C/C++ code.
#![no_std]
use core::panic::PanicInfo;
extern "C" {
pub fn PwCrashBackend(sigature: *const i8, file_name: *const i8, line: u32);
}
#[panic_handler]
fn panic(panic_info: &PanicInfo) -> ! {
let mut filename = "";
let mut line_number: u32 = 0;
if let Some(location) = panic_info.location() {
filename = location.file();
line_number = location.line();
}
let mut cstr_buffer = [0u8; 128];
// Never writes to the last byte to make sure `cstr_buffer` is always zero
// terminated.
let (_, writer) = cstr_buffer.split_last_mut().unwrap();
for (place, ch) in writer.iter_mut().zip(filename.bytes()) {
*place = ch;
}
unsafe {
PwCrashBackend(
"Rust panic\0".as_ptr() as *const i8,
cstr_buffer.as_ptr() as *const i8,
line_number,
);
}
loop {}
}
The Pixel modem firmware linking has a step that calls the linker to link all the objects generated from C/C++ code. By using llvm-ar -x to extract object files from the Rust combined staticlib and supplying them to the linker, the Rust code appears in the final modem image.
There was a performance issue we experienced due to weak symbols during linking. The inclusion of Rust core and compiler-builtin caused unexpected power and performance regressions on various tests. Upon analysis, we realized that modem optimized implementations of memset and memcpy provided by the modem firmware are accidentally replaced by those defined in compiler_builtin. It seems to happen because both compiler_builtin crate and the existing codebase defines symbols as weak, linker has no way to figure out which one is weaker. We fixed the regression by stripping the compiler_builtin crate before linking using a one line shell script.
llvm-ar -t <rust staticlib> | grep compiler_builtins | xargs llvm-ar -d <rust staticlib>
For the DNS parser, we declared the DNS response parsing API in C and then implemented the same API in Rust.
int32_t process_dns_response(uint8_t*, int32_t);
The Rust function returns an integer standing for the error code. The received DNS answers in the DNS response are required to be updated to in-memory data structures that are coupled with the original C implementation, therefore, we use existing C functions to do it. The existing C functions are dispatched from the Rust implementation.
pub unsafe extern "C" fn process_dns_response(
dns_response: *const u8,
response_len: i32,
) -> i32 {
//... validate inputs `dns_response` and `response_len`.
// SAFETY:
// It is safe because `dns_response` is null checked above. `response_len`
// is passed in, safe as long as it is set correctly by vendor code.
match process_response(unsafe {
slice::from_raw_parts(dns_response, response_len)
}) {
Ok(()) => 0,
Err(err) => err.into(),
}
}
fn process_response(response: &[u8]) -> Result<()> {
let response = hickory_proto::op::Message::from_bytes(response)?;
let response = hickory_proto::xfer::DnsResponse::from_message(response)?;
for answer in response.answers() {
match answer.record_type() {
hickory_proto::RecordType:... => {
// SAFETY:
// It is safe because the callback function does not store
// reference of the inputs or their members.
unsafe {
callback_to_c_function(...)?;
}
}
// ... more match arms omitted.
}
}
Ok(())
}
In our case, the DNS responding parsing function API is simple enough for us to hand write, while the callbacks back to C functions for handling the response have complex data type conversions. Therefore, we leveraged bindgen to generate FFI code for the callbacks.
Even with all features disabled, hickory-proto introduces more than 30 dependent crates. Manually written build rules are difficult to ensure correctness and scale poorly when upgrading dependencies into new versions.
Fuchsia has developed cargo-gnaw to support building their third party Rust crates. Cargo-gnaw works by invoking cargo metadata to resolve dependencies, then parse and generate GN build rules. This ensures correctness and ease of maintenance.
The Pixel 10 series of phones marks a pivotal moment, being the first Pixel device to integrate a memory-safe language into its modem.
While replacing one piece of risky attack surface is itself valuable, this project lays the foundation for future integration of memory-safe parsers and code into the cellular baseband, ensuring the baseband’s security posture will continue to improve as development continues.
Special thanks to Armando Montanez, Bjorn Mellem, Boky Chen, Cheng-Yu Tsai, Dominik Maier, Erik Gilling, Ever Rosales, Hungyen Weng, Ivan Lozano, James Farrell, Jeffrey Vander Stoep, Jiacheng Lu, Jingjing Bu, Min Xu, Murphy Stein, Ray Weng, Shawn Yang, Sherk Chung, Stephan Chen, Stephen Hines.
Modern digital security is at a turning point. We are on the threshold of using quantum computers to solve "impossible" problems in drug discovery, materials science, and energy—tasks that even the most powerful classical supercomputers cannot handle. However, the same unique ability to consider different options simultaneously also allows these machines to bypass our current digital locks. This puts the public-key cryptography we’ve relied on for decades at risk, potentially compromising everything from bank transfers to trade secrets. To secure our future, it is vital to adopt the new Post-Quantum Cryptography (PQC) standards National Institute of Standards and Technology (NIST) is urging before large-scale, fault-tolerant quantum computers become a reality.
To stay ahead of the curve, the technology industry must undertake a proactive, multi-year migration to Post-Quantum Cryptography (PQC). We have been preparing for a post-quantum world since 2016, conducting pioneering experiments with post-quantum cryptography, rolling out post-quantum capabilities in our products, and sharing our expertise through threat models and technical papers. For Android, the objective extends beyond patching individual applications or transport protocols. The imperative is to ensure that the entire platform architecture is resilient for the decades to come.
We are beginning tests of PQC enhancements starting in the next Android 17 beta, followed by general availability in the Android 17 production release. This deployment introduces a comprehensive architectural upgrade that is being rolled out across the operating system. By integrating the recently finalized NIST PQC standards deep into the platform, we’re establishing a new, quantum-resistant chain of trust. This chain of trust secures the platform continuously—from the moment the OS powers on, to the execution of applications distributed globally. Android is swapping today’s digital locks for advanced encryption to help enhance the security of every app you download—no matter how powerful future supercomputers get.
Security on any computing device begins when the hardware starts; if the underlying operating system is compromised, all subsequent software protections fail. As quantum computing advances, adversaries could potentially forge digital signatures to bypass these foundational integrity checks. To secure the platform against this looming threat, Android 17 introduces two major post-quantum cryptographic (PQC) upgrades:
Protecting the underlying operating system is only the first layer of defense; developers must be equipped with the cryptographic primitives necessary to leverage PQC keys and establish robust identity verification.
Implementing lattice-based cryptography, which requires significantly larger key sizes and memory footprints than classical elliptic curve cryptography, within the severely resource-constrained Trusted Execution Environment (TEE), represents a major engineering achievement. This capability is designed to support the hardware roots of trust and can now generate and verify post-quantum signatures.
Building on this hardware foundation, Android 17 updates Android Keystore to natively support ML-DSA. This allows applications to leverage quantum-safe signatures entirely within the device’s secure hardware, isolating sensitive key material from the main operating system. The SDK exposes both ML-DSA-65, and ML-DSA-87, enabling developers to seamlessly integrate these using the standard KeyPairGenerator API. This establishes a new era of identity and authentication for the app ecosystem without requiring developers to engineer proprietary cryptographic implementations.
Android is committed to ensuring the platform is PQC resistant and extending the chain of PQC resistance to application signatures. The mechanisms used to verify the authenticity of applications are being upgraded to ensure that app installations and subsequent updates are strictly tamper-proof against quantum-enabled signature forgery. The platform will verify PQC signatures over APKs to enable this chain of trust.
To bring these critical protections to the wider developer community with minimal friction, the transition will be supported through Play App Signing. This approach provides an immediate bridge to quantum safety for the majority of active installs. Google Play will let developers automatically generate 'hybrid' signature blocks that combine classical and PQC keys.
Updating keys across billions of active devices is a complex operational endeavor. Play App Signing leverages Google Cloud KMS, which helps ensure industry-leading compliance standards, to secure signing keys. By managing signing keys securely in the cloud, Google Play enables developers to seamlessly upgrade their app security to PQC standards without the burden of complex, manual key management.
During the Android 17 release cycle, Google Play will handle the generation of quantum-safe ML-DSA signing keys for new apps and existing apps that opt-in, independent of the applications target API . Later, developers will be able to choose their own classical and ML-DSA signing keys and delegate them to Google Play for their hybrid key upgrade. To promote security best practices, Google Play will also start prompting developers to upgrade their signing keys at least every two years.
Google’s post-quantum transition began in 2016, and Android 17 marks the first phase of Android’s post-quantum transition:
Our roadmap further integrates post-quantum key encapsulation into KeyMint, Key Attestation and Remote Key Provisioning. This evolution is intended to bolster the security of the entire identity lifecycle—from hardware-level DICE measurements to our remote attestation servers—ensuring the Android ecosystem remains resilient and private against the quantum threats of tomorrow.
Google has announced the introduction of Advanced Flow, designed to let Android users install apps from unverified developers more safely than before.
This process is known as sideloading. It means installing an app on your device from somewhere other than the Google Play store, usually by downloading and opening its installation file yourself.
Right now, that typically involves:
From Google’s point of view, this has been a security weak spot. Scammers regularly abuse sideloading to trick victims into installing malware while bypassing built‑in protections.
They often pressure victims into installing apps that turn out to be infostealers or other malware. According to research by the Global Anti-Scam Alliance (GASA), scams caused an estimated $442 billion in losses last year.
So anything that helps reduce that risk is welcome.
What Google is changing isn’t dramatic, but it does make the process of installing an app from outside the official Play Store more secure. In simple terms, Advanced Flow adds extra steps and delays so scammers can’t rush people into disabling protections and installing their malware.
To sideload apps using Advanced Flow, users will need to go through a series of steps:
Once you’ve confirmed you understand the risks, you’re all set to install apps from unverified developers. You can allow this for seven days or indefinitely. For safety, you’ll still see a warning that the app is from an unverified developer, but you can just tap “Install Anyway.”
In addition to the Advanced Flow, Google is introducing free, limited distribution accounts for students and hobbyists. These let developers share apps with a small group (up to 20 devices) without needing ID verification or a registration fee.
So after these changes, these will be the options for users that have “developer mode” enabled on their Android device.
Advanced Flow is expected to roll out in August 2026.
Overall, it seems a reasonable compromise. Sideloading isn’t going away, so this keeps that ability but adds meaningful barriers against scam‑driven installs, thwarting social‑engineering campaigns without outright killing power‑user workflows. The one-day delay could turn out to be frustrating though, even if it’s only a one-time event.
We don’t just report on phone security—we provide it
Cybersecurity risks should never spread beyond a headline. Keep threats off your mobile devices by downloading Malwarebytes for iOS, and Malwarebytes for Android today.
Google just dropped a bombshell for app developers with the latest version of its Android mobile operating system. The company can now prevent apps from installing if they try to use the system’s accessibility features.
The new development, live in version 17.2 of Android, is all about security, explains the company. It stops certain kinds of apps from using the accessibility service if Advanced Protection Mode (APM) is enabled.
The accessibility API lets app developers support users living with disabilities who need extra help using their phones. Apps can use this API to access the screen in unique ways, control input for the user, and use voice services, for example.
Sadly, as with most useful tools, someone will always find a way to misuse it and ruin it for everyone else. Malware developers have been using this API for years as a way into your bank account. The accessibility service has a lot of power: Any app with permissions to use it can read what’s on your screen.
Many Android banking Trojans are little more than accessibility API wrappers with criminal intent. They steal 2FA codes, impersonate victims, and drain accounts while victims sleep.
Two tricks dominate. The first is fake overlays. The accessibility API lets you put overlays on top of another app’s screen. Banking and cryptocurrency Trojan developers can use this to capture your keystrokes (you think you’re just logging into your banking app, but malware is collecting everything you type).
The second is permission abuse. Once the Trojan has your passwords, it can authorize its own transactions.
The number of malware frameworks taking advantage of the accessibility API has grown. DroidLock uses it to steal your personal data before demanding a ransom. Albiriox uses it to install itself and give remote control to attackers halfway around the world.
We saw both in December, and just last month Malwarebytes researcher Stefan Dasic noticed an accessibility service-abusing malware program posing as a fake Google Security page.
Google has tried before to curb misuse of the API. In 2017, it warned developers to justify their use of accessibility features or risk removal from the Play Store. Developers revolted, and Google relented. But then, in November 2021, it began demanding permission forms for accessibility API usage for Android 12+ apps.
Now the company is getting tougher still, enforcing stricter accessibility API rules. Apps can no longer freely enable accessibility services using a simple software flag. Instead, only apps whose core purpose is accessibility will be allowed to use it.
Google’s examples include screen readers, switch inputs, voice controls, and Braille displays. With these new rules, password managers or automation apps aren’t getting to the accessibility API anymore.
At least, not if the user has APM turned on.
Launched in May last year, APM is Google’s version of Apple’s Lockdown Mode. It introduces far tighter security controls for people who switch it on, making it harder for malware to exploit them.
The trade-off for that extra security is more limited functionality. For example, only apps from trusted sources will install, and data transfer via USB is restricted. Accessibility API access is now restricted too.
So now, you can be a password manager or an accessibility tool, but not both. Developers relying on accessibility for convenience features will need to find another way.
This is Google acknowledging that some APIs are too dangerous to leave open, even if some legitimate apps suffer. The company is betting that most users care more about not getting robbed than having their password manager use the accessibility API for convenience.
Malware authors will adapt, as always. But for now, Google just made phones with APM turned on a lot harder to mess with.
We don’t just report on phone security—we provide it
Cybersecurity risks should never spread beyond a headline. Keep threats off your mobile devices by downloading Malwarebytes for iOS, and Malwarebytes for Android today.
Google has patched 129 vulnerabilities in Android in its March 2026 Android Security Bulletin, including a Qualcomm display flaw that is known to be actively exploited.
You can check your device’s Android version, security update level, and Google Play system update in Settings. You should get a notification when updates are available, but you can also check for them yourself.
On most phones, go to Settings > About phone (or About device), then tap Software updates to see if anything new is available. The exact steps may vary slightly depending on the brand and Android version you’re on.
If your Android phone shows a patch level of 2026-03-05 or later, these issues are fixed.
Keeping your device up to date protects you from known vulnerabilities and helps you stay safe. We know that because of patch gaps and end-of-support cycles, some users may not receive these updates. That’s why additional protection for your Android device is important.
The Android zero-day, tracked as CVE-2026-21385, is a high‑severity bug in a Qualcomm graphics/display component that attackers are already exploiting in limited, targeted attacks.
The vulnerability lives in an open‑source Qualcomm graphics/display component used by a large number of Android chipsets, with Qualcomm listing that well over 230 different chipset models are affected. Based on recently published Android and chipset market‑share percentages, it is reasonable to assume the issue affects hundreds of millions of devices worldwide, even if the exact number is hard to pin down.
On most Android phones, you can view the processor model in Settings > About phone (or About device) > Detailed info and specs, and look for entries such as “Processor,” “Chipset,” or “SoC.” Names like “Snapdragon 8 Gen 2,” “Snapdragon 778G,” or “Qualcomm SM8xxx/SM7xxx,” indicate a Qualcomm chipset and that the device may be in the affected family.
Google says there are signs that CVE‑2026‑21385 is already being used in “limited, targeted exploitation,” which usually means a small number of high‑value targets rather than broad, drive‑by attacks on the general public. Current descriptions point to a memory corruption scenario in the graphics component. The official description says:
“Memory corruption while using alignments for memory allocation.”
This means that if an attacker can get a malicious app or local code onto the device, they can feed specially crafted data into the graphics component’s driver and corrupt memory in a controlled way. In practice, a bug like this is a good candidate for turning a normal app’s limited access into something much more powerful, like using it as a building block in a chain of exploits to escalate privileges or to escape a sandbox.
As you can see, the attacker needs some kind of local foothold first, such as getting you to install a malicious app, exploiting another vulnerability, or abusing a compromised app already on the device.
From the available information, attackers would need to trick a user into installing a malicious app that could then compromise the device. That’s why it’s a good idea to follow these safety precautions:
We don’t just report on phone security—we provide it
Cybersecurity risks should never spread beyond a headline. Keep threats off your mobile devices by downloading Malwarebytes for iOS, and Malwarebytes for Android today.
We’ve shared how Android’s proactive, multi-layered scam defenses utilize Google AI to protect users around the world from over 10 billion suspected malicious calls and messages every month1. While that scale is significant, the true impact of these protections is best understood through the stories of the individuals they help keep safe every day. This includes people like Majik B., an IT professional in Sunnyvale, California.
Despite his technical background, Majik recently found himself on a call that felt dangerously legitimate. While using his Pixel, he received a call that appeared to be from his bank. The number looked correct, the caller knew his name and his address, and the story about a "suspicious charge" made perfect sense. "I’m usually pretty careful about this stuff," Majik recalled, "but I stayed on the line longer than I normally would. Even knowing how these scams work, it was convincing in the moment."
The turning point came when his phone displayed a Scam Detection warning during the call, which provided a critical moment to pause and reflect. Majik hung up, checked his bank app directly, and confirmed there was no fraudulent charge. For Majik, Scam Detection was the intervention he needed: “The warning is what made me pause and avoid a bad situation”.
While stories like Majik’s show how our existing protections provide a robust shield against scams, our work isn't done. As scammers evolve their tactics and create more convincing and personalized threats, we’re using the best of Google AI to stay one step ahead.
A recent evaluation by Counterpoint Research found that Android smartphones provide the most comprehensive AI-powered protections of any mobile platform. We are committed to building on this foundation by expanding our AI-powered protections to more users and devices, while rolling out new features that utilize on-device AI to defend against increasingly sophisticated threats.
To help protect you during phone calls, Scam Detection alerts you if a caller uses speech patterns commonly associated with fraud. We are bringing these protections to more of our users through new regional expansion and availability on new devices. Scam Detection for phone calls on Google Pixel devices is available in the US, UK, Australia, Canada, France, Germany, India, Ireland, Italy, Japan, Mexico, and Spain.
Scam Detection is already helping millions of users to stay safe from scammers, and we are expanding this feature to more manufacturers, starting with the Samsung Galaxy S26 series in the U.S. We are continuing to work with our partners to bring these industry-leading protections to even more users.
Powered by Gemini’s on-device model, Scam Detection provides intelligent protection against scam calls while ensuring that the processing stays on your device. This keeps your conversations private while delivering warnings in real-time. To preserve your privacy, the phone conversation processed by Scam Detection is neither stored on your device, nor shared outside of the device. To ensure you stay in total control of your experience, Scam Detection is turned off by default. When enabled, the feature only applies to calls identified as potential scams and is never used in calls with your contacts. You can easily manage these preferences in your phone settings whenever you choose.
We want everyone to feel secure when they open their messages, no matter where they are or what language they speak. To make this possible, we’ve now expanded Scam Detection for Google Messages to more than 20 countries. This includes support for several languages including English, Arabic, French, German, Portuguese, and Spanish.
Beyond reaching more people, we are also making our protections more intelligent. We are enhancing how Google Messages identifies fraudulent texts by utilizing our Gemini on-device model on the latest Android flagship devices in the US, Canada, and the UK. The added power of Gemini’s on-device model allows for a much more nuanced analysis of complex conversational threats.
For example, it can better detect the subtle conversational patterns used in job offer scams or sophisticated romance baiting scams (also known as “pig butchering”), a deceptive tactic where a scammer builds a long-term "relationship" with a potential victim to gain their trust, before tricking them into a fraudulent investment. Because these methods rely on gradual manipulation and don’t present typical warning signs, they need more advanced capabilities to catch them at scale. These advanced protections are now rolling out on Google Pixel 10 series and other select devices, and will be available on the Samsung Galaxy S26 series.
Gemini-powered Scam Detection alerts a user to a job offer scam
Android continues to set the standard in mobile scam protections by leveraging advanced AI to identify and intercept threats as they happen. As scammer’s strategies shift, we remain committed to developing equally adaptive and intelligent defenses. Our goal is to provide you with peace of mind so you can continue to connect and communicate with confidence, knowing our multi-layered defenses are there to help protect your financial and personal data against mobile scams.
Disclaimers
1: This total comprises all instances where a message or call was proactively blocked or where a user was alerted to potential spam or scam activity.
The Android ecosystem is a thriving global community built on trust, giving billions of users the confidence to download the latest apps. In order to maintain that trust, we’re focused on ensuring that apps do not cause real-world harm, such as malware, financial fraud, hidden subscriptions, and privacy invasions. As bad actors leverage AI to change their tactics and launch increasingly sophisticated attacks, we’ve deepened our investments in AI and real-time defenses over the last year to maintain the upper hand and stop these threats before they reach users.
We’ve seen a clear impact from these safety efforts on Google Play. In 2025, we prevented over 1.75 million policy-violating apps from being published on Google Play and banned more than 80,000 bad developer accounts that attempted to publish harmful apps. These figures demonstrate how our proactive protections and push for a more accountable ecosystem are discouraging bad actors from publishing malicious apps, while our new tools help honest developers build compliant apps more easily. Initiatives like developer verification, mandatory pre-review checks, and testing requirements have raised the bar for the Google Play ecosystem, significantly reducing the paths for bad actors to enter.
User safety is at the core of everything we build. Over the years, we’ve continually introduced ways to help users stay safe and make informed app choices — from parental controls to data safety transparency and app badges. We’re constantly improving our policies and protections to encourage safe, high-quality apps on Google Play and stop bad actors before they cause harm.
Apps on Google Play undergo rigorous reviews for safety and compliance with our policies. Last year, we shared that Google Play runs over 10,000 safety checks on every app we publish, and we continue to check and recheck apps after they’ve been published. In 2025, we continued scaling our defenses even further by:
We also continued to improve our protections for the broader Android ecosystem, by expanding Google Play Protect and real-time security measures like in-call scam protections to help keep users safe from scams, fraud, and other threats.
As Android’s built-in defense against malware and unwanted software, Google Play Protect now scans over 350 billion Android apps daily. This proactive protection constantly checks both Play apps and those from other sources to ensure they are not potentially harmful. And, last year, its real-time scanning capability identified more than 27 million new malicious apps from outside Google Play, warning users or blocking the app to neutralize the threat. To benefit from these protections, we recommend that users always keep Google Play Protect on.
While fraudsters are constantly evolving their tactics, Google Play Protect is evolving faster. Last year, we expanded:
Keeping Android and Google Play safe requires deep collaboration. We want to thank our global developer community for their partnership and for sharing their feedback on the tools and support they need to succeed.
In 2025, we focused on reducing friction for developers and providing them with tools to safeguard their businesses:
Our top priority remains making Google Play and Android the most trusted app ecosystems for everyone. This year, we’ll continue to invest in AI-driven defenses to stay ahead of emerging threats and equip Android developers with the tools they need to build apps safely. To empower developers who distribute their apps on Google Play, we’ll maintain our focus on embedding checks to help build apps that are compliant by design, while providing guidance to help proactively avoid policy violations before an app is published. We’ll also roll out Android developer verifications to hold bad actors accountable and prevent them from hiding behind anonymity to cause repeated harm.
Thank you for being part of the Google Play and Android community as we work together to build a safer app ecosystem.
Recently, we uncovered BeatBanker, an Android‑based malware campaign targeting Brazil. It spreads primarily through phishing attacks via a website disguised as the Google Play Store. To achieve their goals, the malicious APKs carry multiple components, including a cryptocurrency miner and a banking Trojan capable of completely hijacking the device and spoofing screens, among other things. In a more recent campaign, the attackers switched from the banker to a known RAT.
This blog post outlines each phase of the malware’s activity on the victim’s handset, explains how it ensures long‑term persistence, and describes its communication with mining pools.
The campaign begins with a counterfeit website, cupomgratisfood[.]shop, that looks exactly like the Google Play Store. This fake app store contains the “INSS Reembolso” app, which is in fact a Trojan. There are also other apps that are most likely Trojans too, but we haven’t obtained them.
The INSS Reembolso app poses as the official mobile portal of Brazil’s Instituto Nacional do Seguro Social (INSS), a government service that citizens can use to perform more than 90 social security tasks, from retirement applications and medical exam scheduling to viewing CNIS (National Registry of Social Information), tax, and payment statements, as well as tracking request statuses. By masquerading as this trusted platform, the fake page tricks users into downloading the malicious APK.
The initial APK file is packed and makes use of a native shared library (ELF) named libludwwiuh.so that is included in the application. Its main task is to decrypt another ELF file that will ultimately load the original DEX file.
First, libludwwiuh.so decrypts an embedded encrypted ELF file and drops it to a temporary location on the device under the name l.so. The same code that loaded the libludwwiuh.so library then loads this file, which uses the Java Native Interface (JNI) to continue execution.
The library does not have calls to its functions; instead, it directly calls the Java methods whose names are encrypted in the stack using XOR (stack strings technique) and restored at runtime:
Initially, the loader makes a request to collect some network information using https://ipapi.is to determine whether the infected device is a mobile device, if a VPN is being used, and to obtain the IP address and other details.
This loader is engineered to bypass mobile antivirus products by utilizing dalvik.system.InMemoryDexClassLoader. It loads malicious DEX code directly into memory, avoiding the creation of any files on the device’s file system. The necessary DEX files can be extracted using dynamic analysis tools like Frida.
Furthermore, the sample incorporates anti-analysis techniques, including runtime checks for emulated or analysis environments. When such an environment is detected (or when specific checks fail, such as verification of the supported CPU_ABI), the malware can immediately terminate its own process by invoking android.os.Process.killProcess(android.os.Process.myPid()), effectively self-destructing to hinder dynamic analysis.
After execution, the malware displays a user interface that mimics the Google Play Store page, showing an update available for the INSS Reembolso app. This is intended to trick victims into granting installation permissions by tapping the “Update” button, which allows the download of additional hidden malicious payloads.
The payload delivery process mimics the application update. The malware uses the REQUEST_INSTALL_PACKAGES permission to install APK files directly into its memory, bypassing Google Play. To ensure persistence, the malware keeps a notification about a system update pinned to the foreground and activates a foreground service with silent media playback, a tactic designed to prevent the operating system from terminating the malicious process.
When UPDATE is clicked on a fake Play Store screen, the malicious application downloads and executes an ELF file containing a cryptomining payload. It starts by issuing a GET request to the C2 server at either hxxps://accessor.fud2026.com/libmine-<arch>.so or hxxps://fud2026.com/libmine-<arch>.so. The downloaded file is then decrypted using CipherInputStream(), with the decryption key being derived from the SHA-1 hash of the downloaded file’s name, ensuring that each version of the file is encrypted with a unique key. The resulting file is renamed d-miner.
The decrypted payload is an ARM-compiled XMRig 6.17.0 binary. At runtime, it attempts to create a direct TCP connection to pool.fud2026[.]com:9000. If successful, it uses this endpoint; otherwise, it automatically switches to the proxy endpoint pool-proxy.fud2026[.]com:9000. The final command-line arguments passed to XMRig are as follows:
-o pool.fud2026[.]com:9000 or pool-proxy.fud2026[.]com:9000 (selected dynamically)-k (keepalive)--tls (encrypted connection)--no-color (disable colored output)--nicehash (NiceHash protocol support)
The malware uses Google’s legitimate Firebase Cloud Messaging (FCM) as its primary command‑and‑control (C2) channel. In the analyzed sample, each FCM message received triggers a check of the battery status, temperature, installation date, and user presence. A hidden cryptocurrency miner is then started or stopped as needed. These mechanisms ensure that infected devices remain permanently accessible and responsive to the attacker’s instructions, which are sent through the FCM infrastructure. The attacker monitors the following information:
The KeepAliveServiceMediaPlayback component ensures continuous operation by initiating uninterrupted playback via MediaPlayer. It keeps the service active in the foreground using a notification and loads a small, continuous audio file. This constant activity prevents the system from suspending or terminating the process due to inactivity.
The identified audio output8.mp3 is five seconds long and plays on a loop. It contains some Chinese words.
BeatBanker compromises the machine with a cryptocurrency miner and introduces another malicious APK that acts as a banking Trojan. This Trojan uses previously obtained permission to install an additional APK called INSS Reebolso, which is associated with the package com.destination.cosmetics.
Similar to the initial malicious APK, it establishes persistence by creating and displaying a fixed notification in the foreground to hinder removal. Furthermore, BeatBanker attempts to trick the user into granting accessibility permissions to the package.
Leveraging the acquired accessibility permissions, the malware establishes comprehensive control over the device’s user interface.
The Trojan constantly monitors the foreground application. It targets the official Binance application (com.binance.dev) and the Trust Wallet application (com.wallet.crypto.trustapp), focusing on USDT transactions. When a user tries to withdraw USDT, the Trojan instantly overlays the target app’s transaction confirmation screen with a highly realistic page sourced from Base64-encoded HTML stored in the banking module.
The module captures the original withdrawal address and amount, then surreptitiously substitutes the destination address with an attacker-controlled one using AccessibilityNodeInfo.ACTION_SET_TEXT. The overlay page shows the victim the address they copied (for Binance) or just shows a loading icon (for Trust Wallet), leading them to believe they are remitting funds to the intended wallet when, in fact, the cryptocurrency is transferred to the attacker’s designated address.
Fake overlay pages: Binance (left) and Trust Wallet (right)
BeatBanker’s banking module monitors the following browsers installed on the victim’s device:
Its aim is to collect the URLs accessed by the victim using the regular expression ^(?:https?://)?(?:[^:/\\\\]+\\\\.)?([^:/\\\\]+\\\\.[^:/\\\\]+). It also offers management functionalities (add, edit, delete, list) for links saved in the device’s default browser, as well as the ability to open links provided by the attacker.
BeatBanker is also designed to receive commands from the C2. These commands aim to collect the victim’s personal information and gain complete control of the device.
| Command | Description |
| 0 | Starts dynamic loading of the DEX class |
| Update | Simulates software update and locks the screen |
| msg: | Displays a Toast message with the provided text |
| goauth<*> | Opens Google Authenticator (if installed) and enables the AccessService.SendGoogleAuth flag used to monitor and retrieve authentication codes |
| kill<*> | Sets the protection bypass flag AccessService.bypass to “True”and sets the initializeService.uninstall flag to “Off” |
| srec<*> | Starts or stops audio recording (microphone), storing the recorded data in a file with an automatically generated filename. The following path format is used to store the recording: /Config/sys/apps/rc/<timestamp>_0REC<last5digits>.wav |
| pst<*> | Pastes text from the clipboard (via Accessibility Services) |
| GRC<*> | Lists all existing audio recording files |
| gtrc<*> | Sends a specific audio recording file to the C2 |
| lcm<*> | Lists supported front camera resolutions |
| usdtress<*> | Sets a USDT cryptocurrency address when a transaction is detected |
| lnk<*> | Opens a link in the browser |
| EHP<*> | Updates login credentials (host, port, name) and restarts the application |
| ssms<*> | Sends an SMS message (individually or to all contacts) |
| CRD<*> | Adds (E>) or removes (D>) packages from the list of blocked/disabled applications |
| SFD<*> | Deletes files (logs, recordings, tones) or uninstalls itself |
| adm<>lck<> | Immediately locks the screen using Device Administrator permissions |
| adm<>wip<> | Performs a complete device data wipe (factory reset) |
| Aclk<*> | Executes a sequence of automatic taps (auto-clicker) or lists existing macros |
| KBO<*>lod | Checks the status of the keylogger and virtual keyboard |
| KBO<*>AKP/AKA | Requests permission to activate a custom virtual keyboard or activates one |
| KBO<*>ENB: | Enables (1) or disables (0) the keylogger |
| RPM<*>lod | Checks the status of all critical permissions |
| RPM<*>ACC | Requests Accessibility Services permission |
| RPM<*>DOZ | Requests Doze/App Standby permission (battery optimization) |
| RPM<*>DRW | Requests Draw Over Other Apps permission (overlay) |
| RPM<*>INST | Requests permission to install apps from unknown sources (Android 8+) |
| ussd<*> | Executes a USSD code (e.g., *#06# for IMEI) |
| Blkt<*> | Sets the text for the lock overlay |
| BLKV<*> | Enables or disables full-screen lock using WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY to display a black FrameLayout element over the entire screen |
| SCRD<> / SCRD2<> | Enables/disables real-time screen text submission to the C2 (screen reading) |
| rdall<*> | Clears or sends all keylogger logs |
| rdd<*> | Deletes a specific log file |
| rd<*> | Sends the content of a specific keylogger file |
| MO<*> | Manages application monitoring (add, remove, list, screenshot, etc.) |
| FW<*> | Controls VPN and firewall (status, block/allow apps, enable/disable) |
| noti<*> | Creates persistent and custom notifications |
| sp<*> | Executes a sequence of swipes/taps (gesture macro) |
| lodp<*> | Manages saved links in the internal browser (add, edit, delete, list) |
| scc: | Starts screen capture/streaming |
Our recent detection efforts uncovered a campaign leveraging a fraudulent StarLink application that we assess as being a new BeatBanker variant. The infection chain mirrored previous instances, employing identical persistence methods – specifically, looped audio and fixed notifications. Furthermore, this variant included a crypto miner similar to those seen previously. However, rather than deploying the banking module, it was observed distributing the BTMOB remote administration tool.
The BTMOB APK is highly obfuscated and contains a class responsible for configuration. Despite this, it’s possible to identify a parser used to define the application’s behavior on the device, as well as persistence features, such as protection against restart, deletion, lock reset, and the ability to perform real-time screen recording.
The simple decryption routine uses repetitive XOR between the encrypted data and a short key. It iterates through the encrypted text byte by byte, repeating the key from the beginning whenever it reaches the end. At each position, the sample XORs the encrypted byte with the corresponding byte of the key, overwriting the original. Ultimately, the modified byte array contains the original text, which is then converted to UTF-8 and returned as a string.
BTMOB is an Android remote administration tool that evolved from the CraxsRAT, CypherRAT, and SpySolr families. It provides full remote control of the victim’s device and is sold in a Malware-as-a-Service (MaaS) model. On July 26, 2025, a threat actor posted a screenshot of the BTMOB RAT in action on GitHub under the username “brmobrats”, along with a link to the website btmob[.]xyz. The website contains information about the BTMOB RAT, including its version history, features, and other relevant details. It also redirects to a Telegram contact. Cyfirma has already linked this account to CraxsRAT and CypherRAT.
Recently, a YouTube channel was created by a different threat actor that features videos demonstrating how to use the malware and facilitate its sale via Telegram.
We also saw the distribution and sale of leaked BTMOB source code on some dark web forums. This may suggest that the creator of BeatBanker acquired BTMOB from its original author or the source of the leak and is utilizing it as the final payload, replacing the banking module observed in the INSS Reebolso incident.
In terms of functionality, BTMOB maintains a set of intrusive capabilities, including: automatic granting of permissions, especially on Android 13–15 devices; use of a black FrameLayout overlay to hide system notifications similar to the one observed in the banking module; silent installation; persistent background execution; and mechanisms designed to capture screen lock credentials, including PINs, patterns, and passwords. The malware also provides access to front and rear cameras, captures keystrokes in real time, monitors GPS location, and constantly collects sensitive data. Together, these functionalities provide the operator with comprehensive remote control, persistent access, and extensive surveillance capabilities over compromised devices.
All variants of BeatBanker – those with the banking module and those with the BTMOB RAT – were detected on victims in Brazil. Some of the samples that deliver BTMOB appear to use WhatsApp to spread, as well as phishing pages.
BeatBanker is an excellent example of how mobile threats are becoming more sophisticated and multi-layered. Initially focused in Brazil, this Trojan operates a dual campaign, acting as a Monero cryptocurrency miner, discreetly draining your device’s battery life while also stealing banking credentials and tampering with cryptocurrency transactions. Moreover, the most recent version goes even further, substituting the banking module with a full-fledged BTMOB RAT.
The attackers have devised inventive tricks to maintain persistence. They keep the process alive by looping an almost inaudible audio track, which prevents the operating system from terminating it and allows BeatBanker to remain active for extended periods.
Furthermore, the threat demonstrates an obsession with staying hidden. It monitors device usage, battery level and temperature. It even uses Google’s legitimate system (FCM) to receive commands. The threat’s banking module is capable of overlaying Binance and Trust Wallet screens and diverting USDT funds to the criminals’ wallets before the victim even notices.
The lesson here is clear: distrust is your best defense. BeatBanker spreads through fake websites that mimic Google Play, disguising itself as trustworthy government applications. To protect yourself against threats like this, it is essential to:
Our solutions detect this threat as HEUR:Trojan-Dropper.AndroidOS.BeatBanker and HEUR:Trojan-Dropper.AndroidOS.Banker.*
Additional IoCs, TTPs and detection rules are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.
Host-based (MD5 hashes)
F6C979198809E13859196B135D21E79B – INSS Reebolso
D3005BF1D52B40B0B72B3C3B1773336B – StarLink
Domains
cupomgratisfood[.]shop
fud2026[.]com
accessor.fud2026[.]com
pool.fud2026[.]com
pool-proxy.fud2026[.]com
aptabase.fud2026[.]com
aptabase.khwdji319[.]xyz
btmob[.]xyz
bt-mob[.]net
Recently, we uncovered BeatBanker, an Android‑based malware campaign targeting Brazil. It spreads primarily through phishing attacks via a website disguised as the Google Play Store. To achieve their goals, the malicious APKs carry multiple components, including a cryptocurrency miner and a banking Trojan capable of completely hijacking the device and spoofing screens, among other things. In a more recent campaign, the attackers switched from the banker to a known RAT.
This blog post outlines each phase of the malware’s activity on the victim’s handset, explains how it ensures long‑term persistence, and describes its communication with mining pools.
The campaign begins with a counterfeit website, cupomgratisfood[.]shop, that looks exactly like the Google Play Store. This fake app store contains the “INSS Reembolso” app, which is in fact a Trojan. There are also other apps that are most likely Trojans too, but we haven’t obtained them.
The INSS Reembolso app poses as the official mobile portal of Brazil’s Instituto Nacional do Seguro Social (INSS), a government service that citizens can use to perform more than 90 social security tasks, from retirement applications and medical exam scheduling to viewing CNIS (National Registry of Social Information), tax, and payment statements, as well as tracking request statuses. By masquerading as this trusted platform, the fake page tricks users into downloading the malicious APK.
The initial APK file is packed and makes use of a native shared library (ELF) named libludwwiuh.so that is included in the application. Its main task is to decrypt another ELF file that will ultimately load the original DEX file.
First, libludwwiuh.so decrypts an embedded encrypted ELF file and drops it to a temporary location on the device under the name l.so. The same code that loaded the libludwwiuh.so library then loads this file, which uses the Java Native Interface (JNI) to continue execution.
The library does not have calls to its functions; instead, it directly calls the Java methods whose names are encrypted in the stack using XOR (stack strings technique) and restored at runtime:
Initially, the loader makes a request to collect some network information using https://ipapi.is to determine whether the infected device is a mobile device, if a VPN is being used, and to obtain the IP address and other details.
This loader is engineered to bypass mobile antivirus products by utilizing dalvik.system.InMemoryDexClassLoader. It loads malicious DEX code directly into memory, avoiding the creation of any files on the device’s file system. The necessary DEX files can be extracted using dynamic analysis tools like Frida.
Furthermore, the sample incorporates anti-analysis techniques, including runtime checks for emulated or analysis environments. When such an environment is detected (or when specific checks fail, such as verification of the supported CPU_ABI), the malware can immediately terminate its own process by invoking android.os.Process.killProcess(android.os.Process.myPid()), effectively self-destructing to hinder dynamic analysis.
After execution, the malware displays a user interface that mimics the Google Play Store page, showing an update available for the INSS Reembolso app. This is intended to trick victims into granting installation permissions by tapping the “Update” button, which allows the download of additional hidden malicious payloads.
The payload delivery process mimics the application update. The malware uses the REQUEST_INSTALL_PACKAGES permission to install APK files directly into its memory, bypassing Google Play. To ensure persistence, the malware keeps a notification about a system update pinned to the foreground and activates a foreground service with silent media playback, a tactic designed to prevent the operating system from terminating the malicious process.
When UPDATE is clicked on a fake Play Store screen, the malicious application downloads and executes an ELF file containing a cryptomining payload. It starts by issuing a GET request to the C2 server at either hxxps://accessor.fud2026.com/libmine-<arch>.so or hxxps://fud2026.com/libmine-<arch>.so. The downloaded file is then decrypted using CipherInputStream(), with the decryption key being derived from the SHA-1 hash of the downloaded file’s name, ensuring that each version of the file is encrypted with a unique key. The resulting file is renamed d-miner.
The decrypted payload is an ARM-compiled XMRig 6.17.0 binary. At runtime, it attempts to create a direct TCP connection to pool.fud2026[.]com:9000. If successful, it uses this endpoint; otherwise, it automatically switches to the proxy endpoint pool-proxy.fud2026[.]com:9000. The final command-line arguments passed to XMRig are as follows:
-o pool.fud2026[.]com:9000 or pool-proxy.fud2026[.]com:9000 (selected dynamically)-k (keepalive)--tls (encrypted connection)--no-color (disable colored output)--nicehash (NiceHash protocol support)The malware uses Google’s legitimate Firebase Cloud Messaging (FCM) as its primary command‑and‑control (C2) channel. In the analyzed sample, each FCM message received triggers a check of the battery status, temperature, installation date, and user presence. A hidden cryptocurrency miner is then started or stopped as needed. These mechanisms ensure that infected devices remain permanently accessible and responsive to the attacker’s instructions, which are sent through the FCM infrastructure. The attacker monitors the following information:
The KeepAliveServiceMediaPlayback component ensures continuous operation by initiating uninterrupted playback via MediaPlayer. It keeps the service active in the foreground using a notification and loads a small, continuous audio file. This constant activity prevents the system from suspending or terminating the process due to inactivity.
The identified audio output8.mp3 is five seconds long and plays on a loop. It contains some Chinese words.
BeatBanker compromises the machine with a cryptocurrency miner and introduces another malicious APK that acts as a banking Trojan. This Trojan uses previously obtained permission to install an additional APK called INSS Reebolso, which is associated with the package com.destination.cosmetics.
Similar to the initial malicious APK, it establishes persistence by creating and displaying a fixed notification in the foreground to hinder removal. Furthermore, BeatBanker attempts to trick the user into granting accessibility permissions to the package.
Leveraging the acquired accessibility permissions, the malware establishes comprehensive control over the device’s user interface.
The Trojan constantly monitors the foreground application. It targets the official Binance application (com.binance.dev) and the Trust Wallet application (com.wallet.crypto.trustapp), focusing on USDT transactions. When a user tries to withdraw USDT, the Trojan instantly overlays the target app’s transaction confirmation screen with a highly realistic page sourced from Base64-encoded HTML stored in the banking module.
The module captures the original withdrawal address and amount, then surreptitiously substitutes the destination address with an attacker-controlled one using AccessibilityNodeInfo.ACTION_SET_TEXT. The overlay page shows the victim the address they copied (for Binance) or just shows a loading icon (for Trust Wallet), leading them to believe they are remitting funds to the intended wallet when, in fact, the cryptocurrency is transferred to the attacker’s designated address.
Fake overlay pages: Binance (left) and Trust Wallet (right)
BeatBanker’s banking module monitors the following browsers installed on the victim’s device:
Its aim is to collect the URLs accessed by the victim using the regular expression ^(?:https?://)?(?:[^:/\\\\]+\\\\.)?([^:/\\\\]+\\\\.[^:/\\\\]+). It also offers management functionalities (add, edit, delete, list) for links saved in the device’s default browser, as well as the ability to open links provided by the attacker.
BeatBanker is also designed to receive commands from the C2. These commands aim to collect the victim’s personal information and gain complete control of the device.
| Command | Description |
| 0 | Starts dynamic loading of the DEX class |
| Update | Simulates software update and locks the screen |
| msg: | Displays a Toast message with the provided text |
| goauth<*> | Opens Google Authenticator (if installed) and enables the AccessService.SendGoogleAuth flag used to monitor and retrieve authentication codes |
| kill<*> | Sets the protection bypass flag AccessService.bypass to “True”and sets the initializeService.uninstall flag to “Off” |
| srec<*> | Starts or stops audio recording (microphone), storing the recorded data in a file with an automatically generated filename. The following path format is used to store the recording: /Config/sys/apps/rc/<timestamp>_0REC<last5digits>.wav |
| pst<*> | Pastes text from the clipboard (via Accessibility Services) |
| GRC<*> | Lists all existing audio recording files |
| gtrc<*> | Sends a specific audio recording file to the C2 |
| lcm<*> | Lists supported front camera resolutions |
| usdtress<*> | Sets a USDT cryptocurrency address when a transaction is detected |
| lnk<*> | Opens a link in the browser |
| EHP<*> | Updates login credentials (host, port, name) and restarts the application |
| ssms<*> | Sends an SMS message (individually or to all contacts) |
| CRD<*> | Adds (E>) or removes (D>) packages from the list of blocked/disabled applications |
| SFD<*> | Deletes files (logs, recordings, tones) or uninstalls itself |
| adm<>lck<> | Immediately locks the screen using Device Administrator permissions |
| adm<>wip<> | Performs a complete device data wipe (factory reset) |
| Aclk<*> | Executes a sequence of automatic taps (auto-clicker) or lists existing macros |
| KBO<*>lod | Checks the status of the keylogger and virtual keyboard |
| KBO<*>AKP/AKA | Requests permission to activate a custom virtual keyboard or activates one |
| KBO<*>ENB: | Enables (1) or disables (0) the keylogger |
| RPM<*>lod | Checks the status of all critical permissions |
| RPM<*>ACC | Requests Accessibility Services permission |
| RPM<*>DOZ | Requests Doze/App Standby permission (battery optimization) |
| RPM<*>DRW | Requests Draw Over Other Apps permission (overlay) |
| RPM<*>INST | Requests permission to install apps from unknown sources (Android 8+) |
| ussd<*> | Executes a USSD code (e.g., *#06# for IMEI) |
| Blkt<*> | Sets the text for the lock overlay |
| BLKV<*> | Enables or disables full-screen lock using WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY to display a black FrameLayout element over the entire screen |
| SCRD<> / SCRD2<> | Enables/disables real-time screen text submission to the C2 (screen reading) |
| rdall<*> | Clears or sends all keylogger logs |
| rdd<*> | Deletes a specific log file |
| rd<*> | Sends the content of a specific keylogger file |
| MO<*> | Manages application monitoring (add, remove, list, screenshot, etc.) |
| FW<*> | Controls VPN and firewall (status, block/allow apps, enable/disable) |
| noti<*> | Creates persistent and custom notifications |
| sp<*> | Executes a sequence of swipes/taps (gesture macro) |
| lodp<*> | Manages saved links in the internal browser (add, edit, delete, list) |
| scc: | Starts screen capture/streaming |
Our recent detection efforts uncovered a campaign leveraging a fraudulent StarLink application that we assess as being a new BeatBanker variant. The infection chain mirrored previous instances, employing identical persistence methods – specifically, looped audio and fixed notifications. Furthermore, this variant included a crypto miner similar to those seen previously. However, rather than deploying the banking module, it was observed distributing the BTMOB remote administration tool.
The BTMOB APK is highly obfuscated and contains a class responsible for configuration. Despite this, it’s possible to identify a parser used to define the application’s behavior on the device, as well as persistence features, such as protection against restart, deletion, lock reset, and the ability to perform real-time screen recording.
The simple decryption routine uses repetitive XOR between the encrypted data and a short key. It iterates through the encrypted text byte by byte, repeating the key from the beginning whenever it reaches the end. At each position, the sample XORs the encrypted byte with the corresponding byte of the key, overwriting the original. Ultimately, the modified byte array contains the original text, which is then converted to UTF-8 and returned as a string.
BTMOB is an Android remote administration tool that evolved from the CraxsRAT, CypherRAT, and SpySolr families. It provides full remote control of the victim’s device and is sold in a Malware-as-a-Service (MaaS) model. On July 26, 2025, a threat actor posted a screenshot of the BTMOB RAT in action on GitHub under the username “brmobrats”, along with a link to the website btmob[.]xyz. The website contains information about the BTMOB RAT, including its version history, features, and other relevant details. It also redirects to a Telegram contact. Cyfirma has already linked this account to CraxsRAT and CypherRAT.
Recently, a YouTube channel was created by a different threat actor that features videos demonstrating how to use the malware and facilitate its sale via Telegram.
We also saw the distribution and sale of leaked BTMOB source code on some dark web forums. This may suggest that the creator of BeatBanker acquired BTMOB from its original author or the source of the leak and is utilizing it as the final payload, replacing the banking module observed in the INSS Reebolso incident.
In terms of functionality, BTMOB maintains a set of intrusive capabilities, including: automatic granting of permissions, especially on Android 13–15 devices; use of a black FrameLayout overlay to hide system notifications similar to the one observed in the banking module; silent installation; persistent background execution; and mechanisms designed to capture screen lock credentials, including PINs, patterns, and passwords. The malware also provides access to front and rear cameras, captures keystrokes in real time, monitors GPS location, and constantly collects sensitive data. Together, these functionalities provide the operator with comprehensive remote control, persistent access, and extensive surveillance capabilities over compromised devices.
All variants of BeatBanker – those with the banking module and those with the BTMOB RAT – were detected on victims in Brazil. Some of the samples that deliver BTMOB appear to use WhatsApp to spread, as well as phishing pages.
BeatBanker is an excellent example of how mobile threats are becoming more sophisticated and multi-layered. Initially focused in Brazil, this Trojan operates a dual campaign, acting as a Monero cryptocurrency miner, discreetly draining your device’s battery life while also stealing banking credentials and tampering with cryptocurrency transactions. Moreover, the most recent version goes even further, substituting the banking module with a full-fledged BTMOB RAT.
The attackers have devised inventive tricks to maintain persistence. They keep the process alive by looping an almost inaudible audio track, which prevents the operating system from terminating it and allows BeatBanker to remain active for extended periods.
Furthermore, the threat demonstrates an obsession with staying hidden. It monitors device usage, battery level and temperature. It even uses Google’s legitimate system (FCM) to receive commands. The threat’s banking module is capable of overlaying Binance and Trust Wallet screens and diverting USDT funds to the criminals’ wallets before the victim even notices.
The lesson here is clear: distrust is your best defense. BeatBanker spreads through fake websites that mimic Google Play, disguising itself as trustworthy government applications. To protect yourself against threats like this, it is essential to:
Our solutions detect this threat as HEUR:Trojan-Dropper.AndroidOS.BeatBanker and HEUR:Trojan-Dropper.AndroidOS.Banker.*
Additional IoCs, TTPs and detection rules are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.
Host-based (MD5 hashes)
F6C979198809E13859196B135D21E79B – INSS Reebolso
D3005BF1D52B40B0B72B3C3B1773336B – StarLink
Domains
cupomgratisfood[.]shop
fud2026[.]com
accessor.fud2026[.]com
pool.fud2026[.]com
pool-proxy.fud2026[.]com
aptabase.fud2026[.]com
aptabase.khwdji319[.]xyz
btmob[.]xyz
bt-mob[.]net
Starting from the third quarter of 2025, we have updated our statistical methodology based on the Kaspersky Security Network. These changes affect all sections of the report except for the installation package statistics, which remain unchanged.
To illustrate trends between reporting periods, we have recalculated the previous year’s data; consequently, these figures may differ significantly from previously published numbers. All subsequent reports will be generated using this new methodology, ensuring accurate data comparisons with the findings presented in this article.
Kaspersky Security Network (KSN) is a global network for analyzing anonymized threat intelligence, voluntarily shared by Kaspersky users. The statistics in this report are based on KSN data unless explicitly stated otherwise.
According to Kaspersky Security Network, in 2025:
In 2025, cybercriminals launched an average of approximately 1.17 million attacks per month against mobile devices using malicious, advertising, or unwanted software. In total, Kaspersky solutions blocked 14,059,465 attacks throughout the year.
Attacks on Kaspersky mobile users in 2025 (download)
Beyond the malware mentioned in previous quarterly reports, 2025 saw the discovery of several other notable Trojans. Among these, in Q4 we uncovered the Keenadu preinstalled backdoor. This malware is integrated into device firmware during the manufacturing stage. The malicious code is injected into libandroid_runtime.so – a core library for the Android Java runtime environment – allowing a copy of the backdoor to enter the address space of every app running on the device. Depending on the specific app, the malware can then perform actions such as inflating ad views, displaying banners on behalf of other apps, or hijacking search queries. The functionality of Keenadu is virtually unlimited, as its malicious modules are downloaded dynamically and can be updated remotely.
Cybersecurity researchers also identified the Kimwolf IoT botnet, which specifically targets Android TV boxes. Infected devices are capable of launching DDoS attacks, operating as reverse proxies, and executing malicious commands via a reverse shell. Subsequent analysis revealed that Kimwolf’s reverse proxy functionality was being leveraged by proxy providers to use compromised home devices as residential proxies.
Another notable discovery in 2025 was the LunaSpy Trojan.
LunaSpy Trojan, distributed under the guise of an antivirus app
Disguised as antivirus software, this spyware exfiltrates browser passwords, messaging app credentials, SMS messages, and call logs. Furthermore, it is capable of recording audio via the device’s microphone and capturing video through the camera. This threat primarily targeted users in Russia.
815,735 new unique installation packages were observed in 2025, showing a decrease compared to the previous year. While the decline in 2024 was less pronounced, this past year saw the figure drop by nearly one-third.
Detected Android-specific malware and unwanted software installation packages in 2022–2025 (download)
The overall decrease in detected packages is primarily due to a reduction in apps categorized as not-a-virus. Conversely, the number of Trojans has increased significantly, a trend clearly reflected in the distribution data below.
Distribution* of detected mobile software by type, 2024–2025 (download)
* The data for the previous year may differ from previously published data due to some verdicts being retrospectively revised.
A significant increase in Trojan-Banker and Trojan-Spy apps was accompanied by a decline in AdWare and RiskTool files. The most prevalent banking Trojans were Mamont (accounting for 49.8% of apps) and Creduz (22.5%). Leading the persistent adware category were MobiDash (39%), Adlo (27%), and HiddenAd (20%).
Share* of users attacked by each type of malware or unwanted software out of all users of Kaspersky mobile solutions attacked in 2024–2025 (download)
* The total may exceed 100% if the same users encountered multiple attack types.
Trojan-Banker malware saw a significant surge in 2025, not only in terms of unique file counts but also in the total number of attacks. Nevertheless, this category ranked fourth overall, trailing far behind the Trojan file category, which was dominated by various modifications of Triada and Fakemoney.
Note that the malware rankings below exclude riskware and potentially unwanted apps, such as RiskTool and adware.
| Verdict | % 2024* | % 2025* | Difference in p.p. | Change in ranking |
| Trojan.AndroidOS.Triada.fe | 0.04 | 9.84 | +9.80 | |
| Trojan.AndroidOS.Triada.gn | 2.94 | 8.14 | +5.21 | +6 |
| Trojan.AndroidOS.Fakemoney.v | 7.46 | 7.97 | +0.51 | +1 |
| DangerousObject.Multi.Generic | 7.73 | 5.83 | –1.91 | –2 |
| Trojan.AndroidOS.Triada.ii | 0.00 | 5.25 | +5.25 | |
| Trojan-Banker.AndroidOS.Mamont.da | 0.10 | 4.12 | +4.02 | |
| Trojan.AndroidOS.Triada.ga | 10.56 | 3.75 | –6.81 | –6 |
| Trojan-Banker.AndroidOS.Mamont.db | 0.01 | 3.53 | +3.51 | |
| Backdoor.AndroidOS.Triada.z | 0.00 | 2.79 | +2.79 | |
| Trojan-Banker.AndroidOS.Coper.c | 0.81 | 2.54 | +1.72 | +35 |
| Trojan-Clicker.AndroidOS.Agent.bh | 0.34 | 2.48 | +2.14 | +74 |
| Trojan-Dropper.Linux.Agent.gen | 1.82 | 2.37 | +0.55 | +4 |
| Trojan.AndroidOS.Boogr.gsh | 5.41 | 2.06 | –3.35 | –8 |
| DangerousObject.AndroidOS.GenericML | 2.42 | 1.97 | –0.45 | –3 |
| Trojan.AndroidOS.Triada.gs | 3.69 | 1.93 | –1.76 | –9 |
| Trojan-Downloader.AndroidOS.Agent.no | 0.00 | 1.87 | +1.87 | |
| Trojan.AndroidOS.Triada.hf | 0.00 | 1.75 | +1.75 | |
| Trojan-Banker.AndroidOS.Mamont.bc | 1.13 | 1.65 | +0.51 | +8 |
| Trojan.AndroidOS.Generic. | 2.13 | 1.47 | –0.66 | –6 |
| Trojan.AndroidOS.Triada.hy | 0.00 | 1.44 | +1.44 |
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.
The list is largely dominated by the Triada family, which is distributed via malicious modifications of popular messaging apps. Another infection vector involves tricking victims into installing an official messaging app within a “customized virtual environment” that supposedly offers enhanced configuration options. Fakemoney scam applications, which promise fraudulent investment opportunities or fake payouts, continue to target users frequently, ranking third in our statistics. Meanwhile, the Mamont banking Trojan variants occupy the 6th, 8th, and 18th positions by number of attacks. The Triada backdoor preinstalled in the firmware of certain devices reached the 9th spot.
This section describes malware families whose attack campaigns are concentrated within specific countries.
| Verdict | Country* | %** |
| Trojan-Banker.AndroidOS.Coper.a | Türkiye | 95.74 |
| Trojan-Dropper.AndroidOS.Hqwar.bj | Türkiye | 94.96 |
| Trojan.AndroidOS.Thamera.bb | India | 94.71 |
| Trojan-Proxy.AndroidOS.Agent.q | Germany | 93.70 |
| Trojan-Banker.AndroidOS.Coper.c | Türkiye | 93.42 |
| Trojan-Banker.AndroidOS.Rewardsteal.lv | India | 92.44 |
| Trojan-Banker.AndroidOS.Rewardsteal.jp | India | 92.31 |
| Trojan-Banker.AndroidOS.Rewardsteal.ib | India | 91.91 |
| Trojan-Dropper.AndroidOS.Rewardsteal.h | India | 91.45 |
| Trojan-Banker.AndroidOS.Rewardsteal.nk | India | 90.98 |
| Trojan-Dropper.AndroidOS.Agent.sm | Türkiye | 90.34 |
| Trojan-Dropper.AndroidOS.Rewardsteal.ac | India | 89.38 |
| Trojan-Banker.AndroidOS.Rewardsteal.oa | India | 89.18 |
| Trojan-Banker.AndroidOS.Rewardsteal.ma | India | 88.58 |
| Trojan-Spy.AndroidOS.SmForw.ko | India | 88.48 |
| Trojan-Dropper.AndroidOS.Pylcasa.c | Brazil | 88.25 |
| Trojan-Dropper.AndroidOS.Hqwar.bf | Türkiye | 88.15 |
| Trojan-Banker.AndroidOS.Agent.pp | India | 87.85 |
* Country where the malware was most active.
** Unique users who encountered the malware in the indicated country as a percentage of all users of Kaspersky mobile solutions who were attacked by the same malware.
Türkiye saw the highest concentration of attacks from Coper banking Trojans and their associated Hqwar droppers. In India, Rewardsteal Trojans continued to proliferate, exfiltrating victims’ payment data under the guise of monetary giveaways. Additionally, India saw a resurgence of the Thamera Trojan, which we previously observed frequently attacking users in 2023. This malware hijacks the victim’s device to illicitly register social media accounts.
The Trojan-Proxy.AndroidOS.Agent.q campaign, concentrated in Germany, utilized a compromised third-party application designed for tracking discounts at a major German retail chain. Attackers monetized these infections through unauthorized use of the victims’ devices as residential proxies.
In Brazil, 2025 saw a concentration of Pylcasa Trojan attacks. This malware is primarily used to redirect users to phishing pages or illicit online casino sites.
The number of new banking Trojan installation packages surged to 255,090, representing a several-fold increase over previous years.
Mobile banking Trojan installation packages detected by Kaspersky in 2022–2025 (download)
Notably, the total number of attacks involving bankers grew by 1.5 times, maintaining the same growth rate seen in the previous year. Given the sharp spike in the number of unique malicious packages, we can conclude that these attacks yield significant profit for cybercriminals. This is further evidenced by the fact that threat actors continue to diversify their delivery channels and accelerate the production of new variants in an effort to evade detection by security solutions.
| Verdict | % 2024* | % 2025* | Difference in p.p. | Change in ranking |
| Trojan-Banker.AndroidOS.Mamont.da | 0.86 | 15.65 | +14.79 | +28 |
| Trojan-Banker.AndroidOS.Mamont.db | 0.12 | 13.41 | +13.29 | |
| Trojan-Banker.AndroidOS.Coper.c | 7.19 | 9.65 | +2.46 | +2 |
| Trojan-Banker.AndroidOS.Mamont.bc | 10.03 | 6.26 | –3.77 | –3 |
| Trojan-Banker.AndroidOS.Mamont.ev | 0.00 | 4.10 | +4.10 | |
| Trojan-Banker.AndroidOS.Coper.a | 9.04 | 4.00 | –5.04 | –4 |
| Trojan-Banker.AndroidOS.Mamont.ek | 0.00 | 3.73 | +3.73 | |
| Trojan-Banker.AndroidOS.Mamont.cb | 0.64 | 3.04 | +2.40 | +26 |
| Trojan-Banker.AndroidOS.Faketoken.pac | 2.17 | 2.95 | +0.77 | +5 |
| Trojan-Banker.AndroidOS.Mamont.hi | 0.00 | 2.75 | +2.75 |
* Unique users who encountered this malware as a percentage of all users of Kaspersky mobile solutions who encountered banking threats.
In 2025, we observed a massive surge in activity from Mamont banking Trojans. They accounted for approximately half of all new apps in their category and also were utilized in half of all banking Trojan attacks.
The year 2025 saw a continuing trend toward a decline in total unique unwanted software installation packages. However, we noted a significant year-over-year increase in specific threats – most notably mobile banking Trojans and spyware – even though adware remained the most frequently detected threat overall.
Among the mobile threats detected, we have seen an increased prevalence of preinstalled backdoors, such as Triada and Keenadu. Consistent with last year’s findings, certain mobile malware families continue to proliferate via official app stores. Finally, we have observed a growing interest among threat actors in leveraging compromised devices as proxies.
Starting from the third quarter of 2025, we have updated our statistical methodology based on the Kaspersky Security Network. These changes affect all sections of the report except for the installation package statistics, which remain unchanged.
To illustrate trends between reporting periods, we have recalculated the previous year’s data; consequently, these figures may differ significantly from previously published numbers. All subsequent reports will be generated using this new methodology, ensuring accurate data comparisons with the findings presented in this article.
Kaspersky Security Network (KSN) is a global network for analyzing anonymized threat intelligence, voluntarily shared by Kaspersky users. The statistics in this report are based on KSN data unless explicitly stated otherwise.
According to Kaspersky Security Network, in 2025:
In 2025, cybercriminals launched an average of approximately 1.17 million attacks per month against mobile devices using malicious, advertising, or unwanted software. In total, Kaspersky solutions blocked 14,059,465 attacks throughout the year.
Attacks on Kaspersky mobile users in 2025 (download)
Beyond the malware mentioned in previous quarterly reports, 2025 saw the discovery of several other notable Trojans. Among these, in Q4 we uncovered the Keenadu preinstalled backdoor. This malware is integrated into device firmware during the manufacturing stage. The malicious code is injected into libandroid_runtime.so – a core library for the Android Java runtime environment – allowing a copy of the backdoor to enter the address space of every app running on the device. Depending on the specific app, the malware can then perform actions such as inflating ad views, displaying banners on behalf of other apps, or hijacking search queries. The functionality of Keenadu is virtually unlimited, as its malicious modules are downloaded dynamically and can be updated remotely.
Cybersecurity researchers also identified the Kimwolf IoT botnet, which specifically targets Android TV boxes. Infected devices are capable of launching DDoS attacks, operating as reverse proxies, and executing malicious commands via a reverse shell. Subsequent analysis revealed that Kimwolf’s reverse proxy functionality was being leveraged by proxy providers to use compromised home devices as residential proxies.
Another notable discovery in 2025 was the LunaSpy Trojan.
LunaSpy Trojan, distributed under the guise of an antivirus app
Disguised as antivirus software, this spyware exfiltrates browser passwords, messaging app credentials, SMS messages, and call logs. Furthermore, it is capable of recording audio via the device’s microphone and capturing video through the camera. This threat primarily targeted users in Russia.
815,735 new unique installation packages were observed in 2025, showing a decrease compared to the previous year. While the decline in 2024 was less pronounced, this past year saw the figure drop by nearly one-third.
Detected Android-specific malware and unwanted software installation packages in 2022–2025 (download)
The overall decrease in detected packages is primarily due to a reduction in apps categorized as not-a-virus. Conversely, the number of Trojans has increased significantly, a trend clearly reflected in the distribution data below.
Distribution* of detected mobile software by type, 2024–2025 (download)
* The data for the previous year may differ from previously published data due to some verdicts being retrospectively revised.
A significant increase in Trojan-Banker and Trojan-Spy apps was accompanied by a decline in AdWare and RiskTool files. The most prevalent banking Trojans were Mamont (accounting for 49.8% of apps) and Creduz (22.5%). Leading the persistent adware category were MobiDash (39%), Adlo (27%), and HiddenAd (20%).
Share* of users attacked by each type of malware or unwanted software out of all users of Kaspersky mobile solutions attacked in 2024–2025 (download)
* The total may exceed 100% if the same users encountered multiple attack types.
Trojan-Banker malware saw a significant surge in 2025, not only in terms of unique file counts but also in the total number of attacks. Nevertheless, this category ranked fourth overall, trailing far behind the Trojan file category, which was dominated by various modifications of Triada and Fakemoney.
Note that the malware rankings below exclude riskware and potentially unwanted apps, such as RiskTool and adware.
| Verdict | % 2024* | % 2025* | Difference in p.p. | Change in ranking |
| Trojan.AndroidOS.Triada.fe | 0.04 | 9.84 | +9.80 | |
| Trojan.AndroidOS.Triada.gn | 2.94 | 8.14 | +5.21 | +6 |
| Trojan.AndroidOS.Fakemoney.v | 7.46 | 7.97 | +0.51 | +1 |
| DangerousObject.Multi.Generic | 7.73 | 5.83 | –1.91 | –2 |
| Trojan.AndroidOS.Triada.ii | 0.00 | 5.25 | +5.25 | |
| Trojan-Banker.AndroidOS.Mamont.da | 0.10 | 4.12 | +4.02 | |
| Trojan.AndroidOS.Triada.ga | 10.56 | 3.75 | –6.81 | –6 |
| Trojan-Banker.AndroidOS.Mamont.db | 0.01 | 3.53 | +3.51 | |
| Backdoor.AndroidOS.Triada.z | 0.00 | 2.79 | +2.79 | |
| Trojan-Banker.AndroidOS.Coper.c | 0.81 | 2.54 | +1.72 | +35 |
| Trojan-Clicker.AndroidOS.Agent.bh | 0.34 | 2.48 | +2.14 | +74 |
| Trojan-Dropper.Linux.Agent.gen | 1.82 | 2.37 | +0.55 | +4 |
| Trojan.AndroidOS.Boogr.gsh | 5.41 | 2.06 | –3.35 | –8 |
| DangerousObject.AndroidOS.GenericML | 2.42 | 1.97 | –0.45 | –3 |
| Trojan.AndroidOS.Triada.gs | 3.69 | 1.93 | –1.76 | –9 |
| Trojan-Downloader.AndroidOS.Agent.no | 0.00 | 1.87 | +1.87 | |
| Trojan.AndroidOS.Triada.hf | 0.00 | 1.75 | +1.75 | |
| Trojan-Banker.AndroidOS.Mamont.bc | 1.13 | 1.65 | +0.51 | +8 |
| Trojan.AndroidOS.Generic. | 2.13 | 1.47 | –0.66 | –6 |
| Trojan.AndroidOS.Triada.hy | 0.00 | 1.44 | +1.44 |
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.
The list is largely dominated by the Triada family, which is distributed via malicious modifications of popular messaging apps. Another infection vector involves tricking victims into installing an official messaging app within a “customized virtual environment” that supposedly offers enhanced configuration options. Fakemoney scam applications, which promise fraudulent investment opportunities or fake payouts, continue to target users frequently, ranking third in our statistics. Meanwhile, the Mamont banking Trojan variants occupy the 6th, 8th, and 18th positions by number of attacks. The Triada backdoor preinstalled in the firmware of certain devices reached the 9th spot.
This section describes malware families whose attack campaigns are concentrated within specific countries.
| Verdict | Country* | %** |
| Trojan-Banker.AndroidOS.Coper.a | Türkiye | 95.74 |
| Trojan-Dropper.AndroidOS.Hqwar.bj | Türkiye | 94.96 |
| Trojan.AndroidOS.Thamera.bb | India | 94.71 |
| Trojan-Proxy.AndroidOS.Agent.q | Germany | 93.70 |
| Trojan-Banker.AndroidOS.Coper.c | Türkiye | 93.42 |
| Trojan-Banker.AndroidOS.Rewardsteal.lv | India | 92.44 |
| Trojan-Banker.AndroidOS.Rewardsteal.jp | India | 92.31 |
| Trojan-Banker.AndroidOS.Rewardsteal.ib | India | 91.91 |
| Trojan-Dropper.AndroidOS.Rewardsteal.h | India | 91.45 |
| Trojan-Banker.AndroidOS.Rewardsteal.nk | India | 90.98 |
| Trojan-Dropper.AndroidOS.Agent.sm | Türkiye | 90.34 |
| Trojan-Dropper.AndroidOS.Rewardsteal.ac | India | 89.38 |
| Trojan-Banker.AndroidOS.Rewardsteal.oa | India | 89.18 |
| Trojan-Banker.AndroidOS.Rewardsteal.ma | India | 88.58 |
| Trojan-Spy.AndroidOS.SmForw.ko | India | 88.48 |
| Trojan-Dropper.AndroidOS.Pylcasa.c | Brazil | 88.25 |
| Trojan-Dropper.AndroidOS.Hqwar.bf | Türkiye | 88.15 |
| Trojan-Banker.AndroidOS.Agent.pp | India | 87.85 |
* Country where the malware was most active.
** Unique users who encountered the malware in the indicated country as a percentage of all users of Kaspersky mobile solutions who were attacked by the same malware.
Türkiye saw the highest concentration of attacks from Coper banking Trojans and their associated Hqwar droppers. In India, Rewardsteal Trojans continued to proliferate, exfiltrating victims’ payment data under the guise of monetary giveaways. Additionally, India saw a resurgence of the Thamera Trojan, which we previously observed frequently attacking users in 2023. This malware hijacks the victim’s device to illicitly register social media accounts.
The Trojan-Proxy.AndroidOS.Agent.q campaign, concentrated in Germany, utilized a compromised third-party application designed for tracking discounts at a major German retail chain. Attackers monetized these infections through unauthorized use of the victims’ devices as residential proxies.
In Brazil, 2025 saw a concentration of Pylcasa Trojan attacks. This malware is primarily used to redirect users to phishing pages or illicit online casino sites.
The number of new banking Trojan installation packages surged to 255,090, representing a several-fold increase over previous years.
Mobile banking Trojan installation packages detected by Kaspersky in 2022–2025 (download)
Notably, the total number of attacks involving bankers grew by 1.5 times, maintaining the same growth rate seen in the previous year. Given the sharp spike in the number of unique malicious packages, we can conclude that these attacks yield significant profit for cybercriminals. This is further evidenced by the fact that threat actors continue to diversify their delivery channels and accelerate the production of new variants in an effort to evade detection by security solutions.
| Verdict | % 2024* | % 2025* | Difference in p.p. | Change in ranking |
| Trojan-Banker.AndroidOS.Mamont.da | 0.86 | 15.65 | +14.79 | +28 |
| Trojan-Banker.AndroidOS.Mamont.db | 0.12 | 13.41 | +13.29 | |
| Trojan-Banker.AndroidOS.Coper.c | 7.19 | 9.65 | +2.46 | +2 |
| Trojan-Banker.AndroidOS.Mamont.bc | 10.03 | 6.26 | –3.77 | –3 |
| Trojan-Banker.AndroidOS.Mamont.ev | 0.00 | 4.10 | +4.10 | |
| Trojan-Banker.AndroidOS.Coper.a | 9.04 | 4.00 | –5.04 | –4 |
| Trojan-Banker.AndroidOS.Mamont.ek | 0.00 | 3.73 | +3.73 | |
| Trojan-Banker.AndroidOS.Mamont.cb | 0.64 | 3.04 | +2.40 | +26 |
| Trojan-Banker.AndroidOS.Faketoken.pac | 2.17 | 2.95 | +0.77 | +5 |
| Trojan-Banker.AndroidOS.Mamont.hi | 0.00 | 2.75 | +2.75 |
* Unique users who encountered this malware as a percentage of all users of Kaspersky mobile solutions who encountered banking threats.
In 2025, we observed a massive surge in activity from Mamont banking Trojans. They accounted for approximately half of all new apps in their category and also were utilized in half of all banking Trojan attacks.
The year 2025 saw a continuing trend toward a decline in total unique unwanted software installation packages. However, we noted a significant year-over-year increase in specific threats – most notably mobile banking Trojans and spyware – even though adware remained the most frequently detected threat overall.
Among the mobile threats detected, we have seen an increased prevalence of preinstalled backdoors, such as Triada and Keenadu. Consistent with last year’s findings, certain mobile malware families continue to proliferate via official app stores. Finally, we have observed a growing interest among threat actors in leveraging compromised devices as proxies.
In April 2025, we reported on a then-new iteration of the Triada backdoor that had compromised the firmware of counterfeit Android devices sold across major marketplaces. The malware was deployed to the system partitions and hooked into Zygote – the parent process for all Android apps – to infect any app on the device. This allowed the Trojan to exfiltrate credentials from messaging apps and social media platforms, among other things.
This discovery prompted us to dive deeper, looking for other Android firmware-level threats. Our investigation uncovered a new backdoor, dubbed Keenadu, which mirrored Triada’s behavior by embedding itself into the firmware to compromise every app launched on the device. Keenadu proved to have a significant footprint; following its initial detection, we saw a surge in support requests from our users seeking further information about the threat. This report aims to address most of the questions and provide details on this new threat.
Our findings can be summarized as follows:
libandroid_runtime.so. Once active on the device, the malware injected itself into the Zygote process, similarly to Triada. In several instances, the compromised firmware was delivered with an OTA update.The complete Keenadu infection chain looks like this:
Full infection diagram
Kaspersky solutions detect the threats described below with the following verdicts:
HEUR:Backdoor.AndroidOS.Keenadu.*
HEUR:Trojan-Downloader.AndroidOS.Keenadu.*
HEUR:Trojan-Clicker.AndroidOS.Keenadu.*
HEUR:Trojan-Spy.AndroidOS.Keenadu.*
HEUR:Trojan.AndroidOS.Keenadu.*
HEUR:Trojan-Dropper.AndroidOS.Gegu.*
At the very beginning of the investigation, our attention was drawn to suspicious libraries located at /system/lib/libandroid_runtime.so and /system/lib64/libandroid_runtime.so – we will use the shorthand /system/lib[64]/ to denote these two directories. The library exists in the original Android source. Specifically, it defines the println_native native method for the android.util.Log class. Apps utilize this method to write to the logcat system log. In the suspicious libraries, the implementation of println_native differed from the legitimate version by the call of a single function:
Call to the suspicious function
The suspicious function decrypted data from the library body using RC4 and wrote it to /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The data represents a payload that is loaded via DexClassLoader. The entry point within it is the main method of the com.ak.test.Main class, where “ak” likely refers to the author’s internal name for the malware; this letter combination is also used in other locations throughout the code. In particular, the developers left behind a significant amount of code that writes error messages to the logcat log during the malware’s execution. These messages have the AK_CPP tag.
Payload decryption
The payload checks whether it is running within system apps belonging either to Google services or to Sprint or T-Mobile carriers. The latter apps are typically found in specialized device versions that carriers sell at a discount, provided the buyer signs a service contract. The malware aborts its execution if it finds that it’s running within these processes. It also implements a kill switch that terminates its execution if it finds files with specific names in system directories.
Next, the Trojan checks if it is running within the system_server process. This process controls the entire system and possesses maximum privileges; it is launched by the Zygote process when it starts. If the check returns positive, the Trojan creates an instance of the AKServer class; if the code is running in any other process, it creates an instance of the AKClient class instead. It then calls the new object’s virtual method, passing the app process name to it. The class names suggest that the Trojan is built upon a client-server architecture.
Launching system_server in Zygote
The system_server process creates and launches various system services with the help of the SystemServiceManager class. These services are based on a client-server architecture, and clients for them are requested within app code by calling the Context.getSystemService method. Communication with the server-side component uses the Android inter-process communication (IPC) primitive, binder. This approach offers numerous security and other benefits. These include, among other things, the ability to restrict certain apps from accessing various system services and their functionality, as well as the presence of abstractions that simplify the use of this access for developers while simultaneously protecting the system from potential vulnerabilities in apps.
The authors of Keenadu designed it in a similar fashion. The core logic is located in the AKServer class, which operates within the system_server process. AKServer essentially represents a malicious system service, while AKClient acts as the interface for accessing AKServer via binder. For convenience, we provide a diagram of the backdoor’s architecture below:
Keenadu backdoor execution flow
It is important to highlight Keenadu as yet another case where we find key Android security principles being compromised. First, because the malware is embedded in libandroid_runtime.so, it operates within the context of every app on the device, thereby gaining access to all their data and rendering the system’s intended app sandboxing meaningless. Second, it provides interfaces for bypassing permissions (discussed below) that are used to control app privileges within the system. Consequently, it represents a full-fledged backdoor that allows attackers to gain virtually unrestricted control over the victim’s device.
AKClient is relatively straightforward in its design. It is injected into every app launched on the device and retrieves an interface instance for server communication via a protected broadcast (com.action.SystemOptimizeService). Using binder, this interface sends an attach transaction to the malicious AKServer, passing an IPC wrapper that facilitates the loading of arbitrary DEX files within the context of the compromised app. This allows AKServer to execute custom malicious payloads tailored to the specific app it has targeted.
At the start of its execution, AKServer sends two protected broadcasts: com.action.SystemOptimizeService and com.action.SystemProtectService. As previously described, the first broadcast delivers an interface instance to other AKClient-infected processes for interacting with AKServer. Along with the com.action.SystemProtectService message, an instance of another interface for interacting with AKServer is transmitted. Malicious modules downloaded within the contexts of other apps can use this interface to:
Malicious interface for permission management and device data collection
Once interaction between the server and client components is established, AKServer launches its primary malicious task, titled MainWorker. Upon its initial launch, MainWorker logs the current system time. Following this, the malware checks the device’s language settings and time zone. If the interface language is a Chinese dialect and the device is located within a Chinese time zone, the malware terminates. It also remains inactive if either the Google Play Store or Google Play Services are absent from the device. If the device passes these checks, the Trojan initiates the PluginTask task. At the start of its routine, PluginTask decrypts the command-and-control server addresses from the code as follows:
"ota.host.ba60d29da7fd4794b5c5f732916f7d5c", and the initialization vector is the string "0102030405060708".After decrypting the C2 server addresses, the Trojan collects victim device metadata, such as the model, IMEI, MAC address, and OS version, and encrypts it using the same method as the server addresses, but this time it utilizes the MD5 hash of the string "ota.api.bbf6e0a947a5f41d7f5226affcfd858c" as the AES key. The encrypted data is sent to the C2 server via a POST request to the path /ak/api/pts/v4. The request parameters include two values:
The response from the C2 server contains a code field, which may hold an error code returned by the server. If this field has a zero value, no error has occurred. In this case, the response will include a data field: a JSON object encrypted in the same manner as the request data and containing information about the payloads.
After analyzing the initial infection stages, we set out to determine exactly how the backdoor was being integrated into Android device firmware. Almost immediately, we discovered public reports from Alldocube tablet users regarding suspicious DNS queries originating from their devices. This vendor had previously acknowledged the presence of malware in one of its tablet models. However, the company’s statement contained no specifics regarding which malware had compromised the devices or how the breach occurred. We will attempt to answer these questions.
User complaints regarding suspicious DNS queries
The DNS queries described by the original complainant also appeared suspicious to us. According to our telemetry, the Keenadu C2 domains obtained at that time resolved to the IP addresses listed below:
The domains keepgo123[.]com and gsonx[.]com mentioned in the complaint resolved to these same addresses, which may indicate that the complainant’s tablet was also infected with Keenadu. However, matching IP addresses alone is insufficient for a definitive attribution. To test this hypothesis, it was necessary to examine the device itself. We considered purchasing the same tablet model, but this proved unnecessary: as it turns out, Alldocube publishes firmware archives for its devices publicly, allowing anyone to audit them for malware.
To analyze the firmware, one must first determine the storage format of its contents. Alldocube firmware packages are RAR archives containing various image files, other types of files, and a Windows-based flashing utility. From an analytical standpoint, the Android file system holds the most value. Its primary partitions, including the system partition, are contained within the image file super.img. This is an Android Sparse Image. For the sake of brevity, we will omit a technical breakdown of this format (which can be reconstructed from the libsparse code); it is sufficient to note that there are open-source utilities to extract partitions from these files in the form of standard file system images.
We extracted libandroid_runtime.so from the Alldocube iPlay 50 mini Pro (T811M) firmware dated August 18, 2023. Upon examining the library, we discovered the Keenadu backdoor. Furthermore, we decrypted the payload and extracted C2 server addresses hosted on the keepgo123[.]com and gsonx[.]com domains, confirming the user’s suspicions: their devices were indeed infected with this backdoor. Notably, all subsequent firmware versions for this model also proved to be infected, including those released after the vendor’s public statement.
Special attention should be paid to the firmware for the Alldocube iPlay 50 mini Pro NFE model. The “NFE” (Netflix Enabled) part of the name indicates that these devices include an additional DRM module to support high-quality streaming. To achieve this, they must meet the Widevine L1 standard under the Google Widevine DRM premium media protection system. Consequently, they process media within a TEE (Trusted Execution Environment), which mitigates the risk of untrusted code accessing content and thus prevents unauthorized media copying. While Widevine certification failed to protect these devices from infection, the initial Alldocube iPlay 50 mini Pro NFE firmware (released November 7, 2023) was clean – unlike other models’ initial firmware. However, every subsequent version, including the latest release from May 20, 2024, contained Keenadu.
During our analysis of the Alldocube device firmware, we discovered that all images carried valid digital signatures. This implies that simply compromising an OTA update server would have been insufficient for an attacker to inject the backdoor into libandroid_runtime.so. They would also need to gain possession of the private signing keys, which normally should not be accessible from an OTA server. Consequently, it is highly probable that the Trojan was integrated into the firmware during the build phase.
Furthermore, we have found a static library, libVndxUtils.a (MD5: ca98ae7ab25ce144927a46b7fee6bd21), containing the Keenadu code, which further supports our hypothesis. This malicious library is written in C++ and was compiled using the CMake build system. Interestingly, the library retained absolute file paths to the source code on the developer’s machine:
The dropper’s entry point is the function __log_check_tag_count. The attacker inserted a call to this function directly into the implementation of the println_native method.
Code snippet where the attacker inserted the malicious call
According to our data, the malicious dependency was located within the firmware source code repository at the following paths:
Interestingly, the Trojan within libandroid_runtime.so decrypts and writes the payload to disk at /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The attacker most likely attempted to disguise the malicious libandroid_runtime.so dependency as a supposedly legitimate “vndx” component containing proprietary code from MediaTek. In reality, no such component exists in MediaTek products.
Finally, according to our telemetry, the Trojan is found not only in Alldocube devices but also in hardware from other manufacturers. In all instances, the backdoor is embedded within tablet firmware. We have notified these vendors about the compromise.
Based on the evidence presented above, we believe that Keenadu was integrated into Android device firmware as the result of a supply chain attack. One stage of the firmware supply chain was compromised, leading to the inclusion of a malicious dependency within the source code. Consequently, the vendors may have been unaware that their devices were infected prior to reaching the market.
As previously noted, the inherent architecture of Keenadu allows attackers to gain virtually unrestricted control over the victim’s device. To understand exactly how they leveraged this capability, we analyzed the payloads downloaded by the backdoor. To achieve this, we crafted a request to the C2 server, masquerading as an infected device. Initially, the C2 server did not deliver any files; instead, it returned a timestamp for the next check-in, scheduled 2.5 months after the initial request. Through black-box analysis of the C2 server, we determined that the request includes the backdoor’s activation time; if 2.5 months have not elapsed since that moment, the C2 will not serve any payloads. This is likely a technique designed to complicate analysis and minimize the probability of these payloads being detected. Once we modified the activation time in our request to a sufficiently distant date in the past, the C2 server returned the list of payloads for analysis.
The attacker’s server delivers information about the payloads as an object array. Each object contains a download link for the payload, its MD5 hash, target app package names, target process names, and other metadata. An example of such an object is provided below. Notably, the attackers chose Alibaba Cloud as their CDN provider.
Example of payload metadata
Files downloaded by Keenadu utilize a proprietary format to store the encrypted payload and its configuration. A pseudocode description of this format is presented below (struct KeenaduPayload):
struct KeenaduChunk {
uint32_t size;
uint8_t data[size];
} __packed;
struct KeenaduPayload {
int32_t version;
uint8_t padding[0x100];
uint8_t salt[0x20];
KeenaduChunk config;
KeenaduChunk payload;
KeenaduChunk signature;
} __packed;After downloading, Keenadu verifies the file integrity using MD5. The Trojan’s creators also implemented a code-signing mechanism using the DSA algorithm. The signature is verified before the payload is decrypted and executed. This ensures that only an attacker in possession of the private key can generate malicious payloads. Upon successful verification, the configuration and the malicious module are decrypted using AES-128 in CFB mode. The decryption key is the MD5 hash of the string that is a concatenation of "37d9a33df833c0d6f11f1b8079aaa2dc" and a salt, while the initialization vector is the string "0102030405060708".
The configuration contains information regarding the module’s entry and exit points, its name, and its version. An example configuration for one of the modules is provided below.
{
"stopMethod": "stop",
"startMethod": "start",
"pluginId": "com.ak.p.wp",
"service": "1",
"cn": "com.ak.p.d.MainApi",
"m_uninit": "stop",
"version": "3117",
"clazzName": "com.ak.p.d.MainApi",
"m_init": "start"
}Having outlined the backdoor’s algorithm for loading malicious modules, we will now proceed to their analysis.
This module (MD5: 4c4ca7a2a25dbe15a4a39c11cfef2fb2) targets popular online storefronts with the following package names:
The entry point is the start method of the com.ak.p.d.MainApi class. This class initiates a malicious task named HsTask, which serves as a loader conceptually similar to AKServer. Upon execution, the loader collects victim device metadata (model, IMEI, MAC address, OS version, and so on) as well as information regarding the specific app within which it is running. The collected data is encoded using the same method as the AKServer requests sent to /ak/api/pts/v4. Once encoded, the loader exfiltrates the data via a POST request to the C2 server at /ota/api/tasks/v3.
Data collection via the plugin
In response, the attackers’ server returns a list of modules for download and execution, as well as a list of APK files to install on the victim’s device. Interestingly, in newer Android versions, the delivery of these APKs is implemented via installation sessions. This is likely an attempt by the malware to bypass restrictions introduced in recent OS versions, which prevent sideloaded apps from accessing sensitive permissions – specifically accessibility services.
Use of an installation session
Unfortunately, during our research, we were unable to obtain samples of the specific modules and APK files downloaded by this loader. However, users online have reported that infected tablets were adding items to marketplace shopping carts without the user’s knowledge.
User complaint on Reddit
These modules (such as ad60f46e724d88af6bcacb8c269ac3c1) are injected into the following apps:
Upon execution, the malicious module retrieves the device’s location and IP address using a GeoIP service deployed on the attackers’ C2 server. This data, along with the network connection type and OS version, is exfiltrated to the C2. In response, the server returns a specially formatted file containing an encrypted JSON object with payload information, as well as a XOR key for decryption. The structure of this file is described below using pseudocode:
struct Payload {
uint8_t magic[10]; // == "encrypttag"
uint8_t keyLen;
uint8_t xorKey[keyLen];
uint8_t payload[];
} __packed;The decrypted JSON consists of an array of objects containing download links for the payloads and their respective entry points. An example of such an object is provided below. The payloads themselves are encrypted using the same logic as the JSON.
Example of payload metadata
In the course of our research, we obtained several payloads whose primary objective was to interact with advertising elements on various themed websites: gaming, recipes, and news. Each specific module interacts with one particular website whose address is hardcoded into its source.
This module (MD5: 912bc4f756f18049b241934f62bfb06c) targets the Google Chrome browser (com.android.chrome). At the start of its execution, it registers an Activity Lifecycle Callback handler. Whenever an activity is launched within the target app, this handler checks its name. If the name matches the string "ChromeTabbedActivity", the Trojan searches for a text input field (used for search queries and URLs) named url_bar.
Searching for the url_bar text element
If the element is found, the malware monitors text changes within it. All search queries entered by the user into the url_bar field are exfiltrated to the attackers’ server. Furthermore, once the user finishes typing a query, the Trojan can hijack the search request and redirect it to a different search engine, depending on the configuration received from the C2 server.
Search engine hijacking
It is worth noting that the hijacking attempt may fail if the user selects a query from the autocomplete suggestions; in this scenario, the user does not hit Enter or tap the search button in the url_bar, which would signal the malware to trigger the redirect. However, the attackers anticipated this too. The Trojan attempts to locate the omnibox_suggestions_dropdown element within the current activity, a ViewGroup containing the search suggestions. The malware monitors taps on these suggestions and proceeds to redirect the search engine regardless.
Search engine hijacking upon selecting a browser-suggested option
The initial version of this module (MD5: f0184f6955479d631ea4b1ea0f38a35d) was a clicker embedded within the system wallpaper picker (com.android.wallpaper). Researchers at Dr. Web discovered it concurrently with our investigation; however, their report did not mention the clicker’s distribution vector via the Keenadu backdoor. The module utilizes machine learning and WebRTC to interact with advertising elements. While our colleagues at Dr. Web named it Phantom, the C2 server refers to it as Nova. Furthermore, the task executed within the code is named NovaTask. Based on this, we believe the original name of the clicker is Nova.
Nova as the plugin name
It is also worth noting that shortly after the publication of the report on this clicker, the Keenadu C2 server began deleting it from infected devices. This is likely a strategic move by the attackers to evade further detection.
Request to unload the Nova module
Interestingly, in the unload request, the Nova module appeared under a slightly different name. We believe this new name disguises the latest version of the module, which functions as a loader capable of downloading the following components:
A module with the MD5 hash 3dae1f297098fa9d9d4ee0335f0aeed3 is embedded into the system launcher (com.android.launcher3). Upon initialization, it runs an environment check for virtual machine artifacts. If none are detected, the malware registers an event handler for session-based app installations.
Handler registration
Simultaneously, the module requests a configuration file from the C2 server. An example of this configuration is provided below.
Example of a monetization module configuration
When an app installation is initiated on the device, the Trojan transmits data on this app to the C2 server. In response, the server provides information regarding the specific ad used to promote it.
App ad source information
For every successfully completed installation session, the Trojan executes GET requests to the URL provided in the tracking_link field in the response, as well as the first link within the click array. Based on the source code, the links in the click array serve as templates into which various advertising identifiers are injected. The attackers most likely use this method to monetize app installations. By simulating traffic from the victim’s device, the Trojan deceives advertising platforms into believing that the app was installed from a legitimate ad tap.
Even though AKClient shuts down if it is injected into Google Play process, the C2 server have provided us with a payload for it. This module (MD5: 529632abf8246dfe555153de6ae2a9df) retrieves the Google Ads advertising ID and stores it via a global instance of the Settings class under the key S_GA_ID3. Subsequently, other modules may utilize this value as a victim identifier.
Retrieving the advertising ID
During our investigation, we decided to look for alternative sources of Keenadu infections. We discovered that several of the modules described above appeared in attacks that were not linked to the compromise of libandroid_runtime.so. Below are the details of these alternative vectors.
According to our telemetry, the Keenadu loader was found within various system apps in the firmware of several devices. One such app (MD5: d840a70f2610b78493c41b1a344b6893) was a face recognition service with the package name com.aiworks.faceidservice. It contains a set of trained machine-learning models used for facial recognition – specifically for authorizing users via Face ID. To facilitate this, the app defines a service named com.aiworks.lock.face.service.FaceLockService, which the system UI (com.android.systemui) utilizes to unlock the device.
Using the face recognition service in the System UI
Within the onCreate method of the com.aiworks.lock.face.service.FaceLockService, triggered upon that service’s creation, three receivers are registered. These receivers monitor screen on/off events, the start of charging, and the availability of network access. Each of these receivers calls the startMars method whose primary purpose is to initialize the malicious loader by calling the init method of the com.hs.client.TEUtils class.
Malicious call
The loader is a slightly modified version of the Keenadu loader. This specific variant utilizes a native library libhshelper.so to load modules and facilitate APK installs. To accomplish this, the library defines corresponding native methods within the com.hs.helper.NativeMain class.
Native methods defined by the library
This specific attack vector – embedding a loader within system apps – is not inherently new. We have previously documented similar cases, such as the Dwphon loader, which was integrated into system apps responsible for OTA updates. However, this marks the first time we have encountered a Trojan embedded within a facial recognition service.
In addition to the face recognition service, we identified other system apps infected with the Keenadu loader. These included the launcher app on certain devices (MD5: 382764921919868d810a5cf0391ea193). A malicious service, com.pri.appcenter.service.RemoteService, was embedded into these apps to trigger the Trojan’s execution.
We also discovered the Keenadu loader within the app with package name com.tct.contentcenter (MD5: d07eb2db2621c425bda0f046b736e372). This app contains the advertising SDK fwtec, which retrieved its configuration via an HTTP GET request to hxxps://trends.search-hub[.]cn/vuGs8 with default redirection disabled. In response, the Trojan expected a 302 redirect code where the Location header provided an URL containing the SDK configuration within its parameters. One specific parameter, hsby_search_switch, controlled the activation of the Keenadu loader: if its value was set to 1, the loader would initialize within the app.
Retrieving the configuration from the C2
While analyzing our telemetry, we discovered an unusual version of the Keenadu loader (MD5: f53c6ee141df2083e0200a514ba19e32) located in the directories of various apps within external storage, specifically at paths following the pattern: /storage/emulated/0/Android/data/%PACKAGE%/files/.dx/. Based on the code analysis, this loader was designed to operate within a system where the system_server process had already been compromised. Notably, the binder interface names used in this version differed from those used by AKServer. The loader utilized the following interfaces:
These same binder interfaces are defined by another backdoor that is structured similarly and was also discovered within libandroid_runtime.so. The execution of this other backdoor on infected devices proceeds as follows: libandroid_runtime.so imports a malicious function __android_log_check_loggable from the liblog.so library (MD5: 3d185f30b00270e7e30fc4e29a68237f). This function is called within the implementation of the println_native native method of the android.util.Log class. It decrypts a payload embedded in the library’s body using a single-byte XOR and executes it within the context of all apps on the device.
Payload decryption
The payload shares many similarities with BADBOX, a comprehensive malware platform first described by researchers at HUMAN Security. Specifically, the C2 server paths used for the Trojan’s HTTP requests are a match. This leads us to believe that this is a specific variant of BADBOX.
The path /terminal/client/register was previously documented in a HUMAN Security report
Within this backdoor, we also discovered the binder interfaces utilized by the aforementioned Keenadu loader. This suggests that those specific instances of Keenadu were deployed directly by BADBOX.
One of the binder interfaces used by Keenadu is defined in the payload
Unfortunately, even if your firmware does not contain Keenadu or another pre-installed backdoor, the Trojan still poses a threat to you. The Nova (Phantom) clicker was discovered by researchers at Dr. Web around the same time as we held our investigation. Their findings highlight a different distribution vector: modified versions of popular software distributed primarily through unofficial sources, as well as various apps found in the GetApps store.
Infected apps have managed to infiltrate Google Play too. During our research, we identified trojanized software for smart cameras published on the official Android app store. Collectively, these apps had been downloaded more than 300,000 times.
Examples of infected apps in Google Play
Each of these apps contained an embedded service named com.arcsoft.closeli.service.KucopdInitService, which launched the aforementioned Nova clicker. We alerted Google to the presence of the infected apps in its store, and they removed the malware. Curiously, while the malicious service was present in all identified apps, it was configured to execute only in one specific package: com.taismart.global.
The malicious service was launched only under specific conditions
After discovering that BADBOX downloads one of the Keenadu modules, we decided to conduct further research to determine if there were any other signs of a connection between these Trojans. As a result, we found that BADBOX and Keenadu shared similarities in the payload code that was decrypted and executed by the malicious code in libandroid_runtime.so. We also identified similarities between the Keenadu loader and the BB2DOOR module of the BADBOX Trojan. Given that there are also distinct differences in the code, and considering that BADBOX was downloading the Keenadu loader, we believe these are separate botnets, and the developers of Keenadu likely found inspiration in the BADBOX source code. Furthermore, the authors of Keenadu appear to target Android tablets primarily.
In our recent report on the Triada backdoor, we mentioned that the C2 server for one of its downloaded modules was hosted on the same domain as one of the Vo1d botnet’s servers, which could suggest a link between those two Trojans. However, during the current investigation, we managed to uncover a connection between Triada and the BADBOX botnet as well. As it turns out, the directories where BADBOX downloaded the Keenadu loader also contained other payloads for various apps. Their description warrants a separate report; for the sake of brevity, we will not delve into the details here, limiting ourselves to the analysis of a payload for the Telegram and Instagram clients (MD5: 8900f5737e92a69712481d7a809fcfaa). The entry point for this payload is the com.extlib.apps.InsTGEnter class. The payload is designed to steal victims’ account credentials in the infected services. Interestingly, it also contains code for stealing credentials from the WhatsApp client, though it is currently not utilized.
BADBOX payload code used for stealing credentials from WhatsApp clients
The C2 server addresses used by the Trojan to exfiltrate device data are stored in the code in an encrypted format. They are first decoded using Base64 and then decrypted via a XOR operation with the string "xiwljfowkgs".
Decrypted payload C2 addresses
After decrypting the C2 addresses, we discovered the domain zcnewy[.]com, which we had previously identified in 2022 during our investigation of malicious WhatsApp mods containing Triada. At that time, we assumed that the code segment responsible for stealing WhatsApp credentials and the malicious dropper both belonged to Triada. However, since we have now established that zcnewy[.]com is linked to BADBOX, we believe that the infected WhatsApp modifications we described in 2022 actually contained two distinct Trojans: Triada and BADBOX. To verify this hypothesis, we re-examined one of those modifications (MD5: caa640824b0e216fab86402b14447953) and confirmed that it contained the code for both the Triada dropper and a BADBOX module functionally similar to the one described above. Although the Trojans were launched from the same entry point, they did not interact with each other and were structured in entirely different ways. Based on this, we conclude that what we observed in 2022 was a joint attack by the BADBOX and Triada operators.
BADBOX and Triada launched from the same entry point
These findings show that several of the largest Android botnets are interacting with one another. Currently, we have confirmed links between Triada, Vo1d, and BADBOX, as well as the connection between Keenadu and BADBOX. Researchers at HUMAN Security have also previously reported a connection between Vo1d and BADBOX. It is important to emphasize that these connections are not necessarily transitive. For example, the fact that both Triada and Keenadu are linked to BADBOX does not automatically imply that Triada and Keenadu are directly connected; such a claim would require separate evidence. However, given the current landscape, we would not be surprised if future reports provide the evidence needed to prove the transitivity of these relationships.
According to our telemetry, 13,715 users worldwide have encountered Keenadu or its modules. Our security solutions recorded the highest number of users attacked by the malware in Russia, Japan, Germany, Brazil and the Netherlands.
Our technical support team is often asked what steps should be taken if a security solution detects Keenadu on a device. In this section, we examine all possible scenarios for combating this Trojan.
Modern versions of Android mount the system partition, which contains libandroid_runtime.so, as read-only. Even if one were to theoretically assume the possibility of editing this partition, the infected libandroid_runtime.so library cannot be removed without damaging the firmware: the device would simply cease to boot. Therefore, it is impossible to eliminate the threat using standard Android OS tools. Operating a device infected with the Keenadu backdoor can involve significant inconveniences. Reviews of infected devices complain about intrusive ads and various mysterious sounds whose source cannot be identified.
Review of an infected tablet complaining about noise
If you encounter the Keenadu backdoor, we recommend the following:
Unfortunately, as in the previous case, it is not possible to remove such an app from the device because it is located in the system partition. If you encounter the Keenadu loader in a system app, our recommendations are:
adb shell pm disable --user 0 %PACKAGE%.This is one of the simplest cases of infection. If a security solution has detected an app infected with Keenadu on your device, simply uninstall it following the instructions the solution provides.
Developers of pre-installed backdoors in Android device firmware have always stood out for their high level of expertise. This is still true for Keenadu: the creators of the malware have a deep understanding of the Android architecture, the app startup process, and the core security principles of the operating system. During the investigation, we were surprised by the scope of the Keenadu campaigns: beyond the primary backdoor in firmware, its modules were found in system apps and even in apps from Google Play. This places the Trojan on the same scale as threats like Triada or BADBOX. The emergence of a new pre-installed backdoor of this magnitude indicates that this category of malware is a distinct market with significant competition.
Keenadu is a large-scale, complex malware platform that provides attackers with unrestricted control over the victim’s device. Although we have currently shown that the backdoor is used primarily for various types of ad fraud, we do not rule out that in the future, the malware may follow in Triada’s footsteps and begin stealing credentials.
Additional IoCs, technical details and a YARA rule for detecting Keenadu activity are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.
Malicious libandroid_runtime.so libraries
bccd56a6b6c9496ff1acd40628edd25e
c4c0e65a5c56038034555ec4a09d3a37
cb9f86c02f756fb9afdb2fe1ad0184ee
f59ad0c8e47228b603efc0ff790d4a0c
f9b740dd08df6c66009b27c618f1e086
02c4c7209b82bbed19b962fb61ad2de3
185220652fbbc266d4fdf3e668c26e59
36db58957342024f9bc1cdecf2f163d6
4964743c742bb899527017b8d06d4eaa
58f282540ab1bd5ccfb632ef0d273654
59aee75ece46962c4eb09de78edaa3fa
8d493346cb84fbbfdb5187ae046ab8d3
9d16a10031cddd222d26fcb5aa88a009
a191b683a9307276f0fc68a2a9253da1
65f290dd99f9113592fba90ea10cb9b3
68990fbc668b3d2cfbefed874bb24711
6d93fb8897bf94b62a56aca31961756a
Keenadu payloads
2922df6713f865c9cba3de1fe56849d7
3dae1f297098fa9d9d4ee0335f0aeed3
462a23bc22d06e5662d379b9011d89ff
4c4ca7a2a25dbe15a4a39c11cfef2fb2
5048406d8d0affa80c18f8b1d6d76e21
529632abf8246dfe555153de6ae2a9df
7ceccea499cfd3f9f9981104fc05bcbd
912bc4f756f18049b241934f62bfb06c
98ff5a3b5f2cdf2e8f58f96d70db2875
aa5bf06f0cc5a8a3400e90570fb081b0
ad60f46e724d88af6bcacb8c269ac3c1
dc3d454a7edb683bec75a6a1e28a4877
f0184f6955479d631ea4b1ea0f38a35d
System applications infected with Keenadu loader
07546413bdcb0e28eadead4e2b0db59d
0c1f61eeebc4176d533b4fc0a36b9d61
10d8e8765adb1cbe485cb7d7f4df21e4
11eaf02f41b9c93e9b3189aa39059419
19df24591b3d76ad3d0a6f548e608a43
1bfb3edb394d7c018e06ed31c7eea937
1c52e14095f23132719145cf24a2f9dc
21846f602bcabccb00de35d994f153c9
2419583128d7c75e9f0627614c2aa73f
28e6936302f2d290c2fec63ca647f8a6
382764921919868d810a5cf0391ea193
45bf58973111e00e378ee9b7b43b7d2d
56036c2490e63a3e55df4558f7ecf893
64947d3a929e1bb860bf748a15dba57c
69225f41dcae6ddb78a6aa6a3caa82e1
6df8284a4acee337078a6a62a8b65210
6f6e14b4449c0518258beb5a40ad7203
7882796fdae0043153aa75576e5d0b35
7c3e70937da7721dd1243638b467cff1
9ddd621daab4c4bc811b7c1990d7e9ea
a0f775dd99108cb3b76953e25f5cdae4
b841debc5307afc8a4592ea60d64de14
c57de69b401eb58c0aad786531c02c28
ca59e49878bcf2c72b99d15c98323bcd
d07eb2db2621c425bda0f046b736e372
d4be9b2b73e565b1181118cb7f44a102
d9aecc9d4bf1d4b39aa551f3a1bcc6b7
e9bed47953986f90e814ed5ed25b010c
Applications infected with Nova clicker
0bc94bc4bc4d69705e4f08aaf0e976b3
1276480838340dcbc699d1f32f30a5e9
15fb99660dbd52d66f074eaa4cf1366d
2dca15e9e83bca37817f46b24b00d197
350313656502388947c7cbcd08dc5a95
3e36ffda0a946009cb9059b69c6a6f0d
5b0726d66422f76d8ba4fbb9765c68f6
68b64bf1dea3eb314ce273923b8df510
9195454da9e2cb22a3d58dbbf7982be8
a4a6ff86413b3b2a893627c4cff34399
b163fa76bde53cd80d727d88b7b1d94f
ba0a349f177ffb3e398f8c780d911580
bba23f4b66a0e07f837f2832a8cd3bd4
d6ebc5526e957866c02c938fc01349ee
ec7ab99beb846eec4ecee232ac0b3246
ef119626a3b07f46386e65de312cf151
fcaeadbee39fddc907a3ae0315d86178
Payload CDN
ubkt1x.oss-us-west-1.aliyuncs[.]com
m-file-us.oss-us-west-1.aliyuncs[.]com
pkg-czu.istaticfiles[.]com
pkgu.istaticfiles[.]com
app-download.cn-wlcb.ufileos[.]com
C2 servers
110.34.191[.]81
110.34.191[.]82
67.198.232[.]4
67.198.232[.]187
fbsimg[.]com
tmgstatic[.]com
gbugreport[.]com
aifacecloud[.]com
goaimb[.]com
proczone[.]com
gvvt1[.]com
dllpgd[.]click
fbgraph[.]com
newsroomlabss[.]com
sliidee[.]com
keepgo123[.]com
gsonx[.]com
gmsstatic[.]com
ytimg2[.]com
glogstatic[.]com
gstatic2[.]com
uscelluliar[.]com
playstations[.]click
In April 2025, we reported on a then-new iteration of the Triada backdoor that had compromised the firmware of counterfeit Android devices sold across major marketplaces. The malware was deployed to the system partitions and hooked into Zygote – the parent process for all Android apps – to infect any app on the device. This allowed the Trojan to exfiltrate credentials from messaging apps and social media platforms, among other things.
This discovery prompted us to dive deeper, looking for other Android firmware-level threats. Our investigation uncovered a new backdoor, dubbed Keenadu, which mirrored Triada’s behavior by embedding itself into the firmware to compromise every app launched on the device. Keenadu proved to have a significant footprint; following its initial detection, we saw a surge in support requests from our users seeking further information about the threat. This report aims to address most of the questions and provide details on this new threat.
Our findings can be summarized as follows:
libandroid_runtime.so. Once active on the device, the malware injected itself into the Zygote process, similarly to Triada. In several instances, the compromised firmware was delivered with an OTA update.The complete Keenadu infection chain looks like this:
Full infection diagram
Kaspersky solutions detect the threats described below with the following verdicts:
HEUR:Backdoor.AndroidOS.Keenadu.*
HEUR:Trojan-Downloader.AndroidOS.Keenadu.*
HEUR:Trojan-Clicker.AndroidOS.Keenadu.*
HEUR:Trojan-Spy.AndroidOS.Keenadu.*
HEUR:Trojan.AndroidOS.Keenadu.*
HEUR:Trojan-Dropper.AndroidOS.Gegu.*
At the very beginning of the investigation, our attention was drawn to suspicious libraries located at /system/lib/libandroid_runtime.so and /system/lib64/libandroid_runtime.so – we will use the shorthand /system/lib[64]/ to denote these two directories. The library exists in the original Android source. Specifically, it defines the println_native native method for the android.util.Log class. Apps utilize this method to write to the logcat system log. In the suspicious libraries, the implementation of println_native differed from the legitimate version by the call of a single function:
Call to the suspicious function
The suspicious function decrypted data from the library body using RC4 and wrote it to /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The data represents a payload that is loaded via DexClassLoader. The entry point within it is the main method of the com.ak.test.Main class, where “ak” likely refers to the author’s internal name for the malware; this letter combination is also used in other locations throughout the code. In particular, the developers left behind a significant amount of code that writes error messages to the logcat log during the malware’s execution. These messages have the AK_CPP tag.
Payload decryption
The payload checks whether it is running within system apps belonging either to Google services or to Sprint or T-Mobile carriers. The latter apps are typically found in specialized device versions that carriers sell at a discount, provided the buyer signs a service contract. The malware aborts its execution if it finds that it’s running within these processes. It also implements a kill switch that terminates its execution if it finds files with specific names in system directories.
Next, the Trojan checks if it is running within the system_server process. This process controls the entire system and possesses maximum privileges; it is launched by the Zygote process when it starts. If the check returns positive, the Trojan creates an instance of the AKServer class; if the code is running in any other process, it creates an instance of the AKClient class instead. It then calls the new object’s virtual method, passing the app process name to it. The class names suggest that the Trojan is built upon a client-server architecture.
Launching system_server in Zygote
The system_server process creates and launches various system services with the help of the SystemServiceManager class. These services are based on a client-server architecture, and clients for them are requested within app code by calling the Context.getSystemService method. Communication with the server-side component uses the Android inter-process communication (IPC) primitive, binder. This approach offers numerous security and other benefits. These include, among other things, the ability to restrict certain apps from accessing various system services and their functionality, as well as the presence of abstractions that simplify the use of this access for developers while simultaneously protecting the system from potential vulnerabilities in apps.
The authors of Keenadu designed it in a similar fashion. The core logic is located in the AKServer class, which operates within the system_server process. AKServer essentially represents a malicious system service, while AKClient acts as the interface for accessing AKServer via binder. For convenience, we provide a diagram of the backdoor’s architecture below:
Keenadu backdoor execution flow
It is important to highlight Keenadu as yet another case where we find key Android security principles being compromised. First, because the malware is embedded in libandroid_runtime.so, it operates within the context of every app on the device, thereby gaining access to all their data and rendering the system’s intended app sandboxing meaningless. Second, it provides interfaces for bypassing permissions (discussed below) that are used to control app privileges within the system. Consequently, it represents a full-fledged backdoor that allows attackers to gain virtually unrestricted control over the victim’s device.
AKClient is relatively straightforward in its design. It is injected into every app launched on the device and retrieves an interface instance for server communication via a protected broadcast (com.action.SystemOptimizeService). Using binder, this interface sends an attach transaction to the malicious AKServer, passing an IPC wrapper that facilitates the loading of arbitrary DEX files within the context of the compromised app. This allows AKServer to execute custom malicious payloads tailored to the specific app it has targeted.
At the start of its execution, AKServer sends two protected broadcasts: com.action.SystemOptimizeService and com.action.SystemProtectService. As previously described, the first broadcast delivers an interface instance to other AKClient-infected processes for interacting with AKServer. Along with the com.action.SystemProtectService message, an instance of another interface for interacting with AKServer is transmitted. Malicious modules downloaded within the contexts of other apps can use this interface to:
Malicious interface for permission management and device data collection
Once interaction between the server and client components is established, AKServer launches its primary malicious task, titled MainWorker. Upon its initial launch, MainWorker logs the current system time. Following this, the malware checks the device’s language settings and time zone. If the interface language is a Chinese dialect and the device is located within a Chinese time zone, the malware terminates. It also remains inactive if either the Google Play Store or Google Play Services are absent from the device. If the device passes these checks, the Trojan initiates the PluginTask task. At the start of its routine, PluginTask decrypts the command-and-control server addresses from the code as follows:
"ota.host.ba60d29da7fd4794b5c5f732916f7d5c", and the initialization vector is the string "0102030405060708".After decrypting the C2 server addresses, the Trojan collects victim device metadata, such as the model, IMEI, MAC address, and OS version, and encrypts it using the same method as the server addresses, but this time it utilizes the MD5 hash of the string "ota.api.bbf6e0a947a5f41d7f5226affcfd858c" as the AES key. The encrypted data is sent to the C2 server via a POST request to the path /ak/api/pts/v4. The request parameters include two values:
The response from the C2 server contains a code field, which may hold an error code returned by the server. If this field has a zero value, no error has occurred. In this case, the response will include a data field: a JSON object encrypted in the same manner as the request data and containing information about the payloads.
After analyzing the initial infection stages, we set out to determine exactly how the backdoor was being integrated into Android device firmware. Almost immediately, we discovered public reports from Alldocube tablet users regarding suspicious DNS queries originating from their devices. This vendor had previously acknowledged the presence of malware in one of its tablet models. However, the company’s statement contained no specifics regarding which malware had compromised the devices or how the breach occurred. We will attempt to answer these questions.
User complaints regarding suspicious DNS queries
The DNS queries described by the original complainant also appeared suspicious to us. According to our telemetry, the Keenadu C2 domains obtained at that time resolved to the IP addresses listed below:
The domains keepgo123[.]com and gsonx[.]com mentioned in the complaint resolved to these same addresses, which may indicate that the complainant’s tablet was also infected with Keenadu. However, matching IP addresses alone is insufficient for a definitive attribution. To test this hypothesis, it was necessary to examine the device itself. We considered purchasing the same tablet model, but this proved unnecessary: as it turns out, Alldocube publishes firmware archives for its devices publicly, allowing anyone to audit them for malware.
To analyze the firmware, one must first determine the storage format of its contents. Alldocube firmware packages are RAR archives containing various image files, other types of files, and a Windows-based flashing utility. From an analytical standpoint, the Android file system holds the most value. Its primary partitions, including the system partition, are contained within the image file super.img. This is an Android Sparse Image. For the sake of brevity, we will omit a technical breakdown of this format (which can be reconstructed from the libsparse code); it is sufficient to note that there are open-source utilities to extract partitions from these files in the form of standard file system images.
We extracted libandroid_runtime.so from the Alldocube iPlay 50 mini Pro (T811M) firmware dated August 18, 2023. Upon examining the library, we discovered the Keenadu backdoor. Furthermore, we decrypted the payload and extracted C2 server addresses hosted on the keepgo123[.]com and gsonx[.]com domains, confirming the user’s suspicions: their devices were indeed infected with this backdoor. Notably, all subsequent firmware versions for this model also proved to be infected, including those released after the vendor’s public statement.
Special attention should be paid to the firmware for the Alldocube iPlay 50 mini Pro NFE model. The “NFE” (Netflix Enabled) part of the name indicates that these devices include an additional DRM module to support high-quality streaming. To achieve this, they must meet the Widevine L1 standard under the Google Widevine DRM premium media protection system. Consequently, they process media within a TEE (Trusted Execution Environment), which mitigates the risk of untrusted code accessing content and thus prevents unauthorized media copying. While Widevine certification failed to protect these devices from infection, the initial Alldocube iPlay 50 mini Pro NFE firmware (released November 7, 2023) was clean – unlike other models’ initial firmware. However, every subsequent version, including the latest release from May 20, 2024, contained Keenadu.
During our analysis of the Alldocube device firmware, we discovered that all images carried valid digital signatures. This implies that simply compromising an OTA update server would have been insufficient for an attacker to inject the backdoor into libandroid_runtime.so. They would also need to gain possession of the private signing keys, which normally should not be accessible from an OTA server. Consequently, it is highly probable that the Trojan was integrated into the firmware during the build phase.
Furthermore, we have found a static library, libVndxUtils.a (MD5: ca98ae7ab25ce144927a46b7fee6bd21), containing the Keenadu code, which further supports our hypothesis. This malicious library is written in C++ and was compiled using the CMake build system. Interestingly, the library retained absolute file paths to the source code on the developer’s machine:
The dropper’s entry point is the function __log_check_tag_count. The attacker inserted a call to this function directly into the implementation of the println_native method.
Code snippet where the attacker inserted the malicious call
According to our data, the malicious dependency was located within the firmware source code repository at the following paths:
Interestingly, the Trojan within libandroid_runtime.so decrypts and writes the payload to disk at /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The attacker most likely attempted to disguise the malicious libandroid_runtime.so dependency as a supposedly legitimate “vndx” component containing proprietary code from MediaTek. In reality, no such component exists in MediaTek products.
Finally, according to our telemetry, the Trojan is found not only in Alldocube devices but also in hardware from other manufacturers. In all instances, the backdoor is embedded within tablet firmware. We have notified these vendors about the compromise.
Based on the evidence presented above, we believe that Keenadu was integrated into Android device firmware as the result of a supply chain attack. One stage of the firmware supply chain was compromised, leading to the inclusion of a malicious dependency within the source code. Consequently, the vendors may have been unaware that their devices were infected prior to reaching the market.
As previously noted, the inherent architecture of Keenadu allows attackers to gain virtually unrestricted control over the victim’s device. To understand exactly how they leveraged this capability, we analyzed the payloads downloaded by the backdoor. To achieve this, we crafted a request to the C2 server, masquerading as an infected device. Initially, the C2 server did not deliver any files; instead, it returned a timestamp for the next check-in, scheduled 2.5 months after the initial request. Through black-box analysis of the C2 server, we determined that the request includes the backdoor’s activation time; if 2.5 months have not elapsed since that moment, the C2 will not serve any payloads. This is likely a technique designed to complicate analysis and minimize the probability of these payloads being detected. Once we modified the activation time in our request to a sufficiently distant date in the past, the C2 server returned the list of payloads for analysis.
The attacker’s server delivers information about the payloads as an object array. Each object contains a download link for the payload, its MD5 hash, target app package names, target process names, and other metadata. An example of such an object is provided below. Notably, the attackers chose Alibaba Cloud as their CDN provider.
Example of payload metadata
Files downloaded by Keenadu utilize a proprietary format to store the encrypted payload and its configuration. A pseudocode description of this format is presented below (struct KeenaduPayload):
struct KeenaduChunk {
uint32_t size;
uint8_t data[size];
} __packed;
struct KeenaduPayload {
int32_t version;
uint8_t padding[0x100];
uint8_t salt[0x20];
KeenaduChunk config;
KeenaduChunk payload;
KeenaduChunk signature;
} __packed;After downloading, Keenadu verifies the file integrity using MD5. The Trojan’s creators also implemented a code-signing mechanism using the DSA algorithm. The signature is verified before the payload is decrypted and executed. This ensures that only an attacker in possession of the private key can generate malicious payloads. Upon successful verification, the configuration and the malicious module are decrypted using AES-128 in CFB mode. The decryption key is the MD5 hash of the string that is a concatenation of "37d9a33df833c0d6f11f1b8079aaa2dc" and a salt, while the initialization vector is the string "0102030405060708".
The configuration contains information regarding the module’s entry and exit points, its name, and its version. An example configuration for one of the modules is provided below.
{
"stopMethod": "stop",
"startMethod": "start",
"pluginId": "com.ak.p.wp",
"service": "1",
"cn": "com.ak.p.d.MainApi",
"m_uninit": "stop",
"version": "3117",
"clazzName": "com.ak.p.d.MainApi",
"m_init": "start"
}Having outlined the backdoor’s algorithm for loading malicious modules, we will now proceed to their analysis.
This module (MD5: 4c4ca7a2a25dbe15a4a39c11cfef2fb2) targets popular online storefronts with the following package names:
The entry point is the start method of the com.ak.p.d.MainApi class. This class initiates a malicious task named HsTask, which serves as a loader conceptually similar to AKServer. Upon execution, the loader collects victim device metadata (model, IMEI, MAC address, OS version, and so on) as well as information regarding the specific app within which it is running. The collected data is encoded using the same method as the AKServer requests sent to /ak/api/pts/v4. Once encoded, the loader exfiltrates the data via a POST request to the C2 server at /ota/api/tasks/v3.
Data collection via the plugin
In response, the attackers’ server returns a list of modules for download and execution, as well as a list of APK files to install on the victim’s device. Interestingly, in newer Android versions, the delivery of these APKs is implemented via installation sessions. This is likely an attempt by the malware to bypass restrictions introduced in recent OS versions, which prevent sideloaded apps from accessing sensitive permissions – specifically accessibility services.
Use of an installation session
Unfortunately, during our research, we were unable to obtain samples of the specific modules and APK files downloaded by this loader. However, users online have reported that infected tablets were adding items to marketplace shopping carts without the user’s knowledge.
User complaint on Reddit
These modules (such as ad60f46e724d88af6bcacb8c269ac3c1) are injected into the following apps:
Upon execution, the malicious module retrieves the device’s location and IP address using a GeoIP service deployed on the attackers’ C2 server. This data, along with the network connection type and OS version, is exfiltrated to the C2. In response, the server returns a specially formatted file containing an encrypted JSON object with payload information, as well as a XOR key for decryption. The structure of this file is described below using pseudocode:
struct Payload {
uint8_t magic[10]; // == "encrypttag"
uint8_t keyLen;
uint8_t xorKey[keyLen];
uint8_t payload[];
} __packed;The decrypted JSON consists of an array of objects containing download links for the payloads and their respective entry points. An example of such an object is provided below. The payloads themselves are encrypted using the same logic as the JSON.
Example of payload metadata
In the course of our research, we obtained several payloads whose primary objective was to interact with advertising elements on various themed websites: gaming, recipes, and news. Each specific module interacts with one particular website whose address is hardcoded into its source.
This module (MD5: 912bc4f756f18049b241934f62bfb06c) targets the Google Chrome browser (com.android.chrome). At the start of its execution, it registers an Activity Lifecycle Callback handler. Whenever an activity is launched within the target app, this handler checks its name. If the name matches the string "ChromeTabbedActivity", the Trojan searches for a text input field (used for search queries and URLs) named url_bar.
Searching for the url_bar text element
If the element is found, the malware monitors text changes within it. All search queries entered by the user into the url_bar field are exfiltrated to the attackers’ server. Furthermore, once the user finishes typing a query, the Trojan can hijack the search request and redirect it to a different search engine, depending on the configuration received from the C2 server.
Search engine hijacking
It is worth noting that the hijacking attempt may fail if the user selects a query from the autocomplete suggestions; in this scenario, the user does not hit Enter or tap the search button in the url_bar, which would signal the malware to trigger the redirect. However, the attackers anticipated this too. The Trojan attempts to locate the omnibox_suggestions_dropdown element within the current activity, a ViewGroup containing the search suggestions. The malware monitors taps on these suggestions and proceeds to redirect the search engine regardless.
Search engine hijacking upon selecting a browser-suggested option
The initial version of this module (MD5: f0184f6955479d631ea4b1ea0f38a35d) was a clicker embedded within the system wallpaper picker (com.android.wallpaper). Researchers at Dr. Web discovered it concurrently with our investigation; however, their report did not mention the clicker’s distribution vector via the Keenadu backdoor. The module utilizes machine learning and WebRTC to interact with advertising elements. While our colleagues at Dr. Web named it Phantom, the C2 server refers to it as Nova. Furthermore, the task executed within the code is named NovaTask. Based on this, we believe the original name of the clicker is Nova.
Nova as the plugin name
It is also worth noting that shortly after the publication of the report on this clicker, the Keenadu C2 server began deleting it from infected devices. This is likely a strategic move by the attackers to evade further detection.
Request to unload the Nova module
Interestingly, in the unload request, the Nova module appeared under a slightly different name. We believe this new name disguises the latest version of the module, which functions as a loader capable of downloading the following components:
A module with the MD5 hash 3dae1f297098fa9d9d4ee0335f0aeed3 is embedded into the system launcher (com.android.launcher3). Upon initialization, it runs an environment check for virtual machine artifacts. If none are detected, the malware registers an event handler for session-based app installations.
Handler registration
Simultaneously, the module requests a configuration file from the C2 server. An example of this configuration is provided below.
Example of a monetization module configuration
When an app installation is initiated on the device, the Trojan transmits data on this app to the C2 server. In response, the server provides information regarding the specific ad used to promote it.
App ad source information
For every successfully completed installation session, the Trojan executes GET requests to the URL provided in the tracking_link field in the response, as well as the first link within the click array. Based on the source code, the links in the click array serve as templates into which various advertising identifiers are injected. The attackers most likely use this method to monetize app installations. By simulating traffic from the victim’s device, the Trojan deceives advertising platforms into believing that the app was installed from a legitimate ad tap.
Even though AKClient shuts down if it is injected into Google Play process, the C2 server have provided us with a payload for it. This module (MD5: 529632abf8246dfe555153de6ae2a9df) retrieves the Google Ads advertising ID and stores it via a global instance of the Settings class under the key S_GA_ID3. Subsequently, other modules may utilize this value as a victim identifier.
Retrieving the advertising ID
During our investigation, we decided to look for alternative sources of Keenadu infections. We discovered that several of the modules described above appeared in attacks that were not linked to the compromise of libandroid_runtime.so. Below are the details of these alternative vectors.
According to our telemetry, the Keenadu loader was found within various system apps in the firmware of several devices. One such app (MD5: d840a70f2610b78493c41b1a344b6893) was a face recognition service with the package name com.aiworks.faceidservice. It contains a set of trained machine-learning models used for facial recognition – specifically for authorizing users via Face ID. To facilitate this, the app defines a service named com.aiworks.lock.face.service.FaceLockService, which the system UI (com.android.systemui) utilizes to unlock the device.
Using the face recognition service in the System UI
Within the onCreate method of the com.aiworks.lock.face.service.FaceLockService, triggered upon that service’s creation, three receivers are registered. These receivers monitor screen on/off events, the start of charging, and the availability of network access. Each of these receivers calls the startMars method whose primary purpose is to initialize the malicious loader by calling the init method of the com.hs.client.TEUtils class.
Malicious call
The loader is a slightly modified version of the Keenadu loader. This specific variant utilizes a native library libhshelper.so to load modules and facilitate APK installs. To accomplish this, the library defines corresponding native methods within the com.hs.helper.NativeMain class.
Native methods defined by the library
This specific attack vector – embedding a loader within system apps – is not inherently new. We have previously documented similar cases, such as the Dwphon loader, which was integrated into system apps responsible for OTA updates. However, this marks the first time we have encountered a Trojan embedded within a facial recognition service.
In addition to the face recognition service, we identified other system apps infected with the Keenadu loader. These included the launcher app on certain devices (MD5: 382764921919868d810a5cf0391ea193). A malicious service, com.pri.appcenter.service.RemoteService, was embedded into these apps to trigger the Trojan’s execution.
We also discovered the Keenadu loader within the app with package name com.tct.contentcenter (MD5: d07eb2db2621c425bda0f046b736e372). This app contains the advertising SDK fwtec, which retrieved its configuration via an HTTP GET request to hxxps://trends.search-hub[.]cn/vuGs8 with default redirection disabled. In response, the Trojan expected a 302 redirect code where the Location header provided an URL containing the SDK configuration within its parameters. One specific parameter, hsby_search_switch, controlled the activation of the Keenadu loader: if its value was set to 1, the loader would initialize within the app.
Retrieving the configuration from the C2
While analyzing our telemetry, we discovered an unusual version of the Keenadu loader (MD5: f53c6ee141df2083e0200a514ba19e32) located in the directories of various apps within external storage, specifically at paths following the pattern: /storage/emulated/0/Android/data/%PACKAGE%/files/.dx/. Based on the code analysis, this loader was designed to operate within a system where the system_server process had already been compromised. Notably, the binder interface names used in this version differed from those used by AKServer. The loader utilized the following interfaces:
These same binder interfaces are defined by another backdoor that is structured similarly and was also discovered within libandroid_runtime.so. The execution of this other backdoor on infected devices proceeds as follows: libandroid_runtime.so imports a malicious function __android_log_check_loggable from the liblog.so library (MD5: 3d185f30b00270e7e30fc4e29a68237f). This function is called within the implementation of the println_native native method of the android.util.Log class. It decrypts a payload embedded in the library’s body using a single-byte XOR and executes it within the context of all apps on the device.
Payload decryption
The payload shares many similarities with BADBOX, a comprehensive malware platform first described by researchers at HUMAN Security. Specifically, the C2 server paths used for the Trojan’s HTTP requests are a match. This leads us to believe that this is a specific variant of BADBOX.
The path /terminal/client/register was previously documented in a HUMAN Security report
Within this backdoor, we also discovered the binder interfaces utilized by the aforementioned Keenadu loader. This suggests that those specific instances of Keenadu were deployed directly by BADBOX.
One of the binder interfaces used by Keenadu is defined in the payload
Unfortunately, even if your firmware does not contain Keenadu or another pre-installed backdoor, the Trojan still poses a threat to you. The Nova (Phantom) clicker was discovered by researchers at Dr. Web around the same time as we held our investigation. Their findings highlight a different distribution vector: modified versions of popular software distributed primarily through unofficial sources, as well as various apps found in the GetApps store.
Infected apps have managed to infiltrate Google Play too. During our research, we identified trojanized software for smart cameras published on the official Android app store. Collectively, these apps had been downloaded more than 300,000 times.
Examples of infected apps in Google Play
Each of these apps contained an embedded service named com.arcsoft.closeli.service.KucopdInitService, which launched the aforementioned Nova clicker. We alerted Google to the presence of the infected apps in its store, and they removed the malware. Curiously, while the malicious service was present in all identified apps, it was configured to execute only in one specific package: com.taismart.global.
The malicious service was launched only under specific conditions
After discovering that BADBOX downloads one of the Keenadu modules, we decided to conduct further research to determine if there were any other signs of a connection between these Trojans. As a result, we found that BADBOX and Keenadu shared similarities in the payload code that was decrypted and executed by the malicious code in libandroid_runtime.so. We also identified similarities between the Keenadu loader and the BB2DOOR module of the BADBOX Trojan. Given that there are also distinct differences in the code, and considering that BADBOX was downloading the Keenadu loader, we believe these are separate botnets, and the developers of Keenadu likely found inspiration in the BADBOX source code. Furthermore, the authors of Keenadu appear to target Android tablets primarily.
In our recent report on the Triada backdoor, we mentioned that the C2 server for one of its downloaded modules was hosted on the same domain as one of the Vo1d botnet’s servers, which could suggest a link between those two Trojans. However, during the current investigation, we managed to uncover a connection between Triada and the BADBOX botnet as well. As it turns out, the directories where BADBOX downloaded the Keenadu loader also contained other payloads for various apps. Their description warrants a separate report; for the sake of brevity, we will not delve into the details here, limiting ourselves to the analysis of a payload for the Telegram and Instagram clients (MD5: 8900f5737e92a69712481d7a809fcfaa). The entry point for this payload is the com.extlib.apps.InsTGEnter class. The payload is designed to steal victims’ account credentials in the infected services. Interestingly, it also contains code for stealing credentials from the WhatsApp client, though it is currently not utilized.
BADBOX payload code used for stealing credentials from WhatsApp clients
The C2 server addresses used by the Trojan to exfiltrate device data are stored in the code in an encrypted format. They are first decoded using Base64 and then decrypted via a XOR operation with the string "xiwljfowkgs".
Decrypted payload C2 addresses
After decrypting the C2 addresses, we discovered the domain zcnewy[.]com, which we had previously identified in 2022 during our investigation of malicious WhatsApp mods containing Triada. At that time, we assumed that the code segment responsible for stealing WhatsApp credentials and the malicious dropper both belonged to Triada. However, since we have now established that zcnewy[.]com is linked to BADBOX, we believe that the infected WhatsApp modifications we described in 2022 actually contained two distinct Trojans: Triada and BADBOX. To verify this hypothesis, we re-examined one of those modifications (MD5: caa640824b0e216fab86402b14447953) and confirmed that it contained the code for both the Triada dropper and a BADBOX module functionally similar to the one described above. Although the Trojans were launched from the same entry point, they did not interact with each other and were structured in entirely different ways. Based on this, we conclude that what we observed in 2022 was a joint attack by the BADBOX and Triada operators.
BADBOX and Triada launched from the same entry point
These findings show that several of the largest Android botnets are interacting with one another. Currently, we have confirmed links between Triada, Vo1d, and BADBOX, as well as the connection between Keenadu and BADBOX. Researchers at HUMAN Security have also previously reported a connection between Vo1d and BADBOX. It is important to emphasize that these connections are not necessarily transitive. For example, the fact that both Triada and Keenadu are linked to BADBOX does not automatically imply that Triada and Keenadu are directly connected; such a claim would require separate evidence. However, given the current landscape, we would not be surprised if future reports provide the evidence needed to prove the transitivity of these relationships.
According to our telemetry, 13,715 users worldwide have encountered Keenadu or its modules. Our security solutions recorded the highest number of users attacked by the malware in Russia, Japan, Germany, Brazil and the Netherlands.
Our technical support team is often asked what steps should be taken if a security solution detects Keenadu on a device. In this section, we examine all possible scenarios for combating this Trojan.
Modern versions of Android mount the system partition, which contains libandroid_runtime.so, as read-only. Even if one were to theoretically assume the possibility of editing this partition, the infected libandroid_runtime.so library cannot be removed without damaging the firmware: the device would simply cease to boot. Therefore, it is impossible to eliminate the threat using standard Android OS tools. Operating a device infected with the Keenadu backdoor can involve significant inconveniences. Reviews of infected devices complain about intrusive ads and various mysterious sounds whose source cannot be identified.
Review of an infected tablet complaining about noise
If you encounter the Keenadu backdoor, we recommend the following:
Unfortunately, as in the previous case, it is not possible to remove such an app from the device because it is located in the system partition. If you encounter the Keenadu loader in a system app, our recommendations are:
adb shell pm disable --user 0 %PACKAGE%.This is one of the simplest cases of infection. If a security solution has detected an app infected with Keenadu on your device, simply uninstall it following the instructions the solution provides.
Developers of pre-installed backdoors in Android device firmware have always stood out for their high level of expertise. This is still true for Keenadu: the creators of the malware have a deep understanding of the Android architecture, the app startup process, and the core security principles of the operating system. During the investigation, we were surprised by the scope of the Keenadu campaigns: beyond the primary backdoor in firmware, its modules were found in system apps and even in apps from Google Play. This places the Trojan on the same scale as threats like Triada or BADBOX. The emergence of a new pre-installed backdoor of this magnitude indicates that this category of malware is a distinct market with significant competition.
Keenadu is a large-scale, complex malware platform that provides attackers with unrestricted control over the victim’s device. Although we have currently shown that the backdoor is used primarily for various types of ad fraud, we do not rule out that in the future, the malware may follow in Triada’s footsteps and begin stealing credentials.
Additional IoCs, technical details and a YARA rule for detecting Keenadu activity are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.
Malicious libandroid_runtime.so libraries
bccd56a6b6c9496ff1acd40628edd25e
c4c0e65a5c56038034555ec4a09d3a37
cb9f86c02f756fb9afdb2fe1ad0184ee
f59ad0c8e47228b603efc0ff790d4a0c
f9b740dd08df6c66009b27c618f1e086
02c4c7209b82bbed19b962fb61ad2de3
185220652fbbc266d4fdf3e668c26e59
36db58957342024f9bc1cdecf2f163d6
4964743c742bb899527017b8d06d4eaa
58f282540ab1bd5ccfb632ef0d273654
59aee75ece46962c4eb09de78edaa3fa
8d493346cb84fbbfdb5187ae046ab8d3
9d16a10031cddd222d26fcb5aa88a009
a191b683a9307276f0fc68a2a9253da1
65f290dd99f9113592fba90ea10cb9b3
68990fbc668b3d2cfbefed874bb24711
6d93fb8897bf94b62a56aca31961756a
Keenadu payloads
2922df6713f865c9cba3de1fe56849d7
3dae1f297098fa9d9d4ee0335f0aeed3
462a23bc22d06e5662d379b9011d89ff
4c4ca7a2a25dbe15a4a39c11cfef2fb2
5048406d8d0affa80c18f8b1d6d76e21
529632abf8246dfe555153de6ae2a9df
7ceccea499cfd3f9f9981104fc05bcbd
912bc4f756f18049b241934f62bfb06c
98ff5a3b5f2cdf2e8f58f96d70db2875
aa5bf06f0cc5a8a3400e90570fb081b0
ad60f46e724d88af6bcacb8c269ac3c1
dc3d454a7edb683bec75a6a1e28a4877
f0184f6955479d631ea4b1ea0f38a35d
System applications infected with Keenadu loader
07546413bdcb0e28eadead4e2b0db59d
0c1f61eeebc4176d533b4fc0a36b9d61
10d8e8765adb1cbe485cb7d7f4df21e4
11eaf02f41b9c93e9b3189aa39059419
19df24591b3d76ad3d0a6f548e608a43
1bfb3edb394d7c018e06ed31c7eea937
1c52e14095f23132719145cf24a2f9dc
21846f602bcabccb00de35d994f153c9
2419583128d7c75e9f0627614c2aa73f
28e6936302f2d290c2fec63ca647f8a6
382764921919868d810a5cf0391ea193
45bf58973111e00e378ee9b7b43b7d2d
56036c2490e63a3e55df4558f7ecf893
64947d3a929e1bb860bf748a15dba57c
69225f41dcae6ddb78a6aa6a3caa82e1
6df8284a4acee337078a6a62a8b65210
6f6e14b4449c0518258beb5a40ad7203
7882796fdae0043153aa75576e5d0b35
7c3e70937da7721dd1243638b467cff1
9ddd621daab4c4bc811b7c1990d7e9ea
a0f775dd99108cb3b76953e25f5cdae4
b841debc5307afc8a4592ea60d64de14
c57de69b401eb58c0aad786531c02c28
ca59e49878bcf2c72b99d15c98323bcd
d07eb2db2621c425bda0f046b736e372
d4be9b2b73e565b1181118cb7f44a102
d9aecc9d4bf1d4b39aa551f3a1bcc6b7
e9bed47953986f90e814ed5ed25b010c
Applications infected with Nova clicker
0bc94bc4bc4d69705e4f08aaf0e976b3
1276480838340dcbc699d1f32f30a5e9
15fb99660dbd52d66f074eaa4cf1366d
2dca15e9e83bca37817f46b24b00d197
350313656502388947c7cbcd08dc5a95
3e36ffda0a946009cb9059b69c6a6f0d
5b0726d66422f76d8ba4fbb9765c68f6
68b64bf1dea3eb314ce273923b8df510
9195454da9e2cb22a3d58dbbf7982be8
a4a6ff86413b3b2a893627c4cff34399
b163fa76bde53cd80d727d88b7b1d94f
ba0a349f177ffb3e398f8c780d911580
bba23f4b66a0e07f837f2832a8cd3bd4
d6ebc5526e957866c02c938fc01349ee
ec7ab99beb846eec4ecee232ac0b3246
ef119626a3b07f46386e65de312cf151
fcaeadbee39fddc907a3ae0315d86178
Payload CDN
ubkt1x.oss-us-west-1.aliyuncs[.]com
m-file-us.oss-us-west-1.aliyuncs[.]com
pkg-czu.istaticfiles[.]com
pkgu.istaticfiles[.]com
app-download.cn-wlcb.ufileos[.]com
C2 servers
110.34.191[.]81
110.34.191[.]82
67.198.232[.]4
67.198.232[.]187
fbsimg[.]com
tmgstatic[.]com
gbugreport[.]com
aifacecloud[.]com
goaimb[.]com
proczone[.]com
gvvt1[.]com
dllpgd[.]click
fbgraph[.]com
newsroomlabss[.]com
sliidee[.]com
keepgo123[.]com
gsonx[.]com
gmsstatic[.]com
ytimg2[.]com
glogstatic[.]com
gstatic2[.]com
uscelluliar[.]com
playstations[.]click
The latest Android version continues to improve security and privacy, according to its developers.
The post Android 17 Beta Strengthens Secure-by-Default Design for Privacy and App Security appeared first on SecurityWeek.
Phone theft is more than just losing a device; it's a form of financial fraud that can leave you suddenly vulnerable to personal data and financial theft. That’s why we're committed to providing multi-layered defenses that help protect you before, during, and after a theft attempt.
Today, we're announcing a powerful set of theft protection feature updates that build on our existing protections, designed to give you greater peace of mind by making your device a much harder target for criminals.
We've expanded our security to protect you against an even wider range of threats. These updates are now available for Android devices running Android 16+.
More User Control for Failed Authentications: In Android 15, we launched Failed Authentication Lock, a feature that automatically locks the device's screen after excessive failed authentication attempts. This feature is now getting a new dedicated enable/disable toggle in settings, giving you more granular control over your device's security.
Expanding Identity Check to cover more: Early in 2025, we enabled Identity Check for Android 15+, which requires the user to utilize biometrics when performing certain actions outside of trusted places. Later in the year, we extended this safeguard to cover all features and apps that use the Android Biometric Prompt. This means that critical tools that utilize Biometric Prompt, like third-party banking apps and Google Password Manager, now automatically benefit from the additional security of Identity Check.
Stronger Protection Against Screen Lock Guessing: We’re making it much harder for a thief to guess your PIN, pattern, or password by increasing the lockout time after failed attempts. To ensure you aren’t locked out by mistake (by a curious child, for instance), identical incorrect guesses no longer count toward your retry limit.
