Marcus Chen, YuSMP Group
Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Conçoit et sécurise des plateformes back-end et cloud pour des équipes produit aux États-Unis et dans l'UE
Couloir de serveurs bordé de panneaux façon coffre-fort, parcouru par un essaim de petites sondes lumineuses : une image des attaques automatisées qui balaient les systèmes exposés

Les attaques en bref

Entre le 1er et le 5 octobre 2026, sept établissements financiers sud-coréens ont confirmé des fuites de données touchant environ 66 000 particuliers et 2 200 dossiers d'entreprises, selon le Korea Herald. Shinhan Bank a été la première à communiquer, le 1er octobre ; au 5 octobre, KB Kookmin, Hana, BNK Busan, Yegaram Savings, Welcome Savings et Hyundai Capital avaient suivi. La police nationale coréenne a mobilisé 28 enquêteurs, répartis en quatre équipes de son unité de lutte contre le cyberterrorisme.

Ce qui distingue cette vague, c'est l'outillage soupçonné. Bloomberg, citant Yonhap, a rapporté le 2 octobre que des outils d'IA étaient soupçonnés dans l'intrusion chez Shinhan, et des chercheurs ont trouvé sur l'infrastructure associée un titre de page en chinois signifiant à peu près « console de test d'intrusion autonome par IA ». Le président Lee Jae Myung a déclaré que des signes d'usage de l'IA étaient apparus et a ordonné une enquête approfondie.

Les points d'entrée, eux, étaient banals : des applications périphériques exposées sur Internet, avec une authentification faible. C'est précisément la surface qu'un test d'intrusion et audit de sécurité doit mettre au jour avant qu'un attaquant automatisé ne le fasse.

Quels établissements ont été touchés, et qu'est-ce qui a fuité ?

Shinhan Bank a déclaré le premier incident le 1er octobre, avec environ 25 700 clients concernés. Dans les jours suivants, KB Kookmin Bank, Hana Bank et BNK Busan Bank ont signalé des incidents, puis les banques d'épargne Yegaram et Welcome ainsi que l'organisme de crédit Hyundai Capital. Woori Bank et NH NongHyup Bank auraient également été visées, sans fuite de données confirmée.

Les champs exposés sont ceux que recherchent les fraudeurs : noms et numéros de téléphone associés aux revenus, aux plafonds d'emprunt et, dans certains cas, aux numéros d'enregistrement de résident. Les volumes varient fortement d'un établissement à l'autre — certaines déclarations ne concernaient que quelques dizaines de personnes — et la presse locale diverge sur les chiffres par banque ; nous citons donc le total publié par le Korea Herald le 6 octobre.

La Financial Services Commission a tenu une réunion d'urgence et demandé à tous les acteurs financiers d'inspecter leurs systèmes accessibles de l'extérieur, de réduire l'exposition inutile des données, de vérifier leurs contrôles d'authentification et de partager le renseignement sur la menace. Le Financial Supervisory Service a identifié 28 adresses IP liées aux tentatives et fixé un délai court pour les contrôles internes.

Quel rôle a joué l'IA ?

La piste de l'IA repose sur des indices forensiques, pas sur une attribution confirmée. Un serveur considéré comme lié à l'intrusion chez Shinhan affichait un titre HTML en chinois décrivant une console de test d'intrusion autonome par IA. Des chercheurs l'ont rapproché d'ARTEX, un framework open source qui s'appuie sur des agents LLM pour automatiser la reconnaissance, la découverte de vulnérabilités, la planification des chemins d'attaque, l'exécution d'outils et la vérification des exploits. BleepingComputer a souligné le 5 octobre que les autorités n'ont pas confirmé l'usage de l'outil, et des experts locaux décrivent un opérateur humain qui le pilote.

La nuance compte. Le scénario probable n'est pas celui d'un pirate IA totalement autonome, mais d'une petite équipe qui utilise des outils agentiques pour scanner de nombreuses cibles, enchaîner les découvertes et tester les parcours de connexion à un rythme qui exigeait autrefois bien plus de monde. Cette même catégorie d'outils est vendue et publiée en open source pour du red teaming légitime. Son arrivée côté offensif réduit le délai entre « un endpoint faible existe » et « il est exploité ».

Comment les attaquants sont-ils entrés ?

Selon le Korea Times, les points d'entrée signalés se situaient en périphérie des banques, pas dans les systèmes cœur :

  • Shinhan : un contournement d'authentification sur un service de suivi des dossiers des intermédiaires de crédit — une page de consultation destinée aux partenaires.
  • KB Kookmin : des accès externes anormaux à un système mobile destiné aux salariés.
  • Hana : un accès non autorisé à un système d'appui commercial.

La presse locale évoque aussi du credential stuffing — des connexions automatisées avec des mots de passe ayant fuité. Rien de tout cela ne nécessite d'exploit inédit. Il suffit de trouver des applications annexes qui renvoient des données clients, font confiance au client ou n'ont pas de limitation de débit — un travail qu'un agent IA accomplit sans relâche.

Ce que cela change pour les équipes logicielles aux États-Unis et dans l'UE

Votre application la plus faible définit votre incident. Les banques durcissent leurs plateformes cœur et leur banque en ligne. Les portails d'intermédiaires, les outils de consultation pour courtiers, les back-ends mobiles des salariés et les outils commerciaux sont souvent développés vite, par différents prestataires, et moins audités. Pour les entreprises de la FinTech et leurs fournisseurs, ils constituent désormais une surface d'attaque de premier rang.

Les pentests annuels ne suivent plus le rythme des attaquants. Si un adversaire peut lancer un agent sur des centaines d'hôtes et itérer pendant la nuit, un audit annuel laisse des mois d'exposition. Attendez-vous à ce que régulateurs et grands clients exigent des tests continus ou liés aux mises en production, une surveillance de la surface d'attaque et la preuve que les vulnérabilités sont corrigées.

Les délais réglementaires sont courts. Dans l'UE, les entités financières soumises à DORA doivent classer et notifier les incidents majeurs liés aux TIC dans des délais serrés, et la réglementation new-yorkaise NYDFS Part 500 impose de signaler les événements de cybersécurité sous 72 heures. Une intrusion via un portail développé par un prestataire reste l'incident de l'établissement : les contrats avec les éditeurs de logiciels doivent donc inscrire noir sur blanc des obligations de tests de sécurité et de signalement.

La minimisation des données est un contrôle de sécurité. Une page de suivi qui n'avait besoin d'afficher que « accordé / en cours » mais renvoyait revenus et plafonds de crédit a transformé un bug d'authentification en violation de données à notifier. Concevoir des API qui ne renvoient que les champs indispensables limite l'impact du prochain contournement.

Qu'est-ce que cela signifie pour le marché français ?

En France, les banques, assureurs et prestataires de services de paiement appliquent DORA depuis le 17 janvier 2025, sous la supervision de l'ACPR. Le règlement impose notamment la maîtrise du risque lié aux prestataires tiers de services TIC — c'est-à-dire précisément les éditeurs et ESN qui développent portails d'intermédiaires, outils commerciaux et applications mobiles internes. Les établissements les plus importants doivent en outre mener régulièrement des tests d'intrusion fondés sur la menace (TLPT), en France selon le cadre TIBER-FR piloté par la Banque de France ; des scénarios de reconnaissance assistée par l'IA ont toute leur place dans ces exercices.

Pour les audits eux-mêmes, beaucoup d'acheteurs privilégient des prestataires qualifiés PASSI par l'ANSSI, et en cas de fuite de données personnelles la notification à la CNIL sous 72 heures prévue par l'article 33 du RGPD s'applique en parallèle. Pour une fintech ou un éditeur qui fournit des banques françaises, tests réguliers de ses propres applications, preuves de correction et procédure de signalement claire deviennent des prérequis dans les appels d'offres.

Check-list de durcissement des applications financières exposées sur Internet

  1. Recenser tout ce qui est joignable. Y compris portails partenaires et intermédiaires, API mobiles des salariés, outils marketing et commerciaux, et environnements de recette oubliés.
  2. Imposer l'authentification côté serveur sur chaque route. Aucun contrôle côté client, aucun endpoint « caché », une autorisation au niveau de l'objet pour chaque consultation d'enregistrement.
  3. Bloquer le credential stuffing. MFA résistante au phishing pour les salariés, limitation de débit et détection de bots à la connexion, vérification des mots de passe compromis.
  4. Ne renvoyer que le minimum. Réduire les réponses d'API à ce dont chaque écran a besoin ; masquer par défaut identifiants et champs financiers.
  5. Tester en continu. Scans automatisés dans la CI et de façon planifiée, plus des tests d'intrusion manuels sur chaque nouveau service exposé avant sa mise en ligne.
  6. Surveiller les comportements agentiques. Alerter sur les sondages systématiques et massifs de nombreux endpoints et sur les énumérations inhabituelles d'identifiants.

Questions fréquentes

Que s'est-il passé dans les banques sud-coréennes ?

Entre le 1er et le 5 octobre 2026, sept établissements financiers sud-coréens ont confirmé des fuites de données : Shinhan Bank, KB Kookmin Bank, Hana Bank, BNK Busan Bank, Yegaram Savings Bank, Welcome Savings Bank et Hyundai Capital. Selon le Korea Herald, environ 66 000 particuliers et 2 200 dossiers d'entreprises ont été exposés : noms, numéros de téléphone, numéros d'enregistrement de résident, revenus annuels et plafonds de crédit. Shinhan a déclaré à elle seule environ 25 700 clients concernés.

L'IA a-t-elle vraiment été utilisée dans ces attaques ?

C'est un soupçon, pas une certitude. Bloomberg, citant Yonhap, a rapporté le 2 octobre que des outils d'IA étaient soupçonnés dans le piratage de Shinhan, et des chercheurs ont trouvé sur un serveur lié à l'intrusion un titre de page en chinois signifiant à peu près « console de test d'intrusion autonome par IA ». Cette chaîne est associée à ARTEX, un framework open source de test d'intrusion fondé sur des LLM. Le président Lee Jae Myung a évoqué des signes d'usage de l'IA, mais les autorités n'ont pas officiellement confirmé l'outil.

Comment les attaquants sont-ils entrés ?

Les points d'entrée signalés étaient des systèmes périphériques exposés sur Internet, et non le cœur bancaire : un contournement d'authentification sur le service de suivi des dossiers des intermédiaires de crédit de Shinhan, des accès externes anormaux à un système mobile destiné aux salariés de KB Kookmin et une tentative d'accès non autorisé au système d'appui commercial de Hana Bank. La presse locale évoque aussi du credential stuffing, c'est-à-dire des connexions automatisées avec des mots de passe volés.

Que doivent faire les équipes fintech aux États-Unis et dans l'UE ?

Recenser toutes les applications accessibles de l'extérieur, y compris les portails partenaires, les pages de suivi pour intermédiaires et les back-ends mobiles des salariés ; imposer l'authentification et l'autorisation côté serveur sur chaque endpoint ; ajouter limitation de débit et défenses contre le credential stuffing ; réduire au minimum les données personnelles renvoyées ; et tester en continu, car des attaquants assistés par l'IA balaient une large surface d'attaque bien plus vite qu'un cycle annuel de tests d'intrusion.

Sources

Bloomberg — AI Tools Suspected in Korea’s Shinhan Bank Hack, Yonhap Says (2 octobre 2026)
The Korea Herald — Police launch major probe as suspected AI hacks sweep through banks (6 octobre 2026)
The Korea Times — Shinhan, Kookmin, Hana data breaches fuel concerns over AI-powered cyberattacks (2 octobre 2026)
BleepingComputer — South Korea probes bank breaches amid suspected AI-powered attacks (5 octobre 2026)