What is click injection?

How it works

Android historically broadcast system events when an app installation began. A malicious app listening for those broadcasts learned, in real time, that a specific app was being installed on that device.

Knowing which app and knowing the install was seconds from completing, it fired a click for that app. When the install finished, the most recent click belonged to the fraudster, and last-click attribution awarded them the install.

Unlike click spam, this is not a lottery. The fraudster knows the install is happening and wins essentially every time.

The signal that gives it away

Click to install time is the tell, and it is unusually clean.

A genuine journey has a user click an ad, wait for the store page, decide, download and open — typically minutes. Click injection fires a click during the download, so the interval between click and first open is implausibly short: often seconds.

A source whose CTIT distribution has a large spike under about ten seconds is doing this. It is one of the few fraud patterns with an almost unambiguous signature.

Why it declined

The vulnerability was a platform one, and Android closed it. Newer install referrer APIs no longer broadcast the information that made real-time detection possible, and apps require declared permissions for the broadcasts that remain.

It has not disappeared entirely — older devices and older Android versions remain in use, particularly in markets where device replacement cycles are long — but it is a far smaller problem than it was, and the fix came from the platform rather than from detection vendors.

That is the general pattern worth noting: fraud that depends on a platform capability ends when the platform removes it, which is why the fraud landscape shifts rather than shrinking.