ConnectWise suspend la sauvegarde cloud après la compromission d'identités d'application touchant des tenants Microsoft 365

ConnectWise a suspendu Cloud Backup après un accès non autorisé à ses identités d'application, utilisées pour accéder à des tenants Microsoft 365.

Ajoutez CyberWorldOpsà vos sources préférées sur Google
ConnectWise suspend la sauvegarde cloud après la compromission d'identités d'application touchant des tenants Microsoft 365
Cloud Security

Image d’illustration générée par IA

ConnectWise a suspendu son service Cloud Backup après que des attaquants non identifiés ont obtenu un accès non autorisé à ses identités d'application et s'en sont servis pour pénétrer dans des tenants Microsoft 365.

La société indique avoir détecté le problème le 14 octobre 2026 grâce à sa surveillance de sécurité, puis avoir ouvert une enquête. Selon le compte rendu de ConnectWise relayé par The Hacker News, elle a désactivé sept identités d'application et révoqué les certificats qui soutenaient les connexions concernées le 17 octobre à 07:00 UTC.

Un autre article indique que ConnectWise a annoncé l'interruption de Cloud Backup le 17 octobre à 05:01 UTC. Ces horaires correspondent respectivement à l'action d'atténuation signalée et à l'annonce du service ; il ne faut pas les traiter comme un horodatage unique.

La suspension empêche toute nouvelle authentification par les connexions concernées, mais elle ne supprime pas les identifiants, les permissions ni les autres mécanismes de persistance que les attaquants ont pu déjà créer dans les tenants des clients.

Services de sauvegarde et de gestion mis hors ligne

Cloud Backup, anciennement SkyKick Cloud Backup, assure la sauvegarde et la restauration pour Microsoft 365 et Google Workspace. ConnectWise a également mis temporairement hors ligne SaaS Security et Cloud Management le temps d'examiner l'incident.

Les sauvegardes planifiées ne tournent plus, et les clients ne peuvent actuellement utiliser ni les archives de sauvegarde concernées ni les fonctions de restauration. ConnectWise indique que les archives existantes restent chiffrées, isolées et préservées. La société n'a relevé aucune preuve que les sauvegardes stockées ou les données de sauvegarde des partenaires aient été consultées ou compromises.

ConnectWise a déclaré que les identifiants Cloud Backup partagés impliqués dans l'incident ne sont plus valides. Toutefois, les jetons d'accès émis avant la révocation peuvent rester utilisables jusqu'à leur expiration ou jusqu'à leur invalidation séparée. La désactivation de la connexion d'origine ne neutralise pas non plus les identifiants ou les permissions implantés via d'autres identités d'application.

La société a listé ces sept identités désactivées :

Nom de l'application ID d'application (client)
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 Online b78f6a77-d4e5-46fb-87e5-d1648bd02519
ConnectWise Cloud Management - MS Graph 0de14c77-b9b0-4137-9360-34878a929827
ConnectWise Cloud Management - Partner Center 412dcf96-176d-4b3a-a1b0-4981ad66971e
ConnectWise Cloud Management - SharePoint Online b2b55f5b-7758-4719-8d8f-88ae172e6bdb

Dans les anciens tenants, certaines applications Cloud Management peuvent apparaître sous le nom SkyKick Cloud Manager.

ConnectWise n'a pas déterminé si une vulnérabilité dans l'un de ses produits a contribué à la compromission. Le mécanisme par lequel les identifiants de l'application ont été exposés fait toujours l'objet d'une enquête.

Les identifiants d'application contournent l'authentification utilisateur

L'attaque n'a pas nécessité le mot de passe d'un utilisateur Microsoft 365. Des chercheurs ont indiqué que l'acteur s'était authentifié en tant qu'application de sauvegarde, en présentant son secret à Microsoft Entra ID et en demandant des jetons portant des permissions que les clients avaient déjà accordées.

Comme il s'agissait d'une authentification basée sur une application et non d'une connexion interactive d'utilisateur, l'MFA utilisateur ne s'appliquait pas. La révocation des sessions utilisateur ne suffirait pas, à elle seule, à mettre fin à l'accès de l'application.

Ces permissions existantes étaient étendues. Todyl indique que l'application pouvait techniquement lire et écrire les e-mails et leurs pièces jointes, les fichiers OneDrive et SharePoint, ainsi que les conversations Teams. Cela décrit ce que l'autorisation permettait, et non la preuve que tous ces types de données ont été consultés.

Des permissions de gestion plus larges ont également ouvert des voies de persistance. Huntress a observé des principaux de service associés à ConnectWise Cloud Management s'attribuant des rôles d'annuaire dans près de 50 tenants surveillés, le plus souvent Exchange Administrator. Dans un tenant, le principal de service Cloud Management - MS Teams s'est attribué le rôle Global Administrator et a ajouté des identifiants à une application de gestion d'un MSP ainsi qu'à l'application propre à Huntress. Huntress indique que la séquence a duré environ cinq minutes.

Selon BleepingComputer, Microsoft a qualifié l'opération d'attaque active contre la chaîne d'approvisionnement et estimait que l'acteur avait vraisemblablement abusé des permissions existantes, notamment Directory.ReadWrite.All. Microsoft aurait observé une porte dérobée après une authentification réussie du principal de service, suivie d'une reconnaissance via Microsoft Graph et de tentatives d'ajout d'identifiants.

L'activité de connexion et la compromission confirmée sont deux mesures différentes

Huntress a relevé une activité de connexion provenant de l'adresse IP de l'attaquant dans près de 1 000 tenants Entra. Parmi ces connexions, 300 ont réussi, mais une authentification réussie ne donnait pas toujours accès au tenant : dans certains cas, le principal de service requis n'était pas présent.

Dans l'environnement propre à Huntress, les chercheurs ont identifié au moins 162 tenants compromis. Ce chiffre est distinct des près de 1 000 tenants présentant une activité de connexion et des 300 connexions réussies.

D'autres constats portent sur des échantillons plus restreints :

  • Todyl a examiné neuf tenants et n'a relevé qu'une activité de connexion. Dans ces tenants, il n'a identifié ni création de compte, ni modification de permissions ou de mots de passe, ni persistance via l'application de sauvegarde.
  • Huntress a confirmé un abus de l'application Teams dans un tenant.
  • Près de 50 tenants surveillés par Huntress ont montré une auto-attribution de rôles d'annuaire impliquant des principaux de service ConnectWise Cloud Management.
  • Vague ciblée supplémentaire : 16 tenants des secteurs de la politique, de la sécurité nationale, du commerce et des minerais critiques ont été sélectionnés, mais Huntress a indiqué que ces tentatives avaient échoué.

Huntress a relié des tentatives automatisées utilisant curl/7.88.1 aux 13 et 14 octobre 2026. ConnectWise a détecté le problème plus large le 14 octobre.

Le 15 octobre, Huntress a enregistré la dernière connexion malveillante depuis l'adresse d'origine, à 08:45 UTC. Un balayage ultérieur visant les jetons Graph associés à l'application SkyKick s'est déroulé de 09:25:04 à 12:35:50 UTC. Un second balayage, apparemment manuel, visant les mêmes 16 tenants a eu lieu de 13:54:39 à 14:20:24 UTC, ciblant Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra et les API Office 365 Management.

Huntress indique n'avoir identifié aucune nouvelle activité malveillante après le 15 octobre. ConnectWise affirme de même n'avoir constaté aucune activité réussie dans les environnements qu'elle surveille depuis l'application de ses mesures d'atténuation, tout en précisant qu'elle ne peut pas observer directement les environnements des clients en aval.

Indicateurs et vérifications dans les tenants

L'indicateur réseau principal est :

  • Adresse IP : 144.172.64[.]128

Les user agents associés à l'activité comprennent :

  • python-urllib/3.12
  • python-requests/2.31
  • python-requests/2.34.2
  • curl/7.88.1

Les partenaires de ConnectWise devraient examiner à la fois leurs propres environnements Microsoft 365 et chaque tenant client géré, y compris les connexions SkyKick inactives. Les vérifications recommandées sont les suivantes :

  1. Rechercher dans les connexions des principaux de service Entra les sept ID d'application et les adresses sources inattendues, en particulier 144.172.64[.]128.
  2. Examiner les connexions de l'ensemble des identités à partir du 13 octobre 2026.
  3. Conserver les journaux de connexion et d'audit avant que les actions de confinement ne modifient les preuves disponibles.
  4. Inspecter les identifiants, secrets et certificats d'application pour détecter les ajouts non autorisés effectués depuis le 13 octobre.
  5. Vérifier les consentements OAuth, les rôles d'annuaire, les propriétaires d'applications, les approbations de fédération et les modifications récentes de stratégies.
  6. Rechercher de nouveaux identifiants ajoutés à d'autres applications de confiance, et pas seulement à l'identité ConnectWise d'origine.
  7. Contrôler Exchange pour détecter les transferts non autorisés, les règles de boîte de réception ou de transport et les accès délégués aux boîtes aux lettres.
  8. Examiner les autres intégrations Cloud Management et enquêter sur les identités modifiées ou utilisées pendant l'activité suspecte.

Huntress recommande également de restreindre la liste des personnes détenant les rôles Application Administrator et Cloud Application Administrator, d'utiliser des stratégies de gestion des applications pour limiter les secrets client et leur durée de vie, et d'appliquer l'accès conditionnel aux identités de charge de travail lorsque les licences le permettent. Microsoft Entra ID Protection peut également repérer les principaux de service à risque.

Ces contrôles ne remplacent pas l'examen des identifiants. La révocation décidée par ConnectWise met fin à toute nouvelle authentification par les connexions concernées, mais chaque tenant doit encore déterminer si l'attaquant a créé une voie distincte qui survit à la suppression de l'identifiant d'origine.

À lire aussi

Sources

Cet article est une réécriture originale fondée sur les sources ci-dessous.

Retour à l'accueil

Dernières actualités cybersécurité

Toutes les actualités cybersécurité →