Attackers Bypass Azure AD Conditional Access Using Phantom Device Registration
2026/05/06 gbhackers — Microsoft Entra ID (Azure AD) の Conditional Access を完全にバイパスする深刻な攻撃経路が、Howler Cell の承認されたレッドチーム・オペレーションにより実証された。本来、Azure Conditional Access はクラウド ID セキュリティにおける主要なゲートキーパーとして機能し、ユーザー所在地/デバイス準拠状態/算出されたリスクスコアなどに基づいてアクセス制御を適用するものである。しかし、今回の調査では、サイバー犯罪市場で数百ドル程度で購入できる有効な認証情報 1 セットを起点として、16,000 人以上のユーザーを抱える本番テナントの侵害に成功している。

特筆すべきは、企業エンドポイントへの接触やマルウェア展開を一切行うことなく、Global Administrator 権限への直接的な経路を特定した点にある。この脆弱性は、単一コンポーネントの不備というよりも、デバイス登録と ID サービス間における誤った信頼チェーンに起因している。
Azure AD のバイパス
この攻撃の中核は、Device Registration Service (DRS) にある。Conditional Access によりアカウントがブロックされたとしても、必ずしも攻撃が遮断されるわけではないことが、Cyderes の研究者により明らかにされた。
DRS エンドポイントがエンフォースメント・モードで保護されていなかったことで、Conditional Access の制限を受けない経路を介した認証が可能となっていた。それにより、DRS API が呼び出し元の Windows マシンの正当性を確認しない仕様が突かれ、単一のコマンドから署名付き証明書を用いた偽デバイスの登録を、攻撃者に許すことになった。
このプロセスにおいて、物理ハードウェアや Trusted Platform Module (TPM)/管理者承認すら不要であり、侵害済みアカウントに新規デバイスを紐付けるだけで、多要素認証やアクセス制御を容易に回避できる。この手法は、2024年8月以降に重要インフラを標的としている、ロシア系国家支援アクター Storm-2372 の活動とも酷似している。
偽デバイスを登録した攻撃者は、最重要の認証アーティファクトである Primary Refresh Token (PRT) を生成して、クラウド・リソースへの継続的なアクセス権を手にする。本来はハードウェアで保護されるべき PRT だが、研究者は Linux ラップトップ上で取得し、平文ファイルとして保存することに成功した。
この PRT には暗号化されたデバイス・クレームが含まれるため、ネットワークに対して正規デバイスとして振る舞うことが可能となり、トークン交換を経て “信頼済みデバイス” を要求するポリシーさえも無効化する。
さらに次段階では、ハイブリッド・ドメイン参加デバイスを事前登録対象外とする Intune の制限を逆手に取り、虚偽のドメイン所属を宣言することで Mobile Device Management (MDM) の準拠チェックをバイパスした。
その際に Intune は、偽デバイスに対して BitLocker/Secure Boot などのセキュリティ機能の有効性を確認したが、偽デバイスが返した空値をデフォルト・ロジックが、”非準拠” ではなく “該当なし” として処理してしまった。その結果として、最終的に前述の Linux ラップトップは、正式な準拠済み企業デバイスとしてシステムに承認されることになった。
データ流出と権限昇格
完全な準拠状態を取得した攻撃者は、Intune Management Extension を経由して入手した復号済みのアプリケーション・パッケージから、内部サーバ/ホスト名/管理共有構造/ネットワーク構成情報などを抽出した。通常、このレベルの情報を取得するためには、内部ネットワーク上での数週間にわたるラテラル・ムーブメントを必要とするが、今回は極めて短期間で達成されている。
さらに研究者は、ハイブリッド環境に潜む構造的リスクも特定している。具体的には、クラウドと同期された多数のオンプレミス・アカウントに、Global Administrator を含む特権ロールが割り当てられていた事実を重視している。
これにより、同期済みのオンプレミス・アカウントを 1 つ侵害するだけで、クラウド側のパスワードをリセットできる状態となり、結果として、クラウド固有のエクスプロイトを介さずとも、テナント全体を掌握する可能性が浮き彫りとなった。
一連のオペレーションが成功した背景には、Report-Only トラップという深刻なミスコンフィグが存在していた。それにより、デバイスコード・フローのブロックや登録時の多要素認証 (MFA) を求める重要ポリシーが、ログ記録のみの Report-Only モードに留まっていた。このため、悪意のアクティビティは正確に記録されていたが、実際の防御としては機能していなかった。
こうした偽デバイス登録や ID 悪用を防止するため、ユーザー組織にとって必要なことは、直ちに Microsoft Entra ID のポリシーを監査し、未承認フロー (MITRE ATT&CK T1556.009) のブロックやデバイス登録保護 (T1098.005) に関するルールを強制適用モードへ移行させることだ。
それに加えて、自己申告型の準拠確認に依存する運用を改め、厳格な外部検証メカニズムにより、管理対象ハードウェアのみがアクセスを許容される体制を構築することが急務となる。
訳者後書:今回の事例における原因は、デバイス登録と認証サービスの間に潜んでいた “信頼の連鎖” の不備にあります。本来は守られているはずの場所であっても、特定の条件下における DRS (Device Registration Service) という窓口が、誰でもデバイスを登録できる状態になっていました。また、 Intune の設定において、ハイブリッド・ドメインへの参加状況を自己申告で受け入れてしまい、セキュリティ機能の未確認を “異常なし” と誤認したロジックの隙も重なっています。さらに、せっかく導入していた強力な防御ポリシーが、Report-Only (記録のみ) 設定のまま運用されていたことで、攻撃を検知できても遮断できなかったことが決定打となりました。これらの複合的なミスコンフィグが、深刻な侵害を許す結果を招いています。

You must be logged in to post a comment.