Automatizzare la distruzione del tenant Entra ID con l'IA
May 21, 2026
L'automazione del browser assistita dall'IA può trasformare Microsoft Graph Explorer in un'interfaccia di amministrazione distruttiva di Entra ID quando un account connesso possiede già privilegi di accesso. Utilizzando Claude per Chrome, JavaScript lato browser e richieste batch di Microsoft Graph, azioni distruttive come la cancellazione di utenti, la disabilitazione di account, il reset delle password, la revoca delle sessioni e la rimozione delle policy di Conditional Access possono essere automatizzate direttamente dalla sessione del browser.
Come l’AI può automatizzare la distruzione di un tenant Entra ID tramite Microsoft Graph, Graph Explorer e automazione lato browser
Questo post mostra come l’automazione del browser assistita dall’AI possa essere utilizzata per eseguire operazioni distruttive di Microsoft Graph su un tenant Entra ID, quando l’account autenticato dispone delle autorizzazioni necessarie.
Come l’AI automatizza Graph Explorer per la distruzione di un tenant Entra ID
Microsoft Graph Explorer è uno strumento basato su browser per inviare richieste alle API Microsoft Graph verso un tenant Entra ID. Viene normalmente utilizzato da amministratori e sviluppatori per testare chiamate API, analizzare le risposte e comprendere quali autorizzazioni siano necessarie. In questo post lo uso per dimostrare come l’accesso a Microsoft Graph possa essere sfruttato per automatizzare operazioni distruttive su un tenant, e perché gli stessi workflow diventano pericolosi quando vengono combinati con un assistente AI in grado di controllare il browser.
Esempi reali di distruzione di un tenant
La distruzione di un tenant non si limita più alla cifratura dei server tramite ransomware. A marzo 2026, Stryker ha comunicato un cyberattacco che ha causato interruzioni nel suo ambiente Microsoft; successivamente, Sygnia ha riportato che l’attaccante aveva utilizzato Microsoft Intune per cancellare infrastruttura virtuale interna, inclusi laptop, dispositivi mobili e server virtuali.
Ad agosto 2025, Microsoft ha documentato l’uso di tecniche di ransomware basate sul cloud da parte di Storm-0501, dopo il passaggio dall’Active Directory on-premises a Entra ID. L’attore ha ottenuto privilegi di Global Administrator, ha elevato l’accesso alle sottoscrizioni Azure e ha eliminato dati cloud e risorse di backup per impedire il ripristino prima di richiedere il riscatto.
Usare Claude for Chrome, Developer Tools e JavaScript lato browser per automatizzare le azioni su Microsoft Graph
Claude for Chrome porta Claude direttamente nel browser, dove può interagire con le pagine web, ispezionare gli elementi dell'interfaccia e aiutare a eseguire azioni attraverso la stessa interfaccia che un utente userebbe normalmente in modo manuale. Quando viene combinato con Chrome Developer Tools e JavaScript lato browser, si va oltre il semplice prompting e diventa possibile automatizzare i flussi di lavoro all'interno di Graph Explorer, incluse le operazioni distruttive di Microsoft Graph su un tenant Entra ID.
Prerequisiti
Riproduci questa procedura solo in un tenant di test di tua proprietà che sei disposto a perdere. Non eseguire operazioni distruttive su Graph in un tenant di produzione o in qualsiasi ambiente in cui non disponi di un'autorizzazione esplicita.
In questo post illustro come ho usato Claude for Chrome per automatizzare operazioni distruttive su Entra ID direttamente all'interno di Microsoft Graph Explorer, utilizzando JavaScript lato browser per rendere il flusso di lavoro rapido e senza interventi manuali.
Prima di iniziare, apri Microsoft Graph Explorer in un browser con una sessione di Global Administrator attiva nel tuo tenant di test e tieni Claude for Chrome aperto.
Eseguire una distruzione controllata del tenant in un tenant di test
Prima di toccare qualsiasi cosa, ho chiesto a Claude di enumerare quattro elementi contemporaneamente: tutti i membri dei ruoli di directory, tutte le registrazioni delle applicazioni Entra ID, tutte le policy di Conditional Access e tutti i dispositivi registrati. Ciò che ha reso il processo veloce è stato il modo in cui Claude ha ottenuto il token dell'API Graph. Invece di chiedermi di copiarlo dagli strumenti di sviluppo del browser, ha applicato una patch alla funzione fetch nativa del browser con un piccolo 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 volta successiva in cui Graph Explorer ha effettuato una chiamata API, questo interceptor ha catturato silenziosamente il token Bearer direttamente dalle intestazioni della richiesta. Claude ha poi usato quel token per lanciare tutte e quattro le query di enumerazione contemporaneamente tramite Promise.all(), così invece di attendere il completamento di quattro chiamate separate una dopo l'altra, sono state eseguite tutte in parallelo e i risultati sono tornati quasi istantaneamente. Per i ruoli di directory in particolare, ha prima recuperato l'elenco dei ruoli attivi, poi ha recuperato i membri di ogni singolo ruolo simultaneamente invece di scorrerli uno alla volta. Il risultato finale è stato un inventario completo dell'intero tenant in pochi secondi. Il token catturato inizialmente disponeva solo di scope di sola lettura, quindi qualsiasi operazione di scrittura o eliminazione avrebbe restituito un 403. Claude ha gestito tutto attraverso la scheda Modify Permissions integrata in Graph Explorer.
Per ogni operazione che richiedeva uno scope di autorizzazione più elevato, Claude ha navigato in Graph Explorer fino all'endpoint pertinente con il metodo HTTP corretto, è passato alla scheda Modify Permissions, che ha automaticamente mostrato gli scope richiesti, e ha cliccato su Consent.
Dopo ogni consenso, ha attivato una nuova azione Run Query in modo che Graph Explorer emettesse un nuovo token con gli scope aggiornati, per poi ricatturarlo tramite lo stesso interceptor. Le autorizzazioni a cui ha dato il consenso sono state Application.ReadWrite.All per eliminare le registrazioni delle applicazioni, Policy.ReadWrite.ConditionalAccess per eliminare le policy di Conditional Access, RoleManagement.ReadWrite.Directory per rimuovere gli account dai ruoli di directory e User.DeleteRestore.All per eliminare gli account utente.
Con le autorizzazioni necessarie presenti nel token di accesso, Claude ha eseguito un singolo blocco JavaScript che ha effettuato le azioni distruttive in parallelo. Lo stesso schema è stato utilizzato per ogni tipo di oggetto: recuperare l'elenco completo, mappare ogni oggetto a una richiesta DELETE, eseguire le richieste con Promise.all() e registrare lo stato HTTP per ogni risposta.
Questi log di audit di Entra ID mostrano la pulizia che avviene in tempo reale. Alle 8:06:19, sono state registrate come riuscite più operazioni di eliminazione, tra cui l'eliminazione di dispositivi, l'eliminazione di applicazioni e la rimozione di service principal.
Questo screenshot mostra Claude for Chrome che genera il blocco JavaScript sulla destra, mentre la stessa logica viene eseguita in Chrome Developer Tools all'interno della sessione di Graph Explorer. L'output della console mostra che lo script ha trovato 2.551 utenti, ne ha contrassegnati 2.550 per l'eliminazione, ha protetto 1 account e ha poi iniziato a restituire risposte 204 riuscite per le operazioni di eliminazione.
Qui viene mostrata la fase di eliminazione degli utenti del flusso di lavoro. Alle 8:14:05, sono stati registrati più eventi Delete user sotto Core Directory e contrassegnati come Success.
A titolo di esempio, ho ripristinato parzialmente alcuni degli utenti eliminati, mentre altri sono rimasti nel contenitore degli elementi eliminati. Ho poi usato Claude per automatizzare la pulizia generando JavaScript lato browser in grado di eliminare definitivamente gli utenti rimanenti direttamente dalla sessione del browser.
Questi log di audit mostrano la fase di eliminazione definitiva. Entra ID ha registrato più eventi Hard Delete user sotto Core Directory e UserManagement, tutti contrassegnati come Success. Questa fase è diversa dallo stadio precedente di soft-delete. Questi utenti sono stati rimossi dal contenitore degli elementi eliminati, il che significa che non erano più recuperabili attraverso il normale flusso di ripristino di Entra ID.
Tenant lockout
Un tenant lockout si verifica quando un'organizzazione perde l'accesso amministrativo al proprio tenant Microsoft 365 o Entra ID. Questo può accadere quando tutti gli account Global Administrator o equivalenti vengono eliminati, disabilitati, bloccati a causa di una policy di Conditional Access non funzionante o protetti da impostazioni MFA che nessuno è più in grado di soddisfare. A quel punto, il tenant potrebbe ancora esistere, ma l'organizzazione non è più in grado di gestire utenti, applicazioni, policy, dispositivi o impostazioni di ripristino.
Invece di eliminare gli oggetti del tenant, il flusso di lavoro successivo si concentra sul tenant lockout reimpostando le password degli utenti, revocando le sessioni attive e disabilitando ogni account.
Sotto il cofano, Claude ha utilizzato lo stesso token di accesso lato browser dalla sessione di Graph Explorer e ha costruito le richieste $batch di Microsoft Graph dal browser. Invece di inviare una richiesta per utente manualmente, ha raggruppato gli utenti in batch da 20 e ha inviato tre operazioni batch per gruppo: una per reimpostare la password, una per revocare le sessioni di accesso attive e una per disabilitare l'account.
Ogni batch è stato inviato a https://graph.microsoft.com/v1.0/$batch con il token catturato nell'intestazione Authorization. Questo ha permesso al flusso di lavoro di essere eseguito rapidamente e ripetutamente dal browser, mentre Graph elaborava in blocco le azioni di blocco degli account.
I log di audit mostrano la fase di disabilitazione degli account che si riflette in Entra ID. Più utenti sono stati disabilitati nella stessa breve finestra temporale e ogni evento è stato registrato sotto Core Directory con uno stato di Success. Questo conferma che il flusso di lavoro di lockout ha apportato modifiche reali al tenant di test.
Questo mostra un aggiornamento in blocco del timestamp StsRefreshTokenValidFrom su più account utente in una finestra di tempo molto breve. Questa attività viene aggiornata quando si attiva un'azione di Revoke Refresh Tokens, che invalida tutti i refresh token esistenti per gli utenti interessati e forza una nuova autenticazione.
Conclusione
Questo esempio mostra quanto pochi strumenti siano necessari una volta che le autorizzazioni giuste sono già disponibili. Con un solo browser, Graph Explorer, un assistente AI basato su browser e JavaScript lato browser, è stato possibile automatizzare operazioni distruttive su Entra ID senza scrivere uno strumento autonomo, compilare codice o eseguire script esterni. L'aspetto importante non è che l'AI abbia creato da sola un nuovo percorso di attacco. Il vero pericolo è che l'AI rende i flussi di lavoro amministrativi esistenti più rapidi, più facili da concatenare e più facili da eseguire tramite il browser. JavaScript lato browser ha agito come livello di automazione, trasformando le azioni manuali di Graph Explorer in chiamate API ripetibili che potevano essere eseguite in parallelo. Individuazione delle autorizzazioni, consenso, refresh dei token, richieste Graph, batching, eliminazione, reimpostazione delle password, revoca delle sessioni e disabilitazione degli account potevano essere tutti gestiti dalla stessa sessione del browser.
Condividi su
Scopri di più
Informazioni sull'autore
Huy Kha
Direttore della Ricerca sulla Sicurezza
Scopri di più su questo argomento
Governa l'agente IA come l'identità che è
Il codice di errore è l'indizio
Cos'è il DLL hijacking e perché il tuo nuovo plugin AI potrebbe essere il modo più semplice per entrare
Hanno fatto tutto bene sull'igiene delle identità. Hanno subito 4 volte più violazioni
Miti e il costo dell'attacco