Researchers:  João Santos, Vikas Parthasarathy, Marion Habiby, Gabi Cirlig, Lindsay Kaye, Joao Marques, Adam Sell, Inna Vasilyeva, Maor Elizen

IVT Taxonomy: Automated Browsing, False Representation, Misleading User Interface

HUMAN’s Satori Threat Intelligence Team recently uncovered a massive ad fraud operation we’ve named Konfety, loosely referencing CaramelAds, the mobile advertising SDK that was abused. (“Konfety” is the Russian word for “candy”.) Konfety represents a new form of fraud and obfuscation, in which threat actors operate “evil twin” versions of “decoy twin” apps available on major marketplaces. 

The “decoy twin” is distributed on the Google Play Store, and Satori researchers have observed no fraud upon executing the decoy twin apps. The evil twin, in contrast, is disseminated through a malvertising campaign and conducts several types of fraud, including ad fraud, installing browser extensions, monitoring web searches, and sideloading code onto devices.

According to Google, Google Play Protect warns users and disables apps identified to be "Evil Twin" apps. Google has been actively monitoring the variations and protecting users over the course of its existence.

Once downloaded from a third party source and installed, the evil twin pretends to be the decoy twin by spoofing the app ID and advertising publisher IDs for the purposes of requesting and rendering ads.

This "decoy/evil twin" mechanism for obfuscation is a novel way for threat actors to represent fraudulent traffic as legitimate. Satori researchers identified more than 250 apps on Google’s Play Store with the abused advertising SDK implemented, and each of the apps has a corresponding evil twin. At its peak, Konfety-related programmatic volume reached 10 billion requests per day.

Customers partnering with HUMAN for ad fraud defense are protected from the impacts of Konfety.

Executive Summary

The "evil twin" method that the Konfety operation employs is predicated on abuse of an advertising software development kit (SDK) named CaramelAds. This SDK is not inherently malicious, but was exploited by threat actors to request and render ads, sideload additional Android Package Files (APKs), and communicate with command-and-control (C2) servers.

Satori researchers identified more than 250 apps on Google’s Play Store that were associated with Konfety. These apps are not themselves committing any of the fraud described below, but each has a corresponding evil twin—disseminated and distributed outside official app marketplaces—that conducts the fraud. These evil twins contain a modified version of the CaramelAds SDK enabling the malicious activity, and share infrastructure with the decoy twin apps.

The CaramelAds SDK servers for both the decoy and evil twin sets of apps operate on the same infrastructure, which the threat actor can easily start up and scale as needed to support the "evil twin" applications.

Diagram showing how Konfety apps are distributed and operate

Although the decoy apps on the Play Store purport to be owned by different developers, they are template-based apps, many of which are owned by the Konfety threat actor group. However, these apps are only affiliated with three ad publishers.

In addition, HUMAN observed that the actors are also re-selling inventory for applications that they do not directly own. 

CaramelAds

CaramelAds is a Russia-based ad network which describes itself as partnering with "large publishers" and "developers of premium advertising". It was established around 2018, and in addition to its core SDK, also provides a mediation SDK—a platform enabling integration of several ad networks—covering multiple Android frameworks.

Satori researchers first examined the CaramelAds SDK as part of the BADBOX/ PEACHPIT investigation in 2023; the SDK was observed in some of the apps flagged as part of the campaign and had a suspicious SSP server name. At the time, the primary domain used by this network was inactive. There were suspicious signals but, since we could not confirm fraudulent behavior, researchers opted instead to monitor CaramelAds closely. 

Around September 2023, researchers began seeing fraud connected with these apps. This coincided with one of the CaramelAds SDK domains becoming active.

The CaramelAds SDK code is available on GitHub, and Satori’s analysis showed the SDK provides mediation for several ad networks. It offers very basic functionality to render banner ads and interstitials, as well as a straightforward analytics interface to measure ad performance.

The SDK can, however, be abused by developers in several fashions based on the way it processes certain data values returned in the server response or through a malicious creative or implementation:

• The SDK allows the server to control the UserAgent string the device uses, meaning that it can modify it to appear as though the traffic is originating from any type of device it chooses
• After the device makes a request to the server, the server can send a reply that will open any URL using the device browser causing it to navigate to what could be a malicious location
• If specific conditions on the device are met, the SDK will request a hardcoded malicious URL
• The SDK does not perform any validation that the device is real, that ads are rendered correctly, or other checks common in well-established networks
• The SSP servers used by the SDK, ssp.swe[.]xyz or ssp.thild[.]info, were suspicious - some antivirus vendors identified the servers as potentially malicious, and despite being identified in numerous apps on the Play Store, the servers were offline for many months.

Intent extras sent to the custom webclient class obtained by the server

The API definition for the SDK has a server—api.advancedspot[.]com—that is used for metrics and some additional configuration parameters from the ad network. The server has six endpoints as seen below, with the following functionalities:

• check: obtain status of the application and publisher to determine whether the server is active
• event: report ad-related events but also errors and other analytics from the SDK
• config: used by the SDK to obtain the ad configuration, particularly for mediated ad content
• click: reports click events back to the server
• select: select which ad unit, per CaramelAds network internal IDs, to render on any active ad slot
• shown: notify the server of a successful impression

CaramelAds SDK ApiService class

Ultimately, the Satori team linked abuse of the CaramelAds SDK to an ad fraud operation—dubbed Konfety—which took advantage of the SDK’s ad rendering capabilities and its supply chain to commit ad fraud by making it harder to distinguish this malicious traffic from legitimate traffic.

To understand how the operation worked, we must first understand the evil twin phenomenon used by the threat actors. Konfety operated using “decoy twins”—the apps listed on Google’s Play Store, none of which committed any fraud—and “evil twins”, which were distributed through a malware/malvertising campaign and which were the source of the fraud.

Decoy Twins

The 250+ decoy twins available in Google’s Play Store contain the CaramelAds SDK, and appear to be generic, template-based games.

Screenshots of different applications containing the CaramelAds SDK

While the apps have, on average, 10,000 downloads each, the amount of ad traffic observed by the Human Defense Platform far exceeded what would be a typical ad volume for that number of downloads.

Upon initial investigation, these decoy apps behave normally, functioning in the way a user would expect, but the majority do not render ads. Although Satori observed multiple network requests to each respective SSP server, the response is always empty and no ad is displayed. In the few apps that did display ads, the only rendered content was full-screen video interstitials.

Example of requests to CaramelAds SSP server, and their respective empty replies

Notably, the decoy apps contain the “full” version of the CaramelAds SDK, which includes a GDPR consent notice. This activity is launched from the SDK as part of its initialization process, and is easily identifiable within the Android manifest.

We observed that the main servers of these apps point to an active address, known for malware and DGA domains. Analyzing the ad traffic information observed by the Human Defense Platform, we observed an increase in traffic showing atypical distributions of country, device, application name, and supply chain. 

These observations prompted researchers to explore where the disproportionate volume of traffic was coming from. Researchers concluded the malicious traffic came from the evil twins corresponding to each of the decoy twins.

Evil Twins

The crux of the Konfety operation lies in the evil twin apps. These apps mimic their corresponding decoy twin apps by copying their app ID/package names and publisher IDs from the decoy twin apps:

Top to bottom: decoy app in Play Store, manifest of decoy app showing package name, manifest of evil twin app showing spoofing of decoy app package name

We’ll start with how the evil twins, which don’t have the benefit of major app marketplaces listing them, end up on devices in the first place.

Malvertising Campaign

Satori researchers have high confidence that the Konfety evil twin apps are spread, at least in part, through a malvertising campaign promoting APK “mods” and other off-Play Store applications. This is a relatively common threat tactic, preying on users’ hopes to change an existing app to suit their preferences.

One IP address—139.45[.]197[.]170—hosts more than 400 domains, more than 300 of which were first observed launching on September 8th, 2023. From that date forward, several dozen new domains were registered nearly every day pointing to this same IP address. (A full list of domains can be found in the Indicators of Compromise section below.)

These domains are DGA (domain generation algorithm) domains and all of the observed URLs use the same format. Most of these domains have been flagged by AV vendors as malicious, based on their use in adware and phishing.

Subdomains for one of DGA domains hosted by 139.45[.]197[.]170
Source: https://www.virustotal.com/gui/domain/thoungains.com/relations

If a device using a mobile user agent derived from an EU country visits any of these URLs, a payload is delivered, redirecting the user to download low-quality applications. (Other device configurations cause the user to be redirected to google[.]com.)

Cloaked redirection

Below is an example of this workflow. The user is incentivized to install low-quality apps based on the promise of gifts, awards and other promotions. A sample of the applications obtained through this flow do not appear to be malicious.

Low quality promo pages that push the user to install applications from the Play Store

Continuing to examine the connections within this malvertising campaign reveals additional attack vectors used by the actors to distribute malware. This discovery stemmed from the use of the URL shortener service urluss[.]com embedded within PDF files.

PDF file containing a URL which redirects the user to an APK download page

This new collection of IOCs provided researchers with a broader understanding of the threat's scope. The IOCs included a list of more than 700 URLs, likely including compromised WordPress sites, websites allowing free content uploads, and various other platforms.

List of URLs containing malicious PDFs with urluss[.]com redirect payload

Some notable websites hosting these malicious URLs include:

• hub.docker[.]com

• opensea[.]io

• sites.google[.]com

• facebook[.]com

(Note: all of the above sites are victims of the Konfety operation.)

The threat actors are abusing the capacity for user-generated content (UGC), including PDFs, to spread links to their networks via this URL shortening service. 

The core of the malvertising campaign involved redirecting users to a domain where they were tricked into downloading a malicious APK file. This file disguised itself as a legitimate Android application and was hosted on CaramelAds’ infrastructure.

Satori researchers found several vehicles for this malware/malvertising campaign, including:

• Malicious PDFs: These PDFs were found on legitimate websites across the web, increasing their potential reach and deceptive nature.
• Malvertising: The actors infiltrated online advertising networks to distribute malware through unsuspecting ads.
• Online Questionnaires: Malicious questionnaires may have been used to trick users into downloading malware.
• Pop-Unders: The attackers may have also used pop-unders, which are hidden windows that open behind the main browser window, to drop malicious APKs.

This combination of methods demonstrates the actors' attempt to spread their malware as widely as possible.

Stage One: Dropper APK and Obfuscated Stager

Satori researchers analyzed both the decoy apps and their evil twins in order to determine how the fraud scheme was conducted at a technical level. The evil twin applications operate in three stages:

• A small APK that uses the impersonated package name from the Play Store twin
• A first stage decrypted from the assets of the APK file, used to define the implementation of services and set up C2 communications
• A second (final) stage that performs fraud and contains backdoored or modified versions of known SDKs

We observed several common characteristics among the dropper APKs:

• The APKs were relatively small - all below 3MB in size
• The Android manifest has an excessive number of activity-alias and receiver entries
• A high detection rate in online multiscanner repositories as being malicious
• Contain a ZIP file comment with string @@injseq

During analysis, Satori researchers observed the dropper APKs are very simple and use a standard obfuscation technique—dynamic code loading (DCL)—to avoid detection as seen below. 

DCL function loading dex file present in the application assets

All of the application logic is contained in the app’s obfuscated stager; the main APK is used to set the initial manifest permissions and to load the stager, which then decrypts, loads, and runs the second stage DEX payload discussed below. (Further payloads are downloaded while the application is running.) 

The first stage defines the implementation of services and listeners, and configures C2 communications in addition to decrypting the second stage payload. Additionally, this first stage adds another obfuscation and persistence feature, hiding the application icon from the application drawer of the Android device, and setting a blank name and icon for the app.

From a normal user's perspective, if the user suspects that the latest APK they sideloaded is the reason for the constant spam and disruptive advertising, the application makes it hard to get removed.

Empty icon and label seen in the app uninstall menu (left) and the code responsible (right)

Stage Two: Encrypted DEX Payload

Once decrypted, this second stage loads a class defined by a specific hardcoded string. This stage of the malware includes backdoored or modified versions of known ad SDKs and performs fraud.

This class initializes a service that appears to render ads based on user presence, as seen below.

Class that performs service initialization to render ads depending or user presence

The code responsible for initializing and starting the fraud contained the address of a SSP server attributed to CaramelAds: ssp[.]swe[.]xyz.

Function openBrowser referencing domain related to CaramelAds

The malware obtains configuration parameters from the C2 server that are used in rendering notifications and full screen intents. This C2 server also tells the applications which additional secondary configuration servers to use.

The ID format used by the CaramelAds SDK in both Play Store and malicious twin applications, seen below in communications with the C2, is used to uniquely identify the application within the CaramelAds platforms.

Different requests using the ZWMWD id

The team reviewed multiple versions of this stage across several apps associated with the operation and found that all were around 2MB in size and share the same code logic. Differences between samples are hard to detect since the malware uses custom obfuscation for each payload but the code logic appears to be the same.

How Evil Twins Abuse CaramelAds

Ad Fraud

Satori observed that the primary way these apps perform ad fraud is by rendering full-screen video ads out of context, when the user is either on their home screen or using another app.

The network traffic derived from the evil twin applications is functionally identical to network traffic derived from the decoy twin applications; the ad impressions rendered by the evil twins use the package name of the decoy twins in the request. Below, an impression that purports to be for a decoy twin, but is rendered on the evil twin:

Successful impression for app com.zombieapocalipse.nearme.gamecenter

Configuration settings for ad slots and ad networks are managed via jetengine[.]be, which follows the same message format as described by the CaramelAds SDK conversion server and shares an historic relationship with official CaramelAds servers.

C2 endpoint definition. Following screenshots are to function calls that use the parsed JSON parameters from the server

Communication with jetengine[.]be following the CaramelAds message format

The CaramelAds SDK also makes it possible to selectively render ads, both in the decoy twins as well as the evil twins. 

Download Tracking

A unique characteristic of the Konfety operation is the apparent ability the threat actors have in tracking each unique download within the CaramelAds platform. During malicious ad rendering, the application sends a unique set of characters when reporting an impression. 

This unique string was not found in the application code or any of its assets, but more careful analysis showed that in fact the string was originating from the dropper APK file itself. Using the comment section of the APK, the threat actors added a unique ID to each download from their malvertising infrastructure.

Code within the encrypted DEX file which will obtain the APK location within the device and extract the @injseq string, bellow we can see the hex dump of the APK file revealing the id

These unique ID strings from the APK comment section—which is pushed through CaramelAds SDK and network—allowed the threat actor to track the success rate for each malvertising campaign.

POST request to the threat actor infrastructure where the DID field contains the @injseq id

Open Windows in Default Browser

The CaramelAds server can also send a reply to a request from the SDK that will open any URL using the device’s default browser, causing it to navigate to what could be a malicious location. The evil twin apps leverage this capability of the CaramelAds SDK in order to visit websites using the default browser, as seen below:

The evil twins are also able to create notifications that prompt the user to click on content that can either open the links above or redirect the user to a Google Play Store page.

Device notifications, often included adult content

Additional Fraud from Evil Twins

Abusing the CaramelAds SDK is not the only way in which the evil twin apps conduct fraud. The apps also sideload code (usually modified versions of advertising SDKs, with an aim of exploiting other ad networks) and installing a search toolbar and monitoring the traffic routed through that tool.

Code Sideloading

All of the evil twin apps analyzed by Satori include the ability to sideload additional code, which in turn can be used to download third-party malicious code. This third-party code can only be sideloaded if certain conditions (server-sourced parameters and device properties) are satisfied. 

Snapshot of the flow from C2 URL initialization to DCL 

Satori researchers collected several different samples of this code, all of which include modified versions of ad SDKs that they used to conduct fraud, as well as a modified version of the CaramelAds SDK itself. The modified CaramelAds SDK is a pared-down version of the full SDK, with only the necessary components to render OOC (out-of-context) ads. The most notable changes are the absence of all the debug outputs and the GDPR consent screen.

Archive of the sample

HUMAN did not observe any other malicious behaviors in these samples aside from ad fraud.

Intent Filter Intercepts and Browser Search Monitoring

Satori researchers noticed the extensive permissions and capabilities present in the evil twin AndroidManifest files, including intent filters for applications like Zoom, Telegram, Wikipedia and X (formerly Twitter). 

Intent filters capture when a user clicks on a link that would open another app. For example, clicking on a link to a Wikipedia entry would open the Wikipedia app, if it were installed on the device.

Intent filters for Zoom and Wikipedia

When an intent filter is triggered, the OS will present the user with a dialog box asking if the user wants to open the link in that external app. If multiple apps share an intent filter, all of those apps will be listed in the dialog box as options for which external app should open the link.

Evil twin apps took advantage of this functionality. Below, a Konfety app uses an intent filter to present a link to an external app as opening the Wikipedia app, and instead hijacks the traffic:

From left to right: implementation of the Wikipedia interceptors, user gets prompted with a “Open With” menu where the evil twin app fakes itself as Wikipedia, user then gets redirected to scam sites and other malicious content

Earlier versions of the evil twins did not have the code necessary to implement these intercepts, and victims would not be redirected or have their traffic captured. However, later updates to the apps enabled this feature, and our investigators were able to observe this behavior and collect further evidence. 

The apps implement the capability to track the user’s browser history using the “Search” activity, seen below.

Manifest reference for the search Activity

When installing the evil twin application on the device, the user is prompted to add a “quick search” widget to the home screen, much like the search toolbars of old. This widget mimics the appearance and behavior of the standard Google search bar present on most devices, but in the background, all URLs the user browses are sent to vptrackme[.]com and youaresearching[.]com.

Manifest reference for the search Activity

Satori researchers are presently unsure of the monetization scheme at play with this specific behavior.

Adaptation

As soon as this threat was identified, HUMAN’s Satori Threat Intelligence team began to flag high confidence traffic sourced from these applications to protect our customers. After HUMAN deployed those countermeasures, researchers immediately started observing adaptations: the threat actors shifted which ad networks were targeted by the operation to avoid HUMAN’s customers.

The malware receives several parameters from the configuration server, including which ad networks/SDKs to target and monetize. After our defense measures, we saw the C2 servers removing networks belonging to our customers from this configuration.

C2 Configuration message

Additionally, we observed that one of the stagers now included an updated version of the CaramelAds SDK that included a malicious SSP server in its rotation list.

During long-term analysis of Konfety, we gained visibility into which Android apps were targeted during a given time period. Changing which Android apps were targeted was potentially a technique to avoid detection from automated systems by distributing the ad traffic across multiple applications.

Conclusion

Threat actors understand that hosting malicious apps on stores is not a stable technique, and are finding creative and clever ways to evade detection and commit sustainable long term fraud. Actors setting up mediation SDK companies and spreading the SDK to abuse high-quality publishers is a growing technique. 

HUMAN continues to monitor the Konfety threat, including how the threat actor adapts to our defenses, and keeps those defenses updated to combat the latest TTPs the threat actor employs.

IOCs

List of Evil Twin App Packages: (CSV file, HTML page)

List of C2 Server Domains

Primary C2s

Tracking C2s