Inside "MR ROBOT" - Anatomy of a Malware-as-a-Service Operation Targeting Indian Bank Customers

Executive Summary

MR ROBOT is a previously unreported Android Malware-as-a-Service (MaaS) operation targeting customers of Indian banks. It is not a single-actor campaign but a rented crimeware platform: a master operator leases access to affiliates, who use a Telegram bot ("APK Shield") and a web control panel (v7.0) to build personalized banking trojans on demand and distribute them through fake Play-Store-style pages and messaging-app lures.

The kit impersonates banks, utility providers, and government services. Its ~36-app catalog spans public- and private-sector banks, gas/water/electricity billers, telecom recharge, and RTO traffic-fine scams.

Once sideloaded, a lightweight dropper (com.apkshield.installer.*) decrypts an AES-encrypted second stage into an inner trojan. The trojan intercepts SMS/OTPs, silently enables *21# call forwarding to defeat phone-based 2FA, and overlays phishing screens to harvest card, PIN, UPI, and identity data. Stolen data goes to a Firebase Realtime Database C2 and a Telegram channel, and surfaces in the operator panel for real-time fraud.

Key findings

• A product, not a one-off: an on-demand APK builder, a tiered sub-admin/affiliate reseller model, subscription licensing (per-affiliate App IDs with expiry), and an actively versioned panel (v7.0).
• Discovered from the operator's own tooling: the admin-console app and the panel's public web assets revealed the backend design, the Telegram bot, and the origin-hiding infrastructure from public artifacts alone.
• One C2 per affiliate, not per lure: lures for two different banks embed a byte-identical Firebase configuration. An affiliate's whole catalog drains into a single project, making Firebase takedown a high-leverage disruption point.
• Detection evasion by design: per-build throwaway signing certificates (certificate-hash blocklisting is futile), emulator checks, a 48-hour/3-launch dormancy gate, no launcher icon, and a local-VPN black-hole.
• Known cluster, new infrastructure: MR ROBOT shares tradecraft with Zimperium's FatBoyPanel and RedWing (notably *21# call forwarding and per-customer builders), but its kit, panel, storefront, and licensing scheme are publicly undocumented.

Scale: the platform is multi-tenant

• Affiliate A, the tenant we tracked, showed ~154 enrolled devices and ~3,270 intercepted messages in its panel. Its current Firebase exfiltration sink held just one device at analysis, consistent with a freshly rotated or purged backend.
• Affiliate B, a separate tenant with an exposed database, shows what a mature tenant looks like: 153 devices, 5,407 intercepted SMS (~400/day at peak), and *21# call forwarding active on 58% of victims, harvesting OTPs from more than a dozen banks and payments banks.

Technical Analysis

How we got here

The investigation began with a single malicious APK impersonating a public-sector bank, distributed under an "Aadhaar update" lure. The theme plays on India's mandatory KYC re-verification notices. Static analysis showed a multi-stage dropper: an outer "installer" app decrypts and side-loads a second-stage payload, which re-signs and installs the actual banking trojan.

The payload's capabilities read like a checklist for defeating SMS- and call-based bank security:

• SMS/OTP interception: a high-priority broadcast receiver captures incoming texts and exfiltrates them.
• Outbound SMS and unconditional call forwarding via the carrier code *21*<number>#, which silently reroutes incoming calls (including bank fraud-check callbacks) to a mule number.
• HTML phishing overlays that harvest Aadhaar, PAN, card number and CVV, ATM PIN, UPI, and net-banking credentials.
• No launcher icon, so the app disappears after install.
• Exfiltration to Firebase Realtime Database endpoints, with Telegram as a second channel.

None of that is novel on its own. What made this case different was the next artifact.

The tell: an operator's admin console

Alongside the victim dropper we recovered a second APK, internally labelled MR_ROBOT.apk (app_name = "MR ROBOT"). On a permissions-only triage it looks harmless: package com.godz.myapplication (a stock Android Studio default), only INTERNET and ACCESS_NETWORK_STATE, a normal launcher icon, and no hidden payload.

It is harmless to a victim because it is not meant for victims. It is the crew's own admin console, a thin WebView wrapper that opens the operator's web panel for a given affiliate App ID.

‍

Two details make it the Rosetta Stone of the investigation:

1. On first launch the app shows an "APP Verification — Enter your APP ID" dialog (hint: APP-XXXX-XXXX). This is a per-affiliate license gate: each customer who rents the kit gets an App ID. The recovered build hardcodes a real one, SKY-APP-2026-X9F3, matching the operator's crypto-key naming family (SKYROBOT2026…, X9F3MR2026…).
2. It is signed with a distinct self-signed certificate (CN=MrRobot, O=MrRobot, C=IN, keystore alias MRROBOT), separate from the victim dropper's signing chain. That gives defenders two independent certificate pivots for retro-hunting the operator's other builds.

Holding the operator's console rather than a victim's implant placed this sample on the panel side of the operation, and pointed us at the control infrastructure itself.

Mapping the panel from public assets

The console pointed at Cloudflare Pages hosts. The host hardcoded in the console is now offline; a sibling host is live, serving a single-page React/Vite app titled "MR ROBOT Dashboard — Remote device & SMS management panel."

A single-page app ships its own client code, and that code enumerates the backend functions it can call. The panel's public JavaScript bundle describes the full backend surface:

Function family

What it does

Master-admin authentication

PIN-based master login and session management

Tenant management

Affiliate/app management, usage stats, session and login limits

Live interception control

Toggles SMS interception for a specific victim device

On-demand builder

Starts, tracks, and serves personalized APK builds

Push commands

Sends commands to one device or all devices via Firebase Cloud Messaging

Provisioning and events

Token/VPS provisioning and a live event stream

‍

The UI strings alone describe the product: Devices, Online Devices, Last Seen, SIM Slot, Get SMS, Delete SMS, Call Forwarding / Disable Forwarding / Forward to number, Batch FCM Actions, Download Shoot APK, Generate Shoot URL, Change Login PIN, Create Sub-Admin App, Master Login Limit, Expired Only. Three things stand out.

• The builder has modes. Builds accept a fix_harmful, hidden, or visible mode. A customer enters an App ID and app name, and the backend compiles and re-signs a fresh, personalized trojan. Builds are served from an ephemeral Cloudflare Tunnel, which keeps the real backend server off the public record.
• There is an affiliate hierarchy. "Create Sub-Admin App", "Delete buttons hidden for sub-admins", and per-app login limits confirm a tiered reseller model: a master operator leasing sub-panels to lower-tier customers.
• The Telegram storefront is exposed. The bundle references a Telegram bot used to "Generate Shoot URL", minting victim-facing distribution links on demand. That bot is the operation's front counter.

The operating model

MR ROBOT runs as a self-service crimeware platform.

• Distribution: social-engineering lures (bank-branded "Aadhaar Update" apps) delivered via links minted by the Telegram bot, consistent with the WhatsApp/APK sideloading pattern seen across India-focused campaigns.
• Monetization: per-affiliate App-ID licensing with expiry ("Expired Only" filter, "Master Login Limit"), a subscription/lease model.
• Resilience: a static front end on Cloudflare Pages (cheap, disposable, CDN-fronted), the real backend behind a rotating Cloudflare Tunnel, and C2 data in Firebase, which the malware can re-point dynamically.

The Operation at Scale

The control panel is a running production system with a live victim base, not a proof of concept.

• A live licensing countdown ("Licence Active — 26 days remaining") confirms the subscription model at the top of the operator's console. When the clock expires, the affiliate's access is sealed until renewal.
• Affiliate A's panel held roughly 3,270 intercepted messages, ~154 enrolled devices, and several hundred credential-harvest records, with many devices recently online. Its live Firebase exfiltration sink showed only one device two days later, suggesting the operator rotated or purged the backend while the panel kept its own history.
• The victim fleet is Indian consumer Android: mainstream handsets on Android 13–16, with SIMs across the major Indian carriers.

Operational telemetry

The investigation drew on three data sources belonging to two affiliates.

The figures below come only from Affiliate B's exposed database. They illustrate platform scale and are not Affiliate A's numbers. Only aggregate statistics are reported; no victim-level data is published.

Victim base (Affiliate B)

Device fleet composition (budget Android dominates, matching the targeted demographic)

Handsets span eight brands, mostly budget-focused models, and SIMs span all four major Indian carriers.

Targeting by institution. Attributing intercepted SMS by sender short-code shows which banks this affiliate is harvesting.

About 4,000 of the 5,407 messages come from bank and telecom short-codes; the rest are person-to-person. Telecom recharge/OTP traffic dominates raw volume and provides the OTP relay for account-recovery flows.

A richer schema on Affiliate A. Affiliate A's single victim record goes beyond SMS: it includes gallery-image exfiltration, an installed-app inventory, battery/wake state, and the phishing-form harvest. The platform's data-collection model is actively evolving across builds.

A per-bank builder, not a single trojan. The panel's build screen lets the operator pick a target bank from a dropdown and compile a personalized "Shoot" APK. The selected target observed was a different bank from the one impersonated by the dropper that opened the investigation. One panel mass-produces trojans across multiple Indian banks, each impersonating that bank's own app. Intercepted SMS from small-finance, public-sector and private banks, plus wallet services, corroborates the breadth.

Play-Store-grade distribution. The "Generate Shoot URL" feature mints a fake Play-Store-style install page for each build, so victims can "install directly without searching." This is the delivery mechanism behind the Telegram/WhatsApp lures.

What the overlay steals. The phishing overlays capture a complete financial identity per victim: Aadhaar, PAN, card number, expiry and CVV, ATM PIN, UPI PIN, and net-banking credentials. A fake "verification fee" step confirms the card works.

Operator governance. The settings show a product built for resale: a configurable concurrent-login limit (default 20 devices), delete-protection passwords, master and sub-admin permission tiers, and a bulk "Delete All Messages" control to wipe evidence on demand. The fake-store feature is flagged "NEW IN v7.0", pointing to a maintained product with a release history.

The storefront: an "APK Shield" Telegram catalog

The Telegram bot presents itself as "APK Shield" and runs a self-service menu. It returns a catalog of ~36 ready-made lure apps, sold on a demo-then-paid model ("This is a demo version. Contact us for full paid access."). The catalog reveals targeting far beyond banking:

• Bank impersonations: nine public- and private-sector banks, including a dedicated ATM-PIN variant, card-limit-increase lures, and a generic all-bank credit card app.
• Utility-bill lures: city gas distributors, a municipal water board, electricity/meter updates, and a telecom operator.
• Government/RTO lures: several "RTO Challan" traffic-fine variants, including "billing page" versions that harvest name, PAN, date of birth, and mobile number behind a ₹9–10 "fee."
• Social-engineering props: fake "Customer Support," "Live chat," and "Credit card Apply" apps.

The "Aadhaar Update" dropper that opened this investigation corresponds directly to one bank's entries in this catalog. We were looking at one item on a menu.

A builder sample confirms the pipeline

A sample produced by the same builder for a second bank was analyzed. It is a textbook MR ROBOT dropper and matches the original sample's architecture:

• An outer installer package com.apkshield.installer.*, carrying the same "APK Shield" brand as the storefront, requesting REQUEST_INSTALL_PACKAGES and QUERY_ALL_PACKAGES and bundling a local-VPN service (ApkShieldVpnService).
• An AES-encrypted second-stage payload (~2.9 MB, entropy 8.0/8.0) in assets/, alongside a target_pkg.txt naming the randomized package the real trojan installs as.
• A throwaway signing certificate minted at build time (this build used a fake Indian company name and state as its subject). Every build carries a unique random identity, so certificate-hash blocklisting will not catch new builds.
• The fake-ZIP-encryption anti-analysis trick: archive entries flag themselves as encrypted but carry no real password, breaking naive unpackers while installing normally on-device.

The outer app is a pure dropper. On launch it decrypts (AES-128-CBC + GZIP, key hardcoded in an obfuscated loader class) a small bootstrap DEX, then decrypts the large second-stage blob into an inner base.apk and installs it under a randomized package name. Before doing so it runs anti-analysis gates: emulator checks (build fingerprint, model, hardware, carrier name) and a dormancy delay that waits for several launches and at least 48 hours, slipping past sandboxes that observe a sample for minutes.

The inner trojan requests exactly what SMS/call-based bank fraud needs: RECEIVE_SMS, READ_SMS, SEND_SMS, CALL_PHONE, MANAGE_OWN_CALLS, READ_PHONE_STATE, and RECEIVE_BOOT_COMPLETED for persistence.

One C2 per affiliate, not per lure

The inner trojans from two different lures, one bank's build and another bank's card demo, report to the same C2 backend. Both embed a byte-for-byte identical Firebase configuration (listed in the IOCs below), the same project seen in the original dropper.

The C2 is bound to the affiliate, not the lure. One operator's entire catalog, across every bank it impersonates, funnels stolen SMS and credentials into a single Firebase project, while only the app name, icon, target package, and overlay change per build. Disabling one Firebase project severs an affiliate's whole product line at once, a high-value, low-collateral disruption point.

Kill Chain and TTPs

The operation maps onto a seven-stage kill chain, from the affiliate's build request through to cash-out.

MITRE ATT&CK for Mobile mapping

Where MR ROBOT Fits: A Known Cluster, New Infrastructure

MR ROBOT is the latest entry in a well-documented lineage of India-focused mobile banking MaaS.

• FatBoyPanel (Zimperium, Feb 2025): ~1,000 malicious apps impersonating Indian bank and government apps, 200+ exposed Firebase buckets, ~50,000 victims, and SMS forwarding to live numbers. MR ROBOT's exposed Firebase tenants replicate this pattern almost exactly.
• RedWing (Zimperium, Jul 2026): a commercial Android MaaS sold via Telegram, with a bot that builds and obfuscates the APK per customer, a referral/discount scheme, and the same hidden *21# call forwarding to defeat phone-based 2FA. The overlap with MR ROBOT is striking and raises an open question of shared lineage.

What appears new is MR ROBOT's specific kit and control plane: the "MR ROBOT" branding, the "APK Shield" Telegram storefront, the Cloudflare Pages panel, the com.godz.myapplication console, the com.apkshield.installer.* dropper family, and the SKY-APP-2026-* licensing scheme. As of publication, none appear in public threat-intelligence reporting.

Indicators of Compromise (IOCs)

All network indicators are defanged. A second Firebase tenant that still held exposed victim data at analysis is withheld here pending takedown.

Mitigations

For banks and financial institutions

• Treat SMS-OTP as compromised for any customer reporting missed calls or an unexpected "Aadhaar/KYC update" app install. *21# forwarding silently redirects incoming bank callbacks; advise customers to dial ##21# to cancel call forwarding.
• Migrate from SMS-OTP toward app-based or FIDO authentication where feasible.
• Monitor for the IOCs above and hunt installed packages matching the listed package names and certificates.

For end users

• Never install a bank or "Aadhaar update" APK from a link in SMS, WhatsApp, or Telegram. Banks do not distribute apps this way.
• Keep Google Play Protect enabled, and review which apps hold SMS and call permissions.

For the ecosystem

• The operation relies on abusable free infrastructure: Cloudflare Pages, Cloudflare Tunnel, Firebase, and Telegram. Coordinated abuse reporting to those providers, plus a CERT-In advisory, is the highest-leverage disruption path. Because an affiliate's whole catalog shares one Firebase project, disabling that project severs the entire product line at once.

References

• Zimperium — Mobile Indian Cyber Heist: FatBoyPanel And His Massive Data Breach (Feb 2025)
• Zimperium — RedWing: A Mobile Malware-as-a-Service Operation (Jul 2026)
• McAfee Labs — A New Android Banking Trojan Masquerades as Utility and Banking Apps in India