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

  • Recent Posts

  • Calendar

    March 2015
    S M T W T F S
    « Feb    
  • Email Subscription

  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Jon Oliver (Senior Architect)

    Recently Google announced that it had changed its policy dealing with images in email. In a blog post on the official Gmail blog, Google said:

    [You’ll] soon see all images displayed in your messages automatically across desktop, iOS and Android. Instead of serving images directly from their original external host servers, Gmail will now serve all images through Google’s own secure proxy servers.

    Simply put, this means that all pictures in emails will now be automatically displayed. Instead of being served directly from the site hosting the image, however, they will be given a copy that has been scanned by Google.

    Officially, the stated rationale for this change is that previously, senders “might try to use images to compromise the security of your computer”, and that with the change images will be “checked for known viruses or malware”. This change affects users who access Gmail via their browser, or the official iOS and Android apps.

    In the past, there have been occasions where malicious images were used to compromise computers. A number of image formats were exploited in 2005 and 2006, including a Windows Metafile vulnerability (MS06-001), and an Office vulnerability that allowed arbitrary code execution (MS06-039). More recently, a vulnerability in how TIFF files were handled (MS13-096) was found and not patched until the December Patch Tuesday cycle. Properly implemented, scanning the images would be able to prevent these attacks from affecting users.

    However, actual exploitation of these vulnerabilities has been relatively uncommon. Exploit kits have opted to target vulnerabilities in Flash, Internet Explorer, Java, and Reader instead. Image vulnerabilities are not even listed in the control panels of these kits.

    The primary reason to block images is not to block malware, but to stop information leakage. Images are used by spammers and attackers to track if/when email has been read and to identify the browser environment of the user. Email marketers also use this technique to check how effective their email campaigns are.

    Email marketers have already confirmed that in spite of Google’s moves, email tracking is still very possible. Google’s proposed solution (a web proxy that checks images for malware images) appears to solve a small security problem (malicious image files), while leaving at risk user’s security and privacy. Attackers still have the capability to track that users have read email–and to learn aspects of their browser environment.

    Users can still revert to the previous behavior via their Gmail settings, as outlined in Google’s blog post:

    Of course, those who prefer to authorize image display on a per message basis can choose the option “Ask before displaying external images” under the General tab in Settings. That option will also be the default for users who previously selected “Ask before displaying external content”.

    We strongly recommend that users change this setting for their accounts. Users who access Gmail via POP3 or IMAP should check the settings of their mail application to control the display of images.

    Posted in Bad Sites | Comments Off

    The Blackhole Exploit Kit is one of the most notorious exploit kits currently in circulation among the cybercriminal underground today. Thus, we continuously monitor for incidents and attacks involving the exploit kit itself.

    Last week we reported about the spam campaign leveraging the birth of Prince William’s and Kate Middleton’s son. Our analysis of the campaign yielded its connection to other currently-ongoing campaigns that used other recent news events, such as the controversy surrounding the upcoming movie Ender’s Game.

    Some of the other connected campaigns also used Facebook and eBay as lures to get users to click malicious links.

    The volume of spammed messages related to this spam run reached up to 0.8% of all spam messages collected during the time period — a relatively large percentage compared to other runs. We’ve also identified a list of countries that we detect where the bulk of the spam is coming from, and found that a large portion of them were from the US.

    Another notable aspect of this run is its payload, which includes the information stealer TSPY_FAREIT. TSPY_FAREIT variants are often used as payload in campaigns that leverage BHEK.

    The exact variant in this particular run, detected as TSPY_FAREIT.AFM, not only steals FTP client account information on the system it affects, but also steals stored email credentials, stored login information from browsers and ALSO brute-forces Windows login with a list of predetermined passwords. It basically plunders the affected computer of personal information that can be used to compromise the user’s financial accounts, personal information and even the security of the system they’re using.

    These recent developments regarding this particular exploit kit can certainly be disconcerting, but nothing particularly new in regards to BHEK being used in new, unpredictable ways. What we can glean from this, however, is that even such an old approach is still effective in getting victims, which means that more users need to be protected about this threat. And user protection is not all that hard – as we’ve reminded everyone in the past, guarding against this kind of threat is a simple matter of a)being vigilant against socially-engineered attacks and b) having a security solution that blocks out the threats themselves.

    Infection can be avoided by extra vigilance by users on not clicking on the links that present themselves through suspicious mails such as these. Other precautions include: always installing the latest Java security update (Find out more on how you can use Java safely here), and using a web reputation security product.

    Trend Micro users are protected from all the malicious elements involved in this overarching spam campaign. For more information regarding the Blackhole Exploit Kit, refer to our paper on the subject here.

    With additional inputs from Matt Yang and Rhena Inocencio.

    Posted in Bad Sites, Malware, Spam | Comments Off

    In two recent blog posts (The Risks of the Out of Office Notification and Other Risks from Automatic Replies)  we discussed the possible threats from automatic email replies, from out of office notifications to read notifications to non-delivery receipts, they all allow information to be leaked – which can then be exploited. So what can administrators and users do to deal with this threat and help secure their environment?

    While we have always stressed the importance of user education, in this particular case this should be reinforced with strong server settings. There’s no reason to rely only on user settings, which can be (and frequently, are) set improperly.

    Enterprise email servers have fairly granular control over whether out-of-office notifications are sent or not. A good best practice for e-mail would be to limit out-of-office notifications to recipients within the organization only. If external parties need to receive these notifications, then they can be whitelisted as necessary. However, the default should be that external parties should not be sent out-of-office notifications.

    Read the rest of this entry »

    Posted in Spam | Comments Off

    Recently it was announced via posts in underground forums and Pastebin posts that a new version of the Blackhole Exploit Kit (BHEK), version 2.0, had been released. (The original announcement was in Russian; an English translation has been provided by researcher Denis Laskov and may be found here.)

    We cannot confirm that BHEK 2.0 has been fully deployed by cybercriminals yet. However, intriguing evidence suggests that some parts of BHEK version 2.0 are already being beta-tested in the wild.

    The announcement explicitly called out changes in the URLs that BHEK uses:

    In version 1. * link to malicious payload unfortunately was recognizable for AV companies and reversers, she [sic] looked this kind,. /Main.php?Varname=lgjlrewgjlrwbnvl2. The new version of the link to the malicious payload you can choose yourself, here are some examples: /news/index.php,/contacts.php and so on, now for the moment no one AV can not catch.


    Let’s look at three recent BHEK spam runs to see where they fit here. One spam run, using the name of the Federal Deposit Insurance Corporation (FDIC), was a classic BHEK 1.x spam run with an infection chain of this format:

    hxxp://{compromised domain}/achsec.html
    hxxp://{landing page}/main.php?page=0f123fe645ddf8d7

    In contrast to this, both the eFax and ADP spam runs used the new URL format. eFax used the following format:

    hxxp://{compromised domain}/{8 random characters}/index.html
    hxxp://{redirection domain}/{8 random characters}/js.js
    hxxp://{landing page}/links/raising-peak_suited.php

    ADP used similar URLs for its landing pages as well:


    While these attacks use the URL format of BHEK 2.0, their internals still show signs of BHEK 1.x. We saw use of the plugindetect function in their scripts. However, use of that code was explicitly removed in BHEK 2.0. The following text was directly from the translated announcement:

    We not using anymore plugindetect to determine the version of Java that will remove a lot of the bunch of extra code thus accelerating the download bundles


    This unusual combination indicates that the authors of BHEK 2.0 may still be beta-testing specific features before actually releasing BHEK 2.0 fully into the wild.

    We will continue to monitor for new information related to this new threat, and release our findings as appropriate.

    Additional text by Lala Manly and Jonathan Leopando

    Update as of Sept. 17, 11:20 PM PDT

    Trend Micro Smart Protection Network™ protects users from this threat via web reputation service, which blocks access to the related URLs. File reputation service detects and deletes malware related as JAVA_BLACOLE.ZXX, JAVA_BLACOLE.REP, JS_BLACOLE.UYT, TROJ_FAKEAV.KED and TROJ_REVETON.BEK.

    Based on our initial analysis, both JAVA_BLACOLE.ZXX and JAVA_BLACOLE.REP exploits the vulnerability in Java Runtime Environment (JRE) 1.7 (CVE-2012-4681), which was targeted by a zero-day exploit documented in our previous post. JS_BLACOLE.UYT downloads other files, while TROJ_FAKEAV.KED displays security alert to trick users into purchasing a rogue antivirus program. TROJ_REVETON.BEK drops its component files onto the infected system.

    Posted in Spam | Comments Off

    Last week’s Java zero-day vulnerability has been exploited by many exploit kits in the wild, including the familiar Blackhole Exploit Kit.

    In this blog entry, we thought we would describe some of the outbreaks related to this attack we’ve seen in the past week or so. Our automated processes that are a part of the Trend Micro™ Smart Protection Network™ started detecting and blocking these attacks as soon as they were spotted in the wild.

    A number of methods have been used to direct Internet users to the landing pages hosting these attacks, including:

    The usage of multiple ways to direct users to malicious sites definitely increase the chances of users stumbling into them, thus increasing the risk. In terms of the spam runs, we also saw several types of lures used:

    • Fake LinkedIn messages
    • Fake antivirus notifications
    • Faxes purporting to come from eFax
    • Fake Western Union money transfers

    The spammed messages contained links that would redirect users to compromised websites – which would then redirect to malicious landing pages. Landing pages are meant for two purposes: to scan the systems for any vulnerabilities, and to redirect to a corresponding exploit once a vulnerability is found.

    Looking at just one of the attacks using this new Java exploit, we were able to identify more than 300 malicious domains hosting landing pages, which were hosted on more than 100 servers.

    Almost half of the domains seen were hosted on the most well-recognized top-level domains: .com, .org and .net.

    Another finding is that almost half of the sites were hosted in the United States, with Russia hosting more than a fourth:

    Seems like most of the victims were also situated where the sites were hosted, as two-thirds of the victims we found were from the United States, with European countries making up the bulk of the remaining third.

    Trend Micro users are already protected from this through the Smart Protection Network. Furthermore, we advice users to consider if Java is necessary on their systems; if it is not, we recommend uninstalling it as it can pose a serious security risk. If it is needed, it must be kept up to date with the latest versions that are downloadable from Oracle.

    Trend Micro Deep Security users are also recommended to apply the rule 1005178 – Java Applet Remote Code Execution Vulnerability – 2 to protect from threats seen exploiting this Java vulnerability.

    Coming Soon: The TrendLabs Security Intelligence Blog will be the new Malware Blog

    Posted in Bad Sites, Exploits, Malware, Spam, Vulnerabilities | Comments Off


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