Software Development Kit (SDK) spoofing is the newest type of fraud, on the rising trend: it accounted for 24% of the total intercepted fraud events by the well-known Mobile Measurement Platform Adjust. It is growing at a faster pace than any other fraud’s type, representing now the biggest threat on the market for any app developer planning to invest on app marketing. It is one of the smartest ways fraudsters have imagined because it uses real devices from innocent people to realize its hacking in the aim of getting the attribution of a payment for the action performed, accounting for over dozens of billions of ad fraud. So businesses wonder what it is exactly, as it remains unknown by a majority of people and how can it be spotted and evicted in order to save a lot of money invested in a user acquisition campaign?
SDK spoofing is a method of fraud which consists in the fake creation of a legitimate-looking app install as well as post-install event on an existing mobile device. It is thus one of the most sophisticated and hardest type of ad fraud to detect, making it more and more widely spread. It became a very fruitful way for fraudsters to generate revenues, falsifying the data and stealing ads spend budget from app developers and agencies.
How do they do it? As you know, any app developer wanting to acquire new users by ad marketing campaigns has to integrate the SDK of a Mobile Measurement Platform (MMP) such as Adjust, Appsflyer, Kochava or Branch, in order to attribute and analyze its downloads and app events. What fraudsters do is that they first hack the MMP and listen to their “secure communication” in order to then replicate it and mimic this information to fool the attribution process. It will send the signal to the MMP that an install (and after that any post-install event) has occurred from a specific phone, while actually no such thing happened, faking the attribution system while no ad was seen and no users made any download. It often originates from another downloaded app designated for SDK spoofing, such as a wallpaper, alarm-clock, weather or flash light app, and actually sends signals to an MMP from this real phone. This is different from click spamming fraud, where the app download really occurs but the attribution is poached to organic traffic, after the fraudster sent millions of clicks to get that attribution and payment.
Detecting SDK spoofing is more complicated to detect than any other type of ad fraud, the installs and events originating from an existing device id and the behavior usually looking very similar to a legitimate install. There are still different indicators that can point app developers to that:
So with SDK spoofing fraud, the source is real, the device data generated is real, but the install never actually happened and the user is not even aware of what is going on “behind the scene”. With very few clues to spot it, it is also extremely difficult to evict it from any advertisers’ traffic in order to secure their marketing budget.
As seen in the previous section, the main breach for fraudsters is related to the SDK the app developer has integrated within its app. It is always recommended to avoid an Open SDK that would be an easy entry point for fraudsters using SDK spoofing type of fraud. Then, it became evident that an efficient fraud eviction goes through an automated, real time and evolving fraud prevention tool. This can be done directly by the MMP (such as Appsflyer’s Protect 360 or Adjust’s Fraud Suite), but should be reinforced by an additional layer of control, mostly through another fraud tool that will analyze the data in a different way and thus complete the first control made by the MMP, or working with an adnetwork that has this tool. At Dreamin, we have developed an in-house technology allowing us the detection of such fraud patterns in order to eliminate such traffic and help advertisers save money. By 2022, mobile traffic fraud is estimated to reach $67 billion; it is a long road to go to get that amount close to zero.