Le 7 octobre 2026 vers 3 h 40 (heure du Japon), le fournisseur de cloud japonais IDC Frontier, filiale de SoftBank, a subi une attaque par ransomware sur sa région Est du Japon 1. Selon l’entreprise, 495 sociétés et collectivités sont touchées et, dans quatre zones, les données des clients sont jugées difficiles à récupérer. Voici ce que l’on sait, ce que les attaquants affirment sans preuve et ce que cet incident rappelle sur les sauvegardes chez un fournisseur cloud.
Ce qui s’est passé
IDC Frontier a d’abord annoncé un accès non autorisé, puis a parlé dans son deuxième communiqué, le jour même, d’une attaque par ransomware. La société a coupé le réseau de la région Est du Japon 1 et arrêté ses systèmes pour limiter les dégâts, puis suspendu sa console de gestion accessible de l’extérieur, d’après @IT. Elle travaille avec des sociétés de sécurité externes et a signalé l’incident au ministère de tutelle et à la police de Tokyo, d’après Japan Cyber Watch.
La voie d’entrée, l’identité des attaquants et une éventuelle demande de rançon ne sont pas connues à ce jour.
Quatre zones touchées, des données difficiles à restaurer
Le troisième communiqué, du 8 octobre, a désigné quatre zones de la région Est du Japon 1 : tesla, henry, pascal et joule. IDC Frontier y juge les données des clients difficiles à extraire ou à restaurer, sauf à partir de sauvegardes détenues par les clients eux-mêmes. Les zones radian et newton, les régions Est 2 et 3 et la région Ouest 1 n’ont montré aucun accès non autorisé confirmé. IDCF Cloud TypeS et IDCF Private Cloud ne sont pas concernés, d’après Japan Cyber Watch.
Le 14 octobre, cinquième communiqué : les snapshots se sont révélés intacts et peuvent être récupérés pour 194 des 495 clients, ceux qui avaient activé cette fonction. Les 301 autres dépendent de leurs propres sauvegardes, et la possibilité de restaurer est discutée au cas par cas. Le 18 octobre, la sauvegarde d’IDCF Cloud a repris pour les zones et régions non touchées, mais la fonction de snapshot reste suspendue.
Des données volées ? Une réponse fondée sur l’absence de traces
IDC Frontier affirme n’avoir trouvé aucune trace montrant que les données des serveurs virtuels des clients aient été consultées ou emportées, et conclut à l’absence de fuite. Cette conclusion repose sur l’absence de traces, et la durée couverte par les journaux n’est pas précisée. Par ailleurs, les informations de compte de 48 clients sur le portail IDCF Cloud (identifiants de connexion, empreintes de mots de passe et adresses e-mail de contact) ont été consultées à tort.
Sur les réseaux sociaux, une image imitant la console d’IDCF Cloud, avec le message « YOUR CLOUD IS OURS », revendique 239 hyperviseurs atteints, 225 datastores chiffrés, plus de 16 600 disques de machines virtuelles et 554 153 snapshots. IDC Frontier n’a pas confirmé ces chiffres, dit que l’image semble correspondre à ce qu’affichait sa console, et aucun groupe de ransomware n’est nommé, d’après @IT. D’autres médias reprennent le chiffre de 225 « bases de données » pour 3,6 Po, comme l’a rapporté SC Media : la formulation diffère selon les sources et reste une affirmation de l’attaquant.
Les conséquences chez les clients
Plusieurs grands noms japonais figurent parmi les clients touchés, selon les communiqués relayés par Japan Cyber Watch :
- JR East et View Card : données d’un service d’envoi d’e-mails, jusqu’à environ 6,09 millions d’enregistrements. Ils ne peuvent pas exclure une consultation ou un vol. Leurs avis n’avaient pas été actualisés au soir du 15 octobre.
- JR Kyushu (environ 1,3 million) et JR Central (environ 15 000) : aucune fuite confirmée au 15 octobre, d’après l’enquête d’IDC Frontier.
- Peach Aviation : environ 1,89 million d’enregistrements dans le système concerné, sans fuite confirmée.
- Nissui Logistics : expéditions et réceptions perturbées, retour à la normale attendu la semaine suivante selon son avis du 14 octobre. Un lien direct avec IDCF n’est pas établi dans les sources que nous avons lues.
- Préfectures et communes : plusieurs sites de collectivités sont tombés le 7 octobre. Aucune source officielle ne reliait toutes ces pannes à l’attaque ; la préfecture d’Ibaraki a d’abord évoqué une panne d’électricité.
Les leçons pour vos sauvegardes
- Gardez au moins une copie hors de l’infrastructure de votre fournisseur, et testez régulièrement la restauration. Ici, les clients sans copie externe n’avaient pour recours que les snapshots hébergés au même endroit, retrouvés intacts pour 194 d’entre eux seulement.
- Ne confondez pas snapshot et sauvegarde : un snapshot hébergé chez le même fournisseur partage son sort en cas de compromission de l’infrastructure.
- Changez le mot de passe de votre portail cloud, et ceux que vous réutilisez ailleurs, si vous faites partie des comptes consultés.
- Méfiez-vous du phishing qui usurperait JR East, View Card, JR Kyushu, JR Central, Peach ou Takashimaya : passez par les sites ou applications officiels plutôt que par des liens reçus par e-mail.
Et si vous n’êtes pas client d’IDC Frontier ?
Le fond de l’affaire vaut pour tout hébergement : un fournisseur cloud peut subir une attaque qui détruit à la fois vos données et les copies qu’il conserve pour vous. Si vos données critiques n’existent que chez un seul hébergeur, la question à vous poser est de savoir où se trouve votre dernière copie indépendante et si vous savez la restaurer.
Sources : Japan Cyber Watch, @IT, Impress Watch et SC Media.
Questions fréquentes sur le ransomware d’IDCF Cloud
C’est le service de cloud d’IDC Frontier, filiale de SoftBank Group, qui héberge les serveurs virtuels d’entreprises et de collectivités au Japon.
495 sociétés et collectivités selon IDC Frontier. Les snapshots sont récupérables pour 194 d’entre eux, les 301 autres dépendent de leurs sauvegardes.
IDC Frontier n’a trouvé aucune trace de vol de données dans les serveurs virtuels, mais cette conclusion repose sur l’absence de traces. Les comptes de 48 clients sur le portail ont, eux, été consultés.
On l’ignore. Une image diffusée sur les réseaux sociaux revendique l’attaque, mais aucun groupe n’est identifié et ses chiffres ne sont pas confirmés.
Conserver une sauvegarde testée hors de l’infrastructure de son fournisseur, car un snapshot chez le même hébergeur n’est pas une sauvegarde indépendante.
Laisser un commentaire