Microsoft vergibt in Windows eine eindeutige GDID genannte Kennung, über die Nutzer identifiziert werden können. Der VPN-Anbieter Windscribe hat nun ein Skript entwickelt, um das versteckte GDID-Tracking von Microsoft unter Windows zu blockieren. Das Script deGDID löscht vorhandene Identifikatoren und verhindert die Erstellung neuer Identifikatoren.
Rückblick auf den Scattered Spider-Fall
Bereits im Januar 2024 hatten US-Strafverfolger einen 19 Jährigen, mit Namen Peter Strokes, aus den USA als Mitglied der Hackergruppe Scattered Spider verhaftet. Anfang Juli 2026 wurde durch Gerichtsdokumente bekannt, wie die Ermittler dem Hacker auf die Schliche kamen.
Der Hacker Peter Stokes verwendete für seine Aktivitäten zwar ein VPN-Netzwerk und ließ dessen Verbindungen über drei Länder laufen, um die Aktionen zu verschleiern. Aber er machte den Fehler, Microsoft Windows für seine Hacks zu verwenden. Und Windows verknüpfte die dem Rechner zugewiesene eindeutige "Global Device Identifier" (GDID) in seinen Telemetrie-Daten, die an Microsoft übermittelt werden.
Ich hatte im Blog-Beitrag Scattered Spider-Mitglied Peter Stokes durch Windows GDID identifiziert und überführt über den Sachverhalt berichtet. Seit diese Informationen öffentlich sind, denken viele Leute darüber nach, wie der von Windows vergebene "Global Device Identifier" (GDID) entfernt oder neu generiert werden kann.
"deGDID" entfernt GDID in Windows
Mir ist die Nacht bereits nachfolgender Tweet von Tom's Hardware untergekommen, der auf das Script "deGDID"und den Artikel VPN provider built a script to block Microsoft's hidden GDID tracking on Windows — Windscribe's "deGDID" erases existing identifiers and blocks new ones from being created hinweist.
Weiterhin hat ein Blog-Leser in diesem Kommentar auf das Script hingewiesen (danke dafür). Das Projekt deGDID läuft bereits seit Mitte Juli 2026 auf GitHub. Der Entwickler bezeichnet das Ganze als "Forschung und praktische Absicherung" für den Global Device Identifier (GDID) von Microsoft. Dieser ist eine von Microsoft beim Setup von Windows zugewiesene Installationskennung. Windows kann diese Kennung auch dann abrufen, wenn der interaktive Benutzer nur über ein lokales Konto verfügt.
Der Entwickler von deGDID hat nun ein PowerShell-Script degdid.ps1 erstellt, welches auf einem unterstützten Windows-Zielsystem die tatsächlichen, vom Server vergebenen, GDID-Statusdaten aus den bekannten lokalen Speichern entfernt. Gleichzeitig soll der DeviceAdd-Pfad dauerhaft blockiert werden. Der Entwickler betont, dass das keine finale Sperre sei, um irgendwo das Einfügen einer GDID durch Microsoft zu verhindern.
Windscribe hat das Projekt im Blog-Beitrag Windows Tracks You With a Hidden ID. So We Built deGDID to Block It vom 27. Juli 2026 näher beschrieben. Der Einsatz erfolgt auf eigene Gefahr, und es heißt im Blog-Beitrag, dass bestimmte Cloud-Funktionen, die von der GDID abhängen, durch die Entfernung beeinträchtigt würden. In diesem Kommentar hat ein Blog-Leser ein Anwendungsprotokoll des Scripts für sein System dokumentiert.
MVP: 2013 – 2016
Kann man damit Gefahr laufen, dass einem die Windows-Aktivierung/Lizenz kaputt geht? Ist die deGDID nicht auch damit und einem Microsoft-Konto verknüpft, sofern vorhanden? Sind diese Fragen geklärt und kann das ausgeschlossen werden? Welche Cloudfunktionen genau werden eingeschränkt, um eine eigene Risiko-Abschätzung durchführen zu können? Wenn man Wert darauf legt, all das zu nutzen, sollte man sehr vorsichtig mit der Nutzung solcher Manipulationen sein.
Ja, die GDID ist mit dem Microsoft-Konto verknüpft und die GDID wird auch auf den Microsoft-Servern gespeichert.
Durch das deGDID Script wird der Zugang zum Microsoft-Online-Konto gesperrt, man kann sich also nicht mehr einloggen und die Microsoft-Online-Dienste funktionieren nicht mehr.
Das bedeutet, dass du dieses Script nicht ausführen solltest, da du das Microsoft-Konto für deine Programme brauchst.
Ach wie schön. Nur das Script ausführen und ich bin wieder anonym im Netz unterwegs ;)
Denke nicht, dass dies das Anliegen des Skripts bzw des Beitrags ist…?
Wenn die EU jede Website mit Tracking-Cookie-Warnungen überzogen haben will, warum dann nicht Windows?
Aktiviert windows dann noch? Entfernt mal die aktivierung mit rearm.cmd, dann lasst mal dieses tolle PWSH drüber laufen und versucht mal zu aktivieren.
Uuups..
Wenn man folgende URLs blockt, dann kann man sich nicht mehr an einem Microsoft-Online-Konto anmelden:
login.live.com
account.live.com
siehe auch:
"And above all, we leave login.live.com alone, otherwise goodbye Microsoft account login."
*https://korben.info/en/gdid-windows-cut-tracker-vpn.html
(Artikel zur GDID vom 08.Juli 2026)
Im Script degdid.ps1 selber steht das auch im Kommentar:
"Blocking login.live.com intentionally breaks or degrades MSA, Store, Xbox, OneDrive sign-in, Phone Link, and related identity features."
Also einfach alles blocken bezüglich GDID so wie es das Script macht funktioniert nur mit schweren Nebenwirkungen bzw dann nur noch mit lokalem Konto.
M365, OneDrive, Outlook Online, Teams, Store, XBOX etc gehen dann nicht mehr, denn dafür muss man sich mit sienem MS-Account einloggen.
Wenn man sich online einloggt, dann ist es auch egal, ob man vorher in seiner Registry die GDID gelöscht hatte, denn Microsoft erkennt den Computer trotzdem und trägt die selbe GDID wieder in die Registry ein.
2.
Mark Heitbrink schrieb mehrmals, dass man einfach nur die beiden Dienste DiagTrack ("Benutzererfahrungen und Telemetrie im verbundenen Modus") und WerSvc ("Windows-Fehlerberichterstattungsdienst") abschalten müsse, um die Telemetrie zu sperren.
Bezüglich GDID stimmt das leider nicht und die GDID ist auch eine Art von Telemetrie, die allerdings unabhängig von den normalen Telemetrie-Diensten ausgeführt wird.