Par Tsuky 
Le problème commence avec une relation de confiance. Une entreprise autorise un fournisseur spécialisé à accéder à certaines fonctions de son environnement Microsoft 365 pour sauvegarder ses données. Le fournisseur obtient des permissions techniques qui lui permettent de travailler sans demander à un employé de se reconnecter pour chaque opération.
Cette architecture est indispensable à de nombreux services cloud. Elle devient aussi dangereuse lorsqu'un attaquant récupère les identifiants associés à ces permissions.
C'est le mécanisme au cœur de la cyberattaque contre ConnectWise Cloud Backup, anciennement SkyKick. Microsoft indique qu'un groupe de pirates qu'il suit sous le nom de Storm-0940 a utilisé des agents d'intelligence artificielle pour accélérer l'exploitation de cette compromission et multiplier les opérations dans des environnements Microsoft 365.
Le rapport publié le 21 octobre est inhabituellement détaillé. Il rassemble des informations sur une campagne commencée au moins en septembre, la compromission de services ConnectWise détectée en octobre et les opérations réalisées ensuite contre les organisations clientes.
Microsoft attribue Storm-0940 à un acteur aligné sur les intérêts de l'État chinois. Cette qualification repose sur ses travaux de renseignement et ne constitue pas une confirmation indépendante de la responsabilité du gouvernement chinois. Pékin rejette les accusations américaines de cyberespionnage.
ARTEX : un outil de pentest utilisé pour industrialiser les attaques
L'élément nouveau du dossier est ARTEX, un framework de tests d'intrusion fondé sur plusieurs agents d'intelligence artificielle.
À l'origine, les outils de pentest permettent aux professionnels de la sécurité de rechercher des faiblesses dans des systèmes avec l'autorisation de leurs propriétaires. Leurs fonctions peuvent cependant être détournées à des fins malveillantes.
Microsoft décrit ARTEX comme un système capable de coordonner plusieurs agents pilotés par des modèles de langage. Le framework est développé en Go, utilise une interface Next.js et peut s'appuyer sur différents modèles IA.
Il automatise notamment des opérations de reconnaissance, l'identification de ressources accessibles et certaines étapes d'exploitation. Les résultats accumulés peuvent être organisés dans un graphe représentant les systèmes, comptes et relations découverts.
L'intérêt pour un attaquant tient moins à une capacité entièrement nouvelle qu'à la vitesse et à la continuité des opérations.
Des scripts de sécurité exécutent déjà depuis longtemps des analyses automatisées. ARTEX ajoute une couche de coordination capable de choisir des actions successives, d'interpréter des résultats et d'enchaîner plusieurs tâches avec une intervention humaine réduite.
Le groupe peut ainsi faire fonctionner des processus pendant de longues périodes, explorer plusieurs cibles et réagir aux informations obtenues sans attendre qu'un opérateur reprenne manuellement chaque étape.
Selon Microsoft, plusieurs opérations associées à Storm-0940 ont abouti à des accès privilégiés dans des infrastructures cloud en moins de trois heures.
Il ne s'agit pas d'un délai garanti pour toutes les attaques. Le chiffre concerne plusieurs cas observés par l'entreprise, dans des conditions qui lui sont propres.
151 000 échecs de connexion : une première campagne qui n'a pas réussi
Microsoft décrit une phase de password spraying menée entre le 10 et le 14 octobre.
Cette technique consiste à essayer des combinaisons d'identifiants et de mots de passe contre plusieurs comptes, plutôt que d'attaquer intensivement un seul utilisateur.
Dans le sous-ensemble étudié, l'infrastructure associée à Storm-0940 a ciblé 327 comptes appartenant à huit organisations.
La télémétrie de Microsoft a enregistré plus de 151 000 tentatives de connexion échouées. Le 11 octobre, l'activité a atteint un pic de 2 900 échecs par minute. Plus de 111 000 tentatives ont été concentrées sur une seule journée.
Ces chiffres illustrent la vitesse de la campagne, mais il faut conserver leur résultat réel : Microsoft indique n'avoir observé aucune authentification réussie, aucun jeton délivré, aucun appel Microsoft Graph et aucune modification de répertoire dans cet ensemble précis.
Autrement dit, les 151 000 échecs ne correspondent pas à 151 000 comptes compromis.
Ils montrent une activité offensive massive, sans succès confirmé pour cette séquence particulière.
La situation change avec la compromission de ConnectWise et l'accès aux identités applicatives utilisées par ses services.
Une application compromise, plus de 2 250 environnements visés
Le 15 octobre, des informations publiques commencent à circuler sur des accès non autorisés associés à ConnectWise Cloud Backup.
Microsoft rapproche les indicateurs techniques de cette compromission de ceux identifiés pendant les précédentes opérations de Storm-0940.
Après avoir obtenu le contrôle d'identités associées à plusieurs applications ConnectWise, les attaquants ont utilisé leurs identifiants pour tenter de s'authentifier auprès des environnements Microsoft 365 des clients.
L'ampleur change immédiatement : Microsoft rapporte des tentatives de connexion concernant plus de 2 250 tenants, c'est-à-dire des environnements Microsoft 365 administrativement distincts.
Un tenant ne correspond pas nécessairement à une entreprise unique. Certains groupes exploitent plusieurs environnements, tandis que des fournisseurs administrent ceux de nombreux clients.
Le chiffre de 2 250 désigne donc une portée technique observée, pas le nombre confirmé d'organisations dont les données ont été volées.
La campagne exploite une caractéristique essentielle des applications multitenants : une même solution peut être autorisée à fonctionner dans de nombreux environnements clients.
Cette relation de confiance crée un avantage opérationnel pour le fournisseur, mais aussi une concentration du risque si ses identifiants sont compromis.
L'infographie publiée par Microsoft illustre également plus de 200 connexions réalisées en moins de quatre minutes à l'aide de quatre identifiants applicatifs.
Il faut distinguer cette activité des échecs de password spraying survenus précédemment. Les deux séries de données appartiennent à des phases différentes de la campagne et ne doivent pas être additionnées comme s'il s'agissait d'une seule opération homogène.
Pourquoi les attaquants n'avaient pas besoin du mot de passe d'un employé
La compromission repose notamment sur l'utilisation d'identités applicatives. Dans Microsoft Entra, une application autorisée peut recevoir des permissions lui permettant d'interagir avec certaines ressources Microsoft 365.
Ces permissions peuvent être exercées sans qu'un utilisateur humain valide chacune des opérations, selon le type d'accès accordé.
Pour une solution de sauvegarde, cette possibilité est indispensable. Un service automatisé doit pouvoir accéder aux données couvertes par son contrat sans attendre la présence permanente d'un administrateur.
Mais lorsqu'un attaquant récupère les identifiants permettant d'utiliser cette identité, il peut chercher à exploiter les permissions déjà accordées.
Le fournisseur n'a donc pas besoin d'avoir une vulnérabilité dans Microsoft 365 pour que le risque existe. Une application externe disposant de droits suffisants peut devenir une voie d'accès.
Microsoft précise que les opérations observées ne résultent pas d'une compromission de ses propres systèmes d'entreprise, produits ou services.
La faiblesse mise en évidence concerne ici les identifiants d'applications tierces, les autorisations associées et la manière dont les environnements clients acceptent leurs connexions.
Les attaquants ont notamment utilisé Microsoft Graph, l'interface qui permet aux applications d'interagir avec les ressources et paramètres des services Microsoft 365.
Selon Microsoft, les opérations observées comprennent des reconnaissances, des modifications d'identifiants applicatifs et des tentatives de changement de privilèges.
Certaines modifications ont pu créer des accès persistants au-delà de la connexion ConnectWise initialement compromise.
La persistance cloud est le danger le plus difficile à éliminer
Révoquer un certificat ou désactiver une application compromise peut empêcher de nouvelles connexions par cette voie. Cela ne supprime pas automatiquement les changements déjà réalisés dans les environnements auxquels l'attaquant a eu accès.
Un acteur malveillant peut, par exemple, ajouter des identifiants à une autre application, créer un nouveau principal de service ou modifier des attributions de rôles.
Lorsque de telles modifications ont été effectivement réalisées, l'accès peut rester possible après le traitement de l'incident initial.
C'est ce que Microsoft appelle une persistance cloud privilégiée.
Dans plusieurs environnements, ses chercheurs indiquent avoir observé des opérations permettant d'étendre les droits ou de conserver des possibilités d'accès.
Il serait toutefois incorrect d'en conclure que tous les environnements visés ont subi cette persistance.
Microsoft souligne qu'une authentification réussie ne démontre pas, à elle seule, l'accès à des données sensibles ou leur exfiltration.
La distinction doit être maintenue entre quatre niveaux : une tentative de connexion, une connexion acceptée, une modification non autorisée des permissions et un accès effectif aux données.
L'enquête confirme des activités malveillantes dans plusieurs environnements. Elle ne fournit pas un bilan public complet des données éventuellement extraites de chaque client.
ConnectWise a suspendu trois services pour contenir la compromission
ConnectWise a détecté des activités suspectes le 14 octobre et publié une première communication le 16.
Le fournisseur a identifié des accès non autorisés à des identités applicatives liées à Cloud Backup, son service de sauvegarde de Microsoft 365, auparavant commercialisé sous le nom SkyKick.
Le 17 octobre, ConnectWise a désactivé plusieurs connexions applicatives concernées et révoqué des certificats.
L'entreprise a également suspendu Cloud Backup, SaaS Security et Cloud Management, deux services liés au premier.
Cette mesure a interrompu les sauvegardes programmées, l'accès aux archives et certaines possibilités de restauration. Elle a également perturbé les fonctions de surveillance de SaaS Security ainsi que des opérations de gestion des utilisateurs et licences proposées par Cloud Management.
L'interruption constitue une conséquence concrète de l'incident pour les prestataires de services informatiques et leurs clients.
Un système de sauvegarde n'est pas seulement un service de confort. Il fait partie des moyens permettant de retrouver des données après une erreur, une panne ou une attaque.
ConnectWise affirme que les archives existantes sont restées chiffrées, isolées et préservées, sans indication de compromission.
Ce constat concerne les archives de sauvegarde du fournisseur. Il ne permet pas de conclure que tous les environnements Microsoft 365 des clients sont indemnes.
L'entreprise le précise dans ses propres avis : elle ne peut pas déterminer, par la seule analyse de son infrastructure, si des modifications non autorisées ont été effectuées dans chaque tenant client.
Ces derniers doivent donc être examinés individuellement.
La restauration a commencé, mais tous les services ne sont pas revenus
ConnectWise indique avoir achevé le 19 octobre une réinitialisation des comptes et identifiants dans l'environnement Cloud Backup concerné.
Le 21 octobre, le fournisseur a annoncé le début d'une restauration progressive de ses services après les premières étapes de remédiation et de validation.
Au 22 octobre, l'entreprise confirme que ce processus est toujours en cours.
La remise en service est organisée par phases, avec des vérifications de sécurité à chaque étape. ConnectWise estime qu'elle nécessitera encore plusieurs jours.
Le lancement de la restauration ne signifie donc pas que toutes les fonctionnalités sont de nouveau disponibles.
Les partenaires doivent attendre les consignes spécifiques de reconnexion avant de réactiver les applications affectées.
ConnectWise affirme également ne pas avoir d'indication que d'autres produits ou services de son portefeuille soient concernés par cet incident.
Ces informations décrivent l'état de l'enquête et de la restauration à la date des communications, et non une garantie définitive sur toute l'étendue de la compromission.
Ce que doivent vérifier les administrateurs Microsoft 365
Les recommandations officielles de Microsoft et ConnectWise convergent sur un point : traiter l'incident dans chaque environnement susceptible d'avoir autorisé les applications concernées.
Microsoft recommande de rechercher les identités applicatives visées dans tous les tenants actuels et anciens, y compris lorsque l'intégration n'est plus utilisée.
L'inventaire doit s'appuyer sur les identifiants des applications et les identifiants internes des principaux de service, plutôt que sur leurs seuls noms affichés.
Les administrateurs doivent conserver et examiner les journaux de connexion des principaux de service dans Microsoft Entra, ainsi que les audits Microsoft 365 et Microsoft Graph disponibles.
Les recherches doivent porter notamment sur les connexions provenant de sources inhabituelles, les ajouts d'identifiants applicatifs, les nouvelles autorisations, les changements de propriétaire et les attributions de rôles privilégiés.
Microsoft recommande d'examiner les activités à partir du 15 octobre au minimum. Lorsque les données sont disponibles, l'analyse peut être étendue au début du mois pour rechercher des signes antérieurs.
Un autre point mérite une attention particulière : les identifiants initiaux compromis ne sont pas nécessairement les seuls moyens d'accès possibles après l'attaque.
Une modification malveillante des permissions ou la création d'une autre identité peut nécessiter une remédiation spécifique.
Microsoft déconseille de supprimer immédiatement les applications d'entreprise comme première réaction, car cette opération peut compliquer la conservation des éléments nécessaires à l'enquête.
Les équipes doivent d'abord préserver les preuves pertinentes et suivre les procédures de confinement adaptées, sans retarder les mesures urgentes de protection.
Les indicateurs techniques publiés par ConnectWise constituent des pistes d'investigation, mais leur présence isolée ne confirme pas automatiquement une compromission.
Inversement, l'absence de correspondance avec une adresse IP connue ne garantit pas qu'un environnement n'a pas été touché.
Pourquoi les attaques assistées par IA changent la fenêtre de réaction
ARTEX n'a pas inventé le password spraying, les identités applicatives compromises ni la persistance dans les services cloud.
Ces techniques étaient déjà utilisées par des attaquants avant l'arrivée des agents autonomes.
Ce qui change est la capacité à les enchaîner à grande vitesse et à grande échelle.
Un agent logiciel peut interpréter les résultats d'une reconnaissance, transmettre les éléments intéressants à un autre agent et poursuivre plusieurs hypothèses sans attendre la coordination manuelle de chaque action.
La défense dispose parfois d'alertes décrivant ces opérations. Mais les alertes perdent une partie de leur efficacité lorsque les privilèges sont modifiés avant qu'une équipe ait eu le temps de les traiter.
Dans cette affaire, Microsoft documente des accès privilégiés obtenus en moins de trois heures dans plusieurs cas.
L'enjeu devient alors la capacité à appliquer automatiquement certaines restrictions : limiter les privilèges initiaux, identifier les connexions applicatives anormales et bloquer rapidement les modifications non autorisées.
Les outils de sécurité utilisant eux-mêmes l'IA peuvent aider à analyser les incidents, mais ils ne remplacent pas une architecture d'autorisations robuste.
Un fournisseur tiers ne devrait pas disposer de droits plus étendus que ceux nécessaires à son service. Et ces droits devraient pouvoir être surveillés et révoqués sans laisser subsister des accès inattendus.
Une attribution contestée, des conséquences techniques documentées
Microsoft présente Storm-0940 comme un groupe actif depuis 2021, aligné sur les intérêts de l'État chinois.
Reuters a recueilli une réaction de l'ambassade de Chine à Washington, qui rejette les accusations portées contre la Chine et affirme que le pays combat les activités de piratage.
L'attribution à un acteur étatique relève de l'analyse du renseignement cyber publiée par Microsoft. La compromission d'identifiants applicatifs, les activités d'authentification et les opérations observées dans plusieurs environnements reposent, elles, sur des éléments techniques distincts.
ConnectWise indique que les informations fournies par Microsoft correspondent à son évaluation actuelle de l'incident.
La campagne montre enfin une limite importante de la sécurité cloud : un fournisseur peut sécuriser son infrastructure après une intrusion sans pouvoir garantir que toutes les conséquences ont disparu chez ses clients.
L'étape décisive n'est donc pas seulement la restauration de ConnectWise Cloud Backup. Elle consiste aussi à identifier les modifications éventuelles réalisées dans les environnements Microsoft 365 qui avaient accordé leur confiance aux applications compromises.
Au 22 octobre, la restauration progresse, les archives ConnectWise ne présentent pas d'indication publique de compromission et plusieurs environnements clients nécessitent toujours des vérifications. L'ampleur exacte des accès aux données reste à établir.