GDID Windows – Coupez le mouchard qui vous traque même sous VPN

Comme je vous le disais tout à l’heure, en avril 2026, le FBI a coincé un membre présumé de Scattered Spider. Le mec planquait son trafic derrière un VPN, avec des IP dans trois pays différents. Et devinez quoi ? Ce n’est pas une fausse manip qui l’a balancé mais un identifiant que votre Windows se trimballe H24 et que Microsoft refile aux autorités quand elles le demandent : le GDID. Je vous en ai déjà causé
dans cet article
, et après avoir écrit l’article, je me suis demandé si on pouvait le virer.

Du coup j’ai monté une petite VM Windows 11 Pro et j’ai mis les mains dedans en me faisant assister de mon LLM préféré et voilà ce que j’ai trouvé. Ce qui marche, et surtout ce qui ne marche pas du tout, vous allez voir.

Déjà, faut comprendre ce qu’est ce GDID. C’est pas le numéro de série de votre carte mère, c’est pas un hash en lien avec votre matos. Non, c’est un PUID de 64 bits, c’est à dire un identifiant que les serveurs de Microsoft collent à votre compte dès que vous ouvrez une session Windows. Il est écrit en clair dans votre registre, votre machine l’enregistre dans un annuaire côté Microsoft, et un service le fait remonter peinard quand c’est nécessaire. Et si vous changez d’IP avec un VPN, bah lui il s’en fout. Le GDID ne bouge pas d’un poil.

Regardez votre propre mouchard en face

On commence par le voir de nos yeux. Ouvrez un PowerShell et collez ça :

$lid=(Get-ItemProperty 'HKCU:SOFTWAREMicrosoftIdentityCRLExtendedProperties').LID
"g:$([Convert]::ToUInt64($lid,16))"

Sur ma VM, ça m’a craché g:6755487812206045. Je ne vous le donne pas mais c’est celui que Microsoft peut raccrocher à tout ce que je fais. (En théorie, parce que c’est le code qui est associé à ma VM, donc je m’en fous).

Vous venez de lire l’étiquette qu’on vous a collée dans le dos.

Le supprimer ? Laissez tomber

Réflexe de base, on efface la clé dans la base de registres HKCU:SOFTWAREMicrosoftIdentityCRLExtendedProperties et hop, plus de mouchard. C’est ce que j’ai testé au début… J’ai shooté la valeur, redémarré le service qui s’en occupe, et là plus rien. Gagné ? Ben non. J’ai ouvert le Microsoft Store durant deux petites secondes, et le GDID est revenu. Et pas un nouveau, hein, LE MÊME !!

C’est ça qui est fou. C’est que votre GDID n’est pas planqué sur votre disque, il est planqué chez Microsoft, bien accroché à votre compte comme une moule à son rocher. Votre PC ne fait que le retélécharger encore et encore. Après si vous réinstaller tout, Windows vous donne un nouveau numéro, d’accord, mais l’ancien et tout ce qui y était rattaché restent tout de même bien au chaud sur leurs serveurs. Le passé, on le récupère jamais…

Couper la télémétrie ne change rien non plus

Un autre conseil qu’on voit partout, c’est de désactiver la télémétrie de Windows. Sur ma VM, le service de télémétrie classique était déjà à l’arrêt. Et pourtant mon GDID était là, bien lisible, et les services qui le font remonter tournaient à plein régime. Le mouchard ne passe pas par la télémétrie que vous croyez couper. Il passe ailleurs, par les services de la plateforme d’appareils connectés et de l’optimisation de distribution.

Vous pouvez donc cliquer sur tous les boutons vie privée des réglages, il s’en tape.

Fermer le robinet pour de vrai

Alors puisqu’on peut pas l’effacer, on va faire la seule chose qui est en notre pouvoir : L’empêcher de sortir. Et sans se déconnecter du compte Microsoft, histoire de garder un PC utilisable, hein.

Et pour ça, on a 2 leviers. Le premier, c’est de désactiver les services qui enregistrent et remontent les infos de votre machine. Le second, c’est de renvoyer les serveurs de Microsoft dans le décor simplement via le fichier hosts, comme ça même si les services qui mouchardent tournent, et bien ils ne peuvent plus joindre personne… Et surtout, on ne touche pas à login.live.com, sinon adieu la connexion à votre compte.

Toutefois, il y a un petit piège, vous vous en doutez… Le service qui fait remonter le GDID, DoSvc, refuse de se laisser désactiver par la voie normale. Même en admin, Windows vous balance “Accès refusé”. La parade, c’est donc de le désactiver direct dans le registre, où l’admin a le droit d’écrire là où le gestionnaire de services vous bloque.

Maintenant pour faire ça, plutôt que de vous mettre des tonnes de lignes de code à copier-coller, j’ai tout regroupé dans des scripts propres, que j’ai testés, avec une commande pour tout remettre comme avant.

Le projet est là :
no-gdid sur GitHub
. Vous lancez d’abord l’audit en lecture seule pour voir où vous en êtes, puis les scripts de blocage en mode aperçu, et seulement après avec l’option qui applique vraiment. Testez dans une VM avec un snapshot avant de faire ça sur votre vraie bécane, parce qu’on désactive quand même des services système. Et si vous voulez juste couper le réseau d’un process précis sans tout ce cirque, ce bon vieux
ProcNetBlocker
fait déjà une partie du taf.

Allez c’est parti mon canard !

Ouvrez un PowerShell en administrateur, et la première fois faites-le dans une VM avec un snapshot histoire de tester et de vous familiariser avec les commande. Etape 1, on clone le projet :

winget install --id Git.Git
git clone https://github.com/Korben00/no-gdid
cd no-gdid

D’abord on regarde sa propre situation. Cet audit est en lecture seule, il ne modifie rien, il vous affiche juste votre GDID et quels services de la chaîne tournent :

powershell -ExecutionPolicy Bypass -File .auditGet-GDID-Audit.ps1

Ensuite on regarde ce que la mitigation changerait, sans rien appliquer. Sans l’option -Apply, les deux scripts tournent en mode aperçu et se contentent de lister ce qu’ils feraient :

powershell -ExecutionPolicy Bypass -File .mitigateDisable-GDID-Services.ps1
powershell -ExecutionPolicy Bypass -File .mitigateBlock-GDID-Endpoints.ps1

Si ça vous va, on coupe pour de vrai. Cette fois on ajoute -Apply : les services qui enregistrent et remontent l’appareil sont désactivés, et les serveurs de Microsoft correspondants sont renvoyés dans le vide via le fichier hosts. Votre compte Microsoft, lui, reste connecté :

powershell -ExecutionPolicy Bypass -File .mitigateDisable-GDID-Services.ps1 -Apply
powershell -ExecutionPolicy Bypass -File .mitigateBlock-GDID-Endpoints.ps1 -Apply

Et pour tout remettre comme avant, une seule commande :

powershell -ExecutionPolicy Bypass -File .mitigateRevert-GDID.ps1

Une fois appliqué, tout redeviendra calme… les services d’enregistrement seront à l’arrêt, leurs serveurs injoignables, et votre compte Microsoft restera toujours connecté. Le GDID reste bien évidemment lisible sur le disque, mais il ne remontera plus chez Microsoft.

La vérité qui pique

Après, je ne vais pas faire un tuto qui vous vend du rêve. Ces manips réduisent ce que Microsoft pourra corréler à l’avenir mais elles n’effacent pas votre GDID, qui traîne sur leurs serveurs depuis votre toute première connexion, et elles ne vous rendent pas anonyme. Ensuite, passer en
compte local
comme j’ai pu le lire ailleurs supprime le chemin qu’on vient de bloquer, mais rien ne prouve encore qu’un identifiant anonyme ne prend pas le relais derrière.

La seule vraie parade solide pour une activité sensible, est plus brutale : ne pas faire cette activité sous Windows. Un Linux live par exemple offre un contrôle total de ce qui sort de votre machine. Le reste, c’est que de la réduction des dégâts, rien de plus.

Voilà, défendre sa vie privée, ça commence par savoir ce qu’on vous colle sur le dos et maintenant vous le savez. Pas merci Microsoft.

Source :
The Register
et le
reverse engineering de SmtimesIWndr
.