Skip to content
Qubitron Security

4 min readQubitron Labs security team

Repackaged apps in 2026: why a passing integrity check isn't proof

A new trojan swaps real banking apps for patched copies and relays Play Integrity. What 2026's mobile threats mean for app teams, including India's new RBI app rules.

  • Mobile security
  • Android
  • India

Most mobile teams treat Google's Play Integrity verdict or an app signature check as the answer to "is this really our app?". A trojan documented this month shows why that answer is no longer enough on its own.

Hirudo: replace the app, keep the verdict

ThreatFabric's report on Hirudo, published on 14 October 2026, describes a remote-access trojan that doesn't bother drawing fake login screens over a banking app. It removes the genuine app and installs a patched copy with the bank's own security checks disabled from the inside. Hooks hide the test-key signature, and Play Integrity requests are relayed through a server the attacker controls.

ThreatFabric's conclusion is the line every mobile team should read: "a valid Integrity response alone is not evidence of an untampered app." So far the patched builds target eight apps from seven Indonesian banks.

Hirudo isn't alone. In April 2026, ESET found a new NGate variant hidden inside a maliciously patched copy of a legitimate NFC payment app, HandyPay, aimed at users in Brazil. ESET says the patched version was never on Google Play, and that the added code appears to have been AI-generated, though it has no definitive proof.

The scale behind it

  • Kaspersky counted 93,574 mobile banking trojan installation packages in Q2 2026, out of more than 304,000 malicious packages. In one case a trojanized PDF reader on Google Play dropped the Anatsa banking trojan.
  • In India, a cybercrime unit linked to the Ministry of Home Affairs warned in August 2026 about fake apps pushed through social media ads and sideloaded as APKs, which then abuse Accessibility permissions to make UPI and bank transactions, as reported by The Pioneer.

Secrets still ship inside apps

A repackaged app is also a readable app. Vendor and academic scans keep finding credentials in builds:

  • Quokka's 2026 report, covering more than 150,000 apps, found hardcoded cryptographic keys in 47.8% of Android apps and 17.6% of iOS apps, and hardcoded Google API keys in 39.5% of apps.
  • CloudSEK found 32 hardcoded Google API keys across 22 popular Android apps that could reach Gemini endpoints.
  • A Wake Forest study of 444 iOS apps with built-in AI features found 282 exposing exploitable LLM API credentials in their network traffic.

These are samples, not whole app stores, but the pattern holds across all of them.

What the platforms changed

  • Developer verification. Since 30 September 2026, Google's developer verification protections apply to installs on certified Android devices in Brazil, Indonesia, Singapore and Thailand, with a global rollout planned for 2027. India isn't in the first phase.
  • Play Integrity. Google added remediation prompts and app-access and device-recall signals, and says apps using Play Integrity features see 80% lower unauthorized usage on average. That is Google's own figure, and Hirudo shows a relay can still produce a valid verdict.

India: RBI now requires device binding

The RBI's Commercial Banks Digital Payment Security Controls Directions, 2026, dated 31 July 2026, say "the bank shall ensure device binding of the mobile application" and require older app versions to be deactivated in a phased but time-bound manner. On rooted-device detection, banks only "may explore the feasibility". For any team building payment features for Indian banks, device binding is now a requirement, not a nice-to-have.

What app teams should do

  • Verify integrity on the server. Treat the integrity verdict as one signal on your backend, combined with device binding and behaviour, never as a client-side yes or no.
  • Bind sessions to devices and re-check on sensitive actions, not only at login.
  • Enforce a minimum app version from the server, so patched old builds stop working.
  • Ship no secrets. Anything in the APK or IPA is public. Proxy third-party APIs through your backend with per-user limits.
  • Detect and respond to tampering in layers, with a response decided in advance: refuse, degrade or flag.
  • Test against a repackaged build of your own app. If a patched copy of your app still passes your checks, so will an attacker's.

That last test is part of every mobile app security test we run, on real devices, for Android and iOS.

Sources

Keep reading

All posts

Next step

Find out what your app gives away. Book a free exposure call.

Thirty minutes with an engineer, not a sales deck. Tell us what you ship; we tell you what we'd look at first and what an audit would involve.

Book a free exposure callRequest an audit

We only test applications you own or are explicitly authorized to test.