TL;DR

[!NOTE] Das unten Aufgeführte ist wahr, aber es fehlen einige Informationen. Unabhängig davon, ob Sie mit einem MSA angemeldet sind, haben Sie eine GDID. Das habe ich zum Zeitpunkt der Veröffentlichung nicht erkannt, aber ich habe es überprüft. CDP hat einen anonymen Gerätepfad, der verwendet wird, wenn kein MSA verbunden wurde. Das zugrundeliegende System ist immer noch sachlich korrekt, es fehlen nur ein paar Dinge.

• GDID ist ein echtes Telemetrieelement. Es taucht in der US-Bundesstrafklage (United States v. Peter Stokes, N.D. Ill., Juli 2026) als Global Device Identifier g:6755467234350028 auf.
• Es ist eine Microsoft-Konto-„Device PUID". Eine 64-Bit-Passport Unique ID, die einer Windows-Installation zugewiesen wird, wenn sie sich bei einem Microsoft-Konto registriert, und die im Gerätegraph als g:<decimal> geschrieben wird.
• Die Behauptungen sind falsch. Es ist nicht „128 Bit" und nicht „aus Seriennummern generiert." Die Gerichtsakte selbst sagt, dass eine Neuinstallation eine neue GDID erzeugt, was ausschließt, dass sie von Hardware-Seriennummern wie der GPU abgeleitet wird.
• Der Stack, von unten nach oben: wlidsvc (Microsoft-Kontodienst) richtet das Gerät bei login.live.com ein und erhält eine Geräte-PUID zurück -> speichert sie in der Registry -> die Connected Devices Platform (cdp.dll / CDPSvc) liest sie und registriert sie im Device Directory Service (DDS)-Graph -> Delivery Optimization meldet sie als die dokumentierte UCDOStatus.GlobalDeviceId.
• All dies wurde auf einer echten Windows 11 (26200)-Maschine mit öffentlichen Symbolen nachvollzogen. Sie können Ihre eigene GDID in einem Registry-Read finden (§7).

[!NOTE] Kennzeichnung des Vertrauensgrads. Jede Behauptung ist markiert, damit Sie sie selbst gewichten können: [COURT] Tatsache aus der Primärquelle, [OBSERVED] live auf meiner Testmaschine reproduziert, [STATIC] aus Binärdateien und öffentlichen Windows-PDBs nachgewiesen, [ASSESSED] starke Schlussfolgerung aus den Beweisen.

Inhaltsverzeichnis

1. Hintergrund: was das Gericht tatsächlich sagte
2. Widerlegung der viralen Mythen
3. Wo GDID sichtbar wird: Delivery Optimization
4. Wem es gehört: Connected Devices Platform zu DDS
5. Wie CDP es bekommt: es konsumiert, es berechnet nicht
6. Die Prägestätte: MSA Device PUID (wlidsvc)
7. Finden Sie Ihre eigene GDID
8. Verringerung der Exposition
9. Methodik (reproduzierbar)
10. Einschränkungen und ehrliche Vorbehalte

1. Hintergrund: was das Gericht tatsächlich sagte

Am 1. Juli 2026 entsiegelte das US-Justizministerium eine Strafanzeige gegen Peter Stokes, ein angebliches Mitglied von Scattered Spider (auch bekannt als Octo Tempest / UNC3944 / 0ktapus). Die eidesstattliche Erklärung beschreibt, wie Microsoft dem FBI half, Aktivitäten einem Gerät zuzuordnen.

[!IMPORTANT] [COURT] Aus der ergänzenden Beschwerde (§25, S.34), wörtlich:

„Das ngrok-Konto wurde über die Global Device Identifier g:6755467234350028 (die GDID) eingerichtet. Nach Angaben eines Microsoft-Vertreters ist ein Global Device Identifier im Windows-Ökosystem eine persistente, geräteebenenübergreifende Kennung, die eine Installation eines Windows-Betriebssystems auf einem Gerät eindeutig identifiziert ... Eine GDID ist eine global eindeutige Kennung, die an die Installation von Windows auf einem Gerät gebunden ist. Eine GDID bleibt über Windows-Betriebssystem-Updates auf einem Gerät hinweg konsistent, aber eine Neuinstallation von Windows ... wird an eine neue eindeutige GDID gebunden sein. "

Eine Fußnote fügt hinzu, dass ein Microsoft-Benutzer mehrere GDIDs haben kann. Die eidesstattliche Erklärung korreliert dann die IP-Verlauf und das Surfverhalten der GDID (z.B. empirehotelnyc.com, eine Growtopia/Ubisoft-Anmelde-URL) mit den Konten, bei denen der Verdächtige angemeldet war.

Zwei Dinge tragen den Rest dieses Berichts:

1. Der Wert ist g: plus eine ganze Dezimalzahl (g:6755467234350028). Hexadezimal ist das 0x0018000FC8CB93CC, also eine 64-Bit-Zahl.
2. Eine Neuinstallation ergibt eine neue GDID. Es kann also nicht einfach eine Funktion unveränderlicher Hardware sein.

2. Widerlegung der viralen Mythen

Die Zusammenfassung in den sozialen Medien behauptete, die GDID sei „eine 128-Bit-Kennung, die bei der Installation aus Seriennummern generiert wird." Beide Hälften sind falsch:

[!NOTE] Nach weiterem Reverse-Engineering von CDP. Ich habe einige Fehlinformationen gegeben. Die Verwendung eines lokalen Kontos verhindert keine GDID. CDP hat einen anonymen Gerätepfad, der verwendet wird, wenn kein Microsoft-Konto vorhanden ist. Behalten Sie dies beim Lesen im Hinterkopf.

3. Wo GDID sichtbar wird: Delivery Optimization

[STATIC] Microsofts öffentliche Azure Monitor-Dokumentation definiert eine GlobalDeviceId-Spalte in der Tabelle UCDOStatus (Update Compliance / Delivery Optimization):

GlobalDeviceId (string): „Microsoft global device identifier. Dies ist eine Kennung, die von Microsoft intern verwendet wird."

Es steht direkt neben LastCensusSeenTime, ISP, City, Country, also eine Geräte-ID in Verbindung mit Geo und IP. Dies ist die eine Stelle, an der Microsoft den Wert in öffentlichen Dokumenten benennt. Aber Delivery Optimization meldet es nur. Wichtig ist, dass es das Eigentum NICHT hat. Wenn man es stromaufwärts verfolgt, landet man bei der Connected Devices Platform.

4. Wem es gehört: die Connected Devices Platform zu DDS

[STATIC] C:\Windows\System32\cdp.dll (die Connected Devices Platform, Dienste CDPSvc + CDPUserSvc) enthält das GlobalDeviceId-Symbol und ein vollständiges Device Directory Service-Registrierungs-Subsystem:

ddsregistrationclient.cpp   ddsregistrationmanager.cpp   ddsregistrationinfo.cpp
DdsRegistrationClient   RegisterUserDevicesObserver   DdsRegistrationInfoProviderForCDP
endpoints: dds.microsoft.com  fd.dds.microsoft.com  aad.cs.dds.microsoft.com  cdpcs.access.microsoft.com
device-id format string: "g:%s"

DDS = Device Directory Service, Microsofts geräteübergreifender Identitätsgraph (das Backend hinter Phone Link, Cloud-Zwischenablage, „Auf PC fortsetzen", Nearby Share). CDP ist der Windows-Client, der die Installation in diesen Graphen einträgt, wo sie als g:<decimal> verschlüsselt wird.

4.1 Live aufgezeichnet

[OBSERVED] Durch Erzwingen einer frischen Registrierung (Neustart von CDPSvc mit gelöschtem lokalem Status) und Erfassen der eigenen ETW-Anbieter von CDP wurde der gesamte Handshake erzeugt:

DdsClient::RegisterUserDeviceAsync()   RegistrationReason: Startup   Account Type: MSA
DDSClient: Registration response received. HTTP status code: 200
OnRegisterUserDeviceComplete
GetDeviceIdAndTicketActivity -> deviceid: 0018XXXXXXXXXXXX

Dieses deviceid, geschrieben als g:<decimal>, entspricht strukturell dem Wert aus der Beschwerde:

Beide sind 64-Bit-Werte in derselben 0x0018-High-Word-Klasse (dem Device-PUID-Namespace, siehe §6). Das g:-Präfix ist einfach diese ganze Zahl in Dezimaldarstellung.

5. Wie CDP es bekommt: es konsumiert, es berechnet nicht

[STATIC] Mit dem öffentlichen PDB (cdp.pdb) ist der Geräte-ID-Pfad in cdp.dll nur eine Anfrage und ein Warten auf den Identitäts-Stack. CDP berechnet die ID nie selbst:

flowchart TD
    A["GetStableDeviceIdFromProvider<br/>0x0A3140"] --> B["provider.GetStableDeviceIdAsync<br/>(vtable +0x48)"]
    B --> C["OneCoreAccountProvider::<br/>GetStableDeviceIdAsync 0x0C8370"]
    C --> D["IWebAccountBackedAccountProvider<br/>(MSA / AAD identity COM)"]
    D --> E["OnGetStableDeviceIdCompleted<br/>(const char* deviceId) 0x06CEA0"]
    E -->|"assign() string, signal flag"| A

Der Rückruf, der es empfängt, macht es offensichtlich. Die ID erscheint als String und wird einfach gespeichert:

; OnGetStableDeviceIdCompleted
mov  rbp, r9                 ; r9 = device-id STRING handed in by the identity provider
lea  rcx, [rsi+0xD8]         ; CDP member field
mov  rdx, rbp
call assign@basic_string     ; store it, no computation, no serials
call Set@CdpWaitableFlag      ; unblock the waiter

Fazit: Die GDID wird unterhalb von CDP geprägt, im Windows-Identitäts-Stack, und CDP als undurchsichtiger String übergeben. Das weist auf den Microsoft-Kontodienst hin.

6. Die Prägestätte: MSA Device PUID (wlidsvc)

[STATIC] C:\Windows\System32\wlidsvc.dll, der Microsoft-Konto-/Passport (Windows Live ID)-Dienst, ist die einzige Identitäts-Binärdatei, die das Literal GlobalDeviceId enthält, und sie beherbergt die gesamte Gerätebereitstellungs-Maschinerie:

CDeviceIdentityBase::CreateNewDeviceIdentity / Provision / BindDeviceToHardware / GetDeviceCert
DeviceAssociateRequest      (Passport PPCRL SOAP -> login.live.com)
<ps:DevicePUID> ... </ps:DevicePUID>
DeviceIdStore::LogToRegistry
BCryptGenRandom / CCryptRandom::GenRandom     (device KEY, not the id)

Die Kennung ist eine Device PUID (Passport Unique ID), eine 64-Bit-MSA-Kennung. Das BCryptGenRandom darin erstellt den Geräte-Authentifizierungsschlüssel, den BindDeviceToHardware an die Maschine bindet, nicht die PUID.

6.1 Es wird serverseitig zugewiesen

[STATIC] Der Client zieht die PUID aus der SOAP-Antwort des Servers mit einem XPath in den Antworttext:

/S:Envelope/S:Body/ps:DeviceUpdatePropertiesResponse/HWPUIDFlipped

CAssociateDeviceRequest::ParseResponseBody und die zugehörigen ParseResponse-Methoden lesen Antwort-XML-Knoten in BSTRs. Der Ablauf ist also: Client stellt das Gerät bereit -> login.live.com weist die Geräte-PUID zu und gibt sie zurück -> Client speichert sie. Genau deshalb erzeugt eine Neuinstallation eine neue GDID (neue Bereitstellung, neue serverzugewiesene PUID) und warum es kein Hardware-Hash ist.

6.2 Es wird im Klartext gespeichert

[OBSERVED] Der Microsoft-Konto-Identitätsspeicher hält den Wert direkt in der Registry, in Ihrem eigenen Benutzer-Hive:

HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties
    LID = 0018XXXXXXXXXXXX

HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\{...}
    DeviceId = 0018XXXXXXXXXXXX

Byte für Byte derselbe Wert, den CDP live in DDS registriert hat. Ihre Benutzerkonten-PUID ist eine andere Nummer, die als puid = 0003... gespeichert ist (z.B. 00034002XXXXXXXX). Es gibt auch einen HKLM-Cache-Schlüssel, der nach der PUID benannt ist (HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache\<PUID>_<userSID>), aber der ist nur SYSTEM-zugänglich, also lesen Sie den Wert aus HKCU.

[!NOTE] Das Präfix verrät, was es ist. Benutzer-PUIDs sind der 0003-Klasse, Geräte-PUIDs sind der 0018-Klasse. Die GDID des Gerichts (0018000FC8CB93CC) liegt im 0018-Device-PUID-Raum, genauso wie meine.

6.3 Es authentifiziert die Graph-Endpunkte

[OBSERVED] Der MSA-Token-Cache (HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache\...) enthält Geräte-Token, die genau auf die Endpunkte begrenzt sind, die CDP verwendet:

scope=service::dds.microsoft.com::MBI_SSL_TOKEN_BROKER
scope=service::activity.windows.com::MBI_SSL_SA_TOKEN_BROKER

Der Microsoft-Kontodienst gibt also die Geräte-Anmeldeinformationen aus, die die DDS-Registrierung und die Aktivitäts-Uploads, die die GDID tragen, authentifizieren.

6.4 Die vollständige Kette

flowchart TD
    subgraph MSA["MSA identity layer: wlidsvc.dll"]
        A1["Provision device with login.live.com<br/>(Passport PPCRL SOAP)"] --> A2["Server assigns Device PUID<br/>&lt;ps:DevicePUID&gt; / HWPUIDFlipped"]
        A2 --> A3["Store DeviceId / LID = PUID<br/>HKLM\...\IdentityStore"]
        A3 --> A4["Issue device tokens for<br/>dds.microsoft.com and activity.windows.com"]
    end
    subgraph CDP["Device graph client: cdp.dll / CDPSvc"]
        B1["GetStableDeviceId -> receives PUID string"] --> B2["RegisterUserDeviceAsync -> DDS<br/>OBSERVED: HTTP 200"]
    end
    subgraph SRV["Server: Device Directory Service"]
        C1["Keys g:PUID to the MSA account,<br/>activity and IP history"]
    end
    subgraph REP["Reporting"]
        D1["Delivery Optimization -><br/>UCDOStatus.GlobalDeviceId"]
    end
    A4 --> B1
    B2 --> C1
    C1 --> D1

Alles, was die Beschwerde auf „die GDID" zurückführt – persistent pro Installation, überlebt Updates, neu bei Neuinstallation, an ein Microsoft-Konto gebunden, über IPs und Surfverhalten verfolgbar – alles ergibt sich daraus, dass es sich um eine serverseitig zugewiesene MSA Device PUID handelt, die CDP in den Gerätegraph einträgt.

7. Finden Sie Ihre eigene GDID

[OBSERVED] Auf einer Maschine, die bei einem Microsoft-Konto angemeldet ist, ein Registry-Read aus Ihrem eigenen Benutzer-Hive, kein Administrator erforderlich:

(Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID

Das gibt Ihnen Ihre Device-PUID als 16 Hex-Ziffern (z.B. 0018XXXXXXXXXXXX). Um sie in der g:<decimal>-Form zu sehen, wie sie serverseitig erscheint:

$hex = (Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID
"g:$([Convert]::ToUInt64($hex,16))"

Wenn ExtendedProperties\LID auf Ihrem Rechner leer ist, befindet sich derselbe Wert unter HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\{...}\DeviceId.

[!WARNING] Veröffentlichen Sie nicht Ihren eigenen Wert. Ihre Device-PUID, Ihre MSA-CID (0003...) und Ihre Benutzer-SID entanonymisieren Sie alle. Schwärzen Sie sie in jedem öffentlichen Bericht. Der einzige Wert, der sicher zitiert werden kann, ist der des Gerichts, da er bereits öffentlich ist.

8. Verringerung der Exposition

Die GDID existiert, weil Ihr Gerät in den Microsoft-Konto-Gerätegraph eingetragen ist und die Connected Devices Platform es synchron hält. Um sie zurückzuschneiden:

• Schalten Sie die Connected Devices Platform aus (CDPSvc, CDPUserSvc) und deaktivieren Sie den Aktivitätsverlauf (Einstellungen, Datenschutz, Aktivitätsverlauf), um die Graph-Synchronisation und die Aktivitäts-Uploads zu stoppen.
• Das Löschen von %LOCALAPPDATA%\ConnectedDevicesPlatform löscht nur den lokalen CDP-Status. Die PUID kommt sofort aus dem Identitätsspeicher zurück, also reicht das allein nicht.
• Eine Neuinstallation ergibt eine neue GDID (die Beschwerde sagt es), aber sie wird an eine frische gebunden, sobald sie sich erneut registriert.

9. Methodik (reproduzierbar)

All dies stammt von einer Standard-Windows-11-Maschine (Build 26200).

• Live-Erfassung: TraceLogging-ETW-Anbieter von CDP (Microsoft.Windows.CDP.*) mittels logman während einer frischen CDPSvc-Registrierung, dekodiert mit tracerpt.
• Registry und Token-Cache: IdentityStore und IdentityCRL unter HKLM\SOFTWARE\Microsoft.

ETW und statische Analyse sind das, was tatsächlich funktioniert hat. Ein Proxy wird nur Ihre Zeit verschwenden.

Microsoft.Windows.CDP.Core                    {7762de0c-b0a6-571a-68d3-c018bf009496}
Microsoft.Windows.CDP.Core.Error              {a1ea5efc-402e-5285-3898-22a5acce1b76}
Microsoft.Windows.CDP.CDS                     {dfa6e32a-095f-5f57-d025-0887d33507a1}
Microsoft.Windows.CDP.Aggr                    {bc1826c8-369c-5b0b-4cd1-3c6ae5bfe2e7}
Microsoft.Windows.CDP.AFS                     {5fe36556-c4cd-509a-8c3e-2a547ea568ae}
Microsoft.Windows.CDP.OnecoreAccountProvider  {4ee5bf9a-3e8f-540b-8bfb-12457a2854b6}
Microsoft.Windows.CDP                          {9f4cc6dc-1bab-5772-0c71-a89954718d66}

[!NOTE] NullZeroX auf Twitter hat mir mitgeteilt, dass GDID auch gesendet wird, unabhängig davon, ob Sie mit einem Microsoft-Konto auf Ihrem Gerät angemeldet sind. Ich bin mir nicht sicher, wie wahr das ist, aber es ist erwähnenswert.