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 »

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:

hxxp://69.{BLOCKED}.{BLOCKED}.108/links/systems-links_warns.php
hxxp://108.{BLOCKED}.{BLOCKED}.7/links/differently-trace.php

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.

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:

• Spam runs
• Compromised sites
• Redirection from pornographic websites
• Malvertising

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

Over the past month we’ve been investigating several high-volume spam runs that sent users to websites compromised with the Black Hole exploit kit. Some of the spam runs that were part of this investigation used the name of Facebook, and US Airways. Other spam runs involved LinkedIn, as well as USPS. The most recent campaign we’ve seen that was part of this wave of attacks used the name of CareerBuilder:

We’ll look at the campaign that used Facebook specifically, but our conclusions about these each of these attacks are broadly similar:

• Phishing messages using the names of various organizations spread via email to targets predominantly in the United States. The content of these phishing e-mails were practically indistinguishable from legitimate messages.
• Links in these messages led to multiple compromised websites that redirected the user to various malicious sites. Collectively, these compromised sites numbered in the thousands.
• Users were eventually directed to sites containing the Black Hole exploit kit.

Now, let’s discuss the spam attack that used Facebook as the lure. This particular spam run consists of a fake friend request sent to the victim, as can be seen below:

The link goes to various compromised web sites. We have identified more than 2,000 distinct URLs used in this attack, distributed over 374 domains. On average, each compromised domain hosted 5 separate malicious landing pages.

As we mentioned earlier, this particular campaign was not the only spam run we investigated. We found clear evidence that all these attacks were linked. In many cases, the same sets of compromised URLs were used by multiple spam runs. This suggests that at least some of the parties responsible for these attacks were identical, if it was not the same group altogether.

Read the rest of this entry »

The controversial Stop Online Piracy Act (SOPA) has received a lot of attention of late, with parties ranging from the White House to Rupert Murdoch. Opposition to SOPA has been particularly fierce online, with many sites “blacking out” on January 18 as a form of protest against the bill. The biggest site that will take part in these protests is Wikipedia. Google is also taking part; they have indicated that they will display a link on their front page showing the tech giant’s opposition to the bill.

We reiterate our position on this matter, which we first stated on this blog a month ago. We remain concerned about provisions in the law that could seriously compromise DNSSEC, which will play a key part in future cybersecurity strategy. At the very least, by ensuring the secure transfer of DNS data from servers to end users, DNSSEC will make man-in-the-middle and cache poisoning attacks much more difficult. DNSSEC may also be used as the foundation for further tools and techniques that will aid in greater online security

We endorse the position of the White House, which we quote below:

We must avoid creating new cybersecurity risks or disrupting the underlying architecture of the Internet. Proposed laws must not tamper with the technical architecture of the Internet through manipulation of the Domain Name System (DNS), a foundation of Internet security. Our analysis of the DNS filtering provisions in some proposed legislation suggests that they pose a real risk to cybersecurity and yet leave contraband goods and services accessible online. We must avoid legislation that drives users to dangerous, unreliable DNS servers and puts next-generation security policies, such as the deployment of DNSSEC, at risk.