L’IA ne se contente plus d’accélérer les opérations bancaires : elle peut aussi accélérer une intrusion. En Corée du Sud, une attaque ayant touché plusieurs établissements a exposé les données d’environ 25 000 clients de Shinhan Bank, tandis que les enquêteurs ont retrouvé des traces associées à l’outil open source ARTEX, conçu pour automatiser des tâches de pentest.
Cette affaire intervient alors que les modèles de langage progressent dans la recherche de vulnérabilités. Anthropic affirme que GLM-5.3 a produit des exploits fonctionnels de bout en bout sur ExploitBench dans 50 tentatives sur 410, contre 56 sur 410 pour Claude Mythos Preview. Pour les banques, le problème ne réside donc plus uniquement dans la précision d’un modèle, mais dans la vitesse, l’automatisation et l’échelle qu’il peut apporter à une attaque.
Une attaque bancaire peut désormais s’appuyer sur une chaîne automatisée
L’affaire sud-coréenne montre pourquoi les banques redoutent les agents capables d’enchaîner plusieurs étapes techniques sans intervention permanente. ARTEX est présenté comme un système de penetration testing autonome fondé sur des modèles de langage et plusieurs agents IA. Il automatise notamment la reconnaissance, la recherche de vulnérabilités, la planification des chemins d’attaque, l’exécution d’outils de sécurité et la vérification des résultats.
Cette architecture change la nature du risque. Un attaquant n’a plus besoin de réaliser manuellement chaque étape, de l’inventaire des services exposés jusqu’à la validation d’une faille. L’outil peut structurer ces opérations et réduire le temps nécessaire pour passer d’une information publique à une tentative d’intrusion.
La prudence reste indispensable concernant l’attribution technique de l’attaque. Des enquêteurs ont retrouvé sur une infrastructure liée aux incidents une chaîne en chinois associée à ARTEX, mais plusieurs autorités et médias ont souligné que cette trace ne prouvait pas, à elle seule, que le logiciel avait été exécuté pendant l’intrusion ni qu’elle permettait d’identifier l’attaquant.
À retenir : l’IA n’a pas besoin d’agir seule pour augmenter fortement la capacité d’un pirate. Il suffit qu’elle automatise suffisamment de tâches pour permettre à un opérateur isolé de conduire une opération plus rapide et plus large.
25 000 dossiers volés chez Shinhan Bank
Shinhan Bank a indiqué qu’environ 25 000 clients étaient concernés par la fuite. Les informations compromises comprenaient les noms, les numéros de téléphone, les revenus annuels et les plafonds de prêt calculés dans le cadre du suivi de demandes de crédit.
L’accès ne concernait pas nécessairement l’application bancaire grand public. Les éléments disponibles décrivent une plateforme utilisée par des intermédiaires de crédit pour vérifier l’état de demandes de prêt. Cette distinction est importante : les systèmes périphériques, parfois moins visibles que les applications principales, peuvent devenir des points d’entrée particulièrement attractifs.
D’autres établissements sud-coréens ont également signalé des clients affectés. Korea Times rapporte 119 personnes concernées chez KB Kookmin Bank et 89 chez Hana Bank. TechTimes évoque de son côté plus de 65 000 clients exposés dans sept institutions financières, chiffre qui inclut plusieurs incidents regroupés dans la même campagne.
| Établissement | Clients concernés | Données mentionnées |
|---|---|---|
| Shinhan Bank | Environ 25 000 | Noms, téléphones, revenus annuels, plafonds de prêt |
| KB Kookmin Bank | 119 | Informations liées aux cartes de crédit |
| Hana Bank | 89 | Données de clients affectés par l’incident |
| Yegaram Savings Bank | Environ 40 000 | Informations personnelles de clients |
Ces chiffres ne décrivent pas seulement une perte de données. Ils illustrent la valeur des informations financières indirectes : revenus, capacité d’emprunt, coordonnées et identifiants peuvent alimenter des campagnes de phishing, des fraudes au crédit ou des tentatives d’usurpation.
Les modèles de langage rapprochent l’attaque automatisée de l’exploitation réelle
La progression des modèles dans la cybersécurité offensive constitue un deuxième motif d’inquiétude. Anthropic indique que GLM-5.3 peut construire de manière autonome des exploits complets, à un niveau proche de Claude Mythos Preview.
Sur ExploitBench, un ensemble de tests fondé sur des vulnérabilités réelles du moteur JavaScript V8 de Chrome, GLM-5.3 a réussi 50 tentatives sur 410, soit environ 12 %. Claude Mythos Preview en a réussi 56, soit environ 14 %.
Ces résultats ne signifient pas qu’un modèle peut compromettre n’importe quelle banque à volonté. ExploitBench évalue une capacité précise, dans un environnement défini. Les performances dépendent du système ciblé, des protections en place, de la qualité des informations disponibles et de la possibilité de maintenir un accès.
Ils montrent cependant que les modèles peuvent produire des chaînes d’exploitation utilisables sur des failles connues. Pour les banques, cela réduit le délai entre la publication d’une vulnérabilité et son exploitation potentielle, surtout lorsque les systèmes exposés ne sont pas corrigés rapidement.
Du modèle conversationnel à l’agent opérationnel
Un chatbot qui répond à une question et un agent capable d’appeler des outils ne présentent pas le même profil de risque. Le second peut analyser des résultats, choisir une prochaine étape, lancer une commande, interpréter la réponse et recommencer.
ARTEX s’inscrit dans cette logique d’orchestration. Sa valeur offensive vient moins d’une réponse isolée que de l’enchaînement de tâches : trouver une cible, repérer une faiblesse, préparer une tentative, vérifier son résultat et documenter le chemin suivi.
Cette automatisation peut aussi faciliter le travail des défenseurs. Les équipes de sécurité utilisent déjà des outils de penetration testing pour identifier leurs propres failles. Le risque apparaît lorsque les mêmes capacités sont accessibles à un tiers qui n’est pas autorisé à tester l’environnement.
Les banques doivent contrôler les systèmes invisibles du parcours client
La crise sud-coréenne rappelle qu’un dispositif de crédit, un portail destiné à des intermédiaires ou une interface de vérification peut exposer des données sensibles même s’il ne constitue pas le cœur de la banque en ligne. Une stratégie de sécurité centrée uniquement sur l’application mobile principale laisse donc des zones moins surveillées.
Les architectures bancaires relient de nombreux composants : systèmes de crédit, prestataires, API, outils internes, plateformes commerciales et services d’authentification. Chaque connexion élargit la surface d’attaque et complique l’identification d’un comportement anormal.
L’usage d’agents IA par les attaquants augmente cette pression. Une machine peut effectuer rapidement des reconnaissances répétées, tester plusieurs chemins et revenir sur une cible à des horaires variables. Les défenses doivent donc repérer non seulement une signature connue, mais aussi des séquences inhabituelles d’actions.
Les contrôles prioritaires
- Inventorier les applications exposées, y compris les portails utilisés par les courtiers, partenaires et prestataires.
- Appliquer des contrôles d’accès stricts aux interfaces qui consultent des données de crédit.
- Limiter les privilèges des comptes techniques et séparer les environnements.
- Journaliser les recherches, téléchargements et changements de droits avec une conservation suffisante.
- Tester régulièrement les parcours d’attaque sur les applications périphériques.
- Détecter les séquences automatisées de reconnaissance et d’authentification.
- Prévoir la révocation rapide des accès compromis et la rotation des secrets.
Ces mesures ne neutralisent pas l’IA offensive, mais elles réduisent les possibilités d’enchaînement automatique. Plus les systèmes sont cloisonnés et les privilèges limités, plus il devient difficile pour un agent de transformer une première faille en extraction massive de données.
La fraude gagne en vitesse, en personnalisation et en volume
Les inquiétudes ne se limitent pas au piratage technique. Dans la banque, l’IA peut aussi produire rapidement des messages convaincants, analyser des informations publiques et adapter une arnaque à un profil précis.
Une fuite contenant un nom, un numéro de téléphone, un revenu annuel et un plafond de prêt donne à un fraudeur des éléments pour construire un scénario crédible. Il peut se présenter comme un conseiller, un intermédiaire de crédit ou un service de vérification et reprendre des détails connus de la victime.
La personnalisation augmente la probabilité qu’un client réponde. La génération automatisée permet en outre de multiplier les variantes, de changer de ton et de langue, ou de relancer les personnes qui n’ont pas répondu. Une campagne qui exigeait auparavant un important travail manuel peut désormais être industrialisée.
Les banques doivent donc surveiller les signaux situés après la fuite : modification inhabituelle des coordonnées, nouvelle demande de crédit, changement d’appareil, connexion depuis un environnement atypique ou combinaison inhabituelle d’actions. Aucun signal isolé ne suffit forcément, mais plusieurs anomalies rapprochées peuvent révéler une tentative d’usurpation.
À retenir : la donnée financière volée ne sert pas seulement à accéder à un compte. Elle peut rendre une fraude plus crédible, accélérer l’usurpation et faciliter l’ouverture de nouveaux produits au nom d’un client.
L’IA utilisée par les banques ajoute ses propres risques
Les établissements financiers déploient aussi l’IA pour détecter la fraude, évaluer le risque, assister les conseillers et automatiser des opérations. Cette utilisation défensive et commerciale crée une autre catégorie de préoccupations : erreurs de modèle, décisions difficiles à expliquer, biais de données et dépendance envers des fournisseurs technologiques.
Un système de détection trop sensible peut bloquer des clients légitimes. Un système trop permissif peut laisser passer une transaction frauduleuse. Dans les deux cas, les conséquences touchent directement l’accès aux services financiers et la relation de confiance.
Les modèles de langage ajoutent un risque particulier lorsqu’ils accèdent à des données internes ou à des outils d’action. Une mauvaise configuration peut exposer des informations confidentielles dans une réponse, transmettre un ordre mal interprété ou permettre à un utilisateur de contourner les règles prévues.
La gouvernance doit donc distinguer plusieurs niveaux d’usage : simple génération de texte, consultation de données, recommandation à un employé et action automatique sur un compte ou un paiement. Plus le système peut agir, plus les validations humaines, les limites techniques et les journaux d’audit doivent être stricts.
Les questions que les directions doivent trancher
- Quelles données peuvent être envoyées à un modèle externe ?
- Quelles décisions doivent obligatoirement être validées par un employé ?
- Quels outils un agent peut-il appeler et avec quels privilèges ?
- Comment une banque reconstitue-t-elle le raisonnement ayant conduit à une décision ?
- Quelle procédure s’applique lorsqu’un modèle produit une réponse erronée ?
- Comment vérifier qu’un fournisseur respecte les exigences de sécurité et de confidentialité ?
Ces questions ne relèvent pas uniquement de l’informatique. Elles concernent les directions des risques, la conformité, les métiers, les achats et la protection des données.
Le risque réglementaire devient aussi un risque commercial
Une fuite de données peut entraîner des coûts directs, mais son effet le plus durable peut toucher la confiance. Les clients attendent d’une banque qu’elle protège des informations dont la sensibilité dépasse largement celle d’un compte de messagerie ordinaire.
En Corée du Sud, l’incident a provoqué une réaction des autorités et du président sud-coréen, tandis que le gouvernement a activé une réponse de cybersécurité continue face à la campagne visant plusieurs institutions financières.
Cette réaction montre que les attaques assistées par IA sont désormais traitées comme un sujet de résilience nationale, et non comme un simple problème technique entre une banque et son prestataire. Une compromission peut toucher simultanément la protection des données, la continuité des services, la stabilité financière et la confiance du public.
La pression réglementaire devrait donc porter sur la traçabilité des usages d’IA, la sécurité des fournisseurs, la gestion des accès et la capacité à détecter rapidement une attaque automatisée. Les banques qui ne peuvent pas expliquer quels systèmes utilisent l’IA auront plus de difficulté à prouver qu’elles contrôlent effectivement leurs risques.
Notre avis : l’IA bancaire doit avancer avec des limites vérifiables
L’inquiétude croissante est justifiée, mais elle ne vient pas de l’existence d’un modèle magique capable de pirater seul une banque. Elle vient de la combinaison entre des outils accessibles, des systèmes interconnectés, des données très valorisées et des agents capables d’automatiser une partie croissante du travail offensif.
L’affaire Shinhan Bank donne une mesure concrète de cette évolution : environ 25 000 clients touchés, des données liées au crédit exposées et une enquête portant sur l’usage possible d’ARTEX. Les résultats publiés par Anthropic sur GLM-5.3 ajoutent un indicateur technique : les modèles atteignent désormais un niveau proche d’un système conçu pour l’exploitation autonome de vulnérabilités.
Dans les six prochains mois, l’avantage ira aux banques qui traiteront les agents IA comme des opérateurs à privilèges, et non comme de simples assistants. Chaque action devra être limitée, enregistrée, contrôlée et réversible. La question ne sera plus seulement de savoir si une banque utilise l’IA, mais si elle peut démontrer précisément ce que ses modèles ont le droit de voir et de faire.