Une compromission du service principal ConnectWise Cloud Backup ouvre 173 locataires Microsoft 365
Le 17 octobre 2026, ConnectWise coupe l’accès à son service Cloud Backup après que des attaquants ont compromis l’identité applicative du service et se sont connectés à des locataires Microsoft 365 avec les permissions déjà accordées. Auditez les service principals de vos fournisseurs, désactivez les applications ConnectWise impliquées et révoquez leurs secrets.
15 octobre 2026. Microsoft repère des tentatives d’authentification non autorisées depuis une adresse IP unique, 144.172.64.128, vers des locataires Microsoft 365. 16 octobre 2026. Huntress confirme au moins 162 locataires compromis dans son parc, et Todyl détaille la mécanique. 17 octobre 2026, 05 h 01 UTC. ConnectWise coupe l’accès client à son service Cloud Backup, anciennement SkyKick Cloud Backup. Pourquoi c’est important : l’attaquant n’a pas forcé de mot de passe ni contourné un MFA. Il a utilisé le secret d’une application de sauvegarde légitime, et les permissions que les clients lui avaient déjà données, pour entrer dans leurs locataires.
Une attaque supply chain qui passe par l’identité applicative, pas par les données
Le point d’entrée n’est ni un poste de travail ni un compte utilisateur. C’est le service principal — l’identité applicative — que ConnectWise Cloud Backup utilise pour sauvegarder les données Microsoft 365 de ses clients. Pour fonctionner, ce service s’appuie sur des permissions accordées via Microsoft Entra ID : une identité connue sous le nom de service principal représente le logiciel dans le locataire du client et accède aux ressources selon les droits consentis.
Selon Todyl, l’attaquant s’est authentifié directement auprès de Microsoft 365 en tant qu’application de sauvegarde, en utilisant son secret. Les connexions ont été réalisées par un script automatisé et, parce qu’elles n’impliquaient aucune connexion utilisateur, les protections comme le MFA n’ont eu aucun effet.
La conséquence est brutale. « Parce que l’application détenait déjà des permissions larges, préalablement accordées dans chaque locataire, ces connexions donnaient à l’attaquant la capacité technique de lire et d’écrire les courriels et pièces jointes, les fichiers OneDrive et SharePoint, et les conversations Teams », résume Todyl. Sur les neuf locataires analysés en profondeur, les chercheurs n’ont toutefois trouvé que de l’activité de connexion — pas de création de compte, d’ajout de permission, de changement de mot de passe ni de persistance via l’application de sauvegarde.
La persistance : un rôle Global Admin accordé en cinq minutes
Le tableau se noircit côté Huntress. Sur près de 50 locataires qu’elle surveille, la plateforme a vu des service principals des applications ConnectWise Cloud Management — Exchange Online, Microsoft Teams et Microsoft Graph — s’attribuer des rôles d’annuaire, le plus souvent Exchange Administrator.
Dans un locataire, les chercheurs ont observé l’attaquant établir une persistance en l’espace de cinq minutes environ. L’application Cloud Management - MS Teams s’est accordé un rôle Global Administrator, puis a ajouté des informations d’identification à un outil de gestion MSP et à l’application de Huntress elle-même.
Microsoft a confirmé le même schéma : une persistance via une porte dérobée après une authentification réussie du service principal, suivie de reconnaissance via l’API Microsoft Graph et de tentatives d’ajout d’informations d’identification supplémentaires. Microsoft Threat Intelligence qualifie l’incident de supply chain active, estimant que l’attaquant a probablement abusé de permissions existantes, dont Directory.ReadWrite.All.
Les indicateurs à chercher dès maintenant
Les trois éditeurs de sécurité — Huntress, Microsoft et Todyl — ont tous rattaché l’activité à la même adresse IP, 144.172.64.128. Huntress a identifié l’ID d’application légitime utilisé dans les attaques et l’a relié à des connexions scriptées dès les 13 et 14 octobre, avec l’user-agent curl/7.88.1. Trois autres user-agents sont associés à l’activité malveillante : python-urllib/3.12, python-requests/2.31 et python-requests/2.34.2.
Voici les identifiants d’application à rechercher dans vos journaux Entra ID :
ConnectWise Cloud Backup 506e08f9-6e9a-4da4-942b-a099a03644ae
ConnectWise Cloud Management 2399d300-6fca-4e6a-a686-399fefe75b83
ConnectWise Cloud Management - MS Teams 24205314-2b89-4e07-a2a4-579e898a5640
ConnectWise Cloud Management - Exchange b78f6a77-d4e5-46fb-87e5-d1648bd02519
ConnectWise Cloud Management - MS Graph 0de14c77-b9b0-4137-9360-34878a929827ConnectWise recommande de filtrer les connexions des service principals dans Entra sur ces identifiants et d’examiner les adresses sources inattendues. Microsoft conseille de passer en revue les changements d’informations d’identification d’application, les consentements OAuth et l’activité Graph associée. Les anciens locataires peuvent voir ces applications sous le nom SkyKick Cloud Manager.
Pour automatiser la recherche dans vos journaux, la requête Microsoft Graph ci-dessous liste les connexions du service principal de sauvegarde :
# Microsoft Graph PowerShell — connexions du service principal Cloud Backup
Get-MgAuditLogSignIn -Filter "appId eq '506e08f9-6e9a-4da4-942b-a099a03644ae'"Filtrez ensuite sur les adresses IP sources inattendues et croisez avec les rôles d’annuaire attribués dans Entra — Get-MgDirectoryRoleMember liste les membres d’un rôle. Toute attribution d’un rôle Exchange Administrator ou Global Administrator à une application de sauvegarde est un signal d’alerte immédiat.
Ce que ça change pour les MSP et leurs clients
L’incident redessine la confiance entre un MSP et le logiciel qu’il déploie chez ses clients. Un MSP qui utilise ConnectWise Cloud Backup a, par nature, installé une identité applicative dans les locataires Entra ID de dizaines ou de centaines de clients. Chaque service principal de ce type est une identité privilégiée déléguée : elle porte les permissions que le client a consenties, souvent larges, et elle s’authentifie sans interaction humaine.
C’est ce qui rend la faille si asymétrique. L’attaquant n’a pas eu besoin de cibler chaque client un par un. En obtenant le secret de l’application de sauvegarde, il a hérité d’un passe-partout qui ouvre tous les locataires où cette application est consentie. Le MFA, qui protège les connexions humaines, ne s’applique tout simplement pas aux connexions applicatives scriptées.
Pour les clients finaux, la conséquence est un renversement du réflexe de sécurité : le risque n’est plus « mon fournisseur a-t-il été piraté ? », mais « quelles permissions ai-je accordées à mon fournisseur, et qui surveille l’usage qu’en fait son application ? ». La réponse n’est pas de se passer des MSP — elle est de traiter leurs service principals comme des comptes à privilèges, avec journalisation, alerte et rotation des secrets.
Le point aveugle : couper l’application ne suffit pas
L’interruption de service annoncée par ConnectWise ne retire pas les informations d’identification déjà déposées dans les locataires. Huntress insiste : les administrateurs doivent examiner les secrets et certificats de toutes les applications depuis le 13 octobre et supprimer les ajouts non autorisés.
Todyl pointe un piège plus subtil. Désactiver une application empêche l’émission de nouveaux jetons, mais les jetons existants restent valides jusqu’à leur expiration. Et révoquer les sessions utilisateur ne met pas fin aux accès applicatifs. Une application compromise qui a déjà reçu un jeton de longue durée continue d’agir, même après la coupure de service.
Le vecteur initial — la manière dont l’attaquant a obtenu le secret du fournisseur — reste inconnu au moment de la publication, tout comme le nombre exact de victimes et l’ampleur réelle de l’exfiltration. ConnectWise n’a signalé aucune preuve que les sauvegardes stockées aient été compromises.
Verdict
Si votre organisation est cliente d’un MSP utilisant ConnectWise Cloud Backup, agissez sans attendre la communication du fournisseur : désactivez les applications ConnectWise impliquées, révoquez leurs secrets et certificats ajoutés depuis le 13 octobre, et auditez les rôles d’annuaire — en particulier tout Exchange Administrator ou Global Administrator attribué à un service principal. Si vous n’êtes pas client, la leçon reste valable : chaque application tierce qui détient des permissions dans votre locataire Entra ID est une identité privilégiée à surveiller en continu, pas un fournisseur qu’on oublie après l’intégration. Le MFA ne protège pas l’authentification applicative — seuls la rotation des secrets et le contrôle des consentements le font.