Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Mobile Vulnerabilities

  • Zero-Day Alerts

  • Recent Posts

  • Calendar

    August 2015
    S M T W T F S
    « Jul    
  • Email Subscription

  • About Us

    Author Archive - Trend Micro

    2:09 pm (UTC-7)   |    by

    July has been a fairly poor month for Adobe Flash Player security, to say the least. Three separate zero-day vulnerabilities (all courtesy of the Hacking Team dump) have left many people concerned about Flash security, with many (including this blog) calling for it to go away.

    Some sort of reaction from Adobe to improve Flash security was inevitable. The recent version of Flash, version (, includes several additional mitigation techniques. These were developed by Adobe, working together with Google’s Project Zero.

    The new exploit mitigation techniques are:

    • Vector.<*> length validation – adds a length cookie to the Vector buffer. If an exploit overwrites the Vector length, the cookie checking will cause a failure. Because every Flash exploit today uses overwrites the Vector length, this mitigation point makes Flash exploit harder, and can stop even undisclosed zer0-day exploits.
      After adding the length cookie check, an attacker needs two vulnerabilities to carry out an attack –  one to leak the length cookie, and another to overwrite the length. A single vulnerability that can both leak and overwrite this field can also be used, but this kind of vulnerability is rare.
    • Vector.<uint> buffer heap partitioning – this mitigation makes leaking cookies and overwriting the vector length harder. Specific vulnerabilities are now needed instead of generic information leak and overwrite vulnerabilities.
    • stronger randomization for the Flash heap – this mitigation point makes leaking cookies and overwriting the vector length harder, because the heap layout is harder to predict than before.

    These techniques mitigate exploits fairly effectively, as it can decrease the number of exploits using vector length overwrite techniques. However, note that these are exploit mitigation techniques: in effect, it’s a band-aid on any vulnerable code. Other attempts at exploit mitigation (such as that done on Internet Explorer by Microsoft in 2014) have added mitigation techniques and fixed the underlying code. In the IE example, most IE UAF vulnerabilities became NULL pointer dereferences.

    Not all vulnerabilities can be mitigated in this manner. If attackers were able to find a new class of potential Flash vulnerabilities that bypass these steps, we could be back in a situation where similar vulnerabilities appear in relatively close succession. Alternately, it may become the case that each exploit is essentially “from scratch” and does not rely much on what was found

    Not all of these protection techniques apply to all browsers. Vector.<*> length validation is available to other browsers; however the other techniques are not. Users on other browsers are not yet fully protected, although they will be next month.

    Hacking Team, Targeted Attacks, and Flash: Exploits Beyond the Browser

    While these additional mitigation techniques are useful and can reduce the problems that users face, however Flash is now being targeted for exploitation outside of the browser. It is now being embedded into Office documents; this allows many of these defenses to be bypassed.

    Once again, credit for this “discovery” must go to the people over at Hacking Team. Trend Micro has noticed that some of these zero-day vulnerabilities, CVE-2015-5119, has been adopted in targeted attacks. Emails spoofing the Taiwanese government that contain a malicious attachment have been spotted in the wild, as seen below:

    Figure 1. Spoofed email

    At first glance it would appear to be a perfectly ordinary targeted attack email, complete with a malicious email. We believe that this particular sample has links to the PLEAD campaign which we found last year. In addition, we believe that it can now target 64-bit versions of Windows as well as Mac OS X:

    Figure 2. Windows x64/OS X

    However, what is more interesting is these malicious attachments do not target Microsoft Office vulnerabilities at all. These Office documents contain an embedded Flash file which contains an exploit. If this exploit is successful, it is then used to download and run the actual malware payload.

    Figure 3. Successful exploit with an Internet Explorer process (Click to enlarge)

    Builder tools

    How was this attack carried out? The attackers appear to have been inspired by the Hacking Team, which used a very similar method. Based on correspondence and files from the Hacking Team leak, we learned that the attackers used automated builders to help automate their attacks. The following diagram shows how this builder was actually used:

    Figure 4. Builder usage

    The attackers would provide a “clean” Office document they would use for the attack, the Flash exploit, and the actual malware payload. The builder would create the documents with embedded Flash files, as well as the files that need to be uploaded to a malicious or compromised server of the attacker’s choosing.

    There is one key difference in how the attacks we encountered and how the Hacking Team designed their attacks. The files we saw had the Flash exploit embedded directly. The Hacking Team builder embeds a Flash file which downloads a separate Flash exploit. This has the advantage of not placing any exploit code inside the Flash file which may be detected.

    While the Flash files and the payload do not have to be in the same directory, the builder is designed to place them in the same location.

    The builder is also designed to help make detection and analysis of the malware used more difficult:

    • Network traffic uses HTTPS to encrypt its traffic, making detection by network security solutions such as Deep Discovery more difficult.
    • A random 4-byte key and the XOR function is used to encrypt the malware used.

    Best practices

    A key part of Flash-related best practices to date has been to keep it up to date and use click-to-play in browsers (or to disable it entirely). However, these controls only work with attacks that use Flash via the browser. Solutions that use Flash via Microsoft Office would not be affected, so users can be affected even if they think they are “safe”.

    Security-conscious users should consider completely disabling Flash on their systems, and uninstalling it if possible. Windows users may also opt to use kill bits to disable Flash from running on their systems at all.


    Analysis and data by Brooks Li (Threats Analyst) and Feike Hacquebord (Senior Threat Researcher)

    Zero-day exploits continued to be used in targeted attacks because they are effective, given that software vendors have yet to create patches for them. Throughout our on-going investigation and monitoring of a targeted attack campaign, Operation Pawn Storm, we found suspicious URLs that hosted a newly discovered zero-day exploit in Java. This is the first time in nearly two years that a new Java zero-day vulnerability was reported.

    Note that this zero-day exploit is NOT part of the recent slew of vulnerabilities related to the Hacking Team leak. The group behind Operation Pawn Storm is using the Java zero-day exploit as part of their campaign.

    The said URLs hosting the new Java zero-day exploit are similar to the URLs seen in the attack launched by the threat actors behind Pawn Storm that targeted North Atlantic Treaty Organization (NATO) members and White House last April 2015.  However, at that time, these URLs were not hosting the said exploit yet. Pawn Storm also targeted other nation-state organizations using political events and meetings such as the Asia-Pacific Economic Cooperation (APEC) Forum and the Middle East Homeland Security Summit 2014 as part of its social engineering tactics.  Media and defense industries were other entities targeted by this APT campaign apart from military and government.

    We are able to detect this zero-day exploit through feedback from the Trend Micro™ Smart Protection Network™. Email messages targeting a certain armed forces of a NATO country and a US defense organization contained these malicious URLs where this Java exploit is hosted. Currently, this vulnerability is still not patched by Oracle. Based on our investigation, the latest Java version is affected. Older versions, Java 1.6 and 1.7 are not affected by this zero-day exploit. We already notified Oracle and we’re collaborating with their security team regarding this threat. We will update this blog entry as new information about this threat is found.  Note that this entry serves as a warning for a possible zero-day attack.

    Once successfully exploited, it executes arbitrary code on the default Java settings thus compromising the security of the system. Trend Micro detects the exploit code as JAVA_DLOADR.EFD. The file which Trend Micro detects as TROJ_DROPPR.CXC drops the payload, TSPY_FAKEMS.C to the login user folder.

    Trend Micro is already able to protect users against this threat without any necessary updates. The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can be used to detect this threat by its behavior. The Browser Exploit Prevention feature in the Endpoint Security in Trend Micro™ Smart Protection Suite detects the exploit once the user accesses the URL that hosted it. Our Browser Exploit Prevention detects user systems against exploits targeting browsers or related plugins.

    Vulnerability protection in Trend Micro Deep Security protects user systems from threats that may leverage this vulnerability with the following DPI rule:

    • 1006857 – Oracle Java SE Remote Code Execution Vulnerability

    We also recommend users to disable Java in browsers if installed due to an application. For more tips on how to minimize the risks of using Java, you can read our entry, How to Use Java-If You Must.

    Other related posts to Operation Pawn Storm can be found here:

    With Additional analysis by Peter Pi, Jack Tang and Weimin Wu. 

    Update as of July 12, 2015, 6:39 PM PDT (UTC-7)

    We update to clarify a technical detail about the targets and to add Trend Micro Deep Security solution.

    Below are the SHA1 hashes related to this threat:

    • b4a515ef9de037f18d96b9b0e48271180f5725b7
    • 21835aafe6d46840bb697e8b0d4aac06dec44f5b

    Update as of July 14, 2015 7:40 PM PDT (UTC-7)

    This vulnerability has been patched by Oracle as part of their July 2015 Critical Patch Update. We recommend that affected users update their Java software as soon as possible. It has also been assigned a CVE identifier, CVE-2015-2590.


    Recently, researchers announced that a vulnerability in Samsung Android devices had been found which allowed attackers to run malicious code on vulnerable devices if they became the targets of a man-in-the-middle attack.

    In this post we will explain how this vulnerability works, and what can users do to protect themselves.

    The Vulnerability

    The stock Android keyboard on these affected Samsung devices includes some features based on the Swiftkey SDK. To implement these features, it downloads files that are specific to each keyboard language, as seen below:

    Figure 1. Downloaded keyboard file

    These files are downloaded whenever the language for the device is set up, such as when it is turned on for the first time, or after a factory data reset (where all data and configuration is deleted). This narrows down the window of vulnerability because the files will no longer need to be downloaded after the language is set, unless the user decides to update and download a language pack.
    The files contain important information necessary to each keyboard language. These include character sets and punctuation rules. However, note that the files are downloaded via HTTP, not HTTPS. (We just recently discussed why using HTTPS is a good idea.) This means that an attacker would be able to replace these files if the attacker already had the capability to carry out a man-in-the-middle attack. (There are some countermeasures designed to help defend against this attack. However, these can be bypassed without much difficulty by an attacker that can already carry out MITM attacks.)

    By itself, this would not necessarily be a problem. However, the downloaded files are saved (and were created with) permissions for the system user, which is analogous to the root and Administrator users on Linux and Windows devices. This user has elevated privileges, which means that any code that is downloaded also runs with these elevated privileges.

    The combination results in a rather clever attack: the attacker carries out a man-in-the-middle attack that replaces the files downloaded by the keyboard. The replacement files have been specially crafted so that once processed by the keyboard app, aribitrary code of the attacker’s choosing can be run on the phone, giving the attacker complete control of the device.

    Potential countermeasures

    Currently, no patch exists for this vulnerability. Samsung has indicated that they will use their Knox security solution to remotely issue a fix, but when this will be released is unclear. In the official statement released by Samsung, they only mention that they will “begin rolling out a security policy update in the coming days.” Samsung has also advised users to ensure their devices automatically receive security policy updates. Steps to configure their devices to do so can also be found in the statement.

    Until then, there are two possible countermeasures. The first countermeasure is to only connect to Wi-Fi networks that are secure, in order to prevent any man-in-the-middle attacks. This can be a problem if the user has to connect to public Internet connections. The use of a Virtual Private Network (VPN) helps secure a user’s connection in these cases.

    Secondly, the user can stop the use of the default Samsung keyboard. To do this, they have to do two things: first, select an alternate keyboard instead of the default system keyboard. This can be done under the Language and input section of the device’s settings:

    Figures 2-4. Steps to change Android keyboard

    However, using a different keyboard is not enough. The system keyboard itself has to be turned off. Unfortunately, this has to be done every time the device is turned on. This can be done under the Applications part of the settings menu:

    Figures 5-7. Steps to disable system keyboard

    These steps will mitigate the risk to the user from this vulnerability.


    Companies risk losing all their customers if they continue neglecting their app store presence. While malicious mobile apps do bring serious security concerns to the fore, (70% of top free apps have fake and mostly malicious versions in app stores) companies and developers also face another challenge in the form of copycats.

    For a company that needs to maintain an official mobile app on Google Play, fake or impostor apps can mean trouble for both their credibility and revenue. For users, the impact is similar, although on a more personal level. If users get fooled into downloading these apps, it can eventually lead to information theft, reputation damage, and overall dissatisfaction with the company’s brand and service.

    Companies that maintain official apps in app stores like Google Play have a big role to play in minimizing the risk of their users installing fake apps. By properly establishing their identity and their apps, they can greatly help their users sort out the real apps from the fake ones. For example: ideally, all apps are released under one developer, as is the case for the various Trend Micro apps:

    Figure 1. Trend Micro apps on Google Play

    However, we have noticed that some organizations are not able to do this. Instead, multiple developers all publish various versions of official apps.

    Figure 2. Various banking apps with different developer names

    Why is this the case? Android requires that all apps should be signed (even with a self-signed certificate). Large organizations will, of course, have different teams responsible for developing different apps. Different private keys may be used to sign any created apps, even if they are consolidated under one account. Furthermore, different accounts may be used to upload the apps, even if they’re all related to the same company.

    The practice can cause confusion among users (as seen in Figure 2), where it is not clear which is the official account. Even if the apps are consolidated under one account, outside of the Google Play store there is no way to identify that these apps as legitimate or not (since the certificate is used to identify the author). This can cause confusion if an app is legitimate or not in third-party stores.

    For developers, the main impact here is that their customers might not be able to properly identify their app and they may lose potential install base. For users, however, this can turn into a big risk, since this makes it harder to spot “legitimate” versions of the app (e.g., the developer name used might not make it clear who published the app). In addition, if the user checks what other apps were published by a specific developer there may not be other apps to be found. In and of themselves, these are not necessarily bad, however malicious apps can share these traits as well.

    How do we know who is faking it?

    Companies need to ensure that they properly identify themselves as the credible source for their apps. It is not extraordinarily difficult for organizations to adopt proper key management to allow all apps released to be signed by one key: many large companies are able to do exactly this. The solution is to implement proper key management practices; the IT department of a large organization should be capable of arranging this correctly. Ideally, all official apps should be signed by one certificate, tied to one developer account.

    For consumers, this has one benefit: all apps from an organization would show up as from one developer in Google Play, as well as third-party app stores. With official apps properly identified, this will help users identify fake apps  and prevent from inadvertently downloading them. This protects them from various problems such as information theft.

    For now, we strongly advise users to be careful in choosing which app to download. Checking all details related to the app — developer name, rating, reviews — can help identify fake apps. Additionally, installing a security app such as the Trend Micro Mobile Security and Antivirus can detect fake apps and prevent them from getting installed.

    Posted in Mobile | Comments Off on Mobile Certificates and Developer Accounts: Who is Faking It?

    9:22 pm (UTC-7)   |    by

    Analysis by Marshall Chen, Yi Lee, and Joe Wu

    Brand owners frequently use SPF and DKIM to protect their brands from email forgery. For example, a brand owner could register the same domain name under multiple top-level domains (TLDs) (such as, etcetera) and announce SPF/DKIM records for all of these domains (even if they were not actively being used). While generally effective, there is one loophole: what about the .gov TLD?

    This loophole was recently exploited in a massive phishing attack against American Express, which started on March 4. The attackers sent out emails that imitated American Express notifications, which contained a link to a phishing site. We identified more than 50 distinct phishing sites used in this spam run. These were hosted on various compromised domains, and all had the format of hxxp://{compromised website}/amerrricaneaxpress/security.html.

    Figure 1. Phishing email (address and phishing URL highlighted)

    So far, this has been a fairly ordinary attack. What we found unusual was one of the supposed email addresses used by the attacker. Three addresses were frequently used in this attack:


    The first two domain names ( and are both registered by American Express, and have SPF/DKIM records published. Emails with these addresses would fail SPF verification, as their IP address would be inconsistent with the authentic ones in the SPF record.

    In the third case, however, no SPF records would be published at all. Only US government bodies can register .gov domains. An SPF verification attempt would return none instead of fail, as there is no SPF record to authenticate at all (the domain is not even registered). Therefore, an email system checking for SPF records would not rule this message to be spam on those grounds alone. This may increase the risk that users would receive these spammed messages.

    Our own sources identified more than 430,000 phishing mails sent from more than 4,600 IP addresses as part of this spam run. These IP addresses were located in more than 120 countries. This spam run took place from March 4 to March 11, with most of the senders located in the United States.

    Figure 2. Distribution of spam-sending IPs by country

    Read the rest of this entry »

    Posted in Spam | TrackBacks (2) »


    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice