Behind the Scenes in the War on Fraud: CTCT and Click Injection
4 Min. Read 660Reads

Behind the Scenes in the War on Fraud: CTCT and the Battle Against Click Hijacking

Shani Rosenfelder Jan 08, 2018

Mobile ad fraud was the hottest topic in the mobile marketing space in 2017. We found that app install fraud cost advertisers between $2.2-$2.6 billion worldwide. No small sum.

While the marketing industry has upped its game battling fraud, so too have the bad actors, adapting at increasingly higher speed to anti-fraud methodologies. In 2018, this cat and mouse game will continue, which means we (as in the good guys) need to be extremely dynamic to remain one step ahead.

Everyday, AppsFlyer’s fraud data scientists dive deep into the data, discovering interesting trends and important findings. In this Behind the Scenes in the War on Fraud blog series, we will be sharing insights into what we are seeing as we seek to educate the market about advanced mobile ad fraud.

Our first post will highlight what we’re calling CTCT. You’ve probably heard of CTIT — click to install time. On the same note, CTCT means click to click time — basically the time separating two clicks — specifically, the time between the click before the last click and the last click itself.

CTCT is particularly relevant for a dangerous type of fraud called click hijacking. In this method, a fraudster injects malware into a device, typically through seemingly legitimate apps or apps downloaded from third-party app stores. The malware is then able to detect a real click on a real ad by a real user, immediately triggering a false click in an attempt to hijack the coveted last click position. If successful, the fraudulent click would be attributed, and the fraudster gets paid. Therefore, it’s important to stress that only attribution providers with multi-touch reporting can identify this type of fraud.

Ultimately, click hijacking is another method of attribution fraud, targeting attribution platforms by stealing non-organic installs from legitimate media sources. Don’t confuse it with install hijacking — a far more common type of fraud — which usually steals organic users as its malware detects an app download and then fires a click before the first app launch when the attribution circle closes. 

 Dealing with such fraud is obviously in the details, or in this case, “in the seconds.” After digging through the data, our fraud scientists have recently discovered an interesting finding. To best understand what we’ve found, let’s explore the following graph:If we look at Area #1 in the graph, where the CTCT is extremely short (less than a second), we can see that it makes up the lion’s share of cases. In this very short period, time anomalies are possible. How so? Well, click time is based on a timestamp as it comes out of the endpoint server, which may differ from the actual time when the user clicked on the ad. Sometimes, due to a variety of reasons — namely communication and connectivity issues —a chronological time sequence can be altered.

In the context of CTCT (and not Back to the Future…), this means that the timestamp of a hijacked click can precede the timestamp of the valid click — in which case the bad click would get the attribution (assuming it was the last click) and the valid click would get flagged as fraud.

However, if two clicks occur within Area #2, the second click is fraudulent with near 100% certainty. After all, it is all but impossible to imagine a scenario in which a user clicks on two legitimate ads from two different sources within seconds.

Even if a fraudulent click from click flooding for example enters the fray while meeting the conditions of Area #2, its impact would be marginal. In the sequence below, a valid click would be flagged as fraudulent thinking it is a hijacked click, while the bad click would pass as legit.

This is possible in theory, but it is however highly unlikely that a click from a click flood attack would actually land in this position. Without an actual trigger like in click hijacking, click flooding fraudsters don’t know when a click occurs and just fire at random. But nowadays, advanced fraudsters try to limit their volume of flooding because they know that sending a massive amount of clicks would lead to easy detection. When click flooding is controlled, the odds of randomly hitting the exact time, seconds after a legitimate click, are slim to none.

In this context, it is also important to mention Google Play’s new referrer data, which provides attribution providers with install start time. As stated above, the attribution loop is closed when the app is launched for the first time — not when it is installed on a device — because that is when the attribution SDK is activated for the first time. This leaves an opening for fraudsters to to inject fake clicks triggered by an install in an attempt to become the last click.

While this data from Google gives a significant boost to fighting install hijacking, some argue that it cannot be heralded as the end of click fraud because it does not detect click hijacking.

If you suspect you are subject to a click hijacking attack or want to verify you are in the clear, look for the these patterns in your multi-touch raw data reports.

There are several ways to fight this type of fraud such as pinpointing the highest time anomaly and flagging anything beyond that as fraud (up until several seconds), and examining the device level (after all malware is device-based) to see if it affects other apps.

As we continue to monitor CTCT, we’ll share our insights once we learn more.