AI で Entra ID テナント破壊を自動化

AI が Microsoft Graph、Graph Explorer、ブラウザー側自動化を通じて Entra ID テナント破壊を自動化する方法

本記事では、サインインしているアカウントに必要な権限がある場合に、AI支援によるブラウザー自動化を使って Entra ID テナントに対して破壊的な Microsoft Graph 操作を実行する方法を示します。

AIがEntra IDテナント破壊のためにGraph Explorerを自動化する方法

Microsoft Graph Explorerは、Entra IDテナントに対してMicrosoft Graph APIリクエストを送信するためのブラウザベースのツールです。通常、管理者や開発者がAPI呼び出しのテスト、応答の確認、必要な権限の把握のために使用します。本記事では、Microsoft Graphへのアクセスが自動化された破壊的なテナント操作にどのように利用され得るか、また、ブラウザを操作できるAIアシスタントと組み合わされた場合に、同じワークフローがなぜ危険になるのかを示すためにこのツールを使用します。

テナント破壊の実例

テナント破壊は、もはやランサムウェアによるサーバーの暗号化にとどまりません。2026年3月、Strykerは自社のMicrosoft環境を混乱させたサイバー攻撃を公表し、Sygniaはその後、攻撃者がMicrosoft Intuneを使用してノートパソコン、モバイルデバイス、仮想サーバーを含む内部の仮想インフラを消去したと報告しました。

2025年8月、Microsoftは、Storm-0501がオンプレミスのActive DirectoryからEntra IDに移行した後、クラウドベースのランサムウェア手法を使用した事例を文書化しました。攻撃者はGlobal Administrator権限を取得し、Azureサブスクリプションへのアクセスを拡大し、復旧を防ぐためにクラウドデータとバックアップリソースを削除した上で身代金を要求しました。

Claude for Chrome、開発者ツール、ブラウザ側 JavaScript を使用して Microsoft Graph のアクションを自動化する

Claude for Chromeは、Claudeをブラウザに直接統合し、ウェブページと対話し、UI要素を検査し、ユーザーが通常手動で使用するのと同じインターフェースを通じてアクションの実行を支援できるようにします。Chrome Developer Toolsおよびブラウザ側のJavaScriptと組み合わせることで、単純なプロンプティングを超え、Entra IDテナントに対する破壊的なMicrosoft Graph操作を含む、Graph Explorer内のワークフローを自動化することが可能になります。

前提条件

この手順は、ご自身が所有し、失っても問題のないテストテナントでのみ再現してください。本番テナントや明示的な許可を得ていない環境では、破壊的なGraph操作を実行しないでください。

本記事では、Claude for Chromeを使用してMicrosoft Graph Explorer内で直接Entra IDの破壊的な操作を自動化した方法を解説し、ブラウザ側のJavaScriptを活用してワークフローを迅速かつ手動操作なしで実行できるようにしました。

開始する前に、テストテナントでGlobal Administratorセッションがアクティブな状態のブラウザでMicrosoft Graph Explorerを開き、Claude for Chromeを開いた状態にしておきます。

テスト テナントでの制御されたテナント破壊の実行

何にも触れる前に、私はClaudeに4つの項目を同時に列挙するよう依頼しました。すべてのディレクトリロールのメンバー、すべてのEntra IDアプリケーション登録、すべての条件付きアクセスポリシー、そしてすべての登録済みデバイスです。この処理を高速にしたのは、ClaudeがGraph APIトークンを取得する方法でした。ブラウザの開発者ツールからトークンをコピーするよう私に求めるのではなく、小さなインターセプターを使用してブラウザのネイティブなfetch関数にパッチを適用しました。

      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);
};
      

次にGraph ExplorerがAPI呼び出しを行ったとき、このインターセプターはリクエストヘッダーからBearerトークンを密かに取得しました。Claudeはそのトークンを使用して、Promise.all()を介して4つの列挙クエリを同時に実行しました。4つの個別の呼び出しが順次完了するのを待つのではなく、すべてが並行して実行され、結果はほぼ瞬時に返ってきました。ディレクトリロールについては、まずアクティブなロールのリストを取得し、それから各ロールのメンバーを1つずつループ処理するのではなく、同時に取得しました。最終的に、テナント全体の完全なインベントリをわずか数秒で取得できました。最初に取得されたトークンは読み取り権限のスコープのみを持っていたため、書き込みや削除の操作は403を返しました。Claudeは、Graph Explorerに組み込まれたModify Permissionsタブを通じてすべてを処理しました。

より高い権限スコープを必要とする各操作について、Claudeは正しいHTTPメソッドでGraph Explorer内の該当するエンドポイントに移動し、Modify Permissionsタブに切り替えて必要なスコープを自動的に表示させ、Consentをクリックしました。

各同意の後、新しいRun Queryアクションを実行してGraph Explorerに更新されたスコープを持つ新しいトークンを発行させ、同じインターセプターを通じてそれを再度取得しました。同意した権限は、アプリ登録を削除するためのApplication.ReadWrite.All、Conditional Accessポリシーを削除するためのPolicy.ReadWrite.ConditionalAccess、ディレクトリロールからアカウントを削除するためのRoleManagement.ReadWrite.Directory、そしてユーザーアカウントを削除するためのUser.DeleteRestore.Allでした。

アクセストークンに必要な権限が揃った状態で、Claudeは破壊的な操作を並行して実行する単一のJavaScriptブロックを実行しました。各オブジェクトタイプに対して同じパターンが使用されました。すなわち、完全なリストを取得し、各オブジェクトをDELETEリクエストにマッピングし、Promise.all()でリクエストを実行し、すべての応答についてHTTPステータスを記録するというものです。

これらのEntra ID監査ログは、クリーンアップがリアルタイムで進行している様子を示しています。午前8時6分19秒に、デバイスの削除、アプリケーションの削除、サービスプリンシパルの削除を含む複数の削除操作が成功として記録されました。

このスクリーンショットは、右側でClaude for ChromeがJavaScriptブロックを生成すると同時に、Graph Explorerセッション内のChrome Developer Toolsで同じロジックが実行されている様子を示しています。コンソール出力には、スクリプトが2,551人のユーザーを発見し、2,550人を削除対象としてマークし、1つのアカウントを保護した後、削除操作に対して成功した204応答を返し始めたことが表示されています。

ここでは、ワークフローのユーザー削除フェーズを示しています。午前8時14分5秒に、複数のDelete userイベントがCore Directoryの下に記録され、Successとしてマークされました。

例として、削除されたユーザーの一部を部分的に復元し、その他は削除済みアイテムコンテナに残しました。その後、Claudeを使用してクリーンアップを自動化し、ブラウザセッションから直接、残りの削除済みユーザーを完全に削除できるブラウザ側のJavaScriptを生成しました。

これらの監査ログは、完全削除のステップを示しています。Entra IDは、Core DirectoryおよびUserManagementの下に複数のHard Delete userイベントを記録し、すべてSuccessとしてマークされました。これは、以前のソフト削除段階とは異なります。これらのユーザーは削除済みアイテムコンテナから削除され、通常のEntra IDの復元フローを通じては復旧できない状態になりました。

テナントのロックアウト

テナントロックアウトは、組織が自社のMicrosoft 365またはEntra IDテナントへの管理アクセス権を失った際に発生します。これは、すべてのGlobal Administratorまたは同等のアカウントが削除、無効化されたり、機能不全のConditional Accessポリシーによってブロックされたり、誰も満たせなくなったMFA設定によって保護されたりした場合に発生する可能性があります。この時点でテナント自体はまだ存在しているかもしれませんが、組織はユーザー、アプリケーション、ポリシー、デバイス、または復旧設定を管理することができなくなります。

次のワークフローでは、テナントオブジェクトを削除する代わりに、ユーザーパスワードのリセット、アクティブセッションの取り消し、およびすべてのアカウントの無効化を通じて、テナントロックアウトに焦点を当てます。

内部的には、ClaudeはGraph Explorerセッションから取得した同じブラウザ側のアクセストークンを使用し、ブラウザからMicrosoft Graphの$batchリクエストを構築しました。ユーザーごとに1つのリクエストを手動で送信する代わりに、ユーザーを20人単位のバッチにグループ化し、各グループに対して3つのバッチ操作を送信しました。すなわち、パスワードのリセット、アクティブなサインインセッションの取り消し、アカウントの無効化です。

各バッチは、取得したトークンをAuthorizationヘッダーに含めてhttps://graph.microsoft.com/v1.0/$batchに送信されました。これにより、ワークフローはブラウザから迅速かつ繰り返し実行でき、Graphはアカウントロックアウトのアクションを一括処理しました。

監査ログは、アカウント無効化のステップがEntra IDに反映されている様子を示しています。複数のユーザーが同じ短い時間枠内で無効化され、各イベントはCore Directoryの下にSuccessステータスで記録されました。これは、ロックアウトワークフローがテストテナントに実際の変更を加えたことを確認するものです。

ここでは、非常に短い時間枠内で複数のユーザーアカウントにわたってStsRefreshTokenValidFromタイムスタンプが一括で更新されている様子を示しています。このアクティビティは、Revoke Refresh Tokensアクションが実行された際に更新され、影響を受けるユーザーの既存のリフレッシュトークンをすべて無効化し、再認証を強制します。

結論

この例は、適切な権限がすでに利用可能な状態であれば、必要なツールがほとんどないことを示しています。ブラウザ、Graph Explorer、ブラウザベースのAIアシスタント、およびブラウザ側のJavaScriptのみで、スタンドアロンツールを作成したり、コードをコンパイルしたり、外部スクリプトを実行したりすることなく、破壊的なEntra ID操作を自動化することが可能でした。重要なのは、AIが単独で新しい攻撃経路を生み出したという点ではありません。本当の危険は、AIが既存の管理ワークフローをより高速にし、連鎖させやすくし、ブラウザを通じて実行しやすくしているという点にあります。ブラウザ側のJavaScriptは自動化レイヤーとして機能し、手動のGraph Explorer操作を並列実行可能な繰り返し可能なAPI呼び出しに変換しました。権限の検出、同意、トークンの更新、Graphリクエスト、バッチ処理、削除、パスワードリセット、セッションの取り消し、アカウントの無効化は、すべて同じブラウザセッションから実行できました。

Microsoft Graph Explorer は、Entra ID テナントに対して Microsoft Graph API リクエストを送信するためのブラウザー ベースのツールです。通常は管理者や開発者が、API 呼び出しをテストしたり、レスポンスを確認したり、必要な権限が何かを理解するために使用します。この記事では、Microsoft Graph へのアクセスを使って自動化された破壊的なテナント操作がどのように実行できるのか、そしてブラウザーを操作できる AI アシスタントと組み合わせた場合に同じワークフローがなぜ危険になるのかを示すために、これを用います。

テナント破壊はもはや、ランサムウェアでサーバーを暗号化することに限定されません。

Claude for Chrome は Claude をブラウザに直接取り込み、そこで Web ページとやり取りしたり、UI 要素を検査したり、ユーザーが通常手動で使うのと同じインターフェースを通じてアクションの実行を支援したりできます。これを Chrome の開発者ツールとブラウザ側 JavaScript と組み合わせることで、単なるプロンプト入力を超えて Graph Explorer 内のワークフローを自動化できるようになり、Entra ID テナントに対する破壊的な Microsoft Graph 操作も含めて実行可能になります。

これは、自分が所有しており、万一失っても構わないと準備できているテスト テナントでのみ再現してください。プロダクション テナント、または明示的な許可を得ていない環境では、破壊的な Graph 操作を実行しないでください。

この投稿では、Claude for Chrome を使用して、ブラウザ側 JavaScript によってワークフローを高速かつ手を使わずに実行しながら、Microsoft Graph Explorer の中で直接破壊的な Entra ID 操作を自動化する方法を説明します。

開始する前に、テスト テナントでアクティブな Microsoft Graph Explorer セッションを持つブラウザで Global Administrator を開き、Claude for Chrome を開いたままにしておいてください。

何も触る前に、私は Claude に「一度に4つ」を列挙してほしいと頼みました。具体的には、すべてのディレクトリ ロール メンバー、すべての Entra ID アプリケーション登録、すべての Conditional Access ポリシー、そして登録済みのすべてのデバイスです。これが速かったのは、Claude が Graph API トークンを手に入れた方法によります。ブラウザの開発者ツールからコピーするように頼むのではなく、小さなインターセプターでブラウザのネイティブ fetch 関数をパッチしました。

次に Graph Explorer が何らかの API 呼び出しを行ったとき、このインターセプターがリクエスト ヘッダーから Bearer トークンをそのまま静かに（サイレントに）取得しました。Claude はそのトークンを使って、Promise.all() により、4つの列挙クエリを同時に実行しました。そのため、4つの別々の呼び出しが1つずつ終わるのを待つのではなく、すべてが並列に実行され、結果はほぼ瞬時に返ってきました。ディレクトリ ロールに関しては、まずアクティブなロールの一覧を取得し、次にそれらを1つずつループしてメンバーを取得するのではなく、すべてのロールのメンバーを同時に取得しました。最終的には、数秒でテナント全体の完全なインベントリが得られました。最初にキャプチャされたトークンには読み取りレベルのスコープしかなかったため、書き込みや削除の操作はすべて 403 が返ってきます。Claude は Graph Explorer の組み込みの Modify Permissions タブを通じてすべてを処理しました。

より高い権限スコープが必要な各操作に対して、Claude は Graph Explorer を正しい HTTP メソッドで関連するエンドポイントへ移動し、Modify Permissions タブに切り替えました。このタブでは必要なスコープが自動的に表示され、Consent をクリックしました。

各同意のたびに、Graph Explorer が更新されたスコープで新しいトークンを発行し、その後同じインターセプターでそれを再キャプチャできるように、Run Query を改めて実行する操作をトリガーしました。同意した権限は、アプリ登録を削除するための Application.ReadWrite.All、条件付きアクセス（Conditional Access）ポリシーを削除するための Policy.ReadWrite.ConditionalAccess、ディレクトリ ロールからアカウントを削除するための RoleManagement.ReadWrite.Directory、そしてユーザー アカウントを削除するための User.DeleteRestore.All です。

アクセス トークンに必要な権限が含まれていると、Claude は破壊的な操作を並列に実行する単一の JavaScript ブロックを実行しました。同じパターンが各オブジェクト タイプに対して使われています。つまり、完全な一覧を取得し、各オブジェクトをDELETE のリクエストにマッピングし、Promise.all() でリクエストを実行して、すべての応答の HTTP ステータスをログに記録します。

これらの Entra ID の監査ログは、クリーンアップがリアルタイムで行われていることを示しています。8:06:19 AM に、デバイスの削除、アプリケーションの削除、サービス プリンシパルの削除などを含む複数の削除操作が成功として記録されました。

このスクリーンショットは Claude for Chrome が右側で JavaScript ブロックを生成している様子を示しており、同時に Graph Explorer セッション内の Chrome Developer Tools でも同じロジックが実行されています。コンソール出力では、スクリプトが 2,551 人のユーザーを見つけ、2,550 人を削除対象としてマークし、1 アカウントを保護したうえで、削除操作に対する成功の 204 応答を返し始めたことが分かります。

ここでは、ワークフローのユーザー削除フェーズが示されています。8:14:05 AM に、複数の Delete user イベントが Core Directory の下で記録され、Success としてマークされています。

たとえば、削除済みのユーザーのうち一部は部分的に復元しました。 一方で、ほかのユーザーは削除済みアイテムのコンテナーに残っていました。その後、Claude を使って後片付けを自動化しました。ブラウザー側で動作する JavaScript を生成し、 ブラウザーのセッションから直接、残っている削除済みユーザーを永続的に削除できるようにしました。

これらの監査ログは、永続的な削除（パーマネント削除）の手順を示しています。Entra ID では複数の Hard Delete user イベントが Core Directory および UserManagement の下で記録されており、すべて Success としてマークされています。これは、先ほどのソフト削除の段階とは異なります。これらのユーザーは削除済みアイテムのコンテナーから削除されたため、通常の Entra ID の復元フローではもう復旧できません。

テナントのロックアウトは、組織が自社の Microsoft 365 または Entra ID テナントに対する管理者アクセスを失ったときに発生します。これは、すべての Global Administrator（全体管理者）または同等のアカウントが削除されたり無効化されたり、壊れた Conditional Access ポリシーの背後でロックされたり、もはや誰も満たせない MFA 設定で保護されたりすることで起こり得ます。この時点でテナントはまだ存在している可能性がありますが、組織はユーザー、アプリケーション、ポリシー、デバイス、または回復設定を管理できなくなります。

次のワークフローでは、テナント オブジェクトを削除するのではなく、ユーザーのパスワードをリセットし、アクティブ セッションを無効化（取り消し）し、すべてのアカウントを無効化することで、テナントのロックアウトに焦点を当てます。

内部では、Claude は Graph Explorer セッションで使用したのと同じブラウザー側のアクセス トークンを使い、Microsoft Graph $batch リクエストをブラウザーから組み立てました。ユーザーごとに 1 件ずつリクエストを手動で送信するのではなく、ユーザーを 20 人ずつのバッチにまとめ、グループごとに 3 つのバッチ操作を送信しました。つまり、1 つはパスワードのリセット、1 つはアクティブなサインイン セッションの取り消し、もう 1 つはアカウントの無効化です。

各バッチは https://graph.microsoft.com/v1.0/$batch に送信され、取得したトークンを Authorization ヘッダーに含めました。これにより、ワークフローをブラウザーから素早く繰り返し実行でき、同時に Graph はアカウントのロックアウト処理を一括で実行しました。

監査ログには、アカウント無効化の手順が Entra ID に反映されたことが示されています。同じ短い時間枠の中で複数のユーザーが無効化され、各イベントは Core Directory の Success ステータスとして記録されました。これにより、ロックアウトのワークフローがテスト テナントに実際の変更を行ったことが確認できます。

これは、非常に短い時間枠の中で複数のユーザー アカウントに対して StsRefreshTokenValidFrom タイムスタンプが一括更新されたことを示しています。このアクティビティは Revoke Refresh Tokens アクションがトリガーされると更新されます。これにより、影響を受けたユーザーの既存のすべてのリフレッシュ トークンが無効化され、再認証が強制されます。

この例は、適切な権限がすでに利用可能である場合に、必要なツールがいかに少なくて済むかを示しています。ブラウザー、Graph Explorer、ブラウザー上の AI アシスタント、そしてブラウザー側 JavaScript だけで、スタンドアロンのツールを作成したり、コードをコンパイルしたり、外部スクリプトを実行したりすることなく、破壊的な Entra ID の操作を自動化できました。重要なのは、AI がそれ自体で新しい攻撃経路を作ったことではありません。真の危険は、AI が既存の管理作業のワークフローをより速くし、連携しやすくし、さらにブラウザー経由で実行しやすくしてしまう点にあります。ブラウザー側 JavaScript は自動化レイヤーとして機能し、手作業の Graph Explorer の操作を、並列実行できる反復可能な API 呼び出しへと変換しました。権限の特定、同意、トークンの更新、Graph の要求、バッチ処理、削除、パスワードのリセット、セッションの無効化、アカウントの無効化はすべて、同じブラウザーセッションから実行できました。