How SDK Spoofing Works
An MMP learns about installs and in-app events from its SDK, which sends requests from the app to the MMP's servers. SDK spoofing attacks that channel. Instead of driving real installs, the fraudster sends requests that look like they came from the SDK inside a newly installed app.
The setup usually starts with the real app. The fraudster installs it on a device they control and records the SDK's traffic, often by routing it through a proxy that decrypts HTTPS. That reveals the endpoints, payload fields and the order of calls an install and its events produce. With that template, a script can generate thousands of convincing installs from servers, each with a different device model, OS version and advertising ID.
To get paid, the fraudster pairs each fake install with a click from their own tracking link. The MMP sees a click followed by an install within the attribution window, credits the install to the fraudster's source, and sends a postback to the network. Some schemes add fake purchase or registration events so the traffic passes basic quality checks and qualifies for cost-per-action payouts.
Why SDK Spoofing Is Hard to Spot
Spoofed installs can look clean in a dashboard. The device details are plausible, the click-to-install times are realistic, and there may even be a few events. Unlike click spamming, there is no flood of clicks to notice, and unlike click injection, there is no telltale install-moment click.
What spoofed installs lack is a real user. Retention is near zero after the first day or two, events stop abruptly, and revenue, if any, does not hold up when checked against the store. The trouble is that these signals arrive late, after the network has been paid and the ad platform has learned to buy more of the same traffic.
Detection Signals
Request signing is the most direct defence. The SDK includes a signature computed with a secret built into genuine app builds, and the server rejects or flags requests whose signature is missing or wrong. Fraudsters can still try to extract the secret, so signing is usually combined with other checks.
Network signals help. Installs from data-center IP ranges, hosting providers or Tor exit nodes rarely come from real phones. A mismatch between the click IP and the install IP, especially across countries, points to traffic that did not follow a real user's path. Device data that does not add up, such as an OS version that model never shipped with, is another flag.
Behavioral checks close the gap. Compare each source's day-one retention, event depth and revenue against your baseline. A source with normal install volume and almost no second sessions deserves a closer look.
Preventing SDK Spoofing with Linkrunner
Linkrunner's SDKs support SDK request signing, and Fraud Control includes templates for SDK spoofing and SDK spoofing with IP mismatch. The engine maintains data-center and Tor IP lists that rules can reference. You can write rules in plain English, preview their impact on past traffic before turning them on, and choose to tag matching installs or withhold their postbacks so networks stop optimising toward them. Flagged installs stay in reporting totals, so you can review them and take them up with the partner. Fraud Control is live on every plan. See fraud protection for the full rule library.
What to Do When You Find It
Treat SDK spoofing as a partner problem as well as a technical one. Document the flagged installs, the signals that triggered them and the payouts involved, and raise them with the network or affiliate. Most networks pass the dispute down to the sub-publisher responsible.
Then tighten the setup. Turn on request signing in every app version you ship, make sure old unsigned builds are phased out, and keep postbacks for flagged installs withheld so ad algorithms are not trained on fake users. Recheck the source's numbers a week later: spoofing operations often move to a new sub-publisher ID rather than stopping.