Clicking Bot Applications

Cyber crime, like any crime, has its motives; each malware has its own malicious profit.

Spyware spies on you. Ransomware demands a ransom to decrypt your private digital data. Phishing Malware phishes for your username, password or account numbers. Installation-fraud achieves fake software installations. Ad fraud fraudulently represents online advertisement impressions, clicks, conversion or data events in order to generate financial gain for the developer. And finally, there is Click fraud.

Click fraud (CF) is a type of Ad fraud that abuses online pay-per-click advertising in which an advertiser pays a publisher when the ad is clicked and is big business for developers.

Conservative estimates from the Interactive Advertising Bureau attributes revenue from Ad fraud at 8.2 billion US Dollars, making it a top income generating cybercrime.

Clicking Bot Applications (CBA) use various methods in order to simulate user clicks to generate revenue, what Ads are to be targeted, how the CBAs are controlled by their command and control (C&C) server and how to avoid the detection methods that are commonly used against them.

Although those CBAs are utilized for a fraudulent financial gain at the expense of the advertisers and publishers, some of CBAs’ methods and functionality can easily be utilized for Ransomware, Spyware, and other Malware types.

Zimperium’s core machine learning engine, z9 for Mobile Malware, detects previously unknown malicious applications and zero-day exploits. As a part of the z9 validation of the machine learning detection for malware, several Android Potentially Harmful Applications (PHAs) that were CBAs and part of a Malware Botnet that controls its CBAs activity were found.

My recent CBA research identified several circumstances where the clicks can be identified and by which means. I tried several methods and after changing the CBA’s code, I determined what should be added in order to achieve an efficient CBA result. I also tried other auto clicking methods that can be used, but this post won’t technically specify any additional improvements for CBA activity.

One of the CBA’s methods tried to defraud the Facebook Audience Network. After we, the Zimperium malware team, identified the CBA, we informed the Traffic Quality and Fraud team at Facebook about the malicious apps. We provided the application’s details, the SDK’s account ids and auto clicks we were able to reproduce so Facebook could decide how to react. They promptly removed the apps from the Audience Network and informed us that our research enabled them to find a set of apps that were using this same attack vector. Our research helped confirm the apps were indeed malicious and remove the chances the clicks were from bots and not real users.

Below I provide segments of decompiled-deobfuscated code and Android API references on which you can press the URL link or let a CBA do it for you!

The “Money For Nothing” Malware Network

As a part of our Android defense activity, the Zimperium malware team identified a few APKs classified as a PHAs.

By investigating the PHAs’ referenced file hosted on a cloudfront.net CDN domain, the team managed to find a few other configuration files and a few APKs connected to old Ztorg C&C plugins.

The old Ztorg C&C malicious activity engaged with:

1. Sending premium SMS messages
2. Clickjacking attacks on web pages with WAP billing (by javascript)

The latest malware network adds additional CBA and adware malicious activity:

1. Java script based Ads auto-clicking an Ads auto-subscription features.
2. Dynamic loading of application by the VirtualApp The loaded applications are another Malware. More ads gain bigger revenue.
3. Abusing the Android AccessibilityService for auto-clicking. Abusing the Accessibility Service is the worse type of abuse with respect to auto-clicking. Abusing this service enables the application access to clicking buttons of all applications, including the device settings.
4. Abusing the Android dispatchTouchEvent API for auto-clicking. This is a “lighter” abuse since it’s the clicks are on the CBA’s Ads banners.

In this post will specify the last two auto-clicking methodologies.

The Android API ‘Dispatch Touch Event’ CBAs

For the legitimate use of UI testing and development, the ViewGroup.dispatchTouchEvent allows simulation of a user touch by sending a MotionEvent to the targeted ViewGroup UI component.

A CBA can abuse this and be able to click on its own application UI components, therefore, it can be fraudulently used for clicking on the applications’ own Ads banners.

The Advertisement framework can easily detect this type of fraud per single device by:

1. Observing the different MotionEvent human touch properties like precision, pressure, scaled value of the approximate size of the area being pressed when touched with the finger and few more flags and properties. Constant or random values can be easily be identified.
2. Observing the statistical distribution of the touch event like event time, down time and touching coordinates. Clicking in a frequent or constant rate will be easily identified.
3. Observing the statistical distribution of the different Ad parts that was clicked like icon, title, Sponsored Label, media view, social context, action etc. It is most likely that a user will press the “close” button once in awhile.

The CBA will try to overcome the Advertisement framework by performing the following actions:

1. When the user touches the application UI components, the properties in the last user touch MotionEvent are saved. Those properties will be used in the next fraud click.
2. The click event will be dispatched within a certain configured probability. The last clicking event time is being saved and a second click will be not be dispatched if this amount of time won’t elapsed.
3. The Ad’s UI parts have been chosen with a certain distribution model, including closing the Ad.

A few more central CBA infrastructure features:

• If a certain Ad is no longer available due to the fraud identification, another Ad’s SDK will be selected.
• Which Ads to be fraud with which Ads fallback is a part of the CBA configuration.
• The CBA configuration defines the clicking rates, the minimum time between two clicks, the targeted Ads and their fallback, and whether to be activated as a CBA is given by the C&C server. A default configuration is initially given as well.
• In addition to the Facebook mobile advertising platform, in the CBA Ads SDK configuration list there are AdMob by Google and DoubleClick Ad Exchange by google. More Ads like MobVista, InMobi and the DU Ad platform which belongs to China’s Internet search giant Baidu are aggressively pushed but with no evidence to auto clicking on them.

Let us review the decompiled code of the com.life.read.physical.trian application.

All comments in the code were added by zLabs. Some code was removed to shorten the code snippets.

1. The last user touch motion event properties were previously saved

2. The click event will be dispatched within a certain configured probability

3. The Ads UI parts is been chosen with a certain distribution

1-3 The click event is dispatched within the saved properties and random properties

CBA activation Configuration

CBA Ads Configuration

CBA Ads Fallback

Accessibility Services CBAs

An accessibility service is an Android Service that provides user interface enhancements to assist users with disabilities, or who may temporarily be unable to fully interact with a device.

Accessibility services should only be used to assist users with disabilities in using Android devices and apps. The service grants an app the ability to discover UI widgets displayed on the screen, query the content of these widgets, and interact with them programmatically, all as a means to make Android devices more accessible to users with disabilities.

 

Malware has been using the Accessibility Service Abuse (ASA) for severe Malware attacks like the recent DoubleLocker Ransomware and the Shedun malwares (also known as Kemoge, Shiftybug and Shuanet).

The usage of the Accessibility Service and/or the Draw on Top permissions that allows an app to create windows shown on top of all other apps was defined as the Cloak & Dagger attacks. These attacks together allow a malicious app to completely control the UI feedback loop and take over the device will not be noticeable to the user.

Unlike the previous CBA that required no permission, the Cloak & Dagger (C&D) attacks require the SYSTEM_ALERT_WINDOW (Draw on Top) and BIND_ACCESSIBILITY_SERVICE (Accessibility Service) permissions, but the SYSTEM ALERT WINDOW permission is automatically granted for apps installed from the Play Store.

The abuse of both permissions can maliciously gain some of the worst malware capabilities:

1. Silent installation of application. Since the installation does not need user consent, the application can be God-mode app (with all permissions enabled) or, in other words, it can install a spyware.
2. A very efficient stealthy phishing.
3. Block access to the device by changing the PIN to an attacker-controlled one (and held for ransom)
4. Keystroke recording, including passwords (needs only Accessibility Service permission).

Silent Installation of Application

Let us show how an Android CBA installs another Android application without user consent by abusing the Accessibility Service.

While Ad fraud clicks are noticeable on a device as described in the previous CBA method, installation fraud or traffic fraud cannot be discovered on device, but might be discovered by other server side information based identification.

This post is about the research of the revenue that CBA networks earn, therefore, the applications are likely to install just more Adware or CBAs. Nevertheless, a CBA that has the permissions to commit a C&D attack can become worst than just an Ads fraud clicking because:

1. Android applications can dynamically load unsupervised code by using the VirtualApp framework or any other by other DexClassLoader based technique. This code might be a Ransomware a Spyware or steal passwords.
2. The installed application is without the user consent and with no Google Play Store acceptance, and therefore might be Ransomware or Spyware, steal passwords or become one by dynamically loading unsupervised code like the above.

I found malware that uses auto clicks for application installation, but I would rather display my own proof of concept clean code samples than partly obfuscate reverse-engineered code.

The following example will install an application by doing:

1. Register an AccessibilityService in the manifest for accessibilityservice.AccessibilityService intent filter.
2. Request the Accessibility Service for a “reasonable” reason if it wasn’t granted before.
3. For hiding the installation windows: Cover the screen with a layout using the LayoutParams.TYPE_SYSTEM_ALERT flag.
4. Start the installation activity for an apk local file.
5. Filter on the AccessibilityService for an AccessibilityEvent of the PackageInstallerActivity activity at the android.packageinstaller package
6. Find the install button to be clicked by findAccessibilityNodeInfosByText
7. Auto-Click it with performAction(AccessibilityNodeInfo.ACTION_CLICK)
8. Roll back the covering screen if it was used.

Register a AccessibilityService in the Manifest

Request the Accessibility Service for a “Reasonable” Reason if it wasn’t Granted Before

Hide the Installation Windows in a “Relevant” Content

Start the Installation Activity for an apk Local File

Find the “Install button” and click it

Let us look at the ‘XVideo’ malware that does as the above only without trying to hide the installation activity.

The malware had also implemented some other typical malware features in order to avoid malware detection by the google play:

• All of the application activities named pronclub.* although the application package name is very different.

<application android:name=“org.gro.jp.fjksbxcvbcxnnxlsdtApp” …>

<activity android:name=“com.pronclub.GdetailActivity” />

<activity android:name=“com.pronclub.GwebActivity” />

<activity android:name=“com.pronclub.GpointActivity” />

• The application contains APKs in their assets. the header of the APKs is encoded with rolling XOR. the dex code was loaded dynamically by the DexClassLoader.

DexClassLoader dLoader = new DexClassLoader(str, str2, str4, (ClassLoader) fjksbxcvbcxnnxswdpkff.getFieldfjksbxcvbcxnnxklOjbect(fjksbxcvbcxnnxalldd[3], wrfjksbxcvbcxnnx.get(), fjksbxcvbcxnnxalldd[4]));

The CBA has an accessibility service names “Play decoder++”. The application code name him “auto install service” which indicates on his real function.

<string name=”acc_auto_install_service_name”>[Decoder] Play Decoder++</string>

<service android_label=”@string/acc_auto_install_service_name” android_name=”com.ted.android.service.bni” android_permission=”android.permission.BIND_ACCESSIBILITY_SERVICE”>

Other Fraud Click Methods and Comparison

Click fraud is tricky and coded to evade detection. Let’s take look at some of the methods and parameters one should question when determining if an app is fraudulently clicking outside of user interaction.

1. Can it click outside of the application UI components (Facebook click on WhatsApp)?
2. What application permissions does it require?
3. Does it need to have Root permission or run as system application (an application which is placed under /system/app folder, many times signed by the OS’s platform signature)?
4. Is it noticeable on the device? As before, the information based observations are completed on the server side and does not depend on the clicking method.

When a user clicks on an Android UI component (ViewGroup) the OS or the Ads SDK parameters seen on the device will look like the following output. For example, a user click event produces two MotionsEvent for pressing down and lifting up.

MotionEvent { action=ACTION_DOWN, id[0]=0, x[0]=198.75, y[0]=63.42859, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=18381654, downTime=18381654, deviceId=6, source=0x1002 }

MotionEvent { action=ACTION_UP, id[0]=0, x[0]=198.75, y[0]=63.42859, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=18381742, downTime=18381654, deviceId=6, source=0x1002 }

Let us define on-device-detection: whether the fraud click can be noticed by observing the above MotionEvent parameters.

 

The Android API ‘Dispatch Touch Event:

As previously presented here.

1. Can click only the application’s UI components.
2. Does not need any permission to run.
3. Committing the action doesn’t need root nor to run as a system application.

If done as in the above decompiled com.life.read.physical.trian code, few parameters extradite the fraud.

Firstly, the source=0x1002, secondly the ‘toolType[0]=TOOL_TYPE_UNKNOWN’.

Saving references and recycling a few Android UI components like MotionEvent.PointerCoords, MotionEvent.PointerProperties, setting a few more “sources” and using reflection in few places over the private API will gain a result that apparently cannot be noticed on a device!

And then, if used wisely, there is money for nothing.

Accessibility Service abuse:

As previously presented here.

1. Can click on other components.
2. Need the BIND_ACCESSIBILITY_SERVICE permission. Starting an accessibility service is triggered exclusively by the user explicitly turning the service on in device settings.
3. Does not need root access nor run as system application.

The click event can be noticed on device as the ‘toolType[0]=TOOL_TYPE_UNKNOWN’ parameter extradite the fraud.

While Ads fraud can notice Ads clicking fraud on device, installation fraud or traffic are not to be discovered on device, but might be discovered by other server side information based identification.

Using Android lower level layer Input Pipeline:

The Android input subsystem nominally consists of an event pipeline that traverses multiple layers of the system. A shell user can use the “input” binary to create touch events.

1. Can click on other components.
2. Does not need any permission to run.
3. Needs a Shell User permission which means that a Root permission is “enough”

The click event can be noticed on device as the ‘toolType[0]=TOOL_TYPE_UNKNOWN’ parameters extradite the fraud.

Reflection over the “InputManager” class injectInputEvent method:

Using Java’s Reflection API, over the InputManager.

1. Can click on application components. By running in shell user can click on other components.
2. Does not need any permission to run.
3. Might need to be running as system application, depends on the OS level and the device.

The click event can be noticed on device as the ‘toolType[0]=TOOL_TYPE_UNKNOWN’ parameter that extradites the fraud.

There are other ways for committing Ad fraud, installation fraud and data traffic fraud that were not mentioned like:

1. Tempering the Ads SDKs
2. Reverse engineering the Ads SDKs and sending fake events using reflection.
3. Hooking the Ad’s SDKs or the System UI.

Conclusions

CBAs are becoming increasingly sophisticated. App developers with access to the latest developer kits can be very creative in order to game the system. Given all of the variables, CBAs might evade detection entirely unless there is a more clever and real-time method to rid them from our devices.

In the future, leading Ad providers will demand a defensive mechanism or insurance against bot and click fraud so they aren’t paying out money as a result of fraud. App developers will need to provide comprehensive protection like zIAP™ to detect fraud and mobile malware in real-time. If such a protection isn’t provided, it is most likely that an untrustworthy developer or unprotected device will earn less revenue per click.

I hope that you benefitted from our examples and documented case studies on Click Fraud. zLabs performs this type of research on apps, mobile operating systems, and hardware to deliver the best mobile security products and services to protect your personal and corporate information.

If you have a specific question or would like to provide feedback to zLabs or any other team, please use our Contact Us page to initiate a query.

I would like to thank all the zLabs researchers, especially Matteo Favaro (@fvrmatteo) for the above research.

I hope that you enjoyed your reading. You can share it if you like it, or let the CBA do it for you!