文章总结： 该文档基于美国联邦法院公开文件，深入分析了Windows系统隐藏的全局设备标识符GDID及其在监控体系中的作用。核心结论是GDID作为用户不可见且不可禁用的设备标识符，能将所有网络活动汇报给Microsoft，即使使用VPN也无法逃避。文档详细披露了Microsoft如何通过GDID和遥测数据主动向FBI提交刑事转介，协助识别并追踪网络犯罪组织ScatteredSpider成员PeterStokes。这一体系比历史上的棱镜计划更强大，引发了关于隐私、法律与伦理的深刻讨论。 综合评分： 87 文章分类： 威胁情报,数据安全,网络安全,安全建设,政策法规
当棱镜学会呼吸 —— Windows系统隐藏的GDID全局设备标识符与后斯诺登时代的监控进化 ! – 2026-07-07
原创
穿过狂野的风 穿过狂野的风
安全漫道
2026年7月7日 00:37 陕西
在小说阅读器读本章
去阅读
*”那些不能记住过去的人，注定要重蹈覆辙。”* —— George Santayana *”Feds dont know what they just fumbled…”* —— Peter Stokes, Snapchat, 2025年1月 *”Microsoft 的设备标识符 (GDID) 与 Stokes 关联到了 .168 地址。”* —— FBI 特工宣誓证词，2026年4月
文档性质: 基于美国联邦法院公开法律文件的独立技术分析 核心来源: United States v. Peter Stokes, Case No. 25 CR 812, Superseding Criminal Complaint 签署法官: Hon. Daniel P. McLaughlin, U.S. Magistrate Judge, Northern District of Illinois 宣誓特工: Ali Sadiq, Special Agent, Federal Bureau of Investigation 文件日期: 2026年4月16日
目录
•序章：芬兰赫尔辛基机场，2026年4月10日[1]•第一部分：一份法庭文件引爆的真相[2]
•1.1 Scattered Spider：一个价值一亿美元的犯罪组织[3]•1.2 Microsoft 的刑事转介：一家商业公司如何充当情报源[4]•1.3 破案的关键：一段从未被公开的设备标识符[5]
•第二部分：GDID 解剖 —— 每一台 Windows 设备的隐形身份证[6]
•2.1 什么是 GDID[7]•2.2 GDID 的不可逃避性[8]•2.3 GDID 采集的数据全景图[9]•2.4 本案中的 GDID 实战[10]
•第三部分：Windows 遥测体系 —— 全球最大的端点监控网络[11]
•3.1 遥测采集架构[12]•3.2 数据采集的纵深层级[13]•3.3 Microsoft 可以回答的问题[14]•3.4 遥测数据的可查询性：§2703(d) 反向令的启示[15]
•第四部分：Microsoft 威胁情报机器 —— 从用户数据到刑事证据的工业流水线[16]
•4.1 五阶段 APT 追踪方法论[17]•4.2 Persona 身份解析管线[18]•4.3 刑事转介：商业公司的准执法功能[19]
•第五部分：棱镜计划的幽灵 —— 历史不会重复，但会押韵[20]
•5.1 棱镜计划（PRISM）：一段不应被遗忘的历史[21]•5.2 GDID + 遥测 vs. PRISM：对比分析[22]•5.3 关键差异：为什么 GDID 体系比 PRISM 更强大[23]•5.4 一个令人不安的推测：GDID 与情报机构的潜在关联[24]
•第六部分：Azure 云端监控基础设施[25]•第七部分：本案追踪全链路还原[26]•第八部分：隐私、法律与伦理的十字路口[27]•终章：我们需要问的问题[28]
序章：芬兰赫尔辛基机场，2026年4月10日
2026年4月10日，芬兰赫尔辛基机场。
一名19岁的年轻人正准备登上一架飞往日本的航班。他是美国-爱沙尼亚双重国籍公民，随身携带两台 2TB 容量的硬盘。护照上的名字是 Peter Stokes。
在他通过登机口之前，芬兰警方根据国际刑警组织（Interpol）的红色通缉令将其逮捕。通缉令的基础是美国伊利诺伊州北区联邦地区法院于 2025 年 12 月 22 日签发的逮捕令。
Stokes 并非普通的罪犯。在黑客世界中，他被称为 “Bouquet”、“Jordan”，而在 Microsoft 的内部情报系统中，他的代号是 “spencer”。他是网络犯罪组织 Scattered Spider（又称 Octo Tempest、UNC3944、Oktapus）的核心成员，该组织在数年内入侵了超过 100 家企业网络，勒索金额超过 1 亿美元。
但 Stokes 的被捕并非源于传统的刑侦手段。没有线人。没有跟踪。没有监控摄像头。
将他牢牢锁定在犯罪证据链中央的，是他 Windows 电脑中一个连他自己都不知道的、从未被公开文档化的标识符——GDID: 6755467234350028。
这台电脑默默地、持续地、全面地将他的一切网络活动汇报给了 Microsoft。
而 Microsoft，将这些信息提供给了 FBI。
第一部分：一份法庭文件引爆的真相
1.1 Scattered Spider：一个价值一亿美元的犯罪组织
2026年4月16日，FBI 特别探员 Ali Sadiq 在联邦法官面前宣誓，提交了一份替代刑事起诉书的宣誓证词（Affidavit）。这份证词为我们打开了一扇罕见的窗口，让我们得以窥见 Microsoft 内部的监控能力。
根据法庭文件，Scattered Spider 是一个高度组织化的网络犯罪团伙，其作案手法如下：
攻击链条
社会工程学攻击 │ ▼获取员工凭证 + 多因素认证绕过 │ ▼未经授权访问企业网络 │ ▼数据加密 (勒索软件) + 数据渗出 │ ▼加密货币勒索 (总计 >$100M) │ ▼非法资金洗钱
Stokes 涉及的攻击包括但不限于：
| 受害者 | 行业 | 攻击时间 | 损失/勒索金额 | | — | — | — | — | | Company F | 奢侈品珠宝零售 | 2025年5月 | ~$8M 加密货币 | | Company H | 在线通信平台 | 2023年3月 | PII 数据泄露 | | Company Q | 美国保险公司 | 2025年6月 | $15-20M (含间接损失) | | Company S | 未披露 | 2025年6月 | 260,000+ 文件被窃 |
1.2 Microsoft 的刑事转介：一家商业公司如何充当情报源
法庭文件 ¶ 10 披露了一个惊人的事实：Microsoft 主动向 FBI 提交刑事转介 (Criminal Referrals)，而且远不止一次。
2024年10月，Microsoft 在转介中写道：
“Microsoft analysts have identified information about persona ‘spencer’, a likely operator for Octo Tempest, and their associated accounts. Persona ‘spencer’ handles malware associated with Octo Tempest and has handled files associated with persona [Conspirator A’s moniker]…. Persona ‘spencer’ is likely true name Peter Stokes, and probably lives in Tallinn, Estonia. Microsoft analysts have observed online services telemetry associated with persona ‘spencer’ that indicates likely involvement in dozens of recent Octo Tempest intrusions ……“
这份转介的含金量不容低估。在 FBI 特工的宣誓证词中，Microsoft 的转介被评价为：
“Microsoft’s referrals and reports related to computer intrusions… have been reliable. In fact, multiple, similar referrals from Microsoft in this and related investigations have been corroborated by later legal process issued by the government.”
一家私营商业公司，通过其产品的内建监控功能，收集了足够的信息来识别一个匿名网络犯罪分子的真实身份、居住地、组织从属关系和长达数年的犯罪活动，然后主动将这些信息提交给联邦执法机构。整个过程不需要法院命令、不需要搜查令、不需要任何形式的司法监督。
1.3 破案的关键：一段从未被公开的设备标识符
在 Stokes 入侵 Company F 的行动中，他使用了一个 VPN 代理服务来隐藏自己的真实 IP 地址。通过这个 VPN IP（以 .168 结尾），他注册了一个 Ngrok 账户——Ngrok 是一种安全隧道工具，用于访问和渗出 Company F 的内部数据。
按理说，VPN 应该切断了溯源链路。
但法庭文件 ¶ 7 道出了关键：
“A Microsoft device identifier (a Global Device ID, or GDID, described below) associated with STOKES is linked to the .168 address.”
VPN 没有用。代理没有用。Stokes 的 Windows 设备通过一个他不知道的标识符，将他的一切网络活动汇报给了 Microsoft，包括他在 VPN 保护下的真实活动。
这就是 GDID。
第二部分：GDID 解剖 —— 每一台 Windows 设备的隐形身份证
2.1 什么是 GDID
GDID（Global Device Identifier，全局设备标识符）是 Microsoft 在 Windows 操作系统中实施的设备标识系统。基于法庭文件和 MSDN 残留文档，其技术特征如下：
| 属性 | 详情 |
| — | — |
| 全称 | Global Device Identifier (全局设备标识符) |
| 生成时机 | 每次 Windows 操作系统安装时自动生成 |
| 唯一性 | 每个 OS 安装实例唯一 |
| 持久性 | OS 安装生命周期内不变 — 重装 Windows 会产生新的 GDID (法庭文件原文确认)；系统更新和功能升级不改变 GDID |
| 可见性 | 用户不可见 — 无法在 Windows 设置中找到 |
| 文档化 | ⚠️ 基本未公开 — 仅在唯一一份 MSDN 文档中被提及 |
| 格式 | 16 位十进制数字 (如 6755467234350028) |
| 选择退出 | ❌ 不可禁用 — 没有关闭选项 |
| 覆盖范围 | 所有 Windows 设备 (约 15 亿台) |
2.2 GDID 的不可逃避性
GDID 最根本的特性是其不可逃避性。对于普通用户和网络犯罪分子而言，这种不可逃避性是一致的：
攻击者的分层 OPSEC 措施：
第1层 ┌── VPN (匿名IP) ─── ✅ 绕过传统IP追踪第2层 ├── Tor 网络 ─── ✅ 绕过深度包检测第3层 ├── 代理链 ─── ✅ 绕过单点监控第4层 ├── 租用VPS跳板 ─── ✅ 绕过地理追踪第5层 ├── 公共WiFi ─── ✅ 绕过物理定位第6层 ├── 虚拟机 ─── ⚠️ 增加复杂度但可被关联 │══════════════════════════════════════════════════════════ │第7层 └── Windows GDID (OS内核级) ─── ❌❌❌ 完全无法绕过 要改变GDID → 必须重装 Windows → 丢失所有数据和配置 代价：每次逃避追踪 = 一次完整的系统重装 ⚠️ 且重装后若再次联网，新 GDID 可能被立即分配并关联
在 APT 追踪中的意义：攻击者可以无限次更换 IP 地址、VPN 服务商、代理节点、甚至是物理位置，但只要使用同一台 Windows 设备，Microsoft 就可以将所有碎片化的网络身份串联到同一个 GDID，进而确定它们属于同一个人。
2.3 GDID 采集的数据全景图
根据法庭文件和关联材料的披露，单个 GDID 向 Microsoft 上报的数据范围如下：
GDID 6755467234350028 的数据流
┌─────────────────────────────────────────────────────────────┐│ 网络层 (Network Layer) ││ ┌─────────────────────────────────────────────────────┐ ││ │ • 当前 IP 地址 (包括 VPN/代理后的真实出口IP) │ ││ │ • IP 地址变更历史 (完整的时间序列) │ ││ │ • 网络连接的目标地址和端口 │ ││ │ • 租用服务器/VPS 的连接记录 │ ││ └─────────────────────────────────────────────────────┘ │├─────────────────────────────────────────────────────────────┤│ 传输层 (Transport Layer) ││ ┌─────────────────────────────────────────────────────┐ ││ │ • RDP 连接的目标和来源 │ ││ │ • VPN 连接的使用记录 │ ││ │ • 安全隧道工具使用 (Ngrok 等) │ ││ └─────────────────────────────────────────────────────┘ │├─────────────────────────────────────────────────────────────┤│ 应用层 (Application Layer) ││ ┌─────────────────────────────────────────────────────┐ ││ │ • 网页浏览活动 (URL + 精确时间戳) │ ││ │ • 应用程序使用记录 (进程名、窗口标题、使用时长) │ ││ │ • 在线服务账户活动 │ ││ │ • 视频游戏活动 (游戏名称、游戏时长) │ ││ └─────────────────────────────────────────────────────┘ │├─────────────────────────────────────────────────────────────┤│ 会话层 (Session Layer) ││ ┌─────────────────────────────────────────────────────┐ ││ │ • 活跃时间段 (时区推断) │ ││ │ • 会话持续时间 │ ││ └─────────────────────────────────────────────────────┘ │├─────────────────────────────────────────────────────────────┤│ 设备层 (Device Layer) ││ ┌─────────────────────────────────────────────────────┐ ││ │ • GDID (不可变锚点) │ ││ │ • 硬件指纹 (机器ID) │ ││ │ • OS 版本和配置 │ ││ └─────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────┘
关键观察：这些数据远远超出”系统诊断”所需的范围。特别是网页浏览活动、应用程序使用记录和视频游戏活动——这三类数据与系统安全或性能完全无关，仅对用户行为监控具有价值。
2.4 本案中的 GDID 实战
在本案中，GDID 发挥了三个关键作用：
作用一：穿透 VPN 匿名化
Stokes 攻击 Company F 的网络路径:
Stokes 的 Windows 设备 GDID: 6755467234350028 (位于塔林，爱沙尼亚) │ ▼ VPN 代理服务 (出口 IP 以 .168 结尾) │ ▼ Ngrok 安全隧道 (用于访问 Company F 内部网络) │ ▼ Company F 企业网络 (数据渗出 + 勒索软件部署)
传统溯源路径: Company F → Ngrok → VPN IP (.168) → ❌ 断链GDID 溯源路径: Company F → Ngrok → VPN IP (.168) → GDID 6755467234350028 → ✅ Stokes
作用二：多账户归并
Microsoft 通过 GDID 关联的 IP 地址历史，将 Stokes 使用的五个不同服务平台的账户全部归并到同一人：
GDID 6755467234350028 │ ├── Microsoft 账户 (通过 GDID 直接关联) ├── Snapchat 账户 (通过 IP 共享关联) ├── Apple 账户 1 (通过 IP 共享关联) ├── Apple 账户 2 (通过 IP 共享关联) └── RDP 服务器连接 (通过 IP 共享关联)
结论: 五个独立平台 → 一个 GDID → 一个人 → Peter Stokes
作用三：物理定位
即使 Stokes 从未在任何账户中使用真实地址信息，Microsoft 通过 GDID 上报的 IP 地址，精确锁定了他位于爱沙尼亚塔林的两个住宅 IP。FBI 随后通过 18 U.S.C. § 2703(d) 反向令，要求 Microsoft 搜索这两个住宅 IP 关联的所有账户，进一步扩展了证据链。
第三部分：Windows 遥测体系 —— 全球最大的端点监控网络
3.1 遥测采集架构
GDID 只是冰山一角。法庭文件揭露，Microsoft 的遥测体系是一个从设备端到云端的全栈监控系统：
┌──────────────────────────────────────────────────────────────────┐│ 全球 ~15 亿 Windows 设备 (传感器终端) ││ ││ ┌────────────────────────────────────────────────────────────┐ ││ │ Windows 操作系统 (内核级数据采集) │ ││ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ ││ │ │ GDID │ │ 遥测采集 │ │ 诊断数据 │ │ 活动历史 │ │ ││ │ │ 生成器 │ │ 引擎 │ │ 收集器 │ │ 记录器 │ │ ││ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └──────┬───────┘ │ ││ │ └──────────────┴────────────┴──────────────┘ │ ││ └──────────────────────────┬─────────────────────────────────┘ │└─────────────────────────────┼────────────────────────────────────┘ │ ▼┌──────────────────────────────────────────────────────────────────┐│ Microsoft 云端遥测基础设施 ││ ││ ┌──────────────┐ ┌──────────────┐ ┌────────────────────────┐ ││ │ Azure Monitor │ │ 遥测数据湖 │ │ 威胁情报分析平台 │ ││ │ Logging │ │ (Kusto/ADX) │ │ (MSTIC) │ ││ └──────┬───────┘ └──────┬───────┘ └───────────┬────────────┘ ││ └─────────────────┼──────────────────────┘ ││ │ ││ ┌────────────┐ ┌─────────┴───────┐ ┌──────────────────┐ ││ │ GDID 索引 │ │ IP-账户 关联库 │ │ 恶意软件样本库 │ ││ │ 数据库 │ │ (§2703(d)可查) │ │ │ ││ └────────────┘ └─────────────────┘ └──────────────────┘ │└──────────────────────────────────────────────────────────────────┘
3.2 数据采集的纵深层级
法庭文件脚注 1 以 FBI 特工的视角确认了 Microsoft 遥测数据的范围：
“Cybersecurity researchers at Microsoft, through the course of their job, have access to data, such as computer machine IDs, IP addresses, and malware samples associated with sophisticated cybergroups.”
这与 Windows 诊断数据设置中展示给用户的模糊描述形成了鲜明对比：
| 用户看到的描述 | 法庭文件证实的实际能力 | | — | — | | “发送基本设备信息” | 发送唯一的、不可变的、用户不可见的设备标识符 (GDID) | | “诊断数据” | 包括网页浏览活动、应用使用记录、游戏活动 | | “安全数据” | 包括完整的 IP 地址历史、网络连接日志、RDP 连接记录 | | “改进产品” | 用于构建个人级别的详细数字行为画像 |
3.3 Microsoft 可以回答的问题
基于法庭文件披露的能力，Microsoft 对于任何一个 Windows 用户，可以回答以下类型的问题：
通过 GDID + 遥测，Microsoft 可以回答:
┌─────────────────────────────────────────────────────────────┐│ ││ "这个人在 2025年3月15日 的什么时候使用了什么应用？" ││ → 通过 GDID 的活动时间戳和应用日志获取 ││ ││ "这个人在过去一年中使用了哪些 IP 地址？" ││ → 通过 GDID 的 IP 地址历史获取 ││ ││ "这个人的真实住宅 IP 是什么 (在 VPN 保护下)？" ││ → 通过 GDID 在有/无 VPN 时的 IP 差异分析获取 ││ ││ "这个人玩过什么游戏？什么时间？" ││ → 通过 GDID 的游戏活动遥测获取 ││ ││ "这个人和谁共用过同一个 IP 地址？" ││ → 通过 IP → 多GDID 关联查询获取 ││ ││ "这个人的真实姓名可能是什么？" ││ → 通过 GDID → 账户 → 个人信息交叉推断获取 ││ ││ "这个人居住在哪里？" ││ → 通过住宅 IP 地理定位 + 时区分析获取 ││ ││ "这个人是否参与了网络攻击？" ││ → 通过 GDID → 恶意活动模式匹配获取 ││ │└─────────────────────────────────────────────────────────────┘
3.4 遥测数据的可查询性：§2703(d) 反向令的启示
法庭文件脚注 9 披露了一个极其重要的技术事实：
“on or about June 23, 2025, Chief Judge Virginia M. Kendall signed a reverse 18 U.S.C. § 2703(d) order for two Tallinn, Estonia IP addresses believed to have been used by STOKES, based on Microsoft records. Such an order required Microsoft, among other providers, to search for all accounts that may have used those Tallinn IP addresses and provide associated IP addresses for the accounts that did.”
这证明了三个关键事实：
1.Microsoft 的遥测数据是可查询的——不是一次性日志，而是结构化的、可被检索的数据库。2.数据是双向索引的——既可以通过账户查询 IP，也可以通过 IP 反向查询所有账户。3.查询可以递归扩展——”Microsoft returns from that order show additional IP addresses that were accessed by the underlying, true IP addresses”——每个查询结果都会暴露新的查询目标。
§2703(d) 反向查询的递归扩展:
第 1 轮: FBI 输入 塔林IP₁, 塔林IP₂ Microsoft 输出: 账户A, 账户B, 账户C + 它们各自使用的其他IP
第 2 轮: FBI 输入 新发现的IP₃, IP₄, IP₅ Microsoft 输出: 账户D, 账户E + 更多IP
第 3 轮: FBI 输入 更多新IP ...
结果: Stokes 的整个数字生活 — 每个账户、每个IP、每个设备 — 被完整绘制
第四部分：Microsoft 威胁情报机器 —— 从用户数据到刑事证据的工业流水线
4.1 五阶段 APT 追踪方法论
法庭文件脚注 1 是本案最具揭示性的段落。FBI 特工 Ali Sadiq 在其中完整描述了 Microsoft 网络安全研究团队追踪高级持续威胁 (APT) 组织的标准化操作流程：
Microsoft APT 追踪方法论 (来源: FBI 宣誓证词, 脚注1)
┌─────────────────────────────────────────────────────────────────┐│ ││ Phase 1 ──── 识别恶意活动 ││ ┌───────────────────────────────────────────────────────────┐ ││ │ "identifying malicious activity (malware attacks, │ ││ │ spear-phishing, etc.) conducted against innocent victims" │ ││ │ │ ││ │ 输入: 全球遥测数据流 │ ││ │ 输出: 标记为恶意的活动事件 │ ││ └───────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Phase 2 ──── 识别攻击者的计算机 ││ ┌───────────────────────────────────────────────────────────┐ ││ │ "identify the computers used to conduct the attacks" │ ││ │ │ ││ │ 输入: 恶意活动特征 → 反查遥测数据库 │ ││ │ 输出: 执行攻击的设备 GDID 列表 │ ││ └───────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Phase 3 ──── 发现同伙 ││ ┌───────────────────────────────────────────────────────────┐ ││ │ "identify colleagues of the hacker by finding other │ ││ │ computers also accessed from the same IP addresses used │ ││ │ by the initially identified hacker" │ ││ │ │ ││ │ 输入: 已知攻击者的 IP 列表 │ ││ │ 查询: "哪些其他 GDID 也从这些 IP 连接过?" │ ││ │ 输出: 同伙的 GDID 列表 │ ││ └───────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Phase 4 ──── 建立组织画像 ││ ┌───────────────────────────────────────────────────────────┐ ││ │ "identify unique groups of hackers" │ ││ │ │ ││ │ 输入: GDID 集群 + 共享基础设施 + 共同TTPs │ ││ │ 输出: APT 组织边界 + 成员图谱 + 工具链档案 │ ││ └───────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Phase 5 ──── 持续追踪 ││ ┌───────────────────────────────────────────────────────────┐ ││ │ "track those groups to determine new IP addresses the │ ││ │ hackers are observed connecting to the Internet from, │ ││ │ such as leased server IPs. This also allows the │ ││ │ researchers to determine whether these IP addresses are │ ││ │ being used to target victims." │ ││ │ │ ││ │ 输入: 已标记的 APT 组织 GDID 列表 │ ││ │ 持续动作: 实时监测新 IP → 分析新 IP 的用途 → 发现新攻击目标 │ ││ │ 输出: 实时威胁预警 + 持续更新的情报 │ ││ └───────────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────┘
关键洞见：这套方法论是自动化的、规模化的、持续运行的。它不是一个针对特定案件的调查流程，而是 Microsoft 日常运营的一部分。
4.2 Persona 身份解析管线
Microsoft 不仅仅是追踪设备和 IP——它构建了一条从技术指标到真实世界身份的完整解析管线：
Microsoft 身份解析管线 (以 Stokes 为例)
Layer 0: 技术锚点 └── GDID 6755467234350028 ← 一切的起点
Layer 1: 虚拟身份聚合 ├── Microsoft 账户活动 ├── 关联邮箱: [email protected] └── 内部代号: "spencer"
Layer 2: 多平台关联 ├── GDID IP → Snapchat 账户 (be547f61-...) ├── GDID IP → Apple 账户 1 (21898004821) ├── GDID IP → Apple 账户 2 (18743558491) └── GDID IP → RDP 连接 (.191 服务器)
Layer 3: 行为画像 ├── 活跃时区: 爱沙尼亚/阿联酋 ├── 角色: APT 组织 operator (操作员) ├── 工具链: Octo Tempest 关联恶意软件 ├── 攻击范围: 数十起入侵, 美英关键基础设施 └── 入行时间: 2022年起
Layer 4: 真实身份 ├── 真实姓名: Peter Stokes ├── 国籍: 美国/爱沙尼亚双国籍 ├── 出生日期: 2006年12月3日 ├── 居住地: 塔林, 爱沙尼亚 ├── 护照记录: 美国国务院 └── 旅行轨迹: 巴黎/意大利/西班牙/德国/纽约/迪拜/泰国
Layer 5: 执法行动 ├── Interpol 红色通缉令 ├── 芬兰赫尔辛基机场逮捕 (2026年4月10日) └── 引渡程序进行中
从 Layer 0 到 Layer 5，Microsoft 的分析管线在 2024 年 10 月之前就已经完成了前四层——距离 Stokes 最终被捕还有 18 个月。
4.3 刑事转介：商业公司的准执法功能
Microsoft 的刑事转介并非偶发的人道主义行为，而是一个系统化的、可重复的流程：
Microsoft 刑事转介工厂
┌──────────────────┐ ┌──────────────────┐ ┌─────────────────┐│ 自动检测 │────▶│ 威胁情报分析 │────▶│ 身份解析 ││ (24/7 全球) │ │ (APT组织归因) │ │ (Persona→真实名) │└──────────────────┘ └──────────────────┘ └────────┬────────┘ │ ▼┌──────────────────┐ ┌──────────────────┐ ┌─────────────────┐│ 后续更新 │◀────│ FBI 调查 + 验证 │◀────│ 刑事转介撰写 ││ (持续情报供给) │ │ (独立法律程序) │ │ (结构化报告) │└──────────────────┘ └──────────────────┘ └─────────────────┘
转介报告包含的内容 (基于 ¶ 10-11, ¶ 14, ¶ 16):
•内部代号和真实身份评估•关联的在线服务账户•恶意软件处理历史•同伙关联分析•攻击基础设施 (VPS) 的 IP 地址•攻击时间线和目标清单•地理定位信息•涉及的关键基础设施
法庭文件对转介可靠性的评价明确无误：
“Microsoft’s referrals and reports… have been reliable. In fact, multiple, similar referrals… have been corroborated by later legal process.”
这意味着 Microsoft 的转介不是”线索提示”级别的情报，而是达到了可被独立法律程序验证的准确度。
第五部分：棱镜计划的幽灵 —— 历史不会重复，但会押韵
5.1 棱镜计划（PRISM）：一段不应被遗忘的历史
2013年6月，前 NSA 承包商雇员 Edward Snowden 向《卫报》和《华盛顿邮报》披露了一套被称为 PRISM（棱镜）的秘密大规模监控计划。PRISM 的核心机制是：NSA 和 FBI 直接从 Microsoft、Google、Apple、Facebook 等九家美国主要科技公司收集用户数据，据称依据的是《外国情报监视法》(FISA) 第 702 条。
PRISM 的关键特征：
•政府机构（NSA/FBI）通过法律强制获取数据•主要针对非美国公民的海外通信•数据收集需经 FISA 法院批准•公司被禁止公开讨论该计划•公众在 Snowden 披露前完全不知情
PRISM 在 2013 年引发了全球范围的隐私辩论。美国科技公司随后大力宣传其”隐私优先”和”反对政府监控”的立场。Microsoft 在当时公开挑战美国政府的数据请求，赢得了部分公众信任。
但法庭文件揭示的 GDID + 遥测体系，呈现了一个与 PRISM 既相似又不同的全景监控图景。
5.2 GDID + 遥测 vs. PRISM：对比分析
| 维度 | PRISM (2013) | GDID + Windows 遥测 (2026) | | — | — | — | | 启动方 | 政府 (NSA/FBI) | Microsoft (主动) | | 法律基础 | FISA 702条 + 法院命令 | 用户许可协议 (EULA) + 诊断数据条款 | | 数据流 | 公司 → 政府 (被动响应) | 用户设备 → Microsoft (主动采集) → 政府 (主动转介) | | 用户知情 | 否 (秘密计划) | 形式上是 (EULA中的模糊条款) | | 退出选项 | 否 | 名义上有 (诊断数据设置)，但 GDID 不可关闭 | | 数据范围 | 通信内容 (邮件、聊天等) | 设备级全量活动 (网络、应用、游戏、网页) | | 覆盖规模 | 特定目标 + 批量收集 | ~15 亿 Windows 设备 (全球) | | 标识符 | 账号/通信标识符 | GDID (设备物理绑定、不可变) | | 持久性 | 取决于监控周期 | 设备整个生命周期 | | 执法应用 | 情报用途为主 | 可直接用于刑事起诉 | | 司法监督 | FISA 法院 (秘密) | 无 — Microsoft 主动转介无需法院命令 |
5.3 关键差异：为什么 GDID 体系比 PRISM 更强大
差异一：从”被动响应”到”主动采集 + 主动推送”
PRISM 模式 (2013): 政府请求 → 公司查询 → 返回数据 数据流方向: 政府拉取 (pull)
GDID 模式 (2026): 设备主动上报 → 公司分析 → 主动提交刑事转介 → 政府 数据流方向: 公司推送 (push)
PRISM 需要政府知道自己在找什么。GDID 体系是 Microsoft 先收集了所有人的所有数据，一旦发现”有趣”的目标，就主动打包推送给政府。
差异二：从”通信内容”到”设备全量行为”
PRISM 主要收集通信内容：邮件正文、聊天记录、VoIP 通话。GDID 系统收集的是设备级的全量行为数据，覆盖了网络层到应用层的每一层：
PRISM 数据范围: GDID 数据范围:┌─────────────────┐ ┌─────────────────────────────┐│ 邮件内容 │ │ 网络层: IP、连接、端口 ││ 聊天记录 │ │ 传输层: RDP、VPN、隧道 ││ VoIP 通话 │ │ 应用层: 网页URL、应用使用 ││ 文件传输 │ │ 会话层: 活跃时间、时长 ││ 社交网络数据 │ │ 娱乐层: 游戏活动 ││ │ │ 设备层: GDID、硬件指纹 │└─────────────────┘ └─────────────────────────────┘ 内容 (what) 行为 + 身份 (who + when + how)
差异三：从”有目标的收集”到”无差别的全覆盖”
PRISM 理论上针对特定目标。GDID 系统覆盖了 约 15 亿台设备。对于每一个 Windows 用户，无论是否被怀疑、无论是否犯罪、无论是否是美国公民，数据都被收集、存储和分析。
差异四：从”司法监督”到”公司自主决策”
PRISM 要求 FISA 法院批准。GDID 体系下的刑事转介 完全不需要法院命令——Microsoft 自主决定分析哪些数据、追踪哪些目标、以及将哪些信息转交给 FBI。
5.4 一个令人不安的推测：GDID 与情报机构的潜在关联
法庭文件确认的事实引发了一系列无法回避的问题：
如果 Microsoft 可以主动向 FBI 提交刑事转介，那么它是否也可以向 NSA、CIA 或其他情报机构提交类似的情报产品？
如果 §2703(d) 反向令可以让 FBI 查询 IP 关联的所有账户，那么 FISA 702 条是否被用于针对外国目标的批量查询？
如果 GDID 是一个”仅在一份 MSDN 文档中提及”的标识符，那么有多少其他同样未文档化的数据采集组件存在于 Windows 中？
如果 Microsoft 在 2024 年 10 月就知道 Stokes 的真实身份，为什么逮捕行动要等到 2026 年 4 月？这 18 个月中，Microsoft 是否持续向情报机构提供关于 Stokes 及其同伙的实时活动数据？
我们无法基于公开的法庭文件回答这些问题。但法庭文件确认的事实，使得这些问题不再是阴谋论，而是合理的、需要回答的质疑。
第六部分：Azure 云端监控基础设施
根据参考材料中的线索，Azure 云平台包含了以下与监控直接相关的组件：
6.1 Azure UCDOStatus
UCDO 的全称推断为 Unified Cloud Device Observability（统一云端设备可观测性）。这个组件很可能负责：
Azure UCDOStatus 推断功能:
┌─────────────────────────────────────────────────────┐│ ││ • 设备状态持续监控 ││ • GDID → 云端设备注册表的同步 ││ • 设备在线状态、健康度、活动状态的实时追踪 ││ • 为遥测数据流提供设备维度的元数据 ││ │└─────────────────────────────────────────────────────┘
6.2 Azure Monitor Logging
Azure Monitor 日志系统在遥测基础设施中的角色：
Azure Monitor Logging 推断功能:
┌─────────────────────────────────────────────────────┐│ ││ • 集中化的遥测数据接收端点 ││ • 跨服务日志聚合 (Windows 遥测 + O365 + Azure + Xbox) ││ • 实时数据分析管道 ││ • 长期历史数据存储 (支持 §2703(d) 的数月跨度的查询) ││ • 威胁情报查询接口 ││ │└─────────────────────────────────────────────────────┘
6.3 完整的数据流架构
┌────────────────────────────────────────────────────────────────┐│ Microsoft 云端监控全景 ││ ││ ┌──────────────────────────────────────────────────────────┐ ││ │ 数据采集层 │ ││ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────────┐ │ ││ │ │Windows │ │ Azure │ │Office │ │ Xbox │ │ ││ │ │遥测 │ │服务日志 │ │365 活动 │ │ 游戏遥测 │ │ ││ │ │(GDID) │ │ │ │ │ │ │ │ ││ │ └────┬────┘ └────┬────┘ └────┬────┘ └──────┬──────┘ │ ││ └───────┼────────────┼────────────┼───────────────┼────────┘ ││ └─────────────┴─────────────┴───────────────┘ ││ │ ││ ▼ ││ ┌──────────────────────────────────────────────────────────┐ ││ │ 数据聚合与存储层 │ ││ │ ┌──────────────────┐ ┌──────────────────┐ │ ││ │ │ Azure Monitor │ │ 遥测数据湖 │ │ ││ │ │ Logging │ │ (长期历史存储) │ │ ││ │ └────────┬─────────┘ └────────┬─────────┘ │ ││ └───────────┼──────────────────────┼────────────────────────┘ ││ └──────────┬───────────┘ ││ │ ││ ▼ ││ ┌──────────────────────────────────────────────────────────┐ ││ │ 分析与行动层 │ ││ │ ┌────────────────┐ ┌────────────┐ ┌──────────────────┐ │ ││ │ │ APT追踪引擎 │ │ Persona │ │ 刑事转介生成器 │ │ ││ │ │ (五阶段方法论) │ │ 身份解析 │ │ │ │ ││ │ └───────┬────────┘ └─────┬──────┘ └────────┬─────────┘ │ ││ │ └─────────────────┼───────────────────┘ │ ││ │ │ │ ││ │ ┌─────────────┴──────────────┐ │ ││ │ │ 执法/情报 输出 │ │ ││ │ │ FBI刑事转介 + §2703(d)响应 │ │ ││ │ └────────────────────────────┘ │ ││ └──────────────────────────────────────────────────────────┘ │└────────────────────────────────────────────────────────────────┘
第七部分：本案追踪全链路还原
基于法庭文件的所有证据，以下是 Microsoft 对 Peter Stokes 的完整追踪链路重建：
时间轴: Peter Stokes 追踪全链路
2022 │ Stokes 加入 Octo Tempest 组织 │ Microsoft 遥测系统首次检测到相关设备活动 │ GDID 6755467234350028 开始积累数据 │2023年3月 │ Company H 入侵事件 │ Stokes (Bouquet) 与 Coconspirator A 通信被记录 │ Microsoft 开始建立 "spencer" persona │2023-2024 │ Microsoft 持续追踪 GDID 6755467234350028 │ 收集: │ ├── 所有 IP 地址变化 (VPN + 住宅) │ ├── 所有互联网活动 (网页、应用、游戏) │ ├── 所有在线账户访问 (Microsoft、Apple、Snapchat) │ ├── RDP 连接到 Subject Server 1 (.191) │ └── 数十起网络入侵的证据 │ │ Phase 3 同伙发现: │ ├── 通过共享 IP 发现 Coconspirator A │ └── 通过共享 IP 发现其他 Scattered Spider 成员 │ │ Phase 4 组织画像: │ └── 确认 Octo Tempest / Scattered Spider 组织边界 │2024年10月 │ Microsoft 提交第一次刑事转介给 FBI │ 转介内容: │ ├── "spencer" = 可能的 Octo Tempest 操作员 │ ├── 真实身份评估: Peter Stokes │ ├── 地理位置: 塔林, 爱沙尼亚 │ ├── 关联: 数十起入侵, 美英关键基础设施 │ └── 时间跨度: 自 2022 年起 │2025年5月12-15日 │ Company F 入侵 (奢侈品珠宝零售商) │ GDID 6755467234350028 的关键作用: │ ├── Stokes 使用 VPN IP (.168) 注册 Ngrok │ ├── GDID 将 VPN IP 关联到设备 │ └── 穿透了 VPN 匿名化层 │2025年6月 │ Company Q 入侵 (保险公司, 损失 $15-20M) │ Company S 入侵 (260,000+ 文件被窃) │2025年6月23日 │ 法院签署 §2703(d) 反向令 │ Microsoft 被要求: │ ├── 搜索塔林两个住宅 IP 的所有关联账户 │ └── 提供这些账户的其他 IP 活动记录 │ 查询结果进一步扩展了证据链 │2025年8月 - 2026年5月 │ 跨源 IP 重叠分析进行中 │ 五个数据源交叉验证: │ ├── Snapchat Returns │ ├── Apple Returns 1 & 2 │ ├── Microsoft Returns (GDID) │ └── Subject Server 1 RDP Logs │ 结果: 全连通图 → 所有账户由同一人控制 │2025年12月22日 │ 法院签署: │ ├── 初始逮捕令 │ ├── Snapchat 搜查令 │ ├── Apple 账户搜查令 (×2) │ ├── Facebook 搜查令 │ └── Subject Server 1 搜查令 │2026年4月10日 │ 芬兰赫尔辛基机场 │ Stokes 在登机前往日本前被逮捕 │ 携带: 2×2TB 硬盘 │2026年4月16日 │ 替代刑事起诉书签署 │ 6项联邦重罪指控: │ ├── Count 1: 共谋 (18 U.S.C. § 371) │ ├── Count 2-4: 计算机入侵 (18 U.S.C. § 1030) │ ├── Count 5: 电汇欺诈共谋 (18 U.S.C. § 1349) │ └── Count 6: 电汇欺诈 (18 U.S.C. § 1343) │ │ 引渡程序进行中
整个追踪过程的关键数据来自 Microsoft Windows 遥测系统，而非传统的执法调查手段。
第八部分：隐私、法律与伦理的十字路口
8.1 本案的正面价值
必须承认的是，Microsoft 的监控能力在本案中发挥了明确的正面作用：
•✅ 成功追踪并协助逮捕了一名参与 100+ 起网络入侵的危险犯罪分子•✅ 保护了未来可能被攻击的关键基础设施•✅ 帮助多家受害企业确认了数据泄露的规模•✅ 为国际执法协作提供了技术支撑
8.2 但代价是什么？
然而，必须同时审视的是：
•⚠️ ~15 亿 Windows 用户的同等数据被以同样方式收集，无论他们是否犯罪•⚠️ 用户无法真正选择退出——GDID 不可禁用；即使使用本地账户（不登录 Microsoft 账户），GDID 仍可能被分配和上报•⚠️ 缺乏透明性——GDID 仅在唯一一份 MSDN 文档中被提及•⚠️ 缺乏独立监督——Microsoft 自主决定追踪谁、分析谁、转介谁，无需司法批准•⚠️ 功能蠕变 (function creep)——为”诊断”目的收集的数据被用于刑事调查和情报分析•⚠️ 先例效应——如果 Microsoft 可以这样做，那么其他 OS 厂商会如何跟进？
8.3 法律框架的空白
当前的法律保护 (或缺乏):
美国公民 非美国公民 网络犯罪分子 │ │ │ ▼ ▼ ▼┌──────────┐ ┌──────────┐ ┌──────────────┐│ 第四修正案│ │ FISA │ │ 本案: GDID ││ 保护 │ │ 702条 │ │ 追踪 + 逮捕 ││ (理论上) │ │ │ │ │└────┬─────┘ └────┬─────┘ └───────────────┘ │ │ └───────┬───────┘ │ ▼ ┌─────────────────┐ │ Microsoft 的 │ │ 数据采集 │ │ │ │ 谁来监督? │ │ 答案: 没有人 │ └─────────────────┘
Microsoft 的 GDID 和遥测系统存在于一个法律灰色地带：
•对美国公民：第四修正案保护需要政府行为 (state action) 的前提，Microsoft 的主动采集是否构成政府行为？•对非美国公民：FISA 702 条允许的情报收集范围是否涵盖了 Microsoft 主动推送的数据？•EULA 是否构成合法同意：当”同意”是使用操作系统的前提条件时，”同意”还是自愿的吗？
终章：我们需要问的问题
Peter Stokes 的案件是一个完美的特洛伊木马——就像古希腊人用木马将士兵送入特洛伊城一样，Stokes 的案件将 GDID 和 Windows 遥测体系的真相送入了公众视野。
一个网络犯罪分子被绳之以法，这是好事。但实现这一结果的工具——一个不为人知的、不可禁用的、覆盖 15 亿人的全时全维监控系统——却值得我们每一个人停下来思考。
必须被回答的问题
1.
GDID 到底是什么时候被引入 Windows 的？ 哪个版本开始包含它？Microsoft 是否在任何公开文档中完整描述过它？
2.
GDID 采集的数据到底有多少？ 法庭文件确认的数据类型（网页活动、应用使用、游戏活动）只是冰山一角还是完整清单？
3.
谁可以访问这些数据？ Microsoft 威胁情报团队的范围是什么？数据是否与第三方（包括外国政府）共享？
4.
Windows 用户如何真正退出？ 最新逆向分析表明，即使使用本地账户也可能生成 GDID。重装系统是唯一的 GDID 重置方式——但重装后新 GDID 可能立即被分配。是否存在任何切实可行的方法阻止 Windows 分配和上报设备标识符？
5.
§2703(d) 反向令的使用频率是多少？ 每年有多少 IP 地址被执法机构用于查询 Microsoft 的账户关联数据库？
6.
Microsoft 还向多少国家的执法/情报机构提交过类似转介？ 是否包括非民主国家？
7.
还有多少未文档化的监控组件隐藏在 Windows 中？ GDID 是唯一的吗？
8.
此能力是否曾被滥用？ 是否存在 Microsoft 员工或第三方利用遥测数据追踪个人（非犯罪目的）的案例？
9.
GDPR 和其他隐私法规对此类系统有何约束？ Microsoft 如何向欧洲用户解释 GDID 和遥测数据的收集？
10.
我们作为用户，还有选择吗？
最后的话
当一个 19 岁的黑客使用最先进的 OPSEC 技术——VPN、代理、加密通信、租用服务器——却仍然被他电脑中一个他从未听说过、无法找到、无法关闭的标识符出卖时，我们需要问：如果连一个精通技术的黑客都无法逃避这种监控，普通用户又如何？
2013 年的棱镜计划需要秘密法院、需要政府强制、需要九家公司的被迫配合。2026 年的 GDID 体系——所有这些都不需要。它只需要每一台运行 Windows 的电脑。
棱镜没有消失。它被植入了操作系统内核，并改名为 GDID。
附录 A: 关键法庭段落索引
| 段落 | 内容 | 重要性 | | — | — | — | | ¶ 7 | GDID 首次出现，关联 VPN IP | ★★★★★ | | ¶ 10 | Microsoft 2024年10月刑事转介全文 | ★★★★★ | | 脚注 1 | 五阶段 APT 追踪方法论完整描述 | ★★★★★ | | 脚注 2 | “spencer” 是 Microsoft 内部代号 | ★★★ | | 脚注 9 | §2703(d) 反向令的详细描述 | ★★★★★ | | ¶ 14 | Microsoft 识别 Subject Server 1 | ★★★★ | | ¶ 16b | 五源 IP 重叠分析 | ★★★★★ | | ¶ 4 | 声明证据来源包括 Microsoft 网络专家 | ★★★ |
附录 B: 数据来源声明
本报告所有技术性论断均基于以下公开文件：
•United States District Court, Northern District of Illinois, Eastern Division•Case No. 25 CR 812: United States of America v. Peter Stokes•Superseding Criminal Complaint, dated April 16, 2026•Affidavit of Ali Sadiq, Special Agent, Federal Bureau of Investigation•签署法官: Hon. Daniel P. McLaughlin, U.S. Magistrate Judge
所有标记为”推断”的内容均已明确标注，其余内容均可在上述法庭文件中找到直接或间接的文本依据。
附录 C: 技术逆向验证 —— 法庭文件之外的确凿证据
法庭文件公开后，独立安全研究人员基于 Windows 11 build 26200 的公开符号文件 (Microsoft Public PDBs)、ETW 实时捕获和静态逆向工程，完整复现了 GDID 的生成、存储和传输全链路。以下为技术事实摘要。
C.1 GDID 的真实身份：MSA Device PUID
GDID 并非此前传闻的”128 位硬件序列号哈希”。逆向工程证实：
| 传闻 | 事实 |
| — | — |
| “128 位” | 法庭文件中 Stokes 的 GDID 6755467234350028 转换为十六进制是 0x0018000FC8CB93CC，仅 64 位 |
| “由硬件序列号生成” | 法庭文件原文指出重装系统会产生新的 GDID——若由硬件序列号派生，重装后应得到相同值。事实并非如此 |
| “仅在 MSDN 中提及” | Microsoft 自身的 Azure Monitor 公开文档在 UCDOStatus 表中定义了 GlobalDeviceId 列，描述为 *”Microsoft global device identifier. This is an identifier used by Microsoft internally.”* |
C.2 完整技术链路（已通过 ETW 实时捕获验证）
┌──────────────────────────────────────────────────────────┐│ ① wlidsvc.dll — Microsoft 账户服务 (GDID 的"铸币厂") ││ 设备向 login.live.com 发起设备注册请求 ││ 服务器在 SOAP 响应中返回 <ps:DevicePUID> ││ ⚠️ 本地账户下也可能触发设备注册，生成 GDID ││ 客户端将 PUID 存入注册表 (明文) │└────────────────────────┬─────────────────────────────────┘ │ ▼┌──────────────────────────────────────────────────────────┐│ ② cdp.dll — 连接设备平台 (CDPSvc) ││ GetStableDeviceIdFromProvider → 从 MSA 层获取 PUID ││ RegisterUserDeviceAsync → 注册到设备目录服务 (DDS) ││ 端点: dds.microsoft.com ││ 设备 ID 格式: "g:<十进制PUID>" │└────────────────────────┬─────────────────────────────────┘ │ ▼┌──────────────────────────────────────────────────────────┐│ ③ DDS 服务端 — Device Directory Service ││ 以 g:<PUID> 为键，关联 MSA 账户、活动记录和 IP 历史 ││ Microsoft 内部可查询此图谱 │└────────────────────────┬─────────────────────────────────┘ │ ▼┌──────────────────────────────────────────────────────────┐│ ④ Delivery Optimization (DO) ││ 将 PUID 作为 UCDOStatus.GlobalDeviceId 上报 ││ 旁带 LastCensusSeenTime、ISP、City、Country ││ 即：设备ID + 地理位置 + IP + 时间戳 = 一包完整画像 │└──────────────────────────────────────────────────────────┘
C.3 任何人都可以找到自己的 GDID
不需要管理员权限。不需要逆向工程。一行 PowerShell 命令：
$hex = (Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID"g:$([Convert]::ToUInt64($hex,16))"
或者直接查看：
HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties LID = 0018XXXXXXXXXXXX ← 这就是你的 GDID (十六进制)
前缀 0018 代表 Device PUID 类别（用户 PUID 前缀为 0003）。Stokes 的 GDID 0x0018000FC8CB93CC 与此完全一致。
C.4 关键结论
1.
GDID 是服务器分配的——它不是客户端本地计算的结果，而是 login.live.com 在设备注册时下发的。这意味着 Microsoft 服务端可能拥有一份完整的 GDID→设备的映射表，即使该设备从未使用 Microsoft 账户登录。
2.
GDID 以明文存储在注册表中——任何能读取 HKCU 的应用程序（即几乎所有以当前用户身份运行的程序）都可以获取此值。
3.
GDID 的持久性来自 MSA 账户绑定，而非硬件绑定——重装系统 = 新设备注册 = 新 PUID = 新 GDID。设备一经注册，CDP 服务便会持续将 GDID 同步到 DDS 云端图谱。
4.
本地账户并不能阻止 GDID 的生成——根据最新发现，即使使用本地账户（不登录 Microsoft 账户），Windows 仍可能分配并上报 GDID。这意味着”使用本地账户”这一传统隐私建议在此处可能无效。真正的缓解手段是重装系统并彻底阻止设备注册和 CDP 服务，但这需要相当的技术知识，且可能导致 Windows 功能受限。对于大多数用户而言，GDID 本质上是不可逃避的。
5.
Microsoft 的 Azure 文档公开承认了 GDID 的存在——只是使用了一个不会被用户联想到”全局设备指纹”的技术性名称：UCDOStatus.GlobalDeviceId。
逆向分析来源: gdid-reversal[29] — Windows 11 build 26200, Microsoft public PDBs, ETW TraceLogging via Microsoft.Windows.CDP.* providers.
最终附录: 你可以立即做的事
在你的 Windows 电脑上，打开 PowerShell，输入：
$hex = (Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LIDif ($hex) { "你的 GDID: g:$([Convert]::ToUInt64($hex,16))" }else { $tokenPath = (Get-ChildItem 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token' -ErrorAction SilentlyContinue | Select-Object -First 1).PSPath if ($tokenPath) { $deviceId = (Get-ItemProperty "$tokenPath").DeviceId if ($deviceId) { "你的 GDID: g:$([Convert]::ToUInt64($deviceId,16))" } else { "未找到 GDID" } } else { "未找到 GDID" }}
⚠️ 注意：即使你使用的是本地账户（未登录 Microsoft 账户），仍然可能在注册表中找到 GDID。该标识符的存在与否不取决于你是否主动登录了 Microsoft 账户。
看到那串 g: 开头的数字了吗？
那就是 Microsoft 用来在 15 亿人中唯一标识你的全局设备指纹。
它被存储在明文中。被上报到云端。被关联到你的 IP 地址、网页浏览记录、应用使用习惯和游戏活动。
而你从未被告知。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：安全漫道 穿过狂野的风 穿过狂野的风《当棱镜学会呼吸 —— Windows系统隐藏的GDID全局设备标识符与后斯诺登时代的监控进化 ! – 2026-07-07》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论