URLZone – a disaster waiting to happen

indepthreport-availableThanks to an effective PR strategy, most probably everybody has heard about URLZone by now. If not, you can find out more information regarding URLZone here or here.

We have been talking about it for some time and we already witnessed a few Trojans already using this technique. However, URLZone (or Bebloh) is now the first Trojan to come up with a professional setup to steal money from your account. Not only does it completely control your internet banking session, but it also automatically performs wire transfers to mule money accounts. If this isn’t bad enough, URLZone will then manipulate your online account statement to offset the fraudulent transaction (it can also remove the transaction or change the amount). The first time a victim would become aware of the fraudulent transaction(s) may be weeks or even months later – when they receive their paper statement in the mail! (that is if they get a paper statement at all… Lots of banks are trying to get rid of it altogether!)

Although real-time and session-based Trojans have been around for quite a while, they weren’t used in such a sophisticated way. An example was Yaludle (a Silentbanker variant), which injected HTML into the website that was dynamically retrieved from the web in real-time!

At the moment, only German banks are part of the URLZone configuration, but the bad guys can change the configuration at any second. Attacks against German online banks have always been very sophisticated simply because the German banks have employed one-time-password mechanisms (so called transaction numbers or TAN’s) for many years. Now the bad guys have found their way around it these mechanisms using such sophisticated techniques.

First generation attacks employing such Trojans saw the bad guys inject HTML code into the online banking login page to gather TAN’s in classical phishing attempts.

Then we saw more sophisticated attacks using variants of the well-known Bzub Trojan, which had the ability to perform wire transfers and remove them from the account statement.

Now we have URLZone doing silent wire transfers in the background and changing the online account statement.

Only as a result of the big amounts that these Trojans are fraudulently stealing are we beginning to hear about URLZone in the news, such as the recent $447,000 USD heist at Ferma in California, USA. While the manager had issued legitimate payments, the program initiated a further 27 transactions to various bank accounts, siphoning off a total of $447,000 USD in a matter of minutes. “They not only got into my system here, they were able to ascertain how much they could draw, so they drew the limit,” says Roy Ferrari, Ferma’s President (http://www.technologyreview.com/computing/23488/?a=f).

Another high-profile case was the gigantic Zeus botnet of recent, that also resulted in large amounts being stolen, such as the $415,000 USD heist at Bullitt County, Kentucky (http://voices.washingtonpost.com/securityfix/2009/07/an_odyssey_of_fraud_part_ii.html).

And let’s not forget Signs Designs Inc who also recently lost close to $100,000 USD in similar attacks (http://voices.washingtonpost.com/securityfix/2009/09/more_business_banking_victims.html).

In light of the above, I want to point out a few notes:

  • Firstly – The problem has been around for a long time and it seems that people are only doing something about such threats when they are large enough to be mentioned in the press. That’s exactly what the intelligent botnets such as Mebroot/torpig are exploiting. By staying under the radar and not being too greedy they can do their dirty work and don’t have to worry about consequences. Their motto seems to be: Just keep the security industry busy with non-threats like conficker and they won’t hassle you.
  • Secondly – This type of attack cannot be solved with 2-factor authentication.
  • Thirdly – While there is much hype around URLZone at the moment around how amazing and disturbing it is that the bad guys can do such things, we will always have this problem if the bank’s security and the user’s security systems are not connected.
  • Fourthly – While the Trojan is very, very sophisticated and advanced on the delivery side, they have made it incredibly easy for the good guys to catch them. Don’t expect this to happen in the future with new variants. We are still at the beginning…

One further thing to note is that since all real-time, session-based Trojans need to talk to a C&C server during the banking transaction, just one of TrustDefender’s many layers of protections will fully protect you against such attacks. Our “Secure Lockdown” knows all internet requests that belong to the financial institution and will block everything else while you are in a banking transaction. This will always protect you for all Trojans that work on this principle, not just for the likes of URLZone.

In addition, our Forensics Engine will also pick up the URLZone Trojan itself and will alert you of the infection, while also automatically disabling it for the period of the transaction. This will ensure you are always Safe and Secure while transacting online.

Due to popular demand, we have put together an in-depth TrustDefender Labs report about URLZone, which you can request by sending an email to labs@trustdefender.com. The in-depth report features the complete inner workings, together with an analysis of the configuration file and forensics information.

3 thoughts on “URLZone – a disaster waiting to happen”

  1. Two factor authentication at the online account level won’t work, but maybe some kind 2 factor confirmation would.

    Just an idea, but maybe banks could implement a system that allowed users to set their own limit as to how much can be transferred out (something that isn’t visible or accessible from their online account). Currently we see many banks have something like a $10,000 limit before a flag is raised. So the miscreants take out numerous $9,975 transactions as to not trip a wire and the transfers would go through without a hitch. There was one article I read where a company discovered what was happening and told the bank to disallow the transactions till they figured out what was going on… and several hours later the miscreants successfully took out more money!

    So let’s say a business says they wanna set a limit/flag of $2,000. Any transaction beyond that $ ammount would require the bank to send a notice requiring confirmation that the transaction is in fact legitimate. The confirmation could be as automated as email. They could call by phone or send use SMS messages. Miscreants wouldn’t know the $2,000 flag and hopefully they haven’t also comprised the users phone or email (phone far less likely than email). Further, if a number of transactions are attempted in a certain time period, the bank could make a personal call to the account holder to further ensure an attacker isn’t attempting something fishy.

    Botnets are also tend to be coded with large scope in mind so catering to individual comprised accounts would take a lot more work. And if there is one thing we know, these guys go for low hanging fruit.

    Problems with this? Larger accounts may make a lot more transactions. But honestly, those aren’t the targets. Small to midsize businesses are. And they should have an idea of the kinds of flags that need to be set to offer a good balance of convenience and security.

    Banks also won’t want to implement this system as it would take time and money. But that’s because they try to (and in most cases do) stick the business with loss. Maybe some are working on a system like this? I wouldn’t bet money on it personally. It will affect them in the long run though, if banks customers are losing all their money, then the bank is technically losing money too. They gotta invest with something after all.

    So that was really long comment there. I’m gonna get back to work now :) Great post by TrustDefender as always!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>