Windows hidden fingerprint: what the GDID revelation means for defenders
A federal complaint against an alleged Scattered Spider member surfaced a persistent Windows identifier most security teams have never heard of. Here's how it works, how it survived a VPN, and what to actually do with that information on both sides of the table.
01 The case that surfaced it
In April 2026, Finnish police detained 19-year-old dual US-Estonian national Peter Stokes at Helsinki airport as he attempted to board a flight to Japan. He was extradited to the United States on charges tied to Scattered Spider activity, including an alleged breach of a US luxury jewelry retailer that led to an $8 million ransom demand.
Stokes had used a VPN to obscure his activity while accessing ngrok, a tunneling tool used to maintain persistent unauthorized access to the retailer's network. That should have been enough to keep his device anonymous. It wasn't. The FBI's complaint shows Microsoft supplied telemetry logs containing both Stokes' Global Device Identifier — GDID — and websites visited from his machine, letting investigators work backward from that ngrok session to a specific piece of hardware, regardless of the VPN in front of it.
02 What GDID actually is
GDID is a server-assigned Device PUID, not a hardware hash. It's minted when Windows provisions against a Microsoft Account: the wlidsvc service requests a Device PUID from login.live.com, which then gets registered into Microsoft's Device Directory Service by the Connected Devices Platform (CDP). It persists across Windows updates but resets on a clean reinstall — a reinstall triggers new provisioning and a fresh server-assigned value, which is one reason researchers are confident it isn't derived from fixed hardware.
It's stored locally in plaintext, in the current user's own registry hive:
LocationValue HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedPropertiesLID (hex)03 How it leaked past a VPN
A VPN masks your IP at the network layer. It does nothing to stop the OS from separately reporting a device-bound identifier over its own channels. In the Stokes case, the relevant triggers were login/provisioning traffic to login.live.com, Delivery Optimization update-sharing telemetry, and — per independent analysis — SmartScreen/Defender URL-reputation checks in Edge, which appear to have carried the ngrok signup page alongside the GDID when telemetry was set above the minimum level.
Investigators then used the GDID as a pivot, not a standalone smoking gun: once it was tied to the ngrok session, they built an IP history for that device and cross-referenced it against known logins to Stokes' Apple, Snapchat, Facebook, and Growtopia accounts across Estonia, New York, and Thailand.
04 Practical techniques
The theory is interesting; the operational questions are what matter. Below are concrete, checkable steps for each side of the table. Treat the registry paths and query shapes as a starting point — GDID's internals are still being reverse-engineered by the community, not officially documented by Microsoft, so validate against your own build before relying on it operationally.
For red teams: treat GDID as OPSEC surface
Before an engagement, read the GDID on any operator box that has ever touched a Microsoft Account — including inherited images and gold VMs:
(Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID # server-side g:<decimal> form $hex = (Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID "g:$([Convert]::ToUInt64($hex,16))"
On dedicated operator infrastructure, block outbound to the known reporting endpoints at the firewall or hosts-file level:
login.live.com dds.microsoft.com activity.windows.com
login.live.com is required for MSA sign-in — blocking it breaks that flow, which is the point. It won't stop provisioning that already happened, and Delivery Optimization / Store traffic can use additional endpoints beyond this list.The local-account assumption doesn't fully hold. Community reverse-engineering of CDP indicates it has an anonymous device registration path that can still fire even without a Microsoft Account signed in — so "local account only" reduces but does not eliminate device-level telemetry.
- Never sign a Microsoft Account into infrastructure used for an engagement, even briefly to install something.
- Build operator VMs from a clean, never-provisioned base image; revert to snapshot rather than reusing a box across engagements.
- Disable Delivery Optimization and set diagnostic data to the minimum available level before first boot on the network.
- Assume any box that has ever been MSA-signed-in is burned for future covert use, not just "cleaned."
For blue teams: GDID as a correlation signal
Add registry monitoring on the identity key to catch both legitimate provisioning and tampering (e.g. tools that patch the LID value to spoof another device's identity):
<RuleGroup name="GDID-IdentityCRL" groupRelation="or">
<RegistryEvent onmatch="include">
<TargetObject condition="contains">IdentityCRL\ExtendedProperties</TargetObject>
</RegistryEvent>
</RuleGroup>
If you're pulling Update Compliance / Delivery Optimization data into Sentinel or Log Analytics, UCDOStatus exposes a documented GlobalDeviceId column alongside geo and ISP fields. A device correlating to an unusual number of source locations or IP ranges over a short window is a starting hypothesis, not a verdict:
UCDOStatus
| where TimeGenerated > ago(30d)
| summarize FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated),
DistinctIPs = dcount(IPAddress),
IPs = make_set(IPAddress, 10)
by GlobalDeviceId
| where DistinctIPs > 3
| sort by DistinctIPs desc
- Insider / device-swap investigations: the LID under
IdentityCRL\ExtendedPropertiesis one of the cleanest "is this the same physical install" signals you have locally — cheaper than full disk forensics for a quick triage question. - Legal process: in a breach involving a Microsoft-account-linked endpoint, a GDID can be a concrete artifact to request from Microsoft through legal process, the way the FBI did in the Stokes case — worth adding to your evidence-preservation checklist alongside standard account and sign-in logs.
- Anti-forensic detection: treat unexplained writes to the LID value, or the presence of registry-patching utilities targeting it, as a tamper indicator during DFIR triage on a suspect's own machine.
05 The bigger picture
GDID itself isn't new — it's referenced in Microsoft's own Azure Monitor documentation — but this is the first time its role in device-level correlation has been laid out in this much detail, in a federal complaint, for anyone to read. For defenders, it's a reminder that endpoint telemetry designed for licensing and update management doubles as a persistent forensic trail: one that doesn't require the user to be signed in, and one a VPN alone won't hide.
SOURCES — FBI criminal complaint, United States v. Peter Stokes (N.D. Ill., July 2026) · The Register · Tom's Hardware · gHacks · CSO Online · Proton VPN · Windows Latest · independent GDID reverse-engineering research (community writeups, July 2026)Technical details on GDID's internal structure come from post-case community research rather than official Microsoft documentation and may be revised as further analysis emerges.
