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

    If you’ve read enough crime novels or seen enough action movies, the plot is all too familiar to you: an insider – acting to correct some slight or insult he or she received years ago – turns against an organization and inflicts significant damage. Sometimes the insider is on the side of the good guys, sometimes on the bad guys.

    This makes perfect sense. An insider knows exactly how an organization does things, what they consider valuable, and how they will respond to an attack. Who else would be better to carry out an attack than an insider?

    However, that assumes that an “insider threat” is by design. Fortunately, most people are not out to destroy the organization they belong to. Most people want the group that they are part of to succeed and do well. Unless you’re in an organization that deals with national security, this is probably something you don’t have to worry about.

    The problem is that not all “insider threats” are deliberate. “Insiders” could end up leaking information to attackers inadvertently. Social media has provided users with many new and interesting ways to communicate, and unfortunately sometimes this includes confidential information that shouldn’t be communicated.

    If people are already leaking information online, what more if you have a social engineer trying to squeeze information from others? Social engineering can be defined as the art of getting others to do what you want. It’s an art that’s been practiced in one way or another for thousands of years, so it shouldn’t be a surprise that threat actors have become very good at it.

    Almost all targeted attacks begin with some form of social engineering. While it is not a simple task, you can – and should – attempt to defend against these types of attacks.

    There are two ways that an organization can defend against these attacks, but these ways are not mutually exclusive. First, there are technical means of defense. For example, email blocking can help prevent attacks that are designed to impersonate other parties (such as banks or other trusted organizations.) Heuristic- and email reputation-based solutions are useful in this regard.

    The second way is to harden your users. Teach them to be more careful, vigilant, and aware of the threats going on today. Make sure that instead of just ignoring these attacks, they report them to your own security team so that the entire organization can stay aware of what’s going on.

    Even more important than how to protect data is deciding what data to protect. It is difficult, if not impossible, to protect everything. What you need to decide is: what matters most to your organization and needs to be protected? I would recommend using three categories:

    1. Data which is not sensitive
    2. Data which has a negative impact on your organisation if leaked
    3. Data which destroy your business if leaked

    This organization sounds simple, but a lively debate is likely to ensue when classifying which data goes in what category. However, this is necessary: you need to figure out what is really important and what is core to your organization. Protect that first before anything else.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    Enterprises are currently being targeted by the macro malware BARTALEX in a recent outbreak of thousands of spammed emails. The infection routine for BARTALEX uses a Microsoft Word document and social engineering lure that is widely recognized by enterprises—making infection all too possible. This attack highlights how macro malware in Microsoft Office files is fast becoming a big threat to businesses and organizations.

    BARTALEX Infection Chain

    In this attack, a colleague of mine noticed an outbreak of spammed messages all related to Automated Clearing House (ACH) fraud. ACH is a network used for electronic fund transfers in the United States; as a result it is frequently used by businesses that need to transact with other companies on a regular basis.

    ACH fraud is a typical cybercriminal hook seen in spammed emails. Instead of attachments,  the message this time bore a link to “view the full details.” Other templates used for these spammed emails involve messages about received fax messages, parcels, invoice and billing statements, and wire transfers.

    Figure 1. Sample spammed email that leads to W2KM_BARTALEX.SMA

    By hovering over the URL we can see that it redirects to a Dropbox link with a file name related to the supposed ACH transaction. The URL leads to a Dropbox page that contains specific instructions (and an almost convincing) Microsoft Office warning that instructs users to enable the macros.

    This malicious document is detected as W2KM_BARTALEX.SMA. As of this writing, more than a thousand similar Dropbox links were found with the same routines.

    Figure 2. A Dropbox page contains the malicious macro (click to enlarge)

    Upon enabling the macro, the malicious document then triggers the download of the banking malware TSPY_DYRE.YUYCC. This DYRE variant targets banks and financial institutions in the United States, among which are JP Morgan, U.S. Bank, California Bank & Trust, Texas Capital Bank, etc.

    Based on feedback from the Smart Protection Network, the United States is the top country affected by BARTALEX malware overall, followed by Canada and Australia. Additionally we noticed that this attack used an old Microsoft Office 2010 logo. Given that many enterprises do not immediately upgrade to the latest Office versions, it is possible that users within enterprise organizations may fall victim to this technique.

    Figure 3. W2KM_BARTALEX infection count over the last three months

    Malware Improvements

    This latest observation is but another development for both BARTALEX and DYRE. We previously reported on BARTALEX malware that were attached to spammed emails.

    In January this year, we wrote about improved DYRE infection techniques. These techniques involve hijacking Microsoft Outlook to spread UPATRE, which inevitably download data stealing malware ZeuS and ransomware.

    Dropbox not new to malicious activity

    This isn’t the first time that Dropbox was reported to have been involved in malicious activity. Dropbox and other cloud-based services are known to host malware and cybercriminals’ C&C software, but this is the first time we’re seeing Dropbox used to host macro-based malware, which is rapidly increasing despite its being a thing of the past.

    We have already contacted Dropbox about the more than a thousand links hosted on their site.

    Macro malware still in the picture

    Macro malware like BARTALEX is seemingly more prominent than ever, which is an indicator that old threats are still effective infection vectors on systems today. And they seem to be adapting: they are now being hosted in legitimate services like Dropbox, and with the recent outbreak, macro malware may continue to threaten more businesses in the future.

    Addressing macro malware in an enterprise (and small and medium-sized business) setting involves reevaluating and revisiting existing security policies. It’s also advisable to decrease the attack surface area by making sure systems within the corporation have the necessary security measures in place: for instance, it may be wise to disable Windows Scripting Host on users’ systems if it serves no substantial purpose. Lastly, user education will go a long way in defending against these types of threats, in particular, those that exploit human error, e.g., enabling malicious macros in Word documents.

    The hashes of the files detected as W2KM_BARTALEX.SMA are:

    • 61a7cc6ed45657fa1330e922aea33254b189ef61
    • 6f252485dee0b854f72cc8b64601f6f19d01c02c
    • 85e10382b06801770a4477505ed5d8c75fb37135

    The hash of the files detected as TSPY_DYRE.YUYCC is:

    • 5e392950fa295a98219e1fc9cce7a7048792845e

    The hashes of the malicious Microsoft Office documents are:

    • 0163fbb29c18e3d358ec5d5a5e4eb3c93f19a961
    • 02358bcc501793454a6613f96e8f8210b2a27b88
    • 05fe7c71ae5d902bb9ef4d4e43e3ddd1e45f6d0c
    • 11d6e9bf38553900939ea100be70be95d094248b
    • 19aed57e1d211764618adc2399296d8b01d04d19
    • 559a03a549acc497b8ec57790969bd980d7190f4
    • c0ca5686219e336171016a8c73b81be856e47bbc
    • d047decf0179a79fd4de03f0d154f4a2f9d18da4
    • d3bf440f3c4e63b9c7165c1295c11f71f60b5f8c
    • ec7a2e7c1dce4a37da99a8f20a5d4674f5c80a1f

    Additional analysis by Cris Pantanilla, Francis Antazo, Jay Yaneza, and Maydalene Salvador

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    We have found an interesting discrepancy in how the Angler exploit kit targets Adobe Flash.

    The Angler exploit kit is known for its use of various Adobe Flash Player exploits. Reports have indicated that Angler has started targeting CVE-2015-0359, a vulnerability that was fixed in Adobe’s April 2015 update. CVE-2015-0359 is a race condition vulnerability that occurs because ByteArray::Write is not thread-safe, and it requires many workers to trigger. However, in the sample that we analyzed, the current exploit used by Angler is a use-after-free (UAF) vulnerability related to domainMemory and is easier to trigger, opening the possibility that an already known and patched vulnerability is being exploited.

    Execution Flow

    Instead of CVE-2015-0359, the execution flow of the Flash exploit that we saw is very similar to that used by CVE-2015-0313:

    1. shareable ByteArray object is set to be shared between the main thread and worker thread by calling setSharedProperty.
    2. Set this shareable ByteArray object memory to domainMemory.
    3. A worker thread gets the shareable ByteArray object through worker shared property by calling getSharedProperty, and the execution flow is dependent on the Flash player version. If the version of Flash present is vulnerable to CVE-2015-0313 vulnerability, it then calls ByteArray::Clear; if not, it calls ByteArray::WriteBytes

    Figure 1. Difference between this sample and CVE-2015-0313

    The difference between this new exploit and CVE-2015-0313 is that it will call ByteArray::WriteBytes to cause the underlying buffer change, and this change is not notified to domainMemory (which will still point to the freed memory). This will cause a UAF vulnerability. An attacker can use intrinsic instructions to read and write from the freed memory address. In effect, it is the same kind of flaw as CVE-2015-0313, except a different function is called to trigger it.


    It is not clear why it is thought that the newer exploit used by Angler targets CVE-2015-0359. Perhaps it may have been a happy coincidence that the fix for CVE-2015-0359 also fixed this UAF vulnerability; given that the race condition vulnerability does use the ByteArray::WriteBytes function as well that is a distinct possibility.

    We are working with Adobe to clarify the scope of this vulnerability.

    Additional analysis by Brooks Li and Joseph C. Chen

    Related SHA1 of the Flash sample is as follows:

    • E0C46A5BF1F98C0BF5F831E7AD1881502809DA93
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    Unpatched versions of Microsoft’s Internet Information Services (IIS) web server are vulnerable to a remote denial of service attack that can prove to be very threatening if set against critical systems.

    The vulnerability, which was fixed by Microsoft in MS15-034 as part of the April 2015 Patch Tuesday cycle, can trigger the blue screen of death or more commonly known as BSOD. While there are no indications of possible remote code execution, it is still very important for users to apply the update, especially in systems that require 100% uptime.

    The following versions of Windows are at risk:

    • Windows 7
    • Windows Server 2008 R2
    • Windows 8/8.1
    • Windows Server 2012/2012 R2

    What is the HTTP Protocol Stack?

    The IIS web server has an HTTP listener as a part of the networking subsystem of Windows. This is implemented as a kernel-mode device driver called the HTTP protocol stack (HTTP.sys). It parses the HTTP request and provides a response to the clients.

    HTTP.sys provides the following benefits:

    • Kernel-mode caching. Requests for cached responses are served without switching to user mode.
    • Kernel-mode request queuing. Requests cause less overhead in context switching, because the kernel forwards requests directly to the correct worker process. If no worker process is available to accept a request, the kernel-mode request queue holds the request until a worker process picks it up.
    • Request pre-processing and security filtering.

    For this vulnerability to pose a risk, kernel caching should be enabled in IIS. This is enabled by default in IIS. Several modules in IIS perform tasks related to caching in the request-processing pipeline. Caching improves the performance by storing the processed information (such as Web pages) in memory on the server, and the same data is reused when requested by other requests. IIS Manager has a feature called “output caching”, which is controlled using the following settings:

    Figure 1. HTTP request that will trigger vulnerability

    Exploit and Attack Scenario

    This vulnerability is exploited using the Range HTTP header. This HTTP header allows clients to request specific contents from server at their demand. For example, a client that only needs few bytes of a file, can opt only to request specific parts, instead of the entire file. RFC 2616 (which defines HTTP) explains the definition of Range headers. There is a corresponding header (Accept-Ranges), which is used by servers to notify clients that they are supporting the Range header.

    Typically, the Range header contains values like this:

    Range:  bytes=124-5656

    It could also have values like this:

    Range: bytes=0-

    If the upper bound in the Range header isn’t present, it is considered that client is requesting the complete data. This is as good as not using the Range header at all. What if instead, a very high upper bound is specified by the attacker?

    All an attacker would have to do is send a specially crafted HTTP request with a special Range value, which would cause an overflow of the Range variable on the server. This is already being done by publicly available exploit code:

    Figure 2. HTTP request that will trigger vulnerability

    The cURL command can also be used as below to send the same exploit:

    $ curl -v  -H "Host:" -H "Range: bytes=0-18446744073709551615"

    The upper bound of the Range header is 0xFFFFFFFFFFFFFFFF, which is the largest 64-bit unsigned integer. The large value specified above will cause an integer overflow. A vulnerable server for such request reply with HTTP status line as “Requested Range Not Satisfiable”.

    Figure 3. Reply to exploit code by unpatched server

    This means that that the client asked for a part of the file that lies beyond the end of the file on the server. A successful attack could cause BSOD, leading to a denial of service. Microsoft has said that this vulnerability could lead to remote code execution, although no exploit that is capable of this is publicly known.

    After the fix, the HTTP headers are now checked for errors. A different error is returned if the same attack as before is sent:

    Figure 4. Reply to exploit code by unpatched server

    A response that includes the string “The request has an invalid header name” indicates that server is patched and attack it will fail. Proof-of-concept code is already using this information, as seen below:

    Figure 5. Proof of concept source code


    This is a very easy vulnerability to exploit. A remote unauthenticated attacker could easily perform remote denial of service attacks on web servers running a vulnerable version of IIS. While remote code execution exploits are not known, there is a possibility of such exploit appearing in future. Administrators are advised to apply the patch; if that cannot be done immediately disable IIS kernel caching is a possible workaround.

    We have released the following Deep Security rule to protect Trend Micro customers:

    • 1006620 – Microsoft Windows HTTP.sys Remote Code Execution Vulnerability (CVE-2015-1635)
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    An 18-year-old vulnerability called Redirect to SMB has been resurrected with a new attack vectorThis vulnerability can be used to redirect a victim to a malicious Server Message Block (SMB) server, without any direct action from the user except visiting a website.

    If the SMB security policy is not secure enough, the SMB client will try to make an authenticated request to the malicious server and send credentials through the network. Even if the SMB credentials are protected by encryption, today a state of art brute force attack can recover the credentials in many cases.

    This new vector to the old vulnerability now uses its location header as “location: File://” The file:// protocol handler works in HTTP using tags such as <img> and <iframe>.

    It is important to take in consideration that this vulnerability is just a new vector for a very old pre-existing vulnerability. According to our research, the vulnerability affects Internet Explorer; however, applications using Windows API functions (available via urlmon.dll) are also vulnerable.

    This attack can now be carried out without any user interaction. For this vulnerability it is very important to understand what “HTTP Redirection” is.

    HTTP Redirection

    Redirection is one way to make sure that users always receive the web page that they want. It refers to the process of configuring the web server to issue a redirect message to the client (such as HTTP 302 Found response), which instructs the client to resubmit the request for a new location. The user can be redirected to another file, directory or site.

    Redirection is helpful in the following situations:

    • The location of the website has changed, and users should be redirected to the new site.
    • The website is under construction and part of the site should be unavailable.
    • The content is not located on the web server.
    • The name of a virtual directory has changed, but users should still be able to access files from the old URL.

    Redirection is implemented in the HTTP protocol using the Location header. This is usually is used in combination with some HTTP error messages like 301, 302, and 307, but may be possible using other methods.

    Possible Attack Scenario:

    If an attacker can convince a user to click on a link to a malicious site under the attacker’s control, this vulnerability can be exploited. One possible way of doing it is using HTTP redirection using the Location header in the HTTP response. Another possible way – which has been known for some time – is to use a link on the attacker’s site itself which the user is enticed to click.

    Execution of Attack vector

    The Redirect to SMB attack is a very old attack originally discovered by Aaron Spangler, who found that a user can be redirected using the file://handler. This could be used in an image, iframe, or any other web resource controlled by an attacker.

    The HTTP Location header could be used to redirect the user. The attack can be executed as shown in the following screen:

    Figure 1. Attacker redirecting victim to the malicious file

    The victim’s browser on Windows, when it receives the HTTP redirect response with a Location header pointing to the URL starting with file:// automatically initiates an SMB request to the specified server. Presumably, this would be an SMB server under the attacker’s control. All the clients not having a security policy for SMB shares could be vulnerable to this SMB redirect attack vector.

    This attack can also be used with other SMB vulnerabilities to compromise the victim’s machine and gain foothold in the network.

    Figure 2. Attacker redirecting victim to the malicious file

    In the above picture we can see, the SMB redirect after the HTTP 307 response.


    This is a very old vulnerability which has a new attack vector. Compared to the older (known) vector, this new vector is much easier to target as it doesn’t require user interaction. A man-in-the-middle attack can also exploit this vulnerability very easily. Microsoft has not released a patch for this vulnerability, although they stated in 2009 that an appropriate solution would be to block outbound traffic from ports 139 and 445, which would prevent any SMB connections from being made.

    Trend Micro Deep Security protects users from attacks that may use this attack vector via the following rule:

    • 1006631 – Identified File Protocol Handler In HTTP Location Header


    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  


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