ConnectWise a désactivé sept identités d’application liées à son environnement Cloud Backup après que des attaquants ont utilisé des identifiants d’application compromis pour accéder à des tenants Microsoft 365.
Huntress a confirmé des connexions non autorisées sur 162 tenants au 16 octobre, dont un cas où une autre application ConnectWise a obtenu les privilèges d’administrateur général et ajouté de nouveaux identifiants à d’autres applications.
L’accès côté fournisseur a été contenu, mais l’incident n’est pas terminé pour les administrateurs Microsoft 365. La désactivation des applications concernées n’annule pas les modifications de rôles, les identifiants, les règles de boîte aux lettres, les autorisations accordées ni les autres mécanismes de persistance qu’un attaquant a peut-être déjà créés au sein d’un tenant.
Dans ses dernières recommandations de sécurité pour Cloud Backup, ConnectWise demande à ses partenaires d’examiner leurs propres environnements Microsoft 365 ainsi que chaque tenant client qu’ils administrent, y compris ceux qui disposent d’anciennes connexions SkyKick ou de connexions dormantes.
Ce que ConnectWise a confirmé jusqu’à présent
Au 19 octobre, selon la dernière mise à jour de statut de ConnectWise, Cloud Backup, SaaS Security et Cloud Management restaient suspendus, tandis que les opérations de remédiation et de validation de sécurité se poursuivaient. Les sauvegardes planifiées, l’accès aux archives, les restaurations, la surveillance de la sécurité et certaines fonctions de gestion restaient indisponibles, sans délai de rétablissement confirmé.
ConnectWise affirme que les archives de sauvegarde existantes restent chiffrées et isolées et qu’il n’a aucune preuve que ces archives aient été consultées. Cela est plus limité que d’affirmer que les tenants Microsoft 365 des clients n’ont pas été touchés.
| Confirmé | Toujours en suspens |
|---|---|
| L’accès non autorisé a impliqué des identités d’application ConnectWise | La manière dont l’identifiant fournisseur initial a été exposé |
| Les sept identités d’application concernées ont été désactivées le 17 octobre | Le nombre total de tenants en aval concernés |
| Cloud Backup, SaaS Security et Cloud Management ont été suspendus | La question de savoir si des données ont été consultées dans les tenants de certains clients |
| ConnectWise n’a aucune preuve que les archives de sauvegarde aient été consultées | La question de savoir si les attaquants ont établi une persistance dans chaque tenant auquel ils ont réussi à accéder |
| Huntress a confirmé des connexions Microsoft 365 non autorisées | L’identité et les motivations de l’auteur de la menace |
Selon Huntress, l’attaquant s’est authentifié à l’aide d’un identifiant appartenant à l’application Cloud Backup elle-même, plutôt qu’en dérobant le mot de passe d’un utilisateur final. Les journaux de connexion Microsoft ont enregistré cette authentification comme une assertion client.
Cela modifie les éléments que les défenseurs doivent rechercher. L’authentification réservée aux applications n’implique pas qu’un utilisateur effectue une connexion classique : ce n’est donc pas l’authentification multifacteur de l’utilisateur qui est mise à l’épreuve. L’application s’authentifie avec son propre identifiant et obtient les accès autorisés par ses permissions existantes.
Ces permissions relèvent du même modèle d’autorisation OAuth que celui qu’utilisent les organisations pour permettre à des applications tierces d’accéder aux ressources cloud sans demander à une personne de se connecter à répétition.
Huntress a également découvert une deuxième vague de tentatives visant 16 organisations des secteurs des politiques publiques, de la sécurité nationale, du commerce et des minerais critiques. Beaucoup n’utilisaient pas les produits ConnectWise concernés, et les tentatives ont échoué lorsque le principal de service requis n’était pas présent.
Ce que les administrateurs Microsoft 365 doivent vérifier maintenant
ConnectWise recommande d’examiner l’activité à partir du 13 octobre et de remonter les recherches jusqu’au 1er octobre lorsque la durée de conservation des journaux le permet.
Commencez par les connexions des principaux de service, et pas seulement par la vue des connexions utilisateur. La documentation de Microsoft sur les principaux de service explique que ces enregistrements consignent l’authentification des applications à l’aide d’identifiants tels que des certificats et des secrets client.
L’ID d’application Cloud Backup à vérifier est le suivant :
506e08f9-6e9a-4da4-942b-a099a03644ae
ConnectWise a également publié trois adresses IP associées à l’activité suspecte :
144.172.64[.]128144.172.64[.]99144.172.64[.]60
Une correspondance doit déclencher une enquête, et non une conclusion automatique selon laquelle le tenant a été compromis.
Les administrateurs doivent également examiner :
- Les nouveaux identifiants d’application ou ceux qui ont été modifiés.
- Les attributions de rôles dans l’annuaire et les rôles d’administrateur.
- Les propriétaires d’applications et les autorisations accordées.
- Les relations d’approbation de fédération et les modifications de l’authentification.
- Les modifications récentes apportées à Conditional Access ou à d’autres stratégies.
- Le transfert de messages, les règles de boîte de réception, les règles de transport et les accès délégués.
- Les autres identités utilisateur ou d’application modifiées pendant la période suspecte.
Le guide de Microsoft sur les applications compromises recommande de vérifier les connexions des principaux de service, les identifiants inattendus, les rôles d’application privilégiés et les modifications inhabituelles des permissions lorsqu’une identité d’application pourrait avoir été compromise.
Cet examen plus large est important, car la suppression de l’identifiant ConnectWise d’origine ne supprime pas un second identifiant, une attribution de rôle ou une voie d’accès qu’un attaquant aurait créée après avoir pénétré dans le système.
Kasper Lindgaard, vice-président de la stratégie de sécurité chez CoreView, a déclaré qu’une connexion réussie devait élargir la réponse, au-delà de la simple vérification de la désactivation des applications ConnectWise concernées.
« Si des signes indiquent une connexion réussie de la part de l’auteur de la menace, l’incident doit être traité comme un incident de modification de configuration. Cela signifie qu’il faut cartographier clairement et annuler toute modification non confirmable effectuée entre le 1er octobre et le 17 octobre à 07:00 UTC.
Lindgaard a ajouté :
« ConnectWise a stoppé l’attaque. Mais les entreprises ont malheureusement la responsabilité et la tâche difficile de s’assurer que l’auteur de la menace n’a modifié aucune configuration Microsoft 365 ni établi de mécanisme de persistance au sein de leur tenant. Plus d’un tiers des responsables informatiques croient à tort que Microsoft sauvegarde automatiquement leur configuration, ce qui rend la récupération après une telle attaque d’autant plus délicate. »
Cela signifie que les administrateurs ont besoin d’une vue de l’état du tenant avant et après l’incident, et pas seulement d’une recherche des adresses IP publiées. Une connexion réussie d’une application, suivie de la création d’un nouveau secret, d’un rôle privilégié, d’une règle de boîte aux lettres, d’une autorisation ou d’une modification de stratégie, peut laisser une voie d’accès active après l’arrêt de l’application d’origine.
Ne reconnectez pas encore les applications
ConnectWise indique que les connexions concernées doivent rester désactivées jusqu’à la publication d’instructions officielles de restauration et de réautorisation.
Les administrateurs doivent également conserver les journaux disponibles avant d’effectuer des suppressions inutiles. ConnectWise recommande expressément de conserver les applications d’entreprise en place pendant l’enquête initiale, afin que leur configuration et leurs identifiants restent disponibles comme éléments de preuve.
L’incident met également en évidence une faiblesse plus générale liée aux accès applicatifs de longue durée. Les organisations doivent de plus en plus gérer des identités non humaines telles que les principaux de service, les identités d’application, les identifiants d’API et les agents automatisés, parallèlement aux comptes humains.
Ces identités doivent avoir des propriétaires nommément désignés, des permissions selon le principe du moindre privilège, une rotation des identifiants, une journalisation exploitable et des contrôles périodiques. Ces mêmes contrôles doivent faire partie de la gestion des risques liés aux tiers pour les fournisseurs SaaS qui conservent un accès permanent à des environnements cloud sensibles.
Pour les clients de ConnectWise, le travail immédiat est plus ciblé : conserver les éléments de preuve, trouver chaque connexion pertinente d’un principal de service, enquêter sur les modifications effectuées pendant la fenêtre d’exposition, supprimer les mécanismes de persistance et maintenir les applications concernées désactivées jusqu’à ce que ConnectWise indique qu’il est possible de les reconnecter sans risque.
À lire aussi : Des pirates de TeamFiltration ont exploité des comptes de service Microsoft 365 oubliés, un autre exemple d’identités non humaines créant une voie négligée vers des environnements cloud.