Category: McAfee Labs

Sep 21 2017

Microsoft Kills Potential Remote Code Execution Vulnerability in Office (CVE-2017-8630)

Recently the McAfee IPS Research Team informed Microsoft about a potential remote code execution vulnerability in Office 2016 that McAfee discovered in March. Microsoft released a patch for this vulnerability this week with CVE-2017-8630. In this post, we will briefly discuss the vulnerability and its exploitability.

The Problem

While auditing PowerPoint, we came across an interesting application crash. The stack trace looked like this:

When we disassembled the crash point we noticed something interesting.

We saw the access violation occurred at address 0x6631508d. And at address 0x66315090 we noticed a call instruction. From these instructions it appeared the code was trying to call a virtual function from the vtable of an object. To make sure, we quickly enabled a page heap for PowerPoint and tried to reproduce the issue.

The page heap made it clear that the issue was a dangling pointer, a “use after free” case. The preceding screenshot shows that the object being accessed was already free. Although we identified the issue while examining PowerPoint, digging further reveals the issue lies in some Office 2016 shared functionality. The problem affects not only PowerPoint, but other applications as well. On September 12 Microsoft published a patch confirming that Office 2016 (32-bit and 64-bit editions) is affected by this problem.

Triggering the Condition

This use-after-free condition is not easy to trigger. When we open the proof-of-concept file in PowerPoint, several pop-up windows appear. We need to choose a specific set of options to exploit the vulnerability. The time gap between choosing the options also matters.

After several trials, we noticed the object is freed when we suppress the first pop-up and select OK. The object reuse happens when selecting the Repair option in the second window. This sequence is very helpful when we move to exploit this vulnerability.


Our exploitation strategy was the same as for any other use-after-free vulnerability. However, due to the absence of an interactive engine in Office, preparing the memory layout for the exploitation was challenging. In this case we used an ActiveX object to spray office memory and set up the desired memory layout. Two excellent papers explain how to prepare a desired memory layout to exploit Office.

These papers discuss the technique mostly with Word. However, we ported the same technique to PowerPoint. The following diagram shows the exploitation strategy at a glance:

Preparing the Memory Layout

Our first step in preparing the memory layout is to make sure that controlled data is present at known addresses, such as 0x0a0a0a0a and 0x0c0c0c0c.

The preceding screen shows how to use heap spray to place our controlled data at a predictable address. Address 0x0a0a0a0a has the data 0xdebadeba and some no-operation slides. To be more specific, for exploitation we need an address that we control at 0x0a0a0a0a + 0x8.

The next challenge is to create a fake object in a PowerPoint process of the same size as our object. To make sure we can claim the same freed heap block for our fake object, we must spray the memory several times so that the heap manager forcefully places the fake object where the real object was situated. We must spray the memory with same size multiple times using the pattern 0x0a0a0a0a. Thus when the virtual function is called using the object under our control, it will dereference the value from our heap spray (as we performed in last section) at the address 0x0a0a0a0a + 0x8.

So far, we have not done anything to the PowerPoint file that triggers the use-after-free vulnerability. We have just set the stage on which we will perform the exploitation. Once we have everything in place, we carefully port the heap-spraying code to the open XML file, which triggers the use after free.

The preceding screen shows, once everything is in right place, the register ecx pointing to the fake object. When it is dereferenced, we get a pointer to the fake vtable in eax.

McAfee highly recommends that Office 2016 users apply the patch shipped by Microsoft this month. This vulnerability resides in some shared features and can be exploited through different Office 2016 products. McAfee Network Security Platform IPS can catch some exploits with the help of Signature 0x45217b00.

The author thanks Bing Sun for his help with this post.

The post Microsoft Kills Potential Remote Code Execution Vulnerability in Office (CVE-2017-8630) appeared first on McAfee Blogs.

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 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.