🎯 記事の要約
- パスキーは「ログイン時のフィッシング耐性」は強いが、攻撃者は正面から突破せず、「登録（enrollment）・同期（sync）・復旧（recovery）」という3つの周辺レイヤーへ回り込み始めた。
- Vaultjacking（同期層攻撃）：PhishUが2026年5月に公開。Google Password Manager（GPM）の6桁PINをAiTM（中間者攻撃）で一度奪えば、保管庫全体（パスキー・パスワード）を攻撃者インフラ上で復号・複製できる。ポイントは「SDSがマスター鍵」「Googleにはクロスデバイス承認が無い」こと。
- パスキー登録ヴィッシング（登録層攻撃）：Okta脅威インテリジェンスが2026年7月に報告。脅威アクター「O-UNC-066（Pink）」がMicrosoft 365向けに、偽のパスキー登録画面を使って攻撃者のパスキーを被害者アカウントに直接登録する手口を展開中。
- 保存先によって対象可否が変わる：Vaultjackingの直接対象はGPMに同期保存されたパスキーのみ。Windows Hello（デバイスバウンド）やFIDO2セキュリティキーは同期層の対象外。ただし登録層・復旧層は保存先に関わらずほぼ全員が該当。
- 情シスのアクション：パスキー導入の可否を議論するのではなく、同期パスキーの制御、登録／復旧時の本人確認強化、複数登録による冗長化、登録／デバイス参加イベントの監査という運用設計が重要。
🚨 攻撃面は「ログイン」ではない
パスキーは公開鍵暗号で認証情報をサイトのオリジンに暗号的に紐づけるため、偽サイトでは使えない＝フィッシング耐性が実現されています。ログイン単体の防御力はパスワード＋OTPより明確に高いです。
しかし問題は、攻撃者がその強い部分（WebAuthnのハンドシェイク）を避けて周辺のワークフローを突き始めたことです。現在実際に狙われているのは以下の3レイヤーです。
| レイヤー |
攻撃者の狙い |
関連情報（2026年） |
効く対策 |
| 登録（enrollment） |
パスキーが無いユーザーを偽の登録画面で足止めし、攻撃者が自分のパスキーを被害者の正規アカウントに直接登録 |
O-UNC-066「Pink」がMicrosoft Entra登録を標的（Okta, 2026年7月） |
登録時の本人確認、登録キャンペーンの運用・監査 |
| 同期（sync） |
クラウド同期の集中点（PIN／SDS）を突き、保管庫全体を一括で奪う |
Vaultjacking（PhishU, 2026年5月）／構造解析（Unit 42, 2026年3月） |
同期の許可範囲設計、デバイス参加の監視 |
| 復旧（recovery） |
紛失・機種変更の復旧経路に残る弱い認証（パスワード／SMS／口頭確認）へ落とす |
各社の復旧設計の一般的課題（Microsoft Learn等が対策を明示） |
復旧の本人確認、冗長化、循環依存の排除 |
🔍 自分のパスキーは対象か？「保存先」が決める
Vaultjackingの対象になるかどうかは、「どのサービスにログインするか」「どのブラウザを使うか」ではなく、「パスキーの秘密鍵がどのプロバイダに保存・同期されているか（保存先＝クレデンシャルマネージャ）」で決まります。
重要な原則：Chromeを使っている＝Vaultjackingの対象、ではありません。Chromeでパスキーを作る際に「Google Password Manager」を選べばGPM同期の対象になりますが、「Windows Hello」や「1Password」「FIDO2セキュリティキー」を選べば対象外です。逆にAndroidアプリでGPMに保存したパスキーは、Chromeを使っていなくても対象です。
| パスキーの保存先 |
典型的な利用シーン |
Vaultjacking（同期層） |
登録層（O-UNC-066型） |
復旧層 |
| Google Password Manager（GPM） |
ChromeでGPMを選択／Androidで作成 |
対象（直接対象） |
該当 |
該当 |
| Windows Hello（デバイスバウンド） |
Windows端末・Edge/Chrome |
対象外 |
該当 |
該当 |
| Apple iCloudキーチェーン |
Safari／Apple端末 |
対象外（別構造） |
該当 |
該当 |
| 1Password／Keeper／Bitwarden等 |
各ブラウザ拡張・アプリ |
対象外（マスターパスワードは別の集中点） |
該当 |
該当 |
| FIDO2セキュリティキー（YubiKey等） |
USB/NFCで抜き差し |
対象外（同期レイヤー自体が存在しない） |
該当（attestationで統制可能） |
紛失＝復旧不可。複数登録が前提 |
つまり：同期層（Vaultjacking）は保存先で対象可否が分かれますが、登録層と復旧層は保存先に関係なくほぼ全員が該当します。どの保存先でも設計課題として残ります。
💥 Vaultjacking：PIN 1つで保管庫全体を奪う同期層攻撃
PhishUが2026年5月20日に公開した「Vaultjacking」は、WebAuthnのログイン層ではなくその下の同期層を標的にします。実際のGPMアカウントでエンドツーエンド検証済みとされ、概ね4段階の攻撃フローです。
- PINを釣る：通常のAiTM（中間者攻撃）でパスワードとセッションCookieを奪う流れに、「GPMの6桁PINを確認してください」という偽モーダルを差し込み、PINを入力させる。Google本物のPIN画面を模した見た目のため多くのユーザーが引っかかる。
- 永続化のため攻撃者のパスキーを登録：乗っ取ったセッションで、攻撃者が自分の管理下のパスキーをユーザーのGoogleアカウントに登録。ユーザー自身のパスキーと区別がつかず、パスワードリセット・Cookie失効・トークンローテーションを生き延ぐ。
- 攻撃者インフラからセキュリティドメインに参加：Chromeのセキュリティドメイン参加にはTPM構成証明が必要だが、仮想TPMを備えたコンテナ化Windows VMでこれを満たし、攻撃者パスキーでサインイン。
- 保管庫全体を復号・複製：SDS（マスター鍵）を取得し、同期パスキーとパスワードの保管庫全体を攻撃者インフラ上で復号・複製する。
なぜこれが成立するのか：GPMの同期構造では、SDS（Security Domain Secret）というアカウント単位の対称マスター鍵が全パスキーを暗号化し、新しいデバイスの参加関門は6桁のGPM PINのみ。Googleにはクロスデバイス承認（新しいデバイス参加時に既存デバイスで承認する仕組み）が無いため、PINさえ取られれば一気に突破される。
🎣 パスキー登録ヴィッシング：O-UNC-066「Pink」
Oktaの脅威インテリジェンスが2026年7月に報告した、登録層への攻撃です。脅威アクターO-UNC-066（Unit 42呼称「Pink」）が2026年4月以降、Microsoft 365（Entra）環境向けに展開しています。
- 手法：パスキー登録プロセスそのものを騙すパネル制御型フィッシングキット＋ヴィッシング（電話勧誘）を組み合わせる
- 仕組み：ユーザーを偽の登録フローに誘導し、本人が「パスキーを登録している」と信じ込ませている隙に、攻撃者のパスキーを被害者のアカウントに直接登録する
- 動機：データ恐喝。専用のリークサイトも運用されている
- 登録層攻撃はRP（Relying Party）／IdP側の登録ポリシー（attestation／AAGUID許可リスト等）で大きく影響できる
🌐 ブラウザを変えれば回避できる？
「Chromeが問題なら別のブラウザやセキュアブラウザを使えば回避できるのか」という疑問について、記事は明確に答えています。
- 他ブラウザ（Edge・Firefox・Safari）に変えても、保存先がGPMのままなら対象は変わらない。Vaultjackingが突くのはブラウザではなくGPMの同期構造（SDS・GPM PIN）。
- ブラウザはChromeのままでも、保存先をWindows HelloやFIDO2キーに寄せれば同期層の対象から外れる。「回避したいなら変えるべきはブラウザではなく保存先」が本質。
- ただしブラウザの選択は無意味ではなく、拡張機能のガバナンス、プロファイル同期の統制、AiTMフィッシングの入口削減には有効。
- Chrome Enterprise（管理対象Chrome）でプロファイル同期の可否やパスワードマネージャの有効化を制御可能。
- セキュアブラウザ（Island、Prisma Access Browser、Netskope、Mammoth Cyber等）は、業務パスキーの保存先を管理下に寄せる設計に有効だが、同期構造そのものを無効化するわけではない。
- 重要な限界：同期を後から無効化しても「すでに同期済みの資格情報」は残り続ける。過去に個人アカウントに保存したものの棚卸しは別途必要。
✅ 情シスがやるべきこと
パスキー導入の可否を議論する段階は過ぎました。重要なのは運用設計です。
- 同期パスキーの制御：どの認証器（AAGUID）が許可されているかをIdP側で集計・管理。GPM同期パスキーの利用可否を組織ポリシーで明確化。
- 登録／復旧時の本人確認強化：パスキー登録時の本人確認フローを見直し、conditional access等で登録セッションを統制。
- 複数登録による冗長化：FIDO2セキュリティキー等のデバイスバウンド認証器を併用し、単一障害点をなくす。
- 登録／デバイス参加イベントの監査：新しいパスキー登録やデバイス参加イベントをログ監視し、異常な登録を即座に検知・無効化。
- attestation（構成証明）の活用：WebAuthnの登録セレモニーでRPが許可する認証器をAAGUIDで制限し、不正な認証器の登録を防ぐ。
担当者向けチェックリスト：
① IdPに登録された認証器のAAGUIDを集計 → 保存先を把握
② GPM同期パスキーが業務で使われているか確認
③ パスキー登録時の本人確認・conditional access設定の見直し
④ 登録・デバイス参加イベントのアラート設定
⑤ 復旧経路の認証強度確認（パスワード／SMSに依存していないか）
⑥ デバイスバウンド認証器（FIDO2キー等）の冗長化検討