SDK spoofing 101
Mobile advertising and analytics rely heavily on the trustworthiness of the data an app generates through its tracking tools. This data helps companies determine where users come from, which ad campaigns lead to installations, and what actions users take within the app.
However, sometimes attackers manipulate these signals, leading to unreliable analytics data. SDK spoofing is viewed as one of the most advanced forms of this type of fraud. Let’s find out what SDK spoofing is and how to detect it.
What is SDK spoofing?
To grasp the issue at hand, it’s essential to first understand what an SDK is.
An SDK (Software Development Kit) is a set of tools that developers use to add specific features to a mobile app. In marketing and analytics, an SDK helps track actions like app installations, first launches, user registrations, and in-app purchases. When a user performs any of these actions, the SDK sends a signal to the server of an analytics system or advertising platform.
SDK spoofing is a type of mobile advertising fraud. Instead of getting data from a real app, attackers create scripts or server programs that mimic the SDK. To the system, these requests look like real app events because they are correctly formatted, include the right details, and reach the same API endpoints.
As a result, the platform might wrongly count these events as real. For example, it could log an app install or an in-app purchase, even if the user never actually installed or used the app.
The key aspect of SDK spoofing is that it fakes in-app events, not just clicks or ad views. This makes it more complex and dangerous because it disrupts the analytics and tracking systems that companies use for their marketing decisions.
One of the most famous cases is Uber’s lawsuit against its marketing partner, Fetch Media. Uber discovered that some of its app’s ad installs were attributed to a partner through fraudulent attribution schemes, including large-scale fake clicks and installs. The company filed a lawsuit, claiming it was paying for users who were not actually acquired through the ad campaigns. The case ultimately resulted in a multimillion-dollar settlement, and it became one of the most famous examples of advertising fraud in the mobile industry.
One of the most notable cases is Uber’s lawsuit against its marketing partner, Fetch Media. Uber found that some of the app’s ad installs were fraudulently attributed to this partner through schemes involving fake clicks and installs. The company sued, claiming it was paying for users who hadn’t been acquired through its ad campaigns. The case ended in a multimillion-dollar settlement and became one of the most well-known examples of advertising fraud in the mobile industry.
How does an SDK spoofing attack work?
SDK spoofing attacks generally consist of several stages:
SDK analysis
Attackers start by examining how the application sends data to the server. This can involve analyzing network traffic or studying the SDK’s structure. They look for the API endpoint where events are sent, the request structure, required parameters, the format of device identifiers, and the order in which events are sent. Essentially, the attacker aims to understand what data needs to be sent for the server to accept the event as legitimate.
Recreating SDK requests
After analyzing the SDK, attackers create a software tool, typically a server-side script or bot, to generate the same requests that the SDK sends. These requests include the parameters the system expects, such as device identifiers, IP addresses, and advertising campaign details. Since the structure matches a genuine SDK request, the server accepts it without raising suspicion.
Bulk event generation
Next, attackers generate a large number of fake events. Scripts simulate user activity by sending many requests. Depending on the fraud scheme, they can fake app installs, first launches, registrations, and even purchases. Sometimes, events are sent in a specific sequence to appear more realistic, like registering an install, followed by opening the app, and then registering the user.
Receiving advertising payments
If the platform identifies these events as real, they get attributed to an advertising campaign or an affiliate traffic source. This means the system counts an install or another action, and the advertiser ends up paying for these results. Fraudsters profit from users who don’t actually exist. The issue is made worse by the fact that these fake events often look very realistic: they have the correct format, reach the right server, and contain the expected parameters. This is why SDK spoofing is considered one of the hardest mobile fraud schemes to detect.
How SDK spoofing differs from other types of mobile fraud
Click Spam
Click spam, also known as click flooding, is a scheme where fraudsters generate a massive number of fake ad clicks. If the attribution system records the last click before an app install, the fraudster hopes one of their clicks will be the last one, resulting in the install being incorrectly attributed to them. This means that even real users who install the app end up with the installation source wrongly identified, causing the advertising budget to be misallocated to dishonest partners.
Click Injection
Click injection is a more advanced scheme that occurs on Android devices. In this case, a fraudulent app tracks when a user installs another app from Google Play. At that moment, it sends an ad click that appears to be the source of the install. If this click happens just before the installation is complete, the attribution system attributes the install to this source. Consequently, the fraudster earns payment for the install, even though the user discovered the app through a different channel.
SDK Spoofing
The main difference between SDK spoofing and these other methods lies in the level of deception. Click spam and click injection manipulate clicks and attribution, while SDK spoofing goes a step further by faking the data source itself – the app events. This makes SDK spoofing particularly complex and challenging to detect.
Why SDK spoofing is difficult to detect
Correct Request Format
Attackers carefully analyze the structure of SDK requests before launching an attack. As a result, they send fake events with the same parameters used in real requests, making it harder to spot the fraud.
Use of Real Device IDs
Often, fraudsters utilize real or previously harvested device IDs. This tactic adds to the believability of the events, as the IDs appear to come from legitimate devices.
Server-Side Attack
A significant challenge with SDK spoofing is that it often happens on the server side, without involving any real device or application. Since the system only sees the incoming requests and not their source, it becomes much more difficult to distinguish fake events from genuine ones.
Plausible Event Sequence
To avoid detection, attackers often mimic normal user behavior. For instance, after a fake installation, they may send events for an app open, registration, or other actions. This sequential pattern seems logical and may not raise any red flags in standard analytics reports.
How to protect yourself from SDK spoofing
Verify Request Generation
One effective method is to ensure that requests are generated within the application. This can involve using special authentication mechanisms, such as:
- Digital signatures for requests
- Tokens built into the SDK
- Verification of application secret keys
- Encryption of data sent between the SDK and the server
Encrypt and Secure Network Traffic
Because attackers often analyze an application’s network traffic to understand SDK requests, it’s vital to implement data encryption and secure connections. This includes:
- Using secure transmission protocols while encrypting request parameters
- Protecting API endpoints from unauthorized access
These measures make it harder for attackers to analyze request structures and significantly complicate event spoofing.
Perform Server-Side Event Validation
Implementing additional server-side data validation is another critical mechanism. The system can evaluate:
- The sequence of events and time intervals between them
- Consistency between geolocation data and IP addresses
If an event seems unusual or goes against expected user behavior, it can be excluded from attribution.
Use Anti-Fraud Systems
Many mobile analytics platforms and advertising networks employ specialized anti-fraud algorithms. These systems analyze large datasets and identify patterns that indicate automated event generation.
Conduct Regular Audits of Data and Partners
Companies should consistently assess the effectiveness of their advertising channels, monitor abnormal conversion rates, and limit access to SDK data. Regular monitoring helps quickly spot sources of suspicious activity.
SDK spoofing is one of the most advanced forms of mobile advertising fraud. Unlike many other schemes that focus on faking clicks or ad interactions, SDK spoofing aims to imitate app events. This allows analytics systems to record installs, app openings, or user actions that never actually happened.
As mobile advertising continues to evolve, fraud techniques are becoming more sophisticated. Therefore, it’s crucial for companies to focus not just on user acquisition but also on the quality of the data that supports their analytics. Effective protection against these attacks is essential for maintaining accurate metrics, ensuring transparency in marketing campaigns, and maximizing the effectiveness of advertising investments.
To combat SDK spoofing, companies should invest in security measures like encryption and regular audits. By doing so, they can better protect their data and make more informed marketing decisions. This will help create a more trustworthy advertising environment, benefiting both businesses and users alike.