Les accès décrits par Microsoft n'ont eu besoin ni du mot de passe ni de l'authentification multifacteur des utilisateurs. L'attaquant s'est authentifié au travers d'identités d'applications ConnectWise que des organisations avaient autorisées dans leur environnement Microsoft 365, ou tenant. Qui contrôle ces identités dispose, dans chacun de ces tenants, des permissions de l'application. Un outil de sauvegarde a besoin de droits étendus pour lire et restaurer les données, rappelait le 19 octobre Justin Kohler, de SpecterOps, cité par Infosecurity Magazine. Dans plusieurs cas de la campagne menée depuis septembre, moins de trois heures ont séparé le premier ciblage d'un accès privilégié, selon Microsoft, qui ne précise pas s'il s'agissait de clients de ConnectWise.

Le récit repose sur un billet de Microsoft Security Research et Microsoft Threat Intelligence, résumé le 22 octobre dans une brève d'ActuIA. Microsoft y « estime » que Storm-0940 est responsable de la compromission (traduit de l'anglais, comme les citations suivantes), sans publier de niveau de confiance. Le 19 octobre, ConnectWise écrivait dans un avis, cité par Infosecurity Magazine, ne pas pouvoir « discuter de l'attribution à ce stade ». Le 21 octobre, selon un second article du magazine, l'entreprise a pris acte des conclusions de Microsoft sur la page d'avis de son Trust Center, où elle écrit que les acteurs étatiques ciblent « de plus en plus la chaîne d'approvisionnement logicielle ». Sa page d'état ne mentionne ni Storm-0940, ni la Chine, ni l'IA.

ARTEX, un accélérateur après l'intrusion

Microsoft écrit que Storm-0940 a utilisé ARTEX pour accélérer la reconnaissance et le balayage, la pulvérisation de mots de passe (un même mot de passe courant essayé sur une série de comptes) et l'abus d'applications OAuth chez les victimes en aval. Le billet ne dit pas comment Storm-0940 a obtenu les identités d'application de ConnectWise. Il ne nomme aucun modèle d'IA. ARTEX « peut utiliser n'importe quel modèle d'IA » et conduit un test d'intrusion de la reconnaissance à l'exfiltration « avec peu d'interaction humaine », écrit Microsoft. La part humaine dans cette opération n'est pas précisée.

Dans un billet du 31 octobre 2024, Microsoft écrivait que Storm-0940 exploitait les identifiants obtenus par CovertNetwork-1658, un réseau d'appareils compromis entretenu par un acteur situé en Chine. Dans environ 80 % des cas, ce réseau ne tentait qu'une connexion par compte et par jour. La pulvérisation menée du 10 au 14 octobre 2026, que Microsoft relie à l'infrastructure de Storm-0940, a produit plus de 151 000 échecs contre 327 comptes de huit organisations. Cela fait en moyenne plus de 460 échecs par compte en cinq jours. Microsoft n'y a observé aucune authentification réussie.

Un outil publié en juillet et relié à des intrusions en Corée du Sud

ARTEX est un système multi-agents écrit en Go, publié en open source. Selon une note de la Cloud Security Alliance, il a été mis en ligne le 26 juillet 2026 par un développeur qui signe Autumn-27. CrowdStrike l'a relié début octobre à des intrusions dans des établissements financiers sud-coréens. Le 8 octobre, toujours selon la Cloud Security Alliance, le développeur a retiré le projet de GitHub et annoncé l'arrêt des mises à jour et le passage en code fermé. Une page du projet, avec des dossiers de code, reste pourtant publique sur GitHub au 22 octobre, sans licence affichée.

Microsoft dit avoir repéré des acteurs malveillants qui utilisent ARTEX « dans plusieurs régions du monde ». Il ne les nomme pas. ActuIA a décrit le 20 octobre une autre campagne, criminelle, menée avec des agents d'IA contre les sites de plus de 100 entreprises.

Microsoft compte des tentatives, Huntress des connexions réussies

Les 2 250 tenants sont des cibles. Microsoft écrit que Storm-0940 a utilisé ARTEX pour « tenter de se connecter à plus de 2 250 tenants », et que la majorité de ce ciblage a échoué. Il ne donne aucun nombre de tenants compromis. Une authentification réussie de l'attaquant « n'indique pas nécessairement » un accès aux données ou leur exfiltration, précise-t-il. Le titre de The Register, selon lequel la brèche de ConnectWise a « lâché des espions chinois sur 2 250 tenants cloud », va au-delà du billet.

Le chiffre de 2 900 par minute figure deux fois dans le billet. Il compte des tentatives de connexion pour l'activité postérieure à l'accès à ConnectWise. Il compte aussi des échecs, pour le pic du 11 octobre de la pulvérisation menée du 10 au 14 octobre. Celle-ci a précédé les premiers signalements publics, que Microsoft date du 15 octobre.

Les chiffres de terrain viennent de Huntress, éditeur de sécurité qui a examiné plus de 10 000 tenants équipés d'applications ConnectWise. Il comptait 162 tenants avec des connexions non autorisées confirmées le 16 octobre. Le 17 octobre, il relevait près de 1 000 tenants visés depuis une seule adresse IP, dont plus de 300 avec une connexion réussie. Dans une cinquantaine de tenants suivis par Huntress, des applications se sont attribué des rôles d'administration de l'annuaire, surtout celui d'administrateur Exchange. Huntress documente un seul cas d'auto-attribution du rôle d'administrateur général, qui donne tous les droits sur le tenant, par l'application Cloud Management de ConnectWise pour Teams.

ConnectWise a désactivé sept identités d'application

ConnectWise a d'abord signalé, le 16 octobre, des « tentatives » d'accès non autorisé à l'environnement Cloud Backup, l'ancien SkyKick. Le 17 octobre, l'éditeur a reconnu un accès non autorisé à des identités d'application. Il en a désactivé sept et révoqué les certificats des connexions concernées. SaaS Security et Cloud Management, intégrés à Cloud Backup, ont été suspendus. Le 19 octobre, tous les comptes et identifiants de l'environnement touché ont été réinitialisés.

Le rétablissement par phases a commencé le 21 octobre et doit durer « plusieurs jours ». Les archives de sauvegarde restent « chiffrées, isolées et préservées, sans indication de compromission », selon ConnectWise. Sa page d'état ne donne ni le nombre de partenaires ou de clients touchés, ni leur répartition géographique, ni la date de détection. L'entreprise a confié l'enquête à un cabinet tiers, qu'elle ne nomme pas.

Ce que Microsoft demande aux administrateurs Microsoft 365

Le billet de Microsoft donne des consignes que la page d'état de ConnectWise ne contient pas. Parmi les mesures immédiates qu'il recommande :

  • laisser désactivées les connexions ConnectWise touchées jusqu'aux instructions formelles de rétablissement ;
  • ne pas supprimer les applications d'entreprise en première réponse, afin de préserver la configuration et les preuves, et conserver les journaux de connexion et d'audit Microsoft Entra disponibles ;
  • examiner l'activité depuis au moins le 15 octobre 2026 et, quand les journaux existent, étendre au 1er octobre la revue des connexions des principaux de service (l'identité d'une application dans un tenant) ;
  • examiner séparément les connexions réussies et échouées des principaux de service, sans se limiter aux adresses IP publiées (144.172.64.128, 144.172.64.99 et 144.172.64.60, ainsi que trois adresses VPN : 187.15.88.186, 187.15.90.217 et 187.15.89.186) ;
  • auditer les ajouts d'identifiants, les nouvelles applications, les attributions de rôles et les consentements ;
  • supprimer les identifiants non autorisés confirmés seulement après avoir conservé les preuves.

ConnectWise indique que les jetons d'accès déjà émis « peuvent rester utilisables » jusqu'à leur expiration ou leur invalidation. L'entreprise a annoncé deux points par jour à partir du 22 octobre. Le 20 octobre, elle cherchait encore à « déterminer comment l'accès non autorisé s'est d'abord produit ».

Nos articles remonteront en priorité dans « À la une » de Google.