Chromeのパスキー同期機能を狙う「Pass-ta-key」攻撃、マルウェアによるアカウント乗っ取りの懸念

要点

• Windows版Chromeの「Google パスワード マネージャー」に同期されたパスキーを狙う、新たな攻撃手法が明らかになりました。

• セキュリティ研究機関のUnit 42が、「Pass-ta-key」など3つの攻撃ルートの詳細を報告しました。

• 暗号技術そのものの破綻ではなく、Chromeのデバイスキー保存方法やデバイス再登録時の仕様といった周辺の実装が標的となっています。

• いずれの攻撃ルートも、すでに標的のWindows端末が一般ユーザー権限のマルウェアに感染していることを前提としています。

• ログイン先のWebサイト側の検証が不十分な場合、ユーザーに一切気付かれずに不正ログインが行われる可能性があります。

• 米パロアルトネットワークスの脅威インテリジェンス部門「Unit 42」は2026年8月3日、Windows上のGoogle Chromeにおける「Google パスワード マネージャー」のクラウド認証機能を標的とした3つの攻撃手法を公開しました。これらの手法は「Pass-ta-key（パス・タ・キー）」「Silver Pass-ta-key（シルバー・パス・タ・キー）」「Golden Pass-ta-key（ゴールデン・パス・タ・キー）」と命名されており、一般ユーザー権限で動作するマルウェアが、被害者の画面に指紋認証やPIN入力などのプロンプトを一切表示させることなく、パスキーで保護されたアカウントへ静かにログインできる可能性が示されています。

攻撃の前提と対象範囲

今回の研究が対象としているのは、安全な暗号処理を行う専用チップである「TPM（Trusted Platform Module）」を搭載したWindowsシステム上で動作するChromeのGoogle パスワード マネージャーです。

Unit 42が指摘する攻撃はいずれも、パスキーで使用されている公開鍵暗号のアルゴリズム自体を破壊するものではありません。そうではなく、Chromeがデバイスキーを格納する仕組みや、デバイスの状態が失われた際に再登録（再エンロール）を行うプロセスの不備、およびログイン先のWebサイトがユーザー認証の有無を正しく検証しているかという「パスキーの周辺仕様と実装」に焦点を当てています。また、これらの手法はすべて、すでに被害者のデバイス上で何らかのマルウェアが動作していることを前提とした「ポストエクスプロイト（感染後）」の技術です。

ローカルデータの偵察から始まるプロセス

攻撃の第1段階として、マルウェアはローカル環境の偵察を行います。Chromeは同期された資格情報のレコードを、ユーザーフォルダ内の特定のディレクトリである *%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB* に保存しています。Unit 42によると、管理者権限のない一般ユーザー権限のプロセスであっても、このデータベースから十分なメタデータを読み取ることが可能です。これにより、パスキーが紐づいているWebサイト（リライングパーティ）の名前やユーザー名、さらには資格情報識別子や暗号化された秘密鍵のデータなどを特定できます。

第1の攻撃ルート：「Pass-ta-key」

最初の攻撃手法である「Pass-ta-key」は、Chromeが保持するデバイス識別キーを取り出し、Windowsの暗号化APIである「CNG（Cryptography API: Next Generation）」を通じてTPMに対して署名を要求するものです。

Chromiumのソースコードを確認すると、ChromeはTPMキーを作成する際に「キー名」を指定していません。これはキーがディスクに永続化されるのを防ぐための仕様ですが、一方でChromeは作成したキーを不透明なデータ（blob）としてエクスポートし、後からプロンプトを表示しない設定のまま再ロードしています。このため、マルウェアがこのデータを再利用してTPMに署名させることが可能になってしまいます。

この手法で取得された認証アサーション（ログインの証明データ）には、ユーザーの本人確認が完了したことを示す「UV（User Verified）フラグ」が書き込まれません。WebAuthn（Web認証）の標準仕様では、Webサイト側がユーザー検証を「必須（required）」と設定している場合、このUVフラグがないアサーションでのログインを拒否しなければならないと定められています。

しかし実際にはWebサイト側の対応に差がありました。調査によると、GitHubはこの検証を厳格に行っていましたが、eBayは当初この検証が不十分であり、UVフラグのないテスト用の証明データでもログインを受け入れていました。なお、eBayはこの問題の指摘を受けた後に検証の不備を修正しています。

第2の攻撃ルート：「Silver Pass-ta-key」

さらに高度な第2の攻撃ルート「Silver Pass-ta-key」は、マルウェアが意図的にChromeのデバイス再登録を強制する手法です。

Chromeが新しいデバイスとして再登録処理を行う際、ユーザー検証キーの作成が完了するまでにわずかな時間的猶予（ウィンドウ）が生じます。攻撃者はこの隙を狙って、自身が制御する別の検証キーを登録します。

Unit 42の報告によると、Googleのサービス側は新しく登録されたキーが安全なハードウェアによって生成されたものかどうかを検証していません。その結果、攻撃者が自身の環境で生成したキーを使って署名したアサーションであっても、正当な「UVフラグ付き」のものとして扱われてしまいます。これにより、一度端末が侵害されると、攻撃者は被害者の物理デバイスがない状態からでも、自身の環境から継続的にアカウントへログインし続けることが可能になります。

影響と対応状況

現時点で、これらの攻撃手法が実際のサイバー攻撃で悪用された事例は確認されていません。また、米国の脆弱性情報データベース（NVD）においても、本件に関連するCVE（共通脆弱性識別子）は登録されていません。また、最新の安定版Chromeにおいてこの脆弱性がそのまま悪用可能かどうかの詳細な修正ステータスは、今回の報告書には明記されていません。

補足

パスキーは従来のパスワードに比べてフィッシング詐欺に強い安全な認証手段とされていますが、OSやブラウザなどのローカル環境がマルウェアによって完全に掌握された場合には、その信頼性の前提となる処理プロセスがバイパスされるリスクがあることを、今回の研究結果は示しています。