Des agents IA offensifs ont visé plus de 2 250 clients Microsoft 365 : ce qu'un DSI doit vérifier

Ce qui s'est passé

Le 15 octobre 2026, des informations publiques signalent un incident chez ConnectWise, éditeur de logiciels de gestion informatique très utilisés par les prestataires de services. Le 16, ConnectWise publie un premier avis. Le 21, Microsoft publie son analyse : l'acteur qu'il nomme Storm-0940, qu'il décrit comme aligné sur l'État chinois, a utilisé un accès non autorisé au service ConnectWise Cloud Backup pour tenter de se connecter à plus de 2 250 locataires Microsoft 365, avec les identités d'applications ConnectWise que ces clients avaient autorisées. L'attribution est une évaluation de Microsoft.

L'outil employé s'appelle ARTEX : un cadre de test d'intrusion open source, multi-agents, capable de s'appuyer sur n'importe quel modèle d'IA pour automatiser la reconnaissance, les attaques par mots de passe et l'abus d'applications. Selon Microsoft, plusieurs attaques ont abouti à des accès privilégiés au cloud, dans certains cas moins de trois heures après le premier ciblage.

Ce qui est établi, et ce qui ne l'est pas

Établi par Microsoft. Dans plusieurs environnements, l'attaquant a mené une reconnaissance par Microsoft Graph, ajouté des identifiants à des applications pour conserver un accès, et tenté de modifier des identités, des groupes et des rôles privilégiés. Une application ConnectWise s'est attribuée le rôle d'administrateur global. Des lectures massives de secrets dans plusieurs coffres Key Vault ont été observées.

Pas établi. Une fuite de données. Microsoft écrit que la présence d'une application concernée ou une connexion réussie « n'indique pas nécessairement » un accès aux données ou leur exfiltration, et que la majorité des tentatives a échoué. Les systèmes de Microsoft eux-mêmes n'ont pas été compromis.

Pourquoi c'est un sujet de direction

Deux choses changent. La vitesse d'abord : quand des agents enchaînent reconnaissance et escalade de privilèges en quelques heures, une revue mensuelle des accès arrive après la bataille. La porte ensuite : aucune faille de Microsoft n'a été exploitée. L'attaquant est entré par une confiance déjà accordée, une application tierce autorisée dans l'annuaire avec des permissions larges, qui agit sans connexion humaine, donc sans double authentification.

La plupart des entreprises savent combien elles ont de salariés. Peu savent combien d'applications et d'agents ont le droit d'agir dans leur environnement, avec quelles permissions, et qui les a autorisés.

Ce que Microsoft demande de vérifier

• Rechercher les applications concernées par leur identifiant d'application, et non par leur nom affiché, dans chaque locataire où elles sont ou ont été autorisées.
• Conserver les journaux de connexion et d'audit Entra, les enregistrements Purview et les données du SIEM avant toute modification.
• Relire les connexions des principaux de service au moins depuis le 15 octobre 2026, et depuis le 1er octobre si les journaux existent, sans se limiter aux adresses IP publiées.
• Auditer les ajouts d'identifiants, les nouvelles applications ou nouveaux propriétaires, les consentements, les attributions de rôles privilégiés et les changements d'accès conditionnel.
• Ne pas supprimer l'application d'entreprise en premier réflexe : Microsoft demande de préserver la configuration et les preuves avant tout changement irréversible.

Ce qu'une équipe bien outillée fait différemment

Elle tient un registre vivant des applications et des agents qui agissent dans son environnement, avec leurs permissions et un responsable nommé. Elle surveille en continu les authentifications d'applications à privilèges élevés et les ajouts d'identifiants. Et elle sait prouver après coup ce qui a été vu, quand et par qui, parce que ses journaux ont été conservés et datés avant l'incident, pas reconstitués après.

C'est la logique du Cockpit : le registre des IA, avec la classe de risque de chaque système et l'historique de ses changements, et des preuves datées qu'un contrôleur ou un assureur peut vérifier.

Le danger	Le conseil
Les applications tierces autorisées dans votre annuaire ne sont inventoriées nulle part, ou seulement par leur nom.	Tenez un registre des applications et des agents autorisés, par identifiant d'application, avec leurs permissions et un responsable nommé.
Les connexions des applications, sans utilisateur et sans double authentification, ne sont relues qu'après un incident.	Surveillez en continu les authentifications d'applications à privilèges élevés et les ajouts d'identifiants, avec une alerte.
Le premier réflexe en cas d'alerte est de supprimer l'application suspecte.	Préservez d'abord la configuration et les journaux : sans eux, vous ne pourrez prouver ni l'étendue ni l'absence d'impact.