Fuite de données GMO : ce que l’on sait de l’incident

Les principales étapes de l'incident

• 21 octobre : GMO ferme Onamae Desktop Cloud après avoir découvert un accès non autorisé. L'entreprise reçoit une demande de rançon d'environ 8 milliards de yens.
• 22 octobre : elle signale l'incident à la police japonaise et publie une mise à jour.
• 24 octobre : GMO annonce une indemnisation possible pour ses clients et une solution de service alternative, tout en sollicitant l'aide d'organismes publics.
• 25 et 26 octobre : l'entreprise commence à récupérer des appareils auprès de clients pour rechercher d'éventuels logiciels malveillants et mieux évaluer les impacts.
• 27 octobre : GMO indique qu'un attaquant présumé a publié des informations présentées comme liées à l'entreprise et à ses clients. Leur authenticité restait à vérifier.

Deux chantiers avancent souvent en même temps dans ce type de crise : remettre un service ou fournir un remplacement, et, parallèlement, préserver ce qui peut aider l'enquête. Revenir trop vite en production sans comprendre comment l'intrusion s'est produite, c'est le risque de rouvrir la porte. À l'inverse, couper trop longtemps peut coûter cher côté activité, surtout quand les postes concernés servent à des opérations financières.

Une publication alléguée n'est pas une fuite vérifiée

Le vocabulaire compte. GMO parle de la publication d'informations présentées par l'attaquant comme liées à l'entreprise et à ses clients. Mais le groupe disait aussi vérifier si ces données étaient authentiques. Il faut donc distinguer la publication alléguée, la preuve d'un accès non autorisé, et l'identification des données réellement consultées ou dérobées.

Cette nuance ne rend pas l'incident « moins grave ». Elle évite simplement de transformer une affirmation de l'attaquant en fait établi. Pour un client, la bonne approche consiste à réduire le risque immédiatement et à s'en tenir aux éléments vérifiés, sans publier comme certain une liste de données dont l'origine n'est pas confirmée.

Ce que l'on peut dire - et ce qu'il faut encore vérifier

À ce stade, les éléments rapportés permettent de retenir :

• un accès non autorisé à des systèmes associés au service Onamae a été détecté ;
• GMO a arrêté le service et lancé des vérifications ;
• le groupe estime que jusqu'à 27 000 serveurs pourraient être concernés ;
• des clients signalent des opérations inhabituelles sur des comptes de trading ;
• des données présentées comme liées à GMO et à ses clients ont été publiées par un attaquant présumé, avec authenticité encore à confirmer ;
• GMO propose une indemnisation et un service alternatif, et commence à récupérer des appareils pour rechercher des logiciels malveillants.

En revanche, il n'est pas possible, avec les informations disponibles, d'établir clairement :

• quelles catégories de données ont réellement été exposées ;
• le nombre de personnes touchées ;
• comment l'intrusion a commencé ;
• si des logiciels malveillants ont été installés sur des appareils clients.

Et rien ne confirme, pour l'instant, que les 27 000 serveurs ont tous été accessibles à des fins malveillantes.

Pourquoi cette nuance change la réponse des clients

Une communication de crise utile doit être à la fois assez rapide pour permettre d'agir, et assez précise pour ne pas pousser à des décisions prématurées. Concrètement, pour une organisation cliente, il faut distinguer les mesures prudentes - changer un mot de passe réutilisé, contrôler les opérations, renforcer l'authentification - des décisions qui exigent des faits vérifiés, par exemple notifier des personnes sur la base d'une catégorie de données précise.

Si vous utilisez un service concerné, consignez ce que vous savez : la date, la source et ce qui est réellement affirmé (signalement, hypothèse, confirmation). Ça paraît administratif, mais ça évite les confusions pendant la crise. Et ça aide ensuite à produire une évaluation cohérente pour la direction, les équipes techniques, les clients, et, si nécessaire, les autorités.

L'authentification multifacteur réduit un risque, sans être une baguette magique

Le contexte plus large mentionné dans les informations disponibles évoque Artex, un outil de tests d'intrusion incluant des fonctions d'intelligence artificielle. L'équipe cybersécurité de GMO avait signalé séparément des indices d'utilisation d'Artex dans des attaques visant des entreprises japonaises. Un rapport de CrowdStrike associe aussi Artex à des attaques contre des institutions financières en Corée du Sud en septembre. D'après ces éléments, certaines attaques profitaient de contrôles faibles, notamment l'absence d'authentification multifacteur.

Cela ne prouve pas qu'Artex soit à l'origine de l'incident Onamae. GMO n'a pas établi publiquement de lien entre ces événements. Il faut donc éviter l'erreur classique : rapprocher deux faits dans le temps, remarquer l'usage d'un outil dans d'autres attaques, puis en déduire une attribution. La présence d'un outil dans une enquête ne suffit pas à identifier l'auteur ni la méthode exacte de l'intrusion.

Quand l'authentification multifacteur manque (et qu'on le constate), certains scénarios de compromission d'identifiants deviennent plus faciles. L'activer sur les comptes sensibles est une base solide, mais ça ne remplace pas la gestion des vulnérabilités, la limitation des privilèges, ni la surveillance des connexions. Au Japon, le régulateur des services financiers a d'ailleurs demandé aux établissements de renforcer les défenses de base : gestion des vulnérabilités, défense en profondeur, et préparation aux incidents.

Le sujet concerne aussi les entreprises européennes

Pour une entreprise française ou européenne, l'incident rappelle un point assez simple : confier le poste de travail ne supprime pas la responsabilité opérationnelle. Le fournisseur gère une partie de l'infrastructure, mais le client doit savoir quels comptes ont accès au service, quelles données y circulent, comment les accès sont protégés et qui décide en cas d'interruption.

Cette préparation devient cruciale quand les services cloud supportent des activités sensibles : trésorerie, traitement de commandes, accès à des environnements de production, ou relation avec des clients. Avoir une dépendance documentée, des contacts d'escalade et une procédure de continuité permet d'agir plus vite qu'avec une simple liste de fournisseurs.

Dans le cadre européen, les obligations applicables dépendent du rôle exact de l'organisation, des données concernées et des circonstances. On ne peut donc pas déduire une obligation précise uniquement à partir des informations publiées sur GMO.

1. Vérifier le périmètre et désigner un responsable

Commencez par identifier ce qui dépend concrètement du service : équipes, comptes, appareils, opérations. Désignez une personne responsable de la coordination entre informatique, sécurité, métiers, juridique et direction. Centralisez les échanges avec le fournisseur : annonces officielles, demandes d'action et réponses reçues. Évitez que chaque équipe mène sa propre enquête sans partager ce qu'elle apprend.

Distinguez ce qui est indispensable de ce qui est secondaire. Un compte utilisé pour des opérations financières ou des environnements de production ne se traite pas comme un compte de test. Cette cartographie sert ensuite à prioriser les actions si le service reste indisponible.

2. Sécuriser les identifiants et les opérations sensibles

Suivez les consignes du fournisseur, notamment s'il recommande de changer les mots de passe. Si un mot de passe utilisé pour le service a été réemployé ailleurs, changez-le aussi sur les autres comptes concernés. Activez l'authentification multifacteur quand c'est possible, en priorité pour les comptes administrateurs, les accès distants et les comptes liés aux paiements ou au trading.

Passez aussi en revue les connexions récentes et les opérations inhabituelles. Pour les comptes financiers, mettez en place une validation renforcée par une personne indépendante avant d'exécuter des transactions, si nécessaire. Oui, ça peut ralentir. Mais c'est souvent préférable à une perte difficile à réparer quand des activités anormales ont déjà été signalées.

3. Préserver les preuves avant de nettoyer

Ne réinitialisez pas les appareils et ne supprimez pas les journaux sans coordination avec les équipes compétentes. Ces gestes peuvent effacer des éléments utiles pour comprendre l'incident. Notez les heures, les alertes, les comptes concernés, les demandes du fournisseur et les actions déjà prises. Si un appareil paraît suspect, isolez-le du réseau selon votre procédure interne, puis faites analyser la situation.

Le principe est simple : contenir sans détruire les traces. C'est d'ailleurs la logique de la récupération d'appareils engagée par GMO, qui vise à rechercher des logiciels malveillants et à mieux comprendre les impacts. Côté client, conserver des journaux et une chronologie propre facilite le diagnostic et évite des décisions fondées sur des souvenirs incomplets.

4. Préparer une solution de continuité et documenter les décisions

Si le service est indisponible, activez une solution de remplacement déjà évaluée. Le mode dégradé doit préciser qui peut autoriser les opérations, comment les données sont protégées et comment vous contrôlez le retour à la normale. Une alternative improvisée peut déplacer le risque vers des appareils personnels ou des échanges mal maîtrisés.

Enfin, consignez les raisons de chaque décision et les informations sur lesquelles elles reposent. Si des données personnelles ou des activités réglementées sont possiblement concernées, faites valider les obligations applicables par les responsables compétents. La notification ne se décide pas sur la seule base d'une publication revendiquée par un attaquant : elle dépend de faits vérifiés et du cadre juridique.