Researchers: Louisa Abel, Nico Agnese, Maor Elizen, Lindsay Kaye, João Marques, Vikas Parthasarathy, João Santos, Adam Sell

IVT Taxonomy: Manipulated Behavior

HUMAN’s Satori Threat Intelligence and Research Team has uncovered and disrupted an operation dubbed IconAds. This scheme centered on a collection of 352 apps which load out-of-context ads on a user’s screen and hide the app icons, making it difficult for a user to identify the culprit app and remove it. At its peak, IconAds accounted for 1.2 billion bid requests a day.

IconAds is an expansion and evolution of an operation that Satori researchers have been monitoring and defending against since 2023. That earlier operation has been disclosed by other organizations, but several key tactics—and recent adaptations—in the attack have not previously been described. IconAds-associated traffic appeared worldwide, with the largest percentages of traffic deriving from Brazil, Mexico, and the United States.

Global distribution of IconAds-associated traffic

Google removed all of the apps identified in the report from Google Play. Users are automatically protected by Google Play Protect, which is on by default and can warn users or block apps known to exhibit malicious behavior on Android devices with Google Play Services. Customers partnering with HUMAN for Ad Fraud Defense are protected from the impact of IconAds.

Technical Analysis

Researchers analyzed apps associated with multiple variations of the IconAds threat. During our analysis, we identified commonalities in the apps’ code, network communications, behaviors, and other tactics, techniques, and procedures (TTPs) that allowed us to link together multiple adaptations of IconAds.

Behind The Threat: How IconAds Hides Its Activity and Itself

Researchers identified three commonalities within IconAds apps: 

• Layered obfuscation tactics
• Command-and-control (C2) communication patterns
• A malicious activity-alias

Layered Obfuscation Tactics

Satori researchers observed several types of obfuscation in IconAds applications across Java and native code. IconAds’ primary obfuscation technique uses seemingly random English words to hide certain values—such as model, OS version, and language—during network communications. Additionally, this same obfuscation tactic was used in the URL path and the random words changed from app to app.

Traffic captures from multiple IconAds applications

The threat actors behind IconAds layered obfuscation tactics to increase the challenge of reverse engineering and automated detection of its apps. The Java method names are obfuscated with long names with zeros and O’s, while the strings are encrypted byte arrays which are decrypted by an O-MVLL obfuscated native library. (Later IconAds adaptations encrypted even more of the malicious code.)

Obfuscated representation of hxxps://beye[.]poshoverwatch[.]com

Native library and decryption method

O-MVLL obfuscated library

Command-and-Control (C2) Communications

Researchers observed that each IconAds-associated app had a corresponding, unique C2 domain. The message format of the C2 communications is the same from app to app. For example, C2 network traffic from enden.finder.mange.file.ine was extremely similar to that of com.photofiledetect.comp. 

Researchers observed communications to C2 domains wag[.]hiddenfinders[.]com and airway[.]hiddenfinders[.]com. airway[.]hiddenfinders[.]com serves similar purpose to windmill[.]photofiledetect[.]com of POST requests of JSON data using randomly named keys and what appears to be device data as the values:

This meant that the threat actors were buying and setting up a unique domain for each app they pushed to the Play Store, providing the threat actors with additional obfuscation of their apps and their infrastructure. 

The C2 domains generally shared the following syntax, which is generic enough not to be a viable research angle in and of itself:

General signature for an IconAds C2 domain, which generally includes three subdomains, one of which has the “-test” suffix

These domains consistently resolve to a specific CNAME and return a specific message; this means that while the domains were different, they very likely shared the same back-end infrastructure or second-level C2. These and other unique parameters allowed Satori researchers to find more of these domains and associate them back to IconAds.

Matches using a combination of signatures for IconAds C2 infrastructure

Malicious Activity-Alias

Finally, IconAds’ code declares a malicious MAIN/LAUNCHER activity-alias that replaces the default one by using setComponentEnabledSetting from the PackageManager class. This method allows the developers to disable/enable components (activity, receiver, service, provider) from the application overriding any enabled state which may have been set by the component in its manifest. This means that when the app is installed, the default label name and icon will be displayed, but as soon as the app runs, the activity-alias declared on the manifest will be active and persist even after relaunching the app or rebooting the device.

Usage of ComponentName to enable the activity-alias and to disable the default activity

As seen below, the android:label is an empty string while the icon is a transparent rectangle, resulting in a white space.

Manifest with activity-alias that will replace the default MAIN/LAUNCHER activity

Hidden application

How IconAds Shows Out-of-Context Ads

Using com.works.amazing.colour—the app shared by another organization on X—as an example, researchers captured unusual behavior and out-of-context ads. After installation, the app replaces its icon with a white circle, the app’s name is empty, and when a user clicks on the icon, nothing appears to happen. Within a few moments, interstitial ads loaded regardless of what application is active.

Ads loaded out of context

The new activity-alias (described above) has an android:label and an android:icon that replace the “correct” ones, an android:name that is a fully qualified class name that is used by the ComponentName to be programmatically enabled, and an android:targetActivity that is the class name that contains the code.

Manifest declaration of the activity-alias and corresponding icon

The code of the com.exw.poeja target activity simply has an onTouchEvent with a finish method call to end its execution immediately.

activity-alias targetActivity class

The setComponentEnabledSetting receives the android:name that represents the activity component to be changed and values 1 or 2 represent the android:enabled new state value that replaces the one in the Manifest. For the activity-alias, value 1 will enable the activity while value 2 will disable the initial MAIN/LAUNCHER activity.

Usage of setComponentEnabledSetting to enable the new activity

The encrypted strings are decrypted using a native method located in lib98e3orv.so, an O-MVLL obfuscated native library which required dynamic instrumentalization to obtain the decrypted strings including the C2 beye[.]poshoverwatch[.]com.

During the IconAds investigation, an infected app called com.color.wallpaper.library.hd.beauty was identified with a slight implementation difference. The code responsible for the icon change and the load of ads was stored in an encrypted dex located in assets/wallpaper_list.dat that, when decrypted, resulted in a DEX file called BBA86F92CBFF64B9AA644E57A5B976AE.dat. This DEX file is later dynamically loaded and uses the class com.sharp.vdx.VdxAction as its entry point. 

This application, instead of having a white icon, uses a variation of the Google Play Store’s own icon and name. When opened, it automatically redirects into the official app while working in the background.

IconAds-associated app mimicking the app icon for Google’s Play Store

IconAds Evolution

In October 2023, a new set of applications was identified as associated with IconAds, but only com.photofiledetect.comp and enden.finder.mange.file.ine were published to the Google Play Store at the time.

In these apps, the team noticed adaptations in the way they obfuscate their static code and also in how they attempted to cloak their behavior during dynamic analysis. 

While apps associated with IconAds each employ multiple obfuscation techniques, the most recent wave of malicious apps features greater variation in techniques than in past waves of this threat. 

Researchers observed the following techniques in recent IconAds-associated apps:

• String obfuscation, using StringFog with different approaches for each app
  
  Multibyte XOR of base64 encoded strings
  
  Multibyte XOR of byte encoded strings
• Distinct package name obfuscation techniques, sometimes also using StringFog
  
  Different package name obfuscations
• Some applications had the malicious code present in a malicious ELF library, while others had the malicious code present in Java.
  
  IconAds-associated app loading a ELF library which contains the fraud logic
  
  Screenshot of the fraud logic on an application without ELF library, code is deobfuscated
• Icons are hidden using two main techniques, either by removing the launch activity from the application or, most notably, using Google-related application icons and names
  
  Application using “Google Home” as it launches and a custom Google Home icon as well
  
  Installed IconAds application reporting to be called “Google Home” with a fake icon. See at the bottom the IconAds package name.

From a dynamic analysis perspective, the primary new addition to the IconAds threat is the ability to check if the application was installed from the Play Store. Apps make this check by validating the cryptographic signature of themselves. To achieve this, IconAds uses a 3rd party library PairIP. If an application does not contain a valid Google Play Store signature, it will then exit and not reach out to the C2 server for orders.

Implementation of license check on IconAds apps

In addition to this license check, the actors also added an extra layer of obfuscation during dynamic testing. IconAds-associated applications will use third party services and leverage their platforms’ DeepLinking services to decide whether or not to trigger the malicious flows of the application.

Implementation of the conversion flow by IconAds

Conversion requests

This technique has been observed in other operations in the past. (Note: the Human Defense Platform protects customers against the technique/operation described in the linked Zimperium report.)

Many IconAds-associated apps have short shelf lives before being removed from the Play Store. The chart below shows several IconAds-associated apps and their listing/delisting dates:

Conclusion: HUMAN Protects Customers from Sophisticated Threats

Customers partnering with HUMAN for Ad Fraud Defense are and have been protected from the impact of IconAds. With the several evolutions of this threat, researchers expect continued adaptation, with new apps published and new obfuscation techniques added. Satori researchers will continue to monitor the threat actors for new adaptations and new apps associated with IconAds.

In addition, we recommend the following focused actions for ecosystem participants:

Guidance for DSPs (Demand Side Platforms)

• Inventory Vetting: Apply strict app-level inventory checks. Avoid bidding on impressions from unknown or suspicious apps, especially those with limited public metadata, new or unverified developer accounts, or unusual app store activity.
• C2 Infrastructure Monitoring: Integrate up-to-date threat intelligence, including indicators of compromise (IOCs) such as malicious domains and app package names, to help flag suspicious ad requests in real-time.

Guidance for SSPs (Supply Side Platforms)

• Anomaly Detection: Monitor supply sources for unusual traffic patterns, such as apps generating high bid volumes that do not align with their legitimate user base or app store visibility.
• Transparency in App Metadata: Require full and accurate disclosure of app package names, developer credentials, and version history from publishers, and share this data with buyers to improve trust and decision-making.

Guidance for Publishers

• Collaboration with App Stores: Work closely with app stores to report any suspicious apps or SDKs. Adopting clear app signing and versioning policies can help detect unauthorized or malicious changes more quickly.

The IconAds operation underscores the increasing sophistication of mobile ad fraud schemes. Ongoing collaboration across the digital advertising ecosystem is essential to disrupting these and future fraud operations.

Acknowledgements

The IconAds story builds on the work of several other cybersecurity researchers, including:

• McAfee (first report, second report)
• IAS
• BitDefender
• SecneurX

The work of these researchers has been instrumental in expanding the public’s knowledge of elements of this threat, and the Satori team is grateful to them for their research.

IOCs

IconAds Apps First Disclosed by Satori (CSV, HTML)

IconAds Apps Previously Disclosed by Other Researchers (CSV, HTML)