ConnectWise Cloud Backup : l’application n’a jamais eu besoin de MFA

L’attaquant s’est connecté en tant qu’application

Vos utilisateurs ont passé la MFA. L’attaquant, lui, s’est connecté en tant qu’application. C’est la frontière d’identité derrière l’incident ConnectWise Cloud Backup : un identifiant d’application a servi à demander un accès au titre d’autorisations déjà accordées dans les tenants des clients. Un contrôle conçu pour éprouver la connexion d’une personne n’a jamais été la porte de ce chemin.

L’avis de ConnectWise, consulté le 20 octobre 2026, confirme un accès non autorisé à des identités d’application et décrit le confinement. Il laisse toutefois le mécanisme initial d’exposition de l’identifiant en cours d’investigation. Cet article est une analyse d’architecture fondée sur les sources, pas une reconstitution dans un tenant réel. La question durable est de savoir quel accès une intégration conserve lorsque l’identifiant de son opérateur est entre des mains hostiles. [1][2]

Le consentement crée une identité aux autorisations permanentes

Les autorisations d’application diffèrent des autorisations déléguées. Dans le flux des informations d’identification du client, le logiciel s’authentifie en son nom propre, sans utilisateur connecté. Une application multilocataire possède un principal de service dans chaque tenant où elle est utilisée ; le consentement et les autorisations attribuées définissent ce que cette identité peut y faire. Réinitialiser le mot de passe d’un utilisateur ne révoque pas l’identifiant de l’application et ne réécrit pas ces octrois. [3][4]

C’est pourquoi je commence la revue d’une intégration par l’ensemble des autorisations, et non par l’étiquette commerciale de l’éditeur. La sauvegarde et la restauration justifient légitimement un large accès aux données, mais une capacité de lecture, une capacité d’écriture et le droit de modifier des identités n’ont pas les mêmes conséquences. Consignez les octrois et les rôles d’annuaire exacts de votre tenant. Ne supposez pas que tous les clients ont accordé les mêmes droits, ni que le mot « sauvegarde » cantonne l’application à la lecture.

Conceptual app-only path

Vendor application credential
  -> token request for customer tenant
  -> customer service principal + granted permissions
  -> access token for a resource
  -> resource operation

No user password or MFA prompt is part of this flow.

Votre stratégie couvre-t-elle ce type d’application ?

La documentation de Microsoft sur l’accès conditionnel pour les identités de charge de travail exclut de ces stratégies de principaux de service les applications SaaS tierces et multilocataires. Acheter la licence concernée ne lève pas cette restriction de périmètre. La documentation sur l’évaluation continue de l’accès pour les charges de travail limite elle aussi la prise en charge aux principaux de service monolocataires enregistrés dans le tenant. Le nom d’une fonctionnalité ne prouve pas qu’une identité donnée est couverte. [5][6]

La revue pratique est un exercice de mise en correspondance : pour chaque intégration, nommez le contrôle qui évalue sa demande de jeton, la ressource qui accepte le jeton et les autorisations qu’elle peut exercer. Là où une stratégie ne s’applique pas, consignez l’écart et les restrictions compensatoires disponibles. La MFA des utilisateurs reste précieuse pour l’accès des utilisateurs ; prétendre qu’elle gouverne aussi les identifiants d’application laisse une identité distincte sans examen.

Désactiver une application ne répond qu’à une partie du confinement

Empêcher l’émission de nouveaux jetons et invalider les accès existants sont deux opérations différentes. Microsoft documente une durée de vie par défaut des jetons d’accès de 60 à 90 minutes, mais ce n’est pas un compte à rebours universel pour un incident. Les paramètres des jetons, le comportement de chaque ressource et les mécanismes de révocation pris en charge entrent en jeu. ConnectWise précise que les jetons déjà émis peuvent rester utilisables jusqu’à leur expiration ou à une autre invalidation. Intégrez cette distinction au plan de réponse plutôt que de supposer que désactiver revient à déconnecter instantanément. [1][7]

Il existe un troisième état : un accès créé au travers d’une autre identité. Huntress signale des identifiants non autorisés ajoutés à d’autres applications dans les tenants touchés. Désactiver l’application ConnectWise d’origine ne supprime pas ces identifiants. Mon modèle de clôture comporte donc trois lignes distinctes : nouvelle émission bloquée, accès déjà émis pris en compte, et accès dérivé non autorisé supprimé. Attendre quatre-vingt-dix minutes ne prouve pas la troisième ligne. [2]

Containment question                 Evidence to request
New tokens still issued?             Application state + sign-in outcomes
Existing token still accepted?       Resource behavior + expiry/invalidation
New independent access established?  Credential, grant and role-change review

Elapsed time alone is not a closure record.

Une connexion réussie prouve un accès, pas toutes les actions possibles

Une connexion réussie d’un principal de service prouve quelque chose de plus limité que la lecture de toutes les boîtes aux lettres. L’enquête publiée par Todyl décrit une activité de connexion sans les modifications de persistance recherchées dans les tenants examinés. Huntress décrit des modifications post-compromission ailleurs. Ce sont des ensembles d’observations différents, pas des raisons de projeter le pire résultat observé sur chaque client. L’autorisation établit la capacité ; les preuves au niveau des opérations établissent l’usage observé. [2][8]

Le raccourci inverse est tout aussi dangereux. Une vue vide des connexions utilisateur ne couvre pas les connexions des principaux de service, que Microsoft enregistre séparément. L’absence d’entrées d’audit ne prouve pas non plus que toute lecture de données possible aurait été journalisée. Gardez une affirmation bornée : quelle télémétrie était disponible, quelles identités et ressources elle couvrait, et quelles opérations elle peut réellement montrer. « Inconnu » est une conclusion utile lorsqu’elle préserve l’étape suivante de l’enquête. [2][9]

Suivre les modifications de l’application d’origine vers d’autres identités

Recherchez par ID d’application, puis corrélez les connexions des principaux de service avec les événements d’audit de la fenêtre de l’incident. L’ID de Cloud Backup ci-dessous est un premier point d’ancrage, pas l’inventaire complet des applications concernées ; utilisez la liste à jour de l’éditeur pour l’ensemble de la famille d’applications. Conservez l’initiateur, la cible, le résultat et les identifiants de corrélation. Suivez les modifications dont une application listée est l’acteur aussi bien que celles apportées à cette application. [1]

Examinez les identifiants, octrois de consentement et attributions de rôles inconnus au regard des registres de responsables approuvés avant de les qualifier de malveillants. Les dates de validité d’un identifiant ne suffisent pas à établir quand il a été ajouté. Consignez ce qui a été supprimé, pourquoi, et quelle autre identité cela rendait possible. On obtient ainsi une chaîne qu’un autre relecteur peut suivre, au lieu d’une capture d’écran montrant qu’une application d’entreprise est désactivée. [1]

Initial application ID: 506e08f9-6e9a-4da4-942b-a099a03644ae
Product label: ConnectWise Cloud Backup / formerly SkyKick

Investigation record:
  tenant + application ID + local service principal ID
  event time + initiator + target + outcome + correlation ID
  credential or permission change + approved owner record
  containment action + remaining access + evidence limits

Demandez ce qui survit au bouton « Désactiver »

La question d’acceptation d’une intégration tierce devrait être rédigée avant tout incident : si son identifiant fuit demain, quelle action côté client arrête les nouveaux accès, qu’advient-il des jetons déjà émis, et comment retrouverions-nous les autorisations ou identifiants créés ailleurs ? Exigez des responsables nommés pour ces réponses. Une intégration sans responsable actuel conserve tout accès qui n’a pas été retiré.

Les mêmes questions définissent une mission utile de vérification de la remédiation après un incident. Je vérifierais les preuves de chaque état de confinement et je suivrais les modifications apportées à d’autres identités avant de considérer l’application d’origine comme l’ensemble du problème. Rétablir le service de sauvegarde et prouver que l’accès au tenant est maîtrisé sont des décisions liées qui exigent des preuves distinctes.