“Evil VM”：ゲストの侵害からEntra管理者まで、9つの簡単なステップで

Entra ID におけるデバイス ID の悪用

Entra に参加済みのデバイスは、条件付きアクセスポリシーの評価における重要なシグナルであることを踏まえると、Entra のユーザーに対してデフォルトで付与されている権限に、デバイスをテナントに参加させる権限が含まれていることは、私たちにとって驚きでした。

ただし、このデフォルト設定は Entra B2B ゲストには適用されません。明示的に許可されない限り、ゲストには Entra ID 上でデバイスを「参加」または「登録」する権限は一切ありません。

実装方法：
Entra ID の設定内にある「ユーザーがデバイスを Entra ID に参加させることを許可する（Users may join devices to Entra ID）」オプションを構成し、特定のグループにのみデバイス登録を許可するよう制限します。たとえば、オンボーディング専任チームのみにその役割を与えることで、無制限な登録を防ぐことができます。
利点：
承認されたユーザーのみがデバイスを参加させることができるようになり、環境内に不正または不要なデバイスが追加されるリスクを低減できます。
— msp4mspsより

 

 

私たちの以前の「Restless Guests」調査 ─ すなわち、Entra のゲストアカウントがサブスクリプションの所有権を取得できるという内容 ─ の文脈においては、図1および図2で示したデバイス参加の制御を回避することが可能であるように見受けられます。

このようなサブスクリプション内で作成された仮想マシン（VM）は、デバイス保護なしで構成することができ、デバイス証明書やトランスポートキー、さらにはその VM に発行される可能性のある PRT など、機密性の高いデータやトークン情報が露出するリスクがあります。

ユーザーは Windows VM を作成する際に、「Azure AD ベースの Windows ログイン」拡張機能を有効にするよう選択できます。この拡張が導入されると、VM はデプロイ時に Entra ID に参加されます（図3参照）。

この拡張機能の目的は、ユーザーの Entra ID 資格情報を用いて VM にログインできるようにすることです。さらに、ユーザーに「Virtual Machine User Login」または「Virtual Machine Administrator Login」のいずれかの RBAC ロールを割り当てることで、リモートアクセス権限を付与することも可能になります。

Entra ID のセキュリティとラテラルムーブメント対策において、Evil VM 攻撃経路が重要である理由

デバイスが Entra ID に参加している場合、条件付きアクセスポリシーは、これらのデバイスが組織により所有・管理されていることを前提として構成されています。

私たちの過去の「Restless Guests」調査を振り返ると、デフォルトでは、ホームディレクトリ内で適切な課金ロールを持つゲストは、他テナント内のサブスクリプションの所有権を取得できてしまう可能性があります。

たとえば、攻撃者が Microsoft の「従量課金制（Pay-As-You-Go）」アカウントを用いてサインアップした場合、そのアカウントは課金所有者としての権限を持つことになります。この権限によって、攻撃者はサブスクリプションを作成できます。

さらにもう一つのデフォルト設定として、任意のユーザーまたはゲストは他のゲストをディレクトリに招待することが可能です。したがって、攻撃者がテナント内の任意のユーザーまたはゲストを侵害した場合、自分が作成した Microsoft アカウント（課金所有者）をそのテナントにゲストとして招き入れ、任意のサブスクリプションを作成することができます。

サブスクリプション所有者には、そのサブスクリプション内で任意のインフラストラクチャを作成する権限があります。つまり、攻撃者は Azure AD ログイン拡張機能を含む Windows VM をプロビジョニングでき、その VM は自動的に Entra ID にデバイスとして参加されます。

重要なのは、このプロセスが ユーザーによるデバイス参加が許可されていない場合でも、マネージド ID を利用することで実行可能である点です。

このような「Evil VM」が特に危険なのは、攻撃者自身がその VM に TPM（Trusted Platform Module）を有効にするかどうかを選択できることにあります。たとえば、「第1世代（Gen 1）」のイメージと「Standard（標準）」のセキュリティタイプを選択すれば、TPM の保護は無効となります。

要するに：

攻撃者が最初に任意のゲストまたはユーザーを乗っ取った場合、Entra ID のデフォルト設定のままでは、TPM 保護のない VM に対してローカル管理者権限を取得するラテラルムーブメントが可能になります。

TPM 保護が存在しないということは、その VM に発行された PRT（プライマリ・リフレッシュ・トークン）が、Mimikatz のようなレッドチームツールを使って容易に取得できるということです。

このあと記事では、権限昇格をさらに進める手法として、既知のフィッシング攻撃「デバイスコード・フィッシング」を、この文脈でどのように悪用できるかについて解説していきます。

PRTフィッシング：攻撃者が Entra ID におけるPRTを盗む手口

この攻撃手法は、Dirk-Jan Mollema 氏によって最初に詳述されたもので、Microsoft Authentication Broker アプリケーション向けのリフレッシュトークンを、完全なプライマリ・リフレッシュ・トークン（PRT）に“昇格”させる仕組みを悪用しています。

この「デバイスコード・フィッシング」手法の最大の利点は、ユーザーが悪意あるURLにリダイレクトされることが一切ない点です。フィッシングされたユーザーがやり取りするのは、すべて正規の Entra ID のURLのみです。

この攻撃は、OAuth2 の「デバイスコード」標準フローを利用しています。このフローでは、1台のデバイスが認証プロセスを開始し、別のデバイスで認証を完了させることができます。そして、取得されたトークンは元のデバイスに戻されます。

元記事で述べられているように、この攻撃には一般的な制約があります：

テナント内でデバイスの登録や参加が、特定のユーザーのみに制限されている可能性があります。一般的には、「参加」の方が「登録」よりも頻繁に制限されています。— Dirk-Jan Mollema
出典：dirkjanm.io

さらに、ゲストアカウントには標準設定ではデバイスを「登録」または「参加」させる権限はありません。これらの操作はメンバーのみが可能です。

しかし、ここまでの説明で示したように、Entra ID ログイン拡張機能を使えば、この制約を回避できます。これにより、以下のような完全な攻撃経路が成立します：

 

それでは、次にこのプロセスの各ステップを順を追って見ていきましょう。

Entra ID で PRTを詐取する手順、ステップ・バイ・ステップ

1）ゲストアカウントを侵害してEntra ID内に初期侵入する

まず、攻撃者が対象テナント内の B2B ゲストアカウントを侵害したと仮定します。このゲストには、ロールの割り当て、グループメンバーシップ、または管理者によって明示的に付与されたアクセス権限が一切ないものとします。以降のラテラルムーブメントは、すべて既定の特権とデフォルトのテナント設定のみに基づいて実行されます。これは、実際に起こり得る Entra ID ゲストアカウント乗っ取りシナリオを示しています。

なお、初期侵入の有効な手段は複数あります。

• ユーザーアカウントを侵害する
• ターゲットテナントにゲストとして招待される

2）課金権限を持つ「Restless Guest」をターゲットテナントに招待する

攻撃対象であるリソーステナントに「Restless Guest」を挿入するには、特定の準備が必要です。まず、攻撃者が制御する別のテナント（ホームテナント）にユーザーを作成します。これには、クレジットカードを使って Microsoft アカウントにサインアップするのが最も簡単です。しかも、200ドル分の無料クレジットも付いてきます。

このサインアップに使用されたアカウントは、自動的に課金所有者となります。なぜなら、そのアカウントは課金に使われるクレジットカードと直接紐付けられているためです。

「デフォルトでは、組織内のすべてのユーザー（B2B コラボレーションのゲストユーザーを含む）が外部ユーザーを B2B コラボレーションに招待できます。招待の権限を制限したい場合は、すべてのユーザーに対して招待をオン/オフにするか、特定のロールのみに制限できます。」 — Microsoft Ignite
出典：Microsoft Ignite

次に、この課金所有者を攻撃対象のテナントにゲストとして招待します。Entra ID の招待に関するデフォルト設定が寛容であるため、最初に侵害したゲストアカウントを使って、この課金所有者をターゲットテナントに招待できます。

その結果、攻撃対象のリソーステナント内に、新たなゲストユーザー（かつホームテナントでは課金所有者）を持ち込むことができます。

3）ゲストの課金権限を使って攻撃先ディレクトリ内にサブスクリプションを作成する

攻撃者は、自身のホームテナント内でサブスクリプションを作成できます。そしてデフォルト設定では、そのサブスクリプションをリソーステナント（ゲストとして所属しているテナント）に移行することも許可されています。

ポータル上でこれを実行する際には、サブスクリプション作成時に「詳細設定」の中にある「サブスクリプション ディレクトリ（subscription directory）」のドロップダウンで、リソーステナントを選択します。

この操作が完了すると、ゲストユーザーはサブスクリプションの正式な所有者となります。

4）TPM 非搭載の Evil VM を構築して PRT 窃取を可能にする

サブスクリプションの所有者には、その中で任意のリソースを作成する自由があります。これにより、攻撃者は自由に ”Evil VM”（悪意ある仮想マシン）を作成できます。

このステップの主な目的は、TPM 保護のない VM にローカル管理者としてアクセスすることです。TPM 保護がない VM であれば、PRT を簡単に盗み出せるためです。

この条件を満たすには、「第1世代（Gen 1）」の VM を選択し、セキュリティタイプとして「Standard（標準）」を指定します。

ポータル上での操作例は以下の通りです。

5）VM を Entra ID に参加させて、ラテラルムーブメント用のデバイス ID を生成する

この VM を Entra ID に参加させることで、VM に固有のデバイス ID を付与します。これにより、VM 自身がディレクトリに対して認証を行えるようになります。

ポータル上では、VM の作成時に「管理」タブを開き、「Microsoft Entra ID を使用してログイン」を選択することで設定可能です。

ローカル管理者の資格情報を入力して「作成」をクリックします。VM のデプロイが完了したら、VM 上で「dsregcmd /status」を実行することで、TPM 保護と Entra 参加の状態を確認できます。

興味深いことに、この拡張機能をインストールしなくてもデバイスを参加させることは可能です。この手法は、過去の別記事で初めて検証されました。

拡張機能のバイナリをデコンパイルしてみると、実質的には「dsregcmd.exe」コマンドを呼び出すラッパーであることが分かります。自前のマネージド ID を付与し、いくつかのレジストリ設定を変更した後、「dsregcmd.exe /AzureSecureVMJoin」を実行することで、同様の結果を得られます。

6）デバイス証明書とトランスポートキーを抽出し、永続的なバックドアを作成する

ローカル管理者としてVM にアクセスできるため、デバイス証明書を盗むことが可能です。このデバイス ID は、ゲストアカウント、VM 本体、さらにはサブスクリプションが削除された後でも有効なまま残る可能性があります。

一度証明書を盗んでしまえば、まったく別のマシン上でもこのデバイスIDとして認証することができます。つまり、永続的なデバイスバックドアの完成です。

 

これには、AADInternals の Endpoints モジュールを利用できます。

7）IAM のロール継承を通じて Entra ID の管理者アカウントを列挙する

ユーザーをフィッシングするには、ターゲットとなるユーザーの詳細（名前やメールアドレス）を知る必要があります。幸いなことに、新たに作成したサブスクリプションの IAM（アクセス制御）ロール割り当てを調べることで、多くの場合管理者情報を取得できます。

たとえば、ルート管理グループでロールを持つユーザーは、自動的に作成されたサブスクリプションにもその権限が継承されます。これは通常、Entra ID のグローバル管理者が、全サブスクリプションへの基本アクセスを許可する設定を有効にしている場合に発生します。

ポータル上では、対象のサブスクリプションを開き、「アクセス制御（IAM）」タブ →「ロールの割り当て」画面を確認することで調べられます。

8）デバイスコードフローを用いてユーザーをフィッシングし、完全な PRTを取得する

すでにデバイス証明書を盗んでいるため、これを特殊なタイプのリフレッシュトークンと組み合わせることで、PRT に“アップグレード”することが可能です。この技術は Dirk-Jan Mollema 氏によって最初に公開されました。

詳細な技術背景については同氏のオリジナル記事を読むことを推奨しますが、大まかな流れは次の通りです：

• デバイスコードを用いた OAuth フローを開始し、enrollment.manage.microsoft.com を対象リソースとし、Microsoft Authentication Broker のクライアントIDでリフレッシュトークンを要求する
• 管理者をフィッシングして、デバイスコードフローを完了させ、リフレッシュトークンを取得する
• そのリフレッシュトークンと、前もって盗んでおいたデバイス証明書を組み合わせて、PRT にアップグレードする（※この特定のクライアント＋リソースのトークンのみが PRT への昇格を可能にします）

このフィッシングステップを試したい場合は、ROADtools を使って実装することができます。

攻撃者たちはこの手法を実際に使っており、成功を収め、Microsoft 自身のブログでも話題になっています。実際、このフローに対応したレッドチーム向けのフィッシングキットも存在します。

そのため、もしフィッシングが成功した場合には、再度 ROADtools を使ってリフレッシュトークンを PRT に昇格させればよいだけです。

9）盗んだ PRT を使って、フィッシングした管理者として Entra ID に認証する

この時点で、入手した PRT を使って任意の Azure サービスにアクセスできるようになります。

おめでとう、あなたは今、グローバル管理者です！