文章总结： 本文解析FBI利用Windows设备标识GDID溯源攻击者的案例，指出GDID由微软服务端签发、持久绑定设备且重装系统才会变更，通过五步流程在微软生态内传播，结合IP、账号与行程记录形成证据链。文章总结三条开源对抗方案及其局限，强调服务端留存与硬件指纹使彻底规避困难，建议红队定期更换系统并避免依赖微软服务。
综合评分： 72
文章分类： 逆向分析,取证应急,安全工具,实战经验,其他
GDID：FBI 溯源用的无法彻底删除的设备指纹介绍
原创
佚名
佚名
赛博57库
2026年9月25日 22:00
广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
| |
| — |
| 取证应急 GDID：一个绑定 Windows 系统的设备标识，如何帮 FBI 溯源，以及如何规避 GDID · Windows 设备标识 · 归因溯源 · 反取证 · IdentityCRL · 五条结构性原因 |
| |
| — |
| 📌 本文怎么读 2026 年 7 月，一份解封的起诉书把一个此前几乎没人注意的 Windows 标识推到了台前：FBI 借助微软的 Global Device Identifier（GDID），把一台作案机器和一串个人账号最后归因到了具体的设备和人——这不是漏洞被利用，而是一个设计如此、且没有开关的安装级标识。 本文按这条GDID编号的生命周期讲五件事：它是谁签发的（出生）、为什么你访问哪个服务它都跟着（传播——接口级的五个环节，这是全文的技术核心）、它怎么从一个标识符ID变成证据（成链）、能不能擦掉（对抗——三条开源路线的做法与各自的硬伤），以及防守方怎么用它（落地）。读完你能拿到：GDID 的完整生命周期与关键接口、三条让它可溯源的性质，以及一份可以直接进 IR 流程的取证与反取证痕迹检查项。 彩蛋：文中的接口链路、注册表位置清单与反取证痕迹检查清单已整理成《GDID 取证速查卡》，关注公众号回复「GDID」获取下载链接。 对于攻击者红队来说，最简单的就是定期更换操作系统+避免使用第三方服务里的微软服务。 |
01 · 先说结论：一个 g: 号，把两个身份焊在了一起
2026 年 7 月 1 日，美国司法部解封了对 Peter Stokes 的刑事起诉书。19 岁，美国与爱沙尼亚双籍，网名 “Bouquet”，被指为 Scattered Spider（别名 Octo Tempest / UNC3944 / 0ktapus）成员，在赫尔辛基机场准备登机飞日本时被拦下，随后引渡至美国、在芝加哥首次出庭，指控包括共谋、计算机入侵与欺诈。以下均为指控内容，按无罪推定。
案件本体是典型的服务台社工攻击：2025 年 5 月，攻击者用 Google Voice 号码冒充被锁员工骗过一家奢侈品珠宝零售商的 IT 服务台，拿到三个账号（含两个 IT 管理员）的密码与多因素认证重置；随后用 ngrok 与 Teleport 外传至少 77GB 数据，勒索 800 万美元未果，据该公司向 FBI 的陈述，业务中断、调查、缓解处置三类损失合计约 200 万美元，且”预计还有进一步损失”。
这个案子真正值得写的，是起诉书里的一段技术认定：那个 ngrok 账号，是在一台 GDID 为 g:6755467234350028 的 Windows 设备上注册的。
| |
| — |
| 起诉书里可核验的连接点 ────────────────────────────────────────────── 2025-05-12 19:21 UTC 该设备访问 ngrok 注册页， 与 ngrok 账号创建同一分钟 2025-05-12 约 22:00 该设备经同一代理访问受害人网站 2024-06 塔林 同一 GDID 出现在 Snapchat / Apple / 2024-11 纽约 Facebook 账号的 IP 与时间记录中， 2025-02 泰国 与国务院旅行记录吻合 ────────────────────────────────────────────── |
换句话说，溯源突破口不是漏洞，而是一条编号。本文就按这条编号的生命周期讲四件事：它是谁签发的（出生）、为什么你去哪个服务它都跟着（传播）、它怎么从编号变成证据（成链）、以及为什么擦不掉（对抗）。
02 · 出生：编号由微软服务端签发，客户端只是保存
GDID = Global Device Identifier。起诉书引用微软代表的原话：一个持久化的、设备级标识符，用于唯一标识一台设备上一次 Windows 操作系统的安装。这句话有两个推论：系统更新中它保持不变；重装 Windows 会得到全新的 GDID。
顺手纠正两个流传很广的说法：它不是硬件序列号算出来的——如果它是序列号的函数，重装后应该算出同一个值，而起诉书明说重装换号；它也不是 128 位——案子里这个值换算成十六进制是 0x0018000FC8CB93CC，落在 64 位里。
它的形状是 g: 加一个十进制整数，本地存成 16 位十六进制：设备类常见前缀 0018，账户类通常以 0003 开头，光看前缀就能区分”这是一个设备”还是”这是一个账户”。
谁签发：微软服务端。Windows 侧组件只做”申请”和”保存”：
| |
| — |
| Windows 安装 │ DeviceAddRequest（DeviceInfo 带硬件材料： │ EKPub / SMBIOS 序列号 / 磁盘 / TPM 等） ▼ login.live.com/ppsecure/deviceaddcredential.srf │ 服务端签发 Device PUID ▼ 本地身份存储 IdentityCRL |
这里有一个必须单独记住的点：它不需要微软账户。 CDP 存在一条匿名设备路径——只用本地账户、从不登录微软账户的机器，也能完成机器级注册。实测记录显示，在一台只用本地账户的镜像上，解除注册屏蔽后约两分钟，0018… 形状的 PUID 就出现在 SYSTEM 与 .DEFAULT 两个机器配置单元里。“用本地账户、不碰微软系服务”是很多人默认的 OPSEC 做法，这个假设在这里失效。
编号落盘的位置（自查与取证用途）：
| |
| — |
| HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties LID HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Property\<PUID> HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\*\DeviceId HKEY_USERS\.DEFAULT\Software\Microsoft\IdentityCRL\... LID HKEY_USERS\S-1-5-18\Software\Microsoft\IdentityCRL\... LID |
但不要把自己的值贴到网上——设备 PUID、账户 PUID 加用户 SID 足以认出一个人。
03 · 传播：为什么你访问哪个服务，它都跟着
这是全文最技术的一节，也是”溯源”能成立的地基。先把结论说清楚，因为它常被讲错：
| |
| — |
| GDID 不是被网站收到的，而是在微软服务端每次换取”设备令牌”时被记录下来的。 |
也就是说，让编号跟着你走的不是浏览器，是微软自己这套身份体系。按真实调用顺序，五个环节：
| |
| — |
| ① 发号 POST login.live.com/ppsecure/deviceaddcredential.srf DeviceAddRequest / DeviceInfo → 服务端签发 Device PUID ② 换令牌 login.live.com/RST2.srf（及相关 STS） 用设备身份换设备安全令牌；Autopilot 线里以 x-device-token 的形式带进 ztd.dds.microsoft.com ③ 分发 ...\IdentityCRL\Immersive\production\Token\<客户端GUID>\ 每个客户端目录里同时有 DeviceId 与 DeviceTicket ——同一个 DeviceId 被盖上多份票 ④ 进图 cdp.dll（CDPSvc）→ DdsRegistrationClient::RegisterUserDeviceAsync → cs.dds.microsoft.com 等 DDS 端点，格式串 "g:%s" ⑤ 上报 dosvc（交付优化）→ UCDOStatus.GlobalDeviceId 同一行就是 City / Country / ISP / LastCensusSeenTime |
把这五步读一遍，”为什么访问多个服务都会被带上”就清楚了：
• 第 ② 步是关键。服务要的不是你的密码，而是”这是同一台设备”的证明。任何需要把身份挂到设备上的微软服务，都得走这一步换票。
• 第 ③ 步解释了覆盖面。令牌是按客户端分别落盘的，实测样本里 SYSTEM 与 .DEFAULT 两个机器配置单元各发现了 9 份相同的 DeviceId，客户端包括 Store、Client.CBS（账户、跨设备续接）、ContentDeliveryManager、CDP、设置、Outlook、WebView2 等。谁要跟微软服务说话，谁就去自己那份目录取票——所以同一个编号出现在越多地方，能被关联的行为面就越大。
• 第 ④ 步解释了格式。设备图里用的是格式串 "g:%s"，这正好对应服务端记录里 g:<十进制> 的写法——你看到的那个 g: 号就是这么进图的。
• 第 ⑤ 步解释了地理。交付优化把 GlobalDeviceId 报进更新合规报表，同一行就有城市、国家、运营商、最近上报时间——设备标识与网络位置在数据结构上就是挨着的。
所以准确的说法是：
| |
| — |
| 你用 VPN 访问 ngrok，ngrok 看不到 GDID。但同一台机器为了登录、同步、更新、图功能去微软换令牌时，会带着同一个编号从那个被掩过的 IP 出现。服务端看到的不是”某个网站的访客”，而是”哪一次 Windows 安装、在什么时间、从哪个 IP、用了哪些微软服务”。VPN 改变的是到站点的路径，不是到微软的身份。 |
必须守住的边界：以上能证明微软持有”设备身份 + 时间 + IP + 服务使用”的关联，但“访问了 ngrok 注册页”这个具体 URL 是怎么和 GDID 对上的，公开记录没有指认是哪个组件、哪条通道。起诉书用的是一句 “Microsoft records”，采访此案的律师提醒：这几个字可能把好几个数据源压缩进了一句话，它不一定意味着 Windows 记录了每个浏览器访问的每个网站，也无法确定完整网址来自 Edge、Defender SmartScreen、其他安全服务还是别的产品。这条通道是公开未解问题，本文不作断言。
04 · 成链：从一个编号到一个人，中间只有三步
编号本身没有意义。它变成证据，靠的是三次”归并”。
第一步，把散落的会话归并到同一次安装。 因为编号跨系统更新、日常重启都不变，只有重装才换，案子里同一个 GDID 从 2024 年 6 月的塔林串到 2025 年 5 月的作案，跨度接近一年——这是一个可以长期当主键用的标识。
第二步，把机器和账号接上。 这是本案真正的爆点：同一个 GDID 出现在多个平台的记录里——作案用的基础设施账号，和他个人的 Snapchat、Apple、Facebook 账号。作案机器和个人真身被焊在了同一个键上。 单看任何一边都只是马甲，连起来就是一个人。
第三步，让现实记录来对齐。 IP 历史、时间戳、旅行记录、社交内容互相印证。Huntress 安全运营高级经理 Dray Agha 对 CSO Online 的总结很到位：
| |
| — |
| 微软并不是在监视 ngrok，它监视的是设备，是调查人员把点连了起来。GDID 这种持久标识是烧进操作系统里的——设备通过代理照常回连微软做更新或同步，就等于给这个代理打上了”已知设备”的标签。OPSEC 往往止步于网络层。 |
三步的分工可以一句话记住：技术标识回答”这几个点属于同一台机器”，现实记录回答”这台机器属于谁”。
最后补一条性质上的提醒：刑事起诉书是”合理根据”文书，不是技术审计日志——它能支撑指控，不等于已经把整条数据链讲清楚了。
05 · 对抗：三条路线、三个硬伤
先说清楚”要对抗的是什么”，因为这决定了后面每条路线的天花板。
可控的是局部：本地保存的编号副本、铸号路径、本地再水化源。 不可控的是全局：微软服务端的历史留存、那条至今没被指认的上报通道、以及其它标识平面（账户 PUID、注册请求里的硬件材料、IP 历史、广告 ID、Entra 设备 ID、Autopilot 硬件哈希）。
三条主流开源路线，做法与硬伤如下：
| | | | | |
| — | — | — | — | — |
| 路线 | 代表项目 | 做法 | 它确实挡住了什么 | 硬伤 |
| 移除 + 持续屏蔽 | deGDID | 双栈 hosts 屏蔽身份域、防火墙规则、清空身份存储扩展包 | 已验证范围内的铸号路径与已知本地存储 | 只覆盖非域/非 Entra/非 MDM 的单用户系统；只完整验证了一条 Windows 版本线；明确声明不主张能阻断法庭记载的那条未知通道；证据窗口 33 小时 + 18 小时 |
| 关服务 + 屏蔽域名 | gdid-privacy | 关闭 CDP 相关服务，hosts 屏蔽跟踪端点 | 设备图注册与活动同步 | 铸号方是身份服务的 DeviceAdd，不是 CDP ；关掉 CDP 影响的是”注册进图”，不等于封住铸号路径；清本地 CDP 目录只是本地状态，PUID 会从身份存储回来 |
| 轮换换号 | Windows-GDID-Changer | 清除本地设备注册状态，强制重新注册 | 旧的 GDID 值 | 拿到的是微软真实签发的另一个号；项目自己建议”重新注册前先改硬件标识”，等于承认硬件材料仍可做跨注册匹配；换号只换标签，不换机器 |
deGDID 是这批里做得最严谨的：有明确的完成判定、完整实验记录、每条结论都带置信度标签，还主动划出”我不管什么”。正因为它做得最认真，它的边界最能说明问题——它把”到底是哪个组件、哪条链路把 GDID 和时间、URL、IP 关联起来”列为自己未解的研究问题。同一批工作至今也没有做完线上验证：”匿名 DeviceAdd 的请求与响应字段到底是哪些””交付优化请求里是否真的直接带 GDID”，都还挂在未解清单上。
然后是三条不依赖具体工具的结构性原因：
一、它是服务端签发的。 本地存的是副本，不是原件。你把副本删干净，删除动作也不会送到微软的数据库里，旧记录的留存不受你控制。
二、已知清单天生”有界”。 做得最认真的那个工具在自己文档里写明不保证清单穷尽。这不是客套，是被实测打过：
| |
| — |
| deGDID 记录的一次失败（延迟再水化） ────────────────────────────────────────────── 清理完成 + 门禁健康 → 重启两次 → 服务与任务触发 门禁全程健康，网络侧铸号尝试全部被拦 约 7 小时后：SYSTEM 与 .DEFAULT 的 Property / Token 存储里重新出现设备 PUID ────────────────────────────────────────────── 结论：本地清理会被"再水化"，延迟以小时计 |
三、必须”持续”生效才算数。 同一份实验记录显示：解除屏蔽后，一台从未注册过的系统约两分钟就完成机器级注册。防护只能”一直有效”，做不到”做过一次”——而 Windows 功能更新、防火墙策略重置、hosts 被改、安全软件干预，任何一次都可能让门禁失效。
反过来看，这三条里有一条对防守方是好消息：反取证动作本身必须留痕——被批量清空的身份存储、屏蔽域名用的 hosts 标记区、执行后自删的计划任务，都是取证起点。一台正常机器不会长这样。
所以真正的结论不是”这些工具有 bug”，而是它们在解一道客户端无解的题。
06 · 落地：取证、研判与合理预期
对防守与取证方，这个编号可以直接用起来。
第一，它是可读的。涉案主机的设备身份状态就在注册表里（位置见第二节）。采集时注意两点：必须同时看三个配置单元（当前用户、.DEFAULT、S-1-5-18）——只查当前用户 hive 会漏掉机器级副本；同时记录这些值是否存在且前后一致，整片缺失或互相矛盾本身就是信号。
第二，它”被动过”的状态比它本身更有价值：
| |
| — |
| 反取证痕迹检查起点 ────────────────────────────────────────────── 身份存储：LID / Property / Token DeviceId 被批量清空 hosts ：出现成对标记区，屏蔽身份与设备图相关域名 防火墙 ：存在按域名动态解析的拒绝规则， 且关键域名的地址集合为空或未水化 计划任务：短生命周期、执行后自删的提权任务 凭据 ：设备相关条目缺失（SSO_POP_Device / virtualapp/didlogical） ────────────────────────────────────────────── 单项都不构成证据；组合出现才是"有人在处理设备身份" |
第三，服务商侧记录只能走正式渠道。端点侧无论怎么清理，都拿不到微软手里的历史。研判时也要守住措辞：”Microsoft records” 不足以说明通道，”某产品记录了完整浏览历史”不是能从公开记录里推出来的结论。
对普通用户与隐私关注者，预期要放低。 目前没有可以关掉这个标识的设置项；微软的说法是，这是内部设备级标识、用于特定服务与场景，不是面向消费者的追踪功能。限制诊断数据、检查隐私设置、尽量用本地账户，都不能消除 GDID 本身。
07 · 收尾：变的是归因的成本结构
过去一次入侵要被归因，通常需要攻击者犯错：复用基础设施、泄露真实身份、留下可关联痕迹。防守与执法一侧的假设，本质上是”等一个失误”。
这个案子的形状不太一样。一条操作系统级的安装标识，加上服务商侧长期保存的时间、IP、服务使用关联，就足以把”作案的那台机器”和”个人的真实账号”接到一起——这个过程不需要攻击者在技术层面犯错，他只需要在同一台机器上同时做两件事。
更值得记住的是两侧的不对称：
| |
| — |
| 标识是服务端签发的、跨更新持久的、没有账户也会生成的；它被微软自己的换票流程分发到每一个需要设备身份的服务上，并且和硬件、账户、网络、社交四个平面都有冗余连接。而客户端一侧的应对，只能删本地副本、堵铸号路径，还得持续维持，并且一定会被 Windows 更新和日常运维动作打破。 |
这就是”没有好的规避方法”的准确含义：它不是一道靠更好的工具就能解开的题，因为题目本身不在客户端。
对防守方来说这个结论是正面的——一个你以前可能从没注意过的注册表键，现在是一条能用的线索，它被动过的痕迹本身也是线索；对攻击方来说这个结论是结构性的——“OPSEC 止步于网络层”这句话，在这一案里被写进了法庭文件。
参考与延伸：
• 美国司法部北伊利诺伊州检察官办公室起诉书（United States v. Peter Stokes）：https://www.justice.gov/usao-ndil/media/1450651/dl?inline
• The Hacker News《Court Filing Reveals Windows Device ID Helped FBI Trace Alleged Scattered Spider Hacker》：https://thehackernews.com/2026/07/court-filing-reveals-windows-device-id.html
• CSO Online《A Scattered Spider member was indicted. Microsoft’s GDID went to trial.》：https://www.csoonline.com/article/4203079/a-scattered-spider-member-was-indicted-microsofts-gdid-went-to-trial.html
• Windows GDID 逆向与生命周期记录（含 ETW 观测与 PDB 符号）：https://github.com/SmtimesIWndr/gdid-reversal
• deGDID（移除 + 持续屏蔽路线，含实验与残留风险章节）：https://github.com/yegors/deGDID
• gdid-privacy（关服务 + hosts 路线）：https://github.com/someguy0110/gdid-privacy
• Windows-GDID-Changer（强制重新注册换号，含 DeviceAdd 抓包说明）：https://github.com/gd03gd031/Windows-GDID-Changer
MITRE ATT&CK 对照（仅针对”清理设备身份”这类反取证动作的检测视角）：T1070 指标清除、T1070.004 文件删除、T1562 削弱防御、T1112 修改注册表。以上为本文分析性映射，不是任何项目的官方发布。
本文为公开信息的整理与技术分析：法院文件内容转述自公开报道与起诉书原文，逆向与工具行为描述整理自各项目公开文档（调研时点 2026-09-23），实现可能随版本变化；”哪个组件通过哪条通道上报 GDID”至今没有公开结论，本文不作断言。文中不含任何可直接照做的规避步骤，相关技术仅限授权测试与防御研究。
| |
| — |
| ⚠ 免责声明与边界 ① 本文只讲机制、溯源与取证面，不含任何可直接照做的规避步骤（不写脚本参数、不写屏蔽清单的执行方式、不写清理命令序列）；文中出现的注册表位置用于自查与取证说明。② 司法部起诉书内容按”指控”转述，当事人无罪推定；”微软记录”的具体数据来源与上报通道在公开记录中没有结论，本文不作断言。③ 项目相关描述整理自各项目公开文档（调研时点 2026-09-23），实现可能随版本变化。④ 文中的 ATT&CK 编号为本文分析性映射，不是任何项目的官方发布。⑤ 相关技术仅限授权测试与防御研究，禁止用于任何未授权目标。 |
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：赛博57库 佚名
佚名《GDID：FBI 溯源用的无法彻底删除的设备指纹介绍》