Microsoft, 끌 수 없는 Windows 추적 ID의 존재를 방금 인정했다

텔레메트리 (Telemetry)는 수년 동안 Windows 관련 대화에서 조용한 배경 소음과 같았습니다. 대규모 기능 업데이트가 있을 때마다 불거졌다가 다시 사라지는 그런 주제 말입니다. 하지만 이번 달, 이것은 더 이상 배경 소음이 아니게 되었습니다. 연방 형사 고소로 인해 Microsoft는 Windows 업데이트 후에도 유지되며, 표준 인터페이스를 통해서는 볼 수 없고, 개인 정보 보호 (Privacy) 설정의 거의 모든 다른 항목과 달리 끌 수 있는 스위치조차 없는 지속적인 기기별 식별자 (per-device identifier)의 존재를 처음으로 공개적으로 확인해야 했습니다.

해커의 VPN이 무의미해진 이유

이 식별자는 GDID, 즉 Global Device Identifier의 약자로 불리며, FBI가 2025년 미국 보석 소매업체를 대상으로 한 랜섬웨어 (ransomware) 공격과 관련하여 Scattered Spider 해킹 그룹의 19세 멤버로 추정되는 Peter Stokes를 검거하는 과정에서 공개되었습니다. Stokes는 추적을 피하기 위한 표준 수법인 VPN, 프록시 (proxies), 그리고 여러 국가에 분산된 인프라 (infrastructure) 뒤에서 작전을 수행한 것으로 보고되었습니다. 하지만 그 어떤 것도 소용이 없었습니다. 그의 Windows PC가 어떤 IP 주소나 출구 노드 (exit node)를 사용하든 상관없이, Microsoft에 지속적인 식별자를 조용히 보고하고 있었기 때문입니다.

공개된 39페이지 분량의 고소장에는 GDID를 특정 Microsoft 서비스 및 시나리오(물리적 기기든 VM이든 상관없이) 전반에 걸쳐 Windows 설치를 고유하게 식별하도록 설계된 지속적인 기기 수준의 식별자라고 설명하는 Microsoft 관계자의 인용구가 포함되어 있습니다. 법원의 명령으로 Microsoft가 해당 식별자와 연결된 기록을 제출하게 되자, 조사관들은 웹 활동 타임스탬프 (timestamps), IP 이력, 인프라 연결 정보를 확보할 수 있었습니다. 이를 통해 Stokes의 VPN으로 보호된 세션들을 하나의 식별 가능한 흔적으로 엮어낼 수 있었으며, 여기에는 그가 ngrok 계정에 가입한 정확한 순간과 같이 매우 구체적인 정보도 포함되었습니다.

GDID의 기술적 실체

이 사례 외에 Microsoft가 GDID를 명시적으로 기록한 것은 Delivery Optimization 보고를 위한 Azure Monitor 참조 문서에서 단 한 번뿐입니다. 해당 문서의 GlobalDeviceId라는 열에는 "Microsoft 내부적으로 사용되는 식별자"라는 한 문장만이 적혀 있습니다. 이것이 어떻게 작동하는지에 대한 나머지 모든 정보는 불만이 공론화된 이후 독립적인 역공학 (Reverse Engineering)을 통해 밝혀졌습니다.

이 체인은 Microsoft 계정으로 Windows에 로그인하는 순간 시작됩니다. wlidsvc라고 불리는 시스템 서비스가 login.live.com과 통신하여 Device PUID — Passport Unique ID —를 받아옵니다. 이는 하드웨어 지문 (Hardware Fingerprint)에서 유도된 것이 아니라 서버 측에서 할당되는 64비트 값입니다. 이 값은 레지스트리의 HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties에 g:<decimal> 형식으로 저장되며, 이후 Connected Devices Platform (cdp.dll)이 이를 실제로 등록하고 Microsoft의 서비스 전반에 전파합니다. 이는 기능 업데이트 및 버전 업그레이드 과정에서도 유지됩니다. 클린 재설치 시에는 사라지지만, 재설치 후 동일한 Microsoft 계정으로 다시 로그인하면 Microsoft는 새로운 GDID를 이전 활동과 다시 연결할 충분한 이유가 있으므로, 재설치가 기대만큼 큰 효과를 주지는 못합니다.

개발자들이 특히 주의 깊게 봐야 할 부분

Windows의 다른 모든 텔레메트리 (Telemetry) 설정과 진정으로 다른 점은 바로 이 세부 사항에 있습니다. GDID 생성을 끌 수 있는 사용자 대상 설정, 정책, 또는 레지스트리 플래그가 전혀 존재하지 않는다는 것입니다. 이를 비활성화하는 옵션이 제공되지 않는 이유는 GDID가 Windows 정품 인증 및 Microsoft Store 기능과 구조적으로 결합되어 있기 때문입니다. 이를 차단하면 Microsoft가 선택 사항이 아니라고 간주하는 기능들이 망가집니다. 지금까지 발견된 유일한 제어 수단은 장치가 애초에 login.live.com에 도달하지 못하도록 차단하는 것 — 즉, 설정이 아닌 네트워크 수준의 차단 — 뿐이며, 이는 수많은 정상적인 기능까지 함께 망가뜨리는 취약하고 극단적인 방법입니다.

Windows가 노출하는 다른 모든 개인정보 관련 식별자들 — 광고 ID (Advertising ID), 진단 데이터 수준 (Diagnostic data level), 활동 기록 (Activity history), 맞춤형 환경 (Tailored experiences), Recall — 와 비교해 보십시오. 이들은 Microsoft가 스위치를 아무리 깊숙이 숨겨두었더라도 설정 (Settings)이나 그룹 정책 (Group Policy)을 통해 토글(Toggle)할 수 있습니다. GDID는 전체 스택 중에서 토글을 염두에 두고 설계되지 않은 유일한 식별자이며, 우리가 이를 지금 알게 된 이유는 Microsoft의 공개가 아니라 연방 법원 제출 서류 때문입니다.

실제로 여전히 제어할 수 있는 것들

GDID 자체는 논의 대상에서 제외되었으므로, 대부분의 보안 필진들이 수렴한 실질적인 대응책은 그 주변의 모든 것을 강화하는 것입니다. 즉, 설정 시 여전히 허용되는 경우 로컬 계정 (Local account)을 사용하고, 진단 데이터를 '필수 항목만 (Required-only)'으로 설정하며, 광고 ID (Advertising ID)와 개인 맞춤형 광고 (Personalized-ads) 토글을 제거하고, 활동 기록 (Activity History) 및 클라우드 콘텐츠 검색 (Cloud Content Search)을 꺼서 이미 존재하는 식별자에 연결되는 정보를 최소화하는 것입니다.

저는 오늘 GitHub에 올린 Windows 정리 도구의 일부로, 실제로 토글이 가능한 부분인 텔레메트리 (Telemetry) 영역을 자동화했습니다. 이 도구는 AppX 비대화 (AppX bloat) 및 문서화되지 않은 삭제 (Undocumented uninstalls)라는 더 넓은 문제를 겨냥하고 있습니다 (전체 패키지 스캔, 종속성 인식 제거, 그리고 무언가에 손을 대기 전 네이티브 SRSetRestorePoint API를 통한 적절한 시스템 복원 지점 생성 포함). 하지만 텔레메트리 부분은 구체적으로 광고 ID (Advertising ID)를 끄고, Siuf\Rules 키를 통해 Windows 피드백 팝업을 제거하며, SQMClient\Windows를 통해 CEIP를 비활성화합니다. 이는 설정의 하위 메뉴를 일일이 뒤지는 대신, 여전히 사용자가 제어할 수 있는 세 가지 레버를 한 번에 처리하는 방식입니다. 또한, 확실하지 않은 항목을 제거하기 전에 VirusTotal의 v3 API를 사용하여 로컬 파일 평판 검사를 수행하며, API 키는 바이너리 옆에 평문으로 두지 않고 DPAPI를 통해 저장 시 암호화됩니다. 관심 있는 분들을 위해 제 GitHub에 링크를 남겨둡니다 — WinPurge-Windows 11 Component Cleaner.

더 큰 그림

GDID의 개념 자체가 독특한 것은 아닙니다. Apple은 하드웨어 UUID와 DSID를 가지고 있으며, Linux는 machine-id를 가지고 있습니다. 모든 주요 플랫폼은 라이선싱 및 남용 방지를 위해 지속적인 장치 식별 (persistent device identity) 개념을 유지하고 있습니다. 특이한 점은 Windows가 선택한 조합입니다. 즉, 실제 포렌식 (forensic) 능력을 갖춘 식별자이면서, 문서화가 전혀 되어 있지 않고, 사용자의 가시성도 없으며, 거부 (opt-out)할 수도 없는 상태로 존재한다는 점입니다. 이는 형사 사건의 증거로 나타났기 때문에 대중에게 발견되었습니다. 이번에는 정말로 악의적인 행위자를 잡아냈습니다. 불편한 사실은 바로 동일한 특성들 — 지속적이고, VPN을 가로지르며, MSA (Microsoft Account)에 로그인하는 순간 실제 신원과 연결되는 특성 — 이 랜섬웨어 운영을 수행하는 기기뿐만 아니라, 16억 개의 모든 Windows 설치 환경에 적용된다는 점입니다.

개발용 기기에서 로컬 계정 (local accounts)을 사용하시나요, 아니면 Microsoft가 너무 번거롭게 만들어 놓아서 대부분의 사람들이 더 이상 신경 쓰지 않게 되었나요?