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

  • Recent Posts

  • Calendar

    April 2015
    S M T W T F S
    « Mar    
  • Email Subscription

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

    Author Archive - Jay Yaneza (Threats Analyst)

    We have been continuously monitoring the FlashPack exploit, especially with the recent attack which affected Japanese users. We recently looked at our Smart Protection Network feedback and found in a new development that majority of the infected systems of FlashPack exploit came from the U.S.


    Figure 1. Top infected countries for the FlashPack exploit (based on feedback from September 24-October 22)

    URL Usage and Malware Payload

    We checked the details of the URLs used by the FlashPack exploit and found that the exploit uses three combinations. We broke down the combinations in the table below.


    Figure 2.  Format of the URLs used by the FlashPack exploit

    Based on our analysis, one significant detail is that majority of the sites are employing bulletproof hosting, though some of the said sites have been taken down already. Furthermore, the domain registrations of the discovered sites are new and have been registered only between September and October 2014.

    Given these facts, having a very strong web filter that enforces an existing IT policy of only allowing access to known sites would be ideal as it effectively filters out unknown sites.  At the onset of infection, the URLs used in this attack may not be rated immediately as these are newly created websites and as such may not have been classified or visited yet by a web filter vendor.

    In one of the URLs that was used as a distribution point, the initial file upon its discovery (sha1: 909dc6764355625cb9a98ae45f986439cf3142a6) had little behavioral characteristics as it just launches calc.exe and is generally benign.


    Figure 3. Behavioral characteristics of the initial benign file (sha1: 909dc6764355625cb9a98ae45f986439cf3142a6), seen through sandbox execution in Deep Discovery Analyzer

    The files downloaded from the distribution sites are named this way:   e54 + [0-9,a-f]{10} + [0-9]{10}  + .exe.  Here are other examples:

    (and so on …)

    Note that the file name seems to be generated by the affected sites. However, after monitoring these sites for a few days, we see that the payload changes and we were lucky enough to observe several files that distributed through web sites. One such sample (sha1: 987d17220ee8936d2dfb58b35a6adc17f7141d50) is detected by Trend Micro as TROJ_DOFOIL.WYTU. This malware has characteristics like sandbox checking for its evasion tactic, and process injection:


    Figure 4. Behavioral characteristics of TROJ_DOFOIL.WYTU, seen through sandbox execution in Deep Discovery Analyzer

    Aside from the behaviors mentioned above, we also did code analysis for TROJ_DOFOIL.WYTU and found the following details:

    1. This malware does not perform the intended routines if the following are seen:


    Figure 5. Screenshot of listed software

    These refer to actual software:

    • v  sbiedll – Sandboxie, a sandbox security software for Windows
    • v  dbghelp – Debug Help Library, commonly used to for debugging when working with portable executable (PE) file format
    • v  qemu – a generic and open source machine emulator and virtualizer
    • v  virtual – commonly used to refer to VirtualBox
    • v  VMware – like VMware Workstation and other similar software from VMware
    • v  Xen – from the Xen Project, an opensource hypervisor

    2. It creates a mutex, which is a hashed computer name +  volume SN

    3. It drops/creates the following files:

    • %Appdata%\{random1}{random2}.exe
    • StartMenu\Programs\Startup\{random1}.lnk

    Where {random1} and {random2} are generated from hashed computer name

    4. Once active, it connects to the following URLs:

    • hxxp://kilopinkad[.]com/bimforum
    • hxxp://bulbushkinho[.]org/bimforum

    It also sends the following via HTTP request:

    &cmd={getload or grab or getproxy}
    &login={computer name hashed}{volume SN}
    &sel={malware version} –> ffbot
    &ver={malware version} –> 5.1


    Figure 6. HTTP request parameters of TROJ_DOFOIL.WYTU

    After a few days, the site changed back to the original benign file (SHA1: 909dc6764355625cb9a98ae45f986439cf3142a6). Note that all file hashes with their detections are mentioned at the bottom of this article.

    As seen above, the exploit kit has the capability to load other malicious software that can be a launch pad of secondary attacks. The initial file that was used (which launched only calc.exe) can be viewed as a preliminary attempt during the first few days of this exploit kit’s discovery.


    The risk of an exploit kit is that it is designed to serve as a ‘door’ opener of any malicious file: cybercriminals can change the malware payload to any that they wanted.

    We have already seen further evolution of this particular threat. Through the use of  the Trend Micro Smart Protection Network, we are able to examine files, some of which have new reference data that currently refers to an active malware. One example of is TSPY_ZEMOT.


    Figure 7. TSPY_ZMOT malware file

    ZEMOT is a malware family of Trojan downloaders frequently used by other malware, often to stage additional malware payload (secondary infections). It is known to be distributed via exploit kits. Based on our data (starting from October 13), the North American region is the most affected region by TSPY_ZEMOT.


    Figure 8. TSPY_ZMOT distribution according to region

    Trend Micro is closely monitoring this threat for any new developments. Our Smart Protection Network protects users from all threats associated with the FlashPack exploit kit.

    The following are the related hashes for this attack:

    • 987d17220ee8936d2dfb58b35a6adc17f7141d50 (TROJ_DOFOIL.WYTU)
    • 6b944b5a06e1dee2bd64d2a35d5c14b304a5eb35 (TROJ_DOFOIL.WYTU)
    • 41ff7407630e575d2b7544f79e8da3378d367470 (TROJ_DOFOIL.WYTU)
    • 2df93253f1aa7ab6e99660629ff58efeae9acbc3 (TROJ_DOFOIL.WYTU)
    • 12de009d00b5e543c9d0b6542f1b03516b076478  (TSPY_ZEMOT.SMN0)
    • 2e65dea705983a8ae2e9b4eecd42816bf4ef7a3a (TSPY_ZEMOT.SMN0)
    • 8792dc1f6351e103eac4662ad927b00b663ff08f (TROJ_FORUCON.BMC)
    Posted in Bad Sites, Exploits, Malware | Comments Off

    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.


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


    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 | Comments Off

    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 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} (
    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, 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 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}/

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


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