To save time and resources, app developers rely more and more on third-party SDKs – pre-made software elements that make it easier to add functionality and shorten development timescales.But the rush to get to market and monetize their work is leaving many apps open to malware infection. Malicious SDKs are often to blame.


What Is An SDK?

SDK​ stands for software development kit. Designed for specific platforms like Android or iOS, they comprise a set of ready-to-use software tools app developers can put to work quickly, often for free​.

SDKs can be a huge benefit, freeing up developer time to focus on higher-value features and functions. They can include core software requirements like libraries, code samples, processes, and documentation. For example, an SDK can provide engagement data or crash analysis information.

But their popularity and ease-of-use also make them an irresistible vector of malware infection for cybercriminals and advertising fraudsters.

Suspicious SDKs that promise to connect apps with advertising networks and ad mediation platforms are turning up with increasing frequency – and turning the apps that embed them into something close to malware.

In most cases, the developers are innocent, only embedding SDKs with ad functions to monetize their work and access a revenue stream. But if the development kit contains malicious elements, they end up facilitating advertising fraud – putting their business and end-users at risk.


How Malicious Advertising SDKs Operate

When a malicious SDK is used to build an app, the compromised app embeds malware in end-user devices.  After installation, the app effectively takes over the device, infecting it with malware, then using its operating system to commit fraud.

Victims may be shown intrusive advertising or have credit stolen from their mobile accounts by signing them up for unwanted paid subscriptions.

The modus operandi of malicious SDKs is well known.

  1. The first step is to collect data on the infected device and report it back to a remote command-and-control (C&C) server.
  2. The second step involves the C&C server sending a command that executes inside the user’s device. Common commands can be to load advertisements or to download and install other malicious code.


Recent SDK-borne Infections

Secure-D recently uncovered suspicious activity from popular Android apps Vidmate and Snaptube, which were found to be generating fake clicks and installing suspicious apps without users’ consent.

In the case of Vidmate the app had been compromised with inactive and hidden malware. Once installed on a device, they would load a third-party SDK called Mango and execute it.

Mango would then contact a C&C server and receive instructions for delivering invisible ads to a user’s device. Clicks would then be simulated to instigate and confirm sign-ups for paid data subscriptions.

Although these views and clicks were reported as genuine to the networks serving the ads, the activity was invisible to the end-user.

The Mango SDK was also discovered in Snaptube, another popular Android app where Secure-D observed a common traffic pattern, and the use of similar URLs and domains, as those involved in the Vidmate compromise.

caption: A compromised SDK on a user’s device communicates with a command and control server, which sends back malicious instructions.


In another case, a mobile malware called ExpensiveWall had been embedded in an SDK used by over 50 apps available on the official Google Play store.

The SDK would instruct the device to connect to a C&C server and subscribe the user to premium SMS services. Its malware could even mimic the screen taps needed to execute a multi-step sign-up and hide SMS confirmation messages to keep the activity secret.

In the case of CamScanner, a hugely popular Android app downloaded over 100 million times, the developer used an advertising library from an SDK containing malicious code. The code would push ads to infected devices and install unwanted apps without users knowledge.


How Malicious SDKs Impact End-users

Loss of credit from unwanted subscriptions to premium data services.

Data depletion. For example, in case of a malware called DrainerBot, hidden video ads were delivered secretly in the background, consuming more than 10GB of data each month from every infected device.

Leaking of personal data like IMEI, phone number, email, device information, and location.

—Increased risk of further infection. Many SDKs have the ability to download other malware.

Depleted battery life.


Developers Should Be Afraid, Very Afraid

When detected, malicious SDKs can cause apps to be suspended from app stores – even when developers are unaware of the infection.

CamScanner was a popular app with millions of downloads but Google still removed it from Google Play Store. While the app has since been re-instated, the app’s developers have suffered disruption to revenue, and a loss of reputation that could impact growth or even jeopardise their businesses. If a future infection or suspicious activity is detected, they may well find themselves banned outright from the iOS App Store and Google Play.

In an evolving mobile threat environment, developers would be well-advised to choose SDKs and modules carefully. They can’t let the commercial requirement to monetize apps override the need to stop questionable SDKs from sneaking malware into the products they’ve worked so hard to create.