Mobile fraud is on the rise. Compared to 2017, mobile ad fraud rates have almost doubled, and we currently reject around 10% of all paid installs as fraudulent, a sizeable amount indeed. This threat looms over an advertiser’s bottom line, and without the means to stop it, marketing budgets are left wide open to theft.
Most recently, fraudsters have upped their criminal activities with a new, unfamiliar, yet highly malicious form of mobile ad fraud, known as SDK spoofing. Let’s go over what it is, how to recognize it, and how to take action against it.
What is SDK spoofing?
SDK spoofing is the creation of legitimate-looking installs of mobile apps on real mobile devices without the presence of actual installs. Originating in 2017, SDK spoofing spread like wildfire among fraudsters, and it is also one of the reasons why fraud rates doubled compared to 2017.
Ironically the word spoof means to play a trick on someone as a joke, but SDK spoofing is no laughing matter. The fraudster successfully masquerades as an organic user by falsifying data to steal ad spend budget. Today, it can siphon off as much as 80% or more of a company’s ad budget. It’s quickly surpassed other popular fraud schemes like click injection, click spam, etc., and now accounts for 37% of all rejections, meaning that during an analytics quality review, the attribution will be rejected.
SDK spoofing is a significant threat. What is at risk globally is the communication between client side software (SDKs in Apps), their respective backend servers and the services connected to that infrastructure, be it attribution, ad delivery or measurement of any of these. The spoofing goes even further to also include app/server communication outside of the SDK ecosystem.
No advertiser is immune to the damages it can cause. I firmly believe that understanding it is the first step to combating the problem, which is then followed by understanding exactly how fraudsters carry out SDK spoofing.
Recognizing SDK spoofing
According to Gartner, marketing executives must develop the ability to identify ad fraud and minimize its effect on their campaigns' efficacy. Fraudsters utilize mobile devices to install a fake app or infiltrate a user’s existing app without their knowledge (let alone consent). The data collection is done in apps, with malicious intent, but not necessarily in full on malicious apps.
Exploiting the likelihood that advertisers, marketers, and publishers are unable to identify whether the install is real, fraudsters siphon away advertisers’ campaign dollars. How is this possible if everything is fake? That’s the crux of this form of fraud -- not everything is fake. The source is real, the device data generated is real, but the install never happened. Sadly, advertisers are draining their ad budgets for fake engagements. Even users are unaware that their mobile device has been enslaved and been an unwitting party to fraud.
To better understand how fraudsters attack, let's break it down:
1. By performing a man-in-the-middle attack (MITM attack), fraudsters break open the secure sockets layer (SSL) encryption between the communication of a tracking SDK and its backed servers.
2. Fraudsters then generate a series of ‘test installs’ for the app they are planning to siphon.
3. They then discover which URL calls represent specific actions within an app.
4. Fraudsters research which parts of the URLs are static and which are dynamic.
5. They then test their setup and experiment with the dynamic parts.
6. Finally, once a single install has been successfully tracked, fraudsters know they have figured out a URL setup that will allow them to create installs out of thin air.
7. They then repeat the process indefinitely.
It’s important to note that originally SDK spoofing attacks were easier to spot, but over time it’s become significantly harder to recognize and identify. That’s why it’s imperative for advertisers and marketers to understand how fraudsters attack. More importantly, they need to learn what they can do to defend and protect their budgets from being taken.
Fraud prevention
As the old proverb goes -- an ounce of prevention is worth a pound of cure, meaning that it's easier to stop something from happening early on rather than to deal with the damage after the fact. Often with SDK spoofing there is no recourse. Therefore, prevention is imperative as a defensive measure. How do you prevent SDK spoofing given its a multi-faceted threat?
While you might think “hotfixes” are a possible solution, they are not a silver bullet. In some cases, advertisers and marketers might have to manually research hundreds of thousands of data points in order to prove that the app installs were fake. While it might help in recovering some portion of one’s lost budget, it is time-consuming and not a very viable approach or solution.
Our first solution was to create a signature hash to sign SDK communication packages. We introduced a dynamic parameter to the URL which is only ever used once for every call. Naturally any security layer in an ecosystem where fraud is, as lucrative as the digital advertising industry, will be relatively short lived due to the multitude of highly motivated attackers. Thus we are constantly working on updates to our security solution adding more security layers and will release them in regular intervals. Advertisers will have to review their past stance on SDK updates and should acknowledge that security comes at the price of vigilance, which manifests in the form of regularly updating the security for their apps measurement.
There’s no time to lose
Don’t wait for the first signs of SDK spoofing, as SDK is really hard to detect. Education, recognition, and prevention are three steps that can help combat the problem and keep your ad dollars safe from scammers. Whether an entrepreneur, advertiser, marketer, or publisher, it's essential to remember ad fraud is everyone’s problem. Taking preventive measures and putting up a solid defense is sometimes enough to discourage fraudsters, who may redirect their course and seek more vulnerable companies.
The spoofing attacks do not only target measurement SDKs but also client-server communication of the app - spoofing metrics for the app developers on their servers. They also spoof monetization SDKs in which impressions/clicks are being spoofed without actual ad delivery or user interaction in these apps. Therefore us securing our SDK is a good start but advertisers should be vigilant and inquisitive about any data forwarded to or recorded by them and always check if the data actually makes sense.
Finally, if you want to know more about SDK Spoofing, we recently published an interview with Abdullah Obaied, Mobile Security Specialist at Adjust goes into depth about SDK Spoofing from an expert’s point of view.
James is Adjust's Senior Content Manager. Born Londoner, he moved to Berlin in early 2016 and found Adjust, for whom he's been working for since. James has worked as both a freelancer and within media agencies, and now he's realizing a small dream of working within a tech company.