パスキー時代の新たな脅威：マルウェアがGoogleパスワードマネージャーのパスキーをサイレントに乗っ取る「Pass-ta-key」攻撃

3つの攻撃手法とその仕組み

Pass-ta-key（基本）

この手法では、マルウェアがローカルディスク上の passkey_enclave_state ファイルから、ChromeがTPMでラップしたデバイスID鍵を抽出します。そして、正規のWindows CNG APIを介して攻撃者制御のリクエストに署名させることで、画面上に生体認証やPINのプロンプトを表示することなく、有効なWebAuthnアサーションを生成します。この攻撃は、認証器データ内のUser Verified（UV）フラグを検証しないWebサイトに対してのみ成功します。

悪用する欠陥： クラウド認証器がローカルに保存されたデバイスID鍵を信頼している点、および一部のWebサイトがユーザー検証を強制していない点。

Silver Pass-ta-key

この手法は、ローカルの passkey_enclave_state ファイルを削除または無効化することで、ユーザー検証の強制を回避します。これによりChromeはデバイスの再オンボーディングを強制されます。再オンボーディングの過程で、Chromeは遅延フローでユーザー検証（UV）鍵を一時的に作成しますが、攻撃者はその隙に自身のUV鍵を登録します。Googleのクラウド認証器は新しい鍵のアテステーションを検証しないため、この鍵で署名されたアサーションはUVフラグが1に設定され、ユーザー検証を強制するサイトさえもバイパスします。攻撃者は自身のマシンから持続的かつ再利用可能なアクセスを得るため、被害者のデバイスがオンラインである必要すらありません。

悪用する欠陥： デバイス再オンボーディング時のアテステーション検証の欠如、およびエンクレーブ状態ファイルを保護なしで削除できる点。

Golden Pass-ta-key（深刻）

この手法は上記と同じ再オンボーディングフローをトリガーした後、Chromeのプロセスメモリをダンプして**Security Domain Secret（SDS）**を回復します。SDSは32バイトの対称鍵で、被害者のGoogleアカウントに同期されたすべてのパスキーを暗号化しています。SDSを入手した攻撃者は、既存および将来同期されるすべてのパスキーの秘密鍵を復号でき、それらのパスキーで保護された全サービスへの完全なアカウント乗っ取りが可能になります。Googleは以前、Chromeの chrome://device-log/FIDO 出力にSDSを平文で記録していました（Unit 42の開示後に削除）が、メモリ露出の問題は残っています。

悪用する欠陥： オンボーディングフロー中にSDSがChromeのプロセスメモリ内に平文で存在する点。

影響を受けたサイト

基本的なPass-ta-key攻撃は、UVフラグを検証しないすべてのWebサイト（Relying Party）に有効です。Unit 42はeBayをそのようなサイトの一つとして特定しましたが、eBayはその後修正を行っています。研究者らは、「驚くべき数の」Webサイトが登録時に userVerification: "required" を要求しながら、返されたUVビットを実際には検証していないと指摘しています。

マスターキー（SDS）が漏洩した場合のリスク

SDSは、ユーザーのGoogleアカウントに同期されたすべてのパスキーのマスターキーとして機能する32バイトの秘密です。SDSが盗まれると、以下のリスクが発生します。

• 既存の同期済みパスキーの秘密鍵がすべて復号可能になり、その後同期される新しいパスキーも読み取り可能になります。
• 攻撃者はGmailを含むあらゆるパスキー保護アカウントに、被害者からのさらなる操作を必要とせずに認証できます。
• 攻撃者がGmailにアクセスできれば、関連する下流アカウントのパスワードをリセットできるため、被害範囲は直接侵害されたサービスをはるかに超えます。
• SDSをローテーションする組み込みのメカニズムはありません。つまり、Googleはユーザーが新しいSDSを生成する方法を提供していません。

推奨される対策

Unit 42の調査結果と関連報道に基づく主要な対策は以下の通りです。

• 同期パスキーに加えて、少なくとも1つのハードウェアセキュリティキー（例：YubiKey）を登録する — デバイスにバインドされた認証情報はクラウドに同期されず、Chromeのエンクレーブ状態に入らず、メモリから読み取られることもありません。
• 高リスクユーザー（ジャーナリスト、経営幹部、活動家、管理者）はGoogleの高度保護プログラム（Advanced Protection Program）を有効にする — これによりセキュリティキーまたはデバイスバインドパスキーが必須となり、アカウント復旧パスが強化されます。
• Googleアカウントのデバイスリストを毎月監査し、認識できないセッションを削除する。
• 情報窃取型マルウェア（インフォスティーラー）への感染は、完全な認証情報リセットイベントとして扱う — 復旧後、マシンを再構築し、クリーンなデバイスからすべてのパスキーを再登録します。
• サービス提供側（Relying Party）はサーバーサイドでUVフラグを検証し、機密性の高い操作には userVerification を "preferred" ではなく "required" に設定する。

現状

本稿執筆時点（2026年8月3日）では、いずれの攻撃にもCVEは割り当てられておらず、GoogleはSilverまたはGoldenの攻撃経路を直接修正するかどうかについて公に確認していません。