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.
das macht das programm schon wieder sehr sympatsuich, wenn automaitsch die ganzen nicht benötigten online dienst auch gar nicht erst funktionieren werden/würden.
Der Zugang wird dadurch nicht gesperrt. Es werden nur alle OAUTH 2.0 Token ungültig, die an die gelöschten GDIDs gebunden waren.
Man kann sich nur solange nicht mehr einloggen, wie login.live.com wegen dem Sperreintrag in der host Datei auf 0.0.0.0 bzw :: nicht erreichbar ist.
Löscht man diesen Eintrag in der host Datei kann man sich danach sofort wieder einloggen.
Dabei werden dann nicht nur eine sondern gleich mehrere neue GDIDs vom Server in der MSCloud zugewiesen. Eine für den Account des Devices selbst und bis zu mehrere pro unterschiedlichstem User am Gerät: System, Lokaler User, AD User, MicrosoftOnline User, Entra ID User etc.
Dadurch können auch mehrere GDIDs an jeden lokalen Account gebunden werden.
Löscht man seine GDIDs zu oft fängt man sich dafür aber eine Zeitstrafe für die Neuanlage ein und man muss sich danach unter Umständen auch speziell authorisieren. Passwort alleine wird dann gerne ungültig. Hat man keine Alternative angelegt steht man dumm vor der verschlossenen Tür.
Das alles kann einem auch passieren, wenn GDIDs von der anderen Seite in der MSCloud warum auch immer verworfen werden und dadurch neue GDIDs fällig werden.
Ist login.live.com beim nächsten Neustart des Gerätes wieder erreichbar werden spätestens dann neue lokale GUIDs für Device und System angelegt, damit das Gerät wieder aus der MSCloud erreichbar wird.
Nutzt man ein Gerät mehrere Monate lang nicht werden die lokalen GDIDs auch ungültig und man bekommt beim nächsten Neustart neue zugewiesen.
Genauso verhält es sich mit den GDIDs von MSOnline und Entra IDs. Sie werden nach ca. 60 Tagen ohne Nutzung ungültig und danach gibt es bei der ersten Anmeldung neue GDIDs dafür.
Warum sollte man in diesen Zeiten immer noch Wert darauf legen, ein Microsoft Konto bzw. Cloudfunktionen und all das zu nutzen? Gerade das Gegenteil sollte der Fall sein, wenn man eigenständiges Denken nicht vollständig aufgegeben hat.
In welchen Zeiten?
In den Zeiten wie die USA mit dem Rest der Welt umgeht?
Die Hoffnung stirbt zuletzt, dass sich das nach dieser Amtszeit wieder reguliert, so ganz happy scheinen die Amerikaner ja nicht mehr zu sein.
Ansonsten sollte man doch mal einen Blick weiter über den Tellerrand werfen, denn wenn man keine Services oder Anbieter aus den USA nehmen möchte/sollte, dann hat man doch einiges zu tun.
Zur allgemeinen Äußerung der Microsoftnutzung, das bezieht sich dann auch auf Apple und Google/Android und was bleibt dann noch?
Linux OK, aber da ist auch nicht alles Gold was glänzt…
Du hast die Problematik erkannt. Es bleibt derzeit praktisch nichts. Man hat sich erfolgreich in diverse alternativlose Abhängigkeiten begeben. Und Microsoft/Apple/Google/… Konten bzw. Cloudfunktionen und all das wenigstens schrittweise eben nicht mehr zu nutzen, wäre der Beginn des Beginns, mit dem man anfangen könnte, wenn man wollen würde.
Ich habe zwar einen Microsoft und Google Account aber nutzen tue ich die eher eingeschränkt, zumal es ja auch nie ganz sicher ist, ob mit einer Richtlinienänderung seitens der Anbieter plötzlich irgendwelche Inhalt illegal sind und ich nicht mehr auf meinen Account zugreifen kann.
Im Übrigen mache ich mir nicht erst seit einem halben Jahr Gedanken über die Außenpolitik der USA, inkl. Microsoft, Google, Meta und die ganzen anderen Firmen, das war und ist vor 10 oder 20 Jahren schon dieselbe gewesen.
Nur es wird nicht besser, insofern versuche ich dort so wenig wie nichts zu speichern.
Die USA sind ein schönes als Land, einige Leute sind sehr nett und freundlich und andere sind Arschlöcher genau wie bei uns im Übrigen auch.
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?
Träum weiter…
[ ] du hast die Ironie verstanden
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.
"M365, OneDrive, Outlook Online, Teams, Store, XBOX etc gehen dann nicht mehr," … und besser kann es kaum kommen, denn solcherlei Abfall ist ohnehin obsolet.
Aktualisierungen (Updates) sind hingegen kein Problem – so muß das sein.👍
"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."
Ich denke das ist so nicht ganz richtig: durch das Skript wird die GDID auf dem PC gelöscht, und somit eine evtl. bestehende Verknüpfung des PCs zu einem Micro$oft-Konto getrennt.
Die Anmeldung am Konto selbst sollte aber weiterhin mit den vergebenen Zugangsdaten möglich sein.
Eine Anmeldung an einem Microsoft-Online-Konto benötigt aber die URL login.live.com und das Script trägt dieselbe URL in die hosts ein, wodurch diese URL auf die IP 0.0.0.0 umgeleitet, also gesperrt wird.
😍😍😍
# BEGIN degdid-registration-block
0.0.0.0 login.live.com
:: login.live.com
0.0.0.0 account.live.com
:: account.live.com
0.0.0.0 cs.dds.microsoft.com
:: cs.dds.microsoft.com
0.0.0.0 dds.microsoft.com
:: dds.microsoft.com
0.0.0.0 aad.cs.dds.microsoft.com
:: aad.cs.dds.microsoft.com
0.0.0.0 fd.dds.microsoft.com
:: fd.dds.microsoft.com
0.0.0.0 cdpcs.access.microsoft.com
:: cdpcs.access.microsoft.com
0.0.0.0 ztd.dds.microsoft.com
:: ztd.dds.microsoft.com
0.0.0.0 activity.windows.com
:: activity.windows.com
0.0.0.0 assets.activity.windows.com
:: assets.activity.windows.com
0.0.0.0 edge.activity.windows.com
:: edge.activity.windows.com
# END degdid-registration-block
Im Artikel sind ein paar Einschränkungen erwähnt:
Die Entfernung der GDID wird abgelehnt, wenn der PC Mitglied in einer verwalteten Umgebung ist, d.h. Domäne, M365, etc.
Das Script legt ein Backup an.
D.H., wenn etwas nicht mehr funktioniert, Backup zurückspielen und alle GDID-Einträge werden wieder hergestellt.
Ja, in dem TomsHardware-Artikel steht:
"This script also only works on unmanaged systems with admin accounts. If you're part of an organization or domain, deGDID will refuse to run. More importantly, though, since it blocks Microsoft's DeviceAdd pipeline, some core Windows services will break because they'll fail to authenticate your Microsoft account."
weiter unten steht allerdings folgendes:
"Account verification through login.live.com was also blocked across all browsers, though login.microsoftonline.com still worked. Online games and other apps continued to behave normally as well."
Das habe ich noch nicht ganz verstanden.
Ersetzt login.microsoftonline.com die URL login.live.com, so dass die Anmeldung am Microsoft-Konto damit funktioniert, ohne die GDID zu prüfen bzw zu schreiben?
Gilt das auch für M365, Outlook Online, Teams, OneDrive?
login.live.com – microsoft live services; e.g.: outlook
login.microsoftonline.com – enterprise log-ins (office 365)
*https://www.reddit.com/r/microsoft/comments/17x3pq5/comment/k9llmd5/
—
A)
live.com
[…]primary authentication gateway for personal Microsoft accounts.
Who it is for:
Individual users with email addresses ending in @outlook.com, @hotmail.com, @msn.com, or @live.com.
Common use cases:
Outlook personal email
OneDrive Personal
Xbox accounts
Skype
Microsoft Rewards (earning points is almost a daily grind for many users)
B)
microsoftonline.com
If your browser redirects to microsoftonline.com, you are using a work or school account. This domain is the entry point to Microsoft's enterprise identity platform, now called Microsoft Entra ID.
Who it's for:
Users on Microsoft 365 Business, Enterprise, or Education plans.
Common use cases:
Corporate email login
Azure portal access
SharePoint collaboration
Microsoft Teams (business edition)
*https://www.adspower.com/blog/microsoft-live-microsoftonline-login
—
Laut folgendem Link braucht M365 beide URLs login.live.com und login.microsoftonline.com:
"Authentication chains: Signing into any M365 service triggers a chain of DNS lookups across login.microsoftonline.com, login.live.com, Azure AD endpoints, and conditional access policy servers. If any link in this chain is blocked, authentication fails"
*https://cleanbrowsing.org/support/troubleshooting/microsoft-365-dns-filtering
—
Das Script deGDID.ps1 blockiert im Fall:
1. [nicht verwaltete Computer, privat] die erste URL, aber nicht die zweite URL.
2. [verwaltete Computer, geschäftlich] keine der beiden URLs, weil das Script sich selber vorzeitig beendet.
Wenn M365 beide URls braucht, dann funktioniert M365 im Fall (1) nicht mehr.
Im Fall (2) wird die GDID weiterhin wie vorher gesendet, geprüft und geschrieben.
Daraus kann man schließen, dass TomsHardware die Funktionalität von M365 nach erfolgreichem Durchlauf des Scripts deGDID.ps1 gar nicht getestet hat und im Fall (2) die intakte GDID nicht bemerkt hat oder ebenfalls diese nicht gestestet hat.
Einfach die Verbindungen zu MS in der Firewall sperren(am besten eine exteren Hardwarefirewall) und die GDID kann dir egal sein! Hat den Vorteil brauchst du MS Konto & Co. doch mal, hebst du temporär die Sperre auf… funnktioniert genauso gut aber ohne sich die Nachteile des Scripts einzufangen…
hast du hier vielleicht eine empfehlung? ggf auch etwas was auf openwrt läuft?
openwrt sollte eigentlich direkt eine Firewall inkludiert haben…(netfilter/iptables)
Bolko es sollte klar sein, das es einen neuen unbenutzten MS-Key benötigt der niemals Online war für eine erfolgreiches „Blockieren" der GDID und selbstverständlich auch eine „Offline" Windows Aktivierung, so wie schon bei „XP" als letztes erfolgt und diesen "zehn-elf-Keygen+patch" gibt es zur Zeit nur in einem sehr kleinem Kreis und nicht in „the Wild" soweit mir bekannt.
Das hat mit den Lizenzen selbst nichts zu tun. Es ist eine völlig eigene Baustelle.
Auch mit neuen GDIDs funktioniert alles nach einiger Zeit wieder.
Man muss sich damit aber z. B. auch einmal im Onlinekonto anmelden, damit M365 wieder rund läuft. Und werden dadurch zu viele Geräte benutzt kann es bis zum Timeout der alten GDID auch mal dauern.
Beim Scattered Spider-Fall war er am Flughafen direkt im Internet.
Er wusste nur nicht, dass die an der GDID des Laptop selbst und nicht ihm dran waren. Er fühlte sich deshalb sicher, solange er nicht bei Microsoft eingeloggt war.
Die GDID des Device selbst regelmäßig ändern macht mehr als Sinn. Genauso wie die WLAN MAC.
Als Schutz vor dem bösen Peter Strokes. Das Böse ist immer und überall.
Auf die MAC-Adresse der Netzwerkkarte des Rechners kommt es an. Für Windows-Systeme (bis hin zu Windows 11) gibt's eine kleine Software (SMAC 2.7/2.0 MAC Address Changer > https://smac-tool.com/ [SMAC 2.0/2.7 License Professional/Standard Edition = Free]), mit der die MAC-Adresse der Netzwerkkarte (nicht nur vom Hostrechner, sondern auch die eines Gastrechners) sehr leicht/komfortabel "geändert" (bzw. vorgetäuscht) werden kann. 😉
Lol das geht bei jeder Realtek im Gerätemanager wenn man die Karte aufruft. Viele Treiber können das von Haus aus. Was braucht man ein Tool dafür mit einer "Lizenz"? Lasst euch nicht abschröpfen.
Wer lesen – und noch wichtiger – auch verstehen kann, ist klar im Vorteil … engl. [License is]"Free" = in deutscher Sprache: [Lizenz ist]"frei" (in dem Fall beim Hersteller – Kopieren und Einfügen). 😉
Es wird also niemand "abgeschröpft", ganz im Gegenteil. Wenn Sie also wieder einmal etwas behaupten, wollen Sie doch bitte zuvor prüfen, ob's auch stimmt. Vielen Dank für Ihr Verständnis – sofern eventuell vorhanden.
Ja oke, wer lesen kann ist klar im Vorteil. Geht bei mir mit Windows-Boardmitteln seit Jahren in jedem Treiber ohne Frickeltool. Gibt Leute die nicht jedes Tool laden, weil sie ihr OS kennen und dessen Funktionalität. Danke war alles. Das Glashaus ist heute sehr dunstig.
Im übrigen free != libre. Free as in "free beer", not as in free software. Ohne Quelltext und FSF-Lizenz (echte Lizenzen) lade ich da nichts.
Lösung!
wenn man sich erst gar nicht mit einem Online Konto anmeldet, also nur mit einem lokalen Konto, wird die GDID erst garnicht erstellt.
Bei der Windows installation einfach mit Shift+F10 die CMD öffnen und dort jeh nach Windowsversion: oobe\BypassNRO oder start ms-cxh:localonly
Und schon kann der online Account-Zwang legal umgangen werden.
Diese Befehle stammen von Microsoft selbst :- ))
Selbst ohne Microsoft-Konto ist früher oder später eine GDID vorhanden. Nur, wenn alles ordentlich entseucht und blockiert ist, ist GDID-mäßig Ruhe. Ob deGDID auch Versions-Änderungen übersteht, bleibt noch abzuwarten und ggfs. deGDID im Bedarfsfall erneut auszuführen.
Die deGDID-Maßnahme hat die erste Versions-Änderung (KB5121003 > 26100.9168) ohne Einbußen ihrer Wirkung überstanden.
Wann hast du zum letzen Mal diese Methoden ausprobiert? :-)
Microsoft forciert die Anmeldung mit Account zumindest bei den Home Editionen. Die letzten Male ist es mir nicht mehr gelungen, an einem MS Account vorbei zu kommen.
Wie schon von Klartext erwähnt, würde ich nicht darauf vertrauen, dass du damit keine GDID mehr bekommst. Wer sich am Tracking stört, darf nicht erwarten, dass man Windows dauerhaft trackingfrei konfigurieren kann. Da hilft leider nur ein anderes Betriebssytem zu nutzen.