Overview
Type: Trojan
Destruction Degree: Medium
Prevalence: Medium
Malware Names
(Padvish) Trojan.Android.SmsSpy.DET
(Kaspersky) HEUR:Trojan.AndroidOS.Hiddapp.ay
(BitDefenderFalx) Android.Trojan.SpyAgent.OK
(ESET) A Variant Of Android/Spy.Agent.DET
What is a Trojan?
A Trojan is a type of malware that masquerades as legitimate software, presenting itself as functional and benign. However, once executed, it performs malicious actions that can cause significant damage to the system. Trojans infiltrate systems through various methods, including:
• Downloading software from untrusted sources,
• Embedded malicious code in HTML files,
• Malicious email attachments, and more.
What is the SmsSpy Malware Family?
The SmsSpy malware family consists of a set of malicious applications designed to steal sensitive user information, specifically targeting bank account details. These apps are often distributed through reputable Android markets such as Cafe Bazaar and Myket, as well as through less trustworthy platforms like unofficial websites, Telegram channels, and SMS messages containing malicious links. While these applications may appear legitimate and useful at first glance, they are designed to deceive users and steal personal data through phishing techniques.
The malware’s operation typically begins with deceptive promises of offering additional services (such as access to Legal Notice, subsidies, or Justice Shares). If the user is tricked into paying a small fee, they are redirected to a fake bank page. When users enter their login credentials, the malware captures their banking information. Given the malware’s access to SMS messages, it can also retrieve the user’s second-factor authentication code, providing complete access to the compromised account.
Technical Description
Indicators of Compromise (IoCs)
- Requests for dangerous permissions, including access to SMS messages, contacts, installed applications lists, etc.
- Unusual spikes in battery consumption and system resource usage (CPU, RAM).
- Fake notifications.
Technical Overview
Once the malware “Edalat Hamrah” receives the necessary permissions (including access to SMS messages, contacts, notifications, and call data), it launches a web view that directs users to a phishing page designed to extract payment information. This is how the malware steals bank card details by exploiting the permissions it has been granted. Additionally, the malware is capable of listing installed applications, executing hidden USSD codes, and taking screenshots of the compromised device.
A notable feature of this malware ,shown in the above images, is the static captcha code displayed during phishing attempts, which does not change between page reloads. The dates shown on the page are outdated, indicating that previous versions of this malware family are still being utilized. The malware periodically evolves, with slight changes to its code structure. After a period of dormancy, it resurfaces through social networks and unreliable sources, continuing the cycle of phishing attacks.
◽ Main Activity: com.x.team.main
▫️ ResumableSub_Activity_Create Class
This class is integral to the malware’s execution process and runs asynchronously. During the initial phase, the malware checks for necessary permissions, verifies internet and Google services connectivity, and loads the phishing web page step by step within this class. This class can pause execution and resume from the point it left off after receiving results from other methods (such as permission requests or server data retrieval).
The malware uses a state management system in the resume() method, utilizing switch-case and variable state to determine the stage of execution. It terminates its execution in two cases:
- In emulators running on Intel processors.
- If the SIM card’s country code (retrieved via the getSimCountryIso method) is not “IR” (Iran), the malware displays an error message and terminates its execution.
▫️ ResumableSub_GetConfigs Class
This class is responsible for sending a request to the C2 (Command and Control) server to retrieve the malware’s configurations. These configurations may include control commands, new server addresses, communication ports, and other sensitive data required for performing malicious activities. The server address to which the malware sends the initial request is obtained from the method vvvvvvvvvvvv7_. The initial request is sent to obtain the original address to load it into the malware’s WebView.
The method tries to read the server address from the Domain.txt file. If the file does not exist, it retrieves the value from the vvvvvvvvvvvv0_ method. The server address is then stored in the v5_ server variable and saved to the Domain.txt file. This method utilizes the code to encrypt and decrypt C2 server’s main addresses that is written in Domain.txt file.
After decryption, the -v5 value consists of a list of the following C2 server addresses which is also written in the Domain.txt file:
https[:]//api0.x-pdomain-zrc9w6pj3a.store/X.php A-K-U-M-A
https[:]//api1.x-pdomain-zrc9w6pj3a.store/X.php A-K-U-M-A
https[:]//api2.x-pdomain-zrc9w6pj3a.store/X.php A-K-U-M-A
https[:]//api3.x-pdomain-zrc9w6pj3a.store/X.php A-K-U-M-A
https[:]//api4.x-pdomain-zrc9w6pj3a.store/X.php
Once the initial connection is made to the server, the malware retrieves additional configuration data, which is stored as a JSON file in the data/data/com.x.team/files directory, named config.json. This file contains critical operational data, including commands, permissions, and security settings that are usually created after reading the Domain.txt file and tell the malware how to behave. These include:
- The malware’s phishing page URL (https://ikdplc.org/c/app.php).
- Requested permissions.
- Admin panel requests.
- Initial malicious actions, such as the collection of banking and contact information.
- Offline communication settings.
▫️ ResumableSub_ScreenShot Class
The primary function of this class is to capture screenshots of the victim’s device and send them to the C2 server. The malware captures the current activity screen of the device and saves it (Bitmap) in the file AkumaScreenShot.jpg. This file is subsequently uploaded to the server using the send_screen_ method. Along with the screenshot, the following information is sent:
- Operation type (here, “screenshot”).
- Device model.
- Android version.
- Port used by the malware.
- Screen status (whether the screen is on or off).
🔸 com.x.team.r4 Service
The r4 service functions as a foreground service with several malicious capabilities. Using the vvvvvvvvvvvvvvvvvvvvvvv0_ method, it generates a fake notification titled “Settings” with the message “Receiving data” to disguise its activity. This helps prevent the malware from being easily terminated. The malware also changes its application icon to appear as a “settings” icon using the changeicon_ method, further concealing its malicious intent. The original malware icon is hidden via the hideicon_ method to make it harder for the user to remove. Additionally, the r4 service sets up a receiver that checks for the malware every 3 seconds, restarting it if necessary to maintain persistence.
🔸 com.x.team.r6 Service
The r6 service runs an automated process called AutoTar, which operates in the foreground via a hidden notification. If the system attempts to terminate the service, it is automatically restarted. This service sends device information to the C2 server. The vvvvvvvvvvvvvvvvvvvvvvvvvvv3_ method is used by the service to creates a fake notification that appears as a system update process. Then, the malware uses the runautotar_ method to execute an automated process that is responsible for sending device information to the malware server and then propagating malicious SMS messages to the victim’s contacts. The input parameter str in the method contains the text of the SMS message that is to be sent to the user’s contacts, then the send_autotarstart_ method sends the victim’s device information, including Android ID, phone model, communication port, request time, and message ID, to the malware server. After a 30-second delay, the vvvvvvvv5_ method is triggered, sending the malicious SMS to the victim’s contact list. After sending the malicious SMS messages, the service temporarily halts to avoid detection.
🔸 com.x.team.firebasemessaging Receiver
The firebasemessaging receiver, receives incoming messages from the C2 server via Firebase Cloud Messaging FCM). This receiver acts as a communication channel, executing commands received from the server to perform malicious actions on the victim’s device. These commands include sending SMS messages, stealing bank and credit card information, extracting contacts, retrieving SMS messages, and executing USSD codes to steal account balances. This receiver processes and executes the attacker’s desired commands received from the Firebase server through the resume method (in the ResumableSub_ProcessFCMMessage class).
Malicious Commands and Their Functions:
- oneping: Sends basic information about the victim’s phone, such as the model, Android ID, installed apps list, received bank messages, contacts, etc.
- allping: Collects comprehensive data about the device’s status.
- mutephone: Mutes the victim’s phone
- normalphone: Restores the phone to its normal state.
- fullinformation: Sends complete device information, including text messages, call history, contacts, and installed apps information
- AppList: Sends a list of apps installed on the phone.
- screenshot: Captures screenshot of the current activity screen and sends it to the server.
- putdomain: Changes the malware’s C2 server address.
- hideicon: Hides the malware’s application icon for stealth.
- unhideicon: Restores the application icon to its normal state.
- changeicon: Alters the application icon to prevent detection by the user.
- BankInformation: Extracts sensitive bank-related messages and account information from the victim’s device.
- CardNumbers: Extracts the victim’s bank card numbers from available data.
- lastmessage: Retrieves the last sent and received text messages.
- BankSMS: Extracts bank-related SMS messages from the inbox.
- inboxSMS: Retrieves all incoming SMS messages.
- outboxSMS: Retrieves all sent SMS messages.
- getphones: Retrieves the list of phone numbers stored on the device.
- updatesimcard: Gathers SIM card information, such as IMSI and ICCID numbers.
- send_default: Sends SMS from the phone’s default number.
- send_solt: Sends SMS from the second SIM card on dual SIM devices.
- send_contacts: Sends the victim’s contact list to the server.
- offlinemodeon: Activates the malware’s offline mode, allowing it to send data via SMS.
- offlinemodeoff: Deactivates offline mode.
- detect_saderat: Detects SMS messages from Saderat Bank.
- detect_target: Detects SMS messages received from specific numbers
- detect_exchange: Detects cryptocurrency applications installed on the phone
- runussdcode: Runs USSD codes on the victim’s phone
🔷 _send_bankdata Method
This method examines the user’s bank SMS messages and extracts information such as account balance, bank name, account number, and cut number using the getvvvvvvvvv2_ method and sends it to its server along with other user-related information (such as the victim’s phone model, phone ID, user’s phone operator, malware icon status, and screen status). In the getvvvvvvvvv2_ method, as shown in the image below, the list of received SMS messages is first extracted and then each user’s SMS message is examined to find bank messages, along with the text and sender number of the SMS. Next, it detects the bank name from the SMS text and sender number using the detect_bankname_ method. The name of the bank sending the message is obtained using a series of keywords and Regex. The malware then extracts the account balance from bank SMS messages using the bank_findbalance_ method, such that if the SMS text contains phrases such as “balance”, it identifies the amount followed by this as the account balance. The detect_bankaccountnumber_ method also extracts the account number or card number from the SMS text, if the SMS text contains phrases such as “account”, “withdrawal from” or “card”, the malware tries to extract the number followed by these phrases. Finally, the account and balance information is sent to the send_bankdata_ method.
🔷 sendUssdRequest Method
The sendUssdRequest method allows the malware to send USSD requests using the TelephonyManager class. These codes, such as #123* or #1*140*, are sent to the mobile operator, and the response is captured by the onReceiveUssdResponse method. The response, which may include account balances or other operator-related information, is then forwarded to the C2 server.
The malware uses this method to determine if an active SIM card is present and, if so, sends the USSD response to the attacker’s desired number via the vvvvvvvv4_ method.
How to Deal with and Clean the System
To ensure that a device is free from this malware, install the Padvish Antivirus for android, ensure its database is up-to-date, and perform a full device scan to detect and remove the malware.
How to Prevent Mobile Phone Infections
- To protect your device from infection by this or similar malware, adhere to the following best practices:
- Legitimate judicial or government communication will never come from personal numbers or through untrustworthy channels such as Telegram, WhatsApp, or other social networks. Additionally, official notifications will not contain links for payments.
- Always download applications from trusted Android marketplaces, and avoid unofficial versions of apps, as they may contain malicious code.
- There is no need to pay any fees to view electronic notices or justice shares.
- Always check the permissions requested by an app before installing it.
- Do not use modified or unofficial versions of apps.