Un ransomware frappe IDCF Cloud au Japon et coupe 495 entreprises et collectivités de leurs données
Le 7 octobre 2026, un ransomware frappe IDCF Cloud, l’infrastructure d’IDC Frontier, filiale de SoftBank, et provoque une panne régionale qui coupe 495 entreprises et collectivités de leurs données. L’attaquant revendique 3,6 Po chiffrés et 16 000 disques de VM scellés, un rappel que le cloud de votre fournisseur est aussi un point de défaillance unique.
7 octobre 2026, 3 h 40. Un ransomware frappe IDCF Cloud, l’infrastructure de IDC Frontier, filiale du groupe SoftBank. 495 entreprises et collectivités locales japonaises sont coupées de leurs données. 3,6 Po de bases chiffrées et 554 153 snapshots effacés, selon la revendication de l’attaquant. Pourquoi c’est important : un fournisseur de cloud est un point de défaillance unique, et cette attaque en montre le prix exact.
Une panne régionale, des consoles coupées partout
IDC Frontier a confirmé l’incident sans détour : « notre enquête a établi qu’une perturbation dans la région Est-Japon 1 a été causée par une attaque par ransomware d’un tiers. » L’attaque a démarré le 7 octobre à 3 h 40, heure locale, et a forcé l’arrêt du réseau et des systèmes de la région concernée.
La réponse de l’opérateur est notable. IDC Frontier a isolé et mis hors tension les systèmes touchés de la région Est-Japon 1 pour empêcher la propagation, puis a désactivé l’accès aux consoles de gestion pour toutes les régions — pas seulement la région touchée — le temps de vérifier leur sécurité. L’accès ne sera rétabli qu’une fois la sécurité confirmée. C’est la bonne décision de confinement, mais elle a un coût immédiat : même les clients d’autres régions perdent temporairement la main sur leurs ressources.
L’attaque touche 495 entreprises et collectivités. IDCF Cloud loue des serveurs virtuels, du stockage et du réseau à des clients qui y font tourner sites, applications et systèmes métier dans des datacenters japonais — un profil de clientèle où l’on trouve de l’administration publique, pour qui une panne de cloud est aussi une panne de service public.
Ce que l’attaquant revendique
Avant que les clients ne soient verrouillés hors de la console, des captures d’écran ont circulé montrant le message de l’acteur malveillant. Ses chiffres, s’ils sont exacts, donnent l’ampleur de la compromission.
- 7 minutes pour pénétrer l’infrastructure de la région Est-Japon 1.
- 225 bases de données chiffrées, représentant 3,6 Po de données.
- 239 hyperviseurs atteints.
- 16 000 disques de machines virtuelles scellés.
- 554 153 snapshots effacés.
La vitesse revendiquée — sept minutes pour passer de l’intrusion au chiffrement massif — est le détail le plus inquiétant. Elle ne correspond pas à un acteur qui tâtonne : elle suggère une compromission préparée, avec des accès déjà en main ou un chemin d’escalade maîtrisé d’avance. Ce type de déroulé est devenu la norme des groupes de ransomware matures, qui automatisent l’exfiltration et le chiffrement une fois le point d’appui obtenu.
IDC Frontier n’a pas confirmé ces chiffres et indique poursuivre l’enquête sur la cause précise et l’étendue de l’impact. Le fait que les consoles de toutes les régions soient coupées montre que l’opérateur lui-même n’a pas encore une image complète de ce qui a été touché.
Un fournisseur cloud est un point de défaillance unique
L’incident illustre un risque que beaucoup d’équipes sous-estiment : la concentration sur un seul fournisseur. Vos sauvegardes dans le cloud, vos VM et vos snapshots sont chez le même opérateur que vos charges de production. Si l’opérateur est compromis, l’attaquant peut atteindre les trois d’un coup — ce que la revendication décrit précisément, entre disques scellés et snapshots effacés.
L’effet domino dépasse déjà le périmètre d’IDCF Cloud. Le groupe agroalimentaire Nissui, environ 11 500 salariés, a annoncé que sa filiale logistique Nissui Logistics subissait une panne système due à un accès non autorisé présumé sur un datacenter tiers qu’elle utilise, bloquant expéditions et réceptions. Le lien avec l’attaque d’IDCF Cloud n’est pas établi, mais le mécanisme est le même : une organisation peut être paralysée par une attaque qui ne la visait pas directement, simplement parce qu’elle partage un fournisseur avec la cible.
C’est la leçon de fond : la résilience ne se décrète pas après coup, elle se conçoit dans l’architecture — sauvegardes hors du périmètre du fournisseur, reprise testée, et pour les charges critiques, une seconde région ou un second fournisseur.
Un contexte japonais en dégradation rapide
L’attaque s’inscrit dans une tendance que les chiffres de Macnica rendent tangible. Le chercheur Yutaka Sejiyama comptabilise 119 incidents de cybersécurité impliquant vol de données personnelles ou exposition de données au Japon depuis le début de l’année, dont 83 entre le 1er juillet et le 6 octobre. À titre de comparaison, Macnica en recensait 84 sur toute l’année 2025, et 62 sur 2024.
L’analyse de ces incidents pointe des attaquants qui sondent sites et API à la recherche de faiblesses de contrôle d’accès, de configuration et d’authentification, et qui exploitent des vulnérabilités connues — les n-day. Sejiyama relie cette accélération à la montée d’outils d’IA capables et bon marché, qui rendent économiquement viable l’exploration large et détaillée de cibles qui, auparavant, ne valaient pas l’effort. Le ransomware contre IDCF Cloud n’est qu’un point dans cette courbe — mais un point qui pèse lourd, car il touche un fournisseur partagé.
La réponse à chaud, côté client
Quand un fournisseur de cloud est compromis, le client a peu de leviers sur la cause, mais beaucoup sur les conséquences. Le déroulé des premières heures se joue en trois temps.
D’abord, couper et préserver. Tant que l’opérateur n’a pas confirmé l’étendue de l’intrusion, la prudence veut qu’on suspende les intégrations qui écrivent vers le fournisseur — pipelines de sauvegarde, réplications, synchronisations. Un attaquant qui a la main sur les hyperviseurs peut aussi atteindre ce qui arrive en continu. Préserver, c’est aussi figer les journaux et les captures qui permettront plus tard de comprendre ce qui a été touché.
Ensuite, vérifier les sauvegardes ailleurs. La revendication — disques scellés et snapshots effacés — rappelle que les sauvegardes hébergées chez le même opérateur ne sont pas des sauvegardes. Le test réel, c’est de restaurer un échantillon depuis un stockage hors du périmètre du fournisseur et de mesurer le temps que ça prend. C’est cette durée, et non l’existence du backup, qui détermine votre reprise.
Enfin, communiquer tôt. Les 495 organisations touchées ne sont pas toutes des victimes de chiffrement : certaines ne subissent que la coupure de la console. Dire vite ce qui est affecté — et ce qui ne l’est pas — évite qu’une panne de fournisseur devienne une crise de confiance avec vos propres clients.
Le point commun de ces trois réflexes : aucun ne dépend de la rapidité de l’enquête de l’opérateur. C’est ce qui les rend utiles.
Verdict
Si vous êtes client d’IDCF Cloud ou d’un fournisseur comparable, l’incident doit déclencher une vérification immédiate : confirmez que vos sauvegardes sont hors du périmètre de l’opérateur, et testez que vous pouvez réellement les restaurer — une sauvegarde scellée par le même ransomware ne vaut rien. Si vos charges critiques dépendent d’une seule région d’un seul fournisseur, c’est le moment de chiffrer le coût d’une bascule et d’en préparer une, même réduite. Pour tout le monde, retenez la vitesse revendiquée : sept minutes entre l’intrusion et le chiffrement massif ne laisse aucune place à une réponse improvisée — la seule parade crédible est une architecture qui survit à la compromission du fournisseur, pas un plan de réaction plus rapide.