Investigation Report: Android/BankBot-YNRK Mobile Banking Trojan
This report covers the analysis and findings related to three Android application packages (APKs) assessed for malicious behavior. The objective of this assessment was to determine whether the samples exhibited any malicious functionality, assess their potential impact on mobile devices or user data, and identify indicators of compromise (IOCs) relevant to the client’s environment. Each sample was examined using static and dynamic analysis techniques. Detailed behavioral findings and technical indicators are provided in the subsequent sections of this report.
File Details:
1. File name: IdentitasKependudukanDigital.apk
File size: 23.88 MB (25039234 bytes)
SHA-256:
cb25b1664a856f0c3e71a318f3e35eef8b331e047acaf8c53320439c3c23ef7c
2. File Name: identitaskependudukandigital.apk
File size: 23.88 MB (25039234 bytes)
SHA256:19456fbe07ae3d5dc4a493bac27921b02fc75eaa02009a27ab1c6f52d0627423
3. File Name: identitaskependudukandigital.apk
File size: 23.88 MB (25039230 bytes)
SHA-256: a4126a8863d4ff43f4178119336fa25c0c092d56c46c633dc73e7fc00b4d0a07
All three APK samples were identified as variants of the same malware family, which we have designated as Android/BankBot-YNRK, based on similarities in code structure, package naming conventions, and command-and-control (C2) communication patterns. Static and dynamic analyses were conducted to identify shared components, variant-specific modifications, and behavioral characteristics.
The following sections describe the results of the code analysis, focusing on the core malicious functionalities, permissions, and embedded network indicators observed across the samples.
We examined the decompiled APKs to identify malicious logic, hard-coded strings, and reused code patterns characteristic of the malware family.
The malware specimen exhibits environment detection capabilities designed to determine whether it is operating within a virtualized or emulated environment. This functionality is typically used to evade dynamic analysis and hinder detection by automated sandbox systems.
During initialization, the code inspects device attributes such as manufacturer and model identifiers (e.g., Huawei, Honor, or emulator-specific strings) to assess whether it is running on a real device or within an emulator. Based on the detection result, the malware dynamically adds different “handler” or “checker” objects to a list (arrayList), which are subsequently stored in a static variable (f13205OOOO) for later use during runtime. This behavior is characteristic of anti-emulation techniques commonly employed to evade analysis in sandboxed or virtualized environments.
The O0oO() method performs manufacturer and ROM verification to determine whether the Android device belongs to the OPPO ecosystem. Specifically, it checks whether the device is manufactured by OPPO, branded as OPPO or Realme, or running an OPPO-based ROM such as ColorOS. This logic is typically used for environment profiling or device-specific behavior control within the malware’s execution flow:
The malware also includes logic to identify specific devices. It verifies whether the device is a Google Pixel or a Samsung device and checks if its model is included in a predefined list of recognized or supported models. This allows the malware to apply device-specific functionality or optimizations only on targeted devices while avoiding execution on unrecognized models:
The malware implements a device-specific detection mechanism using a hash map that associates known device models with their corresponding screen resolutions. The hash map, stored in a static variable (f192OOOO), includes a range of Android devices from multiple manufacturers such as Xiaomi (Redmi), Samsung, Vivo, Oppo/Realme, Nokia, and Infinix. Each entry maps a device model string to its display resolution, allowing the malware to identify the device at runtime and potentially tailor its behavior based on the device type. This approach is commonly used for device targeting or to evade execution on unrecognized or unsupported devices, ensuring that malicious functionality is executed only on specific models.
The method logDeviceInfo(String str) is used by the malware to collect and record detailed information about the infected device. It logs attributes such as the Android SDK version, OS release, brand, device name, build ID, hardware identifier, manufacturer, model, and product name. This data is captured through Android’s Build class and passed to a logging function (Logging.m73d) for storage or reporting. Such functionality constitutes device data logging, allowing the malware to profile the environment, tailor its behavior for specific devices, and potentially evade analysis on unrecognized or unsupported devices.
This malware has used “nmm-protect” to obfuscate the code, making analysis and reverse-engineering difficult:
The malware includes functionality to silence the infected device by muting various audio streams. Upon resuming its activity, the code retrieves the system’s AudioManager and sets the volume of multiple streams—including music, ringtone, and notifications—to zero. This effectively disables audible alerts on the device, preventing the user from noticing incoming calls, messages, or other notifications. Such behavior is often employed to avoid user detection, ensuring that the malware can execute its payload or other malicious routines without drawing attention.
The malware is capable of receiving an “OPEN_ACCESSIBILITY” command from its command-and-control (C2) server. Upon receiving this command, it programmatically redirects the user to the device’s Accessibility Settings, prompting them to enable the malware’s accessibility service. By leveraging this mechanism, the malware can gain elevated privileges, including the ability to automatically interact with the device interface, bypass certain permission restrictions, and perform actions without direct user input. This technique is commonly observed in Android malware that abuses accessibility features to escalate permissions and maintain persistence.
The malware targets Android versions up to ‘13’, where it can obtain the required permissions via accessibility services to perform its operations.
Starting with Android 14, Google introduced stricter restrictions on the use of accessibility services to enhance user privacy and security. One of the key changes is the prohibition of using accessibility features to automatically request or grant app permissions. Until Android 13, apps could bypass permission requests through accessibility features; however, with Android 14, this behavior is no longer possible, and users must grant permissions directly through the system interface.
The malware implements persistence on the infected device using Android’s JobScheduler service. Upon starting, it schedules a recurring job (JobHandlerService) with a minimum latency and backoff period of 30 seconds, requiring a network connection to execute. The job is marked as persisted, ensuring that it remains scheduled even after device reboots. This mechanism allows the malware to maintain continuous operation on the device, automatically restarting its service at regular intervals and ensuring that its malicious routines are executed consistently without user intervention.
The malware is capable of receiving a wide range of commands from its C2 (command-and-control) server, enabling comprehensive remote control over the infected device. These commands allow the malware to perform operations such as:
By leveraging these commands, the malware can dynamically control the device, perform surveillance, manipulate the system interface, and maintain persistence, all under remote instruction from the attacker. This wide command set demonstrates the malware’s versatility and its focus on full device compromise.
The malware accesses and captures the Android device’s clipboard content, potentially extracting sensitive information. It may silently steal data such as passwords, cryptocurrency keys, or other personal information without the user’s knowledge or consent.
Upon receiving the “CALL_FORWARD” command, the malware can enable call forwarding on the device by constructing a command string that combines the prefix “21”, the provided input string, and a “#” character (e.g., 21*{str}#), which is the standard sequence for activating call forwarding. This allows the attacker to redirect incoming calls without the user’s knowledge or consent.
The malware attempts to gain device administrator privileges on the Android device by first checking whether the app is already an active administrator. If it is not, the malware starts an intent that prompts the user to grant these permissions. Obtaining device admin rights allows the malware to perform high-level actions on the device, including preventing uninstallation, controlling certain system settings, and enhancing persistence.
The malware continuously captures screen contents and extracts UI metadata—including view bounds, package identifiers, class names, view IDs, textual content, and accessibility descriptions—to reconstruct a structural representation of application screens such as banking apps. This reconstructed “skeleton UI” is then used to drive automated input and exfiltrate credentials. Potential consequences include credential compromise, fraudulent transactions, and persistent unauthorized access.
The malware functions as a controller for cryptocurrency wallets, programmatically opening the wallet app and interacting with its interface via Accessibility services. By automating UI actions and capturing on-screen content, it can extract sensitive information displayed in the wallet (e.g., seed phrases, private keys, or transaction confirmations) without the user’s consent. This capability enables unauthorized transactions, credential/key theft, and persistent fraudulent access to the victim’s crypto assets.
The Kotlin-based wallet automation controller leverages Android’s Accessibility permission to programmatically interact with cryptocurrency wallet apps (e.g., Exodus). It can open the wallet, navigate the UI, read on-screen content, and perform automated input actions.
An autoCloseBiometrics flag controls behavior around biometric prompts—when enabled, the controller will automatically dismiss or interact with biometric dialogs (it does not access raw fingerprint or face data). While it cannot extract biometric templates, the component can scrape any sensitive information rendered in the UI (balances, transaction details, seed phrases/private keys if displayed) and perform transactions or other actions as if a user were operating the device. In short, the component functions as a wallet bot that automates and scrapes wallet interfaces via Accessibility, enabling stealthy data theft and unauthorized transactions.
It targets multiple cryptocurrencies and associated wallets, including:
The malware has the capability to masquerade as Google News to deceive users and gain trust. When the GoAppLauncher activity is triggered, the code programmatically replaces the app’s identity — including name and icon — with Google News branding via an activity-alias configuration, effectively hiding the original application identity. It then loads the legitimate news.google.com site inside a WebView to reinforce the illusion that the user is interacting with the real Google News app. This identity-switching technique increases user confidence and reduces suspicion while the malicious app can continue unauthorized background activities.
Upon execution, the malware immediately suppresses audio and notification volumes by setting multiple streams—including music, ringtone, and notifications—to zero. This effectively disables audible alerts on the device, preventing the user from noticing incoming calls, messages, or other notifications.
It establishes communications with C2 at ping[.]ynrkone[.]top on port 8181 and sends the device identification string along with the application name that has infected the device:
Then it requests a list from the C2 of potential applications that it can target:
The C2 responds with the list of application names:
The response contains the following application names. All potential target applications are related to financial services, such as banks and money transfer services:
The next communication sequence sends details about the infected device, including time zone, accessibility status (whether the malware’s accessibility service is enabled), phone brand, and battery optimization status for the malware:
C2 responds with “operation successful”:
The malware also sends details of installed applications—including their names, package identifiers, and version information—from the infected device to the C2 server. The C2 acknowledges receipt with an “operation successful” response:
The C2 address https[:]//ping[.]ynrkone[.]top[:]8181 hosts a chat room through which all infected devices communicate. It functions as an automated handler, sending and receiving specific data to and from each infected device:
The malware is capable of connecting to the C2 at ping[.]ynrkone[.]top using the WebSocket protocol on port 8989 via the Janus WebRTC server, as indicated by its WebRTC session initialization routines; however, no such communication was observed during analysis:
These malware specimens also attempt to load content through a WebView from the following domains, but the domain names could not be resolved:
No additional C2 commands were received during the analysis of the malware. Possible reasons include the malware detecting the analysis environment and intentionally withholding its true capabilities, remaining in a dormant or sleep state while waiting for a potential target application to be installed, or requiring specific conditions or triggers to initiate communication.
Once the malware obtains Accessibility permissions, it launches a full-screen overlay displaying a message in Indonesian that impersonates a “Personal Information Verification” prompt. The overlay instructs the victim to wait, effectively deceiving them while the malware performs background activities.
During this process, the malware enables all required permissions in the background:
The malware also runs the services required for its operations, such as RemoteService, LocalService, JobHandlerService – using Accessibility privileges:
The malware also adds itself as a Device Administrator app:
Environmental awareness and evasion:
Persistence and self-protection:
Accessibility abuse:
Overlay and impersonation:
Audio and notification suppression:
Command-and-control (C2) communication:
Device and data manipulation:
Cryptocurrency theft and automation:
Screen and UI surveillance:
Command versatility:
The analyzed samples, collectively identified as Android/BankBot-YNRK, represent a highly capable Android banking trojan designed to achieve full remote control of infected devices. By abusing accessibility services, it gains elevated privileges to automate UI interactions, extract sensitive data, and perform unauthorized operations. The malware demonstrates strong persistence through JobScheduler-based tasks and device admin privileges, while employing stealth mechanisms such as audio suppression and deceptive overlays to evade user detection.
Its ability to masquerade as legitimate applications (e.g., Google News) further enhances user deception and trust. Communication with the C2 server enables it to receive a wide range of commands for data exfiltration, device manipulation, and cryptocurrency theft. Overall, Android/BankBot-YNRK exhibits a comprehensive feature set aimed at maintaining long-term access, stealing financial data, and executing fraudulent transactions on compromised Android devices.
| No. | Tactic | Technique |
| 1 | Persistence (TA0028) | T1603: Scheduled Task/Job |
| 2 | Privilege Escalation (TA0029) | T1401: Device Administrator Permissions |
| 3 | Defense Evasion (TA0030) | T1633: Virtualization / Sandbox Evasion |
| 4 | Execution (TA0041) | T1516: Input Injection |
| 5 | Collection (TA0035) | T1417.002: GUI Input Capture T1513: Screen Capture T1414: Clipboard Data T1412: Capture SMS Messages |
| 6 | Discovery (TA0032) | T1418: Software Discovery / Application Enumeration |
| 7 | Command and Control (TA0037) | T1437.001: Web Protocols |
| 8 | Exfiltration (TA0036) | T1646: Exfiltration Over C2 Channel |
| 9 | Impact (TA0034) | T1616: Call Control |
| Indicator | Type | Description |
| cb25b1664a856f0c3e71a318f3e35eef8b331e047acaf8c53320439c3c23ef7c | SHA-256 | APK |
| 19456fbe07ae3d5dc4a493bac27921b02fc75eaa02009a27ab1c6f52d0627423 | SHA-256 | APK |
| a4126a8863d4ff43f4178119336fa25c0c092d56c46c633dc73e7fc00b4d0a07 | SHA-256 | APK |
| Ping[.]ynrkone[.]top | Domain | C2 |
| Plp[.]foundzd[.]vip | Domain | C2 |
| Plp[.]e1in2[.]top | Domain | C2 |
| Plp[.]en1inei2[.]top | Domain | C2 |
User Awareness and Training:
Mobile Device Management (MDM) Controls:
Network and C2 Detection:
Application and System Hardening:
Malware Detection and Response:
Incident Response and Forensics:
