The mobile section of the quarterly cyberthreat report includes statistics on malware, adware, and potentially unwanted software for Android, as well as descriptions of the most notable threats for Android and iOS discovered during the reporting period. These statistics are based on detection alerts from Kaspersky products, collected from users who consented to provide statistical data to Kaspersky Security Network.
The quarter in figures
According to Kaspersky Security Network, in Q2 2026:
More than 1.99 million attacks on mobile devices utilizing malware, adware, or unwanted mobile software were blocked.
The Trojan-Banker category was the most prevalent mobile malware threat with a 30.77% share of total detected applications.
More than 304,000 malicious installation packages were discovered, including:
93,574 packages were related to mobile banking Trojans;
570 packages were related to mobile ransomware Trojans.
Quarterly highlights
Attacks on mobile devices involving malware, adware, or unwanted software continued their downward trend, falling to 1,996,823 in Q2 from 2,676,328 the previous quarter.
Attacks on users of Kaspersky mobile solutions, Q4 2024 — Q2 2026 (download)
We noted a downward trend in attacks driven by specific strains of pre-installed Trojans — a shift likely tied to the rollout of patched vendor firmware.
In Q2, our telemetry uncovered multiple malicious loaders hosted directly on Google Play. As highlighted in a prior report (link in Russian), one such instance involved a PDF reader app trojanized to drop the Anatsa banking malware. Upon execution, the app presented users with a fake request to install an update, which served as a front to stage the banking Trojan on the victim’s device.
Another notable case involves a loader we detected in the Cleanova app alongside several others. The malware sent requests to a command-and-control server containing telemetry gathered from various SDKs that track the installation source. A malicious payload was returned only for certain sources. This is a fairly interesting method for bypassing app store review processes while ensuring precise victim targeting. If an analytics SDK indicates that an arbitrary installation originated from a source outside the threat actors’ scope, the malicious logic remains dormant. This effectively hides the malware from app store scanners.
Mobile threat statistics
In Q2, the number of Android malware samples totaled 304,128. It remained steady compared to the previous reporting period.
The detected installation packages were distributed by type as follows:
Detected mobile apps by type, Q1 — Q2 2026* (download)
* Data for the previous quarter may differ slightly from previously published data due to certain verdicts being retrospectively revised.
While the number of newly discovered banking Trojan variants fell precipitously, they continued to dominate the threat landscape as they did in Q1. Notably, the share of Creduz malware family among identified banking samples has grown significantly despite low activity in victim telemetry. This discrepancy suggests the threat actors are actively iterating on the malware — likely testing new features or bypasses — by generating a high volume of builds before staging a broader campaign.
Share* of users attacked by the given type of malicious or potentially unwanted apps out of all targeted users of Kaspersky mobile products, Q1 — Q2 2026 (download)
* The total may exceed 100% if the same users experienced multiple attack types.
Within the adware category, the sharpest declines were observed in the HiddenAd and MobiDash families. Meanwhile, the proportion of users targeted by Trojan-Dropper malware increased, primarily driven by surges in banking droppers such as Trojan-Dropper.AndroidOS.Banker and Trojan-Dropper.AndroidOS.Mamont. The corresponding drop in the Trojan-Banker category is partially explained by a shift in tactics: several banking Trojans which are now being packed were subsequently reclassified as droppers.
TOP 20 most frequently detected types of mobile malware
Note that the malware rankings below exclude riskware or potentially unwanted software, such as RiskTool or adware.
Verdict
%* Q1 2026
%* Q2 2026
Difference in p.p.
Change in ranking
Backdoor.AndroidOS.Triada.ag
7.09
9.35
+2.25
0
DangerousObject.Multi.Generic.
5.84
5.65
-0.19
0
DangerousObject.AndroidOS.GenericML.
5.51
5.25
-0.26
0
Trojan.AndroidOS.Boogr.gsh
2.15
3.33
+1.18
+9
Backdoor.AndroidOS.Triada.z
3.08
3.23
+0.15
+3
Trojan-Banker.AndroidOS.Mamont.hl
1.10
2.48
+1.38
+22
Trojan.AndroidOS.Fakemoney.v
3.44
2.31
-1.13
-2
Trojan-Spy.AndroidOS.Btmob.e
0.00
2.27
+2.27
Trojan.AndroidOS.Triada.fe
2.98
2.18
-0.81
0
Trojan-Dropper.AndroidOS.Banker.dd
0.01
2.16
+2.15
Trojan.AndroidOS.Triada.hf
2.23
1.93
-0.29
+1
Backdoor.AndroidOS.Triada.ad
1.40
1.93
+0.53
+8
Backdoor.AndroidOS.Keenadu.a
2.73
1.88
-0.85
-3
Backdoor.AndroidOS.Triada.ab
1.72
1.79
+0.07
+2
Trojan-Banker.AndroidOS.Mamont.iv
1.03
1.63
+0.60
+16
Trojan.AndroidOS.Generic.
1.32
1.47
+0.15
+7
Backdoor.AndroidOS.Triada.ae
1.76
1.44
-0.31
-2
Trojan.AndroidOS.Fakemoney.ej
0.00
1.43
+1.43
Trojan.AndroidOS.Triada.ii
2.07
1.41
-0.66
-5
Trojan-Spy.AndroidOS.Agent.asa
0.02
1.38
+1.36
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.
The distribution of top malware families in Q2 largely mirrors the rankings from the previous reporting period. Newer variants of the Mamont banking Trojan climbed the leaderboards, displacing older iterations. This shift points to ongoing, active development of new variants by the threat actors behind the malware.
Mobile banking Trojans
In Q2, the total volume of Trojan-Banker applications dropped sharply compared to the previous quarter, totaling 93,574 installation packages.
Number of installation packages for mobile banking Trojans detected by Kaspersky, Q2 2025 — Q2 2026 (download)
Against the backdrop of this trend, the distribution shifted heavily toward Creduz Trojans. However, as noted earlier, this shift was not reflected in real-world attack metrics: virtually the entire leaderboard by proportion of targeted users continues to be dominated by diverse Mamont variants.
TOP 10 mobile bankers
Verdict
%* Q1 2026
%* Q2 2026
Difference in p.p.
Change in ranking
Trojan-Banker.AndroidOS.Mamont.hl
3.27
11.13
+7.86
+6
Trojan-Banker.AndroidOS.Mamont.iv
3.08
7.33
+4.25
+6
Trojan-Banker.AndroidOS.Mamont.mv
0.00
5.12
+5.12
Trojan-Banker.AndroidOS.Agent.ws
3.78
4.99
+1.22
+2
Trojan-Banker.AndroidOS.Mamont.mg
0.35
4.71
+4.36
+62
Trojan-Banker.AndroidOS.Faketoken.pac
2.56
4.10
+1.54
+6
Trojan-Banker.AndroidOS.Mamont.jo
15.75
3.73
-12.02
-6
Trojan-Banker.AndroidOS.Mamont.mc
0.83
3.51
+2.67
+26
Trojan-Banker.AndroidOS.Mamont.lf
0.00
2.79
+2.79
Trojan-Banker.AndroidOS.Agent.eq
0.89
2.58
+1.69
+23
* Unique users who encountered this malware as a percentage of all users of Kaspersky mobile security solutions who encountered banking threats.
Containerization using Docker has become firmly established in modern development standards, significantly increasing the speed and convenience of deploying various services. Developers often use ready-made Docker images, making only minimal changes. The largest repository of container images is the Docker Hub service.
Container-hosted infrastructure is an attractive target for attackers. At a minimum, a compromised container can be used for DDoS attacks, cryptocurrency mining, or traffic proxying. The list of threats does not end there: once an attacker gains control of a container, they can steal or destroy data directly from it, access neighboring containers, or even attempt to escape the container, compromising the entire enterprise network.
At the same time, the infrastructure inside containers is typically updated less frequently and may contain outdated and vulnerable software versions. When deploying third-party images or modifying them for a specific environment, it is easy to make configuration errors that attackers can later exploit. And due to the architectural characteristics of containers, developers often face constraints when preparing images; to overcome these, they may resort to insecure solutions they find online.
In other words, containerized infrastructure can be both the simplest and the most lucrative target to exploit. Therefore, its security requires heightened attention. To minimize the risk of successful attacks on container infrastructure, it is essential to check the final Docker images, including all underlying layers, for vulnerabilities and misconfigurations. The easiest way to do this is by analyzing the Dockerfile; however, it is not always available for inspection. Moreover, it typically defines how to build layers on top of a base image from an external repository whose reliability cannot be guaranteed.
Image analysis results in Kaspersky Container Security
To help users identify insecure configurations and potential vulnerabilities within them, we have added our AI assistant to Kaspersky Container Security.KIRA (the assistant’s name) uses artificial intelligence to analyze the image and identify potential issues within, along with recommendations on how to fix them.
As part of this study, we asked KIRA to analyze a number of popular community images, and later in this article, we’ll show you the results.
Software vulnerabilities and compromise of update sources
One of the key security issues with using pre-built images is that developers do not update them in a timely manner. A Docker image is, by its very nature, a snapshot of a specific Linux distribution after packages have been installed on it. However, in most cases, it does not receive security updates on its own, unlike traditional Linux servers, where these updates are automatically installed by specialized services, such as unattended-upgrades in Debian-based distributions and dnf-automatic in RedHat-based distributions.
To apply updates to a Docker image, it must be rebuilt and redeployed. Often, this process is not automated, and some updates require additional effort to verify their correct operation, modify configurations when upgrading to new software versions, and so on. As a result, many popular images do not receive timely updates, which significantly increases the risks associated with their use.
An image that was secure at build time accumulates vulnerabilities as they are discovered in the packages installed within it, which over time significantly increases the opportunities for a successful attack on the container.
Vulnerable versions of web applications and network services accessible from the internet immediately become targets of various malicious campaigns. For example, just one day after the discovery of the CVE-2025-55182 vulnerability in React Server Components, our honeypots recorded numerous attack attempts related to this vulnerability. It was adopted by operators of many malicious campaigns, ranging from classic cryptocurrency miners to variants of Mirai and Gafgyt. Attackers are constantly adding new distribution methods and can use dozens of exploits targeting various vulnerabilities and configuration errors in popular services. Often, the same vulnerabilities are used in self-propagation mechanisms from already compromised hosts. For example, in a malicious campaign to spread the Dero miner, attackers use infected containers to automatically search for and infect new targets.
In addition to vulnerabilities that can be exploited remotely, attackers are rapidly adding local vulnerabilities to their arsenal, used to gain root privileges and escape the container: in the Kinsing malware campaign, attackers used CVE-2023-4911 (Looney Tunables) to elevate privileges, and in the perfctl campaign, the CVE-2021-4034 (PwnKit) vulnerability was used for the same purpose. The access gained was used to install a rootkit that hides the presence of perfctl on the system.
To assess the situation with unpatched vulnerabilities in containers, we took a random sample of 100 images, which included various popular solutions with 10,000 to 1 million downloads on DockerHub. In the 64 images we scanned, we found outdated software versions with critical vulnerabilities. For example, some images contained the CVE-2025-49844 vulnerability in the Redis server, leading to RCE by leveraging a vulnerability in the Lua parser; the current CVE-2026-24061 vulnerability in nginx, which in some configurations leads to a server process crash, and with ASLR disabled, again, to RCE; vulnerabilities CVE-2025-32463 in sudo and CVE-2023-4911 in glibc, allowing an attacker to gain root privileges with local access. At the same time, only one in ten Docker images from the analyzed sample is fully up to date.
TOP 10 Critical Vulnerabilities with PoC/Exploits available as shown in the Kaspersky Container Security Dashboard
It is worth noting that, of course, not every discovered vulnerability can be directly exploited by attackers. A practical risk arises when the vulnerable application or library is actually in use, and the conditions necessary for exploitation – which vary significantly from vulnerability to vulnerability – are met. Nevertheless, updates must not be ignored, as the risk of vulnerabilities being exploited – both individually and in various combinations – cannot be predicted in each specific case, and even vulnerabilities that seem harmless at first glance can ultimately pose a serious risk of compromise.
A record number of vulnerabilities in a single image
However, frequent updates have a downside. Every rebuild that downloads new packages from source repositories introduces an additional risk of a supply chain attack – a compromised dependency or a modified base image could silently inject malicious code into your environment precisely through an update. During our analysis of images from the sample, we did not find any signs of supply chain attacks. However, in March 2026, a supply chain incident occurred in the Trivy and LiteLLM projects. In the case of Trivy, the infected file was injected directly into the container image in the official repositories.
Detecting potentially malicious software using one of the images as an example
This leads to a difficult choice: infrequent updates leave known vulnerabilities unpatched within the image, while frequent updates increase the risk of supply chain compromise. Therefore, to protect your infrastructure, you need not only to regularly update base images but also to take a more comprehensive approach, specifically by pinning dependencies to known-good versions and scanning the resulting images for malware upon update.
Configuration vulnerabilities
Even a container with a fully updated image can be compromised if it is configured incorrectly. Embedding keys and secrets in the image, disabling authentication in network services, default passwords, and insecure file access permissions – all of these can be exploited by attackers in one way or another to achieve their goals.
Insecure image configurations detected by KCS based on rules
The situation is exacerbated by the fact that errors may be introduced by the authors of the original image, which complicates their detection, as this requires analyzing every layer and the command that generated it. As with vulnerabilities, not every configuration error leads to compromise: it all depends on the container’s role, its network accessibility, and many other factors. But the very use of insecure settings will sooner or later lead to errors appearing in images where their consequences will be significantly more dangerous.
Standard rules are often insufficient for analyzing problematic configurations. To gain a deeper understanding of the context and assess potential risks, AI tools can be used. Later in this section, we will examine examples of typical insecure configurations we discovered while scanning public images from Docker Hub, along with the descriptions of issues and risk mitigation methods provided by the KIRA AI assistant.
Example of container analysis using KIRA
Insecure handling of credentials
Use of default passwords
In some cases, containers may use default passwords set via environment variables or directly in Dockerfile. If these passwords are not overridden, attackers will be able to access the application by using the default password.
RUN |1 DEBIAN_FRONTEND=noninteractive /bin/sh -c echo [removed]:[removed] | chpasswd
According to KIRA’s analysis, the user’s password is stored in plain text in the image layer history. Anyone who gains access to the image – whether through a public registry, a compromised build environment, or other means – will be able to extract the password. If SSH or another form of interactive access is enabled in the container, this could lead to its complete compromise and allow attackers to move laterally within the infrastructure.
Passwords may be present in environment variables. Consider the following Dockerfile snippet:
In this example, the environment variable PKP_DB_PASSWORD is set to changeMePlease. If the user forgets to override it, the application will use the password that can be obtained from Dockerfile.
For this image, Dockerfile specifies that the administrator password is hardcoded in the ENV directive and remains in the image metadata (layer history, docker inspect). Anyone who gains access to the image (registry, build cache) will be able to extract this secret and compromise the account.
To eliminate these risks, ensure that no passwords are specified in Dockerfile. If authentication is required, you can use orchestrator mechanisms (secrets) or generate a temporary password when starting the container via the entrypoint script, without saving it in the layers. We also recommend using mechanisms for securely passing secrets at runtime (Docker secrets, Kubernetes Secrets) or, as a last resort, passing them via --secret during the build with BuildKit, but under no circumstances should they be left in the final image.
Passing passwords via command arguments
In some cases, passwords may be exposed when passed via command-line arguments, as these arguments are visible to all users on the system:
In the example provided, the MySQL superuser password is passed into the healthcheck command in plaintext, making it visible when viewing the process list (ps aux), in audit logs, and in monitoring systems. If the attacker gains read access to the container’s processes or logs, they can extract the password and gain full control of the database.
To fix this issue, the healthcheck should use a local connection via a Unix socket with default authentication (if the auth_socket plugin is configured for root), or create a dedicated user with minimal privileges (e.g., only USAGE), without a password or with a password passed via a secure file (--defaults-file with restricted permissions). You can also use the MYSQL_PWD environment variable for healthcheck authentication, but it remains visible in /proc.
Privilege escalation in the container
One of the most common vectors for initial compromise of Linux systems is RCE in web applications and network services. Typically, these services have minimal privileges, which complicates attackers’ subsequent actions: dumping credentials, covering their tracks, attempting to escape the container, and much more.
The situation worsens significantly if the attacker gains root privileges, as this allows them to fully control all processes within the container, conceal their activity, and use methods to escape the container. For example, they can compromise the host if the container is privileged, a Docker socket is mounted inside it, or other insecure configurations and vulnerabilities exist that cannot be exploited with standard user privileges.
Similarly, this simplifies network attacks on neighboring containers, the orchestrator, and various internal services, making this configuration error a potential link in the chain for compromising the entire network.
Attacks on sudo
One of the simplest privilege escalation methods is executing arbitrary commands as root using sudo without entering a password. Consider the following example:
Analyzing this configuration using KIRA immediately highlights the main issue: by installing the sudo package and setting NOPASSWD: ALL for the solr, the user severely violates the principle of least privilege. The Solr platform does not require such broad privileges to run within a container; instead, they create an easy path for escalating to root.
In another example of an insecure configuration, NOPASSWD:ALL privileges are granted to a PostgreSQL database user, which is a direct and severe weakening of the access control policy. If an attacker gains the ability to execute code on behalf of the postgres user – through a vulnerability in a network service, an SQL injection, or by compromising of one of the processes – they will immediately and unconditionally be able to execute any commands on behalf of the root user. This is equivalent to the entire container running as root.
As a risk mitigation measure, we recommend completely removing this directive. The minimum necessary commands requiring privileges should be delegated on a case-by-case basis via sudoers with explicit specification of allowed executables and parameters, using NOPASSWD only as a last resort and for specific utilities.
Our AI assistant KIRA can identify even more complex insecure configurations, such as allowing passwordless sudo for the entire sudo group — by modifying existing rules.
The risk in this example is that the command replaces standard declarations requiring authentication with passwordless execution of all commands for any user within the sudo group – potentially including postgres, should it be assigned to that group. This expands the attack surface to all group members, turning each of them into a potential point for instant privilege escalation.
To mitigate the risks, we recommend not modifying the global sudoers policy, keeping the standard password requirement, or using a more secure escalation mechanism – such as gosu to run a specific process on behalf of another user without permanent privileges.
Insecure file permissions
Another common vector for privilege escalation is insecurely configured file and directory permissions. Most often, for convenience, container image authors use 777 permissions, which allow anyone – including unprivileged users – to freely create and delete files, as well as modify their contents. This can lead to both privilege escalation and the ability for an unprivileged attacker to delete or modify logs, among other undesirable consequences.
Consider the following command:
chmod 0777 /usr/share/cargo /usr/share/cargo/bin
The risk is that directories containing binary files and scripts will become writable by any container user. This allows a low-privileged attacker to replace utilities included in cargo or add new malicious executables. When these tools are subsequently invoked, especially as the root user or via sudo, the attacker’s code will execute with the inherited privileges of the calling process, leading directly to a local privilege escalation.
To mitigate the risks, you can set the minimum necessary permissions: chmod 0755 for directories and chmod 0755/0644 for the corresponding files. The owner should be root, and only the owner should be allowed to write. Do not use chmod 777 on any system paths.
Lack of integrity checks
Downloading software without verifying its integrity can make the infrastructure vulnerable to software tampering.
For example, this risk may arise when downloading a distribution via HTTP:
RUN /bin/sh -c wget -qO- ""<a href="http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz">http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz</a>"" | tar --extract --gzip -C /opt/acestream
Using HTTP without verifying the archive’s integrity creates conditions for a man-in-the-middle attack during the image build phase. An attacker controlling the communication channel or DNS can replace the archive with malicious content, which will compromise the container and the entire environment in which it runs.
To mitigate the risks, you can configure connections to web resources to use HTTPS only — if the resource supports this protocol. You can also download the archive without extracting it, compare its checksum (SHA256) with the checksum from a trusted source, and only then extract it. It is advisable to store the verified archive in an internal artifact repository to avoid direct downloads from the network.
There will still be a MitM risk even if certificate verification is disabled:
The absence of TLS certificate verification allows an attacker controlling the network segment to replace the downloaded ZIP archive with malicious content. Since the archive contains PHP code that will be executed by the web server, compromise during the build phase will result in the deployment of a backdoor or data leakage.
To mitigate the risks, remove the --no-check-certificate flag; after downloading, calculate the SHA256 hash of the archive and verify it against a known reference value (the release page or a local repository of trusted hashes). Additionally, consider using a fixed release (tag) rather than the floating 7.2-dev branch.
Conclusion
Docker containers have become a very popular means of deploying software, and attackers are by no means oblivious to this trend. They are rapidly adding software vulnerabilities and configuration errors to their arsenal and carrying out attacks on supply chains. They can compromise container infrastructure for a wide variety of purposes, from cryptocurrency mining to encrypting data for ransom or stealing information critical to the company.
Our research found that 64 out of 100 container images for popular applications contain critically vulnerable software, and only 10% are fully up to date. We also identified numerous insecure configurations, including passwords stored in plaintext in Dockerfiles and excessive privileges granted to users and processes.
To detect and prevent these threats, it is essential to strictly adhere to security measures: audit image configurations, securely manage secrets used in images, apply security updates in a timely manner, scan their contents for malware with every update, and follow industry-standard best practices for enhancing security.
This approach requires specialized solutions built to accommodate the unique characteristics of container environments. Kaspersky Container Security ensures the security of containerized applications at every stage of their lifecycle, from development to operation. The product protects an organization’s business processes, helps ensure compliance with industry standards and security regulations, and enables the implementation of secure software development practices.
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.
The quarter in numbers
According to Kaspersky Security Network, in Q1 2026:
More than 2.67 million attacks utilizing malware, adware, or unwanted mobile software were prevented.
The Trojan-Banker category was the prevalent mobile malware threat with a 52.96% share of total detected applications.
More than 306,000 malicious installation packages were discovered, including:
162,275 packages related to mobile banking Trojans;
439 packages related to mobile ransomware Trojans.
Quarterly highlights
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).
Mobile threat statistics
The number of Android malware samples saw a slight increase compared to Q4 2025, reaching a total of 306,070.
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%).
TOP 20 most frequently detected types of mobile malware
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.
Mobile banking Trojans
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.
TOP 10 mobile bankers
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.
Entrar
