Banking Trojan hijacks out-of-band SMS security - Trusteer

Fraudsters are always looking for new ways to steal money, and this is an example of how they are working across different platforms to breach security. However, I think it is wrong to say that this necessarily enables them to 'fly under the radar of fraud detection systems'. True - many financial institutions use out-of-band authentication - but it is rarely used in isolation.

The strongest fraud detection always comes back to one key premise - knowing your customer: knowing what transactions they do, who they send money to, what amounts they spend, where they log on to their online banking site from, when they typically do transactions etc. Banks have got, at their fingertips, everything they need to build up a detailed picture of normal behaviour for their customers and any transaction that falls outside of that, even if it has apparently been authenticated by a mobile phone, should still be treated as suspicious.

Of course, it is important to educate customers about threats, and ensure they know not to open suspicious messages or links - but the right security system needs to assume all these things will happen anyway, but the customer is still protected.

Divitt, Your comment seemed to be the generally recommended practice today, it seemed to place more weight on SIEM systems than any authentication of identity. Does that mean, if one can only afford to implement one layer of protection, they should go for SIEM? or, let's do this exercise, how much relative weight will you put on each of the following:

* MFA (Identity authentication: OTP, cert., OOBA, etc.)

* Transaction authentication (against MITM)

* SIEM

What I'd like to see is an OTP that can protect against MITB and can have minimum SIEM functions :-) that would be an easy solution !

I think saying "if you could only do one" can be a dangerous game and is probably not beneficial since I really do believe in a layered approach.

With regards to giving a weight to the various options (event monitoring, multi-factor auth and transaction auth) I think event monitoring should probably comprise about 50% of your total solution (budget/efforts/etc) and the others spread evenly at 25% each.

If you implement a multi-factor auth solution to authenticate logons, then you should be definitely using the same system to authenticate payments or other key account activity as well, to maximise its value.

I too, like David Divitt, I am a firm supporter of a layered approach to authentication. The attack, as described in the Finextra story, all centres on the fact that the bank allows users to change their registered mobile number and then sends a confirmation  code via SMS (to the old number) which must be resubmitted into the browser to complete the change. They then use Man in the Browser and social engineering to get the real user to submit this code on another pretext. The fraudster then has his own number registered.

If the fraudsters have infected the users browser with a Man in the Browser attack, they could equally subvert transactions protected by hardware tokens or card readers.

In my view a real-time automated call to the mobile, incorporating authentication and transaction verification (i.e. the playback of the transaction received by the bank – in this case the requested to change his/her registered mobile), would enable the fraudulent transaction to be foiled at source and the customer would be immediately placed in contact with a resource at the bank to deal with such issues….such is the power of real-time telecommunications!