Windows Hello for Businessキーを「借りる」攻撃 — サイレントなEntra ID永続化の手口と検知

Entra ID研究者のDirk-jan Mollema（ROADtoolsの作者）が、サインイン済みのWindowsセッション内で実行中のマルウェアが、被害者のWindows Hello for Business（WHfB）キーをサイレントに使ってMicrosoft Entra IDへ認証できることを実証した。TPMに守られたキーの秘密鍵を抽出する必要も、PINを回復する必要も、生体認証のプロンプトを出す必要もない。管理者権限すら不要だ。攻撃者はそこから長期のクラウドアクセスを確立し、自分が管理するデバイスの登録、プライマリ更新トークン（PRT）の取得、テナントのポリシーが許せば追加の認証手段の登録まで進められる。

2026年8月6日時点で、この手法に対応するCVEやMicrosoftのアドバイザリは見つかっておらず、実地悪用の報告もない。Mollemaはこれを「WHfBの仕組みの帰結」と表現し、Microsoft側も意図的にそのまま残していると述べている。

なぜ「借りる」だけで認証できるのか

WHfBキーはTPMに格納され、エクスポートできない、いわゆるデバイスバインドの資格情報だ。通常、クラウドへのシングルサインオン（SSO）は、このキーを支えるデバイスバインドのPRT経由で行われる。そのため「キーが生きたまま盗まれる」ことはない、と考えられている。

しかしMollemaの調査は、認証の前提を覆す。きっかけは**リモートデスクトップ（RDP）**だ。RDPで別のEntra ID参加デバイスに接続すると、そのデバイスはSSOのために、接続元デバイスAのWHfBキーを使ってPRTを要求する。つまり、ハードウェア上はデバイスAに固定されているキーを、デバイスB上で「使う」ことが設計上許されている（スマートカードがRDP越しに使われるのと似た仕組みだ）。

さらにMollemaは、このキーをWebAuthnのFIDO2パスキーとして扱えることを見つけた。通常のWHfBはデバイスバインドPRT経由でSSOに使われるが、SSO非対応ブラウザやシークレットモードでもサインインが成功する。つまり「Entra ID登録・参加済みデバイス」という前提が実は不要で、DEF CON 32（2024年）で発表した旧手法（Entra登録・参加デバイスが必要）から、この要件を取り除けるようになった。

攻撃の流れ

Mollemaが公開したPoC（ROADtoolsリポジトリのfido_assertion.ps1とhellopoc.ps1）に沿うと、攻撃の流れは次のようになる。

1. 被害者のサインイン済みセッションでコード実行を得る（マルウェア感染など）
2. ユーザー権限のコードが、Windowsのチケット動作（対話サインイン中は秘密鍵操作が利用可能）を利用して、WHfBキーによる認証データの署名を要求する
3. 5分間のEntra IDチャレンジはセッション・ユーザー・テナントのいずれにも紐づいていないため、攻撃者は別のホスト上でチャレンジを要求し、侵害されたエンドポイントにその署名を実行させる
4. 得られた署名済みアサーションを、ROADtoolsでトークン要求やブラウザセッションの開始に使う

なぜ永続化につながるのか

ここから先が、この手法を「認証の横取り」ではなく「永続化の経路」にする部分だ。Mollemaの分析によると、得られたトークンにはデバイスIDクレームが含まれない（図2）。このデバイス非結合のトークンを使うと、攻撃者は自分の管理するデバイスを新規登録し、そのデバイス向けにPRTを要求できる。PRTは90日間有効で、デバイスが活発に使われている限り継続更新される。ここまで到達すれば、Microsoftのクラウドサービスへの長期的なアクセスが手に入る。

さらに厄介なのは、このWebAuthnサインインがConditional Accessの「フィッシング耐性のある認証強度」要件を満たすことだ。しかも「新しい多要素認証」としてカウントされるため、ポリシーが許せば、攻撃者は登録したデバイスにパスキーやWHfBキーを追加登録できる。ただし、別途デバイス状態やコンプライアンスを要求するポリシーがあればチェーンは途切れるため、すべての環境でこの完全な永続化経路が成立するわけではない。

検知と対策

Mollemaが推奨する検知は、デバイスIDが空のWHfBサインインのハンティングだ。ただし、正規のシークレットモードや非SSOブラウザセッションも同じパターンを生むため、単独では決定的でない。あわせて想定外のデバイス登録（ユーザーに紐づく未知のデバイス）の監視も有効だ。

より本質的には、この研究は「フィッシング耐性認証の限界」を示している。資格情報がハードウェアに固定され、エクスポート不能であっても、サインイン済みエンドポイント内でコード実行を得たマルウェアは、その資格情報を「借りて」使える。認証の強度だけを上げても、エンドポイントの整合性（EDRによるセッション内の異常なコード実行の早期検知、LSA・チケット操作の監視、デバイス登録イベントの監査）が保たれなければ、防御の穴は残る。

パスキーは「盗めない鍵」ではなく、「貸し出し可能な鍵」だ。鍵の保管場所を守るだけでなく、鍵を使うセッションそのものを守る必要がある。

出典: The Hacker News — Malware Can Abuse Windows Hello for Business Keys for Persistent Entra ID Access / Dirk-jan Mollema — Borrowing Windows Hello keys for authentication and persistence / ROADtools（GitHub） / Microsoft Learn — プライマリ更新トークン