Dans une analyse publiée le 14 octobre 2026, ThreatFabric rapporte que Hirudo, un cheval de Troie bancaire pour Android, peut remplacer certaines applications bancaires par des copies modifiées qui manipulent leurs contrôles de sécurité internes. L’entreprise décrit huit remplacements dédiés à des applications indonésiennes, réparties entre sept banques, et recommande aux établissements de vérifier les signaux de sécurité côté serveur. ThreatFabric détaille son analyse de Hirudo.

Comment Hirudo remplace une application bancaire

ThreatFabric décrit d’abord des applications leurres qui proposent du contenu fonctionnel — boutique, catalogue vidéo ou courtes fictions — puis présentent Hirudo comme une mise à jour intégrée. Le cheval de Troie est une application distincte : il doit être installé séparément et obtenir ses propres autorisations.

Une fois présent, le RAT — un cheval de Troie d’accès à distance — repère certaines applications bancaires installées, notamment à l’aide des services d’accessibilité, puis affiche une fausse demande de mise à jour. Il ouvre la désinstallation de l’application bancaire authentique et télécharge en parallèle une copie adaptée à la banque visée.

Cette copie conserve le nom de package et le numéro de version de l’application d’origine, mais utilise une clé de test publique d’Android plutôt que la signature de la banque. Android ne peut donc pas l’installer par-dessus l’application légitime : celle-ci doit d’abord être supprimée, puis l’installation de la copie doit être autorisée. ThreatFabric indique que l’utilisateur peut interrompre ces étapes.

Les contrôles internes que la copie peut manipuler

Selon ThreatFabric, le code ajouté à l’application bancaire charge un moteur d’interception fondé sur YAHFA et Dobby. Il peut modifier les réponses de contrôles effectués dans l’application elle-même :

  • renvoyer le certificat de signature de l’application authentique et masquer la clé de test utilisée par la copie ;
  • faire apparaître une liste vide de services d’accessibilité actifs ;
  • retirer le drapeau FLAG_SECURE, qui limite la capture de l’écran ;
  • relayer les requêtes Google Play Integrity par HTTP non chiffré à un serveur contrôlé par les opérateurs, qui renvoie un verdict à l’application.

ThreatFabric rapporte aussi l’emploi d’une « keybox » publique divulguée pour les attestations et indique qu’au moins deux de ses certificats figurent sur la liste de révocation de Google comme compromis. Dans ce scénario, un verdict Play Integrity valide ne suffit pas, à lui seul, à établir qu’une application n’a pas été modifiée.

Des périmètres différents, du faux paiement aux données SMS

Les huit applications dotées d’un remplacement dédié concernent sept banques indonésiennes. Le registre financier analysé par ThreatFabric contient, lui, 42 applications : il s’agit d’un périmètre distinct. Les données de ciblage des identifiants citées dans le rapport nomment l’Indonésie, la Chine, l’Inde, le Mexique, le Maroc et la Thaïlande. Le faux écran de paiement intégré à un leurre comporte par ailleurs des marques de banques et de portefeuilles électroniques malaisiens.

ThreatFabric décrit ce faux paiement comme une page WebView transparente posée sur la page de commande du leurre. Un code PIN de paiement saisi dans ce formulaire est envoyé sous le nom appPayPwd, puis un faux résultat de réussite s’affiche. Le cheval de Troie peut aussi présenter de fausses invites de connexion bancaire, capturer le code secret de l’écran de verrouillage, transmettre l’écran en direct via WebRTC, ouvrir des sessions caméra et collecter des SMS. Le rapport mentionne un premier balayage portant sur les 90 jours précédents, avec une liste définie d’expéditeurs bancaires et de portefeuilles.

ThreatFabric rapporte que les APK leurres étaient distribués par Amazon CloudFront et que les campagnes utilisaient OpenInstall et des identifiants Meta Pixel pour l’attribution. L’entreprise décrit également un panneau de traitement d’APK accessible sans connexion, ainsi que des compartiments de stockage et des identifiants exposés. Des enregistrements capturés en août 2026 comprenaient des milliers d’entrées liées à des identifiants d’applications, des données d’appareils, un historique de verrouillage d’écran et des profils financiers comportant des champs de revenu mensuel et de score de risque.

Les défenses recommandées côté banque

ThreatFabric recommande de vérifier Play Integrity sur les serveurs de la banque et de lier chaque verdict à la session et à l’action protégée. Le rapport préconise aussi de contrôler la révocation des certificats d’attestation, d’ajouter de l’analyse comportementale et de conserver des contrôles de risque pour les opérations, notamment la récupération d’identifiants, l’ajout d’un bénéficiaire et la validation d’un paiement. Les signaux d’accessibilité ou de capture d’écran peuvent compléter ces contrôles, mais ne devraient pas constituer à eux seuls un motif de blocage.

ThreatFabric précise enfin que le VPN non fonctionnel associé au processus d’installation peut réduire les vérifications en ligne de Google Play Protect, tandis que la détection hors ligne des applications potentiellement dangereuses connues reste disponible. The Hacker News rapporte cette précision de ThreatFabric.