Category: Mobile Security

Sep 12 2017

Android Click-Fraud App Repurposed as DDoS Botnet

The McAfee Mobile Research Team tracks the behavior of Android click-fraud apps. We have detected multiple implementations, including recent examples on Google Play in 2016 and Clicker.BN last month. These threats are characterized by a common behavior: They appear innocuous but in the background they perform HTTP requests (simulating clicks) on paid “advertainment” to make money for a specific developer.

This behavior means that a URL is permanently requested via HTTP. Hypothetically, if the target and frequency of that request were modified, we could classify it as a DDoS attack. After all, the app uses the same main malware functionality and botnet infrastructure. From ad fraud to DDoS is only one step—and that is what some variants of Clicker.BN have taken. We have now seen click-fraud Android Trojans repurposed to perform DDoS attacks.

Most of the control servers of this Android/Clicker botnet—aka WireX—were taken down in late August.

The apps that perform click-fraud and those that launch DDoS attacks have much in common: the technique to configure headers from the control server, the domains axclick[.]store and ww[56]8[.] (which have been taken down though others remain active), how they keep control server parameters updated in the local cache, and how the target server performs each HTTP request without loading cache data. They are share methods of obfuscation, packing strategies, and methodology for publishing on Google Play.

The apps do have differences, however. The control server subdomain and GET methods vary, as well as the delimiters used to split the received parameters and the order and data of received parameters:

  • Click-fraud components receive:
    • Target URL
    • JavaScript function (to simulate mouse-over clicks)
    • User agent
    • Google Play package
  • DDoS components receive:
    • Target URL
    • User agent
    • HTTP referrer (same as target URL in our tests)

The DDoS variants put the traffic generation in a loop to fully complete each HTTP request many times:

DDoS authors increased the frequency of the HTTP requests to 100 per minute. (Click-fraud implementations send a request each 55 seconds using same code structure.)

Other DDoS variants perform a UDP flood attack on the target, based on data received from the control server (host and port) and implemented as follows:

The previous thread (C1343a) is executed 50 times by the following method (m7240a), which is invoked after loading the parameters from the control server. These are refreshed every 50, 55, or 60 seconds (depending on the variant).

All variants of this threat use an uncommon method to receive and parse parameters from the control server: They arrive inside the title tag of an HTML file, and vary based on a key string used to parse the parameters. We discussed this in our analysis of Clicker.BN.

We mentioned some other curiosities in our Clicker.BN post. The delimiter strings look a bit like anagrams: “WireX” comes from the string “snewxwri.” Early Clicker.BN variants used the delimiter “eindoejy,” which could represent “I enjoyed” or “die enjoy.” More delimiters are present in other variants of this threat.


Click fraud in 2017 could cost US$16 billion, according to one source. DDoS attacks have their own underground market. Moving from one mobile threat to another is not new. We have seen Android ransomware switch to banking Trojans (in 2016) and premium SMS Trojans move to wireless application protocol billing.

Malware authors pursue profits with different strategies, taking advantage of already developed infrastructure. In this case, Android/Clicker.BN created a mobile botnet and distributed the infecting vector on Google Play, repackaging the threat to look like a clean app and widely distributing it across the globe. The authors modified this malware only a little bit to launch the massive DDoS attack known as WireX.

McAfee Mobile Security detects this threat as Android/Clicker.BN!Gen and prevents its execution. To further protect yourself against malicious apps, use only legitimate app stores, and pay attention to suspicious traits such as nonsense names, missing descriptions, and poor user reviews. Also, verify that the app’s request for permissions are related to its functionality. Be wary when apps request device administration API access, which is usually requested only by security apps, antimalware, mobile device management, or corporate email clients. Most apps and games will never ask for device admin rights.

The post Android Click-Fraud App Repurposed as DDoS Botnet appeared first on McAfee Blogs.

Aug 28 2017

Android Banking Trojan MoqHao Spreading via SMS Phishing in South Korea

Last month, a number of users started posting on South Korean sites screenshots of suspicious SMS messages phishing texts (also known as smishing) to lure them into clicking on shortened URLs. For example, the following message asks the user to click on the link to check if a private picture has been leaked:

Figure 1: Text in Korean: “Why is your picture here? Click to find out.” Source: Naver.

Another example of this ongoing phishing campaign is the following text message:

Figure 2: “You are in the news! Please check.” Source: Naver.

When the victim clicks on the shortened URL using an Android device, a JavaScript script on the web server checks the user agent of the browser and shows an alert message asking to update Chrome to a new version, which is in fact a malicious fake Chrome Android app:

Figure 3: Fake alert message: “A new version of Chrome has been released with enhanced features. Please use it after updating.”

If the URL is accessed by any other device (such as an iPad), the web server redirects the user to a security page of Naver, a popular search engine and portal site in South Korea.

This malware, which McAfee Labs has named Android/MoqHao, has many capabilities:

  • Sends phishing SMS messages to contacts listed in the infected device.
  • Leaks sensitive information, such as received SMS messages, to a remote server.
  • Installs Android apps provided by the control server.
  • Executes remote commands from the control server and returns results.
  • Attempts to gather sensitive information via a local Google phishing website.

Technical analysis

When the downloaded APK is installed by the victim—who must ignore suspicious permissions requested by the app such as “directly call phone numbers,” “read your contacts,” or “read your text messages”—Android/MoqHao attempts to achieve persistence by asking every second for device administrator privileges. Once on board, a fake icon briefly appears on the home screen before is hidden by the malware:

Figure 4: Legitimate and fake (a little bigger) Chrome icons on the home screen.

After hiding the malicious app, Android/MoqHao Base64 decodes bin file in the asset folder of the APK and dynamically loads the decoded DEX. Inside the loaded classes are malicious behaviors that compromise the victim’s device.

First, Android/MoqHao dynamically registers a broadcast receiver for various system events such as new package install, screen state, SMS messages, and so on. This broadcast receiver spies on the device and sends device status information to the control server.

Next, Android/MoqHao connects to the first-stage remote server. The IP for second-stage control server communication is dynamically retrieved from the user profile page of Chinese search engine Baidu:

Figure 5: Control (C&C) server IP address and port retrieval process.

The following Baidu user profiles are known to have control server IP and port numbers hidden in the profile description:

  • haoxingfu88: Haoxingfu (“so happy” in Chinese, 好幸福)
  • ceshi9875: Ceshi (“test,” 测试)
  • womenhao183527: Hao (“good,” 好)
  • dajiahao188384: Dajiahao (“hello everyone,” 大家好)

Figure 6: Baidu profile pages known to store control server IP and port information.

When connected to the second-stage server, Android/MoqHao sends a “hello” message containing the following device information:

  • UUID
  • Device ID (IMEI)
  • Android version
  • Device product name, build ID string
  • Whether the device is rooted
  • SIM status
  • Phone number
  • Registered accounts

The following information is periodically sent to the server with message type “state” after phone state changes and related events:

  • Network operator name
  • Network type (LTE, GPRS)
  • MAC address
  • Current battery level
  • Wi-Fi signal level
  • Is device admin?
  • Is current package ignoring battery optimization?
  • Is screen off?
  • Ringer mode

When the device receives a new SMS message, the contents and sender address are sent to the control server. If a specially formatted SMS message is received, Android/MoqHao parses it and uses the contents for special purposes such as setting the SMS forwarding address “fs” field or the “account” field, which are used to access the Baidu profile page and dynamically extract the control server IP address and port number.

After Android/MoqHao is successfully installed and has connected to the control server, the malware waits for additional commands.

Fake updates to Korean banking apps

Android/MoqHao checks whether major Korean bank apps are installed and downloads relevant fake or Trojanized versions from the control server. We saw similar functionality in an Android banking Trojan distributed via smishing that targeted customers of Korean banks in June 2013 but, unlike Android/MoqHao, the malware from 2013 carried the phishing apps inside the APK file instead of downloading them.

After the fake or Trojanized banking apps are downloaded, an alert dialog tells the victim that the new version is available and that the app needs to be updated:

Figure 7: Alert dialog: “A new version has been released. Please use after reinstallation.”

Once the malicious app is installed, it deletes the legitimate app. The malware checks for the following apps:

  • kbstar.kbbank
  • ibk.neobanking
  • sc.danb.scbankapp
  • shinhan.sbanking
  • smart
  • epost.psf.sdsi
  • kftc.kjbsmb
  • smg.spbs

During our analysis of this threat, when Android/MoqHao requests the download of a specific fake or Trojanized banking app, the control server responds with an error. Affected users in South Korea have not reported downloads or attempted installation of additional APK files. This suggest that the fake update functionality is probably not implemented or is at least not currently used by the malware authors.

Local HTTP server serving phishing website

Unlike Android banking Trojans that use WebViews to load phishing URLs or display overlay screens to obtain banking credentials, Android/MoqHao includes java-httpserver to host a phishing page that opens in the default browser once the user clicks on the fake alert message:

Figure 8: Alert message: “Your Google identity is at risk. Please use it after you certify yourself.”

The phishing page asks the victim to submit name and birthday of the Google account. This is sent to the local HTTP server by POST. Then the local server sends the stolen information to the control server.

Control server communication

Android/MoqHao communicates with the control server by opening a WebSocket and sending JSON-RPC calls back and forth. Both the malware and control server implement RPC functions of their own. Commands implemented in Android/MoqHao:

Figure 9: Client commands.

The control server appears to implement the following RPC functions:

Figure 10: Server commands.


The first version of Android/MoqHao that we have seen appeared in January. It seems to be a test version of the payload (encoded DEX in assets folder) because:

  • The APK file has no resources (such as the Chrome icon or specific strings).
  • The package name is
  • The label of the app is “Test.”

In February an updated version included the dropper and persistence functionality. However, this also seems to be a test version of the dropper component of the malware because:

  • The main package of the app is com.example.
  • The file activity_main.xml inside the APK is the default with the string “Hello World!”

In March another test version used the app name 바이러스 테스트 (Virus Test) and some functionality (for example, startService) was implemented in a native library. The first variant of the current version, described in our analysis, appeared in May and was actively distributed during the past two months.

Figure 11: Android/MoqHao evolution.

Connection with DNS tampering campaign in May 2015

In May 2015 users in South Korea reported a phishing message appearing in the default web browser when they attempted to access the Internet. Blogger nopsled confirmed that users saw the notification because the routers of the victims were hacked (via DNS redirection) due to poor configuration (such as a default user ID and password). The phishing message is very similar to those used to spread Android/MoqHao, pretending to be a new Chrome version and asking the user to update it:

Figure 12: Phishing message from 2015: “The latest version of chrome has been released. Please use it after update.” Source: nopsled.

The Android malware from May 2015 and Android/MoqHao have completely different code bases but they share some similar behaviors and functionality:

  • Extracting the control server’s IP from Chinese websites (qzone and Baidu) by parsing a specific field in the HTML code.
  • Using the same phishing message to trick users into installing a fake banking app.
  • Using similar hidden folders in the SD card to store the downloaded fake banking apps.
  • The same log messages.

The similarities between the 2015 and 2017 phishing campaigns suggests the same cybercriminals, who have shifted from DNS redirection attacks to a smishing campaign. The attackers are still targeting Chrome and getting the control server from a dynamic webpage while changing the code base of the initial dropper component as well as the dynamically loaded payload.


The smishing campaign currently targeting South Korean users shows that phishing SMS messages are still a popular vector for Android malware. This fake Chrome APK distributed via SMS messages shows that Android/MoqHao is a threat that has been in development since early this year. Similar campaigns from 2015 suggest that they are the work of an organized cybercriminal group.

To protect yourselves from this threat, employ security software on your mobile device and do not trust applications downloaded from unknown sources. McAfee Mobile Security detects this threat as Android/MoqHao and alerts mobile users if it is present, while protecting them from any data loss. For more information about McAfee Mobile Security, visit

The post Android Banking Trojan MoqHao Spreading via SMS Phishing in South Korea appeared first on McAfee Blogs.

Aug 24 2017

Android Click-Fraud Apps Briefly Return to Google Play

Click-fraud apps frequently appear on Google Play and third-party markets. They are sometimes hard to identify because the malicious behavior that simulates clicks is similar to the behavior of many legitimate applications (using common API calls and permissions). Further, part of the malicious code does not reside in the original malware and comes from a control server. Using special methods to perform the clicking allows the attackers to decide when and how pursue their fraud.

The McAfee Mobile Malware Research Team recently found on Google Play a group of Android/Clickers published by the developer “TubeMate 2.2.9 SnapTube YouTube Downloader J.” Five apps were updated on Google Play on August 4 and were removed a few days later, along with the developer profile.

By checking “” on GooglePlay we saw something suspicious in this application: a nonsense name, no description, and poorly reviewed. Of course, those traits do not guarantee an app is malicious, but this lineup should serve as a warning for Android users looking for new apps.

Analyzing and reverse engineering this sample shows us a DeviceAdminReceiver class that connects to a hardcoded URL to obtain parameters that indicate how and where to perform click-fraud activities:

This function is part of a service initiated by a receiver related to DeviceAdmin.

Once the URL is requested, the control server returns an HTML page with the parameters in an uncommon way—inside the title tag, as we see in the following:

All the parameters are in one line, but the malware interprets them using the string “eindoejy” to separate them, obtaining the target URL, JavaScript functions to perform clicks, HTTP headers used in the fraudulent HTTP request, and another Google Play package to monetize the clicks in the abused ad network. We thought that string “eindoejy” could be an anagram of “I enjoyed” or “die enjoy,” but we found other variants in which the word used to split the parameters is different.

Once installed, Android/Clicker.BN adds an icon to the main menu that is not related to the downloaded app from Google Play. The new icon appears to be a system utility. Some examples of the icons loaded by the malware:

When Android/Clicker.BN executes, it requests device administration privileges:

Some of the apps can access YouTube inside a WebView and list trending channels, others lock and blacken the screen, and others crash the UI while in the background running click fraud—which not only harms advertisers and publishers, but also generates malicious traffic on infected devices, impacts battery and overall usage performance, and opens the door to new malicious payloads.

McAfee Mobile Security detects this threat as Android/Clicker.BN!Gen and prevents its execution. To further protect yourself against malicious apps, use only legitimate app stores, and pay attention to suspicious traits such as nonsense names, missing descriptions, and poor reviews. Also verify that the app’s request for permissions are related to its functionality. Be wary when apps request device administration API access, which is usually requested only by security apps, antimalware, mobile device management, or corporate email clients. Most apps and games will never ask for device admin rights.

SHA-256 hashes:

  • b212cb284f6aba06599877ab49c1e0373909d65bd6f3c03f01d8c0e3d88dc85a
  • f309ab9ecd2fb4895ba8eca873976e124817b1d8acfc553aa91798b6e82d79ea
  • d642e69a53cba9b7c2a612173f9b410a6b1ac055ed575ad8019b263a5edaaeaf
  • 50247e85ecb6452aa847a572ca04ab310cf8e9288520f824d13ebcc207be7c13

The post Android Click-Fraud Apps Briefly Return to Google Play appeared first on McAfee Blogs.

Aug 14 2017

Smishing Campaign Steals Banking Credentials in U.S.

The McAfee Mobile Research team recently found an active smishing campaign, using SMS messages, that targets online banking users in the United States. The messages attempt to scare victims with a notice that the bank account will be soon closed and that the user must immediately click a malicious URL:

Figure 1: Phishing SMS message.

The structure of the message—with the fields “FRM” and “MSG”—is very similar to the smishing campaign that we saw at the end of July 2016 that targeted iOS users. That campaign attempted to steal Apple account credentials. Instead of using shortened URLs that allow us to track the number of clicks and the creation date of the URL, however, this campaign uses a nonfunctional URL that contains the name of the financial institution to appear less suspicious.

Fake customer identification program

Once the user clicks on that URL, it is redirected to a hacked site that appears to be the real bank’s. The page asks the user to verify identity via its fake customer identification program (CIP) and threatens to inactivate the account and refuse transactions until the identity is confirmed:

Figure 2: Fake customer identification program.

Once the user clicks “Message Received,” the next step is to enter username and password:

Figure 3: Phishing website asking for mobile banking credentials.

Cybercriminals know that a username and password are not enough to get complete access to a victim’s bank account, so they ask for additional sensitive information such as social security number, card number, and even ATM PIN. The site promises that the card will be unlocked once the information is provided:

Figure 4: Phishing web page asking additional banking and sensitive information.

Stealing the second factor of authentication

The final step in this phishing scheme is to pass through a second layer of security by asking the victim to provide a unique access code that the financial institution sends to the user via SMS when accessing certain banking services:

Figure 5: Phishing web page asking for the key to second-factor authentication.

The request for the second factor of authentication allows the cybercriminals to access the victim’s bank account. When the victim clicks on “Confirm my identity,” the access code is captured and the browser is redirected to the legitimate website of the financial institution, making the user believe that the fake CIP was completed successfully, when in fact this sensitive and banking information was only successfully stolen from the victim.

Cybercriminals know that the weakest link in the security chain is always the user, so they constantly attempt to take advantage by running smishing and other campaigns to steal as much sensitive information as possible and fraudulently access victims’ accounts. Looking at the effects of previous smishing campaigns, we see that attackers can target any type of user account as long as they can gain unauthorized access. To protect yourselves from this and similar threats, always suspect unwanted SMS messages or calls from unknown numbers, avoid clicking suspicious links, and think twice before providing sensitive and private information to anyone.

The post Smishing Campaign Steals Banking Credentials in U.S. appeared first on McAfee Blogs.