Compliant Device Bypass - 知っておくべきことのすべて

これまでの経緯

• 2024年12月、Yuya Chudo氏がBlack Hat Europeカンファレンスで「Unveiling the Power of Intune: Leveraging Intune for Breaking Into Your Cloud and On-Premise」と題した講演を行いました。このセッションでは、デバイスコンプライアンスに関する条件付きアクセス（CA）のハードコードされたほとんど知られていない除外設定を、Entra IDの文書化されていない「FOCI機能」と組み合わせて悪用する方法が示されました。講演では、この挙動は仕様どおりであり新しいデバイスのIntune Enrollmentを成功させるために必要である、というMicrosoft MSRC（VULN-123240）の回答も紹介されています。
• カンファレンスの数日後、Sunny Chau氏が概念実証ツールTokenSmithを関連するブログ記事とともに公開しました。これによってこの手法はより広い層に知られることになりました。
• さらに、PowerShellで書かれたPoCも公開されています。
• 12月末以降、私たちglueckkanja AGはこの手法をどのように防止し検知できるかを調査してきました。本記事では、この攻撃に関する知見の一部を共有し、緩和策と検知の選択肢について述べます。

TL;DR

条件付きアクセスには、特定の課題を解決するために、一部のGrant Controls/Conditionsに対する除外があらかじめ組み込まれているリソースが存在します。そのひとつが、デバイスコンプライアンスに対するCompany Portal Appの除外です。これは、デバイスがコンプライアンス準拠と判定される前にIntuneへ登録しなければならないという、鶏と卵の問題を解決するためのものです。この挙動はこちらに文書化されています。 つまり、CAポリシーが「All resources」に対してDevice Complianceを強制していても、管理されていないデバイスからこのアプリのアクセストークンとリフレッシュトークンを取得できるということです。

{: .post__screenshot}

MicrosoftはFamily of Client IDs（FOCI）という機能を実装しています。これは、あるグループに属するMicrosoftのOAuthクライアントアプリケーションが、自らのリフレッシュトークンを使ってそのファミリー内の別のクライアントとしてアクセストークンを取得できるようにするものです。本来OAuth2標準では認められていない挙動です。詳細はSecureworksの元の調査をご覧ください。 Company Portal Appは「ファミリーメンバー」であるため、そのために要求したリフレッシュトークンを使って、同じファミリー内の他のアプリ向けのトークンを取得できます。

FOCI機能には制限があり、クライアントIDとリソースの間のコンセントは明示的に構成され付与されている必要があります。Company Portal Appの場合、このコンセントは、制限されたスコープでのMicrosoft Graphへのアクセスや、現在のユーザーの権限でのAzure AD Graph APIへのアクセスなどに対して付与されています。 つまり、Company Portalのリフレッシュトークンを使って、たとえばスコープuser_impersonationでAzure AD Graph APIのアクセストークンを取得でき、AADInternalsやROADreconなどで多くの操作が可能になります。

この攻撃を実行するには、攻撃者は被害者の有効な資格情報に加え、条件付きアクセスが要求する場合はMFAを実行できることが必要です。あるいは、有効なリフレッシュトークンが必要です。

どのようなリスクと影響範囲があるのか

コンプライアンスの除外の影響を受けるリソース（スコープ）はどれか

攻撃者は、前述のとおり別のFOCIアプリケーション向けのトークンを要求できます。ただしMicrosoftは、特定のリソースアプリケーションの一部のAPIアクセス許可スコープへのトークン取得についてのみ、デバイスコンプライアンス要件のバイパスを実装しています。とりわけ次の委任されたAPIアクセス許可は機微であり、攻撃者にとって関心の対象となります。

付与されたアクセス許可はアプリケーション自身に対するものではないため、影響の大きさは呼び出し元（ユーザーアカウント）の権限と、どの委任されたアクセス許可スコープがそのスコープでのAPI呼び出しを認可されているかによって変わります。

ここで示した委任されたアクセス許可スコープの重大性と、機微なAPIを呼び出せる可能性について、もう少し詳しく見ていきましょう。

どの権限と委任スコープが危険か

Azure AD Graph API

このレガシーなプログラミングインターフェイスは、Entra ID（Azure AD）のディレクトリ設定とオブジェクトを管理するための多数のAPIを提供します。条件付きアクセスポリシー、ディレクトリロール、グループやデバイスに対するCRUD、そしてパスワード変更などサインイン中のユーザーに対する操作が含まれます。サポートされる操作の全一覧はAzure AD Graph APIリファレンスにあります。このAPIはMicrosoftの最新のアナウンスにもとづき、2025年6月30日に完全に廃止されます。

割り当てられた委任スコープ「user_impersonation」は、アプリケーション（この場合はCompany Portal）がユーザーに代わって動作することを可能にします。したがって、サインイン中のユーザーがEntraのオブジェクト、スコープ、ディレクトリレベルに対して持つあらゆるアクセス許可が、API呼び出しの認可として利用され得ます。そのユーザーはEntra IDオブジェクト（アプリケーション、グループ、その他のオブジェクト）の所有者であるかもしれませんし、Entra IDのロール割り当てを通じてアクセス許可を得ているかもしれません。 高い権限を持つロールがアクティブに割り当てられている場合、攻撃者はオブジェクトを変更したり、テナントを侵害したりできてしまいます。 少なくとも、何の権限がなくても、既定のユーザー権限だけでテナント内のディレクトリオブジェクトを広範に偵察・列挙することが可能です。

そのため、Azure AD Graph APIを悪用するシナリオと影響は、対象となるユーザーにアクティブまたは恒久的に割り当てられた権限に左右されます。Microsoft 365のサービスにアクセスするAPI（たとえばOneDriveからの情報持ち出しに使われるもの）はAzure AD Graphには含まれていません。

Microsoft Graph API

Azure AD Graphと比べると、Microsoft Graph APIへの委任スコープは限定されています。OpenIDのスコープ（openid、email、profile）と、ユーザーに代わって行う基本的な読み取り操作（ServicePrincipalEndpoint.Read.All、User.Read）が含まれます。

「Device.Read.All」を使えば、既定のアクセス許可のままMicrosoft Graphの「device」エンドポイントを呼び出して、すべてのデバイスオブジェクトを一覧表示し読み取ることができます。これは攻撃者がデバイスオブジェクトの情報を得るのに役立ってしまいます。

「Intune Administrator」が割り当てられているユーザー、またはMicrosoft IntuneのRBACで何らかの委任を受けているユーザーが侵害された場合、次の委任APIアクセス許可は問題があると考えるべきです。

• ”DeviceManagementConfiguration.Read.All”
• “DeviceManagementConfiguration.ReadWrite.All”

これらの委任されたアクセス許可により、たとえばDevice ComplianceやConfigurationのポリシーに対するCRUD操作に加え、対象デバイス上でさらなる悪意ある活動を行うためのManagement Scriptsの展開も可能になります。

Device Registration Service

このアクセス許可があれば、攻撃者はデバイスをEntra IDにjoinまたは登録できます。その結果、そのデバイスをIntuneに登録することさえ可能になり、Intuneの構成によっては有効でコンプライアンス準拠のデバイスを手に入れ、さらに多くの保護されたサービスにアクセスできてしまいます。

その他のFOCIアプリケーション

たとえばAzure Resource Manager APIのような他の特権インターフェイスへのアクセス要求もFOCIの対象であり、攻撃者の関心事です。ただしこのリソースは依然として保護されており、条件付きアクセスの許可制御「compliant device」はバイパスされません。

この攻撃手法を検知できるか

前述のとおり、最大のリスクはMS GraphとAzure AD Graphへのアクセスから生じます。

このケースでは常にMicrosoft Intune Company Portal AppのアプリケーションIDが使われるため、検知を作るうえでの主な課題は、デバイス登録などの正当な利用を除外することです。当社の観測では、その切り分けはセッション内で最初にどのリソースへアクセスするかによって決まります。攻撃の場合は、たいていMS GraphかAzure AD Graphです。

以下は、当社がさまざまな規模の複数の環境で検証した、実際に機能する検知です。

不審な活動を検知したらどう対応すべきか

次の内容を含む定義済みのプレイブックを用いて、インシデント対応プロセスを開始してください。

• 侵害されたユーザーによる不審または異常な活動のハンティング
  • sessionIdをもとにした、IPアドレスとUserAgentを含むリソースアプリケーションへの非対話型サインインの要約
  • Microsoft Entra Audit Logsに、そのユーザーやIPアドレスによる重大な操作（たとえば所有するアプリ登録への資格情報の追加）が記録されていないかの確認
  • 該当セッションでそのユーザーがデバイスを登録していないかの特定
  • アプリケーション「Company Portal」と対象ユーザーによる操作について、Intuneの監査ログの確認
• 影響を受けたエンティティに関連するアラートのハンティング
  • AlertEvidenceテーブルでエンティティを照会し、SessionId、IPアドレス、ユーザーにもとづく他のアラートを特定
• Exposure Managementで、そのユーザーの重大性を権限の観点から特定
• ハンティング結果を精査し、その操作がデバイス登録の一環として正当なものだったかを検証
• 初期侵入経路を特定し、ユーザーの資格情報を、必要に応じてデバイスもリセット

攻撃を緩和できるか

構成されている除外はIntuneの登録に必要なものであるため、 Microsoft 365の他の部分を壊さずに済む緩和策はありません。 Azure AD Graphリソースへのアクセスは、直接スコープを絞ることも遮断することもできません。許可制御に「Block」を用いる条件付きアクセスポリシーはアクセスを防ぎますが、他の影響が生じるおそれがあります。

ただし緩和を考えるうえで重要なのは、この条件付きアクセスのバイパスがそれ単体で完結した攻撃ではないという点です。これは、一連の攻撃を可能にする一段階としての手法です。

想定される攻撃経路は次のようなものです。

1. フィッシングとAiTMによるアカウントの侵害
2. 条件付きアクセスのバイパス
3. ROADrecon、GraphRunner、AADInternalsなどを用いた偵察
4. Intuneに登録した新しいデバイスを介したラテラルムーブメント、権限昇格、または永続化

Intuneの登録を壊さずに条件付きアクセスのバイパスを緩和することはできないため、攻撃経路の他の段階で緩和策を講じ、あわせて妥当な検知を実装することが十分に理にかなっています。

発生確率と影響を下げるために、他の統制の強度を高め、次の対策を早期に実施することをお勧めします。

• 条件付きアクセスで「All Users」と「All Cloud Apps」に対してMFAを強制してください。 Device Complianceのみを強制している場合、この手法では単要素認証だけで十分になってしまいます。
• ルールセットでDevice ComplianceとMFAのどちらか一方を使うのではなく、常に両方を強制してください。 ORを使うと、コンプライアンス準拠のデバイスへのアクセス制限が徹底されません。MFAがスコープに含まれるアクセストークンがあれば、テナントにアクセスできてしまうからです。
• セキュリティ情報の登録を、コンプライアンス準拠デバイス、フィッシング耐性のある認証、またはTAPに限定してください。 当社のテストでは、セキュリティ情報の登録についてDevice Complianceをバイパスすることはできませんでした。
• デバイスのJoinまたはRegisterにフィッシング耐性のある認証またはTAPを要求してください。 これがないと、たとえばAADInternalsとこの手法でデバイスを登録できてしまいます。
• Microsoft Intuneの登録にMFAと「Sign-in frequency every time」を要求してください。 これにより、攻撃者が新しいデバイスをIntuneに登録するために新鮮な資格情報を使える時間を限定できます。

  🚧 注意: Sign-in frequency every time = 5分ごと Microsoftは、条件付きアクセスポリシーで「every time」を選択した場合、ユーザーが5分に1回より頻繁に認証を求められないよう、5分のクロックスキューを考慮します。

• Intuneの登録制限で個人所有デバイスをブロックしてください。 この制限がないと、攻撃者が新しいデバイスを登録してさらなる足がかりを得られます。
• Intuneでデバイスにコンプライアンスポリシーが割り当てられていない場合に、デバイスコンプライアンスを不準拠とする設定にしてください。 既定では、実際にはポリシーが適用されていなくても各デバイスはコンプライアンス準拠と見なされます。これを変更し、デバイスコンプライアンスポリシーを必須にしてください。

長期的には、Windows Hello for Businessやパスキー（macOS Platform SSOによるPlatform Credentialsを含む）のような、パスワードレスでフィッシング耐性のある認証の展開に投資されることをお勧めします。そうすることで、その後フィッシング耐性のある認証を強制し、AiTM攻撃を遮断できるようになります。パスワードの代わりに、新しいデバイスや従業員のオンボーディングなど、期間とシナリオを限定してTemporary Access Pass（TAP）の利用を許可してください。さまざまなユースケースでTAPを活用できるよう、当社はMyWorkIDを開発しました。

まとめ

Entra IDのゼロトラストエンジンである条件付きアクセスは、それ自体がすでに複雑です。さらにMicrosoftがEntraのバックエンドに組み込んだ除外設定によって、ポリシーや保護の効果を理解することは多くの人にとって一層難しくなっています。それでも、ゼロトラストと多層防御という考え方は有効なままです。

デバイスコンプライアンスポリシーはほとんどのAiTM攻撃を防ぎ、多要素認証（MFA）は、漏えいしたりその他の形で侵害されたりした資格情報の悪用を攻撃者にとって難しくします。

これらのセキュリティ対策は、どれか一方を他方の代わりにするのではなく、組み合わせて使わなければなりません。そうすることで、防御のひとつが改ざんされたり突破されたりしても、安全な環境を維持できます。

悪用の可能性を確実に検知できるよう、ここで示した検知をMicrosoft Defender XDRに展開することを強くお勧めします。自社のSOCがこうしたインシデントを調査できる体制を整え、必要なプレイブックを用意しておいてください。