Android Evasive Malware Stats at a Glance

Triage once again proved invaluable in collecting statistics on malware exhibiting evasive behavior against static analysis. While preparing for my talk at BSides Athens, I wanted to assess current trends in this category—and figured it would be a missed opportunity not to extract additional insights from the dataset. Since it's also been a while since my last blog post, this seemed like the perfect moment to put the data to good use. And so, this post was born.

Lets get started first with some general information:

The following figure shows the top 10 most requested permissions and as expected the "Internet" permission is the most requested one.

What about the top 10 most abused dangerous permissions?

Continuing, one of the most telling indicators of malicious behavior came from broadcast receivers: over 1,800 apps included an identical SmsReceiver class, while 1,200+ others used near-identical obfuscated receiver names like com.nameown12.p060d. These receivers are configured to listen for SMS_RECEIVED and WAP_PUSH_DELIVER broadcasts — a known tactic in spyware and banking trojans. The scale and repetition of these classes across unrelated apps strongly suggest a coordinated malware campaign or shared dropper framework.

Next, this metric highlights frequently reused classes across all analyzed APKs that do not belong to Android's core framework. These are typically Activities, Services, or Broadcast Receivers from third-party SDKs (like ad networks, location providers, payment gateways) or injected by developers and their high reuse can indicate:

• Bundled SDKs like Alipay, Unity Ads, or JPush, found in thousands of unrelated apps.
• Repackaging or trojanization, where common components are cloned across fake or malicious apps.
• Shared malware toolkits or APK generation kits reusing the same class names.
  

By identifying which classes appear most often, we get a clearer picture of what SDKs, behaviors, or obfuscation patterns are being reused at scale. This is particularly useful for attributing malware families and detecting mass-produced droppers.

Next an analysis on the Java package namespaces (like com.tencent, com.applovin, com.nameown12) used in the apps was done. These prefixes indicate the logical ownership or branding of the codebase and are a powerful tool for spotting:

• Legitimate popular apps or SDKs (com.spotify, com.whatsapp, com.bytedance)
• Suspicious or synthetic namespaces (com.nameown12, com.example) often used by malware to appear generic or avoid detection
• High-volume fake apps, clone networks, or grayware distributions using the same namespace across thousands of variants
  

This analysis gives insight into which developer identities dominate the app set — and can highlight coordinated campaigns or shared malware families through their naming patterns.

Another interesting thing to see is evasion heuristics being used:

Another interesting statistic to see is the distribution of the static analysis scores assigned by Triage:

Complementary to that lets also see the signatures for all APKs with score higher than 5:

Do note the Attempts to obfuscate APK file format that indicates some kind of tampering either in the ZIP structure on the AXML part.

Finally the plots below should offer a useful starting point for exploring the relationship between an APK’s size and its internal complexity. By mapping size against the number of declared permissions, services, receivers, and its static analysis score, we can begin to distinguish between legitimate complexity (e.g. feature-rich or SDK-heavy apps) and suspicious bloat (e.g. obfuscation layers, embedded payloads). However, interpreting these patterns in isolation can be misleading. To make meaningful inferences, such as identifying outliers that are likely malicious, we would need to compare this data against a well-defined set of benign, known-good applications (e.g. from playstore). This would help determine whether certain correlations (like high service count in large apps or dense permission use in small ones) are genuinely abnormal, or simply reflective of normal app diversity.

I hope these statistics sparked some interest! Please feel free to reach out to me if you have any ideas or questions. Enjoy!