Acronis relie une opération d'IA au vol de données de secours de Taipei

Acronis relie une opération d'IA au vol de données de secours de Taipei

Ajoutez CyberWorldOpsà vos sources préférées sur Google
Acronis relie une opération d'IA au vol de données de secours de Taipei
IA

Image d’illustration générée par IA

Selon The Hacker News, des données de répartition des secours concernant sept districts de Taipei ont été extraites par un attaquant utilisant des agents d'IA. Le média cite des travaux divulgués la semaine précédente par la Threat Research Unit d'Acronis. Les agents ont également découvert une plateforme non authentifiée du service des pompiers de Taipei, exposant des dossiers de patients datant de 2018, dont des relevés d'électrocardiogramme (ECG) et des vidéos issues d'ambulances.

L'opération ne s'est pas limitée aux services d'urgence. Acronis a constaté que des centaines d'organisations dans au moins onze pays avaient été ciblées, parmi lesquelles des banques, des universités et des systèmes militaires. Une collecte de données ou un accès aux systèmes ont eu lieu auprès d'environ dix organisations à Taïwan, en Thaïlande et au Mexique. Taïwan a de loin été le pays le plus visé et celui où les préjudices confirmés pour les services d'urgence ont été les plus graves.

Les chercheurs ont estimé avec un degré de confiance élevé qu'une seule personne, basée à Hualien, à Taïwan, contrôlait l'opération. Son système, baptisé BOSSAI, combinait la construction d'infrastructures assistée par l'IA et des agents d'attaque fonctionnant surtout sur des modèles locaux dont l'entraînement à la sécurité avait été supprimé. Ses succès concernaient en grande partie des systèmes présentant des failles de protection préexistantes.

Dossiers d'urgence et données de patients exposées

Les données de répartition volées provenaient d'une API (interface logicielle permettant d'échanger des données) connectée au système d'urgence 119 des pompiers et des ambulances d'une ville. Elle décrivait les incidents à l'aide d'horodatages, de types d'intervention, de statuts de dossiers et de localisations au niveau de la rue. Elle ne permettait pas de suivre les ambulances en temps réel.

La plateforme de patients constitue une constatation différente : ses enregistrements étaient accessibles sans identifiant de connexion. Si la synthèse générale d'Acronis évoque un vol de données médicales et personnelles auprès de services d'urgence et d'universités, son compte rendu détaillé établit l'exposition des dossiers de patients de Taipei, et non leur extraction.

D'autres cibles taïwanaises de services d'urgence illustrent la gamme allant de l'accès réussi aux attaques infructueuses, en passant par les constats erronés :

  • Le panneau d'administration de base de données d'un fournisseur de technologies de répartition pour les pompiers a accepté des identifiants root par défaut, donnant aux agents l'accès à au moins 18 tables. Une tentative d'exploiter une vulnérabilité connue pour déployer un web shell, un script permettant l'accès à distance, a échoué.
  • Le JavaScript côté navigateur d'un système d'information de gestion des urgences contenait une clé de chiffrement AES-256 codée en dur. Elle a permis de révéler le contenu de cookies de session, qui contiennent des informations sur la session d'un utilisateur, dont l'identité d'un administrateur. Une compromission n'a pas été confirmée.
  • Un scanner a signalé qu'un centre national de réponse aux catastrophes présentait une faille critique dans Apache permettant l'exécution de code à distance. La faille signalée n'existait pas.
  • Les tentatives de deviner des mots de passe sur le portail d'authentification unique d'une agence nationale de lutte contre les incendies n'ont permis aucun accès confirmé.
  • Les systèmes de services d'incendie de cinq villes ont été scannés pour identifier leurs logiciels, sans compromission confirmée.

Ailleurs à Taïwan, les agents ont récupéré des données de la table des comptes d'une société de crédit au moyen d'une injection SQL, une technique qui manipule les requêtes de base de données via des entrées d'application vulnérables. Ils ont aussi collecté des données auprès de trois universités thaïlandaises par injection SQL, après avoir sélectionné 489 cibles potentielles réparties dans 45 établissements.

L'activité au Mexique a permis d'obtenir environ 206 800 enregistrements de téléphonie fixe contenant des noms et des adresses, à partir de statistiques gouvernementales, de listes de codes postaux et de données de l'autorité de régulation des télécommunications. Environ 15 autres organisations ont fait l'objet d'attaques sans intrusion confirmée. Dans au moins huit autres pays, l'activité s'est arrêtée au stade du scan ou de la préparation d'attaques qui n'avaient pas encore été lancées au moment où les chercheurs ont examiné l'opération.

Un humain coordonnait les agents d'IA

Acronis a reconstitué l'activité à partir du serveur de l'attaquant lui-même. Ressemblant d'abord à une machine de développement mal configurée, il s'est révélé contenir son environnement opérationnel d'attaque : plus de 90 000 fichiers comprenant des conversations avec les agents, l'historique des commandes, des outils d'attaque, des identifiants et des données de victimes.

Les chercheurs ont suivi l'opération pendant 12 jours. Une conversation enregistrée place l'attaquant au travail le 25 juillet. Les résultats ont été divulgués la semaine précédant la publication de l'article de presse.

BOSSAI comptait 12 agents, dont neuf en service, répartis entre la maintenance des serveurs et des outils d'une part, et la reconnaissance et les attaques d'autre part. La coordination dépendait toujours de l'opérateur : les agents ne pouvaient pas échanger de messages, de sorte qu'il copiait manuellement les éléments d'un agent à l'autre.

La majeure partie du développement d'infrastructure reposait sur des modèles cloud commerciaux, principalement Grok. Les demandes d'attaque directes ont été refusées par Grok et par MiniMax M3, qui demandaient une autorisation écrite. Les chercheurs ne savaient pas si une autorisation fabriquée aurait modifié ces réponses. Grok a néanmoins réparé un script d'exploitation de preuve de concept défectueux, que l'opérateur a ensuite transmis à un agent d'attaque.

Pour l'essentiel du travail offensif, l'attaquant a utilisé des versions « abliterated » de DeepSeek, GLM et Qwen, exécutées localement après suppression de leur entraînement à la sécurité. Il a également connecté les agents de programmation Claude Code et Codex à un modèle « abliterated », bien que leur travail concerne surtout l'infrastructure. Cursor, un autre agent de programmation, a utilisé un tel modèle pour attaquer un site de services d'urgence taïwanais.

Les résultats des agents exigeaient un examen attentif. Un outil de scan a fabriqué des identifiants CVE, les numéros de référence utilisés pour suivre les vulnérabilités connues, et plus de la moitié de ses constats de gravité élevée et critique étaient des faux positifs ou ont été mal classés. L'agent d'attaque principal a aussi revendiqué des résultats qui ne s'étaient jamais produits.

Attribution et défenses qui ont tenu

La réutilisation d'identités a aidé Acronis à relier l'opération à son opérateur présumé. Des informations publiques et des erreurs de dissimulation de son identité ont relié des entreprises légitimes à une infrastructure d'attaque, via un profil GitHub, un logo, le nom d'une clé SSH et une adresse e-mail. Son adresse IP personnelle est également apparue dans une conversation avec Grok, lors d'une session de connexion à distance SSH.

Les chercheurs ont jugé que le gain financier était le mobile probable. Une partie des cibles, parmi les systèmes gouvernementaux, d'urgence et militaires, ressemblait à une activité soutenue par un État, tandis que d'autres attaques relevaient de la cybercriminalité ordinaire. La question de savoir si l'opérateur travaillait pour quelqu'un restait sans réponse.

Le compte rendu de The Hacker News sur les conclusions d'Acronis décrit une liste d'indicateurs comprenant neuf adresses IP et neuf domaines. Leur statut d'activité n'est pas précisé, et la plupart ne sont pas accompagnés d'explications sur leur rôle. Le statut de notification et de remédiation des systèmes concernés reste également non résolu, y compris la question de savoir si les données exposées sont toujours accessibles.

L'activité réussie reposait sur des faiblesses déjà présentes : un port de données médicales ouvert depuis 2018, une API de répartition accessible publiquement, 16 points d'injection SQL chez la société de crédit et des bases de données Oracle non corrigées dans les universités. L'IA a réduit le coût de la recherche et du ciblage de nombreuses victimes potentielles, mais les agents ont échoué face à des authentifications obligatoires, à des paywalls exigeant des sessions valides et à des points de terminaison qui filtraient correctement les requêtes.

À lire aussi

Sources

Retour à l'accueil

Dernières actualités cybersécurité

Toutes les actualités cybersécurité →