Pass the Passkey: パスワードレス認証における新たな攻撃対象領域

脅威リサーチセンター脅威リサーチマルウェアマルウェアPass the Passkey: パスワードレス認証における新たな攻撃対象領域 17分 関連製品CortexCortex Cloud 著者: Arie Olshtein 公開日: 2026年8月3日 カテゴリ: マルウェア脅威リサーチ タグ: Google authenticatorGoogle ChromeGoogle CloudIdentityKeyPasskeyPasswordless 共有 エグゼクティブサマリー本記事は、パスワードレス認証に対する新たな攻撃クラスを分析し、Googleの同期パスキーエコシステムとデスクトップクライアントが使用するCloud Authenticatorに焦点を当てています。これらの攻撃は、侵害されたエンドポイント上のマルウェアが、オンボーディング、リカバリ、デバイス信頼ワークフローを悪用してパスキーで保護されたアカウントを乗っ取ることができることを示しています。攻撃者がユーザーの操作なしに認証を完了し、ユーザー検証要件をバイパスし、同期されたすべてのパスキー秘密鍵を抽出できることを示します。数十年にわたる侵害と数十億ドルの損失を経て、パスワードと共有シークレットの時代を定義した攻撃ベクトルは、ついに衰退し始めています。パスキーは、公開鍵暗号化を使用してパスワードと従来の多要素認証（MFA）を置き換えることで、長年脅威ランドスケープを支配してきた攻撃クラス全体を減少させます。盗んだり、再利用したり、フィッシングしたりする共有シークレットがないため、攻撃者の最も信頼できるツールの多くは時代遅れになりつつあります。これは、認証情報窃盗市場にとって大きな変革となります。しかし、攻撃者はしぶとく、進化し、防御者は新世代の攻撃に備える必要があります。パスキーが広く採用され、数十億のアカウントにスケールするにつれて、防御者は新たな攻撃対象領域に備える必要があります。本研究で開示する攻撃対象領域の一部も含まれます。この記事は、セキュリティの観点からパスキーの採用を検証するシリーズのパート3です。以前のパートをまだ読んでいない場合は、ここから始めることをお勧めします。パート1: 見えない鍵のアート – パスキーの世界的ブレークスルーパート2: Google Authenticator: パスワードレス認証の隠されたメカニズムパロアルトネットワークスの顧客は、以下の製品とサービスを通じて、この新しい攻撃ベクトルからより保護されています。Cortex Cloud Identity SecurityIdira Threat Detection and ResponseIdira Endpoint Privilege ManagerIdira Privilege Access Management侵害された可能性があると思われる場合、または緊急の事柄がある場合は、Unit 42インシデントレスポンスチームに連絡してください。関連するUnit 42トピックGoogle Authenticator、Cloud、マルウェア 設定の準備Googleの同期パスキー実装は、その規模と、2つの重要な方法で秘密鍵の保護に高い基準を設定する方法により、特に教育的です。秘密鍵はクラウドエンクレーブ分離環境内で生成および使用されます。ハードウェアバックアップされ、クライアントデバイスにバインドされた鍵が、クラウドベースの暗号化操作へのアクセスを制御し、信頼されたデバイス上のユーザーの存在を証明します。この記事は、以前のシリーズ記事のパート1とパート2のアーキテクチャ分析に基づいています。パスキーがどのように構築および展開されるかから、攻撃者がそれをどのように悪用できるかに焦点を移します。パスキーで保護されたアカウントの乗っ取りを可能にする3つの新しい攻撃を紹介します。各攻撃は、パスキー認証セキュリティの異なる中核的な仮定に挑戦します。クライアントがパスキーで認証する場合、次のことが期待されます。ユーザーはデバイス上で明示的な同意を提供して、ユーザーの存在を検証します。MFAの場合、ユーザーは生体認証（つまり、あなたが持っているもの）または知識ベースの認証（つまり、あなたが知っているもの）の認証要素を検証するためにデバイスのロックを解除する必要があります。パスキー秘密鍵は共有またはコピーできません。Googleのドキュメントはこれらの主要な仮定を反映しており、パスキーログインプロセスをパスワードの安全な代替手段として説明しています（図1を参照）。図1. Googleのドキュメントは、パスキーにはデバイスへのアクセス、デバイスのロック解除、および共有不可能な認証情報が必要であると説明しています。これらの期待に挑戦するのは、私たちが「Pass-ta-key」と名付けた一連の攻撃です。この遊び心のある、層状の名前は、パスキーという単語と「鍵を渡す」というフレーズを組み合わせ、パスタ皿の概念に軽く言及して、この鍵の実装がいかに複雑になりうるかを示しています。これらの攻撃はそれぞれ、実際には異なる弱点を露呈します。Pass-ta-key攻撃: 攻撃者は、特権昇格、デバイスのロック解除、またはユーザーの操作を必要とせずに、被害者のデバイスで実行されているマルウェアを使用して、Google同期パスキーで保護されたアカウントを乗っ取ります。Silver Pass-ta-key攻撃: 攻撃者は、被害者が生体認証でデバイスのロックを解除したとGoogle Cloud Authenticatorを誤認させ、認証中に被害者のデバイスを使用せずに完全なアカウント乗っ取りにつながります。Golden Pass-ta-key攻撃: 攻撃者は、共有または認証情報ブラックマーケットで販売可能な形式ですべての同期パスキーを抽出できます。これらの攻撃は、プロバイダーがクラウドオーセンティケーター内の認証情報を保護するためにハードウェアバックアップ保護を追加した場合でも、マルウェアが同期パスキーをどのように悪用できるかを示しています。免責事項: この研究には、責任ある倫理的なセキュリティ分析が含まれていました。提示されたすべてのエクスプロイトを責任を持って開示しました。クラウドオーセンティケーターモデルは、さまざまなブラウザやプラットフォームのさまざまなパスキープロバイダーによって使用されています。ただし、この作業は、Windows上のChromeのGoogleパスワードマネージャー、特にトラステッドプラットフォームモジュール（TPM）を搭載したデバイスに焦点を当てています。提示されたすべての攻撃は、初期段階で被害者のデバイスにマルウェアがすでに存在していることに依存しています。ステージゼロ偵察攻撃を試みる前に、攻撃者は被害者のアカウント内でパスキーがどのように使用されているかを把握する必要があります。侵害されたエンドポイントでは、この可視性は容易に入手できます。Chromeは、同期プロセスの一部として同期パスキーデータをローカルに保存します。Windowsでは、ChromeはChromeの同期データベース内の同期WebAuthn認証情報を表すprotoエンコードされたWebauthnCredentialSpecificsレコードとしてこのデータを永続化します：%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDBこれらのレコードへのアクセスには、特権昇格は必要ありません。これらのレコードにより、攻撃者は被害者がパスキーをどこで使用しているか、関連するユーザー名、認証情報識別子、および暗号化された秘密鍵を列挙できます。被害者がパスキーを使用しているサービスを特定した後、攻撃者は被害者として認証を試みることができます。攻撃者にとっての主な課題は、認証チャレンジに署名するために使用される秘密鍵の保護をバイパスすることです。この秘密鍵はマスターキーによって保護されています。このマスターキーの暗号化されたバージョンは各クライアントデバイスに保存されていますが、それを復号できるのはクラウドオーセンティケーターのみです。このセキュリティにもかかわらず、アーキテクチャは悪用に対して脆弱なままです。以下のセクションでは、攻撃者がシステムメカニズムを悪用し、被害者として認証し、パスキーで保護されたアカウントを侵害するために使用できる方法を詳しく説明します。デバイスIDなりすまし: Pass-Ta-Key攻撃最初の攻撃は最も単純なアプローチであり、GoogleパスワードマネージャーとChromeの正当な認証中の動作を模倣することによって、パスキーで保護されたアカウントを乗っ取ることが含まれます。通常のフローでは、Chromeはデバイスのハードウェアバックアップ鍵で署名されたリクエストをクラウドオーセンティケーターに送信します。ユーザーの操作とデバイスのロック解除を必要とする正当なユーザーフローとは異なり、この攻撃は、ユーザーの同意、生体認証、デバイスのロック解除、または特権昇格なしに、マルウェアがどのように必要な署名をサイレントに取得できるかを示しています。これを理解するために、ChromeのデバイスID鍵に焦点を当てます。これは、クラウドオーセンティケーターに対するクライアントデバイスの所有権を表します。前述のように（パート2: 同期パスキーとデバイス鍵署名によるログイン）、必要なアサーションを生成するには、デバイスのハードウェアバックアップ鍵のいずれかを使用してクラウドオーセンティケーターに送信されたデータに署名する必要があります。これはID鍵またはユーザー検証鍵（UV鍵）です。どちらの鍵もハードウェアにバインドされていますが、アクセス方法は同じではありません。ID鍵の場合、Chromeは、実行中に署名を要求できる条件を作成します。