Mobile ad fraud methodology
Mobile ad fraud methods are varied and apply different malicious techniques based on several parameters:
- Fraudster target & goal
- Exploited weaknesses or loopholes
- Available technology
- Level of sophistication
- Financial capabilities
The above are all integral parts of the equation for deciding the type of fraud, scale and target that the fraudster is looking to target.
When examining the most common fraud methods, these can be broken down into 2 main categories:
The main difference between the two categories are the users.
Attribution Hijacking methods rely on real users (organic or non-organic), using fake click reports to manipulate attribution conversion flows. Injecting clicks in different points across the user journey will help them steal credit for installs and users provided by other media sources.
With fake installs, the entire user journey is fake. Impressions, clicks, installs, in-app events and even users are all fake.
[Fraud method / user type table]
While both cases damage the advertiser’s activity and resources, with Attribution Hijacking tactics the users are still real and provide some value. Unlike Fake Installs who present zero value to advertisers, often making their entire user acquisition data worthless.
Specific methods under these two categories are varied, the most common methods currently used are examined below.
Install hijacking is a type of fraud where fraudsters “hijack” credit for an install generated by another media source. Common techniques include, sending false click reports or injecting false referrer data.
A user would click on an ad presented by a legitimate media partner, and will be directed to the PlayStore to complete the download. Once the download process starts, the Android device will inform the other apps on the device that a new app is being downloaded – this is done using a standard android broadcast.
This broadcast – available for any app – will then trigger a malware that had already exited on the user’s device within another app.
The malware will generate a fake click report on behalf of the fraudster – making it appear as if the fraudster is the one who generated the install. This will manipulate the last click attribution model, placing the fraudster as the one who generated the last registered click.
Once the app is launched – attribution will be stolen.
Exploiting a basic attribution model is relatively simple for the fraudster. However, this type of fraud is also relatively simple to identify using standard CTIT measurements and anomaly detection.
The fraudster’s click will naturally come in significantly later than clicks driven by legitimate sources.
Thus a short CTIT rate will indicate a case of attempted install hijacking.
Sophisticated fraud solutions can use click timestamps to attribute the install to its rightful media source using attribution calibration – minimizing damages on the advertiser’s reporting and retargeting data.
In click flooding, fraudsters send a “flood” of false click reports from, or on behalf of real devices. Once the actual device downloads the app, the sub-publisher is falsely credited with the install.
Click flooding often targets organic users as it aims to take credit for their activity using probabilistic methods.
The fraudster would create publisher accounts across various attribution channels and pull attribution URLs for as many apps as possible.
Populating large masses of clicks with real device details can be done either by malware from user devices or by purchasing user data in nefarious channels (dark-net).
Clicks can be generated randomly or in a calculated manner based on the user’s installed apps or browsing activity.
Once users organically reach the App Store or Play Store and download an app, a click is already falsely associated with them, even though no ad was viewed or clicked.
Once the app is launched by the user, the fraudster is credited with an organic install that the advertiser should never pay for.
Click flooding attempts can be identified and blocked using different methods like very low conversion rates and CTIT measurements.
A long CTIT rate will likely indicate attempted click flooding, as clicks are constantly sent on behalf of users regardless of their activity or time of app installation.
Attribution hijacking – key takeaways
Attribution hijacking fraud methods are considered relatively simple to initiate and operate. They require quite basic technology and their reliance on real user data means that the majority of data is generated organically rather than falsely inserted into the postback information by the fraud operator.
The potential gain from attribution hijacking fraud is considered limited for several reasons. Its relative operation simplicity also makes it quite simple to detect by fraud detection solutions by measuring CTIT timestamps anomalies. The operations are also limited in potential scale as they rely on real users - limiting them to a finite number of potential devices to exploit.
As attribution hijacking methods rely on real users, advertisers would still receive some value from these users. However the advertiser's marketing budget allocation is manipulated, meaning that quality publishers who made these installs possible are not rewarded as the credit for their hard work is stolen by malicious sources. This affects any future budget allocation decisions made by the advertisers, as fraudulent sources appear to provide quality and legitimate publishers are pushed aside.
Device farms are locations full of actual mobile devices clicking on real ads, downloading real apps, while hiding behind false IP addresses and fresh device IDs.
Often associated with remote parts of the world, device farms could be located in any space that can hold and operate a large number of devices – from bedrooms to warehouses. Very popular in the early 2010’s, these operations can be operated either by low paid employees or emulators, working around the clock on constant app engagement and device resetting.
The more efficient the operation is at creating engagement and resetting its device identities, the more revenue it can generate.
The relative simplicity of this method, combined with lower mobile device prices and economic difficulties, introduced a second wave of device farms in common western households as a means of creating additional income.
Device farm identification
New devices are not uncommon and are expected to be found in any campaign, as users constantly upgrade or change their devices for various reasons. However, a campaign’s New Device Rate should be monitored for anomalies. High NDRs, combined with other parameters, are a possible indication of device farm activity operating with device ID reset at scale.
According to AppsFlyer’s data, common new device rates shouldn’t surpass 10%-20% of the campaign’s activity.
Bots are malicious codes that run a set program or action. While bots can be based on real devices, most bots are server-based. Bots aim to send clicks, installs and in-app events for installs that never truly occurred.
Bots can be applied to automate any action within the user flow or the app itself, including the methods presented earlier. They can be used to mimic real user behavior based on behavioral biometrics data collected by malware on user devices.
These “trained” bots appear “real” making them harder to identify and block. Fraudsters adapt to advanced detection logic and train bots to run through in-app engagement measurement points appear as engaged “real” users. This presents double value for fraudsters as they appear as quality publishers who deliver engaged users, as well as gain CPA revenue from in-app events.
Some fraudsters even offer their bots as services such as harvesting game resources, passing levels, and generating revenue for third parties in what’s considered as FAAS (Fraud as a Service).
Fake installs – key takeaways
Fake installs fraud methods are considered more complicated to operate and maintain. The fraudster would require a very high level of technological abilities and sophistication to not only design an elaborate mechanism to continuously generate users, but also randomize that behavior at scale to avoid sophisticated pattern detection algorithms.
While more complicated to operate and maintain, once successful a fake user fraud scheme presents unlimited potential scale. Unlike attribution hijacking schemes which rely on real users, bots and device farms don't require real users or even real devices to operate. Faking the entire user journey makes their operation potentially limitless and profits much higher.
Unlike attribution hijacking methods, with fake installs the advertisers receives zero value. Users are completely fake, any interaction made within the app is pre-programmed to drain even more CPA rates from the advertiser and cause more damage. the advertiser's data will often be worthless as these fake users mix with real ones, making retargeting efforts pointless.
One form of bypassing install fraud detection is by fraudsters feeding false information into the advertiser servers. SDK hacking (AKA spoofing) is a type of bot-based fraud, often executed by malware hidden on another app within the user’s device.
In SDK hacking, fraudsters add a code to an app (the attacker) which later generates simulated ad clicks, installs and engagement signals to the advertiser’s attribution provider on behalf of another app (the victim).
When successful, these bots can trick an advertiser into paying for tens or hundreds of thousands of installs that did not actually occur, as their servers are tricked into believing that installs indeed took place.
SDK hacking is a common issue for attribution providers with weaker SDKs or poor security infrastructure. Simple security loopholes like a poor encryption mechanism (easier to decipher) or relying on open source technology (presenting code publicly for fraudsters to review) could pose as a potential open door for fraudsters to manipulate the attribution provider’s code or reverse engineer it. A closed source, encrypted SDK (like AppsFlyer’s) provides better protection from reverse engineering and code manipulation, by not revealing the code publicly and masking its encryption logic, making it significantly harder to breach.
It’s important to note that no method is foolproof, as sophisticated hackers can potentially hack anything they set their sites on. However, better security and protection on the code and infrastructure level will minimize risks and make hacking attempts a bad investment for fraudsters.
In-app (CPA) fraud
In 2008 the App Store introduced the CPI promotion model – the dominant promotion form for app developers – rewarding media partners for generated app installs.
The CPI model opened the door to install fraud, which started delivering poor user value for advertisers. In an attempt to reduce the damages of install fraud, a new promotion mechanism was introduced - CPA (cost per action).
CPA models relied on a base assumption that a user who’s active beyond the point of installation would be regarded as a quality user and not a fraudulent one. CPA models relied on a base assumption that a user who’s active beyond the point of installation would be regarded as a quality user and not a fraudulent one. Advertisers (mostly from the gaming vertical) started mapping out key in-app events within their apps to measure user LTV (lifetime value).
- Level reached
- In-app purchase made
The CPA rates for these events were often significantly more rewarding than the CPI offered, as they reflected an engaged user with higher LTV and acquisition value. With time more advertisers from various verticals adopted the CPA model with the assumption that this could provide sufficient protection from ad fraud as well as drive better user value.
However, as stated earlier, fraudsters follow the money – very quickly catching up with the new CPA game. What was once considered a fraud-free promotion model, is now infected with ad fraud.
Advertisers who managed to decrease their install fraud rates by shifting towards CPA (gaming, shopping, and travel verticals mostly) are now hit harder through sophisticated bots specifically designed to bypass install fraud detection, and hit rewarded in-app events, crushing advertiser in-app economies.
In-app purchase fraud
In-app purchases and in-app marketplaces are a common method for advertisers to generate revenue by selling actual (merchandise, services, and products), or virtual goods (game resources, artifacts, etc).
A definite majority of apps rely on free or freemium business models (under 4% paid apps), where the app download is free and revenue generated from ads and in-app purchases as stated above. An app’s entire business model could often revolve around its ability to generate these transactions at certain rates, and they reward their publishers accordingly when these are generated.
CPS (Cost Per Sale) rates are considered the highest in the market, as they reflect the highest quality of users and guaranteed income for the advertiser. These can vary from fixed rates to percentages from each sale. Fraudsters will do whatever possible to get hold of this activity, as they reflect a much bigger payday per successful action than CPI, thus requiring less successful actions to generate revenue.
As in-app fraud continues to evolve and improve, an increase of fraudulent in-app purchase attempts is also noticeable, hitting all major verticals.
False positive test
A false positive is a case where a legitimate install is falsely flagged as fraud.
The false positive test sets the allowed precision level for fraud detection algorithms. The higher precision level is – the more conservative the fraud detection is. The lower precision level is – the more permissive the algorithm will be. More fraud will be detected, but at the price of more false positive cases.
Higher precision = lower false positive rate.
As damaging as mobile ad fraud can be to an advertiser’s business, false positives could potentially be worse, as they indicate cases where an install was falsely identified as fraudulent.
Unlike true positive cases, where real fraud is identified and fraudulent sources get exposed and blocked, a false positive case potentially penalizes legitimate sources. This could harm the advertiser’s relationship with its quality media partners rather than protect it from malicious ones.
Any responsible fraud solution should keep its false positive rate as minimal as possible, in order to protect its integrity and credibility while protecting its client’s best interest.
That being said, fraudsters are fully aware of fraud prevention vendors’ intentions of avoiding false positives, so they deliberately mix legitimate installs into the fraud mix. This isn’t done as an attempt to improve their traffic in any way, but rather whitewashing it, only to be later used as a counterclaim when their activity is blocked.