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

  • Recent Posts

  • Calendar

    September 2014
    S M T W T F S
    « Aug    
     123456
    78910111213
    14151617181920
    21222324252627
    282930  
  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Jay Yaneza (Technical Support)




    Legitimate services are often used by cybercriminals to try and make their attacks more convincing. Recently, I spotted attacks that used services and platforms like Google Drive and Dropbox in order to look less suspicious to unwary users.

    I received a spammed message like the one shown right below that supposedly came from Gmail itself. It warned me that someone logged into my account from an unknown device. However, all of the links in it pointed to a Google Drive URL:

    Figure 1. Sample spam email

    Even though the email message is similar to a legitimate Gmail message, a careful user will note that the displayed e-mail address and the supposed source address did not match. Further examination of the email’s headers indicates that the email was, in fact, sent via a website’s mail form.

    As I mentioned earlier, all the links provided in the email actually go to an HTML file hosted on Google Drive. This HTML file is used to detect the operating system and browser of the user. For example, this particular code is used to determine what operating system the user is running:

    function nav() {
    var OSName="UnknownOS";
    if (navigator.platform.indexOf("Win")!=-1) OSName="W";
    if (navigator.platform.indexOf("Mac")!=-1) OSName="M";
    if (navigator.platform.indexOf("X11")!=-1) OSName="U";
    if (navigator.platform.indexOf("Linux")!=-1) OSName="L";
    if (/Android/.test(navigator.userAgent)) OSName="A";
    return OSName;

    Note that the above code is comprehensive and considers various platforms: Windows, Mac, Unix, Linux, and even mobile platforms (Android). Further code also differentiates what payloads are delivered based on the user’s browser. This is what the user would see (here, running Firefox):

    Figure 2. Fake plugin download page

    However, while the HTML code can differentiate between different configurations, a relatively limited number of payloads are actually delivered. These are detected as BKDR_PERCS.A.  This backdoor steals email credentials and user names and passwords. It also logs keystrokes as part of its information theft routines. As a backdoor, it can also accept remote commands from the attackers.

    Examining the infection chain in Deep Discovery Advisor makes the infection chain a little clearer:

    Figure 3. Deep Discover Advisor screen (Click to enlarge)

    On systems with Firefox, the backdoor is sent in the form of an XPI file (used by Firefox extensions). This binary file contains the backdoor itself, as well as associated malware components.

    The actual malicious payloads are hosted on Google Drive as well. The attackers upload new files to be used in this attack on a fairly regular basis, although the behavior remains the same. For example, on the first day I saw this, this attack distributed files with the following hashes:

    • 012BCE75BCACDAE0CCCB37B6740A925F769F5547
    • D18C7C42236171C37A6A3B7C1DEE6E0A6381AC4E

    Two days later, the links were changed and now pointed to files with the following hashes:

    • 711AFD18ACCF650F6AEC42F836380EE158D4F8D5
    • A7F8F8A251534867CC9FE56636CFAB26D12C03C4

    Several days after that, the same behavior happened and the new files had the following hashes:

    • 711AFD18ACCF650F6AEC42F836380EE158D4F8D5
    • A7F8F8A251534867CC9FE56636CFAB26D12C03C4

    As these files are located on legitimate services, they are also sent via HTTPS, which helps evade some web filtering techniques. In addition, it used a compromised website’s mailer system and an IPv6 address, which can also evade email reputation services.

    gmailspam_image6

    Figure 4. Screenshot of the email headers of the spam email

    gmailspam_smtp

    Figure 5. Screenshot of the name resolution of the sending email server

    Trend Micro protects users from this spam run by detecting malicious files and blocking all related malicious URLs. We also contacted Google about the malicious files that have been uploaded so they can be removed.

     
    Posted in Malware, Spam |



    Last week, in the previous part of this post, we went over the behavior of Control Panel (CPL) malware before the actual infection. In this second part, we go over what happens after the malware has reached a system. (Note: much of this analysis was carried out with Deep Discovery Advisor, so some of the screenshots will have been taken from this product.)

    This particular CPL malware (detected as TROJ_BANLOAD.ZAA) appears to be targeted at Windows 7 users – specifically, those using the 32-bit version. How do we know this? Based on previous research, we know that CPL malware is frequently used as a downloader for other malware. We see this behavior in 32-bit Windows 7:

    Figure 1. Behavior under 32-bit Windows 7
    (Click above image to enlarge)

    However, on other platforms (like 64-bit Windows 7), we do not see that behavior.

    Figure 2. Behavior under 64-bit Windows 7

    So, let’s look into what this malware does when it is run in its “right” target environment.

    It accesses four URLs, two of which are non-malicious and Microsoft-related. One is the Compatibility View list for Internet Explorer 9; the other is the browser icon (favicon.ico) for Bing. Two are potentially malicious, with Deep Discovery Advisor flagging one as malicious.

    Figure 3. URLs accessed by CPL malware

    Let’s look at the first potentially malicious domain. It is a .com domain; the WHOIS records also identify a Spanish man as both the registrant and the technical contact for the domain. It was first registered in 2010.

    All this site does is return a simple text string: “NTFD!”. It’s possible that this may be used for command-and-control, although no definitive evidence either way is present. However, by itself, there’s nothing here that indicates malicious behavior, so it is not flagged as such.

    The other domain is more interesting. It appears that it is a compromised site belonging to an Israeli company – the domain is under the .co.il top-level domain, it is hosted in Israel, and the content clearly belongs to the company as well.

    However, the malware downloaded an executable file directly from this server. While it has a different name - 07-03.exe.exe instead of morph.exe – it has the same hash as the dropped file identified earlier. The file name itself is also intriguing, as if read in a day-month format , it reads “March 7″, which was just days before I actually analyzed this particular attack.

    Once on the system, this particular malware drops multiple copies of itself and proceeds to carry out its information theft routines.

    Figure 4. Analysis of payload
    (Click above image to enlarge)

    From there, the usual information theft routines as discussed in our earlier research proceed, targeting the user’s personal information, as outlined in the threat diagram below. We detect this malware as TSPY_BANKER.ZAA.

    Figure 5. CPL malware threat diagram

    Detection and Prevention

    By providing details on how this attack was able to reach user systems, we hope that this can help others from becoming victims of this threat. Our previous research has indicated that Internet users in Brazil are the most common victims of CPL malware, and that has not changed here.

    Beyond common best practices, this incident allows us to see some possible defenses against attacks like these. For emails, checking the sender IP address is already standard behavior. However, defenses and policies against attachments should be considered – these should be scanned for malicious content, and some potentially risky tile types can be blocked.

    As for the potentially malicious URLs, it may be worth considering to block the download of executable files. In this particular case, doing so would have prevented the download of the main payload by the initial CPL downloader. Failing that, endpoint software should be in place to check the reputation of any downloaded files.

    Trend Micro solutions protect against all aspect of this attack, as well as other similar incidents using CPL malware.

     
    Posted in Malware, Spam | Comments Off



    Recently we’ve discussed how Control Panel (CPL) malware has been spreading in Latin America. In the past, we’ve analyzed in some detail how CPL malware works as well as the overall picture of how this threat spreads. In this post, we shall examine in detail how they spread, and how they relate with other malicious sites and components.

    Recently, while I was checking my spam mailbox, I found one of these messages there. Specifically, I found this email sample:

    Figure 1. Spam message

    This roughly translates to:

    From: {Dear Customer} (delivery-receipt@outlook.com)
    Subject: As requested, the Invoice of Payment is Below
    Message Body:
    Good Morning  Sir/Madam customer,
    As requested, the following is the invoice for payment

    [PDF icon] Click here to download.

    The email address used in this attack may look authentic at first glance, but it is actually just an address from Outlook.com, Microsoft’s free webmail service. In the message itself, there are two highlighted items: the PDF icon, and a link after the PDF icon.

    The PDF icon is actually a hot-link of an image hosted by Google which is a PDF download icon. When clicked, this leads to a fake “access denied” website.

    However, if the user does click on the link, as opposed to the icon, they are directed to a document that is hosted on a Google Drive. From this document, the user is redirected to a malicious page, as seen below:

    Figure 2. Google Drive document

    After more redirections, the user is sent to the URL of a malicious archive. Inside this downloaded archive named Fature.zip one finds the Control Panel malware.

    Figure 3. Malicious archive

    Redirection Details

    As seen, there are actually three malicious sites necessary to get to the malicious file. The overall infection chain is:

    1. Spam message
    2. Google Drive URL
    3. http://{malicious domain #1}/Pdf/Visualizar.php
    4. http://{malicious domain #2}/Fatura.zip

    Both of the mentioned malicious domains above are hosted in Brazil, and use the .br top-level domain.

    Using a Google Drive URL as the initial infection vector was a clever decision, as network traffic with Google will not be found malicious, and URL scanners will frequently whitelist a Google-related URL as well.

    The page at this Google URL is actually an HTML document that uses the META tag to redirect users to the first malicious site, as shown in Figure 2.

    Note that at malicious domain #1, there is also one redirect within the site: the URL from Google only goes to the Pdf directory; the site itself redirects users to the Visualizar.php page.

    Figure 4. Malicious site redirection

    From here, how did it download the malicious payload Fatura.zip? It used HTTP status code redirection, as was used by malicious domain #1:

    Figure 5. HTTP status redirection

    The HTTP Location header field (highlighted above) is provided to the web browser under two circumstances:

    • To ask the browser to load a different page. In this case, the Location header would sent with the HTTP 302 status code, and then would provide a “Moved Temporarily” status. This is what was described above. The user has no choice in the matter, as this is part of the HTTP protocol itself.
    • To provide information about the location of a newly created resource, but this would go with an HTTP status code of 201 or 202.

    We can see how the attacker designed this attack to make it more difficult to block: by using a Google-related URL, it makes blocking these URLs very difficult. Even its misuse of the Google Drive service would be tricky to deal with, since the attacker did not actually use the service to host malicious content, but instead used it as a redirector. The multiple redirections can make detecting the “right” URL to block more difficult if no network monitoring is conducted. (A casual inspection might lead someone to believe that the malicious URL came from Google, which is clearly not the case.)

    In the next part, we will look at how this attack proceeds once it has been installed on an affected system.

     
    Posted in Bad Sites, Malware | Comments Off



    Last week, we talked about what Tor is, how it works, and why system administrators need to be aware of it. Now the question is: should I block Tor, and if I do decide to do that, what can be done to block Tor?

    Tor, by itself, is not inherently malicious. If a user wants to prevent any third party from finding out what sites they are visiting, Tor is an incredibly useful tool. For example, security researchers use Tor routinely to help investigate various online threats. Many dissidents use Tor to hide their traffic from repressive governments.

    However, the same traits that make it useful for legitimate parties also make it attractive for cybercriminals. Particularly in an enterprise context, the idea of having completely anonymous traffic going to somewhere on the Internet is not only terrifying, it may even be an unacceptable risk. Blocking Tor is something that a network administrator must consider, but it is not malicious in and of itself.

    If one does decide to block Tor traffic, how does one do this?

    To block Tor, one has to try and block the connection from the client to Tor servers. These servers frequently listen on several specific ports: ports 80, 443, 9001 and 9030. Clients would try one port or another until it is able to connect to the Tor node(s).

    Figure 1. Internet connection to a Tor node by malware

    So Tor has a recognizable pattern that can be blocked on the network level. Broadly speaking, there are two possible ways to do this. One can attempt to control the traffic outbound to the Internet by the ports being used. For example, one can block outbound traffic to specific ports, or limit the allowed outbound traffic to certain ports.

    Alternately, one can try to use application-level filters or other network inspection techniques to try and determine which is legitimate traffic and which is malicious traffic. For example, application-level filtering, an extension of stateful packet inspection (SPI), would be able to tell the difference between HTTP traffic (port 80) used for web browsing and traffic used for peer-to-peer networking.

    For smaller networks – such as those in homes or small businesses – the best solution is to try and block Tor at the endpoint by detecting any malware that uses it. The inexpensive routers used in these situations are not set up by default to block outgoing traffic, nor do they have sophisticated network inspection tools. In addition, blocking some commonly used ports like port 80 (HTTP) or port 443 (HTTPS) would severely affect the user experience, so it’s not really an option either.  That leaves endpoint protection as the best option.

    For medium to large businesses, it would be a different story. These have the resources and the personnel to implement Tor detection at the network level. Ideally, rules regulating network traffic should already be in place – which may already cover both HTTP and HTTPS traffic.

    So what specific steps should be done to guard against Tor-related network traffic?

    A web application proxy with application control may be useful. Companies often need to control or scan Internet applications.  A good way to do this would be to implement application control, which is more powerful than a simple allow-or-block option, although a combination can be applied:

    • Step 1: implement a web proxy that can perform application control.  This is usually implemented in a machine in a DMZ.
    • Step 2: restrict all direct Internet access to just that web proxy.

    Here’s an illustration of what such a setup would look like:

    Figure 2. Network segmentation for larger networks

    Aside from this, one should monitor firewall hits for outgoing traffic to ports 9001 and 9003. This kind of traffic is characteristic of endpoints trying to access the Tor network. Going through voluminous firewall logs may be daunting, but some firewalls allow logs to be forwarded to security information and event management (SIEM) software, where rules can trigger an automatic notification.

    These recommendations allow a network administrator to tell what goes through port 80 and 443. This not only helps mitigate the effects of have a Tor-related malware, but also improves the overall security posture of the network. For one, this may allow a more proactive position in terms of network defense and countermeasures.  This in better than just waiting for the offending piece of malware to reach the desktop and deal with the effects of infection (i.e., cleanup.)

    Trend Micro offers InterScan Web Security that allows both application control and visibility that is essential to understanding ongoing network risks. Being able to sift through normal web traffic and identify Tor traffic through is as easy as allowing or denying it, as seen below:

    Figure 3. Application Control Screen for Policy Creation

    In addition, the Deep Discovery Inspector allows network-wide visibility of Tor-related traffic:

    Figure 4. Detection logs for Tor-related applications

    Both of these products can be integrated with security information and event management (SIEM) software. The combination of these two security software (InterScan Web Security and Deep Discovery Inspector) as well as other firewall/unified threat management solutions working within a network, all tied to a SIEM product, is an important tool for a network administrator.

    This allows him to visualize the events within a network, allowing him to defend the network against newer threats (such as Tor-related malware) and possibly making it easier to pinpoint devices that may be the cause of security alerts.

     
    Posted in Malware | Comments Off



    In the past few months,  the Tor anonymity service as been in the news for various reasons. Perhaps most infamously, it was used by the now-shuttered Silk Road underground marketplace. We delved into the topic of the Deep Web in a white paper titled Deepweb and Cybercrime. In our 2014 predictions, we noted that cybercriminals would go deeper underground – and part of that would be using Tor in greater numbers.

    Cybercriminals are clearly not blind to the potential of Tor, and network administrators have to consider that Tor-using malware might show up on their network. How should they react to this development?

    What’s Tor, anyway?

    Tor is designed to solve a fairly specific problem: to stop a man-in-the-middle (such as network administrators, ISPs, or even countries) from determining or blocking the sites that a user visits. How does it do this?

    Previously known as “The Onion Router”, Tor is an implementation of the concept of onion routing, where a number of nodes located on the Internet that serve as relays for Internet traffic. A user who wants to use the Tor network would install a client on their machine.

    This client would contact a Tor directory server, where it gets a list of nodes. The user’s Tor client would select a path for the network traffic via the various Tor nodes to the destination server. This path is meant to be difficult to follow. In addition, all traffic between nodes is encrypted. (More details about Tor may be found at the official website of the Tor project.)

    In effect, this hides your identity (or at least, IP address) from the site you visited, as well as any potential attackers inspecting your network traffic along the way. This is quite useful if you’re a visitor who wants to cover your tracks or if, for some reason, the server that you’re trying to connect to denies connections from your IP address.

    This can be done for both legitimate and illegitimate reasons. Unfortunately, this means that it can and has already been used for malicious purposes.

    How can it be used maliciously?

    Malware can just as easily use Tor as anyone else. In the second half of 2013, we saw more malware making use of it to hide their network traffic. In September, we blogged about the Mevade malware that downloaded a Tor component for backup command and control (C&C) communication. In October 2013, Dutch police arrested four persons behind the TorRAT malware, a malware family which also used Tor for its C&C communication. This malware family targeted the bank accounts of Dutch users, and investigation was difficult because of the use of underground crypting services to evade detection and the use of cryptocurrencies (like Bitcoin).

    In the last weeks of 2013, we saw some ransomware variants that called itself Cryptorbit that explicitly asked the victim to use the Tor Browser (a browser bundle pre-configured for Tor) when paying the ransom. (The name may have been inspired by the notorious CryptoLocker malware, which uses similar behavior.)

    Figure 1. Warning from Tor-using ransomware

    Earlier this month, we discussed several ZBOT samples that in addition to using Tor for its C&C connection, also embeds its  64-bit version “inside” the normal, 32-bit version.

    Figure 2. Running 64-bit ZBOT malware

    This particular malware runs perfectly in a 64-bit environment and is injected into the running svchost.exe process, as is typically the case with injected malware.

    This increase in Tor-using malware means that network administrators may want to consider additional steps to be aware of Tor, how to spot its usage, and (if necessary) prevent its use. Illegitimate usage of Tor could result in various problems, ranging from circumvented IT policies to exfiltrated confidential information.

    We will discuss these potential steps in a succeeding blog post.

     
    Posted in Malware | Comments Off


     

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