La plupart des organisations croient savoir où sont leurs portes d'entrée. Il y a la page de connexion, la politique de mots de passe, l'application d'authentification qui vibre à deux heures du matin et la règle d'accès conditionnel qui bloque un pays suspect. Les équipes sécurité passent des années à tout renforcer.
Puis un service de sauvegarde entre par une porte qui n'a jamais figuré sur le plan.
Entre 06h13 et 08h34 UTC le 15 octobre 2026, un acteur inconnu a utilisé un identifiant compromis de ConnectWise Cloud Backup, anciennement SkyKick, pour obtenir des jetons Microsoft Graph dans des locataires Microsoft 365 où l'application était installée. Huntress a confirmé des connexions non autorisées dans 173 locataires partenaires et clients. Sa télémétrie élargie montre une activité depuis la même adresse contre près de 1 000 locataires Entra, dont plus de 300 réussies. Le trafic avançait dans l'ordre des GUID, quelques secondes par locataire : c'est un script qui parcourt une liste, pas un humain.
Personne n'a tapé de mot de passe. Personne n'a validé de notification push. L'application a fait exactement ce pour quoi elle a été conçue.
Ce que l'attaquant a hérité
ConnectWise Cloud Backup protège les données Microsoft 365 et Google Workspace des prestataires gérés et de leurs clients. Pour cela, elle reçoit un consentement large et permanent : lecture et écriture sur les boîtes mail, OneDrive, SharePoint, les conversations Teams et l'annuaire, y compris les droits de restauration.
Celui qui détient cet identifiant n'a rien à élever. Il hérite de tout. Selon l'analyse de Todyl, l'accès couvrait les droits complets sur les boîtes via Exchange Web Services, les fichiers OneDrive et SharePoint, les messages Teams et la lecture d'annuaire, avec la capacité de restaurer des données. Ce n'est pas un point d'appui : c'est tout le système.
La connexion venait de 144.172.64[.]128, une adresse de la plage RouterHosting. Les connexions légitimes de cette application sortent normalement de l'espace IPv6 privé d'Azure : l'anomalie était donc visible pour qui filtrait dessus. Le mot important est « qui filtrait ». Les connexions des principaux de service vivent dans un onglet séparé d'Entra. Si votre supervision ne regarde que les utilisateurs, cet événement n'a produit aucun bruit.
Pourquoi le MFA et l'accès conditionnel n'ont jamais réagi
Le MFA authentifie des humains. Les politiques d'accès conditionnel visent des utilisateurs et des groupes. Une application qui s'authentifie avec son propre secret ou certificat n'est ni l'un ni l'autre. C'est un principal de service, et son jeton est émis parce que l'identifiant correspond, pas parce qu'une personne a relevé un défi.
Les contrôles habituels n'ont donc pas été contournés : ils étaient hors périmètre. Le périmètre ici n'était pas la vérification d'identité, c'était le consentement. Chaque locataire où l'application avait été approuvée était atteignable avec un seul identifiant. Révoquer les sessions utilisateurs ne sert à rien non plus. Désactiver l'application arrête les nouveaux jetons, mais ceux déjà émis restent valides jusqu'à 90 minutes, largement assez pour un balayage automatisé.
La seconde blessure : une application qui s'est couronnée
Dans au moins deux locataires, le comportement est allé au-delà de la lecture. Vers 03h45 UTC, à deux minutes d'intervalle, l'application ConnectWise Cloud Management pour Microsoft Teams s'est attribué le rôle d'administrateur global, puis a exécuté un script (Python-urllib/3.12) déposant de nouveaux secrets clients sur quelques autres applications enregistrées. Dans un cas, cela incluait une application Huntress, et séparément une application de gestion de MSP.
Regardez la forme de cela. Une application de gestion est exactement le type d'outil que les MSP consentent dans les locataires de leurs clients. Un identifiant ajouté là ne vaut pas pour un locataire : c'est une clé qui peut fonctionner dans tous ceux qui font confiance à cet outil. Huntress a retiré l'identifiant non autorisé de sa propre application le 16 octobre et a activé App Instance Property Lock.
Huntress a aussi noté ce qu'elle n'a pas vu : aucune manipulation de boîtes ou de fichiers, aucun changement d'utilisateur ou de politique dans les deux locataires examinés. Et un avertissement qui pèse plus que l'absence de preuve : les lectures d'annuaire Graph ne laissent généralement aucune trace. On ne peut pas prouver que les données n'ont pas été touchées quand les lectures n'ont jamais été journalisées.
Le reste de la journée
La même adresse a servi dans une seconde vague, plus étroite, le 15 octobre entre 09h25 et 12h35 UTC puis de 13h54 à 14h20 UTC, contre 16 locataires protégés par Huntress dans les secteurs politique, sécurité nationale, commerce et minéraux critiques. La plupart n'utilisaient pas de produits ConnectWise : les tentatives ont échoué parce que l'application était absente. Ce détail résume tout l'argument du moindre privilège : l'absence de l'application fut le contrôle qui les a sauvés.
La même infrastructure avait aussi mené du password spraying contre quatre cabinets d'avocats les 13 et 14 octobre. ConnectWise a désactivé l'accès de Cloud Backup jusqu'à nouvel ordre et affirme n'avoir trouvé aucune preuve de compromission des données de sauvegarde partenaires.
Ce qu'il faut faire cette semaine, pas au prochain trimestre
- Ouvrez les journaux de connexion des principaux de service. Dans le centre d'administration Microsoft Entra : Supervision, Journaux de connexion, onglet des principaux de service. Filtrez sur l'ID d'application 506e08f9-6e9a-4da4-942b-a099a03644ae et examinez le 15 octobre. Répétez pour Exchange Online b78f6a77-d4e5-46fb-87e5-d1648bd02519, Teams 24205314-2b89-4e07-a2a4-579e898a5640 et SharePoint b2b55f5b-7758-4719-8d8f-88ae172e6bdb.
- Traquez l'adresse incongrue. Toute authentification hors des plages Microsoft attendues est un constat. 144.172.64[.]128 est l'indicateur principal ; 144.172.64[.]99, .60 et 144.172.94[.]243 apparaissent dans des tentatives échouées liées.
- Désactivez les applications, ne les supprimez pas. Supprimer détruit la trace d'audit dont vous aurez besoin. Gardez-les désactivées jusqu'à confirmation de la rotation par ConnectWise.
- Auditez chaque secret et certificat ajouté à une inscription d'application depuis le 13 octobre, y compris les identifiants fédérés. Une date d'expiration inattendue en 2027 ou 2028 est un marqueur de persistance.
- Vérifiez les attributions de rôles d'annuaire pour les applications et l'historique de la gestion des identités privilégiées.
- Activez les journaux d'activité Graph et l'audit unifié maintenant. On ne peut pas enquêter sur des lectures jamais enregistrées.
- Partez du principe que les données lisibles ont été lues. Vérifiez les règles de boîte et les transferts, les liens de partage, et informez les responsables de la confidentialité client.
- Réduisez les consentements permanents. Portées minimales, verrouillage des propriétés d'instance et revue régulière de chaque application tierce dans chaque locataire.
La leçon pour les entreprises en croissance
Si vous dirigez une entreprise de 40 personnes sur Microsoft 365, vous avez presque sûrement plusieurs applications approuvées il y a des années par quelqu'un qui est parti, chacune avec un accès large et permanent. C'est la même exposition, à plus petite échelle.
La leçon inconfortable du 15 octobre n'est pas que ConnectWise ait été négligent. C'est que notre modèle de sécurité des identités s'arrête à l'humain. Les principaux de service, les consentements et les identifiants applicatifs sont le véritable périmètre d'un locataire moderne, et dans la plupart des organisations personne n'en est responsable.
Un identifiant. Cent soixante-treize locataires. Aucune demande MFA nulle part. Réparez l'inventaire avant que l'inventaire ne vous répare.