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 - David Sancho (Senior Threat Researcher)

    Breaches, breaches everywhere. There has to be a reason for it – criminals aren’t just following a trend like a spring shopper buying the latest styles of shoes. If you put yourself in the shoes of a cybercriminal (not the spring shopper’s), you’ll be able to appreciate how breach data equates money in a number of ways.

    If a hacker manages to steal a long list of a few thousand names with their respective social security numbers, they can get pretty good money for it in the underground black market. The possibilities for such a list are pretty open: imagine how scammers and fraudsters can make use of that information. Now, imagine if the list includes names with their respective emails. Money too, right? Now imagine names, emails and passwords. Better yet, imagine all of them put together. Now imagine the list is for millions of names, instead of thousands. Yes, a gold mine that can even be sold multiple times to different gangs of fraudsters.

    But cybercriminals haven’t just determined now that this is something good and they should grab this data. They’ve been doing this for years. It’s just that their standard way of doing it has changed: a few years ago, they used Trojans to infect their victims and steal their credentials – they still do that, it’s as good a way as any.

    What’s been gradually changing in the cybercriminal landscape in the latest times is that the bad guys have come to the realization that bulk data stealing is more effective when performed at the source. A botmaster can steal email credentials from every one of their bots – normally counting in the thousands – but if they instead hack the email providers, they could potentially get millions of them.

    Enter the second factor to this equation: the difficulty level to hack. I’m guessing that hacking a big email provider or a bank is pretty complicated but how about those high street retailers that handle thousands of transactions a day? Logic states that they should be difficult as well but apparently, not so much. These retailers fall in the sweet spot between the amount of data they hold and their hindered security level due to the sheer complexity of their operations. Oh, my! The criminals are hitting the jackpot so often with them that it would be funny only if it wasn’t our credentials they’re plundering.

    Among those big retailers are also hotels for pretty much the same reasons. I wouldn’t be surprised if next in line are some bookstores, restaurants, coffee stores or *gasp* gas station chains. Retailers need to realize that they are pretty high up on the target list and they need to start securing their networks sooner rather than later. The loss of reputation that any of these breaches entails should be enough incentive to act quickly by securing any and all data they process. No excuses.

    One of our recently released papers, Point of Sale System Breaches – Why The Retail and Hospitality Industries Need Better Security presents more details about this topic, along with information on how such attacks are executed, and the tools used.

    For more details on various targeted attacks, as well as best practices for enterprises, you may visit our Threat Intelligence Resources on Targeted Attacks.

    Posted in Targeted Attacks | Comments Off

    Last week, it was reported that some Android devices could be wiped remotely if the user unwittingly clicked on a link. Since then, Samsung has announced that for the Galaxy S III the issue was already fixed in the last update and urged customers to update their devices accordingly.

    While the speed of Samsung’s response was commendable, what was left unsaid highlights the complicated environment of Android updates – and why it hurts the security of ordinary users.

    Simply put, it is very difficult to push updates for Android devices. Three parties are involved: Google, the phone manufacturer, and the carrier. In theory, the Android Update Alliance (an initiative of Google and its Android partners) is supposed to ensure that Android phones and tablets get updates for at least 18 months after they are introduced.

    The actual situation can vary wildly: some carriers and manufacturers, for example, are notorious for being slow to roll out updates. Other devices – particularly low-range devices – are neglected and rarely, if ever updated. “Fragmentation” is not just a problem for app developers; it could lead to serious security risks as well.

    Consider this issue at hand. This was two features (calling a phone number via the tel:// protocol, and the ability to wipe a phone via a USSD code) that collided in an unfortunate way. Looking at Android’s source code history, it was fixed at least three months ago by somebody working for Google. What about phones running older Android versions such as Gingerbread (Android 2.3)? It was last updated in September 2011, and yet accounts for more than half of all Android devices in use today. Some of them may not be vulnerable for other reasons (such as custom dialers), but many users are still at risk.

    The danger isn’t so much this particular vulnerability. There are other ways to mitigate it aside from an Android patch. (An aside: ignoring tel:// and other unusual protocols would have been a good way to secure users from this threat, and it would have been a perfectly sensible feature to include.)

    The real danger is when Android is hit by a widespread zero-day, execute-arbitrary-code vulnerability – similar to what hit Internet Explorer and Java in September. Users would then be left with two unpalatable alternatives: risk using a vulnerable device until it’s patched (if ever), or spend money on a new, secure device. Either way, it would be a disaster both for users and Android as a whole.

    Google needs to find a way to ensure that security updates can be delivered to as many Android devices as possible in a timely manner. It sounds like a simple task, but it isn’t: it would involve coordination with both carriers and device manufacturers. Serious re-engineering of Android itself may even be necessary. However, it’s something that is necessary: sooner or later, people will wish that it was easy to patch vulnerabilities in Android. Better that it’s done now, before there’s a significant threat – rather than in the middle of a security disaster for millions of users around the world.

    Posted in Mobile | 1 TrackBack »

    During one of our brainstorming sessions looking for interesting research projects, our group thought about how most mobile applications are, in essence, “browsers-in-a-box”.

    Let me explain. When you open your favorite app, chances are it tries to access certain web pages and display the results in a certain way. Not all mobile apps do this, just most of them. I’m not only talking about those Amazon or eBay apps (which obviously do behave like browsers that limit their queries to their specific servers) but also apps like Flipboard. I love Flipboard, but at the very core of it, it’s just accessing Facebook and Twitter and displaying it in a pretty way (okay, very pretty).

    Can this make apps more vulnerable to something that regular browsers are expecting users to do i.e. behaving unexpectedly? For instance, if an app is performing canned requests to a single specific site, can someone take advantage of this behavior to subvert the app or the site?

    I set out to work on this and created an environment to sniff all traffic coming to and from mobile applications both in Android and iPhone/iPad environments. I tested lots of apps, checking their traffic and looking for something that might be exploitable and I did find things.

    There is one particular resource management game a friend recommended that apparently is very popular. It turns out this game rewards players with a prize every weekend. They don’t do that anymore and it might be my fault, although I never contacted them directly. The way this worked is as follows: if you liked the game’s manufacturer on Facebook, they would share with you a certain password that would unlock resources only during a particular weekend. They’d change the password every weekend and it would only work during those two days.

    The way this was implemented was by means of a plain HTTP request ‘here is the password’ and response ‘here is 10 gold and 10 food for you, thank you’. In other words, you could alter the state of the game from the outside by means of a simple, unencrypted HTTP request. Spoofing the server to point to a local server in the lab setup and getting a fake response of ‘here is 10000 gold and 1000 food’ was, of course, trivial. If ever I’ll see my friend again and show him my progress, he’s going to be quite amazed.

    The bottom line of this mini-attack was clear: unprotected canned HTTP is not trustworthy.

    There were other problems in different applications, like a fitness application that sells exercise routines to be displayed in your Android device. The routines consist of exercise descriptions, images, trainer explanations with instructions, timings and order of each routine. All these materials are contained in an XML file with links to each image and sound file. Yes, you guessed it, the XML was downloaded in plain-text, unencrypted HTTP traffic. I could have tried to access the paid content by guessing the XML file names but I didn’t try.

    I saw some others but my problem with the whole project came when I had to put my findings in writing. The problems I found were so heterogeneous that it was difficult to differentiate this project from any web application pentest. So the clients are mobile applications but I was really looking at somebody’s unsecure web code. At the end of the day, my starting axiom was too true: all mobile apps are essentially web clients therefore they are as unsecure as a browser and that’s how you should treat them.

    A failed project, I hear you say? Perhaps, but it opened my eyes with respect to how we – and app developers – need to treat mobile applications as untrusted browsers-in-a-box.

    Coming Soon: The TrendLabs Security Intelligence Blog will be the new Malware Blog

    Posted in Mobile | Comments Off

    The Police Trojan has been targeting European users for about a year. It should come as no surprise that the latest incarnations of this obnoxious malware have started targeting the United States and Canada.

    In the latest batch of C&C servers we have analyzed, not only has the list of countries increased but also their targets are now more specific. For instance, UKash vouchers are not available in the U.S., thus the U.S. fake police notification that spoofs the Computer Crime & Intellectual Property Section of the U.S. Department of Justice, only mentions PaySafeCard as the accepted payment method. The criminals also took the time in adding plenty of logos of local supermarkets and chain stores where the cash vouchers are available.

    Beyond the facade of this criminal attack, we know there is a Russian-speaking gang, which we theorized in our last paper, that had a link to the new Gamarue worm making the rounds in recent months. We can now add another compelling link: the fake police domain announced by the Trojan, has the same registrar as the confirmed Gamarue worm C&C server The first time a researcher sees such a link, it might just be pure coincidence. The second and third times, the link starts to solidify.

    What is becoming crystal clear is that the same Eastern European criminal gangs who were behind the fake antivirus boom are now turning to the Police Trojan strategy. We believe this is a malware landscape change and not a single gang attacking in a novel way. We also found C&C consoles that suggest a high level of development and possible reselling of the server back-end software used to manage these attacks. Police Trojan attacks are here to stay – until they are done milking this cow and have to look for a fatter one, that is.

    You can read our full report on the Police Trojan in Security and Intelligence section of the Trend Micro website.


    In recent months European internet users have been plagued by so called Police Trojans that lock their computer completely until they pay a fine of 100 euros. Yes, a fine: it does its threats by posing as the police forces of the victim’s particular country and in the victim’s language. This bullying strategy seems to be paying off because there’s no shortage of infections in the European countries affected by this Trojan.

    We’ve taken a deeper look into the inner workings of this Trojan as well as the network infrastructure that its owners are using to control and receive the payments. We found ties with different malware campaigns dating back to 2010, from Zeus and CARBERP to a fairly recent newcomer to the malware scene called the Gamarue worm.

    The same people peddling this Trojan are also heavily involved in other malware and are very invested in this business. For instance, we have found that they were affiliates of the DNSChanger Trojan program called Nelicash that Rove Digital was sponsoring for a few years. The main persons behind Rove Digital were arrested on November 8 2011 after a two year investigation by the FBI, the NASA Office of the Inspector General and Estonian police in collaboration with Trend Micro and other industry partners. So we might have found an important clue who is behind the police Trojan.

    These criminals are in it professionally and will continue to be because of how much money they are able to make. This is a perfect example of one such group that has found a way of extorting money out of unsuspecting Internet users. We have written an extensive report on the Trojan and the people behind which you can download to get the full picture of this criminal organization.

    Click for larger view



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