The rapid escalation of banking malware has become a concern for everyone involved in the financial sector, especially traditional and digital-only banks. Grifthorse, Godfather, and other malicious software have evolved to impersonate and target hundreds of banks, developing sophisticated means to steal credentials and conduct fraud. According to our research, the total number of unique mobile malware samples increased by 51% from 2021 to 2022, with more than 920,000 samples of Dirty RatMilad, MoneyMonger, and Dark Herring detected.
About $8 million was lost in more than 700 malware-related scams reported in Singapore last month. In eight of these scams, CPF savings were involved, resulting in losses of $124,000. The victims were tricked into downloading malware onto their phones, resulting in unauthorized transactions from their bank accounts.
The challenge has prompted many customers and regulatory bodies to search for more practical measures and solutions to secure mobile banking applications.
Banking malware: How does it work?
Today’s banking scams are a complex web of deceit that stretches across multiple platforms and mediums. Crafted with a keen understanding of human psychology, these scams employ highly sophisticated social engineering campaigns that begin with the seemingly innocuous act of distributing phishing links. These can be found within emails, SMS messages, and even disguised as QR codes. What makes these tactics so insidious is how they mimic legitimate banking activity, lulling the user into a false sense of security.
Upon clicking on the provided URL or scanning the QR code, a user is redirected to a fake banking page that appears genuine. The deception continues as the page persuades the user to download and install what is presented as a companion app but is, in reality, malicious software or malware. The app then scans the phone, identifying the banking apps that are present, and downloads the necessary assets from a command and control server to further imitate that particular bank.
From this point on, the malware performs a sinister dance each time the end-user opens their real banking app. It seamlessly overlays the login screen, capturing the user’s credentials and One-Time Password (OTP), and then redirects the user to the legitimate app, all without the user suspecting that anything is amiss. Upon taking over the account, other malware capabilities like remote control and screen sharing help intercept and authorize transactions to move money out of the account without triggering alarms.
If the end-user’s device hosts multiple banking apps, the malware continues its deception with each one until it succeeds.
How are banks responding to the threat
Threats from malware are relentless and rapidly evolving. Malicious actors are sharing malware code more often and creating new, more capable malware variants. In order to steal account credentials, ‘CypherRat‘ combined SpyNote’s spying capabilities with banking trojan features such as remote access, GPS tracking, and device status and activity updates.
In order to keep up, banks are adding new security features to their mobile applications to detect malware behaviors. Under these new security protocols, users are temporarily blocked from using the app if suspicious apps are found on their phones. Bank customers who wish to access their bank accounts face not only inconveniences, but also privacy concerns due to the way these protocols function.
But the banking malware problem is multifaceted. We cannot merely label an app as malware based on individual features, permissions, or source, as legitimate apps often have the same individual characteristics. Moreover, malware authors are shrewd. Once they discern what security tools to target, they craft new permissions or capabilities to evade detection. There is no single feature that can determine whether an app is malicious and poses a risk to banking apps.
How regulators are evolving to secure mobile banking
Regulatory bodies globally, responding to an increase in malware-related scams, are mandating various security measures for standard and digital- only banks. Here are a few key examples:
Monetary Authority of Singapore (MAS)
Over 150 deposit-taking institutions are regulated and supervised by the Monetary Authority of Singapore (MAS), including full banks, wholesale banks, merchant banks, and finance companies. MAS issues a revised Technology and Risk Management Guidelines in 2021 that specified security requirements that should be considered to secure mobile banking applications.
Annex C: Mobile Application Security
C.1 Security measures that should be considered for securing mobile applications are as follows:
(a) avoid storing or caching data in the mobile application to mitigate the risk of data compromise on the device. Data should be stored in a protected and trusted area of the mobile device;
(b) protect private cryptographic keys;
(c) implement anti-hooking or anti-tampering mechanisms to prevent injection of malicious code that could alter or monitor the behaviour of the application at runtime;
(d) implement appropriate application integrity check (e.g. using checksum and digital signature) to verify the authenticity and integrity of the application and code obfuscation techniques to prevent reverse engineering of the mobile application;
(e) implement certificate or public key pinning to protect against MITMA;
(f) implement a secure in-app keypad to mitigate against malware that captures keystrokes; and
(g) implement device binding to protect the software token from being cloned.
Reserve Bank of India
In its Master Direction on Digital Payment Security Controls, the Reserve Bank of India (RBI) provides security guidance for regulated entities planning to offer mobile banking and mobile payments services to their customers.
Chapter IV
MOBILE PAYMENTS APPLICATION SECURITY CONTROLS
In addition to the controls prescribed in Chapter II, the following instructions are applicable to the REs offering/ intending to offer mobile banking/ mobile payments facility to their customers through mobile application:
55. On detection of any anomalies or exceptions for which the mobile application was not programmed, the customer shall be directed to remove the current copy/ instance of the application and proceed with installation of a new copy/ instance of the application. REs shall be able to verify the version of the mobile application before the transactions are enabled.
56. Specific Controls for mobile applications include:
a. Device policy enforcement (allowing app installation/ execution after baseline requirements are met);
b. Application secure download/ install;
c. Deactivating older application versions in a phased but time bound manner (not exceeding six months from the date of release of newer version) i.e., maintaining only one version (excluding the overlap period while phasing out older version) of the mobile application on a platform/ operating system;
d. Storage of customer data;
e. Device or application encryption;
f. Ensuring minimal data collection/ app permissions;
g. Application sandbox/ containerisation;
h. Ability to identify remote access applications (to the extent possible) and prohibit login access to the mobile application, as a matter of precaution; and
i. Code obfuscation.
57. REs may consider to perform validation on the security and compatibility condition of the device/ operating system and the mobile application to ensure that activities relating to the account are put through the mobile application in a safe and secure manner.
58. REs may explore the feasibility of implementing a code that checks if the device is rooted/ jailbroken prior to the installation of the mobile application and disallow the mobile application to install/ function if the phone is rooted/ jailbroken.
59. Checksum of current active version of application shall be hosted on public platform so that users can verify the same.
60. REs shall ensure device binding of mobile application5.
61. Considering that the additional factor of authentication and mobile application may reside on the same mobile device in the case of mobile banking, mobile payments, REs may consider implementing alternatives to SMS-based OTP authentication mechanisms.
62. The mobile application should require re-authentication whenever the device or application remains unused for a designated period and each time the user launches the application. Applications must be able to identify new network connections or connections from unsecured networks like unsecured Wi-Fi connections and must implement appropriate authentication/ checks/ measures to perform transactions under those circumstances.
63. The mobile application should not store/ retain sensitive personal/ consumer authentication information such as user IDs, passwords, keys, hashes, hard coded references on the device and the application should securely wipe any sensitive customer information from memory when the customer/ user exits the application.
64. REs shall ensure that their mobile application limit the writing of sensitive information into ‘temp’ files. The sensitive information written in such files must be suitably encrypted/ masked/ hashed and stored securely.
65. REs may consider designing anti-malware capabilities into their mobile applications.
66. REs shall ensure that the usage of raw (visible) SQL queries in mobile applications to fetch or update data from databases is avoided. Mobile applications should be secured from SQL injection type of vulnerabilities. Sensitive information should be written to the database in an encrypted form. Web content, as part of the mobile application’s layout, should not be loaded if errors are detected during SSL/ TLS negotiation. Certificate errors on account of the certificate not being signed by a recognised certificate authority; expiry/ revocation of the certificate must be displayed to the user.
Reserve Bank of Malaysia
The Reserve Bank of Malaysia published Risk Management in Technology (RMiT) that sets out the Bank’s requirements with regard to financial institutions’ management of technology risk. It specifies the control measures on mobile applications and devices.
Appendix 4 Control Measures on Mobile Application and Devices
1. A financial institution should ensure digital payment, banking and insurance services involving sensitive customer and counterparty information offered via mobile devices are adequately secured. This includes the following:
(a) ensure mobile applications run only on the supported version of operating systems and enforce the application to only operate on a secure version of operating systems which have not been compromised, jailbroken or rooted i.e. the security patches are up-to-date;
(b) design the mobile application to operate in a secure and tamper-proof environment within the mobile devices. The mobile application should be prohibited from storing customer and counterparty information used for authentication with the application server such as PIN and passwords. Authentication and verification of unique key and PIN should be centralised
at the host;
(c) undertake proper due diligence processes to ensure the application distribution platforms used to distribute the mobile application are reputable;
(d) ensure proper controls are in place to access, maintain and upload the mobile application on application distribution platforms;
(e) activation of the mobile application should be subject to authentication by the financial institution;
(f) ensure secure provisioning process of mobile application in the customer’s device is in place by binding the mobile application to the customer’s profile such as device ID and account number; and
(g) monitor the application distribution platforms to identify and address the distribution of fake applications in a timely manner.
2. In addition to the guidance in paragraph 1, a financial institution should also ensure the following measures are applied specifically for applications running on mobile devices used by the financial institution, appointed agents or intermediaries for the purpose of processing customer and counterparty information:
(a) mobile device to be adequately hardened and secured;
(b) ensure the capability to automatically wipe data stored in the mobile devices in the event the device is reported stolen or missing;
(c) establish safeguards that ensure the security of customer and counterparty information (e.g. Primary Account Numbers (PAN), Card Verification Value Numbers (CVV), expiry dates and Personal Identification Numbers (PIN) of payment cards), including to mitigate risks of identity theft and fraud21;
(d) enforce masking of sensitive customer and counterparty information when displayed on mobile devices; and
(e) limit the storage of customer and counterparty information for soliciting insurance businesses in mobile devices to 30 days.
The Threat is Evolving – So Must Our Defenses
The fundamental question is: Can the mobile banking app recognize a threat to its integrity, whether from the device itself, the network connection, or malware that inhabits the same space?
Enter “adaptive runtime security,” a proactive and responsive approach that can make mobile banking apps self-defending. Unlike static measures, adaptive security resembles an autonomic biological immune system, continuously adjusting to the ever-changing threat landscape.
Introducing Zimperium zDefend™
Over 85 global banks trust Zimperium to secure their mobile devices and apps, making this a solution for our modern world.
Zimperium’s Runtime Application Self-Protection (zDefend) provides a robust and regulatory-grade solution to these challenges. zDefend is a comprehensive in-app protection solution. It combines machine learning, deterministic techniques and behavioral techniques to provide comprehensive on-device visibility into and protection against devices, networks, malware, and phishing attacks.
When embedded in a mobile application, in-app security acts like a biological immune system that protects the app from known and unknown threats on the device.
This real-time visibility and protection is achieved through an SDK integrated into the host mobile application.
In most cases, mobile app teams do not have visibility into threats across their entire mobile application installation base at runtime. The solution allows App Dev and SOC teams to continuously monitor the entire install base and be alerted when abuse is attempted. When appdev and appsec teams have visibility into real and relevant threats, they can perform meaningful threat modeling and make good decisions about what to secure and what to recommend for residual risks.
The SDK leverages Zimperium’s patented dynamic on-device detection engine (z9), which is unparalleled in detecting malware. In an independent AV test, the solution detected over 99% of online and offline malware.
The protection is provided by on-device actions mapped to specific threats. There are out-of-the-box actions such as blocking app usage, redirecting to a URL, etc., but developers can also create custom actions. When configured properly, the actions allow app teams to choose between disabling just the high-risk features rather than completely blocking the app when a side-loaded malware is detected on the device. As a result of this practical approach to security, the end-user experience is also great.
Unlike other solutions these in-app detections and protections can be updated over-the-air. The SDK automatically keeps its detection capabilities up-to-date. A centralized console allows the actions to be changed and propagated in real-time without needing to release a new application.
Zimperium’s zDefend is embedded directly into mobile banking apps, enabling them to recognize untrusted environments and protect against fraudulent activity without completely blocking users from using the app.
zDefend is part of the Mobile Application Protection Suite (MAPS) in the Zimperium Mobile-First Security Platform™. MAPS helps enterprises build safe and secure mobile apps resistant to attacks. It is the only unified solution that combines comprehensive app protection with centralized threat visibility.
Conclusion: A Future-Proof Approach
Security for mobile banking applications must be as dynamic and intelligent as the threats it seeks to combat. With solutions like Zimperium zDefend, we can build a mobile banking application that’s not just reactive to the current threats but prepared for those we have yet to encounter.
Adaptive security represents not only the present necessity but the future of mobile banking security. By integrating these advanced security measures, we fortify our defenses, protect users’ privacy, and foster trust within the entire financial ecosystem.
In a world where banking malware is continually adapting and finding new vulnerabilities, the time for complacency has passed. Adaptive security is no longer a futuristic concept; it is a present-day requirement, a proven approach, and the path forward. It’s time to make our banking apps not just smarter but safer.
