ConnectWise désactive les identités d’application après une compromission de locataires Microsoft 365
ConnectWise a suspendu Cloud Backup et désactivé sept identités d’application après que des attaquants ont compromis des identifiants pour accéder aux locataires Microsoft 365 de ses clients.
Traduit automatiquement depuis l'original anglais.
ConnectWise a désactivé sept de ses identités d’application et suspendu son service Cloud Backup à la suite d’un incident de sécurité au cours duquel des acteurs malveillants ont obtenu un accès non autorisé à ces identités. La violation, identifiée le 14 octobre 2026, a permis aux attaquants de compromettre des locataires Microsoft 365 appartenant aux clients de ConnectWise, ce qui a incité le fournisseur de logiciels de gestion informatique à prendre des mesures immédiates d’atténuation le 17 octobre 2026.
Ce qui s’est passé
Le 17 octobre 2026, à 07:00 UTC, ConnectWise a pris des mesures décisives en désactivant sept identités d’application spécifiques et en révoquant les certificats utilisés pour les connexions d’applications affectées auprès de tous les utilisateurs. Cette action a effectivement suspendu le service Cloud Backup, interrompant les sauvegardes programmées et rendant temporairement indisponibles les capacités de restauration. L’entreprise a déclaré que, bien que les archives de sauvegarde existantes restent chiffrées, isolées et préservées sans preuve de violation, les identifiants partagés de Cloud Backup ne sont plus valides. ConnectWise a également mis hors ligne temporairement ses services SaaS Security et Cloud Management par mesure de précaution, tout en poursuivant son enquête sur l’incident.
Les identités d’application compromises incluent ConnectWise Cloud Backup et six variantes de ConnectWise Cloud Management couvrant MS Teams, Exchange Online, MS Graph, Partner Center et SharePoint Online. ConnectWise a souligné que la désactivation de ces connexions empêche toute nouvelle authentification, mais ne revient pas sur les modifications précédemment effectuées dans le locataire d’un client. Les jetons d’accès émis antérieurement peuvent rester utilisables jusqu’à leur expiration, ce qui signifie que les identifiants ou autorisations non autorisés établis via des identités distinctes nécessitent un examen et une remédiation supplémentaires de la part des partenaires et clients concernés.
Comment cela fonctionne
Cet incident met en lumière les risques associés aux identifiants des entités de service (service principals) dans les environnements cloud. Au lieu de voler les mots de passe individuels des utilisateurs, les attaquants ont obtenu les identifiants des identités d’application. En s’authentifiant en tant que l’application elle-même, les acteurs malveillants pouvaient demander des jetons d’accès à Microsoft Entra ID en se basant sur les permissions étendues déjà accordées aux outils de ConnectWise pour les tâches de sauvegarde et de gestion. Cette méthode permet à un attaquant de contourner les protections d’authentification multifacteur généralement liées aux comptes utilisateurs.
Une fois authentifiés en tant que l’application, les attaquants pouvaient potentiellement accéder aux boîtes aux lettres, aux documents SharePoint, aux messages Teams et aux informations de l’annuaire. Plus critique encore, ils pouvaient étendre leur accès en ajoutant l’application compromise au rôle Global Administrator, en créant de nouvelles applications et en ajoutant des secrets clients à d’autres applications fiables dans le locataire. Ces nouveaux secrets clients constituent une porte dérobée persistante, permettant aux attaquants de regagner l’accès même si l’identifiant compromis initial est révoqué. Ce mécanisme de persistance complique la remédiation, car la simple rotation du mot de passe ou du certificat initial est insuffisante si de nouveaux secrets ont été implantés.
Détails clés
- ConnectWise a désactivé sept identités d’application le 17 octobre 2026, dont Cloud Backup et divers services Cloud Management.
- Le problème a été identifié le 14 octobre 2026 grâce à une surveillance interne de la cybersécurité, bien que le mécanisme exact d’exposition des identifiants reste en cours d’analyse.
- Huntress a observé des connexions malveillantes depuis l’adresse IP "144.172.64[.]128" et confirmé l’abus de l’application Teams dans au moins un locataire.
- Une deuxième vague de tentatives ciblées a eu lieu le 15 octobre, visant 16 locataires dans les secteurs des politiques publiques, de la sécurité nationale et des minéraux critiques, mais elle a échoué.
- Sur près de 1 000 locataires Entra ayant enregistré une activité de connexion depuis l’IP suspecte, 300 ont réussi, bien que certains aient été bloqués par l’absence d’une entité de service.
- Les archives de sauvegarde existantes sont signalées comme chiffrées et intactes, mais les sauvegardes programmées sont actuellement interrompues.
Pourquoi c’est important
Pour les développeurs de logiciels et les responsables informatiques gérant des environnements Microsoft 365, cet incident souligne l’importance cruciale de sécuriser les entités de service et les permissions des applications. Contrairement aux attaques centrées sur les utilisateurs, la compromission d’une identité d’application accorde un accès automatisé et étendu, difficile à détecter sans une journalisation d’audit rigoureuse. La capacité des attaquants à implanter de nouveaux secrets clients signifie que les limites de confiance au sein du locataire peuvent être altérées de manière permanente, nécessitant un examen approfondi de toutes les inscriptions d’applications et des consentements accordés.
La nature de chaîne d’approvisionnement de cette attaque démontre également comment les vulnérabilités dans les outils des fournisseurs de services gérés peuvent se propager à des centaines de clients en aval. Même si une vulnérabilité produit n’a pas directement causé la compromission, les permissions étendues accordées aux outils de gestion en font une cible de grande valeur. Les organisations doivent considérer que toute application disposant de privilèges élevés pourrait servir de vecteur pour des mouvements latéraux, imposant des contrôles plus stricts sur qui peut gérer les identifiants des applications et sur la façon dont ces identifiants sont stockés et renouvelés.
Ce que vous pouvez faire
- Examinez les journaux de connexion de votre locataire Microsoft 365 et de tous les locataires clients gérés à partir du 13 octobre 2026, en filtrant spécifiquement l’activité provenant de l’adresse IP "144.172.64[.]128".
- Vérifiez l’état des sept identités d’application ConnectWise désactivées et assurez-vous qu’elles restent désactivées jusqu’à nouvel ordre du fournisseur.
- Conservez tous les enregistrements disponibles de connexion et d’audit avant d’initier toute étape de confinement ou de nettoyage afin de maintenir l’intégrité forensique.
- Auditez les identifiants des applications, les relations de fédération, les rôles de l’annuaire et les modifications récentes de politique pour identifier tout ajout ou modification non autorisé.
- Recherchez les règles de transfert de boîte aux lettres non autorisées, les règles de boîte de réception, les règles de transport et les accès délégués aux boîtes aux lettres qui pourraient avoir été créés lors de la compromission.
- Mettez en œuvre des politiques de gestion des applications pour restreindre les secrets clients sur les inscriptions d’applications et limiter la durée de vie des identifiants afin de réduire la fenêtre d’opportunité pour les attaquants.



