![Mobile ad fraud prevention tactics - featured](https://www.appsflyer.com/wp-content/uploads/2023/03/51318-1200x630-1.png)
Immediate fraud risks within iOS 14 and SKAdNetwork
![fraud ios 14 skadnetwork - Square fraud ios 14 skadnetwork - Square](https://www.appsflyer.com/wp-content/uploads/2021/02/fraud-ios-14-skadnetwork.png)
Within the general feeling of confusion and uncertainty surrounding SKAdNetwork, one question remains unanswered – is there a risk of attribution fraud with Apple’s new attribution protocol?
Apple has introduced several anti-fraud mechanisms that are meant to obstruct different types of attribution manipulations. All transactions that are tied to an SKAdNetwork event are cryptographically signed and verified by Apple in order to prove that the postback is attached to a known conversion event by Apple.
The postback includes a unique transaction ID (a unique identifier for a transaction, such as a purchase or re-download) in order to detect replays of valid conversion events.
The mechanisms above are meant to validate the postback’s authenticity, but neglect to address the user’s interaction authenticity (impression or click).
Can these mechanisms be bypassed? And can fraudsters find creative ways to work around these limitations while being unnoticed?
To answer the above, let’s break down the possible attribution fraud scenarios in SKAdNetwork:
- Manipulating a postback before it reaches the advertiser: The signature and transaction ID mentioned above are meant to treat such cases. However, both the signature and transaction ID can be bypassed. For example, the conversion value is not part of the signature, and the transaction ID can be used repeatedly (hoping that whoever’s on the other side doesn’t store all historical transaction IDs forever). The only real solution for this is sending the postback to its real owner – the advertiser.
- Manipulating Apple with a wrong attribution decision at the device level: The examples discussed throughout will illustrate such cases.
We can say for certain that SKAdNetwork attribution protocol provides limited data for either measurement or optimization, offering only source app and campaign ID.
Device interaction time indications are also unavailable. These are critical for measuring time frames between key events – mainly click time and install time. Without these indications, normal user behavioral trends (very difficult to emulate at scale with bots) can’t be constructed – eliminating indication of abnormal behavior.
But, as we try to identify potential loopholes that might be exploited for fraud, we approached the issue from another direction.
Imitating potential fraudulent behavior can help us construct the fraudster’s manipulation path, and in-turn allow us to analyze and identify potential weaknesses as we try to protect our advertisers from such fraud.
Fake install farming
Anyone with one or more devices can click, download, engage with apps, and reset their device ID to make it seem as though it is a different device. This, in a nutshell, is a device farm. Once a VPN solution is introduced the fraudster’s IP address can also be altered or hidden.
Can this be carried out with SKAdNetwork?
The short answer is yes.
SKAdNetwork may have eliminated the use of IDFA but a user’s Apple account ID is still used for measurement purposes.
Resetting the Apple account ID is something that can be done programmatically through various tools and services, thus generating multiple fake users from one device is very possible.
Moreover, when using a jailbroken device you also eliminate the need of using a publisher app, as you can generate fake clicks without one.
The SK protocol logs all clicks in an internal device database. With the right technical knowledge, bad actors can easily create a fake app-like environment which connects to the ad-network’s server to attain its unique signature and campaign details.
This fake app environment can then insert the click details into SK’s database – leaving iOS tricked into thinking that the click was delivered by a real app.
![iOS 14 SKAdNetwork attribution fraud](https://massets.appsflyer.com/wp-content/uploads/2021/02/iOS-14-SKAdNetwork-attribution-fraud.png)
Jailbroken devices also give fraudsters the ability to programmatically control the SK timer through this fake app environment, meaning postbacks can be sent within 20 or 30 seconds, rather than the expected 24 hour window.
Since this timer manipulation occurs on the device, at which there’s no device time data to work with, the advertiser cannot tell whether timing was tampered with.
The above manipulations explain that device farms can operate at scale without any ongoing human interaction.
Flooding the gates
Click flooding is meant to “flood” the advertiser with a wave of fake click reports, in the hopes that one of these clicks will be somehow associated to either an organic install (when a user downloads the app on their own), or a non-organic install (a click that is artificially injected after the user has viewed an ad from another publisher).
SKAdNetwork attributes credit for installs that occurred through the Apple App Store. When a user views an ad on a publisher’s app and clicks it, the app’s in-app store page will appear within the publisher’s app.
This App Store page view is registered as a click by the SK protocol.
Once the user downloads the app from the App store page and launches it, the install will be attributed to the publisher’s app.
How can this flow be manipulated?
Our tests show that publishers can simply trigger the advertiser’s App Store page to appear without a user’s ad click, thus creating a fake click report.
The app store page can be triggered repeatedly without a single ad click, creating a similar effect to click flooding. This is very similar to common manipulations where ad impressions are falsely reported as clicks.
How is this affected by Apple’s recent view-through addition?
With Apple’s latest addition of view-through to the SK protocol, flooding might even become easier. A click-through flow can theoretically be validated by Apple by checking the entire flow (click→ App Store → Install).
However, with view-through attribution, as we eliminate the click from the equation, this flow validation cannot occur. Anyone can theoretically claim to deliver impressions, hoping for installs to be attributed.
With SKAdNetwork, publishers can determine an impression’s start and end times. While Apple’s official statement says that this time frame should be over 3 seconds, It is not enforced in any way. This means publishers are free to generate fake impression reports, generate an impression flood, taking advantage of view-through flows.
An even simpler way to take advantage of view-through attribution is using the device database access mentioned above to insert false impression reports – making sure the publisher is always the one to provide the last impression.
This opens the possibility of creating either click flooding or impression flooding, by programmatically triggering click or impression reports.
While the App Store page pop up is hoping to initiate an actual install from the user who sees the page, all other manipulations simply hope to steal the credit for an organic install that had nothing to do with any exposure to an ad or app page.
Our tests show that even installs that take place up to 24 hours post click-report receive attribution credit from SKAdNetwork. Apple’s official documentation actually discusses a 30-day lookback window, increasing the likelihood of such a scheme to be successful.
Malicious source apps like the ones described above can still be identified and treated by Protect360 (AppsFlyer’s fraud protection solution) using different detection methods. The behavior outlined above will still deviate from standard behavioral trends when viewed on a large enough database scale, even within the aggregate nature of SKAdNetwork.
We’re just getting started
As we enter a new era of attribution measurement, we’re very likely just scratching the surface in terms of possible fraud methods and manipulations.
AppsFlyer is working in cooperation with Apple and the ecosystem at large to raise these issues when they occur, as we work hard to maintain a fraud-free environment in this new era of attribution.
As fraud researchers, it’s now our job to continue diving deeper into possible areas of weakness and identify how they might be exploited, so that we continue to adapt and protect our customers.
Stay tuned for more developments.