TL;DR

[!NOTE] 아래 나열된 내용은 사실이지만 일부 정보가 누락되어 있습니다. MSA에 로그인했는지 여부와 관계없이 GDID가 있다는 점을 깨달았습니다. 게시 당시에는 인지하지 못했지만 조사해 보았습니다. CDP에는 MSA가 연결되지 않은 경우 사용되는 익명 장치 경로가 있습니다. 기본 시스템은 여전히 사실적으로 정확하며 몇 가지 사항만 누락되었습니다.

• GDID는 실제 원격 분석 항목입니다. 미국 연방 형사 고소장(United States v. Peter Stokes, N.D. Ill., 2026년 7월)에 Global Device Identifier g:6755467234350028로 나타납니다.
• Microsoft 계정 "Device PUID"입니다. Windows 설치가 Microsoft 계정에 등록될 때 할당되는 64비트 Passport Unique ID로, 장치 그래프에 g:<decimal> 형식으로 기록됩니다.
• 주장은 틀렸습니다. "128비트"도 아니고 "일련 번호로 생성"되지도 않습니다. 법원 기록 자체에서 재설치는 새로운 GDID를 생성한다고 명시하며, 이는 GPU와 같은 하드웨어 일련 번호에서 파생될 수 없음을 의미합니다.
• 스택, 아래에서 위로: wlidsvc(Microsoft 계정 서비스)가 login.live.com으로 장치를 프로비저닝하고 장치 PUID를 받아 레지스트리에 저장 -> Connected Devices Platform(cdp.dll / CDPSvc)이 이를 읽고 Device Directory Service (DDS) 그래프에 등록 -> Delivery Optimization이 이를 문서화된 UCDOStatus.GlobalDeviceId로 보고합니다.
• 이 모든 과정은 공개 기호가 있는 실제 Windows 11(26200) 머신에서 재현되었습니다. 레지스트리 한 번 읽기로 자신의 GDID를 찾을 수 있습니다(§7).

[!NOTE] 신뢰도 레이블. 모든 주장에는 태그가 붙어 있어 직접 평가할 수 있습니다: [COURT] 1차 출처 사실, [OBSERVED] 테스트 머신에서 실제 재현, [STATIC] 바이너리 및 공개 Windows PDB에서 입증, [ASSESSED] 증거로부터의 강력한 추론.

목차

1. Background: what the court actually said
2. Debunking the viral myths
3. Where GDID surfaces: Delivery Optimization
4. Who owns it: Connected Devices Platform to DDS
5. How CDP gets it: it consumes, it does not compute
6. The mint: MSA Device PUID (wlidsvc)
7. Find your own GDID
8. Reducing the exposure
9. Methodology (reproducible)
10. Limitations and honest caveats

1. 배경: 법원이 실제로 말한 내용

2026년 7월 1일, DOJ는 Scattered Spider(일명 Octo Tempest / UNC3944 / 0ktapus)의 일원으로 추정되는 Peter Stokes에 대한 형사 고소장을 공개했습니다. 진술서는 Microsoft가 FBI가 장치에 활동을 귀속시키는 데 어떻게 도움을 주었는지 설명합니다.

[!IMPORTANT] [COURT] 대체 고소장(¶25, p.34)에서 인용:

"ngrok 계정은 Global Device Identifier g:6755467234350028('GDID')을 통해 설정되었습니다. Microsoft 담당자에 따르면, Windows 생태계의 Global Device Identifier는 장치에서 Windows 운영 체제 설치를 고유하게 식별하도록 설계된 영구적인 장치 수준 식별자입니다... GDID는 장치의 Windows 설치에 연결된 전역 고유 식별자입니다. GDID는 장치의 Windows 운영 체제 업데이트에서 일관되게 유지되지만, Windows 재설치는... 새로운 고유 GDID와 연결됩니다."

각주에는 한 Microsoft 사용자가 여러 GDID를 가질 수 있다고 추가합니다. 진술서는 GDID의 IP 기록 및 검색(예: empirehotelnyc.com, Growtopia/Ubisoft 로그인 URL)을 용의자가 로그인한 계정과 연관시킵니다.

여기서 두 가지 사항이 이 분석의 나머지 부분을 이끕니다:

1. 값은 g: 뒤에 10진수 정수입니다(g:6755467234350028). 16진수로는 0x0018000FC8CB93CC이므로 64비트 숫자입니다.
2. 재설치는 새로운 GDID를 제공합니다. 따라서 변경되지 않는 하드웨어의 단순한 함수일 수 없습니다.

2. 바이럴 오해 바로잡기

소셜 미디어 요약은 GDID가 *"설치 시 일련 번호에서 생성된 128비트 식별자"*라고 주장했습니다. 두 부분 모두 거짓입니다:

[!NOTE] CDP를 좀 더 리버싱한 후 약간의 잘못된 정보를 제공했습니다. 로컬 계정을 사용한다고 GDID가 방지되지는 않습니다. CDP에는 Microsoft 계정이 없는 경우 사용되는 익명 장치 경로가 있습니다. 읽을 때 이 점을 명심하십시오.

3. GDID가 표시되는 곳: Delivery Optimization

[STATIC] Microsoft의 공개 Azure Monitor 문서는 UCDOStatus (Update Compliance / Delivery Optimization) 테이블의 GlobalDeviceId 열을 정의합니다:

GlobalDeviceId (문자열): "Microsoft 전역 장치 식별자. Microsoft에서 내부적으로 사용하는 식별자입니다."

LastCensusSeenTime, ISP, City, Country 바로 옆에 위치하여 지리 및 IP와 연결된 장치 ID가 생성됩니다. Microsoft가 공개 문서에서 값을 명명한 유일한 곳입니다. 그러나 Delivery Optimization은 이를 보고만 합니다. 중요하게도 이를 소유하지는 않습니다. 업스트림을 따라가면 Connected Devices Platform에 도달합니다.

4. 소유자: Connected Devices Platform에서 DDS까지

[STATIC] C:\Windows\System32\cdp.dll (Connected Devices Platform, 서비스 CDPSvc + CDPUserSvc)에는 GlobalDeviceId 기호와 전체 Device Directory Service 등록 하위 시스템이 포함되어 있습니다:

ddsregistrationclient.cpp   ddsregistrationmanager.cpp   ddsregistrationinfo.cpp
DdsRegistrationClient   RegisterUserDevicesObserver   DdsRegistrationInfoProviderForCDP
endpoints: dds.microsoft.com  fd.dds.microsoft.com  aad.cs.dds.microsoft.com  cdpcs.access.microsoft.com
device-id format string: "g:%s"

DDS = Device Directory Service는 Microsoft의 교차 장치 ID 그래프(Phone Link, 클라우드 클립보드, "PC에서 계속", Nearby Share 뒤의 백엔드)입니다. CDP는 이 그래프에 설치를 등록하는 Windows 클라이언트로, g:<decimal>로 키가 지정됩니다.

4.1 라이브 캡처

[OBSERVED] 새 등록을 강제하고(로컬 상태를 지운 후 CDPSvc 다시 시작) CDP 자체 ETW 공급자를 캡처하여 전체 핸드셰이크를 생성했습니다:

DdsClient::RegisterUserDeviceAsync()   RegistrationReason: Startup   Account Type: MSA
DDSClient: Registration response received. HTTP status code: 200
OnRegisterUserDeviceComplete
GetDeviceIdAndTicketActivity -> deviceid: 0018XXXXXXXXXXXX

g:<decimal>로 기록된 그 deviceid는 구조적으로 고소장의 값과 일치합니다:

둘 다 동일한 0x0018 상위 워드 클래스(장치 PUID 네임스페이스, §6 참조)에 있는 64비트 값입니다. g: 접두사는 해당 정수를 10진수로 나타낸 것입니다.

5. CDP가 가져오는 방법: 소비할 뿐 계산하지 않음

[STATIC] 공개 PDB(cdp.pdb)를 사용하면 cdp.dll의 장치 ID 경로는 ID 스택에 대한 요청 및 대기일 뿐입니다. CDP는 ID를 자체적으로 계산하지 않습니다:

flowchart TD
    A["GetStableDeviceIdFromProvider<br/>0x0A3140"] --> B["provider.GetStableDeviceIdAsync<br/>(vtable +0x48)"]
    B --> C["OneCoreAccountProvider::<br/>GetStableDeviceIdAsync 0x0C8370"]
    C --> D["IWebAccountBackedAccountProvider<br/>(MSA / AAD identity COM)"]
    D --> E["OnGetStableDeviceIdCompleted<br/>(const char* deviceId) 0x06CEA0"]
    E -->|"assign() string, signal flag"| A

이를 수신하는 콜백은 명확합니다. ID는 문자열로 나타나며 그냥 저장됩니다:

; OnGetStableDeviceIdCompleted
mov  rbp, r9                 ; r9 = ID 공급자가 전달한 device-id 문자열
lea  rcx, [rsi+0xD8]         ; CDP 멤버 필드
mov  rdx, rbp
call assign@basic_string     ; 저장, 계산 없음, 일련 번호 없음
call Set@CdpWaitableFlag      ; 대기자 차단 해제

결론: GDID는 CDP 아래의 Windows ID 스택에서 생성되어 불투명한 문자열로 CDP에 전달됩니다. 이는 Microsoft 계정 서비스를 가리킵니다.

6. 발행처: MSA Device PUID (wlidsvc)

[STATIC] C:\Windows\System32\wlidsvc.dll은 Microsoft 계정 / Passport (Windows Live ID) 서비스로, 리터럴 GlobalDeviceId를 포함하는 유일한 ID 바이너리이며 전체 장치 프로비저닝 메커니즘을 보유합니다:

CDeviceIdentityBase::CreateNewDeviceIdentity / Provision / BindDeviceToHardware / GetDeviceCert
DeviceAssociateRequest      (Passport PPCRL SOAP -> login.live.com)
<ps:DevicePUID> ... </ps:DevicePUID>
DeviceIdStore::LogToRegistry
BCryptGenRandom / CCryptRandom::GenRandom     (장치 KEY, ID 아님)

식별자는 Device PUID (Passport Unique ID)이며, 64비트 MSA 식별자입니다. 그 안의 BCryptGenRandom은 BindDeviceToHardware가 머신에 고정하는 장치 인증 키를 만들며, PUID가 아닙니다.

6.1 서버 할당 방식

[STATIC] 클라이언트는 서버의 SOAP 응답에서 PUID를 추출하며, 응답 본문에 대한 XPath를 사용합니다:

/S:Envelope/S:Body/ps:DeviceUpdatePropertiesResponse/HWPUIDFlipped

CAssociateDeviceRequest::ParseResponseBody 및 관련 ParseResponse 메서드는 응답 XML 노드를 BSTR로 읽습니다. 따라서 흐름은 다음과 같습니다: 클라이언트가 장치를 프로비저닝 -> login.live.com이 장치 PUID를 할당하고 반환 -> 클라이언트가 저장합니다. 이것이 바로 재설치가 새로운 GDID를 생성하는 이유(새 프로비저닝, 새 서버 할당 PUID)이며, 하드웨어 해시가 아닌 이유입니다.

6.2 일반 텍스트로 유지됨

[OBSERVED] Microsoft 계정 ID 저장소는 사용자 자신의 하이브에 있는 레지스트리 값을 직접 유지합니다:

HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties
    LID = 0018XXXXXXXXXXXX

HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\{...}
    DeviceId = 0018XXXXXXXXXXXX

CDP가 DDS에 라이브 등록한 값과 바이트 단위로 동일합니다. 사용자 계정 PUID는 다른 숫자로 puid = 0003...(예: 00034002XXXXXXXX)로 별도로 저장됩니다. PUID 이름의 NegativeCache 키(HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache\<PUID>_<userSID>)도 있지만 SYSTEM 전용이므로 HKCU에서 값을 읽습니다.

[!NOTE] 접두사는 무엇인지 알려줍니다. 사용자 PUID는 0003 클래스, 장치 PUID는 0018 클래스입니다. 법원의 GDID(0018000FC8CB93CC)는 제 것과 동일한 0018 장치 PUID 공간에 있습니다.

6.3 그래프 엔드포인트 인증

[OBSERVED] MSA 토큰 캐시(HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache\...)에는 CDP가 사용하는 엔드포인트로 정확히 범위가 지정된 장치 토큰이 있습니다:

scope=service::dds.microsoft.com::MBI_SSL_TOKEN_BROKER
scope=service::activity.windows.com::MBI_SSL_SA_TOKEN_BROKER

따라서 Microsoft 계정 서비스는 DDS 등록 및 GDID를 전달하는 활동 업로드를 인증하는 장치 자격 증명을 제공합니다.

6.4 전체 체인

flowchart TD
    subgraph MSA["MSA identity layer: wlidsvc.dll"]
        A1["Provision device with login.live.com<br/>(Passport PPCRL SOAP)"] --> A2["Server assigns Device PUID<br/>&lt;ps:DevicePUID&gt; / HWPUIDFlipped"]
        A2 --> A3["Store DeviceId / LID = PUID<br/>HKLM\...\IdentityStore"]
        A3 --> A4["Issue device tokens for<br/>dds.microsoft.com and activity.windows.com"]
    end
    subgraph CDP["Device graph client: cdp.dll / CDPSvc"]
        B1["GetStableDeviceId -> receives PUID string"] --> B2["RegisterUserDeviceAsync -> DDS<br/>OBSERVED: HTTP 200"]
    end
    subgraph SRV["Server: Device Directory Service"]
        C1["Keys g:PUID to the MSA account,<br/>activity and IP history"]
    end
    subgraph REP["Reporting"]
        D1["Delivery Optimization -><br/>UCDOStatus.GlobalDeviceId"]
    end
    A4 --> B1
    B2 --> C1
    C1 --> D1

고소장에서 "GDID"에 대해 언급하는 모든 것(설치당 영구적, 업데이트 후에도 지속, 재설치 시 새로 생성, Microsoft 계정에 연결, IP 및 검색 기록에서 추적 가능)은 이것이 서버 할당 MSA Device PUID이며 CDP가 장치 그래프에 등록하는 것이라는 사실에서 비롯됩니다.

7. 자신의 GDID 찾기

[OBSERVED] Microsoft 계정에 로그인한 머신에서, 사용자 자신의 하이브에서 레지스트리 한 번 읽기, 관리자 권한 필요 없음:

(Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID

장치 PUID를 16진수 16자리(예: 0018XXXXXXXXXXXX)로 제공합니다. 서버 측에 표시되는 g:<decimal> 형식으로 보려면:

$hex = (Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID
"g:$([Convert]::ToUInt64($hex,16))"

머신에서 ExtendedProperties\LID가 비어 있으면 동일한 값이 HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\{...}\DeviceId에 있습니다.

[!WARNING] 자신의 값을 게시하지 마십시오. 장치 PUID, MSA CID(0003...), 사용자 SID는 모두 당신을 비식별화합니다. 공개 분석에서는 수정하십시오. 인용해도 안전한 유일한 값은 이미 공개된 법원의 값입니다.

8. 노출 줄이기

GDID는 장치가 Microsoft 계정 장치 그래프에 등록되고 Connected Devices Platform이 동기화 상태를 유지하기 때문에 존재합니다. 차단하려면:

• Connected Devices Platform (CDPSvc, CDPUserSvc)을 종료하고 활동 기록(설정, 개인 정보, 활동 기록)을 꺼서 그래프 동기화 및 활동 업로드를 중지합니다.
• %LOCALAPPDATA%\ConnectedDevicesPlatform을 삭제하면 로컬 CDP 상태만 지워집니다. PUID는 ID 저장소에서 바로 다시 돌아오므로 이것만으로는 충분하지 않습니다.
• 재설치는 새 GDID를 제공하지만(고소장에서 명시), 다시 등록하는 즉시 새 것에 연결됩니다.

9. 방법론 (재현 가능)

이 모든 것은 표준 Windows 11(빌드 26200) 머신에서 나왔습니다.

• 라이브 캡처: logman을 통해 CDP의 TraceLogging ETW 공급자(Microsoft.Windows.CDP.*)를 강제로 새 CDPSvc 등록하는 동안 캡처하고 tracerpt로 디코딩했습니다.
• 레지스트리 및 토큰 캐시: HKLM\SOFTWARE\Microsoft 아래의 IdentityStore 및 IdentityCRL.

ETW 및 정적 분석이 실제로 작동했습니다. 프록시는 시간 낭비일 뿐입니다.

Microsoft.Windows.CDP.Core                    {7762de0c-b0a6-571a-68d3-c018bf009496}
Microsoft.Windows.CDP.Core.Error              {a1ea5efc-402e-5285-3898-22a5acce1b76}
Microsoft.Windows.CDP.CDS                     {dfa6e32a-095f-5f57-d025-0887d33507a1}
Microsoft.Windows.CDP.Aggr                    {bc1826c8-369c-5b0b-4cd1-3c6ae5bfe2e7}
Microsoft.Windows.CDP.AFS                     {5fe36556-c4cd-509a-8c3e-2a547ea568ae}
Microsoft.Windows.CDP.OnecoreAccountProvider  {4ee5bf9a-3e8f-540b-8bfb-12457a2854b6}
Microsoft.Windows.CDP                          {9f4cc6dc-1bab-5772-0c71-a89954718d66}

[!NOTE] 트위터의 NullZeroX가 장치에 Microsoft 계정으로 로그인하지 않은 경우에도 GDID가 전송된다고 알려주었습니다. 얼마나 정확한지 확신할 수 없지만 주목할 가치가 있습니다.