Quand une application cloud de confiance devient un chemin d’attaque

Illustration conceptuelle fournie par le propriétaire du site. Elle ne montre pas combien de locataires (tenants) clients ont été touchés, et elle ne suggère aucun nombre de locataires.

Un incident survenu en octobre 2026 autour de ConnectWise Cloud Backup a mis au jour un risque de sécurité qui dépasse les comptes des employés. Des attaquants ont utilisé des identifiants associés à des applications de confiance pour s’authentifier dans les environnements Microsoft 365 de plusieurs clients. L’incident montre pourquoi les identités des applications tierces font partie du périmètre de sécurité d’une organisation.

L’application était de confiance. Son identifiant ne l’était pas.

Les organisations autorisent régulièrement des applications tierces à accéder à leurs environnements Microsoft 365. Un service de sauvegarde cloud, par exemple, a besoin d’une permission pour récupérer des informations dans Exchange Online, SharePoint, OneDrive et d’autres services. Il utilise cet accès pour créer des sauvegardes et permettre la restauration.

Le service de sauvegarde doit fonctionner même lorsqu’aucun employé n’est connecté. Une organisation autorise donc l’identité de l’application, plutôt que d’exiger qu’une personne approuve chaque opération planifiée.

En octobre 2026, ce mode de fonctionnement s’est retrouvé au cœur d’un incident de sécurité impliquant ConnectWise Cloud Backup, anciennement SkyKick. ConnectWise a confirmé un accès non autorisé impliquant des identités d’application associées à son environnement de sauvegarde cloud. Des enquêteurs en sécurité indépendants ont observé des attaquants qui s’authentifiaient au moyen de ces identités auprès de locataires Microsoft 365 de clients.

Le 15 octobre, Sophos X-Ops a repéré des demandes d’authentification automatisées dans lesquelles l’identité de l’application ConnectWise Cloud Backup servait à obtenir des jetons d’accès Microsoft Graph. De son côté, Huntress a signalé des connexions non autorisées dans 162 locataires clients au 16 octobre à 19 h UTC.

Ces constats établissent que des identités d’application de confiance étaient utilisées sans autorisation. Ils n’établissent pas que les 162 locataires ont tous subi un vol de données, une compromission administrative ou un accès persistant de l’attaquant.

Les enquêteurs ont aussi observé, dans au moins un locataire, des modifications plus graves de permissions d’application et d’identifiants. Ces constats doivent être examinés séparément, car les éléments disponibles n’établissent pas que toute l’activité liée a été menée par le même attaquant. Sources : ConnectWise Trust Center, enquête de Sophos X-Ops et enquête de Huntress.

Comment une application de sauvegarde accède à Microsoft 365

Pour comprendre cet incident, il faut distinguer l’identité d’un employé de celle d’une application. Lorsqu’un employé accède à Outlook, Microsoft Entra ID authentifie cette personne selon les exigences de connexion de l’organisation. Celles-ci peuvent inclure l’authentification multifacteur, des vérifications de l’appareil et des politiques d’accès conditionnel (Conditional Access).

Un service de sauvegarde automatisé fonctionne autrement. Il doit accéder aux informations sans qu’un employé soit présent. Microsoft Entra le permet grâce aux identités d’application, qui autorisent un logiciel à s’authentifier et à demander l’accès à des services.

Pour une application tierce utilisée par de nombreuses organisations, Microsoft Entra distingue deux objets liés. L’inscription d’application (application registration) représente l’application logicielle. L’éditeur la gère dans son propre locataire, y compris les identifiants utilisés pour authentifier l’application.

Un principal de service (service principal) représente la présence de cette application dans un locataire client donné. Il fournit l’identité locale à laquelle des permissions et des accès peuvent être attribués. Une application multilocataire peut donc avoir une seule inscription d’application contrôlée par l’éditeur, et des principaux de service distincts dans de nombreuses organisations clientes.

C’est une conception courante des plateformes de logiciel en tant que service (SaaS). Chaque client décide s’il autorise l’application et quelles permissions il lui accorde. L’éditeur contrôle normalement l’identifiant que son application utilise pour prouver son identité.

Microsoft décrit cette relation dans sa documentation sur les objets d’application et principaux de service.

Comment fonctionne la connexion d’une application

Prenons un service de sauvegarde qui récupère des informations dans un locataire client. L’application s’authentifie auprès de Microsoft Entra à l’aide d’un identifiant pris en charge, comme un secret client ou un certificat, et demande un jeton d’accès pour une ressource donnée.

Microsoft Entra vérifie l’identité de l’application, évalue les exigences d’autorisation et de politique applicables, et détermine si la demande peut être approuvée. Si ces vérifications réussissent, Entra émet un jeton d’accès pour la ressource demandée, qui reflète les permissions autorisées de l’application. L’application présente ce jeton à Microsoft Graph, qui évalue si l’opération demandée est permise.

Deux décisions de sécurité distinctes interviennent. L’authentification établit quelle identité fait la demande. L’autorisation détermine ce à quoi cette identité peut accéder ou ce qu’elle peut modifier.

Un identifiant d’application valide ne donne pas un accès illimité à tous les locataires ou services Microsoft 365. L’accès dépend de la présence de l’application dans le locataire cible, des permissions qui lui ont été accordées et des éventuelles restrictions applicables.

Microsoft Entra prend en charge deux modèles de permissions importants. Avec les permissions déléguées, une application agit dans le contexte d’un utilisateur connecté. Avec les permissions d’application, un logiciel peut agir sans utilisateur connecté, dans la limite des permissions qui lui sont autorisées.

L’activité liée aux jetons ConnectWise reposait sur une authentification d’application seule (application-only), selon le modèle OAuth 2.0 des identifiants client (client credentials). C’est pourquoi l’attaquant n’a pas eu besoin d’obtenir le mot de passe d’un employé en particulier, ni de franchir la vérification MFA interactive habituelle de cet employé.

Cela ne signifie pas que la MFA a mal fonctionné. Cela ne signifie pas non plus que les identités d’application n’ont aucun contrôle de sécurité. Cela signifie que l’attaquant tentait de s’authentifier en tant qu’identité de charge de travail, et non en tant qu’utilisateur humain.

Le périmètre de sécurité a cédé lorsque l’attaquant a obtenu un identifiant capable de prouver l’identité d’une application que les clients avaient déjà autorisée.

Comment un seul identifiant a pu atteindre plusieurs organisations

ConnectWise Cloud Backup a été conçu pour fonctionner sur plusieurs locataires Microsoft 365. Chaque client gérait son propre environnement et accordait l’accès à l’application selon son propre processus d’autorisation. Pourtant, l’identifiant d’application contrôlé par l’éditeur pouvait servir à authentifier la même identité d’application dans les locataires clients qui y avaient consenti.

Un attaquant en possession de cet identifiant pouvait donc tenter de s’authentifier auprès de plusieurs organisations sans compromettre séparément les comptes des employés de chacune. Sophos a observé ce mécanisme lors d’un balayage automatisé de jetons (token sweep), le 15 octobre.

Les demandes provenaient d’un serveur privé virtuel situé à l’adresse 144.172.64[.]128 et visaient les locataires clients dans un ordre systématique. Sophos a observé l’activité pendant environ 96 minutes et a indiqué ne pas pouvoir déterminer ce que l’attaquant avait finalement fait des jetons émis. De son côté, Huntress a observé une authentification non autorisée impliquant la même infrastructure source, même si son enquête portait sur un autre ensemble de locataires et d’observations.

Sur le plan technique, l’important est que l’attaquant utilisait une relation d’autorisation qui existait déjà entre chaque client et l’application de l’éditeur. Les locataires clients n’étaient pas fusionnés en un seul environnement de sécurité. Chacun conservait ses propres permissions et contrôles. Mais le même identifiant compromis de l’éditeur pouvait être présenté partout où cette application était autorisée.

Pour un service de sauvegarde, les permissions accordées peuvent inclure l’accès aux boîtes aux lettres, aux fichiers, aux informations d’annuaire et aux opérations nécessaires à la restauration. Un attaquant qui obtient un jeton d’accès pourrait potentiellement exercer les permissions que représente ce jeton.

Les preuves doivent toutefois être interprétées avec prudence. Une demande d’authentification n’est pas une connexion réussie. Une connexion réussie ne prouve pas nécessairement qu’une opération Microsoft Graph demandée a abouti. Et un jeton valide n’établit pas que des informations client ont été téléchargées ou modifiées.

Ce sont des constats différents, qui exigent des preuves différentes. Sources : analyse technique de Sophos X-Ops et enquête de Huntress sur l’incident.

L’enquête a aussi mis au jour une voie d’accès persistant

Les demandes de jetons non autorisées n’étaient pas les seuls constats préoccupants. Huntress a documenté, le 15 octobre, une séquence distincte de modifications d’identités d’application dans un locataire client.

Entre environ 3 h 44 et 3 h 49 UTC, une application liée, nommée ConnectWise Cloud Management – MS Teams, s’est attribué le rôle d’annuaire Administrateur général (Global Administrator). Au cours de la même période, elle a modifié deux autres identités d’application en leur ajoutant de nouveaux secrets client.

L’une de ces identités appartenait à une application de gestion de prestataire de services managés (MSP). L’autre appartenait à l’application Huntress Security Platform dans ce locataire. Huntress a ensuite repéré une authentification réussie à l’aide d’un identifiant non autorisé associé à son application.

Ces observations montrent pourquoi les modifications d’identifiants d’application comptent dans une enquête sur les identités cloud.

Comment un second identifiant crée un chemin d’accès distinct

Un secret client permet à une application de s’authentifier sous son identité inscrite. Si un attaquant dispose d’une autorisation suffisante pour ajouter un nouveau secret à une autre application, il peut être en mesure de s’authentifier avec l’identité de cette application et ses permissions existantes. Cela crée un chemin d’accès distinct de l’identifiant compromis d’origine.

Par exemple, désactiver l’identité ConnectWise Cloud Backup ne supprimerait pas automatiquement un secret non autorisé ajouté à une application de gestion sans rapport. La seconde application doit faire l’objet d’une enquête, et ses identifiants non autorisés doivent être supprimés ou invalidés selon le processus de réponse approprié.

Cependant, posséder l’identifiant d’une application ne donne pas automatiquement le pouvoir de modifier une autre application ou d’attribuer un rôle privilégié. Ces actions exigent des permissions ou des privilèges distincts. Cette distinction est particulièrement importante, car l’incident impliquait plusieurs identités d’application ConnectWise aux relations d’autorisation différentes.

Ce que les enquêteurs ont pu établir, et ce qu’ils n’ont pas pu établir

La chronologie de l’activité observée compte. Huntress a enregistré les attributions du rôle Administrateur général et la création d’identifiants supplémentaires avant l’activité d’authentification ultérieure depuis l’adresse IP publique identifiée.

Les événements antérieurs impliquaient un trafic enregistré depuis un espace d’adresses privées hébergé par Microsoft. Huntress n’a pas pu établir que l’activité antérieure et le balayage de jetons ultérieur depuis l’adresse IP publique avaient été menés par le même opérateur. Huntress a aussi observé d’autres attributions de rôles à des applications qui ressemblaient à une automatisation légitime de ConnectWise, ce qui exigeait une enquête plus poussée plutôt qu’une attribution automatique à l’attaquant.

Le 21 octobre, ConnectWise a déclaré que, d’après les éléments dont elle disposait, notamment des renseignements sur les menaces partagés par Microsoft, il apparaît qu’un groupe aligné sur l’État chinois était responsable de l’attaque contre ConnectWise Cloud Backup, et que ce groupe a utilisé un framework d’IA agentique librement accessible. C’est l’évaluation de l’éditeur. Sophos n’a nommé aucun acteur, et Huntress n’avait pas relié au même opérateur les phases antérieure et ultérieure de l’activité. Source : ConnectWise Trust Center.

Les éléments disponibles permettent donc une conclusion précise :

Des authentifications d’application non autorisées ont eu lieu dans plusieurs locataires clients, et une séquence distincte et préoccupante de persistance par identifiants a été documentée dans au moins un locataire. Le lien complet entre ces activités n’a pas été établi.

Il serait inexact de les présenter comme une seule séquence d’attaque reconstituée de façon concluante et touchant tous les clients. Source : Huntress, enquête sur l’identifiant fournisseur ConnectWise/SkyKick.

Pourquoi le confinement par l’éditeur n’a pas suffi à la remédiation chez les clients

ConnectWise a réagi en désactivant les identités d’application concernées, en révoquant des identifiants et en suspendant les services cloud liés pendant son enquête. Selon ses recommandations du 18 octobre, l’entreprise a désactivé sept identités d’application ConnectWise le 17 octobre à 7 h UTC.

Cette action a empêché toute nouvelle authentification par les connexions concernées. Elle n’a pas annulé automatiquement les modifications déjà apportées dans les locataires Microsoft 365 des clients. Les jetons émis auparavant pouvaient rester valides jusqu’à leur expiration ou leur invalidation effective. Surtout, les identifiants, permissions ou attributions privilégiées supplémentaires établis sur des identités distinctes exigeaient leur propre enquête.

Il faut aussi distinguer le fait qu’un éditeur désactive la connexion d’une application, et le fait qu’un client vérifie l’état de l’application d’entreprise correspondante dans son propre locataire. Ce sont deux contrôles administratifs distincts.

La réponse à l’incident comporte donc deux volets liés. ConnectWise doit sécuriser ses propres identifiants d’application, enquêter sur ses services et confirmer quand les connexions concernées peuvent être rétablies sans risque. Les administrateurs des clients et les prestataires de services managés doivent établir si une activité non autorisée a eu lieu dans les locataires dont ils sont responsables.

Ce que les administrateurs doivent examiner

L’enquête doit se concentrer sur les éléments liés aux identités d’application concernées, plutôt que de modifier sans discernement des identifiants sans rapport.

Les journaux de connexion des principaux de service peuvent montrer les authentifications impliquant des identités de charge de travail. Ces événements sont distincts de l’activité de connexion ordinaire des employés et peuvent ne pas être visibles dans les rapports que les administrateurs consultent habituellement.

Les journaux d’audit Microsoft Entra peuvent révéler les modifications des identifiants d’application, des permissions, des principaux de service et des attributions de rôles d’annuaire. Les enquêteurs doivent examiner quelle identité a initié une modification, quelle identité a été modifiée et si un identifiant inattendu a ensuite été utilisé.

ConnectWise recommande d’examiner l’activité pertinente à partir du 13 octobre 2026, et d’élargir l’enquête lorsque les éléments disponibles l’exigent. Sophos et Huntress fournissent aussi des indicateurs propres à l’incident, notamment des adresses sources, des identités d’application et les logiciels clients observés.

Ces indicateurs doivent être interprétés dans leur contexte. Une adresse IP suspecte peut étayer une enquête, mais l’absence de cette adresse ne prouve pas qu’un locataire n’a pas été touché. De même, des adresses de réseau privé hébergées par Microsoft peuvent apparaître dans une activité légitime et ne désignent pas à elles seules un attaquant.

Une autre limite importante concerne la visibilité. Les journaux de connexion de Microsoft Entra peuvent établir qu’une application s’est authentifiée. Les journaux d’audit peuvent montrer des modifications d’identités et de permissions. Ils n’enregistrent pas nécessairement chaque information qu’une application a lue ensuite via Microsoft Graph.

Lorsque des journaux d’activité Graph supplémentaires sont disponibles, ils peuvent aider les enquêteurs à établir les opérations effectuées ensuite. Leur disponibilité et leur couverture dépendent de la configuration, des licences et des dispositifs de journalisation du locataire. Par conséquent, l’absence d’événement d’accès aux données observé ne permet pas toujours d’établir qu’aucun accès n’a eu lieu.

Les administrateurs doivent conserver les preuves pertinentes, vérifier l’état des applications et suivre les recommandations en vigueur de l’éditeur lorsqu’ils désactivent ou reconnectent les applications concernées. Supprimer immédiatement les objets d’application risque de faire disparaître un contexte utile à l’enquête. Les recommandations de réponse à incident préconisent de désactiver les connexions concernées tout en conservant ce qui est nécessaire pour comprendre leur activité.

Changer les mots de passe des employés ou révoquer les sessions des utilisateurs ne suffirait pas, à soi seul, à régler le problème des identifiants non autorisés associés à des identités d’application. Sources : ConnectWise Trust Center et recommandations de remédiation, enquête de Sophos X-Ops et constats techniques de Huntress.

Les conséquences pour les sauvegardes des clients

L’enquête de sécurité a aussi provoqué une perturbation opérationnelle. ConnectWise a suspendu Cloud Backup et les services liés le temps de sécuriser son environnement et de valider les connexions d’application concernées. Les sauvegardes planifiées, l’accès aux archives et les capacités de restauration ont été interrompus pendant la suspension.

ConnectWise a indiqué que les archives Cloud Backup existantes restaient chiffrées et isolées, sans indice, à ce moment-là, d’une compromission de ces archives. Ce constat concerne les sauvegardes stockées par le fournisseur. Il n’établit pas que l’environnement Microsoft 365 en production de chaque client a été épargné par l’authentification d’application non autorisée.

Un attaquant pourrait potentiellement utiliser les permissions Microsoft Graph accordées à une application de sauvegarde pour accéder à des informations dans un locataire en production, sans compromettre l’archive distincte où sont stockées les données déjà sauvegardées. Les deux sujets doivent donc rester distincts : la sécurité des archives de sauvegarde existantes, et l’accès non autorisé aux environnements clients en production.

ConnectWise a commencé un rétablissement progressif du service le 21 octobre, mais cela ne confirmait ni que tous les services avaient été rétablis, ni que tous les locataires clients concernés avaient terminé leur enquête. Les administrateurs ont reçu pour consigne de garder les connexions d’application concernées désactivées jusqu’à la publication de recommandations officielles de rétablissement et de reconnexion. Source : ConnectWise Trust Center.

Ce que montre cet incident

L’incident ConnectWise n’établit pas que les applications Microsoft 365 tierces sont dangereuses par nature. Les plateformes de sauvegarde et de gestion cloud ont besoin d’accéder aux environnements des clients pour fournir leurs services. Les identités d’application multilocataires et l’authentification d’application seule font normalement partie de cette architecture.

Le risque apparaît lorsqu’un attaquant obtient l’identifiant qui sert à prouver l’identité d’une application que les clients ont déjà autorisée.

Dans ce cas, les enquêteurs ont confirmé des authentifications d’application non autorisées dans plusieurs locataires clients. Huntress a aussi documenté des modifications privilégiées d’applications et des identifiants non autorisés dans un locataire précis, tout en reconnaissant explicitement les limites de l’attribution des différentes phases de l’activité.

Ces constats expliquent pourquoi le remplacement de l’identifiant d’origine de l’éditeur était nécessaire, mais insuffisant pour établir que chaque environnement client était sécurisé. Les organisations devaient aussi déterminer si l’accès avait été étendu au moyen d’identités, de permissions ou d’identifiants distincts.

Le périmètre de sécurité d’une organisation Microsoft 365 inclut les applications tierces qu’elle autorise, et pas seulement les personnes qui se connectent à ses systèmes.

Protéger les comptes utilisateurs reste essentiel. Comprendre et surveiller les identités d’application est une responsabilité distincte, en particulier lorsqu’un seul identifiant contrôlé par un éditeur peut être reconnu comme fiable dans de nombreux locataires clients.

Pour aller plus loin

Recherches examinées le 21 octobre 2026. Les enquêtes sur l’incident peuvent produire de nouveaux constats. Les nombres de locataires reflètent des observations datées, et non le nombre final d’organisations dont le vol de données ou la compromission persistante a été confirmé.

Avis et recommandations de l’éditeur

• ConnectWise Trust Center, Cloud Backup incident advisories : déclarations officielles sur l’incident, mesures de confinement, services concernés et instructions de rétablissement.
• ConnectWise Cloud Backup Technical Investigation and Remediation Guide, octobre 2026 : identifiants des applications, périmètre de l’enquête, conservation des preuves et recommandations de remédiation pour les clients.

Enquêtes indépendantes

• Sophos X-Ops, ConnectWise Cloud Backup application abused in cross-tenant token sweep : analyse indépendante de l’authentification d’application automatisée et des demandes de jetons Microsoft Graph.
• Huntress, ConnectWise/SkyKick vendor credentials abused in Microsoft 365 attacks : observations d’authentifications non autorisées, modifications privilégiées d’applications, persistance par identifiants et limites de l’attribution.
• Kudelski Security, ConnectWise Cloud Backup vendor credential abuse : analyse indépendante de l’incident et contexte technique.

Documentation Microsoft

• Microsoft, Application objects and service principals : explique les inscriptions d’application, les principaux de service dans les locataires clients et l’autorisation multilocataire.
• Microsoft, Service-principal sign-ins : explique les journaux d’authentification des identités de charge de travail.
• Microsoft, Application authorization and resource access : explique les décisions d’accès des applications et les limites d’autorisation.

Les organisations qui enquêtent sur une exposition potentielle doivent suivre les recommandations de sécurité en vigueur de ConnectWise et de Microsoft adaptées à leur environnement.

À lire aussi sur TechiesJournal

• La frontière des identifiants MCP : pourquoi un serveur MCP ne devrait pas décider où vont vos identifiants OAuth (en anglais), pour un autre regard sur les situations où les identifiants d’application méritent, ou non, la confiance.
• Attaques de la chaîne d’approvisionnement CI/CD : comment les attaquants atteignent votre pipeline (en anglais), pour une autre façon dont une connexion de confiance peut devenir un point d’entrée.