Hundreds of Malicious Google Play-Hosted Apps Bypassed Android 13 Security With Ease

Bitdefender's security researchers have identified a large-scale ad fraud campaign that deployed hundreds of malicious apps in the Google Play Store, resulting in more than 60 million downloads total. The apps display out-of-context ads and even try to persuade victims to give away credentials and credit card information in phishing attacks.

The Google Play Store is often targeted by cybercriminals trying to upload malicious apps by bypassing existing protections. Google purges the store of such apps, either on its own volition or after being notified by researchers but criminals adapt.

This is one of the main reasons why it's not enough for users to rely solely on the protection available by default on Android devices and the Google Play Store and why Bitdefender has dedicated technologies to address this issue..

The technology embedded in Bitdefender Mobile Security, App Anomaly Detection, observes the apps’ behavior after installation, which is critical in today’s threat landscape. In some cases, bad actors alter the functionality of previously benign apps that had already been cleared for the Google Play Store, turning them into dangerous software.

Security researchers from IAS Threat Lab uncovered a part of this campaign, exceeding 180 apps. However, the campaign is much larger, as Bitdefender's security researchers learned, and the dangers extend past what we usually observe. Criminals have used their access to devices to direct users towards phishing websites, not just to show them annoying full-screen ads.

Key findings

The campaign features at least 331 apps that were available via the Google Play Store (15 were still online when the research was completed), gathering more than 60 million downloads.
Attackers figured out a way to hide the apps’ icons from the launcher, which is restricted on newer Android iterations.
The apps have some functionality in most cases, but they can show out-of-context ads over other applications in the foreground, bypassing restrictions without using specific permissions that allow this behavior.
Some apps have tried to collect user credentials for online services, and even credit card data, via phishing attacks.
The apps can start without user interaction, even though this should not be technically possible in Android 13.
The campaign seems to either be the work of one actor, or multiple criminals using the same packaging tool sold on black markets.

Insights and overview

The investigated applications bypass Android security restrictions to start activities even if they are not running in the foreground and, without required permissions to do so, spam the users with continuous, fullscreen ads. The same behavior is used to serve UI elements featuring phishing attempts.

Application mimicking simple utility apps like:

QR scanners
Expense tracking apps
Health apps
Wallpaper apps
Many others...

Distribution by countries

Most applications first became active on Google Play in Q3 2024. After further analysis, we saw that older ones that had been published earlier were initially benign and did not contain malware components. The malicious behavior was added afterward, starting with versions from the beginning of Q3.

To be clear, this is an active campaign. The latest malware published in the Google Play Store went live in the first week of March, 2025. When we finished the investigation, a week later, 15 applications were still available for download on Google Play.

Here are a couple from the latest batch uploaded to the store. Both of them were uploaded on March 4.

Technical Overview

Running without user interaction:

The application declares a contact content provider that is automatically queried by the system after the installation has been completed and the application entry point is loaded.

In some of the more recent samples, we noticed an evolution in criminals' methods to evade detection techniques by adding that type of content provider referenced as a string in resources. In previous iterations, it was directly referenced in the app's manifest.

This is likely one reason why our analysis has revealed so many more apps involved in this massive fraudulent campaign. Attackers often find ways to adapt when their methods are discovered, and apps are removed from the store.

Icon hiding techniques:

One way to keep a malicious app hidden from the user is to hide the icon – a behavior that is no longer allowed in the Android OS.

We notice that attackers used multiple approaches to solve this problem. The most popular and interesting one is also likely the most efficient. The app comes with the Launcher Activity (e.g., that the user sees and clicks on) disabled by default.

Afterwards, by abusing the startup mechanism provided by the content provider, the samples use native code to enable the launcher, which is likely carried out as an additional technique to evade detection.

After the "setup procedure" is complete, the app disables its launchers and the icon disappears entirely from the phone launcher. This behavior is not permitted in recent Android versions, which means that the malware's developers likely found a bug or are abusing the API. This also happens in native code.

Another mechanism we've seen in other samples aims to further enhance detection-evasion techniques by using Android LEANBACK_LAUNCHER, a type of launcher specifically designed for Android TV that isn't available on regular Android phones.

Here, the application uses an alias activity of the category LAUNCHER, pointing to the first activity that is defined as a LEANBACK_LAUNCHER. If the alias is disabled by default and the LEANBACK_LAUNCHER is not shown, the application can choose when to enable or disable the LAUNCHER alias.

Also, we can infer this type of icon-hiding behavior from some leftover metadata in the code of some of the applications.

The conclusion is worrisome. The attackers can dynamically disable or enable the icon and the launcher whenever they consider it necessary.

We also noticed that some apps try to hide even in Settings to avoid user removal. In the example below and the video, the app even changes its name to Google Voice to look like an official one.

Starting Activities when not in the foreground and ads mechanism:

At first glance, we noticed that the applications started to show ads without even being started, even if another application was running in the foreground.

We first checked the manifest for the SYSTEM_ALERT_WINDOW permission that allows that behavior, but it was missing.

Secondly, we identified the activity used to show ads in the Java code, but it was not called from anywhere in the Java code. Moreover, the activity registers an empty callback for the Back button and will not allow the user to exit the ad.

It is also interesting that the app uses some options in AndroidManifest.xml that allow it to disappear from recent tasks and hide itself from the user.

These types of activities seem consistent across all the samples from this threat but have different, possible automatically generated, names.

Let's go back to the native library. We see that the mechanism of starting the activity mentioned above is located there, and it successfully starts the activity without the required permissions by abusing the following API calls:

Using DisplayManager.createVirtualDisplay to create a virtual display with a random name and the following flags:

DisplayManager.VIRTUAL_DISPLAY_FLAG_PUBLIC | DisplayManager.VIRTUAL_DISPLAY_FLAG_PRESENTATION | DisplayManager.VIRTUAL_DISPLAY_FLAG_OWN_CONTENT_ONLY

Creating a DisplayManager.DisplayListener with a callback on the function onDisplayAdded, searching for the new display created.
When the new display is found, the application use the presentation API to create a presentation on the display: Android.app.Presentation(context, new_display) and the function show() of the presentation is called.

After a delay, startActivity is used with the flag Intent.FLAG_ACTIVITY_NEW_TASK, to start the required activity.

Our insights revealed this type of behavior in several apps, clearly showing the technical capability of deploying phishing attacks via fullscreen activities. Users could be asked to enter credentials from Facebook, YouTube or other online services, or credit card information under various pretexts.

The following video is a recreation of the apps’ behavior and capabilities as spotted from our insights, and not from any particular sample.

It's also common for attackers to scare users with threats of infected devices in an effort to persuade them to install third-party apps that could prove to be dangerous malware, such as banking Trojans.

Persistence mechanisms:

Besides the content provider mechanism, which is queried often by the system, most of the applications investigated use the app's entry point to start a foreground service that shows an empty entry in the notification bar.

This behavior was only allowed until Android API level 31. On newer Android, when the foreground service is blocked, the applications start the foreground service from native code after the first activity with ads. The app is then considered to be in the foreground and it is allowed to start a service.

Another persistence mechanism leverages different dummy broadcast receivers or services.

C2 Communication:

Most of the applications use custom, dedicated c2 domains and offer links specific to each package (details can be seen in Annex/IOCs).

We also observed different ways of encrypted communication, using combinations of AES, Base64 and custom encryption.

The malware exfiltrates device information using a dictionary-based structure, but the keys in this dictionary are polymorphed and unique to each application. This means the labels used to send data constantly change, making detection and analysis more difficult.

From the server side, even after decryption, the response is intentionally not user-friendly for further block analysis. This jibber-jabber response is used to configure the ads SDKs:

Obfuscation and anti-analysis mechanisms:

Most of the applications analyzed use similar string obfuscation techniques based on XOR but with different inputs like Base64 encoded string, plain strings or even hardcoded byte arrays.

We also identified that the mechanism responsible for starting the activities when not in the foreground is in native libraries with randomly generated names.

The native libraries seem to be obfuscated with Armariris tool.

Also, upon further analysis, we discovered that the library contains runtime checks that allow it to determine if it runs in an emulated environment or debugger is connected to evade detection.