Inside BTMOB: An Analytical Breakdown of a Leaked Android RAT Ecosystem

During a recent investigation, we obtained access to a multi-package archive containing the complete development toolkit behind the Android malware known as BTMOB RAT. The archive includes the Android payload source code, its dropper, a builder environment, the operator panel for Windows, the command-and-control backend, and all the software dependencies required to deploy the full platform.

Every component is stored inside password-protected ZIP files. While ZIP file headers remain readable without a password, allowing us to inspect the file tree, their binary contents cannot be extracted. We intentionally chose not to acquire or circumvent the passwords, avoiding any action that may financially support or operationally benefit a criminal actor.

This analysis is therefore built entirely on directory structures, OSINT artefacts, C2 fingerprinting, public research, and behavioural evidence shared in open channels. Even without access to the binaries, the exposed architecture offers a rare, comprehensive look inside a commercial Android RAT platform as used and distributed by a threat actor and their paying customers.

BTMOB appears to be an evolution of SpySolr, itself derived from the Crax RAT lineage. It has been actively marketed inside closed Telegram communities, distributed through phishing websites masquerading as legitimate streaming or financial services, and continually updated with new overlay, injection and remote-control capabilities. The leak analysed in this report provides the first opportunity to examine the internal organisation of this ecosystem.

Structure of the Leak and Methodology

The archive contains seven main components: the Android APK source, the dropper, the builder toolkit, the Windows operator console, the full C2 web server, an installation guide, and the complete set of software dependencies. Each component is organised in a separate ZIP file, accompanied by a shortcut referencing the password.

Without the ability to extract the content, the analysis relies on identifying the technologies, development frameworks and operational workflows implied by the directory structures. This approach has proven sufficient to reconstruct the full architecture of the BTMOB platform and the relationships between its components.

APK.zip – The Full Android Payload Source Code

The structure of APK.zip immediately reveals the presence of a full Android Studio project. The directory includes .idea/, Gradle scripts, Java/Kotlin source files under app/src/main/java, resource folders under app/src/main/res, custom modules such as materiallockview/, and configuration files including AndroidManifest.xml.

These indicators confirm that the leak contains the original developer source code, not a decompiled APK. Names of classes and resources expose the internal design of the RAT: WebView-based injection pages, accessibility service handlers, remote-screen modules, lockscreen pattern components, and configuration assets such as network_security.xml, pfs1.xml, splits0.xml, and multiple layout files related to fake activities and device-manipulation UIs.

This source tree aligns precisely with public analyses describing BTMOB’s behaviour. The RAT makes extensive use of the Android Accessibility Service to bypass protections, take control of UI interactions, intercept input, simulate gestures, and extract credentials through overlays and injected HTML pages.

Dropper.zip – The Initial Delivery Stage

The presence of multiple APKs inside Dropper.zip shows the structure of the first-stage application used to deliver the malicious payload. One APK serves as the decoy application—often themed as a streaming service, banking tool or productivity app—while another APK is stored within the assets as the “update”.

Once installed, the dropper displays an update screen and uses Accessibility permissions to silently install the second-stage payload. This confirms the infection chain reported by prior research, where the user is lured into enabling Accessibility, after which the malware grants itself additional permissions automatically.

The dropper therefore acts as the visible entry point for the victim, while concealing the malicious payload embedded within.

Builder.zip – A Controlled Compilation Environment

Builder.zip contains a collection of well-known tools used in APK manipulation: apktool.jar, APKEditor.jar, signapk.jar, auxiliary JARs and platform-specific scripts. In a traditional malware kit, such a collection would allow an attacker to modify and rebuild the payload fully on their own.

However, the BTMOB ecosystem does not function this way. Evidence from the server-side HTML pages confirms that the actual build process occurs remotely on the threat actor’s infrastructure. The local builder appears to exist primarily as a configuration interface, while the real compilation—where the C2 address, licence, and operator identifier are embedded—happens on the TA-controlled server.

A commented HTML fragment found within the C2 package reveals how passwords, builder updates and download links are provided to paying customers:

<!--
<div class="builder-msg-box">
    <p class="builder-msg-text">
        The builder problems have been solved. If you still have issues, please update to the latest version
        and try again.
    </p>
    <div class="builder-password-container">
        <input type="text" readonly id="builder-password-input" value="mySecureFile123" />
        <button class="builder-copy-btn">Copy</button>
    </div>
</div>
-->

Another block exposes a hosted RAR archive for a newer version of BTMOB:

<input id="manuallink" type="text"
       value="https://www.mediafire.com/file/NO_DISCLOSURE/BTMOB+v3.6.rar/file" readonly>
<span class="hint">Extract Password: <b>T.ME/NO_DISCLOSURE</b></span>

These snippets demonstrate that the threat actor distributes new releases through external file-hosting services, embedding download infrastructure directly into the C2 panel.

BTMOB 3.6.3.zip – The Operator Panel for Windows

This part of the leak contains the Windows-based operator console, BTMob.exe, together with its libraries and UI resources. On execution, the panel prompts for an email, password and a “token”. The token is obtained from the C2 web interface hosted under the /yaarsa/user/ path.

This mechanism acts as the entry point for the criminal operators who have purchased access to the platform. BTMob.exe is effectively a graphical shell around the C2 APIs and WebSocket channels: it displays infected devices, allows remote interaction, and executes commands within the infrastructure managed by the threat actor.

Since all authentication is performed against the same backend server used by the malware, customers depend entirely on the threat actor’s centralised licensing infrastructure. Nothing in the panel suggests the existence of an alternative self-hosted operational model.

Web Server.zip – Internal Structure of the C2 Backend

The C2 implementation resides under a directory named yaarsa, divided into user/, private/ and private/updates/. The user/ area contains the scripts handling operator login, token generation and 2FA validation. The private/ area contains dozens of PHP files named with identifiers such as yarsap_80541.php, yarsap_23981.php, and similar patterns.

These endpoints correspond to the command and telemetry channels used both by the malware and the operator panel. Queries executed without the proper parameters return the uniform error:

{"Fail":"\"Invalid request.\""}

Yet the directory naming, script volume and cross-references found in public samples confirm these endpoints as command handlers for remote control, injection, keylogging, file management, screen streaming, and general RAT operations. The malware contacts them via HTTP and activates a WebSocket channel for real-time coordination.

A dedicated updates/ section contains notes, file links and internal release comments. These pages expose maintenance notes and passwords that are intended to be seen only by paying customers, making their presence inside the leak particularly revealing.

Operator Authentication and Centralized Control

The leaked material reveals that BTMOB’s operator authentication model is fully centralized. Criminal buyers do not authenticate locally nor through infrastructure they control. Instead, they must obtain a session token directly from the developer’s backend by providing their credentials and two-factor authentication. Only after receiving this token can operators unlock the Windows control panel and access the devices they have compromised.

This architecture has a critical consequence: the developer retains absolute authority over the entire ecosystem. Since all authentication flows through a server controlled by the threat actor (TA), the TA can generate valid tokens for any operator account at any time. This grants the developer unrestricted access to every victim managed by every customer, effectively allowing them to impersonate any operator unnoticed.

Rather than distributing an autonomous malware kit, BTMOB operates as a centralized criminal platform. Customers function more like renters inside the TA’s infrastructure, and all compromised devices ultimately remain under the developer’s control. This design ensures the TA’s supremacy within the ecosystem and provides them with silent, continuous visibility over the operations of all their buyers.

The Active C2 Server – Observed Fingerprints

Through OSINT-based network reconnaissance, an active BTMOB C2 host was identified that matches the structure of the leaked web server. The exposed services offer a clear fingerprint:

• Apache 2.4.52 on Windows with PHP 8.1.2 available on ports 80 and 443,
• MariaDB exposed internally on port 3306,
• a Node.js Express component listening on port 3000,
• a WebSocket-capable service on port 8080,
• Remote Desktop Protocol visibly active on port 3389,
• multiple RPC ports opened, consistent with a Windows desktop/server configuration.

The banners reveal the machine’s hostname and certificate information, strongly suggesting that the C2 is operated on a Windows workstation or a lightly hardened server environment.

This observation confirms that the threat actor uses a centralised server for all customers. The RAT, the operator panel and the builder infrastructure all depend on a shared backend, giving the TA unilateral visibility over every infected device belonging to every paying operator.

The result is an architecture where the threat actor retains complete strategic control. With access to the same login mechanism used by their customers, the TA could impersonate any operator, observe or hijack their victims, revoke licences, or alter collected data. The structure is not that of a malware kit sold to be deployed independently, but rather a criminal Software-as-a-Service platform.

BTMOB RAT Capabilities – A Technical Overview

Public research on BTMOB, including analyses by Cyble and Zimperium, describes a malware family defined by its comprehensive abuse of Android’s Accessibility Service. Once enabled, the RAT acts as a full automation framework for the device.

It establishes a WebSocket connection to the C2, identifies itself using device ID and bot ID, and receives a continuous series of commands. These commands include configuration updates, screen-sharing instructions, WebView-based injection flows, lockscreen manipulation, input injection, and file operations.

The “brows” command is particularly powerful, allowing the C2 to load any URL or dynamically injected HTML into an invisible WebView and drive JavaScript-based harvesting of form inputs. Additional parameters direct the malware to scroll, click, enter text or navigate, effectively enabling a remote phishing automation engine.

The “screen” command triggers screen-capture sessions using Android’s MediaProjection API, including the ability to unlock the device by replaying pattern gestures or entering saved PINs and passwords. All input can be simulated with gesture injection.

The “ject” command handles the installation and execution of HTML phishing overlays. These overlays are stored encrypted inside the app, extracted into designated directories, and launched when the target application is detected in the foreground.

The “wrk” command extends the RAT’s capability to device-wide operations, such as collecting SMS messages, contacts and location, browsing files, altering audio settings, launching activities or executing shell-level actions.

The malware also handles data upload using a compact JSON structure, storing interim results in shared preferences before exfiltrating them back to the server.

The RAT’s feature set mirrors what was historically seen in high-end Android banking malware, but its general-purpose architecture makes it applicable to any target where interactive device control is beneficial.

Future Development – BTMOB v4

Announcements extracted from the threat actor’s Telegram channel indicate that version 4 of BTMOB is under development. Planned enhancements include refinements to the injection engine, extended performance for live screen sessions, expanded compatibility with financial applications, and improved bypasses to reduce user visibility during active remote-control sessions.

The TA’s communication style emphasises continuous updates, rapid bug-fixing, frequent feature rollouts and a marketplace-like relationship with their customers. The speed of iteration suggested by the channel, together with the internal changelogs included in the leak, confirms that the platform is undergoing active expansion and commercialisation.

Strategic Interpretation of the Leak

The BTMOB leak provides a rare perspective on the inner workings of a modern Android RAT-as-a-Service ecosystem. It demonstrates that the threat actor operates not merely as a developer selling a toolkit, but as a service provider enforcing licensing, authentication and version control over their customers.

This model gives the TA a structural advantage: total visibility, control and potential access to every infected device across all operator accounts. It also exposes criminal operators to the same risks they impose on their victims, as the TA can technically assume their identities inside the platform.

From a defensive standpoint, the leak supports attribution of infrastructure components, identification of C2 behavioural signatures, and the generation of stable IOC families such as the yaarsa/private/yarsap_*.php endpoints and WebSocket patterns. It also confirms that Accessibility abuse remains one of the most effective—and least mitigated—vectors for advanced Android spyware.

Conclusion

The BTMOB leak sheds light on a fully integrated criminal ecosystem, combining a modern Android RAT, a dropper mechanism, a remote builder pipeline, a Windows-based operator console, and a centralised C2 built in PHP and Node.js. Even without access to the binary contents, the directory structures and OSINT artefacts allow a complete reconstruction of the platform and its operational workflow.

BTMOB represents a mature form of mobile malware commercialisation, where attackers subscribe to a central platform rather than building their own. Its capabilities—ranging from live device control to credential extraction via overlay and injection—place it among the most versatile Android threats observed in 2024–2025.

The ongoing development of version 4 indicates that the threat actor remains active and continues to evolve the platform. Understanding the architecture revealed in this leak is therefore essential for detecting, analysing and disrupting similar ecosystems in the future.