The RTO Challan Scam Is Still Alive — Despite Arrests, Victim Data Keeps Leaking

The Monero Pool — Alive and Mining

When I tried to interact with the malware's self-hosted Monero mining pool in my initial investigation, I got no response. I was sending standard stratum protocol messages — the kind used by Bitcoin mining pools. Monero pools use a different login method entirely. Once I corrected the protocol and sent the proper request format, the pool responded immediately.

What I confirmed:

The pool is on the Monero mainnet, synced to within two blocks of the live chain at the time of my test. It is fully operational. More significantly: it accepts all logins. Empty wallet addresses, random strings, test credentials — all receive valid mining jobs in response. This tells me the operator's wallet address is configured server-side. Every infected device mines to a single address that the operator controls, and that address is never exposed in the APK or the pool's login response.

The job IDs I observed were in the 25 million range — consistent with a pool that has been continuously assigning mining work since mid-2024. This pool has been running, uninterrupted, for approximately two years.

The APK That Wouldn't Die

In May 2026, I pulled an APK from a WhatsApp forward circulating in Indian group chats. The file was called something plausible — a traffic fine checker, the kind of thing the Indian government actually sends through official channels. Except it wasn't from the government. It was a carefully staged trap.

I spent the better part of a week reverse-engineering it. I documented the C2 infrastructure. I identified the data being exfiltrated. I watched the operator's victim database grow in real time.

Then other cases pulled my attention away. A zero-day engagement. A ransomware incident response. Real-time work with paying clients. The draft sat in my queue.

I opened it again this morning — June 11, 2026 — expecting to find dead servers and a closed chapter.

Everything is still live.

The databases still have public read access. The infected devices are still pinging. The financial records are still sitting in plaintext. Nobody took anything down.

This is that article.

The Last Encrypted File — Cracked

After Part 1 published, one file remained unbroken in my analysis: a 17KB encrypted blob buried in the miner APK's assets folder. I had tried AES decryption with every key derivation strategy I could think of. Nothing worked.

The breakthrough came from a native library I had initially overlooked — a 201KB ARM64 shared object buried in the same APK. At a specific offset inside that library, sitting in plaintext, was a 64-byte key.

The file wasn't AES-encrypted at all. It was XOR-encrypted with a repeating key — a simpler but equally effective obfuscation method when the key is hidden inside a compiled binary. Once decrypted, the blob produced a valid DEX file: a second-stage class loader using InMemoryDexClassLoader to load additional payloads directly into RAM without ever writing them to disk. This is a deliberate anti-forensics technique — nothing touches storage, so standard file-based detection doesn't trigger.

Inside that DEX was a second encryption key and references to additional encrypted payloads that get decrypted and loaded at runtime. The infection chain goes deeper than I initially documented. What I published in Part 1 was the surface.

What GhostBat Actually Does

The malware has been formally documented by researchers I respect. Seqrite Labs' Digvijay Mane published a thorough technical breakdown, and Cyble's CRIL team independently identified and named the same campaign.

I recommend reading both reports for the full technical picture. What I'm contributing here is the backend access and the operational continuity — the fact that months after public disclosure, the infrastructure is still running.

For readers unfamiliar with the technical side, here's how the infection chain works.

Stage 1 — The dropper. The APK the victim downloads contains a native library that is heavily obfuscated using OLLVM — a technique that makes automated analysis nearly useless. Buried inside the APK's asset folder is an 8MB encrypted payload. The dropper decrypts it at runtime and executes it. From the outside, the app looks like a simple form that takes your vehicle number and promises to check if you have outstanding challans.

Stage 2 — The RAT. The decrypted payload is a full Remote Access Trojan. It intercepts every SMS the victim receives, forwards them to the operator in real time, and establishes a persistent connection to Firebase as its command-and-control backbone. The UX deception is clever: the app shows a fake UPI PIN entry screen and a fake credit card form. When the victim enters their card details, the app "declines" the payment — a realistic enough error — and redirects them to a UPI flow. By that point, both their card details and their UPI PIN have been captured and transmitted. The victim thinks their card had a temporary issue. They have no idea they just handed over everything.

Stage 3 — The miner. Once the RAT is established, the malware downloads an architecture-specific build of XMRig — one of the most common open-source Monero mining tools — from a Cloudflare Worker acting as a CDN. The binary is AES-encrypted in transit, with the decryption key derived from the filename's SHA1 hash. Once deployed, it connects back to a self-hosted Monero mining pool running over TLS. The victim's phone battery starts draining. The device runs hot. They assume it's a software bug.

A separate analytics client — using Aptabase, a legitimate open-source product analytics SDK — tracks every infected device's app installs, wake-up events, battery levels, and thermal data. It's instrumentation built for developers who want to understand their user base. In this context, it's a surveillance layer over a criminal botnet.

Three Firebase Projects. Zero Authentication.

This is where my investigation diverges from what's been published before.

When I analyzed the malware's network traffic, I identified three distinct Firebase backend projects serving different operational purposes.

Project one: The RAT C2. This database tracks every infected device. At the time of my initial analysis in May, 107 devices were registered, each reporting battery status and online/offline heartbeat events. Thirty-two devices were active. Every SMS those 32 people received was being forwarded to this database in real time — bank OTPs, family messages, login codes, everything. The database requires no authentication to read. I accessed every record without any credentials.

Project two: The financial harvest. This is the one that kept me up at night. 127 UPI PINs, collected across the victim pool. Three records containing complete credit card details — card number, expiry date, CVV, and cardholder name, all in plaintext. Aadhaar numbers. PAN card details. Bank OTPs sorted by institution. Sitting in a Firebase Realtime Database with public read rules. Anyone who found this URL — not just me, not just law enforcement, anyone — could download every record in under two seconds.

I reported this to Firebase's abuse team. The database is still publicly readable today.

Project three: The command layer. A Firebase Cloud Messaging project used to push commands to infected devices. The operator can wake devices on demand, rotate the Telegram bot tokens used for exfiltration, and update C2 configuration across the entire botnet without ever redeploying the APK. This is how you maintain a RAT campaign with minimal operational overhead. The infected devices check in; you push instructions; they execute. The victims never see it happening.

Who Got Arrested, and Why It Wasn't Enough

In May 2026, the Ahmedabad Cyber Crime Branch announced the arrest of five individuals from Surat's Varachha area in connection with APK e-challan fraud totaling over ₹1 crore. The arrests were real, the charges were real, and the police work was legitimate.

But the person arrested in the role my investigation focused on — a 29-year-old man named Ghanshyam Baraiya from Hirabagh, Varachha — I don't think he is mastermind. He was the financial facilitator: the person whose bank accounts and credit cards were used to route stolen funds, reportedly to repay personal loans. He was a money mule with awareness of the fraud he was enabling, not the developer who built the malware or the operator who runs the servers.

Arresting the money mule is a necessary step. It is not a sufficient one. The person who wrote GhostBat, set up the Firebase projects, configured the mining pool, and is watching 32 devices' SMS feeds right now — that person was not arrested. Based on the forensic artifacts I extracted, that person is still operating.

An Operator Profile Built From Artifacts

I'm not going to publish the infrastructure details that would tip the operator off. But I will describe what I know about who built this, because law enforcement following the money trail from the arrested facilitators should be looking for someone who matches this profile.

The malware developer builds on Manjaro Linux. Their XMRig binaries are compiled from source using the Android NDK, which implies a level of technical competence above off-the-shelf script kiddie tools. The Cloudflare Workers account used for payload delivery uses the handle "botmaster512." Domains were registered through Name.com and GoDaddy and placed behind Cloudflare's DNS, a standard operational security measure that hides origin server IPs.

The system timezone in the build artifacts is set to Asia/Singapore — UTC+8. The Monero mining pool is self-hosted, running TLS on a non-standard port, with a self-signed certificate where the common name is simply "pool" and the country field is set to US. That certificate tells us the operator is not particularly careful about identity consistency in their infrastructure — a useful detail.

None of this is definitive. Timezone spoofing is trivial. But the totality of the artifacts — the build environment, the handle, the domain registrars, the infrastructure choices — paints a picture of a specific person with specific habits. That person is still building and operating malware today.

The Victims Are Real People

I'm not going to name anyone. But I want to be clear that the SMS logs and financial records in these databases aren't abstract data points. They represent real people in real situations.

One set of SMS logs belongs to a kirana shop owner in Bikaner who was running their credit ledger through Khatabook. Their messages are all there — supplier payments, customer balances, family remittances. Every SMS they received after installing this app is in a Firebase database with no password protecting it.

Another victim is an Airtel Payments Bank user whose linked account, UPI PIN, and Aadhaar-authenticated payment history are all in the financial harvest database. Their PhonePe and UCO Bank connections are enumerated in the records.

A third victim is a Gujarati-speaking Jio subscriber who received phishing messages from the same infrastructure — meaning the operator was using their infected device to propagate the campaign further.

These are not edge cases. These are the people this malware was designed to find: users in tier-2 and tier-3 cities who received a WhatsApp message that looked official, who trusted that something called an "RTO e-challan checker" was legitimate, and who are now unknowingly part of a botnet.

The Operator — What I Now Know

The cross-campaign analysis surfaced an email address — developer.gymkhana@gmail.com — found in samples from the most recent campaign, dated April 2026. This may connect to a software studio that could be operating as a spyware-as-a-service entity. I'm not drawing firm conclusions from a single email, but it's an investigative lead that law enforcement can pursue.

The fuller picture of who built this, assembled from artifacts across all six campaigns:

The handle botmaster512 appears on Cloudflare Workers infrastructure across multiple campaigns. The geographic indicators — particularly the connection to Hirabagh, Varachha, Surat, where the arrested financial facilitator lived — suggest the developer has roots in Gujarat. The system timezone in build artifacts is consistently set to Asia/Singapore (UTC+8). The operation has been continuously active since July 2024, making this at least a two-year criminal enterprise. Across all documented campaigns, the estimated victim count exceeds 7,400 individuals.

The operator's monetization model is dual-track: direct financial fraud through harvested UPI PINs and banking credentials, and passive income through Monero mining on infected devices. Both streams are still active.

One more thing worth noting: this operator responds to exposure. After Cyble CRIL published their report, the Telegram bots used for data exfiltration were rotated. After my first article, one of the campaign domains stopped resolving. But responding to exposure is not the same as stopping. They adapt and continue.

If You Downloaded This APK

If someone sent you an APK over WhatsApp related to RTO challans, traffic fines, or e-challan verification — especially if it asked for your UPI PIN or credit card details — do these things now:

1. Disconnect the device from the internet immediately. Turn off WiFi and mobile data.
2. Check your SMS inbox and sent folder for messages you don't recognize sending.
3. Check your bank statements and UPI transaction history for any unauthorized activity from the past 90 days.
4. Factory reset the device. Do not back up app data before resetting — the malware may persist through selective backups.
5. Change every banking password and UPI PIN from a different, clean device before reconnecting the affected phone.
6. File a complaint at cybercrime.gov.in or by calling the national cybercrime helpline at 1930.

Your bank's fraud team can reverse unauthorized UPI transactions if reported within a narrow window. Don't wait.

Where We Go From Here

I'm not done with this campaign. The operator is still running infrastructure, still collecting data, and — based on the device heartbeats I observed this morning — still has active victims. I have additional technical material that I haven't published here because publishing it would alert the operator before law enforcement can act on it.

I've passed the relevant details to the appropriate contacts. Whether anything moves is out of my hands.

What I can control is making the inaction visible. The data is still leaking. The devices are still compromised. The arrests that were announced didn't end anything — they removed one link in a chain that remains otherwise intact.

If you're a journalist covering cybercrime in India, a law enforcement contact with jurisdiction over this campaign, or a security researcher who has independently identified overlapping infrastructure, my contact details are on my Medium profile. I want to hear from you.

The servers are still up. The question is who's going to take them down.

This article is part of an ongoing investigation. Technical indicators will be shared with CERT-In, and relevant platform abuse teams as needed. Victim data referenced in this article has been anonymized. I do not publish specific infrastructure details that could compromise active law enforcement operations.