ニュース

Googleパスワードマネージャーのパスキー認証を突破する3つの攻撃手法が発覚——情シスはマルウェア対策の強化を

2026.08.05

はじめに

Palo Alto Networks の脅威調査チーム Unit 42 は 2026年8月3日（米国時間）、Windows版 Google Chrome に搭載された「Googleパスワードマネージャー」においてパスキー認証を突破できる3つの攻撃手法を公表しました。「Pass-ta-key」「Silver Pass-ta-key」「Golden Pass-ta-key」と総称されるこれらの攻撃は、いずれもマルウェア感染を起点とします。特権昇格は不要であり、ユーザーが気づかないうちにパスキーで保護されたアカウントを乗っ取られる恐れがあります。情シス担当者は自社デバイスのマルウェア対策状況を今すぐ確認してください。

1. 何が起きたか

Palo Alto Networks の脅威調査チーム Unit 42 は 2026年8月3日（米国時間）、Windows版 Google Chrome に組み込まれた「Googleパスワードマネージャー」のパスキー（Passkey）実装に関する研究成果を公表しました。

パスキーはパスワードレス認証の本命として普及が加速しており、多くの企業でも業務アカウントへのパスキー採用が広がっています。しかし今回の発表により、マルウェアに感染した端末では、パスキーで保護されたアカウントも安全ではないことが明らかになりました。

Unit 42 が「Pass-ta-key」と総称するこの一連の攻撃では、3つの異なる手法によってパスキー保護を突破できることが示されました。いずれの攻撃も次の特徴を持ちます：

  • マルウェアがデバイス上で動作していれば十分
  • 特権昇格（管理者権限）は不要
  • ユーザーが介入しなくても実行可能

現時点では野生での悪用は報告されていませんが（2026年8月5日時点）、Googleの公式パッチはまだ発表されていません。

2. 3つの攻撃手法の詳細

攻撃①「Pass-ta-key」——パスキー認証を無音でバイパス

1つ目の手法は、マルウェアが Google ChromeおよびGoogleパスワードマネージャーの正規動作を模倣することで、パスキー認証を完全にバイパスする攻撃です。

ChromeはTPM（Trusted Platform Module）から取得したIDキーの暗号化データをローカルに保管しています。マルウェアはこの暗号化データを抽出し、認証に悪用します。ユーザーの同意・生体認証・デバイスロック解除などをすべてバイパスできます。

発動条件：Webサービス側の userVerification パラメータが preferred（推奨）に設定されている場合に有効。

攻撃②「Silver Pass-ta-key」——パスキーの「乗っ取り再登録」

2つ目の手法は、ユーザー検証キーを偽装する攻撃です。

マルウェアがローカルの既存検証キーを無効化し、次回のパスキー使用時に「再登録」を強制します。再登録中、ChromeはキーのTPMへの書き込みを一時保留する設計になっています。この空白の間に攻撃者自身の公開鍵を挿入・登録します。

一度登録に成功すると：

  • 被害者がオフラインでも、攻撃者の環境から有効なアサーション（認証証明）を生成できる
  • 攻撃者はそのアカウントをいつでも乗っ取れる状態が続く

攻撃③「Golden Pass-ta-key」——マスターキー（SDS）の奪取

3つ目にして最も深刻な手法です。すべてのパスキー秘密鍵を保護するマスターキー（SDS: Security Domain Secret）を盗み取ります。

Silver Pass-ta-keyで再登録を強制した後、キー登録・復旧フローの中でSDSがChromeのプロセスメモリ上に一時的に平文（暗号化なし）で展開されます。マルウェアがこのタイミングでメモリからSDSを抽出します。

SDSを入手した攻撃者が得られる被害は以下のとおりです：

被害 詳細
過去のパスキー復号 同期データベース上の暗号化パスキーレコードをすべて復元可能
将来のパスキーも復号 SDSはローテーション・失効が不可能なため永続的侵害

現在の Google の実装では SDSをローテーション（更新）・失効（無効化）する仕組みが存在しないため、一度SDSが漏洩すると、今後作成するすべてのパスキーも復号可能という非常に深刻な状態に陥ります。

3. 影響範囲と条件

項目 内容
影響対象 Windows版 Google Chrome + Googleパスワードマネージャーでパスキーを使用しているすべてのユーザー
攻撃の起点 端末へのマルウェア感染
必要な権限 特権なし（一般ユーザー権限で動作）
現時点での野生の悪用 未報告（研究報告段階）
Googleの対応 2026年8月5日時点で公式パッチは未発表

攻撃のすべてにマルウェア感染が前提となります。端末をマルウェアから守ることが最も重要な防御策です。

4. 対応方法

Unit 42 は関係者それぞれに向けた対策を提示しています。

情シス担当者がすぐに行うべきこと

  1. エンドポイント保護（EDR/EPP）の状態を確認する — 全社デバイスにマルウェア対策が導入されているか確認してください。
  2. プロセスメモリへのアクセス制限を強化する — EDR製品の「クレデンシャル保護」や「メモリ保護」機能を有効化してください。
  3. 不審なアプリ・スクリプトの実行制御を確認する — アプリケーション制御ポリシー（Windows Defender Application Control等）の適用状況を見直してください。
  4. パスキーを使用している業務アカウントの把握 — 社内で Google パスワードマネージャーでパスキー認証している業務システムがあれば、利用状況を整理してください。

Webサービス運営者（RP）への推奨

  • userVerification を required に設定する（preferred のままにしない）
  • 新規デバイス登録時に追加の検証ステップを設ける

Googleへの期待（プラットフォーム側の課題）

Unit 42 は Google をはじめとするブラウザ開発者に以下の対応を求めています：

  • デバイス上のシークレット（SDS等）の平文露出を防ぐ設計の見直し
  • 復旧・再登録フローのセキュリティ強化
  • ローカルのパスキーデータへのアクセス制限
  • 異常なパスキー使用の検知機能の実装
  • SDSのローテーション・失効機能の追加（最優先）

5. まとめ

「パスキーは安全」という認識は、今回の研究によって大きく揺らぎました。パスキー自体の設計よりも、GoogleパスワードマネージャーのWindows実装における鍵管理の問題が露呈した形です。

情シスとして今すぐできる対策は「マルウェアを端末に入れない」ことに尽きます。EDRの導入・強化、不審なアプリの実行制限、フィッシング対策を組み合わせた多層防御を改めて見直してください。

Googleの公式パッチ・対応状況については今後の続報をお待ちください。YJKでは引き続き最新情報をお伝えします。

YJKにセキュリティ対応を相談する

出典

𝕏 でシェアする
ニュース一覧に戻る