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

  • Recent Posts

  • Calendar

    May 2015
    S M T W T F S
    « Apr    
  • Email Subscription

  • About Us

    In the first part of this series, we discussed about the macro malware we have recently seen in the threat landscape. This second entry will delve deeper into the techniques or routines of macro malware.

    Unintended consequences

    Let us put things into perspective – by itself, macros are not harmful to the user. Its intended function is to automate frequently used tasks. The problem lies when cybercriminals abuse the functionalities of macro code to execute malicious routines. Microsoft offers macro protection  within the Microsoft Office suite, but only to some degree. It will inform the user if a macro exists within the Microsoft office file the user is about to open, but it will not detect if the embedded macro is malicious or not. It isn’t supposed to magically protect the user, but rather make them consciously enable or disable the feature that can be potentially harmful.

    That said, we’ll consider the following scenarios of macro files coming into play in a workplace. The first scenario is an environment with end-users who have developed the skill to write small macros to help them with their daily routine. We can assume that the user who receives a  document with macro code would breeze through the prompt and enable the feature or even have the setting Enable all macros on– as it is common within that environment to exchange files with macros.

    The second scenario, which may be more common, involves end-users who have not heard of macros within the Microsoft Office suite. Unaware of the possible risks, and curious to open the file, these users may ignore the security warning and enable macros to view the document. After all, the file may contain items of interest since there were a lot of things to do before opening the file, and maybe the context of the email that came with had an intriguing message.

    Now, in comparison to malicious code that relies on exploits to deliver the final payload, these kinds of malware threats involve a lot of user interaction:

    • Someone has to open the email and read it.
    • The reader determines that the content was indeed something the reader can associate with.
    • Finally, the reader opens the attachment and follows the necessary steps to enable the originally disabled macro feature in Microsoft Word.

    This may all sound a little bit too tedious to get one’s computer infected but it’s not far from the truth. We must come to terms with the fact that, while this is an old technique, the fact that most users today are not aware of this type of threat makes it effective. The most activity we’ve had in the past in relation to macro threats was probably the early 2000’s and this sets us back some 14 years ago. The cautious and wary behavior older computer users have with the experience of living in the era of mass-mailers is something that the current generation had no chance to acquire… except, perhaps, currently.

    The whole is greater than the sum of the parts

    Let’s look at a few examples of what happens in an endpoint that allows macros to run when a malicious Microsoft Word document is opened:

    Figure 4. W2KM_DLOADR.WYG downloading TSPY_DRIDEX.WW
    Figure 1. Deep Discovery log file of W2KM_DLOADR.WYG downloading TSPY_DRIDEX.WW

    The unassuming characteristics of these events may not even stand out if Microsoft Word documents are enabled to enter from the Internet gateway and reach a person’s mailbox, as what all we can see is a download event from one machine. But if we take in the whole picture:

    • Email comes in with the correct email address domain, with a leading email subject and a believable message content, duping the user into opening the Microsoft Office document.
    • Upon opening the attachment, the end-user is presented with clear instructions on how to enable the disabled feature, if it has not been done so yet. Instructions are clear, with so many online references.
    • Nothing seems to happen, and the end-user knows something is wrong and immediately deletes the email.
    • But this is all too late since the desired malicious activity has already introduced persistence into the system – a resident binary file that monitors your banking activity.

    We can see that there’s a lot more going on than just downloading and opening a file. This next BARTALEX example is equally interesting.

    Figure 5. W2KM_BARTALEX.SM execution
    Figure 3. W2KM_BARTALEX.SM execution

    While this is considerably a long list of activities resulting from just executing a Microsoft Word document, a breakdown of the characteristics gives a different meaning:

    • Task automation functionality that is commonplace: batch files (.bat), visual basic script (.vbs), PowerShell script (.ps1) and, of course, the visual basic for applications (VBA) macro that started the execution
    • Built-in command-line utilities to invoke seeming separate events: cmd.exe, ping.exe, and
    • Executing a binary file
    • an HTTP connection that doesn’t stand out

    This breakdown allows us to see what makes the Microsoft Word file malicious in the first place: the misuse of otherwise legitimate components. Similar with targeted attacks, your desktop probably has built-in functionalities an attacker can exploit to make the attack whole.

    In summary

    While the era of macro malware may seem to be coming back, we can’t really say that history is repeating itself since the underlying functionality as to how macro malware worked before pales in comparison to how they’re done today. Rather, it may be that we just stopped paying close attention to it, and the effect of that has finally caught up with us. Addressing macro malware in enterprise environments requires several measures, summarized into three simple items:

    1. Re-check your security policies. Email security policies could have been in place already, and it’s probably a good time to revisit them – or it may be high time to create one if such does not exist. For example, if it’s common within your company to exchange Microsoft Word files that contain macros via email, then identify if such is required from an external party. That way, you can decide how your company would filter email. A policy would allow such content if the email just travels within your company’s messaging infrastructure, but similar content would be blocked from external sources. Of course, there exists the gray area of wanting documents enabled within the enterprise and received from the Internet. If this predicament applies to your environment, consider having Microsoft Office files go through sandbox execution to determine if these files have malicious intent.
    2. Decrease your surface area of attack. Computing devices of today are much more powerful and technologically advanced compared to those in the early 2000’s.While technological advances are generally intended for good use, the misuse of the same can almost be counted on. Being up to date and abreast with all of these changes may be daunting, but a lot of them are well documented:
      • For example, if there is simply no use for PowerShell in your environment, then you may want to consider blocking its execution through the use of Software Restriction Policies or App Locker. If there is no reason for your users to run Windows Scripting Host, then this may optionally be disabled as well.
      • One other thing to consider, like in the case of W2KM_DLOADR, is the fact that Internet access is required. It’s time to assess if the endpoint really has to go online, or if it only needs to connect to the company resources and access the company intranet.
    3. Educate your users. Don’t you ever wonder why incidents seldom occur from within your IT staff? That’s because they’re the most knowledgeable about it. That being said, end-user education plays a big role in ensuring that everyone who deals with these types of content is aware of the risks. Remember any policy is only as strong as its implementation, and it is uneducated users who are first to break it.

    In relation to checking email security policies, Trend Micro enables enterprises to take action of macro-enabled documents through the Email Security solutions in our Smart Protection Suites. Small businesses can also take advantage of a similar feature in our Worry-Free Business Security solutions. For a full list of how to enable macro file scanning on your Trend Micro product, please refer to this page.

    Enterprises can also employ Trend Micro™ Custom Defense™, which is a family of security solutions that enables organizations to rapidly detect, analyze, and respond to advanced threats and targeted attacks. Custom Defense offers behavior monitoring, which can help mitigate threats such as macro malware.


    With additional insights and analysis from Jamz Yaneza, Jeffrey Bernardino and Renato Geroda

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

    Threats that can evade detection are among the most dangerous kind we’re facing today. We see these characteristics in the most challenging security issues like targeted attacks and zero-day exploits. Being able to stay hidden can determine the success of an attack, making it something that attackers continuously want to achieve. In this series of blog posts, we will take a look at one of the techniques used by cybercriminals to evade detection and analysis.

    The Greek word steganos means hidden, and malware loves to hide stuff sneakily. For the bad guys, this is a marriage made in heaven. This is the first of a series of blog posts on steganography and malware. We will explore what steganography is, and how it applies to malicious software today.

    Of course, you can use steganography in real life. An example is putting secret messages in strange places (the image below shows a fun one), but here we’ll be talking about data files and specifically how these can be used and abused by malicious attackers.

    Figure 1. Then-California Governor Arnold Schwarzenegger’s reply to the California Assembly explaining his veto after a legislator insulted him during a speech. The secret message appears when taking the first letter of each line in the main text.

    Not all of the methods I discuss below are traditionally considered as steganography. However, I view the differences as purely semantic. For purposes of this blog series, we will consider “steganography” to be anything that attackers do to hide data in an unexpected channel.

    Hiding data in an unexpected channel has exactly the same result: to fool security researchers into overlooking an innocuous channel, protocol or container where data exchange is not expected (or at least not the kind of data the stego-attacker sends). On to the examples.

    ZeusVM: hiding malware configuration inside JPG images

    A particular variant of ZeuS malware downloaded its settings as a pretty landscape. Yes, a real image. The end of the image contained extraneous data that, when properly decrypted, would become a configuration data file. For all intents and purposes, the image file downloaded is a real image so any security device capturing the communication would only see a beautiful sunset.

    Figure 2. Picture with hidden message downloaded by ZeusVM

    This particular variant was discussed in a March 2014 blog post titled Sunsets and Cats Can Be Hazardous to Your Online Bank Account.

    VAWTRAK hides configuration file in a remote favicon image file

    This insidious banking Trojan has been observed recently hiding its settings in the icon file of a web site. This favicon.ico image is the one displayed by browsers at the left hand side of a URL. Almost every web site contains a favicon.ico image, so security software seeing such a request would never think twice about its validity. On top of this, Vawtrak’s hosting sites are located on the Tor network. This makes them difficult to take down or sinkhole, but that’s a story for another day.

    VAWTRAK’s image hides the message with a technique called LSB (for Least Significant Bits). It consists of altering the colors of the image ever so slightly in order to encode bits of information. For instance, say a given pixel has its color encoded as 0,0,0. This is complete lack of color (i.e., pure black). If the encoded color is changed to 0,0,1 then the pixel would contain one bit of information and become a slightly grayer black (which is undetectable by human eyes).

    Any modified bits can encode the hidden message and anyone with the knowledge that there is a message within the image could retrieve it by performing the reverse operation. Others would simply enjoy the beautiful sunset – or whatever the image happens to show us.

    You can read a full analysis of the steganographic capabilities of VAWTRAK on the SecurityAffairs site. A more complete description of VAWTRAK is also available in the Threat Encyclopedia.

    FakeReg hides malware settings in the app icon

    Websites are not the only sources of icons with hidden data. With at least one malicious Android app (which we detect as ANDROIDOS_SMSREG.A) the main icon (i.e., the one seen on the phone’s screen) – actually contains the encoded info.

    Figure 3. Screenshot of Android icon with the hidden info. The icon has been pixelated due to its pornographic nature.

    The spreitzenbarch forensics blog contains a detailed analysis of this particular threat.

    VBKlip hides data within the HTTP protocol

    The last example I’ll use today is not steganography through image files, but via network protocols. The VBKlip banking Trojan (a threat very specific to Poland) monitors the infected machine looking for Polish bank accounts that have been entered into the machine.

    Once it finds a legitimate account, it replaces the 26-digit number with a different one in order to redirect payments. This new account belongs to a money mule and is received from the C&C in a very unusual way. It initiates a non-sensical HTTP connection to the C&C server which looks similar to this:

    GET g4x6a9k2u.txt HTTP/1.1

    This is a request for a dummy text file nobody cares about. The HTTP response back from the C&C has the meat (note that some of the other HTTP headers have been redacted for brevity):

    HTTP/1.1 400 Site Not Installed
    Server: .V06 Apache
    Content-Type: text/html

    The base64 string in the HTTP headers decodes to a bank account number such as 0101-02020202-03030303030303. (I would like to thank Lukasz Siewierski from the Polish NASK for his explanation of this example.)

    The Polish victim sees a different bank account and sends money to a money mule, instead of to the real recipient. The attackers abused an unexpected channel which is used by VBKlip to sneak in some configuration data. This is not strictly steganography but it fits my definition above: it misuses/abuses an unexpected information channel to include information that a defender would never look there for.

    We have (very briefly) covered what steganography is, and what malware uses it for. We can get an idea whether or not it’s something useful for malicious attackers – hint: it is. Our next post will cover other kinds of information that malware conceals: binary executable data. Until then, be safe…

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

    Now comes a time when we are reminded of why this security warning prompt in Microsoft Word matters:

    Figure 1. Microsoft Word security warning for macros
    Figure 1. Microsoft Word security warning for macros

    I went around my peers this afternoon and asked, “On the top of your head, can you give me a name of an effective macro malware? Better if its entry point was email.” The first common response I got was “Melissa” and a response from a more tenured colleague resulted in the names “WM Concept” and “LAROUX.”  I asked another colleague if they can name a macro malware that was popular around 2005-2008, and that resulted in a trip down memory lane, to the era when macro malware was so effective in the early 2000’s. We remembered how things changed when Microsoft Office’s security settings were set to high, how the malware landscape changed, and how history is repeating itself right now.

    “New bottles for old wine”

    We’ve already seen signs of macro malware in the threat landscape a year ago with the W97M_SHELLHIDE.A and TSPY_ZBOT.DOCM combination. At first, we thought that it was just a chance encounter but, as covered in our recent report on BARTALEX, the method of distributing malware through the misuse of macros has borne the likes of DRIDEXROVNIX and VAWTRAK into computer systems from the latter part of 2014 up to this year.

    What’s more, we noticed that this resurgence of macro malware has a single area of focus: enterprises. Enterprises were heavily affected by a spam outbreak involving macro malware

    We saw that macro malware detections in Q1 2015 drove huge numbers:

    Figure 2. Q1 2015 MS Word and Excel malware detections
    Figure 2. Q1 2015 MS Word and Excel malware detections

    This data is based on feedback from Trend Micro’s Smart Protection Network, representing files that have been detected on endpoints. The following conclusions can be drawn:

    • The two common malware families seen are W97M_MARKER and W2KM_DLOADR.
    • You can see X2KM_DLOADR detections around the start of February.
    • A couple more significant ones like W2KM_DOXMAL and W2KM_MONALIS started showing up on the first and second weeks of March.
    • Finally, W2KM_BARTALEX started picking up middle of February and was seen up to the last week of March and the first week of April.

    We tried to confirm if the systems were running on old environments and found that majority of the desktops are running current versions of Microsoft® Windows, with intermittent numbers for the now-ailing Windows XP and a few server-based installations that are probably file servers:

    Windows Version Percentage
    Windows 7/Windows Server 2008 R2 91.72%
    Windows XP 4.19%
    Windows Vista/Windows Server 2008 2.18%
    Windows Server 2003 0.86%
    Windows 8.1/Windows Server 2012 R2 0.67%

    To add to this, Operation Woolen-Goldfish did employ spear-phishing emails with malicious attachments that were Excel files with an embedded macro. The macro code was instrumental in dropping the .DLL file that instated the malware, GHOLE. Targeted attack campaigns would usually use vulnerabilities that had been determined to be effective on a target, or even zero-day vulnerabilities. This operation, however, had taken a much easier route of using the tired, old method of traditional malware.

    If you take the methods employed by GHOLE, ZBOT, DRIDEX, ROVNIX and VAWTRAK, we’ve all seen them in the past – as well as macro malware and email-borne threats. I’ve read somewhere that the statement “new bottles for old wine” came from the fact that wine sits in a cellar for an extended period of time, waiting for the right time to be bottled. This looks exactly like the same situation: the right time has come and known threats are repackaged with old methods, resulting to what we now determine to be equally effective.

    Our discussion about the macro malware, specifically, their techniques, will continue in the second entry of this series.

    With additional insights and analysis from Jamz Yaneza, Jeffrey Bernardino and Renato Geroda

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

    One of the vulnerabilities recently patched by Microsoft can be exploited in the same way as Heartbleed, and needs to be addressed immediately.

    Addressed in the April batch of Patch Tuesday fixes (in Microsoft Security Bulletin MS15-034, specifically), the Microsoft Windows HTTP.sys Integer Overflow vulnerability, or CVE-2015-1635, is a remote code execution vulnerability that exists in HTTP.sys, or the HTTP protocol processing module in Microsoft Internet Information Service. Integer overflows have long been known as one kind of notorious and fairly old vulnerability – so why the sudden interest? I found that the vulnerability can be easily used for denial of service (DoS) attacks or data leaks similar to last year’s Heartbleed attack, in which information is copied from memory and sent to the client.

    A researcher already published a checker script for this vulnerability on Pastebin and showed how it can be used to carry out DoS attacks or to leak information. Additionally, another researcher published a POC for information leaks.

    Detailed analysis of DoS attacks and Information leak attacks via CVE-2015-1635

    In this blog post I will explain in detail how the vulnerability can be used for DoS attacks and data leak attacks. Before I dive into the vulnerability, let’s introduce some background information.

    Figure 1. Architecture of IIS

    After installing IIS (Internet Information Service) on the system, there is a service named the World Wide Web Publishing Service, which I call the WWW service. When a client sends an HTTP request to the system, the WWW service starts up or selects a worker process (W3wp.exe) based on load balancing policy to process the HTTP request and send the appropriate HTTP response. The file W3wp.exe uses HTTP.sys to do many tasks related to HTTP protocol handling, which include HTTP protocol parsing, response content assembling, and content caching. HTTP.sys receives the HTTP request and sends the HTTP response via TCPIP.sys.

    How can this be used in DoS attacks?

    Let’s prepare a HTTP request to start our DoS journey. The testing environment I used was Windows 8.1 (32-bit version) plus IIS 8.5.

    First, we take the IIS ‘s default web page iisstart.htm (file size 694 bytes) as an example. We compose a HTTP request as follows:

    GET /iisstart.htm HTTP/1.1\r\nHost: aaaaa\r\nRange: bytes=284-18446744073709551615 \r\n\r\n

    The HTTP range request start position is 284, and the end position is 18446744073709551615. The hexadecimal value of 18446744073709551615 is 0xFFFFFFFFFFFFFFFF. The range length is huge—it must be over the size of the requested web page file, which appears suspicious. I will explain later why I selected the start position as 284.

    After the request is sent to HTTP Server, one w3wp.exe handles the HTTP request processing. TCPIP.sys forwards any HTTP protocol content to HTTP.sys. If the request is a HTTP range request, it will call the function UlpParseRange(). The function parses the request to get the requested range’s start position and end position and calculates the range’s length. We can see that the first integer overflow happens in code which calculates the range’s length. The code is as follows:

    Figure 2. Range Length code

    When the end position=0xFFFFFFFFFFFFFFFF and start position=0, the integer overflow happens and the Range Length equals 0. The code does not check whether there is an overflow and does not take the error handling action.

    In our case, the integer overflow does not happen. The end position=0xFFFFFFFFFFFFFFFF and start position=284, while Range Length equals -284, whose hexadecimal value is 0xFFFFFFFFFFFFFEE4. If this is interpreted as an unsigned integer, the value is very huge.

    After finishing parsing the HTTP request, it will call the function UlAdjustRangesToContentSize(). The function adjusts the Range’s start position and length if the start position and length is “invalid”. The definition of “invalid” contains several scenarios which indicate the Range is over the requested web page content. Examples include:

    • Range Start Position is 0xFFFFFFFFFFFFFFFF
    • Range Length is 0xFFFFFFFFFFFFFFFF
    • Start Position >= the requested web page length
    • End Position >= the requested web page length

    The second integer overflow can be found in the last function. It uses the following code to get the Range End Position:

    Figure 3. Adjustment action

    In this case, the Range Start Position equals 284, Range Length equals 0xFFFFFFFFFFFFFEE4, so an overflow happens, Range End Position equals 0 and the adjusted action is bypass.

    If one same request is received continuously, the request‘s response will be cached and will be taken from the cache and sent to the requester. It will call the function UxpTpDirectTransmit().One job of the function is to calculate the HTTP response packet length. The simplified code is as follows:

    Figure 4. Simplified HTTP code

    Using our case‘s value:

    Range Count = 1;
    Range Boundary and Range Info length = 0; // (This will be explained later.)
    Range Tail Boundary Length = 0; // (This will be explained later.)
    Range Length = 0xFFFFFEE4; // (The value is already cast to 32 bit)
    HTTP Head Length = 283;

    The HTTP Response Length‘s result is 0xFFFFFFFF. The whole length is 4G. Systems will consider that this HTTP response total size is 4G. This means that there is a HTTP response packet whose calculated size is larger than the real size. This is why we used 284 as the Range Start Position.

    HTTP Response Length = HTTP Head Length + (Range End Position – Range Start Position + 1)
    = HTTP Head Length + (0xFFFFFFFF – Range Start Position + 1
    = HTTP Head Length - Range Start Position

    If Range Start Position less than <= HTTP Head Length, it will trigger an overflow. The HTTP Response Length value range is [0, HTTP Head Length).

    Because we want to launch a DoS attack, this is not the result we want. We want the HTTP Content Length value to be large. The preferred range for Range Start Position is [HTTP Head Length+1, target page size). In this range, it does NOT trigger an overflow and the HTTP Content Length value will become large, and will then allow a DoS attack.

    After the HTTP response package is assembled, HTTP.sys will forward the packet information to the protocol stack driver to send it. TCPIP.sys‘s function TcpSegmentTcbSend() will traverse every part content of the packet. There is integer overflow in the function. Here is a list of some simplified code:

    Figure 5. Simplified code

    In the above code, line 15 will trigger the overflow. In our case, the HTTP Response Length is 0xFFFFFFFF. The “virtual address’” initial value must be a kernel address ( >=0x80000000). Because HTTP Response Length is very large, the loop will run many times. When the loop has run many times, the “virtual address” will become a very small value after triggering the integer overflow. In the loop, it will use the “virtual address” to build a partial memory descriptor list (MDL). Because the range is not a sub range in the source range, it leads to a Blue Screen Of Death (or BSOD). The DoS attack is complete.

    How can this be used in an information theft attack?

    We prepare a request as follows:

    GET /iisstart.htm HTTP/1.1\r\nHost: aaaaa\r\nRange: bytes=3-18446744073709551615, 1-600"+ "\r\n\r\n"

    The reason for using multiple ranges will be explained later. We take 3-18446744073709551615 as Range1 and take 1-600 as Range2.

    In function UlpParseRange(),the code can be seen in Figure 3. For this case, we have 2 range lengths:

    Range1 Length = 0xFFFFFFFFFFFFFFFF - 0x3 + 1 = 0xFFFFFFFFFFFFFFFD
    Range2 Length = 600 -1 + 1 = 600

    After parsing the HTTP request, it will call the function UlAdjustRangesToContentSize(). The code is in Figure 3. Range1 will trigger integer overflow (3 + 0xFFFFFFFFFFFFFFFD => 0), so bypass adjust action, even if the Range1 Length is invalid. Range2 is valid, so it should not be adjusted.

    If the same request is received continuously, the request‘s response will be cached and will be taken from the cache and sent to the requester. It will call the function UxpTpDirectTransmit() . The code in Figure 4 is executed, using the following values:

    • Range Count = 2
    • Range1 Length = 0xFFFFFFFFFFFFFFFD
    • Range2 Length = 600
    • Http Head Length= 0x127 //HTTP head content, see Figure 6
    • Range1 Boundary and Range1 Info length = 0x7a
    • Range2 Boundary and Range2 Info length = 0x69
    • Range Tail Boundary Length = 0x32; //see Figure 8

    By using a multi-range request, there is a Range bound tag and Range Information (Content-Type, Content-Range) before each range content. (See Figure 7 for this.)

    Figure 6. HTTP Head

    Figure 7. Range boundary tag and Range Information

    Figure 8. Range Tail

    From Figure 4, we can see that HTTP Response Length = HTTP Head Length + Range Boundary and Range Info length + Range1 Length + Range Boundary and Range Info length + Range2 Length = 0x127+7a+0xFFFFFFFD+0x69+0x258+0x32 => 0x491. At line 5 of Figure 4, an integer overflow occurs when 0xFFFFFFFD is added. At this time, the system takes 0x491 as the HTTP response length.

    The memory status can be described as following:

    Figure 9. Memory status

    After assembling the HTTP response package, HTTP.sys will forward the packet information under the protocol stack driver to send it. TCPIP.sys ‘s function TcpSegmentTcbSend() will traverse every part content of the packet (see Figure)

    See the code in Figure 4. In this case, the HTTP response length is 0x491. When handling the part which length is 0xFFFFFFFD, line 7’s condition is met, Part Length‘s value will be set by Remain Length. At that point, Remain Length is 0x2f0 (0x491 – 0x172- 0x7a). It will use [0x3, 0x3+0x2f0] as a buffer range to read and send to client. Our target web page iistart.html has a length 0x2b6. The status is the following:

    Figure 10. Buffer status

    In Figure 10, the red part is the leaked information buffer. Compared with the code in Figure 5, the condition at line 24 is satisfied and breaks the loop. That is to say, the parts after the part which has 0xFFFFFFFD length will not be sent to client. At this point, we can see why we used a multi-range request.

    Using multi-range requests can let the HTTP response length (calculated in step 3) become larger to leak more information. If only a single range is used, the HTTP response length becomes either too big or too small. If the HTTP response length is too big, it will lead to BSOD, as it was described in the previous section. If the HTTP response length is small, it doesn’t make a range to cover the buffer after the target web page content to do information leak. Attackers use many range to leak more information. For example, I created a multi-range request as follows:

    GET /iisstart.htm HTTP/1.1\r\nHost: aaaaa\r\nRange: bytes=3- 18446744073709551615,1-32,32-64, 64-96,96-128,128-256, 129-130,130-140,160-170,180-190, 190-200"+ "\r\n\r\n"

    In the request, I use 11 ranges. The leaked information can be seen in the following picture:

    Figure 11. Information leakage


    Given these attack scenarios, I strongly advise users and network administrators to apply the patch, if they haven’t. Aside from the update provided by Microsoft, Deep Security also protects users from this through the following Deep Security rule:

    • 1006620 – Microsoft Windows HTTP.sys Remote Code Execution Vulnerability (CVE-2015-1635)

    This blog post is a follow-up to our previous blog entry on CVE-2015-1635:
    IIS At Risk: The HTTP Protocol Stack Vulnerability

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

    A new online banking malware with the same technique used in Operation Emmental has been hitting users in Japan. Detected as TROJ_WERDLOD, this new malware has been causing problems in the country since December 2014 with more than 400 confirmed victims.

    This threat changes two settings that allows information theft at the network level (i.e., without using information-stealing malware). This has the advantage of not requiring a reboot or any memory-resident processes on the affected systems.

    One of the two settings modified is the system’s proxy settings. This routes some of the user’s Internet traffic to a proxy controlled by the attacker. The second is the addition of a malicious root certificate to the system’s trusted root store. This allows malicious site certificates added in man-in-the-middle attacks (as done by the malicious proxy) to be used without triggering alerts or error messages.

    This technique of a malicious proxy combined with an added root certificate was also used in Operation Emmental. This attack indicates that the technique has now reached Japan.

    Infection vector

    TROJ_WERDLOD infects users via spam mails with an attached .RTF document. The document claims to be an invoice or bill from an online shopping site. Once the .RTF file is opened, the user is instructed to double-click the icon in the document (as seen below), leading to TROJ_WERDLOD being executed.

    Figure 1. Spam mail leading to TROJ_WERDLOD’s infection

    Setting a malicious proxy

    Once infected, it modifies the registry value at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL to refer to a proxy.pac file which has been prepared by the threat actors behind this banking Trojan. A proxy.pac file contains automatic settings for a system’s proxy servers. This may include JavaScript code to determine which proxy will be used by a system.

    Figure 2. Modified registry setting

    Both Internet Explorer and Google Chrome obey this system setting. Mozilla Firefox uses its own settings (stored in the pref.js file), but this malware targets that setting as well.

    This proxy.pac file is obfuscated and Figure 3 shows the decrypted version. It shows how the network traffic for several domains is directed via malicious proxy servers. The enumerated domains include 26 Japanese domains including several online banks. Because of this, we believe Japanese users were specifically targeted.

    Figure 3. Decrypted proxy.pac file (click to enlarge)

    Adding a malicious root certificate

    Routing network traffic through malicious proxy servers allows cybercriminals to carry out a main-in-the-middle (MITM) attack. However, online banks use SSL/TLS to encrypt their traffic. Using the proxy server to decrypt this encrypted traffic would result in SSL errors at the endpoint, alerting users that something is wrong.

    To get around this, TROJ_WERDLOD can add its own root certificate into the trusted root store of systems. This certificate is disguised as one that belongs to a known (and trusted) root CA, but the signature does not match the legitimate certificate.

    Normally, a security warning will be shown before the fake certificate is added to the trusted root store. However, TROJ_WERDLOD can automatically push the “yes” button of the error message, installing the certificate without the user noticing.

    Making MITM attacks on SSL/TLS possible

    This is how an attack against an online banking site targeted by the attacker would proceed. The list of targeted sites is contained within the downloaded proxy.pac file. Traffic going to any of these sites will be routed through the malicious proxy.

    The malicious proxy performs a MITM attack against the secure connection. Normally, this would lead to SSL errors, as the fake SSL certificate used by the proxy would not be seen as valid. However, because of the added certificate in the root store, no error messages will be seen. The attacker can then intercept any credentials sent to the banking site; alternately the attacker might instead show a fake website and ask the user to enter their credentials.

    SSL/TLS should be able to avoid MITM attacks, but in this case, the presence of the malicious root certificate obliterates the trust model. This leaves the user at risk of attack.

    Countermeasures against TROJ_WERDLOD

    Opening email attachments has long been recognized as an infection vector. It is advisable that users not open these attachments, unless they are explicitly expected by the recipient.

    Many financial institutions have started using EV (Extended Validation) certificates. These will be issued through stricter screening system than normal SSL server certificates. Stricter screening includes checking if the issuer has been registered, or if the issuer can be contacted.

    EV certificates are more reliable than typical Domain Validation certificates, which can be issued to anyone who can prove they own a domain. When the server is using an EV certificate and working normally, a “green bar” is shown in the address bar, as shown below:

    Figure 5. User interface for a site with an EV certificate

    Where possible, companies that already use SSL/TLS for their login pages should adopt EV certificates. Organizations that use EV certificates may, in effect, “train” their customers to spot MITM attacks, protecting both parties in the transaction.

    TROJ_WERDLOD in the future

    As we mentioned earlier, the use of a fake certificate and proxy was previously found in Operation Emmental. That also used fake mobile apps that stole SMS messages from online banks. It is possible that this particular behavior may be seen in the future, although Japanese banks rarely use SMS authentication.

    Remove the infection

    To restore an infected PC to its normal condition, the following steps need to be performed to remove the malware and undo the two setting changes.

    1. Remove the proxy automatic setting (proxy.pac) in Windows and Firefox, or change it back to the previous setting (if one was provided by the ISP and/or system administrator.)
    2. Remove the malicious root certificate installed by TROJ_WERDLOD from the the trusted root stores in Windows and Firefox. (Instructions on how to do so are provided by Microsoft and Mozilla.) This malicious root certificate has the following signature:
      • A134D31B 881A6C20 02308473 325950EE 928B34CD

    Trend Micro solutions

    Trend Micro endpoint solutions such as Trend Micro™ Security, OfficeScan, and Worry-Free Business Security include behavior monitoring to detect this type of threat. File reputation can detect all the malware we encountered in this attack, including TROJ_WERDLOD. Email reputation can block emails from suspicious users and malicious emails. Mail Security gateway products use the content filtering function and enable to filter emails which include executable files as attachments. Web reputation can block accesses to malicious sites where the related backdoor malware connects and communicate.

    The following hashes are related to this attack:

    • 17ca16506b4a1a92b9e4c5fb809f425c7b670bb8
    • 36ca118945ee4d9ba60c9178b47ea0a5d9547b7b
    • 3860DC86D0300B9C38C4029C8C6DA2D0014695EE
    • 46070ec0b7d4e1b7d6d8152bb1d1e6e7475c5b20
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  


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