Vor einiger Zeit wurde Peter Stokes als mutmaßliches Mitglied der Cybergang Scattered Spider in Finnland verhaftet und ist inzwischen in die USA ausgeliefert worden. Aus Gerichtsdokumenten geht nun hervor, dass die von Windows vergebene eindeutige GDID, per Telemetrie – samt weiteren Daten – an Microsoft übertragen, Stokes bei seinen Aktivitäten, die er bestmöglich verschleierte, verraten und zu seiner Identifizierung geführt hat.
Rückblick auf Scattered Spider
Hier im Blog hatte ich die Aktivitäten der Hackergruppe Scattered Spider, die in Sicherheitskreisen auch unter dem Namen UNC3944 geführt wird, nicht thematisiert. Laut Wikipedia scheint die Gruppe möglicherweise im Mai 2022 gegründet worden zu sein, um Angriffe per SIM-Swapping auf Telekommunikationsunternehmen auszuführen. Dort wurden auch MFA-Fatigue-Angriffe und Phishing per SMS und Telegram verwendet.
Im September 2023 soll die Hackergruppe hauptsächlich aus Personen im Alter von 19 bis 22 Jahren bestanden haben. Bekannt wurde die Gruppe, so die Wikipedia, durch das Hacken von Caesars Entertainment und MGM Resorts International, zwei der größten Kasino- und Glücksspielunternehmen in den Vereinigten Staaten. Den MGM-Hack hatte ich im Blog-Beitrag MGM Resorts International Opfer eines Cyberangriffs: Spielcasinos, Webseiten und Dienste down angesprochen – wobei dort die Gruppe ALPHV/BlackCat genannt wurde.
Zwischenzeitlich wurde die Gruppe wohl Teil einer einer größeren globalen Hackergemeinschaft, die als "the Community" oder "the Com" bekannt ist. Zudem scheinen sich die Mitglieder bei Hacks auch den Werkzeugen von Ransomware-as-a-service-Anbietern zu bedienen.
Identifizierung und Verhaftung von Mitgliedern
Bereits im Januar 2024 hatten US-Strafverfolger einen 19 Jährigen aus den USA als Mitglied der Gruppe verhaftet. Im Juni 2024 hatte ich im Blog-Beitrag Mutmaßlicher Kopf von Scattered Spider in Spanien verhaftet über die Festsetzung eines der führenden Mitglieder dieser Gruppe in Spanien berichtet. Es soll sich beim Verhafteten um den 22-jährigen Schotten Tyler Buchanan handeln.
Im Juli 2025 wurden vier Verdächtige in Großbritannien verhaftet (siehe meinen Beitrag Vier Verdächtige in Großbritannien wegen Co-op-, Marks & Spencer- und Harrods-Hack verhaftet). Und im September 2025 berichtete ich im Beitrag Zwei mutmaßliche Mitglieder von Scattered Spider verhaftet, dass die britische National Crime Agency (NCA) die Verhaftung zweier männlicher Personen bekannt gegeben. Es handelt sich um den 19-jährigen Thalha Jubair aus East London und den 18-jährigen Owen Flowers aus Walsall, West Midlands. Beide wurden ebenfalls die Beteiligung von Angriffen der Gruppe Scattered Spider zur Last gelegt.
Zum 1. Juli 2026 ist mir dann obiger Tweet untergekommen, der sich mit Peter Stokes befasst. Das US-Justizministerium (DOJ) hatte bekannt gegeben, dass der 19 jährige Peter Stokes, ein US-estnischer Doppelstaatsbürger und mutmaßliches Mitglied der Cyberkriminalitätsgruppe "Scattered Spider", aus Finnland ausgeliefert und im Northern District of Illinois wegen Verschwörung, Computerhacking und Betrugs angeklagt wurde.
Peter Stokes war bereits im April 2026 am Flughafen von Helsinki festgesetzt worden, als er nach Japan fliegen wollte. Der obige Tweet fasst zusammen, dass der Cyberger Gruppe Lösegeldzahlungen in Höhe von mehr als 100 Millionen US-Dollar aus über 100 Hacks von Computersystemen zugeschrieben werden. Die Anklageschrift gegen Peter Strokes wirft diesem jedoch lediglich nur einen Angriff auf einen Luxusjuwelier im Mai 2025 vor. Bei diesem Hack wurde eine Lösegeldforderung in Höhe von 8 Millionen US-Dollar gestellt wurde, die jedoch nicht beglichen wurde.
Stokes soll ist die jüngste Persönlichkeit aus dem Umfeld von "Scattered Spider" sein, die im Rahmen internationaler Zusammenarbeit – in diesem Fall mit dem finnischen National Bureau of Investigation und einer Red Note von Interpol – festgesetzt, ausgeliefert und vor US-Gerichte gebracht wurde. Der Fall ist Teil der Operation "Riptide", einer FBI-Kampagne, mit der das FBI nach eigenen Angaben auf die im vergangenen Jahr gemeldeten Verluste durch Cyberkriminalität in den USA in Höhe von mehr als 20 Milliarden US-Dollar reagiert.
Wie Peter Stokes enttarnt wurde
Spannend ist nun aus der Anklageschrift gegen Strokes zu erfahren, wie der Hacker identifiziert und schließlich festgesetzt werden konnte. Mir waren die Fragmente aus nachfolgendem Tweet untergekommen.
Blog-Leser Bolko hatte aus der Anklageschrift gegen Peter Stokes, die als PDF abrufbar ist, eine Reihe an Informationen herausgezogen und im Diskussionsbereich eingestellt. Da ich die Einträge aus diesem Bereich immer mal wieder lösche, ziehe ich die Informationen hier in den Beitrag. Denn die Anklage liefert detaillierte Informationen was hinter den Kulissen abgeht.
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. Windows verknüpfte aber die dem Rechner zugewiesene eindeutige "Global Device Identifier" (GDID) in seinen Telemetrie-Daten, die an Microsoft übermittelt werden.
Ergänzung: Massgravel erklärt in einer Serie von Tweets, was mutmaßlich hinter GDID steckt.
Aus der Anklageschrift geht hervor, dass Windows mit den Telemetrie-Daten die GDID und jede abgerufene IP-Adresse, und jede aufgerufene URL verknüpft und an Microsoft überträgt. Die IP-Adressen, die während des Hacks benutzt wurden, ließen sich bei den Opfern in den Log-Dateien herausfiltern.
Im Gerichtsdokument findet sich die Information, dass Peter Stokes zwar ein Konto bei einem Anbieter eines Tools zur sicheren Datenübertragung über einen Tunnel (VPN-Anbieter) eröffnete. Dieses VPN verwendete er, um auf das Computernetzwerk des als "F" bezeichneten Unternehmens zuzugreifen und Daten aus diesem Netzwerk abzuziehen. In der Anklage heißt es, dass dieses VPN-Konto über die IP-Adresse eines VPN-Proxy-Dienstes lief, die auf .168 endete. Eine mit dem von Peter Stokes verwendeten Windows-Rechner verknüpfte Microsoft-Gerätekennung (eine Global Device ID, kurz GDID) sei aber ebenfalls mit der .168-Adresse verbunden gewesen.
Sprich: Microsoft kann durch die Windows-Telemetrie die Nutzer mittels der GDID auch hinter einem Proxy identifizieren und Bewegungsprofile im Internet erstellen. Aus den Gerichtsdokumenten geht auch hervor, dass die von Microsoft per Telemetriedaten erfassten Aktivitäten zeigen, dass auf dem Windows-Rechner (von Strokes) mit der GDID g:6755467234350028 ein ngrok-Konto aufgesetzt wurde.
Ngrok ist ein beliebter Reverse-Proxy-Dienst, der lokale Entwicklungsumgebungen (wie localhost) über sichere Tunnel direkt für das öffentliche Internet freigibt. Der Datenverkehr wird durch ngrok an lokalen Firewalls und NATs vorbei geleitet.
In den Gerichtsdokumenten heißt es, dass gemäß den Microsoft-Aufzeichnungen am 12. Mai 2025 um 19:21 Uhr UTC – als laut ngrok-Protokollen das ngrok-Konto erstellt wurde – das Gerät mit der betreffenden GDID unter anderem auf folgende ngrok-Seiten zugriff:
*ttps://dashboard.ngrok.com/signup
Dann geben die Gerichtsdokumente an, welche Aktivitäten Microsoft im Rahmen der Telemetrie mit der GDID des betreffenden Windows-Rechners aufgezeichnet hatte:
- Hat im Mai 2025 von Tzulo-Servern aus auf mehrere Websites zugegriffen, darunter am 12. Mai 2025 auf den .168-Server (die IP-Adresse, die zur Erstellung des ngrok-Kontos verwendet wurde)
- Am 4. Juni 2024 um 14:01 Uhr UTC verwendete das Gerät mit der GDID
die IP-Adresse 91.129.97.29, deren Standort in Tallinn, Estland, ermittelt wurde. - Am 18. November 2024 um 7:31 Uhr UTC verwendete das Gerät mit der GDID die IP-Adresse 207.237.190.238, deren Standort in New York ermittelt wurde
- Am 26. November 2024 besuchte das Gerät mit der GDID die URL empirehotelnyc.com. Dies ist die Website eines Hotels namens "Empire Hotel" mit Standort in New York
- Am 8. Januar 2025 nutzte das Gerät mit der GDID die IP-Adresse
213.35.168.5024, vom Standort in Tallinn, Estland, wo Strokes damals lebte, um die nachfolgende URL aufzurufen
*ttps://login.growtopiagame.com/player/login/dashboard?valKey=40db4045f2d8c572efe8c4a060605726
Bolko fasste aus den Gerichtsdokumenten zusammen, dass man Anhand der IP-Adressen, die die Ermittler bezüglich RDP-Verbindungen zu einem Server gefunden hatten, über Microsoft und die mit den abgerufenen IP-Adressen protokollierte GDID feststellen konnte. Diese lieferte also die eindeutige Identifizierung des Computers. Peter Stokes postete Bilder auf Facebook und benutze diverse Dienste, über die er dann identifiziert werden konnte.
Das FBI fragte neben Microsoft bei seinen Ermittlungen dann auch Google, Apple, Facebook, Snapchat, Ubisoft und ngrok bezüglich der Daten dieses Nutzers bzw. der verwendeten Konten an. Anhand der Verknüpfung der von der Windows-Telemetrie übermittelten Daten (GDID, IP, URL) konnte man dann einfach die von Strokes auf Facebook geposteten Fotos abrufen und so den Täter identifizieren. Das führt dann zu seiner Verhaftung.
Bolko schrieb in seiner Zusammenfassung, dass der Täter, hier in Person von Peter Stokes, einige Fehler gemacht habe.
- Er habe Windows statt Linux benutzt, was zwar nicht ganz falsch, aber auch nicht richtig ist. Linux führt unter /etc/machine-id ebenfalls eine solche ID, die theoretisch auch ausgelesen werden könnte. Diese ID lässt sich aber ändern und Linux hat wohl keine Telemetrie, wie Windows. Mit ist diese Diskussion diesbezüglich untergekommen.
- Er habe in Windows die Telemetrie nicht abgeschaltet (wobei mir derzeit unklar ist, ob Stokes überhaupt die Möglichkeit dazu gehabt hätte – denn nicht alle Windows-Versionen lassen die vollständige Deaktivierung der Telemetrie zu, siehe auch meinen Beitrag hier).
- Er änderte die GDID und die IP-Adresse nicht zwischen den Hacks und den Verbindungen mit seinen privaten Accounts bei Google, Apple, Snapchat und Facebook.
Zum letztgenannten Punkt ist mir unklar, wie er die GDID in Windows ändern könnte. Bolko schrieb, dass man seine Online-Aktivitäten mindestens über zwei verschiedene Geräten und von unterschiedlichen Orten aus abwickeln sollte, um die Nachverfolgbarkeit zu erschweren. Bolko führte weitere Fehler an:
- Da die GDID auch bei Benutzung von Proxies an Microsoft geschickt wird ist das Ändern der IP nicht ausreichend. Selbst TOR nützt nichts, wenn es auf einem Windows mit aktivierter Telemetrie läuft.
- Er zeigte bei Facebook Fotos von sich an Orten, die später mit seiner Windows-GDID in Verbindung gebracht werden konnten.
Der ganze Fall ist ein Lehrstück, was man tunlichst nicht machen sollte. Dazu gehört, sich unerlaubt in fremde Computersysteme einzuhacken. Peter Stokes hat meinen Informationen seine ersten Hacks im Alter von 16 Jahren durchgeführt. Der zweite Punkt ist, dass man vielleicht drüber nachdenken sollte, auf Windows zu verzichten, oder wenigstens eine Version zu verwenden, bei der sich Telemetrie abdrehen lässt und dies auch per Gruppenrichtlinien tun sollte.
Ähnliche Artikel:
Mutmaßlicher Kopf von Scattered Spider in Spanien verhaftet
Zwei mutmaßliche Mitglieder von Scattered Spider verhaftet
Vier Verdächtige in Großbritannien wegen Co-op-, Marks & Spencer- und Harrods-Hack verhaftet
MVP: 2013 – 2016
Unglaublich was der Junge in dem Alter drauf hat.
Schade allerdings, wofür er diese Fähigkeiten nutzt.
In dem Alter kam ich mir mindestens genauso gross vor, hab aber rückblickend betrachtet sehr kleine Brötchen gebacken.
Wenn es gut für Stokes läuft, darf er auch in der Gefängnisküche kleine Brötchen backen ;-).
OT: Was mir an der gesamten Diskussion auffällt. Die Kommentatoren reiten darauf herum, wie dumm Stokes doch gewesen sei. Ist zwar naheliegend, der Gedanke – aber der Beitrag enthielt ja auch einen kleinen Graben, den man mental überspringen müsste. Ich erinnere mich an die ersten Diskussionen zur Windows Telemetrie und wie die "Abschaltversuche" als Aluhut-Trägertum abgetan wurden. Auch gibt es seit drei, vier Jahren die DSGVO-Diskussion und die Frage was per Telemetrie an persönlichen Daten an Redmond übertragen wird. Habe ich was überlesen? Eigentlich hätte ich jetzt erwartet, dass M365 und Windows diesbezüglich hinterfragt wird. Aber da ist "Schweigen im Walde", dabei sehe ich in der obigen Diskussion erneut einen "kleinen" Snowden-Momemt. Oder wie seht ihr das?
Der Punkt wird fleissig verdrängt, man will die Wahrheit nicht wissen, sie würde eigenen jahrelangen Glauben in Frage stellen.
na gibt da nur Zwei Gruppen: die einen die das alles egal ist, sei es weil sie zu bequem sind, oder zu naiv das Ganze überhaupt zu verstehen und die andere Gruppe die alles tut um das abzustellen! Die dann aber immer als Aluhutträger abgetan wird.
PS mein Aluhut gefällt mir ;-p Auf Windows kann ich nun Mal leider nicht verzichten, aber ich weiß damit umzugehen!
@Krause, naja für solche Sachen Windows zu nutzen spricht aber nicht für überragendem Intellekt! Sorry aber dafür gibt es speziele Linux Version wie TAILs & Co. Macht man auch nicht auf Systemen welche man noch mit Privaten Accounts nutzt usw.
Das VPN nicht bringen gegen "Rückverfolgung" selbst TOR nicht ist auch seit Jahren bekannt. (legt lediglich den Aufwand höher…
MAAS ist jetzt auch keine Kunst ich entnehme nirgends das der die Malware selbst geproggt hat!
@born
***************************************************************
Er habe in Windows die Telemetrie nicht abgeschaltet (wobei mir derzeit unklar ist, ob Stokes überhaupt die Möglichkeit dazu gehabt hätte – denn nicht alle Windows-Versionen lassen die vollständige Deaktivierung der Telemetrie zu, siehe auch meinen Beitrag hier).
***************************************************************
aber jede (Hardware)Firewall (ausser die Window interne) lässt sich auf "subatomarer Ebene" alles sperren bzw. fein granualar freigeben was dein Netzwerk verlässt und was nicht!
Meinten sie QubesOS? ;)
*https://doc.qubes-os.org/en/latest/introduction/intro.html
Habe gestern alle Laufwerk GUIDs, EFI partition und GDID geändert und ein Clonzilla-Backup gemacht. Checkmate Redmond, schenkt auch den grotesken MSA identity layer.
Dann bleiben noch die seit NT3 während der Installation erzeugte "Machine SID", die seit NT4 für das CryptoAPI erzeugte GUID sowie der "RSA Machine Key", die seit NT5 während der Installation erzeugte "Machine GUID", alle im laufenden Betrieb erzeugten Typ1-GUIDs, deren letzte 6 Bytes gleich der MAC-Adresse des primären NIC sind, …
Soll ich weitermachen?
Im zweiten Screenshot steht:
"GDID only change if OS wiped"
—
Davon darf man nicht ausgehen, denn die GDID wird mittels TPM und UEFI bestimmt und übersteht auch einen sauberen Reinstall von Windows.
"Will a fresh reinstall reset the Windows GDID?
Because GDID is derived from hardware attributes, a standard OS reinstall on the same hardware is unlikely to generate a new GDID"
*ttps://buynowkey.com/microsoft/windows-gdid-telemetry-tracking-audit/
Microsoft schreibt dazu:
"The method will first attempt to use the Trusted Platform Module (TPM), if present, to get an ID. If a TPM is not present, the method will try to get an ID from the Unified Extensible Firmware Interface (UEFI). If neither of these sources is available, this method will return an ID that is backed by the Windows registry. In the case of the Windows registry, the ID will not satisfy all the above guarantees. For example, if a system does not have a TPM or UEFI support, and thus an ID was obtained from the registry, a clean install of Windows will result in a new, different ID being returned."
*ttps://learn.microsoft.com/en-us/uwp/api/windows.system.profile.systemidentification.getsystemidforpublisher?view=winrt-28000
Zuerst wird also das TPM geprüft und falls dieses vorhanden ist, dann wird daraus die ID generiert und zwar bei jeder Installation identisch.
Microsoft (bzw die NSA) hat sich schon etwas dabei gedacht, das TPM zwangsweise einzuführen als Hardwarevoraussetzung für Windows 11.
Das dient der Benutzer-Identifizierung.
Falls das nicht erfolgreich war, dann wird das UEFI geprüft und falls dieses vorhanden ist, dann wird daraus die ID generiert.
Falls weder TPM noch UEFI vorhanden sind, dann wird in der Registry geprüft und neu randomisiert. Dann hat man eine Chance auf eine neue GDID. Das entspricht allerdings nicht mehr den Windows 11 Hardwarevorraussetzungen.
Moderne Systeme haben TPM und UEFI, also übersteht die GDID auch eine Neuinstallation von Windows und bleibt identisch.
Wenn das echte TPM an die VM durchgereicht wird, dann hat man sogar innerhalb der VM eine zur Host-GDID identische Gast-GDID.
2.Zitat:
"Er habe Windows statt Linux benutzt, was zwar nicht ganz falsch, aber auch nicht richtig ist. Linux führt unter /etc/machine-id ebenfalls eine solche ID"
—
Man sollte in solchen Fällen anonymisierende Linux Distributionen wie Tails benutzen, wo die machine-ID bei jedem boot neu mit Zufallszahlen erzeugt wird.
3.Zitat:
"nicht alle Windows-Versionen lassen die vollständige Deaktivierung der Telemetrie zu"
—
Das bezieht sich aber nur auf Deaktivierungsversuche mittels Gruppenrichtlinie "Diagnosedaten zulassen" ("Telemtrie zulassen") alleine.
Das funktioniert nicht.
Statt dessen sollte man die Telemetrie durch folgendes sperren:
1. Dienste abschalten (DiagTrack, WerSvc, dmwappushservice)
2. Aufgaben (Tasks) abschalten, damit die Dienste nicht reaktiviert werden
3. Gruppenrichtlinien
4. Dateisystemrechte für etl sperren
5. Registry
6. Firewall
7. NET Framework Umgebungsvariable
8. Smartscreen abschalten
9. Browser-Sync abschalten
Zu Telemetrie Unterpunkt 2 (Aufgabenplanung, Task Planer):
Der dmwappushservice wird durch den Taskplaner automatisch wieder eingeschaltet, daher muss man folgenden Task deaktivieren:
Aufgabenplanung, Aufgabenplanungsbibliothek, Microsoft, Windows, Management, Provisioning, Logon
Anmerkung:
dmwappushservice wird auch von Intune benutzt.
Falls man also Intune im EInsatz hat, dann darf man diesen Dienst nicht deaktivieren und kann dann die Telemetrie nicht vollständig abschalten.
zusätzliche Tasks abschalten:
Aufgabenplanungsbibliothek, Microsoft, Windows, Customer Experience Improvement Program,
Consolidator: Deaktiviert
wsqmcons: Deaktiviert
UsbCEIP: Deaktiviert
Aufgabenplanungsbibliothek, Microsoft, Windows, Application Experience,
Microsoft Compatibility Appraiser (CompatTelRunner): Deaktiviert
Aufgabenplanungsbibliothek, Microsoft, Windows, Windows Error Reporting,
QueueReporting: Deaktiviert
—–
Zu Telemetrier Unterpunkt 3 (Gruppenrichtlinien):
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Windows-Komponenten,
Datensammlung und Vorabversionen,
"Telemetrie zulassen": Aktiviert ("Deaktiviert" ist falsch!)
"0 – Sicherheit (nur Enterprise)"
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Windows-Komponenten,
Windows-Fehlerberichterstattung,
"Windows-Fehlerberichterstattung deaktivieren": Aktivieren
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
System,
Internetkommunikationsverwaltung,
Internetkommunikationseinstellungen,
"Fehlerberichterstattung deaktivieren": Aktivieren
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
System,
Internetkommunikationsverwaltung,
Internetkommunikationseinstellungen,
"Programm zur Verbesserung der Benutzerfreundlichkeit deaktivieren": Aktivieren
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
System,
Internetkommunikationsverwaltung,
Internetkommunikationseinstellungen,
"Handschrifterkennungs-Fehlerberichterstattung deaktivieren": Aktivieren
Werbe-ID (Advertising-ID) abschalten:
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
System,
Benutzerprofile (User Profiles),
"Werbe-ID deaktivieren" (Turn off the advertising ID): aktivieren
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Microsoft Edge,
"Synchronisierung von Daten mit Microsoft Synchronisierungsdiensten deaktiveren": Aktiviert
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Microsoft Edge Standardeinstellungen,
"Synchronisierung von Daten mit Microsoft Synchronisierungsdiensten deaktiveren": Aktiviert
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Microsoft Edge,
"URL-Berichterstattung in Edge-Diagnosedaten aktiviert": Deaktiviert
Ergänzungen zu Gruppenrichtlinien bezüglich Telemetrie, Synchronisierung, Datenupload, Bewegungsprofil (Poisitonsdaten) etc:
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Microsoft Edge,
"Erforderliche und optionale Diagnosedaten über die Browsernutzung senden": Deaktiviert
("Send required and optional diagnostic data about browser usage")
"Edge 3P SERP Telemetrie aktiviert": Deaktiviert
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Windows-Komponenten,
Anwendungskompatibilität,
"Anwendungstelemetrie deaktivieren": Aktiviert
"Inventory Collector deaktivieren": Aktiviert
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Windows-Komponenten,
Texteingabe,
"Freihand- und Eingabeverbesserung verbessern": Deaktiviert
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Windows-Komponenten,
Einstellungen synchronisieren,
Alles wo "nicht synchronisieren" steht: Aktivieren
"Windows Sicherung aktivieren": Deaktiviert
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Windows-Komponenten,
Mein Gerät suchen,
"'Mein Gerät suchen' Aktivieren/Deaktivieren": Deaktiviert
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Windows-Komponenten,
Nachrichten,
"Synchronisierung von Nachrichtendienstcloud zulassen" Deaktiviert
Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Windows-Komponenten,
Suche,
"Cloudsuche zulassen": Deaktiviert
"Cortana zulassen": Deaktiviert
"Der Suche und Cortana die Nutzung von Positionsdaten erlauben": Deaktiviert
"Nicht im Web suchen und keine Webergebnisse in der Suche anzeigen": Aktiviert
"Websuche nicht zulassen": Aktiviert
Zu Telemtrie Unterpunkten 4,5,6,7:
4.
Telemetrie im Dateisystem sperren:
Folgende zwei Dateien auf Null setzen und danach für das System die Schreib- und Änderungs-Rechte entziehen:
C:\ProgramData\Microsoft\Diagnosis\ETLLogs\AutoLogger-Diagtrack-Listener.etl
C:\Windows\System32\LogFiles\WMI\Diagtrack-Listener.etl
5. Registry
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\Diagtrack-Listener]
"Start"=dword:00000000
6. Telemetrie in der Firewall sperren (aus BSI-Sysiphus PDF):
Ausgehende Regel , Neue Regel , Vordefiniert , DiagTrack ,
Benutzererfahrungen und Telemetrie im Verbund
auswählen , Verbindung blockieren
Ausgehende Regel , Neue Regel , Benutzerdefiniert , Dienste Anpassen
, Auf diesen Dienst anwenden , Benutzererfahrungen und Telemetrie
im Verbund , Weiter , (Protokolle und Ports) Weiter , (Bereich)
Weiter , Verbindung blockieren , Profile alle , Name angeben ,
Fertigstellen
7. NET Framework Umgebungsvariable
Die NET Framework Telemetrie kann man so sperren:
Systemsteuerung, System, Erweiterte Systemeinstellungen, Umgebungsvariablen,
Systemvariablen,
Variable: DOTNET_CLI_TELEMETRY_OPTOUT
Wert: 1
Zu Telemetrie Unterpunkt 1 (Dienste):
Die folgenden 3 Dienste beemnden und deaktivieren (mit services.msc):
1. DiagTrack:
"Benutzererfahrungen und Telemetrie im verbundenen Modus"
(früher: "Diagnosenachverfolgungsdienst)
2. WerSvc:
"Windows-Fehlerberichterstattungsdienst"
3. dmwappushservice (wird aber von Intune benötigt):
"WAP-Push-Nachrichten Routing-Dienst (Wireless Application Protocol) für die Geräteverwaltung"
Alternative (in der cmd Konsole mit Adminrechten):
sc stop DiagTrack
sc stop WerSvc
sc stop dmwappushservice
sc config DiagTrack start= disabled
sc config WerSvc start= disabled
sc config dmwappushservice start= disabled
Nachtrag:
Man kann noch einen Punkt 10 als Telemetrie-Schutz machen:
In einem externen DNS-Filter (ich benutze Technitium DNS Server mit Blocklisten) die Telemetrie-Endpunkte sperren (diese ändern sich manchmal).
*ttps://learn.microsoft.com/en-us/windows/privacy/configure-windows-diagnostic-data-in-your-organization
BSI-PDF, Seite 16:
*ttps://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/SiSyPHus/Analyse_Telemetriekomponente_1_2.pdf?__blob=publicationFile&v=3
*ttps://www.privacy-handbuch.de/handbuch_90a2.htm#29_07_20
Aus obigen Quellen habe ich eine konsolidierte Liste erstellt und auf Pastebin hochgeladen:
*ttps://pastebin.com/g2cgKAgn
Nein, die GDID ist nicht dem Nutzer zugeschrieben, sondern dem PC. Verkafe ich den PC an jemand anders, und er installiert Windows neu, wird immer noch die selbe GDID erzeugt. Erst die Benutzeranmeldung an Windows verknüpft die GDID mit einer Person. Und das sicher auch ohne ein MS-Konto zu nutzen. Aber man kann ja für jede Installation auch ein anderes MS-Konto benutzen.
Spannender finde ich die Frage nach der oben erwähnten VPN-unabhängigeb Surfhistorie, damit die einer GDID / Person zugeordent werden kann, muss man dafür Edge benutzen, oder stört man diese Sammelwut, in dem man Firefox, Chrome oder einen anderen Browser oder gar ein Browser-integriertes VPN (z.B. das von Mozilla) verwendet?
Was man noch testen könnte: Wird eine andere GDID erzeugt, wenn mn den TPM zurücksetzt?
Bolko "jedes Kind" weiß das die GDID unter Windows beliebig veränderbar ist durch Austausch aller SN/FW in jeder verbauten Hardware im Gerät. Das ergibt stets eine neue andere GDID, erkennbar dadurch das Windows dann immer eine neue Aktivierung verlangt. Haha! Die "Scripi-Kids" sind einfach nur doof.
Telemetriedaten an Microsoft schicken? Naiv oder dumm. Der Junge hatte wohl doch nicht so viel drauf.
Die Telemetriedaten kann man nicht zu 100% abschalten.
Und Firewallregeln der Windows-Firewall zur Blockierung der Microsoft Telemetrieserver sind teilweise wirkungslos.
Die Windows-Firewall ignoriert bestimmte Blockierungen von Microsoft Telemetrieservern.
Will man die effektiv blockieren, geht das nur mit einer externen Firewall.
Was die GDID angeht:
Wird die nur bei der Installation generiert und der Wert dann in der Registry abgelegt und dann bei der Übermittlung der GDID nur der Registryeintrag genommen?
Wenn ja, dann könnte man die GDID in der Registry ändern.
Zitat:
"Zum letztgenannten Punkt ist mir unklar, wie er die GDID in Windows ändern könnte."
—
Indem er zwei verschiedene Geräte benutzt.
Ein Gerät nur für Privates (Smartphone oder zweiten Windows-PC) und das andere Gerät nur für die Hacks (Tails-PC).
Außerdem darf er beide Geräte nicht im selben Netzwerk (WLAN) benutzen, weil man sie sonst auch wieder miteinander verknüpfen könnte.
Wenn das Smartphone mittels "Mobile Daten" eingelogt ist oder auch nur die Telefonfunktion aktiv ist, dann kann man anhand der benutzten Funkmasten auch die Position bestimmen und wenn diese Position mit der Position des WLANs übereinstimmt, dann ist ebenfalls eine Verknüpfung möglich.
Die Position der Funkmasten steht allerdings zum Glück nicht in den Microsoft-Logs drin.
Das müsste die Polizei dann anhand der Vorratsdatenspeicherung (oder QuickFreeze) herausfiltern.
Normalerweise darf ein privates Smartphone gar nicht in der Nähe sein, wenn man ernsthaft ein Verbrechen (Hack) begeht, denn Funkzellenabfrage ist Standardroutine in der Umgebung eines bekannten Tatort.
Wenn ein Dienst einen bereits vorher auf dem Kiecker hatte und das Smartphone infiltrieren konnte, dann reicht auch ein Abschalten des Smartphones nicht mehr aus, denn das simuliert dann nur den abgeschalteten Zustand, obwohl es tatsächlich weiter aktiv ist und zum Beispiel stille SMS beantworten kann.
Und deshalb nur Geräte nutzen, bei denen man auch rel. leicht den Akku entfernen kann.
(…) denn nicht alle Windows-Versionen lassen die vollständige Deaktivierung der Telemetrie zu (…)
können wir diesen Mythos jetzt endlich Mal nach 10 Jahren beerdigen? das ist schlicht flashc!
danke @Bolko, das du dich schon geäußert hast.
in JEDER Windows Version lassen sich die 2 relevanten Dienste (diagtrack, wersvc) zentral per GPO! Abschalten.
wenn der Dienst deaktiviert ist, ist dessen Konfiguration per Richtlinie, die immer genannt wird, vollkommen wurscht. Aus ist Aus.
Konfiguration per GPO funktioniert nur bei aktiver Komponente/Dienst
@Günter würdest du das bitte im Text korrigieren? die Leute lesen und glauben das und erzählen es weiter. es bleibt aber flasch.
Auch das nicht nur hier von ahnungslosen Kleinkindern gern wiederholte MÄRCHEN, dem Konto SYSTEM Zugriffsrechte zu entziehen, ist und bleibt ein MÄRCHEN: unter SYSTEM laufende Prozesse haben die Privilegien BACKUP und RESTORE aktiviert, d.h. DACLs werden NICHT beachtet!
Dann kann man sich sämtliche Änderungen auch an Diensten und GPOs sparen, weil System wirklich alles rückgängig machen darf.
Bei mir hat System bisher aber die Dateisystemrechte für die etl Dateien nicht zurückgesetzt und mir ist auch kein Fall bekannt, wo eine unerwünschte Rechteänderung durch System mittels Restore mal passiert wäre.
Damit wäre Windows tot.
Gibt es einen Weg, um System dieses Restore-Privileg zu entziehen?
Die Privilegien für "System" kann man nicht entfernen:
"modifying privileges does not restrict system-level accounts. In order for the operating system and associated tooling to function, these privileges are required and cannot be revoked."
*ttps://blog.palantir.com/windows-privilege-abuse-auditing-detection-and-defense-3078a403d74e
Man muss also darauf vertrauen, dass "System" dieses SeRestorePrivilege nicht missbraucht, um die Rechte zurückzusetzen, sonst wäre die ganze Konfigurationsarbeit sinnlos.
IMMER NOCH VÖLLIG FALSCH
Unter SYSTEM-Konto laufende Prozesse können Dateisystemobjekte auf NTFS IMMER lesen und schreiben, sie müssen die Zugriffsrechte NICHT ändern!
Einfach 'mal die GRUNDLAGEN (verstehen) lernen!
Im Artkel steht 4 mal "Strokes" (falsch) statt "Stokes" (korrekt).
massgravel hat auch etwas dazu geschrieben:
*ttps://xcancel.com/massgravel/status/2074304593303892354#m
(Falls der Link aktuell wegen Überlastung von xcancel nicht geht, dann ersetze xcancl[.]com durch nitter[.]space oder eine beliebige andere der folgenden Instanzen:
*ttps://github.com/zedeus/nitter/wiki/Instances
)
Die Global Device ID (GDID) ist identisch mit Passport Unique ID gleich PassportIdentity.HexPUID.
GDID ist bei Microsoft schlecht dokumentiert.
Passport Unique ID = HexPUID ist besser dokumentiert
Die GDID wird in der Registry und in Tokens gespeichert.
Änderung nur in der Registry bringt nichts.
Der Dienst "Anmeldeassistent für Microsoft-Konten" (wlidsvc) schickt die Hardwaredaten (TPM, UEFI, SMBIOS, Festplatten-Seriennummer) an Microsoft und Microsoft schickt passende Tokens zurück.
Bei einer Änderung der GDID ist die Aktivierung weg und UWP-Apps funktionieren nicht mehr korrekt.
Auch bei einer neuen GDID kann man auf die Hardware rückschließen und ist damit wieder identifizierbar.
Durch die GDID kann man ein Microsoft-Konto auf unterschiedlichen Geräten verfolgen.
Die URLs stammen vermutlich von der optionalen Edge Telemetrie (die man in den Gruppenrichtlinien abschalten kann).
Seine Tipps:
– Telemetrie so weit wie möglich abschalten
– kein Microsoft Konto benutzen
– kein Edge benutzen
– Tails Linux benutzen
– TOR oder Mullvad Browser benutzen
– VM benutzen
– VPN benutzen
re: Auch bei einer neuen GDID kann man auf die Hardware rückschließen und ist damit wieder identifizierbar.
Nein, wenn es richtig gemacht ist.
Bolko es ist ja wohl klar das nach einem "GDID Fix" ein "Offline Clean Install" erforderlich ist, dann ist nichts mehr für MS nachvollziehbar, ergo "es ist eine völlig andere Hardware"!
Ob ein "Offline Clean Install" hinreichend ist für eine GDID-Änderung weiß ich nicht, denn zur Erzeugung der GDID wird das TPM abgefragt und dieses ändert sich nicht.
Die Quellen dazu hatte ich weiter oben verlinkt.
Soweit ich das bisher verstanden habe, ändert auch ein Sysprep nur die GUID und die SID, aber nicht die GDID.
Windows ist für solche Sachen, die 100 prozentige Anonymität voraussetzen, prinzipiell nicht zu gebrauchen, weil man den "globalen Mastertracker und Primärschlüssel der gesammelten Telemetrie" (GDID) nicht gelöscht bekommt, solange man nicht das Mainboard ausbaut und ersetzt.
Bolko was genau davon hast du nicht verstanden, gerne erkläre ich dir das dann.
SN = Seriennummer
(Austausch in allen Hardwarekomponenten des Rechner)
FW=(Austausch/Veränderung bestimmter Firmware Inhalte der verbauten Hardware)
Dienst arbeiten so und erhalten so stets eine neue GDID für die Hardware, sicher hast du schon mal von dem öffentlich aufgetauchen Laptop eines Dienst -absolut ohne jegliche Seriennummen gehört?
Wenn Windows danach eine neue Aktivierung verlangt kannst du erkennen das auch eine neue GDID vergeben wird/wurde.
Ich möchte das hier aber nicht weiter erklären, aus guten nachvollziehbaren Gründen.
Stefan Kanthak hat selbstverständlich völlig Recht mit dem was er zu dir sagte. Zitat: IMMER NOCH VÖLLIG FALSCH
Unter SYSTEM-Konto laufende Prozesse können Dateisystemobjekte auf NTFS IMMER lesen und schreiben, sie müssen die Zugriffsrechte NICHT ändern!
Bolko die GDID unter Windows ist beliebig veränderbar, durch Austausch aller SN/FW in jeder verbauten Hardware im Gerät. Das ergibt stets eine neue andere GDID, erkennbar dadurch das Windows dann immer eine neue Aktivierung verlangt.
Aloha!
Was SN und FW bedeutet war mir auch vorher schon klar, ebenso wie:
"durch Austausch aller SN/FW in jeder verbauten Hardware im Gerät"
Es stellt sich aber die Frage wie man als User die Seriennummern von TPM, Netzwerkchip, UEFI etc mit vertretbarem Aufwand ändern soll.
Das übersteigt doch jedes vernünftige Maß und der Einbau von komplett neuer Hardware ginge schneller.
Hardwarewechsel hatte ich auch weiter oben bereits geschrieben.
Kennt jemand eine Bezugsadresse von TPM und Netzwerkchip OHNE Seriennummern bzw OHNE eindeutige MAC-Adresse?
Falls jemand mit SO einer Hardware angetroffen wird, dann ist doch sowieso sofort klar, dass derjenige für einen Dienst arbeitet und ein hochwertiges Ziel darstellt, weil ein normaler User macht sowas nicht.
2.
Da man dem SYSTEM das SeRestorePrivilege nicht entziehen kann und SYSTEM daher die ACL umgehen kann, ist der Punkt 4 eigentlich sinnlos und kann gestrichen werden:
"4. Dateisystemrechte für etl sperren"
Durch dieses Privileg ist allerdings jede Konfigurationsarbeit letztendlich sinnlos, weil SYSTEM alles rückgängig machen kann.
Man muss also entweder darauf vertrauen, dass Windows sich an die Einstellungen des Administrators hält und nichts willkürlich rückgängig macht oder aber man darf Windows gar nicht mehr einsetzen.
Wenn man Windows derart misstraut, dann kann man gleich alles vergessen, was wir hier in den letzten Jahren bezüglich Sicherheit und Telemetrie gemacht haben.
Dann wäre sogar der Applocker sinnlos, weil SYSTEM auch diesen aushebeln kann.
Ist euer Ratschlag also bezüglich Sicherheit und Windows alles sein zu lassen und so laufen zu lassen, wie Microsoft es voreingestellt hat?
Wenn man aufgrund dieser Erkenntnis des SeRestorePrivilegs von SYSTEM konsequent wäre, dann wäre Windows doch jetzt mausetot, weil ein sicherer Betrieb völlig unmöglich ist, ganz egal, welche Härtungsmaßnahmen man ergreift.
Warum benutzt ihr dann immer noch Windows statt Linux?
Es ist ja so: Dienste wie die NSA usw. würden niemals zulassen, dass ein wirklich sicherer Betrieb von amerikanisch kontrollierten Betriebssystemen wie Windows, Google Android, Apple iOS oder auch AWS usw. möglich wäre. Nationale Sicherheit steht immer an erster Stelle. Dazu gehören natürlich auch Backdoors bis hin zu Killswitch Möglichkeiten.
Jeder der logisch denken kann, weiss das seit über 30 Jahren. Es wird aber nach wie vor ignoriert, vernebelt, schöngeredet, usw.
Warum Windows trotzdem genutzt wird, ist das grösste Rätsel der Menschheit.
Einfach Windows in einer VM laufen lassen.
Da hat man etwas mehr Möglichkeiten, etwas zu ändern.
Z.B. die MAC-Adresse kann man nach Lust und Laune ändern.
$hex = (Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID;"g:$([Convert]::ToUInt64($hex,16))"
Thank me later ;-)
https://github.com/SmtimesIWndr/gdid-reversal
Ach und etwas das dauerhaft bleibt und sich NICHT verändert durch Neuinstallation:
oa3tool.exe /DecodeHwHash=$((Get-CimInstance -Namespace root/cimv2/mdm/dmmap -Class MDM_DevDetail_Ext01 -Filter "InstanceID='Ext' AND ParentID='./DevDetail'").DeviceHardwareData)
oa3tool ist aus dem ADK.
Und ich empfehle mal diese Lektüre: https://download.microsoft.com/download/8/a/2/8a2fb72d-9b96-4e2d-a559-4a27cf905a80/windows-platform-binary-table.docx
In diesem Zusammenhang auch ganz interresant:
https://github.com/Korben00/no-gdid
den Artikel dazu gibt es hier:
https://korben.info/en/gdid-windows-cut-tracker-vpn.html
re (auf der Website): Ein Live-Linux-System beispielsweise gibt Ihnen die volle Kontrolle darüber, welche Daten Ihr System verlassen. Du bist wirklich navi falls du das wirklich glauben solltest, auch Linux ist keine wirkliche Alternative.
Die einzige wirkliche Alternative ist ein selbst erstelltes OS ohne jede 3part-Software auf selbst gebauter Hardware, incl. eigener Firmware, und eigener Satellit-Router, der die Verbindung über einen gehackten "National Security Agency Mil-Satellit" im All herstellt. :-)
Danke für die beiden Links.
Es werden also 3 Dienste abgeschaltet:
DoSvc = "Übermittlungsoptimierung" = "Connected Devices Platform and Delivery Optimization services." = "Delivery Optimization"
CDPSvc = "Plattformdienst für verbundene Geräte" = "Connected Devices Platform Service"
CDPUserSvc = gehört auch irgendwie zu "Connected Devices Platform Service"
(Diesen Dienst habe ich im Dienste-Dialog bisher noch nicht gefunden, aber er steht in der Registry drin.)
Wobei sich der Dienst DoSvc weigert, sich per Kommandobefehl SC abschalten zu lassen.
sc stop DoSvc
sc stop CDPSvc
sc stop CDPUserSvc
sc config DoSvc start= disabled
(Fehler. Zugriff verweigert)
sc config CDPSvc start= disabled
sc config CDPUserSvc start= disabled
Deswegen kann man die Dienste über die Registry abschalten:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\DoSvc" /v Start /t REG_DWORD /d 4 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\CDPSvc" /v Start /t REG_DWORD /d 4 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\CDPUserSvc" /v Start /t REG_DWORD /d 4 /f
Danach ist ein Neustart erforderlich.
Zusätzlich wird in der hosts Datei folgendes eingetragen, um die Telemetrie-Endpunkte zu sperren:
0.0.0.0 dds.microsoft.com
0.0.0.0 fd.dds.microsoft.com
0.0.0.0 aad.cs.dds.microsoft.com
0.0.0.0 cdpcs.access.microsoft.com
0.0.0.0 geo.prod.do.dsp.mp.microsoft.com