L’argent est sorti du propre compte de la banque. Le chemin d’accès passait par un fournisseur.
Le groupe bancaire français Crédit Mutuel Arkéa a révélé le 4 novembre que des attaquants avaient utilisé la plateforme d’un prestataire de services pour accéder à la banque et effectuer des virements frauduleux. La banque affirme que les actifs de ses clients n’ont pas été touchés, mais l’incident place sous surveillance l’accès des fournisseurs aux systèmes de paiement.
Pour les équipes chargées de la sécurité et de la lutte contre la fraude, la question pratique est de savoir jusqu’où peut aller une connexion externe de confiance — et quels contrôles peuvent l’empêcher de déplacer des fonds.
Ce qu’Arkéa a confirmé
Dans sa communication de suivi, Arkéa a déclaré que les attaquants avaient transféré des fonds depuis son propre compte vers d’autres établissements bancaires. Ces transferts auraient potentiellement permis de convertir les fonds en cryptomonnaies via des plateformes spécialisées.
La banque a démenti que les attaquants soient passés par sa filiale Fortuneo. Elle n’a pas nommé le fournisseur ni révélé la méthode initiale de compromission.
Arkéa a refusé de confirmer le vol de 118 millions d’euros, soit environ 133 millions de dollars US, qui avait été rapporté, tout en reconnaissant que l’ordre de grandeur du montant était exact. Une partie des fonds a été bloquée, les efforts de récupération se sont poursuivis et l’impact financier définitif restait en cours d’évaluation.
Sa première déclaration indiquait que certaines transactions avaient été temporairement suspendues afin d’empêcher de nouveaux mouvements frauduleux. Certains virements de clients ont été retardés. Dans sa déclaration de suivi, Arkéa a indiqué que presque toutes les opérations avaient repris le matin du 4 novembre, après des vérifications supplémentaires et le renforcement des mesures de sécurité.
La banque a également averti ses clients d’éventuelles campagnes d’hameçonnage ultérieures. Elle leur a conseillé d’éviter de communiquer leurs identifiants bancaires ou leurs codes de validation par SMS et de contacter directement leur conseiller afin de vérifier les messages suspects.
L’accès d’un fournisseur peut avoir des conséquences au-delà de ce fournisseur
Waseem Ahmed, responsable de l’ingénierie chez Secure.com, a déclaré que la distinction entre les comptes clients et le propre compte d’une banque méritait qu’on s’y attarde.
« Les contrôles antifraude sont généralement particulièrement stricts pour les comptes clients, et le propre compte d’une banque déplace chaque jour des sommes importantes. Un virement important de plus vers un autre établissement peut donc être plus difficile à détecter, a déclaré Ahmed. Je ne sais pas comment sont configurés les contrôles d’Arkéa ; c’est donc une observation générale. »
Sa préoccupation plus générale concerne l’autorité qu’une plateforme externe peut exercer une fois connectée aux systèmes financiers.
« Tout fournisseur dont la plateforme permet d’accéder à vos systèmes fait partie de votre chaîne de paiement, que cela ait été prévu ou non, et il doit être soumis aux mêmes contrôles que le reste de cette chaîne », a-t-il déclaré.
L’accès de tiers peut toucher des fonctions opérationnelles très différentes. Lors d’un autre incident, des attaquants auraient modifié les réglages de réfrigération de sites français de banques du sang via une faille chez un fournisseur, mais la surveillance a empêché les produits stockés de subir des dommages.
Ailleurs, des mises à jour de sécurité cPGuard empoisonnées ont compromis près de 3 000 serveurs. Ces cas illustrent différentes formes de risque lié aux fournisseurs ; aucun des deux ne permet d’établir comment s’est déroulée l’attaque contre Arkéa.
Les détails manquants sont importants
Darin Fredde, directeur principal et évangéliste de la sécurité offensive chez Ridge Security, a déconseillé de reconstituer une attaque à partir de communications incomplètes.
« Nous savons ce que Crédit Mutuel Arkéa a révélé, mais nous ne connaissons pas la séquence complète de l’attaque, a déclaré Fredde. Spéculer sur les contrôles qui ont échoué ou sur la manière dont les attaquants ont opéré peut donner lieu à un récit intéressant, mais cela ne rend pas nécessairement les systèmes plus sûrs. »
Arkéa a déclaré que ses systèmes avaient rapidement détecté une activité suspecte et a écarté l’erreur humaine au sein de la banque comme cause. Cette déclaration ne permet pas d’établir si le fournisseur a subi un vol d’identifiants, l’exploitation d’une faille logicielle ou une autre forme de compromission.
Fredde a expliqué que les attaquants pouvaient combiner exploitation technique, ingénierie sociale et détournement de relations de confiance pour atteindre un objectif opérationnel. Les tests de sécurité doivent donc examiner ce que ces faiblesses permettent lorsqu’elles sont combinées.
« Un analyseur de vulnérabilités peut vous indiquer si un système présente une faiblesse connue. Il ne vous dira pas nécessairement si quelqu’un peut manipuler un processus opérationnel par ailleurs légitime pour accomplir quelque chose qui n’aurait jamais dû être possible », a-t-il déclaré.
Ce que les banques devraient tester sur l’ensemble de la chaîne de paiement
Ahmed recommande de commencer par un scénario concret : vérifier si une personne entrant par l’accès d’un fournisseur peut envoyer un paiement à un bénéficiaire auquel la banque n’a encore jamais versé de fonds.
Cela donne aux équipes de sécurité, de trésorerie et de lutte contre la fraude un objectif de test commun. L’exercice doit établir quelle identité peut créer un bénéficiaire, quelle identité peut autoriser un paiement et si l’approbation reste indépendante lorsqu’une connexion externe est compromise.
Fredde recommande de tester conjointement le principe du moindre privilège, la séparation des tâches, l’autorisation indépendante et la surveillance des transactions. Un programme de tests d’intrusion peut intégrer ces résultats opérationnels à son périmètre, parallèlement aux faiblesses techniques.
Sur la base de leurs recommandations, les banques peuvent organiser l’examen autour de quatre contrôles :
- Tracer les autorisations des fournisseurs. Identifier les comptes, les intégrations et les autorisations qui relient chaque prestataire aux fonctions de paiement. Déterminer si un accès prévu pour l’assistance ou l’échange de données peut également lancer ou modifier des transactions.
- Tester l’approbation indépendante. Dans le cadre d’un exercice contrôlé, vérifier qu’une identité de fournisseur compromise ne peut à la fois demander une modification sensible et satisfaire à l’approbation requise pour l’exécuter.
- Mesurer les sorties de fonds cumulées. Ahmed recommande de plafonner les paiements effectués depuis les propres comptes de la banque, dans chaque système capable d’envoyer de l’argent et sur plusieurs jours. Une fois le seuil franchi, les paiements nouveaux ou inhabituels devraient attendre une approbation.
- Vérifier l’intervention. Déterminer qui reçoit une alerte, qui peut suspendre un paiement et qui peut désactiver l’accès du fournisseur. Consigner si ces actions interviennent avant la finalisation du paiement simulé.
Il s’agit de contrôles proposés pour d’autres établissements, et non de conclusions selon lesquelles Arkéa ne disposait pas de ces mesures. Les seuils et les règles d’approbation doivent refléter les volumes de paiement et les exigences opérationnelles propres à chaque banque.
Le résultat utile consiste à disposer de preuves montrant si la connexion du fournisseur testée permet des paiements non autorisés, si la surveillance détecte la tentative et si le personnel peut intervenir avant la sortie des fonds. Une évaluation du fournisseur ou une simple analyse de vulnérabilités sans résultat ne peut, à elle seule, démontrer ce point.
Pour rester informé : Abonnez-vous à Tech Insider Europe pour recevoir gratuitement une couverture des évolutions technologiques, de l’IA et de la sécurité dans la région.