Online banking customers in Europe are falling victim by the thousands to a new banking Trojan that is infecting Android and BlackBerry devices and is capable of defeating two-factor authentication.

The Trojan, dubbed Eurograbber by researchers at Check Point Software Technologies and Verasafe, is a variant of the Zitmo Trojan. Zitmo, or Zeus-In-The-Mobile, has not moved outside Europe, but could eventually target customers in the United States, for example, as more banks require a second form of authentication for access to their online accounts.

To date, the researchers said, Eurograbber has infected more than 30,000 users and stolen an estimated 36 million Euros. Once the Trojan infects a customer’s PC and mobile device, it is able to transfer funds from a compromised account without the victim’s knowledge in amounts ranging from 500 to 250,000 Euros.

“Eurograbber is an excellent example of a successful targeted, sophisticated and stealthy attack. The threat from custom designed, targeted attacks like Eurograbber is real and is not going away,” wrote Eran Kalige of Verasafe and Darrell Burkey of Check Point in a research report. The victim banks were not identified in the report, but Kalige and Burkey said the financial institutions, as well as law enforcement, have been notified.

Like most targeted attacks, this one kicks off with a phishing message purporting to be from their bank leading them to click on a link which downloads the Trojan onto their PC. The next time the victim logs onto their banking account, the Trojan hijacks the session and injects JavaScript onto the banking page instructing them to proceed through a security upgrade. The message instructs the user to install software that will encrypt transactions from their mobile device, which is used as a second form of authentication via an SMS message sent to the device.

The victim enters their mobile number and device type. In the background, a connection is made to a command and control server where stolen data is stored and further instructions await. The Trojan then sends an SMS to the victim’s mobile that includes a link that will download the Trojan to the phone as well. A device-appropriate version of the malware is sent in the location-appropriate language. A verification code is sent that the victim must enter once the upgrade process is complete.

“Further evidence of the sophistication of the Eurograbber attack, this response informs the attackers when a particular bank customer is now controlled by the Eurograbber attack,” the report said.

The victim then gets a message on their mobile and PC that the security upgrade is complete and they can continue with their banking. In the background, the Trojan is able to hijack the session and start its own transaction in the background, transferring funds to a mule account owned by the attackers.

The key here is the Trojan’s ability to circumvent the second-factor of authentication, or Transaction Authorization Number (TAN) sent via SMS to the user’s mobile. The Trojan gets the SMS and sends the TAN via relay phones and proxy servers to the command and control server’s SQL database. The Trojan uses the TAN to complete its transaction, while the customer sees none of the fraudulent activity.

“In order to avoid detection, the attackers used several different domain names and servers, some of which were proxy servers to further complicate detection,” the report said. “If detected, the attackers could easily and quickly replace their infrastructure thus ensuring the integrity of their attack infrastructure, and ensuring the continuity of their operation and illicit money flow.”

Zitmo traditionally targeted the Android platform, but earlier this year, a version of Zitmo for BlackBerry surfaced. BlackBerry’s use by corporate executives gives the Trojan access to high-value executives, the report said.

Categories: Malware

Comments (10)

  1. Anonymous
    2

    The only way to stop this is to get a fully separated multifactor authentication, where a device like Vasco or RSA dongle (or the card reader from Nordea) is used to authenticate and sign all critical transactions. And there must be no way to get into these devices, by virtue of an air gap. 

    Soft tokens (that reside as client certs or apps in the file system) or mobile phones are way too easy targets. And passwords are so 1977. 

  2. Anonymous
    3

    Sorry, the “fully separated multifactor authentication” devices are also being subverted by ZeuS, SpyEye, Gozi, etc. This was done before MitMo/MitB coordinated attacks were devised.

  3. TextPower
    4

    The problem with the affected multi-factor authentication approach is that it leaves room for a man-in-the-middle (MITB) or man-in-the-browser (MITM) attack.  The only method that will eliminate this, by definition, is an external two-factor authentication (2FA) that completely circumvents the browser. 

    Here comes a shameless plug… my company, TextPower, has developed an SMS-based 2FA method that does precisely that – it completely eliminates MITM and MITB attacks.  How? Simple – the authenticating message is sent *from* the phone into our servers, which communicates on a secure back channel with the server of the web site and indicate whether to grant or deny access.  No browser is involved in the authentication process, thus eliminating this type – and many other types – of attacks. Because of the UDID of the device, it is the least hackable authentication method on the market (nothing is “unhackable” but nobody has yet successfully hacked into our system through all of our testing).

    The product, TextKey, has won two major industry awards and is patent-pending.  Although we are still in “slightly stealth” mode the product has generated significant interest from some major financial institutions and is going to be marketed publicly within the next six months. 

    These attacks are actually quite easy to avoid if the correct approach is taken when planning security.  Using a method that eliminates the possibility of browser-based intrusions is the simplest and easiest way to do so. 

    See an explanatory video at TextPower dot com slash TextKey.

  4. John Zurawski, Authentify
    5

    The real challenge is that authenticating the end user and signing transactions all happen on the front end.  A secure SMS text with an OTP that the MITM can’t read is fine – the MITM doesn’t need it.  He wants you logged on – he’s going to change your transaction details “in flight”

    The front end is unsafe to the point that secure out-of-band, or out-of-channel communication from the backend is required.  Not transaction signing, but transaction review and approval. A phone-based voice call that speaks your transaction details to you and permits approval or cancellation is one example, provided you can can defend against call forwarding and exploits against the phone.  That takes a vendor with experience.

    A smart app on a smart phone or tablet with an encrypted communication layer and a top of the stack application level encryption to protect it from ZITMO is another example.  The app would let you review and approve or cancel the transaction if it isn’t correct.  Don’t trust using an app on the same phone the banking app is on – mix and match.  Bank on a tablet, validate the transaction on the smart phone.  The BYOD trend should offer more ways to secure transactions, not fewer.  The situation today is similar to the initial rush to online banking back in the 90’s.  Identity theft and account takeover were rampant because in the rush to get “there” – not a lot of thought was given to the vulnerabilities.  The mobile rush is on and similar and similar pitfalls are happening.  Now BEFORE anyone starts poking holes in the use of out-of-band, and phone-based authentication, or smart app as an out-of-band end point, as I said – you need a vendor that knows how to defend those channels against the exploits.  Call forward, SIM swap, phone account takeover – and there are ways to defend the voice and 3G 4G channels.  The sky is not falling, FI’s just need to catch up.

  5. Renegade MJ
    6

    We all play blindly..forgetting how to manage the problem at hand but rather criticizing developers has been the issh of the day..Security personnel are expensive dudes n companies r caught in-between defending themselves or there customers. How about if zitmo was made public n taught to customers; What it looks like n How it works.. BTW im offering the public zitmo app for educational n awareness purpose only..it is a cracked version n works pretty well..see how to damage the “Set Admin” protocol. take this discussion here;  romentmj@yahoo.com  No r3v3rse Engin33ring B.S

     

  6. TextPower
    7

    The problem with the affected multi-factor authentication approach is that it leaves room for a man-in-the-middle (MITB) or man-in-the-browser (MITM) attack.  The only method that will eliminate this, by definition, is an external two-factor authentication (2FA) that completely circumvents the browser.

    One approach is to create a process where an SMS is sent *from* a phone, which guarantees its authenticity because of the phone’s fingerprint – the “UDID” – which cannot be spoofed on originating messages (“MOs”).  Since no browser is involved in the authentication process it eliminates this type – and many other types – of attacks. Because of the UDID of the device, it is the least hackable authentication method on the market.

    These attacks are actually quite easy to avoid if the correct approach is taken when planning security.  Using a method that eliminates the possibility of browser-based intrusions is the simplest and easiest way to do so.

  7. ChrisV
    9

    Not really. If I control your compute device through a Bot, I can still allow a proper authentication in terms of your dongle or third party device. And then while you think you are performing a legitimate transaction as displayed on your hijacked compute device and confirmed via dummy sms’s to your hijacked phone…. On the back end these guys could be running different transactions from your hijacked device that has been properly authenticated by you and whatever your security device have entered to authenticate. 

    Step 1 should be that the end user is educated and does not “click” the rogue links to download the trojanBOT to start with

    Step 2 Out of band communications is needed to validate and aithenticate transactions. But the out of band device should not use a communications channel that can be compromised. And the device itself should be a secure device that cannot be compromised

     

  8. Michael
    10

    The only way to block these hijackings with 99.99% certainty is to use an OS lockdown or malware negation technology, that renders malware inoperable. The time is coming to an end where we could get sufficient protection from AV / malware filtering or IPS apps. We need a secure OS environment where malware cannot operate. Let 2 factor prove that we are who we say we are, it was though never architected to stop malware hijacking banking sessions.

Comments are closed.