SDK spoofing, also known as traffic spoofing or replay attacks, is the creation of legitimate-looking installs using real device data. Along with click fraud and click injection, it is yet another way fraudsters are stealing from the pockets of advertisers who are either unaware of the issue or are yet to implement essential fraud prevention tools.
In recent years, this has become one of the fastest-growing threats to the mobile marketing ecosystem, making it critical for all marketers to understand. This is why SDK spoofing is described as “the future of mobile ad fraud,” which Interceptd says accounts for up to 18 per cent of all mobile ad fraud.
In an effort to combat this malicious technique, let’s explore how it works, what this means for campaign results, and how it can be stopped.
What is SDK Spoofing?
Using real device IDs, SDK spoofing allows fraudsters to dupe advertisers into paying for fake installs. This technique consumes an advertiser’s budget by generating legitimate-looking installs that are particularly difficult to detect, due to the use of legitimate device IDs. Although a real device is used to enact this fraudulent scheme, it’s important to note that an install never occurs.
These installs are faked by breaking open the SSL encryption from the communication between a tracking SDK and backend servers. This can be done with a “man in the middle attack,” which can be performed using a proxy software. A man in the middle (MITM) attack is usually when fraudsters attempt to position themselves between a user and an application.
This can be used to impersonate either party, with an aim to emulate a regular exchange of information (in other cases, this can be performed to steal login details or even credit card information.) For SDK spoofing, the MITM attack allows the spoofer to gain control over the source and the means of delivery.
Once the MITM attack is complete, fraudsters target an app with a series of test installs. At this stage, they can read the URLs in clear text format for every server-side connection, learning which URL calls represent different in-app actions – including anything from level-ups to purchases.
Fraudsters will then make use of these communications to determine the URL logic needed to fake an install: once they have created a fake install session that is “successfully” tracked (i.e. faked) these fraudsters have everything they need to repeatedly generate fake installs. This can be particularly lucrative for campaigns with a high Cost per Install (CPI) incentive.
SDK spoofers have continued to develop their fraudulent methods over the last few years, becoming even harder to detect. Rather than using a list of device IDs, there are more sophisticated spoofers who will write their own apps. This means that an app with an entirely functional use, such as a flashlight app, may have been created with the intention of harvesting genuine device IDs.
How will this affect campaign results?
As an advertiser, this results in you losing out to fraudsters, handing over valuable ad spend every time a fake install is generated (something these fraudsters can perform with ease once they have the necessary information). This can happen on a huge scale, with Martech Advisor reporting that advertisers can lose “up to 80% of ad budgets on a campaign” as a result of SDK spoofing.
Although this is a significant loss, the greater damage is to advertisers’ campaign results. With fraudulent activity infiltrating your ad spend, you can no longer trust your analytics. Not only have you lost revenue, but you’re also disadvantaged because you have no clear view on where to invest next.
How can SDK spoofing be stopped?
Because this scheme involves real devices, detecting (and preventing) SDK spoofing is more complicated than, for example, detecting install farms or emulated devices. Unless you have sufficient protection, there’s nothing to stop SDK spoofers from purchasing device IDs and generating more install events for further payment. And because those device IDs are real, everything will appear to be legitimate. This makes it essential for marketers to have logical, calculated expectations of how their campaigns will perform. If SDK spoofers are able to steal 80 per cent of your ad spend, understanding what measurements are too good to be true should be the first line of defence.
Secondly, to be protected from SDK spoofers, you need preventative tools that can verify that this data came from a real app and that it was running on a real device. You should contact your mobile measurement partner and discuss the tools available to you, with a focus on preventative measures against spoofing.
However, even this is particularly difficult (and not entirely foolproof) because the fraudster has control over the source and the means of delivery. A practical solution is to disincentivize SDK spoofers to a point at which it isn’t worth their investment. Just like marketers, fraudsters are interested in a positive ROI, so if you can lower their projected ROI by scamming your app, you’ll make yourself a less valuable target. Even though protective measures cannot be entirely foolproof, they can be complicated enough as to make spoofing your app of little value to SDK spoofers.