Une vaste fraude touchant des services bancaires mobiles met en lumière la nécessité pour les banques d’adopter une sécurité des applications, une authentification modernisée et une analyse des risques

Cet article a été rédigé en collaboration avec Greg Hancell, directeur principal des services-conseils en fraude de OneSpan, et avec la rétroaction de Frederic Mennes – directeur de produit à OneSpan – et Will LaSala - directeur principal, Solutions mondiales.

À l’été 2020, le FBI a publié un avertissement au sujet d’une augmentation des activités malveillantes ciblant les vulnérabilités des services bancaires mobiles, dans un contexte où les activités bancaires sur le canal mobile affichaient une hausse fulgurante en raison de la COVID-19 et des mesures de confinement connexes. Cet avertissement s’est concrétisé à la fin de décembre, au moment où a été découverte une « ferme d’émulateurs malveillants » qui imitait les appareils mobiles des victimes pour dérober frauduleusement des millions de dollars à des titulaires de comptes aux États-Unis et en Europe.

Le présent article a pour but de sensibiliser les institutions financières au sujet de cette menace et d’expliquer l’approche « par niveaux » à utiliser pour atténuer ces fraudes de plus en plus sophistiquées.

Une fraude mobile d’ampleur et de vitesse inédites ciblant les services bancaires

Selon les chercheurs, l’ampleur et la rapidité de cette attaque malveillante la distinguent des cas précédents de fraude mobile. Les pirates ont mis sur pied un réseau d’environ 20 émulateurs imitant 16 000 appareils mobiles et ont fait appel à une automatisation qui a permis de retirer des millions de dollars dans les comptes bancaires en quelques jours seulement. Un émulateur mobile est un appareil mobile virtuel qui imite les fonctionnalités des appareils mobiles réels et copie l’interaction entre ces appareils et leurs utilisateurs. À l’origine, les émulateurs ont été conçus pour pouvoir tester automatiquement des logiciels sur une vaste gamme d’appareils.

Les gestes automatisés par les pirates comprenaient au moins ce qui suit : 

• Recueillir les attributs des appareils 
• Entrer des noms d’utilisateur et mots de passe 
• Déclencher des transactions 
• Recevoir et voler des codes d’autorisation uniques envoyés par SMS 
• Entrer ces codes SMS volés pour accomplir les transactions 

Recueillir les identifiants des appareils mobiles

Dans certains cas, les pirates imitaient les appareils existants de leurs victimes. Dans d’autres cas, les pirates se faisaient passer pour leurs victimes en faisant croire qu’elles utilisaient un nouvel appareil pour accéder à leur compte bancaire. Les chercheurs ne savent pas exactement comment les identifiants bancaires ont d’abord été compromis, mais il est plausible qu’ils aient été volés à l’aide de logiciels malveillants, recueillis au moyen d’attaques par hameçonnage, ou trouvés sur le Web clandestin. On ne se sait pas clairement comment les identifiants des appareils ont été obtenus, mais il apparaît logique que ces données aient été récupérées par des logiciels mobiles malveillants présents sur les appareils des victimes.

Que peuvent faire les institutions bancaires pour atténuer les menaces mobiles semblables?

Il n’existe pas de panacée en matière de sécurité bancaire mobile qui puisse éliminer cette menace mobile. La meilleure protection est une approche par niveaux, avec une défense « en profondeur », qui comprend, sans s’y limiter :

• Une authentification forte client 
• Une analyse des risques du côté client et du côté serveur pour prévenir les fraudes 
• Un blindage d’application mobile avec protection d’exécution 

Luttez contre la prise de contrôle des comptes en modernisant l’authentification

Le cabinet d’analyse des services financiers Aite Group a récemment recommandé, dans son rapport « Revisiting Your Authentication Control Framework » (en anglais seulement) « que les institutions financières, les entreprises de technologies financières et les marchands prennent du recul pour examiner leur cadre de mesures de contrôle d’authentification. Si le dernier examen de ce cadre remonte à quelques années, en raison des progrès technologiques réalisés pendant cette période, le cadre devra probablement être mis à jour. »

Le vol des noms d’utilisateur et mots de passe utilisés pour authentifier les utilisateurs et les paiements ouvre la voie à cette fraude mobile. Ces identifiants statiques, « à facteur unique », sont vulnérables à l’hameçonnage – s’ils n’ont pas déjà été compromis dans le cadre d’autres violations de sécurité ayant mené à une fuite de données. La mise en place d’une authentification multifacteurs ou d’une authentification à deux facteurs faisant appel à des codes d’authentification dynamiques uniques atténue considérablement les risques de prise de contrôle de comptes. En plus d’imiter les appareils existants des utilisateurs, dans certains cas, les pirates ont été en mesure d’activer de nouveaux appareils à l’aide des comptes de leurs victimes.

Par ailleurs, une banque ne devrait pas choisir à la légère les canaux à utiliser pour transmettre les codes d’authentification/d’autorisation dynamiques. Les codes SMS sont réputés pour être vulnérables à l’hameçonnage, et même à une interception. Dans ce cas, les maîtres d’œuvre de la fraude ont été en mesure de recevoir les codes SMS sur leurs appareils imitant ceux des utilisateurs, ce qui a rendu ces codes inutiles pour protéger les comptes bancaires. Une attaque type ciblant les mots de passe uniques par SMS commence par diriger la victime vers une page Web d’hameçonnage qui ressemble à celle de la banque. À cet endroit, l’utilisateur entre les renseignements qui déclenchent l’envoi d’un mot de passe unique par SMS. Un logiciel malveillant présent sur l’appareil de la victime récupère ensuite les codes envoyés par SMS et les transfère au pirate, ce qui signifie que la victime ne se connecte jamais au site de la banque, puisqu’elle interagit avec une page d’hameçonnage.

Les notifications poussées envoyées par canal crypté vers une application mobile fortement reliée à l’appareil de l’utilisateur pendant l’activation auraient probablement empêché les pirates d’obtenir et d’utiliser les mots de passe unique envoyés par SMS pour accéder aux comptes ou autoriser les paiements. De plus, lorsqu’on fait appel aux fonctionnalités matérielles des appareils mobiles (p. ex. : Secure Enclave sur les appareils iOS ou Trusted Execution Environment / Secure Element sur les appareils Android), il est beaucoup plus difficile pour les pirates de voler les identifiants des appareils. En demandant une authentification biométrique en plus de la confirmation associée à la notification poussée, on ajoute une autre couche de sécurité qui aurait pu empêcher ces pirates de réussir leur fraude.

Il est également important que les institutions financières mettent en place une technologie avancée d’inviolabilité (voir la section « blindage d’application mobile avec protection d’exécution » ci-dessous) sur toute application bancaire mobile. Cette technologie réduit le risque que des pirates modifient le processus de mise en relation avec l’appareil ou en fassent une rétro-ingénierie dans le but de reproduire l’itération de l’application bancaire mobile d’un utilisateur légitime sur un appareil émulé.

Luttez contre la fraude numérique sophistiquée grâce à une analyse du côté client et du côté serveur

Gartner a recommandé un cadre de détection de la fraude en ligne comprenant cinq niveaux de protection – axé sur le point terminal, axé sur la navigation et le réseau, axé sur l’utilisateur et l’entité, axé sur l’utilisateur multicanal et sur l’entité, et l’analyse des mégadonnées sur l’utilisateur et l’entité – afin de déceler la fraude en ligne. Comme les pirates ont utilisé un émulateur, ils ont été en mesure de contourner certains éléments du premier niveau de protection. Nous observons de plus en plus d’exemples de fraudeurs qui font appel à des méthodes sophistiquées pour être en mesure de simuler les données du côté client, comme l’appareil, l’endroit et le moment de la journée.

Cet incident de fraude mobile, et la maturité croissante des réseaux de fraude en ligne en général, démontre la nécessité d’adopter une solution plus complète de prévention de la fraude dotée de couches de sécurité supplémentaires configurées adéquatement. Ce faisant, il sera beaucoup plus difficile pour les pirates de contourner des niveaux de protection subséquents :

• Niveau 1 : Axé sur le point terminal – Analyse des comportements au point terminal et des corrélations avec les endroits; ce niveau comprend également la détection des logiciels malveillants et l’empreinte numérique de l’appareil
• Niveau 2 : Axé sur la navigation et le réseau – Analyse de la session, du réseau et des comportements pendant la navigation, ainsi que des tendances suspectes
• Niveau 3 : Axé sur l’utilisateur et l’entité (canal unique) – Analyse du comportement de l’utilisateur/de l’entité par canal (p. ex. : activités bancaires en ligne, activités bancaires mobiles, etc.)
• Niveau 4 : Axé sur l’utilisateur et l’entité sur tous les canaux et pour tous les produits – Analyse des comportements normaux, corrélée sur tous les canaux
• Niveau 5 : Mise en relation de l’utilisateur et de l’entité à l’aide des mégadonnées – Analyse des relations pour détecter le crime organisé et la collusion

Comme vous l’avez peut-être deviné, la collecte et la mise en corrélation des indices de risque pour tous ces aspects deviennent presque impossibles « à la vitesse humaine ». Tout système complet de détection de la fraude en ligne doit faire appel à un apprentissage automatique du côté serveur et à des règles contextuelles automatisées pour pouvoir avoir un impact.

Détecter les interactions automatisées non humaines

La ferme malveillante d’émulateurs imitait les appareils des victimes, ce qui a mis à risque toute banque qui s’appuyait uniquement sur l’identification/l’autorisation des appareils mobiles au moyen d’un ID ou d’un code unique envoyé par SMS. Si les applications de services bancaires ciblées par l’attaque avaient offert des fonctionnalités d’analyse des sessions et de corrélations entre les comportements aux points terminaux et les emplacements, les appareils auraient pu être identifiés comme étant émulés en raison du manque d’interactions « de type humain » (p. ex. : la façon dont une personne interagit avec un appareil, comme la vitesse de frappe, l’angle, la hauteur et bien d’autres aspects comportementaux).

La façon dont un utilisateur interagit avec une session, et le moment où le fait, peuvent fournir des renseignements sur ses comportements habituels pendant une session. Il s’agit là d’un niveau de protection supplémentaire qui peut compliquer la tâche d’un pirate, étant donné que l’émulateur automatisé devrait sans cesse imiter la vitesse d’interaction de la victime et bien d’autres aspects de son comportement.

Surveiller plus que l’ouverture de session : surveillance de session en continu

Maintenant que nous passons aux niveaux 3 et 4, il est important de tenir compte des activités bancaires pendant la séance qui sont accomplies après l’ouverture de session initiale. Au final, un pirate ne voudra pas payer les factures d’un utilisateur : il cherche à retirer des fonds. Il est donc crucial que les banques mettent en application une surveillance continue pour examiner les nouveaux appareils, bénéficiaires et transactions. Cet examen a pour but de déterminer si les appareils, bénéficiaires ou transactions sont nouveaux ou connus (utilisés) par tout autre client ou entreprise cliente d’une banque.

Automatisation de la prévention/détection de la fraude grâce au pouvoir de l’apprentissage automatique

Le fait de comprendre l’analyse des activités habituelles de tous les utilisateurs et appareils permet d’identifier les activations de masse d’appareils, la création de masse de bénéficiaires et les transactions de masse – qui sont tous des indices d’une attaque d’envergure. Dans ce cas-ci, en rétrospective, la banque aurait pu avoir été informée lors d’une des nombreuses étapes de l’attaque. Ces étapes comprennent l’activation de nombreux nouveaux appareils, l’émulation d’appareils, la création de nouveaux bénéficiaires, le transfert de montants élevés, le retrait complet du solde d’un compte et l’envoi d’argent à des comptes auparavant inconnus.

Ces indices, comme des milliers d’autres, peuvent être fournis à des modèles d’apprentissage automatique, qui sont capables de fonctionner dans un espace fortement dimensionnel qui dépasse largement celui d’un être humain, et de fournir une prédiction (anomalie/pointage de risque) en temps réel. Ces modèles permettent donc à une banque d’interrompre une attaque et de l’empêcher de propager et d’activer une réaction automatisée.

Luttez contre les émulateurs et les autres menaces mobiles grâce au blindage d’applications avec protection d’exécution

Bien que nous n’ayons pas tous les détails sur la façon dont les pirates ont cerné les faiblesses dans les applications mobiles de la banque et dans ses systèmes de détection de la fraude, il est raisonnable de croire qu’ils ont été en mesure de faire une rétro-ingénierie de certains aspects des applications mobiles. Il est probable que les pirates aient simplement téléchargé les applications légitimes sur les magasins d’applications officiels et décortiqué les applications sur un émulateur pendant leur exécution.

Le blindage d’application mobile avec protection d’exécution aurait détecté ce genre d’activité et rapidement fermé l’application pour éviter que ne soient accomplies ces activités malveillantes. Non seulement le blindage avancé d’application mobile empêche l’application d’être exécutée sur un émulateur, mais elle détecte et bloque plusieurs outils utilisés par les pirates pour faire une rétro-ingénierie de l’application et comprendre comment l’application fonctionne.

En raison du degré de sophistication de cette menace, il n’est pas exagéré de supposer que les pirates ont été en mesure de faire une rétro-ingénierie de l’application pour comprendre comment elle était liée à l’appareil d’un utilisateur (le cas échéant) et comment elle communiquait avec les API du côté serveur de la banque. Le blindage d’application mobile avec protection d’exécution aurait ajouté une autre couche de contrôle de sécurité qui aurait rendu le travail du pirate encore plus long et dispendieux.

En plus d’atténuer les activités de rétro-ingénierie, le blindage d’application mobile avec protection d’exécution offre plusieurs fonctionnalités de sécurité axées sur les applications bancaires mobiles qui compliquent davantage la tâche des pirates qui cherchent à lancer une cyberattaque sur des applications bancaires mobiles et sur les utilisateurs de ces applications :

• Prévenir l’imitation de l’application en détectant le reconditionnement d’application (c.-à-d. modifier et republier une application de façon malveillante) 
• Identifier la modification du code et/ou l’insertion de librairies d’exécution malveillantes dans une application 
• Réduire les risques de fuite de données sensibles en empêchant les saisies d’écran et l’utilisation de claviers malveillants 
• Déceler l’élévation des privilèges en reconnaissant les appareils débridés ou ceux dont les racines ont été déverrouillées 
• Atténuer les attaques de superposition sur l’interface utilisateur en empêchant les dérogations en avant-plan sur les appareils Android

Résumé et cybersécurité

En conclusion, pour protéger leurs clients bancaires et entreprises clientes contre l’évolution continuelle des risques de sécurité associés aux pirates, les institutions financières doivent adopter une approche par niveaux en matière de fraude bancaire en ligne, qui comprend une authentification forte client, une analyse des risques du côté serveur et une sécurité avancée des applications mobiles, notamment le blindage d’application mobile avec protection d’exécution.