Automatisierung der Entra ID-Mandantenzerstörung mit KI
May 21, 2026
KI-gestützte Browser-Automatisierung kann Microsoft Graph Explorer in eine zerstörerische Entra ID-Verwaltungsschnittstelle verwandeln, wenn ein angemeldetes Konto bereits über privilegierten Zugriff verfügt. Mit Claude für Chrome, browserseitigem JavaScript und Microsoft Graph Batch-Anfragen können zerstörerische Aktionen wie Benutzerlöschung, Kontodeaktivierung, Passwortzurücksetzungen, Sitzungswiderruf und Entfernung von Conditional Access-Richtlinien direkt aus der Browsersitzung automatisiert werden.
Wie KI die Zerstörung von Entra ID-Tenants über Microsoft Graph, Graph Explorer und browserseitige Automatisierung ermöglichen kann
Dieser Beitrag zeigt, wie KI-gestützte Browser-Automatisierung eingesetzt werden kann, um destruktive Microsoft Graph-Operationen gegen einen Entra ID-Tenant auszuführen, wenn das angemeldete Konto über die erforderlichen Berechtigungen verfügt.
Wie KI Graph Explorer zur Zerstörung von Entra ID-Tenants automatisiert
Microsoft Graph Explorer ist ein browserbasiertes Tool zum Senden von Microsoft Graph-API-Anfragen an einen Entra ID-Tenant. Es wird normalerweise von Administratoren und Entwicklern verwendet, um API-Aufrufe zu testen, Antworten zu inspizieren und zu verstehen, welche Berechtigungen erforderlich sind. In diesem Beitrag verwende ich es, um zu demonstrieren, wie der Zugriff auf Microsoft Graph für automatisierte destruktive Tenant-Operationen genutzt werden kann und warum dieselben Workflows gefährlich werden, wenn sie mit einem KI-Assistenten kombiniert werden, der den Browser steuern kann.
Praxisbeispiele für Tenant-Zerstörung
Tenant-Zerstörung beschränkt sich nicht mehr auf die Verschlüsselung von Servern mit Ransomware. Im März 2026 gab Stryker einen Cyberangriff bekannt, der seine Microsoft-Umgebung beeinträchtigte, und Sygnia berichtete später, dass der Angreifer Microsoft Intune verwendet hatte, um die interne virtuelle Infrastruktur, einschließlich Laptops, mobilen Geräten und virtuellen Servern, zu löschen.
Im August 2025 dokumentierte Microsoft, dass Storm-0501 cloudbasierte Ransomware-Techniken einsetzte, nachdem die Gruppe von einem lokalen Active Directory in Entra ID gewechselt hatte. Der Akteur erlangte Global Administrator-Privilegien, weitete den Zugriff auf Azure-Abonnements aus und löschte Cloud-Daten und Backup-Ressourcen, um eine Wiederherstellung zu verhindern, bevor er Lösegeld forderte.
Mit Claude for Chrome, Developer Tools und browserseitigem JavaScript Microsoft Graph-Aktionen automatisieren
Claude for Chrome bringt Claude direkt in den Browser, wo es mit Webseiten interagieren, UI-Elemente inspizieren und beim Ausführen von Aktionen über dieselbe Oberfläche helfen kann, die ein Benutzer normalerweise manuell verwenden würde. In Kombination mit Chrome Developer Tools und browserseitigem JavaScript geht dies über einfaches Prompting hinaus und ermöglicht die Automatisierung von Workflows innerhalb von Graph Explorer, einschließlich destruktiver Microsoft Graph-Operationen gegen einen Entra ID-Tenant.
Voraussetzungen
Reproduzieren Sie dies nur in einem Test-Tenant, der Ihnen gehört und auf dessen Verlust Sie vorbereitet sind. Führen Sie keine destruktiven Graph-Operationen in einem Produktions-Tenant oder in einer Umgebung aus, in der Sie keine ausdrückliche Autorisierung haben.
In diesem Beitrag erläutere ich, wie ich Claude for Chrome verwendet habe, um destruktive Entra ID-Operationen direkt in Microsoft Graph Explorer zu automatisieren, wobei browserseitiges JavaScript den Workflow schnell und ohne manuelle Eingriffe macht.
Öffnen Sie vor dem Start Microsoft Graph Explorer in einem Browser mit einer aktiven Global Administrator-Sitzung in Ihrem Test-Tenant und halten Sie Claude for Chrome geöffnet.
Kontrollierte Tenant-Zerstörung in einem Test-Tenant durchführen
Bevor ich irgendetwas berührte, bat ich Claude, vier Dinge gleichzeitig aufzulisten: alle Mitglieder von Verzeichnisrollen, alle Entra ID-Anwendungsregistrierungen, alle Conditional Access-Richtlinien und alle registrierten Geräte. Was dies schnell machte, war die Art und Weise, wie Claude das Graph-API-Token erlangte. Anstatt mich zu bitten, es aus den Browser-Entwicklertools zu kopieren, patchte es die native fetch-Funktion des Browsers mit einem kleinen 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);
};
Beim nächsten API-Aufruf von Graph Explorer fing dieser Interceptor das Bearer-Token unbemerkt direkt aus den Request-Headern ab. Claude verwendete dann dieses Token, um alle vier Enumerationsabfragen gleichzeitig über Promise.all() auszuführen. Anstatt darauf zu warten, dass vier separate Aufrufe nacheinander abgeschlossen werden, liefen sie alle parallel ab und die Ergebnisse kamen fast sofort zurück. Speziell für Verzeichnisrollen rief es zuerst die Liste der aktiven Rollen ab und dann die Mitglieder jeder einzelnen Rolle gleichzeitig, anstatt sie einzeln nacheinander durchzugehen. Das Endergebnis war eine vollständige Inventarisierung des gesamten Tenants in wenigen Sekunden. Das erfasste Token hatte zunächst nur Lesezugriff-Scopes, sodass jede Schreib- oder Löschoperation einen 403 zurückgab. Claude erledigte alles über die in Graph Explorer integrierte Registerkarte Modify Permissions.
Für jede Operation, die einen höheren Berechtigungs-Scope erforderte, navigierte Claude in Graph Explorer zum entsprechenden Endpunkt mit der korrekten HTTP-Methode, wechselte zur Registerkarte Modify Permissions, die automatisch die erforderlichen Scopes anzeigte, und klickte auf Consent.
Nach jeder Zustimmung löste es eine neue Run Query-Aktion aus, damit Graph Explorer ein neues Token mit den aktualisierten Scopes ausstellte, und erfasste es dann erneut über denselben Interceptor. Die Berechtigungen, denen es zustimmte, waren Application.ReadWrite.All zum Löschen von App-Registrierungen, Policy.ReadWrite.ConditionalAccess zum Löschen von Conditional Access-Richtlinien, RoleManagement.ReadWrite.Directory zum Entfernen von Konten aus Verzeichnisrollen und User.DeleteRestore.All zum Löschen von Benutzerkonten.
Mit den erforderlichen Berechtigungen im Zugriffstoken führte Claude einen einzigen JavaScript-Block aus, der die destruktiven Aktionen parallel ausführte. Das gleiche Muster wurde für jeden Objekttyp verwendet: die vollständige Liste abrufen, jedes Objekt auf eine DELETE-Anfrage abbilden, die Anfragen mit Promise.all() ausführen und den HTTP-Status für jede Antwort protokollieren.
Diese Entra ID-Audit-Logs zeigen die Bereinigung in Echtzeit. Um 8:06:19 Uhr wurden mehrere Löschoperationen als erfolgreich erfasst, darunter Gerätelöschungen, Anwendungslöschungen und das Entfernen von Service Principals.
Dieser Screenshot zeigt, wie Claude for Chrome rechts den JavaScript-Block generiert, während dieselbe Logik in Chrome Developer Tools innerhalb der Graph Explorer-Sitzung ausgeführt wird. Die Konsolenausgabe zeigt, dass das Skript 2.551 Benutzer fand, 2.550 zum Löschen markierte, 1 Konto schützte und dann erfolgreiche 204-Antworten für die Löschoperationen zurückgab.
Hier zeigt sich die Phase der Benutzerlöschung im Workflow. Um 8:14:05 Uhr wurden mehrere Delete user-Ereignisse unter Core Directory erfasst und als Success markiert.
Beispielsweise habe ich einige der gelöschten Benutzer teilweise wiederhergestellt, während andere im Container der gelöschten Elemente verblieben. Anschließend habe ich Claude verwendet, um die Bereinigung zu automatisieren, indem es browserseitiges JavaScript generierte, das die verbleibenden gelöschten Benutzer direkt aus der Browser-Sitzung dauerhaft löschen konnte.
Diese Audit-Logs zeigen den Schritt der dauerhaften Löschung. Entra ID erfasste mehrere Hard Delete user-Ereignisse unter Core Directory und UserManagement, alle als Success markiert. Dies unterscheidet sich von der vorherigen Soft-Delete-Phase. Diese Benutzer wurden aus dem Container der gelöschten Elemente entfernt, was bedeutet, dass sie über den normalen Entra ID-Wiederherstellungsprozess nicht mehr wiederherstellbar waren.
Tenant Lockout
Ein Tenant Lockout tritt auf, wenn eine Organisation den administrativen Zugriff auf ihren Microsoft 365- oder Entra ID-Tenant verliert. Dies kann passieren, wenn alle Global Administrator- oder gleichwertigen Konten gelöscht, deaktiviert, durch eine fehlerhafte Conditional Access-Richtlinie blockiert oder durch MFA-Einstellungen geschützt sind, die niemand mehr erfüllen kann. An diesem Punkt existiert der Tenant möglicherweise noch, aber die Organisation kann Benutzer, Anwendungen, Richtlinien, Geräte oder Wiederherstellungseinstellungen nicht mehr verwalten.
Anstatt Tenant-Objekte zu löschen, konzentriert sich der nächste Workflow auf den Tenant Lockout, indem Benutzerpasswörter zurückgesetzt, aktive Sitzungen widerrufen und alle Konten deaktiviert werden.
Im Hintergrund verwendete Claude dasselbe browserseitige Zugriffstoken aus der Graph Explorer-Sitzung und erstellte Microsoft Graph-$batch-Anfragen direkt aus dem Browser. Anstatt eine Anfrage pro Benutzer manuell zu senden, gruppierte es die Benutzer in Stapel von 20 und sendete drei Batch-Operationen pro Gruppe: eine zum Zurücksetzen des Passworts, eine zum Widerrufen aktiver Anmeldesitzungen und eine zum Deaktivieren des Kontos.
Jeder Batch wurde an https://graph.microsoft.com/v1.0/$batch mit dem erfassten Token im Authorization-Header gesendet. Dadurch konnte der Workflow schnell und wiederholt aus dem Browser ausgeführt werden, während Graph die Konto-Lockout-Aktionen in großem Umfang verarbeitete.
Die Audit-Logs zeigen, wie sich der Schritt zur Kontodeaktivierung in Entra ID widerspiegelt. Mehrere Benutzer wurden innerhalb desselben kurzen Zeitfensters deaktiviert, und jedes Ereignis wurde unter Core Directory mit dem Status Success erfasst. Dies bestätigt, dass der Lockout-Workflow tatsächliche Änderungen am Test-Tenant vorgenommen hat.
Hier wird eine Massenaktualisierung des StsRefreshTokenValidFrom-Zeitstempels über mehrere Benutzerkonten innerhalb eines sehr kurzen Zeitfensters dargestellt. Diese Aktivität wird aktualisiert, wenn eine Revoke Refresh Tokens-Aktion ausgelöst wird, die alle vorhandenen Refresh-Token für die betroffenen Benutzer ungültig macht und eine erneute Authentifizierung erzwingt.
Fazit
Dieses Beispiel zeigt, wie wenig Tools benötigt werden, sobald die richtigen Berechtigungen bereits verfügbar sind. Mit nur einem Browser, Graph Explorer, einem browserbasierten KI-Assistenten und browserseitigem JavaScript war es möglich, destruktive Entra ID-Operationen zu automatisieren, ohne ein eigenständiges Tool zu schreiben, Code zu kompilieren oder externe Skripte auszuführen. Wichtig ist nicht, dass die KI selbst einen neuen Angriffsweg geschaffen hat. Die eigentliche Gefahr besteht darin, dass KI bestehende administrative Workflows schneller, leichter verkettbar und einfacher über den Browser ausführbar macht. Browserseitiges JavaScript fungierte als Automatisierungsschicht und verwandelte manuelle Graph Explorer-Aktionen in wiederholbare API-Aufrufe, die parallel ausgeführt werden konnten. Berechtigungserkennung, Zustimmung, Token-Aktualisierung, Graph-Anfragen, Batching, Löschung, Passwort-Resets, Sitzungswiderruf und Kontodeaktivierung konnten alle aus derselben Browser-Sitzung gesteuert werden.
Teilen auf
Erfahren Sie mehr
Über den Autor
Huy Kha
Direktor für Sicherheitsforschung
Erfahren Sie mehr zu diesem Thema
Wem gehören Ihre KI-Agenten? Wahrscheinlich niemandem
Steuern Sie den KI-Agenten als die Identität, die er ist
Der Fehlercode ist der Hinweis
Was ist DLL-Hijacking und warum Ihr neues KI-Plugin der einfachste Einstieg sein könnte
Sie haben bei der Identitätshygiene alles richtig gemacht. Und wurden 4-mal häufiger kompromittiert