Modern banker malware undermines two-factor authentication

Modern banker malware undermines two-factor authentication

Summary: Once pitched as an additional layer of security for E-banking transactions, two-factor authentication is slowly becoming an easy to bypass authentication process, to which cybercriminals have successfully adapted throughout the last couple of years.


Once pitched as an additional layer of security for E-banking transactions, two-factor authentication is slowly becoming an easy to bypass authentication process, to which cybercriminals have successfully adapted throughout the last couple of years.

Modern banker malware, also known as crimeware, is now fully capable of bypassing the two-factor authentication obstacle by doing a simple thing - patiently waiting for the crimeware-infected victim to authenticate himself in order to abuse the access in real-time.

A recently published article at MIT's Technology Review, details a case where cybercriminals managed to steal $447K despite that two-factor authentication was in place:

Yet the manager's computer had a hitchhiker. A forensic analysis performed later would reveal that an earlier visit to another website had allowed a malicious program to invade his computer. While the manager issued legitimate payments, the program initiated 27 transactions to various bank accounts, siphoning off $447,000 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.

The theft happened despite Ferma's use of a one-time password, a six-digit code issued by a small electronic device every 30 or 60 seconds.

This incident, among the countless number of similar but largely under-reported ones, raises several important questions. Compared to a previous case where a bank was sued for not offering two-factor authentication, should Ferma's bank be sued for actually offering two-factor authentication, but allowing the fraudulent transaction to take place?

Also, could antivirus software have prevented (No security software, no E-banking fraud claims for you) the infection from taking place? Last seek, Trusteer published an advisory entitled "Measuring the in-the-wild effectiveness of Antivirus against Zeus" according to which the most popular banker malware Zeus, is successfully bypassing up-to-date antivirus software :

Installing an anti-virus product and maintaining it up to date reduces the probability to get infected by Zeus by 23%, compared to running without an anti-virus altogether. The effectiveness of an up to date anti virus against Zeus is thus not 100%, not 90%, not even 50% - it’s just 23%.

While disturbing, these results shouldn't come as a surprise due to the "value-added" services offered by a managed crimeware service, namely, the systematic release of undetected Zeus samples. The popularity of Zeus has in fact contributed to the development of a monoculture within the crimeware market, prompting cybercriminals to look for, and actually find remotely exploitable vulnerabilities within outdated crimeware kits, allowing them to easily hijack someone else's misconfigured and outdated botnet.

Its popularity has also prompted the launch of such services as the the Zeus Tracker, which currently list 537 active crimeware domains, with the majority of them hosted in Russia, the U.S and China, followed by the Netherlands, Ukraine and Germany. The real-time blocklist it generates is in fact so useful, the service came under a DDoS attack in February, 2009.

With banker malware clearly able to operate even on PCs with up-to-data antivirus product, a logical anti-fraud move by a bank's customer would be to reclaim control of their bank account by assuming the worst.

In Ferma's case, depending on whether or not their bank offered such services -- like it should -- the ability to set daily, weekly or monthly account transaction limits may have mitigated the impact of the actual compromise. Moreover, issuing one-time passwords (OTP) over SMS is just the tip of the iceberg when it comes to offering additional alert services. Not only is the availability of SMS alert services (automatic SMS alert for each incoming and outgoing transaction) highly advisable, it can help a crimeware-infected victim quickly get hold of their financial institution's 24/7 fraud report center in order to freeze the transaction and the account itself.

Naturally, cybecriminals have found ways to adapt to these SMS alerts, by exploiting badly implemented processes within particular financial institutions allowing a customer to change the mobile number in any particular moment of time. Due to the fact that, for instance, a Chinese bank wouldn't accept U.S mobile number for SMS alert and one-time password services, cybercriminals are already using services offering to accept and forward any data sent to a particular mobile number within a country where they maintain local numbers for fraudulent purposes.

Multiple-factor authentication simply cannot prevent fraudulent activity if the user is operating from a compromised environment in the first place.

Topics: Mobility, Banking, Malware, Security

Dancho Danchev

About Dancho Danchev

Dancho Danchev is an independent security consultant and cyber threats analyst, with extensive experience in open source intelligence gathering, malware and cybercrime incident response.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Ok, ill buy that..

    Yes Two-factor authentication doesnt help avoid the already infected. Now what the bank SHOULD have one (other than the user having a fully patched system and AV if hes on Windows) is when the website detected that there was activity from another IP address - represented another verification system, much like this is your "login key" [a picture that you selected] along with a challenge question/answer set by the person. Or am I missing something and the fruadulant transaction was done from the [i]same[/i] IP address?

    The system should ALWAYS be challenging you and verifing your credentials. Also the preferences to access and change the security question, 'login key', phone number, etc should be protected by another OTP check and/or PIN - that differs from the initial logon check. Maybe we should have these sites start making an encrypted link from they KEYBOARD to the browser window? That could help too... Just my thoughts..
    • I suspect it was originating with the users IP.

      [i]Or am I missing something and the fruadulant transaction was done from the same IP address?[/i]

      A suggestion to protect loss of money would be to use the same two factor authentication to verify every outgoing transfer.
    • If the malware is on the user's system..

      ..why would it need to make the withdrawal using
      somebody else's IP address?
  • What about BoA's authentication?

    They require a user at a PC to authenticate and answer a question. If its at a new PC, the question must be answered again.

    That may or may not fall under two stage.

    They do alert you if a new payer is setup and if any money is transferred. You can also setup limits, etc.

    I think the bottom line here is that antivirus products have to evovle into watchdogs. If something dont smell right, they should atleast alert the user. Obviously you cant hand hold and wipe everyones ass, but it would be a start. Puts them in a tight place either way though.
  • RE: Modern banker malware undermines two-factor authentication

    Sigh.... I am repeating this for years:

    *Any* form of user authentication can be defeated by man-in-the-middle attack. What *cannot* be circumvented is the requirement for user to cryptographically sign transaction she has initiated.

    Here is how it goes in my bank (nad has been going for almost ten years):

    I am issued a little device looking like a very small calculator. When I log on to the e-banking site, I turn on the device, enter PIN, and request a one-time password (6-digit number). I authenticate myself by entering the device's serial number and the password, which is valid for a minute or so. The bank knows it is sommunicating with me, but if malware similar to that described infected my machine, or there is a man-in-the-middle machine that installed itself in the loop by DNS poisoning, they would relay my authentication data to the bank and bank's response to me, while in the meantime merrily inserting their own transactions. So far, so good. However, when the time comes to actually commit transactions, the bank will send me a 8-digit hash of the transaction entered. I will sign it using the same device, and return the resulting 6-digit number to the bank. Only if the bank can verify that the hash has been signed by me the transaction is committed.

    This approach will be completely safe only if there is no option of signing multiple transactions at once. This is, I will admit, a tad inconvenient.
    • But not nearly as inconvenient as losing $477K

      [i]This approach will be completely safe only if there is no option of signing multiple transactions at once. This is, I will admit, a tad inconvenient.[/i]
      • Been saying it for years...

        And so has Schneier.
        Authenticate the transaction, not the user.
        • re: Been saying it for years...

          [i]Authenticate the transaction, not the user.[/i]

          Yes! Absolutely.
    • Still vulnerable to MITM

      The authentication you describe is still vulnerable to MITM attack, more specifically Man In The Browser. The key problem is how do you know that the 8 digit hash of the transaction is the hash for the same transaction value and destination you are intending to authenticate? Since it is simply a generic numbers there is no way for you to know if it is the trojans transaction running in the background destined for a completely different mule account, remember the trojans can and do control every aspect of what is shown in your browser so everything else on the page will subscribe that the hash value is for the destination account and value that you intend but actually you are authenticating the trojans transaction.
  • excellent article, excellent b$ comment

    Thank you both.

    Narr vi
    Narr vi
  • RE: Modern banker malware undermines two-factor authentication

    Don't use on line banking if you have a Windows computer. Just do not use Windows on line as it is a big target for criminals. It is a good system for local use where there is not a internet connection, but on line it is heavily targeted.
  • RE: Modern banker malware undermines two-factor authentication

    the first episode I know happened one year ago in Holland.
    The computer was badly managed. It was later discovered by the police that before the bank's security experts could have access to the client's computer, some "XXX" files were deleted...
  • Add in dual-route

    In Germany we have a system called TANs. It is a set of 100 6-digit numbers printed on a single sheet of paper and posted to bank customers. Every transaction must be authenticated by responding to the request "please provide TAN number X" (1<=X<=100). A criminal needs to do more than intercept your physical post - changing from one set of 100 TANs to another must also be confirmed with one of the old TANs - but banks have not switched to tamper-proof envelopes, so I cannot be sure that only I have a copy of my TANs. My bank recently suggested replacing the physical sheet of paper with an SMS message containing the TAN for each transaction. I declined the offer.
  • RE: Modern banker malware undermines two-factor authentication

    Why not a single transaction per authentication? After a transaction, require the user to wait for the next secureID passkey to perform an additional transaction? This would stop hitchhicking viruses from tagging on additional transactions to a session.
  • Alerts are good, OOBA is better

    I agree that alerts are critical. You can't expect users and businesses to comb through their banking transactions every day looking for fraudulent transactions. But if you can stop the fraud before it happens, even better.

    Out-of-band authentication at the transaction level can protect against these threats. With a service like PhoneFactor, you can require users to enter a PIN into the phone to verify the transaction. In this case, simply changing the phone number won't work. The attacker would still need to know the user's PIN to approve the transaction.
  • ZEUS site suspect

    The credibility of the ZEUS lacks; the site's security certificate is not trusted/self-generated. How can we find their data credible if they don't have an authenticated certificate?
    • Huh?

      How does spending the $30+ needed for a cert add any credibility?
  • Do certificates make us vulnerable?

    I just doesn't seem that hard to get that green background to the url... People have been told to trust the littel green notice but dont understand the wide range of limits to a certificates usefullness.
  • Passwindow two-factor is not vulnerable

    Passwindow two-factor is not vulnerable to these trojan attacks because unlike most two factor tokens it can include deliberate transaction information into the visual challenge themselves (such as value, acc destination etc) where the electronic two-factor systems simply use generic confirmation digits. The attacker or trojan is unable to swap or dissassemble the simple visual patterns without destroying the challenge and the user is made instantly aware of the deception despite how compromised their system is.
    • Flawed and, sorry, irrelevant

      Passwindow seems interesting for some services but it is, I think, seriously flawed. It is similar to a challenge response system where the response will be always the same (the card pattern) or to an encryption when the secret key will be always the same and public. The pattern can be copied from your credit card on a transparent sheet with the cheapest photocopier on the back office of your preferred restaurant. It will be interesting also to perform some calculations about the practical password space of such patterns. What level of complexity is necessary for an acceptable password space, and is this level not too high to avoid confusing the user?

      Nevertheless these banking malwares hijack the authenticated sessions, they do not care about the authentication method or the security of the authentication agent. The Skype wiretap Trojan is a good example of such malware. The problem is not in the authentication method but mainly in the security of the operating system (and of the user of course)