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

  • Recent Posts

  • Calendar

    February 2014
    S M T W T F S
    « Jan   Mar »
     1
    2345678
    9101112131415
    16171819202122
    232425262728  
  • Email Subscription

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

    Archive for February, 2014




    Threats today are designed to appeal to local audiences everywhere: two separate threats we’ve recently encountered show how ransomware is targeted towards users in specific countries; in these cases users in Turkey and Hungary were the targets.

    First, we came across a notification email sent to Turkish users that talks about a billing update. Recipients are prompted to download and view the updated version of the invoice. Upon clicking on the links provided, users are directed to a website which prompts them to enter a CAPTCHA phrase and download the document. It’s also worth noting that any attempts of accessing the website with a modified link will result in the redirection to the official website, in attempt to avoid user suspicion.

    The downloaded file appears to be a PDF file, but a closer look reveals it to be an executable file. Once executed, this malicious file, detected as TROJ_RANSOM.ZD, encrypts files found in the affected system. A pop-up notification appears, instructing the victim to pay for the file decryption. The desktop wallpaper is also modified to display the same message as that of the notification.

    Figure 1. Pop-up notification informing users of file encryption

    The message informs the victim that a vulnerability in the system was exploited to encrypt the files. The victim has three days to pay for the decryption password. An email address acts as the sole contact detail for the person behind this attack; this address belongs to a Ukrainian free email provider.

    It’s worth noting that the message specifically mentions IT administrators – according to the message, the data was encrypted using a technique that will supposedly take a thousand years to decrypt. In addition, to hide its malicious activity, any access to the malicious domain aside from the URLs in this attack redirect to the legitimate website.

    Secondly, we also saw users in Hungary targeted with ransomware. This particular variant is detected as TROJ_RANSOM.HUN and lists the file types that were encrypted, as well as the steps to unlock the file and the amount of the ransom (20,000 forints, or just under 90 US dollars.)

    Figure 2. Hungarian ransomeware

    While the attacks may have very similar behavior, our analysis indicates that the malware files themselves are not related. This indicates that multiple cybercrime gangs have “gone local” and are adapting ransomware tactics to their local “markets”; they may have been inspired by the success of CryptoLocker in recent months.

    Trend Micro blocks all related threats, emails, and URLs associated with these attacks. We advise users to exercise caution when opening all emails. Since the files cannot be decrypted (aside from perhaps paying the fee), it’s also good practice to constantly back up files in case of instances such as this one. Other safety practices can be found in a previous blog entry. More information about ransomware is provided in a special Threat Encyclopedia page.

    Additional analysis and insights by Mark Manahan.

     
    Posted in Malware, Spam | 1 TrackBack »



    The past few weeks have not been good for Bitcoin. Mt. Gox shut down withdrawals due to concerns over transaction malleability. The same flaw was reportedly used to loot more than 4,000 BTC (worth more than 2.7 million US dollars) from Silk Road 2.0 Deep Web marketplace. These stories, together with others that have shaken the confidence of the Bitcoin community, have pushed the value of Bitcoin to just slightly over 600 US dollars, a significant plunge from its peak values of more than $1200.

    So, what is transaction malleability, and why has it caused such a big problem for Bitcoin?

    Imagine I’m going to send you a check numbered 700 for $25. If you know that I only track finances by check number, you can carry out a transaction malleability attack against me as well.

    When you receive the check from me, you change the number by, say, adding a “1″ to the end, making the number 7001. (For the purpose of this discussion, let’s suppose you can do this without the bank noticing.) By itself, changing the check’s number has no impact to the value of this transaction. You then wait, then tell me that you never got the check.

    If I now look in my bank account I see check 7001, but not 700. If I send a new check you win – you cashed two checks from me. Even if I don’t send out a new check, you still have the original check, which can still be cashed.

    This is the same idea behind the transaction malleability vulnerability as exploited in Bitcoin.

    Let’s say you have two parties, Alice and Evan. Alice intends to pay Evan some Bitcoin. Evan wants to scam Alice out of her Bitcoin. When Alice submits the transaction to the Bitcoin network, it is identified by a hash value. One of the elements of the hash value is the ScriptSig field.

    This signature field verifies the authority of this transaction to spend the Bitcoin in the source transaction. These signatures are encoded in a format known as DER. It is rather simple using a type, length, and data construct. One possible type is “0″ or null, or no data. If the attacker adds one or more “0″ bytes to the DER, it is still a valid signature for that transaction, however the transaction will be known by a different hash value.

    Evan would watch the Bitcoin network for his transaction (from Alice to Evan). When he finds one, he takes a copy and edits it so that the hash value changes. She submits many copies of the new “transaction” to the network. If he is lucky, his transaction may beat the legitimate transaction into a block on the block-chain. If Evan is successful, Alice’s transaction will get rejected because the incoming transaction will have already been spent.

    If Alice was only using transaction numbers to keep track of transactions, she would see that the transaction failed, and maybe an automated system would re-issue the transaction. You can see where this is going. If Evan fails, he gets the (original) Bitcoin, if successful, he gets twice the money.

    As scary as this sounds, it is no match for a well-designed payment tracking system. This is a flaw in how exchanges and merchants keep track of payments rather than anything in Bitcoin itself. The hash value should not be used as the sole tracking identifier by Bitcoin users, as it is prone to modification by outside parties. That said, some of these parties are already implementing changes to ensure that the signature can only have one value.

    Always wait for confirmation on outgoing and incoming transactions before considering them paid in full to avoid “double payments” like those that occurred here. Confirm transactions by source address as well as transaction hash.

     



    Earlier we talked about some Flappy Bird-related threats. In the course of uncovering their background, we found several third-party app stores that distributed or created similarly dangerous mobile apps.

    These third-party app stores target mobile users in Vietnam and inject advertising or even malicious code into popular apps. These apps put the user’s privacy at risk, and may even cause financial loss – the recent Trojanized Flappy Bird app used premium service abuse to profit, and also connected to a command-and-control server in order to receive commands.

    This example of a third-party app store imitates the Google Play store and contains various well-known apps that have been Trojanized. Even a fake version of the Google Play app itself is present, but it leads to their own third-party store.

    140218comment01

    Figure 1. Example of imitated Google Play’s page

    The apps in this store contain added advertising code; the profit from these ads goes to the cybercriminals and not the app developers. Among the information sent is the user’s phone number, email address, and device information.

    Figure 2. Advertising information

    In addition, this advertising module may remotely load code to be executed on the device, effectively acting as a backdoor. This poses a great risk for users.

    Figure 3. Backdoor code

    Apps with this malicious code are detected as ANDROIDOS_FLEXLEAK.HBT.

    Another third-party store was even riskier – this single store contained more than 500 OPFAKE malware variants. One of the malicious Flappy Bird apps was downloaded from this store. Not only do they contain the potentially malicious advertising code, they also abuse premium service numbers in order to get money directly from the user.

    Adult apps are also present on this store, with the users having to pay via SMS to use these apps.

    Figure 4. Second malicious third-party store

    A third app store has similar threats as the other stores mentioned in this post. This one, however, has higher download counts (more than 70,000 downloads).

    Figure 5. Third malicious third-party store

    These incidents highlight the possible dangers from downloading apps from third-party stores. Users often visit third-party app stores to obtain apps that may be unavailable in official app stores or  even pirated apps (like free versions of paid apps). Some users, meanwhile, rely on these sites because of the unavailability of official app stores in their region.

    However, visiting these sites can often be a hit-or-miss. Third-party app sites may not be as strict in monitoring and removing malicious apps compared to, say, Google Play. Apps from these third-party sites should be treated as potentially malicious, as a user has no easy way to determine what malicious code was added.

    We detect all the apps listed in these stores that contain malicious content or may violate a user’s privacy.

     
    Posted in Malware, Mobile | Comments Off



    Any vulnerability in Internet Explorer is a large issue, but last week’s zero-day vulnerability (designated as CVE-2014-0322) is particularly interesting. It used what we call a “hybrid exploit”, where the malicious exploit code is split across multiple components that use differing technology: in this case, the exploit code was split between JavaScript and Adobe Flash. The use of “hybrid exploits” provides attackers with a way to evade existing mitigation technology like ASLR and DEP.

    Let’s go over how this exploit was delivered to users. The victim website was compromised, and two malicious files were uploaded to it:

    • Erido.jpg (detected as HTML_EXPLOIT.PB, MD5 hash: 00ae7a1514809749a57d4d05d8c969b5)
    • Tope.swf (detected as SWF_EXPLOIT.PB, MD5 hash: 732b6a98b0a7b2ee795f2193a041520d)

    The overall flow can be found in the following diagram, which will be explained in the text.

    Figure 1. Overall control flow

    A page on the website (img.html) was modified with additional JavaScript and an iframe to load the malicious Flash file, as follows:

    <embed src=Tope.swf width=10 height=10></embed>

    When called, the Flash file carries out a heap spray. Control is then passed back to the JavaScript, via a function call in the Flash file. The actual malicious code that triggers CVE-2014-0322 is actually found here, and not in the Flash file. (To prevent further attacks that may exploit this vulnerability, we will not provide further details about the exploit.) Control is then passed back to the Flash file, where the code responsible for arbitrary memory reads and writes is located.

    From here on, the goal of the code is simple: it searches for return-oriented programming (ROP) gadgets in the memory (specifically, it uses ROP gadgets in ntdll.dll), constructs the ROP chain, and overwrite the virtual table of a Flash object in order to hijack the execution flow of the Flash virtual machine.

    Two ROP gadgets were used in this attack:

    • 77a646a8 94 xchg eax,esp // Pivot the stack pointer
    • ntdll!ZwProtectVirtualMemory (1a1b3000, 1000, PAGE_EXECUTE_READWRITE)

    The first ROP gadget pivots the stack pointer to let it point to controlled data; the second gadget calls ZwProtectVirtualMemory to change this shellcode’s protection to PAGE_EXECUTE_READWRITE, to bypass DEP protection.

    If this shellcode needs to call APIs, it will first check whether the API is hooked inlineby checking the starting byte code of the API. If that is the case, then it will skip the first 5 bytes of the API, to escape from the hook. This technique is used to bypass the detection of security products that are watching for this behavior.

    Figure 2. Malicious shellcode

    The above shellcode does the following:

    1. Decode two PE files using the data in the file Erido.jpg
    2. Drops the two PE files to:
      • %Temp%\sqlrenew.txt
      • %Temp%\stream.exe
    3. Load the contents of sqlrenew.txt into memory
    4. Return to the caller to prevent a Flash or IE crash

    The contents of sqlrenew.txt merely executes the other dropped file, stream.exe. However, this will only happen when IE has been terminated and the module itself is being unloaded.

    Figure 3. Malicious shellcode

    Conclusions

    Any zero-day vulnerability in a widely used program like Internet Explorer is significant, but this one appears to be doubly so. To avoid known exploit mitigation techniques like ASLR and DEP, this attack uses multiple web objects interacting with each other to carry out the exploit instead of a single easily detected file.

    It is likely that we will see more of this technique in the future as cybercriminals try to make their exploits more effective on all platforms. Both developers and security vendors will need to respond to this emerging threat in order to keep users safe.

     
    Posted in Exploits, Vulnerabilities | Comments Off



    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


     

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