What is really behind the Windows ‘GDID’

In the Gerichtsdokumenten des US-Justizministeriums gegen mutmaßliche Mitglieder der Hacker-Gruppe Scattered Spider tauchte Anfang des Monats ein Begriff auf, der in der Tech-Szene für ordentlich Wirbel gesorgt hat: Die Global Device Identifier (GDID).

Auf Twitter/X hieß es sofort schockiert: „Microsoft spioniert uns mit einem unlöschbaren 128-Bit-Hardware-Fingerabdruck aus, der aus Seriennummern generiert wird!“

Kurze Antwort: Falsch. Lange Antwort: Die Wahrheit ist technisch extrem spannend, unterscheidet sich aber deutlich vom Social-Media-Halbwissen. Werfen wir dafür einen Blick unter die Haube von Windows 11.

Myth-Busting: Was die GDID wirklich ist

Werfen wir einen Blick auf das oben verlinkte Gerichtsakten-Verfahren (United States v. Peter Stokes). Dort taucht die GDID konkret im Format g:6755467234350028 auf.

Wenn man diese Zahl von Dezimal in Hexadezimal umrechnet, erhält man 0x0018000FC8CB93CC.

Keine 128 Bit: Das ist eine schlichte 64-Bit-Zahl.
Kein Hardware-Seriennummern-Hash: In der Gerichtsakte steht explizit, dass eine Neuinstallation von Windows eine völlig neue GDID erzeugt. Wäre die ID aus festen Seriennummern deiner GPU oder deines Mainboards berechnet, bliebe sie nach einem Formatieren identisch.

Was ist die GDID also wirklich? Schlicht die Device PUID (Passport Unique ID) deines Microsoft-Accounts? Dazu müssen wir bissl tiefer graben.

Wie funktioniert das Identitäts-Chaos in Windows?

Stell dir dein Windows-System wie ein Hotel vor:

wlidsvc.dll (Der Rezeptionist): Wenn du dich mit deinem Microsoft-Konto anmeldest, ruft dieser Dienst beim Microsoft-Server (login.live.com) an und sagt: „Hey, ich bin eine neue Windows-Installation, gib mir mal einen Pass!“ Der Server generiert eine eindeutige Nummer (die Device PUID) und schickt sie zurück.
Registry (Der Tresor): Das Windows-System schreibt diesen Pass unverschlüsselt in deinen lokalen Tresor (die Registry).
cdp.dll (Der VIP-Manager): Der Connected Devices Platform Service schnappt sich diese Nummer aus dem Tresor und meldet das Gerät im weltweiten Microsoft-Netzwerk an (Device Directory Service). Dadurch wissen Features wie Phone Link or the Zwischenablage-Synchronisierung, welches Gerät gerade online ist.
dosvc.dll (Der Statistiker): Die Delivery Optimization (Übermittlungsoptimierung für Updates) liest die ID ab und hängt sie an Telemetrie-Daten an.

In short: Die GDID wird nicht lokal aus deiner Hardware berechnet, sondern vom Microsoft-Server beim Registrieren zugewiesen.

Der Weg der GDID durch das System

Der gesamte Stack sieht von unten nach oben so aus:

Plaintext

[ Microsoft Server (login.live.com) ]
                │  (weist Device PUID zu)
                ▼
[ wlidsvc.dll ] (Microsoft Account Service)
                │  (speichert ID in Registry)
                ▼
[ HKCU Registry ]
                │  (Liest ID aus)
                ▼
[ cdp.dll ] (Connected Devices Platform)
                │  (Meldet Gerät an DDS)
                ▼
[ Delivery Optimization / Telemetrie ] 
                   (Spuckt UCDOStatus.GlobalDeviceId aus)

Selbst wenn man keinen Microsoft-Account nutzt, greift die Connected Devices Platform (CDP) auf einen anonymen Geräte-Pfad zurück, um eine vergleichbare Kennung zu verwalten.

Finde deine eigene GDID (Do It Yourself)

Du willst wissen, wie deine eigene GDID aussieht? Wenn du mit einem Microsoft-Account eingeloggt bist, brauchst du dafür nicht einmal Admin-Rechte. Ein einfacher PowerShell-Befehl reicht aus:

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

Das Ergebnis spuckt dir genau das Format g:<Dezimalzahl> aus, das auch in den Gerichtsakten der FBI-Ermittler zu finden war.

Important note: Poste deine GDID niemals öffentlich in Foren oder Screenshots! Zusammen mit deiner User-SID oder deiner Account-ID lässt sich dein Gerät damit eindeutig identifizieren.

Wird man das Teil auch wieder los?

Da die GDID serverseitig vergeben und lokal in der Identity-Struktur verankert ist, hilft das bloße Löschen lokaler Cache-Ordner wenig, denn die ID wird einfach neu aus der Registry gezogen.

Wer die Nachverfolgung minimieren möchte:

Connected Devices Services deaktivieren: Das Stoppen von CDPSvc and CDPUserSvc unterbricht die Synchronisation mit dem Microsoft Device Graph.
Aktivitätsverlauf abschalten: In den Windows-Einstellungen unter Datenschutz & Sicherheit -> Aktivitätsverlauf.
Reinstallation: Erzeugt zwar eine völlig neue GDID, verknüpft diese beim nächsten Log-in aber sofort wieder mit deinem Microsoft-Konto.

Ein interessantes Experiment dazu findet sich beispielsweise auch in der detaillierten Sammlung auf Github und it-connect.tech zu dem Thema:

Appendix: Deep-Dive, Blockade & Kollateralschäden

Wer den genauen Weg der GDID durch das System nachvollziehen oder die Übertragung unterbinden möchte, findet hier die technischen Details unter der Haube.

Deep-Dive: Wie die GDID in der `wlidsvc.dll` geschmiedet wird

Wer noch tiefer ins Binary-Gewebe schauen möchte: Die wlidsvc.dll (Microsoft Account / Passport Service) ist der einzige Identitäts-Dienst in Windows, der den Begriff GlobalDeviceId im Klartext enthält. Hier sitzt die komplette Logik für das Device-Provisioning:

Der Zufallsschlüssel ist nicht die ID: Wenn man sich den Code anschaut, findet man Aufrufe wie BCryptGenRandom or CCryptRandom::GenRandom. Das erzeugt allerdings not die GDID selbst, sondern lediglich den lokalen Geräteschlüssel (Device Key), den BindDeviceToHardware nutzt.
Server-Zuweisung via SOAP: Der Client schickt einen DeviceAssociateRequest (Passport PPCRL SOAP) an login.live.com. Die Antwort enthält die XML-Struktur <ps:DevicePUID>.
Klartext-Parsing: Die Methode CAssociateDeviceRequest::ParseResponseBody liest den Wert per XPath direkt aus dem Response-Body aus:

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

Registry-Persistence: DeviceIdStore::LogToRegistry legt die ID anschließend im Klartext in deiner User-Hive ab (HKCU).

Die Magie der Präfixe: `0018` vs. `0003`

Wenn du in deiner Registry unter HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties nach dem Wert LID suchst (oder unter ...\Immersive\production\Token\{...}\DeviceId), siehst du eine 16-stellige Hex-Zahl.

Anhand der ersten vier Stellen erkennst du sofort, womit du es zu tun hast:

0003... (User PUID): Identifiziert dein konkretes Microsoft-Benutzerkonto.
0018... (Device PUID): Das ist der Geräteraum, sprich deine GDID.

Der in den Gerichtsakten genannte Wert (0x0018000FC8CB93CC) liegt exakt in dieser 0018-Geräte-Klasse.

Wie sich das Gerät am Graph authentifiziert

Der Token-Cache von Windows (HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache\...) speichert gerätespezifische Tokens ab. Diese sind exakt auf die Endpunkte zugeschnitten, die der Connected Devices Platform Service (cdp.dll) ansteuert:

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

Der Microsoft-Account-Dienst liefert also nicht nur die ID, sondern gleich auch die passenden Zugangsdaten mit, um die Daten beim Device Directory Service (DDS) abzuliefern.

Kann man die GDID löschen oder blockieren?

Kannst du den Registry-Wert einfach löschen? Klar. Bringt das was? Nein.

Die GDID liegt schließlich nicht nur auf deinem PC, sondern ist bei Microsoft auf den Servern eingebrannt. Sobald sich deine Kiste das nächste Mal verbindet, zieht Windows die ID einfach wieder ab und schreibt sie zurück in die Registry. Wer die GDID wirksam bekämpfen will, muss nicht am Betriebssystem rumschrauben, sondern im Netzwerk ansetzen.

Hier gibt es nach aktuellem Kenntnisstand zwei Wege, die zum Ziel führen. Ohne Einschränkungen geht es aber nicht. Du kannst lediglich wählen, wie viel Kollateralschaden du in Kauf nehmen willst.

Weg 1: Die Kernfusion (die GDID-Erstellung komplett verhindern)

Wenn du das Entstehen der GDID von vornherein blockieren willst, müsste die Kommunikation gar nicht erst stattfinden. Um die Übermittlung also zu blockieren müsstest du login.live.com auf Netzwerkebene aussperren.

Der Effekt: Wenn du eine frische Windows-Installation direkt über einen DNS-Blocker laufen lässt, wird keine GDID bei Microsoft registriert. Aus Microsoft-Sicht existiert dein PC schlicht nicht.
The hook: login.live.com ist das Nadelöhr für das gesamte Microsoft-Konto. Blockst du das, fliegen dir Microsoft Store, OneDrive, Microsoft 365 und sämtliche MS-Account-basierten UWP-Apps um die Ohren.

Weg 2: Die Präzisionsbombe (nur das Reporting unterbrechen)

Du lässt die Generierung zu, kappst aber die Telemetrie- und Sync-Wege von Windows. Dabei bleiben login.live.com erreichbar, aber die Auswertungs- und Synchronisationsdienste werden abgeklemmt.

Wer Pi-hole, AdGuard Home oder einen Technitium-DNS betreibt, kann das elegant mit Wildcards auf Netzwerkebene lösen (die hosts-Datei unter Windows packt leider keine Wildcards *).

Regel-Set am Beispiel von AdGuard Home:

||login.live.com^$dnsrewrite=0.0.0.0
||dds.microsoft.com^$dnsrewrite=0.0.0.0
||cdpcs.access.microsoft.com^$dnsrewrite=0.0.0.0
||do.dsp.mp.microsoft.com^$dnsrewrite=0.0.0.0
||activity.windows.com^$dnsrewrite=0.0.0.0

(Hinweis: ||do.dsp.mp.microsoft.com^ erschlägt direkt die gesamte Delivery-Optimization-Ebene inklusive aller regionalen Subdomänen).

Wer das Ganze lokal automatisieren möchte, ohne ständig am DNS zu drehen, kann sich das Open-Source-Skript no-gdid (MIT-Lizenz) ansehen. Das Skript deaktiviert die Dienste CDPSvc, CDPUserSvc and DoSvc und biegt deren Endpunkte um, während der MS-Account-Login intakt bleibt. (Vorher unbedingt ein Backup oder einen VM-Snapshot machen!)

Welche Windows-Dienste brechen weg? (Übersicht)

Jeder DNS-Block fordert seinen Tribut. Hier ist die Übersicht, was passiert, wenn du an den Stellschrauben drehst:

Blockierte Domain	Rolle in der GDID-Kette	Was funktioniert danach nicht mehr?
`login.live.com`	GDID-Bereitstellung & Login-Token	Massiv: MS-Konto, Store, OneDrive, Office 365, Account-UWP-Apps.
`dds.microsoft.com` `cdpcs.access.microsoft.com`	Registrierung im Device Graph (DDS)	Komfort: Smartphone-Link (Phone Link), „Auf PC fortsetzen“, Cloud-Zwischenablage, Freigabe in der Nähe.
`do.dsp.mp.microsoft.com` (+ Subdomains)	Delivery Optimization Reporting	Gering: P2P-Verteilung von Updates & Store-Inhalten. Windows Update fällt sauber auf Direkt-Downloads zurück.
`activity.windows.com`	Activity history	Minimal: Unter Windows 11 vernachlässigbar, da die Zeitleiste (Timeline) eh gestrichen wurde.

Randnotiz zum Microsoft Store: Wenn nur die Reporting-Domains blockiert sind, verhält sich der Store manchmal etwas zickig. Downloads schlagen beim ersten Versuch fehl, gehen nach zwei, drei Versuchen aber meistens durch.

Kein Toggle, keine Zustimmung

Das frustrierende an der GDID ist das völlige Fehlen von Transparenz: Es gibt keinen Schalter, keinen Consent-Screen und keine wirkliche Dokumentation seitens Microsoft. Nachtrag: Es gibt doch zumindest ein Dokument in dem die GDID vorkommt. Allerdings mit einer dürftigen Beschreibung:

Microsoft global device identifier. This is a identifier used by Microsoft internally.

Natürlich nutzen auch andere Betriebssysteme eindeutige Kennungen: Apple hat die Hardware-UUID/DSID, Linux-Distros nutzen die /etc/machine-id. Der feine Unterschied: Unter Linux oder macOS kann man diese IDs 1) einsehen oder/und 2) mit Bordmitteln steuern.

Windows versteckt die GDID komplett vor dem Nutzer. Die üblichen „Datenschutz“-Schieberegler in den Windows-Einstellungen haben auf das Übertragen der GDID nach bisherigen Erkenntnissen jedenfalls keinerlei Auswirkung.

conclusion

Die GDID ist kein ominöser, tief im Silizium versteckter Spionage-Chip, sondern schlicht ein serverseitig vergebener Token für Microsofts Geräte-Ökosystem. Okay, zugegeben, ist jetzt nicht viel besser.

Dass Strafverfolgungsbehörden solche IDs nutzen, um verdächtige Aktivitäten (wie ngrok-Tunnel oder VPN-Verbindungen) einem bestimmten System zuzuordnen, wenn dies vorhanden und nutzbar ist, zeigt einmal mehr:

Anonymität im Netz erfordert fundiertes Wissen darüber, wie moderne Betriebssysteme nach Hause telefonieren.