This report analyzes a highly sophisticated Android Banking Trojan with integrated Remote Access Trojan (RAT) functionality, specifically targeting Russian financial institutions. The malware leverages advanced evasion techniques, such as native library encryption, rolling XOR string obfuscation, and real-time VNC-like remote control via WebSocket. Its design allows comprehensive device surveillance, including SMS, call logs, contacts, notifications, and banking app monitoring, highlighting its financially motivated and region-specific focus.
This analysis examines the same malware in detail, providing context for its targeted behavior and technical sophistication. The Trojan is engineered to stealthily compromise Russian users, collecting sensitive information and enabling remote control through native code routines and Firebase-backed command infrastructure. Its extensive permissions, multi-layered persistence, and app-targeting logic demonstrate a strategically focused, financially motivated threat, making it a significant risk to affected users and banking systems.
1. Extensive Permission Abuse
2. Targeted Banking Application Surveillance
3. Data Exfiltration
4. Native Library & Obfuscation Techniques
5. Command & Control (C2) Interaction
6. Remote Access & Device Control
7. Persistence & Stealth Mechanisms
8. Communication & Evasion Techniques
9. Operational Flexibility
The application requests an unusually large and intrusive set of high-risk permissions spanning SMS access, call logs, contacts, phone state, location, overlay display, package visibility, boot persistence, exact alarms, and battery optimization bypass, indicating an attempt to obtain extensive surveillance and control capabilities over the device; such excessive permission aggregation is inconsistent with normal app functionality and is commonly associated with financially motivated spyware or banking malware that aims to intercept OTPs, monitor user activity, manipulate communications, and maintain long-term stealthy persistence.
The app targets the latest Android API while maintaining backward compatibility with older versions, maximizing its potential victim base. The randomly generated package name indicates automated building through a RAT kit, a tactic commonly used to evade signature detection and complicate attribution.
The application’s AndroidManifest intentionally replaces the LAUNCHER category with the INFO category to prevent the app icon from appearing in the device launcher. This deliberate configuration indicates an attempt to conceal the application’s presence from the user, strongly suggesting malicious intent and stealth-oriented behavior.
At launch, the malware loads a native library named sysruntime.so, shifting critical logic away from easily analyzable Java code into compiled native code to hinder reverse engineering and static detection.
The native library sysruntime.so is stored in the /lib folder and built for multiple CPU types, including arm64 v8a, armeabi v7a, and x86_64, which allows the malware to run on most Android devices. Important data, such as the bot ID, server list, and WebView link, is hidden inside this native file instead of the normal app code. The attacker has done this on purpose, so these sensitive details are not easily visible during basic analysis. The values are decrypted only when the app runs, making it harder for security tools and researchers to detect the real infrastructure and behavior of the malware.
Analysis of libsysruntime.so shows functions like getBotId, getServerListNative, getWebviewUrlNative, and getWorkerKeyNative, indicating that important configuration data is fetched from native code. It also contains functions for Firebase credentials, confirming that the malware uses Firebase for command and control while hiding its infrastructure details inside the native layer.
The native function getServerListNative implements an obfuscated routine to decrypt the C2 server address. Two critical data structures reside in the ’.rodata’ section:
XOR Key Array (data_409a80 – 22 bytes)
B2 1F CC E3 6A 7E 71 F4 0A C0 1D 78 7B 4B 1B 15 2A 2F 24 20 33 1C
Encrypted Data Block (data_409aad – starting at offset 0x9AAD)
F5 69 1C 83 CB 52 9F E1 34 A0 6D 3A 7F B2 1D E9 54 C8 6B F7 B6
The decryption logic employs a non-linear memory access pattern using the formula base_address – (24 * floor(counter/24)). This reads bytes from 24 byte aligned blocks located before the data_409aad pointer, making the access pattern non sequential and harder to follow statically. As a result, a complete memory map of the ’.rodata’ section is required to retrieve all referenced bytes.
The XOR key starts at 47 and increments by 91 each iteration across the 22 byte loop. The algorithm implicitly handles 32 bit integer overflow, so precise tracking of the key’s evolution is necessary to reproduce the decryption correctly.
To recover the C2 server address, we reverse-engineered the custom XOR based routine implemented in the native function. The sample stores a 22 byte XOR key (byte_9A80) and an encrypted buffer (unk_9AAD) inside the ‘.rodata’ section. Decryption relies on a non linear access pattern defined as base – 24 * floor(counter/24), along with a rolling XOR key initialized at 47 and increased by 91 on each iteration. We reproduced the exact behavior in a Python script, modeling the complete ‘.rodata’ memory layout referenced by the routine to ensure accurate output.
Decryptor
Running the Python script that reproduces the native getServerListNative decryption routine successfully revealed the hidden server address.
[http://193.233.112[.]229]
The result confirms that the malware keeps its command-and-control address hidden and reconstructs it at runtime using obfuscation techniques that make static analysis difficult.
Following the successful decryption of the C2 server, we used the same approach to extract additional Firebase credentials embedded in the binary. We identified an 8 byte XOR key (byte_9AB8: 3A 7F B2 1D E9 54 C8 6B) in the ‘.rodata’ section, along with a 39 byte encrypted blob at unk_99C0. The decryption relies on a rolling XOR scheme, where each byte is XORed with a running value that increases by 55 each iteration, combined with the static key array.
Custom XOR-Decryptor
Running the Python script that replicates the rolling XOR decryption successfully revealed the Firebase API key.
[AIzaSyAjWqYjz1VbRByhLX8Mu0sXeh6FzIko90]
This confirms that the malware stores sensitive Firebase credentials in an obfuscated form and reconstructs them at runtime using the embedded XOR key and rolling scheme.
Using the same methodology, we were able to decrypt all relevant native functions and extract the embedded credentials. This includes the Firebase API Key, Firebase Project ID, Firebase App ID, storage bucket, sender ID, and other associated parameters.
While analyzing the native library, we found that the WebView URL (https://taxi.ru) is stored in plaintext within the ‘.rodata’ section, unlike other strings, which are obfuscated.
In addition to the WebView URL, several other sensitive strings, including the bot ID and Worker key, were found hardcoded in plaintext within the ‘.rodata’ section.
The worker key 9bc096a5f4ec7ba133d743cbaf4b8a2e (stored in plaintext at offset 0x9950) serves a critical role in the malware’s operational structure:
Purpose:
Initially, the malware collects various device details, such as the model, OS version, phone number, and SIM-related information (including SIM count and SIM metadata like slot, operator, and associated number). In addition to this, it gathers sensitive data related to installed banking applications to identify which banks are used by the targeted victim.
The collected configuration is then passed to the function A12(), which issues an HTTP POST request to the endpoint /api/v1/sync/init, transmitting the profiling data in JSON format to the attacker-controlled server.
Upon receiving the intent “NOTIFICATION_RECEIVED”, the malware extracts the originating application’s package name, notification title, and message text. It also parses the notification content using a regex pattern to capture OTPs and other sensitive codes. This data is then transmitted to the attacker-controlled server via an HTTP POST request to the endpoint /api/v1/sync/notification.
Send SMS capability allows the application to silently dispatch SMS messages from a selected SIM slot, allowing the operator to transmit stolen data, such as OTPs and other sensitive SMS content, potentially facilitating 2FA bypass.
Similarly, the malware collects all SMS messages and transmits them to the attacker controlled server via an HTTP POST request to the endpoint /api/v1/sync/backup/messages. The exfiltrated data includes message ID, sender/recipient address, body, timestamp, message type (incoming/outgoing), read status, subscription ID, and a client identifier used to profile the victim.
The application requests to be set as the device’s default SMS app through the official system prompt. If granted, it obtains full control over SMS functionality, enabling it to read incoming messages, send SMS, access OTPs, suppress notifications, and silently delete messages. In a malicious context, this allows interception of verification codes and covert messaging activity without the user’s awareness.
The malware collects the victim’s contact list, including names and phone numbers, and exfiltrates this data to the attacker controlled server via an HTTP POST request to the endpoint /api/v1/sync/backup/contacts. This enables mapping of the victim’s personal network and facilitates further social engineering activities.
Similarly, the malware collects the device’s call history and transmits it to the attacker controlled server via an HTTP POST request to the endpoint /api/v1/sync/backup/calls.
The malware also captures clipboard contents and exfiltrates the data to the attacker controlled server via an HTTP POST request to the endpoint /api/v1/sync/backup/clipboard.
The malware collects comprehensive information about applications installed on the victim’s device, including app name, package name, version, category, whether it is a banking app, and whether it is a system app. This data is compiled into a JSON object and transmitted to the attacker controlled server via an HTTP POST request to the endpoint /api/v1/sync/backup/apps.
It explicitly classifies apps to determine if they belong to banking, marketplace, government, or cryptocurrency categories.
The malware maintains a list of application package names categorized into a HashSet to identify app types, such as government, cryptocurrency, marketplace, or banking. These package names are stored as encrypted strings and are decrypted at runtime using a custom XOR based routine implemented in the function INJG_.A213().
List of encrypted package names
Function A213() revealed that it applies a custom XOR key: {58, 127, -78, 29, -23, 84, -56, 107}.
By reversing the routine, we successfully decoded the obfuscated strings. So far, we have analyzed two of them, and both resolved to package names of Russian banking applications.
String Decryptor
Similarly, we decoded all the obfuscated strings and obtained the following list of application package names.
The malware implements remote access using WebSockets to provide VNC-like functionality for real-time screen streaming. This is achieved through a combination of the Accessibility service and MediaProjection APIs, allowing full control and observation of the device.
The malware is capable of capturing the device’s lock PIN when the user interacts with the system lock screen or any vendor specific keyguard. It first confirms that the foreground interface belongs to a recognized lock screen package, then monitors user input to intercept the PIN as it is entered. The stolen credentials are quietly saved in local SharedPreferences using keys like lock_password and last_captured_pin, along with their corresponding timestamps.
This routine format captured keystroke data into a structured JSON payload containing the source application, logged text, event type, and timestamp. The prepared data is then forwarded to the attacker controlled server, enabling monitoring of user input across applications.
When a Firebase push message labeled “command” is received, the malware extracts the cmd value and accompanying data, wraps them into a PUSH_COMMAND broadcast, and sends it system wide. The app currently does not include any receiver for PUSH_COMMAND, suggesting it may be added later, but the Firebase implementation alone already makes the application highly persistent in the background.
Multi-layered persistence architecture combines boot auto-start, foreground services, accessibility abuse, scheduled alarms, push messaging, and user-activity triggers. Such redundancy ensures the malware remains active under nearly all conditions — reboot, network loss, device idle state, or user attempts to stop it — which is characteristic of advanced Android RAT families.
1. SMS Default Behavior:
When the app launches, it requests to become the default SMS app. Once granted, Android automatically permits most runtime permissions—like notifications, camera, file access, SMS, phone, and microphone—without further prompts. This allows the app to gain full control over SMS functionality, including reading, sending, and writing messages.
2. WebView Attempt:
The app tries to open a WebView pointing to https://taxi.ru, but the domain is unreachable.
3. Server Communication:
The application continuously attempts to connect to the server at IP address 193.233.112.229, but the server is also unresponsive.
The application under analysis demonstrates a highly targeted and region-specific threat posture, primarily impacting Russian users. The malware is purpose-built to exploit the banking ecosystem within Russia, with explicit targeting of financial institutions and other widely used Russian banking applications. Its architecture, permissions, and operational logic indicate a deliberate design choice to maximize effectiveness against this demographic while minimizing accidental exposure in other regions.
Geographic Targeting and Distribution:
Threat Actor Motivation and Capabilities:
| S.N | Tactic | Technique |
| 1. | Initial Access (TA0027) | T1660: Phishing |
| 2. | Persistence (TA0028) | T1541: Foreground Persistence T1603: Scheduled Task/Job |
| 3. | Privilege Escalation (TA0029) | T1626.001: Device Administrator Permissions () |
| 4. | Défense Evasion (TA0030) | T1628: Hide Artifacts T1628.002: User Evasion T1629.001: Prevent Application Removal T1516: Input Injection |
| 5. | Credential Access (TA0031) | T1414: Clipboard Data T1417.001: Keylogging |
| 6. | Discovery (TA0032) | T1420: File and Directory Discovery T1430: Location Tracking T1418: Software Discovery T1426: System Information Discovery T1422: Internet Connection Discovery |
| 7. | Collection (TA0035) | T1414: Clipboard Data T1636.001: Calendar Entries T1636.002: Call Log T1636.003: Contact List T1417: Input Capture T1636.004: SMS Messages T1513: Screen Capture T1512: Video Capture |
| 8. | Command and Control (TA0037) | T1437: Application Layer Protocol T1437.001: Web Protocols T1521: Encrypted Channel T1521.003: SSL Pinning T1481: Web Services |
| 9. | Exfiltration (TA0036) | T1646: Exfiltration Over C2 Channel |
| S. N | indicators | type | context |
| 1. | 67d5d8283346f850eb560f10424ea5a9ccdca5e6769fbbbf659a3e308987cafd | APK | RuTaxi APK (ru.y34tuy.t8595) |
| 2. | 193.233.112[.]229 | URL | C2-exfiltration |
| 3. | 9bc096a5f4ec7ba133d743cbaf4b8a2e | String | Worker Key / Campaign ID |
| 4. | 3A 7F B2 1D E9 54 C8 6B | hexadecimal byte array | Firebase XOR Key (8 bytes) |
| 5. | B2 1F CC E3 6A 7E 71 F4 0A C0 1D 78 7B 4B 1B 15 2A 2F 24 20 33 1C | hexadecimal byte array | C2 XOR Key (22 bytes) |
The analyzed Android malware represents a highly sophisticated and region-specific threat, primarily targeting Russian financial institutions and their customers, with the potential to spread to other regions. Its architecture demonstrates a combination of advanced evasion techniques, multi-layered persistence, and comprehensive data exfiltration capabilities. By leveraging native libraries, custom XOR-based obfuscation, and Firebase-backed command infrastructure, the malware can conceal its operations, maintain long-term persistence, and evade traditional detection mechanisms.
The malware’s functionality—ranging from SMS interception, notification, and clipboard harvesting, keylogging, to full VNC-style remote access—underscores its financial motivation and the risk posed to end-users. Additionally, its deliberate targeting of Russian banking applications, campaign-specific worker keys, and localized distribution channels reveal a strategically focused threat actor.
From a defensive standpoint, this threat emphasizes the importance of:
Overall, this malware demonstrates the evolving sophistication of Android banking RATs, highlighting the need for proactive monitoring, incident response preparedness, and region-specific security measures to mitigate risks to users and financial infrastructures.
rule TaxiSpy_Android_Banking_RAT
{
meta:
author = “Cyfirma_Research”
description = “Detects TaxiSpy Android Banking RAT targeting Russian users”
date = “2026-03-02”
platform = “Android”
hash = “67d5d8283346f850eb560f10424ea5a9ccdca5e6769fbbbf659a3e308987cafd”
strings:
$apk_package = “ru.y34tuy.t8595” ascii
$c2_ip = “193.233.112.229” ascii
$worker_key = “9bc096a5f4ec7ba133d743cbaf4b8a2e” ascii
$firebase_xor = { 3A 7F B2 1D E9 54 C8 6B }
$c2_xor = { B2 1F CC E3 6A 7E 71 F4 0A C0 1D 78 7B 4B 1B 15 2A 2F 24 20 33 1C }
condition:
uint32(0) == 0x504B0304 and // APK ZIP magic
any of ($apk_package, $c2_ip, $worker_key) or
any of ($firebase_xor, $c2_xor)
}
1. Threat Intelligence & Monitoring
2. Mobile Device Security & EDR
3. User Awareness & Education
4. Application & Network Hardening
5. Incident Response & Recovery
6. Collaboration & Reporting
