Dans la banque et la finance, une attaque AiTM (adversary-in-the-middle) ne cherche pas à casser la SCA : elle l'utilise. Le proxy inverse laisse le client s'authentifier normalement, puis récupère la session ouverte côté banque ou côté outil interne. Le point souvent mal compris : le lien dynamique exigé par la DSP2 limite fortement le détournement d'un virement en ligne, mais il ne protège ni la session, ni les parcours qui ne sont pas des paiements.
Deux cibles très différentes : le client et le collaborateur
Les équipes fraude et les équipes SSI regardent souvent la même attaque par deux bouts.
Côté client, l'attaquant vise l'espace en ligne particulier ou professionnel. Son intérêt immédiat n'est pas toujours le virement : la session donne accès aux relevés, aux coordonnées, aux plafonds et aux bénéficiaires enregistrés. Cette matière alimente ensuite un appel de faux conseiller beaucoup plus crédible.
Côté collaborateur, le proxy inverse vise les outils métier exposés sur Internet : messagerie, outil de gestion de la relation client, portail de back-office, console d'administration. Là, aucune SCA au sens de la DSP2 ne s'applique. Une session volée équivaut à un poste de travail emprunté, avec les droits associés.
Ce que la SCA arrête, ce qu'elle laisse passer
La DSP2 (directive (UE) 2015/2366) impose deux facteurs de catégories distinctes et un lien dynamique entre l'authentification et le montant ainsi que le bénéficiaire d'une opération de paiement. Ce lien dynamique est la disposition la plus utile face à l'AiTM : si l'authentification est réellement liée aux données de l'opération, un attaquant ne peut pas transformer un paiement validé par le client en un virement vers son propre compte.
Encore faut-il que l'implémentation affiche et scelle effectivement le montant et le bénéficiaire. Une validation générique de type « confirmez votre connexion » ne remplit pas cette fonction, même si elle utilise deux facteurs.
| Parcours bancaire | SCA applicable ? | Ce que l'AiTM obtient malgré tout | Levier de réduction |
|---|---|---|---|
| Connexion à l'espace client | Oui, sans lien dynamique | Session complète, données patrimoniales | Facteur lié à l'origine, durée de session courte |
| Virement vers bénéficiaire existant | Oui, avec lien dynamique | Rien de directement rejouable si le lien est correct | Affichage explicite du bénéficiaire et du montant |
| Ajout d'un bénéficiaire | Variable selon l'établissement | Préparation de la fraude à venir | Traiter l'ajout comme une opération sensible |
| Modification de coordonnées de contact | Non couverte par la SCA | Détournement des notifications futures | Validation d'intention, délai de carence |
| Outils internes exposés | Non | Accès métier aux dossiers clients | Accès conditionnel, réauthentification par action |
| Portail entreprise multi-signataires | Oui | Vue sur les circuits de validation | Séparation des rôles, double validation hors bande |
La lecture de ce tableau est simple : les parcours non-paiement sont les plus rentables pour un attaquant, parce qu'ils sont hors du champ du lien dynamique tout en préparant le préjudice.
Le passage de relais vers la fraude au téléphone
Le schéma le plus coûteux en banque de détail combine deux temps. L'AiTM fournit d'abord des données réelles : dernières opérations, nom du conseiller, plafonds. Un appel de faux conseiller suit, souvent dans les minutes qui suivent, et exploite ces éléments pour obtenir du client une action qu'il exécute lui-même — validation d'un virement présenté comme une « mise en sécurité », enregistrement d'un nouveau bénéficiaire, ou lecture d'un code.
Ce couplage explique pourquoi une contre-mesure purement technique sur la connexion ne suffit pas. Tant que le client peut être amené à valider lui-même une opération frauduleuse, le point de contrôle doit se situer sur l'opération et pas seulement sur l'ouverture de session.
Parades applicables, par ordre de rendement
- Basculer les populations les plus exposées vers un facteur lié à l'origine. Administrateurs, back-office paiement, gestionnaires de comptes : ce sont les sessions qui coûtent le plus cher.
- Traiter les changements de bénéficiaire et de coordonnées comme des opérations sensibles, au même titre qu'un virement, avec délai de carence et notification hors bande.
- Réduire la durée de vie des sessions internes et rendre la révocation immédiate et testée.
- Corréler authentification et usage : une authentification depuis une infrastructure d'hébergement suivie d'une consultation massive de dossiers est un signal fort.
- Instrumenter le canal téléphonique : aucun conseiller ne demande de valider une opération pendant l'appel. Cette règle doit être connue du client avant l'incident, pas rappelée après.
- Ancrer la preuve sur l'action. Le facteur cognitif fait résoudre un défi au moment de l'opération, dans un canal éphémère ouvert par QR code dynamique à usage unique. Rien de ce qui transite n'est rejouable par un relais, et la validation porte sur l'intention réelle du client.
Ce que DORA change dans la conversation
DORA (règlement (UE) 2022/2554), applicable depuis janvier 2025, déplace le sujet du contrôle d'accès vers la résilience opérationnelle : capacité à détecter, à notifier et à reprendre. Pour un incident AiTM, cela se traduit par des exigences concrètes de traçabilité — savoir quelles sessions étaient actives, lesquelles ont été révoquées, et à quelle heure. Un dispositif d'authentification qui ne produit pas de journal exploitable devient un problème de conformité autant qu'un problème de sécurité.
FAQ
Le lien dynamique DSP2 rend-il l'AiTM inutile en banque ?
Non. Il neutralise le détournement direct d'un paiement validé, ce qui est déjà considérable. Il ne protège ni la connexion, ni la consultation, ni les parcours de gestion de compte, qui sont précisément ceux que l'attaquant utilise pour préparer la suite.
Faut-il abandonner le SMS-OTP pour la banque en ligne ?
Le NIST classe l'OTP par SMS ou voix en « restricted », c'est-à-dire déconseillé. En pratique, il reste relayable par un proxy inverse et exposé au SIM swapping. La priorité raisonnable est de le retirer des parcours à fort impact avant de le retirer partout.
Comment protéger les collaborateurs du back-office ?
Facteur lié à l'origine sur l'ensemble des accès exposés, sessions courtes, et réauthentification explicite pour les actions à effet financier. L'accès conditionnel doit aussi tenir compte de l'état du poste, pas seulement de l'identité.
Un score de risque suffit-il à détecter l'AiTM ?
Il aide, sans suffire. Un score contextuel repère les incohérences d'adresse, d'agent ou d'horaire, mais un attaquant qui poursuit une session existante ne déclenche aucune nouvelle authentification. Il faut donc surveiller aussi les actions post-connexion.
Aller plus loin : authentification cognitive · anatomie d'une attaque AiTM · DSP2 et authentification forte · authentification transactionnelle