Automatisation de la destruction des locataires Entra ID avec l'IA

Comment l'IA peut automatiser la destruction d'un tenant Entra ID via Microsoft Graph, Graph Explorer et l'automatisation côté navigateur

Cet article montre comment l'automatisation du navigateur assistée par IA peut être utilisée pour piloter des opérations destructrices de Microsoft Graph contre un tenant Entra ID lorsque le compte connecté dispose des autorisations requises.

Comment l'IA automatise Graph Explorer pour la destruction d'un tenant Entra ID

Microsoft Graph Explorer est un outil basé sur le navigateur permettant d'envoyer des requêtes à l'API Microsoft Graph contre un tenant Entra ID. Il est normalement utilisé par les administrateurs et les développeurs pour tester les appels d'API, inspecter les réponses et comprendre quelles autorisations sont requises. Dans cet article, je l'utilise pour démontrer comment l'accès à Microsoft Graph peut être exploité pour des opérations automatisées et destructrices sur un tenant, et pourquoi ces mêmes flux de travail deviennent dangereux lorsqu'ils sont associés à un assistant IA capable de piloter le navigateur.

Exemples concrets de destruction de tenant

La destruction de tenant ne se limite plus au chiffrement des serveurs par des rançongiciels. En mars 2026, Stryker a divulgué une cyberattaque qui a perturbé son environnement Microsoft, et Sygnia a ensuite rapporté que l'attaquant avait utilisé Microsoft Intune pour effacer l'infrastructure virtuelle interne, y compris les ordinateurs portables, les appareils mobiles et les serveurs virtuels.

En août 2025, Microsoft a documenté Storm-0501 utilisant des techniques de rançongiciel basées sur le cloud après s'être déplacé d'Active Directory sur site vers Entra ID. L'acteur a obtenu les privilèges Global Administrator, élevé son accès aux abonnements Azure et supprimé les données cloud et les ressources de sauvegarde pour empêcher la récupération avant de demander une rançon.

Utiliser Claude for Chrome, Developer Tools et le JavaScript côté navigateur pour automatiser les actions Microsoft Graph

Claude for Chrome intègre Claude directement dans le navigateur, où il peut interagir avec les pages web, inspecter les éléments de l'interface utilisateur et aider à effectuer des actions via la même interface qu'un utilisateur utiliserait normalement de manière manuelle. Lorsqu'il est combiné avec Chrome Developer Tools et du JavaScript côté navigateur, cela va au-delà du simple prompting et permet d'automatiser des flux de travail au sein de Graph Explorer, y compris des opérations destructrices de Microsoft Graph contre un tenant Entra ID.

Prérequis

Reproduisez cette procédure uniquement dans un tenant de test qui vous appartient et que vous êtes prêt à perdre. N'exécutez pas d'opérations destructrices sur Graph dans un tenant de production ou dans tout environnement où vous ne disposez pas d'une autorisation explicite.

Dans cet article, je détaille comment j'ai utilisé Claude for Chrome pour automatiser des opérations destructrices sur Entra ID directement dans Microsoft Graph Explorer, en utilisant du JavaScript côté navigateur pour rendre le flux de travail rapide et sans intervention manuelle.

Avant de commencer, ouvrez Microsoft Graph Explorer dans un navigateur avec une session Global Administrator active dans votre tenant de test et gardez Claude for Chrome ouvert.

Effectuer une destruction contrôlée du tenant dans un tenant de test

Avant de toucher à quoi que ce soit, j'ai demandé à Claude d'énumérer quatre éléments à la fois : tous les membres des rôles de répertoire, toutes les inscriptions d'applications Entra ID, toutes les stratégies d'accès conditionnel et tous les appareils enregistrés. Ce qui a rendu cela rapide, c'est la manière dont Claude a récupéré le token de l'API Graph. Au lieu de me demander de le copier depuis les outils de développement du navigateur, il a appliqué un patch à la fonction fetch native du navigateur avec un petit interceptor.

      window._originalFetch = window.fetch;

window.fetch = function (...args) {
  const url = args[0];
  const options = args[1] || {};

  if (url.includes("graph.microsoft.com")) {
    const auth = (options.headers || {})["Authorization"];

    if (auth) {
      window._capturedToken = auth;
    }
  }

  return window._originalFetch.apply(this, args);
};
      

La fois suivante où Graph Explorer a effectué un appel d'API, cet interceptor a discrètement capté le token BearerExpand directement depuis les en-têtes de la requête. Claude a ensuite utilisé ce token pour lancer les quatre requêtes d'énumération en même temps via Promise.all()Expand, de sorte qu'au lieu d'attendre que quatre appels distincts se terminent l'un après l'autre, ils se sont tous exécutés en parallèle et les résultats sont revenus presque instantanément. Pour les rôles de répertoire en particulier, il a d'abord récupéré la liste des rôles actifs, puis a récupéré les membres de chaque rôle simultanément plutôt que de les parcourir un par un. Le résultat final a été un inventaire complet de l'ensemble du tenant en quelques secondes. Le token capturé ne disposait au départ que de scopes en lecture seule, de sorte que toute opération d'écriture ou de suppression renvoyait un 403Expand. Claude a tout géré via l'onglet Modify Permissions intégré à Graph Explorer.

Pour chaque opération nécessitant un scope d'autorisation plus élevé, Claude a navigué dans Graph Explorer jusqu'à l'endpoint pertinent avec la méthode HTTP correcte, est passé à l'onglet Modify Permissions, qui a automatiquement affiché les scopes requis, et a cliqué sur Consent.

Après chaque consentement, il a déclenché une nouvelle action Run Query afin que Graph Explorer émette un nouveau token avec les scopes mis à jour, puis l'a recapturé via le même interceptor. Les autorisations auxquelles il a donné son consentement étaient Application.ReadWrite.AllExpand pour supprimer les inscriptions d'applications, Policy.ReadWrite.ConditionalAccessExpand pour supprimer les stratégies d'accès conditionnel, RoleManagement.ReadWrite.DirectoryExpand pour retirer les comptes des rôles de répertoire et User.DeleteRestore.AllExpand pour supprimer les comptes utilisateur.

Les autorisations requises étant présentes dans le token d'accès, Claude a exécuté un seul bloc JavaScript qui a effectué les actions destructrices en parallèle. Le même schéma a été utilisé pour chaque type d'objet : récupérer la liste complète, mapper chaque objet à une requête DELETEExpand, exécuter les requêtes avec Promise.all()Expand et enregistrer le statut HTTP pour chaque réponse.

Ces logs d'audit Entra ID montrent le nettoyage qui se déroule en temps réel. À 8h06m19, plusieurs opérations de suppression ont été enregistrées comme réussies, notamment la suppression d'appareils, la suppression d'applications et la suppression de service principals.

Cette capture d'écran montre Claude for Chrome générant le bloc JavaScript à droite, tandis que la même logique est exécutée dans Chrome Developer Tools au sein de la session Graph Explorer. La sortie de la console montre que le script a trouvé 2 551 utilisateurs, en a marqué 2 550 pour suppression, a protégé 1 compte, puis a commencé à renvoyer des réponses 204Expand réussies pour les opérations de suppression.

On voit ici la phase de suppression des utilisateurs du flux de travail. À 8h14m05, plusieurs événements Delete user ont été enregistrés sous Core Directory et marqués comme Success.

À titre d'exemple, j'ai partiellement restauré certains des utilisateurs supprimés, tandis que d'autres sont restés dans le conteneur des éléments supprimés. J'ai ensuite utilisé Claude pour automatiser le nettoyage en générant du JavaScript côté navigateur capable de supprimer définitivement les utilisateurs restants directement depuis la session du navigateur.

Ces logs d'audit montrent l'étape de suppression définitive. Entra ID a enregistré plusieurs événements Hard Delete user sous Core Directory et UserManagement, tous marqués comme Success. Cela diffère de l'étape précédente de soft-delete. Ces utilisateurs ont été retirés du conteneur des éléments supprimés, ce qui signifie qu'ils n'étaient plus récupérables via le flux de restauration normal d'Entra ID.

Tenant lockout

Un tenant lockout se produit lorsqu'une organisation perd l'accès administratif à son tenant Microsoft 365 ou Entra ID. Cela peut se produire lorsque tous les comptes Global Administrator ou équivalents sont supprimés, désactivés, bloqués par une stratégie d'accès conditionnel défectueuse ou protégés par des paramètres MFA que personne ne peut plus satisfaire. À ce stade, le tenant peut toujours exister, mais l'organisation ne peut plus gérer les utilisateurs, les applications, les stratégies, les appareils ou les paramètres de récupération.

Au lieu de supprimer les objets du tenant, le flux de travail suivant se concentre sur le tenant lockout en réinitialisant les mots de passe des utilisateurs, en révoquant les sessions actives et en désactivant chaque compte.

En coulisses, Claude a utilisé le même token d'accès côté navigateur depuis la session Graph Explorer et a construit des requêtes $batchExpand de Microsoft Graph depuis le navigateur. Au lieu d'envoyer une requête par utilisateur manuellement, il a regroupé les utilisateurs en lots de 20 et a envoyé trois opérations de lot par groupe : une pour réinitialiser le mot de passe, une pour révoquer les sessions de connexion actives et une pour désactiver le compte.

Chaque lot a été envoyé à https://graph.microsoft.com/v1.0/$batchExpand avec le token capturé dans l'en-tête AuthorizationExpand. Cela a permis au flux de travail de s'exécuter rapidement et de manière répétée depuis le navigateur, pendant que Graph traitait les actions de verrouillage de compte en masse.

Les logs d'audit montrent l'étape de désactivation des comptes qui se reflète dans Entra ID. Plusieurs utilisateurs ont été désactivés dans la même courte fenêtre temporelle, et chaque événement a été enregistré sous Core Directory avec un statut Success. Cela confirme que le flux de travail de lockout a apporté des modifications réelles au tenant de test.

On voit ici une mise à jour en masse de l'horodatage StsRefreshTokenValidFromExpand sur plusieurs comptes utilisateur dans une fenêtre très courte. Cette activité est mise à jour lorsqu'une action Revoke Refresh Tokens est déclenchée, ce qui invalide tous les refresh tokens existants pour les utilisateurs concernés et force une nouvelle authentification.

Conclusion

Cet exemple montre à quel point peu d'outils sont nécessaires une fois que les bonnes autorisations sont déjà disponibles. Avec uniquement un navigateur, Graph Explorer, un assistant IA basé sur le navigateur et du JavaScript côté navigateur, il a été possible d'automatiser des opérations destructrices sur Entra ID sans écrire d'outil autonome, compiler de code ou exécuter de scripts externes. L'important n'est pas que l'IA ait créé à elle seule un nouveau vecteur d'attaque. Le véritable danger est que l'IA rend les flux de travail administratifs existants plus rapides, plus faciles à enchaîner et plus faciles à exécuter via le navigateur. Le JavaScript côté navigateur a servi de couche d'automatisation, transformant les actions manuelles de Graph Explorer en appels d'API répétables pouvant s'exécuter en parallèle. La découverte des autorisations, le consentement, le rafraîchissement des tokens, les requêtes Graph, le batching, la suppression, la réinitialisation des mots de passe, la révocation des sessions et la désactivation des comptes pouvaient tous être pilotés depuis la même session du navigateur.