The SBI fake banking app shows that SMS authentication has had its day
As a company fortunate enough to have and maintain our own pentesting team, we often do outreach with other organizations to assist with or provide our expertise in offensive security.
In collaboration with the Kerala Police Cyber unit, we were able to assist with investigating a prolific scam targeting the State bank of India (SBI). SBI is the largest bank in India and one of the top 50 largest banks in the world with over half a billion customers and account holders. It presents a significant target and sadly, is not the only institution to attract this kind of attention.
So what is the attack and what does it do?
The attack in question begins with a typical social engineering vector: an SMS or Whatsapp message warning about an account security issue and asking targets to download the attached .apk file. The APK file (an Android app) is, of course, fake and has nothing to do with SBI.
Unsurprisingly, the app misuses SBI’s YONO brand, runs silently and outside the menu context, which is quite a normal feature for these kinds of apps. The fake app is well protected from reverse engineering and employs anti-forensic techniques to hinder or restrict investigation of the APK itself. (If you’re interested in the trials and tribulations in analyzing the app check out this post.)
The app spoofs the SBI bank login page to collect data from the end user (e.g., account number, card number, password, etc.) and send it to the attacker, who will subsequently use it to log into the legitimate site.
When the bank sends the second authentication factor via SMS to the victim, the malicious app forwards it to a phone number that the attacker controls, and the attacker can now log into the banking portal and empty the victim’s account(s).
The industrialization of the fraud is surprising: there were over 100 different sub-domains mapped to different victims, and unique phone numbers were assigned on a rotating basis, meaning no phone number was used twice (classic burner numbers). Extrapolating from the findings, it seems that at least 100 new victims were being targeted with the fake app each week. Although, as the Police investigation is still ongoing, we aren’t privy to the true number of eventual victims, and there may be tens of thousands of them out there.
Mitigation and conclusions
So breaking it down there are two obvious flaws here.
The first is obviously the ease with which .APKs can be sideloaded. Although there are default configurations to prevent this within most modern Android platforms, the sheer number and variety of Android flavors today guarantees that “spray and pray” attacks like these still work. Naturally this gives a big edge to the iOS platform, since side-loading apps on iOS devices without their being jailbroken is difficult, to say the least.
The next flaw is that SMS as way to receive a second authentication factor is easily compromised and really has no place in secure apps or financial applications of any kind. The fact that many banks still use it as an option is worrying. For example, HSBC (Europe’s largest bank and 8th largest in the world) still defaults to SMS authentication for transaction confirmations, although it has now started to lean heavily into app-based authenticators and soft tokens.
In enterprise contexts, we have evolved and moved quite far into the “zero trust” concept and no longer rely heavily on technologies like SMS authenticators. On the consumer front, vendors like Apple, Microsoft and Google have now also started to deploy passkeys at scale in consumer-based applications – a welcome relief from password overload and insecure methods of 2FA delivery.
It would be good to see large financial global institutions taking the threat more seriously and pivoting away from legacy authentication options so that industrial scale theft and fraud of consumer bank accounts can become a thing of the past.