ANDROID MALWARE POSING AS INDIAN BANK APPS
At CYFIRMA, we are committed to delivering timely intelligence on emerging cyber threats and adversarial tactics targeting individuals and organizations. This report presents an in-depth analysis of a malicious Android application designed to impersonate legitimate Indian banking apps to facilitate credential theft, surveillance, and unauthorized financial activity. The malware leverages advanced techniques such as silent installation, abuse of Android permissions, and remote command execution to evade detection and maintain persistence, using Firebase for command-and-control (C2) operations and phishing pages to mimic genuine banking interfaces and deceive users. By dissecting both static and dynamic behaviors, this report aims to raise awareness and strengthen defenses against mobile banking threats.
The malware operates through a modular architecture involving a dropper and a main payload, using deceptive UI, silent installation mechanisms, and extensive abuse of Android permissions. The below analysis reveals the malware’s capabilities, including SMS interception, data exfiltration, debit card data harvesting, call forwarding abuse, and remote command execution. Firebase infrastructure is used for C2 operations, while stealth techniques such as hidden launcher activities help evade detection. The malware’s use of social engineering, permission exploitation, and persistent behaviors poses significant threats to mobile banking security. This report highlights key behaviors, permissions, and infection tactics, offering crucial insights for defenders and analysts tracking mobile threats.
The malicious banking APK (Dropper) requests the following Android permissions, which enable key functions used for reconnaissance, persistence, and privilege escalation:
android.permission.ACCESS_NETWORK_STATE
This permission allows the application to monitor network connectivity and determine if a device is connected to Wi-Fi or mobile data. Malicious actors use this to ensure payload delivery or data exfiltration occurs only when a stable connection is available, minimizing detection risk.
android.permission.REQUEST_INSTALL_PACKAGES
This highly sensitive permission enables the app to prompt installation of additional APKs from unknown sources. In malicious campaigns, it is commonly abused to drop secondary payloads or malware components once initial access is gained, often without the user’s awareness.
android.permission.QUERY_ALL_PACKAGES
This permission grants visibility into all installed apps on the device. Threat actors exploit it to profile the device, identify security apps or banking apps, and tailor attacks accordingly (e.g., overlay attacks or credential harvesting on specific targets like banking apps).
Silent Installation Mechanism Used by Android Banking Droppers to Deliver Payload
A Malicious Android dropper loads a hidden APK or base Payload (app-release.apk) from the app’s assets folder and writes it to external storage. It then uses FileProvider to generate a URI and prompts the user to install the secondary APK using an intent. The INSTALL_NOW flag triggers the entire process without further user interaction. This behavior is often seen in banking Trojans to deliver the main malware payload after initial infection – such tactics help malware bypass app store checks and deceive users into enabling unauthorized installations.
The PermissionActivity is used to request the REQUEST_INSTALL_PACKAGES permission, allowing the malware to install further payloads. On devices running Android 8.0 (API 26) and above, if the permission isn’t already granted, the user is redirected to the “Manage Unknown App Sources” settings page for the app, tricking them into allowing installations from unknown sources. A delay is introduced using a handler to wait and then reattempt the process. Once permission is granted, the malware silently launches the MainActivity, passing an INSTALL_NOW flag to execute the main payload dropper routine, enabling the APK installation in the background.
The main APK requests the following Android permissions, which support key malicious activities such as data theft, persistence, and stealthy operation:
READ_SMS: Allows the app to read incoming SMS messages, which can be used to steal OTPs, 2FA codes, or other sensitive information.
SEND_SMS: Grants the ability to send SMS messages. This can be exploited to spread malware or take control of banking apps by verifying the device through outgoing OTP messages.
RECEIVE_SMS: Enables interception of incoming SMS messages. Used to monitor, steal, or silently suppress verification messages.
REQUEST_IGNORE_BATTERY_OPTIMIZATIONS: Used to bypass battery-saving restrictions. Ensures persistent background activity without being killed by the system.
READ_PHONE_STATE: Provides access to phone details like network, call status, call forwarding, execute USSD code, make a call, and IMEI. It can aid in device fingerprinting and user tracking.
READ_PHONE_NUMBERS: Allows access to the phone’s own number(s). used for identifying the user or linking device data.
POST_NOTIFICATIONS: Enables capturing notifications. May be used for phishing, fake alerts, capturing OTP, or persistent presence
RECEIVE_BOOT_COMPLETED: Triggers app restart after device boot. Ensures the malware runs automatically upon reboot for persistence.
The main payload deliberately hides itself from the user’s app list by setting its activity category to INFO instead of the usual LAUNCHER, which means the app runs silently in the background without showing any icon, making it invisible to the user. This technique is commonly used by malware to stay hidden and avoid detection while remaining active.
Separate classes are implemented within the malware to carry out specific malicious tasks. For example, the Account class is responsible for harvesting sensitive user credentials, while the Debit class focuses on collecting debit card information. Additionally, the AutostartHelper class is designed to ensure persistence by enabling the malware to automatically restart upon device boot, maintaining its persistence on the user’s device.
The main payload’s phishing page mimics a legitimate banking app by validating user inputs. It first checks that the entered phone number is at least 10 digits long, displaying an error message if the requirement is not met. Next, it verifies that the MPIN (mobile PIN) contains at least 4 digits, alerting the user if it falls short. Overall, it enforces basic input validation similar to a genuine banking application to appear authentic and capture user data effectively.
This malicious Android app is designed to steal debit card information. It checks if the CVV is exactly 3 digits, the card number is 19 characters long, and the ATM PIN is 4 digits. If any condition fails, it shows a warning message using a toast and stops further execution.
The malicious APK saves a local key-value pair (“check” = “false”) and retrieves a locally stored user ID (“id”). It then creates a Firebase Realtime Database reference pointing to the path user/<userID>, which is used to store or fetch user-specific data.
Offline Data Capture and store the values
This method saves a key-value pair (str and str2) into the app’s local storage using SharedPreferences. It ensures the data is stored persistently and applied immediately.
These are Firebase configuration keys embedded in an Android app, including the sender ID, API keys, app ID, crash reporting key, and storage bucket, used to connect the app to Firebase services like messaging, analytics, and cloud storage.
The SMS-stealing technique used by the malicious APK involves monitoring incoming SMS messages by processing each received Protocol Data Unit (PDU). It captures critical metadata such as the sender’s number, message content, and timestamp. The application then leverages Android’s SubscriptionManager to identify the active SIM slot and the associated phone number. This information is subsequently passed to a background thread for further handling, typically used to exfiltrate the intercepted SMS data to a remote server or attacker-controlled infrastructure.
The sendMessage function asynchronously sends SMS message details to a Firebase Realtime Database. It collects data such as the message content, sender, timestamp, message type, sender’s phone number, and receiver, then stores this information in the cloud database, allowing threat actors to remotely collect and monitor intercepted SMS messages.
Permission and Subscription Check:
The code checks if the app has the READ_PHONE_STATE permission. If granted, it retrieves a list of active SIM subscriptions using SubscriptionManager.
SIM Data Extraction:
For each active SIM slot, it extracts key data:
These details are stored in a LinkedHashMap.
This malicious app processes push notifications received via Firebase Cloud Messaging (FCM): when a new message arrives, it extracts data fields such as the title, message, number, and carrier, and based on the value of the message content, it constructs a USSD code using the phone number (activate call forwarding using **21*number#) or a fallback payload using encoded hash symbols (##21#). It attempts to silently forward incoming calls to an attacker-controlled number without user consent.
This malware also enables unauthorized remote calling, potentially abusing Android telephony services to initiate call forwarding or execute USSD codes. This tactic is often used by banking malware or spyware to silently redirect calls or enable surveillance.
The dropper executes by displaying a fake update popup designed to trick the user into clicking.
The dropper prompts the user to enable the ‘Install Unknown Apps’ permission, which allows the main payload to bypass standard security checks and gain installation privileges on the device.
Main Payload Execution
The main payload requests SMS permissions to Read and Send Messages
Main Payloads Phishing Page Mimicking Legitimate Banking App
While Firebase is widely used for legitimate app development, its free-tier access and anonymous setup make it a popular choice for misuse. In this case, the attacker leverages the Firebase as a C2 server to collect sensitive user information. During our investigation, access to the Firebase instance was denied, as it was secured and not publicly accessible. However, the screenshot below confirms that the C2 server remains active and requires authentication for access, indicating it is still operational and potentially in use for malicious purposes.
An APK sample impersonating a legitimate Indian banking application was observed on April 3, 2025, highlighting ongoing trends in mobile-based credential theft and financial fraud.
In many cases, cybercriminals developing malicious banking apps employ deceptive techniques to increase the success of their campaigns. This includes using icons, app names, and user interfaces that closely mimic legitimate banking applications to deceive users into trusting and installing the app. Once installed, these apps often prompt high-risk permissions, thereby capturing credentials and one-time passwords (OTPs) to bypass 2-FA authentication.
Top Delivery Methods for Malicious Banking Apps on Android
Threat actors use a variety of vectors to deliver banking trojans to Android devices, which commonly rely on social engineering, technical deception, and exploitation of platform features or vulnerabilities.
Social Engineering & Phishing
| Method | Description |
| Smishing (SMS phishing) | Fake SMS messages containing links to malicious APKs (e.g., “Your bank account is locked. Click here to verify.”). |
| Email Phishing | Phishing emails masquerading as bank communications, embedding malicious APK links or QR codes. |
| Messaging Apps (e.g., WhatsApp) | Malicious links or APKs spread through impersonated contacts or automated bots. |
| Fake Support Calls (Vishing) | Victims are convinced over the phone to install “security” or “support” apps that are malicious. |
Fake Websites & SEO Poisoning
| Method | Description |
| Fake Bank Websites | Cloned websites impersonating legitimate banks, offering fake apps for download. |
| SEO Poisoning | Malicious APKs promoted via search engine manipulation through fake blogs or forums. |
| Fake App Store Pages | Third-party stores that mimic Google Play, distributing trojanized banking apps. |
Malvertising
| Method | Description |
| In-App Ads | Ads embedded in legitimate apps that redirect users to malicious banking APKs. |
| Adware Push Notifications | Fake alerts urging users to update or install a banking app via deceptive APK links. |
Trojan Droppers and Loaders
| Method | Description |
| Benign-looking Utility Apps | Apps like “QR scanners” or “battery savers” that secretly download and install banking malware. |
| Stage 1 Droppers | Lightweight APKs that fetch and install the full banking trojan from remote servers. |
| Fake System or Play Protect Updates | Apps pretending to be Android system updates or security tools to trick users into installing them. |
QR Codes and NFC (Near Field Communication) Attacks
| Method | Description |
| QR Codes in Posters/Emails | Scanning malicious QR codes redirects to fake banking app downloads. |
| NFC-Based Payloads | Malicious NFC tags placed in public locations (e.g., ATMs) trigger downloads on tap. |
Physical Access / Preloading
| Method | Description |
| Preloaded Malware (Supply Chain) | Some low-cost or counterfeit devices come with pre-installed banking malware. |
| USB Sideloading | Malicious apps manually installed via USB when the attacker has physical access to the device. |
Exploitation of System Vulnerabilities
| Method | Description |
| Abuse of Accessibility Services | Users are tricked into granting permissions that allow silent installs, overlays, and monitoring. |
| Exploiting Android Vulnerabilities | Attackers leverage known vulnerabilities (e.g.: CVE‑2025‑27363) to bypass security controls or execute code remotely. |
The banking malware exhibits a modular, evasive, and persistent architecture, specifically targeting Android users through social engineering and technical exploitation. It leverages permissions like ‘Install from Unknown Sources’ for silent payload delivery and employs Firebase Cloud Messaging (FCM) for covert remote C2 communication. These capabilities enhance its stealth and operational impact, highlighting the urgent need for user vigilance and robust, layered security measures within financial ecosystems to counter advanced mobile threats.
This type of malware may also leverage fake websites, malvertising, Trojanized utility apps, QR/NFC vectors, and exploit Android system vulnerabilities, demonstrating the skill and versatility of attackers in delivering and executing malicious payloads.
| Indicator | Type | Remarks |
| ee8e4415eb568a88c3db36098b7ae8019f4efe565eb8abd2e7ebba1b9fb1347d | Sha256 | Base Payload or Dropper |
| 131d6ee4484ff3a38425e4bc5d6bd361dfb818fe2f460bf64c2e9ac956cfb13d | Sha256 | Main Payload |
| Tactic | Technique ID | Technique |
| Initial Access | T1476 | Deliver Malicious App via Other Means |
| Execution | T1204.002 | User Execution: Malicious File |
| Persistence | T1409 | Install Insecure or Malicious App |
| Persistence | T1547.001 | Boot or Logon Autostart Execution: Registry Run Keys |
| Persistence | T1406 | Broadcast Receivers |
| Credential Access | T1414 | Input Capture |
| Credential Access | T1421 | Capture SMS Messages |
| Collection | T1402 | Broadcast Receivers |
| Collection | T1409 | Access Stored Application Data |
| Discovery | T1421 | System Network Connections Discovery |
| Discovery | T1424 | Process Discovery |
| Discovery | T1426 | System Information Discovery |
| Command and Control | T1437 | Application Layer Protocol |
| Command and Control | T1573 | Encrypted Channel |
| Defense Evasion | T1407 | Download, Install, or Load Code from Remote Sources |
| Defense Evasion | T1445 | Hide Application Icon from App Launcher |
| Impact | T1496 | Resource Hijacking |
| Exfiltration | T1430 | Exfiltration Over Alternative Protocol |
rule Malicious_Bank_APK
{
meta:
description = “Detects malicious Banking Application masquerading as a legit BANK”
author = “CYFIRMA_Research”
threat_type = “Banking malware”
date = “2025-07-23”
sha256_1 = “ee8e4415eb568a88c3db36098b7ae8019f4efe565eb8abd2e7ebba1b9fb1347d”
sha256_2 = “131d6ee4484ff3a38425e4bc5d6bd361dfb818fe2f460bf64c2e9ac956cfb13d”
strings:
$hash1 = “ee8e4415eb568a88c3db36098b7ae8019f4efe565eb8abd2e7ebba1b9fb1347d”
$hash2 = “131d6ee4484ff3a38425e4bc5d6bd361dfb818fe2f460bf64c2e9ac956cfb13d”
$res1 = “activity_finalscreen.xml”
$res2 = “activity_debit.xml”
$res3 = “activity_customer.xml”
$res4 = “activity_account.xml”
condition:
(any of ($hash*) and any of ($res*)) and
filesize == 7074816
}
Strategic Recommendations
Tactical Recommendations
Operational Recommendations
