À la fin du mois dernier, la mention « ARTEX - console de test d’intrusion autonome » a été découverte sur un serveur web utilisé lors de cyberattaques visant des établissements financiers sud-coréens, dont Shinhan Bank (신한은행). ARTEX est un outil de contrôle de sécurité fondé sur un grand modèle de langage (LLM, un modèle d’intelligence artificielle entraîné sur de grands volumes de documents et de données pour produire du texte et traiter des informations). Des articles s’appuyant sur les explications du secteur de la cybersécurité ont évoqué la possibilité que cet outil ait été détourné pour mener les attaques, mais il n’a pas été établi à quelle étape du processus ni pour quelle fonction il aurait été utilisé.

À la même période, des fuites de données personnelles ou des tentatives d’attaque ont été signalées dans le secteur financier, non seulement dans des banques, mais aussi dans des banques d’épargne, des sociétés de financement et des coopératives financières. La question importante soulevée par ces informations ne se limite pas à « l’IA a-t-elle piraté ces systèmes ? ». Des traces d’outils d’IA peuvent indiquer que les attaques ont été menées plus rapidement ou avec davantage de précision, mais il faut aussi examiner les vulnérabilités et l’état de gestion des systèmes qui ont pu les rendre possibles.

Contexte

Le projet ARTEX est un outil publié sur GitHub. En août dernier, il a remporté le concours de capacités offensives « Agent Plus » (에이전트 플러스), organisé par le centre de réponse aux incidents de sécurité de Baidu, en Chine. La découverte de mentions le concernant sur un serveur web utilisé dans les attaques constitue un indice d’un lien possible entre ARTEX et celles-ci. Toutefois, la seule présence du nom de l’outil sur un serveur ne permet pas de conclure qu’ARTEX a mené l’ensemble de l’attaque ou qu’il s’est introduit dans les systèmes de façon autonome, sans intervention humaine.

Le credential stuffing, présenté dans les articles comme le mode opératoire des attaques, consiste à saisir à répétition des identifiants et mots de passe diffusés illégalement sur le dark web, puis à se connecter pour dérober des données personnelles. Jusqu’ici, des robots automatisés saisissaient mécaniquement les identifiants de connexion en suivant des instructions préalablement rédigées par des pirates. La possibilité a été évoquée que des outils fondés sur des LLM aient cette fois exploré les vulnérabilités des systèmes et lancé les attaques, mais le rôle respectif des humains et de l’IA au cours de celles-ci n’a pas été révélé.

Hwang Seok-jin, professeur à l’Université Dongguk (동국대), a expliqué qu’une personne pouvait mettre cinq secondes à saisir des identifiants de connexion, contre une seconde pour un robot automatisé traditionnel et 0,3 à 0,5 seconde pour un agent d’IA. Il a également indiqué qu’un agent d’IA pouvait filtrer les comptes qui ne correspondent pas aux conditions du système, afin de rendre les attaques plus précises. Il s’agit d’une description des vitesses et des fonctionnalités possibles, et non d’une confirmation que cette vitesse ou ces fonctions ont effectivement été utilisées dans cette affaire.

Les articles consacrés au secteur financier ont également mis en évidence la nature commune des systèmes visés. Des services tels que celui de Shinhan Bank destiné aux courtiers en prêts n’appartenaient pas au système informatique central utilisé par les clients, mais à des systèmes auxiliaires et de soutien aux opérations. Selon les informations rapportées, leurs dispositifs de sécurité étaient relativement peu stricts, notamment parce qu’ils n’appliquaient pas l’authentification multifacteur. Kim Myung-ju, professeur à l’Université pour femmes de Séoul (서울여대), a estimé que le problème fondamental n’était pas l’utilisation ou non de l’IA, mais le défaut de gestion des vulnérabilités des systèmes auxiliaires des banques.

Ce que cela signifie

Selon les informations publiées dans le secteur financier, il a été confirmé que les données d’environ 25 000 clients de Shinhan Bank avaient été divulguées : noms, numéros de téléphone, revenus annuels, noms d’employeurs et une partie des numéros d’enregistrement des résidents. Des articles ont également fait état de fuites concernant 119 clients de Kookmin Bank (국민은행) et 89 clients de Hana Bank (하나은행). À Busan Bank (부산은행), les données de 11 employés d’une société de développement sous-traitante ont été exposées lors d’une tentative d’attaque contre un serveur web externe. Woori Bank (우리은행) et NH Nonghyup Bank (NH농협은행) auraient subi des attaques similaires, qui n’ont toutefois pas entraîné de fuite effective.

Dans le secteur financier secondaire, des articles ont rapporté la fuite des données d’environ 40 000 clients de Yegaram Savings Bank (예가람저축은행) et de celles de 146 courtiers en prêts de Hyundai Capital (현대캐피탈). La Fédération nationale des coopératives de crédit Saemaul Geumgo (새마을금고중앙회) et les services de finance coopérative de Nonghyup (농협 상호금융), entre autres, auraient réussi à repousser des tentatives d’accès similaires. Les établissements financiers ont expliqué que les systèmes attaqués étaient distincts des services de banque en ligne et mobile et que les informations sur les transactions financières, telles que les numéros de compte, n’avaient donc pas été divulguées. Cependant, les données exposées pouvant inclure des coordonnées, des revenus et des informations sur l’employeur, des craintes ont été exprimées quant à des préjudices secondaires, notamment des appels ou des SMS frauduleux prétendant connaître les détails d’une véritable demande de prêt.

Il est donc important non seulement de vérifier si des données ont été divulguées, mais aussi de se méfier des usurpations d’identité exploitant ces informations. Par exemple, même si un appel ou un SMS semble connaître les détails d’une demande de prêt que vous avez effectuée, il est plus prudent de ne pas déduire de ces seules informations que votre interlocuteur travaille pour un établissement financier. Selon les articles, les établissements financiers ont informé individuellement les clients concernés de la fuite et des moyens de prévenir les préjudices secondaires, et leur ont indiqué qu’ils indemniseraient intégralement les dommages résultant de cette fuite de données.

Plus largement, l’un des enjeux de cette affaire est qu’un système de soutien aux opérations ne peut pas être considéré comme peu risqué au seul motif qu’il ne s’agit pas du système informatique central destiné aux clients. Des services utilisés par les courtiers en prêts ou les employés peuvent eux aussi contenir des données personnelles et, si l’authentification y est relativement peu stricte, constituer une porte d’entrée pour les attaquants. En plus d’évaluer la vitesse et les capacités d’automatisation de l’IA, il pourrait être essentiel, pour éviter que de tels incidents se reproduisent, de déterminer quels systèmes sont accessibles depuis l’extérieur et comment les comptes et l’authentification sont gérés.

Cadre réglementaire et informations sur l’assistance

Selon le guide juridique interne, l’article 48, paragraphe 1, de la loi sur les réseaux d’information et de communication (정보통신망법) sert à déterminer si une personne dispose d’un droit d’accès légitime à un réseau d’information et de communication et si elle a dépassé le périmètre autorisé. Le fait de connaître un identifiant et un mot de passe ou d’avoir été autorisé à les utiliser par le passé ne suffit pas à établir que l’accès est toujours autorisé. Il convient d’examiner les circonstances concrètes, notamment les droits accordés par le fournisseur du service et le périmètre d’utilisation permis.

Par conséquent, les seuls articles indiquant qu’un outil appelé ARTEX a été repéré sur un serveur utilisé par les attaquants ne permettent pas de conclure à la responsabilité juridique d’un acteur précis ni à la constitution d’une infraction. Il faut examiner les circonstances de l’accès, les autorisations, les actes commis et les éléments de preuve. Le guide juridique rappelle également que la conclusion peut varier selon la législation en vigueur au moment des faits et les circonstances propres à chaque cas ; pour toute situation concrète, il faut donc vérifier les textes applicables et les éléments de preuve disponibles.

Les différences entre les articles

Les articles diffèrent par leur angle et le niveau de détail fourni. Ceux portant sur ARTEX se sont concentrés sur les mentions découvertes sur le serveur utilisé par les attaquants et sur la nature de l’outil, en soulignant qu’il n’est pas établi à quelle étape il aurait servi. Les articles consacrés à l’ensemble du secteur financier ont présenté des cas de fuite ou de blocage dans plusieurs établissements, ainsi que le nombre de personnes concernées dans certains cas et les catégories de données divulguées. Ces articles portent sur des aspects différents de l’affaire ; cela ne signifie pas que l’utilisation effective d’ARTEX ou l’ampleur totale des dommages aient été établies.

Ce qui est établi et ce qui reste à déterminer

Faits établis

  • Des articles ont rapporté que des mentions liées à ARTEX avaient été découvertes sur un serveur web utilisé lors des attaques.
  • ARTEX est un outil de contrôle de sécurité fondé sur un LLM et publié sur GitHub ; il a remporté un concours de capacités offensives en août dernier.
  • Des fuites de données personnelles ou des tentatives d’attaque externe ont été signalées dans plusieurs établissements financiers.
  • Certains systèmes de soutien aux opérations, comme le service de Shinhan Bank destiné aux courtiers en prêts, étaient distincts du système informatique central destiné aux clients et auraient eu un dispositif de sécurité relativement peu strict.
  • Le président Lee Jae-myung aurait été informé des fuites de données personnelles et de la situation des mesures prises par des établissements financiers et des organismes publics, et aurait ordonné une enquête approfondie ainsi que l’élaboration de mesures.

Ce qui reste à déterminer

  • À quelle étape de l’attaque ARTEX a-t-il été utilisé, et pour quelle fonction ?
  • Dans quelle mesure des personnes et l’IA sont-elles intervenues respectivement au cours de l’attaque ?
  • Comment seront établis le volume total des données personnelles divulguées et l’étendue des préjudices, une fois regroupés tous les cas rapportés ?
  • Y a-t-il eu d’autres tentatives d’attaque contre des établissements financiers qui n’ont pas été signalées publiquement ?

Ce que les lecteurs peuvent vérifier

  • Si l’établissement financier concerné vous a informé d’une fuite de données personnelles, vérifiez quelles informations sont concernées et prenez connaissance des mesures de prévention indiquées.
  • Même si un appel ou un SMS mentionne une demande de prêt ou des informations financières, ne faites pas immédiatement confiance à votre interlocuteur : vérifiez séparément l’identité qu’il prétend avoir et le moyen de le contacter.
  • Si vous soupçonnez un préjudice lié à l’utilisation de données divulguées, conservez les informations communiquées et les traces des échanges, puis vérifiez les procédures de signalement et d’indemnisation indiquées par l’établissement financier.

Références