Did You Know These Mobile Fraud Examples?
Most marketers have heard of mobile ad fraud. Most also assume that fraud detection tech companies are detecting mobile fraud and preventing or reducing it for them.
But has it ever occurred to you that the detection technologies are not seeing the fraud because bad guys are actively circumventing detection? For example, by blocking the detection tags, not installing the SDKs, or simply passing fake data so everything gets marked as "valid?"
NOTE that we are not talking about mobile app install fraud in this article, only mobile display ad fraud. Further reading and examples: https://www.slideshare.net/augustinefou/mobile-display-fraud-is-rampant-beyond-belief-102771113/4
Fake Mobile Apps - No Functionality, Just Designed to Load Ads, Steal Info
Mobile apps are truly the wild west. Most are not measured by traditional fraud detection tech. Fraud detection SDKs are not installed by bad guys who intend to use the apps to commit ad fraud. Mobile apps also ask for many permissions - like making and receiving calls, reading and sending SMS, camera and microphone access, ability to launch apps, logging keystrokes, connect to Wifi and networks, prevent the device from sleeping. What do you think they are doing with all these permissions?
Fake Mobile Devices - Hyper-scale Ad Fraud by Loading Apps and Using Them Continuously
A rack of real mobile devices cannot be easily scaled up, due to the need for physical space, electricity, and cooling. But mobile emulators are software programs that can be used to load adware apps and continously load ads. Many copies of these emulators can be maintained in cloud data centers to install (fake installs), launch, and interact (fake engagement) with mobile apps that have the ad tech to run ads. For more information, see this example - Genymotion Cloud.
Defeat Frequency Caps - Using Random, Fake DeviceIDs
Fake mobile apps can easily defeat frequency caps by rotating or randomizing the deviceIDs passed in the bid requests. Since there is no central database of real deviceIDs versus fake ones, most exchanges just let the bid through because they are afraid of false positives and they make more money on the volume of ad impressions that flow through their networks. Even if you set a frequency cap of X per unique device, fraudsters can defeat those frequency caps by presenting a new deviceID that has not been seen before.
Defeat Carrier Checks - To Commit More Fraud on Validated Devices
One would think that wireless carriers can determine which is a real mobile device versus which ones are faked, using fake deviceIDs. They can. But here's how bad guys can still get around these so-called "carrier checks." They copy off a valid deviceID from a real device that has already been verified by a wireless carrier as a real device used by a real human. And fraudster just replays the valid deviceID; when presented in the bid request it appears to be coming from a validated device, so the ad exchanges let the ad serve, even though it's fraudulent (right side, chart above).
Geolocation Fraud - Pretend to be in Any Targeted Location
Mobile apps can't tell if the GPS location being passed to it from the device is real or not. And mobile apps can't tell if the device it is loaded on is real or not. So they just faithfully take the lat-long coordinates that are passed to it and pass it into the bid request. Fake apps designed to commit ad fraud can also do this themselves and it is widely known that any bid request that has location information will earn more than one that does not have locations. So it is a best practice for bad guys to always pass geolocation info, even if it is outright faked, because that is how they maximize yield/profit for every ad impression they create.
Read more: https://www.dhirubhai.net/pulse/geolocation-fraud-rampant-ever-cybersecurity-ad-fraud-researcher/
Thought you bought desktop, avoided mobile in-app?
Have you heard of apps loading webpages in hidden browsers - like the flashlight apps, keyboard app, alarm clock app? When does a human need or use a browser when using a keyboard app? They don't. But yet we are seeing various fraudulent mobile apps load webpages in the background using hidden browsers. Because they control the browser, the HTTP headers can be altered to show anything -- for example, that the referrer came from specific sites, that the app name was com.facebook.katana (the official Facebook app), etc. this way, they can easily defeat fraud detection and also make the traffic appear to be desktop and not in-app, or from "social" sources, etc.
Read more: https://www.slideshare.net/augustinefou/mobile-display-fraud-is-rampant-beyond-belief-102771113/20
You knew all of the above, right? and those don't affect your campaigns, right?
Every Month a New Example Documented and Outed
May 2019 - https://www.buzzfeednews.com/article/craigsilverman/vidmate-app-download
April 2019 - https://www.buzzfeednews.com/article/craigsilverman/google-play-store-ad-fraud-du-group-baidu
March 2019 - https://www.buzzfeednews.com/article/craigsilverman/in-banner-video-ad-fraud
November 2018 - https://www.buzzfeednews.com/article/craigsilverman/android-apps-cheetah-mobile-kika-kochava-ad-fraud
October 2018 - https://www.buzzfeednews.com/article/craigsilverman/how-a-massive-ad-fraud-scheme-exploited-android-phones-to
About the Author: “I advise advertisers and publishers on the technical aspects of fighting digital ad fraud and improving the effectiveness and transparency of digital advertising. I help audit their campaigns and show them detailed data so they can verify for themselves what is fraud and what is not fraud.”
Follow me here on LinkedIn (click) and on Twitter @acfou (click)
Further reading: https://www.slideshare.net/augustinefou/presentations