A banking app can report that its security checks have passed. The harder question is whether your backend has enough independent evidence to believe it.
For banking security and fraud teams, Hirudo is a useful test of that distinction. The Android trojan shows why an application’s own account of its integrity cannot carry the whole weight of a payment decision.
What changes when the attacker replaces the app?
In research published on 14 October 2026, ThreatFabric describes Hirudo replacing legitimate banking apps with modified copies. Its replacement targets include eight Indonesian banking apps. The replacement is signed with a different key, so the original must be removed before the modified version can be installed; it is not a normal trusted update.
Inside the modified app, hooks alter what security checks see. They can return the genuine signing certificate to local queries, hide the malware’s accessibility service and remove screenshot protection. ThreatFabric also describes Play Integrity requests being relayed through attacker infrastructure and key-attestation manipulation using a leaked keybox, including revoked certificates.
The important architectural lesson is not that every integrity service has been broken. It is that an attacker controlling the app process can interfere with requests, responses and the code that interprets them. A reassuring result displayed or accepted locally is not independent proof.
Put verification where the attacker cannot rewrite it
A useful design review starts with three questions: who produces the evidence, who verifies it, and what exact action does it authorise?
For standard Play Integrity requests, Google describes a backend verification flow using a request hash. Relevant request details are bound to the token; the backend checks that they match the operation it is considering. Its verdict guidance also covers request details, freshness and the applicable integrity results.
Translate that into a transaction-level question: could evidence collected for one session or action be accepted for another? A token associated with opening the app should not become a general permission slip for changing a payee or approving a payment. Define which evidence each sensitive action requires, and make the acceptance decision on the server.
Key attestation needs the same discipline. Google’s verification guidance calls for validation on a trusted server, including the certificate chain, trusted roots and revocation status. Receiving a certificate chain is the beginning of the check.
Treat missing evidence as something to investigate
Fraud controls often focus on suspicious activity that arrives. They should also consider expected evidence that disappears.
Suppose a session continues to request payments but stops providing telemetry normally associated with that journey. That gap deserves attention. It could indicate tampering, a broken release, an accessibility issue or a network problem. The useful signal is the change in context, not an automatic conclusion that the customer is fraudulent.
Agree a proportionate response for each stage: login, account recovery, payee creation and payment approval. Options might include additional verification, a temporary hold or review. Record why the backend accepted or challenged the action so investigators can reconstruct the decision.
A practical exercise for your own banking app
Use an authorised test environment, accounts and an application your team owns. Keep the exercise focused on the evidence your controls receive.
- Establish a baseline. Record the server-side evidence and decisions for a genuine test build across the sensitive customer journeys.
- Introduce controlled changes. Have your authorised testing team assess a modified test build and deliberately missing, stale or mismatched integrity evidence.
- Follow the decision. Check whether the backend rejects, challenges or accepts each case. A warning inside the app is not enough if the server still approves the action.
- Test ordinary failures too. Understand what customers experience during telemetry or service outages, and ensure exceptions do not quietly remove the control.
- Give findings an owner. Record gaps, remediation and a repeatable check for future releases.
Keep app protection in the right role
Runtime application self-protection, tamper resistance and obfuscation can make attacks harder. OWASP treats resilience measures as additional protection shaped by the application’s threat model. They complement secure architecture rather than taking responsibility for every trust decision.
For a risk committee, the useful distinction is straightforward: explain which controls increase the attacker’s effort, which provide evidence, and which actually decide whether money can move.
Bring application evidence into the review
MobSTR’s application assessment helps teams examine code, dependencies, permissions and security findings. Use that evidence alongside your authorised testing and backend fraud controls to understand where trust decisions need strengthening.