skip to Main Content

Dealing with Overlay Attacks: Adopting Built-in Security To Safeguard Mobile Experience

The growth of mobile technology and the increased importance of cybersecurity have dominated news cycles in the past year. At the same time, one of the biggest threats we’re seeing against mobile are overlay attacks. These combine social engineering with inherent security weaknesses found in mobile apps, and take advantage of users to trick them into sharing sensitive data.

In the past, these attacks were only spotted in Russia. Later on we have seen the first examples in Europe, such as the MazarBot Android malware, and the US, and there are likely to be more.

So how does it work? What can be done about it? What can organizations and financial institutions do to guard against becoming victims of this malicious attacks?

Understanding the Threat and What it Means for Mobile Banking Apps

In the majority of cases, overlay malware takes the form of a trojan. It is downloaded as a supposedly legitimate application from a legitimate website or app store. It can also be installed by drive-by downloads, which means a user would only need to be on a certain webpage to be compromised.

The malware lies dormant on infected devices, waiting until a user opens up a banking application. Once this happens, the malware pushes the legitimate app to the background, something most apps would not detect as unusual by themselves. In other words, the app wouldn’t know that it’s been pushed to the background. It would therefore keep on functioning normally, accepting user inputs, even though a human couldn’t possibly operate the app.

Simultaneously, the malware creates a window that mimics the look and feel of the app that’s been affected. So, for all intents and purposes, the user would assume they were still interacting with their mobile banking app.

Because the user is none the wiser, they’ll proceed to enter sensitive data while using the banking app as normal. This could be anything from passwords, codes, and financial details. This information is then stolen by the malware. And to make matters worse, data is altered so that the user unknowingly sends transactions to the criminals behind the malware.

Crossing Geographical Borders: BankBot

A recent example of this trojan malware is BankBot. While older samples of BankBot mainly targeted Russian financial institutions, in April 2017 the Dutch company Securify came across a new sample of the malware. This sample shows that BankBot was targeting European and American banks as well.

Newer iterations have targeted at least 420 banks in countries such as Germany, France, Austria, the Netherlands, Turkey and the United States. BankBot, first disguised as a weather forecast application, and then as different video apps, can be downloaded from Google Play. From there it tricks users into giving up usernames, passwords, pin codes, card details, as well as intercepting SMS text messages.

This means it can intercept the text message sent by banking apps to authorize payments. Unfortunately for the user, it’s only when their balances start dropping, or transactions are redirected to criminal accounts, that they realize something’s wrong.

Taking Responsibility: Developers or Providers?

So who’s responsible for protecting against mobile overlay attacks? Is it the app developer or the app provider? Ideally, they should work together. This would ensure that if cyber-criminals exploit one specific weakness on an app, it’s not enough to compromise the user.

The banking application itself should have security built in that detects when the app has been pushed to the background. It should also prevent the user from inputting any details that could be sensitive. However, malware evolves, so there’s always potential for unknown platform weaknesses to be exploited. This is where the joint effort of both developers and providers becomes all the more important.

The solution

The best approach is the sophisticated Application Shielding solution that integrates multi-layered security directly into the mobile apps. So instead of only having one layer of security to break through, hackers would need to compromise numerous layers that are tough to get through to begin with.

Application Shielding also takes into account behavior as well as specific codes. This means it has a greater ability to prevent overlay attacks. However, to be truly effective, the Application Shielding solution chosen shouldn’t provide protection against specific malware samples (eg. the latest version of the BankBot malware). Instead it should provide protection against multiple malware families, such as BankBot, svpeng and Marcher. Many malware families use similar techniques to create overlays so generic Application Shielding solutions will provide more than adequate protection.

Evidently, the technology to prevent overlay attacks already exists, but the question of who will take on the responsibility of making sure everything works together still remains. There is so much to gain from integrating applications security, two-factor authentication and any other solution that ensures users’ confidence and peace of mind. Especially for financial institutions that have a duty to protect customer data and assets. When you consider the great lengths these organizations go to make assurances that their apps are really safe, shouldn’t these apps be as safe as they say they are?

Back To Top