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


  • Recent Posts

  • Calendar

    July 2015
    S M T W T F S
    « Jun    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • Email Subscription

  • About Us


    Author Archive - David Sancho (Senior Threat Researcher)




    The past week has seen some interesting news in the world of online security. First, the US government announced that all websites maintained by federal agencies must be using HTTPS by the end of 2016. Second, the Wikimedia Foundation (best known for Wikipedia) announced that they, too, were rolling out mandatory HTTPS for their own sites as well, with full completion expected “within a couple of weeks”.

    With large organizations moving to full-time HTTPS, and browser vendors pushing for it as well (Mozilla has gone on record that eventually, new features will only be for sites running HTTPS), is it time for smaller site owners to make the move as well? Should end users pressure their favorite sites to adopt HTTPS? Will it really help online security?

    The short answer is yes. Site owners should strongly consider enabling HTTPS for their sites. It’s been clear to many people that in the long run, meaningful adoption of HTTPS would increase the security of the Web. Web giants such as Google and Mozilla, plus international bodies like the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C) have all spoken out in favor of this. Sites that are being set up now should use HTTPS from the start. That’s the direction the web is going today, and a site that’s being set up now should be built with the safety and privacy of its users in mind. For existing sites, enabling HTTPS as soon as is practical is something that owners should strongly consider, especially if sensitive data is being handled.

    Another thing to consider for website administrators is that in the long run, search engines may make HTTPS usage part of their ranking algorithms. Google is already doing just that. While for now it’s not a particularly significant “signal”, down the road that could change. It’s a good idea for site owners to get ahead of the curve and move their users to a more secure and private web.

    HTTPS: A Good Start

    It is important to note that while the mandate to adopt HTTPS is a very important step to improve online security, the effort should not stop there. HTTPS is definitely an improvement, but it is not perfect and is far from a cure-all when it comes to online security.

    Think of it as the equivalent of sending a letter in a secure container; a safe, for instance. An attacker could replace the entire container by their very secure but fake safe, steal the letter after it’s opened (steal the decrypted data from the user’s own machine), or send the user a very secure safe with a bomb inside (direct the user to a malicious  site through a secure channel).  HTTPS deals with the issue of security “in transit”, i.e., while the data is being sent across the Internet. It doesn’t solve other problems with online security, and was never meant to.

    These developments to make HTTPS implementation a norm on the Web is definitely a step into the right direction and it is crucial for website owners to follow suit.

     

     
    Posted in Social |



    Steganography will only become more popular, especially among the more industrious malware groups out there. For an attacker, the ability to hide stuff in plain sight is like peanut butter on chocolate: it makes their favorite thing even better.

    In the first two entries of this series, we explored which steganographic techniques are used by attackers to keep malware from being detected, and how they are used to hide command-and-control (C&C) commands, as well as executable code. This time, we’ll discuss the impact of steganography use in the future.

    But first, let me call out several things that came out in the last couple of weeks:

    1. Banking Trojan uses Pinterest as a C&C communication channel – Again, this is not purely steganography, but this is an interesting case since it shows how cybercriminals will try to use common yet unexpected traffic as communication channels. In this case, the banker client is just reading comments in certain pins and decoding them to get the botmaster’s commands.
    2. Janicab Trojan uses YouTube comments as C&C communication channel – This one is self-explanatory. It’s so similar to the previous one that they might even belong to the same criminals, except that this doesn’t have any clear ties with South Korea. Who knows, perhaps steganography is in fashion in the Far East?
    3. Operation Tropic Trooper downloads executable images embedded in image files – This is similar to what we talked about in the last two blog posts of this series, with the main difference being that steganography was used in a targeted attack against organizations sitting in very specific geographical areas. This goes to show that all sorts of attackers are using the very techniques we’ve been discussing here. And the more they do so, the more popular these techniques get. You can get more information on Operation Tropic Trooper in our white paper.

    So when is steganography especially useful for attackers?

    The full impact of steganography use is most felt in targeted attacks. By definition, these kind of attacks aren’t widespread; their specificity may take researchers some time to discover any new techniques used. In a sense, we can think of steganography use in a targeted attack as a zero-day vulnerability: the longer it stays undiscovered, the more useful it is to the attacker. In the case of an actual zero-day vulnerability, it’s also more damaging to the victim.

    Until then, what can we researchers do to try and find new unknown steganographic attacks in the wild?

    The main weakness of steganography in malware is that the “client” software—the part that looks for the data that’s being concealed in unexpected places—is public. And with cybercriminals trying to spread their malware far and wide, it will eventually fall into the hands of good guys like me and other researchers. At that point, it is only a matter of whether or not the researcher knows where and how to look, decode, and decrypt the data. In essence, steganography only helps the malware stay undetected until security researchers get a sample.

    By their very design, these techniques hide stuff in unexpected places. Therefore, we researchers must look in data files and data streams for stuff that’s out of place. Double-checking for protocol messages that are longer than usual, trying to find extraneous encoded data, or even applying machine learning rules to network trace datasets can all be starting points.

    None of this is easy, and we may even receive the malware sample before we spot the hidden data stream. However, if we never try, we will never know. This is my bottom line: searching regular data and trying to find irregularities or anomalies is the only way to beat the attackers. This may not seem doable (or even worth our time) but it’s certainly a good challenge to tackle. Improvements in available algorithms may help in reducing the burden down the road.

    You can check the previous 2 parts of this blog series here:

     
    Posted in Malware |



    In our earlier post discussing steganography, I discussed how it is now being used to hide configuration data by malware attackers. Let’s go discuss this subject another facet of this topic in this post: how actual malware code is hidden in similar ways.

    Security analysts will probably throw their hands up in the air and say, “we’ve had code hiding within code for years now, that’s not steganography!”. That’s not what I’m talking about. I will talk about how steganography is used with seemingly innocuous data files that actually hide binary code. If the differences sound small to you, I don’t blame you. Hopefully these examples will make things clearer:

    DarkComet dropper carries a bitmap… with data inside

    This particular variant surfaced in November 2014 and is relatively simple. It’s a .NET executable with a BMP image file in the resource section. While the image has perfectly valid headers, it doesn’t really show anything meaningful. To human eyes it looks like random pixels in all manner of fancy colors. Perhaps it was a mistake on the coder’s part? No. Actually, the pixels are encrypted code, not designed to be looked at. When the file is run, DarkComet takes the image, decrypts the code, and runs it.

    Figure 1. Contents of the bitmap image file

    What’s the point of keeping code hidden this way? That is a fair question. As long as there is decryption code included in the malicious package – and it has to be there – antivirus software still has something to detect. How is this helping the attacker evade detection?

    This scenario makes more sense if you think about the what’s hidden: an off-the-shelf keylogger. Antivirus software is capable of detecting it even as it is being created, so the cybercriminal is trying to keep a pistol with a red bullseye with neon lights under the radar. Is this something that can be accomplished with regular packing/encryption? Sure, but whoever was responsible thought this would be more inconspicuous. Alternately, he may have just learned about steganography and wanted to try out new things.

    Hiding C&C commands in DNS traffic

    It’s not just code that can be hidden – so can command and control (C&C) communication channels. C&C communication mainly happens through HTTP, and it’s not too difficult to spot. Sometimes attackers will come up with some small innovation that makes researchers like myself respect the technique behind it, if not the motive. A well thought-out steganography technique is usually that kind of thing. Let me show you the following example.

    The Morto Trojan uses a very shrewd way of concealing its C&C traffic. Instead of using HTTP, it uses simple DNS requests looking for non-existent domain names. The queried DNS server (which is the actual C&C server) responds by providing the commands inside the response.

    Figure 2. DNS records

    The text being exchanged is further obfuscated by a simple Base64 encoding. This tries to prevent automated systems from spotting the contents straight away, although it does provide clues, since the payload is longer than it needs to be – and therefore, suspicious. An earlier blog post has already discussed Morto’s details.

    JPG images on websites used by TDSS/Alureon for C&C communication

    The now-defunct TDSS botnet also used an unusual method of C&C communication: requesting JPG images that were hosted on popular blogging sites. These images contained C&C commands that controlled the botnet. These files were very difficult to block for two reasons: they were hosted on legitimate, well-known sites, and the files themselves were still valid image files.For all intents and purposes, the Trojan was downloading real images from a blog. Let’s look at a collage of three of those images:

    Figure 3. Images with commands overlaid on top (via Microsoft Technet)

    When decoded and decrypted, the images contained the botnet commands shown overlaid on the image above.

    ShadyRAT hides C&C communication inside HTML code

    This notorious data-stealing spying Trojan also used blogging platforms as a C&C channel, except that the commands are encrypted and encoded into HTML comments, interspersed with what appears to be legitimate content. This makes the traffic look like it comes from a real user visiting a blog with a regular web browser. In fact, the page is not being displayed at all on the infected system; the Trojan just decodes the information within the comments and is able to understand the commands the attacker is sending. On a cursory look to the actual blog, a visitor would never spot any of this, since the comments are never displayed on the browser either.

    This is a perfect vehicle for these attackers, who are trying to stay undetected for as long as possible. ShadyRAT was the first major targeted attack that was spotted in the wild, and this technique was possibly a contributing factor. The network traffic looks perfectly tame to any traffic observer or security device.

    On top of this, ShadyRAT was also able to decrypt and decode C&C commands hidden within JPG files using the LSB technique as seen in the first entry of this series. A shady one indeed.

    Summary

    So far, I’ve discussed steganography being used to conceal binary code as well as C&C traffic. This is not so much to stop analysts from understanding the information being hidden; it is more to stop researchers from seeing that the information is there at all.

    In my next post, I’ll take out my crystal ball (or tarot deck) and see what the future may bring in this field. Until then, stay safe.

     
    Posted in Malware |



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

    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…

     
    Posted in Malware, Mobile |



    Yahoo recently rolled out a new way for users to access their services without entering a password. Their new system uses a cellphone to authenticate the user. Instead of entering a password, the user receives a verification code via text message on their phone. (The user would have provided their phone number to Yahoo when setting this option up.) Once the user receives this code, they enter it on the Yahoo login page and voilà!, they’re logged in.

    So what’s wrong with this? Is this a wonderful advance in the field of authentication?

    The intentions are good. It is encouraging that online services are putting thought and effort into making their users’ lives easier and more secure. However, a cold analysis of this method finds that it’s not a particularly secure solution.

    Fundamentally, it’s still a single-factor method of authentication. This means that it does not offer any additional security by itself. If the single factor is compromised, you still lose control of your account. In the same way that losing/forgetting your password prevents you from accessing your email, losing or forgetting your phone does the same.

    However, that’s something we already knew. The real question is: is this method more secure than ordinary passwords?

    What this method means is that an attacker who has control of the user’s phone has complete access to his Yahoo account as well. However, some people (like me) forget phones more than they forget passwords. In that case, someone who has my phone would also be able to access my Yahoo account if I left an indication what my Yahoo user name is on the phone. (While the email can be easily accessed from an app, other Yahoo services may be best used via a browser.)

    More than that, text messages themselves can also be intercepted by mobile malware. Sometimes it’s for blackmail and extortion. Other times, it’s to steal online banking transaction codes. Other times, it’s to hide premium subscriptions. It’s not out of the question that a Yahoo user’s account credentials could be stolen in this manner.

    This authentication process can also be used (and abused) for various purposes, for example, if your phone can’t be found but is nearby – if it’s tied to a Yahoo account this way, it can be used as an impromptu phone locator. Similarly, the authentication process can be used to spam or annoy someone who’s tied their phone to their Yahoo account.

    Overall, is it more convenient to use this method? Sure. Is it more secure? Not at all. If you’re going to do this at all, make sure you never forget your phone anywhere – or at least leave it behind less often than you forget your password. Don’t forget to use any security features your phone has (such as screen lock, etcetera) to keep it as secure as possible if it is lost.

    If you do want to secure your Yahoo account, there’s a better way to do so. Yahoo has supported two-step verification since 2011. This also uses a code sent to the phone to log the user in, but this is in addition to the user’s existing password.

     


     

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