パスキーの「登録」が新しい攻撃面になる：Pass-the-Passkeyが IdP 運用に突きつけたもの

パスキーの売り文句は単純で、しかも正しいものでした。フィッシングで盗めるものが存在しない。偽ドメインに入力させられる文字列がそもそも無い。認証情報のフィッシングでアカウントを失い続けてきた企業にとって、移行の理由はそれだけで十分でした。

ところが2026年8月初旬、48時間と離れないタイミングで2つの独立した研究チームが成果を公開し、その一文の実務上の意味を変えました。どちらも暗号方式そのものは破っていません。両方とも「迂回」しています——そして両方が同じ場所に着地しました。認証情報が登録される瞬間です。

統合的なアイデンティティ基盤を運用中、あるいは計画中であれば、ここは丁寧に読む価値があります。対処のほぼすべては設定の問題であり、その大部分はエンドポイントではなくIdP側に存在します。

8月に何が起きたのか

Unit 42、8月3日。 研究者Arie Olshtein氏が、Google Password Managerの同期パスキーに対する3つの攻撃チェーンを公開しました。いずれもWindows上のChromeが使うクラウドオーセンティケーター経由で成立します。3つとも前提は同じで、通常のユーザー権限でマルウェアがすでに端末上で動作していること——管理者権限は不要、被害者の画面には何も表示されません。

1つ目は、信頼済みデバイスになりすましてGoogleのクラウドオーセンティケーターから有効な認証アサーションをそのまま取得します。指紋センサーにもPIN入力にも一切触れません。2つ目はデバイス再登録のワークフローを悪用します。マルウェアが既存の検証鍵を無効化するか、端末上の認証情報の状態ファイルを削除してChromeに再オンボーディングを強制し、その過程で自分自身のユーザー検証鍵を登録する。以後、攻撃者は自分の端末からサインインでき、被害者の端末に二度と触れる必要がありません。3つ目が最も重大で、再登録の最中にChromeのプロセスメモリ上へ一瞬だけ現れる32バイトのセキュリティドメインシークレットを抜き取ります。この1つの値が、アカウント上の同期パスキーの秘密鍵すべてを——後から作られたものも含めて——復号します。そして現時点で、漏洩後にこの値をローテーションまたは失効させる手段はありません。

これらにCVEは割り当てられていません。Googleは一部の緩和策を展開済みです。

SpecterOps、8月5日、Black Hat USA。 Michael Grafnetter氏が、意図的にPass-the-Hashになぞらえて命名した攻撃群を発表しました。最も深刻なチェーンは2つの弱点の組み合わせです。Windows 11が完全なWebAuthnアサーションレスポンスを運用イベントログに書き出しており、認証済みだが特権を持たないユーザー——構成によってはリモートのユーザー——がそれを読めた。一方でMicrosoft Entra ID側の検証が、リプレイを拒否できるほど厳格ではなかった。両者が揃うことで、フィッシング耐性MFAの強制を満たしたまま、特権クラウドIDへのなりすましが可能になります。同じ研究では、ハードウェアトークンの過去の署名が平文で、非特権アカウントから読める状態にあったことも判明しています。

Microsoftはロギング側をCVE-2026-34348として2026年7月14日の更新で修正し、ログに記録される署名部分を6バイトに切り詰めました——トラブルシューティングには足りるが、リプレイには足りない長さです。SpecterOpsは、パッチ適用済みシステムではWindowsからEntraへの一連のチェーンは成立しないとしています。

構造的な論点：リスクは「登録」へ移動した

パスワードの時代、秘密そのものが資産でした。盗んで、再送する。私たちが積み上げてきた防御——定期変更、複雑性要件、MFA、あり得ない移動の相関検知——はすべて、攻撃者の目的が「ユーザーがすでに持っているものを手に入れること」だという前提の上に立っています。

パスキーの時代、その目的はほぼ機能しなくなります。デバイスバウンドの秘密鍵はオーセンティケーターから出ませんし、パスキーをフィッシングすることはできません。だから攻撃者の問いは、どうやって認証情報を盗むかからどうやって自分宛てに発行させるかへ変わります。

Silver Pass-ta-keyがこの点を最も明瞭に示しています。攻撃者はユーザーの鍵を一度も手に入れていません。システムがまさにその目的のために用意したワークフローを通じて、自分の鍵を追加しただけです。これは認証情報の窃取ではなく、認証情報の発行です。しかも、盗まれたパスワードには決してなかった持続性があります。通常はインシデントを収束させるはずのパスワード変更とセッション失効を、そのまま生き延びるからです。

IdPが新しいオーセンティケーターを受け入れる瞬間は2つしかありません。初回登録と、復旧または再登録です。多くの導入環境において、この2つはアイデンティティ基盤全体で最も監視が薄く、最もポリシー制御がかかっていない操作です。

flowchart TD
    A["認証情報の登録"] --> B["日常の認証"]
    B --> C["復旧または再登録"]
    C --> A
    A --> D["攻撃者が自分のオーセンティケーターを登録"]
    C --> D
    B --> E["ログから採取したアサーションをリプレイ"]
    C --> F["再オンボーディング中に同期マスターシークレットを抽出"]
    D --> G["パスワード変更を生き延びる持続的アクセス"]
    E --> G
    F --> G

導かれる帰結は、居心地は悪いものの明快です。あなたのパスワードレス態勢の強度は、最も弱い登録経路とちょうど同じです。 ヘルプデスク担当者が電話一本で財務部長のアカウントに新しいオーセンティケーターを紐付けられるなら、それはパスキーの衣を着たパスワードリセット手続きに過ぎません。

日本企業として並行して考えるべき論点

個人情報保護法と報告義務。 攻撃者が従業員名義で正規に登録された認証情報を使って侵入した場合、調査チームが最初に直面する問いは「どの個人データに、いつからアクセスされたのか」です。各オーセンティケーターがいつ、どこから登録されたかの記録が無ければ、個人情報保護委員会への速報が求められる時間軸の中でこの問いに答えられません。認証情報のインベントリはセキュリティ施策であると同時に、事故が起きる前に整えておくべき証跡です。

J-SOXとIT全般統制。 アクセス管理は内部統制の評価範囲であり、監査で問われるのは「誰がアクセスできたか」だけでなく「その権限がどう付与されたか」です。認証方式の登録・削除イベントが記録されておらず、承認プロセスも定義されていない状態は、統制上の不備として指摘され得ます。特権ロールに対する認証情報の追加は、承認記録の残る操作として設計してください。

経済安全保障推進法とNISCの基準。 基幹インフラ事業者に該当する場合、認証基盤の構成変更は特定重要設備に関する審査の対象になり得ます。海外クラウドの同期パスキー機構に特権IDの信頼を全面的に預ける構成は、審査の場で説明を求められる可能性がある——という前提で設計判断を残しておくのが安全です。

IdPで設定すべき6つのこと

1. 登録を特権操作として扱う

多くのテナントの既定では、認証済みセッションであれば追加の認証方式を登録できます。これが何を意味するか考えてみてください。従来は期限切れで消えていた盗難セッションクッキーが、恒久的に登録された認証情報へと変換されるのです。

登録を、セッションクッキー単体では満たせない条件の後ろに置いてください——管理下かつコンプライアンス準拠の端末、直近数分以内に実施した再認証、既知のネットワーク範囲、あるいは管理者が明示的に開いた登録ウィンドウ。Entra IDであれば認証方法ポリシーと、セキュリティ情報の登録というユーザーアクションを対象にした条件付きアクセス規則の組み合わせです。Authentikであれば、通常のログインフローが副作用として新規デバイスを紐付けるのを許さず、独自のステージとポリシーを持つ専用の登録フローを用意することを意味します。

覚えておくべき原則は1つです。新しい認証情報の追加を承認する認証情報は、追加される側と同等以上の強度を持つべきです。

2. ユーザー検証フラグを「人がそこにいた証拠」として扱わない

リライングパーティの多くは、アサーション内のユーザー検証ビットを、誰かがセンサーに触れたかPINを入力した証拠として受け入れます。Unit 42の指摘は、侵害されたオーセンティケーターは誰も何も触れないままそのビットを立てられる、というものです。

リライングパーティを自社で保有している場合は、真偽値1つを読むのではなくアサーション全体を検証してください——オリジン、チャレンジの鮮度、署名カウンタの挙動、そしてオーセンティケーターの機種識別子と許可リストの照合です。保有していない場合——つまり大半のSaaS——は、代替統制をIdP側に置くしかありません。そもそもどの機種の登録を許すかを制限するということです。

3. 同期型かデバイスバウンドかを、全社一律ではなく階層別に決める

同期パスキーはパスキー普及の原動力でした。復旧の物語があったからこそ一般の利用者が使えるものになったのです。同時にそれはクラウドアカウント1つ分の被害半径を持ち、Golden Pass-ta-keyは同期の裏側にあるマスターシークレットに現時点で失効手段が無いことを示しました。

説明可能な線引きはこうです。一般的な社内アプリケーション群には同期型で構いません。管理者ロール、財務システム、そして資金移動やアイデンティティ設定の変更ができるものすべてには、登録時のアテステーションを必須としたデバイスバウンドのハードウェアオーセンティケーターを。ポリシー文書は登録リクエストを止めませんから、登録時点のアテステーションと機種許可リストで強制してください。

4. 復旧経路こそが実際のセキュリティ水準

人はスマートフォンを失くすので、どのパスワードレス導入にも代替手段が残ります。SMSワンタイムコード、メールのマジックリンク、ヘルプデスク主導のリセット、一時アクセスパス。

その代替手段がパスキーを新規発行できるなら、主たる方式が何であれ、代替手段こそが認証強度です。攻撃者は10年前から復旧経路へ直行してきましたし、主経路が難しくなった今、その傾向が変わると考える理由はありません。

具体的には、一時アクセスパスの発行を名前で特定された少人数に限定し、短命かつ1回限りとし、発行のたびに必ずアラートを上げること。ヘルプデスク主導のリセットは、発信者がすでに掌握している可能性のない経路で本人確認を行うこと——つまりアカウントに紐付いたメールアドレスと電話番号は使えません。

5. 認証情報インベントリを作り、その変化を監視する

多くの組織は、自社のオーセンティケーターについて基本的な問いに答えられません。このユーザーは何個持っているのか、それぞれいつ、どの端末とどの場所から登録されたのか、そのうち実際に使われているのはどれか。

まずその一覧を作ってください。そのうえで、意味のあるパターンをアラート対象にします——新しい国からの登録、1つ目の直後に数分で追加された2つ目、業務時間外の登録、そして特権ロールを持つアカウント上のあらゆる認証情報変更。これらは事故の後で読まれる監査ログに眠らせるのではなく、担当者を呼び出すべき事象です。

退職処理も同じ文脈にあります。SCIMのデプロビジョニングは、セッションの無効化に加えて登録済み認証情報の削除まで行う必要があります。オーセンティケーターが紐付いたまま停止されたアカウントは、再有効化を待っている状態です——そしてこれこそ統合アイデンティティ基盤が塞ぐべき種類の穴です。

6. 7月のパッチが本当に適用されたか確認する

CVE-2026-34348は2026年7月14日に公開されました。WindowsからEntraへのリプレイチェーンは、このパッチが当たっていないことに依存します。全社的な適用状況を確認し、特に管理用ワークステーションと踏み台サーバーに注意してください。最も価値の高い標的であると同時に、多くの組織で標準のパッチ適用リングから除外されがちな端末でもあります。

堅牢化された登録フロー

flowchart TD
    U["利用者が新しいオーセンティケーターの登録を要求"] --> P1["端末が管理下かつコンプライアンス準拠か確認"]
    P1 --> P2["直近の再認証を必須とする"]
    P2 --> P3["アテステーションを機種許可リストと照合"]
    P3 --> T["アカウント階層を評価"]
    T --> H["特権階層はデバイスバウンドのハードウェアキー必須"]
    T --> S["一般階層は同期パスキーを許可"]
    H --> L["登録イベントを記録しアラート"]
    S --> L
    L --> R["認証情報を登録しインベントリへ追加"]

検知も運用している場合

上記の登録制御が本質的な対策です。エンドポイントのテレメトリ基盤も運用しているなら、Unit 42の手法に素直に対応する3つのシグナルをルールセットに加える価値があります。署名されていない、あるいは通常見かけないバイナリからのブラウザメモリへのプロセスアクセス、ブラウザ以外のプロセスによるブラウザ認証情報の状態ファイルの作成・削除、そしてブラウザ以外のプロセスによる同期データベースの読み取りです。Sysmon環境であればイベントID 10と11、および標準のファイルアクセステレメトリに対応します。

アイデンティティ側で、監査ログからアラートへ格上げすべきイベントは、認証方式の登録と削除、一時アクセスパスの発行、アテステーション検証の失敗、そして特権ロールに触れるあらゆる認証情報の変更です。すでにWazuhベースの監視スタックを運用しているなら、これらは新しいツールではなく追加のログソースにすぎません。

今週中に実施できる短い監査

1. テナント内で新しいオーセンティケーターを登録できる経路をすべて洗い出す。技術的なフローだけでなくヘルプデスクの手続きも含める。
2. 各経路について、有効な盗難セッションだけを持つ攻撃者が何を突破する必要があるかを書き出す。
3. 登録が端末コンプライアンスと直近の再認証で制御されているか、それとも既存セッションのみで通るかを確認する。
4. 管理者ロールを持つ全アカウントの認証情報インベントリを抽出する。想定外の端末や時刻に登録されたものを探す。
5. どの復旧手段が新しいパスキーの発行につながり得るか、そして誰がそれを起動できるかを確定する。
6. 管理用ワークステーションに絞ってCVE-2026-34348の適用状況を検証する。
7. 退職処理がセッションだけでなく認証情報も削除するか確認する。実アカウントで実際に試す。

よくある質問

パスキーの展開を止めるべきですか。

いいえ。パスキーは認証情報フィッシングを排除します。これは依然として、他を大きく引き離して最も一般的な初期侵入経路です。8月の研究はその事実を変えていません。変わったのは「パスキーを導入すればアイデンティティの仕事は完了する」という前提のほうで、仕事は登録・復旧・インベントリへ移動しました。本来そこにあるべきものでした。

Google Password Managerを使っていなければ影響はありませんか。

Unit 42の個別のチェーンはWindows上のGoogleの同期パスキー環境を対象としています。ただし構造的な教訓は同期型の認証情報システム全般に当てはまり、SpecterOpsのチェーンはWindows 11とEntra IDを直接の対象にしています。従業員がMicrosoft 365で認証しているなら、まず読むべきは後者です。

ハードウェアセキュリティキーは今も価値がありますか。

特権アカウントについては、あります。アテステーション付きのデバイスバウンド認証情報は依然として最も強い選択肢であり、同期マスターシークレットの問題は該当しません。8月の研究はWindowsログ上にハードウェアトークンの署名が露出していたことを発見しましたが、それはパッチを当てる理由であって、ハードウェアトークンをやめる理由ではありません。

専任のアイデンティティ担当がいない中堅企業です。どこから着手すべきですか。

登録のゲートと復旧経路からです。この2つで実務上のリスクの大半が塞がり、いずれも新しいソフトウェアを必要としません——すでに運用しているIdPの設定変更です。認証情報インベントリはその次です。一度も数え上げたことのないものの変化を監視することはできないからです。

単一のIdPへ集約すると、リスクが一点に集中して悪化しませんか。

集中するのは統制点であり、リスクの集中とは逆です。24個の独立したログインシステムがあれば登録と復旧の経路も24組あり、その大半は誰も監査したことがありません。IdPが1つなら、堅牢化すべき経路は1組、維持すべきインベントリは1つ、失効を実行する場所も1箇所です。

---

この記事の位置づけ

上記すべての前提は、アイデンティティの集約です。各アプリケーションが自前でログインを管理する分断された環境では、登録にゲートをかけることも、アテステーションの階層を強制することも、認証情報インベントリを維持することもできません——それが集約そのものの根拠です。

SimplicoはsimpliSSOを構築・運用しています。Microsoft 365およびAzure ADとフェデレーションしたAuthentikベースのアイデンティティポータルで、OIDC、SAML2、LDAP、ステップアップMFAポリシー、そして全アプリケーション資産へのSCIMプロビジョニングをカバーします。既存環境の登録堅牢化を進めている、あるいは新規導入のスコープを検討している場合は、環境を拝見しますのでお声がけください：hello@simplico.net

---

出典:

• Pass the Passkey: A Novel Attack Surface in Passwordless Authentication — Unit 42
• New Passkey Attacks Can Recover Synced Private Keys or Bypass Phishing-Resistant MFA — The Hacker News
• New Pass-ta-key attacks let malware hijack Google-synced passkeys — BleepingComputer
• Flaws in Passkey Implementation Show Old Attacks Still Work — Dark Reading
• Pass-the-Passkey Family of Attacks at Black Hat USA 26 — DSInternals