En bref

  • Un credential OAuth de ConnectWise Cloud Backup (anciennement SkyKick) a été compromis le 15 octobre 2026, permettant l'accès à 173 tenants Microsoft 365.
  • Les attaquants ont exploité une identité applicative OAuth pour bypasser MFA et obtenir des tokens Microsoft Graph avec des permissions élevées comme Directory.ReadWrite.All.
  • ConnectWise a suspendu l'accès à son service Cloud Backup ; les administrateurs doivent immédiatement révoquer les permissions OAuth de l'application et auditer les activités suspectes.

Un credential volé suffit pour compromettre 173 organisations

Le 15 octobre 2026, une alerte de sécurité de haute criticité a été émise conjointement par Microsoft et ConnectWise : des acteurs malveillants ont exploité un secret d'API compromis appartenant à ConnectWise pour s'authentifier via l'application OAuth de ConnectWise Cloud Backup — anciennement commercialisée sous la marque SkyKick Cloud Backup — et accéder à des tokens Microsoft Graph dans 173 tenants clients. L'AppId concernée est 506e08f9-6e9a-4da4-942b-a099a03644ae, identifiée et documentée par les équipes de Microsoft Threat Intelligence.

La chronologie de l'attaque est précise : le 15 octobre, à partir de l'adresse IP 144.172.64[.]128, appartenant à un hébergeur commercial, l'identité applicative de ConnectWise Cloud Backup s'est connectée à plusieurs tenants clients de Microsoft 365 et a reçu des access tokens Microsoft Graph. Ces tokens ont été obtenus non pas par des attaques de type credential stuffing ou phishing ciblant les utilisateurs finaux, mais directement via le secret API de l'application OAuth dans le tenant domestique de ConnectWise.

Ce vecteur d'attaque tire parti d'un mécanisme fondamental du modèle de confiance OAuth : lorsqu'une application tierce comme ConnectWise Cloud Backup obtient des permissions dans un tenant Microsoft 365 — notamment des permissions privilégiées telles que Directory.ReadWrite.All, Mail.ReadWrite ou Sites.FullControl.All — ces accès sont délégués à l'identité applicative. Si le secret de cette identité est compromis dans le tenant d'origine du fournisseur, l'attaquant peut usurper l'application entière et accéder à tous les tenants clients qui lui ont accordé des permissions, sans avoir besoin du mot de passe ni du MFA des utilisateurs.

L'ampleur potentielle de l'incident dépasse les 173 tenants confirmés au moment de la divulgation. ConnectWise Cloud Backup est l'une des solutions de sauvegarde M365 les plus déployées dans les environnements MSP (Managed Service Providers) à travers le monde. Les MSP utilisent cette solution pour sauvegarder les boîtes mail, les fichiers SharePoint, les données Teams et OneDrive de leurs clients. Chaque MSP gérant plusieurs dizaines à plusieurs centaines de clients, l'accès à l'identité applicative de ConnectWise constitue de fait une clé maîtresse vers l'ensemble de cet écosystème.

La réponse de ConnectWise a été immédiate mais radicale : la société a suspendu l'accès à l'ensemble de son service Cloud Backup, affectant tous les clients en attente de sauvegarde ou de restauration. Cette décision, bien que perturbatrice sur le plan opérationnel, vise à empêcher toute utilisation supplémentaire des credentials compromis. ConnectWise a également révoqué le secret API concerné et entrepris une rotation complète des identifiants applicatifs. Dans un message adressé à ses partenaires MSP, la société a indiqué enquêter activement sur l'étendue de la compromission et s'est engagée à fournir des indicateurs de compromission (IoC) supplémentaires.

Selon les chercheurs de Huntress, qui ont publié une analyse technique détaillée, les permissions dont disposait l'application OAuth ConnectWise dans les tenants victimes incluaient dans plusieurs cas des niveaux d'accès particulièrement critiques. Directory.ReadWrite.All permet de lire et modifier l'intégralité de l'annuaire Azure Active Directory, y compris les groupes, les rôles et les attributs utilisateurs. Cette permission offre en théorie la capacité de créer des comptes administrateurs fantômes, de modifier des configurations de politiques d'accès conditionnel ou d'exfiltrer l'ensemble du répertoire de l'organisation.

Microsoft a publié des requêtes de chasse aux menaces via Microsoft Sentinel et Defender XDR pour permettre aux équipes SOC d'identifier des activités suspectes liées à l'AppId 506e08f9-6e9a-4da4-942b-a099a03644ae dans leurs tenants. Les indicateurs à surveiller incluent des connexions depuis l'IP 144.172.64[.]128, des acquisitions de tokens Microsoft Graph inhabituelles, et des opérations sur l'annuaire effectuées par le compte de service applicatif ConnectWise en dehors des fenêtres de sauvegarde habituelles.

Les entreprises affectées doivent en priorité : vérifier l'AppId concernée dans leur portail Azure AD (Entra ID), examiner les logs de connexion pour la période du 14 au 16 octobre 2026, révoquer les permissions OAuth de l'application ConnectWise Cloud Backup jusqu'à confirmation d'un correctif, et activer la surveillance des comptes administrateurs pour détecter toute création ou modification non autorisée.

Le risque systémique des chaînes d'approvisionnement cloud

Cet incident illustre une catégorie de risques encore insuffisamment prise en compte dans les modèles de gestion des risques tiers : la compromission non pas d'un prestataire humain, mais d'une identité applicative partagée dans un modèle multi-tenant. Contrairement aux attaques traditionnelles contre les prestataires — comme celle de SolarWinds en 2020 où du code malveillant avait été injecté dans une mise à jour logicielle — ici, aucun code n'a été altéré. C'est la confiance accordée à une application OAuth légitime qui a été détournée.

Ce vecteur d'attaque rappelle l'incident de juillet 2023 impliquant Storm-0558, groupe lié à la Chine, qui avait forgé des tokens d'authentification Microsoft pour accéder aux boîtes mail d'agences gouvernementales américaines et européennes. Dans ce précédent, c'était une clé de signature Microsoft elle-même qui avait été compromise. Le cas ConnectWise diffère en ceci que la compromission a eu lieu chez un tiers de confiance de niveau inférieur, mais avec des conséquences en cascade comparables en raison du modèle MSP.

L'économie des MSP repose précisément sur cette architecture de permissions centralisées : un MSP gère l'IT de dizaines ou centaines de PME, et délègue à des outils comme ConnectWise Cloud Backup des accès étendus pour automatiser les sauvegardes et restaurations. Cette efficacité opérationnelle crée mécaniquement un point de défaillance unique. Si le secret de l'outil est compromis, toute la clientèle du MSP est potentiellement exposée. Les régulateurs commencent à s'interroger sur la nécessité d'imposer des standards d'isolation plus stricts entre les tenants dans ces architectures multi-clients.

Dans le contexte réglementaire européen, cet incident tombe au moment où la directive NIS2 impose aux prestataires de services gérés de notifier les incidents de cybersécurité significatifs dans un délai de 72 heures. Les MSP européens utilisant ConnectWise Cloud Backup devront évaluer si cet incident constitue un événement notifiable au sens de NIS2, en fonction du niveau d'accès effectivement utilisé par les attaquants dans leurs tenants clients.

Ce qu'il faut retenir

  • Le secret OAuth de ConnectWise Cloud Backup a été volé, permettant l'accès sans MFA à 173 tenants M365 ; le service est suspendu le temps de l'investigation.
  • Les permissions élevées (Directory.ReadWrite.All) accordées à l'application constituaient un risque sous-estimé dans les architectures MSP multi-tenants.
  • Auditez immédiatement les applications OAuth tierces dans vos tenants M365 et appliquez le principe de moindre privilège aux identités applicatives.

Comment vérifier si mon tenant M365 a été compromis dans l'attaque ConnectWise ?

Connectez-vous à votre portail Azure AD (Entra ID) et recherchez dans les journaux de connexion les activités de l'AppId 506e08f9-6e9a-4da4-942b-a099a03644ae entre le 14 et le 16 octobre 2026. Vérifiez également les logs Microsoft Graph pour des opérations inhabituelles sur l'annuaire. Si vous utilisez Microsoft Sentinel, déployez les requêtes de détection publiées par Microsoft Threat Intelligence ciblant cette AppId et l'IP 144.172.64[.]128.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact