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

  • Recent Posts

  • Calendar

    June 2014
    S M T W T F S
    « May   Jul »
    1234567
    891011121314
    15161718192021
    22232425262728
    2930  
  • Email Subscription

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

    Archive for June, 2014




    TROJ_UPATRE, the most common malware threat distributed via spam, is known for downloading encrypted Gameover ZeuS onto affected systems. This ZeuS variant, in turn, is known for its use of peer-to-peer connections to its command-and-contol (C&C) servers.  This behavior has been known about since October 2013.

    We have observed that these specific ZeuS variants are now employing non-binary files. The UPATRE downloader is also responsible for decrypting these malicious files. This is done to bypass security features and avoid detection and removal from the infected systems.

    Previously, ZBOT malware can be detected via its header with ZZP0 even though it is initially encrypted by UPATRE. However, in our recent findings, it is found that ZeuS dropped this header and now uses random headers and changed its file extension, thus making it arduous to be detected in the network.

    Here is one particular example of these random headers:

    Figure 1. Random headers

    The decryption of these files starts from the 5th byte onwards using a key found in the TROJ_UPATRE downloader. The sample shown below uses 1b23fed8h as the XOR key. After performing the XOR routine, the file shows compressed version of the executable file. The XOR key used for decryption varies in each sample.

    Figure 2. Portion to be decrypted highlighted

    To get the actual executable file, the UPATRE variant uses the RtlDecompressBuffer function on the decrypted portion of the file. You end up with the original executable, as seen below.

    Figure 3. Original executable

    UPATRE is continuously developing not only in terms of effective social engineering lures such as the abuse of Dropbox links to lead to ZBOT, NECURS, and just recently, Cryptolocker.  This improvement can also be seen in the use of XOR key to decrypt the downloaded file.

    We can say that the cybercriminals behind UPATRE are aware that their tactic of encrypted downloaded file is already detected by security solutions. As such, they continually modify their algorithm to circumvent efforts to detect and mitigate the risk posed by UPATRE. We’re monitoring this threat for any further developments.

    As a downloader, the main function of UPATRE is to deliver the main payload: Gameover ZeuS. In the past, the Pony loader and Cutwail spam botnet was used to download GoZ malware.  Just recently, Trend Micro researchers took part in the efforts of FBI to takedown activities of Gameover ZeuS. While these efforts significantly affected the operations of Gameover ZeuS, we’re continuously monitoring and investigating these threats (ZeuS, UPATRE) so as to proactively protect our users.

    With additional insights from Lord Alfred Remorin

    The SHA1 hashes of the files with this behavior we’ve seen are:

    • 01FD900D3CF7E372CE32C5BEA36286644321095D
    • 94B53631F936F5B1C1B2A6B97A430EC2291FE321
    • A12AB11823B90A16E468294B901805B720797815
     
    Posted in Bad Sites, Botnets, Malware | Comments Off



    One of the reasons that mobile OSes such as iOS and Android are more secure than their desktop counterparts is that they include very robust controls over app permissions. Each app requests from the user and operating system permissions that, in theory, are limited to what they need.

    As applied, they have not always worked. App developers tend to ask for more permissions than they need; users don’t always pay attention and will approve just about anything. Still, for all the faults of the permissions system, it was there, and users who wanted to be particularly careful about app permissions had a useful tool at their disposal.

    Unfortunately, however, it turns out that Google has changed the permissions model of Android in a very fundamental way, significantly reducing its visibility and usability to users. It leaves much more room for malicious app developers to update their apps to add potentially risky permissions to their apps.

    How was this done? Developers in various Android discussion forums found that the update to the Play Store – rolled out in mid-May – had also changed how permissions and app updates were handled, and not in a good way.

    Previously, if an update to an app meant that it required new permissions, the user would have to explicitly review the permissions and approve it, as if a new app was being installed. That is no longer the case. Now, if the requested permission(s) are in the same group as one the user has granted access to, this explicit approval is no longer necessary. If app auto-updates is turned on, the app can update in the background without the user being aware of the changed permissions.

    These permission groups are documented in the Android developer site. The groups are built around functionality; for example all permissions that deal with location services are in one group. The permissions for the wallpaper are in another; the permissions dealing with storage are in yet another. 31 groups in all are defined in the developer documentation, but a total of 13 are explicitly named by Google in an FAQ discussing this topic.

    This is all well-meaning – it streamlines the permissions process and makes it simpler for the user. However, it can be highly problematic. It is now easy – trivial, even – to construct an app that starts out with clearly “innocent” permissions at first, then later integrated the permissions necessary for potentially malicious behavior. For example, permissions to use the flash and recording audio/video are under the same group. In effect, a flashlight app can be easily updated to become a recording/stalking app without the user noticing the change. Other permissions that belong to the same group include:

    • Reading the contents of the external storage
    • Modifying or deleting the contents of the external storage
    • Formatting the external storage
    • Mounting or unmounting the external storage

    Using the list above as an example, an app with the permission to read the contents of the external storage can easily be “upgraded” to having the capability to change or remove content.

    In general, because Google has built these groups around specific features and functions, reading and writing permissions tend to be lumped together. In effect, by giving any app the permissions to read something, we are giving that same app the permission to modify something. This sort of flies in the face of what we would consider normal behavior: if I lend something to a friend, I generally expect to get it in the same state it was when I lent it out.

    In a very real way, all this breaks permissions and renders it useless. It is now very difficult for a user to control an app based on permissions, since each category is so broad that it becomes very likely that even the most simple app will ask for multiple permissions. Conversely, it becomes very easy for an app developer to insert permissions into an app after the user has installed it in the form of a silent update, which can then be used maliciously.

    This means that a greater reliance is placed on other methods to control app behavior, such as Google Bouncer and app verification. All this would be fine, but both are historically proven to be circumventable. For example, Android apps may hide malicious code or dynamically load code from remote servers, making the task of detecting malicious behavior more difficult.

    Users do not have much choice in trying to counteract this “update”. One option users may consider is to turn off background auto-updates entirely. The Google Play app will still inform users if updates are available, and users need to manually update and check the new permissions. Unfortunately, this process can be quite burdensome.

    In addition, in today’s climate of privacy consciousness, “trust us” – as Google is, in effect, asking us to do – is not an ideal proposition. Users must have the tools to decide for themselves what they do or do not trust. Taking such tools away can only be described as an act of arrogance.

     
    Posted in Mobile | Comments Off



    In the previous part of this post, we explained what the “smartification” of the home is, why people are adopting it, and looked into some of the factors that can influence how people choose to add home automation into their daily lives.

    What are some additional factors that influence whether smart devices are accepted into homes?

    Replacement of Existing Equipment

    As existing devices and appliances in the home need replacement, homeowners may choose to replace these with smart devices. Of course, users may not actually use the “smart” features of the equipment, at least not initially.

    “Keeping things dumb” is a valid security consideration for a consumer that ultimately can’t or won’t make use of the features provided by smart devices, or doesn’t want to bother with the ongoing need to administer and maintain a security infrastructure for their home.

    The reason is that they would be increasing the attack surface of their home, without a corresponding perceived benefit. However, all this means that devices which have a shorter life cycle are more likely to become “smart” compared to more durable, long-lasting devices.

    Broadband Provider Bundles

    In many cases, broadband providers not only provide Internet access but phone and TV services as well. As consumers renew their contracts, many will increasingly be enticed into adding smart home services to their existing contracts. Examples of these in the United States include Time Warner’s IntelligentHome, AT&T’s Digital Life, and Verizon Home Control. All these offers include products for the smart home that covers automation, security and energy efficiency.

    This means that users who may not have even thought of acquiring smart devices in the past may find themselves buying these products: after all, it’s now just a small part of the bigger bundle they pay for.

    Tangible Benefits and Ease of Use

    One of the biggest factors in determining whether smart technology is adopted or not is whether it delivers needed or wanted benefits to consumers. Broadly speaking, devices and gadgets fall into somewhere along the following continuum when it comes to perceived benefits:

    Figure 1. Sliding scale of perceived benefits

    I won’t give examples of the “nice to have” and “unused gizmos”, since many of us have drawers full of items that would qualify in these categories. Some products can be considered a “fundamental enhancement” – i.e., something that significantly improves an existing experience. Examples include remote monitoring camera, thermostat, automatic lighting, or smart TVs.

    Others can be “mission critical” and provide completely new services to consumers, such as doctor-prescribed health monitoring or security devices.

    Of course, beyond any classification based on benefits, any device that does not provide simplistic and reliable operation in the hands of the average consumer may also become, simply put, useless.

    Regional and Cultural Mindset

    Local factors – such as the regional and cultural mindset of consumers – will be a significant factor in determining whether smart devices succeed or fail in individual markets. Different regions may come to different conclusions about the trade-off between the value of smart devices and their possible consequences. Factors such as culture, religion and way of life may come into play.

    In addition, the role of smart devices in potential cyber-attacks from other nation-states may cause consumers to become aware and opinionated about where there devices come from – and may judge the acceptance of smart devices accordingly. Politics may play a key role in whether the smart home is accepted in different countries.

    Conclusion

    The combination of all of these factors will influence how quickly smart devices will proliferate in homes around the world. This will influence how the threat landscape surrounding smart devices evolves; market decisions today will influence the threats of tomorrow. In addition, other technical factors may influence this as well. We will be monitoring this market for threats, and will discuss them in future posts.

    Stay tuned for our upcoming Threat Intelligence Resource – Internet of Everything hub, which will provide the latest updates and information about the Internet of Everything.

     
    Posted in Internet of Everything, Social, Vulnerabilities | Comments Off



    The recent introduction of ransomware in the mobile threat landscape was followed by a new development: the usage of TOR to hide C&C communication.

    In our analysis samples we now detect as AndroidOS_Locker.HBT, we found that this malware  shows a user interface that notifies the user that their device has been locked down, and that they need to pay a ransom of 1000 rubles to unlock it. The interface also states that failure to pay would result in the destruction of all data in the mobile device.

    Examples of apps we’ve seen display this routine are found in third-party app stores, bearing names such as Sex xonix, Release, Locker, VPlayer, FLVplayer, DayWeekBar, and Video Player. Non-malicious apps with these names are available from various app stores.

    Here is the warning shown to the user, which is in Russian:

    Figure 1. Warning to user (Click to enlarge)

    Here is a rough translation of the warning:

    For downloading and installing software nelitsenzionnnogo your phone has been blocked in accordance with Article 1252 of the Civil Code of the Russian Federation Defence exclusive rights.

     To unlock your phone pay 1000 rubles.

     You have 48 hours to pay, otherwise all data on your phone will be permanently destroyed!

     1. Locate the nearest terminal payments system QIWI

     2. Approach to the terminal and choose replenishment QIWI VISA WALLET

     3. Enter the phone number 79660624806 and press next

     4. Window appears comment – then enter your phone number without 7ki

     5. Put money into terminal and press pay

     6. Within 24 hours after payment is received, your phone will be unlocked.

     7. So you can pay via mobile shops and Messenger Euronetwork

     CAUTION: Trying to unlock the phone yourself will lead to complete full lock your phone, and the loss of all the information without further opportunities unlock.

    The user will be asked to pay to account 79660624806/79151611239/79295382310 by QIWI or 380982049193 by Monexy within 48 hours. This UI will also keeping popping out, thus preventing the user from being able to use their device properly. At the same time, files on device (both in internal and external storage) with following format are encrypted:

    • jpeg
    • jpg
    • png
    • bmp
    • gif
    • pdf
    • doc
    • docx
    • txt
    • avi
    • mkv
    • 3gp
    • mp4

    While the above-mentioned routines are typical of ransomware, we found that it communicates to its command-and-control server via TOR. Although this is not the first time we’ve seen Android malware use TOR, this is the first ransomware we’ve seen that uses it. Considering the amount of data that users now store in their mobile devices, we predict that this is just the start of the continuous development of mobile ransomware.

    How to Remove this Ransomware?

    For users whose devices are infected with this ransomware, the malicious app can be manually removed through the Android Debug Bridge. The adb is part of the Android SDK, which can be freely downloaded from the Android website. The process would proceed as follows:

    1. Install the Android SDK on a PC, including the adb component.
    2. Connect the affected device via USB to the PC.
    3. Run the following command from the command line:
      adb uninstall “org.simplelocker” 

    This procedure will work without problem for devices with Android versions lower than 4.2.2. For 4.2.2 and later users, however, there is a problem: the phone will prompt the user with a dialog to accept a key to allow debugging. However, the ransomware’s own UI will keep interrupting this, making it difficult to use adb to remove the phone.

    Note that in all cases, the user must have enabled USB debugging on their device before being infected; doing this may be difficult as the steps differ from device to device. In addition, turning USB debugging on is a security risk in and of itself, as it means an attacker who gets physical access to a device can easily get files from it without having to enter information in the Android lockscreen.

    The above step-by-step procedure will remove the ransomware, but not recover any locked files. Recovering the files is difficult, as is the case with ransomware on PCs. We recommend that users recover their files from their backups, whether these are online or offline.

    The SHA1 hashes of the samples used to analyze this attack are as follows:

    • 3313e82160fe574b4d4d83ec157d96980c0e88c4
    • 4824c957b7804d27c56002c93496182c8ec2840d
    • 5a102f0e6238418d8c73173752e20a5914ec4958
    • 725e9553040845d4b7ad2b0fd806597666d61605
    • 808df267f38e095492ebd8aeb4b56671061b2f72
    • 979020806f6fcb8a46a03bb4a4dcefcf26fa6e4c
    • b4bc70e7f046894ef12b5836f70b0318ca7ad06f
    • b5aab4bdb6bbb5914b1860c47080ccb558f07e5b
    • c85e49e0e99c2c0e531f723bf14d84339919985d
    • e6ee6dac2e6bd97c93a6a746442bfc0930e637af
     



    The use of contextually-relevant emails is one of the most common social engineering tactics employed in targeted attacks.  Emails still being the primary mode of business communications are often abused to deliver exploits to penetrate a network that consequently lead to other stages of a targeted attack cycle.

    In one of the targeted attacks we’re monitoring, threat actors used the news of a plane crash that killed the deputy prime minister of Laos.  The email message bore the subject line BREAKING: Plane Crash in Laos Kills Top Government Officials. Attached in this therein are documents purporting to be news clips of the crash to lure users. We have also observed that the email addresses of the real recipients are masked in the To header by using a Yahoo! email address to hide the intended targets of the said malicious email. Although this technique is an old one, we frequently see this maneuver in other targeted attack-related cases we have analyzed.

    The email attachments comprised of two legitimate .JPG files and an archive file which in some cases contain TROJ_MDROP.TRX. When executed, both malware exploit CVE-2012-0158, which is used in several attacks in the past, despite being patched in MS12-027 last 2012. Based on our data, CVE-2012-0158 is the most exploited vulnerability by targeted attacks in the second half of 2013.

     

    tareport2

    Figure 1. Most commonly exploited vulnerabilities related to targeted attacks

    Read the rest of this entry »

     


     

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