近年のデジタルID窃取手法とその対策（パスキーとDBSC概説）

近年のデジタルID窃取⼿法とその対策（パスキーとDBSC概説） 2026年3⽉24⽇ ISACA東京⽀部 情報セキュリティ研究会 ⻄村 宗晃（にしむねあ） [email protected]

1. 近年のデジタルID窃取⼿法 1.1. リアルタイムフィッシング 1.2. 情報窃取型マルウェア（インフォスティーラー） 1.3. ここまでのまとめ

1.1. リアルタイムフィッシング 被害者が偽サイトに⼊⼒した認証情報を、リアルタイムに正規サイトへ中継して不正アクセスを試みる⼿法※1。⼆要素⽬の 認証情報（SMSのワンタイムパスコードなど）も誤って⼊⼒してしまうため、従来の⼆要素認証では攻撃を防ぐことが困難 偽サイト (fake.example.jp) 被害者 IDとパスワードを⼊⼒ 正規サイト (genuine.example.jp) 銀⾏ログイン ID nishimune PW ● ● ● ● ● ● 銀⾏ログイン ⼊⼒されたIDとパスワードを中継 ID nishimune PW ● ● ● ● ● ● ワンタイムパスコードを送信 ワンタイムパスコードを⼊⼒ SMSコードを⼊⼒ SMS ⼆要素⽬の認証情報も盗まれる ●●●● ⼊⼒されたワンタイムパスコードを中継 SMSコードを⼊⼒ SMS ⼆要素認証を突破して、不正アクセス ※1 https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed294f1d-9c31-0f06fca67afc/c7edc43c/20260224_resources_standard_guideline_identityverification_1.pdf ●●●●

1.2. 情報窃取型マルウェア（インフォスティーラー） 被害者の端末から情報を密かに収集するように設計されたマルウェア※1。端末に保存されたIDとパスワードなどのログイン情 報に加え、ログイン後に発⾏されるCookieを盗み出すため、⼆要素認証では不正アクセスを防ぎ切ることができない 被害者の端末 Webサーバ オンライン銀⾏ ⼆要素認証でログイン ○○さんのマイページ Cookieを発⾏ 攻撃者 パスワードマネージャにログイン情報を登録 発⾏されたCookieをファイルに保存 感染端末から認証情報を盗む ログイン後に発⾏されるCookieも盗まれる 盗んだ認証情報で不正アクセス ※1 https://www.cyber.gov.au/threats/types-threats/malware/information-stealer-malware

1.3. ここまでのまとめ ⼆要素認証の導⼊のみでは、近年のID窃取攻撃を防ぐことが困難になってきている。 対策には、以下の技術の確⽴が新たに必要となる ① フィッシング耐性を備えたユーザ認証技術 従来のワンタイムパスコードなどに代わる、新たな⼆要素認証⽅式 ② 第三者によるCookieの不正利⽤を防ぐ技術 窃取されたCookieを別の端末で悪⽤できなくする技術

2. 近年のデジタルID窃取⼿法への対策 2.1. パスキー 2.2. DBSC（Device Bound Session Credentials） 2.3. まとめ

2.1. パスキー フィッシング耐性を有する新たな認証技術。利⽤者の端末などに保存した「鍵」を使って認証を⾏う仕組みであり、利⽤者の 所持する「鍵」を利⽤する際には原則として指紋や顔認証、PINなどによる端末のロック解除が求められるため、⼆要素認証と して機能する※1 近年の定義では、FIDO2に準拠した、発⾒可能な認証情報（Discoverable Credential）全般を意味する※2。端末 間で鍵を同期可能な同期パスキーに加え、特定の端末から鍵を取り出すことのできないデバイス固定パスキーが存在する Discoverable Credential 広義には、ユーザー名を⼊⼒しなくても、端末が保存され ている認証情報を⾃動で⾒つけて提⽰してくれる仕組み ※1 https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed294f1d-9c31-0f06fca67afc/c7edc43c/20260224_resources_standard_guideline_identityverification_1.pdf ※2 https://www.w3.org/TR/webauthn-3/#passkey

2.1. パスキー – 認証の流れ パスキーの核となるのは、サーバへ登録した公開鍵によるチャレンジレスポンス認証。現在アクセスしているWebページのドメイン に応じて、 利⽤する「鍵」をWebブラウザが⾃動判別（⼈が判断しない） ユーザ Webブラウザ （FIDO2認証器） 正規サイト (genuine.example.jp) 事前に認証器の鍵ペアを⽣成、公開鍵をサーバに登録（本資料では割愛） 認証を要求 チャレンジ（ランダムな⽂字列） ローカル認証を要求 ローカル認証（⽣体認証など）を実施 レスポンス（秘密鍵で署名したチャレンジ） 正規サイトに事前登録された 公開鍵でレスポンスを署名検証 現在アクセスしているWebページのドメインに応じて 利⽤する「鍵」をWebブラウザが⾃動判別 認証結果（セッションCookieの発⾏など）

2.1. パスキー – リアルタイムフィッシングを防ぐ仕組み 偽サイトでパスキーの認証をした場合、Webブラウザは偽サイトのドメインの「鍵」を⾃動的に使⽤する（⼈が判断しない）。 正規サイトは、偽サイトの「鍵」で⽣成されたレスポンスを署名検証できないため、認証が失敗する Webブラウザ （FIDO2認証器） 被害者 正規サイト (genuine.example.jp) 偽サイト (fake.example.jp) 事前に認証器の鍵ペアを⽣成、公開鍵をサーバに登録（本資料では割愛） 認証を要求 チャレンジ（ランダムな⽂字列） ローカル認証を要求 ローカル認証（⽣体認証など）を実施 レスポンス（偽サイトの秘密鍵で署名したチャレンジ） 偽サイトのドメインの「鍵」が使⽤される 正規サイトに事前登録された 公開鍵でレスポンスを署名検証 「鍵」が⼀致しないので認証が失敗

2.1. パスキー – 考慮事項 実装を気を付けないと⽣んでしまう脆弱性（※詳細は割愛） • 同じチャレンジを使い回せる à XSSなどでレスポンスのデータが窃取された場合、リプレイ攻撃が可能となり、不正アクセスの被害が持続 • 鍵の有効範囲（rpId）のサブドメイン指定が具体的でない（緩い） à サブドメインテイクオーバーなどで他のサブドメインが乗っ取られた場合、攻撃者に鍵を悪⽤される • サーバ側でオリジンを検証していない à 上記のサブドメインの悪⽤と組み合わせることで、正規サイトのサブドメイン経由でリアルタイムフィッシングが可能に パスキーの登録導線の保護 • 当⼈認証⼿法と同等以上の強度の⼿法を選択する（⾝元確認の再実施など）※1 • 事前に集めている以上の情報は⾝元確認に使えない点に注意 パスキーを利⽤していないユーザの保護 • パスキー移⾏前のユーザや、パスキー以外のログイン⽅法が可能なユーザは、引き続きフィッシングにあうリスクあり • パスキー導⼊で不正アクセスを低減できた分の対策リソースで、⾮パスキー利⽤ユーザの保護を⼿厚くする ※1 https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed294f1d-9c31-0f06fca67afc/c7edc43c/20260224_resources_standard_guideline_identityverification_1.pdf

2.2. DBSC – Device Bound Session Credentials 端末とサーバ間のセッションと認証情報を紐づけることで、Cookieが盗まれても、他の端末では使えないようにする仕組み。 セッションの確⽴に使⽤する「鍵」はTPMなどに保存されるため、情報窃取型マルウェアが「鍵」を持ち出すことを阻⽌できる。 現時点ではW3Cの草案段階にあり※1、今年2⽉に公開のWindows版 Chrome 145以降でのみ、正式利⽤が可能※2。 DBSC⾮対応ブラウザでのWebサイトのアクセスに影響を与えないよう、互換性に配慮した技術仕様となっている ※1 https://www.w3.org/TR/dbsc/ ※2 https://developer.chrome.com/blog/dbsc-windows-announcement?hl=ja

2.2. DBSC – 導⼊⽅法 既存のログインフローに、⾚字箇所の処理を追加する。ログイン後に発⾏するCookieを短命なものとし、端末の「鍵」に基づ くセッション上で、頻度⾼くCookieを⾃動更新することにより、結果、Cookieが盗まれても他所で使えないものとなる Webブラウザ （TPM搭載端末） Webサーバ ログイン (1) Secure-Session-Registration ヘッダを送信 従来の Cookie を発⾏ 鍵ペアを⽣成し、DBSC の「登録IF」に公開鍵を送信（⾃動） (2) 公開鍵とセッションを紐づけ管理 (3) セッション識別⼦を送信 (4) 従来のCookieを、有効期限の短い Cookie に上書き DBSC の「更新IF」に Cookie の更新を要求（⾃動） (5) チャレンジを発⾏ Cookieの有効期限が 迫ると⾃動で実施 DBSC の「更新IF」にレスポンスを送信（⾃動） (6) レスポンスを検証 (7) 有効期限の短い Cookie を更新

2.2. DBSC – ⾮対応ブラウザでの動作 DBSCに⾮対応のブラウザでは、Secure-Session-Registrationヘッダが無視されるため、DBSCの「登録IF」や「更新IF」 が呼ばれない形となる。結果、有効期限の⻑い従来のCookieを⽤いて、従来どおり、Webサイトのアクセスが可能となる DBSC⾮対応 Webブラウザ Webサーバ ログイン (1) Secure-Session-Registration ヘッダを送信 従来の Cookie を発⾏ Secure-Session-Registration ヘッダを無視する（⾃動） 従来どおりのWebサイトアクセスが可能

2.2. DBSC – 試してみたい⽅はこちら 怪しいサイトじゃないので⼤丈夫です。 https://csrf.jp/2026/dbsc/

• https://csrf.jp/2026/dbsc/

2.3. まとめ 近年のデジタルID窃取⼿法 • リアルタイムフィッシング • 情報窃取型マルウェア（インフォスティーラー） リアルタイムフィッシングへの耐性を備えたパスキーが普及 • サーバへ登録した「鍵」によるチャレンジレスポンス認証 • そのサイトで利⽤可能な「鍵」をWebブラウザが⾃動判別（⼈が判断しない） • 実装上の脆弱性、パスキーの登録動線の保護、パスキーを利⽤していないユーザの保護は要考慮 情報窃取型マルウェア対策として標準化が進むDBSC • 現時点で正式利⽤できるのはWindows版Chromeのみ • 端末のTPMに保存した「鍵」によるチャレンジレスポンスにより、端末とサーバ間でセッションを確⽴ • ログイン後に発⾏するCookieを短命なものとし、上記セッション上で頻度⾼くCookieを更新する仕組み