- Cyble reports that GhostBat RAT, an Android trojan, records payment PINs through an invisible layer over the real keypad in Google Pay and MobiKwik.
- Its keylogging feature covers 60 Android apps used for banking and payments in India, and operators can change its behavior after install.
- Fraud and security teams should ask whether their defenses depend on spotting fake pages, and what their apps do when accessibility services are active.
Many mobile fraud defenses are built around spotting a fake page: a cloned login screen or a look-alike app. A new Android trojan reported by Cyble does not need one. The customer uses the genuine app while the malware quietly watches the PIN go in. The lesson here is that a real interface does not, on its own, show that a session is safe.
What Cyble found
Cyble has tracked GhostBat RAT, which targets Android users in India, since October 2025. Its researchers were studying malicious apps that pose as India's mParivahan and eChallan government services. That work led them to a wider operation, which they call GhostX.
The attack starts with a text message containing a malicious link. The link leads to a page posing as the Parivahan service or a Google Play-style download page. Victims are urged to install a fake mParivahan app. Cyble also saw GitHub repositories and GitHub-hosted files used to spread the malicious apps.
The newest variant adds a keylogging feature aimed at 60 Android apps across Indian banking, UPI, wallet and payment services.
How the real-keypad trick works
The malware abuses Android's Accessibility Service. This feature exists to help users with disabilities. It lets an app watch the screen and tap on a user's behalf. Cyble says earlier GhostBat variants it analyzed did not abuse it. The newest one does.
Once the user grants that access, the malware checks which app is in the foreground. If it is a targeted app showing a PIN screen, it places an invisible layer over the keypad. Cyble calls this Ghost Overlay. Cyble names Google Pay and MobiKwik as targets.
The layer has 12 touch zones, laid out like a standard PIN pad. When the customer taps a digit, the invisible zone catches the touch and notes the key. The malware then lets go of that zone and repeats the same tap in the real app. The payment goes through normally. The PIN is recorded at the same time.
That is why this matters beyond Android specialists. The customer sees the real app. The real app gets the taps it expects and keeps working. Cyble contrasts this with conventional Android overlay attacks, which show a fake login or payment page.
A moving target by design
The malware can be changed after it is installed. Cyble says it uses Firebase Remote Config, a Google service for adjusting app settings. Operators use it to update the control servers and switch individual modules on or off. They can also manage the target list this way. That lets them turn on PIN capture only when a chosen app is open.
The delivery layer keeps changing as well. Across the samples it studied, Cyble found at least six different loader or dropper designs. A loader is the first-stage app that unpacks the real malware.
The newest keeps its payload encrypted in an app asset and uses a native library, libnetbridge.so, to unpack it through several layers of encryption and compression. No recognizable Android package appears until the end. Cyble concludes that detection built only on the outer app, a file name or one unpacking routine is unlikely to last.
A managed operation, not a single app
Cyble gained visibility into an exposed Firebase backend. It held administrator and user records with roles and account status. It also held admin login records with device fingerprints and timestamps, plus bot-user mappings. While Cyble watched, the SMS lure text, phishing links, vehicle registration numbers and recipient numbers kept changing. Cyble reads this as active campaign management.
The separate user, administrator and bot-user roles raise the possibility of a malware-as-a-service model. That is the researchers' assessment, not a confirmed finding.
What leaders should ask
Cyble's report does not say how many devices are infected. So this is not a measure of scale. It is a measure of method, and the method changes where defenders should look.
Banks, UPI providers and wallet operators should put three questions to their fraud teams. Can we detect a session where an accessibility service is active over our PIN screen? Do our fraud rules depend on spotting fake pages, which this method does not show? How fast can we learn that a customer's device is under remote control?
Employers with staff who use personal phones for payments or work should look at policy and training. The chain starts with a text about a vehicle fine and a request to install an app from outside the official store. That install is the first gate, not the only one.
PIN capture needs accessibility access. But Cyble also lists SMS interception, remote SMS sending and call-forwarding manipulation among the malware's capabilities. It describes these separately from the accessibility-based PIN theft. So training should cover the install step, and also the permissions a new app asks for afterward.
Checking that a page is genuine is a sensible habit. This case suggests it is not enough: a genuine page can still sit under someone else's hands.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cyble.
