Golden Pass-ta-key : 针对Goole 浏览器密码管理器新攻击手段介绍

原创

赛博57库
赛博57库

赛博57库

2026年11月12日 05:00
广东

去阅读

攻防技术 / 威胁情报 一次重注册，偷走全部 Passkey：Golden Pass-ta-key 红蓝对抗 全链路 · SDS 提取 · 凭据复用 · 主机检测 · 事件响应

本文怎么读 Golden Pass-ta-key  既是一个开源项目,也是指从\"内存里抓到 32 字节\" --> \"离线解密全部 Passkey --> 伪造 WebAuthn 断言 --> 完成账号接管的完整攻击链路。 本文第 00 节给结论与影响面；第 01 节拆 Passkey 的三层结构，解释 SDS 为什么必须存在；第 02 节对照 base、Silver、Golden 三级攻击；第 03 节是技术核心——3.4 秒内存窗口、三个 CBOR 模式、HKDF/AES-GCM 解密与断言伪造；第 04 节评估红队/APT 适用性；第 05 节给蓝队检测、狩猎与 72 小时处置；第 06～07 节收束到修复博弈与行动清单。赶时间可直接看第 00 节的表、第 04 节的决策矩阵和第 05 节的规则。

边界与授权 本文只做协议、内存结构、检测与处置层面的拆解，不提供可直接运行的完整 exp、内存扫描器源码或一键脚本。所有测试与命令仅限自有环境或书面授权的目标；文中不含真实受害者、真实凭据或可复用攻击基础设施。Passkey 仍是当前抗钓鱼能力最强的通用认证方式，本文讨论的是「同步与恢复层」的实现风险，不是否定 Passkey 本身。

0x00 · 先给结论：被偷的不是 Passkey，是「恢复权」

2026 年 8 月 3 日，Unit 42 披露了一组针对 Google Password Manager（GPM）同步 Passkey 的攻击，统称 Pass-ta-key。同年 10 月 18～19 日，研究者 0rcruxe 用两篇长文和一份 PoC，把最严重的 Golden Pass-ta-key 从「内存里抓到 32 字节」推进到「离线解密全部 Passkey、伪造 WebAuthn 断言、完成账号接管」的完整链路。

这项研究最容易被误读的地方，是把它当成「Passkey 被破解」。事实相反：WebAuthn 的椭圆曲线签名没有被攻破，TPM 没有被攻破，Chrome 沙箱也没有被逃逸。攻击利用的是一个架构事实——同步 Passkey 必须能在新设备上恢复，而恢复就意味着某个「根密钥」必须在某个时刻离开云端、进入客户端。

这个根密钥叫 SDS（Security Domain Secret，安全域密钥），32 字节，用来加密该 Google 账号下所有同步 Passkey 的私钥。正常设计里，SDS 在磁盘上只以 wrapped_security_domain_secrets 的密文形式存在，只有 Google 的云认证器（Cloud Authenticator）能解开。但在设备加入或重新加入安全域时，Chrome 会从 Google Trusted Vault 取回 SDS 明文，放进进程内存，用来构造发往云认证器的 CBOR 请求。

于是攻击链变成：

删除 passkey_enclave_state ↓ 诱导 Chrome 重新加入安全域 ↓ SDS 明文进入 Chrome 进程内存（约 3.4 秒） ↓ 按 CBOR 语义定位并取出 32 字节 SDS ↓ 读取 Sync Data\\LevelDB 中的 WebauthnCredentialSpecifics ↓ HKDF + AES-256-GCM 解密出 ECDSA P-256 私钥 ↓ 离线伪造 WebAuthn 断言，登录所有绑定 Passkey 的网站

问题	结论
密码学被攻破了吗	没有。攻击利用的是密钥生命周期与恢复流程
攻击者最终拿走什么	32 字节 SDS，以及本地同步 Passkey 的密文记录
影响范围	该 Google 账号下当前与未来的同步 Passkey
需要管理员权限吗	不需要，普通用户上下文即可
需要用户交互吗	需要受害者使用一次 Passkey，触发重新注册
能离线复用吗	能。拿到私钥后不再需要受害设备在线
SDS 能旋转吗	Unit 42 称当前实现无法旋转或吊销；截至本文截稿未见公开轮换接口
有在野利用吗	截至 2026-11-11，未见公开的、可核实的在野利用或 APT 归因报告

最值得注意的是最后两行。不能旋转意味着事件响应不是「改密码、撤会话」就能收尾；没有可核实的在野意味着现在写检测仍然来得及，但也意味着所有 APT 适用性判断都只能是能力评估，不能写成「某组织已经使用」。

0x01 · 把 Passkey 拆成三层：签名仪式、云认证器、同步层

1.1 第一层：WebAuthn 只保证「签名有效」

Passkey 登录时，网站（Relying Party，RP）下发一次性 challenge。认证器用私钥对两段数据签名：

signedData = authenticatorData || SHA256(clientDataJSON)

clientDataJSON 包含 type（webauthn.get / webauthn.create）、challenge、origin；authenticatorData 至少 37 字节：前 32 字节是 SHA256(rp_id)，第 33 字节是 flags，后 4 字节是 signCount。flags 里有四个关键位：

位	值	含义
UP	0x01	用户在场
UV	0x04	用户已验证（生物识别或 PIN）
BE	0x08	凭据可备份
BS	0x10	凭据当前已备份

GPM 同步 Passkey 的典型 flags 是 0x1D = UP + UV + BE + BS。UV 是 RP 唯一能直接依赖的「用户确实解锁了设备」信号；BE/BS 则告诉 RP：这是一枚可同步、可恢复的凭据，不是只存在于某台设备上的硬件密钥。

1.2 第二层：云认证器 enclave.ua5v.com

Chrome 每次使用 GPM Passkey，都会和 enclave.ua5v.com 建立 WebSocket，使用 Noise_NK_P256_AESGCM_SHA256 通道。这个服务就是 Google 的云认证器，负责生成 Passkey 密钥、处理认证请求、在多台设备之间同步凭据。

设备第一次加入安全域时，Chrome 在本机生成一对 TPM 绑定的设备身份密钥（identity key）。Windows 上的做法很特殊：NCryptCreatePersistedKey 不指定 key name，让密钥成为临时密钥；再用 NCryptExportKey 导出为 NCRYPT_OPAQUE_KEY_BLOB，由 TPM 用驻留密钥加密后，存进 passkey_enclave_state 的 wrapped_identity_private_key。私钥不以明文落盘，但同一用户上下文下的进程，只要拿到这个 blob，就可以通过 CNG API 让 TPM 代为签名。

另一把钥匙是 UV key，由 Windows Hello 的生物识别或 PIN 门控。云认证器并不拒绝用 identity key 签名的请求，它只是根据「哪把钥匙签的」决定断言里的 UV 位是 0 还是 1。换句话说，UV 的强制力不在云端，而在 RP 是否真的检查这一位。

1.3 第三层：Trusted Vault 与 SDS

SDS 不直接存在设备上。本地只有 wrapped_security_domain_secrets，是一个 protobuf map：

map<int32, bytes> wrapped_security_domain_secrets = 10;

map 的 key 是 SDS 版本，value 是云认证器包装后的 SDS，只有云认证器能用 Trusted Vault 管理的 wrapping key 解开。正常认证时，SDS 不需要出现在客户端：Chrome 把请求发给云认证器，云认证器在隔离环境里解密 Passkey、完成签名，再把断言返回。

问题出在「加入安全域」这一刻。Chrome 需要从 Trusted Vault 取回 SDS 明文，才能构造 keys/wrap 请求，把 SDS 重新包装后交给云认证器。Unit 42 的解释是：桌面端沿用了移动端的恢复模型——Android 和 iOS 上的 GPM 不依赖云认证器，必须拿到主密钥才能解密同步 Passkey；Chrome 虽然有能力做更隔离的设计，但实际走的是同一条「把 SDS 交给客户端」的路径。

1.4 本地的两个落点

组件	位置	保护方式	普通用户可读？
passkey_enclave_state	%LocalAppData%\\Google\\Chrome\\User Data\\<Profile>\\passkey_enclave_state	无额外 ACL；含 TPM 包装的 identity key 与 wrapped SDS	可读、可删、可改
WebauthnCredentialSpecifics	...\\Sync Data\\LevelDB	私钥用 SDS 派生的 AES-256-GCM 密钥加密	可读密文
SDS 明文	仅 onboarding 时短暂存在于 Chrome 进程内存	依赖进程边界与云认证器协议	同用户进程可读

WebauthnCredentialSpecifics 是 protobuf 记录，字段包括 rp_id、user_name、user_display_name、credential_id、user_id（WebAuthn userHandle）和 encrypted。LevelDB 里的 key 以 webauthn_credential-dt- 开头；用 Google 的 dfindexeddb 解析 .ldb / .log，再用 Chromium 官方的 webauthn_credential_specifics.proto 反序列化，就能枚举出「这个用户在哪些网站用了 Passkey、用户名是什么、credential ID 是什么」。

这里有两个容易忽略的边界。第一，能读到这些记录，不等于能登录：记录里的私钥是密文，真正的门槛是 SDS；Golden 的全部技术价值，就在于把「读密文」变成「拿根密钥」。第二，Profile 目录可能是 Default，也可能是 Profile 1/2...；检测与取证时要按 User Data\\*\\... 枚举，不能只盯 Default。

▲ GPM 的三层结构：WebAuthn 仪式、云认证器、同步与恢复层。SDS 是唯一能解开同步 Passkey 的根密钥，正常只应在云认证器隔离环境内使用。

0x02 · 三级族谱：从「冒用设备」到「拿走总钥匙」

三级攻击的共同前提都是「恶意代码已经在受害者的 Windows 用户上下文里运行」，区别在于各自攻击了哪一个信任假设。

2.1 基础版：冒用设备身份

基础版不碰 SDS。恶意软件从 passkey_enclave_state 或 Chrome 内存里取出 wrapped_identity_private_key，用 CNG API 让 TPM 签名，然后自己完成与云认证器的握手，请求一枚针对目标 RP 的断言。云认证器看到的是「一台已注册的可信设备发来的合法请求」，于是返回断言；断言里的 UV 位是 0，因为签名用的是 identity key。

实战差异完全取决于 RP 是否检查 UV：GitHub 检查了，基础版登录失败；eBay 虽然把 userVerification 设成 required，但没有真正校验 UV 位，攻击成功，Unit 42 报告后已修复。

基础版每次认证都需要受害设备在场：恶意软件必须保持运行，TPM 必须可用。它适合「一次性拿下一个账号」，不适合长期驻留。

2.2 Silver：注册一把攻击者的 UV key

Silver 的目标是绕过 UV。它的做法不是偷 UV key，而是让云认证器接受一把攻击者控制的 UV key。

01  让现有 UV key 失效：删掉 passkey_enclave_state，或者用盗来的 identity key 代受害者发一条 device/forget。Chrome 下一次使用 Passkey 时，会认为设备尚未加入安全域，开始重新 onboarding。

02  在 uv_key_pending 窗口里注册自己的 key：Windows 上，onboarding 要等到第二次使用 Passkey 才真正完成。第一次使用时，Chrome 在后台加入安全域，同时提示用户输入 GPM recovery PIN；此时设备处于 uv_key_pending，Chrome 还没有创建并注册本机 UV key。攻击者在这个窗口里生成一对密钥，用盗来的 identity key 完成签名，向云认证器发送 device/add_uv_key，把自己的公钥注册成该设备的 UV key。

关键缺陷是：云认证器不校验新注册 UV key 的 attestation，不验证它是否来自安全硬件。于是云端设备记录变成：

devices[device_id] = { hw: identity_public_key, uv: attacker_controlled_uv_public_key }

从那以后，攻击者用自己持有的 UV 私钥签名，就能拿到 UV=1 的断言，而且不再需要受害设备在线。改密码、撤销会话通常无效；只有注销设备或重新注册设备，才可能把这把伪造 UV key 清掉——它挂在「设备」这个身份上，而不是「会话」上。

2.3 Golden：拿走 SDS

Golden 和 Silver 共用同一个触发动作：让设备重新加入安全域。区别在于 Golden 不等 UV key 窗口，而是盯着 SDS 进入内存的那几秒。

拿到 SDS 后，攻击者可以在本地解密 WebauthnCredentialSpecifics 里的全部私钥。每个私钥都是完整的 ECDSA P-256 私钥，签出来的断言和受害者本人在 Chrome 里签的没有区别：UV=1、BE=1、BS=1、签名有效、origin 正确。

更严重的是「未来」：新建的同步 Passkey 仍然用同一个 SDS 加密。攻击者不需要再次入侵，只要 SDS 不变，受害者以后新增的 Passkey 也会被同一把钥匙解开。Unit 42 的结论是，Google 当前实现没有旋转或吊销 SDS 的接口；这意味着 Golden 的持久性不是「一次会话」，而是「这个安全域的生命周期」。

攻击	核心动作	关键前提	过 UV	需在线	持久性
base	用 identity key 签名，向云认证器要断言	代码执行 + 读 state	否（UV=0）	每次都要	低
Silver	强制重注册，device/add_uv_key 注册攻击者 UV key	代码执行 + 触发 onboarding	是（伪造 UV=1）	注册后不需要	中高
Golden	在重注册窗口提取 SDS，离线解密全部 Passkey	同上 + 捕获内存窗口	是（真实私钥）	不需要	最高

2.4 为什么叫「Golden」

这个名字借的是 Golden Ticket 的语义：攻击者拿到的不是某一次登录机会，而是一个能生成「合法身份」的根密钥。

维度	Golden Ticket（KRBTGT）	Golden Pass-ta-key（SDS）
根密钥	KRBTGT 的密钥材料	32 字节 SDS
影响范围	域内所有依赖 Kerberos 的服务	该 Google 账号下所有同步 Passkey
能否旋转	可以重置 KRBTGT（通常两次）	公开资料未见旋转接口
使用方式	伪造 TGT，在线/离线使用	离线解密私钥，伪造 WebAuthn 断言
主要检测面	KDC 事件、票据异常、PAC	主机侧文件/内存；RP 侧几乎不可见

两者有一个重要差别：KRBTGT 的滥用通常发生在域内，检测者拥有 KDC 和终端的完整日志；SDS 的滥用发生在别人的浏览器和别人的账号之间，RP 只看到一次「合法的 Passkey 登录」。这决定了蓝队的重心必须前移到主机侧。

0x03 · Golden 全链路：3.4 秒里的三个瞬间

3.1 触发：删掉一个没有 ACL 保护的文件

passkey_enclave_state 是 Chrome 判断「本机是否已加入安全域」的本地状态，没有额外访问控制，普通用户进程可以删除。删除之后，Chrome 视角里的设备就「不在域内」了；下一次使用或创建 Passkey 时，Chrome 会重新走 onboarding：

01  从 Trusted Vault 取回 SDS 明文；

02  连接 enclave.ua5v.com；

03  构造 keys/wrap 请求，把 SDS 重新包装后交给云认证器；

04  用云认证器返回的结果更新 passkey_enclave_state，写入新的 wrapped_security_domain_secrets，并把 joined 置为 true。

Windows 上还要多一步：第一次使用 Passkey 时，Chrome 提示用户输入 GPM recovery PIN；真正的 UV key 创建和注册被推迟到第二次使用，以避免连续两个 PIN 提示。这个体验设计给攻击者留出了 uv_key_pending 窗口。注意：攻击者不需要知道 recovery PIN；它只需要用户完成这次提示，SDS 就会进入 Chrome 内存。

对攻击者来说，触发不是「完全自动」的：必须有用户使用一次 Passkey。这是 Golden 在 APT 场景里最重要的节奏约束——它可以等，但不能凭空产生一次 Passkey 操作。在授权红队作业中，常见做法是结合社工、会议邀请、内部系统登录诱导，或者长期潜伏，等用户自己触发。

3.2 时间线：SDS 只活 3.4 秒

0rcruxe 的 PoC 在带 TPM 的 Windows 机器上测得了完整时间线：

时间	事件
T+0	Chrome 与 enclave.ua5v.com 建立 TCP 连接
T+78ms	SDS 第一次出现在堆/Windows 临时缓冲区
T+1109ms	keys/wrap CBOR 请求中出现 SDS 明文，生命周期约 125ms
T+3062ms	passkeys/assert （或 passkeys/create）中出现 SDS 明文，约 203ms
T+3.4s	内存中所有 SDS 副本释放
T+4.5～6.5s	Chrome 用解密出的私钥签好断言，发给 RP

三个 CBOR 缓冲区加起来只暴露约 330ms，散布在约 2.2 秒的窗口里；加上堆上的临时副本，SDS 在进程内存里的总寿命约 3.4 秒。这解释了为什么攻击不是「随手 dump 一下内存」：盲目扫描会撞上大量高熵数据、Windows 堆填充模式和别的密钥，必须在正确的时间、正确的内存区域、按正确的结构去找。

3.3 定位：为什么不能靠熵，要靠 CBOR 语义

Chrome 进程里有 1100 多个 MEM_PRIVATE + PAGE_READWRITE 区域，里面混着 Windows 堆填充模式（0xCDCDCDCD、0xBAADF00D）、其他高熵密钥、随机数、TLS 会话材料、各种 protobuf/CBOR 缓冲区。仅靠 Shannon 熵、唯一字节比例、可打印字符比例，无法稳定区分 SDS 和别的 32 字节随机值。

PoC 的关键改进是：不找「像密钥的 32 字节」，而是找「包含 SDS 的 CBOR 结构」。扫描内存中的 CBOR 模式，命中后按结构解析出 secret / key 字段，再取紧随其后的 32 字节。这样误报率远低于随机搜索，也不需要预先知道 SDS 的值。

3.4 三个通用 CBOR 模式

三个模式分别对应 onboarding、认证、创建 Passkey，都以 81（单元素数组）开头，后接 a3 或 a5（3 或 5 个 key 的 map）。

模式一：keys/wrap（onboarding）

81 a3 63 63 6d 64 69 6b 65 79 73 2f 77 72 61 70 63 6b 65 79 58 20 [SDS 32 bytes] 67 70 75 72 70 6f 73 65 76 73 65 63 75 72 69 74 79 20 64 6f 6d 61 69 6e 20 73 65 63 72 65 74

{\"cmd\": \"keys/wrap\", \"key\": \"<SDS>\", \"purpose\": \"security domain secret\"}

模式二：passkeys/assert（使用 Passkey）

81 a5 63 63 6d 64 6f 70 61 73 73 6b 65 79 73 2f 61 73 73 65 72 74 66 73 65 63 72 65 74 58 20 [SDS 32 bytes] 67 72 65 71 75 65 73 74 a1 64 72 70 49 64

{\"cmd\": \"passkeys/assert\", \"secret\": \"<SDS>\", \"request\": {\"rpId\": \"<domain>\"}}

模式三：passkeys/create（创建 Passkey）

81 a5 63 63 6d 64 6f 70 61 73 73 6b 65 79 73 2f 63 72 65 61 74 65 66 73 65 63 72 65 74 58 20 [SDS 32 bytes] 67 72 65 71 75 65 73 74 a3 62 72 70 a2 62 69 64

{\"cmd\": \"passkeys/create\", \"secret\": \"<SDS>\", \"request\": {\"rp\": {\"id\": \"<domain>\", \"name\": \"<domain>\"}}}

58 20 是「32 字节的 byte string」，紧跟其后的 32 字节就是 SDS；63 / 67 / 6f 是 CBOR 的 text 长度标记，a1 / a3 / a5 是 map 的元素个数。攻击者不需要理解整个协议，只要认出这三个「语义骨架」，就能在 125～203ms 的窗口里把 SDS 抠出来。

3.5 离线解密：HKDF 与 AES-GCM 的参数

拿到 SDS 之后，解密链是纯本地的：

01  取记录：用 dfindexeddb 解析 Sync Data\\LevelDB，过滤 webauthn_credential-dt- 前缀，按 webauthn_credential_specifics.proto 反序列化。

02  派生密钥：对 SDS 做 HKDF-SHA256，salt 为空，info 为固定字符串 KeychainApplicationKey:gmscore_module:com.google.android.gms.fido，输出 32 字节 AES-256 密钥。

03  解密：AES-256-GCM，nonce 12 字节，AAD 为 WebauthnCredentialSpecifics.Encrypted。

04  解析明文：encrypted blob 的布局是 nonce(12) || ciphertext(175) || tag(16)，共 203 字节；175 字节明文是 protobuf Encrypted 消息，其中 private_key 字段是 138 字节的 PKCS#8 ECDSA P-256 私钥。

05  导出：私钥可转 DER 或 PEM，PEM 可直接喂给 Passkey Injector 之类的工具。

SDS 不是直接当 AES key 用，而是先经 HKDF 派生；被加密的也不只是裸私钥，而是带 protobuf 包装的 Encrypted 消息。这两个细节决定了「拿到 SDS 之后还要写对代码」——但对有 Chromium 源码的防守方来说，这也意味着可以写检测/取证工具。

▲ SDS 的密码链路：SDS → HKDF-SHA256 → AES-256-GCM → protobuf Encrypted → PKCS#8 私钥 → WebAuthn 断言。

3.6 伪造断言：UV=1 是怎么来的

有了私钥，伪造断言就是标准的 WebAuthn 签名：

01  构造 clientDataJSON：

{\"type\":\"webauthn.get\",\"challenge\":\"<RP 下发的 challenge>\",\"origin\":\"https://<rp_id>\",\"crossOrigin\":false}

01  构造 authenticatorData：

SHA256(rp_id) || 0x1D || signCount(4 bytes, big-endian)

01  计算 signedData = authenticatorData || SHA256(clientDataJSON)；

02  用 ECDSA P-256 + SHA-256 签名，得到 DER 编码的签名；

03  把 credentialId、authenticatorData、signature、userHandle、clientDataJSON 全部 base64url 编码，组装成断言 JSON。

这里的 0x1D 是重点：它告诉 RP「用户在场、用户已验证、凭据可备份、凭据已备份」。因为签名用的是真实的受害者私钥，这个 UV=1 不是伪造的标志位，而是「用一把真实 Passkey 私钥签出来的、语义上完全合法的断言」。RP 没有任何密码学理由拒绝它。

最后一步是把断言注入浏览器的 WebAuthn 流程。SpecterOps 的 Passkey Injector 基于 Edge WebView2 构造浏览器，拦截 navigator.credentials.get()，把预先算好的断言注入回去。它需要一个 .passkey 文件，包含 credentialId、PEM 私钥、relyingParty、url、userHandle、username。这套工具在 Black Hat USA 2026 的「Pass the Passkey Family of Attacks」中公开，说明「提取」和「复用」两半都已经工具化。

▲ 3.4 秒窗口里的三个 CBOR 瞬间：keys/wrap 约 125ms，passkeys/assert 约 203ms；语义定位比熵扫描可靠。

3.7 为什么 TPM 挡不住

TPM 保护的是设备身份私钥，以及 UV key 的使用条件。它确保「设备私钥不能直接导出」「UV key 的使用要经过 Windows Hello」。这些保护在 Golden 面前都没有失效——攻击者根本没有从 TPM 里导出任何东西。

攻击利用的是：Chrome 合法地启动恢复流程；Google 合法地把 SDS 交给 Chrome；SDS 在普通进程地址空间里变成明文；同用户的恶意进程读取这段内存。问题发生在 TPM 的安全边界之外。用一句不太严谨但很直观的话说：TPM 守住了一把钥匙，但应用程序在使用另一把更重要的钥匙时，把它放到了桌面上。

版本与披露边界 0rcruxe 的 PoC 在 Chrome Stable 156、Beta 156、Dev 158、Canary 158 上验证；作者认为这是架构问题，因此「所有版本受影响」。这是研究者的判断，不等于 Google 已公开确认所有版本。日志泄漏路径（chrome://device-log 中的 SDS 明文）已被 Google 修复，并分配了 CVE-2025-12910；但内存暴露路径在 2026-10 的 PoC 中仍然可用，第二次报告（issuetracker 464305542）没有拿到 CVE。Google 的公开立场是「本地恶意软件已意味着设备被攻陷」，属于 threat model 之外；但 Chrome 同时在做 App-Bound Encryption 防浏览器凭据窃取，这种「一边防本地恶意软件、一边说本地恶意软件不在模型内」的不一致，正是争议所在。

0x04 · 红队/APT 适用性：高价值，但前提很窄

4.1 前提清单

类型	条件	不满足会怎样
硬前提	Windows 10/11 + TPM 2.0	没有 TPM，identity key 机制不成立
硬前提	Chrome + GPM 同步 Passkey 已启用	关闭同步或不用 GPM，SDS 不存在
硬前提	至少一枚同步 Passkey	没有可解密的记录，攻击无收益
硬前提	以受害者用户身份执行代码	需要读 Profile、打开 chrome.exe 进程
硬前提	用户使用一次 Passkey	不触发 onboarding，SDS 不进内存
软前提	Chrome 正在运行、Profile 未锁	影响内存扫描与 LevelDB 读取
软前提	目标账号有高价值 SaaS	决定「值不值得等」
软前提	主机遥测薄弱	决定「会不会被抓」

最容易被低估的是「用户使用一次 Passkey」。很多红队项目拿到主机权限后习惯「全自动收集」，但 Golden 不是全自动的：它需要一个业务动作。这更适合长周期驻留的 APT，而不是追求「一小时内出结果」的红队冲刺。

4.2 在 kill chain 里的位置

按 ATT&CK 映射，Golden 主要落在三个点：Credential Access / T1555.003（从浏览器凭据存储获取凭据）、Use Alternate Authentication Material / T1550（用窃取的私钥伪造认证材料）、Account Manipulation / T1098.005（Silver 更典型：向云端注册攻击者控制的设备/密钥）。

初始访问（钓鱼/暴露面） → 用户态 implant → 发现：读取 Sync Data\\LevelDB，枚举 rp_id / user_name → 凭据访问：删 state，等用户用一次 Passkey → 提取：扫 Chrome 内存拿 SDS → 离线：解密私钥，导出 .passkey → 横向：登录 GitHub / 云控制台 / 交易所等绑定 Passkey 的账号 → 持久化：SDS 覆盖未来 Passkey；Silver 还可留下攻击者 UV key

这里的「横向」不是传统的 SMB/WMI 横向，而是向云身份横向。对红队来说，这往往比拿一台内网主机更值钱：一个 GitHub 组织 owner 的 Passkey，可能直接通向代码仓库、CI/CD 和云资源。

4.3 相对优势：为什么它比 LSASS/cookie/钓鱼更划算

路径	管理员	需实时在线	过 UV	复用性与噪声
LSASS dump	通常需要	是	不适用	中；噪声高
Cookie 窃取	否	会话有效期内	可能被 App-Bound Encryption 拦	低～中；噪声中
钓鱼/实时中继	否	是（用户在场）	取决于实现	低；噪声中
Golden Pass-ta-key	否	否（提取后可离线）	是（真实私钥）	高（当前+未来）；噪声低～中

核心优势是「把一次性的会话凭据，升级成长期的身份根密钥」。Cookie 会过期，密码会轮换，会话会被撤销；SDS 不会。对于以「长期访问高价值 SaaS」为目标的 APT，这种属性非常有吸引力。

4.4 OPSEC 与暴露面

步骤	主机痕迹	网络痕迹	账号痕迹	检测难度
枚举 LevelDB	文件读（需 SACL/EDR 文件遥测）	无	无	中
删除 state	文件删除（Sysmon 23/26）	无	无	低
触发 onboarding	Chrome 连 enclave；GPM recovery PIN 提示	DNS/TCP 到 enclave.ua5v.com	设备注册（Google 侧）	中
扫描内存	打开 chrome.exe 句柄 + 读内存（EDR）	无	无	中～高
外带 LevelDB	压缩/上传	C2 流量	无	中
离线复用	无（攻击者环境）	攻击者 IP 到 RP	新 IP/设备/地理	高（RP 侧几乎不可见）

最响的一步是「删除 state」和「打开 chrome.exe 读内存」。这两步在 Sysmon 10/23/26 里都能留下事件；如果目标有成熟的 EDR，攻击者需要额外的规避（注入、白利用、降低扫描频率），成本会显著上升。

4.5 三类使用者：APT、红队、黑产

APT（能力评估，不是已发生）

适合的目标画像：使用个人 Google 账号 + GPM 同步 Passkey 的开发者、运维、管理员；账号绑定 GitHub、云控制台、代码托管、加密货币交易所。APT 的优势是「长驻留 + 等得起」：可以等用户某天使用一次 Passkey，再触发 onboarding。低噪声、无 LSASS、无管理员，符合长期潜伏的偏好。

但 APT 的适用性有三个硬边界：GPM 是消费者同步体系，不是企业 Entra ID / Windows Hello for Business 的设备绑定凭据；需要用户触发，不是零点击；没有公开的、可核实的在野样本，把它写成「某 APT 已使用」是不严谨的。

红队

适合 assume-breach 场景：已经拿到用户态权限，目标是「证明能绕过 MFA 拿到 SaaS」。使用前应确认：授权范围包含凭据访问与账号接管；允许触发用户交互（GPM recovery PIN 会打扰用户）；与蓝队约定检测对抗的边界；数据最小化，测试结束清理 .passkey 与解密出的私钥；报告中区分「能力证明」与「真实凭据泄露」。

黑产 / 初始访问经纪

Unit 42 明确写到，Golden 让 Passkey 变得「可以被共享或出售」。这改变了凭据市场的商品结构：过去卖的是密码、cookie、会话令牌；现在可以卖「某个账号的 Passkey 私钥 + SDS」。

但这里有一个市场信任问题：SDS 可以被复制、且不能旋转。卖家即使把 SDS 和 LevelDB 卖给买家，自己仍然保留一份，未来还能继续解密该账号新增的 Passkey；买家无法验证「卖家是否删除了副本」。这不是技术漏洞，而是根密钥不可旋转带来的经济后果。对防守方来说，「Passkey 泄露」不能按「一次性泄露」定价，而要按「长期根密钥泄露」处置。

推断边界 上述黑产分析是基于 Unit 42 的「可共享/出售」判断做的推演；截至本文截稿，没有公开的 Passkey 交易样本、报价或中间人案例。文章不把推演写成事实。

4.6 决策矩阵：什么时候用，什么时候不用

场景	建议	理由
目标用 GPM 同步 Passkey，RP 只要求 UV 但不校验	基础版即可	成本最低，不需要 SDS
目标 RP 严格校验 UV，但可接受一次重注册打扰	Silver	注册攻击者 UV key，后续跨设备
目标高价值、需要离线/未来访问、可长期等待	Golden	一次 SDS，覆盖当前与未来
目标使用硬件安全密钥 / device-bound Passkey	不适用	没有 SDS，私钥不出设备
目标关闭 GPM 同步 / 不用 Chrome	不适用	没有 SDS 与 LevelDB 记录
目标 EDR 成熟、禁止用户交互	谨慎/放弃	删 state、读内存、PIN 提示都可能暴露
授权范围不含凭据访问	禁止	合规红线

4.7 它不做什么

•  不破解 WebAuthn：签名仍然有效，RP 的密码学验证仍然通过；

•  不破解 TPM：不导出设备私钥，只利用合法签名能力；

•  不等于硬件密钥失守：FIDO2 硬件密钥、device-bound Passkey 没有 SDS；

•  不是所有 Passkey 提供商：研究聚焦 GPM + Chrome + Windows + TPM；其他云同步实现可能有类似模型，但没有公开验证；

•  不是零点击：需要用户使用一次 Passkey；

•  不是远程-only：初始阶段需要主机上的用户态代码；

•  不是永久无解：如果 Google 改变客户端架构、引入 SDS 轮换或 attestation，攻击面会变化。

这套链路的适用范围是 GPM 同步 Passkey。Bitwarden、1Password、KeePassXC 等第三方管理器的同步 Passkey 有各自的加密与解锁模型，不能直接套用；Windows Hello / Entra ID 的 device-bound 凭据没有 SDS。SpecterOps 的注入工具可以复用任何来源的私钥，但「取私钥」这一步因管理器而异。

0x05 · 蓝队对抗：检测模型检测三个攻击瞬间，与三层检测与抵制防线

5.1 检测模型：把攻击拆成三个瞬间

Golden 的检测不应该从「找恶意文件」开始，而应该从「找三个瞬间」开始：

01  准备：非 Chrome 进程读取 Sync Data\\LevelDB，枚举 Passkey；

02  触发：passkey_enclave_state 被非 Chrome 进程删除/重建，随后 Chrome 连接 enclave.ua5v.com；

03  提取/外带：非 Chrome 进程打开 chrome.exe 并请求内存读权限；或 LevelDB 被复制、压缩、上传。

单个信号都可能有正常解释；两到三个信号在 10 分钟内同时出现，才是高置信度的 Golden 线索。

▲ 红队 kill chain 与蓝队检测面的对应关系：准备、触发、提取/外带三段，每段都依赖不同的遥测。

5.2 遥测矩阵

信号	遥测	字段	前提与缺口
删除 state	Sysmon 23/26	TargetFilename 、Image	需开文件删除审计；注入 Chrome 后由 chrome.exe 删除则绕过
重建 state	Sysmon 11	TargetFilename 、Image	常见；正常重注册也会发生
读 chrome 内存	Sysmon 10 / EDR	SourceImage 、GrantedAccess	需开进程访问审计；Sysmon 只记句柄，不记每次读
读 LevelDB	SACL 4656/4663 / EDR	ProcessName 、ObjectName、AccessMask	需定向 SACL；默认不开文件系统审计
连 enclave	Sysmon 22/3	QueryName 、DestinationIp	需开网络/DNS 审计；正常 Passkey 也会连
用户提示	服务台/举报	GPM recovery PIN 异常	依赖人；不及时、易漏
账号异常	IdP/RP 日志	新 IP/ASN/设备、时间	依赖 RP 日志；Golden 可能模仿正常登录

5.3 规则：三条 Sigma、一条 SPL、一条 KQL

规则一：非浏览器进程以内存读权限打开 chrome.exe

title: 非浏览器进程以内存读权限打开 chrome.exe id: 7b3c1f9a-2d4e-4a6b-9c8d-1e2f3a4b5c6d status: experimental description: 检测非浏览器进程打开 chrome.exe 并请求内存读权限，符合 Pass-ta-key 家族提取 identity key / SDS 的行为。 logsource: category: process_access product: windows detection: selection: TargetImage|endswith: '\\chrome.exe' GrantedAccess: - '0x1010' - '0x1410' - '0x1038' - '0x0410' - '0x1F0FFF' filter_browser: SourceImage|endswith: - '\\chrome.exe' - '\\msedge.exe' condition: selection and not filter_browser falsepositives: - EDR/AV 自身 - 调试器、辅助功能工具 - 备份/迁移软件 level: high tags: - attack.t1555.003 - attack.t1550

GrantedAccess 的值在不同 EDR 里可能被归一化，部署前先用一周基线确认本环境 Chrome 的正常访问者。0x1010 是 PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ，0x1410 再多一个 PROCESS_QUERY_INFORMATION，0x1F0FFF 是全权限；恶意工具可能用其中任意一个。

规则二：非 Chrome 进程删除 passkey\_enclave\_state

title: 非 Chrome 进程删除 passkey_enclave_state id: 4d6b8e2f-73a1-4c5d-8e9f-1b3c5d7e9f2a status: experimental description: 检测 Silver/Golden Pass-ta-key 强制重新注册前的状态文件删除。 logsource: category: file_delete product: windows detection: selection: TargetFilename|endswith: '\\passkey_enclave_state' filter_chrome: Image|endswith: '\\chrome.exe' condition: selection and not filter_chrome falsepositives: - 备份/同步软件触碰 Chrome Profile - 用户手动清理/迁移 Profile level: high tags: - attack.t1555.003 - attack.t1098.005

这条规则的关键不是「删除」本身——Chrome 自己也会在重注册时删除/重建——而是「非 chrome.exe 删除」。如果攻击者注入 Chrome 后借 chrome.exe 之手删除，这条会失效，需要靠规则一和网络关联补位。

规则三：非 Chrome 进程读取 Sync Data LevelDB（需 SACL）

title: 非 Chrome 进程读取 Chrome Sync Data LevelDB id: 9a1d3c5e-6f7b-4a2c-8d1e-3b5c7a9d1f2e status: experimental description: 通过 4663 对象访问审计检测 Passkey 枚举（Stage Zero）。 logsource: product: windows service: security detection: selection: EventID: 4663 ObjectName|contains: '\\Sync Data\\LevelDB' AccessMask: '0x1' filter_chrome: ProcessName|endswith: '\\chrome.exe' condition: selection and not filter_chrome falsepositives: - 备份软件、取证工具、Profile 迁移 level: medium tags: - attack.t1555.003

这条规则需要只对 LevelDB 目录配置 SACL（ReadData/ListDirectory），不要全局开启文件系统审计，否则噪声会淹没信号。

SPL：三信号关联狩猎

index=sysmon earliest=-10m@m (EventCode=10 OR EventCode=22 OR EventCode=23 OR EventCode=26) | eval sig=case( EventCode=10 AND like(TargetImage,\"%\\\\chrome.exe\") AND NOT like(SourceImage,\"%\\\\chrome.exe\"), \"mem_access\", (EventCode=23 OR EventCode=26) AND like(TargetFilename,\"%\\\\passkey_enclave_state\"), \"state_delete\", EventCode=22 AND lower(QueryName)==\"enclave.ua5v.com\", \"enclave_dns\") | where isnotnull(sig) | stats dc(sig) as sig_count values(sig) as sigs by Computer | where sig_count>=2

KQL：Sentinel / Sysmon 版本

Event | where Source == \"Microsoft-Windows-Sysmon\" | where EventID in (10, 22, 23, 26) | extend TargetImage = tostring(EventData.TargetImage), SourceImage = tostring(EventData.SourceImage), TargetFilename = tostring(EventData.TargetFilename), QueryName = tolower(tostring(EventData.QueryName)) | extend Sig = case( EventID == 10 and TargetImage endswith @\"\\chrome.exe\" and SourceImage !endswith @\"\\chrome.exe\", \"mem_access\", EventID in (23, 26) and TargetFilename endswith @\"\\passkey_enclave_state\", \"state_delete\", EventID == 22 and QueryName == \"enclave.ua5v.com\", \"enclave_dns\", \"\") | where Sig != \"\" | summarize SigCount=dcount(Sig), Sigs=make_set(Sig) by Computer, bin(TimeGenerated, 10m) | where SigCount >= 2

如果使用 Defender XDR 原生 DeviceEvents，字段名和 ActionType 会因传感器版本不同；先用 DeviceEvents | distinct ActionType 校准，再映射逻辑，不要直接照抄表名。

5.4 误报与基线

误报主要来自四类：EDR/AV 自身（打开 Chrome 进程做扫描）、调试器/辅助功能工具、备份/迁移软件（读取 Profile、复制 LevelDB、触碰 state）、正常重注册（换机、重置 GPM、Chrome 更新后重新加入安全域）。

降噪思路：

01  按签名/哈希白名单，不要按路径白名单（Program Files 里也可能有被利用的二进制）；

02  用 2-of-3 关联，不要单信号告警；

03  先 shadow mode 跑 1～2 周，记录基线，再升级为告警；

04  区分「谁删的」：chrome.exe 删除 state 是正常流程，非 chrome.exe 删除才是信号；

05  把用户举报纳入流程：GPM recovery PIN 异常提示是低成本、高价值的信号。

5.5 72 小时处置

0～2 小时：保全

# 先抓内存，再重启/隔离（重启会丢 SDS 窗口与进程证据） procdump64.exe -accepteula -ma <chrome_pid> chrome.dmp # 保存状态文件与 LevelDB $p = \"$env:LOCALAPPDATA\\Google\\Chrome\\User Data\\Default\" Copy-Item \"$p\\passkey_enclave_state\" .\\evidence\\ -ErrorAction SilentlyContinue Copy-Item \"$p\\Sync Data\\LevelDB\" .\\evidence\\LevelDB -Recurse

同时记录 Chrome 版本、Profile 路径、GPM 账号、EDR 时间线、用户是否看到 recovery PIN 提示。

2～24 小时：定损

•  用 dfindexeddb + webauthn_credential_specifics.proto 解析 LevelDB，列出 rp_id、user_name、credential_id；

•  假设该账号下所有同步 Passkey 都已泄露，不要只处理「最近登录过」的几个；

•  通知对应 RP/身份团队，删除或吊销相关 credential；

•  撤销会话、刷新令牌、检查 OAuth 授权与新增设备；

•  监控异常登录：新 ASN、新地理、短时间多 RP 连续登录。

24～72 小时：重置

•  与 Google/企业管理员确认安全域重置能力；仅删除单个 Passkey 不够，因为 SDS 仍能解密后续新建的 Passkey；

•  高价值账号改用硬件安全密钥或 device-bound Passkey，重新注册；

•  复盘：state 删除时间、enclave 连接时间、chrome 内存访问时间、LevelDB 读取时间，拼成完整时间线；

•  更新检测规则与白名单，补上本次暴露的遥测缺口。

优先级	动作	证据/备注
P0	内存镜像、state/LevelDB 保全	SDS 窗口短，先保全再重启
P0	假设全部 Passkey 泄露	SDS 覆盖当前+未来
P1	RP 侧删除 credential、撤销会话	与身份团队/RP 协同
P1	监控新设备注册、异常地理/ASN	Golden 的登录可能「看起来正常」
P2	安全域重置、硬件密钥重注册	需 Google/管理员配合
P2	检测规则与遥测补盲	把本次事件转成规则

5.6 架构缓解：把「根密钥」从客户端拿走

个人用户

•  高价值账号（邮箱、代码托管、云、交易所）优先用硬件安全密钥，或至少使用 device-bound 的平台认证器；

•  正常使用中突然要求输入 GPM recovery PIN、重新注册设备，要提高警惕；

•  保持 Chrome/Windows 更新，但不要把更新当成 Golden 的解药——它修的是日志，不是架构。

企业身份管理员

•  盘点哪些员工在用 GPM 同步 Passkey 访问企业 SaaS；对高权限组，要求硬件密钥/device-bound；

•  对特权账号，考虑关闭 GPM 同步（SyncDisabled、PasswordManagerEnabled 是钝器，会影响体验，需分组试点）；

•  把「异常重注册」「新设备注册」纳入身份监控；

•  做一次桌面演练：如果某个开发者的 GitHub Passkey 被离线复制，现有检测能不能在 24 小时内发现？

RP / 身份开发者

•  userVerification = required 并真正校验 UV 位；这能挡住基础版，但挡不住 Golden；

•  注册时要求 attestation，按 AAGUID 允许列表限制高保障账号的认证器类型；

•  把 BE=1 的同步 Passkey 视为「较低保障」，对敏感操作做 step-up（硬件密钥/人工复核）；

•  不要依赖 signCount：同步 Passkey 常见常量计数，Unit 42 也指出跨设备一致计数很难实现；

•  记录设备指纹、地理、ASN、登录节奏，用行为风控补密码学看不到的缺口。

5.7 检测边界：RP 侧为什么基本看不见

Golden 的断言在 RP 看来是：签名有效、rpIdHash 正确、origin 正确、UV=1、BE=1、BS=1、signCount 可能是常量。它和受害者本人在 Chrome 里登录没有可区分的密码学特征。RP 能用的只剩行为信号：新 IP、新 ASN、异常时间、短时间多账号、登录后的敏感操作。这些信号有价值，但不能承诺「RP 能检测 Golden」。

真正可靠的拦截点在主机侧：谁读了 LevelDB？谁删了 state？谁在 Chrome 连 enclave 的同一时间打开了 chrome.exe 的内存？谁把 LevelDB 打包上传了？如果这些遥测都没有，防守方只剩「用户举报 + 账号行为风控」，这是不够的。

0x06 · 修复博弈：日志脱敏不是修复

•  2025 年 7 月，研究者报告 SDS 出现在 Chrome 日志中；Google 24 小时内修复，并分配 CVE-2025-12910。

•  2025 年 11 月，Unit 42 的研究者报告「同一个泄漏、另一个字段」；Google 再次修复，但拒绝分配 CVE，理由是「本地物理攻击不在 threat model 内」。

•  据 0rcruxe 的梳理，同一讨论串里，一位 Google 工程师先用 threat model 关闭报告，另一位工程师随即表示「这是疏忽，SDS 很敏感，我们应该把它从日志里拿掉」，然后 24 小时内打了补丁；2025 年 12 月，Google 又回到第一份报告，补充「这不在 threat model 内，不应被归类为漏洞」。

这段历史说明：补丁和 CVE 是两件事。Google 修了日志，但没有改变「SDS 会进入客户端内存」的架构；只要 Chrome 还需要在本地构造 keys/wrap、passkeys/assert、passkeys/create 请求，SDS 就必须以明文形式存在于某个进程内存里。这不是实现疏忽，而是「客户端要使用密钥，密钥就必须在客户端可用」的密码学约束。

Unit 42 的架构建议是：让云认证器代表客户端完成加解密，不把根密钥交给客户端；对新增 UV/identity key 做 attestation 校验；加固恢复与重注册流程；限制本地 Passkey 数据访问；改进异常 Passkey 使用检测（包括协调化的 signCount）。第 1 条是根治，其余是缓解。

对使用云同步 Passkey 的其他厂商来说，Unit 42 的模型分析同样适用：只要「跨设备可恢复」意味着「某个根密钥必须在某个时刻交给客户端」，同类风险就存在。但具体实现是否可被同样利用，需要单独验证，本文不点名未验证的厂商。

接下来值得关注的信号：Google 是否引入 SDS 轮换/吊销，或把加解密完全移回云端；Chrome 是否对 passkey_enclave_state 加 ACL、对内存中的 SDS 做隔离/加密；是否有新的 CVE 或 VRP 报告把「内存暴露」正式纳入漏洞；是否有 APT/黑产样本开始集成 SDS 提取模块；RP 侧是否开始普遍校验 UV、attestation 和 BE/BS。

0x07 · 收尾：四张清单

个人用户

•  高价值账号改用硬件安全密钥；不要把「用了 Passkey」当成「中了木马也安全」；

•  遇到意外的 GPM recovery PIN/重新注册提示，先停下来排查；

•  保持更新，但知道更新不等于架构修复。

企业身份管理员

•  盘点 GPM 同步 Passkey 的使用面，区分高权限/普通员工；

•  高权限组改用 device-bound/硬件密钥，必要时关闭 GPM 同步；

•  把「异常重注册 + 新设备注册 + 异常地理」做成关联告警；

•  做一次「Passkey 被离线复制」的桌面演练。

红队

•  先核对前提，不要在不满足 TPM/GPM/用户触发的目标上浪费时间；

•  把「用户使用一次 Passkey」写进作业计划，不要假设全自动；

•  授权、协调、数据最小化、清理、报告，一个都不能少；

•  不要把 Golden 当成「通用 MFA 绕过」；它只对 GPM 同步 Passkey 成立。

RP / 身份开发者

•  强制并校验 UV；

•  注册时做 attestation，高保障账号限制认证器类型；

•  对 BE=1 的同步凭据做风险降级与 step-up；

•  不要依赖 signCount 检测克隆；

•  记录设备/地理/ASN，用行为风控补位。

最后用一句话收束：

说明

密码学没有输。输的是密钥生命周期：当「可恢复」被实现成「可交出」，Golden 就不会因为一次日志脱敏而消失。

参考

•  Unit 42, Pass the Passkey: A Novel Attack Surface in Passwordless Authentication, 2026-08-03. https://unit42.paloaltonetworks.com/passwordless-authentication-security-risks/

•  0rcruxe, Pass-ta-key Golden Attack: Extracting the Security Domain Secret from Chrome process memory, 2026-10-18. https://0rcruxe.github.io/posts/pass-ta-key-golden-attack-sds-extraction/

•  0rcruxe, Pass-ta-key Golden Attack: Decrypting GPM Passkeys and Forging WebAuthn Assertions for Account Takeover, 2026-10-19. https://0rcruxe.github.io/posts/pass-ta-key-golden-attack-decrypting-gpm-passkeys/

•  PoC: https://github.com/0rcruxe/pass-ta-key

•  SpecterOps, Pass-the-Passkey Family of Attacks: https://github.com/SpecterOps/pass-the-passkey

•  Chromium enclave_manager.cc: https://chromium.googlesource.com/chromium/src/+/main/chrome/browser/webauthn/enclave\_manager.cc

•  Chromium webauthn_credential_specifics.proto: https://chromium.googlesource.com/chromium/src/+/main/components/sync/protocol/webauthn\_credential\_specifics.proto

•  W3C, Web Authentication Level 2: https://www.w3.org/TR/webauthn-2/

•  SecurityWeek, New Attack Methods Enable Malware to Hijack Passkey-Protected Accounts, 2026-08-05. https://www.securityweek.com/new-attack-methods-enable-malware-to-hijack-passkey-protected-accounts/

•  BleepingComputer, New Pass-ta-key attacks let malware hijack Google-synced passkeys, 2026-08-03. https://www.bleepingcomputer.com/news/security/new-pass-ta-key-attacks-let-malware-hijack-google-synced-passkeys/

•  KZero, Pass-ta-key: The Passkey Cryptography Held. The Sync Layer Didn’t., 2026-08-04. https://kzero.com/blog/pass-ta-key-passkey-sync-risk-what-msps-should-do/

•  Andrea Fortuna, How Pass-ta-key attacks steal passkeys instead of passwords, 2026-08-10. https://andreafortuna.org/2026/08/10/pass-ta-key-passkey-forensics/

•  CVE-2025-12910: https://issues.chromium.org/issues/434977743

•  Google issue tracker 464305542: https://issuetracker.google.com/issues/464305542