Research by Aazim Bill SE Yaswant and Vishnu Pratapagiri
In July 2023, it was discovered that an Android mobile campaign, which consisted of banking trojans, was targeting major Iranian banks. Zimperium’s research team recently found that the campaign not only remains active but also extended its capabilities. These newly found samples are completely undetected by the industry. At the same time, evidence was found linking this threat actor to phishing attacks targeting the same banks.
Part 1: Previous Iranian mobile banking malware research
Previously released research identified four clusters of credential-harvesting apps imitating four major Iranian banks (Bank Mellat, Bank Saderat, Resalat Bank, and Central Bank of Iran). In total, 40 apps were found that were reported to circulate from December 2022 to May 2023 and have the capability to:
- Steal banking login credentials
- Steal credit card information
- Hide app icon (to prevent uninstallation)
- Intercept SMS to steal OTP codes
The apps mimicked legitimate versions found on Cafe Bazaar (a popular Iranian market place) and were distributed through several phishing websites, with some of them functioning as command and control servers.
New variants
Zimperium’s research team found 245 apps that were not reported by the original research. Among these, 28 remain undetected by the industry (when uploaded to VirusTotal for scanning).
These samples can be directly linked to the same threat actors and represent two additional iterations of Iranian mobile banking malware since the original research. The first iteration is identical to what was previously reported but includes new targets, the second iteration includes many new capabilities and evasion techniques to make the attack more successful.
The following sections will describe these new variants and capabilities in detail.
Iteration1: Extended targets
Apart from the banks mentioned previously, the app is checking for the presence of other applications. However, not all of them are being actively attacked by the malware. This reveals the malware developers’ plan to expand the attack.
The table below shows the banks that were targeted in the first campaign (on top) and the new banks targeted in the second iteration (highlighted in dark gray). The newly weaponized targets were mentioned in the original research but not yet actively targeted. At the same time, the table shows new non-weaponized targets (highlighted in light gray).
In addition to the discovery of the newly targeted banks, we have seen the ambitions of the threat actors getting bigger since they are also collecting information about the presence of several cryptocurrency wallet applications. Based on the development of the previous variants, it is highly likely that these crypto wallets will be targeted in the near future. The following table shows the full list of apps targeted by this campaign.
Iteration 2: New capabilities
The second iteration of this malware has many unseen capabilities on these families. In this section, we’ll describe them.
Accessibility service abuse
The banker uses accessibility services to overlay screens with the purpose of harvesting login credentials and credit card details.
The attack works by monitoring currently open applications and by opening a webview with a phishing URL if the app in the foreground is on the target list. In previous versions of this malware, the attack was performed using a local file fetched using “content://”. This gives the attacker greater flexibility since the webviews can be modified dynamically.
In addition, accessibility services are used to:
- Auto grant SMS permissions.
- Prevent uninstallation.
- Search for and click on UI elements.
Data exfiltration
An analysis of the Command and Control (C&C) servers used by the campaign showed that some servers have open directories containing its PHP code. By analyzing them, it was possible to get a better understanding on how the data is exfiltrated from the victims to the malware operators.
The data obtained by the phishing links is sent to the C&C through the javascript code shown in Figure 1.
Analyzing the code of the C&C, we found Telegram channel IDs and bot tokens. This information is used to send the data collected to a channel for distribution. The PHP code used to do this is shown in Figure 2.
Usage of GitHub to share the final C&C URL
We observed some variants that are communicating with Github repositories. Upon closer analysis, we found that the repositories contain a README file with a base64 encoded text of the latest live phishing and C&C server URLs.
This allows attackers to quickly respond to phishing sites being taken down by updating the GitHub repository, ensuring that malicious apps are always getting the latest active phishing site. Figure 3 shows a screenshot of one of the repositories found to be actively used by this campaign. The string shown in the README.md file is the base64 encoding of the following: “api_link”:”hxxps://sadeaft.site/rat/”,”api_web”:”hxxps://sadertac-web.click/”
Figure 4 shows the Android code that the app uses to communicate with the GitHub repository and obtain the latest phishing site. In the code snippet shown, it can be seen how the app opens a connection to a Github repository and reads the README.md file. Further down, it’s using utility functions to decode the string.
The accounts used in this campaign were taken down by GitHub after we reported them for violating their terms of service.
Using an interim C&C to get the final Phishing URL
Another common technique used to fetch active phishing sites consists of the use of C&C with the sole purpose of distributing active links. This approach allows for the server URL to be hardcoded on the application without the risk of being taken down.
Figure 5 shows a screenshot of an example of one of these intermediate C&C servers. The file urlx.txt contains a base64 encoded string that, similar to what was shown in the previous section, contains the URL of the phishing site. The URL encoded in the image is: hxxps://webpagea.click
Iranian mobile banking malware: Vendor-Specific Attacks
A drawback of using accessibility services is that it requires the user to grant permissions. For this reason, attackers implemented vendor specific attacks. In particular, they are targeting Xiaomi and Samsung devices.
Figure 6 shows a code snippet implemented by the app in which the device manufacturer is checked and certain actions are taken only for the previously mentioned manufacturers. The defined functions auto-grant SMS permissions, prevent the app uninstallation, and click on matched strings. Figure 7 extends the previous figure by showing Samsung-specific code.
iOS as a potential target
The phishing sites used by this malware also verify if the page is opened by an iOS device. In that case, a website mimicking the iOS version of the app is served (see Figure 8). However, we were not able to find the IPA files that could be spawning the webview on iOS. This suggests that, at the moment, the iOS campaign could be under development, or distributed through an, as of yet, unidentified source.
Telegram Channel Analysis
The phishing campaigns used are sophisticated, trying to mimic original sites in the closest detail. Figure 9 shows an example of a site that prompts the user to either log in or register and shows different screens for each of the options.
The data stolen by this phishing site is sent to two Telegram channels. One of them doesn’t have any protection and can be accessed publicly. Figure 10 shows an example of the kind of messages posted on it. It can be seen that account numbers, IP, device models, and pin codes are distributed on it.
The channels were reported to Telegram so they could be taken down. Due to the sensitivity of the data, we are not disclosing the names of the channels in this blog post. However, we analyzed all messages posted on the open channel and found the distribution of the data collected by the attackers. The distribution of messages is shown in Figure 11. It can be seen that the most common type of message sent to the channel is OTP codes (as is expected, since a single user can produce several of these messages), followed by login credentials and credit card numbers.
Zimperium vs. the Banker: Safeguarding Against the Banking Trojan
Zimperium’s research team identified 245 new variants of this previously reported Iranian mobile banking malware. Of those, 28 were completely undetected by the industry. Eighty-seven percent of the phishing domains found by Zimperium’s on-device phishing detection engine were correctly identified. Customers using Zimperium’s Mobile Threat Defense (MTD) and Runtime Protection SDK (Zimperium zDefend) are fully shielded from these variants, thanks to the patented Dynamic On-Device Detection Engine employed by these solutions.
It is evident that modern malware is becoming more sophisticated, and targets are expanding, so runtime visibility and protection are crucial for mobile applications. During our upcoming Mobile Banking Heist Report, we will examine how the largest banking and fintech apps continue to be targeted by advanced malware attacks.
Currently, Zimperium protects over 135 mobile-powered businesses in the financial sector from mobile threats. Zimperium’s Mobile Application Protection Suite (MAPS) helps these businesses build self-defending mobile apps that protect themselves from reverse engineering and malware abuse. The Code Protection (Zimperium zShield) component applies advanced protections to deter threat actors from reverse engineering the app and finding vulnerabilities that malware can exploit. A runtime security SDK (Zimperium zDefend) component when embedded within the app provides security teams with real-time threat visibility and allows the app to defend itself against malware and other on-device threats across device, network, and phishing vectors.
Although our research focuses on mobile banking apps, malware poses a similar threat to enterprise data and networks accessed by employee mobile devices. As a solution to this risk, Zimperium offers Zimperium Mobile Threat Defense (MTD). Designed with privacy as a priority, Zimperium MTD delivers extensive security for mobile devices within enterprise environments. It effectively safeguards both Bring Your Own (BYO) and company-owned devices from a range of threats including device vulnerabilities, network attacks, malware intrusions, and phishing attempts.
Zimperium’s expertise in identifying mobile threats, including those undetected by others, makes it a formidable ally in the fight against advanced malware campaigns. Our ability to detect malware iterations, understand attacker tactics, and identify targeted applications, along with proactive threat intelligence and robust security measures, make Zimperium a valuable partner in safeguarding digital assets against this growing wave of sophisticated cyber threats.
IOCs
The IOCs identified during this research can be found in [Github repository].
A complete list can be found on https://github.com/Zimperium/Iranian-banking-malware
