新たに公開された手法により、稼働中のWindowsユーザーセッションにアクセスできる攻撃者が、被害者のPINを知らずとも、また生体認証をトリガーすることもなく、Windows Hello for Business(WHFB)の暗号鍵を悪用できることが明らかになりました。
この手法により、クラウド認証、Microsoft Entra IDトークンの取得、デバイス登録、さらには永続的なアカウントアクセスまでもが可能になる恐れがあります。
Mollema氏の調査では、エクスポート不可能な鍵であっても、侵害されたユーザーコンテキストで動作するプロセスから利用され得ることが示されています。
この問題の核心はシングルサインオン(SSO)の挙動にあります。WHFBの鍵はリモートデスクトッププロトコル(RDP)セッションをまたいだ認証をサポートしており、あるデバイスで認証済みのユーザーが、別のEntra ID参加済みデバイスに接続している間にクラウドサービスへアクセスできる仕組みになっています。
この正当な設計要件により、デバイスAに由来する鍵が、デバイスBでのセッション用にプライマリリフレッシュトークン(PRT)を取得するために使われてしまう可能性があります。
Mollema氏は、一定の条件下では、認証済みユーザーセッション内の低権限プロセスであっても、ユーザーのWHFB鍵に署名を要求するために必要なWindowsの暗号インターフェースにアクセスできることを発見しました。
このプロセスは、ユーザーのWindows Hello PIN、顔認識、指紋認証、あるいは管理者権限を必ずしも必要としません。その代わり、Windowsは以前にキャッシュされた認証情報を利用しているとみられ、Microsoftのドキュメントではこれを「チケット」と表現しています。
Passport Key Storage ProviderとWindowsネイティブの暗号化APIを利用することで、ユーザーとして動作するマルウェアやインプラントは、TPMに保護された鍵に認証データへの署名を要求できてしまいます。
この署名機能により、2つの重要な攻撃経路が生まれます。まず、攻撃者はPRTを要求するために必要なアサーションを生成できる可能性があり、これによって長期にわたるEntra IDのシングルサインオンと、Microsoftクラウドリソースへの更新可能なアクセスが得られてしまいます。
従来、この経路を利用するには、攻撃者が別のEntra登録済みまたはEntra参加済みデバイスも制御している必要がありました。これは、PRTの要求にデバイスの状態情報が含まれるためです。
2つ目として、Mollema氏はWHFBの鍵をWebAuthn/FIDO2形式の認証に転用できることを実証しました。攻撃者はEntraのサインインページからサーバーチャレンジを取得し、それを侵害済みのエンドポイントに中継して署名させ、得られたアサーションを遠隔で利用できます。
この一連の流れにはデバイス識別子が含まれない場合があるため、攻撃者が制御する新たなEntraデバイスの登録に使えるトークンが生成される可能性があります。不正なデバイスが一度登録されてしまえば、攻撃者はPRTを取得し、持続的なアクセス(パーシステンス)を確立できてしまいます。
新たに得られたフィッシング耐性のある認証コンテキストは、テナントの構成や委任された権限次第で、パスキーや追加のWHFB鍵といった新しい認証情報の追加にも利用され得ます。
この調査結果は、TPM内の鍵そのものが抽出されることを示すものではありません。むしろ、セッションレベルでの鍵の悪用リスクを浮き彫りにしています。ログイン中のWindowsセッションを制御する攻撃者は、クラウド認証用のハードウェア保護された鍵を事実上「借用」できてしまうのです。
組織は、Windows Hello for Businessが使用されたにもかかわらずデバイスIDが提供されていないEntraサインインを監視すべきです。
セキュリティチームはまた、異常なデバイス登録、新たに追加されたWindowsエンドポイント、想定外のパスキー登録、そして異常なPRTの活動についても調査する必要があります。
ローカルセッションの侵害機会を減らすこと、エンドポイント検知のカバレッジを徹底すること、デバイス登録権限を制限すること、そして条件付きアクセスポリシーを見直すことは、依然として不可欠な防御策です。
ANY.RUNのブラウザ内データ検査で、検知・調査・対応をより迅速に。 フィッシングの可視性を完全に確保し、SOCを強化してMTTRを削減しましょう
翻訳元: https://cyberpress.org/windows-hello-keys-bypass-pins-gain-entra-id/