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.

Sep 01 2017

Emotet Trojan Acts as Loader, Spreads Automatically

Since the middle of July, McAfee has observed new updates of the Emotet, a Trojan that was first discovered in 2014. This malware harvests banking credentials. Early variants used Outlook contact harvesting to spread via malicious spam.

The latest variants act as loaders and use several mechanisms to spread over the network and send spam email. They also use techniques to bypass antimalware products and avoid detection. Initial infection vectors are emails containing a link to download a malicious Office document. Once a system is infected, Emotet collects the computer name and running process information, which are encrypted and sent to a control server via a Post request.

Emotet updates itself with the latest version from the server, and attempts to download additional malware, such as Dridex (banking malware). The banking malware is designed to harvest banking credentials by installing a malicious component into the web browser. It also uses evasion techniques such as “atom bombing” to inject malicious code.

The following illustration shows how Emotet works:


The initial infection vector of Emotet is a malicious Office document containing an obfuscated macro that runs a PowerShell script to download the payload.

Additional information can be found here:

Details of our analyzed sample.

The malware uses several mechanisms to stay persistent and undetected. It unpacks itself directly into memory and drops malicious files in the system. Emotet acts as a loader and can enable several modules. During our analysis, we saw the following:

  • Worm module via brute-force attack to spread over the network.
  • Dropping malware.
  • Sending spam with compromised emails to spread around the world.
  • Updating main file to bypass antimalware signatures.

These modules are enabled by the control server and allow the attackers to perform malicious actions on infected machines.

The malware contains an icon that can be identified on infected machines. We saw several updates to the icon during the campaign:

Emotet malware icons.

Once the malware is running, it is unpacked several times into memory. This process allows the malware to bypass antimalware detection before runtime. The following screenshot shows the unpacking process.

Unpacking at runtime.

The malware changes its name to avoid detection once it has infected a system. In this case the malware used certtask.exe. Each infected machine could have a different name.

Emotet uses several mechanisms to stay persistent, allowing it to run after each reboot. It also creates a service to run the malicious file. Early variants created scheduled tasks.

Run key.

Emotet employs a control server to communicate with infected machines and send the stolen credentials:

Control server connection.

The malware updates itself by sending a Post request and showing a 404 error from the server to fool analysts.

A Post request.

The control server address changed throughout the campaign.


Worm module

We found that Emotet uses a worm module to spread on the network. It brute-force attacks an account to break the password and copy itself on a network share.

A brute-force attack. The malware attempts to connect to specific users.


Spam module

Emotet spreads by email from compromised accounts. The attackers can remotely activate the spam module, which dynamically uses the credentials to send email:


Spam module.


Evasion tricks

The sample arrives packed and runs several processes to unpack its content. By tracking the VirtualAlloc API, we can follow the dump of an unpacked version into memory.

Dumping the unpacked executable into memory.

The dumped executable is a file that runs without an import address table to avoid static analysis. All the functions are resolved dynamically when the sample runs.

Dynamic API resolution.

The sample creates a mutex as an infection marker to detect if the machine is already infected.

Creating a mutex to match the filename emo.bin.

The malware uses a different mutex, generated with the filename during execution, to avoid any possible vaccine. The mutex is always the same if the filename does not change.

The following example shows a different mutex name with a different filename:

Creating a mutex to match the filename emoo2.exe.

To detect any debugging, Emotet employs the undocumented function NtSetInformationProcess:

Emotet creates a suspended process to unpack. If the debugger is detected, the malware terminates the suspended process; otherwise it continues the execution and infects the system.



Emotet has evolved to take advantage of several evasions, persistence, and spreading techniques. It also downloads additional malware to harvest banking credentials and take other actions.

The spreading techniques on the local network seem to have come from lessons learned from the WannaCry and (Not)Petya outbreaks to increase the rates of infection. We can expect to see more weaponized lateral movements in the future.

The author thanks @tehsyntx and @_remixed for their help with this analysis.


Indicators of Compromise


  • C:\Windows\System32\<randomnumber>\
  • C:\Windows\System32\tasks\<randomname>
  • C:\Windows\\<randomname>
  • C:\users\<myusers>\appdata\roaming\<random>
  • %appdata%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
  • <Randomname>.LNK. file in the startup folder

Registry keys

  • HKLM\System\CurrentControlSet\Services “RandomNumbers”
  • HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run “RandomNames” with value c:\users\admin\appdata\roaming\<random>\<legitfile>.exe

IP addresses

  • 81.62.54 Canada
  • 106.1.205 Germany
  • 254.40.5 Germany
  • 23.244.244 Germany
  • 160.15.198 Germany
  • 160.178.17 Germany
  • 188.40.189 Germany
  • 86.91.232 Germany
  • 134.140.21 France
  • 196.73.150 France
  • 121.121.72 France
  • 187.103.156 France
  • 210.206.25 France
  • 79.132.214 United Kingdom
  • 110.224.51 Italy
  • 166.175.18 Netherlands
  • 138.200.249 Netherlands
  • 191.233.221 Poland
  • 150.19.63 Thailand
  • 21.183.63 United States
  • 81.128.131 United States
  • 230.145.224 United States
  • 21.113.151 United States
  • 3.75.246 United States
  • 218.156.113 United States
  • 31.0.39 United States
  • 253.164.249 United States
  • 81.212.79 United States
  • 83.223.34 United States
  • 243.126.142 United States
  • 210.245.164 United States
  • 43.168.206 United States
  • 243.159.58
  • 241.222.53


  • 741f04a17426cf07922b5fcc8ea561fb
  • 12c8365a75dd78a4f01abcce80fbabd6
  • 1e8fb9592c540b3d08d6a11625c11f29
  • 9ae00902d729c271587178d1cbc0e22e
  • eb93ca04522bfe16e8c2a96bd43828b4
  • 2c2046617bb3c1d9ad98650bc17100c9
  • 03c66f518dd64e123dd79b68b0eb6a24
  • 6c58a58c0d1d27d35e72579ab7dcdf2e
  • a3227b853fa657cf1a66b4ebed869f5b
  • 56c709681b3c88e22538bcad11c5ebc6
  • a7ae7df15f40aa0698896284cf6b283b
  • 158b0960e5024cd3ded8224bd1674c1f
  • 5f40e4ddf7ecc2b7c1f02f03b5a6f766
  • 1e8fb9592c540b3d08d6a11625c11f29
  • 03c66f518dd64e123dd79b68b0eb6a24
  • a3227b853fa657cf1a66b4ebed869f5b
  • f459a5750fea85db0b21b6fcf6b64687
  • b3745eb2919d1441baf59a1278a1d199

The post Emotet Trojan Acts as Loader, Spreads Automatically 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.